[Allegro] ZAboM und ORDER : Währungsproblematik
Bernhard Eversberg
ev at biblio.tu-bs.de
Mo Mär 17 10:09:39 CET 2008
Wichtig nur für diejenigen, die auch Rechnungsdaten erfassen
wollen. Wobei immer klar ist, daß allegro nicht die offizielle
Mittelkontrolle erledigen kann, sondern nur für Überblick sorgen.
Es wird überlegt, was die beste Lösung für das Währungsproblem
sein könnte.
Bei Bestellungen oder Abos gibt man die Beträge in der betr.
Währung ein und dazu den Währungscode in #9B$c.
Mit der Fluktuation der Währungskurse kann sich ständig der
reale Betrag, den man letztendlich zu zahlen haben wird, ändern.
Kommt die Rechnung, wird der aktuelle Währungskurs angesetzt
für die Bezahlung. Der bezahlte Betrag wird sich natürlich dann
nicht mehr ändern, er muß daher in EUR eingegeben werden.
In den Bestellsätzen wäre das #9B$q.
Was aber machen wir mit den Rechnungssätzen? Da gibt es #9R$p
für den Gesamtbetrag der Rechnung. Dieser sollte, denken wir
momentan, in der Fremdwährung eingegeben werden, damit dieser
Wert aus dem Rechnungssatz auch später noch abzulesen ist.
Oder hält man dies für verzichtbar und würde für eine Eingabe
von Rechnungsbeträgen grundsätzlich und ausschließlich in
EUR plädieren?
Wenn Fremdwährung in $p für sinnvoll gehalten wird, dann
auch für die Teilbeträge in $t? Es wäre dann nötig, ein $q
auch in den zusätzlichen Rechnungsfeldern #9Rx zu haben.
Vorteil wäre dabei: Man gibt ein, was auf de Rechnung steht,
also Fremdwährung, und ein FLEX rechnet alles um in EUR und
schreibt es in $q. Kein manuelles Umrechnen vor Eingabe der Rechnung,
aber eine ständige Pflege der Währungstabelle wäre vonnöten.
Zur Ausrechnung der Gesamtsummen können bei den Rechnungen
natürlich nur die EUR-Beträge genommen werden, die muß es also
in jedem Fall geben. In den noch offenen Bestellsätzen darf
noch kein umgerechneter Betrag stehen, d.h. eine Summierung
der durch Bestellungen gebundenen Mittel wird zwangsläufig
schwanken, wenn sich die Kurse ändern.
MfG B.E.
Mehr Informationen über die Mailingliste Allegro