ich habe ein Problem mit der internen Verarbeitung von Zahlen, genauer Preisangaben:
Ein Beispiel:
Ich habe ein Produkt, was 1,25EUR kostet. Einer Gruppe gewhre ich 10% Rabatt -> 1,125EUR. Hier fangen die Probleme an. Der Shop zeigt (falsche gerundete) 1,12EUR an. Kaufe ich jetzt aber 10 Stck davon, kostet das nicht 11,20EUR, sondern 11,25EUR ... an hunderter oder tausender Stckzahlen gar nicht zu denken.
Gibt es fr dieses Problem schon eine Lsung, die ich hier im Forum verpat habe und wenn nicht, wo sollte man im phpay am gnstigsten ansetzen, um die gesamte Rechengenauigkeit auf 2 Nachkommastellen zu begrenzen?
Gru.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mit mehr Kommastellen also bei hundert oder Taused stck kommen wahrscheinlich wieder mehr Zahlen zum Vorschein ...
Erst Frage: Wie wird das in der Praxis gelst? Dort steht ja eine hnliche Frage in der gleichen Situation ... Eigentlich wrden 10Stk. ja 12,50EUR kosten und davon 10% abgeogen sind 11,25EUR.
Das fr ein Exemplar 1,12EUR ausgegeben werden liegt vermutlich an number_format(). Fr eine przise Rundung sollte wohl erst round() und dann number_format() verwendet werden ...
phPay ermittelt erst den Gesamtpreis und zieht dann 10% ab. (cart.php und functions.inc.php -> showprice()).
Gru,
Andreas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. Runden der einzelnen Preise und dann komplett mit diesen gerundeten Werten rechnen, also Rabatt nicht erst an der Kasse berechnen.
2. Anzeigen normaler Preise im Shop, allerdings mit einem offen ersichtlichen Hinweis auf die Rabattierung, und den Rabatt als zustzlichen Posten auf der Rechnung (wie die MwSt. auch)
1. hat den Nachteil, da man keinen genauen Prozentsatz am Ende erreicht, durch die Rundung.
2. hat den Nachteil, da man im Shop selber noch den vollen Preis sieht. Durch den Hinweis wird man aber drauf auf merksam gemacht, dass die Preise am Ende exakt (+- 0,5ct) dem angebotenen Rabatt entsprechen.
Gruss.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kann jemand vielleicht Erfahrungen aus Praxis einbringen? Also ich meine so ein richtiges Ladengeschft. Wie wird das da gerechnet? Artikel fr 1,25Euro und davon 10% Rabatt. In ganzen Cent lt sich das ja irgendwie nicht ausdrcken.
Ein hnliches Problem ist ja bei der Brutto/Netto-Rechnerei. In der Praxis ermittelt doch niemand 6 oder 8 Stellen des Nettopreises - oder doch?
Ich denke ein Hinweis in footer.inc.php wre die einfachste Lsung. Sowas wie: Durch Rabatte knnen klenere Differenzen entstehen.
Ansonsten sollte man wirklich das number_format() durch round() ersetzen, damit die Rundungsfehler nicht so deutlich sind.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2003-06-24
In der VAW wird der Rabatt so gewhrt:
Auf einzelne Artikelpositionen (Anzahl x Preis):
10% auf 1x 1,25 entspricht 0,125. Der Rabattbetrag wird kaufmnnisch gerundet, aus 0,125 wird also 0,13. Der Endpreis betrgt dann 1,12.
Bei 10 x 1,25 = 12,50 sind 10% natrlich nur 1,25 und nicht 1,30.
Zweite Mglichkeit ist der Summenrabatt, der auf die Summe ohne MwSt. gewhrt wird. Korrekterweise muss dabei auch bei Inklusivpreisen der Nettobetrag ermittelt werden, dann rabattier, dann die MwSt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich habe ein Problem mit der internen Verarbeitung von Zahlen, genauer Preisangaben:
Ein Beispiel:
Ich habe ein Produkt, was 1,25EUR kostet. Einer Gruppe gewhre ich 10% Rabatt -> 1,125EUR. Hier fangen die Probleme an. Der Shop zeigt (falsche gerundete) 1,12EUR an. Kaufe ich jetzt aber 10 Stck davon, kostet das nicht 11,20EUR, sondern 11,25EUR ... an hunderter oder tausender Stckzahlen gar nicht zu denken.
Gibt es fr dieses Problem schon eine Lsung, die ich hier im Forum verpat habe und wenn nicht, wo sollte man im phpay am gnstigsten ansetzen, um die gesamte Rechengenauigkeit auf 2 Nachkommastellen zu begrenzen?
Gru.
Mit mehr Kommastellen also bei hundert oder Taused stck kommen wahrscheinlich wieder mehr Zahlen zum Vorschein ...
Erst Frage: Wie wird das in der Praxis gelst? Dort steht ja eine hnliche Frage in der gleichen Situation ... Eigentlich wrden 10Stk. ja 12,50EUR kosten und davon 10% abgeogen sind 11,25EUR.
Das fr ein Exemplar 1,12EUR ausgegeben werden liegt vermutlich an number_format(). Fr eine przise Rundung sollte wohl erst round() und dann number_format() verwendet werden ...
phPay ermittelt erst den Gesamtpreis und zieht dann 10% ab. (cart.php und functions.inc.php -> showprice()).
Gru,
Andreas.
natuerlich multiplizieren sich die Fehler.
Mehrere Anstze sind denkbar:
1. Runden der einzelnen Preise und dann komplett mit diesen gerundeten Werten rechnen, also Rabatt nicht erst an der Kasse berechnen.
2. Anzeigen normaler Preise im Shop, allerdings mit einem offen ersichtlichen Hinweis auf die Rabattierung, und den Rabatt als zustzlichen Posten auf der Rechnung (wie die MwSt. auch)
1. hat den Nachteil, da man keinen genauen Prozentsatz am Ende erreicht, durch die Rundung.
2. hat den Nachteil, da man im Shop selber noch den vollen Preis sieht. Durch den Hinweis wird man aber drauf auf merksam gemacht, dass die Preise am Ende exakt (+- 0,5ct) dem angebotenen Rabatt entsprechen.
Gruss.
Kann jemand vielleicht Erfahrungen aus Praxis einbringen? Also ich meine so ein richtiges Ladengeschft. Wie wird das da gerechnet? Artikel fr 1,25Euro und davon 10% Rabatt. In ganzen Cent lt sich das ja irgendwie nicht ausdrcken.
Ein hnliches Problem ist ja bei der Brutto/Netto-Rechnerei. In der Praxis ermittelt doch niemand 6 oder 8 Stellen des Nettopreises - oder doch?
Ich denke ein Hinweis in footer.inc.php wre die einfachste Lsung. Sowas wie: Durch Rabatte knnen klenere Differenzen entstehen.
Ansonsten sollte man wirklich das number_format() durch round() ersetzen, damit die Rundungsfehler nicht so deutlich sind.
In der VAW wird der Rabatt so gewhrt:
Auf einzelne Artikelpositionen (Anzahl x Preis):
10% auf 1x 1,25 entspricht 0,125. Der Rabattbetrag wird kaufmnnisch gerundet, aus 0,125 wird also 0,13. Der Endpreis betrgt dann 1,12.
Bei 10 x 1,25 = 12,50 sind 10% natrlich nur 1,25 und nicht 1,30.
Zweite Mglichkeit ist der Summenrabatt, der auf die Summe ohne MwSt. gewhrt wird. Korrekterweise muss dabei auch bei Inklusivpreisen der Nettobetrag ermittelt werden, dann rabattier, dann die MwSt.