Delivery Driver / Rider Mobile App for Odoo

No. This is a build-to-order module that ECOSIRE designs, builds, installs, and supports specifically for your Odoo. There is no instant download. We first scope your delivery flow (which model represents a delivery, your COD and notification rules, your branding), then build and deploy the module and its driver front end to your database. You receive ownable source code, not a generic marketplace app.

Typical lead time is 2–4 weeks from a confirmed scope and access to a staging copy of your Odoo. A standard build (assigned list, navigation, signature/photo POD, COD collection, live status + GPS sync) sits at the shorter end; native app store publishing, complex multi-stop routing optimisation, or deep third-party TMS integrations push it toward the longer end. We agree a milestone timeline up front — scope and staging, build, UAT, then supervised go-live.

Every build includes a post-launch support and warranty window (agreed in scope) covering bug fixes and compatibility with Odoo point releases within your major version. After that window you can move to a paid support or enhancement retainer for new features, major-version migrations (e.g. 18 → 19), and priority response. Because you receive the source in a Git repo you control, you are never locked in — your own team or any Odoo partner can maintain it.

We build for Odoo 17, 18 and 19, on both Community and Enterprise. The manifest is versioned per your target, and we use only supported ORM, security, QWeb, and JSON-RPC/XML-RPC patterns so the module upgrades cleanly with your Odoo. Tell us your version and edition at scoping and we target it exactly.

Either. If you already dispatch from Inventory (stock.picking) or Sales (sale.order), we wire the driver app to those records so there is one source of truth. If your flow needs it, we add a lightweight delivery.order model with driver assignment, state machine, and COD fields. We recommend the right approach during scoping based on how your operation actually runs.

Each delivery record carries the COD amount due (computed from the linked order). When a rider closes a job they record what was collected and the method (cash / card / partial). An @api.depends computed roll-up totals expected vs collected per driver per shift, and an automated action flags any variance for finance. The signature and photo attached to the record give you a defensible proof if a customer later disputes payment or receipt.

Yes — signatures, photos, and status changes queue on the device when signal drops and sync to Odoo via JSON-RPC once connectivity returns, so a rider in a dead zone never loses a proof of delivery. GPS coordinates are posted with each status change (and optionally on an interval), and dispatch sees live and last-known positions on an Odoo dashboard. We tune update frequency to balance visibility against battery and data use.