EDIFACT, openTRANS und XML direkt in büro+
Ihr grösster Kunde verlangt EDIFACT. Die Datei selbst ist selten das Problem, Ihre Daten sind es.
Wir übersetzen zwischen beidem, und zwar dort, wo Ihre Daten schon liegen: in büro+. Ohne zweites System, ohne Gebühr pro Nachricht. Die Übersetzungslogik bleibt offen einsehbar und änderbar, auch in fünf Jahren.
Oben der übliche Weg mit zwei Zusatzsystemen, unten die Abbildung direkt im ERP.
Beim üblichen Weg entsteht eine zweite Datenhaltung, und die Zuordnungsregeln liegen in einer Zwischenschicht, in die Sie nicht hineinsehen. Bei uns liegt die Logik in Ihrer Warenwirtschaft, nachvollziehbar und änderbar.
Verlangt Ihr Abnehmer ein bestimmtes Clearing-Center, bleibt das in der Kette. Das entscheidet er. Was wegfällt, ist das eigene EDI-System auf Ihrer Seite.
Die Guideline sagt, wie die Nachricht aussehen muss. Woher die Werte in Ihrem Betrieb kommen, steht dort nicht. Ein Beispiel, ein einziges Feld:
Die Guideline verlangt
Länge in Millimetern, als Zahl → 1250
Bei Ihnen steht
„Profil 40 x 1250“
Als Freitext in einem Artikelfeld, gepflegt von drei Leuten über zehn Jahre.
Aus welchem Feld holen wir den Wert?
Wie zerlegen wir die Zeichenkette?
Was, wenn das Feld leer ist?
Wer pflegt es bei neuen Artikeln?

Vier Entscheidungen, und wir sind beim ersten von dreissig bis fünfzig Feldern. Bei einem Stahlhändler hängt die Abnahme derzeit an der Frage, in welchem Format der Abnehmer die Länge erwartet. Das beantwortet nur er selbst.
EDI kauft man nicht. EDI baut man.
Vier Abschnitte zum Aufklappen. Wer EDI kennt, überspringt sie.
EDI heisst Electronic Data Interchange, elektronischer Datenaustausch. Zwei Firmen tauschen Bestellungen, Bestätigungen und Rechnungen direkt von Software zu Software aus. Keine Mail, kein PDF, kein Mensch, der etwas abtippt.
Warum nicht einfach ein PDF? Weil ein PDF für Menschen gemacht ist. Ein Computer kann daraus nicht zuverlässig erkennen, welche Zahl die Menge und welche der Preis ist. EDI hat darum eine feste Grammatik: an einer bestimmten Stelle steht immer die Artikelnummer, an einer anderen immer die Menge.
Warum Ihr Grosskunde darauf besteht. Ein Konzern verarbeitet Tausende Bestellungen pro Woche. Von Hand einzutippen wäre teuer und fehlerhaft. Wer nicht elektronisch liefert, verliert die Lieferantennummer, und damit das Geschäft, nicht die einzelne Bestellung.
Und im Standard Ihrer Software? Im Standard ist es nicht enthalten, denn jeder Abnehmer macht andere Vorgaben. Mitgeliefert werden kann ein Formatwandler. Was er nicht mitliefert, steht oben.
UNB+UNOC:3+SUPPLIER_GLN:14+BUYER_GLN:14+260907:1030+4711' UNH+1+ORDERS:D:07A:UN' BGM+220+1000000001+9' DTM+137:20260907:102' NAD+BY+BUYER_GLN::9' NAD+SU+SUPPLIER_GLN::9' LIN+1++900000000:BP' IMD+F++:::PROFIL 40 X 1250 MM' QTY+21:12500:KGM' PRI+AAA:742.50:::1:TNE' UNS+S' UNT+11+1' UNZ+1+4711'
Vier Werte sind hervorgehoben. Jeder muss aus Ihrem System kommen, und keiner steht dort so, wie die Guideline ihn erwartet. Beispielhafte Nachricht, alle Werte synthetisch.
QTY+21:12500:KGM'
Auf Deutsch: Bestellmenge 12 500 Kilogramm. Das + trennt die Felder, das ' beendet die Zeile. Nüchtern betrachtet ist es ein Formular mit nummerierten Feldern, nur ohne Kästchen.
LINWelches Ihrer Artikelfelder trägt seine Materialnummer?IMDWoher kommt die Länge in Millimetern?PRIUnd Ihre Zuschläge — wohin damit?QTYWas, wenn Sie in zwei Teilmengen liefern?Ein Teil der Felder lässt sich direkt zuordnen: Artikelnummer gegen Materialnummer, Menge gegen Menge. Einmal einstellen, fertig.
Der andere Teil braucht eine Regel dazwischen. Die Länge steckt als Freitext in einem Artikelfeld und muss herausgelöst werden. Der Preis liegt bei Ihnen pro hundert Kilogramm vor, die Guideline will ihn pro Tonne. Und Zuschlagsartikel, die Sie intern als eigene Position führen, dürfen in der Nachricht gar nicht auftauchen.
Genau das liefert kein Formatwandler mit, und genau das ist bei jedem Abnehmer anders. Deshalb ist die Frage nicht, ob eine Software EDIFACT kann, sondern wer die dreissig bis fünfzig Zuordnungen für Ihren Betrieb entscheidet.
D07A nennt die Ausgabe des Wörterbuchs, vergleichbar mit einer Duden-Auflage.ORDERS Bestellung · ORDRSP Auftragsbestätigung · INVOIC Rechnung · DESADV Lieferavis.Anonymisiert: Namen von Kunden und Abnehmern nennen wir nicht. Der Stand ist je Fall angegeben, damit klar ist, was läuft und was im Aufbau ist.

openTRANS 2.1 aus dem ERP, übersetzt nach EDIFACT INVOIC, an zwei Grossabnehmer mit je eigenen Zentralkonditionen.
Die eigentliche Arbeit: die Konditionen so abbilden, dass die Rechnung ohne Rückfrage durchläuft. Dazu ein Werkzeug, mit dem der Anwender abgelehnte Rechnungen selbst neu erzeugt.
EDIFACT D07A in beide Richtungen: ORDERS herein, ORDRSP zurück, direkt aus dem Vorgang.
Die eigentliche Arbeit: Längen in Millimetern aus einem Artikelfeld, Zuschlagsartikel, die in der Nachricht nicht auftauchen dürfen, und der laufende Abgleich der Materialnummern.
EDIFACT über SFTP, ORDERS und DESADV, parallel zum eigenen B2B-Shop.
Die eigentliche Arbeit: zwei Bestellwege — Shop und EDI — in einen Ablauf führen, damit im Lager nicht zwei Wahrheiten entstehen.
Dazu kommen weitere Strecken, die nicht in diese drei Fälle passen: ein Bestellexport an Grosshändler in empfängerspezifischem XML im technischen Handel, eine EDI-FTP-Struktur mit Versand-Maillauf in der IT-Distribution.
Umgesetzt: EDIFACT D07A mit ORDERS, ORDRSP, INVOIC und DESADV · openTRANS 2.1 als Quellformat, übersetzt nach EDIFACT INVOIC · empfängerspezifisches XML für Bestellungen an Vorlieferanten.
Übertragung: SFTP, FTP, Maillauf, oder über das Clearing Ihres Abnehmers. Zugang zum ERP: COM, SQL und GraphQL.
Nicht zu verwechseln: die E-Rechnung. XRechnung und ZUGFeRD sind keine EDI-Nachrichten. Sie erfüllen eine gesetzliche Pflicht gegenüber allen Geschäftskunden, während EDI die Vorgabe eines einzelnen Grossabnehmers ist. Deshalb steht das Thema nicht hier, sondern auf einer eigenen Seite: E-Rechnung, XRechnung und ZUGFeRD aus büro+ heraus — mit den Fristen, den Formaten und dem, was büro+ dabei schon kann.
Guideline lesen · Abgleich mit Ihren Daten · Testdateien aus echten Belegen · Abnahme mit dem Abnehmer · produktiv mit Fehlerbehandlung und Betriebsanleitung.

Nach dem zweiten Schritt haben Sie eine Liste: welche Felder Sie bereits haben, welche gepflegt werden müssen und wo es eine Entscheidung braucht. Bis dahin ist nichts bestellt.
Nein. Die Übersetzung läuft in Ihrer Warenwirtschaft. Verlangt Ihr Abnehmer ein Clearing-Center, bleibt dieses in der Kette. Ein eigenes EDI-System auf Ihrer Seite brauchen Sie nicht.
Die Umsetzung ist meist der kürzere Teil. Den Termin bestimmt die Abnahme mit dem Abnehmer, und die dauert typischerweise zwei bis drei Runden. Wer früh anfängt, hat es leichter.
Bei uns nicht. Sie zahlen die Umsetzung. Ob Ihr Abnehmer über ein Clearing abrechnet, entscheidet er.
Sie werden benachrichtigt, und die Datei bleibt nachvollziehbar. In einem Fall setzt der Anwender abgelehnte Rechnungen selbst zurück, und der nächste Lauf erzeugt sie neu, ohne dass wir eingreifen müssen.
Ja. Beide Wege münden in denselben Ablauf im ERP, damit im Lager keine zweite Wahrheit entsteht.
Nein. ZUGFeRD und XRechnung sind Formate für die elektronische Rechnung und erfüllen eine gesetzliche Pflicht gegenüber allen Geschäftskunden. EDI ist die Vorgabe eines einzelnen Abnehmers und umfasst auch Bestellungen, Auftragsbestätigungen und Lieferavis. Zum ersten Thema haben wir eine eigene Seite.
Die EDI-Guideline Ihres Abnehmers. Damit können wir beurteilen, was die Übersetzung in Ihrem System bedeutet.
Sie haben die EDI-Vorgabe Ihres Grosskunden auf dem Tisch und wissen nicht, was sie für Ihr System bedeutet. Beschreiben Sie kurz, worum es geht. Wir melden uns.
Sie erhalten von uns: welche Nachrichtenarten verlangt sind, welche Felder Sie bereits haben, welche gepflegt werden müssen und wo es eine Entscheidung braucht. Konkret, auf Ihre Guideline bezogen, ohne Verpflichtung.
Lieber direkt sprechen? verkauf@alphacom.ch · +41 81 630 30 15