コールドチェーン食品卸売業者における生鮮ロットのトレーサビリティと本番切り替え

課題

生鮮品は待ってくれません。パレットは6〜12時間の枠内で、受け入れ、検品、ロット引当、ピッキングを行い、冷蔵車に積み込む必要がありました。しかし標準の NetSuite の入荷明細は、在庫残高、総勘定元帳への影響、ビン数量を更新する間、出荷ドックを占有していました。朝に入荷が集中すると、保存に12〜18秒かかり、レコード競合エラーが発生しました。運賃請求書は、商品の受け入れと販売から14〜30日後に届くため、粗利益は帳簿上38%でしたが、ランデッドコストを配賦すると27%でした。

1. 生鮮品のロット時計

   生鮮野菜や低温物流の食料品が、90日間も棚に置かれることはありません。入荷パレットが受け入れられないままドックで待つ1分ごとに、廃棄、顧客への誤引当、取り戻せない利益の損失というリスクが生じます。

2. 同期処理による入荷時のロック

   標準の入荷明細は、1件ごとにユーザーのスレッド上で在庫、総勘定元帳、ビン数量を再計算していました。数十枚のパレットが同時に届くと、スキャナーを持つ作業者の画面は保存のたびに15秒間フリーズし、RCRD_HAS_BEEN_CHANGED の競合が発生しました。

3. ランデッドコストのブラックホール

   海上・鉄道・冷蔵輸送の運賃請求書は、商品が動いてから数週間後に届いていました。入荷時の未払計上がないため、コントローラーが利益率を把握するのは月末、仮勘定の中で、営業チームがすでにそれを祝った後でした。

実施内容

出荷ドックと元帳の間にステージングエンジンを置きました。スキャナーは、認証済みで冪等な RESTlet にデータを送信します。RESTlet は、メモリ上で発注明細、子会社、ロケーションを検証し、ステージングレコードを書き込み、1秒未満でスキャナーを解放します。その後、Map/Reduce ワーカーが、ロット番号と有効期限を在庫サブレコードに紐づけ、過去のレーンテーブルから推定運賃と低温保管のランデッドコストを見越計上し、SKU をピッキングウェーブに引き渡します。レガシープラットフォームからの切り替えは、2週間のスプリントの中で、予定されたシフト交代をまたぐ冪等な差分取り込みとして実施しました。

この図はワークフロー設計の一つであり、統制ポイントと関連するエビデンスを含みます。

仕組みの概要

1. 高スループットな RESTlet ステージングキュー

   出荷ドックの作業者や外部倉庫のスキャナーが、標準のトランザクション画面に触れることはありません。RESTlet は、1秒未満のメモリ上で発注明細、子会社、ロケーションを検証し、ペイロードを最適化されたステージングレコードに書き込んで処理を終えます。キューは冪等です。スキャナーが再試行しても、2枚目のパレットは作成されず、同じステージングレコードが更新されます。

2. 決定論的なロットとサブレコードの紐づけ

   生鮮品の管理は、inventoryassignment サブリストで成否が決まります。Map/Reduce ワーカーは、スキャンのペイロードから、ロット番号の作成、有効期限のタイムスタンプの設定、パレットの冷蔵ビンへの割り当てを行うため、紙のタグを見てロット番号を再入力する必要はありません。

3. ランデッドコストの自動見積もり

   入荷時に、エンジンは過去の仕入先レーンテーブルをもとに、見込みの運賃、低温保管費、ドレージ費用を見越計上します。数週間後に運送会社の請求書が仕入先請求書として届くと、マッチング処理が差額を商品の属するロットに配賦します。そのため、販売時の利益はその計上日に正確な値となり、四半期末に償却が積み上がることもありません。

結果

この事例から得られる示唆

1. 倉庫作業者に総勘定元帳を待たせない

   元帳の整合は、バーコードスキャナーを持つ作業者の仕事ではなく、バックグラウンドのキューの仕事です。物理的な入荷処理と会計上の照合を切り離します。

2. 生鮮品のトレーサビリティはサブレコードの厳密さで決まる

   ピッキングと出荷が済んだ後で、誤ったロット番号を修正することはできません。サブレコードのスキーマは、物理的な入力の時点で検証します。

3. 切り替えはカレンダー上のイベントではなく、エンジニアリングの課題

   週末一括の切り替えが失敗するのは、静的なスナップショットを照合するためです。冪等な差分取り込みなら、配送車両を止めることなく、稼働中にシステムを切り替えられます。

複合事例の振り返りです。クライアントは典型例として示しており、数値は仕組みを説明するための例示です。関連: 投資先企業全体での印刷・スキャン・計量の統合