Reservierung ändert sich ohne neue Aufträge?

Bestände
1

Guten Morgen,

ich bin heute auf ein Phänomen gestossen, was mich wirklich ratlos macht.
Ich habe mir aus einem Lager einen Export über Katalog gezogen, der mir den Physischen und den Reservierten Bestand für dieses Lager zieht.
In diesem Lager sind eigentlich immer alle Artikel im Gleichgewicht, sprich phys. und reserv. Bestand sind immer gleich, weil es sich nur um ein virtuelles Lager handelt.
Beim letzten Export am 15. war noch alles in Ordnung, heute dann bei 2 Artikel waren mehr phys vorhanden als reserviert.

image
image1032×103 11.6 KB

Aber es gibt für diese Artikel in diesem Zeitraum weder Aufträge mit Warenausgang, noch neue Aufträge . Keinerlei neue Warenbewegung also.
Lediglich einen Auftrag der geteilt wurde, dabei haben sich aber die Mengen nicht geändert.
Wie geht das? Hat Jemand ne Idee ?

Gruß

Ute

2

Ich mach zwar kein FBA, aber kann es sein, das die in ein anderes Lager umziehen und diese deshalb nun als Reserviert gelten und dann, wenn diese im anderen Lager sind im alten Lager auf 0 gesetzt werden und im neuen Lager wieder eingebucht mit denen Stückzahlen verbucht werden?

Könnte ich mir nur so vorstellen.

3

Wir listen nicht bei Amazon, sondern verkaufen nur über unseren Aussendienst und über den Shop.
Das kann ich also ausschliessen

4

Normal kenn ich das umgekehrt, dass Reservierungen existieren, ohne offenen Auftrag. Dann wurde ein Lieferauftrag nicht angelegt und der Lieferauftrag der existierte wurde versendet, wodurch der Auftrag als vollständig versendet angesehen wird.

Hier könnte ich mir etwas ähnliches vorstellen.

Wird das Lager evtl. anhand der Aufträge einmalig befüllt (also Wareneingang pro Auftrag)?

Dann wurden evtl. die Lieferaufträge später erzeugt und dann das Lager mit den Lieferaufträgen zusätzlich befüllt.

Zumindest würde das von der Logik her passen.

Beispiel bei uns:

Kollegen bestellen für Auftrag X ein Produkt 10 mal.
Nachbestellung über 10 wird angelegt.
Lager prüft die Lieferung und buchen ohne zu prüfen 10 ins Lager, obwohl nur 5 geliefert wurden.
Lieferaufträge werden angelegt, da nur 5 da sind.
Ein Lieferauftrag geht raus.
Der andere wird neu bestellt, sobald im Hauptlager wieder Ware ist.
Geht man davon aus das alles da ist sind jetzt insgesamt 15 auf unser virtuelles lager gebucht worden. Davon sind 5 schon raus
Physisch also 10
Reserviert entsprechend 5

5

Hallo @DarkCMS-Kevin ,

wir buchen aus unserem Hauptlager die Bestände, pro Auftrag, in dieses Lager um.
Dann werden diese Aufträge irgendwann entweder geteilt oder gruppiert, bleiben dann weiter bestehen oder werden ausgebucht.
Im fraglichen Zeitraum wurde nur 1 Auftrag mit diesen beiden Artikeln geteilt.
Sprich aus Auftrag A wurden die beiden Aufträge AA und BB .
Auftrag AA wurde ausgebucht, darin sind diese beiden Artikel aber nicht enthalten.
Auftrag BB (mit diesen Artikeln) bleibt in diesem Lager, die Menge hat sich aber nicht geändert.
Auftrag BB enthält auch viel mehr Artikel, dann müssten ja auch mehr im Ungleichgewicht sein.
Sprich die Reservierung hat sich nicht geändert, und es wurden keine neuen Mengen ein-oder ausgebucht.
Mit Lieferaufträgen arbeiten wir gar nicht .

Gruß

Ute

6

So, neue Entwicklung:
Plenty hat folgendes geantwortet:

Hallo Ute,

kannst du es jetzt nochmal prüfen? Wir haben eine Korrektur in der Datenbank vorgenommen. Behalte die beiden Varianten mal bitte im Auge.
Viele Grüße,

Die beiden Varianten aus meinem Beispiel stimmen jetzt wieder :flushed_face:

Zwei andere, die weniger eindeutig waren, weswegen ich sie nicht als Beispiel genommen hatte, noch nicht.

ABER, es ist eine neue Variante dazu gekommen, die heute morgen noch in Ordnung war.
Und das macht mir wirklich Sorgen.
Was geht denn da ab?

Gruß

Ute

7

Mal ne ganz doofe Frage, versteh ich das richtig, dass du an der Stelle zu wenige Reservierungen stehen hast, als eigentlich sein sollten?

8

Das ist eine gute Frage, entweder der Bestand verändert sich unvermittelt, oder eben die Rerservierung.
Dieser Artikel war heute morgen noch im Gleichgewicht.
22 St. Phys. / 22 Stück reserviert
Nachdem Plenty dran war, reduzierte sich die Reservierung um 2 Stück

image
Daraufhin habe ich eben mal die Mengen des Artikels, in diesem Lager, ohne Warenausgang zusammen gezählt.
Und es sind: 20
Also ist jetzt die Reservierung korrekt, nicht aber der physische Bestand .

Das Gleiche habe ich eben für einen der Artikel, der heute morgen falsch war und auch von Plenty korrigiert wurde, gemacht.
Da sind 13 aktuell in den Aufträgen reserviert, was bedeutet heute morgen war die Reservierung falsch.

image

Könnt Ihr mir noch folgen ? Mir schwirrt jedenfalls der Schädel…

Gruß

Ute

9

Ich, definitiv.

das macht das Problem aber nicht kleiner :slight_smile:

Den Katalog ziehst du dir Live?
Oder regelmäßig als bereitgestellter Download (also diese „Wir erstellen alle 20 Minuten eine neue Datei“)?

10

Ich denke ja inzwischen schon, ich wäre bekloppt.
Aber wir hatten das Thema in den Letzten Wochen schon mehrfach, haben aber immer gedacht wir würden den Fehler machen.
Kann ja auch sein, aber dieses mal wollte ich dem Thema auf den Grund gehen.

Immer Live

Gruß

Ute

11

Bei diesem Artikel war es auch die Rerservierung die falsch war.
Es sind wirklich 29 in den Aufträgen des Lagers
image

12

Neue Auskunft von Plenty:
Hallo Ute,

*an den physischen beständen wurde nichts geändert, lediglich die Reservierungen wurde auf den neuen Reservierungs-Micro-Service umgestellt. Dazu hast du auch eine Benachrichtigung im Backend erhalten. *

Was wir heute gemacht haben, war, dass wir den Micro-Service einmal deaktiviert haben, dann die Bestände berechnet und anschließend den Micro-Service wieder aktiviert. Dadurch konnten wir einen kompletten Sync der Reservierungen vornehmen, das sollte jetzt also stimmen. Wenn die phys. Bestände nicht passen bzw die Reservierungen vorher höher waren, dann waren sie bereits vor der Umstellung auf den Micro-Service auch schon falsch. Kurz gesagt, die Reservierungen sind korrekt. Ihr müsstet mal im Lager schauen wie viel bestand ihr habt und dementsprechend den Bestand dann korrigieren.
Viele Grüße,

und meine Antwort dazu:

Hallo xxx,

also das Problem hängt mit der Umstellung auf den Microservice zusammen ?

Die Umstellung hatte ich vorgenommen.

Sprich jetzt sind alle Reservierungen korrekt?

Leider ist es nicht möglich die physischen Bestände mal eben zu zählen.

Das Lager ist ein Sammelbecken von an die 100 Kunden, die wir mit Ware auf Kommission beliefern.

Deshalb buchen wir immer, wenn diese neue Ware kommen, diese über einen Auftrag aus unserem Hauptlager in dieses Lager um. Verkaufte und abgerechnete Ware wird dann ausgebucht .

Gruß

Ute

13

Dann würde ich mir heute als Stichtag notieren und das nochmal beobachten.

Tricky wird die Geschichte mit dem Überbestand.
Da lässt sich schwer nachvollziehen, wie der Ursprung ist.

Wenn direkt aus dem Auftrag heraus Ware bestellt wird, sollte es eigentlich keine Überbuchung geben.

Jeder andere Weg :speak_no_evil_monkey:
Wobei, wenn über die „Warenbestand“-Seite gearbeitet wird und dort dann als Vorschlag die 29 drinstehen, würde das passen, kommt dann aber in Konflikt mit denen wo richtig eingebucht wurde, obwohl zu wenig reserviert war.

14

Neue Antwort von Plenty.
Danach gehe ich jetzt mal davon aus, dass die Reservierungen mit Stand heute stimmen.
Also werde ich die physischen Bestände manuell korrigieren, und dann in nächster Zeit immer mal wieder kontrollieren.
Zählung scheidet leider aus.

Naja, der Microservice erfasst alle Reservierungen aus den Aufträgen, die natürlich in dem eingestellten Statusbereich liegen und erzeugt diese dann. Daher sollten die Reservierungen jetzt passen. Daher gehe ich davon aus, dass vor dem Einsatz des Micro-Service die Reservierungen nicht korrekt waren. Aber wie du ja auch sagst, passen die Reservierungen nun zu den offenen Aufträgen ohne Warenausgang. Vielleicht ist mal eine Stornierung nicht korrekt durchgelaufen oder ein Warenausgang ist abgebrochen, genau werden wir es nicht mehr ermitteln können.

Am besten wäre es wenn ihr eine Möglichkeit findet die phys. Bestände zu zählen oder zählen zu lassen. Es scheinen ja nicht viele Varianten betroffen zu sein.
Viele Grüße,

15

Guten Morgen ,

neueste Info dazu:
Das Problem bestand letzte Woche noch weiter und wurde auch nachdem Plenty den Microservice für die Reservierungen erst deaktiviert und nochmal neu aktiviert hatte weiter, bzw es wurde schlimmer.
Am Mittwoch Mittag hat sich dann nach viel hin und her , raus gestellt dass der Mitarbeiter die ganze Zeit das Thema nicht wirklich verstanden hat.
Ich sprach von Reservierungen, er abe rimmer nur vpm physischen Bestand.
Dann kam das:
Wir haben uns den Fall gerade nochmal von dem Fall von gestern mit der Variante ID 6332 angeschaut. Das Problem ist, dass für einen der Aufträge nur 3 reserviert sind, im Auftrag aber die menge 5 steht. Es fehlen also 2 Reservierungen zu der Variante, weshalb es gestern phys. 29 angezeigt hat und reserviert dann 27. Wir werden jetzt die neue Reservierungslogik deaktivieren.

An dieser Stelle möchte ich mich für die Unannehmlichkeiten entschuldigen und der entstandene Mehraufwand. Ich befürchte allerdings, dass ihr die Korrekturen an den Varianten wieder Rückgängig machen. Da ihr die Dateien noch vorliegen habt, könnt ihr euch die Varianten aufrifen und die Korrektur rückgängig machen. Wir werden die reservierungslogik bei euch deaktiviert lassen, bis der Fehler in der Migration behoben wurde. Ich möchte mich nochmals aufrichtig für die Unannehmlichkeiten entschuldigen.
Meine Antwort
Hallo xxx,
nur damit ich Dir folgen kann.
Es liegt also wirklich ein Fehler in der “neuen” Reservierungslogik vor ?

Positiv möchte ich anmerken, dass Du schnell reagiert hast . Das freut mich ehrlich gesagt, denn manchmal dauert es ja deutlich länger bis man eine Reaktion bekommt. Also Danke dafür.
Schade ist aber auf der anderen Seite, dass wir jetzt fast 3 Arbeitstage in dieses Thema gesteckt haben, um dann doch auf das eigentliche von mir vermutete Problem zu stossen.
Die Entschuldigung ist aber akzeptiert.
Ich würde mich morgen früh wieder melden, mit einem aktuellen Stand der Dinge.
Darf ich davon ausgehen, dass Du mich auf dem Laufenden hälst?
Was machen wir mit neuen Vorgängen? Warenausgängen, neuen Aufträgen usw für dieses Lager, können wir ganz normal arbeiten morgen ?
Er:
Genau, die bestände die ihr fälschlicherweise korrigiert habt. Wenn ihr das Korrigiert habt, solltet ihr unbedingt so vorgehen wie du es beschreibst, also mit den Exporten. Vielen Dank für dein Lob und es tut mir wirklich Leid, dass wir das problem nicht erkannt haben. ich werde dich natürlich auf dem laufenden halten und dir mitteilen sobald die Migration gefixed ist. Ich werde dir auch sagen wann wir die Migration erneut vornehmen, dann kannst dun erneut einen Export zur Kontrolle vornehmen. Bis dahin könnt ihr ganz normal weiterarbeiten wir ihr es gewohnt seid.

Es hat sich dann noch bis Freitag hin gezogen, aber aktuell sieht es so aus, als sei das Problem gelöst. Hoffentlich dauerhaft.

Gruß

Ute

16

Ich dachte ja eigentlich das Thema wäre geklärt, aber Plenty hat mit das Gegenteil bewiesen:

Guten Morgen x,

ich weiss nicht ob ich grade lachen oder weinen soll.

A) ist Dir bewusst wie viel Zeit und Geld es uns kostet solchen Fehlern auf de Schliche zu kommen. Wer bezahlt das ?

B) Wie lange soll das dauern bis Ihr uns migriert habt? Wir können ja so nicht weiter arbeiten.

“und dann passiert das auch nicht wieder, da es ein reines Migrationsthema ist. ”

Sorry , aber dein Wort in Gottes Ohr. Denn das hattet Ihr auch beim letzten mal schon versprochen.

Gruß

Ute

  • Hi Ute!

Danke für die Meldung, tatsächlich gab es ein Problem bei der Migration und deswegen habt Ihr zu viele Reservierungen. Das lösen wir, indem wir neu migrieren. Das Verhalten war schon die ganze Zeit da, aber erst durch den Auftrags-Split kam es zur Neukalkulierung bei den Varianten und dann sichtbar.

Ich gebe Bescheid, wenn wir das korrigiert haben und dann passiert das auch nicht wieder, da es ein reines Migrationsthema ist. Bitte entschuldige, dass es erneut passiert ist.

Viele Grüße,

Ute Fenske

vor 1 Stunde

Guten Morgen x.,

leider tritt der Fehler in der Reservierungslogik im Lager KV #103 wieder auf.

Ich beziehe mich hier auf diese Anfrage von mir, Du erinnerst DIch sicher:

:https://help.plentyone.com/hc/de/requests/19676

Meine Kollegin hat gestern, zum ersten mal nach Ihrem Urlaub ( vor dem der Fehler auftrat), den Auftrag 18792 geteilt .

Die daraus entstandenen Aufträge sind 19593 und 19594.

19593 bleibt im KV Lager, 19594 wurde ausgebucht.

Seitdem sind 22 Artikel in diesem Lager “Überreserviert”

Der Katalog 83adf127-da06-5f72-8621-c7f21ea4da2f zeigt das.

Ich habe mir mal exemplarisch den Artikel mit der Var.ID 8260 angesehen.

Gestern morgen sah der im Katalog so aus :

Danach so:

Die Reservierung explodiert förmlich.

Daraufhin habe ich mir mit Katalog bfb7c6cb-960d-5c99-8647-5c3a5d3a41dc mal mal alle Aufträge exportiert, die diesen Artikel in diesem Lager enthalten. Das sind genau 227.

505×481 7.08 KB

Sprich es müssten eigentlich 227 physischer UND 227 reservierter Bestand sein.

Meine Therorie ist, dass irgendwas in Kombination mit der Reservierungslogik und dem gruppieren / teilen von Aufträgen hakt.

Denn das machen wir nur in diesem Lager. Wäre generell was kaputt müssten ja auch die anderen Lager in Schieflage sein oder ?

Ich hoffe Ihr findet da schnell eine Lösung, denn so lässt es sich gar nicht arbeiten.

Gruß

Ute

—