Excel/CSV führende Nullen: Barcode eine Ziffer zu kurz — warum

Fragen Sie jeden, der Barcodes im Stapel erzeugt hat, und Sie hören dieselbe Geschichte: Die Datei sah gut aus, die Barcodes wurden gedruckt, aber jeder einzelne scannte zu einer Zahl mit einer Ziffer zu wenig — oder zu einer Zahl, die in wissenschaftliche Notation verwandelt worden war. Der Barcode-Generator war nicht das Problem. Die Tabelle hat die Daten gefressen, bevor der Generator sie je sah.

Das ist der mit Abstand häufigste Datenfehler bei der Barcode-Erzeugung, und er bleibt fast unsichtbar, bis Sie das Ergebnis scannen. Hier steht, warum er passiert, welche Symbologien gefährdet sind und wie Ihre Daten den Weg von der Tabelle zum Etikett überleben.

Warum Excel führende Nullen frisst

Das Standardverhalten von Excel ist, alles, was wie eine Zahl aussieht, als Zahl zu interpretieren — und Zahlen haben keine führenden Nullen. Tippen Sie 012345678905 in eine Zelle, speichert Excel den numerischen Wert 12345678905; die führende 0 ist in dem Moment weg, in dem Sie Enter drücken.

Für die meisten Tabellen ist das harmlos. Für Barcode-Daten ist es fatal, denn ein UPC-A hat exakt 12 Ziffern, ein EAN-13 exakt 13, ein GTIN-14 oder eine SSCC-18 hat 14 bzw. 18. Fällt eine führende Null weg, haben Sie eine andere, kürzere, ungültige Kennung codiert — eine, die entweder die Prüfziffer nicht besteht oder zum falschen Produkt scannt.

Dasselbe passiert, wenn Sie eine CSV-Datei per Doppelklick öffnen: Excel importiert jede Spalte mit seiner Standardlogik „Typ raten", und ein Feld voller Ziffern wird zur Zahl — die Nullen fallen weg.

Wissenschaftliche Notation: die 11-Ziffern-Klippe

Excel hat ein zweites, heimtückischeres Verhalten. Ein numerischer Wert mit mehr als etwa 11 Ziffern wird in wissenschaftlicher Notation angezeigt (und oft gespeichert) — aus 12345678901234 wird 1.23457E+13.

Für einen 12-stelligen UPC ist das grenzwertig; für ein 14-stelliges GTIN-14 oder eine 18-stellige SSCC ist es garantiert. In dem Moment, in dem der Wert in wissenschaftliche Notation umformatiert wird, werden die letzten Ziffern weggerundet und der Code ist unrettbar zerstört. Kein späteres Neuformatieren der Zelle holt die verlorenen Ziffern zurück, denn die Zahl selbst wurde bereits gerundet.

Die 15-Ziffern-Genauigkeitsgrenze

Selbst wenn Sie die wissenschaftliche Notation vermeiden, hat Excel eine harte Obergrenze: Es speichert Zahlen als IEEE-754-Doppelgenauigkeits-Floats, die nur bis etwa 15 signifikante Ziffern exakt sind.

Jede Kennung mit mehr als 15 Ziffern — und eine SSCC-18 hat 18 — wird in ihren letzten Ziffern stillschweigend gerundet. Sie können eine 18-stellige SSCC in Excel nicht als numerische Zelle speichern und unversehrt halten. Sie muss als Text gespeichert werden. Das ist keine Einstellung, die Sie ändern können; es ist eine Eigenschaft des Formats, dokumentiert in Microsofts eigenen Excel-Spezifikationen und Grenzwerten.

Welche Symbologien gefährdet sind

Jeder Code, der mit einer Null beginnt — bei EAN-13-Codes vieler Länder üblich — ist in dem Moment gefährdet, in dem er eine unformatierte Tabellenzelle berührt.

So behalten Sie die Nullen

Das Kernprinzip: Zwingen Sie die Spalte zu Text, bevor die Daten hineinkommen. Das sind die verlässlichen Methoden, in der Reihenfolge der Empfehlung.

Zwei Hinweise zu den gängigen Lösungen:

• Eine Zelle nachträglich als Text zu formatieren, bringt die verschwundenen Nullen nicht zurück. Die Daten wurden schon entfernt. Sie müssen neu importieren oder neu eingeben oder mit einer Formel fester Breite auffüllen.
• Der Apostroph-Trick funktioniert nur beim Eintippen. Wenn Sie eine ganze Spalte einfügen, formatieren Sie die Spalte vorher als Text.

Wenn Sie aus einer CSV erzeugen, öffnen Sie die CSV in einem einfachen Texteditor und bestätigen Sie, dass die Rohdatei die Nullen noch enthält. Wurde die CSV selbst von einem Programm geschrieben, das sie entfernt hat, hilft kein Tabellentrick — Sie müssen es an der Quelle beheben, die die Datei erzeugt hat.

Die GS1-Perspektive: das sind nicht bloß Zahlen

Die Kennungen, die von Tabellen verfälscht werden, sind nicht beliebig — es sind GS1-Identifikationsschlüssel mit definierter Struktur und berechneter Prüfziffer. Ein GTIN-14, eine SSCC-18 und ein GS1-128-Barcode tragen alle ein GS1 Company Prefix, gefolgt von einer Referenz und einer Prüfziffer.

Das ist aus zwei Gründen wichtig:

• Die Prüfziffer ist das Sicherheitsnetz. Wenn eine führende Null verloren geht, ergibt die kürzere Zahl sehr oft einen Prüfziffer-Fehler. Das ist die gute Nachricht: Der Fehler fällt beim Scannen auf, statt stillschweigend durchzulaufen. Die schlechte Nachricht: Viele Anwender merken nicht, dass die Prüfziffer falsch ist, und drucken immer wieder neu, statt die Daten zu korrigieren. Die Prüfziffer-Logik ist im Glossar-Eintrag zur Prüfziffer erklärt.
• Der Datenträger ist nicht optional. Ein GTIN-14 muss in einem ITF-14 oder GS1-128 mit dem korrekten Application Identifier (AI 01) codiert werden, eine SSCC-18 nutzt AI 00. Ist der Tabellenwert erst verfälscht, codiert der Barcode einen gültig aussehenden GS1-Schlüssel, der schlicht auf das Falsche zeigt — ein Fehler, der deutlich schwerer zu debuggen ist als ein Barcode, der gar nicht scannt.

GS1 veröffentlicht den vollständigen Satz an Standards für Datenträger und Kennungen, und die General Specifications regeln exakt, wie sie codiert werden. Saubere Quelldaten sind die Voraussetzung für alles davon.

Bereits verfälschte Daten reparieren

Wenn die Nullen schon weg sind: keine Panik — es gibt drei Stufen der Wiederherstellung, und nur eine davon ist garantiert.

• Stufe 1 — die Prüfziffer kann eine führende Null rekonstruieren. Bei einem UPC-A, einem EAN-13 oder einem GS1-128-Schlüssel wird die Prüfziffer aus den übrigen Ziffern berechnet. Wenn Ihre Spalte 12 Ziffern für einen Code zeigt, der 13 haben sollte, ist die fehlende Ziffer fast immer eine führende Null; meist können Sie die korrekte erste Ziffer bestätigen, indem Sie die Prüfziffer für jeden Kandidaten berechnen und sehen, welcher passt. Siehe die Prüfziffer-Formel.
• Stufe 2 — auf feste Breite auffüllen. Wenn Sie die Soll-Länge kennen, stellt eine Formel wie =TEXT(A1;"000000000000") (12 Nullen für UPC-A, 13 für EAN-13, 18 für eine SSCC) die Nullen wieder voran. Das funktioniert nur, wenn Sie die Breite kennen und der Wert ansonsten intakt ist; eine SSCC, deren letzte Ziffern durch die 15-Ziffern-Grenze bereits gerundet wurden, lässt sich damit nicht retten.
• Stufe 3 — zurück zur Quelle. Das ist die einzige garantierte Lösung. Exportieren Sie die Daten aus dem ERP, dem Produktstamm oder der ursprünglichen CSV neu, und erzwingen Sie diesmal beim Import die Spalte als Text. Versuchen Sie nicht, eine verfälschte Datei in Korrektheit zu reparieren — die verlorenen Ziffern sind wirklich weg, und sie zu raten ist der Weg zu einem Barcode, der auf das falsche Produkt zeigt.

Der Unterschied zwischen „scannt, aber falsch" und „scannt nicht" ist Thema von scannt, aber abgelehnt: codierter Wert vs. Datenbank — lohnenswert, wenn Ihre Barcodes einwandfrei lesen, das System sie aber immer wieder ablehnt.

So prüfen Sie Ihre Daten vor der Erzeugung

Bevor Sie einen Stapel in einen Generator geben, machen Sie diese Zwei-Sekunden-Prüfung:

1. Zählen Sie die Ziffern. Eine UPC-A-Spalte sollte durchweg 12 Ziffern haben; EAN-13 durchweg 13; SSCC durchweg 18. Fehlt bei jedem Wert eine, wurde eine führende Null gefressen.
2. Suchen Sie nach E+ oder E-. Jede Zelle in wissenschaftlicher Notation ist bereits verfälscht — die letzten Ziffern sind weg.
3. Sortieren Sie und schauen Sie auf die Extreme. Die größten Werte zeigen die 15-Ziffern-Rundung zuerst; eine SSCC, die auf ...0000 endet, wo sie auf ...1234 enden sollte, wurde gerundet.

Die Korrektur einer verlorenen führenden Null geht schnell; die Korrektur einer gerundeten 18-stelligen SSCC nicht, weil die verlorenen Ziffern aus der Tabelle nicht rekonstruierbar sind. In dem Moment, in dem Sie eine lange Kennung als Text speichern, müssen Sie diese Reparatur nie vornehmen.

Das ist die erste Ebene in der 12-Ursachen-Diagnose „scannt nicht" — und diejenige, die die meisten überrascht, weil der Barcode druckt und scannt, nur eben zum falschen Wert. Für den eng verwandten Fall, dass das Symbol korrekt scannt, das System es aber ablehnt, siehe scannt, aber abgelehnt: codierter Wert vs. Datenbank.

Weiterlesen

• Barcode druckt, scannt aber nicht: die 12 Ursachen in Prüfreihenfolge
• SSCC-18: die 18 Ziffern, die Prüfziffer und warum Sie keine wiederverwenden dürfen
• Prüfziffer, erklärt