Both callers already hand the provider a major-currency amount before this
call — freight sends invoice.balanceAmount (e.g. 700 for $700), passenger
sends CurrencyService's converted charge amount — with the target currency's
own decimal precision already applied (0dp DJF, 2dp USD/ETB). CAC's
toMajorAmount then divided anything that wasn't DJF by 100 on top of that,
so a USD 700 charge reached the bank as 7.00. This never surfaced because
CAC has only ever been wired for DJF (passenger) until now.
Also scoped the bank's documented 10-100,000 bound to DJF — it's the only
currency the spec states bounds for, so a USD amount outside that DJF-shaped
range is no longer rejected locally; an amount genuinely out of range still
comes back as a bank rejection.
Passenger is unaffected: its CAC currency has always been DJF, and the DJF
branch's behavior (amount unchanged, bounds enforced) is untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CAC Bank's initiate SMSes an OTP before it answers and routinely takes more
than the 10s this client allowed, so every CAC charge came back as a 502
while the bank was still working — and if the bank had answered, the payer
would have been texted a code for an intent the freight side never recorded.
Matches the passenger API, which already budgets 60s and reads the same
PAYMENT_API_HTTP_TIMEOUT_MS override.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The confirm flow settles money on a provider with no webhook, so the two
places it can go wrong are worth pinning: that the OTP is forwarded against
the GATEWAY intent id (not the local projection id), and that a rejected
code leaves the intent open instead of failing the payment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CAC Bank is an OTP debit with no redirect and no webhook: initiate SMSes a
code to the payer's mobile, and the charge only settles when that code is
confirmed. The payment service already spoke it (passenger uses it); the
freight side had the enum values but none of the flow.
API:
- PaymentClientService.confirmOtp forwards the code to
POST /payments/intents/:id/confirm, mapping 400/404 to BadRequest so a
mistyped code stays retryable instead of surfacing as a gateway failure.
- PaymentService.confirmOtp is keyed by the LOCAL intent id (the invoice's
paymentId) rather than the domain reference, so the right invoice settles
when several share a booking. On success billing settles the invoice.
- payInvoice rejects CAC_BANK without payerAccount before calling the
gateway, and no longer runs the demo auto-settle for a COLLECT_OTP intent
(it is not paid until the payer confirms).
- POST /billing/my-invoices/:id/confirm — ownership-checked, and since
warehouse fee invoices are central invoices it covers those too.
Portal:
- useInvoicePayment owns the whole flow (initiate, redirect-or-OTP, confirm)
and replaces the five near-identical pay mutations at the call sites.
- PaymentMethodModal gains the CAC Bank option, the payer mobile field, and
the OTP step. Click-outside is disabled there so a stray click cannot drop
the payer out of a live OTP window.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Lists every wagon allocated to a booking with tare, equated length,
capacity, container and seal numbers, plus footer totals and signature
lines. Issued on cargo acceptance (export) and on allocation before
marshalling (import), so the endpoint rejects bookings with no wagon
allocations. Price per wagon splits the booking amount by allocated
weight, with the last row absorbing rounding so the column sums to the
total. Reuses the existing marshalling document renderer and its
Chromium-less tabular fallback.
When warehouse is selected in standalone return modal, yard and zone
fields are automatically populated from warehouse data (yard from
warehouse.yard or warehouse.code, zone from warehouse.zone). Fields are
read-only/disabled to prevent manual editing.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Add Yard and Zone input fields to standalone return modal. Add table
showing all returned containers with: container number, booking ref,
returned date, facility, yard, condition, status. Table appears at top
of Container Returns page when returns exist.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Add "Record Return" button at top of Container Returns page for
standalone/unboooked returns. Modal accepts container number, return
date, warehouse, condition, handover notes. No booking association
required — supports returns that arrive without clear booking context.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Update labels and comments to reflect that container returns are for
last-mile trucks only: either EDR last-mile or customer self-haul. Same
truck that delivered will return with empty containers. Changed labels
from "EDR Returns" → "EDR Last Mile" and "Customer Returns" →
"Customer Self-Haul".
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Separate page for tracking empty container returns by type: EDR returns
(empty containers from EDR first-mile) or Customer returns (customer
self-haul). Segmented control filter, expandable booking rows showing
containers, modal to record return with warehouse selection. Accessible
via sidebar menu under Import Operations.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Replace manual facility/yard input with warehouse dropdown. Form fetches
available warehouses and auto-populates facility (warehouse name) and yard
(warehouse code) from selection, eliminating manual entry.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
New page for empty container returns: tables show EDR trucks with company
names and return containers. Modal form for processing single or bulk
returns, with fields for facility, yard, condition, return date, and
handover notes. Accessible via sidebar menu under Import Operations.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
