Auto parts selection in an online store: checking fitment, VINs and part numbers

A customer finds a part that looks right, sees an affordable price and places an order. Only during installation does it become clear that their vehicle variant needs a different version. The store receives a return, and the sales representative selects a replacement manually once again. Auto parts selection in an online store should address precisely this problem: not simply finding similar items, but showing the basis on which a part fits a particular vehicle.

The starting point should not be a ‘Search by VIN’ button, but rules for matching data. Vehicle identification, part fitment, the supplier’s commercial offer and stock availability need to be kept separate. That makes it clear what the website can confirm automatically, when it should ask a clarifying question and when it should refer the request to a specialist.

The part, the vehicle and the offer are separate entities

In a business management system, a product often appears as a row with a name, part number, price and quantity. That is not enough for selling auto parts. A single product may have several searchable numbers, fit different vehicle variants and come from several suppliers. Similar names, meanwhile, do not imply identical designs or interchangeability.

The catalogue model should describe the product separately: its manufacturer, manufacturer’s part number, specifications, package contents and its own stable identifier. The vehicle or vehicle variant should be a separate entity. The relationship between them holds the conditions of fitment, such as engine type, production range or equipment restrictions, where the source provides them. The offer is separate again: supplier, warehouse, price, unit of sale and expected dispatch time.

Fitment is not the same as availability. A part being out of stock does not invalidate its fitment, and a positive stock balance does not prove that it will fit. If these attributes are mixed together, after the next import the store may confidently tell a customer ‘fits’ simply because a supplier sent a similar name.

This is a specific industry challenge within the broader task of designing a product catalogue structure. For auto parts, a complete description also needs a relationship to the vehicle. That relationship should be checked as a separate dataset, rather than buried in free-form text on the product page.

What VIN and part-number searches actually confirm

A VIN is a vehicle identification number. Entering it may help identify a vehicle in a connected service, but the input field itself says nothing about how complete the returned data is. Before designing the interface, check which makes, markets and vehicle types the chosen product covers, what its response contains and which attributes are missing for your range.

For example, the official description of TecDoc solutions distinguishes vehicle information from parts information and describes searches by vehicle parameters, VIN, registration number and original part number. This confirms capabilities across the product family, but does not replace checking the specific contract, dataset and integration method.

A number helps find a candidate, not complete the check

An OE number is an original equipment part number used as one reference for searching. The parts manufacturer’s number, the number in a supplier document and the store’s internal code may differ. Store their types explicitly. If you remove spaces or hyphens for searching, retain the original value as well: normalisation should help matching, not silently change an identifier.

Do not merge items based only on the same short number without the manufacturer context. Likewise, do not turn every link between numbers into an unconditional substitution. A cross-reference, a new number superseding an old one and a confirmed equivalent are different relationships. Each needs a source, a direction and any restrictions present in the source data.

An uncertain result is a state of its own. If a service finds several possible vehicle variants, the website should ask for clarification rather than select the first answer at random. If fitment has not been checked, that is not the same as ‘does not fit’. This distinction allows the sale to continue through a consultation without giving the customer false confidence.

Which sources should form the catalogue’s foundation

A practical starting point is a small sample of your range and real enquiries received by sales representatives. Check whether you can follow the path from a supplier’s code to your own product and then to the fitment conditions. A full import before this check will only increase the number of errors you will have to track down later.

A specialist catalogue, manufacturer data and a commercial price list answer different questions. A price list may describe prices and stock levels well, yet lack sufficient vehicle data. An industry data exchange format does not create fitment facts on its own either: it defines how to transmit them. In particular, the Auto Care Association distinguishes ACES for fitment from PIES for product information. Whether to use these formats depends on your partners and market, not on a universal requirement for every store.

Before signing a contract with a data provider, clarify your rights to display the information on the website, cache it, use images and pass data to other channels. The technical ability to download a file does not grant a right to reuse it in any way you choose. Licensing terms need to be checked for the specific product and your use case.

The source of every relationship must remain traceable. When two suppliers contradict each other, the team should be able to see where the values came from, rather than investigate a single record that has already been overwritten. Priority rules may differ for descriptions, prices and fitment. A blanket ‘last import wins’ rule for all fields is too crude a solution.

How to show customers the basis for their choice

It is important to retain the vehicle context on the search page. Customers should see which variant the results are currently filtered for and be able to change it. If they arrive at a product through a direct link without a selected vehicle, the product page must not inherit a fitment confirmation belonging to someone else.

It helps to distinguish three messages: confirmed for the specified parameters, clarification required and does not match the checked parameters. Display any material condition alongside the conclusion, such as installation side or an equipment-related qualification. Do not hide it only at the bottom of the description if the purchase decision depends on it.

Hypothetical example: brake pads for two equipment configurations

Imagine a store where the supplier’s data lists two brake pad options for one vehicle model, depending on its braking system. This is a hypothetical example of catalogue behaviour, not a recommendation for a particular car. After the model is selected, the website finds both options but still lacks the necessary clarification.

A poor interface labels both items as suitable and leaves the decision to the customer. A better approach is to show that selection is incomplete, explain which attribute needs confirmation and offer a check by a sales representative. Once that clarification is received, the system stores it with the selection result and does not automatically apply it to another vehicle.

The selection context must reach the order. The sales representative should see the selected vehicle, confirmed attributes, the source of the conclusion and unresolved questions. Otherwise, the website has performed a complex check only for its result to disappear during order processing. Restrict access to VINs and other customer information according to work roles; do not expose them in public page URLs.

For a Drupal project, this model should be incorporated into the entity and integration structure before the final screens are designed. GL.ua (Glyanets) develops Drupal online stores with catalogues and ERP data exchange. However, the availability of a particular parts catalogue, licences and the necessary adapters must be checked within your project, rather than assumed to be a built-in property of the CMS.

What to check in a pilot before a full import

A pilot should prove not that a file has uploaded, but that the store helps customers choose the right product. Assemble test cases with a parts specialist: known correct matches, clearly incorrect options and situations where the source data is insufficient. Record the expected response for each case in advance.

1. Match the part number and brand to the internal product. Check identical numbers across different brands, leading zeros, hyphens and the unit of sale so that normalisation does not merge distinct items.
2. Run searches using a known number, vehicle parameters and a VIN within the chosen service’s coverage. Record which clarifications each route requires.
3. Check fitment restrictions: a similar vehicle variant, a different production period or an equipment configuration from the test sample. The system must not lose these distinctions.
4. Reproduce a response with multiple candidates, missing data and an unavailable external service. None of these states should turn into a positive confirmation.
5. Update the test dataset. Establish what happens to a removed relationship, an old number and an open basket where the product was selected before the update.
6. Create a training order and compare the product, package contents, price and selection context in the store and the business management system. Do not send test orders for real dispatch.
7. Check the mobile journey: changing the vehicle, returning to results and contacting a sales representative should retain the correct context.

Acceptance testing must cover negative responses too. Successfully finding a product is only part of the check. Separately confirm that the store can decline to draw an automatic conclusion. Otherwise, expanding the catalogue will increase not only the number of results but also the number of unverified promises.

The pilot may reveal that supplier codes need cleaning first, rather than a new search interface being built. If the main problem is inconsistent product and partner master data, it is useful to define separately the role of PIM and MDM in data management. Do not add another system without understanding who is responsible for a particular field and for correcting an error.

How to expand the catalogue and measure results

Start with a range for which you have verified data, clear accountability and enough enquiries to assess the result. There is no need to enable automatic confirmation for every make immediately. For the rest, you can retain product search and a managed parts-selection enquiry without concealing coverage limitations.

In your analytics, distinguish the reasons for an incomplete search: the vehicle was not identified, clarification is missing, no relationship to a part was found or a compatible product is not available for sale. These are different problems. The first may need a different identification service, the second a better interface, the third data work and the fourth purchasing action.

Returns should also be classified by reason rather than combined into a single figure. A fitment error, incorrect package contents, a different product in the parcel and cancellation of a purchase require different actions. Compare results within the same product groups and selection journeys. Overall sales growth does not prove that the new catalogue itself reduced errors.

In the estimate, separate access to industry data from cleaning your own catalogue, integration, search, interface work, testing and ongoing support. Recurring costs may include data updates, external requests, infrastructure and resolving conflicting matches. The timeline depends primarily on access, the quality of the source master data and the number of exceptions that need agreement with product specialists.

Expand verified coverage, not the number of promises. If a new category fails the test sample, it is better to keep it on manual selection until the cause is resolved. An accurate ‘clarification required’ does more for trust than a confident mistake that the returns department later has to make up for.

Start by checking the data your business already has

A reliable parts store brings together the product catalogue, fitment sources and sales representatives’ workflows. The interface makes this connection clear to the customer rather than replacing it with an attractive search form. Before major development begins, checking a representative sample is enough to identify gaps and determine which part of selection can genuinely be automated.

If you are planning online store development with a catalogue and integrations, discuss a parts-selection pilot using your data with GL.ua. Anonymised price-list examples, a description of the fitment source and typical enquiries to sales representatives are useful for an initial assessment. They will help agree on the catalogue model and acceptance criteria before the full import and sales launch.