Waehrung und Umrechnungskurse

[Sympathisant]

Hai,

ich schreibe derzeit ein Programm zur Verrechnung von auftgetretenen Kosten fuer ein Resort - unter Kosten darf man jetzt nicht zu viel verstehen, es handelt sich hierbei lediglich um die Verrechnung von Getraenken und kleineren Speisen. Hier - auf den Philippinen - ist der philippinische Peso die Waehrung. Die Gaeste koennen jedoch sowohl in EUR als auch in $ bezahlen (auch australischer $).

Folglich habe ich eine Tabelle, die die aktuellen Umrechnungskurse beinhaltet (mit Versionierung, damit auch noch zu einem spaeteren Zeitpunkt - also nach Anpassung des Kurses - die Rechnung so erstellt werden kann, dass am Ende wieder der exakte Endpreis berechnet wird).

Nun moechte ich das Programm nicht auf ein Land / eine Waehrung beschraenken, sondern den Aufbau natuerlich vorausschauend fuer weitere, moegliche Laender planen.

Nun stellt sich mir die Frage, wie man so etwas angeht. Es bedarf ja einer "Grundwaehrung", an der man sich orientiert. An der zB die Wechselkurse definiert werden. Bisher habe ich immer nur Software fuer ein spezielles Land geschrieben. Und in Europa war natuerlich der EUR die Grundwaehrung. Und an dieser Waehrung hat man sich dann orientiert.

Das, was die Anwender sehen, und das, was in der Datenbank steht bzw. auf welche Weise der Code die korrekten Preise berechnet, sind ja zwei verschiedene Paar Schuhe. Kann man daher zb den Dollar ans Grundwaehrung nehmen, so dass sich folglich alle anderen Waehrungen an dem Dollar orientieren?

MfG,
Sympatisant

[Paul]

Hi,

Es bedarf ja einer "Grundwaehrung", an der man sich orientiert...

warum?

Das, was die Anwender sehen, und das, was in der Datenbank steht bzw. auf welche Weise der Code die korrekten Preise berechnet, sind ja zwei verschiedene Paar Schuhe. Kann man daher zb den Dollar ans Grundwaehrung nehmen, so dass sich folglich alle anderen Waehrungen an dem Dollar orientieren?

Nein, wie sollte das auch gehen?

Hast du einen Denkfehler oder verstehe ich deine Frage nicht?

Paul

[Sympathisant]

Hai Paul,

es kann gut sein, dass ich einen Denkfehler habe. Das passiert mir schon manchmal wenn ich zu lange ueber ein Problem nachgruebel.

Ich versuche es nochmal zu erlaeutern, vielleicht klaert es sich dann ja von selbst.

Angenommen, du gibst den Preis fuer Produkt X in EUR an.
Und fuer Produkt Y gibst Du den Preis in $ an.

Die Frage ist jetzt, steht danach in der Datenbank das hier:
name | price | currency_id
X    | 23.00 | 1
y    | 12.00 | 2

Oder folgendes:
name | price | currency_id
X    | 23.00 | 1
y    |  8.00 | 1 <= die Umrechnung hat bereits vorher stattgefunden

Im zweiten Beispiel muesste ich also vor Einfuegen des Datensates in der "exchange_rate" Tabelle nachschauen, wieviel 12 $ in EUR sind, und den entsprechenden Wert in die Tabelle eintragen.
Somit gaebe es hier durchaus eine Grundwaehrung, naemlich die mit der ID 1.

Ja, das war auch gerade meine Frage.

Danke & MfG,
Sympatisant

[Maxx]

Hallo,

Die Frage ist jetzt, steht danach in der Datenbank das hier:
name | price | currency_id
X    | 23.00 | 1
y    | 12.00 | 2

Oder folgendes:
name | price | currency_id
X    | 23.00 | 1
y    |  8.00 | 1 <= die Umrechnung hat bereits vorher stattgefunden

ganz klar ersteres. Im unten aufgeführten Fall kannst du u.U. den Originalbetrag von 12.00 aus den in der Datenbank gespeicherten 8.00 durch Rundungsdifferenzen und abschneiden von Nachkommastellen nicht mehr rekonstruieren.

Nicht desto trotz würde ich eine Art von Basiswährung im Programm führen.
Und sei es nur um die Eingabe eines Betrags zu vereinfachen. Wenn nur eine Angabe zum Betrag (ohne Währung) gemacht wird, dann ist das eben in dieser "Basiswährung".

Und noch so am Rande, aus Lesbarkeitsgründen ist es häufig sinnvoller statt einer WährungsID den ISO-Code zu speichern. Glaub mir ;-)

Grüße,

Jochen

[Sympathisant]

Hai Jochen,

danke fuer deine Antwort.

ganz klar ersteres. Im unten aufgeführten Fall kannst du u.U. den Originalbetrag von 12.00 aus den in der Datenbank gespeicherten 8.00 durch Rundungsdifferenzen und abschneiden von Nachkommastellen nicht mehr rekonstruieren.

Hier kaeme dann ja die von mir im ersten Posting erwaehnte Historiserung ins Spiel. Jede Aenderung an den Umwechlungskursen wird protokolliert und mit einem Datum versehen. Da zusaetzlich jede Buchung von Haus aus bereits mit einem Datum versehen wird, laesst sich das anhand dieser Daten wieder leicht reproduzieren. Ach so, sorry, habe jetzt erst verstanden was du genau meinst. Nun, das haengt dann ja davon ab, wie bzw. ob man die Daten bei der Ausgabe dann wieder "rueckrechnen" muss oder nicht. Aber ich verstehe deinen Einwand und er ist durchaus berechtigt. Aber die erste Variante missfaellt mir ein wenig, da dann ein staendiges Hin und Her der Waherung existiert (zumindest in der DB).

Und noch so am Rande, aus Lesbarkeitsgründen ist es häufig sinnvoller statt einer WährungsID den ISO-Code zu speichern. Glaub mir ;-)

Ja, das Problem hatte ich auch schon ein paar Male. Sollte ich dieses mal vielleicht tatsaechlich mal machen ;-)

MfG,
Sympatisant

[Maxx]

Hallo,

Nun, das haengt dann ja davon ab, wie bzw. ob man die Daten bei der Ausgabe dann wieder "rueckrechnen" muss oder nicht. Aber ich verstehe deinen Einwand und er ist durchaus berechtigt. Aber die erste Variante missfaellt mir ein wenig, da dann ein staendiges Hin und Her der Waherung existiert (zumindest in der DB).

klar, je nach Anwendung. Das kannst nur du beantworten.
Für die Anwendungen an denen ich rumschraub ist die Originalwährung unabdingbar. Im Grundbuch zum Beispiel stehen die Grundschulden (bis 2002) in DEM. Und sie werden auch weiterhin als DEM in Verträgen aufgeführt.

Grüße,

Jochen

[Siechfred]

Nun stellt sich mir die Frage, wie man so etwas angeht. Es bedarf ja einer "Grundwaehrung", an der man sich orientiert.

Ich würde hier von der Währung ausgehen, die dem Geschäft zugrunde liegt. Machst Du sowas für die Philippinen, wäre es also der Peso, machst Du sowas für Australien, wäre es der australische Dollar. Den Preis rechnest Du dann in die Zielwährung um.

Falls Du "Grundwährung" im Sinne von Peso -> Grundwährung -> Australischer Dollar meinst, liegst Du m.E. falsch.

Siechfred

[Sympathisant]

Hai Siechfred,

Falls Du "Grundwährung" im Sinne von Peso -> Grundwährung -> Australischer Dollar meinst, liegst Du m.E. falsch.

Ich meine so was wie
Dollar -> Grundwaherung
Eur -> Grundwaehrung
php -> nichts, da Grundwaherung

Ich würde hier von der Währung ausgehen, die dem Geschäft zugrunde liegt. Machst Du sowas für die Philippinen, wäre es also der Peso, machst Du sowas für Australien, wäre es der australische Dollar. Den Preis rechnest Du dann in die Zielwährung um.

Das hiesse, dass ich die Grundwaherung, also jene Waehrung, die in der Datenbank in den Price-Spalten persistiert wird, in einer Konfigurationsdatei definieren kann, so dass das Programm dann auch in Thailand ohne weitere Aufwaende funktionieren kann.

Ja, ich denke das ist eine gute Loesung.

Danke & MfG,
Sympatisant

[Cheatah]

Hi,

Es bedarf ja einer "Grundwaehrung", an der man sich orientiert.

nein, zu jedem[1] Zeitpunkt gibt es einen Faktor x(A,B), der ausreicht, um Währung A in Währung B umzurechnen. Es ist nicht nötig, eine abstrakte Währung zwischenzuschalten.

Cheatah

[1] Üblicherweise. Es mag exotische Situationen geben, in denen dies nicht so ist; meistens dürfte dann an einigen Börsen Chaos herrschen.

[Frank (no reg)]

Hallo,

du siehst da anscheinend ein paar Bäume vor dem Wald. ;)

Nimm doch für jede Buchung (Kauf von irgendwas) die Währung, in der es geschehen ist, € oder $ oder JPY. Für das gesamte System legst du die Basiswährung fest: PHP (So wie Siechfred das auch vorgeschlagen hat).

Dazu ereugst du eine Tabelle ExchangeRate, bestehend aus:
Currency (varchar(3)), RateAsOf (datetime), Rate (numeric 12, 6), Inverted (bit)

RateAsOf ist das Datum für welches der Umtauschkurs gilt;
Rate ist immer der Wert mit dem du multiplizieren oder dividieren musst, um deine Basiswährung zu erhalten;
Inverted gibt an, ob der Kurs invertiert gespeichert ist, so dass du multplizieren statt dividieren musst

Daten wären zum Bleistift:
USD, 12.12.2008, 47.27356, 0
USD, 13.12.2008, 48.20830, 0
JPY, 13.12.2008, 1.87693, 1

Wenn du standardmässig multiplizierst ...
1000 JPY = 1000 / 1.87693 = 532.785 PHP
10 USD = 10 * 48.20830 = 482.083 PHP

Einberechnen solltest du auch evt. anfallende Umtauschgebühren/Kommissionen, falls diese nicht in den Umtauschkurs eingerechnet sind. Diese wären dann u.U. gewichtet auf die einzelnen Buchungen zu verteilen ...

Wenn du aber mit FX Arbitrage Geschäften anfangen willst, brauchst was komplizierteres. ;)

Ciao, Frank

[Sympathisant]

Hai Frank,

du siehst da anscheinend ein paar Bäume vor dem Wald. ;)

Exakt ;-)

[...]

So in etwa schwebte es mir auch vor den Augen, doch nun ist es mir ersichtlich geworden.

Danke euch allen fuer eure Beitraege!

MfG,
Sympatisant

[Daniel Thoma]

Hallo Sympathisant,

Prinzipiell hast Du erstmal, wie Cheatah andeutet, eine Matrix bzw. eine Funktion f(x, y), die zwei Währungen einen Wechselkurs zuordnet.
Ersmtal gilt sicher f(x, y) = 1/f(y,x) womit man sich schonmal die Hälfte sparen kann.
Nun ist noch die Frage, ob f(x, y) = f(x,z) * f(z,y) gilt. In diesem Fall könnte man eine beliebige Basiswährung einführen und müsste für jede Währung nur den Wechselkurs zu dieser speichern.
Ich hab mal etwas mit < http://www.xe.com/ucc/convert.cgi> herumgespielt und es scheint zumindest nicht exakt zu stimmen. Zwar pendeln sich die Wechselkurse sicher recht schnell so ein, dass das stimmt (sonst könnte man ja ganz schnell Geld durch geschicktes umtauschen verdienen) aber es gibt sicher gewisse Fluktuationseffekte.

Grüße

Daniel