Shopware 6 für B2B: was der Core kann und was eigenen Code braucht

Ebene 1: Was der Core kostenlos kann

Alles in dieser Liste steckt im Open-Source-Core von 6.7.15.1. Wir haben jeden Punkt aus den Entity-Definitionen und Regelklassen dieses Tags gelesen.

• Kundengruppen mit Nettopreisen: jede Gruppe legt fest, ob die Storefront Brutto- oder Nettopreise zeigt, und kann ein eigenes Registrierungsformular haben, auf Wunsch nur für Firmenkonten.
• Registrierung mit Freigabe: ein Kunde kann eine Gruppe beantragen, und Sie nehmen den Antrag an oder lehnen ihn ab. Die Annahme löst ein Event aus, auf das der Flow Builder reagieren kann, etwa mit einer Willkommensmail.
• Firmendaten: der Kunde hat einen Kontotyp, einen Firmennamen und USt-IDs.
• Staffelpreise pro Regel: erweiterte Preise hängen an einer Regel aus dem Rule Builder und einem Mengenbereich. "Kunde ist in Gruppe Großhandel" ist eine Regel, Gruppenpreise mit Mengenstaffeln funktionieren also ohne Erweiterung.
• Bestellmengen: Mindest- und Höchstabnahme sowie Staffelung pro Produkt, damit ein Palettenartikel in Schritten von 40 verkauft wird.
• Zahlung und Versand pro Regel: jede Zahlungs- und Versandart kann eine Verfügbarkeitsregel tragen, damit Kauf auf Rechnung nur Firmenkunden in einer vertrauenswürdigen Gruppe angeboten wird.
• Flow-Builder-Aktionen: Kundengruppe ändern oder ein Tag setzen, wenn ein Event eintritt, ohne Code.

Was der Core nicht hat, ist eine Organisation auf Käuferseite. Die ACL des Core gilt nur für Benutzer der Administration. Ein Storefront-Kunde ist eine Person mit einem Login, ohne Kollegen und ohne Rollen.

Ebene 2: Was die B2B Components ergänzen

Die B2B Components gehören zu Shopware Commercial. Sie schalten jede Komponente pro Kunde unter "Customer-specific features" in der Administration ein oder aus.

Budget Management setzt Ausgabenlimits und braucht B2B Commercial 7.6.0 oder neuer. Auf der Preisseite stehen Angebote, Schnellbestellung, Einkaufslisten, Organisationseinheiten, Budgets, Individual Pricing und die erweiterten Rollen bei Evolve und Beyond. Rise und die Community Edition haben keine davon.

Kundenspezifische Preise aus dem ERP

Individual Pricing arbeitet mit Regeln: es rabattiert einen Katalog für eine Gruppe von Einkäufern. Eine Preisliste pro Kunde und Produkt, gepflegt im ERP, ist eine andere Funktion. Die kundenspezifischen Preise von Commercial nehmen diese Preise über einen Admin-API-Endpunkt entgegen, /api/_action/custom-price, im Sync-Format mit Mengenstaffeln. Die Preisseite führt sie nur bei Beyond. Der Core hat gar keine Preisliste pro Kunde.

Ebene 3: Was weiter eigenen Code braucht

Eigener Code lohnt sich, wenn die Anforderung ein Ablauf ist, den nur Ihr Unternehmen hat. Zwei Projekte aus unseren Fallstudien zeigen die Grenze.

• Eine Ausschreibungsplattform: ein Maschinenbauer verkauft Anlagen über Ausschreibungen mit versiegelten Geboten, Öffnung zum Stichtag und Freigabe durch Finanzen, Recht und Geschäftsführung. Quote Management deckt einen Einkäufer ab, der nach einem Preis fragt. Viele Bieter, die verschlüsselt gegeneinander antreten, deckt es nicht ab, deshalb wurde das ein eigenes Plugin.
• Lieferanten-Routing: ein Großhändler brauchte für jede Bestellung einen Abgleich mit dem Bestand mehrerer Lieferanten, eine Aufteilung, wenn keiner alles hatte, und die Weitergabe an das richtige Lager. Das ist Fulfillment-Logik, die keine Komponente mitbringt.

Weitere typische Individualentwicklung: Preislogik, die der Rule Builder nicht abbilden kann, Bedingungen, die ERP-Daten lesen, und Integrationen, die B2B-Daten nach Ihrem eigenen Takt übertragen.

Wo eigener Code in 6.7 andockt

Das sind die Erweiterungspunkte, mit den Klassennamen, wie sie im Tag 6.7.15.1 existieren.

• Produktpreise: dekorieren Sie AbstractProductPriceCalculator. Der ProductPriceCalculator des Core hat einen internen Konstruktor, dekorieren Sie also den abstrakten Service, statt die Klasse abzuleiten.
• Der Warenkorb: ein CartDataCollectorInterface lädt die Daten einmal, ein CartProcessorInterface ändert Preise oder Positionen, und ein CartValidatorInterface stoppt den Checkout mit einem Fehler.
• Bedingungen im Rule Builder: eine neue Klasse, die Rule erweitert. Das Beispiel unten zeigt eine.
• Flow Builder: erweitern Sie FlowAction für eine neue Aktion, oder implementieren Sie FlowEventAware an Ihrem eigenen Event für einen neuen Auslöser.
• Store API: Routen im StoreApiRouteScope, die eine StoreApiResponse liefern, für Portale und Headless-Frontends.

Beispiel: Kauf auf Rechnung für gesperrte Kunden ausblenden

Angenommen, Ihr ERP markiert Kunden, deren Kreditlimit ausgeschöpft ist, und die Markierung landet in einem Zusatzfeld am Kunden. Eine Bedingung im Rule Builder macht diese Markierung überall nutzbar, wo Regeln wirken: Zahlungsverfügbarkeit, Versand, Preise und 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');
    }
}

Registrieren Sie die Klasse als Service mit dem Tag shopware.rule.definition. Der Rule Builder bietet die Bedingung erst an, wenn auch die Administration sie kennt: registrieren Sie sie mit ruleConditionDataProviderService.addCondition(), und weil die Klasse getConfig() definiert, rendert die generische Komponente sw-condition-generic ihr Feld. Legen Sie dann eine Regel "Kunde ist nicht gesperrt" an und setzen Sie sie als Verfügbarkeitsregel der Zahlungsart Rechnung.

Welche Ebene deckt Ihre Anforderung ab?