Elektronischer Datenaustausch

In der Theorie (also dem, was in der Presse als „Realität“ verkauft wird) leben wir in einer Welt, wo es kein Papier mehr gibt und virtuelle Agenten das Netz nach dem billigsten Preis durchforsten (eine Prognose der c’t von vor gut 30 Jahren die heute noch nicht real existiert).

Real gibt es viel Papier, wenn auch ein Grossteil davon durch PDF-Dokumente ersetzt wurde – der Versand geschieht dann Papierlos und wird nicht selten auf der Empfängerseite wieder ausgedruckt, eingescannt, an ein Archivsystem übergeben und der Ausdruck geschreddert.

Im Handel funktioniert das etwas besser: es gibt moderne XML-Standards wie OpenTrans, ZUGfeRD welche die Designfehler von EDI96a und SEDAS nahtlos zum Ärgernis der Softwareentwickler fortsetzen.

Bei solchen Standards spielt das „Henne-Ei“ Problem eine grosse Rolle: der Programmierer erzeugt aufgrund der recht komplizierten Dokumentation irgendeine Datei und sucht nun nach irgendeiner Stelle, wo man die Datei zur Prüfung einwerfen kann – die defacto nicht existiert.

Bei XML ist das eigentlich ganz einfach: es gibt für das jeweilige Datenformat entsprechende Dateien mit den Prüfvorschriften. Man muss also „nur“ eine entsprechende Software installieren und „Soll-Ist“ vergleichen – sofern es das „out of the box“ gäbe. Gibt es mit Reinigungsfunktion der Bürotasse und kostet einen 4-5stelligen Betrag.

Oder als Online-Service und da ist man sehr überrascht, welche „Profile“ (also unterschiedlichen Varianten) es für ein einzelnes Datenformat gibt.

Dejure sollte das Profil anhand der EDI-Daten erkannt werden, defacto muss man genau wissen was man da nun gegen was prüft.

Kein Wunder, dass sich ZUGfeRD bzw. sein Bastard „X-Rechnung BUND“ nur mit Zwang der Sorte „ab morgen nehmen wir nur noch Rechnungen ab 1.000 EUR digital entgegen“ mühsam etablieren kann.

Um Probleme bei der Implementation zu vermeiden haben etliche Anwender vereinfachte Versionen einer XML-Schnittstelle entworfen.

OpenTrans ist so ein Kandidat den man gut auf das abspecken kann, was im täglichen Betrieb notwendig ist. Oder man erfindet ein eigenes Format (meisstens ziemlich gruselig, aber auch irgendwie programmierbar).

Die Realisierungszeiten sind entsprechend: Ein EDI-Austausch in einem simplen und gut dokumentierten Format mit Beispielen für Bestellungen, Auftragsbestätigung und Rechnung ist hier in 2 Tagen wegprogrammiert (incl. Support und Prüfung auf der Gegenseite).

„Standards“ wie OpenTrans und gerade ZUGfeRD sind kostenfressende Monster deren Realisierungszeitraum sich gerne mal über 2 Jahre hinziehen weil jeder in den Vorgaben sein eigenes Süppchen kocht.

Dieser Beitrag wurde unter Allgemein veröffentlicht. Setzen Sie ein Lesezeichen auf den Permalink.