ロックボックス・ファイル伝送の検証方法

ロックボックス処理の最初のステップは、ロックボックス・ファイル伝送を使用して銀行ファイルからインポートされたデータの検証です。

ロックボックス・プロセスでは、銀行から受け取ったデータが検証され、次のことが確認されます。

ファイル全体を受け取ったこと。
バッチ内に重複する入金がないこと。
顧客およびトランザクションが有効であること。

また、ロックボックスでは、AR_PAYMENTS_INTERFACE_ALL表の列がReceivablesの適切な値および列を参照していることを確認することで、すべてのデータがReceivablesと互換性があることも検証されます。

ロックボックス検証に影響する設定

ロックボックスでは、重複する入金およびトランザクションをチェックします。

重複する入金では、入金番号、金額、通貨および顧客アカウント番号が同じです。ロックボックスでは、同じ顧客に同じ入金ソース内の重複する入金は許可されません。これは、入金を手動で入力した場合にReceivablesで実行される検証と同じです。

トランザクション番号は、入金ソース内で一意性を確保するためにのみ必要です。顧客は、異なる入金ソースに属するかぎり、重複するトランザクション番号を持つことができます。ただし、ロックボックスは、これらのトランザクションに支払を自動的に消し込むことはできません。

顧客がロックボックス伝送内に同じ番号の複数のトランザクションを持っている場合、ロックボックスは、支払の消込先のトランザクションを決定できません。この場合、入金は「未消込」(顧客アカウント番号またはMICR番号が指定されている場合)または「不明」(顧客アカウント番号またはMICR番号が指定されていない場合)のいずれかになります。

Receivablesにより実装に応じて提示されるトランザクション勧告に従って、入金を手動で消し込むことができます。

ロックボックス伝送の検証方法

銀行ファイルをインポートすると、ロックボックスで次の検証が行われます。

伝送レベルの検証
ロックボックス・レベルの検証
バッチ・レベルの検証
入金レベルの検証
オーバーフロー・レベルの検証
顧客の検証
通貨の検証

伝送レベルの検証

ロックボックスではロックボックス伝送を検証し、伝送情報が伝送フォーマットに対応していることを確認します。次の属性が検証されます。

伝送フォーマットに入金レコードが含まれています。
ロックボックス番号は伝送フォーマットの一部であるか、ロックボックスの発行時にロックボックス番号を指定します。
会計日はオープン会計期間内にあります。
指定した合計伝送レコード件数および金額は、ロックボックスによって決定される実際の入金件数および金額と一致する必要があります。伝送フォーマットに伝送ヘッダーまたはトレーラが含まれる場合、ロックボックスはこの伝送のすべてのレコードをカウントします。検証済件数には、暫定表に転送されたすべての入金レコードおよび詳細レコードが含まれています。
採番番号は有効です(指定されている場合)。

ロックボックス・レベルの検証

ロックボックスではロックボックス・レコードを検証し、ロックボックス情報が伝送フォーマットに対応していることを確認します。次の属性が検証されます。

伝送フォーマットに伝送ヘッダーまたはトレーラが含まれる場合は、ロックボックス番号が含まれており、有効であることを確認します。
ロックボックス・バッチ件数は正しいです(指定されている場合)。
ロックボックス金額は正しいです(指定されている場合)。
ロックボックス・レコード件数は正しいです(指定されている場合)。
採番番号は有効です(指定されている場合)。
ロックボックス番号は重複していません。

バッチ・レベルの検証

ロックボックスではバッチ・レコードを検証し、バッチ情報が伝送フォーマットに対応していることを確認します。次の属性が検証されます。

バッチ名はバッチ・レコードに存在します。
バッチ名は伝送内で一意です。
バッチ金額は正しいです。
バッチ・レコード件数は正しいです。
ロックボックス番号はバッチ・レコードに存在します(この番号が伝送フォーマットの一部である場合)。

入金レベルの検証

ロックボックスでは入金レコードを検証し、入金情報が伝送フォーマットに対応していることを確認します。次の属性が検証されます。

送金額が指定されています。
小切手番号が指定されています。
品目番号が指定されており、バッチ、ロックボックスまたは伝送内で一意です(伝送フォーマットに応じて)。
ロックボックス番号が指定されており(この番号が伝送フォーマットのロックボックス・ヘッダーまたはトレーラの一部でない場合)、バッチがインポートされていません。
バッチ名が指定されています(バッチ・ヘッダーまたはトレーラが伝送フォーマットの一部である場合)。
アカウント番号が指定されています(伝送経路番号が伝送フォーマットの一部である場合)。
Invoice1-8は有効であるか、空白のままです。
Installment1-8は有効な賦払番号であるか、空白のままです。
照合番号から導出された請求書、デビット・メモ、クレジット・メモ、対顧客勘定クレジットまたはチャージバック番号は入金に属していません。
消込金額が指定されているトランザクション番号が入力されています。
入金の消込済金額列すべての合計が、送金額を超えていません。
顧客アカウント番号が有効です。
顧客アカウント番号とMICR番号の両方が同じ顧客を参照しています(両方が指定されている場合)。
入金日が指定されています。
入金方法が有効です。
通貨が有効です。

オーバーフロー・レベルの検証

ロックボックスではオーバーフロー・レコードを検証し、オーバーフロー情報が伝送フォーマットに対応していることを確認します。次の属性が検証されます。

バッチ名が指定されています(バッチ・ヘッダーまたはトレーラが伝送フォーマットの一部である場合)。
ロックボックス番号が指定されています(バッチ・ヘッダーまたはトレーラが指定されておらず、伝送フォーマットにロックボックス番号が含まれている場合)。
品目番号が指定されており、入金レコードと一致します。
オーバーフロー・インジケータが指定されています(それが最後のオーバーフロー・レコードでない場合)。
オーバーフロー連番が指定されています。
Invoice1-8は有効であるか、空白のままです。
Installment1-8は有効な賦払番号であるか、空白のままです。
消込金額が指定されている導出済トランザクション番号が入力されています。

ノート: Invoice1-8の入金検証およびオーバーフロー検証の場合: 照合番号を使用しており、入金レコードがこの入金によって複数のトランザクションが支払われることを示す場合、ロックボックスでは、すべてのトランザクションが同じ文書タイプ(請求書、販売オーダー、購買オーダーなど)であるとみなされます。たとえば、最初の2つのトランザクションが請求書の場合、ロックボックスでは、それらがこの入金と正常に照合されます。ただし、次のトランザクションが請求書でない場合、ロックボックスはロックボックス定義に応じて、入金額の残金を「不明」としてインポートするか、入金全体を拒否します。ロックボックスが残りの入金額を「未消込」としてインポートする場合は、無効な照合番号がReceivablesに保持されます。

顧客の検証

ロックボックスは、次の属性に基づいて顧客データを検証するか、一致が見つからない場合は入金を「不明」としてマークできます。

顧客アカウント番号が有効です。
MICR番号が有効です。
請求先顧客は照合済請求書に基づいています(照合が有効な場合)。

通貨の検証

Receivablesを使用すると、複数の通貨で入金を処理できます。通貨、換算タイプおよび入金日を渡した場合、ロックボックスは換算レートを決定しようとします。ロックボックスが換算レートを決定できない場合、入金の検証は失敗します。