リリース11i
B25742-01
目次
戻る
次へ
| Oracle Order Managementインプリメンテーション・マニュアル リリース11i B25742-01 | 目次 | 戻る | 次へ |
与信管理プロセスの最終目標は、日々の業務の結果として組織が想定する財務リスクを最小限に抑えることです。Order Managementの与信チェック機能は、受注を与信チェック・ビジネス・ルールに従って検証およびリリースするプロセスです。与信ルール、システム・パラメータおよび与信プロファイルを使用して、Order Managementの与信チェックは、顧客が組織に対して受注を処理し、支払前に出荷できるほど十分な与信の可用性を持っているかを検証します。
Order Managementでは、顧客の受注または受注明細に対して与信チェックを行い、与信設定に違反している受注または受注明細を自動的に保留にできます。Order Managementの与信チェックを効果的に使用するには、実行時期やパフォーマンス・ファクタを十分考慮するだけでなく、機能上の構成要素を完全に理解している必要があります。例を次に示します。
事前に指定したワークフロー・イベントにおいて、リアルタイム取引データや事前計算済の債務金額の要約に対して自動的に与信チェックを実行できます。事前計算済の債務金額は次のいずれかです。
特定の時点で要約されたリアルタイム取引データ
Oracle Order Management債務表にインポートされた債務金額
特定の時点で要約されたリアルタイム取引データとOracle Order Management債務表にインポートされた債務金額の合計
債務金額全体を計算するときに使用する通貨を指定して、単一組織内で通貨の異なる受注間の与信チェックを実行できます。
システム内のすべての営業単位間で、顧客のアカウント・レベルでの与信チェックを実行できます。
Oracle Applications内で保守されている与信チェック処理と債務残高を利用して、外部取引の与信チェックを実行できます。
Order Managementの与信チェックには、次の機能があります。
受注および明細のワークフローを介してフローを継続するための、既存の与信限度に対する受注および明細の検証
適切な当事者への与信保留通知など、受注または明細レベルでの与信保留
受注または明細の与信保留に対する与信再割当処理の手動リリースまたは予定作成機能
与信限度を超える受注の承認
与信処理を効率的に管理し、与信保留をタイムリな方法で処理するレポート・ツールと問合せツール
ビジネス慣習によってはすべての受注ではなく、与信リスクの可能性がある受注のみを与信チェックする場合があります。次のような受注は与信チェックから除外できます。
指定のタイプ。たとえば、社員向け販売や社内受注を与信チェックから除外できます。与信チェック・ルールは、受注タイプに割り当てられます。受注タイプの設定時に「与信チェック・ルール」フィールドを空白にすると、その受注タイプの受注は与信チェックから自動的に除外されます。
指定の顧客。たとえば、製造業者が最大手の顧客の全受注を与信チェックから除外するとします。Oracle Order ManagementとOracle Receivablesでは、この顧客の個別の顧客プロファイルで「与信チェック」フラグをオフにした場合、特定の顧客を与信チェックから除外できます。
指定の顧客区分。たとえば、製造業者が内部顧客の全受注を与信チェックから除外するとします。この場合、すべての内部顧客を1つの「顧客プロファイル区分」にグループ化して、そのプロファイル区分の顧客が与信チェックから除外されるように設定できます。Oracle Order ManagementとOracle Receivablesでは、顧客プロファイル区分の設定時に「与信チェック」フラグを無効にできます。この顧客プロファイル区分が割り当てられた顧客は、与信チェックから除外されます。
指定の顧客請求先所在地。たとえば、製造業者が、ある最大手顧客の本社に請求する受注を与信チェック処理から除外するとします。Oracle Order ManagementとOracle Receivablesでは、個別の請求先サイトに親顧客と異なる取引プロファイルを設定できます。請求先サイト・プロファイルの設定時、「与信チェック」フラグの設定によって、その所在地に請求される受注を与信チェックするかどうかが決まります。
指定の支払条件。たとえば、支払条件が現金引換の受注明細を与信チェック処理から除外できます。Oracle Order ManagementとOracle Receivablesでは、支払条件で「与信チェック」フラグも指定できます。このフラグをオフにすると、その支払条件の受注明細は、自動的に与信評価から除外されます。与信チェックがオンになっている支払条件の受注明細のみ、与信限度額と比較されます。
取引約定に従って支払われる受注明細。これらの明細は前払で有効になるため、それらを与信チェックする必要はありません。
支払タイプが「クレジット・カード」の受注。これらの受注は与信チェックのかわりにクレジット・カード認証を受けます。
Oracle Order Managementを使用して与信管理方法を定義する場合、次のようなOracle与信チェックの概念を十分に理解する必要があります。
与信プロファイル
与信チェック・ルール
与信使用ルール
与信チェック処理は受注または受注明細に対して実行できます。与信チェックを実行するかどうかは次のすべてに基づいて判断します。
与信チェック・ルールの定義と定義に添付された受注タイプ
受注または明細の支払条件
使用可能な与信プロファイル
これら3つのレベルすべてで与信チェックが有効な場合にのみ、受注または明細に対して与信チェックが行われます。いずれかのレベルで与信チェックが無効である場合は、その受注または明細に対する与信チェックは行われません。
Order Managementで与信チェックを実行する場合、信用価値を判断する場合にどのタイプの債務を使用するか決定します。Order Managementにより、リアルタイム取引データや債務要約表に格納された現在の債務金額に対して与信チェックを実行できます。
リアルタイム取引データは、与信チェックを起動した時点で要約されたすべての関連取引です。
現在の（事前計算済）債務金額は次のいずれかになります。
特定の時点で要約されたリアルタイム取引データ
「与信債務のインポート」コンカレント・プログラムを使用してインポートした債務金額
「与信チェック・ルール」を定義する場合、与信チェックを実行するときに利用する債務のタイプを指定します。
Order Management内の「与信チェック・ルール」により、与信チェックを実行する際の信用価値を判断でき、顧客の与信債務を判断する各種オプションが提供されます。
「与信チェック・ルール」はOrder Management取引タイプに添付されています。「取引タイプ」ウィンドウ内で、与信チェック・ルールは、与信チェック処理を実行する事前に指定したイベントに割り当てられています。たとえば、記帳前に高レベルな与信チェックを実行する一方で、製品を顧客に出荷する前により詳細な管理を適用する場合があります。
Order Managementでは、対応する受注または明細のワークフロー・プロセス内で記帳、ピック・リリースおよび発注リリース（直接出荷の場合)、梱包または出荷の時点で個別の与信チェック・ルールを使用するように割り当てることができます。記帳、ピック・リリースおよび発注リリース（直接出荷の場合)、梱包または出荷の組合せに対して与信チェック・ルールを選択することで、受注または明細のプロセス内の複数の時点で与信チェックを実行することもできます。
Order Managementの与信チェック・ルールでは、次を管理できます。
与信チェック・レベル
与信チェック保留レベル
債務計算時に使用する通貨換算タイプ
与信チェックの検証に使用する債務方法
オープン売掛金残高、未請求受注残高、運送費および特別手数料、または税金の算入
保留管理手順
適切な担当への与信保留の通知
与信チェック処理は、受注ヘッダーまたは受注明細のレベルで実行されます。また、与信チェックを起動するには、受注および受注明細に使用する支払条件を使用可能にする必要があります。「支払条件」を参照してください。
受注ヘッダー・レベル: 受注レベルの与信チェックでは、明細レベルに指定されている様々な請求先サイトは無視され、ヘッダー・レベルの情報が排他的に使用されます。また、受注（ヘッダー）レベルで定義されている顧客請求先に添付された与信プロファイルが使用されます。与信チェックでは受注合計が使用され、ヘッダー・レベルで添付されている与信プロファイルと対照して与信債務が評価され、保留は常にヘッダー・レベルで適用されます。
注意: 受注ヘッダー・レベルの与信チェックでは、前のバージョンの与信チェックとの下位互換性を実現します。
受注明細レベル: 明細レベルの与信チェックでは、受注明細レベルのデータを使用します。異なる請求先サイトに添付された受注明細があり、それらの請求先サイトに添付された特定の与信プロファイルを使用する場合は、受注明細レベルの与信チェックを行う必要があります。
また、システムで顧客関連を定義しており、それをOrder Managementで使用する場合にも、明細レベルの与信チェックを使用できます。この場合、異なる顧客が所有する様々な請求先サイトに添付された明細を含む受注を作成できます。
受注明細レベルの与信チェックを使用している場合、受注または受注明細において与信チェックの検証に失敗した受注または明細を与信保留できます。与信チェック保留は与信ルールの定義に従って自動的に行われ、顧客の与信債務が与信チェック検証に成功する時点まで引き下げられたときに、受注または受注明細の与信保留を自動的に解除できます。「与信チェック・プロセッサ」コンカレント・プログラムを特定の間隔で実行するように予定作成することで自動的に与信保留を解除できます。
Oracle Order Managementの以前のリリースでは、与信チェック処理による受注または明細の与信チェック保留を手動で解除できました。ただし、手動で解除した与信保留に対して追加の与信チェックは行われませんでした。
現在では、受注または明細の与信保留が手動で解除された場合に、追加の与信チェックを行うかどうかを指定できます。「手動リリース許可に必要な日数」フィールドとともに「手動リリースの上書き」チェック・ボックスを使用して、受注または明細の与信保留を手動で解除する場合に追加の与信チェックを先送りする期間（日数）を定義できます。
Order Management取引タイプの定義は、手動で解除された保留（取引タイプの定義内での記帳、ピック・リリースおよび発注リリース（直接出荷の場合）、梱包または出荷に入力した与信チェック・ルール）に対して追加与信チェック処理を行うかどうかを制御します。
このフィールドと「手動リリースの上書き」チェック・ボックスを使用して、手動で解除した保留を許可し、追加の与信チェック処理によって上書きされない期間（日数）を定義できます。
たとえば、「手動リリース許可に必要な日数」フィールドの値を15に設定し「手動リリースの上書き」チェック・ボックスを使用可能にした与信チェック・ルールを定義したとします。また、この与信チェック・ルールは、記帳および出荷の与信チェック・ルールとして取引タイプに割り当てられているとします。記帳後に与信チェック保留から受注または明細を手動で解除し、15日以内に受注または受注明細を出荷する場合、Order Managementでは与信チェックを実行できなくなります。ただし、15日目以降に出荷する場合は、再度与信チェック処理を起動できます。
与信チェック・ルールの換算タイプにより、通貨間での固定換算レートをモデル化したり、平均換算レートを使用できます。与信チェックの実行時に、与信制限通貨は必ずしも機能上の通貨と同じである必要はありません。換算タイプはOracle General Ledger換算レート・タイプウィンドウ内で定義する値に制限されます。
使用する債務方法を決定することで、与信チェック時の信用価値の検証方法を選択できます。
前バージョンの与信チェックでは、基になる取引表にアクセスして顧客債務を算出していました。与信チェック要求が行われると、基になる取引表が合計され、顧客の残高情報が作成されていました。
パフォーマンスを改善するため、Oracle Order Managementには、事前計算済の債務の使用という追加オプションが組み込まれました。このオプションを使用して、与信チェックでは要約表に格納された残高情報に対して債務を検証します。要約表はビジネス慣習による必要性に従って逐次更新され、表への更新内容はコンカレント・プログラムを実行して行います。このプログラムはOracle ReceivablesおよびOrder Managementの両方の取引表にアクセスするため、特定のビジネス・ニーズにあわせて定期的に実行するように予定作成する必要があります。
与信債務の計算の際に、与信ルール・チェック定義に次の与信関連詳細を含めることも除外することもできます。
オープン売掛金残高
未請求受注残高
運送費および特別手数料
税金
リスクのある支払
受注または受注明細で与信チェックが失敗した場合は必ず通知するように選択できます。通知は受注の作成者に送信されます。
Order Management受注取引タイプでは、与信チェックの実行時期を管理できます。また、Order Management取引タイプに与信チェック・ルールを割り当てることにより、与信債務（未払与信残高）の計算時に利用する与信チェック・ルールを管理することもできます。
「受注管理取引タイプ」ウィンドウで取引タイプに与信チェック・ルールを割り当てる場合、その受注タイプを使用するすべての受注または受注明細に対して与信チェックを使用可能にします。「与信チェック・ルール」リージョンの「記帳」、「ピック・リリース」および「発注リリース」（直接出荷の場合）、「梱包」または「出荷」フィールド内で与信チェック・ルールを選択することによって、受注タイプの与信チェック・ルールを選択します。
同一の与信チェック・ルールを単一の機能（フィールド）、複数の機能またはすべての機能に割り当てたり、ビジネス・ニーズにあわせて各機能に異なる与信チェック・ルールを使用できます。
支払条件には、請求書の支払の支払期日と値引日を指定します。また、与信チェックを管理するために支払条件を使用するかどうかを選択することもできます。支払条件の「与信チェック」チェック・ボックスを選択して、支払条件ごとに与信チェックを使用可能にできます。これにより、不必要な与信チェックを行わないようにできます。
支払タイプが「クレジット・カード」の受注を除くすべての受注が、支払条件に関係なく債務計算の実行時に組み込まれます。受注をクレジット・カードで支払い、すでに承認されている（承認日がNULL値でない）場合は、債務には組み込まれません。
与信プロファイルでは、通常の業務で耐える最大財務リスクを定義します。（顧客マスター・レコードの）「標準顧客」ウィンドウの「クレジット」リージョンにある「与信チェック」チェック・ボックスは、与信チェックを実行するために使用可能にする必要があります。次のレベルで与信プロファイル情報を定義できます。
顧客および顧客サイト: このプロファイルでは、個別の顧客または顧客サイトに対する与信ポリシーを定義します。「顧客プロファイル区分」からデフォルトの与信ポリシーを受け入れたり、特定の顧客にあわせて与信限度額をカスタマイズできます。
「プロファイル区分」を変更し、その変更内容を個別の「顧客プロファイル」に適用することで、与信ポリシーの変更を実装できます。複数通貨与信チェックの設定については、現行の制限事項を確認してください。
組織: このタイプの与信プロファイルを使用して、与信管理および与信チェックに対する組織（営業単位）の与信ポリシーを定義します。顧客または顧客サイトの与信プロファイルが見つからない場合は、デフォルトとして使用されます。
組織デフォルトは、顧客プロファイル階層のより高いレベル（顧客サイト-顧客-組織デフォルト）を提供します。営業単位レベルでの履行済与信プロファイルは、顧客またはサイト・レベルで定義された与信限度額を持たない顧客に対して強制的に与信チェックを行います。
品目カテゴリ: 品目カテゴリ与信プロファイルにより、Order Managementの品目カテゴリごとに与信情報を定義できます。
品目カテゴリ与信プロファイルは、顧客の与信プロファイルから完全に独立しています。品目カテゴリ与信チェックでは、事前定義したカテゴリの与信限度額を超えた取引額に対して与信保留を行います。
品目カテゴリ与信プロファイルを使用して、保険補償範囲のサービス明細などの与信限度額をモデル化し、事前定義した限度額を超える資材を出荷しないようにできます。
次のエンティティ間で与信情報を設定するため、与信チェック・ルーチンにより組込み階層が提供されています。
顧客サイト
顧客
組織デフォルト
顧客サイトと顧客の与信プロファイルが存在しない場合、組織デフォルト与信プロファイルが使用されます（存在する場合）。
Oracle Order Managementによりグローバル（複数の営業単位間の）与信チェックを実行できます。グローバル与信チェックでは、営業単位に関係なくすべての組織データが与信チェック処理中に考慮されます。与信使用ルールを定義する際に「グローバル債務」チェック・ボックスを選択すると、グローバル債務与信チェックが使用可能になります。
グローバル与信チェックは現在、与信チェック階層の次のレベルでのみ使用可能です。
顧客レベル与信チェック: グローバル与信チェックでは、すべての営業単位の顧客レベルで定義した与信限度全体が使用されます。
組織デフォルト・レベル与信チェック: グローバル与信チェックでは、組織内のすべての営業単位の組織レベルで定義した与信限度全体が使用されます。
与信チェック・エンジンは、与信チェックに利用する限度全体（階層内のどのレベルか）を特定し、営業単位すべての与信債務を計算し、選択した与信限度全体と計算済債務を検証します。
指定する通貨間で与信限度を共有することで、複数通貨の与信チェックを実行できます。
単一通貨の与信チェックでは、その通貨で顧客の債務を管理する場合、各通貨の与信限度プロファイルを定義する必要があります。つまり、すべての通貨が与信チェックでは個別に扱われます。
複数通貨の与信チェックでは、与信プロファイルは1つ（USドルなど）のみ定義し、他の通貨でそれを共有する必要があります。
使用ルール・セット: 使用ルール・セットは、特定の与信チェック処理に関わる通貨のセットを定義します。使用ルール・セットでは、（取引通貨に基づいて）与信限度での使用に適格な取引を指定します。
使用ルール・セットは、顧客プロファイル区分または与信プロファイル（顧客、顧客サイト、品目カテゴリまたは組織など）に割り当てることができます。使用ルール・セットを与信プロファイルに割り当てない場合、与信チェックは単一通貨与信チェックとして実行されます。
Order Managementのこのリリースでは、Oracle与信チェック処理およびOrder Management内で保守されている債務残高を利用して、外部金額の与信チェックを実行できるようになりました。次の表に示す相違点を除き、APIが実際に実行する与信チェック処理は、Order Managementの与信チェック・エンジンと同じです。
| OM与信チェック・エンジン | 外部の与信チェックAPI |
|---|---|
| 与信チェック・ルールに対して「品目カテゴリ」フラグが使用可能になっているかどうかを検証します。使用可能な場合は、受注の各品目カテゴリに対して品目カテゴリ与信チェックを実行します。 | 品目カテゴリの限度はチェックされません。与信チェック・ルールで「品目カテゴリ」フラグが使用可能になっている場合は、APIがエラーになります。 |
| 顧客プロファイルおよび支払条件に対して「与信チェック」フラグが指定されていることを確認します。これらの品目のいずれかが使用可能ではない場合は、受注に対して与信チェックを実行しないでください。 | 「支払条件」の「与信チェック」フラグ設定は無視します。デフォルト/顧客/サイト与信プロファイルで指定された「与信チェック」フラグのみ、与信チェックを実行するどうかが検証されます。 その他については、APIがコールされたときに与信チェックが必要であるとみなされます。与信チェックを行うかどうかはコーリング・プログラムによって判別されます。 |
| 与信チェック・ルール設定に選択された与信チェック・レベル（受注または明細）により、与信エンジンが実行するレベルが決定されます。 | APIでは、受注レベルの与信チェックを利用する与信チェック・ルールのみが許可されます。明細レベルの与信チェックはサポートされておらず、明細レベルの与信チェック・ルールを指定するとエラーになります。 |
| 「保留通知の送付」チェック・ボックスで与信チェック・ルールが使用可能な場合、受注に与信保留が適用されたときに、与信チェック・エンジンにより受注の作成者にワークフロー通知が送信されます。 | APIは、いずれの通知も送信しません。APIは与信チェック・ルールで設定された「保留通知の送付」フラグを無視します。 |
| 受注が与信チェックに失敗すると、与信チェック保留が適用されます。保留には失敗の事由が含まれています。 | 受注が与信チェックに失敗すると、失敗結果の他にコーリング・プログラムに事由が戻されます。受注に対する与信チェック保留の適用など、適切な処理が行われるかどうかはコーリング・プログラム次第です。 |
与信チェック・ルール、請求先サイトおよび取引額と通貨が指定されている場合、APIはOracle Applications内の与信限度と債務に対して金額を与信チェックし、与信チェックの結果を戻します。チェック結果に基づいて、コーリング・ルーチンが適切な処理を行います。
PL/SQLプロシージャを実行して外部の与信チェックAPIを利用できるカスタム・プログラムを作成する必要があります。外部システムの各受注の場合は、外部の与信チェックAPIをコールしてOracle Order Management内に格納された債務データに対して与信チェックを行う必要があります。コール実行前に、次の点を確認します。
外部取引のすべての明細を、利用する与信チェック・ルールとともに単一金額と単一通貨にグループ化すること。
外部取引と関連付けるOracle Applications内の適切な顧客（請求先サイト）を決定すること。
APIにより、与信チェックの結果が戻されます。
チェック結果に応じて、カスタム・プログラムは与信保留の適用など受注に対して適切な処理を実行できます。
Oracle Order Managementのクレジット・カード承認機能により、Webストアなど、多数の新しいチャネルから受注を受け入れることができます。Order Managementでは、支払方法としてクレジット・カードが使用される受注の承認が取得され、実際の資金獲得に必要な情報がOracle Receivablesに渡されます。受注がクレジット・カード支払であることを指定し、その取引をOracle iPayment経由で承認できます。また、前払機能または頭金機能を使用する場合に請求の発生を待たずに、記帳時点でクレジット・カードから資金を回収できます。この章では、OracleのE-Business Suiteのこのコンポーネントで提供される主要機能を説明します。
Oracle Order Managementでは、支払確認の分野の機能が拡張されています。クレジット・カードを使用して注文した品目に対して支払い、Oracle iPaymentを通じて発行機関から承認を受けたり、実際に資金を回収できます。ここでは、主要な設定オプションとその機能など、Oracle Order Managementのクレジット・カード・ソリューションの様々な機能と、企業での使用方法について説明します。
与信チェックとクレジット・カード承認は、企業が受注した商品およびサービスに対する支払を受け取ることを保証します。Oracle Order Managementでは、クレジット・カード機能は支払検証を使用して与信チェックと組み合されています。「支払の検証」により、支払タイプがクレジット・カードか、その他の方法であるかが判別されます。支払タイプがクレジット・カードの場合は、iPaymentにより情報が処理されます。
リリース11以上のOracle Receivablesには、Oracle Web Customersや他のWebフロント・エンドのユーザーがクレジット・カード支払用のアカウントを獲得するための機能が含まれるようになりました。Oracle Order Managementがクレジット・カード・データをARに提供するように拡張されるまで、Oracle Receivablesは自動インボイス・インポートの前に実行されるプリプロセッサを通じて、クレジット・カード情報を取得していました。そのプリプロセッサは、Oracle Order EntryとiPaymentの表を読み込み、クレジット・カード獲得機能に必要なデータを取得します。Oracle Order Managementのクレジット・カード機能では、Oracle Receivablesのプリプロセッサを実行する必要はなくなりましたが、実際のクレジット・カード支払の処理に必要なすべての会計および回収アクティビティについては、引き続きOracle Receivablesに依存しています。
Oracle Order Managementには、クレジット・カードを受注または受注明細に対する支払方法として受け入れることができる機能が用意されています。受注金額全体の支払に使用するクレジット・カードを、受注ごとに入力または選択できます。
次に、iPayment承認フローの例を示します。
受注ヘッダー入力中に、支払タイプ「クレジット・カード」を選択します。
顧客の基本クレジット・カード番号、失効日およびカード保有者名のデフォルトは、買掛管理の銀行口座表から取り込まれます。この基本クレジット・カードを上書きするには、この顧客の「AP銀行口座」に設定されている他のクレジット・カードから選択する方法と、新規クレジット・カード情報を入力する方法があります。
すべての明細情報を含めて残りの受注情報を入力し、受注を記帳します。
Oracle Order ManagementによりiPaymentサーバーがコールされ、税、運送費およびその他手数料から取引約定を差し引いた受注金額全体に対する承認が取得されます。
iPaymentからは、リスク・コードとともに承認または却下が戻されます。承認コードは受注ヘッダーに記録され、受注がワークフロー内で進行します。承認が却下されるか、受入不能な高リスク・ファクタが戻されると、その受注は問題が解決するまでOracle Order Managementで保留にされます。
受注がピックされて出荷され、請求インタフェース中にクレジット・カード情報がOracle Receivablesに渡されます。ARでは、資金獲得とすべての会計取引が処理されます。
Oracle Order Managementでは、請求の発生を待たずに、記帳時点でクレジット・カードの資金を回収できます。次に、iPayment承認前払フローの例を示します。
受注ヘッダー入力中に、支払タイプ「クレジット・カード」を選択します。
前払属性が選択されている支払条件を選択します。
顧客の基本クレジット・カード番号、失効日およびカード保有者名のデフォルトは、買掛管理表から取り込まれます。この基本クレジット・カードを上書きするには、この顧客の「AP銀行口座」に設定されている他のクレジット・カードから選択する方法と、他の必要な情報とともに新規クレジット・カード番号を入力する方法があります。
すべての明細情報を含めて残りの受注情報を入力し、受注を記帳します。
Oracle Order Managementにより、Receivables入金APIがコールされ、クレジット・カードから資金を獲得して、その資金の受入が作成されます。獲得金額は、税、運送費およびその他手数料から取引約定を差し引いた受注金額全体です。
Receivablesは作成した受入を参照する支払セットIDを戻します。この処理でエラーが発生した場合は、Oracle Order Managementにより問題が解決するまで受注が保留されます。
受注処理の任意の時点で、この受注に関連付けられたReceivablesの入金を「受注ヘッダー」の「入金の表示」を使用して、Order Managementから表示できます。この処理により「売掛管理領収書」ウィンドウを開きます。
受注が履行され、クレジット・カード情報および支払セットIDが請求インタフェース中にReceivablesに渡されます。ARにより入金と請求書が照合され、すべての会計取引が処理されます。
Oracle Order Managementで実行できる承認には3つのタイプがあります。
クレジット・カードは、前述のように自動的に承認できます。そのためには、記帳時または出荷時に与信チェックが実行されるように受注タイプを設定する必要があります。承認は、支払の検証処理中に自動的に発生します。
クレジット・カードは、「受注」ウィンドウで「処理」ボタンをクリックして「支払の処理」受注処理を選択し、オンラインで承認することもできます。この場合は、iPaymentインタフェースを使用して承認が試行され、結果は自動承認の場合と同様に処理されます。
ハードウェア、ソフトウェア、サーバーまたはネットワークなどに問題がある場合は、手動で承認を取得する必要があります。手動での承認が必要となるのは、ハードウェアまたはソフトウェアの問題がiPaymentサーバーやクレジット・カード・ネットワークへのリンクに関連しているためです。バックエンド・プロセッサによっては、ユーザーに承認を要求するエラーを戻すものがあります。いずれの場合も、承認を取得するには、電話で取得する方法とダイアルアップ・デバイスを使用する方法があります。その場合は、受注ヘッダーに承認コードを入力すると、その受注は承認済とみなされます。この音声承認の結果、iPaymentがコールされて承認が記録され、ARにより後でその受注に対する資金を獲得できます。
承認の時期
受注タイプに記帳与信チェック・ルールが設定されている場合、iPaymentへの承認コールは記帳時に発生します。受注にピッキング与信チェック・ルールが設定されている場合や、受注に関して失効または取得されていない以前の承認が存在しない場合は、ピック・リリース中に第2承認を発生させることができます。直接出荷受注の場合、第2承認の評価は購買リリース中に発生します。受注金額が記帳承認以降に増加し、以前の承認が失効すると、受注変更が保存された時点でこのクレジット・カードから回収する金額に対する別の承認が発生します。
承認結果
iPaymentへの承認コールでは、成否とともにリスク・コードが戻されます。正常に承認されると、承認コードと承認日が戻され、受注ヘッダーに格納されます。適切なセキュリティを持つユーザーは、承認コードを表示できます。承認に失敗すると、受注はクレジット・カード承認失敗による保留となります。オンラインで、または記帳時に承認処理が実行された場合は、メッセージによって失敗が通知されます。メッセージは、通信エラー、不正なクレジット・カード番号または資金不足など、発生したエラーのタイプを示します。通信エラーの場合は、「処理」ボタンで処理を再試行できます。不正なクレジット・カード番号や資金不足のエラーの場合は、ヘッダーのクレジット・カード番号を変更して、「処理」ボタンで再承認することで修正できます。
返品と混合受注
Oracle Order Managementでは、返品のみでなく混合受注、つまり、アウトバウンド明細と返品明細の両方を含む受注に、支払タイプとしてクレジット・カードを使用できます。混合受注の場合、承認金額はアウトバウンドとインバウンドの正味ではなく、アウトバウンド受注明細の合計金額です。返品のみの受注の場合はクレジット・カード番号を記録できますが、Order Managementではそれに対して処理は行われません。返品明細の場合はクレジット・カード情報がOracle Receivablesに渡されますが、ARではこのデータに基づき自動的にクレジット・カード払戻は作成しません。ARは手動でクレジット・カード払戻を処理する機能を提供しています。与信は参照請求書の情報を使用して生成されます。クレジット・カードによる払戻を手動で処理するか、返品用に異なる支払タイプを選択することをお薦めします。Oracle Receivablesで返品を処理すると、当初の請求書がクレジット・カードで支払われた場合にクレジット・カードは払い戻されます。
受注のコピー
Oracle Order Managementでは、受注のコピー機能が拡張されており、受注ヘッダーのコピー時にクレジット・カード情報をコピーするかどうかを選択できます。「ヘッダーのコピー」ウィンドウの「クレジット・カード詳細」チェック・ボックスを使用すると、コピーするかどうかを指定できます。コピーされるデータは、クレジット・カード番号、クレジット・カード保有者名、クレジット・カード・タイプおよび失効日です。このチェック・ボックスが使用可能になるのは、プロファイル・オプションで「すべて」または「制限あり」クレジット・カード権限が設定されている場合のみです。このチェック・ボックスは、この種の情報をコピーするかどうかをユーザーが意図的に選択できるように、オフの状態でシードされます。
承認フロー
クレジット・カード承認は、承認金額について取得されます。承認後に受注に変更があると、金額が減額され、それ以上の承認は発生しません。受注合計が増加すると、以前の承認が失効した場合に別の承認が実行されます。iPaymentでは取引の無効化がサポートされなくなりました。このため、複数の承認が実行された場合に発生する可能性がある、必要以上の資金をブロックすることはありません。再承認は、以前の承認が失効している場合にのみ行われます。受注が承認され、一部のみが出荷されると、出荷残数量が出荷される前に取得できるように、出荷済金額がReceivablesに送られる場合があります。その場合、Receivablesでは、当初承認コードを使用して出荷済明細の金額のみが取得されます。承認コードを取得取引に使用できるのは1度のみです。受注の残りの明細が出荷済（ピック・リリ-ス済）になると、失効または取得されていない承認が受注にないかどうかがチェックされます。このような承認がない場合は、残余金額が再承認されます。詳細は、後述の例を参照してください。
前払フロー
受注金額合計から取引約定を差し引いた分について、クレジット・カード資金獲得が行われます。資金獲得後に受注の変更が発生した場合は、Oracle Order ManagementによりReceivables入金APIがコールされ、増分入金または払戻（受注金額が減額されている場合）が行われます。
承認
Order Managementでは、クレジット・カード承認処理に関して2つの保留がシードされています。
クレジット・カード承認失敗は、承認が失敗した場合に適用されます。
「クレジット・カード高リスク」は、承認は成功したが、リスク・スコアがプロファイル・オプションで設定されたしきい値より高い場合に適用されます。
この2つの保留はどちらも手動で解除できますが、後続の承認に失敗した場合は自動的に再適用できます。また、どちらも手動承認で削除できます。
前払
Order Managementでは、前払クレジット・カード機能に関して3つの保留がシードされています。
受注で、受入を非同期的に処理させる必要がある場合に、「プロセス支払保留」が適用されます。
獲得および入金作成処理に失敗し、その解決に人的介入が必要となる場合は、「電子支払失敗保留」が適用されます。
獲得処理で再試行可能なエラーが発生すると、「電子支払サーバー失敗保留」が適用されます。
「クレジット・カード・プロセス保留支払」コンカレント・プログラムで予定作成して、電子支払保留を処理できます。
iPaymentにはリスク管理機能である、Oracle iRiskがあり、問題のある取引のリスクを管理できます。Oracle iRiskでは、多数のリスク・ファクタを定義して顧客の識別情報を確認し、その信用状況を査定し、安全なオンライン環境でリスクを管理できます。このようなファクタとリスク計算式は、iPaymentの設定時に設定します。Oracle Order Managementからの承認では、iPaymentで設定されたデフォルトのリスク計算式が使用されます。承認により、承認コードとともにリスク・スコアが戻されます。このスコアは0〜100で、0はリスクのない取引を指し、100はハイ・リスクの承認を指します。リスク・スコアが対応するプロファイル・オプションに設定したリスクしきい値を超える場合、受注には自動的に「クレジット・カード高リスク」の保留が適用されます。
支払タイプが「クレジット・カード」の受注をインポートできます。支払インタフェース表には、すべてのクレジット・カード関連データ用の列があります。承認コード列と承認日列を移入することで、承認済の受注をインポートできます。これにより、すでに承認を実行済の従来型システムや他のソース・システムから、受注をOracle Order Managementに送信して履行させるようなビジネス・ケースがサポートされます。
同様に、CRMや他のフロント・エンド・システムからの事前承認済の受注は、受注処理APIを通じてOracle Order Managementに入力できます。この種の受注は、出荷時に再承認が必要な場合や、承認後に受注金額が増加したために必要でないかぎり、再承認されません。
取引約定は、Oracle Receivablesに記録された前払取引のタイプです。Order Managementでは、取引約定番号、または必要に応じて受注明細の金額を選択して、取引約定から支払われた資金で明細を支払うように指定できます。支払タイプが「クレジット・カード」の受注に取引約定を使用する場合、承認または回収する金額は、合計受注金額または合計明細金額から、取引約定を持つ明細の取引約定額を差し引いた金額になります。これにより、いくつかの明細が取引約定で前払いされ、顧客がクレジット・カード番号を提示して取引約定で未払の受注金額を支払うようなビジネス・ケースがサポートされます。
Oracle Order Managementでクレジット・カード承認を使用するには、クレジット・カード・プロバイダ・ネットワークと通信するiPaymentサーバーをインストールして設定する必要があります。また、Oracle Order Managementで1つ以上のクレジット・カード・ルールを作成し、与信チェックを使用するように受注取引タイプを設定します。クレジット・カード承認は、クレジット・カード・ルールが受注タイプに提示されるまで自動的には発生しません。その他の主要な必須設定や、クレジット・カード承認操作に影響する設定は、次のとおりです。
参照: 『Oracle iPayment Implementation Guide』
『Oracle iPayment Concepts and Procedures』
このプロファイルはサイト、アプリケーションおよび職責の各レベルで更新可能であり、受注に関するクレジット・カード情報の表示権限と更新権限を制御します。考えられる値は、次のとおりです。
すべて
受注ヘッダーおよび「受注要約」ウィンドウに、完全なクレジット・カード番号と承認コードが表示され、すべての更新機能を使用できます。つまり、新規クレジット・カード番号を入力したり、手動承認やオンライン承認を取得できます。
制限あり
受注ヘッダーと「受注要約」ウィンドウに、書式マスクが適用された状態でクレジット・カード番号と承認コードの末尾4桁のみが表示されます。「すべて」権限を持つユーザーと同様に、すべての更新機能を使用できます。
なし
受注ヘッダーと「受注要約」ウィンドウに、書式マスクが適用された状態でクレジット・カード番号と承認コードの末尾4桁のみが表示されます。また、クレジット・カード番号の入力や手動またはオンライン承認の取得はできません。これはデフォルトです。
このプロファイルは、承認が有効であると予想される日数を表します。各種iPaymentベンダーのすべてが承認に失効日を設けているとは限らないため、デフォルト日数を設定する必要があります。実際の承認有効期間はクレジット・カード・ベンダーごとに異なります。このプロファイルのデフォルトは21（日）です。出荷時に支払確認がコールされると、コードにより当初の承認が失効しているかどうかがチェックされ、失効している場合は、別の承認が取得されます。失効していない場合は、再承認されません。有効期限は、このプロファイル・オプション値を承認日に加算し、システム日付と比較することで算出されます。
このプロファイルは1〜100の値で、リスク・ファクタ付きで承認された受注に「クレジット・カード高リスク」による保留が適用される切捨てポイントを表します。デフォルトは50です。たとえば、受注は正常に承認されたが、リスク・ファクタ51が戻されたとします。そのリスク・コードはしきい値である50を超えているため、保留が適用されます。前述の「リスク管理」を参照してください。
このプロファイル・オプションは、請求インタフェースで支払タイプが「クレジット・カード」の受注をOracle Receivablesに渡すために使用される、デフォルトの支払方法を表します。このプロファイル・オプションが使用されるのは、クレジット・カード支払タイプ定義で支払方法が指定されておらず、顧客の基本支払方法が記録されていない場合です。デフォルトはありませんが、クレジット・カードによる受注をOracle Receivablesにインタフェースする前に、このプロファイルを移入する必要があります。このプロファイルには値リストがあり、AR内で支払タイプが「クレジット・カード」になっている有効なすべての支払方法と対照して検証されます。
受注ヘッダーまたは明細で支払タイプとして「クレジット・カード」を選択すると、Oracle Accounts Payableにある顧客の基本銀行口座により、クレジット・カード番号、カード保有者名および失効日のデフォルト情報が提供されます。受注ヘッダーまたは明細の「クレジットカード番号」フィールドの値リストは、Oracle Accounts Payable内でbranch_id = 1になっている銀行口座表に基づいています。branch_id = 1は、銀行口座のクレジット・カード・タイプを示すAPの規則です。異なる使用クレジット・カード番号を入力できます。新しいクレジット・カード番号の使用時に、新規銀行口座が作成され、データがデータベースに保存またはコミットされると、その口座がAP内で顧客用の新規銀行口座として作成されます。
前払クレジット・カード機能を使用する場合、前払クレジット・カード属性を選択した状態でReceivablesの支払条件を1つ以上設定する必要があります。Oracle Order Managementでは、受注ヘッダー支払条件が前払の支払条件の場合に、前払クレジット・カード処理のみ起動されます。受注に前払クレジット・カードを示すヘッダー支払条件がある場合、受注明細レベルの支払条件は無視されます。これらは、請求の統合時にもReceivablesに渡されることはありません。
クレジット・カード承認で使用される、複数のOM参照があります。クレジット・カード・タイプ用のOM参照があり、「AMEX」や「VISA」など、最も一般的なクレジット・カード・タイプとともにシードされます。このリストは拡張できます。
iPaymentサーバーについては、専用のインプリメンテーション・ガイドが用意されています。Oracle Order Managementに影響する重要な設定事項は、リスク管理ファクタと計算式および市中銀行口座です。その他の設定情報は、『Oracle iPayment Implementation Guide』を参照してください。
Oracle Order Managementには、クレジット・カード情報を含む新規または既存のレポートはありません。
クレジット・カードに使用する受注タイプについて、与信チェックを有効にする必要があります。支払確認コードには承認に関するiPaymentへのコールが含まれており、受注タイプの与信チェック・ルールが存在する場合にのみコールされます。クレジット・カード承認では、受注や明細の支払条件や、顧客または請求先の与信チェックがオンになっているかどうかは考慮されません。
Oracle Order Managementでは、クレジット・カード情報は「OM: クレジット・カード権限」プロファイル・オプションの設定に基づいて、権限のないユーザーが表示できないようにマスクで保護されます。この処理はユーザー・インタフェースでのみ発生します。この時点では、クレジット・カード情報はデータベース内で暗号化されません。データベースへの直接アクセスを制限し、格納されている機密情報へのアクセスを防止する必要があります。
Oracle Order Managementでは、特定の時点で受注ごとに有効な承認が複数あります。承認が失効も取得もされていない受注で受注値が増加した場合、Oracle Order Managementで追加の承認が実行されることはありません。このため、受注が獲得のためにARに届いたときに、資金不足でも受注に対してクレジット・カードを利用できる可能性があります。ARでは、請求金額が承認金額を超える場合に全額の承認および獲得が試行されます。
通常のビジネス慣習として、承認後かつ通常の承認が失効する前に、ユーザーに製品をクレジット・カード受注に追加させている場合、支払対象外のリスクを認定する必要があります。これが問題となる場合は、ユーザーが追加明細や数量に対して新規受注を作成し、その金額が承認されるようにする慣習を採用する場合があります。
iPaymentがインストールされていない場合に、受注に支払タイプとして「クレジット・カード」を入力すると、支払確認ではエラーは戻されず、受注に保留は適用されません。かわりにクレジット・カード承認がコールされるため、与信チェックは発生しません。「処理」ボタンをクリックして「支払の承認」処理を実行することはできません。iPaymentを使用せず、またはカスタマイズを行わずにクレジット・カードを承認するには、手動で承認コードを入力する必要があります。実際には、iPaymentがインストールされていない場合、受注ヘッダーの「クレジット・カード」フィールドは参照専用となります。ただし、iPaymentがインストールされていなくても、クレジット・カード・データはOracle Receivablesに渡されます。これにより自動インボイスで問題が発生する可能性があります。
iPaymentをインストールしておらず、使用されないクレジット・カード情報が入力されないようにする必要がある場合は、ユーザーによる「クレジット・カード」フィールドへのデータ保存を禁止するように処理制約を設定できます。詳細は、「処理制約」を参照してください。
Oracle Order Managementでは常にクレジット・カード情報は自動支払として扱われます。したがって、用意したクレジット・カード情報が自動支払を目的としていない場合は、受注にクレジット・カード情報を入力しないことをお薦めします。クレジット・カード情報を通知目的のみで使用する場合は、受注レベルまたは明細レベルの付加フレックス・フィールドを利用できます。
iPayment統合をユーザーの環境で動作するように設定できない場合に状況を示すログ・ファイルを生成すると、オラクル社カスタマ・サポート・センターでサポートを受けるときに役立ちます。iPayment統合問題のレポート作成時に、デバッグ・ファイルを生成する手順は、次のとおりです。
新規セッションを使用してアプリケーションにログインします。
「受注」ウィンドウを開いて受注を問い合せます。
「ツール」メニューの「デバッグ」をクリックします。
「デバッグをオンにする」を選択します。
「ツール」メニューの「デバッグ」をクリックします。
「キャッシュの初期化」を選択します。
「ツール」メニューの「デバッグ」をクリックします。
「FILEに書込む」を選択します。デフォルトのファイル名をメモします。このファイル名は変更できません。デバッグ・メッセージはこのファイルに書き込まれます。
失敗したステップを実行します。この場合は、記帳/ピック/手動による支払承認の可能性があります。
デバッグをオフにします。
デバッグ・ファイルをオラクル社カスタマ・サポート・センターに提供します。
次の例では、受注タイプに記帳と出荷の両方について与信チェック・ルールが割り当てられており、「OM: 見積承認妥当性期間」プロファイルはデフォルトの21日のままになっているとします。
注意: これらは承認のみの例であり、前払受注や明細レベルの支払による受注には該当しません。
単純受注: 記帳時に承認され、受注変更なしで1週間以内にピック・リリースされ、出荷される単純な受注を考えます。記帳時に、受注全体について単一の承認が取得されます。失効も取得もされていない承認が存在するため、出荷時にそれ以上の承認は発生しません。受注全体がOracle Receivablesに一度にインタフェースされ、Oracle Receivablesでは当初承認コードに対して資金が獲得されます。
部分出荷: この受注は、数量が10で金額が$1000の単一の明細で構成されています。記帳時に取得される承認は$1000分です。数量10のうち、3のみがピックされ、出荷確認されてOracle Receivablesにインタフェースされます。残りの7は出荷残となっています。受注の残余分がピック・リリースされる時点で発生する処理は、Oracle Receivablesで当初承認に対して資金が獲得されているかどうかに応じて異なります。獲得されている場合、ARでは最初の承認に対して$300が獲得されます。受注の残余分のピック・リリース時には、未獲得金額である$700分の新規承認が取得されます。Oracle Receivablesで2番目のピック・リリース時に資金獲得が実行されていない場合、当初承認が失効していないと、Oracle Order Managementでは再承認されません。失効は、「OM: 見積承認妥当性期間」の値に対して計算することで判別されます。承認により資金が獲得されたかどうかは、iPayment APIをコールすることで判別されます。
取消: 前述の「部分出荷」の場合と同じ受注を考えます。ただし、記帳されてからOracle Receivablesにインタフェースされるまでの間に、受注が取り消されるとします。受注全体が取り消されると、Oracle Order Managementでは何も実行されず、承認は失効したままになります。これに対して、受注の一部が取り消されると、出荷済でOracle Receivablesにインタフェース済の部分は、出荷済金額分の資金を当初承認コードに対して獲得します。残余分（取消済金額）は取り消されているため、承認されることはありません。
混合受注: この受注は$200分のアウトバウンド明細と$50分の返品明細で構成されています。したがって、受注合計は正味金額、つまり$150です。記帳時の承認では$200全額が承認されます。
クレジット・カード情報を含む受注の場合、特別なアップグレードは実行されません。旧リリースのOracle Order Entryからのクレジット・カード情報はアップグレード後の受注にコピーされます。新規のアップグレード後の受注が記帳または出荷に達し、受注タイプの与信チェック・ルールがあると、承認が試行されます。
Oracle Order Managementの複数支払および一部支払機能により、支払方法のタイプを追加し、明細レベルでの支払タイプを指定できます。また、頭金をサポートするために、受注ヘッダー・レベルで複数の前払処理が可能です。これにより、企業対消費者取引フローのサポートが強化されます。複数のクレジット・カード、電子支払オプションを使用した、支払回収のリスクの低減、および受注の支払における柔軟性の向上が実現します。次に、その主な機能を示します。
サポートされるその他の支払タイプ。
電信送金
購買カード
自動手形交換所取引（ACH）
口座引落し
現金
クレジット・カード
対顧客勘定（またはPO）
支払タイプを使用可能にし、オプション属性を入力するウィンドウ。
受注または明細の支払情報のウィンドウ。
受注の前払データ入力: 受注合計の部分額または全額の複数前払が作成されます。Oracle Order Managementでは、受注が作成された場合に後で請求書に適用するため、受注にリンクした1つ以上のAccounts Receivableの受入が作成されます。
支払保証用ワークフロー・アクティビティ: たとえば、出荷前に前払が回収されたことが検証されます。
受注に前払がないかぎり、（取引約定の他に）明細レベルで1つの支払手段を入力する機能。
印刷し、小売顧客に手渡すことができる簡易受入文書。
賦払条件のクレジット・カード承認の拡張。Oracle Order Managementでは、合計受注金額ではなく、初回賦払いのみ承認するオプションが提供されています。
ネットワーク停止が原因で失敗する承認の自動再試行など、クレジット・カードのバッチ承認。
受注インポートを使用して複数支払や前払を作成する機能。
支払情報で受注または明細をコピーする機能。
複数支払および一部支払を使用する場合は、クレジット・カード処理に関連した既存のプロファイル・オプションを適切に設定する必要があります。
OMシステム・パラメータを設定します。「OMシステム・パラメータ」の「値」ウィンドウにナビゲートします。「OMシステム・パラメータの設定」を参照してください。
「OMシステム・パラメータ」ウィンドウ
「営業単位」を選択し、「カテゴリ」フィールドで値リストから「支払パラメータ」を選択します。そのカテゴリを問い合せ、値を適切に設定します。
「複数支払を許可」を「Yes」に設定します。デフォルトは「No」です。
複数支払を「Yes」に設定した場合
受注ごとに複数支払を許可するため、全額および一部頭金機能を使用できます。
「支払処理」を使用して「受注」フォームから「支払」ウィンドウへナビゲートできるようになります。
複数支払を「No」に設定した場合
受注ごとの複数支払は禁止になり、かつ頭金機能は使用できません。
一部前払を許可せずに、ヘッダー・レベルで単一支払タイプのみ許可します。一部頭金機能は使用できません。複数支払を「No」に設定した場合、以前のリリースで導入されている全額（100%）頭金機能は使用できます。
明細レベルの支払はありません。
リリース11i.9の既存の機能が保持されます。
「支払」処理は参照不可のため、「支払」ウィンドウにはナビゲートできません。
注意: このパラメータを「Yes」に設定すると、「No」には変更できません。
「初回賦払いのみ承認します」を「Yes」に設定します。これはオプションで、デフォルト値は「No」です。
このシステム・パラメータを使用すると、受注の初回賦払いのみまたは残高合計がクレジット・カード承認で承認されるようにシステムを構成できます。値は次のとおりです。
「Yes」: 支払の初回賦払いのみが承認されます。
この場合、承認金額は初回賦払いから頭金を差し引いた合計となります（該当する場合）。
「No」: 受注金額全体が承認されます。
この場合、承認金額は、受注合計から頭金と取引約定摘要額を差し引いた金額となります。
支払タイプを使用可能にします。支払タイプはOrder Managementで保守されます。「支払タイプ」ウィンドウにナビゲートします。「受注管理」→「設定」→「受注」→「支払タイプ」。
「支払タイプ」ウィンドウ
「支払タイプ」の設定ウィンドウで、次のことができます。
シード済支払タイプのみの有効化または無効化
シード済支払タイプの属性のカスタマイズ
新規支払タイプの追加またはシード済支払タイプの削除はできません。支払タイプは営業単位（OU）固有です。営業単位での変更は他の営業単位には複製されません。Order Managementでは、Oracle ReceivablesおよびiPaymentでサポートされている支払タイプのみシードされます。
注意: 支払タイプが営業単位に対して表示されない場合は、システム管理者職責で、「シード・データの複製」コンカレント・プログラムを実行します。
組織: この支払タイプ設定を使用する営業単位。
支払タイプ・コード: サポートされている支払タイプ。このフィールドのエントリは変更できませんが、摘要と支払タイプ名は変更できます。
入金方法: 事前に定義された入金方法を支払タイプに割り当てます。この支払方法は、オープン残高を回収する場合に請求書で使用されます。このフィールドは更新できます。「複数支払に関するAccounts Receivable（AR）の設定」を参照してください。
開始日: 支払タイプの有効な開始日。このフィールドは更新できます。
終了日: 支払タイプの有効な終了日。このフィールドは更新できます。
遅延支払処理: YまたはNにより、この支払タイプをパフォーマンス向上のため遅延モードで処理するかどうかを判断します。このチェック・ボックスは更新できます。
与信チェック: YまたはNにより、この支払タイプに対して与信チェックを行うかどうかを判断します。これは、前払機能を使用している場合に、与信チェックを行うために必要な追加設定です。このチェック・ボックスは更新できます。
サポートされている支払タイプおよび取引に必要なその他の情報
クレジット・カード/購買カード: 「クレジットカード番号」、「クレジット・カード保有者名」、「失効日」、「カードの種類」を指定します。
自動手形交換所: 「銀行番号」、「口座番号」、「口座名義人名」、「口座種別」を指定します。
口座引落し: 「銀行番号」、「口座番号」、「口座名義人名」、「口座種別」を指定します。
電信送金/EFT: 請求書支払のみでサポートされています。
小切手: 「銀行口座番号」、「小切手番号」を指定します。前払に「小切手」を使用する場合、ロックボックスを使用して小切手を処理できないことに注意してください。
現金: 現金。
「受注ヘッダー」の支払タイプが「NULL」の場合、「請求書の発送」を意味します。さらに、「受注ヘッダー」に発注番号を入力できます。
「取引約定番号」の指定（明細レベルの支払でサポート）
明細レベルでのみ、および受注明細ごとに1つの取引約定のみ使用可能です。
「取引約定合意金額」は更新できます。
取引約定は支払タイプには含まれておらず、頭金には使用できません。
頭金の複数支払タイプは受注レベルのみです。受注に前払/頭金がある場合は、受注明細レベルで支払タイプを指定できません。受注に前払がある場合、「支払」ウィンドウの「明細支払」ボタンがグレー表示され、「明細」タブの「支払処理」は参照できません。
頭金のない受注については、受注明細ごとの取引約定に加えて追加支払タイプを1つ選択できます。取引約定に加えて支払手段は、受注明細の残高に対して1つのみ使用できます。
前払処理とクレジット・カード承認の遅延
支払はまず記帳時に処理できます。ただし、「支払タイプ」の「遅延」フラグを「Yes」に設定して、前払処理を遅延できます。より細かい単位で管理するために、「支払」ウィンドウの取引レベルでフラグのデフォルト値を上書きできます。
「遅延」フラグは、前払処理とクレジット・カード承認を表しています。そのフラグを「Yes」に設定すると、支払処理とクレジット・カード承認が遅延されます。
遅延承認としてフラグが付けられると、Order Managementでは、クレジット・カード承認用のiPaymentのコールが遅延されます。受注または明細に支払承認保留が適用されます。
与信チェック・ルールを出荷時に使用すると、クレジット・カード承認がこのフラグの設定に関係なく実行されるため、「遅延」フラグは適用できません。
与信チェックを支払タイプのある受注で発生させるには、「支払タイプ」でこのフラグをYに、「支払条件」、「受注取引タイプ」および「顧客プロファイル」で「与信チェック」をYに設定する必要があります。
前払支払条件を設定します。支払条件はOrder Managementで設定できます。「設定」→「受注」→「支払条件」にナビゲートします。必要に応じてOracle Receivablesの「スーパーユーザー」メニューから「支払条件」を設定することもできます。
「支払条件」ウィンドウ
設定で前払に対してチェック・ボックスが選択されていると、前払の受注ヘッダーで支払条件を使用する場合、提示された前払金額が「支払」ウィンドウにデフォルトで設定されます。提示された前払金額は、前払条件の初回賦払いの設定に基づいて算出されます。
受注入力中、支払条件の値リスト（LOV）にも「前払」/非前払フラグが表示されます。非前払条件を受注ヘッダーで使用している場合、ユーザーは前払金額を入力して「支払」ウィンドウに前払を記録できます。
頭金については、ヘッダー・レベルの支払条件のみが提示された頭金金額の決定に使用されます。受注入力中に「支払」ウィンドウでこの金額を手動で上書きできます。
賦払のある前払条件については、初回賦払いが頭金になるように設定する必要があります。
Oracle Receivablesでは、頭金ではなく前払や残りの賦払を使用している場合に、早期値引がサポートされています。税金は、頭金の回収時には計上されておらず、収益は確認されません。
注意: 提示された頭金の賦払計算のあるIA前払条件では、初回賦払い時に「税金/運送費を含む」ではなく、賦払間で「税金および運送費を配分」を使用することを前提としています。
明細ワークフローに含まれている支払保証アクティビティで取引タイプを作成します。明細レベル・ワークフロー内に支払保証ワークフロー・アクティビティを含めることができます。
明細レベル・ワークフローの支払保証
このオプションのワークフロー・アクティビティにより、受注明細が進行する前に、受入が支払タイプにより特定の受入ステータスになります。ワークフローの設定またはシード済明細フローを拡張して、このアクティビティを記帳と請求間の任意のポイントに挿入できます。この処理は出荷前に追加することをお薦めします。このアクティビティがフローにある場合、前払受入が使用されている支払タイプに応じた適切なステータスにないかぎり、受注明細は進みません。これにより、頭金回収の妥当性が保証されます。
支払受領書を印刷するかどうか、および支払受領書の起動方法を決定します。受注ワークフローに含まれている支払受領書の印刷アクティビティを使用して取引タイプを作成します。このオプション・ステップにより、受注とともに資金が回収されたときに支払受領書として文書が作成されます。注意: 資金は必ずしも回収されず、処理された前払のみが表示されます。支払受領書を作成する方法は、次の3つです。
オプション1: ワークフローに「支払受領書の印刷」機能を含めます。支払受領書の印刷を常にトリガーする場合は、このオプションを使用します。通常は、受注フローの記帳の後にこのオプションを配置します。
オプション2: 「レポートの実行を使用してパラメータ「受注番号」または「受注タイプ」を指定して、新規レポート支払受領書を起動します。すべての受注に対して支払受領書を印刷しない場合に、このオプションを使用します。
オプション3: 受注レベルの「処理」からもアクセスできます。
支払受領書の印刷処理は、「受注: 支払受領書の印刷」機能がOMメニューに添付されている場合にのみ使用できます。
デフォルティング・フレームワーク（payment_type_code、Receipt_method_id、Payment_collection_event）を使用して次の属性のデフォルト設定を定義できます。デフォルト・ルールは、受注支払および明細支払の各エンティティ、入金方法、API基準デフォルティングに対してシードされます。
支払タイプの設定に値が存在する場合、この値はデフォルトで支払レコードになります。
それ以外の場合、支払タイプが「クレジット・カード」および「自動手形交換所」については、顧客サイトに定義された主要支払方法を参照してください。
それ以外の場合、支払タイプが「クレジット・カード」および「自動手形交換所」については、顧客に定義された主要支払方法を参照してください。
それ以外の場合、支払タイプが「クレジット・カード」の場合のみ、プロファイル・オプション「OM: クレジット・カード取引の支払方法」を参照してください。
注意: 支払方法と顧客の銀行口座IDは支払作成時にデフォルト設定されています。これらはクレジット・カードおよびACHの記帳時に必要です。支払レベル・コードは支払作成時にデフォルト設定されます。
参照: 「デフォルト・ルールの定義」
処理制約を設定します。
前払については、支払が処理されて領収書が正常に作成されると、次のようになります。
支払情報は金額を除き更新できません。金額の値は上下に調整できます。
支払情報は削除できません。
受注ヘッダーでは、属性「取引通貨」、「請求先顧客」、「請求先所在地」、「支払タイプ」は変更できません。
支払番号はシステムによって生成されており、更新できません。
ヘッダー・レベルの請求書支払では、受注明細が1つでも請求インタフェース済になると、支払情報を変更できません。
明細レベルの請求書支払では、受注明細が請求インタフェース済になると、支払情報を変更できません。
クレジット・カードによる請求書支払では、承認が完了すると、クレジット・カード関連データを変更できません。
注意: 受注入力時に支払手段を入力する必要はありません。支払タイプではNULLが許可されています。受注入力時に支払タイプがNULLでないフォームを入力するように制約を設定できます。
制約フレームワークを使用して他の属性で制約を定義できます。使用できる属性は、次のとおりです。
支払タイプ・コード
取引約定適用額
クレジット・カード・コード
クレジット・カード番号
クレジット・カード保有者名
クレジット・カード失効日
クレジット・カード承認コード
クレジット・カード承認日
入金方法ID
支払回収イベント
小切手番号
支払額
参照: 「処理制約の定義」
「プロセス保留支払」コンカレント・プログラムを予定作成します。このプログラムをスタンドアロンまたはバッチ・モードで実行して、支払処理をトリガーすることもできます。「要求の発行」ウィンドウにナビゲートします。「受注管理」→「レポート, 要求」→「要求の実行」。
「要求の発行」ウィンドウ
「名前」フィールドで、値リストから「プロセス保留支払」を選択します。
「プロセス保留支払」の「パラメータ」ウィンドウ
「プロセス保留支払」コンカレント・プログラムを使用して、次をバッチ・モードで処理できます。
クレジット・カード承認のみ（非前払）: 受注に前払がなく、受注または明細に支払承認保留がある受注を処理します。
前払処理のみ: 受注に前払があり、受注または明細にプロセス支払保留がある受注を処理します。
前払処理および非前払処理: 受注または明細に支払承認保留またはプロセス支払保留がある受注を処理します。
指定した回数または定期的に実行されるようにこのプログラムを発行し、手動操作なしで非同期的に支払を処理できます。この設定はオプションです。
注意: 「受注」ウィンドウの「支払の処理」処理では、前払処理およびクレジット・カード承認を含む現行の受注に対するすべての保留支払が処理されます。この処理は、パラメータに前払処理および非前払処理を選択した「プロセス保留支払」コンカレント・プログラムのように動作します。
受注レベル与信チェック
与信チェック中に受注合計額から（取引約定適用額に加えて）支払タイプの前払済金額が差し引かれます。その他すべての与信チェック管理が許可されています。
明細レベル与信チェック
頭金のある受注については、前払済金額は受注合計額からは差し引かれません。取引約定適用額のみが明細合計から差し引かれます。
注意: 与信債務全体の計算は、AR残高が合計債務計算に含まれているかどうかにかかわらず、前払機能の影響を受けません。
「与信チェック」フラグが「ON」の場合: 与信チェックが行われ、オープン残高が承認されます。
「与信チェック」フラグが「OFF」の場合: オープン残高のみが承認されます。
与信チェックは以降の支払処理で再実行されます。
プロセス支払保留: 「支払の処理」アクティビティが「保留中」であるすべてのケースに関連しています。
電子支払失敗保留: 不正データなど、iPaymentによって戻される予期されたエラー用です。
電子支払サーバー失敗保留: サーバー接続障害などiPaymentによって戻される予期しないエラー用です。
「プロセス保留支払」コンカレント・プログラム(バッチ・モード）
「支払の処理」処理（受注ごとの受注フォームからの手動処理）
「記帳時」（記帳は支払の処理をトリガー）
ヘッダー・レベルでのクレジット・カード支払については、ヘッダー・レベルで承認される金額は、前払合計金額を差し引き、取引約定適用額の明細合計と他の支払手段の影響を受ける金額を差し引いた、受注合計（手数料や見積税額を含む）と等しくなります。
明細レベルでのクレジット・カード支払については、明細レベルで承認される金額は、取引約定適用額を差し引いた、明細合計（手数料や税金を含む）と等しくなります。
承認を実行させるためには、記帳用の与信チェック・ルールなどの与信チェック・ルールを必要に応じてオンにする必要があります。
支払超過
回収済前払金額が合計オープン残高より多い場合は、警告メッセージが表示され、支払は正常に処理されます。
注意: 頭金が処理されると、受注合計を増減させる変更による追加の受入または払戻は自動的には行われません。その後の回収については前払金額を手動でより高い値に設定して、「支払の処理」処理を実行するか、「プロセス保留支払」プログラムを実行する必要があります。
Oracle Receivablesでは「売掛/未収金活動」が設定されています。タイプが「前払」の売掛/未収金活動を設定する必要があります。前払のある受注が記帳されると、記帳前に「支払」ウィンドウの「遅延」フラグが選択解除されている場合は、支払の処理が自動的にトリガーされます。Oracle Receivablesで前払の入金が作成されます。この前払の入金は前払売掛/未収金活動に適用されます。タイプが「前払」の売掛/未収金活動は、受注が請求済で、請求書と前払が一致するまではプレースホルダ・アプリケーションです。一致したときに、前払は前払売掛/未収金活動から適用解除され、請求書の残高を解消または減額するために請求書に適用されます。
参照: 『Oracle Receivables Implementation Guide』
「入金区分/支払方法」ウィンドウから「銀行口座」にナビゲートします。「送金銀行」の属性は「最小入金金額」である必要があります。前払に対する受入を作成する前に、受入作成金額が「送金銀行」の「最小入金金額」を超えていることが検証されます。受入作成金額が「最小入金金額」より少ない場合、前払の入金は自動的に作成されません。この場合、受注はプロセス支払保留にはなりません。
参照: 『Oracle Receivables Implementation Guide』
「コピー」ウィンドウの「ヘッダーのコピー」タブおよび「明細のコピー」タブの「支払」チェック・ボックスにより、支払情報をコピーできます。
「コピー」ウィンドウの「ヘッダーのコピー」タブ
このチェック・ボックスのデフォルト値は「未チェック」です。支払タイプはソース受注からコピーされますが、金額はコピーされません。
「コピー」ウィンドウの「明細のコピー」タブ
支払情報のコピーは、アウトバウンド発注にのみ使用できます。
