kann es sein, dass ein Berechnungsfehler in der Artikeleingabe existiert ? Gebe ich z.B. einen Bruttobetrag von 91,40 Euro ein (bei 16% MwSt.), so wird ein Nettobetrag von 78.45 Euro gespeichert. Dies fhrt im Shop (Frontend) dann zu einem Bruttobetrag von 91,00 Euro.
Den Thread bzgl. Rundungsfehler und DB-Spalte auf (10.3) erhhen habe ich bereits gelesen und die Preis-Spalte sogar auf (10.5) erhht. Ntzt nur leider nix.
Gebe ich bei der Artikeleingabe jedoch einen Nettobetrag von 78,7931 ein, so erscheint im Shop der richtige Bruttobetrag von 91,40.
Daher sieht das fr mich nach einem Berechnungsfehler im Artikeleingabeprogramm aus, wenn der Bruttobetrag eingesetzt wird. Fr einen Rundungsfehler ist die Differenz zu gross.
... oder mache ich da irgendwo einen Gedankenfehler ????
Gru Rainer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ist mir noch nicht aufgefallen. Es htte nicht direkt was mit den Formatierungen wie im Shop zu tun, sondern wohl eher damit, da es in der Artikeladministration die Mglichkeit 91,40 und 91.40 einzugeben (Zeile 38f und 84f).
Erstmal versuch bitte ob der Fehler auch auftritt, wenn Du 91.40 als Bruttopreis eingibst, danach tausche die Zeile 38 und 39 bzw 84+85.
(Bei der Ermittlung des Nettopreises von 91,40 wird nmlich nur 91/1.16 gerechnet :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das Problem entsteht, wenn der Shop das Komma als Dezimaltrenner durch einen Punkt zu ersetzen (ereg_replace()), dann wird der Wert zu einer Zeichenkette, die einen Dezimalpunkt hat. Nach dieser Replace-Aktion mu einfach noch ein settype($npreis[$i],"double") oder sowas ausgefhrt werden, damit wird aus dem String wieder eine Zahle und alles ist gut.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm das versteh ich jetzt nicht, heit das Du baust das so ein oder heit das da es schon so gemacht wird und deswegen ein Problem ist ?
;-) Lies nochmal den 1. Satz der is irgendwie mehrdeutig...
FLoh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das 'wenn' ist zweideutig zugegeben.
Es ist schon (fehlerhafterweise) so, da aus dem numerischen Preiswert durch die Ersetzerei eine Zeichenkette wird.
Die Lsung dafr ist das einzubauende settype().
Besser formuliert ;-)
Gru,
Der_Socke.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo Andreas,
kann es sein, dass ein Berechnungsfehler in der Artikeleingabe existiert ? Gebe ich z.B. einen Bruttobetrag von 91,40 Euro ein (bei 16% MwSt.), so wird ein Nettobetrag von 78.45 Euro gespeichert. Dies fhrt im Shop (Frontend) dann zu einem Bruttobetrag von 91,00 Euro.
Den Thread bzgl. Rundungsfehler und DB-Spalte auf (10.3) erhhen habe ich bereits gelesen und die Preis-Spalte sogar auf (10.5) erhht. Ntzt nur leider nix.
Gebe ich bei der Artikeleingabe jedoch einen Nettobetrag von 78,7931 ein, so erscheint im Shop der richtige Bruttobetrag von 91,40.
Daher sieht das fr mich nach einem Berechnungsfehler im Artikeleingabeprogramm aus, wenn der Bruttobetrag eingesetzt wird. Fr einen Rundungsfehler ist die Differenz zu gross.
... oder mache ich da irgendwo einen Gedankenfehler ????
Gru Rainer
Ist mir noch nicht aufgefallen. Es htte nicht direkt was mit den Formatierungen wie im Shop zu tun, sondern wohl eher damit, da es in der Artikeladministration die Mglichkeit 91,40 und 91.40 einzugeben (Zeile 38f und 84f).
Erstmal versuch bitte ob der Fehler auch auftritt, wenn Du 91.40 als Bruttopreis eingibst, danach tausche die Zeile 38 und 39 bzw 84+85.
(Bei der Ermittlung des Nettopreises von 91,40 wird nmlich nur 91/1.16 gerechnet :-(
Ich habe das selbe Problem. Wenn ich statt 91,40 91.40 eingebe, dann funktionierte es....
Habe eine ganz neue Version (2.01)
Ja is doch eh klar....
PHP untersttzt wahrscheinlich standardmig nur den amerikanischen Dezimalpunkt oder?
FLoh
Das ist schon richtig (Dezimalpunkt).
Das Problem entsteht, wenn der Shop das Komma als Dezimaltrenner durch einen Punkt zu ersetzen (ereg_replace()), dann wird der Wert zu einer Zeichenkette, die einen Dezimalpunkt hat. Nach dieser Replace-Aktion mu einfach noch ein settype($npreis[$i],"double") oder sowas ausgefhrt werden, damit wird aus dem String wieder eine Zahle und alles ist gut.
Hm das versteh ich jetzt nicht, heit das Du baust das so ein oder heit das da es schon so gemacht wird und deswegen ein Problem ist ?
;-) Lies nochmal den 1. Satz der is irgendwie mehrdeutig...
FLoh
Das 'wenn' ist zweideutig zugegeben.
Es ist schon (fehlerhafterweise) so, da aus dem numerischen Preiswert durch die Ersetzerei eine Zeichenkette wird.
Die Lsung dafr ist das einzubauende settype().
Besser formuliert ;-)
Gru,
Der_Socke.