営業が受注ソフトへ入れた注文番号・商品・数量・希望日を、出荷担当が別の一覧へ打ち直しています。この転記を、最初につなぐ範囲にします。

架空の注文はO017・明細1、商品A、7個、希望出荷日2026-10-12です。連携では確認済みの情報を出荷一覧の入力案へ渡し、出荷担当が元の注文と照合します。

入力案が届いても、出荷できるとは限りません。在庫・届け先・出荷の承認は今の確認を残します。未確定の見積、請求・会計、自動出荷は今回の対象外です。

項目の対応表は、元の欄と移す先の欄を結びつける表です。マッピング表とも呼びます。同じ「数量」でも、個数とケース数をそのまま移すことはできません。

この例では商品A、個数、倉庫から出す希望日を両側でそろえます。希望出荷日は配達日でも確定日でもありません。O017と明細1を組み合わせたO017-1を残し、元の注文行へ戻れるようにします。

先頭の0が必要な番号は文字として残します。日付形式、文字の読み込み方、必須項目と空欄、単位の変換が必要かを提供会社へ確認します。意味が合わない値は、取り込まず元の担当へ確認してください。

まず、今のソフトに標準の連携機能があるかを提供会社へ聞きます。対象製品・契約・必要な項目・変更の反映が合うかも確認します。連携機能がある前提では進めません。

CSVは表を文字で保存するファイル、APIはソフト同士で情報を渡す窓口です。朝のまとめで間に合えばCSVの案、早く変更を知らせる必要があれば標準連携やAPIの反映時点を確かめます。

画面操作の自動化は、クリックや入力を決めた手順で繰り返す方法です。RPAとも呼び、AIに意味や判断を任せることとは異なります。必要な窓口がない場合も、権限・画面変更・停止時の扱いを確認して比較します。

APIがあっても自動連携が完成するわけではありません。両側の操作・権限・件数制限と接続設計が必要です。標準連携の内部でAPIを使う場合もあり、4方式は完全な別物ではありません。

費用は設定・接続の開発・利用料・毎回の結果確認・変更時の保守に分けます。現場の確認時間も含め、同じ項目と反映時点で見積を求めます。方式名だけで安さや速さは決まりません。

応答がなくても、情報は出荷側へ届いている場合があります。O017-1の登録状態と送った内容を照合し、未登録・登録済み・差異・不明を分けます。番号を付けるだけでは重複は防げません。

同じ番号・同じ内容が登録済みなら行を足しません。数量などが変わったら、出荷準備の状態を担当者が確認し、変更方法を決めます。出荷済みの行を自動で上書きしない扱いも必要です。

不明なO017-1は、再送も新規手入力も保留します。両側の記録を照合し、未登録を確認したら同じ番号で1度登録、登録済みなら追加せず照合します。新しい番号で作り直しません。

注文行・送った内容の版・送信時点・結果・受け側の行番号を記録します。無関係な注文は状態を別に確認し、通常手順を続けられるか担当者が判断します。

空欄や権限不足は原因を先に直します。自動再送には間隔・回数上限・確認担当を決め、応答だけで未登録と判断しません。同じ再送で結果を増やさない設計は、冪等性とも呼ばれます。

実際の出荷や顧客連絡につながらない別の試行先を、担当者と提供会社で用意します。資料を使う権限も確かめ、次の動きを完成条件の案として合意します。

正常なO017-1は商品A・7個・希望出荷日が同じ意味で入り、元の注文行をたどれること。商品番号を空欄にした試験では登録せず理由を残すこと。同じ情報を2度渡した試験では1行のままであることを確かめます。

これらは架空の試験条件で、特定製品の標準機能や検証済みの結果ではありません。合わなければ切り替えず、現在の手順を続けて設定や設計を直します。

切り替える期間・注文範囲・日付・停止担当と、手入力と取り込みの境目を決めます。運用中の登録状態が不明な注文を、手入力で作り直す意味ではありません。確認・修正・保守の負担も記録します。