If you've ever tried to bolt real-time logistics operations onto an ERP that wasn't originally built for it, you know the pain. We recently did this with Odoo for a port terminal client, and the EDI integration piece taught us more than the rest of the project combined.
The problem
Ports don't run on REST APIs and webhooks. They run on decades-old EDI message standards:
- BAPLIE — vessel bay plan (which container sits where on the ship)
- CODECO — container gate-in/gate-out events
- COPRAR — container discharge/loading orders from carriers
- CUSRES — customs response messages
None of these are things Odoo speaks natively. Most "Odoo for ports" modules you'll find on the app store handle basic inventory extensions but stop short of real EDI parsing.
What we actually built
- A custom EDI parser layer (EDIFACT format) that translates incoming messages into Odoo-native records (stock moves, purchase orders, customs holds)
- A queue-based ingestion system so high-volume message bursts (common during vessel arrivals) don't lock up the Odoo ORM
- A reconciliation layer to catch mismatches between EDI-reported container status and what's physically scanned in the yard
Where Odoo's architecture helped
Odoo's ORM and modular app structure made it realistic to extend the inventory model (stock.location) to represent yard blocks/tiers/rows as a nested location tree — which gave us reasonably accurate yard occupancy tracking without building a separate yard management system from scratch.
Where it didn't
PostgreSQL under Odoo's ORM is not built for millisecond-response, high-frequency operations like real-time crane dispatch decisions. For that, you still need a dedicated TOS (Terminal Operating System) — Odoo sits next to it as the ERP/finance layer, not as a replacement.
Full writeup
We documented the full architecture, the EDI mapping approach, and the checklist we now use before recommending Odoo for any port/terminal client here:
https://theintechgroup.com/blog/odoo-for-port-management/
Top comments (0)