proposal: settlement allocation recomputes when the payment changes - #44
Open
delchev wants to merge 1 commit into
Open
proposal: settlement allocation recomputes when the payment changes#44delchev wants to merge 1 commit into
delchev wants to merge 1 commit into
Conversation
A payment booked for the wrong amount and corrected the next day, or entered from a statement and completed later, was never re-allocated: the spec described only the payment's arrival. Proposes allocation over the payment's whole life, as a recompute of its unallocated balance - including releasing the excess when the payment is reduced.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
proposals/0021-settlement-recompute-on-correction.md. Adds no keys - it specifies when an existing construct runs.The problem. The spec describes the payment's arrival, and every implementation reads
settlementsas "allocate once, on create". Payments are not final when they are typed in: one booked for the wrong amount is corrected the next day, one entered from a bank statement is completed once the counter-party is identified, one captured as a draft is amended before anyone treats it as money. The allocation then describes an amount the payment no longer carries, and the invoice's settled figure with it - silently, until a receivables reconciliation months later. The opposite correction is worse: a payment reduced after allocation leaves invoices drawing more from it than it holds.The proposal. Allocation runs on the payment's create and on every subsequent change, and each run is a recompute of the payment's unallocated balance rather than an addition to it: a positive balance is spread as on create, a zero balance changes nothing, a negative balance releases the excess (newest allocation first, reducing rather than removing the last one it touches) so the allocations sum to the payment again. Releases are ordinary junction writes, so the invoice
paidroll-up follows them down.Because every run recomputes, a re-delivered or replayed change converges instead of double-allocating.
Implementation: eclipse-dirigible/dirigible#6818. Site page: IntentFile/intentfile.github.io#35.
🤖 Generated with Claude Code