Skip to content

POST,PATCH /oms/customer-pos/form

OMS > oms.inbound-order

What it does

/oms/customer-pos/form accepts POST,PATCH and is declared in app/systems/OMS/inbound-order/api_routes.php:296 as a path.

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

Call chain:

  1. → omsCustomerPoFormMutation() — app/systems/OMS/inbound-order/api_routes.php:56
  2. ↳ omsCustomerPoAssertGenericMutation() — app/systems/OMS/inbound-order/api_routes.php:26
  3. ↳ apiTableMutationNormalize() — app/shared/api/table_mutation_helper.php:6

Who calls it

Called from:

  • public/assets/js/modules/shared/popup.core.js

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

Input

Where Key
query mode

Request bodies must not use TYPE, ACTION or USERNAME as contract fields.

Output

Key
T_CUSTOMER_PO
T_CUSTOMER_PO_ITEM

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

SQL executed

SELECT CPI.ID FROM T_CUSTOMER_PO_ITEM CPI JOIN T_CUSTOMER_PO CP ON CP.UUID = CPI.CUSTOMER_PO_UUID AND CP.CLIENT_ID = CPI.CLIENT_ID AND CP.TYPE_ID IS NULL AND CP.DELETED_AT IS NULL WHERE CPI.CLIENT_ID = ? AND CPI.ID = ? AND CPI.DELETED_AT IS NULL LIMIT 1

Data

No table reference is visible in the owner function body.

Access

  • module-gated on oms.inbound-order, so tenant module access applies

Validation and failure messages

  • Customer PO type and Booking are managed by the Booking workflow.
  • Customer PO OUT REF# fields are managed by the Booking workflow.
  • Customer PO item 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.