需要と供給の突き合わせ

Inventory Visibilityでは、各供給タイプは需要タイプに一致します。

以下の表は、どの特定の需要タイプがどの特定の供給タイプに一致するかを示しています。

表 1. 需要タイプと供給タイプの関係
  需要タイプ OPEN_ORDER 需要タイプ RSRV_ORDER 需要タイプ SCHEDULED 需要タイプ BACKORDER 需要タイプ DEMAND_FOR_RELEASE 需要タイプ ALLOCATED 需要タイプ PLAN
供給タイプ ONHAND X X X X X X  
供給タイプ INTRANSIT X X X X   X  
供給タイプ PO_PLACED X X X X   X  
供給タイプ PO_SCHEDULED X X X X   X  
供給タイプ PO_RELEASED X X X X   X  
供給タイプ WIP         X    
供給タイプ PLAN              
注:
  • PLAN タイプは、まだ実体化されていない供給または需要を表します。 これらの操作は、可用性に影響を与えません。 ただし、一時的な将来の補充などの目的のために、供給と需要を追跡することが役立つシナリオがまだ存在する可能性があります。
  • ETA 値は、手持ちの供給ではない供給タイプ (ONHAND および ONHAND を拡張するカスタム・タイプを除くすべてのタイプ) に対してのみ構成してください。 手持ちの供給タイプ (ONHAND および ONHAND を拡張するカスタム・タイプ) の場合は、ETA を構成しないでください。 ここで、ETA は、 Adjust Supply および Sync Supply REST API 内の属性を参照します。

既存の供給タイプまたは需要タイプを拡張することができます。新しいタイプは、基本在庫タイプと同じ方法で在庫状況に影響を与えます。 例えば、ONHAND_BACKROOM は、基本在庫タイプ ONHAND の拡張タイプであり、ONHAND_BACKROOM は、ONHAND と同じように在庫状況に影響を与えます。

供給タイプまたは需要タイプを拡張するには、PUT 要求メソッドを使用して、対応する 「供給タイプ」 または 「需要タイプ」 REST API を呼び出します。 供給タイプまたは需要タイプの派生元となる基本在庫タイプを指定します。

可用性の前のコミットメント・レベル

需要は、コミットメント・レベルに基づいて考慮されます。 コミットメント・レベルは、供給と需要がどのように一致するかを示す最小限の視点です。 在庫状況が計算される前の 3 つの異なるコミットメント・レベルは、約束されておらず、約束されておらず、割り振られています。
約束なし
約束のない確約は、フルフィルメントのために (例えば、e-コマース・ストア・サイトから) 取り込まれたが、まだスケジュールされておらず、特定の出荷ノードがまだ割り当てられていないオーダーに適用されます。 出荷ノードは需要にコミットされていないため、オーダーを別の出荷ノードに簡単に再割り振りできるため、「約束していない」コミットメントと見なされます。
約束
オーダーがスケジュールされるか、特定のフルフィルメント・シップ・ノードに割り当てられると、そのオーダーはコミット済み状態になり、割り当てられた出荷ノードがそのオーダーを担当するようになります。 この段階では、確約は「約束された」需要と見なされ、アイテムを別の出荷ノードに簡単に再割り振りすることはできません (ただし、出荷ノード内で再割り振りすることはできます)。
割り振り済み
割り振られた需要には、常に出荷ノードが割り当てられており、オーダーに対して出荷が作成されたフルフィルメント・プロセスに沿って十分な量があります。 この段階では、セラーがリスクなしで在庫を再割り振りすることは困難です。

Inventory Visibility が供給と需要のマッチングを決定すると、コミットメント・レベルが以下の順序で優先順位付けされます。

  1. 割り振り済み
  2. 約束
  3. 約束なし

結果は、在庫状況要求または予約要求で指定された需要タイプのタイプによって異なります。

可用性ルックアップ

需要タイプの在庫状況が検索されると、その需要タイプの確約レベルが決定されます。 以下の表で説明されているように、コミットメント・レベルに基づいて、需要タイプごとのそれぞれの在庫状況が考慮されます。
表 2. 需要タイプとコミットメント・レベルの関連付け
需要タイプ コミットメント・レベル
オープン・オーダー 約束なし
スケジュール済み 約束
リリースの DEMAND_FOR_RELEASE 割り振り済み
割り当てました 割り振り済み
RSRV_ORDER (SRV_ORDER) 約束
入荷待ち 約束なし
注: 注文する場合は、デフォルトの OPEN_ORDER 需要タイプを使用することをお勧めします。 オーダーのスケジューリングまたはリリースには、SCHEDULED または DEMAND_FOR_RELEASE 需要タイプを使用します。 OPEN_ORDER デマンド・タイプの場合、「約束」および「割り振り済み」は無視されます。

予約中に、入力された需要タイプに基づいて在庫状況がチェックされます。 需要タイプが指定されていない場合、予約はデフォルトで OPEN_ORDER になります。 以下の表では、予約時の在庫状況の計算方法について説明します。

テーブル3。 予約中の在庫状況の計算方法
予約入力需要タイプ 供給 約束されていない予約 (OPEN_ORDER) 約束された予約 (SCHEDULED) 割り振り済み予約 (DEMAND_FOR_RELEASE) 使用可能な予約済みの金額
オープン・オーダー 60 7 15 30時間まで

使用可能 = 供給 (60)-約束なし (7)-約束済み (15)-割り振り済み (30) = 8
オープン・オーダー 60 15 15 30時間まで

使用可能 = 供給 (60)-約束なし (15)-約束済み (15)-割り振り済み (30) = 0
スケジュール済み 60 7 15 30時間まで

使用可能 = 供給 (60)-割り振り済み (30)-約束 (15) = 15
スケジュール済み 60 17 15 30時間まで

使用可能 = 供給 (60)-割り振り済み (30)-約束 (15) = 15
割り当てました 60 7 15 30時間まで

可用性 = サプライ (60)-割り振り済み (30) = 30
割り当てました 31 10 20 30時間まで

可用性 = サプライ (31)-割り振り済み (30) = 1

供給タグと需要タグの一致

需要にタグがある場合、供給には、一致する同等のタグがなければなりません。 需要にタグがない場合は、どの供給にも一致させることができます。

以下の例は、タグの需要と供給がどのように一致するかを示しています。

タグ番号がロット番号、バッチ番号、および改訂番号に分類されている Item01 を検討します。

この例では、 Item01 には以下のサプライ用品があります。
  • Tag: A01|230|v1 Qty: 5
  • Tag: A01|230|v2 Qty: 5
  • Tag: A01|230|v3 Qty: 5
  • Tag: " " Qty: 10 (untagged)
この例では、 Item01 には以下の要求があります。
  • Tag: A01|230|v1 Qty: 5
  • Tag: A01|230|v2 Qty: 7
  • Tag: " " Qty: 15 (untagged)

以下の表は、需要にタグがある供給と需要のマッチングの結果を示しています。 需要にはタグがあるため、それぞれに対応する供給タグが必要です。

テーブル4。 需要にタグがある供給と需要のマッチング
供給 需要 使用可能数量
Tag: A01|230|v1 Qty: 5 Tag: A01|230|v1, Qty: 5 0（5－5＝0）

需要は満たされています。
Tag: A01|230|v2, Qty: 5 Tag: A01|230|v2, Qty: 7 0 (5 から 7 = 0)

このタグ付き需要には、このタグ付き需要に対して十分な供給がないため、消費されていない需要数量は 2 になります。 需要は供給 A01|230|v3 または "" からは取得されません。 これは、タグが一致しないためです。

以下の表は、需要にタグがない、供給と需要のマッチングの結果を示しています。 需要はどの供給とも一致する可能性があります。

テーブル5。 需要にタグがない場合の需要と供給のマッチング
供給 需要 使用可能な数量
Tag: " " Qty: 10 (untagged)

Tag: A01|230|v3 Qty: 5

 " " Qty: 15 (untagged) 0 (10 から 10 = 0) タグなし

0 (5-5) A01|230|v3

タグなしの 10 の供給は消費され、需要数量は 5 のままになります。 需要はタグ付けされていないため、需要はどの供給からでも取得できます。 需要は残りの 5 個を A01|230|v3から取得します。
この例では、最終的な供給在庫ピクチャーが示されています。
  • Tag: A01|230|v1 Qty: 0
  • Tag: A01|230|v2 Qty: 0
  • Tag: A01|230|v3 Qty: 0
  • Tag: " " Qty: 0

タグ付けされていない需要と供給の可用性の修正

tagNumber がブランクの場合、または 3 つのパイプ (|||) がある場合、可用性ピクチャーは、調整または同期供給 (あるいはその両方) では正しくありません。 tagNumber がブランクの場合、または 3 つのパイプ (|||) がある場合も、必要に応じて同じことが言えます。 在庫システムで在庫状況が正確であることを確認するために、 Inventory Visibility は、在庫状況の計算時に、供給または需要をブランクおよび 3 つのパイプ (|||) として tagNumber とマージします。 3本のパイプ（|||）を持つ tagNumber 供給または需要が調整または同期された場合、は tagNumber 空白に置き換えられます。 その結果、GETの「供給」または「需要」の欄には、3本のパイプ（|||）ではなく空白が表示されます。この変更は、および Demand.Change イベントにも Supply.Change 同様に適用されます。
注: tagNumber 3 パイプ (|||) は、ブランクと同じです。
以下の例では、可用性の計算時に、 tagNumber がブランクで 3 つのパイプ (|||) を持つ供給と需要がどのようにマージされるかについて説明します。
供給 需要 使用可能数量
Tag: " " Qty: 50 Tag: " " Qty: 10 80(50+50-10-10=80)
Tag: ||| Qty: 50 Tag: ||| Qty: 10
次の例では、「adjust supply」を使用した場合に「3 pipes ||| 」が空白に置き換えられる仕組み tagNumber について説明しています。
供給 供給の調整 供給の取得 Supply.Change イベント
Tag: ||| Qty: 50 Tag: " " Qty: 30 Tag: ||| Qty: 50 Tag: " " Qty: 30 ChangedQty: 30
Tag: ||| Qty: 50

Tag: " " Qty: 30

 Tag: ||| Qty: 20 Tag: " " Qty: 50
注: 20 個のサプライ用品の場合、 tagNumber ||| はブランクに置き換えられます。 結果として、 tagNumber がブランクの 30 個の供給は、20 個の供給 (30 + 20 = 50) とマージされます。
 Tag: " " Qty: 50 ChangedQty: 20

以下の例では、需要の調整を使用する場合に、 tagNumber 3 パイプ ||| をブランクに置き換える方法について説明します。

需要 需要の調整 需要の獲得 Demand.Change イベント
Tag: ||| Qty: 10 Tag: " " Qty: 7 Tag: ||| Qty: 10 Tag: " " Qty: 7 ChangedQty: 7
Tag: ||| Qty: 10

Tag: " " Qty: 7

 Tag: ||| Qty: 3 Tag: " " Qty: 10
注: 3 つの需要の場合、 tagNumber ||| はブランクに置き換えられます。 その結果、 tagNumber がブランクの 7 つの要求は、このような 3 つの要求 (7 + 3 = 10) とマージされます。
 Tag: " " Qty: 10 ChangedQty: 3

利用可能な数量の合計は 80 (50 + 50-10-10 = 80) です。

以下の例では、同期供給を使用する場合に、 tagNumber 3 つのパイプ ||| をブランクに置き換える方法について説明します。

供給 同期供給 供給の取得 Supply.Change イベント
Tag: ||| Qty: 50 Tag: " " Qty: 30
  • Tag: ||| Qty: 0
    注: これは、 tagNumber ||| との 50 の供給が 0 の数量に同期されるためです。
  • タグ: "" 数量: 30
  • Tag: ||| Qty: 0 ChangedQty: -50
  • Tag: " " Qty: 30 ChangedQty: 30
Tag: ||| Qty: 0

Tag: " " Qty: 30

 Tag: "|||" Qty: 100
  • Tag: ||| Qty: 0
    注: tagNumber ||| はブランクに置き換えられるため、数量は 0 です。
  • Tag: " " Qty: 100
    注: tagNumber ||| はブランクに置き換えられます。
 Tag: " " Qty: 100 ChangedQty: 70

以下の例では、同期要求を使用する場合に tagNumber 3 パイプ ||| をブランクに置き換える方法について説明します。

需要 同期要求 需要の獲得 Demand.Change イベント
Tag: ||| Qty: 10 Tag: " " Qty: 5
  • Tag: ||| Qty: 0
    注: これは、 tagNumber ||| との 10 個の需要が数量 0 に同期されるためです。
  • Tag: " " Qty: 5
  • Tag: ||| Qty: 0 ChangedQty: -10
  • Tag: " " Qty: 5 ChangedQty: 5
Tag: ||| Qty: 0

Tag: " " Qty: 5

 Tag: "|||" Qty: 20
  • Tag: ||| Qty: 0
    注: tagNumber ||| はブランクに置き換えられるため、数量は 0 です。
  • Tag: " " Qty: 20
    注: tagNumber ||| はブランクに置き換えられます。
 Tag: " " Qty: 20 ChangedQty: 15

80(100+0-20-0=80)利用可能な総数量は です。

需要と供給の動向の整合

方式 1 - 最寄りの在庫から先に出荷
この動作では、需要日に最も近い供給が選択されます。
たとえば、システムには2つの納入品があり、1つ目は2026年6月1日に、2つ目は2026年6月5日に到着しました。 この動作に従い、2026年6月8日に需要が発生した場合、システムは2026年6月1日ではなく、需要日に近い2026年6月5日の供給を選択します。
注： これは、需要と供給を照合する際に採用されるデフォルトの動作です。
挙動 2 - 先入れ先出し（FIFO）
この動作では、最初に表示された供給が選択されます。
たとえば、システムには2つの納入品があり、1つ目は2026年6月1日に、2つ目は2026年6月5日に到着しました。 この動作に従い、2026年6月8日に需要が発生した場合、システムは、以前に到着した2026年6月5日の供給ではなく、2026年6月1日の供給を選択します。
IBM® Supportデフォルトの動作を変更するには、までご連絡ください。