EC-CUBEの受注CSVメール自動送信｜送信タイミング・宛先・再送の設計ポイント

この記事でわかること
EC-CUBEの受注をきっかけに、注文情報をCSVでメール送信するカスタマイズ事例を紹介します。注文ごとの送信と日次の一括送信の違い、送信タイミング、CSVの形式、宛先管理、失敗時の再送まで、導入前に整理したい点を解説します。

受注CSVの自動送信では、「誰が、どの状態の注文を受け取り、何の作業を始めるか」を先に決めます。メールを送るところだけでなく、受信側での確認や取り込みまで含めて設計すると、処理の漏れや重複を防ぐ運用につなげられます。

注文ごとにCSVをメール送信したカスタマイズ事例

サンクユーでは、「注文が入るたびに、その注文情報をメールで受け取りたい」というご相談に対応し、EC-CUBEをカスタマイズしました。運用上、注文ごとの送信が必要だったため、仕様を確認したうえで実装しています。

注文情報の受け渡しには、日次バッチで1日分をまとめ、メールやSFTPで送る方法もあります。今回の事例では、まとめて送る方式ではなく、注文ごとのメール送信を採用しました。

暗号化ZIPは、個人情報を含むCSVを扱うために当時採用した方法です。以下では、同様の仕組みを現在の環境に導入・改修する際の設計と運用を説明します。

受注時・入金後など、CSVを送るタイミングを決める

受信側が作業を始められる状態を基準にする

「注文が入ったら送る」という要件でも、注文内容が確定した時点、入金を確認した時点、出荷情報が確定した時点では、受信側ができる作業が異なります。次の表は、送信条件を検討するための例です。

たとえば銀行振込では、注文の確定と入金の確認に時間差が生じます。受信したCSVをそのまま出荷指示に使うなら、未入金の注文を渡してよいかを決めておく必要があります。掛け払いの場合も、注文の受け付けと社内承認を分けているかを確認します。

また、受注データの確定・保存を確認してから送信対象にすること、メール処理の遅延や失敗が購入手続きに与える影響を整理します。受注処理と送信処理を分ける構成では、未送信の対象を残し、処理が止まっていないか確認する方法も用意します。

送信後の注文変更・キャンセルを取り決める

初回のCSVを送った後に、数量・配送先・注文状態が変わることがあります。最初のデータだけで作業が進むと、変更前の内容で手配してしまうおそれがあります。

変更分だけを送るのか、注文全体を訂正版として送り直すのか、キャンセルをどの形式で知らせるのかを決めます。すでに出荷などの作業が進んでいる場合は、データの再送だけで済ませず、担当者間で確認する条件も必要です。

受け取り先で使えるCSV項目・形式を揃える

CSVを人が確認する場合と、販売管理・倉庫などのシステムに取り込む場合では、必要な形式が異なります。取り込み先の仕様を先に確認し、実際のサンプルで結果を確かめます。

• 注文・注文明細・配送のどれを1行とするか
• 注文ID、明細ID、配送を識別するIDなど、対応関係を確認する項目
• 商品コード、数量、単価、送料、値引き、税の扱い
• 列の並び、見出しの有無、文字コード、改行、日付の形式
• 取引先コードや注文書番号など、BtoB業務で必要な独自項目

複数商品を含む注文では、「メールは注文ごと、CSVの行は明細ごと」という構成も考えられます。注文合計を各明細行に出す場合は、受信側で合計を重複加算しないようにします。商品コードの先頭ゼロや、項目内のカンマ・改行が正しく扱えることも確認します。

EC-CUBEの公式「CSV出力項目設定」では、出力項目と並び順を設定する機能が説明されています。ただし、自動送信用のCSVにその設定を使うか、別の形式を用意するかは実装によります。項目の設定と、自動出力・添付・送信を行う仕組みを分けて確認します。

参照：EC-CUBE公式マニュアル「CSV出力項目設定」（確認したページは4.3.1-p1版）

宛先と、個人情報を含むCSVの受け渡し方法を決める

送る情報を絞り、宛先の変更も管理する

受信側の作業に必要な情報だけを送るよう、CSVの項目を整理します。注文情報を扱うからといって、氏名・住所・電話番号などをすべての宛先に送る必要があるとは限りません。

宛先は担当部署と確認し、誰が追加・変更できるか、変更後のテストを誰が行うかを決めます。取引先や担当者の変更時には、古い宛先への送信停止も確認します。複数の取引先へ振り分ける場合は、別の取引先の注文が混ざらないことを検証します。

受信したメールや保存したCSVの閲覧範囲、転送、保存期間、削除担当者も整理します。送信元の一時ファイルや作業用コピーについても、不要になった後の削除方法を決めます。

暗号化ZIPを含め、受信側が扱える方法を選ぶ

掲載事例では暗号化ZIPを採用しましたが、暗号化ZIPにするだけで、誤送信や受信後の転送・保管まで防げるわけではありません。採用する暗号化方式、パスワードの共有方法、受信側の添付ファイル制限を確認します。

GoogleのGmailヘルプでも、一部の暗号化された添付ファイルはウイルススキャンできないことが説明されています。添付ファイルを受け取れるか、解凍できるか、社内の運用ルールに合うかを、実際の受信環境で確認することが大切です。

参照：Gmailヘルプ「添付ファイルの表示とダウンロード」

担当者が必要なときに取得するなら、認証とアクセス権限を設けたダウンロード方式も候補です。メールには通知を送り、CSVの取得は許可された担当者に限定する構成を検討します。URLを知っているだけで誰でも取得できる状態にしないこと、取得期限や操作記録をどう扱うかも決めます。

システムが継続的に受け取る用途では、SFTPによるファイル転送やAPI連携も候補になります。いずれの方式も、受信側の対応、認証情報の管理、失敗時の確認方法を含めて選びます。

送信失敗・再送・二重処理に備える

「送信済み」と受信・処理の完了を区別する

システム上で送信処理が終わっても、担当者がCSVを確認したことや、取り込み先で処理が完了したことまでは分かりません。どの段階を「送信済み」「処理済み」と呼ぶかを決め、それぞれの確認方法を整理します。

送信対象の注文、データの作成日時、宛先、送信結果、エラー内容を確認できる記録を検討します。必要以上の個人情報やパスワードを記録に残さず、閲覧権限と保存期間も決めます。

受信側で人が確認するなら担当者と対応期限を、システムへ取り込むなら処理結果や取り込み件数の照合方法を決めます。失敗した処理だけでなく、予定された送信自体が始まっていない状態を見つけられることも必要です。

同じ内容の再送と、訂正版の送信を分ける

送信の途中でエラーになった場合でも、受信側には届いていることがあります。そのまま送り直して取り込むと、同じ注文を二重に処理する原因になります。

注文IDに加え、連携データの識別子や版番号などを使い、同じデータの再送なのか、注文内容を変更した訂正版なのかを受信側で判別できるようにします。同じデータの再送では識別子を維持し、訂正版は新しい版として扱うなど、双方のルールを揃えます。

再送時にCSVを作り直すと、その間の注文変更が反映され、最初に送った内容と変わる場合があります。元のファイルを再送するのか、最新の注文を訂正版として送るのかを明確にします。受信側の処理済み情報と照合し、古い版で新しい情報を上書きしないことも確認します。

自動再送を行う場合は、再送の上限と間隔、停止する条件、対応担当者への通知を決めます。宛先の誤りなど、同じ条件で繰り返しても解消しないエラーについては、修正してから再開する運用にします。

受注CSVメール自動送信の相談前に整理したいこと

ご相談の際は、現在のCSVサンプルと、受信後にどのような作業を行っているかが分かる資料があると、必要な対応を整理しやすくなります。

• EC-CUBEのバージョン、決済方法、既存プラグイン・独自改修
• 送信する目的、宛先、受信後の担当者や取り込み先
• 送信するタイミング、対象条件、注文変更・キャンセルの扱い
• CSVの項目・形式、サンプル、想定する注文数と送信件数
• 添付ファイルの制限、認証・権限、保存・削除のルール
• 送信結果の確認方法、失敗時の担当者、再送・重複処理への対応

サンクユーでは、EC-CUBE構築・カスタマイズやBtoB-EC構築のご相談に対応しています。メール送信に必要な処理と、受信側の業務を確認し、既存環境に合わせた対応範囲を整理します。

受注CSVのメール自動送信に関するよくある質問