Rundungsmodus Fehler oder Denkfehler

[Alex PSV1.6]

Hallo zusammen,

 

ich habe hier entweder ein Problem mit dem Rundungsmodus oder ein Denkfehler. Es geht um die Rundung der Nachkommastellen bei der MwSt. (Wert 1,75470623)

 

PS Version: V1.6.1.12

 

Einstellungen unter Voreinstellungen-->Allgemein:

Rundungsmodus: Kaufmännisch aufrunden (empfohlen)

Rundungsregel: Gesamtsumme runden

Anzahl der Nachkommastellen: 6

Der im Warenkorb nun angezeigte MwSt. Wert lautet: 1,754706

 

--> soweit korrekt.

 

Wird nun die Anzahl der Nachkommastellen auf 2 eingestellt, so würde ich an dieser Stelle den angezeigten Wert 1,75EUR erwarten, da Rundung auf 3te Nachkommastelle, hier Zahl 4, also abrunden

 

Allerdings wird bei dieser Einstellung der Wert 1,76EUR dargestellt.

 

Habe ich hier einen Denkfehler oder wie seht Ihr das?

 

Vielen Dank für jeglichen Tip und Gruss

Alex

 

PS: Nein, keine Overrides vorhanden

Edited April 18, 2017 by Alex PSV1.6 (see edit history)

[rictools]

Ich vermute, Prestashop berechnet die MwSt. für den Gesamtpreis (0,796... = 0,80) sowie die MwSt. für die Versandkosten (0,957...= 0,96) und addiert diese beiden Beträge, dann sind die 1,76 EUR korrekt (frag' mich jetzt nicht, ob das rechtlich so korrekt ist).

[Claudiocool]

eventuell ist in der php.ini die precision (Standardwert ist 14 Stellen nach dem Komma) zu gering gesetzt, so dass da unter Umständen der Rundungsfehler herkommt. Wenn da nicht, sollte mal das Script genauer betrachtet werden, wo die Mwst. gebildet wird.

 

Rundungsproblematiken können immer entststehen, daher sollte man seine Preiskalkulationen auch dahingehend betrachten, ich hab das Problem immer dann, wenn Artikel angelegt werden, weil wir bei diversen Kunden netto rechenen und die Steuer erst hinten draufkommt.

[rictools]

Nein, die Rundung muß - wenn die MwSt. vom Gesamtbetrag berechnet wird - eindeutig nach unten erfolgen, egal wie viele Stellen nach dem Komma noch kommen.

 

Im Grunde lassen sich Rundungsdifferenzen je nach Berechnungsmethode nie vermeiden, es kommt nur darauf an, ob die Berechnungsmethode korrekt ist oder nicht oder ob beide Varianten zulässig sind.

[Alex PSV1.6]

Danke für eure Rückmeldungen, allerdings habe ich hier etwas anderes Verständnis, so wie dies auch hier erklärt wird.

 

Quelle: https://mwst-rechner.plakos.de/

 

Auszug:

Wie muss man die Mehrwertsteuer runden?

Alle Preise und Rechnungsbeträge werden grundsätzlich mit zwei Nachkommastellen angegeben. Somit ist man bei der Ermittlung des Brutto- und Nettobetrages häufig genötigt auf- oder abzurunden. Hier wird immer kaufmännisch gerundet. Das heißt: Ist die dritte Nachkommastelle größer gleich 5 wird aufgerundet, sonst abgerundet.

Beispiel: Netto 21,13 EUR

Bruttobetrag = 21,13 * 1,19 = 25,1447 = 25,14 EUR

2. Beispiel: Netto 21,14 EUR

Bruttobetrag = 21,14 * 1,19 = 25,1566 = 25,16 EUR

 

 

 

Folglich müsste in dem von mir genannten Beispiel bei dem Wert 1,754706 die MwSt auf 1,75 gerundet werden, da ausschlaggebend die 3tte Zahl, hier also 4 ist.

 

Ich vermute jedoch, dass hier auch die 4te Nachkommastelle betrachtet wird (7), was dazu führt, dass aus der 3tten Zahl gerundet eine 5 wird und letzendlich es zu dem Ergebnis 1,76 kommt.

 

Leider bin ich kein PHP Experte (nur Grundkenntnisse), würde jedoch gerne wissen, wo diese Berechnungen durchgeführt werden, um hier entsprechende Anpassungen durchführen zu können. Des weiteren würde es mich wundern, wenn nur ich dieses Problem hätte...

[rictools]

Entschuldigung, du scheinst meinen Beitrag #2 nicht gelesen zu haben, da habe ich doch ganz genau erklärt, wie Prestashop offenbar (und durchaus nach den Rundungsregeln) rundet.

[Claudiocool]

Also.... es kommt auf die Methode der Rechnungsstellung an.

 

Bei einer Rechenungsstellung mit Nettobeträgen und danach auf die Nettosumme beaufschlagte Umsatzsteuer kommt sehr oft was anderes raus als bei einer Brutto-Rechnungsstellung, bei der die Umsatzsteuer unten lediglich ausgewiesen wird.

 

Dieses Problem habe ich z.B. bei Firmenkunden, die nach Variante 1 abgerechnet werden, da kommt meistens was anderes als bei der Endkundenvariante raus.

[Alex PSV1.6]

Hallo Christian,

 

danke für deinen Hinweis, allerdings habe ich sehr genau deinen Beitrag zur Kenntnis genommen.

 

Deine Vermutung kann ich jedoch nicht bestätigen, da ich die Einstellung "Gesamtsumme runden" eingestellt habe und daher annehme, dass hier auch die Gesamtsumme incl. Versand zum Runden verwendet wird. Sollte PS natürlich mit Gesamtsumme nur die Artikel meinen wäre dies ein KO Kriterium.

 

Link: https://www.prestashop.com/forums/uploads/monthly_04_2017/post-412284-0-18415600-1492537230.jpg

 

Dein Ansatz wäre natürlich plausibel, jedoch nicht rechtens für DE. Daher würde ich gerne wissen, wo diese Berechnungen durchgeführt werden

 

@Claudiocool:

Bei meinem Ansatz geht es um Endkundenvariante

Edited April 19, 2017 by Alex PSV1.6 (see edit history)

[rictools]

Du kannst ja in der Rechnung auch die Mehrwertsteuer für die Artikel und die Mehrwertsteuer für die Versandkosten getrennt ausweisen, bei deiner Rechnung würde die Summe der beiden Mehrwertsteuerbeträge dann nicht mehr stimmen. Außerdem gibt es Fälle, wo der Prozentsatz der Mehrwertsteuer auf die Artikel (z. B. teilweise 7, teilweise 19 %) und der auf die Versandkosten nicht übereinstimmen.

 

Wie man's macht, zu Rundungsdifferenzen kann es kommen. Das scheint auch nirgends ein Problem zu sein, über Google finde ich zwar Diskussionen im Zusammenhang mit Shopsystemen, aber keine Beiträge von Rechtsanwälten etc. dazu. Wenn du eine Quelle kennst, wonach das "nicht rechtens" ist, poste sie mal.

[eleazar]

Entschuldigung, du scheinst meinen Beitrag #2 nicht gelesen zu haben, da habe ich doch ganz genau erklärt, wie Prestashop offenbar (und durchaus nach den Rundungsregeln) rundet.

Nein, das macht PrestaShop eben nicht!

 

@Alex PSV1.6

Du hast völlig recht, hier wird mal wieder mathematisch und nicht kaufmännisch gerundet. Letzteres beherrscht PHP nämlich nicht.

Um dem PrestaShop-Team dies zu erklären und überhaupt erst mal dafür zu sorgen, dass ein Fehlerkorrektur-Konstante eingeführt wurde, habe ich mir im Laufe der Jahre schon die Finger wund geschrieben und eine Reihe von Diskussionen im Forum und direkt mit Mitgliedern des Entwicklerteams geführt. Denn die Beschwerden über Rundungsfehler kehren mit jeder Version wieder - allein im englischen und französischen Forum gibt es hunderte Posts bzw. Topics dazu.

Daran ändern auch die zusätzlichen Rundungsoptionen nichts, die PrestaShop seit 1.6 anbietet, zumal sie zum Teil überflüssig sind, s. z.B. meine Beiträge hier: https://www.prestashop.com/forums/topic/350813-16010-testers-needed/?do=findComment&comment=1789734 und hier: http://https://www.prestashop.com/forums/topic/357357-korrekte-mwst-berechnung-für-16-und-15/

 

Zwischendurch gab es immer mal die eine oder andere Unterversion, die richtig rechnete. Die letzte war aber wohl 1.6.0.10. Danach wurden wieder weitere Fehler eingebaut, so dass auch mein für 1.5 entwickeltes Override nicht mehr ausreicht. Inzwischen rechnet PrestaShop wieder kräftig falsch (zumindest bei den empfohlenen Einstellungen), was sich vor allem bei größeren Stückzahlen bemerkbar macht. Als Beispiel möge die beigefügte Rechnung dienen, erstellt zwar mit dem Fork Thirty Bees 1.0, aber genau so reproduzierbar mit Prestashop 1.6.1.2 - 1.6.1.12, da Thirty Bees die Programmierfehler hier übermimmt. Man beachte hier die MwSt-Summe in den Steuerdetails für die Artikel. Richtig wäre bei 19% natürlich nicht ein Betrag von 136,90, sondern nur von 136,84!

 

TB-000003.pdf

 

Da PrestaShop die Rundungsregel "Gesamtsumme runden" nicht richtig beherrscht, sondern nur pro Zeile richtig rundet, besteht der Trick darin, die Option "pro Zeile runden" zu wählen, weil die Rundungsfehler ab einer gewissen Artikelmenge sonst zu offensichtlich werden. Dann stimmt die Rechnung auch, wie man hier sieht:

 

TB-000003.pdf

 

Das gilt gleichermaßen für 1.6.1ff wie für 1.7.

[Alex PSV1.6]

Also eigentlich möchte ich wissen, wie man das Problem in den Griff bekommen kann...

 

Danke im voraus

[Alex PSV1.6]

Hallo Eleazar,

 

vielen Dank für die Info. 

 

Allerdings tritt der gleiche Fehler, bei mir zumindest, immernoch auch bei "pro Zeile runden" auf.

 

Ehrlich gesagt,, kann ich es nicht wirklich nachvollziehen, was das kaufmännische Runden so schwer machen sollte. Ich meine, wenn 2 Nachkommastelle angezeigt werden sollen, so braucht doch nur auf 3tte Nachkommastelle geschaut zu werden. Ist der Wert >4 aufrunden, ansonsten einfach abschneiden. Wäre es nicht möglich sowas mittels eines Overrides abzubilden?

 

Gruss

Alex

[rictools]

hier wird mal wieder mathematisch und nicht kaufmännisch gerundet. Letzteres beherrscht PHP nämlich nicht.

Das kann ich nicht nachvollziehen, lt. Wikipedia gibt es nur einen Unterschied, wenn die dritte Stelle eine 5 ist und sich dahinter nur Nullen befinden, dann wird mathematisch auf die nächste gerade Zahl gerundet, kaufmännisch immer nach oben. Dieser bei der Mehrwertsteuerberechnung äußerst seltene Fall kommt in den Beispielen hier aber nicht vor.

[eleazar]

Hallo Alex,

und du bist sicher, dass du deine Artikelpreise brutto erfasst hast, also die Nettopreise im Back Office mit mehr als 2 Stellen hinterm Komma angezeigt werden?

 

Ehrlich gesagt,, kann ich es nicht wirklich nachvollziehen, was das kaufmännische Runden so schwer machen sollte. Ich meine, wenn 2 Nachkommastelle angezeigt werden sollen, so braucht doch nur auf 3tte Nachkommastelle geschaut zu werden. Ist der Wert >4 aufrunden, ansonsten einfach abschneiden. Wäre es nicht möglich sowas mittels eines Overrides abzubilden?

 

Tja, wenn das mal so einfach wäre, denn dazu brauchst du nicht nur eine Erweiterung des PHP-Befehlssatzes wie im Override der Tools.php, das ich im oben verlinkten Topic gepostet habe, mit dem man die ganzen Rundungsoptionen einfach aushebelt ...

<?php

class Tools extends ToolsCore
{
	public static function ps_round($dVal,$iDec = 0)
	{
	// banker's style rounding (Kaufmännisches Runden) or round-half-even
	// (round down when even number is left of 5, otherwise round up)
	// $dVal is value to round
	// $iDec specifies number of decimal places to retain
	static $dFuzz=0.00001; // to deal with floating-point precision loss
	$iRoundup=0; // amount to round up by
	$iSign=($dVal!=0.0) ? intval($dVal/abs($dVal)) : 1;
	$dVal=abs($dVal);
	// get decimal digit in question and amount to right of it as a fraction
	$dWorking=$dVal*pow(10.0,$iDec+1)-floor($dVal*pow(10.0,$iDec))*10.0;
	$iEvenOddDigit=floor($dVal*pow(10.0,$iDec))-floor($dVal*pow(10.0,$iDec-1))*10.0;
	if (abs($dWorking-5.0)<$dFuzz) $iRoundup=($iEvenOddDigit & 1) ? 1 : 0;
	else $iRoundup=($dWorking>5.0) ? 1 : 0;
	return $iSign*((floor($dVal*pow(10.0,$iDec))+$iRoundup)/pow(10.0,$iDec));
	}

}

... sondern außerdem die Sicherheit, dass nicht irgendwo in den Tiefen von PrestaShop eigene Rundungsvorgänge ablaufen - so wie im Paypal-Modul. Das kann nämlich bei den simplen Additions- und Subtraktionsvorgängen, die hier vorzugsweise zum Einsatz kommen, sehr leicht passieren.

[Alex PSV1.6]

Hallo Eleazar,

 

ja, der Netto Preis hat mehr als nur 2 Nachkommastellen, siehe Anhang.

 

Gruss

Alex

[Claudiocool]

Jetzt ist mir klar, warum ich dieses Problem so nicht habe, ich habe zwar mal zur Annäherung die Preise immer netto eingegeben, aber dann eben im Bruttofeld runde Preise gemacht. Tut man das nicht, kann es passieren, dass die Preise dummerweise hinter der 2. Stelle weitergehen, aber man sieht das da nicht.

[Alex PSV1.6]

hmm, habe soeben beim Nettopreis nach 2ter Kommastelle Werte gelöscht, jedoch besteht dieses Phänomen immer noch (leider)

 

Mit dem Override Tools.php und aktivem Debug Mode erhalte ich folgende Fehlermeldung:

Strict Standards: Declaration of Tools::ps_round() should be compatible with ToolsCore::ps_round($value, $precision = 0, $round_mode = NULL) in /var/www/web697/html/alm/prestashop-prod/override/classes/Tools.php on line 23

Edited April 19, 2017 by Alex PSV1.6 (see edit history)

[eleazar]

Kann, muss aber nicht! Das ist ja das Vertrackte! Versuch es mal nicht wie die PrestaShop-Tester mit der Menge 1 oder 2, sondern mit einem höheren Mengenfaktor. Dann siehst du den Unterschied. Prestashop rechnet standardmäßig mit 6 Nachkommastellen beim Artikel-Nettopreis. (Außer bei reduzierten Preisen, da scheinen sie es schlicht vergessen zu haben, die Variable $decimals mit Inhalt zu füllen. )

[Alex PSV1.6]

Ich glaube einen Workaround gefunden zu haben ... hoffe zumindest

 

Ich denke dass diese Rundungsfehler dadurch zustande kommen, weil der Nettowert von 6EUR einige Nachkommastellen aufweist, die PS nicht richtig runden kann.

 

Folglich habe ich nun den Versandwert auf 5,95EUR eingestellt um den Nettopreis 5EUR zu erhalten.

 

Bisher konnte ich keine Abweichungen feststellen... hoffe es bleibt so

 

Vielen Dank nochmals an alle für Hilfestellungen

[Claudiocool]

Deswegen macht es auch nur Sinn, bei Endkundenshops den Bruttopreis einzugeben, und den Shop die Nettopreise selbst rechnen zu lassen, mir ist da bisher keine grobe Unregelmäßigkeit aufgefallen, die uns das Schicksal eines U.H. vom FCB bescheren würde

[eleazar]

Ich glaube einen Workaround gefunden zu haben ... hoffe zumindest

 

Ich denke dass diese Rundungsfehler dadurch zustande kommen, weil der Nettowert von 6EUR einige Nachkommastellen aufweist, die PS nicht richtig runden kann.

 

Folglich habe ich nun den Versandwert auf 5,95EUR eingestellt um den Nettopreis 5EUR zu erhalten.

 

Bisher konnte ich keine Abweichungen feststellen... hoffe es bleibt so

 

Vielen Dank nochmals an alle für Hilfestellungen

 

Das Problem scheint mir aber woanders zu liegen. Ich habe nämlich gerade festgestellt, dass PrestaShop die Rundungspräzision generell auf 2 Stellen einschränkt, und zwar in der /config/confi.inc.php (Zeile 137). Da heißt es:

define('_PS_PRICE_DISPLAY_PRECISION_', Configuration::get('PS_PRICE_DISPLAY_PRECISION'));
define('_PS_PRICE_COMPUTE_PRECISION_', _PS_PRICE_DISPLAY_PRECISION_);

Als PS_PRICE_DISPLAY_PRECISION wird in der Datenbanktabelle ps_configuration der Wert eingetragen, den man im Back Office für die Anzahl der anzuzeigenden Dezimalstellen festlegt, also in Deutschland 2. Das ist aber Unsinn. Es muss heißen:

define('_PS_PRICE_DISPLAY_PRECISION_', Configuration::get('PS_PRICE_DISPLAY_PRECISION'));
define('_PS_PRICE_COMPUTE_PRECISION_', 6);

Weiteres Problem sind dann die rabattierten Preise. Da findet man nämlich immer noch statt _PS_PRICE_COMPUTE_PRECISION_ die Variable $decimals. Meines Erachtens müsste es in der /classes/Product.tpl in den Argumenten der Funktion priceCalculation statt nur $decimals besser $decimals = 6 heißen.

Damit sollte dann eigentlich auch dieses Problem erledigt sein. Hoffe ich jedenfalls!

[Alex PSV1.6]

Hallo Eleazar,

 

vielen Dank für den erneuten Vorschlag das Problem an der WUrzel zu packen ;-)

 

Ich habe soeben die Zeile in der besagten Datei auf "define('_PS_PRICE_COMPUTE_PRECISION_', 6);" geändert und die Versandkosten wieder zurück auf 6EUR. Leider wird die MwSt erneut falsch dargestellt, sprich 1,76 statt den 1,75 für den Bruttogesamtpreis 11,99EUR. Die rabattierten Preise erstmal ausser Acht gelassen, da der betroffene Artikel nicht rabattiert ist.

 

Folglich löst dieses leider nicht das besagte Problem...

 

Gruss

Alex

[eleazar]

Tja, tut mir leid!

Ich kann jetzt nur für PrestaShop 1.6.1.10 und Thirty Bees 1.0 sprechen. Da werden  in meinen Testläufen mit den von mir vorgeschlagenen Einstellungen die Nachkommastellen exakt berechnet - natürlich vorausgesetzt, die Preise wurden richtig erfasst und die Datenbankfelder für Preise haben das Format 20,6.

Mir fehlt leider die Zeit, sämtliche Versionen von PS durchzutesten.

[Alex PSV1.6]

Hi,

 

es ist absolut nachvollziehbar, dass du nicht jede Version gegenprüfen kannst, trotzdem Danke!

 

Ich kannte Thirty Bees bis dato noch nicht, es klingt jedoch vielversprechend und zielt genau darauf ab, was ich gesucht habe. Meine Frage wäre, ob man auch ein bestehendes System darauf portieren kann bzw. wie ich dies in mein System einbinden kann.

 

Konnte hierzu leider noch keine Info finden...