ダンピング対応システム その２
昨日に続き、私が米国赴任中に作ったダンピングシステムについてご紹介します。
.
ダンピングについては、昨日のブログで説明していますのでそちらを先に読んでください。
.
これ以降は昨日のブログの続きを記します。
.
私が米国に赴任したのは1986年でまだパソコンも普及しておらず、勿論インターネットもない時代でした。でも、ダンピング訴訟を受けて立たなければ会社に大きな損害を与える事になります。
.
ダンピングの説明を一通り聞いたあと、これは大変な事になると直感しました。
システムを使って、仕入価格を割り込む価格では販売していない事を証明しなければならないと直ぐに思いました。でもシステム上は仕入れと販売は別々で全く結びついていません。在庫も製品別の数量合計値しかわかりませんでした。
.
.
倉庫担当者と直接話をし、倉庫の現場では原則FIFO（先入れ先出し）で入出庫しているとの事がわかりました。 であれば、理論上（システムの計算上）FIFOに基づき輸入と出荷を結び付けられるはずと思いました。
.
.
システムは当時System38（AS400の旧版）でRPGでプログラムを作りました。幸いにも月末時点での在庫履歴ファイルがあったので、ある年月末の在庫を、それから直近の輸入Invoiceに遡り理論上の輸入Invoice毎の在庫を割り出します。その後出荷/入庫の履歴を日付順に並べ、先入れ先出しの理論で、輸入Invoiceと出荷Invoice（米国は出荷毎に請求書発行）を結びつける事にしました。でも実際に処理をしてみると、Invoiceに紐づかない入出庫データがある事に気づきました。例えば、棚卸による在庫調整や、顧客からの返品入庫などのデータです。
.
返品入庫に関しては、その顧客に直近に販売したものが返品されたという理屈を当てこみました。在庫調整のプラスに対しては良い案が浮かばず結局、候補のInvoiceの中から最も古いInvoiceを提示し、手で修正できるような仕組みも作ったように記憶しています。
.
System38は汎用機システムですので、結果をレポートで出し、ダンピング訴訟の主幹部門の企画部門責任者に見てもらいました。
.
.
続きはまた明日。
2025年9月3日
コメントを残す