A build-to-order Odoo integration that connects your delivery workflow to a European palletized freight distribution network, automating consignment booking, label and manifest generation, and shipment tracking straight from the sales and inventory flow. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $299.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo integration that connects your delivery workflow to a European palletized freight distribution network, automating consignment booking, label and manifest generation, and shipment tracking straight from the sales and inventory flow. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19.
No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.
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.
New `delivery.carrier` provider type wired to the freight network's booking API, so palletized freight is a first-class shipping method with rate shopping and `delivery.price.rule` pricing intact
Consignment booking triggered on `stock.picking` validation — no re-keying into a carrier portal
Chargeable pallet count and gross/volumetric weight computed via `@api.depends` from `stock.move.line` and package records
Carrier label(s) and dispatch manifest pulled back as `ir.attachment` PDFs, printable directly from the delivery order
QWeb report for pallet labels and a consolidated dispatch manifest matching carrier layout requirements
Consignment/booking reference and tracking URL written back onto the picking and shown on the linked sale order
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.
Runs the dispatch bay and is tired of operators double-keying consignments into a separate carrier portal. Needs one-click booking from the delivery order, printed pallet labels, and a manifest — with zero address re-entry and fewer keying errors on weights and pallet counts.
Owns the Odoo instance and wants the freight carrier to live inside the standard `delivery.carrier` framework, not as a bolt-on silo. Cares about clean security rules, upgrade-safe code across 17/18/19, and audit logging of every carrier call.
Fields "where is my delivery?" calls and needs the consignment reference, tracking link, and live status visible on the sale order and in chatter — without logging into a carrier website or asking the warehouse.
Reconciles freight cost against shipments and wants booked service levels, pallet counts, and references captured against each delivery order so carrier invoices can be checked against what Odoo actually dispatched.
Buy the license on ecosire.com and download the Palletized Freight Network Shipping Integration module ZIP from your account dashboard.
Extract the ZIP into your Odoo custom addons folder on the server (or upload via Apps > Install from file on Odoo.sh / runbot).
Activate Developer Mode, open Apps, click Update Apps List, search for Palletized Freight Network Shipping Integration, and press Install.
Open the new menu, paste your ECOSIRE license key, connect any external credentials (Shopify, Amazon, Stripe, etc.), and save.
Run the built-in connection test, sync your first 10 records, and schedule the recurring cron. Contact support if anything fails.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Carrier connection | Native delivery.carrier provider wired to the freight network API | Built from scratch against the carrier's API by your dev | Generic connector, often not tuned to your service levels | |
| Pallet/weight logic | Chargeable pallet count and weight computed via @api.depends from packages | Whatever your team codes and maintains | Basic weight field; pallet nuance often missing | |
| Labels & manifest | Carrier labels + QWeb dispatch manifest as printable attachments | Must build PDF/label handling yourself | Sometimes label support, layout may not match carrier | |
| Tracking write-back | Scheduled ir.cron polls status, updates picking + sale order chatter | Cron and status mapping built by you | Varies; often one-way booking only | |
| Security | ir.model.access.csv + record rules, encrypted credentials in config params | Depends on developer discipline | Baseline ACLs; credential handling varies | |
| Version & edition fit | Built for your exact 17/18/19, Community or Enterprise | Tied to whoever builds and maintains it | Fixed release; may lag your Odoo version | |
| Support & ownership | Post-go-live support window + full git repo handover | You own all maintenance and bug fixes | Vendor support tiers; source rarely handed over | |
| Delivery model | Build-to-order, scoped and tested on staging, 2–4 weeks | Open-ended internal project timeline | Instant install but generic fit |
No. This is a build-to-order integration. ECOSIRE builds it for your specific carrier account, service levels, and Odoo version after a scoping call, then installs and supports it. There is no instant download — you receive a module built and tested for your environment.
Typically 2–4 weeks from confirmed scope. After the scoping call we agree a written scope, then build, test on a staging copy of your database, run UAT with your team, and deploy. Wider rollouts (multiple service levels, multi-company, or heavy data migration) can extend that, and we tell you the realistic timeline in the fixed quote.
Pricing starts from $299 as an indicative, single-company base-scope figure. Drivers such as additional service levels, multi-warehouse or multi-company rollout, returns/collections/exchange-pallet handling, and data migration volume increase the scope. After a short scoping call we give you a fixed quote — we never commit to a blind fixed price before understanding your workflow.
We support Odoo 17.0, 18.0, and 19.0 on both Community and Enterprise. The module is built on the standard `delivery.carrier`/`stock.picking` framework, so it coexists with existing shipping methods and respects Enterprise features where present. We build against your exact version so upgrades stay clean.
Every build includes a post-go-live support window for defect fixes and configuration questions. Beyond that, we offer ongoing support and can adapt the integration when the carrier changes its API or you add service levels. You also receive the git repository, so your own team can maintain it if you prefer.
Yes. Because it registers as a native `delivery.carrier` provider, your `delivery.price.rule` pricing, rate shopping, and multi-warehouse routing continue to function. We map per-warehouse or per-company carrier accounts during scoping so each dispatch point books against the correct account.
Yes. The booking service is exposed through Odoo's JSON-RPC/XML-RPC API, so an external WMS, e-commerce platform, or portal can create consignments programmatically. Bookings are also triggered automatically when a picking is validated, and tracking updates flow back via a scheduled action.
A build-to-order Odoo integration that connects your delivery workflow to a European palletized freight distribution network, automating consignment booking, label and manifest generation, and shipment tracking straight from the sales and inventory flow. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19.