機械翻訳について

オーダー履行中に発生する変更管理のガイドライン

オーダー履行中に発生する変更の処理方法(変更の補償方法など)を指定する際のガイドラインを適用します。

チャネルからの変更のインポート

変更オーダーは様々なチャネルからインポートできます。

様々なチャネルを介した変更オーダーのインポートのフロー

ノート

  • チャネルには、オーダー取得システム、履行システム、オーダー管理作業領域などを含めることができます。

  • オーダー管理では、新しい販売オーダーに対してこの動作と同様の方法で、相互参照、変換、検証および調整が行われます。 変更の処理方法を制御するルールが存在する場合、オーダー管理によって変更が適用されます。 設定オプションを使用して、オーダー管理でのこの処理方法を変更できます。

  • 販売オーダーをインポートして変更指示をインポートするのと同じExcelテンプレートを使用します。 詳細は、「オーダー管理にオーダーをインポート」を参照してください。

  • 販売オーダーを作成して変更オーダーをインポートするのと同じwebサービスを使用します。 詳細は、「Webサービスを使用したオーダーのインポート」を参照してください。

  • 変更するには1つのチャネルのみを使用します。 たとえば、オーダー改訂の作成を使用して変更を加えたり、webサービスを使用したり、ファイルベースのインポートを使用したりします。 オーダー改訂の作成とwebサービスおよびファイルベースのインポートは使用しないでください。 異なるチャネルを使用すると、変更のソースを識別しようとすると混乱が発生します。

  • 一部の実装では、チャネルでオーダーの価格を設定してから、Order Managementに送信します:

    • チャネルで使用する価格設定をOracle Pricingで使用する価格設定に変更することはできません。

    • Oracle Pricingで使用する価格設定をチャネルで使用する価格設定に変更することはできません。

  • Order Managementは、webサービスを介して受信した変更オーダーをオーダー履行に送信します。 webサービスを介して変更オーダーを送信し、下書きステータスのままにすることはできません。 Order Managementでは、変更オーダーでエラーが発生した場合にのみ、販売オーダーが「下書き」に保持されます。

  • オーダー管理では、下書きステータスの販売オーダーは更新されません。

  • 「オーダー管理」作業領域で「オーダー改訂の作成」を使用し、オーダーを再度改訂する必要がある場合は、「オーダー改訂の作成」を再度使用します。 webサービスまたはファイルベースのインポートを使用してオーダーを再度改訂しないでください。

属性値の管理:

  • 販売オーダーのラインを1つのみ変更する場合、すべての販売オーダー・ラインをインポートする必要はありません。

  • オーダー明細を取り消すには、数量0をインポートします。

  • オーダー管理では、チャネルが送信しないオーダー明細属性ごとに属性値が空に設定されます。 たとえば、元のオーダーに出荷方法の値が含まれ、チャネルが出荷方法を含まない変更リクエストを送信した場合、オーダー管理では出荷方法が空に設定されます。

  • チャネルがオーダー・ヘッダーのみを改訂した場合、オーダー管理はヘッダーを改訂しますが、オーダー明細は改訂しません。

  • チャネルには各必須属性の値が含まれている必要があります。

  • オーダー明細を取り消すには、チャネルで明示的に取消をリクエストする必要があります。 オーダー管理では、販売オーダーの改訂時にオーダー明細が暗黙的に取り消されることはありません。

履行のオーケストレーション

「設定および保守」作業領域の「オーケストレーション・プロセス定義の編集」ページを使用します。 詳細は、「オーケストレーション・プロセスの設定」を参照してください。

ページ作業領域のオーケストレーション・プロセス定義の編集「設定および保守」

次の属性を管理できます:

属性

説明

変更原価ルール

変更を処理した結果、組織で発生するビジネス原価を指定する、オーケストレーション・プロセスに設定するルール。

変更モード

オーケストレーション・プロセスに設定するオプション。 オーダー管理がプロセスの状態を記録するタイミングを決定します。 販売オーダーを補正するときに、これらの状態が比較されます。

値の選択:

  • 詳細 変更処理。 各オーケストレーション・プロセス・ステップでのオーケストレーション・プロセスの状態を記録します。

  • Simple. 変更を処理するのは、変更を受信したステップのみです。 オーケストレーション・プロセスの開始時およびオーケストレーション・プロセスが変更を受信するステップでの状態を記録します。

  • なし 変更を許可しません。 オーケストレーション・プロセスの状態を記録しません。

フレックスフィールド属性の使用

オーケストレーション・プロセスまたはオーケストレーション・プロセス・ステップで、販売オーダーを補正するときにフレックスフィールド属性を調べるかどうかを指定するオプション。

このオプションを有効にすると、オーダー管理は、品目が参照するフレックスフィールド属性を調べて、オーケストレーション・プロセスを補正する必要があるかどうかを判断します。

Colorという名前のフレックスフィールドを作成するとします。 ユーザーが色の値を赤から青に変更したとします。 報酬の間に色を使用すると、履行システムでオーダー明細を再スケジュールして、赤い品目ではなく青い品目を出荷できます。

オーダー管理では、事前定義の各オーケストレーション・プロセスでフレックスフィールド属性の使用およびトランザクション品目属性の使用がデフォルトで無効になっています。 これらのオプションは、事前定義済オーケストレーション・プロセスでは有効にできません。 ただし、事前定義済オーケストレーション・プロセスのコピーを作成してから、そのコピーで有効にできます。

トランザクション品目属性の使用

販売オーダーの補正時にトランザクション属性を調べるかどうかを指定する、オーケストレーション・プロセスまたはオーケストレーション・プロセス・ステップに設定するオプションです。 詳細は、「トランザクション属性の管理」を参照してください。

報酬中にこれらの属性を履行システムに送信する場合にのみ、「フレックスフィールド属性の使用」オプションおよび「トランザクション品目属性の使用」オプションを有効にします。

動的属性の使用

販売オーダーを補正するときに動的属性を調べるかどうかを指定するオプション。

報酬パターン

オーダーの変更時に販売オーダーに対して行う調整を指定する、オーケストレーション・プロセス・ステップに設定するルール。

たとえば、オーダー管理が出荷の作成ステップで別の倉庫から品目を出荷するように指定した変更オーダーを受け取った場合、取消サービスと作成サービスが再度実行されます。

報酬パターンを指定しない場合、オーダー管理ではデフォルトで事前定義済の報酬パターンが使用されます。 事前定義済パターンでは、更新、取消または作成が使用されます。

タスク・タイプ

オーケストレーション・プロセス・ステップに設定した属性。 選択したタスク・タイプによって、オーダー管理がこのステップの販売オーダーを補足する必要があるかどうかを決定する際に使用される属性が決まります。

オーダー管理には、事前定義済タスク・タイプごとに属性セットを使用するように事前定義されています。 事前定義済の設定は変更できませんが、属性を追加することはできます。 Order Managementでは、追加した新しいタスク・タイプにこれらの属性は追加されず、これらの属性を追加するまでこのタスクは評価されません。 これらを追加するには、「すべて追加」をクリックする必要があります。

供給を予約

将来の供給に従ってオーダー明細を予約またはスケジュールする場合は、オーケストレーション・プロセスに予約ステップが必要かスケジュール・ステップが必要かを検討します。 たとえば、予約ステップでは、現在使用可能な供給が調査され、履行システムで品目を履行できるように予約されます。 供給を予約する必要がない場合は、予約ステップを含めないでください。 予約が必要な場合は、予約ステップを手動ステップにすることを検討してください。たとえば、ユーザーは予約などのボタンをクリックする必要があります。

予約またはスケジュール・ステップの前に一時停止ステップを追加することもできます。 一時停止タスクでは、出荷の準備がほぼ完了するまで(出荷予定の12時間前など)、オーケストレーション・プロセスを一時停止できます。 予約ステップが実行されると、出荷日に近いため、より正確な供給状況が提供されます。 この方法で供給を予約すると、出荷時期になるまで在庫を保持するコストを削減することもできます。

変更原価のルールの設定

変更原価のルール

ノート

  • 変更コストを測定するルールを設定します。 高すぎる場合は、変更を拒否します。

  • オーケストレーション・プロセスのヘッダー領域で、変更コスト・ルールの横にある「ルールのクリック」をクリックします。

  • 拡張モードを使用します。

  • Assignアクションを使用します。

  • 数値をHeader.mRuleDecision.costOfChangeに割り当てます。 たとえば:

    Header.mRuleDecision.costOfChange = 10

報酬の設定

報酬の設定

ノート

  • 報酬ルールは変更に対してのみ使用します。 他の属性の値も設定する必要がある場合は、変換後ルールを使用します。

  • オーケストレーション・プロセスのステップ領域で、補正する必要があるステップの「報酬パターン」列で、「ルールのクリック」をクリックします。

  • 拡張モードを使用します。

  • IF文で:

    • attributeChangedやChangedなどの変更関数を使用します。

    • 変更した属性を指定します。 たとえば、ユーザーが品目属性を変更した場合は、INVENTORYITEMIDを使用します。

  • たとえば:

    Fline.attributeChanged(DooSeededOrchestrationRules.IFLine. INVENTORYITEMID)is true

    指定できる属性のリストを取得します。 詳細は、「Order Managementと他の統合時に使用できるエンティティおよび属性Oracle Applications」を参照してください。

  • THEN文:

    • Assignアクションを使用します。

    • たとえば:

      header.mRuleDecision.compensationPattern = "CANCEL_CREATE"

    • 値を割り当てます。

      説明

      UPDATE

      現在の履行リクエストを最新の属性値で更新します。

      各オーケストレーション・プロセスは、デフォルトでUPDATEを使用するように事前定義されています。 報酬パターンを指定せず、オーケストレーション・プロセスで変更が検出された場合、更新リクエストが履行システムに送信されます。

      UPDATE_CREATE

      現在の履行リクエストを最新の属性値で更新し、新しいリクエストも作成します。

      CANCEL_CREATE

      現在の履行リクエストを取り消し、最新の属性値を含む新規リクエストを作成します。

      CANCEL_UPDATE

      現在の履行リクエストを取り消してから、最新の属性値で別の履行リクエストを更新してください。

      CANCEL_UPDATE_CREATE

      現在の履行リクエストを取り消し、最新の属性値を使用して別の履行リクエストを更新してから、最新の属性値を含む新しいリクエストを作成します。

      NOOP

      NOOP (操作なし)。 心配するな。

      これらの値は、オーケストレーション・プロセスが履行システムに送信するリクエストを決定します。

変更の制約

処理制約を使用します:

  • サプライヤが生産するためにかなりのリード・タイムを必要とする品目のサプライヤの変更など、履行システムが対応できないことがわかっている変更を許可しません。

  • 履行システムで対応できない変更がチャネルで発生していないことを確認してください。

  • ユーザーに必要な属性が含まれていることを確認してください。 請求には独自の数値属性xを追加し、請求では請求書を計算するために属性xが必要であるとします。 制約を使用して、ユーザーがxの値を追加し、その値が数値であることを確認できます。

  • 制約がビジネス要件を満たしていない場合は、オーダー管理拡張を使用して検証し、メッセージまたは警告を表示します。

処理制約の管理ページ

ノート

  • 制約エンティティ属性をオーダー履行明細に設定します。

  • 事前定義された制約で使用可能属性がアクティブな場合は、無効にできます。 制約を削除しても実装に悪影響が及ばないことを確認した後にのみ、事前定義済制約を使用不可にします。

  • 制約全体でAND条件を作成するには、グループ番号属性で同じ値を使用します。 たとえば、条件xでグループ番号を10に設定し、条件yでグループ番号を10に設定し、条件xとyの両方がTrueと評価された場合、オーダー管理では制約が適用されます。

  • OR条件を作成するには、グループ番号で異なる値を使用します。 たとえば、条件xでグループ番号を10に設定し、条件yでグループ番号を20に設定し、条件xまたはyがTrueと評価された場合、オーダー管理では制約が適用されます。

  • 「適用可能ロール」タブを使用して、制約に従って属性を編集できるユーザー・ロールまたは編集できないユーザー・ロールを指定します。

  • 「設定および保守」作業領域の「処理制約の管理」ページを使用します。

  • 詳細は、「処理制約の管理」を参照してください。

たとえば:

処理制約の管理のフロー

この制約が実装するロジックを次に示します。

Prevent user from updating attribute Supplier on fulfillment line.

次の値を設定します:

属性

制約エンティティ

オーダー履行明細

制約付き工程

更新

属性名

サプライヤ

使用可能

チェック・マークが含まれます

変更を識別する属性の管理

変更を識別する属性の管理のフロー

この例では、条件を実装します。

If the user changes Quantity on fulfillment line, then perform compensation during shipping.

ノート

  • ユーザーは改訂を作成し、「発行」をクリックしてから、Order Managementでオーケストレーション・プロセスを開始します。

  • オーケストレーション・プロセスは、出荷タスク・タイプを使用するステップに到達し、「設定および保守」作業領域の「変更を識別するオーダー属性の管理」ページを調べ、変更を処理するかどうかを決定します。

  • 詳細は、変更を識別するオーダー属性の管理を参照してください。

たとえば:

属性タスク・タイプの設定

ノート

  • タスク・タイプ属性をスケジュール、予約、出荷などの値に設定して、変更をいつ調べるかを決定します。

  • 属性が存在する場所を決定するエンティティを指定します:

    • オーダー履行明細

    • オーダー明細

    • オーダー・ヘッダー

  • 検査する属性(オーダー数量など)を指定します。

  • 追加処理を使用して、属性を追加します。

  • オーダー数量などの事前定義済属性を追加できますが、無効にすることはできません。

その他のガイドライン

オーダー改訂の作成を使用する場合、オーダー管理では変換前ルールは実行されません。 オーダー改訂の作成の使用時にユーザーが追加する新規オーダー明細にデフォルト属性値を設定する必要がある場合は、デフォルト値を設定する変換後ルールを作成します。

履行ビューを使用して、多数の履行明細を変更できます。 変更ごとに実行する必要があるビジネス・ルールをいくつか設定し、大量の変更を送信すると、パフォーマンスが低下する可能性があります。 環境で対応できる履行明細更新の数をテストし、履行ビューからの更新をパフォーマンス要件を満たすように制限する必要があります。