過去の苦労話・第16回：出荷データと請求データの“本来の姿”と、現場で起きたこと
〜VANは注文だけじゃない。出荷と請求が揃って初めて“電子化”だった〜
業界VANというと、
「注文データを電子化する仕組み」
と思われがちだけど、実は違う。
本来のVANは 三本柱 で動く。
- 注文データ（発注）
- 出荷データ（納品データ）
- 請求データ（仕入データ）
この3つが揃って初めて、
入荷 → 仕入確定 → 支払処理
という“業務の流れ”が電子化される。
でも現場は、そんなに綺麗にいかなかった。
1. 出荷データを物流に上げると何が起きる？
出荷データ（納品データ）が来ると、
物流はこうなる。
「あ、明日この商品が届くんだな」
つまり、
入荷計画が立てられる。
これは本来、めちゃくちゃ便利。
- 荷物の量が予測できる
- 人員配置ができる
- 棚の空きスペースを確保できる
- 入荷処理の段取りが組める
本来なら、
物流が一番喜ぶデータ のはずだった。
しかし──
2. 出荷データが“正確じゃない”と地獄が始まる
現実はこう。
- 出荷データが遅れてくる
- 出荷データが来ない
- 出荷データと実際の荷物が違う
- 数量が違う
- 商品が違う
- そもそも出荷データがFAXで来る（電子化とは？）
結果：
入荷計画が全部崩れる。
物流は怒る。
現場は混乱する。
システム担当は胃が痛む。
3. 物流と本社が“別会社”という構造的バグ
ここがまた地獄ポイント。
- 物流会社：入荷処理だけ担当
- 本社：突合・仕入確定を担当
つまり、こうなる。
- 物流：荷物を受ける
- 物流：入荷データを本社へ送る
- 本社：発注データと突合
- 本社：仕入確定
- 本社：経理へ連携
これ、自動化しないと二重処理になる。
そして当時は──
自動化なんて夢のまた夢。
物流は物流で入力。
本社は本社で入力。
突合しないと怒られる。
でも突合しない。
地獄。
4. 請求データが“紙で降ってくる”問題
請求データも本来はVANで来るはずだった。
でも現実はこう。
- 紙の請求書
- 手書きの請求書
- 月末にまとめてドサッと来る
- 商品名が途中で切れてる（固定長レコードの呪い）
- 品番が違う
- JANが違う
- 数量が違う
- そもそも請求書が来ない（来月まとめて来る）
そして本社はこうなる。
「これ、どの仕入に対応してるの？」
突合できない。
仕入確定できない。
支払処理が止まる。
そして経理が怒る。
5. “ルートに乗らない”仕入先が悪さする
VANに乗らない仕入先は、
注文 → 出荷 → 請求
のどこかが必ず紙になる。
紙になると──
- 読めない
- 違う
- 遅い
- 無い
- 間違ってる
- そもそもFAXが詰まってる
結果：
余計な仕事が増える。
電子化の意味がなくなる。
6. 結論：VANの三本柱は“揃って初めて意味がある”
注文だけ電子化してもダメ。
出荷だけ電子化してもダメ。
請求だけ電子化してもダメ。
三つ揃って初めて“電子化”になる。
でも当時は──
- 直納はFAX
- 出荷データは来たり来なかったり
- 請求データは紙
- JAN突合で止まる
- 物流と本社が別会社
- 自動化は夢
- 現場は混乱
- システム担当は胃が痛い
電子化の夢は正しい。
でも現場の現実はもっと強かった。
コメント