B2B Suite Laravel Package

Getting Started

Check the version matrix before you run anything. The suite's majors don't track Bagisto's, so a mismatch is an infrastructure problem rather than a package problem:

If you're not already on PHP 8.4 and Bagisto 2.5, resolve that first. On a matching stack the install is roughly a day.

The install is three steps and deliberately not the default Laravel flow:

composer require bagisto/b2b-suite

Register the provider in bootstrap/providers.php, after the Shop package (or last in the array):

Webkul\B2BSuite\Providers\B2BSuiteServiceProvider::class,

Composer auto-discovery is intentionally disabled — discovery boots this provider before Shop and the package breaks. Don't "fix" it by re-enabling discovery.

php artisan b2b-suite:install   # migrate, seed, publish assets + view overrides, clear caches

Prebuilt Tailwind bundles ship with the package, so a stock install needs no npm run build.

Read these four things first, in this order:

1. Providers/B2BSuiteManager.php — the architecture in one file. It does $app->bind(CoreClass::class, B2BClass::class) and concord->registerModel(...). Every "how does B2B change core behavior?" question is answered here or in the B2B subclass it points at.
2. Providers/EventServiceProvider.php — view_render_event(...) listeners with $e->addTemplate('b2b::...'). This is how inline B2B UI lands inside core blades.
3. publishables/ — the single source of everything published. The tree under publishables/resources/vendor/<namespace>/<path> maps to resources/views/vendor/<namespace>/<path>. To change a B2B screen, copy the file here, not into your theme.
4. The config flag b2b.general.settings.active — check its value in admin before you debug anything B2B-related.

First use case to stand up: company registration → admin approves the company → admin creates/assigns a company admin → that admin invites sub-users and assigns roles → a buyer builds a requisition list and reorders it via quick order. That single path exercises company management, RBAC, requisition lists, quick order, and the flag. Do it on a production-like snapshot with the flag on, then flip it off and confirm the storefront degrades cleanly.

Implementation Patterns

Gate everything you add behind the existing flag. Nearly the whole suite reads:

core()->getConfigData('b2b.general.settings.active')

When inactive, B2B routes, menus, the company registration view, and B2B blocks inside overridden core views all disappear. Any custom B2B behavior should be gated identically, or you get half-rendered affordances on a store where the flag is off. The flag doubles as your pilot lever: enable per environment for one or two design-partner accounts rather than branching.

Extend via container binding and Concord registration — never by patching core. Copy the package's own pattern: write class B2BThing extends CoreThing, override only what you need, bind it in a manager provider:

$app->bind(CoreClass::class, \Webkul\B2BSuite\...\B2BClass::class);
$concord->registerModel(CoreModel::class, B2BModel::class);

There is no config/concord.php entry — B2BSuiteServiceProvider registers ModuleServiceProvider (models) and EventServiceProvider (view injection) itself. Follow that convention in your own extension layer so upgrades stay separable from core-commerce work in review.

Inject UI via view_render_event, not by forking core blades. Register a listener in an EventServiceProvider and add a template:

$e->addTemplate('b2b::some.partial');

Cheapest way to add a block to a core page, and it survives core upgrades far better than an override. Reserve overrides for screens you're genuinely restyling.

Override views through the namespaced vendor path — one mechanism for everything. Copy the file to resources/views/vendor/<namespace>/<path> (or keep it in publishables/resources/vendor/... if maintaining the package itself). This reaches both regular shop:: / admin:: views and anonymous x-shop:: components, which compile to shop::components.<name> and which theme view-path overrides cannot touch. Don't mix mechanisms; the account navigation in this package is a live example of a component override that only works this way.

Wire workflows around the domain objects, not around checkout. The day-to-day patterns:

• Requisition list → cart. Buyers curate lists and push them to cart. Note the v3.0.1 fix: a list can only contain products inside the company's catalog; out-of-catalog items stay behind with a notice. If you extend list mutation, enforce catalog membership at write time — the fix indicates validation exists somewhere, and you don't want a second path that skips it.
• Quick order (multi-SKU box, CSV upload, search-by-name/SKU) as the repeat-purchase front door. The search path regressed in 3.0.1 — if you customize product search, exercise all three quick-order inputs, not just the one you touched.
• RFQ → quote → order, and purchase order → approval → order. Treat approval steps as a state machine you own the policy for; the package exposes mechanics, not thresholds.
• Pay By Credit at checkout and custom / quantity-tier pricing on the company catalog. These interact with promotions, tax, currency, and multi-store in ways the docs don't evidence — probe those interactions before you sell the feature internally.

Company catalog is the lever with the widest reach. Per-company product and category visibility rides on the swapped core ProductRepository, so every product query in the storefront flows through B2B logic. Practical consequences:

• Test the non-B2B shopper path on every B2B change: category listing, search, product page, cart, checkout for an anonymous or non-company customer.
• Budget for query-shape and caching work at volume; there's no published evidence for behavior at 10k / 50k / 250k SKUs. Load-test with a realistic company catalog before wide rollout.

Development checkout layout. If you clone the repo rather than installing from the registry, it lives at available-extensions/bagisto/b2b-ecommerce and is symlinked into vendor/ via a path repository. The package declares no "version"; your app pins one in the repository entry's options.versions because Bagisto's root sets minimum-stability: stable. Never edit through vendor/ — the write reaches the clone but stays invisible to its git status, which is an expensive way to lose a day.

Gotchas and Tips

Provider order is load-bearing. Auto-discovery off, provider registered after Shop. Missing routes, missing menus, or a boot failure: check bootstrap/providers.php before reading a single line of package code.

b2b-suite:install publishing over existing overrides is the upgrade question to answer before you customize. Everything publishes into resources/views/vendor/<namespace>, and where you already override those paths, conflicts are file-level and silent — last publish wins. Determine whether install re-publishes and overwrites on upgrade, and whether an idempotent upgrade path exists. Practically: keep your overrides in git with a README listing which published files you've edited, and diff the published tree against the package's publishables/ after every upgrade.

Vue @event names colliding with Blade directives fail only at render. A Vue binding like @error or @empty inside a Blade file compiles to broken PHP that 500s at request time — and php artisan view:cache reports success on invalid PHP. This class of defect reaches production unless you add a CI step that compiles/lints views and, ideally, renders the B2B screens in a browser. (The v3.0.1 Playwright suite covering registration, quotations, purchase orders, Pay By Credit, company users/roles, catalogs, requisition lists, quick order, and the company profile across MySQL, MariaDB, and PostgreSQL is a reasonable model to copy.)

Styling: the package injects its bundle at head.before on purpose. Loading a second utility sheet after core lets plain utilities beat core's responsive variants on core elements — this previously broke the admin sidebar and toasts. Two implications: don't "helpfully" reorder the asset injection, and never build or publish into public/themes/{admin,shop}/default/build, because core upgrades revert that silently. Your own theme tokens and utilities are not in the package's bundle, so any custom token used on a B2B screen needs to be delivered separately and verified against the built manifest.

Flag drift reads as a bug. A flag off in one environment presents as "missing routes and menus" and burns triage time. Record the flag value in your environment documentation and check it first when a B2B screen 404s. Conversely, the flag is your safest rollout control — use it rather than a branch.

The ProductRepository rebind has global blast radius. Company-catalog visibility runs through the core repository used by every product query, so a B2B defect degrades the non-B2B storefront. On-call and QA scope must include non-B2B traffic; don't triage incidents as "B2B only" by default.

Version lockstep is a standing cost. Suite majors don't track Bagisto majors, every core upgrade obligates a matching suite upgrade, and a Laravel or PHP security patch can force a suite upgrade ahead of maintainer readiness. Budget this per quarter in the roadmap, not per install. With 27 stars, 0 dependents, and a Webkul\ maintainer namespace, there is no Stack Overflow corpus — plan for self-service troubleshooting and read the source, starting with B2BSuiteManager.php.

Expect to consume ~30% and carry 100% of the upgrade cost. The suite bundles company accounts, RBAC, requisition lists, quick order, RFQ, purchase orders, per-company product and category visibility, custom and quantity-tier pricing, and credit checkout. Pick the subset you need, but recognize the upgrade review covers the whole published surface.

Useful extension points, ranked:

1. view_render_event listeners — cheapest, most upgrade-safe UI insertion.
2. A B2B subclass + container bind — safe for behavior, but every bind is a global change; document each one.
3. concord->registerModel(...) overrides — the sanctioned route for adding columns (ERP IDs, IdP subject mapping) without forking.
4. Namespaced view overrides — powerful and the intended customization surface, but the highest-churn artifact across upgrades.
5. Editing core theme bundles — never.

Resolve these early, because they change your design: is company/custom/tier pricing a peer of core pricing or a layer above it (and how does it interact with promotions, tax, currency, multi-store)? Do PO/RFQ ship multi-level approval thresholds and spend limits, or is that yours to build? Does RBAC cover admin scope or storefront only, and can permissions map to IdP groups? And are B2B capabilities exposed through Bagisto's APIs, or storefront-view only — that single answer decides whether B2B is a channel feature or a platform feature for you.