Für einen Shop für medizinische Produkte sollen wir die Möglichkeit einbauen, dass der Kunde bei der Artikelkonfiguration auswählen kann “Ohne Rezept” und “Mit Kassenrezept”. Bei Kassenrezept wird der Käufer angewiesen, das oder die entsprechenden Rezepte an den Shop-Anbieter zu senden per Post. Gleichzeitig sollen diese Artikel im Bestellvorgang mit 0,00€ versehen werden. Dazu haben wir einen allgemein-gültigen Gutschein erstellt, der 100% auf die Artikelpreise aller Rezept-Artikel ermöglicht, den der Kunde dann nur noch im Warenkorb eingeben muss (ein entsprechender Hinweis im Warenkorb ist vorhanden).
Da die Artikelvarianten durch weitere Parameter sehr zahlreich sind, ist auch sehr viel in der Liste für die zugelassenen Artikel einzutragen. Nach einer Anzahl X wirft Shopware jedoch einfach nur einen Communication Error 0 und die Liste ist wieder leer nach dem erneuten Öffnen des Gutscheins. In der Datenbank sind sie noch vorhanden in der Einschränkungsliste. Wenn man die Liste nun erneut befüllt, wird die alte in der Datenbank überschrieben.
Im System-Log und im Backend-Log finden sich keine Spuren dieser Fehlermeldungen und auch nicht im Server-Log. Die AJAX-Timeoutzeit wurde schon hochgestellt von 30 auf 60 Sekunden, trotzdem erscheint sofort nach dem Öffnen des Gutscheins die Fehlermeldung.
Dazu bemängeln wir auch die eingeschränkten Filterfunktionen in der Artikelauswahl bei den Gutscheinen, denn man kann nur nach dem Artikel- oder Herstellertitel suchen, nicht nach Bestandteilen von Varianten. Oder eben die Einschränkung von Gutscheinen nach Konfiguratoroptionen (die hier ungemein hilfreich wäre).
Das Problem lässt sich leider nicht umgehen, alternativ könntet ihr mal schauen, ob es mit der “Advanced Promotion Suit” von Shopware besser funktioniert.
Hier lassen sich Rabatte auf Basis von Gutscheinen hinterlegen, welche eine detailliertere Zuordnung und ein besseres Ausschlussverfahren erlauben.
Könnt Ihr ja erst einmal testen vor der Kaufentscheidung.
Alternative: Alle betroffenen Artikelvarianten über die Datenbank auslesen, in das entsprechende Feld beim Gutschein eintragen und den Gutschein nicht mehr über das Backend bearbeiten… ist nicht schön, aber leider alles, was Shopware im Standard hergibt.
Ich habe ein ähnliches Problem und gehe davon aus, dass es an der Anzahl der Artikel liegt, auf die der Gutschein (5% Rabatt) begrenzt wird. Ich wollte alle Nadelspiele und alle Sockenwollen rabattieren (bei den Nadelspielen sind das enorm viele, weil alle Varianten - also alle Nadelstärken - einzeln ausgewählt werden müssen). Auch hier verschwindet die Liste der ausgewählten Artikel in der Gutscheinansicht im Backend, wenn man den Gutschein schließt und dann wieder öffnet. Allerdings hatte ich keine Fehlermeldung.
Schlimmer noch: Es werden zwar alle ausgewählten Artikel rabattiert, aber wenn jemand jetzt ganz andere Artikel in den Warenkorb legt, die allesamt nicht in der Liste der rabattierten Artikel sind, und dann spaßeshalber trotzdem den Gutscheincode eingibt, dann greift der Gutschein für alle Artikel im Warenkorb.
Ih habe den Gutschein erstmal wieder entfernt, weil das gar nicht geht.
Wir haben ein PHP-Skript erstellt, dass alle X Stunden mittels Cronjob durch den Server ausgeführt wird. Zuerst wird über
SELECT ordernumber FROM s_articles_details, s_article_configurator_option_relations WHERE s_article_configurator_option_relations.option_id = 87 AND s_article_configurator_option_relations.article_id = s_articles_details.id;
eine Liste erstellt, die alle betreffenden Artikelnummern für den Gutschein aus der Datenbank holt, wobei hier 87 die ID der betreffenden Konfigurator-Option in unserem Fall ist. Das Ergebnis wird dann mittels Semikolon zu einem String verkettet und mit
UPDATE s_emarketing_vouchers SET restrictarticles = ";artikelnummer1;artikelnummer2" WHERE id = 1
in die Gutscheintabelle eingetragen, wobei id = 1 in unserem Fall die ID des Gutscheins für das Rezept ist. Funktioniert bisher ohne Probleme.
Der Kunde muss nur im Backend den jeweiligen Artikeln die Option hinzufügen, den Rest erledigt der Cronjob.