Saudi and GCC e-commerce sellers who ship with Naqel Express usually run their fulfilment out of two disconnected worlds: orders and inventory live in Odoo, but shipment creation, AWB label generation, rate lookups and COD reconciliation happen on the Naqel portal. Every dispatch means re-keying the consignee address, copying an AWB number back into the sales order, and manually chasing tracking updates. Odoo's native Inventory app ships with a delivery-carrier abstraction (delivery.carrier) and connectors for FedEx/UPS/DHL/bpost, but there is no Naqel provider out of the box — so base_on_rule fixed-price carriers are the ceiling, and none of the real Naqel API (rating, waybill, COD, tracking) is reachable.

ECOSIRE builds a dedicated Naqel Express connector as a proper Odoo module (__manifest__.py declaring dependencies on stock, delivery and sale) that adds a native carrier provider. We extend delivery.carrier with a naqel delivery type and implement the standard hook methods — naqel_rate_shipment, naqel_send_shipping and naqel_cancel_shipment — so Naqel behaves like any first-class carrier inside the delivery workflow. Credentials, account number, origin warehouse mapping and COD toggles are stored on the carrier record (and mirrored to ir.config_parameter where it makes sense), with sandbox/production endpoints switchable per environment. When a picking is validated, the module calls the Naqel REST/SOAP API to create the shipment, writes the returned waybill number back onto stock.picking.carrier_tracking_ref, and stores the label. AWB labels are retrieved from Naqel and either attached as the carrier PDF or rendered through a QWeb report so warehouse staff print directly from the delivery order. Live rates are pulled at quotation and checkout time so the customer sees an accurate Naqel price rather than a flat fee.

On the operations side we model what KSA sellers actually need: COD support with the collected-amount passed to Naqel and a reconciliation view that matches Naqel's remittance back to the originating invoice/order, so finance can see which cash-on-delivery shipments have been settled. Tracking is kept current through a scheduled automated action (ir.cron) that polls Naqel for status changes and posts them to the picking's chatter (with optional customer-facing status on the portal), plus an inbound webhook option where Naqel supports push updates. All new fields are computed or stored with proper @api.depends where derived, and every model is locked down with ir.model.access.csv access rights and record rules so multi-company/multi-warehouse setups stay isolated. Because it is a real module, the same shipment and rate calls are reachable over Odoo's XML-RPC/JSON-RPC API for any external storefront or middleware you run alongside Odoo.

This is a build-to-order engagement, not an instant apps.odoo.com download. After a short scoping call we confirm your Naqel account type, required services (domestic, GCC cross-border, COD, returns), Odoo edition (Community or Enterprise) and target version (17.0, 18.0 or 19.0). We then build against your Naqel sandbox credentials, ship the module to a staging database for UAT, and go live with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope, and you receive the full source and a git repository handover so nothing is a black box.