Chat with us, powered by LiveChat
7 min Lesezeit

Waren­wirtschaft bzw. ERP-System mit EDI-Anbindung

Der Versuch eines Vergleichs

Vor 25 Jahren kam der Film "Home Alone" (dt. Kevin – Allein zu Haus) in die Kinos. Die Geschichte ist relativ schnell erzählt – eine Familie aus Chicago bricht zum Weihnachts­urlaub nach Paris auf. Alles ist perfekt geplant und organisiert und alle freuen sich auf schöne Ferien — im Trubel des Abreise vergisst man jedoch versehentlich den kleinen Sohn zu Hause. Das wird allerdings erst im Flugzeug nach Paris bemerkt — eine Umkehr ist zu diesem Zeitpunkt naturgemäß nicht mehr möglich. Nach mühsamen Hin und Her findet mann dann doch wieder zusammen. Happy End mit viel Witz und Slapstick — 90er Jahre Kino von seiner besten Seite.


Kevin - Allein zu Haus
Kevin – Allein zu Haus

Im Hinblick auf ERP-Systeme und EDI lässt sich folgender Vergleich anstellen — leider im Gegensatz zu Hollywood oft ohne Happy End.

Auch bei ERP-Systemen wird viel in die Planung und Vorbereitung des Roll-Outs gesteckt. Nach dem erfolgten Roll-Out bemerkt man erst später — vorrangig durch Anforderungen von möglicherweise neuen Geschäftspartnern, dass eine EDI-Unterstützung für das ERP-System notwendig ist. Verfügt das ERP-System dann nicht über die notwendige Unterstützung von EDI-Prozessen, beginnen die Schwierigkeiten. Schnittstellen müssen nachimplementiert werden, Stammdatenprozesse müssen neu aufgesetzt werden und passende Dienstleister für die EDI-Abwicklung müssen gesucht werden. Dadurch entstehen hohe Kosten, die bei einer entsprechend frühen Berück­sichtigung von EDI hätten vermieden werden können.

ERP-Systeme und EDI

ERP-Systeme und elektronischer Datenaustausch stehen in einer symbiotischen Beziehung zueinander. Ohne ein ERP-System, welches strukturierte Daten importieren und exportieren kann, ist die Umsetzung von EDI-Prozessen schwierig. Es gibt zwar Lösungen auf Basis von Web EDI, diese eignen sich allerdings nur für geringe Belegvolumen. Umgekehrt braucht es strukturierte EDI-Prozesse um Daten aus einem ERP-System in ein anderes ERP-System zu bekommen. Das eine geht also ohne das andere nicht.

Bei der Einführung eines ERP-Systems sollten daher bereits jene Anforderungen berücksichtigt werden, die mit EDI-Prozessen in einem ERP-System verbunden sind. Wir haben im Folgenden die wichtigsten Anforderungen kurz zusammengefasst.

Strukturierte Import- und Exportformate

Kern einer jeden EDI-Anbindung an ein ERP-System ist der Import und Export von strukturierten Daten. Wie in der folgenden Abbildung er­sichtlich, ist die Import- und Export­schnittstelle in einem ERP-System für die Verarbeitung von externen Daten zuständig. Üblicherweise erfolgt die Datenübergabe an einen EDI-Konverter, welcher die weitere Verarbeitung der Daten übernimmt. Die Daten­übertragung an den EDI-Konverter kann dabei auf unter­schiedliche Weise erfolgen — z.B. per SFTP-Server oder mit fort­geschritteneren Konzepten, wie beispielsweise einer direkten API-Integration wie bei ERPEL-fähigen ERP-Systemen.


Exportinterface in einem ERP-System
Exportinterface in einem ERP-System

Der EDI-Konverter nimmt die exportierten Daten entgegen und konvertiert sie in das vom Geschäftspartner erwartete EDI-Format (zumeist irgendeine Art von EDIFACT). Den Geschäftspartnern werden die EDI-Daten anschließend über verschiedene Protokolle zugestellt. Umgekehrt werden von den Geschäftspartnern EDI-Daten entgegen genommen, vom EDI-Konverter konvertiert und anschließend wieder in dem Importformat zu Verfügung gestellt, welches das ERP-System importieren kann.

Wie ersichtlich, kann keine vernünftige EDI-Integration ohne eine Import-/Export­schnitt­stelle im ERP-System durchgeführt werden.

Stammdatenumfang im ERP-System und Exportierbarkeit

Sobald das Thema Import-/Export­schnitt­stelle geklärt ist, muss im Detail untersucht werden, welcher Datenumfang über die Schnittstelle importiert und exportiert werden kann. Je nach Geschäftspartner werden unterschiedliche Arten von Daten in den EDI-Dokumenten erwartet, welche auch entsprechend aus dem ERP-System exportiert bzw. in dieses importiert werden müssen.

Ein Beispiel für ein besseres Verständnis: Um eine EDIFACT-Rechnung für einen Geschäftspartner erstellen zu können, sind üblicherweise die folgenden Felder notwendig (gekürzte Darstellung):

  • GLN des Senders des Dokuments
  • GLN des Empfängers des Dokuments
  • Rechnungsdatum
  • Rechnungsnummer
  • Nummer der dazugehörigen Bestellung
  • Datum der dazugehörigen Bestellung
  • Nummer des dazugehörigen Lieferavis
  • Datum des dazugehörigen Lieferavis
  • Rechnungspositionen
  • Rechnungsbeträge wie Netto, USt, Brutto usw.

Die oben genannten Elemente kommen in so gut wie jeder EDIFACT-Rechnung vor. Soll die Rechnung aber an EDEKA gehen, so sind zusätzliche Angaben notwendig. So muss beispielsweise eine Abkommensnummer mit übermittelt werden, sowie am Ende der Rechnungsübermittlung eine eigene Rechnungsliste (also eine Zusammenfassung der vorher übermittelten Rechnungen) übermittelt werden.

Der EDI-Konverter kann die EDEKA EDIFACT-Rechnung nur dann erzeugen, wenn alle von EDEKA geforderten Daten im Exportformat des ERP-Systems enthalten sind. Doch nur dann, wenn (i) das Exportformat den notwendigen Umfang hat und (ii) die Daten auch im ERP-System gepflegt werden, funktioniert dieser Export.

Auch diese Anforderung sollte bei der Anschaffung eines ERP-Systems bereits früh in die Anforderungs­analyse mit einbezogen werden, um später eine böse Überraschung zu vermeiden.

Prozessabbildung im ERP-System

Ein weiterer wichtiger Aspekt ist das Zusammenspiel der externen EDI-Prozesse mit den internen Prozessen des ERP-Systems. Die folgende Abbildung zeigt einen EDI-Prozess, wie er beispielsweise im Handel sehr oft verwendet wird.

Der Geschäftspartner bestellt mittels EDIFACT ORDERS, welche an­schließend konvertiert und in das ERP-System importiert werden. Um doppelte Dateneingabe zur vermeiden und die Vorteile von EDI so gut wie möglich ausnutzen zu können, werden die Bestelldaten übernommen und eine Bestell­bestätigung wird generiert. An der Bestellbestätigung können vom ERP-Benutzer (zumeist ein Sach­bearbeiter) noch Änderungen vorgenommen werden. Anschließend wird die Bestellbestätigung versendet.


EDI-Prozesse in einem ERP-System
EDI-Prozesse in einem ERP-System

Die Bestellbestätigung wird vom EDI-Konverter in eine EDIFACT ORDRSP-Nachricht (Order Response) übersetzt und zugestellt. Bevor die eigentliche Ware versendet wird, muss an den Geschäftspartner ein Lieferavis übermittelt werden. Auch hier werden die Daten wiederum aus der Bestellbestätigung übernommen, um doppelte Dateneingabe zu vermeiden. Anschließend übernimmt der EDI-Dienstleister wieder die Konvertierung und Zustellung.
Am Ende wird auf Basis der Lieferavis-Daten die Rechnung erstellt und an den Geschäftspartner übermittelt.

Wie auf der linken Seite der Grafik abgebildet, wird die ursprüngliche Bestellung schrittweise zur Rechnung verfeinert, wobei immer eine Datenübernahme aus dem darüberliegenden Dokument erfolgt. Bei EDI spricht man in diesem Zusammenhang auch vom so genannten Turnaround-Verfahren. Durch dieses Verfahren werden notwendige Daten automatisch aus den vorangegangenen Dokumenten übernommen (eine Rechnung braucht beispielsweise eine Referenz auf die Bestellnummer, das Bestelldatum sowie die Lieferscheinnummer und das Lieferscheindatum) und Eingabefehler durch manuelle Verarbeitung können vermieden werden.

Voraussetzung für das Turnaround-Verfahren ist die entsprechende Umsetzung der Prozesse im ERP-System. Auch dies sollte während der ERP-Anforderungsanalyse bereits früh beachtet werden.

Zusammenarbeit mit einem EDI-Dienstleister

Eine weitere wichtige Überlegung ist die Wahl eines geeigneten EDI-Dienstleisters, um die notwendigen Konvertierungen und Anbindungen der Geschäftspartner umzusetzen. Hier gibt es prinzipiell zwei ver­schiedene Möglichkeiten:

  1. Anschaffung eines eigenen lokalen EDI-Konverters

  2. Auslagerung der EDI-Abwicklung an einen externen Dienstleister

Anschaffung eines eigenen lokalen Konverters

Die Anschaffung eines eigenen lokalen EDI-Konverters lohnt sich nur für Unternehmen, die im Unter­nehmen selbst über ein hohes Maß an EDI-Know-How verfügen. Der EDI-Konverter muss von geschultem Personal bedient werden, sodass Wartungsarbeiten (z.B. Anpassungen von EDI-Formaten) möglichst rasch umgesetzt werden können. Zusätzlich zum lokalen Konverter muss noch ein eigener EDI-Dienstleister beauftragt werden, der die Anbindung der Geschäftspartner über die geforderten Protokolle vornimmt (AS2, X.400, OFTP, SFTP, etc.). Ein lokaler Konverter kostet einen fünfstelligen Eurobetrag, wobei bei größeren Lösungen auch sechststellige Beträge eher die Regel, als die Ausnahme sind. Neben den Anschaffungskosten werden bei den meisten Lösungen auch jährliche Wartungspauschalen fällig.

Auslagerung an einen externen Dienstleister

Besser skalierend ist die Auslagerung der EDI-Prozesse an einen externen Dienstleister, der neben der Datenkonvertierung auch gleich die Datenübermittlung an die einzelnen Partner vornimmt. Der externe EDI-Dienstleister arbeitet eng mit dem EDI-Customizer zusammen, sodass der Datenaustausch zwischen ERP-System und EDI-Konverter möglichst reibungslos funktioniert. Im Unterschied zu einem lokalen Konverter fallen keine hohen Einmalkosten für die Beschaffung oder Wartungskosten an — bezahlt wird nur die Einrichtung der jeweiligen Dokumentenkonvertierung.

Moderne Lösungen, wie beispielsweise ecosio.ERPEL (ERPEL = ERP Exchange Language), ermöglichen eine zusätzliche Minimierung von Reibungsverlusten, indem die Import- und Exportschnittstellen in Richtung EDI-Dienstleister bereits Teil des ERP-Systems sind. Somit ist eine direkte Datenübergabe ohne zwischen­geschaltete Lösungen, wie beispielsweise einem SFTP-Server, möglich.

Noch Fragen?

Sie evaluieren die Einführung eines neuen ERP-Systems und haben noch Fragen zur Integration von EDI-Prozessen? Wir helfen Ihnen gerne weiter — nehmen Sie mit uns Kontakt auf oder benutzen Sie unseren Chat!

Themen

Meistgelesen

Weiterlesen

Cookie Einstellungen

Hier sind alle Cookies aufgelistet die für Marketing Zwecke eingesetzt werden
LinkedIn (cn_LinkedINActive)
LinkedIn verwendet Cookies unter anderem um Ihre Einstellungen zu nutzen, Ihnen eine personalisierte Nutzererfahrung bieten zu können, und Ihnen auf Sie zugeschnittene Werbung anzeigen zu können.
Google Analytics (cn_AnalyticsActive)
Wird verwendet um Daten über das Nutzerverhalten und das Gerät des Nutzers an Google Analytics zu senden. Trackt den Besucher über verschiedene Geräte und Marketing Kanäle
Facebook (cn_FacebookActive)
Wird von Facebook genutzt, um eine Reihe von Werbeprodukten anzuzeigen, zum Beispiel Echtzeitgebote dritter Werbetreibender.
Google Adwords (cn_AddWordsActive)
Wird verwendet um Benutzer zu identifizieren, die die Website via Google Werbeanzeigen besuchen.
Pardot (cn_PardotActive)
Pardot verwendet Cookies, um Ihre Interaktion mit unserer Website sinnvoller zu gestalten. Sie helfen uns, die Nutzung unserer Websites besser zu verstehen, damit wir die Inhalte für Sie maßschneidern können.