Hallo und guten Morgen! Gestern fiel uns zum wiederholten - und inzwischen gehäuften - Male auf, dass das Shopsystem ein schlimmes Eigenleben zu entwickeln scheint. Problem 1: Vorkasse-Bestellungen werden neuerdings - automatisch - mit dem Zahlungsstatus “Komplett bezahlt” versehen - und zwar direkt mit der Bestellung. Hierbei ist anzumerken, dass die Bestellungen seit einiger Zeit _immer_ “komplett bezahlt” sind. Ganz gleich welche Versand- und Zahlungsart genutzt wird. Das war nicht immer so. Nur wurde mir jetzt mitgeteilt, dass dies seit einigen Wochen beobachtet wird. Problem 2: Bestellnummern werden doppelt oder gar mehrfach belegt. Wir erhalten Rückmeldungen von Käufern, die Ihre Bestellbestätigungsmail anhängen, in der ein Bestelldatum von vor wenigen Tagen steht und eine Bestellnummer, die schon vor vielen Monaten vergeben wurde. Diese Konstellation ist im Grunde gar nicht möglich. Dabei handelt es sich um Vorkasse- oder PayPal-Bestellungen. Also kein Einzelfall. Wievielen Kunden das passiert können wir nicht sagen, da jene “toten” Bestellungen weder in der Bestellübersicht noch in der Abbruchanalyse auftauchen und sich nicht jeder Kunde zurückmeldet. Dass die Bestellungen aber real rausgegangen sind ist sicher. Denn die PayPal-Bestellungen wurden auch bezahlt. Nur tauchen sie eben nirgends bei uns auf - wegen der neuerlich doppelt vergebenen Bestellnummer. Dieser Effekt wird ebenfalls seit einigen Wochen beobachtet. Das heißt, seit einigen Wochen kommen sporadisch E-Mails mit entsprechenden Kundenrückfragen rein. Allerdings gibt es zwischendurch eine Menge normal funktionierender Bestellungen (hinsichtlich Bestellnummernvergabe). Was geschieht hier? Kennt jemand dieses Problem? Was können wir tun? Das ist äußerst dringend! Wir sind für Tipps sehr dankbar! Software: Seit Erscheinen wird Shopware 4.3.2 eingesetzt. P.S. Dass der Server zeitweilig überlastet war, dürfte als unwahrscheinlich gelten. Da steckt ein XEON-System darunter.
*push*
Muss leider noch einmal „pushen“. Hat niemand eine Idee? :shock:
Hi, leider so spontan keine direkte Idee. Das ist so auch kein bekanntes Phänomen. Welche Plugins hast du dort installiert? Besonders interessant wären die Zahlungsplugins. Wird bei Paypal die Bestellnummer übermittelt (Plugin Konfiguration)? Das kannst du ggf. mal deaktivieren und das Verhalten weiter beobachten. Dann gibt es z.B. weitere Zahlungsplugins, die Bestellnummer reservieren! Wird dann eine Bestellung nicht durchgeführt, so wird die Bestellnummer ggf. zurückgesetzt / freigegeben und dann kann es auch zu Sprüngen oder Doppelbelegungen kommen. Zusätzlich empfehle ich in der Datenbank einmal das Foreign-Key-Reparatur Script auszuführen. Läuft das dann durch oder kommt ggf. eine Fehler? Auch das kann dann auf defekte Beziehungen hindeuten bzw. diese Bestätigen. Gibt es sonst weitere Schnittstellen, die evtl. Änderungen an Bestellungen durchführen können oder gar Informationen zurück in den Shop schreiben? Sebastian
Hallo Sebastian, [quote=“Sebastian Klöpper”]Welche Plugins hast du dort installiert? Besonders interessant wären die Zahlungsplugins.[/quote] installierte Plugins: - Business Essentials - Produktbundle - Multishop - PayPal - plentymarkets - sofortüberweisung (inaktiv) Das einzige aktive Zahlungsplugin war also jenes von PayPal. {quote]Wird bei Paypal die Bestellnummer übermittelt (Plugin Konfiguration)?[/quote] Nein. [quote]Dann gibt es z.B. weitere Zahlungsplugins, die Bestellnummer reservieren! Wird dann eine Bestellung nicht durchgeführt, so wird die Bestellnummer ggf. zurückgesetzt / freigegeben und dann kann es auch zu Sprüngen oder Doppelbelegungen kommen.[/quote] Wie gesagt - keine anderen Zahlungsplugins. [quote]Zusätzlich empfehle ich in der Datenbank einmal das Foreign-Key-Reparatur Script auszuführen. Läuft das dann durch oder kommt ggf. eine Fehler? Auch das kann dann auf defekte Beziehungen hindeuten bzw. diese Bestätigen.[/quote] Erm… okay… was, wie und wo? 
Ich bin kein Programmierer, kann die Datenbank mittels PhpMyAdmin zwar halbwegs “bedienen” aber viel weiter reicht es nicht. [quote]Gibt es sonst weitere Schnittstellen, die evtl. Änderungen an Bestellungen durchführen können oder gar Informationen zurück in den Shop schreiben?[/quote] Nicht, dass ich wüsste. Das einzige Plugin über das ich aktuell nicht genug zu wissen scheine ist das plentymarkets-Plugin. Allerdings sollte das keinen Bestellstatus ändern…
Hi, Foreign Keys haben wir hier einige Infos: http://wiki.shopware.com/Foreign-Keys-r … l_954.html Wenn Sofortüberweisung aktuell nicht genutzt wird bzw. auch inaktiv ist, so empfehle ich das einmal wirklich auch zu deinstallieren. Inaktiv bedeutet ja, dass es noch im System verankert ist, aber die jeweiligen Punkte nur nicht ausgeführt werden. Dann bitte mal den kompletten Cache leeren und das Foreign-Key Script durchlaufen lassen in der Datenbank. Das würde ich jetzt im ersten Schritt machen Sebastian
Obgleich wir keinerlei “technische” Fehlermeldungen erhalten haben, werde ich die Geschichte mit dem Foreign Key einmal ausprobieren. Das mache ich aber morgen früh zeitig, dann melde ich mich zurück.
Hallo Sebastian, nun meine vorläufige Rückmeldung. Sofortüberweisung ist geklärt. Das Foreign-Key-Script habe ich verwendet. Dabei wurden in der Datenbank 246 Abfragen erfolgreich ausgeführt. Ob das nun etwas nützt weiß ich noch nicht. Das werden wir jetzt einen Tag lang beobachten. Allerdings möchte ich etwas anmerken. Im verlinkten WIKI-Artikel steht u.a. folgender Text: [quote]5. Löschen Sie den Inhalt der Ordner /engine/Shopware/Models/Attribute/ und engine/Shopware/Proxies bzw. ab Shopware 4.1 die Ordner /cache/doctrine/proxies und /cache/doctrine/attributes 6. Überprüfen Sie die Dateirechte der Ordner. Diese brauchen vollen Lese- und Schreibzugriff[/quote] Diese beiden Punkte sind nicht durchführbar weil jene Ordner gar nicht existieren. Ich kann mich irren aber ich glaube, dass mit einer der letzten Versionen die Ordnerstruktur etwas verändert wurde.
Meines Erachtens ist die Problematik der Vergabe doppelter (Bestell-) Nummern dem Shopware Code geschuldet. Weder haben die entsprechenden Tabellenfelder einen Unique Index noch wird bei der Generierung neuer Nummern mit transactions gearbeitet (\Shopware_Controllers_Backend_CanceledOrder::convertOrderAction). Das führt, auch im ganz normalen Betrieb von Shopware, mit einer Wahrscheinlichkeit > 0 dazu, dass es zur Vergabe doppelter Nummern kommt. Eigentlich ein komplettes Unding, insbesondere auch hinsichtlich der Genierung von Rechnungsnummern, die ja schon vom Gesetz her eindeutig sein müssen.
Hi,
für die relevante Logik im Frontend haben wir in der 5.2. explizit einen neuen Service geschaffen (shopware/NumberRangeIncrementer.php at 5.2 · shopware/shopware · GitHub), meines Wissens wurde da aber auch schon zuvor mit Locks in der DB gearbeitet (select for update). Die Stelle im CanceledOrder-Modul müsste tatsächlich noch angepasst werden, betrifft aber das Konvertieren von abgebrochenen Bestellungen - wird mMn in vielen Fällen also nicht die Ursache sein (weil selten genutzt).
Den Unique Key Constraint passt nicht zum Datenmodell, da abgebrochene Bestellungen die Bestellnummer “0” haben. Das wollten wir schon ändern - ist aber auch direkt wieder ein Bruch und damit nicht ganz trivial. Durch die Einführung des neuen Services wollen wir daher erstmal einen “kanonischen” Weg forcieren.
Kurzum: Transaktionen kommen, Unique Key Constraint können wir nicht “einfach so” setzen - wäre aber mit dem neuen WK eine Option.
Gruß,
Daniel
Hallo Daniel,
danke schon einmal für die Antwort & das mit NumberRangeIncrementer sieht ja gut aus
Kurzum: Transaktionen kommen, Unique Key Constraint können wir nicht „einfach so“ setzen - wäre aber mit dem neuen WK eine Option.
WK = Warenkorb?
Gruß
Marco
Hallo Daniel,
danke schon einmal für die Antwort & das mit NumberRangeIncrementer sieht ja gut aus
Kurzum: Transaktionen kommen, Unique Key Constraint können wir nicht „einfach so“ setzen - wäre aber mit dem neuen WK eine Option.
WK = Warenkorb?
Gruß
Marco
Ja, WK ist Warenkorb ;)
Gruß,
Simon