Pagamenti in sospeso per fatture in inversione contabile

[SirTakobi]

Module

l10n_it_reverse_charge.

Describe the bug

Dopo aver validato una fattura fornitore in reverse charge, ci sono pagamenti in sospeso.
Nell'esempio riportato qui sotto, sono i due movimenti sui conti Outstanding Payments/Receipts.

To Reproduce

Affected versions:

• 14.0: [FIX] Pagamenti in sospeso per fatture in inversione contabile #3287
• 16.0: [16.0] [MIG] l10n_it_reverse_charge #3566

Steps to reproduce the behavior:

1. Configurare il modulo l10n_it_reverse_charge
2. Creare una fattura con reverse charge e confermarla:
   La fattura confermata è BILL/2023/04/0001, i movimenti contabili creati sono:
   

Expected behavior
Non ci devono essere pagamenti in sospeso (outstanding payments e outstanding receipts) dopo aver confermato la fattura in reverse charge.

Additional context
Il comportamento attuale crea un nuovo pagamento ogni volta che c'è da riconciliare una delle registrazioni generate, questo comportamento è stato introdotto dalla migrazione del modulo in 5e65a06.
Nella PR di migrazione #2310 non ho trovato motivazioni per questo cambio di comportamento, può essere che sia passato inosservato.

Prima della migrazione, le registrazioni venivano riconciliate tra loro con l'ausilio di una registrazione aggiuntiva pagamento.

[TheMule71]

Riapro, da portare dopo migrazione, perché il test del commit
f309def
sono rossi e non è immediata la fix.
https://github.com/OCA/l10n-italy/actions/runs/5484282149/jobs/9991629746?pr=3300#step:8:416

[SirTakobi]

Riapro, da portare dopo migrazione, perché il test del commit f309def sono rossi e non è immediata la fix.

Non sarebbero da correggere nella migrazione?

[TheMule71]

Certo, se la cosa fosse semplice.

[SirTakobi]

Certo, se la cosa fosse semplice.

Fosse una nuova funzionalità sarei più d'accordo, ma questo è un errore: non portarlo vuol dire causare una regressione nel modulo alla versione 16.
A quanto ho capito dai funzionali tra l'altro non è nemmeno così un errore da poco.

Ma forse avere subito un modulo bacato è meglio che avere un modulo funzionante settimana prossima?
Uovo oggi o gallina domani?

[eLBati]

#3300 (comment)

[MarcoCalcagni]

@eLBati

nel fare i test sul nostro db ho :

posizione fiscale

inversione contabile :

registro :

con questa configurazione le registrazioni sono in regola.

[SirAionTech]

Questa si può chiudere perché alla fine #3287 è stata inclusa nella migrazione del modulo alla 16.0 (#3566).