リリース12.1
B70973-01
目次
前へ
次へ
| Oracle Rapid Planningインプリメンテーションおよびユーザー・ガイド リリース12.1 B70973-01 | 目次 | 前へ | 次へ |
プランニング・ソルバーは、計画プロセスを実行するエンジンです。
このエンジンは、迅速な問題解決および迅速なシミュレーション処理に重点が置かれているため、Oracle Advanced Supply Chain Planningでのこれらの処理方法と異なる場合があります。
サプライ・チェーン計画における多く問題の中では、需要と供給の一致に関する問題が最優先になります。プランニング・ソルバーでは、オーダーの優先順位に厳密に基づいて各オーダーが計画されます。ユーザーは、プランニング・ソルバーで優先度の高い需要が計画された方法を把握することにより、需要が特定の方法で計画された根拠を確認できます。
プランニング・ソルバーでオーダーが計画されると、他のオーダーで使用されないように生産資源や資材がロックされます。優先度の低いオーダーによって優先度の高いオーダーの計画が妨げられることはほとんどありません。
プランニング・ソルバーでは、入力データの小さな変更によって出力に大きな変更が生じないように、計画における影響を最小限にするように試みます。
次のラピッド計画を実行できます。
制約なし: 生産能力は無制限であるとみなされます。
制約付き – 生産能力制約の施行: 生産能力制約が需要納期より優先されます。
プランニング・ソルバーでは、次が計画されます。
代替: 部品構成表、構成部品および生産資源
有効性: 構成部品、プロセス
最終品目代替
オーダー・モディファイア（端数処理管理が含まれますが、固定供給日数は含まれません）
安全在庫: 時間ベース、安全リード・タイムのみ
連産品および副産物
確定
計画タイム・フェンス
カレンダ: 製造、出荷、運送業者
仕入先生産能力の考慮
次の状況は計画されません。
ハブ・アンド・スポーク計画
最小移動数量（MTQ）
総生産資源
順序依存設定
保管期限
計画を解決する前に、計画オプションを設定します。
一部の計画オプションは、プロファイル・オプションからデフォルト設定されます。
ユーザーまたはプランニング・ソルバーは、製造、購買および転送のために計画オーダーをOracle e-Business Suiteソース・インスタンスにリリースできます。リリース・プロセスにより、新しい購買依頼または仕掛製造オーダーが作成されます。ユーザーまたはプランニング・ソルバーは、仕掛製造オーダー、購買依頼および発注の再計画をリリースできます。
プランニング・ソルバーの機能の基本を把握すると、その処理をより理解できます。
プランニング・ソルバーの次の機能は、Oracle Rapid PlanningとOracle Advanced Supply Chain Planningエンジンで共通です。機能の詳細は、『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』を参照してください。
収集
予測消込: 組織固有の予測
予測の配置
予測消込: 品目代替
上書きオプション: 「すべて」または「なし」のみ
需要優先度ルール
計画品目の選択: 計画タイプと同様
ソース・ルール、物流構成表、割当セット
ソーシング有効性
ソーシング・ランク
仕入先生産能力
仕入先カレンダ
仕入先オーダー・モディファイア
仕入先固有リード・タイム
代替生産資源
同時生産資源
最大割当ユニット
ロット基準生産資源
リード・タイムと計画タイム・フェンス
安全在庫: 品目属性の「%」のみ。安全在庫リード・タイム（SSLT）は品目属性「安全在庫 %」から計算されます。各供給はSSLT値より前に計画されます。
カレンダ: 出荷、受入および仕入先生産能力
計画受入: Oracle Work in Processの非標準製造オーダー
例外メッセージ: Oracle Rapid Planningの例外メッセージは、Oracle Advanced Supply Chainの例外メッセージと異なります。
計画オーダーのリリース
制約なし計画
品目制約: 部品構成表有効性
設計変更
代替部品構成表および工順
代替構成部品
副産物
オーダー・モディファイア: 固定供給日数を除く
生産資源制約: 工順有効性
代替工順
工順の工程歩留
生産資源生産能力
生産資源の稼働日カレンダ
生産資源効率および使用率: 日次バケット
確定作業指示
ファントム工順
工順有効性
連産品
フロー製造
最終品目代替
代替構成部品
代替部品構成表/工順
代替生産資源
代替ソース
プランニング・ソルバーの次の機能は、計画オプションによって有効になり、Oracle Rapid PlanningとOracle Advanced Supply Chain Planningエンジンで共通です。機能の詳細は、『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』を参照してください。
計画品目タイプ
計画品目
資材計画方法: 「工程開始日」のみ
最終品目代替セット
割当セット
シミュレーション・セット
需要優先度ルール
上書き: 「すべて」または「なし」のみ
需要タイム・フェンス管理
計画タイム・フェンス管理
予測の配置の有効化
予測バケット別の消込
予測の展開
バックワード日数
フォワード日数
計画期間
日次バケット
組織
保管場所算入
需要計画: 名称、摘要およびタイプ
次に、プランニング・ソルバーで使用する品目属性を示します。機能の詳細は、『Oracle Inventoryユーザーズ・ガイド』および『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』を参照してください。
計画担当
製造/購買
安全在庫比率
最小オーダー数量
最大オーダー数量
固定発注数量
固定ロット乗数
計画方法
供給の作成
オーダー数量端数処理
減損率
計画タイム・フェンス
計画タイム・フェンス日数
需要タイム・フェンス
需要タイム・フェンス日数
リリース・タイム・フェンス
リリース・タイム・フェンス日数
DRP計画済
前処理リード・タイム
処理リード・タイム
後処理リード・タイム
固定リード・タイム
可変リード・タイム
承認済仕入先使用
新規販売価格
販売価格
標準原価
ターゲット安全在庫上書き
次の2つの計画オプションにより、計画に含める品目が決まります。
計画品目タイプ: Oracle Rapid Planning計画の場合、このオプションはOracle Advanced Supply Chain Planning計画の「計画タイプ」と同じです。
MPS計画: 「計画方法」が「MPS計画」および「MPS/MPP計画」の品目が含まれます。
MPP計画: 「計画方法」が「MPP計画」、「MPS/MPP計画」および「MRP/MPP計画」の品目が含まれます。
MRP計画: 全計画品目が含まれます。つまり、「計画方法」が「計画なし」でないかぎり全品目が含まれます。
物流計画: 物流計画の全品目が含まれます。Oracle Rapid Planningに固有の物流計画ロジックはありません。
計画品目: プランニング・エンジンが特定の計画実行で計画する品目のタイプを指定します。
全計画品目
需要計画品目のみ: 需要のある品目のみ計画されます。需要計画に代替品目が含まれる場合、プランニング・ソルバーでは代替品目も計画されます。計画オプション「受注対象」を選択した場合は、需要計画内に対応する品目がある受注のみ含まれます。
需要計画および製造部品
需要計画品目および全受注: 需要のある全品目と、対応する受注のある全品目が計画されます。
需要計画品目、WIP構成部品および全受注
品目リストの規模が最も大きくなるのは、次のように選択した計画の場合です。
計画品目タイプ: MRP計画
計画品目: 全計画品目
Oracle Rapid Planningでは、Oracle Advanced Supply Chain Planningの計画オプション「クリティカル構成部品」が使用されません。シミュレーション・セットを使用して、品目属性「計画方法」を更新します。
Oracle Rapid Planningでは、標準品目を計画するのと同じ方法でファントム組立品が計画されます。
ファントム組立品の計画オーダーはリリースできません。
Oracle Rapid Planningではプロファイル・オプション「MSC: 新規プランナ下位互換性」が使用されません。
制約なし計画の場合、Oracle Rapid Planningでは次のエンティティと方法が使用されます。
品目-組織品目属性「計画タイム・フェンス」:
計画オーダーの提示納期は、計画タイム・フェンス日付より早い日付に設定されません。
納期を使用して、供給が計画タイム・フェンス日付より早いか、遅いか、または計画タイム・フェンス日付の当日かが判断されます。
タイム・フェンスを使用して、作業指示および工程が確定されます。
需要タイム・フェンスとリリース・タイム・フェンス
供給の確定フラグ
代替を選択しない
オーダー・モディファイア: 固定供給日数を除く
生産資源および仕入先生産能力の超過: 生産資源は前倒しで計画され、計画実行日の前に計画されることはありません。
生産資源生産能力の超過、仕入先生産能力の超過、リード・タイム、資材不足によるリスクあり受注/需要予測、および生産資源不足によるリスクあり受注/需要予測に対して例外が発行されます。
Oracle Advanced Supply Chain Planningと同様の日付計算。『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』を参照してください。
圧縮:
製造オーダー: 製造品目のWIP製造オーダーおよび計画オーダーの計画と再計画では、製造オーダーの最初のいくつかの工程を圧縮でき、工程開始日と終了日を計画実行日と同じにすることができます。圧縮は最初の工程で開始され、生産資源期間を使用して残りの工程を完了するのに十分なリード・タイムが確保できるまで、後続の各工程が期間なしに圧縮されます。
購買オーダーおよび転送オーダー: 購買品目の発注、購買依頼および計画オーダーの計画と再計画では、前処理リード・タイム、処理リード・タイム、後処理リード・タイムの順に圧縮が発生します。
工順生産資源所要量および生産資源の日当り最大使用可能時間を使用した、製造供給のリード・タイム。各生産資源のリード・タイムは、次のように計算されます。
リード・タイム = [ (生産資源使用量) / (maxAssignedUnits * maxDailyResourceHrs) ]
各項目は次のとおりです。
maxDailyResourceHrs = 見積オーダー開始日からオーダー納期までの、生産資源当りの1日の最大時間数
見積オーダー開始日 = オーダー納期 – [固定リード・タイム + (可変リード・タイム*数量)]
オーダー納期は、需要納期と同じです。
オーダー納期とオーダー開始日は、製造組織カレンダ上の有効な稼働日です。
生産資源使用量 = オーダー数量 * 工順内の品目当りの使用量（ロット基準の生産資源は除外され、オーダー数量に乗算しません）
maxAssignedUnitsは、工順内の最大割当ユニットです。
リード・タイムに関する注意:
同時生産資源がある場合、そのリード・タイムは、リード・タイムが最も長い生産資源に基づいて決まります。
固定および可変リード・タイムが空白の場合、見積オーダー開始日は計画開始日になります。
ここでは、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時間を超える生産資源所要量は、連続する複数の日次バケットに計画できます。
一部の生産資源所要量を日次バケットより大きいバケットに設定する必要がある場合でも、工順の他の生産資源所要量については日次バケットを使用できます。
次の方法で供給を確定できます。
計画オーダー: 次のことが可能です。
供給を確定し、新規日付と新規数量を入力します。
製造場所のオーダーの場合は、代替部品構成表と工順の組合せを選択して確定します。この変更後に計画を再実行しないと、計画オーダーをリリースしたときにオーダー・ヘッダーのみが作成されます。
購買元のオーダーの場合は、代替ソースを選択して確定します。
代替構成部品を選択して確定します。
未確定仕掛製造オーダー:
供給を確定し、新規の終了日を入力できます。計画を再実行すると、プランニング・ソルバーにより次の計画実行で生産資源および構成部品所要量が再計算されます。
ソース内の仕掛製造オーダーを確定すると、プランニング・ソルバーで生産資源および構成部品所要量は変更されません。
未確定発注:
供給を確定し、新規日付と新規数量を入力します。
新規日付を入力しない場合は、計画で提示納期が使用されます。プランニング・ソルバーにより、提示納期が新規日付に設定され、関連するすべての活動が再計画されます。
プランニング・ソルバーで確定供給の提示納期や数量は変更されません。
供給を確定するとき、プランニング・ソルバーは次のように動作します。
生産資源計画を変更できません。
生産資源または仕入先生産能力を超過できます。
プランニング・ソルバーでは、最初に、優先度が最も高い需要に対する確定作業指示および確定計画製造オーダーが処理されます。この場合、需要優先度は考慮されません。ただし、確定オーダーを使用して需要が遅延することはありません。
確定作業指示が処理された後に、未確定作業指示および計画オーダーを使用して優先度別に需要に対する供給が計画されます。
供給が確定される場合、プランニング・ソルバーでは、すべてのアップストリーム供給が確定にペグ済として処理され、遅延は許可されません。これは、これらのオーダーが制約なし計画と同じ方法で圧縮できることを意味します。供給が計画タイム・フェンスによって確定される場合、これは該当しません。
未確定供給を計画する場合、プランニング・ソルバーでは確定供給の計画と同様の方法が使用されますが、需要納期後の供給も考慮されます。
プロセスは次のとおりです。
プランニング・ソルバーでは、未確定供給が使用され、WIP供給の提示納期オーダーは不必要に変更されません。
未確定供給がすべて選択されるまで、未確定供給が継続して使用されます。
未確定供給が需要日より後の場合、プランニング・ソルバーでは、需要を納期どおりに充足するために未確定供給の再計画を試みます。WIP供給に対して、代替生産資源、代替構成部品、または代替部品構成表と工順の組合せは選択されません。
これが供給に対して不可能な場合、プランニング・ソルバーでは、需要を納期どおりに充足するために計画オーダーが作成されます。
これが供給に対して不可能な場合、プランニング・ソルバーでは、需要日に可能なかぎり近い日付で計画オーダーが作成されます。計画オーダー日が計画受入と同じで、既存の供給の使用可能生産能力がある場合は、供給が遅延する場合でも、優先度の低い需要の計画受入が使用されます。
計画オーダー・ペギングに対する作業指示の作業環境を指定するには、Oracle Rapid Planningの品目属性「WIP前の新規計画オーダー・ウィンドウ」をシミュレーション・セットで使用できます。
デフォルト値は10です。
このウィンドウ外の作業指示は、計画オーダーの作成に影響しません。
計画開始日からこの日数の間、プランニング・ソルバーでは作業指示の納期より納期が早い計画オーダーは作成されません。
最初に作業指示の前倒しが試みられ、作業指示の前倒しによって需要が遅延して充足される場合は、このウィンドウ外の計画オーダーが使用されます。
プランニング・ソルバーでは、超過を最小限にするために、未確定オーダーが右側に右揃えされます。これは、品目-組織属性「許容早期日数」で指定した範囲外の場合のみ実行されます。
プランニング・ソルバーでは、次の場合に計画オーダーが作成されません。
計画範囲内に使用可能な生産資源生産能力または資材生産能力がない場合
計画範囲がリード・タイムより短い場合、計画オーダーは作成されません。
Oracle Advanced Supply Chain Planningでは、計画範囲内の制約により、計画範囲の最後に計画オーダーが作成されます。Oracle Rapid Planningソルバーでは、例外メッセージ「未充足需要数量」が生成され、計画の最後に計画オーダーは作成されません。
プランニング・ソルバーでは、需要に対して完全な供給を作成できない場合、需要充足日が計画範囲終了後の日付に設定されます。
計画オーダーを実行システムにリリースすると、Oracle Rapid Planningでは次の情報が渡されます。
リリース・タイム・フェンス内の計画オーダーが自動リリースされます。
作業指示:
開始日と終了日のタイムスタンプが23:59:59の製造オーダー詳細
生産資源予定開始日と予定終了日のタイムスタンプが23:59:59の生産資源詳細
生産資源使用量
生産資源時間
主部品構成表/代替部品構成表と工順の組合せの選択内容
主構成部品または代替構成部品の選択内容
主生産資源または代替生産資源の選択内容
購買依頼:
選択した仕入先、仕入先サイトおよび出荷方法
タイムスタンプが23:59:59の提示納期
社内購買依頼:
選択したソース組織および出荷方法
タイムスタンプが23:59:59のオーダー日
再計画作業指示:
終了日
計画によって作業指示開始日が決定している場合、オーダーの残りの情報はすべて新規です。
購買依頼の再計画または取消:
オーダー番号
タイムスタンプが23:59:59のオーダー日
発注の再計画または取消:
オーダー番号
タイムスタンプが23:59:59のオーダー日
社内購買依頼の再計画または取消:
オーダー番号
タイムスタンプが23:59:59のオーダー日
ユーザーは、プランニング・ソルバーに対して、計画オーダー、再計画および受注のリリースを自動的に開始するように指示できます（自動リリース）。計画が完了した後にコンカレント処理が開始され、計画オーダーが自動的にリリースされます。
プランニング・ソルバーでは、次の計画オーダーおよび再計画がリリースされます。
スナップショット・フェーズで実行する計画内で発生するもの
品目-組織属性「リリース・タイム・フェンス」に値が設定された品目を対象とするもの。「リリース・タイム・フェンス」は日数で設定します。
品目のリリース・タイム・フェンス内にある計画開始日に、搬送先組織の日付があるもの。
処理が「リリース」に設定されているもの
手動でリリースできるもの。たとえば、ファントム品目のオーダーは除外されます。
スナップショットを使用して計画を実行し、自動リリースを使用する場合は、「メイン」タブで次の計画オプションを設定します。デフォルト値は、未選択またはnullです。
「自動リリースの使用可能」
「自動リリースの使用可能」を選択した場合は、「再計画の自動リリース」を有効にします。
次に、リリース・タイム・フェンスがどのように機能するかを説明します。
「リリース・タイム・フェンス」は日数で設定します。プランニング・ソルバーでは、計画開始日後の日数としてリリース・タイム・フェンスが計算されます。たとえば、リリース・タイム・フェンスが3の場合、リリース・タイム・フェンス日付は計画範囲の第4日になります[計画開始日である第1日 + 3日]。
プランニング・ソルバーでは、リリース・タイム・フェンス日付より前の日付のオーダーがリリースされます。この例では、第1日、第2日および第3日のオーダーがリリースされます。ただし、計画をちょうど午前0時（00:00:00）に実行すると、日付がリリース・タイム・フェンス日付のオーダーもリリースされます。
次に、プランニング・ソルバーで自動リリースの対象を決定する方法を説明します。
計画オーダー: 提示開始日がリリース・タイム・フェンス日付以前の場合
先送り: 古いオーダー開始日がリリース・タイム・フェンス日付以前の場合
前倒し: 提示開始日がリリース・タイム・フェンス日付以前の場合
取消: 提示開始日がリリース・タイム・フェンス日付以前の場合
自動リリース・プロセス中のプランニング・ソルバーの動作は次のとおりです。
ユーザーに対して計画を表示するように指示しません。
適格な各オーダーのリリース・ステータスが「リリース済」に変更されます。
適格な各オーダーの処理中数量がリリース済数量に更新されます。
計画がデータベースに保存されます。
終了直後にコンカレント処理が開始され、適格なオーダーがE-Business Suite実行製品にリリースされます。このプロセスで開始できるコンカレント処理は、「リリースの作成」、「購買依頼インポート」および「WIP一括ロード」です。
ユーザーに対して計画を表示するように指示します。
自動リリースに関するその他の考慮事項:
以降のシミュレーションでは、リリース済オーダーは確定計画受入として表示されます。
後でスナップショットなしで再計画すると、リリース済オーダーは確定計画オーダーのままで、「リリース済」とマークされます。後でスナップショットを使用して再計画すると、最新の収集データを使用して供給と需要の状況が再計画されるため、プランニング・ソルバーではリリース済オーダーが無視されます。
プロファイル・オプションの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は正の数です。小数値も可能です。
ユーザー・インタフェースに、前述のステップでエンジンにより計算された資材計画のターゲット安全在庫数量と導出安全在庫数量の両方が表示されます。
次の点に注意してください。
「ターゲット安全在庫」行および「導出安全在庫」行からドリルダウンはできません。
ターゲット安全在庫数量が表示されるのは、計画オプション「安全在庫リード・タイム方法」を「安全在庫数量の使用」に設定した場合のみです。
週または期間レベルで表示されるターゲット安全在庫数量は、その週または期間内の最終日の値です。
資材計画ビューではターゲット安全在庫数量および導出安全在庫数量を編集できません。
「品目詳細」画面で品目属性「ターゲット安全在庫上書き」が挿入されている場合は、資材計画ビューの「ターゲット安全在庫」行が更新されます。
プランニング・ソルバーでは、基本的なFIFO（先入先出）ペギングが使用されます。Oracle Advanced Supply Chain Planningのペギング・プロファイル・オプションは考慮されません。『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』を参照してください。
すべての需要と供給に対して、次のように処理されます。
日別に需要が供給にペグされます。各日の供給と需要はソートされません。
資材使用可能日を使用して需要がペグされます。資材使用可能日は、各需要を充足する供給が計画されるように計算されます。
その日の供給または需要がそれ以上ない場合は、次の日の供給または需要が使用されます。
計画範囲の終了時に、ペグされていない供給は超過に転記されます。
プランニング・ソルバーでは、需要を充足するためにすべての代替が供給とみなされます。
検索パスは、最初に深度を指定し、次に幅を指定します。検索時に、プランニング・ソルバーでは、部分数量を検索した後に、需要を充足するのに必要な残数量を検索できます。部分数量を使用するのは、オーダー・モディファイアを満たす場合のみです。
検索順序は次のとおりです。
最初に、ソース・ルールに基づいて主ソースを検索します。
最初に手持を使用し、受入中、計画受入の順に使用します。
サプライ・チェーンの最後まで各ソースの供給可用性をチェックし、その後に次の下位ランクのソースをチェックします。
全レベルで各代替ソースを検索し、その後に次の代替ソースに進みます。
ソース・ルールにおける主ソースは、割付パーセントが最も高いランク1のソースです。プランニング・ソルバーでは、割付パーセントがあるランク1のソースをすべて検索し、その後にランク2のソースを検索します。
ランク1の複数のソースで割付パーセントが同じ場合、エンジンでは最初に検出されたソースを選択します。
検索パスに製造ソースがある場合は、次のように処理されます。
最初に、代替構成部品と代替生産資源を使用して、主部品構成表と工順の組合せを検索します。
次に、代替構成部品と代替生産資源を使用して、連続する代替部品構成表と工順の各組合せを検索します。部品構成表のランク順に代替を検索します。
プランニング・ソルバーでは、すべての代替ソースが検索対象になるまで代替ソースを検索し続けます。
完全な検索パスを使用して、最初の代替品目を検索します。
完全な検索パスを使用して、連続する各代替品目を検索し続けます。
需要を納期どおりに充足できない場合は、再検索して、供給遅延を最小限にするように試みます。主ソースの供給日が代替ソースの供給日より後の場合は、代替ソースを使用して遅延供給を作成できます。
増分計画は至急需要に対して使用します。増分計画では、計画データが再度スナップショットされません。
増分計画では、次のすべてが確定されます。
供給
計画オーダー
生産資源生産能力の消込
仕入先生産能力の消込
ペギング関係
プランニング・ソルバーでは、次の場合のみ計画出力が変更されます。
至急需要を充足するために供給を作成して再シャッフルし、充足可能な時期を決定する場合
すべての例外メッセージを再計算する場合
複数の至急需要がある場合、プランニング・ソルバーでは次の順序で計画されます。
需要優先度が最も高い
納期が最も早い
数量が最も少ない
増分計画出力が不十分な場合は再計画を実行します。複数の増分計画を実行しないでください。増分計画を実行するときは、スナップショットを使用、または使用せずに計画を起動して実行します。
再計画するとき、プランニング・ソルバーでは、ユーザーがシミュレーション・セットで手動で変更した内容をスナップショット・データで上書きしません。
Oracle Rapid Planningでは、次の機能がOracle Advanced Supply Chain Planningと同じ方法で使用されます。
社内購買依頼および社内受注: ラピッド・プランニング・ワークベンチでは、社内受注は受注として表示されます。
仕入先生産能力
ロット失効日: Oracle Rapid Planningでは例外メッセージが発行されず、手持の失効は追跡されません。
すべての生産資源は、ボトルネック生産資源としてデフォルト設定されます。ユーザーは、フラグの選択を手動で解除する必要があります。
シミュレーション・セットで、制約付き計画内の生産資源のボトルネック・フラグを選択できます。
選択: プランニング・ソルバーでは、過負荷にならないように生産資源が計画されます。生産資源生産能力負荷により、生産資源所要量を早期に計画したり、計画オーダーを遅延して計画できます。
選択解除: プランニング・ソルバーでは、生産資源所要量が計算され、生産資源期間が示されます。生産資源の過負荷が可能で、例外メッセージを発行できます。必要に応じて生産資源所要量が計算され、生産資源生産能力負荷により早期に計画されません。生産資源生産能力負荷により計画オーダーは遅延して計画されませんが、生産資源期間が圧縮されていない場合は遅延できます。
ボトルネック生産資源グループはありません。
プランニング・ソルバーでは、最終品目代替の次の機能のみ使用されます。『Oracle Advanced Supply Chain Planningインプリメンテーションおよびユーザーズ・ガイド』を参照してください。
一方向
双方向
推測
計画属性: 計画で代替セットが指定されている場合、プランニング・ソルバーではその代替セットが使用されます。ユーザーは最終品目代替に対して代替セットを使用する必要があります。
プランニング・ソルバーで次のプロファイル・オプションは使用されませんが、これらの値が設定されているのと同じように動作します。
MSO: 代替用の供給の選択: 「全供給」
MSO: 品目代替関係の推測の使用不可: 「Yes」
MSC: 代替関係で供給を作成する品目の選択: 「品目属性の追跡」
MSO: 最終品目代替優先度の推測に有効日を使用: 「No」
最終需要を充足するために、常に部分代替供給を使用できます。プランニング・ソルバーでは、顧客固有の最終品目代替ルールは使用されません。
発注納期が使用不可の場合、プランニング・ソルバーでは発注希望入手日を使用して仕入先生産能力を消し込みます。
各日の開始時に、仕入先生産能力が累積されます。当日中に起動した計画では仕入先生産能力は累積されず、翌日に累積されます。
仕入先生産能力が拡張仕入先リストから欠落している場合、プランニング・ソルバーは次のように動作します。
仕入先生産能力エントリなし: 仕入先生産能力は無限です。
仕入先生産能力に差異がある: 差異がある間、仕入先生産能力はゼロです。
将来の仕入先生産能が欠落: 最後に定義された仕入先生産能力の後は、仕入先生産能力が無限です。
開始時の仕入先生産能が欠落: 最初に定義された仕入先生産能力の前は、仕入先生産能力が無限です。
プランニング・ソルバーでは、計画タイム・フェンス日付が使用されます。
制約なし計画では、計画オーダーの提示納期は、計画タイム・フェンス日付より早い日付に設定されません。その他のすべての日付は、計画タイム・フェンス日付より前の日付に計画できます。
制約付き計画では、供給タイプに応じて計画オーダーが計画されます。
製造供給: 計画オーダーの提示納期は、計画タイム・フェンス日付より早い日付に設定されません。
購買供給: 計画オーダーの納入予定日は、計画タイム・フェンス日付より早い日付に設定されません。
転送供給: 受入組織での計画オーダーの開始日は、計画タイム・フェンス日付より早い日付に設定されません。
納期超過オーダー
計画受入に過去の提示納期（計画日より前）がある場合、プランニング・ソルバーでは次のように処理されます。
購買依頼および発注の場合は、品目に計画タイム・フェンスがあるかどうかに関係なく、常に先送りされます。
製造オーダーの場合は、常に確定されます。
通常のタイム・フェンス
通常のタイム・フェンスとは、品目に対してユーザーが入力する固定週数から計算される日付とは対照的に、品目の計画受入に基づいてプランニング・ソルバーで計算される計画タイム・フェンス日付です。プランニング・ソルバーでは、計算された日付の遅いほうが計画タイム・フェンス日付として使用されます。
プランニング・ソルバーに対して、通常のタイム・フェンスを品目の計画タイム・フェンスとして使用するように指示するには、次の操作が必要です。
品目属性「計画タイム・フェンス管理」を選択します。
「詳細」タブで計画オプションを設定します。
「タイム・フェンスの作成」を選択した場合は、プランニング・ソルバーに対して、最新の確定ショップ型製造オーダー、発注、フロー・スケジュールまたは出荷の期日に、品目の通常のタイム・フェンスを作成するように指示します。スナップショット・プロセスを使用せずに計画を実行する場合も、通常のタイム・フェンスが計算されます。次に例を示します。
品目属性「計画タイム・フェンス日数」に基づいて計算された計画タイム・フェンス日付は第10日です。品目の最新の計画受入は、納期が第15日の製造オーダーです。計画では、計画タイム・フェンス日付として第15日が使用されます。
品目属性「計画タイム・フェンス日数」に基づいて計算された計画タイム・フェンス日付は第10日です。品目の最新の計画受入は、納期が第5日の製造オーダーです。計画では、計画タイム・フェンス日付として第10日が使用されます。
「計画オーダー・タイム・フェンスの確定」を選択した場合は、プランニング・ソルバーに対して、最新の確定計画オーダーの納期に、品目の通常のタイム・フェンスを作成するように指示します。
「社内購買依頼タイム・フェンスの確定」を選択した場合は、プランニング・ソルバーに対して、最新の確定社内購買依頼の納期に、品目の通常のタイム・フェンスを作成するように指示します。
これらの計画オプションを複数選択した場合は、プランニング・ソルバーに対して、選択した計画オプションでカバーされるすべての供給の中で納期が最新の供給の納期に、品目の通常のタイム・フェンスを作成するように指示します。
通常のタイム・フェンス日付は表示できませんが、品目属性「計画タイム・フェンス日数」を使用して計算された日付が計画タイム・フェンス日付と異なる場合、品目で通常のタイム・フェンスが使用されたことを確認できます。
製造品目のオーダーを開始できるかどうかを把握する必要がある場合は、「製造可能」を使用します。
構成部品の可用性の不足により、遅延のリスクがある製造オーダーを把握するには、次の操作を実行できます。
構成部品の供給を優先します。
重要なオーダーの製造可能メトリックを優先するために、計画生産を再調整および再順序付けします。
オーダーのすべての構成部品が手持にペグされた場合、そのオーダーは製造可能です。構成部品の一部が計画受入（発注、計画オーダー、転送オーダーなど）にペグされた場合、製造可能ではありません。
プランニング・ソルバーでは、次のオーダーについて製造可能かどうかを判断できます。
計画オーダー
ショップ型製造オーダー – 未リリース
ショップ型製造オーダー – リリース済。プロファイル・オプション「リリース済WIP製造オーダー: 製造可能での考慮」を「Yes」に設定します。
属性およびオプション
シミュレーション・セットで、製造可能に関する次の品目属性を設定します。
製造可能での考慮: プランニング・ソルバーでこの品目-組織の製造可能を計算するかどうかを決定します。デフォルトは「No」です。
製造可能の計算: プランニング・ソルバーでこの計画で製造可能を計算するかどうかを決定します。デフォルトは「No」です。
製造可能範囲: プランニング・ソルバーで製造可能KPIメトリックを計算する範囲。この属性は、オーダーの製造可能が計算される時期には影響しませんが、KPIが収集される期間にのみ影響します。デフォルトは計画範囲です。
プランニング・ソルバーでは、ペギング情報を使用して、各製造オーダーの次の属性が計算されます。
製造可能: すべての構成部品が手持で完全に使用可能な場合は「Yes」。
製造可能構成部品の可用性%: 手持で完全に使用可能な、製造オーダーの構成部品のパーセント。
製造準備完了%: 最も制約された構成部品に基づいて、現在開始できるオーダーのパーセント。この値を設定するには、すべての構成部品が少なくとも部分的に手持にペグされる必要があります。
製造可能日: オーダーが製造可能になる日付。これは、最終構成部品資材が手持に到着する日付です。プランニング・ソルバーで使用されるのは、製造計画オーダーの場合は納期、購買オーダーの場合は納入予定日に後処理時間を加えた日付、転送オーダーの場合は受入日に後処理時間を加えた日付です。
次に例を示します。
数量100の製造オーダーで、次の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日に手持に到着するように計画済
「製造可能」 = 「No」[すべての構成部品が手持で完全に使用可能ではない]
「製造可能構成部品の可用性%」 = 0 [手持で完全に使用可能な構成部品はなし]
「製造準備完了%」 = 10 [製造オーダーの10ユニットが開始可能で、これにより、Aを10ユニット、Bを20ユニット、Cを30ユニット消費。(製造準備完了10ユニット / オーダー数量100) * 100]
「製造可能日」 = 6月30日[構成部品Bが最後に手持に到着]
複数レベル間の製造可能
上位レベルの製造オーダーが下位レベルの製造可能な製造オーダーにペグされた場合、計画サーバーは、下位レベルの組立品目が手持ですでに使用可能であるとみなして動作します。
この例では、次の計画オーダーについて説明します。
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では、次の構成が計画されます。
受注組立
受注ピック
次のようにモデル構成部品を調達できます。
同じ組織から全部調達
単一インスタンス内の複数の組織から調達
シナリオ
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にリリースできます。受注が確定されていない場合は、資材使用可能日および最終品目代替を変更できます。
プランニング・ソルバーでは、受注の予定出荷日を使用して受注が計画されます。受注の予定到着日は使用されません。予定到着日を改善するための代替出荷方法は提示されません。ラピッド・プランニングでは、組織から顧客サイトへの移動リード・タイムは再計算されません。また、計画方法が到着タイプの受注は計画されません。
Oracle Rapid Planningでは、次が含まれる受注のソース組織は更新されません。
受注組立モデル
受注ピック、およびその構成部品、オプション、受注組立モデル。プランニング・ソルバーでは、Oracle Order Managementで選択され、有効在庫数量で計画されたソース組織は変更されません。受注ピック・モデルおよびキットの構成部品の受注明細では、リリース推奨を受け入れません。
生産資源使用量の計画および生産の両方が効率的になる管理可能な製造オーダー・サイズを作成する場合は、デフォルト・オーダー・サイズを使用します。
オーダー・サイズが小さすぎると製造現場が非効率になり、オーダー・サイズが大きすぎると計画が困難になるため、需要に対する供給が遅延する可能性があり、通常は大量の未消込の生産資源生産能力が残ります。
デフォルト・オーダー・サイズを使用するには、計画作業単位（数時間、1シフト、1日、またはこれより大きい期間バケット）を指定します。
計画作業単位
計画作業単位は、時間で指定する品目-組織属性です。
Oracle Rapid Planningでは、計画作業単位を使用してオーダー・サイズが決まります。オーダー・サイズは、計画作業単位時間内に生産できるユニット数です。
次に例を示します。
プランニング・ソルバーでは1日当りの生産能力が考慮されるため、ユーザーは1生産日と同じ数量で計画オーダーを作成するかを判断する必要があります。つまり、Oracle Rapid Planningでは1日当りの生産能力のみが考慮されるため、Oracle Rapid Planningは1生産日すべてを使用する作業単位を作成する必要があります。
生産を長期間実行する場合は、計画作業単位を2日から3日、2週間から3週間などに設定します。
プランニング・ソルバーでは、制約付き計画に対して計画作業単位が使用され、制約なし計画に対してはリード・タイムが使用されます。計画作業単位を使用して計画オーダーのリード・タイムを修正することにより、実行可能な日次計画を迅速に作成できます。
計画作業単位サイズ
計画作業単位オーダー・サイズは、計画作業単位時間内に生産できる品目のユニット数です。プランニング・ソルバーでは、主工順および代替工順ごとに計画作業単位を工順リード・タイムで除算して計算されます。端数処理管理を使用している場合、計画作業単位オーダー・サイズは切り上げるように計算されます。
ユーザーが計画作業単位を定義していない場合、Oracle Rapid Planningでは資材および生産資源の可用性に基づいて、1日に生産可能なオーダー・サイズ数量が使用されます。
生産資源と計画作業単位
プランニング・ソルバーでは次のように処理されます。
計画作業単位の適用
生産資源所要量の分割
生産資源所要量の消込
生産資源と計画作業単位: 計画作業単位の適用
プランニング・ソルバーでは、生産資源所要量が製造オーダー終了時間から前倒しで計画されます。
リード・タイムでカバーされる時間内に生産資源が使用可能な場合、プランニング・ソルバーでは、工程ごとに工程リード・タイムが使用されます。たとえば、リード・タイムが10時間で、1日当り8時間のシフトの場合、リード・タイムは2日間にまたがります。生産資源所要量が10時間で1つの割当ユニットを使用する場合、各日の生産資源生産能力所要量は2時間から8時間の間になります。
プランニング・ソルバーで工程を早い日に移動する必要がある場合は、その日の生産資源所要量を反映して計画されます。次に例を示します。
工程の第2日に、4時間の使用可能生産能力があります。
プランニング・ソルバーでは、第2日に4時間が計画されます。
プランニング・ソルバーでは、その前日に6時間が計画されます。
生産資源と計画作業単位: 生産資源所要量の分割
次に、プランニング・ソルバーで、日次バケット間で生産資源所要量が分割される方法を説明します。
生産資源所要量が2時間を超える場合は、2つの連続した日次バケットに分割されます。2時間以上の使用可能生産能力があるバケットが検索され、残りの生産資源所要量は連続するバケットに計画されます。
生産資源所要量が2時間以内の場合は、1つの日次バケット内に計画されます。
次に例を示します。
生産資源所要量は4時間です。
プランニング・ソルバーでは、2時間以上（所要量の半分）のバケットが検索されます。
ある日次バケットに3.5時間が見つかりました。
その日次バケットの前後で、残りの0.5時間を検索します。
生産資源と計画作業単位: 生産資源可用性の消込
次の例では、プランニング・ソルバーで、日次バケットを使用して生産資源を消し込む方法を説明します。
生産資源可用性:
生産資源A: 1日当り8時間
生産資源B: 1日当り8時間
工順:
工程1: 生産資源Aを使用、生産資源所要量 = 0.25時間
工程2: 生産資源Bを使用、生産資源所要量 = 0.25時間
リード・タイム = 0.5時間[0.25 + 0.25]
計画作業単位 = 16時間
計画作業単位オーダー・サイズ = 32 [16 / 0.5]、16時間で32ユニット生産可能
計画オーダー数量が1から32ユニットの場合は、合計リード・タイム = 16時間
工程1のリード・タイム = 8時間
工程2のリード・タイム = 8時間
需要
数量: 60ユニット
納期: 第8日
次の図に、プランニング・ソルバーによるこれらの計画オーダーの計画を示します。
数量 = 20ユニット、第1日と第2日、リード・タイム = 16時間
数量 = 8ユニット、第5日と第6日、リード・タイム = 16時間
数量 = 32ユニット、第7日と第8日、リード・タイム = 16時間
数量32の計画オーダーについては、プランニング・ソルバーで同じ日に複数の工程を計画できます。
第8日: 工程1、8時間消込[32 * 0.25]
第8日: 工程2、8時間消込
数量32の計画オーダーについては、プランニング・ソルバーで連続した異なる日に複数の工程を計画できます。
第7日: 工程1、8時間消込
第8日: 工程2、8時間消込
数量32の計画オーダーについては、プランニング・ソルバーで連続しない異なる日に複数の工程を計画できます。
第6日: 工程1、8時間消込
第8日: 工程2、8時間消込
数量4の計画オーダーについては、プランニング・ソルバーで同じ日に複数の工程を計画できます。
第8日: 工程1、1時間消込[4 * 0.25]
第8日: 工程2、1+時間消込
オーダー・モディファイア
計画作業単位サイズとオーダー・モディファイアの間に競合がある場合、プランニング・ソルバーでは次のルールを使用して計画オーダー・サイズが決まります。
固定ロット乗数が計画作業単位サイズより大きい場合は、固定ロット乗数が使用されます。
最小オーダー数量が計画作業単位サイズより大きい場合は、最小オーダー数量が使用されます。
最大オーダー数量が計画作業単位サイズより小さい場合は、最大オーダー数量が使用されます。
固定オーダー数量がある場合は、固定オーダー数量が使用されます。
この項では、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に示すソリューション（改訂されたコミットを考慮しない）に戻します。
Copyright © 2009, 2011, Oracle and/or its affiliates.All rights reserved.