Dein erster EDI-Partner war einfach. Der zweite kostet das Projekt

Architektonisch ja, in der Konfiguration nein. Plugin-Code arbeitet immer mit einem Mandanten-Kontext, das aktive Setup hat aber nur einen Mandanten. Damit kostet Multi-Tenant in Phase 1 fast nichts und der zweite Partner ist später Setup statt Refactoring. Wir machen das so, weil der zweite Partner fast immer schneller kommt, als geplant.

Mit Playbook und sauberer Architektur eine knappe Sprint-Hälfte für die Standard-Variante. Wenn der Partner ein eigenes Sub-Format mit Quirks hat, zwei Sprints. Ohne Playbook und ohne Multi-Tenant-Architektur landest du zurück bei zwei bis drei Sprints, jedesmal aufs Neue.

Saubere Trennung in der Architektur. Der Parser ist austauschbar, das Mapping ins Shopware-Datenmodell läuft aber zentral. Ein XML- oder CSV-Partner kriegt einen eigenen Parser, mappt aber auf dieselben internen Strukturen. Damit bleibt der Folgepfad einheitlich, nur das Eingangs-Format ändert sich.

Sandbox-Mandant. Jeder neue Partner startet mit einem Mandanten-Setup, das nur in der Sandbox aktiv ist. SFTP-Pfade, Mapping-Tabellen, Test-Dateien laufen dort durch das gleiche Plugin wie produktiv. Erst nach Sign-Off durch Operations wird der Mandant live geschaltet. Wechsel ist ein Flag, kein Deploy.

Beides funktioniert, hat aber unterschiedliche Konsequenzen. Plugin lebt im Shopware-Lebenszyklus, profitiert von Auth, Custom-Fields, Backoffice-UI und ist deploybar wie alles andere. Middleware ist Stand-Alone, oft sinnvoll, wenn EDI auch ohne Shopware laufen muss, also etwa bei mehreren Shop-Systemen oder reiner ERP-Anbindung. Wir empfehlen Plugin, solange EDI ausschließlich in Shopware landet.