When to use this endpoint

Permanently remove a receipt header without checking its relationships.

Authentication and permissions

Authenticate with signed API-key fields or a logged-in CRM session. Session CSRF, account-active and IP restrictions still apply. These handlers add no receipt-specific page, finance, department or record-owner permission check.

Records are scoped to the authenticated tenant. CRM1 displays Goods Received with employer feature bit 262144; CRM2 checks features2.goodsReceivedNotes. Those screen gates are not enforced by these handlers. Mobile receipt routes run separately through the mobile intermediary and have different permission and ownership checks.

Parameters

ParameterTypeRequiredDescription
idIntegerNoDefaults to 0; intval-coerced without positive validation or existence check.

Example request

FM_api('PurchasesIn_delete', ['id'=>'531']);

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.

Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.

Behaviour and edge cases

  • Always returns ok:1 after issuing DELETE, even for zero/missing/nonexistent IDs or write failure. Does not recalculate PO fulfillment or invalidate an explicit cache.
  • The user ID is checked before the query, but there is no receipt-specific permission or confirmation requirement. This is a legacy maintenance route, not a supported reversible cancellation.

Side effects

  • Physically deletes only purchases_in where id matches. No history, tenant deletes entry or stock reversal.

See it in Fieldmotion

CRM1

No production CRM1 caller was found. API-test cleanup uses this route; CRM1 row deletion uses GoodsReceivedNote_delete.

CRM2

No production CRM2 caller was found. Bulk page deletion uses GoodReceived_delete.

Related endpoints