POST reverse_allocation

Reverse an Active Allocation Run. Creates a reversal run and cancels the original.

Endpoint

POST /api/method/konsol.api.reverse_allocation

Authentication: Required (Frappe session cookie)

Parameters

Parameter	Type	Required	Description
name	string	Yes	Document name of the Allocation Run to reverse

What Happens

1. Validates the run is in "Active" status
2. Creates a new Allocation Run with reversal_of pointing to the original
3. Submits the reversal (becomes Active, synced to ClickHouse)
4. Cancels the original (status set to "Reversed", synced to ClickHouse)

Response

{
  "message": {
    "original": "ARUN-2025-P6-0001",
    "reversal": "ARUN-2025-P6-0002",
    "status": "Reversed"
  }
}

Example

curl -X POST http://localhost:8069/api/method/konsol.api.reverse_allocation \
  -H "Content-Type: application/json" \
  -b "cookies.txt" \
  -d '{"name": "ARUN-2025-P6-0001"}'

Error Responses

Wrong status

{
  "exc_type": "ValidationError",
  "_server_messages": "[\"Cannot reverse: current status is 'Reversed', expected 'Active'\"]"
}

dbt Impact

After reversal:

• Original run: status = 'Reversed'
• Reversal run: status = 'Active'
• gold_allocation_results applies no status filter — it does not itself include or exclude runs based on Active/Reversed.
• gold_allocation_audit_trail joins each run's status against gold_allocation_results and negates the allocated amount for Reversed runs (status = 'Reversed' ⇒ -allocated_amount), so both the original and the reversal appear there and net to zero for full traceability.

See also: run_allocation, allocation_history