この章の内容は次のとおりです。
銀行、支店および口座は銀行口座モデルを前提として連携します。
このモデルにより、すべての銀行口座を1箇所で定義および追跡し、口座へのアクセスを次の対象に明示的に許可できます。
複数のビジネス・ユニット
機能
ユーザー
これにより、いくつかの異なるビジネス・ユニットで同じ銀行口座を共有する場合に、これらのビジネス・ユニットで銀行口座を重複して設定することがなくなります。
銀行口座作成の最初のステップは銀行の作成です。 次のことが可能です。
既存の銀行を検索、表示および更新するか、新規銀行を作成します。
既存のパーティから新規銀行を作成します。
次のことを考慮します。
既存のパーティから作成するというオプションは、照合オプションによって暗黙的に実装されます。
このオプションは、同じ銀行が設定された既存のパーティが見つかった場合にのみ使用できます。
照合オプションを選択すると、一致するパーティの情報がページに再投入されます。
銀行の作成が終了したら、次に、その銀行に関連する支店を1つ以上作成します。 支店を作成する際にも照合オプションを使用できます。 照合オプションを使用せずに新規支店を作成するには、次の手順を実行します。
必須の情報を手動で入力します。 任意で次のことを行います。
ページで支店関連のその他の属性を定義します。
既存のパーティが見つかったときに照合オプションを使用しなかった場合は、同じパーティ名を使用して支店が作成されます。
銀行および支店の作成が終了したら、次の手順を実行して銀行口座の設定に進むことができます。
銀行口座に関連付ける銀行支店を選択します。
銀行口座の所有者を割り当てます。
口座の定義には次の4つの領域が関連します。
一般情報
口座の管理
セキュリティ、口座へのアクセス
ビジネス・ユニット割当
次のことを考慮します。
Oracle Fusion Account PayablesまたはReceivablesの口座の場合は、ビジネス・ユニットによって識別されます。
Oracle Fusion Payrollの口座の場合は、法的エンティティによって識別されます。
電子銀行取引明細書プロセスでは、銀行取引明細書を転送し、Oracle Fusion Cash Managementにインポートします。
取引明細書のファイル・フォーマットとして次の4つがサポートされています。
BAI2
SWIFT MT940
EDIFACT FINSTA
ISO20022 CAMT053
Oracle Public CloudからOracle Fusion Applicationsにアクセスする顧客は、Oracle WebCenter Content Managementの文書リポジトリを使用して銀行取引明細書ファイルを転送できます。 WebCenter文書リポジトリは、他の実装によってOracle Fusion Applicationsにアクセスする顧客も利用できます。 Cash Managementユーザー向けのWebCenterには、fin/cashManagement/importというアカウントが設定されています。
銀行取引明細書をロードおよびインポートするには、取引明細書ファイルをzipファイルに圧縮し、WebCenter文書リポジトリに転送してアカウントfin/cashManagement/importの下に配置します。 「インポートのためのインタフェース・ファイルのロード」プロセスを実行して処理を進めます。
このプロセスは次の3つのフェーズで構成されます。
フェッチ・フェーズ: プログラムにより、WebCenterのアカウントから銀行取引明細書zipファイルがフェッチおよび解凍され、取引明細書ファイルがデータベースに格納されます。
ロード・フェーズ: プログラムにより、フェッチされた電子銀行取引明細書が処理され、ステージング領域とも呼ばれる銀行取引明細書インタフェース表に追加されます。
インポート・フェーズ: ステージング領域からロードされた銀行取引明細書データが機能検証に対して処理されてから、銀行取引明細書表に移入されます。 このフェーズでは、解析ルールが実行されます。
インポート・エラーによりプロセスが失敗した場合は、報告されたエラーを修正します。 銀行取引明細書および調整の概要ページの「処理の警告およびエラー」表からインポート・フェーズのみを再実行します。 ただし、ロード・フェーズでエラーが発生した場合は、エラー・データをパージし、プログラムを再発行します。
Oracle Fusion Cash ManagementおよびOracle Fusion Paymentsで電子銀行取引明細書を処理するには、次の前提条件を満たす必要があります。
Cash Managementで次のエンティティを設定します。
銀行口座
残高コード: オープン/クローズ記帳済残高および使用可能残高のISO 20022残高コードが提供されており、追加のコードを残高コード・ルックアップ(CE_INTERNAL_BALANCE_CODES)を使用して定義できます。
トランザクション・コード
解析ルール
銀行取引明細書処理プログラムはPaymentsと統合されています。
プログラムを使用する前に、Paymentsで次のエンティティを設定します。
コード・マップ・グループ: プログラムでは、外部データ・ファイルで報告される残高コードやトランザクション・コードをCash Managementで内部的に定義されているコードにマッピングするために、コード・マップ・グループが使用されます。 各コード・マップ・グループはフォーマットに割り当てられています。 BAIおよびEDIFACTオープン/クローズ記帳済残高コードを内部残高コードにマッピングした2つのコード・マップ・グループが提供されています。 SWIFT940はポジションベースであるため、残高コード・マッピングは不要ですが、トランザクション・コードを内部的に定義されているトランザクション・コードにマッピングするためのコード・マップ・グループは作成可能です。 提供されているコード・マップ・グループはごく基本的なマッピングです。 これらを必要に応じて拡張したり、新規コード・マップ・グループを作成することもできます。
次の例は、電子銀行取引明細書のロード方法について説明しています。
銀行から銀行取引明細書ファイルbai2.txtを取得します。
ファイルをbai2.zipというzipファイルに圧縮します。
ファイルのインポートおよびエクスポート機能を使用して、zipファイルをWebCenter文書リポジトリに転送してアカウントfin/cashManagement/importの下に配置します。
注意
インポートおよびエクスポート・プロセスの詳細は、このトピックの末尾にあるFiles for Import and Export: Explainedのハイパーリンクを参照してください。
「インポートのためのインタフェース・ファイルのロード」プロセスを実行します。 このプログラムには、「インポート・プロセス」および「データ・ファイル」の2つのパラメータがあります。
インポート・プロセス: 銀行取引明細書のファイル・フォーマットに応じて、資金管理プロセスBAI2フォーマットの銀行取引明細書、資金管理プロセスSWIFT MT940フォーマットの銀行取引明細書、資金管理プロセスEDIFACT FINSTAフォーマットの銀行取引明細書、資金管理プロセスISO20022 CAMT053フォーマットの銀行取引明細書の4つのうちいずれかを選択します。
データ・ファイル: WebCenter文書リポジトリからzipファイルを選択します。 たとえば、アカウントfin$/cashManagement$/import$のbai2.zipを選択します。
銀行取引明細書および調整の概要ページで処理エラーの有無をチェックします。 ファイルが正常にインポートされた場合は、「銀行取引明細書の管理」ページからレビューできるようになります。
非クラウド実装では、取引明細書ファイルをローカル・マシンまたはリモート・コンピュータにも格納できます。 「電子銀行取引明細書の処理」を実行して取引明細書ファイルを転送およびインポートします。 このプロセスを使用する際には、取引明細書ファイルを圧縮しないでください。
「電子銀行取引明細書の処理」プロセスは次の3つのフェーズで構成されます。
フェッチ・フェーズ: プログラムにより、外部ソースから電子銀行取引明細書ファイルまたはストリームがフェッチされ、データベースに格納されます。 外部ソースは、リモート・コンピュータに格納されているファイルまたはローカル・コンピュータに格納されているファイルです。
ロード・フェーズ: プログラムにより、フェッチされた電子銀行取引明細書が処理され、ステージング領域とも呼ばれる銀行取引明細書インタフェース表に追加されます。
インポート・フェーズ: ステージング領域からロードされた銀行取引明細書データが機能検証に対して処理されてから、銀行取引明細書表に移入されます。 このフェーズでは、解析ルールが実行されます。
このプログラムを実行する前に、前述の前提条件に加え、Oracle Fusion Paymentsで次のエンティティを設定しておく必要があります。
支払システム
伝送構成
フォーマット: Cash Managementには、サポートされている銀行取引明細書フォーマットごとに1つのフォーマットが用意されています。 別のフォーマットを追加することもできます。
自動調整は、銀行取引明細書明細とシステム・トランザクション間の調整に使用される最も一般的なプロセスです。 大量の銀行取引明細書を処理したり、調整プロセスを自動化する場合に、自動調整を使用します。 自動調整プログラムでは、銀行口座に割り当てられている調整ルール・セットに基づいて、銀行取引明細書明細とシステム・トランザクション間の調整が行われます。
特定の銀行取引明細書明細との照合対象となるアプリケーション・トランザクションを自動調整プログラムで検出できなかった場合、調整例外が発生します。
例外は次のように分類されます。
不明瞭: 明細と照合可能なアプリケーション・トランザクションが複数ある場合、またはトランザクションが複数の取引明細書明細と照合可能な場合、この例外が発生します。
日付: システム・トランザクションが、トランザクションの日付が許容範囲外であることを除いてすべての照合基準を満たす場合、この例外が発生します。
金額: システム・トランザクションが、トランザクションの金額が許容範囲外であることを除いてすべての照合基準を満たす場合、この例外が発生します。
自動調整例外
1対1自動調整ルールごとに、例外が次の順序で検索されます。
不明瞭
日付
金額
特定の銀行取引明細書明細にいずれか1つの例外タイプが見つかった場合、プログラムは、同じルールを使用したその他の例外タイプの検索を停止します。
適切な照合システム・トランザクションを選択して調整できるように、例外が銀行取引明細書明細のコンテキストで表示されます。
アプリケーション・トランザクションが複数の銀行取引明細書明細に対して例外である場合、それらの取引明細書明細のいずれか1つとしか調整できません。
問題が発生した場合、銀行取引明細書処理プログラムの結果が、「銀行取引明細書および調整」作業領域に表示されます。 処理エラーおよび警告リージョンに表示されるステータスは次のとおりです。
| ステータス | 説明 |
|---|---|
|
ロード・エラー |
このステータスはファイル・レベルで割り当てられます。 データのフェッチ中にエラーが発生したか、データの解析中およびインタフェース表への追加中にエラーが発生したために、ファイルのロードに失敗します。 このようなエラーは、通常、データが標準に準拠していない場合に発生します。 |
|
インポート・エラー |
このステータスは取引明細書レベルとファイル・レベルの両方で割り当てられます。 取引明細書レベルでのインポート・エラーは、データがインタフェースに追加され、正常にロードされたにもかかわらず、一部の機能検証が失敗したことを示しています。 たとえば、銀行取引明細書が重複していたり、トランザクション・コードが設定されていない場合などです。 ファイル・レベルでのインポート・エラーは、インポート・エラーで失敗したファイルに1つ以上の取引明細書が存在することを示しています。 |
|
インポート警告 |
このステータスは取引明細書レベルで割り当てられます。 「インポート警告」が割り当てられた取引明細書は、エラーなしでインポートされたものの、いくつかの機能検証に失敗し、それらの失敗がインポートの停止を必要とするほど深刻ではなかったことを示しています。 |
ファイルまたは取引明細書のステータスとそれに関連する問題によっては、「再試行」アイコンを使用して、プログラムを前回の実行で失敗した場所から再開できる場合もあります。 次の表は、使用可能な各種再試行オプションを示しています。
| ステータス | 再試行ダイアログのフィールド | プログラムの再発行時の動作 |
|---|---|---|
|
ロード・エラー |
フェッチ・フェーズでファイルにエラーが発生した場合(「ファイルID」にハイパーリンクは表示されない)。ダイアログでは、プログラム発行時に指定したすべてのパラメータが使用可能です。 これらのパラメータを更新し、プログラムを再発行できます。 |
フェッチ・フェーズから再開されます。 |
|
ロード・エラー |
ロード・フェーズでファイルにエラーが発生した場合(「ファイルID」にハイパーリンクが表示される)。 ファイルはフェッチ済であるため、ファイルのフェッチに関連するパラメータは表示されません。「フォーマット」パラメータのみが表示されます。 以前の実行で「フォーマット」に誤った値を指定した場合は、ここでその値を訂正し、プログラムを再発行できます。 |
ロード・フェーズから再開されます。 指定したフォーマットを使用して、フェッチ済のデータ・ファイルのロードが試行されます。 |
|
インポート・エラー |
ファイル・レベルでのインポート・エラー。再試行ダイアログにフィールドは表示されません。 |
該当するファイルにおいて、インポート・エラーが発生したすべての取引明細書に対してインポート・フェーズが開始されます。 |
|
インポート・エラー |
取引明細書レベルでのインポート・エラー。 取引明細書で銀行口座重複エラーが発生した場合は、ダイアログに銀行口座フィールドが表示されます。 正しい銀行口座を選択し、プログラムを再発行できます。 |
更新した銀行口座を使用して、該当する特定の取引明細書に対してインポート・フェーズが開始されます。 該当する特定の取引明細書に対してインポート・フェーズが開始されます。 |
|
インポート・エラー |
取引明細書レベルでのインポート・エラー。その他のインポート・エラーが発生した場合は、再試行ダイアログにフィールドは表示されません。 |
更新した銀行口座を使用して、該当する特定の取引明細書に対してインポート・フェーズが開始されます。 該当する特定の取引明細書に対してインポート・フェーズが開始されます。 |
次の一般的な問題と解決策のリストは、銀行取引明細書処理プログラムのトラブルシューティングに使用できます。
| 問題 | 解決策 |
|---|---|
|
プログラムを実行し、正常に完了しましたが、「銀行取引明細書の管理」ページに表示されません。 |
「銀行取引明細書および調整」作業領域をチェックし、銀行取引明細書に対する処理エラーが報告されていないか確認します。 |
|
ファイルのロード・エラーが報告され、誤ったファイルが処理されたことが明らかになったため、エラーを修正する必要があります。 |
ファイルがフェッチされている場合は(「ファイルID」フィールドにハイパーリンクが表示される)、そのファイルをパージしてから正しいファイルをロードする必要があります。 ファイルがフェッチされていない場合は(「ファイルID」フィールドにハイパーリンクは表示されない)、「再試行」オプションを使用してプログラムを再開できます。 |
|
ファイルのロード・エラーが報告され、ファイルがフェッチされました。 データ・ファイル内の問題を解決したため、プログラムを再試行する必要があります。 編集したファイルを処理できますか。 |
いいえ。システムにフェッチされたデータ・ファイルの再処理が必要な場合は、新たにプログラムを発行する必要があります。 ファイルがフェッチされると、後からそのファイルで再試行しても、元のソースからデータ・ファイルが再フェッチされることはありません。 |
|
データ・ファイルを処理したところ、一部の取引明細書は正常にインポートされましたが、一部は失敗しました。 失敗の原因は銀行からのエラーです。 訂正済のファイルが送信されましたが、ファイルには、正常にインポートされた他の取引明細書データが含まれています。 このファイルを再び処理した場合、どのような影響がありますか。 |
同じファイルを処理しても問題はありません。 プログラムには重複する銀行取引明細書を検出する機能があり、このような取引明細書には「インポート・エラー」としてフラグが設定されます。 |
|
データ・ファイル内のトランザクション・コードAまたは残高コードAがインポート後にBと表示されます。 なぜですか。 |
AがBとマッピングされるように定義されたコード・マッピングがあるかどうか確認します。 |
|
新規コード・マップ・グループが定義されていますが、正しく機能していないように思われます。 |
Oracle Fusion Paymentsで新規コード・マップ・グループがフォーマットに割り当てられていることを確認します。 |
|
トランザクション・コードが定義されていない場合はインポート・エラーが報告されますが、残高の残高コードが欠落している場合は報告されないか、警告が表示されます。 残高コードはどうなりますか。 |
このような残高はプログラムによりインポートされ、銀行取引明細書ユーザー・インタフェースに表示されます。 ただし、残高摘要はシステムに定義されていないため空になります。 |
|
インポート後、一部の残高レコードの残高摘要が空になります。 |
残高レコードの残高コードが残高コード・ルックアップで定義されているかどうか確認します。 |
|
トランザクション・コードが定義されていないことが通知されます。 コード・マップとトランザクション・コードのどちらを定義する必要がありますか。 |
既存の内部コードが新規コードと同じ目的を果たす場合は、新規コードと既存のコードを関連付けるコード・マップを作成できます。 トランザクション・コードをそのまま使用する場合は、トランザクション・コードを定義します。 |
銀行取引明細書の手動調整では、調整対象の銀行取引明細書明細とシステム・トランザクションを選択する必要があります。 調整時にシステム・トランザクションがまだ決済されていない場合は、調整プロセスにより最初にトランザクションが決済された後に、調整が行われます。 Oracle Fusion Cash Managementでは、1対1、1対多、多対1、多対多のすべての照合シナリオに対して手動調整がサポートされています。 同じ銀行口座からの銀行取引明細書間での調整が可能です。
銀行は、銀行口座への入金額や銀行口座からの引出額を間違う場合があります。 このような銀行エラーは、その訂正および修正とともに銀行取引明細書に表示されます。 銀行は、2つの方式(戻し処理および修正)を使用してエラーを解消します。
次の例は、戻し処理方式および修正方式により銀行エラーを訂正する方法について説明しています。
$100.00の小切手が発行されましたが、銀行はこの支払を間違って$10.00と記録しました。 銀行取引明細書には、$10.00の支払が入力されています。
戻し処理方式を使用する場合、銀行は、エラー入力と戻し処理入力が差し引き0になるように、エラー・トランザクション金額全体を戻し処理します。 その後、銀行は、金額の正しい別のトランザクション入力を作成します。 この例では、元のエラー入力を相殺するために、$10.00の入金の戻し処理入力が作成されます。 さらに、$100.00の支払として追加訂正入力が作成されます。 戻し処理方式では、小切手トランザクションとの調整のために、取引明細書のエラー明細と戻し処理明細、および追加した訂正入力明細をすべて使用します。
修正方式を使用する場合、銀行は、単に、元のトランザクション金額とエラー入力の差異を補う追加トランザクション入力を作成します。 この例では、銀行は、$90.00の支払の追加修正入力を生成します。 修正金額である$90.00は、元のエラー支払金額$10.00と正しい支払金額$100.00の差異です。 修正方式では、エラー明細および修正明細が小切手トランザクションに対して調整される必要があります。
外部資金トランザクションとは、アプリケーション内に記録されていない現金取引に関連するトランザクションのことです。 外部トランザクションのソースは次の4つです。
手動入力
インポート
貸借一致トランザクション: 銀行手数料、換算レートまたはその他の手数料などが原因で取引明細書明細とシステム・トランザクション間に差額が生じた場合に、その差額を記録する目的で作成されるトランザクションです。
銀行取引明細書: 銀行取引明細書トランザクション作成プログラムを使用すると、銀行手数料、利息またはその他の項目などを記録するために、未調整取引明細書明細からトランザクションを作成するようにルールを構成できます。
外部アプリケーションからトランザクションを作成する場合や大量の入力を扱うトランザクションを作成する場合、「スプレッドシートでのトランザクションの作成」テンプレートを使用します。
外部資金トランザクションを作成するには、次の手順を実行します。
データを準備します。
CSVファイルを生成します。
データを転送します。
データをロードおよびインポートします。
必要に応じてインポート・エラーを修正します。
ワークシートでデータを準備する際には、次のガイドラインに従ってください。
各列に必要な情報を入力します。 詳細な指示は、各列ヘッダーのツールチップを参照してください。
テンプレートの列の順序を変更しないでください。
使用しない列は非表示にしたりスキップできますが、削除しないでください。
データを準備する際に推奨されるベスト・プラクティスは次のとおりです。
このテンプレートに外部トランザクションを手動で直接入力します。
または、このテンプレートと同じ列および構造を持つ一時スプレッドシートに外部アプリケーションのデータを抽出します。 その後、一時スプレッドシート内のデータを切り取ってテンプレートに貼り付けます。
必要に応じて、各トランザクションにトランザクション・タイプを割り当てます。 Oracle Fusion Cash Managementは、次のトランザクション・タイプに対応しています。
| トランザクション・タイプ | 意味 |
|---|---|
|
ACH |
自動手形交換所 |
|
BKA |
銀行修正 |
|
BKF |
手数料 |
|
CHK |
小切手 |
|
EFT |
電子送金 |
|
INT |
利息 |
|
LBX |
ロックボックス |
|
MSC |
その他 |
|
ZBA |
ゼロ残高 |
外部データの準備が終了したら、次の手順に進みます。
| タスク | 処理 | 結果 |
|---|---|---|
|
1. CSVファイルを生成します。 |
CSVファイルの生成ボタンをクリックします。 |
CSVファイルを含むzipファイルが作成されます。 |
|
2. zipファイルを転送します。 |
ツール→ファイルのインポートおよびエクスポートの順にナビゲートします。 |
WebCenter文書リポジトリにzipファイルが転送されます。 |
|
3. データをロードおよびインポートします。 |
「インポートのためのインタフェース・ファイルのロード」プログラムを実行します。 |
WebCenterリポジトリからzipファイルでデータが転送されます。 |
|
4. インポート・エラーを修正します。 |
「インポート・エラーの修正」スプレッドシートを使用して修正を加え、アップロード・プロセスを繰り返します。 |
正常に完了したら、インタフェース表から外部トランザクション表にデータがインポートされます。 ロードおよびインポート・プロセスでエラーが発生した場合は、必要に応じて修正します。 |
ここでは、Oracle Fusion Cash Managementで実行される国固有の銀行口座検証ルールの概要について説明します。
次の国には国固有の検証が存在します。
アンドラ
オーストラリア
オーストリア
ベルギー
ボスニア・ヘルツェゴビナ
ブラジル
ブルガリア
カナダ
コロンビア
クロアチア
キプロス
チェコ共和国
デンマーク
エストニア
フィンランド
フランス
フランス領ギアナ
ドイツ
ジブラルタル
ギリシャ
グアドループ島
銀行口座を入力する際、様々な国に、フォーマットや次の関連フィールドのコンテンツを制御する特定のルールを設定できます。
銀行コード
支店番号
口座番号
検証桁
IBAN
「国固有の銀行検証の使用不可」というプロファイル・オプションが導入されました。 このプロファイルはサイト、製品またはユーザー・レベルで設定できます。 サイト・レベルでは、プロファイルはデフォルト値「いいえ」に事前定義されています。 銀行コード、支店番号、口座番号、検証桁およびIBANに関連する国固有の検証は、このプロファイル・オプションで使用不可に設定できます。 プロファイルが「はい」に設定されている場合、これらの検証は実行されません。 一意の銀行、支店、口座および銀行口座番号の必須要件についてのチェックは、このプロファイルによる影響を受けません。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
口座番号の検証アルゴリズム
入力検証桁CD1は、口座番号の最後の2桁です。
計算検証桁CD2は、口座番号の最初の2つのセクションを連結し、それを97で除算して余りを計算することによって導出されます。 余りが0になった場合は、計算検証桁は97になります。
入力検証桁(CD1)と計算検証桁(CD2)が等しくなれば口座番号は有効とみなされ、そうでなければ検証は失敗になります。
さらに、計算検証桁が00になることはないため、入力検証桁(つまり、最後のセクション)が00である場合、口座番号は無効になります(3つ目のポイントによる)。
口座番号123-4567890-78を使用した例
入力検証桁(CD1)は78です。 最初の2つのセクションを連結すると、1234567890になります。
結果を97で除算します。 1234567890 / 97 = 12727504となります。
余りを導出します。 1234567890 - (12727504 * 97) = 2となるため、CD2 = 2です。
ここで、CD1 <> CD2であるため、口座番号は無効です。
この場合、有効な口座番号は123456789-02です。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
会社コード |
|
|
セカンダリ勘定参照 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
コロンビアの場合、「銀行コード」、「支店番号」、「口座番号」または「検証桁」フィールドの検証は行われません。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
納税者ID |
|
|
IBAN |
|
納税者IDの検証アルゴリズム
最初の15桁に関連ファクタが乗算されます。
| 桁 | ファクタ |
|---|---|
|
1桁目 |
71 |
|
2桁目 |
67 |
|
3桁目 |
59 |
|
4桁目 |
53 |
|
5桁目 |
47 |
|
6桁目 |
43 |
|
7桁目 |
41 |
|
8桁目 |
37 |
|
9桁目 |
29 |
|
10桁目 |
23 |
|
11桁目 |
19 |
|
12桁目 |
17 |
|
13桁目 |
13 |
|
14桁目 |
7 |
|
15桁目 |
3 |
これらの15個の積を加算し、合計を11で除算します。
余りが1または0である場合は、検証桁はそれぞれ1または0になります。
余りが1または0でない場合は、余りから11が減算され、その値が検証桁になります。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
| 口座番号の1桁目 | 検証値の構成方法 |
|---|---|
|
1 |
1 |
|
2 |
1 |
|
3 |
1 |
|
4 |
2 |
|
5 |
2 |
|
6 |
1 |
|
7 |
2 |
|
8 |
1 |
|
9 |
1 |
方法1
検証値は次の2つの部分で構成されます。
検証値の最初の部分は口座番号の最初の6桁で構成されます。 たとえば、口座番号が123456789である場合、検証値の最初の部分は123456として作成されます。
検証値の2つ目の部分は口座番号の8桁目から15桁目までの8桁の値で構成されます。 長さが8未満の場合、先行するゼロを必要な数だけ前に付けて8桁の数字に変換されます。 同じ例を使用すると、検証値の2つ目の部分は00000089として作成されます。その後、2つの部分を連結して検証値が構成されます。 つまり、この例では、検証値は12345600000089として構成されます。
方法2
検証値は次の3つの部分で構成されます。
検証値の最初の部分は口座番号の最初の6桁で構成されます。 たとえば、口座番号が123456789である場合、検証値の最初の部分は123456として作成されます。
検証値の2つ目の部分は口座番号の8桁目です。 同じ例を使用すると、検証値の2つ目の部分は8として作成されます。
検証値の3つ目の部分は口座番号の9桁目から15桁目までの7桁の値で構成されます。 長さが7未満の場合、先行するゼロを必要な数だけ前に付けて7桁の数字に変換されます。 同じ例を使用すると、検証値の3つ目の部分は0000009として作成されます。 検証値は3つの部分を連結して構成されます。 つまり、この例では、検証値は12345680000009として構成されます。
合計は検証値に基づいて算出されます。 構成された検証値の最初の2桁に応じて、実行される計算が異なります。
検証値の最初の2桁が88である場合:
フィンランド政府は次のファクタ表を提供しています。 検証値の8桁目から13桁目に関連ファクタが乗算されます。 各結果を加算して合計が算出されます。
| 桁 | ファクタ |
|---|---|
|
8桁目 |
1 |
|
9桁目 |
3 |
|
10桁目 |
7 |
|
11桁目 |
1 |
|
12桁目 |
3 |
|
13桁目 |
7 |
検証値88345600000089を使用した例: 指定の桁に指定のファクタが乗算されます。
| 桁 | 値 | ファクタ | 結果 |
|---|---|---|---|
|
8桁目 |
0 |
1 |
0 |
|
9桁目 |
0 |
3 |
0 |
|
10桁目 |
0 |
7 |
0 |
|
11桁目 |
0 |
1 |
0 |
|
12桁目 |
0 |
3 |
0 |
|
13桁目 |
8 |
7 |
56 |
|
合計 |
|
|
56 |
つまり、この例で算出される合計は56となります。
次のいずれにも該当しない場合、テストは不合格になります。
検証値の14桁目は、10から算出合計の最後の桁を減算した値と等しくなる必要があります。 検証値が88345600000089である場合、算出合計の最後の桁は6です。 つまり、10 - 6 = 4となります。 したがって、検証値の14桁目は4になる必要があります。 この場合、14桁目は9であるため、テストは不合格になります。
検証値の14桁目と算出合計の最後の桁がどちらも0である必要があります。 同じ例を使用すると、どちらの値も0ではないため、テストは不合格になります。
検証値の最初の2桁が88でない場合は、各奇数桁に対する次の計算値に偶数桁の値を加算することによって、最初の13桁の合計が算出されます。
桁に2を乗算します。
結果を10で除算します。
その結果の整数部と余りを加算します。
口座番号123456800000089を使用した例:
| 桁 | 値 | 乗算(a) | 除算(b) | 整数部 | 余り | 結果 |
|---|---|---|---|---|---|---|
|
1桁目 |
1 |
2 |
0.2 |
0 |
2 |
2 |
|
2桁目 |
2 |
|
|
|
|
2 |
|
3桁目 |
3 |
6 |
0.6 |
0 |
6 |
6 |
|
4桁目 |
4 |
|
|
|
|
4 |
|
5桁目 |
5 |
10 |
1 |
1 |
0 |
1 |
|
6桁目 |
6 |
|
|
|
|
6 |
|
7桁目 |
0 |
16 |
1.6 |
1 |
6 |
0 |
|
8桁目 |
0 |
|
|
|
|
0 |
|
9桁目 |
0 |
0 |
0 |
0 |
0 |
0 |
|
10桁目 |
0 |
|
|
|
|
0 |
|
11桁目 |
0 |
0 |
0 |
0 |
0 |
0 |
|
12桁目 |
0 |
|
|
|
|
0 |
|
13桁目 |
8 |
16 |
1.6 |
1 |
6 |
7 |
|
合計 |
|
|
|
|
|
28 |
その後、算出合計が次のプロセスにより変換され、変換後の値を使用して口座番号が有効かどうか判断されます。
算出合計に9を加算します。
結果を10で除算します。
結果の整数部に10を乗算します。
結果から元の算出合計を減算します。
つまり、算出合計28は次のようにして2に変換されます。
28 + 9 = 37
37/10 = 3.7、 結果の整数部 = 3
3 * 10 = 30
30 - 28 = 2
この数字と口座番号の14桁目が比較されます。 一致すればテストに合格し、そうでなければ不合格になります。
この例では、口座番号の14桁目は8であるため、テストは不合格になります。 14桁目が2であれば、テストに合格します。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
口座タイプ |
|
|
IBAN |
|
検証桁の検証アルゴリズム
検証桁(CD1)は、次の方法で口座番号、銀行コードおよび支店番号から計算されます。 これは、検証桁妥当性テストの基準として使用されます。
CD1
検証アルゴリズム用に、AからZまでの文字として入力された口座番号の桁が数値に変換されます。フランス政府は次の変換表を提供しています。
| 値 | 変換 |
|---|---|
|
A、J |
1 |
|
B、K、S |
2 |
|
C、L、T |
3 |
|
D、M、U |
4 |
|
E、N、V |
5 |
|
F、O、W |
6 |
|
G、P、X |
7 |
|
H、Q、Y |
8 |
|
I、R、Z |
9 |
口座番号A1234567890を使用した例:
文字Aは上の表に従って1に変換されるため、口座番号は11234567890になります。
CD1の値は、次の方法で銀行フィールドを連結することによって構成されます。
銀行コードが支店番号と連結され、さらに変換後の口座番号と連結されます。 たとえば、銀行コードが12345、支店番号が67890、変換後の口座番号が11234567890であるとします。 この場合、CD1は123456789011234567890として作成されます。
この連結値にサフィクスとして00を追加し、その結果の値を97で除算します。 この除算の余りを97から減算します。 この減算の結果が計算検証桁になります。
この例では、サフィクス00の追加により12345678901123456789000になります。 これを97で除算し、余りを導出します。 Mod (12345678901123456789000, 97) = 86となります。その結果を97から減算します。 97 - 86 = 11となります。
ユーザーが入力した検証桁とこの計算値が等しい場合、検証は成功です。
この例では、ユーザーが入力した検証桁が11ではないため、検証は無効です。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
ここでは、Oracle Fusion Cash Managementで実行される国固有の銀行口座検証ルールの概要について説明します。
次の国には国固有の検証が存在します。
ハンガリー
アイスランド
アイルランド
イスラエル
イタリア
日本
クウェート
ラトビア
リヒテンシュタイン
リトアニア
ルクセンブルグ
マケドニア
マルタ
マルチニーク
モーリシャス
マイヨット
モナコ
モンテネグロ
オランダ
ニュージーランド
ノルウェー
銀行口座を入力する際、様々な国に、フォーマットや次の関連フィールドのコンテンツを制御する特定のルールを設定できます。
銀行コード
支店番号
口座番号
検証桁
IBAN
「国固有の銀行検証の使用不可」というプロファイル・オプションが導入されました。 このプロファイルはサイト、製品またはユーザー・レベルで設定できます。 サイト・レベルでは、プロファイルはデフォルト値「いいえ」に事前定義されています。 銀行コード、支店番号、口座番号、検証桁およびIBANに関連する国固有の検証は、このプロファイル・オプションで使用不可に設定できます。 プロファイルが「はい」に設定されている場合、これらの検証は実行されません。 一意の銀行、支店、口座および銀行口座番号の必須要件についてのチェックは、このプロファイルによる影響を受けません。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
口座番号の検証アルゴリズム
検証アルゴリズムは口座番号(9桁目から16桁目まで)に対して実行されます。 これらの各桁に次の表に示すファクタが乗算されます。
| 桁 | ファクタ |
|---|---|
|
9桁目 |
3 |
|
10桁目 |
2 |
|
11桁目 |
7 |
|
12桁目 |
6 |
|
13桁目 |
5 |
|
14桁目 |
4 |
|
15桁目 |
3 |
|
16桁目 |
2 |
これらの積を加算し、合計を11で除算します。 この除算の余りを11から減算し、計算検証桁を導出します。 余りが0になった場合は、計算検証桁は0になります。
この計算検証桁と入力検証桁(口座番号の17桁目)が一致する必要があり、一致しない場合、口座番号は無効です。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証桁の検証アルゴリズム
検証桁は、銀行コード、支店番号および口座番号の検証に使用されます。 これらを連結して22文字の文字列が生成されます。
次の表に示すように、各文字には、文字列の中でその文字が奇数番目か偶数番目か応じて値が割り当てられます。
| 偶数番目の値 | 奇数番目の値 |
|---|---|
|
A/0 = 0 |
A/0 = 1 |
|
B/1 = 1 |
B/1 = 0 |
|
C/2 = 2 |
C/2 = 5 |
|
D/3 = 3 |
D/3 = 7 |
|
E/4 = 4 |
E/4 = 9 |
|
F/5 = 5 |
F/5 = 13 |
|
G/6 = 6 |
G/6 = 15 |
|
H/7 = 7 |
H/7 = 17 |
|
I/8 = 8 |
I/8 = 19 |
|
J/9 = 9 |
J/9 = 21 |
|
K = 10 |
K = 2 |
|
L = 11 |
L = 4 |
|
M = 12 |
M = 18 |
|
N = 13 |
N = 20 |
|
O = 14 |
O = 11 |
|
P = 15 |
P = 3 |
|
Q = 16 |
Q = 6 |
|
R = 17 |
R = 8 |
|
S = 18 |
S = 12 |
|
T = 19 |
T = 14 |
|
U = 20 |
U = 16 |
|
V = 21 |
V = 10 |
|
W = 22 |
W = 22 |
|
X = 23 |
X = 25 |
|
Y = 24 |
Y = 24 |
|
Z = 25 |
Z = 23 |
左端の文字は奇数番目です。 割り当てられた値をすべて加算して、その合計を26で除算します。
この除算の余りが次の表に従ってアルファベットに変換されます。
変換アルゴリズム
| 計算 | 計算 | 計算 |
|---|---|---|
|
0 = A |
9 = J |
18 = S |
|
1 = B |
10 = K |
19 = T |
|
2 = C |
11 = L |
20 = U |
|
3 = D |
12 = M |
21 = V |
|
4 = E |
13 = N |
22 = W |
|
5 = F |
14 = O |
23 = X |
|
6 = G |
15 = P |
24 = Y |
|
7 = H |
16 = Q |
25 = Z |
|
8 = I |
17 = R |
|
この値とユーザーが入力した検証桁が一致する必要があり、一致しない場合、検証桁の検証は失敗になります。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
銀行名カナ |
|
|
支店番号 |
|
|
カナ支店名 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
PostまたはGiro以外の口座番号の検証アルゴリズム
長さが10未満の場合、先行するゼロを必要な数だけ前に付けて10桁の数字に変換されます。
オランダ政府はこれらの10桁について次のファクタ表を提供しています。
| 桁 | ファクタ |
|---|---|
|
1桁目 |
10 |
|
2桁目 |
9 |
|
3桁目 |
8 |
|
4桁目 |
7 |
|
5桁目 |
6 |
|
6桁目 |
5 |
|
7桁目 |
4 |
|
8桁目 |
3 |
|
9桁目 |
2 |
|
10桁目 |
1 |
これらを乗算し、その積の合計を計算します。
得られた結果が11で完全に割り切れる場合(つまり、11での除算で余りがない場合)、テストは合格になり、それ以外の場合、入力された口座番号は無効です。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
摘要 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
たとえば、口座番号1234001234には検証アルゴリズムは適用されませんが、口座番号02056439653には後述するように検証アルゴリズムが適用されます。 |
|
検証桁 |
|
|
IBAN |
|
口座番号の検証アルゴリズム
1. 検証桁は、口座番号の最後の桁(つまり、11桁目)に設定されます。 たとえば、口座番号が02056439653である場合、検証桁は3に設定されます。
2. ノルウェー政府は次のファクタ表を提供しています。
| 桁 | ファクタ |
|---|---|
|
1桁目 |
5 |
|
2桁目 |
4 |
|
3桁目 |
3 |
|
4桁目 |
2 |
|
5桁目 |
7 |
|
6桁目 |
6 |
|
7桁目 |
5 |
|
8桁目 |
4 |
|
9桁目 |
3 |
|
10桁目 |
2 |
口座番号の最初の10桁に関連ファクタが乗算されます。 各結果を加算して合計が算出されます。
3. 口座番号02056439653を使用した例
各桁に指定のファクタを乗算します。
| 桁 | 値 | ファクタ | 結果 |
|---|---|---|---|
|
1桁目 |
0 |
5 |
0 |
|
2桁目 |
2 |
4 |
8 |
|
3桁目 |
0 |
3 |
0 |
|
4桁目 |
5 |
2 |
10 |
|
5桁目 |
6 |
7 |
42 |
|
6桁目 |
4 |
6 |
24 |
|
7桁目 |
3 |
5 |
15 |
|
8桁目 |
9 |
4 |
36 |
|
9桁目 |
6 |
3 |
18 |
|
10桁目 |
5 |
2 |
10 |
|
合計 |
|
|
163 |
つまり、この例で算出される合計は163となります。
4. 算出合計を検証桁に加算します。 上の例では、163 + 3 = 166となります。
5. 結果を11で除算します。 166 / 11 = 15となります。
6.余りを導出します。 166 - (11 * 15) = 1となります。
7. 余りが0になった場合、検証は成功になり、それ以外の場合、検証は失敗になります。
8. この例では、余りが1になるため、口座番号の検証は失敗になります。 口座番号の11桁目が2 (つまり、検証桁が2)であれば、余りは165 - (11 * 15) = 0になるため、口座番号の検証は成功です。
ここでは、Oracle Fusion Cash Managementで実行される国固有の銀行口座検証ルールの概要について説明します。
次の国には国固有の検証が存在します。
ポーランド
ポルトガル
レユニオン
ルーマニア
サン・バルテルミー島
サン・マルタン島
サンピエール・ミクロン諸島
サウジアラビア
セルビア
セルビア・モンテネグロ
シンガポール
スロバキア
スロベニア
スペイン
スウェーデン
スイス
チュニジア
トルコ
アラブ首長国連邦
イギリス
アメリカ合衆国
銀行口座を入力する際、様々な国に、フォーマットや次の関連フィールドのコンテンツを制御する特定のルールを設定できます。
銀行コード
支店番号
口座番号
検証桁
IBAN
「国固有の銀行検証の使用不可」というプロファイル・オプションが導入されました。 このプロファイルはサイト、製品またはユーザー・レベルで設定できます。 サイト・レベルでは、プロファイルはデフォルト値「いいえ」に事前定義されています。 銀行コード、支店番号、口座番号、検証桁およびIBANに関連する国固有の検証は、このプロファイル・オプションで使用不可に設定できます。 プロファイルが「はい」に設定されている場合、これらの検証は実行されません。 一意の銀行、支店、口座および銀行口座番号の必須要件についてのチェックは、このプロファイルによる影響を受けません。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証桁の検証アルゴリズム
検証桁(CD1)は、銀行コード、支店番号および口座番号の3つの数字を連結することによって構成されます。
たとえば、銀行コードが1234、支店番号が5678、口座番号が12345678901であるとします。 この場合、CD1は1234567812345678901として設定されます。
ポルトガル政府は次のファクタ表を提供しています。
| 桁 | ファクタ |
|---|---|
|
1桁目 |
73 |
|
2桁目 |
17 |
|
3桁目 |
89 |
|
4桁目 |
38 |
|
5桁目 |
62 |
|
6桁目 |
45 |
|
7桁目 |
53 |
|
8桁目 |
15 |
|
9桁目 |
50 |
|
10桁目 |
5 |
|
11桁目 |
49 |
|
12桁目 |
34 |
|
13桁目 |
81 |
|
14桁目 |
76 |
|
15桁目 |
27 |
|
16桁目 |
90 |
|
17桁目 |
9 |
|
18桁目 |
30 |
|
19桁目 |
3 |
作成された検証桁(CD1)の19桁に関連ファクタが乗算されます。 各結果を加算して合計が算出されます。
上のCD1値を使用した例:
| 桁 | 値 | ファクタ | 結果 |
|---|---|---|---|
|
1桁目 |
1 |
73 |
73 |
|
2桁目 |
2 |
17 |
34 |
|
3桁目 |
3 |
89 |
267 |
|
4桁目 |
4 |
38 |
152 |
|
5桁目 |
5 |
62 |
310 |
|
6桁目 |
6 |
45 |
270 |
|
7桁目 |
7 |
53 |
371 |
|
8桁目 |
8 |
15 |
120 |
|
9桁目 |
1 |
50 |
50 |
|
10桁目 |
2 |
5 |
10 |
|
11桁目 |
3 |
49 |
147 |
|
12桁目 |
4 |
34 |
136 |
|
13桁目 |
5 |
81 |
405 |
|
14桁目 |
6 |
76 |
456 |
|
15桁目 |
7 |
27 |
189 |
|
16桁目 |
8 |
90 |
720 |
|
17桁目 |
9 |
9 |
81 |
|
18桁目 |
0 |
30 |
0 |
|
19桁目 |
1 |
3 |
3 |
|
合計 |
|
|
3794 |
結果を97で除算します。 3794 / 97 = 39となります。
余りを導出します。 3794 - (39 * 97) = 11となります。
97から余りを減算してCD1を導出します。 97 - 11 = 86となります。 つまり、この例ではCD1 = 86です。
CD1の計算値とユーザーが入力した検証桁が一致しない場合、検証桁の検証は失敗になります。 この例では、ユーザーが入力した検証桁が86でないかぎり、検証は失敗になります。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証桁の検証アルゴリズム
次の方法により、検証桁CD1が銀行コードと支店番号から、検証桁CD2が口座番号からそれぞれ計算されます。これらが検証桁妥当性テストの基準として使用されます。
CD1
1. 銀行コードに対して、スペイン政府は次のファクタ表を提供しています。
| 桁 | ファクタ |
|---|---|
|
1桁目 |
4 |
|
2桁目 |
8 |
|
3桁目 |
5 |
|
4桁目 |
10 |
銀行コードの4桁に関連ファクタが乗算されます。 各結果を加算して合計が算出されます。
銀行コード1234を使用した例:
各桁に指定のファクタを乗算します。
| 桁 | 値 | ファクタ | 結果 |
|---|---|---|---|
|
1桁目 |
1 |
4 |
4 |
|
2桁目 |
2 |
8 |
16 |
|
3桁目 |
3 |
5 |
15 |
|
4桁目 |
4 |
10 |
40 |
|
合計 |
|
|
75 |
つまり、この例で算出される合計は75となります。
2. 支店番号に対して、スペイン政府は次のファクタ表を提供しています。
| 桁 | ファクタ |
|---|---|
|
1桁目 |
9 |
|
2桁目 |
7 |
|
3桁目 |
3 |
|
4桁目 |
6 |
支店番号の4桁に関連ファクタが乗算されます。 各結果を加算して合計が算出されます。
支店番号5678を使用した例:
各桁に指定のファクタを乗算します。
| 桁 | 値 | ファクタ | 結果 |
|---|---|---|---|
|
1桁目 |
5 |
9 |
45 |
|
2桁目 |
6 |
7 |
42 |
|
3桁目 |
7 |
3 |
21 |
|
4桁目 |
8 |
6 |
48 |
|
合計 |
|
|
156 |
つまり、この例で算出される合計は156となります。
3. 銀行コードと支店番号の両方の計算から算出された合計を加算します。 上の例では、75 + 156 = 231となります。
4. 結果を11で除算します。
231 / 11 = 21
5. 余りを導出します。
231 - (11 * 21) = 0
6. 11から余りを減算してCD1を導出します。 余りが11である場合、CD1は0になり、余りが10である場合、CD1は1になります。ここでは、11 - 0 = 11となります。 つまり、この例ではCD1 = 11 = 0です。
CD2
1. 口座番号に対して、スペイン政府は次のファクタ表を提供しています。
| 桁 | ファクタ |
|---|---|
|
1桁目 |
1 |
|
2桁目 |
2 |
|
3桁目 |
4 |
|
4桁目 |
8 |
|
5桁目 |
5 |
|
6桁目 |
10 |
|
7桁目 |
9 |
|
8桁目 |
7 |
|
9桁目 |
3 |
|
10桁目 |
6 |
口座番号の10桁に関連ファクタが乗算されます。 各結果を加算して合計が算出されます。
口座番号1234567890を使用した例:
各桁に指定のファクタを乗算します。
| 桁 | 値 | ファクタ | 結果 |
|---|---|---|---|
|
1桁目 |
1 |
1 |
1 |
|
2桁目 |
2 |
2 |
4 |
|
3桁目 |
3 |
4 |
12 |
|
4桁目 |
4 |
8 |
32 |
|
5桁目 |
5 |
5 |
25 |
|
6桁目 |
6 |
10 |
60 |
|
7桁目 |
7 |
9 |
63 |
|
8桁目 |
8 |
7 |
56 |
|
9桁目 |
9 |
3 |
27 |
|
10桁目 |
0 |
6 |
0 |
|
合計 |
|
|
280 |
つまり、この例で算出される合計は280となります。
2. 結果を11で除算します。
280 / 11 = 25
3. 余りを導出します。
280 - (11 * 25) = 5
4. 11から余りを減算してCD2を導出します。 11 - 5 = 6となります。 つまり、この例ではCD2 = 6です。
検証桁妥当性テスト
次のチェックにより、ユーザーが入力した検証桁フィールドの値と計算されたCD1およびCD2が比較され、両方のチェックがtrueになった場合、検証は失敗になります。
| チェック | 説明 |
|---|---|
|
1 |
CD1は、入力された検証桁フィールドの1桁目と比較されます。 |
|
2 |
CD2は、入力された検証桁フィールドの2桁目と比較されます。 |
前に計算したCD1およびCD2を使用したテストの例:
CD1 = 0、CD2 = 6であり、ユーザーが入力した検証桁の値が05であるとします。 CD2が一致しないため、検証桁は無効です。
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
口座タイプ |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
口座名義 |
|
|
検証桁 |
|
|
セカンダリ勘定参照 |
|
|
IBAN |
|
検証ルール
次のルールを採用することにより、フィールドの妥当性がチェックされます。
| フィールド | ルール |
|---|---|
|
銀行コード |
|
|
支店番号 |
|
|
口座番号 |
|
|
検証桁 |
|
|
IBAN |
|
ルーティング・トランジット番号の検証アルゴリズム
番号フィールドの9桁目が検証桁として使用されます。
計算検証桁は、モジュラス10アルゴリズムに基づいて残りの8桁から算出されます。
ルーティング・トランジット番号の各桁に重み付けファクタが乗算されます。 各桁の重み付けファクタを次の表に示します。
| 桁 | 1桁目 | 2桁目 | 3桁目 | 4桁目 | 5桁目 | 6桁目 | 7桁目 | 8桁目 |
|---|---|---|---|---|---|---|---|---|
|
ファクタ |
3 |
7 |
1 |
3 |
7 |
1 |
3 |
7 |
ルーティング・トランジット番号の各桁に関連ファクタが乗算されます。 各結果を加算して合計が算出されます。
次に高い10の倍数から合計を減算します。 この結果が計算検証桁です。 これが支店番号またはルーティング・トランジット番号の9桁目と一致する必要があり、一致しない場合、支店番号またはルーティング・トランジット番号は無効です。
例:
| ルーティング番号 | 0 | 7 | 6 | 4 | 0 | 1 | 2 | 5 | 合計 |
|---|---|---|---|---|---|---|---|---|---|
|
乗算 |
3 |
7 |
1 |
3 |
7 |
1 |
3 |
7 |
|
|
合計 |
0 |
49 |
6 |
12 |
0 |
1 |
6 |
35 |
= 109 |
したがって、検証桁 = 1 (110 - 109)です。
この例では、ルーティング・トランジット番号076401251は検証に成功します。
「銀行取引明細書の編集」ページの「ソーシャル」リンクを使用して他者を会話に招待し、差異に対応します。
たとえば、資金マネージャとして、銀行取引明細書の未調整項目をレビューしているものとします。 銀行が使用している換算レートが想定していたものと異なります。 この換算レートについて買掛管理マネージャに確認する必要があります。
「銀行取引明細書の編集」ページで、次の手順を実行します。
「ソーシャル」をクリックしてOracle Social Networkをオープンします。 共有ボタンをクリックするか、またはコラボレーションがすでに開始されている場合は参加をクリックします。
関連する会話を新規に作成します。
会話への参加を買掛管理マネージャに依頼します。
買掛管理マネージャは、銀行が使用している換算レートが本来あるべきものと異なることを確認します。
この情報に基づいて、取引明細書明細および支払を手動で調整できます。 会話はトランザクションの記録となります。
ジョブ・ロールおよび権限に応じて、次のOracle Fusion Cash Management活動に対応するためにソーシャル・ネットワーキング機能を利用できます。
銀行取引明細書
外部資金トランザクション
Oracle Fusion Cash Managementには、次の領域で使用されるレポートが事前に定義されています。
銀行取引明細書
資金移動
一般会計との調整
「スケジュール済プロセス」作業領域
レポートは、ナビゲータのツールにある「スケジュール済プロセス」作業領域からスケジュールして実行できます。
「レポートおよび分析」作業領域
次の方法でレポートを使用する場合もあります。
ナビゲータのツールにある「レポートおよび分析」作業領域またはその他の作業領域からアクセスします。
Oracle Business Intelligence Catalogを起動するリンクを使用してオープンします。
次の表は、事前定義済レポートをタイプ別に示しています。
銀行取引明細書レポート:
| レポート名 | 説明 | パラメータ(*必須) |
|---|---|---|
|
銀行取引明細書レポート |
特定の銀行取引明細書の残高およびトランザクション情報が表示されます。 |
|
|
銀行取引明細書分析レポート |
残高およびトランザクション詳細の分析に使用された銀行取引明細書が表示されます。 |
|
資金移動レポート
| レポート名 | 説明 | パラメータ(*必須) |
|---|---|---|
|
未達現預金レポート |
特定の銀行口座を対象として、銀行に送金されたトランザクションのうちまだ決済されていないものがすべて表示されます。 無効なトランザクションはすべて除外されます。 また、戻し処理日が基準日以前のすべての戻し処理済トランザクションも除外されます。 |
|
現金および一般会計間調整レポート
| レポート名 | 説明 | パラメータ(*必須) |
|---|---|---|
|
現金からの一般会計消込レポート |
差異の原因となっている未調整の銀行取引明細書トランザクションおよび一般会計仕訳が表示されます。 銀行残高と一般会計資金残高の調整に使用されます。 |
|
事前定義済レポートを実行するには、「スケジュール済プロセス」作業領域にナビゲートし、次の手順を実行します。
新規プロセスのスケジュール・ボタンをクリックします。
プロセス名を検索します。
パラメータを入力します。
適切なプロセス・オプションおよびスケジュールを入力します。
「発行」をクリックします。
Cash Managementでリアルタイム分析を作成するには、サブジェクト領域、フォルダおよび属性を理解する必要があります。
分析を作成するには、最初にサブジェクト領域を選択し、その領域から分析対象の情報の列を選択します。 たとえば、銀行取引明細書の残高情報の分析を作成するには、最初にCash Management - 銀行取引明細書残高リアルタイムというサブジェクト領域を選択します。 サブジェクト領域は、ビジネス・オブジェクトやファクトに基づきます。 この例では、サブジェクト領域は銀行取引明細書の残高表の列に基づいています。
Cash Managementには、資金管理に固有の次の4つのサブジェクト領域があります。
Cash Management - 銀行取引明細書残高リアルタイム
Cash Management - 銀行取引明細書明細手数料リアルタイム
Cash Management - 銀行取引明細書リアルタイム
Cash Management - 外部資金トランザクションリアルタイム
各サブジェクト領域は、それぞれ1つのファクト・フォルダと複数のディメンション・フォルダで構成されます。 ファクト・フォルダには、測定可能な属性、つまり残高コードや貸方/借方インジケータなどの数値属性が含まれています。 ファクト・フォルダは通常、フォルダ・リストの下部に表示され、該当するサブジェクト領域にちなんだ名前を持ちます。 ディメンション・フォルダには、入力タイプや法的連番などの属性および階層列が含まれています。
「時間」などの一部のフォルダは複数のサブジェクト領域に存在します。 これらは共通フォルダまたは共通ディメンションと呼ばれます。
サブジェクト領域内の各フォルダの粒度は異なる場合があります。 次に例を示します。
銀行取引明細書残高詳細には各種属性が含まれています。
銀行取引明細書詳細にはサブフォルダが含まれており、そのサブフォルダに属性が含まれています。
最後に、各ディメンション・フォルダには、属性(列)が含まれています。 たとえば、銀行取引明細書残高詳細フォルダには、次の属性が含まれています。
残高コード
残高コード摘要
貸方/借方インジケータ
浮動日数
資金使用可能日