Catalogue Product Codes and Store Option Identifiers: Keep Them in Separate Fields

A catalogue often carries two kinds of identifier that look similar and mean different things. One is a manufacturer-style product code: a reference that describes the item itself and could be quoted by anyone who deals with that item. The other is a store-specific option identifier: a label your shop assigns to one purchasable choice, such as a colour and size combination of that item. When these share a single field, searches return confusing matches, customers quote the wrong string, and staff cannot tell which one a message refers to. This article proposes a workflow for keeping them apart. It is an illustrative editorial example, using invented samples only.

The hypothetical sample

Imagine a made-up desk lamp. Its product code, as a manufacturer might print it, is LMP-4410. The shop sells it in two finishes and two cable lengths, and assigns option identifiers for each choice: SHOP-L1-BLK-1M, SHOP-L1-BLK-2M, SHOP-L1-WHT-1M, SHOP-L1-WHT-2M. These strings are invented for this exercise.

The product code answers: which item is this? The option identifier answers: which exact purchasable choice did the customer pick? One product code maps to many option identifiers. An option identifier maps back to exactly one product code.

Field design

Propose at least these separate fields on each catalogue record:

• Product code: the item reference, shown on the product page as a reference line.
• Option identifier: one per purchasable choice, shown in the cart, order summary and confirmation.
• Option description: the human words, such as Black, 2 m cable, always displayed beside the identifier.

Label each field distinctly on screen. A label like Item reference and another like Your selection code prevent the two from blending. Whether to show the option identifier to customers at all is an optional choice; some shops keep it internal. If shown, always pair it with the description.

Decision branches

When importing or editing a record, walk these questions:

• Does the value describe the item regardless of the shop? Put it in product code.
• Does the value exist only because of how this shop splits choices? Put it in option identifier.
• Is the value used by both, for example a shop that reuses the product code for single-option items? Record it in both fields explicitly instead of leaving one blank, and note that they currently coincide.
• Is the origin unclear? Hold the record out of publication until someone confirms it.

Search and customer messages

Decide what each search box accepts. A visitor typing LMP-4410 should reach the product page. A visitor typing an option identifier should reach the same page with that option preselected, if the identifier is valid. If a visitor types a code that matches neither, show a no-match message and suggest checking the reference printed on the item or in their order, rather than guessing a near match.

When staff reply to a message, they should quote the field name together with the value, for example Item reference LMP-4410, selection SHOP-L1-WHT-2M. This avoids a reply that treats one as the other.

Stop conditions

Stop publishing a record if the same option identifier appears under two product codes, if an option has no product code, or if two options share an identical description but different identifiers without any visible difference. These all signal that the mapping is ambiguous.

Worked example

A customer writes: I want LMP-4410 in white. Staff look up the product code, find two white options, and ask which cable length is wanted, quoting both descriptions. The customer answers 2 m, and the reply confirms SHOP-L1-WHT-2M with its description. At no point is the product code treated as a complete order reference, because it does not distinguish the options.

Small acceptance test

Use five invented records, including one with a deliberately duplicated option identifier and one with a missing product code.

1. Import all five. Pass if the two flawed records are held back with a visible reason and the other three publish.
2. Search by product code. Pass if the product page loads and lists every option.
3. Search by a valid option identifier. Pass if the same page loads with that option selected.
4. Search by an invented string. Pass if a no-match message appears and no product is suggested as if it matched.
5. Place a test order and check the confirmation. Pass if it shows both the option description and its identifier, labelled differently from the item reference.

Conclusion

Treat the product code as the identity of the item and the option identifier as the identity of one purchasable choice. Separate fields, separate labels, explicit branches for unclear values, and the five-record test keep catalogue data readable for customers and staff alike.

Sources