| Format |
Beschreibung |
Vorteile |
Nachteile |
| ABAS |
ABAS ist eine Datenformat für das gleichnamige ERP-System.
|
Wenn Sie ABAS als ERP einsetzen, wird das das Format Ihrer Wahl sein. |
Leider ist das Format sehr abhängig von der ABAS-Installation und muss daher wahrscheinlich individuell auf Ihre Installation angepasst werden. |
| cXML |
cXML ist ein sehr umfangreiches Datenformat das in XML kodiert wird.
Dieses Datenformat hat eine eigene Webseite, auf der Sie viele Informationen finden:
|
Das Datenformat ist gut dokumentiert und wird u.a. von ARIBA® und COUPA® als Standard verwendet. |
Durch den großen Umfang das Formats gibt es sehr viele Dialekte und eine Anpassung des Adapters an diese Dialekte ist oft notwendig (z.B. sind die Formate von COUPA® und ARIBA® nicht kompatibel). Dies macht Projekte mit diesen Format oft langwierig und daher teuer. |
| Dynamic 365 Business-Central® |
Das ERP-System von Microsoft® ist eine moderne, Cloud-basierte Lösung mit vielen Freiheitsgraden. Für das ERP-System gibt es viele Systemhäuser, die Erweiterungen des Basissystems anbieten. EDIMATO bietet eine Schnittstelle zum Basis-System, die Sie selbst installieren können.
Dazu gibt es Erweiterungen für folgende Systemhäuser: COSMO.
|
Dadurch das EDIMATO und Business Central beides cloud-basierte Systeme sind, ist eine performate und auf das ERP-System zugeschnittene Verbindung schnell aufgebaut. |
Business-Central® wurde von vielen Systemhäusern erweitert. Um alle relevanten Daten auszutauschen, ist daher die Kommunikation mit dem Basis-System häufig nicht ausreichend. Falls wir für Ihr Systemhaus noch keine Schnittstelle anbieten, müssen wir diese dann individuell für Sie aufbauen. |
| EDIFACT |
EDIFACT ist ein Datenformat, dass in den 80er Jahren entstand und durch die UN herausgegeben wird.
"EDIFACT" wird häufig synonym mit "EDI" verwendet, es ist aber nicht das gleiche.
Derzeit unterstützen wir die Versionen D93A, D96A und D97A. Wir haben aber auch schon einzelne Nachrichtentypen mit D10A realisiert.
Auf der Seite der UN finden Sie viele weitere Informationen:
|
Dies ist ein sehr weit verbreitetes Datenformat, dass viele Nachrichtentypen unterstützt.
Unsere EDIFACT-Schnittstelle ist so programmiert, dass sie sehr viele EDIFACT-Dialekte sofort auslesen kann. Die Verarbeitung von Nachrichten, die an uns geschickt werden sollte dadurch sofort möglich sein. |
Jede EDIFACT-Anbindung ist ein eigenes Projekt und kostet Zeit und Geld, weil der EDIFACT-Standard viel größer ist, als die Möglichkeiten eines normalen ERP-Systems. Daher hat jeder Anwender "Guidelines", die befolgt werden müssen, wenn man Daten austauscht. Dem kann auch EDIMATO nicht entkommen: Wenn wir EDIFACT-Nachrichten ausgeben, müssen wir daher die Guidelines des Empfängers programmieren. |
| EDIGURUS |
EDIGURUS ist das Basis-Format unserer deutschen Schwesterfirma.
Sie können neben dem nacken JSON ("EDIGURUS 1 / JSON") das Format auch eingebettet in ein PDF ("EDIGURUS 1 / PDF") austauschen.
Ein ausführliche Beschreibung der Version 1 des Formats finden Sie hier:
|
Geringe Anzahl Felder, einfacher Aufbau. |
Geringe Verbreitung außerhalb unserer Plattform.
"EDIGURUS" ist im Vergleich zu "EDIMATO" (s.u.) etwas komplexer. Daher raten wir dazu, Projekte eher in "EDIMATO" umzusetzen. |
| EDIMATO |
EDIMATO ist das Basis-Format unserer Plattform. Es ist ein sehr schlankes JSON-Format.
Sie können neben dem nacken JSON ("EDIMATO 2 / JSON") das Format auch eingebettet in ein PDF ("EDIMATO 2 / PDF") austauschen.
Eine detaillierte Beschreibung der Version 2 von EDIMATO finden Sie hier:
|
Der große Vorteil dieses Datenformats ist es, dass es einen geringen Umfang hat, der aber für die meisten Unternehmen ausreichend sein sollte. Mit ca. 150 verschiedenen Feldern kann die gesamte Kommunikation zwischen Firmen abgebildet werden. Die Daten sind zudem ohne Redundanzen, sodass immer klar ist, in welchem Feld welcher Wert steht. Durch den geringen Umfang ist das Datenformat für Programmierer sehr überschaubar und Projekte schnell umsetzbar. |
Geringe Verbreitung ausserhalb unserer Plattform. |
| ESIS comfort |
ESIS comfort wurde von SEW-EURODRIVE in Zusammenarbeit mit FESTO und SICK entwickelt. Es ist ein Format, das auf XML basiert.
Der von SEW-EURODRIVE bereitgestellte Service "ESIS comfort" läuft auf unserer Plattform, daher unterstüzen wir selbstverständlich alle Versionen dieses Datenformats.
Ausführliche Informationen finden Sie auf der Seite von SEW-EURODRIVE:
|
Der Umfang von ESIS comfort ist sehr gering. Daher können Projekte sehr schnell realisiert werden.
Das Datenformat ist stark an die Bedürfnisse des Mittelstands angepasst. |
Durch den geringen Umfang des Datenformats können ggf. nicht alle benötigten Daten übertragen werden. |
| Infor-LN |
Dieses Datenformat wurde für das frühere BAAN-ERP-System (jetzt: Infor-LN) unter dem Namen BEMIS entwickelt.
|
Gut standardisiertes Format, das ähnlich wie EDIFACT aufgebaut ist. |
Da das Format nur an die Bedürfnisse von Infor-LN / Baan angepasst ist, hat es außerhalb dieser ERP-Systeme keine Verbreitung. |
| myOpenFactory |
myOpenFactory ist ein proprietäres XML-Format, das die myOpenFactory-Plattform verwendet.
EDIMATO kann sich direkt mit der myOpenFactory-Plattform verbinden, so dass eine Integration leicht möglich ist.
|
Ausgewogenes Datenformat mit dem Fokus auf die diskrete Fertigung. |
Außerhalb der myOpenFactory-Plattform wenig verbreitet. |
| openTRANS |
Das auf XML basierende Datenformat wurde vom Fraunhofer IOA in Stuttgart für die Fertigungsindustrie entwickelt.
Wir unterstützen die Version 1.0
|
Das XML-Format ist gut strukturiert und hat einen Umfang, der für die meisten Anwendungsfälle ausreichend ist. Das Format wird von verschiedenen Anbietern im EDI-Umfeld standardmäßig angeboten. |
Durch die XML-Kodierung und eine starke hierarchische Strukturierung ist das Format von der Datenmenge her relativ groß. |
| Oxaion® |
Proprietäres Format des ERP-Systems Oxaion®.
|
Sehr gut an das ERP-System Oxiaon® angepasst. |
Die Implementierung in Oxiaon® ist nicht vollständig, so dass von einem Oxaion®-Programmierer noch einige Änderungen programmiert werden müssen, bevor die Kommunikation funktioniert. |
| PDF mit KI auslesen |
Diese Konvertierungsmethode nimmt beliebige PDFs, die an EDIMATO z.B. per E-Mail weitergeleitet werden, entgegen und liest die Daten daraus mit Hilfe künstlicher Intelligenz aus.
|
ast alle PDFs, die Sie von Ihren Geschäftspartnern bekommen, können ad hoc in Daten für Ihr ERP-System umgewandelt werden.
Zur Umsetzung der Konvertierung muss weder die IT Ihres Geschäftspartners, noch Ihre eigene IT irgendetwas tun.
Der Roll-Out auf sehr viele Geschäftspartner ist sehr schnell möglich. |
Die KI kann in seltenen Fällen (<0,1%) die Daten nicht richtig zuordnen. In diesen Fällen geht Ihnen das PDF dann wie bisher zu. D.h. Sie stellen sich nicht schlechter als vor der Einführung der KI. |
| PDFs mit Formatierung auslesen |
Diese Konvertierung kann Daten aus PDFs extrahieren. Dazu muss der Konverter aber angelernt werden, was je nach Komplexität des PDFs 2 bis 3 Stunden dauert.
Diese Art des Auslesens wurde inzwischen von "PDF mit KI auslesen" (s.o.) abgelöst, was flexibler ist und kein Anlernen benötigt.
|
Falls ein PDF durch die KI überhaupt nicht verarbeitet werden kann, hat man mit diesem Konverter die Möglichkeit, die Daten dennoch zu extrahieren. |
Der Konverter muss angelernt werden. Wenn das PDF-Format durch der Geschäftspartner geändert wird, muss er erneut angelernt werden. |
| SAP®-IDoc |
SAP®-IDoc ist ein XML-Format, dass von SAP® bereit gestellt wird. Dieses Format findet inzwischen nicht nur bei SAP® sondern auch bei EDI-Systemen Verbreitung, da es einen Umfang hat, der fast alle Bedürfnisse abdeckt.
|
Realitiv gut standardisiert (wenn es nicht von EDI-System "neu" interpretiert wird)
Da viele Kunden auf EDIMATO damit arbeiten, bieten wir eine sehr weitereichende Schnittstelle an, die ad hoc Einsatz-bereit ist.
Sie können Ihr SAP®-System selbstständig mit EDIMATO verbinden |
Teilweise überflüssige Daten, die für eine EDI-Kommunikation irrelevant sind. |
| Tabellen |
Diese Konvertierung arbeitet mit Tabellen, deren Zeilen immer gleich aufgebaut sind.
EDIMATO unterstützt die Formate "*.csv" (Komma-separierte Werte), "*.tsv" (Tabulator-separierte Werte) und "*.xlsx" (Excel).
Sie können den Aufbau der Tabelle selbst definieren.
|
Dies ist eine einfache und schnelle Methode, um eine Schnittstelle aufzubauen. |
Da es nur eine Zeile pro Position gibt, sind komplexere Datenstrukturen nicht abbildbar. |
| UBL |
"UBL" steht für "Universal Business Language". UBL ist von der Komplexität und vom Umfang her ein Nachfolger von EDIFACT auf der Basis von XML.
EDIMATO unterstützt die Version 2.1 von UBL.
Eine ausführliche Beschreibung finden Sie hier:
|
UBL ist ein umfangreiches Datenformat, das alle Möglichkeiten von EDI enthält. |
Durch die Größe des Datenformats ist es sehr schwierig in der Handhabung. Auch hier sind Guideline üblich, die genau definieren welche Felder übertragen werden sollen (wie bei EDIFACT).
Viele UBL-Konverter sind sehr unflexibel und verzeihen keinerlei Abweichungen vom vordefinierten Format. Dies macht Entwicklungen von UBL-Schnittstellen relativ aufwändig. |
| Viele Datenformate |
Dieser Konverter versucht das Format jeder Datei zu erkennen, die er geschickt bekommt und startet danach das Auslesen der Nachricht. Sie können an diesen Konverter alle hier aufgelisteten Datenformate schicken. Wenn PDFs geschickt werden, werden diese mit Hilfe der KI ausgelesen.
Falls das Format der Datei nicht ausgelesen werden kann, wird die Nachricht an eine von Ihnen vorgegebene E-Mail-Adresse weitergeschickt, so dass nichts verloren gehen kann.
|
Der Konverter liest, was man ihm schickt und wandelt es in einen Datensatz für Ihr ERP-System um. |
Es kann dazu kommen, dass das Format verarbeitet werden kann, weil unsere Software es nicht kennt oder weil das Format nicht eindeutig erkannt werden kann. In solchen Fällen ist es besser, einen fixen Konverter zu verwenden. |
| XRechnung |
XRechnungen sind ein XML-basiertes Datenformat, dass bis 2028 in Deutschland verpflichtend eingeführt werden soll.
Wir unterstützen die folgenden Versionen diese Datenformats: 2.2 CII (XML oder eingebettet in ein PDF), 3.0.1 CII + UBL, 3.0.2 CII + UBL. Die "CII"-Varianten des Formats basieren auf dem ZUGFeRD-Format und sind zwar groß aber noch übersichtlich. Die "UBL"-Varianten des Formats sind wie oben beschrieben sehr komplex.
Weitere Informationen zu dem Datenformat finden Sie hier:
|
Schon seit dem 01.01.2025 muss jedes Unternehmen solche XRechnungen verarbeiten, wenn sie vom Lieferanten geschickt werden. Durch die Verpflichtung der Umsetzung bis 2028 wird dieses Format in Deutschland und Europa eine weite Verbreitung erfahren. |
Man merkt dem Datenformat an, dass an seiner Entwicklung sehr viele, große Unternehmen mit Ihren Partikularinteressen gearbeitet haben. Anstatt das Format schlank zu halten, wurde einfach alles aufgenommen und das Format unnötig aufgeblasen. Die Komplexität wird durch interne Abhängigkeiten der Datensegmente verstärkt. |