Product Codes - How to combine six selections into a product code/description

Johnrg

Registered User.
Local time
Today, 22:24
Joined
Sep 25, 2008
Messages
115
Hello all,

Our companies timber products are made up of five seperate componets.

These are:

Grade
Treatment
Dryness
Finish
NominalWidth
NominalThickness

In each category there are multiple options.

The combination of one selection from each category is the product code.

As you can imangine there are alot of possible product codes.

I think I want to set up the database so that a users selection in each category during either product data entry or order data entry will be stored as a product code in another table.

For example my product code for the following six selections would be stored in my product code table as M8LH31KDPG10050

Grade=M8
Treatment=LH31
Dryness=KD
Finish=PG
NominalWidth=100
NominalThickness=50

This would only happen once for each new combiantion of selections made.

Could anyone comment on this way of setting product codes up?

Can a combination of six selections be stored/populated into one table as a product code?

Any other advise would be appreciated.

Thanks

JohnG
 
Can it be done? Sure. Would I do it? Probably not. Is this:

M8LH31KDPG10550

A width/thickness of 10/550 or 105/50? Probably a bad example and it's obvious to you what it would have to be, but I would imagine there are possibilities among all the fields that would be hard to keep straight if it all gets jammed together. Only you know for sure. If each component is always a certain number of digits, then maybe, but then you still have to parse it all out later. If they're kept in different fields, you can link to lookup tables in queries to get the descriptions associated with the codes (which I assume there are).
 
Hi Paul,

Thanks for your reply.

The thing I am am struggling to get my head around is how to use product codes in this application when the combinations are so vast.

I personally think that we don't need a product code for each combination of selections but everyone one I have discussed this with including my programmer seems convinced that each product we sell needs its own "code".

The issue everyone seems to be that everyone I talk to about the design is thinking from a retail point of view rather than a manufacturing point of view.

Any input is appeciated.

Thanks

JohnG
 
You do need some product code but it deosn't need to be based on the product. Such numbering systems get unweildy and hard to read. As Paul describes they can be hard to make sense of without a delimiter and then they get longer and more cumbersome still. Then inevitably something comes along that won't fit the system and it all falls down.

Similar parts are just too similarly numbered and people miss the subtle difference in a long code. I heard once of an antenna input for a television where two near identical parts had one character different in the middle of a sixteen character code. This difference indicated whether the component included islolation capacitors.

Televisions often used to have a live chassis so the antenna socket needed to be isolated. In this situation a non-isloated part was fitted to a live chassis model making the antenna live to mains voltage.

Luckily nobody was killed that time but it does clearly demonstrate the potential problem with unwieldy part numbering systems based on product characteristics. I could see something happening with bolts just as easily.
 
Thanks for the reply,
So how would you guys approach this?
How do I make multiple components of a product that we manufacture togeather into a product code that means soemthing to a casual user?
Thanks
JohnG
 
John,

You definitely want to keep all of your separate fields:

Grade=M8
Treatment=LH31
Dryness=KD
Finish=PG
NominalWidth=100
NominalThickness=50

That way you can easily apply queries to your data without
ripping apart some string.

You should have an AutoNumber as the primary key for each
row of data. This is your "real" Product Number!

But if you want to give users something "meaningful" to
look at you can always construct it:

VisualProductNumber = Grade & "-" & Treatment & "-" & Dryness & "-" & Finish & "-" & NominalWidth & "-" & NominalThickness

You can make that the source for an unbound textbox, OR a NEW column in a query etc.

I add delimiters because as pointed out earlier, it reduces confusion.

hth,
Wayne
 
How do I make multiple components of a product that we manufacture togeather into a product code that means soemthing to a casual user?

The point that I was making earlier was that meaningful part numbers may not be the best solution because "a casual user" may interpret the part specification wrongly from a long string. Eventually something will come along that does not fit the scheme.

I prefer a system where the prefix composed of a few characters is meaningful followed by a meaningless sequence number. This way the user can enter the prefix and get a list from that group to pick from.
 
I agree - product attributes are product attributes, product codes do not need to contain all the attribute information.

They can either be meaningless autonumbers (if their purpose is to relate records together in your db.

Or they can be structured codes that are designed for humans to find easy to use (eg BA101, XY123, etc)

Divorcing the product code from the product attributes (especially the minor ones) is quite important, as the attributes might change subtly for a product line you want to consider the same as its historical antecedents - for example, treatment LH31 is phased out and replaced by PQ982 - but there is no sharp delineation between the two stocks from your supplier, and you want the new product to simply drop into the place of the old one with respect to stock control, order history, etc.
 

Users who are viewing this thread

Back
Top Bottom