Shopware 5.1.5
Zahlungsarten -> Rechnung ist nicht aktiv (entsprechend kann ich bei Risk-Management keine Regel dafür anlegen, was ja auch okay ist)
Grundeinstellungen -> Anmeldung/Registrierung ist überprüft, dort ist bei Standard und Fallback die ID von Vorkasse drin
ABER:
Bei registrierten Kunden wir im Bestellvorgang Rechnung als Standard ausgegeben
Im Profil ist bei den Zahlungsarten Rechnung nicht nur verfügbar sondern vorausgewählt
Hattest du mal Rechnung aktiv? und betrifft es nur Altkunden oder auch solche die sich neu registireren.
Du müsstest jetzt in der Datenbank Tabelle “s_user” Spalte “paymentID” schauen und diese Zahlweise mit einer ID ersetzten mit der alle im Standard bezahlen könnten.
Ich könnte dir ein Sql-Befehl erstellen mit dem du ds vornehmen kannst.
Dazu brauche ich die ID von der Rechnung und die ID der neuen Standard-Zahlart.
Uwe
Danke für deine Hilfe.
Das Problem betrifft tatsächlich nur Altkunden. Da hat wohl irgendwann mal jemand an den Zahlungsarten und Standards gefummelt und es einige Zeit später wieder Rückgängig gemacht.
Ich hab ein SQL update auf alle Datensätze mit der Rechnungs-paymentID losgelassen, und siehe da: Alles prima 
Ich muss das Thema leider wieder aufwärmen:
Offensichtlich wird nach der 2. Bestellung die Zahlungsart automatisch auf Rechnung gesetzt
Es existiert KEINE Riskmanagement Regel (zumindest keine, die ich im Backend sehen würde)
Rechnung ist im Kundenkonto weiterhin auswählbar, auch wenn ich in der DB die paymentID direkt umstelle
Bin völlig ratlos…
Bin völlig ratlos…
Das glaube ich dir, denn du warst ja der Ansicht du hattest den Fehler behoben.
Wie soll man dir da noch helfen, ich kann dir nur Anbieten selbst mal einen Blick drauf zu werfen vieleicht fällt mir was auf.
Hattest du mal nach der Änderung in der Datenbank den Cache-Ordner umbenannt um auf Nummer sicher zu gehen, das der Cache nicht dazwischen funkt. > /var/cache/production_12345
Gruss Uwe
Prüfe auch mal bitte das PaymentPreset in der s_user - sobald da Rechnung als ID drinsteht, kann der User damit immer bestellen.
Okay, ich hab’ mich über den Controller ins Model und weiter bis zum SQL gewühlt, das sPaymentMeans für die View in der der Kunde seine Zahlungsweisen festlegt.
Und bin wieder in der Datenbank bei s_user gelandet. Und dem Feld paymentpreset, das genau wie paymentID fähig ist, die Deaktivierung aus s_core_paymentmeans auszuhebeln. In 2 Stunden mehr über Shopware gelernt, als ich eigentlich wissen wollte 
Falls sich herausstellen sollte, dass tatsächlich für manche Kunden Rechnung wieder aktiviert wird sehen wir weiter.
Vielen Dank, nochmal, dass du mir den richtigen Startpunkt für die Reise ins Labyrinth gezeigt hast!
Prüfe auch mal bitte das PaymentPreset in der s_user - sobald da Rechnung als ID drinsteht, kann der User damit immer bestellen.
Da bin ich, auf die harte Tour, vor ein paar Minuten gelandet 
Und da war auch das Problem.
Prüfe auch mal bitte das PaymentPreset in der s_user - sobald da Rechnung als ID drinsteht, kann der User damit immer bestellen.
Da bin ich, auf die harte Tour, vor ein paar Minuten gelandet
Und da war auch das Problem.
Häää 
Du müsstest jetzt in der Datenbank Tabelle „s_user“ Spalte „paymentID“ schauen und diese Zahlweise mit einer ID ersetzten mit der alle im Standard bezahlen könnten.
Ich denke das hattest du schon mal gemacht??
Das Problem betrifft tatsächlich nur Altkunden. Da hat wohl irgendwann mal jemand an den Zahlungsarten und Standards gefummelt und es einige Zeit später wieder Rückgängig gemacht.
Ich hab ein SQL update auf alle Datensätze mit der Rechnungs-paymentID losgelassen, und siehe da: Alles prima
Dann fasse ich mal kurz die Erkenntnisse aus diesem Thread zusammen:
In der Tabelle s_user gibt es zwei Schlüssel, die dem Kunden eine Zahlungsart zuordnen:
paymentID steuert die Vorauswahl im checkout in der confirm action
paymentpreset steuert die Vorauswahl im account und sorgt dafür, dass die Zahlungsart, deren ID darinsteht in der payment action immer zur Verfügung steht, also ausgewählt werden kann.
In beiden Fällen ist das unabhängig davon, ob die Zahlungsart in der Tabelle s_core_paymentmeans aktiv ist oder nicht.
Bleibt nur noch die Frage, wie eine zu diesem Zeitpunkt inaktive Zahlungsart einem Kunden zugeordnet werden konnte. Und zwar nach der 2. erfolgten Bestellung.
Das ist zumindest das, was der Betreiber des Shops sagt. Ich werde wohl noch weiter forschen müssen
Nachtrag:
Das ist zumindest das, was der Betreiber des Shops sagt.
Nachdem ich das eine zzeitlang beobachtet habe: Es passiert NICHT. Ich kann das Problem als gelöst betrachten 
Ich muss das Thema wieder aufwärmen:
Tatsächlich sind wieder User aufgetaucht, die Rechnung als paymentID und paymentpreset haben.
Das sind definitiv keine Altlasten, das Registrierungsdatum liegt teilweise nach dem Zeitpunkt, zu dem ich das Problem (scheinbar) gefixt hatte. Es hat auch definitiv keiner an der Konfiguration des Shops gefummelt.
Also: Ich bin immer noch auf der Suche nach dem Mechanismus, der Benutzern die Zahlungsart Rechnung freischaltet obwohl das laut Konfiguration nicht möglich sein sollte.
Ich wäre für jeden Hinweis dankbar.
Hallo Uwe,
benutzt du eine Warenwirtschaft für den Abgleich? Und wenn ja welche? Ggf hätte ich eine Vermutung…
VG Alex
Ja, und zwar vario.
Wir benutzen auch vario und bei uns tritt das Problem auch auf…es liegt an einer Einstellung, die in vario geändert werden muss…wenn ich gleich am Rechner bin kann ich dir weitere Infos zukommen lassen - oder kontaktiere den vario Support…
vg
alex
Hallo DROPIN,
wir haben dieses Problem ebenfalls in Verbindung mit Vario. Wäre super, wenn du hier noch kurz erklären könntest, welche Einstellung bei Vario erforderlich ist.
Gruß Tim
Servus!
Habe auch einen Kunden, der dieses Problem hat. Wäre nett, wenn DROPIN uns kurz verraten würde, welche Einstellung man vornehmen muss
VG
David
Ich habe gerade mit der Vario-Hotline telefoniert. Das Problem war dem Mitarbeiter bereits bekannt und liegt wohl an den nicht zugeordneten Zahlungsarten in der Filialverwaltung von Vario. Nach Anleitung habe ich dort nun in den Stammdaten unter “Filialen verwalten” im Reiter “Zahlungsarten” die Verknüpfungen hergestellt. Zuerst wählt man die Zahlungsbedingung aus, die in Vario hinterlegt ist (also bspw. VK für Vorkasse) und gibt dann bei “Webshop-Kennung” die ID der Zahlungsart bei Shopware an. Letztere findet man im Shopware-Backend unter “Einstellungen” -> “Zahlungsarten” in Klammern hinter der Zahlungsart (bspw. “Vorkasse (5)”).
Wir werden sehen, ob die Problematik damit jetzt endlich gelöst ist.
UPDATE : Auch nach Tag vier ist das Problem nun nicht mehr aufgetreten!
Kurios, wir haben das gleiche Phänomen, aber keine Warenwirtschaf und als Zahlungsanbieter nur PayPal und Sofort. Ich habe Mal bei der Zahlungsart Rechnung das Häkchen bei Shops und Länder raus genommen. Muss allerdings noch abwarten, ob das Problem damit gelöst ist.
Gruß
Ich habe gerade mit der Vario-Hotline telefoniert. Das Problem war dem Mitarbeiter bereits bekannt und liegt wohl an den nicht zugeordneten Zahlungsarten in der Filialverwaltung von Vario. Nach Anleitung habe ich dort nun in den Stammdaten unter „Filialen verwalten“ im Reiter „Zahlungsarten“ die Verknüpfungen hergestellt. Zuerst wählt man die Zahlungsbedingung aus, die in Vario hinterlegt ist (also bspw. VK für Vorkasse) und gibt dann bei „Webshop-Kennung“ die ID der Zahlungsart bei Shopware an. Letztere findet man im Shopware-Backend unter „Einstellungen“ -> „Zahlungsarten“ in Klammern hinter der Zahlungsart (bspw. „Vorkasse (5)“).
Wir werden sehen, ob die Problematik damit jetzt endlich gelöst ist.
UPDATE : Auch nach Tag vier ist das Problem nun nicht mehr aufgetreten!
Genauso haben wir das auch gemacht! Es bringt aber keine Änderung… Es gibt immer wieder Kunden mit Zahlart Rechnung. Ich dreh noch durch!