Skip to content

POST /tms/transloads/stuck-dip-cleanup

TMS > tms.transload

What it does

/tms/transloads/stuck-dip-cleanup accepts POST and is declared in app/systems/TMS/transload/api_routes.php:429 as a path.

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

Call chain:

  1. → tmsTransloadApiStuckDipCleanup() — app/systems/TMS/transload/planning_command_api_helper.php:467
  2. ↳ yard_find_entity_location() — app/systems/YMS/yard-move/location_state_helper.php:550

Who calls it

Called from:

  • frontend/pages/system/TMS/transload/inbound-planning.php

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
FORCE_DIP_CLEANUP
PLANNER_ID
REFERENCE_NUMBER
TRANSLOAD_ID

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

SQL executed

SELECT t.ID AS TRANSLOAD_ID,

SELECT LOCATION_CODE FROM T_YARD_LOCATION

Data

Tables reached from the owner function:

  • T_LOADING_PLANNER
  • T_TRANSLOAD

Access

  • module-gated on tms.transload, so tenant module access applies

Validation and failure messages

  • REL # / Load # is required.
  • No active DIP planner was found for this REL # / Load #.
  • This load is not in a DIP cleanup status.
  • Trailer is still in yard location
  • Planner row was not found.

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.