EDI／受発注システムと個別4条明示の役割分担— フィールドマッピングと二重書き込み

1. EDIが「担える」とは何か

1-1. 典型的に載る項目

多くのEDI・受発注では、発注番号、品目コード、数量、単価、納期、納入先、支払条件コード（例: 月末締め翌月末払い）が標準フィールドです。
これらは取引の骨格情報であり、4条の「支払期日」「代金の額」に相当する部分を機械的に埋められる場合があります。
ただし「明示」の要件を満たすかは、取引先がそのフィールドを読み取れる形式で受領しているかに依存します。

1-2. EDIだけでは不足しがちな項目

検査・検収の方法、再委託の可否、知的財産の帰属、秘密保持、解除条件、遅延損害金、準拠法・管轄などは、EDI標準項目に無いことが多いです。
これらは個別4条明示（PDF・契約書・メール添付）で別途交付する設計が現実的です。
記載事項の骨格は4条明示の記載事項テンプレと照合し、EDI側に無い行は「別チャネル必須」としてマークします。

1-3. 「システムに入っている＝交付」の罠

発注側の画面に入力済みでも、受注側がその項目をダウンロード・印刷・保存できなければ、実務上の交付とは言えないケースがあります。
クラウド発注の保存設計はクラウド発注と書面保存の観点とセットで、受注側の閲覧ログまで含めて設計します。

2. 役割分担マトリクス（例）

○はそのチャネルで交付完了と数えられる設計、△は案件タイプ次第、×は別チャネル必須です。
マトリクスは取引先ごとにEDI仕様が違うため、ベンダー名とフォーマット版を列に追加して更新します。

3. フィールドマッピング表

3-1. EDI→台帳の対応例

3-2. マッピングに載せない項目

EDIに存在しない4条項目は、台帳の「書面交付ステータス」で管理し、PDFのファイルIDと交付日を紐付けます。
電子署名・タイムスタンプ付与の有無は電子署名と書面交付の運用と揃え、EDI側には署名情報を期待しない設計にします。

4. 二重書き込み（デュアルライト）のリスク

4-1. 何が起きるか

担当者がEDIとExcel台帳の両方に手入力すると、支払期日・金額・受領日がズレます。
片方だけ自動連携、片方だけ手修正という状態が続くと、「どちらが監査正本か」が現場ごとに異なります。

4-2. 正本の一本化

原則: EDI連携済みフィールドはEDI→台帳の一方向のみ。手修正は例外申請と監査ログ必須。
PDF交付項目は台帳が正本。EDIには「書面交付済みフラグ」だけを載せ、本文は載せない。

4-3. 衝突検知

日次バッチで「EDI金額≠台帳金額」「EDI支払条件≠台帳支払期日」を検知し、差分レポートをコンプラ担当へ送ります。
差分が3営業日放置された案件は、書面交付率KPIから一時除外せず「要確認」として残す方が、隠蔽を防げます。

5. PDF・メール併用の順序

5-1. 推奨フロー

(1) 個別4条PDFを生成・署名（必要なら）
(2) メールでPDF添付交付（Message-IDを台帳に保存）
(3) EDI発注データ送信（発注番号・金額・支払条件）
(4) 台帳へEDI取込＋書面交付日・PDF IDを紐付け
順序を逆にすると、「EDIだけ先に届いて4条不足」の状態が生じ、取引先から指摘を受けやすくなります。

5-2. 継続取引の簡略化

同一取引先・同一条件の継続委託では、基本契約＋個別4条PDFの更新頻度を四半期に固定し、EDIは明細差分のみ送る運用が多いです。
条件変更（単価改定・支払サイト変更）があった月だけPDF再交付を必須にします。

6. 取引先EDI仕様差への対応

6-1. 仕様書の必須確認項目

支払条件コードの一覧、税込/税抜の定義、取消・変更電文の有無、受注側の保存期間、再ダウンロード可否。
仕様書に無い項目は「個別4条PDF必須」とマトリクスに明記します。

6-2. テスト環境での突合

本番連携前に、サンプル発注1件について「EDI受信画面のスクリーンショット」「PDF交付メール」「台帳レコード」の三者突合を行います。
受注側担当者に「この画面で4条のどの項目が読めるか」を確認メールで残します。

7. 監査用エビデンスの残し方

EDI送信ログ（電文ID・タイムスタンプ）、PDF交付メール（Message-ID）、台帳の交付日・受領日を同一発注番号で束ねます。
「EDIのみ」「PDFのみ」の片方だけが残っている案件は、交付完了と数えないルールをKPI定義に書き込みます。
エビデンス束の命名例: PO-2026-0912_取引先略称_EDI+PDF.zip

8. 現場会話例

8-1. 購買担当

「EDIに支払条件入ってるから書面いらないでしょ」→ マトリクスの「検査・再委託」行を見せ、EDI非搭載項目はPDF必須と説明。
「毎回PDFは手間」→ 条件不変の継続取引は四半期更新＋変更月のみ再交付のルールを提示。

8-2. 取引先

「御社のEDI、うちのシステムでは支払期日が見えない」→ 仕様差として記録し、当該取引先はPDF必須チャネルに格上げ。
格上げ一覧は四半期ごとに見直し、EDI側改修で解消できればPDF必須を外します。

9. 業種別の補足（製造・小売）

9-1. 製造業（部材発注）

部品番号・ロット・納入場所はEDIに載りやすい一方、検査規格・再加工条件・治具費の帰属はPDF側が多いです。
量産開始後の単価改定はEDI明細行の更新だけでは4条の「代金の額」変更通知にならないため、改定月はPDF再交付を必須にします。
同一部品番号で複数サプライヤがある場合、発注番号とEDI取引先コードの対応表をマッピング表の別シートに置きます。

9-2. 小売・物流（委託・3PL）

保管料・ピッキング料・返品処理料などサービス要素が多く、EDIの「商品明細」モデルと合わないことがあります。
この場合はサービス契約PDFを正本とし、EDIは数量実績の通知チャネルに限定する設計が安全です。
委託範囲の変更（新倉庫追加・温度帯変更）はEDIマスタだけ更新せず、PDF条項の改定とセットで行います。

10. 移行時のEDI連携チェック

台帳SaaSへ移行する際、EDI連携フィールドと台帳カラムのマッピング表をそのまま引き継ぎます。
移行直後1ヶ月は、EDI取込件数・台帳登録件数・PDF交付件数の三者一致を日次で確認します。
不一致が続く取引先は、EDI仕様レビュー会を設定し、マトリクスの「個別4条PDF必須」欄を見直します。
連携停止中に手入力した発注は、EDI再開時に差分同期せず、台帳正本で上書きするルールを決めておきます。

よくある質問

Q. EDIとFAX発注を併用している場合は

チャネルごとに正本を決め、同一発注番号で束ねます。
FAXは画像保存と交付日が必須。EDIと金額が違う場合は差分レポート対象です。

Q. 受発注SaaSだけで足りる取引先はいますか

受注側が全4条項目をダウンロード可能で、保存期間が監査要件を満たす場合に限り、PDF省略を検討できます。
例外は取引先ごとに文書化し、一律省略は避けます。

Q. マッピング表は誰が更新しますか

購買・経理・コンプラの三者で版管理します。
EDI仕様変更の通知を受けた担当が起票し、コンプラが4条観点で承認する流れが安全です。

Q. 二重入力を完全に防げますか

技術的にはAPI一方向連携＋手修正権限の最小化で近づけます。
完全ゼロより、差分検知と放置日数のKPIの方が現実的です。

まとめ

• EDIは骨格項目を担い、検査・再委託等は個別4条PDFが必要なことが多い
• 役割分担マトリクスとフィールドマッピング表を取引先・版ごとに管理する
• デュアルライトは正本一本化と差分検知で抑える
• 交付順序はPDF→EDI→台帳紐付けが安全
• 監査はEDIログ・メール・台帳の三者束ねが前提

注意

EDI仕様と4条明示の要否は取引形態・契約内容により異なります。
トリカク（torikaku） の台帳項目例を含みますが、法的助言ではありません。個別契約と専門家確認が必要です。