リリース12.2
E57804-01
目次
前へ
次へ
| Oracle Rapid Planningインプリメンテーションおよびユーザー・ガイド リリース12.2 E57804-01 | 目次 | 前へ | 次へ |
ラピッド・プランニングの機能を評価して、それらを使用するかどうかを決定します。 次に例を示します。
安全在庫
固定供給日数
ソーシング分割の施行
製造可能
需要プルイン、アップサイド処理およびオーダー優先度
ファントム
フロー製造
日次バケット
確定供給
供給の作成
代替供給
ボトルネック生産資源計画
代替
仕入先生産能力
計画タイム・フェンス
受注構成
デフォルト・オーダー・サイズと計画作業単位
安全在庫計画は、需要の不確実性を処理し、高い顧客満足度レベルを維持するための状況で役に立ちます。
この機能は、次の場合に使用します。
欠品のために需要に対応できない場合
需要と供給のリード・タイムに確実性がない場合
需要数量が大きく変化する場合は、リード・タイムに基づいて安全在庫計画を考慮します。 それ以外の場合は、数量に基づいて安全在庫計画を考慮します。
プロファイル・オプションのMSC安全リード・タイムの使用が「Yes」の場合は、プランニング・ソルバーで安全在庫リード・タイムが計算されます。
次のように計算されます。
品目属性「安全在庫比率」 / 100
次の整数に切上げ
プランニング・ソルバーでは、安全在庫リード・タイムを使用して、実績需要より数日早い供給が作成されます。 プロセスでは、次の供給の計画が試みられます。
安全在庫リード・タイム分だけ早期
これが不可能な場合は、安全在庫リード・タイムと需要納期の中間
これが不可能な場合は、需要納期当日
プランニング・ソルバーでは次のように処理されます。
稼働日のみ使用されます。
計画タイム・フェンスより早期に再計画されません。
MRP計画で安全在庫比率がある構成部品の計画時に、安全在庫リード・タイムが適用されます。
最終品目代替および代替構成部品の安全在庫リード・タイムを使用して計画されます。
連産品および副産物の安全在庫リード・タイムは計画されません。
Oracle Rapid Planningでは、安全在庫をモデル化する2つの方法が用意されています。
リード・タイム
数量
リード・タイムに基づく安全在庫のモデル化
Oracle Rapid Planningでは、安全リード・タイムを使用して予期しない需要に対してバッファするために、安全在庫をモデル化します。 次の品目属性を使用してモデル化します。
安全在庫計算方法: Oracle Rapid Planningで安全在庫所要量を考慮するには、これを「MRP計画比率」に設定する必要があります。
安全在庫比率: このフィールドには値を入力する必要があります。
安全在庫リード・タイム(SSLT)は内部フィールドです。 これは整数値で、安全在庫比率 / 100で計算されます。計画時に、Oracle Rapid Planningでは、実績需要納期よりSSLT日数早い供給が作成されます。 たとえば、需要が第12日でSSLTが5の場合、提示納期が第7日の供給が作成されます(非稼働日はないと仮定した場合)。
このロジックを有効にするには、計画オプションのMSC: ラピッド・プランニング安全リード・タイムの使用を設定します。 この計画オプションの有効な値は次のとおりです。
Yes: 「安全在庫計算方法」 = 「MRP計画比率」、「安全在庫比率」はnull以外を使用して、品目のSSLTが計算されます。
No: SSLTは計算されません。
数量に基づく安全在庫のモデル化
数量に基づいて安全在庫を計算する場合、Oracle Rapid Planningでは2つのタスクが実行されます。 次のとおりです。
安全在庫比率を安全在庫数量に換算します。
安全在庫数量を安全在庫比率に換算します。
これらの換算を完了するには、現行の安全在庫ロジックに関連する条件が使用されます。
安全在庫比率の安全在庫数量への換算
Oracle Rapid Planningエンジンでは、安全在庫所要量を処理する際に、安全在庫比率が入力として使用されます。 この値は数量に換算して、ユーザー・インタフェースに表示できます。 次のステップは、アプリケーションで使用される換算ロジックを示します。
安全在庫リード・タイム(SSLT)が計算されます。
SSLT = 安全在庫比率/100
導出安全在庫数量(DSSQ)
DSSQ = SSLTx平均日次需要
ここで、平均日次需要は、計画範囲で除算した平均として計算されます。
注意: SSLTは小数値になる場合があります。
次に、換算ロジックの例を示します。
安全在庫比率 = 100
7日間の需要: 20、28、50、33、38、19、28
安全在庫リード・タイム(SSLT) = 100/100 = 1日
計画範囲全体の平均日次需要 = (20+28+50+33+38+19+28)/7 = 30.85
導出安全在庫数量(DSSQ) = 1 * 30.85 = 30.85ユニット
安全在庫数量の安全在庫比率への換算
Oracle Rapid Planningでは、期間別安全在庫数量を入力として読み込むことができます。 ただし、エンジンではSSLTのみサポートされているため、この数量をSSLTに換算する必要があります。
次のステップは、安全在庫に基づく期間別数量を単一のSSLT値に変換する際に使用されるロジックを示します。エンジンでは、このSSLT値を使用して安全在庫が計算されます。
期間別安全在庫数量(SSQi)は入力です。iは対象の期間を示します。
安全在庫リード・タイム(SSLTi)が計算されます。
平均日次需要は、計画範囲全体の平均として計算されます。
安全在庫比率が計算されます。
エンジンで計算に使用される安全在庫リード・タイム(SSLT)は、次に示すように加重平均です。
導出安全在庫数量(DSSQ)は、SSLTを使用して計算されます。
注意: SSLTは小数値になる場合があります。
安全在庫を計算するには、新しい計画オプション「安全在庫リード・タイム方法」を設定します。 この計画オプションの可能な設定は次の3つです。
安全在庫の計算をしない
安全在庫率の使用
安全在庫数量の使用
数量を使用して安全在庫を計算するには、この計画オプションを「安全在庫数量の使用」に設定する必要があります。
次の2つの例は、安全在庫数量の計算方法を示します。
例1
7日間の需要は20、28、50、33、38、19、28です。範囲全体の安全在庫数量は5ユニットで一定とみなされます。
計画範囲全体の平均日次需要 = 30.85
安全在庫リード・タイム(SSLT) = 5/30.85 = 0.16日
安全在庫比率 = 16
導出安全在庫数量(DSSQ) = 0.16 * 30.85 = 4.94ユニット
例2
計画範囲全体の平均日次需要 = 27.86
安全在庫リード・タイムが、安全在庫数量が4ユニットの場合は4/27.86 = 0.14日、6ユニットの場合は6/27.86 = 0.22日と計算されます。
加重平均として計算された安全在庫リード・タイム(SSLT) = (0.14 * 3 + 0.22 * 4)/7 = 0.186
導出安全在庫数量(DSSQ) = 0.186 * 27.86 = 5.18ユニット
注意: SSLTによって安全在庫を決定するとき、SSLTは整数値に切り下げられます。 数量によって安全在庫を決定するとき、SSLTは正の数として使用されます。 小数値は小数第2位まで可能です。 エンジンで計画するとき、SSLTは正の数とみなされます。
構成部品の安全在庫
構成部品の安全在庫も計算されます。 構成部品の安全在庫リード・タイムの計算には、最終品目需要と同様に(スナップショットからの)入力として使用できない構成部品品目需要が必要です。 構成部品の需要は計画時に計算されるため、最初の計画実行では最終品目の安全在庫のみ考慮されます。
最初の計画実行の終了時に、構成部品品目需要が使用可能になります。 これは、後続の計画実行用に更新されます。 構成部品需要のSSLTは、最初の計画実行後に使用可能になり、後続の計画実行で考慮されます。 各計画実行では前の計画実行で生成された構成部品品目需要が考慮されるため、構成部品の安全在庫の計算では常にラグが生じます。 さらに、構成部品品目需要は、親最終品目の充足数量を使用して生成されます。
安全在庫入力
安全在庫入力は、次のいずれかの方法でOracle Rapid Planningに渡されて定義されます。
品目属性「安全在庫比率」
期間別安全在庫数量
入力をOracle Rapid Planningに正常に渡すには、「安全在庫計算方法」を「MRP計画比率」に設定する必要があります。
1. 品目属性「安全在庫比率」によって定義される安全在庫入力
Oracle Rapid Planningで品目属性「安全在庫比率」によって安全在庫が定義されると、エンジンでは次の機能が実行されます。
安全在庫比率が入力として取得されます。
安全在庫リード・タイム(SSLT)が計算されます。
SSLTを使用して安全在庫をバッファすることにより、オーダーが計画されます。
注意: この場合、使用するSSLTは正の数です。 小数値も可能です。
導出安全在庫(DSSQ)が計算されます。
注意: この場合、使用するSSLTは正の数です。 小数値も可能です。
ユーザー・インタフェースに、前述の例のステップでエンジンにより計算された資材計画の導出安全在庫が表示されます。
注意: ターゲット安全在庫数量が指定されている場合、このシナリオでは表示されません。
2. 期間別安全在庫数量として定義される安全在庫入力
Oracle Rapid Planningで期間別安全在庫数量として安全在庫が定義されると、エンジンでは次の機能が実行されます。
安全在庫数量が入力として取得されます。 これはターゲット安全在庫です。
安全在庫リード・タイムが加重平均として計算されます(SSLT)。
安全在庫比率が計算されます。 これは、品目属性値として挿入されます。
SSLTを使用して安全在庫をバッファすることにより、オーダーが計画されます。
注意: この場合、使用するSSLTは正の数です。 小数値も可能です。
導出安全在庫(DSSQ)が計算されます。
注意: この場合、使用するSSLTは正の数です。 小数値も可能です。
ユーザー・インタフェースに、前述のステップでエンジンにより計算された資材計画のターゲット安全在庫数量と導出安全在庫数量の両方が表示されます。
次の点に注意してください。
「ターゲット安全在庫」行および「導出安全在庫」行からドリルダウンはできません。
ターゲット安全在庫数量が表示されるのは、計画オプション「安全在庫リード・タイム方法」を「安全在庫数量の使用」に設定した場合のみです。
週または期間レベルで表示されるターゲット安全在庫数量は、その週または期間内の最終日の値です。
資材計画ビューではターゲット安全在庫数量および導出安全在庫数量を編集できません。
「品目詳細」画面で品目属性「ターゲット安全在庫上書き」が挿入されている場合は、資材計画ビューの「ターゲット安全在庫」行が更新されます。
在庫位置をより包括的に理解するために、Oracle Rapid Planningでは、安全リード・タイムの使用に加え、次の安全在庫計画方法がサポートされています。
ユーザー定義の安全在庫数量およびOracle Inventoryからの安全在庫。 品目安全在庫計算方法は非MRP計画です。
Oracle Rapid Planningで将来の需要の比率として計算された安全在庫数量。 品目安全在庫計算方法はMRP計画比率です。
在庫最適化からOracle Rapid Planningに渡された安全在庫数量。 品目安全在庫計算方法はMRP計画比率です。
数量に基づく安全在庫の計画は、その他すべての実際の需要を計画する前に、サプライ・チェーン全体でのすべての安全在庫需要を計画することで開始します。 これによって、ラピッド・プランニング・エンジンは、安全在庫レベルの低下後に発生する需要によって一時的な安全在庫を消し込むことができます。 このロジックにより、一時的な安全在庫に起因する過剰在庫がなくなります。 次の図およびその後の例に、この動作を示します。
例:
リード・タイム = 5日
| D1 | D2 | D3 | D4 | D5 | |
| 受注 | 10 | ||||
| 安全在庫 | 20 | 20 | 20 | 20 | 20 |
| 手持 | 20 | ||||
| 計画オーダー | 10 | ||||
| 使用可能(安全在庫数量を除く) | 0 | 0 | 0 | -10 | 0 |
| 使用可能(安全在庫数量を含む) | 20 | 20 | 20 | 20 | 20 |
上の表の数字を使用して、計画は次の順序に従って実行されます。
D1の安全在庫を計画します。D1の使用可能数量 = 0
使用可能(安全在庫を除く)に基づいてD4の需要を計画します。 LT = 4日のため、最早充足日 = D5
使用可能(安全在庫を含む)に基づいてD4の需要を計画します。 充足日 = D4
Oracle Rapid Planningでは、次の決定図を使用して、計画オプションの「安全在庫計画方法」および品目属性の「安全在庫計算方法」が使用されます。
ユーザー定義の安全在庫数量(品目レベル)
安全在庫計算方法 = 非MRP計画
ユーザーが入力した安全在庫数量(Oracle Inventory->計画->安全在庫)
次に、Oracle Rapid Planningでは、安全在庫数量が収集され、使用されます。
Oracle Inventoryで生成された安全在庫数量(品目レベル)
安全在庫計算方法 = MRP計画比率
安全在庫バケット日数 = ユーザー定義値
安全在庫比率 = ユーザー定義値
Oracle Rapid Planningでは、次のロジックを使用して、これらの品目属性が収集され、安全在庫数量が計算されます。
a. サプライ・チェーンのすべての品目に対して日次総所要量を計算します。 日次総所要量は独立需要 + 依存需要です。
b. すべての日(第n日)について、安全在庫需要ウィンドウに対する総所要量を計算します。 日はすべて組織の製造カレンダに基づく稼働日です。 需要ウィンドウは次のように導出されます。
ウィンドウの開始日 = 第n日 + m日
mは、安全在庫バケット開始オフセット日数です。 これは、新しいプロファイル・オプション「MSC: 安全在庫バケット開始オフセット日数」に基づいています。 このプロファイル・オプションは計画オプションとしても使用可能です。
第n日およびm日は組織の製造カレンダに基づく稼働日です。
安全在庫バケットの開始日は当日からのオフセットです。 これによってラピッド・プランニングでは、高いバックログ需要のために発生する可能性がある近い将来の高い需要の影響を無視できます。
ウィンドウの終了日 = ウィンドウの開始日 + n日
n = 安全在庫バケット日数(品目属性)
c. バケット日数は、組織の製造カレンダの稼働日数に基づくローリング・ウィンドウとして機能します。
安全在庫は、(バケット日数の稼働日数に対する総所要量の合計 * 比率) / (100 * バケット日数)です。
次のように安全在庫を計算します。
週の稼働日 = 5日
バケット日数 = 5
安全在庫比率 = 100
注意: 週の非稼働日の安全在庫は計算されません。
D1の安全在庫 = (D1からのバケット日数での平均日次総所要量) *(安全在庫比率 / 100)
= [ (10 + 10 + 20 + 20 + 20) / 5 ] * 1.0
= 16
D21の安全在庫 = (D1からのバケット日数での平均日次総所要量) *(安全在庫比率 / 100)
= [ (10 + 20 + 20 + 20 + 20) / 5] * 1.0
= 18
その後も同様に続きます。
ラピッド・プランニングは日レベルの計画ツールであるため、安全在庫レベルは1日の最後までに充足されるターゲットです。
計画が未作成の代替部品構成表または代替構成部品を選択したため、構成部品に依存する需要は計画の初期ブートストラップ実行で即時に使用できない状態です。そのため、この例では、次のロジックを使用して依存需要を計算します。
計画の初期ブートストラップ実行で、総所要量を計算する目的での依存需要は主BOMに基づいています。 主構成部品では、固定リード・タイムおよび変動リード・タイムを使用する無制約MRP展開を使用します。
後続のすべての実行では、依存需要は前回の実行およびその実行で指定された代替部品構成表と代替構成部品の選択に基づきます。
両方のシナリオで、安全在庫計算に使用される合計需要は安全在庫数量とともに資材計画に使用できます。
在庫最適化からOracle Rapid Planningへの安全在庫数量入力
ラピッド・プランニング計画では、サプライ・チェーンでの需要およびリード・タイムの変動の原因を説明する場合、計画オプションの需要計画領域に在庫最適化計画を指定できます。 このような品目の場合、その安全在庫計算方法はMRP計画比率で、在庫最適化計画の一部となります。
ラピッド・プランニング計画は、次のあらゆるグループの品目の組合せで構成できます。
MRP計画比率
一部の品目は在庫計画(需要計画)で安全在庫が計算されます。
一部の品目はOracle Rapid Planningで安全在庫が計算されます。
このカテゴリ(安全在庫計算方法 = MRP計画比率)の品目が在庫最適化計画から需要計画として渡された場合は、在庫最適化で生成された安全在庫が優先され、その他の安全在庫属性(つまり、安全在庫比率)は考慮されません。 その品目の安全在庫はラピッド・プランニングでは計算されません。
非MRP計画
一部の品目にはユーザー定義の安全在庫数量が設定されます。
一部の品目にはOracle Inventoryで生成された安全在庫数量が設定されます。
安全在庫計画の計画オプション
「拡張オプション」セクションにあり、安全在庫計画方法を構成する現在の計画オプション「安全在庫リード・タイム方法」は、「安全在庫計画方法」に変更されました。 次の値があります。
安全在庫を計画しない
安全在庫数量の使用
安全在庫率からの安全在庫リード・タイムの使用
安全在庫を使用した安全在庫リード・タイムはありません。
安全在庫の平滑化
場合によっては、計画内の安全在庫の変動は抑えるが、Oracle Inventoryで生成されたIO計画やユーザー定義されたIO計画など、前述のいずれかのメカニズムから得られた未処理の安全在庫数は直接使用しないことがあります。 次のプロファイル・オプションを使用すると、平滑化がどのような場合にどのようにして発生するかを制御できます。 次に例を示します。
MSC: 安全在庫変更間隔 (日数): 平滑化の間隔に含まれる稼働日数。
MSC: 変更間隔内の安全在庫を計算する平滑方法: 計画範囲から開始して、すべての間隔で未処理安全在庫数量が平滑化されます。 結果は常に最も近い整数に切り上げられます。 有効な値は、「最小」、「最大」および「平均」です。
MSC: 非MRP計画安全在庫への安全在庫変更間隔の適用: 有効な値は「Yes」および「No」です。「No」に設定されている場合に平滑化が発生するのは、品目の安全在庫計算方法が「MRP計画比率」に設定されている場合、つまり、安全在庫数量がラピッド・プランニングで計算される場合やIOから渡される場合のみです。
MSC: 安全在庫値の最大変動率: ある間隔から次の間隔までの平滑化の発生方法が決まります。 前述の表を使用して、次に例を示します。
第2間隔で、間隔 = 5日
最小オプションを使用して間隔内で平滑化した後の安全在庫 = 10
25%の最大変動率を使用して間隔全体で平滑化した後の安全在庫 = 12
MSC: 安全在庫値の最小変動率: このオプションは、安全在庫数量が異なる間隔をトリガーする最小限必要な変動率を示します。 次に例を示します。
間隔(1)の安全在庫(平滑化後) = 20
間隔(2)の安全在庫(平滑化後) = 25
安全在庫値の最小変動率プロファイル = 50%
この例では、間隔(2)は最小率(間隔(1) + 50% = 30)を下回るため、これらの2つの間隔の間での変更および次の間隔への移動をトリガーしないことで、計画によって安全在庫がさらに平滑化されます。 結果を次に示します。
間隔(1)の安全在庫(平滑化後) = 20
間隔(2)の安全在庫(平滑化後) = 20
安全在庫のペギング
ラピッド・プランニングでは、安全在庫所要量に対する実績需要入力は生成されません。 したがって、安全在庫所要量の充足に使用される供給に対してペギングは作成されません。 ただし、安全在庫は他の需要と同様に在庫バッファを消費するため、それに対して別の需要に対応するための供給が、計画によって十分に確保されることになります。
品目属性のシミュレーション
次の品目属性は、シミュレーション・セットとシミュレーション用の計画(What-If分析)の両方で編集できます。 計画でこれらの属性を変更した場合は、スナップショット付きで計画を実行しなくても変更内容は有効になります。
安全在庫計算方法
安全在庫バケット日数
安全在庫比率
これらの属性には、標準的な一括編集操作を使用できます。
資材計画
現在、資材計画では次の需要メジャーを使用できます。 メジャーに対する変更は次のとおりです。
ターゲット安全在庫: これは期間別安全在庫数量を表し、平滑化した後のラピッド・プランニングへの入力とみなされます。 ターゲット安全在庫は、品目の安全在庫計算方法の属性が非MRP計画の場合にのみ編集できます。
未処理ターゲット安全在庫: これは平滑化する前のターゲット安全在庫です。
資材計画では次の編集が可能です。
品目-組織-日: 単純な更新。 割当てはありません。
品目-組織-週: その週のすべての日に適用します。
品目-組織-期間: その期間のすべての日に適用します。
未処理ターゲット安全在庫は、品目の安全在庫計算方法の属性が非MRP計画の場合にのみ編集できます。
この機能は、次の場合に使用します。
数量を一括発注する場合(たとえば、週1回)
生産を一括計画する場合(たとえば、週1回)
プランニング・ソルバーでは、計画タイムラインで固定ポイント(FDS日付)が見積もられます。 需要が優先度順に処理されるように、これらの日数に基づいて供給オーダーが作成およびサイズ変更されます。
無制約計画では、固定供給日数を設定するすべての品目に対して固定供給日数が計算されます。
制約付き計画では、次のいずれかが指定されている、固定供給日数を設定する購買品目に対して固定供給日数が計算されます。
購買元ソーシングのみの品目に割り当てられたソース・ルール。 品目に割り当てられたソース・ルールに購買元および製造場所または移動元がある場合、プランニング・ソルバーでは固定供給日数は計算されません。
品目に割り当てられていないが、購買の製造/購買コードに割り当てられているソース・ルール。
処理
次の最新の情報で、最初のFDS日付が設定されます。
計画開始日
計画タイム・フェンス + 1日。 計画タイム・フェンスより早いFDS日付は作成できません。
最新の計画受入 + 固定供給日数: 作業指示の場合は旧納期が使用されます。
その他のFDS日付を設定するために、次のことが実行されます。
最初のFDS日付で開始します。
固定供給日数に従ってFDS日付を間隔を空けて配置します。
2つのFDS日の間の期間がFDSウィンドウです。
次のことで発生するゼロ以下の予定使用可能残高に対応する必要がある場合は、プランニング・ソルバーで最初のFDSウィンドウの長さを調整する必要があります。
最終計画受入の再計画
最初のFDS日付より前の供給の作成
次のいずれかの方法で処理されます。
最初のFDS日付を移動します。
最初のFDS日付を移動した結果、移動したFDS日付で供給のFDS日が2日を超える場合は、さらに早いFDS日付を作成します。
その他のFDSウィンドウの長さは変更されません。
プランニング・ソルバーではFDS日付でのみ供給が作成されます。
プランニング・ソルバーでは、次の処理が実行されます。
計画オーダーを作成した後、計画受入を最終的に再計画します。
確定計画受入を使用します。
これらの場合は、次の情報が表示されます。
FDSウィンドウの計画受入および計画オーダー
計画受入前の計画オーダー期日
プランニング・ソルバーでは、制約付き-生産能力制約の施行計画の生産能力制約に違反しません。 生産能力が使用可能でない供給を作成するニーズに対応するために、このプロセスが使用されます。
先行製造数量を作成するために前のFDS日付を確認します。
FDSウィンドウ内に使用可能な生産能力がある次のFDS日付を確認します。
プランニング・ソルバーによって、FDS日付で計画オーダーが作成された後、固定ロット乗数、次に最小オーダー数量、次に最大オーダー数量に対応するようにサイズ変更されます。
ソーシング分割がある場合、プランニング・ソルバーは次のように動作します。
FDS日付では計画オーダーを分割しません。
FDS日付でソースを入れ替え、分割比率が指定の比率に近くなるように試行します。
ソーシング分割の違反に関する例外メッセージを発行します。
安全在庫リード・タイムと固定供給日数の両方を品目に設定する場合、プランニング・ソルバーは次のように動作します。
固定供給日数を計算します。
安全在庫は計算しません。
ビュー
シミュレーション・セットに固定供給日数を設定し、「品目」ビューに表示できます。
「資材計画」ビューに供給日数および平均供給日数を表示できます。
供給日数は次のように決定されます。
本日の使用可能供給: 前日の予定使用可能残高 + 本日の使用可能供給を計算します。
本日の使用可能供給で開始し、すべての供給をすべて使用するまで後続する各日の日次需要を差し引きます。
その日数を本日の供給日数として使用します。
FDSウィンドウの最初の日に対して、プランニング・ソルバーでは予定使用可能残高に0が使用されます。
非稼働日の固定供給日数は前日の固定供給日数と同じです。
次に例を示します。
第5日から第15日の需要数量: 各日150
第4日の予定使用可能残高: 0
第5日の供給数量: 500
第5日の使用可能な供給数量: 500 [0 + 500]
第5日の残余供給数量: 350 [500 - 150]
第6日の残余供給数量: 200 [350 - 150]
第7日の残余供給数量: 50 [200 - 150]
第8日の残余供給数量: -100 [50 - 150]、第5日からすべての供給をすべて使用
供給日数: 4 [第5日、第6日、第7日、第8日]
次に例を示します。
FDSウィンドウは5日間
5日間の需要数量は各100
第1日に数量500の計画オーダー
第1日の最後に、400の残余需要数量があり、期間の残りは4日間
第1日の最後の予定使用可能残高は400
供給日数は = 4 [400 / (400 / 4) = 400 / 100]
平均供給日数は次のように決定されます。
予定使用可能残高 / (平均供給日数計算ウィンドウ(日数)の需要の合計 / 平均供給日数計算ウィンドウ(日数)の日数)
平均供給日数計算ウィンドウ(日数)は品目属性で、シミュレーション・セットに含めることができます。
次に例を示します。
平均供給日数計算ウィンドウ(日数)は5
第4日の平均供給日数は、(第4日の予定使用可能残高 / 第4日から第8日までの平均日次需要)
第20日の平均供給日数は、(第20日の予定使用可能残高 / 第20日から第24日までの平均日次需要)
プランニング・ソルバーで、「供給日数が固定供給日数を超過」例外メッセージが発行されます。
この機能は、次の場合に使用します。
ソースに対して複数の仕入先に分割された契約上の義務がある場合
複数の製造施設で品目を分割して作成するビジネス・ルールがある場合
プランニング・ソルバーによって、次のソーシングが分割されます。
すべてのソーシング・タイプ: 製造、購買および転送
ランク1のソース
タイム・ウィンドウ内
設定
アドバンスト・サプライ・チェーン計画ソース・ルールでソーシング率またはランクを作成または検証し、エンティティ割当セットに割り当てます。
計画範囲を複数のウィンドウに分割します。 各ウィンドウ内で、ソーシング率に従ってプランニング・ソルバーで供給が分割されます。 ウィンドウの累計数量がソーシング率と一致しない場合は、例外メッセージが発行されます。 プロファイル・オプション「MSO: ソーシング割当ウィンドウ」を設定します。 「計画オプション」ビューの「詳細」タブを使用します。
ウィンドウのソーシング率と実績率間の許容範囲率を設定します。 その差異が許容範囲を超える場合は、プランニング・ソルバーでソース分割率違反の例外メッセージが発行されます。 プロファイル・オプション「MSC: ソーシング差異許容範囲」を設定します。 「計画オプション」ビューの「詳細」タブを使用します。
収集でソーシング履歴の累計を開始する開始日を設定します。 この情報が計画エンジンで使用され、ソーシングが決定されます。 アドバンスト・サプライ・チェーン計画プロファイル・オプションのプロファイル・オプション「MSC: ソーシング履歴開始日オフセット(月)」を使用します。
プランニング・ソルバーにソーシング分割を処理するように指示します。 「計画オプション」ビューの「メイン」タブにある「ソーシング分割の施行」フィールドを使用します。
処理
制約付き計画では、プランニング・ソルバーは、ソーシング分割のソフト制約より生産能力制約または納期制約を優先します。
プランニング・ソルバーでは、ランク1のソース・ルールのみが使用されます。
アドバンスト・サプライ・チェーン計画から様々な計画をコピーする際は、計画オプション「ソース制約の施行」を選択します。
分析
「サプライ・チェーン構成表」ビューには、ソース、ランクおよびソーシング率が表示されます。 「例外」をクリックすると、ソース分割率違反の例外メッセージが表示されます。
この機能は、次の場合に使用します。
ほとんどの構成部品および半組立品について手持を保持する場合
早期またはすぐに開始できる品目やオーダーを把握する場合
現在の手持をペグするためにオーダーを優先度を再考する場合
製造可能を使用すると、製造品目のオーダーを開始できるかどうかを把握できます。 これは、そのオーダーに必要な資材が使用可能かどうかに依存します。 オーダーのすべての構成部品が手持の状態にある場合、そのオーダーは製造可能です。
構成部品の可用性の不足により、遅延のリスクがある製造オーダーを把握するには、次の操作を実行できます。
構成部品の供給を優先します。
重要なオーダーの製造可能メトリックを優先するために、計画生産を再調整および再順序付けします。
オーダーのすべての構成部品が手持にペグされた場合、そのオーダーは製造可能です。 構成部品の一部が計画受入(発注、計画オーダー、転送オーダーなど)にペグされた場合、製造可能ではありません。
プランニング・ソルバーでは、次のオーダーについて製造可能かどうかを判断できます。
計画オーダー
ショップ型製造オーダー – 未リリース
ショップ型製造オーダー – リリース済: プロファイル・オプション「リリース済WIP製造オーダー: 製造可能での考慮」を「Yes」に設定します。
シミュレーション・セットの属性
シミュレーション・セットで、製造可能に関する次の品目属性を設定します。
製造可能での考慮: プランニング・ソルバーでこの品目-組織の製造可能を計算するかどうかを決定します。 デフォルトは「No」です。
製造可能の計算: プランニング・ソルバーでこの計画で製造可能を計算するかどうかを決定します。 デフォルトは「No」です。
製造可能範囲: プランニング・ソルバーで製造可能KPIメトリックを計算する範囲。 この属性は、オーダーの製造可能が計算される時期には影響しませんが、KPIが収集される期間にのみ影響します。 デフォルトは計画範囲です。
製造可能の属性
プランニング・ソルバーでは、ペギング情報を使用して、各製造オーダーの次の属性が計算されます。
これらの属性は、次のビューに表示されます。
「供給および需要」ビュー
「製造可能シミュレーション」ビュー
「シミュレーション表示の競合」ビュー
製造可能ステータス:
Yes: すべての構成部品が手持で完全に使用可能です。
No - 期限内: オーダーに必要な時点ですべての構成部品が使用可能です。 現時点では一部の構成部品が完全には使用可能でありません。
No - リスクあり: 製造可能日が希望入手日より後です。 構成部品の不足によるリスクがあります。
製造可能構成部品の可用性%: 手持で完全に使用可能な、製造オーダーの構成部品のパーセント。
製造準備完了%: 最も制約された構成部品に基づいて、現在開始できるオーダーのパーセント。 この値を設定するには、すべての構成部品が少なくとも部分的に手持にペグされる必要があります。
製造可能日: オーダーが製造可能になる日付。 これは、最終構成部品資材が手持に到着する日付です。 プランニング・ソルバーで使用されるのは、製造計画オーダーの場合は納期、購買オーダーの場合は納入予定日に後処理時間を加えた日付、転送オーダーの場合は受入日に後処理時間を加えた日付です。
製造可能日(購買済構成部品のみ): 購買構成部品のみを確認している場合は製造可能日。
製造可能による遅延: 製造可能日 - 希望入手日(製造カレンダの稼働日で)。 ゼロは、2つの日付が同じ(遅延なし)または製造可能日が希望入手日より早いことを意味します。
製造準備完了数量: 最も制約された構成部品に基づいて、現在開始できるオーダーの数量。 この値を設定するには、すべての構成部品が少なくとも部分的に手持にペグされる必要があります。 製造準備完了% * オーダー数量。
製造オーダー値: 製造品目標準原価 * オーダー数量。
代替構成部品使用インジケータ:
Yes: オーダーでは代替構成部品を使用します。
No: オーダーでは代替構成部品を使用しません。
製造可能の例
品目1、数量100、6月20日期日の製造オーダーには、次の3つの構成部品を使用します。
構成部品Aの購買使用数 = 1、このオーダーで必要な数量は100
構成部品Bの製造使用数 = 2、このオーダーで必要な数量は200
構成部品Cの購買使用数 = 3、このオーダーで必要な数量は300
手持にペグされた構成部品A = 20、数量80は6月14日に手持に到着するように計画済
手持にペグされた構成部品B = 20、数量180は6月30日に手持に到着するように計画済
手持にペグされた構成部品C = 40、数量260は6月14日に手持に到着するように計画済
品目1の標準原価は$45
「製造可能」 = 「No」[すべての構成部品が手持で完全に使用可能ではない]
「製造可能構成部品の可用性%」 = 0 [手持で完全に使用可能な構成部品はなし]
「製造準備完了%」 = 10 [製造オーダーの10ユニットが開始可能で、これにより、Aを10ユニット、Bを20ユニット、Cを30ユニット消費。(製造準備完了10ユニット / オーダー数量100) * 100]
「製造可能日」 = 6月30日[構成部品Bが最後に手持に到着]
製造可能日(購買済構成部品のみ): 6月14日
製造可能による遅延: 8 [6月30日 – 6月20日(稼働日で)]
製造準備完了数量: 10 [0.1 * 100] 製造オーダー値: $4500 [$45 * 1000]
代替構成部品使用インジケータ: No
複数レベル間の製造可能
上位レベルの製造オーダーが下位レベルの製造可能な製造オーダーにペグされた場合、計画サーバーは、下位レベルの組立品目が手持ですでに使用可能であるとみなして動作します。
この例では、次の計画オーダーについて説明します。
SA123は製造可能: その構成部品CM1とCM2は両方とも手持にペグされています。
AS66311は製造可能: その構成部品CM3は手持にペグされています。 構成部品SA123は製造可能オーダーであるため、手持にペグされています。
| 品目 | 摘要 | オーダー・タイプ | 要求日 | 納期 | オーダー数量 | ペグ数量 | 製造可能 | 製造可能構成部品の可用性 |
|---|---|---|---|---|---|---|---|---|
| AS66311 | 最終品目 | 受注 | 第20日 | - | 100 | - | - | - |
| . AS66311 | 最終品目 | 計画オーダー | - | 第20日 | 100 | 100 | Yes | 100 |
| . . SA123 | 半組立品 | 計画オーダー | - | 第18日 | 100 | 100 | Yes | 100 |
| . . . CM1 | 半組立品構成部品 | 手持 | - | - | - | 100 | - | - |
| . . . CM2 | 半組立品構成部品 | 手持 | - | - | - | 100 | - | - |
| . . CM3 | 最終品目構成部品 | 手持 | - | - | - | 100 | - | - |
この例では、次の計画オーダーについて説明します。
SA123は製造可能: その構成部品CM1とCM2は両方とも手持にペグされています。
AS66311は製造可能ではない: その構成部品CM3は発注にペグされています。 構成部品SA123は製造可能オーダーであるため、手持にペグされています。
| 品目 | 摘要 | オーダー・タイプ | 要求日 | 納期 | オーダー数量 | ペグ数量 | 製造可能 | 製造可能構成部品の可用性 |
|---|---|---|---|---|---|---|---|---|
| AS66311 | 最終品目 | 受注 | 第20日 | - | 100 | - | - | - |
| . AS66311 | 最終品目 | 計画オーダー | - | 第20日 | 100 | 100 | No - 期限内 | 80 |
| . . SA123 | 半組立品 | 計画オーダー | - | 第18日 | 80 | 80 | Yes | 100 |
| . . . CM1 | 半組立品構成部品 | 手持 | - | - | - | 80 | - | - |
| . . . CM2 | 半組立品構成部品 | 手持 | - | - | - | 80 | - | - |
| . . CM3 | 最終品目構成部品 | 発注 | - | - | - | 20 | - | - |
需要/供給ビューでの製造可能情報の使用
需要/供給ビューを使用して、次のことが可能です。
製造可能属性の表示
製造可能属性の検索
オーダー・ステータスの表示: 「未リリース」、「リリース済」など
製造可能属性は更新できません。
製造可能KPIの使用
次に、製造可能KPIメトリックを示します。 一部はOracle Advanced Planning Command Centerでも使用可能です。
製造可能オーダー%
製造可能構成部品の可用性%
製造準備完了%
上位欠品構成部品
上位欠品仕入先
「基本メトリック」を参照してください。
製造可能シミュレーション
「製造可能シミュレーション」ビューを使用して、競合する製造オーダーへの手持のより望ましい割当方法を試行します。 次の方法があります。
製造可能に対して優先する必要がある重要な製造オーダーの識別
製造オーダーの優先順位付け
他の製造オーダーの優先順位解除
計画オーダーの優先順位付けと優先順位解除
受注の優先順位解除
製造可能シミュレーション: 重要な製造オーダーの識別
需要/供給ビューで、主要な受注をフィルタ処理して、受注の補充に関連するリスクがあるかどうかを識別します。 たとえば、次のフィルタを使用します。
収益
予定出荷日/納期
顧客
出荷元組織
品目
ペグされた製造オーダー供給の表示処理を使用します。 これにより、主要な受注にペグされた製造オーダーとその製造可能属性が表示されます。
対象のオーダーを選択し、製造可能ワークベンチ処理を使用します。
製造可能シミュレーション: 製造オーダーの優先順位付け
製造可能にする製造オーダーに優先順位を付けるには、「製造可能優先度」を選択します。
これにより、プランニング・ソルバーでは、次の計画実行時に、優先度が設定されたオーダーに手持供給が割り当てられます。
手持が不十分で優先度が設定されたすべての製造可能オーダーを充足できない場合、プランニング・ソルバーではオーダー納期の順に手持が割り当てられます。
製造可能シミュレーション: 製造オーダーの優先順位解除
製造オーダーの優先順位を解除するには、主要な製造オーダーを選択し、「オーダー競合の表示」をクリックします。
競合対象、つまり、主要な製造オーダーの構成部品の手持について競合している他の製造オーダーが表示されます。 このプロセスでは、主要な製造オーダーに対して最適な改善を提供できる順序で競合対象が表示されます。
構成部品の割当を使用して、優先順位を解除するオーダーを決定します。
「製造可能に対する優先順位解除」を選択します。
製造可能シミュレーション: 計画オーダーの優先順位付けと優先順位解除
確定計画オーダーに優先順位を付けると、プランニング・ソルバーでは、その構成部品を充足するための手持がない場合でも、その確定計画オーダーの日付が使用されます。 その結果、リードタイム圧縮および過負荷例外メッセージが発行される場合があります。
確定計画オーダーの優先順位を解除すると、計画オーダーの確定と日付はそのままですが、プランニング・ソルバーで例外メッセージが発行される場合があります。
計画オーダーに優先順位を付けると、その計画オーダーは確定計画オーダーになります。
計画オーダーの優先順位を解除すると、プランニング・ソルバーでは、次の実行で計画オーダーを再作成するときにその計画オーダーの情報が失われます。
製造可能シミュレーション: 優先度フラグ保持
計画の各実行時に、プランニング・ソルバーでは、ショップ型製造オーダーおよび確定計画オーダーの製造可能優先度と優先順位解除フラグが保持されます。
この項では、Oracle Rapid Planningでプルイン、アップサイドおよびオーダー優先度が考慮されるプロセスとロジックの概要を説明します。 ここでは、オーダー優先度を考慮しながらユーザーがプルインやアップサイドをシミュレートし、計画への影響を分析するためのメカニズムを指定します。オーダー優先度は、ユーザーが設定するか、またはオフライン需要優先順位付けスキームで計算されます。
この機能により、Rapid Planningは、シミュレーション速度、パフォーマンスおよび効率を低下させずに、企業の複数のニーズを満たすことができます。
この項の内容は次のとおりです。
Oracle Rapid Planningの計画ロジックの要約
プルインおよびアップサイド用の計画ロジック
新しい品目属性
新しい例外メッセージ
プルインおよびアップサイドの識別
プルインおよびアップサイドの例
Oracle Rapid Planningの計画ロジックの要約
Oracle Rapid Planningソリューションは、次のロジックに準拠します。
オーダーのリストは、優先度が高い順に順序付けされます。
優先度の最も高いオーダーから一度に1つずつ計画されます。
各オーダーの処理順序は次のとおりです。
供給がオーダー納期を満たすのに使用可能なアップストリームであることを確認します。
これが不可能な場合は、リード・タイムを考慮しながら供給を検索して処理を進めます。
これも不可能な場合は、オーダー遅延が最小限になるように供給を検索します。
オーダーが計画されると、優先度リスト内の次のオーダーが選択される前に、その計画がロックされます。
優先度リスト内のすべてのオーダーが計画されると、需要充足日の昇順に需要がソートされ、FIFOロジックを使用して需要が供給にペグされます。
プルイン・ロジックの目的を次に説明します。需要がプルインされて次の優先度に進み、問題は発生していないがプルインが失敗した場合、つまり、計画ロジックによって改訂オーダー納期に供給が見つからなかった場合、ロジックでは前のプルイン納期に戻す必要があります。 アップサイドの場合は、失敗すると、不足オーダーとして記録されます。
プルインおよびアップサイド用の計画ロジック
プルインおよびアップサイドの計画ロジックは次のとおりです。
アプリケーションでは、オーダーのリストが順序付けされるときに、分割されたオーダーと分割されていないオーダーの両方が考慮されます。 各オーダーには次が必要です。
確定日
確定数量
優先度(優先度は主要オーダー優先度とも呼ばれます)
改訂需要日
改訂需要優先度
次に、アプリケーションではプルインの最高優先度を決定し、すべてのプルイン・オーダーがマークされます。
ステップ2で決定した優先度より高い優先度を持つすべてのオーダーが、確定日および確定数量を使用して計画されます。 この実行の結果、手持プロファイルによって計画可能なプルインおよびアップサイドの量が示されます。
最終的な超過手持は、計画可能なアップサイドの量を示します。
特定の期間の一時超過は、その期間内に計画可能なプルインの量を示します。
ステップ2で決定した最高優先度から最低優先度まで、または供給をすべて使用するまで、計画可能なオーダーが計画されます。
計画対象のオーダーがプルインされると、次のように処理されます。
主要オーダーが計画解除されますが、そのオーダーの履行日は引続き追跡されます。
注意: オーダー全体がプルインされます。部分的なプルインはサポートされていません。
確定数量を使用して、改訂需要日にプルイン・オーダーが計画されます。
このステップが失敗すると、リード・タイムを考慮しながら、改訂需要日と現計画の間で確定数量を検索して処理を進めます。
このステップも失敗すると、遅延が最小限になるように供給を検索します。 これを行うには、改訂需要日と履行日の間で確定数量に対して供給を検索します。
注意: ステップ3供給の検索時には、ステップ3の手持プロファイルが使用されます。
計画が完了すると、需要充足日の昇順に需要がソートされ、FIFOロジックを使用して需要が供給にペグされます。 ただし、部分的なプルインの場合は、部分的にプルインされた数量および充足された日付もソート・ロジックで使用されます。
注意: 一時的なマイナス手持は作成されません。
次の点に注意してください。
受注のリリース: ユーザーは、計画結果をソースの受注管理システムにリリースできる必要があります。
スナップショットのリフレッシュを伴う再計画の起動: 前述したように、プルインおよびアップサイド・ロジックは主にシミュレーション用です。 データはメモリーにのみ保存されます。 ユーザーがスナップショットをリフレッシュして再計画を起動すると、計画に加えた変更は失われます。
遅延需要分析: 遅延需要分析は計画ロジックの一環として実行され、オーダーが納期に充足されなかった事由が判別されます。 事由の中には、アップストリーム制約(生産資源、生産能力など)が含まれる場合があります。 プルインおよびアップサイドの計画時にこれらのオーダーが失敗した場合、つまり、目的の納期にオーダーを充足できない場合は、遅延需要分析ロジックが起動するため、ユーザーは根本原因である制約(資材、仕入先または生産資源)をより的確に把握できます。 ユーザーは根本原因を把握することにより、制約を緩和するために必要な処理を実行できます。
ペギング: 計画ロジックで説明したように、ペギングは計画後に実行される後処理で、計画バケット内でFIFOロジックを使用して需要が供給にペグされます。 ただし、各バケットで部分的に充足される需要の場合は、計画数量が競合しないように、部分数量とその充足日もペギング・ロジックで使用されます。 ペギング・ロジックが表示される需要/供給ビューには、異なるバケットからの部分消込が表示されます。
計画の保存: プルインおよびアップサイドによる計画で、ユーザーが結果に満足した場合は、「計画の保存」機能を使用して計画を保存できます。 計画を保存すると、現行バージョンのラピッド・プランニング計画がデータベースに保存されます。 これは現在の機能と同じで、この拡張機能に影響しません。
プルインおよびアップサイド用の例外メッセージ
改訂需要日に充足されたプルイン・オーダーおよびプルイン数量の遅延を処理するために、4つの新しい例外メッセージ(2つは受注用、もう2つは予測用)が導入されました。 これらは次のとおりです。
プルイン受注の遅延補充: この例外メッセージは、計画ロジックによって、受注明細に対する供給が受注明細の改訂需要日より遅延することが検出された場合に発行されます。
プルイン予測の遅延補充: この例外メッセージは、計画ロジックによって、需要予測に対する供給が需要予測の改訂需要日より遅延することが検出された場合に発行されます。
受注プルイン: このメッセージは、改訂需要日が挿入されているすべての受注に対して発行されます。 次を示します。
改訂需要日までに充足された数量
需要日までに充足された数量
予測プルイン: このメッセージは、改訂需要日が挿入されているすべての予測に対して発行されます。 次を示します。
改訂需要日までに充足された数量
需要日までに充足された数量
プルインおよびアップサイド用の品目属性
Oracle Rapid Planningには、プルインおよびアップサイドをサポートするために次の2つの品目属性があります。
改訂需要日: これは、プルイン・オーダーの納期を示すデータ・フィールドです。 このフィールドが挿入されると、需要明細にプルインが作成されます。
改訂需要優先度: このフィールドにより、「改訂需要日」フィールドに挿入されたプルインの優先度が決まります。 通常、このフィールドの値は確定日より前です。
この2つの新しい属性は、すべてのラピッド・プランニング・ビューの検索機能および拡張検索機能で有効で、ユーザーは、すでにサポートされているエンティティに加えて、改訂需要日および改訂需要優先度による検索を実行できます。 これは、プルインおよびアップサイド・オーダーの分析に役立ちます。
両方の属性には次の特性があります。
デフォルト値がなく、nullが可能なフィールドです。
編集可能です。
一括更新フレームワークを使用して、これらの属性を一括更新できます。 これは、需要/供給ビューで有効である必要があります。
既存のカスタム・セルフサービス・ロード機能を使用して挿入されます。
ロール: アドバンスト・プランニング管理者
ドリル・パス: 「ナビゲータ」->「収集: Oracleシステム」->「セルフサ-ビスロ-ド使用の取引デ-タのロ-ド」
「セルフサ-ビスロ-ド使用の取引デ-タのロ-ド」をクリックすると、「ロード・データ・ファイル」ウィンドウが表示されます。
この画面で、アップロードする必要がある属性が含まれるファイルを選択できます。 このファイルをアップロードするたびに、現在、システム内に存在するすべてのデータが置換されます。
「テンプレートのダウンロード」リンクを使用して、属性をアップロードするのに必要なフォーマットを取得できます。 属性テンプレート・ファイルの名称は次のとおりです。
demandforecast.dat (予測用)
salesorder.dat (受注用)
次に、「改訂需要日」フィールドと「改訂需要優先度」フィールドを使用して作成されたアップサイドおよびプルインの例を示します。
前述の例では、オーダー番号WMT-1011、XYZ-1011およびXYZ-1212は、プルインされたか、またはアップサイドがあります。 オーダー番号WMT-1011およびXYZ-1011はプルインされています。これらのオーダーの改訂需要日と改訂需要優先度に注意してください。 オーダー番号XYZ-1212については、新しい手動需要を作成してアップサイドが計画されています。
ユーザーまたはオフライン・プロセスによって設定されたオーダー優先度をOracle Rapid Planningで考慮するには、プルインおよびアップサイドを識別することが重要です。
Oracle Rapid Planningでは、アップサイドは「手動需要」タイプの新しい需要明細として定義されます。 このオーダーに割り当てられる優先度、オーダーの納期および数量により、オーダー順序内で計画される位置が定義されます。
「改訂需要日」が挿入されると、需要明細にプルインが作成されます。 プルインの優先度は「改訂需要優先度」フィールドに挿入されます。 通常、改訂需要日は確定日より前です。 改訂需要日が確定日より後の場合はプルアウトになり、これは可能ですが、通常ではありません。
前の項に示す新しい品目属性に関する例で、結果内の部分プルイン、完全プルインおよびアップサイドに注意してください。 次の説明では、その例の情報が使用されます。
説明1
オーダー番号WMT-1011は、次に示すように部分的にプルインされます。
確定日 = 2009年2月18日、確定数量 = 1200、優先度 = 2
改訂需要日 = 2009年2月4日、改訂需要優先度 = 6
改訂需要日が確定日より前であるため、オーダーはプルインされます。プルインされる数量は1200で、改訂需要優先度6で計画されます。
説明2
オーダー番号XYZ-1011は、次に示すように完全にプルインされます。
確定日 = 2009年2月11日、確定数量 = 700、優先度 = 4
改訂需要日が確定日より前であるため、オーダーはプルインされます。プルインされる数量は700 (数量全体)で、改訂需要優先度7で計画されます。
説明3
オーダー番号XYZ-1212は、次に示すようにアップサイドがあります。
確定日 = 2009年2月25日、確定数量 = 2000、優先度 = 5
確定日 = 2009年2月25日、確定数量 = 1500、改訂需要優先度 = 8で手動需要が作成されました。
手動需要は、最も低い優先度(この場合は8)を使用して計画されたアップサイドです。
この場合、オーダーの2000ユニットは通常の受注の優先度を使用して計画され、1500ユニットは手動需要の優先度をアップサイドとして使用して計画されます。 両方の需要明細の納期は同じです。
この項で示す例は、次の仮定に基づいています。
このロジックは、予測および受注の両方の需要ストリームに適用されます。
プルインおよびアップサイド情報は、次のいずれかの方法でラピッド・プランニングに渡されます。
バックエンドから: 需要明細に対するプルイン・データ、アップサイド数量、および関連する優先度が挿入され、サポートされているインテグレーション・スキームを介してラピッド・プランニングに渡されます。
需要/供給ビューで手動で作成: ユーザーは関連するフィールドを手動で入力し、プルインまたはアップサイド(あるいはその両方)を作成します。
プルインに対する優先度は、次の2つの方法で指定されます。
外部プロセスで計算: オフライン需要優先順位付けスキームでは、カスタム・ルールに基づいてプルインまたはアップサイドの優先度を計算できるロジックがサポートされています。
手動: プルインまたはアップサイドは、需要/供給ビューで作成したり、更新することができます。 この場合は、ユーザーがプルインおよびアップサイドの優先度を入力します。
需要明細に対して定義され、バックエンドからラピッド・プランニングに受け入れられるアップサイドは、オーダー・タイプが「手動需要」に設定された新しい需要明細として提供されます。
納期を使用して計画するときと、改訂需要日を使用して計画するときで、表示されるペギング情報が異なる場合があります。
このドキュメントでは、確定日は需要日(需要明細の納期)を指し、確定数量は需要明細の数量を指します。
改訂需要日が挿入された場合は、次のように動作します。
需要日が「確定日」にコピーされます。
数量が「確定数量」フィールドにコピーされます。
「確定日」と「確定数量」フィールドは編集できません。
ユーザーは、「改訂需要日」と「改訂需要優先度」フィールドを編集できます。
この動作は、確定および未確定の両方の需要明細に適用されます。
ソリューションの構成部品
ソリューションは次の構成部品で構成されます。
モデル内の条件(後述)
オーダー属性表に追加された新規属性、およびそれらをロードするメカニズム
プルインまたはアップサイド(あるいはその両方)の日付と数量を識別する機能
プルインまたはアップサイド(あるいはその両方)の日付、数量および優先度を考慮して計画する機能
既存のラピッド・プランニング機能に対する影響
次に、プルインまたはアップサイドを作成する際のユーザー処理を説明する一般的なワークフローを示します。
この例では、共通のハード・ディスク仕入先からの供給に対して、4つの顧客が競合しています。 単純化するために、生産リード・タイムはゼロと仮定します。 需要の納期は週の始めです。 ステップ1から5で、顧客の週別需要が判別されます。
需要優先度(顧客、プルインおよびアップサイド)は次のとおりです。
| 顧客 | 優先度 |
| CUST-A | 1 |
| CUST-M | 2 |
| CUST-C | 3 |
| CUST-Mのプルイン | 4 |
| CUST-Cのプルイン | 5 |
| CUST-Aのアップサイド | 6 |
顧客が先週要求した需要は次のとおりです。
| 第1週 | 第2週 | 第3週 | 第4週 | 第5週 | 合計 | |
| CUST-A | 500 | 500 | 500 | 500 | 2000 | 4000 |
| CUST-M | 200 | 200 | 200 | 1200 | 1200 | 2000 |
| CUST-C | 500 | 300 | 700 | 100 | 200 | 1800 |
ハード・ドライブHDD1の今後の供給は次のとおりです。
| 第1週 | 第2週 | 第3週 | 第4週 | 第5週 | 合計 | |
| HDD-1 | 1200 | 1700 | 1800 | 1500 | 1600 | 7800 |
指定された優先順位付けに従って、需要の優先順位付けは次のようになります。
Oracle Rapid Planningでは、顧客需要を計画する際に、前述の優先順位付けスキームが使用されます。
Oracle Rapid Planningの計画ロジックに基づいて、顧客の週別需要が計画されます。 表内では、一時超過が太字で示されています。
| 第1週 | 第2週 | 第3週 | 第4週 | 第5週 | |
| 供給 | 1200 | 1700 | 1800 | 1500 | 1600 |
| バッファ・バランス | 1200 | 2900 | 4700 | 6200 | 7800 |
| CUST-A | 500 | ||||
| 700 | 2400 | 4200 | 5700 | 7300 | |
| 500 | |||||
| 700 | 1900 | 3700 | 5200 | 6800 | |
| 500 | |||||
| 700 | 1900 | 3200 | 4700 | 6300 | |
| 500 | |||||
| 700 | 1900 | 3200 | 4200 | 5800 | |
| 2000 | |||||
| 700 | 1900 | 3200 | 4200 | 3800 | |
| CUST-M | 200 | ||||
| 500 | 1700 | 3000 | 4000 | 3600 | |
| 200 | |||||
| 500 | 1500 | 2800 | 3800 | 3400 | |
| 200 | |||||
| 500 | 1500 | 2600 | 3600 | 3200 | |
| 1200 | |||||
| 500 | 1500 | 2600 | 2400 | 2000 | |
| 200 | |||||
| 500 | 1500 | 2600 | 2400 | 1800 | |
| CUST-C | 500 | ||||
| 0 | 1000 | 2100 | 1900 | 1300 | |
| 300 | |||||
| 0 | 700 | 1800 | 1600 | 1000 | |
| 700 | |||||
| 0 | 700 | 1100 | 900 | 300 | |
| 100 | |||||
| 0 | 700 | 1100 | 800 | 200 | |
| 200 | |||||
| 一時超過(太字) | 0 | 700 | 1100 | 800 | 0 |
現在の週の需要がアップサイドおよびプルインを使用して改訂されます。
| 第1週 | 第2週 | 第3週 | 第4週 | 第5週 | 合計 | |
| CUST-A | 500 | 500 | 500 | 500 | 3500 | 5500 |
| CUST-M | 200 | 1400 | 200 | 0 | 200 | 2000 |
| CUST-C | 500 | 1000 | 0 | 100 | 200 | 1800 |
前述のチャートに従って、顧客Aは第5週にアップサイドが1500ユニットあります。顧客Mは第2週にプルインが1200ユニット、顧客Cは第3週にプルインが700ユニットあります。
一時超過があるため(ステップ5と6を参照)、ステップ6に示すように、通常はラピッド・プランニングでこの週の改訂需要を計画できます。 この週の改訂需要からアップサイドおよびプルインを計画できない場合は、計画に戻り、ステップ5に示すソリューション(改訂されたコミットを考慮しない)に戻します。
Oracle Rapid Planningでは、標準品目などのファントム組立品およびその部品構成表が計画されます。
ファントム組立品の計画オーダーはリリースできません。
Oracle Rapid Planningではプロファイル・オプション「MSC: 新規プランナ下位互換性」が使用されません。
Oracle Rapid Planningでは、フロー製造品目は処理されません。
Oracle Rapid Planningでは、次のエンティティが日別にバケット設定されます。
生産資源および仕入先生産能力。 次のとおりです。
プランニング・ソルバーの処理時間を最小限にするための戦略計画ツールです。
詳細な製造現場計画は実行されず、生産資源は詳細に計画されません。
需要と供給。 タイムスタンプは割り当てられません。
使用可能生産資源生産能力:
第1日に8時間の生産能力、第2日に1時間の生産能力を使用するように製造オーダーが計画された場合、プランニング・ソルバーでは、第1日または第2日のいずれかに生産資源所要量の特定の時間を割り当てません。
プランニング・ソルバーでは、日次バケット内の生産資源生産能力が継続的に有効であることを前提とします。
仕掛製造オーダー完了日。 通常、製造オーダー完了日は最後の日次バケット内に設定され、最後の活動により生産資源生産能力が消し込まれますが、場合によっては後で消し込むことも可能です。 計画ルールは次のとおりです。
通常、1つの生産資源活動は1つの日次バケット内に計画されます。 1つの生産資源活動を2つの連続する日次バケットに計画し、それぞれの日に生産資源使用量を割り当てることもできます。 ただし、1つの生産資源活動が連続しない複数の日次バケットに計画されることはありません。
1つの生産資源所要量が2時間以内の場合は、1つの日次バケット内に計画されます。
1つの工程内では、複数の生産資源は常に連続して計画されます。 つまり、1つの工程内で計画された生産資源の間で、1日以上の間隔が空くことはありません。
2つの工程は、工程間で2日以上の間隔を置いて計画できます。
プランニング・ソルバーですべての生産資源使用量を1つの日次バケットにバケット設定できない場合は、柔軟に計画するために複数の計画オーダーが作成されます。
大規模な生産資源所要量:
1つの生産資源に対する生産資源所要量が2日以上の場合、プランニング・ソルバーでは生産資源生産能力バケットを拡張して、生産資源所要量が複数の日数に分割されます。
計画情報には、生産資源所要量の開始日と終了日が表示され、各日の生産資源使用量も表示されます。 リード・タイムは見積であるため、生産資源所要量の開始日と終了日は生産資源使用量と完全に一致しない場合があります。
生産資源は、1つの工程内に連続して計画されます。
工程が複数の場合は、必ずしも連続して計画されるわけではありません。
2時間を超える生産資源所要量は、連続する複数の日次バケットに計画できます。
一部の生産資源所要量を日次バケットより大きいバケットに設定する必要がある場合でも、工順の他の生産資源所要量については日次バケットを使用できます。
この機能は、次の場合に使用します。
再計画の変更を回避するために供給を確定する場合
Rapid Planningへの計画入力データとして確定供給を使用する場合
次の方法で供給を確定できます。
計画オーダー: 次のことが可能です。
供給を確定し、新規日付と新規数量を入力します。
製造場所のオーダーの場合は、代替部品構成表と工順の組合せを選択して確定します。 この変更後に計画を再実行しないと、計画オーダーをリリースしたときにオーダー・ヘッダーのみが作成されます。
購買元のオーダーの場合は、代替ソースを選択して確定します。
代替構成部品を選択して確定します。
未確定仕掛製造オーダー:
供給を確定し、新規の終了日を入力できます。 計画を再実行すると、プランニング・ソルバーにより次の計画実行で生産資源および構成部品所要量が再計算されます。
ソース内の仕掛製造オーダーを確定すると、プランニング・ソルバーで生産資源および構成部品所要量は変更されません。
未確定発注:
供給を確定し、新規日付と新規数量を入力します。
新規日付を入力しない場合は、計画で提示納期が使用されます。 プランニング・ソルバーにより、提示納期が新規日付に設定され、関連するすべての活動が再計画されます。
プランニング・ソルバーで確定供給の提示納期や数量は変更されません。
供給を確定するとき、プランニング・ソルバーは次のように動作します。
生産資源計画を変更できません。
生産資源または仕入先生産能力を超過できます。
プランニング・ソルバーでは、最初に、優先度が最も高い需要に対する確定作業指示および確定計画製造オーダーが処理されます。 この場合、需要優先度は考慮されません。 ただし、確定オーダーを使用して需要が遅延することはありません。
確定作業指示が処理された後に、未確定作業指示および計画オーダーを使用して優先度別に需要に対する供給が計画されます。
供給が確定される場合、プランニング・ソルバーでは、すべてのアップストリーム供給が確定にペグ済として処理され、遅延は許可されません。 これは、これらのオーダーが無制約計画と同じ方法で圧縮できることを意味します。 供給が計画タイム・フェンスによって確定される場合、これは該当しません。
未確定供給を計画する場合、プランニング・ソルバーでは確定供給の計画と同様の方法が使用されますが、需要納期後の供給も考慮されます。
プロセスは次のとおりです。
プランニング・ソルバーでは、未確定供給が使用され、WIP供給の提示納期オーダーは不必要に変更されません。
未確定供給がすべて選択されるまで、未確定供給が継続して使用されます。
未確定供給が需要日より後の場合、プランニング・ソルバーでは、需要を納期どおりに充足するために未確定供給の再計画を試みます。 WIP供給に対して、代替生産資源、代替構成部品、または代替部品構成表と工順の組合せは選択されません。
これが供給に対して不可能な場合、プランニング・ソルバーでは、需要を納期どおりに充足するために計画オーダーが作成されます。
これが供給に対して不可能な場合、プランニング・ソルバーでは、需要日に可能なかぎり近い日付で計画オーダーが作成されます。 計画オーダー日が計画受入と同じで、既存の供給の使用可能生産能力がある場合は、供給が遅延する場合でも、優先度の低い需要の計画受入が使用されます。
計画オーダー・ペギングに対する作業指示の作業環境を指定するには、Oracle Rapid Planningの品目属性「WIP前の新規計画オーダー・ウィンドウ」をシミュレーション・セットで使用できます。
デフォルト値は10です。
このウィンドウ外の作業指示は、計画オーダーの作成に影響しません。
計画開始日からこの日数の間、プランニング・ソルバーでは作業指示の納期より納期が早い計画オーダーは作成されません。
最初に作業指示の前倒しが試みられ、作業指示の前倒しによって需要が遅延して充足される場合は、このウィンドウ外の計画オーダーが使用されます。
プランニング・ソルバーでは、超過を最小限にするために、未確定オーダーが右側に右揃えされます。 これは、品目-組織属性「許容早期日数」で指定した範囲外の場合のみ実行されます。
プランニング・ソルバーでは、次の場合に計画オーダーが作成されません。
計画範囲内に使用可能な生産資源生産能力または資材生産能力がない場合
計画範囲がリード・タイムより短い場合、計画オーダーは作成されません。
Oracle Advanced Supply Chain Planningでは、計画範囲内の制約により、計画範囲の最後に計画オーダーが作成されます。 Oracle Rapid Planningソルバーでは、例外メッセージ「未充足需要数量」が生成され、計画の最後に計画オーダーは作成されません。
プランニング・ソルバーでは、需要に対して完全な供給を作成できない場合、需要充足日が計画範囲終了後の日付に設定されます。
この機能は、次の場合に使用します。
代替部品構成表、工順および生産資源を使用する場合
需要を満たすために可能な場合は代替供給を使用する場合
プランニング・ソルバーでは、需要を充足するためにすべての代替が供給とみなされます。
検索パスは、最初に深度を指定し、次に幅を指定します。 検索時に、プランニング・ソルバーでは、部分数量を検索した後に、需要を充足するのに必要な残数量を検索できます。 部分数量を使用するのは、オーダー・モディファイアを満たす場合のみです。
検索順序は次のとおりです。
最初に、ソース・ルールに基づいて主ソースを検索します。
最初に手持を使用し、受入中、計画受入の順に使用します。
サプライ・チェーンの最後まで各ソースの供給可用性をチェックし、その後に次の下位ランクのソースをチェックします。
全レベルで各代替ソースを検索し、その後に次の代替ソースに進みます。
ソース・ルールにおける主ソースは、割付パーセントが最も高いランク1のソースです。 プランニング・ソルバーでは、割付パーセントがあるランク1のソースをすべて検索し、その後にランク2のソースを検索します。
ランク1の複数のソースで割付パーセントが同じ場合、エンジンでは最初に検出されたソースを選択します。
検索パスに製造ソースがある場合は、次のように処理されます。
最初に、代替構成部品と代替生産資源を使用して、主部品構成表と工順の組合せを検索します。
次に、代替構成部品と代替生産資源を使用して、連続する代替部品構成表と工順の各組合せを検索します。 部品構成表のランク順に代替を検索します。
プランニング・ソルバーでは、すべての代替ソースが検索対象になるまで代替ソースを検索し続けます。
完全な検索パスを使用して、最初の代替品目を検索します。
完全な検索パスを使用して、連続する各代替品目を検索し続けます。
需要を期日内に充足できない場合は、再検索して、供給遅延を最小限にするように試みます。 主ソースの供給日が代替ソースの供給日より後の場合は、代替ソースを使用して遅延供給を作成できます。
すべての生産資源は、ボトルネック生産資源としてデフォルト設定されます。 ユーザーは、フラグの選択を手動で解除する必要があります。
シミュレーション・セットで、制約付き計画内の生産資源のボトルネック・フラグを選択できます。
選択: プランニング・ソルバーでは、過負荷にならないように生産資源が計画されます。 生産資源生産能力負荷により、生産資源所要量を早期に計画したり、計画オーダーを遅延して計画できます。
選択解除: プランニング・ソルバーでは、生産資源所要量が計算され、生産資源期間が示されます。 生産資源が過負荷の場合は、例外メッセージが発行されます。 必要に応じて生産資源所要量が計算され、生産資源生産能力負荷により早期に計画されません。 生産資源生産能力負荷により計画オーダーは遅延して計画されませんが、生産資源期間が圧縮されていない場合は遅延できます。
ボトルネック生産資源グループはありません。
この機能は、次のことが可能な類似製品がある場合に使用します。
ある品目の需要を別の品目の供給で充足できる場合
ある構成部品のかわりに別の構成部品を使用できる場合
ラピッド・プランニングでは、次の両方が計画されます。
最終品目代替
構成部品代替
プランニング・ソルバーでは、最終品目代替の次の機能のみ使用されます。 『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』を参照してください。
一方向
双方向
推測
計画属性: 計画で代替セットが指定されている場合、プランニング・ソルバーではその代替セットが使用されます。ユーザーは最終品目代替に対して代替セットを使用する必要があります。
プランニング・ソルバーで次のプロファイル・オプションは使用されませんが、これらの値が設定されているのと同じように動作します。
MSO: 代替用の供給の選択: 「全供給」
MSO: 品目代替関係の推測の使用不可: 「Yes」
MSC: 代替関係で供給を作成する品目の選択: 「品目属性の追跡」
MSO: 最終品目代替優先度の推測に有効日を使用: 「No」
最終需要を充足するために、常に部分代替供給を使用できます。 プランニング・ソルバーでは、顧客固有の最終品目代替ルールは使用されません。
Oracle Rapid Planningでは構成部品代替がサポートされており、代替の発生方法および発生順序を制御できます。 予定どおりに需要を満たせるかぎり、ラピッド・プランニングでは、次のいずれかの動作に従います。
代替部品の仕様および原価が主構成部品と非常に類似している場合や代替構成部品が生産終了フェーズにある場合は、主構成部品の購買または製造前に供給をすべて使用できます。 このような場合は、主構成部品の新規オーダーを作成する前に、代替構成部品の手持および計画受入を使用できます。
たとえば、代替構成部品が主構成部品より高額な場合や過剰指定(2GBカードのかわりの4GBカードなど)の場合など、主構成部品の新しい供給を作成するほうが有利で費用効果が高い場合があります。
場合によっては、必要な2%レジスタを1%レジスタで置換するなど、現在の品目に対する不適切な置換となります。 このように、主構成部品に既存または新規の供給を使用して期限内に需要に対応できない場合は、主構成部品を代替することが適切な判断です。
2つの動作は必要に応じて切り替えることができます。
Oracle Rapid Planningエンジンでは、構成部品の供給を完全または部分的に検索し、期限内に需要に対応できます。 見つからない場合、その検索は破棄され、次のステップに移動します。 すべてのレベルで構成部品の供給が、次の順序で検索されます。
主構成部品の既存の供給(手持および計画受入を含む、つまり、発注、購買依頼、確定作業指示、非標準製造オーダー)
代替の既存の供給
主の新規供給の作成
代替の新規供給の作成
代替および主の一部の数量によって所要量が満たされる場合、組立品の製造オーダーは分割されません。 単一オーダーのままになるか、必要に応じてオーダー・モディファイアに基づいて構成部品所要量が主と代替に展開されます。
注意: 通常、主および代替構成部品の検索では、未確定WIPは既存の供給の一部として考慮されません。
次に例を示します。
完成品Aには、ランク1が転送、ランク2が製造のソース・ルール設定があり、BおよびCの構成部品が使用されます。 C1はCの代替です。期限内に需要に対応するための検索順序はAの転送です。 これで対応できない場合、ラピッド・プランニングでは、最初にCの既存の供給、次にC1の既存の供給が使用されます。
アップストリームの供給の検索順序は制御できます。 つまり、これらの制御を使用して、検索順序を次のように構成できます。
主の既存の供給
代替の既存の供給
主の新規供給の作成
代替の新規供給の作成
制御の設定方法の詳細は、このガイドの「構成部品代替のユーザー制御」を参照してください。
新しい供給を作成する場合、ラピッド・プランニング・エンジンでは、主およびすべての代替BOMにユーザー指定の順序が使用されます。 この検索順序は、期限内に需要に対応できるかぎり適用されます。 しかし、代替の既存の供給(前述のステップ2)がある場合は、ラピッド・プランニング・エンジンによって、主の新規供給の作成(前述のステップ3)が選択される可能性があります。 これが発生するのは、代替の既存の供給を使用すると制約またはリード・タイムのために需要が潜在的に遅延するため、主の新規供給の作成によって期限内に需要に対応できない可能性がある場合です。
ラピッド・プランニング・エンジンでは、最小限の遅延になるように、供給作成オプションが主対代替で評価されます。 たとえば、需要の期限がD20で、主および代替のいずれの既存の供給を使用しても期限内に需要に対応できないときは、主の新規供給の作成では需要がD25にプッシュされ、D22など需要をより早く充足することになる代替の新規供給を作成できる場合、主の新規供給は作成されません。
レベルごとの検索
ラピッド・プランニングで代替構成部品の既存の供給を検索すると、現在のレベルおよびすべてのアップストリーム・レベルが一度に1レベルずつ検索されます。 その際は、この複数レベルの検索に適した品目およびチェーン内でアップストリーム検索に適した品目を指定できます。
これらの制御を使用して、検索順序を次のように調整できます。
主の既存の供給
代替の既存の供給
アップストリーム構成部品の既存の供給を伴う主の新規供給の作成(1レベルずつ)
アップストリーム構成部品の既存の供給を伴う代替の新規供給の作成(1レベルずつ)
主の新規供給の作成
代替の新規供給の作成
遅延しきい値
構成部品代替は需要が納期に確実に対応するのみでなく、納期のウィンドウ内で充足された需要が期日どおりとみなされるように、構成可能な特定のオフセットも使用可能にします。
これは、新しい計画オプション「既存供給の消込の遅延しきい値」を使用することで実行します。 この計画オプションにはプラスの整数を設定できます。 デフォルトはゼロです。
次に例を示します。
次の例では、完成品(F)は2つの主構成部品(P1、P2)で構成され、その代替構成部品(それぞれS1、S2)があるとします。 これらの各構成部品は、次に示すBOMを使用して製造されます。
代替構成部品S1の手持アップストリームがあり、検索パスが次のように構成されているとします。
主の既存の供給
代替の既存の供給
アップストリーム構成部品の既存の供給を伴う主の新規供給の作成(1レベルずつ)
アップストリーム構成部品の既存の供給を伴う代替の新規供給の作成(1レベルずつ)
主の新規供給の作成
代替の新規供給の作成
需要の期日がD10で、既存のアップストリーム供給(前述のステップ3)によってS1の計画オーダーを作成してD11に需要を充足し、主の新規供給(前述のステップ5)をD10に作成した場合は、期限内に需要を充足する代替となるように、主の新規供給が作成されます。
| 需要数量 | 納期 | パス | 充足数量 | 日付 | 選択 |
| 100 | D10 | P1、P11、P12 | 100 | D10 | Yes |
| 100 | D10 | S1、S11、S12 | 100 | D11 |
ただし、遅延計算のしきい値はユーザーが構成できます。 2日の遅延しきい値を指定すると決定が変更され、ラピッド・プランニングによって、既存のアップストリーム供給が指定された代替の供給の作成が選択されます。 これは、需要充足日付が納期 + 遅延しきい値であるためです。
顧客による遅延しきい値が2日の場合
| 需要数量 | 納期 | パス | 充足数量 | 日付 | 選択 |
| 100 | D10 | P1、P11、P12 | 100 | D10 | |
| 100 | D10 | S1、S11、S12 | 100 | D11 | Yes |
レベルごとの複数レベル検索からの構成部品の除外
場合によっては、大規模な複数レベルの検索は不要です。 ラピッド・プランニングを使用すると、3つの理由でこの大規模な検索から検索サプライ・チェーンの一部を除外できます。
たとえば、アップストリーム構成部品に低コストの性質がある場合など、既存の供給アップストリームを未使用のままにするほうが望ましい場合があります。
これを広範囲に実行する場合は、パフォーマンス・ヒットが発生します。 したがって、すべてのコンポーネントに対する検索の実行はお薦めしません。
主構成部品のアップストリーム手持は、他の目的のために保持されている場合があります。 代替の新規供給の作成(期限内に需要に対応できる場合)など、需要を充足するめに他のオプションを使用することもできます。
次に例を示します。
主構成部品P1とP2の両方および代替S2の構成部品に対してアップストリーム手持がある場合を考えてみます。
需要の期日がD10で、Pの品目属性がこの複数レベルの検索から除外されるように設定されている場合、ソルバーではP1とS2を使用するオプションが選択されます。P2の既存の供給アップストリームがあるという事実は無視されます。
遅延しきい値 = 0日
| 需要数量 | 納期 | パス | 充足数量 | 日付 | 選択 |
| 100 | D10 | P1およびP2 | 100 | D10 | S21で主の製造前に消込の品目属性が「No」に設定されているため、「No」が使用されます。 |
| 100 | D10 | P1およびS2 | 100 | D10 | Yes |
既存の供給に対する主構成部品と代替構成部品の切替え
主供給と代替供給の既存の供給間で、優先順位を指定できます。 優先順位を設定することで、ラピッド・プランニングで主に新しいオーダー、つまり、新しいリビジョンが作成される前に、ライフ・サイクルが短い製品および古いリビジョンを示す代替が使用されます。
新しいプロファイル・オプション「MSO: RP - 構成部品代替ロジック」で、この切替えを制御します。 使用可能な場合、検索順序は次のように変更されます。
代替の既存の供給
主の既存の供給
アップストリーム構成部品の既存の供給を伴う代替の新規供給の作成(1レベルずつ)
アップストリーム構成部品の既存の供給を伴う主の新規供給の作成(1レベルずつ)
主の新規供給の作成
代替の新規供給の作成
注意: このプロファイル・オプション「MSO: RP - 構成部品代替ロジック」は詳細計画オプションとしても使用可能です。
注意: 代替は、そのレベルでの既存の供給(つまり、1と2の置換)、または既存の供給アップストリーム(つまり、3と4の置換)の場合にのみ優先されます。 新規供給では引き続き「最初に主」アプローチが使用されます。
構成部品代替は、主構成部品レベルで設定するか、主を製造する前に消し込むように設定できます。
計画オプション : MSO: RP - 構成部品代替ロジック
計画オプション「MSO: RP - 構成部品代替ロジック」は、計画全体に適用されるグローバル設定です。 詳細計画オプションとしても使用可能です。 次の項に示すように、これらの設定は個々の品目レベルで上書きできます。 「MSO: RP - 構成部品代替ロジック」は、次のいずれかのオプションに設定されます。
代替を使用する前に、主、既存および新規の供給を使用します。
既存のすべての供給をすべて使用します(最初に主)。c. 既存のすべての供給をすべて使用します(最初に代替)。
既存のすべての供給をすべて使用します(最初に代替)。
デフォルト設定は主を使用です。
既存のすべての供給をすべて使用する(最初に主)設定の場合は、この順序で供給が消し込まれます。
主の既存の供給
代替の既存の供給
主の新規供給の作成
代替の新規供給の作成
既存のすべての供給をすべて使用する(最初に代替)設定の場合は、この順序で供給が消し込まれます。
代替の既存の供給
主の既存の供給
主の新規供給の作成
代替の新規供給の作成
既存の供給には、手持、確定および未確定の発注、購買依頼およびWIPオーダーが含まれます。
主構成部品レベルでの構成部品代替の設定
新しい品目属性構成部品代替ロジックを使用できます。 有効な値はa、bまたはcです。
a - 代替を使用する前に、主、既存および新規の供給を使用します。
b - 既存のすべての供給をすべて使用します(最初に主)。
c - 既存のすべての供給をすべて使用します(最初に代替)。
注意: この品目属性は、シミュレーション・セットを介したバリュー・チェーン計画(VCP)インスタンスでのみ使用可能です。 ソース・システムでは使用できません。
新しい計画オプションと品目属性との相互作用の制御は、次のとおりです。
構成部品に対する主の製造前に消込の設定
この属性は、既存のすべての供給の使用を試みるプロセス(このガイドの「既存の供給に対する主構成部品と代替構成部品の切替え」の項を参照)の一環として、この品目を消し込む必要があるかどうかを制御します。
注意: すべてのレベルのすべての構成部品に対して設定してください。
主の製造前に消込という新しい品目属性があります。 有効な値は「Yes」および「No」です。デフォルト値は「No」です。
注意: これは、シミュレーション・セットを介したVCPインスタンスでのみ使用可能な品目属性で、ソース・システムでは使用できません。
例:
このガイドの「既存の供給に対する主構成部品と代替構成部品の切替え」項の例では、既存の供給の検索対象に含まれないように、品目P11に対してこの属性が「No」に設定されています。 これによって、この品目およびそのアップストリーム構成部品すべてが、既存の供給に対するこの検索から除外されます。
発注納期が使用不可の場合、プランニング・ソルバーでは発注希望入手日を使用して仕入先生産能力を消し込みます。
各日の開始時に、仕入先生産能力が累積されます。 当日中に起動した計画では仕入先生産能力は累積されず、翌日に累積されます。
仕入先生産能力が拡張仕入先リストから欠落している場合、プランニング・ソルバーは次のように動作します。
仕入先生産能力エントリなし: 仕入先生産能力は無限です。
仕入先生産能力に差異がある: 差異がある間、仕入先生産能力はゼロです。
将来の仕入先生産能が欠落: 最後に定義された仕入先生産能力の後は、仕入先生産能力が無限です。
開始時の仕入先生産能が欠落: 最初に定義された仕入先生産能力の前は、仕入先生産能力が無限です。
この機能は、次の管理に使用します。
直近の将来には問題ないが再計画する計画
直近の将来以外に計画されているオーダーの納期
次のように使用します。
品目-組織属性「計画タイム・フェンス日数」の値を計画開始日からの日数に設定します。
計画オプション「計画タイム・フェンス」を選択します。
無制約計画では、計画オーダーの提示納期は、計画タイム・フェンス日付より早い日付に設定されません。 その他のすべての日付は、計画タイム・フェンス日付より前の日付に計画できます。
制約付き計画では、供給タイプに応じて計画オーダーが計画されます。
製造供給: 計画オーダーの提示納期は、計画タイム・フェンス日付より早い日付に設定されません。
購買供給: 計画オーダーの納入予定日は、計画タイム・フェンス日付より早い日付に設定されません。
転送供給: 受入組織での計画オーダーの開始日は、計画タイム・フェンス日付より早い日付に設定されません。
納期超過オーダー
計画受入に過去の提示納期(計画日より前)がある場合、プランニング・ソルバーでは次のように処理されます。
購買依頼および発注の場合は、品目に計画タイム・フェンスがあるかどうかに関係なく、常に先送りされます。
製造オーダーの場合は、常に確定されます。
通常のタイム・フェンス
通常のタイム・フェンスとは、品目に対してユーザーが入力する固定週数から計算される日付とは対照的に、品目の計画受入に基づいてプランニング・ソルバーで計算される計画タイム・フェンス日付です。 プランニング・ソルバーでは、計算された日付の遅いほうが計画タイム・フェンス日付として使用されます。
プランニング・ソルバーに対して、通常のタイム・フェンスを品目の計画タイム・フェンスとして使用するように指示するには、次の操作が必要です。
品目属性「計画タイム・フェンス管理」を選択します。
「詳細」タブで計画オプションを設定します。
「タイム・フェンスの作成」を選択した場合は、プランニング・ソルバーに対して、最新の確定ショップ型製造オーダー、発注、フロー・スケジュールまたは出荷の期日に、品目の通常のタイム・フェンスを作成するように指示します。 スナップショット・プロセスを使用せずに計画を実行する場合も、通常のタイム・フェンスが計算されます。 次に例を示します。
品目属性「計画タイム・フェンス日数」に基づいて計算された計画タイム・フェンス日付は第10日です。品目の最新の計画受入は、納期が第15日の製造オーダーです。計画では、計画タイム・フェンス日付として第15日が使用されます。
品目属性「計画タイム・フェンス日数」に基づいて計算された計画タイム・フェンス日付は第10日です。品目の最新の計画受入は、納期が第5日の製造オーダーです。計画では、計画タイム・フェンス日付として第10日が使用されます。
「計画オーダー・タイム・フェンスの確定」を選択した場合は、プランニング・ソルバーに対して、最新の確定計画オーダーの納期に、品目の通常のタイム・フェンスを作成するように指示します。
「社内購買依頼タイム・フェンスの確定」を選択した場合は、プランニング・ソルバーに対して、最新の確定社内購買依頼の納期に、品目の通常のタイム・フェンスを作成するように指示します。
これらの計画オプションを複数選択した場合は、プランニング・ソルバーに対して、選択した計画オプションでカバーされるすべての供給の中で納期が最新の供給の納期に、品目の通常のタイム・フェンスを作成するように指示します。
通常のタイム・フェンス日付は表示できませんが、品目属性「計画タイム・フェンス日数」を使用して計算された日付が計画タイム・フェンス日付と異なる場合、品目で通常のタイム・フェンスが使用されたことを確認できます。
Oracle Rapid Planningでは、次の構成が計画されます。
受注組立
受注ピック
次のようにモデル構成部品を調達できます。
同じ組織から全部調達
単一インスタンス内の複数の組織から調達
シナリオ
Oracle Rapid Planningでは、次が使用されます。
需要として展開された受注構成予測
需要として展開されたモデル予測
グローバル予測
次のアプリケーションから予測を使用できます。
Oracle Demantra
Oracle Demand Planning
Oracle E-Business Suite
Oracle Rapid Planningでは、常に受注が含まれ、常に受注を使用して予測が消し込まれます。
シナリオ: 需要として事前展開されたモデル予測
Oracle Rapid Planningでは、オプション区分とオプション予測を含む受注組立モデル用に、事前展開された組織固有の予測に対する供給が作成されます。
受注によって予測が消し込まれます。
モデルは単一レベルまたは複数レベルのいずれかが可能です。
ソース・ルールを使用して、半組立品および構成部品が調達されます。
Oracle Rapid Planningでは、オプション、品目およびATOモデル予測を含む受注ピック・モデル予測用に、事前展開された組織固有の予測に対する供給が作成されます。
受注によって予測が消し込まれます。
受注ピック・モデル予測はOracle Rapid Planningに渡されないため、半組立品および構成部品は調達されません。
Oracle Rapid Planningでは、複数の組織間のオプション区分とオプションを含む受注組立モデル用に、事前展開された単一インスタンスのグローバル予測に対する供給が作成されます。
受注によって予測が消し込まれます。
ソース・ルールおよび供給可用性を使用して、比率ベースまたはリージョン・ベースで調達されます。
ローカル組織のソース・ルール、および各構成部品の計画比率を使用して、半組立品および構成部品が調達されます。 Oracle Demantraからの予測の場合は、最終計画比率が渡されます。
Oracle Rapid Planningでは、オプション、品目およびATOモデル予測を含む受注ピック・モデル用に、事前展開された単一インスタンスのグローバル予測に対する供給が作成されます。
受注によって予測が消し込まれます。
受注ピック・モデル予測はOracle Rapid Planningに渡されないため、半組立品および構成部品は調達されません。
シナリオ: 需要として展開されるモデル予測
Oracle Rapid Planningでは、オプション、オプション区分および必須構成部品に対して、組織固有の受注組立モデル予測の供給が展開および作成されます。
受注によって予測が消し込まれます。
計画部品構成表の比率を使用して、モデル予測が各レベルに展開されます。
ソース・ルールを使用して、半組立品および構成部品が調達されます。
Oracle Rapid Planningでは、オプション、品目および受注組立モデル予測を含む組織固有の受注ピック・モデル予測に対して、供給が展開および作成されます。
受注によって予測が消し込まれます。
受注ピック・モデル予測はOracle Rapid Planningに渡されません。
1レベル下に展開された、組織固有の受注ピック予測を渡すことができます。
Oracle Rapid Planningでは、複数の組織間のオプション区分とオプションを含む受注組立モデル用に、単一インスタンスのグローバル予測に対する供給が展開および作成されます。
受注によって予測が消し込まれます。
ソース・ルールおよび供給可用性を使用して、比率ベースまたはリージョン・ベースで調達されます。
ローカル組織のソース・ルール、および各構成部品の計画比率を使用して、半組立品および構成部品が調達されます。
Oracle Rapid Planningでは、複数の組織間のオプション、品目およびATOモデル予測を含む受注ピック・モデル用に、単一インスタンスのグローバル予測に対する供給が展開および作成されます。
受注によって予測が消し込まれます。
ソース・ルールおよび供給可用性を使用して、比率ベースまたはリージョン・ベースで調達されます。
ローカル組織のソース・ルール、および各構成部品の計画比率を使用して、半組立品および構成部品が調達されます。
シナリオ: グローバル予測
Oracle Rapid Planningでは、標準品目について、単一インスタンスのグローバル予測に対する供給が作成されます。
受注によって予測が消し込まれます。
ソース・ルールおよび供給可用性を使用して、比率ベースまたはリージョン・ベースで調達されます。
プランニング・ソルバーでは、無制約で予測が配分されます。 計画比率およびランク1のソース・ルールが使用されます。
受注組立モデル予測の場合、プランニング・エンジンでは、モデル予測が納期どおりに充足されるように、すべての場合においてソース・ルールおよび計画比率に基づいてグローバル予測が配分されます。
予測展開時にオフセットされるグローバル予測の場合、プランニング・ソルバーでは、品目検証組織で定義された処理リード・タイムのみが使用されます。 Oracle Rapid Planningでは、受注を処理するときのみ、固定および可変リード・タイムが使用されます。
事前展開された予測に対する品目属性「予測消込」
モデルの場合は、「消込」または「消込および発生」に設定します。 「消込および発生」に設定することをお薦めします。
モデルの必須構成部品以外の子品目の場合、Oracle Rapid Planningは次のように動作します。
Oracle DemantraおよびOracle Demand Planningの事前展開された予測に対して「消込および発生」に設定するようにユーザーに推奨します。
ATOモデル、PTOモデル、オプション区分、オプションおよび必須構成部品の予測を含めます(オプション)。
予測消込みが実行されます。
予測需要はモデルの計画オーダーにペグされません。
モデルの子品目を「消込」に設定した場合:
Oracle DemantraおよびOracle Demand Planningでは、展開済需要が計算されません。
Oracle Rapid Planningでは、親から展開済需要が作成されません。
モデルの必須構成部品の子の場合、Oracle Rapid Planningは次のように動作します。
「なし」に設定するように推奨します。
展開済需要が計算されます。
計画オーダー需要がモデルの計画オーダーにペグされます。
予測展開に対する品目属性「予測消込」
モデルの場合は、「消込」または「消込および発生」に設定します。 「消込および発生」に設定することをお薦めします。
モデルの必須構成部品以外の子品目の場合、Oracle Rapid Planningは次のように動作します。
Oracle DemantraおよびOracle Demand Planningの予測に対して「消込および発生」に設定するようにユーザーに推奨します。
予測が受注組立モデル、オプション区分、オプションおよび必須構成部品に展開されます。
予測消込みが実行されます。
予測需要はモデルの計画オーダーにペグされません。
モデルの子品目を「消込」に設定した場合、Oracle Rapid Planningでは親から展開済需要が作成されません。
モデルの必須構成部品の子の場合、Oracle Rapid Planningは次のように動作します。
「なし」に設定するように推奨します。
展開済需要が計算されます。
計画オーダー需要がモデルの計画オーダーにペグされます。
計画オプション「予測の展開」を選択します。
Oracle Demantraを使用している場合は、プロファイル・オプション「MSD_DEM: 計画比率の計算」を設定し、最初のダウンロード後はこれを変更しないでください。
Oracle Demand Planningを使用している場合は、プロファイル・オプション「MSD: 計画比率の計算」を設定します。
部品構成表
モデルの場合は、次のことが可能です。
ソース・インスタンスにすでに定義したモデルおよびオプション区分部品構成表に、モデル、オプション区分および品目を追加できます。
モデルおよびオプション区分部品構成表の計画比率を編集できます。
モデルおよびオプション区分部品構成表の「オプション」フラグを編集できます。
計画入力ビューを使用して、これらの変更を行います。
需要計画
次の予測を需要計画として選択できます。
組織固有の受注構成
グローバル受注構成: 複数レベルで複数組織の受注組立モデルがある場合は、適切に予測消込を行うためにそれらを使用することをお薦めします。
組織固有の受注構成予測の場合は、次のいずれかを使用します。
受注組立モデル、オプション区分、オプション・レベルの予測および必須構成部品を含む受注ピック予測。Oracle Demantraでは受注ピック・モデル予測は渡されず、そのオプション、品目および受注組立モデルのみ渡されます。
モデル、オプション区分およびオプション・レベルの予測を含む受注組立予測。
グローバル受注構成予測の場合は、次のレベルでインポートします。
グローバル(品目)
組織
顧客
顧客サイト
ゾーン
顧客ゾーン
マスター組織で、次のプロファイル・オプションを両方とも設定します。
プロファイル・オプション「OE: 品目検証組織」を使用して、品目検証組織を定義します。
Oracle Order Managementの検証組織で共通部品構成表を保守し、プロファイル・オプション「MSC: 予測展開の汎用BOMを含む組織」でその組織を識別します。
予測展開後に、Oracle Rapid Planningでは、ソース・ルールおよび計画比率に基づいて、無制約の方法でグローバル予測が組織に計画されます。 出荷組織で出荷日に基づいて計画され、受入カレンダの制約は考慮されません。
必須構成部品
受注組立予測を事前展開する場合、必須構成部品の予測を渡す必要はありません。これは、Oracle Rapid Planningによって親が消し込まれた後に、その親から必須構成部品の予測が計算されるためです。
事前展開された受注ピック・モデルの場合は、必須構成部品の事前展開された予測が含まれます。
予測展開
Oracle Rapid Planningに対して受注構成予測を展開するように指示するには、計画オプション「展開」を選択します。 予測が展開され、次に予測が消し込まれます。
予測消込
計画オプション「出荷先消込レベル」を設定します。 プロセスでは、「出荷先」の値が同じ予測入力が消し込まれます。
需要区分による消込の場合:
受注に需要区分がある場合、プロセスでは需要区分が同じ予測が消し込まれます。
予測に需要区分がない場合、プロセスではその組織の需要区分が使用されます。
受注に需要区分がない場合、プロセスではその組織の倉庫の需要区分が使用されます。
需要区分によって消し込む際に、予測に需要区分がない場合は、プロファイル・オプションのMSC: ラピッド・プランニング需要区分のない需要予測の消込を設定します。
グローバル予測の場合、プランニング・ソルバーでは次のように処理されます。
すべての受注が、消し込むレベルに集計されます。
受注明細の組織は無視されます。
出荷先エンティティ(ゾーン、顧客サイト、需要区分など)を参照して、在庫組織の受注によってグローバル予測が消し込まれます。
需要区分が受注の需要区分と異なる組織、および需要区分が消込で使用した需要区分と異なる組織に対して、予測および受注が配分されます。
ソース・ルール
Oracle Rapid Planningでは、最初に構成に対してソース・ルールが使用され、次にモデル、ソース階層の順にソース・ルールが使用されます。
グローバル予測の場合は、プロファイル・オプション「MRP: ATP割当セット」を使用して、Oracle Global Order Promisingで使用する割当セット名を指定します。 また、プランニング・ソルバーではこのプロファイル・オプションを使用して、モデルの受注を構成する際のソースが決まります。
構成予測
標準構成対予測を構築し、モデルおよび構成の両方の予測を作成する場合は、予測を顧客固有の予測にします。 モデル予測とその構成部品予測から構成予測の数量を減らします。
プランニング・ソルバーでは、最初に構成品目の受注がある予測が消し込まれ、次にベース・モデルの予測で消し込まれます。
購買モデル
受注組立構成を購買する場合は、「仕入先」ページ->「仕入先サイト」を使用して、その制約を確認できます。
仕入先 - 仕入先サイトの総生産能力を提供してベース・モデルを作成することにより、購買構成を制約できます。
また、次のメトリックを表示できます。
仕入先生産能力稼働率 %
仕入先生産能力
仕入先所要量
プランニング・ソルバーでは次が使用されます。
承認済仕入先リストの受注組立モデルの生産能力(構成品目の仕入先生産能力ではない)
承認済仕入先リストの構成品目のオーダー・モディファイアおよびリード・タイム
オプション依存生産資源
プランニング・ソルバーでは、モデル工順内でオプション依存生産資源が100%ロード済として処理されます。
これにより、生産資源が過負荷と示される場合があります。 このような生産資源は、非ボトルネック生産資源にすることを検討してください。
シミュレーション
モデルおよび構成の予測、およびそのオプション区分、オプションおよび必須構成部品の予測を確定して更新できます。
ただし、Oracle Demantraから事前展開された予測を使用して計画を作成する場合、更新できる受注ピック・モデルおよびオプション区分はありません。
受注明細に対してOracle Order Managementで出荷セットを設定します。 同じ出荷セットが指定された単一の受注の受注明細は、次のように出荷する必要があります。
一緒に: プランニング・ソルバーで出荷予定日が計算されます。
同じ倉庫(組織)から
出荷セットは手動需要で設定することもできます。
プロセス
プランニング・ソルバーでは、無制約計画および制約付き計画で出荷セットが計画されます。
出荷セットのすべての需要を、最も制約された充足日である同日(共通の日付)に充足する供給を作成するために、出荷セットおよび計画の受注明細および手動需要が参照されます。 同じ出荷セットの1つの明細の制約によって、出荷セットのすべての明細が遅延する可能性があります。
プランニング・ソルバーでは次のことは実行されません。
倉庫変更の提示
最終品目代替の考慮
この例では、次のようになります。
品目Cの計画オーダーは第10日までに制約されています。
したがって、プランニング・ソルバーでは、すべての供給およびその受注明細の日付が第5日から第10日に変更されます。
| 品目 | オーダー・タイプ | 数量 | 出荷セット | 需要の納期 | 供給の提示納期(出荷セットがない場合) | 供給の提示納期(出荷セットが考慮された場合) | 需要の出荷予定日(出荷セットがない場合) | 需要の出荷予定日(出荷セットがある場合) |
|---|---|---|---|---|---|---|---|---|
| 品目A | 受注 | 100 | 1 | 第5日 | - | - | 第5日 | 第10日 |
| 品目B | 受注 | 100 | 1 | 第5日 | - | - | 第5日 | 第10日 |
| 品目C | 受注 | 100 | 1 | 第5日 | - | - | 第10日 | 第10日 |
| 品目A | 計画オーダー | 100 | 1 | - | 第5日 | 第10日 | - | - |
| 品目B | 計画オーダー | 100 | 1 | - | 第5日 | 第10日 | - | - |
| 品目C | 計画オーダー | 100 | 1 | - | 第10日 | 第10日 | - | - |
これらは、出荷セットの共通日とは異なる供給納期がプランニング・ソルバーで計画されるときの状況です。 次のとおりです。
制約のために供給を早期に終了する必要があります。 たとえば、生産能力が1日当たり10ユニットのため、第5日に数量30の需要を充足するには、数量10の製造オーダーを3つ計画します。 最初の2つの計画オーダーには第5日ではなく第3日と第4日の納期が割り当てられます。
制約のために供給を遅延して終了する必要があります。 受注に対して遅延補充の例外メッセージが発行されます。
手持から需要を充足することを決定しました。 供給納期は、計画開始日または資材を在庫に移動する予定日に設定されます。
分析および表示
出荷セットを表示および変更するには、「需要/供給」ビューの「出荷セット」フィールドを使用します。 フィールドに値リストはありません。 出荷セット名には文字と数字の両方を使用できます。
出荷セットを問い合せるには、「受注番号」フィールド(「オーダー番号」でなく)および「出荷セット」フィールドを使用します。 異なる受注に同じ出荷セット名を指定できますが、1つの出荷セットは1つの受注にのみ適用されます。 受注2222の出荷セットAは、受注1111の出荷セットAとは異なる出荷セットです。検索フィールド「出荷セット」に値リストはありません。
プランニング・ソルバーによって、出荷セットの遅延を引き起こす受注にのみ制約詳細が割り当てられます。 出荷セットの受注明細すべてをクリックしてから、「制約詳細」をクリックすることをお薦めします。
出荷セットの追加、変更または削除はシミュレートでき、プランニング・ソルバーではその出荷セットが計画されます。
別の受注への受注明細の変更はシミュレートできません。
出荷セットを受注明細に追加すると、明細の確定日が出荷セットの共通日に即時に更新されます。
出荷セットの受注明細の確定日および改訂需要日を変更すると、出荷セットのすべての明細の確定日をこの新しい日付に変更するかどうかを質問するプロンプトが表示されます。 「No」を回答した場合は、変更した確定日を削除する必要があります。
出荷セット名が確保されるように、明細は出荷セット名なしでは一括更新できません。 一括更新には複数の受注が含まれている可能性があるため、プランニング・ソルバーでは共通日を計算できません。
出荷セットに明細がある場合は、受注の確定日および改訂需要日を一括更新できません。 一括更新に出荷セットのすべての明細が指定されているとはかぎらないため、プランニング・ソルバーでは共通日を計算できません。
複数の手動需要に同じ出荷セット名を指定すると、プランニング・ソルバーでは、それらを同時に出荷するように計画されます。 ただし、一部の受注に同じ出荷セット名を使用した場合でも、その出荷セット名は受注に関連付けされません。
シミュレートした新しい計画日は、Oracle Order Managementの受注に渡すことができます。
これはプランニング・ソルバーによって再計画が実行され、例外メッセージ「受注に推奨される変更」が発行される日付です。 受注変更の公開処理を使用します。
この日付は、シミュレーションの実行後に手動で変更した受注には渡されません。 これらの受注明細のリリース・ステータスは「なし」です。
Copyright © 2009, 2014, Oracle and/or its affiliates. All rights reserved.