EC-CUBE で B2B
構築を相談する

カスタマイズ

締め日の決め方、請求番号の採り方、支払期日のずらし方。このあたりは会社ごとに 違います。合わない部分が出たときに、どこまで手が入るかをまとめました。

1ソースが読めます

EC-CUBE 本体もプラグインも、ソースは手元に来ます。中で何をしているかを読めますし、 読んだうえで直せます。ブラックボックスはありません。

SaaS だと、仕様に合わない部分は待つしかありません。要望を出して、採用されるかを 待ち、採用されなければ運用のほうを曲げることになります。ソースが手元にあれば、 その場で直せます。

2差し替え口が用意してあります

主要な処理はインターフェースとして切ってあります。35本のプラグインに、あわせて49か所あります。実装したクラスを置くだけで登録されます。 設定ファイルに書き足す作業はありません。プラグイン本体も書き換えません。 書き換えると、次の版が出たときに当て直すことになります。

会員グループ管理

差し替えられるところできること
VisibilityGuardInterface見せない条件を足す(公開開始日を過ぎるまで隠す、など)。全実装を呼んで1つでも止めれば見せない

会員グループ価格管理

差し替えられるところできること
PriceResolverInterface価格の決め方を足す(数量で単価を変える、など)。優先度の高いものから見て、最初に名乗り出た1本を使う

支払い方法管理

差し替えられるところできること
PaymentPermissionInterface注文の中身で支払い方法を絞る(合計30万円を超えたら代引きを外す、など)

配送方法管理

差し替えられるところできること
DeliveryPermissionInterface届け先や荷物の中身で配送方法を絞る(北海道・沖縄には自社便を出さない、点数の多い届け先にはメール便を出さない、など)

会員限定サイト

差し替えられるところできること
PriceVisibilityInterfaceログイン済みの会員にも価格を隠す(承認が下りるまで卸価格を伏せる、卸グループにだけ出す、など)。隠す方向にだけ働く

取引先アカウント管理

差し替えられるところできること
OrderVisibilityScopeInterfaceマイページで見せる受注の範囲を決める(会社全体、部署単位、役職者だけ全体など)。誰も答えなければ本人の受注だけ
MemberInitializerInterface担当者を発行するときの初期値を決める(与信の枠、独自の権限フラグなど)
MemberAccessDeciderInterface担当者に退会・お届け先の登録を許すかを人ごとに決める(役割で分けるなど)。誰も答えなければ許す
MemberAddressScopeInterface担当者の購入手続きに並べるお届け先を人ごとに決める(拠点の届け先だけにするなど)

担当者のセルフ管理

差し替えられるところできること
MemberLimitInterface担当者の上限を取引先ごとに決める(大口の取引先だけ 20 人にする、無制限にする、など)

取引先の拠点

差し替えられるところできること
DefaultLocationInterface購入手続きをどの拠点で始めるか、その拠点のどのお届け先で始めるかを決める(兼務の担当者は本社を既定にする、拠点ごとに事務所宛を既定にする、など)

会員登録承認制

差し替えられるところできること
ApprovalTargetInterface承認が要るかどうかの判定を、自前の条件にする

購入資格

差し替えられるところできること
PurchasePermissionInterface資格のほかにも売り先を絞る(同じ都道府県の届出がある会員だけ、取引基本契約を結んだ会員だけ)。**絞る方向にしか働きません**

営業担当者

差し替えられるところできること
SalesRepResolverInterface誰の担当かの決め方を足す(会員グループごとに担当営業を決める、基幹システムの得意先マスタから引く、など)。PHP と DQL を対で書く

商品スペック検索

差し替えられるところできること
SearchableSpecProviderInterface絞り込み欄に出すスペックを差し替える(カテゴリごとに出す項目を変える、会員グループによっては見せない、など)

製品比較

差し替えられるところできること
CompareRowProviderInterface比較表に出す行を足す(商品説明の一部を出す、独自のテーブルから引く、など)

代替品・後継品提案

差し替えられるところできること
AlternativeProviderInterface代替品の出どころを差し替える(基幹システムの品目マスタから後継品を引く、など)

商品資料配布

差し替えられるところできること
DocumentAccessInterface落とせるかどうかの判定を足す(取引先の等級ごとに見せる図面を変える、契約している会員にだけミルシートを出す、など)

型番一括発注

差し替えられるところできること
ProductCodeTranslatorInterface貼られた文字列を自社の型番へ読み替える(得意先別品番・旧型番・JAN・ハイフンの有無など)

見積依頼

差し替えられるところできること
QuoteNumberGeneratorInterface見積番号の付け方を差し替える(基幹システムや紙の帳簿の採番に合わせる)

発注単位管理

差し替えられるところできること
QuantityRuleInterface数量の決まりを足す(会員グループごとに単位を変える、など)

定期発注

差し替えられるところできること
NextDateRuleInterface期日を店の都合に寄せる(土日を外す、毎月20日に寄せる、など)
RecipientProviderInterfaceお知らせの宛先を足す(担当者と経理の両方へ送る、など)

切り売り・寸法指定

差し替えられるところできること
CutRuleProviderInterface切り売りの決まりの出どころを差し替える(基幹システムや在庫の定尺から取る、会員グループによって切れる範囲を変える)

予約・先行受注

差し替えられるところできること
PreorderPermissionInterface予約を受ける相手を絞る(展示会に来場した取引先の会員グループだけに先行受注を受ける、など)

サンプル請求

差し替えられるところできること
SampleEligibilityInterface誰にサンプルを出すかを絞る(取引の始まった会員だけ、特定の会員グループだけ)。**絞る方向にしか働きません**

取引先品番管理

差し替えられるところできること
CodeOwnerResolverInterface品番の持ち主をどの会員にするかを決める(事業部ごとに別の品番体系を使う取引先で、表を事業部で分ける)

代理注文

差し替えられるところできること
ForbiddenRouteProviderInterface代理中に塞ぐ画面を足す(自分で足したマイページの画面も、帯のリンクごと消える)

発注承認

差し替えられるところできること
ApproverResolverInterface承認者の決め方を変える(親子関係ではなく部署で決めるなど)

案件別注文管理

差し替えられるところできること
ProjectSourceInterface案件の入れ方を差し替える(基幹システムの案件一覧から選ばせる、取引先ごとに使える工番を決める)

担当者の権限

差し替えられるところできること
PermissionInterface権限を足す(価格を見る、見積りを依頼する、など)

温度帯別配送

差し替えられるところできること
TemperatureZoneResolverInterface温度帯の決め方を差し替える(このカテゴリは全部冷凍、など)。優先度の高いものから見て、最初に温度帯を返した実装が勝ちます

納品場所指定

差し替えられるところできること
AddressKeyNormalizerInterface住所の表記の揺れを吸収して手引きを引き当てる(「1ー2ー3」と「1-2-3」、郵便番号のハイフンの有無を同じとみなす、など)

部屋分け発注

差し替えられるところできること
RoomProviderInterface分け先の一覧をどこから取るかを差し替える(施設の基幹システムや独自のテーブルから引く)

不定貫商品

差し替えられるところできること
WeightPricingInterface端数の扱いを差し替える(四捨五入する、10円単位に丸める、10g 単位に丸めてから計算する)

取り寄せ・分納

差し替えられるところできること
BackorderPermissionInterface取り寄せを受ける相手を絞る(前払いの取引先だけ、この会員グループだけ、など)
RecipientProviderInterface納期回答メールの宛先を足す(担当者と購買部の両方へ送る、など)

月締め請求管理

差し替えられるところできること
BillableOrderCriteriaInterface締め対象の受注の絞り込みを足す
BillingPartyResolverInterface請求先の決め方を変える(部署単位の請求など)
InvoiceNumberGeneratorInterface請求番号の採り方を会計システムに合わせる
DueDateResolverInterface支払期日をずらす(休業日なら翌営業日など)
TaxSummarizerInterface消費税の計算方法を足す
ReturnCollectorInterface外部の返品管理から返還を取り込む
InvoiceDocumentInterface帳票の種類を足す(会計ソフト向け CSV など)
PaymentRestrictionInterface支払方法を会員ごとに絞る(この取引先は請求書払いのみ、など)

注文請書・発注書

差し替えられるところできること
OrderDocumentInterface帳票の種類を足す(見積書、検収書、英語版、会計ソフト向け CSV など)

業務の自動化

差し替えられるところできること
TriggerInterfaceきっかけを足す(出荷が登録された、見積が承認された、など)。宣言だけなので、火を点ける購読やコマンドは足した側で書く
ConditionInterface条件を足す(お届け先の都道府県、取引先の等級、基幹システムの与信枠など)。ルールの中では AND で効く
ActionInterfaceすることを足す(チャットへ流す、自社の基幹システムの API を叩く、独自の帳票を作る)

置くだけで登録されます

置き場所は EC-CUBE 標準のカスタマイズ領域(app/Customize)です。 インターフェースを実装したクラスを置けば、それだけでプラグインから呼ばれます。 順番を変えたいときだけ、クラスに1行足します。

use Symfony\Component\DependencyInjection\Attribute\AsTaggedItem;

#[AsTaggedItem(priority: 50)]
class PublishDateGuard implements VisibilityGuardInterface

既定の実装より先に効かせたいときは priority を上げます。 指定しなければ 0 として扱われます。

組み合わせ方は決まっています

差し替え口ごとに、複数の実装をどう束ねるかが決まっています。ここを取り違えると、書いたのに効かない、あるいは効きすぎることになります。どの型かは各プラグインの手引きに書いてあるので、AI に読ませれば合わせてくれます。

束ね方どうなるか例
全部呼ぶ(AND)1つでも止めれば止まる。足した判定は既定を緩められませんVisibilityGuardInterface、PaymentRestrictionInterface、BillableOrderCriteriaInterface
先に決めた1本が勝つ優先度の高い順に呼び、最初に答えた実装を使います。決められないときは次へ譲りますPriceResolverInterface、ApproverResolverInterface、ApprovalTargetInterface
前の結果を受け取る前の実装が出した値を受け取り、加工して返しますDueDateResolverInterface
結果を連結する全実装の結果をつなげて使いますReturnCollectorInterface

出す場所は PHP を書かずに変えられます

商品ページに何かを足すプラグインは、既定では自動で出ます。設定は要りません。置き場所を決めたいときだけ、テーマのテンプレートに1行書きます。

{# app/template/<テーマ>/Product/detail.twig #}
{{ plg_product_spec() }}      {# 商品スペック検索 #}
{{ plg_matrix() }}            {# 規格一括入力 #}
{{ plg_product_document() }}  {# 商品資料配布 #}

書いたら自動表示は降ります。二重に出ないので、設定で切る必要がありません。書かない店はこれまでどおりです。

自動で出すほうは、断片を JavaScript で本来の位置へ移しています。移す先の目印はテーマを触ると変わります。変わっても例外は出ませんが、出なくなるかフッターの下に出ます。 テーマを大きく作り替えている店は、上の書き方で位置を決めてください。

プラグイン書くもの
商品スペック検索{{ plg_product_spec() }}
規格一括入力{{ plg_matrix() }}
商品資料配布{{ plg_product_document() }}
代替品・後継品提案{{ plg_product_alternative() }}
予約・先行受注{{ plg_preorder() }}
サンプル請求{{ plg_sample() }}
購入資格{{ plg_pq() }}

帳票のレイアウトも同じで、PHP は要りません。請求書は月締め請求管理、注文請書と発注書は注文請書・発注書のページに、 置くファイルの場所を書いています。

画面の文言は管理画面から直せます

マイページの画面、完了ページ、メールの本文、商品ページに差し込まれる断片。 これらはテンプレートの写しを app/template/plugin/<コード>/ に置いて直します。管理画面では直せません(プラグインテンプレート編集プラグイン 4.4.1 から。 直した履歴が残らないため)。直したいファイルだけを置けばよく、テーマを変えても、 プラグインを更新しても写しは残ります。写しは git で控えを残します。

本体のページ管理・メール設定の本文欄からは直さないでください。本体は保存のときに必ずテーマ配下へ書き込むため、そのまま保存すると「保存できたのに画面が変わらない」状態になります。プラグインテンプレート編集 プラグインを入れておくと、この欄を伏せ、本体が書いた写しをその場で消します。 メールの件名だけはメール設定から直せます(件名はテンプレートではなく マスタの項目のため)。

このプラグインは B2B 用ではないので、プラグイン一覧には並べていません。 文言を直したい場合はご相談ください。

3AI に書かせられます

差し替え口が決まっていて、そこに実装を置くだけで動きが変わります。この形は AI と相性がいい。やりたいことを日本語で伝えれば、Claude Code のような AI コーディングツールが 実装を書きます。書かせる場所も、書かせる量も、あらかじめ決まっているためです。

なぜ AI で足せるのか

ソースが手元にあるAI がプラグインの中身を読めます。仕様を推測させずに済みます
触る場所が決まっている書くのは1クラスだけ。プラグイン本体も EC-CUBE 本体も触りません
AI 向けの手引きが同梱各プラグインに CLAUDE.md とdocs/extension-samples.md が入っています。 差し替え口ごとに、そのままコピーして使えるサンプルが載っています
置けば登録されるインターフェースを実装したクラスを置くだけで登録されます。設定ファイルを 触らないので、配線でつまずきません(順番を変えたいときだけクラスに1行足します)
組み合わせ方も決まっている全部呼ぶもの(AND)、先に決めた1本が勝つもの、前の結果を受け取って加工する もの、結果を連結するもの。どの型かは手引きに書いてあるので、AI が読んで合わせます

頼み方はこれだけです

「支払期日が土日祝に当たったら翌営業日にずらしたい」という要望を、そのまま渡します。

app/Plugin/B2BBilling/docs/extension-samples.md を読んで、
支払期日が土日祝なら翌営業日にずらす DueDateResolverInterface の実装を
app/Customize に追加してください。休業日は自前のテーブルから引きます。

出てくるのはこの形です。プラグインの中は1行も変わりません。

namespace Customize\B2BBilling;

use Plugin\B2BBilling\Service\Billing\DueDate\DueDateResolverInterface;

class BusinessDayDueDateResolver implements DueDateResolverInterface
{
    public function resolve(?\DateTimeImmutable $current, BillingContext $context): ?\DateTimeImmutable
    {
        // 前の実装が出した支払期日を受け取り、休業日なら翌営業日へずらして返す
    }
}

そのまま本番に入れないでください

AI が書いたコードは動いて見えても、条件の取り違えが混ざります。請求と在庫にかかわる部分は、金額がずれても気づきにくいのが やっかいなところです。テスト環境で締めを1回通し、出てきた請求書を目で確かめて から本番へ入れてください。

手引きには「効いているか確かめる」手順も書いてあります。AI にそこまで やらせてください。

差し替え口が無いところは、AI でも足せません。プラグイン本体を書き換えることに なり、次の版が出るたびに当て直すことになります。そういう要望はこちらで 引き受けます。

4それでも足りなければ、作ります

差し替え口が用意されていない部分や、プラグインの外側に必要なものは、こちらで 作ります。よくある相談を並べました。

基幹システム・会計ソフトとの連携

受注を基幹へ払い出す、得意先マスタを取り込む。まず受注CSVで足りるかを確かめてください。取引先名・工番・温度帯・搬入の手引き・実重量は、受注CSVの項目として登録済みです(既定は「出力しない」ので、出したいものだけ設定 → CSV出力項目設定でオンにします)。仕訳の起票に使える請求 CSV は月締め請求管理が標準で出すので、会計ソフト別の列並びにしたいときだけ帳票の差し替え口に実装します。

請求書の様式を取引先の指定に合わせる

取引先から様式を指定されることがあります。請求書のレイアウトは Twig テンプレート1枚で差し替えられるので、まずそこで済むかを確かめ、足りなければ帳票の差し替え口から作ります。

得意先別の品番で発注を受け付ける

型番一括発注には、貼られた文字列を読み替える口があります。旧型番や JAN、得意先ごとの品番を自社の型番へ読み替えて受け付けられます。

承認のラインを組織図で決める

既定では取引先の親子関係をそのまま稟議のラインに使います。部署のマスタで決めたい場合は、承認者の決め方を差し替えます。

承認や請求をきっかけに通知する

承認・回送・差し戻しのたびにイベントが流れます。チャットへ流す、外部システムへ渡すといった処理を、プラグインを書き換えずに足せます。

後継品を品目マスタから引く

代替品・後継品提案は、既定では商品登録の画面に型番を並べて書く形です。電子部品や電材のように後継品が基幹システムで決まっている店では、人が1つずつ結べません。代替品の出どころを差し替えます。

温度帯や分け先を、1点ずつ選ばずに決める

扱いが数千点ある食品の店で温度帯を1点ずつ選ぶのは現実的ではありません。「このカテゴリは全部冷凍」のような決め方を足せます。医療・福祉の部屋分けも同じで、分け先の一覧を施設の基幹システムから引けます。

端数の丸め方を取引先との取り決めに合わせる

不定貫商品は既定で円未満切り捨てですが、四捨五入する店、10円単位に丸める店、10g 単位に丸めてから計算する店があります。金額の出し方を差し替えます。

ここに無いこと

やりたいことを書いて送ってください。できる・できない・どのくらいかかるかを お返しします。できない場合はその理由も書きます。

環境ごと引き渡せます

サーバーの構成も Git で管理します。どのサーバーでも同じ手順で立ち上がるので、 あとから別の会社に引き継げますし、VPS からクラウドへ移すこともできます。 囲い込むつもりはありません。

構成は導入の流れに書いています。

合うかどうか、先に確かめてください

いまの受注のしかたと、どこを自動にしたいかを書いて送ってください。プラグインの設定で足りるのか、差し替えで済むのか、作り足しが要るのかをお返しします。