On this page
Quick Overview
Control customer item aliases, pack changes, effective dates, and open orders so a mapping update does not change what was ordered.
A customer's item code is meaningful inside that customer's purchasing process. It is not necessarily unique across accounts, packaging levels, or time. A distributor that treats the code as a permanent universal key can accept an order for the right-looking number and ship the wrong pack.
A controlled cross-reference connects the customer code to an internal item with enough context to make the mapping unambiguous. Effective dates and open-order rules matter as much as the code itself. The goal is to preserve what the customer ordered while making any proposed mapping change reviewable.
Define the mapping as a relationship
Use customer account, customer item code, internal SKU, ordering unit, pack quantity, and effective period as separate fields. Where the customer uses division or location-specific catalogs, include that scope. Keep the source document and approval reference with the mapping.
A product identifier can support the check: GS1's GTIN guidance (opens in a new tab) describes trade-item identification. A customer alias still needs its own account and packaging context. Do not replace a missing customer mapping with a product identifier simply because the description looks similar.
Write down the rule for blank or unknown codes. An intake exception is safer than a guessed match that becomes a warehouse instruction. Search results can help an administrator prepare alternatives, but an authorized item-data owner must approve the relationship.
Work through a pack-size change
Consider an illustrative customer code C17 that previously mapped to an internal six-unit case. The customer announces that new orders using C17 will refer to a twelve-unit case from an agreed date. An open order accepted earlier still calls for 20 six-unit cases.
Overwriting the mapping with the twelve-unit case could double the units on that open order if it is reprocessed. Keeping only the old mapping would make new orders wrong. The review therefore needs an effective-date rule and an explicit treatment for already accepted demand.
The owner might approve the new mapping for orders accepted after a defined cutoff while preserving the old relationship on existing order lines. That is an example, not a universal rule. The actual agreement may instead use requested delivery date, a release identifier, or a revised customer code. Capture the approved basis rather than assuming that today's date decides every case.
| Mapping field | What to record | Why it helps |
|---|---|---|
| Customer scope | Account and relevant division | Prevents cross-account reuse |
| Customer code | Original value | Preserves the buying reference |
| Internal item | SKU and product identifier | Identifies fulfillment stock |
| Unit and pack | Case, each, and contained quantity | Prevents quantity multiplication |
| Effective rule | Date basis and cutoff | Separates old and new demand |
| Approval and source | Named owner and document | Supports later investigation |
Review open work before activating the change
Locate open orders, quotations that may convert to orders, scheduled releases, returns, and customer-specific catalogs using the old mapping. List the records that require a decision. Do not assume the mapping update will automatically preserve historical meaning in every connected system.
For open orders, compare the accepted customer instruction with the proposed internal item. Ask the commercial owner whether customer confirmation is needed. For returns, keep the shipped item's identity available even after the new mapping becomes active. A return arriving under C17 may concern the old six-unit pack.
The new item master-data setup review covers related product-data checks. A customer cross-reference is a distinct relationship, so link it to the item master rather than copying product attributes into an uncontrolled second catalog.
Test the paths that consume the mapping
Use approved test records or a controlled review environment to examine manual entry, EDI import, portal orders, warehouse documents, and customer acknowledgments where those paths exist. The purpose is to confirm that each path interprets the mapping consistently. Do not claim that a successful manual order proves the interface uses the same rule.
Test an order before the cutoff, one after it, an old order reopened for review, and a return against an earlier shipment. Include an unknown code and a code used by another customer. Record expected and observed results, then route any disagreement to the system or data owner.
Check the quantities on customer-facing documents as well as internal screens. A correct internal unit count can still produce a confusing acknowledgment if the displayed customer quantity uses the wrong pack. Have the account owner confirm the language customers should see.
Make ambiguous matches visible
If two active mappings appear valid for the same scope and date, hold the affected intake step under the approved procedure. Present both candidates with their sources. An administrator should not select whichever SKU has stock available; availability does not establish product equivalence.
Similarly, do not resolve a description mismatch by editing the customer's text. Preserve it and explain the difference. The item-data owner may identify a harmless naming variation, an obsolete code, or a different product. Each result should leave a specific disposition rather than a generic “fixed” note.
Keep a reversible change record
Record the previous mapping, approved replacement, effective rule, impacted records, test evidence, and activation acknowledgment. Define who can restore the previous configuration if the change behaves unexpectedly. A rollback must also consider orders processed while the new mapping was active; reversing the master record alone may not correct those transactions.
After activation, review a small set of affected orders with the owner. Compare customer code, accepted unit, internal SKU, shipped quantity, and acknowledgment. Track exceptions by cause, such as missing customer notice or inconsistent interface behavior. Use those findings to refine the change process instead of blaming every mismatch on order entry.
Frequently asked questions
Can the same customer code map to more than one SKU?
It can only be usable if an approved rule resolves the context unambiguously. Account, pack, date, or release scope may distinguish relationships. If the ordering record lacks the field needed to choose, the case requires review.
Should old mappings be deleted?
Preserve enough history to interpret prior orders, shipments, and returns according to your record policy. An inactive mapping can remain searchable without being available for new order entry. The data owner should define the system treatment.
Order workflow support can maintain the change register and prepare affected-order comparisons. Request a consultation with one customer mapping change to define a practical review scope.