管理画面の在庫調整ポップオーバーが刷新。数量の上書きと「移動」を明示的に分け、調整履歴に「ソース／デスティネーション／実行者／日時」がすべて残るようになった。
数量を書き換えても、誰が・なぜ・どこから動かしたのかは履歴として残らない／残し方が分かりにくい。棚卸ミスの原因追跡が困難。
Set To でも Adjust By でも、すべての操作にソース／デスティネーション／操作者／時刻が紐づく。いつでも履歴ビューから確認できる。
使い方 ： 数量を入力するだけ。Shopify が差分を自動で記録する。
向いている場面 ： 棚卸の結果反映など「最終値だけ分かっている」操作。
使い方 ： ソース（どこから）とデスティネーション（どこへ）を選んで増減を入れる。
向いている場面 ： 拠点間移動・破損・返品・補充など「どこから動かしたか」を残したい操作。
| 操作場所 | 挙動 | ソース／デスティネーション |
|---|---|---|
| 在庫調整ポップオーバー （Set To） |
変更後 数量入力 ＋ 差分を自動記録 | 不要（自動） |
| 在庫調整ポップオーバー （Adjust By） |
新規 ソース／デスティネーションを選んで移動として記録 | 必須 |
| Bulk Editor | 据え置き 利用可能在庫を直接設定。挙動は従来通り。 | 不要 |
「最終的にいくつあるか」だけ分かっている場合。数字を入れて確定。
「どこから来てどこへ行ったか」を残したい操作。トレーサビリティ重視。
個別履歴を必須としない大量編集。これまでの運用通り。
同じポップオーバー内でモード切替する設計。実装側ではユーザー教育用のドキュメント差し替え（手順書のスクショ等）が必要。
モードを問わず記録される。これまで「いつ誰が」を別管理（スプレッドシート等）でやっていた現場は、その仕組みを縮退できる可能性。
記事は管理画面の挙動のみを説明。InventoryLevel／InventoryAdjustment 等の GraphQL 仕様への影響は別途ヘルプ・開発者ドキュメントで要確認。
一括で利用可能在庫を上書きするフローは従来通り。ソース／デスティネーションを要求しないため、業務スクリプトや手順は据え置きでよい。
記事は「view your full adjustment history any time」とだけ記載。誰が見られるか／CSV エクスポートできるか／保存期間はヘルプ documentation 側で確認が必要。監査要件のある現場では事前検証必須。