#6818 / #6846 taught settlements to follow a corrected payment AMOUNT: the -updated handler recomputes pot = amount - allocated and allocates the remainder or releases the excess.
A corrected MATCH field is still invisible. A payment whose match value (e.g. Customer) is corrected publishes a full-row -updated; the recompute sees pot = amount - allocated = 0 and no-ops - so the junction rows keep paying the OLD customer's invoices, and the new customer's open items stay open. The correction that most needs re-allocation is precisely the one the amount-based recompute cannot see.
The -rekeyed event (#6819 / #6845) was built for exactly this shape - a row whose grouping moved, published with the PREVIOUS row's values from both the full-row and the targeted write paths - but SettlementOnPayment.java.template does not bind it (components/template/template-application-events-java/.../events/SettlementOnPayment.java.template).
Fix: bind a third settlement handler on the payment's -rekeyed topic: release every allocation of the re-keyed payment (the existing release walk, in full), then re-run the allocation against the corrected match value. That requires the payment's match FK to be part of the entity's groupingKeys union when it is a settlement match source - today that union covers aggregate keys and rollup via FKs only.
Follow-up to #6846.
#6818 / #6846 taught settlements to follow a corrected payment AMOUNT: the
-updatedhandler recomputespot = amount - allocatedand allocates the remainder or releases the excess.A corrected MATCH field is still invisible. A payment whose match value (e.g. Customer) is corrected publishes a full-row
-updated; the recompute seespot = amount - allocated = 0and no-ops - so the junction rows keep paying the OLD customer's invoices, and the new customer's open items stay open. The correction that most needs re-allocation is precisely the one the amount-based recompute cannot see.The
-rekeyedevent (#6819 / #6845) was built for exactly this shape - a row whose grouping moved, published with the PREVIOUS row's values from both the full-row and the targeted write paths - butSettlementOnPayment.java.templatedoes not bind it (components/template/template-application-events-java/.../events/SettlementOnPayment.java.template).Fix: bind a third settlement handler on the payment's
-rekeyedtopic: release every allocation of the re-keyed payment (the existingreleasewalk, in full), then re-run the allocation against the corrected match value. That requires the payment's match FK to be part of the entity'sgroupingKeysunion when it is a settlement match source - today that union covers aggregate keys and rollupviaFKs only.Follow-up to #6846.