| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Discuss (mail)
• Sales (sale_management) • Invoicing (account) • Purchase (purchase) |
| Community Apps Dependencies | Show |
| Lines of code | 9442 |
| Technical Name |
eh_log_ship_agency |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Discuss (mail)
• Sales (sale_management) • Invoicing (account) • Purchase (purchase) |
| Community Apps Dependencies | Show |
| Lines of code | 9442 |
| Technical Name |
eh_log_ship_agency |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Ship Agency: Port Calls, SOF and DA
Run a vessel port call from ETA to settled disbursement: validated vessel master, gated port-call lifecycle, append-only Statement of Facts, and a Disbursement Account that posts to a sale order.
Why this module
Ship Agency: Port Calls, SOF and DA
The SOF cannot be rewritten
Statement of Facts events are append-only. Once created, the description, time, category and company are immutable, and deletion is blocked. A corrective event is appended instead, so the chronology that backs a laytime dispute stays intact.
State changes go through actions, not the ORM
Port call and Disbursement Account state can only move through the action buttons along an allowed-transition map. A direct write to the state field is rejected, so the lifecycle and its stamped timestamps stay coherent.
Estimate, actual and variance on one account
The Disbursement Account carries proforma estimate lines and actual disbursement lines side by side, computes the variance, and posts the actuals to a draft sale order on close. Lines lock once the account is posted or settled.
Day in the life
One vessel call, ETA to settled
A vessel is due. You open a port call against the vessel master record, which already carries the IMO, flag and dimensions. You mark it arrived, tender the Notice of Readiness, and assign a berth; the berth check rejects the assignment if the vessel draft exceeds berth depth or LOA exceeds the berth maximum. Through the call, every state change stamps its time and drops a line onto the Statement of Facts, and you append manual events (pilot on board, weather suspension, customs inspection) with the actual time they happened. On the money side you issue a proforma from estimate lines, record actuals as charges land, then post the account to a sale order and mark it settled. You print the NOR, SOF and DA PDFs straight from the records.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
The vessel master rejects an invalid IMO number using the Resolution A.1078(28) checksum, so a transposed digit cannot create an unrecoverable record. MMSI must be exactly nine digits.
On berth assignment the call validates vessel draft against berth depth and vessel LOA against berth maximum LOA, and fails the move-to-berthed action with the specific reason rather than silently corrupting the call.
SOF event description, time, category and company are locked after creation and events cannot be deleted; the notes field stays editable for an after-the-fact annotation, and corrections are appended as new events.
Each SOF event carries an Against Laytime flag so weather suspensions and agreed exceptions can be marked as not counting, giving the agent the evidence basis for a laytime argument.
A port call cannot be closed while its Disbursement Account is still open; the account must reach posted or settled first, so a call never closes with unsettled money attached.
Issuing the proforma requires at least one estimate line, and posting requires lines present; once posted or settled, disbursement lines are read-only.
IMO number, berth code per port, and husbandry code are unique per company, and isolation rules scope records per company throughout the suite.
What is inside
Built to do the job, end to end.
- Vessel and berth masters. eh.log.ship.vessel carries IMO, MMSI, call sign, flag, vessel type, gross, net and deadweight tonnage, LOA, beam, draft, and separate registered owner and operator partners. eh.log.ship.berth carries depth, max LOA, terminal operator and customs status (bonded, domestic, free zone) and runs the compatibility check.
- Port call lifecycle and SOF. eh.log.ship.port.call moves expected, arrived, berthed, working, sailed, closed (plus cancelled) with each transition auto-stamping its time and emitting a Statement of Facts event. eh.log.ship.sof.event is the append-only chronology with category and an against-laytime flag. NOR is tendered between arrived and berthed.
- Disbursement Account and husbandry. eh.log.ship.disbursement.account runs draft, proforma, actual, posted, settled with estimate, actual and computed variance, and builds a sale order from the actual lines. eh.log.ship.husbandry.service seeds crew change, spares, provisions, fresh water, garbage, slop, bunker and medical entries, each with a default charge code that propagates onto disbursement lines.
- Documents and tests. Three QWeb PDFs: Notice of Readiness, Statement of Facts and Disbursement Account, all on the shared logistics paper format. The module ships a test suite covering IMO and MMSI validation, berth compatibility, the full port-call and disbursement lifecycles, append-only SOF behaviour, and sale-order posting.
Honest about the edges
What this does not do, so nothing surprises you.
- The module records the laytime evidence (NOR time, the append-only SOF chronology, and a per-event against-laytime flag) but does not compute a laytime statement, demurrage or despatch figures. The numbers are prepared by hand from the SOF.
- Ports are modelled as standard company partners rather than a dedicated port master table, so there is no separate port directory with UN/LOCODE lookup.
- There is no AIS, ETA feed, or external EDI message ingestion. Events are entered by the agent or emitted by state transitions, not synced from an external tracking system.
- The Disbursement Account posts a sale order from actual lines; full accounting (vendor bills for each disbursement, currency revaluation of the DA) is left to the standard Odoo accounting flow.
- Customs status on a berth is an informational classification (bonded, domestic, free zone); there is no customs declaration or HS-code workflow in this module.
- Requires the eh_log_base, eh_log_quotation and eh_log_freight suite modules plus sale_management.
ship agency Odoo, port agency software, port call management, vessel master Odoo, IMO number validation, Statement of Facts SOF, disbursement account DA, proforma disbursement, husbandry services, Notice of Readiness NOR, ship chandlery, bunker coordination, crew change logistics, maritime agency Odoo 19, laytime evidence, berth management, Odoo 19 Community logistics
Please log in to comment on this module