Oxid Country VAT Module berechnet Mehrwertsteuer falsch

Deutsches Forum
1

Hallo Forum,

wir haben gerade durch einen Zufall entdeckt, das das von OXID bereitgestellt Modul
Country VAT für die unterschiedliche Mehrwertsteuerberechnung leider falsche Nettopreise auswirft, wenn ein Kunde aus einem anderen EU Land mit einer gültigen Mehrwertsteuernummer eine Nettobestellung auslöst.

Beispiel:
Unser Shop in DE hat als MwSt Satz natürlich 19% in den Grundeinstellungen angegeben.
Wir legen der Einfachheit halber einen Artikel mit 119 EUR Bruttopreis an.

Bestell nun ein Kunde wie bei uns z.B. aus Belgien und hat dort eine gültige MwSt. ID
sollte der Preis dann Netto 100,00 EUR sein, das die Lieferung ja netto erfolgt und dann
vom Kunden mit dem belgischen Steuersatz von 21% dort abgeführt wird.

Ist er aber leider nicht, der Preis ist nur 98,35 EUR, nachgerechnet zieht der Shop 21%, also
den belgischen Steuersatz ab.
Ist leider reproduzierbar.

Ich hatte eines unserer Module im Verdacht und habe das mit einem frisch aufgesetzen Testshop CE 6.4.4 probiert, Modulversion Country VAT 1.0.4

Dort leider gleiches Verhalten, Modul deaktiviert, Nettopreise werden nach der Umsatzsteuer
mit dem angegebenen % Satz in den Shop GHrundeinstellungen berechnet, Modul aktiviert und die Nettopreise werden leider mit dem Steuersatz berechnet was in den Ländergrundeinstellungen für das VAT Modul hinterlegt ist.
Schaltet man das Modul wieder aus, stimmt der Nettopreis wieder.

Liegt also definitiv und reproduzierbar am Modul und muss gefixt werden,
da die Berechnung so natürlich nicht stimmt bzw. die Shop Logik so verändert das sie nicht mehr stimmt.

Das ganze habe ich bereits im Bugtracker eingetragen:
https://bugs.oxid-esales.com/view.php?id=7696

Aber vielleicht auch ganz nüttlich als Information hier im Forum, für alle die das noch nicht bemerkt haben.

Viele Grüße,
Michael

2

Hallo Michael!

Vielen Dank, dass du dir die Zeit genommen hast, einen Bugeintrag zu machen.
Wir schauen uns das an und geben dir dazu Rückmeldung.

So eine Art Fehler hätte ich nach so langer Zeit im Modul eigentlich nicht mehr erwartet.

Viele Grüße,
Sven

3

Unsere erste Analyse hat ergeben, dass der Shop diesen Anwendungsfall nicht vollständig unterstützt.
Eigentlich sollten B2B-Kunden immer die Mehrwertsteuer aus dem Land des Shopbetreibers erhalten. Entweder abgezogen, wenn die angegebene Umsatzsteuer-Identifikationsnummer ungültig war, oder nur informativ, wenn sie gültig war.
Es gibt ein paar Probleme damit: Der Shop weiß (sofern nicht die B2B-Edition verwendet wird) nicht mit Sicherheit, ob ein Kunde ein B2B-Kunde ist.
Ein weiterer Aspekt, den wir anscheinend übersehen haben, ist die 10.000 EUR-Grenze, die ein Shop-Betreiber möglicherweise nutzen möchte.
In diesem Fall würde er auch nicht wollen, dass das Land des Kunden zur Anwendung kommt. Im einfachsten Fall könnte er einfach das Country-.VAT-Modul nicht verwenden, aber es könnte durchaus sein, dass er unterschiedliche Mengen in verschiedene Länder (innerhalb desselben Subshops) verkauft und es in einigen dennoch nutzen möchte.

Wir werden dies in einer der nächsten Versionen des Moduls berücksichtigen. Falls Du nicht so lange warten und dies selbst anpassen möchtest:
Wir denken, dass wir dies durch eine Erweiterung an dieser Stelle beheben können:

Das Hinzufügen einer Prüfung, ob der Benutzer ein B2B-Kunde ist und in diesem Fall das Land des Shop-Besitzers anstelle eines der Länder des Benutzers zurückzugeben, könnte dieses Problem bereits lösen.

Stay tuned,
Sven

4

Guten Morgen Sven,

ich bin da nicht so bewandert in Module anpassen / erweitern.
Technisches Verständnis habe ich ein gutes, Shopinstallation und Composer
bereiten mir mittlerweile auch keine Kopfschmerzen mehr, aber Programmierer bin ich nicht :wink:

Das ganze ist uns auch nur durch einen blöden Zufall aufgefallen:
Wir hatten einer Kundin Restbestände von speziellen Spinnakertüchern reserviert,
die dann online nicht mehr bestellbar waren.
Sie hatte uns dann per Mail eine Liste gesendet, wir haben dann in unserer WaWi einen
Auftrag angelegt und da die Ust.Id von ihr gültig ist, hat die WaWi natürlich korrekterweise
eine Nettorechung ohne Deutsche MwSt. ausgewiesen.

Ihr ist dann aufgefallen, dass die Preise im Onlineshop von denen in der manuellen Auftragsbestätigung abgewichen sind.
Dann habe ich mal geforscht woran das liegt.

Ist natürlich unglücklich, da das ganze nicht auffällt, wenn Aufträge automatisiert aus OXID importiert werden. Man prüft ja nicht bei jeder Bestellung nach, ob die Preise aus dem Shop auch korrekt sind.
Das betrifft ja auch nur die Bestellungen aus dem EU-Ausland, bei denen B2B vorliegt und eine korrekte UstID eingetragen wurde.
Aber natürlich ärgerlich, wir haben einige B2B Kunden aus Dänemark, die dann durch den Shop 25% abgezogen bekommen haben statt nur 19%.

Von daher wäre das ein wichtiger Fix finde ich.
Auf das VAT Modul verzichten können wir nicht, da wir die 10000€ Schwelle schon im Februar reißen, daher müssen wir eh den “One Stop Shop Gerümpel” machen :wink:

Viele Grüße,
Michael

5

Hallo Michael,

Für B2B-Kunden ist das definitiv ein Bug und sollte so nicht passieren. Das ist übrigens nicht nur so, wenn die korrekte UStID eingetragen ist. Die Regel gilt sobald es sich überhaupt um einen Firmenkunden handelt. Da dem Shop da bisher eine klare Unterscheidung fehlt, würde ich eine eingetragene UStID so oder so als “ich bin Firmenkunde” interpretieren und in dem Fall die Umsatzsteuer des Shopbetreibers verwenden.
Der Unterschied zwischen “gültige” und “ungültige” UStID ist dann nur in der Ausweisung der Steuer im Warenkorb zu finden.

Wenn ihr die Schwelle IMMER und in jedem Land reißt, dann ist ja zumindest für B2C-Kunden die Berechnung des Moduls korrekt.
Was ihr natürlich quasi als Workaround machen könntet, wäre, einen getrennten B2B-Shop einzurichten und dort das Modul einfach nicht zu aktivieren.
Der Aufwand dafür wäre aber natürlich nicht gerade gering. Bei hohen Umsätzen würde sich das aber ggf. sowieso anbieten, da B2B-Kunden auch gern spezielle Anforderungen bei der Ansprache und den gebotenen Funktionen haben (daher gibt es ja auch unsere B2B-Edition und einige Lösungen von unsereren Partnern).

Wir werden mal versuchen, ob wir das im Modul für die 7.2 noch unterbringen können. Das kann ich aber keinesfalls versprechen, da die Arbeiten dazu bereits im Gange sind und die Planung eigentlich abgeschlossen war.

Viele Grüße,
Sven

6

Hallo Sven,

ein extra B2B Shop lohnt sich nicht für uns, wir verkaufen fast ausschließlich B2C,
das wäre mit Kanonen auf Spatzen schießen.

Es wäre schön, wenn da in absehbarer Zeit ein Fix kommt, wir nutzen noch den
CE Shop 6.4.3 mit VAT Modul 1.0.4

Ich denke es gibt da auch durchaus noch den einen oder anderen Shop mit dieser oder
älterer Version “da draußen” die das ebenso betrifft.

Viele Grüße und schon mal ein schönes Wochenende,
Michael

7

@djelo Es gibt noch einen besseren Workaround: Den Shop im Nettomodus betreiben: Stammdaten->Grundeinstellungen->Einstell.->Mehrwertsteuer->
Artikelpreise netto eingeben (zuzüglich MwSt.)

Dann rechnet der Shop in jedem Fall korrekt.
Das eigentliche Problem ist nämlich, dass der Shop (bzw. das Country VAT-Modul) bei der Eingabe von Bruttopreisen den falschen Mehrwertsteuersatz für die “Rückrechnung” verwendet.

8

@SvenBrunk Das ist ein schöner Lösungsansatz, wir hatten das damals, als OSS aufkam, allerdings verworfen, da ein Modul von uns den Nettobetrieb nicht mochte und den Shop in den Wartungsmodus gebracht hat.

Ich habe das ganze einmal in einer Kopie von unserem Shop ausprobiert, mittlerweile kann ich das in den Nettomodus umstellen ohne das der Shop “abklappt”

Allerdings zeigt sich ein merkwürdiges Phänomen, was ich nicht so recht deuten kann:
Um nicht jeden Preis von Hand umändern zu müssen, habe ich das mit einer SQL Query
über PHP My Admin gemacht, benutzt habe ich dafür die Abfrage:

UPDATE oxarticles SET oxprice=round(oxprice/1.19 , 5);

Das hat auch funktioniert und die Preise sind im Backend auch Netto zu sehen und in Klammern der Bruttopreis.

Im Frontend zeigt sich nun aber die Merkwürdigkeit, dass bei Einzelartikeln der Bruttopreis korrekt angezeit wird, bei Variantenartikeln hingegen nicht.
Dort wird der alte Bruttopreis zzgl. Mwst angezeit.
Rufe ich den Variantenartikel im Backend auf, steht dort aber der korrekte Nettopreis und auch in Klammern der korrekte Bruttopreis.
Drücke ich beim Artikel nun einmal auf “Speichern” wird auch im Frontend der korrekte Bruttopreis angezeigt.

Als ob da noch irgendwo was im Cache ist.
Cache wurde aber natürlich gelöscht und Views habe ich auch aktualisiert.

Hast Du eine Idee woran das liegt?

Viele Grüße,
Michael

9

@djelo wo schaust du dir die Variante denn an? Wenn du sie auf der Detailseite auswählst oder auf der Produktübersichtsseite? Der Shop speichert auch die “von-bis”-Preise für die Varianten beim Vater-Artikel.
Wenn du also nur den Preis änderst, bleiben die varmin und varmax-Preise erstmal unverändert.

10

@SvenBrunk Guten Morgen Sven,

danke für den Hinweis, varminprice und varmaxprice habe ich in der Datenbank glatt übersehen,
das erklärt es dann.

Ich hatte das ganze im Frontend angeschaut, sowohl auf der Übersichtsseite als auch auf der Detailseite passte bei den Variantenartikeln der angezeigte Preis nicht.
Im Dropdown Menü stimmte er, nach Auswahl einer Variante wurde er auch richtig angezeigt.
Im Backend waren alle Preise ok.

Aber dadurch das es noch varminprice und varmaxprice gibt, hat er natürlich diesen genommen und dann noch die MwSt. raufgerechnet, daher die merkwürdigen Preise bei den Varianten.

Ich mach die Umrechnung noch einmal für die beiden Datenbankfelder, dann müsste es ja passen.

Nachtrag:
Das ganze funktioniert und nun werden auch im Frontend auch die korrekten Preise bei Varianten angezeigt.
Einen Nachteil hat diese Variante jedoch:
Wir hatten das ganze bisher so, das der Bruttopreis Länderunabhängig war (auch wenn das unseren Gewinn natürlich etwas geschmälert hat), also ein Produkt, was Brutto 100 € gekostet hat, hat diesen Preis auch in Dänemark gehabt.
Mit der Umstellung des Shops auf Nettopreise bekommt der Kunde den korrekten Preis erst nach Anmeldung bzw. Angabe der Lieferadresse angezeigt, aus 100 € werden dann auf einmal durch den anderen Steuersatz 105,04 €.
Rechtlich mag das ja in Ordnung sein, aber schön (und auf den ersten Blick transparent) ist das für den Endkunden nicht.
Ich denke wir werden da abwarten und hoffen, das es für das Modul einen zeitnahen Fix gibt.

Viele Grüße,
Michael