The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

item coding?

Hello,

I would like to solicit some info regarding item coding. Which is easy to adopt and implement?
I'm building a liquor POS system. Aside from barcoding I'm assigning them an easy to read item code.

Which is a better approach? My coding format is CLASS+SEQUENCE. 1.) To impose a fixed 3 char class, followed by a sequence. e.g. WNE-001 (wine), VOD-001 (vodka), Or 2.) or non-fixed class e.g. WINE-001, etc. VODKA-001 etc. or 3.) to be more item specific instead of class. e.g. FUN for Fundador, GIL for Gilbeys. Something like that. Which would you suggest?
Thanks.
j2e
Tuesday, March 27, 2007
 
 
And these codes would be useful for what to users (don't make it your primary key)?

1. I'd look at the existing distributors catalogs.  (You'll be re-ordering using their codes)

2. Size of bottle is going to be an important identifying factor for users, since the same brand will come in different size bottles.  (There will also be issues of the different units of measure - order and receive in cases, issues, sales, returns and spoils will be in eaches - some other industries like vending and supermarkets tend to have three units of measure)
Cade Roux Send private email
Tuesday, March 27, 2007
 
 
Everybody thinks they want human readable, highly abbreviated identifiers that contain basic information regarding brand, vendor, packaging, etc. In practice, 5-7 digit codes and full text descriptions are just as good. This is especially true for item searches. At any given time you have access to either a number or a description. Either you already know the answer to whatever question is being asked or you have to look it up in the database. Fancy codes simply don't help all that much. The new guy is always getting the abbreviations screwed up and the old guy works quicker with raw digits.

Go check out a real parts counter. You'll find that even the new guy is mapping numbers to items without the additional overhead of having to memorize a bunch of arcane abbreviations. And they will get arcane--everybody will clamour for so much information that you end up with things like VG7XG and VG5XV (Vodka, Gilbey's, 750 ml, Xmas special with glasses and ...500 ml Xmas special with a mini-bottle of vermouth). And then somebody will screw up one of the abbreviations and the whole system comes crashing down.

You have fields for information and you have fields for identifiers. Some may be both depending on your primary key philosophy. I've yet to see the benefit of duplicating information in another field. If it makes a difference, I crawled up from truck driver through various warehouse positions to inventory systems programmer.
Ron Porter Send private email
Wednesday, March 28, 2007
 
 
+1 Ron > In practice, 5-7 digit codes and full text descriptions are just as good.

I'm doing POS work for a large retailer. They've sold a lot of stuff for a long time with 6-digit product id's without any special coding.  One nice thing about them is that the 6-digit number works for selling what the customer would see as "the same thing" (say, a bottle of bourbon) even though receiving might see it as different UPC's from different manufacturers.  Every product will have a UPC... but no one says it has to have only one.
Pat Morrison Send private email
Wednesday, March 28, 2007
 
 
Thanks.

Ok. If I consider : 1 letter representing the class. e.g. W = wine, V = vodka. and the rest is digit.

The purpose of this is to determine an item code from the barcode. I'll be using one field for entering the barcode or the item code. If the code begins with a letter then, it is item code otherwise it is barcode.

Will this be a better approach?

Another? Is it ok to utilize the current barcode of the item? That is currently on the bottle.

Thanks.
j2e
Wednesday, March 28, 2007
 
 
"I'm building a liquor POS system. Aside from barcoding I'm assigning them an easy to read item code. "

What is the benefit of having 2 IDs for a single object?  Why does it need to be "easy to read"?  Ron Porter has it right, up above, I think.  What is the benefit of doing this? 


"I'll be using one field for entering the barcode or the item code."

I'm not a fan of overloading fields, although I've seen it done.  Could you not have two fields, with one greying out the other if a value is put into it?  This keeps the semantic meaning of the two IDs separate, and doesn't require merging validation code for each field, etc.
Dan Fleet Send private email
Wednesday, March 28, 2007
 
 
"The purpose of this is to determine an item code from the barcode. I'll be using one field for entering the barcode or the item code. If the code begins with a letter then, it is item code otherwise it is barcode."

I thought the barcode was simply an alternate representation of otherwise human-readable characters.  I realize I don't have a lot of experience with barcodes, but I've always thought of them as being just a fancy font with a prefix, suffix, and/or checksum bracketing the actual data.

I did a very small amount of work with some Zebra printers and quite a bit more with just a barcode font on regular label printers. I don't remember which codes we used on the Zebra, but we used Code39 for our regular label printers.

In both cases, we set things up so that the label printed both the code and text representations. The barcode reader (just a simple keyboard wedge) did all the decoding and dumped the exact text of the id into the ID field. If the reader failed in any way, simply typing the exact text of the id into that same field got you the same results. No special characters or identifiers, just a nice simple string of characters.

For what it's worth, one of the reasons to stick with pure digits is that anybody can come up to speed quickly on the numeric keypad, even if they've  never seen a keyboard before.
Ron Porter Send private email
Thursday, March 29, 2007
 
 
Keep in mind that you have to deal with the issue of character casing when assigning alphanumeric SKU's. It's not a big deal but it is something to consider.

In my current POS system I allow retailers to go alpha or completely numeric by setting a switch. But I have to say that the majority of retailers use a numeric SKU for various reasons. They are easier to encode in private barcodes and there is no ambiguity caused by case. They are also typically migrating from older legacy systems that constrained them to use numeric SKU's because they weren't based on modern relations databases.

You will also want to consider UPC cross reference support. This would be a separate table of UPC/SKU code pairs that would allow the cashier to scan the manufacturer's barcode instead of having to paste private barcodes all over the merchandise. Having more than one barcode on each product can be costly in terms of confusion at the POS as well as just having to afix private barcodes to all of the merchandise.

Finally, the other two things you should consider are department/class hierarchies and inventory requirements. Groups of SKU's will be classified by department. For example you could have a department for beer and a department for drink mixes. Department is also often called "Class" but the idea is the same. I've worked with a lot of retailers who assign SKU's using a numeric department number as the prefix. So for example all SKU's under the beer department (which is dept. 023) would be of the form 023#### for a seven digit SKU.

As for inventory, you will want to be able to track this at the SKU level. The reason I bring this up is that it is possible for a retailer to want to track multiple UPC codes as the same SKU. Manufacturers will often substitue new barcodes on merchandise that is pretty much the same or on merchandise that is intended to phase out old products. Going back to idea of having a UPC cross reference table, this would imply that more than one UPC could point to the same SKU.
dood mcdoogle
Thursday, March 29, 2007
 
 
I should also note that having a single input field where the user can enter either a UPC or a SKU is the best approach. When the user enters a value you go to the UPC cross reference table first. If there is no matching entry, try the input as a SKU. If there is still no matching entry, show an "Item Not On File" error message.

But regardless of which they enter, always track items by SKU. This is the value you will use for inventory management.
dood mcdoogle
Thursday, March 29, 2007
 
 
Thanks for your suggestions.
Ok. I'll stick with numbers. 3 digits class, 2 digits brand, 2 digits sequence. e.g.
 for wine (021), brandy (022) the next 2 digits is the brand. (01 = fundador, 02 = gilbeys etc. the rest will be the sequence.
e.g.
0220101 (brandy fundador 500ml)
0220102 (brandy fundador 700ml)
etc.

I'll be supporting searching by description. but will be using short description for printing.

I agree that most users are better with numeric keypad.

And, the classification will aid the users in narrowing the search. e.g. when the user enters 022 all the items that start with 022 are displayed for selection.

Is my coding better now?
j2e
Friday, March 30, 2007
 
 
That sounds just fine.
dood mcdoogle
Friday, March 30, 2007
 
 
thanks dood. thank you guys.
j2e
Sunday, April 01, 2007
 
 
I disagree that this sounds fine.

I've worked, in the past 27 years, with quite a number of systems where a single field (usually but not always an account number) consisted of several distinct parts strung together. This has WITHOUT EXCEPTION caused problems.

Go with just a pure ID code. No portion of the code, smaller than the whole thing, should have any meaning whatsoever.

Do yourself another problem-avoidance favor too. I see no reason why you would ever be treating this code as a number - that is, you'll never do any math with it, and the only comparison you'll ever do is equality which works just fine and unambiguously with strings. Don't think of it as a number. Don't call it a number. Preferably, don't store it as a number. (And if it happens to be a string of digits, make sure the leftmost digit is not a "0".)
Don Edwards Send private email
Tuesday, April 03, 2007
 
 
keep the item code as running numbers without any intellegence. Have additional fields to group the item into . like , type, brand , size etc.

Kabeer
kabeer Send private email
Thursday, April 19, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz