Stackrail

Aus echten EDI-Anbindungen, nicht aus EDIFACT-Tutorials

Deine 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.

PDF kostenlos laden

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

    Du übernimmst 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 du brauchst, und Felder, die du ignorieren darfst. 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 du Encoding zuverlässig erkennst, bevor du parst.

  • 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 du Mandantenfähigkeit in das erste Setup einbaust, 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. Punkt 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. Punkt 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. Punkt 3

    Eigener Parser oder gepflegte Library

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

  4. Punkt 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

Lade die PDF kostenlos

Trag deine E-Mail ein, dann schicken wir dir 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 du nur einen Handelspartner hast und sein EDIFACT-Format dem Standard entspricht, kann ein gekaufter Konnektor passen. Sobald du mehrere Partner mit unterschiedlichen Pflichtfeldern, mehrere Mandanten oder eigene Mapping-Tabellen brauchst, wirst du 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 im DACH-Mittelstand 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 du gegen dein Plugin laufen lässt. Plus selbst gebaute Fehler-Dateien, die absichtlich kaputt sind, damit du die Quarantäne testest. 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.

EDI-Anbindung gerade akut?

30 Minuten Erstgespräch, kostenlos. Wir gehen einen konkreten Punkt deiner 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

Wer steckt dahinter?

Stackrail GmbH ist Shopware Partner mit Sitz in Singen am Hohentwiel. Wir bauen EDI-Anbindungen und ERP-Schnittstellen für den B2B-Mittelstand in DACH, pflegen eigene Plugins im Shopware Store und schreiben offen über das, was wir in echten Projekten gelernt haben. Auch über die Encoding-Sache.

Wenn du tiefer einsteigen willst