Pickware zerschießt Bestände!

Wir setzen seit einigen Wochen Pickware (ohne Mobile/Handscanner) ein, und ich bin kurz vor dem Nervenzusammenbruch.

Laufend zerhaut es uns die Bestände, und ich komme auch nicht dahinter, wie das zustande kommt.

Immerhin wissen wir nun, daß wir bei Retouren ZUERST Versendet=0 setzen müssen, bevor wir die Stornorechnung erstellen lassen. Beim Verschicken lassen wir natürlich die physikalischen Bestände auch brav ausbuchen.

Trotzdem laufen die Zahlen immer wieder unkontrolliert auseinander: oft ist der Lagerbestand fälschlicherweise niedriger als der verfügbare Bestand, manchmal ist es auch andersrum, und dann kommts auch vor, daß einfach gar nix passt.

Katastrophe!

Falls jemand einen heißen Tip hat her damit. 

Importiert ihr eure Bestände zufällig täglich per CSV?

Wir laden jeden Tag unsere Bestände via Import / Export Modul hoch und haben dadurch auch immer auseinander gehende Bestände.

Von Zeit zu Zeit bereinigen wir diese indem wir alle komplett nullen und dann neu hochladen.

Nein, wir haben keine Schnittstellen!

OK also nutz ihr rein die Bestandsverwaltung in Pickware.
Dann kann ich da leider nicht wirklich helfen.

Was sagt denn die Bestandshistorie, ist die Veränderung da nachvollziehbar? Sind eventuell irgendwelche Plugins aktiv die mit dem Bestand arbeiten? Wir arbeiten seit fast einem Jahr mit Pickware und den mobilen Scannern und haben keinerlei Probleme. 

1 „Gefällt mir“

Nein. Läßt sich nicht nachvollziehen.

Wir hatten Anfangs immer wieder Differenzen, die wir dann manuell im Backend behoben haben.

Dann haben wir zwischen den Tagen große Inventur gemacht und die Bestände komplett abgeglichen in der Hoffnung, daß wir nun grün sind, da uns Pickware auf den Fehler im Ablauf der Storno Buchungen (ZUERST Versendet Nullen, dann Storno) hingewiesen hatte. Naiv wie ich war dachte ich, damit ist das Problem gelöst, und erste Tests sahen auch gut aus.

Das Pflegen der Bestandsabweichungen über das Backend ist eine Strafarbeit. Hab mir daher dann ein Tool zaubern lassen um die Bestände komfortabel ohne Backend abzugleichen, für diese Anpassungen ist in der Bestandshistorie dann logischerweise auch kein Eintrag. Nach den Anpassungen mit dem Tool stimmen die Bestände dann … und ein paar Tage später dann offensichtlich nicht mehr.

Jetzt 2-3 Wochen später bekommen wir langsam wieder Probleme mit fehlenden Artikeln aus Bestellungen und ich muß feststellen, daß es wieder total auseinanderläuft. An den Workflow wird sich akribisch gehalten. Daran liegt es nicht. Sonst fummeln auch keinerlei Plugins in den Beständen herum.

Von Pickware kam bisher nur läppsch die Aussage, ich sollte halt den Scanner kaufen. Ey sorry, wenn das System ohne Scanner nicht lebensfähig ist, dann sollen die das vorher sagen und gar nicht erst so ungar verkaufen. Kann mir ja auch keiner versprechen, daß es dann mit dem Ding hier besser läuft.

@xMarcox schrieb:

Importiert ihr eure Bestände zufällig täglich per CSV?

Wir laden jeden Tag unsere Bestände via Import / Export Modul hoch und haben dadurch auch immer auseinander gehende Bestände.

Von Zeit zu Zeit bereinigen wir diese indem wir alle komplett nullen und dann neu hochladen. 

Hallo xMarcox,

sofern Sie das Import/Export Advanced Modul von Shopware nutzen, gibt es eigens von Pickware zur Verfügung gestellte Profile, um die Bestandsdaten zu importieren. Weitere Informationen dazu, finden Sie in unserem entsprechenden Blogpost.

 

@alDente schrieb:

Nein. Läßt sich nicht nachvollziehen.

Wir hatten Anfangs immer wieder Differenzen, die wir dann manuell im Backend behoben haben.

Dann haben wir zwischen den Tagen große Inventur gemacht und die Bestände komplett abgeglichen in der Hoffnung, daß wir nun grün sind, da uns Pickware auf den Fehler im Ablauf der Storno Buchungen (ZUERST Versendet Nullen, dann Storno) hingewiesen hatte. Naiv wie ich war dachte ich, damit ist das Problem gelöst, und erste Tests sahen auch gut aus.

Das Pflegen der Bestandsabweichungen über das Backend ist eine Strafarbeit. Hab mir daher dann ein Tool zaubern lassen um die Bestände komfortabel ohne Backend abzugleichen, für diese Anpassungen ist in der Bestandshistorie dann logischerweise auch kein Eintrag. Nach den Anpassungen mit dem Tool stimmen die Bestände dann … und ein paar Tage später dann offensichtlich nicht mehr.

Jetzt 2-3 Wochen später bekommen wir langsam wieder Probleme mit fehlenden Artikeln aus Bestellungen und ich muß feststellen, daß es wieder total auseinanderläuft. An den Workflow wird sich akribisch gehalten. Daran liegt es nicht. Sonst fummeln auch keinerlei Plugins in den Beständen herum.

Von Pickware kam bisher nur läppsch die Aussage, ich sollte halt den Scanner kaufen. Ey sorry, wenn das System ohne Scanner nicht lebensfähig ist, dann sollen die das vorher sagen und gar nicht erst so ungar verkaufen. Kann mir ja auch keiner versprechen, daß es dann mit dem Ding hier besser läuft.

Hallo alDente,

natürlich können Stornos und Retouren auch korrekt über das Backend abgewickelt werden, ohne das es zu auseinanderlaufenden Zählern und Bestandsfehlern kommt. Vorerst daher auch nochmal hier der direkte Link zur Dokumentation für die Verarbeitungen von Retouren ohne Pickware Mobile.

Wir vermuten, dass Ihr Tool zur automatischen Behebung von Bestandsfehlern leider nur temporäre Korrekturen dieser vornimmt, anstatt die Ursache der Fehler korrekt zu beheben. Wenn die Bestandsfehler einmal im Ursprung beseitigt wurden, tauchen diese auch nicht wieder auf. Daher haben wir auch dazu vor einiger Zeit einen Blogpost veröffentlicht, der bei der Beseitigung der Bestandsfehler helfen soll: pickware.de/blog/posts/pickware-1x1-physischer-reservierter-verfuegbarer-lagerbestand-was-heisst-das.

Ausnahmen können durch Drittanbieterplugins hervorgerufen werden, welche den verfügbaren Lagerbestand verändern, ohne auch die entsprechende Änderung am physischen Lagerbestand vorzunehmen. Ob mit oder ohne Scanner gearbeitet wird, hat dabei selbstverständlich keinen Einfluss auf die Richtigkeit der Bestände. Da Sie einen Einfluss von Drittanbieterplugins bei Ihnen ausschließen, würden wir Sie bitten uns einmal per E-Mail zu kontaktieren, damit wir die Bestandsfehler in Ihrem Shop untersuchen können.

Viele Grüße und ein schönes Wochenende
das Pickware Team

… wir haben jetzt folgenden Hinweis vom Support bekommen:

Die Änderung des physischen Bestandes ist eine weitreichendere Änderung als nur die Änderung des Wertes in der Datenbank. Im Hintergrund läuft hier ein komplexer Stock-Manager, der die Änderungen des Bestandes verwaltet.

Das war dann wohl der Grund, warum die Bestandsanpassungen in der DB nicht nachhaltig waren.

 

Immerhin gibt es nun endlich einen Weg, die Bestände ohne den Backend Klick Wahnsinn abzugleichen (das gibts wohl erst seit neulich):

Seit einem der letzten Updates ist es möglich Bestände per CSV-Import Bestände zu aktualisieren. Damit sollten Sie keine Änderungen in der Datenbank vornehmen. Eine Anleitung finden Sie hier.

https://docs.google.com/document/d/1O2BHC--F\_3Fmzke-MN-8ghnVJfe0pYAW\_Tb9jht-Y9o/edit#heading=h.6d8ze2ek7i69

… ich werde berichten. 

1 „Gefällt mir“

„Führen Sie eine Stornierung aller relevanten Positionen wie im obigen Abschnitt durch und erstellen Sie ggf. eine Stornorechnung. Gegenüber der Storno muss in diesem Fall zusätzlich eine manuelle Bestandskorrektur über die Artikelstammdaten erfolgen, um die Ware wieder physisch einzubuchen. Erhöhen Sie daher den physischen Lagerbestand in Höhe der retournierten Ware über die Artikelstammdaten.“

Warum nicht einfach eine Checkbox zum Wiedereinlagern der Artikel einbauen,sobald man storniert, anstatt das manuell machen bzw über die „Versendet“-Spalte? Gilt auch für Rückgabe am POS. Das wäre das plausibelste - das jetzige Verhalten ist imho ein Bug und vllt auch verstecktes Upselling für die mobile App :stuck_out_tongue:
 

Auch eine einfachere Möglichkeit Bestandsinkonsistenzen zu beheben wär e super - das Click-working ist echt ne Höllenarbeit, wenn man bei Kunden „aufräumen“ soll.
Für jeden Hinweis um da massenhaft alles zu bereinigen wär ich sehr dankbar.