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 one working week 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.