Repository navigation
T3469 FIX last payment computation - #288
Conversation
ecino
commented
Oct 1, 2026
ecino
commented
- In some cases the last payment was not set when it was not coming from a banking statement (online payments for instance).
- In some cases the last payment was not set when it was not coming from a banking statement (online payments for instance).
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if st_lines: | ||
| payment_dates.extend(st_lines.mapped("date")) | ||
| else: | ||
| payment_dates.extend(payment_lines.mapped("date")) |
There was a problem hiding this comment.
When a statement-backed payment and a later online payment fully reconcile one invoice, this branch finds the statement and excludes the online payment date. The invoice can therefore retain the earlier date as last_payment. The monthly thank-you summary filters by that field, so it can place the invoice in the wrong month. Apply the fallback separately to payments without a statement. This needs to be fixed before merging.
Artifacts
Mixed-payment compute reproduction script
- The authored script executes each revision's compute method against the same mocked reconciliation group, making the date-selection comparison reproducible.
Parent compute result with mixed payments
- Running the parent method from /home/user/repo returned the later online date with exit code 0, establishing the comparison result.
Candidate compute result with mixed payments
- Running the candidate method from /home/user/repo returned the earlier statement date and failed the assertion with exit code 1, showing the regression in the mocked case.
Authored last-payment execution script
- The authored script loads and executes the payment computation from a selected Git revision against synthetic records, making the limited check reproducible.
Repository payment-test search
- A repository search located the payment helper and last-payment implementation but no Python assertion of the computed field, confirming the coverage gap.
Parent-revision payment computation
- Executing the parent revision against four synthetic payment cases produced three dates that did not match expectations.
PR candidate payment computation
- Executing the candidate against the same four synthetic cases produced all expected dates, without establishing Odoo integration behavior.
| if st_lines: | ||
| payment_dates.extend(st_lines.mapped("date")) | ||
| else: | ||
| payment_dates.extend(payment_lines.mapped("date")) |
There was a problem hiding this comment.
The existing payment helper creates a payment but never asserts last_payment. There are no tests for the new no-statement fallback or an invoice with mixed payments, so another date-selection error could reach invoice reporting without a test catching it. This is a non-blocking test-coverage concern.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Artifacts
Mixed-payment compute reproduction script
- The authored script executes each revision's compute method against the same mocked reconciliation group, making the date-selection comparison reproducible.
Parent compute result with mixed payments
- Running the parent method from /home/user/repo returned the later online date with exit code 0, establishing the comparison result.
Candidate compute result with mixed payments
- Running the candidate method from /home/user/repo returned the earlier statement date and failed the assertion with exit code 1, showing the regression in the mocked case.
Authored last-payment execution script
- The authored script loads and executes the payment computation from a selected Git revision against synthetic records, making the limited check reproducible.
Repository payment-test search
- A repository search located the payment helper and last-payment implementation but no Python assertion of the computed field, confirming the coverage gap.
Parent-revision payment computation
- Executing the parent revision against four synthetic payment cases produced three dates that did not match expectations.
PR candidate payment computation
- Executing the candidate against the same four synthetic cases produced all expected dates, without establishing Odoo integration behavior.
1 participant
