Aus echten EDI-Anbindungen, nicht aus EDIFACT-Tutorials

Ihre EDI-Bestellungen sollen ankommen. Nicht überraschen

8 Punkte für stabile EDIFACT-ORDERS-Imports in Shopware. Mit den Encoding- und Dedup-Fallen aus echten Anbindungen.

Warum EDI-Imports in der Praxis kippen

  • Dieselbe Datei läuft zweimal durch

    Der Handelspartner sendet erneut. Der SFTP-Pickup ist nicht idempotent. Resultat sind doppelte Bestellungen, die später storniert werden müssen.

  • Encoding-Mismatch sprengt Umlaute

    UNOC oder UNOD im EDIFACT-Header steht eine andere Charset-Wahrheit als der eigentliche Datei-Inhalt. Sonderzeichen werden zu Frage-Boxen, Kundennamen verlieren die Bedeutung.

  • Open-Source-Parser ist seit Jahren ohne Maintenance

    Sie übernehmen eine Library, deren letzter Commit aus einer anderen Zeit kommt. Bugs gehen unbeantwortet, Sicherheits-Patches gibt es nicht.

  • Fehler im Log statt im Fach-UI

    Eine kaputte ORDERS-Datei wirft eine Exception. Die Operations-Person sieht nichts, der Handelspartner ruft am Nachmittag an und fragt, wo die Bestellung bleibt.

  • Der zweite Handelspartner kostet das halbe Projekt

    Was als Einmal-Skript für einen Großkunden gebaut wurde, lässt sich nicht für den nächsten Partner kopieren. Mandantenfähigkeit hatte beim ersten niemand auf dem Plan.

Was in der PDF steht

  • EDIFACT D96A, welche Felder wirklich kritisch sind

    Pflicht-Segmente, optionale Felder, die Sie brauchen, und Felder, die Sie ignorieren dürfen. Aus der Sicht eines Shopware-Imports.

  • Encoding sauber lesen

    UNOC, UNOD und die typischen Mismatches mit ISO-8859-1, ISO-8859-2 und UTF-8. Wie Sie Encoding zuverlässig erkennen, bevor Sie parsen.

  • SFTP-Pickup ohne Doppel-Verarbeitung

    File-State-Machine, atomare Moves, Quarantäne für kaputte Dateien. Damit der gleiche Inhalt nicht zweimal als Bestellung endet.

  • Multi-Tenant von Tag 1

    Wie Sie Mandantenfähigkeit in das erste Setup einbauen, ohne sie sofort nutzen zu müssen. Damit der zweite Partner kein Refactoring auslöst.

Auszug aus der Checkliste

Vier der 8 Punkte als Vorgeschmack. Die anderen vier inklusive Testfall-Matrix stehen in der PDF.

  1. 1

    Interchange-Referenz als Dedup-Schlüssel

    UNB-Header trägt Interchange-Referenz und Absender-Kennung, zusammen eindeutig. Plugin speichert beides und lehnt Wiederholungen ab. Dateiname allein reicht nicht.

  2. 2

    Encoding aus dem Header lesen, nicht raten

    UNB-Segment liefert den Charset-Code. UNOC ist ISO-8859-1, UNOD ist ISO-8859-2. Erst Header lesen, dann mit dem richtigen Charset parsen, nicht in UTF-8 raten.

  3. 3

    Eigener Parser oder gepflegte Library

    OSS-Parser für EDIFACT sind oft unmaintained. Ein eigener Parser für die paar Segmente, die Sie brauchen, sind 200 bis 400 Zeilen. Überschaubarer als drei tote Dependencies.

  4. 4

    Fehler fachlich, nicht technisch

    Mapping-Fehler landen im Admin-UI in lesbarer Sprache, nicht als Stack-Trace. Beispiel: Artikel X mit GTIN Y nicht im Katalog. Operations löst das ohne Entwickler.

Vorschau: EDI-Orders-Import in Shopware, 8 Punkte

Laden Sie die PDF kostenlos

Tragen Sie Ihre E-Mail ein, dann schicken wir Ihnen den Download-Link plus Passwort per Mail. Kein Newsletter, kein Verteiler.

  • 8 Punkte für stabile EDIFACT-ORDERS-Imports
  • Dedup über Interchange-Referenz statt Dateiname
  • Encoding-Erkennung über UNB-Header
  • Testfall-Matrix für Go-Live ohne böse Überraschungen

Häufige Fragen zum EDI-Import

  • Reicht ein Standard-EDI-Konnektor oder müssen wir custom bauen?

    Standard-Konnektoren decken die einfachen Fälle ab. Wenn Sie nur einen Handelspartner haben und sein EDIFACT-Format dem Standard entspricht, kann ein gekaufter Konnektor passen. Sobald Sie mehrere Partner mit unterschiedlichen Pflichtfeldern, mehrere Mandanten oder eigene Mapping-Tabellen brauchen, werden Sie den Konnektor erweitern oder ersetzen. Wir empfehlen Custom, wenn der Partner-Mix wächst.

  • Was ist mit anderen EDIFACT-Versionen, etwa D01B?

    Strukturell ähnlich, in Details anders. D96A ist bei kleinen und mittelständischen B2B-Unternehmen im DACH-Raum am häufigsten, manche Handelspartner bestehen aber auf D01B oder neuere Versionen. Wir bauen das Plugin so, dass Parser-Versionen pluggable sind. Dann kommt ein neuer Partner mit D01B ohne grosses Refactoring rein.

  • Wie testen wir EDI vor Go-Live realistisch?

    Mit echten Beispieldateien aus der Anbindung. Der Handelspartner schickt typischerweise zehn bis zwanzig Test-ORDERS, die Sie gegen Ihr Plugin laufen lassen. Plus selbst gebaute Fehler-Dateien, die absichtlich kaputt sind, damit Sie die Quarantäne testen. Die genauen Testfälle stehen in der PDF.

  • Brauchen wir wirklich Multi-Tenant, wenn nur ein Partner geplant ist?

    Die Architektur ja, die Konfiguration nein. Plugin-Code arbeitet immer mit einem Mandanten-Kontext, das aktive Setup hat aber nur einen Mandanten konfiguriert. Damit kostet Multi-Tenant in Phase 1 fast nichts und der zweite Partner ist später Konfiguration statt Refactoring.

  • Was kostet eine EDI-Anbindung typischerweise?

    Zwischen zwei und sechs Sprints, je nach Komplexität und Partner-Mix. Wir nennen eine konkrete Range nach 30 Minuten Erstgespräch, wenn wir wissen, welcher Partner mit welchem Format und welcher Frequenz dranhängt. Reine Inbound-Anbindungen sind günstiger als Inbound plus Outbound mit Auftragsbestätigungen.

Shopware-Partner für Ihren EDI-Import

Stackrail GmbH ist Shopware Partner mit Sitz in Singen am Hohentwiel. Wir bauen EDI-Anbindungen und ERP-Schnittstellen für kleine und mittelständische B2B-Unternehmen im DACH-Raum, haben und warten eigene Plugins im Shopware-Marktplatz und schreiben offen über das, was wir in echten Projekten gelernt haben. Auch über die Encoding-Sache.

EDI-Anbindung gerade akut?

30 Minuten Erstgespräch, kostenlos. Wir gehen einen konkreten Punkt Ihrer EDI-Anbindung durch und sagen konkret, was wir tun würden.

Raphael Schnick

Raphael Schnick

Geschäftsführer & Softwareentwickler

Erstgespräch buchen

Öffnet die Buchungsseite in einem neuen Tab.

Oder direkt per Mail anfragen