Odoo 19 documentation describes a dispatch management system for companies that organise their own deliveries. It groups transfers into loads, assigns a dock and vehicle, compares weight and volume with available capacity, and helps teams prepare the route on a map.
For an SME or multi-site organisation in Belgium or France, this continuity between Odoo Inventory and Fleet can replace some shared spreadsheets used by warehouse and transport. It does not turn Odoo into an advanced route-optimisation platform: its value starts with dependable product data, addresses and capacities.
What standard Odoo 19 covers
Vehicle categories hold maximum capacity in kilograms and cubic metres. A vehicle model passes its category to the relevant vehicles. A vehicle can act as an internal delivery method, while each loading dock receives its own Odoo location.
On the operation type, the team enables dispatch management and selects available docks. Deliveries are grouped into batches assigned an owner, date, dock and vehicle. Odoo also provides dispatch calendar and route views, along with batch statistics.
Mapbox is required for mapping inside Odoo. Once a batch is in progress, users can see destinations and generate a journey in Google Maps. These tools assist preparation; the documentation does not promise automatic optimisation for traffic, time windows and complex constraints.
The decisive prerequisite: reliable weight, volume and addresses
Odoo can evaluate capacity only when product weight and volume are populated. Teams must decide which logistics unit to measure, how to represent packaging and pallets, and how to handle the difference between theoretical volume and actual space occupied.
Addresses must also be standardised and suitable for geocoding. A correct invoice address is not necessarily a workable delivery instruction: access, time slots, tail-lift requirements, on-site contacts and urban restrictions may require extra fields or a complementary process.
What changes for each team
Warehouse
The dock and batch become shared objects. Operators must distinguish the end of picking, availability at the dock and actual loading. Without explicit statuses and ownership, the new view merely digitises existing ambiguity.
Transport and customer service
Assignment must account for capacity and real availability. Teams need to decide who can change a frozen load, how an urgent delivery is inserted and how a failure returns to Odoo. Customer service needs a meaningful status, not just a technical transfer state.
IT and data
Mapbox requires an access token. Odoo recommends URL restrictions and warns that a secret token cannot be displayed again after creation. Secret permissions, rotation and environment separation belong in the operating procedure.
Underside analysis: separate planning, execution and proof
We recommend three moments. Planning builds the load and reserves a dock and vehicle. Execution confirms what actually departed. Proof records delivery, refusal, damage or return. Odoo 19 mainly strengthens the first two; proof may require extra configuration, a mobile app, signature workflow or carrier integration.
A useful pilot covers one depot, a small fleet and repeatable routes. Measure data completeness, capacity overruns, dock waiting time, changes after load freeze and geocoding failures. This evidence guides the choice between standard Odoo, targeted automation and an external TMS.
When integration is still needed
- Optimisation involving time windows, traffic, skills or driver rules.
- Exchange of orders, labels, statuses and proof with several carriers.
- Capacity calculations involving pallets, stacking, temperature zones or dangerous goods.
- Real-time GPS tracking and dynamic route recalculation.
- A driver portal, advanced proof or detailed returns management.
Odoo can remain the system of record for orders, products, inventory and invoices while a TMS handles optimisation. The architecture must state which system owns each status.
Checklist before the pilot
- Separate own-fleet from outsourced transport.
- Audit weight, volume, logistics units and addresses.
- Configure categories, models and vehicles with consistent capacities.
- Create one location per dock and document assignment.
- Secure Mapbox and separate test from production.
- Test overload, vehicle change, delay, invalid address and return.
- Define statuses understood by warehouse, transport and customer service.
- Measure the pilot before automating.
This work extends Odoo inventory and logistics and Odoo Fleet. In a migration, capacity and address data belong in scope before go-live.
Official sources
Underside helps teams scope and integrate Odoo workflows across orders, warehouse, fleet and invoicing. The aim is to validate data and ownership in a pilot before automating transport.