Falsche Rechnungsstellung ins EU-Ausland bei vorhandener USt-ID-Nummer

[Finsterone]

Hallo,

ich bin von PS 1.6 auf 8.1 umgestiegen und habe seitdem das Problem, dass Kunden, die ihre Umsatzsteueridentifikationsnummer hinterlegt haben, trotzdem die Mwst. berechnet wird. Hat jemand die gleiche Erfahrung gemacht und das Problem womöglich gelöst?

Gruß

René

[Nickz]

Hast du den 1.6 shop noch?

An deiner Stelle solltest du den neuen Shop Lokal aufziehen und checken.
Wie man Aktualisiert: Die Shops Startpunkt 1.6 und nicht sofort auf 8.1, sondern geht durch jede höhere Version bis man bei 8.1 ankommt.

[Finsterone]

Nee, der neue Shop ist jetzt schon ein paar Wochen live, da muss ich jetzt am lebenden Objekt herumbasteln. Natürlich gibt es da Work-arounds, aber meines Wissens musste ich in 1.6 nix einstellen und ein paar Versionen später funktioniert es nicht mehr?

[Nickz]

In einem VPS kannst du die PHP Versionen so lange laufen lassen bis du einen andern Shop brauchst.
Hostings die dich zwingen zu aktualisieren meide ich.

Der Unterschied zwischen 1.6 und 1.7 sind schon gewaltig, 17 kam ein Framework was dazu geführt hat das viele Module nicht weiterliefen wie gewohnt.

[rictools]

In Prestashop gibt es das Modul vatnumber, in dem man das eigene Land einstellt. Ab 1.7 wurde Prestashop ja abgespeckt, für aktuelle Versionen gibt es z. B. diesen Fork des Moduls:

https://www.silbersaiten.de/en/administrationstools/366-vat-number-prestashop-module.html

Ob man das jetzt braucht, weiß ich nicht, ich habe ja noch 1.6.

[Finsterone]

Ich habe mal das Tool von Silbersaiten installiert. Ist ne feine Sache, wenn man die USt-ID überprüfen möchte, die man vom Kunden geliefert bekommt - auch wenn sie etwas langsam ist (liegt am Webservice). Aber mit dem Vorgang innerhalb von PS hat das nichts zu tun. Ich habe einen österreichischen Beispielkunden angelegt und der bekommt eine wenig vertrauenserweckende Nachricht: Die Bestellbestätigung zeigt den Betrag ohne Mwst., die Zahlungsaufforderung ist der Betrag mit Mwst. - absurd.

 

Edited June 18 by Finsterone (see edit history)

[rictools]

Das macht (sofern nicht danach noch die Bankdaten folgen) gar keinen Sinn, würde ich entweder per CSS-Anweisung "display: none;" ausblenden oder schauen, welche Variablen verwendet werden (für die 14,17 und für die 16,87 €, du müßtest die zweite ja gegen die erste ersetzen können). Oder du blendest den Betrag aus und schreibst nur "Bitte überweisen Sie den Gesamtbetrag an ...". Das würde ich vor den Satz setzen, dass die Bestellung abgeschlossen ist.

Ist das die einzige Stelle, wo der Betrag inkl. MwSt. genannt wird? Dann müßte das Modul doch etwas bewirkt haben, es sei denn ich habe deinen Eingangspost komplett falsch verstanden.

[Finsterone]

Die Bankdaten habe ich jetzt tatsächlich ausgeblendet, da kommt noch etwas hinterher. In der Tat könnte ich die Variablen austauschen bzw. gleichsetzen, aber das löst das Problem nicht: Kunden ohne USt-ID müssen tatsächlich den im Moment unten aufgeführten Betrag überweisen, aber nicht andere Unternehmen mit einer gültigen Umsatzsteuer-ID, die halt den Betrag ohne Umsatzsteuer. Wenn ich es richtig deute, müsste im Programm bei vorhandener USt-Id der Steuersatz auf 0% gestellt werden, so dass die beiden Variablen, also die mit Ust.-Ausweis und die ohne Ust.-Ausweis, den gleichen Wert bekommen.

[Finsterone]

Fun fact: Beim Versand in die Schweiz, wo nie Ust. ausgewiesen wird, klappt alles.

[rictools]

In die Schweiz (und andere Nicht-EU-Länder) erfolgt die Lieferung ja generell umsatzsteuerfrei.

Wird denn, wenn ein Privatkunde (ohne UID) aus Österreich bestellt, nicht der Betrag inkl. MwSt. angezeigt? Dann ist die Frage, ob für die Gesamtsumme die gleiche Variable verwendet wird (die zuvor unterschiedlich berechnet wird), dann kannst du die nach unten kopieren. Ansonsten streiche den Betrag an dieser Stelle halt komplett.

 

[Finsterone]

Wenn ein Privatkunde bestellt, bekommt er die Ware ganz normal mit Mwst. angezeigt. Das funktioniert. Ich kann vielleicht das System auch dahin bringen, dass die richtigen Beträge in der Bestellbestätigung angezeigt werden, das löst das grundsätzliche Problem jedoch nicht, dass die Rechnungen falsch ausgestellt werden. Prestashop müsste eine IF THEN-Abfrage bereit halten, dass, wenn eine UID vorliegt, keine USt berechnet wird. Und offenbar tut es das nicht. Und was mich noch mehr wundert: Bin ich der einzige, der hier im Forum B2B ins Ausland verkauft?

[rictools]

Wir sollten erst einmal klären, wo der Fehler denn nun genau auftritt, bisher war nur von der Bestätigungsseite nach Absenden der Bestellung die Rede, nicht z. B. von der PDF-Rechnung oder E-Mails.

[Finsterone]

Grundsätzlich gebe ich Dir recht, doch je länger ich mich mit der Thematik beschäftige desto mehr tippe ich auf einen Programmierfehler. Bereits die Berechnung der Bestellsumme (Produktsumme + Versandkosten) ist fehlerhaft. Ich habe beispielsweise einen separaten Versand eingerichtet, der nur EU-Businesskunden zugeordnet wird. Die Versandkosten enthalten dann keine Umsatzsteuer. Bestellt so ein Kunde, wird auf die Versandkosten keine USt erhoben, aber den Produkten wird trotz vorhandener UID Umsatzsteuer aufgeschlagen.
Und natürlich setzt sich dieser Fehler in den Rechnungen fort, die ja nur die Ergebnisse der internen Operationen widerspiegeln. Die zugeordneten Werte sind schlicht falsch.

[rictools]

Ich blicke immer noch nicht durch. Oben auf deinem Screenshot sind die Zahlen doch korrekt (abgesehen von den 16,87 €) oder? Wie sieht es im Warenkorb und auf der Kassenseite aus? Wie im BackOffice?

In der PDF-Rechnung verwende ich eine if-Bedingung, um bei umsatzsteuerfreien Lieferungen einen darauf abgestimmten Text einzufügen, das kannst du abwandeln:

{if $tax_exempt}
		<tr>
				<td><div style = "font-size: 9pt; font-weight: bold; width: 100%">{l s='Umsatzsteuerfreie innergemeinschaftliche Lieferung' pdf='true'}<br />Ihre USt-IdNr. / UID / TVA / VAT / BTW: {$addresses.invoice->vat_number}</div></td>
		</tr>
		{else if (($order_invoice->total_paid_tax_incl - $order_invoice->total_paid_tax_excl) == 0)}
		<tr>
				<td><div style = "font-size: 10pt; font-weight: bold; width: 100%">{l s='Umsatzsteuerfreie Ausfuhrlieferung' pdf='true'}</div></td>
		</tr>
	{/if}

[Finsterone]

Ich versuche das noch einmal zusammenzufassen:
In PS 1.6 wurde jede Bestellung mit Mwst. ausgewiesen, es sei denn sie ging ins Ausland (Nicht-EU-Staaten) oder eine UID lag vor. Dieses Erkennen, dass eine UID vorliegt, funktioniert in PS 8.1 nicht, die Umsatzsteuer wird immer ausgewiesen. Damit die Rechnung hier stimmt, muss ich eine neue Kundengruppe anlegen, dieser umsatzsteuerfreien Versand definieren und beim Design der Rechnung als Rechnungsbetrag den Nettobestellwert inkl. Nettoversandkosten nehmen. Das ist aufwändig und nur ein Work-around, aber das schlimmste ist, dass fast alle Kunden bei mir per Paypal oder Kreditkarte bezahlen. Und der von Presta errechnete Rechnungsbetrag beinhaltet immer die Mwst., das heißt, sie müssen zu viel überweisen. Und ich muss später die Rechnungen um die Umsatzsteuer kürzen und die Differenz erstatten. Mega lästig.
Daher frage ich mich, ob dies noch niemandem aufgefallen ist oder ob ich übersehen habe einen Haken zu setzen, der zum gewünschten Ergebnis führt.

Hilft das?

Gruß und danke für deinen Einsatz

[rictools]

Dann verstehe ich deinen Screenshot immer noch nicht (ist das jetzt ein Kunde in der USt.-freien Kundengruppe?).

Das funktioniert auch mit dem Modul von Silbersaiten nicht anders? Du hast dort Deutschland als Land eingestellt?

Es handelt sich nicht um einen originalen Prestashop 8, sondern du hast von 1.6 aus geupgradet?

[Finsterone]

29 minutes ago, rictools said:

Dann verstehe ich deinen Screenshot immer noch nicht (ist das jetzt ein Kunde in der USt.-freien Kundengruppe?).

>>>Genau, und dieser Kunde bekommt im oberen Teil die richtige Summe (14,17 €) angezeigt, doch für die Rechnung bzw. Paypal etc. wird die unten stehende (16,87 €) verwendet.

Das funktioniert auch mit dem Modul von Silbersaiten nicht anders? Du hast dort Deutschland als Land eingestellt?

>>>Das Modul ist aktiv, nur den Webservice zur Verifizierung der UID habe ich ausgeschaltet, weil er sehr langsam ist.

Es handelt sich nicht um einen originalen Prestashop 8, sondern du hast von 1.6 aus geupgradet?

>>>Genau, ich habe keine Neuinstallation gemacht sondern mittels Add-on geupgradet.

 

[rictools]

Dann haben wir es im Grunde mit zwei verschiedenen Problemen zu tun.

Noch mal: Du hast im Modul Deutschland als Land eingestellt?

Es kann gut sein, dass das Problem nur bei einem von 1.6 upgegradeten Shop auftritt. Hattest du stufenweise upgegradet (vgl. Post von Nickz)? Hast du mal den Inhalt des Ordners var/cache gelöscht?

[Finsterone]

Also, ich habe das Gefühl, dass Du mir nicht glaubst, bevor ich Dir ein Bild poste, aus dem ersichtlich wird, dass Deutschland im Add-on eingestellt ist. Ergo s. Anhang.

Ich habe mir von PrestaHero 1 Click to Upgrade geholt und in einem Rutsch von 1.6 auf 8.1 geupdatet. Da hier im Forum niemand reagiert oder ähnliche Erfahrungen gemacht zu haben scheint, ist es gar nicht so unwahrscheinlich, dass der Fehler während des Upgrade-Prozesses passiert ist.

[rictools]

Ich glaube dir schon, aber du hast dich dazu nicht geäußert und an dieser Stelle gibt es mitunter Mißverständnisse.

Auf die Frage nach dem Cache löschen hast du auch nicht geantwortet. Ansonsten fürchte ich, dass da ein Profi ran muss ... Vielleicht kannst du ja den Modulautor kontaktieren.

[Nickz]

1 hour ago, Finsterone said:

Ich habe mir von PrestaHero 1 Click to Upgrade geholt und in einem Rutsch von 1.6 auf 8.1 geupdatet.

Siehe hier

Der Update von 1.6 auf 8.1 geht so gut wie nie 100% durch. Vor einem Update macht man einen Backup.

Den Backup ziehst du dann lokal auf, wenn der läuft dann kannst den aktualisierten Shop hochladen.

[Finsterone]

Tja, das ist dann wohl Pech, da war ich naiv, dass das so einfach gehen würde. Zur Erläuterung: Ich wurde im Januar gehackt, jemand versuchte Kreditkartendaten von meinen Kunden zu bekommen, was ihm glücklicherweise nur in einem Fall - ohne Schaden - gelang. Aus diesem Grund entschied ich mich zu einem Upgrade, weil ich im fransösich-sprachigen Forum auf einen Beitrag stieß, dass das wohl eine bekannte Sicherheitslücke in 1.6 sei. Die alte Version liegt natürlich noch vor, ein Backup ist also vorhanden, aber das nützt nichts, da die Welt sich weiter dreht und ich dann alle in der Zwischenzeit getätigten Bestellungen implementieren müsste. Das Chaos und den Arbeitsaufwand mag ich mir gar nicht vorstellen. Da wir nicht so viele B2B-Kunden in Österreich haben, haben wir den Fehler erst relativ spät bemerkt, das kam dazu.

Und "hätte, hätte, Fahrradkette" ist jetzt auch nicht mehr zielführend, ich frage mich, ob ein Update auf 8.1.4 den Fehler theoretisch beheben könnte.

Achja, den Cache hatte ich gelöscht.

[Nickz]

59 minutes ago, Finsterone said:

Die alte Version liegt natürlich noch vor, ein Backup ist also vorhanden, aber das nützt nichts,

sattel um zu Thirtybees. das ist ein Fork der 1.6 version und läuft über php8.1 Kontaktformulare laufen über die Datenbank und über SQL Injection kommt es häufiger zu gehacke.

[Netagent]

Also soweit ich das hier lese und verstehe, werden die (ehemals im 1.6er Shop eingetragenen) Vat Nummern nicht mehr berücksichtigt (bzw. erkannt). Korrekt?

Falls dem so ist, sind wahrscheinlich im Zuges des Updates die vorhandenen Vat Nummern schlicht in einer falschen Tabellenspalte hinterlegt worden. Das ist sehr oft der Fall, da die 1.6er Version noch nicht für das (deutsche) B2B optimiert war und somit die "französischen" Spalten (z.B. Siret) in der "ps_customer" Tabelle oft zweckentfremdet wurden. Und diesen Zustand hast du mit in die 8er Version genommen. Daher werden die jetzt nicht mehr erkannt. 

Schau dir das Modul hier mal an: https://addons.prestashop.com/de/buchhaltung-rechnung/27158-european-vat-number.html

Das erkennt (nach meiner Erfahrung) eigentlich alle möglichen Vat Einträge in verschiedenen Tabellenspalten und überprüft diese dann automatisch (Angabe jetzt ohne Garantie 😉 ). Einmal erkannt und positiv getestet, werden diesen Kunden auch die korrekten Nettopreise angezeigt - auch auf der Rechnung.

Falls das Modul die vorhandenen Vat- nummern nicht erfasst, bzw. erkennt, müsste man die eben manuell in die korrekte Tabellenspalte schieben. Das wäre dann die Spalte "vat_number" in der Tabelle "ps_address".

Es ist natürlich möglich, dass das Modul von "Silbersaiten" das auch so handhabt - nur kenne ich das nicht und kann daher nichts dazu sagen. Bei dem o.g. Modul habe ich bisher keine Schwierigkeiten und es funzt wie es soll.

 

Gruß Dirk 

[Finsterone]

Hallo Dirk,

wenn Du mit Deiner Vermutung richtig lägst, würde das Phänomen doch nicht bei neu angelegten Kunden auftreten, oder? Die Kundin, die mich auf den Fehler aufmerksam gemacht hat, hat ihren Account aber erst nach der Umstellung auf PS 8.1.3 angelegt.

Wäre ansonsten eine geniale Lösung gewesen.

Gruß

René

[Claudiocool]

Kurze Frage:

Ich hab das Modul im 8.1.7 installiert, kann aber dennoch problemlos Fantasienummern eingeben, ohne dass der meckert. Glücklicherweise werden aber auch die Kundensettings nicht geändert, der zahlt weiter die Mwst. 

Was muss man denn noch einstellen?

[rictools]

Auf dem ersten Screenshot auf der Modulseite sehe ich entsprechende Einstellungen.

[Finsterone]

Hat sich Dein Problem geklärt? Wenn Du die VAT-IDs checken lässt, dann verzögert sich der Prozess, weil die Validierung einfach einen Augenblick dauert. Bei mir ist es leider noch immer so, dass aber egal, ob ich eine (gültige oder ungültige) USt-Id eingebe oder nicht, immer die Mwst. berechnet wird. Sucks.

Und ich gehe davon aus, dass Du die von rictools angesprochene Modulseite gesehen und eingestellt hast.

[Claudiocool]

ich hab jetzt das genommen, das funktioniert:

[FREE MODULE] Vat checker - Free Modules & Themes - PrestaShop Forums

https://www.prestashop.com/forums/topic/1066616-free-module-vat-checker/

[Netagent]

vor einer Stunde schrieb Claudiocool:

ich hab jetzt das genommen, das funktioniert:

[FREE MODULE] Vat checker - Free Modules & Themes - PrestaShop Forums

https://www.prestashop.com/forums/topic/1066616-free-module-vat-checker/

Sieht doch gar nicht mal so schlecht aus. Haben zwar einige damit viele Probs gehabt, aber wenn es jetzt wirklich funktioniert, wäre das natürlich gut. Und etwas günstiger ist es ja auch 😉

[Claudiocool]

Läuft gut, man muss halt auch drauf achten, dass man bei den Europ. Settings einstellt, dass der Versand anteilmäßig die Steuer der Ware hat, was dann 0% ist