この記事でわかること
EC-CUBEの受注一覧から注文商品を一括変更するカスタマイズ事例を紹介します。標準の受注編集との違い、変更対象の商品・規格・明細の特定、金額・在庫・決済・出荷への影響、誤更新を防ぐための確認事項を整理します。
複数の注文で同じ商品変更を行う業務では、受注一覧から対象を選んで処理する方法があります。ただし、商品を置き換えると、請求額や在庫、出荷指示にも影響する場合があります。画面操作をまとめることと、関連する処理を正しく揃えることをあわせて考える必要があります。
受注一覧から注文商品を一括変更するカスタマイズ事例
サンクユーでは、注文商品の変更を繰り返し行う運用に合わせて、受注一覧ページから対象の注文を選び、商品を一括変更できるようにカスタマイズしました。元の記事で紹介しているのは、EC-CUBE 2.13系を対象とした事例です。
注文ごとに受注詳細を開いて変更する方法では、対象件数の分だけ画面を行き来します。本事例では、受注一覧に選択欄と商品変更用の操作を設け、複数注文の変更をまとめて行えるようにしました。
対象の受注を選び、変更先の商品を指定する
以下は、本事例の受注検索結果の画面です。赤枠の①で対象の受注を選択し、②で変更先の商品を選んで「選択した商品に変更する」を実行する構成です。
- 受注管理画面で、変更対象の注文を検索する
- 受注一覧で、商品を変更したい注文を選択する
- 変更先の商品を選び、対象の注文へ変更を適用する
画像は個別にカスタマイズした当時の画面であり、EC-CUBE 4系の標準画面ではありません。また、確認画面、変更履歴、差額決済、複数明細の処理など、後述する確認事項のすべてを本事例で実装したという意味ではありません。
標準の受注編集と、一覧からの商品一括変更を分けて考える
EC-CUBEには、注文ごとに内容を編集する機能があります。確認したEC-CUBE4の公式マニュアル（4.3.1-p1版）では、受注編集画面で商品の追加や注文内容の編集を行い、計算結果を更新する操作が案内されています。
一方、受注一覧の標準の一括操作として案内されているのは、メール送信、納品書出力、対応状況の変更です。確認した同バージョンの受注一覧の画面ソースも、この構成です。「一括操作がある」ことと、「複数注文の商品をまとめて置き換えられる」ことは区別します。
実際の導入では、利用中のバージョン、プラグイン、既存のカスタマイズを確認します。商品変更の頻度や件数が少ない場合は、標準の個別編集と確認手順の整理で対応できることもあります。
なお、この記事で扱うのは、受け付けた注文の中の商品を変更する機能です。商品マスターの名前や販売価格を一括更新する機能とは異なります。どちらのデータを変更するのかを明確にしてから仕様を決めます。
変更する注文・商品・規格・明細を特定する
商品名だけで対象を決めると、同名の商品や、色・サイズなどが異なる規格を取り違えるおそれがあります。変更元の商品・規格、変更先の商品・規格、対象となる注文明細を特定できるようにします。
| 決める項目 | 確認する内容 |
|---|---|
| 対象の注文 | 選択した注文だけか、検索結果全件か。ページをまたぐ選択の扱いと実行件数 |
| 変更元・変更先の商品 | 商品ID・規格ID・商品コードと、確認用の商品名・規格名 |
| 対象の明細 | 注文内の特定商品だけか、複数の該当明細を含むか。配送先ごとの区別 |
| 数量と販売単位 | 元の数量を維持するか。一部数量の変更や、箱・個など単位の違いがないか |
| 対象外の条件 | 発送済み、キャンセル済み、決済処理中、変更元の商品が含まれない注文など |
複数明細や一部数量の変更は、注文全体の置き換えと分ける
例えば、商品Aと商品Bを含む注文で、商品Aだけを商品Cへ変更する場合、商品Bの明細を残す必要があります。同じ商品Aが複数の配送先に分かれている場合は、どの配送分を変更するかも決めます。
また、10個のうち2個だけを別商品に変更する場合は、元の明細の数量調整と変更後の明細の追加が必要になることがあります。単に商品名や商品IDを一括で置き換えるだけでは扱えないため、注文・明細・数量の単位を分けて設計します。
本事例の画像だけでは、複数明細や数量の分割にどう対応していたかは確認できません。これらを必要とする場合は、追加の要件として整理します。
商品変更後の金額と、決済・請求の処理を確認する
単価・税率・送料・値引きを含め、変更前後の金額を確認する
商品を変更するときは、元の注文の単価を維持するのか、変更後の商品価格を使うのかを先に決めます。BtoB-ECでは、取引先別の価格や合意済みの見積価格があるため、現在の商品マスターの価格をそのまま適用してよいとは限りません。
数量、税率、送料、手数料、値引き、ポイントやクーポンへの影響も確認します。再計算の対象を決め、変更前後の支払合計と差額を確認できるようにします。送料などを含むすべての項目が、希望どおりに自動調整されると決めつけないことが大切です。
注文金額の更新と、決済サービス側の処理を分ける
EC-CUBEの注文金額を変更しただけで、決済サービス側の金額変更や返金まで完了したとは扱いません。連動の有無や操作手順は、決済サービス、プラグイン、決済の進行状況によって確認します。
カード決済では金額変更の可否や追加の決済操作、銀行振込では入金額との差額対応、掛け払いでは請求書や締め処理への反映を整理します。金額差がない場合でも、購入者へ案内する商品名・規格・納期が変わっていないか確認が必要です。
定期購入や継続課金を扱う場合は、今回の注文だけを変更するのか、次回以降の契約商品も変更するのかを分けます。受注データの変更が、継続課金の契約まで連動するとは限りません。
在庫・出荷指示・外部システムとの整合性を保つ
変更前の引当解除と、変更後の引当をどこで行うか決める
在庫を引き当て済みの商品を変更する場合は、変更前商品の引当を解除し、変更後商品の在庫を確保する処理を確認します。標準の受注編集処理、既存のカスタマイズ、倉庫・基幹システムとの連携を把握し、同じ在庫を二重に戻したり減らしたりしないようにします。
複数注文を同時に変更する場合は、変更後の商品について、対象全体で必要になる数量を確認します。確認画面を開いた後に在庫や注文内容が変わることもあるため、実行時点でも変更できる状態かを確かめる設計が必要です。
在庫数や注文データの一部だけを直接書き換える処理にせず、既存の検証・計算・在庫更新処理との整合性を確認します。注文取消しに伴う処理については、注文キャンセルと在庫戻しの注意点も参考になります。
出荷指示済みの注文は、倉庫側の変更・停止まで確認する
出荷CSVを渡した後や倉庫で作業が始まった後は、EC-CUBE側の商品を変更しても、旧商品の出荷指示が残る場合があります。どこまで進んだ注文を一括変更の対象にするか、先に決めます。
変更が必要な場合は、旧指示の停止・差し替え方法、変更データの受け渡し、倉庫側での反映確認を整理します。CSVを作り直すだけで完了とせず、二重の出荷指示にならない運用にします。
発送済みの商品は、通常の一括変更とは分けて返品・交換として扱います。一部出荷の注文は、変更する商品と数量が未出荷かを確認します。商品単位の進行管理については、商品別ステータス管理と一部出荷の設計で解説しています。
確認画面・履歴・処理結果で誤更新を防ぐ
一括変更では、1回の操作が複数注文へ反映されます。以下は導入時に検討したい設計事項です。本事例ですべて実装済みとするものではありません。
- 実行前に対象の注文番号、件数、変更前後の商品・規格・数量・金額を確認する
- 画面上の選択だけでなく、サーバー側でも権限、対象の注文、変更可能な状態を検証する
- 確認後に他の担当者が編集した注文や、出荷が進んだ注文をそのまま上書きしない
- ボタンの二度押しや画面の再送信で、変更や通知が重複しないようにする
- 変更後の受注情報、帳票、購入者への案内内容、連携先のデータを確認する
成功・失敗・未処理を区別し、再実行の範囲を明確にする
対象の一部でエラーが発生した場合に、全件を中止するのか、処理できる注文だけを更新するのかを決めます。どちらの場合も、注文ごとの結果と理由が分かり、未完了の作業を追えることが重要です。
外部の決済や倉庫への連携を含む場合、EC-CUBE内のデータを戻すだけでは、外部で完了した処理まで取り消せません。注文更新、決済操作、在庫・出荷連携、通知メールそれぞれの結果を確認して、必要な部分だけを再処理できるようにします。
変更した担当者、日時、理由、変更前後の内容を残し、問い合わせや誤操作時の確認に使います。履歴を残すことと、自動で元に戻せることは別です。変更を取り消す場合にも、その時点の決済・在庫・出荷状況を確認します。
| 確認するケース | 確認するポイント |
|---|---|
| 商品・規格・配送先が異なる注文 | 指定した明細だけが変更され、他の商品や配送情報が維持されるか |
| 単価・税率・送料などが変わる注文 | 支払合計と差額が意図どおりで、決済・請求への反映を確認できるか |
| 在庫不足や出荷済みの注文 | 対象外やエラーの理由が分かり、他の注文への影響を把握できるか |
| 同時編集・二度押し・途中停止 | 上書きや二重処理を防ぎ、成功済みと未完了を区別できるか |
相談時には、変更元・変更先の商品例、対象となる注文の状態、1回あたりの件数、数量・価格の扱い、決済や倉庫との連携方法を整理すると、必要な処理を具体化できます。
サンクユーでは、EC-CUBE構築・カスタマイズやBtoB-EC構築のご相談に対応しています。標準機能の活用も含め、日々の商品変更業務に合う操作と確認手順を整理します。
受注変更・出荷管理の関連記事
EC-CUBEの注文商品一括変更に関するよくある質問
EC-CUBEの標準機能で、複数注文の商品を一括変更できますか？
確認したEC-CUBE 4.3.1-p1では、受注ごとの商品編集と、メール送信・納品書出力・対応状況変更などの一括操作があります。複数注文の商品をまとめて別の商品へ置き換える操作とは異なります。利用中のバージョン、プラグイン、既存のカスタマイズを確認し、必要な機能を判断します。
商品規格や複数明細を含む注文にも対応できますか？
個別に設計できます。変更元の商品・規格と対象明細を特定し、どの明細を何個変更するかを決めます。同じ商品が複数の配送先に分かれている場合や、一部の数量だけを変更する場合も区別します。本記事の既存事例について、これらすべてへの対応が確認できているわけではありません。
商品を変更すれば、金額や決済も自動で変更されますか？
注文金額の計算と、決済サービス側の金額変更・返金は別に確認します。元の単価を維持するか変更後商品の価格を使うかを決め、税率、送料、値引きなどを含む差額を確認します。決済との連動可否や手順は、利用サービスとプラグイン、決済の状態によって異なります。
変更前の商品の在庫は、手動で戻せばよいですか？
一律に手動で戻す運用にはしません。標準の受注編集処理、既存のカスタマイズ、倉庫・基幹システムの在庫連携を確認し、変更前商品の引当解除と変更後商品の引当をどこで行うか決めます。複数の処理で同じ在庫を戻したり減らしたりしない設計が必要です。
発送済みやキャンセル済みの注文も一括変更できますか？
通常の商品変更では、対象外にする条件を先に決めます。発送済みは返品・交換として扱う必要があり、キャンセル済みや決済処理中の注文にも別の確認が必要です。一部出荷の場合は、注文全体の状態だけでなく、変更する商品・数量が未出荷かを確認します。
途中で失敗した場合、同じ処理をもう一度実行してよいですか？
結果が分からないまま全件を再実行しないようにします。注文ごとの成功・失敗・未処理と理由を記録し、現在の状態を確認したうえで未完了分を処理する設計を検討します。注文更新だけでなく、在庫連携、決済操作、通知メールの二重実行も防ぐ必要があります。
EC-CUBEの注文商品変更・受注管理をご相談ください
変更対象の商品・明細、金額・在庫・決済・出荷への影響を確認し、業務に合う一括処理と誤更新を防ぐ設計を整理します。
投稿者プロフィール
- サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。
Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。
ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。
