Goods returns
Delete the CRM1 return-note header
/a/GoodsReturnedNote_delete
Delete one return header and call the tenant deletion log, without deleting its lines or restoring stock.
When to use this endpoint
This is CRM1’s goods-return table delete action. It removes the header, not the underlying return transaction’s stock effect.
Authentication and permissions
Authenticate with signed API-key fields or a logged-in CRM session. Session CSRF and account/IP restrictions still apply. These handlers add no goods-return, finance, department, owner or page-role permission check.
Records belong to the authenticated tenant. CRM1 shows this workflow when the employer features bit 262144 is enabled; CRM2 uses features2.goodsReturnedNotes. These are UI gates, not checks performed by these handlers.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
id | Integer | Yes | Positive header ID after intval. |
Example request
FM_api('GoodsReturnedNote_delete', ['id'=>642]);Example response
{"ok":1}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":"missing or invalid parameter: id"} | Missing or non-positive ID. |
{"error":"Return Note does not exist"} | The ID lookup found no header, including a read failure. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- Physically deletes only the goods_returned header; no soft-delete marker or transaction. Existing children and prior catalog deductions remain.
- Both the delete result and Core_logDeletion result are unchecked. A failed delete can still be followed by a deletes entry and ok; an audit failure can follow a successful delete.
- The database call includes goods_returned as an unkeyed extra parameter rather than a cache key; it does not request the intended table-cache invalidation.
Side effects
- Calls Core_logDeletion for the header after DELETE. Unlike mapped deletion, this handler does not write a Core_log field-history event.
- No child cleanup, purchase-order/received-note update, stock restoration or total recalculation.
See it in Fieldmotion
CRM1
pageGoodsReturned configures GoodsReturnedNote_delete for its table delete button.
CRM2
CRM2 uses GoodReturned_delete instead.