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

[M°M]

Wir haben die manuellen Korrekturen heute abgeschlossen.

Unsere Erkenntnis ist, dass die doppelten Aufträge (_1 etc.) ausschließlich das Auftragsdatum 06.06.2023 erhalten haben.
Kann jemand von JTL bestätigen, dass sich das Problem auf das Auftragsdatum 06.06.2023 lokalisieren lässt?

An den Tagen davor und danach haben wir eine sehr überschaubare Anzahl von geteilten Aufträgen, die sich in Summe mit den Vorgängen in der SellerCentral decken.

Das Rechnungs- bzw. Auftragsdatum der ersten bzw. korrekten Aufträge reicht, wie bereits mehrfach beschrieben, bis weit in den Mai zurück.

Nach Berücksichtigung der erstellten Rechnungskorrekturen sind unsere statistischen Werte wieder plausibel.

Bei uns liegt das Auftragsdatum der doppelten Aufträge (_1) zwischen dem 02.06. und dem 05.06. Insofern muss ich Deine Frage verneinen.

 

[Michael Offergeld]

Ein kurzer Zwischenstand und eine Bitte an euch:

Wir testen das Tool derzeit im internen QA-Prozess. Wir könnten hier für unsere Tests nochmals eine weitere Datenbank benötigen, die von doppelten FBA-Bestellungen betroffen ist und zeitgleich Amazon VCS nutzt. Schreibt mir gerne kurz eine Nachricht hier im Forum, wenn ihr uns unterstützen möchtet.

 

[Albart]

Ein kurzer Zwischenstand und eine Bitte an euch:

Wir testen das Tool derzeit im internen QA-Prozess. Wir könnten hier für unsere Tests nochmals eine weitere Datenbank benötigen, die von doppelten FBA-Bestellungen betroffen ist und zeitgleich Amazon VCS nutzt. Schreibt mir gerne kurz eine Nachricht hier im Forum, wenn ihr uns unterstützen möchtet.

Hallo Michael,

wir könnten euch ein Backup zur Verfügung stellen. Sagt nur wann und wie.
Wir haben doppelte Aufträge und nutzen VCS. Für die doppelten Aufträge wurden keine VCS Rechnungsnummern zugeordnet, daher landen die später in JTL2DATEV nicht im Umsatz.

 

[jim-tonic]

Kann jemand von JTL bestätigen, dass sich das Problem auf das Auftragsdatum 06.06.2023 lokalisieren lässt?

Das kann man so oder so sehen. Das Bestelldatum des Kunden kann bis in den Mai zurückgehen. Das Auftragsdatum bei JTL ist das Datum des Imports, dann wenn der FBA Versand stattfand. Ich halte das ohnehin für falsch und wir korrigieren das Datum über die Datenbank, damit das Auftragsdatum mit dem echten Bestelldatum des Kunden übereinstimmt.

Ich würde sagen die Fehler betreffen nur das Importdatum/Versanddatum 6.6.2023.

 

[Michael Offergeld]

Hallo Michael,

wir könnten euch ein Backup zur Verfügung stellen. Sagt nur wann und wie.
Wir haben doppelte Aufträge und nutzen VCS. Für die doppelten Aufträge wurden keine VCS Rechnungsnummern zugeordnet, daher landen die später in JTL2DATEV nicht im Umsatz.

Danke dir - ich habe gerade über das Nachrichtensystem schon Datenbank bekommen. Ich würde dich anschreiben, wenn gleich nochmal Bedarf besteht.

 

[M°M]

Das kann man so oder so sehen. Das Bestelldatum des Kunden kann bis in den Mai zurückgehen. Das Auftragsdatum bei JTL ist das Datum des Imports, dann wenn der FBA Versand stattfand. Ich halte das ohnehin für falsch und wir korrigieren das Datum über die Datenbank, damit das Auftragsdatum mit dem echten Bestelldatum des Kunden übereinstimmt.

Ich würde sagen die Fehler betreffen nur das Importdatum/Versanddatum 6.6.2023.

Sorry, dass habe ich falsch gelesen. Bei mir ist es auch nur Importdatum / Versanddatum 06.06.2023

 

[jim-tonic]

Sorry, dass habe ich falsch gelesen. Bei mir ist es auch nur Importdatum / Versanddatum 06.06.2023

Ne, Du hast schon richtig gelesen. Seit ich glaube 1.6 setzt JTL das Importdatum statt dem Bestelldatum als Auftragsdatum. Man hat dann am Montag immer einen Bombenumsatz weil das Wochenende auf den Montag fällt. Daher korrigiere ich das nachträglich per Makro über die DB.

JTL, wenn das Jemand liest, bitte ändern wie es vorher war.

 

[Leventinio]

JTL, wenn das Jemand liest, bitte ändern wie es vorher war.

Das würde ich auch als wichtig empfinden. Leute die den Worker standartmäßig nicht nutzen, haben nie ein korrektes Auftragsdatum. @Enrico W. kannst du daraus mal ein Issue machen?

 

[Xndrei]

Ein kurzer Zwischenstand und eine Bitte an euch:

Wir testen das Tool derzeit im internen QA-Prozess. Wir könnten hier für unsere Tests nochmals eine weitere Datenbank benötigen, die von doppelten FBA-Bestellungen betroffen ist und zeitgleich Amazon VCS nutzt. Schreibt mir gerne kurz eine Nachricht hier im Forum, wenn ihr uns unterstützen möchtet.

Hi, hätte auch ein Backup für dich.

 

[Shopküche.de]

Ein kurzer Zwischenstand und eine Bitte an euch:

Wir testen das Tool derzeit im internen QA-Prozess. Wir könnten hier für unsere Tests nochmals eine weitere Datenbank benötigen, die von doppelten FBA-Bestellungen betroffen ist und zeitgleich Amazon VCS nutzt. Schreibt mir gerne kurz eine Nachricht hier im Forum, wenn ihr uns unterstützen möchtet.

Schafft ihr den Release noch bis morgen? Wenn bis morgen die Rechnungskorrekturen erstellt werden, dann ist das Thema in der Buchhaltung kein Chaos mehr. Sonst laufen alle doppelten Rechnungen von Juni in die Buchhaltung ohne Korrektur.

 

[JohnMeyers]

Das würde ich auch als wichtig empfinden. Leute die den Worker standartmäßig nicht nutzen, haben nie ein korrektes Auftragsdatum. @Enrico W. kannst du daraus mal ein Issue machen?

Habe ich schon im Januar diesen Jahres getan

 

[Leventinio]

Habe ich schon im Januar diesen Jahres getan

Kannst du mir dann mal den Link mitteilen?

 

[Spielgeist]

Hallo JTL und User, wie sieht es denn nun aus. Ist das Tool fertig? Wenn nicht, wie müssen wir händisch korrekt vorgehen, um die Daten in der Wawi zu bereinigen?

 

[pannscheck]

Hallo JTL und User, wie sieht es denn nun aus. Ist das Tool fertig? Wenn nicht, wie müssen wir händisch korrekt vorgehen, um die Daten in der Wawi zu bereinigen?

Wir haben am 30.6./1.7. Jahresabschluss!!
Falls das Tool erst im Juli läuft, MÜSSEN die Gutschriften ( GS Datum) noch auf den Juni laufen können.

LG Pannscheck

 

[JohnMeyers]

Kannst du mir dann mal den Link mitteilen?

Bug | WAWI-66893

Scheint aber für JTL nicht so wichtig zu sein... steht seit einem halben Jahr auf zukünftig

 

[recent.digital]

Bug | WAWI-66893

Scheint aber für JTL nicht so wichtig zu sein... steht seit einem halben Jahr auf zukünftig

Link funktioniert nicht richtig, hier der funktionierende Link: https://issues.jtl-software.de/issues/WAWI-66893

 

[P0ttwal]

Hallo JTL und User, wie sieht es denn nun aus. Ist das Tool fertig? Wenn nicht, wie müssen wir händisch korrekt vorgehen, um die Daten in der Wawi zu bereinigen?

Hast du das ernsthaft erwartet?

 

[Deploy24]

Wie sieht es aus? Meine Kunden sind auch schon ungeduldig, da sie die Rechnungskorrekturen brauchen um die Buchhaltung abzugeben.

 

[faceofboh]

So ist halt JTL. Als Kunde fühlt man sich da richtig wohl, wertgeschätzt ob der tollen Kommunikation und hat großes Vertrauen in die Zukunft.

 

[aaha]

So ist halt JTL. Als Kunde fühlt man sich da richtig wohl, wertgeschätzt ob der tollen Kommunikation und hat großes Vertrauen in die Zukunft.

🤔
🤬