EC-CUBEでB2Bサイトを作る：標準・プラグイン・カスタマイズの線引き

7月末から、EC-CUBE で B2B サイトを作る話を9本書きました。個別の記事はそれぞれ独立していて、どこから読んでも困らないようにしてあります。ただ、全体としてどこまでが標準で、どこからが作るものなのかが見えにくくなりました。

棚卸しします。見積もりを取る前に、自社の要件がどの層にあるかを確かめるための記事です。

3つの層

B2B EC に求められる機能を、EC-CUBE でどう賄うかで分けるとこうなります。

境目は、「会員によって出し分けたいだけ」か「業務の流れそのものを足したい」かです。前者はプラグインで届きます。後者は用意がありません。

標準でできること

素の EC-CUBE でも、B2B の土台になる部分はあります。

• 会員登録と、仮会員を挟む運用
• カートと購入手続き、在庫の引き当て、購入数量の制限
• 受注管理、受注の編集、明細の追加や値引き行
• 納品書のPDF出力
• 注文完了メール、出荷通知メール

取引先ごとに価格を変えることはできません。 商品の価格は誰が見ても同じです。会員ランクで価格を変える機能もありません。ここが B2B で最初に突き当たる壁です。

詳しくは取引先ごとに卸価格を出し分ける方法に書きました。よくある回避策とその限界もまとめてあります。

プラグインで足りるところ

出し分けは会員グループ管理プラグインとアドオンで揃います。判定の軸はすべて会員グループです。

全部要るわけではありません。取引先ごとの価格だけが目的なら、本体と価格管理アドオンの2つで動きます。

入れる順番には決まりがあります。会員グループの設計を最初に固めること、承認制は仮会員登録と会員登録拡張アドオンが前提であること。順番を守らないと有効化すらできない組み合わせがあります。卸売サイトを立ち上げる順番に手順としてまとめました。

作ることになるもの

ここから先は用意がありません。実際に作って、どれくらいのものになるかを記事にしてあります。

6つとも、本体を1行も編集せずに済みました。 すべて app/Customize に収まっています。EC-CUBE には拡張の口が用意されていて、購入フローへの差し込み、クエリへの割り込み、イベントでの差し替え、エンティティの拡張、サービスの継承で足りました。

これは見積もりの前提として大きいところです。本体を書き換える改修は、バージョンアップのたびに差分を当て直すことになります。そうならない範囲で収まるかどうかが、長く使えるかを分けます。

どれから手を付けるか

全部を一度に作る必要はありません。実際に相談を受けるときの順番はだいたいこうなります。

1. 会員グループを決める。 これだけは後戻りが高くつきます。取引先ごとに作るか、掛け率ごとにまとめるか
2. プラグインで出し分けを組む。 価格、商品、支払い方法、配送方法。ここまでで「取引先が自分の価格で買える」状態になります
3. 入り口を決める。 会員登録を審査制にするか、こちらで登録して案内するか
4. 業務の流れを足す。 見積が要るのか、一括発注が要るのか、承認が要るのか。ここは要件次第で、要らない会社も多い

4つ目に進む前に、2つ目までで運用が回るかを確かめてください。卸価格が出るだけで足りる会社は、思ったより多いです。

この記事で扱っていないこと

正直に書いておきます。

多段の承認には届いていません。 承認できるのは管理者1人だけという前提で作りました。金額で承認者を変える、部長と役員の2段にする、といった稟議には作り直しが要ります。

受注を会社単位でまとめる処理がありません。 担当者が発注した受注の会員は担当者本人です。会社宛に請求をまとめるなら、集計する仕組みを別に足すことになります。

カード決済との相性を詰めていません。 見積も承認フローも、銀行振込や請求書払いのような後払いを前提にしています。承認前に決済が走る問題は残っています。

パッケージとの比較はここではしていません。 運用まで任せたい規模なら、B2B 専用パッケージのほうが妥当です。その判断材料はB2B ECの見積もりを取る前に確かめてほしいことにまとめました。この記事の線引きは、その見積もりを取る前に自社の要件がどちら側にあるかを見るためのものです。

まとめ

上4つで足りるなら、プラグインを入れて設定するだけです。下5つが要件に入っているなら、そこが見積もりの対象になります。