Clean Up Duplicate Part Numbers in a Spare-Parts Master

Two records can read almost the same and still represent different parts. A left-hand roller and a right-hand roller may share most of a description. One record may be priced by each while another represents a kit. Combining either pair because the words look alike would remove information the warehouse and buyer need.

Treat a similarity result as a request for review, not as permission to merge. First establish the original part identity. Then map every alias, variant, unit and open transaction that would be affected. The proposed source-to-target mapping should be approved before anyone changes a live spare-parts master.

Similar descriptions are only a starting point

Search rules and matching software are useful for finding records that deserve attention. They can standardize case, spacing and common abbreviations, then place likely matches in a candidate group. That reduces the list a reviewer must inspect. It does not establish that the records describe the same item.

A description can omit the field that makes a part distinct. Side, material, finish, assembly level, pack quantity or another variant may appear only in a suffix, drawing, supplier document or unit field. Records can also use different names for the same manufacturer, while identical-looking numbers can belong to different manufacturers. For these reasons, neither a high similarity score nor membership in the same product family proves equivalence or interchangeability.

Keep the original record IDs unchanged while candidates are being reviewed. For each candidate pair, retain the text that triggered the match, the matching method or rule, and the date of the candidate run. That makes it possible to reproduce why the pair was raised without allowing the search result to become an identity decision.

Establish the original part identity

Begin with the original manufacturer, rather than assuming the company named on a reseller label or equipment package made the component. Record the manufacturer name as supported by a parts list, drawing, data sheet, supplier confirmation or other controlled source. Keep known manufacturer-name aliases in a separate field so searches can find them without overwriting the supported identity.

Copy the complete manufacturer part number (MPN), including any meaningful prefix, suffix or revision marker. Do not silently remove characters until a manufacturer-specific rule or source shows that the normalized forms mean the same thing. Sharecat’s guidance on spares data and SPIR records identifies the original manufacturer name and part number as central validation fields. It also describes the risk of receiving a product-family number instead of the number for the supplied variant.

Read the MPN together with the variant. Depending on the record, a meaningful distinction could be left versus right, component versus assembly, a material or coating, a connector or mounting arrangement, or a package configuration. This review records those differences; it does not decide machine fit. If the evidence does not identify the variant, enter UNKNOWN and hold the candidate.

Check the unit of measure (UOM) as part of identity, not as a formatting cleanup. “1 EA,” “1 pair,” and “1 kit of 12” are different inventory statements. A documented conversion may support related records, but it does not justify combining balances as if their quantities had the same meaning. Sharecat’s description of its MRO data-cleansing scope lists duplicate identification alongside UOM, reference-link, manufacturer and part-number validation, and it says changes are logged. These are useful review dimensions; its service claims do not establish a KTSU process or the identity of any particular part.

Before recommending a mapping, the reviewer should be able to answer all of the following from cited evidence:

• Who is the original manufacturer, and which recorded names are aliases?
• What is the complete original MPN, and what source supports it?
• Which variant or package configuration does each record represent?
• What does one inventory unit mean in each record?
• Does the evidence show one identity, a documented relationship, or a conflict?

If the task instead is to interpret an unfamiliar OEM-style number or determine what it identifies, use the separate guide to track roller part-number formats. A duplicate-master review starts after the available identity evidence has been collected.

Check what a merge would change

A candidate can be an exact duplicate only if consolidating it would preserve the meaning of the stock and its connected records. Choose the proposed target deliberately: it should be the record that will remain findable, carry the supported identity fields and preserve the required history. Do not select it merely because it has the shorter code or newer creation date.

The matrix below is a copyable review record. Complete both record columns from evidence, name the source for each important value, and use UNKNOWN rather than a blank or assumption. The decision column is completed only after the transaction and trace-back checks that follow.

The status rule is intentionally strict. Any missing or unknown required field produces HOLD. An identity, variant, unit or transaction conflict produces REJECT CANDIDATE or KEEP RELATED RECORDS, depending on whether a useful relationship remains. Only complete, consistent evidence can produce READY FOR APPROVAL, and that status still does not change either record.

Consider three hypothetical walkthroughs. In the normal case, source record S-104 and target T-221 have the same verified original manufacturer and complete MPN, both mean one left-hand component per EA, all aliases are retained, open records have an approved handling plan, and the target and trace-back plan are identified. The output is ready for approval, not merged. If T-221 lacks a source for the original MPN, the output is HOLD. If one record is left-hand and the other right-hand, or one UOM is EA and the other is an undocumented kit, the output is a conflict; the records remain separate even if their descriptions are otherwise similar.

Open transactions

Inventory on hand is only one part of the impact. Search the system for every open or linked record that still uses the source ID. Depending on the platform and operating process, that may include purchase orders, sales orders, quotations, receipts, shipments, work or production orders, reservations, bills of material and vendor links. Record actual references and owners instead of entering “none” because a single screen appears empty.

StartProto’s current Merge Items documentation illustrates why this review matters in one specific system: its merge moves linked records to a target, consolidates inventory, permanently deletes the source, and carries history to the target. Its pre-merge check includes the affected records, inventory, target selection and matching UOM. Other systems can behave differently, so the system owner must confirm the actual migration and reversal behavior before execution.

For each open transaction, decide whether it should remain on the source until closure, be reissued, or transfer under an approved system procedure. Check quantities, UOM, prices, vendor references, reservations and status after the proposed treatment. If ownership, timing or treatment is unknown, keep the mapping on hold. A neat master record does not justify breaking an order already in motion.

Alias and supersession history

An alias is a searchable alternative identifier; it is not automatically another physical item. A supplier’s internal number can be retained as an alias to an original MPN when evidence supports that relationship. Preserve the alias, its issuer, the source that established the link and any validity conditions.

A supersession needs a different relationship. It may be directional, effective from a date, limited by configuration or subject to an engineering decision. Do not turn “new number replaces old number” into “both parts are interchangeable in every application.” Keep the old number, the successor, the supporting document, effective conditions and approval as history. If those conditions are unknown, maintain separate records or a pending relationship until the responsible reviewer resolves them.

The trace-back plan should let a later user recover the former record ID, its descriptions and aliases, the evidence used, its inventory balance, affected transactions, the chosen target, the approval and the date of any later change. Take the system export or controlled snapshot before execution, and specify the post-change checks. A log that says only “duplicate deleted” cannot reconstruct what was moved or why.

Approve the mapping before changing records

Separate the mapping decision from the software action. The reviewer prepares the evidence and recommends one of four dispositions: a candidate ready for merge approval, related records that should remain linked but distinct, a rejected candidate that should remain separate, or a hold for missing information. The designated data owner and the owners of affected transactions then approve, reject or condition that recommendation.

An approval record should name the source and target IDs, the evidence establishing identity, the treatment of aliases and supersessions, the UOM decision, the open-transaction plan, the trace-back and recovery plan, the approvers and the effective window. It should also define who will verify balances, links and search behavior after any authorized change. If the software action is irreversible, the retained export and recovery procedure need review before the change, not after a problem appears.

Do not pass an unknown field by choosing the most plausible value. Return it to the manufacturer, supplier, document owner, warehouse or transaction owner who can establish the fact. When all required fields are supported and consistent, hand the approved mapping to the responsible system administrator under the organization’s change controls. The review matrix authorizes a decision trail; it does not perform an ERP merge.