ヘッダーをスキップ

Oracle Order Managementユーザーズ・ガイド
リリース12.1
B62702-01		目次へ
目次		前のページへ
前へ		次のページへ
次へ

請求および支払

請求処理

概要

Order Managementの請求処理は、受注と返品のデータをOracle Receivablesにインタフェースして、収益の認識と販売実績の管理のために請求書とクレジット・メモを作成するプロセスです。

Oracle Order Management内では、請求処理はワークフロー・アクティビティとして実行されます（請求インタフェース）。請求インタフェース・アクティビティは受注、返品および運送費の情報を受注管理表から収集し、この情報をOracle Receivablesインタフェース表に転送します。品目摘要、受注数量、単価、合計額、支払方法、倉庫ID、販売実績などのデータ要素が、Oracle Receivablesインタフェース表経由で転送されます。請求インタフェース・アクティビティが完了した後、Oracle Receivablesコンカレント・プログラム自動インボイスを発行して、請求データと販売データをOracle Receivablesにインポートする必要があります。

注意: 受注または請求の参照情報を持たない返品は対顧客勘定クレジットになります。

Oracle Receivablesに取引をインタフェースする方法の詳細は、『Oracle Receivablesインプリメンテーション・ガイド』および『Oracle Receivables Reference Guide』を参照してください。

請求とクレジット・メモの作成の詳細は、『Oracle Receivablesユーザーズ・ガイド』および『Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide』を参照してください。

請求書のレベル処理

Oracle Order Managementでは、次の2つのレベルで請求処理をサポートします。

  1. 受注ヘッダー・レベル請求

    受注レベル請求インタフェース・ワークフロー・アクティビティは、受注ヘッダー・ワークフロー・プロセスの一部です。すべての受注または返品のデータが同時にOracle Receivablesにインタフェースされます。

  2. 受注明細レベル請求

    受注明細レベル請求インタフェース・ワークフロー・アクティビティは、受注明細ワークフロー・プロセスの一部です。個々の明細または明細のセットのデータがインタフェースに適格になるとOracle Receivablesにインタフェースされます。

    注意: 請求またはクレジット・メモのための受注または受注明細のグループ化は、必須グループ化ルールまたはOracle Receivablesで設定するオプション・グループ化ルールに左右されます。受注管理の請求インタフェース・ワークフロー・アクティビティによるグループ化は行われません。

    受注管理の請求インタフェース・アクティビティ

Oracle Order Managementの請求インタフェース・ワークフロー・アクティビティを使用すると、次のことが可能です。

受注管理の請求インタフェース・アクティビティは、受注明細詳細をOracle Receivablesにインタフェースします。受注明細に次のいずれかの条件が付いている場合は、請求インタフェースに対して不適格です。

  1. 品目の請求可能属性が「NO」に設定されている場合

  2. 品目の請求属性使用可能が「NO」に設定されている場合

  3. 展開品目タイプ

  4. 構成品目タイプ

  5. サービス対象の品目がサービス可能でない場合のサービス品目

  6. 社内受注

前述のすべての条件について、請求インタフェース・ワークフロー・アクティビティは、不適格のステータスで完了します。

明細または受注に保留がある場合は、受注明細も返品明細もOracle Receivablesにインタフェースされません。請求インタフェース・アクティビティ時に受注明細や返品明細に保留中のステータスがあると、請求インタフェース・ワークフロー・アクティビティも保留中のステータスで完了します。手動で「受注の進行」コンカレント・プログラムを実行すると、受注処理を続行できます。プログラムを実行しない場合、受注明細または返品明細は保留のリリースから12時間間隔で自動的に再評価されます。

資料送付ワークフロー・アクティビティは、出荷後請求の請求インタフェース・アクティビティより前に配置しておく必要があります。Order Managementでは、出荷後請求受注の分割出荷済数量に関する請求インタフェース・アクティビティは、受注明細レベルでのみ実行されます。

値引情報

請求インタフェース・アクティビティは、価格調整情報をOracle Receivablesにインタフェースします。詳細な値引情報の印刷にはオプションが1つあります。

例: 受注明細に次の例のデータがあり、プロファイル・オプション「OM: 請求書に値引詳細の表示」が「YES」に設定されているとします。

次の表は、受注明細詳細の例です。前述のデータに関するOracle Receivable請求書の表示内容を示しています。

受注明細詳細の例
明細 摘要 数量 単価 金額
1 品目A 2 100 200
2 値引名1 2 < 10 > < 20 >
3 値引名2 2 < 15 > < 30 >
受注合計 - - - 150

注意: この表の明細1の金額列には、請求書明細の割引額が反映されていません。

今度は、プロファイル・オプション「OM: 請求書に値引詳細の表示」が「NO」に設定されているとします。値引の詳細は、Oracle Receivables請求書に表示されません。ただし、請求明細ごとの支払額を表示できます。次の表は、受注明細詳細の例です。前述のデータ例に関するOracle Receivables請求書の表示内容を示しています。

受注明細詳細の例
明細 摘要 数量 単価 金額
1 品目A 2 100 150
受注合計 - - - 150

注意: 明細1の金額列は請求書明細の値引を反映していますが、これ以上の詳細は記載されません。

手数料情報

請求インタフェース・アクティビティは、受注または返品の手数料情報もOracle Receivablesにインタフェースします。ただし、現行のOrder Managementでは、手数料明細のみを請求ヘッダー・レベル手数料としてインタフェースします。Order Managementを使用すると、次のことが可能です。

Order Managementによって、詳細手数料情報がOracle Receivablesに渡されますが、請求書そのものには個々の手数料を表示できません。

たとえば、次の情報を持つ受注が請求されます。

1つの受注明細からなる受注#123。受注運送費は$5。

受注#123、明細#1の場合: 品目番号 = ItemXYZ、数量 = 1、価格 = $100。受注明細の運送費は$10で、追加手数料（保険手数料）は$3です。

Oracle Order Managementでは、次の3つの手数料明細をインタフェースします。

3つの手数料明細は、個々にOracle Receivablesに転送されてから、Oracle Receivables内で同一の受注手数料としてまとめられます（合計$18）。

受注#123の請求書#500は次のとおりです。

搬送に基づいた請求書採番

プロファイル・オプション「OM: 請求書採番方法」が「搬送」に設定されている場合、請求インタフェース・アクティビティは搬送名に基づいて請求書番号をOracle Receivablesにインタフェースします。

出荷後請求

請求インタフェース・アクティビティは、部品構成表に出荷後請求構成部品がある場合に明細の数量のすべてまたは一部をインタフェースします。このアクティビティによって、出荷後請求構成部品が出荷されるまでは親品目が請求されません。

請求書情報の表示

請求書番号、バッチ・ソース、請求日、金額および残高などの請求データは、次のように表示できます。

プロファイル・オプション

次の表は、受注管理の請求インタフェース・アクティビティの操作に影響するプロファイル・オプションを示しています。

OM請求インタフェースの操作に影響を与えるプロファイル・オプション
プロファイル・オプション名 使用方法
OM: 請求書採番方法 請求番号自動採番を使用するか、搬送名採番を使用するか決定します。
税金: 運送用在庫品目 請求インタフェース・アクティビティでは、収益明細として処理された運送費に対して、この品目をインタフェースします。
税金: 売上としての運送費請求 運送費を収益明細として処理するかどうかを決定します。請求インタフェース・アクティビティでは、VAT税情報と販売実績もインタフェースします。
税金: 税金コード上書の許可 VAT税コード情報をインタフェースするかどうかを決定します。
OM: 売上の運送に対するクレジット営業担当 運送明細が収益明細としてインタフェースされている場合に、運送明細のダミー販売実績または受注明細/ヘッダー販売実績を渡すかどうかを決定します。
OM: 請求書に値引詳細の表示 請求書に詳細値引情報を印刷するかどうかを決定します。
OM: 請求書ソース OM取引タイプに値が定義されていない場合は、Oracle Receivablesに値がインタフェースされます。
OM:搬送なし請求書ソース 「OM: 請求書採番方法」が「搬送」に設定され、かつ明細が出荷不可である場合は、値がOracle Receivablesに転送されます。
OM: 請求取引タイプ OM取引タイプに値が定義されていない場合は、Oracle Receivablesに値が転送されます。

システム・パラメータ「超過出荷請求書ベース」は、超過出荷の受注数量または出荷済数量をインタフェースするかどうかを決定します。

前述のプロファイル・オプションおよびシステム・パラメータのユーザーに関する追加情報は、『Oracle Order Managementインプリメンテーション・マニュアル』のOrder Managementのプロファイル・オプションに関する項を参照してください。

請求処理の受注ステータス詳細

受注明細ステータスが拡張され、請求アクティビティに関連して明細ステータスの詳細情報が提供されるようになりました。以前のリリースでは、明細ステータスには「請求インタフェース完了」および「請求インタフェース一部インタフェース済」がありましたが、このリリースでは明細が進行しなかった事由の詳細が明細ステータスに示されます。

複数支払および一部支払の概要

複数支払によって、受注の支払オプションが拡張され、受注ヘッダーの現金、小切手、クレジット・カードまたはNULLなどの単一支払タイプ・オプション（取引約定を除く）に置き換わります。現在は、単一の受注に対して複数の支払タイプを指定できます。この変更によって、購買カードや直接銀行振替などの他の支払オプションが使用できるようになりました。他のビジネス状況には、次のような特徴があります。

Order Managementでは、前払がある場合、受注明細レベルで別の支払タイプを指定することはできません。また、取引約定の与信チェックは「No」に設定され、約定適用（確約）額は、与信チェック債務から常に除外されます。

EDI/XML標準には、拡張された支払サポートはありません。

複数支払および一部支払の主な機能

税金の問題と前払

入金APIを介して回収される前払では、税金用の会計仕訳は作成されません。これは、金銭の受領が課税対象となる国（特にVATの実施国）では問題となる可能性があるためです。このような場合、会計の視点から完全に適切に処理するために、前払は使用できません。

Order Managementでは、こうした国での前払の使用を禁止していません。実施企業の責任で税法に準拠していることを確認する必要があります。

100%前払および複数支払の前払機能

複数支払サポートでは、受注金額を変更しても、入金作成または払戻は自動的に起動されません。処理を手動で実行し、前払額を手動で修正する必要があります。

注意: 受注金額変更時の自動入金作成または払戻はサポートされていません。

支払機能

受注ごとの複数の支払タイプ

Order Managementのこのリリースでは、限定された方法で、複数の支払タイプを使用するか、（複数のクレジット・カードのように）同じ支払タイプを何度か使用して受注を支払うことが許可されます。

注意: Order Managementでは、受注レベルおよび前払に対してのみ複数の支払タイプがサポートされます。

Order Managementの支払条件に関する注意事項

現在サポートされている支払タイプは、次のとおりです。

Order Managementでは、ARおよびOracle Paymentsでサポートされている支払タイプのみがシードされます。

これらの手段は、Order Managementで回収される前払、またはARで回収される請求書支払に対してサポートされます。

また、受注ヘッダーに発注番号を入力できます。

取引約定に関する注意事項

  1. 取引約定は、受注明細レベルでのみ使用できます。受注明細ごとに1つの取引約定のみ指定できます。

  2. 約定確約額を更新できます。

    確約額の入力条件は次のとおりです。

  3. 受注明細合計金額以下であること

  4. 取引約定の使用可能残高以下であること

  5. 取引約定は、前払または頭金には使用できない

    頭金または前払は、前述のサポート手段を1つ以上使用して支払うことができます。ただし、請求書の残高に対しては、取引約定に加えて1つの支払手段のみ使用できます。

  6. 収益は頭金の回収時には認識されません。

  7. 税金は頭金の回収時には考慮されません。

支払処理

支払処理時には、次の処理が発生します。

Order Managementによる前払およびクレジット・カード承認の金額の計算方法

前払

クレジット・カード承認

その後に続く支払処理は、次の方法でのみ起動できます。

最低入金額と呼ばれる送金銀行口座に関する属性があります。入金を作成する前に、その入金額に対してこの最低入金額がチェックされます。入金額が最低入金額より少ない場合、入金は作成されず、受注は支払処理保留になります。この少額の増額は請求時にARで回収するか、他の受注変更がある場合は、次回の入金に組み込むこともできます。最低入金額は払戻には適用されません。

支払保証ワークフロー

アクティビティ名: 支払保証

パラメータ: ステータスをチェックする頻度。このパラメータはビジネス要件にあわせて設定してください。Order Managementでは、24時間に1回実行するようにシードされます。

一部のビジネス慣習、特に小売業では、前払または頭金が回収されるため、受注の履行前に適正な支払保証が必要です。

このアクティビティは、受注フローの記帳と請求の間（推奨は出荷前）にいつでも配置できます。このアクティビティでは、入金ステータスがチェックされ、ステータスで適正な支払保証が示されるまでフローが保留されます。

前払のある受注について、Order Managementでは入金のステータスがチェックされます。ARで一意の支払セットが割り当てられ、1つの受注に対するすべての入金に同じ支払セットが設定されます。作成時の入金のステータス、および支払保証に合格するために必要なステータスについては、次の表を参照してください。

入金ステータス
作成ステータス
支払手段 		承認済 確認済 送金済 決済済 支払保証のステータス
クレジット・カード、購買カード   X     送金済
ACH   X     決済済
口座引落し   X     決済済
電信送金（EFT/EDI） X        
小切手   X     決済済
現金   X     決済済
取引約定          

注意: 顧客からの支払が仕入先の口座に送金されると、勘定調整時に、Cash Managementは入金ステータスを決済済に設定します。勘定の調整は通常、月末に行われます。また、支払が口座に入金された時点で入金ステータスを設定するようにシステムを設定することもできます。入金区分の決済方法は自動決済に設定できます。通常のビジネス慣習では、小切手が決済されるまで3日間かかります。これは固有の設定です。

複数の支払タイプの入力

Order Managementでは、様々な受注ユーザー・インタフェースを使用した、受注のコピー、受注インポートおよび受注処理APIによる複数支払機能が提供されます。

コピー

受注が取り消されると、前払の払戻が自動的に生成されます。受注明細の取消では、自動払戻は生成されません。頭金の額を減らし、「支払の処理」をアクティブ化して、払戻を手動で実行する必要があります。

インバウンド明細とアウトバウンド明細の両方が含まれる混合受注では、前払額のデフォルトはアウトバウンド明細にのみ基づいて設定されます。前払機能では、受注合計の計算にインバウンド受注明細は考慮されません。

顧客によるクレジット

Receivablesでのクレジット処理

  1. 返品受注または受注明細には、支払済請求書に対する参照がある場合とない場合があります。

    支払済請求書の参照情報がない返品の場合、クレジットは対顧客勘定クレジットに設定されます。

    支払済請求書の参照情報がある返品の場合、請求書の支払方法によってクレジットは様々な方法で払い戻されます。次の表を参照してください。

    返品処理

    Order Managementは、クレジット・メモ作成用に返品受注明細をARにインタフェースします。

  2. 取り消された受注または受注明細の場合、前払の支払方法によってクレジットは様々な方法で払い戻されます。次の表を参照してください。

    払戻処理

    Order Managementによって、ARの払戻APIが次のように呼び出されます。

    受注全体を取り消す場合は自動的に呼び出されます。

    その他の場合は手動またはコンカレント・プログラムを使用して開始します。

    注意: 払戻APIを呼び出すと、ARは同じクレジット・カードまたは購買カードを入金の金額まで払い戻します。差額は小切手を使用してクレジットされます。

    払戻払戻
    クレジット
    支払方法         		Account Payableで発行される小切手 カード払戻 取引約定戻し処理 注釈
    クレジット・カード、購買カード   X   差額は小切手を使用してクレジットされます。
    ACH X      
    口座引落し X      
    電信送金 X      
    小切手 X      
    現金 X      

バッチ・モードでのクレジット・カード承認

クレジット・カード承認は遅延できます。これは、支払タイプ設定レベルおよび支払取引レベルで利用できます。保留承認を処理するには、「プロセス支払保留」コンカレント・プログラムまたは「支払の処理」処理を使用できます。

ビジネス・フロー

単一支払タイプ

  1. 「受注」ウィンドウを使用して受注を入力します。設定されているデフォルト・ルールに基づいて、デフォルトの支払タイプがヘッダーに表示されます。支払タイプに必要な追加データを入力します。たとえば、小切手の場合は、銀行口座、ルーティング番号および小切手番号が記録されます。

  2. 記帳時または出荷時に、受注タイプの設定および支払ルールの検証に基づいて、支払が承認されます。

  3. 請求時に、支払情報は、請求または回収、および会計目的でARに渡されます。

1つの受注に対する複数タイプでの支払

  1. 「受注」ウィンドウを使用して受注を入力します。設定されているデフォルト・ルールに基づいて、デフォルトの支払タイプがヘッダーに表示されます。支払タイプに必要な追加データを入力します。たとえば、支払タイプが発注の場合は、顧客発注番号が必要です。

  2. 必要に応じて受注明細を入力します。顧客は、クレジット・カードなど、別の支払タイプを使用して1つ以上の明細を支払うことを希望しています。2番目の支払情報を、今度は、適用される受注明細に追加します。他の明細はすべて、ヘッダーの支払タイプを使用して支払われます。別の明細で3番目の支払タイプを使用する場合は、同様の方法で入力します。

  3. 記帳または出荷時に、受注タイプの設定および支払ルールの検証に基づいて、クレジット・カードまたはその他の支払タイプが承認されます。承認情報が記録されます。

  4. 請求時に、支払情報は、請求または回収、および会計目的でARに渡されます。クレジット・カードで支払われる予定の明細では、クレジット・カード情報がARに渡されます。その他の明細では、明細またはヘッダーから支払タイプが取得されます。

前払フロー

  1. 「受注」ウィンドウを使用して受注を入力します。前払が必要であることを示す支払条件がデフォルト設定または選択されます。設定されているデフォルト・ルールに基づいて、デフォルトの支払タイプもヘッダーに表示されます。支払タイプに必要な追加データを入力します。たとえば、支払タイプがクレジット・カードの場合は、クレジット・カード番号と失効日が必要です。

  2. 受注に対する明細が入力されます。

  3. 受注を記帳します。頭金の金額に対して、クレジット・カード回収および入金作成が行われます。支払タイプがクレジット・カードの場合は、残高に対してクレジット・カード承認が試行されます。

  4. 通常どおり受注が出荷されます。

  5. 請求時に、残高が勘定で回収され、手順3で作成された入金が請求書と照合されるように、支払セットIDがARに渡されます。

賦払による支払

  1. 「受注」または「クイック受注」ウィンドウを使用して顧客および受注タイプを入力します。

  2. 設定されているデフォルト・ルールに基づいて、デフォルトの支払タイプおよび支払条件がヘッダーに表示されます。

  3. 支払条件は上書きできます。分割支払の支払条件を選択します。

  4. 1つ以上の品目を入力します。

  5. すべての品目を入力した後、支払情報を表示します。「支払」ウィンドウをオープンし、初回賦払の金額、および未回収金額を参照します。

  6. 受注を記帳します。

  7. 記帳または出荷時に、受注タイプの設定および与信チェック・ルールに基づいて、初回賦払または受注合計金額が承認されます。クレジット・カード認証は、記帳に対して与信チェックが設定されている場合にのみ行われます。承認される金額（全額または初回賦払）は、OMシステム・パラメータ「初回賦払のみ承認」の設定によって制御されます。

  8. 請求時に、支払情報は、請求または回収、および会計目的でARに渡されます。

ユーザー・プロシージャ

支払保証付きで、前払として小切手を指定して受注を入力し、受領書を印刷する手順は、次のとおりです。

  1. 「受注」ウィンドウにナビゲートし、受注を入力します。前払が必要であることを示す支払条件がデフォルト設定または選択されます。支払条件で100%頭金が必要であることが示されているとします。設定されているデフォルト・ルールに基づいて、デフォルトの支払タイプもヘッダーに表示されます。

  2. 受注に対するすべての明細を入力します。

  3. 入力終了後、受注ヘッダーに移動し、「支払」ウィンドウをオープンします。「支払」ウィンドウには、複数明細領域に2つのエントリがあり、各明細にデフォルトの支払タイプが設定されています。パーセントは支払条件定義からデフォルト設定され、この場合、頭金が100%、残高が0%になります。金額も同様に計算されます。

    「支払」ウィンドウ

    本文の説明内容に関するイメージ

  4. 頭金は小切手で支払われ、残りの金額に対しては請求が行われます。頭金の支払タイプとして小切手を選択し、小切手番号を入力して金額を確認します。計算された金額より多いか、または少ない可能性があります。必要な場合は金額を変更します。「支払」ウィンドウをクローズします。

  5. 受注を記帳し、「支払受領書の印刷」処理を選択して、小切手に対する受領書として顧客に渡すための受領書を印刷します。

  6. 受注管理処理では、小切手に対する入金が作成され、小切手の情報がARに渡されます。与信チェック条件が適用される場合は、残高が与信チェックされます。

  7. 小切手が決済されてから品目を出荷する場合、品目の出荷準備は整っているため、支払保証ワークフロー・アクティビティが起動され、そのアクティビティによってAR入金がチェックされ、小切手が決済されたかどうかが確認されます。小切手が決済されていない場合、商品はShippingにリリースされませんが、かわりに明細ステータスが支払保証待ちとなります。AR入金を通過すると、次回の支払保証アクティビティのチェック時に、チェックは成功し、明細は次のアクティビティ（出荷）に進みます。

  8. 品目が出荷され、明細は手順6で作成された入金の支払セットIDを持って請求に進みます。ARでは小切手入金が取引に自動的に適用され、未回収の残高に対する実際の請求書が送信されます。

参照

既存のクイック・コードの変更

新規クイック・コード

システム・パラメータ

新規の受注管理のシステム・パラメータ: 「複数支払を許可」を「No」に設定すると、既存の機能を保持できます。「No」に設定した場合、支払情報は受注ヘッダーでのみ入力できます。新規の「支払」ウィンドウにはナビゲートできません。この場合、部分前払機能のない、ヘッダー・レベルでの単一の支払タイプのみが許可されます。パラメータが「No」に設定されている場合は、より多くの支払タイプを使用できます。ただし、受注ごとに複数支払を使用し、頭金機能を使用するには、このパラメータを「Yes」に設定する必要があります。

注意: このパラメータは、一度「Yes」に設定すると、「No」に変更することはできません。

「初回賦払のみ承認」を「Yes」に設定すると、初回賦払のみを承認できます。デフォルトは「No」です。承認金額（全額または初回賦払）は、OMシステム・パラメータ「初回賦払のみ承認」の設定で制御されます。

複数支払のシステム・パラメータ複数支払のシステム・パラメータ
コード 名称 説明 カテゴリ 値セット オープン受注チェック 使用可 注釈
Multiple_Payments 複数支払を許可 複数支払機能を使用可能にします。 支払 OM: 「Yes」または「No」 W Yes 「No」でシードされています。
Authorize_First_Installment_Only 初回賦払のみ承認 初回賦払のみ承認します。 支払 OM: 「Yes」または「No」 Y Yes 「No」でシードされています。

制約

シード済処理制約

Order Managementには、受注の記帳後や前払入金作成後の属性の更新を禁止するためのシード済処理制約があります。また、クレジット・カードを使用した請求書支払については、承認が完了するとデータは変更できません。

前払の場合は、支払が処理され、入金が正常に作成されると、金額を修正して増減できる以外は、支払情報を更新できません。

前払の場合は、支払が処理され、入金が正常に作成されると、支払情報を削除できません。

受注ヘッダー

受注が記帳され、前払が処理される（支払セットIDが設定される）と、ユーザーは次の属性を変更できません。

受注明細

なし。

oe_paymentsの制約に対して次の2つの新規エンティティがあります。

  1. 受注支払

  2. 明細支払

受注支払

明細支払

支払タイプ

「支払タイプ」ウィンドウでの挿入/削除は許可されません。

「支払タイプ」ウィンドウでの更新は、Payment_type_codeは不可ですが、その他は可能です。

メッセージ

（ヘッダーまたは明細支払に対する）支払回収イベントが請求書の場合、選択できる支払手段は1つのみです。別の支払手段を追加すると、保存時にエラーが発生します。

メッセージ名: ONT_INVOICE_PAYMENT_INSTUMENT

メッセージ・テキスト: 請求書の支払手段を複数選択できません。

メッセージ・タイプ: エラー

前払は明細レベルの支払でサポートされていません。明細レベルの前払を追加すると、保存時にエラーが発生します。

メッセージ名: ONT_LINE_PREPAY_NOT_SUPPORTED

メッセージ・テキスト: 前払は明細レベルでサポートされていません。

メッセージ・タイプ: エラー

電信送金は前払手段としてサポートされていません。電信送金を前払手段として選択すると、エラーが発生します。

メッセージ名: ONT_NO_WIRE_TRANSFER_FOR_PREPAY

メッセージ・テキスト: 電信送金は前払ではサポートされません。

メッセージ・タイプ: エラー

複数の支払が存在する場合、支払情報を更新するには「支払」ウィンドウを使用する必要があります。

メッセージ名: ONT_MULTIPLE_PAYMENTS_EXIST

メッセージ・テキスト: 受注に複数の支払が存在するため、受注ヘッダーの支払属性を更新できません。支払属性を更新するには、「支払」ウィンドウを使用してください。

メッセージ・タイプ: エラー

前払と明細レベルの支払は同時に使用できません。

メッセージ名: ONT_LINE_PAYMENTS_EXIST

メッセージ・テキスト: 明細レベルに支払が存在するため、前払を入力できません。

メッセージ・タイプ: エラー

メッセージ名: ONT_LINE_INVOICE_NOT_SUPPORTED

メッセージ・テキスト: 受注レベルに前払が存在するため、明細レベルで支払を入力できません。

メッセージ・タイプ: エラー

明細レベルの支払は受注明細に関連付けられる必要があります。

メッセージ名: ONT_NO_LINES_FOR_PAYMENT

メッセージ・テキスト: この受注に明細がないため、明細レベルの支払を入力できません。

メッセージ・タイプ: エラー

「支払」ウィンドウを使用した支払情報の更新。

メッセージ名: ONT_GOTO_PAYMENTS_WINDOW

メッセージ・テキスト: この受注の支払属性を更新するには、「支払」ウィンドウを使用してください。

メッセージ・タイプ: エラー

受注インポート: 支払参照情報が無効な場合は、エラーが発生します。

メッセージ名: OE_OI_ORIG_SYS_PAYMENT_REF

メッセージ・テキスト: 無効なORIG_SYS_PAYMENT_REFです。NULL以外の値を入力してください。

メッセージ・タイプ: エラー

ARのデータ要件

  1. 取引約定: 取引約定番号

  2. クレジット・カード/Pカード: 番号、失効日

  3. ACH: 通常のビジネス慣習では、顧客との基本契約が記録され、顧客は、自分の銀行口座に借方記入するACH転送の開始者（Oracle配布企業: 取引先）を承認します。次の各データを取得できる場合は、1回の電話によるACH承認が法的に認可されています。

    これら6点がNACHA（ACHネットワークの管理団体）によって要求されています。

  4. 電信

  5. 小切手: 次の2通りのフローがサポートされています。

遡及請求の概要

遡及請求は、ある種の業界、特に自動車業界の一般的なビジネス・プラクティスを指します。この方法は、クレジットを受け取るために請求済受注で仕入先から請求された金額について、顧客が変更を要求する場合に使用されます。

営業基本契約または発注上の品目の価格は、定期的に変更されます。たとえば、商品の価格が急激に上下することがあります。顧客は、営業基本契約または発注に対する修正を発行します。価格変更が遡及となる場合は、遡及請求期間中に発生した出荷数量が識別され、追加費用またはクレジットが計算されて、請求のために顧客に送られます。

遡及請求の主な機能

価格表の変更

品目の新規販売価格、品目の範囲または特定の顧客の価格表を取得できます。新規販売価格は、有効日の範囲を指定して（単価または旧価格に対する%として）入力できます。

「価格表」ウィンドウを使用すると、有効日の範囲を指定して品目または品目カテゴリの単価を定義または変更できます。また、価格表にクオリファイアを追加して、特定の価格表の価格が適用される顧客または受注の種類を指定することもできます。「営業基本契約」ウィンドウは、価格表明細の変更を取得するための入力ウィンドウです。

1. 遡及請求明細のタイプが「受注」であるか「返品」であるかを判別するために、定価の差異が考慮されます。定価の差異が0（ゼロ）の場合は、販売価格の差異が考慮されます。例: 請求済ULPが$100で最新ULPが$50の場合は、請求済USPが$90で最新USPが$110（設定に新規モディファイアがあるため）でも、遡及請求明細のタイプは「返品」です。

2. 当初明細（または以前の遡及請求明細）に存在するモディファイアが遡及請求の実行時の設定で無効な場合、このモディファイアは、遡及請求明細に関する「調整の表示」ウィンドウに表示され、adjusted_amountの値は次のようになります。遡及請求明細のタイプが「受注」の場合、遡及請求明細に対応するadjusted_amountは、当初明細（または以前の遡及請求明細）に対応するadjusted_amountに-1を乗算した値です。遡及請求明細のタイプが「返品」の場合、遡及請求明細に対応するadjusted_amountは、当初明細（または以前の遡及請求明細）に対応するadjusted_amountです。

3. 新規モディファイアMOD_NEWが設定に存在し、価格設定エンジンによって戻された場合、「調整の表示」ウィンドウのMOD_NEWに対するadjusted_amountの値は、次のようになります。list_line_type_codeが'PBH'の場合は、'DIS'に変更されます。遡及請求明細のタイプが「受注」の場合、adjusted_amountは、最新の定価に対応する価格設定エンジンによって戻される金額です。遡及請求明細のタイプが「返品」の場合、adjusted_amountは、最新の定価に対応する価格設定エンジンによって戻される金額に-1を乗算した値です。

4. 「調整の表示」フォームでの差異調整の場合、list_line_type_codeが'DIS'の場合は符号(オペランド)= -1*符号(adjusted_amount)、list_line_type_codeが'SUR'の場合は符号(オペランド)=符号(adjusted_amount)です。

適格明細の識別

柔軟な基準リストを使用して、適格の出荷済/請求済明細を識別できます。次の基準で請求書明細を識別できます。

適格明細のレポート

価格が再設定された適格の請求書明細をすべてレポートできます。このレポートは、RLMの現行の遡及請求レポートにかわるものです。プレビューまたは実行済の遡及請求要求の結果をオンラインで表示できます。

関連項目: 遡及請求レポート

先日付の出荷に対する価格調整

先日付の全出荷の価格設定を、新規の価格表情報に基づいて更新できます。オープン・オーダーを一括変更するか、出荷確認前に出荷の価格を再設定して、最新の価格詳細を保証できます。

この機能はOrder Managementで使用可能です。受注を一括選択して「受注の価格設定」処理を使用できます。または、明細ワークフローに出荷時に再価格設定するワークフロー・アクティビティを追加できます。これにより、請求前の出荷時に再価格設定が自動的に実行されます。

再請求済明細の参照可能性

適格の請求書明細を検索するときに、請求書明細に対する再価格設定処理をすべて識別できます。再価格設定済の明細の履歴、最新の販売単価およびその価格に基づいていない借方/貸方を表示できます。

遡及請求レポートと照会結果には、適格な受注明細が表示されます。請求済単価と請求済金額は、実行済の遡及請求処理の正味額です。つまり、当初請求単価が$10で、すでに遡及請求が一度実行されて価格が$9に引き下げられており、現在は価格を$8に引き下げるために別の遡及請求要求で作業している場合、レポートと問合せでは請求済単価が$9として表示されます。

遡及請求のプレビュー（照会）

遡及請求基準を使用して、適格の請求書明細、提示済の価格変更（更新済の販売単価、借方または貸方としての請求書差異付き）および請求済金額に影響する過去の価格変更のリストをプレビューできます。

この処理では、遡及請求要求をプレビュー・モードで実行でき、結果をオンラインで表示できます。プレビューの（同時またはリアルタイム）実行後は、ウィンドウの「調整」/「クレジット」部分が「要約」タブとともに移入されます。また、当初価格、新価格および価格差異などの遡及請求詳細を示す「遡及請求レポート」を印刷できます。

調整の承認および自動作成

調整を作成する前に、再価格設定済の明細セットを承認できる必要があります。再価格設定済の適格の請求書明細のリストを承認すると、各明細の借方（請求書明細）または貸方（クレジット・メモ）を自動的に作成できます。新規請求書明細は、1件の請求書に出荷別、顧客出荷先事業所別または顧客別にグループ化できます。新規クレジット・メモ明細は、1件のクレジット・メモに出荷別、顧客出荷先事業所別または顧客別にグループ化できます。

承認プロセス

承認処理では、プレビュー結果を表示して遡及請求要求を実行するように選択します。そのアクティビティでは、遡及請求受注が記帳され、他の受注/明細に似たワークフローが実行されます。

注意: 会社がより正式な承認処理を必要とする場合は、受注または明細のワークフローにワークフロー承認ステップを挿入できます。

遡及請求受注

遡及請求イベントが発生すると、オープン調整受注明細として調整金額が作成されます。価格が上昇すると、この明細は請求のみとなり、「受注」明細カテゴリが設定されます。価格が下落すると、この明細はクレジットのみとなり、「返品」明細カテゴリが設定されます。新規のシード済遡及請求ソースは、明細が調整済明細であることを示し、現行の遡及請求要求を参照します。次の表を参照して、遡及請求明細の属性がどのように移入されるかを確認してください。

遡及請求の値
遡及請求明細の列 値の取得元
品目 当初明細からコピーされます。
数量 遡及請求可能数量（当初明細の受注数量から返品数量が差し引かれた数量）。
単位 当初明細からコピーされます。
明細カテゴリ・コード 明細が顧客へのクレジット提供に使用される場合は「返品」、
顧客への請求に使用される場合は「受注」。
明細タイプ 受注タイプ定義に設定されているデフォルトの「受注」または「返品」明細タイプが使用されます。
品目タイプ・コード 常にSTANDARDとしてハードコード化されます。
価格計算フラグ デフォルトで凍結価格を意味するNに設定されます。
単価 価格表明細の単価差異です。
販売単価 値引適用後の差異です。
価格表 当初受注明細の価格表が有効でなくなった場合は、デフォルト・フレームワークに基づいてデフォルト設定されます。これは、デフォルト設定エンジンまたは価格設定エンジンの出力に基づいた当初受注明細とは異なる場合があります。
価格設定日 現在の日付です。
税コード 当初明細からコピーされます。
Shippable_Flag N。明細が出荷不可であることを意味します。
返品事由コード システム・パラメータ「デフォルト遡及請求事由」からデフォルト設定されます。遡及請求要求ごとに上書きすることもできます。
Order_Source_ID 新規のシード済受注ソース・タイプ「遡及請求」です。
Orig_sys_document_ref 当初受注のheader_idが格納されます。
Orig_sys_line_ref 当初受注明細のline_idが格納されます。
Source_Document_shipment_ref 遡及請求の場合は移入されません。
Retrobill_Request_ID 遡及要求表への外部キーです。
Reference_Line_Id この列は使用しません。
Credit_Invoice_Line_Id 遡及請求済の請求書明細が格納されます。
Shipped_Quantity NULL
Reserved_Quantity NULL
Shipping_Quantity NULL
Shipping_quantity_UOM NULL
Actual_Shipment_Date NULL
Over_Ship_Reason_Code NULL
Over_Ship_Resolved_Flag NULL
Shipping_interfaced_Flag NULL
Option_Number NULL
Commitment_Id NULL
その他のフィールド 当初明細からコピーされます。

前述の明細は、顧客別、通貨別、換算タイプ別、換算日別、および換算レート別にグループ化されます。これらの受注は、請求のみまたはクレジットのみのオープン受注です。ARグループ化ルールに応じて、遡及請求受注から1件以上の請求書またはクレジット・メモを生成できます。受注属性がどのように移入されるかについては、次の表を参照してください。

受注属性の移入
遡及請求受注の列 値の取得元
受注タイプ 受注管理のシステム・パラメータからデフォルト設定されます。このデフォルトは、遡及請求要求用に受注タイプを選択して上書きできます。
その他の属性 デフォルト設定されます。
Order_Source_Id 新規の受注ソース・タイプ「遡及請求」を使用します。
Orig_sys_document_ref retrobill_request_idが格納されます。

注意: 遡及請求明細には、当初明細の基本契約情報がコピーされます。

遡及請求イベント・パラメータ

必要に応じて、遡及請求処理に次の入力パラメータを指定できます。

遡及請求イベント・パラメータ遡及請求イベント・パラメータ
パラメータ 説明 必須か デフォルト・ソース
受注タイプ 遡及請求受注の作成に使用される受注タイプ No 受注管理のシステム・パラメータ。
遡及請求事由 ARに送信されるクレジット・メモ事由 Yes 受注管理のシステム・パラメータ。
遡及請求イベント名 遡及請求処理を識別する名称 Yes  
摘要 遡及請求要求の短い摘要または注釈 No  
モード 「プレビュー」または「実行」 Yes 選択する処理によって決定されます。プレビューした遡及請求受注が保存されている場合は、「入力済」ステータスで作成されます。実行済の遡及請求受注は、「記帳済」ステータスで作成されます。

遡及請求金額の計算

シード済の価格設定イベント「遡及請求」では、請求金額またはクレジット金額が決定されます。このイベントは価格設定フェーズ「リスト明細基準価格」とともにシードされます。当初受注明細に適用済の値引がある場合は、その値引が新規の定価に適用され、価格変更の有無が判別されます。

明細レベルのモディファイアの再評価も必要とする顧客の場合は、Advanced Pricingのイベント・フェーズ・マッピングを変更し、明細レベル・フェーズを有効化できます。modifier_level_code='LINE'のフェーズのみを添付する必要があります。遡及請求エンジンにより検証が実行され、誤ったフェーズが添付されている場合はエラーが発生します。考慮されるのは、値引、追加料金および価格分岐ヘッダーのみです。

  1. 明細グループ・レベルと受注レベルの値引の再計算はサポートされていません。

  2. 現在の日付を価格設定日として、選択した受注明細の価格が設定されます。

  3. 各調整は当初受注明細（および、前に遡及請求済の場合は、価格設定日に基づく最新の遡及請求明細）に添付された同一モディファイアと比較され、adjusted_amount差異が計算されます。この調整は、適用済の差異とともに格納されます。適用方法は、必要に応じて「金額」に変更されます。遡及請求明細の「調整の表示」に表示されるのは、この種の調整のみです。

    販売実績

営業担当と販売実績は、当初受注明細からコピーされます。これらの情報がOracle Receivablesにインタフェースされ、販売実績が調整されます。

ワークフローの考慮点

遡及請求受注に使用される受注タイプについては、「受注」と「返品」の両方の明細に対して同じワークフローを割り当ててください。「受注」と「返品」の明細に対するワークフローで異なる処理が必要な場合は、遡及請求明細の明細カテゴリに基づいて分岐するワークフローを作成してください。

典型的な遡及請求の使用

ここでは、この設計による遡及請求機能の典型的な使用例について説明します。これは、すべてのビジネス・シナリオを説明するものではありません。

品目定価の下落に伴う顧客への遡及クレジット処理

  1. 顧客AおよびBから次の受注を得たとします。

    顧客受注の発行
    受注番号 顧客 明細 品目 数量 明細カテゴリ 単価 販売単価 金額 請求書番号
    1000 A 1.1 X 10 受注 20 20 200 2000
    1001 B 1.1 X 20 受注 20 20 400 2001
    1000 A 1.1 X 5 受注 20 20 100 2002

    顧客受注の発行

  2. 品目Xの単価が$20から$17に下落しました。ユーザーは品目Xの法人価格表明細を取り消して、品目X用に別の価格表明細を追加しました。

    価格表の変更
    価格表 品目 開始有効日 最終有効日 単価
    法人 X 1/1/2000 7/31/2003 20
    法人 X 8/1/2003   17

    価格表の変更

ユーザーはこの3件の受注を遡及請求し、遡及請求エンジンにより次の受注が生成されます。

遡及請求生成受注
受注番号 顧客 明細 品目 数量 明細カテゴリ 単価 販売単価 金額 対象となるクレジット・メモ
2000 A 1.1 X -10 返品 3 3 -30 請求書2000
2001 B 1.1 X -20 返品 3 3 -60 請求書2001
2000 A 1.1 X -5 返品 3 3 -15 請求書2002

遡及請求生成受注

品目定価の上昇に伴う顧客への遡及請求処理

  1. 顧客AおよびBから次の受注を得たとします。

    顧客受注の発行
    受注番号 顧客 明細 品目 数量 明細カテゴリ 単価 販売単価 金額 請求書番号
    1000 A 1.1 X 10 受注 20 20 200 2000
    1001 B 1.1 X 20 受注 20 20 400 2001
    1000 A 1.1 X 5 受注 20 20 100 2002

    顧客受注の発行

  2. 品目Xの単価が$20から$23に上昇しました。ユーザーは品目Xの法人価格表明細を取り消して、品目X用に別の価格表明細を追加しました。

    価格表の変更価格表の変更
    価格表 品目 開始有効日 最終有効日 単価
    法人 X 1/1/2000 7/31/2003 20
    法人 X 8/1/2003   23

  3. ユーザーはこの3件の受注を遡及請求し、遡及請求エンジンにより次の受注が生成されます。

    遡及請求生成受注遡及請求生成受注
    受注番号 顧客 明細 品目 数量 明細カテゴリ 単価 販売単価 金額 請求書番号
    2000 A 1.1 X 10 受注 3 3 30 3000
    2001 B 1.1 X 20 受注 3 3 60 3001
    2000 A 2.1 X 5 受注 3 3 15 3000

ユーザー・プロシージャ

遡及請求を実行する手順は、次のとおりです。

  1. 「遡及請求オーガナイザ」の「検索」ウィンドウにナビゲートします。

    遡及請求オーガナイザの「検索」ウィンドウ

    本文の説明内容に関するイメージ

  2. 遡及請求する受注の基準を入力します。品目と顧客による検索は、「受注オーガナイザ」で実行できる検索と同様です。基準と一致する明細が表示されます。

    「営業単位」フィールドはフォルダ対応で、すべてのタブで使用可能です。デフォルトの営業単位が表示されます。値リストから、アクセス可能な別の営業単位を選択できます。選択した営業単位で遡及請求が（システム・パラメータを介して）使用可能になっている必要があります。

    「遡及請求: 結果の検索」ウィンドウ

    本文の説明内容に関するイメージ

  3. 遡及請求する行を選択します。行を選択しないと、手順4から6で説明する処理が検索基準で選択されたすべての行に対して実行されます。

  4. 「オンライン」または「コンカレント要求」をクリックして遡及請求を起動します。パラメータ・ウィンドウが表示され、パラメータを指定できます。遡及請求イベント名、摘要、受注タイプ、事由およびモード（「プレビュー」または「実行」）を指定できます。

    遡及請求パラメータ・ウィンドウ

    本文の説明内容に関するイメージ

  5. 必要に応じて、遡及請求のプレビュー・アクティビティを実行します。これによって、遡及請求エンジンがプレビュー・モードで実行されます。要求を名称で問い合せると、遡及請求オーガナイザでプレビューの結果を表示できます。各明細の遡及請求金額および要約情報も表示できます。必要な場合は遡及請求レポートを実行し、詳細を標準レポートとして表示できます。

    複数の営業単位の受注に対して単一の遡及請求要求は作成できません。ただし、職責を変更せずにアクセス可能な異なる営業単位の受注は遡及請求できるため、アクセス可能な各営業単位に対して複数の遡及請求要求（1つ以上）が作成されます。

    注意: プレビューまたは実行後に、遡及請求エンジンにより作成された遡及請求受注明細が「明細」タブに表示されます。プレビューした結果について、遡及請求受注明細の選択を解除したり、遡及請求数量を変更して、再びプレビューまたは実行できます。

    入力パラメータを入力して「OK」をクリックできます。「コンカレント要求」ボタンを使用して起動した場合は、コンカレント要求IDが表示され、カーソルが「遡及請求」ウィンドウに戻ります。「オンライン」ボタンを使用して起動した場合は、結果が遡及請求明細ごとに「遡及請求」ウィンドウの「明細」タブに表示されます。さらに「要約」タブも表示されます。「要約」タブをクリックすると、遡及請求受注を表示できます。この「要約」タブには、2つのリージョンがあります。

    上部リージョンには、「遡及請求イベント」、「摘要」、「受注タイプ」および「事由」の各パラメータが表示されます。また、「要求ステータス」フィールドは、遡及請求要求がプレビュー・モードであるか実行モードであるかを示します。

    下部リージョンは「受注オーガナイザ」の「要約」タブと同じで、フォルダ対応です。シード済のデフォルト・フォルダには、「受注番号」、「顧客名」、「通貨」、「受注額」、「小計」、「税」、「換算タイプ」、「換算レート」および「換算日」があります。「営業単位」はフォルダ対応のフィールドです。

    遡及請求検索結果の「要約」タブ

    本文の説明内容に関するイメージ

  6. 任意の遡及請求明細の数量を変更するか、実行前に明細のプレビュー・セットから明細を削除するように選択できます。

  7. 最後に、遡及請求の実行アクティビティを選択します。これによって、選択した明細に対して遡及請求エンジンが実行モードで実行されます。先にプレビューしなかった場合は、この時点で遡及請求受注および明細が作成され、記帳されます。先にプレビューして結果を保存している場合は、今回の実行によって、遡及請求受注が「記帳済」ステータスに更新されます。

  8. 必要な場合は、要求を実行せずに終了し、後から「遡及請求オーガナイザ」で問い合せて遡及請求要求に戻ることができます。

  9. プレビュー済の遡及請求要求をイベント名で問い合せるには、「遡及請求オーガナイザ」ウィンドウの「遡及請求要求」タブにナビゲートします。このタブは、遡及請求要求を品目、顧客、要求日で問い合せる場合にも使用できます。このタブに情報を入力すると、「受注情報」および「明細情報」タブが使用不可になります。品目識別子タイプと受注品目は非表示のフォルダ・フィールドとして使用できるため、顧客品目の問合せも可能です。

    注意: 注意: フィールドには自由形式のテキストを入力でき、問合せは入力した内容に基づいて実行されます。値リストから要求を選択した場合、問合せは、選択内容に対応するretrobill_request_idに基づいて実行されます。

  10. 「検索」をクリックすると、次の要約ウィンドウが表示されます。遡及請求要求を1つ選択して「オープン」をクリックし、遡及請求要求を個別に表示できます。

    注意: 検出された遡及請求要求が1件のみの場合、遡及請求要求の要約ウィンドウは表示されず、「遡及請求」ウィンドウが表示されます。

シード・データ

受注管理パラメータ

遡及請求に関連して、次のような受注管理パラメータが新しく追加されました。

  1. 遡及請求使用可: 値は「使用可」または「使用不可」です。デフォルトは「使用不可」です。

  2. 遡及請求の「デフォルト受注タイプ」: 値は、定義済の有効な受注タイプすべてに基づきます。この値は、遡及請求受注のデフォルト受注タイプとして使用されます。

  3. 遡及請求事由コード: 値は、有効なARクレジット・メモ事由すべてに基づきます。この値は、遡及請求受注のデフォルトの遡及請求事由として使用されます。

前述のパラメータは、新規カテゴリ「遡及請求」に追加されます。

制約

新規のシード済検証テンプレート「遡及請求明細」。retrobill_request_idが移入されている明細の場合はTRUEとなります。

新規のシード済検証テンプレート「返品遡及請求明細」。返品明細の作成後に遡及請求明細が作成された返品明細の場合はTRUEとなります。

請求処理

顧客受入

様々な国の多くの会社では、商品を正式に受領した後で仕入先から請求される商取引が一般的です。顧客受入を記録して表示するために、Oracle Order ManagementはAccounts ReceivablesおよびCostingと統合されています。顧客は、次のいずれかの方法で、またはいくつかの方法を組み合せて商品を受け入れることができます。

請求前顧客受入では、商品の受入後に請求が実行されます。請求後顧客受入では、収益認識処理が遅延され、出荷済商品を受け入れた顧客にリンクされます。全受入のみ記録され、一部受入は記録されません。遅延会計基準がある明細では、請求後顧客受入はサポートされません。

黙示的な顧客受入

受注明細の「受入日数」フィールド（「その他」タブ、フォルダ対応）で、顧客受入に対して指定した期限を確認できます。これは、Receivables（収益管理）の延期事由定義で設定されます。延期事由の設定方法および失効活動の詳細は、『Oracle Receivablesユーザーズ・ガイド』を参照してください。

黙示的な顧客受入

請求前および請求後の黙示的受入は、「黙示的受入要求セット」を使用してチェックされます。この要求セットは、黙示的受入の失効を検証します。

明示的な顧客受入

「履行受入」処理項目を使用して、商品を明示的に受け入れることができます。これは「受注明細」ウィンドウで使用でき、このオプションを選択すると、受注情報ポータルの「受注詳細」ウィンドウがオープンします。

本文の説明内容に関するイメージ

明示的受入は受注情報ポータルに記録され、このポータルを使用して、一度に複数の明細を検索して受入または拒否できます。

本文の説明内容に関するイメージ

「受入」または「拒否」を選択すると、受注情報ポータルの明細の受入ステータスが「受入済」または「拒否済」に変更されます。受注情報ポータルに受入を記録するには、受入日、署名およびその他のフィールドを指定する必要があります。また、「受注」ウィンドウの受注ステータスは「クローズ」に変更されます。「受注」ウィンドウには、最早許容日と最遅許容日の2つの日付が表示され、これらは顧客受入機能ではなく予定作成に関連します。受入日、受入注釈などの受入詳細は、明細がクローズする前のみ更新でき、明示的受入を実行する権限（機能セキュリティ）を持つユーザーが使用できます。

注意: 受入日は履行日よりも前の日付に設定できますが、実際の出荷日よりも前には設定できません。実際の出荷日を使用できない場合、受入日は履行日と比較検証され、履行日よりも前には設定できません。

顧客受入はヘッダー・レベルと明細レベルで可能ですが、受注明細（「その他」タブ）には顧客受入関連の次のフィールド（フォルダ対応）があります。

本文の説明内容に関するイメージ

受入名をフィールドに指定します。これは延期事由とも呼ばれ、Receivablesの収益管理で定義されます。受入が失効する日数がReceivablesで定義されている場合は、「受入日数」に値が表示されます。同様に、「受入失効イベント」には、Receivablesフィールドからの値が表示されます。これらは黙示的受入の場合に値が挿入されます。

販促商品の顧客受入

当初品目に販促商品が関連付けられている場合、顧客は両方を個別に受け入れる必要があります。顧客は一方を受け入れてもう一方を拒否することもできます。

ATO/PTO/CTO品目の顧客受入

ATOモデルの場合:

PTOモデルの場合:

キットの場合（PTO品目）:

受入はトップ・モデルでのみ可能です。トップ・モデル明細が受け入れられると、すべての展開品目が受け入れられます。

営業基本契約の場合は、商品が拒否または廃棄として処理されると、RMA（返品承認）を作成する必要があります。営業基本契約の数量と金額は、請求前の受入または拒否の際に調整できます。

ユーザー・プロシージャ

顧客受入を記録および表示する手順は、次のとおりです。

一般手順

  1. 顧客による受入が必要な受注を入力します。この受入は顧客営業担当が記録します。

  2. 受注明細の各受入フィールドを表示/更新します。受注明細の「その他」タブには、フォルダ対応の受入フィールドが表示されます。

  3. 受注通知レポートには、「受入要」と印刷されます。

  4. 品目の出荷を確認します（「請求前受入保留中」または「請求後受入保留中」明細ステータスを表示します）。

  5. 受入/拒否を実施します。

  6. 受注明細に受入詳細を表示します。

  7. 明示的受入:

    ヘッダーまたは明細から受注情報ポータル（「受注処理 - 履行受入」をクリック）を介した受入、または受注インポート経由での受入です。

  8. 黙示的受入:

    イベント属性を出荷確認日および失効日数として使用し、延期事由をARに定義する必要があります。

黙示的受入を記録する黙示的受入要求セットは、次の複数のコンカレント・プログラムで構成されています。

顧客受入/拒否のシナリオ

ここでは、受入/拒否（黙示的または明示的、請求前または請求後）が指定されるいくつかのシナリオを示します。

請求前顧客受入、明示的な全受入

請求前に顧客受入が要求され、明示的な全受入の場合:

  1. 請求前に顧客受入が要求され、明示的な全受入の場合:

  2. 受注がピックされて出荷されます。

  3. 受注明細のステータスは「請求前受入保留中」になります。

  4. 顧客は、受注情報ポータルにログインし、注文を問い合せて、出荷された全数量に対して明細を「受入済」とマークします。あるいは、顧客が電話またはFAXでコール・センターに受入を伝えると、CSRはその注文を問い合せて、「受注」フォームの「履行受入」処理を使用して受注情報ポータル・ページを表示し、受入を記録します。

  5. 受注明細は請求処理および収益認識へ進みます。明細の請求日は受入日になります。

  6. CSRは明細を問い合せて、受入の詳細を検索できます。

請求前顧客受入、一部商品の受入不可

請求前に顧客受入が要求されるが、明細の数量の一部が受入不可の場合:

  1. CSRは受注を入力して記帳します。

  2. 受注がピックされて出荷されます。

  3. 受注明細のステータスは「請求前受入保留中」になります。

  4. 顧客はCSRに対して電話またはFAXで、受領したすべての品目を受け入れることができず、1つ以上の受注明細の一部を拒否することを伝えます。CSRは顧客に対して、取り替えるためにその品目を返送するように依頼します。

  5. CSRは、当初の受注明細を参照してクレジットのためのRMAを作成します（当初の受注明細は請求されていないため、クレジットは対顧客勘定になります）。

  6. CSRは、取替商品を出荷するための新規受注も作成します。

  7. 取替品目が出荷されて受領されると、顧客は電話またはFAXで、品目が受入可能であることを伝えます。

  8. CSRは、受注情報ポータルにログインし、当初の受注明細を問い合せて、出荷された全数量に対して明細を「受入済」とマークします。または、「受注」フォームの「履行受入」処理を使用して受注情報ポータル・ページを表示し、全受入を記録します。受入を記録するとき、CSRは、詳細を記録し、必要に応じて取替受注番号を参照できるように、注釈を入力できます。

  9. 受注明細は請求処理および収益認識へ進みます。

  10. CSRは明細を問い合せて、受入の詳細を検索できます。

請求後顧客受入、黙示的な全受入

請求後の顧客受入で、黙示的な全受入の場合:

  1. CSRは受注を入力して記帳します。収益管理で、出荷後30日以内に明示的な受入または拒否が実行されない場合は受入とみなすように設定されます。

  2. 受注がピックされて出荷されます。

  3. 受注明細は請求にインタフェースされます。

  4. 受注明細のステータスは「請求後受入保留中」になります。

  5. 30日を経過しても、商品の受入または拒否はありません。

  6. 受入とみなされます。受注明細はクローズし、収益認識が発生します。

  7. 後で問合せがあった場合、CSRは受注明細を問い合せて、出荷後31日目に自動受入が生成されたことを確認します。

請求後顧客受入、明示的な全拒否

請求後に顧客受入が要求され、明示的な全拒否の場合:

  1. CSRは受注を入力して記帳します。

  2. 受注がピックされて出荷されます。

  3. 受注明細は請求にインタフェースされます。

  4. 受注明細のステータスは「請求後受入保留中」になります。

  5. 顧客はCSRに対して電話またはFAXで、受注明細を拒否したことを伝えます。CSRは顧客に対して、品目を返送するか、または廃棄するように依頼します。

  6. CSRは、受注情報ポータルにログインし、受注明細を問い合せて、出荷された全数量に対して明細を「拒否済」とマークします。または、「受注」フォームの「履行受入」処理を使用して受注情報ポータル・ページを表示し、拒否を記録します。

  7. 受注明細をクローズします。

  8. CSRは、拒否された受注明細を参照して、商品の受領または廃棄を示す明細フローがあるRMA受注を作成します。

  9. CSRは明細を問い合せて、受入の詳細を検索できます。

請求前顧客受入、明示的な全受入、商品とサービスが同じ受注

請求前に顧客受入が要求され、明示的な全受入の場合:

  1. CSRは、製品およびその製品に対するサービス（延長保証）の受注を入力して記帳します。

  2. 商品明細がピックされて出荷されます。

  3. 両方の受注明細（商品およびサービス）のステータスは「請求前受入保留中」と表示されます。

  4. 顧客はCSRに対して電話またはFAXで、商品を受け入れたことを伝えます。

  5. CSRは、受注情報ポータルにログインし、商品の受注明細を問い合せて、出荷された全数量に対して明細を「受入済」とマークします。サービス明細は、受入可能な明細としてユーザー・インタフェースに表示されません。あるいは、CSRは、「受注」または「クイック受注」フォームで受注を問い合せて、「履行受入」処理を起動し、受注情報ポータル・ページを表示して明細を受入としてマークします。

  6. 両方の受注明細が請求処理および収益認識へ進みます。商品およびサービスの請求日は受入日になります。

  7. CSRは明細を問い合せて、受入の詳細を検索できます。

請求前顧客受入、遅延サービス

請求前に顧客受入が要求され、受注に遅延サービスがある場合:

  1. CSRは、Order Managementを使用して、別の注文で受注した品目に対するサービス（延長保証など）の受注を入力します。サービス明細では、サービス可能品目の当初受注またはその導入ベース・インスタンスを参照できます。CSRはサービスの受注を記帳します。

  2. サービス明細のステータスは「請求前受入保留中」になります。

  3. サービス可能商品がすでに受け入れられている場合は、サービス明細も自動的に受け入れられます。ユーザーによる処理は必要ありません。商品明細の受入詳細がサービス明細にコピーされます。

  4. サービス可能商品が受け入れられていない場合、サービス明細は、商品明細が受け入れられるまで、「請求前受入保留中」ステータスで請求インタフェースで待機します。CSRは、サービス明細を明示的に受入または拒否できません。商品明細が受け入れられると、受入詳細がサービス明細に自動的にコピーされ、サービス明細はワークフロー内を自動的に先に進みます。

  5. 商品が受け入れられると、サービス明細は請求されてクローズします。

  6. 受入詳細はサービス明細にコピーされるため、後でサービス明細の受入時期や受入方法について問合せがあった場合に、CSRはサービス明細を問い合せることができます。

請求前顧客受入、ATOまたはPTOモデル

請求前に顧客受入が要求され、PTO内のATOを含むATOおよびPTOモデルの明示的な全受入の場合:

  1. CSRは受注を入力し、構成して（必要な場合）記帳します。

  2. 受入属性は、受注のトップ・モデル明細（子明細ではなく）でのみ表示して更新できます。

  3. 受注がピックされて出荷されます。

  4. 構成のすべての子明細も含めて、すべての受注明細のステータスは「請求前受入保留中」になります。

  5. 顧客は受注情報ポータルにログインし、注文を問い合せます。顧客が表示できるのは、受入対象となるモデル明細のみです。顧客は、出荷された全数量に対して明細を「受入済」とマークします。

  6. すべての受注明細は請求処理および収益認識へ進みます。

  7. CSRは明細を問い合せて、受入の詳細を検索できます。

注意: 非SMC PTOモデル、および埋込みATOモデルがあるPTOモデルの場合、受入はトップ・モデル・レベルでのみ発生することに注意してください。出荷されたオプションに対して請求および回収が必要な場合は、請求前受入ではなく請求後受入を選択する必要があります。

クレジット・カード暗号化

Oracle PaymentsおよびCash Managementでは資金取得拡張が開始され、その目的はクレジット・カードおよび銀行口座の集中化された情報システムを使用することです。クレジット・カード番号、クレジット・カード・セキュリティ・コード（CVV2）、銀行口座などの重要な機密データは、暗号化されてこの集中化されたモデルに格納されます。これは、クレジット・カード詳細などの情報をローカルに格納していたアプリケーション（Order Managementなど）が、この集中化されたモデルに統合されたことを意味します。これによって、セキュリティが強化され、重要情報を管理できます。「受注」ウィンドウ、「支払」ウィンドウおよび「クイック受注」ウィンドウでは、クレジット・カード保有者名などのクレジット・カード情報が暗号化された書式で表示され、失効日は値なしで表示されます。また、これらのウィンドウのクレジット・カード失効ステータス・フィールドには、暗号化された失効日に基づいて、クレジット・カードのステータスを「未失効」または「失効済」で表示できます。暗号化の書式はカスタマイズ可能で、次のオプションがあります。

注意: このオプションは、銀行口座のマスクにも使用できます。

本文の説明内容に関するイメージ

明細がヘッダー・レベルのクレジット・カードで保証され、ヘッダー・レベルのクレジット・カードに対して有効な承認が存在する場合は、明細レベルのクレジット・カード支払は入力できません。「クレジット・カード支払はこの明細に入力できません。受注ヘッダーで指定されたクレジット・カードにより、すでに承認されています。」というエラー・メッセージが表示されます。

これまでのリリースからアップグレードされたクレジット・カード受注については、アップグレード前に「監査履歴連結」プログラムを実行していた場合は、「監査履歴の表示」ウィンドウに表示されるクレジット・カード番号は暗号化された書式であり、クレジット・カード番号の新しいマスク設定は適用されません。

アップグレード後に「監査履歴連結」コンカレント・プログラムを実行すると、「監査履歴の表示」ウィンドウに表示されるクレジット・カード番号は現行のクレジット・カード・マスク設定による書式です。

アップグレード前のリリースでクレジット・カード受注に対して「監査履歴連結」を実行していた場合は、クレジット・カード番号が「監査履歴の表示」ウィンドウにマスクされた書式で表示できます。表oe_audit_attr_historyのクレジット・カード関連のレコードを削除して、「監査履歴連結」コンカレント・プログラムを再実行できます。クレジット・カード・レコードの属性IDは46、47、48、49です。

クレジット・カード・セキュリティ・コード

商品およびサービスの売買時に、クレジット・カードの不正使用からインターネット・ベースの取引を保護するために、Visa、Master Card、American Expressなどのクレジット・カード会社には、クレジット・カード番号に加えてセキュリティ・コード番号を付加することが求められています。このコード番号は、VisaではCVV2（カード検証値）、MasterCardではCVC2（カード検証コード）、American ExpressではCID（カード識別番号）と呼ばれます。このコード番号は3桁または4桁で、カードの裏面に印刷されています。

クレジット・カード会社はこの検証コードを使用して、インターネットを介した取引など顧客のカードが手元にない状況で取引を処理する業者に対して、強化されたセキュリティを提供します。このコードを使用して、顧客が本物のクレジット・カードを所有し、そのアカウント番号が正当であることを確認します。セキュリティ・コードは、カードの磁気テープにはエンコードされておらず、領収書には印刷されません。

「受注」ウィンドウのクレジット・カードの「セキュリティ・コード」フィールドに入力されたクレジット・カード番号とともに検証されたセキュリティ・コードを入力できます。「セキュリティ・コード」フィールドはフォルダ対応で、その値はOracle Paymentsで検証されます。

本文の説明内容に関するイメージ

クレジット・カードの承認失敗が発生すると（セキュリティ・コードまたはクレジット・カード番号が検証不可）、受注は保留になります。さらに、カードがリスク検証に失敗すると、Order Managementは受注を保留にします。Risk Managementを使用すると、任意の数のリスク・ファクタを定義して、セキュアなオンライン環境で、顧客のIDの検証、信用評価の査定、およびリスクの管理ができます。

Oracle Paymentsで必須フィールドとして設定されたクレジット・カード・セキュリティ・コードを使用する際は、次の点を考慮してください。

クレジット・カード暗号化およびクレジット・カード・セキュリティ・コードの詳細は、『Oracle Order Managementインプリメンテーション・マニュアル』の「支払」の章を参照してください。

一部期間収益認識

厳密な会計標準に従って、収益管理では、日次収益、一部期間収益など、詳細なレベルで収益を計上する必要があります。一部期間収益認識機能によって、一部期間または日次レートの収益を正確に認識できます。この機能は売掛管理モジュールで起動しますが、Order ManagementおよびOracle Service Contractsではレート計算用に使用できます（サービス品目のみ）。販売したサービスの収益は、サービス期間（サービス開始日からサービス終了日までの間）にわたって正確に配分する必要があります。

カレンダ月は標準の月定義で、指定された日数（たとえば、1月1日から1月31日）で構成されます。1年は標準の12か月です。

サービス・カレンダ月は、ユーザーが契約に署名した日に基づいて開始されます。したがって、2004年2月23日に契約に署名した場合、サービス月は2004年2月23日から2004年3月23日と定義されます。顧客が2004年2月23日から2004年3月23日を1か月とみなす場合、一部期間収益認識ルールを使用しないでください。

この例では、顧客が、Receivablesで請求されるサービス明細に対して一部期間収益認識ルールを使用しない場合、Receivablesでは2004年2月23日（基準開始日）に1か月分の収益を認識します。

使用可能な会計基準タイプは次のとおりです。

タイプ 説明
固定予定 全期間の期間およびパーセントが固定されています。
変動予定 第1期間はオプションで固定され、残りの期間は按分されます。
日次収益率、全期間 全期間が日次収益率を使用します。
日次収益率、一部期間 一部期間が日次収益率を使用します。全期間は按分されます。

次の各例では、一部期間または日次レートの計算方法について説明します。

固定予定

この例では、収益は日次レートに基づいて計算されません。収益は、指定された期間にわたって均等に配分されます。

「固定予定」会計タイプで、GLカレンダを使用し、期間は6か月です。

各期間の収益= $600/6 = $100。収益予定は次のとおりです。

GL記帳日 期間 金額
4月17日 4月分 100
5月17日 5月分 100
6月17日 6月分 100
7月17日 7月分 100
8月17日 8月分 100
9月17日 9月分 100
  6か月分 600

変動予定

GL記帳日 期間 金額
4月17日 4月分 85.71
5月17日 5月分 85.71
6月17日 6月分 85.71
7月17日 7月分 85.71
8月17日 8月分 85.71
9月17日 9月分 85.71
10月17日 10月分 85.71
  6か月分 600

日次収益率 - 全期間

このオプションを使用すると、収益は日次収益率に基づいて計算されます。呼出し側アプリケーションであるOrder ManagementおよびOracle Service Contractsは、ルール開始日と期間数、またはルール開始日とルール終了日のいずれかにインタフェースする必要があります。

一部期間および全期間は、期間の日数に基づきます。

収益予定は次のとおりです。

GL記帳日 期間 金額 日数
4月17日 4月分 45.92 14
5月17日 5月分 101.68 31
6月17日 6月分 98.40 30
7月17日 7月分 101.68 31
8月17日 8月分 101.68 31
9月17日 9月分 98.40 30
10月16日 10月分 52.24 31
  7か月分 600 183

日次収益率 - 一部期間

期間内の日数に基づいて一部期間が按分されます。全期間に収益が均等に配分されます。

収益予定は次のとおりです。

GL記帳日 期間 金額 日数
4月17日 4月分 45.92 14
5月17日 5月分 100.32 31
6月17日 6月分 100.32 30
7月17日 7月分 100.32 31
8月17日 8月分 100.32 31
9月17日 9月分 100.32 30
10月16日 10月分 52.48 16
  7か月分 600 183

一部期間収益認識で使用するウィンドウ

「売掛管理」ウィンドウの「会計基準」で、「ルール・タイプ」、「期間」、「期間数」などの属性を指定して会計基準を設定できます。

本文の説明内容に関するイメージ

「受注」ウィンドウで「ヘッダー」 > 「その他」を選択すると「会計基準」フィールドが表示され、「売掛管理」の「会計基準」ウィンドウの値が値リストに表示されます。

本文の説明内容に関するイメージ

目次   |   前へ   |   先頭へ   |   次へ

Oracleロゴ
Copyright © 2002, 2010, Oracle and/or its affiliates. All rights reserved.