Importi a 2 cifre decimali

[fgambarelli]

A mio parere, nel momento in cui si imposta la contabilità a 2 cifre decimali, è errato salvare nel DB gli importi con 4 cifre. Quello che si vede a video deve corrispondere con l'importo salvato. Inoltre ritengo sia corretto che nel momento in cui si emette in forma definitiva una fattura (dalla quale avviene la registrazione in contabilità, lo scadenzario ed i registri IVA e la FE) consolidare gli importi dei totali che appaiono in essa. Il ricalcolo continuo con arrotondamenti crea chiusure di bilancio e calcoli complessivi sbagliati.

[fgambarelli]

Riporto qui le conseguenze di questo punto: Il totale delle fatture riportato è diverso dal totale impostato in scadenzario e nelle diverse movimentazioni successive. Con questa query, nel DB ho pi7 di 75 fatture vendite, su 600 errate.

SELECT co_documenti.id, co_documenti.numero_esterno, co_documenti.data,round(co_scadenziario.da_pagare,2) scadenzario,
SUM(round(co_righe_documenti.subtotale,2) - round(co_righe_documenti.sconto,2) + round(co_righe_documenti.iva,2) + round(co_righe_documenti.rivalsainps,2) - round(co_righe_documenti.ritenutaacconto,2)) TOT_FATTURA 
FROM co_documenti
join co_righe_documenti on co_documenti.id = co_righe_documenti.iddocumento
join co_tipidocumento on co_tipidocumento.id = co_documenti.idtipodocumento
left join co_scadenziario on co_scadenziario.iddocumento = co_documenti.id
where co_documenti.data > '2017-12-31' and co_tipidocumento.dir = 'entrata' 
group by co_documenti.id, co_documenti.numero_esterno, co_documenti.data, co_scadenziario.da_pagare
HAVING (SUM(round(co_righe_documenti.subtotale,2) - round(co_righe_documenti.sconto,2) + round(co_righe_documenti.iva,2) + round(co_righe_documenti.rivalsainps,2) - round(co_righe_documenti.ritenutaacconto,2)) <> round(co_scadenziario.da_pagare,2))
ORDER BY `co_documenti`.`numero_esterno`  DESC

[Dasc3er]

@fgambarelli A quanto mi risulta, la contabilità viene già salvata nel modo corretto in base alle impostazioni selezionate. In particolare:

• per importi e quantità con lo stesso numero di cifre, le operazioni di calcolo sui totali non possono generare valori con cifre meno significative
• se le cifre di importi e quantità sono differenti, i conti vengono utilizzati sfruttando le cifre inferiori e in questo caso si potrebbero generare totali con cifre meno significative, che vengono arrotondate sempre nello stesso modo da parte del programma

Di conseguenza, a meno di personalizzazioni sul funzionamento del gestionale, il sistema dovrebbe essere coerente. Ci è però necessario salvare sempre in 4 cifre decimali nel database.

Per quanto riguarda le operazioni di finalizzazione dei documenti, sono in discussione per la versione 2.5 nella seguente issue: #248.

---

Non mi risulta nessuna query come quella da te indicata all'interno della versione base di OpenSTAManager.

[fgambarelli]

Scusa ma nelle fatture di VEndita c'è proprio questo errore! Nella Fatturazione elettronica le cifre devono essere riportate in due decimali e ribdisco non riusciamo ad usare il vostro Registro iva perchè le somme sugli arrotondamenti delle singole cifre sulle ive portano a degli errori.

---

Sul DB dovrebbero essere salvate arrotondate e non con tutte le 4 cifre decimali, se nelle impostazioni si imposta di avere la contabilità in 2 cifre!

[loviuz]

Abbiamo fatto delle valutazioni, e prendo un esempio: IMPONIBILE: 3,13 € IVA 22%: 0,6886 €

Supponiamo di avere 10 righe con questo importo e questa iva:

IMPONIBILE: 31,30 € IVA 22%: 6,89 €

Se arrotondassi e salvassi l'iva di ogni riga a 2 decimali, avrei 0,69 € di iva, che sommata 10 volte mi darebbe 6,90 € (più alta di 1 centesimo). Se mantenessi le 4 cifre decimali (come è ora) per effettuare la somma, avrei 6,8860 che arrotondato a 2 cifre solo alla fine darebbe 6,89 €, importo corretto.

Non possiamo quindi salvare l'iva di ogni riga arrotondata a 2 cifre perché genererebbe un errore. Non possiamo nemmeno salvare l'iva finale del documento perché una fattura può avere delle righe con aliquote iva diverse, per cui devo mantenere l'iva a 4 cifre dato che la divisione per 100 di un importo a 2 cifre genera sempre un numero a 4 cifre. Arrotondandolo ad ogni riga perderei precisione.

Possiamo usare questo esempio per verificare che gli importi tornino sul piano dei conti, prima nota, scadenzario e registro iva, e se non ci sono altre segnalazioni, il problema arrotondamenti dovrebbe essere risolto.

[fgambarelli]

In contabilità, quello che voi definite un errore è invece il comportamento corretto!! Vince la quadratura ed il totale corretto dell'iva della fattura dell'esempio che fai deve essere 6.90 e non 6.89. Mi sono confrontata con un commercialista.