On 23 February 2013 14:09, <kurt@roeckx.be> wrote:
> My problem now is that I it's always displayed with the dashes in between,
> even when I want to show the EAN13. As far as I know EANs are never shown
> with the dashes.
Right, they're not. But then, contrib/isn also sanitises both ISBN
ranges and EAN country codes using its own internal database, which
ought to be kept in lockstep with an external database whose
maintenance is highly decentralised - regional authorities make
certain decisions that can create a need to update the database. I'm
pretty sure that that database doesn't actually exist, at least all in
one place, in the case of ISBN. So contrib/isn is fundamentally
wrong-headed, and I would be quite happy to see its removal from
contrib.
In my experience of supply chain type applications, there is generally
a need to support fairly complex custom rules for sanitising EANs,
which generally makes a custom bigint domain a compelling choice. For
example, sometimes (typically in situations where products are sold by
weight), a price will be baked into the barcode that is affixed to the
product after it is weighed on a digital scales. The last 5 digits of
a barcode before the check digit is often a price (a number of cents,
usually) that a scales assigns based on a known price per kilogram,
plus the item's weight. This may present you with a need to store the
"normalised, base barcode" (basically, just the pseudo "custom"
country code and SKU) without any price, and without a check digit
(the check digit is of course a function of the dynamically assigned
price).
There are examples for Postgres on the internet that you can
generalise from for this sort of thing. These show how to enforce that
a check digit is correct using SQL, using this simple method:
https://en.wikipedia.org/wiki/EAN-13#Calculation_of_checksum_digit
We actually discussed changing the formatting of isn along the lines
you've discussed, and it was shot down. I'd just like to see it go.
--
Regards,
Peter Geoghegan
