ERP-Integration, die die Mode-Komplexität meistert

Im Fashion-Segment unterscheidet sich die Datenstruktur grundlegend von anderen Branchen. Ein Basisartikel, im ERP oft als Modell oder Style bezeichnet, ist keine eigenständige Bestelleinheit. Er ist ein Container für eine Variantenmatrix aus Farbe und Größe. Während ein Werkzeughändler einen Schraubenzieher mit einer EAN und einem Bestand führt, verwaltet ein Modehändler dieselbe Position als 48 einzelne SKUs, von denen jede separat bestellt, geliefert und verkauft wird. Diese Grundstruktur muss die Schnittstelle korrekt abbilden.

Dazu kommen saisonale Zyklen: Frühjahr/Sommer und Herbst/Winter wechseln sich ab, Carry-over-Artikel bleiben über mehrere Saisons, Sale-Phasen aktivieren gestaffelte Preisreduktionen und Pre-Order-Fenster erlauben Bestellungen auf Ware, die noch nicht im Lager ist. Jede dieser Phasen hat eigene Regeln für Sichtbarkeit, Preis und Verfügbarkeit, die aus dem ERP gesteuert und im Shop umgesetzt werden müssen. Hinzu kommen oft mehrere Vertriebskanäle: der eigene Shop, Marketplace-Anbindungen und das stationäre Geschäft müssen denselben Bestand teilen, ohne Überverkäufe zu riskieren.

Das zentrale Datenproblem im Modehandel ist die Variantenmatrix. Ein Basis-Style wird im ERP mit Farboptionen und einer Größentabelle angelegt. Die Größentabelle folgt je nach Produktkategorie unterschiedlichen Normierungen: Konfektionsgrößen für Oberbekleidung (XS bis 4XL oder 34 bis 52), Schuhgrößen in EU, UK und US, Ringgrößen in Millimetern oder Hosen mit Taille und Schrittlänge. Diese strukturellen Unterschiede muss die Schnittstelle kennen und korrekt in das Shop-Variantenmodell übersetzen.

Wir implementieren einen Variantenimporter, der die Style-Strukturen aus Ihrem Fashion-ERP liest und in das Variantensystem von Shopware CE überführt. Farbvarianten werden als übergeordnete Gruppenoption angelegt, Größenvarianten als untergeordnete Option. Jede resultierende SKU erhält ihre eigene EAN aus dem ERP, ihre eigene Bestandszahl und, wenn das Preismodell es vorsieht, einen eigenständigen Preis. Produktbilder werden der Farbvariante zugeordnet, damit der Shop beim Farbwechsel automatisch das korrekte Bild anzeigt, ohne erneuten Import-Trigger.

Die Modebranche lebt von Saisonalität. Zweimal pro Jahr wird ein großer Teil des Sortiments ausgetauscht. Neue Kollektionen werden Wochen vor dem Launch im ERP angelegt und gepflegt, damit Einkauf, Lager und Vertrieb vorbereitet sind. Der Shop soll die neue Kollektion erst zum definierten Launch-Datum zeigen, nicht bereits wenn der Datensatz im ERP angelegt wird. Auslaufartikel sollen bis zur vollständigen Ausverkauf-Phase sichtbar bleiben und dann ohne manuellen Eingriff deaktiviert werden.

Wir implementieren eine Saison-Steuerungsschicht in der Middleware, die Kollektion-Daten und Aktivierungsdaten aus dem ERP liest und den Shop-Import entsprechend steuert. Neue Saison-Artikel werden vorbereitet importiert und im Shop auf "nicht sichtbar" gesetzt, bis das definierte Erscheinungsdatum erreicht ist. Carry-over-Artikel, die von einer Saison in die nächste übernommen werden, behalten ihre Produktseiten und Produktbewertungen. Sale-Artikel erhalten die Preisreduktionen zum definierten Sale-Start automatisch aus dem ERP, ohne dass im Shop manuell eingegriffen werden muss.

Im Modehandel ist Bestandsgenauigkeit besonders kritisch, weil die Sortimentstiefe hoch und die Mengen je SKU oft gering sind. Ein Oberteil in Größe S, Farbe Dunkelblau, hat vielleicht nur drei Stück auf Lager. Wenn eine davon in der Filiale verkauft wird, eine im Shop bestellt und eine im Lager reserviert ist, ist die Verfügbarkeit im Shop sofort erschöpft. Die Warenwirtschafts-Anbindung muss diese feingranulare Bestandssituation in Echtzeit reflektieren, da bereits ein einziger Überverkauf Folgekosten durch Stornierung, Rückabwicklung und Kundenkommunikation auslöst.

Wir implementieren Event-basierte Bestandssynchronisation, die auf jede Lagerveränderung sofort reagiert. Wareneingang, Kommissionierung, Filialabgang und Retoure lösen jeweils einen Sync-Trigger aus, der den Shop-Bestand der betroffenen SKU aktualisiert. Eine kanalübergreifende Reservierungslogik blockiert Bestände bereits bei der Warenkorbanlage, nicht erst bei Bestellabschluss. So wird derselbe Bestandspool sicher zwischen Online-Shop, Ladengeschäft und Marktplatzkanälen geteilt, ohne Überverkaufs-Risiko. Für saisonale Spitzenzeiten, wie den Saisonstart oder Sale-Phasen, ist die Synchronisation auf erhöhte Last ausgelegt.

Preismanagement im Modehandel unterscheidet sich durch seine Zeitdimension von anderen Branchen. Ein Artikel hat einen Einstiegspreis zum Kollektionsstart, einen Aktionspreis nach einigen Wochen, einen Sale-Preis zum Ausverkauf und möglicherweise einen Clearance-Preis am Ende der Saison. Diese Preisentwicklung wird im ERP geplant und muss automatisch in den Shop übertragen werden, ohne dass das Redaktionsteam bei jedem Preisschritt manuell eingreift.

Unsere Preis-Middleware liest den Preisplan je Artikel aus dem ERP und synchronisiert Preisänderungen zum definierten Datum. Streichpreise (ehemaliger UVP) werden als Referenzpreis übernommen und korrekt als historischer Vergleichswert dargestellt, im Einklang mit den preisrechtlichen Vorgaben der aktuellen Rechtslage zu Preisangaben und Streichpreisen. Staffelpreise für Händler-B2B-Kanäle, Mengenrabatte und kundengruppenspezifische Konditionen werden gleichzeitig in der richtigen Hierarchie synchronisiert. Über API-Schnittstellen kann die Preissteuerung auch an externe Pricing-Systeme oder Revenue-Management-Tools angebunden werden.

Die Modebranche setzt auf spezialisierte ERP-Systeme, die die Branchenstruktur mit Kollektionen, Saisons, Styles und Varianten nativ abbilden. Häufig begegnen uns Systeme wie Microsoft Dynamics 365 in Verbindung mit Fashion-Add-ons, JTL-Wawi mit Varianten-Management-Erweiterungen oder branchenspezifische Lösungen. Für die buchhalterische Anbindung über DATEV ist die Shop-ERP-Integration oft mit einer separaten Belegfluss-Integration kombiniert.

Unabhängig vom eingesetzten ERP-System analysieren wir die verfügbaren Schnittstellen und entwickeln den optimalen Integrationsweg. Moderne Fashion-ERPs bieten REST-APIs mit Varianten-Endpunkten. Ältere Systeme kommunizieren über CSV-Exporte oder proprietäre Flatfile-Formate. Für letztere entwickeln wir Transformer-Komponenten, die das Ausgangsformat in unser einheitliches Integrations-Datenmodell überführen, sodass die Shop-seitige Logik immer mit derselben Schnittstelle kommuniziert, unabhängig davon, was auf der ERP-Seite liegt. Auch die Anbindung von JTL-Warenwirtschaft und Marktplatz-Kanälen lässt sich in diese Architektur einbinden.

Die Modebranchen-Retourenquote liegt im deutschen E-Commerce bei bis zu 50 Prozent (Handelsverband Deutschland) — deutlich höher als in anderen Segmenten. Jede Retoure muss zurück in den Shop-Bestand fließen, wenn die Ware einwandfrei ist, oder als unverkäuflich ausgebucht werden, wenn sie beschädigt ist. Diese Retouren-Logik muss zwischen Shop, ERP und Logistik-Dienstleister synchronisiert sein, damit die Bestandszahlen zu jeder Zeit korrekt sind und keine fälschlicherweise nicht mehr verfügbaren Artikel im Shop gesperrt bleiben.

Unsere Integrations-Middleware implementiert einen Retouren-Workflow, der den Retourenstatus aus dem ERP oder dem Lagerverwaltungssystem liest und den Shop-Bestand entsprechend aktualisiert. Eingehende Retouren, die als neuwertig eingestuft werden, erhöhen den Shop-Bestand automatisch. Beschädigte oder nicht wiederverkäufliche Teile werden ausgebucht ohne Bestandserhöhung. Gutschriften fließen aus dem ERP an den Shop und lösen dort die Kundenbenachrichtigung aus. So bleibt der gesamte Rückfluss transparent und der Bestand korrekt, auch in retourenintensiven Nachsaison-Phasen.