EC-CUBEの注文内容をマイページで変更｜BtoB-ECの受付条件と運用設計

「配送先を選び間違えた」「納品希望日を変えたい」。注文後にこうした修正が必要になると、顧客が問い合わせを送り、店舗が対象の注文を探して変更する作業が発生します。

条件を満たす注文をマイページから変更できるようにすれば、顧客が自分で手続きを進められます。ただし、出荷準備や決済が進んでいる注文もあるため、変更の受付条件と、その後の業務への反映まで合わせて設計することが大切です。

EC-CUBEで注文後の変更を受け付けるには

EC-CUBE4の標準マイページには、注文履歴の確認、会員情報編集、お届け先の登録・編集などがあります。一方、店舗側には受注データを編集する管理画面があります。これらを踏まえ、会員が対象の注文を選んで変更するための画面と処理を追加するのが、今回のカスタマイズです。

標準機能については、公式のマイページ機能と受注管理を参照できます。利用中のバージョンや既存プラグインによって構成が異なるため、導入前に現在の動作を確認します。

登録済み住所の編集と、注文済みの配送先変更を分ける

会員情報や「お届け先一覧」の住所を編集することと、すでに受け付けた注文の配送先を変更することは別です。住所帳を直しただけで、今回の注文先まで変わったと思わせない案内が必要です。

変更画面では対象の注文番号と現在の配送先を表示し、「どの注文の情報を変更するか」を確認できるようにします。複数のお届け先に分かれた注文では、変更する配送分も特定します。

マイページで変更できる項目を絞る

管理画面で編集できる項目を、そのまますべて顧客に開放する必要はありません。現在多く発生している変更依頼から、顧客自身で手続きできる範囲を選びます。以下は検討例であり、標準機能の一覧ではありません。

配送に関する変更でも、必ず金額が変わらないとは限りません。たとえば、配送先地域の変更で送料が変わる場合は、合計金額と決済の扱いも確認する必要があります。

商品や数量の変更も、一律に対象外と決める必要はありません。ただし、影響する処理が多くなるため、最初は配送情報などに範囲を絞り、商品・数量は店舗への変更申請で受け付ける進め方もあります。

変更期限は、実際の受注・出荷業務に合わせる

経過時間だけでなく、出荷や連携の進み具合で判定する

「注文から一定時間内」という期限だけでは、すでに手配が進んでいる注文を見落とすことがあります。倉庫への出荷指示、送り状の作成、製作開始など、変更を止めるべき業務上の区切りを決めます。

EC側の表示が「未発送」でも、外部の倉庫では作業を始めている場合があります。ECの受注状況と、倉庫・販売管理側の状態をどう照合するかが重要です。連携先の状態を確認できない場合は、即時変更の対象を狭め、店舗確認へ回す方法を検討します。

BtoB-ECでは、取引先ごとの締め時間、受注生産品の手配、分納なども関係します。注文全体を変更可能にするか、まだ手配していない明細・配送分だけを対象にするかも決めます。

変更を確定する時点でも条件を確認する

顧客が画面を開いたときには変更できても、入力中に店舗担当者が受注を編集したり、出荷処理が進んだりすることがあります。確定時にも最新の状態を確認し、古い情報で上書きしない仕組みが必要です。

変更ボタンを隠すだけでなく、送信された変更を受け付ける処理側でも、注文の所有者・担当者権限・受付期限・変更可能な項目を確認します。締切後の画面には、変更できない理由と問い合わせ先を表示すると、顧客が次の行動を判断しやすくなります。

即時変更と、店舗確認後の変更を使い分ける

マイページからの手続きは、入力内容をその場で反映する方法と、変更希望として受け付けて店舗が確認する方法に分けられます。

申請方式では、「変更希望を受け付けました」と「注文内容を変更しました」を区別します。店舗が確認する前に、顧客が変更済みと思わない表示にすることが大切です。

また、申請を確認している間に出荷を進めてよいか、いったん保留するかも決めます。申請が届くだけで作業が止まらなければ、確認中に変更できなくなる場合があるためです。

注文別のメッセージ機能を窓口にする方法もあります。その場合も、会話の記録と実際の受注更新は別の処理として管理します。

金額・決済・在庫・出荷の整合を確認する

受注金額の更新と、決済の変更をそろえる

商品や数量、配送先が変わると、商品代金、送料、手数料、値引き、ポイントなどに影響する場合があります。どの条件を再計算し、注文時のどの条件を維持するかを決めます。住所の修正に伴って、無関係な商品の単価まで現在価格へ置き換わることがないよう注意します。

EC側の合計金額を更新しても、決済サービス側の金額まで自動的に変わるとは限りません。利用中の決済プラグインと決済状態を確認し、金額変更、取消し、再手続き、差額対応などの必要性を検討します。操作の可否や期限は決済サービスによって異なります。

掛売の場合も、請求データを作成した後の変更をどう扱うか確認します。取引先への案内、社内の処理、ECと販売管理の金額が食い違わない流れにします。

数量変更は、在庫と取引条件を再確認する

数量を増やす場合は追加分の在庫や納期、減らす場合は確保済み在庫の戻し方を確認します。BtoB-ECでは、ロット・ケース単位、最低注文数、数量別単価、取引先別の販売条件も変更後の内容と照合します。

店舗側の修正と顧客の操作が重なった場合や、送信を繰り返した場合にも、在庫や金額を二重に更新しない制御が必要です。

出荷指示・帳票・外部システムへ反映する

配送先をEC側で変更しても、倉庫へ渡したCSVや発行済みの送り状が古いままでは、変更前の住所へ発送されるおそれがあります。受注画面、メール、納品書、出荷CSV、販売管理・倉庫システムのうち、どこを更新・再発行するかを整理します。

連携が途中で失敗した場合は、顧客へ変更完了と案内する前に、未反映の状態を把握できるようにします。変更を取り消すのか、出荷を保留して担当者が確認するのかなど、復旧の手順も決めておきます。

連携方法の考え方は、EC-CUBEと基幹・在庫システムを連携する方法でも解説しています。

BtoB-ECでは担当者の権限と変更履歴も決める

同じ会社の注文を閲覧できることと、その注文を変更できることは別です。発注者本人、会社の管理者、店舗担当者のうち、誰に何の変更を認めるかを決めます。担当者が退職・異動した場合の扱いも、法人アカウントの権限設計と合わせて整理します。

承認済みの注文で数量や金額が変わる場合は、変更後の内容について再承認が必要か確認します。単価・与信・納期など、顧客側だけで判断できない条件は店舗確認へ回す方法があります。

変更履歴には、変更前後の内容、操作した担当者、日時、理由、処理結果を残す範囲を決めます。顧客への通知と、営業・受注・出荷担当への通知も整理し、変更があったことを関係者が確認できるようにします。

既存サイトへ導入する際の進め方

まずは、現在受けている変更依頼を集め、件数だけでなく、確認や修正に時間がかかる理由を整理します。そのうえで、即時変更できる項目、店舗確認が必要な項目、受付終了の条件を決めます。

• 変更依頼が多い項目と、現在の受付窓口・対応手順
• EC-CUBEのバージョン、決済プラグイン、既存の受注・マイページ改修
• 倉庫・販売管理との連携時刻と、変更を止める業務上の区切り
• 担当者の権限、承認、通知、変更履歴の要件

公開前には、受付期限を過ぎるケース、入力中に出荷処理が進むケース、在庫不足、送料変更、決済や連携の失敗などを確認します。すべての項目を一度に対応させず、運用に合う範囲から導入して、問い合わせ件数や対応時間の変化を確認する進め方が考えられます。

変更しやすさと、受注後の業務を両立する

マイページから注文を変更できる仕組みは、顧客が自分で手続きを進める選択肢を増やします。変更できる項目と期限を絞り、決済・在庫・出荷まで反映する流れを整えることで、店舗側も扱いやすい機能になります。

サンクユーのEC-CUBE構築・カスタマイズでは、既存サイトと受注業務を確認し、マイページ改修や受注管理の改善をご提案します。