リソース · 62
在庫：在庫状況、予約、同時処理を検証する
在庫（現物、販売可能、予約済み、入荷予定）を区別し、同時購入、キャンセル、チャネル同期をテストします。
更新済み · 3 min
このガイドが達成するのに役立つこと
- 状態の定義
- ユニットとロケーションの接続
- 予約の実行
- 同時実行のテスト
クイックチェック
- 在庫品は常に販売可能でしょうか？
- 払い戻しは常に在庫を解放するか？
- 最後のユニットはどのように確認すべきか？
手順
- 1
状態の定義
物理ユニット、利用可能ユニット、コミット済みユニット、利用不可ユニット、入荷予定ユニットに名前を付ける。 Shopifyはこれらの区別を文書化している。 ここでは、すべてのツールが同一の遷移を実装しているとは限らないため、用語は参考としてのみ使用する。
成果物：ツールごとの状態辞書。
- 2
ユニットとロケーションの接続
販売が許可されているバリアント、ロケーション、チャネルを特定する。 信頼できる在庫状況ソースを選択する。 共有合計は、購入者の注文を履行できない倉庫を隠蔽する可能性がある。
成果物：割り当てと同期ルール。
- 3
予約の実行
ユニットが保留状態になるタイミングと、それが利用可能状態に戻る方法を定義します。 支払い保留、放棄、拒否、キャンセル、返金をテストします。 曖昧なイベントのみに基づいてユニットを解放しないでください。
成果物：トランジションとビジネスイベント。
- 4
同時実行のテスト
架空の最後のユニットを使用して、2つのリクエストを同時に送信し、通知を再生します。 ビジネス結果、最終在庫、および購入に失敗した購入者のメッセージを確認します。 システムの実際の保証に基づいて予約と確認を行います。 想定されるロックについてはテストが必要です。
成果物：同時試行および繰り返し試行の証拠。
- 5
差異を調整します。
移動、予約、および実在庫数を比較します。 同期の遅延と手動調整を特定します。 入荷した在庫は必ずしも販売可能であるとは限りません。 予約注文には、明確な在庫状況と配送ポリシーが必要です。
成果物：差異レポートと修正手順。
再利用可能なワークシート
承認された観察結果を記入してください。 これらのフィールドは作業用テンプレートであり、観察結果ではありません。
| フィールド | 記録する情報 |
|---|---|
| 品目／場所 | バリアント、倉庫、およびチャネル |
| 遷移 | イベントと期待される状態 |
| 同時実行 | リクエスト、予約、および固有の効果 |
| 差異 | 移動、監視、および修正 |
架空の事例
具体的な状況
架空の例：同期遅延中に2つのチャネルが最後のユニットを表示します。
決定と期待される証拠
このテストでは、一方の有効な割り当て、もう一方の注文に対する明示的なメッセージ、および文書化された在庫収束を検証します。
メカニズムの区別
| メカニズム | 目的 | 検証または制限 |
|---|---|---|
| 現物在庫 | 現物在庫数を数える | 販売可能在庫と同一視しない |
| 予約 | 二重割り当てを避ける | リリースと有効期限を定義する |
| 入荷在庫 | 補充準備 | 明確なルールなしに在庫確保を約束しない |
管理指標
| 指標 | 測定対象 | 最初のアクション |
|---|---|---|
| 在庫差異 | 期待値と実測値の差異 | 各修正を在庫移動に紐付ける |
| 保留中の予約 | ルール外で保管されている在庫 | リリース前に原因を調査する |
| 同期遅延 | ソースとチャネル間のラグ | 影響を受ける輸送経路に名前を付ける |
よくある間違い
- 販売可能在庫と同一視しない
- リリースと有効期限を定義する
- 明確なルールなしに在庫確保を約束しない
よくある質問
在庫品は常に販売可能でしょうか？
いいえ。注文を履行できない場所に保管されている場合、在庫が確定、破損、または保管されている可能性があります。
払い戻しは常に在庫を解放するか？
いいえ。現物返品と品質は重要です。 財務上の決定と在庫移動を分離してください。
最後のユニットはどのように確認すべきか？
架空データを使用して2つの同時購入を演習し、注文、割り当て、および最終在庫を検証します。
公式参照文献
参照文献はメソッドを裏付けるものです。 チェックは状況に合わせて調整してください。 これらは認証ではありません。 元の参照文献のタイトルやソース文書は別の言語で書かれている場合があります。
参照資料の確認日 .
