Rundungsproblem, Währungsumrechnung, gibt es feste Regeln?

[Andreas Korthaus]

Hallo!

Ich habe eine Art "Kalkulations-Tabelle", die in verschiedenen Währungen angezeigt werden muss. In die Tabelle werden Stückpreise eingegeben, Gesamtpreise und Summe wird daraus errechnet. Hierbei treten Rundungs-Probleme auf. Das heißt, wenn ich eine Zahl mit einer Währungkurs mit 5 Nachkommastellen multipliziere, bekomme ich eine Zahl mit mehr Nachkommastellen, und irgendwie bin ich nicht ganz sicher wie ich damit umgehen muss. Ich habe mal gehört dass es bestimmte Regeln für die Umrechnung von DEM -> EUR gab (habe ich allerdings noch nicht gefunden), gibt es sowas auch für allgemeine Währungsumrechnungen? Also so Vorgaben wie "hier wird gerundet, hier wird mit der gerundeten Zahl gerechnet...".

Damit man sich das besser vorstellen kann, hier mal eine beispielhafte Tabelle:

Artikel    |  Stückpreis  |   Anzahl   |   Gesamtpreis
---------------+--------------+------------+--------------
Bleistift      |      0,55000 |        150 |      83,50000
Briefumschlag  |      0,21000 |       1200 |     252,00000
Kugelschreiber |      1,29000 |        180 |     232,20000
----------------------------------------------------------
                                     Summe       566,70000

Bis hier noch sehr einfach. Die Preise und auch der Faktor (z.B. Währung) sollen 5-stellig sein. Ich muss leider etwas krummere Zahlen verwenden, weil das Problem sonst nicht deutlich wird. Angenommen das hat jetzt jemand in der Währung XYZ mit dem Umrechnungskurs 1,26537(zum EUR) eingegeben. Jetzt möchte ich mir diese Tabelle aber in EUR anzeigen, also die Preise durch den Faktor teilen:

Artikel    |  Stückpreis  |   Anzahl   |   Gesamtpreis
---------------+--------------+------------+--------------
Bleistift      |      0,43466 |        150 |      65,19900
Briefumschlag  |      0,16596 |       1200 |     199,15200
Kugelschreiber |      1,01946 |        180 |     183,50280
----------------------------------------------------------
                                     Summe       447,85380

In diesem Fall habe ich die Stückpreise durch den Faktor(Währungskurs = 1,26537) dividiert, auf 5 Stellen gerundet, und damit weiter gerechnet. Das alles entscheidende ist die Summe, denn die wird später überwiesen, und sollte also stimmen. Aufgrund der Rundung kommt man bei der manuelle Berechnung der Summe aber auf einen anderen Wert:

566,70000 / 1,26537 = 447,85320 != 447,85380

Gut das ist jetzt nicht viel, mit anderen Zahlen hatte ich hier aber auch schon eine Differenz von 150 EUR.

Was kann ich dagegen machen? Ich könnte intern/transparent mit mehr Nachkommastellen rechnen, das reduziert das Problem, beseitigt es allerdings nicht (schon nach 1-2 Berechnungen entstehen meist zu viele Nachkommastellen...). Ganz im Gegenteil kann dies auch zu neuen Problemen führen, wenn mit anderen Zahlen als angezeigt tatsächlich gerechnet wird.

Gut, da die Summe der entscheidende Preis ist (der wird schließlich vom Konto abgebucht), könnte man ja auf die Idee kommen, diesen, bzw. die Gesamtpreise zu speichern, und die Einzelpreise aus den Gesamtpreisen zu errechnen. Heißt also, ich rechne die letzte Spalte um und speichere das, und später errechne ich daraus anhand der Mengen auch die Stückpreise. Mal am Beispiel:

Artikel    |  Stückpreis  |   Anzahl   |   Gesamtpreis
---------------+--------------+------------+--------------
Bleistift      |      0,43466 |        150 |      65,19832 (= 83,50000 / 1,26537)
Briefumschlag  |      0,16596 |       1200 |     199,15124 (")
Kugelschreiber |      1,01946 |        180 |     183,50364 (")
---------------+--------------+------------+--------------
                                     Summe       447,85320

Soweit so gut. Nur leider, wenn jetzt jemand mit dem Taschenrechner nachrechnet:

0,43466 * 150 = 65,19900 != 65,19832 => BETRUG!

Auch der Stückpreis direkt umgerechnet stimmt nicht:

0,43466 * 1,26537 = 0,55001 != 0,55000

wobei letzters vorerst nicht ganz so schlimm ist, die Summe ist wichtig. Trotzdem darf es keine offensichtlichen "Rechenfehler" wie oben geben.

Und es gibt ein weiteres Problem. Der EUR ist die Referenz-Währung, das heißt dieser Preis zählt später, entsprechend wird auch alles in EUR gespeichert. Das heißt, ich speichere nicht den vom Anwender eingegebenen Preis, sondern einen gerundeten EUR-Preis, und rechne ihm dann bei der Anzeige seine Preise entsprechend mit seinem Währungskurs um. Durch die Rundung hier kann es passieren, dass er auf einmal einen anderen Preis da stehen hat, den er gar nicht eingegeben hatte. Genau das passiert auch in diesem Fall. Egal welche der beiden Methoden zur Umrechnung ich verwende, ich speichere z.B.

0,55000 / 1,26537 = 0,43466

in der Datenbank als Stückpreis für den Bleistift, und wenn ich ihm die Tabelle erneut anzeige, dann erhalte ich bei der Berechnung

0,43466 * 1,26537 = 0,55001 != 0,55000

Das heißt er gibt "0,55" ein, es wird aber ein minimal anderer (gerundeter) Wert gespeichert. Somit kann ich nie wieder auf die Zahl kommen, die ursprünglich mal eingegeben wurde. Mit anderen Zahlen sind auch hier größere Abweichungen möglich.

Ich sehe 2 Probleme bei der Berechnung:

1. Es wird mit gerundeten Werten multipliziert/dividiert, das führt dazu, dass ein Teil der Informationen verloren geht. Dadurch die Fehler in den Berechnungen mit "Stückpreis x Menge".

2. Es wird nicht das eingegebene Gebot gespeichert, sondern ein gerundetes Ergebnis einer Division. Auch hier gehen Informationen durch die Rundung verloren, die dann für den Anwender zu nicht nachvollziehbaren Werten führen.

Wenn man zusätzliche Nachkommastellen speichert, verlagert man das Problem einfach entsprechend weiter nach hinten, aber man wird es nicht los. Bei entsprechend großen und genauen Zahlen wird es weiter Probleme geben, auch mit 10 Nachkommastellen.
Außerdem werden nur 5 Nachkommastellen angezeigt, wenn ich eine Zahl aber tatsächlich mit mehr Nachkommstellen speichere und zu Berechnungen verwende, dann ist das Ergebnis zwar richtig(er), aber da  in der Anzeige gerundet wird, ist diese nicht mehr mit dem Taschenrechner nachvollziehbar.

Im Moment bin ich der Ansicht, dass sich das Problem nicht vollständig beseitigen lässt, egal wie man es dreht und wendet. Daher fällt mir bisher nur ein, die entsprechenden problematischen Umrechnungen an Stellen zu verlagern, wo es "nicht so schlimm ist". Schlimm ist es z.B., wenn ein Anwender einen Preis eingibt, und das System tatsächlich einen anderen Preis speichert. Daher sollte man wohl eher die originale Eingabe speichern, und von dort aus umrechnen. Dann hat derjenige der was eingibt eine konsistente Tabelle. Außerdem kann man dann von diesen Werten ausgehend, also von einem ungerundeten/originalen Preis andere Preise berechnen, auch in anderen Kursen.

Aber leider habe ich dann immer nur eine konsistente/schlüssige Tabelle. Wenn ich will das alle Tabellen in sich logisch/nachrechenbar sind, habe ich das Problem dass ich nicht überall auf dieselbe Summe komme.

Entweder ich rechne von dem angezeigten (gerundeten) Stückpreis den  Gesamtpreis aus, habe so eine Konsistente Tabelle, oder ich Rechne von dem angezeigten Gesamtpreis den Stückpreis aus, was dazu führt dass zwar überall Gesamtpreise und Summen stimmen, aber nicht alle Tabellen in sich schlüssig sind. Irgendwie beides keine angenehmen Alternativen.

Ist etwas kompliziert wie ich finde ;-)

Muss man mit diesen Unstimmigkeiten leben, oder gibt es eine Möglichkeit dass alle Werte stimmen? Oder gibt es irgendwo Normen/Vorschriften/Standards wie man solche Umrechnungen zu machen hat? Oder hat jemand Ideen für einen ganz anderen Ansatz? Im Moment beißt sich die Katze in den Schwanz...

Viele Grüße
Andreas

[Richard Rüfenacht]

Hallo Andreas,

diese Abweichungen entstehen vermutlich dadurch, dass die 6. Nachkommastelle nicht gerundet, sondern lediglich abgeschnitten wird. In Datenbanken gibt es dafür meist ein Format "Währungen", das dieses Problem vermeidet.

Schönen Gruss

Richard

[Andreas Korthaus]

Hallo!

diese Abweichungen entstehen vermutlich dadurch, dass die 6. Nachkommastelle nicht gerundet, sondern lediglich abgeschnitten wird. In Datenbanken gibt es dafür meist ein Format "Währungen", das dieses Problem vermeidet.

Nein, das Problem besteht schon in der Theorie. Die angegebenen Tabellen habe ich in Excel eingegeben und berechnet. Und es wurde auch nur mit den angezeigten Nachkommastellen gerechnet, also mit den gerundeten Werten (kann man bei Excel unter Extras -> Optionen -> Berechnungen einstellen). Habe das auch mit dem Taschenrechner überprüft.

Das Kernproblem ist ganz einfach:

Nehme einen Wert mit 10 Nachkommastellen, runde auf 5 Stellen. Dann multipliziere mit irgendeiner Zahl, und Du wirst ein anderes Ergebnis erhalten, als mit dem originalen Wert. Der "originale Wert" ist z.B. ein mit 5 Nachkommastellen eingegebener Preis, der mit einem Wechselkurs mit ebenfalls 5 Nachkommastellen umgerechnet wurde.

Das Problem ist wirklich etwas kompliziert, sorry, aber ich kann es leider nicht einfacher formulieren. Obwohl ich schon viel Zeit hiermit verbracht habe, fällt es mir nach einiger Zeit immer wieder schwer mich da hineinzudenken ;-)

Grüße
Andreas

PS: Leider muss ich Datenbank-Unabhängigkeit bewahren - soweit möglich. Daher verlagere ich einen Teil dieser Logik in die Anwendung, auch wenn das nicht so effizient ist, leider geht es nicht anders.

[Richard Rüfenacht]

Hallo Andreas,

war mir nicht so ganz klar, wie du das rechnest. Exel rundet korrekt. Du musst einfach mit einer grösseren Anzahl Nachkommastellen rechnen. Rechnen mit gerundeten Werten führt immer zu Abweichungen. Andererseits sind solch geringfügige Abweichungen (Rundungsfehler) aber durchaus handelsüblich.

Gruss Richard

[Andreas Korthaus]

Hallo Richard nochmal ;-)

diese Abweichungen entstehen vermutlich dadurch, dass die 6. Nachkommastelle nicht gerundet, sondern lediglich abgeschnitten wird. In Datenbanken gibt es dafür meist ein Format "Währungen", das dieses Problem vermeidet.

Oder meinst Du, dass man bei solchen Preis-Berechnungen gar nicht runden darf, sondern abschneiden muss? Oder nur bei Währungsumrechnungen? Gibt es hier entsprechende Standards?

Werd das mal versuchen...

Danke Dir!

Grüße
Andreas

[Andreas Korthaus]

Hi!

Oder meinst Du, dass man bei solchen Preis-Berechnungen gar nicht runden darf, sondern abschneiden muss? Oder nur bei Währungsumrechnungen? Gibt es hier entsprechende Standards?

Werd das mal versuchen...

Hm also das geht glaube ich auch nicht. Denn das ist ja im Prinzip nichts anderes als abrunden, und auch hierbei gehen entsprechend Informationen verloren, also kann ich nicht mit einem wie auch immer beschnittenen Stückpreis auf denselben Gesamtpreis kommen, wie mit dem Original-Preis.

Grüße
Andreas

[Andreas Korthaus]

Hallo nochmal!

Ich habe mal gehört dass es bestimmte Regeln für die Umrechnung von DEM -> EUR gab [...]

OK, sowas hab ich gerade gefunden: http://www.sparkasse.at/erstebank/content/0,,1185233,00.html (bisschen schlecht im Firefox)
Da sind ja wirklich viele Regeln definiert. Nur finde ich darunter bisher nichts wirklich hilfreiches, gibt es vergleichbare Standards für allgemeine Währungsumrechnungen, oder Berechnungen von faktorierten Preisen? Auch finde ich da nichts von "Abschneiden"...

Grüße
Andreas

[Siechfred]

Hallo Andreas.

gibt es vergleichbare Standards für allgemeine Währungsumrechnungen, oder Berechnungen von faktorierten Preisen?

Für die Umrechnung nationale Währung in eine andere innerhalb der EU galt folgendes Verfahren:

1. Umrechnung in Euro anhand des festgelegten Wechselkurses
2. Rundung des Betrages auf 3 Nachkommastellen (bei "5" war stets aufzurunden)
3. Umrechnung des Betrages 2 in die "Zielwährung" mit 5 Nachkommastellen
4. Rundung auf 2 Nachkommastellen wie bei 2.

Aber das ist Geschichte :)

Nun zu der Frage, wie es aktuell aussieht. Hier gibt es verbindlich festgelegte Umrechnungsregeln, die eigentlich ganz einfach sind:

1. Umrechnung EUR -> Drittwährung
   EUR-Betrag * EUR-Kurs
2. Umrechnung Drittwährung -> EUR
   Drittwährungsbetrag / EUR-Kurs

Gerundet wird wie bereits oben beschrieben: 1-4 abrunden, 5-9 aufrunden. Anlehnen kannst du dich bei der Umrechnung und Rundung an den DRS 14, eine kurze Zusammenfassung gibt es z.B. hier:

http://rsw.beck.de/rsw/shop/default.asp?docid=104277&docClass=NEWS&from=BC.560

Vielleicht hilft's ja.

Freundschaft!
Siechfred

[Siechfred]

Hallo Andreas.

Ich hatte dir zwar schon geantwortet, erlaube mir aber nochmal, auf dein Ausgangsposting einzugehen

Angenommen das hat jetzt jemand in der Währung XYZ mit dem Umrechnungskurs 1,26537(zum EUR) eingegeben.

Das heißt 1 Fremdwährungseinheit (FWE) = 1,26537 EUR?

In diesem Fall habe ich die Stückpreise durch den Faktor(Währungskurs = 1,26537) dividiert, auf 5 Stellen gerundet, und damit weiter gerechnet.

Der Weg ist zunächst der richtige, nur die Rundung nicht. Du müsstest auf 2 Nachkommastellen runden, wie ich es dir bereits schrieb. Danach sähe deine Tabelle so aus:

Artikel    |  Stückpreis  |  Stückpreis  | Stückpreis
               |     (EUR)    |     (FWE)    |  (gerundet)
---------------+--------------+--------------+------------
Bleistift      |      0,55000 |      0,43466 |        0,44
Briefumschlag  |      0,21000 |      0,16595 |        0,17
Kugelschreiber |      1,29000 |      1,01946 |        1,02
----------------------------------------------------------

Das alles entscheidende ist die Summe, denn die wird später überwiesen, und sollte also stimmen.

Aus diesem Grund ist dein Ansatz m.E. ein falscher. Entweder du rechnest alle Preis in FWE zusammen und rechnest den Rechnungsbetrag von der FWE in EUR um (so wäre es nach DRS 14 korrekt) oder du rechnest die in EUR umgerechneten Einzelpreise um und addierst sie (was m.E. falsch wäre).

Gut, da die Summe der entscheidende Preis ist (der wird schließlich vom Konto abgebucht), könnte man ja auf die Idee kommen, diesen, bzw. die Gesamtpreise zu speichern, und die Einzelpreise aus den Gesamtpreisen zu errechnen. Heißt also, ich rechne die letzte Spalte um und speichere das, und später errechne ich daraus anhand der Mengen auch die Stückpreise.

IMHO ist es sowieso müßig, Einzelpreis aus einer Fremdwährung in EUR anzugeben, da der maßgebende Tageskurs ständigen Schwankungen unterliegt. Ich würde sogar noch weiter gehen und es als fahrlässig bezeichnen, denn wenn ein gedachter Kunde so eine Lösung von dir bekäme, sind Verlust aus Währungsschwankungen vorprogrammiert. Und ehe der Einwand mit Preisen auf dem ausländischen Markt kommt (a la "aber in Golf kostet in den USA doch 10.000 USD, egal wie der Dollar steht): die Unternehmen, die es so machen, rechnen ihre Preise nicht um, sie _kalkulieren_ in der Fremdwährung.

1. Es wird mit gerundeten Werten multipliziert/dividiert, das führt dazu, dass ein Teil der Informationen verloren geht. Dadurch die Fehler in den Berechnungen mit "Stückpreis x Menge".

Preise gibt man im gewöhnlichen Geschäftsverkehr mit zwei Nachkommastellen an (jaja, ich weiß, die Tankstellen ...). Ein Beispiel:

Preis in FWE: 2,99
Preis in EUR: 3,78 (3,78345)
Zurück nach FWE: 2,99 (2,98726)

2. Es wird nicht das eingegebene Gebot gespeichert, sondern ein gerundetes Ergebnis einer Division. Auch hier gehen Informationen durch die Rundung verloren, die dann für den Anwender zu nicht nachvollziehbaren Werten führen.

Das kannst du nicht vermeiden, du kannst lediglich (ja eigentlich musst du sogar) den Anwender auf die international gültigen Umrechnungsregeln hinweisen.

In der Hoffnung, etwas Licht ins Dunkel gebracht zu haben und wie immer
Freundschaft!
Siechfred

[Eidgenosse]

Hallo Siechfred,

Ich würde sogar noch weiter gehen und es als fahrlässig bezeichnen, denn wenn ein gedachter Kunde so eine Lösung von dir bekäme, sind Verlust aus Währungsschwankungen vorprogrammiert.

Nur der Vollständigkeit halber: Unternehmen, die so etwas tun, haben oft Absicherungsgeschäfte vorgenommen. Und bei richtiger Wahl der Gegenpartei (Rating z. B. AA) gibt's dann auch keinen Ärger mit dem Wirtschaftsprüfer.

Gruß

Eidgenosse

[Andreas Korthaus]

Hallo Siechfred!

Das heißt 1 Fremdwährungseinheit (FWE) = 1,26537 EUR?

Genau, FWE ist besser als XYZ ;-)
Der Kurs ist aus der Luft gegriffen, soll nur "falsche" Ergebnisse provozieren, daher nicht 0,5 oder sowas.

In diesem Fall habe ich die Stückpreise durch den Faktor(Währungskurs = 1,26537) dividiert, auf 5 Stellen gerundet, und damit weiter gerechnet.

Der Weg ist zunächst der richtige, nur die Rundung nicht.

In meinem Fall ist es eine Vorgabe dass sämtliche Preise mit 5 Nachkommastellen angezeigt werden. Aufgrund der großen Mengen ist auch die 5. Nachkommastelle noch wichtig. Ich habe das Problem soweit ich das konnte auf das Kernproblem reduziert. Tatsächlich handelt es sich nicht um einen Währungsfaktor, sondern einen Faktor in den unter anderem ein Währungskurs, aber auch andere Dinge wie Lieferkonditionen einfließen. Aber es ist und bleibt ein Faktor mit 5 Nachkommastellen.

Du müsstest auf 2 Nachkommastellen runden, wie ich es dir bereits schrieb. Danach sähe deine Tabelle so aus:

Artikel    |  Stückpreis  |  Stückpreis  | Stückpreis
               |     (EUR)    |     (FWE)    |  (gerundet)
---------------+--------------+--------------+------------
Bleistift      |      0,55000 |      0,43466 |        0,44
Briefumschlag  |      0,21000 |      0,16595 |        0,17
Kugelschreiber |      1,29000 |      1,01946 |        1,02

Nein, es soll tatsächlich auf eine Genauigkeit von 5 Nachkommastellen gerechnet werden. Hier geht es nicht um eine Rechnung in einem Buchhaltungsprogramm oder sowas, sondern um eine dynamische Preisverhandlung. Entscheidend ist der Endpreis/die Summe. Naja, das ist nicht ganz richtig. Mein Problem wird ja erst dadurch so kompliziert, dass auch Stückpreise und Mengen wichtig sind. Das heißt, die Zahlen werden hinterher in ein System importiert (irgendein SAP-Kram), und dort weiter verwendet. Das heißt, SAP und ich müssen gleich rechnen.

Das alles entscheidende ist die Summe, denn die wird später überwiesen, und sollte also stimmen.

Aus diesem Grund ist dein Ansatz m.E. ein falscher. Entweder du rechnest alle Preis in FWE zusammen und rechnest den Rechnungsbetrag von der FWE in EUR um (so wäre es nach DRS 14 korrekt)

Das dumme ist nur, ich muss auch die Stückpreise in EUR sehen. Wenn das nicht wäre, dann hätte ich das Problem nicht. Wenn ich erstmal die Summe in FWE errechne, kann ich auch die Gesamtpreise (jeweils Stückpreis x Menge) errechnen (die Summe der Gesamtpreise sollte ja stimmen), dann könnte ich diese Gesamtpreise in EUR umrechnen, und davon die Stückpreise zurückrechnen. Aber dann bekomme ich eben das Problem, das die so errechnete Tabelle in EUR aufgrund von Rundungsdifferenzen in sich nicht schlüssig ist.

oder du rechnest die in EUR umgerechneten Einzelpreise um und addierst sie (was m.E. falsch wäre).

ja.

IMHO ist es sowieso müßig, Einzelpreis aus einer Fremdwährung in EUR anzugeben, da der maßgebende Tageskurs ständigen Schwankungen unterliegt. Ich würde sogar noch weiter gehen und es als fahrlässig bezeichnen, denn wenn ein gedachter Kunde so eine Lösung von dir bekäme, sind Verlust aus Währungsschwankungen vorprogrammiert.

Das ist irrelevant. Der Kurs(eigentlich der Faktor) wird am Anfang festgelegt und bleibt so. Das ist so festgelegt. Und das funktioniert auch so in der Praxis.

Und ehe der Einwand mit Preisen auf dem ausländischen Markt kommt (a la "aber ein Golf kostet in den USA doch 10.000 USD, egal wie der Dollar steht): die Unternehmen, die es so machen, rechnen ihre Preise nicht um, sie _kalkulieren_ in der Fremdwährung.

Bei mir ist es so, dass die Anwender Firmen sind, aus verschiedenen Ländern. Die eine aus USA, die andere aus D. Die erste soll Preise in USD sehen und eingeben (ein entsprechender Wechselkurs wird in den Faktor eingerechnet), der andere sieht und gibt Preise in EUR ein. Jeder gibt seine eigenen Stückpreise in seiner Währung ein, und ich sehe jetzt beide Eingaben (mit Stückpreisen), ggfs. umgerechnet in EUR. Bei der Firma aus D. kein Problem, bei der Firma aus USA bestehen die besagten Probleme, nämlich dass entweder meine Tabelle in EUR inkonsistent ist, oder meine und seine Summe nicht entsprechend dem festgelegten Währungskurs/Faktor übereinstimmen. Wenn dagegen meine Tabelle und die Summen stimmen, wird seine Tabelle inkonsistent (er sieht andere Preise als eingegeben)...

Preise gibt man im gewöhnlichen Geschäftsverkehr mit zwei Nachkommastellen an (jaja, ich weiß, die Tankstellen ...).

Das ist kein gewöhnlicher Geschäftsverkehr, erheblich ungewöhnlicher als Tankstellen ;-)

Ein Beispiel:

Preis in FWE: 2,99
Preis in EUR: 3,78 (3,78345)
Zurück nach FWE: 2,99 (2,98726)

Ja, swoeit noch ganz einfach, schwieriger wird es wenn Du noch eine Menge dazu nimmst, z.B.

Menge: 32,56 Liter

Gesamtpreis in FWE:
2,99 FWE/L * 32,56 L = 97,35 FWE

Gesamtpreis in EUR:
97,35 FWE * 1,26537 EUR/FWE = 123,08 EUR

Stückpreis in EUR:
123,08 EUR / 32,56 L = 3,78 EUR/L

Wunderbar! Schnell nochmal mit dem Taschenrechner kontrollieren:

123,08 EUR / 1,26537 EUR/FWE = 97,27 FWE != 97,35 FWE

Da stimmt dann wohl was nicht. Genau da liegt mein Problem. Und es ist wohl mathematisch nicht lösbar, ganz einfach aufgrund des Informationsverlustes beim Runden.

2. Es wird nicht das eingegebene Gebot gespeichert, sondern ein gerundetes Ergebnis einer Division. Auch hier gehen Informationen durch die Rundung verloren, die dann für den Anwender zu nicht nachvollziehbaren Werten führen.

Das kannst du nicht vermeiden, du kannst lediglich (ja eigentlich musst du sogar) den Anwender auf die international gültigen Umrechnungsregeln hinweisen.

Mal bezogen auf das 2,99 -Beispiel oben, bei dem was Du gerechnet hast, sind mir die Regeln klar. Aber der Fehler passiert ja erst bei dem was ich gerechnet habe, und da ist es mir nicht mehr klar. Natürlich zählt in der Rechnungslegung nur der Endpreis, entsprechend umgerechnet..., in diesem Fall geht es aber nicht um externes Rechnungslegung, sondern eher um eine betriebswirtschafltiche Kalkulation, internes Rechnungswesen. Es interessieren auch die Stückpreise. Und die interessieren mich nur in meiner vorgegebenen Referenz-Währung. Das Problem ist, das anscheinend andere Programme identisch mit sowas umgehen, ich aber nicht weiß woran genau die sich orientieren.

In der Hoffnung, etwas Licht ins Dunkel gebracht zu haben und wie immer

Hat mir in jedem Fall geholfen, auch wenn ich von der wahren Erleuchtung noch ein bisschen entfernt bin, glaube ich ;-)

Viele Grüße
Andreas

[Sven Rautenberg]

Moin!

Ich habe eine Art "Kalkulations-Tabelle", die in verschiedenen Währungen angezeigt werden muss.

Es wird schon seinen Grund haben, warum es auf der Welt US-Dollar und Euro als Leitwährungen gibt. Ein Aspekt ist natürlich eine gewisse Sicherheit gegenüber Währungsschwankungen. Aber ganz sicher ist ein zweiter Aspekt auch, dass man nur dann eine verlässliche Preisgestaltung erreicht, wenn sich Vertragspartner darauf verständigen, in EINER Währung abzurechnen.

Dein Problem ist grundsätzlich nicht mit Mathematik lösbar. Egal wie du es drehst und wendest, es werden dir immer Rundungsdifferenzen entstehen, wenn du als eine Rechnungsalternative die Summe der Einzelpositionen zuerst umrechnest, rundest und dann addierst, oder zuerst addierst und dann umrechnest und rundest - und diese Differenz ist halt irgendwie zu behandeln.

Das Gleiche spielt sich ja bei der Mehrwertsteuer auch ab: Rechnet man diese von einem unglücklichen Bruttopreis herunter, können gerundete Nettopreise entstehen, die ihrerseits mit addierter Mehrwertsteuer den Bruttopreis nicht erreichen oder übertreffen (Abweichung: 1 kleinste Währungseinheit, bei Rundung auf zwei Nachkommastellen also 0,01 - sofern die Währung in hundert Bruchteile gestückelt ist. Die dänische Krone beispielsweise stückelt nur noch auf x,00; x,25; x,50 und x,75 - und die Dänen leben immer noch, trotz der täglich auftretenden Rundungen, denn die Preise sind natürlich nicht so gestückelt).

Im Prinzip mußt du selbst dich entscheiden, wie du mit diesen Rundungsfehlern umgehen willst. Klar ist dabei eigentlich nur eines: Egal wie die Summe der Einzelpreise auch entsteht - irgendwann wird unten auf der Rechnung ein Endpreis (ob nun mit oder ohne Steuer) herauskommen, und genau den muß der Kunde bezahlen, und genau den mußt du als Einnahme verbuchen - nichts anderes.

Wenn du also Ausgangspreise in Euro hast, und einem Kunden Dollarpreise präsentieren willst, dann hast du eine grundsätzliche Entscheidung zu treffen: Gibst du für alle Produkte einen aufgrund des Währungskurses berechenbaren Preis "informationshalber" aus, rechnest intern aber weiter in Euro bis hin zur Endsumme, welche dann umgerechnet wird in Dollar (alternativ kannst du dir die Rechnung natürlich auch in Euro bezahlen lassen, dann liegt das Wechselkursrisiko beim Kunden) - oder rechnest du die Artikelpreise alle in einen festen Dollarpreis um, und summierst dann die Einzelpreise in Dollar, wenn die Endsumme in Dollar abgerechnet werden soll.

Beide Verfahren sind in meinen Augen legitim. Das zweite Verfahren hat den Vorteil, dass du den Vorgang "Ich hab aber eigentlich Europreise" dem Kunden verborgen bleibt, weil er die umgerechneten Preise tatsächlich summieren und nachrechnen kann, und alles aufgeht, und den Nachteil, dass du für jedes Produkt und jede Währung einen eigenen Preis speichern und behandeln mußt. Das erste Verfahren hat den Vorteil, dass du tatsächlich nur einen wirklichen Produktpreis hast, der von allen Kunden bezahlt wird, aber unweigerlich auf Rundungsfehler stößt.

Wenn man aber davon ausgeht, dass es vielleicht keine schlechte Idee ist, je Währung doch noch etwas flexibler reagieren zu können und manuell an den Preisen zu schrauben (kann ja sein, dass ein optisch attraktive Schwellenpreis auch in der Dollarwährung ausgenutzt werden soll), dann bleibt dir ohnehin nur das zweite Verfahren übrig. Dass dir die Kunden da aufs Dach steigen, würde ich nicht vermuten. Die Preisgestaltung ist ausschließlich deine Sache als Verkäufer. Wer sich als Dollarzahler schlechter gestellt sieht, der kann ja gerne in Euro zahlen, wenn er meint, dadurch Geld zu sparen, und umgekehrt.

Muss man mit diesen Unstimmigkeiten leben, oder gibt es eine Möglichkeit dass alle Werte stimmen? Oder gibt es irgendwo Normen/Vorschriften/Standards wie man solche Umrechnungen zu machen hat? Oder hat jemand Ideen für einen ganz anderen Ansatz? Im Moment beißt sich die Katze in den Schwanz...

Der Ansatz ist die freie Preisgestaltung. Du kannst als Preis nehmen, was du gerne willst. Du kannst in Euro mehr oder weniger nehmen, als in Dollar. Solange der Kunde den Preis bezahlt, sollte das keine großen Probleme machen. :)

- Sven Rautenberg

[Andreas Korthaus]

Hallo!

Dein Problem ist grundsätzlich nicht mit Mathematik lösbar.

Das hatte ich befürchtet ;-)

Im Prinzip mußt du selbst dich entscheiden, wie du mit diesen Rundungsfehlern umgehen willst. Klar ist dabei eigentlich nur eines: Egal wie die Summe der Einzelpreise auch entsteht - irgendwann wird unten auf der Rechnung ein Endpreis (ob nun mit oder ohne Steuer) herauskommen, und genau den muß der Kunde bezahlen, und genau den mußt du als Einnahme verbuchen - nichts anderes.

Bei der Software geht es nicht um den Verkauf einer Ware. Hier werden Preise unterschiedlicher Anwender(Anbieter/Hersteller) mit unterschiedlichen Faktoren "belastet". Letztendlich gebucht werden verschiedene Leistungen, die in die Faktoren eingerechnet sind... außerdem werden kalkulatorische Posten eingerechnet... ist wirklich kompliziert zu erklären. Jedenfalls sind die Preise die ich dann erhalte kalkulatorische Preise, die (durch den Faktor) auf eine betriebswirtschaftlich vergleichbare Basis gebracht werden. Dass man hier auch Wechselkurse einrechnen kann ist ein Nebeneffekt, nur ist das Problem an diesen einfacher nachzuvollziehen. Was der Faktor letztendlich bedeutet ist ja für die Darstellung/Berechnung nicht so wichtig.

Wenn du also Ausgangspreise in Euro hast, und einem Kunden Dollarpreise präsentieren willst, dann hast du eine grundsätzliche Entscheidung zu treffen: Gibst du für alle Produkte einen aufgrund des Währungskurses berechenbaren Preis "informationshalber" aus, rechnest intern aber weiter in Euro bis hin zur Endsumme, welche dann umgerechnet wird in Dollar

Das Währungsrisiko kann ich zum Glück komplett ignorieren.
Es ist so, dass ich als Ausgangspreis EUR habe. USD soll eine Hilfestellung sein, allerdings soll es wirklich transparent sein. Das Problem ist, nicht ich gebe den Preis an, sondern der Benutzer. Der gibt dann meinetwegen einen USD-Stückpreis mit 5 Nachkommastellen an. daraus berechnet sich dann in seiner Tabelle mit den Mengen je ein Gesamtpreis und darüber die Summe. Diese Tabelle, die will _ich_ jetzt in EUR sehen, ebenfalls mit 5 Nachkomastellen. Die Tabelle soll in sich ebenfalls konsistent sein, und meine Summe soll gemäß dem Kurs mit der Summe des Amerikaners überein stimmen. Dies ist aber mathematisch nicht möglich, jedenfalls wüsste ich nicht wie.

oder rechnest du die Artikelpreise alle in einen festen Dollarpreis um, und summierst dann die Einzelpreise in Dollar, wenn die Endsumme in Dollar abgerechnet werden soll.

Das gibt garantiert Probleme bei der Endsumme.

Beide Verfahren sind in meinen Augen legitim. Das zweite Verfahren hat den Vorteil, dass du den Vorgang "Ich hab aber eigentlich Europreise" dem Kunden verborgen bleibt, weil er die umgerechneten Preise tatsächlich summieren und nachrechnen kann, und alles aufgeht, und den Nachteil, dass du für jedes Produkt und jede Währung einen eigenen Preis speichern und behandeln mußt. Das erste Verfahren hat den Vorteil, dass du tatsächlich nur einen wirklichen Produktpreis hast, der von allen Kunden bezahlt wird, aber unweigerlich auf Rundungsfehler stößt.

Hm, vom Regen in die Traufe... ;-)

Der Ansatz ist die freie Preisgestaltung. Du kannst als Preis nehmen, was du gerne willst. Du kannst in Euro mehr oder weniger nehmen, als in Dollar. Solange der Kunde den Preis bezahlt, sollte das keine großen Probleme machen. :)

Das Problem ist, dass es genau anders herum läuft:
ICH will einen bestimmten Artikel kaufen/herstellen lassen. Daher frage ich verschiedene Firmen nach deren Preisen. Im Prinzip eine Ausschreibung. Ich will aber am Ende nicht nur den Gesamtpreis wissen, sondern will unter anderem für meine Kostenrechnung auch die Einzelpreise in mein SAP-System einlesen. Und dann stehe ich vor dem Problem, der Amerikaner hat schön Einzelpreise in USD angegeben und ich will die Einzelpreise in EUR in SAP einlesen, und am Ende soll dieselbe Summe da rauskommen, wie sie tatsächlich aufgrund der USD-Summe(umgerechnet in EUR mit angegebenem Kurs) des Amerikaners von meinem Konto abgebucht wird. In meinen Augen ist das nicht möglich. Oder? (Angeblich schon...)

Viele Grüße
Andreas

[Siechfred]

Hallo Andreas.

Ich antworte dir mal hier.

ICH will einen bestimmten Artikel kaufen/herstellen lassen. Daher frage ich verschiedene Firmen nach deren Preisen. Im Prinzip eine Ausschreibung. Ich will aber am Ende nicht nur den Gesamtpreis wissen, sondern will unter anderem für meine Kostenrechnung auch die Einzelpreise in mein SAP-System einlesen.

Da haben wir es doch. Wenn es das ist, dann liegst du mit dem DRS 14 goldrichtig, alles andere ist entsprechend der gültigen nationalen und internationalen Regeln falsch. Dass die Vorgaben des DRS 14 nicht mathematischen sondern kaufmännischen Grundsätzen folgt, bestätigt deine Vermutung, dass es mathematisch nicht auflösbar ist.

Und dann stehe ich vor dem Problem, der Amerikaner hat schön Einzelpreise in USD angegeben und ich will die Einzelpreise in EUR in SAP einlesen, und am Ende soll dieselbe Summe da rauskommen, wie sie tatsächlich aufgrund der USD-Summe(umgerechnet in EUR mit angegebenem Kurs) des Amerikaners von meinem Konto abgebucht wird. In meinen Augen ist das nicht möglich. Oder? (Angeblich schon...)

Du willst eine Fremdwährungskalkulation in EUR nachvollziehen, verstehe ich dich da richtig? Wenn ja, verstehe ich (noch) nicht den Sinn des Ganzen.

Freundschaft!
Siechfred

[Andreas Korthaus]

Hallo Siechfred!

ICH will einen bestimmten Artikel kaufen/herstellen lassen. Daher frage ich verschiedene Firmen nach deren Preisen. Im Prinzip eine Ausschreibung. Ich will aber am Ende nicht nur den Gesamtpreis wissen, sondern will unter anderem für meine Kostenrechnung auch die Einzelpreise in mein SAP-System einlesen.

Da haben wir es doch. Wenn es das ist, dann liegst du mit dem DRS 14 goldrichtig, alles andere ist entsprechend der gültigen nationalen und internationalen Regeln falsch. Dass die Vorgaben des DRS 14 nicht mathematischen sondern kaufmännischen Grundsätzen folgt, bestätigt deine Vermutung, dass es mathematisch nicht auflösbar ist.

Hm. Bisher habe ich zu "DRS 14" nur Zusammenfassungen gefunden, die meiner Meinung nach keine zusätzlichen, für mich relevanten Regeln enthalten.
Wie würde denn die entscheidende Regel gemäß DRS 14 aussehen? SAP weiß nichts davon dass die Preise in ein System in USD eingegeben wurden, es bekommt nur die EUR-Preise von mir. Wenn ioch jetzt 5 Nachkommastellen habe, und mal vorgebe dass die Summe exakt stimmen muss, kann es keinen Stückpreis geben, der mit der Menge multipliziert exakt den umgerechneten Gesamtpreis ergibt (ich hoffe Du konntest mir folgen ;-)).
Außerdem stellt die Währung nur eine Komponente des tatsächlichen Faktors dar...
Ich denke ich drehe mich hier im Kreis. So wie ich es glaubte verstanden zu haben, kann es mathematisch nicht funktionieren. An irgendeiner Stelle muss es was geben was ich nicht weiß. Vielleicht werden ja originale Preise und entsprechender faktor in SAP eingelesen, oder sonstwas.

Und dann stehe ich vor dem Problem, der Amerikaner hat schön Einzelpreise in USD angegeben und ich will die Einzelpreise in EUR in SAP einlesen, und am Ende soll dieselbe Summe da rauskommen, wie sie tatsächlich aufgrund der USD-Summe(umgerechnet in EUR mit angegebenem Kurs) des Amerikaners von meinem Konto abgebucht wird. In meinen Augen ist das nicht möglich. Oder? (Angeblich schon...)

Du willst eine Fremdwährungskalkulation in EUR nachvollziehen, verstehe ich dich da richtig? Wenn ja, verstehe ich (noch) nicht den Sinn des Ganzen.

Ja, genau das. Wie gesagt hat das wenig mit externem Rechnungswesen zu tun, es geht im "Managenment-Auswertungen"... da kommen die Leute halt schonmal auf solche Ideen. Wie das allerdings zur Zeit funktionieren kann (die machen das so!), ist mir noch ein Rätsel.

Grüße
Andreas

[Siechfred]

Hallo Andreas.

Hm. Bisher habe ich zu "DRS 14" nur Zusammenfassungen gefunden, die meiner Meinung nach keine zusätzlichen, für mich relevanten Regeln enthalten. Wie würde denn die entscheidende Regel gemäß DRS 14 aussehen?

Da der endgültige Standard nur kostenpflichtig eingesehen werden kann, hier mal ein Link zum Entwurf: http://www.standardsetter.de/drsc/docs/drafts/18.html.

Es kommt natürlich erst einmal darauf an, ob du bzw. dein Kunde sich an den DRS 14 halten muss oder will. Falls ja, ist die wichtigste Frage, welches die funktionale Währung des Unternehmens ist, also die Währung des wirtschaftlichen Umfeldes, in dem das Unternehmen überwiegend tätig ist. Danach richtet sich, was wie umzurechnen ist, nach der Umrechnung richtet sich auch, ob Währungsdifferenzen entstehen, die ggf. gewinnwirksam zu erfassen sind.

Wie gesagt hat das wenig mit externem Rechnungswesen zu tun, es geht im "Managenment-Auswertungen"... da kommen die Leute halt schonmal auf solche Ideen.

Hm, was soll denn Ziel bzw. Aussage der Auswertungen sein?

Freundschaft!
Siechfred

[Andreas Korthaus]

Hallo!

Da der endgültige Standard nur kostenpflichtig eingesehen werden kann, hier mal ein Link zum Entwurf: http://www.standardsetter.de/drsc/docs/drafts/18.html.

Hm, darin finde ich weder das Wort "komma", noch "stelle", noch "dezimal"...
Das sind alles allgemeine Vorgaben, ich finde nichts darüber, wie man jetzt tatsächlich/mathematisch rechnen soll, also so Sachen wir " auf 2. Nachkommastelle runden...", wie Du es gesagt hast.

Es kommt natürlich erst einmal darauf an, ob du bzw. dein Kunde sich an den DRS 14 halten muss oder will.

Ja, ist das denn die Frage? Wie gesagt will ich keine Rechnung daraus generieren, die dann irgendwo ordnungsgemäß gebucht wird, sondern ich Preise durch dynamische Faktoren auf eine gemeinsame/vergleichbare Basis bringen. Hierbei sollten die Berechnungen in sich konsistent sein.

Falls ja, ist die wichtigste Frage, welches die funktionale Währung des Unternehmens ist, also die Währung des wirtschaftlichen Umfeldes, in dem das Unternehmen überwiegend tätig ist. Danach richtet sich, was wie umzurechnen ist, nach der Umrechnung richtet sich auch, ob Währungsdifferenzen entstehen, die ggf. gewinnwirksam zu erfassen sind.

Das geht in meinem Fall so oder so nicht, da der Faktor nicht nur einen Währungskurs enthält, sondern weitere Komponenten, womit sowas gar nicht mehr möglich ist.

Wie gesagt hat das wenig mit externem Rechnungswesen zu tun, es geht im "Managenment-Auswertungen"... da kommen die Leute halt schonmal auf solche Ideen.

Hm, was soll denn Ziel bzw. Aussage der Auswertungen sein?

Man hat dann viele Daten aus denen man irgendwelche tollen Auswertungen/Analysen/Trends ableiten kann...

Grüße
Andreas

[Richard Rüfenacht]

Hallo Andreas,

doch, es ist ein rein mathematische Problem und auf diesem Wege auch lösbar. Es ist prinzipiell unmöglich mit einem Faktor, der selbst nur auf 5 Stellen hinter dem Komma genau ist, auf eine Genauigkeit von 5 Stellen hinter dem Komma zu rechnen. Nach deiner Rechnung ist das Ergebnis auf 2, allenfalls 3 Stellen hinter dem Komma genau. Wenn du auf wirklich 5 Nachkommastellen genau rechnen willst, muss dein Faktor mindestens auf 10 Stellen, sicherer 11 Stellen nach dem Komma genau sein (Nullen anhängen gilt nicht, das erhöht nicht die Genauigkeit!). Ich habe das schnell mal mit einem Faktor mit 7 Nachkommastellen gerechnet, dann sind sicher 3 Stellen hinter dem Komma genau. Du kannst das ja mal nachrechnen.

Ob das wirklich sinnvoll ist, vermag ich nicht zu beurteilen. Ich würde mich entweder mit drei Stellen hinter dem Komma zufrieden geben (wobei bei der letzten Stelle Differenzen in Kauf genommen werden), oder schlicht den Umrechnungsfaktor neu berechnen und die Sache so stimmig machen. Es ist einfach eine Frage, wie gross die Abweichungen sein dürfen.

Beste Grüsse

Richard

[Richard Rüfenacht]

Hallo Andreas,

nun wollte ich doch die Probe aufs Exempel machen und der Theorie die Praxis, oder der Behauptung den Beweis folgen lassen:

Deinen Umrechnungsfaktor habe ich von 2,26537 auf 1,26536981547 erweitert, damit gerechnet ergibt sich:

447,853262298729 (65,19833094751 + 199,15126543966 + 183,50366660012)

566,70000 / 1,26536981547 = 447,853262399427

also auf 5 Nachkommastellen: 447,85326 = 447,85326

447,853262298729 * 1,26536981547 = 566,70000074386

also auf 5 Nachkommastellen: 566,70000 = 566,70000

So geht es, so stimmt es.

Liebe Grüsse aus dem http://www.emmental.ch

Richard

[Richard Rüfenacht]

Hallo Andreas,

Deinen Umrechnungsfaktor habe ich von 2,26537 auf 1,26536981547 erweitert, damit gerechnet ergibt sich:

müsste natürlich heissen von 1,26537 auf ...

Hoffentlich sind mir nicht noch mehr Tippfehler unterlaufen ;-)

Gruss Richard

[Richard Rüfenacht]

Hallo Andreas,

mit einer Behauptung habe ich mich zu später Nachststunde etwas verrannt. Der Umrechnungsfaktor selbst kann auch nur 5 Nachkommastellen haben, nur beim Rechnen damit sind dann mindestens 10 Stellen erforderlich. Erst am Schluss der ganzen Rechnung erfolgt dann die Rückkehr zu 5 Nachkommastellen. So werden entsprechende Rundungsfehler vermieden.

Einen schönen Gruss

Richard

[Andreas Korthaus]

Hallo!

mit einer Behauptung habe ich mich zu später Nachststunde etwas verrannt. Der Umrechnungsfaktor selbst kann auch nur 5 Nachkommastellen haben, nur beim Rechnen damit sind dann mindestens 10 Stellen erforderlich. Erst am Schluss der ganzen Rechnung erfolgt dann die Rückkehr zu 5 Nachkommastellen. So werden entsprechende Rundungsfehler vermieden.

Nein, so wird der Rundungsfehler einfach nach hinten verschoben, so dass er in diesem Beispiel nicht mehr auffällt. Mit anderen Zahlen kann er aber wieder auftauchen.

Grüße
Andreas

[Richard Rüfenacht]

Hallo Andreas

Nein, so wird der Rundungsfehler einfach nach hinten verschoben, so dass er in diesem Beispiel nicht mehr auffällt.

Das ist richtig. Aber der Rundungsfehler verliert so seine Bedeutung.

Mit anderen Zahlen kann er aber wieder auftauchen.

Auch mit allen anderen Zahlen wird der Rundungsfehler in keinem Fall innerhalb der ersten 5 Nachkommastellen liegen. Damit ist er für deine Rechnung nicht mehr relevant.

Wenn du nach DRS 14 rundest (ist für Bilanzen vorgesehen und sehr ungenau) wird die Rechnung noch schwerer vergleichbar.

US_Wert / Faktor != EU_Wert * Faktor  war zurecht dein Kritikpunkt.
Diese Werte sind aber immer nur annähern gleich, solange die Zahlen nicht ohne Rest teilbar sind. Das kannst du nicht durch andere Rundungsregeln lösen, sondern nur durch genaueres Rechnen. Wenn dir für den Vergleich 5 Nachkommastellen ausreichend sind, spielt es doch keine Rolle, wenn bei der 7. Nachkommastellen keine Übereinstimmung mehr besteht.

Allenfalls hättest du noch die Möglichkeit in umgekehrter Reihenfolge zu rechnen, also den Stückpreis durch Division aus dem Gesamtpreis zu errechnen. Dann weicht der Gesamtpreis wenigstens nicht voneinander ab.

Beste Grüsse

Richard

[Andreas Korthaus]

Hallo Richard!

Diese Werte sind aber immer nur annähern gleich, solange die Zahlen nicht ohne Rest teilbar sind. Das kannst du nicht durch andere Rundungsregeln lösen, sondern nur durch genaueres Rechnen. Wenn dir für den Vergleich 5 Nachkommastellen ausreichend sind, spielt es doch keine Rolle, wenn bei der 7. Nachkommastellen keine Übereinstimmung mehr besteht.

Ja, so langsam denke ich dass es doch daraus hinaus laufen wird. Eigentlich hatte ich es auch so gemacht, mich hatte aber eine Tatsache verwirrt:

Der Anwender hat gesagt, es würde in der Software genau so gerechnet, wie SAP, wenn die Daten dort eingelesen werden. Ich war dabei davon ausgegangen, dass SAP nur diese 5 Nachkommastellen bekommt, womit dort ein anderes Ergebnis rauskommen muss, gegenüber meiner Software, die ja tatsächlich mit 14 Stellen rechnet.

Ich ging weiter davon aus, dass wenn man in der Software mit Taschenrechner nachrechnet, dass mit den auf 5 Stellen gerundeten Werten das korrekte Ergebnis herauskommt.

Inzwischen zweifele ich, dass das so ist. Angenommen die Daten werden per Excel in SAP importiert, und in Excel werden 5 Nachkommastellen dargestellt, aber in Wirklichkeit 10 Stellen gespeichert, und angenommen auch SAP rechnet dann mit diesen genaueren Werten, dann passt ja wieder alles zusammen.

Kein Mensch wird das mit dem taschenrechner nachrechnen, sondern nur mit Excel. Und wenn das funktioniert, kann ich den Anwender verstehen wenn er sagt "bei uns gibt es keine Rundunksfehler, das geht alles auf...". Kann mir zwar nicht so richtig vorstellen dass SAP so viele Nachkommastellen verwendet, aber mal sehen.

Ich werde mir mal die ungünstigsten Konditionen überlegen, und so viele Nachkommastellen in der DB, in PHP und im Excel-Export verwenden, dass es keine Probleme mehr gibt. Ich hatte zwar gehofft dass man es irgendwie anders lösen kann, aber ich wüßte nicht wie.

Allenfalls hättest du noch die Möglichkeit in umgekehrter Reihenfolge zu rechnen, also den Stückpreis durch Division aus dem Gesamtpreis zu errechnen. Dann weicht der Gesamtpreis wenigstens nicht voneinander ab.

Ich hoffe dass es ausreicht entsprechend viele Nachkommastellen zu verwenden. Ich überlege wie gesagt auch den "originalen" Preis in der Fremdwährung zu speichern, denn dann speichere ich nicht schon einen krummen Wert, sondern maximal 5 Nachkommastellen. Dann kann ich auf dieser Basis Rechnen, dabei sollte es in der Fremdwährung keine Probleme geben, und die Umrechnung in EUR kann ich dann von dem dynamisch zusammengrechneten Gesamtpreis in Fremdwährung ausrechnen. Hätte also dieselbe Genauigkeit beim Gesamtpreis, und die Garantie dass der Eingegebene Preis nicht einem Rundungsfehler zum Opfer fällt, und so evtl. anders angezeigt wird als tatsächlich eingegeben.

Nur würde dadurch die Berechnung zur Laufzeit aufwändiger, und nicht nur hier, sondern auch für jede spätere Auswertung die mal aus den Daten gezogen werden soll.

Bleibt mir wohl nichts anderes übrig als das ein bisschen auszutesten (oder ist hier irgendein Mathe-Student der mir mal eben berechnen/beweisen kann, wieviele Nachkommastellen ich im ungünstigsten Fall bei der jeweiligern Variante benötige... der Teil von Mathematik war noch nie meine Stärke ;-))

Grüße
Andreas

[bernd]

Hi,

Bleibt mir wohl nichts anderes übrig als das ein bisschen auszutesten (oder ist hier irgendein Mathe-Student der mir mal eben berechnen/beweisen kann, wieviele Nachkommastellen ich im ungünstigsten Fall bei der jeweiligern Variante benötige... der Teil von Mathematik war noch nie meine Stärke ;-))

im ungünstigsten Fall kannst du die Nachkommastellen nicht berechnen, z.B. beim Umrechnungsfaktor 0.9, hättest du
auch drauf kommen können;).
Du brauchst auch keinen Mathematiker oder eine größere Maschine (Earth II) sondern einen, der sich mit Wirtschaft und Verkauf auskennt. 150 WE kosten niemals 150 * Einzelpreis :D.

bernd