Warum direkte Einzelschnittstellen schnell teuer werden
Wer jeden Händler direkt aus dem ERP anbindet, verteilt EDI-Fachlogik über viele Stellen. Aus einer Rechnung wird für Partner A eine EANCOM-INVOIC über AS2, für Partner B eine Datei per SFTP. Zusätzlich unterscheiden sich Pflichtfelder, GLNs, Einheiten, Rundungen und Referenzen. Eine Änderung am ERP kann dadurch mehrere produktive Verbindungen gleichzeitig berühren.Ein EDI-Hub trennt diese Aufgaben. Das ERP spricht eine stabile, verständliche Sprache – beispielsweise JSON. Der Hub übernimmt daraus die Übersetzung in das erwartete Nachrichtenformat sowie Versand, Empfang und technische Rückmeldung.
JSON rein, EANCOM raus – und Bestellungen zurück
ONE4EDI ist für genau diese Rolle konzipiert. Aus den Daten eines beliebigen ERP entstehen GS1-konforme EANCOM-Nachrichten. Für den ausgehenden Prozess stehen Rechnungen als INVOIC und Lieferavise als DESADV im Mittelpunkt. Eingehende Bestellungen werden als ORDERS angenommen, validiert und als definiertes JSON an das führende System zurückgegeben.Damit bleibt die Fachlogik dort, wo sie hingehört: Preise, Artikel, Aufträge und Bestände liegen im ERP. Formatregeln und Partnerbesonderheiten werden zentral im EDI-Hub behandelt.
Der Standard allein reicht nicht
EANCOM schafft eine gemeinsame Grundlage, ist aber noch keine fertige Händleranbindung. Nahezu jeder Partner beschreibt in seiner Message Implementation Guideline – kurz MIG – eigene Pflichtangaben und Ausprägungen. Deshalb benötigt jede produktive Verbindung ein Partnerprofil mit GLN, Nachrichtenversion, Feldregeln, Transportparametern und Beispieldaten.Eine seriöse Einführung beginnt folglich nicht mit dem Versprechen „Plug-and-play für jeden Händler“, sondern mit der konkreten MIG, echten Belegen und einer dokumentierten Abnahme durch den Empfänger.
Transport, Archiv und Betrieb gehören dazu
Eine korrekt erzeugte Nachricht hilft wenig, wenn niemand bemerkt, dass sie im Versand hängen bleibt. ONE4EDI unterstützt AS2, SFTP, FTP und E-Mail. Status, technische Fehler und Wiederholungen werden sichtbar gemacht. Alarmierung und Verwaltungs-API geben dem Betrieb eine klare Sicht auf laufende Übertragungen.Ausgehende und eingehende Belege werden mit ihren Metadaten nachvollziehbar archiviert. So lässt sich später beantworten, welche Fassung wann erzeugt, geprüft und übertragen wurde. Das schafft eine belastbare Grundlage für GoBD-nahe Abläufe, ersetzt aber nicht die individuelle Prüfung des gesamten Archivierungsverfahrens.
Was heute belastbar ist – und was die erste Abnahme noch zeigen muss
Produktiv bewiesen ist derzeit die Verbindung BORD512 von Jeremias zu ITK. INVOIC, DESADV, ORDERS und AS2 sind implementiert und automatisiert getestet. Die Abnahme durch einen ersten angebundenen Händler steht noch aus. Ebenso entstehen belastbare Partnerprofile erst mit den jeweiligen MIGs und Testdaten.Der sinnvolle Einstieg ist deshalb eine Pilotaufschaltung mit klarer Grenze: ein Mandant, ein Händler und ein Format. Das Ziel ist konkret messbar – JSON kommt aus dem ERP, der Händler nimmt die Nachricht fachlich und technisch ab, Rückmeldungen sind sichtbar und der Vorgang ist nachvollziehbar archiviert.
Für welche Systeme eignet sich das?
Der Hub ist nicht an ein bestimmtes ERP gebunden. Viele Systeme können angebunden werden, sofern sie die vereinbarte JSON-Struktur liefern und Rückmeldungen verarbeiten können. Dadurch lässt sich EDI ergänzen, ohne ein gewachsenes ERP nur für einzelne Händlerformate tiefgreifend umzubauen.Mehr zum Modul: Auf der ONE4EDI-Produktseite sind Funktionsumfang, Transportwege und das empfohlene Pilotvorgehen kompakt zusammengefasst.