Importazione fatture con più decimali dell'ordinario, se modificate, non quadrano con l'einvoice

[sergiocorato]

Module

l10n_it_fatturapa_in

Describe the bug

La fattura con più decimali viene importata correttamente, ma se si modifica il sistema ricalcola i valori con i decimali standard, portando a dei risultati incoerenti con la fattura ricevuta.

To Reproduce

Affected versions:

• 12.0: [ADD][12.0] New module to add ability to modify e-invoice vendor #2874
• 14.0: sì
• 16.0: sì, dopo [FIX] Precisione decimale non usata durante l'importazione della fattura elettronica #4446

Steps to reproduce the behavior:

1. importare una fattura modificando i decimali di importazione nella maschera pop-up che si apre all'importazione dell'einvoice
2. entrare nella fattura creata e modificare un dato che faccia scattare il ricalcolo dei valori (esempio data contabile)

Expected behavior
La fattura, anche se modificata, rispetta comunque i valori originali della fattura ricevuta.

Additional context
v. 12.0:

v. 14.0:

[FrancescoBallerini]

Ciao Sergio, riguardo la 14.0 se possibile aggiungerei una piccola descrizione del problema, non so se c'è modo di proporre un commit direttamente sul post, intanto lo scrivo qui:

• 14.0

'Quando premuto, il pulsante 'esporta e-fattura' riporta i decimali a 2 cifre a prescindere dalla decimal precision impostata sulla currency'

Mi da l'idea che si possa risolvere aggiungendo il riferimento alla currency nella tree view definita qui definita sul form, o qualche problema simile https://github.com/OCA/l10n-italy/blob/14.0/l10n_it_fatturapa_out/views/attachment_view.xml#L87

avevo avuto un problema simile ma in un contesto leggermente diverso e so che i fields.Monetary possono dare comportamenti 'strani' sulle tree view, potrei fare qualche prova. Ultima cosa, ritieni sensato aprire una issue correlata, essendo un problema diverso da quello dell'importazione o continuo a scrivere qui per aggiornamenti?

[sergiocorato]

@FrancescoBallerini in che senso esporta e-fattura? Questa issue è relativa all'importazione.

[FrancescoBallerini]

@FrancescoBallerini in che senso esporta e-fattura? Questa issue è relativa all'importazione.

Perché per testare l'importazione sono partito esportando una fattura da Odoo (non ne avevo sotto mano con più di 2 decimali), e mi sono accorto che già in fase di esportazione mi resetta a 2 i decimali. Quelli settati con decimal.precision, tipo i fields.float quindi ad es. product price, mi tiene i decimali corretti, mentre per i campi legati alla precisione impostata sulla valuta, tipo imposte, totale ordine etc, nonostante esporto a 6 decimali me li riporta a 2 già in esportazione.

Me ne sono accorto cercando di esportare una fattura per poi reimportarla in un DB con meno decimali, però si non è direttamente correlato.. se mi confermi che è un comportamento inaspettato appena riesco apro un'altra issue in cui descrivo bene il problema.

[sergiocorato]

Eviterei di incasinare la verifica, puoi semplicemente provare a caricare uno dei file di test caricati nella PR.

[FrancescoBallerini]

@sergiocorato Stavo dando un'occhiata in giro e mi sono accorto di questi controlli che sembrano però annullare la scelta della precisione effettuata sul wizard, anche se credo sia voluto.

l10n-italy/l10n_it_fatturapa_in/wizard/wizard_import_fatturapa.py

Lines 1683 to 1691 in 98a9cc8

	if price_precision and different_price_precisions:
	self._restore_original_precision(
	price_precision, original_price_precision)
	if qty_precision and different_qty_precisions:
	self._restore_original_precision(
	qty_precision, original_qty_precision)
	if discount_precision and different_discount_precisions:
	self._restore_original_precision(
	discount_precision, original_discount_precision)

Togliendo queste righe di codice, la scelta operata da wizard va a modificare direttamente la precisione decimale nel modello decimal.accuracy, a quel punto è possibile calcolare/ricalcolare correttamente i valori che però devono comunque rispettare il numero massimo di decimali riportato nella fattura, altrimenti si verificano comunque imprecisioni nel calcolo.

Non mi è molto chiaro il motivo del controllo e di _restore_original_precision(), a meno che l'obiettivo non sia quello di calcolare gli importi corretti con la precisione decimale aumentata e poi rimetterla com'era prima, il problema è che nel momento in cui viene rimessa come prima, gli importi vengono ricalcolati con quella precisione.

Non so bene come funzionino i calcoli su account.move ma direi che bisognerebbe effettuare il ricalcolo con la precisione aumentata e poi troncare i valori invece di arrotondarli.. qualcosa del genere?

[sergiocorato]

@sergiocorato Stavo dando un'occhiata in giro e mi sono accorto di questi controlli che sembrano però annullare la scelta della precisione effettuata sul wizard, anche se credo sia voluto.

l10n-italy/l10n_it_fatturapa_in/wizard/wizard_import_fatturapa.py

Lines 1683 to 1691 in 98a9cc8

	if price_precision and different_price_precisions:
	self._restore_original_precision(
	price_precision, original_price_precision)
	if qty_precision and different_qty_precisions:
	self._restore_original_precision(
	qty_precision, original_qty_precision)
	if discount_precision and different_discount_precisions:
	self._restore_original_precision(
	discount_precision, original_discount_precision)

Togliendo queste righe di codice, la scelta operata da wizard va a modificare direttamente la precisione decimale nel modello decimal.accuracy, a quel punto è possibile calcolare/ricalcolare correttamente i valori che però devono comunque rispettare il numero massimo di decimali riportato nella fattura, altrimenti si verificano comunque imprecisioni nel calcolo.

Non mi è molto chiaro il motivo del controllo e di _restore_original_precision(), a meno che l'obiettivo non sia quello di calcolare gli importi corretti con la precisione decimale aumentata e poi rimetterla com'era prima, il problema è che nel momento in cui viene rimessa come prima, gli importi vengono ricalcolati con quella precisione.

Non so bene come funzionino i calcoli su account.move ma direi che bisognerebbe effettuare il ricalcolo con la precisione aumentata e poi troncare i valori invece di arrotondarli.. qualcosa del genere?

È esatto, la logica di questo wizard esistente è di andare a modificare provvisoriamente la precisione decimale per ovviare al problema. Il che comporta però che appena si prova a modificare la fattura per un qualsiasi motivo, il ricalcolo viene fatto con una precisione inferiore e quindi la fattura risulta errata.

Questo modulo va in pratica ad evitare l'intervento dell'utente (che dovrebbe con il wizard sopra 'sapere' a priori quanti decimali servono per ogni fattura) in modo da non dover tener traccia manualmente di queste variabili. Nell'ultima versione ho aggiunto un campo nella configurazione della contabilità per cui è possibile definire questo comportamento in maniera fissa. Il calcolo viene fatto a partire dai valori nelle righe della fattura elettronica, salvati tali e quali sono nel file xml, con la precisione massima definita nel file di configurazione dell'xml.

[sergiocorato]

(ultima versione che caricherò a breve ;) )

[FrancescoBallerini]

@sergiocorato Fantastico! Almeno so che l'idea del problema l'ho azzeccata, già che ci sono ti chiederei un parere se secondo te può funzionare una soluzione un pò semplificata (nel senso più facile per me da sviluppare con le mie competenze):

per la v14.. se al momento dell'importazione salvassi direttamente il valore della precisione impostata dall'utente invece che ricercarlo a ogni ricomputazione in base alle righe xml, e trovassi il modo di eseguire il ricalcolo con la precisione salvata inizialmente, potrebbe essere una soluzione accettabile (magari in via temporanea)?

Perchè sebbene i wizard dei moduli oca non subiscano molte variazioni ho visto invece che dalla v12 alla v14 cambiano radicalmente i moduli account.invoice/account.move, però per una soluzione definitiva posso comunque provare a prendere spunto dalla tua e provare ad adattarla.. non assicuro nulla ma tentar non nuoce :P

[sergiocorato]

@sergiocorato Fantastico! Almeno so che l'idea del problema l'ho azzeccata, già che ci sono ti chiederei un parere se secondo te può funzionare una soluzione un pò semplificata (nel senso più facile per me da sviluppare con le mie competenze) per la v14.. se al momento dell'importazione salvassi direttamente il valore invece che ricalcolarlo ogni volta sulla base delle righe xml, e trovo il modo di eseguire il ricalcolo con la precisione salvata inizialmente, potrebbe essere una soluzione accettabile (magari in via temporanea)? Perchè sebbene i wizard dei moduli oca non subiscano molte variazioni ho visto invece che dalla v12 alla v14 cambiano radicalmente i moduli account.invoice/account.move, però per una soluzione definitiva posso comunque provare a prendere spunto dalla tua e provare ad adattarla.. non assicuro nulla ma tentar non nuoce :P

Quella strada l'ho già provata e non ho trovato un sistema perchè sia fattibile, almeno nella v. 12.0 (in sostanza si tratterebbe di un'estensione della logica attuale), in quanto dovresti intercettare tutti i casi in cui il sistema resetta i valori ai decimali di default e farli calcolare a quelli specifici, un lavoro improbo e poco affidabile (oltre che poco manutenibile). Se trovi una strada ben venga, io non ci sono riuscito.

[FrancescoBallerini]

In effetti vista così sembra una soluzione molto traballante.. Sicuramente cercherò di guardare meglio la tua soluzione per vedere se in qualche modo riesco a prendere spunto.. in alternativa ti aggiornerò comunque se dovessi riuscire a fare qualcosa di interessante sulla v14.

[SirAionTech]

In 16.0 non succede

Screencast.from.12-06-2024.17.20.43.webm