Fehlerhafte Preisänderung bei Artikelvarianten.

[Joram]

Hallo,

ich habe folgendes Problem.

 

Artikel Fixpreis ink. : 5,70€

Variante 1 (Preis bleibt gleich)

Variante 2 (Preis Reduziert um 1,80 ink.) wäre: 3,90€ ink. 

Im Backend steht auch: Der endgültige Preis des Artikels ist 3.9 €

 

Jedoch im Frontend ist der Preis nicht 3.90 sondern 3.68 ink.

 

Warum?!?

Wieso ist der Preis im Frontend anders???

 

Bitte um Hilfe!!! Danke.

[rictools]

Zunächst: Immer Prestashop-Version angeben, möglichst auch PHP-Version. Ein Link zum Shop kann auch hilfreich sein.

 

Hast du alle Caches (Prestashop und Browser) gelöscht?

 

Ist das Problem auf den einen Artikel beschränkt? Was ist wenn du einen neuen Artikel mit den gleichen Preisen neu anlegst?

[Joram]

Hallo, sry. 

Prestashop Version 1.6.1.9

PHP Version: 5.6

Habe es auch mit einem neu angelegten Artikel versucht. 

Prestashop und Browser Cache habe ich gelöscht und auch mit verschiedenen Browsern versucht, immer das gleiche. 

[rictools]

Ist das bei anderen Preisen auch so (wie groß ist dann der Unterschied, immer um den gleichen Betrag oder Prozentsatz falsch?)? Ist das überall im Frontend so (also Übersichtsseite, Produktseite, Warenkorb ...)? MwSt. 19 %?

 

Vielleicht könnte noch ein Screenshot der Preiseinstellungen bei der Variante helfen.

[casher666]

Ich denke ich habe exakt das gleiche Problem.

 

PrestaShop-Version 1.6.1.10

Aktuelle verwendetes Template default-bootstrap

PHP-Version 5.6.19

 

Ich denke man sieht es besser, wenn ich einen Link zum Demo-Shop sende.

 

Erstaunlich: Die Preise in der linken Tabelle "Mengenrabatt" stimmen exakt - inkl. ausgewählter Varianten

 

Nur der Einzelpreis, der in der rechten Box steht, vergißt die Varianten, die einen Mehrpreis haben,

berücksichtigt also nur den Mengenrabatt.

 

Im Warenkorb sind alle Preise richtig!!! Auch bei Mengenänderung stimmen Mengenrabatt + Variantenpreise!

[Joram]

Hallo,

danke schonmal für die schnelle Hilfe!!!

 

Ich habe mich jetzt nochmals in Ruhe dazu gesetzt und bin darauf gekommen dass mein Shop bei einer Preiserhöhung der Varianten genau 12,5% bzw. 1/8 des Bruttopreises dazurechnet. Ich weiß nicht wo ich das umgestellt habe. (Habe testhalber einen neun Shop installiert und dort gleich getestet... dort funktioniert die Preiserhöhung ohne Probleme).

 

Im Backend steht der richtige Preis und die richtige Preisberechnung  z.b.: 100 + 2 € Preiserhöhung = 102,00€. 

Im Frontend steht dann allerdings: 102,25€

Egal ob ich die Steuer aktiviere oder nicht. Die 12,5% werden immer dazugerechnet..

 

Wo könnte diese Berechnung definiert sein??

[rictools]

Wo könnte diese Berechnung definiert sein??

Ich würde mal direkt in der Datenbank nach dem Wert suchen (denke daran, daß du den Wert mit Punkt, also 12.5 eingeben mußt).

Ich denke man sieht es besser, wenn ich einen Link zum Demo-Shop sende.

Den Link sehe ich nirgends.

[casher666]

 

Den Link sehe ich nirgends.

 

Hallo

Ich wollte den Link erst senden wenn sich jemand meldet, weil der Shop ja noch nicht offen ist.
Inzwischen habe ich 1.7 installiert, bin davon aber maßlos enttäuscht.

Bei 1.7 stimmen jetzt DIESE Anzeige, dafür wird die Tabelle "Mengenrabatt" nicht aktualisiert.


Wenn man den Artikel in den Warenkorb legt, nimmt dieser auch die richtigen Preise (Variante SM + Mengenrabatt).
Wird IM WARENKORB, die Anzahl geändert, stimmt der Preis, aber unter "testlack ral " wird er erst richtig angezeigt, wenn die Seite aktualisiert wird.

Und noch ein Hinweis für die Entwickler:
Man muss nicht immer alles noch komplizierter machen. Ich habe folgende Varianten:
126 Farben mit 6 Glanzgraden
Siehe http://www.billigspray.at/catalog/product_info.php?cPath=21&products_id=28

Und da soll ich jetzt bei den Varianten die Aufpreise einzeln eingeben? Ein Wahnsinn.
Dabei ginge es so einfach, wenn man bei den Varianten-Werten schon +/- Preise definieren könnte.

Besten Dank

Edited December 20, 2016 by casher666 (see edit history)

[rictools]

Hier wird allgemein davon abgeraten, die neue Version 1.7 schon zu verwenden.

 

Was die Varianten-Aufpreise angeht, in 1.6.x geht das, in 1.7 nicht mehr?

[casher666]

Ja ich glaube, dass ich wieder auf 1.6.10 wechseln werde ... bei 1.7 gefällt mir einiges nicht.

 

Varianten-Aufpreise geht auch bei 1.6 nicht (im Gegensatz zu oscommerce), aber man kann zumindest beim Varianten-Generator für eine Wertgruppe die Preisänderungen eingeben.

 

Ich melde mich wieder, wenn ich auf 1.6.10 gewechselt habe. Dort hat alles funktioniert, bis auf eine !!! Preisanzeige.

Den Shoplink schalte ich wieder aus.

 

Danke

[rictools]

Varianten-Aufpreise geht auch bei 1.6 nicht (im Gegensatz zu oscommerce), aber man kann zumindest beim Varianten-Generator für eine Wertgruppe die Preisänderungen eingeben.

Worin besteht denn da der Unterschied?

 

Davon abgesehen gibt es natürlich Module, die bei den Varianten mehr Möglichkeiten bieten.

[casher666]

1.6.10: Beim Varianten-Generator kann man für eine Wertgruppe die Preisänderungen eingeben (1 x beim Erzeugen)

 

1.7: Der Varianten-Generator erzeugt die Varianten und nachher (!) wählt man DIE Varianten aus, wo man die Preise ändern muss.

 

Bedeutet: Ich suche mir bei 126 Farbtönen die Wert-Gruppe SM aus und erhöhe den Preis ... dann 126 mal die Gruppe M usw. ... das ganze 5 x

 

Module: Nach tagelangem (!) Suchen habe ich evtl. 1 oder 2 gefunden die passen könnten ... nur wenn sie dann doch nicht die richtigen sind, habe ich umsonst bezahlt ... da liegt das Problem.

[michaa]

Hi Casher,

 

leider ist dein genannten Problem ein Prestashop-Fehler mit dem viele andere Shopbetreiber auch zu kämpfen haben.

 

"Mein" Entwickler konnte das Problem auf Basis dieser Anleitung aber beheben. Nun werden Varianten mit verschiedenen Preisstaffelungen auf der Produktseite korrekt angzeigt. 

 

https://www.prestashop.com/forums/topic/527373-mengenrabatt-preisanzeige-falsch/?do=findComment&comment=2337462

 

Grüße

[casher666]

Hi michaa

 

Danke fürs suchen, aber den Tipp kenn ich schon. Abgesehen das ich "saubere"  Lösungen bevorzuge, habe ich nicht nur unterschiedliche Wertpreise, sondern auch Werte die KEINE Preisänderung haben.

 

Da dürfte die Lösung nicht funzen (wie er selbst schreibt). Werde erstmal den 1.6 wieder aufsetzen und ....

[casher666]

Ein Hallo in die Runde
 
Shop wieder neu installiert
PrestaShop-Version 1.6.1.10
Aktuelle verwendetes Template default-bootstrap
PHP-Version 5.6.19
MySQL-Version 5.6.33
Speichergrenze 128M
 
Artikel eingestellt: http://www.keindreckshop.at/webshop/home/8-testlack-spray-ral.html
 
Varianten: (netto / brutto)
Farbton RAL ... keine Preisänderung
Glanzgrad:
Glänzend ... keine Preisänderung
Halbglänzend ... + € 1,00 / 1,20
Matt ... + € 2,00 / 2,40
 
Mengenrabatt (bezogen auf Variante):
3 stk ... - € 1,00 / 1,20
6 stk ... - € 2,00 / 2,40
 
Ergebnis:
Linke Tabelle Mengenrabatt stimmt IMMER - egal welche Auswahl
Warenkorb stimmt IMMER - egal welche Auswahl - auch bei Änderungen im Warenkorb !!!

 

Preisanzeige in der grauen Box:

Preis inkl. MwSt. zeigt den richtigen Mengenrabatt an, wenn eine Variante OHNE Aufpreis gewählt wird (glänzend).

Preis inkl. MwSt. zeigt NICHT den richtigen Mengenrabatt an, wenn eine Variante mit Aufpreis gewählt wird.

Preis € pro 100 ml stimmt zwar bei allen Varianten, ignoriert aber den Mengenrabatt.

[casher666]

Wie es ein Newbie ausdrücken würde:

 

Warum ersetzt man nicht die falsche Preisanzeige mit der richtigen Variablen aus dem Warenkorb?

Wie gesagt: Dieser Preis stimmt immer - auch nach Änderung der Anzahl.

[casher666]

Noch ein Hinweis: SQL "beschwert" sich:

Der Spaltenname 'from' ist ein reserviertes MySQL-Schlüsselwort.
Der Spaltenname 'to' ist ein reserviertes MySQL-Schlüsselwort.
ps_specific_price
ps_specific_price_rule

Der Spaltenname 'condition' ist ein reserviertes MySQL-Schlüsselwort.
ps_product
ps_product_shop

Keine Ahnung ob das wichtig ist.

[Joram]

Ich würde mal direkt in der Datenbank nach dem Wert suchen (denke daran, daß du den Wert mit Punkt, also 12.5 eingeben mußt).

 

Hallo, danke für die Antwort... nur wie such ich etwas in der Datenbank? :/ 

Hab phpmyAdmin für die DB... nur wie kann ich da nach diesem Wert suchen?

[rictools]

Hallo, danke für die Antwort... nur wie such ich etwas in der Datenbank? :/ 

Hab phpmyAdmin für die DB... nur wie kann ich da nach diesem Wert suchen?

Es gibt da doch auch eine Suchfunktion. Oder man kann die Spalten nach Werten sortieren.

[casher666]

sodale ... nach 6 Tagen suchen bin ich zu der Erkenntnis gekommen, dass dieses Problem SEIT JAHREN besteht und der letzte von mir gefundene Eintrag :

 

Posted 03 October 2016 - 06:33 AM

Quickly looking at the affected files (product,js and Product.php) and the bug is still there.

 

Im Prinzip heißt das nichts anderes als:

 

ES GEHT UNS VÖLLIG AM A VORBEI

[rictools]

Prestashop ist sicherlich nicht frei von Bugs, das ist sowieso keine Software auf der Welt, nur finde mal ein System, das im Preis-Leistungs-Verhältnis besser ist ...

[casher666]

 

frei von Bugs gibt es nicht ... richtig

hat auch niemand behauptet, aber die Anwender SEIT JAHREN darüber im unklaren zu lassen, dass bestimmte Funktionen nicht umsetzbar ist, ist schlichtweg eine Frechheit.

 

Beweis dafür sind hunderte Anfragen zum aktuellen Thema, hier und im engl. Forum, auf die einfach NICHT geantwortet wird. So nach dem Motto: Laß ihn mal suchen, dann wird er schon merken, dass es dazu hunderte Anfragen gibt ohne Antwort.

 

Wenn man wirklich so um Service bemüht ist wie es die Werbung verspricht, könnte man ja auch ein Topic installieren, indem man dazu Stellung nimmt. Aber das entspricht natürlich nicht der heutigen Vorstellung von Marketing. Was jetzt natürlich nicht speziell mit PS zu tun hat, sondern mit der heute üblichen Kunde-ist-König-Verar***ung.

 

Preis-Leistungs-Verhältnis: Darüber bin ich mir noch im Unklaren, weil ja noch auf der Suche. Zumindest hat mich das aktuelle Thema schon mal 1 Woche Arbeitszeit gekostet ... und damit meine ich jetzt nicht den "schlimmen Burn-Out-Arbeitstag" von 8 Stunden.

 

Sollte mit Preis-Leistungs-Verhältnis die kostenlose Software gemeint sein, dann lasse ich zumindest bei mir die allseits beliebte Aussage nicht gelten:

Gratis haben wollen und alles verlangen.

 

Nein bestimmt nicht, ich wäre gerne bereit, für Lösungen zu zahlen. Allerdings werden ja keine angeboten. Und ich gehöre sicherlich nicht zu jenen Anwendern, die sich darüber beschweren, dass ein Modul 70 € kostet (unglaublich, so etwas zu lesen).

[rictools]

Du befindest dich hier nicht in einem Servicebereich von Prestashop (Support gibt's von Prestashop sowie Agenturen gegen Geld), hier helfen sich lediglich Anwender untereinander.

 

Für professionelle Shopbetreiber ist es - selbst wenn sie bereits fünfstellige Summen für das eigentliche Shopsystem bezahlen - übrigens völlig normal, noch Programmierer zu beschäftigen, die den Shop an ihre Bedürfnisse anpassen.

 

Allerdings gibt es halt bei einem dermaßen komplexen System wie Prestashop - bei dem ja auch noch Serverbedingungen, zusätzliche Module, Browsereigenheiten etc. mitspielen - Bugs, die weder von den Prestashop-Entwicklern wie auch von externen Programmierern so einfach zu lösen sind. Es gibt aber auf jeden Fall Module, die bei Varianten mehr Möglichkeiten bieten, ich kann dir aber nicht sagen, ob deine Problematik da auch auftritt.

[casher666]

oh danke, das ist ja dann mal eine Ansage.

 

Soll also heißen, dass ich für einen Bug der Software den Support befragen soll? Und der kann mir dabei helfen?

Klingt für mich unlogisch.

[rictools]

Soll also heißen, dass ich für einen Bug der Software den Support befragen soll? Und der kann mir dabei helfen?

Jedenfalls kannst du nicht erwarten, daß die ganz normalen User, die hier im Forum sind, das in jedem Fall können und auch bereit sind, kosten- und nicht selten auch danklos eine Lösung zu suchen.

 

Generell dürfte die Chance, daß ein Problem geklärt wird, mit der Bereitschaft, dafür zu zahlen, steigen, das gilt sicher auch bei Prestashop. Gleiches gilt für unabhängige Programmierer (der Vorteil eines Open-Source-Systems ist ja, daß der Quellcode komplett offen ist und jeder der will und kann diesen optimieren kann und darf).

[casher666]

Sollte mit Preis-Leistungs-Verhältnis die kostenlose Software gemeint sein, dann lasse ich zumindest bei mir die allseits beliebte Aussage nicht gelten:

Gratis haben wollen und alles verlangen.

 

Nein bestimmt nicht, ich wäre gerne bereit, für Lösungen zu zahlen. Allerdings werden ja keine angeboten. Und ich gehöre sicherlich nicht zu jenen Anwendern, die sich darüber beschweren, dass ein Modul 70 € kostet (unglaublich, so etwas zu lesen).

habe ich genau deshalb geschrieben, allerdings ist mir nicht bewußt, dass sich hier keine Programmierer "rumtreiben", die das lesen könnten

[rictools]

allerdings ist mir nicht bewußt, dass sich hier keine Programmierer "rumtreiben", die das lesen könnten

Die aktiven kannst du im deutschen Bereich an einer Hand abzählen (ist zumindest mein Eindruck nach erst kurzer Aktivität hier).

[casher666]

ok das erklärt alles

 

vmtl. hat es auch keinen Sinn, das als Bug zu melden, weil es wahrscheinlich schon mehrmals gemeldet wurde

[eleazar]

Es hat vor allem keinen Sinn, Bugs im Forum zu melden. Dafür gibt es den Bugtracker.

[Joram]

Hallo,

ich habe in der Datenbank gesucht, jedoch nichts gefunden. Nichts mit 12.5 oder 12,5 oder so ähnlich. 

 

Jetzt ist mir aufgefallen dass die fälschliche Preisberechnung nur bei dem Artikelfenster selbst ist! Nicht in der List oder Grid View und auch nicht im Warenkorb. Nur beim Artikel selbst!!! 

 

Listview: http://shop.lieferservice-gleisdorf.at/56-schnitzel-klassiker

 

Artikel selbst: http://shop.lieferservice-gleisdorf.at/schnitzel-klassiker/11-schnitzel-schwein.html

 

(Hier sollte 3,70 nicht 3,48 stehen...)

 

Wie kann sowas sein?

[Shad86]

Mal kurz zu cascher666:

 

Mein Eindruck ist auf jeden Fall das hier im deutschen Bereich wenige Leute sind die gerne und viel helfen.

Das sind im englischen auf jeden Fall mehr Leute.

Aber es ist leider wirklich so das hier zwar Programmierer unterwegs sind aber auch die entweder ihr eigenes Shop Project laufen haben oder man ausdrücklich nach einem Programmierer verlangen muss der einem etwas bastelt. (Gegen Bezahlung dann natürlich)

Mit dem Bug Tracker habe ich sehr gute Erfahrung gemacht. Alles von mir bemängelte wurde promt beantwortet und ich habe das Gefühl das auch immernoch daran gearbeitet wird.

[eleazar]

Hallo,

ich habe in der Datenbank gesucht, jedoch nichts gefunden. Nichts mit 12.5 oder 12,5 oder so ähnlich. 

 

Jetzt ist mir aufgefallen dass die fälschliche Preisberechnung nur bei dem Artikelfenster selbst ist! Nicht in der List oder Grid View und auch nicht im Warenkorb. Nur beim Artikel selbst!!! 

 

Listview: http://shop.lieferservice-gleisdorf.at/56-schnitzel-klassiker

 

Artikel selbst: http://shop.lieferservice-gleisdorf.at/schnitzel-klassiker/11-schnitzel-schwein.html

 

(Hier sollte 3,70 nicht 3,48 stehen...)

 

Wie kann sowas sein?

 

Wieso in der Detailsicht ca. 6% vom Preis abgezogen werden, erschließt sich mir leider auch nicht, muss aber wohl an fehlerhaften Einstellungen liegen, da das eigentlich nicht vorkommen sollte.

Was mir allerdings auffällt, ist, dass du die rechtsichere Erweiterung in Form des Moduls Europäische Rechtssicherheit (Advancedeucompliance) nicht installiert hast.

Du kannst zwar in Österreich deswegen nicht wie in Deutschland von jedem darauf spezialisierten Anwaltsbüro kostenpflichtig abgemahhnt werden, aber strafbewehrt ist es schon. Mach dich lieber mal sachkundig, bevor du deinen Shop startest, denn er ist in vielerlei Hinsicht nicht rechtssicher: http://www.it-recht-kanzlei.de/oesterreich-verbraucherrechte-richtlinie-2011-83-eu.html

[rictools]

Jetzt ist mir aufgefallen dass die fälschliche Preisberechnung nur bei dem Artikelfenster selbst ist! Nicht in der List oder Grid View und auch nicht im Warenkorb. Nur beim Artikel selbst!!! 

In diesem Thread geht es mit verschiedenen Postern und Problemen so durcheinander, daß ich jedenfalls nicht mehr richtig durchblicke, so sind die Zahlen bei dem von dir verlinkten Artikel wieder anders als in vorherigen Beispielen.

 

Ist das mit den 3,70 / 3,48 EUR genauso wenn du einen neuen Artikel anlegst (nicht kopieren, sondern komplett neu!)?

 

Sind alle Preise mit Varianten fehlerhaft oder nur bestimmte, welche Gemeinsamkeiten gibt es (z. B. immer gleicher Prozentsatz oder Betrag als Unterschied zwischen falsch und richtig)?

 

Wie sieht die Seite im Backoffice aus, auf der die Preise eingestellt werden?

 

Was passiert, wenn du unter Erweiterte Einstellungen die Optionen unter Debug Modus auf Ja stellst und alle Caches leerst?

Edited January 3, 2017 by rictools (see edit history)

[Joram]

Hallo, 

danke für die Antworten. 

Ich habe soeben einen komplett neuen Artikel und auch neue Varianten angelegt. 

Anbei die Screenshots vom Backend und Frontend. 

der Link zum Artikel: http://shop.lieferservice-gleisdorf.at/schnitzel-klassiker/364-testartikelvarianten.html#/30-testvariante-gleichbleibend

 

Habe alle Caches geleert und auch deaktiviert. 

Hab auch testmäßig den Debug Modus bei beiden auf Ja gestellt. Keine Veränderung. :/

[rictools]

Sehr seltsam. So stimmt das "ab 100,00 €" auf der Kategorieseite auch nicht. Und warum heißt die TestVariante in deinen Back-Office-Screenshots so und im Front-Office auf einmal testvariatne?

 

Ändert sich etwas, wenn du den Testartikel in eine neue, ansonsten leere Kategorie verschiebst?

[Joram]

Hallo!

Das mit ab... war wegen dem Modul Eu Rechtssicherheit. Dort hatte ich das aktiviert. 

ich habe jetzt auch noch einen zweiten artikel angelegt mit dem preis von 1000... verhaltet sich ganz gelich. Spricht der unterschiedliche Wert ist nicht von der höhe des Preises abhängig. 

Ich habe auch alle Module durchgesehen. Ob ich vl. einen installiert hätte was nicht "verifiziert" ist und das vl. das problem verursachen könnte... alle was ich nachinstalliert habe ich testmäßig deaktiviert und dann immer wieder die seite neu geladen und getestet.. leider kein erfolg.

 

Mir ist jedoch aufgefallen dass nach dem cache löschen für einen ganz kurzen Moment der richtige Variantenpreis da steht. Beim laden der Artikelseite steht zuerst der richtige Preis und sobald die Seite fertig geladen hat (Foto... etc) steht der falsch berechnete wieder da. 

 

Im Nachhinein wenn ich nachdenke hatte ich anfangs Probleme mit den Sprachen. Die habe ich mehrmals installiert bzw. überspielt.  Kann das von dem kommen? 

 

Für die Fehlersuche..

Kann ich irgendwie einen aktuellen Status des Shops abspeichern und dann verschieden Punkte aktivieren/deaktivieren/deinstallieren und danach wieder zu dem vorherigen Stand zurückkehren?!

 

http://shop.lieferservice-gleisdorf.at/190-testkategorie

[rictools]

Na, es müßte aber nicht ab 100 € heißen, sondern ab 50 oder 43,81 € ...

 

Wie waren bei der 1000er-Variante deine Auf- bzw. Abschläge? Auch 50? Wie sind die Beträge bei 60? oder bei 500?

 

Hast du das aus meinem letzten Post probiert: Ändert sich etwas, wenn du den Testartikel in eine neue, ansonsten leere Kategorie verschiebst?

 

Hast du bewußt Änderungen an tpl-, php- und js-Dateien vorgenommen? Wenn (und wo) nicht oder auch probeweise, könntest du per FTP nachschauen, welche neueren Datums sind und diese durch Originaldateien ersetzen.

[Joram]

Hallo,

habe den Artikel in eine neu erstelle "testkategorie" verknüpft. Leider keine Änderung. 

Habe auch einen neuen Testshop erstellt. Dort funktionieren diese Varianten natürlich. 

Habe jetzt versucht die Ordner von aktiven Shop mit denen vom Testshop zu überschreiben. Versuchte es mit den Ordnern: Theme, config, controllers, css, js, modules und override. Es hat auch keine Veränderungen bewirkt.  Ich vermute fast dass es irgendwo in der DB sein muss?? Wie könnte ich das rausfinden? 

[Joram]

Hallo. 

Danke für alle Antworten!!

Ich habe gestern in einen alten Post die Lösung gefunden! 

https://www.prestashop.com/forums/topic/514178-falsche-preisberechnung-bei-varianten/?hl=%2Bvarianten

 

Das Problem lag interessanterweise in der Productcontroller.php 

Die Datei habe ich zwar nie verändert, aber egal, es funktioniet nun wieder!!!