Onboard a new bearing supplier catalog

A new supplier file is the point where most catalog inconsistency enters. The steps below turn a supplier export into reviewable records without destroying information you will need later. They work for a spreadsheet process and for an automated pipeline; the difference is only who performs each step.

Before you start

Agree three things with the team that will use the data:

• Target model. Which fields, units and families your catalog uses. If you do not have one, start from a small draft and grow it per family.
• Identity rule. Manufacturer plus full designation, with documented formatting normalization.
• Acceptance policy. What a reviewer must see before a value or a match is accepted.

Step 1: Preserve the original

Store the file exactly as received, with the date, sender and any accompanying notes. Assign each row a stable ID that does not depend on sort order, for example the file ID plus the original row number.

Everything that follows refers back to these IDs. If a value is ever questioned, you can show the cell it came from.

Step 2: Profile the headers and values

Before mapping, understand what the file contains.

• List every header with its fill rate, distinct-value count and a few sample values.
• Note headers that carry units in the label (for example “Bore (mm)”) and those that do not.
• Look for placeholder strings: ”-”, “n/a”, “TBD”, “see drawing”.
• Check encoding, delimiter and quoting. Garbled accented characters usually mean the file was read with the wrong encoding.
• Look for cells that begin with =, +, - or @; spreadsheet tools may interpret them as formulas.

Illustrative, synthetic profile:

Step 3: Map headers to target fields

Write a mapping per source, not per header string. Each rule names the source, the family it applies to, the raw header and the target field. Leave a header unmapped rather than guessing; unmapped headers go to review.

Do not map dimensional columns until the family is known for each row. The width normalization guide shows why a column like “B” can carry different dimensions in different families.

Step 4: Run deterministic checks

Deterministic checks are rules with a fixed, explainable outcome. Run them before any enrichment or matching, because they are cheap and their results are unambiguous.

• Required fields present: manufacturer, designation, family.
• Numeric fields parse as numbers.
• Units present where the target field requires one.
• Values within plausible ranges for the family.
• No formula-like text in exported cells.
• Exact duplicate candidates: rows that share manufacturer and full designation after formatting normalization.

The local catalog checker performs the structural part of this step in your browser: you map your headers, and it reports missing required values, invalid numbers, missing units and duplicate candidate groups, then lets you download a flat report keyed by original row number.

Step 5: Review duplicate candidates

Rows grouped as duplicate candidates need a decision, not a merge. For each group decide:

• Same product, repeated row. Link both rows to one product identity; keep both source rows.
• Same designation, different pack or condition. Separate listings for one product.
• Truncated or ambiguous designation. Leave unresolved; request clarification or research.

Illustrative, synthetic output:

Step 6: Assign field status

For each target attribute on each row, record a status: populated, unknown, not_applicable, conflicting or not_researched. Applicability comes from the family rules, not from whether the cell happens to be filled. See missing versus not applicable.

Step 7: Enrich only what is applicable and unresolved

Enrichment should target applicable attributes with status not_researched or unknown. Every added value carries an assertion: source, location, raw label, raw value, method and review status. Where a new source disagrees with the supplier file, mark the attribute conflicting and keep both values.

Step 8: Review and accept

Reviewers see, for each proposed change:

• the original value and row ID,
• the proposed value and unit,
• the source and location,
• any conflicts and unresolved fields.

Accepted changes are recorded with who accepted them and when. Rejections are recorded too.

Step 9: Export

Produce a flat export in your catalog’s format, plus a sidecar or audit sheet that keeps:

• original row IDs,
• original values next to normalized values,
• field status per attribute,
• unresolved items and why.

Escape formula-like text in any CSV you produce so that opening it in a spreadsheet does not execute content from the supplier file.

Step 10: Make the next import cheaper

Turn decisions into rules. Every resolved mapping question and every accepted family rule for this supplier should be stored so the next file from the same source maps automatically and only new questions reach a reviewer.

Apply it

• Run steps 2 and 4 now with the local catalog checker; files stay in your browser.
• Compare your target model with the draft bearing record schema.
• Read about the full catalog management workflow, or discuss your catalog if you have a supplier file you want assessed.