Teams moving goods on pallets across Europe live in two systems: Odoo for orders and inventory, and a separate carrier portal where a warehouse operator re-keys the same address, weight, pallet count, and service level by hand for every consignment. That double entry is slow, error-prone, and invisible to Odoo — the delivery order says "shipped" but nobody can see the consignment number, the pallet labels, or where the freight actually is. Odoo's native delivery framework (delivery.carrier, stock.picking, choose_delivery_carrier) gives you a shipping-method field and a price rule, but it has no built-in connector to a palletized freight network, no concept of pallet dimensions and exchange, no carrier label PDF, and no tracking write-back. That is exactly where native Odoo runs out of road.

We build a dedicated shipping integration as a proper Odoo module: a new delivery.carrier provider type wired to the freight network's booking API, with a models.Model service layer that maps a stock.picking (and its stock.move.line and package data) into a valid consignment request — collection and delivery addresses from res.partner, chargeable pallet count and gross weight computed via @api.depends, requested service level, timed and tail-lift options, and hazardous flags. When the operator validates the picking, the module calls the carrier over the API, stores the returned consignment/booking reference on the picking, and pulls back the label(s) and manifest as ir.attachment records ready to print. A scheduled automated action (ir.cron) polls the tracking endpoint and writes status transitions onto the picking, posting a chatter message on the linked sale order so sales and support see delivery progress without leaving Odoo.

Technically the module ships with everything an Odoo review expects: a clean __manifest__.py declaring dependencies on stock and delivery, ORM models with typed fields and compute methods, XML and OWL views extending the delivery and picking forms, a QWeb report for the pallet label and dispatch manifest, ir.model.access.csv plus record rules so warehouse users and managers see only what they should, and encrypted storage of API credentials in ir.config_parameter rather than in plain fields. Booking and tracking calls run through a resilient client with retry and error surfacing, and every carrier response is logged for audit. Because it is built on the standard carrier abstraction, rate shopping, delivery.price.rule pricing, and multi-warehouse routing keep working — we extend Odoo rather than bolt a silo alongside it. It targets Odoo 17.0, 18.0, and 19.0 and works on Community or Enterprise (Enterprise studio/accounting hooks are respected where present). The same JSON-RPC/XML-RPC API surface remains available so external WMS or portal systems can trigger bookings programmatically.

Delivery is build-to-order: after a short scoping call we confirm the exact service levels, label layout, address mapping, and Odoo version in a written scope, then build, test on a staging copy of your database, run UAT with your team, and deploy — typically 2–4 weeks from confirmed scope. You receive the installable source, documentation, and a post-go-live support window. Pricing starts from $299 (indicative, single-company base scope); additional service levels, multi-company or multi-warehouse rollout, deeper carrier options (returns, collections, exchange-pallet reconciliation), and data migration volume increase the quoted scope. We provide a fixed quote after the scoping call — never a blind fixed price before we understand your workflow.