ean13badCheckDigit

[dimitrisal]

Hello I am trying to create a EAN13 barcode

I get the following error

Error: bwipp.ean13badCheckDigit: Incorrect EAN-13 check digit provided

My code is this

        bwipjs.toBuffer({
            bcid:        'ean13',       // Barcode type
            text:       '1234567891010',    // Text to encode
            scale:       3,               // 3x scaling factor
            height:      10,              // Bar height, in millimeters
            includetext: true,            // Show human-readable text
            textxalign:  'center',        // Always good to set this
        })

if I pass 12 digits it works.....

[joewestcott]

The checksum you provided (0) is incorrect. It should be 9 for '123456789101'.

https://www.gs1.org/services/check-digit-calculator

[dimitrisal]

That's true i found out that you check if the last digit is correct ,kinda cool.

I created it on my own now but is there anyway i could get it in the Promise before i create the image?

[metafloor]

Do you mean you just want the input validated? I have just released a minor patch (2.0.8) that fixes an issue with the dontdraw option where it would not work with composite symbols. You can now add dontdraw:true to your options and the rendering phase will be skipped. When you do this, the Promise will resolve with a null buffer. Likewise, if using a callback, it will be invoked with both the error and buffer params null.

[dimitrisal]

Thanks you!!

again great library ^_^

[TarikHuber]

Is it possible to disable the checksum check?

[metafloor]

The checksum is an integral part of the EAN symbology, so not sure why you would want to disable it. Essentially, you have two options:

1. Provide all 13 digits including the correct checksum.
2. Provide the first 12 digits and let BWIPP calculate/append it.

[TarikHuber]

In our warehouse management system that also generates barcodes we sometimes need to enter placeholder EAN-s untill we get the real ones. Sometimes the EAN-s are only B2B so we use internal non EAN conform numbers because the whole system identifies items over the EAN. I know what you think. I also don't like that. I just downgraded to a version that does not have that check.

[terryburton]

@TarikHuber For my personal edification, are you at any time reading the malformed images with a barcode scanner than does not detect the incorrect check digit? If so, whose equipment does that please?

[TarikHuber]

@terryburton Yes we read them with different hardware and software. All scanners have an Android App made by us. At first we used the camera then Grappa adapters for the Samsung S4. After that Unitech PA720. After that the Zebra MC330L. Every one of them had no problem with the incorect EAN. Some had a problem with a SSCC that had a wrong checksum so we made those always valid and generated by the system but we never noticed any isses with non valid EAN data.

[terryburton]

@TarikHuber Thanks! *Shudders...

[TarikHuber]

We are a logitstics company. We use it only for customers that don't even have any kind of barcodes but we want to have organized the stuff with them just to make it easier for us. Those customer have shorter item numbers from 4 to 7 digits (because they handle them manually). In Such cases we add zeroes in front of that item number so it stays the same for that company that get's the items back but has then 14 digits for the EAN. That way we have an EAN on the barcode with witch our scanners can work and those same "invalid" barcodes can be read and handled by those companies without valid EANs. This library and also the scanner did not complain about it before ;) There are so many companies that never heard of EAN, GS 1 or anything related to barcodes :( and yes we are located in germany -.-

[terryburton]

Thanks for the additional information.

You mention 14 digits for EAN. Are you talking about EAN-13 (13 digit data content), or EAN-14 or ITF-14 perhaps?

Scanners accepting EAN-14s with invalid check digits would be unsurprising since this is only a data verification digit, not a structural (symbology) verification digit.

In more detail...

In the EAN-13 barcode symbology the check digit is explicitly defined by the symbology specification as being an integral part of the barcode's structure, i.e. an EAN-13 image with an invalid check digit doesn't meet the definition of an EAN-13. A scanner that accepts EAN-13 barcodes with incorrect check digits is not standards compliant, except where it allows the user to explicitly opt in to scanning "something like an EAN-13 but without a check digit" (or weasel words to the same effect) to differentiate it from the official standard which has well-known data security properties. In fact, many scanners do not even transmit the check digit for an EAN-13 unless explicitly configured to do so, and such a scanner that also accepts symbols with a broken check digit would entirely defeat the intended purpose of the validation without even providing a means to shift the onus onto the user. They lower the data security of the symbology in a way that is completely silent if the check digit isn't validated or the validation erroneously disabled.

EAN-14 and ITF-14 are application specific variations of other fundamental symbologies: Code 128 and Interleaved 2 of 5, respectively.

The Code 128 symbology has an inherent, structural check digit but it is implicit and never transferred in the data or supplied by the user. A GTIN-14 number includes its own a data check digit, so when it is expressed as the application-specific EAN-14 variant it can be "doubly" verified: First the symbol check digit is verified; next the data check digit can be verified. Most scanners only verify the symbology check digit since they do not process the GS1 data content, which is subsequently validated by the receiving application.

Interleaved 2 of 5 has an explicit check digit which is defined as being optional. The GS1 application-specific variant ITF-14 mandates the use of this symbology check digit so that it can be verified by the scanners built in structural check. The algorithm for the data check digit of GTIN-14 was chosen to match the ITF scheme - so the GTIN-14 check digit is both a data check digit and a structural check digit when embodied in an ITF-14.

Fun, isn't it...

[TarikHuber]

Doesn't sound like fun 🤣

It is the EAN 14 in a Code 128 with multiple AI Data. I found it just strange that it worked for over 2 years and then a minor update changed that behaviour.

Anyway. Thank you very much for the detailefd explanatation. I appritiate it and I realy learnet something. I'm not a barcode specialist at all -.-

[terryburton]

The issue that you're seeing has nothing to do with the EAN-13 symbology check digits, but it's due to invalid GS1 data.

We recently introduced GS1 AI syntax linting: https://www.linkedin.com/pulse/gs1-application-identifier-syntax-dictionary-terry-burton/

If necessary for your internal applications you should use a recent version of the library together with the dontlint option to disable GS1 AI syntax valuation: https://github.com/bwipp/postscriptbarcode/wiki/GS1-Application-Identifier-Standard-Format#gs1-application-identifier-linting

However you should not do this within open applications since invalid data can result in chargebacks.

[TarikHuber]

Thank you @terryburton That is exactly what I was searching for :)