return-bookings¶

YMS > yms.container-tracking

What it does¶

/yms/containers/return-bookings accepts PATCH and is declared in app/systems/YMS/container-tracking/api_routes.php:2073 as a path.

The route handler delegates to ymsContainerApiUpdateReturnBookings(). That function is the owner of this behaviour; the route entry is only dispatch.

Call chain:

→ ymsContainerApiUpdateReturnBookings() — app/systems/YMS/container-tracking/api_routes.php:288
↳ ymsContainerApiNormalizeReturnBookingUpdates() — app/systems/YMS/container-tracking/api_routes.php:44

Who calls it¶

Called from:

public/assets/js/modules/shared/kj-table-options-export.js

A caller is the strongest available evidence of the intended use.

Input¶

No named input key is visible in the handler or its owner function. The endpoint either takes no parameters or reads them through a shared helper in app/shared/api/.

Output¶

Key
`OUT_REF_ACTION`
`RETURN_BOOKING_ID`
`T_EQUIPMENT`
`UPDATE`

Success is { "data": …, "requestId": "…" }. Failure is { "error": { "code", "message" }, "requestId": "…" }.

Data¶

No table reference is visible in the owner function body.

Access¶

module-gated on yms.container-tracking, so tenant module access applies

Validation and failure messages¶

Return booking updates are required.
Invalid return booking update.
Duplicate equipment update.

These strings come from the owner function and are the messages a client can receive. They are also the cheapest way to tell a rejected request from a broken one.

PATCH /yms/containers/return-bookings¶