Hi
I've been playing around with the barcodes widget and I've noticed some confusing behaviour on the examples available.
I initially used the cheese example with some valid barcodes and noticed that entering an EAN13 in its full 13 digits causes an error and fails to show any barcodes. Using https://demos.telerik.com/kendo-ui/barcode/index if you change the code for the first item (Manchego) and change it to EAN13 and then enter a valid EAN13 (eg 9300657234720) it not only shows no barcode but also obliterates all of the following barcodes. If you remove the check digit (the last digit) then everything works.
I then found the API example https://demos.telerik.com/kendo-ui/barcode/api where I worked out what is happening. The Kendo widget is accepting ONLY the first 12 digits and then calculating the check digit for itself. So entering
930065723472
will generate a valid barcode and will correctly calculate the check sum as 0.
However this means that the security of the checksum is stripped out meaning that if an end user manually types the example
9300657234720
without the checksum so
930065723472
but makes a transposition error with the last 7 with the last 4 to
930065723742
then it will still generate a valid barcode
930065723742 4
However the original barcode is for baked beans and the erroneously created barcode does not exist as a product.
Further if the original barcode is checked in its entirety but has the transposition error with the 4 and the 7 with the checksum 0 then this error would be caught https://barcode.tec-it.com/en/EAN13?data=9300657237420
So, my question is how do I use the Barcode widget and a full EAN13 with check digit to ensure that data entered is correct and that the barcode being generated is for baked beans not non existent products?
Hi, Sean,
Thank you for the provided details.
I am a bit confused about the problem at hand.
You are absolutely correct that the component will automatically calculate the checksum. This is by design and it is working as intended. Which is also why you can only enter 12 digits and you can optionally display the checksum.
The barcode's purpose is to verify that the entered format is correct and to generate the checksum.
Best Regards,
Georgi
The problem is that an EAN13 barcode requires the entry of all 13 digits otherwise you are unable to confirm that there has been no transposition errors in the initial 12 digits.
If you are creating NEW barcodes then you only need to enter the first 12 digits and can allow Kendo to calculate the checksum.
If you are entering EXISTING barcodes (i.e. a barcode that another supplier has provided you with) then you must enter the FULL 13 digits including the checksum, otherwise you cannot be certain that the barcode has been entered correctly without visually checking that the check digits are the same. The checksum acts as a verification that the barcode that you've typed in is correct. Again unless you are generating brand new barcodes then the checksum is part of the barcode and cannot be safely omitted. The example above shows what happens when you switch two digits and don't have the checksum in place, a 12 pack of baked beans becomes a null product. In some instances it may generate an entirely erroneous product.
I have focussed on the EAN13, but this issue applies to all barcodes with checksums.
Hi, Sean,
Thank you for the clarification.
The Kendo UI Barcode is designed to generate new barcodes and not to check existing ones. The latter would require a component like "Barcode Reader" or something similar.
Presently, we don't have a component of that sort, so you'll have to write a custom validation logic.
Here's an example with EAN-13:
https://dojo.telerik.com/@gdenchev/iqEsAzIX
Best Regards,
Georgi