DPP erstellen aus PIM-Daten

July 6, 2026

DPP aus deinem PIM-System erstellen

So funktioniert die Integration mit Akeneo und anderen PIM-Systemen

Das Wichtigste zuerst

Du hast Tausende Produktdaten in deinem PIM: Material, Lieferanten, Pflegeinstruktionen, Verpackungsinhalte. Alles ist organisiert und aktuell. Jetzt brauchst du einen Digital Product Passport für ESPR. Das klingt wie ein großes Projekt.

Es ist es nicht.

Der einfachste Weg zu Compliance ist, die Daten zu nehmen, die du bereits hast. Du brauchst sie nicht neu zu sammeln oder dein PIM umzubauen. Du brauchst eine Brücke, die deine bestehenden Daten strukturiert und in einen konformen DPP umwandelt. Das dauert Wochen, nicht Monate. Und es funktioniert mit jedem modernen PIM: Akeneo, SAP, Inriver, andere.

Was ist ein DPP und warum jetzt?

Der Digital Product Passport ist eine europäische Anforderung (ESPR steht für Ecodesign for Sustainable Products Regulation). Ab 2026 müssen Hersteller von Textilien einen DPP anbieten. Ab 2027 folgen Elektronik, Batterien und weitere Kategorien.

Der DPP ist eine lesbare, digitale Form deiner Produktinformationen. Maschinenlesbar. Meist über QR-Code zugänglich.

Für dich konkret: Du brauchst einen Mechanismus, der deine Produktdaten strukturiert, validiert und verfügbar macht. Das kann Custom-Development sein (30.000 bis 50.000 Euro, viele Monate). Oder es kann eine PIM-Integration sein (zwei bis drei Wochen).

Die Frage ist einfach: Sind deine Daten schon da? Bei den meisten Unternehmen: ja. Dann brauchst du nur eine Brücke.

Wie ein DPP aus deinem PIM entsteht

Das Prinzip ist einfach. Vier Schritte:

  1. Deine PIM-Attribute (Material, Herkunft, Zertifikate, Größen, Farben, Lagerdaten, Lieferkette) sind das Fundament.
  2. Ein Mapping verbindet diese Attribute mit den DPP-Feldern, die ESPR verlangt.
  3. Ein Connector übersetzt deine Produktdaten ins DPP-Format: strukturiert, validiert, signiert.
  4. Ein QR-Code wird generiert und kann direkt in dein Labeling fließen.

Alles läuft im Hintergrund. Du arbeitest wie immer in deinem PIM. Neue Produkte anlegen, Daten pflegen, Varianten managen. Der Connector lädt deine Updates hoch und generiert den QR automatisch.

Das funktioniert mit jedem modernen PIM, das eine API hat:

  • Akeneo (Industrie-Standard für Fashion und Möbel)
  • SAP Product Information Management
  • Inriver
  • Salsify
  • Syndigo
  • Andere

Das Mapping: Von deinen Feldern zum DPP

Das zentrale Stück ist das Mapping. Wie verbindest du deine PIM-Attribute mit DPP-Anforderungen?

Option 1: Bestehende Felder nutzen (empfohlen)

Du hast wahrscheinlich schon:

  • Material wird zu DPP-Feld "Material composition"
  • Washing instructions wird zu DPP-Feld "Care instructions"
  • Certifications wird zu DPP-Feld "Applicable regulations"
  • Supplier country wird zu DPP-Feld "Origin information"
  • Size + Weight wird zu DPP-Feld "Dimensions and weight"

Das ist dein Ausgangsmapping. Kein großer Umbau. Du fragst einfach: Welche Felder habe ich bereits, und welche davon passen rein?

Die Lücken zeigen sich schnell. Circular-Economy-Daten (Rücknahme, Recyclierbarkeit) fehlen oft. Die fügt man hinzu. Gezielt, nicht chaotisch.

Option 2: Neue Felder anlegen

Manche legen extra Felder an: DPP_Material, DPP_Instructions, etc. Das ist sauberer in der Theorie. In der Praxis aufwendiger. Wenn Material aus vier verschiedenen Quellen kommt (Hauptprodukt, Variante, Supplier-Master, Kommentar-Feld), merkst du schnell: Du verschiebst Daten, statt sie zu konsolidieren.

In der Realität läuft es auf einen Mix hinaus: 80 Prozent bestehende Felder, Lücken mit neuen Feldern. Fertig.

Wie der Connector technisch arbeitet

Die Integration läuft über eine API zwischen deinem PIM und dpp.cloud. Der Fluss:

Dein PIM-System → Attribute synchronisieren → Mapping Engine: PIM-Feld → DPP-Feld → DPP strukturiert + validiert → QR-Code generiert → Zurück ins PIM oder zum Download → Label + Verpackung

Was in jedem Schritt passiert

1. Synchronisation

Dein PIM sendet Produktänderungen an den Connector: neue SKU, aktualisierte Attribute, Löschungen. Das läuft über Webhooks oder periodische API-Abfragen.

2. Mapping

Ein Mapping-File definiert die Regeln. Wenn material im PIM existiert, schreibe es in DPP.Material composition. Falls care_label leer ist, nutze einen Fallback. YAML oder JSON. Einmal konfiguriert, dann läuft es.

3. Validierung

Der Connector prüft: Sind alle Pflichtfelder gefüllt? Stimmt die Syntax? Sind Links erreichbar? Bei Fehlern wird das Produkt markiert, damit dein Team nachjustieren kann.

4. DPP-Datei

Ein DPP ist technisch eine XML- oder JSON-Datei, die die ESPR-Struktur erfüllt. Der Connector kompiliert deine Daten rein, mit Versionierung und optionalen Signaturen.

5. QR generieren

Ein QR-Code wird erzeugt, der auf eine URL zeigt, wo der DPP abrufbar ist. Die URL kann auf deiner Domain laufen (mit Redirect zu dpp.cloud) oder bei dpp.cloud gehostet sein. Der QR bleibt stabil. Änderungen später zeigen auf die aktuelle Version.

6. Zurück ins PIM

Optional: Der QR-Code oder die DPP-URL wird in ein Feld deines PIM geschrieben (z.B. QR_Code_Link). Dann ist er direkt in deinen Label-Systemen verfügbar.

Alles bleibt in deinem System

Das Wichtigste: Du brauchst keine neue Software. Kein Login in eine externe Plattform, kein neues Dashboard, das dein Team lernen muss. Die Integration läuft unsichtbar im Hintergrund.

So funktioniert es:

Dein PIM ist die Zentrale

Du pflegst deine Produktdaten wie immer in deinem PIM oder ERP. Material, Lieferanten, Zertifikate, alles dort. Wenn du ein Produkt speicherst, triggert das automatisch die DPP-Generierung.

Template wählen, fertig

Bei der Erstellung des Produkts wählst du aus, welches DPP-Template du nutzen möchtest (z.B. "Textile Standard", "Electronics Advanced", oder dein Custom-Template). Das war's. Der Rest läuft automatisch.

DPP entsteht automatisch

Der Connector nimmt deine Daten, strukturiert sie nach dem Mapping, validiert sie, und generiert den DPP-Text sowie den QR-Code.

Alles kommt zurück

Der QR-Code und der DPP-Text werden direkt in Felder deines PIM zurückgespielt. Du kannst Sie von dort in dein Labeling-System, dein ERP, dein Verpackungs-Setup exportieren. Oder sie fließen automatisch in deine Produktionsanbindung ein.

Du agierst nie mit dpp.cloud direkt. Alles läuft über dein bestehendes System. Bei neuen Produkten läuft die ganze Automation einfach mit.

Ein echtes Beispiel

Ein europäischer Textilhersteller mit 600 aktiven Textil-SKUs. Akeneo als PIM. ESPR-Deadline 2026. Nächste Frühjahrs-Order muss QR auf dem Label tragen.

Das Projekt:

  1. Tag 1: Kickoff. Welche Attribute gehen rein? 2-3 Stunden, Klärung zwischen Teams.
  2. Tag 2-7: Data Review. Wie vollständig sind die Attribute? Welche neuen Felder brauchen wir?
  3. Tag 7-10: Mapping Call. Technical Team definiert: Welche Akeneo-Attribute zu welchen DPP-Feldern? Wie Mehrsprachigkeit und Varianten?
  4. Tag 10-14: Tech Setup. Der Hersteller legt Felder an, generiert API-Credentials. dpp.cloud stellt das Mapping her.
  5. Tag 14-17: Pilot. Ein Produkt end-to-end. Material → DPP → QR. Client prüft, gibt Freigabe.
  6. Tag 17+: Scale. QR-Training. Rollout auf 600 Textilien. Koordination mit Etikettendrucker.

Die Realität: Die schnellste Phase ist die Technik (3-5 Tage). Die längste ist die Koordination und das physische Aufbringen der QR-Codes auf Etiketten. Darin stecken die Wochen. Nicht in der Datenintegration.

Andere PIM-Systeme

Die Grundlogik ist überall gleich:

PIM API-Standard Besonderheiten
Akeneo REST API Sehr flexible Attribut-Struktur
SAP PIM OData / REST Enterprise-Scale, oft Legacy-Systeme angebunden
Inriver REST API Stark in B2B, viele Varianten-Strukturen
Salsify REST API Cloudnativ, flexibel und modern

Die Unterschiede sind Syntax und Authentifizierung. Das Muster ist überall gleich: Attribute mappen, QR generieren, rückführen.

Die wichtigsten Fragen

Muss ich mein PIM umbauen?

Nein. Deine aktuelle Struktur ist wahrscheinlich schon 80 Prozent des Wegs dort. Schlimmstenfalls kommen 3-5 neue Felder hinzu. Kein Rebrand, keine Neustrukturierung nötig.

Was wenn Produktattribute leer sind?

Das hängt vom Feld ab. Pflichtfelder (Material, Herkunft, Größe) müssen gefüllt sein. Optionale Felder können leer bleiben. Der Connector zeigt dir die Lücken, damit dein Team nachjustieren kann.

Kann ich Übersetzungen haben?

Ja. Dein Akeneo hat wahrscheinlich schon Lokalisierungen pro Attribut (z.B. care_label_de, care_label_en). Der Connector respektiert das und erzeugt einen mehrsprachigen DPP.

Wann werden die QR-Codes aktuell?

In Echtzeit, sobald du ein Produkt im PIM speicherst. Es gibt optionale Batch-Zyklen (z.B. nur nachts), aber Standard ist: ändern, Webhook, neuer QR in wenigen Minuten.

Kann ich einen QR generieren, bevor die Daten vollständig sind?

Ja, das ist sogar empfohlen. Der QR bleibt stabil, während die Daten dahinter wachsen. Du kannst Etiketten drucken, während dein Team noch Zulieferer-Informationen sammelt. Der Code ist ungültig, bis die Daten da sind, aber es blockiert deine Produktion nicht.

Warum GS1 Digital Link?

GS1 Digital Link ist ein Standard für QR-Codes, der die GTIN/EAN direkt in der URL kodiert. Das bedeutet:

  • Maschinenlesbar: Deine POS-Kassen können ihn scannen wie einen normalen Barcode.
  • Flexibel auf Serial-Nummern-Ebene: Du kannst DPPs auf Batch-, Chargen- oder sogar Seriennummern-Level erstellen. Jede Einheit hat ihren eigenen QR, aber derselbe DPP-Link funktioniert für alle.
  • Keine zusätzliche Software-Layer: Du brauchst kein zusätzliches System zum Verwalten von Links. Alles läuft über GS1 Digital Link Standard.
  • Zukunftssicher: Wenn sich URLs ändern, kann der QR später neupositioniert werden – der physische Code bleibt stabil.
  • Eine Struktur statt zwei: Ein QR-Code statt Barcode + DPP-Code parallel.

Was wenn ich auch Magento und Zendesk habe?

Nein, das macht es nicht kompliziert. Die dpp.cloud Anbindung ist nur PIM. Magento und Zendesk können die QR-Codes aus dem PIM oder von dpp.cloud abrufen, müssen aber nicht neu integriert werden. Wenn dein Magento Store DPP-URLs anzeigen soll, ist das eine separate, einfache Integration (API-Call). Aber optional – oft entfällt das, weil der QR auf dem physischen Produkt das Wichtigste ist.

Wer bezahlt für API-Calls und Mapping?

Das ist Teil deiner dpp.cloud Subscription. Es gibt verschiedene Pakete (Growth, Professional) mit unterschiedlichen SKU-Limits. Mapping und API-Anbindung sind im Preis inbegriffen. Keine versteckten Gebühren pro Sync oder API-Call.

Welche Lücken entstehen oft?

Wenn du DPP-Daten aus deinem PIM extrahierst, findest du normalerweise schnell diese Lücken:

Circular Economy

ESPR verlangt Infos über Recycling, Rücknahme, Reparierbarkeit. Viele PIM-Systeme haben das nicht strukturiert. Es ist irgendwo in einer Beschreibung vergraben oder fehlt ganz.

Lösung: Neue Felder für Recycling-Info, Reparierbar-Ja/Nein, Rücknahme-Link. Meist 3-5 neue Attribute.

Care Label / Waschanleitung

Oft sind Waschangaben in PDFs oder Bildern, nicht als strukturiertes Feld.

Lösung: Ein Feld für die Text-Version (für den DPP) und ein Feld für das Bild (für das physische Label). Einmalige Umstellung.

Supplier / Herkunftsinformation

Du hast vielleicht "Made in India" irgendwo, aber der DPP braucht auch: Welcher Supplier genau? Welche Zertifikate? Link zu seinen Daten?

Lösung: Ein Master-Data-Feld für Supplier-Info oder eine Referenz zu deinem Supplier-Management-System. Meist komplexer, aber oft schon vorhanden.

Compliance und Sicherheit

Für Elektronik und Batterien: Sicherheitsdatenblätter, Konformitätserklärungen, RoHS-Status.

Lösung: Dateien-Feld im PIM mit Verlinkung im DPP, oder direkte URL-Referenzen.

Diese Lücken sind nicht kritisch. Sie bedeuten nur, dass dein DPP-Pilot ohne 100 Prozent Daten startet. Das ist okay. Daten werden gepflegt, während das System lädt.

Die Roadmap

Woche 1-2: Kickoff + Mapping

  • Entscheidungen treffen (welche Kategorien, welche Daten, welche Domain für QR)
  • Mapping definieren
  • Neue PIM-Felder anlegen

Woche 2-3: Pilot

  • Ein Produkt oder kleine Batch end-to-end durchlaufen
  • QR-Code prüfen, DPP-Daten validieren
  • Mapping-Anpassungen bei Bedarf

Woche 3-4: Scale

  • Rollout auf die ganze Kategorie
  • QR-Generierung für Etikettendrucker
  • Physical Application koordinieren (der längste Teil)

Monat 2+: Normalbetrieb

  • Regelmäßige Daten-Pflege im PIM
  • QR-Codes fließen automatisch in neue Orders
  • Weitere Kategorien (Elektronik, Batterien) bei Bedarf nachladen

Was du gewinnst

Compliance ab Tag 30 statt Monat 6

Keine Daten-Migration – dein PIM ist schon die Quelle der Wahrheit

Kein extra Team – dein bestehendes PIM-Team handelt das mit Training

Skalierbar – von 100 SKUs bis 10.000 funktioniert dasselbe System

DPP bleibt aktuell – wenn du Daten im PIM änderst, ist es im DPP automatisch aktuell

Das ist nicht "Compliance ist schwer, aber wir haben einen Workaround". Das ist: Du hast die Daten schon. Wir machen daraus schnell einen konformen DPP. Fertig.

Nächste Schritte

Du hast Akeneo oder ein anderes PIM? Du fragst dich, ob und wie die Integration passt? Wir machen eine 30-minütige Strategie-Session. Gemeinsam schauen wir auf dein PIM, klären die Lücken, geben dir konkrete Zahlen und einen Zeitplan.

Buche deine kostenlose Strategie-Session

FAQ

Muss ich mein PIM umbauen?

Was wenn Produktattribute leer sind?

Wird der DPP auch übersetzt?

Wie werden die QR Codes aktualisiert?

Kann ich einen DPP generieren, bevor die Daten vollständig sind?

Related Posts