Hallo zusammen,
ich stelle die Preiseinkl. MwSt. im Shop da. Ein bestimmter Artikel kosteninkl. MwSt. 15€. Jetzt ist es so, dass ich diesen Betrag nicht ausgeben kann auf Grund der Rundunsgeingeschaften von Oxid.
[ul]
[li] 12.6€ergibt 14,99€und 12.61€ergibt 15,01€[/ul][/li]Gibt es einen Weg -ausser alles auf zzgl. MwSt. einzustellen- um einen oder diesen bestimmten Betrag ausgeben?Danke!
Hallo somespy,
hat das einen besonderen Grund, dass Du Bruttopreise angezeigt haben willst, aber Nettopreise einpflegst?
Wenn Du nämlich die 15 EUR im Artikel-Stamm einträgst werden vorne auch 15 EUR angezeigt.
Hallo,
wenn ich das richtig verstehe, gibst Du Nettopreise ein, die Bruttopreise sollen errechnet werden. Wo werden denn die Netto-Preise von Dir eingegeben, werden diese vielleicht importiert? Mit welcher Shopversion arbeitest Du denn?
Gruß
Marco Steinhäuser
Community Guide
OXID eSales AG
Hallo,
ich nutze die Version: CE 4.0.1.0. Die Preise werden manuell über die Artikelverwaltung eingetragen im Eingabefeld “Preis”. Nach Eingabe wird der Bruttopreis automatisch errechnet, also zzgl. der MwSt. Somit kann ich natürlich nicht wie empfohlen den Bruttopreis eintragen.
Danke für das Eröffnen eines issues.
Hallo somespy,
wir haben es ausgefochten und uns geeinigt, dass der “issue” erstmal nicht weiter bearbeitet wird.
Man nehme öffne Start > cmd > calc und tippe dort 15/1,19 ein. Das Ergebnis wird kopiert, der Taschenrechner zurückgesetzt. Nun das Ergebnis wieder in den Taschenrechner kopieren und mit 1,19 multiplizieren: Siehe da - wir landen bei 14.99.
Offensichtlich handelt es sich also um ein Präzisionsproblem.Man gehe also zu Admin -> Grundeinstellungen -> Einstellungen -> Währungen und ändere die Präzision auf drei Nachkommastellen. Hier werden jetzt alle Preise mit drei Nachkommastellen dargestellt: 15,000 <-- nicht schick.
An dieser Stelle wird mal wieder das Thema b2b berührt, das wir derzeit nicht in vollem Umfang unterstützen.
Kannst Du damit leben, die Preise als Brutto-Preise im Shop einzugeben? Mit den Import- und Export-Filtern sollte es eigentlich nicht wirklich ein Thema sein.
Gruß
Marco Steinhäuser
Community Guide
OXID eSales AG
Ich habe mich mit dem Kunden auf 14,99€ für dieses eine Produkt geeinigt.
Zukünftig werde ich Brutto-Preise einpflegen.
Vielen Dank für die Unterstützung.
Ich bedanke mich auch. Das ist immerhin äußerst wertvoller Input, den wir hier bekommen 
Gruß
Marco Steinhäuser
Community Guide
OXID eSales AG
Hallo, dieses Problem hatte ich auch.
Als ich mir aber den Quellcode angeschaut habe, bin ich auf folgendes gestoßen:
Soweit ich das beurteilen kann wird in der oxprice.php der Netto/Brutto Betrag zuerst gerundet, bevor er umgerechnet wird.
d.h. 15€ inkl. mwst sind netto: 12,605042016806722689075630252101
wenn oxprice das umrechnet, wird also nicht das 12,6050… genommen sondern 12,61, was dann in brutto 15,0059 bzw eben diese 15,01 ergibt.
Ich hoffe man konnte mir folgen 
Man schreibe also ein Plugin, welches den Betrag davor nicht rundet und schon stimmt alles!
Oder ist dieses Betrag-runden zu etwas anderem noch gut? Bevor ein Preis ausgegeben wird, wird dieser ja selbst nochmal auf die 2 Stellen nach dem Komma formatiert.
EDIT:
Wenn das obige der Fehler ist, müsste man folgende 4 Zeilen auskommentieren, damit richtig berechnet wird (ohne Gewähr):
(378) $dBrutto = oxUtils::getInstance()->fRound($dBrutto);
(400) $dNetto = oxUtils::getInstance()->fRound($dNetto);
(415) $this->_dNetto = oxUtils::getInstance()->fRound( $this->_dNetto );
(422) $this->_dBrutto = oxUtils::getInstance()->fRound( $this->_dBrutto );
Ui, das ist gefährlich. Womöglich tauchen an anderen Stellen Berechnungsfehler auf, die man so einfach gar nicht abschätzen kann…
Ist es denn überhaupt möglich, 30 Nachkommastellen (ja, ich habe gezählt ) einzugeben?
Gruß
Marco Steinhäuser
Community Guide
OXID eSales AG
http://twitter.com/marcosteinhaeus
Naja eigentlich sollten dadurch ja keine Berechnungsfehler auftreten, da die Zahlen durch das wenigere Runden exakter sind. Eher werden Berechnungsfehler durch das ofte Runden begünstigt (siehe Anfangspost).
Ob es möglich ist 30 Nachkommastellen einzugeben, weiss ich selber auch nicht genau 
aber 4 Nachkommastellen sollten eigentlich ausreichen.
Vielleicht kann ein Core-Entwickler sich den Code nochmal anschauen und überlegen, ob dieses viele Runden der Zahlen nötig ist.
Grüßle
jups, genau dafür gibt’s den Bug-Eintrag 
Gruß
Marco Steinhäuser
Community Guide
OXID eSales AG
http://twitter.com/marcosteinhaeus
Dann wird der Bug Eintrag doch nicht mehr beachtet? oder habe ich was übersehen?
Wir müssen das Thema mit B2B neu anfassen…
Marco Steinhäuser
Community Guide
OXID eSales AG
http://twitter.com/marcosteinhaeus