Die Mehrwertsteuerberechnung in VirtueMart 2.x ist nun anders geregelt als in den Versionen von VM 1.1.x.

Zunächst ein paar gesammelte Erkenntnisse:

  • In der Tabelle #_virtuemart_product_prices liegen die Preise für die Produkte. Als Fremdschlüssel zur Product-Tabelle wird hier logisch die Produkt-ID (#_virtuemart_product_id) verwendet. Im Feld product_tax_id steht eine id für die anzuwendende Mehrwertsteuerregel. 0 entspricht der Standardregel.
  • In VM 2.x gibt es nun generell Rechenregeln, die im Backend erstellt werden und in der Tabelle #_virtuemart_calcs verwaltet werden. Hier können auch sehr umfangreich konfigurierbare Mehrwertsteuerregeln definiert werden. Diese können z.B. abhängig gemacht werden von Ländern, Kategorien, Staaten, Shoppergruppen u.v.m. Folglich sollte hier auch eine MwSt.-Regel für den deutschen Standardsatz von 19% angelegt werden.
  • Ganz wichtig ist die Zuordnung der Shoppergruppen zu diesem Steuersatz, damit am Anfang überhaupt etwas passiert, zu den Steuergruppen -default- und -anonymous-.



  • Wenn man seine Daten aus VM 1.1.x migriert hatte, dann gibt es hier möglicherweise Probleme. Bei der Migration wird zwar auch die Tax-ID bei den Produkten mit übernommen, jedoch fast "treffsicher" falsch. In meinen Projekten ist das i.d.R. die Tax ID 3. Diese gibt es so aber im neuen Projekt nicht. Die erste Regel wird ziemlich wahrscheinlich die 0 erhalten und damit haben wir einen Konflikt. Demgegenüber sind bei Neuinstallationen schon 3 Regeln definiert und die 3. davon ist auch schon unsere 19%-WwSt. Behelfen könnte man sich im Migrationsfall, in dem entweder per SQL-UPDATE das Feld product_tax_id mit einer 0 befüllt wird, oder die Datensätze aus einer Neuinstallation in die Migrations-DB überträgt, oder wir legen verher zwei ungenutzte Regeln an damit die 3., unsere MwSt-Regel die ID 3 bekommt (ungetestet). Für die DB-Freunde hier mal so einen SQL-Befehl (auf eigene Gefahr!):

 

update j25_virtuemart_product_prices SET product_tax_id=0;

 

  • Eine weitere sehr schöne Konfiguartionsmöglichkeit im Zusammenhang mit der MwSt-Anzeige kann über die Konfiguration der Käufergruppen erfolgen. Hier kann sehr fein eingestellt werden, welche Preisarten angezeigt werden sollen (z.B. Nettoprei, Bruttopreis, MwSt-Betrag, Gesamtpreis, ermäßigter Preis usw.).
  • Im Übrigen ist es nicht notwendig, wenn man shopweit mit dem selben Mehrwertsteuersatz arbeiten will, bei den Steuerregeln explizit sämtliche Länder, Shoppergruppen, Produktkategorien hinzuzufügen. Lässt man die genannten Auswahlfelder komplett leer, ist das gleichbedeutend damit, als wenn man alle ausgewählt/zugewiesen hätte. Nur für den Fall, dass man also mehrere Steuersätze anlegen will, die zwischen Produktkategorien, Ländern oder Kundengruppen abweichend zugewiesen werden sollen, dann ist hier eine Auswahl notwendig.

 

Punkt als Dezimaltrennzeichen!

Ganz wichtig, weil eine der häufigsten Fehlerquellen bei der Berechnung der MwSt. ist, dass diese im Format 0.00 eingegeben wird, also mit Dezimalpunkt. VM braucht und speichert nummerische Werte! Die Schreibweise 0,00, also mit Komma, würde von VM so interpretiert werden, dass nur die Zahl vor dem Komma verarbeitet würde und darauf bei der Steuerregel +% die Steuer draufgerechnet wird. Das passt dann natürlich am Ende bei der Überprüfung der Rechenwerte nicht zusammen, also aufpassen!

 

MwSt-Rechenoperation berücksichtigen!

I.d.R. wird ja für die MwSt.-Berechnung die Formel verwendet, bei der die MwSt. auf den Nettopreis draufgerechet wird. Das ist quasi der Standard. Die mathematische Operation dazu ist in VM benannt als +%. VM speichert folglich auch die Preise netto und rechnet die MwSt. entspr. des angegebenen Satzes drauf.

Bei der Pflege er Produktpreise kann man sich den Preis auch aus einem Brutto-Verkaufspreis berechnen lassen, was besonders dann von Vorteil ist, wenn man dem Kunden hübsch glatte Beträge anbieten will. Das ist aber lediglich ein kleines Tool in der Pflegemaske und ändert nichts an der Tatsache, dass VM Nettobeträge haben will und diese auch so in ~_virtuemart_product_prices.product_price als Nettobeträge speichert.

Bei den Versandkosten wird das dann noch mal deutlich. Hier gibt es keine Eingabemöglichkeit für Bruttobeträge und auch keine automatische Umrechnung. Es wird ein Nettopreis erwartet!

 

Wenn Ihnen dieser Beitrag geholfen und viel Zeit gespart hat, zeigen Sie sich erkenntlich: Über eine Klick auf Google+1 oder Rückmeldungen freue ich mich, zeigt es mir doch, dass sich die Mühe für die Beitragerstellung gelohnt hat. Schenken Sie auch den Produktwerbungen Ihre Beachtung.