この記事でわかること
EC-CUBEへ代引きの入金データを取り込み、注文との照合や確認作業を支援する設計ポイントを解説します。代金回収と店舗口座への入金の違い、手数料を含む金額確認、ステータス更新、二重取り込みとメールの重複送信を防ぐ方法を整理します。
代引きの入金データ取込では、どの注文・配送について、どの段階まで確認できたのかを明確にすることが大切です。CSVの取り込みに合わせて注文ステータスを一律に変えるのではなく、照合結果と実際の出荷・入金状況に応じた処理を設計します。
代金回収・振込予定・店舗口座への入金を区別する
代金引換では、お客様が商品を受け取る際に配送会社などへ代金を支払い、その後、契約に応じた精算を経て店舗へ送金されます。「お客様から回収できたこと」と「店舗の口座に入金されたこと」は、確認する段階が異なります。
入金データを使う目的が、代金回収の確認なのか、店舗への振込の確認なのかで、必要な項目と更新する情報が変わります。まずは、取得するデータが何を示しているかを確認します。
| 確認する段階 | 主な確認内容 |
|---|---|
| お客様からの代金回収 | 対象の荷物について回収が完了しているか、回収金額・回収日を確認できるか |
| 精算・振込予定 | 対象期間、精算対象の明細、手数料や調整額、振込予定日・予定額は何か |
| 店舗口座への入金 | 口座の入金明細と精算データが対応し、日付・金額を確認できているか |
ヤマト運輸の「売上・入金管理ツール」では、精算情報のCSVダウンロードが案内されています。SGシステムの「e-コレクト®照会」でも、代金回収状況の確認と振込データのCSVダウンロードが案内されています。取得できる項目や対象期間、提供時点は、利用サービスと契約内容を確認します。
振込予定のデータを取得しただけで、店舗口座への入金確認まで完了したとは判断しません。回収日、振込予定日、実際の口座入金日、EC-CUBEへの取込日時を分け、どの日付を何に使うかを決めます。
参照：ヤマト運輸「売上・入金管理ツール」／SGシステム「e-コレクト®照会」
送り状番号と注文・配送を対応づける
配送会社側の明細が、EC-CUBEの注文番号を持っているとは限りません。送り状番号、依頼主側の管理番号、配送会社や契約の識別情報など、実際に取得できる項目から照合方法を決めます。
EC-CUBE側にも、照合に使う番号を正しく登録しておく必要があります。送り状の発行・再発行に合わせた番号の戻し方は、送り状CSV連携の項目変換・取込確認・再発行の設計もあわせて確認してください。
識別番号の表記と、複数配送の扱いを揃える
番号の先頭ゼロ、ハイフン、空白などをどう扱うかを定めます。表計算ソフトで開いて保存したことで番号が変わらないよう、識別番号は文字列として扱います。異なる番号が同じ値になってしまう加工は避けます。
1件の注文に複数の配送がある場合や、送り状を再発行した場合は、注文と送り状が単純な1対1にはならないことがあります。どの配送でいくら回収する運用なのかを確認し、1明細の照合だけで注文全体の精算を完了させない条件を決めます。
入金データに注文番号がない場合も、氏名や金額だけで決め打ちせず、対象を一意に特定できる情報を組み合わせます。配送会社や契約が異なるデータを扱う場合は、それらの識別情報も含めて照合します。
一致しない明細を、確認対象として残す
該当する注文がない、候補が複数ある、支払方法が代引きではない、取消・返品になっているといった明細は、自動更新を止めて確認できるようにします。取り込めなかった行を、画面から消すだけで終わらせないことが重要です。
確認画面には、元データの識別番号、候補の注文、金額、処理できない理由を表示する方法を検討します。担当者が手動で対応づける場合も、変更理由と操作した人を記録します。
また、CSVに載っている明細だけを処理しても、未回収・未精算の注文がすべて見つかるとは限りません。サービス側の反映時期を考慮しながら、出荷済みの代引き注文と処理履歴を比較し、まだ対応する明細がない対象を確認する運用も必要です。
代引金額・手数料・振込額を同じ意味で比較しない
EC-CUBEの支払合計、配送会社が回収する金額、店舗口座へ振り込まれる金額は、用途と集計単位が異なります。金額の列を取り込む前に、それぞれが何を表すかを整理します。
| 金額・情報 | 照合時に確認すること |
|---|---|
| 注文の支払合計 | 値引き、ポイント利用、送料、お客様へ請求する手数料を含めた請求内容 |
| 配送ごとの代引金額 | 実際に回収する対象と金額。複数配送で注文総額を重複して扱っていないか |
| 配送会社などの手数料 | 契約上の請求・控除方法と対象期間。注文時にお客様へ請求した手数料との区別 |
| 取消・返品・調整額 | 対象取引、調整理由、元の明細との関係、今回の精算に含まれるか |
| 精算単位の振込額 | 複数注文をまとめた金額か、どの明細・手数料・調整を含むか |
| 口座の入金明細 | 精算データとの対応、実際の入金日と金額、確認担当者 |
注文ごとの照合と、まとめて振り込まれる金額の照合を分ける
複数注文の代金がまとめて振り込まれる場合は、個別の回収明細と精算全体を分けて確認します。振込単位の手数料や調整額がある場合、それを各注文の不足額として扱わないようにします。
手数料の差し引き方は契約やデータの仕様によって異なるため、「回収額から一定額を引けば一致する」と一律に決めません。明細の合計と精算書・振込額がどう対応するかを確認します。
差額に理由がある場合も、その根拠を残します。説明できない差額を自動で丸めたり、注文金額を書き換えて合わせたりせず、確認対象とします。EC-CUBE内の確認結果を会計・基幹システムへ渡す場合は、最終的な入金管理をどこで行うかも決めておきます。
発送状況を保ちながら、入金確認の結果を記録する
EC-CUBE4には受注検索や対応状況の一括変更があります。ただし、それらは配送会社ごとの入金CSVを読み込み、注文と照合して消し込む処理とは別です。利用バージョン、導入済みプラグイン、既存改修を確認し、追加する機能を整理します。
ここでいう消し込みは、明細と対象の注文・配送を対応づけ、決めた確認が済んだことを記録する処理です。CSVの読み込みが成功したことと、金額や入金の確認が終わったことを区別します。
発送済みの注文を一律に「入金済み」へ変更しない
代引きでは、商品を発送した後に回収・精算を確認します。EC-CUBE4の公式開発ドキュメントが示す標準のステータス遷移では、「新規受付」から「入金済み」への経路はありますが、「発送済み」から「入金済み」への経路はありません。
発送済みであることを保ちながら、代引きの回収・精算状況を管理する設計が必要です。追加項目や専用の管理画面・履歴などを使う方法を、利用環境に合わせて検討します。必要な情報が既存機能で管理できる場合は、その運用との整合も確認します。
ステータスを拡張する場合は、名称を追加するだけでなく、変更できる条件と変更時の処理、マイページでの表示、プラグインや基幹連携への影響を確認します。入金データの取り込みをきっかけに、出荷や在庫・ポイントなどの処理が重ねて実行されないようにします。
参照：EC-CUBE公式マニュアル「受注一覧」／EC-CUBE公式開発ドキュメント「受注ステータスのカスタマイズ」
入金確認メールは、必要な対象とタイミングを決める
配送会社などから店舗への振込は、お客様が代金を支払った日より後になることがあります。その都度「ご入金を確認しました」と送ると、お客様が支払った時点との違いで戸惑う可能性があります。
通知は必須とせず、何を知らせるために送るのか、宛先は注文者か社内担当者か、どの確認段階で送るのかを決めます。会員登録の有無だけで対象を決めず、実際の注文と連絡先を確認します。
取込処理が完了してもメール送信だけが失敗する場合に備え、取込結果と送信結果を分けて管理します。未送信・送信済み・結果不明を確認し、再取り込みだけで同じメールが再送されないようにします。
二重取り込み・訂正データ・途中失敗を扱えるようにする
同じファイルをもう一度選ぶ、同じ期間の明細を再ダウンロードする、複数の担当者が同じデータを取り込むといった操作を想定します。ファイル名が違っても同じ取引が含まれることがあるため、ファイル名だけでは重複を判断できません。
配送会社・契約・取引を識別する番号・精算情報など、元データの仕様に合わせて処理済みかを照合する方法を決めます。ファイル全体の一致確認に加え、明細ごとの処理履歴を持つ方法を検討します。
同じ送り状番号でも、後日、取消や訂正・調整の情報が届く場合には、新しい情報として扱う必要があります。単純に「同じ番号はすべて無視する」とせず、元取引との関係や変更内容を確認し、承認された訂正を記録します。
取込前の確認と、取込後の結果を残す
取込前には、利用するサービス・契約、対象期間、ファイル形式、文字コード、必須項目、件数・金額を確認します。更新予定の注文と変更内容を先に表示し、担当者が確認してから確定する方法も有効です。
- 正常に照合できた明細、確認が必要な明細、処理済みの明細を区別する
- 取り込み中に注文が変更された場合は、確定前に条件を再確認する
- 途中で失敗した場合、全件を取り消すか、確定した明細を残すかを決める
- 処理件数・金額・対象注文・更新前後の内容・実行者・実行日時を記録する
- 再実行する際は、確定済みの更新や通知を重ねない対象選択を行う
誤ったファイルを取り込んだ場合も、現在の情報を一律に上書きして戻すと、その後の正しい変更を失うおそれがあります。対象の履歴を確認し、訂正する範囲と承認者を決めて対応します。
個人情報や取引情報を含むファイルは、担当者の権限、保存先、保管期間を定めます。原本と処理結果を必要な範囲で保管し、作業用のコピーが不用意に増えない運用にします。
代引き入金データ取込の相談前に整理したいこと
まずは、現在の照合作業と実際のサンプルデータを確認します。通常の明細だけでなく、不一致・返品・訂正・重複などのケースを含めると、必要な処理を具体的に整理できます。
- EC-CUBEのバージョン、プラグイン、受注・決済・出荷に関する既存改修
- 配送会社・決済サービス・契約と、取り込むファイルの種類・項目定義
- 代金回収と店舗口座への入金のうち、どの段階を確認したいか
- 送り状番号と注文・配送の対応、分納・再発行・複数契約の扱い
- 手数料・差額・取消・返品の確認方法と、会計・基幹システムとの役割分担
- 更新する項目、確認担当者、処理頻度・件数、メール通知の要否
相談時には個人情報を置き換えたサンプルを使用します。導入前には検証環境で、正常データに加え、番号不一致、金額差異、処理済み明細、訂正データ、途中失敗を確認します。発送状況や既存の連携、メール送信に意図しない変化がないかも確認します。
サンクユーでは、EC-CUBE構築・カスタマイズやBtoB-EC構築のご相談に対応しています。現行のCSVや照合手順を確認し、注文との対応づけ、金額確認、履歴管理、既存システムとの連携まで、業務に合う対応方法を整理します。
EC-CUBEの代引き入金データ取込に関するよくある質問
EC-CUBEの標準機能だけで代引き入金CSVを取り込めますか？
EC-CUBE4には受注検索や対応状況の一括変更がありますが、配送会社ごとの入金CSVを照合して消し込む処理とは別です。利用バージョン、導入済みプラグイン、既存改修を確認し、対象形式の読み込み、注文との照合、金額確認、履歴管理に対応するプラグインや個別開発が必要かを判断します。
代引きの回収済みと、店舗への入金済みは同じですか？
お客様から代金を回収した段階と、配送会社などから店舗の口座へ振り込まれた段階は異なります。振込予定データも実際の口座入金とは区別します。何を確認したら処理済みとするかを決め、回収日、振込予定日、口座入金日、取込日時を混同しないようにします。
注文番号が入っていないデータも照合できますか？
送り状番号など、EC-CUBE側に登録された配送情報と対応する識別情報があれば照合方法を検討できます。配送会社や契約を識別する情報も含め、一意に対象を決められるか確認します。一致しないデータや候補が複数あるデータは自動更新せず、担当者が確認します。
振込額が注文金額と違っていても取り込めますか？
まず、比較している金額の意味と集計単位を確認します。代引回収額と店舗への振込額は、契約に基づく手数料や調整額によって異なる場合があります。注文・配送ごとの回収額と、精算単位の振込額を分けて照合し、説明できない差額は確認対象として残します。
発送済みの注文を入金済みに変更すればよいですか？
一律に変更する設計にはしません。EC-CUBE4の公式開発ドキュメントが示す標準の遷移では、発送済みから入金済みへ変更する経路はありません。利用環境を確認したうえで、発送状況を保ちながら、代引きの回収・精算状況や履歴を別に管理する方法を検討します。
同じCSVの再取り込みや、メールの重複送信を防げますか？
取引を識別する情報と処理履歴を照合し、処理済みの明細を重ねて反映しない仕組みを設計します。ファイル名だけには依存せず、訂正データや途中で失敗した処理の扱いも決めます。メールは取込処理と送信結果を別に記録し、通知が必要な対象だけを確認して送信・再送します。
EC-CUBEの代引き入金データ取込をご相談ください
現在の入金データと照合手順を確認し、注文照合、金額確認、ステータス・履歴管理、再取り込みまで、業務に合う方法を整理します。
投稿者プロフィール
- EC-CUBE・WordPressを中心に、サイト構築やカスタマイズを担当。
要件に応じた柔軟な実装を心がけています。
Movable Type案件の増加に伴い、対応領域拡大のためスキル強化中です。
ネイビー色が好きで「navy」という名前をよく使いますが、海軍好きと勘違いされることも。
でも軍モノ古着は好きです。
