validation.gs1-check-digit

def gs1_check_digit(data: str) -> int

from fune.validation.gs1_check_digit import gs1_check_digit  # validation.gs1-check-digit@^1

def _ascii_digits(value: object) -> bool:
    # Compare against ASCII explicitly: str.isdigit() accepts Arabic-Indic and
    # superscript digits, which the other two languages would reject.
    return isinstance(value, str) and value != "" and all("0" <= ch <= "9" for ch in value)


def gs1_check_digit(data: str) -> int:
    """The GS1 mod-10 check digit for `data`, the digits of a GS1 key without
    its check digit.

    One rule serves every key length because the weights are counted from the
    right: 3, 1, 3, 1 ... starting with the digit that will sit next to the
    check digit. Counting from the left instead only works for EAN-13 and the
    other even-length data strings.
    """
    if not _ascii_digits(data):
        raise ValueError("GS1 data must be one or more ASCII digits, received %r" % (data,))
    total = 0
    weight = 3
    for ch in reversed(data):
        total = (total + (ord(ch) - 48) * weight) % 10
        weight = 1 if weight == 3 else 3
    return (10 - total) % 10

def is_gs1_check_digit_valid(key: str) -> bool

from fune.validation.gs1_check_digit import is_gs1_check_digit_valid  # validation.gs1-check-digit@^1

from .validation_gs1_check_digit_gs1_check_digit import gs1_check_digit  ← gs1CheckDigit, another function of this group · built into the same file, even by a slim install


def is_gs1_check_digit_valid(key: str) -> bool:
    """Whether the last digit of `key` is the GS1 check digit of the digits
    before it.

    Only the arithmetic: the length, the prefix and an all-zero key are the
    caller's to judge. Validators answer rather than raise, so anything that is
    not two or more ASCII digits is False.
    """
    if not isinstance(key, str) or len(key) < 2 or any(ch < "0" or ch > "9" for ch in key):
        return False
    return gs1_check_digit(key[:-1]) == ord(key[-1]) - 48

Install

fune build

With that line in your source, in a Python project (language python in fune.project), fune build resolves it and nothing else, pins them in fune.lock, downloads only the Python package of each, and builds the code above into your project’s .fune/build, one readable file per capability with a header linking back here. Or pin a range in fune.project and build in one step:

fune add validation.gs1-check-digit

That builds the whole group. To build only what you call, and whatever it uses inside the group:

fune add validation.gs1-check-digit --only gs1CheckDigit

The manifest, vectors and README with only the Python implementation. Install it without the registry with fune add ./validation.gs1-check-digit-1.0.0-python.fune, or fetch it from a terminal with fune pull validation.gs1-check-digit@1.0.0:python.

The whole function, every language, is one file too: validation.gs1-check-digit-1.0.0.fune, 15,242 bytes, sha256 f57294b4fe86f2e8ced3fffedc28f4fba3738cd0d9037d8ce207562cf69d30ca. It installs into a project of any language.

# fune: before validation.gs1-check-digit.gs1CheckDigit
# fune: before validation.gs1-check-digit.isGs1CheckDigitValid

# fune: after validation.gs1-check-digit.gs1CheckDigit
# fune: after validation.gs1-check-digit.isGs1CheckDigitValid

# fune: step validation.gs1-check-digit.<fn> after <n|label>

More from the author

## The rule

Weight the data digits 3, 1, 3, 1 ... starting from the rightmost and moving left, add them up, and the check digit is whatever brings the sum up to a multiple of ten: `(10 - sum mod 10) mod 10`. A sum that is already a multiple of ten gives 0, not 10.

Weighting from the right is what lets one rule serve every length, and it is the detail home-grown code gets wrong. An EAN-13's first digit is weighted 1, but a GTIN-8's, a UPC-A's and an SSCC's first digit is weighted 3, so code that always starts at the left with 1 is right only for keys with an even number of data digits.

GS1's worked example: the GTIN-13 data `629104150021` weighted from the right sums to 57, so the check digit is 3 and the GTIN is `6291041500213`. The SSCC data `37610425002123456` sums to 101, check digit 9. Both are vectors.

## Input

ASCII digits only, of any length (at least one data digit; at least two digits for a whole key). Spaces, hyphens and the `(00)`-style application identifiers printed on labels are not tidied away: strip them before calling, because what counts as a separator is the key's business, not the checksum's. Non-ASCII digits (Arabic-Indic, superscripts) are refused in every language.

- `gs1CheckDigit` throws on anything else, empty included, with `GS1 data must be one or more ASCII digits`: there is no digit to return. - `isGs1CheckDigitValid` answers `false` instead, as validators do.

## What it does not check

Only the arithmetic. It does not know which lengths a key may have, what a GS1 prefix means, or whether GS1 allocated the number. An all-zero key passes the arithmetic (its check digit is 0); `validation.gtin` refuses it as a GTIN, and any other key that should do the same says so itself. A passing key is well formed: every single mistyped digit and most adjacent transpositions (all except those of two digits differing by 5) change the check digit.

## Source

GS1 General Specifications, section 7.9 "Check digit calculation"; https://www.gs1.org/services/how-calculate-check-digit-manually

Files