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.
- 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
SELFHTML Linkverzeichnis: http://aktuell.de.selfhtml.org/links/