If you ship with J&T Express across Southeast Asia, China or MENA, your team is almost certainly living in two systems at once: Odoo for the sale order and delivery, and the J&T merchant portal or a spreadsheet for the actual booking, waybill and COD figures. Every parcel gets keyed twice, tracking numbers are copy-pasted back by hand, and COD amounts collected by the courier never quite reconcile against what Odoo invoiced. Odoo's native stock.picking and the built-in delivery carrier framework give you a carrier_id and a manual tracking-reference field, but there is no J&T API call behind the "Send to Shipper" button — the native flow stops exactly where the real integration needs to begin.

ECOSIRE builds a dedicated J&T Express connector that plugs into that native delivery layer and does the rest. We add a J&T delivery.carrier provider type so a shipping method resolves against J&T's serviceability and rating rules, then implement the send_shipping() and cancel_shipment() hooks to call the J&T Express API directly from the picking. When a warehouse user validates a delivery, the connector creates the J&T order, writes the airway bill number back onto stock.picking.carrier_tracking_ref, and pulls a print-ready label. API credentials (customer code, API key, HMAC/private-key request signing) live in an encrypted settings model backed by ir.config_parameter — never hardcoded — with separate sandbox and production endpoints so we can UAT safely before go-live.

Technically, the connector is a proper Odoo addon: a clean __manifest__.py declaring delivery and stock_delivery dependencies, new models extending models.Model for J&T configuration, shipment logs and COD reconciliation lines, compute fields with @api.depends for landed cost and COD variance, and QWeb reports for the AWB label and a shipping manifest. Access is locked down through ir.model.access.csv plus record rules so only shipping and finance roles touch courier data. Tracking sync runs on a scheduled automated action (ir.cron) that polls the J&T tracking endpoint and posts status changes to the delivery's chatter; where J&T supports push callbacks we expose a signed controller endpoint instead of polling. COD amounts are mapped from the sale order total onto the booking payload and, on remittance, matched back so finance sees a clean collected-vs-expected line. The same connector is exposed to your other automations through Odoo's XML-RPC/JSON-RPC API, so an external OMS or marketplace bridge can trigger a J&T booking without touching the UI.

Because this is build-to-order, nothing ships as a blind download. We start with a short scoping call to confirm your J&T account type, regions, COD workflow and whether you are on Odoo 17.0, 18.0 or 19.0 (Community or Enterprise — the connector targets Community APIs so it runs on both). We then build against your J&T sandbox credentials, hand you a staging environment for UAT, and only after you sign off do we install to production with a rollback plan. Typical delivery is one working week from confirmed scope, and you receive the full source, documentation and a post-go-live support window.