Newsgroup: it.comp.appl.access
Titolo: Operazioni con Euro: Attenzione !

Ritorno (per aver leggo vecchi post) sul problema dell'uso dell'Euro.
Potrei sbagliare ma mi pare che qualcuno abbia ipotizzato di usare
nelle tabelle dei campi definiti DOUBLE per contenere importi in EURO.
Attenzione: questo porta ad errori.
I campi che contengono valori in euro possono solo essere definiti
Valuta ( Currency)
Questo č dovuto al fatto che i numeri decimali rappresentati nel
sistema binario comportano, a volte, degli arrotondamenti.
Il sistema VALUTA a virgola fissa risolve abbastanza il problema
riportando l'errore a livelli che sono trascurabili nelle applicazioni
contabili.
Per verficarlo, provate a cambiare la definizione di 'a' e di 'x'
nella seguente funzione:
Function y()
Dim a As Currency
' Dim a As Double
' Dim x As Single
' Dim x As Double
Dim x As Currency
Dim i, a2, x2 As Integer
x = 0.0001
a = 0
a2 = a * 100
x2 = x * 100
For i = 1 To 10000
a = a + x
a2 = a2 + x2
Debug.Print a; Format(Nz(a2 / 100, 0), "0.00"); " -->  "; a2 / 100 - a
Next i
a = a * 10 ^ 8
Debug.Print a;
End Function
Per provarla mettetela in un modulo ed eseguitela dalla finestra di
debug.
- - -
Spero non pensiate che voglia fare il saputello. So che quasi tutti lo
sapete benissimo, ma ci sono dei novellini che potrebbero non saperlo.
In caso contrario, scusate l'irruzione...

 ha scritto nel messaggio
news:mkorquodk3ia5ab06...@4ax.com...

Vorrei aggiungere che basta una semplice sottrazione per ritrovarsi nei
campi Double o Single una fila di decimali forse indesiderati.
Private Sub x()
    Dim a As Double
    Dim b As Double
    Dim c As Double
    a = 144
    b = 143.3
    c = a - b
    Debug.Print c
    a = 144
    b = 143.7
    c = a - b
    Debug.Print c
End Sub
Ciao Giorgio

 End Sub
--
Ciao :-)
Maurizio
--------
?SPQR(C)
 X
--------

        c = FormatNumber(a - b, 2)
In questi casi mi affido a una dritta trovata a suo tempo sulla KB
Microsoft:
c= CDec(a-b)  oppure   c=CDec(a)-CDec(b)
Ciao, Ettore

 c= CDec(a-b)  oppure   c=CDec(a)-CDec(b)
    Buona. La sapevo e l'avevo dimenticata. :-(
    Ma nei programmi contabili io preferisco ancora Format perche' voglio
essere certo riguardo al numero dei decimali.


 essere certo riguardo al numero dei decimali.
Giustissimo: il passaggio per il sottotipo decimal va effettuato
semplicemente per non avere residui decimali in calcoli floating-point ... i
risultati di tali calcoli (non necessariamente contabili/commerciali)
potrebbero avere piů di due decimali.
In altre parole, questo č un discorso "collaterale" a quello intavolato da
Marco.
Ciao, Ettore

 Marco.
Mah, forse collaterale non è la definizione migliore: secondo me il Thread è
nato male.
Allora, una cosa sono i problemi che s'incontrano con i floating points.
Ho peraltro ritrovato il link alla kb di cui parlavo:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q210423
E' bene leggerselo: ai floating points non si può rinunciare a piè pari,
anche nel gestionale (come li memorizzo prezzi unitari con sei decimali?).
Altra faccenda è memorizzare fisicamente valori arrotondati
_commercialmente_ al secondo decimale: notare bene che anche usando il tipo
currency spesso i calcoli daranno risultati con quattro e NON due decimali.
Quindi sarà comunque necessario usare funzioni d'arrotondamento (io uso
quella di Karl sul S.C.) per assicurarsi che nel DB i dati siano memorizzati
col correttamente.
Ciao: Ettore

 >     Giusto.
    :-)
    Giusto, non andrebbe bene. Ma per fortuna non si comporta come Round.


 Altra faccenda è memorizzare fisicamente valori arrotondati
Non vedo questa esigenza.
La memorizzazione "fisica" dei valori arrotondati e' un'operazione
ridondante. e' nelle fatture che questo arrotondamento deve essere
rappresentato (e non memorizzato)
Davide

 rappresentato (e non memorizzato)
--


 ha scritto nel messaggio

Scusa ma io la metterei in un altro modo.
Faccio quindi una distinzione tra programmi gestionali e programmi
contabili.
In un gestionale non c'e' motivo di memorizzare l'informazione in quanto
viene calcolata al momento
In un programma di contabilità devi per forza memorizzare il dato perche'
normalmente non ci vai a memorizzare le righe fattura ma solo i movimenti
contabili.
Se devi fare interagire un programma gestionale con uno di contabilita', al
momento dello spostamento dei dati il gestionale calcolera' tutto quello che
deve calcolare e lo "memorizzera' " nel programma contabile.
premesso questo osserverei che in un NG come questo al 99% parliamo di
programmi di fatturazione e gestione, non certo di programmi di
contabilita', che richiedono tutt'altre premesse che quelle di un "medio
programmatore" che sviluppa da se.
Sib

 ridondante.
Ridondante??
In una qualunque gestione è frequente (vedi il caso di scorpori) dover
memorizzare risultati di calcoli.
Risultati che quasi sempre avranni più di due decimali, ma che tu devi
memorizzare in formato Euro corretto.
Mah.
Ettore

 rappresentato (e non memorizzato)
Interessante: quindi tu rappresenti il Totale Fattura con due decimali senza
preoccuparti che il valore contenuto nel campo calcolato (o variabile, o
textbox non associata) sia *fisicamente* a due decimali.
Quindi quando questa fattura andrà in contabilità (che è un bell'esempio di
gestionale strettamente collegato con la Fatturazione) ce lo mandi con più
di due decimali ... bravo!
Ciao, Ettore

Leggendo in tema di arrotondamenti, non posso fare a meno di intervenire
di fronte a certe affermazioni dettate da esperienze discutibili.
E' necessario, anzi fondamentale, salvare fisicamente i decimali che
interessano.
Ho già verificato la differenza che Access compie quando somma
importi con decimale salvati fisicamente e importi con decimali non salvati
fisicamente.
Si tratta di differenze che anno rilevanza, in qualsiasi ambito: sia
contabile che
non contabile. Tale differenza non è dovuta a un difetto di Access ma un
pregio dei
calcoli compiuti dalla cpu. Gli arrotondamenti con l'euro vanno fatti quindi
con molta
attenzione. Inoltre memorizzare fisicamente i valori arrotondati non vìola
affatto la normalizzazione di un database.
Mentre, mi preme inoltre sottolineare che i programmi di fatturazione sono
programmi
di contabilità, come il magazzino, ecc. ecc.; queste cose i ragionieri le
sanno bene.
Onde per cui concordo con chi la pensa come me.
Cordialità.
Toni
:)

e' priva di senso. 
Era esattamente quello che tu suggerivi. Il calcolo in eurocent.... ma
non mi sono perso in spiegazioni (forse avrei dovuto..)
Quanto ai prezzi unitari molto piccoli... Currency gestisce fino a
0,0001 Euro. La legge fiscale, se non erro, richiede che i prezzi
possano al massimo , in casi particolari, avere TRE decimali.
Magari alla fine della discussione facciamo un riassunto su come
operare con le valute e poi magari lo mettiamo sul sito... che dite ?

 operare con le valute e poi magari lo mettiamo sul sito... che dite ?
    Mi sembra un'ottima idea.


 possano al massimo , in casi particolari, avere TRE decimali.
Non era una legge fiscale.
E in casi particolari erano previsti più di quattro decimali.
Ciao, Ettore

 E in casi particolari erano previsti più di quattro decimali.
Parlo naturalmente di prezzi unitari.

E in casi particolari erano previsti più di quattro decimali.
Volgio dire che mi pare di ricordare una discussione con un
commercialista la momeneto del passaggio all'Euro che la legge
impedisce di pubblicare listini con voci con valori con più di TRE
decimali. Quanto agli arrotondamenti ci sono disposizioni precise su
come farli e in quali passaggi (vedi ad es. come si calcola il capital
gain sui titoli operati in USA...!!!!)

 gain sui titoli operati in USA...!!!!)
Ovvio, ma questo è un altro discorso.

memorizzare in formato Euro corretto.
Concordo.
Ciao, Silvio

possano al massimo , in casi particolari, avere TRE decimali.
Ti confermo che non č cosě: alcune ditte operano con sei decimali sul prezzo unitario.
Difficile dire se continueranno in quel modo anche nei prossimi anni, per ora č un dato di fatto.
Ciao, warp


[CUT]
Chi è che faceva quella specie di blob con le frasi celebri dal NG...
Lorenzo Coronati, mi pare...
ehi, questa è super!
--
Alberto

 gain sui titoli operati in USA...!!!!)
La norma che fissa il numero di decimali da usare riguarda solo il momento
in cui si converte in euro un valore in lire... e le cifre decimali possono
essere anche più di tre o più di quattro.
I listini in euro possono avere quanti decimali vuoi, la legge solo
stabilisce che gli importi suscettibili di autonoma contabilizzazione
(imponibile, IVA, totale ...) non possono avere più di due decimali.
Ciao
--
Alberto

:

mo' moo segno :-)
--
lorenzo coronati
---

"Lorenzo Coronati" <
Però oggi sei sprovvisto di frasette celebri!

 Però oggi sei sprovvisto di frasette celebri!
Ci vuole la licenza, ma domani!
Antonio

Però oggi sei sprovvisto di frasette celebri!
tempo fa avevo evidentemente stuzzicato la sensibilita' del
biso-clone, che aveva iniziato a clonare anche me :-)
e siccome ci tengo al mio fegato, ho smesso con le
signatures
cmq si parlava di mettere le migliori sul sc
appena luciano torna a lavorare... ;-)
--
lorenzo coronati
---