Shopware 6 for B2B: what core does and what needs custom code

Layer 1: What Core Does for Free

Everything in this list is in the open-source core of 6.7.15.1. We read each one from the entity definitions and rule classes at that tag.

• Customer groups with net prices: each group decides whether the storefront shows gross or net prices, and can have its own registration form, limited to company accounts if you want.
• Registration with approval: a customer can apply for a group, and you accept or decline the request. Acceptance fires an event the Flow Builder can react to, for example with a welcome mail.
• Company data: the customer has an account type, a company name and VAT IDs.
• Tiered prices per rule: advanced prices attach to a Rule Builder rule and a quantity range. "Customer is in group Wholesale" is a rule, so group prices with quantity tiers work out of the box.
• Order quantities: minimum and maximum purchase quantity and purchase steps per product, so a pallet item can be sold in steps of 40.
• Payment and shipping per rule: every payment and shipping method can carry an availability rule, so invoice payment can be limited to company customers in a trusted group.
• Flow Builder actions: change a customer's group or add a tag when an event fires, without code.

What core does not have is a buyer-side organisation. Core ACL covers Administration users only. A storefront customer is one person with one login, with no colleagues and no roles.

Layer 2: What the B2B Components Add

The B2B Components ship with Shopware Commercial. You switch each one on or off per customer under "Customer-specific features" in the Administration.

Budget Management sets spending limits and needs B2B Commercial 7.6.0 or later. On the pricing page, quotes, quick ordering, shopping lists, organisation units, budgets, individual pricing and the extended roles sit on Evolve and Beyond. Rise and the Community Edition have none of them.

Customer-specific prices from the ERP

Individual Pricing is rule-based: it discounts a catalogue for a group of buyers. A price list per customer and product, maintained in the ERP, is a different feature. Commercial's customer-specific pricing takes those prices through an Admin API endpoint, /api/_action/custom-price, in the sync format with quantity tiers. The pricing page lists it on Beyond only. Core has no per-customer price list at all.

Layer 3: What Still Needs Custom Code

Custom code earns its place when the requirement is a process only your business runs. Two projects from our case studies show the line.

• A tender platform: an industrial machinery manufacturer sells equipment through tenders with sealed bids, a reveal at the deadline and approval by finance, legal and management. Quote Management covers a buyer asking for a price. It does not cover many bidders competing under encryption, so this was a custom plugin.
• Supplier routing: a distributor needed each order checked against several suppliers' stock, split when no single supplier had everything, and sent to the right warehouse. That is fulfilment logic no component ships with.

Other typical custom work: price logic the Rule Builder cannot express, conditions that read ERP data, and integrations that push or pull B2B data on your own schedule.

Where Custom Code Plugs In on 6.7

These are the extension points, with the class names as they exist at the 6.7.15.1 tag.

• Product prices: decorate AbstractProductPriceCalculator. The core ProductPriceCalculator has an internal constructor, so decorate the abstract service instead of extending the class.
• The cart: a CartDataCollectorInterface loads the data once, a CartProcessorInterface changes prices or line items, and a CartValidatorInterface blocks the checkout with an error.
• Rule Builder conditions: a new class that extends Rule. The example below shows one.
• Flow Builder: extend FlowAction for a new action, or implement FlowEventAware on your own event to get a new trigger.
• Store API: routes in the StoreApiRouteScope that return a StoreApiResponse, for portals and headless frontends.

Example: hide invoice payment for credit-blocked customers

Say your ERP flags customers whose credit limit is used up, and the flag lands in a customer custom field. A Rule Builder condition makes that flag usable everywhere rules work: payment availability, shipping, prices and flows.

<?php declare(strict_types=1);

namespace Acme\B2b\Rule;

use Shopware\Core\Checkout\CheckoutRuleScope;
use Shopware\Core\Framework\Rule\Rule;
use Shopware\Core\Framework\Rule\RuleConfig;
use Shopware\Core\Framework\Rule\RuleConstraints;
use Shopware\Core\Framework\Rule\RuleScope;

class CustomerCreditBlockedRule extends Rule
{
    final public const RULE_NAME = 'acmeCustomerCreditBlocked';

    public function __construct(protected bool $isBlocked = true)
    {
        parent::__construct();
    }

    public function match(RuleScope $scope): bool
    {
        if (!$scope instanceof CheckoutRuleScope || !$customer = $scope->getCustomer()) {
            return false;
        }

        $blocked = (bool) ($customer->getCustomFields()['acme_credit_blocked'] ?? false);

        return $this->isBlocked ? $blocked : !$blocked;
    }

    public function getConstraints(): array
    {
        return ['isBlocked' => RuleConstraints::bool(true)];
    }

    public function getConfig(): RuleConfig
    {
        return (new RuleConfig())->booleanField('isBlocked');
    }
}

Register the class as a service with the tag shopware.rule.definition. The Rule Builder only offers the condition once the Administration knows it too: register it with ruleConditionDataProviderService.addCondition(), and because the class defines getConfig(), the generic sw-condition-generic component renders its field. Then build a rule "customer is not credit-blocked" and set it as the availability rule of the invoice payment method.

Which Layer Covers Your Requirement?