Magento und die Steuern: Probleme?

"Darf ich mal was beisteuern?" Das würde ich ganz gerne einmal zu Magento Inc sagen. Amerikaner wissen augenscheinlich nicht ganz wie man richtig mit Steuern umgeht - müssen Sie aber auch nicht. Schließlich werden die Preise dort sowieso fast überall Netto ausgewiesen und man muss, damit man weiß was es am Ende kostet, selber noch rechnen. Aber wie kritisch ist die Steuerberechnung in Magento 1.4.1.1 nun wirklich?

Update: Bitte beachte auch den neuen Beitrag aus 2011 zum Thema Steuern mit dem Titel "Magento 1.5 und die Steuern: Eine Lösung?" Mit Magento 1.5 gehören die hier genannten Probleme der Vergangenheit an.

Vorwort

Für alle Szenarien gilt: Wir sind ein deutscher Shop-Betreiber und möchten unseren Kunden Brutto-Preise ausgeben. Im Backend pflegen wir ebenfalls Brutto-Preise.  Das bedeutet das Magento, rein technisch, nun auch Brutto-Preise in die Datenbank schreibt.

Datenbankeintrag zum Preis

phpmyadmin

Unser Produkt soll 47 € kosten. 47 kann man nämlich total doof, ohne Rundungsfehler, mit 19% multiplizieren bzw. dividieren. Ein Beispiel: 47 / 1.19 = 39,4957 Gehen wir also nun fälschlicher Weise von 39,49 € Netto aus und multiplizieren das nun wieder mit 1.19 ergibt sich ein Preis von 46,9931 - schon haben wir einen Cent Rundungsdifferenz.

Szenario 1: Ein deutscher Kunde

Beim deutschen Kunden verhält sich das System vollständig korrekt. Die Bruttopreise sind schließlich als Bruttopreise in der Datenbank gespeichert und beim Ausweisen der Mwst. muss man mitunter kaufmännisches Auf- bzw. Abrunden damit am Ende der Rechnungsbetrag keine Differenzen aufweist. Das heißt: Bestellt ein deutscher Kunde im deutschen Shop läuft das System problemlos.

warenkorb_de

Szenario 2: Ein französischer Kunde

Für Auslandslieferungen haben wir unterschiedliche Möglichkeiten die Mwst. auszuweisen. Für das europäische Ausland ist es jedoch üblich (oder sogar Pflicht?) die Rechnung mit deutscher Mwst. zu erstellen. Das bedeutet für uns das wir eine Steuerregel für Frankreich erstellen:

create_steuern_fr

Diese so erstellte Regel wird zusätzlich unter "Steuerregeln verwalten" hinzugefügt. Nun noch schnell wieder unser Produkt für 47 € in den Warenkorb, im Checkout die Rechnungsadresse auf Frankreich gestellt und was sehen wir?

warenkorb_fr

Genau. Rundungsfehler. Der Produkt mit gleicher Mwst. kostet urplötzlich einen Cent mehr - also 47,01 €.

Szenario 3: Prozentuale Rabatte

Lieber Kunde, wenn du bei mir kaufst gibt es 3% Rabatt auf alles außer Tiernahrung. Mit Magento eigentlich kein Problem aber wie verhalten sich die Steuern?

Steuern in Magento mit Gutschein

Zur-Kasse_1290718434356

Also rechnen wir das mal nach:

  • Wir haben ein Produkt im Warenkorb. Dieses kostet 47 €. Stimmt.
  • 3% von 47,00 € sind 1,41 €. Stimmt.
  • Versandkosten betragen 9,90 €. Stimmt.
  • Gesamtsumme Brutto sind dann 47,00 - 1,41 + 9,90 = 55,49 €. Stimmt.
  • Alle Artikel, auch der Versand, hat 19,00 % Mwst.
  • 55,49 € Gesamt - 9,08 € Steuern ergeben 46,41 € Netto.
  • 46,41 € + 19% Mwst. sind 55,23. Stimmt nicht!

Was ist passiert? Magento hat leider wieder die Mwst. falsch ausgerechnet. Richtig wären hier 8,86 ( = 55.49 - 55.49 / 1.19 ).

Fazit

Magento ist ein gutes System hat aber im Moment ein paar Probleme mit dem deutschen Steuersystem. Ich würde diese total gerne im Rahmen eines Foocamp vollständig fixen. Was wir dazu brauchen? Natürlich den Damian Luszczymak als Organisator und ein paar Sponsoren die uns Geld für Anreisen, Räume und Nahrung zu Verfügung stellen möchten. Meldet euch unter tobi@webguys.de - so früher desto besser :)



Ein Beitrag von Tobias Vogt
Tobias's avatar

Tobias Vogt arbeitet seit 2008 mit Magento und ist seit 2011 durch Magento zertifizierter Entwickler. Seit 2016 ist er Mitgründer und CTO bei der connect-io GmbH, einer Magento-Agentur mit Sitz im idyllischen Paderborn-Salzkotten. Er gehört zum Gründer-Team der Webguys und ist seit November 2011 Bachelor of Science (Wirtschaftsinformatik). Sie erreichen Ihn per E-Mail unter tobi@webguys.de.

Alle Beiträge von Tobias

Kommentare
Andreas am

Hallo,

Steuersaetze, Quantität und Rabatte stehen in Bezug. Lässt man für Steuern und Rabatte die gleiche Genauigkeit zu, kann man keine präzisen Ergebnise gewährleisten

Es gibt 2 Richtungen: x ist der Betrag und y der Prozentsatz(Steuern) s ist der gerundete Zwischenschritt. A) incl => exkl. => incl. B) exkl. => incl. => exkl. Wichtig ist das im Zwischenschritt gerundet wird! Dort gebe ich die max. Ungenauigkeit an. Bei 2stellen ist das 5*10^-3

A) x10^2/(y+10^2) // s(y+10^2)/10^2 B) x(y+10^2)/10^2 // s10^2/(10^2+y)

A) Ist der Zwischenschritt auf 2 Stellen genau: 510^-3(y+10^2)/10^2 => (y+10^2)/10^2 für kein y 3 Stellen: 510^-4(y+10^2)/10^2 => (y+10^2)/10^2 y (y+10^2)/10^2 y 10^2/(10^2+y) für alle y

Für die Steuerbetragberechnung sieht es anders aus:

A) Total => Steuer =>Total B) Steuer => Total => Steuer

A) xy/10^2 // s10^2/y B) x10^2/y // sy/10^2

A) 2 Stellig: (510^-3)10^2/y => 10^2/y < 1 => y>10^2 3 Stellig: (510^-4)10^2/y => 10^2/y < 10 => y>10 4 Stellig: 10^2/y < 10^2 => y>1

d.h.: Berechnet man die Steuern und hat eine interne Genauigkeit von 10^-4, müssen die Steuern ganzzahlig sein, solange man das Total zurueckrechnen will! Mir ist im Frontend kein Fall bekannt. Dieses Problem kann allerdings intern vorkommen oder man meldet einem Dienst oder bekommt von einem eine Zwischensumme und berechnet den Anteil neu.

Bsp: Total: 15,15 Steuer: 0,3% => Steueranteil ist 0,04545 => gerundet 0,0455 Steueranteil: 0,0455 => Total: 15,17

B) 2Stellig: (510^-3)y/10^2 => y/10^2 y < 10^2

Ob Steuern oder Rabatte, Promotion, etc ist egal. Zu beachten ist noch dass die Quantität hier keine Rolle spielt! Diese muss mit den "Preisen" (gerundet) und nicht mit Zwischenwerten hantieren und einen richtigen Preis versprechen. Das ist nur schwer möglich. q = 10^a => Dann muss a+2-stellig abgespeichert werden.

Keine Ahnung, ob das hier korrekt ist. Gut möglich, dass ich mich um eine 10Stelle verrechnet habe.

Fazit: Die Genauigkeit der Preise steht in Verbindung mit den Steuern/Rabatten. Bei 4-stelligen Zwischenspeicherungen ist ausreichend. Um auf Nr. Sicher zu gehen, sollte der Satz keine Nachkommastellen besitzen und kleiner als 90900 sein. Für Summen wird immer ein 2-stelliger Einzelpreis zur Berechnung herangezogen, ansonsten kann mit "Quantitätsberechnung" kein genauer Preis gewährleistet werden.

Andreas am

Hallo,

Ich bin über die ungenauen Darstellungen inzwischen enttäuscht. z.B.: 47 / 1.19 = 39,4957 Gehen wir also nun fälschlicher Weise von 39,49 € Netto Das ergibt zum einen 39,50 und ist ein schlechtes Bsp.

Ein 4stelliger Betrag kann helfen. Es gibt 2 Richtungen: x ist der Betrag und y der Prozentsatz(Steuern) s ist der gerundete Zwischenschritt. A) incl => exkl. => incl. B) exkl. => incl. => exkl. Wichtig ist das im Zwischenschritt gerundet wird! Dort gebe ich die max. Ungenauigkeit an. Bei 2stellen ist das 5*10^-3

A) x10^2/(y+10^2) // s(y+10^2)/10^2 B) x(y+10^2)/10^2 // s10^2/(10^2+y)

A) Ist der Zwischenschritt auf 2 Stellen genau: 510^-3(y+10^2)/10^2 => (y+10^2)/10^2 für kein y 3 Stellen: 510^-4(y+10^2)/10^2 => (y+10^2)/10^2 y 10^2/(10^2+y) für alle y

Für die Steuerbetragberechnung sieht es anders aus:

A) Total => Steuer =>Total B) Steuer => Total => Steuer

A) xy/10^2 // s10^2/y B) x10^2/y // sy/10^2

A) 2 Stellig: (510^-3)10^2/y => 10^2/y < 1 => y>10^2 3 Stellig: (510^-4)10^2/y => 10^2/y < 10 => y>10 4 Stellig: 10^2/y < 10^2 => y>1

d.h.: Berechnet man die Steuern und hat eine interne Genauigkeit von 10^-4, müssen die Steuern ganzzahlig sein, solange man das Total zurueckrechnen will! Mir ist in Magento aber kein Fall bekannt. Bsp: Total: 15,15 Steuer: 0,3% => Steueranteil ist 0,04545 => gerundet 0,0455 Steueranteil: 0,0455 => Total: 15,17

B) 2Stellig: (510^-3)y/10^2 => y/10^2 y Dann muss a+2-stellig abgespeichert werden.

Keine Ahnung, ob das hier korrekt ist. Gut möglich, dass ich mich um eine 10Stelle verrechnet habe.

Fazit: Die Genauigkeit der Preise steht in Verbindung mit den Steuern/Rabatten. Bei 4-stelligen Zwischenspeicherungen ist ausreichend. Um auf Nr. Sicher zu gehen, sollte der Satz keine Nachkommastellen besitzen und kleiner als 100 sein. Für Summen wird immer ein 2-stelliger Einzelpreis zur Berechnung herangezogen, ansonsten kann mit "Quantitätsberechnung" kein genauer Preis gewährleistet werden.

Andreas am

Hallo,

Ich bin über die ungenauen Darstellungen inzwischen enttäuscht. z.B.: 47 / 1.19 = 39,4957 Gehen wir also nun fälschlicher Weise von 39,49 € Netto Das ergibt zum einen 39,50 und ist ein schlechtes Bsp.

Ein 4stelliger Betrag kann helfen. Es gibt 2 Richtungen: x ist der Betrag und y der Prozentsatz(Steuern) s ist der gerundete Zwischenschritt. A) incl => exkl. => incl. B) exkl. => incl. => exkl. Wichtig ist das im Zwischenschritt gerundet wird! Dort gebe ich die max. Ungenauigkeit an. Bei 2stellen ist das 5*10^-3

A) x10^2/(y+10^2) // s(y+10^2)/10^2 B) x(y+10^2)/10^2 // s10^2/(10^2+y)

A) Ist der Zwischenschritt auf 2 Stellen genau: 510^-3(y+10^2)/10^2 => (y+10^2)/10^2 für kein y 3 Stellen: 510^-4(y+10^2)/10^2 => (y+10^2)/10^2 y 10^2/(10^2+y) für alle y

Für die Steuerbetragberechnung sieht es anders aus: A) Total => Steuer =>Total B) Steuer => Total => Steuer

A) xy/10^2 // s10^2/y B) x10^2/y // sy/10^2

A) 2 Stellig: (510^-3)10^2/y => 10^2/y y>10^2 3 Stellig: (510^-4)10^2/y => 10^2/y y>10 4 Stellig: 10^2/y y>1

d.h.: Berechnet man die Steuern und hat eine interne Genauigkeit von 10^-4, müssen die Steuern ganzzahlig sein! Bsp: Total: 15,15 Steuer: 0,3% => Steueranteil ist 0,04545 => gerundet 0,0455 Steueranteil: 0,0455 => Total: 15,17

B) 2Stellig: (510^-3)y/10^2 => y/10^2 y Dann muss a+2-stellig abgespeichert werden.

Keine Ahnung, ob das hier korrekt ist. Gut möglich, dass ich mich um eine 10Stelle verrechnet habe.

Fazit: Die Genauigkeit der Preise steht in Verbindung mit den Steuern/Rabatten. Bei 4-stelligen Zwischenspeicherungen sollte der Satz keine Nachkommastellen besitzen und kleiner als 100 sein. Für Summen wird immer ein 2-stelliger Einzelpreis zur Berechnung herangezogen, ansonsten kann mit "Quantitätsberechnung" kein genauer Preis gewährleistet werden.

Ich hoffe diese Einschränkungen werden von Magento erkannt und entsprechend umgesetzt und dass ich mich nicht verrechnet habe.

Magento am

Hallo zusammen,

ich habe ein Update von 1.4.2 auf 1.7.0.2 durchgeführt. Die Steuern habe ich ohne weitere Extensions so eingestellt, wie dies in der RackSpeed-Anleitung (http://rackspeed.de/forum/magento-faq-backend/mwst-deutschland-einrichten-21) beschrieben ist. Nun aber habe ich das Problem, dass im Warenkorb und in der Kasse die Steuer nicht richtig angezeigt wird, sondern mehrfach abgezogen wird:

-- Zwischensumme 238,00 € Gesamtsumme exkl. MwSt. 162,00 € Steuer 38,00 € Gesamtsumme inkl. MwSt. 200,00 € --

Was habe ich falsch eingestellt und wie kann man das beheben?

Viele Grüße

Hahni

Magento 1.5 und die Steuern: Eine Lösung? | Magento eCommerce, Webshop, Reddot - webguys.de am

[...] und Steuern. Ja das war eine Sache für sich. Ich erinnere mich nur ungern an meinen sehr kritischen Beitrag zu diesem Thema zurück. Aber dann ist etwas passiert und ich bin vorsichtig optimistisch. Vinai [...]

Tobias Vogt am

Also, großes Interesse dort etwas auf die Beine zu stellen. Ich werde mich mal bemühen, zusammen mit Damian und David ein paar Leute unter einen Hut zu bekommen.. so das wir zusammen einen KickOff machen können, Grundlagen schaffen und das Vorgehen genauer besprechen :)

Branislav Bardak am

Jau, das Problem ist schon seit 2009 bekannt und in dem Forum besprochen worden, hier der (englischsprachige) Beitrag dazu: http://www.magentocommerce.com/boards/viewthread/17972/

Viel Spaß beim Lesen ;)

Daneben gibt's noch einen HAUFEN weiterer Bugs, zum Beispiel keine Berücksichtigung der Kundengruppen-Steuerklasse wenn man im Backend eine neue Bestellung erstellt und Kundengruppen switched, was insbesondere dann problematisch wird, wenn man eine bestehende Bestellung bearbeiten bzw. im Magento-Kontext eben "wieder-erstellen" will, siehe unter anderem diesen Beitrag: http://www.magentocommerce.com/boards/viewthread/39243/

Vergesst allerdings direkt mal die dort vorgeschlagenen "Fixes", die funktionieren nämlich überhaupt nicht. Das hier hingegen klappt - zumindest für 1.3.2.3 und 1.3.2.4 - vorzüglich: http://groups.google.com/group/magento-devel/browse_thread/thread/25ac6f2677202d2f

Gibt da noch einiges Weiteres ^^

Wär aber auch an einer aktiven "Bekämpfung" interessiert, keine Frage.

Bran

Christian Rohde am

Hi Tobias,

können wir gerne machen.

-Christian-

Tobias Vogt am

Hey Christian,

super das du dort auch was machst. Wie man an den Kommentaren sehen kann ist das Interesse das gemeinsam zu tun auch bei Vinai, Rouven, David, Damian usw. sehr groß.

Ich würde vorschlagen das wir uns alle mal gemeinsam zusammensetzen, das vorgehen besprochen, Aufgaben verteilen und dann richtig loslegen. Was hältst du davon?

schönen Gruß

Tobi

Christian Rohde am

Hallo,

habe gerade festgestellt das mein Name hier gefallen ist. ;-)

Da ich gerade dabei bin einen Patch für Magento zusammenzustellen, würde ich mich über Zuschriften freuen diesbezüglich.

Es kann sein das ich erst einen Patch erstelle der den Rundungsfehler und alles was damit zu tun hat patched. Wobei mein Ziel ist einen größeren Patch zu erstellen der die meisten Kleinigkeiten behebt.

Zur Info ich habe das auf der MeetMagento mit Rico besprochen und der Patch wird dann an Roy bzw. Magento Inc. weitergeleitet.

Deshalb wäre ich um Hilfe Dankbar.

-Christian-

Kai Köpke am

Ja bisher gab es nach den Änderungen gemäß Christian Rohdes Vorschlägen auch hier keine weiteren Meldungen mehr. Ist nur anfangs für die Kunden etwas gewöhnungsbedürftig, daß die Preise im Admin teils mit 4 Nachkommastellen angegeben werden...

@theorouv: der Link gibt nen 404

therouv am

Was mir gerade noch eingefallen ist: Ich hatte die Vorschläge von Christian Rohde (mit Ausnahme des Templates) mal in ein Modul gepackt und seither bei meinen Kunden immer installiert. Diese Preisrundungsgeschichte gehörte damit der Vergangenheit an (zumindest gab es keine Bug-Meldung mehr in diesem Zusammenhang).

Hab das Modul gerade kurz gezippt und hier zum Download bereitgestellt: http://bit.ly/gqwDyj

therouv am

FOOCAMP! FOOCAMP! FOOCAMP! :-)

Kai Köpke am

Oh ja leider ein altbekanntes Problem, welches nicht erst seit 1.4.1.1 auftritt...

Einige Links, die mir bisher geholfen haben das Problem zumindest ansatzweise zu verstehen und teilweise zu fixen: http://www.rohde-christian.de/magento-rundungsfehler/ http://www.magentocommerce.com/boards/viewthread/39367/P0/

Ich finds super, daß ihr euch dessen annehmen wollt :)

Tobias Vogt am

Werner, den Beitrag finde ich recht spannend. Ich werde das mal nachstellen und schauen ob es zumindest Teile Probleme aus dem Beitrag löst :) Dennoch sollte unser aller Ziel sein irgendwann man ein Market-Ready-Germany zu haben das auch die oben genannten Probleme beseitigt :)

Werner Aschenbrenner am

Wir kämpfen regelmäßig mit irgendwelchen (relativ skurrilen) Rundungsfehlern bei Magento. Eine der Ursachen, dass Runden nach der zweiten Stelle lässt sich beheben mit wenigen Handgriffen - wir (genauer gesagt @hasipeter) haben dazu eine aktuellen Beitrag verfasst http://www.loremipsum.at/blog/code/rundungsfehler-in-magento-beheben/

In Kombination mit mehreren Anderen Apsekten - z.B. Rabatt auf Versandkosten oder Produktbzogener Rabatt kanns auch noch lustige Fehler geben.

Manuel Brückmann am

Oh ja! Das Problem kenne ich nur zu gut! Diese Rundungs Probleme hatten wir bisher bei allen Magento Projekten... :-/

David am

Foocamp... find' ich gut!

Andreas von Studnitz am

Wenn's zeitlich passt, wäre ich auch gern dabei - das Problem muss gelöst werden! Ein bisschen Sponsoring werde ich sicher auch übernehmen können...

Ralf Siepker am

Diesmal würde ich bestimmt nicht absagen :-)

Dein Kommentar