Fetchr / Address-by-GPS Last-Mile Connector for Odoo

Key Features

Extends `res.partner` with `partner_latitude`/`partner_longitude` and a geolocation-first address model for delivery points without formal street data

Phone-pin capture flow: customer confirms or drops a GPS location via an SMS/WhatsApp link, written back to the contact and the picking

New `delivery.shipment` model (or `stock.picking` extension) linking each confirmed `sale.order` / delivery order to a carrier booking

`Book Shipment` server action that calls the courier REST API and writes the returned AWB number onto the delivery order

AWB label ingestion as `ir.attachment` PDFs, plus an optional branded QWeb manifest report

Live tracking sync via `ir.cron` polling or carrier webhook, mapped to a compute-driven delivery state (booked / picked-up / out-for-delivery / attempted / delivered / RTO)

COD amount-to-collect carried on every shipment with a `@api.depends` computed outstanding-balance field

COD remittance reconciliation view that matches courier settlement reports against collected cash and flags shortfalls

Delivery-slot scheduling: offer and lock time windows that ride along in the booking payload

Carrier credentials and endpoints stored on `delivery.carrier` / a settings model — never hard-coded, environment-switchable (sandbox vs production)

`ir.model.access.csv` plus record rules so warehouse, finance, and manager roles each see only their scope

Retry-safe booking with idempotency handling and logged API failures so a courier timeout never silently drops an order

Optional XML-RPC/JSON-RPC exposure so external storefronts or middleware can trigger bookings and read tracking programmatically

Built and pinned to your exact Odoo minor (`17.0`, `18.0`, or `19.0`), respecting Community vs Enterprise stock/delivery differences

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 Odoo.

Go live + support

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

About this Product

If you sell across the UAE, KSA, Egypt, or the wider MENA region, the hardest part of fulfilment is not picking the goods — it is finding the customer. Millions of delivery points have no formal street address, and the "villa near the mosque, call when you arrive" reality breaks every assumption Odoo's native res.partner model makes. Out of the box, Odoo stores street, street2, city, and zip as free text and hands those strings to a carrier that expects structured addresses. There is no place to capture a GPS pin or a phone-verified location, no shipment-booking call to a Fetchr-style carrier, no AWB lifecycle, and no way to reconcile the cash your COD courier collected on your behalf. Teams end up copy-pasting order data into a courier portal and re-keying tracking numbers back — slow, error-prone, and impossible to audit.

Fetchr / Address-by-GPS Last-Mile Connector closes that gap. ECOSIRE builds a dedicated Odoo module that extends res.partner and stock.picking with geolocation-first delivery addressing: latitude/longitude fields, a phone-pin capture flow (the customer drops or confirms a location via an SMS/WhatsApp link), and a saved-location book so repeat buyers resolve instantly. A new delivery.shipment model (or an extension of stock.picking, depending on your warehouse setup) maps each confirmed Odoo order to a carrier booking. From the delivery order, a Book Shipment action calls the courier's REST API over the standard Odoo requests layer, receives an AWB number, and writes it back onto the picking. Label PDFs come back as ir.attachment records — printable directly, or re-rendered as a QWeb report if you need a branded manifest. Tracking status is polled by an ir.cron automated action (or ingested via the carrier's webhook where available) and mapped onto a clear delivery state so your CS team sees "out for delivery / attempted / delivered / RTO" without leaving Odoo.

Technically, the connector is a proper Odoo app: a clean __manifest__.py declaring dependencies on stock, delivery, and sale; ORM models with @api.depends computed fields for delivery status and COD balances; carrier credentials stored on delivery.carrier (or a dedicated settings model) and never hard-coded; and security enforced through ir.model.access.csv plus record rules so warehouse users, finance, and managers each see only what they should. COD is first-class — each shipment carries the amount to collect, and a reconciliation view matches courier remittance reports against collected cash, flagging shortfalls before they become write-offs. Delivery-slot scheduling lets you offer and lock time windows that ride along with the booking payload. The module is delivered against your Odoo edition, so we respect Community vs Enterprise differences (for example, Studio-generated fields or Enterprise-only stock features) and target your exact minor: 17.0, 18.0, or 19.0.

Because this is build-to-order, you are not downloading a generic zip and hoping it fits. We start with a short scoping call to confirm your carrier, address-capture flow, COD workflow, and Odoo version, then build, test, install, and support the module for you. Typical delivery is 2–4 weeks from confirmed scope, you receive the full source and a git repo handover, and everything is validated on a staging database before it touches production.

What you get

Installable module source code built and pinned to your Odoo version (17.0 / 18.0 / 19.0)

Installation and configuration on your environment, including carrier credentials, sandbox-to-production switchover, and COD settings

Technical documentation: models, fields, API integration points, cron jobs, and security matrix

End-user guide plus a live training session for warehouse, CS, and finance roles

UAT on a staging database with a documented test plan and a rollback plan before production go-live

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

Full git repository handover with commit history and README

Carrier API integration mapping document (fields, endpoints, webhook/polling behavior, error handling)

Who this is for

MENA e-commerce operations lead

Runs fulfilment for an online store shipping across the UAE, KSA, or Egypt where most delivery points have no formal street address. Needs orders to book straight from Odoo to a GPS-based courier and tracking to flow back without portal copy-paste.

Finance / COD reconciliation manager

Owns cash collected on delivery. Needs each shipment to carry its amount-to-collect, and courier remittance reports to reconcile against Odoo so shortfalls and delayed settlements surface immediately instead of at month-end.

Odoo-using retailer scaling last-mile

Already runs sales and inventory in Odoo and is adding or switching to a Fetchr-style carrier. Wants a clean, supported module tied to their exact edition and version — not a brittle in-house script maintained by whoever built it.

Warehouse / dispatch supervisor

Prints labels and hands parcels to couriers daily. Needs one-click AWB booking, printable labels, and clear delivery states inside Odoo so the team never leaves the delivery order screen.

How Fetchr / Address-by-GPS Last-Mile Connector for Odoo Compares

Criterion	ECOSIRE	Custom Build	Competitor	Odoo Native
Addressing model	GPS/phone-pin fields on res.partner + saved-location book, built for informal addresses	Whatever your developer models, quality varies	Assumes structured street/city/zip	Free-text street fields only, no geolocation
Carrier booking	One-click AWB booking against your carrier's real API	Possible but you own the integration	Fixed to the carriers it ships with	No last-mile carrier booking out of the box
COD reconciliation	Amount-to-collect per shipment + remittance matching view	Build it yourself if scoped	Rarely included, if at all	Not available
Odoo version fit	Pinned to your exact 17.0/18.0/19.0 + edition	Depends on the developer's target	Only the versions the vendor maintains	N/A
Tracking sync	ir.cron polling or webhook, mapped to clear states	Manual unless you build it	Varies, often limited	None
Support & ownership	Post-go-live support window + full git handover	Tied to whoever built it	Vendor support tiers, shared roadmap	Community/DIY
Delivery time	2–4 weeks from confirmed scope, built for you	Unpredictable, depends on hiring	Instant install but generic fit	Immediate but no capability
Maintainability	Clean manifest, ORM extensions, record-rule security	Quality depends on the individual	Black-box, vendor-controlled	Core only

Frequently Asked Questions about Fetchr / Address-by-GPS Last-Mile Connector for Odoo

How long does delivery take, and what happens first?

This is a build-to-order module, not an instant download. After a short scoping call to confirm your carrier, address-capture flow, COD workflow, and Odoo version, typical delivery is 2–4 weeks from confirmed scope. Complex multi-carrier or heavy custom-reconciliation requirements may extend that, and we tell you before you commit.

Which Odoo versions and editions do you support?

We build and pin the module to your exact minor — 17.0, 18.0, or 19.0 — on either Community or Enterprise. We account for edition differences (for example, Enterprise-only stock features or Studio-generated fields) during scoping so the module fits your database rather than a generic assumption.

Do you integrate with my specific courier, or only Fetchr?

Fetchr-style GPS/phone-pin addressing is the pattern, but the connector is built against your carrier's actual REST API. During scoping we map their endpoints for booking, AWB, tracking, and COD remittance. If your courier has no public API, we tell you what is and isn't possible before any build starts.

How does COD reconciliation work?

Each shipment carries its amount-to-collect. A reconciliation view matches the courier's remittance/settlement report against the cash Odoo expected, computes outstanding balances with `@api.depends` fields, and flags shortfalls or delayed settlements so finance catches gaps early instead of at month-end.

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

You get a post-go-live support window for defect fixes and configuration adjustments, plus the full source and git repo so nothing is locked to us. Version upgrades (for example, moving to a newer Odoo release) or new carrier features are scoped as follow-on work — we can quote a support/maintenance retainer if you want ongoing coverage.

Will this break my Odoo upgrades?

We build a proper module with a clean `__manifest__.py`, ORM extensions instead of core patches, and security via `ir.model.access.csv` and record rules — the maintainable pattern. Odoo major upgrades still require a migration pass, which we scope separately, but nothing here forks or hacks core.

Can external systems trigger bookings or read tracking?

Yes. Beyond the in-Odoo actions, we can expose booking and tracking through Odoo's XML-RPC/JSON-RPC API so a headless storefront or middleware layer can create shipments and pull status programmatically. That surface is scoped to your integration needs during the call.