Oxid rundet Bruttopreise aus Nettopreisen falsch (bei Artikelpreis)

Deutsches Forum
1

Hallo,

ich bin mit der Forensuche leider nicht fündig geworden. - Falls dieses Problem schon 1000x besprochen wurde, freue ich mich auch über einen Link zum entsprechenden Thread!

Hier mein Problem:

Ich pflege gerade Artikelvarianten in einen Oxid CE 4.5.5 Shop ein. Die Artikelpreise werden im Admin NETTO eingegeben. In den meisten Fällen stimmen die Bruttopreise dann auch, ab und an kommt es aber vor, dass Oxid mir den exakten Brutto-Betrag verweigert. Nachfolgend zwei Beispiele:

Beabsichtigter Bruttopreis: 14,90 bei 7% MwSt.
Bei Eingabe im Admin (netto) 13,925 bekomme ich brutto 14,91 im Frontend angezeigt.
Bei Eingabe im Admin (netto) 13,924999 bekomme ich brutto 14,89 im Frontend angezeigt. - Ich habe also keine Chance, auf einen Bruttopreis von 14,90 zu kommen!

Laut Taschenrechner wäre der korrekte (auf vier Stellen gerundete) Netto-Preis 13,9252, wenn ich 14,90 brutto brauche.

Beabsichtigter Bruttopreis: 135,00 bei 19% MwSt.
Bei Eingabe im Admin (netto) 113,445 bekomme ich brutto 135,01 im Frontend angezeigt.
Bei Eingabe im Admin (netto) 113,444999 bekomme ich brutto 134,99 im Frontend angezeigt. - Ich habe also keine Chance, auf einen Bruttopreis von 135,00 zu kommen!

Laut Taschenrechner wäre der korrekte (auf vier Stellen gerundete) Netto-Preis 113,4454, wenn ich 135,00 brutto brauche.

Ist das ein bekanntes Problem oder habe ich irgendwo eine Einstellung falsch gesetzt?

Ich wäre für Hinweise jeglicher Art sehr dankbar!

Viele Grüße,
Christoph

2

stell doch den shop auf btutto eingabe um ?

3

ja, das wollte ich auch gerade empfehlen - ist einfacher wenn die Anzeigepreise in brutto rund sein müssen

4

Vielen Dank für Eure Antworten!

Und ja, ich würde den Shop prinzipiell mit Bruttopreisen betreiben, allerdings soll er zum Jahreswechsel per Schnittstelle (von TStrunk) an CAO angebunden werden und der Kunde arbeitet seit jeher mit Nettopreisen. - Soweit ich das der Schnittstellen-Dokumentation entnommen habe, muss dann auch im Shop mit Nettopreis-Eingabe gearbeitet werden.

Aber abgesehen davon, läuft da doch bei Oxid “unter der Haube” etwas schief, oder? - Da stimmt ja rein mathematisch etwas nicht.

5

http://www.oxid-esales.com/forum/showthread.php?t=924#post5683

https://bugs.oxid-esales.com/view.php?id=735

6

Hey, vielen Dank! - Das werde ich mir näher anschauen.

Hat jemand Erfahrung mit dem Auskommentieren der Rundung auf zwei Nachkommastellen? - Der Moderator schreibt ja, dass das gefährlich sei, was ich mir (wie andere Poster im verlinkten Thread) aber eigentlich nicht vorstellen.

Danke nochmal!

7

Hallo,

Stell in CAO, unter Shopeinstellung, Brutto-Shop ein und in Oxid alle Artikelpreise auf Bruttoeingabe. Dann sollte es passen. Unabhängig davon arbeitet CAO intern immer mit Netto.

8

Das Problem hatte ich auch, die Lösung aus diesem Thread:
http://www.oxid-esales.com/forum/showthread.php?t=924#post5683 hat bei mir nicht funktioniert.

Die Lösung:

In core/oxutils.php

return round($sVal + $dprez, $iCurPrecision);

ändern in:

return round($sVal + $dprez, 3);

So konnte ich das Problem aus der Welt schaffen.

9

Hallo zusammen,

da ich gerade vor der gleichen Problematik der Rundungsfehler stehe, habe ich die Lösung aus dem Bugreport und die von Bell angesehen. Außerdem ein wenig im Forum recherchiert.

Das Raufschrauben der Präzision im Backend ist ja mit dem Nachteil verbunden, dass die Preise im Shop dementsprechend auch mit 3 Nachkommastellen ausgegeben werden.

Die Lösung von Bell scheint im ersten Anhieb zu funktionieren, wobei man anstatt der 3 die etwas elgantere Lösung $iCurPrecision+1 umsetzen kann.

Nun da das Ganze recht gut funktioniert stellt sich mir allerdings die Frage wo der Haken an der Sache ist? Bzw. die Lösung ist recht simpel und auf den ersten Blick wäre es doch optimal, wenn man im Backend die Möglichkeit bekäme, 2 Angaben zur Präzision machen zu können: Einmal die Anzeige im Frontend, und einmal als Grundlage für die Rundungsfunktion?

Aktuell besteht ja das Problem dass das Paypal-Portlet meckert, da die Preise nach Korrektur nicht mehr mit denen bei Paypal übereinstimmen (allerdings nur wenn man den Warenkorb überträgt).

Wenn es aber keine weiteren Einwände gegen diesen Lösungsweg gibt dann könnte man die Umsetzung bei einem nächsten Update in Erwägung ziehen? Immerhin recht leicht umzusetzen. So wie es hier im Forum aussieht missbrauchen doch ziemlich viele die CE-Version als mittelprächtige B2B-Lösung.

10

Hi,

[QUOTE=paranoise2;102459]
Wenn es aber keine weiteren Einwände gegen diesen Lösungsweg gibt dann könnte man die Umsetzung bei einem nächsten Update in Erwägung ziehen? [/QUOTE]

Wir schauen uns das grad an :wink:

Gruß

11

Hi,

also in einer 4.6.4 tritt der Fehler nicht mehr auf, zumindest bei mir. Also ist es schon gefixed oder?

12

Moin,

[QUOTE=bhasis;102510]
also in einer 4.6.4 tritt der Fehler nicht mehr auf, zumindest bei mir. Also ist es schon gefixed oder?[/QUOTE]

Nee, das sieht man auch nur deutlich in bestimmten Konstellationen.

Gruß