Neu Shop 5.4.0: Zahlungsarten nun als Position in der Wawi?

[sjk]

Moin,

Der Shop 5.4.0 übergibt die Zahlungsart als Position im Auftrag (Typ 'Zahlungsart'). Mir erschließt sich nicht ganz weshalb. Zahlungsarten haben meiner Meinung nach nichts in der Positionsliste zu suchen. Klar, ggf. sollte dort ein Vorkasserabatt stehen, aber doch nicht die Zahlungsart?
Wir nutzen z. B. nie Vorkasserabatte, trotzdem setzt der Shop als Standard-Gebührennamen bei der Zahlungsart Vorkasse 'Vorkasserabatt'. Das ganze wurde nun also so als zusätzliche Zeile auf der Rechnung ausgegeben: Vorkasserabatt 0 €. Da freuen sich unsere Kunden aber.

Davon abgesehen wird der Name der Zahlungsart sowieso schon immer in der Payments-Tabelle auf der Rechnung ausgegeben. Dort ergibt es auch Sinn. Wie gesagt, Gebühren, die den Rechnungsbetrag verändern, sinnvollerweise in die Positionsliste, den Namen der Zahlungsart in der Payments-Tabelle.

Ist das ein Bug oder soll es ein Feature sein?

 

[OliverS]

Das macht der Shop eigentlich nicht. Überweisung/Vorkasse taucht bei mir nicht als Position in der Wawi auf. Vorkassenrabatt auch nicht. Ist vielleicht für irgendeine Versandart ein Vorkassenrabatt von 0 gesetzt? Normalerweise sollte das Feld ja komplett leer sein, wenn kein Rabatt oder Aufschlag gesetzt werden soll.

 

[sjk]

Hallo Oliver, das wars. Bei allen Versandarten war in allen für diese Versandart jeweils aktivierten Zahlungsarten eine Gebühr von 0.00 eingetragen.
Bei uns in der Wawi tauchten die Positionen in allen Aufträgen auf, die nach dem Update auf die 5.4.0 eingegangen sind. Vermutlich gibt es also einen Bug in der Updateroutine.

 

[wo0dle]

Hallo Oliver, das wars. Bei allen Versandarten war in allen für diese Versandart jeweils aktivierten Zahlungsarten eine Gebühr von 0.00 eingetragen.
Bei uns in der Wawi tauchten die Positionen in allen Aufträgen auf, die nach dem Update auf die 5.4.0 eingegangen sind. Vermutlich gibt es also einen Bug in der Updateroutine.

Kann ich bestätigen, nach dem Update auf 5.4.0 haben wir in allen Shops bei uns eine neue Position auf den Aufträgen (Zahlungsrabatt 0,00)
Lösung war alle Versandarten im Shop Backend öffnen und die 0,00 aus den jeweiligen Zahlungsarten/Rabatten zu löschen (freies Feld) und speichern

Vorher dem Update hatten wir keine Extra Positionen in Aufträgen.

 

[OliverS]

Das ist merkwürdig. Ich frage mich, ob eine SQL-Servereinstellung dafür verantwortlich ist, bei Updates in meinen Testshops passiert das nicht. Oder ggf. ein Plugin, dass beim Update noch aktiv ist. Für fAufpreis ist der Standard-Wert NULL. Warum da beim Update 0,00 reingeschrieben werden sollte, ist mir schleierhaft.

 

[sjk]

Wir sind im JTL Hosting, die Servereinstellungen sollten also passen. Kann dir gern mal eine Liste unserer Plugins per DM rausschreiben, falls Ihr euch das anschauen wollt.

 

[OliverS]

Wir sind im JTL Hosting, die Servereinstellungen sollten also passen. Kann dir gern mal eine Liste unserer Plugins per DM rausschreiben, falls Ihr euch das anschauen wollt.

Werd ich im Nachhinein vermutlich nicht mehr nachvollziehen können. Mich wundert das auch generell, denn selbst wenn ich absichtlich 0 oder 0.00 in den Aufschlag eintrage, übernimmt der Shop das nicht und das Feld ist nach dem Speichern wieder leer. Kurios...

 

[Javi]

Haben wir auch genau denselben Fehler gehabt.

Nachdem Update auf 5.4.0 war auf einmal 0,00 drin.

Unser Shop wird auch im JTL Hosting betrieben.

 

[wo0dle]

Das ist merkwürdig. Ich frage mich, ob eine SQL-Servereinstellung dafür verantwortlich ist, bei Updates in meinen Testshops passiert das nicht. Oder ggf. ein Plugin, dass beim Update noch aktiv ist. Für fAufpreis ist der Standard-Wert NULL. Warum da beim Update 0,00 reingeschrieben werden sollte, ist mir schleierhaft.

Denke ein Zusammenhand mit dem PayPal Checkout Plugin könnte vorhanden sein, weil bei unseren neuen Zahlungsarten (Google Pay, Apple Pay) die wir in den letzten Monaten eingerichtet haben, dort 0,00 stand.

Mysql Version: 10.5.26.MariaDB-ubu2004- log

 

[Dessator]

Auch bei mir erscheinen seit dem Update auf 5.4.0 die Zahlungsarten mit 0,00 als Artikel…

 

[OliverS]

Woher das kommt, hab ich nicht herausgefunden. Möglich das es Altlasten von PayPal Checkout oder anderweitigen Updates sind. Aber die Kosten von 0 oder 0,00 zu löschen, oder die Versandart einfach nochmal zu speichern sollte helfen. Wenns sehr viele Versandarten sind, dann geht das auch über diese SQL-Anweisung (per phpMyAdmin z. B.. Backup nicht vergessen!):

UPDATE tversandartzahlungsart SET fAufpreis=NULL WHERE fAufpreis = 0 OR fAufpreis = 0.00;

Das leert alle Zuschlags-/Rabattfelder in denen 0 bzw. 0,00 steht. Wenn das über die SQL-Anweisung gemacht wird, ist es auch möglich, dass danach noch der Objekt- Cache geleert werden muss.

 

[dapole]

Gottseidank

Genau diesen Thread hab ich gesucht Hat schonmal geklappt. HAb unseren B2B Shop am Wochenende geupdatet, und gleich 2 Katastrophen gehabt.

Einmal das hier erwähnte und zweitens:
Shop - Subscription anbgelaufen und es konnte Abgleich mehr durchgeführt werden. Beim durchführen garnicht gemerkt. Gemerkt hat es der Innendienst,

Und dann war es Tricky: Wir haben 2 Shops und sind JTL Pro ....

Hintergrund: Wir hatten dort noch 'Lizenz-leichen', die wir nicht löschen konnten ... Es kam sehr prompt eine Antwort vom Support:

Um die nicht-gewünschte Shop-Lizenz zu löschen, können Sie bei Ihren Lizenzen im Kundencenter über Aktion "zum Abonnement umwandeln" auswählen, danach die Seite neu laden und dann über Aktion "Löschen/Kündigen" die Kündigung anstoßen.

-> Das hat auch prima funktioniert