Neu EU-weite Lieferschwelle und One-Stop-Shop ab 01.07.2021

[timmken]

Gut, es scheinen ja mehrere zu bestätigen. Vielen Dank für eure Mühe. Ihr habt ja sicherlich ein Backup, sodass ihr nicht alle händisch ändern müsst, sondern auf ein Update ggf. warten könnt.
JTL scheint ja dran zu sein, dies zu prüfen, sodass es bald Infos geben wird.

das Backup wird zumindest uns wenig nutzen, da wir schon seit einigen Stunden wieder versenden. Wichtig wäre ein manueller Workflow der die ID umstellen kann.

 

[smandrew]

Hallo,
wir haben das SQL Script heute um 0:01 durchgefüht und das hat auch bei Versandland GB (wir haben eine GB USt-ID) Zonen für alle EU-Länder angelegt.
Seit Brexit könnten die EU-Länder aber weiterhin in der EU-Zone bleiben, da GB nicht mehr EU Mitglied ist, oder?
Und bei Lieferungen von GB nach EU (z.B. DE) sollte die GB USt-ID auf die Rechungen kommen, da die Steuer in GB abgeführt wird.
In der WaWi wird aber unsere DE USt-ID bei Versand GB Zone EU angezeigt. Meiner Meinung nach ist es falsch.
Ist das ein Bug, oder wie habt ihr das gelöst?

 

[Stephan K.]

Also diesmal muss JTL richtig Gas geben und sauber arbeiten. In weiser Voraussicht wurde die Rechnungsstellung seit Mitternacht deaktiviert. Man hat 24 Std. Zeit, um Rechnungen bei Amazon hochzuladen.
Gestern blieben seitens der Moderation noch ein paar Fragen offen, um die sich gekümmert werden sollte. Da ist bis heute keine Rückmeldung erfolgt. So wichtig scheint die eigene Wawi also nicht zu sein, wenn da keine Nachtschicht für die bugs existiert, um die vielen tausenden von Händlern nicht nur die gleiche Arbeit machen zu lassen, sondern Ihnen auch noch das richtige Werkzeug in die Hand zu geben.

Es nützt nichts, wenn das OSS-Verfahren angewandt wird, aber keine Variable das Ursprungslandprinzip ausgeben kann. Somit ist FBA-Versand aus dem Versandlager (="Firma") auch immer die UST-ID, die ausgegeben wird...

 

[LUGIUM]

Also diesmal muss JTL richtig Gas geben und sauber arbeiten. In weiser Voraussicht wurde die Rechnungsstellung seit Mitternacht deaktiviert. Man hat 24 Std. Zeit, um Rechnungen bei Amazon hochzuladen.
Gestern blieben seitens der Moderation noch ein paar Fragen offen, um die sich gekümmert werden sollte. Da ist bis heute keine Rückmeldung erfolgt. So wichtig scheint die eigene Wawi also nicht zu sein, wenn da keine Nachtschicht für die bugs existiert, um die vielen tausenden von Händlern nicht nur die gleiche Arbeit machen zu lassen, sondern Ihnen auch noch das richtige Werkzeug in die Hand zu geben.

Es nützt nichts, wenn das OSS-Verfahren angewandt wird, aber keine Variable das Ursprungslandprinzip ausgeben kann. Somit ist FBA-Versand aus dem Versandlager (="Firma") auch immer die UST-ID, die ausgegeben wird...

Ja, wir haben es genauso gemacht und hoffen es in der 24 Stundenfrist zu lösen (ich habe es um 23 Uhr deaktiviert), notfalls müsste man im Übergang in der Vorlagenverwaltung das Hardcodieren, also z.B. je nach Liefer-Versand-Land die UST ID drauf drucken. Ich denke, das ist besser, als sich mit Amazon anzulegen oder hunderte falsche Rechnungen hochzuladen, die historisch in alle Ewigkeit deinen Fehler dokumentieren und du daher eigentlich offiziell die Rechnungen Stornieren und neu anlegen müsstest.
Ich bin aber zuversichtlich, dass JTL hier was bringen wird, denn sie sind ja schon dran und eine Behebung des Fehlers sollte auf Programmebene nicht so schwierig sein.

 

[LUGIUM]

Hallo,
wir haben das SQL Script heute um 0:01 durchgefüht und das hat auch bei Versandland GB (wir haben eine GB USt-ID) Zonen für alle EU-Länder angelegt.
Seit Brexit könnten die EU-Länder aber weiterhin in der EU-Zone bleiben, da GB nicht mehr EU Mitglied ist, oder?
Und bei Lieferungen von GB nach EU (z.B. DE) sollte die GB USt-ID auf die Rechungen kommen, da die Steuer in GB abgeführt wird.
In der WaWi wird aber unsere DE USt-ID bei Versand GB Zone EU angezeigt. Meiner Meinung nach ist es falsch.
Ist das ein Bug, oder wie habt ihr das gelöst?

ist mir im Testsystem auch aufgefallen und hab daher GB rausgenommen:

 

[SebiW]

Also diesmal muss JTL richtig Gas geben und sauber arbeiten. In weiser Voraussicht wurde die Rechnungsstellung seit Mitternacht deaktiviert. Man hat 24 Std. Zeit, um Rechnungen bei Amazon hochzuladen.
Gestern blieben seitens der Moderation noch ein paar Fragen offen, um die sich gekümmert werden sollte. Da ist bis heute keine Rückmeldung erfolgt. So wichtig scheint die eigene Wawi also nicht zu sein, wenn da keine Nachtschicht für die bugs existiert, um die vielen tausenden von Händlern nicht nur die gleiche Arbeit machen zu lassen, sondern Ihnen auch noch das richtige Werkzeug in die Hand zu geben.

Es nützt nichts, wenn das OSS-Verfahren angewandt wird, aber keine Variable das Ursprungslandprinzip ausgeben kann. Somit ist FBA-Versand aus dem Versandlager (="Firma") auch immer die UST-ID, die ausgegeben wird...

Haben wir genauso gelöst. Allerdings kann man zumindest für die Aufträge, die aus DE Lagern (oder eben dem Lager in dem man OSS gemeldet ist) versendet werden ja schon gefahrlos die Rechnungen erstellen. Gleiches gilt bei PAN EU bei Lieferungen, bei denen Versand&Lieferland identisch sind.
Auch wäre es schlauer von mir gewesen den OSS Haken für Deutschland in keinem der Lieferländer zu setzen ... damit wären die auch alle korrekt. Naja, wieder was gelernt.

Kann mir eigentlich nochmal einer sagen warum ich Depp nicht einfach Schäfer geworden bin?

 

[Stephan K.]

Fehler Export mit Ameise:

Test
Nur DE UST-ID
Versand nach Frankreich per OSS mit 20%.
OSS in Steuereinstellung FR aktiviert/nicht aktiviert

Der Datensatz wird als fehlerhaft markiert und nicht exportiert. Möchte man ihn exportieren und klickt "Steuereinstellungen nicht beachten" an, dann fehlen natürlich die Steuerschlüssel im Export.

Also der optische Export der korrekten Rechnung mit hardcoded UST-ID ist eine Teillösung, die aber tieferliegende Probleme nicht lösen wird.

 

[Stephan K.]

Auch wäre es schlauer von mir gewesen den OSS Haken für Deutschland in keinem der Lieferländer zu setzen ... damit wären die auch alle korrekt. Naja, wieder was gelernt.

Wie meinst du das? Also bei Globalen Einstellungen (Deutschland) für alle Länder den Haken wegmachen?

 

[lxshld]

Hi,

wir haben folgendes Setup

- Taric Codes hinterlegt und überall geprüft (überall Standardsatz)
- USt-IDs in DE, AT, FR, PL, CZ, UK

Können wir das Setup mit dem Script so umsetzen?

 

[Don-Filipe]

Wir haben heute Nacht mit go-oss umgestellt und das Plug in von Webstollen "OSS Lieferland" installiert.

Alles perfekt geklappt, kleinere Macken, bzw. ein Problem mit go-OSS wurde gleich heute Morgen von Go-Ecommerce behoben.

40k Artikel sind allen Lieferländern steuerrechtlich zugeordnet, erste Rechnungen richtig erstellt.

Danke an dieser Stelle an Go-Ecommerce

 

[SebiW]

Wie meinst du das? Also bei Globalen Einstellungen (Deutschland) für alle Länder den Haken wegmachen?

Ne anders rum, in jedem Versandland das nicht DE ist den Haken bei DE weg nehmen. Damit wird die UID des Lieferlandes DE verwendet was an dieser Stelle ja erstmal korrekt wäre.
Hätte zumindest Polen und Tschechien für uns wahrscheinlich entschärft. Sollte heute nix von JTL kommen werd ich das wohl nachmittags riskieren.

Zwecks Deinem Export Test 1 oben drüber - ich bin mal sehr gespannt was JTL2Datev da für Daten kriegt. Stand jetzt siehts ja doch etwas nach Clusterfuck aus.

 

[Marcel85]

Fehlermeldung „Für die Firma ist für das Versandland keine Umsatzsteuer-Identnummer eingerichtet“

Wir versenden ausschließlich aus Deutschland. Nachdem ich nun alle Länder-Zonen erstellt habe (bis auf DE habe ich in allen EU-Ländern den Haken bei „Steuern über Versandland abführen (OSS-Verfahren)“ aktiviert), taucht beim nächsten Öffnen der Steuerverwaltung der o.g. Hinweis auf.
In den Firmeneinstellungen ist für Deutschland eine USt.-IdNr. hinterlegt und das Häckchen „Auch Versandland“ ist aktiv.

Was könnte nun diese Fehlermeldung auslösen?

Wir haben das gleiche Problem.

 

[Stephan K.]

Ne anders rum, in jedem Versandland das nicht DE ist den Haken bei DE weg nehmen. Damit wird die UID des Lieferlandes DE verwendet was an dieser Stelle ja erstmal korrekt wäre.
Hätte zumindest Polen und Tschechien für uns wahrscheinlich entschärft. Sollte heute nix von JTL kommen werd ich das wohl nachmittags riskieren.

Zwecks Deinem Export Test 1 oben drüber - ich bin mal sehr gespannt was JTL2Datev da für Daten kriegt. Stand jetzt siehts ja doch etwas nach Clusterfuck aus.

Kann ich nicht bestätigen.

In beiden Ländern UST-ID

PL -> DE
mit/ohne Haken
immer PL-UST-ID

 

[SebiW]

Kann ich nicht bestätigen.

In beiden Ländern UST-ID

PL -> DE
mit/ohne Haken
immer PL-UST-ID

Hast Du in Deiner polnischen Versandzone für DE ne eigene Lieferzone hinterlegt? Und ganz wichtig: JTL wertet den Haken bei ERSTELLUNG des Auftrags aus. Wenn Du also nur einen Auftrag anschaust und hin und her switcht siehst Du den Unterschied nicht. Du musst tatsächlich einen ganz neuen Auftrag anlegen, auch duplizieren hat bei uns Probleme in der Nachvollziehbarkeit gemacht.

 

[Stephan K.]

Hast Du in Deiner polnischen Versandzone für DE ne eigene Lieferzone hinterlegt? Und ganz wichtig: JTL wertet den Haken bei ERSTELLUNG des Auftrags aus. Wenn Du also nur einen Auftrag anschaust und hin und her switcht siehst Du den Unterschied nicht. Du musst tatsächlich einen ganz neuen Auftrag anlegen, auch duplizieren hat bei uns Probleme in der Nachvollziehbarkeit gemacht.

Ich habe jetzt ein paar Aufträge nach vorherigem Backup angelegt.

für Deutschland scheint es zu funktionieren, wenn ich den Haken rausnehme.

Anderes Beispiel PL & CZ
beide mit UST-ID

CZ -> PL
mit Haken CZ UST-ID
ohne Haken PL UST-ID

es müsste die deutsche dastehen.

 

[Markus Hütz]

Hallo zusammen,

wir haben die Ermittlung geprüft und leider ist die Ermittlung der UstID im Falle von einem vom Firmenland abweichenden Versandland in der Tat falsch. Somit ist die UstID in den entsprechenden Aufträgen und Rechnungen falsch.

Hierfür arbeiten wir gerade an einem Hotfix für JTL-Wawi 1.5 sowie für die Pilotversion von JTL-Wawi 1.6!

Folgende Punkte werden angepasst und korrigiert:

1. Im Falle eines von Firmenland abweichenden Versandlandes wird bei aktivem OSS-Verfahren die UstID vom Firmenland herangezogen und nicht mehr die UstID vom Versandland.
2. Im Update wird die UstID der betroffenen (ab 01.07.2021) fehlerhaften Aufträgen und Rechnungen mit der richtigen UstID überschrieben und die korrigierten Datensätze werden ausgewiesen.

Gruß

https://issues.jtl-software.de/issues/WAWI-56107

 

[fashioncase]

Im Update wird die UstID in den fehlerhaften Aufträgen und Rechnungen mit der richtigen UstID überschrieben und die korrigierten Datensätze werden ausgewiesen.

@Markus Hütz
Das darf natürlich nur bei Aufträgen mit Versand ab 01.07.2021 erfolgen!!!

 

[Sven17]

Wir haben das gleiche Problem.

Bei uns ebenfalls, allerdings scheint wohl alles sonst zu laufen. Wir haben zum Glück auch nur den Versand auch Deutschland.

 

[SebiW]

@Markus Hütz
Das darf natürlich nur bei Aufträgen mit Versand ab 01.07.2021 erfolgen!!!

Ich kann gar nicht genug betonen, wie unglaublich wichtig der Kommentar von @fashioncase bei der Umsetzung ist.
Danke für diesen extrem wichtigen Einwurf!

 

[MichaelH]

Als Hinweis, wenn jemand bitte noch testen wollen würde ...
... funktioniert, ABER nicht mit jedem Land, was mir ein großes Rätsel ist, denn die Stammdaten sind identisch, nur eben anderer Steuerschlüssel und anderes FIBU-Konto:

https://forum.jtl-software.de/threads/oss-export-bug.161356/