オーダー履行時に発生する変更の管理の概要
オーダー管理には、変更を処理するために事前定義されていますが、ニーズにあわせて設定を変更できます。
変更オーダーは、オーダー履行中に販売オーダーに影響する変更です。 ユーザーからオーダー取得システム、オーダー管理作業領域を使用するユーザー、インポートした変更オーダーなど、様々なソースから取得できます。 たとえば、オーダー履行に送信した後、販売オーダーに変更を加える必要がある場合があります。
-
数量および出荷先住所を変更します。
-
昨日作成した販売オーダーに品目をさらに追加します。
-
販売オーダーを取り消すか、オーダー明細を取り消します。
-
ピック・リリース後など、ある時点以降または条件が発生した後は、販売オーダーの変更を許可しないでください。
次に、変更が発生する例を示します。
-
オーダー入力スペシャリストは、オーダー改訂の作成処理を使用して、販売オーダーの改訂や履行ビューの変更を行います。 Order Managementでは、ユーザーが履行ビューに変更を加えると、オーダー管理拡張は適用されません。 詳細は、送信済の販売オーダーの改訂を参照してください。
-
チャネルから変更をインポートします。
変更オーダーの仕組み
オーダー管理で変更の処理に使用する順序を次に示します。
-
「変更オーダーの受入」. チャネルから変更オーダーを受け取ります。
-
制約付き? 処理制約を適用します。
処理制約は、販売オーダーを変更できる担当者、当該販売オーダーで変更可能な箇所、および変更が発生する時期を制御するルールです。
オーダー管理は、ヘッダーと履行明細を調べます。
エンティティ
説明
オーダー・ヘッダー
ヘッダーの処理制約によって変更が防止されるかどうか、および販売オーダーがクローズされるかどうかを決定します。
-
制約が変更を許可しない場合、またはオーダーがクローズされている場合は、変更全体を拒否してこの順序を終了します。
-
オーダー明細を評価する前にオーダー・ヘッダーを評価すると、オーダー管理はクローズ済販売オーダーを不必要に処理できなくなります。
-
オーダー管理では、ユーザーが改訂を作成するときに属性を評価し、ユーザーが改訂を発行して、オーダーに影響を与える可能性がある他の履行変更が発生しなかったことを確認します。
履行明細
履行明細の制約で変更を許可するかどうかを決定します。
-
制約で履行明細の変更が許可されていない場合は、変更全体を拒否し、この順序を終了します。
-
履行明細の一部の制約では、履行明細ステータスが出荷済の場合のオーダー明細の更新など、一部の変更はデフォルトで許可されません。
-
-
「変換」. 変更オーダーを変換します。
オーダー管理は、ソース・オーダーの属性値を履行システムで理解できる値に変換するなど、設定した変換を実行します。 詳細は、「変換ルール」を参照してください。
変更オーダーに影響するオーダー管理拡張を作成すると、Order Managementは変換を終了し、拡張を実行します。
-
「デルタ?」. デルタは、元の販売オーダーの属性値と変更オーダーの属性の新しい値の差です。 たとえば:
条件
説明
元のオーダーの数量は1で、改訂オーダーの数量は3です。
デルタが存在し、その値は2です。
元のオーダーの数量は1で、改訂オーダーの数量は1です。
デルタが存在しません。
オーダー管理がデルタを決定する方法を次に示します。
-
どの属性を調べるかを決定するために設定を調べます。
-
「変更を識別するオーダー属性」ページで指定した値を使用します。
-
タスクに影響する事前定義済属性を調べます。 これらの事前定義済属性を検査するかどうかは指定できません。
-
タスクに影響する追加属性を調べます。 追加した属性を検査するかどうかを指定できます。
-
-
これらの属性を参照するオーケストレーション・プロセス・ステップを識別します。
-
各ステップの状態を分析します。 オーケストレーション・プロセスでは、タスクを実行するたびに状態が記録されます。 オーダー管理では、変更オーダーと既存の販売オーダーを比較して、属性の値が変更されたかどうかを判断します。
-
これらの状態の詳細を使用して、変更の組み込みに必要な処理を決定します。
この例では、ユーザーが数量を変更し、変更属性として数量を指定すると、オーダー管理で報酬が開始されます。
-
-
「現在のタスクを保留」. デルタが存在する場合は、現在実行中のタスクを保持します。
オーケストレーション・プロセスがオーダー履行ですでに処理している販売オーダーの変更リクエスト。 オーケストレーション・プロセスでは、オーダー履行中に様々なタスク(スケジュール、予約、出荷、請求書など)が実行されます。
たとえば、オーケストレーション・プロセスが出荷システムに品目を出荷するリクエストを送信し、出荷システムが応答を送信するのを現在待機しており、ステータスが出荷待ちに設定されているとします。 変更オーダーは出荷に影響する可能性があるため、オーダー管理は出荷システムにリクエストを送信して、タスクの処理を一時的に停止します。
タスクを停止すると、オーダー管理は変更を完了し、変更オーダーがリクエストした変更なしで出荷システムで販売オーダーを出荷できなくなります。
履行システムで変更に対応できない場合は、拒否で応答し、連番が終了します。 たとえば、履行システムが販売オーダーをすでに出荷している場合は、変更に対応するには遅すぎます。 かわりに、オーダー入力スペシャリストは、リクエストされた変更を行うために返品オーダーを作成する必要があります。
-
マージ オーケストレーション・プロセスが現在処理している販売オーダーに変更オーダーをマージします。
-
Compensate.
補正
報酬パターンとは、オーケストレーション・プロセス・ステップで設定するルールで、オーダーが変更されたときに実行する調整を指定します。
たとえば:
-
別の倉庫を使用するように変更オーダー・リクエスト。
-
出荷の作成ステップの報酬パターンはやり直しです。
-
このステップでは、現在のリクエストを取り消すために取消サービスをコールし、変更オーダーを含む新しいリクエストを作成するためにサービスを作成します。
-
オーダー管理は、このステップの新規倉庫を含む変更オーダーを受け取ると、取消および作成を再実行します。
報酬がどのように機能するかを次に示します。
-
「デルタをチェック」. 現在のタスクに影響するデルタが存在するかどうかを確認します。 たとえば、現在のタスクが予約で、数量属性のデルタが存在する場合、オーケストレーション・プロセスが変更オーダーを反映するように予約数量を調整する必要があるため、デルタは予約タスクに影響を与えます。
属性に報酬が必要であるとデルタが判断した場合、オーケストレーション・プロセスでは、ステップが参照する報酬パターンを使用してステップを補正します。
-
「補正」. オーダー管理の機能を次に示します。
-
オーケストレーション・プロセスを再度実行します。
-
各タスクの履行システムに更新を送信します。 変更された属性がタスクに影響しない場合、オーケストレーション・プロセスは属性変更を販売オーダーに適用しますが、履行システムに更新を送信しません。
報酬パターンに従って実行する処理を決定するビジネス・ルールを設定できます。
ほとんどのオーケストレーション・プロセス・ステップには報酬パターンが含まれず、デフォルトで更新が使用されます。 この例では、オーダー管理はいくつかのステップを補います。
オーダー管理が補うステップ
説明
スケジュール
スケジュール・ステップを取り消し、このステップの新規インスタンスを作成します。 Order Promisingによって可用性が決定されます。 オーダー管理では、履行を再実行し、各オーケストレーション・プロセス・ステップに改訂日を割り当てます。
予約の作成
この例のオーケストレーション・プロセスに予約の作成ステップのパターンが含まれているとします。
-
需要区分コードがゴールドでない場合は、予約の作成ステップを取り消して、このステップの新規インスタンスを作成します。
このルールは、オーダー管理に供給をリリースし、Gold顧客を除くすべての顧客に対して新規予約を作成するよう指示します。 オーダー管理では、新しい日付に従って予約の作成も更新され、予約数量が更新されます。
出荷リクエストの作成
新規日付および新規品目で出荷リクエストの作成ステップを更新します。
補正サービスが実行され、終了します。 これらのサービスは、デフォルトでFIFO (先入れ先出し)シーケンスを使用して、オーケストレーション・プロセス・シーケンスに従って販売オーダーを補正します。 オーダー管理で販売オーダー全体を取り消す必要がある場合は、LIFO (先入れ先出し)が使用されます。
元のオーケストレーション・プロセスの場合。
-
変更に対応できます。 オーダー管理では、元のオーケストレーション・プロセスを使用して処理を続行します。
-
変更に対応できません。 オーダー管理では、元のオーケストレーション・プロセスが取り消され、変更に対応できる新しいオーケストレーション・プロセスが開始されます。
-
-
「更新の送信」. 報酬が終了します。 オーケストレーション・プロセスの処理は、オーダー管理が変更オーダーを受け取ったときと同じステップになりました。
オーダー管理は、更新メッセージを履行システムに送信し、変更された属性を含む変更済オーダーで元のメッセージを更新します。 たとえば:
値
説明
元値
数量は1で、到着日は2018年8月15日です
報酬後の値は、変更された属性を含む変更オーダーに対して在庫の更新メッセージを送信します。
数量は2で、到着日は2018年8月18日です
変更処理の例
オーダー・エントリ・スペシャリストが数量を変更したときに変更を補うようにオーダー管理を設定する必要があるとします。
ShipOrderGenericProcessオーケストレーション・プロセスを作成します。 使用する設定は次のとおりです。
|
設定 |
値 |
|---|---|
|
変更モード |
詳細 |
|
変更を識別するオーダー属性 |
属性を含めます。
|
|
変更原価 |
ルールを指定します。 履行明細ステータスが次の場合。
数値が小さいほどコストが低くなります。 |
ステップを追加します。
|
ステップ |
名前 |
タスク・タイプ |
|---|---|---|
|
1 |
スケジュール |
スケジュール |
|
2 |
予約の作成 |
予約 |
|
3 |
出荷リクエストの作成 |
出荷 |
|
4 |
出荷通知の待機 |
出荷 |
|
5 |
請求書の作成 |
請求書 |
|
6 |
請求書の待機 |
請求書 |
各ステップはタスク・タイプを参照し、各タスク・タイプは、オーダー管理が販売オーダーを補正するかどうかを決定するために使用するオーダー属性を参照します。 この例では、スケジュール・ステップと出荷ステップがそれぞれ、オーダー数量属性を参照するタスク・タイプを参照します。
たとえば、ユーザーが販売オーダーの数量を増やす場合、オーダー管理ではより多くの供給をスケジュールして出荷する必要があります。
-
オーダー入力スペシャリストが数量1のAS54888デスクトップ・コンピュータの販売オーダーを発行するとします。
-
1日後、オーダー入力スペシャリストは改訂の作成をクリックし、数量を2に変更し、発行をクリックします。
オーダー管理は、スケジュール・ステップと出荷ステップを補います。