Neu Amazon Promition Fix - Einsicht vor Ausführung?

[dekodi]

Die Diskrepanz findet man nur, wenn man JTL2DATEV oder Taxdoo einsetzt, bei denen die externen Amazon Reporte mit den Kostenstellen und Rechnungen verglichen werden.

@oliverthoma: Kleine Ergänzung. Wird der dekodi Nexus eingesetzt, wird diese Diskrepanz auch festgestellt.

 

[Stephan K.]

Also so wie es derzeit ist, sind die Rechnungen und Gutschriften korrekt, aber die Aufträge falsch...
Anstelle der gleichen Bruttorate an Promotion wurde hier von JTL nur netto verbucht.
Und bei Aufträge, die gesplittet wurden, wurde nur eine Promo gutgeschrieben...

Man muss also korrekterweise auch die Aufträge mit den Zahlungen korrigieren. Zum Glück ist die "Zahlung" in der 1.5.x nicht gesperrt. Wie ist das in der 1.6.x?

 

[dazligth]

Man sieht es den Aufträgen in der Wawi nicht an, dass sie falsch sind.
Die Diskrepanz findet man nur, wenn man JTL2DATEV oder Taxdoo einsetzt, bei denen die externen Amazon Reporte mit den Kostenstellen und Rechnungen verglichen werden.

Der Fehler führte dazu, dass ein Auftrag z.B. über 20 € Brutto

mit 2 € Versandkosten
bei dem aber Amazon durch Promo die 2 Euro Versandkosten dem Kunden erlassen hat, der Auftrag nicht mit den Pos

• Ware 18 €
• Versand 2 €
• VersandPromo -2 €

mit 18 Euro Brutto und 18 Euro Zahlung in der Wawi ist,

sondern

• Ware 18 €
• Versand 2 €

mit 20 € und 20 € Zahlung in der Wawi ist. Die Promo wurde ignoriert und damit der Auftrag mit 20 € versteuert statt mit 18 €. (vereinfacht dargestellt)


Das wichtige und das bitten wir Sie, mit dem Steuerbüro abzuklären ist, zu welchem Zeitpunkt diese Rechnungskorrektur mit dem Tool erstellt wird. Das ist abhängig davon, ob bei UST-Meldungen für November und Dezember Korrekturen eingereicht werden sollen und ob OSS für Q4 (Frist bis 31.01.22) bereits eingereicht ist.

Option/Fall 1 - Rechnungskorrekturdatum auf aktuell

Die Meldungen für November und Dezember 21 sind mit diesen Fehlern an die Behörden (auch OSS, wenn diese für Q4-21 bereits ausgeführt ist) gegangen und Bruttoumsatz damit zu hoch gemeldet.

Dann werden die Rechnungskorrekturen auf den aktuellen Zeitpunkt der Korrektur ausgestellt. Damit melden Sie dann die Korrekturen in der jeweils nächsten Abrechnung. Es gibt auch die Möglichkeit einer Korrektur-Meldung bei der UST. Damit könnte dann die Option/Fall2 genutzt werden.

(Sollten Sie zu dieser Gruppe gehören, setzen wir uns gerne mit Ihnen über den Einsatz von JTL2DATEV auch als monatliche Mietvariante in Verbindung.)

Option/Fall 2 Rechnungskorrekturdatum auf Rechnungsdatum

Steuerbüro hat (durch JTL2DATEV oder Taxdoo) die Fehler rechtzeitig erkannt und die Meldungen anhand der Amazonreporte bereits korrigiert gemeldet.

Dann werden die Rechnungskorrekturen zum Zeitpunkt der Rechnung erstellt und die Wawi Datenbasis damit auf den gleichen Stand der Buchhaltung gebracht.

Wir haben das zusammengefasst auch an unsere Kunden gesendet mit dem Angebot es zu fixen und per SQL vorab zu prüfen ob Fix notwendig ist:
https://6dklr.r.bh.d.sendibt3.com/m...h9_sX3tKsIf33J73QbffGIJvO5EJuVziYSjKc60AdfS4X

Bei uns deckte JTL2Datev die Fehler nicht auf!
Wir haben im Dez schon ein SQL zur "Aufdeckung" geschrieben und ca. 500 von 20.000 korrigiert.
Ich hatte den Fehler Anfang Dez in der Facebook Grupp egemeldet.
https://www.facebook.com/groups/offiziellejtlgruppe/posts/2427743294023266/

 

[DerDima]

Verstehe den Aufwand, den Du betrieben hast nicht.
Das Fix das JTL dafür zur Verfügung gestellt hat,
https://forum.jtl-software.de/threa...S3MfiHMh_sSJkLCS0zDyA2_Da3VMEIbB8Gmz4gtNTrW4o
hätte das mit Backup wohl in unter 30 Minuten gemacht und mit 2 Modis zum Datum der Gutschrift zur Auswahl.

Eine einfache Abfrage im SQL um festzustellen ob man vielleicht betroffen ist und weiter etwas machen sollte ist auch:

SELECT * FROM pf_amazon_settlementpos WHERE AmountType = 'Promotion'

Wenn da gar kein kein Ergebnis kommt, sollte es auch keine geben.
Wenn doch, dann das Script oben von Sebastian ausführen zur genaueren Analyse.

Wo genau wird Schritt für Schritt beschrieben, wie man diese SQL Abfrage, ob man überhaupt betroffen ist, ausführt. Ich kenne mich mit SQL nicht aus und würde mir hier mehr Klarheit wünschen. Wenn man diese SQL Abfrage vor dem Ausführen des durch JTL bereitsgestellten Tools vornehmen sollte, verstehe ich nicht, wieshalb das nicht vernünftig kommuniziert wird.

Oder sollte jetzt jeder Händler zur Sicherheit mal ein Ticket eröffnen?

 

[Badcat]

OK, jetzt bin ich offiziell überfordert.

Die SQL-Abfrage von der ersten Seite findet über 1000 Ergebnisse. Das Tool korrigiert aber nur ~200.

Bedeutet das, dass eigentlich nur ~200 Datensätze betroffen waren?

 

[forumjtlolshopag]

Bei uns deckte JTL2Datev die Fehler nicht auf!
Wir haben im Dez schon ein SQL zur "Aufdeckung" geschrieben und ca. 500 von 20.000 korrigiert.
Ich hatte den Fehler Anfang Dez in der Facebook Grupp egemeldet.
https://www.facebook.com/groups/offiziellejtlgruppe/posts/2427743294023266/

Hattest du auch ein Ticket damals Anfang Dezember gestellt gehabt? Mit Tickets kommt man am Ende immer am besten. Eine einfache Meldung hier im Forum oder in solchen Gruppen auf sozialien Netzwerken können schnell untergehen. JTL2Datev hat uns auch keine Fehler gemeldet, aufgefallen ist es erst im Rechnungswesen selbst.

 

[dazligth]

Hattest du auch ein Ticket damals Anfang Dezember gestellt gehabt? Mit Tickets kommt man am Ende immer am besten. Eine einfache Meldung hier im Forum oder in solchen Gruppen auf sozialien Netzwerken können schnell untergehen. JTL2Datev hat uns auch keine Fehler gemeldet, aufgefallen ist es erst im Rechnungswesen selbst.

Ja selbstverständlich, hättest du auch im Link nachlesen können.
Waren ausgiebig mit den JTL-Entwicklern in Kontakt.

Wir machen immer Tickets auf. Ich lese zu oft wie sich Leute beschweren, aber nie Ticktes aufmachen. Ohne Ticket kann es keine Lösung geben.

 

[forumjtlolshopag]

Ja selbstverständlich, hättest du auch im Link nachlesen können.
Waren ausgiebig mit den JTL-Entwicklern in Kontakt.

Ne hätte ich nicht. Zeigt auch das diese FB Gruppe keinen Mehrwert gegenüber diesem Forum hat ...

 

[dazligth]

Ne hätte ich nicht. Zeigt auch das diese FB Gruppe keinen Mehrwert gegenüber diesem Forum hat ...
Den Anhang 77776 betrachten

Ja gut, ist ja deine Entscheidung nicht Mitglied in der offiziellen JTL Facebook Gruppe zu sein.

Egal dir ging es um das Ticket, das ist passiert. 🤘

 

[Astor]

Hallo,

das Tool fixt automatisch nur Dinge, die (noch) nicht Buchhaltungsrelevant sind - also defekte pf_amazon_bestellung-Datensätze sofern noch keine Bestellung erzeugt wurde und defekte tbestellung Einträge, sofern noch keine Rechnung erzeugt wurde.
Die buchhaltungsrelevanten Rechnungskorrekturen werden nur angelegt, wenn man dem explizit zustimmt.

Wer wissen möchte, welche Datensätze ggf. betroffen sind kann das folgende SQL nutzen:

Moin !

gibt es zwingend eine WAWI Versionsnummer, damit das

Hallo,

das Tool fixt automatisch nur Dinge, die (noch) nicht Buchhaltungsrelevant sind - also defekte pf_amazon_bestellung-Datensätze sofern noch keine Bestellung erzeugt wurde und defekte tbestellung Einträge, sofern noch keine Rechnung erzeugt wurde.
Die buchhaltungsrelevanten Rechnungskorrekturen werden nur angelegt, wenn man dem explizit zustimmt.

Wer wissen möchte, welche Datensätze ggf. betroffen sind kann das folgende SQL nutzen:

Moin !

Wenn ich die Abfrage auf der Datenbank machen, um zu checken, ob ich betroffen bin, dann bekomme ich folgende Fehlermeldung

Msg 208, Level 16, State 1, Line 1
Ungültiger Objektname "dbo.pf_amazon_bestellung".

Ich nutze WAWI Version 1.5.40.0

Mache ich eventuell etwas falsch ?
Danke !

 

[forumjtlolshopag]

Hallo,

das Tool fixt automatisch nur Dinge, die (noch) nicht Buchhaltungsrelevant sind - also defekte pf_amazon_bestellung-Datensätze sofern noch keine Bestellung erzeugt wurde und defekte tbestellung Einträge, sofern noch keine Rechnung erzeugt wurde.
Die buchhaltungsrelevanten Rechnungskorrekturen werden nur angelegt, wenn man dem explizit zustimmt.

Wer wissen möchte, welche Datensätze ggf. betroffen sind kann das folgende SQL nutzen:

Wir haben mal das Query bei uns durchgeführt, weil wir nur ~80 korrigieren mussten. Bei der Abfrage kamen aber weit aus mehr. Nun haben wir die mehr gemeldeten nachgeprüft, dort war die Summe am Ende eigtl. korrekt. Kann es sein das die Abfrage mehr liefern könnte als wie es notwendig ist? Auffällig war, das der Promotionbetrag auf 0 ausgeglichen war in diesen Aufträgen, sodas es keinen Einfluss auf die Endsumme hatte. Auch in der Buchhaltung war alles i.O. Keine offenen Posten.

@Badcat Ja das ist uns auch aufgefallen. Wir vermuten, das die Abfrage nicht ganz korrekt ist.

 

[DaPole88]

Hi,

ich muss sagen, dass ich auch den Überblick verloren habe. Wir haben ein BackUp auf Testsystem aufgespielt und das tool ausgeführt.

In der Mail ist ja ein Zeitfenster angegeben, aber das Tool findet auch Datensätze, die außerhalb des Zeitfensters sind ?!?

🤨🧐