Moin, wir haben große Problem mit Bestellungsänderungen über das Backend speziell bei umsatzsteuerfreien Bestellungen (z.B. in die Schweiz und an Firmen in der EU mit Ust-Id). Wenn man bei einer solchen Bestellung den Status ändert (z.B. Ware versandt), wird die Rechnungssumme neu berechnet. Dabei kommen sehr verwunderliche Ergebnisse heraus. Siehe http://jira.shopware.de/Widgets/Jira/?ticket=SW-5957 Da wir nicht darauf warten können, bis in einer der nächsten Versionen der Fehler behoben wird, habe ich versucht, die Neuberechnung der Gesamtsumme zu verstehen und bin auf folgenden Code aus /engine/Shopware/Models/Order/Order.php gestossen: public function calculateInvoiceAmount() { $invoiceAmount = 0; $invoiceAmountNet = 0; //iterate order details to recalculate the amount. /\*\*@var $detail Detail\*/ foreach ($this-\>getDetails() as $detail) { $invoiceAmount += $detail-\>getPrice() \* $detail-\>getQuantity(); $tax = $detail-\>getTax(); // if no tax is given use the default value 19. // additional tax checks required for sw-2238, sw-2903 and sw-3164 if ($tax && $tax-\>getId() !== 0 && $tax-\>getId() !== null && $tax-\>getTax() !== null) { $taxValue = $tax-\>getTax(); } else { $taxValue = 19; } if ($this-\>net) { $invoiceAmountNet += ($detail-\>getPrice() \* $detail-\>getQuantity()) / 100 \* (100 + $taxValue); } else { $invoiceAmountNet += ($detail-\>getPrice() \* $detail-\>getQuantity()) / (100 + $taxValue) \* 100; } } if ($this-\>net) { $this-\>invoiceAmountNet = $invoiceAmount + $this-\>invoiceShippingNet; $this-\>invoiceAmount = $invoiceAmountNet + $this-\>invoiceShipping; } else { $this-\>invoiceAmount = $invoiceAmount + $this-\>invoiceShipping; $this-\>invoiceAmountNet = $invoiceAmountNet + $this-\>invoiceShippingNet; } } Das sieht für mich aus wie völliger Unsinn: - Wenn in der Bestellposition keine Tax-ID steht (da steht tatsächlich 0 drin), wird einfach mal 19% angenommen. - invoiceAmountNet wird aufsummiert und es werden genau diese 19% addiert. Wenn es die Netto-Summe ist, warum werden dann 19% addiert? Die Bestellposition ist bei einer Nettobestellung auch Netto gespeichert. Warum soll ich die Steuer addieren? - Wenn es eine Bestellung mit Steuern ist, wird für invoiceAmountNet die Steuer von der Bestellposition abgezogen. Das wäre logisch. - Das endgültige Ergebnis ($this->invoiceAmountNet) ergibt sich weiter unten dann aus $invoiceAmount (Der Summe der Netto-Positionen) und dem Netto-Versand - ABER: Der Brutto-Wert ($this->invoiceAmount) ergibt sich aus den Bestellpositionen, zu denen die Umsatzsteuer addiert wurde (die Variable heisst aber $invoiceAmountNet )und dem Brutto-Versand. Waaaas soll das? Das Resultat ist, dass bei Netto-Bestellung die Gesamtsumme im Backend mit Umsatzsteuer ausgewiesen wird. Mir scheint der obige Code völlig daneben. Oder wer fühlt sich in der Lage das zu erklären? Es kommt noch hinzu, dass bei Änderung der Versandkosten im Backend der Netto-Versandkostenwert nicht aktualisiert wird und das die Berechnung dann völlig durcheinanderbringt. Siehe http://jira.shopware.de/Widgets/Jira/?ticket=SW-5958 Das kann doch alles nicht wahr sein. Es gibt jetzt schon die neunte Version von Shopware 4 (4.00 bis 4.08) und es lässt sich immer noch nicht vernünftig einsetzen. Grüße kapeha
Noch etwas: in s_order gibt es die beiden Felder „taxID“ und „tax_rate“ mit einmal der ID und einmal tatsächlichen Wert des Steuersatzes (z.B. 19). Warum zwei Werte? Wann wird welcher Wert benutzt? in s_order gibt es die Felder „net“ und „taxfree“. Warum zwei Felder? In welchen Fällen können diese unterschiedliche Werte annehmen? Wer kann helfen?
Ich habe das jetzt weiter untersucht: In /engine/core/class/sOrder.php wird die TaxID der Bestellposition auf 0 gesetzt. if ($this-\>sNet == true){ $basketRow["taxID"] = "0"; } Die TaxRate wird jedoch weiterhin gespeichert, z.B. 19%. In engine/Shopware/Models/Order/Order.php wird dann geprüft, ob die ID 0 ist und wieder 19% angenommen: if ($tax && $tax-\>getId() !== 0 && $tax-\>getId() !== null && $tax-\>getTax() !== null) { $taxValue = $tax-\>getTax(); } else { $taxValue = 19; } Kann es sein, dass hier ein Entwickler nicht weiß, was der andere macht? Erst den Wert bei der Bestellung löschen und dann als Workaround annehmen, dass es 19% ist? Und es dann noch zum Bruttobetrag einer steuerfreien Bestellung addieren? In der Bestellposition könnte doch ohne weiteres die TaxID gespeichert werden, auch wenn es sich um eine Netto-Bestellung handelt. Beim Ausrechnen der Summe kann die Steuer ignoriert werden. Muss man später aus irgendeinem Grund die Bestellung zu einer Brutto-Bestellung machen, kann die Steuer dann nachträglich berechnet werden, da sie bei den Artikelpositionen gespeichert ist. Das muss sich wohl mal ein Entwickler anschauen, der die Historie nachvollziehen kann. Die im Kommentar erwähnten Bugs sw-2238, sw-2903 and sw-3164 kann ich leider nicht im Ticket-System finden.
Kann ich bestätigen. Bei Nettobestellungen wird zunächst der korrekte Wert im Backend angezeigt. Speichert man die Bestellung ab, erscheint der Bruttowarenpreis + Netto-Versandkosten. Im Frontend bleibt aber alles korrekt. Also auch im Kundenkonto unter „Meine Bestellungen“. Es wirkt so, als wenn jeder Bereich ein eigenen Code zur Berechnung bekommen hat.
eklatant @ :shopware:
Hallo, wir schauen uns deine Tickets im Zuge der 4.1 an - das sieht auf den ersten Blick so aus, als wenn der Fallback auf 19 % bei der Refaktorierung des alten Codes (aus Shopware 3.5) übernommen worden ist - der wird aber eigentlich nicht mehr benötigt. (Hintergrund: Früher gab es keine konfigurierbaren Steuersätze in Shopware, das ist später dazu gekommen, deshalb wurde “damals” ein Fallback verwendet, für den Fall, dass noch alte Datensätze ohne direkte Steuerdefinition vorhanden sind) Du kannst einmal probieren, ob folgende Code-Änderung (Im Model) bei dir funktioniert - damit entfällt der Fallback und die Netto-Summe dürfte sich nicht mehr verändern. $taxValue = 0; // if no tax is given use the default value 19. // additional tax checks required for sw-2238, sw-2903 and sw-3164 if ($tax && $tax-\>getId() !== 0 && $tax-\>getId() !== null && $tax-\>getTax() !== null) { $taxValue = $tax-\>getTax(); } [quote] in s_order gibt es die beiden Felder “taxID” und “tax_rate” mit einmal der ID und einmal tatsächlichen Wert des Steuersatzes (z.B. 19). Warum zwei Werte? Wann wird welcher Wert benutzt? [/quote] Die Tax-Rate lässt sich ja global ändern, somit hätte man u.U. keinen konsistenten Zustand mehr in der Datenbank - sprich die Brutto-Summe von Bestellungen würde ggf. auch verändert - daher wird neben der 1 zu 1 Beziehung auch die Steuer selbst zusätzlich gespeichert. [quote]in s_order gibt es die Felder “net” und “taxfree”. Warum zwei Felder? In welchen Fällen können diese unterschiedliche Werte annehmen?[/quote] Es gibt ja 2 Fälle: - Netto Kundengruppe: Bekommt Artikelpreise im Frontend & auf Belegen Netto dargestellt, zahlt aber ganz normal die Ust. im Bestellprozess (B2B) => net = 1 | taxfree = 0 - Komplette Netto-Lieferung (Schweiz z.B.) => net = 1 | taxfree = 1
Hallo, also ich muss jetzt auch mal meinen Frust los werden :thumbdown:: Wenn man in der Bestellübersicht die Versandkosten manuell ändert werden diese auf der Rechnung plötzlich mit 0% Steuer ausgewiesen, da zwar ‚invoiceShipping‘ (bzw. ‚invoice_shipping‘ als MySQL Tabelleneintrag) geändert wird, jedoch nicht ‚invoiceShippingNet‘ (‚invoice_shipping_net‘ entsprechend). Da das Backend nochmal komplett ein eigenes Ding in JScript ist kann man sich nun durch etlich mögliche Stellen im Code wühlen, um die Passende Stelle zu finden, an der die Entwickler eklatanter Weise vergessen haben, dass die Nettobeträge auch angepasst werden müssen. Da es nicht das erste Mal ist, dass eine wirkliche Basisfunktion schlicht _nicht korrekt_ funktioniert und ich den Shopware Code nun bereits mehrmals durchwühlt habe, bleibt festzuhalten, dass dieser wirklich sehr sehr undurchsichtig ist. Mehr und mehr erhalte ich den Eindruck, dass gewisser Fehler absichtlich enthalten sind, damit dann entnerfte Community Edition Benutzer bezahlten Support kaufen - vor allem wenn wirklich Grundlegende Sachen wir korrekte Steuerberechnung, Rechnungserstellung und Anpassung fehlerhaft sind. :thumbdown:
Hallo AR0x7E7, das Thema hier wurde doch schon längst gelöst?! Was du aktuell bemängelst ist ein ganz anderes Thema. Zudem ist es an der Stelle nicht vorgesehen, den Wert zu ändern. Das hat Shopware aber auch in de Doku stehen. [quote]Die Versandkosten können an dieser Stelle nicht verändert werden! Sollten Sie einmal Versandkosten anpassen müssen, so leeren Sie dieses Feld und fügen eine neue Position “Versandkosten” unterhalb vom Reiter “Positionen” ein.[/quote] In der neuen Version sind zwei Felder vorhanden, so das man, wenn man unbedingt in dem Feld was ändern will/muss, netto und brutto pflegen kann. Dynamisch berechnen geht ja nicht ohne weiteres, da ja auch ein Steuersatz jeweils dafür vorhanden sein muss bzw. der korrekte Satz angewendet werden muss. Daher kann man es fast nur mit 2 Feldern machen. Über eine neue Position ist es daher besser gelöst, wie in der Doku genannt. MfG Max
Von wegen gelöst… Leider gibt es bei der Berechnung der Gesamtsumme immer noch Fehler. Siehe: http://jira.shopware.de/?ticket=SW-7680 Diesmal stimmt die Netto-Summe nicht. @max Das neue Eingabefeld für die Netto-Versandkosten kann ja auch nur eine Zwischenlösung sein. Der Shop muss ja auch während der Bestellung die Umsatzsteuer auf die Versandkosten berechnen. Warum sollte er das nicht auch nachträglich leisten können?