Requisition orders
Update one mapped requisition field
/a/RequisitionOrder_updateField
Apply one mapped field value to selected requisition headers.
When to use this endpoint
Use mapped CRM2 names and native picker objects. For a full header plus spreadsheet replacement, use Layout_setValue; independent API calls are independent transactions.
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 Edit 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 / ids | Positive integer / native or JSON ID array | Yes | Creation ignores supplied IDs. UpdateData accepts one existing header; updateField accepts an explicit nonempty selection and saves the whole batch atomically. |
field | Stored writable map name | Yes | For example description, deliveryDate, status, metaLink, target or deliveryNet. Unknown, timestamp, derived total, approval, deletion and PO-link fields are rejected. |
val | Value of the selected field | Yes | Required explicitly, including for status. Use the same value validation as mapped create/update; null is skipped by the field parser and is not a clear command. |
Example request
$result = FM_api('RequisitionOrder_updateField', [
'id' => '1042',
'field' => 'description',
'val' => 'Updated materials request',
]);Example response
{"ok":1}Creation returns {ok:1,id:
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":"permission denied"} | Required office page/action access is absent. |
{"error":"requisition order does not exist"} | The header is missing, deleted or outside the caller’s scope. |
{"error":"Processed requisitions are read-only"} | A material/header edit targets status 2. |
{"error":"Unable to save requisition. Check the saved state before retrying."} | A checked database/audit operation failed; verify saved state before replaying an uncertain request. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- Aliases expand to typed stored fields; native pickers are required, and JSON strings are accepted only for the documented JSON fields/ID lists. Unknown fields are ignored. Omitted/null values do not clear fields; send blank text or the explicit No Link pair where supported.
- New headers are Open with zero line totals, server creation/edit timestamps and the actor as default requester. New IDs are not idempotent. Processed header material edits are rejected. Other ordinary edits preserve existing approval.
- Approval uses the same validation as RequisitionOrder_approve. Eligible status transitions enqueue Workflow in the same transaction when features2.workflow is enabled. The helper does not start a second status transaction that can commit earlier header edits.
- The header/line changes, aggregate totals and audit are checked in one tenant transaction. A failed write or audit rolls back the operation. Existing caller transactions use savepoints; the caller owns final commit. No request key deduplicates creation.
- Follow-up notifications and mentions run after the owning commit. If a follow-up fails after persistence, the response includes saved=1 and a warning; read the saved object before retrying and do not replay creation.
Side effects
- Writes checked header changes, line-only aggregates, last_edited and history. Status transitions may queue Workflow; notifications, mentions and cache invalidation follow the owning commit. Layout_setValue atomically includes all replacement lines and allocation reconciliation.
See it in Fieldmotion
CRM1
No direct caller was found in CRM1 source. Its requisition screen uses the legacy header/line endpoints instead.
CRM2
CRM2 list widgets can derive this generic RequisitionOrder_updateField route; current Requisition table columns derive RequisitionOrder_updateData for inline saves. No literal direct RequisitionOrder_updateField caller was found; filter for Layout_setValue/mapped updates instead.
Related endpoints
RequisitionOrder_updateData— Update several mapped values.RequisitionOrder_approve— Use explicit approval stamping.