Building Parts eCommerce on Odoo: Why Vanilla Odoo Isn't Enough

If you sell parts that customers buy by Make, Model, and Year — cars, trucks, motorcycles, aircraft, boats, RVs, industrial equipment — and you're evaluating Odoo as your operating platform, this post is for you.

Odoo is a genuinely strong ERP. For most industries, it handles inventory, purchasing, accounting, CRM, and manufacturing well enough that you don't need to think about the platform. For parts businesses, though, there's a critical gap between what Odoo ships with and what your customers expect from your storefront and your B2B portal. The gap isn't a flaw in Odoo — it's just that Odoo was built as a general-purpose platform, and MMY-driven parts businesses have very specific requirements that don't fit the general case.

This post walks through what those gaps actually are, what fills them, and what a real parts eCommerce implementation on Odoo looks like. It's aimed at operators and decision-makers who are evaluating whether to bet their operation on Odoo, not at technical readers looking for module-level detail.

What Odoo does well for parts businesses

To be fair to Odoo, it's worth being specific about what already works before we talk about what doesn't. Out of the box, Odoo handles:

• Inventory and warehousing. Multi-location stock, bin management, reorder rules, cycle counts, transfers — all native. For most parts businesses, this is enough without customization.
• Purchasing and vendor management. Vendor pricelists, purchase agreements, dropship configurations. Solid.
• Accounting. Full double-entry, multi-currency, multi-company. Real accounting, not a bookkeeping app pretending to be one.
• CRM and sales pipeline. Lead-to-opportunity workflow, quote generation, sales team dashboards. Works well for both consumer and B2B channels.
• Basic eCommerce. Product listings, cart, checkout, payment processing, order management. Good foundation.

That's a serious feature set. For a business selling generic products — not parts — Odoo alone would typically get you to launch without additional layers. The problem is specifically the parts context.

The five gaps that break parts businesses on vanilla Odoo

Gap 1: No Make/Model/Year fitment lookup

Your customer arrives at your storefront looking for brake pads. They don't want to see all brake pads. They want to see the brake pads that fit their 2019 Toyota Camry V6. That means the storefront needs to ask, first, what they drive — and then filter everything else based on that answer.

Vanilla Odoo's product filters are attribute-based. You can filter by brand, category, price. You cannot filter by "vehicles this fits." There's no native concept of a vehicle in Odoo, no native concept of fitment, no native way to say "product A fits vehicles X, Y, Z." Building this from scratch is a substantial project, and most teams underestimate how much data maintenance the fitment database requires ongoing.

Gap 2: No ACES/PIES data structure

The automotive aftermarket runs on two industry-standard data formats: ACES (Aftermarket Catalog Exchange Standard) for application data (which parts fit which vehicles), and PIES (Product Information Exchange Standard) for product data (attributes, images, descriptions). If you're buying data from manufacturers, distributors, or a fitment provider, it comes in ACES/PIES. If you're publishing data to distribution partners, they expect ACES/PIES.

Odoo's product model wasn't designed with ACES/PIES in mind. You either build a mapping layer that translates between the two formats and Odoo's native model, or you constantly wrestle with data that doesn't quite fit. Neither is fun. Both take engineering effort.

Gap 3: No customer vehicle garage

Trade customers and consumers both expect to save their vehicles. A workshop that services three fleet vehicles wants to save all three and switch between them when ordering parts. A consumer with two cars in their driveway wants both saved so they don't re-enter Make/Model/Year every visit.

This "customer garage" pattern is standard on every serious parts storefront. It's not in vanilla Odoo. Bolting it on isn't just a UI feature — it requires linking vehicles to customer accounts, filtering cart contents against saved vehicles, showing fitment warnings when a customer adds a part that doesn't fit their saved vehicle. All doable, none free.

Gap 4: No B2B trade account logic

Consumer and trade customers shop very differently. A consumer visits, searches, adds to cart, pays with a card. A trade customer visits, filters by their fleet vehicle list, sees their negotiated pricing tier, orders on credit terms, and expects the invoice to show up in accounting with their PO number attached.

Vanilla Odoo can handle both, but not natively at the same time. You'd need pricing rules that vary by customer group, credit limit enforcement at checkout, PO number capture, quick-reorder workflows, and often multi-user account structures (an owner user plus staff sub-users under the same trade account). This is the B2B portal layer, and it's the one most likely to trip up teams that budget for "eCommerce" without thinking through trade requirements.

Gap 5: No fitment-aware kit or bundle logic

Parts businesses sell kits — brake kit (pads + rotors + hardware), tune-up kit (filter + spark plugs + oil), service kit (multiple parts for a specific vehicle service). Kits vary by vehicle. The brake kit for a 2019 Camry contains different rotors than the brake kit for a 2019 F-150.

Odoo handles kits generally — bundles of parts sold together at a fixed price. It doesn't handle vehicle-aware kits — kits whose contents are determined by the target vehicle. That has to be added on top, tied into both the fitment layer and the eCommerce catalog.

What a real implementation stack looks like

When we work with a parts business on Odoo, the implementation typically combines five components running on a single Odoo instance. We'll cover each briefly here; the deeper architecture writeup lives on our parts eCommerce solution page.

1. ShowMyPart API integration. Rather than build and maintain a fitment database in-house, we integrate a third-party fitment API — ShowMyPart being the one we've built the most expertise around. The API provides the vehicle-to-part mappings; we integrate it into the Odoo product catalog and storefront filters.

2. Odoo as the operating platform. The ERP layer stays Odoo. Inventory, purchasing, accounting, CRM, warehousing — all Odoo. The parts-specific layers sit on top of a full Odoo implementation.

3. Parts eCommerce theme. A storefront theme designed for parts businesses. Make/Model/Year selector prominent. Category filtering respects fitment. Product pages show compatible vehicles. Cross-sells matched to service intervals or complementary parts.

4. B2B customer portal. Trade account management on top of the standard checkout — tiered pricing, credit terms, PO capture, saved vehicles per account, multi-user structure. Separate portal for the B2B side while sharing the same catalog and inventory.

5. MMY logic layer. The connective tissue between Odoo's product model, the fitment API, the storefront theme, and the customer portal. This is where the "your Odoo instance thinks about vehicles" behavior actually lives — cross-sells, kit resolution, fitment warnings, catalog filtering, all driven by MMY logic.

Optional, depending on business: a CPQ configurator for shops that do custom builds alongside catalog parts. Performance fabricators, hot rod shops, custom RV outfitters — anyone selling built-to-order product mixed with catalog inventory — often benefits from adding AktivCPQ to the same Odoo instance.

The buy-vs-build question, honestly

When we walk a parts business through this list, the first question is usually: "Can we build the layers ourselves?" Technically, yes — everything above is buildable in Odoo with enough engineering. Whether you should is a different question.

The build-in-house approach makes sense when:

• You have Odoo-experienced developers already on staff
• Your fitment requirements are narrow (one vehicle family, one industry vertical)
• You want to own the IP for strategic reasons
• You're willing to accept a 12+ month timeline

The buy-and-integrate approach makes sense when:

• You want to be live in months, not years
• You'd rather focus your engineering on parts-domain-specific advantages than platform plumbing
• You want ongoing fitment data maintenance handled by the API provider
• You want a proven pattern rather than a custom architecture

Most mid-market parts businesses we talk to land on buy-and-integrate. The math on data maintenance alone is compelling — maintaining a fitment database in-house is a full-time job that ShowMyPart's provider does at scale. But the honest answer depends on your specific situation.

Beyond automotive: other MMY-driven industries

Everything above is written in automotive language because that's where the biggest market is. But the same architecture works for any industry where the buyer identifies compatibility by Make, Model, and Year (or model number, or serial range).

Aircraft parts. Marine (boats, personal watercraft, outboard motors). RVs and campers. Powersports (motorcycles, ATVs, snowmobiles). Industrial equipment (forklifts, generators, agricultural machinery). Even non-vehicle categories like appliance parts and small engine parts follow the same MMY-lookup pattern.

The technical stack is largely the same across all these. What differs is the fitment data source (ShowMyPart is automotive-focused; other verticals have their own data providers), the compliance requirements, and the specifics of trade account structures. The Odoo base, the eCommerce theme approach, the B2B portal, and the MMY logic layer transfer across industries with adaptation.

What we don't recommend

A few honest calls we've made after doing this work:

Don't try to build parts eCommerce on Shopify beyond a certain size. Shopify with a fitment app is fine for early-stage or small-catalog businesses. Once you have multi-warehouse inventory, real B2B trade accounts, ACES/PIES data flows with distributor partners, and integrated accounting, you'll outgrow it. The migration off Shopify at that point is painful.

Don't try to run parts on Salesforce Commerce Cloud unless you're enterprise-scale. The licensing costs alone will crush the margin on any mid-market parts business. Salesforce Commerce is built for a scale of business that doesn't map to typical parts distribution economics.

Don't buy an all-in-one "automotive parts platform" that isn't ERP-grade. There are several vertical solutions that handle the parts eCommerce side beautifully but treat accounting, inventory, and warehousing as afterthoughts. You'll end up paying twice — once for the vertical platform and again for whatever you patch onto it for real operations.

Don't underestimate the data cleanup effort. Whatever platform you land on, the biggest work item is almost always getting your catalog data — SKUs, attributes, fitment, images, pricing — into a clean, structured form. That work has to happen regardless. Budget for it up front.

Where to go from here

If you're actively evaluating platforms for a parts business, our parts eCommerce solution page covers what we specifically build — the ShowMyPart integration, the eCommerce theme, the B2B portal, the MMY logic layer, and how the pieces fit onto Odoo.

If you're a manufacturer or distributor evaluating whether to consolidate a disconnected stack of ERP, eCommerce, accounting, and CRM tools into one Odoo instance, our breakdown of the real cost of a disconnected stack covers the underlying economics.

Or if you'd rather just talk to someone, the Aktiv Software team is the group that actually delivers this work. A 30-minute conversation is usually enough to figure out whether we're a fit for what you're trying to build. You can reach out here.