Automotive Spare Parts Management for ERPNext

Key Features

`Part Cross Reference` DocType modelling OE, aftermarket, private-label and competitor equivalences as an explicit graph, with source and confidence fields rather than free-text notes

Directed `Part Supersession` DocType with `superseded_by`, effective date and a bi-directional interchange flag, plus a whitelisted chain-walk method returning every node from a legacy number to the current revision

`Vehicle Fitment` DocType (make, model, year range, engine, trim, position) with a composite index tuned for counter-speed lookups

Keyboard-first counter sales screen resolving plate, VIN fragment, OE number or partial description into a ranked candidate list in a single whitelisted call

On-hand quantity per warehouse pulled from Bin and shown inline against every node of a supersession chain, so substitutions are deliberate

Core charge handling via a linked non-stock Item and a `Core Charge Ledger` written from a `Sales Invoice` `on_submit` doc event registered in `hooks.py`

Core return reconciliation through a Credit Note flow that closes the matching ledger row, making outstanding core liability queryable

Scheduler event recomputing A/B/C velocity classes from Stock Ledger Entry over a rolling window and writing suggested levels to Item Reorder

Replenishment produces a draft Material Request for human review and submission instead of auto-ordering stock

Whitelisted REST methods with stable, documented response shapes for catalog lookup, fitment search and supersession resolution

Role profiles (`Parts Counter`, `Parts Manager`, `Warehouse`) with field-level permissions — counter staff apply supersessions but cannot edit cross-reference sources

Bulk catalog and fitment ingest through Frappe Data Import with a pre-flight validation pass reporting unresolvable references instead of creating orphans

Client scripts adding inline fitment confirmation and supersession prompts to Sales Order and Sales Invoice without patching core forms

Delivered as a standalone Frappe app installed with `bench get-app` / `install-app`, so ERPNext core upgrades remain safe

Version-targeted for Frappe/ERPNext v15 and v16, with the exact target confirmed at scoping

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your ERPNext.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Auto parts distribution breaks the assumptions ERPNext core makes about an Item. A brake pad is not one part number — it is an OE number, three aftermarket equivalents, two private-label SKUs, a supersession chain that has moved through four revisions, and a fitment list covering nine make/model/year/engine combinations. When a counter customer arrives with a plate number or a worn part in their hand, the parts advisor has seconds to find what actually fits, see what it supersedes to, check whether the shelf holds the superseded or the current revision, and quote a price that includes a refundable core charge. ERPNext gives you Item, Item Variant, Customer Item Code and Item Price — all useful, all one-to-one. It has no concept of an equivalence graph, no supersession direction, no vehicle-fitment dimension, and no core-charge liability tracked from the outbound invoice through to the returned casing. Distributors end up running the real catalog in a spreadsheet beside ERPNext, and the ERP becomes the place where stock is recorded after the fact rather than where the sale is made.

ECOSIRE builds this as a proper Frappe app — its own repository, its own module, installed with bench get-app and bench --site <site> install-app, versioned in git and upgradable independently of your ERPNext version. At its centre is a Part Cross Reference DocType that models equivalence as an explicit graph rather than a text field: each row links a source Item to a target Item or an external number and carries a reference type (OE, Aftermarket, Private Label, Competitor) plus confidence and source fields, so a match taken from a manufacturer catalog is distinguishable from one a counter clerk added. Part Supersession is deliberately a separate, directed DocType — superseded_by, effective date, and a bi-directional flag for parts that interchange both ways — because supersession is a chain, not an equivalence. A frappe.whitelist() method walks that chain to the current live revision while returning every intermediate node, so the counter can still sell what is physically on the shelf. Fitment lives in Vehicle Fitment (make, model, year range, engine, trim, position) with a composite index tuned for the lookup your counter actually performs.

The counter workflow is where the app earns its keep. A Counter Sale DocType wraps a fast, keyboard-first screen built as a Frappe page with client scripts over Sales Invoice, backed by whitelisted search methods that resolve a plate, VIN fragment, OE number or partial description into a ranked candidate list in one round trip — no per-keystroke DocType queries. Selecting a superseded part surfaces the chain inline with on-hand quantity per warehouse pulled from Bin, so substitution is a conscious decision rather than a surprise at picking. Core charges are modelled as a linked non-stock Item plus a Core Charge Ledger entry created in a Sales Invoice on_submit doc event registered in hooks.py; the returned casing is reconciled through a Credit Note flow that closes the ledger row, so outstanding core liability is a queryable number instead of a month-end reconstruction. Replenishment runs off a scheduler event that recomputes velocity classes (A/B/C by movement, not value alone) from Stock Ledger Entry over a rolling window, writes suggested levels back to Item Reorder, and produces a draft Material Request for human review rather than silently ordering stock.

Everything is built the way Frappe expects. Business logic sits in server scripts and controller hooks, not patched core files, so bench update stays safe. Permissions ship as role profiles — Parts Counter, Parts Manager, Warehouse — with field-level permissions, so a counter clerk can apply a supersession but not edit a cross-reference source. Every DocType is exposed over the Frappe REST API, and the performance-sensitive catalog lookups additionally have whitelisted methods with documented response shapes, so a workshop tablet, your website, or a trading partner's system can integrate without scraping the desk UI. Bulk catalog ingest runs through Frappe Data Import with a validation pass that reports unresolvable references instead of creating orphan records. We target Frappe/ERPNext v15 and v16, and confirm your exact version at scoping.

This is built to order, not downloaded. After you request a quotation we run a scoping call, agree the catalog shape, fitment data source, core-charge policy and counter workflow in writing, then build against your version. Typical delivery is 2-4 weeks from confirmed scope, depending on catalog complexity and how much cross-reference data needs importing. You get the full source in a git repository you own, installation on staging first, a UAT window with your parts team, then production cutover with a documented rollback plan. Fixes and support are covered for an agreed window after go-live.

What you get

Installable Frappe app source code, built and tested against your exact ERPNext version (v15 or v16)

Installation and configuration on your site, including role profiles, permissions and scheduler events

Technical documentation: DocType reference, hooks and doc events, whitelisted API methods with request/response shapes

User guide for counter staff and parts managers, plus one live training session with your team

UAT on a staging site using a real sample of your catalog, with a documented rollback plan before production cutover

Catalog and fitment data import assistance, including a validation report on unresolvable cross-references

Post-go-live support window for defect fixes and configuration questions

Handover of the private git repository, so the source is yours to maintain or extend

Who this is for

Parts Distributor Operations Manager

Runs a multi-warehouse distribution business with tens of thousands of SKUs and a cross-reference file that still lives in Excel. Needs equivalence and supersession data inside ERPNext so quoting, picking and stock decisions all read the same catalog.

Counter Sales Supervisor

Judged on how quickly the trade counter turns a customer around. Needs a lookup that accepts whatever the customer offers — a plate, an OE number, a description — and instantly shows what fits, what supersedes to what, and what is on the shelf.

Workshop or Service Centre Owner

Buys parts and consumes them on repair orders. Needs fitment confirmation before ordering to cut wrong-part returns, and core charges tracked so refundable casings are not quietly written off.

ERPNext Systems Administrator

Owns the site and its upgrade path. Wants business logic in a separate installable app using hooks and server scripts rather than core patches, documented APIs, and a git repository they can inspect and maintain.

How Automotive Spare Parts Management for ERPNext Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
Cross-reference and supersession model	Purpose-built equivalence graph plus a directed supersession chain with effective dates	Whatever your developer designs; quality depends entirely on their parts-domain knowledge	Usually a flat equivalence list; supersession direction and chains rarely modelled	Item, Item Variant and Customer Item Code only — one-to-one, no equivalence graph
Vehicle fitment lookup	Dedicated `Vehicle Fitment` DocType with indexed make/model/year/engine search	Buildable, but fitment indexing is commonly under-designed and degrades as data grows	Often absent, or bolted on as a text attribute on the Item	No fitment concept at all
Counter sales speed	Keyboard-first screen; one whitelisted call resolves plate, OE or description to ranked results	Depends on the build; naive per-keystroke DocType queries are the usual failure mode	Generic POS screen with no parts-specific lookup path	Standard Sales Invoice form — accurate, but not built for counter tempo
Core charge tracking	Ledger DocType written on invoice submit, closed by a Credit Note return flow	Achievable, though the return-reconciliation half is the part DIY builds most often skip	Rarely covered; treated as an ordinary line item with no liability tracking	No core charge concept; handled manually as a line item
Replenishment logic	Scheduled velocity classing from Stock Ledger Entry, producing draft Material Requests for review	Feasible, but rolling-window velocity logic is frequently simplified to value-only ABC	Typically static reorder levels set by hand	Item Reorder levels, maintained manually per item and warehouse
Upgrade safety	Separate installable app using hooks and server scripts; no core patches	Varies — core patching is a common shortcut that later blocks `bench update`	Usually a proper app, but its release cadence is not tied to your upgrade plan	Core itself; upgrades are safe, but every gap stays your manual problem
Integration surface	Documented whitelisted methods with stable response shapes, plus full REST API access	APIs exist if specified up front; often an afterthought	Standard REST on its DocTypes; purpose-built lookup endpoints uncommon	Full REST API on core DocTypes, but no parts-domain endpoints to call
Delivery and ownership	2-4 weeks from confirmed scope, UAT on staging, git repository handed to you	Timeline and code quality depend on the team you hire; ownership usually yours	Immediate install, but you inherit the vendor's roadmap and cannot change the code	Available today; the gaps remain yours to work around

Frequently Asked Questions about Automotive Spare Parts Management for ERPNext

How long does delivery take?

This is a build-to-order app, not an instant download. Typical delivery is 2-4 weeks from confirmed scope. The clock starts once we have agreed in writing on your catalog shape, fitment data source, core-charge policy and counter workflow — we do not start building against an unconfirmed brief. Large catalog imports or unusual fitment sources can extend that, and we tell you before quoting, not after.

What is included in support and updates?

A post-go-live support window is included in every engagement for defect fixes and configuration questions; its exact length is stated in your quotation. Because you receive the full git repository, you can also maintain it yourself or hand it to another developer. Version upgrades — moving the app from ERPNext v15 to v16, for example — and new feature work are quoted separately as change requests.

Which ERPNext versions do you support?

We target Frappe/ERPNext v15 and v16 and build against your exact version, confirmed at the scoping call. We do not ship one build and hope it runs everywhere. If you are on an older self-hosted version, we will tell you honestly whether it is worth building against it or upgrading first.

Will this break my ERPNext upgrades?

No. It is delivered as a separate Frappe app with its own module, installed via `bench get-app` and `bench --site <site> install-app`. Logic lives in `hooks.py` doc events, server scripts and client scripts — we do not patch ERPNext core files, so `bench update` remains safe. Every DocType we add is namespaced to the app.

Can you import our existing cross-reference and fitment data?

Yes. Ingest runs through Frappe Data Import with a pre-flight validation pass that reports unresolvable references — a target part number that does not exist, a supersession pointing at a deleted Item, a fitment row with no matching vehicle — instead of silently creating orphan records. We agree the file format at scoping. Data cleansing beyond mapping and validation is scoped separately if your source needs it.

Can other systems talk to the catalog?

Yes. Every DocType is available through the standard Frappe REST API, and the performance-sensitive lookups — fitment search, supersession resolution, cross-reference expansion — also have `frappe.whitelist()` methods with documented, stable response shapes. That is how a workshop tablet, your website or a trading partner integrates without scraping the desk UI.

How do core charges work in practice?

The core is a linked non-stock Item added to the sale. On `Sales Invoice` submit, a `hooks.py` doc event writes a `Core Charge Ledger` row capturing the customer, the part and the amount. When the casing comes back, a Credit Note flow closes the matching row. Outstanding core liability then becomes a figure you can query and report on, rather than something reconstructed from invoice lines at month end.