ERPNext already knows what should leave your warehouse — Delivery Notes are drawn from Sales Orders, stock moves post correctly, and Sales Invoices follow. What ERPNext core does not model is the day itself: which van a Delivery Note is loaded onto, in what order the twenty drops are sequenced, who signed for drop eleven, which customer refused half a pallet, and how much cash each driver is holding when he walks back into the depot at six in the evening. Most distributors bridge that gap with a WhatsApp group and a clipboard, then spend the following morning arguing over which delivery was actually completed and whether the cash count balances. The Delivery Trip DocType in ERPNext gives you a driver, a vehicle and a stop list with map-based optimisation — it does not give you a driver-facing task screen, structured proof of delivery, partial-delivery handling, or a cash reconciliation that closes against a Journal Entry.

ECOSIRE builds a proper Frappe app for this — its own app on the bench with a delivery_operations module, installed alongside erpnext, never a pile of Customize Form overrides that break on the next bench update. The core DocTypes are a Trip Run (driver, vehicle, depot, run date, status workflow of Draft to Dispatched to In Progress to Returned to Reconciled) with a child table of Trip Stops, each linked to the source Delivery Note and carrying its own sequence, planned window, status and outcome reason. A second document, Delivery Proof, is created per stop and holds the recipient name, the signature or photo attachment, geolocation and the client-side timestamp captured on the device. Cash Reconciliation closes the run: it sums the COD amounts of completed stops, records what the driver actually handed over, and posts a Journal Entry through the standard ERPNext accounting API so the depot cash account and the customer receivables move together rather than being patched in later.

The driver side is a mobile-first Frappe web page — a whitelisted controller under @frappe.whitelist() serving a lightweight portal route, not the Desk UI, because Desk on a five-inch screen in a loading bay is not a usable tool. The driver signs in as a real ERPNext User bound to a Delivery Driver role profile, sees only the stops on his own run through a permission query condition on the owning driver field, marks each stop delivered, partially delivered or failed with a reason from a configurable link field, and captures the signature straight into a File attached to the Delivery Proof. Submission goes over the Frappe REST API with an offline queue in the browser so a dead spot in a basement car park does not lose the drop, and the server handles a replayed stop idempotently — the same submission twice does not create two proofs.

Behind that, hooks.py doc events keep ERPNext consistent: on_submit of a Delivery Note can auto-create or attach a Trip Stop, and completing a stop can submit the Delivery Note and trigger invoicing according to the rules we agree during scoping. A scheduler event runs the overnight roll-up that closes returned runs, flags runs where cash collected does not match cash expected, and refreshes report data. Server scripts and controller validation enforce the rules that actually matter to you — a run cannot be reconciled while a stop is still open, a COD stop cannot be marked delivered without a proof record, a vehicle cannot be double-booked for the same slot. Reporting ships as real Query Reports and a dashboard: on-time percentage by driver and by route, failed-delivery reasons ranked, average stops per run, cash variance by driver over time, and drop density by postcode. Permissions are wired through role profiles so a dispatcher plans, a driver only executes, and only a finance role can post the reconciliation Journal Entry.

This is build-to-order, and we say so plainly: there is no instant download. You request a quotation, we run a scoping call of about thirty minutes on your actual routes, COD rules and existing ERPNext setup, and we come back with a fixed scope and price. Typical delivery is one working week from confirmed scope, depending on how much of the invoicing and cash-posting flow you want automated. We build against your Frappe and ERPNext version — v15 or v16 — deploy to your staging bench for UAT first, then to production with a documented rollback. You receive the full source in a git repository you own, so you are never locked to us for the next change.