Registered: July 22, 2007 | Posts: 348 |
| Posted: | | | | Quoting Don'tPanic: Quote: So the answer is, it's already complete. The point isn't that maybe only 11 digits of the 12 are needed, the point is the database stores the complete UPC/EAN that is on the release. Therefore, if a UPC/EAN "graphic" is created for ultimate printing on a report, it needs to be equal to what is actually on the release. | | | Mr Video Productions If it isn't Unix, it isn't an OS :-) |
|
Registered: June 4, 2010 | Posts: 10 |
| Posted: | | | | Quoting MrVideo: Quote: Quoting Don'tPanic:
Quote: So the answer is, it's already complete.
The point isn't that maybe only 11 digits of the 12 are needed, the point is the database stores the complete UPC/EAN that is on the release. Therefore, if a UPC/EAN "graphic" is created for ultimate printing on a report, it needs to be equal to what is actually on the release. I didn't say anything about only 11 digits being needed. You need all 12 (or 13) digits. You posted that DVDP would have to embed some code because there is checksum info in the barcode. I then pointed out that the last digit (12th or 13th) is the check digit, so you don't have to worry about it, meaning that it is already calculated and part of the UPC code. I certainly didn't say, or imply, that you didn't need it. I was just trying to explain why DVDP does not need any embedded code to handle producing barcodes from the UPC/EAN number that it already has. The only thing DVDP would have to do is prepend and append asterisks to the 12-digit UPC number (or 13-digit EAN number). |
|
Registered: July 22, 2007 | Posts: 348 |
| Posted: | | | | Quoting Don'tPanic: Quote: I was just trying to explain why DVDP does not need any embedded code to handle producing barcodes from the UPC/EAN number that it already has.. Sorry about the misunderstanding. | | | Mr Video Productions If it isn't Unix, it isn't an OS :-) |
|