ルールとルール・セット
ルールは、品目および構成の属性に対する整合性制約を定義します。 操作上およびユーザー定義属性に対して整合性制約を定義できます。
整合性制約はビジネス・ルールを実装でき、ルール・フレームワークを使用して作成されます。 たとえば、最小速度は最大速度より小さくする必要があるというルールが考えられます。
ルール・セットでは複数のルールがまとめて収集され、属性グループ、品目区分、変更タイプ、構成タイプなどの属性のソースに関連付けられます。 特定のソース(属性グループ名など)は、ルール・セットの一部として定義されます。 ルール・セットには、品目や品目サプライヤ、品目改訂などの有効なビジネス・エンティティもリストされます。 ルール・セットと特定の属性ソースとの関連付けによって、ルール・セット内のルールに入力されたルール式が、許容可能なエンティティをチェックして検証できるようになります。
各属性は、ビジネス・エンティティと属性グループ名、その後に属性名で参照されます。 たとえば、[Item].[Physical Attributes].[Unit Volume]です。 この例では、[Item]は品目属性、[Physical Attributes]は属性グループの表示名、[Unit Volume]は属性の表示名を示します。
次の点を考慮してください。
-
ルール・セットが属性グループに関連付けられている場合は、そのグループ内の属性のみがそのルールで使用できます。
-
ルール・セットが品目区分に関連付けられている場合は、その品目区分に有効な属性グループのみがそのルールで使用できます。
ルール・セット下書きのステータスを設定できます。 ルール・セットのドラフトが完了するまで、ルール・セットをドラフト・ステータスに保持できます。 ルール・セットがドラフト・ステータスの場合、通常のトランザクションが完了してもルール・セットはトリガーされません。 この間、ルール影響分析を実行して、選択した既存の品目のセットに対するルール・セットの影響をシミュレートおよび調査できるため、必要な変更を行うことができます。 シミュレーションの実行中、ドラフト・ルール・セットと他のアクティブなルール・セットが、選択した品目のセットに適用され、その影響は非同期スケジュール済プロセスによって取得されます。
新規品目リクエストおよび変更オーダー・タイプに関連付けられたルール・セットを使用して、新規品目リクエストおよび変更オーダーの識別番号が生成されます。
ルール・セットとルールのタイプは次のとおりです:
-
アサイメント
-
検証
-
ブレンド
-
複合
アサイメント
割当ルール・セットは、指定された条件に基づいて品目属性の値を決定します。
通常の英語で表される割当ての例を次に示します: リード・パーセントは、リード・マス合計をユニット重量で除算した値です。
ルールを作成したら、検証して保存します。 次に、必要に応じて後続のルールを入力します。 ルールは、ルール・セット内の順序に従って実行されます。 したがって、属性の式が以前に計算された値に依存している場合は、ルールで属性より前の値が表示され、したがって最初に計算されるようにする必要があります。 通常、割当のルール・セットは検証のルール・セットより前に実行する必要があるため、確信できる割当結果に対して検証条件を記述できます。
- 変更ヘッダー属性および拡張可能フレックスフィールドを割当ルールに含めて、変更ヘッダー属性およびフレックスフィールドに値を割り当てることができます。
- 次の属性は、変更時に作成された番号割当ルールではサポートされていません: 承認日、割当先、変更ID、作成者、作成日、希望入手日、事由およびリクエスト者。
-
複数行拡張可能フレックスフィールドは、変更の番号生成ルールではサポートされていません。
-
Groovyスクリプトは、拡張可能フレックスフィールドを使用した変更に対する検証および割当ルールの作成にはサポートされていません。 そのため、品目ルールを使用することをお薦めします。
検証
検証ルール・セットは、品目に定義されている属性値に基づいて条件を検証します。 検証ルール・セットは、通常、品目の事前定義済ビジネス・ルールをモデル化するために使用されます。
検証ルールは、品目に関連品目として追加できる品目を制限し、品目に対して許可できる関係タイプを制限します。 この制限は、標準運用属性または拡張可能フレックスフィールドである品目または品目改訂レベルの属性に基づくことができます。
「品目の更新」ページに移動し、適切な属性グループを編集して、検証をテストします。 更新された値はルールに対して検証され、エラー・メッセージが画面に表示されます。
検証ルールの重大度によって、検証が失敗した場合に実行される処理が決まります。 重大度レベルとその結果として生成されるアクションは次のとおりです:
|
重大度 |
摘要 |
|---|---|
|
警告 |
ビジネス・エンティティは保存できます。 定義した説明メッセージがエンド・ユーザーに表示されます。 ユーザーは警告メッセージを確認して品目を保存する必要があります。 |
|
承認が必要 |
属性データでは、ビジネス・エンティティに対して変更オーダーを作成する必要があります。 |
|
否認 |
ビジネス・エンティティは、属性検証に合格するまで保存できません。 |
実行時エンド・ユーザー・セッション中に検証ルールに対して次の動作が発生します:
-
ルールは、次の状況を除き、変更された属性に対してのみ実行されます。
-
品目の品目クラスが変更されました
-
ルールは有効なコンポーネント・タイプ・ルールです
-
ルールは、
Context.ExecutionDateTimeなどのコンテキスト属性を使用 -
このルールでは、次のいずれかの関数を使用します:
-
exists() -
loopSum() -
conditionalLoopSum() -
assignedToCatalog() -
assignedToOrg()
-
-
-
重大度が拒否の検証に失敗すると、その属性を含むビジネス・エンティティ全体が拒否されます。
-
重大度が承認必要の検証に失敗した場合は、変更オーダーを発行して承認する必要があります。
-
すべての関連属性には変更オーダーも必要です。 このコンテキストでは、関連属性は、変更オーダーを必要とする属性を使用する検証で使用される属性です。 つまり、属性に変更オーダーが必要な場合、その検証ルールの更新済属性(ルールの「IF式」および「検証条件」フィールドに指定されている属性)もすべて同じ変更オーダーの一部である必要があります。
-
割当ルールで計算された属性が後続のルールで使用されている場合は、依存関係の連鎖を形成できます。 データの一貫性を保つために、変更オーダー要件はこの依存関係チェーンに沿って伝播されます。
-
変更オーダー要件は、更新された属性にのみ伝播されます。 属性が更新されない場合は、他の属性には影響しません。
-
ブレンド
品目データを提供する複数のスポーク・システムがある場合は、ブレンド・ルールがインポート時に適用され、ブレンド・ルールで定義した各スポーク・システムのブレンド優先度に基づいて、複数のスポーク・システムから生産にインポートされる品目属性値が制御されます。
複合
複合ルール・セットには、割当ルール・セットと検証ルール・セットの両方を含めることができます。 複合ルール・セットを使用すると、様々な属性グループおよび品目区分で動作するルール・セットを集計できます。
複合ルール・セットは、「ルール・セット」の管理ページで作成します。 混合タイプの複合ルール・セットを定義するには、割当ルール・セットと検証ルール・セットの両方が含まれていることを確認してください。 タイプを「混合」に設定すると、割当ルール・セットと検証ルール・セットの両方を含むルール・セットを作成できます。 次に、割当ルール・セットと検証ルール・セットを複合ルール・セットに追加します。