Slashdot Mirror

If you intend to sell your product at any store larger than the Joe's Corner Computer Mart, you'll have to get a barcode for it. This is not cheap (a few thousand dollars, as I recall). Further information is available here.

People really need to do research before going all half ass about this stuff. Did anyone actually read the specification [uc-council.org]. EAN-13 and UPC-A use the same barcode. To quote the page:

The symbol itself comprises only 12 digit characters. The 13th digit is not represented directly by a digit character, but is inferred in the use of the number sets A and B to encode the rest of the 6 digits in the left half of the code. The 13th digit, which is not directly represented, is always the digit in the leftmost position of the 13-digit number. The remaining 12 digits in the number are represented by the digit characters in the symbol, in the same sequence left to right

I'm just an informative AC...

I wrote some home-brew barcode software a while back and while implementing my barcode drawing routine I came across this page [uc-council.org]. It decribes the current 12 digit code (UPC-A) and also covers the 13 digit code (EAN-13). From what I remember, the first digit of the UPC-A was a descriptor of the type of item (food, clothing and such) and the last digit is a simple checksum. This leaves only 10 digits for use and if 5 are used for the manufacturer then that's only 99,999 seperate manufacturers and 99,999 seperate items. It's fairly easy to see why they want to switch everyone to the EAN-13 standard. It's not just tacking another number on as some seem to believe.

Not that simple. On the 12 digit barcode, as far as UPC's are concerned, you only have 10 usable digits, and even then, for reatil applications, there are strict allocation guidlines.

UCC Reference

Digit 1: Code, UCC Prefix.
Digits 2-6: Company Number
Digits 7-11: Item Reference
Digit 12: Check

Thus, you only have 10 useable digits for identifying products, and only 100,000 different companies to dole out 100,000 UPC's, (multiply by 3 because the first digit is 0, 6, or 7 for standard products.) That's 3.0 * 10^10 combinations. However, like IP addresses, these are handed out in inefficient methods, because they go in blocks of 100,000. Which means you need to pay somebody some money to get ahold of one.

This is a common problem for aspiring independent artists who want to get their music out. They get to make a choice... do I pay someone for a UPC, or do I go without? Stores generally won't accept a CD for sale w/o a UPC code on it. (Barring local merchants who may be willing to stock the item and either just put a price tag on it, or use one of their own UPC's. (UPC's beginning with 4 are reserved for such "internal applications". If your grocery store has a bulk foods department, and prints out UPC codes from a scale, the code will probably begin with 4.)

And the UCC is the body responsible for handing out the company codes.

Not that simple. On the 12 digit barcode, as far as UPC's are concerned, you only have 10 usable digits, and even then, for reatil applications, there are strict allocation guidlines.

UCC Reference

Digit 1: Code, UCC Prefix.
Digits 2-6: Company Number
Digits 7-11: Item Reference
Digit 12: Check

Thus, you only have 10 useable digits for identifying products, and only 100,000 different companies to dole out 100,000 UPC's, (multiply by 3 because the first digit is 0, 6, or 7 for standard products.) That's 3.0 * 10^10 combinations. However, like IP addresses, these are handed out in inefficient methods, because they go in blocks of 100,000. Which means you need to pay somebody some money to get ahold of one.

This is a common problem for aspiring independent artists who want to get their music out. They get to make a choice... do I pay someone for a UPC, or do I go without? Stores generally won't accept a CD for sale w/o a UPC code on it. (Barring local merchants who may be willing to stock the item and either just put a price tag on it, or use one of their own UPC's. (UPC's beginning with 4 are reserved for such "internal applications". If your grocery store has a bulk foods department, and prints out UPC codes from a scale, the code will probably begin with 4.)

And the UCC is the body responsible for handing out the company codes.

RTFA. The rest of the world is currently using 13-digit UPCs, and this change is more to satisfy manufacturer complaints than opening up more address space, IMO.

14-digit codes like the RSS code are currently being used on shipping crates and so forth, and the article says that some companies are actually going to use those 14-digit codes in order to consolidate their databases. A good idea.

The 'cheap' manufacturers probably haven't paid for a membership in the Uniform Code Council - the organization that assigns the manufacturers ID portion of the UPC barcode. They either made one up or tried to figure out who's they could use and not overlap too much.

Actually, the cost for bar codes isn't quite so horrific. You can get info on joining the coalition that distributes them here. It's $750 for sales up to $2million a year, which I assume a small label would fall under. Still very expensive, less than $1200.

The Uniform Code Council assigns the company codes on the UPC. The first part of the code is unique to the company manufacturing the product. The end of the code is determined by the company. Therefore, there shouldn't be any duplicate bar codes (unless the same company produced both or someone created unauthorized codes).

Want a UPC code of your own? Check out The Uniform Code Council's instructions.

Hah! This wouldn't be paying nearly enough respect to the people who spent YEARS developing the concept of bar codes! What you should really be doing is designing your own way to universally and effectively identify a product based on a small printed region!

Oh, and on that note, did you know that you have to pay licensing fees to Uniform Code Council for permission to make and sell products with UPC codes? I'm not sure how or if this applies to private, non-commericial use of the system, but it's something to think about nonetheless.

I've worked with a bit of EDI myself - mainly the products from St. Paul Software - I don't know if these were the guys you worked with (it doesn't sound like them) or not (it wasn't the Gentran software from Sterling Commerce, was it? I've never used their products, so I can't comment on them).

I've had good luck with SPS's solutions in regards to EDI (first with spEDI*tran on a sco box, then with Evision on NT) - they had excellent tech support, which is one thing that has stood out in my mind. However, their product isn't cheap.

To be honest, portions of the standards for EDI (which come from the UCC, a company we all love, right?) are convoluted, while most of the others are straight forward (most of the warehousing/inventory/order forms are easy - but the insurance related forms can give you nightmares).

Good luck in finding a free project, or starting your own - the "standards" tend to be the issue. It seems like every year they change significantly, to the point where it is hard to keep up with the standard. On top of that, the fees to buy a copy of the standards (in order to code a solution) can be pretty high. Plus, anybody working with the system would need a copy of those standards as well.

Most of the EDI solutions offered by companies (such as SPS's Evision product) are actually development environments, that allow you to create the templates to do the translation (basically, all EDI comes down to is data translation from one obscure format to another "standard" format to interchange data). The company may also offer services to create these templates as well, for a fee (many times it is cheaper to do this than doing the templates in house with the software).

I looked into the possibility of creating my own EDI software at one point - a template development/translation environment. I realized pretty soon that such a task would be near impossible by myself. I figured to even have a hope, I would have to have about 10 programmers working and designing for about a year before we would even get something (this was before I heard of free software, open source, and the GPL). Maybe today it would be possible to do what you want - but it would be akin to creating a programming language (in fact, SPS's software started exactly that way back in the early 80's - as a form of interpreted BASIC - you essentially wrote BASIC code to do the translation - the tools that came later GUI'ized the system, but still, under the hood of Evision, lies BASIC code and interpreter, chugging away). With the head start the other companies already have (10-20 years in some cases, like SPS), it might be possible, but it would be an uphill battle.

Still, if you have the need and development time, and you are well versed enough in EDI to consider it, I say go for it - create a simple system to handle creation of simple forms, or the portions of the forms thereof (so you can combine the pieces to form full forms), then go from there.

BTW - if you get something going, anounce it on /. - I would love to follow it's progress.