Anwendertipps: Wie funktionieren Formatbeschreibungen?

Formatbeschreibungen arbeiten im Maschinenraum unserer Produkte. Sie definieren, wie EDI-Dateien aufgebaut und befüllt sein müssen, damit sie Geschäftsprozesse richtig abbilden. Die obersten Ziele sind dabei Präzision und Effizienz: Die Anwender müssen die Vorgaben genau verstehen und das mit möglichst wenig Vorwissen und in möglichst kurzer Zeit. Um diese Ziele für unterschiedliche Anforderungen zu erfüllen, nutzen wir drei Elemente für den Aufbau der Formatbeschreibungen: Syntax-Vorgaben, Regeln und Sub-Prozesse.

Genauso wichtig ist es aber auch für unsere Kunden zu verstehen, wie diese Instrumente funktionieren, schließlich sind sie es, die die Vorgaben für Formatbeschreibungen machen. An dieser Stelle möchten wir deswegen zeigen, welches Element sich für welche Aufgabe am besten eignet und Ihnen so ein Gefühl dafür geben, wie eine gute Formatbeschreibung aufgebaut sein sollte.

Syntax-Vorgaben beziehen sich zum einen auf den Status eines Segments und der darin enthaltenen Daten-Felder. Sind diese verpflichtend, muss der Datensender sie verwenden, sind sie optional, kann er dies nach Ermessen tun. Zum anderen können Sie vorschreiben, ob Mindest- oder Maximallängen für die Felder eingehalten werden müssen, ob der Inhalt nur aus Zahlen oder auch aus weiteren Zeichen bestehen darf und ob er einem bestimmten Aufbau folgen muss.

Syntax-Vorgaben zu setzen, ist immer dann empfehlenswert, wenn ein Inhalt grundsätzlich in einem Geschäftsprozess auf immer dieselbe Art übermittelt werden muss. So könnte beispielsweise das Segment, in dem die Nettosumme einer Rechnung abgebildet wird, den Status „verpflichtend“ erhalten, weil diese Information für alle Rechnungen relevant ist. In einer Formatbeschreibung für Lieferscheine könnten Sie dagegen eine Liste mit Packmittel-Codes vorgeben, mit denen der Datensender die verwendeten Packmittel identifizieren muss. Verwendet er einen Code, der nicht in dieser Liste enthalten ist, wird ein Fehler ausgegeben.

EDI-Guidelines enthalten aber auch Informationen, die in unterschiedlichen Segmenten einer EDI-Nachricht abgebildet werden können, nur unter Umständen übertragen werden müssen, oder sich gegenseitig ausschließen. Da diese sich nicht mit einfachen syntaktischen Vorgaben abbilden lassen, haben wir logische Prüf-Regeln als zweites Element der Formatbeschreibungen eingebaut. Mit den Regeln können Sie beispielsweise überprüfen, ob Berechnungen richtig durchgeführt oder Datumsangaben in einer logischen Reihenfolge dargestellt wurden.

Regeln machen immer dann Sinn, wenn wichtige Inhalte nicht mit den Mitteln der Syntax-Vorgaben abgedeckt werden können. Ein Beispiel: Sie stellen Ihren Partnern frei, die Bestellnummer im Kopf oder in den Positionen einer Bestellantwort zu referenzieren. Syntaktisch müssen damit die Segmente für die Bestellnummer auf Kopf- und Positionsebene den Status „optional“ haben. Wären sie verpflichtend, müsste der Datensender ja die Bestellnummer sowohl auf Kopf- als auch auf Positionsebene darstellen. Gäbe es aber nur syntaktische Vorgaben, wäre die Information insgesamt optional, da ja die Segmente syntaktisch optional sind. Eine Regel hierzu könnte prüfen, ob die Bestellnummer entweder an der einen oder an der anderen Stelle gesetzt wurde und einen Fehler anzeigen, wenn sie gar nicht enthalten ist. Falls sie auch gleichzeitig an beiden Stellen übertragen werden darf, könnte man noch prüfen, ob der Wert identisch ist.

Auch Plausibilitätsprüfungen für Berechnungen lassen sich nur mit logischen Regeln durchführen: Die Segmente mit den Operanden können korrekt dargestellt sein und trotzdem ist die Rechnung fehlerhaft. Nur eine Regel, die auf die Inhalte zugreift und diese nachrechnet, kann sicherstellen, dass die Inhalte nicht nur formal, sondern auch logisch korrekt sind.

Manche EDI-Guidelines bilden mehrere Szenarien eines Geschäftsprozesses ab. Beispielsweise könnte eine Guideline für Transportaufträge sowohl Vorgaben zu Luftfracht- als auch zu Seefracht-Prozessen machen. Hier sind es ein bis zwei Kriterien, die logisch entscheiden, welche Inhalte dargestellt werden müssen. In unserem Beispiel wäre das der Indikator, ob es sich um Luft- oder Seefracht handelt. Würde man alle Logiken einer solchen Guideline in einer Formatbeschreibung abbilden, würde das zu einer großen Zahl an Regeln führen. Man müsste für viele Segmente prüfen, ob alle Bedingungen erfüllt sind, die ein Segment verpflichtend machen.

Mit Sub-Prozessen können Sie die Vorgaben der Guidelines auf mehrere Varianten einer Formatbeschreibung aufteilen. Beim Beispiel der Transportaufträge könnten Sie eine Variante „Luftfracht“ erstellen, bei der Sie Segmente, die nur für diese Variante benötigt werden, in den Syntax-Vorgaben als verpflichtend markieren. In einer Variante „Seefracht“ wären diese Segmente dagegen optional, stattdessen wären die hierfür benötigten Segmente verpflichtend. Auf diese Weise sparen Sie zum einen insgesamt jene Regeln ein, deren einzige Bedingung die Transportart gewesen wäre. Zum anderen müssen Sie in jeder Variante nur die jeweils notwendigen Regeln überprüfen, so dass Anwender leichter die jeweiligen Anforderungen verstehen. Sub-Prozesse sind immer dann sinnvoll, wenn Sie damit Ihre Formatbeschreibung thematisch in zwei bis vier große Blöcke aufteilen können, die von Ihren Partnern dann schneller umgesetzt werden können, als wenn alle Vorgaben in einer Formatbeschreibung dargestellt würden.

Mit diesem Artikel wollten wir Ihnen zeigen, mit welchen Elementen Sie bei der Erstellung von Formatbeschreibungen arbeiten können. Dabei lassen wir Sie aber nicht allein: Wir stehen wir Ihnen mit all unserer Erfahrung zur Seite und erarbeiten gemeinsam mit Ihnen eine Lösung, mit der Sie Ihr EDI-Onboarding beschleunigen und vereinfachen oder Ihre produktiven Daten präzise überwachen können.