19c

現預金のための売掛/未収金クレジットの実装

目次タイトルおよびコピーライト情報

はじめに

1 共通売掛/未収金構成の定義

Receivablesを操作するための簡単な構成

補助元帳会計の事前定義済売掛/未収金データ

売掛/未収金のノート・マッピング

営業担当の作成

クレジット・メモ要求の手動レビューの構成

共通売掛/未収金構成の定義に関するFAQ

トランザクションを作成できない、または会計を生成できないのはなぜですか。

法的エンティティ文書連番

Receivablesでの法的エンティティの文書連番

自動インボイスによる法的エンティティ文書連番を使用したトランザクションの処理方法

法的エンティティ文書連番に関するFAQ

元帳またはビジネス・ユニット間で文書連番を共有できますか。

売掛/未収金活動

売掛/未収金活動タイプ

GL勘定科目のソース

税率コードのソース

自動消込ルール・セット

各自動消込ルールの使用例

自動消込ルール・セットの使用例

自動消込ルール・セットに関するFAQ

自動消込ルール・セットの選択および使用方法を教えてください。

1

一部入金の使用方法を教えてください。

承認限度

承認限度文書タイプ

承認限度に関するFAQ

承認限度があるユーザーはどのようにして管理できますか。

取引明細書

顧客取引明細書の実装方法

取引明細書送付サイクルの使用方法

取引明細書に関するFAQ

取引明細書サイトを作成するにはどうすればよいですか。

取引明細書での対顧客勘定入金と未消込入金の表示

標準メッセージに関するFAQ

異なる言語でメッセージを記述できますか。

文書にメッセージを追加するにはどうすればよいですか。

配分セットに関するFAQ

配分セットとは何ですか。

2 売掛/未収金システム・オプションの管理

売掛/未収金システム・オプション設定に関するガイドライン

ヘッダー・レベル端数処理の例

税金請求書印刷オプション

自動インボイス調整セグメント

自動インボイスのログ・ファイル・メッセージ・レベル

売掛/未収金システム・オプションの管理に関するFAQ

転記間隔(日数)とは何ですか。

トランザクションの削除を許可するとどうなりますか。

メモリー割当はどのようにして決定できますか。

どのような場合に「入金の自動適用までの日数」を使用しますか。

例外ルール活動とは何ですか。

請求先サイトで入金が必要になるのはいつですか。

実現為替差益勘定および実現為替差損勘定と相互通貨端数処理勘定の違いは何ですか。

Eメール送信

トランザクションおよび取引明細書の送信Eメールの件名の使用例

Eメールを使用したトランザクションおよび取引明細書の送信の仕組み

Eメール送信に関するFAQ

Eメール送信を使用してトランザクションまたは取引明細書を印刷できないのはな

2

ぜですか。

OAGIS 10.1およびUBL 2.1 XML

ReceivablesでのOAGIS 10.1 XMLトランザクション送信の概要

ReceivablesでのUBL 2.1 XMLトランザクション送信

OAGIS 10.1 XMLトランザクション送信のためのReceivablesの設定

OAGIS 10.1 XMLトランザクション送信のためのコラボレーション・メッセージングの設定

顧客インポートFBDIを使用したOAGIS 10.1 XMLトランザクション送信の設定データのインポート

B2B XML

ReceivablesでのB2B XML請求

ReceivablesでのXMLトランザクション

売掛/未収金XMLトランザクションを送信するためのOracle B2Bの設定

B2B XMLに関するFAQ

プロファイル区分でB2B XMLを構成できないのはなぜですか。

詳細な売掛/未収金配分

詳細な売掛/未収金配分の概要

詳細な売掛/未収金配分の有効化に関するガイドライン

詳細な売掛/未収金配分のための補助元帳会計設定

3 顧客請求構成の定義

自動インボイス

自動インボイス・データの準備

自動インボイス・グループ・ルールの例

自動インボイス・グループ・ルールの属性

自動インボイス明細ソート・ルールのトランザクション属性

自動インボイスに関するFAQ

自動インボイスがトランザクションを拒否したのはなぜですか。

自動インボイスが重複するトランザクション番号のトランザクションを作成したのはなぜですか。

自動インボイスでグループ・ルールに定義されていないトランザクション区分を処理するとどうなりますか。

グループ・ルールに明細ソート・ルールが必要になるのはいつですか。

支払条件

支払条件の定義に関するガイドライン

分割支払条件と未払額

支払条件割引基準

3

割引の計算方法

割引額の導出例

支払条件に関するFAQ

繰越残高支払条件と他の支払条件との違いは何ですか。

自動会計

自動会計の勘定科目タイプとセグメント値

自動会計構成の作成に関するガイドライン

自動会計で会計フレックスフィールド・セグメントを導出する例

自動会計に関するFAQ

自動会計で補助元帳会計が作成されるのはいつですか。

トランザクション・タイプ

トランザクション・タイプを使用した転記済活動および非転記済活動のオプション

通常消込および超過消込

トランザクション・タイプ参照勘定に関するガイドライン

トランザクション・タイプに関するFAQ

トランザクション・タイプはどのような順序で作成しますか。

トランザクション・タイプを使用して顧客残高をレビューおよび更新するにはどうすればよいですか。

トランザクション・ソース

トランザクション採番に関するガイドライン

自動インボイスと販売実績情報

自動インボイスによるインポート済トランザクションの検証方法

CPQ CloudおよびReceivablesの処理の実装方法

トランザクション・ソースに関するFAQ

トランザクション・ソースを作成する前に作成するものは何ですか。

トランザクション・ソースを使用してクレジット・メモを管理するにはどうすればよいですか。

自動インボイス・グループ・ルールを入力しないとどうなりますか。

決済勘定を作成しないとどうなりますか。

メモ明細

収益勘定とメモ明細

メモ明細に関するFAQ

メモ明細はいつ使用しますか。

税金メモ明細を使用するにはどうすればよいですか。

繰越残高請求

4

顧客アカウントおよびサイトの繰越残高請求

繰越残高請求の設定の例

繰越残高請求のEメール送信

繰越残高請求書のEメール送信

繰越残高請求書のEメール送信の設定方法

繰越残高請求に関するFAQ

繰越残高請求サイクルとはなんですか。

営業担当参照勘定に関するFAQ

営業担当参照勘定とは何ですか。

送金先住所に関するFAQ

送金先住所を使用する方法

自動インボイスが送金先住所を検証する方法

デフォルトの送金先住所を定義する方法

国が表示された理由

住所を確認する理由

4 顧客支払の定義

Receivablesでの共有サービス・モデルの作成

消込ルール・セット

消込ルール・セットのルール

消込ルールの使用例

残高に混合符号を使用するトランザクションでの消込ルールの使用例

消込ルール・セットに関するFAQ

税処置とは何ですか。

端数処理訂正を使用するにはどうすればよいですか。

入金区分および入金方法

送金方法と決済方法

自動入金方法の定義に関するガイドライン

自動入金に対する資金振替エラー処理

入金方法に対する送金銀行口座

入金区分および入金方法に関するFAQ

入金区分にはどのような作成方法が必要ですか。

入金区分と入金方法にはどのような関係がありますか。

入金に割り当てられるのはどのような法的エンティティですか。

ロックボックス

ロックボックス・インタフェース表AR_PAYMENTS_INTERFACE_ALL

5

入金別照合ルールを使用した入金消込

ロックボックスに関するFAQ

ロックボックスに入金ソースが見つからないのはなぜですか。

ロックボックスのバッチ・サイズを計算するにはどうすればよいですか。

会計日ソースを使用するにはどうすればよいですか。

自動適用では無効なトランザクション番号はどのように管理されますか。

ロックボックスの伝送フォーマット

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

ロックボックス伝送フォーマット

ロックボックス伝送レコード・タイプ

ロックボックス伝送フォーマット・フィールド・タイプ

ロックボックスの伝送フォーマットに関するFAQ

伝送金額を再フォーマットできますか。

オーバーフロー・レコードとは何ですか。

自動照合ルール・セット

自動照合の勧告の計算方法

自動照合の結合加重しきい

自動照合の金額加重例外

自動照合の文字列処理の仕組み

消込例外ルール・セット

消込例外ルールの条件と処理

消込例外ルール・セットに関するFAQ

消込例外ルール・セットはいつ使用しますか。

自動照合ルール・セットと消込例外ルール・セットの違いは何ですか。

顧客支払関係

顧客階層と支払関係

顧客支払関係に関するFAQ

アカウント関連と支払関連の違いは何ですか。

顧客階層タイプが非アクティブ化されるとどうなりますか。

入金ソースに関するFAQ

自動バッチ採番はどのように機能しますか。

入金ソースはどこで使用されますか。

5 支払システムとの接続の構成

検証のオプション

フォーマットの設定方法

6

伝送プロトコル

伝送構成

伝送構成の設定方法

アウトバウンド・メッセージとインバウンド・メッセージのPretty Good Privacy (PGP)暗号化およびデジタル署名の構成方法

伝送構成のテスト方法

支払システムへの通信チャネルの構成方法

支払システムの設定方法

支払システム・アカウント

複数のビジネス・ユニットの支払システム接続の設定: 説明

トークン化設定データのインポートとエクスポート

セキュリティ資格証明ファイルのインポート

支払システムとの接続の構成に関するFAQ

フォーマット・タイプとは何ですか。

複数のビジネス・ユニットの支払システム接続を設定できますか。

6 資金取得の定義

資金取得プロセス・プロファイル

決済グループ化ルールの例

ルーティング・ルール

Oracle BI Publisher Enterpriseを使用して、フォーマットで使用するためのテンプレートを変更する方法

資金取得の定義に関するFAQ

支払コードとは何ですか。

銀行指図コードとは何ですか。

決済チャネル・コードとは何ですか。

支払事由コードとは何ですか。

オンライン検証とは何ですか。

7 支払セキュリティの定義

システム・セキュリティ・オプション: 重要な選択

機密支払情報の暗号化の有効化

クレジット・カード・トークン化を有効にする方法

インポートされたレガシー・クレジット・カードの処理方法

個人を識別可能な情報の削除

8 顧客の定義

顧客アカウントの定義

7

顧客アカウント関係

顧客アカウント情報

顧客住所のガイドライン

追加の顧客サイトの表示方法

売掛/未収金顧客プロファイル区分の管理

顧客プロファイル区分の使用方法

プロファイル区分の更新方法およびバージョン管理方法

与信チェックの顧客プロファイルの設定方法

売掛/未収金顧客プロファイル区分の管理に関するFAQ

プロファイル区分のデフォルトはいつ使用されますか。

顧客の管理

顧客とパーティ体系

パーティ関係の使用方法

顧客税金プロファイルの使用方法

顧客のマージ方法

顧客の管理に関するFAQ

新しい顧客は顧客アカウントに属していますか。

すでに存在する顧客情報を入力するとどうなりますか。

他の顧客情報を更新するにはどうすればよいですか。

顧客データ・アップロードの管理

顧客データのインポート方法

スプレッドシートを使用した顧客データのアップロードのガイドライン

顧客スプレッドシート・アップロード・データの検証の例

顧客リスト・レポート

レガシー顧客クレジット・カード・データのインポート

顧客データ・アップロードの管理に関するFAQ

顧客スプレッドシートをアップロードできないのはなぜですか。

顧客アップロード・バッチにエラーがあるのはなぜですか。

データ・インポートの管理

顧客およびコンシューマのデータ・インポート

顧客およびコンシューマのデータ・インポート・バッチの例

リソースおよびパートナのデータ・インポート

リソースおよびパートナのデータ・インポート・バッチの例

データ・インポート・バッチでのWhat-If分析の例

データ品質サービスとデータ・インポート

8

データ・インポートの管理に関するFAQ

インポート・プロセスの詳細を表示できないのはなぜですか。

バッチを再度インポートできますか。

すでにインポート済のバッチのデータ・インポート・プロセスを再定義して再インポートできますか。

インポート前処理時に発生したエラーを表示するにはどうすればよいですか。

データ・インポート・バッチをパージするとどうなりますか。

データ・インポート・バッチをパージできないのはなぜですか。

9 受取手形の定義

受取手形に関するシステム・オプションの有効化

受取手形作成入金方法の作成

受取手形バッチのトランザクションの準備

受取手形送金入金方法の作成

受取手形の送金銀行口座の作成

受取手形の定義に関するFAQ

顧客名宛人を作成するにはどうすればよいですか。

署名済受取手形と未署名受取手形の違いはなんですか。

名宛人によって受取手形が発行されるのはどのような場合ですか。

受取手形の延滞手数料を提示するにはどうすればよいですか。

10 売掛/未収金の収益管理構成の定義

収益ポリシーの定義に関するガイドライン

イベントベースの収益管理の仕組み

偶発収益

支払ベースの偶発収益

偶発収益削除イベント

偶発収益割当ルール

売掛/未収金の収益管理構成の定義に関するFAQ

偶発収益とは何ですか。

どのような場合に偶発を含む収益ポリシーを使用しますか。

どのような場合に偶発収益割当ルールを作成しますか。

11 与信管理の定義

与信プロファイルのコンポーネント

与信アナリストと与信マネージャ

スコアリング・モデルの作成

スコアリング・モデル計算の定義方法

9

クレジット事例フォルダ・テンプレートの作成

データ・ポイントの要約表の保守方法

データ・ポイントのサード・パーティ与信データのインポート方法

与信管理データ・ポイントのインポート方法

クレジット事例フォルダの付加フレックスフィールド

与信管理の定義に関するFAQ

信用評価と与信分類の違いは何ですか。

与信通貨が定義されていないとどうなりますか。

スコアリング・モデルを編集または削除できないのはなぜですか。

スコアリング・モデルにデータ・ポイントを追加できないのはなぜですか。

NULLデータ・ポイント値とゼロ・データ・ポイント値の違いは何ですか。

与信通貨とスコアリング・モデル通貨の違いは何ですか。

事例フォルダ・テンプレートにスコアリング・モデルを追加するのはなぜですか。

デフォルトの事例フォルダ・テンプレートを割り当てるにはどうすればよいですか。

事例フォルダ・テンプレートを編集できますか。

12 資金管理および銀行取引構成の定義

銀行、支店および口座コンポーネントの連携の仕組み

口座の作成時の考慮事項

資金管理プロファイル・オプション

解析ルール・セットの概要

トランザクション・タイプ・マッピングの概要

許容範囲ルールの概要

突合せ照合ルール

突合せルール・セットの概要

銀行取引明細書トランザクション・コードの概要

構成可能なBAI2トランザクション・コードのマッピング方法

銀行取引明細書トランザクション作成ルールの概要

スプレッドシートでの銀行、支店および口座の作成

資金管理の高速実装の概要

資金ポジションおよび資金予測の設定

資金管理向けにOracle Fusion Paymentsを設定する方法

資金ポジションおよび資金予測の設定方法

銀行口座検証

国別の銀行口座検証: アルバニアからグアテマラまで

国別の銀行口座検証: ハンガリーからノルウェーまで

10

国別の銀行口座検証: パキスタンからアメリカ合衆国まで

13 Advanced Collections構成の定義

回収プリファレンスの管理

回収プリファレンスの設定に関するガイドライン

回収プリファレンスの定義

回収プリファレンスの管理に関するFAQ

「グローバル・プリファレンス」と「プリファレンス」の違いは何ですか。

ビジネス・レベルにおける顧客、アカウントおよびサイトの間の違いは何ですか。

最小督促金額と最小督促請求書金額の違いは何ですか。

年齢調べ方法の管理

年齢調べ方法

年齢調べ方法の作成

年齢調べ方法の管理に関するFAQ

事前定義の年齢調べ方法を変更するにはどうすればよいですか。

回収担当の管理

回収担当の設定に関するガイドライン

回収担当の作成

回収担当付加フレックスフィールドの概要

回収担当付加フレックスフィールドの設定

回収担当の管理に関するFAQ

従業員割当とグループ割当の違いは何ですか。

督促構成の管理

年齢調べ済督促と段階的督促

顧客督促の構成オプション

督促構成のインストール後

督促構成の管理に関するFAQ

年齢調べ済督促方法と段階的督促方法の違いは何ですか。

スコアリングの定義

スコアリング算式

スコアリング算式の作成

スコアリング算式の編集

スコアリング算式のデータ・ポイント

スコアリング・データ・ポイントの作成

スコアリングの定義に関するFAQ

11

スコアリング算式ステータスとは何ですか。

スコアリング算式セグメントとは何ですか。

戦略の定義

戦略の処理

回収戦略

回収戦略の作成

タスクの作成

「個別トランザクションの回収戦略」の有効化

回収スコアリングおよび戦略割当の管理

セグメントによるスコアリングおよび戦略割当

セグメントによるスコアリング算式および延滞戦略割当の定義

セグメントによる事前遅延戦略割当の定義

14 請求管理の定義

請求管理の設定

用語集

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

12

19c

現預金のための売掛/未収金クレジットの実装

Oracle Financials Cloud 現預金のための売掛/未収金クレジットの実装19C部品番号F23165-01Copyright c 2011, 2019, Oracle and/or its affiliates.All rights reserved.

原本著者: Robert MacIsaac、Wallace Gardipe、Carol Ann Lapeyrouse、Sampriti Singharoy、Reshma Shaik、NainiKhajanchi、Vineeta Kumar

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS:Oracle programs, including any operating system, integrated software, anyprograms installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercialcomputer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplementalregulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operatingsystem, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to licenseterms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

13

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMDOpteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracleCorporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

このドキュメントで使用されている事業所名は架空のものであり、現在または過去に実在する実際の会社を特定するためのものではありません。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

14

19c

現預金のための売掛/未収金クレジットの実装

はじめにここでは、アプリケーションを使用する際に役立つ情報ソースについて説明します。

Oracle Applicationsの使用Applicationsヘルプの使用方法ヘルプにアクセスするには、アプリケーション内でヘルプ・アイコン を使用します。ページにヘルプ・アイコンが表示されていない場合は、グローバル・ヘッダーで自分のユーザー・イメージまたはユーザー名をクリックし、「ヘルプの表示」アイコンを選択します。ヘルプ・アイコンがないページもあります。Oracle Applicationsヘルプにアクセスすることもできます。

視聴: このビデオ・チュートリアルでは、ヘルプの検索方法およびヘルプ機能の使用方法を示します。

Applicationsヘルプの使用を参照することもできます。

その他のリソースコミュニティ: Oracleのエキスパート、パートナ・コミュニティおよびその他のユーザーから情報を入手するには、Oracle Cloud Customer Connectを使用します。ガイドおよびビデオ: Oracle Help Centerにアクセスしてガイドおよびビデオを参照できます。トレーニング: Oracle Universityで提供されるOracle Cloudのコースを受けることができます。

表記規則

15

このガイドで使用されるテキスト表記規則を次の表に示します。

規則 意味

太字 太字は、ユーザー・インタフェース要素、ナビゲータ・パス、または入力する値や選択する値を示します。

固定幅フォント

固定幅フォントは、ファイル名、フォルダ名、ディレクトリ名、コードの例、コマンドおよびURLを示します。

→ 右矢印記号は、ナビゲータ・パスの要素を区切ります。

ドキュメントのアクセシビリティについてオラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトを参照してください。

このガイドに含まれるビデオは、このガイドで使用可能なテキストベースのヘルプ・トピックの代替メディアとして提供するものです。

オラクル社へのお問合せOracle Supportへのアクセスサポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はMy Oracle Supportにアクセスするか、聴覚に障害のあるお客様はアクセス可能なOracleサポートにアクセスしてください。

ご意見およびご提案Oracle Applicationsヘルプやガイドに関するフィードバックをお寄せください。電子メールの送付先:oracle_fusion_applications_help_ww_grp@oracle.com。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

16

19c

現預金のための売掛/未収金クレジットの実装

1 共通売掛/未収金構成の定義この章の内容は次のとおりです。

Receivablesを操作するための簡単な構成補助元帳会計の事前定義済売掛/未収金データ売掛/未収金のノート・マッピング営業担当の作成クレジット・メモ要求の手動レビューの構成共通売掛/未収金構成の定義に関するFAQ法的エンティティ文書連番売掛/未収金活動自動消込ルール・セット承認限度取引明細書標準メッセージに関するFAQ配分セットに関するFAQ

Receivablesを操作するための簡単な構成Receivablesの操作環境は7つの構成により作成できます。残りの構成はオプションであるか、事前定義値があります。

該当する場合は、レガシー・システムから顧客情報を移行するためのプランをReceivables構成に含める必要があります。

Receivables構成タスク

17

Receivablesの操作環境を作成するために必要な7つの構成タスクがあります。これらのタスクを実行する前に、Oracle Financialsに必要なすべての実装タスクが完了していることを確認する必要があります。

次の7つのタスクを示されている順序で実行します。

1. 売掛/未収金システム・オプションの設定売掛/未収金システム・オプションを設定して、Receivables環境を定義します。Receivablesの設定中に、勘定科目、顧客および請求書のパラメータ、自動インボイスおよび自動入金プログラムの動作を指定します。

2. 売掛/未収金活動の定義売掛/未収金活動を定義して、その他現金、割引、延滞手数料、修正、消込など、トランザクションと入金以外のすべての活動のデフォルト会計を作成します。

3. 自動会計ルールの定義自動会計の定義は、顧客請求を処理するために必要な構成タスクです。自動会計を定義して、ReceivablesでトランザクションのデフォルトGL勘定科目を決定する方法を指定します。Receivablesでは、自動会計の設定を使用して、収益、売掛金、運送費、税金、前受収益、未請求売掛金、延滞手数料および自動インボイス決済(仮勘定)勘定科目のデフォルト勘定科目を作成します。

4. 入金区分および入金方法の定義入金区分および入金方法の定義は、顧客支払を処理するために必要な構成タスクです。入金区分によって、この区分で入金方法を割り当てる入金に必要な処理ステップが決まります。これらのステップには、確認、送金および決済が含まれます。入金方法では、入金エントリおよび消込の会計を指定し、顧客送金銀行情報を決定し、自動入金処理および資金振替エラー処理を構成します。

5. 送金先住所の定義未回収売掛/未収金の支払の送信先を顧客に知らせるための送金先住所を定義します。Receivablesでは、トランザクション入力時に、この住所を使用してデフォルト送金先情報が提供されます。トランザクションを完了するには、送金先住所を指定する必要があります。自動インボイスを使用しますが、特定の顧客サイトについて送金先住所を定義していない場合、自動インボイスでは、送金先住所を決定できなかったすべてのトランザクションが拒否されます。

6. 承認限度の定義承認限度を定義して、Receivablesユーザーが修正またはクレジット・メモ要求を承認できるかどうかを決定します。承認限度は、文書タイプ、金額および通貨別に定義します。

7. 取引明細書送付サイクルの定義顧客取引明細書を作成するタイミングを制御する取引明細書送付サイクルを定義します。取引明細書送付サイクルは顧客プロファイルに割り当てます。

関連トピック

送金先住所を使用する方法自動会計の勘定科目タイプとセグメント値売掛/未収金システム・オプション設定に関するガイドライン

補助元帳会計の事前定義済売掛/未収金データ18

Oracle ReceivablesによってOracle Subledger Accountingの事前定義済データが提供され、このデータを使用して2つのアプリケーションを統合できます。

「売掛/未収金会計の作成」を実行すると、プログラムは自動会計からデフォルト会計情報を変更なしで受け入れ、事前定義済データを使用して補助元帳に会計を作成します。補助元帳会計によって確定会計が一般会計に転送されます。

注意: オプションで独自の補助元帳会計基準を定義して、会計イベントのデフォルト勘定科目を上書きできます。

Receivablesでは、補助元帳会計において売掛/未収金という名前の1つのアプリケーションが事前定義されます。補助元帳会計に対してReceivablesで事前定義されるほとんどのデータは、売掛/未収金アプリケーションに関連付けられます。

この表は、Receivablesで売掛/未収金アプリケーションに対して事前定義される属性値を示しています。

フィールド 値

アプリケーション名 売掛/未収金

ドリルダウン・プロシージャ AR_DRILLDOWN_PUB_PKG.DRILLDOWN

セキュリティの使用 はい

ポリシー関数 XLA_SECURITY_POLICY_PKG.MO_POLICY

仕訳ソース 売掛/未収金

サード・パーティ管理勘定科目タイプ 顧客

検証対象 いいえ

レポート通貨金額の計算 はい

この表は、Receivablesでイベント・エンティティに対して事前定義される設定情報を示しています。

アプリケーション エンティティ名 説明 欠番なしイベント処理

売掛/未収金 修正 修正 いいえ

売掛/未収金 入金 入金 いいえ

売掛/未収金 トランザクション トランザクション いいえ

売掛/未収金アプリケーションに対して、プロセス・カテゴリが事前定義されます。これらのプロセス・カテゴリは次のとおりです。

修正その他入金標準入金サード・パーティ・マージトランザクション

19

補助元帳会計用のReceivablesの事前定義済データに関する追加の考慮事項は、次のとおりです。

イベント区分およびイベント区分オプションソース、ソース割当および会計属性割当仕訳明細ルール勘定科目ルール仕訳ルール・セット会計処理基準

イベント区分およびイベント区分オプションReceivablesでは、売掛/未収金アプリケーションに属する各イベント・エンティティに対して、イベント区分が事前定義されます。

この表は、Receivablesで売掛/未収金アプリケーションに対して事前定義されるイベント区分を示しています。

エンティティ イベント区分名

修正 修正

入金 その他入金

入金 入金

トランザクション チャージバック

トランザクション クレジット・メモ

トランザクション デビット・メモ

トランザクション 請求書

会計イベント区分オプションでは、イベント区分の属性を定義します。Receivablesでは、各事前定義イベント区分に対して会計イベント区分オプションが定義されます。

この表は、Receivablesで売掛/未収金アプリケーションに対して事前定義される会計イベント区分オプションを示しています。

イベント区分 プロセス・カテゴリ デフォルト仕訳カテゴリ トランザクション・ビュー 残高タイプ

修正 修正 修正 AR_ADJ_INF_V 実績

その他入金 その他入金 その他入金 AR_CR_INF_V 実績

入金 標準入金 入金 AR_CR_INF_V 実績

チャージバック トランザクション チャージバック AR_TRX_INF_V 実績

クレジット・メモ トランザクション クレジット・メモ AR_TRX_INF_V 実績

デビット・メモ トランザクション デビット・メモ AR_TRX_INF_V 実績

請求書 トランザクション 売上請求書 AR_TRX_INF_V 実績

20

ソース、ソース割当および会計属性割当Receivablesでは、補助元帳会計のソース、ソース割当および会計属性割当が事前定義されます。

事前定義済のソース、ソース割当または会計属性割当を変更することはできません。ただし、独自のソースを定義できます。

独自の仕訳明細ルールまたは会計処理基準を定義する場合、デフォルト会計属性割当を上書きできます。

仕訳明細ルールReceivablesでは、各事前定義済イベント区分に対して仕訳明細ルールが事前定義されます。Receivablesでは、各仕訳明細ルールの使用条件を指定します。

この表は、Receivablesで売掛/未収金アプリケーションに対して事前定義される仕訳明細ルールを示しています。

イベント区分 名前 残高タイプ サイド

修正 修正 実績 貸方

修正 修正手数料 実績 貸方

修正 修正デフォルト売掛/未収金 実績 貸方

修正 修正繰延税 実績 貸方

修正 修正手数料控除対象外税 実績 貸方

修正 修正控除対象外税金 実績 貸方

修正 修正税 実績 貸方

チャージバック チャージバック・デフォルト売掛/未収金 実績 借方

チャージバック チャージバック収益 実績 貸方

クレジット・メモ クレジット・メモ・デフォルト繰延税消込 実績 貸方

クレジット・メモ クレジット・メモ・デフォルト消込 実績 貸方

クレジット・メモ クレジット・メモ・デフォルト税金消込 実績 貸方

クレジット・メモ クレジット・メモ払戻消込 実績 貸方

クレジット・メモ クレジット・メモ手数料 実績 貸方

クレジット・メモ クレジット・メモ・デフォルト売掛/未収金 実績 借方

クレジット・メモ クレジット・メモ・デフォルト収益 実績 貸方

クレジット・メモ クレジット・メモ・デフォルト税金 実績 貸方

クレジット・メモ クレジット・メモ端数処理 実績 貸方

21

クレジット・メモ クレジット・メモ未請求売掛金 実績 貸方

クレジット・メモ クレジット・メモ繰越収益 実績 貸方

デビット・メモ デビット・メモ手数料 実績 貸方

デビット・メモ デビット・メモ・デフォルト売掛/未収金 実績 借方

デビット・メモ デビット・メモ運送費 実績 貸方

デビット・メモ デビット・メモ収益 実績 貸方

デビット・メモ デビット・メモ端数処理 実績 貸方

デビット・メモ デビット・メモ税金 実績 貸方

デビット・メモ デビット・メモ未請求売掛金 実績 借方

デビット・メモ デビット・メモ繰越収益 実績 貸方

請求書 請求書手数料 実績 貸方

請求書 請求書デフォルト売掛/未収金 実績 借方

請求書 請求書運送費 実績 貸方

請求書 請求書収益 実績 貸方

請求書 請求書端数処理 実績 貸方

請求書 請求書税金 実績 貸方

請求書 請求書未請求売掛金 実績 貸方

請求書 請求書繰越収益 実績 貸方

その他入金 その他入金銀行手数料 実績 貸方

その他入金 その他入金決済済現預金 実績 貸方

その他入金 その他入金確認済現預金 実績 貸方

その他入金 その他入金短期借入金 実績 貸方

その他入金 その他入金ファクタリング現金 実績 貸方

その他入金 その他入金その他現金 実績 貸方

その他入金 その他入金送金済現預金 実績 貸方

その他入金 その他入金税 実績 貸方

入金 入金対顧客勘定消込 実績 貸方

入金 運送費に対する入金消込 実績 貸方

入金 収益に対する入金消込 実績 貸方

入金 端数処理に対する入金消込 実績 貸方

22

入金 仮勘定収益に対する入金消込 実績 貸方

入金 税金に対する入金消込 実績 貸方

入金 未請求収益に対する入金消込 実績 貸方

入金 実現収益に対する入金消込 実績 貸方

入金 入金銀行手数料 実績 貸方

入金 入金決済済現金 実績 貸方

入金 入金クレジット・カード・チャージバック消込 実績 貸方

入金 入金チャージバック消込 実績 貸方

入金 入金確認済現金 実績 貸方

入金 入金通貨端数処理 実績 貸方

入金 入金短期借入金 実績 貸方

入金 入金デフォルト消込 実績 貸方

入金 入金繰延税 実績 貸方

入金 入金期限内割引 実績 貸方

入金 運送費での入金期限内割引 実績 借方

入金 入金期限内割引控除対象外税金 実績 貸方

入金 収益での入金期限内割引 実績 借方

入金 税金での入金期限内割引 実績 借方

入金 入金為替差益 実績 貸方

入金 入金為替損益 実績 損益

入金 入金為替差損 実績 貸方

入金 入金ファクタリング現金 実績 貸方

入金 入金支払ネッティング消込 実績 貸方

入金 入金前払金消込 実績 貸方

入金 入金払戻消込 実績 貸方

入金 入金送金済現金 実績 貸方

入金 入金税 実績 貸方

入金 入金未消込入金 実績 借方

入金 未消込入金 実績 借方

入金 入金損益明細の未消込 実績 借方

23

入金 入金期限外割引 実績 貸方

入金 運送費での入金期限外割引 実績 借方

入金 控除対象外税金での入金期限外割引 実績 貸方

入金 収益での入金期限外割引 実績 借方

入金 税金での入金期限外割引 実績 借方

入金 入金不明入金 実績 貸方

入金 入金消込の消込 実績 貸方

入金 戻し処理済入金不明入金の未消込 実績 借方

入金 戻し処理済入金不明残高明細 実績 借方

入金 入金不明入金の未消込 実績 借方

入金 入金不明残高明細 実績 借方

入金 未消込戻し処理済入金 実績 借方

勘定科目ルールReceivablesでは勘定科目ルールが事前定義されます。補助元帳会計では、Receivablesによって提供された事前定義済の勘定科目ルールを使用する場合、Receivablesで自動会計を使用して生成されるデフォルト会計が変更なしで受け入れられます。

オプションで、会計フレックスフィールドまたはセグメントに対して独自の勘定科目ルールを定義できます。この場合、補助元帳会計は、ドラフトまたは確定補助元帳会計の作成時に、Receivablesで生成されたデフォルト勘定科目、またはデフォルト勘定科目の個別のセグメント値を上書きします。

売掛/未収金アプリケーションに対して事前定義される勘定科目ルールは、次のとおりです。

クレジット・メモ配分GL勘定科目回収銀行手数料勘定回収銀行口座現預金勘定回収銀行ファクタリング手数料勘定配分GL勘定科目送金銀行未消込勘定システムによるGL勘定科目取得システム損失GL勘定科目トランザクション配分GL勘定科目参照付きトランザクション配分GL勘定科目

仕訳ルール・セットReceivablesでは、対応する事前定義済イベント・タイプ内で、事前定義済の仕訳明細ルールおよび勘定科目ルールをグループ化する仕訳ルール・セットが事前定義されます。Receivablesでは、各事前定義済仕訳ルー

24

ル・セットがイベント区分内のすべてのイベント・タイプに割り当てられます。

この表は、Receivablesで売掛/未収金アプリケーションに対して事前定義される仕訳ルール・セットを示しています。

イベント区分

仕訳ルール・セット名 仕訳明細ルール

修正 修正 -デフォルト発生主義

修正、修正手数料、修正手数料控除対象外税金、修正デフォルト売掛/未収金、修正繰延税、修正控除対象外税金、修正税

チャージバック

チャージバック - デフォルト発生主義

チャージバック・デフォルト売掛/未収金、チャージバック収益

クレジット・メモ

クレジット・メモ - デフォルト発生主義

クレジット・メモ手数料、クレジット・メモ・デフォルト消込、クレジット・メモ・デフォルト繰延税消込、クレジット・メモ・デフォルト売掛/未収金、クレジット・メモ・デフォルト収益、クレジット・メモ・デフォルト税金、クレジット・メモ・デフォルト税金消込、クレジット・メモ繰越収益、クレジット・メモ払戻消込、クレジット・メモ端数処理、クレジット・メモ未請求売掛金

デビット・メモ

デビット・メモ - デフォルト発生主義

デビット・メモ手数料、デビット・メモ・デフォルト売掛/未収金、デビット・メモ繰越収益、デビット・メモ運送費、デビット・メモ収益、デビット・メモ端数処理、デビット・メモ税金、デビット・メモ未請求売掛金

請求書 請求書- デフォルト発生主義

請求書手数料、請求書デフォルト売掛/未収金、請求書繰越収益、請求書運送費、請求書収益、請求書端数処理、請求書税金、請求書未請求売掛金

その他入金

その他入金

その他入金銀行手数料、その他入金決済済現金、その他入金確認済現金、その他入金ファクタリング現金、その他入金その他現金、その他入金送金済現金、その他入金短期借入金、その他入金税

入金 入金 -デフォルト発生主義

入金銀行手数料、入金チャージバック消込、入金決済済現金、入金確認済現金、入金クレジット・カード・チャージバック消込、入金通貨端数処理、入金デフォルト消込、入金繰延税、入金期限内割引、入金期限内割引控除対象外税金、入金為替損益、入金ファクタリング現金、入金対顧客勘定消込、入金支払ネッティング消込、入金前払金消込、入金払戻消込、入金送金済現金、入金短期借入金、入金税、入金未消込入金、入金期限外割引、控除対象外税金での入金期限外割引、入金不明入金、入金消込の消込、未消込入金

入金 入金 -基準仕訳ルール・セット

実現収益に対する入金消込、運送費に対する入金消込、収益に対する入金消込、端数処理に対する入金消込、仮勘定収益に対する入金消込、税金に対する入金消込、未請求収益に対する入金消込入金銀行手数料、入金決済済現金、入金確認済現金、入金通貨端数処理、入金期限内割引、運送費での入金期限内割引、収益での入金期限内割引、税金での入金期限内割引、入金為替損益、入金ファクタリング現金、入金対顧客勘定消込、入金支払ネッティング消込、入金前払金消込、入金払戻消込、入金送金済現金、入金短期借入金、入金未消込入

25

金、入金損益明細の未消込、入金期限外割引、運送費での入金期限外割引、収益での入金期限外割引、税金での入金期限外割引、入金不明入金、入金消込の消込、未消込入金

会計処理基準Receivablesでは、「売掛/未収金デフォルト発生主義」会計処理基準が事前定義されます。

この表は、Receivablesで売掛/未収金アプリケーションに対して事前定義される「売掛/未収金デフォルト発生主義」会計処理基準の割当を示しています。

イベント区分割当 イベント・タイプ割当 会計の作成 仕訳ルール・セット割当

修正 すべて はい 修正 - デフォルト発生主義

チャージバック すべて はい チャージバック - デフォルト発生主義

クレジット・メモ すべて はい クレジット・メモ - デフォルト発生主義

デビット・メモ すべて はい デビット・メモ - デフォルト発生主義

請求書 すべて はい 請求書 - デフォルト発生主義

その他入金 すべて はい その他入金

入金 すべて はい 入金 - デフォルト発生主義

注意: 補助元帳会計には、補助元帳アプリケーション用に事前定義された会計処理基準をグループ化する事前定義済の補助元帳会計処理基準が用意されています。オプションで、独自の補助元帳会計処理基準を作成できます。

Receivablesでは、事前定義済の「売掛/未収金デフォルト発生主義」会計処理基準が事前定義済の「補助元帳会計処理基準」会計処理基準に割り当てられます。この補助元帳会計処理基準を元帳に割り当てることができます。

売掛/未収金のノート・マッピングノート共通コンポーネント・ポートレットは、すべての売掛/未収金トランザクション・ページで使用できます。トランザクション・サイクル全体(未完了、完了、転記済)を通してトランザクションでノートを作成、表示、更新および削除できます。

ノートには、内部と非公開の2つのタイプがあります。内部ノートはすべてのユーザーが使用できます。非公開ノートは作成者のみが使用できます。

売掛/未収金トランザクションでノート・ポートレットを使用するために実行する構成タスクは3つあります。

ノート・マッピング構成タスク

26

売掛/未収金へのノートのマッピングには、3つの構成タスクがあります。

次のタスクを示されている順序で実行します。

1. 売掛/未収金ノート・タイプの管理ノート・タイプに必要な参照を定義します。

2. 売掛/未収金ノート・タイプ・マッピングの管理CRMコンポーネントを使用して、ノート・タイプを売掛/未収金トランザクション・オブジェクト(AR_TRANSACTIONS)にマップします。この表は、売掛/未収金の事前定義済ノート・タイプ・マッピングを示しています。

OBJECT_CODE MAPPING_TYPE_CODE MAPPED_LOOKUP_CODE 意味 説明

AR_TRANSACTION ZMM_NOTE_TYPE MAINTAIN (デフォルト) 保守 売掛/未収金トランザクションの保守

AR_TRANSACTION ZMM_NOTE_TYPE AR_APPROVAL 売掛/未収金クレジット・メモ要求承認

売掛/未収金クレジット・メモ要求承認ノート・タイプ

3. 売掛/未収金ノート付加フレックスフィールドの管理オプションで、ノートの付加フレックスフィールドを定義できます。売掛/未収金トランザクションでノート付加フレックスフィールドを使用して、ビジネス要件の追加情報を取得できます。

営業担当の作成トランザクションおよび販売実績割当の営業担当を作成します。

Receivablesでは、デフォルトの営業担当「販売実績なし」が提供されます。売掛/未収金システム・オプション「営業担当必須」が有効になっていて、営業担当が定義されていない場合、すべてのトランザクションでデフォルトで「販売実績なし」が移入されます。自動会計が営業担当に依存する場合、収益、運送費および売掛/未収金の総勘定元帳参照勘定を「販売実績なし」に割り当てる必要があります。これらの勘定科目は、デビット・メモ戻し処理を作成する場合や、販売実績がないトランザクションを入力する場合に必要です。

営業担当を作成するには、次のタスクを実行します。

営業担当としてのユーザーの作成ユーザーへのリソースの割当売掛/未収金営業担当参照勘定の定義

営業担当としてのユーザーの作成新規ユーザーを作成するか、既存のユーザーを営業担当として更新できます。

新規ユーザーを営業担当として作成する手順は、次のとおりです。

27

1. 「ユーザーの作成」ページにナビゲートします。2. ユーザーの個人詳細を入力します。3. 「雇用情報」セクションで、「個人タイプ」フィールドの「従業員」を選択します。4. 「リソース情報」セクションで、「リソース・ロール」フィールドの「営業担当」を選択します。5. 要件に応じて残りのページに入力し、保存します。

ユーザーへのリソースの割当作成したユーザーに営業担当ロールと参照セットを割り当てます。

営業担当ユーザーにリソースを割り当てる手順は、次のとおりです。

1. 「リソースの管理」ページにナビゲートします。2. ユーザーを検索して選択します。3. 表示される「リソース」ページで、「ロール」タブにナビゲートします。4. 「ロール名」フィールドで、ユーザーに「営業担当」または「営業マネージャ」のロールを割り当てます。

5. 必要に応じて、「日付: 自」および「日付: 至」フィールドを更新します。6. 「営業担当」タブにナビゲートします。7. 「セット」フィールドで、営業担当に参照セットを割り当てます。8. 要件に応じて残りのフィールドに入力し、保存します。

売掛/未収金営業担当参照勘定の定義必要な一般会計参照アカウントをユーザーに割り当てます。自動会計が営業担当に依存する場合、Receivablesでは、営業担当に対して入力する総勘定元帳参照勘定と、トランザクションのデフォルト収益、運送費および売掛/未収金勘定を決定するために定義した自動会計ルールが組み合せて使用されます。

総勘定元帳参照勘定を営業担当ユーザーに割り当てる手順は、次のとおりです。

1. 「営業担当アカウント参照の管理」ページにナビゲートします。2. 営業担当ユーザーを検索して選択します。3. ビジネス・ユニットを入力または更新します。4. このユーザーに割り当てる収益、運送費および売掛/未収金の勘定を入力し、保存します。

関連トピック

販売実績と自動会計

クレジット・メモ要求の手動レビューの構成Oracle Business Rulesを使用して、売掛/未収金トランザクションに対するクレジット・メモ要求の手動レビューおよび承認を構成できます。クレジット要求およびその関連ワークフロー通知に関する追加情報を取得することもできます。

28

手動クレジット・メモ要求承認フローでは、指定された各承認者にEメールまたはオンライン通知を送信します。各承認者は、クレジット要求の詳細をレビューしたり、クレジット・メモ承認に関連する情報を入力および更新できます。

手動ワークフロー通知プロセスの構成次のタスクを順番に構成して、手動クレジット・メモ要求の承認フローを有効にします。

FinArTrxnsCreditMemosAutomaticManual: デフォルトでは、このタスクはクレジット・メモの自動作成用に「自動」に設定されています(ビジネス・ルール1 = 1)。このタスクを「手動」に設定すると、クレジット要求の手動レビューおよび承認を開始できます。このタスク自体は、ワークフロー通知を有効にしません。FinArTrxnsCreditMemosCreationPostProcess: クレジット要求の手動レビューを有効にした後、このタスクを使用して、手動レビューのワークフロー通知を有効にします。タスク構成割当先ルールを使用して、このワークフローのレビュー担当者を複数構成できます。

手動ワークフロー通知プロセスを構成する手順は、次のとおりです。

1. BPMワークリストにナビゲートします。2. ユーザーのドロップダウン・リストで、「管理」を選択します。3. 「タスク構成」タブをクリックします。4. 「設定するタスク: 検索」フィールドに「* Credit」と入力し、「実行」アイコンをクリックします。これにより、クレジット・メモに使用可能なヒューマン・タスク(HT)が表示されます。

5. 「FinArTrxnsCreditMemosAutomaticManual」を選択し、出力値「HtOutcmeCreateManualCreditMemo」を使用して手動クレジット要求レビューのタスクを構成します。

6. 「FinArTrxnsCreditMemosCreationPostProcess」を選択し、手動クレジット要求レビューのワークフロー・プロセスを構成します。

7. ワークフロー通知のルーティング・ルールを設定します。8. 要件に応じて、通知ウィンドウのBIPテンプレートを設定します。標準テンプレートをコピーし、BIP編集ツールを使用してそのコンテンツを変更できます。

割当先ルール条件の追加属性を使用して、ワークフローのルーティング・ルールを構成できます。次の属性があります。

営業担当名営業担当EメールIDすべての修正金額の合計すべての入金額の合計クレジット・メモ事由コード付加フレックスフィールド属性1 - 15請求書明細摘要回収担当付加フレックスフィールド属性1 - 15明細レベルのクレジット請求書明細タイプ請求書または明細修正

29

消込済入金売掛/未収金システム・オプション付加フレックスフィールド属性1 - 15品目番号要求明細金額トランザクション情報付加フレックスフィールド属性1 - 15収益スケジューリング・ルール開始日収益スケジューリング・ルール終了日収益スケジューリング・ルール期間数収益スケジューリング・ルール・タイプ収益スケジューリング・ルール名要求税金貸方金額

クレジット・メモ要求のレビュー権限の有効化次の3つの権限を使用して、「クレジット・メモ要求のレビュー」ページへのユーザー・アクセスを保守します。

IEX_REVIEW_CREDIT_REQUEST_PRIV (クレジット要求のレビュー): この権限により、承認者は次のことができます。

クレジット要求のレビュー・ページにアクセスします。「トランザクション活動の表示」ボタンを使用して、元のトランザクション活動にアクセスします。「内部コメント」フィールドにコメントを入力します。

IEX_UPDATE_DISPUTE_TYPE_PRIV (クレジット要求の係争タイプの更新): この権限により、承認者は「係争タイプ」フィールドの値を更新できます。IEX_UPDATE_REBILL_DETAILS_PRIV (クレジット要求の再請求詳細の更新): この権限により、承認者は「再請求番号」および「再請求グループ」フィールドの値を更新できます。

クレジット要求のレビュー権限は、請求管理職務および回収管理基本の各職務ロールにデフォルトで含まれます。

特定のユーザーのビジネス・プラクティスに従って、クレジット要求の係争タイプの更新およびクレジット要求の再請求詳細の更新権限を必要な職務ロールに追加できます。

関連トピック

ワークフローEメール通知の設定の概要財務管理の構成可能なワークフロー通知の概要Oracle BI Publisher Enterpriseを使用して、フォーマットで使用するためのテンプレートを変更する方法

共通売掛/未収金構成の定義に関するFAQ

30

トランザクションを作成できない、または会計を生成できないのはなぜですか。基本的な売掛/未収金活動を実行する前に、会計期間をオープンする必要があります。これは新規インストールにも当てはまります。インストールが完了したら、会計期間を手動でオープンします。

法的エンティティ文書連番Receivablesでの法的エンティティの文書連番プライマリ元帳を設定して、Receivablesの文書連番を元帳レベルではなく法的エンティティ・レベルで許可できます。

つまり、同じ元帳に複数の法的エンティティが割り当てられている場合は、各法的エンティティに属する売掛/未収金トランザクション、修正および入金に個別の文書連番を割り当てることができます。

法的エンティティ・レベルの文書連番を使用すると、地方自治体および政府当局の要件に準拠する一方で、同じプライマリ元帳に複数の法的エンティティを編成できます。

Receivablesの法的エンティティ・レベルで文書連番を使用する場合は、次のガイドラインをレビューしてください。

Receivablesでの文書連番Receivables文書カテゴリ欠番なしの文書連番自動インボイス・プロセス

Receivablesでの文書連番

Receivablesで文書連番を法的エンティティ・レベルで使用するには、プライマリ元帳のオプションの指定ページにある「連番」セクションで、次のタスクのいずれかまたは両方を実行します。

1. 「連番基準」オプションを「法的エンティティ」に設定します。2. オプションで、Receivablesの「文書連番の強制」オプションを有効にします。

ステップ1およびステップ2を実行した場合、元帳に割り当てられたすべての法的エンティティで常に文書連番が使用されます。売掛/未収金イベントで生成されるすべての文書カテゴリに、文書連番を割り当てる必要があります。

ステップ1を実行してもステップ2は実行しない場合、必要に応じて、ビジネス要件を満たすReceivables文書カテゴリに文書連番を割り当てることができます。たとえば、自動入金処理にのみ順次採番を使用し、トランザクションには使用しない、といったことが可能です。

Receivables文書カテゴリ

プライマリ元帳で、文書連番が法的エンティティ・レベルで使用可能になっている場合(「連番基準」オプ

31

ションを「法的エンティティ」に設定)、Receivablesでは、元帳に割り当てられているすべての法的エンティティで、次の売掛/未収金イベントごとに文書カテゴリが作成されます。

請求書トランザクション・タイプクレジット・メモ・トランザクション・タイプデビット・メモ・トランザクション・タイプ受取手形トランザクション・タイプ標準入金修正

文書カテゴリに文書連番を割り当てる手順は、次のとおりです。

1. 「文書連番カテゴリの管理」ページにナビゲートします。2. 目的の文書カテゴリを検索します。「カテゴリ・コード」フィールドを使用して、請求書や入金などを入力することで検索を制限できます。

3. 検索結果をレビューし、目的の文書カテゴリを見つけます4. 必要な場合は、要件に応じてカテゴリ名を更新します。5. 変更を保存します。6. 「売掛/未収金文書連番の管理」ページにナビゲートします。7. 必要な文書連番名を検索するか、新しい文書連番を作成します。8. 「検索結果」セクションで、要件に応じて文書連番設定を更新または完了します。9. 「割当」セクションで、この文書連番に割り当てる文書カテゴリを選択します。

10. 変更を保存します。

次の関連処理が実行されると、各売掛/未収金イベントに対して文書連番が生成されます。

トランザクション: トランザクションの保存または完了時。該当するビジネス・ユニットの売掛/未収金システム・オプション「文書番号生成レベル」の設定によって異なります。修正: 修正が発行されたとき。領収書: 領収書が発行されたとき。受取手形: 受取手形が完了したとき。

Receivables文書連番には、次のルールが適用されます。

文書連番日付は会計日です(トランザクション日や入金日ではありません)。

注意: 受取手形で名宛人引受が必要な場合、Receivablesでは会計日ではなくトランザクション日を使用して文書番号が割り当てられます。これは、手形の引受時ではなく完了時に受取手形文書番号が生成されるためです。

文書連番を持つトランザクションの法的エンティティは変更できません。デフォルトでは、文書連番を持つトランザクションや入金は削除できません。売掛/未収金システム・オプション「支払削除の許可」が有効になっている場合、該当するビジネス・ユニットの入金および受取手形トランザクションのみを削除できます。

欠番なしの文書連番

文書連番では、文書連番の日付として会計日が使用されます。トランザクションに対して欠番なしの文書連

32

番を確保するために、文書番号の連番として年代順を強制できます。

注意: 欠番なしの文書連番は、手動で入力されたか、自動インボイスを使用してインポートされた請求書、クレジット・メモおよびデビット・メモのトランザクションにのみ適用されます。入金、修正または受取手形には適用されません。

売掛/未収金トランザクションに対して法的エンティティ・レベルで欠番なしの文書連番を確保するには、プライマリ元帳のオプションの指定ページの「連番」セクションで、次の3つのタスクを実行します。

1. 「連番基準」オプションを「法的エンティティ」に設定します。2. Receivablesで「文書連番の強制」オプションを有効にします。3. 「文書日付に年代順を強制」オプションを有効にします。

欠番なしの文書連番については、3つのステップをすべて実行する必要があります。「文書日付に年代順を強制」オプションを有効にすると、文書連番会計日とトランザクション会計日の間の相関が強制されます。これにより、Receivablesでは、同じ文書連番で最後に連番付けされた文書の会計日より前の会計日を持つトランザクションが作成されなくなります。

たとえば、2014年1月1日の会計日で請求書を作成するとします。この請求書には文書番号100が割り当てられます。作成する次の請求書には、請求書の会計日が2014年1月1日以降の場合は、文書番号101が割り当てられます。会計日が2014年1月1日より前の場合、Receivablesではトランザクションは作成されません。

自動インボイス・プロセス

法的エンティティ・レベルで文書連番を使用しており、プライマリ元帳オプション「文書日付に年代順を強制」が有効になっている場合は、売掛/未収金システム・オプション「不正な会計日」を設定する必要があります。このオプションを設定することで、会計日が文書連番内の順序外であった場合に、自動インボイスでトランザクションがどのように処理されるかが決まります。

「売掛/未収金システム・オプション」ページの「請求および収益」タブにある「自動インボイス」セクションで、「不正な会計日」フィールドを「拒否」または「修正」に設定します。

拒否: トランザクション会計日が文書連番内で順序外の場合は、トランザクションを拒否してエラー表に転送します。修正: トランザクション会計日が文書連番内で順序外の場合は、文書連番会計日に一致するように会計日を修正します。

関連トピック

トランザクションに割り当てられるのはどのような法的エンティティですか自動インボイス・インポート中の会計日の導出文書連番文書連番カテゴリ

自動インボイスによる法的エンティティ文書連番を使用したトランザクションの処理方法プライマリ元帳で文書連番が使用可能になっている場合、自動インボイスでは、元帳設定の要件に従って文書番号を検証し、トランザクションに割り当てます。

33

注意: インポートされたトランザクション明細にすでに文書番号がある場合、自動インボイスはこの文書番号を受け入れますが、それ以上の検証は行いません。

自動インボイス・トランザクション処理に影響する設定

プライマリ元帳オプション「文書日付に年代順を強制」が有効になっている場合は、売掛/未収金システム・オプション「不正な会計日」を設定する必要があります。このオプションを設定することで、会計日が文書連番内の順序外であった場合に、自動インボイスでトランザクションがどのように処理されるかが決まります。

「自動インボイスのインポート」プログラムを実行する前に、文書連番を作成し、インポートしたトランザクションに割り当てるトランザクション・タイプの文書カテゴリに割り当てる必要もあります。

トランザクションの処理方法

法的エンティティ・レベルで文書連番が設定されているプライマリ元帳の場合、自動インボイスはトランザクションを次のように処理します。

1. トランザクション明細を検証してトランザクションにグループ化します。2. 各トランザクションの法的エンティティを導出し、法的エンティティをトランザクションに割り当てます。

3. トランザクションに会計日がない場合は、会計日を導出します。4. プライマリ元帳オプション「文書日付に年代順を強制」が有効になっていない場合:

a. トランザクションに割り当てられた各トランザクション・タイプの文書カテゴリについて、文書連番を取得します。

b. 法的エンティティ、トランザクション・タイプ、文書連番および会計日の組合せに従って、トランザクションに文書番号を割り当てます。

5. プライマリ元帳オプション「文書日付に年代順を強制」が有効になっている場合:a. 法的エンティティ、次にトランザクション・タイプによってトランザクションを順序付けします。

b. トランザクションに割り当てられた各トランザクション・タイプの文書カテゴリについて、文書連番を取得します。

c. トランザクションを文書連番によって順序付け、次に会計日を昇順の年代順で順序付けます。d. 文書連番会計日をトランザクションの会計日と比較します。e. トランザクション会計日が文書連番会計日以降である場合は、法的エンティティ、トランザクション・タイプ、文書連番および会計日の組合せに従って文書番号をトランザクションに割り当てます。

f. トランザクション会計日が文書連番会計日より前である場合は、売掛/未収金システム・オプション「不正な会計日」の値を取得します。

g. 「不正な会計日」オプションの設定に応じて次のようになります。拒否: トランザクションを拒否して、トランザクションをエラー表に転送します。修正: トランザクション会計日を文書連番会計日で更新します。

注意: 文書連番会計日がクローズ期間内の場合は、この日付を最初のオープン会計期間に修正します。

h. 法的エンティティ、トランザクション・タイプ、文書連番および会計日の組合せに従って、トランザクションに文書番号を割り当てます。

34

関連トピック

自動インボイスによるインポート中のデータの処理方法インポートされたデータに対する自動インボイス検証

法的エンティティ文書連番に関するFAQ

元帳またはビジネス・ユニット間で文書連番を共有できますか。

元帳に対して文書連番が有効になっている場合は、元帳またはビジネス・ユニット間で同じ文書連番を共有することはお薦めしません。

文書連番では、文書連番の日付として会計日が使用されます。元帳では異なる会計期間をオープンできるため、各元帳で同じ文書連番の異なる会計日が導出される可能性があります。

文書カテゴリは作成した各トランザクション・タイプに対して作成されるため、ビジネス・ユニットごとに個別のトランザクション・タイプのセットを作成して保持することをお薦めします。

売掛/未収金活動

売掛/未収金活動タイプ売掛/未収金活動タイプでは、トランザクションおよび入金以外の売掛/未収金のすべての活動に対してデフォルトの会計情報が提供されます。

売掛/未収金活動タイプの使用

修正

修正を作成するときは、このタイプの活動を使用します。このタイプの活動を少なくとも1つ作成する必要があります。

また、内部使用専用として予約されている3つの関連活動もあります。

チャージバック修正修正戻し処理チャージバック戻し処理

チャージバックを作成する前に、「チャージバック修正」活動に対して総勘定元帳勘定科目を定義する必要があります。

入金の戻し処理を行う際に、修正またはチャージバックが存在する場合、Receivablesでは、「修正戻し処理」および「チャージバック戻し処理」活動を使用して、オフ設定修正が自動的に生成されます。

35

銀行エラー

その他入金の入力時には、このタイプの活動を使用します。このタイプの活動は、Cash Managementを使用した銀行取引明細書の消込に役立ちます。

受取手形資金回収

受取手形から入金の消込を取り消す必要がある場合は、このタイプの活動を使用します。CashManagementで入金の戻し処理はできないため、この活動を使用してマイナスのその他入金を作成し、受取手形資金回収に消し込みます。

クレジット・カード・チャージバック

クレジット・カード・チャージバックを記録する場合は、このタイプの活動を使用します。クレジット・カード・チャージバックを記録する前に、Receivablesによって提供されるクレジット・カード・チャージバック活動に対して一般会計清算勘定を定義する必要があります。

Receivablesでは、クレジット・カード・チャージバックを適用するときに決済勘定が貸方に記入され、マイナスのその他入金の生成後、勘定が借方に記入されます。その後、チャージバックが無効であると判断した場合、クレジット・カード・チャージバックを取り消すときにReceivablesにより決済勘定が借方に記入され、マイナスのその他入金の戻し処理後に勘定が貸方に記入されます。1つのビジネス・ユニット内で一度にアクティブにできるクレジット・カード・チャージバック活動は1つのみです。

クレジット・カード払戻

顧客クレジット・カード勘定に対する払戻を処理するときには、このタイプの活動を使用します。この活動には、クレジット・カード払戻の決済に使用する一般会計清算勘定に関する情報が含まれます。クレジット・カード払戻を処理するには、このタイプの活動を少なくとも1つ作成する必要があります。

注意: クレジット・カード・サービスは、現在、Oracle Cloud実装では使用できません。

期限内割引

トランザクションの支払条件によって決定された割引期間内に支払を受領した場合は、このタイプの活動を使用して、トランザクションを修正します。

延滞手数料

このタイプの活動を使用して、延滞手数料ポリシーを定義します。期限超過トランザクションに対する修正として延滞手数料を記録する場合、延滞手数料活動を定義する必要があります。延滞手数料以外の違約金を評価する場合は、違約金に対して別の延滞手数料活動を定義します。

その他現金

その他入金の入力時には、このタイプの活動を使用します。「その他現金」活動では、配分セットを使用して、様々な勘定科目間でその他現金を自動的に配分します。このタイプの活動を少なくとも1つ作成する必要があります。

36

この活動の「税率コードのソース」が「活動」である場合は、その他入金およびその他支払の税金を計上するための資産および負債税率コードを定義する必要があります。

支払ネッティング

他のオープン入金に対して入金を消し込むときに、このタイプの活動を使用します。1つの入金を別の入金と相殺する場合に使用する、一般会計清算勘定を定義する必要があります。1つのビジネス・ユニット内で一度にアクティブにできる支払ネッティング活動は1つのみです。

前払金

前払金入金の作成時には、このタイプの活動を使用します。前払金活動を使用する前払金入金に対して総勘定元帳勘定科目を定義する必要があります。1つのビジネス・ユニット内で一度にアクティブにできる前払金活動は1つのみです。

入金消込

入金を消し込むときには、このタイプの活動を使用します。入金の未消込金額または支払不足を消し込む場合、クレジット処理するGL勘定科目を定義する必要があります。

払戻

自動化された非クレジット・カード払戻を処理するときは、このタイプの活動を使用します。払戻の決済に使用する一般会計精算勘定を定義する必要があります。このタイプの活動を少なくとも1つ作成する必要があります。1つのビジネス・ユニット内で一度にアクティブにできる払戻活動は1つのみです。

短期借入金

このタイプの活動を使用して、受取手形が償還請求権付きでファクタリングされたときに銀行によって債権者に行われる仮払を記録します。受取手形送金入金方法で使用する送金銀行を作成または更新するときに、短期借入金売掛/未収金活動を選択します。

期限外割引

トランザクションの支払条件によって決定された割引期間後に支払を受領した場合は、このタイプの活動を使用して、トランザクションを修正します。

GL勘定科目のソース売掛/未収金活動を定義する場合、「GL勘定科目のソース」を使用して、活動で生成された費用または収益の勘定科目がReceivablesによりどのように導出されるかを示します。

GL勘定科目のソース・オプション

GL勘定科目活動

売掛/未収金活動に指定した総勘定元帳勘定科目に費用または収益を配賦します。活動タイプが「銀行エラー」、「延滞手数料」、「前払金」または「入金消込」の場合は、このオプションのみを選択できます。

37

配分セット

指定した配分セットに費用または収益を配賦します。この値は、「その他現金」活動と一緒にのみ使用されます。

請求書の収益

請求書で指定された収益勘定に税金の費用または収益の正味金額を配賦します。「税率コードのソース」が「なし」に設定されている場合は、これらの勘定科目に総額を配賦します。このオプションを選択できるのは、活動タイプが「修正」、「期限内割引」または「期限外割引」の場合のみです。

請求書の収益が前受の場合、自動会計によって予想される収益会計配分勘定および金額が導出されます。その後、Receivablesではこの情報を使用して、これらの導出された収益勘定に修正金額または割引額が配賦されます。

請求書の税率コード

請求書の税率コードで指定された費用/収益勘定を使用して正味部分を配賦します。「税率コードのソース」が「なし」に設定されている場合は、これらの勘定科目に総額を配賦します。このオプションを選択できるのは、活動タイプが「修正」、「期限内割引」または「期限外割引」の場合のみです。

注意: ゼロ金額の収益配分のある請求書を修正する場合は、修正活動の「GL勘定科目ソース」を「請求書の収益」または「請求書の税率コード」に設定できません。

関連トピック

トランザクションに対する修正の計算方法

税率コードのソース売掛/未収金活動を定義する場合、「税率コードのソース」を使用して、Receivablesが活動の税率コードを導出する方法を指定します。

税率コードのソース・オプション

なし

指定された「GL勘定科目のソース」に従って、税額全体が配賦されます。このオプションは、税金を個別に会計処理しない場合に使用します。

活動

活動で指定された資産または負債税勘定に対して税額が配賦されます。

請求書

請求書の税率コードに指定された税勘定に税額が配分されます。このオプションは、活動タイプが「その他

38

現金」または「延滞手数料」の場合は選択できません。

注意: 税金配分金額がゼロの請求書に対する税金修正の場合は、修正活動の「税率コードのソース」を「請求書」に設定できません。

「税率コードのソース」が「活動」または「請求書」の場合は、この活動の税金が控除対象か控除対象外かを示す必要があります。

関連トピック

売掛/未収金トランザクションに対する税金の会計処理

自動消込ルール・セット

各自動消込ルールの使用例6つの自動消込ルールの組合せから、自動消込ルール・セットを作成します。ルールは、未回収借方品目への入金の消込に使用する順序で入力します。

自動消込ルールは次のとおりです。

支払と請求書の照合勘定決済支払遅延請求書決済支払条件ごとの支払遅延請求書の決済最も古い日付の請求書から消込組合せルール

入金を消し込むとき、Receivablesでは自動消込ルール・セットの最初のルールが使用されます。セット内の最初のルールで一致が検出されなかった場合、Receivablesは順序内の次のルールを使用し、入金が消し込まれるまで同様に処理を続けます。

これらの例は、各ルールで入金がトランザクションに消し込まれ、顧客残高が更新される方法を示しています。

支払と請求書の照合

請求書と支払の照合ルールでは、入金額が借方品目の金額と正確に一致する場合のみ、単一の請求書、デビット・メモまたはチャージバックに入金が消し込まれます。入金額と一致する未回収金額が複数の借方品目にある場合、Receivablesでは、最も早い期日の品目に入金が消し込まれます。複数の借方品目の金額と支払期日が同じである場合、Receivablesでは、最も小さい支払予定ID番号(内部識別子)の品目に入金が消し込まれます。

Receivablesでは、自動消込ルール・セットの未回収残高計算に指定された値、および顧客プロファイルに割り当てられた割引猶予日数を使用して、借方品目の未回収残高が決定されます。ルールでは、「一部入金消

39

込」オプションの値が無視されます。

たとえば、次のようなシナリオを考えてみます。

品目/オプション 値

割引 期限内のみ

延滞手数料 いいえ

入金 $1800

入金日 2003年1月14日

割引猶予日数 5

請求書詳細は次のとおりです。

請求書番号 請求書金額 割引 支払条件 請求書日付 支払期日

600 $2000 $20 10% 10/正味30 2003年1月1日 2003年1月30日

この請求書に割り当てられている支払条件には、請求書が10日以内に支払われる場合は10%の割引が含まれ、自動消込ルール・セットの未回収残高計算では期限内割引が可能です。請求書が10日の期間後に支払われた場合も、Receivablesは5日間の割引猶予日数を加算するため、この請求書は10%の割引の対象となります。

1月14日の請求書の未回収残高は$1800です。未回収残高が入金額と一致するため、入金が消し込まれます。請求書の未払残高は$2000であるため、割引猶予期間がなかった場合、Receivablesで入金を消し込むことができませんでした。

勘定決済

勘定決済ルールでは、入金額が顧客の未回収残高と正確に一致する場合にのみ入金が消し込まれます。Receivablesでは、顧客の未回収残高の計算時に、すべての未回収借方品目および貸方品目が含まれます。貸方残高品目には、クレジット・メモ、対顧客勘定クレジット、対顧客勘定および未消込入金があります。ルールでは、「一部入金消込」オプションの値が無視されます。

勘定決済ルールでは、次の式を使用して各借方品目の未回収残高が計算されます。

Open Balance = Original Balance + Late Charges - Discount

次にReceivablesは各借方品目の残高を加算して、合計勘定残高を決定します。ルールでは、各請求書、チャージバック、デビット・メモ、クレジット・メモおよび借方品目への未消込入金または対顧客勘定入金の消込にこの式が使用されます。

Receivablesでは、自動消込ルール・セットの未回収残高計算に指定された値、および顧客プロファイルに割り当てられた割引猶予日数を使用して、顧客未回収残高が決定されます。

たとえば、次のようなシナリオを考えてみます。

品目/オプション 値

40

延滞手数料 はい

係争品目 はい

入金 $590

この表は、顧客活動を示しています。

遅延借方/貸方 請求書金額 延滞手数料 係争中

請求書45 $500 $40 はい

請求書46 $300 $0 N/A

クレジット・メモ100 $50 N/A N/A

未消込入金 $200 N/A N/A

「延滞手数料」および係争品目オプションが使用可能になっているため、この顧客の未回収残高は$590です。入金額が顧客の未回収残高と一致するため、入金を消し込むことができます。

入金額が顧客の勘定残高と完全に一致しなかった場合、Receivablesではセット内の次のルールを使用して入金の消込が試行されます。

支払遅延請求書決済

支払遅延請求書決済ルールでは、入金額が顧客の遅延勘定残高と正確に一致する場合にのみ入金が消し込まれます。Receivablesでは、遅延勘定残高を計算する際に、すべての未回収遅延借方品目および貸方品目が含まれます。ルールでは、「一部入金消込」オプションの値が無視されます。

支払遅延請求書決済ルールでは、現在遅延している品目のみに入金が消し込まれます。請求書支払期日が現在消し込まれている入金の日付以前である場合、借方品目は遅延とみなされます。Receivablesでは、未消込入金と対顧客勘定入金の入金日、およびクレジット・メモと対顧客勘定クレジットのクレジット・メモ日付を使用して、これらの金額を顧客の遅延勘定残高の一部として含めるかどうかが決定されます。

たとえば、入金日が2003年1月10日の入金について、すべての未消込入金と対顧客勘定入金、およびすべてのクレジット・メモと対顧客勘定クレジットを消し込む場合、トランザクション日(入金日またはクレジット・メモ日)が2003年1月10日以前の入金は、顧客の遅延勘定残高を計算するときに含まれます。

Receivablesでは、自動消込ルール・セットの未回収残高計算に指定された値、および顧客プロファイルに割り当てられた割引猶予日数を使用して、顧客の遅延勘定残高が決定されます。「延滞手数料」および係争品目オプションの設定により、入金額が顧客の遅延勘定残高と一致していても、遅延借方品目がクローズされない場合があります。

たとえば、次のようなシナリオを考えてみます。

品目/オプション 値

延滞手数料 いいえ

係争品目 いいえ

入金 $420

41

この表は、顧客活動を示しています。

遅延借方/貸方 請求書金額 延滞手数料 係争中

請求書209 $300 $0 N/A

請求書89 $250 $0 はい

請求書7 $120 $30 N/A

「延滞手数料」および係争品目オプションが使用可能になっていないため、Receivablesでは、顧客の遅延勘定残高の計算に請求書89 ($250)または請求書7 ($30)の延滞手数料は含まれません。したがって、この顧客の遅延勘定残高は$420です。入金額が顧客の遅延勘定残高と一致するため、入金が消し込まれます。ただし、請求書7と請求書89はまだ未回収の遅延借方品目です。

支払条件ごとの支払遅延請求書の決済

支払条件ごとの支払遅延請求書の決済ルールでは、入金額が顧客のクレジット・メモと支払遅延請求書の合計と正確に一致する場合にのみ入金が消し込まれます。このルールは支払遅延請求書決済ルールと似ていますが、最初に支払条件別に支払遅延請求書をグループ化し、グループ内で最も古いトランザクション期日をグループ期日として使用します。

請求書支払期日が現在消し込まれている入金の日付より前である場合、借方品目は遅延とみなされます。クレジット・メモの場合、Receivablesでは、クレジット・メモ日を使用して、これらの金額を顧客の勘定残高に含めるかどうかが決定されます。

たとえば、入金日が2003年1月10日の入金を消し込む場合、トランザクション日が2003年1月10日以前のクレジット・メモが含まれます。クレジット・メモには支払条件がないため、各グループに含まれます。

Receivablesでは、自動消込ルール・セットの未回収残高計算に指定された値、および顧客プロファイルに割り当てられた割引猶予日数を使用して、顧客クレジット・メモと支払遅延請求書の合計が決定されます。「延滞手数料」および係争品目オプションの設定により、入金額が顧客クレジット・メモと支払遅延請求書の合計と一致していても、遅延借方品目がクローズされない場合があります。

たとえば、6月25日に消し込まれた$900の入金について考えます。この表は、関連顧客活動を示しています。

トランザクション番号 支払条件 支払期日 請求書金額

1 A 5月25日 $500

2 A 6月25日 $200

3 A 6月25日 $200

4 B 6月20日 $900

5 C 5月25日 $905

これらのトランザクションは、Receivablesによって次のようにグループ化されます。

グループ1: トランザクション1、2、3 金額: $900 グループ期日: 5月25日グループ2: トランザクション4 金額: $900 グループ期日: 6月20日

42

グループ3: トランザクション5 金額: $905 グループ期日: 5月25日

グループ1と2はどちらも入金額と一致するため、Receivablesでは最も古い支払期日を持つグループ(グループ1)が選択され、このグループのトランザクションに入金が消し込まれます。

最も古い日付の請求書から消込

最も古い日付の請求書から消込ルールでは、入金が顧客の借方品目および貸方品目に、最も古い支払期日の品目から消し込まれます。Receivablesでは、自動消込ルール・セットの未回収残高計算に指定された値を使用して、顧客の最も古い未処理品目が決定されます。

たとえば、次のようなシナリオを考えてみます。

品目/オプション 値

一部入金消込 はい

延滞手数料 いいえ

入金 $200

この表は、顧客活動を示しています。

請求書番号 請求書金額 延滞手数料 支払期日

801 $0 $35 2002年12月01日

707 $450 $0 2003年1月1日

2つの請求書の期日のみを比較する場合、請求書801が最も古い請求書になります。ただし、Receivablesでは、自動消込ルール・セットの未回収残高計算および自動照合ルール・オプションもチェックされます。「延滞手数料」オプションが使用可能でないため、Receivablesでは請求書801が無視され(残金が延滞手数料のみで構成されるため)、$200の入金が請求書707に消し込まれます。

「一部入金消込」オプションが使用可能になっていない場合、Receivablesはこの入金を消し込むことができず、順序内の次のルールを参照します。

組合せルール

組合せルールでは、入金額が2つの借方品目の金額と正確に一致する場合にのみ、2つの請求書、デビット・メモまたはチャージバックに入金が消し込まれます。2つの借方品目の複数の組合せに入金金額と一致する合計未回収金額がある場合、Receivablesでは、支払期日が最も早い品目の組合せに入金が消し込まれます。2つの借方品目の複数の組合せで同じ金額と支払期日が指定されている場合、Receivablesでは、最も小さい支払予定ID番号(内部識別子)の品目の組合せに入金が消し込まれます。

Receivablesでは、自動消込ルール・セットの未回収残高計算に指定された値、および顧客プロファイルに割り当てられた割引猶予日数を使用して、借方品目の未回収残高が決定されます。ルールでは、「一部入金消込」オプションの値が無視されます。

たとえば、ロックボックスには次の5つの未回収請求書があります。

請求書番号 請求書金額

43

101 $50.00

201 $200.00

301 $175.00

401 $372.00

501 $127.00

ロックボックスには$572の入金が含まれています。最初の自動消込ルールとして組合せルールを使用すると、入金は請求書201と401に消し込まれます。

関連トピック

入金および対顧客勘定クレジット・メモの消込に関するガイドライン

自動消込ルール・セットの使用例この例では、自動消込ルール・セットの作成方法と使用方法を示します。Global Freight Carriersから受け取った支払を管理するために、自動消込ルール・セットを作成します。この会社と期限内割引の契約はありますが、支払や割引の猶予日数がないため、期限を過ぎて受領した支払に対して延滞手数料を追加しません。

自動消込ルール・セットの作成

次の値を使用して、自動消込ルール・セットを作成します。

フィールド 値

未回収残高計算: 割引 期限内のみ

未回収残高計算: 延滞手数料 いいえ

未回収残高計算: 係争品目 いいえ

自動照合ルール: 一部入金消込 はい

自動照合ルール: 消込残高処理 対顧客勘定

自動消込ルール 1. 支払と請求書の照合

自動消込ルール 2. 勘定決済

自動消込ルール 3. 最も古い日付の請求書から消込

自動消込ルール・セットを使用した支払の処理

Global Freight Carriersに次の未処理請求書があり、そのいずれも係争中ではありません。

番号 残高 支払期日 割引日 割引額

123 $200 2002年12月11日 2002年12月01日 $20

44

124 $300 2002年12月08日 2002年11月30日 $30

125 $150 2002年12月13日 2002年11月28日 $15

預入日が2002年12月10日の$600の支払がGlobal Freight Carriersに入力されました。

作成した自動消込ルール・セットを使用して、Receivablesでは次のように支払が処理されます。

1. 自動消込ルール1の「支払と請求書の照合」は失敗します。これは、入金の金額($600)と等しい未回収残高がある顧客オープン項目がないためです。

2. Receivablesは自動消込ルール2を参照します。3. 顧客の計算済勘定残高($650)が入金額と同じでないため、自動消込ルール2の「勘定決済」は失敗します。

4. Receivablesは自動消込ルール3を参照します。5. Receivablesでは、自動消込ルール3の「最も古い日付の請求書から消込」が使用されます。

a. Receivablesは、最初に入金を最も古い請求書である請求書124 ($300)に消し込み、次の計算を実行します。

2002年11月30日の割引日が過ぎており、「割引」フィールドが「期限内のみ」に設定されているため、$30の割引は使用できなくなりました。この請求書の未払額残高は、$0か、この品目に対して以前に評価された延滞手数料の金額と等しくなります。「延滞手数料」オプションは「いいえ」に設定されているため、延滞手数料は顧客未回収残高計算に含まれません。残りの入金額は$300.00となります。

b. Receivablesは、次に古い請求書である請求書123に$200を消し込み、次の計算を実行します。請求書124と同様に、請求書123の割引日は過ぎており、$20の割引は使用できなくなりました。この請求書の未払額残高は、$0か、この品目に対して以前に評価された延滞手数料の金額と等しくなります。「延滞手数料」オプションは「いいえ」に設定されているため、延滞手数料は顧客未回収残高計算に含まれません。残りの入金額は$100となります。

c. 「一部入金消込」オプションが「はい」に設定されているため、Receivablesでは、残りの$100が部分入金として請求書125 ($150)に消し込まれます。

注意: 「一部入金消込」オプションが「いいえ」に設定されている場合、残りの金額は請求書125に消し込まれません。「消込残高処理」オプションが「対顧客勘定」に設定されているため、かわりに勘定に記録されます。

他の請求書と同様に、請求書125の割引日は過ぎており、$15の割引は使用できなくなりました。この請求書に延滞手数料がない場合、未払額残高は$150から$50に減額され、オープンのままになります。

自動消込ルール・セットに関するFAQ

自動消込ルール・セットの選択および使用方法を教えてください。

支払処理中に、Receivablesは入金別照合ルールを使用して入金をオープン・トランザクションと照合し、入金を自動的に消し込むか、入金消込について勧告を提示します。トランザクションを照合できない場合や、トランザクション情報を利用できない場合、Receivablesは、顧客サイトまたは顧客レベルで顧客プロファイルに定義されている自動消込ルール・セットを使用して入金を消し込みます。

45

顧客のプロファイルに自動消込ルール・セットが割り当てられていない場合、Receivablesは、システム・オプションに割り当てられている自動消込ルール・セット、および顧客サイトまたは顧客プロファイルで定義されている割引猶予日数を使用して入金を消し込みます。

自動消込ルール・セットに適用するルールがない場合、自動消込ルール・セットの「消込残高処理」オプションの設定に応じて、残りの金額は未消込または対顧客勘定のいずれかになります。

一部入金の使用方法を教えてください。

自動消込ルール・セットの「最も古い日付の請求書から消込」ルールで、「一部入金消込」オプションを使用します。このオプションを使用可能にした場合、借方品目のクローズに必要な金額よりも少ないトランザクションに対して入金を消し込むことができます。

自動消込ルール・セットで一部入金は使用されないが、未回収残高計算に延滞手数料が含まれる場合、Receivablesでは、トランザクション金額に延滞手数料を加えたものに対する入金消込を部分入金として解釈できます。

たとえば、$100の入金を消し込んで$100のトランザクションをクローズするが、トランザクションには$10の延滞手数料が累計されているとします。「一部入金消込」オプションが使用可能になっていない場合、$100の入金を現在は$110の未回収借方品目に消し込むことはできません。

承認限度

承認限度文書タイプ特定のトランザクション活動および金額範囲に対するユーザーの承認限度を通貨ごとに定義できます。文書タイプでは、ユーザーが承認できるトランザクション活動を識別します。

文書タイプ

修正

通貨および金額別に修正承認限度を定義します。Receivablesでは、修正を作成または承認する際に、文書タイプが修正の承認限度を使用します。

承認限度範囲を超える修正を入力した場合、適切な承認限度を持つ別のユーザーが承認または拒否するまで、修正のステータスは「待ち状態」に割り当てられます。

入金消込

通貨および金額別に入金消込承認限度を定義します。Receivablesでは、入金に対して未消込入金額または過少支払のいずれかを消し込む際には常に、この文書タイプの承認限度が使用されます。

承認限度範囲外の入金金額は消し込むことができません。また、消込の承認限度は売掛/未収金システム・オプションの消込金額とは異なりますが、超えることはできません。

46

クレジット・メモ払戻

通貨および金額別にクレジット・メモ払戻承認限度を定義します。Receivablesでは、対顧客勘定クレジット・メモの払戻を行うたびに、この文書タイプの承認限度が使用されます。

関連トピック

トランザクションに対する修正の計算方法入金および対顧客勘定クレジット・メモの消込に関するガイドライン消込と入金

承認限度に関するFAQ

承認限度があるユーザーはどのようにして管理できますか。

承認限度を割り当てることができるのは、組織内で定義されている有効なユーザーのみです。ユーザー、文書タイプおよび通貨の組合せにより、特定の承認限度レコードが識別されます。たとえば、同じユーザーおよび文書タイプに対して、システムに定義されている各通貨で、複数の承認限度範囲を定義できます。

人員の変更が発生した場合は、必ず承認限度を更新してください。

取引明細書

顧客取引明細書の実装方法取引明細書を印刷して、指定された期間の請求書、デビット・メモ、チャージバック、入金、対顧客勘定クレジット、クレジット・メモおよび修正活動の完全な記録を顧客に提供します。

取引明細書を設定するには、次のタスクを実行します。

取引明細書の売掛/未収金システム・オプションの設定送金先住所の定義取引明細書送付サイクルの定義顧客サイト・プロファイルの定義

取引明細書の売掛/未収金システム・オプションの設定

取引明細書処理に必要な売掛/未収金システム・オプションを設定します。

取引明細書の売掛/未収金システム・オプションを設定する手順は、次のとおりです。

1. 「システム・オプションの作成」ページまたは「システム・オプションの編集」ページにナビゲートします。

2. 該当するビジネス・ユニットを選択します。3. 「請求および収益」がまだ表示されていない場合は、そのタブをクリックします。

47

4. 「送金先住所の印刷」オプションを有効にして、送金先住所を顧客取引明細書に印刷します。5. 「自国名印刷」オプションを有効にして、その国の住所を参照するトランザクションおよび取引明細書に自国を印刷します。

6. 「デフォルト国」フィールドで、自国として使用する国を選択します。これは、送金先住所のデフォルト国の値です。また、自国は、税金計算や納税者IDおよび税務登録番号の検証にも使用されます。

7. 要件に従って残りのReceivablesシステム・オプションを入力または更新し、保存します。

送金先住所の定義

取引明細書およびトランザクションに関するデフォルトの送金先情報を提供する送金先住所を定義します。

送金先住所を定義する手順は、次のとおりです。

1. 「送金先住所の作成」ページにナビゲートします。2. 「送金先住所セット」フィールドで、参照データ・セットを選択します。3. 「国」フィールドには、売掛/未収金システム・オプションで定義されたデフォルト国が表示されます。必要に応じて、別の国を選択します。

4. 住所詳細を入力して保存します。5. 「基準から入金」セクションで、「作成」アイコンをクリックして基準から入金を作成ウィンドウを開きます。このウィンドウを使用して、指定した場所の顧客請求先サイトに作成した送金先住所を割り当てます。

6. 「国」フィールドで、この送金先住所を顧客請求先サイトに割り当てる国を選択します。7. 必要に応じて、「都道府県」フィールドと「郵便番号」フィールドを使用して送金先住所割当をさらに制限し、保存します。

取引明細書送付サイクルの定義

取引明細書送付サイクルを定義して、取引明細書を顧客にいつ送信するかを決定します。

取引明細書送付サイクルを定義する手順は、次のとおりです。

1. 「取引明細書送付サイクルの管理」ページにナビゲートします。2. 「検索結果」セクションで「追加」アイコンをクリックします。3. 「名前」フィールドに、この取引明細書送付サイクルの名前を入力します。4. 「間隔」フィールドで、取引明細書を生成する頻度を決定する間隔を選択します(週次、月次、四半期)。

5. 「サイクル日」セクションで、「追加」アイコンをクリックします。6. 「ビジネス・ユニット」フィールドで、この取引明細書送付サイクルを使用するビジネス・ユニットを選択します。

7. 「取引明細書日付」フィールドに、取引明細書送付サイクルの取引明細書を印刷する最初の日付を入力します。

8. 該当するビジネス・ユニットごとに、取引明細書送付サイクルの間隔として適切な行数が設定されるまで、ステップ5から7を繰り返します。たとえば、1年の期間を対象とするには、四半期間隔に4行、または月次間隔に12行を入力します。

9. 取引明細書送付サイクルで間隔をスキップする場合は、行で「スキップ」オプションを有効にします。

48

たとえば、月次間隔と12の月次取引明細書日付で取引明細書送付サイクルを作成した後で、取引明細書を月次ではなく、隔月に送信するように決定したとします。1行おきに「スキップ」オプションを有効にして、取引明細書の数を年間6通に削減できます。

10. 要件に応じて残りのフィールドに入力し、保存します。

顧客サイト・プロファイルの定義

送金先住所および取引明細書送付サイクルを定義した後、取引明細書の送信先となる各顧客請求先サイトで適切なプロファイル設定を有効にする必要があります。顧客に1つの取引明細書サイトを使用していない場合は、要件に応じて、同じ顧客アカウントに属する請求先サイトに異なる取引明細書送付サイクルを割り当てることができます。このようにして、各請求先サイトにそのサイト・トランザクション用の独自の取引明細書を割り当てることができます。

取引明細書の顧客サイト・プロファイルを定義する手順は、次のとおりです。

1. 該当する顧客サイトの「サイトの編集」ページにナビゲートします。2. 「取引明細書および督促」セクションにナビゲートします。3. 「取引明細書送付」オプションを有効にします。4. 「取引明細書送付サイクル」フィールドで、このサイトで使用する取引明細書送付サイクルを選択します。

5. 「延滞手数料」タブをクリックします。6. 「通貨設定」セクションにナビゲートします。7. 「追加」アイコンをクリックします。8. 「通貨」フィールドで、このサイトで使用する通貨を選択します。9. 「最小取引明細書金額」フィールドに、取引明細書を生成する最小金額を入力します。指定通貨での最小未回収残高がこの金額を超える場合、そのサイトの取引明細書が生成されます。

10. 要件に応じて残りのフィールドに入力し、保存します。

関連トピック

顧客プロファイル区分の使用方法送金先住所を使用する方法

取引明細書送付サイクルの使用方法取引明細書送付サイクルを使用して、取引明細書を顧客にいつ送信するかを決定します。取引明細書送付サイクルを顧客およびサイト・レベルのプロファイルに割り当てます。

特定の顧客の取引明細書を印刷する場合は、次のようになります。

顧客の取引明細書サイトを定義した場合、Receivablesでは、顧客アカウント・プロファイルに定義されている取引明細書送付サイクルが、印刷に使用するデフォルトの取引明細書送付サイクルとして使用されます。取引明細書サイトを定義しなかった場合は、印刷実行に含まれる該当する請求先サイトごとに、顧客サイト・プロファイルに定義されている取引明細書送付サイクルが使用されます。

顧客を選択しない場合、印刷実行用に入力した取引明細書送付サイクルと一致する取引明細書送付サイクルを持つすべての顧客の取引明細書が印刷されます。

49

取引明細書送付サイクルを作成する場合、サイクルに使用する間隔(週次、月次、四半期)と、サイクルで取引明細書を印刷する日付を定義します。また、特定の取引明細書日付をスキップするかどうかも指定できます。

Receivablesでは、顧客の取引明細書送付サイクルが1つ以上の取引明細書日付で印刷をスキップするように設定されている場合でも、この顧客の取引明細書を最後に印刷した時点から現在の取引明細書日付までのすべての活動が含まれます。Receivablesでは、取引明細書の前期間からの未回収借方品目も含まれます。

シナリオ

次の条件について考えてみます。

システム日付: 2011年9月3日取引明細書日付: 2011年9月1日前の取引明細書の日付: 2011年6月1日(スキップ)取引明細書送付サイクル: 四半期

この取引明細書に含まれる活動の範囲は、取引明細書が最後に印刷された日付(2011年3月1日)から現在の取引明細書日付(2011年9月1日)にわたります。前の2011年6月1日の取引明細書はスキップされたため、その期間の活動は現在の取引明細書に表示されます。

この図は、この取引明細書に含まれる活動を示しています。

この表は、トランザクション日に基づいて取引明細書の特定のトランザクションを含めるために使用されるロジックの説明を示しています。

請求書作成日 取引明細書に含まれるか

請求書日付:2011年2月28日

いいえ。2011年3月1日と2011年8月31日の間に未処理であるか、クローズされた場合を除きます。

請求書日付:2011年8月30日

はい。請求書日付が、取引明細書の最終印刷日と取引明細書日付の間にあるためです。

請求書日付:2011年9月2日

いいえ。請求書日付が取引明細書日付より後であるためです。

関連トピック

年齢調べ方法

50

取引明細書に関するFAQ

取引明細書サイトを作成するにはどうすればよいですか。

顧客アカウントに属するサイトの1つを取引明細書サイトとして指定できます。取引明細書サイトを作成すると、Receivablesでは、各サイトの取引明細書ではなく、すべての顧客請求先サイトについて統合された単一の取引明細書が生成されます。顧客アカウントごとに1つのアクティブな取引明細書サイトのみを定義できます。

取引明細書サイトを作成する手順は、次のとおりです。

サイトに取引明細書ビジネス目的を割り当てます。「使用される取引明細書、督促状および延滞手数料サイト・プロファイル」プロファイル・オプションを「はい」に設定します。

取引明細書での対顧客勘定入金と未消込入金の表示

対顧客勘定入金と未消込入金を含むすべての入金が、対応する請求先サイトの取引明細書に表示されます。請求先サイト割当のない対顧客勘定入金または未消込入金があり、顧客に対して取引明細書サイトが定義されていない場合、これらの入金は顧客の請求先サイト取引明細書に含まれません。

顧客の取引明細書サイトを作成すると、Receivablesによって対顧客勘定入金と未消込入金がクレジットとして要約され、これらが連結済取引明細書の別のページに印刷されてから、顧客請求先サイトごとの小計が要約されます。

標準メッセージに関するFAQ

異なる言語でメッセージを記述できますか。はい。企業のニーズに合った任意の言語でメッセージを記述できます。どの言語の場合も、標準メッセージのテキストは255文字を超えることはできません。Receivablesでは、メッセージに対して他の検証は実行されません。

文書にメッセージを追加するにはどうすればよいですか。標準メッセージは、顧客取引明細書と、デビット・メモまたは利息請求書として提示された延滞手数料文書に印刷できます。

取引明細書の場合、アクティブな標準メッセージは、「顧客取引明細書の作成」プログラムの値リストの選択肢として表示されます。選択したメッセージは、顧客取引明細書の最後に表示されます。

延滞手数料文書の場合、アクティブな標準メッセージは、該当する顧客またはサイト・プロファイルの「延滞手数料」タブ・セクションにある「メッセージ・テキスト」フィールドの選択リストに表示されます。選択したメッセージは、この顧客の延滞手数料文書の「ノート」セクションに表示されます。

51

配分セットに関するFAQ

配分セットとは何ですか。配分セットは、その他入金、つまり非請求関連の入金を会計処理するために使用します。配分セットは、プラスのその他入金額の貸方勘定およびマイナスのその他入金額の借方勘定を決定するために定義する一般会計コードの組合せのグループです。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

52

19c

現預金のための売掛/未収金クレジットの実装

2 売掛/未収金システム・オプションの管理この章の内容は次のとおりです。

売掛/未収金システム・オプション設定に関するガイドラインヘッダー・レベル端数処理の例税金請求書印刷オプション自動インボイス調整セグメント自動インボイスのログ・ファイル・メッセージ・レベル売掛/未収金システム・オプションの管理に関するFAQEメール送信OAGIS 10.1およびUBL 2.1 XMLB2B XML詳細な売掛/未収金配分

売掛/未収金システム・オプション設定に関するガイドライン特定の売掛/未収金システム・オプション設定は、該当ビジネス・ユニットに対するReceivablesの動作に重要な影響を与えます。特定の売掛/未収金システム・オプションの設定方法を決定する前に、事前の計画を行うことが必要になる場合があります。

売掛/未収金システム・オプション設定に関する考慮事項は、次のとおりです。

営業担当ヘッダー・レベル端数処理

53

印刷済トランザクションの変更の許可割引

営業担当収益会計を使用する予定がある場合は、「営業担当必須」売掛/未収金システム・オプションを有効にする必要があります。収益会計では、収益または販売実績のいずれかで修正可能なすべてのトランザクションに販売実績を割り当てる必要があります。

「営業担当必須」売掛/未収金システム・オプションを有効にした場合は、「販売実績率限度」フィールドを使用して、営業担当がトランザクション明細に入力できる収益販売実績率と非収益販売実績率の限度を指定します。

「販売実績率限度」フィールドに値を入力しない場合、収益会計の処理中に販売実績限度の検証は実行されません。

ヘッダー・レベル端数処理自国の法的要件によっては、売掛/未収金勘定のトランザクション・ヘッダー・レベルで金額を端数処理した後、収益勘定ごとにこの端数処理済金額と端数処理済明細金額合計の差異を計上して別の勘定に転記する必要があります。これを行うには、「ヘッダー・レベル端数処理の使用」オプションを有効にし、「ヘッダー端数処理勘定」を定義します。

ヘッダー・レベルと明細レベルの端数処理の間の端数処理差異が、「ヘッダー端数処理勘定」に割り当てられます。

「ヘッダー・レベル端数処理の使用」オプションを有効にした場合、Receivablesでは、通貨に関係なくすべてのトランザクションの端数処理配分明細が表示されます。トランザクションの通貨が元帳通貨である場合、この明細の金額はゼロです。

「ヘッダー・レベル端数処理の使用」オプションを有効にしない場合は、明細レベルで金額が端数処理され、端数処理差異が売掛/未収金勘定に転記されます。

注意: 「ヘッダー・レベル端数処理」を有効にして売掛/未収金システム・オプション・レコードを保存した後で、該当するビジネス・ユニットの機能を無効にすることはできません。

印刷済トランザクションの変更の許可印刷されたトランザクションの更新を許可するには、「印刷済トランザクションへの変更の許可」オプションを有効にします。このオプションによって、印刷済、転記済または消込済のトランザクションが顧客の所在地に割り当てられているときに、その所在地を更新できるかどうかも決まります。

注意: トランザクションに対して活動がある場合、このオプションの設定に関係なく、そのトランザクションは更新できません。活動の例として、支払、クレジット・メモ、修正、繰越残高請求書へのトランザクションの割当などがあります。

54

割引Receivablesで期限外割引の受入を可能にするには、「期限外割引の許可」オプションを有効にします。期限外割引は、顧客が割引期間経過後に受ける割引です。該当ビジネス・ユニットに対して期限外割引の受入が可能かどうかは、売掛/未収金システム・オプション・レコードによってのみ決まります。

未回収借方品目への一部支払に対する割引を許可するには、「割引対象一部支払」オプションを有効にします。一部支払は、残りの未払額よりも少ない支払です。このオプションを有効にした場合でも、支払条件を定義するとき、トランザクション・レベルで一部支払に対する割引を許可しないことを選択できます。

一部支払に対する割引を許可することがない場合は、「割引対象一部支払」を有効にしないでください。

関連トピック

収益認識の実装設定割引の計算方法

ヘッダー・レベル端数処理の例この例では、ヘッダー・レベルの端数処理により通貨換算が処理され、端数処理差異が計上される方法を示します。

シナリオABC社は元帳通貨としてユーロを使用し、3つの明細品目を含む請求書をノルウェーのクローネで受け取ります。この例におけるクローネとユーロの換算レートは6.55957です。

トランザクションの詳細該当するビジネス・ユニットで「ヘッダー・レベル端数処理の使用」売掛/未収金システム・オプションが有効になっており、「ヘッダー端数処理勘定」が定義されています。

この表は、請求書の各明細金額を換算するために実行される計算を示しています。

品目/説明 金額(クローネ) 換算レート 金額(ユーロ) コメント

紙 15.00 6.55957 2.29 端数を切上げ

ペン 12.00 6.55957 1.83 端数を切上げ

封筒 25.00 6.55957 3.81 端数を切捨て

小計 52.00 N/A 7.93 品目の合計

端数処理差異 N/A N/A - 0.01 N/A

合計金額 52.00 6.55957 7.92 端数を切捨て

55

分析「ヘッダー・レベル端数処理の使用」売掛/未収金システム・オプションが有効になっているため、Receivablesは、売掛/未収金勘定に割り当てられたヘッダー・レベルでの合計請求書金額の通貨換算と、各収益勘定に割り当てられた明細レベルでの通貨換算合計との間の端数処理差異を計算する必要があります。この差異が、指定されたヘッダー端数処理勘定に転記されます。

換算結果Receivablesは、まず各明細品目をクローネからユーロに換算してから合計し、合計7.93 EURを算出します。次に、明細金額を請求書通貨(クローネ)で個別に加算してから元帳通貨に換算し、合計7.92 EURを算出します。

端数処理差異.01が、売掛/未収金システム・オプションで定義されているヘッダー端数処理勘定に割り当てられます。

税金請求書印刷オプション「税金請求書印刷オプション」売掛/未収金システム・オプションでは、Receivablesでトランザクションの税額の印刷に使用する方法を指定します。ここに入力した値が、顧客プロファイル区分のデフォルト値になります。

税金請求書印刷オプション欧州税フォーマット

明細ごとに税金情報を項目化しないで、税率を請求書明細の最後の列として印刷します。最後に運送費品目を印刷します。請求書の最後の税金名別の税要約セクションに、税率コードごとの課税対象額と請求税額の要約が示されます。

項目別にして集計

請求書明細ごとに税金情報を項目化します。請求書の最後の税金名別の税要約セクションに、税率コードごとの請求税額の要約が示されます。請求書の最後に、請求書の小計、税金、出荷額および請求書合計が印刷されます。

税金を項目別に示す

請求書明細ごとに税金情報を項目化します。

要約あり項目別

請求書明細ごとに税金情報を項目化します。請求書の最後の税金名別の税要約セクションに、税率コードごとの請求税額の要約が示されます。

56

要約

明細ごとに税金情報を項目化しません。請求書の最後の税金名別の税要約セクションに、税率コードごとの請求税額の要約が示されます。

税金の集計

明細ごとに税金情報を項目化しません。請求書の最後の税金名別の税要約セクションに、税率コードごとの請求税額の要約が示されます。請求書の最後に、請求書の小計、税金、出荷額および請求書合計が印刷されます。

税金名別に集計

明細ごとに税金情報を項目化しません。請求書の最後の税金名別の税要約セクションに、印刷された税名および税率ごとの請求税額の要約が示されます。

税額合計のみ

文書の最後に税額合計のみを表示します。

関連トピック

売掛/未収金トランザクションに対する税金処理の例トランザクションはどのように印刷しますか

自動インボイス調整セグメント売掛/未収金システム・オプションの作成および売掛/未収金システム・オプションの編集ページの「請求および収益」タブにある「自動インボイス: 調整セグメント」セクションを使用して、会計フレックスフィールドおよびシステム品目フレックスフィールドのセグメントを調整セグメントとして指定します。調整セグメントを使用すると、自動インボイスのパフォーマンスを改善できます。調整セグメントは、自動インボイスによって最も頻繁にアクセスされるセグメントです。

会計フレックスフィールド調整セグメント自動インボイスと、GL_CODE_COMBINATIONS表にすでに存在する索引のパフォーマンスを改善する必要がある場合は、索引に指定した値を会計フレックスフィールド調整セグメントとして使用します。連結索引を定義した場合は、連結索引の最初の列を使用します。

GL_CODE_COMBINATIONS表に索引が存在しない場合は、最も個別性の高い値を含むセグメントを会計フレックスフィールド調整セグメントとして入力します。

システム品目フレックスフィールド調整セグメント

57

自動インボイスと、MTL_SYSTEM_ITEMS表にすでに存在する索引のパフォーマンスを改善する必要がある場合は、索引に指定した値をシステム品目フレックスフィールド調整セグメントとして使用します。連結索引を定義した場合は、連結索引の最初の列を使用します。

MTL_SYSTEM_ITEMS表に索引が存在しない場合は、最も個別性の高い値を含むセグメントをシステム品目フレックスフィールド調整セグメントとして入力します。

自動インボイスのログ・ファイル・メッセージ・レベル「システム・オプションの作成」または「システム・オプションの編集」ページの「請求および収益」タブにある「自動インボイス」セクションの「ログ・ファイル・メッセージ・レベル」フィールドに、自動インボイス・ログ・ファイルに表示する詳細量を示す0から5までの値を入力します。

日常的なビジネス・ニーズへの対応やパフォーマンスの改善が目的の場合は、レベルを0に設定します。自動インボイスの実行中にエラーが継続的に発生する場合は、より高い出力レベルを設定して、ログに示されたエラーに関する詳細情報をレビューできます。

ログ・ファイルのメッセージ・レベルの定義メッセージ・レベル0では、ログ・ファイルに次のエントリが出力されます。

製品バージョンプログラム名自動インボイス開始時間自動インボイス・コンカレント要求引数エラーおよび警告のメッセージ自動インボイス終了時間自動インボイス論理ステップ

メッセージ・レベル1では、メッセージ・レベル0のすべてのエントリに加えて、次のものが出力されます。

タイムスタンプ機能ラベル

メッセージ・レベル2では、メッセージ・レベル0および1のすべてのエントリに加えて、次のものが出力されます。

割り当てられた配列のサイズ動的SQL文更新、挿入および削除された行数

メッセージ・レベル3では、メッセージ・レベル0、1および2のすべてのエントリに加えて、次のものが出力されます。

方法IV SQL配列値

58

メッセージ・レベル4では、メッセージ・レベル0、1、2および3のすべてのエントリに加えて、次のものが出力されます。

FNDまたは税金ルーチンの呼出しに使用されるすべての変数の値

メッセージ・レベル5では、メッセージ・レベル0、1、2、3および4のすべてのエントリに加えて、次のものが出力されます。

すべての不良明細および否認済明細の詳細。これにより、自動インボイスのCデバッグに必要なすべてのメッセージが提供されます。

売掛/未収金システム・オプションの管理に関するFAQ

転記間隔(日数)とは何ですか。「転記間隔(日数)」設定を使用すると、転記中にロールバック領域がなくならないように、転記するトランザクションをより小さいグループで処理できます。

たとえば、会計期間が30日で、この値を30に設定すると、転記プログラムでは1つのサイクルのみ使用されます。会計期間が30日で、この値を17に設定すると、転記プログラムでは2つのサイクルが使用されます。ベスト・プラクティスとしては、このフィールドには会計期間の日数より小さい数を設定します。

トランザクションの削除を許可するとどうなりますか。保存された売掛/未収金トランザクションをユーザーが削除できるようにする場合は、「トランザクション削除の許可」売掛/未収金システム・オプションを有効にします。このオプションを有効にしない場合、いずれの売掛/未収金ユーザーもトランザクションを削除できません。

トランザクション番号の欠番なしでトランザクションを順次採番することがインストールで法的に義務付けられている場合は、このオプションを有効にしないことがベスト・プラクティスです。

「トランザクション削除の許可」オプションを有効にした場合でも、機能セキュリティを使用して、トランザクションを削除できるユーザーを制御できます。

メモリー割当はどのようにして決定できますか。「最大メモリー(バイト)」フィールドに、検証のために自動インボイスに割り当てるメモリー量を表す値を入力します。デフォルトは65535バイトです。最善の結果を得るには、インポートするレコードの最大数を偶数に切り上げて、それを1024で乗算した値を入力します。たとえば、自動インボイスを使用して一度に100件を超えるレコードをインポートする場合は、値102400を入力します。

自動インボイスの処理中に、アプリケーションでメモリーの割当に失敗したことを示すメッセージを受け取った場合は、より小さい数値を入力します。メモリーが足りないというメッセージを受け取った場合は、より大きい数値を入力します。

59

どのような場合に「入金の自動適用までの日数」を使用しますか。「入金の自動適用までの日数」フィールドに、自動適用が顧客トランザクションに対する消込の対象とみなす入金の日齢を入力します。トランザクションの作成前に顧客が支払うことが多い場合は、このフィールドを使用します。

自動適用では、オープン入金を検索して、指定した日数内に作成されたトランザクションを消し込むことを試みます。たとえば、10を入力すると、過去10日以内に作成されたすべての入金がトランザクションへの消込の対象とみなされます。11日以上前に作成された入金は対象とみなされません。

このフィールドに値を入力しない場合、自動適用では入金の照合を1回のみ試行します。

例外ルール活動とは何ですか。アクティブな消込例外ルール・セットによって、入金消込後の超過支払額および過少支払額に対して実行する処理が決定されます。処理が請求修正または消込の場合、これらの支払の処理に使用するデフォルトの売掛/未収金活動を定義できます。

「売掛/未収金システム・オプション」の「現預金処理」タブにある「例外ルール修正活動」フィールドには、超過支払または過少支払に対する修正に使用するデフォルトの売掛/未収金活動が示されます。「例外ルール消込活動」フィールドには、超過支払または過少支払の消込に使用するデフォルトの売掛/未収金活動が示されます。

請求先サイトで入金が必要になるのはいつですか。請求先サイトを入金に関連付ける必要がある場合は、「入金処理時請求先事業所必須」売掛/未収金システム・オプションを有効にします。有効にした場合、Receivablesでは請求先サイトを持たない入金は作成されません。

このオプションは、取引明細書サイトのない顧客に使用します。このオプションを有効にしない場合、取引明細書サイトのない顧客に入金があり、請求先サイトがその入金に関連付けられていないと、この顧客の取引明細書のいずれにも入金の未消込金額は表示されません。

実現為替差益勘定および実現為替差損勘定と相互通貨端数処理勘定の違いは何ですか。実現為替差益および実現為替差損勘定は、相互通貨入金消込から発生する換算レート差損益を元帳通貨で計上するために使用されます。たとえば、外貨請求書の換算レートが1.7で、この請求書の支払の換算レートが2.0である場合、Receivablesはこの差異を差益として実現差益勘定に転記します。

相互通貨端数処理勘定は、相互通貨入金消込中に作成された端数処理エラー金額を記録するために使用されます。相互通貨入金を作成する場合は、端数処理エラー勘定を定義する必要があります。

60

Eメール送信

トランザクションおよび取引明細書の送信Eメールの件名の使用例売掛/未収金システム・オプションの「請求および収益」タブ・リージョンにある「Eメールを使用したトランザクション送信」および「Eメールを使用した取引明細書送信」セクションで、「Eメール件名」フィールドを使用します。

Receivablesでは、ビジネス・ユニット、トランザクション番号および取引明細書日付の後に期間が挿入され、各フィールド値の間にスペースが挿入されます。

次の例では、使用する設定に応じて件名がどのように表示されるかを示します。

例1

この表のように設定した場合、Eメールの件名は次のようになります。「請求書はレビューの準備が完了しています。Vision Operations。INV1234。」

フィールド 値

Eメール件名 請求書はレビューの準備が完了しています。

Eメール件名にビジネス・ユニットを含む 最終

Eメール件名にトランザクション番号を含む 最終

例2

この表のように設定した場合、Eメールの件名は次のようになります。「Vision Operations。取引明細書はレビューの準備が完了しています。01-01-2017。」

フィールド 値

Eメール件名 取引明細書はレビューの準備が完了しています。

Eメール件名にビジネス・ユニットを含む 最初

Eメール件名に取引明細書日付を含む 最終

例3

この表のように設定した場合、Eメールの件名は次のようになります。「請求書はレビューの準備が完了しています。INV1234。」

フィールド 値

Eメール件名 請求書はレビューの準備が完了しています。

Eメール件名にビジネス・ユニットを含む 含めない

61

Eメール件名にトランザクション番号を含む 最終

Eメールを使用したトランザクションおよび取引明細書の送信の仕組みEメールを使用して売掛/未収金トランザクションおよび明細を印刷し、指定された顧客に送信します。

「売掛/未収金トランザクションの印刷」プロセスまたは「顧客取引明細書の作成」プロセスを実行すると、それぞれのプロセスで、Eメール送信用に設定されている顧客アカウントおよびサイトの指定電子メール・アドレスに、トランザクションまたは取引明細書がPDFファイルまたはZip済PDFファイルとして送信されます。

Eメールを使用した送信に影響する設定

次の設定は、電子メールを使用した印刷送信に影響します。

印刷オプション: 「印刷オプション」は、特定の顧客サイトについて印刷する場合は顧客サイト・レベルで、顧客アカウントに属するすべてのサイトについて印刷する場合は顧客アカウント・レベルで、「印刷」または「印刷しない」に設定します。トランザクションにサイト・レベルまたはアカウント・レベルで有効な「印刷オプション」値がない場合、Receivablesはトランザクション・タイプに設定されている必要な「印刷オプション」を使用します。必要な場合は、トランザクションの「印刷オプション」設定を変更して、個々のトランザクションを印刷実行に含めたり、除外することができます。

注意: トランザクション・タイプの「未回収売掛/未収金」オプションが有効になっていない(つまり、無効トランザクションである)場合、Eメール送信プロセスでは、顧客サイト・レベルおよび顧客アカウント・レベルでの「印刷オプション」設定は無視され、トランザクション・タイプに割り当てられた設定が使用されます。その場合でも、トランザクションのこの設定を上書きできます。

優先送信方法: Eメールを使用した送信を、特定の顧客サイトについて行う場合は顧客サイト・レベルで、顧客アカウントに属するすべてのサイトについて行う場合は顧客アカウント・レベルで、「優先送信方法」フィールドを「Eメール」に設定します。顧客担当者: Eメール・アドレスと請求先目的または取引明細書目的の両方に、アカウント・レベルまたはサイト・レベルで少なくとも1人の顧客担当者を割り当てます。顧客担当者には次のルールが適用されます。

「売掛/未収金トランザクションの印刷」または「顧客取引明細書の作成」プロセスを実行するときは、その担当者がアクティブになっている必要があります。顧客アカウントまたはサイトにEメール・アドレスと請求先目的または取引明細書目的の両方を持つ担当者が存在しない場合、この顧客アカウントまたはサイトについてはトランザクションも取引明細書も送信されません。トランザクションについて、顧客アカウントまたはサイトにEメール・アドレスと請求先目的の両方を持つ担当者が存在するが、同じ担当者のEメール・アドレスに回収目的または督促目的も割り当てられている場合、この担当者はEメール送信から除外されます。取引明細書について、顧客に取引明細書サイトがある場合は、その顧客アカウントに属するすべての請求サイトに対して、連結された取引明細書が作成されて送信されます。

「Eメール」売掛/未収金システム・オプション: 「売掛/未収金システム・オプション」ページの「請求および収益」タブ・リージョンにある「Eメールを使用したトランザクション送信」および

62

「Eメールを使用した取引明細書送信」セクションを使用します。対応するフィールドに次の値を入力します。

送信元名: 企業の名前。送信元Eメール: 企業のEメール・アドレス。返信先Eメール: 顧客がEメールを送信できる宛先の企業のEメール・アドレス。Eメール件名: Eメールの件名のテキスト。Eメール件名にビジネス・ユニットを含む: ビジネス・ユニットの名前を件名に含めるためのオプション。Eメール件名にトランザクション番号を含む: トランザクション番号を件名に含めるためのオプション。Eメール件名に取引明細書日付を含む: 取引明細書日付を件名に含めるためのオプション。Eメール本文: Eメール・メッセージのテキスト。適切なフォーマットを含めます。

注意: これらはすべて条件付き必須フィールドです。トランザクションまたは取引明細書の印刷およびEメール送信を有効にする場合は、正常に送信できるように、これらのフィールドに値を入力しておく必要があります。

Eメールを使用したトランザクションおよび取引明細書の送信方法

設定が完了したら、顧客トランザクションを印刷する場合は「売掛/未収金トランザクションの印刷」プロセスを使用し、顧客取引明細書を印刷する場合は「顧客取引明細書の作成」プロセスを使用します。「出力ファイル・タイプ」パラメータを使用して、印刷実行で使用する出力を指定します。Eメールを使用して印刷を送信する場合、「PDF」または「Zip済PDF」を選択する必要があります。「Zip済PDF」を選択した場合、ファイルには、印刷された各トランザクションの最初と最後のページを識別する、印刷実行の索引ファイルが含められます。

トランザクションを作成すると、Receivablesにより「印刷オプション」の設定が参照され、次の順序でトランザクションに割り当てられます。

顧客サイト・プロファイル顧客アカウント・プロファイルトランザクション・タイプ

印刷処理中、Eメール送信プロセスでは、各トランザクションまたは取引明細書について次のことが確認されます。

トランザクションの場合、「印刷オプション」が「印刷」に設定されていること。「印刷オプション」の設定は、個々のトランザクションで印刷前に更新できます。顧客アカウントまたはサイトの「優先送信方法」フィールドが「Eメール」に設定されていること。少なくとも1人のアクティブな顧客担当者が、Eメール・アドレスと請求先目的または取引明細書目的の両方を持っていること。Eメール送信プロセスでは、トランザクションまたは取引明細書の送信先のEメール・アドレスは、次の順序で検索されます。

トランザクションの場合、トランザクションの請求先顧客担当者のEメール・アドレス。請求先目的または取引明細書目的が割り当てられているが、回収目的も督促目的も割り当てられていない顧客サイトの担当者のEメール・アドレス。請求先目的または取引明細書目的が割り当てられているが、回収目的も督促目的も割り当てられていない顧客アカウントの担当者のEメール・アドレス。

「売掛/未収金システム・オプション」の「請求および収益」タブ・リージョンにある「Eメールを使

63

用したトランザクション送信」または「Eメールを使用した取引明細書送信」セクション内のすべてのフィールドが入力されていること。

Eメールを使用して送信されるトランザクションに対する出力PDFファイルの名前の書式は、次のとおりです。

<INV_NUMBER>_<INSTALLMENT_NUMBER>.PDF

Eメール送信に関するFAQEメール送信を使用してトランザクションまたは取引明細書を印刷できないのはなぜですか。

Eメール送信の設定が完了していません。

この原因として可能性が高いのは、次の2つの設定のうちいずれかです。

売掛/未収金システム・オプションで、該当ビジネス・ユニットの「請求および収益」タブ・リージョンにある「Eメールを使用したトランザクション送信」または「Eメールを使用した取引明細書送信」セクションの「送信元Eメール」フィールドまたは「返信先Eメール」フィールドに、アクティブなEメール・アドレスを入力する必要があります。少なくとも1人の顧客担当者が、請求先目的または取引明細書目的の割当とアクティブなEメール・アドレスの両方を持っている必要があります。トランザクションの場合:

トランザクションに請求先顧客担当者がない場合、またはその担当者がEメール・アドレスを持っていない場合、Eメール送信プロセスでは、請求先目的とEメール・アドレスの両方を持つすべてのアクティブな顧客担当者が、アカウント・レベルまたはサイト・レベルで検索されます。そのような担当者が存在する場合、それらの担当者すべてにトランザクションが送信されます(ただし、同時に回収目的または督促目的も割り当てられている担当者Eメール・アドレスを除く)。存在しない場合、トランザクションは印刷されません。

OAGIS 10.1およびUBL 2.1 XML

ReceivablesでのOAGIS 10.1 XMLトランザクション送信の概要オープン・アプリケーション・グループ統合仕様(OAGIS) 10.1 XMLフォーマットを使用して、売掛/未収金トランザクションをXML文書として顧客に送信します。

XMLトランザクション送信では、コラボレーション・メッセージング・フレームワーク(CMK)を使用してトランザクションを顧客に送信し、顧客から確認メッセージを受信します。

Receivables OAGIS 10.1 XMLは、次の機能を提供します。

64

コラボレーション・メッセージング・フレームワークを使用して、請求書、クレジット・メモ、デビット・メモおよびチャージバックをOAGIS 10.1 XMLフォーマットで顧客(取引先)に送信します。サービス・プロバイダを使用して、または使用せずに、XMLトランザクションを取引先に送信します。確認ビジネス・オブジェクト文書(CBOD)を使用して、顧客からのトランザクション送信の承認を受信します。CBODでは、OAGIS 10.1 XMLフォーマットも使用されます。標準のマップ済属性以外に、ユーザー定義属性もXML文書に含めます。Receivablesでは、OAGIS 10.1XMLトランザクションの請求書ヘッダー・レベル、請求書明細レベルおよび請求書税金明細レベルでUserArea拡張属性を含めることがサポートされています。トランザクション・ヘッダー・レベルの添付をOAGIS 10.1 XML送信に含めます。コラボレーション・メッセージング・フレームワークを使用してXMLトランザクション送信をレビューします。

機能設定マネージャ(FSM)の機能オプトイン・ページを使用して、「オープン・アプリケーション・グループ統合仕様(OAGIS) 10.1 XMLフォーマットでの売掛/未収金請求書送信」を有効にします。

Universal Business Language (UBL) 2.1 XMLトランザクション送信を有効にする場合も、同じ機能オプトインを使用します。

次に、Receivablesおよびコラボレーション・メッセージング・フレームワーク(CMK)で、OAGIS 10.1またはUBL 2.1 XMLトランザクションを顧客に送信するための関連設定を完了する必要があります。

これらの設定は、関連するReceivablesおよびコラボレーション・メッセージング・フレームワークの設定タスクを使用して完了します。サービス・プロバイダを使用してXML文書を送信する場合は、顧客インポートFBDIテンプレートを使用して、XMLトランザクション送信に必要なCMK設定と、関連する売掛/未収金顧客アカウント・プロファイル情報の両方をインポートすることもできます。

注意: サービス指向アーキテクチャ(SOA) BtoB (B2B)ゲートウェイを介して既存の売掛/未収金XML請求を使用している場合は、顧客がトランザクションをOAGIS 10.1 XMLフォーマットで受信する準備が整ったときにのみ、OAGIS 10.1 XMLトランザクション送信に切り替える必要があります。切り替えたときには、コラボレーション・メッセージング・フレームワークでサービス・プロバイダおよび取引先の設定を再実行する必要があります。

ReceivablesでのUBL 2.1 XMLトランザクション送信Universal Business Language (UBL) 2.1 XMLフォーマットを使用して、売掛/未収金トランザクションをXML文書として顧客に送信します。

現在、一部の国では、企業と政府間の電子請求処理でUBL 2.1フォーマットの使用が義務付けられています。

OAGIS 10.1の場合と同様に、UBL 2.1 XMLトランザクション送信では、コラボレーション・メッセージング・フレームワーク(CMK)を使用してトランザクションを顧客に送信し、顧客から確認メッセージを受信します。

Universal Business Language (UBL) 2.1 XMLフォーマットの構成方法

UBL 2.1 XMLトランザクション送信を使用するには、機能設定マネージャの機能オプトイン・ページで「オープン・アプリケーション・グループ統合仕様(OAGIS) 10.1 XMLフォーマットでの売掛/未収金請求書

65

送信」機能を有効にする必要があります。これにより、Universal Business Language (UBL) 2.1フォーマット機能がデフォルトで有効になります。

OAGIS 10.1 XMLトランザクション送信に必要なすべての設定を完了する必要がありますが、UBL 2.1XMLの場合は次の変更点と制限があります。

「コラボレーション・メッセージング・サービス・プロバイダの管理」タスクで、CMKでUBL 2.1XMLに対してサポートされている送信方法タイプは、「B2Bアダプタ」および「Eメール」です。「コラボレーション・メッセージング・サービス・プロバイダの管理」タスクで、CMKにおけるUBL 2.1 XMLのアウトバウンド・コラボレーション・メッセージ定義は、UBL_2.1_INVOICE_OUTです。売掛/未収金XML機能のユーザー定義属性機能を使用して、UBL 2.1 XMLトランザクションに追加属性を含めることができます。追加属性をUBL 2.1 XMLトランザクションにマップするには、「コラボレーション・メッセージング・フレームワーク」作業領域からアクセス可能な「コラボレーション・メッセージ定義の管理」タスクを使用して、デフォルトのUBL 2.1 XSLTを変更します。

注意: CMKでサポートされている送信方法以外を使用してUBL 2.1 XMLトランザクションを送信する場合、またはUBL 2.1請求書に証明書と署名を追加する必要がある場合は、サード・パーティのサービス・プロバイダを使用する必要があります。

OAGIS 10.1 XMLトランザクション送信のためのReceivablesの設定OAGIS 10.1 XMLフォーマットでの顧客へのトランザクション送信を可能にする実装の一部として、OAGIS10.1 XMLトランザクション送信のためにReceivablesを設定します。

Receivablesの設定を完了するとともに、コラボレーション・メッセージング・フレームワークで関連設定を完了する必要もあります。両方の製品で設定を完了すると、XMLトランザクション送信を使用できるようになります。

OAGIS 10.1 XMLトランザクション送信のためにReceivablesを設定するには、次のタスクを実行します。

顧客アカウント・プロファイルでXML請求を設定します。XMLトランザクション用の添付カテゴリを設定します(オプション)。

注意: これらの設定を完了する前に、機能設定マネージャの機能オプトイン・ページを使用して、「オープン・アプリケーション・グループ統合仕様(OAGIS) 10.1 XMLフォーマットでの売掛/未収金請求書送信」機能を有効にしておく必要があります。OAGIS 10.1 XMLトランザクション送信を有効にすると、Universal Business Language (UBL) 2.1 XMLトランザクション送信も有効になります。

顧客アカウント・プロファイルのXML請求の設定

XMLトランザクション送信の取引先として定義する顧客の売掛/未収金顧客アカウント・プロファイルを設定します。使用する設定は、その顧客アカウントに属するすべてのサイトに適用されます。

XMLトランザクション送信の顧客アカウントを設定する手順は、次のとおりです。

1. 「請求」作業領域にナビゲートします。

66

2. 「顧客の管理」タスクを選択します。3. 「顧客の管理」ページで、XMLトランザクション送信を有効にする顧客を検索します。4. 「アカウントの編集」ページで、「プロファイル履歴」タブをクリックします。5. 「請求」セクションで、「優先送信方法」を「XML」に設定します。6. この顧客の該当トランザクションに対して「XML請求の使用可能」のチェック・ボックス(「請求書」、「デビット・メモ」、「チャージバック」、「クレジット・メモ」)を選択します。この顧客アカウントに対して「XMLトランザクションの生成および転送」プロセスを実行するたびに、Receivablesによってすべての適格なトランザクションが選択されます。

7. 作業内容を保存します。8. 該当する各顧客アカウントについて、ステップ3から7を繰り返します。

XMLトランザクション用の添付カテゴリの設定

オプションで、XMLトランザクションにトランザクション・ヘッダー添付を含めるための添付カテゴリを定義できます。

「XMLトランザクションの生成および転送」プロセスの実行中、定義したXML添付カテゴリに関連付けられているトランザクションへの添付がOAGIS 10.1 XMLに埋め込まれます。

XMLトランザクション用の添付カテゴリを設定する手順は、次のとおりです。

1. 「設定および保守」作業領域にナビゲートします。2. 「添付カテゴリの管理」タスクを選択します。3. 「添付カテゴリの管理」ページで、プラス(+)アイコンをクリックして、新規の添付カテゴリを作成します。

注意: 既存の添付カテゴリを使用することもできます。

4. XMLトランザクション添付カテゴリの各フィールドに入力します。次に例を示します。カテゴリ名: XML_INVOICEユーザー名: XML請求書摘要: XML請求書ヘッダーに埋め込まれる添付

5. 「添付エンティティ」セクションで、プラス(+)アイコンをクリックします。6. 「エンティティ名」フィールドに、RA_CUSTOMER_TRX_ALLを入力して、添付をトランザクション・ヘッダーに関連付けます。

7. 作業内容を保存します。8. 「売掛管理プロファイル・オプションの管理」タスクを選択します。次に、添付カテゴリを、添付を印刷するための「請求提示」プロファイル・オプション(AR_BPA_PRINT_ATTACH_CATEGORY)に関連付けます。

9. 「売掛管理プロファイル・オプションの管理」ページで、AR_BPA_PRINT_ATTACH_CATEGORYプロファイル・オプションを検索します。

10. 「プロファイル値」セクションで、プラス(+)アイコンをクリックします。11. 「プロファイル・レベル」フィールドに、「サイト」と入力します。12. 「プロファイル値」フィールドに、ステップ4で定義した添付カテゴリの名前を入力します。13. 作業内容を保存します。

このサイト・プロファイル値を使用すると、トランザクション・ヘッダーのAR_BPA_PRINT_ATTACH_CATEGORYカテゴリに属する添付をXMLトランザクションに埋め込むことができます。

67

14. 「トランザクションの作成」ページの「添付」ウィンドウで、作成してAR_BPA_PRINT_ATTACH_CATEGORYプロファイル・オプションと関連付けた添付カテゴリを使用して、XMLトランザクションに含める添付を追加します。

OAGIS 10.1 XMLトランザクション送信のためのコラボレーション・メッセージングの設定XMLフォーマットでの顧客へのトランザクション送信を可能にする実装の一部として、OAGIS 10.1 XMLトランザクション送信のためにコラボレーション・メッセージング・フレームワークを設定します。

コラボレーション・メッセージング・フレームワークの設定を完了するとともに、Receivablesで関連設定を完了する必要もあります。両方の製品で設定を完了すると、OAGIS 10.1 XMLトランザクション送信を使用できるようになります。

コラボレーション・メッセージングの設定では、オーダー-入金文書用にコラボレーション・メッセージングを有効にし、サービス・プロバイダと取引先を作成して、さらにそれらを取引先顧客アカウントと関連付けます。

XMLトランザクション送信のためにコラボレーション・メッセージングを設定するには、次のタスクを実行します。

Receivablesでのコラボレーション・メッセージングの有効化。サービス・プロバイダの設定。B2B取引先の設定。サービス・プロバイダおよび取引先の顧客アカウントとの関連付け。

注意: これらの設定を完了する前に、機能設定マネージャの機能オプトイン・ページを使用して、「オープン・アプリケーション・グループ統合仕様(OAGIS) 10.1 XMLフォーマットでの売掛/未収金請求書送信」機能を有効にしておく必要があります。

Receivablesでのコラボレーション・メッセージングの有効化

アウトバウンド・メッセージ処理を構成し、「オーダー-入金」ビジネス・プロセスを有効にします。

Receivablesでコラボレーション・メッセージングを有効にする手順は、次のとおりです。

1. 「設定および保守」作業領域にナビゲートします。2. 「コラボレーション・メッセージング構成の管理」タスクを選択します。3. 「コラボレーション・メッセージング構成の管理」ページの「一般設定」タブ・リージョンで、「グローバル送信者ID」フィールドに会社識別子を入力します。この識別子は、サービス・プロバイダおよび取引先が自分をXMLトランザクションの送信者として識別するために使用します。

4. XMLトランザクションとともに添付を送信する場合は、「最大添付サイズ」フィールドに、XMLトランザクションに埋め込むことができる添付の最大サイズ(MB)を入力します。トランザクション・ヘッダー内の添付のサイズがこの制限を超えると、その添付はXMLトランザクション送信に埋め込まれません。

5. 「ビジネス・プロセス設定」タブをクリックします。6. 「コラボレーション・ビジネス・プロセス」表で、「オーダー-入金」ビジネス・プロセスに対し

68

て「使用可能」ボックスを選択します。7. 作業内容を保存します。

サービス・プロバイダの設定

「コラボレーション・メッセージング・サービス・プロバイダの管理」タスクを使用して、サービス・プロバイダを作成します。サービス・プロバイダは、Oracle Applications Cloudと取引先(顧客)の間でメッセージを交換する仲介役です。

サービス・プロバイダごとに、OAGIS 10.1 XMLトランザクション送信の送信方法、アウトバウンド・コラボレーション・メッセージおよびインバウンド・コラボレーション・メッセージを定義します。

注意: サービス・プロバイダを使用せずにXMLトランザクションを取引先に直接送信する場合は、このタスクをスキップして、B2B取引先を設定するタスクを完了し、サービス・プロバイダおよび取引先を顧客アカウントに関連付けます。

サービス・プロバイダを設定する手順は、次のとおりです。

1. 「設定および保守」作業領域にナビゲートします。2. 「コラボレーション・メッセージング・サービス・プロバイダの管理」タスクを選択します。3. 「コラボレーション・メッセージング・サービス・プロバイダの管理」ページで、プラス(+)アイコンをクリックして、「コラボレーション・メッセージング・サービス・プロバイダの作成」ウィンドウを開きます。

4. 「名前」フィールドに、サービス・プロバイダに使用する名前を入力します。5. 「プロバイダID」フィールドに、サービス・プロバイダの識別子を入力します。6. 「IDタイプ」フィールドで、「一般」を選択します。7. 「摘要」フィールドに、XMLトランザクション送信用のこのサービス・プロバイダを識別する摘要を入力できます。

8. 「保存してクローズ」ボタンをクリックします。9. 「コラボレーション・メッセージング・サービス・プロバイダの編集」ページで、「配信方法」タブをクリックします。

10. プラス(+)アイコンをクリックして、送信方法の行を開きます。11. 「名前」フィールドに、サービス・プロバイダとの契約に従って、XMLメッセージ送信方法の名前

を入力します。12. 「配信方法タイプ」フィールドで、次のように選択します。

OAGIS 10.1 XMLの場合、「Webサービス」を選択します。UBL 2.1 XMLの場合、「B2Bアダプタ」または「Eメール」を選択します。

13. 「サービス名」フィールドで、同期サービスの場合は「CollaborationMessage.Process」を選択し、非同期サービスの場合は「CollaborationMessage.ProcessAsync」を選択します。

14. ビジネス要件に従って、送信方法の残りのフィールドに入力します。15. 「アウトバウンド・コラボレーション・メッセージ」タブをクリックします。16. プラス(+)アイコンをクリックして、アウトバウンド・コラボレーション・メッセージの行を開きま

す。17. 「名前」フィールドに、このアウトバウンド・コラボレーション・メッセージを識別する名

前(AR_Invoiceなど)を入力します。18. 「コラボレーション・メッセージ」フィールドで、次のように選択します。

69

アウトバウンドOAGIS XMLトランザクション送信の場合は、OAGIS_10.1_PROCESS_INVOICE_COLLAB_MSG_OUT。アウトバウンドUBL 2.1 XMLトランザクション送信の場合、UBL_2.1_INVOICE_OUT。

19. 「ステータス」フィールドで、「アクティブ」を選択します。20. 「配信方法名」フィールドに、「配信方法」タブで定義したXMLメッセージ送信方法を入力しま

す。21. サービス・プロバイダが受信したXMLトランザクションに対して確認をOAGIS 10.1 CBODフォー

マットで送信することに同意した場合は、「インバウンド・コラボレーション・メッセージ」タブをクリックして、インバウンド・コラボレーション・メッセージを定義します。

22. プラス(+)アイコンをクリックして、インバウンド・コラボレーション・メッセージの行を開きます。

23. 「名前」フィールドに、このインバウンド・コラボレーション・メッセージを識別する名前(AR_CBODなど)を入力します。

24. 「コラボレーション・メッセージ」フィールドで、「OAGIS_10.1_CONFIRM_BOD_COLLAB_MSG_IN」を選択します。

25. 「ステータス」フィールドで、「アクティブ」を選択します。26. 「アウトバウンド・コラボレーション・メッセージ」タブを再度クリックします。27. 「ステータス」フィールドで、「非アクティブ」を選択します。

これにより、アウトバウンド・コラボレーション・メッセージ内の各フィールドを編集できます。28. 確認メッセージ名フィールドに、定義したばかりのCBODメッセージの名前を入力します。

これにより、XMLトランザクションの確認応答を受信するように、インバウンドCBODメッセージがアウトバウンド・トランザクション・メッセージに関連付けられます。

29. 「ステータス」フィールドで、「アクティブ」を選択します。30. 作業内容を保存します。

B2B取引先の設定

取引先は、売掛/未収金トランザクションをXMLフォーマットで受信するために指定する顧客です。各取引先が、(自分とサービス・プロバイダが認識できる)取引先識別子を持つ必要があります。この識別子はXMLメッセージに含められ、XML文書を受信する取引先をサービス・プロバイダが識別するために使用されます。

また、XMLトランザクション送信の取引先として定義する顧客ごとに、売掛/未収金顧客アカウント・プロファイルを設定する必要もあります。

取引先の作成後、サービス・プロバイダに定義したアウトバウンド・コラボレーション・メッセージおよびインバウンドCBODコラボレーション・メッセージを取引先に関連付ける必要があります。

取引先を設定する手順は、次のとおりです。

1. 「コラボレーション・メッセージング」作業領域にナビゲートします。2. 「B2B取引先の管理」タスクを選択します。3. 「B2B取引先の管理」ページで、プラス(+)アイコンをクリックして、「取引先の作成」ウィンドウを開きます。

4. 「サービス・プロバイダ」フィールドで、XML送信でこの取引先に対して使用するサービス・プロバイダを選択します。サービス・プロバイダを使用せずにXMLトランザクションを取引先に直接送信する予定がある場合

70

は、「なし」を選択します。5. 「取引先ID」フィールドに、取引先の識別子を入力します。6. 「パートナIDタイプ」フィールドで、取引先識別子のカテゴリを選択します。有効な値は、「D-U-N-S」、「一般」(取引先の識別に顧客アカウント番号を使用する場合)、「GLN」、「MISC」、PHONE、TAXID、「名前」(取引先の識別に顧客アカウント名を使用する場合)です。

7. 「保存してクローズ」ボタンをクリックします。8. 「取引先の編集」ページの「サービス・プロバイダ用のコラボレーション文書」セクションで、「文書」列に、このサービス・プロバイダに対するアウトバウンド・コラボレーション・メッセージおよびインバウンドCBODコラボレーション・メッセージを入力します。

9. 作業内容を保存します。

サービス・プロバイダおよび取引先の顧客アカウントとの関連付け

サービス・プロバイダおよび取引先を設定した後は、サービス・プロバイダと取引先の両方を関連する顧客アカウントに関連付けます。

サービス・プロバイダを使用せずにXMLトランザクションを取引先に直接送信する予定がある場合でも、サービス・プロバイダの値「なし」を、関連する顧客アカウントに関連付ける必要があります。

サービス・プロバイダおよび取引先を顧客アカウントに関連付ける手順は、次のとおりです。

1. 「コラボレーション・メッセージング」作業領域にナビゲートします。2. 「顧客アカウント・コラボレーション構成の管理」タスクを選択します。3. 「顧客アカウント・コラボレーション構成の管理」ページで、目的の顧客アカウントを検索します。

4. 顧客アカウントを選択し、「コラボレーション構成の編集」ボタンをクリックします。5. 「顧客アカウント・コラボレーション構成の編集」ページの「関連サービス・プロバイダ」セクションで、プラス(+)アイコンをクリックして、サービス・プロバイダの行を開きます。

6. サービス・プロバイダおよび関連する取引先IDを入力します。これにより、サービス・プロバイダおよび取引先が顧客アカウントに関連付けられます。

7. 「サービス・プロバイダ用のコラボレーション文書」セクションで、プラス(+)アイコンをクリックして、コラボレーション文書の行を開きます。

8. 「文書」フィールドに、サービス・プロバイダと関連付けるアウトバウンド・コラボレーション・メッセージを入力します。インバウンドCBODコラボレーション・メッセージは、すでにサービス・プロバイダに関連付けられているため、入力する必要はありません。

9. 関連ステータス・フィールドで、「使用可能」を選択します。10. 作業内容を保存します。

関連トピック

取引先の作成サービス・プロバイダを使用しない取引先の作成顧客アカウントのコラボレーション・メッセージングの構成

顧客インポートFBDIを使用したOAGIS 10.1 XMLトランザク

71

ション送信の設定データのインポート顧客インポートFBDI (ファイルベース・データ・インポート)を使用して、OAGIS 10.1 XMLトランザクション送信のための特定の設定を完了します。

顧客インポート・テンプレートのRA_CUSTOMER_PROFILES_INT_ALLワークシートを使用して、コラボレーション・メッセージング・フレームワークおよびReceivablesでの次の設定を完了できます。

コラボレーション・メッセージング: B2B取引先。コラボレーション・メッセージング: 顧客アカウント・コラボレーション構成。Receivables: 顧客アカウント・プロファイル。既存の顧客アカウント・プロファイルを更新するか、新規の顧客アカウント・プロファイルを作成できます。

このワークシートのデータは、Receivablesに転送するためにRA_CUSTOMER_PROFILES_INT_ALLインタフェース表にインポートされます。

注意: サービス・プロバイダを使用してXML文書を送信する場合は、顧客インポートFBDIを使用しないと、OAGIS 10.1 XMLトランザクション送信のための設定データをインポートできません。

顧客インポート・テンプレートを使用して設定データをインポートする前に、次のタスクを完了しておく必要があります。

機能設定マネージャの機能オプトイン・ページを使用して、「オープン・アプリケーション・グループ統合仕様(OAGIS) 10.1 XMLフォーマットでの売掛/未収金請求書送信」機能を有効にします。「コラボレーション・メッセージング・サービス・プロバイダの管理」タスクを使用して、XMLトランザクション送信用のサービス・プロバイダを作成します。

XMLトランザクション送信のための設定データをインポートする手順は、次のとおりです。

1. 顧客インポート・テンプレートをダウンロードします。2. 「RA_CUSTOMER_PROFILES_INT_ALL」タブをクリックします。

RA_CUSTOMER_PROFILES_INT_ALLワークシートに、売掛/未収金顧客アカウント・プロファイルの列が表示されます。デフォルトでは、コラボレーション・メッセージングの列は非表示です。

3. 次のようにして、コラボレーション・メッセージングの列を表示します。a. クレジット・メモのXML請求列および次の列を強調表示します。b. 右クリックして、コラボレーション・メッセージングの列を表示します。

4. コラボレーション・メッセージングの各列に、次のように入力します。a. コラボレーション・メッセージング構成の有効化: 顧客アカウントのコラボレーション・メッセージング設定データをインポートする場合は、「Y」を選択します。

b. サービス・プロバイダ名: 「コラボレーション・メッセージング・サービス・プロバイダの管理」タスクを使用して定義したサービス・プロバイダの名前を入力します。

c. 取引先ID: XMLトランザクションを受信する取引先としての顧客アカウントを識別するコードを入力します。

d. 取引先IDタイプ: 取引先識別子のカテゴリを選択します。有効な値は、「D-U-N-S」、「一般」(取引先の識別に顧客アカウント番号を使用する場合)、「GLN」、「MISC」、PHONE、TAXID、「名前」(取引先の識別に顧客アカウント名を使用する場合)です。

e. 売掛/未収金アウトバウンドXMLトランザクション文書: 取引先が売掛/未収金トランザクショ

72

ンをXMLフォーマットで受信できることを指定する場合は、「Y」を選択します。f. 売掛/未収金インバウンド確認文書: 取引先がXMLトランザクションの受信後に確認BODを返信できることを指定する場合は、「Y」を選択します。

5. 要件に従って、売掛/未収金顧客アカウント・プロファイル列に値を入力します。6. 「データ・インポート・バッチ」を発行して、Receivablesおよびコラボレーション・メッセージングの設定データを対応する表にインポートします。

B2B XML

ReceivablesでのB2B XML請求Oracle B2Bアウトバウンド・サービスを使用して、売掛/未収金トランザクションをXMLフォーマットで指定の顧客に電子送信します。Oracle B2Bは、企業と顧客の間のやり取りを管理するSOA Suiteコンポーネントです。

トランザクションをXMLフォーマットで受信するよう指定された顧客を、取引先と呼びます。Oracle B2Bで顧客取引先を設定し、次のいずれかの伝送方法を使用してXMLトランザクションを送信します。

顧客に直接送信。Oracle Supplier Networkを使用。サード・パーティ・サービスを使用。

Receivablesで、アカウント・プロファイルの「請求」セクションを使用して、B2B XML用の関連顧客アカウントを設定する必要があります。使用する設定は、その顧客アカウントに属するすべてのサイトに適用されます。

B2B XML請求用の顧客アカウントを設定する手順は、次のとおりです。

1. 「勘定科目プロファイル」タブの「請求」セクションにある「優先送信方法」フィールドで、「XML」を選択します。

2. 「B2B取引パートナ・コード」フィールドに、取引先の接続識別子を入力します。該当する場合は、同じ取引先コードを複数の顧客アカウントに割り当てることができます。

注意: これは、XML送信では必須の値です。接続識別子を入力しない場合、トランザクションをXMLフォーマットでこの顧客アカウントに送信できません。

3. 「XML請求の使用可能」チェック・ボックスを使用して、XMLフォーマットでこの取引先に送信するトランザクションを選択します。この顧客アカウントに対してXML請求プログラムを実行するたびに、Receivablesによってすべての適格なトランザクションが選択されます。

B2B XML請求用の顧客アカウントを設定した後、XML請求書テンプレートを使用して、売掛/未収金属性をテンプレートのユーザー領域セクション内の属性にマッピングすることにより、請求書出力に含める情報を拡張できます。

設定が完了したら、XML請求プログラムを使用して、顧客トランザクションをXMLフォーマットで送信します。伝送プロセス中にトランザクションが失敗した場合は、「トランザクションの管理」ページを使用して、失敗したトランザクションをレビューし、訂正処理に進みます。その後、XML請求プログラムを使用し

73

て、これらのトランザクションを再送信できます。

ReceivablesでのXMLトランザクションXML請求プログラムを使用して、売掛/未収金トランザクションを顧客取引先に送信します。

送信するトランザクションには次の制約が適用されます。

トランザクションがXML請求用に設定された顧客アカウントに属していること。トランザクションが完了していること。トランザクションのステータスが「印刷待ち」になっていること。関連する顧客アカウント・プロファイルで、トランザクション(請求書、クレジット・メモ、デビット・メモ、チャージバック)のXML請求が有効になっていること。トランザクションでトランザクション・タイプの印刷オプションが「印刷」に設定されていること。

新規トランザクション

新規トランザクションをXMLフォーマットで顧客に送信するには、「含まれるトランザクション」フィールドで「新規トランザクションのみ」を選択します。すべてのビジネス・ユニットおよび顧客に対して適格なすべてのトランザクションを処理することも、ニーズに応じて使用可能なパラメータを使用して処理対象のトランザクションを制限することもできます。

失敗したトランザクション

伝送プロセス内の3つのステージのいずれかで、トランザクションが正しく伝送されない場合があります。

次の3つのステージがあります。

売掛/未収金プロセスSOAプロセスB2Bプロセス

次の表では、B2B XML伝送プロセスの各ステージで発生する可能性があるエラーを示します。

XML

プロセス エラー条件 エラー通知 訂正処理

売掛/未収金

顧客アカウントにB2B取引先コードがありません。

トランザクションに「失敗」のマークが付き、対応するエラー事由が示されます。

B2B取引先コードを適切なアカウントに追加します。

SOA 売掛/未収金システムまたはサーバーが停止しています。

トランザクションは処理されなかったため、マークは付きません。システム・エラーはEMコンソールでのみ通知されます。

システム管理者がトランザクションのSOAを再起動します。

SOA 変換エラー。 トランザクションに「失敗」のマークが付き、対応するエラー事由が示されます。

システム管理者が変換エラーを修正します。

SOA B2Bサーバーが停止しています。

トランザクションに「失敗」のマークが付き、対応するエラー事由が示されます。

システム管理者がB2Bサーバーを再起動します。

74

B2B B2B設定が完了していないか、正しくありません。

トランザクションに「失敗」のマークが付き、対応するエラー事由が示されます。

B2B管理者がB2B設定エラーを修正します。

売掛/未収金XMLトランザクションを送信するためのOracleB2Bの設定Oracle B2B Serverは、当該会社と取引先の間のやり取りを管理するOracle SOA Suiteコンポーネントです。Oracle Receivablesでは、Oracle B2B Serverを使用してトランザクションをXMLフォーマットで顧客取引先に送信するためのアウトバウンドOracle B2Bフローをサポートしています。

ReceivablesのOracle B2Bフローの設定では、次の既存の要素が使用されます。

XMLスキーマ文書のガイドラインOAG-7.2.1-PROCESS_INVOICE_002-OAG_DEF文書定義ホスト取引先MyCompany

売掛/未収金トランザクションをXMLで送信するためにOracle B2Bを設定する手順は、次のとおりです。

ホスト取引先とリモート取引先の構成ホスト取引先とリモート取引先の間の契約の構成

取引先の構成

自社をホスト取引先として構成し、XML文書を受信するすべての顧客をリモート取引先として構成します。

取引先を構成する手順は、次のとおりです。

1. Oracle B2Bサーバーにログインします。2. 「管理」ページにナビゲートします。3. 「文書」タブをクリックします。4. OAG-7.2.1-PROCESS_INVOICE_002-OAG_DEF文書定義ファイルをロードします。5. 「タイプ」タブをクリックします。6. 「B2B取引パートナ・コード」という名前の新しい内部識別子を追加します。この名前は、顧客アカウント・プロファイルのフィールド名と一致します。

7. 「パートナ」ページにナビゲートします。8. 「パートナ」セクションで、デフォルトのホスト・パートナ「MyCompany」を選択します。9. 必要に応じて、デフォルトのホスト・パートナ名を、実際の企業を反映した名前に更新します。

10. 「ドキュメント」タブをクリックします。11. OAG-7.2.1-PROCESS_INVOICE_002-OAG_DEF文書定義がホスト取引先に割り当てられていることを

確認します。12. 「送信者」オプションが有効になっていることを確認します。13. 「パートナ」セクションで、「追加」アイコンをクリックします。14. リモート取引先の名前を入力します。15. 以前に作成した内部識別子タイプのB2B取引先コードを選択して、識別子の値を入力します。

この値が、このリモート取引先の顧客アカウント・プロファイルの「B2B取引パートナ・コード」フィールドに入力する値です。

75

16. 「ドキュメント」タブをクリックします。17. 「追加」アイコンをクリックして、OAG-7.2.1-PROCESS_INVOICE_002-OAG_DEF文書定義をリモー

ト取引先に関連付けます。18. 「受け側」オプションを有効にします。19. 「チャネル」タブをクリックします。20. リモート取引先のチャネルを定義します。

このチャネルにより、XMLトランザクションをB2Bからリモート取引先に送信する方法(直接、Oracle Supplier Network (OSN)を使用、またはサード・パーティ・サービスを使用)が決まります。Oracle Supplier Network (OSN)を使用して通信している場合は、一般識別子を選択してOSNのIPアドレスを入力します。

21. 各リモート取引先について、ステップ13から20を繰り返します。

契約の構成

取引先契約では、2つの取引先(送り側と受け側)がビジネス文書を交換できるようにするための条件が定義されています。この契約に、取引先、取引先識別子、文書定義およびチャネルが示されます。

契約は、ホスト取引先および1つのリモート取引先の2つの取引先で構成され、これらの取引先間におけるビジネス・トランザクションの1つのタイプを表します。たとえば、ホスト取引先MyCompanyとリモート取引先ABC Solutionsが購買オーダーと請求書の両方を定期的に交換する場合、各文書定義に対して2つの個別契約が必要になります。

ホスト取引先とリモート取引先の間の契約を構成する手順は、次のとおりです。

1. Oracle B2Bサーバーにログインします。2. 「パートナ」ページにナビゲートします。3. 「契約」セクションで、「追加」アイコンをクリックして、ホスト取引先MyCompanyの新しい契約を開きます。

4. 契約のIDと名前を入力します。5. 契約パラメータを入力します。6. この契約の文書定義「OAG-7.2.1-PROCESS_INVOICE_002-OAG_DEF」を選択します。7. この契約に含めるリモート取引先を選択します。8. リモート取引先のチャネルを選択します。9. リモート取引先の識別子を追加します。

10. 「保存」をクリックして、契約を保存します。11. 「検証」をクリックして、契約を検証します。12. 「デプロイ」をクリックして、契約をデプロイします。

デプロイメントは、契約を設計時リポジトリから実行時リポジトリにアクティブ化するプロセスです。

13. ホスト取引先とこのリモート取引先の間の各契約について、ステップ3から12を繰り返します。

B2B XMLに関するFAQ

プロファイル区分でB2B XMLを構成できないのはなぜですか。

76

B2B XML請求パラメータは、関連する顧客アカウント・プロファイル内で構成および保守します。顧客サイトは、関連する顧客アカウントの設定を共有します。

詳細な売掛/未収金配分

詳細な売掛/未収金配分の概要詳細な売掛/未収金配分は、トランザクション、修正および入金を複数の貸借一致セグメント値または資金に転記できるようにする、オプションの会計機能です。詳細な売掛/未収金配分機能は、マルチファンド会計とも呼ばれます。

デフォルトの会計モデルでは、1つのトランザクションの複数の収益、運送費および税金明細が連結され、1つの配分明細として計上されます。ビジネス・ユニットおよび元帳に対して詳細な売掛/未収金配分が有効になっている場合、会計プロセスでは、勘定科目コード組合せの貸借一致セグメント値に従って、各トランザクション明細の詳細配分が作成されます。

詳細な売掛/未収金配分を使用して、各貸借一致セグメント値の入金および使用をモニターし、トラッキングできます。これにより、たとえば、一般運営資金、寄付基金、贈与資金など、特定の公共部門プロジェクトをサポートする資金の支出を管理できます。あるいは、ディビジョン、部門および製品別ごとに別々の請求書を作成する必要なく、組織の財務情報をモニターおよび抽出できます。

詳細な売掛/未収金配分の使用は、新規のビジネス・ユニットおよびプライマリ元帳の設定にのみ関連します。詳細配分が適用される活動は、標準入金とその他入金、請求書、クレジット・メモ、デビット・メモおよび修正のみです。

次の各表に、請求書の詳細配分の作成例を示します。この例では、請求書101は2つの異なる資金ソースから資金を利用しています。

請求書101には、金額$1000と金額$500の2つの請求書明細があります。

明細番号 メモ明細 数量 単価 金額

1 1年間のサポート 1 1000 1000

2 1年間の追加相談 2 250 500

詳細配分を含むこれらの請求書明細の会計では、売掛/未収金と収益が2つの資金間で分割されます(追加の$190は税金および運送費です)。

明細 イベント アカウント 区分 借方 貸方

1 請求書作成 02-000-1200-0000-000 売掛/未収金 1120.00

2 請求書作成 03-000-1200-0000-000 売掛/未収金 570.00

3 請求書作成 02-000-4100-0000-000 収益 1000.00

4 請求書作成 03-000-4100-0000-000 収益 500.00

77

詳細な売掛/未収金配分の有効化に関するガイドライン詳細な売掛/未収金配分は、ビジネス・ユニットに対する「売掛/未収金システム・オプション」設定の一部として有効にします。

詳細な売掛/未収金配分のデプロイメントは、新規のビジネス・ユニットおよびプライマリ元帳の設定にのみ関連します。詳細な売掛/未収金配分を使用する場合、事前計画を行い、その使用による影響を理解することが必要です。この機能を有効にする前に、このトピックに示されているすべてのガイドラインをレビューしてください。

注意: 実装目的で、詳細な売掛/未収金配分機能の事前定義データはマルチファンド会計と呼ばれます。

詳細な売掛/未収金配分の有効化

詳細な売掛/未収金配分を有効にするには、次のステップに従います。

1. 「設定および保守」にナビゲートします。2. タスク「売掛/未収金システム・オプションの管理」を検索します。3. 詳細な売掛/未収金配分用に作成されたビジネス・ユニットの、「システム・オプションの作成」または「システム・オプションの編集」ページを開きます。

4. まだ表示されていない場合は、「請求および収益」タブ・リージョンの「会計」セクションにナビゲートします。

5. 「マルチファンド会計の使用可能」オプションを有効にします。6. 作業内容を保存します。

注意: 詳細な売掛/未収金配分に対して「マルチファンド会計の使用可能」オプションを有効にして「システム・オプション」レコードを保存した後、このビジネス・ユニットに対してこの機能を無効にすることはできません。

詳細な売掛/未収金配分の設定を完了するには、このビジネス・ユニットに割り当てられたプライマリ元帳の補助元帳会計での会計処理基準を作成することも必要になります。

ビジネス・ユニットおよびプライマリ元帳の要件

ビジネス・ユニットに対する「売掛/未収金システム・オプション」設定の一部としてこの機能の設定を有効にした場合でも、実際にはこの設定はプライマリ元帳およびこの元帳に関連付けられているすべての売掛/未収金ビジネス・ユニットに適用されます。

ビジネス・ユニットに対して詳細な売掛/未収金配分を有効化する場合、次の要件が適用されます。

あるビジネス・ユニットに対して詳細な売掛/未収金配分機能を有効にすると、同じプライマリ元帳に関連付けられたすべてのビジネス・ユニットについて、自動的に、この機能が同様に有効になります。このプライマリ元帳に関連付けられたビジネス・ユニットのいずれかで詳細な売掛/未収金配分が必要でない場合は、この機能を有効にする前に、そのビジネス・ユニットとこの元帳との関連付けを解除する必要があります。詳細な売掛/未収金配分は、トランザクションがないビジネス・ユニットに対してのみ有効にできます。このため、この機能は新規のビジネス・ユニットおよび元帳の実装でのみ使用できます。

78

レガシー・トランザクションの移行の要件

詳細な売掛/未収金配分が有効になったビジネス・ユニットにレガシー・トランザクションを移行する場合は、次の要件が適用されます。

レガシー・システムからこのビジネス・ユニットにトランザクションを移行する前に、ビジネス・ユニットの詳細な売掛/未収金配分を有効にしておく必要があります。FBDIテンプレートまたは売掛/未収金REST APIリソースのいずれかを使用して、トランザクションを移行できます。トランザクション明細ごとに、レガシー・トランザクションを未回収残高として移行します。レガシー・トランザクションを移行した後、すべてのトランザクションを一般会計に転記します。

移行したすべてのトランザクションが確実に1つの仕訳に転記されるようにするには、該当する元帳の「会計オプションの編集」ページで、「総勘定元帳仕訳」オプション仕訳要約を「GL記帳日別に要約」に設定します。

この設定を使用すると、一般会計からの未回収残高の移行と矛盾しないように、仕訳を手動で逆仕訳できます。また、これにより、当期間の収益、運送費および税金の不要なエントリも回避されます。

詳細な売掛/未収金配分のための補助元帳会計設定「売掛/未収金システム・オプション」の「マルチファンド会計の使用可能」オプションを使用してビジネス・ユニットの詳細な売掛/未収金配分を有効にした後、そのビジネス・ユニットに割り当てられたプライマリ元帳の補助元帳会計で、関連する会計処理基準および仕訳ルール・セット割当を作成する必要があります。

注意: 実装目的で、詳細な売掛/未収金配分機能の事前定義データはマルチファンド会計と呼ばれます。

詳細な売掛/未収金配分のためのプライマリ元帳を準備する手順は、次のとおりです。

マルチファンド会計用の会計処理基準を作成します。マルチファンド会計貸借一致処理基準の事前定義済仕訳ルール・セットを、その会計処理基準に割り当てます。マルチファンド会計用の会計処理基準をプライマリ元帳に関連付けます。

詳細な売掛/未収金配分のための補助元帳会計を設定する手順は、次のとおりです。

1. 売掛/未収金構成から「会計処理基準の管理」タスクにナビゲートします。2. 会計処理基準「標準経過勘定」を検索します。3. 「標準経過勘定」の「会計処理基準の編集」ページで、「処理」メニューから「複製」を選択します。

4. 「会計処理基準の作成」ウィンドウで、マルチファンド会計用の会計処理基準を作成します。たとえば、次のように入力します。

a. 「名前」フィールドに、「マルチファンド会計処理基準」と入力します。b. 「短縮名」フィールドに、MULTI_FIND_ACCOUNTING_METDと入力します。c. 「摘要」フィールドに、「マルチファンド会計をサポートする会計処理基準」と入力します。d. 「勘定体系」フィールドで、勘定体系を選択します。e. 「保存してクローズ」ボタンをクリックします。

79

5. マルチファンド会計の「会計処理基準の編集」ページの「仕訳ルール・セット割当」セクションで、「複製」処理からコピーされた既存のルール・セットを削除します。

6. 次のように、事前定義済のマルチファンド会計ルール・セットを入力します。請求書 - マルチファンド会計貸借一致処理基準クレジット・メモ - マルチファンド会計貸借一致処理基準デビット・メモ - マルチファンド会計貸借一致処理基準修正 - マルチファンド会計貸借一致処理基準入金 - マルチファンド会計貸借一致処理基準その他入金 - マルチファンド会計貸借一致処理基準

7. マルチファンド会計処理基準をアクティブ化します。8. 作業内容を保存します。9. 「元帳オプションの指定」タスクにナビゲートします。

10. マルチファンド会計が有効になっているビジネス・ユニットに関連付けられているプライマリ元帳を選択します。

11. 「元帳オプションの指定」ページの「補助元帳会計」セクションにある「会計処理基準」フィールドで、マルチファンド会計用に定義した会計処理基準を選択します。

12. ビジネス要件に従って、残りのフィールドに入力します13. 作業内容を保存します。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

80

19c

現預金のための売掛/未収金クレジットの実装

3 顧客請求構成の定義この章の内容は次のとおりです。

自動インボイス支払条件自動会計トランザクション・タイプトランザクション・ソースメモ明細繰越残高請求営業担当参照勘定に関するFAQ送金先住所に関するFAQ

自動インボイス

自動インボイス・データの準備自動インボイス・プロセスが適切に機能するようにするには、インポートする新しいデータ用にReceivables環境を準備する必要があります。Receivablesで定義されていない設定データをオリジナル・システムが使用する場合は、自動インボイスを使用する前にこのデータを定義する必要があります。

データ・チェックリスト

Receivablesおよび関連アプリケーションで適切なレコードが設定および更新されていることを確認します。

次の設定データを追加または更新します。

Receivablesで定義されていない顧客のデータがオリジナル・システムに含まれている場合は、顧客を

81

追加またはインポートします。未定義の単位がオリジナル・システムで使用されている場合は、単位を追加します。一般会計で次のデータを追加または更新します。

通貨(未定義の通貨がオリジナル・システムで使用されている場合)。会計フレックスフィールド・セグメント値(未定義の値がオリジナル・システムで使用されている場合)。

税金で次の税データを追加または更新します。未定義の税率コードに割り当てられた税率。特定の場所に出荷される製品に関連付けられた税率。顧客および品目に対する税金の全額控除または一部控除。

次の売掛/未収金参照コードを追加または更新します。本船渡し(FOB)参照コード(未定義のFOBポイント・コードがオリジナル・システムで使用されている場合)。運送業者参照コード。

次のReceivablesデータを追加または更新します。自動会計(これは自動インボイスを使用するために必要な設定です)支払条件トランザクション・タイプトランザクション・ソース営業担当収益スケジューリング・ルール

自動インボイスの設定

自動インボイスに固有のReceivablesデータをレビューおよび更新します。

次のデータをレビューおよび更新します。

自動インボイス・グループ・ルール: 追加のグループ・ルールを定義するか、Receivablesによって提供されるデフォルトのグループ・ルールを更新します。自動インボイスでは、グループ・ルールを使用して、トランザクションの作成方法を決定します。自動インボイスでは、使用するグループ・ルールを決定する際に、次の階層を使用します。

トランザクション・ソース顧客サイト顧客プロファイルシステム・オプション

自動インボイス明細ソート・ルール: 自動インボイスの明細ソート・ルールを定義して、トランザクション明細のソート方法を決定します。自動インボイスでは、明細ソート・ルールを定義していない場合、トランザクションの明細がランダムにソートされます。自動インボイス・トランザクション・ソース自動入金処理: 自動インボイスで入金処理のためにインポート済クレジットを自動的に評価する場合は、自動インボイス・トランザクション・ソースで「クレジットの入金処理」オプションを有効にします。売掛/未収金システム・オプション: 「請求および収益」タブで自動インボイスの売掛/未収金システム・オプションを設定します。

「顧客」セクション: 「グループ・ルール」フィールド: トランザクションの処理中にグループ・ルールを選択するためのデフォルト階層の一部として使用する、自動インボイス・グルー

82

プ・ルールを割り当てます。「自動インボイス」セクション: 「インタフェース表のパージ」オプション: 自動インボイスの実行後にデータを自動的にパージする場合は、このオプションを有効にします。「自動インボイス」セクション: 「最大メモリー(バイト)」フィールド: 検証のために自動インボイスに割り当てるメモリー量を表す値を入力します。「自動インボイス」セクション: 「ログ・ファイル・メッセージ・レベル」フィールド: 自動インボイス・ログ・ファイルに表示する詳細の量を示す0から5のレベルを入力します。「自動インボイス」セクション: 「不正な会計日」フィールド: 「拒否」または「修正」を選択して、会計日が文書連番内で不適切な場合に、自動インボイスでトランザクションを処理する方法を決定します。

注意: この設定を使用するのは、プライマリ元帳が文書連番に対して有効になっている場合のみです。

プロファイル・オプション: 次の自動インボイスのプロファイル・オプションを設定します。IDフレックスフィールド・コード: 自動インボイスで使用するフレックスフィールド・コードのIDを指定します。自動インボイス・ワーカーごとの最大明細数: 自動インボイス・ワーカーごとの最大明細数を指定します。ソース・コード: 自動インボイスで使用するソース・コードを指定します。パラレル・ヒントの使用: 自動インボイスでパラレル・ヒントを有効にします。自動インボイス統計の収集許可: このプロファイル・オプションを「はい」に設定した場合に自動インボイスを発行すると、まずインタフェース表(RA_INTERFACE_LINES_ALL、RA_INTERFACE_DISTRIBUTIONS_ALLおよびRA_INTERFACE SALESCREDITS_ALL)が分析され、トランザクションのインポートの実行に最適な方法を判断するために統計が収集されます。インポートするレコード数およびワーカー・プロセス数が以前の自動インボイスの発行とほぼ同じである場合は、このプロファイル・オプションを「いいえ」に設定してこの分析をスキップできます。

トランザクション・フレックスフィールド

Receivablesでは、自動インボイスを使用してインポートする各トランザクションおよびトランザクション明細を一意に識別するために、トランザクション・フレックスフィールドを使用します。トランザクション・フレックスフィールドは、トランザクション明細の参照およびリンクにも使用されます。

明細レベルとヘッダー・レベルの両方のトランザクション・フレックスフィールドを定義する必要があります。ヘッダー情報を参照する明細レベルのトランザクション・フレックスフィールドのすべてのセグメントは、ヘッダー・レベルのトランザクション・フレックスフィールドにも存在する必要があります。たとえば、4つのセグメントを持つ明細レベルのトランザクション・フレックスフィールドを定義し、最後の2つのセグメントのみが明細レベルの情報を参照する場合は、最初の2つのセグメントを使用して、ヘッダー・レベルのトランザクション・フレックスフィールドを定義します。

参照およびリンク先トランザクション・フレックスフィールドを作成しない場合、Receivablesでは、明細レベルのトランザクション・フレックスフィールド体系を使用して異なる明細をリンクおよび参照します。この場合、個別の参照およびリンク先トランザクション・フレックスフィールドを定義する必要はありません。

ただし、独自のフォームを作成してインタフェース・データを入力し、参照およびリンク先トランザクション・フレックスフィールドを表示する場合は、これらのトランザクション・フレックスフィールドを定義す

83

る必要があります。これらのフレックスフィールドは、明細レベルのトランザクション・フレックスフィールドと同じフレックスフィールド体系である必要があります。

関連トピック

Receivablesでの法的エンティティの文書連番

自動インボイス・グループ・ルールの例この例は、グループ・ルールを使用して、自動インボイスのインポート中にトランザクション明細をトランザクションにグループ化する方法を示しています。

シナリオ

同じ請求書に表示される項目を指定する自動インボイス・グループ・ルールを定義します、項目は、通貨(CURRENCY_CODE)や顧客請求先住所(ORIG_SYSTEM_BILL_ADDRESS_ID)などのすべての必須属性で一致する必要があり、販売オーダー・タイプ(SALES_ORDER_SOURCE)のオプション属性でも一致する必要があります。

トランザクションの詳細

自動インボイスのインポート中に、通貨および顧客請求先住所以外のすべての必須属性が一致しているとします。

次の図は、この例で定義された自動インボイス・グループ・ルールに従って、3つのインポート済請求書がどのように作成されるかを示しています。

分析

品目Aと品目Bは同じ通貨および販売オーダー・タイプを共有するため、同じ請求書(請求書1)に表示されます。品目Cの通貨はAおよびBと同じですが、販売オーダー・タイプが異なるため、独自の請求書(請求書2)に

84

表示されます。品目Dと品目Eは同じ通貨および販売オーダー・タイプを共有するため、同じ請求書(請求書3)に表示されます。

結果

販売オーダー・タイプのオプション属性のため、自動インボイスによって3つの請求書が作成されました。グループ・ルールで必須属性のみが指定されていたら、自動インボイスによって作成される請求書は2つのみになります。

自動インボイス・グループ・ルールの属性自動インボイス・グループ・ルールには、同じトランザクションのすべての品目で同一である必要があるトランザクション属性が含まれています。たとえば、トランザクション番号(TRX_NUMBER)は、すべてのグループ・ルールの必須属性です。インタフェース表にトランザクション番号が異なる2つのレコードがある場合、自動インボイスではレコードごとに個別のトランザクションが作成されます。

自動インボイス・グループ・ルールは、インポート済トランザクションに必須トランザクション属性とオプション・トランザクション属性の両方を提供します。必須属性はグループ・ルールから削除できませんが、必須属性にオプション属性を追加して新しいグループ・ルールを作成できます。

必須トランザクション属性

自動インボイス・グループ・ルールは、RA_INTERFACE_LINES_ALL表の次の必須トランザクション属性を提供します。これらのトランザクション属性はすべて、自動インボイス・グループ・ルールを使用して作成されたすべてのトランザクションに適用されます。

BILL_PLAN_NAMEBILL_PLAN_PERIODCOMMENTSCONS_BILLING_NUMBERCONVERSION_DATECONVERSION_RATECONVERSION_TYPECREDIT_METHOD_FOR_ACCT_RULECREDIT_METHOD_FOR_INSTALLMENTSCURRENCY_CODECUSTOMER_BANK_ACCOUNT_IDCUST_TRX_TYPE_IDDOCUMENT_NUMBERDOCUMENT_NUMBER_SEQUENCE_IDGL_DATEHEADER_ATTRIBUTE1-15HEADER_ATTRIBUTE_CATEGORYHEADER_GDF_ATTRIBUTE1-30INITIAL_CUSTOMER_TRX_IDINTERNAL_NOTES

85

INVOICING_RULE_IDORIG_SYSTEM_BILL_ADDRESS_IDORIG_SYSTEM_BILL_CONTACT_IDORIG_SYSTEM_BILL_CUSTOMER_IDORIG_SYSTEM_SHIP_CONTACT_IDORIG_SYSTEM_SHIP_CUSTOMER_IDORIG_SYSTEM_SOLD_CUSTOMER_IDORIG_SYSTEM_BATCH_NAMEPAYMENT_SERVER_ORDER_IDPAYMENT_SET_IDPREVIOUS_CUSTOMER_TRX_IDPRIMARY_SALESREP_IDPRINTING_OPTIONPURCHASE_ORDERPURCHASE_ORDER_DATEPURCHASE_ORDER_REVISIONREASON_CODERECEIPT_METHOD_IDRELATED_CUSTOMER_TRX_IDSET_OF_BOOKS_IDTERM_IDTERRITORY_IDTRX_DATETRX_NUMBER

オプション・トランザクション属性

自動インボイス・グループ・ルールは、RA_INTERFACE_LINES_ALL表の次のオプション・トランザクション属性を提供します。グループ・ルール内のトランザクション区分に、次の属性の1つ以上を割り当てることができます。

ACCOUNTING_RULE_DURATIONACCOUNTING_RULE_IDATTRIBUTE1-15ATTRIBUTE_CATEGORYINTERFACE_LINE_ATTRIBUTE1-15INTERFACE_LINE_CONTEXTINVENTORY_ITEM_IDREFERENCE_LINE_IDRULE_START_DATESALES_ORDERSALES_ORDER_DATESALES_ORDER_LINESALES_ORDER_REVISION

86

SALES_ORDER_SOURCETAX_CODETAX_RATE

自動インボイス明細ソート・ルールのトランザクション属性自動インボイスではトランザクションを請求書、デビット・メモおよびクレジット・メモにグループ化した後、明細ソート・ルールを使用して、トランザクションの各明細のソート方法および採番方法を決定します。作成する自動インボイス・グループ・ルールごとに、自動インボイス明細ソート・ルールを指定できます。

トランザクション属性

自動インボイスでは、明細ソート・ルールで使用するために、RA_INTERFACE_LINES_ALL表の次のトランザクション属性を提供します。

ACCOUNTING_RULE_DURATIONACCOUNTING_RULE_IDACCOUNTING_RULE_NAMEAMOUNTATTRIBUTE_CATEGORYATTRIBUTE1-15FOB_POINTINTERFACE_LINE_ATTRIBUTE1-15INTERFACE_LINE_CONTEXTORIG_SYSTEM_SHIP_ADDRESS_IDQUANTITYQUANTITY_ORDEREDREASON_CODEREASON_CODE_MEANINGREFERENCE_LINE_ATTRIBUTE1-15REFERENCE_LINE_CONTEXTREFERENCE_LINE_IDSALES_ORDERSALES_ORDER_DATESALES_ORDER_LINESALES_ORDER_SOURCESHIP_DATE_ACTUALSHIP_VIATAX_CODEUNIT_SELLING_PRICEUNIT_STANDARD_PRICEUOM_CODEUOM_NAME

87

WAYBILL_NUMBER

自動インボイスに関するFAQ

自動インボイスがトランザクションを拒否したのはなぜですか。

自動インボイスの処理中に、検証に失敗したトランザクション明細がある場合、インポート・プロセスはトランザクション・ソースの「無効明細」フィールドの値を確認して、トランザクションの処理内容を決定します。

値が「請求書の拒否」の場合、自動インボイスは、グループ・ルールに従って1つの請求書を構成するすべてのトランザクション明細を拒否します(いずれかのトランザクション明細が無効な場合)。たとえば、グループ・ルールが3つのトランザクション明細を1つの請求書として作成するように指定していて、トランザクション明細の1つにエラーがある場合、自動インボイスは3つのトランザクション明細をすべて拒否して、請求書を作成しません。

ただし、値が「請求書の作成」の場合、自動インボイスは1つの無効なトランザクション明細を拒否して、残りの2つの有効なトランザクション明細から請求書を作成します。

自動インボイスが重複するトランザクション番号のトランザクションを作成したのはなぜですか。

自動インボイスの処理中、グループ化が完了すると、インポート・プロセスはトランザクションおよび文書番号が一意であることを検証します。場合によっては、自動インボイスは、同じグループに同じトランザクション番号または文書番号の複数の請求書を作成します。グループ化が完了すると、自動インボイスは重複するトランザクション番号および文書番号をチェックし、検証に失敗した明細をレポートします。

たとえば、2つの明細は同じトランザクション番号でインポートされますが、通貨は異なります。これらの明細は通貨が異なるため、グループ化中に2つの個別の請求書に分割されます。グループ化が完了すると、トランザクション番号が同一であるため、両方の請求書が検証に失敗します。

自動インボイスでグループ・ルールに定義されていないトランザクション区分を処理するとどうなりますか。

自動インボイスでグループ・ルールを使用し、グループ・ルールに定義されていないトランザクション区分を処理している場合、自動インボイスは必須トランザクション属性のみを使用して、トランザクションをグループ化します。

グループ・ルールに明細ソート・ルールが必要になるのはいつですか。

グループ・ルールによって作成されたトランザクションに属するトランザクション明細を特定の順序で編成する場合は、自動インボイス明細ソート・ルールを自動インボイス・グループ・ルールに割り当てます。「ソート・タイプ」を使用して、トランザクション属性に属する値を最小から最大(昇順)または最大から最小(降順)のいずれでソートするかを指定します。

たとえば、分散オーダー・オーケストレーションからトランザクションをインポートする場合は、SALES_ORDER_LINE属性を使用して明細ソート・ルールを定義し、請求書の項目を販売オーダーに表示されるのと同じ順序でリストできます。

または、AMOUNT属性および「降順」の「ソート・タイプ」を使用して明細ソート・ルールを定義し、グ

88

ループ・ルールによって作成されたトランザクションで最も高い請求書明細金額が最初にリストされるようにすることができます。

支払条件

支払条件の定義に関するガイドライン支払条件を使用して、顧客トランザクションの支払期日および割引日を識別します。

支払条件の作成後に、オプションで、これら両方を顧客アカウント・プロファイルと顧客サイト・プロファイルおよびトランザクション・タイプに割り当てることができます。割り当てた支払条件は、関連する顧客アカウントまたはサイト、またはトランザクション・タイプを使用して手動で作成するトランザクションにデフォルトで割り当てられます。

支払条件に関する考慮事項は次のとおりです。

支払条件および顧客プロファイル支払条件および割引賦払のある分割支払条件前払金支払条件

支払条件および顧客プロファイル

顧客アカウント・プロファイルおよび顧客サイト・プロファイルに対する支払条件の設定は、手動で作成するトランザクションの支払条件の使用および可用性に影響します。

トランザクションを手動で作成すると、Receivablesは支払条件を探して、次の順序でトランザクションに割り当てます。

1. 請求先顧客のサイト・プロファイルに割り当てられた支払条件。2. 請求先顧客のアカウント・プロファイルに割り当てられた支払条件。3. トランザクション・タイプに割り当てられた支払条件。

トランザクションに割り当てられた支払条件を変更するには、顧客アカウント・プロファイルまたは顧客サイト・プロファイルで「条件上書き」オプションを有効にする必要があります。「条件上書き」オプションを有効にすると、手動トランザクションにより柔軟に支払条件を割り当てることができます。

顧客アカウント・プロファイルおよび顧客サイト・プロファイルで「条件上書き」オプションを有効にしない場合は、次のようになります。

デフォルトで割り当てられている支払条件を変更できません。請求先顧客を選択した場合に、この顧客のアカウント・プロファイルまたはサイト・プロファイル、またはトランザクション・タイプに支払条件が割り当てられていない場合は、トランザクションで使用できる支払条件はありません。別の方法として、別の請求先顧客を選択するか、顧客を選択する前に支払条件を選択することもできます。

89

支払条件を選択してから請求先顧客を選択した場合に、この顧客のアカウント・プロファイルまたはサイト・プロファイルに支払条件が割り当てられていない場合は、最初に割り当てられた支払条件を変更できません。

ヒント: 顧客アカウント・プロファイルおよび顧客サイト・プロファイルで「条件上書き」オプションを無効のままにする場合は、手動トランザクションに使用するトランザクション・タイプに支払条件を割り当ててください。

支払条件および割引

顧客の標準支払条件を定義して、オープン項目の支払期日および割引日を指定します。支払条件には、期日前支払の割引率を含めることができます。また、支払条件の明細ごとに複数の割引を割り当てることができます。

たとえば、10日以内の支払で2%、30日以内全額支払という支払条件は、支払を10日以内に受領した場合、顧客に対して2パーセントの割引が許可されることを示しています。10日を超えた後は、トランザクション日から30日以内が全残高の支払期日となり、適用可能な割引はありません。

支払条件に関連付けられた項目の一部支払で顧客が割引を受けることができるようにするには、「一部支払割引の許可」オプションを有効にします。一部支払は、残りの未払額よりも少ない支払です。これを行う場合は、売掛/未収金システム・オプション「割引対象一部支払」が有効になっていることも確認する必要があります。

「割引基準」フィールドを使用して、支払条件の割引の計算に使用する金額を決定します。支払条件で賦払を使用する場合は、各賦払に割引率を割り当てることができます。

「割引基準日」フィールドを使用して、割引の計算に使用する日付を選択します。選択肢は次のとおりです。

入金日: 入金が作成された日付。入金消込日: 入金がトランザクションに消し込まれた日付。預入日: 入金が送金銀行に振り込まれた日付。

トランザクションが支払条件割引日までに支払われた場合、割引が適用されます。算式はTransactionDate + Discount Due By Period >= Discount Basis Date (Receipt Date/ReceiptApplication Date/Deposit Date)です。

賦払のある分割支払条件

支払期日が異なる請求書賦払の分割支払条件を作成します。支払条件は、各賦払の金額を決定します。

「賦払オプション」フィールドを使用して、トランザクションに対して請求される運送費および税額を配賦する方法を決定します。税額および運送費をすべての賦払に配分するか、すべての運送費および税額を初回賦払に配賦できます。

分割支払条件の支払予定を定義します。支払予定は、各賦払の期日、各賦払の金額および各賦払でオファーする割引額を決定します。

前払金支払条件

オプションで前払金支払条件を定義するには、「前払金」オプションを有効にします。前払金支払条件をト

90

ランザクションに割り当てて、商品およびサービスの前払金が必要なトランザクションを示します。

前払金支払条件では、請求または前払済商品またはサービスの搬送の前に資金取得は必要ありません。これらの資金を事前に取得する場合は、企業で特定のビジネス・プラクティスを設定する必要があります。

分割支払条件と未払額分割支払条件は、「賦払オプション」フィールドの設定に応じて、支払予定の賦払ごとに異なる未払額を導出します。

基準金額が関連金額と異なる場合に、「賦払オプション」フィールドを「税金および運送費を配分」に設定すると、Receivablesでは定義した比率に基づいて支払予定の関連金額に基準金額が按分されます。Receivablesでは、次の式を使用して、各賦払の当初未払金額を決定します。

Amount Due = Relative Amount/Base Amount * Invoice Amount

「賦払オプション」フィールドを「初回賦払に税金および運送費を含む」に設定した場合、支払予定に指定する基準金額および関連金額は、これらの支払条件を割り当てる請求書の当初明細金額が異なる賦払にどのように配分されるかのみを示します。

この場合、当初の運送費および税額は、最初の支払に指定した基準金額と関連金額の比率で配賦された明細金額に加えて、初回賦払に含められます。Receivablesでは、次の式を使用して、初回賦払の当初未払金額を決定します。

Amount Due = (Relative Amount/Base Amount * Base Line Amount) + Base Freight Amount + Base Tax Amount

支払条件割引基準支払条件「割引基準」フィールドは、Receivablesで割引額を計算する基準を決定します。

割引基準

請求書金額

トランザクションの税金、運送費および明細金額の合計に基づいて割引額を計算します。

明細のみ

トランザクションの明細金額のみに基づいて割引額を計算します。

明細、運送費品目および税金

明細品目の金額とその運送費および税額に基づいて割引額を計算しますが、トランザクション・ヘッダー・レベルの運送費および手数料は除外されます。

明細および税金(運送費品目および税はなし)

91

明細品目とその税額に基づいて割引額を計算しますが、運送費品目とその税金明細は除外されます。

割引の計算方法Receivablesでは、設定、トランザクションの支払条件、受領した支払のタイプに応じて、異なる算式を使用して割引を計算します。

Receivablesでは、次の割引イベントの算式を提供します。

最大割引期限内割引および一部支払の許可一部支払割引が許可されている期限外割引一部支払割引が許可されていない期限内割引期限外割引および一部支払の不可明細のみに対する割引

最大割引

Receivablesでは、次の算式を使用して最大割引額を決定します。

Maximum Discount = (Amount Due Original) * (Highest Discount Percent - Discount Taken)

期限内割引および一部支払の許可

入金額が未回収残高よりも多い場合は、割引を差し引いて、Receivablesでは次の算式を使用して期限内割引を決定します。

Earned Discount = Amount Due Remaining * Discount Percent

入金額が未回収残高と等しいか、または少ない場合は、割引を差し引いて、Receivablesでは次の算式を使用して期限内割引を決定します。

Earned Discount = (Receipt Amount * Discount Percent) / (1 - Discount Percent)

一部支払割引が許可されている期限外割引

Receivablesでは、次の算式を使用して、一部支払が許可される場合の期限外割引を決定します。

Unearned Discount = Maximum Discount - Earned Discount

一部支払割引が許可されていない期限内割引

支払条件の「一部支払割引の許可」オプションが有効になっていない場合に、入金額が賦払をクローズする場合は、Receivablesでは期限内割引のみを処理します。

92

一部支払割引が許可されておらず、入金額が賦払をクローズする場合、Receivablesでは次の算式を使用して、期限内割引を決定します。

Earned Discount = Amount Due Original * Discount Percent

期限外割引および一部支払の不可

支払条件の「一部支払割引の許可」オプションが有効になっていない場合に、入金額が賦払をクローズする場合は、Receivablesでは期限外割引のみを処理します。

一部支払が許可されておらず、入金額が賦払をクローズする場合、Receivablesでは次の算式を使用して、期限外割引を決定します。

Unearned Discount = (Amount Due Original) * (Maximum Discount Percent - Earned Discount)

明細のみに対する割引

支払条件の「割引基準」フィールドが「明細のみ」に設定されている場合、Receivablesでは、税金、運送費または延滞手数料に消し込まれる入金額の割引は行われません。Receivablesでは、次の算式を使用して割引額を決定します。

Line Percent = Discount Percent * (Sum of Lines + Sum of Line Adjustments - Sum of Line Credits) / (Amount Due Original + Sum of Adjustments - Sum of Credits)

割引明細パーセントを決定したら、これらのすべての算式でこれを割引率として使用します。

割引額の導出例この例は、Receivablesで入金日に基づいて割引情報を導出する方法を示しています。

入金を手動で入力すると、Receivablesでは、支払条件、割引猶予日数、売掛/未収金システム・オプション、トランザクション日、支払条件割引基準日(入金日、入金消込日または入金預入日)に基づいて割引が許可されるかどうかを決定します。割引が許可される場合、Receivablesでは、設定の詳細によって決定される期限内割引と期限外割引の両方の金額を決定します。

シナリオ

次の情報を使用するとします。

期限外割引 = はい支払条件: 10日以内の支払で10%、15日以内の支払で5%、30日以内全額支払割引基準日: 入金日割引猶予日数 = 0明細のみに対する割引の計算 = いいえ一部支払割引の許可 = はい

93

この表は、割引詳細を示しています。

パーセント 日付 明細のみの場合 一部支払の場合

5 2010年12月17日 いいえ はい

10 2010年12月12日 いいえ はい

次の請求書詳細を前提とします。

請求書#101請求書日付: 2010年12月2日支払期日: 2011年1月1日金額: $1100

次の表は、様々な入金消込日に基づくデフォルトの割引額を示しています。また、顧客が獲得できる期限内割引および期限外割引の金額も確認できます。

入金日 入金額 デフォルトの割引額

メッセージ行

期限内割引の許可

期限外割引の許可

2010年12月2日から2010年12月12日まで

$990 $110 割引期限内 =110

合計= 110

$110 なし

2010年12月17日以降

$990 0

期限外割引を適用するには、金額を更新する必要があります。

割引期限内 = 0

合計= 110

なし $110

2010年12月2日から2010年12月12日まで

$1000

$10の入金は、デフォルトの割引後に「未消込」のままとなります。

$110 割引期限内 =110

合計= 110

$110 なし

2010年12月13日から2010年12月17日まで

$1000

デフォルトの割引($52.63)後、入金は全額消し込まれます。ただし、請求書に対する残高は$47.37です。

$52.63

期限外割引を適用するには、金額を更新する必要があります。

割引期限内 =52.63

合計= 110

$52.63 $57.37

2010年12月17日以降

$1000

デフォルトの割引はないので、入金は全額消し込まれます。請求書に対する残高は$100です。

0

期限外割引を適用するには、金額を更新する必要があります。

割引期限内 = 0

合計= 110

なし $110

94

支払条件に関するFAQ

繰越残高支払条件と他の支払条件との違いは何ですか。

繰越残高請求支払条件は、繰越残高請求サイクルを「繰越残高請求書の作成」プログラムに渡します。請求サイクルによって、顧客繰越残高請求書の生成時期が決まります。

繰越残高請求書は賦払間で分割できないため、繰越残高請求支払条件の賦払に関連するすべての設定が無効になります。既存の支払条件を前後に変更して、非繰越残高請求と繰越残高請求の両方の支払条件として使用することはできません。

自動会計

自動会計の勘定科目タイプとセグメント値自動会計を定義して、手動で入力するトランザクションまたは自動インボイスを使用してインポートするトランザクションのデフォルト総勘定元帳勘定科目を決定する方法を指定します。Receivablesにトランザクションを入力する前に、自動会計を定義する必要があります。トランザクションを入力または更新する場合は、自動会計で作成されるデフォルト総勘定元帳勘定科目を上書きできます。

勘定科目タイプ

勘定科目のタイプごとに自動会計レコードを定義します。その後、勘定科目の各セグメントに表名または定数値を割り当てることができます。

自動インボイス決済

インポートされたトランザクションの決済勘定。Receivablesでは、決済勘定を使用して、指定された収益金額と、販売価格にインポート済請求書明細の数量を乗算した金額との差異を保持します。Receivablesでは、インポートされたトランザクションに使用されるトランザクション・ソースでこのオプションを有効にした場合にのみ決済勘定を使用します。

受取手形

トランザクションの受取手形勘定。トランザクションを受取手形に消し込む場合、Receivablesではこの勘定を使用します。

ファクタリング受取手形

受取手形トランザクションのファクタリング受取手形勘定。

運送費

トランザクションの運送費勘定。

95

売掛/未収金

トランザクションの売掛/未収金勘定。

送金済受取手形

受取手形トランザクションの送金済受取手形勘定。

収益

トランザクションの収益および延滞手数料勘定。

税金

トランザクションの税勘定。

未請求売掛金

トランザクションの未請求売掛金勘定。トランザクションで「未収」請求ルールを使用する場合、Receivablesではこの勘定を使用します。トランザクションの収益スケジューリング・ルールで、請求ルールによる請求前に収益を認識する場合、Receivablesではこの勘定を使用します。

前受収益

トランザクションの前受収益勘定。トランザクションで「前受」請求ルールを使用する場合、Receivablesではこの勘定を使用します。トランザクションの収益スケジューリング・ルールで、請求ルールによる請求後に収益を認識する場合、Receivablesではこの勘定を使用します。

未払受取手形

受取手形トランザクションの未払受取手形勘定。

表名

Receivablesで特定の勘定科目の各会計フレックスフィールド・セグメントの情報を取得するために使用する表名または定数値を入力します。

自動会計で特定のセグメントに常に同じ値を使用する場合は、表名ではなく定数値を入力します。このセグメントに有効な情報を入力する必要があります。たとえば、会社セグメントを00から10の範囲の有効な値を持つ2文字のセグメントとして定義した場合、この範囲内の2文字の値を入力する必要があります。

請求先サイト

トランザクションの請求先サイトを使用して、収益、運送費、売掛/未収金、自動インボイス決済、税金、未請求売掛金および前受収益の各勘定のこのセグメントを決定します。

名宛人サイト

名宛人サイト表を使用して、受取手形、ファクタリング受取手形、送金済受取手形および未払受取手形の各

96

勘定のこのセグメントを決定します。

送金銀行

送金銀行表を使用して、ファクタリング受取手形勘定および送金済受取手形勘定のこのセグメントを決定します。

営業担当

営業担当表を使用して、収益、運送費、売掛/未収金、自動インボイス決済、税金、未請求売掛金および前受収益の各勘定のこのセグメントを決定します。

自動インボイス決済、税金または前受収益の各勘定に対してこのオプションを選択すると、Receivablesでは、トランザクションの営業担当に関連付けられた収益勘定を使用します。未請求売掛金勘定に対してこのオプションを選択すると、Receivablesでは、トランザクションの営業担当に関連付けられた売掛/未収金勘定を使用します。

トランザクションの明細タイプが「明細」であり、在庫品目が「運送費」である場合、自動会計では、収益勘定ではなく運送費勘定の収益スケジューリング・ルールを使用します。

標準明細

トランザクションのメモ明細または在庫品目を使用して、収益、自動インボイス決済、運送費、税金、未請求売掛金および前受収益の各勘定のこのセグメントを決定します。

自動インボイス決済、運送費、税金、未請求売掛金または前受収益の各勘定に対してこのオプションを選択すると、Receivablesでは、メモ明細品目または在庫品目に関連付けられた収益勘定を使用します。

トランザクションの明細タイプが「明細」であり、在庫品目が「運送費」である場合、自動会計では、収益勘定ではなく運送費勘定の収益スケジューリング・ルールを使用します。

税金

トランザクションの税率コードに割り当てられた税勘定を使用します。

トランザクション・タイプ

トランザクション・タイプ表を使用して、収益、運送費、売掛/未収金、自動インボイス決済、税金、未請求売掛金および前受収益の各勘定のこのセグメントを決定します。

トランザクションの明細タイプが「明細」であり、在庫品目が「運送費」である場合、自動会計では、収益勘定ではなく運送費勘定の収益スケジューリング・ルールを使用します。

自動会計構成の作成に関するガイドライン自動会計を実装するには、まず自動会計構成を定義し、自動会計がデフォルトの勘定科目を適切に作成できるように、各営業担当、トランザクション・タイプ、製品および税率コードの情報を定義します。

請求書およびクレジット・メモを入力する前に自動会計構成を定義する必要があり、勘定科目タイプごと

97

に1つの構成のみを定義できます。トランザクションの作成中、自動会計ですべての会計フレックスフィールド・セグメントを決定できない場合は、決定できるものが導出され、不完全な会計フレックスフィールドが表示されます。トランザクションを完了する前に、欠落している会計フレックスフィールド情報を指定する必要があります。

自動会計構成を作成する際は、勘定科目タイプごとにこれらのガイドラインをレビューしてください。

自動インボイス決済勘定運送費勘定売掛/未収金勘定収益勘定税勘定未請求売掛金勘定前受収益勘定各勘定の利用可能な情報

この表は、各勘定科目タイプの作成に使用できる情報を示しています。(売掛/未収金)および(収益)は、対応する売掛/未収金と収益会計のどちらのフレックスフィールドから勘定情報を取得するかを示しています。

情報ソース/自動会計タイプ

定数

顧客請求先サイト 営業担当

トランザクション・タイプ 標準品目

税率コード

自動インボイス決済 はい

はい はい(収益) はい はい(収益)

いいえ

運送費 はい

はい はい はい はい(収益)

いいえ

売掛/未収金 はい

はい はい はい いいえ いいえ

収益 はい

はい はい はい はい いいえ

税金 はい

はい はい(収益) はい はい(収益)

はい

未請求売掛金 はい

はい はい(売掛/未収金)

はい はい(収益)

いいえ

前受収益 はい

はい はい(収益) はい はい(収益)

いいえ

表に関する注意事項:

自動インボイス決済、税金、未請求売掛金または前受収益の各勘定の自動会計が標準品目に基づいている場合、Receivablesでは、標準品目収益会計フレックスフィールドのセグメントを使用します。自動インボイス決済、税金または前受収益の各勘定の自動会計が営業担当に基づいている場合、Receivablesでは、営業担当収益会計フレックスフィールドのセグメントを使用します。未請求売掛金の自動会計が営業担当に基づいている場合、Receivablesでは、営業担当売掛/未収金会計フレックスフィールドのセグメントを使用します。自動インボイス決済、収益、税金、未請求売掛金または前受収益の各勘定が営業担当に基づいており、複数の営業担当がトランザクションに存在する場合、Receivablesでは営業担当ごとに個別の配分を作成します。

98

自動インボイス決済勘定

自動インボイスの処理中、Receivablesでは自動インボイス決済勘定を使用して、指定された収益金額とインポート済請求書明細の(価格 * 数量)との差異を格納します。

インポートされたトランザクションに割り当てられたトランザクション・ソースで「決済の作成」オプションを有効にした場合、Receivablesでは自動インボイス決済勘定のみを使用します。ただし、このオプションを有効にするかどうかに関係なく、決済勘定を定義する必要があります。

自動インボイス決済勘定には、定数値、顧客請求先サイト、営業担当、トランザクション・タイプおよび標準品目を使用できます。営業担当または標準品目を選択した場合、Receivablesでは指定された収益会計フレックスフィールドを使用します。

運送費勘定

運送費勘定は、運送費を転記する総勘定元帳の勘定科目を管理します。定数値、顧客請求先サイト、営業担当、トランザクション・タイプおよび標準品目を使用して、運送費勘定を指定できます。

標準品目を選択した場合、Receivablesでは指定された収益会計フレックスフィールドを使用します。また、ヘッダー・レベルの運送費を含むトランザクションは、自動インボイスを介してインポートできません。

トランザクションの明細タイプが「明細」であり、在庫品目が「運送費」である場合、自動会計では、収益勘定ではなく運送費勘定の収益スケジューリング・ルールを使用します。

売掛/未収金勘定

売掛/未収金勘定は、売掛/未収金金額を転記する総勘定元帳の勘定科目を管理します。トランザクション・タイプ、顧客請求先サイト、営業担当および定数値を使用して、売掛/未収金勘定を指定できます。

収益勘定

収益勘定は、収益金額を転記する総勘定元帳の勘定科目を管理します。トランザクション・タイプ、顧客請求先サイト、標準品目、営業担当および定数値を使用して、収益勘定を指定できます。

税勘定

税勘定は、税額を転記する総勘定元帳の勘定科目を管理します。税率コード、顧客請求先サイト、営業担当、トランザクション・タイプ、標準品目および定数値を使用して、税勘定を指定できます。

営業担当または標準品目を選択した場合、Receivablesでは指定された収益会計フレックスフィールドを使用します。

未請求売掛金勘定

Receivablesでは、請求および収益スケジューリング・ルールが設定されたトランザクションに対して未請求売掛金勘定を使用します。請求ルールによるトランザクションに対する請求前に、収益スケジューリング・ルールでトランザクションの収益を認識する場合は常に、Receivablesではこの金額を未請求売掛金勘定に転記します。

未請求売掛金勘定には、定数値、顧客請求先サイト、営業担当、トランザクション・タイプおよび標準品目

99

を選択できます。

標準品目を選択した場合、Receivablesでは指定された収益会計フレックスフィールドを使用します。営業担当を選択した場合、Receivablesでは営業担当売掛/未収金会計フレックスフィールドを使用します。

前受収益勘定

Receivablesでは、請求および収益スケジューリング・ルールが設定されたトランザクションに対して前受収益勘定を使用します。請求ルールによるトランザクションに対する請求後に、収益スケジューリング・ルールでトランザクションの収益を認識する場合は常に、Receivablesではこの金額を前受収益勘定に転記します。

前受収益勘定には、定数値、顧客請求先サイト、営業担当、トランザクション・タイプおよび標準品目を選択できます。

営業担当または標準品目を選択した場合、Receivablesでは指定された収益会計フレックスフィールドを使用します。

自動会計で会計フレックスフィールド・セグメントを導出する例この例は、自動会計でデフォルトの会計フレックスフィールド・セグメントを導出する方法を示しています。

Receivablesでは、自動会計を使用してトランザクションのデフォルト会計を導出し、補助元帳会計で事前定義済設定を使用して、「売掛/未収金会計の作成」プログラムが自動会計が変更せずに導出したデフォルト勘定科目を受け入れるようにします。ただし、補助元帳会計設定を変更する場合は、かわりにすべての会計フレックスフィールド・セグメントの定数値を選択できます。

次の2つのシナリオは、定義した自動会計構成を使用して、Receivablesが会計フレックスフィールドのデフォルトを決定する方法を示しています。

4つの定義を持つフレックスフィールド

4セグメントの収益フレックスフィールド00-000-0000-000 (会社-コスト・センター-勘定科目-製品)を定義します。自動会計を定義して、各セグメントのデフォルトを導出できます。

第1セグメントの会社は定数01です。第2セグメントのコスト・センターは営業担当(John Doe)から導出されます。第3セグメントの勘定科目はトランザクション・タイプ(標準請求書)から導出されます。第4セグメントの製品は標準明細(20 Megabyte Hard Disk)から導出されます。

営業担当John Doeは、20 Megabyte Hard Driveに対する1つの明細の標準タイプの請求書を入力します。

次の図は、自動会計が各セグメントの個別の定義に基づいて収益フレックスフィールドを導出する方法を示しています。

100

2つの定義を持つフレックスフィールド

自動会計がセグメント1と2のトランザクション・タイプ(標準請求書)、およびセグメント3と4の標準明細(コンサルティング・サービス)の情報のみを使用するように、構成を再定義します。

次の図は、自動会計がセグメント1と2およびセグメント3と4の同じ定義に基づいて収益フレックスフィールドを導出する方法を示しています。

自動会計に関するFAQ

自動会計で補助元帳会計が作成されるのはいつですか。

自動会計では、設定に従って、Receivablesのトランザクション会計イベントごとにデフォルトの会計を導出します。自動会計は、有効な会計フレックスフィールドを請求書およびクレジット・メモに割り当てて、すべての関連勘定科目(運送費、売掛/未収金、収益、自動インボイス決済、税金、未請求売掛金および前受収益)に対して有効な会計フレックスフィールドを自動的に生成します。

「売掛/未収金会計の作成」プログラムを発行すると、補助元帳会計仕訳が作成されます。補助元帳会計によって確定会計が一般会計に転送されます。

オプションで、補助元帳会計で独自の会計基準を定義して、ビジネス要件を満たす会計を作成できます。補助元帳会計設定を変更して独自の会計を作成すると、補助元帳会計は、トランザクション入力時に自動会計が最初に導出したデフォルトの勘定科目または勘定科目の個々のセグメントを上書きします。

101

トランザクション・タイプ

トランザクション・タイプを使用した転記済活動および非転記済活動のオプショントランザクション・タイプの「未回収売掛/未収金」オプションおよび「GL転記」オプションを使用して、トランザクションの転記済活動および非転記済活動を管理します。

「未回収売掛/未収金」オプションが有効な場合、このトランザクション・タイプの完全なデビット・メモ、クレジット・メモ、チャージバックまたは対顧客勘定クレジットを作成するたびに、Receivablesでは顧客残高を更新します。また、Receivablesでは、これらのトランザクションは標準年齢調べおよび回収プロセスにも含まれます。

「GL転記」オプションが有効な場合、Receivablesはこのトランザクション・タイプのトランザクションを一般会計に転記します。このオプションが有効になっていない場合、このトランザクション・タイプのトランザクションに対して会計は生成されません。

トランザクション・タイプの定義に関する考慮事項は次のとおりです。

トランザクション・タイプの無効化顧客アカウントおよび年齢調べの更新会計のみの更新

トランザクション・タイプの無効化

「無効」トランザクション・タイプを定義することで、デビット・メモ、クレジット・メモ、対顧客勘定クレジットまたは請求書を無効にできます。「無効」トランザクション・タイプを定義する場合は、「未回収売掛/未収金」オプションおよび「GL転記」オプションを「いいえ」に設定します。その後、トランザクションに対する活動がなく、一般会計に転記されていない場合は、トランザクション・タイプを「無効」に変更して、トランザクションを無効にできます。

この活動は顧客残高を変更しないため、「顧客アカウント詳細のレビュー」ページには含まれません。

顧客アカウントおよび年齢調べの更新

「未回収売掛/未収金」オプションを「はい」に設定し、「GL転記」オプションを「いいえ」に設定した場合、Receivablesはこのトランザクション・タイプに割り当てられたトランザクションのトランザクション活動で顧客アカウントを更新します。会計には影響ありません。

初期実装中にこれらの設定でトランザクション・タイプを使用します。トランザクション金額は売掛/未収金勘定の総勘定元帳期首残高に含まれますが、活動を年齢調べして、これに対して支払を回収する必要があります。クレジット・メモ、支払、修正など、トランザクションに対するすべての関連活動は、顧客残高に影響を与えるものとして計上されます。これらの活動は、「顧客アカウント詳細のレビュー」ページでレビューできます。

会計のみの更新

102

「未回収売掛/未収金」オプションを「いいえ」に設定し、「GL転記」オプションを「はい」に設定した場合、Receivablesは顧客残高に影響を与えることなく会計を更新します。

これらの設定でトランザクション・タイプを使用するのは、総勘定元帳勘定科目を組み替えるために顧客に再請求する場合など、会計活動を修正する場合です。「未回収売掛/未収金」オプションが「いいえ」に設定されたクレジット・メモおよび請求書が作成されます。クレジット・メモによって当初請求書の総勘定元帳勘定科目が逆仕訳され、請求書によって新しい総勘定元帳勘定科目で会計が作成されます。支払を受領するときに当初請求書が現金消込に使用されるため、この活動は顧客に対して透過的です。

この活動は顧客残高を変更しないため、「顧客アカウント詳細のレビュー」ページには含まれません。

関連トピック

トランザクションのクレジットおよび再請求はいつ行うのですか

通常消込および超過消込トランザクションに割り当てるトランザクション・タイプは、トランザクション残高に対して許可される消込のタイプを定義します。この定義は、トランザクション・タイプの「超過消込不可」オプションおよび「超過消込の許可」オプションによって管理されます。

通常消込では、トランザクション残高をゼロに近づけるか、ゼロにするトランザクションに対してのみ支払またはクレジットを消し込むことができます。たとえば、請求書の未回収残高が$400の場合、このトランザクションに対して$400までしか消し込むことができません。通常消込では、残高をゼロにすることのみ可能です。

超過消込では、トランザクションに対して未回収残高以上を消し込むことができます。たとえば、$500の入金を$400の請求書に消し込むと、請求書に$100が超過消込され、残高の符号がプラスからマイナスに反転されます。

通常消込および超過消込の使用

トランザクションが超過消込を許可するかどうかによって、そのトランザクションで実行できる処理が決まります。

通常消込のみを許可するトランザクションに全額支払われると、トランザクションをクレジットするために、クレジットを作成する前にまずトランザクションから入金の消込を取り消す必要があります。

自動インボイスを使用して、支払済請求書に対してクレジット・メモをインポートし、これらのクレジットを自動入金処理のために評価する場合、支払済請求書のトランザクション・タイプで通常消込のみを許可する必要があります。ただし、トランザクションのトランザクション・ソースで「クレジットの入金処理」オプションが有効になっていない場合、自動インボイスは、請求書から入金の消込が取り消されるまで、関連するクレジット・メモをインタフェース表に残します。

関連トピック

自動インボイスによるクレジット金額の処理方法

トランザクション・タイプ参照勘定に関するガイドライン

103

「請求書」、「チャージバック」、「クレジット・メモ」および「デビット・メモ」の各区分のトランザクション・タイプの会計を定義します。Receivablesでは、この情報と自動会計定義を使用して、適用可能なトランザクション・タイプのトランザクションに使用する勘定を決定します。

収益

トランザクション・タイプで運送費が許可されていない場合を除き、収益勘定を入力します。

クレジット・メモに使用される請求書会計プロファイル・オプションが「いいえ」に設定されている場合、クレジット・メモ・トランザクション・タイプに収益勘定は必要ありません。

運送費

トランザクション・タイプで運送費が許可されていない場合を除き、運送費勘定を入力します。

売掛/未収金

すべてのトランザクション・タイプに対して売掛/未収金勘定を入力します。

トランザクション・タイプの「GL転記」オプションが有効になっている場合、Receivablesはこの勘定科目を使用して売掛/未収金トランザクション・レコードを作成し、会計を一般会計に転送して仕訳を作成します。

チャージバック・トランザクション・タイプの場合、売掛/未収金チャージバック勘定を入力します。元の借方トランザクションの売掛/未収金勘定に対する相殺は、チャージバック修正によって生成されます。

クレジット・メモに使用される請求書会計プロファイル・オプションが「いいえ」に設定されている場合、クレジット・メモ・トランザクション・タイプに売掛/未収金勘定は必要ありません。

自動インボイス決済

これが請求書またはデビット・メモのトランザクション・タイプの場合は、自動インボイス決済勘定を入力します。Receivablesでは、この勘定を使用して、収益勘定に指定された収益金額と、販売価格にインポート済請求書明細の数量を乗算した金額との差異を保持します。

Receivablesで自動インボイス決済勘定を使用するのは、「決済の作成」オプションが有効になっているトランザクション・ソースを含むインポート済トランザクションのみです。「決済の作成」オプションが有効になっていない場合、自動インボイスでは、請求書の収益金額が販売価格に数量を乗算した金額に等しいか、請求書が拒否される必要があります。

税金

これが請求書、クレジット・メモまたはデビット・メモのトランザクション・タイプの場合は、税勘定を入力します。

未請求売掛金

これが請求書またはクレジット・メモのトランザクション・タイプの場合は、未請求売掛金勘定を入力します。この勘定は、「未収」請求ルールを使用するトランザクション用です。

前受収益

104

これが請求書またはクレジット・メモのトランザクション・タイプの場合は、前受収益勘定を入力します。この勘定は、「前受」請求ルールを使用するトランザクション用です。

トランザクション・タイプに関するFAQ

トランザクション・タイプはどのような順序で作成しますか。

各トランザクション区分のトランザクション・タイプを作成し、トランザクション・タイプ間の依存関係を考慮できる方法で作成します。

次の順序でトランザクション・タイプを作成します。

クレジット・メモ・トランザクション・タイプ請求書トランザクション・タイプデビット・メモ・トランザクション・タイプチャージバック・トランザクション・タイプ

必要に応じて、トランザクション・ソースを作成する前に、トランザクション・ソースに追加するトランザクション・タイプを作成します。

延滞手数料を使用している場合、延滞手数料をデビット・メモとして提示する借方メモの区分を持つトランザクション・タイプ、および延滞手数料を利息請求書として提示する請求書の区分を持つトランザクション・タイプを作成します。これらのトランザクション・タイプの売掛/未収金勘定および収益勘定を指定します。Receivablesでは、延滞手数料の生成時に、自動会計ではなく、これらの勘定を使用します。

トランザクション・タイプを使用して顧客残高をレビューおよび更新するにはどうすればよいですか。

トランザクション・タイプの「未回収売掛/未収金」オプションを使用して、一時トランザクションまたは暫定トランザクションの承認サイクルを実装します。

たとえば、作成後にレビューする、特に重要なデビット・メモ、クレジット・メモ、対顧客勘定クレジット、チャージバックまたは請求書がある場合は、「未回収売掛/未収金」を「いいえ」に設定して「暫定」というトランザクション・タイプを定義し、適用可能なトランザクションに割り当てることができます。このトランザクション・タイプでは、顧客残高は更新されません。

これらのトランザクションをレビューおよび承認したら、「未回収売掛/未収金」を「はい」に設定して「最終」というトランザクション・タイプを定義し、同じトランザクションに割り当てることができます。これにより、これらのトランザクションで顧客残高が更新されます。

トランザクション・ソース

トランザクション採番に関するガイドライントランザクションに割り当てられているトランザクション・ソースの様々なオプションを使用して、トラン

105

ザクション採番要件を管理します。

特定のトランザクション・ソースに割り当てられたトランザクションにトランザクション採番を定義する場合は、次のガイドラインを参照してください。

文書連番トランザクション番号自動採番文書番号をトランザクション番号にコピー重複するトランザクション番号の許可クレジット・メモ・トランザクション・ソース

文書連番

必要に応じて、自動的に割り当てられるトランザクション番号に加え、各トランザクションに一意の番号を割り当てるための文書連番を定義します。

要件に応じて、文書連番に必要な設定が完了していることを確認します。

トランザクション番号自動採番

トランザクション・ソースを使用して作成する新しいトランザクションを自動的に採番するには、「トランザクション番号自動採番」オプションを有効にして、最終番号フィールドに番号を入力します。

たとえば、トランザクションの採番を1000から開始するには、最終番号999を入力します。Receivablesではトランザクション・ソースの最終番号フィールドが自動的に更新されるため、後でトランザクション・ソースをレビューして、生成された最終トランザクション番号を確認できます。

注意: トランザクション・ソースの最終トランザクション番号は、キャッシュが原因で、単なる推定となります。

トランザクション番号自動採番は、インポート済トランザクション・ソースと手動トランザクション・ソースの両方で使用できます。

文書番号をトランザクション番号にコピー

文書連番を使用していて、トランザクション・ソースに割り当てられたトランザクションの文書番号とトランザクション番号の両方と同じ番号を使用する場合は、「文書番号をトランザクション番号にコピー」オプションを有効にします。

欠番なしの文書連番を使用している場合に、欠番なしのトランザクション採番が必要な場合は、このオプションを有効にする必要があります。これにより、トランザクション番号が連続して生成され、欠落している番号がなくなります。

重複するトランザクション番号の許可

「重複するトランザクション番号の許可」オプションを有効にして、トランザクション・ソース内の重複するトランザクション番号を許可します。

このオプションは、トランザクション番号手動採番専用です。

106

クレジット・メモ・トランザクション・ソース

クレジットする請求書とは異なる方法でクレジット・メモを採番する場合は、クレジット・メモ・トランザクション・ソースを請求書トランザクション・ソースに割り当てます。

関連トピック

文書連番

自動インボイスと販売実績情報自動インボイスの処理中に、インポート済トランザクション明細の販売実績情報を提供する必要があるかどうかは、トランザクション・ソースの「販売実績の許可」オプションおよび売掛/未収金システム・オプション「営業担当必須」の設定によって決まります。

インポート済トランザクション明細の販売実績情報を渡すための要件は次のとおりです。

「営業担当必須」システム・オプションとトランザクション・ソースの「販売実績の許可」オプションの両方が有効になっている場合、販売実績情報を提供する必要があります。「営業担当必須」システム・オプションが有効でなく、トランザクション・ソースの「販売実績の許可」オプションが有効になっている場合、販売実績情報を提供できますが、必須ではありません。「営業担当必須」システム・オプションが有効で、トランザクション・ソースの「販売実績の許可」オプションが有効になっていない場合、販売実績情報を提供する必要があります。「営業担当必須」システム・オプションとトランザクション・ソースの「販売実績の許可」オプションの両方が有効になっていない場合、販売実績情報は提供できません。自動インボイスは渡される値をすべて無視します。

自動インボイスによるインポート済トランザクションの検証方法インポート済トランザクション・ソースの「自動インボイス・オプション」セクションおよび「情報のインポート」セクションを使用して、自動インボイスでインポート済トランザクション明細を検証する方法を定義します。

トランザクション・ソースで参照されるすべてのフィールドの値を渡す必要はありません。自動インボイスによって特定のデータが渡されないようにする場合、関連オプションを「なし」に設定できます。

注意: この情報がインタフェース表にインポートされないようにするために、トランザクション・ソース・データ・オプションを「なし」に設定した場合でも、自動インボイスは無効なデータを含むトランザクション明細を検証および拒否できます。

インポート済トランザクションの検証に影響する設定

次の設定は、インポート済トランザクションの検証に影響します。

「無効明細」フィールド: 「請求書の拒否」または「請求書の作成」を選択して、自動インボイスで無効な明細を含むインポート済トランザクションを処理する方法を指定します。

「請求書の拒否」を選択した場合、自動インボイスはこのトランザクションまたはその明細を

107

インタフェース表にインポートしません。「請求書の作成」を選択した場合、自動インボイスは有効な明細のみを含むトランザクションを作成します。たとえば、3つの請求書明細を含む請求書をインポートし、いずれかの明細が無効であるとします。自動インボイスは、2つの有効な明細のみを含む請求書を作成し、無効な明細を拒否します。「トランザクションの編集」ページを使用して、拒否された明細を追加できます。

「クローズ期間の会計日」フィールド: クローズした会計期間内のインタフェース明細表に明細があるインポート済トランザクションを自動インボイスで処理する方法を指定します。

「修正」を選択した場合、自動インボイスは会計日を次のオープン期間または先日付入力可能期間の最初の会計日に自動的に修正します。「拒否」を選択した場合、これらのトランザクション明細を拒否します。

「情報のインポート」セクションで、必要に応じて各オプションの「番号」、「値」、「セグメント」または「ID」を選択し、自動インボイスで情報を検証する方法を指定します。

「番号」を選択した場合、割り当てられた番号を使用してレコードをインタフェース表にインポートします。「値」を選択した場合、実際の名前を使用してレコードをインタフェース表にインポートします。

注意: トランザクション・ソースを使用してOracle以外のシステムからデータをインポートする場合は、「値」を使用します。

「セグメント」を選択した場合、フレックスフィールド・セグメントを使用します。「ID」を選択した場合、レコードの内部識別子を使用します。

「金額」または「パーセント」を選択して、自動インボイスでトランザクション明細の販売実績および収益勘定配賦を検証する方法を指定します。

インポート済トランザクションの検証方法

自動インボイスでは、割り当てられたインポート済トランザクション・ソースの設定に基づいて、インポートされたトランザクションを検証します。検証に失敗したトランザクションは、インポート自動インボイス検証レポートに表示されます。

自動インボイスは、特定の列値が相互に一致していることを確認します。これらの値は、1つのインタフェース表または複数のインタフェース表内に存在します。たとえば、収益スケジューリング・ルールを使用できないことがトランザクション・ソースで示された場合、自動インボイスは、請求ルール、収益スケジューリング・ルールおよび収益スケジューリング・ルール期間に渡された値を無視します。

自動インボイスは、収益スケジューリング・ルールを使用して、トランザクション明細に対して次の検証を実行します。

収益スケジューリング・ルールを使用するトランザクションをインポートする場合、これらのトランザクションに請求ルールも含まれている必要があります。収益スケジューリング・ルールに重複する期間がある場合、明細を拒否します。指定された会計期間が収益スケジューリング・ルールの期間に存在しない場合、明細を拒否します。

CPQ CloudおよびReceivablesの処理の実装方法CPQ CloudおよびReceivablesを設定して、見積-入金の統合クラウド・サービスを有効にします。この統合サービスにより、見積、価格設定、オーダー入力、与信チェックおよび請求のプロセス全体を管理できま

108

す。

CPQ Cloud/Receivables統合サービスを設定するには、次のタスクの1つ以上を実行します。

CPQ CloudおよびCPQ Cloudデータを設定します。Receivablesトランザクション・ソースを設定します。複数のCPQ Cloudインスタンスを設定します。

CPQ Cloudの設定

CPQ管理ページを使用して、CPQ Cloudで必要な設定を実行します。

CPQ Cloud/Receivablesの見積-入金のクラウド・サービスで使用される、各統合サービスのデータ表定義を作成します。

与信チェック・サービス: 顧客信用価値を検証するサービス。売掛/未収金請求書サービス: CPQ CloudからReceivablesの自動インボイス・インタフェース表にオーダー明細を転送するサービス。

各データ表定義には、次の属性が含まれます。

エンドポイントURL: サービスへの接続に使用するURL。ユーザー名: サービスによって認識される有効なユーザー名。パスワード: 有効なユーザーに付随するパスワード。

CPQ Cloudトランザクション・ソースの設定

Receivablesでは、CPQ Cloud/Receivables統合サービスを構成するために使用する共通参照セットの下に、インポート済トランザクション・ソースが提供されます。

このトランザクション・ソースを使用して、次のことを行います。

CPQ Cloudから自動インボイス・インタフェース表へのトランザクション情報の転送を管理します。トランザクションが作成された後にReceivablesのトランザクション情報をCPQ Cloudに送信するコール・バック・サービスを管理します。

CPQ Cloudのトランザクション・ソースを設定する手順は、次のとおりです。

1. 「トランザクション・ソースの編集」ページにナビゲートします。2. CPQ Cloudトランザクション・ソースを開きます。3. 必要に応じて、法的エンティティを入力します。4. 必要に応じて、「日付: 自」フィールドおよび「日付: 至」フィールドを更新します。5. 「Oracle CPQ Cloud統合」セクションで、「使用可能」オプションを選択します。6. 「定義」ボタンをクリックして、「エンドポイント・ポリシーの定義」ウィンドウを開きます。7. 「URL」フィールドに、コール・バック・サービスへの接続に使用するURLを入力します。8. 「セキュリティ・ポリシー」フィールドに、oracle/wss_username_token_over_ssl_client_policyと入力します。

9. 「ユーザー名」フィールドに、コール・バック・サービスに使用するユーザー名を入力します。10. 「パスワード」フィールドに、有効なユーザーに付随するパスワードを入力します。

109

11. 「保存してクローズ」ボタンをクリックして、「エンドポイント・ポリシーの定義」ウィンドウを終了します。

12. 「トランザクション・ソースの編集」ページを保存して閉じます。

複数のCPQ Cloudインスタンスの設定

Receivablesにデータを送信するCPQ Cloudインスタンスを複数使用する予定がある場合は、各CPQインスタンスをビジネス・ユニットとして表し、各インスタンスのトランザクション・ソースを定義する必要があります。

複数のCPQ Cloudインスタンスを設定する手順は、次のとおりです。

1. CPQ Cloudインスタンスごとに参照セットを1つ定義します。2. この参照セットを、参照オブジェクト・トランザクション・ソースのビジネス・ユニットに関連付けます。

3. 各参照セットのトランザクション・ソースを作成します。a. 「トランザクション・ソースの作成」ページを開きます。b. 「トランザクション・ソース・セット」フィールドで、ビジネス・ユニットに適用可能な参照セットを選択します。

c. 必要に応じて、法的エンティティを入力します。d. 「名前」フィールドおよび「摘要」フィールドに、このトランザクション・ソースの名前および説明を入力します。

e. 「タイプ」フィールドで、「インポート済」を選択します。f. 必要に応じて、「日付: 自」フィールドおよび「日付: 至」フィールドを更新します。g. トランザクション・ソースの残りのフィールドは、事前定義済トランザクション・ソースと同じ設定で入力します。

h. 「Oracle CPQ Cloud統合」セクションで、「使用可能」オプションを選択し、エンドポイント・ポリシーを完了します。

i. 「トランザクション・ソースの作成」ページを保存して閉じます。

トランザクション・ソースに関するFAQ

トランザクション・ソースを作成する前に作成するものは何ですか。

トランザクション・ソースを作成する前に、特定のレコードを作成する場合があります。

オプションで、手動またはインポート済トランザクション・ソース用に次のオブジェクトを作成できます。

トランザクション・タイプ: トランザクション・ソースに割り当てられたトランザクションにデフォルトで表示されるトランザクション・タイプを定義します。クレジット・メモ・トランザクション・ソース: 請求書のトランザクション・ソースを定義する前に、クレジット・メモのトランザクション・ソースを定義します。このトランザクション・ソースを使用して、クレジットしている請求書とは異なる方法で請求書に対して作成されたクレジット・メモを採番します。

オプションで、インポート済トランザクション・ソース用に次のオブジェクトを作成できます。

請求書トランザクション・フレックスフィールド: 請求書トランザクション・フレックスフィールド

110

に取得し、インポートされたトランザクションに表示される参照情報(購買オーダー番号など)を定義します。自動インボイス・グループ・ルール: インポートされたトランザクション明細にデフォルトで表示されるグループ・ルールを定義します。自動インボイス決済勘定: 「決済の作成」オプションを有効にする場合、自動インボイス決済勘定を定義します。自動インボイスでは、トランザクションの収益金額と、販売価格に数量を乗算した金額との差異がこの勘定に格納されます。

トランザクション・ソースを使用してクレジット・メモを管理するにはどうすればよいですか。

クレジット・メモのトランザクション・ソースの作成には、特殊条件が適用される場合があります。

クレジット・メモに割り当てられたトランザクション・ソースについて、次の考慮事項をレビューします。

クレジット・メモ要求承認プロセスで作成されたクレジット・メモの手動トランザクション・ソースを定義します。クレジット・メモに使用される手動トランザクション・ソースの「トランザクション情報フレックスフィールドをクレジット・メモにコピー」オプションを有効にし、請求書トランザクション・フレックスフィールドの参照情報を、請求書をクレジットしているクレジット・メモにコピーします。クレジットしている請求書とは異なる方法で請求書に対して作成されたクレジット・メモを採番する場合、クレジット・メモのトランザクション・ソースを定義して、請求書のトランザクション・ソースに割り当てます。

自動インボイス・グループ・ルールを入力しないとどうなりますか。

自動インボイスでインポート済トランザクション明細のグループ化に使用するインポート済トランザクション・ソースに、自動インボイス・グループ・ルールを割り当てます。

インポート済トランザクション・ソースにグループ・ルールを割り当てなかった場合、自動インボイスは次の階層を使用して、使用するルールを決定します。

1. トランザクション明細のトランザクション・ソースに割り当てられたグループ・ルール。2. トランザクション明細の請求先顧客サイト・プロファイルに割り当てられたグループ・ルール。3. トランザクション明細の請求先顧客プロファイルに割り当てられたグループ・ルール。4. 売掛/未収金システム・オプションに割り当てられたグループ・ルール。

決済勘定を作成しないとどうなりますか。

自動インボイス決済勘定を使用せず、トランザクション・ソースの「決済の作成」オプションを有効にした場合、自動インボイスでは、収益金額が、販売価格に処理するすべてのトランザクションの数量を乗算した金額に等しくなる必要があります。自動インボイスは、この要件を満たさないトランザクション明細を拒否します。

メモ明細

111

収益勘定とメモ明細オプションで、収益勘定をメモ明細に関連付けることができます。

自動会計がメモ明細に依存する場合、Receivablesはメモ明細に定義された収益勘定セグメント値を自動会計構成の残りの部分と組み合せて使用して、メモ明細を含む請求書のデフォルト収益、運送費、自動インボイス決済、税金、未請求売掛金、前受収益および売掛/未収金勘定を決定します。

メモ明細のあるデビット・メモまたは対顧客勘定クレジット・メモを作成した場合、Receivablesでは、当初売掛/未収金品目の収益勘定をクレジット勘定として使用します。ただし、デビット・メモ戻し処理またはチャージバックを作成する場合、Receivablesでは、かわりに当初売掛/未収金品目の収益フレックスフィールドを貸方勘定として使用します。

関連トピック

デビット・メモ戻し処理

メモ明細に関するFAQ

メモ明細はいつ使用しますか。

品目が在庫品目でない場合は、トランザクションでメモ明細を使用します。たとえば、コンサルティング・サービスと呼ばれるメモ明細を定義して、コンサルティング活動の手数料を識別できます。メモ明細は、デビット・メモ、対顧客勘定クレジット、デビット・メモ戻し処理、チャージバックおよび請求書に割り当てることができます。

税金メモ明細を使用するにはどうすればよいですか。

税金定義でトランザクションに手動税金明細を入力できる場合のみ、トランザクションで税金メモ明細を使用できます。トランザクションに税金メモ明細を入力した後、トランザクション明細に割り当てる税金金額を指定できます。

繰越残高請求

顧客アカウントおよびサイトの繰越残高請求繰越残高請求詳細は、顧客アカウント・レベルおよび顧客サイト・レベルで有効にして保守できます。顧客アカウントと顧客サイトの間の顧客対応を管理するルールによって、繰越残高請求に含まれるサイトが決まります。

アカウントおよびサイトの繰越残高請求のルール

次のルールは、アカウント・レベルおよびサイト・レベルの繰越残高請求に適用されます。

サイト・プロファイルを作成すると、アカウント・レベルの顧客プロファイル値が、関連する顧客サ

112

イトのデフォルト値になります。繰越残高請求がアカウント・レベルで有効になっている場合でも、これらのサイトをアカウント・レベルの繰越残高請求書に含めるには、関連サイト・プロファイルで繰越残高請求を有効にする必要があります。サイト・プロファイルの「繰越残高請求」セクションで、次のようにします。

「使用可能」オプションを設定します。「請求レベル」フィールドで、「アカウント」を選択します。「請求タイプ」フィールドで、アカウント・レベルで定義されている請求タイプを選択します。

特定のサイトについて個別の繰越残高請求詳細を定義できます。サイト・プロファイルの「繰越残高請求」セクションで、次のようにします。

「使用可能」オプションを設定します。「請求レベル」フィールドで、「サイト」を選択します。「請求タイプ」フィールドで、このサイトに使用する請求タイプを選択します。

サイト・プロファイルを作成して、個別の繰越残高請求詳細を定義すると、そのサイト・プロファイルはアカウント・プロファイルを参照しなくなります。サイト・レベルの繰越残高請求定義は、アカウント・レベルの繰越残高請求定義よりも優先されます。

関連トピック

繰越残高請求の概要

繰越残高請求の設定の例この例は、顧客Business Worldの繰越残高請求を設定する方法を示しています。この例には、繰越残高請求サイクル、繰越残高請求支払条件およびBusiness Worldの顧客プロファイルの設定が含まれています。

この表には、このシナリオの重要な意思決定が要約されています。

検討事項 この例の場合

どの請求サイクルが使用されますか。 月次

支払条件に使用されるのは1か月のうちのどの日付ですか。 15th

繰越残高請求書はどのように統合されますか。 アカウント・レベル

顧客は繰越残高請求書からトランザクションを除外できますか。 はい

タスクの概要

顧客の繰越残高請求書を生成する手順は、次のとおりです。

1. 繰越残高請求サイクルを定義します。2. 繰越残高請求支払条件を定義します。3. 繰越残高請求の顧客プロファイル区分を設定します。4. プロファイル区分をBusiness Worldの顧客アカウントに割り当てます。

113

繰越残高請求サイクルの定義

この顧客に使用する繰越残高請求サイクルを定義します。

1. 「繰越残高請求サイクル」ウィンドウを開きます。2. 次の表に示すように、フィールドに情報を入力します。

フィールド 値

名前 この顧客のこの繰越残高請求サイクルを識別する名前。

頻度 月次

繰返し間隔 1

月日付 月末日

繰越残高請求支払条件の定義

この顧客に使用する繰越残高請求支払条件を定義します。

1. 「支払条件の作成」ページを開きます。2. 次の表に示すように、フィールドに情報を入力します。

フィールド 値

名前 この顧客のこれらの支払条件を識別する名前。

請求サイクル 前のステップで定義した請求サイクル。

期日: 月日付 15

繰越残高請求の顧客プロファイル区分の設定

繰越残高請求用のBusiness Worldの顧客プロファイルを設定します。

1. 「売掛/未収金顧客プロファイル区分の作成」ページを開きます。2. プロファイル区分の一般的な必須フィールドへの入力を完了します。3. 次の表に示すように、「プロファイル区分」タブのフィールドに値を入力します。

フィールド 値

繰越残高請求使用可能 このオプションを有効にします。

請求レベル アカウント

請求タイプ 詳細

支払条件 前のステップで定義した繰越残高請求支払条件。

条件上書き このオプションを有効にします。

注意: 「条件上書き」オプションを使用すると、非繰越残高請求支払条件と前のステップで定義

114

した1つの繰越残高請求支払条件の両方をトランザクションで使用できます。これにより、トランザクションに非繰越残高支払条件を割り当てることで、個々のトランザクションを繰越残高請求から除外できます。

Business Worldの顧客アカウントへのプロファイル区分の割当

プロファイル区分をBusiness Worldのアカウントに割り当てます。

1. Business Worldの「アカウントの編集」ページを開きます。2. 「プロファイル」タブをクリックします。3. 「アカウント・プロファイルの挿入」ページを開き、前のステップで定義したプロファイルでBusiness Worldの顧客アカウントを更新します。

4. 繰越残高請求が、繰越残高請求に含める顧客アカウントに属するすべてのサイトのサイト・プロファイル・レベルで使用可能になっていることを確認してください。

関連トピック

顧客の請求サイクルをどのように変更できますか繰越残高請求のトランザクションを選択する方法

繰越残高請求のEメール送信繰越残高請求書のEメール送信

繰越残高請求書を、顧客アカウントまたはサイト・レベルの担当者にEメールでPDF添付として送信します。

繰越残高請求書は、請求書を印刷する既存の機能に加えて、顧客に直接Eメールで送信できます。

繰越残高請求書のEメール送信の設定この機能をオプト・インして有効にし、Receivablesで関連する設定を完了する必要があります。

繰越残高請求書のEメール送信の設定には、次のものがあります。

売掛/未収金システム・オプション: Eメールを使用したトランザクション送信顧客アカウント・プロファイルおよび顧客サイト・プロファイル顧客アカウント担当者および顧客サイト担当者

繰越残高請求書の更新プロセス繰越残高請求書のEメール送信を有効にして設定すると、次の予定済プロセスを使用して繰越残高請求書を生成できます。

繰越残高請求書の作成: 繰越残高請求書をPDFとして生成し、Eメールで送信します。繰越残高請求書の送信: 指定された送信方法(紙またはEメール)を使用して、以前送信した繰越残高請求書を送信します。「繰越残高請求書要約の印刷」および「繰越残高請求書詳細の印刷」: 送信方法「紙」を使用して、以前送信した繰越残高請求書を引き続き送信します。

115

「繰越残高請求書の作成」プロセスには、追加パラメータ「ドラフトEメールID」が含まれています。繰越残高請求書をドラフト・モード(「印刷オプション」パラメータ = 「ドラフト繰越残高請求書の印刷」)で作成した場合は、このパラメータを使用して、テストおよびレビューのために選択したEメール・アドレスにドラフト請求書を送信できます。

「ドラフトEメールID」パラメータは自由テキスト・フィールドですが、入力するEメール・アドレスはEメール・アドレスの標準形式(abc@xyz.pqr)に準拠している必要があります。このパラメータにEメール・アドレスを指定して「繰越残高請求書の作成」プロセスを実行すると、このEメール・アドレスは、Eメール送信のみが有効な顧客に対して実行されたプロセスによって生成されたすべての繰越残高請求書のPDFを受信します。

「繰越残高請求書の作成」プロセスでは、次のいずれの条件でもエラーは生成されません。

入力したEメール・アドレスが存在しません。入力したEメール・アドレスは存在しますが、それは対象となるEメール・アドレスではありません。Eメール受信者の受信ボックスが一杯です。

繰越残高請求書の送信プロセス繰越残高請求書のEメール送信機能により、「繰越残高請求書の送信」プロセスで、該当する顧客に前回の繰越残高請求書(紙またはEメール)を送信できます。

「繰越残高請求書の送信」プロセスを使用して、以前に作成した繰越残高請求書を顧客に送信します。「プロセスID」パラメータに、前回の繰越残高請求書の実行のプロセスIDを入力します。このプロセスは、Eメール送信が有効なすべての顧客アカウント・プロファイルおよび顧客サイト・プロファイルに、請求書をPDF添付としてEメールで送信します。

繰越残高請求書のEメール送信の設定方法

「繰越残高請求」を使用すると、顧客アカウントまたはサイト・レベルの担当者に、繰越残高請求書をPDF添付としてEメールで送信できます。

繰越残高請求書のEメール送信機能をオプト・インして有効にする必要があります。Eメールで繰越残高請求書を送信するには、オプト・イン後に次の設定を完了する必要があります。

売掛/未収金システム・オプションの「請求および収益」タブの「Eメールを使用したトランザクション送信」セクションを設定します。繰越残高請求およびEメール送信用に、該当する顧客アカウント・プロファイルおよび顧客サイト・プロファイルを設定します。繰越残高請求書をEメールで受信する顧客アカウントおよびサイトごとに担当者を設定します。

売掛/未収金システム・オプション該当するビジネス・ユニットの「売掛/未収金システム・オプション」の「Eメールを使用したトランザクション送信」セクションのフィールドに入力する必要があります。

トランザクションのEメール送信にこのセクションをすでに使用している場合は、繰越残高請求書に同じ値を使用したり、要件に応じて個々のフィールドを更新することができます。たとえば、トランザクションと繰越残高請求書の両方に対応するように、「Eメール件名」フィールドおよび「Eメール本文」フィールドを編集する必要がある場合があります。

繰越残高請求書のEメール送信用に売掛/未収金システム・オプションを設定する手順は、次のとおりです。

116

1. 目的のビジネス・ユニットの「システム・オプションの作成」ページまたは「システム・オプションの編集」ページで、「請求および収益」タブの「Eメールを使用したトランザクション送信」セクションにナビゲートします。

2. 繰越残高請求書のEメール送信用に、このセクションのすべてのフィールドに入力します。これらのフィールドは、条件付きで必須です。繰越残高請求書がEメールで正常に送信されるように、これらのフィールドに値を入力する必要があります。

3. 作業内容を保存します。

顧客アカウント・プロファイルおよび顧客サイト・プロファイル該当する顧客アカウント・プロファイルおよび顧客サイト・プロファイルで繰越残高請求を設定し、優先送信方法にEメールを設定する必要があります。

注意: 繰越残高請求書のEメール送信機能ではXML送信を使用できません。この機能では、優先送信方法XMLは紙とみなされます。

繰越残高請求書のEメール送信用に顧客アカウントまたはサイトを設定する手順は、次のとおりです。

1. 目的の顧客アカウントまたはサイトの「アカウントの編集」ページまたは「サイトの編集」ページにナビゲートします。

2. 「プロファイル履歴」タブをクリックします。3. 顧客アカウントまたはサイトのプロファイルを更新または挿入します。4. 「プロファイル」タブの「繰越残高請求」セクションで、次のフィールドに入力します。

使用可能: 繰越残高請求をアクティブ化するには、このオプションを有効にします。請求レベル: 繰越残高請求書を生成するレベルを選択します(「アカウント」または「サイト」)。顧客サイト・プロファイルの場合、サイトに属するトランザクションをアカウント・レベルの繰越残高請求書に含めるには、請求レベル「アカウント」を選択します。サイトに属するトランザクションに対して個別の繰越残高請求書を送信するには、請求レベル「サイト」を選択します。

注意: 繰越残高請求を正常に処理するには、使用する請求レベルの設定に関係なく、顧客アカウント・レベルとサイト・レベルの両方でアクティブな顧客プロファイルを設定する必要があります。

請求タイプ: 繰越残高請求書に使用する書式を選択します。5. 「条件」セクションの「支払条件」フィールドで、このアカウントまたはサイトに使用する繰越残高請求支払条件を選択します。

6. 「請求」セクションの「優先送信方法」フィールドで、「Eメール」を選択します。プロファイルの「請求レベル」設定が「アカウント」の場合、「繰越残高請求書の作成」プロセスは顧客アカウント・プロファイルの「優先送信方法」設定を参照します。プロファイルの「請求レベル」設定が「サイト」の場合、「繰越残高請求書の作成」プロセスは顧客サイト・プロファイルの「優先送信方法」設定を参照します。

7. 要件に応じてプロファイルを入力し、保存します。

顧客アカウント担当者および顧客サイト担当者繰越残高請求書をEメールで受信するアカウントまたはサイトごとに、少なくとも1人の顧客担当者を設定する必要があります。

117

Eメールで繰越残高請求書を受信するには、顧客担当者に次のすべての設定が必要です。

担当者のロール・タイプの割当。アクティブなEメール・アドレス。回収または督促以外の職責の職責タイプの割当。

注意: 顧客担当者をプライマリとして指定した場合でも、該当する顧客アカウントまたはサイトに割り当てられているすべての担当者にEメールで繰越残高請求書が送信されます。

繰越残高請求書のEメール送信用に顧客アカウントまたはサイトの担当者を設定する手順は、次のとおりです。

1. 目的の顧客アカウントまたはサイトの「アカウントの編集」ページまたは「サイトの編集」ページにナビゲートします。

2. 「通信」タブをクリックします。3. 「担当者の編集」ボタンをクリックします。4. 該当するいずれかのプラス(+)アイコン(「担当者の作成」または「担当者の追加」)をクリックして、担当者の新しい個人レコードを作成するか、既存の個人レコードを担当者として追加します。

5. 要件に応じて、担当者の名前および関連するジョブ情報を入力します。6. 「ロール・タイプ」フィールドで、「担当者」を選択します。7. オプションで、この担当者の「プライマリ担当者の設定」アイコンをクリックします。8. 「連絡先」セクションで、プラス(+)アイコンをクリックして、「連絡先の作成」ウィンドウを開きます。

9. 「連絡先タイプ」フィールドで、「Eメール」を選択します。10. 「Eメール」フィールドに、担当者のEメール・アドレスを入力します。11. 「日付: 自」フィールドおよび「日付: 至」フィールドに、この連絡先がこの担当者に対してアク

ティブである日付を入力します。12. オプションで、この連絡先の「プライマリの設定」アイコンをクリックします。13. 「職責」セクションで、プラス(+)アイコンをクリックして、職責行を作成します。14. 「職責タイプ」フィールドで、この担当者の職責を選択します。15. オプションで、プラス(+)アイコンを再度クリックして、担当者の追加職責を作成します。

繰越残高請求書のEメール送信では、回収または督促以外の職責を担当者に割り当てることができます。

16. 担当者のプライマリ職責を設定するには、職責を選択して、「プライマリ職責の設定」アイコンをクリックします。

17. 作業内容を保存します。

関連トピック

Eメールを使用したトランザクションおよび取引明細書の送信の仕組み

繰越残高請求に関するFAQ

繰越残高請求サイクルとはなんですか。

繰越残高請求サイクルでは、繰越残高請求書を生成する年の日付および繰越残高請求書に含まれるトランザ

118

クションを決定します。繰越残高請求サイクルを支払条件に割り当てます。

「繰越残高請求書の作成」プログラムを実行する場合、請求サイクルを選択する必要があります。特定の顧客、顧客サイトおよび支払条件を選択することもできます。「繰越残高請求書の作成」プログラムの実行には、支払条件と選択した請求サイクル、または他のプログラム・パラメータによって決定されたこれらの支払条件のサブセットが割り当てられている、前回の繰越残高請求書に含まれていないすべてのトランザクションが含まれます。

営業担当参照勘定に関するFAQ

営業担当参照勘定とは何ですか。総勘定元帳勘定科目を営業担当に割り当てます。自動会計が営業担当に依存する場合、Receivablesはここで定義した勘定参照を使用して、特定の営業担当が割り当てられているトランザクションで使用する勘定科目を導出します。

送金先住所に関するFAQ

送金先住所を使用する方法送金先住所により、顧客は未回収借方品目の支払の送信先を把握できます。送金先住所を作成した後、国および該当する場合は地域と郵便番号の範囲で指定した顧客および顧客サイトの請求先住所に割り当てることができます。

売掛/未収金システム・オプション「送金先住所の印刷」が有効な場合、関連する顧客督促状および取引明細書に送金先住所が印刷されます。

自動インボイスが送金先住所を検証する方法インポート・プロセス中、自動インボイスは、送金先住所を決定できないすべての請求書を拒否します。自動インボイスで請求書をインポートするには、該当する各請求先サイトの地域の送金先住所を定義するか、1つ以上の場所のデフォルトとして使用する送金先住所を定義する必要があります。

デフォルトの送金先住所を定義する方法送金先住所を作成または選択し、「基準から入金」ダイアログ・ボックスを開きます。この送金先住所に割り当てる国を選択します。

国のみを選択した場合は、この国のすべての顧客請求先サイトにこの送金先住所が割り当てられます。

この送金先住所を国内の特定の場所に割り当てる場合は、国内の州または地域、および郵便番号の範囲をオ

119

プションで選択できます。

国が表示された理由送金先住所を作成する場合、売掛/未収金システム・オプションで国が定義されていれば、デフォルトで国が表示されます。このデフォルトは、送金先住所の該当する国に変更できます。

住所を確認する理由取引先コミュニティ・データ品質がインストールされている場合、該当する国の「送金先住所の作成」ページおよび「送金先住所の編集」ページに「住所の検証」ボタンを表示できます。

送金先住所を入力した後、「住所の検証」ボタンを使用して、その住所が取引先コミュニティ・モデルのレジストリにあることを確認します。ない場合は、Receivablesによって代替住所が示されるか、またはオプションで入力した住所をレジストリに追加できます。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

120

19c

現預金のための売掛/未収金クレジットの実装

4 顧客支払の定義この章の内容は次のとおりです。

Receivablesでの共有サービス・モデルの作成消込ルール・セット入金区分および入金方法ロックボックスロックボックスの伝送フォーマット自動照合ルール・セット消込例外ルール・セット顧客支払関係入金ソースに関するFAQ

Receivablesでの共有サービス・モデルの作成サービス・プロバイダ関係を使用し、Receivablesで共有サービス・モデルを作成して顧客支払の処理を集中化します。

共有サービス・モデルで、顧客支払に対してサービス・ビジネス・ユニットを1つ定義します。次に、このサービス・ビジネス・ユニットと1つ以上のクライアント請求ビジネス・ユニットの間でサービス・プロバイダ関係を作成します。

注意: すべてのビジネス・ユニットが同じ元帳に属している必要があります。

この関係を定義した後、サービス・ビジネス・ユニットはそのすべてのクライアント請求ビジネス・ユニットの支払を受領して処理できます。集中化された顧客支払処理の共有サービス・モデルは、Receivablesのすべての入金作成方法をサポートします。

121

手動入金。スプレッドシートを使用してアップロードされた入金。ロックボックス入金。自動入金。

Receivablesには、顧客支払の処理を容易にするために、ビジネス・ユニット間の入金処理に追加機能が用意されています。

サービス・プロバイダ関係外の請求ビジネス・ユニットが、同じ元帳の他のビジネス・ユニットによって処理されたトランザクションの支払を行うことを許可します。同じ元帳の任意のビジネス・ユニットのトランザクションに個々の入金を消し込むことを許可します。

Receivablesで共有サービスを管理する手順は、次のとおりです。

顧客支払サービス・プロバイダの定義ビジネス・ユニット間の入金処理に関する売掛/未収金システム・オプションの定義ビジネス・ユニット間の処理に対する入金の有効化

顧客支払サービス・プロバイダの定義この手順の各ステップを実行して、サービス・ビジネス・ユニットおよびクライアント請求ビジネス・ユニットを定義します。

1. サービス・ビジネス・ユニットおよびクライアント・ビジネス・ユニットを作成します。2. 各ビジネス・ユニットに適切なビジネス機能を割り当てます。

a. サービス・ビジネス・ユニットの「ビジネス機能の割当」ページを開きます。b. サービス・ビジネス・ユニットにビジネス機能を割り当てます。少なくとも、サービス・ビジネス・ユニットに「顧客支払」ビジネス機能を割り当てる必要があります。

c. 作業内容を保存します。d. 最初のクライアント・ビジネス・ユニットの「ビジネス機能の割当」ページを開きます。e. クライアント・ビジネス・ユニットにビジネス機能を割り当てます。少なくとも、クライアント・ビジネス・ユニットに「請求/収益管理」ビジネス機能を割り当てる必要があります。

f. 作業内容を保存します。g. クライアント・ビジネス・ユニットごとに、ステップ4から6を繰り返します。

3. 各クライアント・ビジネス・ユニットにサービス・ビジネス・ユニットを割り当てます。a. 「サービス・プロバイダ関係の管理」タスクから、最初のクライアント・ビジネス・ユニットの「サービス・プロバイダの管理」ページを開きます。

b. 「顧客支払サービス・プロバイダ」セクションで、「追加」アイコンをクリックします。c. 「検索と選択」ウィンドウで、サービス・ビジネス・ユニットを選択します。d. 作業内容を保存します。e. クライアント・ビジネス・ユニットごとに、ステップ1から4を繰り返します。

ビジネス・ユニット間の入金処理に関する売掛/未収金システム・オプションの定義

122

この手順の各ステップを実行して、サービス・プロバイダ関係外の請求ビジネス・ユニットが、同じ元帳の他のビジネス・ユニットによって処理されたトランザクションの支払を行うことを許可します。

1. 「売掛/未収金システム・オプションの管理」タスクから、目的のビジネス・ユニットの「システム・オプションの編集」ページを開きます。

2. 「請求および収益」タブ・リージョンにナビゲートします。3. 「ビジネス・ユニットによる入金処理の許可」オプションを有効にします。4. 作業内容を保存します。このビジネス・ユニットは、同じ元帳の他のビジネス・ユニットによって処理されたトランザクションの支払を行うことができるようになりました。

ビジネス・ユニット間の処理に対する入金の有効化この手順の各ステップを実行して、同じ元帳の任意のビジネス・ユニットに属する1つ以上のトランザクションに個々の入金を消し込みます。

1. 「入金の作成」ページを使用して新しい入金を作成するか、「入金の編集」ページを使用して未消込入金を開きます。

2. 「消込」タブ・セクションで、「未回収売掛/未収金の追加」ボタンをクリックします。3. 「未回収売掛/未収金の追加」ウィンドウで、「すべてのビジネス・ユニットからのトランザクションを含む」オプションを有効にします。

4. 入金を消し込むトランザクションを検索して選択します。同じ元帳の任意のビジネス・ユニットからトランザクションを選択できます。

5. 「追加」ボタンをクリックして、「完了」ボタンをクリックします。6. 必要に応じて、該当する各トランザクションの「消込済金額」フィールドの数値を更新します。7. 「保存」ボタンをクリックして、選択したトランザクションに入金を消し込みます。

消込ルール・セット

消込ルール・セットのルール入金またはクレジット・メモをトランザクションに消し込むと、消込ルール・セットによって、Receivablesでトランザクションの明細金額、税額、運送費および延滞手数料金額の未回収残高を減額する方法が決定されます。

Receivablesでは、トランザクション・タイプに割り当てられた消込ルール・セットを使用して、支払消込を処理します。トランザクション・タイプに消込ルール・セットが割り当てられていない場合は、売掛/未収金システム・オプションに割り当てられた消込ルール・セットが使用されます。

必要に応じて、消込ルール・セット内の明細タイプおよび消込ルールの順序を編成できます。各明細タイプが消込ルール・セットに含まれること、かつ1回のみ含まれることが必要です。超過消込ルールは、常に順序内の最後になります。

明細が先、税金が後ルール

123

明細が先、税金が後ルールは、最初に支払をオープン明細金額に消し込み、次にその残金を関連税金に消し込みます。

支払がオープン明細と税額の合計より大きい場合、Receivablesは次の順序で残金を消し込み、支払が全額消し込まれると停止することによって、残りの各オープン項目のクローズを試みます。

1. 運送費2. 延滞手数料

支払が全額消し込まれた後、入金額の残金がある場合は、この金額は超過消込ルールによって管理されます。

明細と税金で按分

明細と税金で按分ルールは、オープン明細および各明細の税額に比例配分された支払額を消し込みます。

支払がオープン明細と税額の合計より大きい場合、Receivablesは次の順序で残金を消し込み、支払が全額消し込まれると停止することによって、残りの各オープン項目のクローズを試みます。

1. 運送費2. 延滞手数料

支払が全額消し込まれた後、入金額の残金がある場合は、この金額は超過消込ルールによって管理されます。

すべてで按分

すべてで按分ルールは、借方品目に関連付けられた各未回収金額(つまり、この品目の明細金額、税額、運送費および延滞手数料金額)に比例配分された支払額を消し込みます。

Receivablesでは、次の算式を使用して消込済金額を決定します。

Applied Amount = open application line type amount / sum of application line types in rule details * Receipt Amount

支払が全額消し込まれた後、入金額の残金がある場合は、この金額は超過消込ルールによって管理されます。

超過消込ルール

超過消込ルールは、常に消込ルール・セット内の最後のルールとなります。このルールにより、すべてのトランザクション明細の未回収残高がゼロに減少された後の入金額の残金が管理されます。

借方品目のトランザクション・タイプで超過消込が許可されている場合、Receivablesによって残金がトランザクション明細に消し込まれ、未回収残高がマイナスになります。借方品目のトランザクション・タイプで超過消込が許可されていない場合、残金を対顧客勘定にするか、未消込のままにすることができます。

注意: ロックボックスでは、消込ルール・セットではなく自動消込ルール・セットを使用して、残金の消込方法を決定します。

124

関連トピック

通常消込および超過消込各自動消込ルールの使用例

消込ルールの使用例次の例は、消込ルール・セット内の各消込ルールがトランザクションに支払を消し込む方法を示しています。

請求書123に含まれる詳細は次のとおりです。

フィールド 値

明細 $1000

税金 $140

運送費 $200

合計 $1340

顧客はこの請求書に対して$1040の一部支払を送金します。この表は、Receivablesで3つの各消込ルールを使用して支払を消し込む方法を示しています。

消込ルール 消込済金額合計 消込済明細金額 消込済税額 消込済運送費

明細が先、税金が後 1040 1000 40 0

明細と税金で按分 1040 912.28 127.72 0

すべてで按分 1040 776.12 108.66 155.22

この表は、各消込ルールで使用される計算を示しています。

消込ルール 計算

明細が先、税金が後 1. 支払をオープン明細金額に消し込みます。2. 残金がある場合はこれを税金に消し込みます。

明細と税金で按分 1. (1040/1140) * 1000 = 912.28 (入金額 / 明細と税金の合計) * 明細金額 = 消込済明細金額2. (1040/1140) * 140 = 127.72 (入金額 / 明細と税金の合計) * オープン税額 = 消込済税額

すべてで按分 1. (1040/1340) x 1000 = 776.12 (入金額 / 請求書合計) * オープン明細金額 = 消込済明細金額2. (1040/1340) x 140 = 108.66 (入金額 / 請求書合計) * オープン税額 = 消込済税額3. (1040/1340) x 200 = 155.22 (入金額 / 請求書合計) x オープン運送費 = 消込済運送費

明細が先、税金が後

明細が先、税金が後ルールは、最初に支払を明細金額に消し込み、未回収残高をゼロに減らします。その後、Receivablesは残金($40)を税額に消し込み、オープン税額を$100に減らします。支払がこれらの品目をクローズするのに十分でないため、運送費残高は影響を受けません。

125

この表は、明細が先、税金が後ルールを使用して金額を消し込む前と後の各明細タイプの比較を示しています。

トランザクション金額 残金 明細品目 明細品目残高 税金 税金残高 運送費 運送費残高

$1340 $300 $1000 $0 $140 $100 $200 $200

明細と税金で按分

明細と税金で按分ルールは、オープン明細および税額に比例配分された金額を消し込みます。消し込まれた金額がこれらの品目をクローズするのに十分でないため、運送費残高は影響を受けません。

この表は、明細と税金で按分ルールを使用して金額を消し込む前と後の各明細タイプの比較を示しています。

トランザクション金額 残金 明細品目 明細品目残高 税金 税金残高 運送費 運送費残高

$1340 $300 $1000 $87.72 $140 $12.28 $200 $200

この表は、比例配分された金額に至るまでの計算を示しています。

項目 計算

明細品目 1000 - 912.28 = 87.72

金額明細品目 - 消込済明細金額 = オープン明細金額

税金 140 - 127.72 = 12.28

税金当初 - 消込済税額 = オープン税額

すべてで按分

すべてで按分ルールは、このトランザクションの明細、税金および運送費に比例配分された入金額を消し込みます。

この表は、すべてで按分ルールを使用して金額を消し込む前と後の各明細タイプの比較を示しています。

トランザクション金額 残金 明細品目 明細品目残高 税金 税金残高 運送費 運送費残高

$1340 $300 $1000 $223.88 $140 $31.34 $200 $44.78

この表は、比例配分された金額に至るまでの計算を示しています。

項目 計算

明細品目 1000 - 776.12 = 223.88

金額明細品目 - 消込済明細金額 = オープン明細金額

税金 140 - 108.66 = 31.34

税金当初 - 消込済税額 = オープン税額

運送費 200 - 155.22 = 44.78

運送費当初 - 消込済運送費 = オープン運送費

126

残高に混合符号を使用するトランザクションでの消込ルールの使用例この例は、すべてで按分消込ルールを使用して、残高に混合符号を使用するトランザクションに支払を消し込む方法を示しています。残高に混合符号を使用するトランザクションでは、トランザクションを構成する手数料にプラス符号とマイナス符号の組合せが含まれます。

残高に混合符号を使用するトランザクションに支払を消し込む場合、Receivablesでは支払と同じ符号の支払金額にのみ支払を消し込みます。たとえば、支払がプラスの金額に対するものである場合(つまり、これはクレジット・メモではありません)、Receivablesでは残高がプラスの手数料のみを減額します。マイナスの残高は影響を受けません。

残高に混合符号を使用するトランザクションの場合と同様、Receivablesでは、消込ルール・セットに割り当てられた超過消込ルールに従って、残金を消し込みます。

残高に混合符号を使用する場合のすべてで按分

請求書101に含まれる詳細は次のとおりです。

フィールド 値

明細 <$100>

税金 $100

運送費 $30

延滞手数料 $10

すべてで按分消込ルールを使用しているとします。顧客が$100の入金を送金します。Receivablesは、プラスの入金額を、プラスの税額、運送費および延滞手数料金額の間で按分します。<$100>の明細金額は影響を受けません。

この表は、入金消込後の請求書101の新しい残高を示しています。

フィールド 値

明細 <$100>

税金 $28.56

運送費 $8.58

延滞手数料 $2.86

この表は、すべてで按分ルールを使用して支払を消し込む前と後のこの請求書の各明細タイプの比較を示しています。

明細品目 明細品目残高 税金 税金残高 運送費 運送費残高 延滞手数料 延滞手数料残高

<$100> <$100> $100 $28.56 $30 $8.58 $10.00 $2.86

127

この表は、各明細タイプに消し込まれた金額を示しています。

消込済金額合計 消込済明細金額 消込済税額 消込済運送費 消込済延滞手数料金額

100 0 71.44 21.42 7.14

この表は、すべてで按分消込ルールで使用される計算を示しています。

項目 計算

税金 100 - (21.42 + 7.14) = 71.44

運送費 (30 * 100) / 140 = 21.42

延滞手数料 3(10.00 * 100) / 140 = 7.14

消込ルール・セットに関するFAQ

税処置とは何ですか。

消込ルール・セットの「税処置」オプションは、支払が消し込まれる際に明細金額に関連して税額を減額する方法を決定します。

税処置オプションは次のとおりです。

按分: 明細の正味金額および関連する税額を比例して減額します。前: 最初にオープン税額を減額し、次に残金を明細に消し込みます。後: オープン明細金額を減額し、次に残金を関連する税金に消し込みます。

端数処理訂正を使用するにはどうすればよいですか。

端数処理訂正は、消込ルール・セットに属する明細タイプ(明細、運送費または手数料)のいずれかに割り当てます。金額が複数の明細タイプに按分される場合、消込ルール・セットでは、端数処理調整を許可するように指定した明細タイプが使用されます。指定された明細タイプの明細金額は、消込ルール・セット内の端数処理訂正を考慮して調整されます。

入金区分および入金方法

送金方法と決済方法各入金区分の送金方法および決済方法を定義します。これらの設定により、特定の入金区分の入金の送金動作および決済動作が決まります。

送金方法

送金方法を使用して、この入金区分に割り当てられた入金方法を使用して作成された入金に使用する勘定科

128

目を決定します。

標準

この入金区分の入金方法に割り当てられた自動入金に送金勘定を使用します。

ファクタリング

この入金区分の入金方法に割り当てられた自動入金にファクタリング勘定を使用します。

標準およびファクタリング

Receivablesでは、バッチ送金方法に関係なく、この入金区分に割り当てられた入金を送金用に選択します。この場合、送金バッチの作成時に、これらの送金方法のいずれかを指定できます。

送金なし

手動入金の場合のみ。この入金区分に割り当てられた手動入金には送金は必要ありません。

決済方法

決済方法を使用して、この入金区分に割り当てられた入金方法を使用して作成された入金を、一般会計現預金勘定に転記する前に消し込む必要があります。

直接

この方法は、銀行に送金される予定がない、その後決済される入金を対象としています。

これらの入金は、入金の入力時に決済され、これ以上の処理が必要ないとみなされます。

自動決済

この方法を使用して、「入金の自動決済」プログラムを使用して入金を決済します。

注意: Cash Managementでこの方法を使用して、入金を決済することもできます。

照合

この方法を使用して、Cash Managementで手動で入金を決済します。

関連トピック

入金の送金に関する考慮事項入金の自動決済

自動入金方法の定義に関するガイドライン自動入金方法の属性を定義して、選択したトランザクションに対する自動入金の処理方法を決定します。

129

自動入金方法の属性を定義する際は、次のガイドラインをレビューしてください。

入金継承トランザクション番号入金処理数ルール入金満期日ルール自動印刷テンプレート逆算日数顧客支払方法

入金継承トランザクション番号

「入金処理数ルール」として「請求書毎」を使用している場合は、「入金継承トランザクション番号」オプションを有効にすると、自動入金番号を常に消込先のトランザクション番号と同じにすることができます。このオプションを有効にすると、自動入金の追跡に役立ちます。

注意: 自動入金で文書連番を使用している場合は、このオプションを有効にしないでください。

入金処理数ルール

「入金処理数ルール」は、自動入金プロセスがトランザクションに対して入金を作成し、消し込む方法を決定します。

次のいずれかのルールを選択します。

顧客毎: 顧客ごとに1つの入金を作成します。顧客支払期日毎: 顧客および支払期日ごとに1つの入金を作成します。このオプションでは、顧客の請求書に複数の支払期日がある場合、顧客に対して複数の支払が作成されます。請求書毎: 請求書ごとに1つの入金を作成します。サイト毎: 顧客サイトごとに1つの入金を作成します。サイト支払期日毎: 顧客サイトおよび支払期日ごとに1つの入金を作成します。

注意: 入金処理数ルールでは、支払手段別の追加のグループ化を前提としています。たとえば、「顧客毎」ルールを使用し、同じ顧客に属する2つの請求書を異なる銀行口座から支払う場合、自動入金プロセスでは2つの入金(銀行口座番号ごとに1つずつ)を作成します。

入金満期日ルール

入金満期日ルールは、1つの入金で支払期日が異なる複数の請求書支払に使用します。

入金がカバーするすべての請求書の最も早い期日を入金満期日として使用する場合は、「最早」を選択します。入金がカバーするすべての請求書の最も遅い期日を入金満期日として使用する場合は、「最遅」を選択します。

入金を送金すると、Receivablesでは、満期日を使用して、顧客銀行口座から送金銀行口座に資金を振り替えるタイミングを決定します。

自動印刷テンプレート

この入金方法での伝送に使用する自動印刷テンプレートを入力します。

130

Receivablesには、入金文書を作成するときに支払選択プログラムおよび支払作成プログラムの出力をフォーマットする標準入金印刷テンプレートが1つ用意されています。別の入金印刷テンプレートを使用するには、この標準入金印刷テンプレートをコピーして変更する必要があります。

逆算日数

逆算日数は、この入金方法を使用する自動入金プロセスによって消込用に請求書を選択できる請求書支払期日までの日数です。

このオプションは、顧客の承認が必要な場合などに便利です。この値は、顧客の承認を得るのに通常必要な日数に設定できます。

顧客支払方法

この入金方法を使用して自動入金の支払を送金するために顧客が使用する資金取得支払方法を選択します。

Oracle Paymentsには、事前定義済の資金取得支払方法が用意されていますが、独自に定義することもできます。

関連トピック

自動入金の処理方法

自動入金に対する資金振替エラー処理自動入金方法に対する資金振替エラー処理を定義して、自動入金処理中のエラー訂正を管理します。

資金振替エラー処理を定義して、クレジット・カード承認中または支払取得中、あるいは銀行口座振替中に発生したエラーを自動的に訂正します。

該当する自動入金方法について、「入金区分および入金方法の作成」ページまたは「入金区分および入金方法の編集」ページの「自動処理」タブの「資金振替エラー処理」セクションでエラー処理を設定します。

注意: クレジット・カード・サービスは、現在、Oracle Cloud実装では使用できません。

サード・パーティ・エラー・コードのマッピング

特定の自動入金方法の資金振替エラー処理を定義するには、サード・パーティ・クレジット・カード・プロバイダまたは金融機関のエラー・コードを、トランザクションのカテゴリごとにReceivablesの訂正処理にマップします。

指定された入金方法での自動入金の支払処理中にエラーが発生した場合、Receivablesでは、特定のサード・パーティ・エラー・コードに対応する訂正処理が適用されます。

各エラー・コードを、トランザクションの各カテゴリの対応する処理にマップします。この表は、各カテゴリで使用できる訂正処理を示しています。

カテゴリ 使用可能な処理

請求書、デビット・メモ、クレジット・メモ 支払情報の消去、再試行

131

入金 再試行、入金戻し処理

払戻 再試行、入金戻し処理

エラー・コードのマッピング: 例

クレジット・カード・プロバイダのエラー・コードGW-0062を、「請求書」カテゴリおよび「再試行」処理にマップします。

クレジット・カード承認が失敗し、クレジット・カード・プロバイダが複数のトランザクションに対してエラー・コードGW-0062を返すと、Receivablesでは、これらの失敗したトランザクションに対するこのエラー・コードが自動的に削除されます。これらのトランザクションは、次の自動入金バッチに含めることができます。

入金方法に対する送金銀行口座入金区分に割り当てられた各入金方法の送金銀行口座情報を定義します。送金銀行口座情報には、入金を入力または消し込むときに使用する総勘定元帳勘定科目が含まれます。

送金銀行口座および入金通貨

1つの通貨でのみ入金を送金する場合、入金方法に対して複数の送金銀行口座を入力できますが、入金方法に対して1つの口座をプライマリ銀行口座としてマークする必要があります。

入金方法について複数の通貨で入金を送金する場合、通貨ごとに少なくとも1つの送金銀行口座を入力し、通貨ごとに1つの口座をプライマリとしてマークする必要があります。

入金の入力および処理中に、Receivablesでは、プライマリ銀行口座が入金のデフォルト送金銀行口座として使用されます。この値を受け入れるか、入金と同じ通貨の入金方法に定義されている他の銀行口座を入力できます。

ファクタリング入金

入金方法の入金区分でファクタリングが許可されている場合は、特定の銀行口座のファクタリング入金の「リスク消去日数」の数値を指定できます。

入金をファクタリングすると、Receivablesでは、顧客デフォルトが発生した場合のリスクを計上するために短期借入金が作成されます。これらの入金を決済またはリスク消去すると、入金満期日に、入力したリスク消去日数を加えた日数の後に、負債が決済されます。

関連トピック

口座の作成時の考慮事項

入金区分および入金方法に関するFAQ

入金区分にはどのような作成方法が必要ですか。

自動作成方法で自動入金プロセスを使用して、選択したトランザクションからの入金のバッチを作成しま

132

す。自動入金の場合、Paymentsは資金取得プロセスを担当します。手動で入力された入金またはロックボックスを使用してインポートされた入金には、手動作成方法を使用します。

入金区分と入金方法にはどのような関係がありますか。

入金区分に割り当てられた入金方法により、入金エントリおよび消込が計上されます。また、顧客送金銀行情報も決定されます。

入金区分によって、入金に必要な処理ステップが決定されます。これらのステップには、自動作成または手動作成、送金方法、銀行決済方法、および入金に顧客による確認が必要かどうかが含まれます。

入金に割り当てられるのはどのような法的エンティティですか。

法的エンティティは、送金銀行口座および当方銀行口座にリンクされます。入金方法によって、入金に割り当てられる送金銀行口座(法的エンティティ)が決定されます。

すべての入金は銀行口座から法的エンティティを継承し、すべての払戻は当初入金の法的エンティティを継承します。

入金と入金の消込先のトランザクションが同じビジネス・ユニット内にある場合、複数の法的エンティティで入金消込を実行できます。複数の法的エンティティでの入金消込および入金決済は、補助元帳に会社間会計として記録されます。

ロックボックス

ロックボックス・インタフェース表AR_PAYMENTS_INTERFACE_ALLロックボックス処理のインポート・ステップ中、Receivablesは、銀行ファイルの入金データをAR_PAYMENTS_INTERFACE_ALL表に格納します。AR_PAYMENTS_INTERFACE_ALL表の各列には、ロックボックスを正常に実行するために必要な情報が含まれています。

TRANSMISSION_RECORD_ID

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

R_PAYMENTS_INTERFACE_S.NEXTVAL

検証

宛先CREATION_DATE

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

133

現在のシステム日付。

検証

宛先CREATED_BY

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

FND_GLOBAL.WHO_USER_NAME

検証

宛先LAST_UPDATE_LOGIN

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

不明。

検証

宛先LAST_UPDATED_BY

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

FND_GLOBAL.WHO_USER_NAME

検証

宛先LAST_UPDATE_DATE

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

現在のシステム日付。

検証

134

宛先RECORD_TYPE

レコード・タイプを入力します。たとえば、これがバッチ・ヘッダー・レコードであり、銀行が値3を使用してバッチ・ヘッダーを識別する場合、この列に3を入力します。

AR_TRANS_RECORD_FORMATS.RECORD_IDENTIFIER

検証

宛先STATUS

この表に挿入されるすべてのレコードに対して値AR_PLB_NEW_RECORD_INFを入力します。この列には、Receivablesが提供する管理ファイルが移入されます。

FND_MESSAGES.MESSAGE_NAME

検証

宛先TRANSMISSION_REQUEST_ID

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

FND_JOB.REQUEST_ID

検証

宛先TRANSMISSION_ID

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

AR_TRANSMISSIONS.TRANSMISSION_ID

検証

宛先

135

DESTINATION_ACCOUNT

送信銀行の口座番号を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先ORIGINATION

送信銀行の伝送経路番号を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先DEPOSIT_DATE

伝送が銀行口座に預け入れられた日付を入力します。この日付は、伝送のどのレコード・タイプでも指定できます。

一意の預入日それぞれによって、伝送レコードのバッチが決定されます。たとえば、2つの一意の預入日を伝送に入力すると、ロックボックスは伝送を2つの入金バッチに分割します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先GL_DATE

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

預入日、インポート日または入力日から導出されます。

検証

宛先DEPOSIT_TIME

136

預入が行われた時間を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先TRANSMISSION_RECORD_COUNT

インポート・ファイルのレコード数を入力します。件数にはすべてのレコード・タイプ(ヘッダー、トレーラ、入金、オーバーフロー・レコード)を含めます。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先TRANSMISSION_AMOUNT

伝送の金額を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先TRANSFERRED_RECEIPT_COUNT

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

プログラムにより、正常に転送されたレコード数がカウントされます。

検証

宛先TRANSFERRED_RECEIPT_AMOUNT

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

プログラムにより、正常に転送されたレコードの入金額が合計されます。

137

検証

宛先LOCKBOX_NUMBER

ロックボックス・ヘッダー・レコードまたはトレーラ・レコードの場合、銀行によって指定されたロックボックス名または番号を入力します。

バッチ・ヘッダー・レコードおよびトレーラ・レコードの場合、バッチ内の入金に割り当てられたロックボックス番号を入力します。

入金レコードの場合、入金に割り当てられたロックボックス番号を入力します。

オーバーフロー・レコードの場合、入金のロックボックス番号を入力します。

銀行から提供されるか、ユーザーが入力します。

検証

宛先LOCKBOX_BATCH_COUNT

ロックボックスのバッチ数を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先LOCKBOX_RECORD_COUNT

ロックボックスの支払レコード数を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先LOCKBOX_AMOUNT

ロックボックスの入金合計金額を入力します。

138

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先BATCH_NAME

バッチ・ヘッダー・レコードおよびトレーラ・レコードの場合、銀行がバッチの識別に使用する名前または番号を入力します。

入金レコードの場合、この入金のバッチ名を入力します。

オーバーフロー・レコードの場合、このオーバーフロー・レコードのバッチを入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先BATCH_AMOUNT

このバッチのすべての入金合計金額を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先BATCH_RECORD_COUNT

このバッチの入金レコード数を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先ITEM_NUMBER

バッチ内の各入金レコードまたはオーバーフロー・レコードの場所を示す連番を入力します。

139

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先CURRENCY_CODE

各入金の通貨を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先EXCHANGE_RATE

入金の場合、この通貨に使用する換算レートを入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先EXCHANGE_RATE_TYPE

入金に使用する換算レート・タイプ(「社内」、「直物」または「ユーザー」)を入力します。

ロックボックス定義またはロックボックス伝送フォーマットから導出されます。

検証

宛先REMITTANCE_AMOUNT

バッチ内の各入金の値を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

140

宛先TRANSIT_ROUTING_NUMBER

入金の伝送経路番号を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先ACCOUNT

入金の銀行口座番号を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先CUSTOMER_BANK_ACCOUNT_ID

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

AP_BANK_ACCOUNT_USES.EXTERNAL_BANK_ACCOUNT_ID

検証

宛先ANTICIPATED_CLEARING_DATE

入金予定決済日。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先CHECK_NUMBER

入金の印刷された小切手番号を入力します。

141

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先SPECIAL_TYPE

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

プログラムにより、タイプが決定されます。

検証

宛先AUTOAPPLY_FLAG

ロックボックス処理中に自動適用プロセスが使用されるかどうかを示します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先CUSTOMER_NUMBER

顧客アカウント番号を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先OVERFLOW_INDICATOR

Receivablesでは、この列を使用して、現在の入金のオーバーフロー・レコードを示します。すべてのオーバーフロー・レコードの値を入力する必要があります。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

142

検証

宛先OVERFLOW_SEQUENCE

オーバーフロー・レコードの順序を示す連番を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先CUSTOMER_ID

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

プログラムにより、IDが決定されます。

検証

宛先BILL_TO_LOCATION

この入金の顧客請求先サイトを入力し、請求先サイトを伝送フォーマットに含めます。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先CUSTOMER_SITE_USE_ID

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

プログラムにより、IDが決定されます。

検証

宛先

143

RECEIPT_DATE

入金レコードの場合、小切手に記載される日付を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先RECEIPT_METHOD

入金に関連付ける入金方法を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先RECEIPT_METHOD_ID

Receivablesは、インポート・プロセス中にこの列に値を割り当てます。

プログラムにより、IDが決定されます。

検証

宛先INVOICE1-8

入金レコードおよびオーバーフロー・レコードの場合、必要に応じて、入金が消し込まれる請求書番号を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先MATCHING1_DATE - MATCHING8_DATE

照合日用。

144

宛先RESOLVED_MATCHING_NUMBER1-8

解決済照合番号用。

プログラムにより、番号が決定されます。

宛先RESOLVED_MATCHING1_DATE - RESOLVED_MATCHING8_DATE

解決済照合日用。

プログラムにより、日付が決定されます。

宛先MATCH_RESOLVED_USING

照合解決用。

プログラムにより、値が決定されます。

検証

宛先RESOLVED_MATCHING1_INSTALLMENT - RESOLVED_MATCHING8_INSTALLMENT

解決済照合賦払用。

プログラムにより、値が決定されます。

宛先INVOICE1_STATUS - INVOICE8_STATUS

入金が消し込まれる請求書のステータス。

プログラムにより、値が決定されます。

検証

宛先COMMENTS

145

バッチ・ヘッダー・レコードおよびトレーラ・レコード、および入金レコードの場合、自由書式のコメントを入力します。

ロックボックス伝送フォーマット。

検証

宛先ATTRIBUTE_CATEGORY

この入金の付加フレックスフィールド・カテゴリ情報を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先ATTRIBUTE1-15

ATTRIBUTE_CATEGORY列で指定されるカテゴリの付加フレックスフィールド属性を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先INVOICE1_INSTALLMENT - INVOICE8_INSTALLMENT

入金レコードおよびオーバーフロー・レコードの場合、入金の消込先の複数の支払スケジュールがある請求書の賦払番号を入力します。

ロックボックス・データ・ファイルまたはロックボックス伝送フォーマット。

検証

宛先CUSTOMER_NAME_ALT

顧客のカナ名。

146

ロックボックス・データ・ファイル。

検証

宛先CUSTOMER_BANK_NAME

顧客銀行の名前。入金レコードに使用します。

ロックボックス・データ・ファイル。

検証

宛先CUSTOMER_BANK_BRANCH_NAME

顧客銀行支店の名前。入金レコードに使用します。

ロックボックス・データ・ファイル。

検証

宛先REMITTANCE_BANK_NAME

支払を受領した銀行の名前。入金レコードに使用します。

プログラムにより、名前が決定されます。

検証

宛先BANK_TRX_CODE

銀行のトランザクション・コード。

プログラムにより、コードが決定されます。

検証

147

宛先AMOUNT_APPLIED1-8

請求書を消し込む入金の金額を入力します。入金通貨とトランザクション通貨が異なる場合は、消し込む入金の金額をトランザクション通貨で入力します。

ロックボックス・データ・ファイル、またはAMOUNT_APPLIED_FROMおよびEXCHANGE_RATEから導出されます。

検証

宛先AMOUNT_APPLIED_FROM1-8

入金レコードおよびオーバーフロー・レコードの場合、入金通貨とトランザクション通貨が異なる場合は、消し込む入金の金額を入金通貨で入力します。

ロックボックス・データ・ファイル、またはAMOUNT_APPLIED_FROMおよびEXCHANGE_RATEから導出されます。

検証

宛先INVOICE_CURRENCY_CODE1-8

入金レコードおよびオーバーフロー・レコードの場合、入金通貨とトランザクション通貨が異なる場合は、トランザクションの通貨を入力します。この列は、相互通貨入金消込に使用されます。

ロックボックス・データ・ファイル、またはAR_PAYMENT_SCHEDULES_ALLから導出されます。

検証

宛先TRANS_TO_RECEIPT_RATE1-8

入金レコードおよびオーバーフロー・レコードの場合、入金通貨とトランザクション通貨が異なる場合は、入金をトランザクション通貨に換算するのに使用する換算レートを入力します。

ロックボックス・データ・ファイル、またはAMOUNT_APPLIED_FROMおよびEXCHANGE_RATEから導出されます。

148

検証

宛先CUSTOMER_REFERENCE_1-8

顧客参照用。

CUSTOMER_REASON1-8

顧客事由コード用。

関連トピック

ロックボックス標準入金インポート・プロセス

入金別照合ルールを使用した入金消込ロックボックスおよび手動入金の処理中、Receivablesでは入金別照合ルールの設定を使用して、顧客情報が使用できない場合に入金をトランザクションと照合するために使用する文書タイプを識別します。

入金照合の文書タイプ

次の6つの文書タイプを使用して、入金をトランザクションと照合します。入金の処理中に、Receivablesでは次のいずれかの文書タイプをこの順序で検索します。

トランザクション番号販売オーダー番号購買オーダー番号繰越残高請求番号出荷参照契約番号

入金別照合ルールの選択

Receivablesで現在の検索と同じ番号の文書タイプを検出して、入金をトランザクションと照合すると、プロセスにより、次の順序で入金別照合ルールが有効になっている事業所がチェックされます。

顧客請求先サイト顧客ロックボックス(ロックボックス処理用)システム・オプション

Receivablesでは、現在の検索で番号の文書タイプに一致するルールを検索し、値が検出されると停止します。たとえば、Receivablesが最初の検索で一致するトランザクション番号を検出した場合は、入金別照合ルールについて顧客サイトをチェックします。ルールが「トランザクション」に設定されている場合、Receivablesは入金をこのトランザクションと照合して、入金を消し込みます。

149

顧客サイトの入金別照合ルールがトランザクション以外の文書タイプの場合、 はこの文書タイプに一致する番号を検索します。

顧客サイトまたは顧客レベルで割り当てられている値がない場合:

ロックボックス処理の場合、Receivablesでは、ロックボックスに割り当てられた入金別照合ルールを使用するか、「照合基準を使用して顧客を決定する」オプションが有効になっている場合は、文書タイプ階層全体を使用します。手動入金処理の場合、Receivablesでは、ビジネス・ユニットに割り当てられた売掛/未収金システム・オプション・レコードの「入金別照合」設定を使用します。

Receivablesで各文書タイプを検索した後に一致が見つからない場合は、プロセスにより、顧客に定義された自動消込ルール・セットを使用して入金が消し込まれます。

自動消込ルール・セットで入金を消し込むことができない場合、Receivablesでは入金に「未消込」のステータスを割り当てます。その後、入金を手動で消し込む必要があります。

照合ルールの例

次に、照合ルールの使用例を2つ示します。

例1: ロックボックスの処理中に、入金レコードが、未回収借方品目12345に入金を消し込む必要があることを示しています。Receivablesによって、まず、この番号のトランザクション(請求書、デビット・メモ、チャージバック)が検索されます。Receivablesによってこの番号の請求書が検出されたため、プロセスによって顧客サイトの「入金別照合」パラメータの値がチェックされます。この顧客サイトの入金別照合ルールはNULLであるため、Receivablesによって顧客プロファイルの設定がチェックされます。顧客プロファイルで「入金別照合」が「トランザクション」に設定されているため、Receivablesによって、この入金が照合され、請求書に消し込まれます。

例2: 例1と同じ入金レコード情報を使用し、Receivablesによって番号12345のトランザクションが検出されなかったとします。次に、プロセスによって、この番号の販売オーダーが検索されます。Receivablesでは、この番号の販売オーダーが見つからないため、番号12345の購買オーダーを検索して見つけます。Receivablesは、次に、顧客サイトで入金別照合ルールをチェックします。この顧客サイトの入金別照合ルールはNULLであるため、Receivablesによって顧客プロファイルの設定がチェックされます。このルールは顧客プロファイルでもNULLであるため、Receivablesによってロックボックスのルールがチェックされます。このロックボックスの入金別照合ルールが「購買オーダー番号」に設定されているため、プロセスによって、この入金がこの購買オーダーと照合され、入金がトランザクションが入金によって消し込まれます。

関連トピック

各自動消込ルールの使用例例外トレンドとは何ですか

ロックボックスに関するFAQ

ロックボックスに入金ソースが見つからないのはなぜですか。

入金ソースが作成され、特定のビジネス・ユニットに割り当てられます。ロックボックスが作成され、特定のロックボックス・セットに割り当てられます。特定のロックボックスで使用できる入金ソースは、その

Receivables

150

ロックボックス・セットに属するビジネス・ユニットに作成および割り当てられた入金ソースに制限されます。

ロックボックスで使用する入金ソースを定義するには、次の設定を使用します。

「入金ソース・タイプ」を「手動」に設定します。デフォルトの入金方法とデフォルトの銀行口座の両方を指定します。「バッチ採番方法」を「自動」に設定します。

ロックボックスのバッチ・サイズを計算するにはどうすればよいですか。

「バッチ・サイズ」フィールドを使用して、ロックボックスの処理中に各入金バッチに割り当てる入金数を入力します。たとえば、991個の入金があり、バッチ・サイズを10に設定した場合、ロックボックス・プロセスによって、10個の入金を含む99個のバッチと1個の入金を含む1個のバッチが作成されます。

ロックボックス・プロセスでロックボックス発行を複数の入金バッチに分割しない場合は、次の手順を実行します。

このロックボックスのロックボックス伝送に、入金数より大きい数値を入力します。ロックボックス伝送を発行するときに、「完了バッチのみ」オプションを有効にします。

会計日ソースを使用するにはどうすればよいですか。

ロックボックスの「会計日ソース」フィールドの値によって、ロックボックス内の入金に適用する会計日が決まります。

ロックボックス処理の会計日ソースの値は次のとおりです。

一定日: ロックボックス伝送に入力する会計日を使用します。会計日を入力しない場合、ロックボックス・プロセスではデータが検証されません。預入日: ロックボックス伝送に入力する預入日を使用します。これは、送金銀行が入金を預け入れた日付です。預入日を入力しない場合、ロックボックス・プロセスによってエラーが表示され、ロックボックスを発行するための預入日のプロンプトが表示されます。インポート日: 入金をインポートする日付を使用します。

自動適用では無効なトランザクション番号はどのように管理されますか。

ロックボックスで自動適用を使用する場合、ロックボックス・プロセスでは、設定に基づいて顧客を入金と照合および入金をトランザクションと照合しようとします。

トランザクション番号が無効なためにロックボックスで入金を全額消し込むことができない場合は、未消込一部金額の転記オプションに従って追加金額が管理されます。入金が有効なトランザクションに消し込まれ、入金額の残金が「未消込」とマークされます。

ロックボックスの伝送フォーマット

151

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

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

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

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

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

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

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

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

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

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

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

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

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

伝送レベルの検証

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

152

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

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

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

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

バッチ・レベルの検証

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

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

入金レベルの検証

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

送金額が指定されています。小切手番号が指定されています。品目番号が指定されており、バッチ、ロックボックスまたは伝送内で一意です(伝送フォーマットに応じて)。ロックボックス番号が指定されており(この番号が伝送フォーマットのロックボックス・ヘッダーまたはトレーラの一部でない場合)、バッチはインポートされません。バッチ名が指定されています(バッチ・ヘッダーまたはトレーラが伝送フォーマットの一部である場

153

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

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

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

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

注意: Invoice1-8の入金検証およびオーバーフロー検証の場合: 照合番号を使用しており、入金レコードがこの入金によって複数のトランザクションが支払われることを示す場合、ロックボックスでは、すべてのトランザクションが同じ文書タイプ(請求書、販売オーダー、購買オーダーなど)であるとみなします。

たとえば、最初の2つのトランザクションが請求書の場合、ロックボックスはそれらをこの入金と正常に照合します。ただし、次のトランザクションが請求書でない場合、ロックボックスはロックボックス定義に応じて、入金額の残金を「不明」としてインポートするか、入金全体を拒否します。

ロックボックスが入金額の残金を「未消込」としてインポートする場合、Receivablesでは無効な照合番号が保持されます。

顧客の検証

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

154

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

通貨の検証

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

関連トピック

ロックボックス標準入金インポート・プロセス

ロックボックス伝送フォーマットロックボックス入金処理では、管理ファイル(.ctl)とも呼ばれる伝送フォーマットを使用して、Receivablesインタフェース表にインポートするために銀行ファイル内のデータを編成する方法を指定します。

管理ファイルは、ロックボックス入金を転送するために多数の銀行で使用される業界標準に基づいています。

ロックボックス入金処理中:

「インポートのためのインタフェース・ファイルのロード」プロセスは、銀行ファイル名のプリフィクスに基づいて、使用する管理ファイルを識別します。たとえば、Arlockboximportbai2_mmddyyyy.datファイルはarlockboximportbai2で始まるため、このプロセスではこの伝送フォーマットを使用します。ロックボックス検証プロセスでは、伝送フォーマットの構造を使用して、データが銀行ファイルから表に正しく転送されることを確認します。

伝送フォーマット

次のリストは、事前定義済の売掛/未収金伝送フォーマットを示しています。BAI管理ファイルおよびEDI823管理ファイルは、固定長のテキストベースのデータ・ファイルです。

BAI管理ファイルおよびEDI823管理ファイルが特定の顧客の特定の要件を満たすことができない場合、Receivablesでは、カンマ区切りのFBDI管理ファイル(arlockboximportc.ctl)および対応するスプレッドシートも提供されます。

BAI (arlockboximportbai.ctl)

Bank Administration Instituteによって作成されたオリジナル・フォーマット。

BAI 2.0 (arlockboximportbai2.ctl)

Bank Administration Instituteによって作成された更新済フォーマット。

BAI2拡張(arlockboximportextbai2.ctl)

155

拡張フィールド長を提供する更新済フォーマット。

ORA_BAI2-EXTENDED_GENERIC (arlockboximportgenbai2.ctl)

比較可能なデータを保持するデータベース表のフィールド長に類似したフィールド長を持つ、BAI2拡張フォーマットに類似した更新済フォーマット。

EDI823 (arlockboximportedi823.ctl)

電子データ交換(EDI)環境で使用されるフォーマット。

売掛/未収金標準入金のインポート(FBDI) (arlockboximportc.ctl)

CloudのFBDIプロセス管理ファイルに類似したフォーマット。これらのファイルは、カンマ区切りデータ・ファイルに対応するマクロ対応スプレッドシート・テンプレートを提供します。

ロックボックス伝送レコード・タイプロックボックス伝送フォーマットに含めるレコード・タイプを入力します。「識別子」列を使用して、各レコード・タイプを一意に識別します。

銀行ファイルにこれらのレコード・タイプの一部が含まれていない可能性があります。伝送フォーマットを定義して、実際に使用するレコード・タイプのみを含めるようにしてください。

レコード・タイプ

バッチ・ヘッダー

バッチ・ヘッダーは、特定のバッチの開始をマークします。バッチ・ヘッダーには通常、バッチ番号、預入日、ロックボックス番号などの情報が含まれています。

バッチ・トレーラ

バッチ・トレーラは、特定のバッチの終了をマークします。バッチ・トレーラには通常、バッチ番号、ロックボックス番号、バッチ・レコード件数、バッチ金額などの情報が含まれています。

ロックボックス・ヘッダー

ロックボックス・ヘッダーは、特定のロックボックスの開始をマークします。ロックボックス・ヘッダーには通常、入金先口座や採番番号などの情報が含まれています。

ロックボックス・トレーラ

ロックボックス・トレーラは、特定のロックボックスの終了をマークします。ロックボックス・トレーラには通常、ロックボックス番号、預入日、ロックボックス金額、ロックボックス・レコード件数などの情報が含まれています。

オーバーフロー入金

156

オーバーフロー支払には通常、バッチ番号、品目番号、連番、オーバーフロー・インジケータ、請求書、デビット・メモ、チャージバック番号、借方品目金額など、特定の支払の請求書情報が含まれています。Receivablesでは、オーバーフロー・レコードと支払レコードを組み合せて論理レコードを作成し、支払消込を発行します。

入金

入金には通常、MICR番号、バッチ番号、品目番号、小切手番号、送金額などの支払情報が含まれています。

サービス・ヘッダー

サービス・ヘッダー・レコードには、伝送に関する一般情報が含まれています。

伝送ヘッダー

伝送ヘッダーは、特定のデータ・ファイルの開始をマークします。伝送ヘッダーには通常、入金先口座、採番番号、預入日、預入時刻などの情報が含まれています。

伝送トレーラ

伝送トレーラは、特定のデータ・ファイルの終了をマークします。伝送トレーラには通常、レコード件数合計などの情報が含まれています。

ロックボックス伝送フォーマット・フィールド・タイプ各ロックボックス伝送レコード・タイプの特性を識別するために使用するロックボックス伝送フィールド・タイプを入力します。

各伝送レコードのサイズ、順序およびフォーマットを指定します。ロックボックス伝送プログラムでは、伝送フォーマットで定義したフィールドのみが検証されます。伝送フォーマットは、ロックボックス・ファイル内のデータの編成方法と完全な互換性がある必要があります。

フィールド・タイプ

アカウント

顧客銀行口座。銀行口座番号および伝送経路番号により、顧客MICR番号が構成されます。

カナ名

この顧客のカナ名。

「消込済金額1」から「消込済金額8」

各請求書、デビット・メモまたはチャージバックに消し込まれる金額。各支払レコードまたはオーバーフロー支払レコードは、最大8つの借方品目番号に対応できます。相互通貨消込の場合、これはトランザクション通貨で消し込まれる金額です。

157

「消込済金額: 自1」から「消込済金額: 自8」

相互通貨入金消込に使用されます。これは、入金通貨で各トランザクションに消し込まれる金額です。各支払レコードまたはオーバーフロー支払レコードは、最大8つの借方品目番号に対応できます。

「属性1」から「属性15」

属性を使用して、付加フレックスフィールド・セグメントを入力します。属性は支払レコードにのみ割り当てることができます。

銀行トランザクション・コード

銀行取引明細書でトランザクションの種類(借方、貸方、無効など)を一意に識別するために銀行で使用される各勘定に定義されるコード。これは、Cash Managementで入金有効日を決定するためにも使用されます。

バッチ金額

特定の銀行バッチの入金バッチ金額合計。

バッチ名

特定の銀行バッチのバッチの名前。

バッチ・レコード件数

特定の銀行バッチの支払レコード合計数。すべてのバッチ・レコードの合計数は、ロックボックス・レコード件数と等しくなります。これには、オーバーフロー支払、ヘッダーまたはトレーラは含まれません。

請求先事業所

銀行は支払の請求先事業所を伝送します。伝送されるデータ・ファイルで請求先事業所が表示されるフィールド名およびフィールド位置のみを指定する必要があります。

コメント

この伝送に関連付けるコメント。

換算レート

この支払に関連付けられた換算レート(ロックボックスを使用して外貨入金をインポートする場合)。

換算タイプ

外貨入金を元帳通貨に換算するために使用する換算タイプ。

通貨

支払の通貨。相互通貨支払の場合は、請求書通貨を入力することもできます。このフィールドに値を入力し

158

ない場合、ロックボックスは「消込済金額1」から「消込済金額8」フィールドおよび「消込済金額: 自1」から「消込済金額: 自8」フィールドで指定された情報から通貨を導出します。

顧客銀行支店名

顧客銀行支店の名前。

顧客銀行名

顧客銀行の名前。

顧客番号

支払を発行した顧客の識別番号。

「顧客事由1」から「顧客事由8」

支払で相違が示される顧客事由。

「顧客参照1」から「顧客参照8」

この支払に関する顧客コメント。

預入日

銀行が顧客支払を受領および預け入れた日付。

預入時刻

銀行が顧客支払を受領および預け入れた時間。

入金先口座

ビジネス銀行口座。ビジネスには複数の銀行口座がある場合があります。

有効日

銀行が利息を適用する顧客残高を決定する日付(Cash Managementで使用されます)。

「請求書1」から「請求書8」

支払を消し込む請求書、デビット・メモおよびチャージバック。各支払レコードまたはオーバーフロー支払レコードは、最大8つの借方品目番号に対応できます。

「請求書1賦払」から「請求書8賦払」

この請求書の賦払番号。

159

請求書通貨 から請求書通貨

トランザクションの通貨このフィールドは、相互通貨入金消込に使用されます。このフィールドはオプションです。

品目番号

銀行が特定の支払に割り当てる連番。この番号によって請求書が入金に関連付けられます。

ロックボックス金額

特定のロックボックス内の支払金額合計。

ロックボックス・バッチ件数

特定のロックボックス内の銀行バッチ合計数。

ロックボックス番号

特定のロックボックスの識別番号。

ロックボックス・レコード件数

特定のロックボックス内の支払レコード数。これには、オーバーフロー支払、ヘッダーまたはトレーラは含まれません。

「照合日1」から「照合日8」

入金をトランザクションと照合するために使用する日付(このロックボックスに「対応日照合」オプションを使用している場合)。

銀行採番番号

銀行が提供した銀行採番番号。この番号は、ロックボックス情報を送信する銀行支店を一意に識別します。

オーバーフロー・インジケータ

この支払の追加オーバーフロー・レコードがあるかどうかを示します。

オーバーフロー連番

銀行が各オーバーフロー支払に割り当てる連番。

入金方法

このロックボックスに関連付けられた入金方法。

支払番号

1 8

160

支払の識別番号。たとえば、小切手番号です。

入金日

顧客が支払を行った日付。

レコード識別子

伝送レコードの種類を識別する番号。

送金額

支払の金額。

送金銀行支店名

この支払が発生した銀行支店の名前。

送金銀行名

この支払が発生した銀行の名前。

ステータス

この支払のステータス。

レコード件数合計

銀行ファイル内の伝送レコード合計数。これには、ヘッダー、トレーラ、支払、オーバーフローの各レコードが含まれます。

「入金レート換算1」から「入金レート換算8」

入金額を入金通貨からトランザクション通貨に換算するために使用される換算レート。このフィールドは、入金通貨およびトランザクション通貨に固定レートがない場合、相互通貨入金消込に使用されます。これらの通貨に固定レートがある場合、このフィールドはオプションです(この場合、ロックボックスは使用するレートを導出します)。

伝送経路番号

顧客銀行を一意に識別する番号。伝送経路番号および顧客銀行口座番号により、顧客MICR番号が構成されます。

伝送金額

銀行ファイルの支払合計金額。

161

ロックボックスの伝送フォーマットに関する伝送金額を再フォーマットできますか。

はい、「金額書式」フィールド設定を使用します。このフィールドを「はい」に設定すると、ロックボックスでは、金額書式を元帳通貨と同じ精度および同じ小数点以下桁数に丸めます。

たとえば、元帳通貨がUSD (精度 = 2)で、このオプションを「はい」に設定した場合、銀行データ・ファイルの値50000は500.00としてフォーマットされます。このオプションを「いいえ」に設定した場合、この値はフォーマットされず、50000として表示されます。

オーバーフロー・レコードとは何ですか。

オーバーフロー・レコードには、入金レコードに収まらない追加入金情報が格納されます。これは通常、追加請求書番号および各請求書に消し込まれる入金額です。

各オーバーフロー・レコードには、親として入金レコードが必要です。1つの入金レコードに複数のオーバーフロー・レコードがある場合、各オーバーフロー・レコードにはオーバーフロー連番が割り当てられます。

自動照合ルール・セット

自動照合の勧告の計算方法入金の処理中に、Receivablesでは、提供されたトランザクション情報に基づいて入金をトランザクションに消し込みます。提供されたトランザクション情報がレコードのトランザクション番号と完全に一致しない場合、自動適用プロセスは可能なかぎり近い一致を見つけ、入金をトランザクションに自動的に消し込むか、1つ以上のトランザクションを手動入金消込の勧告として提示しようとします。

同様に、ロックボックスの処理中に、ロックボックスに不完全または不正確な顧客情報が含まれている場合があります。自動適用プロセスは、顧客を入金と照合し、1人以上の顧客を入金の勧告として提示しようとします。

自動照合ルール・セットは、自動適用プロセスが入金をトランザクションに消し込むプロセスを完了するために使用する情報を提供します。自動照合ルール・セットの設定によって、次の勧告が提供されます。

顧客勧告: 照合プロセスでは、無効な顧客情報が含まれるロックボックス入金に対して顧客を勧告します。トランザクション勧告: 照合プロセスでは、ロックボックス入金と手動入金の両方について、入金消込に対する1つ以上のトランザクションを勧告します。

自動照合の勧告に影響する設定

勧告は、自動照合ルール・セットで定義された照合しきい値レベルに基づいています。次のしきいの設定により、入金勧告について顧客またはトランザクションを考慮するために必要なパーセント・レベルが決まります。

FAQ

162

顧客勧告しきい: 顧客情報を入金に追加するために必要な適格パーセント。顧客アカウント番号の計算スコアがこのしきい値を超えている場合、自動適用プロセスはこの顧客情報を入金に追加します。最小照合しきい: 入金消込対象のトランザクションを勧告するために必要な適格パーセント。1つ以上のトランザクションの計算スコアがこのしきい値を超えている場合、自動適用プロセスは一致率が高い順に、入金消込対象のトランザクションを勧告します。

注意: 最小照合しきいは、顧客勧告しきいおよび結合加重しきいより小さくする必要があります。

結合加重しきい: 自動適用プロセスが入金をトランザクションに自動的に消し込むために必要な適格パーセント。このパーセントは、入金照合の際に考慮される提供された顧客情報、トランザクション情報および実際のトランザクション金額に定義された適格パーセントの合計です。消込済請求書日数しきい: 自動照合プロセスに含めるクローズ済トランザクションを決定します。しきい値として指定された日数以前にクローズされたすべてのトランザクションが、消込または勧告で考慮されます。

自動照合の勧告の計算方法

自動照合ルール・セットで定義されたしきいの適格パーセントは、照合プロセスで分析される各顧客アカウント番号またはトランザクション番号の結果スコアと比較されます。

照合プロセスでは、次の方法で勧告を導出します。

1. 該当する場合は、自動照合ルール・セットの文字列処理で定義されているように、数値から文字およびスペースを削除します。

2. 結果の文字列に算式(レーベンシュタイン・アルゴリズム)を適用して、スコアを取得します。この算式は次のとおりです。

1 - (number of changes required to make the recommended string match the provided string / length of the larger string)

3. 結果スコアを該当するしきい値と比較します。

自動照合の勧告: 例

トランザクション番号10010は、入金消込のロックボックスによって提供されます。この番号は存在しませんが、Receivablesでは番号AR10001が検出されます。この番号に対する勧告は、次の方法で計算されます。

1. 自動照合ルール・セットの文字列処理設定は、対象の文字列から最初の2文字を削除することを示しています。ReceivablesはARを削除し、番号10001を残します。

2. 10001が10010と一致するには、位置を1つ入れ換える必要があります。したがって、この一致のスコアは(1 - 1/5) = 80%です。

3. スコア80%は結合加重しきい値70%を超えるため、入金はトランザクションAR10001に自動的に消し込まれます。

関連トピック

どのような場合に「入金の自動適用までの日数」を使用しますか入金消込の勧告の計算方法

163

自動照合の結合加重しきい自動照合ルール・セットを定義する場合は、加重しきいのフィールドを使用して、自動入金消込を許可するために必要なパーセントを適格化します。この適格パーセントでは、自動適用プロセスがトランザクションの3つの主要コンポーネント(顧客情報、トランザクション情報およびトランザクション金額)に適用する重要度(加重)を考慮します。

結合加重しきいの使用方法

自動入金消込に対してトランザクションを考慮する場合、自動適用プロセスが顧客、トランザクションおよび金額の情報を正常に照合するために適用する加重をパーセントで入力します。

3つのパーセントの合計は100になる必要があります。ほとんどの場合、トランザクションの各コンポーネントに同じ加重を適用することはありません。つまり、3つの加重値として33、33、34と入力することはありません。自動適用で入金をトランザクションに自動的に消し込むために、入力する加重しきい値は、標準のビジネス・プラクティスを反映する必要があります。

次の加重しきいを入力します。

顧客加重: トランザクションの顧客情報の照合に適用する加重を入力します。トランザクション加重: 正しい照合または「入金別照合」ルールの文書参照により、正しいトランザクションの識別に適用する加重を入力します。金額加重: 未回収残高金額の照合に適用する加重を入力します。トランザクション金額の一部がこの決定に関与する可能性があるため、「金額加重例外」セクションを使用して、対象となる未回収残高金額をより詳細に指定できます。

自動適用プロセスでは、顧客、トランザクションおよび金額の間の照合ごとにパーセント・スコアを計算します。次に、各加重しきいの最終スコアを加重しきい値のパーセントとして導出し、これらの結果を追加して最終スコアを取得します。次に、この最終スコアは、結合加重しきい値と比較されます。

たとえば、次の加重しきい値を入力します。

加重 値

結合加重しきい 75%

顧客 20%

トランザクション 70%

金額 10%

ロックボックスの処理中に、次の詳細を含む入金消込に対してトランザクションが提示されます。

顧客アカウント番号: 1001トランザクション番号: 10010未払額残高: 127割引後の金額: 120.65税金残高: 20運送費残高: 7期限外割引: 6.35

164

ロックボックスは、次の詳細を含む消込に対して入金を提示します。

顧客アカウント番号: 1005参照番号: 1001参照金額: 120.65

自動適用では、次の計算が実行されます。

顧客照合: アカウント番号1001と1005の照合の計算スコアは、75% [(1-1/4)*100]です。顧客加重しきい値が20%であるため、最終スコアは15%になります。トランザクション照合: トランザクション照合の計算スコアは、80% [(1-1/5)*100]です。トランザクション加重しきい値が70%であるため、最終スコアは56%になります。金額照合: トランザクション金額照合は100%です。金額加重しきい値が10%であるため、最終スコアは10%になります。

3つの最終スコアの合計は81%であり、結合加重しきい値75%を超えています。したがって、自動適用により、入金がトランザクションに自動的に消し込まれます。

注意: スコアが結合加重しきい値を下回っているが、最小照合しきい値を超えている場合、自動適用はユーザー・レビューの勧告を生成します。スコアが最小照合しきい値を下回っている場合、自動適用は勧告を生成しません。

自動照合の金額加重例外自動照合ルール・セットを定義する場合、「金額加重例外」セクションに入力する値は、「金額加重」しきいによって考慮される未回収残高金額の内容を適格化します。

金額加重例外の使用方法

しきいパーセントを入力して、トランザクションの未回収残高金額の様々な部分に適用する加重を適格化します。

次の金額加重例外しきいを入力します。

正味税加重: 税金を除いたトランザクション合計金額(ただし、運送費を含む)に適用する加重を入力します。税および運送費の正味額加重: 税金および運送費を除いたトランザクション合計金額に適用する加重を入力します。正味運送費加重: 運送費を除いたトランザクション合計金額(ただし、税金を含む)に適用する加重を入力します。期限外割引加重: 期限外割引を含むトランザクション金額に適用する加重を入力します。

入金額とトランザクション金額の間に完全一致が存在する場合、自動適用では、金額加重例外を参照せずに、「金額加重」しきい値を使用します。

入金額とトランザクション金額の間に完全一致が存在しない場合、自動適用では、すべての金額加重例外の中で最適な一致を検索して、パーセント・スコアを導出します。

たとえば、次の金額加重例外しきい値を入力します。

165

加重 値

正味税加重 70%

税および運送費の正味額加重 70%

正味運送費加重 80%

期限外割引加重 60%

ロックボックスの処理中に、次の詳細を含む入金消込に対してトランザクションが提示されます。

顧客アカウント番号: 1001未払額残高: 127割引後の金額: 120.65税金残高: 20運送費残高: 7期限外割引: 6.35

ロックボックスは、次の詳細を含む消込に対して入金を提示します。

顧客アカウント番号: 1005参照金額: 120

トランザクション金額と入金額の間に完全一致が存在しないため、自動適用では、金額加重例外の中で最も一致するものを検索して、金額加重を導出します。入金額と、運送費を除いたトランザクション金額(127 - 7= 120)の間に完全一致が存在します。そのため、自動適用では、金額加重しきいの計算スコアとして「正味運送費加重」しきい値80%を使用します。

自動照合の文字列処理の仕組み「自動照合ルール・セットの作成」ページおよび「自動照合ルール・セットの編集」ページの「文字列処理」セクションには、自動適用で使用される「入金別照合」文書参照に対するトランザクション照合の検索を支援するルールが用意されています。

これらのルールは、削除処理後の番号と入金処理中に提供される照合番号を比較するために、文字列のどの部分を削除するかを示します。文字列の照合勧告は、自動照合ルール・セットの加重しきい値に従って処理されます。

トランザクション文字列および送金文字列のルールを定義できます。

文字列処理に影響する設定

文字列処理の設定を使用して、文字列比較の前に文字列のどの部分を削除するかを指定します。これは通常、英数字のプリフィクスまたはサフィクス、あるいは番号を同じ長さにするために埋込みに使用されるゼロの文字列です。

次の設定を入力します。

文字列位置: 文字列の「前」または後ろのいずれから文字および数字を削除するかを指定します。文字列値: 削除する文字および数字のタイプを指定します(「ゼロ」、空のスペースまたは「すべ

166

て」)。「すべて」には、ゼロ、スペースおよびすべての文字、数字または特殊文字が含まれます。文字数: 削除する桁数を指定します。

文字列処理の使用方法

トランザクション番号の文字列処理設定が次のような場合:

文字列位置: 前。文字列値: すべて。文字数: 5。

文字列ABC: 10044は、10044に変換されます。文字列処理プロセスにより、文字列から最初の5文字(英数字ABC、コロン(:)およびスペース)が削除されました。

トランザクション番号の文字列処理設定が次のような場合:

文字列位置: 後ろ。文字列値: ゼロ。文字数: 3。

文字列は次のようになります。

ABC: 10044000は、ABC: 10044に変換されます。985660000は、985660に変換されます。985660000000003は処理されません。これは、自動適用が文字列の末尾にあるゼロを探しましたが、かわりに数字を検出したためです。

消込例外ルール・セット

消込例外ルールの条件と処理売掛/未収金消込例外ルール・セットの作成ページの「例外ルール」セクションを使用して、超過支払条件および過少支払条件のそれぞれの処理方法を指定します。

各例外ルールの構成は次のとおりです。

1つの条件。条件に適用される金額およびパーセント。条件が発生したときに実行する処理。

「処理」フィールドには、修正、入金消込または払戻に対して定義した売掛/未収金活動が含まれます。過少支払額または超過支払額は、該当する売掛/未収金活動に属する総勘定元帳勘定科目に計上されます。

「ユーザー・レビュー必須」オプションは、処理が自動的に処理されるか、手動レビューおよび承認が必要かを指定します。

たとえば、次の例外ルールがあるとします。

167

Over Payment >= 100 Refund

入金消込でトランザクションが$100以上の超過支払であった場合、顧客は払戻を受け入れる必要があることを意味します。

次の例外ルールがあるとします。

Under Payment < 5 Write-off

入金消込によって$5未満の過少支払が発生した場合、残金を消し込むことができます。

「パーセント」フィールドと「金額」フィールドを使用して、条件のスコープをさらに絞り込むことができます。両方のフィールドを使用する場合は、ルールを適用するために両方の条件を満たす必要があります。

たとえば、次の例外ルールがあるとします。

Under Payment < 5 5% Write-off

入金消込によって$5未満および未回収残高の5%未満の過少支払が発生した場合、残金を消し込むことができます。この場合、$10の未回収残高に$4の過少支払がある場合、$4は未回収残高の40%であるため、この例外ルールは適用されません。$4の過少支払が未回収残高$100に対するものである場合、$4は未回収残高の4%であるため、このルールが適用されます。

関連トピック

承認限度文書タイプ入金消込の勧告の計算方法

消込例外ルール・セットに関するFAQ

消込例外ルール・セットはいつ使用しますか。

消込例外ルール・セットを使用して、ロックボックス処理後の残金を管理します。

ロックボックスで入金が処理および消し込まれると、自動適用プロセスでは消込例外ルール・セットを使用して、超過支払および過少支払の管理方法を決定します。

超過支払がある場合、消込例外ルールは、金額を顧客に払い戻すか、金額を勘定に記録するか、金額を消し込むか、金額を未消込のままにするかを示します。過少支払がある場合、消込例外ルールは、トランザクションの未回収残高の残金の消込を許可するかどうかを示します。

自動照合ルール・セットと消込例外ルール・セットの違いは何ですか。

ロックボックスの処理中、自動照合ルール・セットでは、提供されたトランザクション情報に基づいて入金とトランザクションの照合に関する勧告を提供します。自動適用プロセスでは、入金とトランザクションを照合して、入金を自動的に消し込むか、入金消込に対して手動処理のトランザクション勧告を提示しようとします。

168

自動適用プロセスで、すべてのトランザクション参照に入金を自動的に消し込むことができる場合、消込例外ルール・セットの詳細を使用して、顧客に超過支払を払い戻すか(ある場合)、例外ルールに従って過少支払を処理します。

自動適用ですべてのトランザクション参照に入金を自動的に消し込むことができない場合、手動処理のために残りのトランザクション勧告(使用可能な場合)が提示され、消込例外ルール・セットは使用されません。

注意: 入金にトランザクション参照がない場合、超過支払の消込例外ルール・セットは使用されません。

顧客支払関係

顧客階層と支払関係顧客階層は、企業または企業の一部の体系を表します。企業体系は、FND_HIER表で定義および保守されます。顧客階層、取引先コミュニティ・パーティ階層およびダンアンドブラッドストリート階層の3つの事前定義済階層があります。

階層に支払関係を割り当てて、階層内のパーティが相互の顧客支払を管理できる方法を指定します。次の2つの支払関係があります。

任意支払: 関係内の任意のパーティは、その関係内の他の任意のパーティの勘定科目に対して支払を実行できます。下位支払: 親子関係によって、各パーティは、独自のトランザクションに加え、階層内の下位に存在するすべてのパーティ(子、孫など)のトランザクションに対して支払を実行できます。

この図は、Acme Corporationの顧客階層を示しています。

169

「任意支払」支払関係

このAcme Corporationの階層に「任意支払」支払関係が割り当てられている場合は、次のようになります。

Acme Worldwideは、Acme USA、Acme JapanおよびAcme Westに対して支払を行うことができます。Acme USAは、Acme Worldwide、Acme JapanおよびAcme Westに対して支払を行うことができます。Acme Japanは、Acme Worldwide、Acme USAおよびAcme Westに対して支払を行うことができます。Acme Westは、Acme Worldwide、Acme USAおよびAcme Japanに対して支払を行うことができます。

「下位支払」支払関係

このAcme Corporationの階層に「下位支払」支払関係が割り当てられている場合は、次のようになります。

Acme Worldwideは、Acme USA、Acme Japan、Acme Westおよび独自のトランザクションに対して支払を行うことができます。Acme USAは、Acme Westおよび独自のトランザクションに対して支払を行うことができます。Acme Japanは、独自のトランザクションに対して支払を行うことができます。

170

関連トピック

階層の管理方法

顧客支払関係に関するFAQ

アカウント関連と支払関連の違いは何ですか。

アカウント関係は、2つの顧客アカウント間のみのフラットな関係です。アカウント関係では、1つのアカウントが別のアカウントのトランザクションに対して支払を行う(一方向)か、両方のアカウントが相互のトランザクションに対して支払を行う(相互)ことができます。

支払関係は企業内の階層構造を利用して、あるパーティに関連付けられたすべての対応するアカウントおよびトランザクションが構造内の他のパーティにアクセスできるようにします。支払関係では、1つのアカウントが階層の下位のアカウントのトランザクションに対して支払を行う(下位支払)か、階層内のすべてのアカウントが他のパーティのトランザクションに対して支払を行う(任意支払)ことができます。

顧客階層タイプが非アクティブ化されるとどうなりますか。

この階層のアクティブな支払関係割当が無効になります。関連する支払関係割当ごとに、顧客階層タイプが非アクティブ化された日付以前の終了日を入力する必要があります。

入金ソースに関するFAQ

自動バッチ採番はどのように機能しますか。自動入金プロセスおよび自動送金プロセスでは、前のバッチ番号に+1を追加することにより、自動入金バッチまたは自動送金バッチに番号を割り当てます。自動入金の入金ソースを定義する場合、次の自動入金バッチ番号を増分する開始点として、「次のバッチ番号以降から開始」フィールドに番号を入力します。

たとえば、1000で始まる自動入金バッチを採番するには、番号999を入力します。自動入金プロセスでは、新しいバッチが作成されると、後続の各番号に+1が追加されます。

入金ソースはどこで使用されますか。入金ソースは、入金バッチおよび送金バッチでのみ使用します。これには、自動入金バッチ、ロックボックス入金、およびスプレッドシートを使用して作成された入金が含まれます。

自動入金の入金ソースは、自動入金プロセスおよび自動送金プロセスによって自動的に使用されます。この入金ソースを入力する必要はありません。

このページは役に立ちましたか?

171

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

172

19c

現預金のための売掛/未収金クレジットの実装

5 支払システムとの接続の構成この章の内容は次のとおりです。

検証のオプションフォーマットの設定方法伝送プロトコル伝送構成伝送構成の設定方法アウトバウンド・メッセージとインバウンド・メッセージのPretty Good Privacy (PGP)暗号化およびデジタル署名の構成方法伝送構成のテスト方法支払システムへの通信チャネルの構成方法支払システムの設定方法支払システム・アカウント複数のビジネス・ユニットの支払システム接続の設定: 説明トークン化設定データのインポートとエクスポートセキュリティ資格証明ファイルのインポート支払システムとの接続の構成に関するFAQ

検証のオプション検証は、トランザクションが印刷される前や支払システムに電子的に発行される前に、それらが有効であることを確認するルールです。検証を使用して、請求書、支払、支払ファイルなどの支出トランザクションの支払を行う前に、それらが特定の条件を満たしていることを確認します。支払方法および支払フォーマットに検証を割り当てることができます。検証は、買掛/未払金文書、支払または支払ファイル・レベルで実行できます。

173

支払処理では、支払システムおよび金融機関に送信された支払ファイルが有効であり、正しくフォーマットされていることが重要です。そうでない場合は、支払プロセスが遅くなり、問題の解決に余分な時間とコストがかかります。Oracle Fusion Paymentsでは、支払関連の詳細が有効であることを確認することにより、ストレートスルーな処理を実現できます。検証を割り当てる際には、次のオプションから選択できます。

検証の割当ユーザー定義の検証の作成検証の事前定義ライブラリからの選択

次の表は、検証可能なオブジェクトと、該当する設定について検証が実行される時期を示しています。

オブジェクト 支払方法に基づいた検証が実行される時期

支払ファイル・フォーマットに基づいた検証が実行される時期

買掛/未払金文書

請求書がソース製品に保存されたとき。請求書賦払が支払対象として選択されたとき。

請求書賦払が支払対象として選択されたとき。

支払 関連する買掛/未払金文書をまとめることによって支払が作成されたとき。

関連する買掛/未払金文書をまとめることによって支払が作成されたとき。

支払ファイル

該当なし。 支払ファイルが作成されたとき。

検証の割当ユーザー定義の検証は、次のものに割り当てることができます。

支払方法支払ファイル・フォーマット

検証の必要性を生じさせるものであればどのオブジェクトにも検証を割り当てることができます。たとえば、特定のフィールドの文字数を制限する必要がある銀行フォーマットの場合、その検証を銀行フォーマットに割り当てることができます。このようにすると、該当する場合にのみ検証が実行されるようになります。ただし、支払方法や支払フォーマットに固有でない一般的な検証を実行する場合は、自分でタイミングを決定できます。

Paymentsでは常に、所定のオブジェクトおよび設定について、可能なかぎり早い段階で検証が実行されます。支払方法に関連付けられた買掛/未払金文書の検証は、フォーマットに関連付けられたものよりも、プロセスの早い段階で実行されます。請求書を入力した同じ個人によって検証の失敗が処理されるようにする場合は、支払方法に検証を関連付けることができます。この方法は、入力した項目の完全な所有権が各個人に付与されるビジネス・プロセスに適しています。ただし、検証に失敗した請求書入力を対象として1人のスペシャリストが一元的に処理を担当するようにする場合は、フォーマットに検証を関連付けることができます。この方法は、一部の共有サービス・センターに適しています。

ユーザー定義の検証の作成ユーザー定義の検証では、検証を適用するオブジェクトを明示的に指定します。

買掛/未払金文書支払

174

支払ファイル

ユーザー定義の検証は、単純な操作に対応する基本的な検証です。これらの検証は、より複雑な検証を構築するためのコンポーネント、つまり構成要素として使用できます。たとえば、これらを使用して次の条件を検証できます。

値の長さ。例: 銀行固有の支払ファイル・フォーマットでは、「支払詳細」が60文字未満である必要があります。フィールドにデータが移入されているかどうか。例: 支払方法が「電子」である場合、送金先銀行口座が必要です。フィールドの内容が許可されているかどうか。例: 国内支払ファイル・フォーマットを使用する場合、通貨はUSDである必要があります。

検証の事前定義ライブラリからの選択Paymentsには、事前定義の検証のライブラリが用意されています。これらの事前定義の検証を、作成した支払方法または支払ファイル・フォーマットに関連付けることができます。Oracleが提供する支払フォーマットの多くには、事前定義の検証がデフォルトで関連付けられています。

事前定義の検証は、特定の目的のために個々の検証をまとめたグループです。支払フォーマットに関連付けることができる事前定義の検証の多くは、国固有です。事前定義の検証は変更できませんが、特定の値を定義するために設定可能なパラメータが含まれているものもあります。

フォーマットの設定方法フォーマットの設定は、Oracle Fusion Paymentsの必須タスクです。フォーマットは、Oracle BusinessIntelligence Publisher (Oracle BI Publisher)テンプレートが適用される支出または資金取得データ・ファイルです。Oracle BI Publisherテンプレートには、データ・ファイルをフォーマットするフォーマット属性が含まれています。フォーマットされる出力には、印刷される小切手、電子的に伝送される支払ファイル、決済バッチおよびレポートが含まれます。

フォーマットを設定する目的は、支出または資金取得トランザクションに関する固有のフォーマット要件がある場合に、支払システム、金融機関または国が会社のメッセージを認識できるようにすることです。インバウンド・メッセージは、支払システムまたは金融機関から会社に送信されます。アウトバウンド・メッセージは、会社から支払システムまたは金融機関に送信されます。

フォーマットの設定には、次の処理が含まれます。

Oracle BI Publisherテンプレートの使用データ抽出の使用IDフォーマットの使用ベスト・プラクティスの検討フォーマットの設定フォーマット・エンティティ間の関連の理解フォーマットへの検証の割当

175

注意: フォーマットを設定する前に、Oracle BI Publisherで対応するテンプレートを設定しておく必要があります。テンプレートの設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Publisherレポート・デザイナーズ・ガイド』(http://docs.oracle.com/cd/E25054_01/bi.1111/e13881/toc.htm)を参照してください。

Oracle BI Publisherテンプレートの使用Paymentsのフォーマットはそれぞれ1つのOracle BI Publisherテンプレートに対応します。BI Publisherテンプレートでは、フォーマットされた出力の生成方法を厳密に指定します。BI Publisherテンプレートを使用して、BI PublisherのeText機能によって、マシンで読取り可能な定位置形式のファイルを生成することもできます。

データ抽出の使用支出または資金取得フォーマットはそれぞれ、Paymentsの支出または資金取得データ抽出にも関連付けられます。それぞれのデータ抽出にはトランザクション・データが含まれます。Oracle BI Publisherテンプレートでは、データ抽出を使用してトランザクション・データをフォーマットします。トランザクション・データは、PaymentsまたはOracle Fusion Receivablesのトランザクション表から抽出されます。

支出抽出については、次のものからデータが取得されます。

支払支払ファイル買掛/未払金文書表

資金取得抽出については、次のものからデータが取得されます。

資金取得トランザクション決済バッチ売掛/未収金トランザクション

PaymentsのXML抽出の詳細は、My Oracle SupportにあるHow To Generate and View Fusion Payments XMLExtract (文書ID 1428249.1)を参照してください。

IDフォーマットの使用IDフォーマットでは、Paymentsに用意されているXML抽出が出力されます。これは診断を目的としていますが、トランザクションおよび設定エンティティから抽出フィールドにどのようにデータが移入されるかを理解するために使用することもできます。これは、他のテンプレートを使用して複雑な構成を作成する場合に特に便利です。

IDフォーマットは、IBY_IDENTITYと呼ばれるOracle BI Publisherテンプレートです。これは、資金取得承認および決済レポートの一部です。支出レポートにIDフォーマットを使用する場合、RTFテンプレートをダウンロードし、目的の支出レポートの一部としてアップロードする必要があります。その後、支払プロセス・プロファイルまたは資金取得プロセス・プロファイルで新しく作成したフォーマットを使用して、変更後のフォーマットをPaymentsで設定し、XML出力を確認できます。

176

ベスト・プラクティスの検討フォーマットを設定する前に、処理銀行でサポートされている支払フォーマットを確認します。複数の銀行で使用できる、標準ベースの次のような支払フォーマットを使用することを検討してください。

EDIFACTフォーマット(PAYMUL、MT100、MT103など)NACHAフォーマット(Generic、CCD、PPDなど)

フォーマットの設定「設定および保守」作業領域で、次のものを使用して、「フォーマットの管理」ページで事前定義のフォーマット・タイプを選択します。

オファリング: 財務機能領域: 支払タスク: フォーマットの管理

選択したフォーマット・タイプによって、次のものが指定されます。

作成されるメッセージのタイプデータ・ファイルのフォーマットに使用されるOracle BI Publisherテンプレート使用されるデータ抽出

「フォーマットの作成」ページで、選択したフォーマット・タイプにOracle BI Publisherテンプレートを関連付けます。

フォーマット・エンティティ間の関連の理解次の表は、フォーマット・タイプ、テンプレートおよびデータ抽出の間の関連について説明しています。

フォーマット・タイプ Oracle BI Publisherテンプレート データ抽出

支出支払ファイル・フォーマット 支出支払ファイル・フォーマット 支出抽出

支出正支払ファイル・フォーマット 支出正支払フォーマット 支出正支払抽出

支出送金通知書フォーマット 支出送金通知書フォーマット 支出抽出

支出付き通知書フォーマット 支出付き通知書フォーマット 支出抽出

支出支払プロセス要求ステータス・レポート・フォーマット

支出支払プロセス要求ステータス・レポート

支出支払プロセス要求抽出

支出支払ファイル台帳フォーマット 支出支払ファイル台帳 支出抽出

資金取得決済フォーマット 資金取得承認および決済フォーマット

資金取得抽出

資金取得付き通知書フォーマット 資金取得付き通知書フォーマット 資金取得抽出

資金取得支払人通知フォーマット 資金取得支払人通知フォーマット 資金取得抽出

177

フォーマットへの検証の割当フォーマットを作成したら、オプションで、「フォーマットの編集」ページで事前定義またはユーザー定義の支払検証を割り当てることができます。検証によって、支出または資金取得トランザクションが、指定した条件に従って実行されることが保証されます。

伝送プロトコルコンピュータは、伝送プロトコルを使用してネットワーク上で相互に通信します。Oracle Fusion Paymentsから支払システムに支払ファイルなどのデータを伝送するために、実装担当者は、支払システムが受信できるプロトコルを定義します。

Paymentsには、FTP、HTTP、HTTPSなど、事前に定義された業界標準の伝送プロトコルが用意されています。これらは、次のもので構成されています。

支払システム・サーブレットが伝送を行うために使用するコード入力ポイント伝送構成で値を指定する必要がある、ネットワーク・アドレスやポートなどのパラメータのリスト支払サーブレットに依存せず、Paymentsエンジンからコールできる伝送プロトコル入力ポイント

伝送プロトコルでは通信に必要なパラメータが定義され、伝送構成では各パラメータに指定する値が定義されます。伝送構成と支払システムは、資金取得については資金取得プロセス・プロファイルで、支出については支払プロセス・プロファイルで関連付けられます。

注意: この注意は、オンプレミスのお客様にのみ適用され、Oracle Cloudのお客様には適用されません。推奨されるファイルベース伝送プロトコルは、セキュア・ファイル転送プロトコル(SFTP)です。ファイル転送プロトコル(FTP)は保護されていないため、従来のサード・パーティ要件を満たすためにのみ使用してください。FTPは、仮想プライベート・ネットワークや、データ・リンク・レベルの暗号化が有効になっている専用回線などのセキュア・リンク上で使用する必要があります。

伝送構成伝送構成は、特定の伝送詳細のグループです。伝送構成では、伝送プロトコル内の各パラメータの値が定義されます。伝送構成の値は、1つの支払システムまたは金融機関に固有です。

たとえば、伝送プロトコルにソケットIPアドレスとソケット・ポート番号のパラメータ値が必要であるとします。そのプロトコルを受け入れる支払システムから、これらのパラメータについて受け取る必要がある値が提供されます。該当する値を伝送構成の「ソケットIPアドレス」フィールドと「ソケット・ポート番号」フィールドに入力します。伝送構成はその後、資金取得トランザクションについては資金取得プロセス・プロファイル内で、支出トランザクションについては支払プロセス・プロファイル内で支払システムに割り当てられます。

「設定および保守」作業領域で、次のものを使用して、伝送構成を設定することによりファイルを支払システムに伝送します。

178

オファリング: 財務機能領域: 支払タスク: 伝送構成の管理

「伝送構成の管理」ページで、「作成」をクリックします。「伝送構成の作成」ページが表示されます。

伝送構成の設定方法Oracle Fusion Paymentsでは、会社が支払システムまたは銀行に支払を伝送する場合、伝送構成の設定は必須です。会社が支払システムまたは銀行と情報を交換できるようにするには、情報をどのように構造化するか、およびそれぞれの側が情報をどのように送受信するかについて、事前の合意が存在している必要があります。

伝送構成の設定には、次の処理が含まれます。

プロトコルの理解伝送構成の理解トンネリング構成の理解ベスト・プラクティスの検討伝送構成の設定

プロトコルの理解伝送プロトコルは、コンピュータなどの電子デバイス間でデータを伝送するための一連のルールや手順です。Paymentsから外部の支払システムに支払ファイルや決済バッチなどのデータを伝送するには、支払システムが受入可能な伝送プロトコルを定義する必要があります。

Paymentsには、SFTP、HTTP、HTTPS、AS2など、業界標準の事前定義済伝送プロトコルが用意されています。これらのプロトコルには、次のものが含まれています。

一般的な方法で通信の技術詳細を実装するプロトコル実装クラス伝送構成で値を指定する必要がある、ネットワーク・アドレスやポートなどのパラメータのリスト

伝送プロトコルでは、会社とその支払システムまたは銀行の間の通信に必要なパラメータが定義されます。

伝送構成の理解伝送構成は、特定の伝送詳細のグループであり、特定の伝送プロトコルに関連付けられます。伝送構成では、伝送プロトコル内の各パラメータの値が定義されます。伝送構成の値は、1つの支払システムまたは金融機関に固有です。たとえば、パラメータとしてソケットIPアドレスとソケット・ポート番号が伝送プロトコルに必要な場合があります。そのプロトコルを受け入れる支払システムから、それらのパラメータについて受け取る必要がある値が提供されます。それらの値を「ソケットIPアドレス」フィールドと「ソケット・ポート番号」フィールドに入力します。

179

トンネリング構成の理解トンネリング構成は伝送構成の一種で、内部データを公開することなく、支払システムまたは銀行に安全に接続できる伝送サーブレットを介してデータを伝送できるようにします。伝送サーブレットは、ネットワーク・インフラストラクチャの異なるセグメント間のリレーまたはブリッジとして機能し、DMZゾーンなど、そこから外部システムへの接続を開くのに適したものもあります。

ベスト・プラクティスの検討支払処理のプロトコルを選択する前に、次のことを行ってください。

処理銀行で何がサポートされているかを確認します。Paymentsで事前定義されている伝送プロトコルを優先します。伝送およびフォーマットをより簡単に構成できるように、資金取得プロセス・プロファイルまたは支払プロセス・プロファイルを使用します。

支払処理の伝送構成を選択する前に、次の点に注意してください。

ネットワーク・セキュリティ・ルールによって通常ブロックされるプロトコルを使用する場合は、次のような2つの伝送構成が必要になることがあります。

ファイアウォールを通過するためのトンネリング構成支払システム・サーバーの伝送構成

伝送構成はトンネリング構成を指す必要があります。

注意: トンネリング構成が、それ自体を含む他のトンネリング構成を指す場合は、常に構成エラーとなります。

伝送構成の設定「設定および保守」作業領域で、次のものを使用して、伝送の方法であるプロトコルを選択し、「伝送構成の管理」ページで「作成」をクリックします。

オファリング: 財務機能領域: 支払タスク: 伝送構成の管理

「伝送構成の作成」ページで、選択したプロトコルについて各パラメータの値を指定して、支払システムまたは銀行との電子接続を有効にします。

伝送構成はその後、資金取得トランザクションについては資金取得プロセス・プロファイルで、支出については支払プロセス・プロファイルで支払システムまたは銀行に割り当てられます。

アウトバウンド・メッセージとインバウンド・

180

メッセージのPretty Good Privacy (PGP)暗号化およびデジタル署名の構成方法ペイロード・セキュリティを使用して、アウトバウンド・メッセージとインバウンド・メッセージの両方を保護できます。ペイロード・セキュリティでは、OpenPGP標準に基づいた支払ファイルの暗号化とデジタル署名を使用して、支払ファイルおよびその他のファイルを保護します。銀行との既存の接続に暗号化とデジタル署名を使用するように、既存の伝送構成を更新できます

アウトバウンド・メッセージの場合、Oracle Payments Cloudでは次のものについて暗号化とデジタル署名がサポートされています。

支出の支払ファイルおよび正支払ファイル資金取得の決済バッチ・ファイル

インバウンド・メッセージの場合、アプリケーションでは、次のものについてデジタル署名された暗号化ファイルの復号化と検証がサポートされています。

資金取得承認ファイル銀行取引明細書

SFTPやHTTPSなど、保護された伝送プロトコルを使用して支払データを保護することもできます。

注意: Oracle Applications Cloudでは、BCPG 1.45以下のバージョンのOpenPGP標準を使用して暗号化された支払ファイルの復号化がサポートされています。

アウトバウンド・メッセージとインバウンド・メッセージの暗号化およびデジタル署名の構成には、次の処理が含まれます。

キーの生成アウトバウンド伝送構成の設定インバウンド伝送構成の設定銀行から提供された公開キー・ファイルのアップロードシステム生成の公開キー・ファイルのダウンロード

キーの生成暗号化とデジタル署名の検証には公開キーが必要です。反対に、復号化とデジタル署名には非公開キーが必要です。公開キーと非公開キー(キー・ペアと呼ばれる)を生成したパーティが非公開キーを保持し、公開キーを他方のパーティと共有します。銀行との契約の対象となる公開キーを生成または受信できます。

次の表は、公開キーと非公開キーのペアの生成に関する一般的な詳細を示しています。

生成されるキー・ペアPaymentsからのアウトバウンド・メッセージを生成

Paymentsへのインバウンド・メッセージを生成

PGP公開暗号化キーおよびPGP非公開署名キー

銀行 当該会社

PGP公開署名検証キーおよびPGP非公開復号化キー

当該会社 銀行

181

キー・ペアを生成する場合、Oracle Applications Cloud内で自動的に生成できます。

PGP公開暗号化キーまたはPGP公開署名検証キーを受け取った場合、UCMを使用してOracle ApplicationsCloudにインポートする必要があります。

アウトバウンド伝送構成の設定支払ファイル、正支払ファイル、決済バッチ・ファイルなどのアウトバウンド・メッセージについては、次のことを行う必要があります。

銀行から提供された公開暗号化キーを使用して支払ファイルを暗号化します。オプションで、生成した非公開署名キーを使用して支払ファイルにデジタル署名します。

「伝送構成の作成」ページには、次の表に記載されているアウトバウンド・パラメータが表示されます。

アウトバウンド・パラメータ 説明

PGP公開暗号化キー

アウトバウンド支払ファイルの暗号化に使用する、銀行から提供されるキー。銀行から提供された公開暗号化キーをアップロードするには、「ツール」→「ファイル・インポート/エクスポート」にナビゲートしてUCMを使用します。最後に、「伝送構成の作成」ページの「PGP公開暗号化キー」パラメータについて、「値」選択リストから公開暗号化キー・ファイルを選択します。

PGP非公開署名キー

アウトバウンド支払ファイルにデジタル署名するために、ユーザーによって生成されるキー。非公開署名キーを生成するには、「PGP非公開署名キー」パラメータの「値」選択リストから「作成」オプションを選択します。アプリケーションは、次の処理を実行します。

非公開署名キーを自動的に生成し、伝送構成にリンクします。UCMからダウンロードして銀行と共有できる、公開暗号化キー・ファイルを生成します。銀行は、その公開暗号化キー・ファイルを使用して、銀行に伝送された支払ファイルのデジタル署名を検証します。

インバウンド伝送構成の設定承認や銀行取引明細書などのインバウンド支払メッセージについては、次のことを行う必要があります。

銀行から提供された公開署名検証キーを使用してデジタル署名を検証します。生成した非公開復号化キーを使用してファイルを復号化します。

「伝送構成の作成」ページには、次の表に記載されているインバウンド・パラメータが表示されます。

インバウンド・パラメータ 説明

PGP公開署名検証

インバウンド承認ファイルや銀行取引明細書のデジタル署名を検証するために使用する、銀行から提供されるキー。

182

キー銀行から提供された公開署名検証キーをアップロードするには、「ツール」→「ファイル・インポート/エクスポート」にナビゲートしてUCMを使用します。UCMを使用して、銀行から提供された公開署名検証キーをアップロードしたら、「伝送構成の作成」ページの「PGP公開署名検証キー」パラメータの「値」選択リストからそのキー・ファイルを選択できます。公開署名検証キー・ファイルを選択すると、自動的にインポートされます。

PGP非公開復号化キー

インバウンド暗号化ファイルを復号化するために、ユーザーによって生成されるキー。非公開復号化キーを生成するには、「PGP非公開復号化キー」パラメータの「値」選択リストから「作成」オプションを選択します。アプリケーションは、次の処理を実行します。

非公開復号化キーを生成し、伝送構成にリンクします。UCMからダウンロードして銀行と共有できる、公開署名検証キー・ファイルを生成します。銀行は、その公開署名検証キー・ファイルを使用して、承認や銀行取引明細書を暗号化します。

銀行から提供された公開キー・ファイルのアップロード銀行から提供されたPGP公開暗号化キーまたはPGP公開署名検証キーをOracle Applications Cloudにアップロード(インポート)するには、次のステップを実行します。

1. 銀行から提供されたキー・ファイルの名前にサフィクスとして_public.keyを追加して変更します。キー・ファイル名にアンダースコア以外の特殊文字が含まれていないことを確認してください。

2. 「ナビゲータ」→「ツール」→「ファイル・インポート/エクスポート」にナビゲートします。3. 銀行から提供されたキー・ファイルをアカウントfin/payments/importにインポートします。4. 「伝送構成の作成」ページにナビゲートします。5. 該当するパラメータの「値」選択リストから、アップロードしたキー・ファイルを選択します。

ヒント: 選択リスト内のキー名は、UCMを使用してアップロードしたものと同じです。

6. キーを選択して伝送構成を保存すると、キーが自動的にPaymentsにインポートされます。

システム生成の公開キー・ファイルのダウンロードシステム生成の公開キー・ファイルをPaymentsからダウンロードして銀行と共有するには、次のステップを実行します。

1. 「伝送構成の作成」ページで、該当するパラメータについて「作成」オプションを選択します。2. 「保存してクローズ」ボタンをクリックします。3. 「ナビゲータ」→「ツール」→「ファイル・インポート/エクスポート」にナビゲートします。4. 「アカウント」選択リストから、fin/payments/importを選択し、システム生成の公開キー・ファイルを検索します。

5. システム生成の公開キー・ファイルをダウンロードします。

ヒント: ファイル名は、生成されて伝送構成に関連付けられた非公開キー・ファイルと類似しています。

注意: SFTP 2要素認証のSSH (セキュア・ソケット・シェル)キー生成は、サービス・リクエストに基づいてOracle Supportによって生成されます。

183

伝送構成のテスト方法伝送構成設定は、アウトバウンド支払ファイル、決済バッチ・ファイルおよび正支払ファイルを支払システムまたは金融機関に伝送するために使用されます。また、資金取得承認ファイルを取得するためにも使用されます。この設定では、プロトコルによって異なる可能性がある様々なパラメータを取得します。伝送構成をテストして、アウトバウンドおよびインバウンド伝送プロトコルの設定が正しいかどうかを確認できます。

設定が正確であることを確認するには、「伝送構成の作成」ページまたは「伝送構成の編集」ページで「テスト」ボタンをクリックします。「テスト」ボタンがアクティブになるのは、すべての必須パラメータに関連付けられた値が存在する場合のみです。テストに使用できる一般的な伝送構成パラメータは次のとおりです。

宛先サーバーのURL宛先サーバーのIPアドレス宛先サーバーのポート番号リモート・ファイル・ディレクトリユーザー資格証明

伝送構成設定のテストには、戻りメッセージのレビューが含まれます。

戻りメッセージのレビュー「テスト」ボタンの処理によって、指定したパラメータを使用して宛先サーバーに接続し、結果として戻りメッセージが生成されます。戻りメッセージは、機能テキストとRAWメッセージ・テキストの組合せです。そのため、機能ユーザーと技術ユーザーの両方がメッセージから有用な情報を得ることができます。たとえば、リモート・ファイル・ディレクトリが無効であるとします。この場合、戻りメッセージは「リモート・ディレクトリが正しくありません(IBY_Trans_Test_Remote_Dir_Fals)」のようになります。

次の表は、伝送構成の接続テストとテスト結果とともに、関連する戻りメッセージについて説明しています。

テスト テスト結果 戻りメッセージ

接続が正しいかどうか。 接続に成功しました。リモート・ファイル・ディレクトリが存在します。

成功(RAWメッセージ)

リモート・ファイル・ディレクトリが有効かどうか。

接続に成功しました。リモート・ファイル・ディレクトリが存在しないか、正しくありません。

リモート・ディレクトリが正しくありません(RAWメッセージ)

ユーザー資格証明が正しいかどうか。

接続に失敗しました。宛先IPアドレスおよびポートは正確です。ログイン資格証明が正しくありません。

ユーザー資格証明が正しくありません(RAWメッセージ)

IPアドレスまたはポートが正しいかどうか。

接続に失敗しました。IPアドレスまたはポートが正しくあ

宛先サーバーの詳細が正しくありません(RAWメッセージ)

184

りません。

キー・ファイルベースの2要素認証に成功したかどうか。

接続に失敗しました。キー・ファイルベースの認証に失敗しました。

認証に失敗しました(RAWメッセージ)

宛先サーバーが応答するかどうか。

宛先サーバーは停止しています。 宛先サーバーは応答していません(RAWメッセージ)

該当なし。 その他の失敗。 (RAWメッセージ)

支払システムへの通信チャネルの構成方法支払情報を支払システムとの間で伝送または受信するには、支払システムとの通信に使用するチャネルを構成する必要があります。このトピックでは、次の概念について説明します。

プロキシ・サーバーSecure Sockets Layer (SSL)プロトコル保護されていないプロトコル

プロキシ・サーバーPaymentsは、プロキシ・サーバーを介してその支払システムと通信する必要があります。Oracle FusionApplicationsを最初に設定したときに構成ファイル内にある標準のJavaネットワーキング・プロキシ・システムのプロパティを使用できます。また、「伝送構成の作成」ページで「プロキシ・ホスト」パラメータの値を入力して、伝送プロトコルのプロキシ設定を指定することもできます。

Secure Sockets LayerプロトコルPaymentsが支払システムと通信する際に交換される情報は、クレジット・カード番号などの機密情報である場合があります。通信がセキュアでない場合は、セキュリティ・リスクが生じます。支払システムへの通信がインターネットなどのパブリック・ネットワークを介して行われると、セキュリティ・リスクは高まります。

Secure Sockets Layerを使用して支払システム・サーブレットを設定するには、サーブレットが常駐するアプリケーション・サーバーでHTTPSを有効にします。支払システムについて資金取得プロセス・プロファイルが定義されていない場合は、「支払システムの編集」ページの「伝送サーブレット・ベースURL」を、HTTPSで始まるように変更します。資金取得プロセス・プロファイルが定義されている場合は、「伝送構成の編集」ページの「宛先URL」パラメータの値を、HTTPSで始まるように変更します。

支払システムとのセキュアな通信を行うには、最新の認証局(CA)証明書がOracle Fusionのセキュア・ソケットのトラスト・ストア・ファイルにあることを確認してください。Paymentsで支払システムのセキュア・ソケット証明書が拒否される場合は、証明書を手動で挿入する必要が生じることがあります。

次の表は、クラウドおよびオンプレミスに適用可能なセキュリティ処理を示しています。

処理 クラウド オンプレミス

185

Secure Sockets Layerを使用して支払システム・サーブレットを設定する。

該当なし。 サーブレットのアプリケーション・サーバーでSSLを有効にします。

認証局証明書を挿入する。 ヘルプ・デスクにサービス・リクエストを提出します。

「伝送構成の作成」ページまたは「伝送構成の編集」ページで「Walletの場所」パラメータの「値」フィールドに値を入力します。

保護されていないプロトコル推奨されるファイルベース伝送プロトコルは、セキュア・ファイル転送プロトコル(SFTP)です。ファイル転送プロトコル(FTP)は保護されていないため、従来のサード・パーティ要件を満たすためにのみ使用してください。FTPは、仮想プライベート・ネットワークや、データ・リンク・レベルの暗号化が有効になっている専用回線などのセキュア・リンク上で使用する必要があります。

支払システムの設定方法Oracle Fusion Paymentsでは、会社が支払システムまたは銀行に電子支払または資金取得トランザクションを伝送する場合には、支払システムの設定が必須になります。支払システムは、会社が銀行口座を持つ銀行にすることも、会社を財務ネットワークに接続するサード・パーティ・プロセッサまたはゲートウェイにすることもできます。支払システムを設定する目的は、Paymentsで資金取得および支出トランザクションの処理に使用される外部組織を定義することです。

小切手など、印刷される支出支払には支払システムは必要ありませんが、正支払レポートなどの関連サービスには必要になることがあります。

支払システムの設定には、次の処理が含まれます。

ゲートウェイまたはプロセッサ支払システムの選択ベスト・プラクティスの検討支払システムの定義支払システム設定の指定支払システム・アカウントの理解

ゲートウェイまたはプロセッサ支払システムの選択Paymentsでは、ゲートウェイ支払システムとプロセッサ支払システムの両方がサポートされています。ゲートウェイは、第一者受取人と支払プロセッサの間の仲介として機能するサービス・プロバイダです。プロセッサは、銀行およびカード会社と直接連携して財務トランザクションを処理するサービス・プロバイダです。支払プロセッサの例には、Visa、MasterCard、American Expressなどがあります。

ゲートウェイ支払システムとプロセッサ支払システムのどちらと統合するかの選択は、通常、次のような要素によって決まります。

ビジネスのタイプ1日当たりのトランザクション数

186

銀行

次の表は、ゲートウェイ支払システムとプロセッサ支払システムの違いについて説明しています。

要素 ゲートウェイ プロセッサ

接続とセキュリティ

簡単な接続を提供し、多くの場合はSSLベースのインターネット接続を使用します。

より厳密なセキュリティ、接続およびテスト要件を提供します。

追加料金 プロセッサ手数料に加えて、トランザクションごとの料金などの追加料金を課します。

該当なし。

トランザクションの量

トランザクションの量が少ない業者や、設定と接続が簡単であればトランザクションごとのプレミアムを支払っても構わないという業者に適しています。

多くの場合、プロセッサ接続のために多くの労力をかけても構わないという、トランザクションの量が多い業者に適しています。

オンラインまたはオフライン

すべてのトランザクションがオンラインで行われます。

承認はリアルタイムで行い、決済やクレジットなどのフォローアップ・トランザクションはオフラインで行うことができます。

オフライン・トランザクションは、まとめてバッチ処理し、1つの要求として支払システムに送信する必要があります。承認以外のトランザクションはすべて、デフォルトではオフラインで実行されます。オフライン・トランザクションは、次の決済バッチ操作が試行されるときに送信されます。

ベスト・プラクティスの検討支払システムを設定する前に、銀行やプロセッサとの現在の関係を活用します。銀行またはプロセッサがトランザクションを処理できるか、プロセッサとのパートナシップがあるかを確認します。

支払システムの定義「設定および保守」作業領域で、次のものを使用して、支払システムを定義します。

オファリング: 財務機能領域: 支払タスク: 支払システムの管理

「支払システムの管理」ページで、「作成」をクリックします。「支払システムの作成」ページが表示されます。

「支払システムの作成」ページで支払システムを設定するときには、次のものを指定します。

支払システムが資金取得トランザクションについてサポートする支払手段のタイプ支払システムが受け入れるデータ・ファイル・フォーマットおよび伝送プロトコル

187

支払システムで必要な設定トークン化プロバイダで必要な設定(会社がトークン化を有効にしている場合)

注意: 支払システムの設定は、支払ファイルをローカル・ドライブにダウンロードして支払システムまたは銀行にEメールで送信することにより、オフラインで伝送する場合にも必要になることがあります。支払システムおよび支払システム・アカウントの設定では、支払ファイルまたは決済バッチ・メッセージで渡される様々な属性を取得します。これらの属性がない場合、支払ファイルは無効であり、銀行で拒否されます。

支払システム設定の指定「支払システムで必要な設定」セクションで、支払システムがそれぞれの内部支払人または受取人から必要とする設定を指定します。これらの設定を使用して、内部支払人または受取人を支払システムのクライアントとして指定したり、他の処理情報を指定できます。それぞれの設定に必要なデータのタイプを指定し、マスキングによって設定の値を保護することを推奨するかどうかを決定できます。

ヒント: 支払システム・アカウントの一部として入力する支払システム設定の値は通常、支払システムから提供されます。

支払システム・アカウントの理解「支払システム・アカウントの編集」ページで、支払システムとの会社のアカウントを定義します。支払システム・アカウントには、支払システムで必要な各属性の値が含まれます。たとえば、支払システムでは、送信されるメッセージに発行者IDおよび発行者パスワードが必要な場合があります。

パスワードを入力することにより、セキュアな支払システム・アカウントを構成できます。保護された設定では、支払システム・アカウントで取得された値がマスクされます。

ヒント: 1つの支払システムについてPaymentsで複数の支払システム・アカウントを設定できます。

支払システム・アカウント支払システム・アカウントは、パラメータの値で構成されるアカウント識別子です。支払システムから、それぞれの支払または決済バッチ・ファイルを識別するために必要な値が提供されます。支払システム・アカウントに格納されるのは、設定および会社の識別子の値です。会社は、1つの支払システムとの間に複数の支払システム・アカウントを持つことができます。

支払システム・アカウントは、次の設定オブジェクトに関連付けられます。

内部受取人資金取得プロセス・プロファイル支払プロセス・プロファイル

次の表は、設定オブジェクトと、それらが支払システムに関連して実行する処理を示しています。

188

設定オブジェクト 設定オブジェクトの処理

支払システム 資金取得トランザクションの送信先をPaymentsに通知します。支出トランザクションの送信先をPaymentsに通知します。

支払システム・アカウント 支払システムに対して自身を識別する方法をPaymentsに通知します

伝送構成 トランザクションを支払システムに伝送する方法をPaymentsに通知します

内部受取人内部受取人に割り当てられるルーティング・ルールを設定できます。ルーティング・ルールでは、様々なトランザクション属性の値に基づいて、トランザクションの伝送先となる支払システム・アカウントが指定されます。

どの支払システム・アカウントがトランザクションに適切なものであるかを決定する詳細なルーティング・ルールが必要でない場合、またはいずれのルーティング・ルールも適用されない場合のフォールバック値を必要とする場合は、支払方法ごとにそれぞれの内部受取人について1つのデフォルトの支払システム・アカウントを設定できます。

資金取得プロセス・プロファイル資金取得プロセス・プロファイルによって、資金取得トランザクションの処理方法および支払システムとの通信方法がOracle Fusion Paymentsに通知されます。資金取得プロセス・プロファイルは、1つの支払システムおよびその支払システム・アカウントに固有です。

資金取得プロセス・プロファイルで有効になっている支払システム・アカウントごとに、最大3つの伝送構成(承認、決済および通知についてそれぞれ1つずつ)を選択できます。

支払プロセス・プロファイル支払プロセス・プロファイルによって、支出トランザクションの処理方法、および支払ファイルまたは正支払ファイルを伝送するための支払システムとの通信方法がPaymentsに通知されます。電子伝送が必要な場合、支払プロセス・プロファイルは、1つの支払システムおよびその支払システム・アカウントに固有です。支払プロセス・プロファイルで有効になっている支払システム・アカウントごとに、伝送構成を選択します。

複数のビジネス・ユニットの支払システム接続の設定: 説明様々な国でクレジット・カード機能を実装する場合、各国のビジネス・ユニットごとに業者アカウントとSecure Acceptanceプロファイルの個別の組合せを構成できます。業者アカウントは、トークン化サービス・プロバイダであるCyberSourceで設定する業者識別子です。Secure Acceptanceプロファイルは、業者がクレジット・カード・トランザクションに使用する接続設定を表します。支払システム接続は、支払システム・レベルと支払システム・アカウント・レベルの両方で設定できます。支払システム・レベルで

189

は、CyberSourceとの接続に必要なパラメータを取得します。また、支払システム・アカウント・レベルでは、同じパラメータに加えて、ビジネス・ユニットなどの追加パラメータを取得することもできます。これらの接続オプションを使用して、CyberSourceの業者アカウントごとに個別の支払システム・アカウントを構成できます。

複数のビジネス・ユニットの場合はまず、1つの国の各ビジネス・ユニットについて、CyberSourceで業者アカウントとSecure Acceptanceプロファイルの組合せごとに接続設定を設定します。その後、OraclePaymentsで対応する接続設定を支払システム・アカウント・レベルで入力する必要があります。このシナリオでは、支払システム・レベルで構成されたパラメータはデフォルトの接続設定として機能します。ただし、ビジネス・ユニットの支払システム・アカウントがない場合、支払システム・レベルのパラメータ値が使用されます。同様に、業者アカウントが1つのみの場合は、支払システム・レベルで支払システム接続を構成します。

次の図は、CyberSourceにおける設定とアプリケーションにおける設定の関連を示しています。

190

前提条件複数のビジネス・ユニットの支払システム接続を設定する前に、「システム・セキュリティ・オプションの管理」ページでトークン化を有効にしておく必要があります。

複数の業者アカウントとSecure Acceptanceプロファイルの組合せの設定Oracle Public Cloud Applicationsでクレジット・カード機能を使用する前に、CyberSourceで次のステップを実行する必要があります。

1. CyberSourceとの業者アカウントを設定します。2. アクティブなCyberSource Secure Acceptanceプロファイルを作成します。

支払システム接続の設定業者アカウントとSecure Acceptanceプロファイルの組合せが1つのみである場合は、「支払システムの作成」ページで接続情報を設定する必要があります。

次の表は、「支払システムの作成」ページおよび「伝送構成の作成」ページの「トークン化支払システム設定」セクションにある「値」フィールドに入力する接続設定を示しています。

CyberSourcePaymentsの設定

Paymentsのページ Paymentsのフィールド

Secure AcceptanceプロファイルによってSecureAcceptanceアクセス・キーが生成される

SecureAcceptanceアクセス・キー

「支払システムの作成」ページ

Secure Acceptanceアクセス・キーを安全に切り取って、「値」フィールドに貼り付けます。

Secure AcceptanceプロファイルによってSecureAcceptance署名キーが生成される

SecureAcceptance署名キー

「支払システムの作成」ページ

Secure Acceptance署名キーを安全に切り取って、「値」フィールドに貼り付けます。

CyberSource SecureAcceptance Web/MobileConfiguration Guide

トークン化サーブレット・ベースURL

「支払システムの作成」ページ

『CyberSource Secure Acceptance Web/MobileConfiguration Guide』からこの定数値をコピーして、「値」フィールドにトークン化サーブレット・ベースURLを貼り付けます。

注意: トークン化サーブレット・ベースURLは、CyberSourceのドキュメントではiFrameCreate Payment Token Endpointと呼ばれています。

Secure Acceptanceプロファイルを保存すると、プロファイルIDが自動的に生成される。

クライアント識別子(プロファイルIDと同じ)。

「支払システムの作成」ページ

「値」フィールドにプロファイルIDを入力します。

該当なし トークン作成モジュール

「支払システムの作成」ページ

「値」選択リストから「CyberSource SecureAcceptance Web」を選択します。

191

CyberSource SecureAcceptance Web/MobileConfiguration Guide

トークン化支払URL

「支払システムの作成」ページ

『CyberSource Secure Acceptance Web/MobileConfiguration Guide』からこの定数値をコピーして、「値」フィールドにトークン化支払URLを貼り付けます。

注意: トークン化支払URLは、CyberSourceのドキュメントではiFrame Transaction Endpointと呼ばれています。

CyberSource SOAP ToolKits for Web ServicesDeveloper Guide

SOAPトランザクションURL

「伝送構成の作成」ページ

『CyberSource SOAP Tool Kits for Web ServicesDeveloper Guide』からこの値をコピーして、「値」フィールドにSOAPトランザクションURLを貼り付けます。

業者接続の設定業者アカウントとSecure Acceptanceプロファイルの組合せが複数ある場合は、「支払システム・アカウントの編集」ページで接続情報を設定します。

次の表は、「支払システム・アカウントの編集」ページの「設定」セクションにある「値」フィールドに入力する接続設定を示しています。

CyberSourcePaymentsの設定 Paymentsのページ Paymentsのフィールド

該当なし 商業インジケータ

「支払システム・アカウントの編集」ページ 「値」フィールドにインターネットと入力します。

「Transaction SecurityKey」ページでトランザクション・セキュリティ・キーが生成される。

SOAP APIセキュリティ・キー

「支払システム・アカウントの編集」ページ 前にダウンロードしたトランザクション・セキュリティ・キーを「値」フィールドに入力します。

Secure AcceptanceプロファイルによってSecure Acceptanceアクセス・キーが生成される

SecureAcceptanceアクセス・キー

「支払システム・アカウントの編集」ページ

注意: この接続が支払システム・アカウント・レベルで構成されている場合は、ここで取得します。この接続が支払システム・レベルで構成されている場合は、そこで取得します。

Secure Acceptanceアクセス・キーを安全に切り取って、「値」フィールドに貼り付けます。

Secure AcceptanceプロファイルによってSecure Acceptance署名キーが生成される

SecureAcceptance署名キー

「支払システム・アカウントの編集」ページ

注意: この接続が支払システム・アカウント・レベルで構成されている場合は、ここで取得します。この接続が支払システム・レベルで構成されている場合は、そこで取得します。

Secure Acceptance署名キーを安全に切り取って、「値」フィールドに貼り付けます。

Secure Acceptanceプロファイルを保存すると、プロファイルIDが自動的に生成される。

クライアント識別子(プロファイルIDと同じ)。

「支払システム・アカウントの編集」ページ

注意: この接続が支払システム・アカウント・レベルで構成されている場合は、ここで取得します。この接続が支払システム・レベルで構成されている場合は、そ

「値」フィールドにプロファイルIDを入力します。

192

こで取得します。

関連トピック

クレジット・カード・トークン化を有効にする方法

トークン化設定データのインポートとエクスポートトークン化設定データは、「支払システムの作成」ページおよび「支払システム・アカウント」ページで設定する値(キー)で構成されます。テスト環境のこれらのページで、該当する「値」フィールドにSecureAcceptanceアクセス・キーとSecure Acceptance署名キーの値を入力します。キーの値は、CyberSourceテスト・アカウントから取得します。どちらのキーもCyberSourceデータ・センターでの認証に使用されます。トークン化を実行するには、これらが必要です。

次の図は、トークン化設定データをテスト環境からエクスポートし、トークン化設定データを本番環境からテスト環境にコピーして、クレジット・カードのテストが完了した後に、エクスポートしたものと同じトークン化設定データをインポートするために実行するステップを示しています。

注意: クレジット・カード・サービスは、現在、Oracle Financials Cloud実装では使用できません。

193

本番に類似した環境でクレジット・カードおよびトークン化設定データをテストするには、次のステップを実行します。

1. トークン化設定データをテスト環境からローカル・ドライブにエクスポートし、ファイルとして保存します。

2. 本番環境のトークン化設定データをテスト環境にコピーして、テスト環境を疑似本番環境のトークン化設定データで上書きします。

3. 前にエクスポートしたものと同じトークン化設定データ・ファイルを本番に類似した環境にインポートして、元のテスト環境に戻します。

トークン化設定データのエクスポートトークン化設定データをテスト環境からローカル・ドライブにエクスポートするには、次のステップを実行します。

1. 「ツール」→「スケジュール済プロセス」にナビゲートします。2. 「概要」ページで、「新規プロセスのスケジュール」をクリックします。3. 「新規プロセスのスケジュール」ページで、「セキュリティ証明書のインポート・ジョブ」を検索して選択します。

194

4. 「資格証明ファイル・タイプ」選択リストから、「トークン化設定のエクスポート」を選択します。

5. 「送信」をクリックします。6. 「ツール」→「ファイル・インポートおよびエクスポート」の順にナビゲートします。7. 「アカウント」選択リストから、fin/payments/importを選択します。8. 「検索」をクリックします。9. 「検索結果」セクションで、ファイルをクリックし、ローカル・ドライブに保存します。

テスト環境への本番環境のトークン化設定データのコピー本番環境のトークン化設定データをテスト環境にコピーするには、標準的な手法に従います。コピー手順により、テスト環境が本番環境のトークン化設定データで上書きされます。これで、本番に類似した環境でクレジット・カードをテストできます。

エクスポートしたトークン化設定データのアップロードトークン化設定データをインポートする前に、前にダウンロードしたファイルをローカル・ドライブからUCMにアップロードする必要があります。ファイルをアップロードするには、次のステップを実行します。

1. 「ツール」→「ファイル・インポートおよびエクスポート」の順にナビゲートします。2. 「検索結果」セクションで「+」アイコンをクリックします。3. 「ファイルのアップロード」ダイアログ・ボックスで、「ファイルの選択」をクリックして、アップロードするファイルを参照します。

4. 「アカウント」選択リストから、fin/payments/importを選択します。5. 「保存してクローズ」をクリックします。

トークン化設定データのインポートトークン化設定データをローカル・ドライブから本番に類似した環境にインポートするには、次のステップを実行します。

1. 「ツール」→「スケジュール済プロセス」にナビゲートします。2. 「概要」ページで、「新規プロセスのスケジュール」をクリックします。3. 「新規プロセスのスケジュール」ページで、「セキュリティ証明書のインポート・ジョブ」を検索して選択します。

4. 「資格証明ファイル・タイプ」選択リストから、「トークン化設定のインポート」を選択します。5. 「UCMファイル名」選択リストから、アップロードしたファイルを選択します。6. 「送信」をクリックします。

セキュリティ資格証明ファイルのインポート電子伝送を保護するために、セキュリティ資格証明ファイルをアップロードおよびインポートして、伝送構

195

成に割り当てることができます。セキュリティ資格証明ファイルは、銀行などのリモートのサード・パーティ・システムに伝送されるデータを暗号化または認証するためにアプリケーションが使用する、セキュリティ・キーが格納されたデジタル・ファイルです。セキュリティ資格証明ファイルとその秘密キーが特定の伝送構成に割り当てられると、この伝送構成を実行および参照するその後のプロセスでは、そのファイルとそのキーが伝送セキュリティに使用されます。アプリケーションは、どの資格証明ファイルがどのプロトコルで使用されるかを認識し、適切なもののみを設定ページに表示します。

Paymentsでは、Walletファイル、トラスト・ストア・ファイル、デジタル証明書など、セキュリティ関連の様々な資格証明ファイルがサポートされています。

注意: この手順は、Oracle Cloud実装にのみ適用されます。

セキュリティ資格証明ファイルとそのキーをPaymentsにインポートする前に、まず、Paymentsマスター暗号化キーを作成する必要があります。

Walletファイルとマスター暗号化キーの自動作成Walletファイルとマスター暗号化キーを自動的に作成するには、次のステップを実行します。

1. 「設定および保守」作業領域で、次の項目に移動します。オファリング: 財務機能領域: 支払タスク: システム・セキュリティ・オプションの管理

2. 「システム・セキュリティ・オプションの管理」ページで、「クイック・デフォルトの適用」をクリックします。

3. 「Walletファイルおよびマスター暗号化キーの自動作成」チェック・ボックスを選択します。4. 「保存してクローズ」をクリックします。

Walletセキュリティ資格証明ファイルのアップロードセキュリティ資格証明ファイルをインポートする前に、まず、そのファイルをPaymentsにアップロードする必要があります。

注意: 必ず、資格証明ファイルの作成時にはパスワードで保護し、インポート・プロセスが完了したらすぐにOracle Fusion Applicationsから削除してください。

1. 「ツール」→「ファイル・インポート/エクスポート」にナビゲートします。2. 「アップロード」アイコンをクリックして、「ファイルのアップロード」ダイアログ・ボックスを開きます

3. 作成してローカルに格納したファイルを参照します。4. 「アカウント」選択リストから、fin/payments/importを選択します。5. 「保存してクローズ」ボタンをクリックします。

Walletセキュリティ資格証明ファイルのインポート拡張セキュリティ機能で使用するWalletや非公開キーなど、セキュリティ関連の資格証明ファイルをイン

196

ポートするには、「セキュリティ証明書のインポート・ジョブ」プロセスを使用します。

1. 「ツール」→「スケジュール済プロセス」にナビゲートして、「スケジュール済プロセス」ページを開きます。

2. 「新規プロセスのスケジュール」ボタンをクリックして、「新規プロセスのスケジュール」ダイアログ・ボックスを開きます。

3. 大/小文字を区別して「セキュリティ証明書のインポート・ジョブ」を検索して選択し、「プロセスの詳細」ダイアログ・ボックスを開きます。

4. 「資格証明ファイル・タイプ」選択リストから、資格証明に適したファイル・タイプを選択します。

5. 「セキュリティ資格証明名」フィールドに、資格証明ファイルの名前を入力します。6. UCM (ユニバーサル・コンテンツ管理)の「ファイル名」選択リストから、前にアップロードしたファイルを選択します。

7. 「送信」ボタンをクリックします。確認メッセージに、プロセスが正常に実行されたことが示されます。

8. 「閉じる」ボタンをクリックします。9. 「リフレッシュ」アイコンをクリックします。「検索結果」セクションに「セキュリティ証明書のインポート・ジョブ」が「成功」ステータスで表示されます。

伝送構成へのWalletファイルの割当資格証明ファイルを伝送構成に割り当てるには、次のステップを実行します。

1. 「設定および保守」作業領域で、次の項目に移動します。オファリング: 財務機能領域: 支払タスク: 伝送構成の管理

2. 「伝送構成の管理」ページの「検索」セクションで、「プロトコル」選択リストからプロトコルを選択し、「検索」をクリックします。

3. 「検索結果」セクションで、該当する構成リンクをクリックして「伝送構成の編集」ページを開きます。

4. プロトコルの該当するパラメータの「値」フィールドで、作成、アップロードおよびインポートしたファイルを選択します。セキュリティ資格証明ファイルのインポートに使用される具体的なパラメータの名前は、プロトコルによって異なります。

これで、この伝送構成を使用して電子ファイルを安全に伝送できます。

支払システムとの接続の構成に関するFAQ

フォーマット・タイプとは何ですか。フォーマットの用途を示すタイプまたはカテゴリ。フォーマット・タイプの例には、支払ファイル、送金通

197

知書、銀行取引明細書などがあります。Oracle Fusion Paymentsで作成した各フォーマットはフォーマット・タイプに関連付けられるため、アプリケーションでフォーマットの使用方法が認識されます。フォーマット・タイプは、支払ファイルに関連する支出フォーマット、または決済やレポートに関連する資金取得フォーマットです。

次の表は、フォーマット・タイプのいくつかの例を示しています。

支出フォーマット・タイプ 資金取得フォーマット・タイプ

支出送金通知書 資金取得承認および決済

支出正支払ファイル 資金取得付き通知書

支出支払プロセス要求ステータス・レポート 資金取得支払人通知

フォーマットに関連付けたフォーマット・タイプによって、次のものが指定されます。

作成されるメッセージのタイプトランザクション・データをフォーマットするためにテンプレートで使用されるデータ抽出

関連トピック

Oracle BI Publisher Enterpriseを使用して、フォーマットで使用するためのテンプレートを変更する方法

複数のビジネス・ユニットの支払システム接続を設定できますか。はい。様々な国でクレジット・カード機能を実装する場合、各国のビジネス・ユニットごとに業者アカウントとSecure Acceptanceプロファイルの個別の組合せをCyberSourceで構成できます。その後、OraclePaymentsで対応する接続設定を支払システム・アカウント・レベルで入力します。支払システム接続は、支払システム・レベルと支払システム・アカウント・レベルの両方で設定できます。支払システム・レベルでは、CyberSourceとの接続に必要なパラメータを取得します。支払システム・アカウント・レベルでは、支払システム・レベルと同じパラメータに加えて、ビジネス・ユニットなどの追加パラメータを取得します。これらの接続オプションを使用して、CyberSourceの業者アカウントごとに個別の支払システム・アカウントを構成できます。

関連トピック

クレジット・カード・トークン化を有効にする方法

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

198

19c

現預金のための売掛/未収金クレジットの実装

6 資金取得の定義この章の内容は次のとおりです。

資金取得プロセス・プロファイル決済グループ化ルールの例ルーティング・ルールOracle BI Publisher Enterpriseを使用して、フォーマットで使用するためのテンプレートを変更する方法資金取得の定義に関するFAQ

資金取得プロセス・プロファイル資金取得プロセス・プロファイルは、資金取得トランザクションの処理に必要なすべてのルールが含まれる、重要な設定エンティティです。これによって特定の支払システムとの通信方法がOracle FusionPaymentsに通知され、また、これにはトランザクションの処理に使用される支払システム・アカウントが含まれます。処理中に、内部受取人の設定中に作成されるトランザクション・ルーティング・ルールから、資金取得プロセス・プロファイルが導出されます。

注意: クレジット・カード・サービスは、現在、Oracle Cloud実装では使用できません。

資金取得プロセス・プロファイルには、資金取得プロセスの次の各ステップを制御するルールが含まれます。

メッセージの書式設定決済からの決済バッチの構築支払システムへのメッセージの伝送

199

メッセージの書式設定処理タイプが「銀行口座」の場合は、「資金取得プロセス・プロファイルの作成」ページに「検証」セクションが表示されます。処理タイプが「クレジット・カード」の場合は、「検証」セクションのかわりに「承認」セクションが表示されます。いずれの場合も、支払システムにおいて受信するオンライン・メッセージに想定されている書式を選択します。このアウトバウンド書式によって、Oracle Fusion BI Publisherに対して、メッセージをどのように表示するかが指示されます。また、支払システムから受け取るインバウンド応答に想定されている書式も選択します。

「資金取得プロセス・プロファイルの作成」ページの「決済」セクションでは、支払システムによって受け入れられる決済メッセージ・フォーマットを選択できます。決済は、ゲートウェイタイプの支払システムではオンライン、プロセッサタイプの支払システムではバッチになります。オンラインの決済トランザクションは、通常、グループとして伝送されますが、個別トランザクションとして処理されます。また、支払システムから受け取るインバウンド応答に想定されている書式も選択します。

支払システムに連絡して承認を取得するためのフォーマットを選択できます。また、トランザクションが成功したか失敗したかを示す支払システムからの応答を受信するために、他のフォーマットを選択することもできます。支払システムから会社に承認をプッシュすることも、会社が支払システムから承認を取得することもできます。

「資金取得プロセス・プロファイルの作成」ページの「支払人への通知」セクションで、支払人への通知フォーマットと送信方法を選択します。支払人通知は、決済または決済バッチが伝送された後、各支払人に送信されるメッセージです。このメッセージによって、各支払人に、そのクレジット・カードまたは銀行口座に請求する資金取得トランザクションが通知されます。

決済からの決済バッチの構築「資金取得プロセス・プロファイルの作成」ページの「作成ルール」タブで、決済グループ化属性を選択します。特定のグループ化属性が有効になっているとき、Paymentsでは、1つの決済バッチ内のすべての決済の値が、確実に同じになります。様々な属性値を持つ決済によって、一意の値の組合せがあるだけの決済バッチの作成がトリガーされます。たとえば、グループ化ルールとしてビジネス・ユニットを選択した場合は、同じビジネス・ユニットを持つ決済のみが決済バッチにグループ化されます。

また、決済の金額または数によって決済バッチのサイズを制限することもできます。

支払システムへのメッセージの伝送資金取得プロセス・プロファイルは、1つの支払システムおよびその支払システム・アカウントに固有です。「資金取得プロセス・プロファイルの作成」ページの「アカウント」タブで、資金取得プロセス・プロファイルで使用する支払システム・アカウントを指定します。有効にする各支払システム・アカウントに対して、最大3つ(それぞれ、承認または検証、決済、確認用)の伝送構成を選択します。支払システム・アカウントによって支払システムへの支払が識別され、伝送構成によって、支払システムにトランザクションを伝送する方法がPaymentsに通知されます。

関連トピック

支払システム・アカウント伝送構成

200

決済グループ化ルールの例精算グループ化は、「資金取得プロセス・プロファイルの作成」ページの「精算グループ化ルール」セクションで1つ以上のチェック・ボックスを選択して構成します。決済グループ化属性の選択によって、当該プロファイルの使用時に、同じ属性を持つ決済を一意の決済バッチに含めることが指定されます。次の各シナリオは、精算グループ化ルール・オプションを使用して、特定の資金取得プロセス・プロファイルによって精算を精算バッチにグループ化する方法を示しています。

資金取得プロセス・プロファイル1この例の資金取得プロセス・プロファイル1では、次の精算グループ化オプションが選択されています。

ビジネス・ユニット第一者法的エンティティ決済日

決済バッチの作成資金取得トランザクションの処理中に、「精算バッチの作成」プログラムによって次の表にある精算が選択されます。

決済 金額

外部支払人

トランザクションを所有するビジネス・ユニット

トランザクションを所有する第一者法的エンティティ 決済日

A 1000USD

顧客1 カリフォルニア 北米 2012年2月1日

B 250USD

顧客2 カリフォルニア 北米 2012年2月1日

C 500USD

顧客3 オレゴン 北米 2012年2月1日

D 750USD

顧客4 カリフォルニア 北米 2012年3月1日

次に、「精算バッチの作成」プログラムは、次の精算バッチに精算をグループ化します。

決済バッチ1精算バッチ1には、精算AおよびBが含まれます(どちらの精算にも次のように同じ精算グループ化属性が含まれるため)。

ビジネス・ユニット = カリフォルニア第一者法的エンティティ = 北米決済日 = 2012年2月1日

201

決済バッチ2精算バッチ2には、精算Cが含まれます(次の精算グループ化属性が含まれるため)。

ビジネス・ユニット = オレゴン第一者法的エンティティ = 北米決済日 = 2012年2月1日

決済バッチ3精算バッチ3には、精算Dが含まれます(次の精算グループ化属性が含まれるため)。

ビジネス・ユニット = カリフォルニア第一者法的エンティティ = 北米決済日 = 2012年3月1日

ルーティング・ルールルーティング・ルールによって、資金取得トランザクションが正しい支払システム・アカウントにルーティングされます。ルーティング・ルールでは、トランザクションの属性に基づいて、使用する資金取得プロセス・プロファイルが決定されます。たとえば、Oracle Fusion Paymentsでは、支払方法、ビジネス・ユニット、金額、通貨などのトランザクションの属性が、ルーティング・ルールの条件に対して比較されます。すべての条件が満たされると、指定された支払システム・アカウントおよび資金取得プロセス・プロファイルがトランザクションに使用されます。資金取得プロセス・プロファイルは、トランザクションの処理方法を定義するために使用されます。

ルーティング・ルールは、内部受取人の設定中に、内部受取人に割り当てます。各受取人に、優先度が付けられたルーティング・ルールを設定できます。優先度が最も高いルーティング・ルールがPaymentsによって最初に評価されます。要求された資金取得トランザクションの値がルーティング・ルールの条件と一致する場合、そのトランザクションは、処理のために、該当する支払システム・アカウントにルーティングされます。

「設定および保守」作業領域で、次のものを使用して、ルーティング・ルールを作成します。

オファリング: 財務機能領域: 顧客支払タスク: 内部受取人の管理

「内部受取人の管理」ページで、「受取人」フィールドに受取人を入力し、「検索」をクリックします。「検索結果」セクションで内部受取人を選択し、「ルーティング・ルールの管理」をクリックします。「ルーティング・ルールの管理」ページが表示されます。「ルーティング・ルール」セクションで、「支払方法」選択リストから支払方法を選択し、「作成」をクリックします。「ルーティング・ルールの作成」ページが表示されます。

要求された資金取得トランザクションの属性がルーティング・ルールの条件と一致しない場合、ルーティング・ルールは無視され、次のルーティング・ルールがPaymentsによって評価されます。すべてのルーティン

202

グ・ルールが評価され、該当するものがない場合は、「ルールの設定」ページの「デフォルト・ルーティング」セクションで受取人に対して入力された支払方法タイプに固有の、支払システム・アカウントおよび資金取得プロセス・プロファイルがPaymentsによって検索されます。

承認に使用される支払システム・アカウントおよび資金取得プロセス・プロファイルは、決済や後続の払戻などの追加処理で自動的に使用されます。

Oracle BI Publisher Enterpriseを使用して、フォーマットで使用するためのテンプレートを変更する方法Oracle Fusion Paymentsの各フォーマットは、Business Intelligence Publisher Enterprise (BI PublisherEnterprise)の1つのテンプレートに対応します。Paymentsでは、BI Publisher Enterpriseテンプレートを使用して、金融機関および支払システムのフォーマット要件に従って、資金取得および資金支出トランザクションをフォーマットします。各テンプレートには、データの場所など、規定されたフォーマット属性が含まれています。銀行、支払システムおよび国には、支払ファイルや決済バッチについて、特定の電子フォーマット要件があります。

既存のBI Publisher Enterpriseテンプレートを使用することや、Microsoft Wordなどの標準テキスト・エディタを使用して、最小限の労力でそれらを変更することができます。たとえば、支払システムで支払ファイル・フォーマットの変更が必要になったとき、適切なテンプレートを変更することで迅速に変更できます。

既存のテンプレートを変更するか、新しいものを作成するかに関係なく、新規フォーマットおよび新規支払プロセス・プロファイルも作成するかどうかを決定します。各支払プロセス・プロファイルはフォーマットに関連付けられます。次の表は、2つのテンプレート・シナリオと、その結果として実行する処理を示しています。

処理 シナリオ1 シナリオ2

新規テンプレートを作成するか、既存のテンプレートを変更します。

新規テンプレートを作成します。 既存のテンプレートを変更します。

テンプレートに名前を付けます。 テンプレート名を変更します。 同じ名前を維持します。

新規または変更されたテンプレートの保存場所。

「カスタム」フォルダによって「支払」フォルダ、「会計」フォルダによって「支払」フォルダ。

「カスタム」フォルダによって「支払」フォルダ。

新しいフォーマットを作成します。

はい いいえ

新しい支払プロセス・プロファイルを作成します。

はい いいえ

テンプレートを変更するには、次の方法があります。

該当するテンプレートのコピーをダウンロードします。

203

変更したテンプレートのコピーをアップロードします。

該当するテンプレートのコピーのダウンロード事前定義済テンプレートのコピーをダウンロードするには、次のステップを実行します。

1. Oracle BI Publisher Enterpriseにサインインします。2. 「ホーム」タブで、「カタログ・フォルダ」リンクをクリックします。「カタログ」タブが表示され、フォルダの階層が示されます。

3. 「会計」フォルダを展開します。4. 「支払」フォルダを展開します。5. 変更する事前定義済テンプレート・タイプを見つけ、「詳細」リンクをクリックします。6. メニューから、「カスタマイズ」を選択します。変更対象の事前定義済テンプレート・タイプに関連付けられているすべてのテンプレートが、「カスタム」フォルダによってフォルダにコピーされます。

7. これで、「カスタム」フォルダからファイルをダウンロードして変更したり、ステップ8に進むことができます。

注意: 事前定義済のテンプレートを変更しないでください。新しいパッチまたは新しいリリースを適用すると、事前定義テンプレートに加えた変更が上書きされます。ただし、事前定義済テンプレートをコピーして変更することはできます。

8. 「データ・モデル」タブで、事前定義済テンプレートをコピーしてローカル・ドライブにRTFファイルとして保存するには、該当するテンプレートの「編集」リンクをクリックします。次に、「保存」ボタンをクリックします。

9. テンプレートのコピーを保存する場所にナビゲートし、「保存」ボタンをクリックします。10. 保存されたRTFファイルにナビゲートして開きます。

変更したテンプレートのコピーのアップロード変更されたテンプレートのコピーをアップロードするには、次のステップを実行します。

1. テキスト・エディタを使用して、ローカル・ドライブ上のRTFファイルを変更します。2. 他のフォーマットとして保存し、ファイル名を変更して保存ボタンをクリックし、ファイルを閉じます。

3. 変更したテンプレートのコピーをOracle BI Publisher Enterpriseにアップロードするには、該当するタブにナビゲートし、「新規レイアウトの追加」リンクをクリックします。

4. 「アップロード」アイコンをクリックします。「テンプレート・ファイルのアップロード」ダイアログ・ボックスが表示されます。

5. 「レイアウト名」フィールドに、変更したテンプレートの名前を入力します。6. 「テンプレート・ファイル」フィールドで、ローカル・ドライブ上の変更されたテンプレートの場所を参照し、「開く」ボタンをクリックします。

7. 「タイプ」選択リストから、「RTFテンプレート」を選択します。8. 「ロケール」選択リストから、変更したテンプレートの言語を選択します。9. 「アップロード」ボタンをクリックします。変更されたテンプレートが、該当するタブの「データ・モデル」タブに表示されます。

注意: 変更されたテンプレートは、「カスタム」フォルダの「支払」フォルダにもコピーされま

204

す。

10. 変更されたテンプレートを開くには、「編集」リンクをクリックします。11. 変更されたテンプレートが保存されていることを確認するには、「カタログ」リンクをクリックし

ます。「カタログ」タブが表示され、フォルダの階層が示されます。12. 「カスタム」フォルダ→「会計」フォルダ→「支払」フォルダの順にナビゲートします。13. 「支払」フォルダを選択します。14. 該当するテンプレートについて、「編集」リンクをクリックします。変更されたテンプレートが表

示されます。

資金取得の定義に関するFAQ

支払コードとは何ですか。Oracle Fusion Paymentsを使用すると、金融機関によって要求される支払コードを指定できます。支払コードによって、銀行や支払システムに、規制レポートを目的として、トランザクション処理、銀行手数料または支払事由に関する詳細を提供できます。

支払コード・タイプには、次のものがあります。

銀行指図コード決済チャネル・コード支払事由コード

銀行指図コードとは何ですか。銀行指図コードは、支払ファイル・レベルで銀行または金融機関に渡す必要がある指示を含む値です。支払プロセス・プロファイルには、最大2つの銀行指図を入力できます。その支払プロセス・プロファイルが支払ファイルの作成中に使用される場合は、銀行指図の値が支払ファイルに直接コピーされます。値は、抽出によってフォーマット・プロセスで使用可能になります。支払フォーマットで銀行指図の使用が指定されている場合、値は支払ファイルのヘッダー・レベルで銀行に渡されます。

Oracle Fusion Paymentsには、多数の事前定義された銀行指図コードが用意されています。

決済チャネル・コードとは何ですか。決済チャネルは、受取人への支払方法を銀行に通知する指示です。デフォルトの決済チャネル値は、サプライヤ、サプライヤ住所、サプライヤ・サイトのいずれかで設定できます。Oracle Fusion Payablesの請求書には、これらのうちで最も低いレベルからの値が自動的に移入されます。請求書では、これは賦払とともに表示され、そこで手動で上書きできます。

賦払が支払われると、支払文書の決済チャネルが同じである場合は、買掛/未払金文書から支払に、決済チャネルがコピーされます。プロファイルでグループ化ルールとして決済チャネルを選択した場合は、同じ決済チャネルを共有するすべての文書が、1つの支払にグループ化されます。

205

Oracle Fusion Paymentsには、多数の事前定義された決済チャネル・コードが用意されています。

支払事由コードとは何ですか。支払事由コードは、通常、国の政府または中央銀行によって提供される国固有の識別子です。これらのコードは、支払システムまたは銀行に、規制レポートを目的として、支払の事由に関する追加詳細を提供します。国の支払システムまたは中央銀行によって要求される支払事由コードを入力する目的は、支払の事由を指定することです。

Oracle Fusion Paymentsには、多数の事前定義された支払事由コードが用意されています。

オンライン検証とは何ですか。支払人の銀行口座から資金を取得する前に、オンライン・メッセージを支払システムに送信し、銀行に連絡して支払人の銀行口座が有効であることを検証するように要求できます。口座の資金はこのプロセスでは保留されず、クレジット・カード承認で保留されます。

資金取得プロセス・プロファイルにおけるオンライン検証を有効にするには、検証用のアウトバウンド書式とインバウンド応答書式を選択します。

注意: オンライン支払人の検証はオプションの機能となり、すべての支払システムで提供されるわけではありません。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

206

19c

現預金のための売掛/未収金クレジットの実装

7 支払セキュリティの定義この章の内容は次のとおりです。

システム・セキュリティ・オプション: 重要な選択機密支払情報の暗号化の有効化クレジット・カード・トークン化を有効にする方法インポートされたレガシー・クレジット・カードの処理方法個人を識別可能な情報の削除

システム・セキュリティ・オプション: 重要な選択アプリケーション・セキュリティ・オプションは、組織固有の完全なセキュリティ・ポリシーの一部として、「システム・セキュリティ・オプションの管理」ページで実装できます。セキュリティ・オプションは、クレジット・カードと銀行口座の暗号化およびトークン化と、支払手段マスクに対して設定できます。セキュリティ・オプションは、資金取得プロセスと支出プロセスの両方に使用されます。

注意: クレジット・カード・サービスは、現在、Oracle Financials Cloud実装では使用できません。

注意: Expensesにクレジット・カードをインポートするには、事前に、Paymentsでクレジット・カードの暗号化またはトークン化を有効にする必要があります。

機密データを保護するには、次のセキュリティ質問を考慮してください。

どのようなセキュリティ上の措置を採用しますか。クレジット・カード・データをトークン化しますか。銀行口座データを暗号化しますか。クレジット・カード・データを暗号化しますか。マスター暗号化キーとサブキーはどのような頻度でローテーションしますか。

207

クレジット・カード番号と銀行口座番号をマスクしますか。その場合はどのような方法で行いますか。

「設定および保守」作業領域で、次のものを使用して、アプリケーション・セキュリティのオプションを設定します。

オファリング: 財務機能領域: 支払タスク: システム・セキュリティ・オプションの管理

最適なセキュリティ上の措置支払処理については、次のようにすることが最適なセキュリティ上の措置とみなされています。

クレジット・カード業界データ・セキュリティ基準(PCI DSS)に準拠します。PCI DSSは、ほとんどのタイプのクレジット・カードを処理するために必要となるセキュリティ基準です。

クレジット・カード支払を受け入れるためのすべての要件に準拠します。機密性の高い顧客データが公開されるリスクを最小化します。

マスター暗号化キーを作成します。マスター暗号化キーを定期的にローテーションします。

マスター暗号化キーおよび暗号化の実装プロセスクレジット・カード・データまたは銀行口座データの暗号化を有効にするには、事前に、マスター暗号化キーを自動的に作成する必要があります。マスター暗号化キーはOracle Platform Security Services (OPSS)のファイル・システムに存在します。OPSSによってマスター暗号化キーが格納されます。アプリケーションでは、マスター暗号化キーを使用して機密データを暗号化します。

マスター暗号化キーを自動的に作成することで、それが適切な場所に作成および格納され、必要なすべての権限を持つことが確実になります。

クレジット・カード・トークン化クレジット・カード・データをトークン化する場合は、PCI DSSの要件に準拠します。PCI DSSでは、PCIDSS準拠の支払アプリケーションを企業が使用することを要求します。

トークン化は、クレジット・カード・データなどの機密データを、機密とみなされない一意の番号またはトークンに置き換えるプロセスです。このプロセスでは、機密情報を格納し、アプリケーションおよびデータベース・フィールド内の機密データを置き換えるトークンを生成する、サード・パーティの支払システムを使用しています。暗号化とは異なり、トークンを数学的に戻し処理して実際のクレジット・カード番号を導出することはできません。

「システム・セキュリティ・オプションの管理」ページで「トークン化支払システムの編集」をクリックすることにより、トークン化支払システムを設定できます。次に、クレジット・カード・データのトークン化をアクティブ化するために、「クレジット・カード・データ」セクションの「トークン化」をクリックします。

208

クレジット・カード・データ暗号化クレジット・カード・データを暗号化して、次のものによる、カード所有者のデータ保護の要件の遵守に役立てることができます。

クレジット・カード業界(PCI)データ・セキュリティ基準VisaのPCIベースのCardholder Information Security Program (CISP)

Oracle ReceivablesおよびOracle Collectionsで入力されたクレジット・カード番号は自動的に暗号化されます。暗号化は、「システム・セキュリティ・オプションの管理」ページで指定した、クレジット・カード暗号化設定に基づきます。

注意: インポート経由でPaymentsにカード番号を取り込む場合は、その直後に「クレジット・カード・データの暗号化」プログラムを実行することをお薦めします。

銀行口座データ暗号化サプライヤおよび顧客の銀行口座番号を暗号化できます。

銀行口座暗号化は、当方銀行口座番号に影響を及ぼしません。当方銀行口座は、Oracle Cash Managementで設定されます。これらは、Oracle Payablesでは支出銀行口座として、Receivablesでは送金先銀行口座として使用されます。

Oracleアプリケーションで入力されたサプライヤ、顧客および従業員の銀行口座番号は、自動的に暗号化されます。暗号化は、「システム・セキュリティ・オプションの管理」ページで指定した、銀行口座暗号化設定に基づきます。

注意: インポート経由でPaymentsに銀行口座番号を取り込む場合は、その直後に「銀行口座データの暗号化」プログラムを実行することをお薦めします。

マスター暗号化キーとサブキー循環支払手段の暗号化のために、Paymentsによってチェーン・キー・アプローチが使用されます。チェーン・キー・アプローチはデータ・セキュリティに使用され、ここではAがBを暗号化し、BがCを暗号化するという方式が使用されます。Paymentsでは、マスター暗号化キーによってサブキーが暗号化され、サブキーによって支払手段データが暗号化されます。このアプローチを使用すると、マスター暗号化キーのローテーションが簡単になります。

マスター暗号化キーはOPSSに格納されます。OPSSでは、暗号化されたフォーマットでデータを格納します。マスター暗号化キーはローテーションまたは生成でき、これによりサブキーも暗号化されますが、銀行口座番号は再度暗号化されません。

インストール環境に既存のマスター暗号化キーがある場合は、「ローテーション」をクリックすることで、新しいものを自動的に生成できます。

注意: 支払手段データを保護するには、マスター暗号化キーを年に1回にローテーションするか、会社のセキュリティ・ポリシーに従ってローテーションすることをお薦めします。

209

また、新しいサブキーが自動的に生成される頻度が、使用状況と最大日数のどちらに基づくようにするかを選択することもできます。サブキー循環ポリシーを指定するには、「サブキー循環ポリシーの編集」をクリックします。

注意: 支払手段データを保護するには、定期的なサブキー循環をスケジュールすることをお薦めします。

クレジット・カード・データおよび銀行口座データ暗号化のセキュリティ・アーキテクチャは、次のコンポーネントで構成されています。

OPSS支払マスター暗号化キー支払サブキー機密データの暗号化と格納

次の図は、OPSSリポジトリ、マスター暗号化キーおよびサブキーのセキュリティ・アーキテクチャを示しています。

クレジット・カードおよび銀行口座番号のマスクPaymentsは、顧客およびサプライヤ情報の支払データ・リポジトリとして機能します。Paymentsには、顧客およびサプライヤの支払情報と、クレジット・カードや銀行口座などの支払手段がすべて格納されます。Paymentsでは、銀行口座番号のマスクを可能にすることによって、データ・セキュリティを提供します。

「システム・セキュリティ・オプションの管理」ページで、クレジット・カード番号および外部銀行口座番号をマスクできます。これを行うには、マスクおよび表示する桁数を選択します。たとえば、銀行口座番号XXXX8012では最後の4桁が表示され、残りすべてがマスクされています。これらの設定では、複数のアプリケーションのユーザー・インタフェースでの支払手段番号のマスキングを指定します。

210

機密支払情報の暗号化の有効化財務トランザクションには機密情報が含まれ、そのような情報はセキュアな暗号化モードで保護される必要があります。クレジット・カードおよび外部銀行口座情報を保護するために、暗号化を有効にできます。暗号化によって機密データがエンコードされ、読取りやコピーができなくなります。暗号化を有効にするには、マスター暗号化キーを作成する必要があります。Oracle Platform Security Servicesは、マスター暗号化キーが格納されるリポジトリです。アプリケーションでは、マスター暗号化キーを使用して機密データを暗号化します。

注意: Expensesにクレジット・カードをインポートするには、事前に、Paymentsでクレジット・カードの暗号化またはトークン化を有効にする必要があります。Expenses以外の場所でクレジット・カード・データを使用する場合は、Paymentsでトークン化を有効にする必要があります。

クレジット・カードまたは銀行口座データを保護するには、次のステップを実行します。

1. 「設定および保守」作業領域で、次の項目に移動します。オファリング: 財務機能領域: 支払タスク: システム・セキュリティ・オプションの管理

2. 「システム・セキュリティ・オプションの管理」ページで、「クイック・デフォルトの適用」をクリックします。

3. 次のすべてのチェック・ボックスを選択します。Walletファイルおよびマスター暗号化キーの自動作成クレジット・カード・データの暗号化銀行口座データの暗号化

4. 「保存してクローズ」をクリックします。

クレジット・カード・トークン化を有効にする方法クレジット・カード・トークン化は、機密データを、機密とみなされない一意のサロゲート番号またはトークンに置き換えるプロセスです。このプロセスでは、機密情報を格納し、アプリケーションおよびデータベース・フィールド内の機密データを置き換えるトークンを生成する、サード・パーティのトークン・サービス・プロバイダのサービスを採用しています。

注意: クレジット・カード・サービスは、現在、Oracle Financials Cloud実装では使用できません。

注意: Expensesにクレジット・カードをインポートするには、事前に、Paymentsでクレジット・カードの暗号化またはトークン化を有効にする必要があります。

クレジット・カード・トークン化を有効にするには、次の設定ページでステップを実行します。

211

「システム・セキュリティ・オプションの管理」ページ「支払システムの作成」ページ

システム・セキュリティ・オプションの管理「システム・セキュリティ・オプションの管理」ページでクレジット・カード・トークン化を有効にするには、「トークン化支払システムの編集」をクリックします。トークン化支払システムとして、CyberSourceを選択します。これで、「トークン化」セクションで、読取り専用のトークン化支払システムとしてCyberSourceを表示できるようになりました。

支払システムの作成「支払システムの作成」ページでクレジット・カード・トークン化を有効にするには、次のステップに従います。

1. 「トークン化支払システム設定」サブセクションで、「クレジット・カード・トークン化」チェック・ボックスを選択します。

2. 「トークン化支払システム設定」セクションで、次のフィールドに関連する値を入力します。名前コードデータ型保護: 「はい」または「いいえ」を指定します。値

注意: トークン化設定は、CyberSource支払システムに対してすでに事前定義されています。値を入力することのみが必要です。

インポートされたレガシー・クレジット・カードの処理方法レガシー・クレジット・カードのインポート・プロセスを使用して、レガシー・ソースおよび外部ソースから、フラット・ファイルベースのバッチのインタフェースを介して、トークン化されたレガシー・クレジット・カード・データをOracle Payments Cloudにインポートします。スプレッドシート・テンプレートをダウンロードして、レガシー・クレジット・カード・データを入力できます。スプレッドシート・テンプレートには、作業を簡易化するための支援として、フィールドレベルのバブル・ヘルプが用意されています。

注意: 監査からOracle Applications Cloudを保護するPCI (クレジット・カード業界)のルールに対する厳格なコンプライアンスを維持するために、レガシー・クレジット・カード番号をPaymentsにインポートする前に、それらがトークン化されていることを確認する必要があります。

この図は、レガシー・クレジット・カード・データをアプリケーションにインポートし、エラーを修正するフローを示しています。

212

IbyLegacyCreditCardsImportTemplate.xlsmスプレッドシート・テンプレートにアクセスするには、次のステップを実行します。

1. Oracle Financials Cloudのファイルベース・データ・インポートのガイドに移動します。2. 目次で、「ファイルベース・データ・インポート」リンクをクリックします。3. レガシー・クレジット・カードのインポート・リンクをクリックします。4. 「ファイル・リンク」セクションで、Excelテンプレートへのリンクをクリックします。

レガシー・クレジット・カード・データをインポートするには、事前に、次のステップを実行する必要があります。

1. Paymentsでトークン化を有効にします。2. 少なくとも1つの支払システムを、トークン化を有効にして構成します。トークン化サービス・プロバイダはCyberSourceです。

3. レガシー・クレジット・カードのインポート・プログラムを有効にする、ORA_IBY_DTK_RUN参照

213

を構成します。4. CyberSourceのバッチ・ファイル・アップロード・プロセスを使用して、レガシー・クレジット・カード・データをトークン化します。

スプレッドシート・テンプレートでデータを準備する際は、次のガイドラインに従ってください。

各列の必須情報を入力してください。想定されるデータ型や詳細なインストラクションは、各列ヘッダーのツールチップを参照してください。スプレッドシート・テンプレート内の列の順序を変更しないでください。列の順序を変更すると、アップロード・プロセスが失敗します。使用しない列は非表示にしたりスキップできますが、削除しないでください。列を削除すると、アップロード・プロセスは失敗します。

レガシー・クレジット・カードのインポート・プロセスに影響をするスプレッドシート・タブ次の表に、レガシー・クレジット・カードのインポートのスプレッドシート・テンプレートのスプレッドシート・タブの名前と、その内容の簡単な説明を示します。

スプレッドシートのタブ 説明

インストラクションおよびCSV生成 プロセスの概要CSV生成ボタン改訂履歴

トークン化されたクレジット・カードの詳細 トークン化されたカードの詳細を入力するための列見出し

レガシー・クレジット・カードのインポートの処理方法次の表は、トークン化されたレガシー・クレジット・カードをPaymentsにインポートする場合のデータのフローについて説明しています。

連番 処理 結果

1 Oracle Financials Cloudのファイルベース・データ・インポートのガイドから、IbyLegacyCreditCardsImportTemplate.xlsmという名前のスプレッドシート・テンプレートをダウンロードします。これは、ファイル・ベース・データ・インポートの章の、レガシー・クレジット・カードのインポートの項に示されています。

ファイルベース・データ・インポート用のスプレッドシート・テンプレートがダウンロードされます。

2 1. スプレッドシート・テンプレートにデータを入力します。2. 列のデータ入力の詳細なインストラクション、または列に必要なデータおよびデータ型の説明は、各列ヘッダーのバブル・テキストを参照してください。

3. 大文字のテキストが表示される5番の行は削除しないでください。

4. 各クレジット・カードは、顧客アカウントまたは顧客アカウントのサイト使用レベルで顧客に割り当てられます。

スプレッドシート・テンプレートを使用してCSVファイルを生成できるようになります。

214

3 1. CSVファイルの生成をクリックします。2. 一意の名前を付けてCSVファイルを保存します。

CSVファイルが生成され、ZIPファイルに圧縮されます。

4 ZIPファイルをOracle Universal Content Managementにアップロードする手順は、次のとおりです。

1. 「ツール」→「ファイル・インポートおよびエクスポート」にナビゲートします。

2. 「ファイル・インポート/エクスポート」ページで、プラス(アップロード)アイコンをクリックします。「ファイルのアップロード」ダイアログ・ボックスが表示されます。

3. 「ファイル」フィールドで、ZIPファイルを参照して選択します。

4. 「アカウント」選択リストから、fin/payments/importを選択します。

5. 「保存してクローズ」をクリックします。

ZIPファイルがアップロードされます。

5 レガシー・クレジット・カードのインポート・プロセスを発行する手順は、次のとおりです。

1. 中央のOracle Enterprise Schedulerサーバーにサインインします。

2. 「ツール」→「スケジュール済プロセス」にナビゲートします。

3. 「新規プロセスのスケジュール」をクリックします。新規プロセスのスケジュール・ダイアログ・ボックスが表示されます。

4. 「名前」選択リストから、「クレジット・カード・データのトークン化」を検索して選択します。

5. 「OK」をクリックします。「プロセスの詳細」ダイアログ・ボックスが表示されます。

6. 「クレジット・カード・データ・インポート・ファイル」選択リストから、該当するZIPファイルを選択します。

7. 「送信」をクリックします。

レガシー・クレジット・カードのインポート・プロセスでは、最初に、クレジット・カードと関連データを検証した後、アップロードされたファイルから、次のPayments表にデータをインポートします。

IBY_CREDITCARDIBY_PMT_INSTR_USES_ALL

レガシー・クレジット・カードのインポート・プロセスを発行すると、次のデータがPaymentsに表示されます。

クレジット・カード・データ割当データ

レガシー・クレジット・カードのインポート・プロセスのログ出力には、成功したレコードおよび拒否されたレコードの数がレポートされます。

6 インポート・エラーを修正する手順は、次のとおりです。1. レガシー・クレジット・カードのインポート・プロセスからのログ出力を表示します。

2. ログ・ファイルに記載されている詳細に基づいて、拒否されたレコードを識別します。

3. 古いスプレッドシート・テンプレートからコピーしたレコードのうち、拒否されたレコードのみを含む新しいスプレッドシートを作成します。

4. 元の「サイト目的ソース参照」列に、別の一意の値を入力します。

5. データに必要な修正を加えます。6. 新しいスプレッドシートを使用してデータをロードします。

7. CSVファイルを生成し、ZIPファイルをアップロードして続行します。

失敗したレコードは、レガシー・クレジット・カードのインポート・プロセスからのログ出力に表示されます。修正済のレコードのみが含まれる新しいスプレッドシートがアップロードされ、再び処理されます。

7 レガシー・クレジット・カードのデータに識別子が関連付けられている場合は、データを次のいずれかのレベルでインポートします。

顧客アカウント顧客アカウント・サイト

スプレッドシートで、所有者レベル列がCUST_ACCOUNTの場合、クレジット・カードは顧客アカウント・レベルで割り当てられます。スプレッドシートで、所有者レベル列

215

がCUST_ACCT_SITE_USEの場合、クレジット・カードは顧客アカウント・サイト・レベルで割り当てられます。

関連トピック

支払システムの設定方法支払システムへの通信チャネルの構成方法レガシー顧客クレジット・カード・データのインポート

個人を識別可能な情報の削除一般データ保護規則は、EUおよび欧州経済領域内のすべての個人のデータ保護とプライバシに関する欧州連合(EU)法による規制です。組織は、EU居住者の個人データの収集および使用についてGDPRに準拠できます。

次の場合に、ある個人の個人データを削除できます。

個人が要求した場合個人が組織に勤務しなくなった場合

注意: 個人を識別可能な情報を削除すると、その情報を取得できなくなります。

削除プロセスを実行するには、財務アプリケーション管理者の職務ロールを持っている必要があります。

Oracle Financialsアプリケーションのなんらかの製品に関する、ある個人の個人を識別可能な情報を削除するには、「Financialsアプリケーションからの個人識別可能情報の削除」プロセスを発行します。

1. 「ナビゲータ」→「ツール」→「スケジュール済プロセス」にナビゲートします。2. 「スケジュール済プロセス」ページで、「新規プロセスのスケジュール」をクリックします。3. 「Financialsアプリケーションからの個人識別可能情報の削除」を検索して選択します。4. 「パーティ」選択リストから、個人を識別可能な情報を削除する個人の名前を選択します。5. 「送信」をクリックします。

個人を識別可能な情報を削除する可能性がある表と列の詳細この表は、アプリケーション、および機密データを格納する対応する表と列、各列に格納されているデータ型、列からデータをリダクションできるかどうか、およびリダクションの理由を示しています。

連番と製品 表 列 データ型

1

OraclePayments

IBY_CREDITCARD CC_NUMBER_HASH1 VARCHAR2(64文字)

216

2

OraclePayments

IBY_CREDITCARD CC_NUMBER_HASH2 VARCHAR2(64文字)

3

OraclePayments

IBY_CREDITCARD CCNUMBER VARCHAR2(30文字)

4

OraclePayments

IBY_CREDITCARD CHNAME VARCHAR2(80文字)

5

OraclePayments

IBY_CREDITCARD EXPIRYDATE DATE

6

OraclePayments

IBY_CREDITCARD MASKED_CC_NUMBER VARCHAR2(30文字)

7

OraclePayments

IBY_EXT_BANK_ACCOUNTS BANK_ACCOUNT_NAME VARCHAR2(80文字)

8

OraclePayments

IBY_EXT_BANK_ACCOUNTS BANK_ACCOUNT_NAME_ALT VARCHAR2(320文字)

9

OraclePayments

IBY_EXT_BANK_ACCOUNTS BANK_ACCOUNT_NUM VARCHAR2(100文字)

217

10

OraclePayments

IBY_EXT_BANK_ACCOUNTS BANK_ACCOUNT_NUM_ELECTRONIC VARCHAR2(100文字)

11

OraclePayments

IBY_EXT_BANK_ACCOUNTS BANK_ACCOUNT_NUM_HASH1 VARCHAR2(64文字)

12

OraclePayments

IBY_EXT_BANK_ACCOUNTS BANK_ACCOUNT_NUM_HASH2 VARCHAR2(64文字)

13

OraclePayments

IBY_EXT_BANK_ACCOUNTS IBAN VARCHAR2(50文字)

14

OraclePayments

IBY_EXT_BANK_ACCOUNTS IBAN_HASH1 VARCHAR2(64文字)

15

OraclePayments

IBY_EXT_BANK_ACCOUNTS IBAN_HASH2 VARCHAR2(64文字)

16

OraclePayments

IBY_EXT_BANK_ACCOUNTS MASKED_BANK_ACCOUNT_NUM VARCHAR2(100文字)

17 IBY_EXT_BANK_ACCOUNTS MASKED_IBAN VARCHAR2(50

218

OraclePayments

文字)

18

OraclePayments

IBY_FNDCPT_TX_EXTENSIONS INSTRUMENT_SECURITY_CODE VARCHAR2(10文字)

19

OraclePayments

IBY_TRXN_SUMMARIES_ALL DEBIT_ADVICE_EMAIL VARCHAR2(255文字)

20

OraclePayments

IBY_PAYMENTS_ALL EXT_BANK_ACCOUNT_NAME VARCHAR2(360文字)

21

OraclePayments

IBY_PAYMENTS_ALL EXT_BANK_ACCOUNT_NUMBER VARCHAR2(100文字)

219

22

OraclePayments

IBY_PAYMENTS_ALL EXT_BANK_ACCOUNT_IBAN_NUMBER VARCHAR2(50文字)

23

OraclePayments

IBY_PAYMENTS_ALL PAYEE_NAME VARCHAR2(360文字)

24

OraclePayments

IBY_PAYMENTS_ALL PAYEE_ADDRESS1 VARCHAR2(240文字)

25

OraclePayments

IBY_PAYMENTS_ALL PAYEE_ADDRESS2 VARCHAR2(240文字)

26

OraclePayments

IBY_PAYMENTS_ALL PAYEE_ADDRESS3 VARCHAR2(240文字)

27

OraclePayments

IBY_PAYMENTS_ALL PAYEE_ADDRESS4 VARCHAR2(240文字)

28

OraclePayments

IBY_PAYMENTS_ALL PAYEE_CITY VARCHAR2(60文字)

29

OraclePayments

IBY_PAYMENTS_ALL PAYEE_POSTAL_CODE VARCHAR2(60文字)

30

OraclePayments

IBY_PAYMENTS_ALL PAYEE_STATE VARCHAR2(120文字)

31

OraclePayments

IBY_PAYMENTS_ALL PAYEE_PROVINCE VARCHAR2(120文字)

32

Oracle

IBY_PAYMENTS_ALL PAYEE_COUNTY VARCHAR2(120文字)

220

Payments

33

OraclePayments

IBY_PAYMENTS_ALL PAYEE_COUNTRY VARCHAR2(60文字)

34

OraclePayments

IBY_PAYMENTS_ALL REMIT_ADVICE_EMAIL VARCHAR2(255文字)

35

OraclePayments

IBY_PAYMENTS_ALL PAYEE_PARTY_NAME VARCHAR2(360文字)

36

OraclePayments

IBY_PAYMENTS_ALL PAYEE_LE_REGISTRATION_NUM VARCHAR2 (50文字)

37

OraclePayments

IBY_PAYMENTS_ALL PAYEE_TAX_REGISTRATION_NUM VARCHAR2 (50文字)

38

OraclePayments

IBY_PAYMENTS_ALL PAYEE_ADDRESS_CONCAT VARCHAR2(2000文字)

39

OraclePayments

IBY_PAYMENTS_ALL BENEFICIARY_NAME VARCHAR2 (360文字)

40

OraclePayments

IBY_PAYMENTS_ALL PAYEE_ALTERNATE_NAME VARCHAR2 (360文字)

41

OraclePayments

IBY_PAYMENTS_ALL EXT_BANK_ACCOUNT_ALT_NAME VARCHAR2 (320文字)

42

OraclePayments

IBY_PAYMENTS_ALL EXT_BANK_ACCOUNT_NUM_ELEC VARCHAR2 (100文字)

221

43

OraclePayments

IBY_PAYMENTS_ALL EXT_BANK_ACCT_OWNER_PARTY_NAME VARCHAR2 (360文字)

44

OraclePayments

IBY_EXTERNAL_PAYEES_ALL REMIT_ADVICE_EMAIL VARCHAR2(255文字)

45

OraclePayments

IBY_EXTERNAL_PAYERS_ALL DEBIT_ADVICE_EMAIL VARCHAR2(255文字)

46

OraclePayables

AP_CHECKS_ALL ADDRESS_LINE1 VARCHAR2(240文字)

47

OraclePayables

AP_CHECKS_ALL ADDRESS_LINE2 VARCHAR2(240文字)

48

OraclePayables

AP_CHECKS_ALL ADDRESS_LINE3 VARCHAR2(240文字)

49

OraclePayables

AP_CHECKS_ALL CITY VARCHAR2(60文字)

50

OraclePayables

AP_CHECKS_ALL COUNTRY VARCHAR2(60文字)

51

OraclePayables

AP_CHECKS_ALL ZIP VARCHAR2(60文字)

52

OraclePayables

AP_CHECKS_ALL VENDOR_NAME VARCHAR2(240文字)

222

53

OraclePayables

AP_CHECKS_ALL BANK_ACCOUNT_NUM VARCHAR2(30文字)

54

OraclePayables

AP_CHECKS_ALL ADDRESS_LINE4 VARCHAR2(240文字)

55

OraclePayables

AP_CHECKS_ALL COUNTY VARCHAR2(150文字)

56

OraclePayables

AP_CHECKS_ALL IBAN_NUMBER VARCHAR2(40文字)

57

Oracle CashManagement

CE_PAYEES TAX_REGISTRATION_NUMBER VARCHAR2(20文字)

58

OracleReceivables

AR_CUSTOMER_ALT_NAMES ALT_NAME VARCHAR2(320文字)

59

OracleReceivables

AR_PAYMENT_SCHEDULES_ALL DEL_CONTACT_EMAIL_ADDRESS VARCHAR2(1000文字)

60

OracleReceivables

RA_CUSTOMER_TRX_ALL DEL_CONTACT_EMAIL_ADDRESS VARCHAR2(1000文字)

61

OracleAdvancedCollections

IEX_DUNNINGS CONTACT_DESTINATION VARCHAR2(240文字)

223

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

224

19c

現預金のための売掛/未収金クレジットの実装

8 顧客の定義この章の内容は次のとおりです。

顧客アカウントの定義売掛/未収金顧客プロファイル区分の管理顧客の管理顧客データ・アップロードの管理データ・インポートの管理

顧客アカウントの定義

顧客アカウント関係顧客アカウント関係を使用して、2つのアカウント間での請求サービスと出荷サービスおよび支払活動の共有を管理します。

アカウント関係を使用すると、別のアカウントの出荷または請求書を受け入れることができる顧客アカウントの他に、他のアカウントの未回収借方品目に対して支払を行うことができるアカウントを識別できます。

顧客アカウント関係の使用方法

「アカウントの編集」ページの「関係」タブを使用して、特定の顧客アカウントのアカウント関係を作成および保守します。

顧客アカウント関係は、一方向の関係または相互関係です。デフォルトでは、アカウント関係は一方向です。これは、親アカウントは関連アカウントの未回収借方品目に入金を消し込むことができますが、関連アカウントの入金を親アカウントの未回収借方品目に消し込むことはできないことを意味します。2つのアカウントが相互の未回収借方品目に対して支払を行うことができるようにするには、関係定義の「相互」オプ

225

ションを有効にします。

請求サービスおよび出荷サービスを含む関係については、「請求先」オプションおよび「出荷先」オプションを有効にします。一方向の関係では、親アカウントが請求書を処理し、関連アカウントの出荷を受け入れることができます。相互関係では、一方のアカウントがもう一方のアカウントのこれらのサービスを管理できます。

売掛/未収金システム・オプション「無関連トランザクション支払の許可」を使用すると、顧客アカウント関係の管理に役立ちます。入金消込および請求サービスと出荷サービスの共有を、各顧客アカウントに定義したアカウント関係に制限する場合は、このオプションを有効にしないでください。

売掛/未収金システム・オプション「無関連トランザクション支払の許可」を有効にすると、すべての顧客アカウントが、他の顧客アカウントの未回収借方品目に対して支払を行うことができます。引き続きアカウント関係を使用して、請求サービスおよび出荷サービスを管理できます。

関連トピック

アカウント関係と支払関係の違いは何ですか

顧客アカウント情報顧客アカウント・レコードを使用して、各顧客アカウントに関する詳細情報を保守します。

顧客アカウント情報の入力および更新に関連する次の活動をレビューします。

支払詳細通信情報アカウント関係アカウント・プロファイル

支払詳細

「支払詳細」セクションを使用して、各顧客アカウントで使用するアクティブな入金方法および支払手段を保守します。トランザクションおよび入金の入力中に、Receivablesは、プライマリ入金方法および支払手段をデフォルトとして割り当てます。トランザクション・レベルまたは入金レベルの次のデフォルトは、顧客アカウントに属する別のアクティブな入金方法または支払手段で上書きできます。

入金方法: 各顧客アカウントに自動入金方法および手動入金方法を割り当てます。各入金方法の開始日と終了日は重複できません。

自動入金で使用する自動入金方法を割り当てます。自動入金方法により、自動入金に必要な処理ステップ(確認、送金、消込など)が決まります。手動入金方法を割り当てて、このアカウントに属するトランザクションの支払を収集するために使用する入金フォームを指定します。

支払手段: 各顧客アカウントにクレジット・カードおよび銀行口座を割り当てます。顧客アカウントに対して作成した支払手段情報は、資金取得処理中に使用するために、Oracle Paymentsに格納されます。

自動入金で使用する銀行口座を割り当てます。指定した銀行口座は、自動入金プロセスがこれらの口座から送金銀行口座に資金を振り替える際に使用されます。複数の顧客銀行口座を異なる通貨で定義し、銀行口座を顧客住所に割り当てます。特定の通貨

226

のプライマリ銀行口座は、自動入金処理中にデフォルト口座として使用されます。日付範囲が重複する場合でも、同じ通貨で複数の非プライマリ口座を定義できます。

通信情報

「通信」セクションを使用して、各顧客アカウントの顧客担当者を保守します。各担当者について保守できる情報は、次のとおりです。

名前およびジョブ・タイトル。電話番号、FAX番号、Eメール・アドレス、インスタント・メッセージ・アドレス、URLなどの連絡先。ジョブ職責。住所。担当者に固有の新しい住所を入力するか、顧客アカウントに属するアカウント・サイトの住所を入力できます。

新しい担当者を作成するか、顧客アカウントまたはアカウント・サイトの既存の担当者を追加できます。既存の担当者を追加する場合は、各パーティの顧客レベルでパーティ関係を定義し、そのパーティに「担当者」ロール・タイプを割り当てる必要があります。

アカウント関係

顧客アカウント関係を使用して、2つのアカウント間での請求サービスと出荷サービスおよび支払活動の共有を管理します。

アカウント・プロファイル

アカウント・プロファイルは、指定した期間に顧客アカウントに割り当てられるプロファイル区分レコードです。プロファイル区分レコードを使用して、企業のニーズを反映するカテゴリに顧客アカウントを編成します。同じプロファイル区分を複数の顧客アカウントに割り当てる場合は、特定の顧客アカウントのニーズに従って個々のプロファイルを変更できます。

関連トピック

追加構成および統合

顧客住所のガイドライン売掛/未収金顧客レコードの住所情報を入力および保守します。

顧客を作成する場合は、アカウントおよび住所情報を入力する必要があります。この住所は、顧客のアカウント・サイト・レコードになります。

顧客に追加の顧客アカウントを作成する場合は、新しい住所情報を入力して新しいアカウント・サイトを作成するか、既存のアカウント・サイトを使用できます。既存のアカウント・サイトを新しいアカウントに割り当てる場合、住所情報自体は変更できますが、この住所が他のパーティと共有されていると、警告が表示されます。

次のガイドラインは、顧客住所の入力および更新に適用されます。

アカウント・サイトの参照データ・セット

227

更新の共有アカウント住所詳細住所ビジネス目的参照アカウント

アカウント・サイトの参照データ・セット

顧客を作成またはインポートする前に、顧客アカウント・サイトで使用する参照データ・セットを作成する必要があります。この参照データ・セットは、要件に応じて1つ以上のビジネス・ユニット間で共有できます。

顧客アカウント・サイトの新しい参照データ・セットにアクセスするには、指定されたユーザーに適切なデータ・ロールをプロビジョニングして、特定のビジネス・ユニットおよび参照データ・セットのジョブ・ロールへのアクセス権を付与します。

更新の共有

情報が間違っていたか欠落していたために住所を更新した場合、これらの更新は、この住所を使用するすべてのアカウント・サイトと共有されます。

更新の共有は、住所情報にのみ適用され、アカウント住所詳細またはビジネス目的には適用されません。

アカウント住所詳細

「アカウント住所詳細」サブセクションを使用して、アカウント・サイトの次の値を指定します。

顧客カテゴリ・コード: 企業のニーズに応じてこの顧客を分類する場合に使用します。これらのカテゴリ・コードは、取引先コミュニティ・モデルを使用して定義します。翻訳済顧客名: 別の言語で顧客名を入力する場合に使用します。外部文書の顧客名が翻訳された名前で置換されます。

住所ビジネス目的

住所ビジネス目的をアカウント・サイトに割り当てて、特定の各顧客アカウント・サイトによって実行される機能を識別します。住所ビジネス目的ごとに1つのアカウント・サイトをプライマリとして指定できます。

共通の住所ビジネス目的には、次のものがあります。

請求先: 請求先ビジネス目的は、請求を受け入れて処理するように指定されたアカウント・サイトに割り当てます。顧客のトランザクションを処理するには、少なくとも1つの請求先サイトを作成する必要があります。出荷先: 出荷先ビジネス目的は、顧客アカウントが購入した商品を受け入れるように指定されたアカウント・サイトに割り当てます。出荷先ビジネス目的を作成する場合は、出荷済商品の請求を処理する関連請求先サイトを指定する必要があります。出荷先サイトに関連付けることができる請求先サイトは、同じ顧客アカウントまたは関連顧客アカウントに属します。搬送先: 搬送先ビジネス目的は、出荷先サイトに送付されたすべての商品または一部の商品を受け入

228

れるサイトに割り当てます。船荷証券: 船荷証券ビジネス目的は、顧客の商品を出荷する運送業者の契約を管理するサイトに割り当てます。督促: 督促ビジネス目的は、督促状を受け取るサイトに割り当てます。延滞手数料: 延滞手数料ビジネス目的は、この顧客アカウントの延滞手数料ポリシーが割り当てられているサイトに割り当てます。「使用される取引明細書、督促状および延滞手数料サイト・プロファイル」プロファイル・オプションが「はい」に設定されている場合、Receivablesでは、延滞手数料サイトに割り当てられた延滞手数料ポリシーを使用して、トランザクションの延滞手数料を計算します。プロファイル・オプションが「いいえ」に設定されている場合、Receivablesでは、トランザクションに割り当てられた請求先サイトに割り当てられた延滞手数料ポリシーを使用します。

参照アカウント

収益、運送費、売掛/未収金、自動インボイス決済、税金、未請求売掛金および繰延収益の各勘定の配分を顧客請求先サイトに割り当てます。自動会計が請求先サイトに依存する場合、Receivablesでは、トランザクションの請求先サイトを使用して、これらの配分の関連セグメントを決定します。

関連トピック

参照データ・セット

追加の顧客サイトの表示方法デフォルトでは、「顧客の管理」ページの「サイト」セクションに、選択した顧客アカウントに割り当てられたアカウント・サイトが表示されます。「関連担当者サイトの表示」オプションを有効にすると、「サイト」セクションに追加のサイトが表示される場合があります。

追加のサイトは、パーティのなんらかの処理を通じて、アカウント・サイトとして使用された関連パーティに属することがあります。たとえば、従業員が顧客アカウントの代理として注文しましたが、自分の個人住所を出荷先住所として使用したとします。これにより、アカウント・サイト住所として従業員住所を使用した顧客アカウントのアカウント・サイトが作成されました。

追加のサイトは、顧客アカウントにリンクされている他のシステムの既存のアカウント・サイトなど、データ移行の一部である場合もあります。

売掛/未収金顧客プロファイル区分の管理

顧客プロファイル区分の使用方法プロファイル区分を使用して、企業のニーズを反映するカテゴリに顧客アカウントを編成します。プロファイル区分レコードには、産業、事業所、規模、信用価値、ビジネス量、支払サイクルなどの幅広いカテゴリに顧客をグループ化するために、様々な方法で設定できる汎用オプションが含まれています。

たとえば、顧客の支払行動を反映する3つのプロファイル区分を定義できます。これら3つは、即座に支払う

229

顧客用、支払遅延する顧客用(延滞手数料レートが高い)、大部分を分割で支払う顧客用(期日前支払には割引インセンティブがある)です。

プロファイル区分管理

顧客アカウントを作成した場合、Receivablesでは、プロファイル区分DEFAULTが割り当てられます。「アカウントの編集」ページを使用して、このプロファイル区分を変更するか、顧客アカウントに別のプロファイル区分を割り当てます。

顧客サイトを作成した場合、Receivablesでは、DEFAULTプロファイル区分と顧客アカウントのプロファイル区分のいずれも割り当てられません。かわりに、「サイト・プロファイルの作成」ページを使用して、サイトに最初のプロファイル区分を割り当てる必要があります。「サイトの編集」ページを使用して、既存のプロファイルを更新するか、サイトに新しいプロファイル区分を割り当てます。

顧客アカウントまたはサイトにプロファイル区分を割り当てた後、そのアカウントまたはサイトの特定の要件を満たすようにプロファイル区分の詳細を変更できます。たとえば、特定のサイトが別の通貨で取引を行ったり、そのサイトに追加の延滞手数料または違約金が課される場合があります。これらの更新は、その特定のアカウントまたはサイトにのみ適用され、プロファイル区分レコード自体には影響しません。

プロファイル区分の更新および割当は、有効日範囲を使用して管理されます。割り当てたり更新する各プロファイル区分は、指定された日付範囲内の前のプロファイル区分よりも優先されます。このようにして、顧客の行動または顧客の要件で発生する変更を長期的に管理できます。指定されたトランザクションまたは入金の日付により、活動に適用されるアカウント・プロファイルまたはサイト・プロファイルが決まります。アカウントまたはサイトのプロファイル履歴には、特定のバージョンのプロファイル区分がアクティブになる時期の詳細が示されます。

プロファイル区分の更新方法およびバージョン管理方法既存のプロファイル区分を更新すると、Receivablesによって更新を保存する方法について3つのオプションが提示されます。プロファイル区分レコードのみを更新したり、プロファイル区分レコードの更新に加えて、このレコードを使用するプロファイルを様々な方法で更新することもできます。

プロファイル区分レコードを更新するための3つのオプションは、次のとおりです。

新規プロファイルのみに変更を適用。未修正のプロファイルに変更を適用し、未修正の既存プロファイルをバージョン管理すべてのプロファイルに変更を適用し、すべての既存プロファイルをバージョン管理。

この更新プロセスは、「顧客プロファイル区分更新の伝播」プログラムによって管理されます。

新規プロファイルのみに変更を適用

このオプションは、プロファイル区分レコードのみを更新します。このプロファイル区分を使用するアカウント・プロファイルまたはサイト・プロファイルに更新は適用されません。

このプロファイル区分に加えた変更は、このプロファイル区分が割り当てられた新しいアカウント・プロファイルまたはサイト・プロファイルに適用されます。

未修正のプロファイルに変更を適用し、未修正の既存プロファイルをバージョン管理

230

このオプションは、設定を変更していないプロファイルにバージョン管理を適用します。このオプションの更新プロセスは次のとおりです。

プロファイル区分レコードを更新します。このプロファイル区分を使用する未変更のアカウント・プロファイルおよびサイト・プロファイルに更新を適用します。システム日付を有効開始日として使用して、このプロファイル区分を使用する新しいバージョンのアカウント・プロファイルおよびサイト・プロファイルを作成します。このプロファイル区分を使用する前のバージョンのアカウント・プロファイルおよびサイト・プロファイルに、システム日付より前の日付の有効終了日を割り当てます。この前のバージョンは、その有効日範囲内で有効です。

顧客アカウント・レコードおよびサイト・レコードの「プロファイル履歴」タブを使用して、プロファイルのバージョンを表示します。

すべてのプロファイルに変更を適用し、すべての既存プロファイルをバージョン管理

このオプションは、すべてのプロファイルにバージョン管理を適用します。このオプションの更新プロセスは次のとおりです。

プロファイル区分レコードを更新します。このプロファイル区分を使用するすべてのアカウント・プロファイルおよびサイト・プロファイルに更新を適用します。システム日付を有効開始日として使用して、このプロファイル区分を使用する新しいバージョンのアカウント・プロファイルおよびサイト・プロファイルを作成します。このプロファイル区分を使用する前のバージョンのアカウント・プロファイルおよびサイト・プロファイルに、システム日付より前の日付の有効終了日を割り当てます。この前のバージョンは、その有効日範囲内で有効です。

顧客アカウント・レコードおよびサイト・レコードの「プロファイル履歴」タブを使用して、プロファイルのバージョンを表示します。

与信チェックの顧客プロファイルの設定方法見積-入金プロセスの与信チェック・サービスは、顧客プロファイルまたは顧客アカウント・プロファイルの与信設定に従って、与信承認要求を評価します。

与信承認の決定に使用する設定を使用して、各顧客プロファイルまたは顧客アカウント・プロファイルの「与信および回収」セクションを設定します。

与信承認に使用される設定は次のとおりです。

「与信限度額」フィールド: 顧客または顧客アカウントが指定された通貨で使用できる与信限度額合計を入力します。「許容範囲」フィールド: 顧客が与信限度額を超過できるパーセントを入力します。「換算レート・タイプ」フィールド: トランザクション金額を与信通貨に換算するために使用する換算レート・タイプを入力します。

231

「与信チェックに含める」オプション:このオプションを有効にした場合、適用可能通貨の使用可能貸方が要求金額と比較されます。このオプションを有効にしない場合、顧客または顧客アカウントは与信チェック・プロセスから除外されます。

「失効相殺日数」フィールド: 与信承認の失効日の計算に使用する日数を入力します。

与信承認失効日の導出方法

Receivablesでは、トランザクションの使用可能な日付情報および「失効相殺日数」フィールドの値(存在する場合)に応じて、与信承認の失効日を導出します。

与信承認失効日を導出するロジックは次のとおりです。

「失効相殺日数」フィールドに値がある場合は、次のようになります。履行日/出荷日が指定されている場合: 失効日 = 履行日/出荷日 + 相殺日数。履行日/出荷日が指定されていないが、販売オーダー日が指定されている場合: 失効日 = 販売オーダー日 + 相殺日数。履行日/出荷日および販売オーダー日のいずれも指定されていない場合: 失効日 = 与信承認日 +相殺日数。

「失効相殺日数」フィールドに値がない場合は、次のようになります。履行日/出荷日が指定されている場合: 失効日 = 履行日/出荷日 + 5。履行日/出荷日が指定されていないが、販売オーダー日が指定されている場合: 失効日 = 販売オーダー日 + 5。履行日/出荷日および販売オーダー日のいずれも指定されていない場合: 失効日 = 与信承認日 +5。

売掛/未収金顧客プロファイル区分の管理に関するFAQ

プロファイル区分のデフォルトはいつ使用されますか。

顧客プロファイル区分は、デフォルト設定(「入金別照合」、「自動照合ルール・セット」、「自動消込ルール・セット」、「自動インボイス・グループ・ルール」、支払条件および税印刷オプション)を売掛/未収金の他の部分と共有します。これらの各設定は、トランザクション・プロセスまたは入金プロセスに必要な階層に従って使用されます。

入金処理の場合:

Receivablesは、入金とトランザクションの比較に使用する「入金別照合」の値を、顧客サイト・プロファイル、顧客アカウント・プロファイル、ロックボックス(ロックボックス処理用)、売掛/未収金システム・オプションの順に検索します。Receivablesは、入金の自動消込方法および手動消込を勧告するトランザクションを決定するルール・セットを決定する自動照合ルール・セットを、顧客サイト・プロファイル、顧客アカウント・プロファイル、ロックボックス(ロックボックス処理用)、売掛/未収金システム・オプションの順に検索します。Receivablesが入金をトランザクションと照合できない場合、入金の消込に使用する自動消込ルール・セットを、顧客サイト・プロファイル、顧客アカウント・プロファイルおよび売掛/未収金システム・オプションの順に検索します。

232

トランザクション処理の場合:

自動インボイスのインポート中、Receivablesは、トランザクション明細をトランザクションにグループ化するために使用する自動インボイス・グループ・ルールを、トランザクション・ソース、顧客サイト・プロファイル、顧客アカウント・プロファイルおよび売掛/未収金システム・オプションの順に検索します。Receivablesは、トランザクションで使用する支払条件を、顧客サイト・プロファイル、顧客アカウント・プロファイルおよびトランザクション・タイプの順に検索します。支払条件がサイト・プロファイルまたはアカウント・プロファイルから取得され、「条件上書き」オプションが有効になっている場合は、トランザクションのデフォルト支払条件を更新できます。Receivablesは、トランザクションの税金を印刷するために使用する税印刷オプションを、顧客サイト・プロファイル、顧客アカウント・プロファイルおよび売掛/未収金システム・オプションの順に検索します。値が見つからない場合、Receivablesは、「税額合計のみ」をデフォルト値として使用して、トランザクションを印刷します。

顧客の管理

顧客とパーティ体系顧客を作成して、売上トランザクションを適切に記録および計上するとともに、販売関係の他の属性を識別します。売上トランザクションを記録するには、取引先コミュニティ・モデルにパーティとして格納された顧客に、請求先ビジネス目的のある顧客アカウントと顧客サイトの両方があることが必要です。

取引先コミュニティ・モデルのコンテキストにおける顧客の役割を理解するには、いくつかの関連する概念を理解することが役立ちます。顧客および顧客活動に関連する主な概念は次のとおりです。

パーティ顧客顧客アカウントサイト関係担当者

パーティ

パーティとは、商品売買やサービス提供など、別のパーティとビジネス関係を結ぶことができるエンティティです。パーティは、組織または個人のいずれかです。パーティは、そのパーティと別のパーティとのビジネス関係とは独立して存在します。

顧客

顧客は、販売関係のある、組織または個人であるパーティです。この販売関係は、たとえば、製品およびサービスの購入または将来の購入のベースとなる条件のネゴシエーションの結果として発生する可能性があります。

233

顧客アカウント

顧客アカウントは、パーティが別のパーティと結ぶことができるビジネス関係の属性を表します。顧客アカウントには、パーティとビジネスを行う条件に関する情報が含まれます。

たとえば、内部使用のために会社が行った購買に対する商業アカウントと、エンド・ユーザーに製品を販売するために同じ会社が行った購買に対する再販業者アカウントを作成できます。

1つのパーティに対して複数の顧客アカウントを作成して、様々なカテゴリのビジネス活動に関する情報を保持できます。たとえば、様々なタイプの購買の請求書を追跡するために、事務用品を購入するためのアカウントと、家具を購入するための別のアカウントを保持できます。

また、組織内の複数の事業分野と取引する顧客に対して複数の顧客アカウントを保持することもできます。

プロファイル情報、信用価値、住所、担当者などのパーティに関する情報は、パーティの顧客アカウント全体で共有できます。さらに、顧客アカウントごとに、担当者住所および連絡先とともに個別のプロファイルおよび担当者を保持することもできます。

サイト

サイトとは、空間におけるポイントとなり、住所で表現されます。パーティ・サイトとは、パーティが物理的に存在する場所のことです。

顧客サイトとは、顧客アカウントのコンテキストで使用されるパーティ・サイトです。1つの顧客アカウントが複数のサイトを持つことができます。

顧客住所とは、販売関係の一部である請求、出荷などの目的で使用されるサイトです。識別住所とは、パーティの事業所を識別するパーティ・サイト住所です。各パーティの識別住所は1つのみとなりますが、1つのパーティに複数のパーティ・サイトを設定できます。

関係

パーティ関係とは、そのパーティが別のパーティのコンテキストで果たす役割です。たとえば、関連会社、子会社、パートナ、従業員、担当者などです。

パーティ内の複数の顧客アカウントの間にアカウント関係を設定することで、請求、出荷および支払情報の共有が可能になります。

担当者

担当者とは、パーティまたは顧客アカウントの代理として通信または処理する個人です。担当者は、アカウント・レベルまたはサイト・レベルの顧客に対して存在できます。

通常、個人は組織の担当者としての役割を果たしますが、別の個人の担当者としての役割を果たすこともできます。たとえば、管理アシスタントは、多くの場合、役員の担当者です。

関連トピック

顧客階層と支払関係

パーティ関係の使用方法

234

パーティ関係を使用して、ビジネスを行う方法に従って顧客レコードをモデル化します。パーティ関係は、ビジネスの相手となる顧客についてより深く理解し、意思決定するために役立ちます。

顧客レコードで使用するパーティ関係を定義します。パーティ関係レコードには、顧客に関係するパーティの名前、パーティが顧客に関係する方法(関係ロール)、およびこの特定の関係が存在する期間が含まれます。これらのパーティを、特定の顧客のアカウントまたはアカウント・サイトに属する担当者として追加できます。

パーティ関係は、各エンティティが他のエンティティに対して果たす役割に基づいて、2つのエンティティが相互にやり取りする方法を表します。たとえば、個人と組織の間の雇用関係は、従業員としての個人の役割、および雇用主としての組織の役割によって定義されます。

関係は相互関係を表すことができます。各エンティティは、観点または方向に応じて、サブジェクトまたはオブジェクトのいずれかになります。関係を定義する主体となるパーティがサブジェクトで、関連先とするパーティがオブジェクトです。たとえば、JoeがOracleの従業員である場合、Joeがサブジェクトで、Oracleがオブジェクトです。サブジェクトとオブジェクトが逆になる、Joeの雇用主としてのOracleも同じ関係を表します。

顧客税金プロファイルの使用方法税金プロファイルを使用して、顧客および顧客サイトに関するオプションの税金情報を保守します。OracleTaxを使用して第三者税金プロファイルを作成し、該当する顧客または顧客サイトのこれらの税金プロファイルを更新できます。

Receivablesでは、顧客レコードに属する税金プロファイルは顧客サイト・レコードに移入されません。顧客サイトの要件に応じて、そのサイトごとに個別の税金プロファイルを定義する必要があります。顧客サイト・レベルで定義された税金プロファイル・レコードは、顧客レベルで定義された税金プロファイル・レコードより優先されます。

たとえば、顧客レベルの税金プロファイルに免税が含まれていない場合があります。ただし、関連する顧客サイトの1つが発展途上国または地域に位置する場合があり、そこでは事業の税制上の優遇措置に特定の製品またはサービスに対する免税が含まれます。この場合、この顧客サイトに対して個別の税金プロファイルを定義して保守する必要があります。

関連トピック

パーティ税金プロファイル

顧客のマージ方法データ品質がインストールされている場合、取引先コミュニティ・モデルは重複する顧客レコードおよび冗長な顧客レコードのマージを管理します。

2つの顧客レコードは、「顧客の管理」ページから次のように手動でマージできます。

1. 対象の顧客を検索します。2. 顧客を選択します。3. 「処理」メニューから「レコードのマージ」コマンドを選択して、「マージ」ウィンドウを開きます。

235

4. 「マージ」ウィンドウで、マスター・レコードおよび重複レコードを選択し、マージ要求を完了します。

5. 対象の顧客ごとにステップ2から4を繰り返します。

関連トピック

確認済の重複レコードの統合方法

顧客の管理に関するFAQ

新しい顧客は顧客アカウントに属していますか。

いいえ、顧客個人または顧客組織を作成すると、なんらかの販売関係があるとしてこのパーティが作成されます。また、パーティとの売上トランザクションと、パーティとの販売関係の他の属性の両方を適切に記録および計上するために、顧客レコードの請求先目的を持つ少なくとも1つの顧客アカウントおよび1つの顧客アカウント・サイトを作成する必要があります。

顧客を手動で作成した場合、顧客アカウントにはプロファイルDEFAULTが割り当てられます。顧客をインポートした場合、顧客アカウントに割り当てられるデフォルト・プロファイルはありません。CUST_ORIG_SYSTEM属性およびCUST_ORIG_SYSTEM_REFERENCE属性の情報を指定し、CUST_SITE_ORIG_SYSTEM属性およびCUST_SITE_ORIG_SYS_REF属性を空白のままにして、RA_CUSTOMER_PROFILES_INT_ALL表で顧客アカウント・プロファイルを指定する必要があります。

すでに存在する顧客情報を入力するとどうなりますか。

データ品質がインストールされている場合、取引先コミュニティ・モデルは重複するパーティ情報および冗長なパーティ情報の制御を管理します。

既存の情報に類似または一致するパーティ情報を入力すると、設定に応じて、この情報を管理する様々な方法でプロンプトが表示されます。

これには次のものが含まれます。

データ入力の防止。データ入力の確認の組込み。一致するデータまたは類似するデータの確認と選択。

他の顧客情報を更新するにはどうすればよいですか。

「アカウントの編集」ページを使用して、この顧客に対して作成された顧客アカウントに関連する情報を更新します。

「サイトの編集」ページを使用して、各顧客アカウントに対して作成された顧客サイトに関連する情報を更新します。これには、関連するアカウント・サイトの住所情報および税金プロファイルが含まれます。

顧客データ・アップロードの管理

236

顧客データのインポート方法顧客のインポート・プロセスを使用して、Receivablesおよび取引先コミュニティ・モデルのレジストリに顧客データをアップロードします。顧客データには、関連する顧客属性(顧客プロファイル、顧客支払方法、顧客銀行口座など)に加えて、パーティ、パーティ・サイト、アカウント、アカウント・サイト、サイト使用が含まれます。

顧客インポートFBDIスプレッドシート・テンプレートをダウンロードして、データの準備に使用できます。このテンプレートには、情報の入力作業を支援するインストラクション・シートが含まれています。

注意: 「スプレッドシートから顧客をアップロード」プロセスを使用して、取引先コミュニティ・モデルのレジストリのデータなしで、顧客データのみのアップロードを実行することもできます。「スプレッドシートから顧客をアップロード」プロセスを使用して、顧客、顧客担当者、顧客請求先サイト参照アカウントおよび顧客銀行口座のデータのみをアップロードします。

テンプレートにアクセスするには、次のステップを実行します。

1. Oracle Financials Cloudのファイルベース・データ・インポートのガイドに移動します。2. 目次で、「ファイル・ベース・データ・インポート」をクリックします。3. 顧客のインポートをクリックします。4. 「ファイル・リンク」セクションで、Excelテンプレートへのリンクをクリックします。

ワークシートでデータを準備する際は、次のガイドラインに従ってください。

各列の必須情報を入力してください。詳細なインストラクションは、各列ヘッダーのツールチップを参照してください。テンプレートの列の順序は変更しないでください。使用しない列は非表示にするか、スキップできますが、削除しないでください。

テンプレートが完成したら、「インポートのためのインタフェース・ファイルのロード」プロセスを使用してアップロードします。

1. 「インポート・プロセス」フィールドで、「顧客データのインポート」を選択します。2. 「データ・ファイル」フィールドに、完成したテンプレートを入力します。3. 「インポートのためのインタフェース・ファイルのロード」プロセスにより、テンプレートに含まれる各顧客のデータがアップロードされます。

顧客インポート・テンプレートに影響する設定

顧客インポートFBDIテンプレートには、1つのインストラクション・タブ、および顧客情報のインポートに使用する各インタフェース表用の19のタブがあります。

スプレッドシートのタブ 説明

インストラクションおよびCSV生成

データの準備およびロードとテンプレートのフォーマット、顧客のインポート・プロセスの発行、インポート・エラーの修正に関する情報が含まれています。

顧客のインポート・インタフェース表

該当するタブを使用して、各インタフェース表の顧客データを入力します。これらの表は次のとおりです。

237

HZ_IMP_PARTIES_THZ_IMP_PARTYSITES_THZ_IMP_PARTYSITEUSES_THZ_IMP_ACCOUNTS_THZ_IMP_ACCTSITES_THZ_IMP_ACCTSITEUSES_THZ_IMP_ACCOUNTRELSHZ_IMP_ACCTCONTACTS_THZ_IMP_CONTACTPTS_THZ_IMP_CONTACTROLESHZ_IMP_CONTACTS_THZ_IMP_LOCATIONS_THZ_IMP_RELSHIPS_THZ_IMP_ROLERESPHZ_IMP_CLASSIFICS_THZ_IMP_PERSONLANGRA_CUSTOMER_PROFILES_INT_ALLRA_CUST_PAY_METHOD_INT_ALLRA_CUSTOMER_BANKS_INT_ALL

顧客データの処理方法

インポートされたデータは、対応するReceivablesおよび取引先コミュニティ・モデルの表にロードされます。データを最終的に処理する前に、データをモニターおよびプレビューできます。

売掛/未収金顧客データの場合、各顧客には顧客番号、顧客アカウント番号および顧客サイト番号の一意の組合せが必要です。

スプレッドシートを使用した顧客データのアップロードのガイドライン「スプレッドシートから顧客をアップロード」プロセスを使用して、顧客データを一括でアップロードします。単一のアップロード・プロセスにより、バッチの生成、インタフェース表へのスプレッドシート・テンプレート内の顧客データの転送、およびインタフェース表からOracle Applicationsへのデータのインポートというすべての操作が実行されます。

顧客データの準備に使用する顧客スプレッドシート・テンプレートをダウンロードできます。テンプレートには使用説明シートとサンプル・データが含まれており、顧客情報を入力するプロセスでガイドとして使用できます。

関連する顧客情報の設定

顧客データをアップロードする前に、必要なビジネス・オブジェクトを設定します。

これには次のものが含まれます。

アカウント住所セット: 顧客アカウント・サイトについて必要な参照セットを設定します。顧客プロファイル区分: 顧客レコードについて1つ以上のプロファイル区分を設定します。参照アカウント: 顧客の参照アカウントとして使用する総勘定元帳勘定科目を設定します。

238

顧客銀行口座: 銀行および銀行口座情報を設定します。税金情報: Oracle Taxを使用して税務登録番号および税率コードを設定します。付加フレックスフィールド。

スプレッドシートの列へのデータ入力

「顧客」、「担当者」、「参照アカウント」、「顧客銀行口座」という4つの各ワークシート内の指定された列にデータを入力します。

列へのデータの入力には次のルールが適用されます。

アスタリスク(*)が付いた列ラベルは、必須列を示します。追加の列の表示と非表示を切り替えるには、拡張可能属性の表示ボタンと拡張可能属性の非表示ボタンを使用します。既存の列を移動または削除したり、新しい列を挿入しないでください。正しいフォーマットでデータを入力します。ほとんどの場合、各列では、アップロードの要件に従って、入力したデータがフォーマットされます。顧客ごとに、次の値の一意の組合せが必要です。

顧客番号。顧客アカウント番号。顧客サイト番号。

顧客担当者ごとに、一意の個人番号が必要です。

顧客スプレッドシート・アップロード・データの検証の例アップロードの処理中に、「スプレッドシートから顧客をアップロード」プロセスにより、「顧客」ワークシートと「担当者」ワークシートの特定の列に一意の値があるかどうかが確認されます。値が一意である場合、レコードが作成されます。値が一意でない場合、レコードは失敗し、アップロード・エラーが発生します。

この検証が行われる列は次のとおりです。

「顧客」ワークシート:顧客番号アカウント番号サイト番号

「担当者」ワークシート:個人番号

次の各項では、検証プロセスの例を示します。これらの例は、すべてのレコードのソース・システム値が同じであることを前提としています。

「顧客」ワークシート: 顧客番号の検証

顧客番号の検証では、「顧客番号」、「顧客ソース参照」および「顧客名」の各列を横断して値の一意の組合せが検索されます。

次の表のレコードは、同じ顧客名について、2つの異なる顧客番号と顧客ソース参照があるため、顧客番号

239

の一意性検証に失敗します。

顧客番号 顧客ソース参照 顧客名

VCORP 256113 VCORP 256113 Vision Corporation

VCORP 256114 VCORP 256114 Vision Corporation

次の表のレコードも、顧客番号と顧客ソース参照の同じ組合せについて、2つの異なる顧客名があるため、顧客番号の一意性検証に失敗します。

顧客番号 顧客ソース参照 顧客名

VCORP 256113 VCORP 256113 Vision Corporation

VCORP 256113 VCORP 256113 Vision ABC Corporation

次の表のレコードも、同じ顧客番号について、2つの異なる顧客ソース参照があるため、顧客番号の一意性検証に失敗します。

顧客番号 顧客ソース参照 顧客名

VCORP 256113 VCORP 256113 Vision Corporation

VCORP 256113 VCORP 256114 Vision Corporation

同様に、アカウント番号の検証では、「アカウント番号」、「アカウント・ソース参照」および「アカウント摘要」の各列を横断して値の一意の組合せが検索されます。サイト番号の検証では、「サイト番号」、「サイト・ソース参照」および「サイト名」の各列を横断して値の一意の組合せが検索されます。

「担当者」ワークシート: 個人番号の検証

個人番号の検証では、「個人番号」、「個人ソース参照」、「名」および「姓」の各列を横断して値の一意の組合せが検索されます。

次の表のレコードは、個人番号と個人ソース参照の同じ組合せについて、2つの異なる名と姓の組合せがあるため、個人番号の一意性検証に失敗します。

個人番号 個人ソース参照 名 姓

1000228801 1000228801 Rodney Jones

1000228801 1000228801 John Jones

次の表のレコードも、同じ個人番号について、2つの異なる個人ソース参照があるため、個人番号の一意性検証に失敗します。

個人番号 個人ソース参照 名 姓

1000228801 1000228801 Rodney Jones

1000228801 1000228802 Rodney Jones

240

次の表のレコードは、一意性検証に成功します。検証プロセスでは、同じ名と姓の組合せを持つ2つの異なる個人番号と個人ソース参照の組合せが許可されています。これは、2人の異なる個人の名前が同じである場合があるためです。

個人番号 個人ソース参照 名 姓

1000228801 1000228801 Rodney Jones

1000228802 1000228802 Rodney Jones

顧客リスト・レポート顧客リスト・レポートを使用して、顧客情報をレビューします。既存の顧客情報、手動で入力された顧客情報、「スプレッドシートから顧客をアップロード」プロセスを使用してアップロードされた顧客情報または「データ・インポート」プロセスを使用してインポートされた顧客情報をレビューできます。

顧客レコードには大量の情報が含まれている可能性があるため、事前定義済レポートに存在しない顧客情報をレビューすることや、表示される情報のフィルタリング方法を変えることが必要になる場合があります。Oracle Transactional Business Intelligenceの機能を使用して、ダッシュボード全体またはダッシュボードの個々のレポートをコピーして変更できます。これにより、「売掛/未収金 - 顧客リアルタイム」サブジェクト領域から使用できるレポートに対して、列を置き換えたり追加することができます。

「顧客リアルタイム」サブジェクト領域では、表示のために数多くの追加データ属性を使用でき、この中には、顧客関係、顧客信用価値、優先請求プラクティス、延滞手数料と違約金の計算、支払プリファレンスなどが含まれています。

このレポートは、新しい顧客情報を入力するときや、既存の顧客情報を更新するときに使用します。

選択するレポート・パラメータ

顧客データを選択するには、必須パラメータの少なくとも1つに値を入力します。

顧客の選択を絞り込むには、追加パラメータを使用します。追加パラメータはダッシュボードの各タブで使用でき、顧客担当者、顧客住所、支払情報などのデータのタイプに基づいて、選択したデータを絞り込むことができます。

最終更新日

このパラメータを使用して、アップロードされたデータをレビューします。

顧客アップロードの発行日を入力します。

1つ目のフィールドに発行日を入力し、2つ目のフィールドを空白のままにして、発行日からシステム日付までのすべての顧客データを含めます。両方のフィールドに同じ日付を入力して、特定の日の顧客アップロードの結果を表示します。

ヒント: 1日の終わりにレポートを実行する場合、および1日の間に複数のアップロードがあった場合、レポートにはアップロードされたすべての顧客データが含まれます。データが大量になる場合は、顧客名の範囲などの追加パラメータを使用して、ニーズに従ってデータをフィルタすることが必要になる場合があります。

241

顧客レコードはいつでも手動更新される可能性があるため、顧客アップロードの発行が完了した直後にレポートを実行することをお薦めします。

顧客名

表示する顧客の範囲を入力します。レポートでは、顧客名が取得され、英数字順に表示されます。

1人の顧客のみを表示するには、両方のフィールドに同じ名前を入力します。最初のフィールドにのみ顧客名を入力した場合、レポートには、入力した名で始まるすべての顧客が英数字順で表示されます。

顧客登録ID

表示する顧客の関連パーティ識別子を入力します。たとえば、ある顧客のすべてのアカウントが確実に選択されるようにするために、このパラメータを使用します。場合によっては、顧客名よりも信頼性が高くなります。

顧客区分

1つの分類(商用または政府など)にのみ属する顧客を表示します。

レポート出力

事前定義済レポートには、顧客アップロード・スプレッドシート・テンプレートと類似したフォーマットで顧客情報が表示されます。

次の5つのタブがあります。

顧客の一般情報: 顧客名、顧客区分、顧客プロファイル区分、関連する識別子(顧客登録ID、D-U-N-S、納税者ID、顧客アカウント番号、サイト番号)。顧客住所情報: 各顧客サイトの住所およびすべてのサイト関連情報。顧客担当者情報: 各顧客アカウントの担当者名(完全な担当者詳細を含む)。顧客参照アカウント情報: 各顧客請求先サイトの総勘定元帳参照勘定科目(収益、運送費、売掛/未収金、自動インボイス決算、税金、未請求売掛金および繰延収益)。自動会計が請求先サイトに依存する場合、Receivablesでは、トランザクションの請求先サイトを使用して、トランザクション配分の関連セグメント値を決定します。顧客支払情報: 各顧客アカウントの銀行口座情報。

事前定義済レポートには、担当者や支払情報などの情報がレコードに含まれていない場合でも、顧客アカウント・サイトのすべてのレコードが表示されます。これにより、たとえば、顧客アップロードから欠落している可能性があるデータを識別できます。値のないレコードを表示する必要がない場合は、OracleTransactional Business Intelligenceの標準機能を使用して、必要な情報を含むサイトのみが表示されるように個々のレポートを変更できます。

レポートの情報をPDF、ExcelまたはCSV形式でエクスポートして、オフラインで表示できます。

関連トピック

Receivablesのサブジェクト領域、フォルダおよび属性

242

レガシー顧客クレジット・カード・データのインポートデータ・インポート・プロセスを使用して、レガシー顧客クレジット・カード・データをOracle ApplicationsCloudにインポートできます。

注意: クレジット・カード・サービスは、現在、Oracle Financials Cloud実装では使用できません。

データ・インポート・プロセスには、次のフェーズが含まれています。

CyberSourceへの顧客クレジット・カード・データのアップロードCyberSourceからのトークンのダウンロード簡略化されたスプレッドシートを使用した顧客住所のインポートOracle Applications Cloudへのトークンのアップロード

注意: レガシー顧客クレジット・カード・データをインポートする前に、Oracle Applications Cloudを監査から保護するクレジット・カード業界データ・セキュリティ基準(PCI DSS)ルールに厳密に準拠している必要があります。PCI DSSでは、顧客クレジット・カード情報を処理、格納または伝送するすべての会社にセキュアな環境を維持することを要求しています。顧客クレジット・カード・データは、OracleApplications Cloudデプロイメントのどの部分とも相互作用できません。

前提条件

レガシー顧客クレジット・カード・データをインポートする前に、次のステップを実行する必要があります。

Oracle Payments Cloudをトークン化対応として設定します。少なくとも1つの支払システムをトークン化対応として構成します。トークン化プロバイダを使用して、レガシー顧客クレジット・カード・データをトークン化します。

CyberSourceへの顧客クレジット・カード・データのアップロード

要約: CyberSourceスプレッドシートを取得し、レガシー顧客クレジット・カード・データを使用して完成させ、CyberSourceにアップロードします。

顧客クレジット・カード・データをCyberSourceにアップロードしてトークン番号を生成するには、次のステップを実行します。

1. CyberSource Test Business Center (https://ebctest.cybersource.com/ebctest)にナビゲートします。2. 業者ID、ユーザー名およびパスワードを使用してCyberSourceにサインインします。3. 「Tools & Settings」→「Batch Transactions」→「Templates」にナビゲートして、CyberSourceからスプレッドシートをダウンロードします。「Template」選択リストから、「New subscriptions(Created)」を選択します。

4. スプレッドシートを.csvファイルとしてローカル・ドライブに保存します。5. CyberSourceスプレッドシートを準備します。

a. EditPlusでCyberSourceスプレッドシートを開き、次の必須フィールドに入力します。バッチID: 識別子はそれぞれのバッチで一意である必要があります。取引明細書請求住所カード所有者名: 名および姓

243

実際の顧客クレジット・カード番号カード・ブランド・コード: たとえば、VISAのカード・タイプの値は001です。有効期限カード詳細: 月および年

6. 「Tools & Settings」→「Batch Transactions」→「Upload」にナビゲートして、「Transaction BatchUpload」ページを開きます。

a. バッチに関する参照ノートを入力します。b. バッチのステータスに関する通知を受信するEメール・アドレスを入力します。c. 準備した.csvファイルを参照して選択し、「Submit」をクリックします。すべての検証に合格すると、確認Eメールが送信されます。

CyberSourceからのトークンのダウンロード

トークン化された顧客クレジット・カード・データのスプレッドシートをCyberSourceからダウンロードするには、次のステップを実行します。

1. CyberSourceで、「Reports」→「Report Search」にナビゲートして、「Report Search」ページを開きます。

a. 「Report」選択リストから、名前にバッチIDがあるダウンロードするレポートを選択し、頻度を選択します。

b. 日次レポート検索日が現在の日付であることを確認し、「Submit」をクリックします。「Report Search Results」ページが表示されます。

c. ファイル名oraclepayments<BATCHID>.reply.aa.csvのバッチIDでレポートを検索し、ダウンロード・リンクをクリックして、レポート・スプレッドシートをローカル・ドライブに保存します。

2. ローカル・ドライブのこのスプレッドシートをEditPlusで開きます。スプレッドシートにいくつかの追加フィールドが表示されます。

ヒント: 科学表記法を使用してセルの完全な内容を表示するには、セルを選択してフィールドの完全な値を表示します。

3. 列Cのトークン番号を表示します。トークン番号の例は、paySubscriptionCreateReply_subscriptionID=9903000066742619です。

ヒント: スプレッドシートには、トークン番号を対応する顧客クレジット・カード番号に関連付ける列はありません。

顧客取引明細書請求住所のインポート

要約: 簡略化された顧客インポート・スプレッドシートを取得して完成させ、.csv統合.zipファイルを生成して、Oracle Receivables Cloudにアップロードします。

簡略化された顧客インポート・スプレッドシートを使用して、レガシー顧客クレジット・カード取引明細書請求住所をReceivablesにインポートするには、次のステップを実行します。

1. 簡略化されたスプレッドシートを取得するには、次のステップを実行します。a. Oracle Applications Cloudに売掛管理マネージャとしてサインインします。b. 「設定および保守」作業領域にナビゲートします。c. 「顧客アップロードの管理」タスクを検索して選択します。d. 「検索結果」セクションで、「顧客スプレッドシート・テンプレートのダウンロード」ボタン

244

をクリックして、簡略化されたスプレッドシートをダウンロードします。e. このスプレッドシートをローカル・ドライブに保存します。

2. ローカル・ドライブでこのスプレッドシートを開き、「顧客」タブを選択して、必須フィールドにデータを入力します。

3. 列AYの「目的」に、顧客クレジット・カード取引明細書請求住所としてCC_Billingを入力する必要があります。これらの住所は、最終的には、Oracle Applications Cloudに後でインポートする顧客クレジット・カード・トークン番号に関連付けられます。

4. 「インストラクション」タブを選択し、CSVファイルの生成ボタンをクリックして、1つ以上の.CSVファイルを含む統合.zipファイルとともに個別のスプレッドシートを作成します。

5. 「売掛管理」→「請求」→「請求」作業領域→「タスク」アイコン→「スプレッドシートから顧客をアップロード」リンクにナビゲートして、「顧客アップロードの管理」ページを開きます。

6. 「スプレッドシートから顧客をアップロード」ボタンをクリックして、「スプレッドシートから顧客をアップロード」ダイアログ・ボックスを開きます。

7. バッチ名を入力します。8. ステップ4で生成した.zipファイルを参照し、「発行」をクリックします。

a. 「ナビゲータ」→「顧客データ管理」→「データ・インポート」にナビゲートして、アップロードの進行状況を追跡できます。このプロセスには時間がかかる場合があります。

9. 「顧客アップロードの管理」ページの「検索結果」セクションで、簡略化された顧客インポート・スプレッドシートに緑色のチェック・マークで示された成功ステータスがあることを確認します。

10. 簡略化された顧客インポート・スプレッドシートに移入された顧客データを問い合せて、顧客データがアップロードされたことを確認します。

Oracle Applications Cloudへのトークンのアップロード

要約: トークン化されたスプレッドシートを取得して準備し、Oracle Applications Cloudにアップロードし、クレジット・カードのトークン化プロセスを実行して、トークンがインポートされたことを確認します。

トークン化された顧客クレジット・カード・データをOracle Applications Cloudにアップロードするには、次のステップを実行します。

1. トークン化されたスプレッドシートを準備します。a. https://cloud.oracle.com/homeで、Oracle Financials Cloudドキュメンテーションにナビゲートして、最新リリースのブック・リンクをクリックします。開発カテゴリで、Financials Cloudのファイルベース・データ・インポートのリンクをクリックします。

b. 「ファイルベース・データ・インポート」の章を開き、レガシー・クレジット・カード・トークン・インポートのリンクをクリックします。

c. LegacyCreditCardTokenImportTemplate.xlsmのリンクをクリックし、このスプレッドシートをローカル・ドライブにダウンロードします。

d. ローカル・ドライブから、EditPlusでスプレッドシート・ファイルを開くことで、科学表記法ではなく完全なトークン番号を表示できます。

e. 次の列の値を入力します。i. 列Aは元のソース・システムです。列Aのソース・システムに顧客インポート・スプレッドシートにあるソース・システムの値を入力します。

ii. 列Bはトークン番号です。CyberSourceからダウンロードしたトークン化されたスプレッドシートの列Cにあるクレジット・カードに対して作成されたトークン番号を入力します。

iii. 列Cは元のサイト目的ソース参照です。このスプレッドシート・ファイルの一意の参照番

245

号を入力します。iv. 列Dは有効期限です。クレジット・カードが失効する年と月を入力します。v. 列Eはカード・ブランドです。たとえば、大文字で、VISA、MASTERCARD、DISCOVER、AMEX、DINERS、JCB、ENROUTEまたはCARTEと入力します。

vi. 列Fは所有者の元システム参照です。サイト・レベルでトークンを割り当てる場合は、列AXの「サイト目的ソース参照」に顧客インポート・スプレッドシートにある値を入力し、アカウント・レベルでトークンを割り当てる場合は、列Jの「アカウント・ソース参照」に顧客インポート・スプレッドシートにある値を入力します。

vii. 列Gは摘要です。フリー・テキストを入力します。viii. 列Hは購買カードです。「いいえ」の場合はN、「はい」の場合はYを入力します。ix. 列Iは購買カード・サブタイプです。このフィールドは空のままにするか、値を入力します。B (ビジネス・カード)、C (コーポレート・カード)、P (購買カード)またはU (不明)などの値を入力します。値は、タイプがIBY_PURCHASECARD_SUBTYPEの標準参照値と一致する必要があります。

x. 列Jは所有者レベルです。サイト・レベルでトークン番号を割り当てる場合はCUST_ACCT_SITE_USEを入力し、アカウント・レベルでトークン番号を割り当てる場合はCUST_ACCT_USEを入力します。

xi. 列Kはマスク済クレジット・カード番号です。一連のXの後に、実際のクレジット・カードの最後の4桁を入力します。たとえば、クレジット・カード番号が16桁の場合は、12個のXの後にスペースを入れずに4桁を入力します。

xii. 列Lはカード所有者名です。カード所有者の名と姓を入力します。xiii. 列Mは請求住所です。このシートの元の「サイト目的ソース参照」列と同じ請求住所参

照を入力します。f. データを入力し終わったら、スプレッドシートのインストラクションおよびCSV生成タブのCSVファイルの生成ボタンをクリックします。

g. .csvファイルを一意の名前でローカル・ドライブに保存します。2. トークン化されたスプレッドシートをアップロードします。

a. Oracle Applications Cloudに実装者としてサインインします。b. 「ナビゲータ」→「ツール」→「ファイル・インポート/エクスポート」にナビゲートして、「ファイル・インポート/エクスポート」ページを開きます。

c. 「検索結果」セクションで「アップロード」(+)アイコンをクリックし、「ファイルのアップロード」ダイアログ・ボックスを開きます。

d. ローカルに保存した.csvファイルを参照して選択します。e. 「アカウント」選択リストから「fin/payments/import」を選択し、「保存してクローズ」をクリックします。保存された.csvファイルが「検索結果」セクションに表示されます。

3. クレジット・カードのトークン化プロセスを実行します。a. 「ナビゲータ」→「ツール」→「スケジュール済プロセス」にナビゲートします。b. 「新規プロセスのスケジュール」ボタンをクリックして、「新規プロセスのスケジュール」ダイアログ・ボックスを開きます。

c. 「名前」選択リストで、クレジット・カードのトークン化プロセスを検索して選択し、「OK」をクリックして「プロセス詳細」ページを開きます。

d. 「クレジット・カード・データ・インポート・ファイル」選択リストから、アップロードした.csvファイルを選択し、「発行」をクリックします。

246

e. 「スケジュール済プロセス」ページの「検索結果」セクションで、「リフレッシュ」アイコンをクリックします。出力とともに、発行されたプロセスのステータスが表示されます。

f. 「添付」リンクをクリックして、「添付」ダイアログ・ボックスを開きます。g. プロセスに関連付けられた.txtリンクをクリックして、.txtファイルを開きます。トークン化されたスプレッドシートに入力した一意のオリジナル・システム参照番号を表示できます。これは、トークン化されたスプレッドシートがアップロードされたことを示します。

4. トークンのインポートを検証します。a. Receivablesに売掛管理マネージャとしてサインインします。b. 「売掛管理」→「売掛管理」にナビゲートして、「売掛管理」作業領域を開きます。c. 「タスク」アイコンを選択し、「顧客の管理」リンクをクリックして「顧客の管理」ページを開きます。

d. 「組織名」フィールドに、目的の組織を入力して「検索」をクリックします。e. 「検索結果」セクションまでページを下にスクロールして、顧客を選択します。f. 「サイト」表でサイト番号を探してクリックし、「サイトの編集」ページを開きます。g. 「支払詳細」タブをクリックします。h. 「支払手段」セクションの「クレジット・カード」タブで、クレジット・カード番号の最後の4桁を確認できます。

関連トピック

クレジット・カード・トークン化を有効にする方法

顧客データ・アップロードの管理に関するFAQ

顧客スプレッドシートをアップロードできないのはなぜですか。

すべての.csvファイルを含む.zipファイルのみアップロードできます。個々の.csvファイルまたは完成した.xlsmファイル・テンプレート自体は選択できません。

顧客アップロード・バッチにエラーがあるのはなぜですか。

無効なデータまたは重複レコードが原因です。

無効なデータには、欠落している情報や間違ったフォーマットの情報が含まれます。一部の情報は、「顧客データの修正」スプレッドシートで直接修正できます。無効なデータが顧客プロファイル区分、支払方法、参照アカウントまたは顧客銀行口座に関連している場合は、新しいスプレッドシートのアップロードを使用して正しいデータをインポートする必要があります。

既存のレコードの重複を避けるには、「顧客」ワークシートの各顧客が次の値の一意の組合せを持つようにします。

顧客番号顧客アカウント番号顧客サイト番号

「担当者」ワークシートの各担当者には、必ず一意の個人番号を割り当ててください。

247

データ・インポートの管理

顧客およびコンシューマのデータ・インポートファイルベース・インポート・プロセスを使用して、CSVファイルまたはXMLファイルからデータをインポートできます。「データ・インポート」ダッシュボードを使用して、インポート・ジョブをモニターし、レポートおよび統計を表示します。

ファイル・インポート・バッチを一時停止し、「データ・インポート」作業領域を使用してバッチのデータ品質サービスを構成できます。HZ_IMP_PAUSE_FILE_IMPORTプロファイル・オプションが「はい」に設定されている場合、インポート・アクティビティを一時停止できます。プロファイル・オプションが「はい」に設定されている場合、発行されたすべてのインポート・アクティビティが管理者レビューに送信され、データ・インポート・バッチの概要ページに表示されます。

データを登録にインポートする前に、データ品質サービスを使用するかどうか、使用する場合は次のデータ品質サービスをどのように構成するかを決定する必要があります。

バッチ重複除去登録重複除去「登録にインポート」オプション

バッチ重複除去

バッチ重複除去を使用すると、インポートしているバッチ内の重複を識別して解決できます。

バッチ重複除去を定義するには、次のことを行う必要があります。

各エンティティの重複を識別するために使用する照合構成ルールを選択します。バッチ内の重複レコードに対して実行する処理を指定します。これらの処理は、データが登録にインポートされるときに実行されます。

登録重複除去

登録重複除去では、バッチ重複除去と同様、データが登録にインポートされる前に、バッチ内のデータとレジストリ内のデータの間の重複が識別されます。バッチ重複除去と同様、登録重複除去では、照合構成を選択して重複レコードの処理を指定します。

「登録にインポート」オプション

「登録にインポート」のオプションは、次のことを定義するために使用します。

インポート・プロセス・モード: インポート・プロセスをプレビュー・モードで実行したり、データをプレビューせずに直接データを登録にロードすることができます。プレビュー・モードでは、データが実際にインポートされる前に、バッチ・データ内の重複数、間違っている住所、更新されるレコード数、作成されるレコード数などの情報をレビューできます。バッチをレビューした後、バッチをインポートするか、照合構成ルールおよび処理を修正してからバッチを再実行して、データを再度レビューできます。

248

住所のクレンジング: インタフェース表の住所を登録にインポートする前に検証できます。住所は、住所を検証し、間違っている場合に修正する、統合サード・パーティ・サービスを使用して検証されます。地理検証: HZ_IMP_DEFAULT_GEO_VALID_ADDRESSプロファイル・オプションを「はい」に設定することで、データ・インポートの地理検証を構成できます。これにより、インポート・バッチ内の住所を登録にインポートする前に地理データに対して検証されます。地理検証では、各国の地理的住所検証設定を使用して、有効な住所のみをインポートします。

注意: このプロファイル・オプションの設定に関係なく、すべてのインポート済住所に対して地理名参照が実行されます。

エラー処理の限度: プロセスが自動的に停止されるまでに、インポート・バッチ・プロセスによって発生が許容されるエラー数を定義できます。

顧客およびコンシューマのデータ・インポート・バッチの例この例では、データ・インポート・バッチを作成し、インポートを完了する前にデータで使用するインポート・プロセスのデータ品質サービスを定義する方法を示します。

注意: インポートが完了すると、データが登録にロードされます。

顧客およびコンシューマ・データをインポートする手順は、次のとおりです。

顧客およびコンシューマ・オブジェクトを含むデータ・インポート・バッチを作成します。インポート・データをインタフェース表にロードします。重複除去のためにデータ・インポート・プロセスを構成します。バッチをプレビュー・モードで実行し、すべての重複データが削除されたことを確認してからバッチを発行します。

データ・インポート・バッチの作成

顧客およびコンシューマのデータ・インポート・バッチを作成する手順は、次のとおりです。1. 「請求」作業領域で、「顧客: データ・インポートの管理」をクリックします。2. 「データ・インポート・バッチの管理」ページで、プラス(+)アイコンをクリックします。3. 「データ・インポート・バッチの作成」ウィンドウで、次の表に示すようにフィールドに入力します。

フィールド 値

バッチ名 顧客のインポート・バッチ

ソース・システム カンマ区切りの値

オブジェクト 顧客およびコンシューマ

見積レコード数 300

バッチ摘要 顧客データのインポート

4. 「保存してクローズ」をクリックします。「データ・インポート・バッチの管理」ページに、新しいバッチとバッチIDが表示されます。

249

5. インポート・バッチを作成したら、FBDIテンプレートを使用してデータをインタフェース表にロードします。

インポート・データのロード

データをインタフェース表にロードする手順は、次のとおりです。1. 顧客データを含むFBDIスプレッドシートを準備します。2. 「パーティ」タブで、作成したバッチのバッチIDを「バッチ識別子」列に入力します。3. .zipファイルを生成し、次のいずれかの方法を使用してデータをアップロードします。

「インポートのためのインタフェース・ファイルのロード」プロセスを実行します。ERP統合サービスを使用します。

4. 次の項のステップに従って、インポート・バッチを実行します。

データ・インポート・プロセスの定義: バッチ重複除去

バッチ内に住所、組織、および個人の重複があるかを確認し、これらの重複をバッチからすべて削除する必要があります。

1. FBDIテンプレートを使用してインタフェース表に顧客データがアップロードされていることを確認します。

2. 「データ・インポート・バッチの管理」ページで、目的のバッチの行を選択します。3. 「処理」メニューから「インポート」を選択します。4. 「インポートの定義: バッチ重複除去」ページで、「インポートの前にバッチ内で重複をチェック」オプションを有効にします。

5. 次の表に示すように、「インポート・バッチ内の重複を判断するために構成の照合を選択」セクションのフィールドに入力します。

フィールド 値

住所 住所重複識別

組織 アカウント重複識別

個人 担当者重複識別

6. 次の表に示すように、「デフォルト処理の上書き」セクションのフィールドに入力します。

フィールド 値

個人および組織の処理の選択 すべての重複を削除

住所の処理の選択 すべての重複を削除

7. 「次」をクリックします。

データ・インポート・プロセスの定義: 登録重複除去

インポート・バッチと登録の間で、住所、組織および個人の重複をチェックして、重複レコードがインポートされないようにします。

1. 「インポートの定義: 登録重複除去」ページで、「インポートの前にインポート・バッチと登録間で

250

重複をチェック」オプションを有効にします。2. 次の表に示すように、「インポート・バッチと登録間の重複を判断するために構成の照合を選択」セクションのフィールドに入力します。

フィールド 値

住所 住所重複識別

組織 アカウント重複識別

個人 担当者重複識別

3. 次の表に示すように、「デフォルト処理の上書き」セクションのフィールドに入力します。

フィールド 値

個人および組織の処理の選択 重複レコードをインポートしない

住所の処理の選択 重複レコードをインポートしない

4. 「次」をクリックします。

データ・インポート・プロセスの定義: 登録にインポート

前処理後にデータをレビューするために、バッチをプレビュー・モードで表示できるように、データ・インポート・プロセスを構成できます。インポートの前に住所をクレンジングし、バッチのエラー限度を指定します。また、インポート・バッチのすべての住所を地理データに対して検証します。これにより、すべての受信される住所が「地理の管理」タスクの地理構造および検証レベル設定に従って検証されます。検証中にエラーとレポートされた住所はインポートされません。

1. 「インポートの定義: 登録にインポート」ページで、「バッチをプレビュー・モードで実行」ラジオ・ボタンをクリックします。

2. 「インポートの前に住所をクレンジング」オプションを有効にします。3. 「住所をマスター参照地理に対して検証」オプションを有効にします。4. 「エラー限度」フィールドに200と入力します。5. 「送信」をクリックします。

リソースおよびパートナのデータ・インポートファイルベース・インポート・プロセスを使用して、CSVファイルまたはXMLファイルからデータをインポートできます。「データ・インポート」ダッシュボードを使用して、インポート・ジョブをモニターし、レポートおよび統計を表示できます。

ファイル・インポート・バッチを一時停止し、「データ・インポート」作業領域を使用してバッチのデータ品質サービスを構成できます。HZ_IMP_PAUSE_FILE_IMPORTプロファイル・オプションが「はい」に設定されている場合、インポート・アクティビティを一時停止できます。プロファイル・オプションが「はい」に設定されている場合、発行されたすべてのインポート・アクティビティが管理者レビューに送信され、データ・インポート・バッチの概要ページに表示されます。

インポート・プロセスを定義する際、インポート・プロセスをプレビュー・モードで実行するか、データをプレビューせずに直接登録にロードするかを決定します。また、インポート前に住所をクレンジングし、イ

251

ンポート・バッチ内の住所を地理データに対して検証し、バッチのエラー限度を定義することもできます。

インポート・プロセス・モード

インポート・バッチをプレビュー・モードで実行するか、データを登録に直接ロードします。プレビュー・モードでは、バッチ内の重複のレベルや間違っている住所に関する情報をレビューできます。また、各エンティティに対して作成または更新されるレコード数もレビューできます。その後、バッチをインポートするか、照合構成ルールを更新してバッチを再発行できます。

「登録にインポート」オプション

「登録にインポート」オプションを使用して、次のことを実行できます。

住所のクレンジング: インタフェース表の住所を登録にインポートする前に検証できます。住所は、住所を検証し、間違っている場合に修正する、統合サード・パーティ・サービスを使用して検証されます。地理検証の定義: インポート・バッチ内の住所を登録にインポートする前に地理データに対して検証できます。エラー処理限度の構成: プロセスが自動的に停止されるまでに、インポート・バッチ・プロセスによって発生が許容されるエラー数を定義できます。

地理検証HZ_IMP_DEFAULT_GEO_VALID_ADDRESSプロファイル・オプションを「はい」に設定することで、データ・インポートの地理検証を構成できます。これにより、インポート・バッチ内の住所を登録にインポートする前に地理データに対して検証されます。地理検証では、各国の地理的住所検証設定を使用します。検証エラーの住所はインポートされません。

注意: このプロファイル・オプションの設定に関係なく、すべてのインポート済住所に対して地理名参照が実行されます。

エラー処理限度

プロセスが自動的に停止されるまでに、インポート・バッチ・プロセスによって発生が許容されるエラー数を定義できます。レビューできるよう、エラー・レポートが生成されます。

リソースおよびパートナのデータ・インポート・バッチの例この例では、データ・インポート・バッチを作成し、インポートを完了する前にデータで使用するデータ品質住所クレンジング・サービスをアクティブ化する方法を示します。

注意: インポートが完了すると、データが登録にロードされます。

リソースおよびパートナ・データをインポートする手順は、次のとおりです。

リソースおよびパートナ・オブジェクトを含むデータ・インポート・バッチを作成します。インポート・データをインタフェース表にロードします。バッチをプレビュー・モードで実行し、住所クレンジング結果を確認してからバッチを発行します。

252

データ・インポート・バッチの作成

リソースおよびパートナのデータ・インポート・バッチを作成する手順は、次のとおりです。

1. 「請求」作業領域で、「顧客: データ・インポートの管理」をクリックします。2. 「データ・インポート・バッチの管理」ページで、プラス(+)アイコンをクリックします。3. 「データ・インポート・バッチの作成」ウィンドウで、次の表に示すようにフィールドに入力します。

フィールド 値

バッチ名 顧客のインポート・バッチ

ソース・システム カンマ区切りの値

オブジェクト 顧客およびコンシューマ

見積レコード数 300

バッチ摘要 顧客データのインポート

4. 「保存してクローズ」をクリックします。「データ・インポート・バッチの管理」ページに、新しいバッチとバッチIDが表示されます。

5. インポート・バッチを作成したら、FBDIテンプレートを使用してデータをインタフェース表にロードします。

インポート・データのロード

データをインタフェース表にロードする手順は、次のとおりです。1. 顧客データを含むFBDIスプレッドシートを準備します。2. 「パーティ」タブで、作成したバッチのバッチIDを「バッチ識別子」列に入力します。3. .zipファイルを生成し、次のいずれかの方法を使用してデータをアップロードします。

「インポートのためのインタフェース・ファイルのロード」プロセスを実行します。ERP統合サービスを使用します。

4. 次の項のステップに従って、インポート・バッチを実行します。

データ・インポート・プロセスの定義: 登録にインポート

「登録にインポート」ページで次の内容を構成できます。

バッチをプレビュー・モードで実行するかどうかを選択します。住所クレンジングを構成します。地理検証を定義します。これにより、すべての受信される住所が「地理の管理」タスクの地理構造および検証レベル設定に従って検証されます。検証中にエラーとレポートされた住所はインポートされません。エラー限度を指定します。

前処理後にデータをレビューするために、バッチをプレビュー・モードで表示できるように、データ・インポート・プロセスを構成できます。インポートの前に住所をクレンジングし、バッチのエラー限度を指定します。また、インポート・バッチのすべての住所を地理データに対して検証します。

253

登録インポート・オプションを構成する手順は、次のとおりです。

1. FBDIテンプレートを使用してインタフェース表に顧客データがアップロードされていることを確認します。

2. 「データ・インポート・バッチの管理」ページで、目的のバッチの行を選択します。3. 「処理」メニューから「インポート」を選択します。4. ナビゲーション・トレインで「登録にインポート」をクリックします。5. 「インポートの定義: 登録にインポート」ページで、「バッチをプレビュー・モードで実行」ラジオ・ボタンをクリックします。

6. 「インポートの前に住所をクレンジング」オプションを有効にします。7. 「住所をマスター参照地理に対して検証」オプションを有効にします。8. 「エラー限度」フィールドに200と入力します。9. 「送信」をクリックします。

データ・インポート・バッチでのWhat-If分析の例この例では、処理されてステータスが「インポート前処理の完了」で完了したデータ・インポート・バッチに対してWhat-If分析を実行する方法を示します。照合構成が再定義され、インポート・プロセスが再発行されます。その後バッチ重複除去処理が修正され、バッチのインポートが完了します。

次の表に、このシナリオの主な決定がまとめます。

検討事項 この例の場合

バッチ重複除去の照合構成を再定義しますか。

はい、組織エンティティに対して異なる照合構成が選択されています。

登録重複除去の照合構成を再定義しますか。

はい、個人エンティティに対して異なる照合構成が選択されています。

個人、組織および住所の重複に対してどのような処理を実行しますか。

「登録重複除去」で、「個人」および「組織」について「重複レコードをインポートしない」を選択します。

「登録重複除去」で、「住所」について「重複レコードのインポート」を選択します。

前提条件

1. データ・インポート・バッチが作成されていること。2. データがインタフェース表にアップロードされていること。3. バッチがインポート済であり、ステータスが「インポート前処理の完了」で完了していること。

What-If分析の表示

1. 「請求」作業領域で、「顧客: データ・インポートの管理」をクリックします。2. 「データ・インポート・バッチの管理」ページで、目的のインポート前処理バッチのバッチIDリンクをクリックします。

3. 「データ・インポート・バッチの編集」ページで、概要およびインポート・プロセスのパフォーマンス情報を確認します。「インポート詳細」ボタンをクリックして、「インポート・プロセス詳

254

細」ページを開きます。4. 「インポート・プロセス詳細」ページで、「バッチ重複除去」タブをクリックします。バッチ重複除去の結果が満足いくものであるかを確認します。

5. 「インポート・プロセス詳細」ページで、「住所クレンジング」タブをクリックします。住所クレンジングの結果が満足いくものであるかを確認します。

6. 「インポート・プロセス詳細」ページで、「登録重複除去」タブをクリックします。登録重複除去の結果が満足いくものであるかを確認します。

照合構成の再定義とインポート・プロセスの再発行

レビュー後、バッチ重複除去および登録重複除去の結果が予想どおりでないと判断しました。照合構成を再定義する必要があります。

1. 「インポート・プロセス詳細」ページおよび「データ・インポート・バッチの編集」ページで、「取消」をクリックします。

2. 「データ・インポート・バッチの管理」ページで、そのバッチの行を選択します。3. 「処理」メニューから「インポート」を選択します。4. 「インポートの定義: バッチ重複除去」ページで、組織エンティティについて別の照合構成を選択します。「登録重複除去」をクリックします。

5. 「インポートの定義: 登録重複除去」ページで、個人エンティティについて別の照合構成を選択します。「登録にインポート」をクリックします。

6. 「インポートの定義: 登録にインポート」ページで、「発行」をクリックします。

What-If分析での重複に対する処理の変更

バッチに対して選択した新しい照合構成について、What-If分析を確認します。

1. 「データ・インポート・バッチの管理」ページで、バッチのバッチIDリンクをクリックします。2. 「データ・インポート・バッチの編集」ページで、概要およびインポート・プロセスのパフォーマンス情報を確認します。「インポート詳細」ボタンをクリックして、「インポート・プロセス詳細」ページを開きます。新規の照合構成の結果は問題ありませんが、重複に対する処理を変更します。

3. 「インポート・プロセス詳細」ページで、「登録重複除去」タブをクリックします。4. 「個人および組織の処理の選択」セクションで、「処理」フィールドから「重複レコードをインポートしない」を選択します。

5. 「住所の処理の選択」セクションで、「処理」フィールドから「重複レコードのインポート」を選択します。

6. 「インポートの完了」をクリックします。

データ品質サービスとデータ・インポートデータ品質サービスによって、登録にインポートされるデータの品質が確保されます。データをデータベースにインポートする前に、これらのサービスをアクティブ化するようにデータ・インポート・プロセスまたはファイル・インポート・プロセスを構成できます。

次のデータ品質サービスを使用できます。

バッチ重複除去: ロードされるデータ内の重複除去を定義できます。

255

登録重複除去: 登録にすでに存在するレコードと、ロードされるデータとの間の重複除去を定義できます。「登録にインポート」オプション: インポート・プロセス・モード、データ・クレンジングおよび地理検証を定義できます。

ファイル・ベース・インポートのデータ品質サービス

ファイル・ベース・インポート・プロセスでは登録重複除去オプションを定義できます。ファイル・ベース・インポート・プロセス中のファイル・ベースのインポート・アクティビティについて、バッチ重複除去および「登録にインポート」オプションなどの他のデータ品質サービスは定義できません。ただし、処理後、データをインポートする前にインポート・アクティビティを一時停止し、管理者レビューのために送信できます。管理者はインポート・プロセスをレビューし、データ品質サービスを構成できます。

HZ_IMP_PAUSE_FILE_IMPORTプロファイル・オプションが「はい」に設定されている場合、インポート・アクティビティが一時停止され、管理者レビューのために送信されます。

データ・インポートのデータ品質サービス

データ・インポートのデータ品質サービスを構成できます。登録重複除去方法とバッチ重複除去方法の両方では、重複および重複解決処理を識別する照合構成を選択します。次のことを指定できます。

インポート・プロセスをプレビュー・モードで実行します。インポート前にデータをクレンジングします。インポート前にデータの地理検証を実行します。

HZ_IMP_DEFAULT_GEO_VALID_ADDRESSプロファイル・オプションを「はい」に設定することで、サイト・レベルでのデータ・インポートの地理検証を構成できます。住所は、各国の地理的住所検証設定に基づき、マスター参照地理データに対して検証されます。検証エラーの住所はインポートされません。

データ・インポートの管理に関するFAQ

インポート・プロセスの詳細を表示できないのはなぜですか。

インポート・プロセス詳細を表示できるのは、バッチをプレビュー・モードで実行し、インポート用にバッチを発行した場合のみです。

バッチを再度インポートできますか。

はい、インポート・プロセスのステータスが「インポート前処理の完了」、「エラーありで完了」、「エラー」または「エラー限度到達時に終了」の場合、検証エラーを修正するためにバッチを再インポートできます。

すでにインポート済のバッチのデータ・インポート・プロセスを再定義して再インポートできますか。

はい。データがまだインタフェース表にあり、バッチのステータスが「インポート前処理の完了」、「エラーありで完了」、「エラー」または「エラー限度到達時に終了」の場合、データ・インポート・プロセスを再定義してバッチを再インポートできます。

256

バッチが正常にインポートされた後は、データがインタフェース表にあっても、バッチを再インポートできません。

インポート前処理時に発生したエラーを表示するにはどうすればよいですか。

「データ・インポート・バッチの管理」ページで、目的のバッチのバッチIDをクリックします。次に、「データ・インポート・バッチの編集」ページの「レポート」ボタンをクリックし、「エラー・レポート」ウィンドウを表示します。

データ・インポート・バッチをパージするとどうなりますか。

バッチ内のすべてのレコードがインポート・インタフェース表から完全に削除されます。バッチが正常にインポートされ、インタフェース表のデータが必要なくなったことを確認するまでバッチをパージしないでください。

インタフェース表をパージすると、インポートのパフォーマンスが向上します。インポート済のデータをアーカイブするには、データをカスタム表のセットにコピーします。

データ・インポート・バッチをパージできないのはなぜですか。

ステータスが「処理中」のデータ・インポート・バッチはパージできません。バッチをパージすると、インタフェース表のバッチ・データがパージされます。バッチがデータをインタフェース表から登録にインポートしている間は、このプロセスを実行できません。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

257

19c

現預金のための売掛/未収金クレジットの実装

9 受取手形の定義この章の内容は次のとおりです。

受取手形に関するシステム・オプションの有効化受取手形作成入金方法の作成受取手形バッチのトランザクションの準備受取手形送金入金方法の作成受取手形の送金銀行口座の作成受取手形の定義に関するFAQ

受取手形に関するシステム・オプションの有効化受取手形トランザクションおよび入金の処理の管理に役立つ、売掛/未収金システム・オプションを有効にします。

受取手形に関連するシステム・オプションは、次のとおりです。

「無関連トランザクション支払の許可」オプション: 未関連顧客のトランザクションを受取手形に消し込む場合は、このオプションを有効にします。このオプションを有効にしない場合は、顧客名宛人およびその関連顧客に属するトランザクションのみを消し込むことができます。「受取手形の使用可能」オプション: 受取手形を使用するには、このオプションを有効にする必要があります。受取手形トランザクション・ソース: デフォルトの受取手形トランザクション・ソースをオプションで選択できます。選択したトランザクション・ソースがすべての受取手形トランザクションにデフォルトで表示されます。このオプションを設定する前に、受取手形トランザクション・ソースを設定しておく必要があります。

258

「償還請求なしの受取手形のファクタリングを許可」オプション: 償還請求権なしのファクタリング受取手形送金を作成する場合は、このオプションを有効にします。このオプションを有効にすると、「受取手形送金バッチ」ページの「償還請求権付きのファクタリング」オプションを無効にすることができます。このオプションを有効にしない場合、「償還請求権付きのファクタリング」オプションは読取り専用で有効になります。

関連トピック

名宛人とは何ですか受取手形のリスク

受取手形作成入金方法の作成「受取手形バッチの作成」プロセスを使用してトランザクションから受取手形を自動的に作成するには、受取手形作成入金方法を作成します。この入金方法では、トランザクション・タイプ、満期日、手形番号に加えて、必要に応じて最小請求額と最大請求額を指定し、トランザクションを受取手形にグループ化する方法を決定します。

受取手形作成入金方法を作成したら、受取手形作成入金方法と、名宛人として定義された支払顧客の両方を、受取手形に対して自動的にバッチ処理するトランザクションに割り当てる必要があります。

新しい受取手形作成入金方法を作成する手順は、次のとおりです。

1. 「入金区分および入金方法の作成」ページにナビゲートします。2. 入金区分に名前を付け、「作成方法」フィールドで「受取手形」を選択します。3. 入金方法を作成します。4. 「受取手形」タブにナビゲートします。5. 該当する場合、「受取手形継承トランザクション番号」オプションを有効にして、トランザクション番号を手形番号として使用します。これは、受取手形に含まれるトランザクションが1つの場合にのみ適用されます。受取手形に複数のトランザクションが含まれる場合は、受取手形トランザクション・ソースの設定に従って手形番号が割り当てられます。

6. 「受取手形数ルール」フィールドで、トランザクションを受取手形にグループ化するために使用するルールを選択します。

a. 顧客毎: 単一の顧客名宛人に属するすべてのトランザクションを1つの受取手形にグループ化します。

b. 顧客支払期日毎: 単一の顧客名宛人に属するトランザクションのうち、支払予定支払期日が同じであるすべてのトランザクションを1つの受取手形にグループ化します。トランザクションで支払条件「即時」が使用されている場合、このトランザクションは、支払期日に関係なく、トランザクション金額に対応できる最初の使用可能な受取手形に含まれます。この場合、有効なグループ化ルールは「顧客毎」と同じです。

c. 請求書毎: 単一のトランザクションのすべての支払予定を1つの受取手形にグループ化します。d. 支払予定毎: トランザクションの支払予定ごとに別個の受取手形を作成します(グループ化なし)。

e. サイト毎: 単一の顧客名宛人サイトのすべてのトランザクションを1つの受取手形にグループ化

259

します。f. サイト支払期日毎: 単一の顧客名宛人サイトのトランザクションのうち、支払予定支払期日が同じであるすべてのトランザクションを1つの受取手形にグループ化します。トランザクションで支払条件「即時」が使用されている場合、このトランザクションは、支払期日に関係なく、トランザクション金額に対応できる最初の使用可能な受取手形に含まれます。この場合、有効なグループ化ルールは「サイト毎」と同じです。

7. 「受取手形満期日ルール」フィールドで、「最早」または「最遅」を選択して、手形に消し込まれるすべてのトランザクションの最早支払期日と最遅支払期日のどちらから受取手形の満期日を導出するかを指定します。

8. この入金方法で使用する受取手形トランザクション・タイプを入力します。トランザクションから作成されるすべての受取手形で、このトランザクション・タイプの設定が使用されます。

9. 「逆算日数」フィールドに、トランザクションを受取手形に消し込むことができるようになる、トランザクション期日までの日数を入力します。

10. 「最小額」フィールドと「最大額」フィールドを使用して、トランザクションから作成される受取手形の最小額と最大額を入力します。

最小額を入力した場合、合計がこの額より大きくないかぎり、該当するトランザクションについて受取手形は作成されません。最大額を入力した場合、受取手形の合計金額がこの額と正確に一致する必要があります。トランザクションを受取手形に消し込んだ後、手形の最大額を超過した一部のトランザクション金額が未消込のままになることがあります。たとえば、最大額が$900の受取手形に$1000の請求書が消し込まれた場合、$100の未回収金額がトランザクションに残ります。

関連トピック

受取手形のトランザクションのバッチ処理に関するガイドライン

受取手形バッチのトランザクションの準備「受取手形バッチの作成」プログラムを使用してトランザクションから受取手形を生成する予定がある場合は、受取手形バッチの対象として適格になるようにトランザクションを準備する必要があります。

受取手形バッチの対象となるトランザクションを準備するには、次に示すそれぞれの作業に関連するタスクをレビューし、必要に応じて実行してください。

顧客の準備受取手形作成入金方法の割当受取手形バッチに適格なトランザクションのレビュー顧客名宛人銀行口座の設定

顧客の準備受取手形トランザクションの顧客を準備します。顧客を名宛人として定義し、該当するトランザクションに名宛人を割り当てる必要があります。

次の2つのタスクを実行します。

260

1. 顧客を名宛人として定義します。顧客アカウント・サイトを受取手形の名宛人サイトとして定義します。受取手形を作成する予定のそれぞれの顧客アカウントについて、名宛人サイトを定義する必要があります。顧客アカウントの該当するアカウント・サイトそれぞれについて、次の操作を行います。

a. 「サイトの編集」ページの「サイト詳細」タブにナビゲートします。b. ビジネス目的「名宛人」を割り当てます。c. 受取手形参照勘定科目として受取手形、未払受取手形、送金済受取手形およびファクタリング受取手形を入力します。

2. 名宛人を支払顧客としてトランザクションに割り当てます。該当するそれぞれのトランザクションに顧客名宛人を支払顧客として割り当てます。トランザクションにおいて商品またはサービスの支払責任を負うパーティである名宛人を支払顧客として指定する必要があります。

受取手形作成入金方法の割当受取手形に消し込むそれぞれのトランザクションに受取手形作成入金方法を割り当てます。受取手形作成入金方法では、トランザクション・タイプ、満期日、受取手形番号、および受取手形ごとの最小請求額と最大請求額を指定し、トランザクションを受取手形にグループ化する方法を決定します。

受取手形作成入金方法は、トランザクションに手動で割り当てることも自動的に割り当てることもできます。

受取手形作成入金方法を自動的に割り当てる手順は、次のとおりです。

1. 顧客名宛人の「アカウントの編集」ページまたは「サイトの編集」ページを開きます。2. 「支払詳細」タブで、1つ以上の受取手形作成入金方法を追加します。3. これらの入金方法のいずれかを「プライマリ」として設定します。手動で入力したトランザクションまたは自動インボイスを使用してインポートしたトランザクションのうち、この顧客名宛人に属するトランザクションにプライマリ入金方法が自動的に割り当てられます。

受取手形作成入金方法を手動で割り当てる手順は、次のとおりです。

1. 「トランザクションの編集」ページでトランザクションを開きます。2. 「支払」タブを開き、目的の入金方法を「入金方法」フィールドで選択します。「入金方法」フィールドの選択リストには、顧客名宛人に割り当てられたすべての入金方法が含まれます。

注意: 受取手形作成入金方法で、「顧客毎」または「顧客支払期日毎」のいずれかの「受取手形数ルール」が使用されている場合、受取手形を自動的に生成するには、さらに、該当する顧客名宛人サイトのプライマリ・ビジネス目的として「名宛人」を設定する必要があります。これは、顧客名宛人が、トランザクションを決定する要素であるためです。

受取手形バッチに適格なトランザクションのレビュー「受取手形バッチの作成」プログラムを実行すると、プログラムの実行について入力したビジネス・ユニットとパラメータ値に該当する顧客名宛人の適格なトランザクションがすべて選択されます。

261

次の表では、受取手形バッチの対象となるトランザクションを選択する際に適用されるルールについて説明します。

機能 ルール

不適格なトランザクション

「受取手形バッチの作成」プログラムを使用して、係争トランザクションまたは他の受取手形を受取手形に割り当てることはできません。

通貨 「通貨」パラメータに値を入力すると、受取手形を作成するために、この通貨のトランザクションのみが選択されます。「通貨」パラメータに値を入力しない場合は、選択されたトランザクションの通貨に応じて、様々な通貨で受取手形が作成されます。このプログラムでは、同じ通貨と換算レートを持つ、適格なすべてのトランザクションから受取手形が生成されます。

デビット・メモとクレジット・メモ

支払条件が「即時」のデビット・メモとクレジット・メモをバッチ処理する場合、これらのデビット・メモとクレジット・メモは、手形に割り当てられた支払期日グループ化ルールに関係なく、使用可能な最初の受取手形に含まれます。

注意: さらに、デビット・メモとクレジット・メモの金額は受取手形の最大額(ある場合)に準拠する必要があります。手形に消し込まれるデビット・メモとクレジット・メモの合計が、手形について指定された最大額を超過すると、手形を適切な額にするために、1つ以上のデビット・メモまたはクレジット・メモが除外されます。

顧客名宛人銀行口座の設定通貨、換算レート、支払顧客銀行口座、および受取手形作成入金方法に割り当てられた設定によって、トランザクションを受取手形にグループ化する方法が決まります。

適格なトランザクションの顧客名宛人銀行口座は、トランザクションを受取手形にグループ化するための追加ルールとして機能します。「受取手形バッチの作成」プログラムでは、同じ顧客名宛人銀行口座を持つトランザクションから個々の受取手形が作成されます。

注意: 顧客名宛人銀行口座は、受取手形に消し込まれるトランザクションと同じ通貨である必要があります。

手動で入力したトランザクションまたは自動インボイスを使用してインポートしたトランザクションに顧客名宛人銀行口座を自動的に割り当てる手順は、次のとおりです。

1. 「サイトの編集」ページの「サイト詳細」タブで、該当するそれぞれの顧客名宛人サイトについて、追加のビジネス目的「請求先」を割り当てます。

2. 「サイトの編集」ページの「支払詳細」タブにある「銀行口座」セクションで、請求先サイトの顧客名宛人銀行口座を入力します。

3. この銀行口座を「プライマリ」として設定します。

次の両方の条件に該当する場合、「受取手形バッチの作成」プログラムによって作成された受取手形にトランザクションの銀行口座が継承されます。

顧客名宛人サイトが請求先サイトでもあります。受取手形作成入金方法で、「顧客毎」または「顧客支払期日毎」のいずれかの「受取手形数ルール」が使用されていません。

262

受取手形作成入金方法の「受取手形数ルール」が「顧客毎」または「顧客支払期日毎」である場合、「受取手形バッチの作成」プログラムによって作成された受取手形にトランザクションの銀行口座が継承されるのは、次の両方の条件に該当するときのみです。

銀行口座が、「プライマリ」としてマークされた顧客名宛人サイトに割り当てられています。プライマリ名宛人サイトが請求先サイトでもあります。

適格なトランザクションの銀行口座がプライマリ名宛人サイトに割り当てられていない場合は、顧客名宛人銀行口座なしで受取手形が作成されます。

関連トピック

トランザクションから受取手形を作成できないのはなぜですか受取手形のトランザクションのバッチ処理に関するガイドライン

受取手形送金入金方法の作成受取手形送金バッチで使用する受取手形送金入金方法を作成します。受取手形送金バッチによって、適格なすべての受取手形が処理され、銀行に送金する準備が整えられます。

受取手形送金入金方法には、「入金区分および入金方法の作成」ページと「入金区分および入金方法の編集」ページにある次の設定が適用されます。

「作成方法」フィールド: 「受取手形送金」を選択します。「送金方法」フィールド: 標準的な受取手形については「標準」を選択し、償還請求権付きまたは償還請求権なしのファクタリング受取手形については「ファクタリング」を選択します。「デビット・メモ継承入金番号」オプション: この入金方法で送金された受取手形に消し込まれる入金のデビット・メモ戻し処理に入金番号を継承する場合は、このオプションを有効にします。「入金継承受取手形番号」オプション: この入金方法で送金された受取手形について作成される入金に手形番号を継承する場合は、このオプションを有効にします。「送金銀行口座」タブ: このタブをクリックして、この入金方法で使用する送金銀行口座を作成します。送金銀行には、送金に使用する銀行口座情報と、送金された受取手形および後続の入金の会計の両方が含まれます。

関連トピック

受取手形送金の概要受取手形送金バッチの作成受取手形送金の入金の作成および決済

受取手形の送金銀行口座の作成

263

受取手形送金入金方法で使用する送金銀行口座を作成します。送金銀行口座によって、受取手形のグループ化および送金の方法が決定され、受取手形トランザクションと入金の両方に関する会計情報が提供されます。

受取手形送金銀行口座には、「送金銀行口座の作成」ページと「送金銀行口座の編集」ページにある次の設定が適用されます。

「プライマリ」オプション: これがこの入金方法のプライマリ銀行口座である場合は、このオプションを有効にします。同じ通貨の送金銀行口座を複数作成する場合は、いずれかの銀行口座を「プライマリ」として設定する必要があります。「銀行の上書き」オプション: 作成後に受取手形送金バッチの送金銀行情報を変更できるようにする場合は、このオプションを有効にします。「決済日数」フィールド:

この入金方法が標準的な送金済受取手形を対象としている場合、銀行が顧客名宛人の入金を決済するために要する日数を入力します。この入金方法が償還請求権付きでファクタリングされた受取手形を対象としている場合、銀行が現金仮払金(短期借入金)の入金を決済するために要する日数を入力します。

「リスク消去日数」フィールド: この入金方法が償還請求権付きでファクタリングされた受取手形を対象としている場合、短期借入金を決済するための満期日以降の日数を入力します。「送金済受取手形」および「ファクタリング受取手形」フィールド: 受取手形トランザクションに使用する送金済受取手形勘定とファクタリング受取手形勘定を入力します。「回収日数」フィールド: この入金方法が標準的な送金済受取手形を対象としている場合、満期日以降に送金された手形の回収に送金銀行が使用する最小日数を入力します。「短期借入金」フィールド: この入金方法でファクタリング受取手形に使用する短期借入金勘定を入力します。

注意: 「ファクタリング」フィールドは受取手形には使用されません。受取手形入金はファクタリングされず、送金済として作成されます。

関連トピック

受取手形送金バッチの作成受取手形送金の入金の作成および決済

受取手形の定義に関するFAQ

顧客名宛人を作成するにはどうすればよいですか。ビジネス目的が「名宛人」の顧客アカウントについて、顧客サイトを少なくとも1つ作成します。受取手形を使用する予定のそれぞれの顧客アカウントについて、顧客名宛人サイトを作成する必要があります。

顧客トランザクションから受取手形を作成する予定がある場合は、さらに、それらのトランザクションの支払顧客として顧客名宛人を割り当てる必要があります。

264

署名済受取手形と未署名受取手形の違いはなんですか。署名済受取手形を完了して送金できるようにするには、顧客名宛人による引受が必要です。

未署名受取手形は、顧客名宛人による引受を必要とせずに開始できます。未署名受取手形自体が、返済の請求に必要な文書になります。

未署名受取手形トランザクション・タイプを作成するには、「署名済」オプションと「名宛人による発行」オプションの両方の選択を解除したままにします。

名宛人によって受取手形が発行されるのはどのような場合ですか。特定の日付に特定の金額を返済するという約束付きの受取手形を顧客名宛人が作成する場合です。これは約束手形とも呼ばれます。約束手形は、通常、その手形を発行する銀行によって保証されます。

受取手形の延滞手数料を提示するにはどうすればよいですか。受取手形の延滞手数料は、デビット・メモまたは請求書としてのみ提示できます。受取手形トランザクションは修正できないため、延滞手数料を修正として提示することはできません。

延滞手数料タイプとして「修正」を選択した場合、受取手形を除くすべての期限超過トランザクションについて延滞手数料が生成されます。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

265

19c

現預金のための売掛/未収金クレジットの実装

10 売掛/未収金の収益管理構成の定義この章の内容は次のとおりです。

収益ポリシーの定義に関するガイドラインイベントベースの収益管理の仕組み偶発収益支払ベースの偶発収益偶発収益削除イベント偶発収益割当ルール売掛/未収金の収益管理構成の定義に関するFAQ

収益ポリシーの定義に関するガイドライン「収益ポリシーの管理」ページを使用して、該当する各ビジネス・ユニットの収益ポリシーを定義します。Receivablesはこの収益ポリシー定義を使用して、手動で入力されたトランザクションとインポートされたトランザクションの収益認識を自動的に決定します。

Receivablesは、収益ポリシーに対して各トランザクションを比較し、ポリシー定義を逸脱しているトランザクションまたはトランザクション明細に偶発収益を割り当てます。

与信分類与信分類を使用して、高リスクで信用度が低い顧客を識別します。最大3つのレベルのリスクを割り当てることができます。Receivablesは、これらのリスク・レベルを顧客プロファイルに割り当てられた与信分類と比較します。

266

収益ポリシー内の与信分類の1つに一致する与信分類を持つ顧客のトランザクションを入力またはインポートすると、Receivablesにより次の処理が行われます。

顧客信用価値の偶発がそのトランザクションに割り当てられます。トランザクション全体の収益が繰り延べられます。トランザクションの収益が、受領した支払の範囲内でのみ認識されます。

払戻ポリシーしきい「払戻ポリシーしきい」列を使用して、顧客に通常提示する標準払戻期間を日数で入力します。

契約に関連付けられた明細を含むトランザクションを入力またはインポートすると、Receivablesによって、その契約詳細が分析されます。契約で提示されている払戻期間が払戻ポリシーを逸脱している場合は、Receivablesによって次の処理が実行されます。

偶発払戻がトランザクション明細に割り当てられます。トランザクション明細の収益が自動的に繰り延べられます。トランザクション明細の払戻期間の失効後に、トランザクション明細の収益が認識されます。

支払条件しきい「支払条件しきい」列を使用して、支払条件を延長する最大期間を日数で入力します。

支払条件ポリシーに違反する支払条件または賦払スケジュールを含むトランザクションを入力またはインポートすると、Receivablesにより次の処理が行われます。

拡張支払条件の偶発がそのトランザクションに割り当てられます。トランザクション全体の収益が繰り延べられます。トランザクションの収益が、受領した支払の範囲内でのみ認識されます。

たとえば、収益ポリシーの支払条件しきいとして180日を入力し、その後、次の4回の賦払を伴う支払条件のある請求書を入力またはインポートしたとします。

ネット60ネット90ネット120ネット200

最後の賦払はしきい180日を20日超えているため、Receivablesは請求書の収益金額を全額繰り延べます。

関連トピック

トランザクションの収益の認識方法支払条件の定義に関するガイドライン

267

イベントベースの収益管理の仕組みReceivablesは、手動入力されたトランザクションおよび自動インボイスを使用してインポートされたトランザクションの両方に対する収益認識のタイミングを自動化します。この自動収益管理プロセスにより、USGAAPおよび国際会計基準で義務付けられた厳密な収益認識要件に準拠できます。

イベントベースの収益管理プロセスでは、各トランザクションが評価され、即時に収益を認識するか、トランザクションに割り当てられた偶発に基づいて一時的に収益を前受収益勘定に繰り延べるかが決定されます。収益は、その後、各偶発に割り当てられた削除イベントに従って認識されます。

注意: 自動収益認識を設定した場合でも、トランザクションの収益の手動修正は可能です。手動で収益を修正すると、Receivablesでは偶発の自動モニタリングが中止されます。

イベントベースの収益管理に影響する設定次の設定はイベントベースの収益管理に影響します。

「営業担当必須」売掛/未収金システム・オプション: 収益認識を使用するには、「営業担当必須」システム・オプションを有効にする必要があります。AR_INTERFACE_CONTS_ALL表: AR_INTERFACE_CONTS_ALL表を使用すると、自動インボイスを使用してトランザクションをインポートする前に、偶発収益IDを請求明細に割り当てることができます。

注意: 親と子のトランザクション明細をインポートすると、自動インボイスによってすべての偶発が親明細から子明細に自動的にコピーされます。

偶発収益: トランザクションに割り当てられた偶発収益およびそれに対応する削除イベントによって、繰延収益とその期間が決まります。収益ポリシー: 収益ポリシーによって、トランザクションへの偶発の割当がトリガーされる場合があります。偶発収益割当ルール: アクティブな偶発収益割当ルールによって、トランザクションへの偶発の割当がトリガーされる場合があります。収益スケジューリング・ルール: トランザクションに収益スケジューリング・ルールが割り当てられている場合、その収益スケジューリング・ルールの詳細およびルール開始日に従って収益が認識されます。

イベントベースの収益管理の計算方法トランザクションの収益を繰り延べて後で認識するためのイベントベースの収益管理プロセスは、次のステップに従って行われます。

1. Receivablesは、手動で入力されたトランザクションまたは自動インボイスを使用してインポートされたトランザクションを収益認識のために評価します。

2. 1つ以上の偶発が存在する場合、Receivablesは対応する収益を前受収益勘定に繰り延べて、繰延の事由を記録します。

3. Receivablesは、偶発収益を削除して収益認識をトリガーできるイベントが発生するまで、偶発をモニターします。

4. 削除イベントが発生すると、Receivablesはトランザクションの適切な前受収益金額を認識します。

268

収益は、収益スケジューリング・ルールまたは最終偶発削除日に従って認識されます。

関連トピック

売掛/未収金システム・オプション設定に関するガイドライン

偶発収益事前定義済の偶発収益を使用して、顧客トランザクションに割り当てることができます。事前定義済の偶発に基づいて独自の偶発を定義でき、また偶発収益割当ルールを定義して、どの偶発をどのトランザクションに割り当てるかを制御することもできます。

この表は、事前定義済の偶発収益およびそれに対応する偶発削除イベントを示しています。

偶発名 偶発削除イベント

取消 偶発の失効日または失効期間

顧客信用価値 入金消込

搬送 搬送証明

不良回収の可能性 入金消込

明示的受入 顧客受入

拡張支払条件 入金消込

喪失 偶発の失効日または失効期間

導入 顧客受入

請求前受入 請求

払戻 偶発の失効日または失効期間

支払ベースの偶発収益支払ベースの偶発収益の収益認識は、オープン・トランザクションに対して行われた支払に依存します。顧客や、支払を受け入れた場合にのみ収益が認識されるようにする特定のトランザクションに対しては、支払ベースの偶発を使用します。

トランザクションまたはトランザクション明細に支払ベースの偶発が含まれる場合、次のルールが適用されます。

Receivablesでは、まず、税金、運送費および延滞手数料を除くすべての明細残高の合計に関して収益を繰り延べます。支払ベースの偶発が1明細にのみ存在し、かつ、次のいずれかの状況に該当する場合、Receivablesで

269

は、関連する明細についてのみ収益を繰り延べます。支払ベースの偶発がデフォルトでトランザクションのすべての明細に割り当てられ、かつ、特定の明細の偶発が手動で失効した場合。支払ベースの偶発が1つ以上の明細に手動で適用された場合。

自動インボイス・インポート中、インポートされたトランザクションに対する入金の全額または一部消込によって、以前の繰延収益の自動認識がトリガーされる場合があります。このような場合、Receivablesでは、消し込まれた入金の金額で、前受収益勘定から該当する実現収益勘定への収益配分が開始されます。支払ベースの偶発を含むトランザクションに入金を消し込む場合、認識される収益合計金額がトランザクションの当初未払金額または消込可能なクレジット・メモを超えることはありません。後で入金の戻し処理が必要になった場合は、Receivablesによって戻し処理済入金の金額が前受収益勘定に自動的に戻されます。

支払ベースの偶発支払ベースの収益管理は、トランザクションに繰延収益が存在するときに、信用価値、拡張支払条件、不良回収の可能性といった偶発収益が原因で発生します。

信用価値: 信用価値がないことを示す与信分類を顧客プロファイルまたはサイト・プロファイルに割り当てることができます。また、そのような与信分類を3つまで収益ポリシーに割り当てることができます。Receivablesがトランザクションの顧客をこのいずれの与信分類にも関連付けることができない場合、その顧客は信用価値があるとみなされます。Receivablesが顧客をこのいずれかの与信分類と関連付けることができる場合、信用価値の偶発がすべてのトランザクション明細に割り当てられ、トランザクション金額全体が繰り延べられます。拡張支払条件: 収益ポリシーに支払条件しきいを定義します。トランザクションの支払条件が定義されたしきい値を超える場合、Receivablesは拡張支払条件の偶発をすべてのトランザクション明細に割り当て、トランザクション金額全体を繰り延べます。不良回収の可能性: 通常、延滞手数料の回収可能性は不確実であるため、支払を受け入れるまでは実現収益とみなさないようにする必要があります。不良回収の可能性についての決定は、通常、自動インボイスによるインポートが発生する前に、フィーダ・システムで行われます。

これらの偶発と時間ベースの偶発の組合せが原因で、繰延収益がトランザクションに存在する可能性があります。そのような場合は、時間ベースの偶発が失効した場合にのみ、消込支払が収益認識を開始します。

次の場合、入金消込は収益認識に影響を与えません。

その他入金を消し込む場合。収益認識の対象となるのは標準入金のみです。手動で繰り延べた収益があるトランザクションに対して入金を消し込む場合。時間ベースの偶発が失効していないために繰り延べられた収益があるトランザクションに対して入金を消し込む場合。この場合、Receivablesによってトランザクションまたはトランザクション明細の収益金額が前受収益勘定で保守されますが、偶発が失効するまで、トランザクションには収益認識保留中のマークが付けられます。

270

偶発収益削除イベントReceivablesのイベントベースの収益管理プロセスでは、偶発収益を含むトランザクションの収益の認識が管理されます。トランザクションに1つ以上の偶発収益が含まれる場合、Receivablesは偶発が失効するまで収益を前受収益勘定に繰り延べます。

収益繰延の程度と後続の収益認識のタイミングは、偶発の種類によって異なります。

時間ベースの偶発の削除および収益認識は、偶発が失効して初めて可能になります。支払ベースの偶発の削除および収益認識は、支払が行われて初めて可能になります。偶発の削除および収益認識は、請求後顧客受入条項の失効(暗黙的受入)または手動での受入(明示的受入)が行われて初めて可能になります。請求前顧客受入条項では、請求のためにReceivablesにインポートする前に、フィーダ・システムに顧客受入を記録するか、またはその条項が失効することが要求されます。偶発を削除し、請求のためにオーダーをReceivablesにインポートするには、顧客受入またはその失効が発生している必要があります。

Receivablesで提供されている偶発には、それぞれ対応する削除イベントがあります。削除イベントによって、トランザクションまたはトランザクション明細から偶発を削除するために必要な処理またはイベントが決まります。

この表は、偶発収益およびそれに対応する削除イベントを示しています。

偶発名 偶発削除イベント

取消 偶発の失効日または失効期間

顧客信用価値 入金消込

搬送 搬送証明

不良回収の可能性(延滞手数料やその他手数料などの条件により発生) 入金消込

明示的受入 顧客受入

拡張支払条件 入金消込

導入 顧客受入

請求前受入 請求

払戻 偶発の失効日または失効期間

偶発収益割当ルール「偶発収益割当ルール」ページを使用して、偶発収益をトランザクションに自動的に割り当てるためのルールを定義します。

偶発収益割当ルールは、次の要素で構成されます。

271

ルール名と摘要(オプション)。トランザクションに割り当てる偶発収益。偶発を割り当てる条件を含む1つ以上のパラメータ。

ルール定義に使用できるルール・パラメータは次のとおりです。

収益スケジューリング・ルールトランザクション・ソース請求先顧客請求先サイト顧客プロファイル区分メモ明細ビジネス・ユニット出荷先顧客出荷先サイトトランザクション・タイプ

異なる一致基準を使用して同じ偶発を戻す複数のルールを定義できます。また、同じ一致基準を使用して複数の偶発を戻す複数のルールを定義することもできます。

割当ルールを作成した後は、ルールをテストして、すべての表現が正確であり、ルールが予想どおりに機能することを確認できます。

シナリオ偶発収益割当ルールを使用すると、企業の実際のニーズを反映する方法で、偶発収益をトランザクションに自動的に割り当てることができます。通常、収益ポリシー設定でサポートされない偶発割当要件をサポートする場合にこれらのルールを使用します。

たとえば、関連するトランザクションの収益を認識するには、その前に、顧客ABCが手動で項目を受け入れることが必要になるようにする必要があるとします。このことを必須のプロセスにする手順は、次のとおりです。

1. 新しい偶発収益割当ルールを作成します。2. このルールに対して明示的受入の偶発収益を選択します。3. ルール・パラメータとして「請求先顧客」を選択します。4. 関連する顧客条件を入力します。

このデフォルト・ルールを設定すると、Receivablesによって顧客ABCのすべてのトランザクション明細に明示的受入の偶発が割り当てられ、顧客が各明細項目の受入を承認するまで、収益が繰り延べられます。

売掛/未収金の収益管理構成の定義に関するFAQ

偶発収益とは何ですか。

272

偶発収益は、収益の即時認識を回避する、販売契約またはビジネス契約内の条件です。この条件は、USGAAPおよび国際会計基準で義務付けられた厳密な収益認識要件に基づいています。

収益認識を遅らせる可能性のある一般的な偶発には、顧客信用価値、非標準支払条件、非標準払戻ポリシーなどがあります。

どのような場合に偶発を含む収益ポリシーを使用しますか。企業の収益ポリシーに基づいて、偶発をトランザクションに割り当てることができます。

次のオプションがあります。

与信分類: 該当する顧客が収益ポリシー内に定義されている与信分類の1つと一致する与信分類を持つ場合、この偶発がトランザクションに割り当てられます。支払条件: 支払条件が収益ポリシーの支払条件しきいを超えた場合、この偶発がトランザクションに割り当てられます。払戻: 収益ポリシーの払戻ポリシーしきいを超える払戻ポリシーがトランザクションに含まれる場合、この偶発がトランザクションに割り当てられます。

収益ポリシーで偶発の詳細を詳細を考慮しない場合は、「なし」を選択します。

どのような場合に偶発収益割当ルールを作成しますか。偶発をトランザクションに自動的に割り当てる場合は、偶発収益割当ルールを作成する必要があります。定義するルールごとに、1つ以上の一致基準を指定します。ルール基準が一致するたびに、Receivablesによって、指定した偶発が該当するトランザクション明細に割り当てられます。

次の2つの場合、偶発収益割当ルールを作成する必要がありません。

収益ポリシーの違反: 収益ポリシーに対する違反が発生するたびに、Receivablesは適切な偶発収益をトランザクションに自動的に割り当てます。繰延収益スケジューリング・ルール: 繰延収益スケジューリング・ルールが割り当てられたトランザクションでは、関連する偶発が失効するか、または収益を手動でスケジュールするまで、すべての収益が繰り延べられます。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

273

19c

現預金のための売掛/未収金クレジットの実装

11 与信管理の定義この章の内容は次のとおりです。

与信プロファイルのコンポーネント与信アナリストと与信マネージャスコアリング・モデルの作成スコアリング・モデル計算の定義方法クレジット事例フォルダ・テンプレートの作成データ・ポイントの要約表の保守方法データ・ポイントのサード・パーティ与信データのインポート方法与信管理データ・ポイントのインポート方法クレジット事例フォルダの付加フレックスフィールド与信管理の定義に関するFAQ

与信プロファイルのコンポーネント顧客および顧客アカウントの与信プロファイルを保守します。

与信プロファイルには、次の目的で使用される設定が含まれます。

顧客の与信枠を作成します。顧客の与信プロファイルの継続的なレビューを提供します。顧客の与信レビュー・プロセスに貢献します。

与信プロファイルは、企業の与信ポリシーや各顧客の信用価値を管理するために不可欠です。

与信プロファイルの定義

274

プロファイル・ページに直接データを入力するか、ファイルベース・データ・インポートの顧客のインポート・テンプレートを使用して、顧客および顧客アカウント・プロファイルの与信関連情報を入力し、アップロードできます。

与信プロファイルは、顧客レベルと顧客アカウント・レベルでのみ定義および保守できます。

顧客(パーティ)レベルで与信専用プロファイルを定義します。顧客与信プロファイルは、会社レベルでの与信レビューを容易にし、会社の全体的な与信状況に寄与します。デフォルトでは、顧客与信プロファイルの設定は顧客のすべてのアカウントに適用されます。ビジネス要件に応じて、個別の顧客アカウント・プロファイルでの顧客与信プロファイルのデフォルト設定を更新できます。アカウント・プロファイル設定の一部として、顧客アカウント・レベルで与信プロファイルを定義します。顧客アカウントの与信プロファイルの設定は、すべての顧客サイトに適用されます。

また、必要な与信設定を使用して顧客プロファイル区分を定義し、顧客または顧客アカウントに個別のプロファイル区分を適用することもできます。

必要な場合は、ビジネス要件に従って、プロファイルの有効終了日を入力し、新規または更新されたプロファイルを顧客または顧客アカウントに適用できます。

与信プロファイル設定次の表は、与信プロファイルの各設定について説明しています。これらの設定の一部は、顧客プロファイルのみ、または顧客アカウント・プロファイルのみで使用されます。

設定 用途

有効開始日/有効終了日

顧客プロファイルがアクティブである日付範囲。新しい有効開始日は、前の有効終了日の翌日に開始します。

与信アナリスト

顧客のクレジット事例フォルダに割り当てられたデフォルトの与信アナリスト。これには、与信承認失敗または定期レビュー・プロセスによって作成された事例フォルダが含まれます。

与信分類 顧客の与信分類。与信分類と事例フォルダ・レビュー・タイプの組合せにより、この顧客のクレジット事例フォルダの作成に使用するクレジット事例フォルダ・テンプレートが決まります。

与信限度額

顧客に割り当てられている、与信通貨での貸方合計金額。「与信チェックに含める」オプションが有効になっており、「許容範囲」値が0で、未処理の貸方残高がこの金額を超える場合、要求された与信承認は失敗します。

オーダー限度額

顧客の個別オーダーの与信通貨での限度額。「与信チェックに含める」オプションが有効になっている場合に個々のトランザクション金額がこの金額を超えると、要求された与信承認は失敗します。

与信通貨 与信限度額値およびオーダー限度額値の通貨。与信通貨は、顧客または顧客アカウントに対して作成されたクレジット事例フォルダ内のすべての金額ベースの値を表示するために使用されます。与信通貨は、顧客トランザクションの通貨である必要はありません。たとえば、ビジネス要件に応じて、特定のグローバル地域または事業部門に属するすべての顧客の与信通貨を定義できます。

許容範囲 顧客または顧客アカウントが与信限度値を超過できる割合。たとえば、「与信チェックに含める」オプションが有効で、「許容範囲」値が10の場合、有効な与信限度は、プロファイルで定義された与信限度額に与信限度額値の10%を加えたものになります。

リスク・ 顧客または顧客アカウントの信用リスクのレベルを識別するコード。「顧客信用リスク」参照タイ

275

コード プを使用して、追加のリスク・コードを定義できます。

信用評価 顧客または顧客アカウントの信用評価。顧客の信用評価参照タイプを使用して、追加の信用評価名を定義できます。

換算レート・タイプ

要求された承認金額の通貨が与信通貨と異なる場合に、クレジット計算で使用する換算レート・タイプ。

失効相殺日数

与信承認が失効するまでの日数。顧客または顧客アカウントのビジネス要件および与信ポリシーに従って数値を入力します。

与信レビュー・サイクル

顧客または顧客アカウントの信用価値の定期的な与信レビューに使用するレビュー・サイクル期間。有効な値は「四半期次」、「半期」、「年次」です。

前回レビュー日

顧客または顧客アカウントの前回与信レビューの日付。この日付は、顧客または顧客アカウントに対してクレジット事例フォルダが手動または自動で作成されるたびに、定期レビュー・プロセスまたは与信チェック失敗によって更新されます。

次回レビュー日

プロファイルに割り当てられた前回レビュー日とレビュー・サイクル期間に基づいた、次の与信レビューのデフォルト日付。「前回レビュー日」の値が更新されると、それに応じて「次回レビュー日」の値が再計算されます。

与信チェックに含める

このオプションはデフォルトで有効になっています。有効な場合、顧客または顧客アカウントに対して与信チェック・サービスが呼び出されたときに与信チェックが実行されます。

与信保留 このオプションはデフォルトで有効になっていません。顧客または顧客アカウントが与信保留になっている場合、与信チェック・サービスは保留を確認するメッセージを返し、使用可能貸方のチェックに進みません。この顧客に対しては、引き続き新規売掛/未収金トランザクションを作成できます。

関連トピック

顧客プロファイル区分の使用方法パーティ階層での与信限度額の導出方法

与信アナリストと与信マネージャ顧客および顧客アカウントに対する与信レビュー・プロセスを操作、保守および管理する与信アナリストおよび与信マネージャとして、ユーザーを指定します。

セキュリティ・コンソールを使用して、ユーザーに与信マネージャ・ロールと権限を割り当て、与信マネージャ・ロールを使用して与信アナリスト・ロールを作成します。

与信マネージャの設定には次のものが含まれます。

ロール・コード: ORA_AR_CREDIT_MANAGER_JOB。機能セキュリティ・ポリシー: ORA_AR_CREDIT_MANAGER_JOB。

与信アナリストの設定には次のものが含まれます。

276

ロール・コード: ユーザー定義。機能セキュリティ・ポリシー: ORA_AR_CREDIT_MANAGER_JOBの機能セキュリティ・ポリシーを開始点として使用して与信アナリスト・ロールを定義し、与信アナリストが必要としない権限(与信レビュー拡張管理権限など)を削除します。

与信アナリスト与信アナリストは、顧客アカウントの信用価値を監視し、与信関連の問題の解決を支援します。

与信プロファイルに入力された与信アナリストには、デフォルトで、このプロファイルが割り当てられた顧客および顧客アカウントのすべての事例フォルダが割り当てられます。与信アナリストには、自分が手動で作成した事例フォルダも割り当てられます。

与信アナリストは自分の事例フォルダを他の与信アナリストに再割当できますが、他のアナリストの事例フォルダを再割当することはできません。

与信マネージャ与信マネージャは、与信アナリストのチームに対して責任を持ちます。

与信マネージャは、自分の顧客と顧客アカウント、およびチームのすべての与信アナリストに割り当てられた顧客と顧客アカウントの事例フォルダと与信レビュー情報にアクセスできます。与信マネージャは、事例フォルダの最終承認に対して責任を持ちます。

与信マネージャは、与信アナリストのすべての職務を実行できます。また、与信マネージャは、与信レビュー拡張管理権限の一部として次のタスクを実行できます。

与信アナリストから別の与信アナリストに事例フォルダを再割当します。チームに属するすべての事例フォルダを承認または否認します。

スコアリング・モデルの作成顧客のクレジット・スコアの計算に使用するスコアリング・モデルを作成します。必要な与信レビューのタイプごとに異なるスコアリング・モデルを作成できます。これにより、顧客および顧客アカウント全体で標準的な一貫性のあるスコアリング・ガイドラインを適用できます。

スコアリング・モデルをクレジット事例フォルダ・テンプレートに割り当てます。与信レビューが開始されて事例フォルダが作成されると、適切なテンプレートおよびスコアリング・モデルが与信レビュー・プロセスの事例フォルダに割り当てられます。

スコアリング・モデルには、特定の与信レビューに適したデータ・ポイントおよびスコアリング方法が含まれます。スコアリング・モデルを作成するとき、データ・ポイントごとに次の操作を行います。

特定のデータ・ポイントに対して定義する必要があるすべての値範囲を入力します。各値範囲にスコアを割り当てます。他のすべてのデータ・ポイントと関連するため、相対重み付け係数をデータ・ポイントに割り当てま

277

す。

与信分析時に、各データ・ポイントの値範囲に割り当てたスコアを使用して、スコアが計算されます。

注意: クレジット・スコアは整数として計算され、小数値の.5以上は切り上げられます。たとえば、70.5は71になり、70.4は70になります。

スコアリング・モデルを作成する手順は、次のとおりです。

1. 「設定および保守」→「クレジット・スコアリング・モデルの管理」ページにナビゲートします。2. プラス(+)アイコンをクリックして「クレジット・スコアリング・モデルの作成」ページを開きます。

3. 「名前」および「摘要」フィールドに、このスコアリング・モデルの名前と説明を入力します。事例フォルダ・テンプレートまたは顧客のサブセットに関連するものとして、スコアリング・モデルのタイプを識別する名前を使用できます。

4. 「開始日」フィールドに、このスコアリング・モデルをアクティブにする日付を入力します。デフォルトはシステム日付ですが、将来の日付に変更できます。

5. 「終了日」フィールドを使用して、スコアリング・モデルに対するアクティブな操作の制限を定義します。有効な終了日は現在の日付のみです。新規事例フォルダを作成するか、事例フォルダ・テンプレートにスコアリング・モデルを添付する場合は、終了日がないか、終了日が事例フォルダまたは事例フォルダ・テンプレートの作成日より後のスコアリング・モデルのみを選択できます。

注意: 終了日を入力して作業内容を保存すると、終了日を変更または削除できなくなります。これにより、与信ポリシーが厳密に適用され、スコアリング・モデル間の比較は引き続き意味のあるものになります。

6. 「通貨」フィールドで、スコアリング・モデル通貨を選択します。クレジット・スコアの計算で使用されるすべてのデータ・ポイント値は、スコアリング・モデル通貨に換算されます。

7. 「NULL値をゼロ値に変換」オプションを使用して、スコアリング・モデルでのNULL値を持つデータ・ポイントの処理方法を指定します。このオプションはデフォルトで有効になっています。

注意: このオプションを無効にした場合、データ・ポイントにNULL値が含まれていると、スコアリング・モデルではクレジット・スコアが計算されません。この場合、事例フォルダの作成後に与信レビュー・プロセスが停止し、与信アナリストはこれらのデータ・ポイントに対して手動で値を入力する必要があります。

8. 「データ・ポイント」セクションで、プラス(+)アイコンをクリックして「データ・ポイントの追加」ウィンドウを開きます。

9. 「データ・ポイントの追加」ウィンドウで、必要なデータ・ポイントを検索して選択します。「カテゴリ」フィールドでは、特定のカテゴリに属するすべてのデータ・ポイントを表示します。複数のデータ・ポイントを選択し、「適用」ボタンをクリックして、それらをスコアリング・モデルに割り当てることができます。次に、異なるカテゴリに属するデータ・ポイントを検索し、データ・ポイントの選択およびスコアリング・モデルへの適用を続行できます。

10. 目的のデータ・ポイントをすべて追加した後、「OK」ボタンをクリックして「クレジット・スコアリング・モデルの作成」ページに戻ります。

11. 「データ・ポイント」セクションで、最初のデータ・ポイントを選択します。12. 「加重」フィールドに、このデータ・ポイントの相対加重を入力します。

割り当てた加重は、スコアリング・モデルにおけるデータ・ポイントの相対的な重要度を示しま

278

す。13. 「詳細」セクションで、プラス(+)アイコンをクリックして、最初の値範囲と、その範囲に対応する

スコアを入力するための行を開きます。14. 「範囲: 自」および「範囲: 至」フィールドに、値範囲を入力します。範囲内のそれぞれの値に最

大15文字を入力できます。範囲に欠番や重複を含めることはできません。数値データ・ポイントの場合、最初の行の「範囲: 至」の値は2番目の行の「範囲: 自」の値と同じである必要があります。この表は、欠番のない数値範囲を示しています。

範囲 自 至 スコア

現行残高 0 1000 10

現行残高 1000 2000 20

現行残高 2000 3000 30

英数字のデータ・ポイントの場合は、範囲の行ごとに1つの値のみを入力します。つまり、「範囲:自」と「範囲: 至」の両方の値は同じである必要があります。この表は、2つの範囲値を示しています。

範囲 自 至 スコア

範囲1 A2B A2B 10

範囲2 B3B B3B 5

15. 「スコア値」フィールドに、この値範囲の数値スコアを入力します。必須ではありませんが、スコアを割り当てる共通の原則として、スコアが高いほど与信リスクが低くなります。スコアは、値範囲を入力するにつれてその数値が小さくなり、最高レベルのリスクについては、スコアがゼロ(0)またはゼロ近くになります。

16. 行の追加を続行し、値範囲および各範囲に対応するスコアを入力します。入力する範囲には、信用リスクを確立する視点から、指定したデータ・ポイントの可能性のある値がすべて含まれている必要があります。

17. データ・ポイントごとにステップ11から16を繰り返します。18. 「使用可能」オプションを選択して、スコアリング・モデルをアクティブ化します。

後で「使用可能」オプションの選択を解除して、スコアリング・モデルを非アクティブに設定できます。与信要件が一時的に変更されるが、スコアリング・モデルを後で使用できるようにする場合、終了日を入力するかわりにこの操作を実行する必要があります。

注意: スコアリング・モデルを無効にする場合は、アクティブな事例フォルダまたは事例フォルダ・テンプレートで使用されていないことを確認する必要があります。

19. 作業内容を保存します。

関連トピック

データ・ポイントの概要

279

スコアリング・モデル計算の定義方法「スコアリング・モデル」ページを使用して、顧客または顧客アカウントのクレジット・スコア計算で使用するスコアリング・モデルを作成および更新します。

クレジット・スコアのスコアリング・モデル計算には、スコアリング・モデルの各データ・ポイントに割り当てられた、次のスコアリング属性が使用されます。

データ・ポイントの値範囲。各データ・ポイントの値範囲に割り当てられたスコア。各データ・ポイントに割り当てられた加重。

データ・ポイント、その相対加重およびその各値範囲のスコア全体が、クレジット・スコアを得るために使用されるスコアリング・モデルの計算です。

スコアの割当スコアリング・モデルに含まれるデータ・ポイントごとに、値範囲と各範囲に対応するスコアを割り当てる必要があります。データ・ポイントの値範囲は、通常、信用リスクのレベルを表します。

範囲については、スコア可データ・ポイントの行ごとに1つの範囲値を入力して、数値範囲と英数字の範囲を入力できます。

スコアには、数値を入力する必要があります。対応する信用リスクは、並べ方に応じて、昇順または降順の数値スコアの結果になります。

この表は、請求書遅延支払済パーセント・データ・ポイントの範囲とスコアの例を示しています。

信用リスク 範囲: 自 範囲: 至 スコア

低 0 10 100

中 10 60 50

高 60 100 0

この表は、「売上債権回転日数」(DSO)データ・ポイントの範囲とスコアの例を示しています。

信用リスク 範囲: 自 範囲: 至 スコア

低 0 10 100

中 10 25 60

高 25 50 25

最高 50 100 10

加重の割当スコアリング・モデルの各データ・ポイントの相対的な重要度を示すために、各データ・ポイントに重み付

280

けファクタを割り当てます。相対的な重要度の定義は、スコアリング・モデルの使用の計画方法によって異なります。

たとえば、スコアリング・モデルを作成して、自社との長年の与信履歴がある既存の顧客に対して信用限度額増加を決定する場合は、より高い重み付けファクタを請求書遅延支払済パーセント・データ・ポイントに割り当て、より低い重み付けファクタを、たとえば信用機関のスコアや評価を表すデータ・ポイントなどに割り当てることができます。

この例で続行するために、この表は、請求書遅延支払済パーセント・データ・ポイントと「売上債権回転日数」(DSO)データ・ポイントの2つのデータ・ポイントの可能な重み付けファクタを示しています。

データ・ポイント 加重

請求書遅延支払済パーセント 75

売上債権回転日数(DSO) 25

この例では、各加重が次のようにクレジット・スコア合計に影響します。

請求書遅延支払済パーセントの加重は75/(25+75)=75%、つまり0.75「売上債権回転日数」(DSO)の加重は25/(25+75)=25%、つまり0.25

請求書遅延支払済パーセントの加重は、合計クレジット・スコアに向けて75%寄与します。「売上債権回転日数」(DSO)の加重は、合計クレジット・スコアに向けて25%寄与します。

スコアの計算このスコアリングの例は、前述の例で定義されたスコアリング・モデルに基づくクレジット・スコアの計算方法を示しています。

クレジット・スコアの計算は、加重獲得ポイントの合計をパーセントで表したものです。獲得ポイントは、データ・ポイントの値に割り当てられるスコアであり、データ・ポイントの範囲に割り当てられたスコアによって決まります。加重獲得ポイントは、獲得ポイントとデータ・ポイントに割り当てられた加重の積です。

この表は、このスコアリング・モデルを使用するクレジット事例フォルダの獲得ポイントを示しています。

カテゴリ データ・ポイント 値 獲得ポイント

請求および支払 請求書遅延支払済パーセント 57% 50

請求および支払 売上債権回転日数(DSO) 15日 60

この顧客の請求書遅延支払済のパーセントは57%で、スコアリング・モデルでは10% > 60% の中リスク範囲になります。この範囲に割り当てられたスコアは50で、獲得ポイントは50です。

スコアリング・モデルでこのデータ・ポイントに割り当てられた加重は、75%、つまり.75です。請求書遅延支払済パーセント・データ・ポイントの加重獲得ポイント(獲得ポイントx加重)は、50 x .75 = 37.5となります。

この顧客の「売上債権回転日数」(DSO)は15日で、スコアリング・モデルでは10 > 25日の中リスク範囲になります。この範囲に割り当てられたスコアは60であるため、獲得ポイントは60です。

281

スコアリング・モデルでこのデータ・ポイントに割り当てられた加重は、25%、つまり.25です。「売上債権回転日数」(DSO)データ・ポイントの加重獲得ポイント(獲得ポイントx加重)は、60 x .25 = 15となります。

加重獲得ポイントの合計をパーセントで表したクレジット・スコアの算式は、次のようになります。

Credit score = points earned 1 x weight 1 (in percentage) + points earned 2 x weight 2 (in percentage) + ...

この場合、獲得ポイント1 = 50、加重1 (パーセント)は0.75、獲得ポイント2 = 60、加重2 (パーセント)は0.25です。つまり、次のようになります。

クレジット・スコア= 50x0.75 + 60x0.25 = 52.5 (全体を100とした場合)

クレジット事例フォルダ・テンプレートの作成クレジット事例フォルダの作成で使用するクレジット事例フォルダ・テンプレートを作成します。

クレジット事例フォルダ・テンプレートでは、次のものを定義します。

事例フォルダに表示するデータ・ポイント。所定の与信レビューで使用可能にする事例フォルダ内の必須およびオプションのデータ・ポイントの定義。必要に応じて、顧客または顧客アカウントの事例フォルダで使用するスコアリング・モデル。

クレジット事例フォルダは、与信分類とレビュー・タイプの組合せに対して作成されます。これらの組合せごとに事例フォルダ・テンプレートを設定できます。与信ポリシーに従って、同じ組合せで複数の事例フォルダ・テンプレートを作成できますが、一度にアクティブにして有効にできる特定の組合せのテンプレートは1つのみです。

たとえば、アドホック・レビュー中に、高リスクの顧客には、与信の決定の基礎になる追加の担保および銀行参照データ・ポイントが必要です。または、中リスク(D&B使用)顧客の定期レビュー中に、主に「DBPaydexスコア」および「DB評価」データ・ポイントの値に依存する場合があります。

与信レビューが開始されて事例フォルダが作成されると、与信分類とレビュー・タイプの組合せに基づいて事例フォルダ・テンプレートが割り当てられます。この組合せでテンプレートが見つからない場合は、デフォルトとして指定した事例フォルダ・テンプレートが使用されます。

事例フォルダ・テンプレートを作成する手順は、次のとおりです。

1. 「設定および保守」→「クレジット事例フォルダ・テンプレートの管理」ページにナビゲートします。

2. プラス(+)アイコンをクリックして、「クレジット事例フォルダ・テンプレートの作成」ページを開きます

3. 「名前」および「摘要」フィールドに、この事例フォルダ・テンプレートの名前と説明を入力します。与信分類とレビュー・タイプの組合せに関連するため、事例フォルダ・テンプレートのタイプを識別する名前を使用できます。

282

4. 「開始日」フィールドに、この事例フォルダ・テンプレートをアクティブにする日付を入力します。デフォルトはシステム日付ですが、システム日付よりも前または後の日付に変更できます。アクティブおよび有効な事例フォルダ・テンプレートは、事例フォルダ・テンプレートの開始日以降に作成された事例フォルダで使用できます。

5. 「終了日」フィールドを使用して、事例フォルダ・テンプレートに対するアクティブな操作の制限を定義します。与信ポリシーが変更された場合、または近い将来に変更されると予想される場合、与信分類とレビュー・タイプの特定の組合せに対して複数の事例フォルダ・テンプレートを作成できます。これを行うには、将来の終了日を現在のテンプレートに適用し、現在のテンプレートの終了日より後の開始日を指定して新しいテンプレートを作成します。

注意: 終了日を入力して作業内容を保存すると、終了日を変更または削除できなくなります。

6. オプションで、「スコアリング・モデル」フィールドに、この事例フォルダ・テンプレートで使用するスコアリング・モデルを入力します。スコアリング・モデルを選択しない場合、このテンプレートに設定したデータ・ポイントは与信アナリストにより与信の決定に使用されますが、クレジット・スコアは計算されません。

7. 「データ・ポイント」セクションで、「カテゴリ」フィールドを使用して、特定のカテゴリのデータ・ポイントのみを表示します。デフォルトでは、「データ・ポイント」セクションにはすべてのカテゴリのすべてのデータ・ポイントが表示されます

8. 「事例フォルダに含める」列のフィールドを使用して、事例フォルダ・テンプレートに含めるデータ・ポイントを指定します。

いいえ: デフォルト。これらのデータ・ポイントは保存後にテンプレートに表示されず、このテンプレートを使用して作成された事例フォルダには表示されません必須: データ・ポイントはテンプレートに含まれ、与信の決定、およびこのテンプレートを使用するクレジット事例フォルダでクレジット・スコアを計算するには、値が必要です。クレジット事例フォルダでは、値のない必須データ・ポイントに警告アイコンのラベルが付いています。オプション: データ・ポイントはテンプレートに含まれますが、値は必須ではありません。オプションのデータ・ポイントにより、与信アナリストは特定の与信の決定に必要な値をより柔軟に決定できます。

注意: このテンプレートに対してスコアリング・モデルを選択した場合でも、このテンプレートを使用するクレジット事例フォルダに表示するためには、スコアリング・モデルのデータ・ポイントを「必須」または「オプション」に設定する必要があります。与信アナリストがスコア可のオプションのデータ・ポイントに値を入力した場合は、この値がクレジット・スコア計算に含められます。

9. テンプレートに必要なデータ・ポイントをすべて設定した後、作業内容を保存します。

データ・ポイントの要約表の保守方法多くのデータ・ポイントの値は、Receivablesの要約表AR_TRX_BAL_SUMMARYおよびAR_TRX_SUMMARYに保持されます。

AR_TRX_BAL_SUMMARYAR_TRX_BAL_SUMMARY表には、顧客および顧客アカウントに関連する要約データが保持されます。

283

表には、次のデータ・ポイント・カテゴリの要約データが含まれています。

年齢調べ: すべてのオープン件数とオープン金額。遅延金額、修正金額、リスクあり金額。請求および支払: 支払関連データ。ビジネス情報および与信: 現行売掛/未収金残高。

この表に格納されているデータ・ポイント値の最も低い詳細度レベルは、指定通貨での特定の顧客アカウントの顧客請求先サイトのレベルになります。

顧客または顧客アカウントの事例フォルダに表示されるAR_TRX_BAL_SUMMARY表のデータ・ポイント値は、次の方法で導出されます。

すべての請求先サイト(顧客アカウント事例フォルダの場合)またはすべての顧客アカウント(顧客事例フォルダの場合)のすべての値を追加します。顧客または顧客アカウント・プロファイルで通貨および換算レート・タイプに定義された値を使用して、値を与信通貨に換算します。顧客または顧客アカウント・プロファイルで定義されている与信通貨がスコアリング・モデル通貨と異なる場合、スコアリングに使用されるデータ・ポイント値はスコアリング・モデル通貨に換算されます。

AR_TRX_SUMMARYAR_TRX_SUMMARY表には、顧客および顧客アカウントのトランザクションに関連する要約データが保持されます。

表には、次のデータ・ポイント・カテゴリの要約データが含まれています。

請求および支払: トランザクション件数、金額およびパーセンテージ。ビジネス情報および与信: 貸方の金額と日付。

AR_TRX_SUMMARY表のデータは12か月の期間にわたります。この期間にわたって集計された注文、請求書および支払データの表示により、顧客または顧客アカウントとの関係の全体像を把握し、将来のパフォーマンスを予測できます。

この表に格納されているデータ・ポイント値の最も低い詳細度レベルは、特定の12か月の期間における指定通貨での特定の顧客アカウントの顧客請求先サイトのレベルになります。

顧客または顧客アカウントの事例フォルダに表示されるAR_TRX_SUMMARY表のデータ・ポイント値は、次の方法で導出されます。

すべての請求先サイト(顧客アカウント事例フォルダの場合)またはすべての顧客アカウント(顧客事例フォルダの場合)のすべての最新基準日の値を加算します。顧客または顧客アカウント・プロファイルで通貨および換算レート・タイプに定義された値を使用して、値を与信通貨に換算します。顧客または顧客アカウント・プロファイルで定義されている与信通貨がスコアリング・モデル通貨と異なる場合、スコアリングに使用されるデータ・ポイント値はスコアリング・モデル通貨に換算されます。

284

「顧客アカウント要約に対する売掛/未収金トランザクションの処理」プロセスの実行事例フォルダの存続期間中に、顧客データは、新規トランザクション、修正、支払、係争、およびその他のトランザクションと残高の更新により変更される可能性があります。

「顧客アカウント要約に対する売掛/未収金トランザクションの処理」プロセスを使用すると、AR_TRX_BAL_SUMMARYおよびAR_TRX_SUMMARYの表のデータを更新してこれらすべての変更を反映できます。

「顧客アカウント要約に対する売掛/未収金トランザクションの処理」プロセスの定期的な実行をスケジュールして、関連するすべてのデータ・ポイントに適用可能な顧客アカウント要約データをリフレッシュします。

AR_TRX_BAL_SUMMARYおよびAR_TRX_SUMMARY表をリフレッシュした後で、適用可能な事例フォルダを開き、「処理」メニューから「データのリフレッシュ」を選択して事例フォルダ内のデータ・ポイントをリフレッシュできます。

データ・ポイントのサード・パーティ与信データのインポート方法スコアリング・モデルでデータ・ポイント値として使用するために、サード・パーティの与信サービスから与信データをインポートできます。

次のデータ・ポイント・カテゴリの与信データをインポートできます。

銀行参照ビジネス情報および与信担保財務データ保証人参照取引参照事業資金追加のデータ・ポイント(使用可能なカテゴリの範囲でないデータ)

与信データのアップロード・テンプレート・ワークシートを使用して、データ・ポイント・カテゴリ、データ・ポイントおよびデータ・ポイント値を使用して、サード・パーティから顧客の与信データを入力します。「インポートのためのインタフェース・ファイルのロード」プロセスの「与信データのインポート」プロセスを使用して、完了したワークシートをアップロードします。

サード・パーティ与信サービスから与信データをアップロードする手順は、次のとおりです。

1. 与信データのアップロード・テンプレートをダウンロードします。テンプレートのインストラクションのタブで情報をレビューします。

285

2. 目的の顧客およびデータ・ポイント値について、ワークシートの各行に入力します。各データ・ポイント値について、次のように入力します。

顧客パーティ番号(登録ID)顧客アカウント番号(データが顧客アカウントにのみ適用可能な場合)データ・ポイント・カテゴリデータ・ポイント名データ・ポイント値データ・ポイント値通貨

注意: 顧客、顧客アカウント、データ・ポイント・カテゴリおよびデータ・ポイント名の同じ組合せには、1つのデータ・ポイント値のみを入力できます。

注意: 「通貨」列は、銀行参照の平均残高と現在の残高、事業資金額、ほとんどの財務データなど、数値を使用するほとんどのデータ・ポイントに必要です。詳細は、与信データのアップロード・テンプレートのインストラクションを参照してください。

3. テンプレートが完成したら、アップロード用の.zipファイルを生成します。4. 「スケジュール済プロセス」に移動します。5. 「インポートのためのインタフェース・ファイルのロード」プロセスにナビゲートします。6. 「インポート・プロセス」パラメータで「与信データのインポート」を選択します。7. 「データ・ファイル」パラメータで、ステップ3で生成した.zipファイルを選択します。8. 「インポートのためのインタフェース・ファイルのロード」プロセスを発行します。

注意: データ・ポイント値がすでに存在する場合は、新たにインポートされたデータによって既存の値が上書きされます。

9. 完了したアップロード・プロセスをレビューし、アップロード・エラーや正常にインポートされなかった行についてログ・ファイルをレビューします。

与信管理データ・ポイントのインポート方法「与信データのインポート」プロセスを使用して、スコアリング・モデルでデータ・ポイント値として使用するために、サード・パーティ組織から与信データをインポートします。

データを準備するために使用できる、顧客の与信データのFBDIテンプレートをダウンロードできます。このテンプレートには、情報の入力作業を支援するインストラクション・シートが含まれています。

テンプレートにアクセスするには、次のステップを実行します。

1. Oracle Financials Cloudのファイルベース・データ・インポートのガイドに移動します。2. 目次で、「ファイル・ベース・データ・インポート」をクリックします。3. 与信管理データ・ポイントのインポートをクリックします。4. 「ファイル・リンク」セクションで、Excelテンプレートへのリンクをクリックします。

ワークシートでデータを準備する際は、次のガイドラインに従ってください。

各列の必須情報を入力してください。詳細なインストラクションは、各列ヘッダーのツールチップを参照してください。

286

テンプレートの列の順序は変更しないでください。使用しない列は非表示にするか、スキップできますが、削除しないでください。

テンプレートが完成したら、「インポートのためのインタフェース・ファイルのロード」プロセスを使用してアップロードします。

1. 「インポート・プロセス」フィールドで「与信データのインポート」を選択します。2. 「データ・ファイル」フィールドに、完成したテンプレートを入力します。3. 「インポートのためのインタフェース・ファイルのロード」プロセスにより、テンプレートに含まれる各顧客の与信データがアップロードされます。インポート・プロセスでは、顧客(パーティ)番号および顧客アカウント番号(入力した場合)の一意性がチェックされます。

顧客与信データのアップロード・テンプレートに影響する設定顧客与信データのアップロード・インポート・テンプレートには、インストラクションのタブと顧客与信データのタブが含まれています。

スプレッドシートのタブ 説明

インストラクションおよびCSV生成

データの準備およびロードとテンプレートのフォーマット、「与信データのインポート」プロセスの発行、インポート・エラーの修正に関する情報が含まれています。

CustomerCreditData 適用可能な各顧客および顧客アカウントのクレジット・データ・ポイント情報を入力します。

顧客与信データの処理方法次のデータ・ポイント・カテゴリのサード・パーティ組織から与信データをインポートできます。

銀行参照ビジネス情報および与信担保財務データ保証人参照取引参照ベンダー資金追加(ユーザー定義データ・ポイントの場合)

顧客、顧客アカウント、データ・ポイント・カテゴリおよびデータ・ポイント名の同じ組合せに対して1つのデータ・ポイント値を入力します。データ・ポイントが数値を使用する場合、多くの場合、通貨を追加する必要があります。

検証済データ・ポイントは、該当する顧客および顧客アカウント用に作成されたスコアリング・モデルで使用できるようになります。

関連トピック

287

データ・ポイントの概要

クレジット事例フォルダの付加フレックスフィールド付加フレックスフィールドを使用して、与信チェック要求の追加ソース・トランザクション情報を渡します。この情報は、与信チェック失敗の結果として作成されたクレジット事例フォルダに渡されます。

契約開始日、契約請求頻度、契約請求ルールなど、与信チェックを要求しているソース・トランザクションに関する情報を渡すことができます。付加フレックスフィールドは、クレジット事例フォルダの編集および表示のページの「追加情報」セクションに表示されます。

事例フォルダが承認される前は、これらの追加属性値を編集できます。事例フォルダが承認されると、これらの値は読取り専用として表示されます。

定義したクレジット事例フォルダ付加フレックスフィールドが、与信チェック・サービスを介して渡される値と一致することを確認する必要があります。属性のデータ型が一致しない場合、または付加フレックスフィールドが定義されていない場合、与信チェックに失敗したために作成される事例フォルダにこれらの追加属性は表示されません。

関連トピック

フレックスフィールドのコンポーネントフレックスフィールド構成の概要実行時のフレックスフィールド

与信管理の定義に関するFAQ

信用評価と与信分類の違いは何ですか。信用評価およびリスク・コードは、顧客または顧客アカウントに関する内部コメントまたはノートとして使用できるユーザー定義可能な値です。これらの値には、プログラム的な使用方法はありません。

与信分類は、顧客の信用価値を管理するための不可欠な部分です。与信プロファイルと事例フォルダ・レビュー・タイプ(「アドホック・レビュー」、「定期レビュー」、「与信チェック失敗」)の与信分類の組合せによって、顧客与信レビューの事例フォルダの作成に使用するクレジット事例フォルダ・テンプレートが決まります。

たとえば、「高リスク」の与信分類と「与信チェック失敗」のレビュー・タイプを持つ顧客プロファイルでは、顧客の与信履歴の詳細なレビューを必要とする事例フォルダを作成し、「新規顧客」の与信分類と「アドホック・レビュー」のレビュー・タイプを持つ顧客プロファイルでは、正式なレビュー・プロセスのみを必要とする場合があります。

288

与信通貨が定義されていないとどうなりますか。「AR: デフォルト与信管理通貨」プロファイル・オプションを使用して、デフォルト与信通貨を定義できます。与信チェック・プロセスでは、該当する顧客、顧客アカウントまたはパーティ・プロファイルで与信通貨が定義されていない場合、この通貨が使用されます。

「AR: デフォルト与信管理通貨」プロファイル・オプションが定義されていない場合、与信チェック・プロセスでは与信通貨としてUSドル(USD)が使用されます。

換算レート・タイプが定義されていない場合、与信チェック・プロセスでは換算レート・タイプ「社内」が使用されます。

スコアリング・モデルを編集または削除できないのはなぜですか。これは、スコアリング・モデルが事例フォルダまたは事例フォルダ・テンプレートで使用されるためです。使用中のスコアリング・モデルの内容は削除または更新できません。

「スコアリング・モデル」ページで、スコアリング・モデルを無効にしたりスコアリング・モデルに終了日を適用できます。終了日を適用する場合は、新規スコアリング・モデルを割り当てるか、相当する終了日が適用可能な事例フォルダまたは事例フォルダ・テンプレートに適用されるようにする必要があります。

スコアリング・モデルにデータ・ポイントを追加できないのはなぜですか。スコアリング・モデルに追加できるのは、スコア可のデータ・ポイントのみです。スコア可のデータ・ポイントは、スコア値を割り当てる値範囲を使用します。これらのスコア値は、クレジット・スコアの計算に使用されます。

スコア不可のデータ・ポイントは参照情報のみを提供します。スコア不可のデータ・ポイントを事例フォルダに追加すると、顧客の与信の評価に役立ちます。

NULLデータ・ポイント値とゼロ・データ・ポイント値の違いは何ですか。NULLデータ・ポイント値は活動がないことを示します。ゼロ・データ・ポイント値は、過去に活動が発生したが、データ・ポイントに現在の値がないことを示します。

たとえば、請求書遅延支払済の件数データ・ポイントの場合、NULL値は支払が行われなかったことを意味し、ゼロ値はすべての請求書が期限内に支払われたことを意味します。

与信通貨とスコアリング・モデル通貨の違いは何ですか。与信通貨は顧客与信プロファイルで定義します。

顧客または顧客アカウントのクレジット事例フォルダでは、使用可能貸方、与信限度額、データ・ポイント

289

値など、すべての金額ベースの値が与信通貨で表示されます。

スコアリング・モデル通貨は、データ・ポイントおよびデータ・ポイント範囲のすべての金額ベースの値を「スコアリング・モデル」ページに表示するために使用されます。

事例フォルダ・テンプレートの一部としてのスコアリング・モデルは、様々な顧客のクレジット・スコアの計算に使用されます。クレジット事例フォルダでスコアリング・モデルを使用している場合、金額ベースのデータ・ポイント値は、「クレジット事例フォルダ」ページに与信通貨で表示され、「スコアリング詳細」ページにスコアリング・モデル通貨で表示されます。

ビジネス要件に応じて、スコアリング・モデル通貨としてUSドルやユーロなどのグローバルに認識された通貨を使用したり、特定のグローバル地域または事業部門の代表通貨を与信通貨として使用できます。

事例フォルダ・テンプレートにスコアリング・モデルを追加するのはなぜですか。このクレジット事例フォルダ・テンプレートを使用して作成されたクレジット事例フォルダで、クレジット・スコアを計算するためです。事例フォルダの作成時にすべてのデータ・ポイントに値がある場合、クレジット・スコアは自動的に計算されます。与信レビュー中に、データ・ポイント値を入力、追加および更新し、スコアを再計算できます。

事例フォルダ・テンプレートでスコアリング・モデルが使用されていない場合、このテンプレートで作成された事例フォルダには、スコアを計算せずに「必須」および「オプション」に設定したデータ・ポイントが表示されます。これらのデータ・ポイントを使用して、顧客または顧客アカウントの信用価値を評価できます。また、データ・ポイント値として使用可能なサード・パーティ信用評価を使用することもできます。

デフォルトの事例フォルダ・テンプレートを割り当てるにはどうすればよいですか。デフォルトの事例フォルダ・テンプレートは、特定の与信分類とレビュー・タイプの組合せでテンプレートが見つからない場合、与信レビュー中に事例フォルダに割り当てられます。

デフォルトの事例フォルダ・テンプレートは1つのみ指定できます。デフォルトの事例フォルダ・テンプレートを有効にし、現在の日付以前の開始日を設定しますが、終了日は指定しないでください。終了日を指定した事例フォルダ・テンプレートをデフォルトとして使用することはできません。

「クレジット事例フォルダ・テンプレートの管理」ページで、テンプレートを選択し、「デフォルトとして設定」ボタンをクリックします。以前のデフォルトのテンプレートはすべて、新しい指定のテンプレートに再割当されます。

事例フォルダ・テンプレートを編集できますか。はい。テンプレートを使用して事例フォルダを作成していない場合は、テンプレート名を除き、テンプレートの内容全体を編集できます。

テンプレートを使用して事例フォルダを作成した場合、テンプレートに終了日を適用することと、「使用可能」オプションの選択を解除することのみが可能です。これらの更新のいずれかを行う場合は、現在の事例フォルダに影響を与えないようにする必要があります。

290

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

291

19c

現預金のための売掛/未収金クレジットの実装

12 資金管理および銀行取引構成の定義この章の内容は次のとおりです。

銀行、支店および口座コンポーネントの連携の仕組み口座の作成時の考慮事項資金管理プロファイル・オプション解析ルール・セットの概要トランザクション・タイプ・マッピングの概要許容範囲ルールの概要突合せ照合ルール突合せルール・セットの概要銀行取引明細書トランザクション・コードの概要構成可能なBAI2トランザクション・コードのマッピング方法銀行取引明細書トランザクション作成ルールの概要スプレッドシートでの銀行、支店および口座の作成資金ポジションおよび資金予測の設定銀行口座検証

銀行、支店および口座コンポーネントの連携の仕組み銀行、支店および口座は銀行口座モデルを前提として連携します。

このモデルにより、すべての銀行口座を1箇所で定義および追跡し、口座へのアクセスを次の対象に明示的

292

に許可できます。

複数のビジネス・ユニット機能ユーザー

これにより、いくつかの異なるビジネス・ユニットで同じ銀行口座を共有する場合に、これらのビジネス・ユニットで銀行口座を重複して設定することがなくなります。

銀行銀行口座作成の最初のステップは銀行の作成です。次のことが可能です。

表示および更新の対象となる既存の銀行を検索する既存のパーティから新規銀行を作成する

次の点を考慮してください。

既存のパーティから作成するというオプションは、照合オプションによって暗黙的に実装されます。このオプションは、同じ銀行が設定された既存のパーティが見つかった場合にのみ使用できます。照合オプションを選択すると、一致したパーティから情報がページに再移入されます。

支店銀行の作成が終了したら、次に、その銀行に関連する支店を1つ以上作成します。支店を作成する際にも照合オプションを使用できます。照合オプションを使用せずに新規支店を作成するには、必要な情報を手動で入力します。また、同じページで支店関連のその他の属性を定義することもできます。

既存のパーティが見つかったときに照合オプションを使用しなかった場合は、同じパーティ名を使用して支店が作成されます。

口座口座の定義に関連した、次の4つの領域があります。

一般情報口座の管理セキュリティ、および口座へのアクセスビジネス・ユニット割当

銀行および支店の作成が終了したら、次の手順を実行して銀行口座の設定に進みます。

銀行口座に関連付ける銀行支店を選択します。銀行口座の所有者を割り当てます。

注意: PayablesまたはReceivablesのための銀行口座を作成するには、その銀行口座を使用するビジネス・ユニットに対して、最初にビジネス・ユニット・アクセスを追加します。

次の点を考慮してください。

293

Oracle Fusion Account PayablesまたはReceivablesの口座は、ビジネス・ユニットによって識別されます。Oracle Fusion Payrollの口座は、法的エンティティによって識別されます。「銀行および銀行支店の非アクティブ化」プログラムを使用すると、アクティブな当方銀行口座および外部銀行口座がないすべての銀行および銀行支店を非アクティブ化できます。

口座の作成時の考慮事項銀行、支店および口座は銀行口座モデルを前提として連携します。銀行口座モデルを使用すると、すべての銀行口座を1箇所で定義および追跡できます。

銀行口座モデルでは、複数のビジネス・ユニット、機能およびユーザーに口座へのアクセスを明示的に許可できます。銀行口座を設定するときには、次のことを考慮してください。

一意の一般会計現預金勘定を各口座に割り当て、それを使用して口座のすべての資金トランザクションを記録します。これによって、台帳から銀行への突合せが容易になります。銀行口座にセキュリティを付与します。銀行口座セキュリティは、銀行口座使用セキュリティ、銀行口座アクセス・セキュリティ、ユーザーおよびロール・セキュリティで構成されます。

口座使用口座使用とは、次を対象に作成された口座のことをいいます。

Oracle Fusion PayablesOracle Fusion ReceivablesOracle Fusion Payroll

これらのアプリケーションの1つ以上で口座を作成する場合は、適切な使用を選択します。

口座アクセス買掛管理および売掛管理の口座アクセスはビジネス・ユニットによって保護されます。銀行口座を買掛管理または売掛管理で使用するには、次のことを行う必要があります。

1. アプリケーションに適した使用を選択します。2. 1つ以上のビジネス・ユニットにアクセス権を付与します。

注意: アクセス権は、法的エンティティを所有する銀行口座と同じ元帳を使用するビジネス・ユニットにのみ割り当てることができます。

ユーザーおよびロール・セキュリティ特定のユーザーおよびロールのみが使用できるように、銀行口座をさらに保護できます。「ユーザーとロールにより保護された銀行口座」のデフォルト値は「いいえ」です。買掛管理および売掛管理の場合、「ユー

294

ザーとロールにより保護された銀行口座」が「いいえ」であっても、銀行口座にアクセスするには適切なビジネス・ユニットが割り当てられている必要があります。「ユーザーとロールにより保護された銀行口座」が「はい」に設定されている場合、銀行口座を使用するには、ユーザー名が指定されているかまたは銀行口座に割り当てられているロールを実行する必要があります。

「資金マネージャ」ジョブ・ロールに「資金管理の運用管理」セキュリティ職務ロールを割り当てて、銀行、支店および口座を設定するためのアクセス権を提供する必要があります。ユーザーおよびロール・セキュリティを変更するには、銀行口座セキュリティの管理権限が割り当てられている必要があります。「セキュリティ」タブへのアクセスを制限する場合は、カスタマイズしたロールを作成して、銀行口座セキュリティの管理権限を削除する必要があります。たとえば、「資金管理の運用管理」職務ロールをコピーして名前を変更し、権限を削除します。

資金管理プロファイル・オプションOracle Fusion Cash Managementのプロファイル・オプションでは、ビジネス・プラクティスの効率を改善および促進する方法が提供されます。これらのプロファイル・オプションの構成方法は、他のアプリケーションとの相互作用に影響を与える可能性があります。これらのプロファイル・オプションを使用可能にすると、これらのアプリケーション間のプロセスを合理化できます。

次の表では、資金管理プロファイル・オプションをリストし、これらについて説明します。

プロファイル・オプション プロファイル表示名 適用対象 デフォルト設定

CE_DISABLE_BANK_VAL 国固有の銀行検証の使用不可 当方銀行口座外部銀行口座

いいえ

CE_GL_RECON_ENABLED 仕訳突合せ使用可能 銀行残高突合せ はい

CE_MASK_INTERNAL_BANK_ACCT_NUM 当方銀行口座番号のマスク 当方銀行口座 マスクなし

CE_USE_EXISTING_BANK_BRANCH 既存の銀行および支店の使用 従業員銀行口座受取人銀行口座

いいえ

注意: 当方銀行口座はOracle Fusion Cash Managementで設定されます。支払銀行口座をOracle FusionAccount Payablesに、送金先銀行口座をOracle Fusion Account Receivablesに割り当てます。

注意: 外部銀行口座は、サプライヤ、顧客、非定型受取人および従業員用に設定および使用されます。

プロファイル・オプションの有効化: 考慮する点次の詳細は、プロファイル・オプションの構成、他のアプリケーションへの影響およびビジネス・プラクティスの合理化の方法を示しています。

1. 国固有の検証の使用不可このプロファイル・オプションは、銀行コード、支店番号、口座番号、検証桁およびIBANの国固有の検証を管理します。このプロファイル・オプションはサイトまたはユーザー・レベルで設定でき

295

ます。プロファイル・オプションのデフォルトは、サイト・レベルで「いいえ」に設定されています。プロファイル・オプションが「はい」に設定されている場合、銀行コード、支店番号、口座番号、検証桁およびIBANに対する国固有の検証プロセスはなくなります。このプロファイル・オプションは当方銀行口座および外部銀行口座に影響します。銀行口座番号の一意の銀行、支店、口座、必須要件のチェックには影響しません。

2. 仕訳突合せ使用可能このプロファイル・オプションにより、GL仕訳手動入力から直接、銀行取引明細書明細の手動および自動突合せが可能になります。このプロファイル・オプションはサイト・レベルで設定できます。プロファイル・オプションのデフォルトは「はい」に設定されています。このプロファイル・オプションが「いいえ」に設定されている場合は、「突合せ照合ルールの管理」、「手動突合せ」ページおよび突合せプロセスで仕訳ソース・トランザクションが無効化されます。注意: 突合せ済の仕訳がゼロの場合のみ、このプロファイルを「いいえ」に設定できます。

3. 当方口座番号のマスクこのプロファイル・オプションにより、当方銀行口座番号のマスクが可能になります。このプロファイル・オプションはサイトまたはユーザー・レベルで設定できます。プロファイル・オプションのデフォルトは、サイト・レベルで「マスクなし」に設定されています。「最初の4桁を表示」または「最後の4桁を表示」を選択できます。たとえば、当方銀行口座番号XXXX8012は最後の4桁を表示し、残りすべてをマスクします。このプロファイル・オプションは当方銀行口座にのみ影響します。

4. 既存の銀行および支店の使用従業員または非定型受取人銀行口座を作成するときに、銀行支店データ情報を事前ロードするには、このプロファイル・オプションを有効にします。銀行支店データを事前ロードし、従業員が自分の銀行口座を入力するときに事前ロード済データを選択するように設定できます。または、従業員に自分の口座に関連する銀行、支店および口座情報をすべて入力させることもできます。顧客は、このプロファイルを介して銀行支店データを事前ロードするようにプリファレンスを設定できます。このプロファイル・オプションはサイトまたはユーザー・レベルで設定できます。デフォルトでは、このプロファイル・オプションは「いいえ」に設定されており、事前ロードされた情報は使用できません。この場合、「銀行」、「銀行コード」、「銀行支店」、「支店番号」および「BICコード」フィールドがフリー・テキスト・フィールドとして表示され、新しい銀行および銀行支店がその銀行口座用に作成されます。銀行名が入力されていない場合は、CE_EMP_UNSPECIFIED_BANKというデフォルト名が使用されます。支店名が入力されていない場合は、CE_EMP_UNSPECIFIED_BRANCHというデフォルト名が使用されます。このプロファイル・オプションを「はい」に設定すると、従業員または非定型受取人銀行口座を作成するときに、既存の銀行および支店の情報が使用可能になり、値リストに表示されます。

解析ルール・セットの概要Oracle Fusion Cash Managementでは、銀行取引明細書インポート・プロセス中にデータを変換する解析ルール・セットがサポートされます。解析ルールを使用して、フィールド間でデータを移動します。解析ルール・セットは銀行口座設定で銀行口座に関連付けられます。この解析ルール・セットは、一般的に取引明細書明細追加情報フィールドのデータを解析して、より具体的な取引明細書明細フィールドに移動する場合に使用されます。解析ルール・セット内の各解析ルールは、次のフィールドで構成されます。

順序: ルールを処理する順序を決定します。

296

トランザクション・コード: 取引明細書明細タイプの決定に使用されるコード。

ソース・フィールド: 解析するデータが格納されているインタフェース表のフィールド。

ターゲット・フィールド: データの解析先となる取引明細書明細フィールド。

ルール: 解析するソース・フィールド内のデータを決定するための構文が含まれます。

上書き: ターゲット・フィールドの既存データを上書きするか、データの解析をスキップするかを制御するために使用されます。

解析ルールの構文を次に説明します。

[LITERAL](<[MATCHING TOKEN],[START-END]>)[LITERAL]

ここで

LITERALは、ソース・データと正確に一致する必要がある、識別子によって表される文字列または文字値を表します。

MATCHING TOKENは、抽出するデータを記述するトークン(またはトークンのセット)を表します。次の表に、有効なトークンとその説明を示します。

トークン 説明

N 有効な数値の抽出

. 小数部

X 英数字の抽出

~ ソース・フィールド内の解析位置からデータの末尾までまたは次のリテラルまでのすべてを抽出します。

START データの抽出を開始する位置。解析位置によってオフセットされます。有効な数値である必要があります。

END データの抽出を停止する位置。ENDには有効な数値または~トークンを使用できます。

次の表に、いくつかの例を示します。

説明 ソース・データ ルール

ターゲット・データ

ソース・フィールドから数値レート・データを抽出する

EST/TRX RTE 3.76 USD/LIBOR CPTY: PRU RTE (N.NN) 3.76

ソース・フィールドから日付の値を抽出する

Dt.01/01/2011?Receipt Dt.(1-10)?Receipt

01/01/2011

ソース・フィールドから小切手番号を抽出する

Account Number 1005 AccountNumber.(X~)

1005

ソース・フィールド $^EUR:Dt $^(1-3):Dt. EUR

297

から通貨を抽出する

同じソース・フィールドから不明な文字列長の相手方を抽出する

EST/TRX RTE 3.76 USD/LIBOR CPTY:PRU CPTY: (X~) PRU

位置一致を使用して同じソース・フィールドから通貨を抽出する

PRU EST/TRX RTE 3.76 USD/LIBOR CPTY: PRU RTE(7-9) USD

入力追加情報から契約IDを抽出する

TXT:AR:Receipt Num:CEF-1:For:2010$^USD:Dt.01/01/2011?Receipt Method:CE-Foreign:Receipt Type:Standard:BU:VisionOperations:Customer:World of Business:Account No.1001

AccountNumber(NNNN)

1001

顧客参照からトランザクションIDを抽出する

CustRef # A.23@orlc.com CustRef(X~).com

#A.23@orlc

トランザクション・タイプ・マッピングの概要トランザクション・タイプ・マッピングを使用すると、資金トランザクション・タイプをアプリケーション・トランザクションに関連付けることができます。

関連付けるには次のものを作成して、資金トランザクション・タイプにマップする必要があります。

Oracle Fusion Account Payablesの支払方法Oracle Fusion Account Receivablesの支払方法Oracle Fusion Payrollの支払タイプ

資金トランザクション・タイプをアプリケーション・トランザクションに割り当てると、銀行取引明細書の突合せプロセスがより効率的になります。

銀行取引明細書明細も資金トランザクション・タイプに関連付けられており、この共通属性を使用して照合ルールを作成できます。

許容範囲ルールの概要許容範囲ルールを使用すると、日付と金額の許容範囲を指定できます。これにより、突合せが定義済の許容範囲に違反する場合に防止または警告されます。

金額許容範囲は、換算レートの端数処理または変動のために差異が発生する可能性がある外貨トランザクションを突き合せるときに最もよく使用されます。銀行が銀行取引明細書明細金額に処理料金を含める場合にも使用できます。日付許容範囲は主に、ある1日に発行され、数日または数週間後まで銀行勘定を決済しない小切手に使用されます。

298

許容範囲ルールを定義するときには、次のことを考慮してください。

許容範囲を適用することで、これらのトランザクション・タイプに対する突合せと会計を自動化できます。日付または金額許容範囲がルール内で定義されていない場合は、完全一致が必要です。手動突合せの場合、オプションで許容範囲ルールを銀行口座に割り当てることができます。自動突合せの場合、許容範囲ルールは、ルール・セット設定で照合ルールと関連付けることができ、照合ルールが日付や金額またはその両方で照合する場合に適用できます。ただし、金額許容範囲を含む許容範囲ルールを、1対1照合タイプ以外の照合ルールに割り当てた場合、その金額許容範囲は無視されます。

日付許容範囲突合せの日付許容範囲は、日付範囲として定義されます。日付許容範囲は、ソース・トランザクション日が、銀行取引明細書明細の日付よりも前または後の特定の日数以内であることを検証するものです。

手動突合せでは、銀行口座に割り当てられた許容範囲ルールで日付許容範囲が指定されている場合、その日付許容範囲はすべての照合シナリオに適用されます。日付許容範囲違反の場合は警告メッセージが表示されますが、取引明細書明細とトランザクションを突き合せることはできます。日付許容範囲が割り当てられていないか指定されていない場合、正確な日付一致である必要があり、警告メッセージが表示されます。

自動突合せでは、日付許容範囲を含む許容範囲ルールを照合ルールに関連付けることができます。照合ルールが日付で照合する場合、日付許容範囲が適用されます。このシナリオでは、日付許容範囲違反が発生すると突合せが阻止されます。

金額許容範囲突合せの金額許容範囲は、手動突合せと自動突合せの両方について、1対1の照合シナリオでのみ使用できます。1対多、多対1または多対多の照合シナリオでは、突合せの金額許容範囲は使用できません。このようなシナリオでは、銀行取引明細書明細の金額がトランザクション金額と等しい必要があります。突合せの金額許容範囲は、パーセントまたは金額範囲、あるいはその両方として定義できます。パーセントと金額の両方を適用した場合は、取引明細書明細金額に応じて最も控えめな許容範囲がアプリケーションによって使用されます。

たとえば、金額許容範囲がプラスまたはマイナス$5、パーセント許容範囲がプラスまたはマイナス1%で、取引明細書明細金額が$100の場合、アプリケーションは最初にパーセント金額($100の1% = $1)を計算します。次に、これを$5と比較し、より小さい金額を使用します。この場合、これは$1であるため、この明細にトランザクションを突き合せるには、$99から$101の間である必要があります。

自動突合せでは、パーセントまたは金額、あるいは両方の許容範囲タイプを含む許容範囲ルールを照合ルールに関連付けることができます。ただし、許容範囲は、照合ルールが1対1照合タイプのルールの場合にのみ適用できます。この1対1タイプの照合のシナリオでは、許容範囲内の金額差異はすべて、資金管理における外部トランザクションとして自動的に作成されます。

突合せ照合ルール299

突合せ照合ルールは、銀行取引明細書明細とシステム・トランザクションを照合して手動介入の必要性を最小限に抑えるために役立ちます。

銀行取引明細書の自動突合せ照合ルールを定義し、銀行取引明細書の自動突合せルール・セットに割り当てます。銀行口座にルール・セットを割り当てた後、自動突合せプロセスにより、より高い照合率を達成する突合せ照合ルールが選択されます。

照合ルールごとに次を指定します。

トランザクション・ソース: 買掛/未払金、売掛/未収金、給与、仕訳または外部。照合タイプ: 1対1、1対多、多対1または多対多。次の表に、Oracle Fusion Cash Managementで使用可能な様々な照合タイプを示します。

照合タイプ 説明

1対1 1つの銀行取引明細書明細が1つのシステム・トランザクションと照合され、互いに突合せされます

1対多 1つの銀行取引明細書明細が、多数のシステム・トランザクションに対して突合せされます

多対1 多数の銀行取引明細書明細がグループ化され、1つのシステム・トランザクションに対して突合せされます

多対多 多数の銀行取引明細書明細がグループ化され、多数のシステム・トランザクションに対して突合せされます

グループ化属性: 選択した照合タイプに基づいて、銀行取引明細書明細およびシステム・トランザクションをグループ化するために使用されます。選択した属性の組合せによって、照合基準として何を使用できるかも決まります。日付、トランザクション・タイプおよび突合せ参照は、グループ化属性として選択した後でのみ、照合基準として使用できます。次の表に、選択された照合タイプで必要なグループ化属性を示します。

照合タイプ 取引明細書明細のグループ化属性 システム・トランザクションのグループ化属性

1対1 該当なし 該当なし

1対多 該当なし グループ化属性が必要

多対1 グループ化属性が必要 該当なし

多対多 グループ化属性が必要 グループ化属性が必要

多対1照合では、グループ化属性を使用して銀行取引明細書明細をグループ化します。1対多照合では、グループ化属性を使用してシステム・トランザクションをグループ化します。次に、銀行取引明細書明細のグループ化に使用できる共通のグループ化属性を示します。

トランザクション日体系化支払参照トランザクション通貨トランザクション・タイプ突合せ参照トランザクション・コード相手方銀行口座

300

次に、システム・トランザクションのグループ化に使用できる共通のグループ化属性を示します。銀行預入番号トランザクション日ビジネス・ユニット相手方銀行口座相手方名仕訳バッチ名仕訳名支払ファイル識別子支払プロセス要求名支払指図識別子支払ファイル参照支払方法体系化支払参照入金バッチ番号入金区分突合せ照合日付突合せ参照送金バッチ番号トランザクション通貨トランザクション・タイプトランザクション・ソース

照合基準: 一般的に使用される照合属性のリストが含まれます。単に属性を選択して、選択した照合ルールにその属性を含めることができます。選択した属性によって、突合せ時に正しく照合される銀行取引明細書明細とシステム・トランザクションの間の照合条件が定義されます。

注意: 「突合せ照合ルールの作成」ページに提供されている照合タイプの設定は「1対1」で、「突合せ参照」、「日付」および「トランザクション・タイプ」のチェック・ボックスが使用可能になっています。照合タイプを「1対多」、「多対一」または「多対多」に変更すると、これらのチェック・ボックスは使用不可になります。

照合基準の属性は次のとおりです。金額日付突合せ参照トランザクション・タイプ

拡張照合基準: 銀行取引明細書明細とシステム・トランザクションを正常に照合するために満たす必要がある、追加の照合ロジックまたはフィルタリング条件を指定できます。次の点を考慮してください。

条件の作成時に「大/小文字の比較」チェック・ボックスを有効または無効にできます。基準で照合するように選択した場合は、式の両側のデータ型が同じで、相互に対応している必要があります。たとえば、「取引明細書.記帳日」属性を一方の側で選択した場合は、照合基準として「トランザクション日」を選択できます。「日付」は検索対象と同じデータ型であり、検索対象に対応しているデータ型です。リテラル式タイプの場合、オペランド値はデータベース値と一致している必要があります。たとえば、取引明細書.トランザクション・タイプ = ACH です

301

「条件の作成」ページで使用できる取引明細書属性とトランザクション属性のリストは、選択する照合タイプによって異なります。次の表に、共通の取引明細書属性とトランザクション属性の一部を示します。

取引明細書属性 トランザクション属性

取引明細書.口座サービス機関参照 トランザクション.銀行預入番号

取引明細書.入力追加情報 トランザクション.ビジネス・ユニット

取引明細書.記帳日 トランザクション.相手方名

取引明細書.小切手番号 トランザクション.相手方サイト

取引明細書.決済システム参照 トランザクション.仕訳バッチ名

取引明細書.契約ID トランザクション.仕訳明細番号

取引明細書.相手方銀行口座 トランザクション.仕訳名

取引明細書.顧客参照 トランザクション.支払ファイル参照

NA トランザクション.支払プロセス要求名

NA トランザクション.支払ファイル識別子

NA トランザクション.支払指図識別子

取引明細書.エンド・トゥ・エンドID トランザクション.入金バッチ番号

取引明細書.指示ID トランザクション.突合せ照合金額

取引明細書.突合せ照合金額 トランザクション.突合せ照合日付

取引明細書.突合せ参照 トランザクション.突合せ参照

取引明細書.体系化支払参照 NA

取引明細書.トランザクションID トランザクション.送金バッチ番号

NA トランザクション.体系化支払参照

取引明細書.トランザクション通貨 トランザクション.ステータス

取引明細書.トランザクション・タイプ トランザクション.トランザクション通貨

取引明細書.評価日 トランザクション.トランザクション日

NA トランザクション.トランザクション番号

NA トランザクション.トランザクション・ソース

NA トランザクション.トランザクション・タイプ

1つのルールで1つ以上のトランザクション・ソースを選択できます。次の点を考慮してください。

1対1または多対1の照合ルールで複数のソースが選択されている場合、自動突合せプログラムは選択されたソース全体で照合トランザクションを検索します。

302

1対多または多対多の照合ルールで複数のソースが選択されている場合、プログラムは最初に、選択されたソース全体で使用可能なすべてのトランザクションを検索し、データ・プール全体にグループ化ルールを適用します。つまり、取引明細書明細は、様々なソースのトランザクションを含むグループに対して突合せできます。グループに含まれるトランザクションが同じトランザクション・ソースのトランザクションになるようにするには、グループ化属性として「トランザクション・ソース」を指定します。注意資金管理では、ファイルベース・データ・インポートやOracle Fusion ADF Desktop Integrationなどのスプレッドシート・ベースのツールを使用した仕訳突合せ参照のインポートがサポートされています。必要な設定が完了すると、突合せ参照がアップロードされて仕訳明細に保存されます。

関連トピック

自動突合せ決済勘定の突合せの設定突合せ参照および仕訳明細

突合せルール・セットの概要銀行取引明細書突合せルール・セットは、照合ルールと許容範囲ルールのグループです。これらは銀行口座に割り当てられ、銀行取引明細書明細とトランザクションを突き合せるために使用されます。

ルールを作成するときには、次のことを考慮してください。

ルール・セットとルール・セット詳細を親子関係として構築します。各ルール・セットは、優先順位または順序が設定された1つ以上の照合ルールで構成されます。より高い突合せ成功率を達成するには、ルールを並べ替える必要があります。1対1のルールは、他のタイプのルールよりも順番を前にすることをお薦めします。最適な突合せ率を提供するには、指定したルールでどの程度正確に正しい銀行トランザクションに突合せできるかに応じて、順番を変更する必要があります。

たとえば、銀行が参照IDを提供するソースからのトランザクションは、突合せ率が高くなる可能性があります。これらのルールは、より小さい順序番号を設定して先頭に配置する必要があります。逆に、参照IDを持たないトランザクションは、重複したり、突合せ率が低くなる可能性があるため、より大きい順序番号を設定して末尾に配置する必要があります。

拒否された支払の自動突合せ

インポート済銀行取引明細書で報告された拒否済支払を自動的に突き合せるには、オプトイン機能「拒否された支払の自動突合せ」を有効にする必要があります。この機能を有効にするには、次のステップを実行します。

銀行トランザクション・コードでトランザクション・タイプを「戻し処理」として選択します。このトランザクション・コードおよび戻し処理インジケータを使用して、銀行取引明細書明細の拒否が識別されます。自動突合せプロセスによって拒否が識別され、元の決済済支払の突合せが取り消され、元の取引明細

303

書明細と拒否された取引明細書明細の突合せが行われます。

銀行取引明細書トランザクション・コードの概要銀行取引明細書トランザクション・コードは、報告されるトランザクションのタイプを識別するために銀行取引明細書明細で使用される内部コードです。これらは、次のように呼ばれることもあります。

トランザクション・コード取引明細書コード

次に、コードの例を示します。

115: ロックボックス預入

475: 支払済小切手

698: その他料金

Oracle Fusion Cash Managementは、これらのコードの単一のセットを保持し、外部から報告されたトランザクション・コードを他の形式からこの単一の正規化されたセットに変換します。コード・マップ・グループを使用して、外部データ・ファイルで報告されたトランザクション・コードを、アプリケーションで内部的に定義されたトランザクション・コードにマップできます。この構成は、Oracle Fusion Paymentsコード・マップ・グループの設定を介して行われます。

構成可能なBAI2トランザクション・コードのマッピング方法BAI2銀行取引明細書をインポートする場合、銀行取引明細書明細のフロー・インジケータ(DR/CR)は、その明細に関連付けられたトランザクション・コードによって決定されます。

構成可能なBAI2トランザクション・コードを標準BAI2コードにマップして、ファイルのインポート時に必要な取引明細書明細フロー・インジケータを導出できます。

構成可能なBAI2トランザクション・コードのマッピングこの例では、クレジット・コード856とデビット・コード868が、次のステップを使用してトランザクション・コードとしてマップされます。

1. 「設定および保守」作業領域で、次の項目に移動します。2. オファリング: 財務3. 機能領域: 「支払」または「顧客支払」4. タスク: コード・マップ・グループの管理5. 「名前」で「BAI2銀行取引明細書」を検索し、「編集」をクリックします。6. 「マッピング」で、「フィールド」に新規レコード「CE_TRX_CODE」を入力します。

304

7. 親のCE_TRX_CODEの場合、「フィールド」値に2行追加し、次のように入力します。

明細番号 入力値と出力値

明細1 入力値: 856、出力値: 275 (標準のCREDIT BAI2コード)を入力します。

明細2 入力値: 868、出力値: 575 (標準のDEBIT BAI2コード)を入力します。

8. 保存して閉じます。9. BAI2形式の銀行取引明細書をロードおよびインポートすると、次のようになります。

トランザクション・コード 結果

定義済入力値: 856 コード275でインポートされ、フロー・インジケータが「CREDIT」に設定されます。

定義済入力値: 868 コード575でインポートされ、フロー・インジケータが「DEBIT」に設定されます。

銀行取引明細書トランザクション作成ルールの概要銀行取引明細書トランザクション作成ルールは、未突合せ銀行取引明細書明細を識別し、トランザクションを作成して計上するために、Oracle Fusion Cash Managementで使用されます。

作成されるトランザクションの属性と特性の一部を指定して、銀行取引明細書トランザクション作成ルールを構成します。ルールを構成するときには、次のことを考慮してください。

別個のビジネス・オブジェクトとして作成します。「銀行口座の管理」ページで銀行口座に割り当てます。処理する順番に並べてグループ化します。

銀行口座に対する順序付けされたルールのグループによって、銀行取引明細書トランザクション作成プログラムの実行時に使用される銀行口座ルール・セットが構成されます。

銀行取引明細書トランザクション作成プログラムを実行することで銀行取引明細書トランザクション作成ルールを処理し、未突合せ銀行取引明細書明細からトランザクションを作成します。このプログラムは、銀行手数料、手数料、利息などの最初の通知項目に対するトランザクションを作成して計上するために使用されます。プログラムを実行する前に次を実行する必要があります。

銀行取引明細書の自動突合せを実行します。銀行取引明細書に対して任意の手動突合せを実行します。

これにより、アプリケーションにすでにトランザクションが記録されている銀行取引明細書明細から外部トランザクションが作成されなくなります。

305

スプレッドシートでの銀行、支店および口座の作成

資金管理の高速実装の概要Microsoft Excelテンプレートを使用して、次の設定オブジェクトを高速実装します。

銀行銀行支店銀行口座

「機能設定マネージャ」タスク

設定オブジェクトのデータを迅速に作成するために実行する必要がある機能設定マネージャ・タスクを次に示します。これらのタスクにアクセスするには、「高速実装のための財務構成の定義」タスク・リストを含む実装プロジェクトを作成します。

スプレッドシートでの銀行、支店および口座の作成: 高速実装Excelスプレッドシートのテンプレートをダウンロードします。このスプレッドシートに銀行、支店および銀行口座のデータを入力して、ロードするデータ・ファイルを生成します。銀行、支店および口座のアップロード: パラメータとしてアップロードされるデータ・ファイルを使用して、「銀行、支店および口座のアップロード」プロセスを起動します。前のタスクで生成されたデータ・ファイルをアップロードする必要があります。

データの準備

銀行、支店および口座情報を準備して、スプレッドシート・テンプレートに入力します。

銀行情報には、国、名前および番号が必要となります。支店情報には、名前、番号、BICコードおよびカナ名が必要となります。口座情報には、名前、番号、通貨、法的エンティティ、タイプおよびIBANが必要となります。

スプレッドシートでのデータの準備が完了したら、銀行、支店および口座ファイルの生成ボタンをクリックします。生成されたXMLファイルを保存します。

データのロード

次のステップを使用してデータを読み込みます。

「設定および保守」作業領域で、「高速実装のための財務構成の定義」タスク・リストを含む実装プロジェクトを作成します。実装プロジェクトから、「銀行、支店および口座のアップロード」タスクに移動します。このタスクでは、「銀行、支店および口座のアップロード」プロセスを起動します。前に保存したXMLファイルを選択して、プロセスを発行します。プロセスが正常に完了したことをプロセス・モニターで確認します。作成された銀行、支店および口座をレビューします。

306

ベスト・プラクティス

推奨されるベスト・プラクティスは次のとおりです。

各銀行口座の法的エンティティを決定します。法的エンティティはプライマリ元帳に関連付けられている必要があります。各銀行口座の用途(買掛管理、売掛管理、あるいはその両方)を決定します。各銀行口座の資金および資金決済勘定を決定します。勘定体系に基づいて勘定科目組合せ全体を入力します。たとえば、01-000-1110-0000-000です。

関連トピック

電子銀行取引明細書の処理方法

資金ポジションおよび資金予測の設定

資金管理向けにOracle Fusion Paymentsを設定する方法非定型支払を行うには、次を実行する必要があります。

Oracle Fusion Cash Managementで受取人を作成します。Oracle Fusion Paymentsで、資金管理の「使用ルール」タブにある「支払方法」をレビューします。Oracle Fusion Paymentsで支払方法デフォルト・ルールをレビューし、資金管理支払方法の優先度を適宜に設定します。

資金管理での受取人の作成は、調達でサプライヤを設定することとは別のタスクです。資金管理で行われた設定は、アプリケーションから非定型支払を行うためにのみ使用されます。また、支払を正常に行うには、支払内の設定をレビューおよび編集する必要があります。

資金管理での受取人の作成

1. 資金管理で受取人を作成します。次の受取人情報を入力します。

フィールド 必須 説明

名前 はい 受取人の名前。

税務登録番号

いいえ 受取人の摘要。

税務登録番号

いいえ 税務当局によって受取人に割り当てられた一意識別子。

アクティブ いいえ、ただし、お薦めします。

受取人がアクティブか非アクティブかを示すチェック・ボックス。

2. 銀行口座情報を作成します。次の銀行口座情報を入力します。

フィールド 説明

307

国 銀行口座が属する銀行の国。

アカウント番号 受取人銀行口座の銀行口座番号。

通貨 受取人銀行口座の通貨

口座タイプ 受取人銀行口座のタイプ。当座預金や普通預金など。

検証桁 口座番号検証。

口座名義 銀行口座名義人の名前。

セカンダリ口座参照 英国の住宅金融共済組合のロール番号などの追加の口座参照。

銀行 受取人銀行の名前。

銀行支店 受取人銀行支店の名前。

ルーティング・トランジット番号

電子転送のルーティング・トランジット番号。

BICコード 銀行または銀行支店を識別するためにSWIFTで使用されるコード。

アクティブ 銀行口座がアクティブであることを示すために選択します。デフォルトは、「アクティブ」に設定されています。

3. 「保存してクローズ」ボタンをクリックして、情報を保存します。

資金管理向けのOracle Fusion Paymentsでの使用ルールの設定

1. Oracle Fusion Paymentsおよび「支払方法の作成」ページにナビゲートします。2. 「名前」、「コード」および「日付: 自」必須フィールドに入力します。3. 「使用ルール」タブを選択します。4. 「資金管理」タブを選択します5. 「資金管理での使用を許可」チェック・ボックスを選択します。6. 「すべて」または「特定」を選択します。7. 資金管理向けに用意されている支払プロセス・トランザクション・タイプをレビューします。適切な支払タイプを適用します。有効な値は次のとおりです。

銀行口座振替非定型支払

8. Oracle Fusion Paymentsで支払方法デフォルト・ルールをレビューし、資金管理支払方法の優先度を適宜に設定します。

関連トピック

支払方法支払方法デフォルト使用ルール

資金ポジションおよび資金予測の設定方法

308

次のものを使用して、資金ポジションおよび資金予測レポート要件を設定します。

資金ポジションおよび資金予測オプションの指定資金ポジションおよび資金予測トランザクション・グループ化の管理

資金ポジションおよび資金予測オプションの指定

オプション・ページを使用して、Essbaseキューブにデータを転送するために使用される抽出期間を定義します。トランザクション日がその期間内にあるトランザクションがキューブに抽出されます。異なるGL会計カレンダを選択して、キューブ内で時間ディメンション構造をレイアウトすることもできます。

次のオプションを構成します。

フィールド名 使用可能な値デフォルト値

抽出期間 過去3か月過去6か月過去1年過去2年過去3年

過去2年

レポート通貨 アプリケーションで定義されている通貨のリスト USD -USドル

残高コード 「当方残高コード」参照(LOV) クローズ記帳済

残高日しきい値日数

銀行取引明細書がないと報告されるまでの定義済日数 2

トランザクション・カレンダ

アプリケーションで定義されているトランザクション・カレンダのリストで、定義されていない場合は、毎日(7)が営業日とみなされます。

デフォルトなし

期間 アプリケーションで定義されている会計カレンダのリスト デフォルトなし

注意: キューブを作成してロックすると、このページで更新が無効になります。資金ポジション・データ削除プログラムを発行してキューブ内の詳細を消去するまで、キューブを更新できません。

資金ポジションおよび資金予測トランザクション・グループ化の管理

このページから、資金ポジションおよび資金予測の構成可能なディメンションを作成または編集します。資金ポジション・ディメンションの作成または資金ポジション・ディメンションの編集ページにアクセスするには、「資金ポジションおよび資金予測トランザクション・グループ化の管理」権限が必要です。

アプリケーションで定義された構成可能なディメンションを検索します。会社固有の要件を満たすように構成可能なディメンションを作成しますレポート要件を満たすように、構成可能なディメンションを変更および編集します。摘要の入力はオプションですが、お薦めします。

309

次の表に、入力を完了するフィールドを示します。

フィールド名 説明

名前 必須であり、一意である必要があります

アプリケーション 必須であり、有効な値は「Oracle Fusion Applications」または「その他」です。

ソース 必須であり、次の値を指定できます。買掛/未払金請求書買掛/未払金支払売掛/未収金入金売掛/未収金トランザクション銀行取引明細書外部資金トランザクション

ソース表 選択したアプリケーションおよびソースからの表のリスト

ソース列 選択したソース表からの列のリスト。

注意: キューブの作成およびロック後は、このページを更新できません。更新を行うには、資金ポジション・データ削除プログラムを発行して、キューブ内の詳細を消去する必要があります。

関連トピック

資金ポジションおよび資金予測資金ポジション資金予測に関する考慮事項

銀行口座検証

国別の銀行口座検証: アルバニアからグアテマラまでここでは、Oracle Fusion Cash Managementで実行される国固有の銀行口座検証ルールの概要について説明します。

次の国には国固有の検証が存在します。

アルバニアアルジェリアアンドラアルゼンチンオーストラリア

オーストリア

アゼルバイジャン

310

バーレーンベラルーシ

ベルギー

ボスニア・ヘルツェゴビナ

ブラジルイギリス領バージン諸島

ブルガリア

カナダ

コロンビアコスタリカ

クロアチア

キプロス

チェコ共和国

デンマークドミニカ共和国エジプトエルサルバドル

エストニアフェロー諸島

フィンランド

フランス

フランス領ギアナジョージア

ドイツ

ジブラルタル

ギリシャグリーンランド

グアドループグアテマラ

銀行口座を入力する際、様々な国に、フォーマットや次の関連フィールドのコンテンツを制御する特定のルールを設定できます。

1. 銀行コード2. 支店番号3. 口座番号4. 検証桁5. IBAN

311

銀行コード、支店番号、口座番号、検証桁およびIBANに関連する国固有の検証を使用不可にするには、「国固有の銀行検証の使用不可」プロファイル・オプションを使用します。このプロファイル・オプションはサイトまたはユーザー・レベルで設定できます。サイト・レベルでは、プロファイルはデフォルト値「いいえ」に事前定義されています。プロファイルが「はい」に設定されている場合、これらの検証は実行されません。一意の銀行、支店、口座および銀行口座番号の必須要件についてのチェックは、このプロファイルによる影響を受けません。

アルバニア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

アルジェリア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。26文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。

312

最初の2文字は文字です。3番目と4番目の文字は数字です。

アンドラ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは24文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

アルゼンチン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード オプション

支店番号 オプション

口座番号 必須長さは最大22文字である必要があります。スペースとハイフンは使用できます。

検証桁 オプション

IBAN オプション

オーストラリア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

313

フィールド ルール

銀行コード

オプション入力する場合、長さは2桁または3桁の数字である必要があります。

支店番号

必須「支店番号」と「銀行コード」を組み合せた長さが6桁の数字である必要があります。したがって、有効な長さの値(3、4、6)は、「銀行コード」(3、2、0)によって決まります。このフィールドは「BSB」としてラベル付けされます。

口座番号

必須長さは5文字から10文字の間である必要があります。口座通貨がオーストラリア・ドルの場合、口座番号は数字である必要があります。外貨の場合、英数字の値が許容されます。

検証桁

オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

オーストリア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション長さは5桁の数字である必要があります。

支店番号

オプション長さは5桁の数字である必要があります。

口座番号

必須長さは4桁から11桁の間の数字である必要があります。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは20文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。

314

最初の2文字は文字です。3番目と4番目の文字は数字です。

アゼルバイジャン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

バーレーン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。22文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

315

ベラルーシ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ベルギー

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須長さは12桁の数字である必要があります。999-9999999-99というフォーマットにする必要があります。口座番号に検証アルゴリズムが適用されます。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは16文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。

316

最初の2文字は文字です。3番目と4番目の文字は数字です。

口座番号の検証アルゴリズム

1. 入力検証桁CD1は、口座番号の最後の2桁です2. 計算検証桁CD2は、口座番号の最初の2つのセクションを連結し、それを97で除算して余りを計算することによって導出されます。余りが0になった場合は、計算検証桁は97になります。

3. 入力検証桁(CD1)と計算検証桁(CD2)が等しくなれば口座番号は有効とみなされ、そうでなければ検証は失敗になります。

4. さらに、計算検証桁が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が必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは20文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ブラジル

317

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード 必須長さは最大3桁の数字である必要があります。長さが3未満の場合、先行するゼロを必要な数だけ前に付けて3桁の数字に変換されます。

支店番号 必須長さは最大5桁の数字である必要があります。

口座番号 必須

検証桁 オプション

会社コード オプション。口座作成フォームに入力します。入力する場合、長さは最大15桁の数字である必要があります。

セカンダリ口座参照

このフィールドは「会社コード」としてラベル付けされます。

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。29文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

イギリス領バージン諸島

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。24文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

318

ブルガリア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは22文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

カナダ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプションこのフィールドは「ルーティング・トランジット番号」としてラベル付けされます。

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。

319

最初の2文字は文字です。3番目と4番目の文字は数字です。

コロンビア

コロンビアの場合、次の表に示すように、「銀行コード」、「支店番号」、「口座番号」または「検証桁」フィールドの検証は行われません。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

納税者ID

オプション長さは最大15桁の数字(納税者IDの14桁に検証桁の最後の桁を加えたもの)である必要があります。国内で一意です。顧客、サプライヤおよび会社で納税者IDの相互検証が行われます。納税者IDが顧客、サプライヤまたは会社で使用されている場合は、顧客名、サプライヤ名または会社名を銀行名と照合する必要があります。納税者IDには検証桁が適用されます。

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

納税者IDの検証アルゴリズム

次の表に示すように、最初の15桁に関連ファクタが乗算されます。

桁 ファクタ

1st 71

2nd 67

3rd 59

4th 53

5th 47

6th 43

320

7th 41

8th 37

9th 29

10th 23

11th 19

12th 17

13th 13

14th 7

15th 3

1. これらの15個の積を加算し、合計を11で除算します。2. 余りが1または0である場合は、検証桁はそれぞれ1または0になります。3. 余りが1または0でない場合は、余りから11が減算され、その値が検証桁になります。

コスタリカ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。22文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

クロアチア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィー

321

ルド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは21文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

キプロス

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは28文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

チェコ共和国

322

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは24文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

デンマーク

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

長さは最大10桁の数字である必要があります。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは18文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されま

323

せん。最初の2文字は文字です。3番目と4番目の文字は数字です。

ドミニカ共和国

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

エジプト

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。27文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

324

エルサルバドル

.

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

エストニア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは20文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

325

3番目と4番目の文字は数字です。

フェロー諸島

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。18文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

フィンランド

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション入力する場合、6桁の数字である必要があります。

口座番号

必須長さは8桁から14桁の間の数字である必要があります。口座番号に検証アルゴリズムが適用されます。

検証桁

オプション入力する場合、1桁の数字である必要があります。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。

326

長さは18文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

口座番号の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桁の数字に変換されます。同じ例を使用すると、検証値の2つ目の部分は0000009として作成されます。検証値は3つの部分を連結して構成されます。つまり、この例では、検証値は12345680000009として構成されます。

合計は検証値に基づいて算出されます。構成された検証値の最初の2桁に応じて、実行される計算が異なります。

検証値の最初の2桁が88である場合:

327

フィンランド政府は次のファクタ表を提供しています。検証値の8桁目から13桁目に関連ファクタが乗算されます。各結果を加算して合計が算出されます。

桁 ファクタ

8th 1

9th 3

10th 7

11th 1

12th 3

13th 7

検証値88345600000089を使用した例: 指定の桁に指定のファクタが乗算されます。

桁 値 ファクタ 結果

8桁目 0 1 0

9桁目 0 3 0

10桁目 0 7 0

11桁目 0 7 0

12桁目 0 3 0

13桁目 8 7 56

合計 N/A N/A 56

この結果、この例の算出合計は56になります。

次のいずれにも該当しない場合、テストは不合格になります。

検証値の14桁目は、10から算出合計の最後の桁を減算した値と等しくなる必要があります。検証値が88345600000089である場合、算出合計の最後の桁は6です。つまり、10 - 6 = 4となります。したがって、検証値の14桁目は4になる必要があります。この場合、14桁目は9であるため、テストは不合格になります。検証値の14桁目と算出合計の最後の桁がどちらも0である必要があります。同じ例を使用すると、どちらの値も0ではないため、テストは不合格になります。

検証値の最初の2桁が88でない場合は、各奇数桁に対する次の計算値に偶数桁の値を加算することによって、最初の13桁の合計が算出されます。

桁に2を乗算します。結果を10で除算します。その結果の整数部と余りを加算します。

口座番号123456800000089を使用した例

328

桁 値 乗算(a) 除算(b) 整数部 余り 結果

1st 1 2 0.2 0 2 2

2nd 2 N/A N/A N/A N/A 2

3rd 3 6 0.6 0 6 6

4th 4 N/A N/A N/A N/A 4

5th 5 10 1 1 0 1

6th 6 N/A N/A N/A N/A 6

7th 0 16 1.6 1 6 0

8th 0 N/A N/A N/A N/A 0

9th 0 0 0 0 0 0

10th 0 N/A N/A N/A N/A 0

11th 0 0 0 0 0 0

12th 0 N/A N/A N/A N/A 0

13th 8 16 1.6 1 6 7

合計 N/A N/A N/A N/A N/A 28

その後、算出合計が次のプロセスにより変換され、変換後の値を使用して口座番号が有効かどうか判断されます。

1. 算出合計に9を加算します。2. 結果を10で除算します。3. 結果の整数部に10を乗算します。4. 結果から元の算出合計を減算します。

つまり、算出合計282は次のように2に変換されます。

1. 28 + 9 = 372. 37/10 = 3.7.結果の整数部 = 33. 3 * 10 = 304. 30 - 28 = 2

この数字と口座番号の14桁目が比較されます。一致すればテストに合格し、そうでなければ不合格になります。

この例では、口座番号の14桁目が9であるため、テストは失敗します。14桁目が2であれば、テストに合格します。

フランス

検証ルール

329

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

必須長さは最大5桁の数字である必要があります。長さが5未満の場合、先行するゼロを必要な数だけ前に付けて5桁の数字に変換されます。

支店番号

必須長さは最大5桁の数字である必要があります。長さが5未満の場合、先行するゼロを必要な数だけ前に付けて5桁の数字に変換されます。

口座番号

必須長さは最大11桁の数字である必要があります。特殊文字とスペースは使用できません

検証桁

オプション入力する場合、長さは最大2桁の数字である必要があります。検証桁に検証アルゴリズムが適用されます。

口座タイプ

このフィールドは「預金種目」としてラベル付けされます。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは27文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

検証桁の検証アルゴリズム

検証桁(CD1)は、次の方法で口座番号、銀行コードおよび支店番号から計算されます。これは、検証桁妥当性テストの基準として使用されます。

CDI

検証アルゴリズム用に、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

330

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が必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは34文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

331

ジョージア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは24文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ドイツ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは8桁の数字である必要があります。

支店番号

オプション入力する場合、長さは8桁の数字である必要があります。「銀行コード」と「支店番号」が入力されている場合、両方の値が一致する必要があります。

口座番号

必須長さは最大10桁の数字である必要があります。

検証桁

オプション検証桁の値を入力する場合、口座番号の最後の桁と一致する1桁の数字を入力する必要があります。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは22文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。

332

最初の2文字は文字です。3番目と4番目の文字は数字です。

ジブラルタル

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは23文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ギリシャ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは3桁の数字である必要があります。

支店番号

オプション入力する場合、長さは4桁の数字である必要があります。

口座番号

必須長さは8文字から16文字の間の英数字である必要があります。

検証桁

オプション値を入力する場合、1桁の数字である必要があります。

333

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは27文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

グリーンランド

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。18文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

グアドループ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証 オプション

334

桁

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは34文字である必要があります。先頭と末尾のスペースは無視されます。中間でのスペースの使用は許可されていません。最初の2文字は文字です。3番目と4番目の文字は数字です。

グアテマラ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

国別の銀行口座検証: ハンガリーからノルウェーまでここでは、Oracle Fusion Cash Managementで実行される国固有の銀行口座検証ルールの概要について説明します。

次の国には国固有の検証が存在します。

ハンガリー

アイスランドインド

アイルランド

イスラエルイランイラク

335

イタリア象牙海岸

日本ヨルダンカザフスタンコソボ

クウェート

ラトビアレバノン

リヒテンシュタイン

リトアニア

ルクセンブルク

マルタ

マルティニークモーリタニア

モーリシャス

マヨット

メキシコモルドバ

モナコ

モンテネグロモロッコ

オランダ

ニュージーランド

ノルウェー

銀行口座を入力する際、様々な国に、フォーマットや次の関連フィールドのコンテンツを制御する特定のルールを設定できます。

1. 銀行コード2. 支店番号3. 口座番号4. 検証桁5. IBAN

銀行コード、支店番号、口座番号、検証桁およびIBANに関連する国固有の検証を使用不可にするには、「国固有の銀行検証の使用不可」プロファイル・オプションを使用します。このプロファイル・オプションはサイトまたはユーザー・レベルで設定できます。サイト・レベルでは、プロファイルはデフォルト値「いいえ」に事前定義されています。プロファイルが「はい」に設定されている場合、これらの検証は実

336

行されません。一意の銀行、支店、口座および銀行口座番号の必須要件についてのチェックは、このプロファイルによる影響を受けません。

ハンガリー

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは28文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

アイスランド

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは4桁の数字である必要があります。長さが4未満の場合、先行するゼロを必要な数だけ前に付けて4桁の数字に変換されます。

支店番号

オプション入力する場合、長さは4桁の数字である必要があります。「銀行コード」と「支店番号」が入力されている場合、両方の値が一致する必要があります。

口座番号

必須長さは最大18桁の数字である必要があります。長さが18未満の場合、先行するゼロを必要な数だけ前に付けて18桁の数字に変換されます。口座番号に検証アルゴリズムが適用されます。

337

検証桁

オプション検証桁の値を入力する場合、口座番号の17桁目と一致する1桁の数字を入力する必要があります。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは26文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

口座番号の検証アルゴリズム

1. 検証アルゴリズムは口座番号(9桁目から16桁目まで)に対して実行されます。これらの各桁に次の表に示すファクタが乗算されます。

桁 ファクタ

9th 3

10th 2

11th 7

12th 6

13th 5

14th 4

15th 3

16th 2

これらの積を加算し、合計を11で除算します。この除算の余りを11から減算し、計算検証桁を導出します。余りが0になった場合は、計算検証桁は0になります。

この計算検証桁と入力検証桁(口座番号の17桁目)が一致する必要があり、一致しない場合、口座番号は無効です。

インド

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプションこのフィールドは「IFSCコード」としてラベル付けされます

338

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

アイルランド

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは6桁の数字である必要があります。

支店番号

オプション入力する場合、長さは6桁の数字である必要があります。「銀行コード」と「支店番号」が入力されている場合、両方の値が一致する必要があります。

口座番号

必須長さは8桁の数字である必要があります。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは22文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

イスラエル

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

必須

339

入力する場合、長さは最大2桁の数字である必要があります。

支店番号 必須長さは3桁の数字である必要があります。

口座番号 必須長さは最大13桁の数字である必要があります。スペースは使用できません。

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。23文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

イラン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。26文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

イラク

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

340

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。23文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

イタリア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

必須長さは最大5桁の数字である必要があります。

支店番号

必須長さは最大5桁の数字である必要があります。

口座番号

必須長さは最大12文字の英数字である必要があります。長さが12未満の場合、先行するゼロを必要な数だけ前に付けて12桁の数字に変換されます。

検証桁

オプション入力する場合、長さは1文字の英数字である必要があり、検証桁に検証アルゴリズムが適用されます。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは27文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

検証桁の検証アルゴリズム

検証桁は、銀行コード、支店番号および口座番号の検証に使用されます。これらを連結して22文字の文字列が生成されます。

次の表に示すように、各文字には、文字列の中でその文字が奇数番目か偶数番目か応じて値が割り当てられます。

341

偶数番目の値 奇数番目の値

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で除算します。

この除算の余りが次の表に従ってアルファベットに変換されます。

変換アルゴリズム

342

計算 計算 計算

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 N/A

この値とユーザーが入力した検証桁が一致する必要があり、一致しない場合、検証桁の検証は失敗になります。

象牙海岸

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

日本

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィール

343

ド ルール

銀行コード

必須長さは4桁の数字である必要があります。

銀行名カナ

オプション

支店番号 必須長さは3桁の数字である必要があります。

カナ支店名

オプション

口座番号 必須

口座タイプ

必須このフィールドは「預金種目」としてラベル付けされます。

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ヨルダン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。30文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

カザフスタン

344

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。20文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

コソボ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。20文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

クウェート

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

345

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須長さは最大22文字である必要があります。スペースとハイフンは使用できます。

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます30文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

ラトビア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは21文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

レバノン

検証ルール

346

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

リヒテンシュタイン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは21文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

リトアニア

検証ルール

347

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは20文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ルクセンブルク

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは3桁の数字である必要があります。

支店番号

オプション入力する場合、長さは3桁の数字である必要があります。「銀行コード」と「支店番号」が入力されている場合、両方の値が一致する必要があります。

口座番号

必須長さは最大13文字である必要があります。

検証桁

オプション入力する場合、長さは2桁の数字である必要があります。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは20文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されま

348

せん。最初の2文字は文字です。3番目と4番目の文字は数字です。

マルタ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは31文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

マルティニーク

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

349

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは34文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

モーリタニア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。27文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

モーリシャス

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証 オプション

350

桁

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは30文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

マヨット

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは34文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

メキシコ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード オプション

支店番号 オプション

口座番号 必須

351

長さは10桁から11桁の間の数字である必要があります。スペースとハイフンは使用できます。

検証桁 オプション

IBAN オプション

セカンダリ口座参照 オプション入力する値の条件は次のとおりです。

18桁数値

モルドバ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。24文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

モナコ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

352

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます27文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

モンテネグロ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは22文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

モロッコ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

353

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

オランダ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須次の2つのタイプの口座番号が検証されます。銀行口座番号が数字あり、次のいずれかに当てはまる場合、その銀行口座はPostまたはGiro口座とみなされます。

長さが7桁以下プリフィクス000付きプリフィクスPまたはG付き

PostまたはGiro口座に対しては検証桁検証は行われません。その他の口座番号については、長さが9桁または10桁の数字である必要があります。口座番号に検証アルゴリズムが適用されます。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは18文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

PostまたはGiro以外の口座番号の検証アルゴリズム

354

1. 長さが10未満の場合、先行するゼロを必要な数だけ前に付けて10桁の数字に変換されます。2. オランダ政府はこれらの10桁について次のファクタ表を提供しています。

桁 ファクタ

1st 10

2nd 9

3rd 8

4th 7

5th 6

6th 5

7th 4

8th 3

9th 2

10th 1

これらを乗算し、その積の合計が4に算出されます。

得られた結果が11で完全に割り切れる場合(つまり、11での除算で余りがない場合)、テストは合格になり、それ以外の場合、入力された口座番号は無効です。

ニュージーランド

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

必須長さは2桁の数字である必要があります。

支店番号 必須長さは4桁の数字である必要があります。このフィールドは「BSB」としてラベル付けされます。

口座番号 必須長さは最大8桁の数字である必要があります。口座サフィクスは、2桁から4桁までの数字である必要があります。

検証桁 オプション

摘要 このフィールドは「参照」としてラベル付けされます。

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。

355

34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ノルウェー

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須長さは11桁の数字である必要があります。口座番号の5桁目と6桁目が00でない場合、口座番号に検証アルゴリズムが適用されます。

たとえば、口座番号1234001234には検証アルゴリズムは適用されませんが、口座番号02056439653には口座番号の検証アルゴリズムで説明したように、この表に従って検証アルゴリズムが適用されます。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは15文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

口座番号の検証アルゴリズム

1.検証桁は、口座番号の最後の桁(つまり、11桁目)に設定されます。たとえば、口座番号が02056439653である場合、検証桁は3に設定されます。

2.ノルウェー政府は次のファクタ表を提供しています。

桁 ファクタ

1st 5

2nd 4

3rd 3

4th 2

356

5th 7

6th 6

7th 5

8th 4

9th 3

10th 2

口座番号の最初の10桁に関連ファクタが乗算されます。各結果を加算して合計が算出されます。

3.口座番号02056439653を使用した例

各桁に指定のファクタを乗算します。次の表は、検証を決定するファクタを示しています。

桁 値 ファクタ 結果

1st 0 5 0

2nd 2 4 8

3rd 0 3 0

4th 5 2 10

5th 6 7 42

6th 4 6 24

7th 3 5 15

8th 9 4 36

9th 6 3 18

10th 5 2 10

合計 N/A N/A 163

この結果、この例の算出合計は163になります。

4.算出合計を検証桁に加算します。この例では、163 + 3 = 166になります。

5.結果を11で除算します。166 / 11 = 15 6になります。

6.余りを導出します。166 - (11 * 15) = 1になります。

7.余りが0になった場合、検証は成功になり、それ以外の場合、検証は失敗になります。

8.この例では、余りが1になるため、口座番号の検証は失敗になります。口座番号の11桁目が2 (つまり、検証桁が2)であれば、余りは165 - (11 * 15) = 0になるため、口座番号の検証は成功です。

357

国別の銀行口座検証 パキスタンからアメリカ合衆国までここでは、Oracle Fusion Cash Managementで実行される国固有の銀行口座検証ルールの概要について説明します。

次の国には国固有の検証が存在します。

パキスタンパレスチナポーランド

ポルトガルカタール

レユニオン

ルーマニア

サンバルテルミーセントルシアサンマリノ

サンマルタン

サンピエール・ミクロン

サウジアラビア

セルビア

セルビア・モンテネグロセネガルセーシェル

シンガポール

スロバキア

スロベニア

スペイン

スウェーデン

スイス

マケドニア旧ユーゴスラビア共和国

チュニジア

トルコウクライナ

アラブ首長国連邦

イギリス

アメリカ合衆国

:

358

銀行口座を入力する際、様々な国に、フォーマットや次の関連フィールドのコンテンツを制御する特定のルールを設定できます。

1. 銀行コード2. 支店番号3. 口座番号4. 検証桁5. IBAN

銀行コード、支店番号、口座番号、検証桁およびIBANに関連する国固有の検証を使用不可にするには、「国固有の銀行検証の使用不可」プロファイル・オプションを使用します。このプロファイル・オプションはサイトまたはユーザー・レベルで設定できます。サイト・レベルでは、プロファイルはデフォルト値「いいえ」に事前定義されています。プロファイルが「はい」に設定されている場合、これらの検証は実行されません。一意の銀行、支店、口座および銀行口座番号の必須要件についてのチェックは、このプロファイルによる影響を受けません。

パキスタン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。24文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

パレスチナ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

359

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。29文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

ポーランド

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは8桁の数字である必要があります。

支店番号

オプション入力する場合、長さは8桁の数字である必要があります。「銀行コード」と「支店番号」が入力されている場合、両方の値が一致する必要があります。

口座番号

必須長さは最大16文字の英数字である必要があります。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは28文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ポルトガル

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

必須長さは4桁の数字である必要があります。

360

支店番号

必須長さは4桁の数字である必要があります。

口座番号

必須長さは最大11桁の数字である必要があります。

検証桁

オプション長さは2桁の数字である必要があります。入力する場合、検証桁に検証アルゴリズムが適用されます。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは25文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

検証桁の検証アルゴリズム

検証桁(CD1)は、銀行コード、支店番号および口座番号の3つの数字を連結することによって構成されます。たとえば、銀行コードが1234、支店番号が5678、口座番号が12345678901であるとします。この場合、CD1は1234567812345678901として設定されます。ポルトガル政府は次のファクタ表を提供しています。

桁 ファクタ

1st 73

2nd 17

3rd 89

4th 38

5th 62

6th 45

7th 53

8th 15

9th 50

10th 5

11th 49

12th 34

13th 81

14th 76

361

15th 27

16th 90

17th 9

18th 30

19th 3

作成された検証桁(CD1)の19桁に関連ファクタが乗算されます。各結果を加算して合計が算出されます。

CD1の値を使用した例:

桁 値 ファクタ 結果

1st 1 73 73

2nd 2 17 34

3rd 3 89 267

4th 4 38 152

5th 5 62 310

6th 6 45 270

7th 7 53 371

8th 8 15 120

9th 1 50 50

10th 2 5 10

11th 3 49 147

12th 4 34 136

13th 5 81 405

14th 6 76 456

15th 7 27 189

16th 8 90 720

17th 9 9 81

18th 0 30 0

19th 1 3 3

合計 N/A N/A 3794

結果を97で除算します。3794 / 97 = 39になります余りを導出します。3794 - (39 * 97) = 11になります

362

97から余りを減算してCD1を導出します。97 - 11 = 86になります。つまり、この例ではCD1 = 86です。CD1の計算値とユーザーが入力した検証桁が一致しない場合、検証桁の検証は失敗になります。この例では、ユーザーが入力した検証桁が86でないかぎり、検証は失敗になります。

カタール

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。29文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

レユニオン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます

363

34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ルーマニア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは24文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

サンバルテルミー

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証

364

桁オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

セントルシア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。32文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

サンマリノ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

365

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。27文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

サンマルタン(フランス領)

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

サンピエール・ミクロン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

366

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

サウジアラビア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは最大4文字である必要があります。

支店番号 オプション

口座番号 必須長さは最大25文字である必要があります。

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます24文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

セネガル

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

367

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。28文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

セルビア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須。

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは22文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

セルビア・モンテネグロ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

368

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

セーシェル

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。31文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

シンガポール

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

必須長さは4桁の数字である必要があります。

支店番号 必須長さは3桁の数字である必要があります。

口座番号 必須

検証桁

369

オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

スロバキア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます24文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

スロベニア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

370

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます19文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

スペイン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

必須長さは最大4桁の数字である必要があります。銀行コードが4桁未満の場合、先行するゼロを必要な数だけ前に付けて4桁の数字に変換されます。

支店番号

必須長さは最大4桁の数字である必要があります。銀行コードが4桁未満の場合、先行するゼロを必要な数だけ前に付けて4桁の数字に変換されます。

口座番号

必須長さは10桁の数字である必要があります。

検証桁

オプション入力する場合、長さは最大2桁の数字である必要があります。検証桁に検証アルゴリズムが適用されます。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは24文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

検証桁の検証アルゴリズム

次の方法により、検証桁CD1が銀行コードと支店番号から、検証桁CD2が口座番号からそれぞれ計算されます。これらが検証桁妥当性テストの基準として使用されます。

371

CD1

1.銀行コードに対して、スペイン政府は次のファクタ表を提供しています。

桁 ファクタ

1st 4

2nd 8

3rd 5

4th 10

銀行コードの4桁に関連ファクタが乗算されます。各結果を加算して合計が算出されます。

銀行コード1234を使用した例:

各桁に指定のファクタを乗算します。

桁 値 ファクタ 結果 桁 値 ファクタ 結果 桁 値 ファクタ 結果 桁 値 ファクタ 結果

1st 1 4 4

2nd 2 8 16

3rd 3 5 15

4th 4 10 40

合計 N/A N/A 75

この結果、この例の算出合計は75になります。

2.支店番号に対して、スペイン政府は次のファクタ表を提供しています。

桁 ファクタ

1st 9

2nd 7

3rd 3

4th 6

支店番号の4桁に関連ファクタが乗算されます。各結果を加算して合計が算出されます。

支店番号5678を使用した例:

各桁に指定のファクタを乗算します。

桁 値 ファクタ 結果

1st 5 9 45

2nd 6 7 42

372

3rd 7 3 21

4th 8 6 48

合計 N/A N/A 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.口座番号に対して、スペイン政府は次のファクタ表を提供しています。

桁 ファクタ

1st 1

2nd 2

3rd 4

4th 8

5th 5

6th 10

7th 9

8th 7

9th 3

10th 6

口座番号の10桁に関連ファクタが乗算されます。各結果を加算して合計が算出されます。

口座番号1234567890を使用した例:

各桁に指定のファクタを乗算します。

桁 値 ファクタ 結果

373

1st 1 1 1

2nd 2 2 4

3rd 3 4 12

4th 4 8 32

5th 5 5 25

6th 6 10 60

7th 7 9 63

8th 8 7 56

9th 9 3 27

10th 0 6 0

合計 N/A N/A 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が一致しないため、検証桁は無効です。

スウェーデン

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

374

フィールド ルール

銀行コード

オプション入力する場合、長さは4桁から5桁の間の数字である必要があります。

支店番号

オプション入力する場合、長さは4桁から5桁の間の数字である必要があります。「銀行コード」と「支店番号」が入力されている場合、両方の値が一致する必要があります。

口座番号

必須長さは最大16桁の数字である必要があります。

検証桁

オプション長さは1桁の数字である必要があります。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは24文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

スイス

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは3桁から5桁の間の数字である必要があります。

支店番号

オプション入力する場合、長さは3桁から9桁の間の数字である必要があります。

口座番号

必須長さは最大17桁の数字である必要があります。

検証桁

オプション

口座タイプ

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは21文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されま

375

せん。最初の2文字は文字です。3番目と4番目の文字は数字です。

マケドニア旧ユーゴスラビア共和国

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます長さは19文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

チュニジア

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須。

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。

376

長さは22文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

トルコ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号

オプション

口座番号

必須。

検証桁

オプション

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは26文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ウクライナ

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション

支店番号 オプション

口座番号 必須

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。

377

モジュラス97ルールを使用して、IBANの妥当性が計算されます。29文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

アラブ首長国連邦

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは最大4文字である必要があります。

支店番号 オプション

口座番号 必須長さは最大21文字である必要があります。

検証桁 オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。23文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。

イギリス

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション入力する場合、長さは6桁の数字である必要があります。

支店番号 必須国内で一意です。長さは最大6桁の数字である必要があります。長さが6未満の場合、先行するゼロを必要な数だけ前に付けて6桁の数字に変換されます。このフィールドは「ソート・コード」としてラベル付けされます。

口座番号 必須長さは7文字から8文字の間である必要があります。長さが7文字である場合、先頭文字としてゼロを追加して8文字に変換されます。

検証桁 オプション

378

セカンダリ口座参照

オプション入力する場合、長さは最大18文字である必要があります。このフィールドは「住宅金融共済組合のロール番号」としてラベル付けされます。

IBAN 必須IBANが入力されていない場合、「IBANが入力されていません。この銀行口座は、支払処理にIBANが必要な国で定義されています。」という警告メッセージが表示されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。長さは22文字である必要があります。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

アメリカ合衆国

検証ルール

次のルールを採用することにより、フィールドの妥当性がチェックされます。

フィールド ルール

銀行コード

オプション。

支店番号

このフィールドは「ルーティング・トランジット番号」としてラベル付けされます。長さは最大9桁の数字である必要があります。長さが9未満の場合、先行するゼロを必要な数だけ前に付けて9桁の数字に変換されます。9桁になるように数字を埋める場合、最初の8桁がすべてゼロになってはなりません。たとえば、001および000007は、9桁になるように数字を埋めると000000001および000000007になり、先行するゼロが8桁になってしまうため、無効なルーティング・トランジット番号です。ルーティング・トランジット番号に検証アルゴリズムが適用されます。

口座番号

必須

検証桁

オプション

IBAN オプション。入力する場合、次のルールが適用されます。モジュラス97ルールを使用して、IBANの妥当性が計算されます。34文字を超える長さにすることはできません。左右のスペースは削除されます。中間のスペースは削除されません。最初の2文字は文字です。3番目と4番目の文字は数字です。

ルーティング・トランジット番号の検証アルゴリズム

1. 番号フィールドの9桁目が検証桁として使用されます。2. 計算検証桁は、モジュラス10アルゴリズムに基づいて残りの8桁から算出されます。3. ルーティング・トランジット番号の各桁に重み付けファクタが乗算されます。各桁の重み付けファクタを次の表に示します。

379

桁 1st 2nd 3rd 4th 5th 6th 7th 8th

ファクタ 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 N/A

合計 0 49 6 12 0 1 6 35 = 109

したがって、検証桁 = 1 (110 - 109)です。

この例では、ルーティング・トランジット番号076401251は検証に成功します。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

380

19c

現預金のための売掛/未収金クレジットの実装

13 Advanced Collections構成の定義この章の内容は次のとおりです。

回収プリファレンスの管理年齢調べ方法の管理回収担当の管理督促構成の管理スコアリングの定義戦略の定義回収スコアリングおよび戦略割当の管理

回収プリファレンスの管理

回収プリファレンスの設定に関するガイドラインOracle Fusion Advanced Collectionsでは、ユーザー・インタフェースに従って回収プリファレンスの設定を進めることができます。必須の設定リージョンは、「グローバル・プリファレンス」と「プリファレンス」の2つです。質問に回答し、日付範囲やデフォルトなど、アプリケーションの動作に関して意思決定します。プリファレンスを定義する前に、次の決定事項を検討してください。

決定事項 このOracle Fusionが該当するかどうか

作成する従業員、事業所および組織の数

はい。企業体系の設定によって異なります。Advanced Collectionsを設定する前に、レビューして確認してください。

作成する従業員 はい。回収プロセスに関与する従業員の数を決定します。

381

回収担当の割当 はい。回収担当をどのように割り当てるか。顧客アカウント、アカウント、サイトまたはその他の基準に基づいて割り当てます。

Oracle Fusion AccountsReceivablesの設定

はい。Receivablesがどのように設定され、Advanced Collectionsにどのような影響を与えるか。

ARトランザクション要約表の有効化

はい。トランザクションに適用された活動を更新するためにReceivablesで設定するプロファイル・オプション。

Oracle FusionPaymentsの設定

はい。トランザクションに適用するクレジット・カードおよび自動資金振替を使用するように設定します。

単位の設定 はい。トランザクションに必要なReceivablesの設定。

セキュリティおよびユーザーの設定

はい。Oracle Fusion Identity Managementで回収に対するアクセス権を付与するように設定します。

ノートの設定 はい。これは、回収担当が顧客とのやり取りについてコメントを入力するためのOracle Fusion Common Application Components (CAC)の機能です。

タスクの設定 はい。これは、回収担当またはマネージャがフォローアップ・タスクを割り当てるためのCACの機能です。

Oracle BusinessIntelligence Publisherの設定

はい。ただし、Business Intelligence Publisherが回収レポートを実行するように機能していることを確認する必要があります。

グローバル・プリファレンス

「グローバル・プリファレンス」リージョンで行った選択は、回収担当が「回収顧客」作業領域および回収ダッシュボードから参照するビューに影響します。「グローバル・プリファレンス」では次の設定を定義します。

表示されるデフォルトのトランザクション区分

オープン・トランザクションの表示

クローズ済トランザクションの表示

以前および将来のトランザクションが表示される日数ダッシュボードで作業を再スケジュールする日数

デフォルトの年齢調べ方法

データを区切るために使用するデリミタ、および検索を実行するために必要な文字数督促通信用の送信者または返信先Eメール・アドレス約束違反になるまでの最大猶予日数約束支払期日の最大日数破産の有効化

プリファレンス

「プリファレンス」リージョンで行った選択は、回収担当が回収プロセスを進めていくときのデフォルト設定に影響します。「プリファレンス」では次の設定を定義します

プリファレンス・セット

382

回収ビジネス・レベル

貸方の要約または年齢調べ

デフォルトの換算レート

督促の送信方法

督促受取者が不明な場合のデフォルト担当者

通信

「通信」表で行った選択は、回収担当が回収プロセス中に通信を送信するときのデフォルト設定に影響します。「通信」では、次の設定を定義します。

プリファレンス・セット係争通知の送信係争テンプレート支払通知の送信支払テンプレート支払約束通知の送信支払約束テンプレート

回収プリファレンスの定義この例では、Oracle Fusion Advanced Collectionsのプリファレンスを設定する方法を示します。

プリファレンスの2つのセクション(「グローバル・プリファレンス」と「プリファレンス」)の設定を任されました。次の要件に基づいてプリファレンスを構成します。

会社では、期日を90日超過しているトランザクションと30日先までの現行トランザクションを回収担当がレビューする必要があります。回収担当はアカウント別に顧客をレビューし、期日超過通知をEメールで送信します。使用可能な担当者情報がない場合は、買掛/未払金マネージャに通知が送信されます。顧客の履歴をレビューするには、現行トランザクションとクローズ済トランザクションを表示する必要があります。会社では、ダッシュボードで作業を2日まで再スケジュールできます。修正および係争は、記録されてから1営業日以内に処理されます。1つのアカウントに対する貸方は要約されます。年齢調べは、5バケット年齢調べ方法で表示されます。換算レートは、社内で設定されたレートに基づきます。データを区切るために使用するデリミタ記号はパイプです。顧客アカウントの検索を実行するための最小文字数は3文字となり、これが推奨される文字数です。

次の表を使用して、プリファレンスの2つのセクションを定義します。

回収プリファレンスの構成

1. 「グローバル・プリファレンス」を定義します

383

フィールド 値

「トランザクション」タブのデフォルトのトランザクション・タイプを選択します

「請求書」を選択します。他のトランザクションの選択肢は、「すべて」、「クレジット・メモ」または「デビット・メモ」です。

「トランザクション」タブにクローズ済トランザクションを自動的に表示します

顧客の履歴の一部としてクローズ済トランザクションを表示するには、「はい」を選択します。

「トランザクション」タブに現行トランザクションを自動的に表示します

顧客の待ち状態の現行トランザクションまたはオープン・トランザクションを表示するには、「はい」を選択します。

トランザクション日付範囲が開始する現在日より前の日数を入力します

この例では、90日を指定すると、3か月分の履歴が回収担当に表示されます。使用可能な範囲は1から9999です。

トランザクション日付範囲が終了する現在日より後の日数を入力します

30日分の現行トランザクションまたはオープン・トランザクションが表示されます。使用可能な範囲は1-9999です。

ダッシュボードで作業を再スケジュールできる最大日数を入力します

作業のスケジュールで許容される変更は2日です。使用可能な範囲は1-9999です。

活動が生成される修正または係争が発行されてからの日数を入力します。

1日で係争および修正が生成されます。使用可能な範囲は1-9999です。

デフォルトの年齢調べ方法を選択します 5バケット年齢調べ。様々な年齢調べバケットを定義でき、それらを使用できる場合があります。

回収ダッシュボードで顧客、アカウントおよびサイトを区切るために使用するデリミタを入力します

パイプ記号。使用可能な他の選択肢は、「より大きい」記号、ダッシュ記号およびコロン記号です。

検索の実行に必要な最小文字数を入力します

お薦めする検索の文字数は3文字です。使用可能な範囲は1-9999です。

督促通信用の送信者または返信先Eメール・アドレスを入力します

顧客が応答するデフォルトの返信先Eメール・アドレス

2. 「プリファレンス」を定義します

「プリファレンス」表の列名 フィールド値

回収プリファレンス・セット 値「共通セット」を選択します。

回収ビジネス・レベルの選択 「アカウント」。他の選択肢は「顧客」と「サイト」です。

貸方残高をデフォルトで年齢調べするか要約するかを選択します

「要約済」。貸方を年齢調べ済として表示することもできます。

複数通貨トランザクションを換算するための換算レート・タイプを選択します

「社内」。様々な選択肢を定義でき、それらが表示されます。

回収通知を送信するデフォルトの方法を選択します 「Eメール」を選択します。他の方法は「FAX」または「印刷」です。

督促受取者が不明な場合のデフォルト担当者を入力します

買掛/未払金マネージャ。担当者がリストされない場合はユーザー定義。

384

「通信」表の列名 フィールド値

回収プリファレンス・セット

値「共通セット」を選択します。

修正通知の送信 顧客のアカウントに対して行われた修正を顧客に通知するには、「はい」を選択します。

修正テンプレート 提供されているテンプレートを選択します。

係争通知の送信 顧客のアカウントに対して行われた係争を顧客に通知するには、「はい」を選択します。

係争テンプレート 提供されているテンプレートを選択します。

支払通知の送信 顧客のアカウントに対して行われた支払を顧客に通知するには、「はい」を選択します。

支払テンプレート 提供されているテンプレートを選択します。

約束通知の送信 顧客のアカウントに対する支払約束を顧客に通知するには、「はい」を選択します。

約束テンプレート 提供されているテンプレートを選択します。

3. 「保存」または「保存してクローズ」をクリックして、プリファレンスを有効にします。

回収プリファレンスの管理に関するFAQ

「グローバル・プリファレンス」と「プリファレンス」の違いは何ですか。

「グローバル・プリファレンス」は、クローズ済トランザクションまたはオープン・トランザクションの表示や日付範囲パラメータの設定など、「回収顧客」作業領域に影響します。

「プリファレンス」は、特定のビジネス・ユニットについて一意に設定できます。「プリファレンス」は、プリファレンス・セットや、通知を送信するデフォルトの方法など、デフォルト設定に影響します。

ビジネス・レベルにおける顧客、アカウントおよびサイトの間の違いは何ですか。

表示または変更するために顧客レベルで設定されたトランザクションには、顧客に関連付けられたすべてのトランザクション活動が網羅されます。たとえば、顧客レベルの督促状には、顧客レベルとアカウント・レベルのトランザクションが含まれます。

表示または変更するためにアカウント・レベルで設定されたトランザクションは特定のアカウントを対象とし、そのアカウントの請求先サイトすべてのトランザクションを含みます。

表示または変更するためにサイト・レベルで設定されたトランザクションは、請求先事業所に固有です。

最小督促金額と最小督促請求書金額の違いは何ですか。

すべての期限超過トランザクションの合計金額が、設定された最小督促金額に達すると、通信が生成されます。たとえば、最小督促金額が$100に設定され、3つの期限超過トランザクションが$25、$35および$55で、合計が$105になる場合は、この3つの請求書が期限超過としてリストされた督促状が生成されます。

385

1つの期限超過トランザクションの金額が、設定された最小督促請求書金額に達すると、通信が生成されます。たとえば、最小督促請求書金額が$25に設定され、3つの期限超過トランザクションが$15、$50および$75である場合は、$50と$75のトランザクションについて督促状が生成されます。

年齢調べ方法の管理

年齢調べ方法年齢調べ方法は、顧客の延滞プロファイルを理解することを目的として売掛/未収金、借方品目および貸方品目をグループ化するために使用される期間です。

時間のバケット別にトランザクションをグループ化すると、顧客の年齢調べビューが作成されます。年齢調べした情報を使用すると、次のような利点があります。

回収担当は、延滞債務の回収を効果的に試みることができます。回収組織では、作業を割り当てるためのより効果的なポリシーを策定し、業務の効率化を図ることができます。

Advanced Collectionsには事前構成済の年齢調べ方法が用意されていますが、会社の要件に基づいて新しい年齢調べ方法を作成することもできます。

年齢調べ方法の機能

年齢調べは、顧客の期日超過トランザクションおよび現行トランザクションを計算するという概念です。Oracle Fusion Advanced Collectionsでは、期限超過債務が時間別にグループ化され、債務項目の年齢調べバケットに基づいて作業が割り当てられます。年齢調べ方法には次のような機能があります。

会社に対する顧客の負債金額の表示。金額が未回収になっている期間も含まれます。たとえば、年齢調べでは、現在、30日、60日、90日、120日以上などのバケットに売掛/未収金が分類されます。年齢調べ方法の設定画面と、別個の「年齢調べ」タブで構成される機能。督促プランの作成中に使用される年齢調べ方法の使用。時間の経過に応じて表示される期限超過金額を回収担当が理解するために役立つ、トランザクションまたは売掛/未収金データの表示。この内容を理解することにより、回収担当は支払を確保したり、修正または係争を作成できます。

関連トピック

督促の概要

年齢調べ方法の作成この例では、Oracle Fusion Advanced Collectionsで事前に定義されていない年齢調べ方法を作成する方法を示します。

会社では、回収の事前定義年齢調べ方法ではない年齢調べ方法を必要としています。新しい年齢調べ方法を作成することになりました。指定がある場合を除き、デフォルト値を使用します。次のセグメントを使用し

386

て、「1 to 120 Days Method」という名前の年齢調べ方法を作成します。

連番 バケット・タイプ 年齢調べ日数: 自 年齢調べ日数: 至 年齢調べバケット見出し

1 現在 -9999 0 現在

2 期日超過 1 45 45日期日超過

3 期日超過 46 60 60日期日超過

4 期日超過 61 90 90日期日超過

5 期日超過 91 120 120日期日超過

6 期日超過 121 9999 121日以上期日超過

年齢調べ方法の作成

1. 「年齢調べ方法の管理」ページから開始します。2. 「年齢調べ方法」リージョンから、緑色のプラス記号をクリックして年齢調べ方法を作成します。3. 次の表のように、各フィールドに値を入力します。

フィールド 値

年齢調べ方法名

1 to 120 Aging Day Method

年齢調べタイプ

「取引明細書による年齢調べ」。年齢調べ方法のバケット数に応じた、4バケット年齢調べと7バケット年齢調べのオプションがあります。

使用可能 はい

年齢調べ方法セット

共通セット

年齢調べ方法摘要

現在から120日までの年齢調べ方法。

4. 「保存」をクリックします。5. 「1 to 120 Aging Day Method: 詳細」で、次の表のように、各フィールドに値を入力します。

フィールド 値

連番 1

バケット・タイプ 期日超過

年齢調べ日数: 自 1

年齢調べ日数: 至 45

年齢調べバケット見出し

45日期日超過。「作成」アイコンをクリックして、次の連番の行を作成します。

連番 2

バケット・タイプ 期日超過

387

年齢調べ日数: 自 46

年齢調べ日数: 至 60

年齢調べバケット見出し

60日期日超過

6. 連番4から6についてこのステップを繰り返し、「年齢調べ日数: 自」および「年齢調べ日数: 至」の値を適宜増やします。

7. 「保存してクローズ」をクリックして、新しい年齢調べ方法の作成を完了します。年齢調べ方法を作成または変更する際には、次の検証ルールが適用されます。

バケットには、2つ以上、7つ以下のバケット明細が含まれている必要があります。バケット・タイプは、ユーザー・インタフェースから固定定数値として渡されます。バケットの「年齢調べ日数: 自」には、「年齢調べ日数: 至」よりも小さい値を指定する必要があります。すべてのバケットは-9999から9999までの範囲を対象とする必要があり、フィールドを-9999または9999の値に更新する方法はありません。年齢調べバケットで-9999から9999の間にギャップを含めることはできません。

年齢調べ方法の管理に関するFAQ

事前定義の年齢調べ方法を変更するにはどうすればよいですか。

事前定義の年齢調べ方法は変更できませんが、それらをコピーして、名前を変更し、複製に変更を加えることができます。「年齢調べ方法の管理」ページで、提供されている年齢調べ方法のいずれかを選択し、「複製」ボタンを選択します。方法の名前が変更されて、複製された年齢調べ方法の名前の前に「コピー」が追加されます。たとえば、5バケット年齢調べは「コピー5バケット年齢調べ」のようになり、変更を加えることができます。変更を保存すると、変更した年齢調べ方法が作成されます。

回収担当の管理

回収担当の設定に関するガイドライン回収担当は、様々な回収作業を実施するために顧客に割り当てる、個人または個人のグループです。タスクは次のとおりです。

通信の送信顧客履歴のレビュー顧客からの支払の回収

注意: 回収担当を作成する前に、個人をOracle Fusion Human Resourcesアプリケーションで従業員として設定し、Oracle Fusion Customer Relationship Management (CRM)アプリケーションでリソースとして設定する必要があります。

388

回収担当の設定

個人を回収担当として設定するときには、次のことを考慮してください。

回収担当は、1つ以上の顧客に個別に割り当てることも、1つ以上の顧客から回収するグループ・メンバーにすることもできます。組織に最も適した回収ニーズを評価してください。

回収担当は、顧客、アカウントまたはサイト・レベルで割り当てることができます。組織が顧客とどのようにやり取りするかを決定してください。

組織が回収担当間で作業およびタスクをどのように分割するかを調査します。

Collectionsの組織体系は、顧客の数に基づいて様々な方法で作成できます。たとえば、サイズに従って小規模から大規模までに顧客をグループ化したり、地域や顧客との取引金額に基づいて顧客を分割することができます。

回収担当グループの使用

回収担当グループは、プライマリ回収担当と1人以上の個別回収担当で構成されます。回収担当グループを使用して、回収タスクをチームとして実行します。回収担当グループの回収担当は、同じ回収タスクを実行できます。

「回収」作業領域では、回収担当グループに属するすべての回収担当に同じ延滞顧客および戦略タスクが表示されます。「戦略タスク」情報タイルには、グループのオープン状態の手動戦略タスクのリストが表示されます。グループの回収担当は、タスクを自分自身またはグループ内の他の回収担当に再割当できます。「戦略タスク」リストには、タスクのプライマリ回収担当と割り当てられた回収担当が表示されます。

プライマリ回収担当に割り当てられた活動は、グループ内の回収担当の活動の数およびリストには含まれません。

回収担当をグループに追加するときには、次のルールを考慮してください。

指定の日付範囲について回収担当をグループ・メンバーまたはバックアップ回収担当として指定できます。回収担当は、指定の日付範囲の間、1つのアクティブな回収担当グループにのみ属することができます。

回収担当の作成この例では、回収担当を作成し、従業員割当およびグループ割当として割り当てる方法を示します。

会社で、回収担当として5人の個人を作成するとします。次のことに基づいて回収担当を設定します。

回収部門では、地域(北部、南部、東部および西部)に基づいて回収を行います。Acme Corporationは大口顧客で、このアカウントには1人の回収担当を割り当てます。5人の個人はすべて、個人パーティおよび従業員として作成済で、回収担当を作成するための前提条件を満たしています。回収担当グループは、地域ごとに設定できます。

それぞれの個人について次の情報が必要です。

フィールド 処理

389

名前 従業員名

説明 オプション。詳細情報

通信 送信される通信に使用される名前

電話番号 担当者番号

従業員名 アクティブな従業員リスト

アクティブまたは非アクティブ 回収担当ステータス

従業員割当の作成

1. 機能設定マネージャの「回収担当設定」ページから開始します。2. このページから回収担当を検索したり、新しい回収担当を作成できます。3. 回収担当の追加または作成アイコンをクリックします。4. 「回収担当名」を入力します。5. 回収担当のタイプとして「従業員」が定義されていることを確認します。6. 「従業員」列の値リストから従業員の名前を選択します。7. 「使用可能」フィールドはデフォルトで「はい」に設定されています。8. 適切な「回収担当セット」を選択します。9. 「保存してクローズ」ボタンをクリックします。

回収担当グループの作成

回収マネージャは回収担当グループを作成できます。回収担当グループを作成するには、次のステップを実行します。

1. 「リソースの管理」ページにナビゲートします。2. 設定する回収担当グループのプライマリ回収担当を選択します。3. ページの「回収担当グループ」セクションに移動します。4. 「新規」アイコンをクリックして、新しい回収担当グループを追加します。5. 一意の回収担当グループ名を入力します。「使用可能」フィールドはデフォルトで「はい」に設定されています。

6. 「回収担当」リストからメンバー名を選択してグループに追加します。「使用可能」フィールドは、開始日とともにデフォルトで「はい」に設定されます。

7. グループにすべての回収担当を追加したら、「保存」または「保存してクローズ」をクリックします。

関連トピック

従業員または派遣就業者リソースを作成できますか

回収担当付加フレックスフィールドの概要回収担当付加フレックスフィールドを使用して、地域や回収経験などの回収担当情報に関するカスタム属性を追加できます。

390

たとえば、回収担当の地域を指定する付加フレックスフィールドを作成すると、その地域または付近の顧客に回収担当を割り当てるために使用できます。回収担当の経験を追跡すると、回収担当に割り当てる顧客アカウントの決定に役立ちます。

Oracle Fusion Advanced Collectionsでは、1つの付加フレックスフィールドを使用できます。

付加フレックスフィールド 説明

回収担当 回収担当に関する追加情報を表示するために15のセグメントを使用できます。

付加フレックスフィールド・セグメントの定義

「付加フレックスフィールドの管理」タスクを使用して、付加フレックスフィールドのセグメントを定義します。回収のニーズや詳細情報のレベルに基づいて、回収担当に関連する情報をさらに追加できます。

付加フレックスフィールドのアクティブ化

付加フレックスフィールドをデプロイして値セットとセグメント値を定義したら、フレックスフィールドをアクティブ化します。付加フレックスフィールドを表示するには、アプリケーションからサインアウトしてサインインする必要があります。

注意: 回収担当付加フレックスフィールドのグローバル・セグメントは使用できません。

関連トピック

付加フレックスフィールドの概要付加フレックスフィールドの管理に関する考慮事項

回収担当付加フレックスフィールドの設定「回収担当者の管理」付加フレックスフィールドには、追加情報を取得するための15のセグメントが用意されています。これらのセグメントは、「回収担当者の管理」ページで個別のフィールドとして使用できるようになります。この例では、次のシナリオに基づき、コンテキスト依存セグメントを使用して付加フレックスフィールドを設定する方法を示します

シナリオ

回収担当の設定を任され、回収担当の地域および回収経験に関する詳細情報を取得することにしました。これらの情報を検索し、作成する各回収担当にその情報を関連付けることができるようにします。次の情報を使用して追加フィールドを設定します

セグメント名 値

地域 東部西部中部

経験 初心者初級上級

391

設定ステップ

1. 機能設定マネージャの「設定および保守」にナビゲートします。2. 「すべてのタスク」タブを選択します。3. 「値セットの管理」タスクを検索します。4. 「タスクに進む」アイコンをクリックします。5. 「モジュール」フィールドで「拡張回収」を検索します。6. 「検索」をクリックします。7. 「検索結果」リージョンで「作成」アイコンをクリックします8. 「値セットの作成」ページで、次の情報を入力します。

値セットの作成 値

値セット・コード IEX_REGION

説明 オプション

モジュール 拡張回収

検証タイプ 非依存

値データ型 文字

「定義」リージョン 値

値サブタイプ テキスト

最大長 20

最小値 空白のまま

最大値 空白のまま

大文字のみ 選択解除

ゼロ埋め 選択解除

9. 「保存してクローズ」ボタンをクリックします。10. 作成した値セット・コードを検索します。値セット・コードが検索結果に表示されます。11. 検索結果で「値の管理」ボタンをクリックします。12. 「値の管理」ページの「検索結果」リージョンで、「作成」アイコンをクリックします。13. 「値の作成」ページで、「東部」、「西部」および「中部」という値を作成します。14. 次の情報を入力します。

フィールドまたはチェック・ボックス 値

必須値 東部

説明 オプション

有効 選択

開始日 オプション

392

終了日 オプション

ソート順 オプション

15. 「保存してクローズ」ボタンをクリックします。16. 「中部」および「西部」地域についても繰り返します。「作成」アイコンをクリックします17. 各地域の入力が完了したら、「保存してクローズ」ボタンをクリックします。18. 「保存してクローズ」ボタンをクリックします。19. 「完了」ボタンをクリックします。20. 「完了」ボタンを最後にもう一度クリックします。21. 「値セットの管理」タスクから、「タスクに進む」をクリックします。22. 「作成」アイコンをクリックします。23. 「値セットの作成」ページで次の情報を入力します。

値セット・フィールド 値

値セット・コード IEX_EXPERIENCE

説明 オプション

モジュール 拡張回収

検証タイプ 非依存

値データ型 文字

「定義」リージョンのフィールドまたはチェック・ボックス 値

値サブタイプ テキスト

最大長 20

最小値 空白のまま

最大値 空白のまま

大文字のみ 選択解除

ゼロ埋め 選択解除

24. 「保存してクローズ」ボタンをクリックします。25. 作成した値セット・コードを検索します。値セット・コードが検索結果に表示されます。26. 「値の管理」ボタンをクリックします。27. 「値の管理」ページの「検索結果」リージョンで、「作成」アイコンをクリックします28. 「値の作成」ページで、「初心者」、「初級」および「上級」という値を作成します。

フィールドまたはチェック・ボックス 値

必須値 初心者

説明 オプション

有効 選択

393

開始日 オプション

終了日 オプション

ソート順 オプション

29. 「初級」および「上級」値について情報を繰り返し入力します。30. 「保存してクローズ」ボタンをクリックします。31. 「保存してクローズ」ボタンをもう一度クリックします。32. 「完了」ボタンをクリックします。33. 「完了」ボタンをもう一度クリックします。34. 「すべてのタスク」タブで、「付加フレックスフィールドの管理」を検索します。35. 「タスクに進む」アイコンをクリックします36. 「名前」フィールドに「回収担当」と入力します。37. 「検索」ボタンをクリックします38. 回収担当の「検索結果」リージョンで、「編集」アイコンをクリックします。39. 「コンテキスト・セグメント」リージョンの「プロンプト」フィールドに、「回収担当者の管

理」ページに表示されるプロンプトの名前として「追加情報」と入力します。40. 「コンテキストの管理」ボタンをクリックします。41. 「コンテキストの管理」ページで「作成」アイコンをクリックし、次のように入力します。

フィールド 値

表示名 追加情報

コンテキスト・コード IEX ADD INFO (大文字を推奨)

42. 「保存」ボタンをクリックします。43. 「コンテキスト依存」リージョンで「作成」アイコンをクリックし、次のように入力します。

フィールド 値

名前 地域

コード IEX REGION

説明 オプション

44. 「列割当」リージョンで、次のように入力します。

フィールド 値

データ型 テキスト

表の列 属性1

45. 「検証」リージョンで、次のように入力します。

フィールドまたはチェック・ボックス 値

値セット IEX_Region

説明 オプション

394

範囲タイプ 不要

必須 選択解除

初期デフォルト 不要

46. 「プロパティの表示」リージョンで、次のように入力します。

フィールドまたはチェック・ボックス 値

プロンプト 回収担当の地域

表示タイプ 値リスト

必須 選択解除

47. 「保存してクローズ」ボタンをクリックします48. 「コンテキスト依存」リージョンで「作成」アイコンをクリックし、次のように入力します。

フィールド 値

名前 経験

コード IEX EXPERIENCE

説明 オプション

49. 「列割当」リージョンで、次のように入力します。

フィールド 値

データ型 テキスト

表の列 属性2

50. 「検証」リージョンで、次のように入力します。

フィールドまたはチェック・ボックス 値

値セット IEX_Experience

説明 オプション

範囲タイプ 不要

必須 選択解除

初期デフォルト 不要

51. 「プロパティの表示」リージョンで、次のように入力します。

フィールドまたはチェック・ボックス 値

プロンプト 回収担当の経験

短いプロンプト 経験

表示タイプ 値リスト

395

必須 選択解除

52. 「保存してクローズ」ボタンをクリックします。53. 「保存してクローズ」ボタンをもう一度クリックします。54. 「完了」ボタンをクリックします。55. 「保存してクローズ」ボタンをクリックします。56. 「付加フレックスフィールドの管理」ページの「名前」フィールドで、「回収担当」を検索しま

す。57. 「検索結果」リージョンに、付加フレックスフィールドが表示されます。58. 「フレックスフィールドのデプロイ」ボタンをクリックします。59. ポップアップ・ウィンドウで「OK」をクリックします。60. 環境からサインアウトした後、もう一度サインインして、付加フレックスフィールドをアクティブ

化します。61. 「設定および保守」にナビゲートします。「すべてのタスク」タブを使用して、「回収担当者の管

理」を検索します。62. 「タスクに進む」アイコンをクリックします。63. 「追加情報」フィールドが「地域」および「経験」の値リストとともに「検索」リージョンに表示

されることを確認します。64. 新しい回収担当を作成し、行を展開します。2つのセグメント「地域」と「経験」を含む「追加情

報」がそれぞれの適切な値とともに表示されることを確認します。

関連トピック

付加フレックスフィールドの概要付加フレックスフィールドの管理に関する考慮事項

回収担当の管理に関するFAQ

従業員割当とグループ割当の違いは何ですか。

従業員割当は、1つの顧客に割り当てられる回収担当です。個人をユーザー、リソースまたは回収担当として設定する前に、従業員として作成する必要があります。

グループ割当は、回収担当のグループに作業および顧客を割り当てるために作成されます。1つのグループに複数の従業員または回収担当を含めることができます。

督促構成の管理

年齢調べ済督促と段階的督促次の2つの督促方法を使用して、顧客通信を設定できます。

1. 年齢調べ済

396

2. 段階的

督促方法は次のレベルでサポートされています。

顧客アカウント請求先サイト

「年齢調べ済督促」方法

「年齢調べ済督促」方法は、最も古い年齢調べ済トランザクションに基づいて顧客に回収通知を送信する会社で使用できます。延滞識別コンカレント・プロセスが実行されると、延滞トランザクションが自動的に識別されます。事前構成済の督促通知テンプレートを使用することも、当該会社が独自の督促通知テンプレートを作成することもできます。最も古い年齢調べ済トランザクションが次の年齢調べバケットに移動すると、督促状の内容が変更されることがあります。複数の延滞トランザクションがある同じ顧客に複数の年齢調べ済督促状を送信しないように、1つの連結通知を送信できます。テンプレートは、督促構成プロセスで年齢調べバケットに関連付けられます。

「段階的督促」方法

「段階的督促」方法は、トランザクションが期日を超過した日数ではなく、最後の督促状が送信されてからの日数に基づきます。複数の延滞トランザクションがある同じ顧客に複数の段階的督促状を送信しないように、1つの連結通知を送信できます。延滞識別コンカレント・プロセスが実行されると、延滞トランザクションが自動的に識別されます。トランザクションに賦払期日がある場合、段階的督促状では、連結通知の本文にそれぞれの期限超過賦払日が記載されます。段階的督促状は、督促構成プロセスで定義された遅延間隔で送信されます。これらの間隔によって、それぞれの通知が送信される時期が制御されます。事前構成済の督促テンプレートを使用するか、新しいものを作成します。

顧客督促の構成オプション顧客との定期的な通信を容易にするために、督促プランおよび督促状を構成します。

次に示すオプションのうち、督促プロセスの再実行を除くすべてのものが、機能設定マネージャの通信構成で作成されます。

督促状オプション

督促状の送信オプション

督促構成セット

督促トランザクション

督促プロセスの再実行

督促状オプション

アプリケーションに用意されている事前構成済の年齢調べ済督促状または段階的督促状を使用するか、固有の要件を満たす新しい督促状を作成します。次に示す2つの方法のいずれかで督促を実行するように構成します。

1. 「年齢調べ済督促」は、最も古い期日超過借方品目に基づきます。

397

2. 「段階的督促」は、前の通知が送信されてからの日数に基づきます。

督促状の送信オプション

顧客への督促状の送信手段は次のとおりです。

Eメール

FAX

普通郵便

督促トランザクション

督促状に含めるトランザクションおよび手数料を選択します。

督促状生成プログラムには、期日前請求書、係争請求書およびクレジット・メモを含めることができます。

督促状には現行トランザクションを含めることができます。

延滞金利を明細項目として含めることができます。

「係争請求書を含む」を選択すると、係争解決待ちのトランザクションが表示され、合計に含まれます。

督促構成セット

督促は、1つのビジネス・ユニットまたは複数のビジネス・ユニットで構成できます。セットを定義するときには、次のことを考慮してください。

セットによって、サプライヤや顧客など、ビジネス・オブジェクトのマスター・リストのサブセット(この場合は督促構成セット)が定義されます。セット決定要因は、セットとの間に1対1の関係を持つビジネス・オブジェクトであり、通常はいずれかのタイプの組織ユニットです。セット決定要因が表示されている場合は、セットを非表示にできます。データ・セキュリティを適用するために、ビジネス・オブジェクトのセットを組織ユニット(ビジネス・ユニットや法的エンティティなど)に関連付けることができます。その後、ユーザーが組織ユニットに関連付けられると、その組織ユニットに適したビジネス・オブジェクトのサブセットのみが自動的に表示されます。「セット」フィールドまたはセット決定要因フィールドが、組織ユニットによって使用されるオブジェクトのマスター・リストのサブセットを決定する参照コードとして表示されます。たとえば、購買トランザクションを実行する場合、「セット」またはセット決定要因の値によって、使用できるサプライヤが決まります。

督促プロセスの再実行

エラーを修正したり、督促状を再生成するには、督促プロセスを再実行します。

プログラムのフェーズ中にエラーが発生した場合は、督促プロセスを再実行します。

顧客が別のコピーを要求した場合は、前の督促状を再生成します。

398

顧客が督促状を受け取らないようにするには、「プロファイル」タブで督促から「除く」として指定します。

督促構成のインストール後Oracle Fusion Advanced Collectionsの督促機能では、Oracle Business Intelligence Publisherを利用して、Eメール、FAXまたは印刷によって顧客に督促状を送付します。この機能を使用するには、当該会社の内部Eメール・サーバー、印刷サーバーまたはFAXサーバーに接続するようにOracle Business Intelligence Publisherを構成する必要があります。

Oracle Business Intelligence Publisherの構成: Eメール・サーバーを追加して、Oracle Business IntelligencePublisherを構成します。『Oracle Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド』(OracleFusion Applications Edition)を参照してください。

Eメール・サーバーの追加

Eメール・サーバーを追加する手順は、次のとおりです。

1. 「管理」ページから「電子メール」を選択します。追加されているサーバーのリストが表示されます。「サーバーの追加」を選択します。

2. Eメール・サーバーの「サーバー名」、「ホスト」および「ポート」を入力します。3. Eメール・サーバーとの接続に使用する「セキュアな接続」方法を選択します。オプションは次のとおりです。「なし」または「SSL」。Secure Socket Layerを使用します。「TLS」(Transport LayerSecurity)。サーバーがTLSプロトコルをサポートしている場合、TLSを使用します。レスポンスではSSLが受け付けられます。「TLS必須」。サーバーがTLSをサポートしていない場合、接続は確立されません。

4. オプションで、「一般」のフィールド(「ポート」)と「セキュリティ」のフィールド(「ユーザー名」および「パスワード」)を入力します(該当する場合)。

督促構成の管理に関するFAQ

年齢調べ済督促方法と段階的督促方法の違いは何ですか。

年齢調べ済督促では、最も古いトランザクションの年齢に基づいて督促状が送信されます。マネージャは、それぞれの年齢調べバケットについて送信する督促状を指定します。

段階的督促では、最も古いトランザクションの年齢と最後の通知が送信されてからの日数に基づいて督促状が送信されます。マネージャは、次の段階を実行するまでに待機する期間を指定します。

どちらの方法についても、マネージャは、延滞が解決されなかった場合にフォローアップ・コールを手動でスケジュールするかどうかを決定します。

スコアリングの定義

399

スコアリング算式スコアリング算式は、回収活動の基盤です。

スコアリング算式

Oracle Fusion Advanced Collectionsでは、次の2つの方法でスコアリングが使用されます。

1. トランザクション・ステータスを現行、延滞または事前延滞として決定します。Collectionsでは、Oracle Fusion Accounts Receivablesからの請求書およびデビット・メモがスコアリングされます。期日超過トランザクションがある場合、顧客は延滞となります。

2. 顧客、アカウントまたは請求先サイト・レベルで各顧客の回収可能性を決定します。顧客に関するデータ・ポイントを使用して回収可能性を判断します。

スコアリング算式は次のもので構成されます。

高スコアと低スコア

1つ以上の加重データ・ポイントとして、合計が1になる必要があります

使用可能なすべての値を網羅するために定義するデータ・ポイント詳細

トランザクションをスコアリングする場合にのみ使用されるステータス

データベースのサブセットまたはセグメントに対して実行できるセグメント

算式をテストできるレビュー

スコアリング算式を使用すると、回収リソースおよび戦略を効果的に管理できます。

Collectionsには、特定のビジネス・ニーズに適用したりコピーして変更できるスコアリング算式のセットが用意されています。

考慮事項と推奨事項

次の点を考慮してください。

本番環境のデータの一部または全部を使用して、すべてのデータ・ポイントとスコアリング算式をテスト環境でテストする必要があります。

スコアリング結果およびパフォーマンスに問題がなければ、テストしたスコアリング算式を本番環境に移行できます

スコアリング算式の作成この例では、スコアリング算式を作成する方法を示します。

次のデータ・ポイントに基づいて単純なスコアリング算式を作成します。

1. アカウント・レベル延滞件数2. 延滞の計上済金額

注意: これらが存在しない場合は、スコアリング算式を作成する前に作成しておく必要があります。

400

スコアリング算式の作成

ナビゲーション: 「設定および保守」→「すべてのタスク」→「回収の定義」→「回収スコアリングの管理」→「タスクに進む」アイコン→「スコアリング算式の管理」

1. 「スコアリング算式の管理」ページで、「作成」アイコンをクリックします。2. 次の表を使用して、記載されている情報を入力します。

フィールド 値

名前: 必須 Simple Scoring Formula

タイプ: 必須 アカウント: 算式に追加できるデータ・ポイントのタイプを決定します。

摘要: オプション 延滞の数および金額。

スコア: 自: 必須 1: 算式で計算される最も低いスコア。

スコア: 至: 必須 100: 算式で計算される最も高いスコア。

使用可能: 算式をアクティブ化します

選択

3. 「データ・ポイント」セクションから、データ・ポイントを算式に追加します。各データ・ポイントは、スコアリング算式の上限と下限の範囲内でマップされる必要があります。

4. 「行の追加」アイコンをクリックします。5. 「名前」フィールドで、「アカウント・レベル延滞件数」データ・ポイントを検索します。6. データ・ポイントを強調表示して、「OK」をクリックします。7. 「加重」フィールドに値1を入力します。8. 次の表を使用して、記載されている情報をデータ・ポイント詳細セクションに入力し、4つの行を設定します。

範囲: 自 範囲: 至 値

0 10 100

11 50 75

51 100 50

101 999,999,999 1

9. 「保存」をクリックします。10. 「行の追加」アイコンをクリックします。11. 「名前」フィールドで、「延滞の計上済金額」データ・ポイントを検索します。12. データ・ポイントを強調表示して、「OK」をクリックします。13. 次の表を使用して、記載されている情報をデータ・ポイント詳細セクションに入力し、4つの行を設

定します。

範囲: 自 範囲: 至 値

0 5,000.00 100

401

5,000.01 25,000.00 75

25,000.01 50,000.00 50

50,000.01 999,999,999.00 1

14. 次の表を使用して、2つのデータ・ポイントの加重を調整します。

データ・ポイント 加重

アカウント・レベル延滞件数 0.25

延滞の計上済金額 0.75

合計 1.00

15. 「保存」ボタンをクリックします。16. 「次」ボタンをクリックします。次の表を使用して、記載されている情報をスコアリング算式セグ

メント・ページに入力します。

セグメント 値

ビュー名: スコアリング算式に適用する顧客、アカウント、サイトまたはトランザクションのグループを選択します。

IEX_F_ACCOUNTS_V

識別子: それぞれの顧客、アカウント、サイトまたはトランザクションを識別する一意の属性を選択します。

CUST_ACCOUNT_ID

17. 「次」ボタンをクリックします。18. 「保存」ボタンをクリックします。19. スコアリング算式レビュー・ページに移動します。20. 「サンプル・スコア」セクションで、次の表に記載されている情報を使用して算式をテストしま

す。

フィールド 値

アカウント番号: 延滞または現行トランザクションがあるアカウントを選択します。

有効なアカウント番号

ビジネス・ユニット: それらのトランザクションが含まれるビジネス・ユニットを選択します。

有効なビジネス・ユニット

21. 「スコア」ボタンをクリックします。

スコアリング算式の結果

「データ・ポイント」表には、次の内容が表示されます。

1. コンポーネント・スコア: テスト・アカウントに関する延滞の実際の数と延滞の合計金額。2. マップされたコンポーネント・スコア: その数値がそれぞれのデータ・ポイント詳細にどのように換算されるか。

3. 加重スコア: 「マップされたコンポーネント・スコア」にデータ・ポイント加重を乗算した値。スコア合計には、すべてのデータ・ポイントの加重スコアの合計が表示されます。これが、アカウントに割り当てられるスコアです。

402

算式の適用

算式がアクティブ化されたので、ジョブとしての回収スコアリング・プログラムを発行して適用します。

ナビゲーション: 「ナビゲータ」→「スケジュール済プロセス」→ジョブとしての回収スコアリング

1. 「新規プロセスのスケジュール」ボタンをクリックします。2. 値リストからジョブとしての回収スコアリングを選択します。3. 次の表に従ってパラメータを入力します。

パラメータ 値

ビジネス・ユニット: 必須 アカウントを含むビジネス・ユニットを選択します。

スコアリング算式: 必須 Simple Scoring Formula

4. 「発行」ボタンをクリックします。5. 「回収」作業領域にナビゲートして検証します。顧客、アカウントまたは請求先サイトの問合せを実行してレビューします。「顧客階層」タスク・ペインにスコアが表示されます。

スコアリング算式の編集この例では、既存の算式を取得し、複製機能を使用して算式を編集する方法を示します。

Oracle Fusion Advanced Collectionsには、顧客のスコアリングに使用できる算式のセットが用意されています。既存の算式をコピーして変更を加えることにより、ビジネス要件を満たすように変更できます。

既存の算式の編集

算式「顧客スコアリング」を使用していますが、既存の算式の加重を変更して、91日以上期限を超過している顧客により低いスコアを割り当てることにしました。

ナビゲーション: 「設定および保守」→「すべてのタスク」→「回収の定義」→「回収スコアリングの管理」→「タスクに進む」アイコン→「スコアリング算式の管理」

1. 既存の算式を問い合せます。「名前」の「例による問合せ」フィールドに「顧客スコアリング」と入力し、[Enter]を押します。

2. 行を選択して、「複製」アイコンをクリックします。3. 次の表を使用して、算式の情報を編集します。

フィールド 値

名前必須

顧客スコアリングのコピーの名前を置き換えます。これは一意の名前である必要があります

91+顧客スコアリング

摘要: オプション 顧客スコアリング算式のコピーを変更したもの。加重値を変更。

開始日: 必須 現在の日付

403

終了日: オプション 空白のまま: 算式の有効期間が限られている場合は、終了日を使用します。

タイプ: 算式に追加できるデータ・ポイントのタイプを決定します。

顧客

説明 これはオプションのフィールドです。

スコア: 自: 必須 1: 算式で計算される最も低いスコア。

スコア: 自: 必須 100: 算式で計算される最も高いスコア。

使用可能: 算式をアクティブ化します。 はい

4. 次の表に従って加重を変更します。

データ・ポイント 加重

1-30日期限超過の延滞のパーセント 0.1: 他のデータ・ポイントを増やすには値を小さくします

31-60日期限超過の延滞のパーセント 0.1: 他のデータ・ポイントを増やすには値を小さくします

61-90日期限超過の延滞のパーセント 0.1: 他のデータ・ポイントを増やすには値を小さくします

91日以上期限超過の延滞のパーセント 0.7: 他のデータ・ポイントを増やすには値を小さくします

合計は1.00である必要があります 1.00

5. 「次」ボタンをクリックします。6. 顧客セグメントがリストされたままにします。「次」ボタンをクリックします。7. 「スコアリング算式の作成: レビュー」で、「保存」ボタンをクリックします。8. 「サンプル・スコア」セクションで、次の表に記載されている情報を使用して算式をテストします。

フィールド 値

アカウント番号 91日以上の延滞トランザクションがあることがわかっているアカウントを選択します。

ビジネス・ユニット

それらのトランザクションが含まれるビジネス・ユニットを選択します。

9. 「スコア」ボタンをクリックします。「データ・ポイント」表には、次の内容が表示されます。

a. コンポーネント・スコア: テスト・アカウントに関する延滞の実際の数と延滞の合計金額。b. マップされたコンポーネント・スコア: その数値がそれぞれのデータ・ポイント詳細にどのように換算されるか。

c. 加重スコア: 「マップされたコンポーネント・スコア」にデータ・ポイント加重を乗算した値。

「スコア合計」には、すべてのデータ・ポイントの加重スコアの合計が表示されます。

算式の割当

算式がアクティブ化されたので、次のステップを実行して適用します。

404

ナビゲーション: 「ナビゲータ」→「スケジュール済プロセス」→ジョブとしての回収スコアリング

1. 「新規プロセスのスケジュール」ボタンをクリックします。2. 値リストからジョブとしての回収スコアリングを選択します。3. 次の表に従ってパラメータを入力します。

パラメータ 値

ビジネス・ユニット 先ほどテストしたアカウントを含むビジネス・ユニットを選択します。

スコアリング算式 91+顧客スコアリング

4. 「発行」ボタンをクリックします。5. 「回収」作業領域にナビゲートして検証します。顧客、アカウントまたは請求先サイトの問合せを実行してレビューします。「顧客階層」タスク・ペインにスコアが表示されます。

スコアリング算式のデータ・ポイントデータ・ポイントは、スコアリング算式のコンポーネントです。

データ・ポイント

スコアリング算式を作成する前に、まずデータ・ポイントを定義する必要があります。

注意: Cloudのお客様が算式で使用するスコアリング・データ・ポイントを作成、編集または変更するには、サービス・リクエストを送信する必要があります。

データ・ポイントは、次の2つのタイプのいずれかとして定義できます。

1. SELECT文2. データベース関数(延滞トランザクションの合計数や顧客延滞の合計延滞金額を問い合せるものなど)

注意: どちらのタイプについてもPL/SQL文または関数の作成方法を理解している必要があります。

データ・ポイント詳細の条件は次のとおりです。

1つの数値を返す必要があります

スコアリングの対象となるデータベース・エンティティである特定の要素について作成する必要があります

プラスにすることも、マイナスにすることもできます

-999,999,999から999,999,999までの数値範囲で構成する必要があります

連続している必要があり、重複しないようにする必要があります

データ・ポイントによって計算された値は加重され、スコアリング算式で使用されます。Collectionsに用意されている算式では、スコアが高い方が回収の可能性が高いことを示し、スコアが低い方が回収の可能性が低いことを示します。スコアが高い方が回収の可能性が低くなり、スコアが低い方が回収の可能性が高くなる算式を構成することもできます。

405

スコアリング・データ・ポイントの作成この例では、スコアリング算式で使用するデータ・ポイントを作成する方法を示します。

次の情報に基づいて2つのデータ・ポイントを作成します。

1. 指定された顧客アカウントの延滞の数に関する1つ目のデータ・ポイントを構成します2. 合計延滞金額に関する2つ目のデータ・ポイントを構成します。このデータ・ポイントでは計上済金額を使用し、異なる通貨の合計を計算できます。

注意: 算式を作成する前に、データ・ポイントを作成する必要があります。

データ・ポイントの作成

ナビゲーション: 「設定および保守」→「すべてのタスク」→「回収の定義」→「回収スコアリング・データ・ポイントの管理」→「タスクに進む」アイコン

1. 「回収スコアリング・データ・ポイントの管理」ページにナビゲートし、「作成」アイコンをクリックします。

2. 次の表を使用して、1つ目のデータ・ポイントを作成します。

フィールド 値

名前: 必須 アカウント・レベル延滞件数: 一意の名前を使用してください。

タイプ: 必須 アカウント: その他の選択肢は次のとおりです。顧客請求先トランザクション

摘要: オプション 顧客アカウントの延滞の合計数。

関数: データベース関数を表します いいえ: この例ではPL/SQL文を使用します。

使用可能: 算式で使用するデータ・ポイントをアクティブ化します。

選択

SQL文: このタスクには、PL/SQL文を記述するための知識が必要です

Select count(1) from iex_delinquencies where

cust_account_id=:cust_account_id and

status<>'CURRENT'

3. 「保存して再追加」ボタンをクリックします。4. 次の表を使用して、2つ目のデータ・ポイントを作成します。

フィールド 値

名前: 必須 延滞の計上済金額: 一意の名前を使用してください。

タイプ: 必須 アカウント: その他の選択肢は次のとおりです。顧客請求先トランザクション

摘要: オプション

異なる通貨の合計を計算できる、計上済金額による延滞の合計金額。

406

関数: データベース関数を表します

いいえ: この例ではPL/SQL文を使用します。

使用可能: 算式で使用するデータ・ポイントをアクティブ化します。

選択

SQL文: このタスクには、PL/SQL文を記述するための知識が必要です

Select NVL(sum(ar.acctd_amount_due_remaining),0) from

ar_payment_schedules ar, iex_delinquencies del where

ar.payment_schedule_id = del.payment_schedule_id AND del.status in

('DELINQUENT', 'PREDELINQUENT') AND del.cust_account_id =

:cust_account_id AND del.creation_date >= sysdate -365

5. 「保存してクローズ」ボタンをクリックします。

スコアリングの定義に関するFAQ

スコアリング算式ステータスとは何ですか。

スコアリング算式ステータスは、スコアリング算式タイプの値が「トランザクション」の場合にのみ適用可能です。次のいずれかのステータスを割り当てます。

現在延滞事前延滞

スコアリング算式セグメントとは何ですか。

セグメントは、スコアリング対象のオブジェクトのサブセットです。

たとえば、日本に拠点を置く顧客とは異なる基準で、米国に拠点を置く顧客をスコアリングする場合、2つの異なる算式を作成し、それらの算式に2つの異なるセグメントを関連付けることができます。

セグメントはデータベース・ビューであり、データベース管理者が作成する必要があります。

戦略の定義

戦略の処理戦略を使用する前に、一連のプロセスが実施される必要があります。

戦略のプロセス・フローを次に示します。

407

「回収スコアリング」プログラムを実行して、回収オブジェクトをスコアリングします「回収要約データの更新」プログラムを実行して、顧客データを集計します「戦略管理」コンカレント・プログラムを実行して、それぞれの延滞オブジェクトについて戦略を作成しますそれぞれの戦略が、それに適用されたスコアに基づいて割り当てられますこのスコアによって、戦略で延滞顧客にどの程度積極的または穏やかに対処するかが決まります

戦略の処理

延滞およびスコアリング回収オブジェクト(30日期日超過や60日期日超過の請求書など)を作成しました。

次の情報が指定された2つの戦略があります。

戦略名 タスク

ソフト 1. リマインダ通知の送信2. 電話3. フォローアップ・コール4. 督促状の送信

ハード 1. 督促状の送信2. 電話3. 監督者によるコール・エスカレーション

結果

「戦略管理」プログラムが実行されると、次のスコアが生成されます。

スコア 結果

50 スコアが高い方がソフトな戦略になります

30 スコアが低い方がハードな戦略になります

分析

次の処理が行われます。

正確なスコアと一致する戦略が見つからない場合は、より積極的な戦略が割り当てられますスコアリング・エンジンから返された延滞スコアが35の場合、プログラム内の選択モジュールはランク35の戦略を検索し、見つからない場合は、有効なスコアが見つかるまで34、33と順に検索します。この例では、延滞オブジェクトにハード戦略が割り当てられます

関連トピック

顧客に戦略を割り当てるにはどうすればよいですか

回収戦略Oracle Fusion Advanced Collectionsの戦略は、実行される順序に従って相互にリンクされたタスクと呼ばれる、一連の手動または自動の活動です。

408

各タスクは、延滞金を回収するために使用される回収活動です。タスクの例には、次のものが含まれます。

回収のための顧客への電話書簡、FAXまたはEメールの送付監督者へのエスカレーションタスクがエスカレートされると、マネージャはエスカレーション通知を自動的に受け取り、タスクは回収担当に割り当てられたままになります。

注意: 複数のタスクを作成して、様々な戦略で再利用できます。

回収戦略では、次のものに基づいた活動がサポートされています。

ビジネス要件スコアリング・ルール督促プランの代替延滞トランザクションに対する回収単純なものから複雑なものまで様々な回収活動

注意: 戦略または督促プランのどちらかを使用して延滞を管理できますが、両方の方法を使用することはできません。

次のように戦略を使用します。

ビジネスを行うデータ・レベルに応じて、顧客、アカウントまたは請求先サイトに関連付けます延滞トランザクションを識別し、延滞オブジェクトをスコアリングする、Advanced Collectionsスコアリング・エンジンからの情報を利用します

戦略の設定

次の順序で戦略を設定します。

1. 回収タスクの作成2. 回収戦略の作成3. 回収のメソッド名の割当4. 戦略へのタスクの割当

戦略の処理と結果

すべてのビジネス・ユニットについて「戦略管理」コンカレント・プログラムを一度に実行して、適切な戦略を回収オブジェクトに割り当てます。

戦略はスコアリング・エンジンの結果に基づきます。コンカレント・プログラムの結果は次のとおりです。

Oracle SOA BPELによってタスクが開始および管理され、指定した個人に通知が送信されますOracle BI Publisherによって通信が送信されます

関連トピック

顧客に戦略を割り当てるにはどうすればよいですか

409

スコアリング・エンジンと戦略はどのように連携しますか

回収戦略の作成この演習では、戦略を作成し、タスクを割り当てて、それらを順番に割り当てる方法を示します。

戦略は一連の手動または自動タスクであり、これらのタスクが実行される順序に従って相互にリンクされます。戦略は次のもので構成されます。

戦略テンプレート・グループの作成: 戦略に関する一般情報を定義するために使用します顧客セグメント: この戦略のグループおよび一意の属性を識別します戦略: 戦略の様々なステージとスコアをリストしますタスク: タスクを順番にリストし、それぞれの詳細を定義します

戦略の作成

ナビゲーション: 「設定および保守」→「すべてのタスク」→「回収戦略の管理」→「タスクに進む」アイコン→戦略の管理

1. 「回収戦略の管理」セクションで「作成」アイコンをクリックします。2. 次の情報を入力します。「戦略テンプレート・グループの作成」ページ:

フィールド 値

グループ名 US Customers

戦略レベル アカウント

許容範囲当たりの戦略の変更 いいえ

有効 はい

開始日 ピック・リストから現在の日付を選択します。

終了日 空白

「顧客セグメント」セクション

フィールド 値

ビュー名 アカウント

識別子 ID

「戦略」セクション

フィールド 値

メソッド名 USA Strategy Good

最低適用可能スコア 50

メソッド名(「行の追加」アイコン) USA Strategy Bad

410

最低適用可能スコア 0

「タスク」セクション: 「USA Good Strategy」を選択

フィールド 値

順序 10

名前 Friendly Phone Call

順序 20

名前 Friendly Phone Call

順序 30

名前 Friendly Phone Call

3. 「保存してクローズ」ボタンをクリックします

関連トピック

顧客に戦略を割り当てるにはどうすればよいですか

タスクの作成この例では、手動タスクを作成する方法を示します。

それぞれの戦略は1つ以上のタスクで構成されます。手動または自動で実行されるタスクはワークフローによって駆動されます。ワークフローは、回収担当にタスクを実行するよう通知するか、自動プロセスを開始します。それぞれのタスクにワークフローが関連付けられています。

タスクは、次の2つの作業タイプのいずれかによってグループ化されます。

1. 手動: 回収担当またはスペシャリストによって実行されるタスク。タスクを完了すると、タスクはキューからクローズされます。手動タスクの例としては、個人訪問、電話通話、営業担当への連絡などがあります。

2. 自動: 自動プロセスによって実行されるタスク。これには、EメールやFAXの送信、印刷される文書の送付などのタスクが含まれます。

手動タスクの作成

ナビゲーション: 「設定および保守」→「すべてのタスク」→「回収戦略タスクの管理」→「タスクに進む」アイコン→「戦略タスクの管理」

1. 「戦略タスク」セクションで「作成」アイコンをクリックします。2. 次の情報を入力します。

フィールド 値

有効 選択

名前 Friendly phone call

411

説明 顧客の期日が少し超過したときに、友好的な電話をかける

タイプ 手動

カテゴリ 電話通話

戦略がこのタスクを実行するまで待機する時間

0日間

戦略がこのタスクを実行してから待機する時間

0日間

オプション Y

日数 1日

3. 「保存してクローズ」ボタンをクリックします。

関連トピック

顧客に戦略を割り当てるにはどうすればよいですか

「個別トランザクションの回収戦略」の有効化通常、回収戦略はクライアント・レベルで割り当てられます。ただし、ビジネス要件に応じて、これらの戦略を個々のトランザクションに割り当てることもできます。そのためには、「個別トランザクションの回収戦略」機能を有効にする必要があります。

この機能を有効にする手順は、次のとおりです。

1. 「ナビゲータ」→「自分の企業」→「オファリング」をクリックします。2. 「オファリング」ページで、「財務」を選択します。3. 「オプトイン機能」ボタンをクリックします。4. 「オプトイン: 財務」ページで、回収の「機能」アイコンをクリックします。回収機能のリストが表示されます。

5. 「個別トランザクションの回収戦略」機能の「使用可能」チェック・ボックスを選択し、変更を保存します。

注意: 「個別トランザクションの回収戦略」機能を有効にする前に、前提条件となる次の機能も有効にしていることを確認してください。

セグメントによる回収スコアリングおよび戦略割当サード・パーティ・システムでの回収タスクの自動開始または自動履行

回収スコアリングおよび戦略割当の管理

412

セグメントによるスコアリングおよび戦略割当Advanced Collectionsの「セグメントによる回収スコアリングおよび戦略割当」機能を使用すると、回収担当は顧客のスコアリングと戦略割当を柔軟に管理できるため、回収効率の向上とキャッシュ・フローの改善に役立ちます。

ビジネス・ユニット、プロファイル区分、未払額などの様々なセグメントに基づいて回収担当が顧客を分類できるようにするには、「セグメントによる回収スコアリングおよび戦略割当」機能を使用します。様々なスコアリング算式および延滞戦略グループを顧客に割り当てることができ、回収担当は事前延滞オプションを定義できます。また、事前遅延戦略グループを顧客に割り当てることもできます。

新しい「セグメントによる回収スコアリングおよび戦略割当」機能をサポートするために、AdvancedCollectionsの作業領域および「顧客」ページが拡張されました。たとえば、同じ顧客に対して実行されている複数の戦略が「顧客」ページの「戦略」タブに表示されるようになりました。さらに、設定プロセスが完了していれば、事前遅延戦略もランディング・ページに表示されます。

割当はデフォルトのスコアリング算式として定義され、延滞戦略グループ割当は各ビジネス・レベルで定義されます。スコアリング算式および延滞戦略グループが自動的に表示され、ビジネス要件に基づいて定義されたスコアリング算式や戦略グループにそれらのグループを変更できます。

関連トピック

「拡張回収」作業領域の概要

セグメントによるスコアリング算式および延滞戦略割当の定義「回収スコアリングおよび戦略割当の管理」タスクを使用して、スコアリング算式および延滞戦略割当を定義できます。「回収スコアリングおよび戦略割当の管理」タスクの「セグメント別延滞戦略割当」リージョンでセグメントを指定して、詳細な割当を入力する必要があります。セグメントは、スコアリング対象として識別された様々なオブジェクトのセットまたはサブセットとして定義されます。セグメンテーションは各ビジネス・ユニットおよびプロファイル区分を通じて実装され、「顧客」、「アカウント」または「サイト」ビジネス・レベルのセグメンテーションを定義します。たとえば、セグメント名「Business Level + BU+ Profile + High / Low Amount」を定義し、それぞれのセグメントについてデフォルト値を指定します。

「金額超過下限しきい値」または「金額超過上限しきい値」と、未払額が下限しきい値を下回る場合または上限しきい値を上回る場合に使用する、対応する延滞戦略グループを定義します。一方または両方のしきい値を定義しても、どちらも定義しなくても構いません。

金額超過下限しきい値: 顧客の未払額がこの下限しきい値を下回ると、「しきい値に満たない戦略グループ」が使用されます。しきい値に満たない戦略グループ: 顧客の未払額が「金額超過下限しきい値」より少ない場合の戦略グループ割当。金額超過上限しきい値: 顧客の未払額がこの上限しきい値を上回ると、「しきい値を超過した戦略グループ」が使用されます。しきい値を超過した戦略グループ: 顧客の未払額が「金額超過上限しきい値」より多い場合の戦略グループ割当。

次の項では、デフォルトのスコアリングおよび戦略割当を指定する様々なシナリオを定義します。

1. 様々なビジネス・レベルのスコアリングおよび戦略割当: 3つのビジネス・レベルすべてについて、

413

デフォルトのスコアリング算式と戦略グループを設定できます。スコアは、顧客のビジネス・レベルのデフォルト・スコアリング算式と、各ビジネス・レベルのデフォルト戦略グループに基づいて割り当てられる延滞戦略に基づいて計算されます。

2. ビジネス・ユニットによるスコアリングおよび戦略割当: スコアリング算式は、ビジネス・ユニットに応じて異なります。選択したビジネス・ユニットについてそれぞれ異なるスコアリング算式と戦略グループを使用でき、残りのビジネス・ユニットには1つのスコアリング算式と戦略グループを使用できます。

3. プロファイル区分によるスコアリングおよび戦略割当: 異なるプロファイル区分に属する延滞顧客とそのスコアは、異なるスコアリング算式に基づいて計算され、異なる戦略グループに基づいて戦略が割り当てられます。

4. 金額超過下限しきい値によるスコアリングおよび戦略割当: 各ビジネス・ユニットの金額超過下限しきい値と、しきい値に満たない場合の戦略グループを指定できます。顧客の未払額が金額超過下限しきい値より少ない場合、しきい値に満たないときに使用するように指定された戦略グループが割り当てられます。それ以外の場合は、割当で定義されている延滞戦略グループがデフォルトで割り当てられます。

5. ビジネス・ユニットとプロファイル区分によるスコアリングおよび戦略割当: スコアは、その特定のビジネス・ユニットとプロファイル区分に対応する様々なスコアリング算式に基づいて計算され、様々な戦略グループに基づいて戦略が割り当てられます。

6. 金額超過下限しきい値と金額超過上限しきい値によるスコアリングおよび戦略割当:

顧客の未払額が金額超過下限しきい値より少ない場合、しきい値に満たないときに使用するように指定された戦略グループが割り当てられます。顧客の未払額が金額超過上限しきい値より多い場合、しきい値を超過したときに使用するように指定された戦略グループが割り当てられます。それ以外の場合は、割当で定義されている延滞戦略グループが割り当てられます。

関連トピック

「拡張回収」作業領域の概要

セグメントによる事前遅延戦略割当の定義「回収延滞管理」プロセスでは、ビジネス・レベルと事前延滞オプションに基づいて、顧客、顧客トランザクション、アカウントおよびサイトの延滞ステータスと事前延滞ステータスが適切に識別されます。

「回収スコアリングおよび戦略割当」スケジュール済プロセス

「回収延滞管理」プロセスが正常に完了したら、2つ目のプロセス「回収スコアリングおよび戦略割当」を実行します。このプロセスでは、セグメンテーションに基づいてスコアリング算式が割り当てられ、スコアが計算された後、さらにセグメンテーションに基づいて戦略が割り当てられます。

「回収スコアリングおよび戦略割当」スケジュール済プロセスを実行する手順は、次のとおりです。

1. 「スケジュール済プロセス」にナビゲートします。2. 「新規プロセスのスケジュール」をクリックします。3. プロセスの実行に必要なパラメータを入力または選択します。4. 「発行」をクリックします。

注意: プロセスを実行する前に、「回収スコアリングおよび戦略割当の管理」を有効にする必要がありま

414

す。

「回収要約データの更新」を実行する手順は、次のとおりです。

このプロセスでは、延滞顧客と戦略タスクに関する情報タイルがある「回収」ランディング・ページのデータがリフレッシュされます。

1. 「回収」作業領域にナビゲートします。2. 「回収」作業領域が表示され、4つの情報タイルの情報がすべて表示されます。延滞顧客またはアカウントを選択します。

延滞顧客および顧客の対応する詳細がデフォルトで表示されます。セグメントによるスコアリングおよび戦略割当の管理の設定データに基づいて、スコアが計算され、延滞戦略が割り当てられます。また、設定情報に基づいて、事前延滞となっている顧客に事前遅延戦略が割り当てられます。1つの顧客が延滞と事前延滞に同時に該当することがあるため、延滞戦略と事前遅延戦略を同時に実行します。

3. 「戦略」タブを選択して、戦略の詳細を表示します。この場合、両方の戦略が実行中であり、戦略タイプ、および戦略割当の名前が参照用に表示されます。

関連トピック

「拡張回収」作業領域の概要

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

415

19c

現預金のための売掛/未収金クレジットの実装

14 請求管理の定義この章の内容は次のとおりです。

請求管理の設定

請求管理の設定Oracle Fusion Bill Managementを使用すると、未回収トランザクションやクレジット・メモのレビュー、係争のモニタリング、オンライン支払など、様々な受取手形プロセスが有効になるように、請求管理を設定できます。請求管理を構成したら、外部ユーザー(顧客アカウント)を登録し、様々な支払オプションを処理するためのシステム・オプションを定義できます。

請求管理を設定する方法は、次のとおりです。

1. 標準参照を使用して請求管理を有効にします。2. 内部ユーザーにデータ・アクセスを付与します。3. システム・オプションを管理してプリファレンスを有効にします。

設定が完了すると、ユーザーは次のような主要な機能を使用できるようになります。

オープン・トランザクションとクローズ済トランザクションの分析トランザクションのダウンロード係争のモニター支払オプションの処理

請求管理の有効化請求管理で使用可能な標準参照を使用して、アプリケーション機能を有効にする必要があります。

416

請求管理を有効にするには、次のステップを実行します。

1. 「設定および保守」作業領域で、「オファリング」として「財務」を選択します。2. 「標準参照の管理」に移動します。3. 「標準参照の管理」ページで、参照タイプARB_FEATURESを検索します。4. 参照コードBILL_MANAGEMENTを同じ参照タイプに追加します。5. 変更を保存します。

内部ユーザーへのデータ・アクセスの付与ユーザーにはジョブ・ロールが割り当てられます。これらのユーザーに、ビジネス・ユニットに属するデータおよびトランザクションにアクセスするための権限を付与できます。

内部ユーザーにデータ・アクセスを付与するには、次のステップを実行します。

1. 「設定および保守」作業領域で、「オファリング」として「財務」、「機能領域」として「ユーザーおよびセキュリティ」、「タスク」として「ユーザーのデータ・アクセスの管理」を選択します。

2. 「ユーザーのデータ・アクセスの管理」ページで、ユーザー名、ロール、セキュリティ・コンテキストおよびセキュリティ・コンテキスト値を選択して、ユーザーのデータ・アクセスを作成します。

3. 変更を保存します。

システム・オプションの管理システム・オプションを使用して、外部ユーザー・ロール割当や、トランザクションおよび支払処理の条件を設定したり、プリファレンスを有効にしたり、外部ユーザーのEメール通知を設定できます。

外部ユーザーの請求管理システム・オプションを管理する方法は、次のとおりです。

1. 「設定および保守」作業領域で、「オファリング」として「財務」、「機能領域」として「請求管理」、「タスク」として「請求管理システム・オプションの管理」を選択します。

2. 「登録」セクションで、「顧客買掛/未払金スペシャリスト」を選択して外部ユーザーにロールを割り当てます。

3. 「トランザクションおよび支払処理」セクションで、トランザクション履歴(月数)、年齢調べ方法、および許可される最大先日付支払日数を選択します。

4. 「プリファレンス」セクションで、必要なプリファレンスを設定します。ビジネス・ユニットごとに構成できるプリファレンス項目のリストを次に示します。

銀行支払: 銀行を介した支払を制限または許可します。クレジット・カード支払: クレジット・カードによる支払を制限または許可します。

注意: クレジット・カード・サービスは、現在、Oracle Cloud実装では使用できません。

クレジット・カード支払限度: クレジット・カードの限度額に基づいて支払を制限します。限度額が支払金額合計を下回る場合、支払は制限されます。元帳通貨のみ: 元帳通貨のみを使用した支払を制限または許可します。請求書の印刷: 請求書の印刷を制限または許可します。

5. 「通知」セクションで、ビジネス・ユニットごとにユーザー登録プロセスのEメール通知を構成しま

417

す。ビジネス・ユニットを選択し、必要なEメール・アドレスを入力します。6. 変更を保存します。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

418

19c

現預金のための売掛/未収金クレジットの実装

用語集D | E | F | H | I | P | S | T

D

買掛/未払金文書支払う準備ができた品目。Oracle Fusion Payablesでの賦払に相当します。

E

抽出支払ファイルに関連するデータのスーパーセットを含むXMLファイル。

F

フォーマットOracle Fusion Business Intelligence Publisher (BI Publisher)テンプレートやトランザクション処理中に実行する検証で使用される属性などのフォーマット属性を結合する、Oracle Fusion Paymentsにおける重要な設定エンティティ。FTP

ファイル転送プロトコル(File Transfer Protocol)の頭字語。一般的にはインターネットによってコンピュータ・ファイルを転送するためのシステム。

資金取得支払プロファイル(Funds Capture Payment Profile)

資金取得処理のルールを保持する重要な設定エンティティ。

419

H

HTTPHypertext Transfer Protocolの頭字語。クライアント/サーバー・コンピューティングで一般的に使用されている、リクエストとレスポンスの標準。HTTPでは、Webブラウザまたはスパイダがクライアントとして機能し、Webサイトをホストするコンピュータで実行されているアプリケーションがサーバーとして機能します。クライアントはHTTPリクエストを送信し、ユーザー・エージェントとも呼ばれます。応答するサーバーはHTMLファイルやイメージなどのリソースを格納または作成し、オリジン・サーバーとも呼ばれます。ユーザー・エージェントとオリジン・サーバーの間には、プロキシ、ゲートウェイ、トンネルといった複数の仲介サービスが存在することがあります。HTTPSHyper Text Transfer Protocol Secureの頭字語。主に、セキュアで安全なインターネット・トランザクションを目的として開発されたプロトコルです。HTTPSでは、オンライン・バンキングなど、セキュアなE-Commerceトランザクションが可能です。

I

賦払連続的な固定回数で支払うために、借入金またはその他の買掛/未払金合計を分割した複数部分のいずれか。

内部受取人顧客(支払人)から資金を受け取る当該会社、またはそのいずれかのビジネス・ユニット。受取人は、クレジット・カード支払、デビット・カード支払、銀行口座からの口座引落、または銀行に送信される受取手形トランザクションによって顧客から資金を受け取ります。

P

支払プロセス・プロファイル買掛/未払金文書、支払および支払ファイルごとに処理動作を導出する設定エンティティ。

支払システム財務決済サービスを提供する外部組織。支払システムは、当該会社が銀行口座を持つ銀行にすることも、当該会社と財務ネットワークを接続するサード・パーティ・プロセッサにすることもできます。

支払システム・アカウント資金取得フローにおいては、支払システムと内部受取人の関係の表現として、承認、決済または決済バッチを支払システムに伝送できるようにします。支出フローにおいては、支払システムと内部支払人の間の関係の表現として、支払ファイルまたは正支払ファイルを銀行またはその他の支払システムに伝送できるようにします。

420

S

サーブレットリクエスト/レスポンス・プログラミング・モデルを経由してアクセスされるアプリケーションをホストするサーバーの機能を拡張するために使用されるJavaプログラミング言語クラス。サーブレットはあらゆるタイプのリクエストに応答できますが、Webサーバーによってホストされるアプリケーションを拡張するために使用されます。このようなアプリケーションのために、Javaサーブレット・テクノロジではHTTP固有のサーブレット・クラスを定義しています。

決済バッチ1つのファイルにまとめて支払システムに送信されるトランザクション(通常は清算およびクレジット)のグループ。精算バッチは、通常、プロセッサ・モデルの支払システムによって使用されます。

T

伝送構成支払ファイルなどのファイルを伝送するための構成。

伝送プロトコルFTPやSecure HTTPなど、データを電子的に伝送するために使用される方法。

このページは役に立ちましたか?

© Oracle About Oracle Contact Us Products A-Z Terms of Use and Privacy Ad Choices

421