You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
VS match picks the first invoice when two open docs share the same VS and amount #7
If two open invoices end up with the same VS (e.g. INV/2026/00001 and FAX/2026/00001 from two sale journals) and the same amount, a bank line with that VS and no known payer gets reconciled to the first one. The comment in _l10n_cssk_find_vs_counterpart_amls says it should only accept a single matching document, but the loop returns the first hit. Leaving it for a person when more than one fits would be safer. Happy to share a small test.
Confirmed and fixed in 792f382 (l10n_cssk_payment_symbols). No test needed from your side, thanks; the case is now in the suite.
_l10n_cssk_find_vs_counterpart_amls now collects every document whose open amount equals the transaction, and accepts the match only when there is exactly one. Two that both fit (your INV/2026/00001 and FAX/2026/00001 case) leave the line for a person. A known payer, or an amount only one of them has, still settles it.
The matcher is shared by the OCA and Enterprise reconciliation bridges, so the fix covers both. Tests are in l10n_cssk_payment_symbols (the matcher directly) and l10n_cssk_payment_symbols_oca (end to end through OCA's auto-reconcile).
Activity
sync: l10n_cssk@8949f588
Rad0van commentedon Oct 24, 2026
Confirmed and fixed in 792f382 (
l10n_cssk_payment_symbols). No test needed from your side, thanks; the case is now in the suite._l10n_cssk_find_vs_counterpart_amlsnow collects every document whose open amount equals the transaction, and accepts the match only when there is exactly one. Two that both fit (your INV/2026/00001 and FAX/2026/00001 case) leave the line for a person. A known payer, or an amount only one of them has, still settles it.The matcher is shared by the OCA and Enterprise reconciliation bridges, so the fix covers both. Tests are in
l10n_cssk_payment_symbols(the matcher directly) andl10n_cssk_payment_symbols_oca(end to end through OCA's auto-reconcile).sync: l10n_cssk@8949f588