Lagerbestand und Verfügbarer Bestand bringen mich zum verzweifeln!
Ich erstelle Testbestellungen und will im Nachhinein ein sauberer Bestand haben. Das gelingt mir nicht, da Unterscheide zwischen Lagerbestand und Verfügbarer Bestand gibt.
Weiß jemand welche Status eine Bestellung haben muss (Zahlungsstatus/ Lieferstatus / Bestellstatus) sodass am Ende immer Lagerbestand = Verfügbarer Bestand?
Danke und Gruß
Bringt mich auch zum Verzweifeln. Zwar ist es logisch, dass der Verfügbare vom tatsächlichen Lagerbestand wärend des Bestellvorgangs abweicht. Aber wenn eine Order abgeschlossen ist, sollte sich doch der tatsächliche Lagerbestand automatisch anpassen?
Bzw. spätestens beim Status „shipped“. Da der Artikel dann das Lager verlassen hat.
damit kämpfe ich auch gerade. Ich kenne das von meinem bisherigen System auch so, dass bei einer Bestellstornierung der Bestand wieder nach oben korrigiert wird.
Ich werde jetzt aus dem verhunzten Produkt ein Testprodukt machen, worauf ich Testbestellungen auslösen kann. Das ist aber keine Dauerlösung, da es ja immer wieder mal zu Bestellstornierungen kommen kann
Hallo [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)
kannst du uns bitte hier einen Vorschlag machen, wie wir das Problem lösen können? Der Lagerbestand und verfügbarer Bestand gehen auseinander bei Stornierungen. Der Lagerbestand bleibt unverändert aber der verfügbarer Bestand geht auf null. Somit kann man keine Bestellungen mehr machen, es sei denn ändert man den Lagerbestand nach oben. Aber dann stimmt der Lagerbestand nicht mehr.
Wie soll ich hier vorgehen?
Danke und Gruß,
Hey
es gibt hierfür bereits ein Ticket im Issue Tracker:
https://issues.shopware.com/issues/NEXT-6927
Wird demnach mit der 6.1.4 voraussichtlich korrigiert.
LG Andre
Wir schauen auch aktuell mal nach einem Quickfix.
Ich hake mich auch hier einmal rein - wir haben in unserer ERP auch verschiedene Bestände (Ist, frei, …)
Per API konnte ich den freien/verfügbaren Bestand leider nicht anpassen - das Feld sei schreibgeschützt.
Ich möchte gerne als Entwickler den Bestand an den Shop geben, den ich für richtig halte (bedeutet, irrelevant von Shop-Bestellungen) - wie geht das?
Am Ende zählt bei uns der Bestand in der ERP (eBay, Amazon, mehrere Shops, …) - nicht der Bestand innerhalb einer Plattform.
Schöne Grüße,
Niklas
Danke
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”) Könntest Du mir noch Feedback zu meinem letzten Kommentar geben?
In Kurzform: Ich möchte per API/Repository den freien/verfügbaren Bestand anpassen, weil bei uns (und allen anderen externen Systemen) sich der Bestand nicht aus dem Shop, sondern beliebig vielen anderen Quellen auseinander setzen kann - eine Bestellstornierung ist also komplett irrelevant, weil am Ende der verkaufbare Bestand aus vielen anderen Faktoren sich zusammenstellt.
EDIT : Wir werden das wohl lösen, indem wir andere Werte an den Shop geben um die Differenzen auszugleichen, die existieren können.
Schöne Grüße,
Niklas
Das Thema ist für mich auch weiterhin relevant. Mich würde interessieren, wann 6.1.4 mit dem Fix veröffentlicht wird.
Danke.
Für eine korrekte Berechnung brauchen wir auch die Menge an reservierten Beständen - ist das hier https://github.com/shopware/platform/blob/8f1007da94ac0b14b2463e84e766942b25073b8b/src/Core/Content/Product/DataAbstractionLayer/Indexing/ProductStockIndexer.php#L303 wirklich die einzige Stelle, an der es passiert? Private und plain SQL? … Da komme ich ja nicht wirklich schön ran …
Schöne Grüße,
Niklas
Ich hake hier mal ein, da ich aktuell die gleiche Herausforderungen habe… Shopware ist an unser ERP System angebunden. Dort laufen die tatsächlichen Bestände zusammen. Da das Feld des verfügbaren Bestands aber schreibgeschützt ist, lässt sich der Wert nicht überschreiben.
Jeder, der ein ERP hinter Shopware hat wird das Problem vermutlich in gewisser Form haben. Dafür muss es doch seitens Shopware eine Lösung geben?!
Guten Tag zusammen,
gibt es hier mittlerweile weitere Entwicklungen? Wir stehen gerade vor der gleichen Schwierigkeit da ein ERP System das Bestandsführende System ist.
Hat hier jemand eine Lösung? Das Problem müsste doch überall auftreten wo Produkte über mehrere Kanäle aus einem bestandsführenden ERP System verkauft werden.
Guten Tag,
es wäre sehr hilfreich wenn eine Bestellung getätigt wurde das ein reservierter Bestand abgezogen wird.
Nicht erst wenn die Bestellung „Abgeschlossen“ ist das der Bestand reduziert wird.
Shopware könnte ja ne Option machen, Bestand buchen bei Status X
Ich hänge mich ebenfalls ran.
Gibt es hier bereits eine lösung?
Wir haben ein ERP System an Shopware, welches den Bestand führend leitet.
Keine Chance das mit SW6 zu nutzen. Da wir unter SW5 das Backend niemals genutzt haben um die Bestellungen zu verwalten, sind fast alle Produkte nach der Migration zu SW6 trotz Bestand nicht mehr verfügbar!
Keine Lösung in Sicht und Shopware sagt, das soll so sein…
Wir hatten das selbe Problem und es lies sich nur lösen indem wir alle offenen Bestellungen abgeschlossen hatte, und jetzt eine eigene Integration alle 2 min den Bestand ändern lassen. Wir haben JTL im Einsatz.
Danke. Das mit dem abschließen habe ich probiert und dann neu migriert, funktioniert. Alle Bestände sind gleich dem verfügbaren Bestand.
Ansich ist der verfügabre Bestand ja eine tolle Sache, da sich Shopware nun selbst merkt, wenn es noch offene Bestellungen gibt, das haben wir vorher bzw. jetzt per manueller Auswahl im ERP gelöst.
In SW6 kann der Rule Builder genutzt werden um neue Bestellungen direkt als abgeschlossen zu markieren. Dann passen sich die Bestände ja auch wieder an.
Es kann doch nicht sein, dass es nach Jahren kein Häckchen gibt „Verfügbaren Bestand verwalten Ja/Nein“. Den Bestand, den unser ERP an Shopware meldet, ist der verfügbare Bestand, daran hat kein Shopystem ungefragt rumzufuchteln.
Ein weiterer Punkt auf einer großen Liste, wo wir uns gegenüber unserem Kunden rechtfertigen müssen.
Die Option sollte laut Roadmap ab 6.6 verfügbar sein.
Na super! Das bedeutet dann vermutlich (schon 
) im Mai 2024 …