Shopware 6 & PIM: Produktdaten sauber anbinden statt manuell pflegen

Die meisten Shopware-Projekte starten mit einer vernünftigen Entscheidung: Die Produktdaten werden direkt im Shop gepflegt. Für einen Kanal, eine Sprache und ein überschaubares Sortiment ist das genau richtig. Zwei Jahre später sieht es anders aus. Dazu kommen ein Marktplatz, ein zweites Land, ein Händlerportal und ein Katalog. Wer dann noch „einfach im Shop pflegt“, pflegt in Wahrheit an fünf Stellen gleichzeitig.

Unsere These: Shopware 6 ist ein hervorragendes Verkaufs- und Ausspielsystem, aber kein Redaktionssystem für Produktdaten über mehrere Kanäle. Sobald mehr als ein Kanal an denselben Daten hängt, gehört die Pflege in ein PIM als Single Source of Truth. Shopware bekommt die Daten dann sauber, automatisch und nur mit den Änderungen geliefert. Du pflegst einmal und spielst überall aus.

Hier bekommst du eine faire Einordnung der Shopware-Bordmittel, eine Referenzarchitektur, eine Feld-Mapping-Tabelle mit den echten Shopware-Feldern, den Anbindungsprozess in sieben Schritten und eine Readiness-Checkliste.

Warum Shopware-Bordmittel an Grenzen stoßen

Zuerst die ehrliche Seite: Shopware 6 bringt für Produktdaten eine Menge mit. Wer das kleinredet, verkauft dir ein PIM aus den falschen Gründen.

• Eigenschaften und Varianten. Filterbare Merkmale legst du als Eigenschaften an. Variantenbildende Merkmale wie Farbe oder Größe werden zu Optionen, aus denen Shopware Varianten erzeugt. Varianten sind Kind-Produkte und erben nicht gepflegte Werte vom Hauptprodukt.
• Zusatzfelder. Für alles, was das Standardmodell nicht abdeckt, gibt es Zusatzfelder (Custom Fields) mit Typen wie Text, Zahl, Datum, Auswahl oder Medium.
• Mehrsprachigkeit und Verkaufskanäle. Sprachen können voneinander erben, und Produkte lassen sich je Verkaufskanal (Sales Channel) sichtbar schalten.
• Import/Export. Das Modul importiert CSV-Dateien über Profile, die festlegen, welche Spalte in welchem Feld landet. Es bietet einen Testlauf und eine Fehlerdatei mit den fehlerhaften Datensätzen.
• KI-Unterstützung. Ab dem Rise-Plan enthält Shopware KI-Funktionen (Shopware Intelligence, in der Doku als AI Copilot geführt), die unter anderem Produktbeschreibungen formulieren und Eigenschaften aus einem Beschreibungstext vorschlagen.

Für einen Shop als einzigen Kanal reicht das oft. Die Grenzen liegen nicht in einer einzelnen Funktion, sondern im Zweck des Systems: Shopware ist gebaut, um Produkte zu verkaufen und auszuspielen, nicht als Redaktionssystem, in dem Produktdaten für viele Abnehmer angereichert und freigegeben werden. Typische Reibungspunkte:

• Die Daten sind auf den Shop zugeschnitten. Shopware kann über Verkaufskanäle vom Typ Produktvergleich Feeds an Preisportale ausleiten und mit Multichannel Connect Marktplätze anbinden (eigenes Zusatzangebot). Printkatalog, Händlerportal oder Datenlieferungen an Handelspartner brauchen dieselben Daten aber oft in anderer Struktur. Ohne zentrale Quelle außerhalb des Shops entstehen Kopien, und Kopien laufen auseinander.
• CSV-Importe sind Handarbeit mit Tücken. Jemand muss die Datei erzeugen, hochladen und die Fehlerdatei abarbeiten. Laut Shopware-Dokumentation ergänzt ein Import Informationen nur, entfernt aber keine. Eine bestehende Sales-Channel-Zuordnung lässt sich per Import zum Beispiel nicht aufheben.
• Lieferantendaten kommen roh an. Formate, Einheiten und Schreibweisen von Zulieferern müssen vereinheitlicht werden, bevor sie in den Shop dürfen.
• Viele Hände, keine Freigabe. Produktmanagement, Marketing, Übersetzung und Technik arbeiten an denselben Artikeln. Ohne Statusmodell und Verantwortliche je Attributgruppe weiß niemand, welcher Stand verkaufsfertig ist.
• Übersetzungen fallen leise zurück. Die Sprachvererbung ist praktisch. Fehlt eine Übersetzung, zeigt der Shop ohne Hinweis den Text der geerbten Sprache. Im Admin erkennst du die Lücke an grau dargestellten Werten, allerdings Feld für Feld und Artikel für Artikel.

Ob diese Punkte schmerzen, ist keine Frage der Shopgröße, sondern der Kanalzahl. Die Grundsatzfrage klären wir in Braucht es neben dem Online-Shop überhaupt noch ein PIM?, den B2B-Blick mit Kundengruppen und Preislogik in Shopware für B2B.

Architektur: PIM → Shopware

Die saubere Anbindung folgt einem einfachen Prinzip: Jede Datenart hat genau ein führendes System, und die Daten fließen nur in eine Richtung. Für Produktdaten sieht die Kette so aus:

Quellen (ERP, Lieferanten, Fotografie, Übersetzung) → PIM (Pflege, Anreicherung, Prüfung, Freigabe) → Integrationsschicht (Mapping, Transformation, Delta, Fehlerbehandlung) → Shopware 6 (Admin API) → Storefront und weitere Sales Channels

Entscheidend ist die mittlere Ebene: Sie übersetzt zwischen PIM-Datenmodell und Shopware-Datenmodell. Technisch schreibt sie über die Admin API, die Shopware ausdrücklich für Backend-Integrationen und Datensynchronisation vorsieht. Für größere Datenmengen bündelt die Sync API viele Schreibvorgänge und verschiedene Entitäten in einem Request.

Wer ist führend? Die Datenhoheit

Der häufigste Fehler in Anbindungsprojekten ist organisatorisch: Zwei Systeme halten sich für führend bei denselben Feldern. Kläre deshalb vor jeder Zeile Code, wer was besitzt. Die folgende Aufteilung ist ein bewährtes Muster, keine Pflicht.

Drei Wege, die Brücke zu bauen

Für die Integrationsschicht gibt es drei gängige Varianten. Keine ist grundsätzlich besser.

1. Fertiger Konnektor aus dem Shopware Store. Für verbreitete PIM-Systeme gibt es Erweiterungen. Schnell startklar, wenn dein Datenmodell nah am Standard liegt; je nach Konnektor stößt du bei individuellen Feldern, Sonderlogik oder mehreren Zielsystemen an Grenzen.
2. Middleware zwischen den Systemen. Eine Datendrehscheibe übernimmt Mapping, Transformation, Delta-Erkennung und Fehlerbehandlung und kann weitere Systeme bedienen. Robust bei komplexen Landschaften, braucht aber Betrieb und Monitoring.
3. Individuelle Integration gegen die Admin API. Maximale Freiheit, aber Fehlerbehandlung, Wiederholungslogik und Protokollierung baust du selbst. Sinnvoll, wenn es schon ein Integrationsteam gibt.

Wie das Ausleiten an viele Kanäle grundsätzlich funktioniert, beschreiben wir in Syndizierung von Produktdaten.

Feld-Mapping: vom PIM-Attribut zum Shopware-Feld

Das Mapping ist das Herzstück der Anbindung. Die Tabelle zeigt die zentralen Felder des Shopware-6-Produkts, mit Admin-Bezeichnung und technischem Namen aus der Admin API. Fünf Felder sind beim Anlegen eines Produkts Pflicht: Name, Produktnummer, Steuersatz, Preis und Bestand.

Die wichtigste Mapping-Entscheidung betrifft die mittleren Zeilen: Eigenschaft, Option oder Zusatzfeld? Als Faustregel gilt: Was deine Kundschaft auswählt, ist eine Option. Was sie filtert oder vergleicht, ist eine Eigenschaft. Was sie nur liest, gehört in ein Zusatzfeld. Wer jedes technische Merkmal als Eigenschaft anlegt, bläht Filter und Varianten-Logik auf. Wer alles in Zusatzfelder schiebt, verliert die Filterbarkeit.

Der Anbindungs-Prozess in 7 Schritten

Ein Anbindungsprojekt folgt fast immer derselben Reihenfolge. Ein übersprungener Schritt rächt sich spätestens beim ersten Delta-Lauf.

1. Datenhoheit festlegen. Schreibe für jede Datenart das führende System auf (siehe Tabelle oben) und stimme es mit ERP-, Shop- und Produktteam ab.
2. Datenmodell in Shopware entscheiden. Lege fest, welche Merkmale Eigenschaften, Optionen oder Zusatzfelder werden, welche Sprachen und Sales Channels bespielt werden und wie Varianten aufgebaut sind.
3. Mapping spezifizieren. Jedes PIM-Attribut bekommt ein Zielfeld, eine Transformationsregel (Einheit, Format, Werteliste) und eine Regel für leere Werte.
4. Schlüssel und Identitäten klären. Die Produktnummer ist der fachliche Schlüssel. Dazu kommt die Frage, wie Medien, Eigenschaftswerte und Kategorien eindeutig wiedererkannt werden, damit ein zweiter Lauf aktualisiert statt dupliziert.
5. Initialbefüllung durchführen. Der erste Volllauf überträgt den gesamten Bestand. Bei großen Datenmengen lässt sich die Indexierung laut Shopware-Dokumentation in den Hintergrund verlagern oder abschalten, damit der Import den Server nicht ausbremst. Schaltest du sie ganz ab, plane danach einen vollständigen Indexlauf ein. Verlagerst du sie in den Hintergrund, muss die Message Queue die Indexierung abarbeiten, bevor der Shop den neuen Stand zeigt.
6. Delta-Synchronisation und Fehlerbehandlung aufsetzen. Im Betrieb werden nur Änderungen übertragen. Fehlgeschlagene Datensätze werden protokolliert und erneut versucht, und jemand ist zuständig, das Protokoll zu lesen.
7. Abnahme mit Kennzahlen. Prüfe vor dem Go-live stichprobenartig und automatisiert: Sind alle Pflichtfelder je Kanal gefüllt? Stimmen Varianten, Bilder und Übersetzungen? Laufen Delta-Änderungen innerhalb des vereinbarten Zeitfensters im Shop an?

Checkliste: Bist du bereit für die Anbindung?

• ☐ Für jede Datenart ist das führende System schriftlich festgelegt.
• ☐ Die Artikelnummer ist eindeutig, stabil und in PIM, ERP und Shop identisch.
• ☐ Pflichtfelder sind je Kanal und je Sprache definiert.
• ☐ Die Aufteilung in Eigenschaften, Optionen und Zusatzfelder ist entschieden.
• ☐ Wertelisten für filterbare Merkmale sind gepflegt, nicht als Freitext angelegt.
• ☐ Bilder haben eine feste Reihenfolge und ein definiertes Coverbild.
• ☐ Es gibt eine Mapping-Spezifikation mit Transformations- und Leerwert-Regeln.
• ☐ Fehlerprotokoll, Wiederholungslogik und eine verantwortliche Person sind benannt.
• ☐ Die Initialbefüllung ist mit einem Testlauf auf einer Staging-Umgebung erprobt.

Fehlen dir mehr als drei Häkchen, liegt die Arbeit zuerst im Datenmodell, nicht in der Schnittstelle. Welche Anforderungen von deiner Rolle in der Lieferkette abhängen, liest du in PIM-System: Hersteller vs. Händler; vor der Systemwahl hilft der PIM-Software-Vergleich.

Was die apollon Shopware-Agentur übernimmt

Viele Anbindungsprojekte haben ein strukturelles Problem: PIM-Anbieter und Shop-Agentur sind zwei Dienstleister mit zwei Zeitplänen und einer Schnittstelle dazwischen, für die sich im Zweifel keiner verantwortlich fühlt.

apollon ist beides: PIM-Hersteller mit Online Media Net (OMN) und offizieller Shopware-Partner. Deshalb kommen Produktdaten-Plattform, Anbindung und Shop bei uns aus einer Hand:

• Eigenentwickelte Middleware zwischen OMN und Shopware 6. Sie synchronisiert Produktdaten, Kategorien, Medien und Preise.
• Delta-Exporte. Übertragen werden nur geänderte Daten.
• Konfigurierbares Feldmapping zwischen OMN und Shopware, dazu Unterstützung für Custom Fields und Sales Channels.
• Fehlerprotokollierung und automatische Wiederholung, damit nichts unbemerkt liegen bleibt.
• Shop-Entwicklung, Migration und ERP-Anbindung vom selben Team, damit die PIM-Anbindung von Anfang an mitgeplant ist.

So sieht das in Kundenprojekten aus:

• Compass und SEALAND24: Relaunch der Online-Shops auf Shopware 6 mit neuem Design; die Produktinformationen kommen aus OMN, die Shops sind an PIM und ERP angebunden (Success Story).
• Egle: Der bestehende Shopware-Shop wird aus OMN mit Produktinformationen, digitalen Assets und aktuellen Preisen versorgt; wir entwickeln den Shop weiter und binden ERP und OMN an (Success Story).
• Börlind: Über eine direkte Anbindung an Shopware 6 fließen die Produktdaten aus OMN automatisiert in den B2C-Onlineshop (Success Story).
• Hellmut Ruck: Der B2C-Shop der Eigenmarke peclavus läuft auf Shopware 6 und bezieht seine Produktdaten aus OMN (Success Story).
• Pewag: Internationaler Konfigurator auf Shopware 6 mit OMN-Integration.

Du setzt bereits ein ERP ein? Dann verbinden wir Shopware über unsere Middleware auch mit deinem bestehenden ERP. Wie das Zusammenspiel von OMN und Shopware konkret aussieht, zeigen wir auf der Seite PIM-Integration für Shopware.

FAQ: Shopware 6 und PIM

Braucht Shopware 6 ein PIM?

Nicht zwingend. Für einen einzelnen Shop mit einer Sprache und überschaubarem Sortiment reichen die Shopware-Bordmittel oft aus. Ein PIM lohnt sich, sobald dieselben Produktdaten in mehrere Kanäle fließen, mehrere Sprachen gepflegt, Lieferantendaten vereinheitlicht werden müssen oder mehrere Teams mit Freigaben an den Daten arbeiten.

Wie werden Produktdaten aus einem PIM in Shopware 6 übertragen?

Über eine Integrationsschicht, die in die Admin API von Shopware schreibt. Für größere Datenmengen bündelt die Sync API viele Schreibvorgänge in einem Request. Die Integrationsschicht kann ein fertiger Konnektor aus dem Shopware Store, eine Middleware oder eine individuelle Integration sein. Im laufenden Betrieb werden nur Änderungen (Delta) übertragen.

Welche Pflichtfelder braucht ein Produkt in Shopware 6?

Beim Anlegen eines Produkts über die Admin API sind fünf Felder Pflicht: Name (name), Produktnummer (productNumber), Steuersatz (taxId), Preis (price) und Bestand (stock). Varianten brauchen zusätzlich die Referenz auf das Hauptprodukt (parentId), eine eigene Produktnummer, einen Bestand und ihre Optionen.

Was ist der Unterschied zwischen Eigenschaften und Zusatzfeldern in Shopware 6?

Eigenschaften (properties) sind strukturierte Merkmale mit festen Werten, die sich für Filter und Vergleiche eignen. Variantenbildende Merkmale wie Farbe oder Größe werden als Optionen genutzt. Zusatzfelder (customFields) speichern beliebige weitere Daten wie Texte, Zahlen, Datumswerte oder Medien. Sie erscheinen aber nicht automatisch in der Storefront. Faustregel: Auswählen gleich Option, Filtern gleich Eigenschaft, nur Lesen gleich Zusatzfeld.

Reicht der CSV-Import von Shopware für eine PIM-Anbindung?

Für gelegentliche Massenänderungen ja, als dauerhafte Anbindung eher nicht. Der Import über Profile ist dateibasiert, wird im Admin oder per Kommandozeile (Befehl import:entity) angestoßen und kann laut Shopware-Dokumentation Informationen nur ergänzen, nicht entfernen, etwa keine Sales-Channel-Zuordnung aufheben. Eine automatisierte Anbindung über die Admin API überträgt Änderungen laufend und behandelt Fehler systematisch.

Sollen Preise und Bestände aus dem PIM oder aus dem ERP kommen?

Häufig ist das ERP führend für Preise, Staffelpreise und Bestände, weil diese Werte sich schnell ändern und kaufmännisch dort entstehen. Das PIM ist führend für Texte, Merkmale, Medien und Übersetzungen. Entscheidend ist, dass für jede Datenart genau ein System führend ist und das vor Projektstart festgelegt wird.

Konnektor-Plugin oder Middleware: was ist besser?

Das hängt von der Ausgangslage ab. Ein fertiger Konnektor aus dem Shopware Store ist schnell startklar, wenn das Datenmodell nah am Standard liegt und Shopware der einzige Zielkanal ist. Eine Middleware lohnt sich, wenn der Konnektor bei individuellen Feldern, Sonderlogik oder mehreren Zielsystemen an Grenzen stößt oder wenn Mapping, Delta-Erkennung und Fehlerbehandlung zentral gesteuert werden sollen.