Fieldmotion API Getting started

Purchase orders

Remove one legacy order line

POST /a/PurchaseOrderEntry_delete

Remove one saved line and refresh its parent’s stored totals.

When to use this endpoint

Use the CRM1 line Delete action for an explicit line ID. This removes the row immediately; it is not a stock receipt reversal.

Authentication and permissions

Authenticate with signed API-key fields or a logged-in CRM session. Session requests use dispatcher CSRF protection when configured. API keys use their owner’s permissions.

Requires explicit View on Purchase Order or Purchase Orders, plus Edit on either page. Non-administrators with legacy Purchase Orders visibility disabled (crm_access bit 256) are denied.

Explicit line IDs are checked against their active, visible parent orders. A supplied po_id must match the line’s owner. These are tenant-local record IDs, not displayed order numbers.

Parameters

ParameterTypeRequiredDescription
idPositive integer or digit stringYesExisting local line ID; its parent must be active and visible.

Example request

$result = FM_api('PurchaseOrderEntry_delete', ['id'=>'2081']);

Example response

{
  "ok": 1
}

Errors and unusual responses

ResponseCondition
{"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"}Page/action rights or the legacy visibility setting deny access.
{"error": "purchase order does not exist"}An explicit parent/header ID is absent, deleted or outside the caller’s scope.
{"error":"Cannot change stock quantities or identity on an allocated or received Purchase Order"}The change would invalidate existing allocations or receipts; the transaction rolls back.

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 Purchase Order View/Edit; header Delete is not required for a line. The existing active scoped parent is locked before the line is removed.
  • Recalculates parent totals plus carriage, touches its timestamp/cache, records detailed line history and resets approval when necessary. Unallocated initial availability is reconciled to the surviving lines.
  • A line removal that changes identity/quantity on an allocated or received order is rejected and rolled back. It is not an inventory or receipt reversal. Existing physical line-row removal remains unchanged; this fix does not alter deletion lifecycles.
  • Supplier, carriage and changed line data clear approval and require approval again. Exact no-op saves retain approval. Non-administrators with crm_access bit 8192 cannot make financial changes to approved orders.

Side effects

  • Writes use the tenant-owner lock and a transaction or caller savepoint. A rejected operation rolls back its local writes and checked history. Earlier separate API requests remain committed.
  • Edit events, notifications and form follow-ups run after the owning commit. A saved/no-replay warning identifies committed data with a failed follow-up; inspect the saved state rather than repeating creation or sending.
  • Removes the explicit line, reconciles compatible availability and commits checked parent/history changes; queues the edit event.

See it in Fieldmotion

CRM1

In CRM1 Purchase Order details, delete a line and inspect PurchaseOrderEntry_delete.

CRM2

CRM2’s spreadsheet replacement uses the different filter-based PurchaseOrderEntry_deleteData route. The mobile app goes through m/www’s separate PurchaseOrder_save/OrdersM workflow; its validation and ownership rules do not establish this office endpoint’s contract.

Related endpoints