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

[LUGIUM]

Hallo zusammen,

wir schaffen es heute leider nicht mehr den Hotfix bereitzustellen. Der Hotfix soll ja nicht nur die Ermittlung korrigieren sondern auch schon bereits erstellte Vorgänge automatisch mit den eingerichteten Daten korrigieren, damit für euch keinerlei Nacharbeit an den von JTL-Wawi erstellten Vorgängen notwendig ist.

Gruß

Hallo @Markus Hütz, vielen Dank für die ehrliche und schnelle Antwort. So können wir die Zeit wenigstens produktiv nutzen und überlegen, wie wir damit umgehen.
Ist es evtl. möglich zwei Hotfixe bereit zu stellen? Einen, der ausschließlich die Funktion der Checkbox korrigiert und später dann einen der auch die bereits erstellten Vorgänge korrigiert?

Viele reine FBA Händler haben sicherlich gewartet und die Rechnungsstellung / den Auftragsimport pausiert. Diese könnten zumindest schonmal "gerettet" werden
Falls ihr diesen Fix so nicht bereit stellen könnt, habt ihr vielleicht eine Empfehlung für die Vorgehensweise, sodass man mit minimaler Arbeit das Ziel erreicht? Eventuell habt ihr hier andere Vorgehensweisen im Kopf, die uns noch nicht eingefallen sind, die uns aber ggf. sehr helfen würden.

Mir selbst fällt z.B. ein, dass man die Rechnungsvorlage temporär verändert, sodass bei Amazon die Rechnung korrekt hochgeladen wird. Also z.B. dass man in der Vorlage der Rechnung die Umsatzsteuer "hardcodiert" je nach Versandland und Lieferland. Vielleicht könnt ihr uns hier Tips und ggf. schon entsprechende Code-Schnipsel zur Verfügung stellen. Immerhin zahlen alleine wir pro Jahr knapp 5000 Euro für die Amazonschnittstelle, welche ja ohne eine ordentliche Rechnungsstellung nicht nutzbar ist und als geschäftskritisch einzustufen ist, wenn man Gefahr läuft von Amazon sanktioniert zu werden. Mir ist bewusst, dass Probleme auftreten und ich weiß euer Engagement, schnell Lösungen bereit zu stellen, auch sehr zu schätzen. Trotzdem muss ich einem Vorredner zustimmen, dass JTL notfalls länger arbeiten muss, um die von Ihnen abhängigen Kunden zu unterstützen.

 

[M°M]

Ich habe gerade nach einer Möglichkeit gesucht, mittels Workflow nach Aufträgen zu suchen, die Versandland x und Lieferland y haben. Ich bin hier nicht weitergekommen. Ich bin aber auch kein Servicepartner. Dazu kommt, dass ich nicht weiß, ob man über einen Workflow auch die USt.-ID setzen könnte.

Das Update in der DB zu machen ist wahrscheinlich möglich, sofern dem nicht die Begrenzung auf stored procedures entgegensteht.

Wer sich ein Backup anlegt würde aber sicherlich ein (oder mehrere) SQL ausführen wollen, welches in Abhängigkeit des Versandlandes und des Lieferlandes in den Aufträgen (cUStID in tBestellung ?) eine bestimmte USt.-ID setzt.

Wer das heute Abend noch auf die Beine stellt, hat möglicherweise bald ein paar Kunden mehr.

 

[seller77]

Mal eine ganz andere Frage. Wir nutzen noch die 1.5.38... und haben demnach diese (so wie ich das verstehe NOCH fehlerhafte) OSS-Option noch gar nicht an Board. Sollten wir auf die aktuellste Wawi-Version aktualisieren und läuft die stabil?

Habt ihr hierzu noch ein kurzes Statement?

 

[M°M]

Habt ihr hierzu noch ein kurzes Statement?

https://forum.jtl-software.de/threa...ne-stop-shop-ab-01-07-2021.159481/post-875950

 

[LUGIUM]

Vorabbemerkung für die Vorsichtigen: Bei der nachfolgenden SQL Abfrage handelt es sich um eine "SELECT" Anweisung. Es werden also nur Daten geholt / angesehen, NICHT geschrieben. Die Ausführung ist also gefahrlos möglich, es werden keine Veränderungen in dem Datenbestand vorgenommen!

Ich habe mir das grad einmal angeschaut und festgestellt, dass in der Datenbanktabelle tSteuerzone die Spalte nUStIdAusFirmenland hinzugefügt wurde. In dieser ist offensichtlich der Wert auf 1, wenn die Checkbox OSS angehackt wurde. Nun habe ich folgendes für das Rechnungsformular gebastelt, was bei mir funktioniert. Könnte das jemand gegenprüfen und als valide Übergangslösung bestätigen? Ich hoffe, dass ich damit einigen helfen kann. Ein Benutzer hat vorhin angemerkt, dass es beim Rechnungsexport / Datev noch Fehler gibt. Diese Fehler sind damit natürlich nicht behoben und werden erst durch die Aktualisierungen von JTL behoben. Das macht aber nichts, denn ein Rechnungsexport vom Juli wird ja frühestens im August benötigt (je nach individuellen Meldefristen). Meine Lösung ist sozusagen nur eine Schönheitsoperation, welche aber ein korrektes Rechnungsdokument erstellen sollte, bzw. die korrekte Umsatzsteuer ID auswerfen sollte. .

"VAT-ID: " +
COND( JTL_DirectQuery ("
SELECT count(*)
FROM tSteuerzone
JOIN tSteuerzoneLand ON tSteuerzoneLand.kSteuerzone = tSteuerzone.kSteuerzone
WHERE tSteuerzone.nUStIdAusFirmenland = 1 AND tSteuerzone.cLandIso = '"+Vorgang.Auftrag.Versandland.ISO  +
"' AND '"  + Vorgang.Auftrag.Lieferadresse.LandISO + "' =  tSteuerzoneLand.cISO")  = 1, "PLATZHALTER Deutsche UST ID", Vorgang.Auftrag.Firma.UstID)

Erläuterung:
Das Problem ist ja eigentlich nur, dass manchmal statt der benötigten deutschen UST-ID eine andere verwendet wird. Ich muss also nur im Problemfall die deutsche ID einfügen. Dazu suche ich in der Datenbank (tSteuerzone) nach dem Land von dem die Ware versendet wurde und ob der Wert nUStIdAusFirmenland = 1 ist, also OSS angewendet wird. Dann verknüpfe ich die Tabelle mit der Tabelle tSteuerzoneLand um noch zu prüfen, ob das Land in das versendet wurde auch dem des Auftrages entspricht. Wenn ich ein Ergebnis erhalte, dann ist es ein OSS Fall und hinterlege die deutsche Steuer ID.

Testen:
Da die Vorlagen auch auf bestehende Vorgänge angewendet werden, kann man das testen, ohne die Amazonaufträge abzuholen. Einfach Testweise entsprechende Vorgänge suchen und gucken, wie die Rechnung aussieht.

P.S. Habe es grad öfter getestet und es scheint ordentlich zu funktionieren. Immer wenn ich den OSS Haken gesetzt habe, wird die deutsche Steuernummer verwendet. Diesen Code Schnipsel kann man in der Vorlagenverwaltung in der Rechnungsvorlage da einfügen, wo vorher die UST ID angezeigt wurde. Den alten Wert kommentiert man einfach aus mit z.B. /* Wert zum auskommentieren */. Somit behaltet ihr ihn, müsst ihn nicht löschen und könnt später das obigen einfach wieder entfernen und die Zeichen zum auskommentieren /* */ rausnehmen.

Toll wäre, wenn jemand das von JTL noch einmal sichten könnte, sodass vielen ggf. die Unsicherheit genommen wird und sie dann beruhigt schlafen gehen können

 

[M°M]

Toll wäre, wenn jemand das von JTL noch einmal sichten könnte, sodass vielen ggf. die Unsicherheit genommen wird und sie dann beruhigt schlafen gehen können

Nicht von JTL aber für mich macht das Sinn. Wenn man schon auf Rechnung 2.0 (?) ist, müssten die Variablen ersetzt werden (BITTE ÜBERPRÜFEN!)

"VAT-ID: " +
COND( JTL_DirectQuery ("
SELECT count(*)
FROM tSteuerzone
JOIN tSteuerzoneLand ON tSteuerzoneLand.kSteuerzone = tSteuerzone.kSteuerzone
WHERE tSteuerzone.nUStIdAusFirmenland = 1 AND tSteuerzone.cLandIso = '"+Report.ShipFromCountryISO  +
"' AND '"  + Report.InvoiceShipToAddress.CountryISO + "' =  tSteuerzoneLand.cISO")  = 1, "PLATZHALTER Deutsche UST ID", Report.Company.ValueAddedTaxId)

 

[LUGIUM]

Vorabbemerkung für die Vorsichtigen: Bei der nachfolgenden SQL Abfrage handelt es sich um eine "SELECT" Anweisung. Es werden also nur Daten geholt / angesehen, NICHT geschrieben. Die Ausführung ist also gefahrlos möglich, es werden keine Veränderungen in dem Datenbestand vorgenommen!

Ich habe mir das grad einmal angeschaut und festgestellt, dass in der Datenbanktabelle tSteuerzone die Spalte nUStIdAusFirmenland hinzugefügt wurde. In dieser ist offensichtlich der Wert auf 1, wenn die Checkbox OSS angehackt wurde. Nun habe ich folgendes für das Rechnungsformular gebastelt, was bei mir funktioniert. Könnte das jemand gegenprüfen und als valide Übergangslösung bestätigen? Ich hoffe, dass ich damit einigen helfen kann. Ein Benutzer hat vorhin angemerkt, dass es beim Rechnungsexport / Datev noch Fehler gibt. Diese Fehler sind damit natürlich nicht behoben und werden erst durch die Aktualisierungen von JTL behoben. Das macht aber nichts, denn ein Rechnungsexport vom Juli wird ja frühestens im August benötigt (je nach individuellen Meldefristen). Meine Lösung ist sozusagen nur eine Schönheitsoperation, welche aber ein korrektes Rechnungsdokument erstellen sollte, bzw. die korrekte Umsatzsteuer ID auswerfen sollte. .

"VAT-ID: " +
COND( JTL_DirectQuery ("
SELECT count(*)
FROM tSteuerzone
JOIN tSteuerzoneLand ON tSteuerzoneLand.kSteuerzone = tSteuerzone.kSteuerzone
WHERE tSteuerzone.nUStIdAusFirmenland = 1 AND tSteuerzone.cLandIso = '"+Vorgang.Auftrag.Versandland.ISO  +
"' AND '"  + Vorgang.Auftrag.Lieferadresse.LandISO + "' =  tSteuerzoneLand.cISO")  = 1, "PLATZHALTER Deutsche UST ID", Vorgang.Auftrag.Firma.UstID)

Erläuterung:
Das Problem ist ja eigentlich nur, dass manchmal statt der benötigten deutschen UST-ID eine andere verwendet wird. Ich muss also nur im Problemfall die deutsche ID einfügen. Dazu suche ich in der Datenbank (tSteuerzone) nach dem Land von dem die Ware versendet wurde und ob der Wert nUStIdAusFirmenland = 1 ist, also OSS angewendet wird. Dann verknüpfe ich die Tabelle mit der Tabelle tSteuerzoneLand um noch zu prüfen, ob das Land in das versendet wurde auch dem des Auftrages entspricht. Wenn ich ein Ergebnis erhalte, dann ist es ein OSS Fall und hinterlege die deutsche Steuer ID.

Testen:
Da die Vorlagen auch auf bestehende Vorgänge angewendet werden, kann man das testen, ohne die Amazonaufträge abzuholen. Einfach Testweise entsprechende Vorgänge suchen und gucken, wie die Rechnung aussieht.

P.S. Habe es grad öfter getestet und es scheint ordentlich zu funktionieren. Immer wenn ich den OSS Haken gesetzt habe, wird die deutsche Steuernummer verwendet. Diesen Code Schnipsel kann man in der Vorlagenverwaltung in der Rechnungsvorlage da einfügen, wo vorher die UST ID angezeigt wurde. Den alten Wert kommentiert man einfach aus mit z.B. /* Wert zum auskommentieren */. Somit behaltet ihr ihn, müsst ihn nicht löschen und könnt später das obigen einfach wieder entfernen und die Zeichen zum auskommentieren /* */ rausnehmen.

Toll wäre, wenn jemand das von JTL noch einmal sichten könnte, sodass vielen ggf. die Unsicherheit genommen wird und sie dann beruhigt schlafen gehen können

Anmerkung: Am besten wäre es, wenn man einen Datumsvergleich hinzufügt, der die Abfrage nur macht, wenn das Versanddatum nach dem 30.06. ist. Ich habe die Variable jetzt nicht auf Anhieb gefunden und mache es daher manuell. Man sollte dann die Rechnungen nicht per Workflow erstellen lassen, sondern manuell prüfen welche vor dem 1.7. versendet wurden. Hier die alte Vorlage verwenden, Rechnung erstellen und dann zu Amazon hochladen. Erst nach erfolgtem Upload (im Log prüfen) sollten die Vorlagen umgestellt werden und dann die Rechnungen mit Versand nach dem 30.06. erstellt und zu Amazon hochgeladen werden. Stellt vor dem Amazonabgleich, sicher, dass die Rechnungen euch zusagen, da sonst die falsche bei Amazon liegt und man die nicht einfach löschen kann.

 

[Stephan K.]

"VAT-ID: " +
COND( JTL_DirectQuery ("
SELECT count(*)
FROM tSteuerzone
JOIN tSteuerzoneLand ON tSteuerzoneLand.kSteuerzone = tSteuerzone.kSteuerzone
WHERE tSteuerzone.nUStIdAusFirmenland = 1 AND tSteuerzone.cLandIso = '"+Vorgang.Auftrag.Versandland.ISO  +
"' AND '"  + Vorgang.Auftrag.Lieferadresse.LandISO + "' =  tSteuerzoneLand.cISO")  = 1, "PLATZHALTER Deutsche UST ID", Vorgang.Auftrag.Firma.UstID)

Danke für deinen Hotfix. viel schlimmer als das, was JTL mit der heißen Nadel gestochen hat, ist es auch nicht. Daher ja der Name.

Ich verleihe dir den Titel unbezahlter "Ehrenprogrammierer" für JTL für das, was die Firma nicht hinbekommt, obwohl Sie monatelang Zeit dafür hatte.
Für meine Zwecke reicht es jetzt erst einmal.

Dass JTL aus unlogischen Gründen den Fix nicht zweteilt, um den fix mit alten Fehler erstmal nicht zu korrigieren, obwohl uns die Zeit davon läuft und daher definitiv Fehler gemacht werden, ist mir absolut unverständlich.
Das ist heute fast schon die zweite Nachtschicht für idiotische Arbeiten, die uns JTL gerne mal gegen Bezahlung machen lässt...

 

[M°M]

Anmerkung: Am besten wäre es, wenn man einen Datumsvergleich hinzufügt, der die Abfrage nur macht, wenn das Versanddatum nach dem 30.06. ist. Ich habe die Variable jetzt nicht auf Anhieb gefunden und mache es daher manuell. Man sollte dann die Rechnungen nicht per Workflow erstellen lassen, sondern manuell prüfen welche vor dem 1.7. versendet wurden. Hier die alte Vorlage verwenden, Rechnung erstellen und dann zu Amazon hochladen. Erst nach erfolgtem Upload (im Log prüfen) sollten die Vorlagen umgestellt werden und dann die Rechnungen mit Versand nach dem 30.06. erstellt und zu Amazon hochgeladen werden. Stellt vor dem Amazonabgleich, sicher, dass die Rechnungen euch zusagen, da sonst die falsche bei Amazon liegt und man die nicht einfach löschen kann.

Report.ServiceDate ist das Lieferdatum

 

[M°M]

Anmerkung: Am besten wäre es, wenn man einen Datumsvergleich hinzufügt, der die Abfrage nur macht, wenn das Versanddatum nach dem 30.06. ist.

Vielleicht:

Cond( Report.ServiceDate >= Date("01.07.2021"), "TRUE", "FALSE")

Ich habe erst auf den 30.06. geprüft aber das berücksichtigt nicht 30.06.2021 15:21:00, also prüfen wir, ob das Versanddatum (Lieferdatum) nach dem 30.06.2021 23:59:59 Uhr liegt. Bei mir passt das.

 

[M°M]

Weil hier immer wieder die Diskussion zu gleichen Netto- / Bruttopreisen beim Verkauf in die EU aufkommt:

Durch einen Zufall habe ich eben bei Amazon unter "Einstellung" -> "Informationen zum Verkäuferkonto" -> dann mittig unter "Steuerinformation" -> Einstellungen zur Umsatzsteuerberechnung folgendes entdeckt:



Wer dann auf "Welcher Mehrwertsteuersatz gelten je PTC?" klickt wird feststellen, dass Amazon aus den übertragenen Bruttopreisen für Deutschland den entsprechenden Nettopreis errechnet und dann jeweils den landesspezifischen USt.-Satz aufschlägt, je nach Lieferland.

Amazon hält also den Nettopreis für alle Kunden konstant. (siehe unten)

P.S.: Amazon verwendet aktuell diese Tabelle



*Edit: Es wäre zu schön gewesen. Ich habe zwar noch keine eigene Rechnung geschrieben (für AT z.B.), habe aber eben gelesen, dass bei Bestellungen aus AT der Bruttopreis behalten und der Nettopreis angepasst wird.

 

[SebiW]

Ich habe auch schon mit dem Gedanken gespielt da einfach an der Rechnungsvorlage rumzubasteln. Was mir allerdings als Sorge bleibt ist: Was passiert mit den Aufträgen und einem möglichen JTL Fix.
Wenn die Rechnungen schon erstellt sind sollte der Auftrag ja eigentlich fixiert sein. Wird auch bei einem solchen Auftrag der Wert in der DB im Nachgang noch durch den geplanten Fix korrigiert?
Kann ja durchaus sein, dass man so eine Rechnung in ein paar Jahren nochmal ausgeben muss. Wäre verdammt unfein, wenn es da dann zu Abweichungen käme.
Gleiches gilt für Exporte aus dem System. Ich bin auch immer noch sehr unsicher, wie JTL2Datev sich da verhält.
Kann das jemand besser einschätzen?

 

[ChrisTS]

Falsche UVP @Manuel Pietzsch
Der Shop 4 ändert offensichtlich den UVP nicht ab. Da bleibt der UVP von Deutschland stehen
Dh. wenn ein Kunde aus einem Land mit höherer UST eingeloggt ist, sieht er seinen Preis und dazu einen geringeren UVP.
Als Kunde würde ich mir komisch vorkommen, wenn ich mehr als den UVP bezahlen muss

Siehe Anhang (p.S. ist auch ohne Plugin so)

 

[hula1499]

@Truckstyler

Wie hoch schätzt du das wohlwollen, wenn ein Kunde ein Produkt sieht, dass zum UVP verkauft wird? In Zeiten von 99% Rabatt, XY-Schlussverkäufe überall....

Aber natürlich hast du mit dem Bug recht.

 

[Stephan K.]

Weil hier immer wieder die Diskussion zu gleichen Netto- / Bruttopreisen beim Verkauf in die EU aufkommt:

Durch einen Zufall habe ich eben bei Amazon unter "Einstellung" -> "Informationen zum Verkäuferkonto" -> dann mittig unter "Steuerinformation" -> Einstellungen zur Umsatzsteuerberechnung folgendes entdeckt:

Den Anhang 66391 betrachten

Wer dann auf "Welcher Mehrwertsteuersatz gelten je PTC?" klickt wird feststellen, dass Amazon aus den übertragenen Bruttopreisen für Deutschland den entsprechenden Nettopreis errechnet und dann jeweils den landesspezifischen USt.-Satz aufschlägt, je nach Lieferland.

Amazon hält also den Nettopreis für alle Kunden konstant.

P.S.: Amazon verwendet aktuell diese Tabelle

Danke für den Hinweis! Man muss es tatsächlich einmalig aktivieren, damit es greift. Hierzu musste ich auch mein Standardland abwählen und neu auswählen, damit er es akzeptiert.
Ganz unten ist natürlich noch der Amazon Rechnungsservice standardmäßig aktiviert, den man kurz prüfen sollte.

 

[surus]

Hey, das Problem haben wir auch. Liegt laut JTL an folgendem Umstand:

seit heute (01.07.2021) werden neue Bestellungen durch Amazon offensichtlich über das Feld
"is-amazon-invoiced" als VCS Aufträge gekennzeichnet.
Dadurch werden diese in der Wawi für die Rechnungsstellung gesperrt.

Bitte prüfen Sie dies in den Bestellberichten im Sellercentral.
Wenn Sie dies auch dort in den Bestellberichten feststellen dass dieses Feld den Wert "true" aufweißt
bitte ich um Kontaktaufnahme zu Amazon.

Sollten die Bestellungen aufgrund eines Fehlers im Bericht gesperrt worden sein lassen sich diese
manuell entsperren.

Dazu selektieren Sie beliebig viele Bestellungen. Nach einem Rechtsklick wählen Sie
"Auftrag -> Auftrag zur Rechnungsstellung freigeben"

Hoffe, dass hilft weiter.

VG

Es ist bei uns leider auch so. Die Rechnungen wurden gestern abend nicht erstellt. Im Bestellbericht ist "is-amazon-invoiced" = true.
Wir benutzen kein VCS von amazon. Wie kann man es abstellen? Amazon habe ich angeschrieben, erfahrungsgemäss wird es aber Wochen dauern, bis der gute Inder es irgendwann verstehen wird, dass wir kein VCS Kunde sind und in den Bestellberichten "is-amazon-invoiced" = false stehen soll.
Ich habe es zwar in meiner Mitteilung an den Support direkt am Anfang, dann in der Mitte des Texte und abschliessend am Ende angegeben, dass wir kein VCS Kunde sind und wollen es nicht nutzen.
Wie die Erfahrung zeigt bekommen wir trotzdem als erste Antwort irgendetwas in der Art "Es ist so richtig, da Sie ein VCS Kunde sind". Dann dauert es Tage, biss jemand verstehen wird, dass es ein amazon Fehler ist und danach Wochen, bis es jemand umstellt.

Gibt es vielleicht eine schnellere Lösung?

Und wie prüfen wir am besten, welche Rechnungen noch erstellt werden müssen?

Ich habe folgendes gemacht.
1. Verkauf - Aufträge - Ohne Rechnung (Dropdown).
2. Tag Filtern
3. Alle Aufträge mit Lieferstatus "Verpack und versendet" finden und markieren.
4. Rechte Maustaste - Rechnung erstellen -> Rechnung erstellen auswählen.

Ist es so richtig?

Wird es danach automatisch bei amazon hochgeladen oder muss man dafür noch etwas tun?

 

[surus]

Danke für den Hinweis! Man muss es tatsächlich einmalig aktivieren, damit es greift. Hierzu musste ich auch mein Standardland abwählen und neu auswählen, damit er es akzeptiert.
Ganz unten ist natürlich noch der Amazon Rechnungsservice standardmäßig aktiviert, den man kurz prüfen sollte.

Und wenn wir überall den selben Brutto Preis haben möchten, was muss man dort einstellen?

 

[M°M]

Es wäre zu schön gewesen. Ich habe eben gelesen, dass Amazon den jeweiligen Bruttopreis mit dem individuellen USt.-Satz ansetzt, also die Bruttopreise gleich lässt und den USt.-Satz des Landes herausrechnet. Ich habe meinen Beitrag oben editiert.

 

[LUGIUM]

Ich habe auch schon mit dem Gedanken gespielt da einfach an der Rechnungsvorlage rumzubasteln. Was mir allerdings als Sorge bleibt ist: Was passiert mit den Aufträgen und einem möglichen JTL Fix.
Wenn die Rechnungen schon erstellt sind sollte der Auftrag ja eigentlich fixiert sein. Wird auch bei einem solchen Auftrag der Wert in der DB im Nachgang noch durch den geplanten Fix korrigiert?
Kann ja durchaus sein, dass man so eine Rechnung in ein paar Jahren nochmal ausgeben muss. Wäre verdammt unfein, wenn es da dann zu Abweichungen käme.
Gleiches gilt für Exporte aus dem System. Ich bin auch immer noch sehr unsicher, wie JTL2Datev sich da verhält.
Kann das jemand besser einschätzen?

Von Seiten JTL (Markus Hütz) wurde folgendes geschrieben:

Hallo zusammen,

wir schaffen es heute leider nicht mehr den Hotfix bereitzustellen. Der Hotfix soll ja nicht nur die Ermittlung korrigieren sondern auch schon bereits erstellte Vorgänge automatisch mit den eingerichteten Daten korrigieren, damit für euch keinerlei Nacharbeit an den von JTL-Wawi erstellten Vorgängen notwendig ist.

Gruß

Ich erwarte also, dass die Korrektur erfolgt. So richtig eine Wahl hatten wir auch nicht, da Amazon erwartet, dass mindestens 95% der Business Kunden innerhalb von 24 Stunden eine Rechnung erhalten. Amazon drohte regelmäßig in den Newslettern mit einer Kontosperrung, wenn die Statistik nicht eingehalten wird, sodass ich das nicht riskieren wollte. Wenn JTL jetzt ein paar Tage für den Fix braucht und das dann auch nicht rückwirkend behebt, ist es sehr problematisch. Ich bin aber zuversichtlich, dass JTL das machen wird, denn es kann nicht davon ausgegangen werden, dass alle JTL Kunden nun ungewiss ggf. tagelang ihr Geschäft ruhen lassen.

Ich saß nachts noch bis vier morgens, um die Rechnungen zu prüfen und die Rechnungen mit Versand vor dem 1.7. zu korrigieren, ich glaube aber es hat soweit funktioniert und bei Amazon liegen die Rechnungen mit der Korrekten UST und der korrekten UST Id. Die Einstellungen in der Steuerverwaltung (bis auf der OSS Haken) haben ja auch super funktioniert und führten zur korrekten Umsatzsteuerberechnung bzw. der Anwendung des korrekten Umsatzsteuersatzes.

Drücken wir die Daumen, dass JTL hier alles gibt und nicht dem Motto "Freitag ab 1 macht jeder seins" folgt

 

[SebiW]

Da wir nur relativ wenige Business Kunden haben habe ich die betroffenen Orders händisch separiert und umgestellt.
Die normalen Orders lasse ich jetzt erstmal unangetastet und hoffe auf einen zeitnahen Fix durch JTL.

Ansonsten schließe ich mich einfach mal @LUGIUM mit der Hoffnung auf einen baldigen Fix an.
Derzeit jagt echt ein Highlight das nächste. Falsche Steuerberechnung, falsch wegen externer Rechnung gesperrte Aufträge und jetzt haut Microsoft noch einen fetten Bug im Drucker Spooler raus.

Meine Fresse, hoffentlich brennt vor dem Wochenende nicht noch der Serverraum ab.