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