Neu Ist es korrekt, dass Belegdaten von Amazon (VCS) mit einer etwa 7-tägigen Verzögerung in WAWI landen?

[vygi]

Ich benutze Dienste von CountX (eigentlich Tochterfirma von JTL), und diese Verzögerung führt zu unvollständigen Monatsdaten, weil CountX bereits am 5. des Monats Belegdaten aus der WAWI-Datenbank übernimmt.

 

[dazligth]

Ich benutze Dienste von CountX (eigentlich Tochterfirma von JTL), und diese Verzögerung führt zu unvollständigen Monatsdaten, weil CountX bereits am 5. des Monats Belegdaten aus der WAWI-Datenbank übernimmt.

Ich arbeite mit VCS Daten für UK und CH wo wir im Zwangs VCS sind und zumindest da kommen die frühestens nach 3-4 Tagen und Teilweise viele viele Tage später.

Duchschnitt bei mir 135 Tage.


Mein höchster Wert für 2025:
3.1.2025 ist der Auftrag erstellt worden und in der WaWi ist der VCS Eintrag für diesen Auftrag dErstelltUtc:
2025-10-22 14:14:14

Schau es dir selbst an hier meine UK Analyse:

-- WaWi bis 1.10: pf_amazon_vcs
-- WaWi ab 1.11 Amazon.tVcs

-- Hier meine WaWi 1.11 Version ab 2025
SELECT
        CAST(DATEDIFF(MINUTE, B.dErstellt, av.dErstelltUtc) / 1440.0 AS DECIMAL(10,4)) AS Tage_ab_Auftrag, B.cAuftragsNr
    FROM Verkauf.tAuftrag B
    JOIN dbo.pf_amazon_bestellung AB ON B.cExterneAuftragsnummer = AB.cOrderId
    JOIN Amazon.tVcs av ON LEFT(B.cExterneAuftragsnummer,19) = av.OrderID
    WHERE
        B.kPlattform = 53 -- nur Amazon.co.uk
        AND B.dErstellt >= '2025-01-01'


-- Analyse dazu:
-- ########### VCS Analyse #############
-- mit Median
-- #####################################
WITH DifferenzTage AS (
    SELECT
        CAST(DATEDIFF(MINUTE, B.dErstellt, av.dErstelltUtc) / 1440.0 AS DECIMAL(10,4)) AS Tage_ab_Auftrag, B.cAuftragsNr
    FROM Verkauf.tAuftrag B
    JOIN dbo.pf_amazon_bestellung AB ON B.cExterneAuftragsnummer = AB.cOrderId
    JOIN Amazon.tVcs av ON LEFT(B.cExterneAuftragsnummer,19) = av.OrderID
    WHERE
        B.kPlattform = 53 -- nur Amazon.co.uk
        AND B.dErstellt >= '2025-01-01'
),
MetrikenMitMedian AS (
    SELECT
        Tage_ab_Auftrag,
        COUNT(*) OVER () AS Anzahl,
        AVG(Tage_ab_Auftrag) OVER () AS Durchschnitt,
        MIN(Tage_ab_Auftrag) OVER () AS Minimum,
        MAX(Tage_ab_Auftrag) OVER () AS Maximum,
        PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY Tage_ab_Auftrag) OVER () AS Median
    FROM DifferenzTage
)
SELECT TOP 1
    Anzahl,
    CAST(Durchschnitt AS DECIMAL(10,2)) AS Durchschnitt_Tage_ab_Auftrag,
    CAST(Minimum AS DECIMAL(10,2)) AS Min_Tage_ab_Auftrag,
    CAST(Maximum AS DECIMAL(10,2)) AS Max_Tage_ab_Auftrag,
    CAST(Median AS DECIMAL(10,2)) AS Median_Tage_ab_Auftrag
FROM MetrikenMitMedian;

Kann natürlich für "echtes VCS" anders sein.

 

[dazligth]

Aber mal ein anderer Einwurf, wir sind auch bei CountX und meines Wissens nach nutzen die aber Settlement Daten.
Wo man auch aufpassen muss. Seit Amazon diese neue 7 Tages Auszahlungsrichtlinie eingeführt hat, werden alle Settlements erst 7 Tage später erst veröffentlich.

Was genau meinst du denn wenn du sagst "unvollständigen Monatsdaten", für Umsatzsteuer und Verbringen oder was?
Erfolgsrechnung in der Buchhaltung und wie macht ihr die? Nutzt ihr noch andere Tools wie JTL2Datev?

An der Stellle verweise ich gerne mal auf diesen Beitrag von mir, weil wir auch mal Probleme hatten:
https://forum.jtl-software.de/threa...hren-neue-ruecklagenrichtlinie-amazon.228301/

 

[vygi]

Ich bin mit diesen Begriffen nicht ganz vertraut, aber wenn "Settlement" das sind, was in SellerCentral unter "Alle Abrechnungszeiträume" erscheint ("Abrechnungsbericht V2"), dann habe ich damit keine Probleme.
Diese Abrechnungsberichte, in denen die Auszahlungen von Amazon aufgeschlüsselt sind, kommen zuverlässig.
Was mit Verspätung kommt sind die Belegdaten, also Buchungsdaten -> VCS.

Was genau meinst du denn wenn du sagst "unvollständigen Monatsdaten", für und Verbringen oder was?
Nutzt ihr noch andere Tools wie JTL2Datev?

Ja, für OSS und für die ausländischen USt-Voranmeldungen.
CountX hat dazu einen eigenen " Connector", der sich mit der WAWI-Datenbank verbindet.
Ich verwende auch " JTL2Datev" von Jira. Auch diese Applikation bekommt über WAWI die Belegdaten von Amazon mit einer etwa 7-tägigen Verzögerung.

Dummerweise bewegt sich CountX kein bisschen und weigert sich, Daten später als am 5. Tag des Monats um etwa 4 Uhr aus WAWI zu übernehmen. Zu diesem Zeitpunkt fehlen noch Belege aus den letzten zwei Tagen des Vormonats.

Ich habe mir die Situation in WAWI unter "Plattformen > Amazon > Buchungsdaten > VCS" genau angeschaut und stelle fest, dass genau jetzt, am Abend des 23. Tages des Monats, dort folgende Daten zu sehen sind:

• „Verarbeitet“: Rechnungen mit dem Belegdatum bis zum 17. und Rechnungskorrekturen bis zum 18.
• „Verarbeitung ausstehend“: Rechnungen mit dem Belegdatum vom 18. und 19. sowie Rechnungskorrekturen vom 19.

Das zeigt sehr gut, dass am frühen Morgen des 5. Tag des Monats noch nicht alle VCS-Daten des Vormonats verarbeitet sind.

ABER

Offenbar gleiche Daten - und zusätzlich auch noch neuere - erscheinen auch unter "VCS Lite"! Und zwar alle grün ("Verarbeitet"), lediglich mit dem Fehlercode "Wird über VCS abgerechnet".
Dort sind sogar Belege mit dem heutigen Datum zu sehen.

Warum ist das so?
Können diese Daten anstelle von "VCS" verwendet werden?

 

[dazligth]

Da kam ja heute ne mail von COUNTX dass sie den Zeitraum von der Einlesung verschiedebn.
Ich muss meine Aussage von oben was anpassen. Die SQLs die ich da oben Ende 2024 erstellt hatte basierten auf WaWi 1.9 da hatte ich empirisch ermittelt, dass die VCS Einträge am 5. Tag noch nicht immer vollständig da waren.
Wir haben hier nen SQL Agent laufen der ne email schickt wenn wir in UK nen Auftrag haben für den kein VCS Eintrag vorliegt mit der Bedingung "AND B.dErstellt < GETDATE() - 6" ... hier kommen regelmäßig mails und die Trefferquote war seit Juli 2025 100%. Für alle Einträge mussten wir manuell Rechnungen erstellten, für die Ausnaßmen die nicht im Zwangs VCS sind. Also sollte es wenn CountX jetzt am 7 Tage den Snapshot zieht erstmal passen.

Im Oktober sind wir auf die 1.10 gewechselt und damit hat sich was verändert und die WAWI hat allerhand VCS Einträge nachgeladen. Da kamen dann auch Zwangs VCS Gutschriften mit rein die mein SQL oben nicht mehr korrekt gemacht haben.

Hier mal das update mit dem ihr selbst prüfen könnt. Wenn ihr von WaWi 1.9 auf 1.10 geweselt seid, darf das Datum nicht vor dem update auf die 1.10 liegen.

-- ########### VCS Analyse #############
-- mit Median
-- #####################################
WITH DifferenzTage AS (
    SELECT
        CAST(DATEDIFF(MINUTE, B.dErstellt, av.dErstelltUtc) / 1440.0 AS DECIMAL(10,4)) AS Tage_ab_Auftrag, B.cAuftragsNr
    FROM Verkauf.tAuftrag B
    JOIN dbo.pf_amazon_bestellung AB ON B.cExterneAuftragsnummer = AB.cOrderId
    JOIN Amazon.tVcs av ON LEFT(B.cExterneAuftragsnummer,19) = av.OrderID
    WHERE
        B.kPlattform = 53
        AND NOT RIGHT(av.VATInvoiceNumber,4) = 'CBVR'
        AND convert(date,B.dErstellt) >= '2025-01-01'
),
MetrikenMitMedian AS (
    SELECT
        Tage_ab_Auftrag,
        COUNT(*) OVER () AS Anzahl,
        AVG(Tage_ab_Auftrag) OVER () AS Durchschnitt,
        MIN(Tage_ab_Auftrag) OVER () AS Minimum,
        MAX(Tage_ab_Auftrag) OVER () AS Maximum,
        PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY Tage_ab_Auftrag) OVER () AS Median
    FROM DifferenzTage
)
SELECT TOP 1
    Anzahl,
    CAST(Durchschnitt AS DECIMAL(10,2)) AS Durchschnitt_Tage_ab_Auftrag,
    CAST(Minimum AS DECIMAL(10,2)) AS Min_Tage_ab_Auftrag,
    CAST(Maximum AS DECIMAL(10,2)) AS Max_Tage_ab_Auftrag,
    CAST(Median AS DECIMAL(10,2)) AS Median_Tage_ab_Auftrag
FROM MetrikenMitMedian;

Meine Werte ab den 22.10 nachdem wir auf WaWi 1.10 gewechselt haben.



Wenn ihr das SQL im Beitrag hier drunter aussführt könnt ihr auch die Ausreißer nach oben sehen. Also bei mir allein in den letzen 6 Wochen schon zwei Einträge mit > 5 Tagen ... und ich hatte damals auch Einträge die auch mal 7,8,9 tage und mehr auf der Uhr hatten.


Auf jeden Fall habt ihr mit dem SQL ein Mittel an der Hand um am 10. Tag zu prüfen ob die Daten vom 7. noch valide sind.

 

[dazligth]

Hier nochmal der WITH Teil als sortiertes SQL absteigend

    SELECT

        CAST(DATEDIFF(MINUTE, B.dErstellt, av.dErstelltUtc) / 1440.0 AS DECIMAL(10,4)) AS Tage_ab_Auftrag, B.cAuftragsNr

    FROM Verkauf.tAuftrag B

    JOIN dbo.pf_amazon_bestellung AB ON B.cExterneAuftragsnummer = AB.cOrderId

    JOIN Amazon.tVcs av ON LEFT(B.cExterneAuftragsnummer,19) = av.OrderID

    WHERE

        B.kPlattform = 53

        AND NOT RIGHT(av.VATInvoiceNumber,4) = 'CBVR'

        AND convert(date,B.dErstellt) >= '2025-01-01'

    ORDER BY Tage_ab_Auftrag DESC

 

[dazligth]

Dummerweise bewegt sich CountX kein bisschen und weigert sich, Daten später als am 5. Tag des Monats um etwa 4 Uhr aus WAWI zu übernehmen. Zu diesem Zeitpunkt fehlen noch Belege aus den letzten zwei Tagen des Vormonats.

Im Zuge meiner aktuellen Untersuchungen kann ich das so bestätigen. Siehe oben. CountX hat das jetzt offensichtlich auch festgestellt und eine (temporäre) Anpassung gemacht.
Falls CountX sogar die Tabelle Rechnung.tExternerBeleg nutzt kommen die Daten sogar noch etwas später ...
Dazu habe ich eben auch ein Thema erstellt.
https://forum.jtl-software.de/threa...utzung-und-zwangs-vcs-fuer-gb-schweiz.243252/

 

[frankell]

Hier nochmal der WITH Teil als sortiertes SQL absteigend

Nur zur Sicherheit für diejenigen, die es nicht wissen:
Die Sortierung per "ORDER BY ..."-Zeile funktioniert nur, wenn man den WITH-Teil separat ausführt. Wenn man den gesamten Code ausführt, darf die "ORDER BY ..."-Zeile nicht im WITH-Teil enthalten sein. SQL Server meckert sonst.

 

[dazligth]

Nur zur Sicherheit für diejenigen, die es nicht wissen:
Die Sortierung per "ORDER BY ..."-Zeile funktioniert nur, wenn man den WITH-Teil separat ausführt. Wenn man den gesamten Code ausführt, darf die "ORDER BY ..."-Zeile nicht im WITH-Teil enthalten sein. SQL Server meckert sonst.

Ja da war zwischendrin ein kleiner Fehler drin, weswegen ich das nochmal separat rausgezogen habe. Order by darf nicht ins with...
https://forum.jtl-software.de/threa...zoegerung-in-wawi-landen.242151/#post-1323375