- 受発注で確認したい例外の種類
- 例外一覧に必要な6項目
- システム設定と運用ルールの切り分け
- ベンダーへ同じ条件で確認する方法
通常フローだけでは要件が決まらない
EDIは企業間で取引情報を電子的に交換する仕組みです。ただし、どの取引プロセスや情報項目を扱うかは製品・連携範囲によって異なります。「注文を受けられる」だけでなく、変更、回答、出荷、検収、請求など、自社が必要とするプロセスと例外を確認する必要があります。
頻度が低く判断が複雑な例外は人の運用に残し、どこから誰が引き取るかを決める方が現実的な場合もあります。
洗い出したい例外の例
| 分類 | 例 | 確認すること |
|---|---|---|
| 商品 | 廃番、代替品、登録外品、単位違い | 代替可否と判断者 |
| 価格 | 契約単価差、キャンペーン、送料条件 | 正しい価格の参照元 |
| 数量・在庫 | 欠品、分納、最低ロット、端数 | 回答期限と顧客連絡 |
| 納期 | 締切後、指定日不可、緊急出荷 | 承認者と追加費用 |
| 変更 | 数量変更、届け先変更、取消 | 変更可能な締切時点 |
| 取引先 | 新規、与信保留、部門別請求 | 登録完了までの仮処理 |
| データ | 必須項目欠落、コード不一致、重複送信 | エラー通知と再処理 |
例外一覧を作る4ステップ
現場の差し戻し記録から集める
記憶だけでなく、訂正メール、付箋、保留一覧、問い合わせ履歴など、例外が残っている場所を確認します。顧客名や個人情報は共有用資料から外します。
発生時点と検知者を書く
受信時、入力時、在庫引当時、出荷時、請求時のどこで見つかるかを記録します。早く検知できる条件も併記します。
頻度と影響を分けて評価する
毎日発生する軽微な例外と、年数回でも誤出荷につながる例外を区別します。件数、追加時間、顧客影響を別列にします。
対応先を3つに分ける
「システム設定で処理」「人が判断してシステムへ戻す」「対象外として別運用」のどれかを仮置きし、候補製品へ確認します。
最小の記入例
| 例外 | 頻度 | 検知時点 | 判断者 | 顧客影響 | 対応仮説 |
|---|---|---|---|---|---|
| 旧品番で注文 | 週3件 | 受注入力 | 商品担当 | 回答待ち | 変換表＋要確認 |
| 欠品・分納 | 日5件 | 在庫引当 | 受注責任者 | 納期変更 | 在庫連携＋承認 |
| 締切後変更 | 月2件 | 出荷準備 | 倉庫責任者 | 誤出荷リスク | 別運用・記録必須 |
表の件数は説明用の仮想例です。自社の記録で置き換えてください。対応仮説は決定事項ではありません。同じ一覧を候補ベンダーへ渡し、標準機能、設定、追加開発、対象外のどれに当たるかを回答してもらうと比較しやすくなります。
見落としを減らす確認質問
- 注文変更はどの時点まで元データとひも付けられるか
- エラー時に誰へ、どの情報が通知されるか
- 同じ注文を再送したとき重複を検知できるか
- 一部欠品や分納時に元注文との関係を残せるか
- 人が修正した履歴と理由を確認できるか
- 連携停止時の代替手順と復旧後の再処理はどうするか
よくある質問
例外は何件まで集めればよいですか
件数の上限より、日常的な高頻度例外と、低頻度でも顧客・出荷・請求への影響が大きい例外を含めることを優先します。類似例外は判断ルールが同じならまとめます。
現行運用の例外をそのまま再現すべきですか
再現前に、その例外が取引条件上必要か、古い慣習かを確認します。不要な手順をそのままシステム化すると複雑さが残ります。
関連する実務記事
参考情報
- 中小企業庁「中小企業の受発注デジタル化」（2026-07-13確認）
- ITコーディネータ協会「中小企業共通EDI認証制度について」（2026-07-13確認）
編集方針：特定製品を推奨せず、導入前に例外を比較可能な形へ整理する一般的な手順として作成しています。機能範囲は製品・契約・連携方式により異なるため、提供事業者へ確認してください。最終更新日：2026.07.13
更新日：2026.07.22
編集方針：公開情報とミチタスの実務知見をもとに、事実・仮定・説明例を区別して作成しています。特定製品の推奨、導入効果、投資回収、法令適合を保証しません。固有の顧客情報・社内情報・機密情報は使用していません。