機械翻訳について

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

オーダー履行中に発生した変更の処理方法(変更に対する支払方法を含む)を指定する場合は、ガイドラインを適用します。

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

様々なチャネルを通じて変更オーダーをインポートします。

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

ノート

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

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

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

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

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

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

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

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

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

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

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

属性値の管理。

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

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

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

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

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

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

オーケストレーション・プロセスの設定

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

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

機能を管理できます。

機能

説明

変更原価ルール

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

変更モード

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

値を選択します。

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

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

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

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

販売オーダーの報酬支払時にフレックスフィールド属性を確認するかどうかを指定する、オーケストレーション・プロセスまたはオーケストレーション・プロセス・ステップで設定するオプション。

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

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

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

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

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

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

動的属性の使用

販売オーダーの補正時に動的属性を確認するかどうかを指定するオプション。

報酬パターン

オーダーが変更されたときに販売オーダーに加える調整を指定する、オーケストレーション・プロセス・ステップで設定するルール。

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

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

タスク・タイプ

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

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

供給を予約

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

予約またはスケジュール・ステップの前に一時停止ステップを追加することもできます。 一時停止タスクでは、出荷の準備がほぼ完了するまで(出荷予定の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.

ノート

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

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

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

たとえば:

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

ノート

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

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

    • オーダー履行明細

    • オーダー明細

    • オーダー・ヘッダー

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

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

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

その他のガイドライン

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

ユーザーは、履行ビューを使用して、多数の履行ラインを変更できます。 各変更に対して実行する必要があるビジネス・ルールをいくつか設定し、ユーザーが大量の変更を送信すると、パフォーマンスの低下が発生する可能性があります。 環境に対応できる履行明細更新の数をテストし、最適に応じて履行ビューから更新を制限する必要があります。