HQ ERP codes and local 1C names: building a mapping table

A Korean company's Uzbek entity often lives in two worlds at once. Head office reports from its ERP, with long structured part numbers. The local team keeps goods in 1C or Excel, under names that a storekeeper recognises at a glance and that were typed by whoever received the shipment. A count can be flawless and still fail to reconcile, simply because the two sides do not call the same part by the same name. A mapping table fixes this before the first label is scanned.

Why the codes drift apart

The gap rarely comes from carelessness. It builds up for ordinary reasons:

• Head office uses a structured code, while the local records carry a supplier name, a short internal code or a description in Russian or Uzbek.
• One head-office code covers several local items, for example different colours or pack sizes. Or the opposite: one local item stands for a set that head office tracks as separate components.
• Spelling varies. Latin and Cyrillic letters that look identical, such as A and its Cyrillic twin, are different characters for a computer, and a stray space at the end of a code breaks an exact match.
• Design revisions change the number at head office, while the local record keeps the old one for years.

None of this is visible in daily work, because the storekeeper finds the item by its name. The problem appears when the figures are added up for head office: the same item appears on two lines, or two different items are merged into one.

Build the table in five steps

The table has one row per local item. Useful columns: head-office code and description, local code or name in 1C, the text actually printed on the label, unit at head office, unit locally, conversion factor, match status and the person who confirmed the match.

1. Export both lists, from the ERP and from 1C or Excel, with the same cut-off date.
2. Normalise the text: trim spaces, unify upper and lower case, replace look-alike letters, and keep every code as text so that leading zeros survive.
3. Match automatically wherever an exact code exists, including a supplier code stored in both systems.
4. Review the remaining lines on the floor, with a storekeeper standing at the shelf and the physical item or its label in hand.
5. Give every line a status: matched, matched with conversion, one-to-many, or no match.

For illustration, suppose the local list has 2,500 lines. Perhaps 1,900 match automatically, 400 more after a review on the floor, and 200 remain open. Those 200 are normal, and they are exactly what the table is for.

Handling the leftovers

Do not force a match to make the table look complete. A wrong link is worse than an honest gap, because it hides a real difference inside a pair that appears to balance.

• Items with no match go onto a separate "unmatched" sheet. They are still counted, described by what is physically on the label, and photographed if needed. What happens to them is agreed after the count.
• One-to-many links need a decision about the level of counting. Usually the lowest level is counted and converted upwards, for instance counting single pieces and converting them to boxes using the pack size.
• Sets and kits are counted either as assembled sets or as components, but never as both. Write the rule into the table.

Who confirms what

A mapping is only as good as the person who signs it. A storekeeper or warehouse supervisor confirms that the physical item matches the line. Someone from finance or the head-office reporting side confirms that the high-value lines are linked to the right ERP code. Date the table, give it a version number and freeze it before the count starts. If a link must change afterwards, record the change instead of quietly editing the file; otherwise nobody can later explain why the result differs from the first export.

Summary

A count that cannot be linked to the ERP is just a list. Agree the table, fix the units and keep the unmatched items visible, and the later comparison becomes a matter of reading differences instead of arguing about identity. Smart Inventory builds this correspondence table with your team before the count, shows head-office codes and local names side by side in the result file, and sets unmatched items aside so that their treatment can be agreed afterwards.