Shopware B2B Plattform — Firmenkonten & Rollen
Firmenkonten, Mitarbeiter, Rollen, Budgets und Firmenadressen direkt im Checkout
Ein Firmenkunde hat zehn Mitarbeiter, drei Abteilungen, zwei Budgetverantwortliche und einen Geschäftsführer, der alles über 500 Euro freigeben will. Standard-Shopware kann das nicht abbilden. Also wird improvisiert: separate Accounts, manuelle Abstimmung per Mail, Excel-Listen für Budgets. Irgendwann fällt das auseinander. Die Bronn B2B-Plattform ist das zentrale Plugin der Bronner B2B Suite. Sie bringt Firmenkonten mit Mitarbeitern, Zugriffsrechte nach Rollen, Budgets pro Abteilung und Freigabeprozesse in deinen Shopware-Shop. Modular aufgebaut, nativ in Shopware integriert. Aktuelle Version: 1.8.1. Mit v1.8.0 wurde ein durchgreifender Type-Design-Refactor live gezogen: Vier BackedEnums (`B2bPermission`, `BudgetPeriod`, `ApprovalStatus`, `RestrictionType`) machen die API durchgehend typsicher — Tippfehler in Strings sind nicht mehr möglich, statische Analyse fängt jeden Mismatch ab. Zwei neue Unique-Indizes verhindern Duplikate auf Datenbankebene: `permission` ist pro Rolle nur noch einmal vergebbar und ein Mitarbeiter kann pro Cost-Center nur noch einmal verknüpft sein. Zwei XOR-Validatoren erzwingen saubere Datenmodelle: ein Budget gehört entweder zu einer Abteilung ODER zu einem Cost-Center (nie beides), eine Product-Restriction filtert entweder über Produkt-IDs ODER über Kategorien (nie beides gleichzeitig). Eine Legacy-Bridge sorgt dafür, dass bestehende String-Werte aus der Datenbank weiterhin funktionieren — keine Breaking-Changes für bestehende Installationen. v1.8.1 ist ein UX-Hotfix für die XOR-Validatoren: bei Verletzung wurde vorher ein generischer `businessError`-Flash angezeigt. Jetzt zeigt das Plugin spezifische, übersetzte Snippet-Texte an, sodass Admins sofort verstehen, welche XOR-Regel verletzt wurde und wie sie sie reparieren. Früher: Mit v1.7.5 wurde ein umfassendes Security-Hardening live gezogen (Cross-Company-Schutz, separate Cart-Extension, `approvals.submit`). v1.7.6 brachte flächiges Observability mit `LoggerInterface` in 9 Controllern und konservativem Approval-Default. v1.7.7 und v1.7.8 stabilisierten den `CrossCompanyAccessAuditLogger` auf ERROR-Level. v1.7.9 stellte die `config.xml` zurück auf Inline-Labels mit `lang="de-DE"`/`lang="en-GB"`, damit die Plugin-Konfiguration im Shopware-Extension-Manager vollständig deutsch und englisch sichtbar ist.
Funktionen
Firmenkonten, die komplexe Strukturen abbilden
Jede Firma bekommt ein eigenes Konto. Darunter legen sich Mitarbeiter, Abteilungen und Hierarchien an. Der Firmenkunde verwaltet das selbst, ohne dass du im Admin jedes Mal manuell nachhelfen musst. Das spart Supportzeit. Ein Großhändler mit 200 Firmenkunden und jeweils 5 bis 50 Mitarbeitern kann nicht bei jeder Personaländerung ein Ticket schreiben. Mit der B2B Plattform erledigt der Kunde das in zwei Minuten selbst.
Rollen und Berechtigungen, die Sinn ergeben
Nicht jeder Mitarbeiter darf alles. Der Einkäufer soll Produkte in den Warenkorb legen. Der Abteilungsleiter soll Bestellungen prüfen. Der Geschäftsführer gibt frei. Das Berechtigungssystem bildet das ab. Du legst Rollen an und vergibst Rechte. Wer darf bestellen? Wer darf nur den Warenkorb befüllen? Wer sieht welche Preise? Die Rollen werden einmal angelegt und dann wiederverwendet.
Budgets und Freigaben ohne manuelle Eingriffe
Hier wird es für Einkaufsabteilungen interessant. Du setzt Budgets pro Mitarbeiter, pro Abteilung oder pro Firma. Sobald jemand sein Budget überschreitet, geht die Bestellung nicht raus, sondern landet beim Vorgesetzten zur Freigabe. Der Prozess läuft automatisch. Der Einkäufer sieht, dass die Bestellung auf Freigabe wartet. Der Vorgesetzte bekommt eine Benachrichtigung und gibt mit einem Klick frei oder lehnt ab. Ein konkretes Szenario: Ein Industriezulieferer hat 15 Einkäufer mit jeweils 2.000 Euro Monatsbudget. Bisher hat der Vertriebsleiter am Monatsende manuell geprüft, wer wie viel bestellt hat. Jetzt sieht er in Echtzeit, wo die Budgets stehen, und muss nur bei Überschreitungen aktiv werden.
Modular aufgebaut, beliebig erweiterbar
Die B2B Plattform funktioniert allein. Du kannst sie mit weiteren Plugins der Bronner B2B Suite kombinieren. Bestelllisten, damit Kunden wiederkehrende Orders in Sekunden aufgeben. Angebotsanfragen, damit Preise direkt im Shop verhandelt werden. Preise ausblenden, damit nur freigeschaltete Kunden deine Konditionen sehen. Jedes Plugin ist unabhängig. Du installierst, was du brauchst, und erweiterst, wenn der Bedarf wächst.
Firmenadressen direkt im Checkout (neu in v1.5.0)
Mitarbeiter müssen Firmenadressen nicht mehr vorab in ihr Adressbuch übernehmen. Auf der Bestellbestätigungsseite stehen zwei Dropdowns bereit: "Firmenadresse als Lieferadresse" und "Firmenadresse als Rechnungsadresse". Beim Absenden kopiert das Plugin die Adresse in das persönliche Adressbuch und setzt sie sofort als aktive Liefer- bzw. Rechnungsadresse. Damit verschwindet der frühere Zwei-Schritt-Umweg über den Account-Bereich. Der bestehende Adopt-Workflow im Account-Bereich bleibt zusätzlich verfügbar — als Self-Service oder für Bestellvorlagen. Die zugehörige `adopt-and-select`-Route ist POST-only mit CSRF-Token. Exception-Details werden nicht an den Storefront-Client durchgereicht.
Adress-UI komplett B2B-konform (neu in v1.6.0)
Die Standard-Shopware-Adressverwaltung wurde für B2B-Mitarbeiter vollständig durch die B2B-Adressverwaltung ersetzt. Das passiert an drei Eingriffspunkten: Der Account-Bereich `/account/address` leitet Mitarbeiter automatisch auf das Firmenadressen-Modul um. Im Checkout öffnet der Adress-Wechsler statt der Standard-Adressverwaltung den B2B-AddressManager als Modal mit Tabs für Liefer- und Rechnungsadressen. Direkte Standard-Save-Routen (`/account/address/create`, `/account/address/edit`) werden serverseitig mit HTTP 403 geblockt, sodass Mitarbeiter keine privaten Adressen mehr anlegen können. v1.7.2 stabilisiert den Modal-Workflow: das Helfer-Plugin `BronnB2bModalInit` re-initialisiert das `BronnB2bAddressManager`-Storefront-Plugin nach jedem Modal-AJAX-Load. Hidden-Stub-Inputs und Pane-Divs verhindern, dass Shopware-Core-Code beim Re-Render auf undefinierte Felder zugreift und das Modal crasht.
Permission `shop.purchase` (konsolidiert, v1.7.0)
Die bisher getrennten Permissions `cart.add` (in den Warenkorb legen) und `product.view_prices` (Preise sehen) wurden zur einen Permission `shop.purchase` zusammengelegt. Das spiegelt wider, wie B2B-Einkauf tatsächlich funktioniert: Wer einkaufen darf, muss Preise sehen — und umgekehrt ergibt eine Preis-Sicht ohne Cart-Möglichkeit kaum Sinn. Die Migration `Migration1762000000MergeCartAndPriceViewPermissions` hebt bestehende Rollen automatisch an: Jede Rolle, die vorher mindestens eine der beiden alten Permissions hatte, bekommt jetzt `shop.purchase`. Die alten Permission-Strings werden batch-konsolidiert per `INSERT ... SELECT` (v1.7.1). Gleichzeitig wurde die Cart-Sperre über `CartAddPermissionSubscriber` mit der Preis-Sicht konsistent gemacht: Mitarbeiter ohne `shop.purchase` sehen weder Preise noch können sie Produkte in den Warenkorb legen — auf Produktdetail, in der Listings-Kachel und in der Cart-Summary. Cart-Error-IDs sind eindeutig pro LineItem, damit Fehler-Stacking pro Produkt sichtbar bleibt.
Cross-Company-Schutz (Security-Audit gehärtet, v1.7.5)
Ein Security-Audit Anfang Mai 2026 hat sechs Cross-Company-Vektoren in den B2B-Controllern offengelegt: Mitarbeiter aus Firma A konnten unter bestimmten Bedingungen Entities von Firma B referenzieren (Budget-Lookup per Employee-ID, Approval-Lookup per ID, Cost-Center-Filter, Address-Edit, Restriction-Anlage, Role-Detail). Diese sechs Blocker sind in v1.7.5 geschlossen. Kern der Lösung ist ein zentraler Helper `B2bContextService::assertEntityBelongsToOwnCompany`. Jeder Controller, der eine Entity über eine ID aus dem Request lädt, ruft diesen Helper auf — er prüft die Company-ID der geladenen Entity gegen die Company-ID des angemeldeten Mitarbeiters und wirft eine `AccessDeniedHttpException`, wenn sie nicht übereinstimmt. Damit gibt es nur noch eine zentrale Stelle, die Cross-Company-Logik kennt. Die Cart-Add-Permission war zusätzlich über einen statischen Bypass per `Cart::isModified()` umgehbar. v1.7.5 ersetzt das durch eine eigene Cart-Extension `BronnB2bAddItemContext`, die nur für genau einen tatsächlich gerade hinzugefügten LineItem den Bypass markiert — alle anderen LineItems im selben Cart laufen weiterhin durch den vollen Permission-Check. Eine neue Permission `approvals.submit` trennt das Einreichen einer Freigabe vom Entscheiden. Vorher konnten Mitarbeiter mit reiner View-Permission Submit-Events feuern. Die Migration ist idempotent (`bronnColumnExists`, `bronnIndexExists`) und läuft sauber durch, auch wenn Teile davon schon manuell installiert wurden.
Vollständiges Logging + Audit-Trail (v1.7.6 – v1.7.8)
Ab v1.7.6 ist `LoggerInterface` in alle 9 B2B-Controller injiziert. Jeder Controller-Catch landet jetzt im Log statt im Frontend — vorher konnten DAL-Fehler oder Permission-Verletzungen Stack-Traces ans Storefront-DOM durchreichen. Das Pattern ist einheitlich: `try { ... } catch (B2bAccessDeniedException) { audit.warning, redirect } catch (DalException) { logger.info, redirect } catch (Throwable) { logger.error, redirect }`. v1.7.7 erweitert das um den `CrossCompanyAccessAuditLogger`. Jeder gefangene Cross-Company-Versuch wird zunächst mit `WARNING` geloggt, inklusive Customer-ID, Customer-E-Mail, Entity-Typ, Entity-ID, Controller-Action und User-Agent. Damit ist nachvollziehbar, ob ein Mitarbeiter wiederholt versucht, fremde Firmen-Entities anzufassen — das ist ein klares Eskalationssignal. v1.7.8 hebt den Cross-Company-Audit-Logger auf `ERROR`-Level. Hintergrund: Der Shopware-Default-Monolog filtert `WARNING` in vielen Setups standardmäßig weg, sodass kritische Sicherheitsereignisse unsichtbar blieben. Mit `ERROR` landen alle Cross-Company-Versuche garantiert in den Server-Logs und sind in Standard-Log-Tools (z. B. ELK, Sentry) ohne Sonderkonfiguration sichtbar. `requiresApproval` defaultet seit v1.7.6 konservativ auf `true`, wenn das Customer-Datenmodell unvollständig ist (z. B. kein Employee verknüpft, keine Company-ID am Customer). Vorher wurde im Zweifel `false` zurückgegeben — Bestellungen liefen ohne Freigabe durch, obwohl die Datenlage es nicht hergab. Jetzt landen sie sicher im Freigabeprozess, bis das Datenmodell korrekt ist.
Plugin-Konfiguration mehrsprachig sichtbar (v1.7.9)
Die Plugin-Konfiguration im Shopware-Extension-Manager ist ab v1.7.9 vollständig deutsch und englisch sichtbar. Hintergrund: v1.7.6 hatte die Labels von Inline-Texten auf Snippet-Schlüssel umgestellt, weil das saubere i18n-Praxis ist. In der Praxis löst der Shopware-Extension-Manager Snippet-Keys in der Config-View aber nicht zuverlässig auf — Admins sahen leere Felder oder rohe Snippet-Schlüssel. v1.7.9 stellt deshalb auf den Shopware-empfohlenen Weg um: Labels und Helptexte stehen direkt als `<label lang="de-DE">…</label>` und `<label lang="en-GB">…</label>` in der `config.xml`. Damit sieht jeder Admin sofort, was die Konfigurationsoptionen tun — egal in welcher Sprache und ohne Snippet-Pfad-Magie. Storefront-Snippets bleiben unverändert über das Snippet-System lokalisiert.
Type-Safe API durch BackedEnums (v1.8.0)
Mit v1.8.0 wurde die komplette interne API auf PHP-BackedEnums umgestellt. Vier zentrale Enums machen die Plugin-Logik typsicher: `B2bPermission` listet alle erlaubten Permission-Strings (z. B. `shop.purchase`, `approvals.submit`, `approvals.decide`) und ist die einzige Quelle, aus der Permissions referenziert werden dürfen. `BudgetPeriod` enthält `monthly`, `quarterly`, `yearly` — keine willkürlichen Strings mehr in Migrationen oder Repositories. `ApprovalStatus` listet `pending`, `approved`, `rejected`, `withdrawn` typsicher; jeder State-Übergang ist gegen den Enum abgesichert. `RestrictionType` unterscheidet `product` und `category` für Produkt-Restriktionen. Der Vorteil: Tippfehler in Strings kann es nicht mehr geben — der PHP-Compiler und statische Analyse-Tools (PHPStan/Psalm) fangen jeden Mismatch beim Code-Schreiben ab, bevor er in Produktion auftaucht. Refactorings wie "eine Permission umbenennen" sind jetzt safe: man ändert den Enum-Case einmal und der Compiler zeigt jeden Aufrufer, der angepasst werden muss. Legacy-Bridge ohne Breaking-Changes: Bestehende Datensätze aus der Datenbank (z. B. alte `permission`-Strings in `bronn_b2b_role_permission`) werden über eine Bridge transparent in den Enum-Wert gemappt. Plugins, die noch mit String-Werten arbeiten (z. B. ältere Custom-Erweiterungen), bleiben kompatibel. Es gibt keine Migration, die Daten zerstört.
Unique-Indizes verhindern Duplikate (v1.8.0)
Zwei Datenbank-Unique-Indizes schließen Race-Conditions, die früher zu Duplikaten führen konnten. Erster Index: `permission` ist pro Rolle nur noch einmal vergebbar. Vorher konnte unter ungünstigen Bedingungen (zwei gleichzeitige API-Calls, manuelles SQL-Editing) eine Rolle die gleiche Permission doppelt zugewiesen bekommen — das verwirrte die Permission-Logik, weil DELETE-Statements nur den ersten Eintrag erwischten. Zweiter Index: Ein Mitarbeiter kann pro Cost-Center nur noch einmal verknüpft sein. Vorher konnten Bulk-Imports oder Sync-Skripte denselben Employee mehrfach im selben Cost-Center anlegen, was Budget-Berechnungen verfälschte. Die Migrations laufen idempotent: bestehende Duplikate werden vor der Index-Anlage automatisch deduziert (DELETE über Self-JOIN, behält den ältesten Eintrag). Sollte die Migration auf einem Shop laufen, der manuell schon Duplikate hatte, werden sie sauber konsolidiert. Anschließend verhindert der Unique-Index neue Duplikate auf Datenbankebene — auch wenn Plugin-Code Bugs hätte.
XOR-Validatoren erzwingen saubere Datenmodelle (v1.8.0 / v1.8.1)
Zwei XOR-Validatoren machen unklare Datenkombinationen unmöglich. Erster Validator: Ein Budget gehört entweder zu einer Abteilung ODER zu einem Cost-Center — niemals beidem. Vorher konnte ein Admin versehentlich ein Budget mit beiden Referenzen anlegen, und die Budget-Aggregation in der Approval-Logik kannte die korrekte Berechnung nicht. Zweiter Validator: Eine Product-Restriction filtert entweder über Produkt-IDs ODER über Kategorien — niemals gleichzeitig. Vorher konnten beide Felder befüllt sein, und die Filter-Logik im StoreApi-Loader hat eine der beiden Listen stillschweigend ignoriert. Die XOR-Prüfung läuft vor dem Persist und wirft eine `WriteConstraintViolationException`. In v1.8.0 wurde im UI ein generischer `businessError`-Flash gezeigt, der dem Admin nicht klar gemacht hat, welche XOR-Regel verletzt war. v1.8.1 ist der UX-Hotfix dafür: Der XOR-Check wandert vor den try-Block, und das Plugin zeigt spezifische, übersetzte Snippet-Texte an — `bronnB2b.budget.xor.violation` mit klarem Hinweis "Bitte entweder Abteilung ODER Cost-Center wählen, nicht beides", `bronnB2b.productRestriction.xor.violation` analog für Produkte vs. Kategorien. Admins verstehen sofort, welche Regel sie verletzt haben und wie sie sie reparieren.
Was ohne ein B2B-Plugin passiert
Die Shopware-Standardfunktionen decken B2C ab. B2B-Kunden erwarten aber, dass ihre Firmenstruktur im Shop abgebildet ist, dass Mitarbeiter nur das sehen und tun dürfen, was sie sollen, und dass Bestellungen nicht ohne Freigabe rausgehen. Ohne ein Plugin wie die B2B Plattform baust du dir das selbst zusammen oder du lebst mit Workarounds. Selbst bauen ist teuer und wartungsintensiv. Workarounds halten bis zur nächsten Beschwerde.
Typische Einsätze
Großhändler für Industriebedarf
Ein Großhändler für Industriebedarf hat 200 Firmenkunden. Jeder Firmenkunde verwaltet seine Mitarbeiter, Rollen und Budgets selbst. Einkäufer bestellen, Abteilungsleiter geben frei. Der Supportaufwand beim Großhändler sinkt, weil 90% der Verwaltungsarbeit beim Kunden liegt.
Hersteller von Elektrokomponenten
Ein Hersteller von Elektrokomponenten verkauft an Handwerker, Planer und Fachhändler. Jede Kundengruppe hat eigene Rollen und Preise. Die B2B Plattform steuert, wer was sieht und was bestellen darf, ohne dass der Vertrieb jedes Mal manuell eingreifen muss.
Zentrale Bestellplattform
Ein Shopware-Shop, der als zentrale Bestellplattform für mehrere Unternehmen dient. Die B2B Plattform trennt die Firmen sauber über eigene Konten, Rollen und Berechtigungen.
Wann brauche ich das?
Echte B2B-Szenarien, in denen dieses Plugin den Unterschied macht.
Distributor mit komplexen Abnahmehierarchien
Ein Distributor beliefert 300 Firmenkunden, von denen jeder eigene Einkäufer, Abteilungsleiter und Budgetverantwortliche hat. Die B2B Plattform bildet diese Struktur direkt im Shopware-Shop ab. Einkäufer befüllen den Warenkorb, Abteilungsleiter geben frei, Freigaben laufen automatisch — ohne ein einziges E-Mail oder Telefonat.
Großhändler mit individuellen Kundengruppen-Preisen
Drei Händlerklassen, drei Preisebenen: Stammhändler, Fachpartner und Gelegenheitskäufer sehen verschiedene Preise und haben unterschiedliche Bestelllimits. Die B2B Plattform steuert das über Rollen und Berechtigungen — ohne manuelle Eingriffe des Vertriebs.
Lieferant mit mehrstufiger Freigabe
Bestellungen über 1.000 Euro müssen vom Einkaufsleiter genehmigt werden. Über 5.000 Euro braucht der Geschäftsführer sein Okay. Die B2B Plattform bildet diesen mehrstufigen Freigabeprozess ab — vollautomatisch, dokumentiert und ohne Medienbrüche.
Die Vorteile
- Selbstverwaltung durch den Firmenkunden
- Automatische Freigabeprozesse
- Reduzierter Supportaufwand
- Budgetkontrolle in Echtzeit
- Skalierbar für hunderte Firmenkunden
- Firmenadressen direkt im Checkout auswählbar (v1.5.0)
- Permission shop.purchase (konsolidiert) — Preise sehen und Cart-Add gemeinsam (v1.7.0)
- Adress-UI komplett B2B-konform für Mitarbeiter (v1.6.0)
- Cart-Sperre konsistent mit Preis-Sicht — kein "In den Warenkorb" ohne Preisrecht (v1.5.2)
- Cross-Company-Schutz (Security-Audit gehärtet, v1.7.5)
- Vollständiges Logging + Audit-Trail (v1.7.6 – v1.7.8)
- Konservativer Approval-Default für unvollständige Datenmodelle (v1.7.6)
- Audit-Logs als ERROR-Events sichtbar (v1.7.8)
- Plugin-Konfiguration vollständig deutsch + englisch im Extension-Manager (v1.7.9)
- Type-Safe API durch BackedEnums (v1.8.0)
- Unique-Indizes verhindern Duplikate (v1.8.0)
- XOR-Validatoren erzwingen saubere Datenmodelle (v1.8.0)
- Spezifische, übersetzte Fehlermeldungen bei XOR-Verletzungen (v1.8.1)
Häufige Fragen
Funktioniert die B2B Plattform mit Shopware 6.6 und 6.7?
Ja, die Bronner B2B Plattform unterstützt Shopware 6.6 und 6.7. Alle Versionen ab 6.6 werden aktiv gepflegt.
Kann ich die Anzahl der Mitarbeiter pro Firma begrenzen?
Ja, in der Plugin-Konfiguration lässt sich eine maximale Mitarbeiteranzahl pro Firma festlegen. Der Wert 0 steht für unbegrenzt.
Wie funktionieren Budgets und Freigabeprozesse?
Du setzt Budgets pro Mitarbeiter, Abteilung oder Firma. Überschreitet eine Bestellung das Budget, wird sie automatisch zur Freigabe an den Vorgesetzten geleitet. Dieser gibt per Klick frei oder lehnt ab.
Wie wähle ich eine Firmenadresse im Checkout aus?
Ab v1.5.0 stehen auf der Bestellbestätigungsseite zwei Dropdowns bereit: „Firmenadresse als Lieferadresse" und „Firmenadresse als Rechnungsadresse". Wähle die gewünschte Firmenadresse, bestätige per Button — die Adresse wird in das persönliche Adressbuch kopiert und sofort als aktive Liefer- bzw. Rechnungsadresse gesetzt. Der bestehende Adopt-Workflow im Account-Bereich bleibt zusätzlich verfügbar. Die zugehörige Route ist POST-only und CSRF-geschützt.
Warum sehe ich als Firmen-Inhaber den Menüpunkt „Firmenadressen" jetzt zuverlässig?
In den Versionen 1.4.x fehlten dem Owner-Account synthetische Permissions für das Adressen-Modul, deshalb war der Menüpunkt unsichtbar. Ab v1.5.0 injiziert der `AccountMenuSubscriber` die Owner-Permissions vollständig — der Menüpunkt erscheint wieder zuverlässig im Storefront-Account.
Lässt sich die B2B Plattform mit anderen Bronner Plugins kombinieren?
Ja. Die B2B Plattform ist das Kernelement der Bronner B2B Suite. Sie lässt sich mit Bestelllisten, Angebotsanfragen, Preise ausblenden und weiteren Modulen kombinieren.
Kann ein Firmenkunde seine eigene Unternehmensstruktur selbst verwalten?
Ja. Firmenkunden verwalten Mitarbeiter, Abteilungen und Rollen eigenständig im Kundenkonto. Kein Support-Ticket beim Shopbetreiber nötig. Das reduziert den Administrationsaufwand erheblich.
Gibt es eine maximale Anzahl an Firmenkonten oder Mitarbeitern?
Nein. Das Plugin skaliert mit deinem Shop. Ob 20 oder 2.000 Firmenkunden mit jeweils 50 Mitarbeitern – es gibt keine technische Begrenzung.
Ist eine kostenlose Demo möglich?
Ja, eine persönliche Demo kann über das Kontaktformular auf bronner-b2b.de angefordert werden.
Warum kann mein Mitarbeiter ohne Preis-Sicht nichts in den Warenkorb legen?
Seit v1.7.0 gibt es nur noch die konsolidierte Permission `shop.purchase`. Sie umfasst beides: Preise sehen UND Produkte in den Warenkorb legen. Fachlich gehört das zusammen — wer keinen Preis sieht, kann nicht sinnvoll einkaufen, und Preis-Sicht ohne Kaufmöglichkeit ergibt im B2B kaum einen Anwendungsfall. Vergeben Sie der Rolle Ihres Mitarbeiters `shop.purchase`, dann hat er beide Fähigkeiten gleichzeitig. Der `CartAddPermissionSubscriber` prüft die Permission konsistent in Frontend, Backend und Cart-Summary.
Was ist mit dem alten `cart.add` bei meinen Rollen passiert?
Die Migration `Migration1762000000MergeCartAndPriceViewPermissions` läuft beim Update auf v1.7.0 automatisch und hebt bestehende Rollen an: Jede Rolle, die vorher `cart.add` ODER `product.view_prices` (oder beide) hatte, bekommt jetzt `shop.purchase`. Die alten Permission-Strings werden aus `bronn_b2b_permission` entfernt. Sie müssen nichts manuell anpassen. Ab v1.7.1 läuft die Migration als Batch-INSERT-SELECT — Sekunden statt Minuten Laufzeit, auch bei großen Rollen-Beständen.
Welche Audit-Spuren liefert das Plugin?
Ab v1.7.6 schreibt das Plugin in den Symfony-Logger über `LoggerInterface`. Drei Signal-Stufen sind relevant: `WARNING` wird gefeuert, wenn ein Mitarbeiter versucht, auf eine Entity einer fremden Firma zuzugreifen (Customer-ID, Customer-E-Mail, Entity-Typ, Entity-ID und Controller-Action stehen im Log) — das ist ein klares Eskalationssignal und wird seit v1.7.7 vom `CrossCompanyAccessAuditLogger` in 9 Controller-Catches einheitlich erzeugt. `INFO` deckt erwartbare DAL-Fehler ab, etwa wenn eine referenzierte Entity nicht gefunden wird. `DEBUG` zeigt Approval-Linking-Details — z. B. welcher Cart welcher Freigabeanfrage zugeordnet wurde. Damit lässt sich im Nachhinein lückenlos nachvollziehen, wer wann was versucht hat und wo das System gegriffen hat. Die Logs landen im Standard-Symfony-Log-Verzeichnis und können per Filter `b2b` ausgewertet werden.
Passende Plugins
Kombiniere für maximale Wirkung.
Bestelllisten
Wiederkehrende Bestellungen als Listen speichern und nachbestellen
Angebotsanfragen
Individuelle Preise direkt aus dem Warenkorb anfragen
Preise ausblenden
Preise nur für registrierte oder freigeschaltete Kunden
Mindermengenzuschlag
Automatische Zuschläge mit Staffelung, Fortschrittsanzeige und Kundengruppen-Steuerung
Preishistorie
Preisverlauf der letzten 6 Monate als Diagramm auf der Produktdetailseite
Bronn B2B-Plattform testen
Fordere eine kostenlose Demo-Umgebung an. Alle Plugins vorinstalliert, voller Funktionsumfang.