reserved から committed へ引っ越す「確保済みだがまだフルフィルされていない在庫」を committed に一本化する一度きりのデータ移行。available と on_hand は変わらず、購入可能数にも影響なし。フィールドの削除・改名も無し。
reserved に計上されていたが、これが committed に移される。committed なので、「確保済みだが未フルフィル」= committed という一本の意味に揃う。
注文由来のホールドは committed、下書き注文・移動・出荷のホールドは reserved。同じ「押さえてある在庫」なのに読む場所が分かれていた。
committed が「売約済みだがまだフルフィルされていない在庫すべて」を表す。下書き注文・移動・出荷のホールドもここに合流する。
いずれも 移行実行時点でまだ在庫をホールドしているもの に限られる。
これらは もう reserved 在庫を保持していないため、そもそも動かす対象が無い。
| 項目 | 影響 | 内容 |
|---|---|---|
| available / on_hand | 影響なし | 数量は一切変わらない。総在庫も不変で、動くのは 2 つの「unavailable」バケットの間だけ。 |
| quantity name | 両方とも有効 | reserved も committed も、引き続き有効でクエリ可能な名前として残る。 |
| フィールド定義 | 削除・改名なし | API のフィールドは削除も改名もされない。スキーマ破壊は発生しない。 |
| 販売可能在庫 | 影響なし | 買い手が購入できる数量は変わらない。ストアフロント側の見え方は変化しない。 |
| 既存クエリの動作 | コード変更不要 | クエリを動かし続けるためのコード修正は不要。返る「値」だけが 2 つの状態の間でシフトする。 |
| 移行前の履歴データ | そのまま | 移行以前の historical data は as-is で保持される。 |
InventoryLevel.quantities(names: ["reserved"]) を読んでいる箇所を全部リストアップする。
「下書き注文／移動・出荷のホールドを検知する目的」で reserved を見ているものが対象。
該当箇所は今後 committed を読む。それ以外はコード変更不要。
| あなたのアプリがやっていること | 移行後に起きること | 対応 |
|---|---|---|
quantities(names: ["reserved"]) を読んでいる |
影響ショップで reserved の値が減り、その分 committed が増える | 要確認 値の変動を前提にロジックを見直す |
| reserved を使って下書き注文／移動・出荷のホールドを特定している | その情報は reserved から消える | 要変更 今後は committed を読む |
| クエリが動き続けるかを心配している | クエリ自体は壊れない | 対応不要 コード変更は required ではない |
| available / on_hand ベースで在庫連携している | 何も変わらない | 対応不要 |
在庫の調整レポート（在庫状態ごとに調整を分解するタイプ）を使っているマーチャントには、reserved の値が committed に移る様子がそのまま表示される。
移行が走ったタイミングで one-time correction entry が記録される。対象は移行時点でアクティブな下書き注文とオープンな移動／出荷のみ。
フィールドの削除も改名も無く、reserved / committed のどちらもクエリ可能なまま。壊れるのは型ではなく 「reserved = 下書き注文のホールド」という暗黙の前提 のほう。
unavailable の内訳が変わるだけで on_hand は不変。reserved + committed の合計で見ている集計なら影響ゼロ。逆に単独で見ている箇所だけが動く。
対象は実行時点で在庫をホールド中のものだけ。完了・キャンセル・解放済みは対象外。移行日時の明示は記載なしなので、日次バッチの差分検知は一時的に跳ねる可能性を織り込む。
在庫調整レポートに一度きりの correction entry が現れる。「原因不明の調整が入った」と誤読されやすいので、BI 側の異常検知ルールを持っているなら事前に周知しておく。
影響範囲の中心は InventoryLevel の quantities(names: [...]) フィールドと、name ごとに返る InventoryQuantity オブジェクト。どの API バージョンから適用されるか、対象ショップの判定条件は記載なし — 影響有無は自分のストアで実測して確認する。
quantities(names: ["reserved"]) を読んでおり、移行後に値が黙って減る。エラーは出ないので気付けない。"reserved" で全文検索 → 用途を「ホールド検知」と「単なる合計表示」に仕分け → 前者だけ committed 参照に切り替える。names: ["reserved","committed"] で両方取って比較しながら段階移行できる。committed ひとつで「spoken for but not yet fulfilled」を表せるため、集計ロジックを 1 本化する。