Das Data Exchange Framework verstehen Teil 1

Das Data Exchange Framework ist Grundlage für eine ganze Reihe an Funktionalitäten. Sei es den Export oder den Import von Dateien in und aus Buchungsblätter, das Erstellen von Zahlungsdateien oder das Einlesen von Kontoauszügen.

Außerdem hat es eine sehr flexible Struktur, so dass es auch leicht an andere Anforderungen angepasst werden kann. Die Flexibilität bringt es mit sich, dass sehr viel Eingerichtet werden kann. Dazu erreichen uns immer wieder Support Fälle. Diese Blog Serie macht anhand von konkreten Beispielen die Anwendung deutlich.

Ein Blick auf den folgenden MSDN Eintrag erklärt die grundlegende Arbeitsweise im Detail. Insbesondere die folgenden Schaubilder sind zum Verständnis sehr hilfreich.

https://msdn.microsoft.com/en-us/library/dn495318(v=nav.80).aspx

Ganz kurz zusammengefasst, lässt sich sagen, dass wir in den Tabellen 1222 – 1227 eine Schnittstellendefinition hinterlegen können. Es werden Textdateien mit variabler Länge und Trennzeichen oder mit fester Länge sowie XML Dateien unterstützt.

Beim Import werden die Dateien zuerst einmal in die Tabellen 1220 / 1221 eingelesen, um dann über eine Mapping Codeunit in die richtigen Tabellen kopiert zu werden.

Dazu werden in der Posting Exchange Definition Codeunits und XML Posts für die verschiedenen Zwecke hinterlegt. Die Screenshots sind aus der Version Microsoft Dynamics NAV 2015 in der Vorversion gab es weniger Möglichkeiten Codeunits zu hinterlegen, das Prinzip ist jedoch auch dort genauso.

In diesem ersten Teil soll es darum gehen, eine sehr einfache Textdatei mit fester Feldlänge und ein paar Gemeinheiten als Kontoauszug einzulesen. Im zweiten Teil schauen wir uns an, wie wir eine Datei mit variabler Feldlänge in ein Buchblatt importieren können. In weiteren Teilen werden wir uns auch einige Beispiele für den Export anschauen und uns genauer mit den Möglichkeiten zu beschäftigen, die uns der SEPA Schema Viewer bietet. Am Ende schauen wir uns dann noch an, wo Sie eingreifen können, wenn Sie die Struktur der Posting Exchange Definition nutzen, aber etwas ganz Anderes im- oder exportieren wollen. Wenn Sie Fragen haben, gerne in den Kommentaren ich versuche die Antworten in den folgenden Beiträgen unterzubringen, wenn eine direkte Antwort zu ausführlich werden würde.

Starten wir also mit einer Datei, die folgendes Format hat:

00Die Kopfzeile kann ganz anders aussehen
11010715Verwendungszweck Zeile 1                          000000000012345S
11020715Verwendungszweck Zeile 2                          000000000033345S
11030715Verwendungszweck Zeile 3                          000000000444445H
11040715Verwendungszweck Zeile 4                          000000000033345H
11050715Verwendungszweck Zeile 5                          000000000022245S
14Erweiterter Verwendungszweck
22Eine Endzeile

Sie können die Daten für die Datei einfach mit Copy und Paste in einen Editor kopieren und dann bei sich speichern. Überprüfen Sie zur Sicherheit noch einmal, dass die Datenzeile auch wirklich zur Beschreibung passt und nicht zusätzliche Leerzeichen mit kopiert wurden. Das Beispiel wurde erstellt auf de Deutschen Version Microsoft Dynamics NAV 2015 Cumulative Update 8.

Erster Schritt ist es nun eine neue Posting Exchange Definition anzulegen:

Die Datensätze, die wir einlesen wollen 5 Spalten - das können wir in den Zeilen eintragen und auch die Spalten wie in der Datensatzbeschreibung angegeben hinterlegen. In Data Line Tag können wir „11“ hinterlegen. Tun wir das können wir uns die Eingabe von Header und Footer Tag sparen. Nur das was als Datum gekennzeichnet ist, wird so eingelesen.

Beim Import darf es nur einen Datensatz in der Posting Line Definition geben. Die Posting Column Definition wird pro Column Line Definition hinterlegt. Wichtig ist die Angabe der Anzahl der Spalten.

Damit fehlt jetzt nur noch das Mapping. Aufzurufen über die Funktion Field Mapping Bei der Posting Line Definition. Sie können zu jeder Zeile mehrere Mappings anlegen, wenn Sie zum Beispiel Werte gleichzeitig in mehrere Tabellen einlesen wollen.

Zur Demonstration lesen wir in die Tabelle 274 ein. Als Mapping Codeunit verwenden Sie in diesem Fall 1248 „Process Bank Acc. Rec Lines“ denn wir lesen in die Bank Account Reconciliation Lines ein.

Das eigentliche Field Mapping zeigt hier auch einige Besonderheiten. Zum einen verwenden wir dort nur Daten die wir auch in der Datenbank speichern wollen. Es ist also nicht notwendig alle Spalten zuzuweisen. Spalte 1 fehlt also hier. Bei dem Betrag haben wir den Multiplier gesetzt – denn in unserer Datei gibt es kein Trennzeichen für Nachkommastellen. Dann sehen Sie, dass unsere Soll- / Haben Spalte auch auf das Feld Statement Amount gemappt wird. Das führt dazu, dass das Vorzeichen des Betrages verändert wird, wenn der Inhalt der Spalte Soll / Haben unserem Negative Line Identifier entspricht.

Dazu eine Anmerkung in Cumulative Update 9 ist es noch so, dass ein eventueller Negative Line Identifier hinter dem Betrag stehen muss. Steht dieser vor dem eigentlichen Betrag, so wird zuerst eine 0 mit -1 multipliziert mit dem Ergebnis 0 und dann der Betrag eingetragen. Eine Änderung dazu wird im nächsten Cumulative Update enthalten sein. Wichtig ist dies nur dann, wenn das Vorzeichen nicht im Betrag selbst mit hinterlegt ist, sondern so wie hier als anderes Zeichen in der Datei steht. Wenn im Betrag direkt -100055 steht zum Beispiel dann benötigen Sie auch kein extra Mapping für die negativen Werte.

Damit haben wir die Einrichtung der Posting Exchange Definition abgeschlossen. Um diese nun in der Anwendung nutzbar zu machen fehlen noch zwei Schritte.

1. Im Bank Import / Export Setup benötigen Sie einen neuen Eintrag. Diese kann so aussehen:

Die Codeunits müssen Sie hier nicht angeben.

2. Der obige Eintrag muss einer Bank zugewiesen werden.

In meinem Fall habe ich die „GIRO“ Bank genutzt. Nun können wir die Datei importieren. Ich bin dazu in das Zahlungsabstimmungsbuchblatt und habe einen neuen Import für die Bank GIRO gestartet.

In der Beispieldatei gibt es auch noch einen Satz mit Typ 14. Dieser lässt sich so nicht einlesen. Wenn wir eine Datei mit fester Feldlänge importieren, dann können wir ohne Anpassung an den Codeunits genau ein Format importieren. Die Datensätze wie sie in der Beispieldatei auftauchen also Typ 00, 22 und eben 14 können wir jedoch ignorieren, sodass wir die Datei einlesen können auch wenn Sie nicht zu 100% aus der gleichen Satzlänge besteht.

Mit freundlichem Gruß

Andreas Günther

Microsoft Dynamics Germany