Das GDSN Major Release 3: KEIN Grund zur Panik! … revisited im Handel!

Zum 12.05.2016 wird das jetzige GDSN Release 2.8 durch das neue GDSN Major Release 3 (MjR3) abgelöst. Das neue Release ist nicht abwärtskompatibel und hat Auswirkungen auf das Datenmodell und die XML-Nachrichten: Neue Attribute kommen hinzu, bestehende Attribute fallen weg, Attribute werden neu strukturiert oder ändern sich hinsichtlich ihrer Länge oder Wiederholbarkeit. Codelisten ändern sich. Ebenso die Struktur der XML-Nachricht.

mj3r-zeitDies ist auch der Auslöser für mehrere Projekte zur Anpassung der weiterverarbeitenden Systeme bei einem meiner Handels-Kunden, der einen großen Umfang von Artikeldaten aus dem GDSN bezieht. In diesem Projekt zeigte sich recht schnell, dass der verbleibende Zeitraum bis Mai 2016 nicht ausreichend ist, um alle bestehenden Prozesse und Systeme an das neue Release anzupassen.

Neue MjR3 Funktionalität

Bspw. wird in MjR3 das sogenannte „preliminary item“ eingeführt, dass es der Industrie erlaubt, Artikeldaten möglichst früh bereitzustellen, auch wenn noch nicht alle Informationen zu dem Artikel verfügbar sind. Defacto werden für solche Items die meisten der GDSN-Validierungen einfach nicht angewendet. Für ein Handelsunternehmen ist die Verarbeitung eines solchen „vorläufigen“ Artikeldatensatzes natürlich alles andere als trivial. Kann man den „vorläufigen“ Artikel schon listen?

Das wäre natürlich wünschenswert – typischerweise ist so ein Artikel aber im Backend eines Händlers gar nicht speicherbar, da auch hier eine Vielzahl an Validierungen versuchen die Datenkonsistenz sicherzustellen. Und selbst wenn er gespeichert und gelistet werden kann – wie geht man dann mit der Situation um, wenn der Lieferant keine vollständige Aktualisierung mehr schickt, bevor man die erste Bestellung auslöst?

Hier stellt man also sehr schnell fest wie tiefgreifend die Änderungen des MjR3 aus Handelssicht ist, wenn man konsequent alle neuen Funktionalitäten in den internen Prozessen auch umsetzen will.

Rück-Mapping als Lösung

Damit mein Kunde über Mai 2016 hinaus trotzdem Artikeldaten aus dem GDSN erhalten und verarbeiten zu kann, haben wir ein Rück-Mapping von MjR3 XML-Nachrichten auf schema-valide 2.8 XML-Nachrichten entwickelt.

teaser3

Für neue Funktionalitäten des MjR3, die das Handelshaus nicht implementiert, generieren wir eine automatische Antwortnachricht (CIC Review) für den Lieferanten, dass diese Funktionalität nicht unterstützt wird.

Damit können die bestehenden Systeme ohne Anpassung auch nach Umstellung auf MjR3 weiterbetrieben werden. Die Umstellung kann dann in der Folge Schritt für Schritt, System für System erfolgen, in selbst festgelegter Zeitplanung, unabhängig vom MjR3 Umstellungszeitpunkt. Das Rück-Mapping selbst wird dabei lediglich in den bestehenden laufenden GDSN Nachrichtenstrom eingehängt.

Aufgrund der umfangreichen Änderungen ist dieses Rück-Mapping keine einfache technische Formattransformation, sondern ein detailliertes Mapping mit einigen Herausforderungen und Lösungen. So mussten Mappings für neue, genauso wie für strukturell veränderte, Attribute gefunden werden. Immer unter der Randbedingung valide 2.8 XML-Nachrichten zu erzeugen. Trotzdem werden auch neue MjR3 Inhalte in 2.8 transportiert: Als sog. „Attribute Value Pairs“. Dies erlaubt bei Bedarf neben dem selbstgewählten Zeitpunkt zum Umstieg auf MjR3 auch frühzeitig gezielt einige neue Inhalte bereits in der „2.8er Welt“ zu nutzen.

Mehr Informationen zum Rück-Mapping finden Sie hier.

Haben Sie Interesse an einem Rück-Mapping? Dann senden Sie mir gerne eine Nachricht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.