ERP-Systeme wissen gut, was auf einem Etikett stehen soll,
und schlecht, ob das Etikett physisch druckbar ist. Die Lücke zeigt sich
immer an derselben Stelle: eine am Dienstag geänderte Vorlage, eine
Schicht, die am Mittwoch beginnt, und eine Palette falsch gedruckter
Etiketten, weil zwischen ERP und Drucker nie jemand auf die Ausgabe
gesehen hat.
Die Kette und wo sie wirklich bricht
Egal welches System — Odoo, NetSuite, ein eigenes WMS — die Form ist
gleich: Geschäftsdaten werden in eine Etikettenvorlage gemischt, das
Ergebnis wird als ZPL ausgegeben und roh an TCP-Port 9100 geliefert. Drei
Bruchstellen liegen in dieser Kette, und keine davon ist die Schuld des
Druckers:
Der Merge erzeugt Inhalt, den das Layout nicht fasst.
Ein Produktname doppelt so lang wie im Testdatensatz, eine Adresse mit
vierter Zeile, ein Chargencode mit mehr Stellen als erwartet. Für die
Daten, gegen die sie entworfen wurde, war die Vorlage nie falsch.
Die Vorlage wurde für einen anderen Drucker gezeichnet.
Koordinaten in ZPL sind Punkte; ein für 203 dpi gebautes Layout druckt auf
300 dpi bei etwa zwei Dritteln. Lager kaufen Drucker über Jahre, selten
alle auf einmal.
Vor dem Senden prüft nichts. Port 9100 kennt kein
Rückgängig: Sobald Bytes ankommen, bewegt der Drucker Material — der erste
Hinweis auf einen fehlerhaften Merge ist ein physischer Stapel falscher
Etiketten.
Das Prüftor
Die Lösung ist ein Schritt, kein Produkt: Zwischen "ERP hat ZPL erzeugt"
und "an den Drucker senden" eine Strukturprüfung setzen und alles
ablehnen, was durchfällt. Praktisch ist das ein HTTP-Aufruf in dem Dienst,
der ohnehin druckt.
curl -X POST "https://api.labelixa.com/v1/diagnostics?dpmm=8&w=4&h=6" --data-binary @merged-label.zpl
Die Antwort listet Befunde mit Schweregrad und Position.
error ist ein harter Stopp — das Etikett rendert nicht wie
beabsichtigt — und warning sollten Sie protokollieren, auch
wenn Sie weitermachen: Warnungen sind das, was später zu "warum scannten
die Etiketten letzten Monat schlechter" wird. Dasselbe Tor gibt es als
Kommandozeilenschritt für Cron oder CI (npx labelixa validate
merged-label.zpl endet bei Fehlern mit Exit-Code ungleich null) —
der einfachste Weg, eine Vorlage vor einem Release gegen echte Datensätze
zu prüfen.
Die zweite Hälfte ist das Rendern. Ein Tor fängt strukturelle Probleme
ab; ein Render zeigt dem Menschen, wie das Etikett aussehen wird — genau
das braucht man, wenn eine Vorlage sich ändert und jemand sie freigeben
muss.
Odoo
Die Etikettenausgabe in Odoo ist vorlagengesteuert und kann als ZPL an
einen Netzwerkdrucker gehen. Der praktische Rat ist versionsunabhängig:
Halten Sie die ZPL-Vorlage in der Versionsverwaltung statt nur in der
Datenbank, testen Sie gegen Ihre längsten echten Werte (nicht die
Demodaten) und setzen Sie das Prüftor in denselben Codepfad, der druckt.
Da sich Odoo-Installationen zwischen Versionen und Modulen stark
unterscheiden, prüfen Sie die konkreten Konfigurationsmasken in der
Dokumentation Ihrer eigenen Version, nicht in einem Screenshot aus einem
anderen Release.
NetSuite
NetSuite erzeugt Etikettenausgaben aus Saved Searches und Skripten; das
Etikett entsteht also dort, wo die Geschäftslogik lebt. Das macht es
leicht, einen Prüfschritt in dasselbe Skript zu legen, und macht den Test
mit dem "längsten echten Wert" besonders wichtig: Eine Saved Search, die
mit heutigen Daten funktioniert, kann beim ersten längeren Artikelnamen
ein überlaufendes Etikett erzeugen. Wie bei Odoo gilt: Record- und
Skript-Setup sind versionsspezifisch und gehören gegen die aktuelle
Dokumentation geprüft.
Was vor einem Release zu testen ist
Der längste echte Wert in jedem variablen Feld, nicht der
durchschnittliche.
Die Vorlage in der Dichte jedes Druckermodells im Bestand — der
Größen- und DPI-Analyzer nennt
die Annahme der Datei, der
DPI-Konverter rechnet
Koordinaten um, wenn der Bestand gemischt ist.
Ein Etikett je Vorlage durch
den Viewer, angesehen von der Person,
der der Prozess gehört — nicht nur von der Entwicklerin, die es geändert
hat.
Druckt ein Etikett danach immer noch falsch, grenzt die
Symptom-Triage die Ursache
ein, ohne Material für Vermutungen zu verbrennen.
Häufig gestellte Fragen
Wo gehört der ZPL-Prüfschritt in einer ERP-Integration hin?
Zwischen "ERP hat ZPL erzeugt" und "an den Drucker senden", im Dienst, der ohnehin druckt: ein Diagnoseaufruf, bei Befunden der Stufe error nicht in die Warteschlange, Warnungen protokollieren. Ein Schritt, kein Produkt.
Warum versagt eine im Test funktionierende Vorlage in der Produktion?
Weil die Zusammenführung Inhalte erzeugt, die das Layout nicht fasst: ein längerer Produktname, eine vierte Adresszeile, eine Chargennummer mit mehr Stellen. Testen Sie jedes variable Feld mit dem längsten echten Wert, nicht mit Demodaten.
Funktioniert dieselbe ZPL-Vorlage auf 203- und 300-dpi-Druckern?
Nein. ZPL-Koordinaten sind Punkte; ein für 203 dpi gezeichnetes Layout druckt auf einem 300-dpi-Kopf etwa in Zweidrittelgröße. Halten Sie je Dichte eine Vorlage oder konvertieren Sie sie, und prüfen Sie mit der tatsächlichen Dichte des Zieldruckers.
Brauche ich dafür eine bestimmte Odoo- oder NetSuite-Version?
Nein. Das Muster — Vorlage in der Versionskontrolle, Test mit dem längsten Wert, Prüfschritt im Druckpfad — ist versionsunabhängig. Die genauen Konfigurationsmasken prüfen Sie in der Dokumentation Ihrer eigenen Version.
