Recover uncertain saves and coordinate edits
Expenses has no documented original-intent/idempotency-key recovery protocol like Charity's financial workflow. A lost response is not proof that nothing committed.
Diagnostic procedure
- Stop issuing further mutations on the same expense.
- Record the exact expense/journal/payment IDs and intended action without private credentials/evidence.
- Reload the register/detail and related journal/payment list through authorised reads.
- Compare actual saved fields, states and counters with the intended change.
- Resolve through the responsible finance/support process before another create, post, cancel or reset.
Examples
| Uncertain action | Check before repeating |
|---|---|
| Add Expense | Search exact User/date/description/amount; inspect duplicates |
| Post expense | Existing journal/payment relationships, actual returned/saved status |
| Record reimbursement | Newest payment rows and recorded-paid/due counters |
| Approve/reject | Saved Approval Status and actor/time/reason |
| Cancel/reset payment | Exact payment state and unchanged/reconciled expense counters |
| Delete draft | Original ID/result before any recreation |
The journal link/count can disappear or show zero after a read error; that is not adequate evidence of no financial activity. Retry the read or ask support to verify the records.
Concurrent work
Expense create/update/status requests do not expose an expected-version contract like Employee editors. The sequential balance check does not demonstrate a complete concurrent-creator/duplicate-payment guarantee. Coordinate one operator per financial action and re-read saved outcomes.
Do not manually increment versions, create token amount changes to reset approval or change status labels to bypass a conflict. Duplicate-number/record checks and all referenced IDs must remain tenant-correct.
Some compound posting operations run inside a service transaction and reject failures, but that does not solve network uncertainty or make a repeated request safe. Browser confirmation prompts are human confirmation, not a durable server reservation or financial idempotency guarantee.