F51には注文番号、商品番号、数量、希望日、備考の5列があります。希望日は顧客が望む日であり、自社が回答した納品日ではありません。名称の似た受注表の納品日へそのまま写しません。

商品00128は識別する文字、数量10は個数として数える値と決めます。数量の単位が個か箱か未合意なら、数字が読めても試験条件ができていません。送付元へ確認する欄として残します。

空欄の備考は記載なし、空欄の数量は受注を決められない不足とする架空の受付規則です。同じ空欄でも列ごとに結果が違うため、受付担当が実務上の判断を定義します。

この章の根拠：出典1出典3

RFC4180は欄の区切りや引用符を説明しますが、商品番号を文字として読むかは受取側の条件も必要です。F51について区切り、見出し行、文字コード、改行、日付表記を送付元と合意します。

日付2026-10-15を10月15日と読む期待値を明記します。10/11のように月と日の順序が曖昧な例は受け付け方を別に決め、道具の自動判定だけで採用しません。

JSONは、データを項目名と値などで表して受け渡す形式です。CSVをJSONへ変換する中間処理があれば、商品番号を文字列として渡す条件も照合します。ファイル単体の試験だけでなく、実際に経由する形式と保存先を試験対象へ含めます。

この章の根拠：出典1出典2出典3

F51の通常行T51は商品00128、数量10個、希望日10月15日です。原文と期待する受注表の値を先に書き、試験後の結果に合わせて正解を変更しません。

不足行T52は数量空欄、特殊行T53は備考にカンマと改行を含めます。T52は保留、T53は備考が1欄に保たれることを期待します。どちらも正常行の代用品にはなりません。

実顧客の注文へ登録せず、確認用の資料と取込先を連携担当が用意します。試験先が本番と同じ通知や出荷へつながるなら、実行前に切り離せるかを担当者へ確認します。

比較表は横に動かして全ての列を確認できます。

この章の根拠：出典1出典3

T51の商品番号が128になった場合、元ファイルの00128、取込直後の値、受注表の値を順に比べます。最初から番号が欠けて届いた場合と、自社の変換で消えた場合では修正担当が違います。

取込直後は00128で受注表だけ128なら、保存欄や後続の変換を調べます。最終画面の見た目だけを直して試験を閉じず、再出力した番号も確認します。

T53の注文数が増えたなら、備考中の改行をレコードの区切りに扱った箇所を調べます。不具合の段階、修正先、再試験する行を記し、曖昧な原因のまま取込を続けません。

この章の根拠：出典1出典2出典3

取込担当は列数、文字、日付表記、改行の読込結果を報告します。受付責任者は商品・数量・希望日が業務上の意味を保つかを判定します。両方が確認できてから対象の受領ファイルを登録します。

通常行だけ通り、不足行が勝手に0個で登録されたなら開始を保留します。対象のファイル全体を止めるか、不足行を隔離して残りを扱えるかは受付規則と取込機能の両方で決めます。

合格記録にはF51の形式版、試験日時、利用した道具、判定者を残します。次回のファイルで列や文字コードが変わったら、その記録を根拠に同じ条件と判断せず再確認します。

この章の根拠：出典1出典3

まず受付責任者が、商品番号は文字、数量は個数、希望日は顧客の希望だと定義します。取込担当は列数、文字コード、改行、日付表記を合意し、曖昧な欄を残したまま登録しません。

通常・不足・特殊文字の試験行に期待値を置き、原ファイルから受注表まで照合します。誤りが起きた段階を特定することで、送付元への差戻しか自社側の変換修正かを判断できます。

最後に、形式と業務の判定者が開始対象と保留条件を確認します。記入メモには形式版、試験結果、未確認事項を残し、次回の変更時も同じ条件かを追えるようにします。

この章の根拠：出典1出典2出典3