The tick and the money are bound. Marking an instalment paid records a payment for its agreed amount with the chosen method and a reference naming the instalment, and stores the resulting payment id on the schedule row. Un-ticking removes that payment and re-derives the order. Rows ticked before the binding existed are matched by order, amount and the reference this panel wrote.
Also called: mark instalment paid · un-tick a payment · schedule says paid but balance says not
- 1markPaid calls recordPayment and stores the returned payment id
- 2The method is chosen inline in the row rather than behind a dialog
- 3markUnpaid follows paid_payment_id, or falls back to matching reference plus amount
- 4A failure explains itself — 'Nothing left to pay on this order' or how much is actually outstanding
- 5Failure messages render in the error colour, not the success colour
'This used to clear the tick and leave the payment behind, so the schedule said "nothing paid" while the header said $4,833.67 paid and the bar was part-filled. Both were reading real data; the tick and the money simply weren't bound to each other.' On the inline method: 'How it was paid is the field nobody can reconstruct later — three weeks on, "did that cheque clear?" is only answerable if somebody said it was a cheque at the time… a modal for one dropdown is a layer for its own sake.' On tone: 'a failure rendered in the success colour reads as success and gets ignored.'
- A tick that books money it cannot un-book
- Two panels showing different amounts paid
- Payment method lost by the time anyone asks
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →