Two payments of the same invoice in one statement import make the whole import fail #9

Activity

1. Rad0van

   closed this as completedon Oct 24, 2026
2. Rad0van

   added a commit that references this issue on Oct 24, 2026

   sync: l10n_cssk@8949f588

   ...

   This issue will close once commit 792f382 is merged into the '19.0' branch.

   792f382
3. Rad0van commented on Oct 24, 2026

   

   Rad0van

   on Oct 24, 2026

   Member

   More actions

   Confirmed and fixed in 792f382 (l10n_cssk_payment_symbols_oca).

   As you found: OCA's create() proposes a counterpart for every line of the batch and only then reconciles them, so both lines were given the invoice's full residual. The second reconcile_bank_line() raised already reconciled, and since that happens inside create(), the whole import was rolled back, on every re-pull.

   The VS pass now tracks what earlier lines of the same import will reconcile, and a line proposes only what's left open:

   • 100 + 100 against a 100 invoice: the first pays it, the second is left for a person (it isn't handed to OCA's own matcher either, which would propose the same item again);
   • 60 + 40: both reconcile, the invoice is paid;
   • 60 + 100: the first reconciles, the second is proposed for the remaining 40 and waits for a person.

   Only a line that will actually be reconciled claims anything. An overpayment that is merely proposed takes nothing from an exact payment later in the same file. The import itself never fails on this any more.

   This is the OCA bridge. The Enterprise bridge (l10n_cssk_payment_symbols_ee) reconciles line by line and re-searches open items each time, so it shouldn't have this problem, but I haven't run it.
4. Rad0van

   added a commit that references this issue on Oct 25, 2026

   sync: l10n_cssk@8949f588

   ...

   This issue will close once commit 8bbd3fc is merged into the '19.0' branch.

   8bbd3fc