Der Termin steht seit zwei Wochen im Kalender: Kickoff mit der EDI-Abteilung eines großen Handelspartners, dreißig Minuten, drei Leute auf der anderen Seite. Nach zehn Minuten ist die technische Anbindung geklärt — AS2, Zertifikate tauschen, Testfenster in drei Wochen. Danach kommt die Frage nach den GLN der Warenempfänger, und ab da wird das Gespräch einseitig.
Das ist der Normalfall. Die Übertragung selbst ist der einfachste Teil eines EDI-Projekts. Zertifikate, Verbindungstest, ein Testdokument hin und zurück — das ist an einem Arbeitstag erledigt und geht danach jahrelang störungsfrei. Woran erste Anschlüsse im Mittelstand tatsächlich hängen, sind Stammdaten, die vorher niemand pflegen musste, weil die Bestellungen bisher per Mail kamen und jemand sie von Hand ins ERP getippt hat. Beim manuellen Erfassen fällt es nicht auf, wenn die Kundenartikelnummer nirgends hinterlegt ist. Man erkennt den Artikel an der Bezeichnung. Eine Schnittstelle erkennt nichts.
GLN sind keine Kundennummern
Die erste Hürde ist fast immer die Adressstruktur. Ein EDI-Auftrag unterscheidet mindestens zwischen dem Käufer, dem Warenempfänger und dem Rechnungsempfänger — bei Handelsketten mit Zentralregulierung kommen Zentralregulierer und Lieferanschriften der Filialen dazu. Jede dieser Rollen kommt in der Bestellung nicht als Adresse, sondern als GLN. Dreizehn Ziffern, sonst nichts.
Viele ERP-Installationen kennen pro Kunde eine Lieferadresse und ein Feld für die Kundennummer beim Partner. Das reicht für Zentrallagerbelieferung mit zwei Rampen. Es reicht nicht, wenn derselbe Partner an achtzig Filialen liefern lässt und die Rechnungen zentral reguliert werden. Dann brauchst du achtzig Lieferadressen im ERP, jede mit ihrer eigenen GLN in einem Feld, das die Schnittstelle lesen kann — und nicht im Bemerkungsfeld.
Der Punkt, der in Projekten regelmäßig Zeit kostet: Die Zuordnung muss in beide Richtungen funktionieren. Eingehend musst du aus der GLN eine Adresse im ERP finden, sonst landet die Bestellung im Fehlerkorb. Ausgehend musst du auf Lieferschein und Rechnung dieselbe GLN wieder mitgeben, sonst kann der Partner die Belege nicht zuordnen. Kommt eine unbekannte GLN herein — neue Filiale, umgezogenes Lager —, muss klar sein, wer das mitbekommt und wer die Adresse anlegt. Sonst bleibt die Bestellung liegen, und der Erste, der es merkt, ist der Disponent beim Kunden.
Dazu gehört auch die eigene GLN. Wer keine hat, braucht eine GS1-Mitgliedschaft — und die braucht man ohnehin, spätestens für die Packstücknummern.
Die Artikelnummer des Partners ist die Wahrheit
In der Bestellung steht die Artikelnummer des Handelspartners, nicht deine SKU. Manchmal steht auch nur eine GTIN darin. Beides muss im ERP zu genau einem Artikel führen.
Die meisten Systeme können das. Shopware, JTL, PlentyONE haben Felder für Kundenartikelnummern oder herstellerfremde Nummern, und wo sie fehlen, baut man ein Attribut. Das Problem ist nicht die Struktur, sondern die Pflege: Die Nummern liegen in einer Excel-Datei beim Vertrieb, teils veraltet, teils mit führenden Nullen, die Excel längst entsorgt hat. Bevor du den ersten Testauftrag verarbeitest, brauchst du diese Zuordnung einmal vollständig und dann einen Prozess dafür, wie neue Listungen ins ERP kommen. Erfahrungsgemäß ist das die längste Vorarbeit im ganzen Projekt — und die einzige, die niemand delegieren kann, weil nur der Vertrieb weiß, welche Nummer zu welchem Artikel gehört.
Daneben die Mengeneinheiten. Handelspartner bestellen oft in Verkaufseinheiten oder Umkartons, das Lager arbeitet in Stück. Steht die Umrechnung nicht am Artikel, bestellt der Partner zwölf und bekommt zwölf Stück statt zwölf Kartons. Solche Fehler fallen erst in der Reklamation auf, weil die Übertragung technisch fehlerfrei war.
GTIN ist Pflicht, und zwar auf mehreren Ebenen
Ohne GTIN geht bei großen Handelspartnern nichts. Jede Variante braucht eine eigene, jede Farbe, jede Größe, jede Gebindegröße. Wo im Shop bisher ein Artikel mit drei Varianten ohne EAN lief, weil es niemanden gestört hat, muss vorher aufgeräumt werden.
Das gilt nicht nur für die Verbrauchereinheit. Für Umkartons erwarten viele Partner eine eigene Nummer auf Handelseinheitsebene — häufig als ITF-14 auf dem Karton. Und wenn der Partner seine Artikeldaten über einen Datenpool bezieht, ist die Stammdatenübermittlung ein eigenes Teilprojekt neben dem Nachrichtenaustausch: Maße, Gewichte, Nährwerte, Zolltarifnummern, je nach Branche eine lange Liste. Ein Anschluss, der die Bestellabwicklung technisch beherrscht, aber die Artikeldaten nicht liefert, wird trotzdem nicht freigegeben.
Das Lieferavis ist der eigentliche Umbau
Bestellungen einlesen ist überschaubar. Der Aufwand steckt im Lieferavis. Ein DESADV beschreibt nicht nur, was geliefert wird, sondern wie es gepackt ist: Palette mit Nummer, darauf Kartons mit Nummern, darin Artikel in Mengen. Der Wareneingang beim Partner scannt die Nummer auf dem Transportetikett und weiß aus dem Avis, was darunter liegt. Deshalb ist ein DESADV, dessen Packstruktur nicht der tatsächlichen Palette entspricht, schlimmer als keins.
Dafür brauchst du Nummern für Versandeinheiten — 18-stellig, gebildet aus deiner GS1-Basisnummer, einer fortlaufenden Nummer und einer Prüfziffer. Sie müssen eindeutig sein und dürfen sich über Jahre nicht wiederholen. Die Frage, wer sie erzeugt, entscheidet über den halben Projektaufwand: das ERP beim Erstellen des Lieferscheins, ein Lagerverwaltungssystem beim Packen oder der EDI-Dienstleister. Vergibt sie das ERP, muss das Lager die vorgegebene Packstruktur exakt einhalten. Vergibt sie das Lager, muss die Struktur zurück ins ERP, bevor das Avis rausgeht. Beides funktioniert. Was nicht funktioniert, ist die Kombination aus einem ERP, das eine Palette annimmt, und einem Kommissionierer, der auf drei packt.
Dazu gehört das Transportetikett. Es wird gescannt, also muss es lesbar sein, an der richtigen Stelle sitzen und die Nummer als Barcode tragen. Für den Etikettendruck plant man in Projekten regelmäßig zu wenig Zeit ein — er hängt an Druckern, Materialien und dem Layout des Partners.
Rechnungen: das ERP führt, der Dienstleister formatiert
Die letzte Frage kommt oft erst spät, gehört aber an den Anfang: Wer erzeugt die Rechnung. Manche Dienstleister bieten an, das Rechnungsdokument aus dem Lieferavis abzuleiten. Das klingt bequem und ist in fast allen Fällen die falsche Entscheidung. Die Rechnung ist ein Buchhaltungsbeleg. Nummernkreis, Steuersätze, Konditionen, Skonti, Gutschriften, Aufbewahrung — das gehört ins ERP, und die Buchhaltung muss jede ausgehende Rechnung dort wiederfinden. Entsteht sie beim Dienstleister, hast du zwei Wahrheiten und beim ersten Klärfall eine unangenehme Diskussion.
Sinnvoll ist die andere Aufteilung: Das ERP erzeugt die Rechnung als Beleg, der Dienstleister übersetzt sie ins Format des Partners und übernimmt die Übertragung. Was das ERP dafür können muss, ist überraschend banal — es muss alle Werte liefern, die der Partner erwartet. Bestellnummer und Bestelldatum, Lieferscheinbezug, GLN aller Beteiligten, GTIN je Position, Konditionen so aufgeschlüsselt, wie der Partner sie erwartet. Fehlt die Bestellnummer auf der Rechnung, wird sie abgelehnt. Das ist der häufigste Grund, warum das Rechnungsdokument als letztes freigegeben wird, obwohl es die einfachste Nachricht ist.
Was du vor der Terminzusage machen solltest
Bevor du dem Partner ein Testfenster bestätigst, nimm eine echte Bestellung aus den letzten Wochen und gehe sie im ERP durch. Findest du zu jeder Position die Partnerartikelnummer und eine GTIN. Steht die Liefer-GLN als Feld an einer Adresse. Kannst du zur Lieferung eine Packstruktur mit eindeutigen Nummern erzeugen und dazu ein Etikett drucken. Trägt die Rechnung die Bestellnummer.
Wo du an einer dieser Stellen hängst, hast du den Projektplan. Und du hast das Argument dafür, das Testfenster nicht auf drei Wochen zu legen, sondern auf den Zeitpunkt, an dem die Stammdaten stehen. Der Handelspartner hat damit erfahrungsgemäß kein Problem. Mit drei fehlgeschlagenen Testläufen schon.
KI-generierter Inhalt.