VCdb, PCdb and PAdb: The Databases Behind ACES Data

You open a supplier’s ACES file expecting a parts list. What you get is a wall of integers.

BaseVehicleID 18243. PartTerminologyID 5340. QualifierId 2871. Nowhere in the file does it say “2015 Ford F-150” or “brake pad”. The words are not missing by accident — they were never in the file to begin with. An ACES document is a set of pointers, and the things it points at live in four separate databases published by the Auto Care Association.

If you do not have those databases, an ACES file is not hard to read. It is impossible to read. This is the single most common reason a parts catalog stalls on its way into a store, and it is worth understanding before you go looking for a tool to fix it.

The four databases, one paragraph each

VCdb — the Vehicle Configuration Database

The VCdb is the vehicle side of the equation. It is a fully normalized relational database of vehicle configurations covering light, medium and heavy duty vehicles, plus powersports, off-highway and equipment. Makes, models, submodels, engine configurations, drive types, bed lengths, body styles.

The important word there is normalized. A vehicle in the VCdb is not one row that says “2015 Ford F-150 XLT 3.5L EcoBoost 4WD SuperCrew”. It is a BaseVehicleID joined to a submodel, joined to an engine configuration, joined to a body type, joined to a drive type. That is why one BaseVehicleID in an ACES file can expand into dozens of real-world vehicles once you resolve it, and why “how many vehicles does this part fit?” is a question with no answer until you have the VCdb open.

PCdb — the Product Classification Database

The PCdb is a classification hierarchy that standardizes part terminology in coded form. It defines the industry’s agreed list of part types and the categories they sit in — so “spark plug” is not a string somebody typed, it is a PartTerminologyID that every participant in the industry resolves to the same thing.

It covers replacement parts, service parts, collision repair parts and aftermarket supplies. This is the database that stops one supplier calling something a “brake pad set”, another calling it “pads, disc brake”, and a third calling it “DISC BRK PAD KIT”. They all reference the same ID, and the disagreement disappears.

PAdb — the Product Attribute Database

The PAdb defines standard attributes for each part classification, across roughly 20 product categories, describing the fit, form and function of a part.

This is what makes attributes comparable rather than merely present. A brake rotor has a diameter, a thickness, a bolt pattern, a vane count. Without the PAdb, each supplier invents their own attribute names and units, and you cannot build a filter, a comparison table or a spec sheet that spans two suppliers. With it, “Rotor Diameter” means the same measurement everywhere.

Qdb — the Qualifier Database

The Qdb classifies application notes. It is the smallest of the four and the easiest to underestimate.

Fitment is rarely absolute. A part fits a vehicle when built before a certain date, with a particular brake option, excluding heavy duty suspension. Those conditions are the qualifiers, and the Qdb turns them from free text into coded, machine-readable conditions. When a customer buys the wrong part despite your fitment lookup saying it fits, an unresolved qualifier is very often the reason.

There is also a Brand Table, which maps brand and sub-brand identifiers to real brand names. Small, but you will notice its absence immediately — every product will be branded with a code.

The subscription structure catches people out

Here is the part that surprises most teams, and it is worth knowing before you budget for this.

The databases are subscription products, and they are bundled in a way that does not match how people assume they work. According to the Auto Care Association’s subscription terms:

• Subscribing to the VCdb gives you the VCdb, Qdb, PCdb and Brand Table. All four are required to create or receive ACES XML.
• Subscribing to the PAdb gives you the PAdb, PCdb and Brand Table. All three are required to create or receive PIES XML.

Read that twice, because the implication is easy to miss. ACES and PIES are usually discussed as a pair, but they do not draw on the same set of databases. ACES needs four; PIES needs three; they overlap on two. If you subscribed once and assumed you were covered for both, you are probably missing something — and the symptom will not be an error message. It will be a column of unresolved IDs in whichever half you did not cover.

This is also why “just send me the ACES file” is an incomplete request. The file is meaningless without the reference data, and the reference data is not the supplier’s to give you.

What resolving a single line actually looks like

It helps to walk one application through the whole chain, because the number of lookups surprises people.

Say the file contains one App element. It carries a BaseVehicleID, a PartTerminologyID, a couple of attribute references and a qualifier. To turn that into something a shopper can use, you resolve:

• The base vehicle, against the VCdb — which gives you a make, model and year range, but not yet a specific vehicle.
• The sub-configuration, also against the VCdb — submodel, engine configuration, drive type, body style, whichever of these the application constrains. This is where one application expands into many real vehicles, or narrows to a handful.
• The part type, against the PCdb — turning the terminology ID into a human part type and locating it in the category hierarchy.
• The attributes, against the PAdb — resolving attribute IDs into named, unit-bearing specifications for that part type.
• The qualifier, against the Qdb — turning the condition into readable text such as a build-date cutoff or an equipment exclusion.
• The brand, against the Brand Table — turning the brand ID into a name you can display.

Six lookups, four databases, for one line of one file. A mid-size catalog has hundreds of thousands of those lines. This is the honest reason spreadsheet-based approaches fall over: not that the work is conceptually hard, but that it is six joins deep and has to be exactly right several hundred thousand times.

It is also why the answer to “can you just export it to CSV?” is usually no. The CSV can hold the resolved output, but producing the resolved output is the entire job.

Version drift is the failure nobody plans for

The four databases are updated on a release schedule. New vehicles appear in the VCdb. New part types appear in the PCdb. Attributes get added, and occasionally deprecated.

That creates a mismatch nobody designs for: the supplier built their ACES file against one version, and you are resolving it against another.

What that looks like in practice:

• A BaseVehicleID in the supplier’s file simply does not exist in your older VCdb. The application resolves to nothing, and the part silently loses coverage for a vehicle it genuinely fits.
• A PartTerminologyID resolves, but to a term that has since been renamed. Your category tree and the supplier’s stop agreeing, and nobody notices until the taxonomy looks wrong.
• A qualifier ID resolves to a different note than the supplier intended. This is the dangerous one, because the part still appears to fit — it just fits under a condition you are now displaying incorrectly.

The last case matters more than the other two. A missing vehicle costs you a sale. A wrong qualifier sells the customer a part that does not fit their car, and you pay for the return, the shipping and the review.

Why a Shopify store cannot hold any of this natively

Once you can read the databases, a second problem starts: the destination has nowhere to put what you just decoded.

There is no fitment concept in a Shopify product. A product has variants, options, metafields and tags. It does not have a structured relationship to a list of vehicles, and there is no native place to express “fits these 340 configurations, with these three conditions”. Fitment has to be modeled — usually into metafields with a defined structure, sometimes into a separate lookup — and the model you choose determines whether a year/make/model search can ever work properly.

Attribute names collapse. The PAdb gives you clean, comparable attributes. Shopify gives you metafields, which are only as consistent as whoever created them. Map carelessly and you will end up with rotor_diameter, Rotor Diameter and diameter_mm on three suppliers’ products, which is the same mess the PAdb exists to prevent.

The hierarchy flattens. The PCdb is a hierarchy — category, subcategory, part type. Shopify collections are not a hierarchy in the same sense. Deciding how the PCdb tree becomes a browsable catalog is a real decision with real consequences for navigation and internal linking, and it is not reversible cheaply once you have thousands of products.

For the wider set of things Shopify does not accept from these standards — the price types, the description codes, the part number question — the companion piece on what ACES and PIES actually are covers that ground in detail. This article is the layer beneath it: the reference data that makes an ACES file legible in the first place.

The four places this quietly goes wrong

Across catalogs we have looked at, the same four failures come up repeatedly.

Three of those four are invisible on the product page. That is what makes them expensive — they are found by customers, not by QA.

What mapping actually involves

“Mapping” gets used loosely, so it is worth being concrete about the work.

For each supplier, it means deciding how their ACES applications resolve against your VCdb version, how PCdb part types become your category structure, which PAdb attributes become metafields and under what names, how qualifiers are represented so they survive into the storefront, and how the Brand Table resolves to the brands you actually display.

Those decisions are per-supplier, and they need to be consistent across suppliers or the catalog fragments. That is the real difficulty: not any single mapping, but keeping twelve suppliers’ mappings coherent so that a filter built on one works on all of them.

It is also why this rarely goes well as a one-time import. Suppliers reissue files. Databases get new releases. A mapping that exists only in the head of the person who did the first import is a mapping that breaks the first time either of those happens.

Where SEMA Data fits

If your suppliers distribute through the SEMA Data Co-op, some of this is handled upstream — the co-op validates and standardizes what member suppliers publish, which raises the floor on data quality considerably.

It does not remove the mapping problem. You still receive standards-compliant data that Shopify has nowhere to put, and you still need to decide how fitment, attributes and hierarchy are represented in your store. The SEMA Data Co-op and Shopify piece covers what the co-op does and does not do for a merchant.

Doing this without rekeying it

Apimio maps ACES applications and PIES attributes into a Shopify-ready structure — fitment preserved as structured data rather than flattened text, PAdb attributes mapped to consistent metafields across suppliers, qualifiers carried through, and the PCdb hierarchy resolved into a category structure you choose rather than one you inherit. The Supplier Bridge side handles the recurring part: suppliers reissue files, and the mapping holds.

One honest note on how this works today. Automotive import is not a self-serve upload screen. We map a real segment of your data with you on a call and switch the module on for your organization once the mapping is right. A merchant-facing upload step is planned, but we would rather tell you what exists now than what is on a roadmap.

If you are earlier in the process and still deciding whether structured fitment is worth the effort at all, the automotive aftermarket overview is the better starting point.

The short version

• An ACES file contains IDs, not words. The words live in four Auto Care Association databases: VCdb (vehicle configurations), PCdb (part types), PAdb (part attributes) and Qdb (application qualifiers), plus the Brand Table.
• ACES requires four of them; PIES requires three. They overlap on two, and subscribing once does not cover both.
• Resolving one application line takes six lookups across four databases. A mid-size catalog has hundreds of thousands of them.
• Version drift between the supplier’s databases and yours is a silent correctness problem — the worst case is a misresolved qualifier, which sells someone the wrong part.
• Shopify has no native fitment concept, no attribute standardization and no real hierarchy, so all three have to be modeled deliberately.
• The expensive failures — flattened fitment, dropped qualifiers, unstandardized attributes — are invisible on the product page and get found by customers.