A build-to-order Odoo connector that books last-mile shipments from your sales orders using GPS/phone-pin addressing instead of street data — with AWB label sync, live tracking, and COD reconciliation for MENA deliveries. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo connector that books last-mile shipments from your sales orders using GPS/phone-pin addressing instead of street data — with AWB label sync, live tracking, and COD reconciliation for MENA deliveries.
Şimdi ödeme yok. Bu, ekibimize bir teklif talebi gönderir — fiyat ve sonraki adımlarla e-posta ile dönüş yapacağız.
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.
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)
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.
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.
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.
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.
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.
Lisansı ecosire.com adresinden satın alın ve hesap kontrol panelinizden Fetchr / Address-by-GPS Last-Mile Connector for Odoo modülünün ZIP dosyasını indirin.
ZIP'i sunucudaki Odoo özel eklentiler klasörünüze çıkarın (veya Uygulamalar > Odoo.sh / runbot'taki dosyadan yükle yoluyla yükleyin).
Geliştirici Modunu etkinleştirin, Uygulamalar'ı açın, Uygulama Listesini Güncelle'ye tıklayın, Fetchr / Address-by-GPS Last-Mile Connector for Odoo'i arayın ve Yükle'ye basın.
Yeni menüyü açın, ECOSIRE lisans anahtarınızı yapıştırın, tüm harici kimlik bilgilerini (Shopify, Amazon, Stripe vb.) bağlayın ve kaydedin.
Yerleşik bağlantı testini çalıştırın, ilk 10 kaydınızı senkronize edin ve yinelenen cronu planlayın. Herhangi bir sorun olursa desteğe başvurun.
| Kriter | ECOSIRE | Özel Yapı | Rakip | Odoo Yerlisi |
|---|---|---|---|---|
| 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 | |
| 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 | |
| COD reconciliation | Amount-to-collect per shipment + remittance matching view | Build it yourself if scoped | Rarely included, if at all | |
| 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 | |
| Tracking sync | ir.cron polling or webhook, mapped to clear states | Manual unless you build it | Varies, often limited | |
| Support & ownership | Post-go-live support window + full git handover | Tied to whoever built it | Vendor support tiers, shared roadmap | |
| Delivery time | 2–4 weeks from confirmed scope, built for you | Unpredictable, depends on hiring | Instant install but generic fit | |
| Maintainability | Clean manifest, ORM extensions, record-rule security | Quality depends on the individual | Black-box, vendor-controlled |
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.
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.
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.
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.
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.
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.
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.
A build-to-order Odoo connector that books last-mile shipments from your sales orders using GPS/phone-pin addressing instead of street data — with AWB label sync, live tracking, and COD reconciliation for MENA deliveries.