Freight forwarders live in the gap between a customer booking and a settled shipment: a house of email threads, spreadsheets, carrier portals, and a general ledger that only ever hears about the shipment weeks later. Odoo out of the box handles the accounting and the contacts beautifully, but it has no native concept of a shipment file, a house or master bill of lading, container and cargo lines, or the many-legged buy/sell margin a forwarder has to prove per job. Teams end up bolting freight onto Sales Orders and Projects, then reconciling the money by hand — which is exactly where revenue leaks and audit trails go dark.

ECOSIRE builds a dedicated freight forwarding application as a proper Odoo module (__manifest__.py declaring the module, its dependencies, data files, and security). At its heart is a freight.shipment model (models.Model) that ties together the transport mode (sea FCL/LCL, air, road), a booking reference, the origin/destination ports or airports, the routing legs, and the parties — shipper, consignee, notify, carrier, and agent — as Many2one links into res.partner. Cargo is modeled as One2many container and package lines carrying weight, volume, and chargeable-weight fields, with @api.depends compute methods that roll dimensions up to the shipment and derive volumetric weight so operators never re-key a number. A freight.charge line model captures each cost and revenue item (freight, THC, customs, documentation, insurance) with cost and sell amounts, so per-shipment and per-customer margin is a stored, reportable figure rather than a monthly guess.

The build wires that data into the parts of Odoo you already use. Charge lines generate customer invoices and vendor bills through the standard account.move flow, so finance keeps its chart of accounts, taxes, and reconciliation untouched. A status pipeline (quotation, booked, in-transit, arrived, delivered, closed) is driven by an explicit state field with server-side transitions, and QWeb report templates produce branded shipping documents — booking confirmations, cargo manifests, and arrival notices — as PDFs. We add OWL/XML views (list, form, kanban by status, and a calendar of ETD/ETA), automated actions and activity reminders for milestone deadlines, and — where you need it — integration to carrier or rate-source systems over Odoo's XML-RPC/JSON-RPC API. Access is locked down with ir.model.access.csv plus record rules so operators, the finance team, and outside agents each see only what they should, and everything is multi-company aware if you run several branches. The module targets Odoo 17.0, 18.0, and 19.0, and works on Community or Enterprise (Enterprise-only features such as the accounting follow-ups or studio-style extensions are used only where your edition provides them).

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call, map your shipment lifecycle, charge structure, and document set, then build against a written specification, demonstrate on a staging database, run UAT with your team, and deploy with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); additional transport modes, multi-company or multi-branch rollout, carrier/rate integrations, localized customs or e-invoicing requirements, and historical data migration volume increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise invoice.