Multi-Carrier Rate Shopping Engine for ERPNext

Key Features

`Carrier Rate Request` orchestration DocType that fans out one request concurrently to every enabled carrier connector and aggregates the responses

Normalized `Carrier Rate Quote` child rows so DHL, Aramex, FedEx and local couriers are compared on a common schema (service level, transit days, base, surcharges, landed total)

`Rate Shopping Rule` DocType with cheapest / fastest / best-value policies and a configurable transit-vs-cost weighting factor

Dimensional-weight calculation from per-carrier volumetric divisors, compared against actual weight to match real carrier billing

Zone and weight-band resolution driven by carrier-specific tables, refreshed on a scheduler event

Hard-constraint rules (service exclusions, hazmat/perishable restrictions, max transit days, markup caps) evaluated before selection

Customer-facing shipping markup layer that applies handling margin while retaining raw carrier cost on the quote for reconciliation

Client script adding a 'Shop Rates' action with ranked inline quotes on Quotation, Sales Order and Delivery Note

`Delivery Note` `validate` / `before_submit` doc-event hook that auto-assigns the winning carrier, service level, tracking-carrier field and chosen rate

Whitelisted REST methods (`@frappe.whitelist()`) `get_rates()` and `select_rate()` for storefront, POS and headless-checkout integration

Per-company / per-warehouse / per-customer-group / per-item-group rule scoping so different channels shop rates differently

Rate caching with configurable TTL and stale-quote expiry via a Frappe scheduler event to control carrier-API call volume

Role-profile and permission-rule gating so carrier credentials and pricing logic are restricted from general users

Error and fallback handling when a carrier connector times out, returns no service, or fails auth — logged and surfaced without blocking the sale

Audit trail linking every shipment back to the quote set it was chosen from, for margin analysis and carrier SLA review

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

If you run more than one carrier account, ERPNext gives you a Shipping Rule engine that resolves to a flat or slab-based charge from a table you maintain by hand — it does not call your carriers, does not know today's fuel surcharge, and cannot compare DHL against Aramex against your local courier for a specific parcel. The result is either overpaying because you default everything to one carrier, or a person tabbing between four carrier portals copying quotes into a Sales Order. Neither scales past a few dozen shipments a day, and neither reflects dimensional weight, zone bands, or the negotiated discounts sitting in your carrier contracts.

ECOSIRE builds the Multi-Carrier Rate Shopping Engine as a proper Frappe app (its own module, DocTypes, and hooks.py wiring) installed on your ERPNext v15 or v16 bench. At its core is a Carrier Rate Request orchestration layer: given an origin, destination, weight, and package dimensions, it fans out concurrently to every carrier connector you have enabled and normalizes each response into comparable Carrier Rate Quote rows (service level, transit days, base cost, surcharges, landed total). A Rate Shopping Rule DocType lets you define selection policy per company, warehouse, customer group, or item group — cheapest, fastest, or best-value with a configurable transit-vs-cost weighting — plus hard constraints like "never ship perishables on ground" or "cap markup at 15%". Dimensional weight is computed from your carrier divisors and compared against actual weight so quotes match what the carrier will actually bill.

The engine hooks into the documents where the decision actually happens. A client script surfaces a "Shop Rates" action on Quotation, Sales Order, and Delivery Note so an agent sees ranked live quotes inline; a Delivery Note validate/before_submit doc event can auto-assign the winning carrier, write the service level, and stamp the chosen rate and margin. Customer-facing markup is applied through a rules layer so the rate you show at checkout already includes your handling margin, while the raw carrier cost is retained on the quote for reconciliation. Everything is exposed over the Frappe REST API through whitelisted methods (@frappe.whitelist()), so your storefront, POS, or a headless checkout can request get_rates() and post back the selection without touching the carrier APIs directly. A scheduler event refreshes cached zone/fuel tables and expires stale quotes, and all access is gated by Frappe role profiles and permission rules so pricing logic and carrier credentials stay locked down.

Because this is build-to-order, we start from your actual carrier mix and contracts rather than a generic template. After a short scoping call we confirm which carriers, service levels, and selection rules you need, then build against your ERPNext version, run it through UAT on a staging bench, and hand over installable source and a Git repository. Typical delivery is 2–4 weeks from confirmed scope depending on how many carrier connectors and edge-case rules are in play. You get the code, the docs, a training session, and a post-go-live support window — not a black box.

What you get

Installable source code for your ERPNext v15 or v16 version, built as a proper Frappe app

Installation and configuration on your bench (staging first, then production) including carrier connector wiring

Technical documentation: DocType reference, hooks, whitelisted API methods, and rule configuration

End-user guide plus a live training session for shipping and sales staff

UAT on a staging bench with agreed acceptance criteria and a documented rollback plan

Post-go-live support window for bug fixes and configuration adjustments

Git repository handover with full commit history so your team owns and can extend the code

Rule and rate-table seed configuration matched to your carriers, zones and contracts

Who this is for

Multi-carrier ERPNext merchant

Runs three or more live carrier accounts and wants ERPNext to pick the cheapest or fastest option automatically instead of defaulting everything to one courier or hand-copying quotes from carrier portals.

Fulfillment / warehouse operations lead

Owns the Delivery Note process and needs carrier auto-assignment, service-level rules and dimensional-weight accuracy so packers stop guessing and shipments go out on the right service every time.

Ecommerce / omnichannel manager

Needs live, marked-up shipping rates surfaced at checkout via the Frappe REST API so the customer sees an accurate landed price and the business protects its handling margin.

Finance / margin owner

Wants raw carrier cost retained alongside the customer-facing rate and an audit trail from shipment back to quote, to reconcile carrier invoices and review which carriers actually hit their SLAs.

How Multi-Carrier Rate Shopping Engine for ERPNext Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
Live carrier rate comparison	One request fans out to all connected carriers and ranks them	Possible but you build the orchestration yourself	Often single-carrier or a fixed shortlist	None — Shipping Rules are static hand-maintained tables
Auto-selection logic	Cheapest/fastest/best-value rules per company, warehouse, customer	Whatever you code and maintain	Basic or cheapest-only, limited scoping	No selection — one rule resolves to one charge
Dimensional weight	Per-carrier divisors, billed on greater of actual vs volumetric	Must be implemented and tested per carrier	Sometimes supported, often generic	Not modeled
Delivery Note auto-assignment	`before_submit` hook stamps winning carrier, service, rate	Custom doc events you write and own	Rarely wired into Delivery Note	Manual carrier entry
Customer-facing markup	Margin layer with raw cost retained for reconciliation	Build your own markup and audit fields	Limited or no margin handling	Only what a static Shipping Rule charges
API / headless access	Whitelisted REST methods for storefront, POS, headless	You expose and secure the endpoints	Varies; may be UI-only	No live rate API
Fit and ownership	Scoped to your carriers + ERPNext version, source + Git handed over	Fully yours but you carry all the build risk	Generic; you adapt to its assumptions	Fits nothing beyond flat tables
Support model	Install, UAT, training, post-go-live support window	Your team supports it	Vendor support, upgrade risk on your version	Community/self-support

Frequently Asked Questions about Multi-Carrier Rate Shopping Engine for ERPNext

How long until it is live?

This is build-to-order, so it is built for your carrier mix and ERPNext version rather than downloaded ready-made. Typical delivery is 2–4 weeks from confirmed scope, depending on how many carrier connectors and edge-case selection rules are involved. We confirm the exact timeline in writing after the scoping call.

Which carriers does it support?

The engine is carrier-agnostic — it fans out to whatever carrier connectors you have installed and enabled in ERPNext. During scoping we confirm your carriers (for example DHL, FedEx, Aramex, UPS, or a regional/local courier). If a carrier you use has no existing connector, we quote building that connector as part of the same engagement.

Is this an existing Frappe Marketplace app I can just install?

No. ECOSIRE designs, builds, installs and supports this specifically for your ERPNext v15/v16 bench, your carrier contracts, and your selection rules. There is no instant download — you are buying a scoped build plus installation, documentation, training and support, and you receive the full source and Git repository.

How does it handle support and future ERPNext updates?

Every build includes a post-go-live support window for bug fixes and configuration tweaks. Because you receive installable source and the Git repository, your own team can maintain and extend it. For version upgrades (for example a v15-to-v16 migration) or new carriers and rules after the support window, we offer a maintenance arrangement or scoped follow-on work.

Will it interfere with ERPNext's native Shipping Rules?

It runs alongside ERPNext core rather than replacing it. Native Shipping Rules stay available; the rate shopping engine adds live multi-carrier comparison and auto-selection on Quotation, Sales Order and Delivery Note through client scripts and doc-event hooks, so nothing in standard ERPNext is patched destructively.

Can our storefront or POS call it directly?

Yes. Rate shopping is exposed over the Frappe REST API through whitelisted methods such as `get_rates()` and `select_rate()`, so a web storefront, a headless checkout, or ERPNext POS can request live marked-up rates and post back the customer's selection without ever handling carrier credentials themselves.

How do you make sure the quoted rate matches what the carrier actually bills?

The engine computes dimensional (volumetric) weight from each carrier's divisor and bills against the greater of actual and dimensional weight, resolves the correct zone and weight band, and includes surcharges in the landed total. We validate the numbers against your real carrier invoices during UAT on staging before go-live.