I’m using TCPDF to generate a page of retail store bin tags. These tags include a 1D UPC barcode. The system has worked for years, save for one problem: manufacturers and/or distributors occasionally send out a UPC with the wrong checksum.
By the time the data gets to me, it’s set in stone. My customer is a $1M/year retailer dealing with multiple $10B/year distributors. They’ll never be able to wag that dog and they’ve been politely told the problem won’t be fixed. Undoubtedly that number has become deeply embedded into who knows how many databases and reports.
And it causes TCPDF to error out when trying to generate a barcode. Yes, I can go find the correct checksum number, but that changes the 12-digit barcode, which is all that matters. I need to generate a scannable barcode regardless the final number.
- I am using type UPCA (UPC_A).
- The error I’m getting is
TCPDF ERROR: Error in 1D barcode string - My sample UPC is: 417489022098 (the check digit should be 4, but c’est la vie).
Is there a way to disable the checksum check in TCPDF?
If not, is there a barcode type that’s a UPC-style barcode that doesn’t use a checksum check? I’m unfamiliar with most of the barcode types supported by TCPDF and the documentation doesn’t even mention this check.
3
Irrespective of the motivation, a UPC symbol that is generated as a result of disabling the check digit is an invalid symbol that will not be successfully scanned by any ISO/IEC 15420 compliant barcode reader.
Knowingly providing an invalid symbol may in some cases result in repercussions for the supplier of the symbol, especially if it is subsequently used in open supply chains.
Common industry advice is that when confronted with an intractable request to generate an invalid symbol for an invalid number, to in fact generate a clearly fictitious symbol and point out this fact. Explain that it is just as valid as any other symbol that might be produced as a result of disabling the check digit, i.e. not at all valid!
| Clearly invalid symbol that will likely educate | Invalid symbol that will provide false assurance |
|---|---|
The customer is likely to object to the leftmost image, thereby providing a direct opportunity to explain that there is no such thing as a valid UPC-A image that represents their invalid number. If they have an ounce of self reflection then they should see the error of their ways.
Creating a derivative of a common library that will happily produce images akin to the rightmost symbol is harmful. It will ultimately result in the stealthy introduction of invalid symbols into supply chains since users will not have a clear indication that all is not well with their data.
1