Amazon VCS Lite: Fehler 50002 bleibt nach 3 Versuchen dauerhaft hängen – Analyse zu 1.10.14.2 / 1.11.11 und Lösungsvorschlag

[MrHaendler]

Hallo zusammen,
ich habe ein wiederkehrendes Problem bei der automatischen Verarbeitung von Amazon VCS Lite untersucht, durch das Rechnungen mit Fehlercode 50002 nach einigen Versuchen dauerhaft auf „Fehlerhaft“ stehen bleiben und anschließend manuell angestoßen werden müssen.
Ich konnte das Verhalten inzwischen bis auf Datenbankebene nachvollziehen und möchte meine Analyse sowie meinen Lösungsvorschlag hier teilen.

---

1. Historie: JTL-Support-Patch unter Wawi 1.10.14.2​

Das Problem hatte ich bereits unter JTL-Wawi 1.10.14.2.
Damals hatte ich vom JTL-Support einen Patch für folgende View erhalten:

Amazon.vVcsLiteRechnungOffenerBeleg

Der Support hatte dort den Abstand zwischen zwei automatischen Verarbeitungsversuchen auf 24 Stunden gesetzt.
Sinngemäß:

DATEADD(HOUR, 24, tVcsLite.dFehlgeschlagenUtc)

Damit wurden die maximal drei Verarbeitungsversuche über mehrere Tage verteilt.

---

2. Änderung in JTL-Wawi 1.11.11​

Nach dem Update auf JTL-Wawi 1.11.11 wurde die View beim Datenbankupdate neu erstellt.
Die aktuelle Standardversion verwendet nun einen Retry-Abstand von nur noch 1 Stunde:

DATEADD(HOUR, 1, tVcsLite.dFehlgeschlagenUtc)

Grundsätzlich halte ich diese Änderung sogar für sinnvoll.
Wenn ein temporäres Problem nach kurzer Zeit behoben ist, sollte man nicht 24 Stunden auf den nächsten Versuch warten müssen.
Das eigentliche Problem liegt meiner Analyse nach deshalb nicht beim Retry-Abstand, sondern bei der maximalen Anzahl der Fehlversuche.

---

3. Das eigentliche Problem: Nach drei Fehlern wird Schweregrad 10 gesetzt​

In:

Amazon.spVcsLiteSetzeFehlercode

befindet sich aktuell folgende Logik:

tVcsLite.nFehlgeschlagenSchweregrad =
CASE
WHEN tVcsLite.nFehlgeschlagenAnzahl + 1 >= 3
THEN 10
ELSE @Schweregrad
END

Das bedeutet:

1. Fehlversuch
→ nFehlgeschlagenAnzahl = 1
→ Schweregrad bleibt 1

2. Fehlversuch
→ nFehlgeschlagenAnzahl = 2
→ Schweregrad bleibt 1

3. Fehlversuch
→ nFehlgeschlagenAnzahl = 3
→ Schweregrad wird auf 10 gesetzt

Die View:

Amazon.vVcsLiteRechnungOffenerBeleg

berücksichtigt für einen automatischen Retry jedoch nur Datensätze mit:

nFehlgeschlagenSchweregrad < 2

Damit ist nach dem dritten Fehlversuch endgültig Schluss mit der automatischen Verarbeitung.

---

4. Verhalten bei Fehler 50002​

Bei meinen festhängenden Belegen trat durchgehend folgendes Muster auf:

InvoiceStatus = InvoicePending
nFehlercode = 50002
nFehlgeschlagenAnzahl = 3
nFehlgeschlagenSchweregrad = 10
dVerarbeitetUtc = NULL

Die dazugehörige Fehlermeldung lautet sinngemäß:

Amazon-Bestellpositionen wurden noch nicht übernommen

Wichtig ist dabei:
Fehler 50002 wird von JTL zunächst selbst mit Schweregrad 1 behandelt.
Es handelt sich also zunächst gerade nicht um einen permanenten Fehler mit Schweregrad 10.

---

5. Warum Fehler 50002 aus meiner Sicht ein temporärer Fehler ist​

Ich habe einen konkreten Fall bis in die beteiligten Tabellen verfolgt.
Zu diesem Zeitpunkt waren bereits vorhanden:

VCS-Lite-Daten
Amazon-Bestellung
Amazon-Bestellposition
kAmazonBestellungPos

Die Amazon-Bestellung war also bereits in den Amazon-Tabellen von JTL angekommen.
Nicht vorhanden waren jedoch noch:

Verkauf.tAuftrag
Verkauf.tAuftragPosition

Es ergab sich also folgender Zustand:

Amazon VCS-Lite Daten
vorhanden
↓
Amazon-Bestellung
vorhanden
↓
Amazon-Bestellposition
vorhanden
↓
Wawi-Auftrag
noch nicht vorhanden
↓
Wawi-Auftragsposition
noch nicht vorhanden

JTL versucht in dieser Situation bereits, den VCS-Lite-Beleg zu erzeugen.
Das kann zu diesem Zeitpunkt verständlicherweise noch nicht erfolgreich funktionieren.
Fehler 50002 ist daher in diesem Fall korrekt.
Das Problem ist lediglich, dass dieser temporäre Zustand nach sehr kurzer Zeit zu einem dauerhaften Fehlerstatus wird.

---

6. Warum die Kombination „1 Stunde + maximal 3 Versuche“ problematisch ist​

Mit der aktuellen Logik ergibt sich ungefähr:

Versuch 1
→ Fehler 50002
→ Schweregrad 1

+ 1 Stunde

Versuch 2
→ Fehler 50002
→ Schweregrad 1

+ 1 Stunde

Versuch 3
→ Fehler 50002
→ Schweregrad 10

→ keine weitere automatische Verarbeitung

Damit gibt JTL einen möglicherweise nur temporären Synchronisationsfehler bereits nach ungefähr zwei Stunden endgültig auf.
Wenn der Wawi-Auftrag beispielsweise drei, fünf oder zehn Stunden später vollständig übernommen wird, hilft das dem VCS-Lite-Beleg nicht mehr.
Er steht bereits auf:

nFehlgeschlagenSchweregrad = 10

und wird nicht mehr automatisch berücksichtigt.
Der Benutzer muss den Beleg anschließend manuell erneut anstoßen.
Genau dieses Verhalten habe ich bei mehreren Rechnungen beobachtet.

---

7. Warum der alte 24-Stunden-Patch das Problem entschärft hat​

Rückblickend ist damit auch nachvollziehbar, warum der JTL-Support mir unter 1.10.14.2 den Retry-Abstand auf 24 Stunden gesetzt hatte.
Bei weiterhin maximal drei Versuchen ergab sich ungefähr:

Versuch 1 → Tag 0

Versuch 2 → Tag 1

Versuch 3 → Tag 2

Die eigentliche Auftragsübernahme hatte dadurch wesentlich mehr Zeit, bevor JTL den Datensatz endgültig auf Schweregrad 10 setzte.
Der 24-Stunden-Patch war damit offenbar ein funktionierender Workaround.
Ich halte die aktuelle 1-Stunden-Logik aber grundsätzlich für besser.
Wenn der Auftrag beispielsweise 30 Minuten später vorhanden ist, möchte ich nicht bis zum nächsten Tag warten.
Deshalb würde ich nicht wieder auf 24 Stunden zurückgehen.

---

8. Mein Lösungsvorschlag​

Ich habe deshalb die aktuelle Retry-Zeit von 1 Stunde unverändert gelassen.
Stattdessen habe ich ausschließlich für Fehlercode 50002 die Anzahl der möglichen Retry-Versuche erhöht.
Mein gewünschtes Verhalten ist:

Fehler 50002:
→ einmal pro Stunde erneut versuchen
→ maximal ca. 6 Tage

alle anderen Fehler:
→ weiterhin JTL-Standard
→ maximal 3 Versuche

Dafür verwende ich:

DECLARE @MaxVersuche INT =
CASE
WHEN @Fehlercode = 50002
AND @Schweregrad < 2
THEN 145
ELSE 3
END;

Anschließend:

tVcsLite.nFehlgeschlagenSchweregrad =
CASE
WHEN tVcsLite.nFehlgeschlagenAnzahl + 1 >= @MaxVersuche
THEN 10
ELSE @Schweregrad
END

---

9. Warum 145 Versuche?​

Bei einem Retry ungefähr jede Stunde ergibt sich:

Versuch 1 → sofort

Versuch 25 → ca. 24 Stunden

Versuch 49 → ca. 48 Stunden

Versuch 73 → ca. 72 Stunden

Versuch 97 → ca. 96 Stunden

Versuch 121 → ca. 120 Stunden

Versuch 145 → ca. 144 Stunden

144 Stunden entsprechen ungefähr 6 Tagen.
Damit kann JTL bei diesem speziellen temporären Fehler bis zu sechs Tage darauf warten, dass die fehlende Auftragsposition verfügbar wird.
Wenn der Fehler danach immer noch besteht, wird weiterhin:

Schweregrad 10

gesetzt und ein manueller Eingriff erforderlich.
Es gibt also weiterhin eine klare Obergrenze.

---

10. Warum ich nicht einfach alle Fehler auf 145 Versuche gesetzt habe​

Das halte ich für sehr wichtig.
Ich möchte ausdrücklich nicht jeden beliebigen VCS-Lite-Fehler sechs Tage lang stündlich wiederholen.
Es gibt Fehler, bei denen ein automatischer Retry offensichtlich nicht sinnvoll ist, beispielsweise bei:

unterschiedlichen Währungen
bereits vergebenen Belegnummern
unterschiedlichen OrderIDs
nicht ermittelbaren Steuereinstellungen
bereits vorhandenen externen Belegen

Auch Fehler, die JTL direkt mit:

@Schweregrad = 10

meldet, sollen selbstverständlich weiterhin sofort schwere Fehler bleiben.
Meine Anpassung betrifft daher nur:

Fehlercode = 50002
UND
ursprünglicher Schweregrad < 2

Alle anderen Fehler behalten das bisherige JTL-Verhalten.

---

11. Bereits festgefahrene Datensätze​

Die bereits bestehenden problematischen Datensätze standen bei mir beispielsweise auf:

InvoiceStatus = InvoicePending
nFehlercode = 50002
nFehlgeschlagenAnzahl = 3
nFehlgeschlagenSchweregrad = 10
dVerarbeitetUtc = NULL

Diese werden durch eine Änderung an der Stored Procedure natürlich nicht automatisch reaktiviert.
Ich habe deshalb ausschließlich diese bereits festgefahrenen Fälle einmalig wieder auf Retry gesetzt.
Dabei habe ich bewusst dFehlgeschlagenUtc nicht verändert, damit die bestehende 1-Stunden-Wartezeit weiterhin eingehalten wird.

---

12. Ergebnis nach der Änderung​

Vorher:

nFehlgeschlagenAnzahl = 3
nFehlgeschlagenSchweregrad = 10
nFehlercode = 50002

Nach dem einmaligen Reset:

nFehlgeschlagenAnzahl = 0
nFehlgeschlagenSchweregrad = 1
nFehlercode = 50002

Nach einem weiteren automatischen Fehlversuch bei weiterhin fehlendem Wawi-Auftrag:

nFehlgeschlagenAnzahl = 1
nFehlgeschlagenSchweregrad = 1
nFehlercode = 50002

Der Datensatz befindet sich damit wieder regulär in der automatischen Retry-Verarbeitung.

---

13. Mein Vorschlag an JTL​

Aus meiner Sicht wäre es sinnvoll, Fehler 50002 anders zu behandeln als echte permanente Fehler.
Die aktuelle Retry-Zeit von 1 Stunde würde ich ausdrücklich beibehalten.
Anpassen würde ich lediglich die pauschale Eskalation nach drei Versuchen.
Denkbare Lösungen wären aus meiner Sicht:
Variante A
Für Fehler 50002 eine deutlich höhere maximale Anzahl von Retry-Versuchen vorsehen.
Variante B
Nicht nach Anzahl der Versuche, sondern zeitbasiert arbeiten, beispielsweise:

Fehler 50002 bis zu 5–7 Tage automatisch erneut versuchen.

Variante C
Für 50002 eine eigene Retry-Logik implementieren und diesen Fehler von der allgemeinen Drei-Versuche-Regel ausnehmen.

---

14. Zusammenfassung​

Unter JTL-Wawi 1.10.14.2 hatte mir der JTL-Support für dieses Problem bereits einen Patch bereitgestellt:

Retry-Abstand:
24 Stunden

maximale Versuche:
3

Unter JTL-Wawi 1.11.11 lautet der Standard jetzt:

Retry-Abstand:
1 Stunde

maximale Versuche:
3

Die kürzere Retry-Zeit finde ich grundsätzlich besser.
Das Problem ist aber, dass Fehler 50002 dadurch bereits nach ungefähr zwei Stunden auf Schweregrad 10 eskaliert und anschließend dauerhaft hängen bleibt.
Meine aktuelle Lösung lautet deshalb:

Retry-Abstand:
1 Stunde

Fehler 50002:
bis zu ca. 6 Tage / 145 Versuche

alle anderen Fehler:
weiterhin maximal 3 Versuche

Damit wird nicht pauschal die Fehlerbehandlung aufgeweicht, sondern ausschließlich der offensichtlich temporäre Synchronisationszustand bei Fehler 50002 robuster behandelt.

---

Technische Details / SQL​

Meine vollständige Analyse inklusive:

• beteiligter Views und Stored Procedures
• SQL-Abfragen zur Diagnose
• Analyse von Fehler 50002
• SQL zur Anpassung der Retry-Logik
• einmaligem Reset bereits festgefahrener Datensätze
• Kontrollabfragen
• Rollback auf den JTL-Standard

habe ich als PDF an diesen Beitrag angehängt.
Mich würde insbesondere interessieren:
Ist die Eskalation von Fehler 50002 nach drei Versuchen auf Schweregrad 10 von JTL bewusst so vorgesehen?
Falls ja, wäre aus meiner Sicht trotzdem zu überlegen, diesen Fehler aufgrund seines temporären Charakters separat zu behandeln.
Vielleicht hilft die Analyse auch anderen Nutzern, bei denen VCS-Lite-Belege mit Fehler 50002 scheinbar dauerhaft auf „Fehlerhaft“ stehen bleiben und regelmäßig manuell angestoßen werden müssen.