7月末から、EC-CUBE で B2B サイトを作る話を17本書きました。個別の記事はそれぞれ独立していて、どこから読んでも困らないようにしてあります。ただ、全体としてどこまでが標準で、どこからが作るものなのかが見えにくくなりました。
棚卸しします。見積もりを取る前に、自社の要件がどの層にあるかを確かめるための記事です。
3つの層
B2B EC に求められる機能を、EC-CUBE でどう賄うかで分けるとこうなります。
| 層 | 何が入るか |
|---|---|
| 標準でできる | 会員登録、カート、購入手続き、受注管理、納品書、注文履歴、各種メール |
| プラグインで足りる | 取引先ごとの価格、見せる商品の制限、支払い方法と配送方法の出し分け、会員登録の承認制 |
| 作ることになる | 見積、型番一括発注、担当者アカウント、承認フロー、見積書、その通知、月締め請求と請求書 |
境目は、「会員によって出し分けたいだけ」か「業務の流れそのものを足したい」かです。前者はプラグインで届きます。後者は用意がありません。
標準でできること
素の EC-CUBE でも、B2B の土台になる部分はあります。
- 会員登録と、仮会員を挟む運用
- カートと購入手続き、在庫の引き当て、購入数量の制限
- 受注管理、受注の編集、明細の追加や値引き行
- 納品書のPDF出力
- 注文完了メール、出荷通知メール
取引先ごとに価格を変えることはできません。 商品の価格は誰が見ても同じです。会員ランクで価格を変える機能もありません。ここが B2B で最初に突き当たる壁です。
詳しくは取引先ごとに卸価格を出し分ける方法に書きました。よくある回避策とその限界もまとめてあります。
プラグインで足りるところ
出し分けは会員グループ管理プラグインとアドオンで揃います。判定の軸はすべて会員グループです。
| やりたいこと | 使うもの |
|---|---|
| 会員をグループに分ける、商品やカテゴリを見せない | 会員グループ管理（本体） |
| 取引先ごとの卸価格、掛け率、数量割引 | 会員グループ価格管理アドオン |
| 請求書払いを法人だけに出す | 支払い方法管理アドオン |
| 専用の配送便を用意する | 配送方法管理アドオン |
| 登録時にグループを割り当てる | 会員登録拡張アドオン |
| 登録を審査してから開通する | 会員登録承認制アドオン |
| 購入実績でグループを自動で入れ替える | 会員ランク管理アドオン |
全部要るわけではありません。取引先ごとの価格だけが目的なら、本体と価格管理アドオンの2つで動きます。
入れる順番には決まりがあります。会員グループの設計を最初に固めること、承認制は仮会員登録と会員登録拡張アドオンが前提であること。順番を守らないと有効化すらできない組み合わせがあります。卸売サイトを立ち上げる順番に手順としてまとめました。
作ることになるもの
ここから先は用意がありません。実際に作って、どれくらいのものになるかを記事にしてあります。
| 機能 | 何が要るか | 記事 |
|---|---|---|
| 型番で一括発注 | 型番から商品規格を引いてカートへ入れる画面 | 型番一括発注の画面を足す |
| 見積依頼から受注まで | 受注ステータスの追加、ステートマシン、在庫を引くタイミング | 見積依頼機能を足す |
| 1社に複数の発注担当者 | 会員の親子関係、担当者の発行、会社単位の注文履歴 | 1社に複数の発注担当者を置く |
| 発注の承認 | 承認待ちステータス、購入フローへの差し込み、承認の画面 | 担当者の発注を管理者が承認してから通す |
| 見積書のPDF | 納品書のPDF出力の継承、背景PDFの差し替え | 見積書のPDFを出す |
| 承認の通知 | 完了メールの差し替え、承認依頼と結果の通知 | 承認フローの通知メールを整える |
| 金額で承認者が変わる稟議 | 承認限度額、いま誰の番かを持つ受注、階層をたどる処理 | 金額で承認者が変わる社内稟議を作る |
| 稟議の記録 | 承認・回送・差し戻しを残すテーブル、差し戻し理由 | 稟議の記録を残す |
| 店舗側から稟議を追う | 受注編集画面のテンプレートへの差し込み | 稟議の履歴を店舗側からも読む |
| 月締めで請求をまとめる | 取引先ごとの締め日、会社配下の受注の集計、締めた金額の保持 | 取引先の請求を月締めでまとめる |
| 請求書のPDF | 納品書のPDFサービスの継承、背景PDFを使わない描画 | 請求書のPDFは納品書の継承では届かない |
| インボイス制度への対応 | 税率ごとの集計、端数処理を締め単位で1回にする | 締めてから消費税を計算し直す |
| 適格請求書の成立 | 納品書との組み合わせ、書類どうしの関連づけ | 適格請求書は1枚でなくてもいい |
| 返品の差し引き | 締め済み受注の返品の検出、次の請求からの控除 | 締めたあとに返品が来たら |
| 部分返品と値引き | 返還を請求から切り離した記録、返せる残りの判定 | 一部だけ返す、あとから値引きする |
| 入金の消し込み | 入金の記録、支払期日、未入金と期日超過の表示 | 入金されたかどうかを追う |
| 会社情報の固定と退会の連動 | フォームと保存後の二重の固定、管理者の退会に合わせた担当者の退会 | 穴だと書いたものが、穴ではなかった |
17本とも、本体を1行も編集せずに済みました。 すべて app/Customize に収まっています。EC-CUBE には拡張の口が用意されていて、購入フローへの差し込み、クエリへの割り込み、イベントでの差し替え、エンティティの拡張、サービスの継承で足りました。
これは見積もりの前提として大きいところです。本体を書き換える改修は、バージョンアップのたびに差分を当て直すことになります。そうならない範囲で収まるかどうかが、長く使えるかを分けます。
どれから手を付けるか
全部を一度に作る必要はありません。実際に相談を受けるときの順番はだいたいこうなります。
- 会員グループを決める。 これだけは後戻りが高くつきます。取引先ごとに作るか、掛け率ごとにまとめるか
- プラグインで出し分けを組む。 価格、商品、支払い方法、配送方法。ここまでで「取引先が自分の価格で買える」状態になります
- 入り口を決める。 会員登録を審査制にするか、こちらで登録して案内するか
- 業務の流れを足す。 見積が要るのか、一括発注が要るのか、承認が要るのか。ここは要件次第で、要らない会社も多い
- 請求の出し方を決める。 都度請求で足りるのか、月締めが要るのか。月締めなら締め日と、請求書をどう出すかまで決めることになります
4つ目に進む前に、2つ目までで運用が回るかを確かめてください。卸価格が出るだけで足りる会社は、思ったより多いです。
5つ目は、要ると分かっているなら早めに触っておいたほうがいい部分です。締めた金額をあとから動かすかどうか、消費税をどの単位で丸めるか、請求書に何を書いて何を納品書に任せるか。どれも実装より先に決めることがあって、後から変えると出した書類と食い違います。
この記事で扱っていないこと
正直に書いておきます。
カード決済との相性を詰めていません。 見積も承認フローも、銀行振込や請求書払いのような後払いを前提にしています。承認前に決済が走る問題は残っています。
稟議のラインと請求のまとまりは、同じ形とは限りません。 請求は取引先の管理者にぶら下がる担当者までを集めます。担当者の下にさらに担当者がいる3階層の構成にすると、いちばん下の受注が請求に入りません。ここは要件を聞いてから決める部分です。
パッケージとの比較はここではしていません。 運用まで任せたい規模なら、B2B 専用パッケージのほうが妥当です。その判断材料はB2B ECの見積もりを取る前に確かめてほしいことにまとめました。この記事の線引きは、その見積もりを取る前に自社の要件がどちら側にあるかを見るためのものです。
まとめ
| 要件 | どうなるか |
|---|---|
| 取引先ごとに価格を変えたい | プラグインで足りる |
| 取引先ごとに見せる商品を変えたい | プラグインで足りる |
| 請求書払いや専用配送を用意したい | プラグインで足りる |
| 会員登録を審査制にしたい | プラグインで足りる |
| 型番を並べて発注させたい | 作る |
| 見積のやり取りをサイト上でやりたい | 作る |
| 1社で何人も発注させたい | 作る |
| 発注に社内承認を挟みたい | 作る |
| 金額で承認者を変えたい | 作る |
| 見積書や独自の帳票を出したい | 作る |
| 月締めで請求をまとめたい | 作る |
| 適格請求書として請求書を出したい | 作る |
| 返品を次の請求で差し引きたい | 作る |
| 入金を消し込んで未入金を追いたい | 作る |
上4つで足りるなら、プラグインを入れて設定するだけです。下の10項目が要件に入っているなら、そこが見積もりの対象になります。