How an Electronics Distributor Is Scoping a Pilot to End Manual ERP Product Lookups

Can software fill in the ERP product record that a quote is waiting for? Largely, yes: it can find the manufacturer's data, map it to the ERP's fields and flag what a person still has to check. That is the question a distributor of industrial electronics brought to us. Its sales team cannot quote an RFQ line until the product exists in the ERP, and for every new item someone opens the manufacturer's website and copies the data field by field. Automa.Net proposed to collect that data automatically, with the source of every value shown, map it to the distributor's own ERP fields and deliver it ready for import or through an API, starting with the fields that block a quote. The project is now at the stage of agreeing the scope of the pilot, so this article describes the problem and the plan, not results. It is the second case in our series on pilot projects, after automating quotes from raw stock lists: Automa.Net is not only off-the-shelf software, we also build around one customer's process, and we start with a pilot.

The case in brief:

• Problem: every RFQ item that is not yet in the ERP waits for a manual product lookup on the manufacturer's website.
• Cost: quotes blocked until a product record exists, effort that grows with every RFQ line, no record of where values came from, and code or brand errors found late.
• Proposed solution: automated product data enrichment from manufacturer sources first, mapped to the distributor's ERP fields, with a source and a review status for every value.
• First step: a pilot, now being scoped: fields, rules, manufacturers, sample RFQs and how success is measured.
• Current stage: no results yet, by design.

What Is Product Data Enrichment for an ERP?

Product data enrichment for an ERP means filling in a product record automatically from external sources instead of typing it by hand: descriptions, category, dimensions, weight, customs and export codes, EAN, country of origin and lifecycle data. For a distributor of industrial parts the main source is the manufacturer, because only the manufacturer's data is reliable enough for customs, shipping and customer questions. Good enrichment does three things beyond copying values: it converts them to the ERP's own units and field definitions, it records where each value came from, and it marks values that conflict or are missing so a person can decide.

The Problem: No Product Record, No Quote

The distributor holds a large stock of industrial electronics. Even so, many RFQs ask for parts it has not sold before. In its ERP a price can only be given once the product record exists. So every new RFQ line goes through the same manual chain:

1. The RFQ arrives with a list of part numbers.
2. The product is not in the ERP.
3. Someone searches the manufacturer's website for the exact part and variant.
4. The data is copied field by field into the ERP.
5. The product record is created, and only then can the line be quoted.

This is done by hand, one product at a time. Before a product can be created and quoted, a set of mandatory fields must be complete: identification and descriptions, category and manufacturer, the customs commodity code, dimensions, net weight and export control classification. Further fields, such as alternative codes, EAN, country of origin and lifecycle data, make the record complete and can follow later. A related guide on overcoming data silos in manufacturing supply chains explains why data copied by hand between systems tends to drift.

What the Problem Costs: Time and Errors

We have not measured the distributor's lookup time yet; agreeing how to measure it is part of the pilot scope. The cost is still easy to see in how the work is done:

• The quote is blocked. A customer waiting for a price waits for a product record first. The more new items in one RFQ, the longer the whole quote waits.
• Effort grows with every line. Each new item means another search, another variant to identify and another round of copying. A long RFQ multiplies it.
• No record of where a value came from. Once a weight or a country of origin is in the ERP, nobody can tell whether it came from the manufacturer, a reseller listing or a guess.
• Errors are found late. RFQ lines contain codes that match several products, typing or OCR errors in part numbers, and parts listed under the wrong brand. Found by hand, they surface after the product record already exists, or after the quote has gone out.
• Units do not match. Manufacturers often publish packaged weight and dimensions, while the distributor's rules require product-only values in its own units. Every lookup also means a conversion.

How We Plan to Solve It: Manufacturer Data, Mapped to the ERP

The proposal replaces one-by-one lookups with one batch per RFQ list: the whole list goes in, and each product comes back with its values mapped to the distributor's ERP fields.

Manufacturer data comes first. Values are taken from three kinds of sources, in a fixed order:

1. The manufacturer's website. Data extracted directly from the manufacturer and mapped to the distributor's fields. Extraction already runs for 21 manufacturers, including Siemens, Allen-Bradley, Schneider Electric, ABB, Omron, Lenze, Phoenix Contact and Pilz, and more can be added based on RFQ volume.
2. The Automa.Net database, with product data on parts from more than 9,000 manufacturers, used only for fields or products the manufacturer source does not cover.
3. Third-party sources, used only for the gaps that remain, and only those the distributor accepts, in the order it accepts them.

Every value shows its source and its status. For each field the result says where the value came from and whether it can be used: confirmed, needs review, conflict between sources, or missing. When sources disagree, the manufacturer's value wins and the conflict stays visible. Units follow the distributor's own rules, with a flag when the manufacturer publishes only packaged values.

Values are captured to the distributor's definitions, not the manufacturer's format. Alternative order codes are stored side by side, so either code finds the product, and lifecycle data comes with successor and predecessor linked where the manufacturer publishes them. Our guide on tracking obsolete industrial parts covers why those fields matter for a distributor.

Each product is sorted by what it still needs before quoting:

• Ready to quote: all product creation, quoting and shipping fields are complete from accepted sources.
• Needs review: an ambiguous match, a corrected code or conflicting values. A person confirms before the record is created.
• Missing data: mandatory fields not found in any agreed source. These go back to manual handling.

The output is prepared for import into the ERP or delivered through an API, depending on whether the team wants to look up single products or send whole RFQ lists. This is the same product data behind the Automa.Net product data enrichment service, here mapped to one company's field definitions.

The Pilot as the First Step

The rollout starts with the fields that block quoting:

• Phase 1, unblock quoting: the manufacturer's website as the only source, the product creation, quoting and shipping fields, and the mapping to the distributor's ERP fields and categories.
• Phase 2, complete the record: the Automa.Net database and agreed third-party sources, the remaining enrichment fields, and extra checks where manufacturer data runs out.

Before any of it is built, the pilot needs five decisions, and these are what we are agreeing with the distributor now:

1. The field mapping: product categories, units and lifecycle definitions.
2. Rules for incomplete manufacturer data, for example when only packaged weight or dimensions are published.
3. Manufacturers, sample RFQs and dates, with a deliberate mix of clean codes, alternative codes and problematic entries, so the pilot tests the hard cases and not only the easy ones.
4. Third-party sources for the remaining gaps: which ones the distributor accepts and in what order.
5. How the pilot is measured, for example lookup time saved per RFQ line.

The Current Stage

The project is at the scoping stage. We have shown the distributor how the data would be captured, sourced and sorted, and we are agreeing the field mapping, the rules and the pilot sample. We will not publish numbers until the pilot has run on the distributor's real RFQs and been measured the way both sides agreed. We will report on the results in a follow-up.

Talk to Us About a Pilot on Your Own Data

A pilot like this makes sense when product records are the bottleneck between an RFQ and a quote:

• New items arrive with every RFQ, and each one needs a product record before it can be priced.
• Your ERP has its own field definitions, units and categories that manufacturer data does not match one to one.
• You need to know where each value came from, for customs, export control or customer questions.
• Your RFQ process already has a fixed shape. Our guide on how to streamline the RFQ process for parts describes the steps where data usually gets stuck.

The first step is a conversation, not a contract. Send us a sample of real RFQ lines and your ERP field list, and we will show you which fields can be filled from manufacturer sources, which need review and which are missing, before anything is built. Contact the Automa.Net team to talk about a pilot.

Frequently Asked Questions

Can software automate product lookups for electronic RFQs?

Largely, yes. Software can match each RFQ line to the manufacturer's product, extract the data the ERP needs and map it to the right fields. Lines with ambiguous codes, typing errors or conflicting sources still need a person to confirm, so a good setup sorts products into ready to quote, needs review and missing data instead of guessing.

What product data does an ERP need before a quote?

Typically a code, descriptions, category, manufacturer and customs commodity code to create the item, plus dimensions, net weight and export control classification to quote and ship it. EAN, country of origin, lifecycle phase, successor and predecessor complete the record and can follow later.

Where does enriched product data come from?

From the manufacturer's website first. The Automa.Net database fills fields or products the manufacturer does not cover, and agreed third-party sources fill only what remains. Every value carries its source, and when sources disagree the manufacturer's value wins while the conflict stays visible.

What happens when the manufacturer publishes incomplete data?

The pilot agrees a rule for it in advance. A common case is a manufacturer that publishes only packaged weight and dimensions while the ERP needs product-only values: the value is flagged instead of entered as if it were correct. Mandatory fields that no agreed source has go back to manual handling.

Can enriched data go into the ERP without double data entry?

Yes. The data is mapped to the ERP's own fields and delivered as an import file or through an API, so nobody retypes it. Whether the team sends whole RFQ lists in one batch or looks up single products through the API is one of the decisions made during the pilot.

What are ECCN and the statistical number in a product record?

ECCN, the Export Control Classification Number, says whether a product falls under export controls and which ones; it is needed before some products can be shipped abroad. The statistical number is the customs commodity code, built on the international HS code and extended by the EU, the UK or the US into their own national codes. Both are fields a quote or a shipment can depend on, and manufacturers do not always publish them, which is why every value carries its source.

How do you measure a data enrichment pilot?

Both sides agree the measure before the pilot starts, for example lookup time saved per RFQ line, the share of products that come back ready to quote, and the share that need review. The sample should mix clean codes, alternative codes and problematic entries, so the result reflects real RFQs.