Oracle Order Managementインプリメンテーション・マニュアル リリース12 E05611-01

目次

前へ

次へ

受注入力ツール

この章の内容は、次のとおりです。

• 取引タイプ
• 概要
• 機能の概要
• 機能
• 用語
• 明細（取引）タイプの定義
• 受注取引タイプの定義
• 取引タイプへのワークフローの割当
• ワークフロー検証
• 文書連番の作成
• 文書連番の割当
• レポート
• 例
• Oracle Order ManagementでのOracle Workflowの使用
• 概要
• ワークフロー
• 待機を伴う履行
• 明細フロー: 一般、パフォーマンス
• デフォルト・ルール
• 主な拡張機能
• 用語
• Oracle Order Managementでの属性とエンティティ
• 条件
• デフォルトの順序
• 値のソース
• 依存性
• 例
• 変更の制御
• レポート
• 実装時の考慮事項
• 新規のデフォルト設定機能
• Order Managementのデフォルト・ルール
• 連鎖

取引タイプ

概要

Oracle Order Managementでは、取引タイプを定義する必要があります。取引タイプにより、受注、見積および営業基本契約などの営業文書にデフォルト情報が提供され、Oracle Workflowとのプロセス制御が確立されます。

機能の概要

この章では、「受注管理取引タイプ」の設定について説明し、詳細な例を示します。受注取引タイプと明細取引タイプの作成、ドキュメント連番の割当と適切なワークフローの関連付けなど、新規取引タイプの作成に必要な設定ステップについて説明します。この章の最後には、詳細な例が記載されています。

取引タイプ/ワークフローには、次のような新しい機能が用意されています。

• 受注の各明細は個別のワークフローを備えているため、明細ごとにフローが異なる場合もあります。このため、同一受注上で受注明細と返品明細の両方を保持できます。

• カスタムPL/SQLコードから新規ワークフロー・アクティビティを作成できます。このため、OMを簡単に拡張できます。

• 各見積は、ヘッダー・フローのみに割り当てられます。明細フローは見積ごとに割り当てられないことに注意してください。

• ワークフロー・プロセスには、次のようなサブプロセスを使用できます。

• 文書が交渉フェーズから履行フェーズに移るときに文書番号を生成する方法を制御します。

• 履行への遷移が発生したときに、見積と同じ文書番号を保持するか、新規の文書番号を生成します。

• ワークフロー・プロセスには、必要な数のアクティビティを使用できます。

• Oracle Order Managementで定義できるカスタム・ワークフロー・アクティビティの数には、制限はありません。

• 受注または受注明細のワークフローのステータスは、表形式またはグラフ形式で表示できます。グラフ形式の場合は、ワークフローが完了しているアクティビティのみでなく、未完了のアクティビティも表示できます。

• 通知に承認者を割り当てて順序付けします。

機能

受注タイプと明細タイプの両方に関連付けられている取引タイプが存在します。このリリースでは、受注取引タイプに一意の文書連番を割り当てることで受注番号が制御されます。Order Managementでは、文書連番の作成と受注取引タイプへの割当は2つの個別ステップであり、どちらも「取引タイプ」ウィンドウから直接実行できません。設定については後述します。

注意: 営業基本契約には自動採番のみを使用します。

用語

取引タイプは、Oracle Order Managementで営業文書の取引タイプの両方を指す一般用語です。売掛管理トランザクション・タイプはまったく異なるオブジェクトであるため、混同しないでください。

取引タイプ・コードには、値「受注」または「明細」を指定できます。このコードにより、取引タイプが受注取引タイプであるか明細取引タイプであるかが決定されます。このマニュアルでは、受注タイプは受注取引タイプと同義、明細タイプは明細取引タイプと同義に使用しています。

文書連番は、受注タイプに使用する番号の範囲で、採番方法（自動、手動または無欠番採番）により定義されます。この連番は、開始受注番号です。

文書カテゴリは、受注や発注など、特定の文書タイプです。これは、多数のOracle Applicationsで主要エンティティに使用されます。Oracle Order Managementでは、受注取引タイプの作成時に、同じ名前を持つ文書カテゴリが自動的に作成され、次のように2つの文書連番カテゴリが作成されます。

一方のカテゴリは取引タイプと同じ名前で、他方のカテゴリは取引タイプと同じ名前ですが文字列「-quote」が追加されます。これは、受注タイプに連番を割り当てるために使用されます。

明細（取引）タイプの定義

「取引タイプの定義」ウィンドウを使用して、受注タイプと明細タイプの両方について、営業文書の取引タイプを定義します。最初に定義するのは明細タイプです。受注明細と返品明細の両方について明細タイプを定義する必要があります。明細タイプを定義するには「取引タイプ」ウィンドウにナビゲートします。詳細は、「Order Management取引タイプの定義」を参照してください。

取引タイプを使用して明細を定義する際の注意事項は、次のとおりです。

• 「取引タイプ」フィールドに明細タイプ名を入力します。この名前は一意にする必要があり、同じ名前を持つ受注タイプと明細タイプは作成できません。

• 「取引タイプ・コード」に「明細」と入力します。

• 値リストから営業単位を選択します。

• 新規明細タイプが受注明細用であるか返品明細用であるかに応じて、「受注カテゴリ」に「受注」または「返品」と入力します。

• このウィンドウの他の多数のフィールドと「明細フローの割当」ボタンは明細タイプに該当しないため、取引タイプ・コードを入力するとアクセス不可になります。たとえば、「受注ワークフロー」、「デフォルト返品明細タイプ」、「デフォルト受注明細タイプ」、「基本契約要」、「発注要」の各フィールドとすべての与信チェック・ルール・フィールドがアクセス不可です。

• 「基本契約タイプ」フィールドは、受注明細の検証に使用されます。このフィールドに基本契約タイプを入力すると、受注明細に使用できるのは、このタイプの基本契約のみになります。このフィールドを空白にすると、任意のタイプの基本契約を入力できます。

• デフォルト・ソースに明細タイプを使用する場合は、「メイン」タブに価格表を入力すると、この取引タイプの各受注に指定の価格表がデフォルト設定されます。ユーザーが受注入力時に明細に手動値引を適用できるかどうかは、「定価の強制」フラグにより決定されます。

• 「出荷」タブの「自動予定作成」フラグは、受注タイプにのみ適用されるためアクセス不可です。返品明細の受入時に検査が必要かどうかは、「検査要」フラグにより決定されます。

このタイプの明細について受注入力時の予定作成機能を制御できるように、「ATPのみ」、「全出荷予定処理の許可」、「予約なし」、「予約あり無効需要」および「予約なし無効需要」という5つの予定作成レベル・オプションが用意されています。残りのフィールドはデフォルト設定に使用できます。

「出荷」タブの「予定作成レベル」値リストでは、2つの値「予約あり無効需要」および「予約なし無効需要」により異なる予約要件がサポートされます。これらのレベルを取引タイプに設定すると、明細の予定は作成されず、APSでは需要とみなされません。このレベルが設定されている場合、ユーザーが入力した予定出荷日が受け入れられ、予定作成は実行されません。予定作成が処理として、またはワークフローを介して実行される場合、予定出荷日が設定されていなければ要求日がコピーされます。値は次のとおりです。

予約あり無効需要

• 意味: 明細はAPS需要で参照できません。

  • 予定日を手動で入力しても、システムでは予定が作成されません。

  • 明細は予約できます。

  • これは標準品目用で、出荷セットまたは到着セットはサポートされません。

予約なし無効需要

• 意味: 明細はAPS需要で参照できません。

  • 予定日を手動で入力しても、システムでは予定が作成されません。

  • 明細は予約できません。

  • これは標準品目用で、出荷セットまたは到着セットはサポートされません。

「財務」タブのフィールドには、財務アプリケーションとのインタフェースに影響する情報が含まれています。「請求ルール」および「会計基準」フィールドは受注のデフォルト・ソースとして使用され、この情報が自動インボイスに渡されます。「請求書ソース」、「非搬送請求書ソース」および「売掛管理トランザクション・タイプ」の各フィールドの値は、Oracle Receivablesへのインタフェースには必要ですが、受注ヘッダーや明細にはありません。ワークフローの請求インタフェース・アクティビティが実行されると、明細取引タイプ、受注取引タイプ、プロファイル・オプションの順に値が検索されます。値が見つからない場合は、請求インタフェース・アクティビティが失敗します。「売上原価勘定」は、明細の出荷確認時に在庫インタフェースの勘定科目生成機能で使用できます。

Order Management明細取引タイプには、次の役割があります。

次の表は、Order Management明細取引タイプに対して使用できる様々な列管理を示しています。

Order Management明細取引タイプの定義時に、このタイプの明細が実行される明細フローを定義できます。明細取引タイプは、異なる受注取引タイプと組み合せることができます。たとえば、返品取引タイプは、標準受注タイプまたは国際受注タイプと組み合せて使用できます。ただし、取引タイプの可能な組合せについては、フロー結合を指定する必要があります。

受注取引タイプの定義

「取引タイプ」ウィンドウにナビゲートし、受注タイプを定義します。

Order Management取引タイプ

受注取引タイプを定義する際の注意事項は、次のとおりです。

• 取引タイプの定義情報を取得する営業単位を値リストから選択します。複数組織アクセス管理が有効の場合、使用している「MO: セキュリティ・プロファイル」を経由してアクセス可能なすべての営業単位間で取引タイプを管理できます。

• 「取引タイプ」フィールドに受注タイプ名を入力します。この名前は一意にする必要があり、同じ名前を持つ受注タイプや明細タイプは作成できません。

• 摘要を入力します（オプション）。

• 営業文書を入力します（オプション）。

• 「受注カテゴリ」に値「混合」、「受注」または「返品」を入力します。「受注」と入力すると、受注タイプに使用できるのは「受注」取引タイプの明細のみとなります。「返品」と入力すると、受注タイプに使用できるのは「返品」取引タイプの明細のみとなります。「混合」と入力すると、受注には「受注」または「返品」取引タイプの明細を使用できます。SAの場合は、「受注カテゴリ」と「営業文書タイプ」で「受注」を選択します。注意: 見積とSAの場合は返品がサポートされないため、タイプとして「受注」を選択する必要があります。

• 取引タイプ・コードとして「受注」または「明細」を選択します。

• 取引タイプに履行フローを割り当てます。これは、この取引タイプを使用して受注が処理されることを示します。見積とは、交渉フェーズで始まる受注で、交渉フェーズには明細レベルのワークフローがありませんが、タブを使用してデフォルト情報を設定できます。明細を割り当てると、履行フェーズにのみ適用されます。

• 見積の処理に同じ取引タイプを使用する場合は、交渉フェーズを割り当てます。注意: 交渉フローはSAに適用可能です。

• 有効日を入力し、必要に応じてデフォルティング・フレームワークで使用するデフォルトの取引フェーズを選択します。

• 「レイアウト・テンプレート」（オプション）については、設定に関する章の取引タイプに関する項を参照してください。

• 「契約テンプレート」（オプション）については、設定に関する章の取引タイプに関する項を参照してください。

• 必要に応じて「文書番号の保持」チェック・ボックスを選択します。取引タイプが交渉フローと履行フローの両方に関連付けられている場合は、文書が履行に遷移しても文書番号が保持されます。

• 取引フローに承認者リストを割り当てる場合は、「承認」ボタンを選択します。

• 「明細フローの割当」ボタンを使用して、適切な明細ワークフローを割り当てます。注意: SAで使用されるのはヘッダー・フローのみで、デフォルト・ルールは使用されません。SAの場合、明細レベルのワークフローはありません。

「メイン」タブ

• 「基本契約タイプ」フィールドは、受注の検証に使用されます。このフィールドに基本契約タイプを入力した場合、この受注タイプの受注に使用できるのは、その基本契約タイプの基本契約のみになります。このフィールドを空白にした場合は、どのようなタイプの基本契約でも入力できます。「基本契約要」および「発注要」は、検証に使用されます。ボックスを選択すると、受注の記帳時には、このタイプのすべての受注にこれらのフィールドの指定が必要になります。受注タイプを受注の価格表のデフォルト・ソースとして使用する場合は、「メイン」タブで価格表を入力できます。受注や出荷の「与信チェック・ルール」により、この受注タイプについての与信チェックが実行されるかどうかが決定されます。これらのフィールドを空白にすると、このタイプの受注については与信チェックが実行されず、「最小マージン率」フィールドでこの受注タイプの受注に許可する最小許容マージン率を入力できます。受注全体のマージンがこの最小率より小さい場合は、検討できるように記帳時にマージン保留が適用されます。この属性を使用するには、OMパラメータでマージンの計算機能を有効化しておく必要があります。

• 「承認」および「明細フローの割当」ボタン。「返品明細タイプ」および「デフォルト受注明細タイプ」フィールドは、後から入力されます。これは見積にのみ適用されます。

• 「価格設定」セクションには、デフォルトの価格設定情報を設定するためのオプション・フィールドがあります。

• 「与信チェック・ルール」セクションには、デフォルトの与信チェック情報を設定するためのオプション・フィールドがあります。

「出荷」タブ

• 「出荷」タブの「自動予定作成」フラグにより、このタイプの受注の明細に対して予定作成で自動計画が試行されるかどうかが決定されます。「検査要」フラグにはアクセスできません（明細にのみ適用されます）。残りのフィールドはデフォルト設定に使用できます。

「財務」タブ

• 「財務」タブのフィールドは、財務アプリケーションとのインタフェースに影響する情報に使用されます。「通貨」および「通貨換算タイプ」フィールドは、受注ヘッダーのデフォルト・ソースとして使用できます。「請求ルール」および「会計基準」フィールドは受注明細のデフォルト・ソースとして使用され、受注に関するこの情報が自動インボイスに渡されます。「請求書ソース」、「非搬送請求書ソース」および「売掛管理トランザクション・タイプ」の各フィールドの値は、Oracle Receivablesへのインタフェースには必要ですが、受注ヘッダーや明細にはありません。ワークフローの請求インタフェース・アクティビティが実行されると、明細取引タイプ、受注取引タイプ、プロファイル・オプションの順に値が検索されます。値が見つからない場合は、請求インタフェース・アクティビティが失敗します。「売上原価勘定」は、明細の出荷確認時に在庫インタフェースで使用されます。

注意: 通常、クレジット・メモ取引タイプは明細取引タイプ、受注取引タイプおよびプロファイル・オプション（「OM: クレジット・メモ取引タイプ」）から順番にデフォルト設定されます。ただし、複数の営業単位を使用している場合、プロファイル・オプションの値は考慮されません。

「定価の強制」フラグ

「定価の強制」フラグにより、ユーザーが受注入力時に受注に手動値引を適用できるかどうかが決定されます。しかしこのフラグは、「価格設定」、「有効数量」および「受注インポート」の各ウィンドウでは機能しません。「価格設定」、「有効数量」および「受注インポート」の各ウィンドウを使用する場合は、必ず「定価の強制」チェック・ボックスの選択を解除してください。

受注タイプと明細タイプの各レベルで、「定価の強制」フラグを確認できるので、価格設定中はモディファイアが明細に適用されません。ただし運送手数料により販売価格が変わらないようにフラグを選択したとしても運送手数料は適用されます。

価格設定は「定価の強制」フラグをサポートしないため、モディファイアが適用されないように、次の処理が発生します。価格イベントで、「価格計算フラグ」は「Y」に設定されます。保存や記帳のようなイベントが連続して発生すると、「価格計算フラグ」は「部分」（P）に設定され、その結果運送費のみが計算されてモディファイアは適用されません。

受注レベル管理と明細レベル管理

受注全体に適用し、明細レベルでは上書きできない受注管理を定義できます。たとえば、受注の採番は受注レベルで管理されます。受注には、受注や返品など受注タイプによって異なる番号を付けることができます。

明細タイプ・レベルに影響を与える明細管理も定義できます。受注レベルからデフォルト設定し、明細レベルで上書きできる特定の管理を設定できます。たとえば、1つの受注に返品と受注の両方を含めて、処理は返品明細と受注明細で別々に行うことができます。個別の明細処理は、上位の明細タイプ・レベルで管理されます。取引タイプの可能な組合せについては、ワークフローの結合を指定する必要があります。明細を処理する前にヘッダー・フローで完了する必要がある通知、またはワークフロー・アクティビティが組合せに含まれている場合は、ヘッダー・フローにフロー継続アクティビティを含める必要があります。明細フローには、適切な待機アクティビティを含める必要があります。

次の表は、Order Management受注取引タイプに対して使用できる様々な列管理を示しています。

注意: 参照されている受注または明細がある場合、基準言語の取引タイプ名は変更できません。

明細フロー割当

「明細フロー割当」ウィンドウは、OM受注取引タイプのみの場合に使用できます。このウィンドウを使用して、受注タイプとともに使用できる様々な明細タイプに明細フローを割り当てます。

明細フローは、受注タイプ、明細タイプおよび品目タイプの組合せに割り当てることができます。Order Managementでは、特定の組合せに対して有効な割当を1つのみ定義できます。品目タイプが指定されていない場合は、特定の割当がないすべての品目タイプにその割当が適用されます。ATOモデルの明細タイプを使用する場合は、構成品目の品目タイプに割当を指定する必要があります。「ワークフローの概要」および「ワークフローの設定」を参照してください。

次の表は、サンプル受注明細タイプと関連受注明細ワークフロー割当を示しています。

取引タイプへのワークフローの割当

受注タイプと明細タイプに適切なワークフローを選択します。複数のヘッダーおよび明細ワークフローがシードされています。受注、返品、直接出荷受注、構成品目の受注、受注組立品目の受注など、すべての標準OM処理は、シード済ワークフローのみを使用して実行できます。見積用に新規の交渉フローを割り当てることも可能です。また、追加のステップ（通知など）や追加のプロセスが必要な場合は、独自のワークフローを定義することもできます。すべての受注ワークフローがすべての明細ワークフローと併用できるとはかぎりません。受注と明細間の一部のワークフロー・ステップは、相互に依存しています。たとえば、ヘッダー・レベルの請求を伴う受注フローには、ヘッダー・レベルの請求を伴う明細フローの続行アクティビティが完了するまで待機するステップがあります。連動するように設計された受注フローと明細フローを使用しない場合は、完了準備ができていないアクティビティや完了することのないアクティビティを完了する受注や明細を使用できます。

受注タイプのみにより、受注ワークフローが決定されます。受注タイプの「取引タイプの定義」ウィンドウで、選択した受注ワークフローを入力します。これは、Workflow Builderでのプロセス名です。受注タイプまたは交渉フロー、あるいはその両方を保存します。保存しないと、その受注タイプを次のステップで選択できません。

受注タイプ、明細タイプおよび品目タイプの組合せにより、明細のワークフローが決定されます。このため、「受注タイプのワークフロー定義」ウィンドウから明細ワークフローを定義し、「明細フローの割当」ボタンをクリックして受注タイプを入力します。この受注に使用する明細タイプと品目タイプの組合せごとに、「ワークフロー・プロセスの割当」ウィンドウに1行を入力します。最初のステップで定義した明細タイプを使用してください。品目タイプは在庫モジュールでの品目の定義に基づいており、「標準品目」、「キット」および「PTOモデル」などの値があります。「品目タイプ」を空白にすると、定義したワークフロー・プロセスはすべての品目タイプに使用されます。（例外: 受注構成プロセスを使用する場合は、構成品目タイプにワークフローを特別に割り当てる必要があります。構成品目には、「品目タイプ」フィールドが空白になっているワークフローは使用されません。）プロセス名は、Workflow Builderで定義されたワークフロー・プロセス名です。各明細フロー定義の開始日を入力する必要があります。注意: 受注タイプを使用して文書を作成した後は、対応付けられたワークフロー割当を変更できません。したがって、取引に割り当てたワークフローの変更や、取引の無効化が必要な場合は、既存の割当の終了日を入力する必要があります。また、該当する場合は、新規ワークフロー用に新規割当を入力してください。

最後に、「受注取引」ウィンドウにデフォルト受注明細タイプとデフォルト返品明細タイプを入力します。この2つの値は、明細タイプのデフォルトをこの受注タイプの受注のデフォルトに設定するためのソースとして使用できます。

見積

Order Managementフレームワークには、内部承認や顧客受入のように通常は交渉フェーズで発生するアクティビティをサポートするためのワークフロー・フェーズが組み込まれています。交渉フェーズでの文書は見積と呼ばれます。これにより、交渉フェーズで見積を作成して管理し、見積を確定受注に移行させることができます。

交渉で承認を使用するには、まず使用する取引タイプに「交渉フロー - 承認のある一般」を割り当てる必要があります。交渉はSAにも適用できます。見積と同じワークフローが使用されますが、SAは交渉フェーズでも履行フェーズでもSAのままです。

参照:

承認

Oracle Order Managementには、承認階層を定義して取引タイプに関連付ける機能が用意されています。「OM承認」フォームを使用すると、承認通知を受け取る承認者のリストを設定できます。このフォームにアクセスするには、「設定」->「取引タイプ」->「承認」の順に選択するか、「取引タイプ」フォームで「承認」ボタンを使用して設定します。承認通知を受け取るメンバーのリストを割り当て、それぞれの「有効」フラグを設定します。取引タイプは必ず指定してください。

参照:

承認

ワークフロー割当

受注タイプにより受注ワークフローが決定されます。受注タイプ、明細タイプおよび品目タイプの組合せにより、明細ワークフローが決定されます。

受注タイプ、明細タイプおよび品目タイプ用に適切なワークフローを選択します。

受注、返品、直接出荷、構成品目の受注、受注組立品目の受注など、すべての標準処理はシード済ワークフローを使用して実行できます。追加のステップ（追加の通知やプロセスなど）が必要な場合は、独自のワークフローを作成することもできます。

明細ワークフローに使用する受注ワークフローは選択できません。受注と明細間の一部のワークフロー・ステップは、継続フロー・アクティビティと待機フロー・アクティビティがどのようにペアになっているかに依存します。したがって、異なる受注取引タイプと組み合せて使用する場合は、同じ明細取引タイプで異なる明細フローを使用する必要があります。

たとえば、ヘッダー・レベルの請求を伴う受注フローは、明細フローのアクティビティが完了するまで待機します。連動するように設計された受注フローと明細フローを使用しない場合は、完了準備ができていないアクティビティや完了することのないアクティビティを完了する受注や明細を使用できます。

明細が処理中の在庫品目には、特定のフロー要件がある場合があります。たとえば、構成には、ピックして出荷する前に作成された部品構成表と作業指示が必要です。標準品目は在庫からピックして出荷できます。したがって、構成品目に対するワークフローは、標準品目とは異なります。ただし、両方のタイプの受注明細で同じ明細タイプを使用できます。「ワークフロー割当」ウィンドウには、指定の受注または受注明細タイプの割当に対してワークフローの割当が可能な次の品目タイプが表示されます。

• ATOモデル、区分、オプション、品目

• 構成品目

• キット

• 展開品目

• PTOモデル、区分、オプション

• 標準品目

• サービス品目

品目タイプ・コードを空白にすると、指定したワークフロー割当は、特定の割当がないすべての品目タイプに適用されます。ただし、ATOモデルに明細タイプを使用する予定の場合は、構成品目タイプの割当を指定する必要があります。

注意: 指定した明細タイプを使用して明細を作成するには、その明細タイプに対するワークフロー割当が必要です。

「クイック受注」ウィンドウの「サービス詳細」リージョンは、サービス明細の作成ではなく明細のサービス情報の表示に使用します。このウィンドウの「サービス詳細」リージョンではサービス明細を作成できますが、デフォルト設定されるためには取引設定が適切に定義されていることが前提となります。このリージョンでは明細タイプはフォルダ項目ではなく、値を選択できません。明細ワークフローは「サービス」タイプの品目に関連付ける必要があります。取引タイプの定義の詳細は、『Oracle Order Managementユーザーズ・ガイド』を参照してください。

次の表は、サンプル受注タイプと関連受注ヘッダー・ワークフロー割当を示しています。

ワークフロー検証

Oracle WorkflowによりOrder Managementが起動されます。Oracle Workflow Builderを使用すると、Order Managementワークフローをカスタマイズおよび拡張できるので、Order Managementに関する固有のニーズを満たします。

カスタマイズや変更により例外エラーが発生し、データの破損とパフォーマンスの低下が生じる場合があります。ワークフローのプロセスが実行時にエラーを発生しないようにするために、実際に使用する前にOrder Managementワークフロー検証機能を使用してワークフローのプロセスを検証できます。Order Managementワークフロー検証により、Oracle Workflow Builderが実行する検証に加えて、別の検証が実行されます。

Order Managementでは、「取引タイプ」ウィンドウのワークフロー・プロセスを検証できます。

取引タイプの定義を保存している間に、ほとんどのワークフロー・プロセスに対して暗黙的または必須の検証が発生します。ただし、特有のワークフロー・プロセスを検証する必要がある場合は、次の3つオプションのうち1つを使用できます。

• 「取引タイプ」ウィンドウの「ワークフローの検証」ボタン – このボタンをクリックすると、「OMワークフローの検証」コンカレント・プログラムが起動されます。

• 「OMワークフローの検証」コンカレント・プログラム - 固有のパラメータに対して起動できます。

• OE_Validate_WF.validate() パブリックAPI – このカスタム・プログラムまたはUIをコールしてワークフローの定義を検証できます。

（必須の）ワークフロー検証が発生するイベントには次のものがあります。

「取引タイプ」メイン・ウィンドウ

• 新規の受注タイプを作成するか、既存の受注タイプに対してワークフロー・プロセスを割り当てる場合、レコード保存時に暗黙的な（必須）検証が発生します。適用可能であれば、割り当てられた包括的なネゴシエーション・ワークフローもまた致命的なエラーと比較して検証されます。

• ヘッダー・ワークフローが更新されるときに、そのヘッダー・ワークフローによってすでに明細フローが割り当てられている場合、暗黙的な（必須）検証は、新規のヘッダー・ワークフローが既存の明細ワークフローと互換性があるかどうかを判断します。これは変更が保存されたときに発生します。

「取引タイプ」 - 「明細ワークフロー割当」ウィンドウ

暗黙的な必須検証は、新規に明細フローを作成してレコードを保存すると発生します。明細ワークフロー割当について次のような考慮事項があります。

• 「エラーのみ」および「エラーと警告」という2つのモードでワークフロー検証を実行できます。「取引タイプ」ウィンドウと「明細ワークフロー割当」ウィンドウによって、保存時には暗黙的または必須検証はエラーのみ確認し、警告は確認しません。ただしコンカレント・プログラムを実行する場合は、エラーと警告の両方が表示されます。

• レコードを保存している間に、既存のフォーム・レベルの検証後のみエラーに対する暗黙的な（必須）検証が発生して既存のエラー報告機能を補完します。

• 「エラーと警告」モードで検証が発生します。受注ヘッダー、受注明細、営業基本契約およびネゴシエーション・ワークフローのときに発生します。

完全なエラーと警告のリストは、次のとおりです。

エラー

• OUT遷移がないアクティビティです。

• FULFILL_LINEアクティビティは、履行アクティビティ名品目属性によって指定されたアクティビティによるワークフローでは先に進みません。これは2段階の確認です。履行アクティビティ（たとえば、SHIP_LINE）がワークフローにない場合、ワークフロー割当時間（暗黙的な（必須）検証中）時にエラーとして扱われます。そうでない場合は、メッセージが表示されて「検証」ボタンを使用して別の検証を行うように通知されます。履行アクティビティがFULFILL_LINEの前にきていないことが検証により検出された場合には、エラーになります。そうでない場合は、警告が表示されるので手動でこれを検証します。

• 「ヘッダー・レベル請求書インタフェース」が、明細フローか明細フローに対応するヘッダー・フローに対してのみ定義されているか、またはヘッダー・フローかヘッダー・フローに対応する明細フローに対してのみ定義されています、あるいはその両方の状態です。

• BOOK_WAIT_FOR_Hは明細フローにありますが、ヘッダー・フローにはBOOK_CONT_Lがありません、またはBOOK_WAIT_FOR_Hが明細フローにありませんが、ヘッダー・フローにはBOOK_CONT_Lが存在します。

• CLOSE_WAIT_FOR_Lはヘッダー・フローに存在しますが、明細フローにはCLOSE_CONT_Hが存在しません、またはCLOSE_WAIT_FOR_Lはヘッダー・フローにはありませんが、明細フローにはCLOSE_CONT_Hがあります。

• シード済ATOモデル、ATO品目、構成品目または知識品目ワークフロー・プロセス（R_ATO_ITEM_LINE、R_ATO_MODEL_LINE、R_CONFIGURATION_LINEおよびR_OTA_LINE）は、これらのワークフロー・プロセスが適用できないOM品目タイプに割り当てられました。

警告

• WFSTD: WAIT（標準待機アクティビティ）には相対時間による待機モードがありますが、その指定時間が0です。ループの中でこの値が指定されるとエラーになりますが、そうでなければWAITは警告を表示します。しかし、パフォーマンスの問題を考慮し、ワークフロー実行中にこの確認を実行しないでください。

• WFSTD: WAIT（標準待機アクティビティ）には相対時間による待機モードがありますが、アクティビティがループの中にあります。指定された待機時間はワークフローのバックグラウンド・プロセスの予想最長実行時間より長くなるという警告が表示されますが、それ以外の場合では、ワークフローのバックグラウンド・プロセスのパフォーマンスの問題が発生することがあります。

• WFSTD: DEFER（標準遅延アクティビティ）がループの中にあります。これによりWFBGのパフォーマンス問題が発生する場合があります。

• WFSTD: WAIT（標準待機アクティビティ）には絶対時間による待機モードがあります。ユーザーに指定された時間が適切かどうかを確認する警告を発します。

• FULFILL_LINEが明細フローにありません。

• BOOK_ORDERかCLOSE_HEADERアクティビティがないヘッダー・フローです。

• CLOSE_LINEアクティビティがない明細フローです。

• INVOICE_INTERFACEがSHIP_LINEの前にきています。

• シード済ATOモデル、ATO品目、構成品目または知識品目ワークフロー・プロセス（R_ATO_ITEM_LINE、R_ATO_MODEL_LINE、R_CONFIGURATION_LINEおよびR_OTA_LINE）から派生したと考えられるカスタム・ワークフロー・プロセスが、4つのプロセスが適用できないOM品目タイプに割り当てられました。

• パフォーマンスに余裕があれば、前述したことに加えて他のすべてのマスター詳細ワークフロー同期処理の事象を検証し、実際にヘッダー・フローや標準ワークフローAPIのwf_standard.waitforflow()が割り当てられた全アクティビティに対するすべての明細フローの検査と、割り当てられたヘッダーまたは明細ワークフローにアクティビティが継続して存在しているかどうかの確認をします。同様に、wf_standard.continueflow()が割り当てられた各アクティビティは、割り当てられたヘッダーまたは明細ワークフローにおいて指定された待機アクティビティと適合します。これはエラーとして報告されますが、パフォーマンスの関係上、コンカレント・プログラムのみがこの検証を実行します。

文書連番の作成

Oracle Order Managementでは、受注の採番にAOL文書連番機能が使用されます。受注タイプに使用する文書連番を少なくとも1つは定義する必要があります。ただし、旧リリースのOracle Order Entryからアップグレードする場合は、文書連番もアップグレードされます。定義した文書連番は、すべての受注タイプに使用できます。たとえば、1から始まる自動連番を定義して、すべての受注タイプに割り当てることができます。その場合、新規受注を入力するたびに、連番で次の番号が割り当てられます。また、複数の文書連番を定義し、受注タイプごとに異なる連番を使用できます。たとえば、一方の連番を1で始まる国内受注に使用し、他方の連番を10000から始まる国際受注に使用できます。番号の範囲は分離されているため、受注タイプを簡単に識別できます。

文書連番の割当

受注タイプを文書連番に割り当てます。「受注管理」 -> 「設定」 -> 「文書」 -> 「割当」の順にナビゲートします。「文書」タブで、「アプリケーション」フィールドに「Oracle Order Management」と入力し、「カテゴリ」フィールドに受注タイプを入力します。帳簿を選択します。「方法」フィールドに連番が手動の場合は「手動」、それ以外の場合は「Null」と入力します。「割当」タブで、前のステップで受注タイプに対して定義した開始日と連番を入力します。受注タイプと帳簿に対する割当は変更できないことに注意してください。割当を変更するには、既存の割当に終了日を割り当てて、新規割当用に新規作成する必要があります。同じ日付範囲、文書タイプおよび帳簿に複数を割り当てることはできません。

見積が受注に移行するときには、文書番号の参照と番号の生成方法について追加の制御を考慮する必要があります。

無欠番採番タイプが要件となる場合は、交渉と履行に取引タイプを使用するときに「文書番号の保持」チェック・ボックスを選択しないでください。

取引タイプに交渉フローを割り当てる方法の詳細は、「Order Managementでの交渉」を参照してください。

受注採番用文書連番の定義

受注文書の採番

Oracle Application Object Library（AOL）の文書連番機能を使用して、受注採番オプションを定義します。様々なOM受注取引タイプと文書連番を設定できます。OM取引タイプと文書連番のどちらでも、どの受注タイプを自動または手動で採番するかを制御できます。

たとえば、すべてのアウトバウンド受注に特定の連番で番号を付け、すべての返品には別の連番で番号を付けることができます。OM受注取引タイプが作成されると、同じ名称の文書カテゴリが自動的に作成されます。連番を定義し、その連番をそれぞれの文書カテゴリに割り当てることができます。

レポート

取引タイプの設定情報が印刷されるレポートを使用できます。これは取引タイプ・リスト・レポートと呼ばれ、名前順の単一取引タイプ、名前順の取引タイプの範囲、受注取引タイプのみ、明細取引タイプのみ、またはこれらのパラメータの任意の組合せを指定して印刷できます。

例

この例では、新規の受注タイプと関連明細タイプを作成し、ワークフロー・プロセスを割り当て、文書連番を作成して割り当てます。ここまでのステップを完了すると受注を入力できます。

受注明細用の明細タイプを作成します。「設定」->「取引タイプ」->「定義」にナビゲートします。次の情報を指定して新規取引タイプを作成します。この表にないフィールドは空白にしてください。

次に、返品明細用の明細タイプを作成します。同じウィンドウで、次の情報を指定して新規取引タイプを作成します。この表にないフィールドは空白にしてください。

最後に、取引タイプとして受注取引タイプを作成する必要があります。同じウィンドウで、次の情報を指定して新規取引タイプを作成します。この表にないフィールドは空白にしてください。

次に、取引タイプにワークフローを割り当てます。この場合も、「混合」受注タイプの「取引タイプの定義」ウィンドウで操作する必要があります。このウィンドウに次の情報を追加します。

次のステップで使用できるように、受注取引タイプを保存します。

「明細フローの割当」をクリックし、「明細ワークフロー割当」ウィンドウに次の情報を入力します。

受注用の文書連番を作成します。「受注管理」->「設定」->「文書」->「定義」にナビゲートし、次の情報を入力します。

最後に、受注タイプを文書連番に割り当てます。「受注管理」->「設定」->「文書」->「割当」にナビゲートし、次の情報を入力します。

これで、「混合」タイプの受注を入力し、受注明細と返品明細の両方を請求経由で処理できます。

Oracle Order ManagementでのOracle Workflowの使用

概要

ワークフロー・テクノロジでは、ビジネス・プロセスの自動化と継続的な改善がサポートされます。どのようなタイプのルーティング情報も、ユーザー定義のビジネス・ルールに従ってサポートされます。受注の発行や購買依頼など、各種の制御、ルーティングおよび承認を必要とするビジネス・トランザクションは、ワークフロー・テクノロジを活用することで従来より効率的に管理できます。主としてこのような理由から、Oracle Order ManagementがOracle Workflowと統合され、ユーザーに包括的な受注処理および履行システムを提供します。

Oracle Order Managementでは、Oracle Workflowを使用して受注、返品、受注明細および返品明細の処理中に発生するイベントの順序を制御します。Oracle Workflowでは、アクティビティを管理し、機能を実行し、通知を送信し、完了済アクティビティ履歴を保守し、エラーを検出してエラー・プロセスを開始します。Oracle Order Managementでは、受注履歴の追跡を可能にするためにもOracle Workflowが使用されます。また、一般的な受注処理についてビジネス・プロセスをモデル化できます。新規のワークフローを定義するときは、受注処理の基本アクティビティから開始できます。シードされているフローをコピーして編集するか、またはシードされているカスタム・アクティビティをコンポーネントとして使用して、自社のビジネス・プロセスを拡張できます。Oracle Order Managementでビジネス・ニーズにあわせてOracle Workflowを拡張する方法の詳細は、『Oracle Order ManagementにおけるOracle Workflowの使用』を参照してください。このマニュアルには、Oracle Order Managementでシードされるワークフロー・プロセスの詳細も記載されています。

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

ワークフロー

入力から請求までの基本的な受注フローでは、一般受注タイプに割り当てられている一般受注および明細フローが通常使用されます。次の図は、一般受注ワークフロー・プロセス（入力→記帳→クローズ）の例です。

「受注フロー - 一般」ワークフロー・プロセス

次の図は、一般受注明細ワークフロー・プロセス（入力→計画→出荷→請求→クローズ）の例です。

「明細フロー - 一般」ワークフロー・プロセス

待機を伴う履行

Oracle Order Managementでは、新規のシード済ワークフロー・サブプロセス「明細の履行を待機」を提供するために履行ワークフロー・アクティビティが拡張されています。このサブプロセスは、既存の「履行の遅延」または「明細の履行」あるいはその両方のサブプロセスの前に挿入できます。

Order Managementで「明細の履行を待機」サブプロセスを使用すると、より柔軟に受注を変更および取り消すことができます。このサブプロセスは、履行アクティビティを遅延させるのと同様に、出荷可能、出荷不可および請求のみの各明細に使用できるため、履行前に変更または訂正する機会が得られます。

タイムアウト・アクティビティは「ヘッダー」ワークフローの「履行 - 明細待ち」アクティビティに設定されます。Oracle Workflow BuilderでOEOH（受注ヘッダー・ワークフロー）を開き、「受注フロー - ヘッダー・レベル請求書インタフェースあり一般」プロセスを確認できます。前述のアクティビティのタイムアウトが1日に設定されている場合は、1日後にアクティビティが再試行されることを意味します。この値は要件にあわせて変更できます。

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

注意: OE_Fulfill_WF.check_wait_to_fulfill_lineプロシージャのデフォルト論理では、出荷不可受注明細がFulfill_Line_Eligibleブロックで保持されます。次のタイプの出荷不可受注明細は、このブロックで保持されません。

• 構成の一部である明細

• 同じ受注の出荷可能受注明細を参照しているサービス明細

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

明細フロー: 一般、パフォーマンス

このシード済ワークフロー・プロセスは、ワークフロー・サブプロセスを排除してワークフローのパフォーマンスを改善するように設計されています。「明細フロー - 一般」プロセスのアクティビティがすべて含まれていますが、そのほとんどはサブプロセスに分解されるかわりにメイン・フローに直接組み込まれています。

明細フロー: 一般、パフォーマンス

明細フロー: 一般、パフォーマンス（続き）

このプロセスは、パフォーマンスや多数のユーザーにあわせて最適化されており、一般フローをビジネス・ニーズにあわせて変更する必要がない場合の推奨プロセスです。また、このフローにはプロセス簡素化の一例という意図もあります。ワークフロー変更を含むパッチを適用した後、カスタマイズしたワークフロー全体をシード済ワークフローと比較して変更を上書きコピーする必要があるかどうかを確認する作業が必要になるため、このフローを使用してカスタマイズしたワークフロー・プロセスを作成することはお薦めしません。

デフォルト・ルール

Oracle Order Managementのデフォルト・ルールにより、受注や返品の入力時に必要なデータ入力量が減少します。デフォルト値設定に関するビジネス・ルールを定義し、条件と検証ルールの実装方法に優先順位を設定できます。デフォルト・ルール定義で受注または返品に必要なデフォルト値を設定できない場合は、受注や明細などのエンティティ内でほとんどの属性（フィールド）に対してデフォルト・ルールを追加定義するように選択できます。

Oracle Order Managementにはシード済のデフォルト・ルールが用意されており、次のいずれかの方法で追加作成できます。

• 新規に条件を作成するか既存の条件を使用して、新規のデフォルト・ルールを定義します。

• シード済のデフォルト・ルールを無効化して独自に作成します。シード済のデフォルト・ルールは変更できませんが、デフォルト・ルールの条件を無効化することはできます。

  注意: シード済としてマークされているデフォルト・ルールは更新できません。ただし、シード済のルール定義に基づいてルールを追加作成してから、シード済のルールを無効化できます。

  注意: 受注明細の「品目識別子」タイプ属性をデフォルト設定する場合は、リリース・レベルに応じて「INT」または「社内品目」を選択します。

デフォルト・ルールを使用して、ヘッダー・エンティティと明細エンティティのフィールド（属性）に値をデフォルト設定できます。

• エンティティには、「受注」や「明細」などの関連属性のグループが含まれます。

• 属性は、「倉庫」、「出荷先事業所」または「基本契約」など、特定のエンティティ内の個別フィールドです。

デフォルトは、Order Managementにより受注または明細のフィールドに自動的に設定される値です。

受注と明細の両方の属性名が同一の場合は、最初にヘッダーの値を明細にデフォルト設定できます。

たとえば、最初に発注番号を作成するときに、ヘッダーの発注を明細の発注にデフォルト設定できます。

注意: 初期値はデフォルト設定されますが、発注を変更した場合、連鎖が有効ですべての明細が更新される場合以外に、新規の値が自動的にデフォルト設定されることはありません（ヘッダーから明細まで）。

• また、同じエンティティ内の別の属性から属性値をデフォルト設定することもできます。たとえば、明細エンティティ内の要求日から明細の確約日をデフォルト設定できます。

デフォルト条件が実行時に評価され、すべてのオブジェクト属性に適切なデフォルト・ソース割当が選択されます。指定した機能モードでオブジェクト（データ・オブジェクト）のオブジェクト属性のデフォルト設定を制御するデフォルト条件を定義できます。たとえば、「支払条件」がAの場合には特定の方法でデフォルトが設定され、「支払条件」がBの場合には別の方法でデフォルトが設定されるように条件を設定できます。

エンティティに対して作成されたデフォルト条件は、そのエンティティ内の属性に準拠している必要があります。

デフォルト・ルールは、次のコンポーネントで構成されています。

• デフォルト・ソース/値（エンティティと属性、ソース・タイプ）

• デフォルト条件

• デフォルト条件の優先度（複数のデフォルト条件が存在する場合、使用される条件は優先度により決定）

• 順序（複数のルールが存在する場合にルールが適用される順序）

• ソース・タイプとデフォルト・ソース/値（属性値の導出方法）

デフォルト・ルール

様々な受注処理状況で使用する複数の異なるルールを定義できます。

初期属性のデフォルト設定の順序

属性に同じ連番が付いている場合、デフォルトはアルファベット順に設定されます。異なる順序でデフォルト設定する必要がある場合は、この順序を変更できます。たとえば、明細の属性Aを同じ明細の属性Bからデフォルト設定するようにソース・ルールを定義できます。パフォーマンスを向上させるため、属性Aの前に属性Bがデフォルト設定されるようにデフォルト順序を変更します。

ルールがあらゆる使用例で正しく機能するように、属性Aを属性Bに依存するように設定する必要もあります。この設定方法の詳細は、「依存性」を参照してください。

デフォルト・ルールの順序

フィールドのデフォルト値を検索するための優先順序を指定します。Order Managementでは、最小の連番からデフォルト値の検索が開始され、番号を増加させながら値が見つかるまで検索が継続されます。たとえば、第1と第2のソースがNULLで第3のソースに値がある場合は、第3のソースが使用されます。

デフォルト・ソース

デフォルト・ルール・ソースとはデフォルト値を取得する場所であり、通常は別のエンティティや属性です。ほとんどの属性には、他のデフォルト・ソースを使用する他に、少なくとも1つのエンティティ/属性デフォルト・ソースを割り当てることができます。

次のようなデフォルト・ソースがあります。

• 同一レコード

• 関連レコード

• システム変数

• 定数値

• アプリケーション・プロファイル

• PL/SQL API

たとえば、様々なソースから受注ヘッダーにデフォルトの価格表を設定するルールを定義する必要があるとします。使用可能なデフォルト・ソースには、顧客基本契約、顧客および受注タイプが含まれます。これら3つのすべてのエンティティに可能な属性が価格表です。使用するソースは選択可能で、ビジネス・プラクティス、特定の受注についてこれらのソースが存在するかどうか、およびこれらのソース向けに価格表が定義されているどうかに従って選択できます。顧客については、顧客自体のみでなく請求先および出荷先所在地に対して別の価格表を定義できます。これら3つのフィールドは、すべてソースとして使用できます。

デフォルト・ソースの例

アプリケーション・プロファイル

プロファイル・オプション・ソースでは、デフォルト値のソースとして、システム定義またはユーザー定義のプロファイル・オプションを使用できます。プロファイル・オプションの名前をデフォルト値として使用することをルールに記述する必要があります。プロファイル・オプション・ソースを使用すると、複雑なカスタマイズを行わずにデフォルト値を柔軟に調整できます。

注意: デフォルト・ソースとしてプロファイル・オプションを使用する場合は、デフォルト・ルール内で参照する前に、そのプロファイル・オプションが定義されていることを確認してください。

定数値

定数値ソース・オプションによって、値を含むフィールドのかわりに定数値を指定できます。デフォルトを同じ値にする場合またはルールに対して定義した他のソースが値を提供できない場合に特に役立ちます。

たとえば、組織のすべての品目が「各」単位で販売される場合、「受注明細」エンティティの「単位」属性の値が「各」にデフォルト設定されるようにデフォルト・ルールを定義できます。

システム変数

このシステム変数ソース・オプションを使用すると、フィールドに対してシステム変数またはシステム変数の関数をデフォルト設定できます。通常、このソースは日付フィールドのデフォルト設定に使用します。日付フィールドには、SYSDATE式またはSYSDATEの関数を使用して、現在の日付またはその関数をデフォルト設定できます。

たとえば、組織に全品目を翌日出荷するという方針がある場合は、システム変数としてsysdate + 1を指定して要求日のデフォルト・ルールを設定できます。

同一レコード

ソースと同じレコードを使用して、同じエンティティ・レコードの別の属性からデフォルト属性を設定できます。

たとえば、受注明細の予定出荷日に基づいてその明細の税額を計算するという共通要件があるとします。予定出荷日と同じレコード・ソースおよびソース属性を使用して、税金日付のデフォルト・ルールを設定します。

関連レコード

関連レコードは、最も使用頻度の高いデフォルト・ソースの1つです。特定の属性のデフォルトを、顧客、出荷先、請求先および品目などの関連オブジェクト・レコードを定義するときに設定できます。

デフォルトとして使用する属性ごとに、関連レコード・ソース・オブジェクト/ソース属性がシステム内で事前定義されます。

PL/SQL API

他のデフォルト・ソースでは定義できない複雑なデフォルト・ルールがある場合は、APIソースを使用できます。デフォルト値の導出論理をカスタムPL/SQL APIにコード化し、そのAPIをデフォルト・ルール内で参照できます。

依存性

一部の属性は、同じレコードの他の属性の値に依存します。依存性を設定できるのは同じエンティティの属性間のみで、エンティティ間では設定できません。使用可能なソース属性と依存属性のリストは事前に定義されています。ほとんどの属性は使用可能ですが、使用できない属性もあります。

属性がユーザーまたはシステムにより変更されると、その依存属性は消去されてから再びデフォルト設定されます。

たとえば、ヘッダー・エンティティの「運送条件」は「基本契約」に依存します。ヘッダーの「基本契約」が変更されると、ヘッダー・エンティティの「運送条件」が消去されてから再びデフォルト設定されます。

属性Yを使用する条件に基づいて属性Xのルールを作成する場合は、属性Yが属性Xより先に（手動入力ではなく）デフォルト設定されることを確認してください。また、手動でYを入力し、現行の値Yに基づいてXをデフォルト設定する場合は、ソース属性Yと依存属性Xを指定して依存性を定義する必要があることに注意してください。

たとえば、「顧客」を使用して「単位」をデフォルト設定するための条件を定義する場合は、「単位」より先に「顧客」がデフォルト設定されることを確認します。顧客を入力し、この新規の「顧客」値に基づいて「単位」を再デフォルト設定させる場合は、「顧客」に対する「単位」の依存性を定義する必要があります。

依存性の追加作成または既存の依存性の無効化が必要な場合は、依存性拡張APIを更新できます。

「デフォルト・ルール」での依存性とAPIの使用の詳細は、OracleMetaLink（http://www.oracle.com/support/metalink/）から入手可能なOrder Managementホワイト・ペーパー「Defaulting Rules Setup」を参照してください。

受注および明細の変更による影響

受注を変更すると、デフォルト・ルールによるデフォルト値が再適用される場合があります。このデフォルトの再適用によって変更が生じ、さらに別のデフォルト設定が実行される場合もあります。

Order Managementでは、再適用によって値が変更されて受注の情報に整合性がなくなった場合は、ユーザーによる受注の確定ができなくなり、データの訂正に有効なメッセージが表示されます。たとえば、デフォルト・ルールによっては、受注明細の明細タイプが変更されると、明細の価格表が変更される場合があります。明細品目が新しい価格表に含まれない場合、その受注は確定できず、指示が発行されます。

デフォルト・ルールの変更は、「受注ヘッダー」または「受注明細」ウィンドウを開いたとき、または受注の属性（フィールド）を更新したときに、変更したデフォルト・ルールを使用する新規受注に対して有効になります。受注を問い合せたり、変更したデフォルト・ルールを使用する既存の受注を変更してデフォルト設定の検証を実行しなければ、変更による影響はありません。

受注と明細のデフォルト設定中に既存受注の更新を実行する際には、デフォルト設定された属性の値がすべての共通する下位レベルのエンティティに複製（連鎖）されることはありません。既存の受注または明細レコードの属性をデフォルト設定するために下位レベル・エンティティの値を変更する場合は、一括変更機能を利用する必要があります。

たとえば、受注ヘッダーの明細レベル属性「出荷方法」を全受注明細にデフォルト設定するように、デフォルト・ルールが設定されているとします。出荷方法Aを使用して受注を作成してから、複数の明細を追加します。受注ヘッダーには出荷方法Aを使用しているため、以降に作成する各受注明細にはデフォルトの出荷方法Aが使用されます。そこで、受注ヘッダーの出荷方法をBに変更することにします。

この属性を受注ヘッダーで変更すると、以降に作成される新規受注明細には、デフォルトとして出荷方法Bが使用されます。ヘッダー属性を変更した結果、出荷方法Aが設定されている既存の受注明細が出荷方法Bに更新されることはありません。

受注明細を出荷方法Bに更新するには、一括変更を使用します。

ルールと条件のデフォルティング・パッケージの生成

デフォルト・ルールまたはデフォルト条件を生成または更新するには、「デフォルティング・ジェネレータ」コンカレント・プログラムを発行する必要があります。このコンカレント・プログラムを発行すると、各エンティティの属性ごとにデフォルティング・ハンドラ・パッケージが生成されます。属性のデフォルティング・パッケージが正常に生成されるまで、新規ルールまたは条件の作成や変更後のルールおよび条件は無効です。

このコンカレント・プログラムは、次のいずれかを実行する場合に発行する必要があります。

• 既存のデフォルト・ルールの更新。

• デフォルト条件の更新: デフォルト条件の検証ルールが更新された場合は、エンティティの全属性についてデフォルティング・パッケージを再生成する必要があります。

• デフォルト条件の無効化。

主な拡張機能

このフレームワークでは、次のような新しい拡張機能が可能です。

• 返品と返品明細のデフォルト・ルールを定義する機能。これはハード・コード化する必要があります。

• デフォルト・データを作成する算式を定義する機能。「値のソース」を参照してください。

• デフォルト動作と連鎖の明確な区別。

用語

このリリースでは、デフォルト・ルールは汎用になっており、他のOracle Applicationsでも使用できるため、汎用的な名前が使用されています。属性とエンティティはデフォルトの設定対象で、ソースはデフォルトの取込元です。

参照: 「値のソース」

Oracle Order Managementでの属性とエンティティ

このコンテキストでのエンティティは、Oracle Order Managementの表またはフォームにほぼ対応する関連属性のグループです。受注ヘッダー、受注明細などのエンティティがあります。

属性は、そのエンティティに属しているフィールドまたは列です。したがって、受注単位は受注明細エンティティの属性です。特定のエンティティの「デフォルト設定」ウィンドウを問い合せると、デフォルト・ルールを定義できるすべての属性のリストが表示されます。

付加フレックスフィールドのデフォルトはAOLのフレックスフィールド・ルーチンにより制御されるため、付加フレックスフィールドのデフォルト・ルールは定義できません。

条件

デフォルト条件検証テンプレート

条件は、特定のデフォルト・ソース・グループが検査される時期を制御するために設定されるルールです。ビジネス・ニーズを満たす共通のビジネス・ルールに基づいて、エンティティごとに1つ以上の条件検証テンプレートを定義します。このテンプレートは、そのエンティティの属性に何度でも使用できます。たとえば、すべての返品明細用に特定の条件テンプレートを設定し、すべての社内調達明細用に別の条件テンプレートを設定できます。エンティティごとにALWAYS条件がシードされます。条件セットを定義してルールに使用する場合は、デフォルト条件の優先順位の最後にALWAYS条件を置いてください。

条件検証テンプレートの定義

「デフォルト設定」ウィンドウで操作するエンティティを問い合せて（フラッシュライト・アイコンを使用すると、使用可能なエンティティの値リストが表示されます）、「デフォルト条件テンプレート」ボタンをクリックし、条件定義用のウィンドウを開きます。このエンティティについて定義済のすべての条件を示すウィンドウが表示されます。新規条件を追加するには、空白行にナビゲートし（または緑の「+」アイコンをクリックして空白行を作成し）、新規条件の名前と摘要を入力します。

• このウィンドウの下半分には、定義または表示する条件の詳細を入力します。

• グループ番号は、ANDおよびOR条件の制御に使用する任意の番号です。ルールがANDルールで接続されていることを示すには同じグループ番号を与え、ルールがORで接続されていることを示すには異なるグループ番号を与えます。

• 「属性」列で、条件の基礎として使用可能な属性のリストから選択します。このリストに使用可能な属性として表示されるのは、このエンティティの属性のうち、「デフォルト設定 - エンティティ属性」ウィンドウで「デフォルト条件の作成に含む」チェック・ボックスが選択されている属性です。依存関係のソースとなるのは、このチェック・ボックスが選択されている属性のみです。後述の「依存性」を参照してください。この属性リストには属性を追加できません。

• 「演算子」列で、等しい、等しくない、より大きい、より小さい、より大きくない、より小さくないから演算子を1つ選択します。

• 「値文字列」列に、実際に比較する値を入力（または値リストから選択）します。

デフォルトの順序

メインの「デフォルト設定」画面にはエンティティのすべての属性が表示され、「デフォルト順序」と呼ばれる列があります。この番号により、属性のデフォルトの順序が決定されます。複数の属性に同じ番号が付いている場合、デフォルト設定はアルファベット順になります。すべての属性は、順序50でシードされます。異なる順序によるデフォルト設定が必要な場合は、これらの順序を変更できます。たとえば、ある明細の属性Aのデフォルトを同じ明細の属性Bから設定するソース・ルールを定義できます。

値のソース

ソースは、値のデフォルトの取込み元です。デフォルト・ルールには、デフォルトの作成に使用できるように様々なソースが用意されています。そのほとんどは、Oracle Order Entryの場合と同様です。

• 定数値: 固定値が使用されます。

• アプリケーション・プロファイル: プロファイル・オプションの値です。システムに用意されているプロファイル・オプション、またはデフォルト値を提供するためにのみ定義した新規プロファイル・オプションを使用できます。

• 同じレコード: ルールを定義する属性と同じエンティティ（またはレコード）にある別の属性の値です。たとえば、「確約日」は同じ明細の「要求日」からデフォルト設定されるように設定できます。

• 関連レコード: 関連エンティティ（またはレコード）の別の属性の値です。たとえば、明細の「出荷方法」をヘッダーの「出荷方法」からデフォルト設定するように設定できます。また、受注ヘッダーの属性は、関連顧客レコードの属性からデフォルト設定できます。

• システム変数: システム日付など、システム（サーバー）変数の値です。このタイプのソースの場合のみ、sysdate + 7のように算式を含む式を使用できます。

• PL/SQL API: デフォルトを提供する独自ルーチンを定義します。このソースを使用する少数のシード済デフォルト・ルールが用意されていて、たとえば、帳簿から受注ヘッダーの通貨へのデフォルト設定は、この方法でシードされます。

• その他: この属性のWeb App Dictionaryの定義に関連して複数の難解なソース・タイプがあります。

  ソース・ルールの定義

  デフォルト・ソース・ルール

  

「デフォルト設定」ウィンドウで操作するエンティティを問い合せて、条件を定義すると、ソース・ルールを定義する準備が完了したことになります。操作する属性を選択して「デフォルト・ルール」ボタンをクリックすると、「属性デフォルト・ルール」ウィンドウが表示されます。このウィンドウには、この属性に関して定義済のすべての条件とルールが表示されます。新規の条件とルールを追加するには、このウィンドウの「デフォルト条件」セクションの空白行にナビゲートし（または、緑の「+」アイコンをクリックして空白行を作成し）、優先順位を入力して、定義済の条件から選択します。（優先順位により、条件の評価順序が制御されます。）

このウィンドウの下半分に、この条件について定義または表示するルールの詳細を入力します。このデフォルト・ルール・セットは、対応するデフォルト条件がTRUEの場合に使用されます。

• ここで指定した順序により、システムでデフォルトの検索が試行される順序が制御されます。

• 「ソース・タイプ」列で、前述のようにソース・タイプのリストから選択します。

• 「デフォルト・ソース/値」列で、ソースに使用する属性または値を指定します。ここでの選択は、選択したソース・タイプに応じて異なります。このフィールドには、ソース・タイプに基づくコンテキストを持つフレックスフィールドが表示されます。シード済のソース属性の候補から選択できます。

デフォルトには同様の制限事項があります。データ型は、デフォルト設定する属性のデータ型と一致する必要があり、ソース関係は事前に定義する必要があります。

依存性

一部の属性は、同じレコードの他の属性の値に依存しています。属性がユーザーまたはシステムにより変更されると、それに依存する他の属性のみが消去され、再デフォルト設定されます。2000年9月の時点で、この機能は、再デフォルト設定により依存フィールドに新しい値が設定されない場合は、古い値が消去されるかわりに保持されるように変更されました。この種のフィールドは「価格表」、「営業担当」、「顧客PO番号」または「受注タイプ」などです。

たとえば、価格表は基本契約に依存しています。基本契約に変更があると、価格表は消去され、再デフォルト設定されます。再デフォルト設定により依存フィールドに新しい値が設定されない場合は、古い値が消去されるかわりに保持されます。

デフォルト・ルールの初期実装時に、依存性がハード・コード化されています。ハード・コード化されている依存性パッケージOE_Dependencies（ファイル$ONT_TOP/patch/115/sql/OEXUDEPB.pls）の現行のコードをチェックして、最新リストを取得することもできます。

依存性の追加作成または不要になった既存の依存性の無効化が必要な場合は、APIフックであるパッケージOE_Dependencies_Extn（$ONT_TOP/patch/115/sql/OEXEDEPB.pls）を使用できます。

このフックを介した依存性の追加がサポートされるのは、ファイルに記述されているガイドラインに従う場合のみです。ガイドラインに従うことにより、顧客が導入した変更がパッチにより上書きされないことも保証されます。

ただし、次のことに注意してください。

• 依存性の設定に使用できるソース/依存属性のリストには制限があります。詳細リストはファイルOEXEDEPB.pls内のコメントを参照してください。

• 依存性を確立できるのは同じエンティティの属性間のみで、エンティティ間では確立できません。たとえば、受注ヘッダーの属性を変更しても、受注明細の属性は変更されません。

例

受注の出荷先は更新されていますが、このため請求先が消去または更新されます。出荷先から請求先をデフォルト設定するためのデフォルト・ルールが削除または無効化されても、動作に変更はありません。これは、「出荷先」フィールドについて「請求先」との依存性がハード・コード化されているためです。請求先が出荷先変更の影響を受けないようにするには、この新規フックを介して依存性を無効化する必要があります。ソース属性に「出荷先」、依存属性に「請求先」を指定します。

IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN

x_extn_dep_tbl(l_index).source_attribute := OE_HEADER_UTIL.G_SHIP_TO_ORG;

x_extn_dep_tbl(l_index).dependent_attribute := OE_HEADER_UTIL.G_INVOICE_TO_ORG;

x_extn_dep_tbl(l_index).enabled_flag := 'Y';

l_index := l_index + 1;

「出荷先」が更新されても、受注明細の「請求先」の値が変更されないようにする場合は、明細についても依存性を個別に無効化する必要があります。

ELSF p_entity_code = OE_GLOBALS.G_ENTITY_LINE THEN

x_extn_dep_tbl(l_index).source_attribute := OE_LINE_UTIL.G_SHIP_TO_ORG;

x_extn_dep_tbl(l_index).dependent_attribute := OE_LINE_UTIL.G_INVOICE_TO_ORG;

x_extn_dep_tbl(l_index).enabled_flag := 'Y';

l_index := l_index + 1;

OEXEDEPB.plsにリストされていないソース属性または依存属性について依存性を作成する場合は、やや煩雑になります。この場合は、既存パッケージのカスタマイズが必要になり、変更内容は将来のパッチにより上書きされる可能性があります。

1. 新規のソース属性を追加します。ヘッダーの「出荷方法」を「出荷優先度」に依存させるとします。

   • ソース属性に「出荷優先度」、依存属性に「出荷方法」を指定して、前述のようにOEXDEPB.pls内で依存性を追加します。

   • 「出荷優先度」は、受注ヘッダーで使用可能なソース属性の1つとしてリストされていないため、別のエンティティ固有のユーティリティ・パッケージをカスタマイズします。

OE_Header_Util.Clear_Dependent_Attrに次の文を追加します。

（ファイル: OEXUHDRB.pls）。受注明細の出荷優先度を変更した場合に、それを受注明細エンティティの出荷方法にも反映させる場合は、OE_Line_Util_Extに次のようなコードを追加する必要があります。

     IF NOT OE_GLOBALS.Equal(p_x_header_rec.shipment_priority_code 

        ,p_old_header_rec.shipment_priority_code) 

     THEN 

        l_index := l_index + 1.0; 

        l_src_attr_tbl(l_index) := OE_HEADER_UTIL.G_SHIPMENT_PRIORITY; 

     END IF;

1. 新規の依存属性を追加します。明細の「計画優先度」を「需要区分」に基づいてデフォルト設定するとします。前述のように、ソース属性に「需要区分」、依存属性に「計画優先度」を指定して、OEXDEPB.pls内で依存性を追加する必要があります。需要区分が受注明細エンティティで使用可能なソース属性の1つとしてリストされていない場合は、前述のステップに戻ってソース属性として追加する必要があります。また、計画優先度が受注明細エンティティの依存属性の1つとしてリストされていない場合は、エンティティ固有のユーティリティ・パッケージの別のセクションもカスタマイズする必要があります。

   OE_Line_Util_Ext.Clear_Dependents（ファイル: OEXULXTB.pls）に次のサブプロシージャを追加します。

     PROCEDURE PLANNING_PRIORITY IS

     BEGIN

     IF (p_initial_line_rec.PLANNING_PRIORITY = FND_API.G_MISS_CHAR

      OR OE_GLOBAlS.Equal(p_initial_line_rec.PLANNING_PRIORITY

                , p_old_line_rec.PLANNING_PRIORITY))

     THEN

       p_x_line_rec.PLANNING_PRIORITY := FND_API.G_MISS_NUM;

     END IF;

     END PLANNING_PRIORITY;

VARCHAR2フィールドの場合は、G_MISS_NUMをG_MISS_CHARで置換する必要があることに注意してください。DATEフィールドの場合は、G_MISS_DATEにする必要があります。また、メイン・プロシージャの大きいIFループに、この新規サブプロシージャをコールする文を追加します。

 ELSIF l_dep_attr_tbl(I) = OE_LINE_UTIL.G_AGREEMENT THEN

         AGREEMENT;

受注ヘッダー・エンティティに依存フィールドを追加する場合は、前述の手順に従って、ヘッダー・ユーティリティ・パッケージOE_Header_Util（ファイル: OEXUHDRB.pls）に同様のコードを追加します。

変更の制御

Oracle Order Managementのデフォルト・ルールでは、属性のデフォルト設定方法に関係なく、処理制約フレームワークを使用して、データを変更できるユーザーと変更できる時期を制御します。また、処理制約を定義するときには、システムによる属性の更新は可能にし、他のユーザーの変更権限は制限するように指定できます。

デフォルト・ルールによりエンティティの既存属性が変更されるのは、その属性が変更対象となった他の属性に依存している場合のみです。

レポート

Oracle Order Managementには、設定済のデフォルト・ルールを示す新規レポートが用意されています。このレポートは、旧リリースのOracle Order Entryの標準値ルール・リストにかわるものです。このレポートはデフォルト・ルール・リスティング・レポートと呼ばれ、リストを特定のオブジェクト（エンティティ）、属性または条件に限定できるようにパラメータが用意されています。もう1つのパラメータは、シード済かどうかを指定するオプション「シード済」（「Yes」または「No」）です。

顧客の受注タイプと営業担当をデフォルトに設定したOrder Managementのシード済デフォルト・ルールは削除されています。提供されているレポートで、削除されたデフォルト・ルールのリストを参照できます。レポートはontkexc01.sqlで生成されたontkexc01.lstファイルであり、パッチ・ログから入手できます。

実装時の考慮事項

条件の作成

前述のように、条件により、会社用のデフォルト・ルールの実装方法を設計する場合に、大幅な柔軟性が得られます。ただし、条件の作成時には、いくつかの動作を考慮する必要があります。

使用できる属性

エンティティについて条件を作成する場合に基礎として使用できるのは、そのエンティティに属する属性のみであることに注意してください。したがって、たとえば、担当はヘッダー属性であるため、担当に基づいて明細属性の条件を設定できません。同じレベルの属性に関して条件を記述できるように、ビジネス・ルールを慎重に調べる必要があります。Order Managementでは、ヘッダー・レベルのほとんどの属性は（価格表や通貨など、一部の例外を除き）明細レベルにも存在します。ソフトウェアでは顧客が受注全体で同一になるように規定されていても、販売先顧客は明細レベルの属性として存在します。このため、顧客を明細の条件テンプレートに使用できます。

条件内で使用される属性の順序

属性のデフォルト設定の順序は、条件とソース・ルールを適切に設計する上で重要な役割を果たします。属性Yを使用し、条件に基づいて属性Xのルールを作成する場合は、属性Yのデフォルトが属性Xより前に設定されるように設定しなければ、条件はTRUEに評価されません。たとえば、顧客を使用して単位のデフォルトを設定する条件を定義すると、顧客のデフォルトが単位より前に設定される場合にのみ、この条件が機能します。また、この条件は、「単位」フィールドの初期デフォルト設定にのみ機能します。これは、依存性によるものです。

条件内で使用される属性の依存性

したがって、条件の作成時には依存性を考慮する必要があります。属性Yに関連する条件を使用して属性Xのデフォルト・ルールを設定すると、属性Xが属性Yに依存する場合にのみ、そのルールが属性Yの後続の更新中に機能します。このため、前述の単位と顧客の場合は、後で受注の顧客を変更しても、単位は顧客に依存しないため、新規顧客に基づいて単位のデフォルトが再設定されることはありません。

デフォルト設定と連鎖の違い

Order Managementでは、デフォルト設定と連鎖に明確な区別があり、様々な方法で各ウィンドウにデータを挿入します。Order Entryでは、デフォルト設定と連鎖が混在しており、あるレベルで属性が変更された場合の処理を予測するのは困難な場合がありました。Order Managementでは、デフォルト設定ロジックが機能するのは、レコードの初期作成時（ウィンドウ上で新規レコードをクリックしたとき）、またはこの属性が依存する属性に変更があった場合のみです。これに対して連鎖は、ヘッダー属性が変わると、該当する明細属性が変わることを意味します。連鎖の間は、すべての明細が更新されるか、失敗時には明細は更新されないかのいずれかです。この場合も、新規で大量に変更する機能とは異なり、変更する行を複数選択した場合に、「受注一括変更」ウィンドウで「OK」をクリックすると選択された行が更新されます。

これらの概念がどのように適用されるかを考えます。たとえば、出荷方法のような属性のデフォルトを、ヘッダーから明細に設定するようにデフォルト・ルールを設定しているとします。複数の明細を含む受注を作成し、ヘッダーに出荷方法Aを使用して、明細のデフォルト値を出荷方法Aにします。その後、ヘッダー・レベルで出荷方法をBに変更する必要が生じました。この属性をヘッダーで変更すると、後続の新規明細には出荷方法Bがデフォルト設定されます。出荷方法Aが指定されていた既存の明細は、出荷方法属性の連鎖が有効になっている場合以外はヘッダー属性に変更があってもBには変更されません。このような状況において、明細レベルでの出荷方法属性は、自動的に出荷方法Bに更新されます。出荷方法を除いて、他の関連するフィールドも連鎖により自動的に更新されます。

新規のデフォルト設定機能

このリリースでは、「最終顧客」機能を使用して導入ベース情報のデフォルトをより正確に設定できます。必要に応じてヘッダー・レベルと明細レベルで「導入ベース所有者」、「現行事業所」および「導入場所事業所」の値をデフォルト設定できます。「最終顧客」フィールドは、「受注」フォームの「その他」タブにあります。

新規の「価格設定および有効数量」機能も用意されており、需要区分、品目識別子タイプ、倉庫および価格表などの価格設定および有効数量属性をデフォルト設定できます。

SVRSとデフォルト・ルールの間で根本的なアーキテクチャに大幅変更があったため、ユーザー定義のSVRSはアップグレードしないように決定されました。リリース12のシード済SVRSと同等の機能を持つデフォルト・ルールがシードされています。

Oracle Order Entryで独自の標準値ルールを作成したり、シード済ルール・セットをカスタマイズしていた場合は、変更やカスタマイズを裏付けるロジックを慎重に書き換えて、影響を受ける属性用に等価のデフォルト・ルールを作成する必要があります。通常、ユーザーは特定のビジネス・ニーズに対応する条件を作成して、必要な属性に関する条件を使用してデフォルト・ルールを作成します。

Order Managementのデフォルト・ルール

「デフォルト・ルール・リスティング・レポート」では、デフォルト・ルールで定義可能なエンティティと属性が表示されます。エンティティは受注ヘッダー、受注明細、明細支払、受注支払に適しています。

連鎖

以前のリリースでは、更新時に明細に連鎖する属性の数は限られていました。現在のリリースで導入された連鎖機能では、受注明細に連鎖する属性の数が拡張されており、必要に応じてその数を設定時に指定できます。連鎖は、すべての明細に発生するか発生しないかのいずれかです。ある明細で更新が失敗すると、連鎖処理は他の明細に対して失敗します。たとえば、明細レベルで処理制約が発生した場合、その処理制約により更新が制限されます。属性はヘッダーで更新されるため、その後の明細の更新も失敗し、他のすべての明細に対する連鎖も失敗します。

注意: 連鎖は、大量変更または複数選択のかわりや拡張として使用しないでください。

既存のプロファイル「OM: 受注フォーム: ヘッダー変更を行にも適用」は、この機能を使用する場合にユーザーが選択したものを判断しますが、連鎖を強制するものではありません。連鎖の発生前に、クイック・コード参照にある属性を有効にする必要があります。属性は有効化または無効化でき、プロファイルは連鎖する方法を判断します。たとえば、明細に連鎖させたり、自動で処理されるように設定できます。

プロファイルには次の3つのモードがあります。値が「自動」に設定されている場合、ヘッダー属性が連鎖されたら、システムはヘッダー属性を明細に連鎖します。値が「ユーザーに確認」に設定されている場合、連鎖するかしないかを決定します。値が「手動」に設定されている場合、明細の属性に対する値を手動で変更する必要があります。変更は、システムによってヘッダーから明細へ連鎖されません。

プロファイルが設定されている場合、属性を有効にして設定を完了する必要があります。この方法での連鎖はユーザーインタフェースを通じてサポートされていますが、APIに対してはサポートされていません。

参照「OM: ヘッダーから明細カスケード属性」には属性のリストがあり、このリストは受注ヘッダーから受注明細へのデフォルト・ソースとなります。この参照は、属性が受注ヘッダーで更新されたらすぐにヘッダーから明細へ連鎖される属性を決定するのに使用されます。参照にある属性を無効にすると、ヘッダー属性の値の変更時にヘッダーから明細へ連鎖しなくなります。クイックコードまたは参照は、ユーザーレベルで設定されますが、拡張可能ではありません。

明細属性のリストを連鎖によって変更することの詳細は、付録の「ヘッダーから明細へのカスケード属性参照」を参照してください。

Copyright © 2000, 2006, Oracle. All rights reserved.