Requisition orders
Delete a requisition header
/a/RequisitionOrder_delete
Retain a requisition header as deleted while leaving its lines and allocations in place.
When to use this endpoint
Use after confirming the intended order. The default status gate allows Open/Approved headers; force is a legacy bypass, not a normal integration option.
Authentication and permissions
Authenticate with signed API-key fields or a logged-in CRM session. API keys use their owner’s tenant; session dispatch applies CSRF checks. Office requisition access requires View and Delete on Requisition Order or Requisition Orders. A visible UI control is not sufficient authorization.
Tenant and TeamAccess/legacy department scope apply to headers and to the parent of each line. Deleted parents hide their lines. Scoped users can see their own unlinked requisitions; the legacy department-only rule retains its target-based visibility. There is no additional Requisition feature-entitlement check.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
id | Positive integer | Yes | Existing, non-deleted requisition ID in the authenticated tenant and your record scope. |
force | Integer-compatible | No | Legacy control: any nonzero integer bypasses the status<2 deletion gate. Callers should not use it to bypass business review. |
Example request
$result = FM_api('RequisitionOrder_delete', [
'id' => '1042',
]);Example response
{
"ok": 1
}Errors and unusual responses
| Response | Condition |
|---|---|
{"error":"not logged in"} | No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs. |
{"error":"missing or invalid parameter: id"} | id absent or converted value<1. |
{"error":"requisition order does not exist"} | Header missing/already deleted. |
{"error":"Requisition Order not of a valid status for deletion"} | status>=2 without force. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- Looks up a non-deleted header first. Status<2 is allowed; Processed/Received/Cancelled normally fail. force bypasses only this status gate.
- Sets deleted/ddate, not last_edited, and does not cascade to entries, order_containers, Job stock or Purchase Orders. Entry readers exclude lines whose parent is deleted.
- The primary write acknowledgement is unchecked. It can proceed to notification/audit even if that write fails; the steps have no enclosing transaction.
Side effects
- Retains the header with deleted=1 and epoch ddate; invalidates header cache. CRM2 session sends update/time notifications; Core_logDeletion records the retained header in the tenant deletion audit.
See it in Fieldmotion
CRM1
On CRM1 Requisition Orders delete an unprocessed order; filter for RequisitionOrder_delete.
CRM2
In CRM2 Requisition Orders use Delete; filter for RequisitionOrder_delete. UI permissions/status warnings are separate from the handler.
Related endpoints
RequisitionOrder_restore— Restore a retained header through Admin-console identity.RequisitionOrderEntry_deleteData— Remove selected mapped lines independently.