Fix Record

AK 4711    K0815   20130530
POS0001S123    0005000009990
POS0002H456    0003000017950

Das ist ein extrem simples Beispiel, aber für die Grundlagen reicht’s.

Dröseln wir die Zeilen auf.

AK 4711    K0815   20130530

• AK soll hier für den Auftragskopf stehen. Dies ist die Satzartkennung, an der eine Software (oder auch der Mensch) erkennt, was für ein Datensatz kommt. Sie ist drei Stellen lang, hier aufgefüllt mit einem Leerzeichen.
• 4711 ist die Auftragsnummer, 8 Stellen lang, mit Leerzeichen aufgefüllt.
• K0815 ist die Kundennummer, ebenso lang und aufgefüllt.
• 20130530 schließlich ist das Auftragsdatum, Format yyyymmdd, also 8-stellig.
• Dahinter steht noch ein Leerzeichen, das sehen Sie nur jetzt nicht (aber später).

POS0001S123    0005000009990

• POS ist die Kennung für die Position. Da sie bereits dreistellig ist, muss kein Leerzeichen mehr angefügt werden.
• 0001 ist die Positionsnummer. Sie wird auf eine Länge von 4 Zeichen mit führenden Nullen aufgefüllt.
• S123 ist die Artikelnummer, mit folgenden Leerzeichen auf 8 Zeichen gefüllt.
• 0005 wurde mit Nullen auf Länge 4 aufgefüllt, das ist die Menge.
• 000009990 schließlich soll 9.99 darstellen, vorne mit Nullen aufgefüllt, und statt eines Dezimaltrenners wurde einfach definiert, dass eben immer die letzten drei Ziffern die Nachkommastellen darstellen. Gesamtlänge 9.

Rechnen Sie die Längen dieser Felder mal zusammen! Was kommt raus? Beide Male 28. Um das zu erreichen, wird die Kopf-Zeile noch mit einem Leerzeichen am Ende aufgefüllt. Gäbe es mehr als diese beiden Satzarten, wären alle so lang, dass die längste Platz hat. Oder man wählt gleich eine übliche „Computer-Zahl“ wie 64, 128 oder 256. Das ist bei solchen Datenformaten ziemlich üblich, aber nicht wirklich zwingend. Im Prinzip kann jede Satzart eine eigene Länge haben, doch die muss dann genau festgelegt sein. Durch diese Regel, dass jede Satzart ihre Länge einzuhalten hat, kann man auf Zeilentrenner verzichten (viele Systeme mögen so was auch gar nicht) und kann alles hintereinander schreiben:

AK 4711    K0815   20130530 POS0001S123    0005000009990POS0002H456    0003000017950

Jetzt sehen Sie auch das Leerzeichen am Ende des Kopfsatzes.

Satzartkennungen
Eine Nachricht besteht üblicherweise aus verschiedenen Teilen, zum Beispiel einem Kopf wie oben, oft auch einem Nachsatz am Ende, dann Informationen zu einzelnen Sendungen oder Abrufen oder was auch immer, Details zu Positionen und so weiter. In vielen Formaten steht die Satzart gleich ganz vorne. Das ist ungemein praktisch, denn dann kann man nach einer einfachen Regel vorgehen:

Man sehe sich die ersten Zeichen der Datei an. Da steht, welche Satzart kommt. Anhand der Format-Definition weiß man nun, wie lang diese Satzart ist und welche Werte wo stehen. Und danach muss man sich einfach nur die nächsten Zeichen anschauen, dann weiß man, was als nächstes kommt.

Regeln für die Praxis
Das mit der exakten Länge jeder Satzart ist schöne Theorie, in der Praxis gibt es da ein paar Varianten. Wenn man ganz puristisch sein will, hat tatsächlich jede Satzart exakt ihre Länge einzuhalten und dazu notfalls mit Leerzeichen aufgebläht zu werden. Außerdem gibt es keine Zeilentrennung, alles steht direkt hintereinander. Ist wunderbar maschinenlesbar, für einen Menschen allerdings nicht wirklich schön (siehe oben). Daher kommt es häufig vor, dass die einzelnen Satzarten doch durch Zeilenumbrüche voneinander getrennt sind.  Das wiederum ist für den Computer nicht ganz so schön, weil er die Zeilenumbrüche als überflüssige Zeichen erkennen und bei der Längenberechnung berücksichtigen muss.

Eine Satzart mit 128 Zeichen hat so eigentlich 129 oder 130 (LF oder CRLF).
Wenn man grad dabei ist und die Satzarten durch Zeilenumbrüche trennt, kann man auch gleich die Füllzeichen am Ende weglassen. Damit wäre der Kopfsatz oben plötzlich nur noch 27 Zeichen lang, statt der eigentlich vorgegebenen 28. Nicht gerade das, was man sich ursprünglich bei diesem Format gedacht hat, aber in der freien Wildbahn trifft man diese Variationen immer wieder an.

Es gibt ein paar weitere Regeln, die nicht unbedingt zwingend, aber in bekannten Fix-Record-Datenformaten umgesetzt sind:

• Zahlenwerte werden meist mit führenden Nullen auf ihre definierte Länge aufgefüllt.
• Nicht-Zahlenwerte dagegen werden mit Leerzeichen, und zwar rechts vom eigentlichen Wert, aufgefüllt.
• Fließkommazahlen werden meist nicht mit Dezimaltrenner dargestellt, sondern mit einer festen Anzahl impliziter Nachkommastellen. Aus 3.05 wird dann z.B. (mit Auffüllung vorweg): 00003050. Hier sind also die letzten drei Stellen implizite Nachkommastellen. Wie viele es jeweils sind, wird normalerweise für jeden Wert einzeln vorgegeben.
• Auch ein Datum oder eine Zeitangabe kommt normalerweise ohne Trennzeichen aus, statt dessen sind die Formate yymmdd bzw. yyyymmdd und hhmm bzw. hhmmss sehr verbreitet.
• Die Satzartkennungen stehen meist am Anfang, es gibt aber auch (üblicherweise nur in der jeweiligen Firma genutzte) Formate, die die Kennungen erst irgendwo mitten in den Daten ansiedeln.
• Gibt es nur eine einzige Art von Datensätzen, kann man natürlich ohne Kennung auskommen.

Datenformate, die auf Fix Record aufbauen
Die zwei bekanntesten Vertreter sind Fortras und VDA (hier die älteren Formate). Beide wurden von Konsortien entwickelt und verabschiedet und haben ihre eigenen Artikel hier. Dazu kommt noch das ältere IDOC-Format von SAP, dem ebenfalls ein eigener Artikel gewidmet ist. Darüber hinaus werden aber oft z.B. Exporte aus Datenbanken so aufgebaut, vor allem, wenn die Daten aus einer AS400 alias IBM iSeries kommen. Da hat jede Spalte der Tabelle ihre definierte Länge, und oft genug steht alles gleich in einem immer gleich langen String in einer einzigen Spalte. Auch einige andere Programme nutzen für Ex- oder Importe Dateien im Fix-Record-Format, da diese sehr einfach zu lesen sind. Man setzt den Dateizeiger einfach immer z.B. 128 Zeichen weiter und hat automatisch den nächsten Datensatz, und auch innerhalb des Datensatzes springt man nur an die von Anfang an bekannten Positionen, um an die gewünschten Werte zu kommen. Als die meisten Programme ihre Daten noch in eigenen Strukturen auf Platte (oder gar Diskette) hielten, anstatt allgemein verfügbare Datenbanken zu nutzen (die es damals nicht so leicht verfügbar gab), war das die praktikabelste Lösung, wenn nicht alles in den Speicher passte.