Errore creazione fatture split payment con DDT

[CiroBoxHub]

Se si crea un fattura da un Ordine di vendita per un cliente in regime di Split Payment e c'è un DDT (delivery_note) la fatturazione va in errore

Module

• 16.0: l10n_it_delivery_note

Describe the bug

Se si crea un fattura da un Ordine di vendita per un cliente in regime di Split Payment e c'è un DDT (delivery_note) la fatturazione va in errore

To Reproduce

Allego video
screencast-oca-l10n-italy-16-0-6652a1e7fe26_runboat_odoo-community_org-2024_10_31-17_46_28.webm

Il tutto funziona normalmente se non c'è il DDT o se la posizione fiscale non ha Scissione Pagamenti

[masimassimo]

Il problema non si verifica solamente se c'è un DDT. Dopo aver emesso una fattura in regime di Split Payment senza DDT, provando a modificare la quantità o il prezzo in una riga, Odoo andrà in errore: "Il movimento (Fattura in bozza (* 116908)) non è bilanciato".

[francesco-ooops]

@masimassimo è lo stesso problema segnalato in #4231 o sbaglio?

[masimassimo]

@francesco-ooops si, non avevo visto #4231, ma il problema è lo stesso.

[francesco-ooops]

@masimassimo ok, puoi testare la PR #4233 che dovrebbe risolvere il problema (e verificare con l'autore se ha in programma a breve di applicare le modifiche richieste per arrivare al merge)

[masimassimo]

@francesco-ooops col codice della #4233, continuo ad avere il problema. Ho fatto un test, aggiungendo al context check_move_validity=False, quando la write di account.move chiama la super.
In questo modo, succede che la fattura viene scritta correttamente ed è bilanciata, anche se il sistema diceva il contrario.
Forse, quando Odoo esegue il controllo con la funzione _check_balanced di account.move, la scrittura delle righe non è ancora completa.

[francesco-ooops]

@masimassimo puoi riportare questo commento nella PR specifica così non "dirottiamo" questa issue?

[masimassimo]

@francesco-ooops ok

[CiroBoxHub]

Buongiorno a tutti, quindi se ho compreso il problema è il modulo dello split payment?
la #4233 non risolve quindi ancora il problema?

[francesco-ooops]

Testala Cirú :)

[CiroBoxHub]

Buonasera, ho analizzato di nuovo il codice, riportato alla versione ultima split payment e creato fatture senza la presenza del DDT. Tutto funziona correttamente.
Con il DDT non fattura dando l'errore di scompenso nelle registrazioni. Dal log ho notato un unlink su account.move.line ogni volta che provavo a fatturare. Ho cercato è ho trovato che qui

l10n-italy/l10n_it_delivery_note/models/account_invoice.py

Line 97 in a72c49b

old_lines.unlink()

viene eseguito un unlink e che questa funzione update_delivery_note_lines viene richiamata sia in:

• l10n-italy/l10n_it_delivery_note/models/sale_order.py

  Line 122 in a72c49b

  invoices.update_delivery_note_lines()

  (sale_order)

• l10n-italy/l10n_it_delivery_note/models/stock_delivery_note.py

  Line 744 in a72c49b

  invoices.update_delivery_note_lines()

  
  Mi è bastato commentare le due riga per non far richiamare la funzione da avere la generazione corretta

[CiroBoxHub]

Buonasera, aggiorno l'issue specificando che il funzionamento corretto commentando quanto riportato sopra è dovuto al fatto che in questo modo non viene chiamata la write sulle account.move.line.
Infatti, anche li dove, non facendo un ddt, la fattura con split viene creata correttamente, se si prova a fare delle modifiche questa va in errore.
Reputo che il tutto quindi sia da imputare al modulo dello split payment e alla sua write

[dcorio]

Ciao, è ancora valida questa issue?
Ho fatto un test su un db 16.0 creato da zero e non ho riscontrato il problema.
Vedi immagine.
L'unica differenza è che non ho usato i dati demo. Quindi la fattura era in EUR con l'imposta 22SP creata dal modulo split payment.

[CiroBoxHub]

Ciao Davide, si avevo già fatto anche questo tentativo. Ci sono però due problematiche:

• Se si prova a fare l'esportazione del file xml va in errore perchè l'imposta 22SP è un gruppo di imposte dove c'è la 22sp neg che ha come valore percentuale -22,00 il che fa andare in errore l'esportazione della fattura per la presenza di un valore negativo nel valore aliquota
  
  

• Anche volendo fare una correzione sull'imposta mettendo l'aliquota la 22,00 e mettendo il segno meno invece sulla percentuale di ripartizione della stessa (mentenendo cosi l'effetto il medesimo), la fattura viene esportata ma non è valida ai fini SDI (allego esempio di errore)
  
  

[dcorio]

Ciao Ciro,
grazie per il feedback.

Ma se contabilmente ciò che viene generato usando conti/imposta SP creati dal l10n_it è corretto, allora il problema è solo il modulo out_sp, ovvero il come viene generato il XML il problema. Giusto?

Ovviamente mi rimetto a qualche esperto contabile.
Ciò che viene scritto in contabilità è corretto?
Se si, possiamo rivendere la generazione del XML soltanto, che sicuramente è meno problematica.

[dcorio]

https://github.com/OCA/l10n-italy/blob/16.0/l10n_it_fatturapa_out/wizard/wizard_export_fatturapa.py#L132

qui viene già usato abs per l'importo dell'IVA. Si usasse abs anche per l'aliquota il problema si risolverebbe.

Dando per scontato che tutto il resto sia contabilmente ok ovviamente...

[dcorio]

EDIT: come dice giustamente @CiroBoxHub, nel XML finiscono comunque le due aliquote del gruppo e quindi non va bene

[SirAionTech]

Potrebbe essere duplicata di #4231.