MPMS addresses a specific automotive parts-planning question: for each part and market, which vehicles in operation can use that part, and what annual replacement opportunity does that population represent?

The solution uses Databricks and PySpark to resolve vehicle-part matches from fitment rules, retain the rule behind every match, and calculate business-facing measures by part, market and reporting year. It connects vehicle configuration to planning decisions through one traceable chain:

Vehicle configuration → Rule-based part applicability → Eligible fleet → Annual replacement potential → Commercial sales and captured-share measures → Planning decisions

MPMS combines seven inputs. Each has a distinct role in the calculation:

• Parts master – part identifiers and active status, so only active parts are evaluated.
• Vehicle documentation – VIN, market, model type, BM/BR identifiers and installed options; the configuration that rules are matched against.
• Fitment rules – applicable configurations, required options, market restrictions, effective dates, fitment position and rule version.
• Vehicle population – active fleet, eligibility dates and vehicle age.
• Replacement assumptions – annual replacement rates by part, market and vehicle-age band.
• Warranty claims – approved replacement quantities for the reporting year.
• Commercial sales – sold quantities, maintained separately from warranty claims.

Warranty claims and commercial sales are kept apart on purpose: they are different business events, and blending them would distort market-share measures.

Planning teams need a reliable count of vehicles that can use each part. Producing it is harder than it looks:

• Part number alone is not enough – applicability depends on vehicle configuration, installed options, geography, effective dates and fitment position.
• Naive comparison does not scale cleanly – comparing every vehicle with every part creates a vehicle-count × part-count candidate space.
• Multiple matches can inflate counts – a vehicle can match the same part through more than one rule or fitment position; without deduplication, fleet counts are overstated.
• Different business events must stay separate – warranty replacements and commercial sales measure different things and cannot be interchanged in share calculations.

MPMS handles each of these explicitly, so the resulting measures can be explained and defended in planning discussions.

Configuration-Aware Matching
MPMS filters to active parts and effective-dated rules, then uses separate Spark matching paths for exact BM+BR, BM-only, BR-only and model-type-level rules. Market restrictions are applied, and a rule matches only when every option it specifies is installed on the vehicle. Keeping each rule type in its own path makes the matching logic explicit and easier to review with fitment owners.

Traceable Applicability
Every match retains the VIN, part number, market, fitment position, matched rule ID and rule version. For any part-and-vehicle result, planners can see which rule supported it and which version of that rule was in force.

Eligible-Fleet Calculation
Applicability is deduplicated to VIN, part and market before it is joined to the eligible fleet. Multiple rule or position matches therefore do not count the same combination repeatedly, and the eligible fleet reflects distinct vehicles rather than distinct matches.

Annual Market Potential
Annual replacement rates by part, market and vehicle age are applied to the eligible fleet, and expected replacement quantities are aggregated by part and market. The rates are supplied as an input dataset and require business approval before production use.

Separate Commercial Measures
Approved warranty claims and commercial sales are aggregated independently. Each remains visible as its own measure, so warranty replacements are never counted as commercial sales.

Captured Share
Captured share relates commercial sales to the market opportunity:

Captured share (%) = Commercial sales quantity ÷ Estimated annual replacement potential quantity × 100

This is the implemented working definition and requires business approval before it is used to drive decisions.

Repeatable Execution
A Databricks Workflow runs a single notebook task that writes nine managed Delta tables in Unity Catalog. The technical bundle, deployed with Databricks Asset Bundles, is named supply-chain-demand-forecasting.

MPMS is organized around business transformations rather than storage layers. Each step turns one planning concept into the next:

1. Parts + Vehicle Configuration + Fitment Rules
Active parts · VIN, market, model type, BM/BR, installed options · effective-dated rules
↓ Match configuration, options, market and dates to fitment rules

2. Rule-Based Applicability
VIN · part · market · fitment position · matched rule ID · rule version
↓ Deduplicate to VIN / part / market, then join the eligible fleet

3. Eligible Fleet + Replacement-Rate Assumptions
Active, eligible vehicles with age · rates by part, market and vehicle-age band
↓ Apply annual replacement rates by vehicle-age band

4. Annual Market Potential
Expected replacement quantity by part and market
↓ Bring in reporting-year warranty claims and commercial sales

5. Separate Warranty Claims + Commercial Sales
Two independent measures for the reporting year
↓ Compare commercial sales with annual replacement potential

6. Part-and-Market Planning View
Eligible fleet · replacement potential · warranty claims · commercial sales · captured share

Delta tables in Unity Catalog hold the outputs; the transformations above define the solution.

Matching correctness is checked by comparing the set of applicable vehicle-part pairs produced by MPMS with the output of an independent, bounded reference implementation. The purpose is to confirm that rule-based matching returns the same set of pairs. It is a correctness check and is not presented as evidence of a runtime improvement; reducing the number of candidate pairs to the applicable pairs is a logical outcome of the rules, not a measured reduction in Spark processing work.

• Databricks Workflows – runs the repeatable notebook task
• Serverless compute – executes the workflow
• Apache Spark / PySpark – rule matching, deduplication and aggregation
• Delta tables – nine managed output tables
• Unity Catalog – governed home for the output tables
• Python notebooks – implementation of the processing logic
• Databricks Asset Bundles – deployment of the supply-chain-demand-forecasting bundle

Future Extension: Demand Forecasting
A separate optional forecasting notebook exists but has not been executed; it requires approved monthly demand history. Forecasting is a future extension of MPMS and is not part of the delivered outcomes.

Implemented Capabilities

• Repeatable applicability and market-potential calculations by part, market and reporting year.
• Rule-level traceability from every match back to rule ID and rule version.
• Correctness comparison of the applicable vehicle-part set against a bounded reference.
• Separate warranty-claim and commercial-sales measures.

Decisions the Solution Supports
After validation with approved inputs, MPMS can support planning teams in:

• Comparing opportunity – addressable fleet and annual replacement potential by part and market.
• Targeting investigation – high-potential, low-sales part-and-market combinations.
• Setting priorities – stocking priorities, distribution coverage and sales focus.
• Preparing for forecasting – a consistent applicability and potential foundation for future demand forecasting.

Production Prerequisites
Before production use, the following need to be in place:

• Approved fitment rules and fleet-eligibility definitions.
• Approved replacement rates and an approved captured-share definition.
• Reconciliation of inputs to their source records.
• Benchmarking at representative scale.

MPMS – from vehicle configuration to part-and-market planning decisions