- Added support for container hazardous-cargo surcharge (HAZARDOUS billed PER_CONTAINER) in the rule engine.
- Introduced new method in to calculate and apply container hazard charges based on booking details.
- Updated to handle per-container hazard rates, ensuring they are scoped by trade direction and lane.
- Enhanced tests to cover scenarios for container hazard rates, including validation for required fields and conflict checks.
- Created a migration to update existing rates and enforce new constraints for container hazard rates in the database.
An inspection report mirrored its outcome onto the inventory item but
never touched the item's status, and the loading paths gated on status
alone. Cargo that passed, reached READY_FOR_LOADING and was then
re-inspected as FAILED kept that status and loaded anyway.
Gate loading on the inspection outcome. load() is the single choke point
every loading path runs through, including loadItemsOntoTrain, so the
check sits there: nothing but PASSED travels, and the message names the
outcome so the operator knows what to fix.
A failed or under-review re-inspection also pulls the cargo back out of
the ready queue. load() refuses it either way, but leaving it READY_FOR_*
would keep it on the loading and pickup lists as though nothing had
happened.
Reversing a held inspection now needs a reason. Passing cargo whose
current inspection is FAILED or NEEDS_REVIEW is rejected without remarks,
so the record says why cargo that was deliberately held may now travel.
A first-time pass is unaffected.
Mark Selected as Inspected skips failed and under-review items instead of
clearing them. Overturning a failure is a deliberate, reasoned act, never
a side effect of ticking a row in a list; those items are reported back
with a reason telling the operator to re-inspect them individually.
Verified: freight-api type-check passes; 15 warehouse suites pass
(90 tests, 12 of them new).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Marking a received item inspected advanced only the rows the operator
ticked. A booking's cargo spans one inventory row per container, and a
multi-truck arrival files a GRN batch per truck, so a six-container
booking stayed half-inspected and never reached Ready To Load.
Widen the selection to every still-inspectable row of the same booking
before inspecting. Each row is then passed and advanced exactly as
before — EXPORT to READY_FOR_LOADING, IMPORT to READY_FOR_PICKUP — so
the whole booking moves together.
The rows the operator actually ticked lead the response, and are kept
even when ineligible so their skip reason still surfaces rather than
being dropped silently. Rows already PASSED, rows in a status that
cannot be inspected, and rows belonging to another booking are left
alone. Ad-hoc inventory with no booking expands to itself.
Also show yards by name in the receive and received queues. They
selected yards.code, so the route column read KALITY, the internal code
for the yard everyone calls GMP / Gelan Multipurpose Port.
Verified: freight-api type-check passes; both new SQL statements
EXPLAIN-validated against the dev database; 14 warehouse suites pass
(78 tests, 5 of them new).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The receive drawer captured one truck per arrival, so a customer whose
containers came on three trucks had to be received three times over.
Stage trucks instead. "Add another truck" validates the form exactly as a
single-truck receive does, files the truck with its own plate, driver and
containers, and clears the form for the next one. The staged trucks are
listed above the form with their boxes, each removable, and the arrival is
received in one operation.
Containers already staged on an earlier truck drop out of the picker, so
the same box cannot be sent twice.
Receiving with a part-filled form and trucks already staged is treated as
the operator still typing rather than a finished arrival: it asks them to
finish or clear the truck instead of silently dropping what they entered.
An untouched form receives just the staged trucks.
With no trucks staged the drawer sends the original truckEntrance and
containerNumbers fields, so a single-truck arrival takes exactly the path
it did before.
Verified: backoffice type-check reports 982 errors both with and without
this change (all pre-existing, none in the touched files); 13 warehouse
API suites pass (73 tests).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`findAll` selected `r.*` in raw SQL. `dataSource.query` bypasses the entity
mapping, so rows came back under their database names — `container_numbers`,
`submitted_at`, `quoted_total_amount` — while both clients read camelCase.
Every field on the row was undefined; the backoffice queue crashed on
`containerNumbers.join(", ")` and took the page down through the error
boundary.
Alias each column explicitly, the way `plannedReturns()` below it already
does, and cast the two numeric columns with `::float8` — raw SQL skips the
entity's numeric->Number transformer, which would otherwise hand the clients
strings. Type the result as `EmptyReturnRequestRow` so the signature matches
what the projection actually selects rather than claiming absent fields.
Guard the three `containerNumbers.join(...)` call sites too, so one odd row
cannot white-screen the queue again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A customer's containers routinely arrive together on several trucks, but
bulk receive accepted one truck per operation: a single truckEntrance and
a flat containerNumbers list capped at two boxes. Receiving a six-container
arrival meant six separate operations.
Model the arrival as a list of trucks instead. Each entry carries its own
truckEntrance, its own containers and, optionally, its own bookingIds,
defaulting to the operation's. The receive loop iterates trucks, so every
per-truck invariant is preserved rather than pooled: the physical capacity
check (one 40ft or up to two 20ft), the container-to-plate assignment
check, the GRN batch number and the capacity assertions all still apply
per truck.
Callers sending the existing truckEntrance and containerNumbers fields
collapse to a one-element list and behave exactly as before.
Reject a container listed on more than one truck up front. The per-booking
check only catches this once a unit is marked received, so a duplicate
would otherwise surface from whichever truck happened to be processed
second and read as a duplicate gate entry rather than a data-entry slip.
Verified: freight-api type-check passes; all 13 warehouse suites pass
(73 tests).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operators know the yards by name, not by the internal code: the yard coded
KALITY is universally called GMP / Gelan Multipurpose Port (Indode), so
rendering the code alongside the name read as two different places.
Show the name alone in route creation, the yard desks modal and the
booking route card, falling back to the code only when a yard has no
name. The code is unchanged in the data and remains searchable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Implemented method in to allow customers to request an extension for expired contracts.
- Added component in for users to initiate extension requests.
- Updated to include logic for handling extension requests for expired contracts.
- Enhanced to display extension request options and status.
- Created migration to add and columns to the contracts table.
- Added unit tests for contract extension request and handling in .
- Defined DTOs for request and extension in .
- Updated types in to include new fields related to contract extensions.
- Added TrainCrewAssignment module with controller and service for managing crew assignments.
- Integrated TrainCrewAssignmentService into TrainSchedulingService to ensure crew readiness before train dispatch.
- Updated TrainScheduling module to include TrainCrewModule for dependency injection.
- Introduced new permissions for assigning train crew in freight permissions registry.
- Enhanced front-end ScheduleCrewPage to allow assignment of crew members to train schedules, including validation and UI for adding/removing drivers and support crew.
- Created trainCrewAssignment.service to handle API interactions for crew assignments.
- Introduced ScheduleCrewPage for assigning train crew to schedules.
- Updated routing in App.tsx to include crew assignment path.
- Enhanced TrainScheduleV2ListPage with a button to navigate to crew assignment.
- Added new chart components and styles for improved wagon performance reporting.
- Refactored existing styles and components for better visual feedback and usability.
