旧F61は注文番号、商品番号、数量、希望日の4列です。新F62は数量の後ろに配送区分を加えた5列です。連携担当は両方の見出しと代表行を変更票へ並べます。

ファイル名が同じ受注.csvでも、列の形が同じとは限りません。新ファイルを旧ファイルへ上書きせず、受領日時と送付元の連絡を関連付けて比較できる状態にします。

新列の値が通常と至急であっても、自社の受付で何を変えるのかは未確認です。見た目から優先順位や送料を決めず、意味と適用開始日を確認事項として残します。

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

位置で4列目を希望日として読む処理なら、新F62では配送区分を日付欄へ入れてしまいます。列が増えただけとして続行せず、現在の読込方法を連携担当へ確認します。

列名で希望日を選ぶ処理でも安心とは限りません。名前の重複、変更、新しい必須欄、未対応の列を扱う条件があるため、追加欄を無視できるかを仕様と試験で判断します。

受付の取込処理が正常でも、後続の配送表が位置で読む場合があります。ファイルを使う処理の一覧を作り、画面、集計、出力、外部連携まで影響先をたどります。

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

新F62の取込みを保留し、受領資料は失わないよう管理します。旧形式F61の確認済み処理まで止める必要があるかは、混在と影響の有無を見て責任者が決めます。

すでにF62を取り込んだ受注O201で希望日が通常になっていれば、配送表や顧客への回答へ伝わったかを調べます。今後の取込停止だけでは、登録済みの値を直したことにはなりません。

受付が止まる間に手入力するなら、どの注文を手で登録したかを残します。再開後に同じ受領分をまとめて取り込んで二重登録しないよう、対象と照合先を決めます。

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

連絡票にはF61とF62の見出し、追加列の位置、受領日時、自社が希望日を読めなくなった結果を示します。単にCSVが壊れたと伝えず、相手が仕様変更か生成ミスかを調べられる材料にします。

配送区分の許す値、空欄時の扱い、適用開始日、旧形式を使える期間を確認します。新列が必須なら、値を埋める担当と不足時の差戻しも合意します。

送付元が旧形式を再送する場合は、同じ注文の修正版か別の追加注文かを確認します。形式を戻すだけで内容まで同じと見なさず、注文番号と数量の照合を付けます。

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

送付元と新形式V02を合意したら、通常と至急、配送区分空欄、希望日未記載の代表行を試験します。空欄を採用できるかは合意した条件で判定し、取込結果に合わせて規則を変えません。

受付の画面だけでなく配送表の希望日も確認します。旧形式の受領が続くなら、V01を受けるか保留するかも試し、混在時の取込先を決めます。

再開対象には形式版、受領ファイル、判定日時を残します。保留中の手入力注文と取り込む注文を照合し、対応済みと未処理を分けてから受領分を流します。

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

まず旧新の見出しと代表行を保存し、追加位置と意味の変更を示します。列数が増えた事実と、希望日や配送判断が変わる影響を分けて考えます。

次に新形式の未取込分を保留し、登録済みや手入力の受注を追います。送付元には許す値、適用日、旧版終了、再送の意味を具体的に確認します。

最後に新旧と失敗例を試し、受付から配送表まで照合します。形式版、再開対象、未処理の受領分を記入メモへ残し、担当者が再開の根拠を説明できるようにします。

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