ERP parts data structuring for an electric vehicle manufacturer

A Dutch vehicle manufacturer had a problem that's common in small engineering teams: part numbers in the ERP didn't match what was on the technical drawings, supplier references were inconsistent, and nobody had a complete overview of what was actually in the system. Odoo was being updated, but the drawings and surrounding documents weren't, and over time, the two worlds had drifted apart.

I'd worked at this company for 4 years in previous roles, so I understood the operational context from the inside. When they reached out about a remote data project, I knew exactly what kind of mess I'd be walking into.

The core task: build a structured parts master covering 9 vehicle models, coupling OEM supplier part numbers to the company's internal numbering system, and make it ERP-ready in Odoo.

On the surface that sounds straightforward. In practice, the data came from multiple sources: technical drawings, supplier exports, legacy spreadsheets, and Odoo itself. None of them agreed with each other.

The first instinct was to match parts by name and description. I tested that approach and rejected it: too many unverifiable matches, too much ambiguity. A name-based matcher produces confident-looking output that's wrong in ways you only discover later.

Instead, I built a deterministic methodology: part number first, verified in both directions. Every coupling between a supplier number and an internal number had to be confirmed from the supplier side and from the internal side before it was accepted. Anything that couldn't be verified was flagged, not guessed.

A second discovery: Odoo contained far more internal part numbers than appeared on any drawing. Some were options sold separately that never made it into the base vehicle drawings. Others were legacy parts from earlier versions, still used occasionally by service and maintenance. Understanding that distinction, and labelling it, turned out to be as important as the coupling work itself.

OEM part number as the primary coupling key (8-digit format)

Two-directional coverage check: supplier → internal, and internal → supplier

Structured parts master per vehicle model, with consistent description formatting

Separate column for procurement variants where purchasing used different reference numbers

Anomalies flagged with context, not silently dropped

The pilot cluster (FM-240/Linhai/Volmer) is complete. The Regard series (FM-50/55/80/90/100) is active. Once all 9 models are covered, the completed parts master will serve as a baseline measurement, a starting point for tracking future drift between Odoo and the drawings over time.

The longer-term opportunity the client is exploring is using the structured data foundation to support AI-assisted catalogue management across the 3 domains the business operates in: base vehicle, options assembly, and service/maintenance.