Runden
Dirk Martin
Textfelden in meinem Formular zeigen mir errechnete Eurobetraege mit 2
Kommastellen an.
Nun ist es aber der Regelfall das die Betraege mehr als 2 Kommastellen
haben.
Wie kann ich es erreichen das Access mit den auf 2 Kommastellen gerundete
Zahlen weiterrechnet anstatt mit den genauen/ungerundeten Werten.
Hintergrund ist: Access errechnet aus den Zahlen 1,114 + 2,224 = 3,338 also
gerundet 3,34.
Im Formular wird dabei angezeigt 1,11 (gerundet) + 2,22 (gerundet) = 3,34
(gerundet)
Ich moechte aber das Access mit den ungenauen/ungerundeten Werten
weiterrechnet und als Ergebnis 3,33 rau bekommt.
Geht sowas?
Danke und Gruss
Dirk
Carsten Wilke
> Hallo Ng,
>
> Textfelden in meinem Formular zeigen mir errechnete Eurobetraege mit 2
> Kommastellen an.
> Nun ist es aber der Regelfall das die Betraege mehr als 2 Kommastellen
> haben.
> Wie kann ich es erreichen das Access mit den auf 2 Kommastellen gerundete
> Zahlen weiterrechnet anstatt mit den genauen/ungerundeten Werten.
>
gerade mal (A97) getestet:
2 Zahlenfelder (Format:Allgemeine Zahl)
1 Feld, welches mir die Summe gibt
Da zeigt mir das Summenfeld genau die Anzahl Dez. Stellen. wie in den
ersten beiden Felder drin sind. (also so, wie du es willst)
Kann es sein, daß du in deinem Feld "Dezimalstellen: 2" hast?
Dann mach daraus mal "Automatisch"
HTH,
Carsten
Dirk Martin
da habe ich wohl mein Problem falsch beschrieben...
ich habe einen Rechnungsvordruck auf dem 5 berechnete Felder sind (in Euro).
Angezeigt werden mir nur 2 Kommastellen. Das ist auch gewollt so, da ich ja
eine Währung anzeige. Intern speichert Access aber nicht nur die 2
angezeigten Kommastellen, sondern auch noch die restlichen.
Wenn ich jetzt diese 5 Felder summiere und in einem 6. Feld darstelle kommt
es nun zu meinem Problem. Access rechnet mir zu genau, weil es alle
Kommastellen, also auch die nach der zweiten, mit einrechnet.
Mein Problem ist, dass ich diesen Rechnungsvordruck ausdrucke und als
Rechnung an Kunden verschicke. Auf dem Ausdruck stehen natuerlich nur 2
Kommastellen. Und wenn der Kunde sich jetzt die Muehe macht diese
zusammenzurechnen und die Summe weicht um einen Cent ab, wird er
stutzig.....
Bsp:
Das sehe ich auf dem Formular:
+0,01 EUR
+0,01 EUR
=0,03 EUR
weil:
Access hat im Hintergrund folgende Zahlen im Textfeld stehen:
+0,014... EUR
+0,013... EUR und zeigt diese wie oben mit 2 Kommastellen an.
Als Ergebnis wird mir Access 0,03 EUR Anzeigen.
Auf der Rechnung steht dann 0,01+0,01=0,03 !!! und genau dann denkt der
Kunde: der ist doch doof...
Gruss
Dirk
"Carsten Wilke" <c-w...@gmx.de> schrieb im Newsbeitrag
news:9rept6$cim$07$1...@news.t-online.com...
Mike Fried
> ich habe einen Rechnungsvordruck auf dem 5 berechnete Felder sind (in Euro).
> Angezeigt werden mir nur 2 Kommastellen. Das ist auch gewollt so, da ich ja
> eine Währung anzeige. Intern speichert Access aber nicht nur die 2
> angezeigten Kommastellen, sondern auch noch die restlichen.
> Wenn ich jetzt diese 5 Felder summiere und in einem 6. Feld darstelle kommt
> es nun zu meinem Problem. Access rechnet mir zu genau, weil es alle
> Kommastellen, also auch die nach der zweiten, mit einrechnet.
> Mein Problem ist, dass ich diesen Rechnungsvordruck ausdrucke und als
> Rechnung an Kunden verschicke. Auf dem Ausdruck stehen natuerlich nur 2
> Kommastellen. Und wenn der Kunde sich jetzt die Muehe macht diese
> zusammenzurechnen und die Summe weicht um einen Cent ab, wird er
> stutzig.....
versuch doch mal die Zahlen vorher zu formatieren z.B. mit
cdbl(Format([DasFeld],"#,00"))
damit sollte das dann auch funktionieren. Diese Funktion setze ich aber
eigentlich bereit beim einfügen der Artikel in meinen Auftrag ein.
Gruß Mike
Elmar Boye
"Dirk Martin" <DirkM...@web.de> schrieb ...
> ich habe einen Rechnungsvordruck auf dem 5 berechnete Felder sind (in Euro).
> Angezeigt werden mir nur 2 Kommastellen. Das ist auch gewollt so, da
> ich ja eine Währung anzeige. Intern speichert Access aber nicht nur
> die 2 angezeigten Kommastellen, sondern auch noch die restlichen.
Eben Fliesskomma. Die Dezimalstellenanzeige der Formatangabe
ist da reine Optik... gilt für Formulare wie auch Tabellen.
> Wenn ich jetzt diese 5 Felder summiere und in einem 6. Feld darstelle
> kommt es nun zu meinem Problem. Access rechnet mir zu genau, weil es
> alle Kommastellen, also auch die nach der zweiten, mit einrechnet.
Da hilft nur, jeden schritt des Rechenweges einzeln zu runden -
mit Hilfe einer Funktion entsprechend FAQ 2.1 Runden (www.donkarl.com).
Ausgangsfelder in Tabellen sollten von vorneherein auf 2 Komma-
stellen gerundet sein. Wichtig vor allem dann wenn Du Deine
Euro Berechnung via Teile durch 1.95583 realisiert hast.
Dnach sind jegliche Rechenschritte/(Zwischen)ergebnisse zu runden,
wobei bei Fliesskomma auch eine Addition daneben gehen kann,
spätestens bei Multiplikationen ist ein Rundungsschritt aber
zwingend notwendig (wie Menge * Preis).
Vermeiden solltest Du zudem Single Datentypen, die noch eher
ihre Genauigkeit verlieren. Eher auf den Decimal Typ von
A2000 und höher ausweichen.
Gruss
Elmar
Carsten Wilke
> Hallo Carsten,
>
> da habe ich wohl mein Problem falsch beschrieben...
>
Oder ich habs falsch verstanden... :-)
Aber Elar hat dir ja schon die passende Antwort genannt.
Alle Einzelfelder runden, dann klappts auch mit der Rechnung.
Gruss,
Carsten
Sascha Wostmann
> Da hilft nur, jeden schritt des Rechenweges einzeln zu runden -
> mit Hilfe einer Funktion entsprechend FAQ 2.1 Runden (www.donkarl.com).
>
> Ausgangsfelder in Tabellen sollten von vorneherein auf 2 Komma-
> stellen gerundet sein. Wichtig vor allem dann wenn Du Deine
> Euro Berechnung via Teile durch 1.95583 realisiert hast.
>
> Danach sind jegliche Rechenschritte/(Zwischen)ergebnisse zu runden,
Wie ist das denn rechtlich? Ich dachte immer, man rechnet intern mit
6-stelliger Genauigkeit (daher auch 1.95583 = 6 Stellen) und rundet
erst zum Schluss auf 2 Stellen.
Ich habe schon auf einigen Rechnungen den Spruch gesehen, dass
Rundungsdifferenzen durch die Umrechnung DM/Euro möglich seien.
Aber in gut 2 Monaten interessierts eh keinen mehr...
Viele Grüße,
Sascha
--
Access FAQ unter http://www.donkarl.com/
Access Beispiele (u.a.) unter http://www.access-guru.de/
BITTE KEINE DIREKTEN ACCESS-ANFRAGEN PER MAIL
Elmar Boye
"Sascha Wostmann" <sas...@wostmann.de> schrieb ...
> Elmar Boye :
>
> > Da hilft nur, jeden schritt des Rechenweges einzeln zu runden -
> > mit Hilfe einer Funktion entsprechend FAQ 2.1 Runden (www.donkarl.com).
> >
> > Ausgangsfelder in Tabellen sollten von vorneherein auf 2 Komma-
> > stellen gerundet sein. Wichtig vor allem dann wenn Du Deine
> > Euro Berechnung via Teile durch 1.95583 realisiert hast.
> >
> > Danach sind jegliche Rechenschritte/(Zwischen)ergebnisse zu runden,
>
> Wie ist das denn rechtlich? Ich dachte immer, man rechnet intern mit
> 6-stelliger Genauigkeit (daher auch 1.95583 = 6 Stellen) und rundet
> erst zum Schluss auf 2 Stellen.
>
> Ich habe schon auf einigen Rechnungen den Spruch gesehen, dass
> Rundungsdifferenzen durch die Umrechnung DM/Euro möglich seien.
Da kann man es halten wie die Dachdecker: Letztendlich kannst
Du beide Wege wählen. Sowohl die Einzelposten in der Referenz-
Währung errechnen und dann Summieren oder erst die Summe bilden
und dann in die andere Währung umrechnen.
Die 6 Nachkommastellen gelten nur für den Rechenweg bei Umrechungen
(Triangulation), die Werte sind jeweils in der entsprechenden Anzahl
Nachkommastellen für die Währung auszuweisen.
Wahlweise kannst Du dann jeden Posten einer Rechnung umrechnen oder
aber die Gesamtsumme am Schluss.
Buchhalterisch gilt, das Differenzen auf einem Verrechnungskonto
festzuhalten sind.
Bereits 97/98 von der EU veröffentlicht:
http://europa.eu.int/euro/html/dossiers/00121/00121-de.pdf
(neben einigen mehr)
Gruss
Elmar
Dirk Martin
Hab mir aus den Vorschlaegen was zusammen gebastelt und das funzt jetzt
sogar.
Ich runde jede Einzelposition. Die Kommastellen kommen bei mir nicht durch
Waehrungsumrechnungen, sonder durch die MwSt-Berechnung und Zusammenfuehrung
mehrerer solcher Rechnungen. Meine Datenbank laeuft von vornherein auf Euro
und somit habe ich die eine Sorge der Waehrungsumrechnung weniger! Dafuer
muss ich wahrscheinlich die Altbestaende an DSen von DM in EUR rueckwirkend
umrechnen. *wuerg*
Gruss
Dirk
Hans-J.Bacher
nix würg, das machst du dir leicht mit einer Aktualisierungsabfrage.
Gruß Hans
Dirk Martin schrieb:
Dirk Martin
ja das werde ich schon hinbekommen, das Problem ist aber
noch das aus mehreren DBen (oder besser Altlasten) Tabellen
mit unterschiedlichem Aufbau in eine einheitliche
zusammengefuehrt werden sollen. Es bleibt also nicht nur
beim umrechnen... deshalb *wuerg*.
Hatte eigentlich vor mir die Daten in Excel zu kopieren und
dort die Spalten anzupassen. Ich schau aber mal ob das in
Kombination mit Aktualisierungsabfragen nicht doch einfacher
wird. Danke fuer den Tipp.
Gruss
Dirk
"Hans-J.Bacher" <restauran...@t-online.de> schrieb im
Newsbeitrag news:3BDD2DA8...@t-online.de...
Carsten Wilke
>
> ja das werde ich schon hinbekommen, das Problem ist aber
> noch das aus mehreren DBen (oder besser Altlasten) Tabellen
> mit unterschiedlichem Aufbau in eine einheitliche
> zusammengefuehrt werden sollen. Es bleibt also nicht nur
> beim umrechnen... deshalb *wuerg*.
> Hatte eigentlich vor mir die Daten in Excel zu kopieren und
> dort die Spalten anzupassen. Ich schau aber mal ob das in
> Kombination mit Aktualisierungsabfragen nicht doch einfacher
> wird. Danke fuer den Tipp.
>
leg dir einfach ein neues Feld an, Preis_DM (Benamsung wie du möchtest)
und update dann _nur_ dieses Feld. Sprich: behalte beide Währungen,
und für den Übergang Euro/DM lass einfach beide Felder anzeigen. Das
ist gut für dich (kein "Datenverlust") und für die User (haben als "Referenz"
immer noch den alten DM Wert).
HTH,
Carsten