Oracle Order Managementユーザーズ・ガイド リリース12.1 B62702-01

目次

前へ

次へ

受注管理処理

この章では、次のトピックについて説明します。

• 明細（出荷/到着）セット
• 到着セット
• 出荷セット
• 出荷予定
• 明細分割時の出荷間の情報保持
• 明細分割で発生した出荷間の共通属性
• 履行セット
• 待機を伴う履行
• 各明細に対する出荷セット
• 各明細の出荷セットの主な機能
• ユーザー・プロシージャ
• 記帳済受注のプロジェクト・タスク変更の概要
• 記帳済受注のプロジェクト・タスク変更の主な機能
• ユーザー・プロシージャ
• シード・データの変更
• 最終顧客
• 最終顧客の主な機能
• ユーザー・プロシージャ
• 営業文書のプレビューおよび印刷
• プレビューおよび印刷の主な機能
• 文書の書式設定
• セキュリティ
• ユーザー・プロシージャ
• 統合
• シード・データ
• 直接出荷の概要
• 元帳間の直接出荷および変更管理の概要
• 元帳間の直接出荷の主な機能
• ユーザー・プロシージャ
• シード・データ: 制約
• 直接出荷処理
• 直接出荷受注の変更管理
• 購買リリース
• 受注明細のサービス情報の定義
• サービス終了の概要
• サービス終了の主な機能
• ユーザー・プロシージャ
• 受注明細のプロジェクト製造情報の定義
• 受注明細のリリース管理情報の定義
• 受注入力の必須フィールド
• 「受注」ウィンドウの「明細」タブでの受注明細のソート
• 受注の記帳
• 例外管理
• 営業グループ別計画営業収益レポート
• ユーザー・プロシージャ

明細（出荷/到着）セット

Order Managementでは、共通受注明細属性に基づいて明細セットを作成し、運用することが可能です。出荷セットでは、出荷確認の時点で、その全明細が個別にではなく一括してピックされ、出荷されます。Oracle Order Managementでは、出荷のセット作成という概念を発展させ、出荷、到着および履行に基づく新たなセット機能を追加しました。一般に、受注明細をセットとしてグループ化することにより、次のことが可能になります。

• 出荷コストの削減を容易にします。

• 受注ソースとは関わりなく、相互に合意された日付に、指定された顧客に受注全数量を搬送できるようにします。

• モデルとキットを分割ではなく、必ず一括して出荷することを指定します。

• 複数の機能を個別ではなく一括して実行することを可能にします。たとえば、商品やサービスは、すべての明細が履行されるまでは請求しない、などの処理を可能にします。これは、セットに属するすべての明細が特定のアクティビティを完了してから、該当するプロセス・フローの次のアクティビティに進むことを確認することにより実現されます。

• 分割出荷（バックオーダー明細）明細を新規または既存の出荷セットに追加します。

セットの受注/明細属性の識別

セット定義は、受注明細属性に基づいて作成されます。このセット定義により、Order Managementにおける、セットの整合性維持が可能になります。

セット固有の受注/明細属性の識別の詳細は、次の項目を参照してください。

到着セット

履行セット

出荷セット

セットのヘッダー・レベルのデフォルトを有効にすると、受注明細を到着セットまたは出荷セットのいずれかに自動的に追加できます。セット（到着セットまたは出荷セットのみ）に対する受注明細のヘッダー・レベルのデフォルトを顧客サイトで自動的に有効にするには、「標準-顧客」ウィンドウの「受注管理」タブで適切なチェック・ボックス（「到着セット」または「出荷セット」）を選択します。

注意: デフォルト・ルールを作成する場合、受注ヘッダー・エンティティを使用してセット詳細の値をデフォルト設定することはできません。このような機能はサポートされていません。

セット機能

「受注明細」ウィンドウ内で次の3つの方法のいずれかを選択することにより、セットに受注明細を定義、追加または移動できます。

• マウスの右クリックにより、「セット」を選択してから、該当する機能を選択します。

• 「出荷」タブの該当する「セット名」フィールドにデータを入力するか、データを選択するか、データをクリアします。ただし、「履行セット」フィールドは例外です。

  注意: 履行セットの定義には、マウスの右クリックを使用する必要があります。新規履行セットは、「履行セット」フィールドに一意の値を入力することによっては定義できません。

  現在の受注に対応する適切なセット定義が存在しないために実行中の機能が完了できない場合には、新規セットを入力するための「新規セット」ポップアップ・ウィンドウが表示されます。

  たとえば、到着セットの既存の受注明細を、出荷セットに移動しようとしたときに、現在の受注に該当する出荷セット定義が存在しない場合がこの例に該当します。この場合、「新規セット」ポップアップ・ウィンドウが表示され、セット追加機能が実行されます。セット名を入力し、「OK」ボタンをクリックすると、受注明細が作成され、新規セットに追加されます。「取消」ボタンをクリックすれば、新規セットの作成が取り消されます。

セット・ステータス

受注管理セットは「有効」と「クローズ」のいずれかに設定されます。

• セットは、その中の1つまたは全部の明細が出荷されるまで「有効」です。

• セットは、その中の1つまたは全部の受注明細が出荷または履行された場合、あるいは到着日に応じて「クローズ」となります（セット定義によります）。

セット内の1つの受注明細が出荷されると、残りの明細が出荷されない場合には、残りの明細はセット定義から削除され、セットはクローズされます。

クローズされたセットに受注明細を追加したり、そこから受注明細を削除することはできません。

セット機能の詳細

新規セットを定義すると、現在の受注明細識別属性に基づいたセット定義が作成されます。

セット固有の識別受注/明細属性の詳細は、次の項目を参照してください。

到着セット

履行セット

出荷セット

• 1つの受注明細は1つのセットに入れることも複数のセットに入れることもできます。また、1つの受注に属する別のセット・タイプと部分的または完全に重なっても差し支えありません。たとえば、1つの出荷先事業所に対応するすべての受注明細を1つの到着セットに入れ、この到着セットに所属する一部の明細のみを履行セットに入れる、などの運用が可能です。

• セットは複数の受注にわたることはできません。セットはその作成対象となった受注に限定されます。ただし、複数の組織にわたるセットは可能です。また、システム制御のセットとユーザー制御のセットがあります。

  • システム定義のセット（システム組込みセット）は、受注明細が保管されたとき、一定の条件で自動的に作成されます。このセットはシステム制御であり、システム定義のセットに格納されたセット・データを更新することはできません。システム制御のセットは、ATO構成および出荷モデル完了PTO構成を対象としている受注明細に対して、自動的に作成されます。

  • ユーザー定義のセットは、新規セットを定義するユーザーからの要求の結果として作成されます。

• 出荷できない受注明細に対して、セット機能は使用できません。

• どのセット機能を実行しても、選択された明細に対して、受注明細予定作成が必ず実行されます。この明細がセットの一部である場合には、セットに所属するすべての明細に対して、予定作成が実行されます。

  受注明細の更新が正常に終了すると、更新はコミットされ、「受注明細」ウィンドウの「出荷」タブに表示されます。

  更新が失敗すると、該当するエラー・メッセージが表示され、更新は無効となります。たとえば、受注明細を到着セットABCから到着セットCDFに移動しようとした場合、セットABCの到着予定日がCDFの到着予定日より前であると、挿入に失敗することがあります。

• 最遅許容日が無制限供給タイム・フェンスを超えていない場合、予定作成の自由度の範囲で最遅許容日の選択オプションに応じて、受注明細の予定作成が実行されます。

• 新規セットの定義を除いて、いずれかのセット機能を実行すると、Order Managementは次の2つの条件を強制します。

  1. 選択されたセットが「有効」であること。

  2. セット機能の実行対象として選択した受注明細が、選択されたセットの識別属性を継承できること。

     注意: 新規セットの定義の場合、Order Managementは、入力された受注明細属性または既存のセット機能からデフォルトとして決定される受注明細属性を検証します。

     注意: たとえば、受注明細の到着日と予定出荷日を入力し、新規到着セットを定義しようとすると、受注明細予定作成が実行されます。「予定到着日」に入力した値が予定作成エラーのために不適合となると、その受注明細に対して新規到着セットを定義する要求はエラーとなります。

• 受注明細をセットから移動または削除した場合、その受注明細がセット定義の唯一の受注明細であっても、セット定義は削除されません。セットの定義は、受注がクローズされないかぎり、セット定義内に受注明細を追加/作成するために使用できます。

  注意: セットから受注明細を移動または削除する場合、Order Managementは、そのセットの中で移動/削除対象の明細の完了を待機している可能性のある受注明細に関連する待機ワークフロー・アクティビティを自動的に更新します。

• 「予定出荷日」と「予定到着日」のフィールドに現在表示されているデータは、セットから受注明細を削除するときに更新されません。これらのフィールドのデータを更新するには、予定解除機能の実行が必要です。

  注意: セットの一部である受注明細の予定は解除できません。セット内の受注明細の予定を解除するには、セットから明細を削除してから明細の予定を解除する必要があります。

• ATO構成モデルと出荷モデル完了PTOモデルは必ずシステム定義セットに格納されます。どちらかのモデルがユーザー定義セットに格納されると、モデル明細とすべてのオプション明細がどちらも自動的にユーザー定義セットの定義に組み込まれます。ただし、検証の合格が前提です。

  モデルまたは親品目をセットから削除すると、すべてのオプション明細が自動的にそのセットから削除されます。モデルに対するすべてのセット操作は、その親品目で実行します。

• Order Managementには、セットに対して機能を制限するための検証機能が用意されています。セットが定義された後、セット内のいずれかの明細が出荷された場合、そのセット定義はクローズ済とみなされるため、変更はできません。

• セットの中で1つの受注明細に対応してセット属性が変化すると、その属性がセット内のすべての受注明細にカスケードされます。この結果、セット定義が更新されます。

• グループ予定作成は単位取引です。セット内の全受注明細が予定作成に成功すると、セットに追加されます。

明細分割

元の受注明細が出荷セット内にある場合に、分割出荷の結果として受注明細が新たに生成されると、生成された新規受注明細（および出荷セット内の出荷されていない既存の明細）が出荷セットから削除されます。

• 出荷セットに1つの明細があり、その一部が出荷されると、分割出荷の結果として新規明細が作成されますが、出荷セットには関連付けられません。

• 出荷セットに2つの明細があり、1つが完全に出荷されると、2番目の明細は削除され、その出荷セットから除外されます。

セットの識別属性値のカスケード

ユーザーが選択したセット機能によりデータのカスケードが保証されている場合、Order Managementは、セット識別属性をセット内のすべての受注明細にカスケードします。

• セット機能の実行時では、セット識別属性のみがカスケードされます。（出荷セットと到着セットのみ）

• セット機能内部で実行されるカスケードは下方向限定です（出荷セットと到着セットのみ）。

• システム定義セットがユーザー定義セットの一部でもある場合、ユーザーセットに加えられた変更はすべてシステム定義セットにカスケードされます。

予定作成と出荷セット

Order Managementの出荷セットでは、出荷セット内の受注明細の予定作成は、受注明細のコミット（保存）後に実行されます。

Order Managementセット機能用のユーザー・プロシージャ

マウスの右クリックを使用してセット機能を実行する手順は、次のとおりです。

注意: セット機能を実行すると、要求されたセット機能が完了した後、カーソルは最初の受注明細に戻ります。

注意: たとえば、1つの受注から受注明細4から6までを複数選択し、到着セットに追加する処理を考えます。受注明細を選択し、到着セット名を入力すると、カーソルは受注明細1に戻ります。

1. 「受注明細」ウィンドウで、既存の受注明細の上にカーソルを置き、マウスを右クリックしてから、「セット」を選択し、次に表示されるサブメニューから適切な機能を選択します。

2. 実行中の機能に対応して表示される値リストから適切なセット名を選択します。

   注意: 受注明細は、セットから定義、移動または削除できます。このためには、「受注明細」ウィンドウの「出荷」タブの該当する「セット名」および「日付」フィールドで値の入力、更新または削除を実行します。

   注意: この方法は、「履行セット」フィールド以外のすべてのセット・フィールドについて該当します。「履行セット」フィールドは入力も更新もできません。履行セット機能を実行するには、マウスの右クリックを使用する必要があります。

   明細セットは明細をグループ化する場合に使用します。出荷セットおよび到着セットは、それぞれ予定出荷日、予定到着日というように、類似の日付を基準としています。出荷セットはピック・リリースの時点で実行されます。出荷確認時に警告メッセージを発する出荷セットを割り当てることができます。このように指定すれば、割り当てられたすべての明細の準備が整わないかぎり、出荷セットは処理されません。1つの明細は、同時に出荷セットと到着セットの両方に割り当てることができます。

   定義上、出荷セットは次の3つの属性によって指定されます。

   倉庫

   出荷先

   予定出荷日

   出荷セット定義には、オプション属性「出荷方法」を追加できます。その制御は、プロファイル・オプション「OM: 出荷セットに対する出荷方法の強制」をします。値を「Yes」に設定すると、出荷セットの定義に「出荷方法」が追加されます。デフォルト値は「No」です。

   注意: ヘッダー・レベルの明細セットのデフォルト値には、「出荷先」、「請求先」、「売却先」のいずれか3つの場所を選択できます。

   最新のOracle Order Managementでは、ユーザー側で出荷、到着および履行の各セットに明細を追加できます。ヘッダー・レベルで、ユーザーの介入なしに出荷セットまたは到着セットに明細を追加できます。明細レベルで明細を明細セットに追加するには、手動で明細のセット名を指定します。明細セットへの明細の追加または削除は、メニューから操作できます。

明細レベルの出荷/到着セット

履行セットを使用すると、1受注につき1通の請求書を作成できます。到着セットを使用すると、出荷方法の異なる明細の予定到着日を調整できます。出荷セットでは、選択した受注明細の予定出荷日が同一になります。

受注取引タイプによる「明細セット」フィールドのデフォルト設定

• 受注取引タイプによって、出荷セット、到着セットおよび履行セットのデフォルト・ルールが有効になるかどうかが決まります。

• 各明細セットのステータスは、既存のセットに明細が追加できなくなる時点を決定します。

  • 出荷セット: ステータスがクローズ（出荷確認アクティビティ後）。出荷パラメータが出荷セットを強制するように設定されていると、ステータスがクローズになります（ピック・アクティビティ後）。

受注インポートまたは受注処理APIを介して設定された明細の追加または削除

受注インポートおよび受注処理APIは、履行セットからの明細の削除と、履行セットに対する追加と削除の同時実行をサポートしています。

• 明細セットが次のような場合は、追加も削除もできません。

  • 出荷セット: ステータスがクローズ（出荷確認アクティビティ後）。出荷パラメータが出荷セットを強制するように設定されていると、ステータスがクローズになります（ピック・アクティビティ後）。

  • 到着セット: ステータスがクローズ

ヘッダーでの出荷/到着セットの名称指定

システムによって生成された出荷/到着セットには、ヘッダー上に名称を指定できます。この名称は受注明細にカスケードされます。名称を指定しない場合は、システムによって受注明細にセット番号が移入されます。

到着セット

到着セットにより、セット定義で設定されたすべての受注明細の顧客サイトへの到着予定が、出荷方法や出荷先事業所とは関わりなく、確実に同じ日となります。到着セットでは次のことが可能です。

• 複数の組織にわたること。ただし、受注は、セットの作成対象となった受注に限定されます。

• 異なる倉庫からの出荷および異なる日の出荷。

到着セット内のすべての受注明細は、次の受注/明細識別属性値が同一であることが必要です。

• 受注明細の予定到着日

• 受注明細の出荷先組織

既存の到着セットに新しい受注明細を追加するときには、前述の条件を満たすことが必要で、満たさないと要求は失敗します。たとえば、到着セットに明細を挿入する要求を発行すると、到着予定日が、セット内の既存の明細から継承されます。最初に、セットのすべての既存の明細上の到着予定日を更新しないと、明細をセット定義に追加できません。

到着セット内のいずれかの受注明細に対して明細予定作成またはATPチェック機能を実行すると、この機能はセット内のすべての受注明細をその対象とします。

受注明細に対して到着セット機能を実行するには、「Order Managementセット機能用のユーザー・プロシージャ」を参照してください。

出荷セット

概要

出荷セットを使用すると、受注明細を出荷ごとにまとめてグループ化できます。関連項目: 各明細に対する出荷セット

出荷セットの使用により、出荷セットに所属するすべての明細の数量が出荷可能になるまで、どの受注明細も該当する明細フロー内の出荷ワークフロー・サブプロセスを超えて進まないことが保証されます。出荷セットの適用は、受注/明細を識別する次の属性が同じ値を持つ受注明細に限定されます。

• 出荷元組織と出荷先組織（どちらのフィールドもNULL値は無効です）

• 予定出荷日

出荷セット詳細

1つの受注明細に複数の搬送明細を割り当てることが可能ですが、1つの出荷セットに属するため、Oracle Shipping Executionは、出荷セット処理を1つの出荷セット定義に関連付けられている受注明細のグループ化に限定し、その出荷セット定義に関連付けられている受注明細について生成または作成された搬送明細のグループ化には適用しません。

「出荷パラメータ」ウィンドウの「ピック・リリース」タブにある「出荷セットおよび出荷モデルの強制」チェック・ボックスを選択しなかった場合、ユーザーはOracle Shipping Executionを使用することにより、ピック・リリース時に出荷セット機能を上書きできます。

• 「出荷セットおよび出荷モデルの強制」チェック・ボックスを選択していなければ、たとえ出荷セットが受注明細に指定されていても、ピッキング中(出荷確認中)に出荷セットおよび出荷モデル用の搬送明細が検証されることはありません。

  注意: 業務上の条件によっては、倉庫ごとに「出荷セットおよび出荷モデルの強制」パラメータを設定することが必要です。

• 「出荷セットおよび出荷モデルの強制」チェック・ボックスを選択すると、出荷セットおよび出荷モデルに対応する搬送明細がピッキング中に検証されます。出荷セットに属するいずれかの明細がピッキングに使用可能でない場合は、警告メッセージが表示されます。ユーザーは、出荷セット機能を上書きして出荷可能な明細のみを処理するか、警告メッセージを受け入れて出荷セットに属するすべての明細がピッキング可能になるまで待機するか、のいずれかを選択できます。出荷セットに属するすべての受注明細は、ピック・リリース時に完全にリリースされるか、自動的にバックオーダー扱いとなります。どの部分も使用可能でない場合には、出荷セットに属するすべての明細がバックオーダーとなります。

  受注を作成するときには、バックオーダーとなった明細に対して出荷セットを保持するか、保持しないかを指定する必要があります。これは、Order Managementの「受注」ウィンドウで指定できます。

  注意: 取引可能でない搬送明細に対応する出荷セットは、出荷確認時に検証されます。ただし、ピック・リリース時には、取引可能でない搬送明細に対応する出荷セットは、品目が在庫からピックされていないため、検証はされません。

• 構成製品の受注明細を出荷セットとして定義すると、Order Managementは、明細がピック用にリリースされる前に各構成のすべての品目が使用可能になるまで待機します。

• 出荷セットに所属し、出荷中に処理されない明細は導出出荷セットに格納されます。Order Managementは、出荷セットに属するすべての明細を、明細が出荷適格か不適格かに関わりなく、Oracle Shipping Executionに渡します。出荷不適格な明細の場合、Order Managementは不適格の事由も渡します。

• Oracle Shipping Executionにより処理されない明細と出荷時に分割が必要な（分割処理のため）明細は、新しい出荷セットに格納されます。

• 出荷セットには、異なるリリース・ステータスの明細を追加できます。出荷セットに追加できる明細のリリース・ステータスは「ステージング」および「倉庫へのリリース」です。明細ステータスが「クローズ」の場合は、明細を出荷セットに追加できません。

出荷セットの分割

分割

出荷セットの一部である明細を分割した場合は、分割を通知するメッセージが表示されます。出荷確認プロセスが開始されると、分割された明細は元の出荷セットから除去され、どの出荷セットにも自動的に割り当てられません。

受注明細に対して出荷セット機能を実行する場合は、「明細（出荷/到着）セット」を参照してください。

受注明細の予定作成と出荷セット

受注明細を出荷セットに自動または手動でグループ化し、グループ化した受注明細のいずれかの最遅許容日が品目の無制限供給タイム・フェンスを超えている場合、その受注明細および出荷セットに属するすべての受注明細の予定は作成されません。

• 出荷セットの受注ヘッダーのデフォルト値が「出荷」に設定されていない場合（「顧客」ウィンドウの「受注管理」タブにある「明細セット」チェック・ボックスの値によって決まります）に、手動で受注明細を出荷セット内にグループ化すると、ATP設定に基づいて各出荷セットに属する全受注明細の予定作成が試みられます。なんらかの理由（品目設定が不完全であるなど）で出荷セットに属するいずれかの明細の予定が作成されなかった場合は、該当するエラー・メッセージが表示され、失敗した明細と同じ出荷セットに格納しようとしたすべての受注明細に対応する出荷セットは生成されません。

• 出荷セットの受注ヘッダーのデフォルト値が「出荷」に設定され、プロファイル・オプション「OM: 各明細に対する新規セットの割当」が「N」に設定されている場合は、設定に基づいて最早予定出荷日が自動的に決定され、全受注明細に共通の出荷セットが作成されます。なんらかの理由（品目設定が不完全であるなど）で自動設定ルーチンが失敗すると出荷セットは生成されないため、手動で受注明細を出荷セットに追加する必要があります。

• 出荷セットの受注ヘッダーのデフォルト値が「出荷」に設定され、プロファイル・オプション「OM: 各明細に対する新規セットの割当」が「Y」に設定されている場合は、Order Managementにより、設定に基づいて最早予定出荷日が自動的に決定され、各受注明細に固有の出荷セットが作成されます。なんらかの理由（品目設定が不完全であるなど）で自動設定ルーチンが失敗すると特定の受注明細には出荷セットが生成されないため、手動で受注明細を出荷セットに追加する必要があります。

Order Managementでは、コンカレント・プログラムを発行して、出荷セットに属する全明細の予定を再作成することもできます。このコンカレント・プログラムを使用して、リアルタイムの需要と供給に基づいて出荷セットを再作成し、現行の予定日より先に出荷できます。関連項目: 出荷セット、「出荷セットの予定再作成」コンカレント・プログラム

さらに、次の設定によって、出荷セットの作成を容易に管理できます。

• 最遅許容日を、最大のリード・タイムを持つ受注品目の無制限供給タイム・フェンスを超えるように設定する必要があります。

• Oracle Shipping Executionのパラメータを、出荷セットを強制するように設定する必要があります。

• 受注管理のプロファイル・オプション「OM: 自動プッシュ・グループ日」を「Yes」に設定する必要があります。

• 「自動予定作成」をオフにします。

たとえば、次の表内の供給詳細を使用する受注番号123の場合を考えてみます。

受注123の場合:

• 受注入力時に手動で明細に入力した出荷セットはありません。

• 保存時に、システムで出荷セット名の割当てと設定が行われます。

• ATPが適用可能な場合は、システムで全受注明細についてATP有効数量が調査され、出荷セット内の受注明細が最遅許容ATP日に予定されます。

• 予定作成が共通日に適合できない場合、その受注明細は保存されますが、予定は作成されず、出荷セットへの割当ても行われません（この状況は、最遅許容日が無制限供給タイム・フェンスを超えていない場合にのみ発生します）。

最初の保存が実行された後、受注123に対する予定作成の詳細は、次の表のようになります。

一度保存された受注に対して2つの明細を追加すると、出荷セットへの割当てと設定が実行されます。

ATP有効数量が再び検証され、受注明細のグループ全体が自動プッシュされ、出荷セット内の明細が最遅ATP日に予定されます。予定作成が共通日に適合できない場合、2つの新規明細は保存されますが、予定は作成されず、出荷セットへの割当ても行われません（最遅許容日が無限タイム・フェンスを超えている場合）。

次の表は、2つの受注明細が追加された後の予定作成の結果を示しています。

予定作成後、受注明細は単一の出荷セット（1）に属していますが、有効な予定日がプッシュされていません。品目Dが5月7日よりもかなり前に使用可能になれば、出荷を予定日まで待つ必要がなくなる可能性があります。この場合、現行の予定日を受け入れるか、または「出荷セットの予定再作成」コンカレント・プログラムを発行して、受注明細を最早制限供給日に予定しなおすことができます。

新しいコンカレント・プログラムは、次のパラメータを使用して、明細をピックする基準を導出します。

• 出荷セット名

• 受注番号（下限）

• 受注番号（上限）

• 現行日付からの日数（開始）

• 現行日付からの日数（終了）

品目Dが2001年12月10日に使用可能になる場合、「予定再作成」コンカレント・プログラム発行後の受注123のステータスは次のようになります（次の表4を参照）。コンカレント要求は、次のパラメータを使用して実行されたと仮定します。「受注番号:下限」は123、「受注番号:上限」は132、「予定出荷日」は2002年5月7日、「最小日数」は0、「最大日数」は0、「出荷セット名」は1。

関連項目

「出荷セットの予定再作成」コンカレント・プログラム

Order Managementのセット・タイプの機能と使用方法の詳細は、次の項目を参照してください。

到着セット

履行セット

出荷セット

出荷予定

顧客から長期間にわたって複数の出荷が必要な発注を受けた場合は、複数の受注明細を個別に入力するかわりに、受注明細を分割できます。

明細を複数の出荷に分割すると、「受注」ウィンドウの「明細品目」タブからこれらの出荷にアクセスできます。そして受注明細の変更と同じようにこれらの出荷を変更できます。

モデル明細を複数の出荷に分割した場合、Order Managementではモデルに属するものはすべて各出荷予定に複製されます。個々の出荷予定が出荷確認されるまでは、PTO構成を使用して、出荷予定に対するオプションを変更できます。たとえば、顧客から、今後6か月間、毎月100の構成を出荷する営業基本契約を受注したとします。3か月後、選択されたオプションの1つのサポートを中止した場合は、3か月分の出荷が未出荷のまま残ります。そこで、廃止されたオプションを削除して、未出荷の3か月分の出荷予定を更新できます。

複数の要求日に対して出荷を予定する場合、Order Managementは、出荷予定のリリースを自動的に管理します。Order Managementは、ピック・リリース基準と一致する出荷予定明細のみリリースします。たとえば、要求日が2000年5月31日と2000年10月31日の2つの出荷予定明細があり、要求日が2000年5月31日までの受注をリリースする場合、Order Managementは日付を自動的にチェックし、最初の出荷予定明細のみリリースします。

出荷予定のために出荷情報を定義する手順は、次のとおりです。

1. 「出荷」タブ・リージョンにナビゲートします。

2. 出荷予定の最終出荷先について所在地情報を入力します。

3. 受注明細の出荷優先度を選択します。

   注意: 出荷優先度によって、出荷を緊急度に応じて異なるカテゴリにグループ分けできます。また、出荷優先度はピック・リリースのパラメータとして使用できます。異なる出荷優先度は「受注管理クイックコード」ウィンドウで追加定義できます。

4. 運送業者を選択します。

   注意: 運送業者は、ピック・リリースのパラメータとして使用できます。

出荷予定のためにプロジェクト情報を定義する手順は、次のとおりです。

1. 「プロジェクト」タブ・リージョンにナビゲートします。

2. プロジェクト番号を選択します。

3. プロジェクト番号を選択した場合は、タスク番号を選択します。

出荷予定のためにリリース管理明細情報を変更または定義する手順は、次のとおりです。

警告: このリージョンにアクセスするには、Oracle Release Managementがインストールされている必要があります。

1. 「リリース管理」タブ・リージョンにナビゲートします。

2. 顧客製造オーダー番号を入力します。

3. 顧客生産ラインを入力します。

4. オプションの顧客モデル・シリアル番号を入力します。

5. 品目を搬送する顧客ドックを入力します。

6. 値リストから中間出荷先事業所を選択します。

7. 計画生産順序番号を入力します。

8. 産業情報付加フレックスフィールドにナビゲートします。

9. 「追加産業属性」ウィンドウが表示されます。

10. 作業内容を保存します。

明細分割時の出荷間の情報保持

添付

ユーザーによる分割の場合 - 明細を分割すると、手動添付のみが複製されます。

システムによる分割の場合 - 手動添付および自動添付がともに複製されます。

値引/追加料金/運送費

追加料金と運送費は、調整として同じ方法で処理されます。

保留

明細の分割時、未リリースの保留は複製されます。分割された新規明細の属性を変更すると、保留ソースのアプリケーション・ルールが再評価されます。

販売実績

明細の分割時に、明細レベルの販売実績が複製されます。

ステータス情報

明細の分割時に、明細ワークフローのステータス情報が複製されます。分割された新規の明細は独自のフローを持ちます。新規の明細は、そのフロー内で分割元の明細と同じ段階に置かれます。

予約

予定作成属性が同じ場合は、明細の分割時に予約が分割されます。

税

明細の分割時に税が再評価されます。

明細分割で発生した出荷間の共通属性

Order Managementでは、明細を分割すると明細セットが作成されます。元の明細で作成されたすべての出荷は、同じ明細セットに属します。明細セットは、標準品目明細と構成およびキットの最上位レベル明細についてのみ作成されます。

Order Managementでは、明細セットのすべての出荷にわたって次の属性を共通にできます。

• 受注品目

• 単位

• 出荷許容量の超過および不足

構成に対するバックグラウンドでの明細の分割

「受注」ウィンドウで「分割構成」コンカレント要求を使用して、バックグラウンドで明細を分割できます。これはATOモデル、PTO構成およびキットに適用されます。「明細の分割」アクション・ウィンドウの「分割の遅延」ボックスでは、構成明細をバックグラウンドで分割し、受注に対して他の処理を継続できます。「分割の遅延」ボックスは、ATOモデル、PTO構成およびキットのみに有効です。「分割の遅延」ボックスを選択して「分割」をクリックすると、コンカレント・プログラム「分割構成」によって明細がバックグラウンド・プロセスとして分割されます。これによってパフォーマンスが改善され、「受注」ウィンドウでの作業を継続できます。明細分割の結果を確認するには、明細を再度問い合せる必要があります。

バックグラウンドでの分割の遅延

「分割構成」コンカレント・プログラムを取り消す場合、受注明細で「分割構成の取消」処理を使用します。明細分割処理は、このコンカレント・プログラムが実行中の場合にのみ取り消すことができます。特定の明細で「分割構成」コンカレント・プログラムが実行中の場合、その明細をさらに分割することはできません。分割すると、次のメッセージが表示されます。

&ID REQUEST_IDの有効な分割構成要求が存在します。明細をこの時点では分割できません

履行セット

バックグラウンド

Order Managementは、受注または受注明細の履行の確認に必要な機能を提供しています。履行の重要な特徴の1つは、受注明細が別個にではなく一緒に請求されることの確認です。

概要

履行セットは、共通の属性を持ち一緒に履行することが必要な受注明細のグループです。履行セットの一部である受注明細は、履行セット内のすべての明細がそれぞれの履行アクティビティを終了するまでは、そのフロー内の履行アクティビティを超えて進むことはできません。

Order Managementは「履行」ワークフロー・アクティビティを使用して、受注の履行を確認します。

シード済の受注管理ワークフロー・プロセスおよびアクティビティは、受注明細、直接出荷明細および返品明細のための基本機能を提供するために使用できます。この機能には、他のアクティビティを履行方法として定義できる融通性が備わっているため、独自の業務プロセスをモデル化できます。

重要な機能

受注または受注明細の履行は、多くの異なるイベントに基づいて判断されます。Order Managementの履行機能は、ワークフロー・アクティビティ「履行」により制御されます。

受注は、「履行」ワークフロー・アクティビティが正常に終了したときに、履行と判断されます。

注意: 履行セットに所属するすべての明細は、その受注明細フローに「履行」ワークフロー・アクティビティが設定されていることが必要です。

シード済の受注管理ワークフロー・プロセスには、履行方法アクティビティ（ワークフロー項目属性）とみなされる2つのアクティビティがあります。標準的な出荷可能明細の場合、履行方法アクティビティは出荷アクティビティです。返品明細の場合、履行方法アクティビティは受入アクティビティです。

ワークフロー・プロセスの中に任意のアクティビティを履行方法アクティビティとして定義できます。定義する各ワークフローの中で、こうして定義された履行アクティビティは「履行」ワークフロー・アクティビティに先行していることが必要です。

明細ワークフローが履行アクティビティに達すると、履行方法アクティビティ（出荷または受入）が正常に完了したか確認する処理が呼び出されます。確認されると、明細上の履行済数量が、出荷済、受注済または受入済数量に更新され、履行フラグが「Yes」に設定されます。さらにワークフローでは、この明細が履行セットの一部であるかどうかの確認が実行されます。

• 明細が履行セットの一部でない場合には、これで履行アクティビティが終了し、ワークフロー・プロセスの次のアクティビティに進みます。

• 明細が履行セットの一部の場合は、履行セット内の他の明細が履行済かどうか確認されます。

  • 履行済でない明細が存在する場合は、履行済が確認された受注明細は履行アクティビティで待機します。

  • すべての明細が履行済となった時点で、履行セット内のすべての明細について、履行アクティビティが完了したことになります。

履行セット詳細

• 履行セットから明細を削除できます。ただし、履行済となった明細は、履行セットに追加したり、履行セットから削除したりできません。

• 履行セットの中の既存の受注明細のいずれかが履行された場合、明細をこの履行セットに追加することはできません。

• 1つの受注に対して2つの履行セットがあり、これらの履行セットに共通の明細が存在する場合、すべての明細が履行されるまで、一部の明細が履行を超えて進むことはありません。たとえば、履行セットF1に明細1、2、3があり、履行セットF2に明細3、4、5がある場合、明細1から5がすべて履行されるまで、どの明細も履行を超えて進むことはありません。

• ある明細が履行セットの一部であり、ある受注明細のプロセス・フローに「履行」アクティビティが存在する場合、構成のどの明細も、履行セットのすべての明細が履行されるまで、履行アクティビティを超えて進むことはありません。

  注意: 履行セットでは分割履行がサポートされていません。履行セットの一部である受注明細の分割履行が発生すると、分割明細も元の明細と同じ履行セットに格納されます。新たに作成された明細が履行されるまで、履行セットは履行済になりません。

• 単一の受注に複数の履行セットを持たせることができます。明細が2つの履行セットのメンバーである場合、明細のどれかの履行アクティビティを完了するには両方の履行セットの全明細を履行する必要があります。

• 通知を伴う受注明細ワークフロー・プロセスが履行セットにあり、通知が拒否された場合、このセット内の他の明細は、それぞれのフローを進むことができなくなります。再承認プロセスが受注明細フローに組み込まれていないかぎり、拒否された明細を手動で削除するか、取り消すことが必要です。この場合、通知を再承認するか、拒否された明細の削除または取消を実行してください。

• 履行セットに明細が割り当てられていない場合、または割り当てられた明細が削除されている場合、その履行セットは自動的にクローズされます。

受注明細に対して履行セット機能を実行するには、「Order Managementセット機能用のユーザー・プロシージャ」を参照してください。

1つの履行セットへの受注の全明細の自動割当て

受注の全明細の請求処理を同時に実行できます。そのための方法の1つが、履行セットを使用することです。受注の明細ごとに履行セット名を入力するかわりに、受注の全明細を履行セットに自動的に割り当てることができます。この割当ては、顧客、出荷先、請求先および受注取引タイプに基づくデフォルト・ルールを使用し、受注レベルで制御できます。ヘッダー・レベルのデフォルトにより明細レベルに値が移入されます。

• 既存の受注に明細が追加されると、その明細にはデフォルトの履行セット値が移入されます。ただし、既存の履行セットのステータスが「クローズ」の場合、既存の受注に追加されたすべての新規明細は、履行セットに割り当てられません。

  • 履行セットが「クローズ」ステータスのため、既存の履行セットに明細を追加できないことを示すエラー・メッセージが戻されます。

• デフォルトの履行セット値は、手動で上書きできます。

  注意: 履行セットに追加されたサービス明細は、親明細の後に履行されます。

  • 到着セット: ステータス「クローズ」

  • 履行セット: ステータス「クローズ」（「履行」アクティビティの後）

• 取引タイプを定義して、特定の取引タイプに自動的に設定される履行に明細を追加するかどうかを決定できます。

  • 明細は複数の履行セットに追加できます。

• デフォルトの明細セット（「出荷」または「到着」）は、特定の取引タイプに自動的にデフォルト設定されます。

  受注インポートまたは受注処理APIを介して設定された明細の追加または削除

受注インポートおよび受注処理APIは、履行セットからの明細の削除と、履行セットに対する追加と削除の同時実行をサポートしています。

履行セット: ステータスがクローズ（履行アクティビティ後）の履行セットについてヘッダーに指定する名称

ヘッダー上でシステム生成履行セットの名称を指定できます。この名称は受注明細にカスケードします。名称を指定しない場合は、受注明細に設定番号が移入されます。

関連明細がすでに履行セットに含まれている場合は、ヘッダー・レベルで履行セットを選択すると、その履行セットに受注ベースのサービス明細が追加されます。この明細は、親明細の後にのみ履行されます。

ユーザー・プロシージャ

Oracle Order Managementでは、ヘッダー・レベルでの出荷セットおよび到着セットの選択機能が拡張されました。「OM: 各明細に対する新規セットの割当」プロファイルには、次の2つのオプションがあります。

多くの企業では、単一の受注に対して複数の出荷を作成することは望ましいことではありません。このプロファイルでは、1つの受注に対して1つの出荷セット/到着セットを作成する設定がNにデフォルト設定されています。たとえば、ヘッダー・レベルの選択が「出荷」で、すべての明細の予定が正常に作成された場合、これらの予定作成済明細は自動的に1つの出荷セットに入ります。

また一方では、1つの受注につき1つの完成された明細出荷があり、それでいて複数の出荷を実行できることが重要となる企業もあります。その場合、明細の予定作成で、このプロファイルをYに設定することにより、1つの受注の各明細に対して固有の出荷セットまたは到着セットが作成されます。

待機を伴う履行

明細の履行ワークフロー

Order Managementでの明細の履行ワークフロー・アクティビティは、次のことを示しています。

1. 受注明細ワークフローで履行アクティビティとして使用する必要のあるワークフロー・アクティビティ

2. 履行アクティビティに必要な完了結果

   Order Managementの明細の履行ワークフロー・アクティビティでは、この明細の履行アクティビティが必要な結果（出荷確認）で完了するかどうかが確認されます。必要な結果で完了した場合は、明細の履行アクティビティが完了し、受注明細は履行済としてマークされます。

出荷可能明細の履行と出荷不可明細の履行

通常、*出荷可能明細には履行アクティビティとして「出荷明細」ワークフロー・アクティビティ、完了結果として出荷確認が使用されます。

注意: *出荷可能明細の履行アクティビティは、「出荷明細」でなくてもかまいません。

これに対して、出荷不可明細（請求のみワークフロー、サービスなどの明細）には、明確な履行アクティビティはありません。この種の明細の履行は、通常、受注に含まれる他の一部の出荷可能明細の履行に依存するか、またはOrder Managementシステムの外部で処理されます。受注の記帳時には、出荷可能明細は「出荷明細」アクティビティで実際の出荷を待ってから、明細の履行アクティビティに移行します。ただし、出荷不可明細は即時に履行アクティビティに到達します。履行アクティビティがないため、明細の履行が完了します。**

注意: **唯一の例外は、明細が履行セットに含まれている場合です。

シード済のワークフロー・サブプロセス

一部の企業では、明細が実際に出荷確認された後も、出荷可能明細の履行を保留にしておく場合があります。そのため、既存の機能（履行の遅延または明細の履行）の前に、シード済ワークフロー・サブ・プロセス「明細の履行を待機」を追加できます。

明細の履行を待機ワークフロー

明細履行の待機をチェック

ワークフローの受注明細は、予定が作成され出荷されると、明細履行の待機をチェック機能に到達します（出荷可能明細の場合のみ）。

この機能は、デフォルトで次のいずれかの値を戻します。

1. No。すべての出荷可能明細、構成に含まれる全明細、同じ受注の出荷可能受注明細を参照しているサービス明細の場合です。この種の明細は、このサブプロセスを通過せずにワークフロー内で履行の遅延に進みます。履行機能には特殊な処理が用意されており、構成に含まれる出荷不可明細および同じ受注を参照するサービス明細が処理されます。この種の明細には、追加の待機は不要です。

2. Yes。ポイント1で説明したタイプの出荷不可明細を除く出荷不可受注明細の場合です。この場合、受注明細は「明細の履行 - 適格」ブロックで待機します。このブロックの完了はビジネス・プロセスによって決定されます。

   注意: サブプロセス「明細の履行を待機」はコピーできます。ビジネス要件に固有の遅延履行に適格な受注明細については値「Yes」を戻すように、コピーしたファンクションを処理するプロシージャを記述できます。

次のプロシージャが用意されています。

• OE_Fulfill_WF. Complete_Fulfill_Eligible_Block。このプロシージャは、Order Management外部のカスタム履行ソリューションからコールされるとブロックFulfill_Line_Eligibleを完了します。このプロシージャは、明細がビジネス・プロセスごとに履行される場合、および履行に進行させる場合に使用できます。

• また、「受注」ウィンドウで「処理」 > 「受注の進行」を使用して追加のブロック（待機）を完了することもできます。

  注意: Fulfill_Line_Eligibleブロックを完了するためのシード済コンカレント・プログラムはありません。これは、履行遅延に移行するかどうかを決定するイベントやプロセスの機能がビジネスごとに異なるためです。

各明細に対する出荷セット

Oracle Order Managementでは、ヘッダー・レベルの出荷/到着セット機能の顧客向け選択肢が増えています。プロファイル「OM: 各明細に対する新規セットの割当」には、2つの代替値が用意されています。

多くの企業は、1件の受注に対して複数の出荷を作成することを希望しません。デフォルトは「N」に設定されるため、受注ごとに1つの出荷/到着セットが作成されます。たとえば、ヘッダー・レベルで「出荷」を選択すると、正常に予定作成済の全明細は作成時に自動的に1つの出荷セットに送られます。

他の企業の場合は、受注当り1件の明細の出荷完了と複数の出荷が許可されていることが重要です。このプロファイルを「Y」に設定すると、明細が予定作成可能な場合は受注明細ごとに一意の出荷/到着セットが作成されます。

これにより、同じ出荷セットに割り当てられた全明細は、セット内の各明細の準備が完了するまで進行しません。履行セットにより明細はアクティビティ（「出荷」または「返品」）別にグループ化され、明細を請求処理にまとめて送ることができます。1つの明細を複数の履行セットに割り当てることができ、出荷または到着セットにも追加できます。

注意: 明細が1度に属すことができるのは、出荷セットまたは到着セットの一方のみです。

各明細の出荷セットの主な機能

• 到着セットは、様々な出荷方法がある明細の予定到着日を統合します。

• 出荷セットは、選択した受注明細に同じ予定出荷日があるかどうかを確認するために使用します。これにより、同じ出荷方法を持つ明細を容易に連結できます。

ヘッダー・レベルで「明細セット」フィールドを設定することにより、明細が出荷セットまたは到着セットのいずれに入るか選択できます。「出荷」を選択して、すべての明細の予定が正常に作成された場合、これらの予定作成済明細は自動的に1つの出荷セットに組み込まれます。同様に「到着」を選択して、すべての明細の予定が正常に作成された場合、これらの予定作成済明細は自動的に1つの到着セットに組み込まれます。

明細の予定が作成可能な場合、この機能により、各明細が新規のセット（「出荷」または「到着」）に組み込まれます。

1つの出荷セットにグループ化された明細には、同じ「予定出荷日」、「出荷元」および「出荷方法」が含まれます。これらのフィールドのいずれかを変更しようとした場合、その明細が出荷セットから除去されるまで、システムはこの変更を許可しません。「予定出荷日」、「出荷元」または「出荷先」の変更を進めると、システムから、明細を出荷セットから除去するというエラー・メッセージが表示されます。

エラー・メッセージ: 「予定出荷日」、「出荷元」、「出荷先」を変更すると、明細が出荷セットから削除されます。続行しますか?（Y/N）

複数の受注に同じ出荷セット名を使用できます。出荷セット名は各出荷セットに固有のship_set_idsにマップされます。

ユーザー・プロシージャ

Oracle Order Managementでは、ヘッダー・レベルでの出荷セットおよび到着セットの選択機能が拡張されました。「OM: 各明細に対する新規セットの割当」プロファイルには、次の2つのオプションがあります。

多くの企業では、単一の受注に対して複数の出荷を作成することは望ましいことではありません。このプロファイルでは、1つの受注に対して1つの出荷セット/到着セットを作成する設定がNにデフォルト設定されています。たとえば、ヘッダー・レベルの選択が「出荷」で、すべての明細の予定が正常に作成された場合、これらの予定作成済明細は自動的に1つの出荷セットに入ります。

また一方では、1つの受注につき1つの完成された明細出荷があり、それでいて複数の出荷を実行できることが重要となる企業もあります。その場合、明細の予定作成で、このプロファイルをYに設定することにより、1つの受注の各明細に対して固有の出荷セットまたは到着セットが作成されます。

1つの特定の取引タイプにデフォルトの明細セットを設定する手順は、次のとおりです。

1. 「取引タイプ」ウィンドウにナビゲートします。

2. デフォルト明細セットを「取引タイプ」が標準の到着セットとして設定します。

3. 作業内容を保存します。

4. 「受注」ウィンドウにナビゲートします。

5. 「取引タイプ」が標準で受注を作成します。「明細セット」は「到着」の値でデフォルト設定されます。

6. 受注に明細を追加します。

7. 「設定日」または「自動プッシュ・グループ日」プロファイルに基づいて明細の予定作成が可能な場合、すべての明細は自動的に到着セットに追加されます。セット全体が共通日を取得するためにプッシュされて、予定が再作成されます。

   デフォルト明細セットが出荷セットとして設定されている場合、すべての明細は自動的に出荷セットに追加されます。

8. 作業内容を保存します。

明細を履行セットに含めるための手順は、次のとおりです。

1. 「取引タイプ」ウィンドウにナビゲートします。

2. 「取引タイプ」が標準の「デフォルト履行セット」を「Yes」に設定します。

3. 作業内容を保存します。

4. 「受注」ウィンドウにナビゲートします。

5. 「取引タイプ」が標準で受注を作成します。デフォルトの「履行セット」は「Yes」の値でデフォルト設定されます。

6. 受注に明細を追加します。

7. 受注ヘッダーで指定された場合、すべての明細が履行セットに自動的に追加されるか、または履行セットが自動的にシステム生成されます。

出荷セットまたは到着セットをデフォルト設定するためのデフォルト・ルールを設定する手順は、次のとおりです。

1. 「デフォルト・ルール設定」ウィンドウにナビゲートします。

2. 顧客、出荷先、サイトなどのデフォルト・ルールを、受注明細セットがデフォルト設定されている順序で設定します。

3. 作業内容を保存します。

4. 「受注」ウィンドウにナビゲートします。

5. デフォルト・ルールによってデフォルト設定された「到着」または「出荷」の値をデフォルト値として持つ「顧客明細セット」の受注を作成します。

6. 「設定日」または「自動プッシュ・グループ日」プロファイルに基づいて明細の予定作成が可能な場合、すべての明細は自動的に出荷セットまたは到着セットに追加されます。セット全体が共通日を取得するためにプッシュされて、予定が再作成されます。

記帳済受注のプロジェクト・タスク変更の概要

Oracle Project Manufacturing機能を使用すると、組織において、資材と労務の計画、スケジューリング、処理および原価計算を特定の顧客契約に対して実行できます。Project Manufacturingの処理では、Oracle Order Managementなど、Oracle E-Business Suiteのほとんどの製品と連携します。Oracle Order Managementは、受注明細、出荷およびオプションのプロジェクト/タスク情報を、オンライン（「受注」ウィンドウを使用）とバッチ・モード（「受注インポート」コンカレント・プログラムを使用）の両方で取得します。また、管理品目のモデル/ユニット機能の終了品目ユニット番号も取得します。この情報は、Oracle Project Manufacturingとの統合に使用されます。

記帳後は、シード済制約により、プロジェクトおよびタスク番号を変更できませんが、この制約は削除できます。これにより、プロジェクト製造情報を使用する作業の柔軟性が向上します。追加のシード済システム制約（これは削除できません）によって、次のような状況における変更が禁止されます。

受注明細:

1. 出荷数量がNULLではない場合

2. 明細が請求にインタフェースされる場合

3. 品目がピック・リリースされている場合

4. 在庫インタフェース・ワークフロー・アクティビティが完了している場合

   このアクティビティは非出荷サイクルで使用されます。このアクティビティが完了することは、品目が搬送済であること（そのため、在庫を更新する必要があること）を意味します。この時点で、該当する明細のプロジェクト/タスクは更新できなくなります。

5. 購買リリース・ワークフロー・アクティビティが完了している場合

6. ATO品目が出荷通知されている場合

7. ATOモデルの構成明細が出荷通知されている場合

返品明細:

明細が記帳されている場合

プロジェクトは、倉庫や在庫組織に固有のものです。倉庫またはプロジェクトに対して、「倉庫/プロジェクト」組合せが無効になるような更新を加えると、エラー・メッセージが表示されます。明細にプロジェクトがある場合、倉庫は予定作成によって更新されません。値リストには、入力されたプロジェクトに対して有効な倉庫のみが表示されます。

記帳後に受注明細の予定が再作成されると、倉庫がGlobal Order Promisingに渡されます。Global Order Promisingでは、資材について、その倉庫内のみでの有効数量をチェックします。

分割明細の更新

いずれか1つの分割明細のプロジェクト/タスクを変更または更新して、その明細を保存しようとすると、すべての分割明細のプロジェクトとタスクを更新するよう要求するメッセージが表示されます。

プロジェクト/タスクを更新するには、各分割明細を手動で変更して保存するか、またはすべての分割明細を選択し、一括変更機能を使用してプロジェクト/タスクを更新します。

タスクの検証

受注明細に入力されたプロジェクトに対してOracle Project Manufacturingで設定されたタスクを指定できます。プロジェクト情報を変更すると、「タスク」フィールドが消去されます。最初に有効なプロジェクトが入力されていない場合は、タスクを指定できません。たとえば、プロジェクトP1に2つのタスクT1およびT2が関連付けられており、プロジェクトP2にタスクT3およびT4が関連付けられている場合、P1のエントリT1は有効です。ただし、プロジェクトをP2に変更すると、「タスク」フィールドが消去され、有効なタスク番号としてT3またはT4のみを指定できます。

ATOモデルまたはPTOモデル内のハイブリッドATOのすべてのオプションには、モデル明細で指定済のものと同じプロジェクトとタスクが指定されます。

記帳済受注のプロジェクト・タスク変更の主な機能

「受注」ウィンドウ

プロジェクトおよびタスクごとの受注と受注明細の検索

「受注」ウィンドウの「検索」ウィンドウを使用して、検索基準に指定されているプロジェクトおよびタスクの明細が1つ以上ある受注または受注明細を検索します。プロジェクトとタスクの番号は、Oracle Project Manufacturingがインストールされている場合にのみ、検索基準として使用できます。

受注明細へのプロジェクトとタスクの入力

「受注」ウィンドウまたは「受注の予定作成」ウィンドウを使用して、受注明細のプロジェクトとタスクの情報を入力します。この情報は、次の場合に入力できます。

• Project Manufacturing製品がサイトにインストールされている場合

  明細の「倉庫」が、Oracle Inventoryでプロジェクト対応として設定されている場合

プロジェクトとタスクの情報のデフォルト化

受注明細に指定されているプロジェクトとタスクは、そのすべての子出荷明細のデフォルトになります。受注明細がモデルである場合、プロジェクトとタスクはそのモデルに指定されているすべてのオプションのデフォルトになります。

プロジェクトとタスクの情報のカスケード

プロジェクトとタスクの情報は、更新されるとカスケードされます。この情報は、受注明細からモデル明細のすべてのオプションまで、すべての子出荷明細にカスケードされます。

モデル/ユニット番号有効性管理品目の最終品目ユニット番号の入力

「受注」ウィンドウまたは「受注の予定作成」ウィンドウを使用して、受注明細の最終品目ユニット番号を入力します。この情報は、次の場合に入力できます。

• Project Manufacturing製品がサイトにインストールされている場合

• 明細の「倉庫」が、Oracle Inventoryでプロジェクト対応として設定されている場合

• 品目がモデル/ユニット番号の有効性管理に属している場合

プロジェクトとタスクの情報の検証

プロジェクトとタスクの情報は、次のことに関して検証されます。

• 有効なプロジェクトとタスクのみが指定されること。

• 受注の顧客に関連付けられているプロジェクトのみが指定されること。この強制はオプションです。

• プロジェクトが指定されていない場合はタスクを指定できないこと。

• 明細「倉庫」のプロジェクト管理レベルが「タスク」に設定されており、受注明細にプロジェクトが指定されている場合、その受注が記帳される前にタスクも指定する必要があること。

• ATOモデルまたはPTOモデル内のハイブリッドATOのすべてのオプションには、モデル明細で指定済のものと同じプロジェクトとタスクが指定されること。

モデル/ユニット番号有効性管理品目の最終品目ユニット番号の検証

最終品目ユニット番号は次の場合に検証されます。

• 最終品目ユニット番号が表に対して検証されるとき

• 受注の記帳後に最終品目ユニット番号を変更できないとき

ユーザー・プロシージャ

プロジェクトとタスクに基づいて受注を問い合せる手順は、次のとおりです。

1. 「受注」ウィンドウにナビゲートし、「検索」アイコンを選択します。

2. 次の問合せ基準のすべてまたはいずれかを入力します。

   プロジェクト番号

   タスク番号

3. 「検索」をクリックします。

   「検索」ウィンドウ - 「明細情報」タブ

   

4. 入力した問合せ基準によって戻された受注が表示されます。

プロジェクト、タスクおよび最終品目ユニット番号を入力する手順は、次のとおりです。

1. 「受注」ウィンドウにナビゲートします。

2. 受注情報を入力し、「明細」タブを選択します。

3. 必要な明細情報をすべて入力し、「その他」タブを選択します。

4. プロジェクト、タスクおよび最終品目ユニット番号を入力します。

5. 作業内容を保存します。

プロジェクト、タスクおよび最終品目ユニット番号を更新する手順は、次のとおりです。

1. 「受注」ウィンドウにナビゲートします。

2. 更新する明細を問い合せます。

3. 「その他」タブを選択します。

   「受注」ウィンドウ - 「その他」タブ

   

4. 適切なフィールドを更新します。

5. 作業内容を保存します。

シード・データの変更

プロジェクトとタスクの制約

記帳後のプロジェクトとタスクの更新を許可しないシード済制約は、システムによってシードされたものではないため、インプリメンテーションに基づいて削除できます。

次の新しい条件はシード済システム制約であり、変更できません。

受注明細:

• 出荷数量がNULL以外の場合は、プロジェクトとタスクを更新できません。

• 明細が請求書インタフェース済の場合は、プロジェクトとタスクを更新できません。

• 品目がピック・リリース済の場合は、プロジェクトとタスクを更新できません。

• 在庫インタフェース・ワークフロー・アクティビティが完了している場合は、プロジェクトとタスクを更新できません。

• 購買リリース・ワークフロー・アクティビティが完了している場合は、プロジェクトとタスクを更新できません。

• ATO明細が出荷通知済の場合は、プロジェクトとタスクを更新できません。

• ATOモデルの構成明細が出荷通知済の場合は、プロジェクトとタスクを更新できません。

  返品明細:

• 明細が記帳済の場合は、プロジェクトとタスクを更新できません。

メッセージ

名称: OE_VAL_PROJECT_REQD

メッセージ: タスクが NULL でない場合には、プロジェクトは必要です。

目的: 検証目的。このメッセージは、タスクがあるがプロジェクトがない明細を作成すると表示されます。

名称: OE_VAL_PROJ_UPD

メッセージ: 区分/オプションがATOモデル内の場合、プロジェクトは更新できません。

目的: このメッセージは、ATOモデルに属する区分またはオプションでプロジェクトを更新すると表示されます。

名称: OE_VAL_TASK_REQD

メッセージ: 倉庫のプロジェクト管理がタスクに設定されました。 プロジェクト参照はプロジェクトおよびタスクで構成されなければなりません。

目的: このメッセージは、プロジェクトがNULLではなくタスクがNULLである場合に管理がタスクに設定されると、表示されます。

名称: OE_VAL_TASK_UPD

メッセージ: 区分/オプションがATOモデル内の場合、タスクは更新できません。

目的: このメッセージは、ATOモデルに属する区分またはオプションでタスクを更新すると表示されます。

最終顧客

この機能は、次の状況に対応します。

企業が、製品サポートの適格対象者、販売実績に適格対象者?、販売項目のユーザーなど、様々な理由から受注明細の最終顧客を知る必要がある場合。

注意: 販売先顧客/取引先は、品目のクレジット返品または修理返品ができます。

取引先受注処理を使用している場合、取引先は多数の最終顧客に販売するのが一般的です。1件の受注で販売を複数の最終顧客に連結できます。

受注時に最終顧客が指定されている場合、システムではOracle Install Baseに適切な最終顧客を自動的に移入し、Order ManagementとOracle Install Baseの統合を効率化できます。

ビジネスでOracle Service Contractsを使用している場合は、受注から1件のサービス契約を作成できます。この機能は、販売先顧客/取引先が複数の最終顧客に対するサービス契約を所有している場合に役立ちます（1件の受注で複数の最終顧客に対する複数のサービス契約を作成することはできません）。

この機能は、次の場合に適しています。

• 製品サポートにOracle Install Baseを使用している場合。

• サポート契約にOracle Service Contractsを使用している場合。

• 市場で使用されている販売チャネル、つまり、取引先の顧客と最終顧客を適切に把握する必要がある場合。

• 販売コミッションを取引先と最終顧客の間で分割する場合。

最終顧客の主な機能

受注ヘッダーまたは受注明細、あるいはその両方での最終顧客の指定

「受注」ウィンドウには、ヘッダー・レベルと明細レベルの両方にOracle Install Base内の最終顧客の属性を指定するための列があります。フラグを設定してOracle Install Base内の所有者、インストール場所および現行事業所を指定できます。

明細レベルの独立性

受注明細ごとに異なる最終顧客を指定できます。

基本契約を参照する受注での最終顧客サポート

営業基本契約または価格設定基本契約を参照する受注では、ヘッダーと明細の両方で最終顧客を指定できます。

最終顧客機能は、標準の「受注」ウィンドウと「クイック受注」ウィンドウの両方でサポートされています。

最終顧客機能は、標準の「受注オーガナイザ」と「クイック受注オーガナイザ」の両方でサポートされています。最終顧客での問合せと最終顧客の表示ができます。

取引先または最終顧客への出荷

最終顧客または取引先/販売先顧客に出荷できます。また、最終顧客に出荷する場合は、最終顧客パーティ名が荷受証に表示されます。

Oracle Install Baseへの適切な所有者のデフォルト設定

Oracle Install Baseに適切な所有者をデフォルト設定できます。所有者は、販売先顧客の場合や最終顧客の場合があります。

導入場所事業所/現行事業所の識別

現行事業所と導入場所事業所の両方を識別できます。最終顧客の事業所を、導入場所事業所または現行事業所として使用できます。

Oracle Install Baseへの現行事業所のデフォルト設定

Oracle Install Baseに現行事業所をデフォルト設定できます。現行事業所には、出荷先、最終顧客、搬送先、販売先または請求先（まれ）を指定できます。

Oracle Install Baseへの導入済事業所のデフォルト設定

Oracle Install Baseに導入済事業所をデフォルト設定できます。導入場所事業所には、出荷先、最終顧客、搬送先、販売先または請求先を指定できます。

Oracle Service Contractsでの顧客への販売先のデフォルト設定

Oracle Service Contractsに対して販売先顧客をデフォルト設定できます。

最終顧客に基づく販売実績分割のインポート

最終顧客が指定されている場合に、販売実績を分割できます。たとえば、最終顧客に関連付けられた営業担当に50%、販売先顧客に関連付けられた営業担当に50%を付与します。分割販売実績をiStoreからインポートするか、標準の「受注インポート」を使用できます。

最終顧客属性のインポート

標準の「受注インポート」では、最終顧客属性がサポートされています。現時点では、EDIおよびXMLはサポートされていません。

受注ごとにサービス契約を作成できます。ヘッダー上の販売先顧客（取引先）がOracle Serviceに渡され、1件のサービス契約を作成できます。

最終顧客、事業所および担当の意味は次のとおりです。

• 最終顧客: 受注上の商品の利益の最終的な受取者。

• 最終顧客事業所: 販売先、出荷先、搬送先または請求先のビジネス目的を持つ最終顧客のサイト。

• 最終顧客担当: 販売先、請求先、出荷先、搬送先のロールを持つか、またはまったくロールを持たない最終顧客の担当。

新規受注/明細属性: 「IB所有者」、「導入済事業所」および「現行事業所」

IB内の品目の所有者には、販売先顧客（取引先）または最終顧客を指定できます。Order Managementでの「IB_Owner」フラグの値は、次のいずれかに限定されます。

• 販売先顧客

• 最終顧客

「最終顧客事業所」には、次のいずれかのビジネス目的が使用可能です。

• 出荷先

• 搬送先

• 販売先

• 請求先

制約

明細がOracle Install Baseとインタフェースされた後は、IB所有者、現行事業所および導入済事業所の更新を禁止する制約があります。IB所有者、導入場所および現行事業所がOracle Install Baseに渡されます。

• 出荷可能品目の場合は、出荷後に属性が渡されます。

• 出荷不可品目の場合は、履行後に属性が渡されます。

最終顧客のアカウント自動作成

最終顧客のアカウントを自動的に作成し、見積などのアプリケーションで使用できます。

最終顧客属性の一括変更

最終顧客の属性には一括変更を使用できます。一般的なビジネスでの例では、1つの明細に複数の最終顧客が記載されている受注が考えられます。ある最終顧客には5つの明細、別の最終顧客には6つの明細、また別の最終顧客には4つの明細などを適用する可能性があります。一連の明細を複数選択して、最終顧客を変更したり、最終顧客の属性すべて（Installed Baseの最終顧客所在地、担当、所有者、現行事業所、導入場所事業所など）を一括変更できます。

最終顧客属性に対するHVOPサポート

HVOPを使用して最終顧客の属性をインポートできます。これは、大量のデータを処理するユーザー向けの一括インポートに対応しています。流通業界では大量受注が一般的です。

最終顧客情報のレポート

最終顧客販売をパートナ別にレポートできます。次の内容もレポートされます。

• パートナ/Sold_To顧客の販売先最終顧客

• この最終顧客の購入元

OIPでの最終顧客の名称および所在地の表示

受注情報ポータル（OIP）では、受注を処理する際に取得した最終顧客名と所在地をヘッダー・レベルと明細レベルの両方で表示できます。

OIPでの最終顧客の担当の表示

受注を処理する際に取得した最終顧客の担当をヘッダー・レベルと明細レベルの両方で表示できます。外部パートナは、追跡のために担当を使用できます。社内ユーザーは、最終顧客の担当を表示できます。表示する必要がない場合は、パーソナライズによって担当を非表示にできます。

OIPでのInstalled Base用最終顧客属性の表示

OIPでは、所有者、導入場所事業所および現行事業所をヘッダー・レベルと明細レベルの両方で表示できます。この情報は、社内外の両方のユーザーに役立ちます。表示されるのは、受注時に取得した情報であるため、更新されていない可能性があり、その後Installed Baseで変更されている可能性もあります。

OIPでの個々のDFFセグメントの表示

OIPでは、付加フレックスフィールド（DFF）の各フィールドの内容をユーザー定義ラベルとともに表示できます。たとえば、再販店の名称と所在地、2年目の更改金額またはCSI番号を取得することが重要な場合があります。OIPでは、ヘッダー・レベルと明細レベルでDFFの個々のセグメントすべてを表示できます。

最終顧客別ソート

OIPを使用すると、問合せ結果を最終顧客別にソートできます。たとえば、すべての受注を問い合せ、次にそれらの受注を最終顧客別にソートできます。これは、取引の多い最終顧客を知る指標となり、特定の最終顧客に関する受注情報を検索する際にも便利です。

ユーザー・プロシージャ

「受注」ウィンドウから最終顧客を手動で定義する手順は、次のとおりです。

1. ヘッダー・レベルのデフォルト設定。次のいずれかの属性を手動で入力できます。ただし、ほとんどのユーザーは「受注」ウィンドウにデフォルト値を設定します。必要な場合は、APIデフォルト条件を作成できます。つまり、基本契約がXであればデフォルトの最終顧客がIB所有者となりますが、基本契約がYの場合はIB所有者として販売先顧客がデフォルト設定されます。または、「導入ベース所有者」、「現行事業所」および「導入場所事業所」のプロファイル・オプションに基づいて属性をデフォルト設定できます。

2. 最終顧客。最終顧客を手動で入力する必要があるか、または受注ヘッダーの出荷先または販売先からデフォルト設定する必要があるかを指定します。

3. IB所有者。APIデフォルト条件を作成して、IB所有者のヘッダー・レベル依存属性を移入するためのロジックを定義できます。または、デフォルト・フレームワークを使用して、販売先顧客または最終顧客をデフォルト設定できます。

4. 現行事業所。出荷先、最終顧客、搬送先、販売先または請求先のいずれかの事業所をヘッダーからデフォルト設定します。

5. インストール場所事業所。出荷先、最終顧客、搬送先、販売先または請求先のいずれかの事業所をヘッダーからデフォルト設定します。

   「所有者」、「現行事業所」および「導入事業所」の値がOracle Install Baseに渡されます。

6. 明細レベルのデフォルト設定。必要な値を手動で入力できます。オプションで、前述の属性を明細レベルにデフォルト設定する方法を定義できます。たとえば、必要な場合はヘッダーと同じ値を明細にデフォルト設定できます。

7. 顧客の定義。「顧客」ウィンドウを使用して最終顧客を定義します。これにより、最終顧客を販売先顧客として使用できます。最終顧客を出荷先顧客として使用する場合は、出荷先サイトも定義する必要があります。必要な場合は、請求先や搬送先など、他のビジネス目的を設定します（最終顧客事業所のビジネス目的として、販売先、出荷先、搬送先または請求先を使用できます）。

8. 受注ヘッダー。通常の手順で受注ヘッダーを作成します。必要な場合は、「ヘッダー」の値リストから「最終顧客」を選択します。Oracle Install Base属性（「所有者」、「導入済事業所」および「現行事業所」）にデフォルト設定された値を検討し、必要に応じて変更します。

9. 受注明細。「明細」タブで、必要な場合は明細ごとに異なる最終顧客を指定して情報を入力します。オプションで、デフォルト・フレームワークを使用して、ヘッダーの「最終顧客」を明細の「最終顧客」にデフォルト設定できます。

10. 記帳、出荷、請求書など、受注と明細の取引タイプでの定義に従って受注を進行させます。機能アクティビティ「導入ベース・インタフェース」を出荷可能明細フローに挿入している場合は、後述のようにIB属性値がOracle Install Baseに渡されます。

    アウトバウンド受注明細

11. 品目が出荷可能な場合は、実際の出荷を使用してInstall Baseが更新されます。

12. 品目が出荷不可能な場合、実際の出荷詳細はありません。明細フローの履行-明細アクティビティを使用してInstall Baseが更新されます。

    インバウンド明細

    明細がRMAの場合、Oracle Install Baseの更新は在庫資材取引を明細の更新に使用できるかどうかに応じて異なります。

13. 明細がRMAで、実際の資材受入が必要な場合は、その受入に対する在庫資材取引によってInstall Baseの更新がトリガーされます。

14. RMA明細が受入を必要としない場合は、返品明細フローの履行-明細ワークフロー・アクティビティを介してInstall Baseが更新されます。

最終顧客機能と受注インポート

1. 「最終顧客」およびOracle Install Base属性（「所有者」、「導入場所事業所」および「現行事業所」）の値をインタフェース表に直接移入するかどうかを決定します。または、必要に応じてデフォルト・フレームワークおよびプロファイル・オプションのソースを使用して、これらの値を受注ヘッダーおよび明細にデフォルト設定できます。

2. 「顧客」ウィンドウで最終顧客を設定します。これにより、最終顧客を販売先顧客として使用できます。最終顧客を出荷先顧客として使用する場合は、出荷先サイトを設定する必要があります。必要な場合は、請求先や搬送先など、他のビジネス目的も設定できます。

   注意: 「受注インポート」の「顧客の追加」機能では、最終顧客はサポートされません。

3. 「受注インポート」を実行します。EDIとXMLは使用できないことに注意してください。

4. 受注および明細の取引タイプ（つまり、記帳、出荷、請求など）で定義されているように受注を進めます。IB属性値は次のようにInstall Baseに渡されます。

   アウトバウンド受注明細

5. 品目が出荷可能な場合は、実際の出荷を使用してInstall Baseが更新されます。

6. 品目が出荷不可能な場合、実際の出荷詳細はありません。履行-明細ワークフロー・アクティビティ・ノードを使用してInstall Baseが更新されます。

   インバウンド明細（RMA）

   明細がRMAの場合、Oracle Install Baseの更新は在庫資材取引を明細の更新に使用できるかどうかに応じて異なります。

7. 明細がRMAで、実際の資材受入が必要な場合は、その受入に対する在庫資材取引によってInstall Baseの更新がトリガーされます。

8. RMA明細が受入を必要としない場合は、履行-明細ワークフロー・アクティビティ・ノードを介してInstall Baseが更新されます。

Oracle Order Captureを介してOrder Managementに取り込まれるiStore受注

1. シード済のワークフロー機能アクティビティ「導入ベース・インタフェース」を、出荷可能明細の取引タイプに追加します。

2. 「顧客」ウィンドウで最終顧客を設定します。これにより、最終顧客を販売先顧客として使用できます。最終顧客を出荷先顧客として使用する場合は、出荷先サイトを設定する必要があります。必要な場合は、請求先や搬送先など、他のビジネス目的も設定できます。

3. iStoreで、最終顧客情報、所有者、現行事業所および導入場所事業所を指定して受注を作成します。必要な場合は、明細ごとに異なる最終顧客を指定します。

4. Oracle Order CaptureによりGroup APIがコールされ、受注がOrder Managementに取り込まれます。最終顧客情報とIB属性（所有者、現行事業所および導入事業所）が、iStoreからOrder Managementに取り込まれます。

5. 記帳、出荷、請求書など、受注と明細の取引タイプでの定義に従って受注を進行させます。Oracle Install BaseとOracle Service Contractsを使用している場合は、後述のようにIB属性値がOracle Install Baseに渡されます。

   アウトバウンド受注明細

6. 品目が出荷可能な場合は、実際の出荷を使用してInstall Baseが更新されます。

7. 品目が出荷不可能な場合、実際の出荷詳細はありません。履行-明細ワークフロー・アクティビティ・ノードを使用してInstall Baseが更新されます。

   インバウンド明細（RMA）

   明細がRMAの場合、Oracle Install Baseの更新は在庫資材取引を明細の更新に使用できるかどうかに応じて異なります。

8. 明細がRMAで、実際の資材受入が必要な場合は、その受入に対する在庫資材取引によってInstall Baseの更新がトリガーされます。

9. RMA明細が受入を必要としない場合は、履行-明細ワークフロー・アクティビティ・ノードを介してInstall Baseが更新されます。

最終顧客を伴う見積

1. 見積のヘッダー・ワークフローは変更不要です。

2. 「顧客」ウィンドウで最終顧客を設定します。これにより、最終顧客を販売先顧客として使用できます。最終顧客を出荷先顧客として使用する場合は、出荷先サイトを設定する必要があります。必要な場合は、請求先や搬送先など、他のビジネス目的も設定できます。

3. 最終顧客情報、所有者、現行事業所および導入場所事業所をヘッダーに指定して、見積を作成します。

4. 必要に応じて明細ごとに異なる最終顧客を指定して、見積明細を作成します。

5. 見積が受注に変換された後は、記帳、出荷、請求書など、受注と明細の取引タイプで定義されているフローに従って受注を進行させます。IBワークフローを持つ出荷可能明細の場合は、IB属性値がOracle Install Baseに渡されます。Oracle Service Contractsを使用している場合は、Oracle Order CaptureからOracle Service Contractsに取引先/販売先顧客が渡されます。

6. 出荷可能品目の場合は、出荷後に値が渡されます。

7. 出荷不可品目の場合は、履行後にOracle Order Captureが情報を取得してOracle Service Contractsに送信します。

   注意: 取引先以外の受注の場合、「最終顧客」はNULLになります。取引先受注とそれ以外の受注が混在する場合は、2つの異なる受注タイプの使用を検討する必要があります。

営業文書のプレビューおよび印刷

ビジネスには、それぞれが固有のビジネス・ニーズに適合した、様々な情報が含まれる文書が必要です。動的なプレビューおよび印刷の機能によって、独自のレイアウト要件を満たすことができる、印刷可能なAdobe Portable Document Format（PDF）を生成できます。「プレビューおよび印刷」は、各ビジネス文書（受注、受注のリリース、見積または営業基本契約）で使用できる処理で、表示と印刷が可能なPDF文書が表示されます。

次の機能があります。

• レイアウト・テンプレートを特定の書式要件に合せて設計できます。

• ヘッダー、明細情報、署名ブロックなど、ビジネス文書の関連情報を印刷します。

• デフォルトのレイアウト・テンプレートを取引タイプに定義できます。

• A 「ビジネス文書」フィールドには、「プレビューおよび印刷」用に定義されたレイアウト・テンプレートが表示されます。

• シードされている交渉ワークフローにサブプロセス「営業基本契約/受注生成」を組み込むように拡張することで、内部承認者へのワークフロー通知にPDFを自動的に添付でき、システム内のビジネス文書にPDFファイルを添付できます。

• 営業基本契約または受注を生成できます。

プレビューおよび印刷の主な機能

文書のプレビューおよび印刷

多くのビジネスで、営業基本契約や、見積または受注を、顧客署名用に表示されるとおりにプレビューし、文書を印刷する必要があります。文書には、基本契約の一部として、テキストによる条件が含まれる場合と含まれない場合があります。

注意: 契約条件は、顧客がOracle Sales Contractsのライセンスを取得し、設定している場合にのみ、営業基本契約に組み込むことができます。

営業基本契約および見積/受注のプレビューおよび印刷

ユーザーが、営業文書である営業基本契約または見積/受注のプレビューを開始すると、システムによって、次のコンポーネントに基づいて文書のプレビューが生成されます。

• 営業基本契約データ（営業基本契約のヘッダーと明細、価格設定と条件を含む）

• 書式設定用のカスタマイズ可能なスタイルシートまたはレイアウト・テンプレート

  または

• 見積/受注データ（受注、価格設定および条件（前述の注意を参照）を含む）

• 見積または受注のヘッダー・レベルまたは明細レベル（あるいはその両方）における参照元の営業基本契約のPDFへのリンク

営業文書のプレビュー

書式設定された営業基本契約をプレビューできます。文書には、ヘッダー情報、明細と価格情報、およびテキストによる条件などが含まれます。

営業基本契約のヘッダーからプレビューおよび印刷するには、「処理」 > 「プレビューおよび印刷」を使用するか、マウスを右クリックして「プレビューおよび印刷」にアクセスします。特定の営業基本契約がオープンしているときに、書式設定された契約文書のプレビューを開始できます。営業基本契約から文書をプレビューするときは、常にPDF形式で表示されます。ファイル出力形式を選択する必要はありません。

社内承認を得るために営業基本契約を発行すると、システムによって、書式化されたPDF文書が自動的に生成されます。これは、営業基本契約への契約文書添付として格納されます。このPDFが添付として自動的に格納されるのは、前述のWF機能拡張が交渉フェーズに追加されている場合のみです。

書式設定された営業文書をプレビューできます。印刷される文書には、ヘッダー情報、明細と価格情報、およびテキストによる条件などが含まれます。

注意: 営業基本契約と印刷文書で契約条件を使用可能にするには、Oracle Sales Contractsのライセンスとその設定が必要です。

T&C（条件）は、Oracle Sales Contractsと統合されている場合のみ有効です。メニュー・オプション「プレビューおよび印刷」は、見積/受注のヘッダーから使用できます。特定の見積/受注がオープンしているときに、書式設定された受注文書のプレビューを開始できます。

見積/受注から受注文書をプレビューするときは、常にPDF形式で表示されます。ファイル出力書式を選択する必要はありません。

営業基本契約または見積/受注へのプレビューの添付

営業基本契約または見積に対する承認処理を開始（「処理」 > 「草案の発行」）すると、承認処理の開始時に、営業基本契約または見積の書式設定されたPDFファイルがワークフロー承認通知に添付されます。この結果、承認者は、書式設定された文書を承認通知から直接表示できます。

受注の記帳時に、システムによって、受注の書式設定されたPDFファイルが自動的に添付されます。

注意: 自動添付を取得するには、承認付き交渉フローに、サブプロセス「営業基本契約/受注生成」を追加する必要があります。

ワークフロー承認通知からのビジネス文書のプレビュー

承認者は、ワークフロー承認通知をオープンし、承認通知内のリンクを直接クリックしてビジネス文書を表示できます。出力ファイル・タイプはPDF形式です。

すべてのビジネス変数が表示され、空のビジネス変数に対しては適切なプレースホルダが表示されます。

「ファイル」ウィンドウからビジネス文書のPDFファイルの印刷を選択するには、Adobe Acrobatの「ファイル」 > 「印刷」メニュー・オプションを選択するか、Adobe Acrobatの変数である印刷ツールバー・アイコンをクリックします。

注意: この機能は、Netscape 4.79とAdobe Acrobat Reader 5.0の組合せとは互換性がありません。これ以降のバージョンとは互換性があります。Acrobat Reader 6.0にアップグレードすると、互換性の問題は解決します。

契約の印刷を実行するには、Adobe Acrobatから「ファイル」 > 「印刷」を選択するか、ツールバーから印刷メニュー・アイコンを選択します。

印刷

3つの取引すべてに対する印刷機能は同じです。最初にPDFをプレビュー（「処理」 > 「処理」）する（または既存の添付をオープンする）必要があります。次に、プリンタ・アイコンまたは「ファイル」 > 「印刷」を使用するか、[Ctrl]キーを押しながら[P]キーを押すとPDFを印刷できます。

文書の書式設定

スタイルシートまたはレイアウト・テンプレートによって、営業基本契約または見積/受注文書のプレビューまたは印刷時の書式が定義されます。アプリケーションとともに4つのレイアウト・テンプレートがシードされます。

• 営業基本契約用のPDFを生成するためのXMLパブリッシャを生成するレイアウト・テンプレート

• 見積/受注用のPDFを生成するためのXMLパブリッシャを生成するレイアウト・テンプレート

• 営業基本契約用のHTMLを生成するXMLパブリッシャ・レイアウト・テンプレート

• 見積/受注用のHTMLを生成するXMLパブリッシャ・レイアウト・テンプレート

スーパーユーザーは、設定時に複数のカスタム・レイアウト・テンプレートを定義できます。ユーザーは、設定の一部として、受注管理の各取引タイプに対してレイアウト・テンプレートを関連付けます。ユーザーがプレビューを開始すると、文書は、その取引タイプに関連付けられたレイアウト・テンプレートに基づいてプレビューされます。

注意: レイアウト・テンプレートの定義時に、作成者はその内容がすぐに判別できるような名称を設定する必要があります。そうすることで、そのレイアウト・テンプレートを取引タイプに関連付けるときに、正しいレイアウト・テンプレートを簡単に選択できます。この手順は設定時に1回行うのみで、通常のユーザーが実行する必要はありません。

注意: レイアウト・テンプレートは、「XMLパブリッシャ」 > 「テンプレート」を使用して作成できます。

ビジネス文書データの書式設定

スーパーユーザーは、営業基本契約および見積/受注の次の各コンポーネントについて、レイアウト・テンプレートの書式設定プロパティを定義できます。

• 営業基本契約および見積/受注データ: 品目、品目摘要、価格および取引約定数量（営業基本契約のみ）などのデータには、レイアウト・テンプレートで定義され、データの書式設定方法を契約プレビュー・ツールに通知する特定のプロパティを設定できます。

• セクション: スーパーユーザーは、句のセクションに対する書式設定プロパティを定義できます。セクションとは、次の「1.0 General Terms」など、句グループのヘッダーです。セクションのタイトルと連番には固有のスタイルを設定することもできます。

  • 1.0 General Terms

  • 1.1 Term 1

  • 1.2 Term 2

• 句: スーパーユーザーは、句テキストに対する書式設定プロパティを定義できます。句のタイトル、句テキストおよび句番号に固有のスタイルを設定することもできます（Oracle Sales Contractsのライセンスがあり、設定されていることが前提です）。

  静的テキスト: 営業基本契約または見積/受注スキーマ、あるいは条件に表示されない他のテキストの印刷が必要になる場合があります。このデータは、レイアウト・テンプレートで定義されます。たとえば、次の例のテキスト「Software License Agreement」、「Between」および「And」はレイアウト・テンプレートで定義されます。

  Software License Agreement

  Between

  <Oracle> <system variable>

  And

  <Company B> <system variable>

• ビジネス変数: ビジネス変数の代替の値には、句で定義されるとおりの固有のスタイルを設定できます。これには、システム変数とユーザー定義変数の両方が含まれます。

セキュリティ

レイアウト・テンプレートのセキュリティ

レイアウト・テンプレートはグローバルな参照が可能で、組織に固有ではありません。

ユーザー・プロファイル

次に、ユーザーと、そのユーザーがプレビュー/印刷機能の使用中に実行するタスクを示します。

スーパーユーザー

通常、システム管理者とITエンジニアはスーパーユーザーです。これらのユーザーはアプリケーション設定の一部としてXMLパブリッシャ・レイアウト・テンプレートを定義/カスタマイズします。このレイアウト・テンプレートはプログラミングで定義するものであり、XMLパブリッシャの知識が必要です。

ビジネス・ユーザー

営業マネージャ、営業担当、顧客サービス・マネージャ、顧客サービス担当、契約管理者/交渉者およびその他のビジネス・マネージャ（営業役員、価格設定の専門家）で構成されます。

ビジネス・ユーザーが関与するタスクには、ビジネス文書のオーサリング、交渉、承認があります。通常、ビジネス・ユーザーはビジネス文書のレイアウト定義を担当し、システム管理者と一緒にレイアウト・テンプレートを定義または更新し、適切な書式のビジネス文書を作成します。

エンド・ユーザー

営業担当や顧客サービス担当（CSR）で構成されます。エンド・ユーザーは、文書のプレビュー/印刷機能を使用します。プレビュー/印刷機能は、日常業務の一環として使用されます。

プレビューおよび印刷（PnP）が使用される場合の例は、次のとおりです。

• 承認開始前

• 承認者は各WF通知に対してPnP（プレビューおよび印刷）を使用して、ビジネス文書の詳細を表示します。

• 顧客受入前の顧客との共有使用

• 顧客署名を印刷紙で取得し、スキャンして、将来の参照のためにビジネス文書に添付します。

• 取引参照時に署名バージョンの詳細を表示します。

ビジネス文書データの書式設定プロパティ

スーパーユーザーは、契約コンポーネントに対して次のレイアウト・テンプレート・プロパティを定義できます。

• フォント・タイプおよびサイズ

• 太字体、下線、斜体などのフォント属性

変数の書式設定

スーパーユーザーは、ビジネス変数の書式を定義できます。表の書式設定に対して次の書式設定オプションがサポートされています。

• 各列ヘッダーのテキスト

• 表示/印刷される列とその順序

• フォント・タイプ（14の標準PDFフォント）および列とヘッダーのサイズ

• 列およびヘッダーに対する太さ（太字体）や強調（下線、斜体）などのフォント属性

• 境界線（合計またはなし、線の幅）

テキスト書式で表示される変数に対して、次の書式設定オプションがサポートされます。

• フォント・タイプおよびサイズ

• 太字体、下線、斜体などのフォント属性

ヘッダーおよびフッターの書式

スーパーユーザーは、レイアウト・テンプレートのカスタマイズの一部として、文書のヘッダーとフッターを定義できます。ヘッダーとフッターには、次の項目を組み込むことができます。

• 静的テキスト

• ページ番号（アラビア数字）

• 合計ページ数（FOP/ATGインフラストラクチャでサポートされる場合）

• 文書に使用できる変数（仕入先名など）

レイアウト・テンプレートのヘッダーとフッターに対して、次のスタイル・プロパティを定義できます。

• フォント・タイプ（14の標準PDFフォント）およびサイズ

• 太さ（太字体）や強調（下線、斜体）などのフォント属性

署名ブロックの生成

署名ブロックは、レイアウト・テンプレートで定義されるときに、SAまたは見積/受注の一部として生成されます。

新規レイアウト・テンプレートの登録

新規レイアウト・テンプレートの作成または既存レイアウト・テンプレートの変更（あるいはその両方）、およびそれらのアプリケーションへの登録ができます。

注意: シード済レイアウト・テンプレートは、アップグレードをサポートするために変更できないよう保護されます。ただし、シード済レイアウト・テンプレートをダウンロードし、それを変更するか、または変更せずに有効なレイアウト・テンプレートとして登録できます。

レイアウト・テンプレートと取引タイプの関連付け

書式レイアウト・テンプレートを選択して、それを受注管理取引タイプと関連付けることができます。ビジネス文書の生成では、ビジネス文書の取引タイプおよび関連付けられたレイアウト・テンプレートに従って書式設定されます。

例:

レイアウト・テンプレートが「取引タイプ」画面で識別されない場合にプレビュー/印刷処理を開始すると、エラー・メッセージが表示され、レイアウト・テンプレートを定義する必要があることが通知されます。「設定」 > 「取引タイプ」 > 「定義」を選択すると、「レイアウト・テンプレート」フィールドに値リストが表示されます。値リストには、選択可能な登録済レイアウト・テンプレートがすべて表示されます。

「取引タイプ」ウィンドウ - 「レイアウト・テンプレート」フィールド

インライン書式設定

プレビュー/印刷では、限定数のHTMLスタイル・タグを使用したインライン書式設定がサポートされています。ビジネス文書のプレビュー/印刷機能にはリッチ・テキスト・エディタが用意されていないため、これらのタグをテキストに直接挿入する必要があります。

たとえば、句内のいくつかの語を太字で書式設定する必要がある場合は、次のようになります。: "Applicable shipping costs are to be paid for by the Customer, who agrees to pay them in full per payment terms."

ビジネス変数の置換

ビジネス文書作成機能では、句へのビジネス変数の組込みがサポートされています。これらの変数は、ビジネス文書がプレビュー/印刷されるときにその値で置換されます。アプリケーションでは、単純（スカラー）変数と表ビジネス変数がサポートされています。

単純ビジネス変数の置換

単純ビジネス変数は、文書がプレビューまたは印刷されるたびにその値で置換されます。ビジネス変数の表示書式は、レイアウト・テンプレートで定義されます。すべてのカスタム書式ニーズを満たすように、レイアウト・テンプレートをカスタマイズできます。

単純ビジネス変数の例: <Customer>の部分が顧客名に置換されます。

"Applicable shipping costs will be paid for by <Customer> …"

Customer = ACME Corporationの場合の例:

"Applicable shipping costs will be paid for by ACME Corporation..."

表ビジネス変数の置換

表ビジネス変数は、変数に含まれる値のXML値で表現されます。表示される列など、表の表示書式は、レイアウト・テンプレートで定義されます。すべてのカスタム書式ニーズを満たすように、レイアウト・テンプレートをカスタマイズできます。XML表現には、印刷に使用できるすべての表列が含まれています。レイアウト・テンプレートによって、表示される列とその順序が決まります。

未決定のビジネス変数の印刷

ビジネス変数に定義されている値がない場合、システムでプレースホルダ（下線が引かれた10文字長のブランク）が出力されます。

ユーザー・プロシージャ

次に、文書のプレビュー/印刷機能使用のユーザー・プロシージャを、各手順を実行するユーザー/ロールとともに示します。

レイアウト・テンプレートを受注管理取引タイプに関連付ける手順は、次のとおりです（スーパーユーザー + ビジネス・ユーザー）。

1. 「取引タイプ」ウィンドウの取引タイプ設定にナビゲートします。

2. 「レイアウト・テンプレート」フィールドで、値リストを使用して取引タイプに対するレイアウト・テンプレートを選択します。

3. 作業内容を保存します。

   注意: この取引タイプからビジネス文書をプレビューする場合、書式設定は、ここで定義したレイアウト・テンプレートに基づきます。

承認通知からのプレビューおよび印刷。すべての取引で共通。

1. ワークフロー承認プロセスを開始します。承認者は、承認通知を受信し、PDFリンクをクリックするとビジネス文書をプレビューできます。

2. ビジネス文書はPDF形式で表示されます。書式設定はレイアウト・テンプレートに基づきます。

3. 文書を検討し、必要に応じて印刷して文書をクローズします。印刷するには、「ファイル」 > 「印刷」メニュー・オプションをクリックするか、印刷アイコンをクリックします。

4. まだオープンしている承認通知に返答します。承認サイクル中はビジネス文書を変更できません。

「見積」、「受注」または「営業基本契約」ウィンドウからプレビューおよび印刷する手順は、次のとおりです。

1. ウィンドウにナビゲートし、プレビューまたは印刷する取引（SA）を検索します。「処理」ボタンから、またはマウスを右クリックして表示されるメニューから、「プレビューおよび印刷」オプションをクリックします。

2. レイアウト・テンプレートが定義されていない場合は、次のエラー・メッセージが表示されます。: 「ビジネス文書< >は、レイアウト・テンプレートが「取引タイプ」設定画面で定義されていないためプレビューまたは印刷できません。」

   レイアウト・テンプレートが定義されている場合、ビジネス文書は、スタイル・シートの書式設定に基づいてPDF形式で生成されます。

3. 文書を検討し、Acrobatウィンドウから文書の印刷も選択できます。印刷するには、Acrobatの「ファイル」 > 「印刷」メニュー・オプションを選択するか、印刷アイコンをクリックします。

「契約条件」ウィンドウからのプレビューおよび印刷

「契約条件」ウィンドウ（「処理」 > 「契約条件」）を表示しているときに「文書のプレビュー」をクリックすると、Oracle Sales Contractsがインストールされている場合は、「取引タイプ」設定画面で識別されたレイアウト・テンプレートを使用して、書式設定された同様のビジネス文書が表示されます。

注意: 営業基本契約から作成される、その営業基本契約に固有の価格表とモディファイアのみがプレビューまたは印刷されます。標準価格表が識別されている場合は、ビジネス文書に参照として表示されます。

統合

統合の依存関係: XMLパブリッシャの依存関係

文書プレビュー（PDF）を生成するには、XMLパブリッシャが必要です。XMLパブリッシャは、Oracle Sales Contractsでは必須の前提条件であるため、Oracle Sales Contractsがインストールされている場合は、プレビューおよび印刷が可能です。Sales Contractsがインストールされていない場合は、XMLパブリッシャをインストールして、文書プレビューを生成できるようにする必要があります。XMLパブリッシャがインストールされていない場合は、包括受注基本契約および見積/受注の「プレビューおよび印刷」処理は有効になりません。この依存関係は、次の機能に影響を与えます。

• 書式設定された文書プレビュー（PDFファイル形式）の生成の手動開始（『Oracle Order Managementユーザーズ・ガイド』を参照）

• 書式設定された文書の自動生成および表示のためその文書を承認通知に添付

シード・データ

この項では、包括受注基本契約または見積/受注のプレビュー/印刷に必要なすべてのシード・データを示します。

• ビジネス文書のレイアウト・テンプレートのシード。一般的な営業基本契約書式のプレビュー用に、レイアウト・テンプレート（デフォルトの営業基本契約）がシードされています。

• 見積/受注用のPDFを生成するためのレイアウト・テンプレート。

• SA用のHTMLを生成するレイアウト・テンプレート。

• 見積/受注用のHTMLを生成するレイアウト・テンプレート。

• 営業基本契約のプレビューまたは印刷を表示するためのファンクションがシードされています。

  • SAのプレビュー/印刷が「営業基本契約」ウィンドウから呼び出されると、次のシード済ファンクションが起動され、プレビュー/印刷ページが起動されます。

  • ファンクション: ONT_PRINT

  • ユーザー・ファンクション名: Order Management Print

• BSAのプレビュー/印刷が「契約条件」ウィンドウから呼び出されると、次のシード済ファンクションが起動され、プレビュー/印刷ページが起動されます。

  • ファンクション: プレビューおよび印刷

直接出荷の概要

概要

直接出荷機能を使用すると、顧客から受けた受注を、仕入先のサイトから直接履行できます。Order Managementでは、標準、モデル、キットおよび構成品目に対して直接出荷の受注および明細を入力できます。ただし、出荷モデル完了（SMC）のPTOに対しては、現在直接出荷は実行できません。

在庫にない品目や在庫が十分でない品目に対して受注を受けることができ、仕入先から顧客に直接、品目を搬送できます。直接出荷の利点は次のとおりです。

• 在庫が不要

• 受注履行の処理コストの削減

• フロー時間の短縮

• 販売不可の商品による損失を防止

• 梱包と出荷コストの削減

• 必要な在庫スペースの削減

• 顧客への出荷期間の短縮

• 顧客に幅広い製品をオファーできる

受注を直接出荷で処理するときは、次のことができます。

• オプションで事前出荷通知（ASN）を受け取り、電子的に処理できます。

• 出荷の通知を基に、論理的な受入を自動的に実行できます。

• 製造品目および購入品目に対して直接出荷を実行でき、直接出荷する必要がある受注明細のソース・タイプを「外部」に自動的にデフォルト設定できます

直接出荷受注の需要と供給の詳細は、Oracle Planningアプリケーションから参照できません。このため、直接出荷受注を出荷するための別の論理（ダミー）組織を関連付けることをお薦めします。この論理組織は計画プロセスに含めないでください。

通常の在庫組織で直接出荷品目を使用している企業はまれではありません。この使用方法は、企業がMRPまたはMIN-MAXを使用していない場合は問題がありません。これは、MIN-MAXおよびMRPでは、すべての供給は手持在庫数量の想定範囲内の増加であると考えるように設計されているためです。一方、実際には、直接出荷の受注に関連付けられている供給によって手持在庫数量が増加し、その後、手持在庫数量から受入数量がただちに消し込まれます。この「偽り」の供給により直接出荷の発注にリストされる数量のために、MRPおよびMIN-MAXで正しい結果が得られなくなる可能性があります。したがって、直接出荷在庫組織は、非直接出荷在庫組織とは完全に独立して作成することをお薦めします。『Oracle Order Managementユーザーズ・ガイド』には、直接出荷組織を「論理的」な在庫組織にする必要があることが説明されています。これは、直接出荷の受注は直接出荷の在庫組織のみで実施する必要があることを意味します。

モデルまたはキットが含まれる受注を直接出荷で処理するときは、SMC以外のPTO構成内の個別品目を異なる仕入先から直接出荷でき、一部の構成部品を在庫から出荷することもできます。

ATO構成が含まれる受注を直接出荷で処理するときは、次のことができます。

• 構成の詳細を示す生成済添付ファイルを、構成可能品を製造する仕入先に送付できます。仕入先は、この情報をiSupplier Portalから参照することもできます。

• 照合を実行できます。「構成品目の作成」サブプロセス時に新しい構成IDを生成するかわりに、既存の構成IDを使用できます。照合は組織/仕入先に関係なく行われます。

購買、ATO品目やATO構成の直接出荷およびこれらの受注タイプの変更の詳細は、『CTO Implementation Manual』を参照してください。

注意: このリリースでサポートされている直接出荷の追加機能は、「元帳間の直接出荷および変更管理の概要」の項を参照してください。

直接出荷受注に影響を与える品目属性

直接出荷品目（およびすべての外部ATOまたはPTOモデル、そのオプション区分とオプション）はすべて、受注管理のシステム・パラメータ「品目検証組織」の値で指定された品目検証組織内に定義する必要があります。

品目に対する直接出荷受注明細の作成機能に影響を与える在庫品目属性とその値を、次の表に示します。

Oracle Purchasingで、単発費用品目という用語が使用されます。これは、在庫で定義されていない費用品目で、品目データベース表MTL_SYSTEM_ITEMSにも関連するレコードが存在していない品目を表します。単発費用品目は在庫で定義されないため、在庫属性をチェックできず、そのため直接出荷できません。

直接出荷在庫組織を作成した後は、保管場所を定義する必要があります。保管場所を作成するには、在庫職責に移動して、「設定」 > 「組織」 > 「保管場所」の順にナビゲートします。直接出荷保管場所については、すべて「予約可能」ボックスを選択する必要があります。資産保管場所については、「予約可能」および「資産」ボックスを選択する必要があります。費用保管場所については、「予約可能」ボックスを選択する必要があり、「資産」ボックスは選択できません。

• 資産保管場所の保管場所属性

  • 予約可能/在庫引当の許可

  • 資産保管場所

• 費用保管場所の保管場所属性

  • 予約可能

  • 資産 – 使用可にはできません

受注明細属性「ソース・タイプ」のデフォルト設定

組織品目属性「デフォルト出荷組織ソース・タイプ」（「組織品目」ウィンドウの「受注管理」タブ）は、シード済のOrder Managementデフォルト・フレームワーク内で使用され、受注明細の「ソース・タイプ」フィールドのデフォルト値を提供します。この属性の値は組織ごとに設定できます。

「ソース・タイプ」フィールドのデフォルトを設定するための手順は、次のとおりです。

1. 組織品目属性「デフォルト出荷組織ソース・タイプ」の値を確認します。

   この属性がNULLの場合は、次の処理が実行されます。

2. Order Managementによって、値が「内部」にデフォルト設定されます。

3. 受注明細の「ソース・タイプ」フィールドの値がデフォルト設定されないようにするには、受注明細属性「ソース・タイプ」に対するシード済デフォルト・ルールを無効にする必要があります。

4. 受注明細の「ソース・タイプ」の値が「外部」から「内部」に変更され、明細の予定出荷日が手動で入力されると、Order Managementは、入力された日付で受注明細の予定を作成しようとします。

   • Order Managementのシード済制約によって、「供給の作成 - 明細」ワークフロー・サブプロセス内のソース・タイプ分岐ワークフロー・アクティビティが完了している場合は、ソース・タイプの値を変更できません。

一括変更と受注明細属性「ソース・タイプ」

受注明細属性「ソース・タイプ」に対して一括変更を実施できます。受注明細属性「ソース・タイプ」は、「一括変更」ウィンドウの「出荷」タブで（フィールドとして）使用できます。

予約

受注明細が外部受注として指定されると、Order Managementでは、その受注明細に対して予約を設定できません。

入力および記帳

標準のOrder Managementの機能を使用して受注を入力でき、入力時に特定の明細を直接出荷するかどうかを決定できます（受注明細のソース・タイプは「外部」に設定されます）。標準品目および費用品目はともに直接出荷が可能ですが、直接出荷で現在サポートされている搬送先タイプ（品目属性）は「費用」と「在庫」のみです。標準の受注の場合、直接出荷する予定の受注または明細の変更は、入力後、通常は受注明細の記帳時まで可能です。

ソース・タイプが「外部」の受注明細が記帳されると、シード済ワークフロー「明細フロー - 一般」が直接出荷明細を処理します。「供給の作成 - 明細」サブプロセスが機能「ソース・タイプ分岐」を使用し、「ソース・タイプ分岐」は、「ソース・タイプ」が「外部」の品目を検出し、明細を「購買リリース - 遅延」に移動します。外部のATOモデルまたはATO品目は、適切なATOパスに従います。次に「供給オーダーの作成 - 明細、手動」サブプロセス内で、CTOが品目の「ソース・タイプ」が「外部」であることを検出し、明細を「購買リリース - 遅延」に移動します。ワークフロー・バックグラウンド・プロセッサが明細を処理すると、「購買リリース」プロセスが起動し、PO_REQUISITIONS_INTERFACE表にレコードを書き込みます。

購買リリースおよび購買依頼インポート

「購買リリース」コンカレント・プログラムは、ソース・タイプが「外部」の適格な明細を処理し、Oracle Purchasingに情報を渡します。購買リリース時にOracle Purchasingに転送される購買担当詳細は、受注管理のプロファイル・オプション「OM: 直送明細に対して購買担当コードを生成」の値によって決まります。

自動作成直接出荷オーダー・コンカレント・プログラムは、ソース・タイプが「外部」の適格なATO品目および構成明細を処理し、Oracle Purchasingに情報を渡します。Oracle Purchasingの「購買依頼インポート」コンカレント・プログラムを発行することにより、この情報に基づいた購買依頼を作成します。プログラムの発行時には、入力パラメータ「複数配分」が「No」に設定されていることを確認してください。

注意: 購買リリースの実行後に、購買担当がOracle Purchasingで購買依頼または発注を変更するか、発注の作成後に受注を変更する場合は、Order Managementの受注と発注の差異レポートを使用して、当初の受注と関連する発注の差異を確認します。

出荷および受入の確認

Oracle Purchasingの標準機能によって、仕入先が直接出荷を完了したことが確認されます。確認は、電話による簡単な確認の場合および事前出荷通知（ASN）や出荷と請求の事前通知（ASBN）などの電子データ交換（EDI）による確認の場合があります。

出荷確認を受領したときは、直接出荷品目が取引不可であっても受入をOracle Purchasingに入力します。これによって、インバウンドおよびアウトバウンドの資材取引が会計上の目的でシステム内に作成されます。直接出荷受注は複数の元帳、営業単位または法的エンティティにわたって処理できます。

直接出荷品目は、論理組織で受け入れる必要があります。Oracle Advanced Planning and Schedulingを計画に使用している場合は、供給計算での誤りを避けるため、計画に論理組織を含めない方法を取る場合があります。論理組織を含める場合は、計画や需要予測に混乱が生じないことを確認してください。

仕入先が請求書のみを送付してきた場合は、受動的な受入を入力する必要があります。

請求

システムの在庫に取引が記録された後、請求アクティビティ・プログラムと自動インボイス・プログラムを実行して、顧客に対する請求書を生成します。仕入先が直接出荷に含めた陸揚げ費用や特別手数料を請求書に転嫁することもできます。

受動的な受入

仕入先が直接出荷に対する請求書のみを送付してきた場合は、受動的な受入を実行する必要があります。受動的な受入は、手動で実行する必要があります。

受入数量は関連する請求書から取り出し、直接出荷の論理的な受入を実行する必要があります。

サービス品目

購買可能サービス品目は、販売業者によって提供され、かつ仕入先が実際に直接出荷している品目である場合に、直接出荷できます。直接出荷のサービス明細はソースから直接出荷されません。

たとえば、テレビをサービス可能品目として定義できます。受注の発行時、ソース・タイプは「外部」に設定し、テレビのサービス明細を定義する必要があります。ただし、購買依頼または発注を作成するためにOracle Purchasingに送信できるのは、このテレビのみです。仕入先は、顧客にこのテレビを出荷する責任のみを負います。

モデルまたはキットの遅延サービスであるサービスは、受注管理で受注明細として定義されます。

スケジューリング

モデルまたはキット、あるいは標準品目の直接出荷を実行するとき、予定出荷日は受注明細の要求日からデフォルト設定され、Oracle Global ATPの計算は無視されます（直接出荷受注の需要は、Oracle Planning製品では参照できません）。

直接出荷受注は、標準品目、ATO品目およびモデルとそれらの各構成部品に対する需要予測を消し込むことはできません。

返品

Order Managementの標準機能を使用して、返品承認（RMA）を処理します。顧客は、直接出荷された品目を返品元または仕入先に返品できます。返品を自社の在庫に受け入れた場合は、そのまま保管するか、または仕入先に出荷できます。返品された品目を仕入先に渡す場合は、Oracle Purchasingで返品文書を生成して、返品を承認する必要があります。仕入先が返品を直接受け入れた場合、仕入先は受け入れたことを返品元に通知する必要があります。その後に、返品元はOrder Managementで返品を処理できます。

保留および承認

保留と承認の標準機能を使用して、直接出荷受注を管理します。受注ワークフローの異なる段階で保留と承認を実施して、直接出荷処理を管理できます。たとえば、仕入先に返品を拒否できる権利がある場合、受注ワークフローに承認ステップを追加して、仕入先が返品された品目の受入を返品元に通知しないかぎり、顧客がクレジットを受け取ることのないようにできます。

• 「購買依頼インポート」コンカレント・プログラムの発行前に明細を保留した場合、購買依頼は作成されません。購買依頼を正常に生成するには、保留を削除する必要があります。

• 「購買リリース」コンカレント・プログラムの発行前に明細を保留した場合、発注は作成されません。発注を正常に生成するには、保留を削除する必要があります。

直接出荷受注明細に対して発注が生成された後は、保留を手動で管理する必要があります。手動で管理することによって仕入先と調整できます。受注と発注の差異レポートには保留された受注が表示され、検討できます。

関連項目

直接出荷処理

受注の取消

保留の概要

受注のコピー

注意: 元帳間の直接出荷取引または会社間取引を使用する場合は、「元帳間の直接出荷および変更管理の概要」の項を参照してください。

関連項目: 『Oracle Order Managementインプリメンテーション・マニュアル』の出荷許容範囲の受注の概要に関する項

『Oracle Order ManagementにおけるOracle Workflowの使用』

購買品目の必須設定の詳細は、『Oracle Purchasingユーザーズ・ガイド』、『Oracle Inventoryユーザーズ・ガイド』および『Oracle Configure To Orderインプリメンテーション・マニュアル』を参照してください。

元帳間の直接出荷および変更管理の概要

直接出荷

Oracleに対してアウトソーシング製造へのサポート拡張を要望しているビジネスには、次の3つの傾向があります。

• 一部またはすべての製品を顧客に提供するために、契約製造業者への依存度が増加しています。

• 顧客ニーズにあわせて製品を構成する一括カスタマイズに対する顧客の需要が増加しています。

• 多くの企業が世界各地でビジネスを展開するグローバル化が拡大しています。多くの企業が、グローバルな供給計画を作成して仕入先とグローバル契約を結んでいますが、一方では、国ごとに固有の契約を結び、子会社や仕入先に対してその国に製品を提供する権限を付与しています。

多くの企業は、国ごとにローカル組織を作成してビジネスを展開しています。各ローカル組織には個別に元帳があり、特定の地域または国でハードウェアやソフトウェア製品を販売してサービスを提供する権利を所有しています。製品の販売権を所有する法的エンティティは個別に存在します。多くの場合（すべての場合ではありません）、販売の法的エンティティに関連した物理的な物流センターが存在します。たとえば、企業は、搬送エンティティを自国に1つ所有し、さらにすべての海外組織向けにもう1つ所有する場合があります。複数国にまたがって調達される製品の場合、ローカル組織はそれぞれの地域で販売権を所有する法的エンティティに注文する必要があります。このような状況から、直接出荷、外注処理および製造協力の機能拡張がOracleに要望されています。

直接出荷は、次の場合に発生すると考えられます。

• 顧客が、通常は在庫していない品目を注文した場合

• 顧客が、ある品目を膨大な数量で注文した場合

• 仕入先から顧客に品目を直接出荷した方が費用効果が大きい場合

  元帳間の直接出荷および変更管理

• 複数の元帳、営業単位または法的エンティティ間の直接出荷: 直接出荷機能の拡張によって、受注組織以外の営業単位（OU）、法的エンティティまたは元帳に属する倉庫を選択できます。

• 同一または異なる元帳に存在する複数の組織（営業単位または法的エンティティ）間での会社間取引の拡張: 複数の営業単位間での会社間会計がサポートされています。

• Order ManagementとPurchasing間の変更管理の拡張: 変更管理サポートの拡張によって、Order ManagementおよびPurchasingでの変更が自動的に同期化されます。

• 仕入先に送信される追加の受注データ要素: 直接出荷機能の拡張によって、直接出荷処理に必要な追加の受注データ要素が仕入先に送信されます。

元帳間の直接出荷の主な機能

元帳間の直接出荷

元帳、営業単位または法的エンティティ間での直接出荷が可能となりました。たとえば、製造工場、営業組織および会計会社がそれぞれ別の国に存在する場合があります。このようなエンティティ構造によって、多国籍企業は各エンティティが組織される地域での法的環境の利点を利用できます。また、企業は、地域別に運営の中心地を置き、そこに製品需要の合理化と資材調達の管理を集約することで、製品を市場に迅速かつ収益性の高い方法で供給できます。

元帳、営業単位または法的エンティティ間で商品を直接出荷する機能は、今日のビジネスでは重要な要素です。以前のOracle Applicationsでは、営業単位や元帳間の直接出荷は不可能でした。営業単位間の直接出荷が導入されたことによって、取引を実行する2つの組織間で、受注を両方の組織ではなく、一方の組織に直接出荷するという複合型の直接出荷に対するニーズが高まっています。

• 商品のソースが別の組織の場合、または受注が直接出荷として入力される場合の直接出荷をモデル化できます。購買リリースが実行されると、受注明細が調達組織の購買システム（別の元帳を使用する別の営業単位）に表示されます。

• 直接出荷の実行をサポートするために、複数の元帳および法的エンティティにまたがって顧客所在地を表示できます。

• 営業組織での論理的な商品受入を容易にするために、事前出荷通知（ASN）を受領して記録できます。ASNには、数量、品目、出荷日および出荷先事業所（顧客所在地）が示されています。このASNは、調達組織で論理的な受入が処理されると自動的に作成されます。

• 会社間で発生する売掛管理取引と買掛/未払金取引は、自動的に記録されます。調達組織では商品の会社間売掛請求書を作成し、営業組織では会社間買掛/未払金請求書を生成します。これらの取引は、この2つの組織間で交渉した価格に基づいて実行されます。会社間勘定の残高を一致させるために、売掛請求書と買掛/未払金請求書は同時に作成する必要があります。

  たとえば、会社Aでは、複数のグローバル企業にまたがる直接出荷取引を実行する必要があります。直接出荷取引では、各法的エンティティ内で残高が一致している必要があります（借方=貸方）。各法的エンティティの勘定体系、カレンダまたは通貨は異なる場合があります。

• 直接出荷明細の場合、品目の原価は「会計オプション」ウィンドウ（財務システム・パラメータ）で定義された組織から取得されます。

次の図に、直接出荷の処理フローを示します。

直接出荷の処理フロー

元帳間の直接出荷

直接出荷サポートの拡張によって、システム内で使用可能なすべての倉庫を選択できます。倉庫は、異なる元帳、OUまたは法的エンティティ（LE）から選択できます。上位レベルには、拡張された直接出荷フローとして、フロー 1: 元帳間の直接出荷、またはフロー 2: 物流センター直接出荷があります。

フロー 1: 元帳間の直接出荷

受注はOU1/DCで発行されます。この受注は仕入先から直接出荷して、物流センター（DC/OU3）で履行されます。

• 受注明細は、OU1営業単位で作成され、出荷元組織（受入組織）はDCで、直接出荷受注明細としてマークされます。

• 購買依頼はOU3営業単位で作成され、出荷先組織はDCです。出荷先事業所は顧客事業所です。

• 発注はOU3営業単位で作成され、出荷先組織はDCです。出荷先事業所は顧客事業所です。

複数の元帳にまたがる直接出荷の処理フローは従来の直接出荷処理と同じですが、購買依頼と発注が異なる営業単位で作成される点が異なります。会社間取引は、発注に対して論理的な受入および搬送取引が発生すると実行されます。後述する「会社間取引の拡張」の項を参照してください。

フロー2: 物流センター直接出荷

受注はOU1/MOで発行されます。この受注は仕入先から直接出荷して、物流センター（DC/OU3）で履行されます。

• 受注明細は、OU1営業単位で作成され、出荷元組織（受入組織）はMOで、直接出荷受注明細としてマークされます。

• 購買依頼はOU1営業単位で作成され、出荷先組織はMOです。出荷先事業所は顧客事業所です。

• 発注はOU3営業単位で作成され、出荷先組織はMOです。出荷先事業所は顧客事業所です。

フロー2は、Purchasingで使用可能な新しいShared Procurement機能によってサポートされます。この場合、購買依頼は1つの組織（Order Management/OU1）にあり、購買担当は、別の組織（DC/OU3）に属している仕入先から資材を調達できます。仕入先がOU3に関連付けられているため、発注はOU3から除外されますが、出荷先組織はMOのままです。

別のバージョンのフローでは、受注はOU1/RCで発行され、発注は仕入先から直接出荷してOU3/DCで履行できます。

会社間取引の拡張

会社間取引サポートの拡張によって、直接出荷フローに含まれる複数の組織（OU1、OU2およびOU3）間での会社間取引を実行できます。さらに、会社間の関連を設定することによって、取引に含まれる複数の組織間で会社間勘定や原価などが定義されます。

会社間取引は、Purchasingシステムで搬送取引が発生すると自動的に実行されます。その際、受注明細は「履行済」とマークされ、請求に処理が進められます。

顧客がすでに取引フローを定義している場合は、会社間会計およびOrder Managementの直接出荷受入処理の動作に変更があります。搬送取引がPurchasingで発生すると、取引フローが定義されている場合はInventoryモジュールですべての処理が実行され、Order Managementが呼び出されて明細が履行されたことが示されます。この場合、Order Managementでは在庫を減らさず、受注明細は「履行済」とマークされて処理が進められます。また、会計処理では、在庫の増減はなく、取引フローに含まれる複数の組織間での論理的な会社間取引のみが実行されます。

取引フローを使用しない場合は、複数の組織間で会社間の関連が設定されている前提で、従来の会社間取引が実行されます。この場合、発注の搬送によって在庫が増加し、論理的な受注出庫によって在庫が減少します。会社間取引は受注の出庫取引を使用して実行されます。現行の会社間取引は、2つの組織間でのみ使用できることに注意してください。また、取引フローも、中間組織を除いた2つの組織間で定義できます。

既存の顧客に関連する動作の変更

現在、倉庫は同じ元帳からのみ取得可能であるため、購買依頼は受注と同じ営業単位で作成されています。この動作は変更され、購買依頼は常に倉庫の営業単位で作成されるようになりました。これによって、購買依頼を倉庫と同じ営業単位で作成する必要がある場合、複数の元帳または法的エンティティ間のビジネスにおける一貫性が向上します。さらに、会社間処理が発生するポイントを会社間ロジックで明確に識別できるようになります。

直接出荷の設計変更

次のウィンドウと処理は、拡張された元帳間の直接出荷機能に対応しています。

「受注」ウィンドウ:

直接出荷受注では、使用可能な倉庫を任意に選択できます。「倉庫」フィールドの値リストには、複数の元帳にまたがる倉庫が表示されます。

受注ビジネス・オブジェクトの変更（受注処理）:

直接出荷の設計変更:

• 直接出荷明細の検証で、すべての倉庫が使用可能になりました。

• 「追加明細情報」ウィンドウ:

• オーバーフロー・リージョンに、購買依頼と発注に関する営業単位情報が追加されました。

• 複数組織アクセス管理では、発注と受注が別の営業単位で作成されたときも、発注が作成された営業単位に対してアクセス権が付与されている場合は、発注を表示できます。

• 直接出荷情報ビューに、購買依頼と発注情報が表示されるようになりました。

購買リリース処理:

受入組織が受注の営業単位に属していない場合、購買リリース処理では、その受入組織の営業単位で購買依頼が作成されるように変更されました。

直接出荷の受入処理:

直接出荷の受入ロジックは、元帳間の直接出荷に対応するように変更され、受注とは異なる営業単位で発注を作成できます。

従業員/要求者情報とビジネス・グループ間の影響

従業員（ユーザー）が異なるビジネス・グループ内の異なる営業単位で発注を作成する場合を処理するために、Purchasingでは購買依頼インポートが可能となりました。これによって、顧客サービス担当（CSR）は、プロファイル・オプション「HR:複数ビジネス・グループ間」が「Yes」に設定されている場合、CSRが属するビジネス・グループとは異なるビジネス・グループに関連付けられた営業単位で購買依頼を作成できます。

ユーザー・プロシージャ

異なる元帳を使用する直接出荷受注明細（社外ソース）を入力する手順は、次のとおりです。

1. 「受注」ウィンドウにナビゲートします。

2. 受注および受注明細を社外ソース品目、数量10で入力します。

3. 元帳が異なる受入組織を使用します。

4. 受注を記帳します。

5. 購買リリースが自動的に実行されます。購買リリースが遅延される場合は、WF項目タイプ受注管理明細（OEOL）のワークフロー・バックグラウンド・プロセスが実行されます。

6. 適切な営業単位に変更した後で、購買依頼インポート（購買依頼の作成および承認）を実行します。

7. Purchasingで発注を作成します。「出荷」ブロックの「直接出荷」タブで、受注情報を確認します。「購買」ボタンは、発注を作成した営業単位に対してアクセス権が付与されている場合にのみ使用可能になります。

8. 発注を承認し、印刷します。出荷に関する追加の受注情報を確認します。

9. 発注を仕入先に送信します。

10. 発注を論理的に受け入れ、搬送します。

11. 受注明細の出荷数量が正しく設定されていることを確認します。

発注の承認後にデータ要素を変更する手順は、次のとおりです（制約がある（許可されない）場合）。

1. 「受注」ウィンドウにナビゲートします。

2. 受注および受注明細を社外ソース品目、数量10で入力します。

3. 受注を記帳します。

4. 購買リリースが自動的に実行されます。購買リリースが遅延される場合は、WF項目タイプ受注管理明細（OEOL）のワークフロー・バックグラウンド・プロセスが実行されます。

5. 受注数量を20に変更します。

6. 購買依頼インポートを実行し、購買依頼の受注数量が20であることを確認します。

7. 受注明細の受注数量を30に更新し、変更内容を保存します。Purchasingで購買依頼数量が変更されていることを確認します。「追加明細情報」ウィンドウの「直接納入」タブを選択します。

8. 変更されている場合は、「直接納入」タブにステータスが表示されます。

9. 購買依頼から発注を作成します。

10. 受注明細の受注数量を40に更新し、変更内容を保存します。発注明細の数量が40に変更されていることを確認します。「追加明細情報」ウィンドウの「直接納入」タブを選択します。

11. 発注を承認します。

12. 今度は受注数量を50に変更し、保存します。関連する発注が承認済であるため、受注を変更できないことを示すメッセージが表示されます。

13. この手順は、Order ManagementおよびPO間で通信されているすべてのデータ要素（出荷先事業所など）で繰り返すことができます。

発注の承認後にデータ要素を変更する手順は、次のとおりです（制約がない（許可される）場合）。

1. 受注数量の増加、出荷先事業所および出荷指示の変更に関する制約を使用不可にします。

2. 前述の手順の受注を問い合せます。

3. 受注数量を50に変更し、出荷先事業所および出荷指示を変更して保存します。変更は正常に保存されます。

4. 発注の数量、出荷先事業所、出荷指示が変更されていること、および発注ステータスが「再承認が必要」に設定されていることを確認します。

5. 発注を再承認し、変更した発注を印刷して受注データ要素を確認します。

6. この手順も、Order ManagementおよびPurchasing間で通信されているすべてのデータ要素で繰り返すことができます。

シード・データ: 制約

制約

直接出荷受注明細（ソース・タイプがEXTERNAL）に対して新規制約が追加されています。この制約は、ビジネス・ニーズによっては削除/使用不可にできます。

直接出荷処理

前提条件

1. 受注管理取引タイプを作成済で、その取引タイプを直接出荷がサポートされている受注ワークフローと明細ワークフローにリンクしていることを確認してください。

2. 受注管理のプロファイル・オプション「OM: 展開品目凍結方法」が適切に設定されていることを確認してください。導入詳細によっては、その他のアプリケーション・プロファイル・オプションが、直接出荷受注明細の処理に影響を与える場合があります。

3. Oracle Workflowバックグラウンド・エンジンが実行されていることを確認してください。

4. 直接出荷の実行に使用するすべての直接出荷事業所で、出荷先サイトと受入サイトが定義されていることを確認してください。

5. 直接出荷顧客に対して内部出荷先事業所を定義していることを確認してください（Oracle Receivablesの「顧客-標準」ウィンドウ、「使用目的登録詳細」タブ）。

6. 標準品目に対して、関連する定価が発注在庫組織内に定義されていることを確認してください（Oracle Payablesの「会計オプション」ウィンドウ、「仕入先-購買」タブ）。

   ATOモデルの場合は、モデルとそのオプション区分とオプションが購買対象であり、かつ購買可能であることを確認し、『Oracle Configure To Orderインプリメンテーション・マニュアル』の設定の章で定義されている購買設定ステップに従ってください。

7. 必要に応じて、受注明細の「ソース・タイプ」フィールドのデフォルト値を設定するデフォルト・ルールを使用可能にしていることを確認してください。フィールド「ソース・タイプ」に対するデフォルト・ルールは、品目属性「デフォルト出荷組織ソース・タイプ」を使用して、受注明細の「ソース・タイプ」フィールドの値をデフォルト設定します。

注意: 元帳間の直接出荷取引または会社間取引を使用する場合は、「元帳間の直接出荷および変更管理の概要」の項を参照してください。

標準品目の直接出荷の追加詳細

予定出荷日

標準品目の直接出荷を実行すると、Order Managementは、購買リリース・ワークフロー・アクティビティの完了後に予定出荷日を戻します。

受注明細属性「ソース・タイプ」のカスケード

モデル、キットおよび構成の直接出荷の追加詳細

ATOモデルまたはキットの場合、「デフォルト出荷組織ソース・タイプ」属性は、モデルからモデル内のすべての品目に継承されます。PTOモデルの場合、「デフォルト出荷組織ソース・タイプ」属性は継承されません。

受注明細の「ソース・タイプ」フィールドのデフォルト設定ロジックおよびカスケード・ロジックは、次のとおりです。

ATO構成に属する受注明細の場合:

• 最上位ATOモデルに対するソース・タイプの値は、デフォルト・ルールに基づいてデフォルト設定されます。

• 構成に新規オプションが追加されるとき、Order Managementは、最上位ATOモデル明細から（追加される新規受注明細に対する）ソース・タイプの値をデフォルト設定します。

ソース・タイプの値を変更する場合は、モデル明細の値を変更する必要があります。この変更は、Order Managementによって、モデルのすべての子明細に対するソース・タイプ値にカスケードされます。また、Order Managementでは、オプション/区分または構成品目レベルではソース・タイプは変更できません。受注明細ワークフローの特定のチェック・ポイントをすぎるとソース・タイプ値を変更できないというルールもあります。

SMC以外のPTO受注明細の場合

• SMC以外の構成部品のデフォルト・ソース・タイプは、デフォルト・ソースから設定される場合があります。

• 受注明細ワークフローの特定のチェック・ポイントをすぎるとソース・タイプ値を変更できないというルールもあります。

Order Managementは、SMC以外のPTOモデルおよび関連する子明細に対しては、ソース・タイプの値をカスケードしません。

ソーシング

PTOモデル（SMC PTOを除く）の下の個別明細は、モデル、区分またはキットの下に展開品目がある受注明細も含めて、受注明細のソース・タイプ、Planningの品目属性「生産/購買タイプ」、およびこれらの各品目またはモデルに対するソース・ルールに基づいてソースが指定され、個別の仕入先から直接出荷されます。

PTOモデルの一部に内部のソースを指定することもできます。出荷モデル完了以外のPTOモデル内の受注明細をいくつか内部ソース指定し、残りを外部ソース指定した場合は、Oracle Global ATPが使用されて内部ソース指定された明細の予定が作成されますが、直接出荷受注明細の予定出荷日は、常に直接出荷明細の要求日からデフォルト設定されます。

スケジューリング

• ATOモデルの直接出荷を実行すると、Order Managementは、受注明細予定作成ワークフロー・アクティビティの一環として、要求日と同じ予定出荷日を戻します。

  Oracle Global ATPは、外部のソースが指定された明細の予定作成には使用されません。要求日を変更した場合、変更は出荷予定日には反映されないため、予定出荷日を手動で変更する必要があります。

• ATOモデルおよび関連する子明細の予定作成機能を完了するには、倉庫が必須です。

変更受注通知

Order Managementの変更受注通知機能は、外部ソースのATO品目またはモデルの直接出荷に対しては機能せず、受注変更に関する通知は送信されません。Order Managementの受注と発注の差異レポートを使用して、当初の受注と関連する発注の差異を確認し、適切な処理を実行してください。

モデル、キット、あるいはモデルまたはキットの構成部品が含まれる受注明細に対して受注変更または取消が行われた場合は、構成のリンクが解除されます。

直接出荷の受注明細を取り消す場合は、明細に対する受入が作成されていないことを確認する必要があります。

一部の受入が作成されると、受注に対して分割明細が作成され、出荷されない残りの数量は、新規のバックオーダー分割明細の数量になります。外部ソースのATOモデルは、その構成の一部または全体が受け入れられると、変更できなくなります。ただし、バックオーダー受注明細については、受注明細が受け入れられていない場合は取消が可能です。

注意: 残余モデル明細およびその子明細には、カスケードおよび構成の検証はありません。ユーザーが残余明細に対して変更を行うと、その残余明細は標準明細であるかのように扱われます。

直接出荷に対するPTO残余

現在のリリースのOrder Managementでは、内部ソースと外部ソースの受注明細が混合している受注がある場合は、混合PTOモデルに対するいずれかの受注が出荷されるかまたは受け入れられると、モデルは残余になります。

混合受注明細が含まれるPTOモデルを処理するには、PTOモデルの全明細が出荷されたときにPTOモデルを請求できるように、ヘッダー・レベルの請求を使用可能にするか、または履行セットを使用する必要があります。ヘッダー・レベルの請求では、受注明細がすべて請求可能になるまで個別の受注明細の請求はできません。また、履行セットを使用すると、受注明細がすべて履行待ちワークフロー・サブプロセスに進むまで受注を履行できません。

購買依頼インポート/購買リリース

購買リリース受注明細ワークフロー・アクティビティを使用すると、ATO品目、構成品目およびSMC以外のPTOの出荷可能構成部品に対して購買依頼を作成できます。

購買依頼インポートおよび購買リリース時に定価がデフォルト設定される方法の詳細は、『Oracle Purchasingユーザーズ・ガイド』を参照してください。

請求

完了モデルおよびキットのみを請求する場合は、ヘッダー・レベルの請求を使用するか、または構成（モデルまたはキット）の全明細を履行セットに手動で入れてください。履行セットまたはヘッダー・レベルの請求が使用されない場合は、Order Managementの機能によって、受注に対する最初の出荷可能構成部品（明細）の出荷後すぐに出荷不可明細の請求が可能になり、残りの受注明細は出荷されるときに請求されます。

検証

• ATO構成のオプションまたは区分に対するソース・タイプ受注明細属性は変更できません。

• Order Managementは、外部ATOモデルの下の全受注明細に対して購買可能品目属性が設定されていること（チェック・ボックスが選択されていること）を検証します。

• SMCモデルに対する受注明細は直接出荷できません。

• 外部ソースのATOモデルは、その構成の一部または全体が受け入れられると、変更できなくなります。

ワークフロー

• モデルまたはATO品目のソース・タイプが「外部」の場合は、ソース・タイプ分岐アクティビティが、ATO品目および作成（ATOモデルの場合）にそれぞれ分岐し、直接出荷の分岐には進みません。

• 構成品目およびATO品目の場合、CTOの「供給の作成 - 明細」サブプロセスがソース・タイプ品目属性を検証し、その値が「外部」の場合は、Order Managementの購買リリース・ワークフロー・アクティビティが、Oracle Purchasingの購買依頼を自動作成します。

• PTOまたはATOモデルの出荷不可構成部品のソース・タイプが「外部」の場合、Oracleの購買リリース・プログラムは、これらの品目のレコードをOracle Purchasingのインタフェース表に挿入しません。かわりに、結果を「購買適用不能」に設定することによって、これらの品目の明細ワークフローは次のワークフロー・アクティビティに進められます。

  直接出荷受注のサンプル・フロー

標準品目の直接出荷

1. 直接出荷品目に対する受注を入力します。

2. 受注を記帳します。

3. 購買依頼インポートを実行します。

4. 購買依頼から発注を作成します。

5. 発注を承認します。

6. 発注を受け入れます。

   ATOモデルの直接出荷先行フロー

   1. 直接出荷されるATOモデルに対する受注を入力します。

   2. オプションを選択します。

   3. 受注の予定を作成し、記帳します（全明細に対して、予定日は要求日にデフォルト設定します）。

   4. 受注のATOモデル明細の処理を進めるか、構成の自動作成バッチ・プロセスを実行して、構成品目を作成します。

   5. 受注および明細のステータスを検証します。

   6. 構成品目明細の処理を進め、自動作成直送オーダー・バッチ・プロセスを実行して、供給オーダー（直接出荷購買依頼）を作成します。

   7. Oracle Purchasingの購買依頼インポートを実行して、購買依頼を作成します。

   8. 購買依頼に対する発注を作成します。

   9. 発注を承認します。

   10. 発注を受け入れます。

   ATO品目の直接出荷先行フロー

   1. 直接出荷されるATO品目に対する受注を入力します。

   2. 受注の予定を作成し、記帳します（全明細に対して、予定日は要求日にデフォルト設定します）。

   3. 構成品目明細の処理を進め、自動作成直送オーダー・バッチ・プロセスを実行して、供給オーダー（直接出荷購買依頼）を作成します。

   4. Oracle Purchasingの購買依頼インポートを実行して、購買依頼を作成します。

   5. 購買依頼に対する発注を作成します。

   6. 発注を承認します。

   7. 発注を受け入れます。

   直接出荷される標準オプションを含んだSMC以外のPTOモデル

   1. PTOモデルに対する受注を入力します。

   2. オプションを選択します。構成部品のソース・タイプはデフォルト設定されます。

   3. 受注の予定を作成し、記帳します。

   4. 購買依頼インポートを実行して、購買依頼を作成します。

   5. 購買依頼に対する発注を作成します。

   6. 発注を承認します。

   7. 発注を受け入れます。

      関連項目

      直接出荷の概要

      受注のコピー

      受注インポート

      「元帳間の直接出荷および変更管理の概要」の追加サンプル・フローを参照してください。

      購買品目の必須設定の詳細は、『Oracle Purchasingユーザーズ・ガイド』、『Oracle Inventoryユーザーズ・ガイド』および『Oracle Configure To Orderインプリメンテーション・マニュアル』を参照してください。

直接出荷受注の変更管理

Order ManagementとPurchasingの間での拡張された変更管理では、ユーザーが受注を変更すると、購買依頼または発注に対する変更が自動的に起動されます。購買依頼または発注について、文書ステータスが原因で変更を実行できない場合、その変更は拒否され、該当するメッセージが発行されます。

変更管理のもう1つの側面は、購買または仕入先システムに関係します。購買担当は、購買依頼または発注に変更を加えることができ、仕入先システムでも確約日や数量を変更できます。拡張された変更管理では、購買依頼および発注の変更は受注明細と同期化されます。出荷先事業所の変更など、特定の種類の変更は、以前は受注明細と発注の間のリンクが非同期だったために許可されていましたが、現在は制限されます。

注意: 受注と発注の差異レポートには、Order ManagementとPurchasingの間の保留差異が含まれています。発注の差異レポートでサポートされなくなったため、この情報は使用できなくなりました。

受注変更

受注変更は、発注の変更が可能であるかぎりサポートされます。受注明細が、発注に変換されていない購買依頼にリンクされている場合は、購買依頼が新しい変更で更新されます。受注明細が、未承認の発注にリンクされている場合は、発注が更新されます。Purchasingでは、発注は、承認されている場合でも変更できます。承認済発注の変更では、承認プロセスが再起動され、変更は承認される場合と承認されない場合があります。変更が承認されない場合は、CSRに通知が送信されます。発注変更が承認されると、変更された発注が仕入先に送信されます。仕入先のシステムで受注を変更できない場合または商品が出荷済である場合、仕入先はどのような場合でも変更を拒否できます。直接出荷の受注明細の場合は、受注明細がすでに取り消されている場合があるため、問題が発生する可能性があります。仕入先システム内の受注のステータスがシステムで認識されないという問題を処理するために、Order Managementには、使用不可にできる制約が用意されています。これらの制約によって、発注が承認されると受注明細の変更が制限されます。ビジネスおよび仕入先との関係によっては、制約を使用不可にして、受注変更により柔軟性を与えることもできます。ただし、例外を処理する責任もあります。

Purchasingにインタフェースされた直接出荷受注の明細が変更されると、変更管理処理が開始されます。購買依頼インポートが実行されておらず、購買依頼の要求がまだ購買依頼インタフェースにある場合は、インタフェース・レコードが更新されます。受注明細に対する購買依頼または発注が存在している場合、Order Managementは更新されたデータ要素を受け入れ、許容される場合は、購買依頼または発注に変更をカスケードします。同じ処理によって、変更管理/自動承認処理も起動されます。文書ステータスが原因で購買依頼または発注を変更できない場合は、失敗の理由を示したメッセージが発行されます。発注に存在するデータ要素は、購買依頼または発注で直接更新されます。

一部受入があって受注明細が分割されている場合、発注出荷の「直接出荷」タブに表示される受注明細番号は、オープン受注明細を反映して、出荷数量はNULLで表示されます。一方、完全受入があって受注明細がクローズされている場合は、在庫に搬送された数量が出荷数量に反映されます。

単一の受注明細を取り消すと、対応する購買依頼明細では、「取消フラグ」フィールドが「Yes」に、「金額」フィールドが「0」に更新されます。複数の受注明細を取り消すと、購買依頼明細では、「取消フラグ」フィールドが「Yes」に、「取消日」フィールドはシステム日付からのデフォルト設定に、「取消事由」フィールドは入力が必要な状態に、「金額」フィールドは「0」に更新されます。

受注変更は発注に送信され、その後仕入先に送信されます。変更の内容は、次のとおりです。

• 取消

• 要求日または予定日

• 受注数量

• 出荷先所在地

変更は、購買担当または仕入先が実行できます。

仕入先に送信される追加の受注データ要素

拡張された変更管理では、次の受注データ要素が仕入先に送信されます。

• 出荷先顧客名

• 出荷先顧客所在地（サポート済）

• 出荷先担当名

• 出荷先担当電話番号

• 出荷先担当FAX番号

• 出荷先担当Eメール

• 搬送先顧客名

• 搬送先顧客所在地（全所在地情報）

• 搬送先担当名

• 搬送先担当電話番号

• 搬送先担当FAX番号

• 搬送先担当Eメール

• 出荷方法

• 出荷指示

• 梱包指示

• 顧客製品摘要*

• 顧客発注番号

• 顧客発注明細番号

• 顧客発注出荷番号

  顧客製品摘要の導出には、ユーザー品目摘要、顧客品目摘要、一般品目摘要の優先度が使用されます。Purchasingでは、購買依頼表または発注表に受注データ要素は格納されません。かわりに、情報は必要になるたびに受注明細から取得されます。

追加の受注データ要素の変更は、次にリストしたすべての通信モードで仕入先に連絡されます。

• 印刷された受注変更レポート

• 印刷された発注レポート

• FAX発注

• Eメール発注

• EDI 860（発注変更アウトバウンド）

• XML（CHANGE_PO）

• iSupplier Portal

次の受注明細フィールドは、Purchasingに直接インタフェースされ、購買依頼と発注で使用できます: 「出荷先事業所」、「希望入手日」、「受注数量」、「受注数量単位」、「プロジェクト」、「タスク」、「最終品目」、「受注数量2」、「単位2」、「グレード」、「在庫品目」。仕入先に送信される追加のデータ要素は参照用で、購買依頼または発注では保存されません。

受注明細がまだ購買依頼インタフェースにある場合は、すべてのフィールドの変更がサポートされ、レコードはインタフェース・レコード内で更新されます。

購買依頼または発注がすでに作成されている場合は、次のルールが適用されます。

• 受注明細の第1数量（「受注数量」）の更新のみが、Purchasingでの第2数量の同期変更を起動します。

• Purchasingで第2数量（「受注数量2」）が同期化されるのは、受注と購買依頼/発注の間に1対1のマッピングがあり、単位が同じ場合のみです。第2数量が受注と自動的に同期化されない場合、Purchasingでは標準換算に基づいて第2数量が導出されます。つまり、品目が二重単位で管理されている場合、すべての二重単位管理（固定、デフォルト、デフォルトなし）は固定管理で処理され、標準換算が使用されます。

• グレードは、Order ManagementとPurchasingの間で自動的に同期化されません。グレードは、Order ManagementとPurchasingの両方で変更できます。

  Purchasingに渡される出荷方法情報

直接出荷受注の購買依頼には現在、出荷方法が含まれています。Order Managementの出荷方法では、顧客へのパッケージの出荷方法が指示されます。購買依頼に出荷方法が含まれているため、直接出荷仕入先は、顧客が希望する出荷方法がわかるようになりました。たとえば、顧客Aが可能なかぎり早い受注の受取りを希望している場合は、この受注の出荷方法によって、受注の出荷確認を行う担当者は、その受注を翌日航空便で出荷するように通知されます。顧客Bが受注の受け取りを急いでいないことを伝えている場合は、この受注の出荷方法によって、受注の出荷確認を行う担当者は、その受注を陸送で出荷するように通知されます。

直接出荷仕入先に渡される出荷情報

顧客固有の出荷指示は、Order Managementで当初受注が発行されるときに取得されます。この情報は購買依頼およびその後の発注に転送されます。倉庫ベースの出荷では、出荷情報は仕入先出荷指示に変換され、発注出荷指示の一部として仕入先に渡されます。発注情報は、EDI、XML、業界標準のインタフェース要件およびiSupplier Portalに準拠しています。出荷組織は、受注に関するすべての関連顧客情報を使用できます。

受注出荷情報の次のデータ要素は、関連するすべての直接出荷仕入先で使用できます。

• 出荷先顧客名

• 出荷先顧客所在地

• 出荷先顧客担当名

• 出荷先顧客担当名電話番号

• 出荷先顧客担当Eメール

• 搬送先/使用顧客名

• 搬送先/使用顧客所在地

• 搬送先/使用顧客担当名

• 搬送先/使用顧客担当名電話番号

• 搬送先/使用顧客担当Eメール

• 出荷方法

• 出荷指示、梱包指示

• 顧客発注番号、顧客発注明細番号

  注意: 出荷先所在地と搬送先所在地が1つの顧客に対して異なる場合があります。また、出荷先所在地の顧客名が最終的な搬送先顧客名と異なる場合もあります。

  Purchasingでの受注番号とデータ・フィールドの参照

購買担当は、「発注の入力」ウィンドウと「リリースの入力」ウィンドウの両方の「納入」ブロックに追加された新しい「直接納入」タブで受注明細の詳細を参照できます。

Purchasingの「直接納入」タブには、次の受注情報が表示されます。

• 受注番号

• 受注明細番号

• 受注明細受注数量

• 受注明細出荷数量

• 受注明細ステータス

• 出荷先顧客名

• 出荷先顧客担当

• 受注明細ステータス

「購買」ウィンドウまたは「リリース納入」ウィンドウには、「受注の表示」という新しいメニュー・オプションがあります。発注出荷が直接出荷受注明細に関連付けられている購買依頼明細を参照している場合、購買担当は、このオプションを起動して、顧客や出荷詳細などの受注情報を参照できます。

次の新規ステータス詳細を受注の追跡に使用できます。

発注購買依頼申請済

発注購買依頼作成済

発注作成済

発注受入済

購買依頼または発注のステータスは、「追加明細情報」ウィンドウの「直接納入」タブにあります。

購買依頼の変更

購買担当は、直接出荷受注にリンクされている購買依頼の次のデータ要素は変更できません。

• 在庫品目

• 出荷先事業所（POでは搬送先）

• 単位

• 数量

• 希望入手日

• 倉庫（出荷先組織）

• プロジェクトとタスクの情報

また、直接出荷購買依頼は要求者に戻すことができません。通常、購買担当は購買依頼を要求者に戻すことができ、処理は実行されません。購買依頼の分割も購買担当は許可されていません。受注にリンクされている購買依頼は、取り消したり、最終クローズすることはできません。

購買リリース

「購買リリース」プログラムは、適格な直接出荷の受注明細に関する情報をOracle Purchasingに渡します。このプログラムは、「営業単位」パラメータに値を指定して、一度に1つの営業単位に対して実行するか、パラメータを空白のままにして、アクセス権が付与されているすべての営業単位に対して実行できます。コンカレント・プログラムのMOACの詳細は、「コンカレント・プログラムに関する付録」を参照してください。

購買リリースが正常に終了した後、Oracle Purchasingで購買依頼インポートを実行して、処理済の受注明細に対する購買依頼を生成します。

購買リリース・プログラムは、購買リリース・ワークフロー・アクティビティに相当し、設計済のワークフローを使用してすべての明細を購買リリースに適合させてから明細をピックする場合にのみ使用します。シードされているワークフローでは、フローが遅延ワークフロー・アクティビティに到達し、ワークフロー・エンジンによって明細がピックされると、明細の購買リリースが処理されます。

注意: 受注の出荷元の倉庫の所属先が、その受注を作成した営業単位でない場合でも、元帳間の直接出荷機能が付加されたことによって、購買リリースで、倉庫の営業単位で購買依頼が作成できるようになりました。

適格な受注明細への保留の影響

購買リリース・プログラムは、ワークフロー・アクティビティが指定されていないか、または購買リリースのワークフロー・アクティビティが指定されている場合、未リリースの保留がある受注または受注明細は処理しません。Oracle Purchasingにインタフェースする受注または受注明細に対する保留は、削除する必要があります。

eワークフロー・アクティビティ結果

購買リリースには、次のワークフロー・アクティビティの結果があります。

• 適格 -- 受注明細は正常に記帳されました。ソース・タイプは「外部」です。

• 完了 -- 受注明細情報はOracle Purchasingに正常にインタフェースされました。

• 未完了 -- 購買をリリースする十分な情報が受注明細にありません。

注意: 購買リリース・アクティビティが次の理由で完了できなかった場合、「購買リリース」コンカレント・プログラムはエラーではなく警告で完了します。1. その明細が保留中である場合。2. 従業員の設定が正しくない場合。3. 搬送先事業所が無効である場合。4. 品目属性の設定が正しくない場合。

前提条件

このプログラムを使用する前に、次のことを実行する必要があります。

• 外部で履行する明細を含んだ受注を入力および記帳します。

• 受注フロー・アクティビティに定義した他の受注または受注明細の前提条件を満たす必要があります。

発行

「購買リリース」ウィンドウの「名称」フィールドに「購買リリース」と入力するか、または購買リリースの購買依頼インポート要求セットを選択します。

パラメータ

購買リリースには次のパラメータがあります。

受注番号（下限/上限）

受注番号または範囲を選択します。あるいは、全受注の適格な明細でプログラムを実行するには、このパラメータを空白のままにします。

要求日（自/至）

受注要求日の範囲を選択するか、または空白のままにします。

顧客発注番号

顧客から受け入れた発注に対応する番号を選択するか、または空白のままにします。

出荷先事業所

明細の搬送先の最終事業所を選択するか、または空白のままにします。

受注タイプ

特定の受注タイプを選択するか、または空白のままにします。

顧客

受注に関連付けられている顧客を選択するか、または空白のままにします。

品目

特定の品目に処理を制限するか、または空白のままにします。

関連項目

『Oracle Purchasingユーザーズ・ガイド』の購買依頼インポート処理に関する項

直接出荷処理

受注明細のサービス情報の定義

Order Managementを使用すると、受注ワークベンチからサービスを受注できます。受注できるサービスは、現在受注を受けている製品品目のサービス（つまり、即時サービス）や、すでに設置されている製品品目のサービスまたは遅延サービスです。

Order Managementを使用して、次の処理を実行できます。

• 製品明細と一緒にサービス明細の受注。

• 受注インポートを使用したサービス明細とサービス受注のインポート。

• 請求も含めて、アプリケーションが他の受注に対して適用している操作の実行。

• 1つの構成内にあるサービス可能なすべてのオプションに対する一度のサービス入力。

ワークフロー

Order Managementでは、Oracle Workflowを使用してサービス品目タイプのサービス明細を管理できます。サービス明細は予定作成できず、出荷もできません。「ワークフロー割当」ウィンドウを使用すると、これら2つの機能を含まないワークフロー・プロセスをサービス明細に割り当てることができます。また、Oracle Workflowの割当てを使用すると、明細と品目タイプの組合せをワークフロー・プロセスに指定できます。この方法で、ビジネス・ニーズを満たすようにワークフロー・プロセスをカスタマイズできます。

関連ドキュメント: 『Oracle Order ManagementにおけるOracle Workflowの使用 リリース12』

変更の適用

期間に関連する変更をサービス受注明細に適用すると、Order Managementは、その変更を構成内の関連するサービス受注明細に自動的に適用します。個々のオプション明細を直接変更することもできます。1つの構成内の全サービス受注明細について、価格調整と販売実績を同時に入力できます。価格調整と販売実績への変更を適用すると、Order Managementは、構成内の関連するサービス受注明細にその変更を自動的に適用します。個々のオプション明細を直接変更することもできます。

小数以下の数量

Order Managementでは、単位（UOM）を定義せずに数量が1未満のサービス品目を入力して、「受注」ウィンドウに部分的な数量を表示できます。関連項目: 小数以下の数量

パーセント基準の価格設定

Order Managementでは、関連する製品に対するパーセントでサービスの価格設定を構成できます。

出荷

Order Management、ShippingおよびOracle Serviceを使用して、サービス・プログラムの開始と関連製品の出荷を同期化できます。

サービス開始遅延日数は、Oracle Inventoryでのサービス可能製品の定義時に定義できます。サービス開始遅延日数とは、出荷日以後、付帯保証の開始をオフセットする日数です。サポート・サービスの開始日は、出荷日にサービス開始遅延日数を加えた日付になります。終了日は、サポート・サービスの開始日にこの期間を加算して計算されます。これは、付帯保証に適用できますが、延長保証（サービス・プログラム）には適用されません。

支払条件

Order Managementでは、関連する製品とは異なる受注済サービスについて支払条件を指定できます。支払条件は、受注明細ごとに指定できます。

関連顧客

サービスの関連顧客の入力は、次のいずれかの方法でサポートできます。

• サービスを発注している顧客以外の顧客に対して、導入ベース製品を参照する発注サービスをサポートします。

• サービスを発注している顧客以外の顧客に販売した受注明細を参照する発注サービスをサポートします。

システム・パラメータ「顧客関連」（サービス）の値に応じて、異なる顧客へ販売した製品の発注サービスを促進できます。顧客は関連顧客にもできます（パーティ関連ではなくアカウント関連）。

システム・パラメータの値が「単一顧客」の場合、導入ベースで参照されるサービス製品に関連顧客情報を入力できません。受注の詳細は、同じ顧客のみとなります。同様に、参照できる受注明細も、同じ顧客に属する明細のみとなります。

システム・パラメータの値が「関連顧客」の場合、関連顧客は元の顧客が指定した品目へのサービスを発注できます。すなわち、元の顧客とアカウント関連（パーティ関連ではなく）を持つすべての顧客は、元の顧客が指定した、品目を参照するサービスを発注できます。

システム・パラメータの値が「全顧客」の場合、どの顧客に販売した品目についても、サービスを発注できます。

「契約詳細」ウィンドウ

作成された保証の表示方法の詳細は、『Oracle Service Contracts User Guide』を参照してください。

サービス可用性ルール

サービス可用性ルールの使用方法の詳細は、『Oracle Service Contracts User Guide』を参照してください。

受注サービス情報を定義する手順は、次のとおりです。

1. 受注ワークベンチの「明細」タブにサービス品目を入力します。「サービス」タブでは、サービス品目に関するサービス関連列をすべて使用できます。

2. 「明細品目、サービス」タブ・リージョンにナビゲートします。

3. サービス参照タイプを定義します。

   サービス参照タイプには、受注と顧客製品の2種類があります。

   受注では、「サービス参照受注番号」フィールドの値リストは次の列で構成されます。

   • 受注番号

   • 受注タイプ

   • 顧客番号

   • 顧客名

   顧客製品では、「サービス参照顧客製品」フィールドの値リストは次の列で構成されます。

   • 製品:シリアル番号:参照番号

   • 摘要

   • システム

   • 顧客番号

   • 顧客名

4. サービス受注タイプを定義します。

5. サービス参照タイプが受注の場合は、サービス参照受注番号とサービス参照明細番号を定義します。

6. サービス参照タイプが受注の場合は、サービス参照出荷番号とサービス参照オプション番号を定義します。

7. サービス参照タイプが顧客製品の場合は、サービス参照顧客製品名とサービス参照システム名を定義します。

8. 「サービス同時終了フラグ」チェックボックスを選択して、このオプションを有効または無効にします。

   「サービス協調終了」フィールドを使用して、特定の顧客に販売されたり、特定のシステムにグループ化された全サービス・プログラムに対して同じ終了日を設定します。詳細は、『Oracle Service Contracts User Guide』を参照してください。

9. サービス開始日とサービス終了日を定義します。

   「サービス開始日」フィールドと「サービス終了日」フィールドによって、サービス・プログラムの開始日と終了日が決まります。

10. サービス継続期間とサービス期間を定義します。

    「サービス継続期間」フィールドには、サービス・プログラムの継続期間を入力します。このフィールドまたは「サービス終了日」フィールドのいずれかに入力する必要があります。

    「サービス期間」フィールドには、サービス・プログラムの期間を日、月、年などで入力します。

11. 受注についての取引事由と追加の取引注釈を定義します。

12. 作業内容を保存します。

注意: この機能は「クイック受注」ウィンドウでも利用できます。

サービス終了の概要

サービス品目は、通常、拡張保証などのサービスを提供する基本契約として定義されます。サービス品目の終了機能や顧客へのクレジット承認機能は、多くの業界で一般的なビジネス要件になっています。

Order Managementは、履行ワークフロー・アクティビティ（明細の履行）を介してサービス契約にインタフェースします。このアクティビティによって、サービス契約インタフェース表が移入されます。インタフェース・レコードを処理するには、サービス契約受注処理コンカレント・プログラムを実行する必要があります。

サービス可能品目がクレジットのために返品されたとき、顧客に延長保証がクレジットされるかどうかは、プロファイル「OKS: IBインスタンス終了のためクレジット・メモをあげる」の値によって決まります。また、発行されるクレジット金額は、グローバル契約のデフォルト設定によって決まります。この金額は、ワークフロー・アクティビティ「受注明細の設定 - サービス実績」を介してサービス可能品目返品明細レベルで上書きできます。このアクティビティを使用して、service_credit_eligible_codeの値を「完全」、「按分済」または「なし」に設定できます。

サービス終了の主な機能

製品の返品時にサービス品目を終了する機能

サービス品目は、製品が返品されたときに終了できます。サービス契約でサービスが終了したときに、サービスに対してクレジットを発行するかしないかは、ソース取引（RMA）で判断します。

OMでは、クレジットのために返品された製品を処理した時点で、RMA明細のサービス・クレジットの認定が自動的に実行されます。現在、OMにクレジットのために製品が返品されると、Install Baseが、品目インスタンスの所有者を社内組織に変更し、Service Contractsをコールして、製品に関連付けられている保証および拡張保証も終了します。さらに、Install Baseでは、OM内の製品品目を参照して、その製品品目に対するサービスの終了によって、クレジットを発行するかどうかを決定します。

サービス明細に対する全クレジットまたは分割クレジットの発行

インディケータには、返品明細（製品品目）のサービスに対して全クレジット（100%）を発行するように表示されます。これは、Oracle Service Contractsのプロファイル・オプションとして最初に導入された管理で、職責レベルまたはサイト・レベルで設定できます。Oracle Order Managementでは、Order Management、Install BaseおよびService Contracts間の既存の統合を使用してサービスを終了します。サービスの終了の詳細は、『Oracle Service Contracts User Guide』を参照してください。

ユーザー・プロシージャ

サービス終了を設定する手順は、次のとおりです。

Service Contractsアプリケーション内でサービス明細のすべてまたは一部のクレジットに対してプロファイル・オプション「OKS: 返品の全クレジット」を設定します。このプロファイル・オプションはサイト・レベルで設定できます。

製品が参照のあるクレジットのみ返品対象となる場合に、サービス品目を終了する手順は、次のとおりです。

1. 「受注」ウィンドウにナビゲートします。

2. 顧客名、受注タイプ = 返品または混合など、ヘッダー情報を入力します。

   注意: 受注カテゴリが「返品」または「混合」で、返品フローのある明細タイプを持つ受注タイプを設定する必要があります。Order Managementでは、受注タイプ/明細タイプはシードされません。

3. 明細品目の数量全体を返品にしない場合は、明細上で数量を減らします。

4. 「明細品目」タブで、製品品目番号を入力して「返品」タブをクリックし、「明細タイプ = クレジットのみ返品」と入力します。「参照」フィールドをクリックし、「参照タイプ = 受注」と入力し、受注番号と明細番号を入力します。返品事由を入力します。返品明細の導入詳細も入力します。

5. 返品を記帳します。

6. Order Managementの「履行」ワークフロー・アクティビティがバックグラウンドで実行され、製品明細の処理が続行されます。

7. Order Managementの「導入ベース・インタフェース」がバックグラウンドで実行され、製品明細の処理が続行されます。

8. サービス品目の返品時に、Install BaseはIB取引タイプに基づいて関連サービス契約明細を終了させます。IBでは、Service Contracts APIが終了日に基づいてクレジットを自動的に按分したり、プロファイル設定に基づいてクレジット全体を発行できます。これは自動化されたフローであり、手動によるクレジット金額の上書きはできません。サービス明細はService ContractsアプリケーションからARにインタフェースされ、OKSで別個のクレジットが発行されます。

9. 製品明細は、Order Managementの「請求インタフェース」ワークフロー・アクティビティに進みます。このアクティビティはバックグラウンドで実行され、Oracle Receivablesは請求処理のために製品明細を取り出して、その明細に対するクレジットをOrder Managementで発行します。

受注明細のプロジェクト製造情報の定義

Order Managementでは、資材と労務の計画、スケジュール、処理および原価計算を特定の顧客契約に対して行うことができます。「受注」ウィンドウを利用して、受注明細に関するプロジェクトとタスクの情報を取得できます。

注意: 「プロジェクト」フィールド内でプロジェクトを選択できるようにするには、Oracle Project Manufacturingを完全にインストールする必要があります。

プロジェクト製造情報を定義する手順は、次のとおりです。

1. 「受注」ウィンドウの「明細品目、その他」タブ・リージョンにナビゲートします。

2. プロジェクト番号を選択します。

   Oracle Inventoryで、倉庫のプロジェクト管理レベルが「プロジェクト」に設定されている場合は、記帳前にプロジェクト番号を入力します。

3. タスク番号を選択します。

   Oracle Inventoryで、倉庫のプロジェクト管理レベルが「タスク」に設定されている場合は、プロジェクトの選択時にタスク番号を入力する必要があります。

4. 最終品目ユニット番号を選択します。

   モデル品目ユニット番号または最終品目ユニット番号は、部品構成の識別に使用されます。部品の構成を変更したり、親構成部品との関係を特定の効果のために変更することができます。

プロジェクトとタスクのカスケード

プロジェクトとタスクの変更が最上位のモデル・レベルで指定されると、最上位モデルのすべてのオプション明細にそれらの変更が自動的にカスケードされます。ただし、ATO半組立品の場合には、プロジェクトとタスクの変更は、該当するプロジェクト・レベルまたはタスク・レベルで指定されたときに、カスケードが可能になります。

たとえば、ATO半組立品が最上位モデルのオプションである場合もあります。他のオプションへのプロジェクトおよびタスクの変更は許可されません。

受注のカスタマイズ

「メイン」および「その他」の受注ヘッダー情報の定義

「メイン」の受注明細品目情報の定義

受注明細の出荷情報の定義

受注明細の所在地情報の定義

受注明細の返品情報の定義

受注明細のサービス情報の定義

受注明細のプロジェクト製造情報の定義

受注明細のリリース管理情報の定義

『Oracle Project Manufacturingユーザーズ・ガイド』および『Oracle Project Manufacturingインプリメンテーション・マニュアル』

受注明細のリリース管理情報の定義

Order Managementでは、出荷が承認されていない需要に対する変更を管理できます。需要は、計画日付に出荷するように計画できますが、需要に対する保留削除などの承認イベントが発生するまで、顧客には発送されません。承認は、ワークフロー通知に応答することによって開始できます。また、出荷承認済需要に対する数量や日時などの属性も変更できます。

タイムスタンプ

要求日、予定日および確約日を含めて、すべての日付フィールドにタイムスタンプを付けることができます。要求日は、出荷日または搬送日のいずれかを示します。

構成

Order Managementでは構成済の受注を変更できます。ATOおよびPTO出荷モデル完了構成の場合、関連する全明細のステータスは、親モデル明細のステータスと同じになります。たとえば、親モデル明細が「出荷未承認」ステータスの場合、出荷セット内の構成で関連する全明細は、同じ「出荷未承認」ステータスになります。

処理制約

指定した処理の実行後、指定したユーザーが需要の属性を変更できないように制限できます。たとえば、需要がすでに出荷済の場合は、ユーザーによる受注数量の変更ができないように制限できます。受注管理の処理制約は受注の変更に適用できる他に、インタフェースされた需要明細にも適用できます。

顧客品目の相互参照

社内品目番号または顧客品目番号のいずれかを使用して、受注明細の相互参照の問合せ、表示、入力およびレポート作成を行うことができます。受注を表示するとき、または受注のレポートを作成するときに、顧客品目の相互参照を表示できます。顧客部品番号を指定して、受注または明細を検索できます。

現在需要の表示

受注の検討時に、クローズ済の受注明細を除外できます。「受注の検索」ウィンドウで受注を検討するときは、全明細、オープン受注明細のみ、またはクローズ明細のいずれかを表示できます。また、オープン受注明細がない受注を表示できます。

オープン受注明細がない受注をオープンしたままにするか、またはクローズするかを指定できます。また、明細のクローズや受注のクローズなどのアクティビティに保留を定義できます。オープン受注明細がない受注がクローズされるのを防ぐため、このようなアクティビティに特定の保留を適用できます。

記帳済明細の削除

Order Managementは、記帳済明細の削除をサポートしています。ただし、請求済またはピック・リリース済の受注の明細は削除できません。

取消

数量の更新は、属性の増分/減少に基づいて処理されます。受注処理によって受注明細が更新され、違反をチェックするためのセキュリティ検証が実行されます。受注は即時にコミットされるため、リリース管理では、受注明細すべてが処理されるか、まったく処理されないかのいずれかになります。

受注パージ

クローズ済でリリース管理されている受注が、受注パージ基準をすべて満たしている場合はパージできます。

注意: 受注パージ機能は、Oracle Order Managementで提供されています。「受注パージ」コンカレント・プログラムを使用すると、選択したクローズ済受注とそのワークフロー履歴をパージできます。

リリース管理情報を定義する手順は、次のとおりです。

1. 「明細品目」タブ内の「その他」タブ・リージョンにナビゲートします。

2. 顧客製造オーダーを入力します。

   注意: 顧客製造オーダーの機能を使用する顧客は、スキーマのOE_ORDER_LINES_ALL表のCUSTOMER_JOB列にカスタム索引を作成する必要があります。

3. 顧客生産ラインを入力します。

4. 品目のモデル・シリアル番号を入力します。

5. 品目を搬送する顧客ドックを入力します。

6. 中間出荷先事業所を選択します。

7. RLM（リリース管理）スケジュール・タイプを入力します。

8. 作業内容を保存します。

受注入力の必須フィールド

次の表は、受注の入力時または記帳時に値の入力が必要なフィールドを示します。この作業は、デフォルト・ルールに従って情報をデフォルト設定したり、「受注」ウィンドウに値を入力したり、既存の受注または返品からデータをコピーしたり、受注インポートを使用して値を入力します。必須の値を入力済またはデフォルト設定済の場合、受注明細を含まない受注を記帳できます。

関連項目

受注のコピー

受注インポート

「受注情報」の「メイン」タブ・リージョン

次の表に、ウィンドウの「メイン」タブ・リージョンから利用可能で、受注または返品の場合に値の指定を必要とする「受注ヘッダー」属性を示します。

受注明細

次の表に、受注明細ウィンドウから利用可能で、受注または返品の場合に値の指定を必要とする「受注明細」属性を示します。

「受注」ウィンドウの「明細」タブでの受注明細のソート

「受注」ウィンドウの「明細」タブに表示された受注明細または返品明細を、指定した基準に基づいてソートし、受注番号（デフォルト）の順に受注明細または返品明細を表示することができます。

受注明細または返品明細をソートするときには、1つ、2つまたは3つの受注属性を選択してソートを実行できます。1つの属性ごとに昇順または降順をそれぞれに指定できます。デフォルトのソート順序クオリファイアは昇順です。

さらに、対応するチェック・ボックスを選択して、クローズ済または取消済の受注明細を非表示にします。「クローズ済」チェック・ボックスまたは「取消済」チェック・ボックスのいずれかを選択した場合、ソートが完了するとクローズ済または取消済受注明細は表示されません。

「受注」ウィンドウの「明細」タブで受注明細をソートする手順は、次のとおりです。

1. 「受注」ウィンドウの「明細」タブにナビゲートします。

2. 「フォルダ」メニューから「データのソート」を選択します。

   「受注明細ソート基準」ウィンドウ

   

3. 受注明細または返品明細をソートするために、1つ以上の受注属性を選択します。1つ、2つまたは3つの受注属性を組み合せたソートを指定できます。

   ソート・キー・フィールドで最初のソート順の属性を選択します。さらに2番目のキーおよび3番目のキー・フィールドに受注明細属性を追加指定することができます。すべてのソート・フィールドの値リストは、データベース・ビュー定義内の受注属性、OE_ORDER_LINES_Vに基づいています。

4. 選択された各受注明細属性について、ソート順を指定します。

   • 昇順: 受注明細を昇順（小さな値から大きな値の順序で）で表示します。

   • 降順: 受注明細を降順（大きな値から小さな値の順序で）で表示します。

5. 「クローズ済」チェック・ボックスまたは「取消済」チェック・ボックスのいずれかを選択してソートするとき、クローズ済または取消済の受注明細のみを表示するように選択します。「クローズ済」チェック・ボックスおよび「取消済」チェック・ボックスの初期値は、プロファイル・オプション「OM: クローズ済明細の表示」および「OM: 取消済明細の表示」の値によってそれぞれ決まります。

6. 「OK」をクリックして受注明細のソートを開始するか、「取消」をクリックして受注明細ソート・ウィンドウをクローズします。

受注の記帳

受注の記帳とは、受注入力プロセスが完了し、顧客が受注を約定したことを示します。受注または返品が次のワークフロー・アクティビティに進むには、記帳を行う必要があります。

注意: Order Managementでは、受注に対して受注明細を1つも定義せずに受注を記帳できます。

受注を記帳する手順は、次のとおりです。

1. 「受注」ウィンドウにナビゲートします。

2. 新規受注のヘッダーと明細レベル情報を入力するか、既存の受注を問い合せます。

3. 「受注の記帳」をクリックします。

   記帳では、受注に必要なすべてのフィールドが入力されているかどうかが検証されます。必須フィールドの詳細は、受注の必須フィールドに関する項を参照してください。検証に成功すると、受注が記帳されたことを示す確認メッセージが表示され、受注は次のワークフロー・アクティビティに進みます。検証に失敗すると、検証の失敗に関するメッセージが「プロセス・メッセージ」ウィンドウに表示されます。次のことを選択できます。

   • 「続行」または「取消」の選択 - ウィンドウが閉じ、制御が受注フォームに戻されます。

   • 「メッセージの保存」の選択 - メッセージが保存され、後で「プロセス・メッセージ」ウィンドウを使用して問い合せることができます。

   • 「通知」の選択 - 通知ウィンドウが表示され、選択した職責に通知を送信できます。

     注意: 記帳は、1つの受注の全受注明細に対して同時に実施されます。同じ受注内の明細の一部を記帳したり、未記帳にすることはできません。

     注意: 記帳済の受注は、（定義されている処理制約によって）変更が可能な場合があり、新しい受注明細が追加される場合があります。記帳済の受注に受注明細が追加されると、その受注の保存時に受注全体が記帳の検証の対象になります。

     注意: 記帳後にATOモデルを進行させる（構成品目を作成する）場合、会計期間にデフォルト設定のルールが存在していることが必須となります。標準品目およびPTOモデルの場合、これは必須ではありません。

関連項目

記帳

『Oracle Order Management Suiteインプリメンテーション・マニュアル』のOracle Payments処理に関する項

顧客の追加

受注の「ツール」メニュー

受注のコピー

受注インポート

注意: Oracle Order Managementでサポートされるのは、ここに記載されている受注カスタマイズのみです。

例外管理

「プロセス・メッセージ」ウィンドウに保存されているワークフロー・エラーを表示して、訂正できるようになりました。記録されている各メッセージにはステータスが関連付けられています（シードされている値は「オープン」または「クローズ」です）。

様々な取引**ウィンドウには、未解決のエラーへのダイレクト・ナビゲーションが用意されており、エラー状態のワークフロー・アクティビティを再試行できます。再試行に成功すると、オープン・メッセージは自動的にクローズします。

新しいワークフロー・エラー処理プロセスによって、ワークフローの標準機能を使用するOrder Management固有の通知が生成され、この通知の受取者は、エラー状態のアクティビティを再試行できます。また、ワークフローでは、問題のある受注または明細の診断情報が自動的に生成されます。

アクティビティのエラーの原因となっている問題すべてを修正するためには、エラーの修正とアクティビティの再試行を数回繰り返す場合があります。この機能には、Oracleサポートでの問題解決の手助けとなるエラーおよび対応する診断情報の記録も含まれています。

** - 受注、営業基本契約およびオープン・インタフェース・トラッキング

主な機能

強化されたワークフロー・アクティビティ・エラーの表示

特定のワークフロー・アクティビティで発生したエラーは、様々な取引ウィンドウから直接問い合せて表示できます。たとえば、「受注」ウィンドウの「明細」タブにカーソルをあわせると、特定の明細のエラーのみが表示されます。

未解決のエラーを直接表示できるウィンドウは、次のとおりです。

• 受注

• 受注オーガナイザ

• クイック受注

• クイック受注オーガナイザ

• 営業基本契約

• オープン・インタフェース・トラッキング

メッセージ・ステータスが挿入されたメッセージ

• エラー・メッセージには、「オープン」ステータスの修正処置を識別するためにステータス（オープン/クローズ）が関連付けられています。

• 各メッセージに使用できるステータスは拡張可能で、独自のステータスを追加できます。カスタム・ステータスは「オープン」ステータスと同様に処理されます。

• アクティビティを再試行すると、クローズしていないエラー・メッセージは自動的にクローズします。

• 「メッセージのパージ」コンカレント・プログラムは、ステータスをパラメータとして受け取ります。

エラー状態のアクティビティの再試行

再試行は、前述したウィンドウの「処理」ボタン、（マウスの右クリック機能が使用可能な場所で）マウスの右クリック、およびワークフロー通知から使用できます。クローズしていないエラー・メッセージは、アクティビティが再試行されて正常に完了すると、自動的にクローズします。

Order Management固有のワークフロー・アクティビティ・エラー処理

• プロファイル・オプション「OM: エラー・アクティビティの診断の生成」が「Yes」に設定されている場合は、ワークフロー・アクティビティがエラーになると、新しいエラー処理プロセスによって「診断: OM受注情報」コンカレント・プログラムが自動的に起動されます。コンカレント・プログラムの出力には、ワークフロー・エラー・メッセージとワークフロー・アクティビティ・スキップ情報が含まれているため、問題のある受注を簡単にデバッグできます。

• 新しいエラー処理ワークフローでは、通知に要求IDが配置され、プロセス・メッセージに表示されるメッセージと要求IDが追加されます。コンカレント・プログラムの出力を検索し、その出力を、エラーを解決できないアクティビティについてOracleサポートでTARを記録する場合のサポートに提供できます。

• エラー処理フローは、受注ヘッダー、受注明細、交渉、営業基本契約および電子メッセージの各ワークフローに関連付けられています。

  次の機能は、機能セキュリティによって保護されています。

• オープン・メッセージの表示: この機能は、デフォルトで、すべてのユーザーが使用できます。

• エラーのアクティビティを再試行: この機能は、デフォルトで、すべてのユーザーが使用できるわけではありません。これは、ワークフロー・アクティビティの再試行を、すべてのユーザーに対しては許可しない場合があるためです。システム管理者は、この機能を有効化する前に、例外管理パッチを適用する必要があります。

受注の進行と再試行機能の対比

エラーのアクティビティの再試行処理は、既存の「受注の進行」処理とは異なります。既存の受注管理ワークフロー・プロセスには、ほとんどの機能アクティビティに対して適格なステータスが含まれています（例: 記帳の「記帳に適格」、予定作成の「予定作成に適格」、請求インタフェースの「請求インタフェースに適格」など）。予期したエラーのためにアクティビティがエラー状態となった場合はそのワークフローが適格な状態まで戻るため、修正ステップを実行した後、「受注の進行」処理を手動で選択できます。

一方、予期しないエラーのためにワークフロー自体がエラー状態になった場合は、新しい「エラーのアクティビティを再試行」を使用すると、特定のアクティビティを再試行できます。つまり、受注の進行は適格な状態のアクティビティに適用されるのに対して、「エラーのアクティビティを再試行」はエラー状態のアクティビティに適用されます。

オンライン・ユーザー

ユーザーは、「受注」ウィンドウで受注を進行し、エラー・メッセージをオンラインで受信します。オンライン・ユーザーは、次のことができます。

• オープン・メッセージの表示機能を介して、該当する受注のヘッダーまたは明細のエラーを表示します。この機能は、「受注」、「クイック受注」、「受注オーガナイザ」、「クイック受注オーガナイザ」のウィンドウの「処理」ボタンまたはマウスの右クリックを介して使用できます。

• エラーの修正ステップを実施できます（原因が判明している場合）。

• 「エラーのアクティビティを再試行」機能へのアクセス権が付与されている場合は、「処理」ボタンまたはマウスの右クリック・メニューを介してアクティビティを再試行できます。

管理者

ワークフロー管理者は、新しい受注管理フローによって自動的に送信される通知に基づいて受注を識別し、ワークフロー・アクティビティのエラーに対処できます。この機能はオンライン・ユーザーがいない場合（遅延したワークフロー・バックグラウンド・エンジン処理中のワークフロー・アクティビティ・エラーなど）に便利です。

• ワークフロー管理者は、通知に埋め込まれている受注情報ポータルへのリンクをクリックすることで、受注を表示できます。

• この通知には、受注番号やOrder Managementに固有なその他の情報が含まれているため、ワークフロー管理者は、「受注」ウィンドウで受注を問合せできます。

• ワークフロー管理者は、エラーを表示してそのエラーの修正ステップを実行し、通知に従って直接、または前述の項の説明に従って、アクティビティを再試行できます。

• プロファイル・オプション「OM: エラー・アクティビティの診断の生成」の値が「Yes」に設定されている場合は、「診断: 受注情報」コンカレント・プログラムの出力を、TARを記録する場合のサポートに提供できます。

特定のメッセージ・ステータスのメッセージを使用して受注を確認する手順は、次のとおりです。

受注オーガナイザ/クイック受注オーガナイザを使用すると、特定のステータスのエラー・メッセージを使用して、すべての受注を問合せできます。

• このオーガナイザを使用すると、少なくとも1つの「オープン」ステータスのメッセージが含まれている受注を問合せできます。

この機能は、メッセージ・ステータス・コードの拡張機能と併用することもできます。たとえば、問題を修正できない場合、オンライン・ユーザーは、「オープン」メッセージを他のカスタム・ステータスに手動で変更できます。次に、パワー・ユーザー/管理者は、このカスタム・メッセージ・ステータスに基づいて受注を定期的に問い合せ、詳細な分析が必要な受注を識別できます。

ワークフロー・アクティビティ・エラーとその処理例

次の図は、この新機能を使用してワークフロー・アクティビティのエラーを修正するためのビジネス・フローを表しています。

例外管理のビジネス・フロー

「プロセス・メッセージ」ウィンドウ

オープン・メッセージへのアクセス

受注/明細のオープン・メッセージは、「受注」、「受注オーガナイザ」、「クイック受注」または「クイック受注オーガナイザ」の各ウィンドウから移動せずに直接処理できます。複数のレコードを選択すると、処理は機能しません。

問合せ機能

特定のシード済ステータスまたはカスタム・ステータスのメッセージを少なくとも1つ保持する受注/明細を問合せできます。

メッセージ・ステータスに基づいて受注を検索できます。

「受注オーガナイザ」の「検索」ウィンドウ - 「受注情報」

メッセージ・ステータスに基づいて明細を検索できます。

「受注オーガナイザ」の「検索」ウィンドウ - 「明細情報」

「受注オーガナイザ」ウィンドウ

「オープン・メッセージ」チェック・ボックスは、受注にオープン・メッセージがあるかどうかを示します。

「受注」および「クイック受注」フォームには、明細レベル（「メイン」タブ）にも「オープン・メッセージ」チェック・ボックスがあります。また、このチェック・ボックスは、「受注オーガナイザ」および「クイック受注オーガナイザ」フォームにも表示されます。

注意: パフォーマンス上の理由で、このフィールドが移入されるのは、プロファイル・オプション「OM: プロセス・メッセージ・フラグの表示」の値が「Yes」に設定されている場合のみです。

「受注オーガナイザ」、「受注」、「クイック受注オーガナイザ」、「クイック受注」

「処理」およびマウスの右クリック・メニュー機能には、「要約」リージョンと「明細」リージョンの両方からアクセスできます。

強化された「診断: OM受注情報」コンカレント・プログラム

このコンカレント・プログラムでは、次の情報が表示されます。

• ヘッダー処理メッセージ（すべてのステータス）

• 明細処理メッセージ（すべてのステータス）

• ワークフロー・スキップ情報

• 出荷アクティビティをスキップすると、Order Managementでは、ユーザーID、アプリケーションIDおよび職責IDが記録され、2つのワークフロー通知が送信されます。一方の通知はシステム管理者（SYSADMIN）に送信され、もう一方の通知は出荷アクティビティをスキップした担当者に送信されます。これらの通知は、スキップについて送信者に警告し、今後はアクティビティをスキップしないように助言します。

プロファイル「OM: エラー・アクティビティの診断の生成」が「Yes」に設定されているときに、ワークフロー・アクティビティが予期しないエラーとなった場合は、OMエラー・プロセスによって、このコンカレント・プログラムが自動的に開始されます。

診断コンカレント・プログラムは、対応する受注（受注の作成に失敗した進行発注など）がない電子メッセージ・フローや、営業基本契約フローに対してはトリガーされません。

「メッセージのパージ」コンカレント・プログラム

このコンカレント・プログラムでは、メッセージ・ステータス・パラメータが使用されます。

「メッセージのパージ」コンカレント・プログラム - 「パラメータ」ウィンドウ

注意: パラメータの値は、同じ参照タイプであるONT_MESSAGE_STATUSに基づいています。メッセージ・ステータス・パラメータを「オープン」に設定してこのコンカレント・プログラムを発行すると、「オープン」ステータスのメッセージに加えて、「NULL」ステータスのメッセージもパージされます。

「OMエラー」ワークフロー

Order Management固有の新しいエラー・フローは、アクティビティのエラー時に開始されます。通知には、システム管理者が受注を識別して、エラーの根本原因を見つける際に役立つOrder Management固有の情報（受注番号、受注タイプ、明細番号、組織など）が含まれています。プロファイル「OM: エラー・アクティビティの診断の生成」が「Yes」に設定されている場合は、OM診断コンカレント・プログラムが自動的に発行されます。これには、エラーになった受注または明細に関する、通知から受注情報ポータルへのリンクが含まれています。

「OM標準エラー処理再試行あり」ワークフロー（OMERROR/R_ERROR_RETRY）

この新しいワークフロー・エラー処理は、既存のワークフロー・アクティビティに関連付けられています。関連付けられているワークフロー・パッケージはOE_ERROR_WFです。注意: シードされている通知のタイムアウトは3日間です。エラーがない場合は、この期間の終了時にフローが自動的にクローズします。

「OM標準エラー処理再試行あり」のステップ

検証

注意: 通知の件名は、様々なエンティティに対応するように、次のようになります（受注ヘッダー）。

ワークフロー受注タイプ: 標準、受注XXXX ORA-20001受注明細でのOMエラー

ワークフロー受注タイプ: 標準、受注XXXX、明細1.1 ORA-20001交渉ヘッダーでのOMエラー

ワークフロー受注タイプ: 標準、見積番号XXXX ORA-20001営業基本契約ヘッダーでのOMエラー

ワークフロー受注タイプ: 標準、営業基本契約番号XXXX ORA-20001電子メッセージでのOMエラー

ワークフロー受注ソース: XML、当初システム文書参照: XXXX、顧客: コンピュータ・サービスおよびレンタル ORA-20001でのOMエラー。さらに、電子メッセージでは、受注番号がないケース（たとえば、発注処理で受注の作成に失敗した場合）があります。この場合、これらの情報は通知には表示されません。バージョン番号、フロー・ステータス、OIPへのリンクおよびOM診断要求IDのフィールドはすべて、受注が存在する場合にのみ該当するためです。

また、文書の送信アクティビティ（アウトバウンドXML文書で使用）の場合、アクティビティはXMLゲートウェイが所有し、OMのみが参照します。このように、アクティビティには独自のXMLゲートウェイ固有のエラー処理と通知（ECXERROR）があります。したがって、文書の送信に失敗した場合、システム管理者には前述のOM固有の通知は送信されません。ユーザーは、XMLゲートウェイ通知と同様に、その後も「オープン・インタフェース・トラッキング」フォームからアクティビティを再試行できます。

注意: 「オープン・インタフェース・トラッキング」フォームから文書の送信アクティビティを再試行しても、同じアクティビティに対する以前のエラー通知は自動的には削除されません。このことは、「OM標準エラー処理再試行あり」エラー・ワークフローを使用しない他のアクティビティにも当てはまります。その理由は、このエラー・フローから送信された既存の通知のみが削除されるためです。

「エラーのアクティビティを再試行」コンカレント・プログラム

「エラーのアクティビティを再試行」コンカレント・プログラムを起動することで、複数の受注/明細についてエラー状態にあるワークフロー・アクティビティを再試行できます。次のワークフロー項目タイプがサポートされます。

受注番号を入力すると、ヘッダー・フローと失敗したすべての明細フローが再試行されます。他のパラメータ値はすべて無視されます。項目タイプは必須のため、受注ヘッダーにデフォルト設定されます。受注番号パラメータの値リストには、複数の営業単位の受注番号が表示されます。

このコンカレント・プログラムは、「プレビュー」と「実行」の2つのモードをサポートしています。「プレビュー」モードでは、エラー状態のアクティビティの要約が表示されます。

「実行」モードでは、アクティビティが再試行されます。「プレビュー」モードを使用してエラー状態のアクティビティ数を識別し、「実行」モードを使用してアクティビティを再試行できます。

このコンカレント・プログラムは、エラーのワークフロー・アクティビティを再試行し、再試行の結果とエラー・メッセージを表示します。標準の「要求の発行」ウィンドウに入力した基準を満たすエラー・アクティビティがすべて再試行されます。

「エラーのアクティビティを再試行」コンカレント・プログラムには、後続の「エラーのアクティビティを再試行」コンカレント・プログラムとの間に互換性がありません。このプログラムは同時に2つのインスタンス（受注の予定作成、受注の予約、出荷セットの予定再作成）を実行できません。

エラーのワークフロー・アクティビティの再試行で問題が解決されないケースがあります。このようなケースは、明細出荷ワークフロー・アクティビティはエラーだが、明細の出荷以降に、対応する少なくとも1つの搬送詳細がクローズされた場合に発生します。この場合は、既存の例外管理機能を介してアクティビティを再試行しても常にエラーとなります。

新機能では、例外管理がこのような状況に直面した場合、ワークフロー・アクティビティは再試行されずに、「通知済」に設定されます。

Oracle Workflowステータス・モニターから出荷明細アクティビティを再試行した場合、アクティビティ・ステータスの「通知済」への設定はサポートされません。次の3種類のいずれかの方法を使用する必要があります。

1. 受注オーガナイザ、クイック受注オーガナイザ、「受注」ウィンドウと「クイック受注」ウィンドウの「エラーのアクティビティを再試行」処理、およびOrder Managementエラー通知の再試行機能を使用します。

2. アクティビティ・エラー時に送信されるOrder Managementエラー通知を使用します。

3. 「エラーのアクティビティを再試行」コンカレント・プログラムを使用します。

注意: 「オープン・インタフェース・トラッキング」ウィンドウからの「エラーのアクティビティを再試行」処理の動作と、「営業基本契約」ウィンドウからの「エラーのアクティビティを再試行」処理の動作は同じです。

「エラーのアクティビティを再試行」コンカレント・プログラムへのアクセス権の割当てには注意が必要です。このコンカレント・プログラムはエラーのアクティビティを再試行するため、結果として、Oracle Workflowの表に格納される行数が増加し、不適切または無計画な使用方法によってワークフロー表への過剰な移入が発生し、パフォーマンス上深刻な問題となる可能性があります。プログラムを再発行する前に、コンカレント・プログラムのログ出力に含まれているメッセージを使用して、可能なかぎり多くのエラーを識別して修正してください。また、コンカレント・プログラムは、エラーのアクティビティを再試行せずにエラーの識別に貢献できるように、プレビュー・モードで発行できます。アクティビティがエラーとなる根本原因を識別して修正した場合のみ、そのアクティビティは再試行時に正常に完了します。

また、エラーのアクティビティを再試行する処理およびコンカレント・プログラムでは、エラーのアクティビティを再試行する前に、未解決のWFERRORフローを中断してパージします。

「営業基本契約」フォーム

営業基本契約オーガナイザ

オープン・メッセージへのアクセス

営業基本契約のオープン・メッセージは、「営業基本契約」ウィンドウから移動せずに直接処理できます。

注意: この処理は、最初のフェーズで複数を選択して実行することはできません。

問合せ機能

問合せの対象は、特定のシード済ステータスまたはカスタム・ステータスのメッセージを少なくとも1つ保持する営業基本契約です。

営業基本契約オーガナイザ

「オープン・メッセージ」チェック・ボックスは、クローズしていない1つ以上のメッセージがあるかどうかを示します。

注意: エラーのワークフロー・アクティビティの再試行は、SAオーガナイザからは使用できません。

「営業基本契約」ウィンドウの処理とマウスの右クリック

この処理とマウスの右クリック・メニュー機能は、「メイン」タブからアクセスできます。

オープン・メッセージ – 「オープン・インタフェース・トラッキング」ウィンドウ

電子メッセージ取引のオープン・メッセージは、「オープン・インタフェース・トラッキング」ウィンドウから移動せずに直接処理できます。

注意: オープン・メッセージの表示機能は、「詳細」ウィンドウの「処理」ボタンでのみアクセスできます。これは、このウィンドウの機能については右クリック・メニューがサポートされていないためです。複数選択は、「オープン・インタフェース・トラッキング」ウィンドウではサポートされていません。

再試行機能

エラーのアクティビティは、「オープン・インタフェース・トラッキング」ウィンドウから再試行できます。

注意: 再試行機能は、「詳細」ウィンドウの「処理」ボタンでのみアクセスできます。このウィンドウの機能については右クリック・メニューはサポートされていません。複数選択は、「オープン・インタフェース・トラッキング」ウィンドウではサポートされていません。

問合せ機能

問合せの対象は、特定のシード済ステータスまたはカスタム・ステータスのメッセージを少なくとも1つ保持する取引です。

「検索」ウィンドウの詳細

「オープン・メッセージ」チェック・ボックスは、クローズしていない1つ以上のメッセージがあるかどうかを示します。

営業グループ別計画営業収益レポート

Order Managementでは、受注明細の販売実績を受け取る営業担当を指定できます。営業グループは受注明細で取得されるようになりました。受注明細に営業グループが格納されるのみでなく、次のような新機能があります。

• 営業担当に基づく営業グループのデフォルト設定

• 営業グループの先日付の変更または更新の凍結

• 営業グループの上書き

• 返品明細（RMA）への営業グループの追加

Order Managementの営業グループ・サポート

営業グループは、営業担当の選択時に自動的に移入されます。また、参照される場合は、営業グループがRMA明細とともに表示されます。

営業グループの変更禁止

「固定」チェック・ボックスを介して営業グループの変更の固定または禁止がサポートされます。

デフォルト営業グループの上書き

受注明細上の営業グループを手動で変更できます。営業担当を入力すると、適切な営業グループが受注明細に自動的に移入されます。ただし、営業グループを別の有効なグループに変更することもできます。

ユーザー・プロシージャ

営業グループのデフォルト設定

「販売実績」ウィンドウに営業担当が入力される際と、受注処理を介して販売実績が作成される際に、営業グループがデフォルト設定されます。営業担当の他に、受注日または記帳日がAPIでデフォルト設定のための入力として使用されます。

このAPIでは、営業グループ有効日の範囲内で受注日または記帳日を持つ営業グループが考慮されます。受注が入力されても記帳されなければ、システムでは受注日がAPIに送信されて営業グループがデフォルト設定されます。受注が記帳されると、記帳日がAPIに送信されて営業グループのデフォルトが再設定されます。デフォルトの再設定が発生するのは、手動でデフォルト設定された値を上書きしていない場合、または営業グループ値をNULLにしていない場合のみです。

営業グループの固定または設定

受注入力時にデフォルト設定された営業グループを使用する場合は、「固定」チェック・ボックスを選択して、営業グループを凍結または更新不可としてマークできます。これにより、営業グループの有効性に変更があっても、記帳時には営業グループのデフォルトが再設定されなくなります。

異なる営業グループの選択

「営業グループ」値リストから有効な営業グループを選択し、デフォルト設定された営業グループを手動で上書きできます。値リストからレコードを選択すると、「固定」チェック・ボックスが選択されます。

RMA明細上の営業グループのコピー

参照先RMAがある場合は、受注明細上の元の営業グループと販売実績を新規RMA明細にコピーする必要があります。

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