Newsgroup: it.comp.lang.vo-clipper
Titolo: [CL5.2] Funzione EURO

C'è qualcuno che ha realizzato un Funzione che trasforma le lire in EURO.
Sicuramente Si.
Sono sfacciatamente un pigro, di conseguenza se la funzione è già stata
fatta io ne approfitterei.
GRAZIE


Spero che tu non stia parlando della semplice divisione per 1936.27...
EMG

E ricordati che devi arrotondare alla 2° decimale.
Mi spiego meglio: se una fattura il lire ha un imponibile di Lit. 38.090.350
in euro sarŕ di euro 19.672,02 e non 19.672,02405.
Cioč fai la funzione ROUND(imp_lire/1936.27,2)


Si, ma conviene farlo solo quando si va a visualizzare il risultato a
video altrimenti si rischia di introdurre pesanti errori di
arrotondamento.
EMG

SI ... !!!!   ha ragione Enrico si rischia di fare dei casini con gli
arrotondamenti quando si coinvolgono cifre elevate. Io ad esempio metto la
picture "###,###.##" solo per visualizzazione, ma nei conteggi interni
divido rigorosamente per 1936.27. Una cosa č la visualizzazione del numero
decimali, un'altra č l'elaborazione interna. (un pň come credo faccia
EXCEL).

 ha scritto nel messaggio
news:yICZ6.139$Nj....@news2.tin.it...


 o c'è qualcosa altro di cui tenere conto lavorando con VO?"
Veramente la domanda riguardava Clipper 5.2 (come da Subject).
EMG


La regola d'oro per gli arrotondamenti è la seguente:
Quando un importo in Lire non costituisce autonomo importo monetario da
contabilizzare o pagare deve essere convertito in Euro con i seguenti
decimali:
se espresso in         1L            5 decimali
se espresso in         10L          4 decimali
se espresso in         100L        3 decimali
se espresso in         1000L      2 decimali
Un importo in Euro da non contabilizzare o pagare può essere trattato con
decimali a piacere.
Ciao a tutti.
Roberto Cordini

 > Cioè fai la funzione ROUND(imp_lire/1936.27,2)


Attenzione: Non possono essere contabilizzati documenti con piů due cifre
decimali.
Va sempre arrotondato, quindo cosa te ne fai du piů decimali in un campo che
deve contenere
Imponibile, totali, etc. etc.?


REGOLA D'ORO
Robby wrote:

Per l'iva vale sempre il ROUND(    ,2)
non si arrotonda più solo per eccesso

 ha scritto nel messaggio
news:3B37B580...@flashnet.it...


 ha scritto nel messaggio
news:j9LZ6.2982$6x.9...@news.infostrada.it...


 Imponibile, totali, etc. etc.?
No, non ci siamo spiegati bene. E' chiaro che gli importi specificati
direttamente dall'utente vanno arrotondati alla seconda cifra decimale.
Quello che non va fatto č l'arrotondamento parziale durante un calcolo.
Solo il risultato finale deve essere arrotondato altrimenti gli errori
di arrotondamento potrebbero sommarsi e dare un risultato falsato.
EMG

 ha scritto nel messaggio
news:yICZ6.139$Nj....@news2.tin.it...


 ha scritto nel messaggio
news:HQ6_6.8629$mu2....@news2.tin.it...


 in stampa o video il risultato formattato a due decimali?
A questo punto io non ho proprio capito cosa ti serve esattamente...
EMG

 capire come state affrontando la fine dell'anno.
Personalmente ho semplicemente, da tempo, previsto due cifre decimali
nei database e quindi devo solo (l'ho già fatto e sembra che non ci
siano altri problemi) cambiare le PICTURE nelle GET e nelle stampe,
oltre a fare un programmino di conversione per gli archivi già
utilizzati dai clienti.
EMG


wrote:

Nella conversione all'Euro di un programma contabile, Io sto adottando
una strategia massimamente  prudenziale: ho impostato a 5 decimali i
campi che devono contenere gli importi in euro che derivano dalla
conversione dei relativi campi che adesso contengono quelli in lire.
Tutte le picture e le uscite nei report sono invece arrotondate ai due
decimali. Nel tempo (quando il programma funzionerà solo in euro) i
cinque decimali saranno eccessivi (tutti i nuovi inserimenti avranno
sempre solo due decimali), ma nel periodo di transizione i cinque
decimali mi garantiscono la precisione nelle conversioni.
Per la conversione ho fatto due banali funzioni che effettuano la
divisione o la moltiplicazione degli importi per 1963.27 (il programma
è studiato perché possa funzionare in euro o in lire indifferentemente
e quindi sono necessarie entrambe le funzioni)
Ciao, Marino

Ciao, Marino
 Ovviamente c'è un errore nel messaggio: 1 euro = 1936.27 lire e non
1963.27 come scritto :(
Ciao, Marino

 ha scritto nel messaggio
news:3B3983D2...@flashnet.it...


 ha scritto nel messaggio
news:JT6_6.8638$mu2....@news2.tin.it...


 ha scritto nel messaggio
news:9hcof3$ssp$1...@fe2.cs.interbusiness.it...


 ha scritto nel messaggio
news:yICZ6.139$Nj....@news2.tin.it...


 risultato a 2 decimali (importo della riga)
Però attenzione, come si è già detto, agli errori di arrotondamento.
Sarebbe preferibile fare sempre i calcoli in base agli importi singoli e
alle quantità non arrotondati e arrotondare solo i risultati finali.
D'altronde anche in lire c'è lo stesso identico problema quando, ad
esempio, calcoliamo l'IVA per la singola riga (nel caso ci siano
aliquote diverse per ogni articolo).
EMG

 ha scritto nel messaggio
news:3B3DC7CE...@flashnet.it...


 decimali quando la contabilità deve essere fatta a 2 ?
Attualmente se hai 12 pezzi che costano ognuno 0.45 lire che fai? Scrivi
5.4 lire di totale riga, giusto? E quindi sommi proprio questo importo
per ottenere il totale, ok? Se lo arrotondassi a 5 lire il conto non
tornerebbe più. Oppure tornerebbe se utilizzassi il valore arrotondato
per la somma. Ma in questo caso ci sarebbero forti errori di
arrotondamento nel calcolo del totale da pagare.
EMG

 ha scritto nel messaggio
news:3B40BE74...@flashnet.it...


 ha scritto nel
messaggio news:9hse16$ulv$1...@pegasus.tiscalinet.it...


 non si arrotonda più solo per eccesso
Sei sicuro di questo? Io in assenza di informazioni
ho fatto gli arrotondamenti in eccesso.
Sai dove e' possibile reperire info ufficiali?
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 GRAZIE anticipatamente
Prova questa, esegue l'arrotondamento al decimale corretto in base alla valuta
scelta dalla variabile globale G_EURO.
E' un po patchata (traduzione: rappezzata?) perche' ho avuto comportamenti 
strani in alcune occasioni.
L'avevo sviluppata tenendo conto degli arrotondamenti per eccesso dell'iva,
ma se anche per l'iva si puo' fare l'arrotondamento matematico basta fare
round(n,2)
#define EU_HIGH    1
#define EU_MATH    2
#define EU_LOW     3
* ------------------------------   EUROUND   ------------------------------
* esegue l'arrotondamento monetario in base alla valuta usata. nType indica
* se l'arrotondamento deve essere matematico, troncato, o alla valuta
* superiore del valore assoluto, di default al valore superiore
function euRound(nVal,nType)
  local n
  if empty(nVal) ; return nVal ; endif
  default nType to EU_HIGH
  if G_EURO 
    if str(nVal,16,4) == str(round(nVal,2),16,4) ; return nVal ; endif
    do case
      case nType == EU_MATH    ; n := round(abs(nVal), 2)
      case nType == EU_LOW     ; n := round(abs(nVal) - .005, 2)
      otherwise                ; n := round(abs(nVal) + .004999 ,2)
      endcase
  else
    if str(nVal,16,2) == str(round(nVal,0),16,2) ; return nVal ; endif
    do case
      case nType == EU_MATH    ; n := round(abs(nVal), 0)
      case nType == EU_LOW     ; n := round(abs(nVal) - .5, 0)
      otherwise                ; n := round(abs(nVal) + .499999 ,0)
      endcase
    endif
  if nVal < 0 ; n := -n ; endif
return n


 ha scritto nel messaggio
news:CEK07.2273$D03....@news.infostrada.it...


Sono rientrato ora dalle ferie.
Se desideri ti mando un fax con articolo del sole 24 ore del giorno
17-07-00.


 > > non si arrotonda piů solo per eccesso


 decimali per l'euro).
Ti sarei grato se facessi sapere anche a me le conclusioni. Finora non
mi è mai capitato questo tipo di problematica ma ora la cosa, con
l'EURO, diventa pressante. E d'altronde con le leggi non ci sono
ragionamenti che tengano. Bisogna seguirle alla lettera e basta.
EMG