Wer professionelles E-Commerce betreiben möchte, muss sich früher oder später Gedanken um Standardformate machen. Online-Händler, die neben dem Shop-System noch eine Warenwirtschaft einsetzen, müssen zwischen diesen Systemen Daten austauschen. Dies geschieht oft in Form von Dateien oder Datenströmen in bestimmten Formaten. In diesem Artikel erkläre ich, warum Sie dabei auf Standardformate setzen sollten.
Wozu Standardformate im E-Commerce dienen
Die wichtigen Bereiche im E-Commerce sind der Austausch von Bestellungen/Aufträgen (oder anderen Dokumenten wie Rechnungen) und der Austausch von Katalogdaten wie Produkte/Artikel mit den dazugehörigen Kategorien.
Wie in vielen Branchen haben sich im E-Commerce Standardformate etabliert.
Beispiele für Standardformate:
- openTRANS
- BMEcat
Man kann sich das vorstellen wie ein Steuer-Formular, das Sie vom Finanzamt kennen. Das Formular ist damit ein Standard für den Austausch von Steuer-Daten. Es gibt vorgefertigte Felder, in die bestimmte Werte eingetragen werden müssen. Es ist klar definiert, was in solchen Felder stehen darf, ob sie leer sein dürfen und ob Zahlen oder Buchstaben enthalten sein müssen. So kann der Sachbearbeiter im Finanzamt schnell erkennen, welche Steuern gezahlt oder erstattet werden müssen.
Für das E-Commerce gibt es ebenfalls Daten-Formate, die sinngemäß genau so funktionieren. Sie haben das Ziel, von Maschinen (also Software) gelesen und erstellt zu werden. Im Vordergrund steht dabei der reibungslose Datenaustausch, bestenfalls ohne, dass ein Anwender eingreifen muss.
Ein Standardformat ist dabei ein Datenformat, das festen Regeln folgt, und von verschiedenen Systemen verarbeitet werden kann. Dies ermöglicht eine große Kompatibilität zwischen verschiedener Software, die sonst keine Daten miteinander austauschen könnten.
Kommen wir auf das Steuerformular zurück. Dieses kann von Ihnen und einem beliebigen Steuerberater erstellt und vom Sachbearbeiter im Finanzamt gelesen werden. Sie müssen sich nicht jedes Mal auf eine individuelle Regel einigen.
Unterschied zwischen Standardformaten und offenen Formaten
Im Unterschied zu Standardformaten gibt es auch offene Formate. Das sind Dateien, die nur sehr wenige Regeln für den Aufbau der Dokumente haben.
Stellen Sie sich einmal vor, Sie würden für Ihre Steuererklärung kein Formular ausfüllen, sondern würden diese als Fließtext in einem Aufsatz beim Finanzamt abgeben, der eine von Ihnen gewählte, beliebige Struktur hat. Sie werden den Sachbearbeiter damit bestimmt nicht für sich gewinnen können. So ähnlich verhält es auch mit offenen Formaten.
Beispiele für offene Formate:
- Excel
- CSV
- XML
Offene Formate können fast beliebigen Inhalt haben. Das kennen Sie zum Beispiel aus Excel. Die einzige Regel in Excel lautet: Es ist einigermaßen tabellarisch. Es gibt über der tabellenartigen Struktur hinaus aber keinen festen Regelsatz.
Das Fehlen von Regeln macht eine automatische Verarbeitung fast unmöglich.
Daher muss beim Einsatz eines offenen Formats zunächst ein Regelwerk definiert werden. Darin ist dann definiert, in welchen Feldern welche Daten genau stehen, welche Länge sie haben usw. Solche Regeln sind in Standardformaten schon vorhanden. Eine Regel könnte sein, dass zum Beispiel eine Bestellung in Excel in der ersten Zeile Kopfdaten (wie die Adresse des Kunden) beinhaltet und in allen weiteren Zeilen die Positionsdaten (wie Artikelnummern, Menge).
Offene Formate können daher nicht ohne eine Konvertierung ausgetauscht werden. Wenn wir beim Beispiel der Bestellung im Excel-Format bleiben, müsste ein extra Konverter programmiert werden, der die Daten erst einmal für das Warenwirtschaftssystem aufbereitet.
Das ist meistens mit hohen Kosten verbunden. Die Wiederverwendbarkeit der Individuallösung ist ebenfalls eingeschränkt und überdauert den Wechsel der Warenwirtschaft oder des Shop-Systems meistens nicht.
(Einige wenige Warenwirtschaften können auch mit offenen Formaten wie CSV-Dateien umgehen – jedoch sind den Möglichkeiten auch dann oft enge Grenzen gesetzt, da auch hier gewisse Regeln befolgt werden müssen. Ob es zufriedenstellend funktioniert, kann daher erst nach einem Test gesagt werden.)
Welche Standardformate gibt es speziell im E-Commerce
Dokumente (Bestellungen, Aufträge, Lieferscheine, Rechnungen usw.)
openTRANS 1.0
Das Fraunhofer-Institut für Arbeitswirtschaft (Fraunhofer IAO) hat bereits 2001 angefangen einen Standard für Dokumente zu entwickeln, die im geschäftlichen Alltag ausgetauscht werden. Herausgekommen ist das openTRANS-Format, das neben Bestellungen auch noch weitere Dokumente (wie Rechnungen, Gutschriften) unterstützt. Das Format wird oft im deutschsprachigen Raum eingesetzt und basiert auf XML.
openTRANS 2.x
Es handelt sich um die zweite Version des openTRANS-Standards mit diversen Verbesserungen. Diese Version ist nicht mit Version 1 kompatibel.
IDoc
IDoc ist ein von SAP entwickeltes Format, das eigentlich für den Datenaustausch innerhalb von SAP-Anwendungen gedacht ist. Es ist möglich, dieses Format auch extern zu nutzen (warum das keine gute Idee ist, steht weiter unten). Das Format ist textbasiert.
Katalogdaten (Produkte)
BMEcat
Produktdaten können mit BMEcat ausgetauscht werden. Dieses Format wurde ebenfalls vom Fraunhofer IAO entwickelt und erschien erstmalig 1999. Es ist im deutschsprachigen Raum häufig anzutreffen und basiert auf XML.
OCI
OCI ist ein Katalogdaten-Standard, der von SAP entwickelt wurde. Er wird häufig bei großen E-Commerce-Plattformen eingesetzt, die Produktdaten aus SAP-Anwendungen beziehen. Das Format basiert auf XML.
Spezialformate
Es gibt Spezialformate, die nicht ausschließlich für das E-Commerce gedacht sind, aber dennoch dafür verwendet werden können. Manche Formate haben lediglich Berührungspunkte mit dem E-Commerce (z. B. beim Paketversand oder erst bei der Rechnung), andere werden nur von speziellen Branchen eingesetzt.
UN / EDIfact
Verfahren und Datenformat zum Austausch von Dokumenten im Geschäftsverkehr. Es sind diverse Unter-Formate definiert (wie zum Beispiel INVOICE für Rechnungen). Im Vordergrund steht die vollständige, rechtssichere und automatische Verarbeitung von geschäftlichen Dokumenten wie Aufträge, Rechnungen usw. Meistens wird mit dem Einsatz von EDIfact der automatische Prozess angestrebt. Deshalb ist es viel mehr als ein Format.
ZugFeRD
Beschreibt den Inhalt von PDF-Rechnungen als Anhang innerhalb der PDF-Datei. ZugFeRD wird zurzeit nur in Deutschland eingesetzt und dient der automatischen Rechnungsverarbeitung.
Fortras
Austausch von Dokumenten im Speditionsgewerbe.
VDE
Verfahren und Datenformat für den Austausch von Dokumenten (Aufträge, Rechnungen, usw.) im Geschäftsverkehr der Automobilindustrie zwischen Zulieferern und Automobil-Herstellern
DATANORM
Standardverfahren für den Artikel-/Stammdatenaustausch zwischen Herstellern, Fachhändlern und dem Handwerk in der Baubranche
DATEV-CSV-Format
Daten für Buchhaltungssysteme (wie Debitoren, Kreditoren, Buchungen)
DATEV Postversandformat
Ähnliche Daten wie beim DATEV-CSV-Format, nur für den Datenaustausch auf Disketten optimiert. Wir heute immer noch eingesetzt.
Warum Sie auf Standardformate setzen sollten
Der allergrößte Vorteil von Standardformaten ist, dass sie von vielen Softwareprodukten bereits im Standard unterstützt werden. Das heißt, dass kein Programmierer extra dafür beauftragt werden muss, das Format anzupassen.
Beispiel 1: Bestellungen
Ihr Online-Shop exportiert Bestellungen im openTRANS-Format. Sie möchten diese Bestellungen in Ihr Warenwirtschaftssystem einlesen. Wenn Ihre Warenwirtschaft das openTRANS-Format lesen kann, benötigen Sie keine individuell programmierte Schnittstelle.
Beispiel 2: Produktdaten
Sie setzen in dem Beispiel ein PIM (Product Information Management – Plattform zur Verwaltung von Produktdaten) zur Verwaltung der Artikeldaten ein. Diese Artikelstammdaten können sowohl in den Onlineshop als auch in das Warenwirtschaftssystem übertragen werden, wenn alle drei Systeme das BMEcat-Format verstehen.
Empfehlung
Was ist aber, wenn von weder der Online-Shop, noch das Warenwirtschafts-System eines der Standardformate unterstützt? In dem Fall muss man häufig auf Konverter zurückgreifen oder eine Schnittstelle programmieren lassen.
In dem Fall empfehle ich Standardformate einzusetzen und eine Schnittstelle für ein Standardformat erstellen zu lassen.
Der Grund ist simpel: Das Standardformat ermöglicht die Wiederverwendbarkeit der Schnittstellen beim Wechsel von Systemen. Wenn Sie zum Beispiel die Shop-Software wechseln wollen, aber die Warenwirtschaft bleibt, benötigen Sie lediglich eine Shop-Software, die das gewählte Standardformat unterstützt. Die Chancen stehen eben erheblich besser, dass es bereits günstige und funktionierende Lösungen zu den Standardformaten für das System gibt. Außerdem hat der beauftragte Programmierer bestenfalls bereits Erfahrungen mit dem Format und erzielt wesentlich schneller bessere Ergebnisse.
Welche Standardformate Sie im E-Commerce besser meiden sollten
(zumindest wenn es keinen wichtigen Grund dafür gibt)
Vor Formaten, bei denen es meistens kompliziert und damit aufwändig wird, möchte ich Sie im Vorfeld warnen. „Warnen“ klingt zwar sehr einschränkend, ist aber aus der Kosten-Nutzen-Perspektive zu sehen. Es gibt Standardformate, deren Implementierungsaufwand in der Regel sehr hoch ist.
Außerdem ist es bei manchen Formaten üblich, dass sehr individuelle Besonderheiten zugelassen sind. Diese zu berücksichtigen, ist selbst bei Standards mit oft mit großen Programmieraufwänden verbunden und die Wiederverwendbarkeit der Schnittstellen ist dennoch nicht garantiert. Welche Formate dies betrifft, stelle ich im Folgenden kurz dar.
IDoc
Extrem komplex
Eher für den internen Datenaustausch zwischen SAP-Anwendungen gemacht.
Bevor Sie IDoc implementieren, sollten Sie prüfen, ob es auch einfachere Alternativen gibt.
EDIfact
Selbst innerhalb des Standards von EDIfact-Dokumenten gibt es bei vielen Datenempfängern Besonderheiten zu beachten, die gesondert implementiert werden müssen. Üblicherweise werden dazu einmalig sogenannte Mapping-Tabellen erstellt, wo die Standards beider Systeme nochmals aufeinander abgestimmt werden müssen.
Die Datenkommunikation ist meistens nur mit bestimmten technischen Verfahren (z. B. Teleboxen, X.400, AS2) möglich, was der Einfachheit entgegensteht. In manchen Szenarien sind diese Mechanismen aber gewollt. EDIfact wird zum Beispiel dort eingesetzt, wo es um Rechtsverbindlichkeit und Beweisbarkeit zwischen den Parteien ankommt (zum Beispiel, wenn Sie Supermarkt-Konzerne als Kunden haben).
EDIfact ist im E-Commerce-Umfeld eher selten im Einsatz. Es greift in der Regel bei anderen Prozessen, zum Beispiel, bei Auslieferung von Waren an Großhändler.
Bei sehr großen hochintegrierten E-Commerce-Systemen trifft man EDIfact ab und zu an.
Standardformate in der Praxis
Sehr viele Software-Produkte, vom Shop-System bis ERP-Anwendung, werben damit, Standardformate zu unterstützen. Das ist grundsätzlich zu begrüßen. Wie bereits erwähnt, ist der vordergründige Nutzen von Standardformaten wie openTRANS die Wiederverwendbarkeit von Schnittstellen und Kompatibilität zwischen den Systemen.
In der Praxis funktioniert das leider nicht immer auf Knopfdruck. Viele Software-Systeme unterstützen nur bestimmte Teile der Standardformate oder setzen Anwendungsfälle nicht standardgemäß um.
Beispiel:
Lexware bietet in Warenwirtschafts-Programmen einen Import für Shop-Aufträge, die im Kern dem openTRANS-Format Version 1.0 entsprechen. Allerdings wurden ein paar Anpassungen gemacht, sodass es nicht mehr 100% Standardkonform ist.
Das heißt dann, dass die Warenwirtschaft keine Bestellungen aus einem Shop verarbeiten kann, die das „korrekte“ openTRANS-Format erzeugt.
Welches Standardformat sollte im E-Commerce eingesetzt werden?
Diese Frage ist gar nicht so leicht zu beantworten. Es gibt viele gute Standards, die funktionieren. Man muss diese Frage immer im Kontext aller angeschlossenen Systeme beantworten.
Für E-Commerce Schnittstellen-Lösungen im deutschsprachigen Raum hat sich openTRANS (Achtung: auf die Version achten) für Geschäftsdokumente wie Bestellungen etabliert.
Für Katalogdaten eignet sich BMEcat nach meiner Erfahrung sehr gut.
Allerdings sollte auch hier immer die jeweilige Produkt-Struktur berücksichtigt werden und über den Tellerrand hinausgeschaut werden. Wenn ihre Lieferanten Produktdaten vorzugsweise in DATANORM bereitstellen, hilft es Ihnen kaum, wenn Sie die Produktdaten nur im BMEcat-Format importieren können.
Fazit
Die klare Empfehlung lautet, auf Standardformate zur Datenübertragung zu setzen. Dies ermöglicht die größte Kompatibilität, weil die Formate gewissen Regeln unterworfen sind. Dies hat den Vorteil, dass viele Systeme den Standard unterstützen und auch gegen andere getauscht werden können. Die Chance, dass Software-Systeme auf Anhieb zusammenarbeiten, ist damit grundsätzlich gegeben. Sollte das nicht im Standard möglich sein, ist das Standardformat trotzdem eine clevere Basis für etwaige Schnittstellen-Programmierung.
Allerdings ist selbst beim Versprechen der Software-Hersteller auf Kompatibilität immer Vorsicht geboten. So kann es sein, dass einige Formate nur in Teilen umgesetzt werden oder sogar Veränderungen daran vorgenommen worden sind, sodass man nicht mehr von 100% dieses Standardformats sprechen kann. Aber auch das ist immer noch besser, als würde gar kein Standard eingesetzt werden.
Es hilft nur eins: Bevor man sich darauf verlässt, dass die Systeme wirklich zusammenarbeiten, muss der konkrete Anwendungsfall getestet werden. Dabei fallen häufig auch noch weitere Probleme auf, die nichts direkt mit der Format-Umsetzung zu tun haben. So müssen Artikelnummern oder Zahlungs- und Liefer-Konditionen häufig zwischen den Systemen angeglichen werden. Eine Ein-Klick-Lösung bekommt man leider so gut wie nie.
Wie sind Ihre Erfahrungen mit Standardformaten oder haben Sie ungelöste Probleme? Schreiben Sie mir dazu gern unter Kontakt.
