Hallo,
bei mir in meinem Oxid 6.0.5 ist glaube ich ein Bug in der Berechnung der Einzelartikel-Werte in der OxOrderArticles. Wenn der Bestand unter 0 ist werden Nachkommastellen bei OXNETPRICE, OXVATPRICE und OXNPRICE berechnet. Zudem wird dann der OXNPRICE einfach aus dem oxNetPrice übernommen, statt auf den Netto Stückpreis runter zu gehen. Dieses Phänomen tritt aber nur auf, wenn der Lagerbestand unter 0 ist.
Wenn ich mir den Code angucken ergibt sich folgendes:
// prices
$oPrice = $oContent->getPrice();
$oOrderArticle->oxorderarticles__oxnetprice = new \OxidEsales\Eshop\Core\Field($oPrice->getNettoPrice(), \OxidEsales\Eshop\Core\Field::T_RAW);
$oOrderArticle->oxorderarticles__oxvatprice = new \OxidEsales\Eshop\Core\Field($oPrice->getVatValue(), \OxidEsales\Eshop\Core\Field::T_RAW);
$oOrderArticle->oxorderarticles__oxbrutprice = new \OxidEsales\Eshop\Core\Field($oPrice->getBruttoPrice(), \OxidEsales\Eshop\Core\Field::T_RAW);
$oOrderArticle->oxorderarticles__oxvat = new \OxidEsales\Eshop\Core\Field($oPrice->getVat(), \OxidEsales\Eshop\Core\Field::T_RAW);
$oUnitPrice = $oContent->getUnitPrice();
$oOrderArticle->oxorderarticles__oxnprice = new \OxidEsales\Eshop\Core\Field($oUnitPrice->getNettoPrice(), \OxidEsales\Eshop\Core\Field::T_RAW);
$oOrderArticle->oxorderarticles__oxbprice = new \OxidEsales\Eshop\Core\Field($oUnitPrice->getBruttoPrice(), \OxidEsales\Eshop\Core\Field::T_RAW);
Die Nettopreisberechnung wird wie folgt vorgenommen:
public function getNettoPrice()
{
if ($this->isNettoMode()) {
return \OxidEsales\Eshop\Core\Registry::getUtils()->fRound($this->_dNetto);
} else {
return $this->getBruttoPrice() - $this->getVatValue();
}
}
Also wäre der Zusammenhang der für Unterschiede sorgt ob es sich um eine Netto oder Brutto Bestellung handelt, welcher unterschiedliche Rundungen hervor ruft.
Kann es sein, dass eine Bestellung aus Deutschland und eine Bestellung aus Ausland welche von B2B vorgenommen und laut Länder Konfiguration Umsatzsteuerfrei also netto?
Update: Die obere Bestellung mit 2 Nachkommastellen müsste, dann nach meiner Theorie aus Ausland B2B Kunden.
Hallo,
der Shop ist ein B2B (Fehler ist ein reiner B2C) Shop und es sind absolute Ausnahmen, dass mal jemand aus der EU mit USt-ID bestellt. Dafür kommt es zu häufig und zu regelmäßig vor.
Als Unterschied kann ich nur erkennen, dass einmal der Bestand im Minus ist und das andere mal vorhanden. Ist aber unlogisch, dass dies ein Unterschied machen soll.
Zudem wird bei mir nur der oxShortDesc und oxPic etwar in der oxOrderArticles Tabelle eingetragen, wenn die oxStock >0 ist. Der oxTitle und die anderen Felder sind immer da.
Handelt es sich um einen reinen B2B Shop und es wird die Community Edition verwendet?
Mag sein. Was für Probleme könnte eine Preisangabe mit mehreren Nachkommastellen machen?
Du meinst bei Dir im Shop gibt es dort Individualisierungen? Gibt es den andere Individualisierungen bei Dir im Shop die zu Deinem beschriebenen Verhalten führen könnten z.B. wurde Dein Shop auf B2B optimiert?
Weitere interessante Fragen wären wieviele Bestellungen sind davon betroffen? Gibt es noch weitere Gemeinsamkeiten neben den negativen Warenbestand?
Update: Was in Deinem Screenshot zu meiner These auffällt. Normalerweise würde ich oxvat = 0 erwarten in der ersten Zeile, warum dort 16%. Da scheint in der Tat etwas durcheinander zu kommen ob Netto Mode gesetzt ist aber 16% Umsatzsteuer. Das passt aus meiner Sicht nicht zusammen. Greift eine Modullösung welche den Netto Mode manipuliert bei Dir?
Hallo,
sorry, ist ein reiner B2C Shop auf Brutto-Basis. Es wird die CE verwendet, Upgrade aus der 4er mit diversen Modulen. Die Module sollten aber für mein Eindruck nicht in die Preisberechnung eingreiffen. Eine Netto-Berechnung findet außerhalb des Standarts nicht statt.
Die Preisangaben mit den Nachkommastellen sind wohl eher das Ergebnis eines anderen Problems. Wobei der oxNPrice ja falsch berechnet bzw. übernommen wird. Die Werte nutzen wir aber nicht, da alle Bestellungen zu pixi übergeben werden und dort die Rechnungen generiert werden.
Dass in der oxOrderArticles die beiden weiteren Felder fehlen ist mir zusätzlich aufgefallen. Es gibt keine Artikelindividualisierung. Bei dem Screenshot ist es auf ein Artikel gefiltert. In der oxOrderArticles kann ich neben dem negativen Bestand keine Auffälligkeiten erkennen. Betroffen ist ca. die Hälfte der Bestellzeilen.
Noch ein anderer Gedanke wird die oxorderarticles von einem anderen Prozess befüllt?
Kann es sein, dass dies keine “normale” Bestellungen sind die über das Shop Frontend erfolgen?
Weil oxorderarticles.oxstock ist laut Tabellendesign immer per Default -1 wenn diese Spalte bei einem Insert in die Tabelle nicht mit angegeben ist. Dies würde z.B. auch erklären warum oxshortdesc und oxpic fehlen…
Verdacht wäre da das pixi* dort einen Import fährt.
Interessant wären die Shop Grundeinstellungen zu “Negative Lägerbestände erlauben”
