Requisition orders
Approve a requisition
/a/RequisitionOrder_approve
Set approval metadata and Approved status on an existing requisition.
When to use this endpoint
Save pending edits first. CRM2 offers approval on Open orders and then exposes Purchase Order creation, but those UI state restrictions are not all enforced by this handler.
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.
Disable RO Approve is enforced server-side unless the actor is a client administrator or has the wildcard all permission. No requisition monetary approval ceiling is evaluated.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
id | Positive integer | Yes | Existing, non-deleted requisition ID in the authenticated tenant and your record scope. |
Example request
$result = FM_api('RequisitionOrder_approve', [
'id' => '1042',
]);Example response
{"ok":1}An exact no-op header setter may include warning:"No Change.". Committed follow-up failures include saved=1 and a warning; inspect saved state before retrying.
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. |
{"error":"Only Open requisitions can be approved"} | The existing status is neither Open nor the Approved no-op. |
{"error":"Requisition approval is disabled for your role"} | The role disables approval without an administrator/wildcard exemption. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- Requires an existing Open requisition and stamps status=1, date_approved and approved_by from the actor/server. Repeating approval on Approved is a no-op and preserves the original stamp. Processed, Received and Cancelled cannot be reset to Approved.
- Disable RO Approve is enforced server-side. There is no monetary limit calculation and no Purchase Order/supplier split created by approval. Ordinary later edits preserve approval.
- When features2.workflow is enabled, the eligible transition is queued atomically with approval, totals and audit.
- 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
- Checked header/totals/history writes with last_edited and deferred notifications/mentions/cache invalidation. Delivery remains separate from line totals; ordinary edits retain approval.
See it in Fieldmotion
CRM1
On CRM1 Requisition details, choose Approve and confirm; filter for RequisitionOrder_approve.
CRM2
On CRM2 Requisition details, choose Approve. The UI saves its layout first, calls RequisitionOrder_approve, hides Approve and exposes Create Purchase Order.
Related endpoints
RequisitionOrder_get— Read approval metadata.RequisitionOrder_updateData— Save pending mapped fields first.