Ocean freight, run end to end. 

Active rounds and voyages, fleet utilisation and available TEU, overbooked-voyage alerts, revenue trend and revenue by service, bookings by status, top agents and top routes. Every widget responds to round, voyage, service, agent and date filters.

Each widget is backed by a server-side MongoDB aggregation, and the pipelines run in parallel rather than in sequence. Dashboard stats and permission lookups sit in an in-memory TTL cache, so the page stays fast as bookings grow.

Revenue only counts Layer 2 Final Loading bookings, the containers actually on the ship. The headline number is one finance can sign off, not an optimistic estimate.

A route editor for each service: country, city, port, terminal and the local agent for every port call, in sailing order. Vessels, agents, locations, container types and expense types are managed as master data.

Port calls are stored as an ordered array on the service and validated against the location master (country → city → port → terminal). Each consecutive pair of ports becomes a route leg, which is what voyages are generated from.

When the route is data and not free text, the system can create voyages, resolve imported rows and compute capacity per leg. A typo in a port name can no longer break a report.

Each round shows its vessel, service, dates and status, with every voyage on it: POL → POD, ETD/ETA, actual ATD/ATA and status (scheduled, departed, in transit, arrived). Extra voyages can be added manually where the real schedule differs.

Creating a round walks the service's route legs and inserts one voyage per leg, marked Auto. Manual voyages are flagged separately so they're never overwritten. Voyages are grouped by round across the app.

Operators used to type every voyage by hand, for every rotation. Generating them from the route removes that work and keeps codes and legs consistent from round to round.

Estimated bookings hold commercial reservations. Operational bookings track each container: type, status, freight rate, shipper and consignee, VGM and hazardous cargo. Tabs show discharged and remaining cargo, and discharge lists can be exported per port.

Both layers share one booking model with a layer flag. Every report, the capacity engine and every export read the same two layers. Once a booking is on the Final Loading manifest it becomes read-only, so nothing can change after the ship sails.

Mixing estimates with real cargo was the main reason the old numbers never matched. Separating the layers, and locking what's final, makes revenue and capacity trustworthy.

Upload an Excel file per agent and round as Booking, Final Loading or Discharge. A preview shows which rows will be created (green) and which will update existing containers (orange) before anything is saved. A template download is included.

Each row resolves its own voyage from its POL/POD against the round's voyages, so one file can cover several voyages. Rows are matched by container number within the round and agent: existing ones update, new ones are created, invalid rows are skipped, and nothing is ever cancelled.

The import is idempotent, so the same file can be uploaded twice without creating duplicates. Matching on container number fits how agents actually work, and the preview catches problems before they reach the database.

For any round: peak onboard, total loaded TEU, vessel capacity and average utilisation. A cargo-flow timeline shows loaded and discharged TEU at each port call, colour-coded against capacity, with a detailed card for every voyage.

Container sizes convert to TEU and a running onboard total is computed in sailing order: previous onboard, minus discharged, plus loaded, from Layer 1 and Layer 2. Pending bookings can be included to see a what-if.

Overbooking a leg is expensive, and finding out at the port is worse. Computing it from live bookings shows the risk while there's still time to act.

Seven reports: voyage profitability, voyage performance, round capacity, bookings, revenue, expenses, and booking revenue grouped by agent, commodity, POL/POD, container type and rate. Bulk export covers 13 modules to Excel or ZIP with date filters.

Reports are aggregation pipelines over the same booking layers as the dashboard, rendered as widgets. Exports stream through ExcelJS, PDF documents come from jsPDF, and multi-module exports are zipped on the server.

Every number in a report traces back to the same bookings and expenses the dashboard uses, so there's one version of the truth whether you read it on screen or in a spreadsheet.

Custom roles such as Viewer, Tracking Officer, Finance Officer and Operations Manager, plus a protected SuperAdmin. A matrix sets View, Read, Create, Update, Delete, Override and Hidden for each module, with quick-set rows. Users get roles, and an immutable audit log records every action.

Permissions are checked by middleware on every one of the 25 API route files, not only in the UI. Hidden removes a module from the navigation entirely, and Override gates the actions that break normal rules. Permission lookups are cached.

Finance data and operational edits carry real money. Enforcing access on the API means a hidden button is never the only thing standing between a user and a write.