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 🙂

 

[Cassiopeia]

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.

Da muss man erstmal drauf kommen 🙂

 

[Rayblaster]

Aber die Kosten von 0 oder 0,00 zu löschen, oder die Versandart einfach nochmal zu speichern sollte helfen.

So ist es leider nicht!
Bei uns erscheinen ebenfalls die 0,00 bei den aktivierten Zahlarten. Wenn ich diese nun lösche und speichere, die Seite anschließend neu lade, sind die ganzen 0,00er wieder da.
Also das leere Feld zu erreichen ist so nicht machbar.

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...

Stimmt so auch nicht. Beim nächsten LogIn oder Cache löschen, sind die 0,00 wieder da.
Hier muss es sich doch um einen Bug handeln und eine Lösung muss her.
Kann ja nicht sein dass die Posten nun immer in den Aufträgen als Position erscheinen!

 

[OliverS]

So ist es leider nicht!
Bei uns erscheinen ebenfalls die 0,00 bei den aktivierten Zahlarten. Wenn ich diese nun lösche und speichere, die Seite anschließend neu lade, sind die ganzen 0,00er wieder da.
Also das leere Feld zu erreichen ist so nicht machbar.



Stimmt so auch nicht. Beim nächsten LogIn oder Cache löschen, sind die 0,00 wieder da.
Hier muss es sich doch um einen Bug handeln und eine Lösung muss her.
Kann ja nicht sein dass die Posten nun immer in den Aufträgen als Position erscheinen!

Das ist dann vermutlich ein lokales und anderes Problem bei dir. Mach am besten ein Ticket dazu auf.

 

[Rayblaster]

Das ist dann vermutlich ein lokales und anderes Problem bei dir. Mach am besten ein Ticket dazu auf.

Das ist sicher kein lokales Problem.
Sobald man eine Zahlungsart aktiviert und speichert, erscheint dahinter eine 0,00. Das ganze in Firefox und Chrome. Manchmal ist kurz das Feld leer aber spätestens nach dem nächsten LogIn sind die 0,00 wieder da.
Ich bin ja anscheinend nicht der einzige der das Problem hat und da das ganze nach dem 5.4 Update auftritt muss ja irgendwas geändert worden sein dass die Zahlarten als Position erscheinen.
Beim Update auf 5.3 vor drei Wochen war dies ja noch nicht der Fall.

 

[OliverS]

Das ist sicher kein lokales Problem.
Sobald man eine Zahlungsart aktiviert und speichert, erscheint dahinter eine 0,00. Das ganze in Firefox und Chrome. Manchmal ist kurz das Feld leer aber spätestens nach dem nächsten LogIn sind die 0,00 wieder da.
Ich bin ja anscheinend nicht der einzige der das Problem hat und da das ganze nach dem 5.4 Update auftritt muss ja irgendwas geändert worden sein dass die Zahlarten als Position erscheinen.
Beim Update auf 5.3 vor drei Wochen war dies ja noch nicht der Fall.

Du bist nicht der einzige, der das Problem hat, nein. Du bist hier im Thread aber soweit der einzige, bei dem das löschen und speichern scheinbar nicht klappt.

 

[Rayblaster]

Du bist nicht der einzige, der das Problem hat, nein. Du bist hier im Thread aber soweit der einzige, bei dem das löschen und speichern scheinbar nicht klappt.

Nur als Info falls es noch jemanden betrifft.
Erst mit 5.4 kann man die 0,00 komplett entfernen sodass das Feld leer bleibt.
Mit 5.3.3 ging es nicht!

 

[forumjtlolshopag]

Wir hatten das heute mal zufällig, weil eine Vorkassenrabatt Position mit 0 EUR im Auftrag in der JTL Wawi plötzlich aufgetaucht ist. 6 Aufpreis Einträge mit 0.00 waren in der Datenbank vorhanden. Haben wir über das Update SQL korrigiert.

 

[donc]

ist mit 5.7 immernoch nicht behoben, danke an diesen Thread, sodass wir nicht wieder Stunden mit einer Lösungssuche verbringen mussten.