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

[dazligth]

Die upside an dieser Sache. Ich sehe, dass heute wieder Gutschriften durch den worker erstellt wurden. Mal abwarten ob auch weitestgehend alle gemacht werden wie früher.

 

[dazligth]

Die upside an dieser Sache. Ich sehe, dass heute wieder Gutschriften durch den worker erstellt wurden. Mal abwarten ob auch weitestgehend alle gemacht werden wie früher.

Oder auch nicht ... die Automatische Gutschrifterstellung hat jetzt ne Gutschrift auf den falschen Auftrag geschrieben der schon mit der Stornorechnung storniert war und nicht auf den ursprünglichen richtigen Auftrag.

Hab jetzt hier auf dem "neuen falschen Auftrag" sowohl eine Gutschrift als auch eine Stornorechnung drauf ...

 

[Pinkman]

Es wäre schön, wenn ihr darauf mal eingeht und es nicht totschweigt.

das wirst Du nicht erhalten...

 

[jankoerber]

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.

Hi,

danke für die Info.
Meine Frage:
Könnt ihr überhaupt noch erkennen, welche Aufträge wirklich doppelt sind und wo es sich um Splittaufträge handelt durch zB Lieferungen aus 2 Lägern? Das ist nämlich die entscheidende Frage.
Wenn man das nämlich nicht unterscheiden kann, wird es Aufträge geben, die zu Unrecht gutgeschrieben werden.
Wenn ihr das nicht unterscheiden könnt, würden wir damit beginnen die 3400 Rechnungen gutzuschreiben und bei jedem Auftrag im SC schauen, ob es sich um eine doppelte Anlage oder um einen Splittauftrag handelt.
Viele Grüße

 

[dazligth]

Ich bekomme ehhh grad ein mulmiges Gefühl ... bin grad dabei alles per Hand zu korrigieren und jetzt kommt mir der zweite Auftrag in die Hände wo ein Kunde just am 6.6. wo die Fehler aufgetreten sind, dasselbe nochmal bestellt, wofür in der Erstlieferung schon ne Erstattung angefordert worden ist. Könnte natürlich ne Ersatzlieferung von Amazon sein, weil die ursprüngliche Sendung nach nur (!) 4 Tagen noch nicht angekommen war, ist aber insgesamt irgendwie "fragwürdig".

 

[DiplomWurst]

Ich bekomme ehhh grad ein mulmiges Gefühl ... bin grad dabei alles per Hand zu korrigieren und jetzt kommt mir der zweite Auftrag in die Hände wo ein Kunde just am 6.6. wo die Fehler aufgetreten sind, dasselbe nochmal bestellt, wofür in der Erstlieferung schon ne Erstattung angefordert worden ist. Könnte natürlich ne Ersatzlieferung von Amazon sein, weil die ursprüngliche Sendung nach nur (!) 4 Tagen noch nicht angekommen war, ist aber insgesamt irgendwie "fragwürdig".
Den Anhang 99715 betrachten

Sollte nur Zufall sein. Versanddaten sind bei beiden Aufträge identisch. Sollte also nicht doppelt versandt worden sein.

 

[forumjtlolshopag]

Dürfte keine Rolle spielen, die Amazon Bestellnummer ist ja auch unterschiedlich. Bei den doppelten sind ja diese identisch, nur das dann ein _1 etc. dran hängt.

 

[SebastianB]

Hi,

danke für die Info.
Meine Frage:
Könnt ihr überhaupt noch erkennen, welche Aufträge wirklich doppelt sind und wo es sich um Splittaufträge handelt durch zB Lieferungen aus 2 Lägern? Das ist nämlich die entscheidende

Es gibt ja den Abrechnungsbericht von Amazon - den können wir neben die Bestellungen legen und anhand dessen die falschen Datensätze rauslöschen. Das geht leider nur zeitverzögert, weil der Abrechnungsbericht später kommt.

 

[SebastianB]

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.

Ein wenig wäre, über die OrderItemId / OrderItemCode in den Settlements zu joinen, dann würden die fehlerhaften pf_amazon_bestellung ja schon durch den join rausfliegen. Aber das Tool wir auch die fehlerhaften pf_amazon_bestellung entweder löschen oder auf "storniert" setzen.

 

[forumjtlolshopag]

Wir haben bei uns gesehen das solche Doppelungen auch entstehen, wenn der Kunde von einem Artikel z.B. 2x in einer Amazonbestellung geordert hat und Amazon diese dann in zwei getrennt hat, wo jeweils 1x der Artikel drin ist. Erkennt das Tool das dann auch?

 

[SebastianB]

das wirst Du nicht erhalten...

Also: Dass die Daten falsch von Amazon kommen kann ja nun jeder in seiner Datenbank sehen: Bei den FBA Gutschriften passt im Settlement-Report die OrderItemId der Verkaufs nicht zur Gutschrift. Bei den doppelten FBA-Bestellungen sieht man auch in der Datenbank, dass die neuen Bestellpositionen abweichende OrderItemIds zu den bereits bestehenden haben. Dass es ein globales Problem von Amazon ist, zeigt Amazon ja nun auch selber in seiner Status-Seite und man kann es auch in den github-Reports nachlesen.

Für unsere Software spielt die Korrektheit der OrderItemId eine sehr große Rolle - ist die falsch, fliegt das JTL-System auf die Nase.

Ob jetzt die Auswirkungen dieses Bugs bei Amazon bei anderen Anbietern die selben sind, weiß ich nicht: Ich weiß nicht, wie andere Anbieter die Retouren von Amazon einlesen - also ob die das über den durch diesen Bug betroffenen Settlement-Report machen, oder ob die einen anderen Bericht verwenden der nicht betroffen ist, oder ob die einen anderen Weg nutzen um die Positionen miteinander zu verknüpfen.
Ich weiß auch nicht, wie die die FBA-Bestellungen einlesen und verarbeiten und welche Rolle in deren Prozess die OrderItemId spielt. Und das gar nicht, weil ich es hier totschweigen will, sondern weil ich es schlicht nicht weiß, weil ich bei den Unternehmen nicht gearbeitet habe und den Quelltext von denen nicht kenne. Ich kenne unseren Code und kann sagen, weshalb wir von dem Amazon-Bug betroffen sind.

 

[SebastianB]

Wir haben bei uns gesehen das solche Doppelungen auch entstehen, wenn der Kunde von einem Artikel z.B. 2x in einer Amazonbestellung geordert hat und Amazon diese dann in zwei getrennt hat, wo jeweils 1x der Artikel drin ist. Erkennt das Tool das dann auch?

Ja.

 

[Zodiak]

Wird das Tool auch für 1.5.55.6 gehen? Bei den doppelten angelegten wurde ja nochmal eine Rechnung angelegt. In der Version 1.6 kann man ja eine Stornorechnung erstellt. Wie müssen alle unter 1.6 die Sache angehen? Rechnungskorrektur?

 

[SebastianB]

Wird das Tool auch für 1.5.55.6 gehen? Bei den doppelten angelegten wurde ja nochmal eine Rechnung angelegt. In der Version 1.6 kann man ja eine Stornorechnung erstellt. Wie müssen alle unter 1.6 die Sache angehen? Rechnungskorrektur?

Ja, es wird eine Version für 1.5.x und eine für 1.6+ geben. In der 1.5 wird es über Rechnungskorrekturen laufen.

 

[Blochi]

Achtung. Das Problem ist vermutlich schwerwiegender und besteht schon länger.
Bei uns wurden am 12.05.2023 > 1000 Bestellungen doppelt importiert. Es handelt sich dabei stets um Aufträge aus dem März, in welchen Kunden mehrere Artikel bestellt haben. Ich hatte mich bereits gewundert, warum die Umsätz lt. BWA deutlich von der Amazon Statistik abweicht. Es stellt sich die Frage, ob das schon öfters umbemerkt passiert ist, ggfs. auch im letzten Jahr? Kann das bitte nachhaltig geprüft werden?

 

[Pinkman]

welchen Kunden mehrere Artikel bestellt haben.

hast Du genau kontrolliert, dass es tatsächlich doppelte sind?
Bei Aufträgen wo Kunden mehrere Artikel bestellen kommt es öfters vor, dass die Pakete gesplittet werden

 

[Blochi]

Ja habe ich und ja das ist mir bewusst. Warum sollten wir am 12.05 plötzlich 1000 zusätzliche Rechnungen fakturieren aus Aufträgen vom März?

 

[dazligth]

Es gibt ja den Abrechnungsbericht von Amazon - den können wir neben die Bestellungen legen und anhand dessen die falschen Datensätze rauslöschen. Das geht leider nur zeitverzögert, weil der Abrechnungsbericht später kommt.

Damit muss man im Moment aber auch recht vorsichtig sein, die kommen nicht zuverlässig bzw. vollständig.
Hier ein Beispiel was aktuell aktiv ist.
Der Eintrag steht auf verzögert und wir warten nun schon seit ca. 5 Wochen, dass er veröffentlicht wird und im Settlement landet.

 

[dazligth]

Achtung. Das Problem ist vermutlich schwerwiegender und besteht schon länger.
Bei uns wurden am 12.05.2023 > 1000 Bestellungen doppelt importiert. Es handelt sich dabei stets um Aufträge aus dem März, in welchen Kunden mehrere Artikel bestellt haben. Ich hatte mich bereits gewundert, warum die Umsätz lt. BWA deutlich von der Amazon Statistik abweicht. Es stellt sich die Frage, ob das schon öfters umbemerkt passiert ist, ggfs. auch im letzten Jahr? Kann das bitte nachhaltig geprüft werden?

Also für uns kann ich das sicher ausschließen.

 

[Just-Commerce]

Ob jetzt die Auswirkungen dieses Bugs bei Amazon bei anderen Anbietern die selben sind, weiß ich nicht: Ich weiß nicht, wie andere Anbieter die Retouren von Amazon einlesen - also ob die das über den durch diesen Bug betroffenen Settlement-Report machen, oder ob die einen anderen Bericht verwenden der nicht betroffen ist, oder ob die einen anderen Weg nutzen um die Positionen miteinander zu verknüpfen.
Ich weiß auch nicht, wie die die FBA-Bestellungen einlesen und verarbeiten und welche Rolle in deren Prozess die OrderItemId spielt. Und das gar nicht, weil ich es hier totschweigen will, sondern weil ich es schlicht nicht weiß, weil ich bei den Unternehmen nicht gearbeitet habe und den Quelltext von denen nicht kenne. Ich kenne unseren Code und kann sagen, weshalb wir von dem Amazon-Bug betroffen sind.

Kein Vorwurf aber eine Bitte:
Schaut euch an wie die anderen Systeme das machen.
Ich will auch in Zukunft JTL nutzen.
Mit den Problemen der letzten Monate kann ich mir das aber nicht erlauben. Ich bin eine one man show und verfüge nicht über die tiefgehenden IT Kentnisse von vielen Leuten die hier schreiben.
Ich bin darauf angewiesen das die JTL Wawi das macht was man erwartet!