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.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
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.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 Fetchr / Address-by-GPS Last-Mile Connector for Odoo 模块 ZIP。
将 ZIP 解压到服务器上的 Odoo 自定义插件文件夹中(或通过“应用程序”>“从 Odoo.sh / runbot 上的文件安装”上传)。
激活开发者模式,打开应用程序,单击更新应用程序列表,搜索 Fetchr / Address-by-GPS Last-Mile Connector for Odoo,然后按安装。
打开新菜单,粘贴您的 ECOSIRE 许可证密钥,连接任何外部凭据(Shopify、Amazon、Stripe 等),然后保存。
运行内置连接测试,同步前 10 条记录,并安排定期 cron。如果出现任何问题,请联系支持人员。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| 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.