Why it exists

Before this, knowing which shipments were stuck meant opening CargoWise one shipment at a time. The dashboard answers four questions that used to get asked by hand every day:

• Risk zone. Shipments already delivered that haven't reached "completed." The clock starts at actual delivery and the target is 6 days; yellow up to 5 days late, red after that.
• Ready for financial close, blocked by an overdue invoice. The central panel: shipments that could already close on the books and can't because they're carrying an overdue receivable or payable. It's the money that's stuck, with a name and a day count attached.
• On hold. Shipments held for operational or billing reasons, sorted oldest to newest — the oldest one is the most expensive.
• Performance by operator. Funnel, age of work in progress, days between delivery and invoicing, and portfolio health per person.

This is also where data gets written back: every shipment accepts notes with an author and a history, and there's a switch that freezes the risk zone's count during month-end close — it turns itself off on the 1st, so no one has to remember.

Where the data comes from

The dashboard consumes four read webhooks — shipments, receivables, payables, and transport bookings — and two write endpoints, for notes and for the billing pause. The join between invoices and shipments happens in the browser with a Map keyed by job number, not in SQL: that keeps the webhook contract flat and stable for every dashboard that consumes it.

There's an enrichment step that isn't cosmetic: when a movement is booked through a transport booking, CargoWise leaves the shipment's actual dates empty. The dashboard fills them in from the linked booking, and without that a ground shipment already delivered would show up as "not delivered."

The committed delivery date comes back empty for 100% of the table: it simply doesn't exist in the ERP. That's why the target is measured against the actual delivery plus six days instead of a made-up promise.

Build decisions

• The three action tables ignore filters on purpose. Risk, overdue receivables, and holds always show the full universe: if filtering by operator could hide a critical shipment, the dashboard would stop doing the job it's opened for.
• Never two currencies on the same axis. One entity bills in dollars and the other in pesos; adding them produces a number that means nothing. It's a design-system rule, not a judgment call left to whoever builds the dashboard.
• Bookings with no parent shipment come in as their own rows. Since Jul-2026, domestic ground moves are created directly as bookings to save on transaction fees and never become a shipment; without this rule, that work was invisible.
• Every addition sits behind a switch. Flipping a flag to false reverts to the previous behavior without touching anything else.
• No framework, no npm. The sources live split by dashboard and a build.py assembles them into a self-contained HTML file that gets deployed to the internal portal.

What's different in this demo

It's the same file that runs in production: not a single line of logic was touched. The only thing that changes is where the data comes from — fetch is intercepted and answered the way the webhook would, with a deterministic generator. The filters, the calculations, and the loading states are the real ones; the generator deliberately reproduces even the quirks of the real feed.

• The brand, clients, amounts, and operators are all made up.
• The natural-language query panel answers with a local engine over that fake data, not a model. Its demo PIN is announced on the screen itself.
• Exporting to Excel is disabled: the viewer doesn't grant the page download permission.