メールで届く注文を受注一覧に取り込む｜品番の突合・複数明細・読めなかった注文の扱いを先に決める

取引先からの注文がメールで届き、担当者が受注システムやExcelに手で入力している会社が、その入力を取り込みに置き換えるとき、つまずくのは取り込みの手段より、その先です。取引先の品番を自社の品番に直す、1通に複数の明細がある、同じ注文が再送・修正・取消で何度も届く、読めなかった注文が出る。この4つを先に決めておくと、手段が何であっても、受注一覧が崩れにくくなります。

FAXと違って、メールは差出人・受信時刻・添付ファイル名が、機械で読める形で届きます。取引先の特定や、同じメールの二重取り込みの防止には、その項目が使えます。一方、品番の書き方や、1通の中の注文の数、注文を直して送り直すかどうかは、メールでも取引先ごとに違います。この記事では、メールで届くことで増える論点に絞って、先に決めることを順に書きます。

入口が複数あっても受注をひとつの一覧にそろえる考え方と、FAXの注文の品番対応表の作り方は、FAX受注のシステム化の記事に書きました。公式の説明を書いた部分と、当社の整理・読み取りは、文の中で区別しています。公式ページの確認日は2026年10月6日です。

メールの注文は、本文に書く・添付で来る・取引先のシステムの通知、の3通りに分ける

取り込みの作り方が変わるのは、注文の中身がメールのどこにあるかです。本文に品番と数量が書かれているなら、文章から項目を拾います。添付のExcelやPDFなら、書式ごとに、どの列、どの位置を読むかを決めます。取引先のシステムが送る通知なら、件名や本文の形がいつも同じなので、読み方を決めやすくなります。本文は挨拶と連絡だけで、注文は添付に入っている、という混ざり方もあります。

どの部分を注文の原本として扱うかは、取引先ごとに決めて、台帳に書いておきます。国税庁の一問一答は、メールで取引情報を受け取った場合について、本文に取引情報が書かれているときはそのメールを、添付ファイルで受け取ったときはその添付ファイルを、それぞれ保存する、と書いています（電子帳簿保存法一問一答（電子取引関係）問4・問6）。この考え方は、受注一覧に載せる原本を決めるときにも使えます（当社の読み取り）。取引先ごとの入口と締め時刻を台帳に書く方法は、FAX受注のシステム化の記事にあります。

メールから機械で取れる項目は、取引先の特定と、二重取り込みの防止に使う

メールには、本文のほかに、差出人、メッセージID、返信の関係、受信時刻、添付の情報が付いています。インターネットのメールの書式を定めたRFC 5322と、Gmail API、Microsoft Graphの説明から、受注の取り込みで使う項目を次の表にまとめました（RFC 5322、Gmail API、Microsoft Graph）。

項目名はメールの製品によって違います。表はGmail APIとMicrosoft Graphの例で、使っている製品の公式の説明で、同じ意味の項目を確かめます。表の「注意すること」の列のうち、台帳にないアドレスを確認待ちにする、スレッドを根拠にしない、本文に画像があるメールを確認待ちにする、の3つは当社の整理です。

品番の突合は、取引先の書き方・単位・入数を1行にして、結果を3つに分ける

取引先は、自社が付けた品番、略称、メーカーの品番、商品のJANコードなど、それぞれの書き方で品目を書いてきます。取引先の書き方を自社の品番に直す対応表の作り方は、FAX受注のシステム化の記事で書きました。ここでは、対応表の1行に何を持つかと、突き合わせた結果の扱いを書きます。

品番だけでなく単位と入数まで持つ理由は、同じ品物でも、単品とケースで商品コードが別になるからです。GS1 Japanによると、JANコード（GTIN）は「どの事業者の、どの商品か」を表す商品識別コードで（GS1事業者コード・GTIN（JANコード）とは）、ケースやボールなど企業間の取引単位の集合包装には、別にGTIN（集合包装用商品コード）を設定します。荷姿や入数が違う集合包装は、先頭のインジケータ（1〜8）で分けます（GTIN（集合包装用商品コード）とITFシンボル）。集合包装の入数を変えたときは、新しいGTINにするのが公式の基準の1つです（GTINの変更ルール）。単品と集合包装のコードが一致しない型について、公式は、発注時の単品のコードと入荷時の集合包装のコードが違う番号になるため、正確に照合できる仕組みが必要、と書いています。注文書の品番が同じでも、「個」と書かれたか「ケース」と書かれたかで、自社の品番が変わることがあります。

業界の標準にも、同じ考え方があります。家電製品協会のE-VAN（家電VAN）の受発注データは、商品コードの欄とは別に、そのコードがJANの標準タイプか、短縮タイプか、インストアコードかを示す識別区分と、メーカーの型番の欄を持っています（EDI標準化仕様 受発注データ）。コードの文字だけでなく、コードの種類も一緒に持つ作りです。メールの注文書にJANコードが書かれている取引先なら、JANコードを対応表の列に持たせて、取引先の書き方より先に引く、という使い方もあります（当社の読み取り）。

通すのを「一致」だけにすると、最初は確認待ちが多くなります。人が選んだ結果を対応表に足していくと、確認待ちが減っていきます。「見つからない」は、理由で直す場所が違うので、理由を分けて数えます。新しい書き方なら対応表に足し、廃番や終売の品物は取引先に代わりの品物を確かめ、書き間違いは取引先に確かめます。存在しない品番を、いちばん近い品番に自動で寄せることはしません（当社の整理）。

1通に複数の明細があるときは、ヘッダーと明細に分けて、明細ごとに状態を持つ

メールの注文は、1通が1注文とは限りません。1通に品目が何行も書かれていることも、納品先や納期が違う注文がまとめて書かれていることもあります。家電製品協会の標準は、受発注データを、ヘッダー（発注企業、納品場所、発注日、備考など）と、明細（商品コード、型番、数量、納品単価など）に分けています。発注番号は、伝票単位の発注ならヘッダーに、明細単位の発注なら明細に置く、と書かれています（EDI標準化仕様 受発注データ）。

取り込む側も、ヘッダーは1件、明細はN行で持つと、1行ずつ突合の結果を持てます。注文の全体で止めるか、読めた行だけ先に登録するかは、取引先の注文の出し方で決めます。

案Bを選ぶときは、注文に「一部確認待ち」の印を付けて、受注一覧で確認待ちの行が見えるようにします。印がないと、読めた行だけが出荷され、残りが忘れられます。

再送・修正・取消は別のメールで届く。同じ注文かは、注文キーで見分ける

RFC 5322は、メッセージIDを、あるメールの特定の版を示す一意の識別子と説明し、内容を直した版には新しいIDが付くと書いています（RFC 5322 3.6.4）。このため、メッセージIDは、同じメールを2回取り込まないための印には使えますが、取引先が直して送り直した修正版が、同じ注文のものかどうかは、IDでは分かりません。返信の関係やスレッドは手がかりになりますが、取引先が新しいメールで送ってくると、つながりません（当社の読み取り）。

同じ注文かどうかを決めるのは、取引先の注文番号です。注文番号が書かれていない取引先は、取引先、納品先、希望納期、明細の組が前のメールと一致したときに、重複の候補として確認待ちに入れ、取引先に確かめます。

修正と取消は、元の注文を書き換えず、版として積みます。何が変わったかを後から追えるようにするためです。出荷が済んだ後の修正と取消をどう扱うかは、取引先との取り決めで違うので、取引先ごとの台帳に書いておきます（当社の整理）。

読めなかった注文は、確認待ちの箱に入れて、見る人と時刻を決める

読めなかった理由は、差出元が台帳にない、添付が開けない、納品先や明細が欠けている、品番が一致しない、数量や単位がふだんと違う、同じ注文がすでにある、のどれかに分けられます。理由ごとに、直す場所が違います。差出元なら台帳、品番なら対応表、数量なら取引先への確認です。

箱に入れるときは、理由、原本へのリンク、受信時刻、取引先を付けます。箱は、誰が、何時までに見るかを決めておかないと、取りこぼしの置き場になります。取引先ごとの締め時刻から逆算して、見る時刻を決めます。毎日見るのは、箱の件数と、いちばん古い受信時刻です。古い注文が残っていれば、見る人か時刻が合っていません。

会計・基幹システムへは、確認済みの注文だけを、注文キーつきで渡す

受注一覧から基幹システムや会計へ渡すのは、確認済みになった注文だけにします。取込先がCSVなどの取込を使う場合は、どの列で同じ注文と見なすかを、先に決めます。たとえばkintoneのヘルプは、ファイルの取込で、更新キーに指定したフィールドの値が一致するかどうかで、登録済みのレコードを更新するか、新しいレコードを登録するかが決まる、と説明しています。レコード番号以外をキーにするときは、そのフィールドで値の重複を禁止する設定が要ります。文字コードと区切り文字は取込のときに指定し、プレビューで内容を確かめます（ファイルからレコードのデータをアプリに読み込む）。

修正と取消は、新規の注文としてでなく、同じキーの更新として渡します。キーの列、文字コード、1回に取り込める件数は、取込先ごとに違うので、取込先の説明で確かめます。会計へは、受注の時点でなく、出荷や請求の段階で渡す形が、FAX受注のシステム化の記事の状態の流れ（受付・確認・引当・出荷・請求）と合います（当社の整理）。

履歴は、原本・読み取った値・人が直した箇所の3つを残す

国税庁の一問一答（令和8年7月）は、電子メールで取引情報を受け取る取引を電子取引とし、本文に取引情報が書かれているメールはそのメールを、添付ファイルで受け取ったものは添付ファイルを保存する、と説明しています。取引情報のないメールは保存する必要がない、とも書かれています（問4・問6）。受領した側で訂正や削除ができるデータは、タイムスタンプの付与か事務処理規程に沿った管理が要り、検索できる状態で保存する必要があり、メールソフトで見られるだけでは足りない、とされています（問5）。受注一覧に打ち込んだ値だけでなく、原本をそのまま持つ理由の1つです。

原本の保存は、税の保存の話であると同時に、取引先と注文の内容が食い違ったときに、何が届いたかを示す根拠にもなります。読み取った値と、人が直した箇所を残すと、直しの多い項目が分かり、対応表と取り出しのルールの直しにつながります。税の取り扱いは、税理士や税務署に確かめてください。電子帳簿保存法の電子取引の扱いの全体は、FAX受注のシステム化の記事でも触れています。

試す順番：取引先と型を絞って動かし、確認待ちの理由を数える

4つの決めごとは、すべての取引先、すべての型を対象に決めようとすると決まりません。メールの注文が多い取引先を1社、型を1つ選んで動かし、人の入力と並べて、違う項目を数えます。

手順3の、確認待ちの理由の集計が、いちばん役に立ちます。理由が品番に偏っていれば対応表を、数量に偏っていれば取引先ごとのふだんの範囲を、見直します。件数が減り、一致が続いた取引先から、自動で進める範囲を広げます。

メールで届く注文の取り込みを、品番の突合や確認待ちの置き場まで含めて決めたいときは、Aurant Technologies の受発注・在庫管理システムのページで相談を受けています。取引先ごとの違いを先に数える方法は、受発注システムの開発費用の記事にまとめています。