Falscher Warenbestand bei Produktpflege und zwischenzeitlicher Bestellung

[Tarob]

Hallo zusammen,

mir ist folgendes aufgefallen:

Wenn ich gerade dabei bin ein Produkt zu pflegen (sei es um den Bestand zu erhöhen oder die Artikelbeschreibung anzupassen) und während ich beim Bearbeiten des Artikels bin und jemand den Artikel in einer Stückzahl X kauft und den Bestellvorgang beendet, ich aber erst danach meine Änderung speichere, so wird der Bestand dann so gesichert wie ich den Artikel geöffnet hatte.

ERGO: Der Bestand stimmt nicht mehr!

Nochmal etwas deutlicher in zeitlicher Abfolge:

1. Admin öffnet Artikel XY zur Bearbeitung (Bestand 10)
2. Benutzer kauft Artikel XY (Anzahl 5) (checkout komplett)
3. Admin speichert Artikel mit Bestand 10 (da Bestand 10 war als Artikel zum Bearbeiten geöffnet wurde)

Nun haben wir im Shop 10 Stück gelistest obwohl real nur noch 5 vorhanden sind, da diese vom Benutzer gekauft wurden.

Wie kann man das verhindern?

Meine Idee war:

Bevor ich einen Artikel editiere, deaktiviere ich ihn.

Dies funktioniert wohl für den Fall das ein Kunde den Artikel noch nicht im Warenkorb hat. Liegt der Artikel allerdings schon vor dem Deaktivieren im Warenkorb, ist das dem System egal und er verringert den Bestand trotzdem nach dem Checkout.

Die Frage ist also: Wie kann ich gefahrlos einen Artikel editieren, ohne das der Bestand fehlerhaft wird?

Ist es vielleicht auch möglich dies systemseitig zu verhindern (durch ein entsprechendes DB-Flag etc.)?

Danke im voraus.

Linkback: https://www.modified-shop.org/forum/index.php?topic=17046.0

[Tomcraft]

[...]
1. Admin öffnet Artikel XY zur Bearbeitung (Bestand 10)
2. Benutzer kauft Artikel XY (Anzahl 5) (checkout komplett)
3. Admin speichert Artikel mit Bestand 10 (da Bestand 10 war als Artikel zum Bearbeiten geöffnet wurde)
[...]

Sorry wenn ich hier den Fehler nicht finden kann...

Verschoben von "Bugs oder Funktionsfehler" nach "Admin- und Shopbereich".

Man könnte darüber nachdenken hier vor dem Speichern nochmal mögliche Änderungen abzufragen und ggf. einen Hinweis auszugeben.

Grüße

Torsten

[Tarob]

Hallo Torsten,

nun ich halte das für einen Fehler vom Shopsystem, da dies doch abgefangen werden müsste / könnte.

Siehst du das anders?

Stell dir einen großen Shop vor, mit über 10.000 Artikeln und hunderten täglichen Bestellungen. Wenn man nun als Betreiber eine Lieferung bekommt, und den Bestand entsprechend ändern (addieren, subtrahieren) muss, und dies bei mehreren hundert Artikeln es dort zwischenzeitlich zu diesem Verhalten kommt, stimmt der Warenbestand vorne und hinten nicht und Kunden werden Artikel bestellen, die nicht mehr auf Lager sind.

Also wo wäre an dieser Stelle dann Fehlverhalten des Shopbetreibers?

Oder anders gefragt: Wie muss der Shopbetreiber bei der Produktpflege vorgehen?

Danke im voraus.

[Tarob]

Nochmal Hallo.

Was ich allerdings wirklich für einen Fehler halte, ist das Zweite beschriebene Phänomen:

Wenn ich den Artikel vor Bearbeitung deaktiviere. Nun kann niemand den Artikel kaufen.

ABER

Kunden die vorher den Artikel im Warenkorb hatten, können das trotzdem!

Das dürfte doch aber eigentlich nicht passieren, oder wie siehst du das? Da müsste vor dem Checkout, in der Routine wo der Bestand geprüft wird, doch evtl. noch geprüft werden ob ein Artikel aktiviert ist.

Wie siehst du das?

Danke und Gruß

Patrick

[ThorstenK]

[...]
Kunden die vorher den Artikel im Warenkorb hatten, können das trotzdem!

Das dürfte doch aber eigentlich nicht passieren, oder wie siehst du das? Da müsste vor dem Checkout, in der Routine wo der Bestand geprüft wird, doch evtl. noch geprüft werden ob ein Artikel aktiviert ist.
[...]

Hier bin ich völlig bei Dir, das macht mich auch irre, ich hab Kunden die Ihre Warenkörbe teils erst nach 14-Tagen auch kaufen und dann hast Du den Salat, so eine Prüfung gehört denke ich auch in den Shop.

Das Bestandsproblem kann Dir aber kein Datenbanksystem der Welt lösen. Das ist ein einfaches Versionierungsproblem. Die Shopsoftware hat damit nichts zu tun, der Hebel müsste bei MySQL angelegt werden. Einige Systeme behelfen sich damit, dass sie die letzte Änderung (also Deine in diesem Fall) verwerfen und der Bearbeiter noch mal von vorne anfangen kann. Auch nicht so prickelnd.

Übrigens beneidenswert, dass das ein echtes Problem für Dich ist, das muss ja richtig brummen. Lösungsvorschlag: Mit externer Software offline die Änderungen vornehmen und in den Shop schiessen. Das reduziert die Zeitfenster zur Bearbeitung im Shop deutlich.

Grüße
Thorsten

[Tarob]

Hallo Thorsten,

es beruhigt mich aber doch, dass es ausser mir noch jemanden gibt, dem das aufgefallen ist.

Hm. Hm. Hm.

Das mit der externen Software ist sicher eine Alternative. Kennst du da ein brauchbares Tool?

Und auch hier muss natürlich der Bestand berücksichtigt werden...

Danke für deine Hilfe.

lg

Patrick

[ThorstenK]

Die meisten hier und auch ich verwenden JTL-Wawi. Interessant ist das vor allem wegen dem Worker - der pollt in regelmässigen Abständen die Bestellungen aus dem Shop in die Wawi und übermittelt die Artikeländerungen in den Shop. Interessant dabei ist vor allem, dass Bestandsminderungen durch Bestelleingänge erst mal in den "reservierten Bestand" gehen. Das heißt Dein gerade eingegebener Bestand ist auch bei Eingang einer Bestellung während Deiner Änderungen korrekt.
Nehmen wir an Du hast einen Bestand von 10 Stk., es geht eine Bestellung über 3 Stk. ein während Du gerade den Bestand um 10 erhöhst, sieht das wie folgt in JTL Wawi aus.

Vor Bestelleingang:
Bestand: 10
Zugang: 10
reserviert: 0
-------------
Verfügbar: 20

Bestelleingang:
Bestand: 10
Zugang: 10
reserviert: 3
--------------
Verfügbar: 17

An den Shop wird immer der verfügbare Bestand übermittelt, die Bestände stimmen also. Du müsstest dann extremes Pech haben, dass exakt in der Millisekunde in der der Artikeldatensatz aktualisiert wird eine Bestellung abgschlossen wird. M.E. ein völlig zu vernachlässigendes, hypothetisches Problem.

Ich hoffe ich konnte behilflich sein.

Grüße
Thorsten