Delivery Driver Operations

Características clave

New `Delivery Trip`, `Delivery Stop` and `Delivery Event` tables with driver and vehicle on the trip, and stops linked by RecordId to the source Warehouse Shipment or Posted Sales Shipment rather than duplicating shipment data

Trip planning page that pulls released Warehouse Shipments into a run, sequences stops by drag-order or postcode grouping, and enforces per-vehicle weight and volume capacity from item unit-of-measure data

Table and page extensions stamping trip no., stop no. and delivery status onto `Sales Header`, `Warehouse Shipment Header` and `Sales Shipment Header`, with FactBox visibility for warehouse and accounts users

Mobile-web driver task list scoped by user so a driver sees only their own open stops for the current date, ordered by stop sequence, with tap-to-call and tap-to-navigate on the ship-to address

Proof of delivery capture: recipient name, on-screen signature, multiple photos and GPS coordinates with timestamp, stored in Media/Media Set fields on the stop so evidence lives inside the Business Central database

Line-level delivered, refused and returned quantities per stop, with configurable failed-delivery reason codes that drive return-to-warehouse handling and reporting

Driver cash run with expected COD accrual per stop, end-of-day declared total, per-stop variance analysis and a supervisor approval step before anything posts

Cash receipt posting through the standard Cash Receipt Journal applied to matching `Cust. Ledger Entry` records, honouring your existing bank and cash accounts, posting groups, dimensions and number series — no direct G/L Entry writes

API pages exposed over Business Central REST API v2.0 / OData v4 for trips, stops, POD events and driver cash runs, with OAuth so a Power App or external device app can read and write safely

Event subscribers on the shipment posting codeunits so posting, correcting or undoing a shipment keeps trip and stop state consistent — the subscriber pattern is used throughout instead of base-app modification

Job Queue entries for nightly trip roll-forward, auto-closing of stale runs, KPI snapshot capture and unposted-cash-run alerts to the delivery supervisor

Delivery KPI reports and Power BI-ready datasets: on-time delivery rate, stops per driver per day, failed reasons by cause, average dwell time per stop, and COD variance by driver over a period

Dedicated permission sets separating Dispatcher, Driver and Delivery Supervisor, so a driver account cannot open unrelated customer or financial data

Optional Dataverse / Power Platform connectivity via virtual tables or the API pages, for customers who prefer a Power Apps canvas app or Power Automate notifications on failed delivery

Hecho a medida, listo para ti

Sin configuración por tu cuenta: una app funcional creada, instalada y con soporte de ECOSIRE.

Haces el pedido

Empieza con un precio único de desarrollo. Definimos el alcance contigo en el arranque.

Creamos e instalamos

ECOSIRE la crea, la configura y la instala en tu Dynamics 365 Business Central.

En marcha + soporte

Sales en vivo en unas 2–4 semanas, con un periodo de soporte posterior al lanzamiento.

Sobre este producto

A distributor running its own fleet has a real operational day that Business Central does not model. Warehouse Shipments and Posted Sales Shipments tell you what left the building, but not which van it left on, in what stop sequence, who signed for it, what came back undelivered, or how much cash the driver is carrying at 6pm. Teams fill the gap with a WhatsApp group, a printed manifest and a spreadsheet, then spend the next morning matching signed paper against posted shipments and counting COD envelopes against a cashbox. The Sales Shipment Header, Warehouse Shipment Line and Cust. Ledger Entry tables each hold part of the truth, but nothing joins them into a trip, and nothing in the base app carries a driver, a stop time, a signature or a failed-delivery reason.

We build a Dynamics 365 Business Central extension in AL that adds that missing layer inside the same database and the same posting rules. New tables model Delivery Trip, Delivery Stop and Delivery Event, with the stop pointing back at the source Warehouse Shipment or Posted Sales Shipment rather than duplicating it. A planning page lets dispatch build a trip from released warehouse shipments, assign a driver and vehicle, sequence the stops and set a delivery date and time window. Table extensions stamp the trip and stop reference onto the shipment records so a warehouse or accounts user can always answer "which run was this on" from the document they already have open. Codeunits hold the trip state machine — planned, dispatched, in progress, closed — and event subscribers on the posting codeunits keep the stop in step when a shipment is posted, corrected or undone, so the delivery layer can never drift away from the ledger.

Drivers get a mobile-web task view rather than a native app: API pages exposed over Business Central REST API v2.0 (OData v4) plus a lightweight, phone-sized page that runs in the Business Central web client, or a Power Apps canvas app on Dataverse — whichever fits your licensing and device fleet. A driver sees only their own open stops for today, in sequence, with the customer address, contact number, items and amount due. Arriving at a stop they capture proof of delivery: recipient name, a signature drawn on the phone, photos of the goods or the door, GPS coordinates and a timestamp, all stored against the stop in Media/Media Set fields so the evidence stays inside Business Central and rides your normal backup. A partial or failed delivery is captured with a configurable reason code and a line-level delivered quantity, which drives return-to-warehouse handling instead of becoming an email to the office.

Cash and COD reconciliation is the part that usually justifies the project. Every stop marked as cash-collected accrues against the driver's open run. At end of day the driver closes the run with a declared cash total; a Driver Cash Reconciliation page shows expected versus declared, the per-stop variance, and the unreturned goods. On supervisor approval the extension creates cash receipt lines applied to the correct Cust. Ledger Entry records and posts through the standard Cash Receipt Journal, using your existing bank and cash accounts, posting groups, dimensions and number series — we never write a General Ledger Entry directly. Delivery KPI reports and Power BI-ready API pages then give you on-time rate, stops per driver per day, failed-delivery reasons by cause, average dwell time per stop and COD variance by driver over any period.

This is a build-to-order product, not an AppSource download. After you request a quotation we run a scoping call, confirm your Business Central version and deployment (SaaS or on-premises), your delivery process, your COD and cash-handling rules, and how drivers will get devices. We then quote a fixed scope, build the extension against your version, deliver it to a sandbox for UAT, and go live with you. Typical delivery is 2-4 weeks from confirmed scope. You receive the AL source, the deployable app package, permission sets, technical and user documentation, and a training session, and the code is handed over in a git repository you own.

lo que obtienes

Complete AL source code for the extension, built and tested against your exact Business Central version and deployment type (SaaS or on-premises)

Deployable .app package plus installation and configuration on your sandbox and production environments

Technical documentation: object ID ranges, table and API page schemas, event subscriber map, permission sets, upgrade codeunit notes and integration points

End-user guide for dispatchers, drivers and the delivery supervisor, plus a live training session for your team

UAT on a staging/sandbox environment against your own data, with an agreed test script, sign-off and a documented rollback plan

Post-go-live support window for defect fixes and configuration adjustments on the delivered scope

Handover of the private git repository containing the full source history, so the code is yours to maintain or extend

Data configuration assistance: reason codes, driver and vehicle master setup, cash and bank account mapping, and number series

¿Para quién es esto?

Distribution Operations Manager

Owns the fleet and the daily run. Needs to plan trips from released warehouse shipments in minutes rather than rebuilding a manifest in Excel, see live stop progress during the day, and get a factual on-time and failed-delivery report at week end instead of driver anecdotes.

Delivery Driver

Works from a phone in a van, often with patchy signal and one hand free. Needs a short ordered list of today's stops, the customer's address and phone, what to hand over, how much to collect, and a way to capture a signature and photo in under thirty seconds per stop.

Finance / Accounts Receivable Controller

Carries the risk on cash-on-delivery. Needs every collected amount matched to the right customer ledger entry, a defensible expected-versus-declared reconciliation per driver per day, and cash receipts posting through the standard journals with correct dimensions rather than manual adjustments.

Business Central Partner or Internal IT Lead

Answers for the environment. Needs an AL extension that uses event subscribers rather than base-app modification, survives Microsoft release wave updates, exposes clean API pages for Power BI and Power Apps, and arrives with source code, permission sets and documentation they can maintain.

Cómo se compara Delivery Driver Operations

Criterio	ECOSIRE	Construcción personalizada	Competidor	Nativo de Dynamics 365 Business Central
Fit to your delivery process	Built to your trip, stop and COD rules after a scoping call	Fits exactly, but only after you specify and design everything yourself	Fits the vendor's assumed process; you adapt your operation to it	No trip or stop concept exists; the process lives in spreadsheets
Proof of delivery capture	Signature, photos, GPS and timestamp stored on the stop inside Business Central	Whatever you build; media storage and mobile capture are non-trivial	Usually present, often stored in the vendor's cloud rather than your database	None; POD is paper, or an email attachment on the document
COD cash reconciliation	Expected vs declared per driver, approval step, posts via Cash Receipt Journal	Achievable, but this is where DIY projects most often overrun	Varies widely; many delivery apps stop at collection and hand you a CSV	Manual counting and journal entry against customer ledger entries
Source code and ownership	Full AL source handed over in a git repo you own	You own it entirely, and you own every future fix	Closed source; you depend on the vendor's roadmap and release cadence	Microsoft base app; not yours to change
Upgrade safety across release waves	Event subscribers, no base-app modification, upgrade codeunits included	Depends on your team's discipline; base-app edits are a common trap	Vendor handles it, on their timeline, sometimes with forced version jumps	Nothing to break, because there is nothing there
Cost and timeline	Fixed-scope quote, typically 2-4 weeks from confirmed scope	Open-ended; discovery, design and rework are all on your budget	Fast to install, but per-user monthly fees compound across a driver fleet	No licence cost, paid for in daily manual reconciliation time
Integration and reporting	API pages over REST v2.0 / OData v4, Power BI datasets, Dataverse-ready	You build the API surface and the reports yourself	Vendor API if offered; data often has to be pulled back out of their cloud	Standard shipment data only; no delivery KPIs to report on
Security and access separation	Dispatcher, Driver and Supervisor permission sets; drivers see only their stops	Permission design is your responsibility and is easy to get wrong	Vendor's own role model, which may not map to your BC user setup	Standard BC permissions; no driver-scoped delivery view to restrict

Preguntas frecuentes sobre Delivery Driver Operations

How long does delivery take, and what happens after I request a quotation?

This is a build-to-order extension, not an instant download. After your request we hold a short scoping call to confirm your Business Central version and deployment, your delivery and COD process, and your device situation, then issue a fixed-scope quotation. Typical delivery is 2-4 weeks from confirmed scope, covering build, sandbox deployment, UAT with your data, and go-live. Broader scope — complex route optimisation, a native device app, or a multi-company rollout — is quoted with its own timeline at scoping.

What support and updates do I get after go-live?

Every build includes a post-go-live support window for defect fixes and configuration adjustments on the delivered scope, agreed and written into your quotation. Because we hand over the AL source and the git repository, you are never locked in — your own partner or IT team can maintain it. We also offer ongoing support and compatibility work for future Business Central release waves as a separate engagement; the extension is written with event subscribers and no base-app modification specifically so those upgrades stay small.

Does this run on Business Central SaaS, on-premises, or both?

Both. We build against your version and deployment type. On SaaS it is delivered as a per-tenant extension, or on the AppSource track if you have a reason to prefer that route, installed to your sandbox first and promoted after UAT. On-premises we deliver the .app package with deployment instructions for your service tier. Current supported release waves are targeted by default; if you are on an older version we confirm at scoping what is achievable on it.

Do drivers need a native mobile app or a special device?

No. The standard delivery is a mobile-web driver task view — a phone-sized Business Central page a driver opens in a browser, or a Power Apps canvas app over the same API pages if you already run Power Platform. Any modern smartphone with a browser works, and signature, photo and GPS capture use standard browser capabilities. A native app is possible as an extended scope item, but most fleets do not need one and it adds cost and app-store overhead.

How does COD cash reconciliation post into the ledger — is it safe?

Nothing is posted directly to General Ledger Entries. The extension accrues expected cash per stop, compares it to the driver's declared end-of-day total, and after supervisor approval creates cash receipt journal lines applied to the matching customer ledger entries. Those lines post through the standard Business Central Cash Receipt Journal using your existing bank and cash accounts, posting groups, dimensions and number series, so your normal controls, approvals and audit trail all still apply and the variance is visible before anything is posted.

How is this different from just customising Business Central ourselves?

Nothing stops you — the difference is that the hard parts are already designed. The trip and stop data model that survives shipment corrections and undo, the event subscriber wiring that keeps delivery state in step with posting, the permission separation that stops a driver seeing customer financials, the media storage for signatures and photos, and the cash reconciliation that posts safely through journals are all decisions we have already made and tested. You get the AL source for all of it, so it remains fully customisable by you afterwards.

Will this conflict with our other extensions or a WMS we already run?

We check that at scoping. The extension uses its own object ID range and integrates through event subscribers and API pages rather than modifying base objects, which is what keeps it co-installable. If you already run a warehouse management or 3PL extension we look at where the shipment handover happens and integrate at that boundary — the delivery layer starts where the goods leave the building, so in most cases the two are complementary rather than overlapping.

Delivery Driver Operations

An AL extension for Dynamics 365 Business Central that plans delivery trips and stops, gives drivers a mobile task list, captures proof of delivery, and reconciles COD cash back to the customer ledger. Built to order by ECOSIRE for your version and your delivery process.

Mobile-web driver task list scoped by user so a driver sees only their own open stops for the current date, ordered by stop sequence, with tap-to-call and tap-to-navigate on the ship-to address

¿Qué es Delivery Driver Operations?

¿Qué es Delivery Driver Operations?

Características clave