Wo und wie wird der Brutto VK berechnet?

Ich versuche gerade ein Rundungs-Problem zu verstehen.
Dazu hier meine Frage: Wie und wo genau berechnet Gambio den Brutto-VK?
Und weiter, ob das ev. in letzter Zeit überarbeitet wurde. Ich habe hier einen 4.8.0.2er Shop, und sehe das Problem zum ersten Mal. Jetzt ist unklar, ob ich das bisher übersehen habe, ob etwas an Gambio geändert hat, oder an meiner WAWI von der ich die Artikel hochlade.

Hintergrund:
Gambio und meine WAWI (Vario) scheinen bei brutto/netto anders zu rechnen, das zu Rundungsfehlern in der Anzeige im Shop führt:

Ich habe in meiner WAWI einen Artikel mit BruttoVK 30CHF, MWST 7.7%
Vario speichert dazu automatisch als NettoVK 27.86.
Dieser Wert geht per API an den Shop, der das im Frontend dann als 30.01 darstellt:
27.86 * 1.077 ergibt 30.00522. Dann wird vermutlich etwas wie SQL round(30.00522,2) gemacht, was eben auf 30.01 aufrundet.

Wenn ich im Shop-Admin im Artikel einen Brutto von 30.- eingebe, ist danach in der DB 27.8552 gespeichert. Dies mit MWST 7.7 ergibt dann 30.0000504, was beim Runden auf zwei Stellen nicht mehr auf 30.01 kippt.

PS: Im Admin vom Produkt wird übrigens das gerundete 27.86 gezeigt, aber das hat wohl nur mit Ästhetik zu tun.

 

Danke. Aber nein, das scheint ein anderes Thema zu sein.
Ich denke, es hat wie beschrieben damit zu tun, dass die beiden Systeme anders umrechnen und runden zwischen Netto und Brutto.

 

Schwierig, VARIO speichert selbst nur zwei Stellen, zb. im Fall von Brutto=30... allgemein zwischen 2 und 4 Stellen.
Scheint so, dass das abhängig ist davon, wie viele Stellen es braucht, um beim Umrechnen auf Brutto einfach nach zwei Dezimalstellen abschneiden zu können, statt das Runden, das Gambio macht...
EDIT: Nein, nicht ganz, wohl eher Runden mit drei Kommastellen:

Verstehe es nicht... egal, muss ich auch nicht.

 

Hmm, gibt's vielleicht in den Shop Einstellungen irgendetwas wo man die Berechnung konfigurieren kann?

 

Danke.
Durchblicken tue ich da aber nicht: wenn ich nach round suche, finde ich mehrere Treffer wie:

PHP:

1041                         $t_price = round($p_special_price, $this->currencies[$this->actualCurr]['decimal_places']);

Das scheint aber nur das Runden auf die in der Währung konfigurierten Anzahl Stellen zu sein.

Es geht mir ja um die Stelle, wo Brutto errechnet wird. Also wenn ich nach tax suche, finde ich das:

PHP:

 432         public function xtcAddTax($p_price, $p_tax_rate, $p_consider_currency = true)
433         {
434                 $t_price = (float)$p_price + (float)$p_price / 100 * (float)$p_tax_rate;
435
436                 if($p_consider_currency)
437                 {
438                         $t_price = $this->xtcCalculateCurr($t_price);
439                 }
440
441                 $t_price = round($t_price, (int)$this->currencies[$this->actualCurr]['decimal_places']);
442
443                 return $t_price;
444         }


Hmm, das ist scheinbar auch nicht das Gesuchte. Da wird auch mit den Stellen der Währung gerundet. Das sind dann 2 bei mir, wie wohl bei den meisten.

In den Einstellungen gibt es tatsächlich ein Setting für's Umrechnen:

Das kann man im UI aber nicht tiefer als 4 setzen (weniger wird als 4 gespeichert).
Mit der Suche in Texte anpassen finde ich die Bezeichnung des Feldes: PhraseRICE_PRECISION_TITLE
Heisst das also in der DB ähnlich?
In der DB finde ich das Feld PRICE_PRECISION, das ist normal 4.
SELECT * FROM configuration WHERE configuration_key = 'PRICE_PRECISION'
Ah, das ist's? Nein... wenn ich es in der DB auf 3 setze, ändert sich nichts im UI... Und auch nichts am Rundungsfehler im Frontend.
Und ah ja, wenn ich das im UI auf 5 setze, bleibt in der DB in configuration der Wert von PRICE_PRECISION unverändert...

Also, falls jemand mehr weiss:
gerade frage ich mich weiterhin

1. wo die Netto-Brutto Umrechnung erfolgt
2. wo der Wert Umrechnungsgenauigkeit für Dezimalstellen gespeichert wird
3. wo überall er greift (ev. mehr Orte neben brutto-netto und netto-brutto?)
4. wozu in der DB in configuration der Wert PRICE_PRECISION dient, wenn nicht für die Umrechnung.

 

Ah ja. Aber das scheint nur zu beeinflussen, wie viele Stellen in der DB gespeichert werden in products.price. Auf die Umrechnung netto>brutto hat's offensichtlich keinen Einfluss.
Ich suche also immernoch die Stelle, wo der Rundungsfehler passiert.
public function xtcAddTax in xtcPrice.php schien mir erst die richtige Stelle, aber das ist nicht der Fall. Sieht man ja schon daran, dass die Stellen-Zahl der Währung genommen wird. Der Rundungsfehler tritt aber auf, weil offensichtlich mit vier Stellen gerundet wird.

 

Mit grep -irn "configuration/PRICE_PRECISION" . wollte ich finden, wo der Wert aus der DB in eine PHP Konstante übernommen wird, finde damit aber nur eine Datei aus dem Updater, die tut nichts zur Sache.
Wo also passiert das?

 

@Stephan Hochradl ja, das ist oben schon beschrieben dass dies nicht hilft bei meinem Problem. Es ändert die Genauigkeit, mit der der Netto-Preis gespeichert wird.
Was mich da interessieren würde ist, warum man das überhaupt einstellen kann, also welche Situationen das erfordern.

@Dominik Späte Ja, genau das hab ich gesehen.
Aber das sind zum einen alles Orte wo der Wert angewendet wird, ich suche für's Verständnis noch die Definition, etwas wie
const PRICE_PRECISION = [Wert aus der DB]...

Zum anderen sind das ausser /admin/includes/functions/general.php immer Dateien spezifische Bereiche, für die Preisausgabe am Produkt etc. müsste etwas anderes zuständig sein, nicht?
EDIT: ah, die general.php ist ja in admin/, kann also auch nicht für's Frontend zuständig sein... ja, testhalber umbenannt, Shop läuft weiter.
Somit sind eigentlich alle Dateien ausgeschlossen. Mein Verdacht ist, dass die Umrechnung irgendwo passiert mit der Genauigkeit hartcodiert. Das deckt sich ja auch damit, dass ein ändern von PRICE_PRECISION in der DB nichts auslöst.

 

Ah... für's Frontend ist tatsächlich xtcPrice.php zuständig...

Wieso schrieb ich das nur? tax wird doch dazugerechnet auf Zeile 434!

PHP:

 432         public function xtcAddTax($p_price, $p_tax_rate, $p_consider_currency = true)
433         {
434                 $t_price = (float)$p_price + (float)$p_price / 100 * (float)$p_tax_rate;
435
436                 if($p_consider_currency)
437                 {
438                         $t_price = $this->xtcCalculateCurr($t_price);
439                 }
440
441                 $t_price = round($t_price,       1);// (int)$this->currencies[$this->actualCurr]['decimal_places']);
442
443                 return $t_price;
444         }


Und wenn ich die Genauigkeit in Zeile 441 auf 1 Nachkommastelle verbiege, werde ich auch die Rundungsfehler los...
Das ist etwas gemurkst, aber da ich keine feineren Abstufungen habe als 0.1 genügt das vermutlich vorerst... Sollte ja von Vario gefixt werden vermutlich.
Ich habe schon mal angefragt dort, wie sie denn netto>>brutto rechnen, dann könnte ich das dort einfügen.

Was mir noch fehlt, ist die Stelle, die das für den Admin Bereich umrechnet. Aber man kann auch damit leben, dass dort noch falsch gerundet wird. Editieren sollte ich eh nur noch in der WAWI...

 

Nein, ich habe ja die temporäre "Lösung" für mich im letzten Beigrag, das definitive muss vom WAWI Hersteller kommen.

Im Thread hier geht's ja um die schon weiter oben beantwortete Frage Wo und wie wird der Brutto VK berechnet?
Deine Frage tönt etwas anders. Darum denke ich am besten machst du einen neuen Thread, beschreibst dort was/wo denn genauer dein Problem ist (beschreib ob das beim Warenkorb vorkommt wegen Stück-Multiplikation, weil du Netto eingibst und "gerade" brutto willst, etc...). Kannst mich gerne mit @sirtet erwähnen, damit ich die Frage mitbekomme. Vielleicht weiss ich dann was dazu.