Verbandsportal anbinden: Vorgaben in PIM-Felder übersetzen

Ein PVH-Artikel ist im PIM schnell angelegt. Doch sobald er an ein Verbandsportal geht, zählt jede Feldlänge, jeder Code und jede Pflichtangabe. Wer dorthin liefert, trifft auf Einreichungsvorgaben, die vor die PIM-Konfiguration gehören und nicht erst an den Upload.

Die verbindliche Pflichtfeldliste gibt immer der jeweilige Verband heraus. Was sich unabhängig davon beschreiben lässt, ist die Struktur solcher Vorgaben, denn im PVH folgen sie fast durchgängig derselben Mechanik: eine Klassifikation, ein Austauschformat und eine Portalspezifikation obendrauf.

Warum Verbandsvorgaben die Datenstruktur im PVH bestimmen

Im technischen Großhandel und im PVH entstehen Artikelstammdaten nicht aus freier Gestaltung. Verbandsportale und Beschaffungsplattformen geben Format, Pflichtfelder und Einreichungslogik vor. Wer anschließt, liefert in diesem Rahmen. Ein Branchenverband leitet diese Vorgaben aus den Anforderungen seiner Häuser ab und setzt sie für alle gleich. Das betrifft Pflegeaufwand und Lieferfähigkeit direkt, auch bei Herstellern, die über den Großhandel liefern.

Der eigentliche Kostenhebel liegt im Zeitpunkt der Klärung. Fallen Vorgaben erst beim Portal-Upload auf, müssen bereits gepflegte Daten überarbeitet werden, an Stellen, die nie als Problem galten. Die Auseinandersetzung mit den Vorgaben gehört deshalb vor die PIM-Konfiguration, nicht danach.

Wie komplex das wird, hängt nicht an der Artikelzahl. Treiber sind die Zahl der Absatzkanäle, die Sprachen, geforderte Standards wie ETIM und eCl@ss, die Änderungsfrequenz und Compliance-Pflichten. Ein schmales Sortiment über viele Kanäle kann aufwändiger sein als ein breites über einen.

Als Orientierung dient die ETIM-BMEcat-Guideline, weil sie die Struktur solcher Anforderungen offenlegt. Welche Felder Ihr Portal als Pflicht setzt, erfahren Sie dagegen nur dort.

Ein Portal, mehrere Onboarding-Spuren

Ein Branchenportal ist oft kein einzelner Kanal, sondern ein Bündel von Ausgabespuren: nationale und internationale Produktdaten, bauwerksbezogene Stammdaten, BIM, Klassifikation nach ETIM, Planungsdaten und EDI. Ein Lieferant bedient häufig mehrere davon gleichzeitig, weil dieselbe Artikelbasis in Katalog, Planung und Beschaffung gebraucht wird.

Die Spuren unterscheiden sich in der Merkmalstiefe. Bauwerksbezogene Stammdaten und BIM verlangen Attribute mit eigenen Strukturen und Bezugssystemen, ein reiner Katalogdatensatz liefert sie nicht. Planungsdaten laufen als eigene Spur mit eigenen Datenformaten und Prüfschritten. EDI benötigt stabile Ordnungs- und Mengeneinheiten statt Marketingtext.

Vor der Konfiguration klären Sie deshalb vier Punkte:

• Gebuchte Spuren: jede bringt eigene Pflichtfelder mit.
• Zuordnung: welcher Datensatz speist welche Spur.
• Merkmalsherkunft: welche Attribute stammen aus ETIM, welche sind Hausmerkmale.
• Ausgabeformate: welche Formate ein Produkt gleichzeitig bedienen muss.

Setzen Sie Datenmodell und Merkmalspflege so auf, dass ein Produkt mehrere Ausgabeformate speist, ohne dass Merkmale doppelt gepflegt werden. Ein Merkmal, eine Pflegestelle, mehrere Projektionen.

Welche Standards und Formate den Rahmen setzen

Die Anforderungen greifen auf drei Ebenen ineinander.

• Klassifikation: Über ETIM oder eCl@ss wird festgelegt, mit welchen Merkmalen ein Artikel beschrieben wird.
• Austauschformat: BMEcat regelt, wie diese Daten technisch übergeben werden.
• Portalspezifikation: Der jeweilige Betreiber eines Datenpools setzt eigene Vorgaben.

Verbandsvorgaben betreffen in der Regel die ersten beiden Ebenen. Die dritte kommt pro Kanal hinzu.

Referenzformat ist BMEcat. Es ist die Grundlage der meisten Lieferantenvorgaben und gehört zu den Formaten, die nextPIM im Im- und Export unterstützt. Welche BMEcat-Version ein Portal annimmt, steht in dessen Spezifikation.

Die ETIM-BMEcat-Guideline liegt in Version 5.0 vor, Herausgeber ist ETIM International. Sie ist ausdrücklich als Vorgabe an Lieferanten formuliert und beschreibt, welche Produktdaten in welcher Struktur zu liefern sind. Damit dient sie unmittelbar als Vorlage für die Feldkonfiguration im PIM. Wie sich diese Aufbereitung für Hersteller auswirkt, die über Händler und Portale liefern, beschreibt der Beitrag Produktdatenmanagement für Hersteller.

Rein global sind die Anforderungen nicht. Länderspezifische Regulierungen werden separat aktualisiert. Der Rahmen ist damit national überlagert: Ein Portal kann Felder verlangen, die ein anderes nicht kennt.

Vom Anforderungsblock zum PIM-Feld: die Ableitung

Aus diesen Formatvorgaben wird im nächsten Schritt eine Feldstruktur. Die Guideline gliedert ihre Anforderungen in Blöcke, und jeder Block nimmt in der Konfiguration genau eine von drei Formen an.

• Katalog-Grundanforderungen: Dateiname und allgemeine Inhaltsregeln. Im PIM entstehen daraus Exportprofile und Namenskonventionen je Kanal.
• Root-Element: Die Referenz auf das XSD-Schema legt die Schemaversion fest. Sie gehört als feste Formatversion ins Katalogprofil, nicht in die Einzelfallentscheidung.
• HEADER-Felder: Katalogmetadaten. Sie werden als Pflichtfelder auf Katalogebene geführt, nicht am einzelnen Produkt.
• Inhaltliche Sektionen: Produktbeschreibung, Keywords, Klassifikation und Features, Bestellung, Preise, Bilder und weitere Dokumente, Subtree PRODUCT_REFERENCE, REACH, Sicherheitsdatenblatt und ECCN-Codes, Verpackungsvarianten, Produktserien. Diese Struktur lässt sich nahezu eins zu eins in PIM-Sektionen abbilden.

Ableitungsregel für die Praxis: Jede Vorgabe wird entweder ein Pflichtfeld, eine Validierungsregel oder eine eigene Sektion. Was in keine dieser drei Kategorien fällt, ist für die Einreichung nicht relevant und wird nicht in den Kern aufgenommen.

Welche Felder im Shop über Sichtbarkeit und Conversion entscheiden, zeigt der Beitrag Produktdaten optimieren.

Vier Transaktionen verlangen Delta- und Lifecycle-Logik

Die Ableitung endet nicht bei den Feldern. Die Guideline trennt vier Transaktionen:

• T_NEW_CATALOG für die Erstanlage
• T_UPDATE_PRODUCTS für Produktänderungen
• T_UPDATE_PRICES für Preisänderungen
• T_NEW_PRODUCTDATA für neu hinzukommende Produktdaten

Preise werden damit unabhängig von Produktdaten aktualisiert. Legen Sie Preislisten mit Gültigkeitsdatum und Währung an, statt ein einzelnes Preisfeld am Artikel zu führen. Produktänderungen laufen als Update, nicht als Neuanlage. Das setzt Änderungsstände und Zeitstempel voraus, damit erkennbar bleibt, was seit dem letzten Export geändert wurde.

Damit verschiebt sich die Aufgabe von statischer Stammdatenpflege zu einem wiederkehrenden Lebenszyklus. Für den Innendienst ist das eine Routineaufgabe, kein einmaliges Projekt. Wer Produktdaten weiterhin manuell in Excel pflegt, erzeugt bei jeder Preisrunde denselben Aufwand neu, statt einmal ein Exportprofil zu hinterlegen.

Die praktische Konsequenz für die Konfiguration: Der Export muss Deltas bilden können. Fehlt diese Funktion, erzeugt jede Preisänderung den kompletten Katalog neu.

Compliance-Felder: REACH, Sicherheitsdatenblatt, ECCN

Die Guideline führt REACH, Sicherheitsdatenblatt und ECCN-Codes als eigene Sektionen. Das sind eigenständige Anforderungsblöcke, keine Randnotizen. Für Sicherheitsdatenblätter gilt der Rahmen aus Anhang II der REACH-Verordnung in der Fassung der Verordnung (EU) 2020/878.

• REACH: Stoffangaben zum Produkt
• Sicherheitsdatenblatt: Dokument mit Stand und Sprache
• ECCN: Klassifizierungscode

In gewachsenen Datenbeständen fehlen genau diese Felder typischerweise. Sie wurden nie systematisch erfasst, weil frühere Kanäle sie nicht verlangten.

Daraus folgt eine Freigabelogik: Ein Produkt wird erst für Online-Kanäle freigegeben, wenn die Compliance-Felder befüllt sind. nextPIM setzt das über Pflichtfelder um, wie bei den GPSR-relevanten Feldern. Welche Angaben dort konkret hinterlegt werden, zeigt der Beitrag zur GPSR-Sicherheitsbescheinigung im Onlineshop.

Klären Sie vorab, wer die Inhalte liefert. Sicherheitsdatenblätter und ECCN-Codes kommen in der Regel vom Hersteller oder Lieferanten, die Abstimmung läuft über den Einkauf. Beim ECCN-Feld ist zusätzlich zu klären, auf welches Klassifizierungsschema sich die Angabe des Lieferanten bezieht.

Wie viele Artikel betroffen sind, hängt vom Sortiment ab und lässt sich nicht pauschal angeben. Aussagekräftig ist die Prüfung des eigenen Bestands auf leere Felder in diesen drei Sektionen.

Verpackungsvarianten und Produktserien als Datenmodell

Compliance-Felder sind nicht der einzige Anforderungsblock, der ein eigenes Datenmodell verlangt. Verpackungsvarianten und Produktserien sind in der Guideline ebenfalls eigene Sektionen. Beide lassen sich nicht über einfache Felder abbilden. Die Anforderungen an Produktdaten im PVH sind anspruchsvoll, und genau das zeigt sich an diesen Strukturen.

Verpackungsvarianten als Variantenmodell

Verpackungsvarianten verlangen ein Variantenmodell mit Basiseinheit, Umverpackung und Paletteneinheit. Jede Ebene braucht Umrechnungsfaktoren. Das betrifft Bestellmengeneinheiten unmittelbar: Ein Artikel kann in Stück, Karton oder Palette bestellt werden. Ein einzelnes Feld für die Bestelleinheit reicht dafür nicht.

Produktserien als Hierarchie

Produktserien verlangen eine Hierarchie oder Produktfamilie. Ein Artikel wird damit nicht nur über seine eigene Nummer auffindbar, sondern auch über seine Serie. Das verbessert Navigation und Suchtreffer in Katalogen.

Datenmodellentscheidung mit Nachziehpflicht

Beide Punkte sind Datenmodellentscheidungen. Werden sie nach der ersten Konfiguration eingeführt, müssen bestehende Artikel nachgezogen werden. Für den Export bedeutet das: Varianten und Serien müssen als Relationen geführt werden, nicht als Freitextfelder. Nur so bleiben sie beim Katalogexport auswertbar.

Planungsdaten als eigener Datenbestand

Planungsdaten laufen parallel zum Kataloggeschäft und folgen einer eigenen Logik. Computergestützte Planung ist in Gewerken wie Bad, Heizung und Elektro seit Jahrzehnten etabliert, und die Spur nutzt ein eigenes Datenmodell, das die gängigen Planungsprogramme der Branche implementieren.

Der Portalbetreiber sammelt die Planungsdaten, prüft sie und stellt sie Planern bereit. Diese Reihenfolge zeigt, dass die Validierung vor der Verteilung stattfindet, nicht danach.

Für Hersteller folgt daraus: Planungsdaten sind ein eigener Datenbestand. Geometrische und planungsrelevante Merkmale haben im Katalogdatensatz keine Entsprechung und müssen separat aufbereitet werden. Bleiben hier Lücken, tauchen die Produkte in der Planung nicht auf, während Wettbewerberprodukte in die Zeichnung wandern. Aus einem Datenmangel wird eine Umsatzverlagerung. Klären Sie vor der Konfiguration, welche Planungsformate Ihre Zielsoftware verlangt. Vergleichbare Anforderungen gelten für Hersteller im Baubereich.

Mapping-Tabelle: Verbandsvorgabe, PIM-Feldtyp, Validierungsregel

Der prüfbare Teil der Umsetzung ist die Ableitungstabelle. Sie wird zum zentralen Arbeitsmittel der Konfiguration und hält zugleich fest, wer eine Zeile befüllt.

Verbandsvorgabe	PIM-Feldtyp	Validierungsregel	Zuständig
Katalogkopf	Exportprofil mit Namenskonvention	Dateiname, Schemaversion, HEADER-Felder vollständig	Datenpflege
Produktbeschreibung	mehrsprachiges Textfeld	Mindestlänge, Pflichtfeld für alle Kanäle	Produktmanagement
Keywords	Mehrfachauswahl aus kontrolliertem Vokabular	kein Freitext, Wertebereich begrenzt	Produktmanagement
Klassifikation und Features	Zuordnung zu eCl@ss- oder ETIM-Klassen mit Merkmalswerten	Vollständigkeit der merkmalsrelevanten Felder	Produktmanagement
Preise	Preisliste	Gültigkeitsdatum und Währung, kein Einzelpreisfeld	Vertrieb
Bilder und Dokumente	Medienzuordnung	Typ und Sprache je Medium	Produktmanagement
ECCN	Code-Feld	Formatprüfung	Produktmanagement
Verpackung	Variantenrelation	Umrechnungsfaktor vollständig	Innendienst
Referenzen	Relation für Zubehör, Ersatzteile, Serien	Bezug aufgelöst, kein Freitext	Produktmanagement

Die Zeilen folgen den Sektionen der Guideline. Die vierte Spalte verhindert den häufigsten Stillstand im Onboarding: Felder, für die sich niemand zuständig fühlt, weil Preise im Vertrieb liegen, Merkmale im Produktmanagement und Mengeneinheiten im Innendienst. Die genaue Fundstelle und die exakte Pflichtfeldkennzeichnung entnehmen Sie der jeweils gültigen Fassung des Dokuments.

Die Tabelle wird zum Katalogprofil. Jede Zeile mit Pflichtfeldkennzeichnung erzeugt ein Pflichtfeld, jede Formatangabe eine Validierungsregel. Vor dem ersten Export gehört eine Prüfliste dazu: Pflichtfelder befüllt, Relationen aufgelöst, Codes formatkonform, Medientypen und Sprachen vollständig. Compliance-relevante Felder entscheiden über die Freigabe, vergleichbar mit den Pflichtangaben aus der Produktsicherheitsverordnung im stationären Handel.

Länder- und portalspezifische Zusatzfelder richtig einordnen

Die Mapping-Tabelle beschreibt den Kern. Nationale Vorgaben kommen hinzu, und sie ändern sich unabhängig davon. Ein Portal kann Felder verlangen, die ein anderes nicht kennt.

Die saubere Lösung: Kernfelder nach Guideline, länder- und portalspezifische Zusatzfelder als eigene Feldgruppe daneben. So bleibt der Kern stabil, und die Länderanforderung bleibt wartbar.

Wer portalspezifische Felder als Pflichtfelder für alle Kanäle führt, blockiert damit Exporte für Kanäle, die sie gar nicht benötigen. Prüfen Sie deshalb vor der Konfiguration, welche Absatzkanäle und Länder tatsächlich bedient werden. Daraus ergibt sich, welche Zusatzfelder wirklich gebraucht werden. Wie bestehende Listen in den Stamm kommen, zeigt die Funktionsseite zu den flexiblen Excel-Importen.

Fazit: Prüfliste vor der PIM-Konfiguration

Sind Kernfelder und länderspezifische Zusatzfelder getrennt, lässt sich die Konfiguration abschließen. Sechs Punkte gehören vorher auf die Prüfliste.

• Spuren festlegen: Klären Sie, welche Ausgabespuren das Portal überhaupt vorsieht: Produktdaten, bauwerksbezogene Stammdaten, BIM, Klassifikation, Planungsdaten, EDI. Planungsdaten sind ein eigener Datenbestand und gehören früh eingeplant.
• Vorgaben sammeln: Tragen Sie Verbandsvorgaben und Portalspezifikationen vollständig zusammen, bevor Felder angelegt werden. Die portalspezifischen Angaben holen Sie beim Betreiber ein, nicht aus zweiter Hand.
• Anforderungsblöcke übersetzen: Überführen Sie jeden Block der Guideline in Pflichtfeld, Validierungsregel oder Sektion und dokumentieren Sie das in einer Mapping-Tabelle.
• Delta-Logik vorsehen: Planen Sie die vier Transaktionen so, dass Preise und Produktänderungen getrennt exportierbar bleiben. Das verlangt Änderungsstände und getrennte Preislisten mit Gültigkeitsdatum.
• Compliance und Varianten einplanen: REACH, Sicherheitsdatenblatt und ECCN-Codes sowie Verpackungsvarianten und Produktserien gehören ins Datenmodell, bevor der erste Artikel gepflegt wird. Nachträglich verursachen sie Nacharbeit an bestehenden Datensätzen.
• Aufwand realistisch halten: Mit einem PIM, das eCl@ss und ETIM klassifiziert und BMEcat-Kataloge erzeugt, bleibt die laufende Pflege eine Innendienstaufgabe. nextPIM gibt es seit 2019, dahinter stehen mehr als 100 erfolgreiche Implementierungen in Handel und Industrie, der Einstieg liegt bei 600 Euro pro Monat bei jährlicher Abrechnung.

Wer diese fünf Punkte abarbeitet, bevor das erste Katalogprofil entsteht, vermeidet Nacharbeit, die sonst erst bei der Portalübergabe sichtbar wird.