AS400 / IBM i の出荷業務では、「出荷データが取引先に届いていない」「同じデータを二重送信したかもしれない」「再送してよいか分からない」という相談があります。出荷確定、ファイル作成、FTP送信、取引先取込を分けて確認します。
出荷連携で見る順番
| 確認 | 見るもの | 判断 |
|---|---|---|
| 出荷確定 | 確定日時、取消、再確定 | 元データが作られたか |
| ファイル作成 | IFS、CSV、固定長、更新時刻 | 送信前ファイルがあるか |
| 送信 | FTPログ、EDIログ、リターンコード | 外部へ送れたか |
| 取込 | 取引先側結果、外部システムログ | 受信後に失敗していないか |
| 再送 | 送信済み管理、承認、影響範囲 | 二重送信にならないか |
二重送信・未送信を分ける判断表
出荷データは、相手先に渡った瞬間に現物の出荷、納品、請求、在庫へつながります。AS400側で「送ったかどうか」だけを見るのではなく、相手先が受け取ったか、取り込んだか、業務担当が出荷を進めてよい状態かを分けて確認します。
| 状態 | 見るもの | 判断 |
|---|---|---|
| 未送信 | 出荷確定、送信対象抽出、送信ジョブ | 送信処理を再実行できるか確認 |
| 送信済み・相手先未受信 | FTP/EDIログ、通信エラー、相手先受信ログ | 再送候補。ただし対象範囲を絞る |
| 相手先受信済み・未取込 | 相手先取込ログ、エラー戻り、件数 | 相手先側の再取込か、自社再送かを相談 |
| 相手先取込済み | 伝票番号、件数、取込時刻 | 原則再送しない。訂正や取消手順を確認 |
| 二重送信疑い | 同一伝票、同一ファイル名、送信時刻 | 現物出荷や請求へ進んでいないか確認 |
再送前に残す確認メモ
- 取引先、出荷日、伝票番号、ファイル名、件数
- 出荷確定の状態、取消や再確定の有無
- AS400側の送信ログ、FTPログ、ジョブログ
- 相手先の受信有無、取込結果、エラー内容
- 再送可否を判断した担当者と承認者
- 再送後に確認する在庫、出荷、請求への影響
同じ出荷番号が二度送られた想定例
取引先から重複受信の連絡があった場合、AS400の送信状態だけでなく、ファイル作成、転送、相手側取込の識別キーを追います。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 元データ | 出荷番号、送信管理番号、状態、更新時刻を確認する | 同じ業務データと再作成データを分ける |
| 送信経路 | 作成ファイル、転送ログ、再送操作、応答を時系列で確認する | 通信再試行と業務再送を混同しない |
| 相手側 | 受領回数、取込結果、重複排除キー、訂正方法を確認する | 確認前に三度目の送信を行わない |
未送信の疑いでも同じ確認順を使い、相手側の受領状態を確認してから再送します。対応後は送信管理と業務伝票の状態をそろえ、原因となった再実行手順を見直します。
再送後に完了とする条件
EDI再送は、ファイルをもう一度送った時点では完了ではありません。相手先の受信、取込、業務処理への反映まで確認してから完了扱いにします。
| 確認 | 見ること | 完了にしない状態 |
|---|---|---|
| 相手先受信 | 受信時刻、件数、ファイル名 | 相手先が未確認 |
| 取込結果 | 正常取込、エラーリスト、リターンコード | 受信済みだが取込失敗 |
| 業務影響 | 出荷、請求、納品、締め | 二重処理や未処理が残る |
| 証跡 | 連絡内容、再送理由、承認者 | なぜ再送したか説明できない |
本番送信前のチェック
| 確認 | 見ること | 事故例 |
|---|---|---|
| 環境 | 本番かテストか、ライブラリ、接続先 | テスト環境のつもりで本番送信する |
| 送信先 | 取引先コード、送信先ID、通信定義 | 別の相手先へ送る |
| データ | テストデータ、実データ、対象日付 | テスト注文や架空出荷を送る |
| ファイル名 | 送信ファイル、IFS、保存先、世代 | 古いファイルを再送する |
| 再送 | 二重送信防止、再送条件、履歴 | 同じデータを重複送信する |
| 業務影響 | 出荷、在庫、請求、相手側取込 | 物が届かない、請求がずれる |
業務理解がないとEDIは扱えない
EDIは通信だけの問題ではありません。出荷、在庫、請求、相手先業務とつながっています。業務が理解できないまま送信や再送を行うと、技術的には成功していても、業務上は事故になることがあります。
業務確認は AS400業務ヒアリングシート、クラウド/API連携前の確認は AS400連携とは｜IBMiをWebAPI・外部システムにつなぐ考え方も確認してください。
Codexでできること
EDI関連のCLやRPGは、長年の運用で複雑になりがちです。CodexやAIは、送信前チェック、処理概要、ファイルの流れ、再送条件、テスト観点を整理する下書きに使えます。利用するAIサービスへの提供が契約・社内ルールで許可されているかを先に確認し、許可範囲内でも取引先名、実データ、接続情報を除いてください。
テストデータを本番送信した疑いがある時に最初に見ること
若手や外部メンバーで起きやすい失敗の一つが、EDIのテストデータを本番側へ送ってしまうことです。疑いが出た時は、すぐ再送や削除に進まず、送信先、送信時刻、送信ジョブ、対象データ、相手先の受信状態を分けて確認します。EDIは相手先が絡むため、技術的な成功だけで判断しないことが大切です。
- 送信先が本番取引先か、テスト先かを確認する
- 対象データのキー、件数、送信日時、ファイル名を残す
- ジョブログで送信ジョブの終了状態とMSGW（メッセージ待ち）有無を見る
- 相手先へ連絡する前に、事実と推測を分ける
- 本番DBを修正する場合は、更新前データと承認を残す