EDIによって受注データの取り込みが自動化されても、出荷時に同梱・送付する納品書だけは取引先指定のレイアウトで出力する必要があります。同じ「納品書」という名前でも、取引先が10社あれば事実上10種類の様式が存在するというのが流通業の実態です。

違いは「項目順」だけでなく「粒度」と「ルール」にまで及ぶ

納品書に記載される情報自体は、納品先、商品明細、数量、単価、合計金額、伝票番号といった項目で大きくは共通します。しかし実際に取引先ごとの仕様書を読み込んでみると、

• 項目の並び順（合計金額が上か下か、税抜・税込の表示順 など）
• 記載粒度（明細を商品単位で出すか、SKU単位で出すか）
• 記載ルール（一定金額以上は別葉に分けるか、複数納品先をまとめてよいか）
• 罫線・余白・フォントサイズの指定

まで細かく規定されているケースが珍しくありません。これを汎用テンプレート1本で吸収するのは無理があり、取引先ごとに専用テンプレートを用意するのが現実解になります。

テンプレート分離設計が長期的な運用負担を決める

EDI対応の販売管理システムであれば、取引先プロファイルごとにテンプレートを切り替えて自動印字できる構造になっています。受注データを取り込んだ時点で取引先が判別され、対応するテンプレートに必要情報が流し込まれて印刷される——この流れが組めれば、現場での手作業による加工はゼロになります。

逆に、汎用システムを取引先ごとにカスタマイズする方式で対応しようとすると、1社追加するたびにテンプレート開発費が発生します。さらに既存テンプレートとの整合性チェック、印字テスト、本番展開の工数まで含めると、新規取引先1社対応に数十万円〜という負担が積み重なっていきます。

仕様変更は不定期に発生する前提で構成を組む

納品書のレイアウト変更要求は、取引先側のシステム改修、流通BMSのバージョンアップ、消費税率変更、インボイス制度対応といったきっかけで、不定期に発生します。「年単位で発生する追加要件」と捉えるのではなく、「日常的に発生する保守要件」と捉えて構成を組むことが大事です。

テンプレート修正だけで対応できる構造にしておけば、こうした突発的な変更にも追加開発費なしで対応できます。EDIシステム選定の段階で、テンプレートの修正にどこまでベンダー作業が必要か、自社で編集できる範囲はどこまでか、を確認しておくと、長期運用での負担感が大きく変わってきます。