Müsste der Endpreis im Warenkorb nicht 474,81 € sein, also 1 Cent mehr als Shopware berechnet? Hier der Eintrag für den Artikel in s_artciles_prices: id pricegroup from to articleID articledetailsID price pseudoprice baseprice percent 10009 EK 1 beliebig 1 1 39.9 0 39.9 0
Nein, das wäre ja dann in der Ansicht falsch. Links unter dem Bild siehst du ja den Stückpreis. Dieser wird ja mit der Menge multipliziert. 47,48 x 10 = 474,80
Stimmt, ich darf nicht von der Gesamtsumme ausgehen… Dann kann ich meinem Kunden ja schön unter die Nase binden, dass der alte Shop das falsch gemacht hat 
Der hat nämlich 1 Cent mehr ausgewiesen.
Trotzdem ist die MwSt.-Berechnung falsch MwSt. = 75,81 Euro / Netto: 398,99 Euro wäre m. E. richtig. 
1 Cent mehr fürs FA Gruß Rainer
19% von 474,80 € sind 75,8084 € --> gerundet also 75,81€ also ist die MwSt. berechnung falsch.
Das liegt wohl daran, dass hier die MwSt. pro Artikel berechnet, gerundet und dann mit der Anzahl der Artikel multipliziert wird. Nach den Regeln ordnungsgemäßer Buchführung muss aber in der Tat die MwSt. immer aus der Summe gezogen werden. Wir lassen das die Warenwirtschaft machen und zeigen die MwSt. im Shop nicht explizit an. Dann ist das sauber … AS
Gibt es schon ein Bug-Ticket für dieses Problem?
Hallo in die Runde, scheinbar wird derzeit noch immer die MwSt je Artikelposition x Menge berechnet. Am Ende werden dann die einzelnen MwSt.-Beträge addiert. Dies ist aber falsch und Shopware kann ja eigentlich schlecht eigene Steuergesetze erstellen. Es muss immer aus der Gesamtnettosumme der Steuersatz von 19% hinzukommen. 1) Ist dieses Problem, welches bei jeder Steuerprüfung ein Problem darstellen wird (ebenso für die TrustedShops Auditierung), erkannt und wird daran gearbeitet? 2) Kann man im Backend vielleicht bereits festlegen, wie die MwSt berechnet und gerundet werden soll? Beispiel: 3 x 30,01 EUR netto = 90,03 2 x 19,36 EUR netto = 38,72 1 x 19,36 EUR netto = 19,36 1 x 1,11 EUR netto = 1,11 = 149,22 EUR netto Shopware berechnet 177,58 EUR brutto, korrekt wäre aber 177,57 EUR Der Kunde bezahlt A) 0,01 EUR zuviel und B) stimmt der Umsatzsteuerbetrag nicht. Vielen Dank.
[quote=“industrialparts”]Hallo in die Runde, 2) Kann man im Backend vielleicht bereits festlegen, wie die MwSt berechnet und gerundet werden soll? [/quote] Würde mich auch interessieren: Ich war gerade mehr als nur erstaunt, dass ich (schreibe gerade eine Lexware Shopware Verbindung mit Ruby on Rails) bei Aufträgen (Bestellungen) immer falsche Werte bzgl. der USt bekomme. Ein Blick auf die Daten aus Shopware macht es deutlich: 1.9.3p448 :030 \> Shopware::Order.find(443) Shopware::Order Load (0.5ms) SELECT `s_order`.\* FROM `s_order` WHERE `s_order`.`id` = 443 LIMIT 1 =\> #<:order id: ordernumber: userid: invoice_amount: invoice_amount_net: invoice_shipping: invoice_shipping_net: ordertime: status: cleared: paymentid: transactionid: comment: customercomment: internalcomment: net: taxfree: partnerid: temporaryid: referer: cleareddate: nil trackingcode: language: dispatchid: currency: currencyfactor: subshopid: o_attr1: o_attr2: o_attr3: o_attr4: o_attr5: o_attr6: remote_addr:>
1.9.3p448 :031 > Shopware::Order.find(443).details
Shopware::Order Load (0.5ms) SELECT `s_order`.* FROM `s_order` WHERE `s_order`.`id` = 443 LIMIT 1
Shopware::OrderDetail Load (0.4ms) SELECT `s_order_details`.* FROM `s_order_details` WHERE `s_order_details`.`orderID` = 443
=> [#<:orderdetail id: orderid: ordernumber: articleid: articleordernumber: price: quantity: name: status: shipped: shippedgroup: releasedate: nil modus: esdarticle: taxid: config: od_attr1: od_attr2: od_attr3: od_attr4: od_attr5: od_attr6:>]
Man beachte: invoice_amount: 182.05, invoice_amount_net: 153.0
wo doch 153.0 * 1.19 = 182.07 ist !!!
Ich benutze Shopware 3.5.7 und kann mich jetzt durch den Code wühlen, um den Rundungsfehler in den Berechnungen zu finden. Das ist mehr als nur unschön!!
PS:Das ist das Problem, wenn die Businesslogik ein Mischmasch von SQL und PHP ist… wenn ich mal viel Zeit habe, gibt es eine Shopware Rails Anwendung
PPS: Und nein, die 4.x Version mit Doctrine ist m.A.n. auch nicht besser - PHP ist einfach nix für elegante Programmierung (Habe ich selbst viele Jahre gemacht - ich weiss, wovon ich rede) - da kann man noch so viele Frameworks draufsetzen…</:orderdetail></:order>