処理制約
処理制約を使用して、ユーザーが販売オーダーに対して実行できる変更を制御できます。
処理制約は、販売オーダーを変更できるユーザー、販売オーダーで変更できる内容、および変更が発生するタイミングを制御するルールです。 たとえば:
-
オーダー入力スペシャリストが販売オーダー、オーダー明細または履行明細の発行または変更を試行し、処理制約で発行または変更が許可されない場合は、拒否してメッセージを表示します。
-
ソース・システムが販売オーダーを発行または変更しようとした場合は、販売オーダーを否認して返品メッセージを送信します。
また、オーダー管理では、事前定義された処理制約を使用して、各履行リクエストにリクエストの処理に必要な属性が含まれていることを確認します。
例
|
制約の例 |
説明 |
|---|---|
|
販売オーダーが出荷時に変更を拒否します。 |
オーケストレーション・プロセスが販売オーダーの出荷ステージを達成し、ユーザーが変更を送信したとします。
オーケストレーション・プロセスが出荷ステップを達成した後に変更を拒否する制約を作成します。 |
|
必須属性を含まない各販売オーダーを拒否します。 |
会社が出荷先担当を含まない住所に品目を搬送していないとします。 販売オーダーに出荷先担当が含まれていない場合に、販売オーダーを拒否する制約を作成します。 |
|
承認が必要な変更を否認します。 |
トランザクション値が$10,000を超えた場合、およびマネージャが変更を承認していない場合、オーダー入力スペシャリストが変更を送信できないとします。 これらのすべての条件がtrueの場合に変更を拒否する処理制約を作成します。
|
処理制約の構成要素
|
部品 |
説明 |
|---|---|
|
ロール |
制約が参照するジョブ・ロールでは、変更を行うことはできません。 たとえば、オーケストレーション・プロセスが指定したステップを超えたときに、オーダー入力スペシャリストが販売オーダーを変更しないように制限できます。 |
|
処理 |
制約で許可されない処理。 ユーザーがこれらのアクションを実行しないように制限できます。
|
|
条件 |
制約を適用するかどうかを決定するために制約が評価する条件。 たとえば、オーダー管理が販売オーダーを発行するときに制約を適用する条件を作成できます。 |
このトピックでは、事前定義済ジョブ・ロールを使用します。 セキュリティ要件に応じて、独自のジョブ・ロールを作成する必要があります。 詳細は、「Order Managementの実装に必要な権限」を参照してください。
仕組み
処理制約では、次のロジックが適用されます:
-
検証ルール・セットがtrueで、ユーザーが処理制約によって防止されるレコード・セットに対する処理を試行した場合は、操作を制約してメッセージを表示します。
例について考えてみます。
この例の動作は次のとおりです:
|
ステップ |
オブジェクト |
説明 |
|---|---|---|
|
1 |
処理制約 |
オーダー入力スペシャリスト・ロールが履行明細エンティティに対して更新操作を行う場合: |
|
2 |
検証ルール・セット |
また、履行明細エンティティの「ステータス」属性に「出荷待ち」の値が含まれている場合は、次のようになります: |
|
3 |
制約エンティティ |
次に、オーダー入力スペシャリストが行おうとしている変更を制約します: |
|
4 |
レコード・セット |
履行明細エンティティの請求先顧客属性に従って。 |
別の例
オーダー・ヘッダーの有効でない処理制約に関する事前定義済の出荷方法について考えてみます。
|
この適用可能なロールの場合 |
この制約付き操作の実行の試行 |
この制約エンティティ |
この検証ルール・セットがTrueの場合 |
変更の否認およびこのメッセージの表示 |
|---|---|---|---|---|
|
すべて |
送信 |
オーダー・ヘッダー |
オーダー・ヘッダーの出荷方法が無効です |
オーダー・ヘッダーの出荷方法を決定する輸送モード、サービス・レベルおよび運送業者の組合せが無効であるため、販売オーダーを送信できません。 |
オーダー・ヘッダーの出荷方法が無効ですルール・セットでは、オーダー・ヘッダーの輸送モード、サービス・レベルおよび運送業者が参照されます。 これらの属性の1つに値が含まれている場合、すべての属性に値が含まれている必要があります。 いずれかに値が含まれているが、すべてではない場合、ルール・セットはtrueと評価され、処理制約によって送信が防止されます。
処理制約に設定するオブジェクト
|
オブジェクト |
説明 |
|---|---|
|
検証ルール・セット |
1つ以上のIf文のグループ。 たとえば:
この例では、Order is Closed(オーダーがクローズ済)という事前定義の検証ルール・セットによって、オーダー・ヘッダーのOpen(オープン)属性が調査され、値がNであるかどうかが判別されます。 ノート
|
|
レコード・セット |
制約を評価できるように、オーダー管理で共通属性値に従ってグループ化される一連のレコード。 たとえば、顧客のすべての販売オーダーを評価するには、レコード・セットの作成時にこれらのエンティティのいずれかを評価するように指定します。
次に、属性を選択してレコード・セットを絞り込むことができます。 たとえば、顧客のすべての販売オーダーを評価するには、オーダー・ヘッダー・エンティティを選択し、販売先顧客属性を選択します。 検証ルール・セットとレコード・セットは連携して、制約によって処理が制約される条件を作成します。 最初に検証ルール・セットとレコード・セットを作成してから、制約を作成する必要があります。 |
|
制約エンティティ |
制約が制約するビジネス・オブジェクトまたはオーケストレーション・プロセス。 たとえば、オーダー・ヘッダーやオーダー・ヘッダーの属性(最遅許容出荷日など)です。 |
|
制約パッケージ |
オーダー管理がOracleデータベースの表に適用するトリガー・セット。 制約パッケージを作成すると、バックグラウンド・プロセスによってトリガーが設定されます。 制約パッケージでは、新規または変更をアクティブ化できます。
制約パッケージを作成する方法を次に示します。
表タイプではない検証の制約パッケージを作成する必要はありません。 |
制約名
制約名で使用できるテキスト文字列を次に示します。
|
テキスト文字列 |
次を使用して検証中に実行される制約 |
|---|---|
|
GTM |
Oracle Global Trade Management。 |
|
PAYMENT |
支払 |
|
PRICING |
価格設定 |
|
制約名にGTM、PAYMENTまたはPRICINGが含まれていません |
オーダー検証中のすべてのタイプの画面。 |
たとえば、支払を指定するには、DOO_PAYMENT_EXCEPTIONを使用します。
テキスト文字列のテキスト・スタイルでは、大文字と小文字は区別されません。 たとえば、GTM, Gtm, gtm, gtMなどを使用します。
テキスト文字列は、制約名の任意の場所に配置できます。
Order Managementでの制約のメッセージの表示方法
通常、Order Managementでは、Order Management作業領域の制約のメッセージ属性に入力した値が表示されます。 ただし、履行ビューで一部の処理に関するメッセージは表示されません。
出荷ステージの各履行明細を編集できないようにする制約を作成し、このテキストを制約のメッセージ属性に追加するとします。
You can't update the fulfillment line because its in the shipping stage.
実行時に、次のことを行います:
- 100件のオーダー明細を含む販売オーダーを作成し、「送信」をクリックします。
- 数日待ちます。 待機している間、Order Managementは100件のオーダー明細のうち70件を出荷します。
- 順序を開き、「履行ビューに切り替え」をクリックします。
オーダー・ページで、「履行明細」をクリックし、すべての100行を選択して、「処理」>「編集」をクリックします。
Order Managementでは、すべての明細に対して処理を実行できないが、制約のメッセージを表示すると予想したことを示す警告が表示されます。 Order Managementでは、制約のメッセージ属性の値が表示されません。これは、そのメッセージの70個の個別のインスタンスが表示されるためです。 かわりに、警告ダイアログでOKをクリックすると、Order Managementに制約のない30行を編集できるダイアログが表示されます。
事前定義済処理制約
Order Managementには、事前定義された処理制約がいくつか用意されています。 次のものを表示できます:
- 「設定および保守」作業領域に移動してから、タスクに移動します。
- オファリング: オーダー管理
- 機能領域: オーダー
- タスク: 処理制約の管理
- 「処理制約の管理」ページで、「制約名」属性で値を検索します:
- DOO
- 履行
- オーダー
別の方法として、「制約エンティティ」属性をフィルタします。
- 検索結果を確認します。 Order Managementの動作を制御する様々な制約が含まれています。 「メッセージ」属性を確認して、各制約が実行時に表示されるメッセージを表示します。
販売実績の制約
オーダー・ヘッダーに販売実績があり、Order Managementが販売オーダーの明細をクローズした場合、または請求する明細をインタフェースした場合、DOO_HEADER_SALECREDITS_UPDATE制約によってその与信を変更できません。 この制約は、使用可能として事前定義されています。 有効にしたままにしておくことをお薦めしますが、必要に応じて一時的に無効にできます。 たとえば、与信を割り当てた営業担当が営業マネージャになったため、他のユーザーに割り当てる必要があります。
- 販売オーダーを作成し、オーダー・ヘッダーの販売実績をJune Tsaiに割り当て、2つのオーダー明細を追加して送信するとします。 履行時に、Order Managementは明細1をクローズし、明細2を出荷待ちに設定します。
- June Tsaiはマネージャに昇格されるため、営業担当として6月を使用不可にします。
- 顧客が明細2の改訂をリクエストするため、販売オーダーを改訂する必要があります:
- 「設定および保守」作業領域に移動し、「処理制約の管理」ページを使用してDOO_HEADER_SALECREDITS_UPDATE制約「Generate Packagesをクリック」を無効にします。
- 「オーダー管理」作業領域に移動し、販売オーダーの改訂を作成します。
- 改訂で、「販売実績」の横にある鉛筆をクリックし、「営業担当」属性を「Diane Cho」などの他のユーザーに設定します。
- 明細2を更新し、改訂を発行します。
- 「処理制約の管理」ページを使用して、DOO_HEADER_SALECREDITS_UPDATE制約「パッケージの生成」を有効にします。
営業担当の作成方法のバックグラウンドは、My Oracle Supportの「営業担当の定義方法(ドキュメントID 2155741.1)」を参照してください。
その他
-
条件を含まない制約を設定した場合、その制約は常にtrueになります。 たとえば、オーダー入力スペシャリストが販売オーダーを削除できないようにする事前定義の処理制約によって、すべての状況で削除が防止されます。
-
拡張可能フレックスフィールドでは制約を使用できます。
-
販売実績の制約を作成できます。 たとえば、オーダー管理がすでにオーダー明細を出荷した場合に、ユーザーが販売実績を更新できないようにする制約を記述します。 販売実績を制約する検証ルール・セットは作成できません。 たとえば、販売実績が空の場合、ユーザーが倉庫を更新できない制約を記述することはできません。
-
ANDおよびOR条件の設定方法など、制約を使用して変更を管理する方法について学習します。 詳細は、「オーダー履行中に発生する変更管理のガイドライン」を参照してください。