PDA

Vollständige Version anzeigen : Prozentzahl mit Felddatentyp Währung


SusannJo
18.08.2009, 08:22
Hallo,
ich möchte mich nur vergewissern:
Ist es sinnvoll in einer Tabellen wo verschiedene Geldbeträge gespeichert werden, auch die Felder für Prozentzahlen (Rabatt, Skonto...) mit Felddatentyp Währung und Format Prozentzahl anzulegen?
In Abfragen werden ja dann die geldbeträge mit den Prozentzahlen multipliziert und da ist es ja dann möglicherweise günstig, wenn beide Zahlen den gleichen Felddatentyp haben, oder?

Viele Grüße
Susann

hcscherzer
18.08.2009, 08:43
Moin Susann,

das ist nicht besonder sinnvoll. Ich würde empfehlen den Datentyp für den Prozentwert als Zahl (Double) anzulegen.
Und das Ergebnis der Abfrage solltest Du sowieso im Formular oder Bericht formatieren ... in der Abfrage hat ein Format eines nummerischen Wertes eigentlich nichts zu suchen (Ausnahmen bestätigen die Regel).

Josef P.
18.08.2009, 09:10
Ich würde empfehlen den Datentyp für den Prozentwert als Zahl (Double) anzulegen.
Das würde ich nur bedingt empfehlen. ;)
Falls exakte Werte benötigt werden, sind Währung oder Dezimal besser geeignet.

hcscherzer
18.08.2009, 09:20
exakte WerteWas verstehst Du darunter ? IMHO ist der Wert 1/3 auch mit den beiden von Dir genannten Datentypen nicht exakt zu erfassen ...

SusannJo
18.08.2009, 09:23
Hallo Christian,
der Datentyp Währung hat meiner Ansicht nach aber den Vorteil, dass dort nur maximal 4 Stellen nach dem Komma gespeichert werden. Gebe ich also eine Zahl wie 0,123456789 ein - wird gleich richtig gerundet nur die Zahl 0,1235 (12,35%) gespeichert. Bei Double dagegen wird die komplete Zahl gespeichert, und bei Berechnungen muss man dann immer erst runden.

Bei der Multiplikation Betrag(Währung)*Prozent(Währung) entfällt dann meiner Ansicht nach die Runderei - und das Ergebnis ist dann automatisch auch vom Datentyp Währung.

Atrus2711
18.08.2009, 09:34
Hi,

Währung hat feste 4 Dezimalen. Für Prozentwerte, die ja typischerweise zwischen 0 und 1 (0%-100%) liegen, ist dieser Typ dann nur geeignet, wenn die Prozentwerte nicht allzuviele Dezimalen haben.

5% = 0,05 = 2 Dezimalen (ok für Währung)
5,5% = 0,055 = 3 Dezimalen (ok für Währung)
5,55% = 0,0555 = 4 Dezimalen (noch ok für Währung)
5,555% = 0,05555 = 5 Dezimalen (mööp!)

Wer kann das schon ausschließen? Und selbst wenn man sagt "solche Rabatte gbt doch keiner ein": vielleicht möchte man eine Gesamtsumme (10512,17) auf einen glatten Betrag (10000) bringen und muss daher für jeden Posten einen Rabatt von 4,8721624555158449682605970032829% geben....

Double ist auf jeden Fall fehl am Platz (Gleitkommaprobleme!). Dezimal mit hinreichender Precision und Scale wäre sinnvoll.

hcscherzer
18.08.2009, 09:36
entfällt dann meiner Ansicht nach die RundereiSo gesehen hast Du Recht.

Josef P.
18.08.2009, 10:02
@Hans-Christian:
Bei 1/3 wird bei Währung dann 0.3333 gespeichert. Dieser Wert ist dann aber exakt. Er sieht genau so aus, wie er gespeichert ist.

Bei Gleitkommazahlen gibt es allerdings Zahlen, die sich nicht exakt speichern lassen. Das sind alle Zahlen, die sich nicht zu 100% im Binärsystem abbilden lassen (z. B. 0.1). Dann kann es zu Rechenfehlern kommen.

SusannJo
18.08.2009, 10:18
Hallo,
Prinzipiell müsste man doch in einer Tabelle wo reale Geldbeträge gespeichert werden folgende Feld-Einstellung vornehmen:

Felddatentyp: Zahl
feldgröße: Dezimal
Genauigkeit: 18 (z.B.)
Dezimalstellen: 2

Damit würde man doch sicherstellen, dass vom eingegebenen Geldbetrag maximal 2 Dezimalstellen beachtet werden - also Geldbeträge mit mehr Dezimalstellen werden abgeschnitten. Real kann es ja nur 2 Dezimalen geben.

Bei Berechnungen, die mehr dezimalen liefern, muss man dann auf 2 Dezimalen runden.

Tschüss Susann

Atrus2711
18.08.2009, 10:18
Abschreckendes Beispiel:
Sub Test()
Dim i As Long
Dim d As Double
Dim s As Double

d = 0.1 'argh!
s = 0 'just for sure
For i = 1 To 100000000
s = s + d
Next i

Debug.Print s
'Debug.Print i * d 'unsinnig, da i hier = 100000001. Kaffeemangel.
End Sub
Aufruf:
test
9999999,98112945

Josef P.
18.08.2009, 10:22
also Geldbeträge mit mehr Dezimalstellen werden abgeschnitten. Real kann es ja nur 2 Dezimalen geben.
... wie man an der Tankstelle bei den Liter-Preisen sieht. ;)

Atrus2711
18.08.2009, 10:22
Hi,

die Begrenzung auf 2 Dezimalen gilt nur für Geldbeträge, die fließen. Zwischenergebnisse dürfen sehr wohl mehr als 2 Dezimalen haben.

Das siehst du an jeder Tankstelle. 1 Liter kostet z.B. 1,299 = 1,30 "bar", aber 10 Liter kosten trotzdem nur 10*1,299 = 12,99 und nicht 10*1,30 = 13. Die 1,30 sind unzulässig gerundet, wenn damit weitergerechnet wird.

Wie das erst bei Umsatzsteuer pro Einzelposten und in Summe aussieht...?!
Oder bei der Umrechnungen von Währungen?

Josef P.
18.08.2009, 10:28
@Martin:
Debug.Print i * d

Da unterstellst du VBA etwas. ;)
vgl.:
Debug.Print i, i * d, 100000000 * d

Atrus2711
18.08.2009, 10:33
stimmt. ;)
aber eigentlich gings ja nur um die wiederholte Addition (s), nicht um Schleifengrenzen :grinange:

SusannJo
18.08.2009, 10:42
Hallo,
gut an solche Tankstellenfälle habe ich nicht gedacht. In meinem Projekt gibt es nur diese fließenden Geldbeträge wo ich bei der Eingabe möglichst sicher gehen wollte, dass nicht sinnlose Dezimalen eingegeben werden können. Soll ich dennoch bei datentyp Währung bleiben? Bietet der bei Berechnungen noch irgendwelche Vorteile?

Gruß
Susann

Atrus2711
18.08.2009, 10:44
Gegen die Eingabe von sinnlosen Dezimalen schützt ein Eingabeformat. Aber: wieviele Dezimalen gibst du z.B. beim Dollarkurs vor?

Zur generellen Problematik von Festkomma- vs. Gleitkommaberechnungen schau mal da: http://de.wikipedia.org/wiki/Gleitkomma#Eigenschaften_einer_Gleitkommaarithmetik

Fazit: für alles, was Geld ist oder Geld werden kann (Mengen, Rabatte, etc) nehme ich Festkommatypen, also Währung oder Dezimal. Double in Tabellen kommt bei mir faktisch nicht vor (ich habe fast nur mit Finanztransaktionen zu tun).

Ich weiß auch nicht, ob du das Wort fließend aus meinem Beitrag richtig verstanden hast. Ich meinte "Geldbeträge, die ausgehändigt bzw. transferiert werden". Das heißt nicht deshalb Fließkomma, weil da Geld fließt... :)

hcscherzer
18.08.2009, 14:06
Das heißt nicht deshalb Fließkomma, weil da Geld fließt...Aber es heißt Festgeldkonto, weil sich die Bank das Geld, was beim Abschneiden hinter der festen Dezimalstelle übrigbleibt, auf ein solches überweist ... ;)

Atrus2711
18.08.2009, 14:08
Hab ich erwähnt, dass ich Banker bin? Wir würden das *nie* tun! :mrcool: Für solche mysteriöse Erträge haben wir vor zig Jahren die deutsche Zinsmethode erfunden.

SusannJo
18.08.2009, 16:16
Hallo Martin,

Fazit: für alles, was Geld ist oder Geld werden kann (Mengen, Rabatte, etc) nehme ich Festkommatypen, also Währung oder Dezimal. Double in Tabellen kommt bei mir faktisch nicht vor (ich habe fast nur mit Finanztransaktionen zu tun).
ok - diese Aussage ist ja sehr hilfreich - werde ich auch so machen.

Den Begriff fließendes Geld hatte ich richtig verstanden, ich hatte ihn halt real genannt, aber das gleiche gemeint.

Danke und Tschüss
Susann

hcscherzer
18.08.2009, 16:57
Hab ich erwähnt, dass ich Banker bin?
Hätte ich das sonst geschrieben?

SusannJo
18.08.2009, 17:12
Hallo Martin,
nun noch eine Frage zum Abschluss.
Bei der Multiplikation in einer Abfrage Betrag(Währung)*Rabatt(Währung)=neuerBetrag(Währung) muss man ja nun möglicherweise das Ergebnis auf 2 dezimalen runden. Verwendest du da die Funktion aus FAQ2.1?

Danke und tschüss
Susann

Atrus2711
19.08.2009, 08:08
Hi,

wenn das nur ein Zwischenergebnis ist, nein. Wenn das ein Endergebnis ist, ja.

Meist ist ja Rabatt auf Postenebene ("bestellzeile") möglich, die einzelne Zeile ist dann nur ein Zwischenergebnis. M.E. darf da nicht gerundet werden. Notfalls mal einen Fachmann fragen.


Menge Artikelnr Einzelpreis Rabatt% Gesamt
2 4711 3,32 5 6,308 (!)
3 8273 4,11 10 11,097 (!)

SusannJo
19.08.2009, 08:42
Hallo Martin,
verwendest du diese Rundungsfunktion aus FAQ2.1?

Wenn ich am Ende der Bestellzeile nicht runde, sondern erst in der Gesamtsumme, dann kann es passieren das auf einem Ausdruck(dort werden ja nur 2 Dezimalen angezeigt) die Summe scheinbar nicht ganz korrekt ist, weil sie ja nicht wirklich mit den abgebildeten Zahlen - sondern mit den nicht gerundeten Zahlen - gebildet wurde. Bei vielen Posten fällt das ja nicht auf, weil das kein mensch nachrechnet - aber bei wenigen ist es manchmal ja schon sofort ersichtlich.

ich danke dir für deine Mühe
Susann

Atrus2711
19.08.2009, 08:54
verwendest du diese Rundungsfunktion aus FAQ2.1?
Ich hab doch ja gesagt!? :confused:

Wenn ich am Ende der Bestellzeile nicht runde, sondern erst in der Gesamtsumme, dann kann es passieren das auf einem Ausdruck(dort werden ja nur 2 Dezimalen angezeigt) die Summe scheinbar nicht ganz korrekt ist, weil sie ja nicht wirklich mit den abgebildeten Zahlen - sondern mit den nicht gerundeten Zahlen - gebildet wurde.
So ist es. Aber die Zwischenergebnisse fließen nicht, es wird der Gesamtpreis bezahlt. Daher sind die Zwischenergebnisse m.E. nicht zu runden.

Im Extremfall könnte also folgende Rechnung auftauchen (nur Zeilenendbeträge):

Artikel Menge Einzelpreis Rabatt Zwischensumme (intern/gezeigt)
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
... ... ... ... 11,001 -> 11,00
Summe: 110,01 110,00


Das Problem ist also nicht die fehlende Rundung bei der Summierung, sondern eine nicht gerechtfertigte Begrenzung der Zwischenergebnis-Dezimalanzeige auf 2 Dezimalen. Das Zwischenergebnis ist eine rein virtuelle Größe ohne buchhalterische Bedeutung, etwa so sinnvoll wie ein Übertrag, der oft noch auf mehrseitigen Dokumenten ausgegeben wird. Dementsprechend ist es völlig sinnlos, das auf Basis formatierter Werte (!) nachrechnen zu wollen.

Die 11,001 fließen nicht ein einziges Mal. Sie werden aber 10x addiert. Da darf m.E. nicht gerundet werden. Wer in obiger Rechnung 110,00 ausweist, hat m.E. unrecht (immerhin zugunsten des Kunden :) ).

Ein Wirtschftsprüfer kann dir das aber genauer sagen.

Atrus2711
19.08.2009, 08:57
Auf diese Weise kann auch eine Summe von "0"-Werten zu einem Wert über 0 werden. Damit kann man sogar Vorstände verwirren. :) Aber sie wollten ja nur zwei Dezimalen sehen.

SusannJo
19.08.2009, 09:17
Hallo Martin,
ich danke dir noch einmal - du hast mir sehr geholfen.
Ich glaube nun ist alles klar.

Gruß Susann