Newsgroup: it.comp.lang.delphi
Titolo: Arrotondamento currency

Ciao a tutti,
   domanda super trattata nei vari anni con soluzioni diverse e, devo dire, 
mi sono un po perso tra le varie risposte.
 
Comunque ripropongo il quesito, nel caso mi sia sfuggito nelle risposte nei 
vari post trovati.
 
Ho un currency impostato 66.825, con formatcurrency('#,###,##0.00',66825) 
restituisce 66.82, ma la calcolatrice "commerciale" arrotonda a 66.83.
 
Ora lasciando perdere i vari criteri di arrotondamento usati, non c'e' un 
modo spartano per far si che l'arrotondamento (in qualsiasi ultimo decimale 
impostato) se
e' compreso ta 0..4 arrotonda in difetto altrimenti se e' compreso tra 5..9 
in eccesso, come da approssimazione commerciale.
 
Tutto questo perche' nella classica stampa finale di una qualsiasi fattura, 
a volte, per questo cacchio di approssimazione ho una differenza sul totale 
di 1 centesimo
tra imponibile e imponibile + iva.
Ovviamente risolto con la dicitura "arrotondamento' ...  l'intenzione e' 
evitare di inserirla.
 
Grazie
 
Daniele
 
 
 
 

 in eccesso, come da approssimazione commerciale.
 
http://docwiki.embarcadero.com/Libraries/XE7/en/System.Round
 
http://docwiki.embarcadero.com/Libraries/XE7/en/System.Math.RoundTo
 
http://docwiki.embarcadero.com/Libraries/XE7/en/System.Math.SimpleRoundTo
 
 
 
 

Ciao,
  grazie per la risposta.... ma come puoi leggere anche tu il problema e' 
che usano un arrotondamento al numero intero piu' vicino e
se e' esattamente in mezzo (5) arrotondano al numero dispari piu' vicino 
(5.55 = 5.50 anziche' 5.60 e 5.65 = 5.70 corretto) che e' quello che devo 
evitare.
 
Grazie per l'interesse
 
Daniele
 
 
 

 5..9 in eccesso, come da approssimazione commerciale.
 
 
System.Math.SimpleRoundTo
 
-- 
Morde

 evitare.
 
Non proprio... se rileggi attentamente la documentazione delle tre
funzioni che ti ha indicato, vedrai che una delle tre non usa l'arrotondamento del banchiere (che cmq arrotonda al /pari/ piu' vicino, 
non al dispari) ma proprio il classico arrotondamento "all'antica" che 
serve a te.
 
ciao
Giacomo
 
 

 evitare.
 
Costruisci la tua routine. Considera, pero`, che il banker's rounding e` l'algoritmo migliore di arrotondamento, quando si lavora con i soldi. 
 
 

 l'algoritmo migliore di arrotondamento, quando si lavora con i soldi.
Io sto usando ben quello .... pero' ogni tanto ho questa situazione.
 
Grazie a tutti per l'interesse. 
 

 ma 204.90 + 10% = 225.39
 
Il totale IVA, se applichi il 10%, non e` 20.50, ma 20.49. E` chiaro che se sommi valori gia` arrotondati, non farai altro che propagare l'errore.

 wrote:
 
Ho rifatto quella fattura con il mio gestionale.
L'iva al 10% su 204,90 viene 20,49. 
io non stampo in fattura l'arrotondamento.


4ndre4 ha scritto:

Posso chiederti come funzione il banker's rounding?
 
non ho capito il problema ma lo avrei risolto in questi modo
 
procedure TForm1.Button1Click(Sender: TObject);
Function Arrotonda(numero:Single;Cifre,LimiteInferiore : Integer):String;
Var App1 : Integer;
     App2 : Single;
Begin
   App2 := Trunc(Numero*Power(10,Cifre));
   App1 := Trunc(Numero*Power(10,Cifre+1)) Mod 10;
   if (App1>LimiteInferiore) Then
   Begin
     App2 := App2 + 1
   End;
   Arrotonda := FloatToStr(App2 / Power(10,Cifre));
End;
 
begin
   Caption := Arrotonda(3.4567345,3,5);
end;
 
 
 
 
 
-- 
-------------------------------
per scrivere in privato
togliere "1975nosp"
 
to reply remove "1975nosp"
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 Function Arrotonda(numero:Single;Cifre,LimiteInferiore : Integer):String;
[...]
 
Non serve reinventare la ruota, le funzioni di arrotondamento esistono gia` in Delphi, e il problema specifico che Daniele sta avendo e` dovuto al fatto che arrotonda i valori intermedi e li somma. A quel modo, avra` sempre risultati di molto distanti dal valore corretto, e dovra` fare correzioni in piu` o in meno. I valori vanno sempre sommati NON arrotondati, e poi si arrotonda il totale. 
Queste dovrebbero essere le basi per qualunque programmatore.

 Non serve reinventare la ruota, le funzioni di arrotondamento esistono gia` in Delphi,....
 
ho solo messo una cosa che non c'era, la possibilità di cambiare il 
limite dell'ultima cifra oltre il quale arrotondare alla cifra superiore.


 limite dell'ultima cifra oltre il quale arrotondare alla cifra superiore.
 
http://docwiki.embarcadero.com/Libraries/XE7/en/System.Math.RoundTo
 
 
"ADigit indicates the power of ten to which you want AValue rounded. It can be any value in the range from -20 through 20."

 "ADigit indicates the power of ten to which you want AValue rounded. It can be any value in the range from -20 through 20."
 
E cambiare il limite non serve, dal momento che il banker's rounding e` l'algoritmo di arrotondamento ottimo. 

 
 
ma se fai una semplice operazione del tipo : 204,90 * 10 / 100 ti da 20,49 e non 20,50 come dici tu, per cui, secondo me, devi rivedere il calcolo.
 
Ciao da Enrico.


 
Fai pace con te stesso, NON sarai mai sanzionato per aver addebitato 1 
centesimo in più o in meno in una fattura anche perché l'errore di 
arrotondamento ci sta tutto.
 
Non sai quanti errori di "arrotondamento" ci stanno nelle fatture 
scritte manualmente da operatori che, purtroppo, poco scolarizzati ma, 
devo riconoscere, anche "fortemente scolarizzati" (e mi riferisco a 
laureati 110 e lode che NON sanno fare a mano le 4 operazioni e NON 
sanno usare una calcolatrice:) ).
 
In ogni caso se il layout della tua fattura prevede il calcolo dell'iva 
su ogni riga della fattura, vai tranquillo a stampare il dettaglio 
dell'iva come sommatoria delle colonne imponibile ed iva 
(rispettivamente 204.90 e 20.50) se, invece, il tuo layout prevede solo 
l'esposizione dell'imponibile in ogni riga allora, vai tranquillo a 
stampare il dettaglio iva con la sommatoria dell'imponibile (204.90), 
dell'iva calcolata (20.49) così che rispettivamente avrai le fatture con 
un totale diverso, nel primo caso 225.40 e nel secondo 225.39.
 
Ripeto NON sarai mai sanzionato e NESSUNO dei clienti si ribellerà ad 
una o all'altra fattura.
 
Parola di consulente (se conta qualcosa ;)).
 
Ciao.

 (rispettivamente 204.90 e 20.50) se, invece, il tuo layout prevede solo 
 
L'IVA e` 20.49, non 20.50
 
 


Mi riferivo alla somma della colonna IVA della tabella postata da Daniele:
 > prezzo    quantita'      iva         imponibile          iva         >
 > 12.15          5               10               60.75          6.08
 > 10.94          5               10               54.70          5.47
 > 8.90            5               10               44.50          4.45
 > 8.99            5               10               44.95          4.50
 
Ripeto: NESSUNA norma ti sanzionerà mai per questioni sull'arrotondamento.
 
Ciao.
 

Ciao tutti,
  il problema e' lo ha identificato ben bene Luigi.
 
Riga per riga si deve indicare prezzo unitario, quantita', imponibile, iva 
applicata , valore dell'iva, totale.
Ovviamente per forza che riga per riga esistono gli arrotondamenti che, 
anche qui per forza, si portano dietro.
L'erorre, quando si manifesta, e' sempre sul doppio controllo somma dei 
totali riga con imponibile + iva nel totale documento
ed e' sempre di +/- 1 centesimo.
 
Una soluzione approvata in mattinata e' quella di NON indicare il totale su 
ogni riga e di fare il "totalone" alla fine, come nelle
fatture che riceviamo. In questo caso niente piu' problemi, un solo valore 
su cui calcolare l'iva e poi sommarlo.
 
Ancora grazie a tutti.
 
Daniele
 
 
 
 
 
 
 

 Ripeto: NESSUNA norma ti sanzionerà mai per questioni sull'arrotondamento.
 
Non si tratta di essere sanzionati, si tratta di riportare i numeri corretti e di fare le cose come Cristo comanda. I calcoli intermedi non vanno MAI approssimati. Sono i risultati che si approssimano. Si chiama propagazione dell'errore ed e` una cosa che un programmatore dovrebbe conoscere bene.

 ogni riga e di fare il "totalone" alla fine, come nelle
 
Certo che non si indica il totale su ogni riga! Si arrotonda solo il totale!
E c'era bisogno addirittura di "approvarlo"? LOL... 
 


 
Ma che, IMHO, va adattata al caso concreto, che è la fattura:
Nel peggiore dei casi, potresti avere *un* centesimo di arrotondamento 
per ogni riga di fattura. Ma una fattura NON ha mai un numero di righe 
tali da avere UNO o più euro di arrotondamento, anzi! ;)
 
L'esperienza mi dice che, generalmente, l'arrotondamento per eccesso di 
una riga viene compensato dall'arrotondamento in difetto di un'altra 
riga e sul totale tale arrotondamento potrebbe addirittura risultare 
neutro o comunque *trascurabile*.
 
Diverso sarebbe il caso di una serie di calcoli concatenati che se 
basati su importi arrotondati invece che reali verrebbe fuori un 
risultato completamente diverso.
 
Ciao.

 quando già ho detto nell'altro post.
 
naturalmente è "quanto già detto..."
 
 

 Ma che, IMHO, va adattata al caso concreto, che è la fattura:
 
Non si adatta niente. Il principio vale comunque e sempre.

> E c'era bisogno addirittura di "approvarlo"? LOL...
 
Sebbene sia difficile capirlo ..... qui la questione sta andando ancora 
avanti con le ragioniere.
C'e' qualcuno/a che non capisce, ancora, come mai sballa 1 centesimo.
 
Da parte mia, questione chiusa ... :-)
 
Ciao
 
Daniele
 
 
 


Ok, Ciao.

 avanti con le ragioniere.
 
Spero, per te, non siano della stessa risma del ragioniere che ho 
incrociato io che prese la calcolatrice per calcolare "100 - 80" non 
fidandosi di ciò che io gli dicevo. :)
 
-- 
@WarpTen10


 C'e' qualcuno/a che non capisce, ancora, come mai sballa 1 centesimo.
 
E` difficile farlo capire a certi programmatori, figuriamoci a delle segretarie.