Fieldmotion API Getting started

Purchase orders

Clear the supplier invoice marker

POST /a/PurchaseOrder_deleteInvoiceDetails

Remove the invoice-received metadata from a Purchase Order.

When to use this endpoint

Use the supplier-invoice dialog’s remove action to clear its indicator. This is not deleting a sales Invoice, receipt, purchase order or payment.

Authentication and permissions

Authenticate with signed API-key fields or a logged-in CRM session. Session requests use dispatcher CSRF protection when configured.

Requires explicit View on Purchase Order or Purchase Orders. Writes also require the matching Edit permission; clearing invoice details requires Delete. A non-administrator blocked by the legacy Purchase Orders visibility flag (crm_access bit 256) is denied. API keys use their owner’s permissions.

The primary order is checked against the current tenant and Purchase Order record scope. Configured TeamAccess follows permitted linked Contracts, Customers, Jobs, Quotes and Departments; the legacy department filter follows direct Customer/Quote/customer-Job links. An inaccessible or missing order returns purchase order does not exist.

Parameters

ParameterTypeRequiredDescription
idInteger-compatibleYesPositive local Purchase Order ID/digit string; not the displayed po_num. Missing, malformed or inaccessible IDs fail.

Example request

$result = FM_api('PurchaseOrder_deleteInvoiceDetails', [
	'id'=>'1042',
]);

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": "no purchase order ID provided"}id is absent/null; zero is not rejected by this presence check.
{"error": "permission denied"}The required page/action or legacy visibility setting denies access.
{"error": "purchase order does not exist"}The primary order is missing or outside the caller’s permitted scope.

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 the Delete action as well as View. Sets invoice_received to SQL NULL; the old details remain in changed-row history.
  • Already-null is an idempotent no-op. A missing/inaccessible order is an error. This does not delete an order, sales Invoice, receipt or payment.

Side effects

  • Header writes lock the existing order and tenant owner, check persistence and record history in the same transaction. Errors roll back the header and audit; a true no-op returns {ok:1,warning:"no change needed"} without a new event/history entry. Cache invalidation and edit-event follow-ups run after the owning transaction commits; an event exception returns saved=1 and a no-replay warning.
  • A changed header emits PurchaseOrder_edit after commit; configured account listeners may perform integration work. No order email/PDF is sent directly by this route.

See it in Fieldmotion

CRM1

In CRM1 Purchase Orders, remove the supplier-invoice indicator/details. Watch PurchaseOrder_deleteInvoiceDetails.

CRM2

In CRM2 Purchase Orders, open the supplier-invoice dialog and choose Delete. CRM2 checks its delete UI permission; this handler adds no equivalent page permission.

Related endpoints