Brutto Netto [ERLEDIGT]

[Manfred]

Hi,

sicherlich sind hier echte Finanzexperten, die hierzu eine Lösung parat haben:

9,99 € Brutto. Wie rechne ich denn hier die 19% Ust raus, das der Wert danach wieder 9,99 € ergibt?

9,99/1,19 = 8,394957983 -> gerundet auf 8,40 ergibt 8,40 * 1,19 -> 9,996 -> also 10,--
-> gerundet auf 8,39 ergibt 8,39 * 1,19 -> 9,984 -> also 9,98

Das war jetzt sicherlich nur stellvertretend für andere Werte, die auch so laufen könnten. Hier ist es mir aber aufgefallen.

[Jan]

Hallo Manfred,

bei uns benutzen wir 2 Alternativen:

1) Wir speichern intern mit 5 Nachkommastellen. Bei Ausgaben auf Bildschirm oder Drucker wird das dann auf 2 Stellen gerundet.

2) Wir speichern immer den Ausgangswert, nichts anderes. Alles andere wird davon ausgehend fallweise berechnet. So ist dann der Bruttowert immer der gleiche, egal wohin da was weggerechnet wurde.

Jan

[Martin Altmann]

Moin Manfred,
das Problem wirst Du immer haben, wenn Du die Berechnungen "mischt"!
Du kannst halt nicht einmal runter rechnen und einmal hoch rechnen - ist halt so!
Vor allen Dingen darfst Du nicht erwarten, wenn Du aus einer Gesamtsumme die Märchensteuer raus rechnest, da das selbe herauszubekommen, wie bei den Einzelwerten (und dann aufsummiert)

Viele Grüße,
Martin

[Manfred]

Hi,

die Sache ist aber die, ich habe zu dem Zeitpunkt einen Wert, von dem ich nicht weiß, ob er mit Umsatzsteuer ist, oder aber als Differenzbesteuerung läuft, also ohne Ust. gewertet wird. Und dann eben, ob 19% oder 7%.

[peternmb]

wie wäre es mit einem zusäzlichen Datenbankfeld, in dem du den Steuersatz (als Wert oder Schlüssel) speicherst?

[Manfred]

Yepp,

mache ich ja. Ich muß nur die Summen addieren. Und dabei gibt es halt Differenzbesteuerung und Nettoangaben von umsatzsteuerpflichtigen Werten. Also rechne ich vorher die Ust raus und dann wieder rein.

[Tom]

Es gibt tatsächlich gesetzliche Regeln für das Runden beim Herausrechnen von Mehrwert- und Umsatzsteuer. Einfach mal danach googeln. Ich habe z.B. das hier gefunden:

http://www.haufe.de/steuern/newsDetails ... d=00560203

[Manfred]

Ach,

nee, es geht hier um etwas ganz anderes. Die Sache ist die, beim Bezahlen steht 9,99 dann kommen die internen Berechnungen, weil ich die Beträge netto abspeichere und die Ust getrennt. Später in der Kasse erscheint aber dann 9,98. Das ist das Problem. Ich möchte am Ende wieder den richtigen Bruttobetrag haben.

[Tom]

Hallo, Manfred.

Dann musst Du eben eigene "Regeln" dafür aufstellen. Nur werden die nicht helfen.

9,99 brutto sind 8,39495798... netto. Vollkommen "richtig" gerundet 8,40. 19% Mehrwertsteuer auf 8,40 sind 1,596, also richtig gerundet 1,60. Ergibt zusammen 10 Euro. Nun entscheidest Du, den errechneten Nettobetrag nicht zu runden (legst das als Regel fest) und speicherst ihn als 8,39. Bei der Mehrwertsteuerwiederberechnung wird nun gerundet. 19% auf 8,39 sind 1,5941, also 1,59, das ergibt (Du hast das alles schon vorgerechnet) zusammen aber 9,98. Nächstes Problem: Wenn Du so vorgehst (netto wird nicht gerundet), entstehen aus 9,98 8,38 netto. Darauf die Umsatzsteuer aufgeschlagen ergibt nur noch 9,97. Und so weiter.

Es hilft nichts - Du musst die Nettobeträge mit weiteren Nachkommastellen abspeichern (mindestens 5), um wieder auf die richtigen Bruttobeträge zu kommen. Wenn Du diese Nettobeträge allerdings auch noch irgendwo anzeigen musst, wird's wieder problematisch, denn es gibt ja keine Zehntel-Cents. Also kannst Du nicht 8,39495 anzeigen, sondern musst 8,40 darstellen. Jemand, der dann nachrechnet, welchen Bruttopreis das ergibt, kommt auf 10 Euro. Und es gibt diese Leute, die alles nachrechnen. So ein Ärger aber auch.

Eigentlich kann, wenn eine Nettokalkulation angestellt wird, ein Bruttopreis von 9,99 überhaupt nicht existieren - es gibt keinen Nettopreis, der diese Summe ergibt: 8,39 plus Märchen sind 9,9841, kaufmännisch gerundet 9,98. 8,40 plus Märchen sind 9,996, also 10.

[Manfred]

OK, alles klar.

Ich dachte nur, ich hätte irgendwas übersehen und es gäb die Elwms dafür.

Der Bruttopreis entsteht ganz einfach. Er wird festgelegt und dann sind da eben 19% Ust. drin.

[brandelh]

Hi,

es kommt immer darauf an wovon man ausgeht.

Wenn ein Betrieb NETTO Preise ermittelt, werden daraus die Mwst Berechnet und die Summe gibt den Bruttopreis.
Wenn ein Betrieb den BRUTTO Preis festlegt, errechnet man daraus (nach der gesetzlichen Regelung !) entweder die Mwst oder den Nettobetrag, den jeweils anderen bekommt man durch abziehen.

In jedem Fall speichert man (wenn man klug ist ) alle 3 Beträge und den Steuersatz.
Solange kein Gesetz was anderes sagt speichere und rechne ich mit auf 2 Nachkommastellen gerundeten Beträgen.

In einem Programm musste ich monatliche Zinsen über mehrere Monate aufaddieren.
Wenn man da nicht je Monat rundet und die gerundeten Werte addiert (wie man es ja tun würde wenn man jeden Monat einzeln zahlt), kommen da mehrere Euro Unterschied zusammen wenn es lang genug dauert. Das geht natürlich nicht.

[Tom]

Ja, die so genannten "Schwellenpreise" (,99 oder ,98 oder ,95). Die übrigens nicht erdacht worden sind, um Käufer zu täuschen, sondern um Kassierer dazu zu zwingen, jeden Verkauf an der Kasse zu tätigen, weil sie immer Wechselgeld benötigen würden. Erst später hat man entdeckt, dass solche Preise auch kaufpsychologisch bedeutsam sind, weil Kunden Centbeträge gedanklich kaum wahrnehmen und einen Preis von z.B. 9,99 eher bei 9 als bei 10 einordnen. Wenn Einzelhändler solche Schwellenpreise als Bruttopreise festlegen, machen sie sich offenbar selten Gedanken darüber, wie man später auf den Nettopreis kommen soll. Auf Kassenbons wird die Mehrwertsteuer schließlich summarisch ausgegeben. Dabei stellt sich die interessante Frage, was da steht, wenn man einen Artikel für 9,99 kauft. Müsste man glatt mal ausprobieren.

[Manfred]

Hi Hubert,

ich weiß jetzt nicht genau, wie Du es meinst, aber ich bekomme zunächst den Bruttopreis. Dis Ust habe ich auch. Also rechne ich den Nettopreis aus und speichere zu jedem Vorgang dann den Nettopreis, die Ust und den Ust Satz.

[Tom]

Na, dann ist doch alles fein. Wenn sich nur ein Wert von den dreien durch so eine simple Operation wie die Subtraktion errechnet, gibt's auch keine Rundungsfehler.

[Manfred]

Doch,

gibt es schon. Aber egal, ich werde das mal überdenken, ob meine Lösung so das Gelbe vom Ei ist.

[Tom]

Du musst nur die Umsatzsteuer als Differenz aus dem errechneten gerundeten (!) Nettopreis und dem Bruttopreis ermitteln, dann sind später auch alle Rückberechnungen richtig.

[Manfred]

Ach so,

Du meinst Bruttopreis -> Nettopreis errechnen und dann Brutto - netto...

[Tom]

Jup. Wenn man nachrechnet, kommt man dann zwar auf andere Ergebnisse, aber die wiederum würden bei einer Rückberechnung zu anderen Voraussetzungen führen. Also:

Bruttopreis: 9,99 -> speichern
Errechneter Nettopreis (gerundet): 8,40 -> speichern
Darin enthaltene Mehwertsteuer: 1,59 -> nicht notwendigerweise speichern

Wenn die Mehrwersteuer wieder gebraucht wird: 9,99 - 8,40 = 1,59

[brandelh]

Auch beim Rechnen gibt es eben Funktionen, die nicht umkehrbar sind

Kein Mensch würde versuchen einen Kuchen in Eier, Mehl, Milch und Zucker zurück zu verwandeln,
aber aus einem GERUNDETEN Endergebnis erwartet man die KRUMMEN Ausgangszahlen

Meine 4 Vorauszahlungen für die Müllabfuhr sind auch jeweils auf und abgerundet, sodass am Ende die Cent genau stimmen ...

Ursprung ...,.3
genau ....,.3/4 ... ooups
gibt
1. ...,.1
2. ...,.0
3. ...,.1
4. ...,.1
--------
= ...,.3

und alle sind zufrieden - na ja es könnte insgesamt weniger sein

[Tom]

Besonders viel Spaß beim Runden kann man auch haben, wenn man in der Applikation mit Zeiten arbeitet und rechnet. Vor allem, wenn man auf die Idee kommt, alle Zeiten als Stundenwerte mit Nachkommastellen zu repräsentieren, dem Benutzer aber ermöglichen will, konkrete Zeiten zu erfassen. Da werden aus 10 Minuten schnell mal 9.

[brandelh]

So ist das in der Wissenschaft, da hat man die schönste Theorie aber die Praxis holt einem immer wieder ein

Links seht Ihr übrigens meinen neuen Avatar, mein altes Bild soll mir gar nicht ähnlich gesehen haben ...
Nun man wird älter, was ich diesmal alles retuschieren musste - zum Glück ist es ja so klein

[Koverhage]

Hubert,

bei mir ist das Bild rechts

[Tom]

bei mir ist das Bild rechts

Das lässt sich ändern.

[brandelh]

Hi,

das Rundungsproblem von oben ( 0,03 / 4 ) ist zwar so nicht lösbar, aber ein anderes ginge schon ...

Mit dem Datentyp Currency (10 Byte), den Xbase++ nicht kennt, sind Rundungsfehler die
durch die binäre Darstellung der DOUBLE Variablen entstehen (wir erinnern uns ... 1 / 19.6 * 19.6 # 1 etc.)
ausgeschlossen und auch mehr als 15 signifikante Stellen sind möglich.

Ich sage es ja schon immer, wir brauchen mehr (numerische) Datentypen ... andere haben Sie

[brandelh]

Besonders viel Spaß beim Runden kann man auch haben, wenn man in der Applikation mit Zeiten arbeitet und rechnet. Vor allem, wenn man auf die Idee kommt, alle Zeiten als Stundenwerte mit Nachkommastellen zu repräsentieren, dem Benutzer aber ermöglichen will, konkrete Zeiten zu erfassen. Da werden aus 10 Minuten schnell mal 9.

Hier wäre es besser die Zahl in MINUTEN zu speichern, zwar wäre sie 60 mal so groß, aber würde als INTEGER behandelt (beim Teilen müsste man den Integer wieder erzwingen).
In der Anzeige dann einfach nMinWert / 60 und Picture setzen.