Neu Amazon FBA Bestellungen wurden doppelt eingelesen - Bestellimporte für FBA vorübergehend deaktiviert!

[Grandstream]

Bei einem unseren Kunden das gleiche 72 Tausend Bestellungen doppelt seit 2016

Verstehe ich nicht. Die sind ja nicht doppelt sondern gesplittet. Eine Kundenbestellung über Amazon, aus zwei unterschiedlichen Versandlagern, zwei Aufträge in der Wawi angelegt. In Summe Menge und Preis korrekt.
Der Fehler mit den doppelten ist bei mir erst seit gestern Abend bzw. heute morgen der Fall.

 

[LTH-Köln]

Bei einem unseren Kunden das gleiche 72 Tausend Bestellungen doppelt seit 2016

Wie viel Bestellungen mit _1 angelegt worden sind:

SELECT
SUBSTRING(cExterneAuftragsnummer,20,20),
*
FROM Verkauf.tAuftrag where
SUBSTRING(cExterneAuftragsnummer,20,20) = '_1'

Wie viele Externe Auftragsnummer ohne _1 gleich sind:

SELECT *
FROM Verkauf.tauftrag
WHERE cExterneAuftragsnummer IN(
select
SUBSTRING(cExterneAuftragsnummer,1,19)

from verkauf.tAuftrag where
SUBSTRING(cExterneAuftragsnummer,20,20) = '_1' )

Vielen Dank für den Code!

Für diejenigen, die auch externe Auftragsnummern mi dem Suffix "_2" und "_3" haben, kann man den Abfragecode wie folgt erweitern:

SELECT
SUBSTRING(cExterneAuftragsnummer,20,20),
*
FROM Verkauf.tAuftrag where
SUBSTRING(cExterneAuftragsnummer,20,20) = '_1'
OR SUBSTRING(cExterneAuftragsnummer,20,20) = '_2'
OR SUBSTRING(cExterneAuftragsnummer,20,20) = '_3'

Viele Grüße aus Köln

 

[CT Cool Time]

@Dominic Nelle: Gibt es denn seitens JTL eine konkrete, klare und vor allem sichere Vorgehensweise, wie wir jetzt am plausibelsten prüfen können, welche Aufträge bei uns davon betroffen sind und was wir mit diesen dann machen?
Mir kommt es vor, als wären hier neben uns auch sehr viele weitere User ziemlich aufgeschmissen. Ich kann mir vorstellen, dass ihr wahrscheinlich ebenso aufgeschmissen seid, zum Teil. Aber das ist ja hier leider wirklich kein kleines Problem, im Endeffekt versaut es uns allen komplett die Buchhaltung. Und das gleiche ist ja schon mit den Gutschriften seit ca. 3 Monaten der Fall.

 

[topsi]

Bei einem unseren Kunden das gleiche 72 Tausend Bestellungen doppelt seit 2016

Wie viel Bestellungen mit _1 angelegt worden sind:

SELECT
SUBSTRING(cExterneAuftragsnummer,20,20),
*
FROM Verkauf.tAuftrag where
SUBSTRING(cExterneAuftragsnummer,20,20) = '_1'

Wie viele Externe Auftragsnummer ohne _1 gleich sind:

SELECT *
FROM Verkauf.tauftrag
WHERE cExterneAuftragsnummer IN(
select
SUBSTRING(cExterneAuftragsnummer,1,19)

from verkauf.tAuftrag where
SUBSTRING(cExterneAuftragsnummer,20,20) = '_1' )

Die _1 Aufträge müssen ja nicht per se falsch sein, ich finde ältere FBA Aufträge zB aus 2021, die zusammen in JTL dem Wert der SC Bestellung entsprechen, ich kann mir vorstellen dass diese aus unterscheidlichen Lägern versendet wurden und daher amazon an JTL 2 Aufträge übergibt.
Interessant wird es diese "korrekten" zu identifizieren und nicht mit zu löschen oder wie auch immer das Prozedere dann aussehen wird. Bei uns sind es ca 6k Aufträge, aber wir arbeiten mit VCS insofern ist aktuell nur die Statistik betroffen. MFN kommt weiter rein.

 

[Benjamin S.]

@KMorcinek deine Query berücksichtigt allerdings ja alle Aufträge mit _1.
Es gibt allerdings auch andere Cases für einen _1 Auftrag.
Mir ist z.B. bekannt, dass FBA Aufträge doppelt angelegt werden, falls die Artikel aus verschiedenen Lagern versendet wurden.
Evtl. gibt es ja auch weitere Fälle welche uns nicht bekannt sind.

Hier lässt die JTL Doku allerdings zu wünschen übrig 🙃

In JTL direkt kann man das ganze allerdings nicht überprüfen, da es keinen unique identifier in der DB gibt. Die einzige Möglichkeit wäre sich die Daten von Amazon direkt zu holen und die beiden Datensätze zu vergleichen.
Das ist allerdings JTLs Job und nicht unserer...

 

[SebastianB]

Hallo zusammen,

um mal den aktuellen Stand der Dinge zusammenzufassen:

Amazon hat in den Bestellberichten die wir seit gestern - etwa 17 Uhr - bekommen, die OrderItemId geändert. Eigentlich ist die OrderItemId die eindeutige Kennung für eine Bestellposition. Dadurch können wir die Daten nicht mehr korrekt zuordnen, und das System legt eine doppelte Bestellposition an. Zum zeitlichen Rahmen: Alle Berichte die seit gestern angefordert werden erhalten die "neuen" OrderItemIds. Alle FBA-Bestellungen die also ihren Bestellstatus ändern, werden dann eingelesen und sind damit betroffen. Somit sind nicht nur Bestellungen seit gestern betroffen, sondern alle Bestellungen die seit gestern neu eingelesen werden, weil sich an der Bestellung etwas geändert hat (z.B. eine Teillieferung usw.) Stand jetzt ist das älteste, was ich bislang in Datenbanken gesehen habe, etwa Mitte Mai 2023.

Die betroffenen Bestellungen kann man mit folgendem SQL herausfinden:

SELECT pf_amazon_bestellung.cOriginalOrderId, pf_amazon_bestellungpos.cArtNr, pf_amazon_bestellungpos.nQuantityPurchased, pf_amazon_bestellungpos.cTrackingNumber, pf_amazon_bestellungpos.cCarrier
FROM dbo.pf_amazon_bestellungpos
JOIN dbo.pf_amazon_bestellung ON pf_amazon_bestellung.kAmazonBestellung = pf_amazon_bestellungpos.kAmazonBestellung
WHERE pf_amazon_bestellung.nFBA = 1 AND pf_amazon_bestellung.nStatus >= 20 AND pf_amazon_bestellung.nDeleted = 0
GROUP BY pf_amazon_bestellung.cOriginalOrderId, pf_amazon_bestellungpos.cArtNr, pf_amazon_bestellungpos.nQuantityPurchased, pf_amazon_bestellungpos.cTrackingNumber, pf_amazon_bestellungpos.cCarrier
HAVING COUNT(DISTINCT pf_amazon_bestellungpos.cOrderItemId) > 1

Wir arbeiten zur Zeit an einem Tool, was das Problem auch rückwirkend in Euren Systemen lösen wird. Das Tool wird ggf. doppelte Rechnungen gutschreiben und die doppelten Bestellungen in der JTL-Wawi stornieren. Es wird dann auch ein Report geben, den ihr zusätzlich in die Buchhaltung geben wird. Ich hoffe, dass wir das Tool Anfang nächster Woche durch die Testphase haben und Euch dann zur Verfügung stellen können.

Wer mag kann natürlich auch die doppelten Rechnungen per Hand gutschreiben, allerdings kann ich nur dazu raten, die "erste" Rechnung gutzuschreiben und nicht die "zweite" - denn OrderItemIds der "zweiten" Bestellung passen zum Settlement-Report, die OrderItemIds der "ersten" Bestellung passen nicht mehr zum Settlement-Report - und dann gibt es wieder Kirmes mit FBA Gutschriften usw.

Meine persönliche Empfehlung: Wartet auf das Tool.

 

[Grandstream]

Meine persönliche Empfehlung: Wartet auf das Tool.

Aber wird Serverseitig auch daran gearbeitet das richtig eingelesen wird, oder muss das tool "für immer" verwendet werden?

 

[Benjamin S.]

@SebastianB
Mit folgendem code (durch 2 Daten ergänzt) bekommen wir unter anderem auch Aufträge von 2018.

SELECT pf_amazon_bestellung.cOriginalOrderId, pf_amazon_bestellungpos.cArtNr, pf_amazon_bestellungpos.nQuantityPurchased, pf_amazon_bestellungpos.cTrackingNumber, pf_amazon_bestellungpos.cCarrier, MAX(cast(dbo.pf_amazon_bestellung.dErstellt as date)), MIN(cast(dbo.pf_amazon_bestellung.dErstellt as date))
FROM dbo.pf_amazon_bestellungpos
JOIN dbo.pf_amazon_bestellung ON pf_amazon_bestellung.kAmazonBestellung = pf_amazon_bestellungpos.kAmazonBestellung
WHERE pf_amazon_bestellung.nFBA = 1 AND pf_amazon_bestellung.nStatus >= 20 AND pf_amazon_bestellung.nDeleted = 0
GROUP BY pf_amazon_bestellung.cOriginalOrderId, pf_amazon_bestellungpos.cArtNr, pf_amazon_bestellungpos.nQuantityPurchased, pf_amazon_bestellungpos.cTrackingNumber, pf_amazon_bestellungpos.cCarrier
HAVING COUNT(DISTINCT pf_amazon_bestellungpos.cOrderItemId) > 1
ORDER BY MIN(cast(dbo.pf_amazon_bestellung.dErstellt as date)) asc

 

[KMorcinek]

@KMorcinek deine Query berücksichtigt allerdings ja alle Aufträge mit _1.
Es gibt allerdings auch andere Cases für einen _1 Auftrag.
Mir ist z.B. bekannt, dass FBA Aufträge doppelt angelegt werden, falls die Artikel aus verschiedenen Lagern versendet wurden.
Evtl. gibt es ja auch weitere Fälle welche uns nicht bekannt sind.

Hier lässt die JTL Doku allerdings zu wünschen übrig 🙃

In JTL direkt kann man das ganze allerdings nicht überprüfen, da es keinen unique identifier in der DB gibt. Die einzige Möglichkeit wäre sich die Daten von Amazon direkt zu holen und die beiden Datensätze zu vergleichen.
Das ist allerdings JTLs Job und nicht unserer...

Ja, ist noch nicht ganz durchsichtig . Bei meinem Kunden wurden heute 20 k Bestellungen mit dem Suffix angelegt.

 

[spezialagent73]

Vielen Dank für den Code!

Für diejenigen, die auch externe Auftragsnummern mi dem Suffix "_2" und "_3" haben, kann man den Abfragecode wie folgt erweitern:

SELECT
SUBSTRING(cExterneAuftragsnummer,20,20),
*
FROM Verkauf.tAuftrag where
SUBSTRING(cExterneAuftragsnummer,20,20) = '_1'
OR SUBSTRING(cExterneAuftragsnummer,20,20) = '_2'
OR SUBSTRING(cExterneAuftragsnummer,20,20) = '_3'

Viele Grüße aus Köln

Bitte hierbei nicht vergessen, dass es auch richtige Vorgänge mit Suffix "_1", "_2" etc. geben kann, wenn die Artikel aus Mehrfachaufträgen aus unterschiedlichen Fulfilment-Ländern versendet werden...

 

[SebastianB]

Aber wird Serverseitig auch daran gearbeitet das richtig eingelesen wird, oder muss das tool "für immer" verwendet werden?

Wir können da serverseitig nichts tun - Amazon hat die Id geändert - und alles was wir jetzt tun können ist, die Scherben aufzuwischen so gut es geht. Sollte es notwendig sein, dass Tool längerfristig zu nutzen, werden wir eine entsprechende Routine in die JTL-Wawi einbauen. Ich hoffe aber, dass wir jetzt einmal einen großen Schwung haben werden und es sich dann erledigen wird.

@Benjamin S. das SQL hat bislang auf den Datenbanken gut funktioniert. Kann ich es mir bei Euch mal anschauen, dann kann ich ggf. das SQL noch etwas optimieren? Die 100% Auswertung wird es leider erst mit dem Settlement-Report geben, der aber ja wie üblich erst Stunden bis Tage verzögert reinkommt. Das Tool wird letztlich den Settlement-Report mit den Bestelldaten abgleichen.

 

[faceofboh]

Acht das hofft Ihr? Das ist ja wahnsinnig beruhigend ....
Ich möchte aber mal die Frage stellen warum ich bei anderen Tools nicht von entsprechenden Problemen lese? Auch bei den FBA Gutschriften ist das so. Es hat für außenstehende immer den Anschein das es exklusive JTL probleme sind.
Ich hoffe doch JTL bastelt sich gleichmal selbst ein Tool damit diese Transaktionen im Easy Auction Tarif nicht berechnet werden?

Langsam aber sicher entwickelt sich JTL zu einem ständigen Ärgernis.

 

[Grandstream]

Wichtig wäre auch noch zu wissen wann denn der FBA Abgleich wieder aktiviert wird ...

 

[Benjamin S.]

@SebastianB gerne kannst du es dir bei mir mal anschauen, melde dich gerne per PM

 

[spezialagent73]

Wenn ihr beabsichtigt, den ersten Vorgang zu löschen, weil jetzt die OrderItemId des zusätzlich importierten Vorgangs richtig ist, dann solltet ihr vorsichtig sein. Die Aufträge stimmen teilweise gar nicht überein!

Dies ist z.B. der Fall, wenn Amazon im Rahmen einer Versandaktion Versandkosten gutschreibt. Ich habe diverse Beispiele bei denen die Versandkosten eigentlich 2,99 sind. Amazon schreibt dann diese 2,99 gut, so dass die Versandkosten für den Kunden 0,00 betragen. Bei den nun zuisätzlich importierten Vorgängen ist diese Versandkostengutschrift plötzlich in einigen Fällen doppelt so hoch, also für diese Beispiel 5,98. Damit stimmt der Auftragswert eben um diese 2,99 nicht mehr...

Wenn ihr pauschal die neuen Vorgänge behalten wollt, dann stimmt die Buchhaltung wieder nicht.

Das ist echt ein ganz schöner Murks. Auch von mir nochmals die Frage: Warum hat bspw. afterbuy (weder bei den FBA Gutschriften noch bei dieser Sache) ein Problem mit der OrderItemID? Es muss ja offensichtlich auch Lösungen geben, die sich da von amazon (wenn der Fehler wirklich von amazon gemacht wurde) nicht verwirren lassen. Es wäre schön, wenn ihr darauf mal eingeht und es nicht totschweigt.

 

[Vesave]

Wenn ihr beabsichtigt, den ersten Vorgang zu löschen, weil jetzt die OrderItemId des zusätzlich importierten Vorgangs richtig ist, dann solltet ihr vorsichtig sein. Die Aufträge stimmen teilweise gar nicht überein!

Dies ist z.B. der Fall, wenn Amazon im Rahmen einer Versandaktion Versandkosten gutschreibt. Ich habe diverse Beispiele bei denen die Versandkosten eigentlich 2,99 sind. Amazon schreibt dann diese 2,99 gut, so dass die Versandkosten für den Kunden 0,00 betragen. Bei den nun zuisätzlich importierten Vorgängen ist diese Versandkostengutschrift plötzlich in einigen Fällen doppelt so hoch, also für diese Beispiel 5,98. Damit stimmt der Auftragswert eben um diese 2,99 nicht mehr...

Wenn ihr pauschal die neuen Vorgänge behalten wollt, dann stimmt die Buchhaltung wieder nicht.

Das ist echt ein ganz schöner Murks. Auch von mir nochmals die Frage: Warum hat bspw. afterbuy (weder bei den FBA Gutschriften noch bei dieser Sache) ein Problem mit der OrderItemID? Es muss ja offensichtlich auch Lösungen geben, die sich da von amazon (wenn der Fehler wirklich von amazon gemacht wurde) nicht verwirren lassen. Es wäre schön, wenn ihr darauf mal eingeht und es nicht totschweigt.

Dies kann ich bestätigen! Ist mir ebenfalls bei den neuen doppelten Aufträgen aufgefallen.

 

[dazligth]

Wer mag kann natürlich auch die doppelten Rechnungen per Hand gutschreiben, allerdings kann ich nur dazu raten, die "erste" Rechnung gutzuschreiben und nicht die "zweite" - denn OrderItemIds der "zweiten" Bestellung passen zum Settlement-Report, die OrderItemIds der "ersten" Bestellung passen nicht mehr zum Settlement-Report - und dann gibt es wieder Kirmes mit FBA Gutschriften usw.

Klingt charmant, ist aber buchhalterisch natürlich nicht ganz korrekt, wegen dem Rechnungsdatum/Leistungsdatum.
Weil nicht über den Monatswechsel, vielleicht grad noch so akzeptabel.

Die Kirmes mit den Gutschriften besteht grad ehh ... wollte da nochmal eintauchen. Mit WaWi 1.7.11.0 hatte ich auch in der USA.

Und ja ich hab auch Fälle gesehen in den die neuen Aufträge die Versandkosten und Versandkostenerstattungen nicht identisch waren. Also die neuen Aufträge sind zum Teil auch "inhaltlich" falsch.
Vermutlich weil diese Vorgänge jetzt doppelt in der pf_amazon stehen und er jetzt die Mengen/Artikelpositionen durcheinander wirft.

 

[dazligth]

Wenn ihr beabsichtigt, den ersten Vorgang zu löschen, weil jetzt die OrderItemId des zusätzlich importierten Vorgangs richtig ist, dann solltet ihr vorsichtig sein. Die Aufträge stimmen teilweise gar nicht überein!

Dies ist z.B. der Fall, wenn Amazon im Rahmen einer Versandaktion Versandkosten gutschreibt. Ich habe diverse Beispiele bei denen die Versandkosten eigentlich 2,99 sind. Amazon schreibt dann diese 2,99 gut, so dass die Versandkosten für den Kunden 0,00 betragen. Bei den nun zuisätzlich importierten Vorgängen ist diese Versandkostengutschrift plötzlich in einigen Fällen doppelt so hoch, also für diese Beispiel 5,98. Damit stimmt der Auftragswert eben um diese 2,99 nicht mehr...

Wenn ihr pauschal die neuen Vorgänge behalten wollt, dann stimmt die Buchhaltung wieder nicht.

Das ist echt ein ganz schöner Murks. Auch von mir nochmals die Frage: Warum hat bspw. afterbuy (weder bei den FBA Gutschriften noch bei dieser Sache) ein Problem mit der OrderItemID? Es muss ja offensichtlich auch Lösungen geben, die sich da von amazon (wenn der Fehler wirklich von amazon gemacht wurde) nicht verwirren lassen. Es wäre schön, wenn ihr darauf mal eingeht und es nicht totschweigt.

Kann ich so bestätigen hatte ich gestern auch gesehen, dass die Versandkosten nicht immer korrekt waren.

 

[dazligth]

Kann ich so bestätigen hatte ich gestern auch gesehen, dass die Versandkosten nicht immer korrekt waren.

Hier ein Beispiel dazu

 

[dazligth]

Wir arbeiten zur Zeit an einem Tool, was das Problem auch rückwirkend in Euren Systemen lösen wird. Das Tool wird ggf. doppelte Rechnungen gutschreiben und die doppelten Bestellungen in der JTL-Wawi stornieren

Wird es denn auch die pf_amazon korrigieren? Die dortigen falschen doppelten Einträge machen unsere Deckungsbeitragsrechnungen kaputt, weil wir historisch über diese auf die settelments joinen.
Wir betrachen aber auch die Artikelmengen dort um Kosten anteilig bei meheren Artikeln oder Teillieferungen sauber zu splitten.
Nehme an ihr macht das ähnlich für die Versandkosten und deren Gutschrifen, weswegen jetzt bei den doppelt erstellten dort Problem aufgetaucht sind.