Hallo,
es kommt bei uns immer wieder vor (war in der SW 4 auch so) das der Lagerbestand nicht mit dem Lager übereinstimmt. Wenn wir dan eine Zählung machen und alles in SW Aktualisieren dauert es keinen Monat und wieder sind Fehler vorhannden-
Wir können uns die Fehler nicht erklären, wir pflegen unseren Bestand natürlich bei z.B. offlinebestellungen. Kenn jemand die Problematik?
Wir haben auch eine Synchronisation mit einer Warenwirtschaft (Lagerbestand und Bestellungen) - bei uns passt alles. Der Fehler liegt also klar an der von euch eingesetzten Lösung. Habt Ihr an den Cache des Lagerbestands im Onlineshop gedacht?
Cache des Lagerbestands?
Naja bei eingeschaltetem Cache werden die meisten Sachen eben gecached. Dazu gehört z.B. der Lagerbestand (Preis z.B. wird nicht gecached). Wenn nun eine Bestellung eingeht dann wird der Cache für diesen Artikel invalidiert und der nächste Aufruf zeigt dadurch natürlich wieder den richtigen Bestand an.
Wenn nun aber im Ladengeschäft ein Artikel verkauft wird und per API ein update des Lagerbestandes an den Shop gesendet wird, wird der Cache nicht invalidiert. D.h. der nächste Aufruf des Artikels findet wieder aus dem Cache statt und dadurch stimmt der Lagebestand nicht.
Hier muss man also darauf achten, dass solche Updates auch zu einer korrekten Lagerbestandsanzeige im Shop führen.
Also nach manueller Änderung des lagerbestands im Backend chache leeren?
Hmm, das weiß ich nicht. Ich kann mir aber nicht vorstellen, dass das bei Änderungen im Backend nötig sein muss. Soweit ich das im Kopf habe wird dann auch der Cache invalidiert. Ich dachte ihr habt eine automatische Synchronisation mit einer Lagerhaltungssoftware.
Wenn dem nicht so ist dann macht vl. ein Plug-In Blödsinn oder der Fehler passiert beim manuellen updaten der Lagerbestände oder Diebstahl.
Macht ihr manchmal Testbestellungen?
Bei mir war es so, dass ich nach Testbestellungen die Ware wieder eingepflegt habe. Dann stimmt es wieder. Wenn man jetzt die Bestellung löscht, wird die Ware ein zweites Mal zurückgelegt. Das war bei mir ein Fehler.
@steinsoftware
Naja bei eingeschaltetem Cache werden die meisten Sachen eben gecached. Dazu gehört z.B. der Lagerbestand (Preis z.B. wird nicht gecached). Wenn nun eine Bestellung eingeht dann wird der Cache für diesen Artikel invalidiert und der nächste Aufruf zeigt dadurch natürlich wieder den richtigen Bestand an.
Ich weiß nicht, ob es noch aktuell ist, aber du schriebst, dass sich der Lagerbestand im Frontend aktualisiert, sobald eine Bestellung getätigt wurde.
Reproduzieren kann ich jedoch das nicht. Problem ist, dass eine Bestellung getätigt wurde, der Lagerbestand, wenn man diesen im Frontend mit {$sArticle.instock} ausgibt danach jedoch noch immer der alte ist. Erst wenn der Cache manuell geleert wird oder das Intervall ausläuft, wird die Variable {$sArticle.instock} aktualisiert…
Hi,
grundsätzlich werden Preise oder Bestände in Shopware immer live abgefragt! Das wird maximal im Template gecacht, wenn ihr das so irgendwo eingebaut habt.
Ab Warenkorb/Kasse ist standardmäßig der komplette Cache natürlich nicht vorhanden. Bei einer Bestellung wird in dem Moment des Bestellabschlusses der Bestand reduziert. Ist somit sofort für jeden anderen Besucher passend und der Bestand wird im Warenkorb und vor Bestellung immer nochmal direkt geprüft.
Stimmen also Bestände nicht, dass muss es eigentlich eine Schnittstelle, Plugin oder manuelle Anpassung als Ursache sein.
Sebastian
PS: Es wird aber im Standard bei einer Bestellung keinerlei Cache invalidiert. Das würde ja sehr stark negativ auf die Performance gehen.
@SebastianKlöpper
vielen Dank für deine Antwort.
Ich habe des in einem frisch aufgesetzten Shop reproduziert, indem ich bei einer Badge einfach mal $sArticle.instock ausgegeben habe. Dann habe ich den Shop auf Produktivmodus umgestellt und folgendes Szenario getestet:
in Kategorie XY den Artikel XY mit Bestand 10 ausgewählt - > Detailseite aufgerufen -> Artikel XY 1x in den Warenkorb gelegt -> über den Checkout 1x gekauft -> nach dem Kauf auf „zurück zum Shop“ geklickt und wieder in das Listing XY mit dem Artikel XY. $sArticle.instock als Badge zeigt noch immer 10 an.
In den Template Vars > frontend\listing\index.tpl|… (40) (z.B. mit Firebug) ist der Bestand von Artikel XY auch noch bei 10.
Erst nach Leeren des Caches über das Backend konnte ich den aktuellen Lagerbestand sehen.
Ist diese Verhalten nun falsch?
Hi,
das ist korrekt und völlig logisch. Das wird ja gecacht im Template/Theme.
Wenn du da sowas einbaust und das live sein soll, dass muss das auch entsprechend implementiert werden.
Understanding the Shopware HTTP Cache
Der Produktivmodus/Http-Cache speichert ja die gesamte Seite als HTML weg. Wenn man nicht speziell Bereiche ausschließt bzw. mit ESI-Tags live nachlädt, wird auch der Wert beim ersten Aufruf für die Cache-Zeit mit gespeichert.
Das ist ja genau das, was ich oben geschrieben haben.
Sebastian
@SebastianKlöpper
Könnte man dementsprechend aus den Badges mit Hilfe eines ESI-Tags diese aus dem Cache herausholen? Ich habe die Doku dazu leider nicht richtig verstanden.
Verstehe ich das richtig, dass ich in einem Theme oder Plugin dann die Badges beispielsweise über einen solchen ESI Tag aus dem Cache holen kann?
Also irgendwie so (code funktioniert natürlich nicht):
box-basic.tpl
{extends file="parent:frontend/listing/product-box/box-basic.tpl"}
{* Product box badges - highlight, newcomer, ESD product and discount *}
{block name='frontend_listing_box_article_badges'}
{action module=frontend controller=listing action=productBadges}
{/block}