1. オーダー管理の実装
  2. オーダー管理での拡張可能フレックスフィールドの設定に関するガイドライン
機械翻訳について

Order Managementでの拡張可能フレックスフィールドの設定に関するガイドライン

オーダー管理で拡張可能フレックスフィールドを設定するときにガイドラインを適用します。

  • 付加フレックスフィールドとは異なり、必要な数のセグメントを追加できます。
  • コンテキストを使用して、ビジネス・データをダイアログなどのユーザー・インタフェース要素の簡潔な領域に編成します。
  • 表示および使用の要件に従って、属性を論理グループに編成します。
  • 拡張可能フレックスフィールドがオーダー取得およびオーダー履行ライフサイクルで役立つ可能性がある場所を検討します。
  • 販売オーダー・ヘッダーに追加する拡張可能フレックスフィールドは、履行明細に追加する拡張可能フレックスフィールドから独立しています。 オーダー管理では、拡張可能フレックスフィールドごとに同じ名前を使用する場合でも、それらの間で値が通信または転送されません。 間に依存関係が必要な場合は、オーダー管理拡張を作成し、拡張で依存ロジックを定義します。

セグメントおよびコンテキストの作成

セグメントおよびコンテキストの作成

次の場合:

  • 新しいセグメントの作成。 「コード」属性と「API名」属性に同じ値を使用します。 これにより、設定とメンテナンスが簡素化されます。 設定全体(統合設定時など)にAPI名を使用し、webサービス、ビジネス・ルール、ビジネス・インテリジェンスなどを使用します。 セグメントの作成後にコードまたはAPI名を変更することはできません。

  • すでに存在するセグメントの変更。 API名は変更しないでください。 拡張可能フレックスフィールド・ロジックはAPI名を調べます。 空の場合、ロジックではコードの値が使用されるため、API名に値を指定する必要はありません。 API名を変更すると、実行時にフレックスフィールドが予期しない結果で失敗する可能性があります。

ノート

  • セグメントごとに一意のコード、名前および説明を入力します。 オーダー管理作業領域ではこれらの値は表示されないため、設定およびメンテナンス時に最も役立つ命名規則を使用してください。

  • コンテキストで「翻訳可能」オプションを有効にしないでください。 詳細は、「オーダー管理での拡張可能フレックスフィールドの設定」を参照してください。

名称

作成する各セグメントまたはコンテキストの「名前」属性および「コード」属性が正しい命名法を使用していることを確認します:

  • 名前はアルファベットの文字AからZで始まります。

  • 複数の連続する空白文字を含めることはできません。

  • コード属性にスペースを含めないでください。 空白を使用すると、ランタイム・エラーが発生します。

  • 名前に文字と数字のみが含まれ、次の特殊文字のみが含まれていることを確認してください:

    文字

    摘要

    .

    期間

    -

    ハイフン

    emダッシュまたはenダッシュを使用しないでください。

    _

    アンダースコア

    :

    コロン

    '

    一重引用符

    /

    スラッシュ

「拡張可能フレックスフィールド属性の公開」スケジュール済プロセスの実行時に誤った別名エラーが発生した場合は、コンテキストおよびセグメントで正しい命名法が使用されていることを確認してください。

属性およびセグメントの数

コンテキストに追加できる属性およびセグメントの数は、コンテキストに設定したデータ型によって異なります。

データ型 追加できる属性の数 追加できるセグメント数
Varchar 20 20
数値 10 5
日付 5 10
時間 5 10

各コンテキストに最大40個のセグメントを追加できます。

オーダー管理では、追加できるコンテキストの数は制限されませんが、各コンテキストがパフォーマンスに影響を与える可能性があるため、必要なコンテキストの最小数のみを追加する必要があります。

オーダー管理拡張の作成

オーダー管理拡張で拡張可能フレックスフィールドを使用する場合のガイドライン

ノート

  • 拡張が参照する各コンテキストおよびセグメントが存在し、値が含まれていることを確認するIf文を含めます。 欠落しているオブジェクトと空の値をチェックしない場合、予測できない結果で拡張が失敗する可能性があります。

  • 拡張可能フレックスフィールドの値を作成または更新するには、getOrCreateContextRowメソッドを使用します。 オブジェクトが存在しない場合は、このメソッドによってオブジェクトが作成されるため、このメソッドを使用して更新を行う前に、オブジェクトが存在するかどうかを確認する必要はありません。 getContextRowを使用して行のみを取得します。

  • 拡張可能フレックスフィールド・コンテキストを参照する場合は、コンテキスト・コードを使用します。

  • 拡張可能フレックスフィールド・セグメントを参照する場合は、API名を使用します。 拡張可能フレックスフィールドの設定時にAPI名を指定しない場合は、セグメント・コードを使用しますが、スペース()のかわりにアンダースコア( _)を使用します。

  • Groovyコードは、拡張可能フレックスフィールドからすべてのデータを取得するためにコンテキストおよびセグメントを横断する必要があります。

    while文を使用してすべてのデータを横断する例を次に示します。

    def complianceDetails = header.getOrCreateContextRow("ComplianceDetails");
complianceDetails.setAttribute("_ComplianceReason", "This has been set by pre submit extension.");

def lines = header.getAttribute("Lines");
while( lines.hasNext() ) {
  def line = lines.next();
  def inventoryItemId = line.getAttribute("ProductIdentifier");
  def orgId = line.getAttribute("InventoryOrganizationIdentifier");
  def item = getItem(inventoryItemId, orgId);
  
  String hazardous = item.getAttribute("HazardousMaterialFlag");
  def packShipInstruction = line.getOrCreateContextRow("PackShipInstruction");
  
  if( "Y".equals(hazardous) ) {
      // get details for fulfill line context PackShipInstruction
      
      packShipInstruction.setAttribute("_ShippingInstruction", "Hazardous Handling Required.");
  } 
  
}

ビジネス・ルールの使用

履行システムで、販売オーダーの事前定義済属性が指定していないデータが必要な場合は、他の販売オーダー属性にデフォルト値を設定するための基準として拡張可能フレックスフィールドの値を使用します。

Sample Requestedという名前の拡張可能フレックスフィールドを設定したとします。 含めることができる値は次のとおりです。

  • 無料

  • 手数料

  • サンプルなし

変換ルールを作成できます。

  • 値がComplimentaryまたはChargeの場合は、サンプル品目の履行明細を追加します。

次に、値がComplimentaryかChargeかに応じて、サンプル明細の価格詳細を移入するルールを設定できます。

変換ルールの処理時には、これらのタイプの変換のいずれかでデフォルト・ルールを実行するようにしてください。 属性値を拡張可能フレックスフィールドにデフォルト設定することはできません。

変換のタイプ

摘要

変換前

他の変換ロジックでデフォルト属性値が必要な場合は、拡張可能フレックスフィールドを使用します。

たとえば、デフォルトの属性値を使用して、変換中に無料のサンプル品目を追加するかどうかを決定する必要がある場合は、デフォルト値を設定する変換前ルールを定義します。

変換後

デフォルト・ルールを実行する前に変換を実行する必要がある場合は、ポスト変換を使用します。

たとえば、変換中に品目を追加する予定で、オーダー・ヘッダーの拡張可能フレックスフィールド属性を使用して、新しい履行明細に設定するデフォルト値を決定する場合です。

ビジネス・ルールで拡張可能フレックスフィールドを使用します。 詳細は、「ビジネス・ルールのフレックスフィールド・コンテキストおよびカテゴリ・コードの識別」を参照してください。

インポートと統合

クローズ済履行明細またはクローズ済販売オーダーの拡張可能フレックスフィールドは、Order Management作業領域でのみ更新できます。 ファイル・ベースのデータ・インポート、webサービス、REST APIまたはOracle Application Development Framework (ADF)などを介してインポートまたは統合を実行することはできません。

ソース・オーダーのインポート

オーダー・インポート・テンプレートを使用して拡張可能フレックスフィールドのデータをインポートする場合は、ガイドラインを適用します。

  • 各セグメントの表列属性を割り当て、オーダー・インポート・テンプレートの正しい列を参照します。

  • Excelにコメントを追加して、設定を文書化します。

  • DOO_ORDER_HDRS_ALL_EFF_B_INTワークシートを使用して、オーダー・ヘッダーの拡張可能フレックスフィールド詳細を取得します。

  • 履行明細の拡張可能フレックスフィールド詳細を取得するには、DOO_ORDER_LINES_ALL_EFF_B_INTワークシートを使用します。

  • ATTRIBUTE_CHAR1などの列を使用して、各属性の詳細を取得します。

  • ワークシート名または列名は変更しないでください。 かわりに、コメントを追加します。

オーダー明細エンティティに拡張可能フレックスフィールドを追加することはできません。 オーダー・ヘッダー・エンティティまたは履行明細エンティティにのみ追加できます。 テンプレートではDOO_ORDER_LINESという語句が使用されますが、DOO_ORDER_LINES_ALL_EFF_B_INTワークシートに追加する詳細を使用して、オーダー明細ではなく履行明細の拡張可能フレックスフィールドと相互作用します。

詳細は、「オーダー管理にオーダーをインポート」を参照してください。

この例では、ATTRIBUTE_CHAR1列を参照するCompliance Infoセグメントを設定する方法を示します。

列ATTRIBUTE_CHAR1を参照するセグメント・コンプライアンス情報を設定

Webサービスを使用した拡張可能フレックスフィールド詳細のインポート

オーダー管理がwebサービスとの通信に使用するペイロードに拡張可能フレックスフィールドの詳細を追加します。

  • ペイロードの例を取得します。 詳細は、「オーダー管理を統合するWebサービス・ペイロードの例」を参照してください。

    返品、カバレッジ、構成など、様々な例を使用できます。 これらのペイロードには、必要な販売オーダー・データのほとんどが含まれます。

  • 独自のペイロードを作成する場合は、ペイロードに必要なWSDL定義に従って作成します。 詳細は、「独自のペイロードを使用した拡張可能フレックスフィールドのインポート」を参照してください。

  • 拡張可能フレックスフィールド属性の公開スケジュール済プロセスを実行します。

  • スケジュール済プロセスが作成したログ・ファイルから、ペイロードを含むXSDファイルに拡張可能フレックスフィールド・データをコピーします。 このデータを、拡張可能フレックスフィールド・データを必要とする各オブジェクトにコピーします。 この方法は、チャネル・システムをオーダー管理で設定したものと同期させるのに役立ちます。

  • Application Development Framework (ADF)からのインポート・サービスを使用します。 SOA (サービス指向アーキテクチャ)インポート・サービスは使用しないでください。

ログ・ファイルからXSDファイルに1つのコード・セクションをコピーするペイロードの例を次に示します。

コードの1セクションをログ・ファイルからXSDファイルにコピーするペイロード

詳細は、「Webサービスを使用したオーダー管理の統合に関するガイドライン」を参照してください。

他のOracle Applicationsとの統合

拡張可能フレックスフィールドは、価格設定、売掛管理、出荷、受入、購買などの他のOracle Applicationと統合する場合に使用します。 Oracle Pricingに設定したサービス・マッピングに似たサービス・マッピングを設定します。 拡張可能フレックスフィールドを使用して、サービス・マッピングに必要な値を格納します。

サービス・マッピングに必要な値を格納する拡張可能フレックスフィールド

ノート

  • ログ・ファイルからビュー・オブジェクトの名前をコピーします。 サービス・マッピングでは、ビュー・オブジェクトを使用して拡張可能フレックスフィールドからデータを取得します。 拡張可能フレックスフィールド属性の公開スケジュール済プロセスで作成されるログ・ファイルを使用します。

  • 新しいエンティティを定義する場合は、_Customサフィクスを使用します。

  • 統合アルゴリズムを使用して、複雑なロジックを実装します。 たとえば、品目を品目をカバーするカバレッジと連結して数量を追加し、結果を売掛/未収金の付加フレックスフィールドに格納する必要があるとします。 この要件を実装するには、統合アルゴリズムを使用します。

オーダー管理作業領域での拡張可能フレックスフィールドの検索

56794販売オーダーで拡張可能フレックスフィールドを検索する必要があるとします。

  1. 「オーダー管理」作業領域に移動します。
  2. 概要ページの「タスク」>「履行明細の管理」。
  3. 「フィールドの追加>拡張可能フレックスフィールド・カテゴリ」をクリックします。
  4. 値を設定します。
    属性 値
    オーダー 56794
    拡張可能フレックスフィールド・カテゴリ 追加の履行明細情報と等しい
  5. 「検索」をクリックします。
  6. 検索結果で、右端までスクロールし、拡張可能フレックスフィールドの属性を確認します。 これらは、コンテキストやカテゴリなど、フレックスフィールドに対して設定した名前を持ちます。

    オプションとして、「表示」>「列」をクリックし、検索結果から個々の属性を追加または削除します。

  7. 「保存」をクリックして、検索を保存します。 このようにして、次にフレックスフィールドの詳細を表示する必要があるときに、保存済検索にアクセスできます。

販売オーダーでフレックスフィールドを検索する方法を次に示します。

  1. 「オーダー管理」作業領域に移動します。
  2. 「概要」ページで、「タスク」→「オーダーの管理」の順にクリックします。
  3. 「オーダーの管理」ページで、「フィールドの追加>拡張可能フレックスフィールド・カテゴリ」をクリックします。
  4. 属性を設定します。
    属性 値
    オーダー 56794
    拡張可能フレックスフィールド・カテゴリ 等しい追加ヘッダー情報

変更オーダーの管理

変更オーダーの処理中に拡張可能フレックスフィールドを使用する場合のガイドライン

ノート

  • 変更管理の要件を特定します。 たとえば、拡張可能フレックスフィールドの値を変更するときにオーケストレーション・プロセスが補正する必要があるかどうか、およびスケジューリングや売掛/未収金のコールなどの報酬で実行する処理を決定します。

  • オーケストレーション・プロセスが参照する値が変更された場合に補正します。

    • 「任意の拡張可能フレックスフィールド」. オーケストレーション・プロセス定義のヘッダーで「フレックスフィールド属性の使用」オプションを有効にします。

    • 「特定の拡張可能フレックスフィールド」. オーケストレーション・プロセス定義の変更管理領域で「フレックスフィールド属性の使用」オプションを有効にします。 拡張可能フレックスフィールドを参照するオーケストレーション・プロセス・ステップに追加します。 また、このステップで給与パターンを定義します。

      報酬パターンを使用して、変更する値に応じて、取消、作成、更新などの処理を指定します。 単一値が変更されたときに更新を送信し、他の値が変更されたときに更新の送信をスキップするように構成できます。 この方法では、報酬に関するより詳細な管理が提供されます。

      次に、報酬パターンの例を示します。

      pseudocode: 
If segment3 changes, then cancel task x, and then recreate task x. 
If segment4 changes, then do nothing.
If segment5 changes, then call an update service.

      詳細なコード例を確認します。 詳細は、変更された販売オーダーの補正を参照してください。

    • すべての拡張可能フレックスフィールド値に対する変更を無視するには、変更管理領域の各ステップのフレックスフィールド属性の使用が有効になっていないことを確認します。

変更管理では、販売オーダー・ヘッダーで設定した拡張可能フレックスフィールド値に対してオーダー入力スペシャリストが実行する各変更は無視されます。

レポートおよび分析の使用

レポートの変更

レポートで拡張可能フレックスフィールドを使用する場合のガイドライン。

ノート

  • 販売オーダーを作成または表示するときに、販売オーダー・レポートを使用できます。

  • 拡張可能フレックスフィールド・データをレポートに追加します。

    • Oracle Analytics Publisher Desktopのインストール

    • Oracle Analytics Publisherの販売オーダー・レポートの編集処理を使用します。 このアクションにより、販売オーダー・レポートがリッチ・テキスト形式で表示されるため、変更できます。

    • 「原野」を右クリックし、「コピー」をクリックします。

    • Oracle Analytics Publisherのプロパティを使用して、レポートがフィールドのデータを表示するために使用するソースを指定します。

      次の書式を使用します

      <?context/segment?>

      説明

    • 「コンテキスト」. 拡張可能フレックスフィールド・コンテキストの名前。

    • 「スラッシュ」. コンテキストとセグメントの間にはスラッシュを使用する必要があります。

    • セグメント 拡張可能フレックスフィールド・セグメントの名前。

    • context/segmentを囲むには、一連の疑問符( ??)を使用する必要があります。

    • 疑問符を囲むには、山カッコ(< >)のセットを使用する必要があります。

    たとえば、Context1を使用して取引コンプライアンスの詳細を格納し、SegmentAを使用してコンプライアンスの説明を格納する拡張可能フレックスフィールドを設定したとします。 使用するコードを次に示します。 

    <?Context1/SegmentA?>

分析の変更

Oracle Transaction Business Intelligence (OTBI)は、アナリティク・レポートを提供します。 拡張可能フレックスフィールド・データはOTBIで表示できます。

拡張可能フレックスフィールド・データをOTBIで表示する際のガイドライン

ノート

  • 拡張可能フレックスフィールドの設定時に「BI有効」オプションを有効にします。

  • トランザクションBusiness IntelligenceのOracle Fusionデータ拡張のインポート・スケジュール済プロセスを実行します。 このプロセスによってOTBIが更新され、OTBIのサブジェクト領域に拡張可能フレックスフィールドが表示されます。 詳細は、「フレックスフィールド変更インポートの概要」を参照してください。

  • サブジェクト領域からOTBIのレポートに拡張可能フレックスフィールドを追加します。

  • OTBIで使用される形式は次のとおりです。

    Category_Context

    たとえば:

    Additional Fulfillment Line Information_Additional Details1

    説明

    • Additional Fulfillment Line Informationはカテゴリです

    • Additional Details1はコンテキストです

その他のガイドライン

XMLでは、数字で始まるコンテキスト名またはセグメント名はサポートされません。 そのため、コンテキストまたはセグメントの名前を数字で開始すると、オーダー管理では実行時に名前にアンダースコア( _)が自動的に表示されます。 たとえば、コンテキストに1MyContextという名前を付けると、オーダー管理によってその名前が_1MyContextに自動的に変更されます。