検証の管理
コンフィギュレータによるコンフィギュレータ・モデルの検証方法とタイミングを管理します。
コンフィギュレータは、構成品目を含む販売オーダーをOracle Order Managementにインポート、作成、改訂または発行するとき、またはOrder Managementが明示的に検証をリクエストするときに、モデルの検証が必要になる場合があります。
モデルを検証する必要がない場合があります。 構成品目を含む下書き販売オーダーを作成するとします。コンフィギュレータは構成を検証しますが、顧客が購買にコミットする準備が整っていないため、オーダーを発行しません。また、必要な構成がわからない場合、購買をプルする時間をさらに必要とします。 数週間後、顧客の最新の変更でオーダーを改訂し、オーダーを発行します。 コンフィギュレータは下書きオーダーの構成をすでに検証しているため、発行済オーダーの構成で何が違うかをすばやく確認して、検証をスキップできるかどうかを判断できます。
多数の構成品目または大規模な複合構成品目を販売する場合、特定の条件下で検証をスキップして、パフォーマンスの向上を実現し、デプロイメントをより効率的にできます。
検証のスキップ
モデルの検証をスキップするかどうかを指定します。
-
モデルを開いて、リリースしていないワークスペースで編集します。
-
「コンフィギュレータ・モデルの編集」ページで、「構造」をクリックし、モデルのルート・ノードを選択してから、「プリファレンス」をクリックします。
-
「不要な場合に検証をスキップ」オプションにチェックマークが付いていることを確認してください。
-
モデルを保存し、ワークスペースを解放します。
必須でない場合に検証のスキップを有効にしない場合、実行時構成に影響するモデルに変更を加えたかどうかに関係なく、コンフィギュレータは実行時構成を検証します。
このオプションを有効にするかどうかに関係なく、構成有効日の指定が必要になる場合があります。
構成有効日の指定
「構成有効日」パラメータを使用して、検証するバージョンを識別できます。
モデルのバージョンが異なる場合があり、各バージョンの開始日と終了日を異なる方法で設定することもできます。 次のものがあるとします:
- バージョン1(実際には6月1日から6月10日まで)。
- バージョン2(実際には6月11日から6月15日まで)。
- バージョン3(実際には6月16日から6月30日)。
コンフィギュレータは、発行したバージョンを「構成有効日」パラメータに従って存在するバージョンと比較します。
演習
-
設定およびメンテナンス作業領域に移動し、Order Managementパラメータの管理タスクに移動します:
-
オファリング: オーダー管理
-
機能領域: オーダー
-
タスク: オーダー管理パラメータの管理
-
-
構成有効日パラメータの値を設定します。
値
説明
構成日
オーダー明細を追加した日付に有効なバージョンを使用し、明細に品目を構成します。
受注明細を作成し、その明細にストーブを追加して、6月1日にストーブを構成するとします。 構成日は6月1日です。
この例では、バージョン1は6月1日に有効であるため、コンフィギュレータはバージョン1を使用します。 6月11日にストーブを構成すると、コンフィギュレータはバージョン2を使用します。
オーダー日 オーダー日に有効なバージョンを使用します。 Order Managementでは、オーダーの作成時にオーダー日がデフォルトで設定されます。ただし、オーダーを発行する前に手動で変更できます。
たとえば、オーダー・ヘッダーのオーダー日属性に6月16日が含まれている場合は、6月16日に有効なバージョンを使用します。 この例では、バージョン3です。
現在の日付
現在の日付に有効なバージョンを使用します。 たとえば、現在の日付が2023年6月1日の場合、2023年6月1日に有効なバージョンを使用します。
現在の日付は、オーダーを履行するために発行した日付です。
6月1日にオーダーを作成し、それをドラフトとして保存するが、6月10日まで送信しないとします。 オーダー日は6月1日で、現在の日付は6月10日です。 この例では、パラメータを現在日に構成すると、6月1日にすでにバージョン1が検証され、バージョン1がまだ有効であるため、コンフィギュレータはモデルを検証しません。
パラメータを値に設定しない場合、Order Managementではデフォルトで現在の日付が使用されます。
要求日 リクエスト日に有効なバージョンを使用してください。 たとえば、オーダー明細のリクエスト日属性に7月14日が含まれている場合は、7月14日に有効なスナップショットを使用します。 この例では、バージョン2です。
ほとんどのデプロイメントでは、オーダーを発行する日付であるため、構成有効日パラメータを現在日に設定することをお薦めします。 発行時にオーダー明細にある構成には、通常、必要な構成が含まれます。これは、顧客の現在の要件を反映するために構成に加えた変更が含まれているためです。
別の値を使用するための特定の要件がある場合があります。 たとえば、リクエスト日は、顧客が品目を受入する日付です。 モデルを構成してから実際に配信するまでの間にモデルを変更する予定があり、その変更を配信する前に適用する場合は、リクエスト日を使用できます。
詳細は、オーダー管理パラメータの管理を参照してください。
検証に影響する変更
コンフィギュレータは、各バージョンで行った変更を調べて、検証済のバージョンと比較します。 構成有効日パラメータを使用して、参照するバージョンを決定します。
次のように仮定します。
- Configuration Effective Date(構成有効日)をCurrent Date(現在の日付)に設定します。
-
モデルの一部であるコンポーネントの最大数量属性を更新し、変更がモデルにいつ有効になるかを指定します。
-
Order Managementで販売オーダーを改訂します。
条件:
|
属性値の変更が有効になります |
コンフィギュレータは検証しますか? |
|---|---|
|
現在の日付以前。 |
Yes |
|
現在の日付の後。 |
No |
例
モデルにこの階層があるとします。
Stove
Oven
10K BTU Gas Burner
20K BTU Gas Burner
Stovetop
10K BTU Gas Burner
20K BTU Gas Burner
次のように仮定します。
- 市場調査では、顧客は3つではなくストーブの上部に最大4つの10K BTUガス・バーナーを設置する必要があるため、10K BTUガス・バーナーの最大数量属性を3から4に変更し、新しい数量が6月15日に有効になるように最大数量の開始日を設定します。 新しい開始日は、10Kバーナーの供給を増やすのに十分な時間を提供し、ファクトリが別のバーナーを追加するために使用する新しいワークフローに適応する時間を提供します。
- 販売オーダー56497は6月1日に作成するため、オーダー日は6月1日になります。 顧客がストーブを1日か2日で追加すると言っているため、冷蔵庫のオーダー明細を追加し、オーダーを下書きとして保存します。
- 6月2日に新規受注明細を作成し、その明細にストーブを作成してストーブを構成し、その受注を下書きとして保存します。 したがって、構成日は6月2日です。
- オーダー明細のリクエスト日は6月20日です。
- オーダーは6月10日まで送信しないため、現在の日付は6月10日です。
コンフィギュレータは、構成有効日パラメータの設定方法に応じて、オーダーの発行時に検証する場合としない場合があります。
|
構成有効日パラメータを次のように設定します。 |
検証しますか? |
|---|---|
|
構成日 |
構成日は6月2日ですが、最大数量の開始日は6月15日まで発生しないため、変更を検証する必要はありません。 コンフィギュレータは現在のバージョンを使用でき、ドラフト・オーダーの作成時にそのバージョンをすでに検証しています。 お客様はストーブの上部に10Kバーナーを3台まで追加できます。 |
|
現在の日付 |
現在の日付は6月10日ですが、最大数量の開始日は6月15日まで発生しないため、変更を検証する必要はありません。 コンフィギュレータは現在のバージョンを使用でき、ドラフト・オーダーの作成時にそのバージョンをすでに検証しています。 お客様はストーブの上部に10Kバーナーを3台まで追加できます。 |
| オーダー日 | オーダー日は6月1日ですが、最大数量の開始日は6月15日まで発生しないため、変更を検証する必要はありません。 お客様はストーブの上部に10Kバーナーを3台まで追加できます。 |
| 要求日 | リクエスト日は6月20日で、最大数量の開始日はリクエスト日より前の6月15日に発生するため、構成では変更数量を考慮する必要があります。 コンフィギュレータによって変更が検証されます。 お客様は、ストーブの上部に最大4台の10Kバーナーを追加できます。 |
|
最大数量属性 |
コンフィギュレータ予定 |
|---|---|
|
販売オーダーのリクエスト日の後。 |
検証をスキップします。 |
|
販売オーダーのリクエスト日より前。 |
構成を検証します。 |
製品情報管理からインポートしないモデルの検証をスキップ
コンフィギュレータは、様々な属性を調べて、モデルを製品情報管理作業領域からコンフィギュレータ・モデル作業領域にインポートするか、コンフィギュレータ・モデル作業領域で直接作成するかに応じて、検証をスキップできるかどうかを判断します。
製品情報管理からモデルをインポートせず、かわりにコンフィギュレータ・モデル作業領域でモデルを作成した場合、コンフィギュレータは次の場合に検証をスキップできます:
- モデルを変更していません。
- モデルの子コンポーネントの属性を変更していません。
コンフィギュレータは、モデルの次の属性を調べて、変更したかどうかを確認します:
-
オーダー管理分割不可
-
構成品目タイプ
コンフィギュレータは、モデルの子コンポーネントで次の属性も調べ、変更したかどうかを確認します:
-
数量
-
最小数量
-
最大数量
-
オプション
-
相互排他オプション
-
Instantiability. 値は、複数インスタンス、オプション単一インスタンスまたは単一インスタンスが必要のいずれかです。
これらの属性の詳細は、「有効なコンポーネント属性および構成タイプ」を参照してください。
コンフィギュレータは、モデルの子コンポーネントを終了したか、モデルからコンポーネントを削除したかも決定します。
製品情報管理からインポートしたモデルの検証をスキップ
モデルを製品情報管理作業領域からスナップショットとしてコンフィギュレータ・モデル作業領域にインポートし、スナップショットを変更およびリリースする場合、コンフィギュレータは次を実行します:
- リリースした変更を調べて、更新がモデルの品目構成、ルールまたはユーザー・インタフェースに影響するかどうかを判断します。
- モデルの子品目のスナップショットを更新およびリリースしたかどうかを決定します。
検証をスキップしないためのガイドライン
次の場合は、検証をスキップしないでください:
-
構成の実行時インスタンスの有効日は、構成の最新改訂の有効日以降、販売オーダーを作成、インポートまたは発行する前、またはOrder Managementが明示的に検証をリクエストしたときに発生します。 コンフィギュレータによる構成の初期作成または検証後に、販売オーダーのオーダー日またはリクエスト日を変更した場合は、ランタイム構成を検証する必要があります。
-
品目区分または値セットは、構成を最初に作成または検証した後、販売オーダーを作成、インポート、改訂または発行する前に、スナップショットでリリースします。
-
モデルには、外部アプリケーションをコールする拡張ルールが含まれており、そのコールによって構成が変更されます。 「拡張ルール」を参照してください。
-
構成にはトランザクション属性が含まれます。 「トランザクション属性」を参照してください。
これらの状況のいずれかがモデルに適用される場合、「不要な場合に検証をスキップ」オプションにチェック・マークが含まれていないことを確認してください。