Jump to content
  • 0
Jörg Saxtec

Brutto und Netto Anzeige PrestaShop 1.7

Question

Hallo,

Unter PrestaShop 1.7.2 ist mir aufgefallen, dass im Checkout sowie in der Bestätigungsmail zum Kunde Brutto und netto Anzeigen durcheinander gewürfelt sind.

So wird noch vor dem Checkout alles korrekt in Brutto Preisen angezeigt, In der Bestellbestätigung werden in der Produkttabelle nur Netto Preise angezeigt und in der Bestätigungsmail wird in der Produkttabelle der Einzelpreis netto angezeigt, und der Gesamtpreis (Einzelpreis * Anzahl) wieder Brutto, also mit Mehrwertsteuer.

Kann man das vereinheitlichen, dass IMMER Brutto Preise angezeigt werden? Die entsprechenden Smarty Variablen habe ich schon mit "print_r" validiert, die korrekten Preise sind jedoch nicht erhältlich.

 

Hat von jemand von euch auch das Problem? Wie habt Ihr das gelöst?

 

LG Jörg   

Bildschirmfoto 2018-01-04 um 18.27.01.png

Bildschirmfoto 2018-01-04 um 18.27.11.png

Bildschirmfoto 2018-01-04 um 18.34.21.png

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

Das Array für die Mail (order_conf) beinhaltet folgende Daten (Ein Produkt in der Tabelle) 

Array ( 
	[id_product] => 3 
	[reference] => 12345678 
	[name] => TEST Produkt 
	[price] => 758,00 CHF 
	[quantity] => 2 
	[customization] => Array ( ) 
	[unit_price] => 351,90 CHF 
	[unit_price_full] => 351,90 CHF 
)

Im Beispiel habe ich 2 Produkte für je 379,00 CHF, gesamt 758,00 CHF. Das ist auch korrekt in Brutto ausgezeichnet. Ein Einzelpreis in Brutto fehlt. Was habe ich übersehen? 

Share this post


Link to post
Share on other sites
  • 0

Die Variable {products} in der order_conf.html wird über die Klasse PaymentModule.php versorgt, ab Zeile 482. Da müsstest du dich dann mal durchwühlen.

Kleiner Tipp:

$price, $unit_price = Nettopreis

$price_wt, $unit_price_wt = Bruttopreis

$unit_price_full = Nettopreis mit Angabe der Einheit

Dummerweise lassen sich Klassen ab PrestaShop 1.7 nicht mehr per Override überschreiben. Man muss also den Quelltext selbst ändern, und das ist dann beim nächsten Update u. U. wieder weg.

Share this post


Link to post
Share on other sites
  • 0

Habe auch schon etwas "gewühlt". Es werden die Variablen "unit_price" und "unit_price_full" dafür verwendet. 

Die finde ich in der PaymentModule.php ab Zeile 501.  Die Änderung funktioniert zumindest in der Bestätigungsmail (order_conf), im Frontend (noch) nicht.

 In Zeile 490 wird $product_price definiert und die Mehrwertsteuer entsprechend eingerechnet. Weiter unten wird jedoch (fälschlicherweise?) mit der Netto Variablen $product['price'] anstatt $product_price gerechnet. Ich habe das geändert und es funktioniert - bis zum nächsten Update.

Möglicherweise könnte man daraus ein Override machen.

if (isset($product['price']) && $product['price']) {
	// $product_var_tpl['unit_price'] = Tools::displayPrice($product['price'], $this->context->currency, false);
	$product_var_tpl['unit_price'] = Tools::displayPrice($product_price, $this->context->currency, false);
	// $product_var_tpl['unit_price_full'] = Tools::displayPrice($product['price'], $this->context->currency, false)
	//     .' '.$product['unity'];
	$product_var_tpl['unit_price_full'] = Tools::displayPrice($product_price, $this->context->currency, false)
	.' '.$product['unity'];
} else {
	$product_var_tpl['unit_price'] = $product_var_tpl['unit_price_full'] = '';
}

 

Share this post


Link to post
Share on other sites
  • 0

Das habe ich wiederum übersehen. :D Für die Darstellung im Frontend bist du an dieser Stelle falsch. Hier geht es nur um die Mail.

Aber wie ich schon sagte: Overrides von Klassen funktionieren nicht in 1.7.

 

Share this post


Link to post
Share on other sites
  • 0

Auch wenn ich Dich und Deine Fachkenntnis sehr schätze: Overrides funktionieren recht gut mit Klassen in PrestaShop 1.7.

Habe in einem Shop die Bestellnummern so überschrieben, da der Kunde die Buchstabenkombination nicht wünschte :D 

<?php 

class Order extends OrderCore
{
	public static function generateReference()
	{
	    $last_id = Db::getInstance()->getValue('
	        SELECT MAX(id_order)
	        FROM '._DB_PREFIX_.'orders');

	    $order_id = str_pad((int)$last_id + 1, 6, '000000', STR_PAD_LEFT);
	    return "LT-".$order_id;
	}
}

 

Share this post


Link to post
Share on other sites
  • 0

Ja, du hast recht. Es geht tatsächlich, ich habe es gerade ausprobiert. Abe die Frage ist wirklich, wie lange noch, denn der Hinweis von Xavier hier ist ernst zu nehmen: http://build.prestashop.com/news/prestashop-1-7-faq/#is-there-any-change-planned-to-the-override-system

Die Override-Möglichkeiten im Core werden zurückgefahren. Das ist Firmenpolitik.

Share this post


Link to post
Share on other sites
  • 0

Ich denke, man muss das von zwei Seiten sehen. Natürlich ist die "override" Geschichte sehr angenehm und im Gegensatz zu manch anderem Shopsystem auf dem Markt schon ein Grund, auf PrestaShop zu setzen. 

Die andere Seite ist jedoch: Wenn ich ein Modul erzeuge, und für die korrekte Funktion Overrides benötige, kann ich für den Händler automatisiert die Files in den Override Ordner kopieren. Wurde und wird von einigen Modulherstellern auch intensiv genutzt. Wenn ich nun aber ein zweites Modul installiere, welche die gleiche Klasse überschreiben möchte, dann knallt es an der Stelle. Der Händler sieht im Backend nach der Modulinstallation nur, das etwas nicht funktioniert. Das ist dann ärgerlich.

Ich kann mir gut vorstellen,  dass aus diesem Grund die Entscheidung aus dem Hohen Haus so getroffen wurde.

Share this post


Link to post
Share on other sites
  • 0

Bei einem an Gewinnerzielung orientierten Unternehmen wie PrestaShop dürften da wohl eher geschäftliche Erwägungen den Ausschlag gegeben haben.

Aber wie dem auch sei, ich bin da in Sachen Overrides anderer Ansicht. Denn es knallt bei den Overrides nur dann, wenn das Modul schlampig programmiert wurde und nicht erkennt, ob bereits ein Override für eine Klasse, ein Modul oder auch einen Controller oder auch fürs Back Office besteht. In einem solchen Fall muss es die zusätzlichen Änderungen in die bestehende(n) Dateien(en) reinschreiben und nicht mit einer Fehlermeldung aussteigen - und sich natürlich auch korrekt deinstallieren lassen. Und hier bin ich ganz bei dir - das können nämlich viele Module nicht. Am ärgerlichsten sind die Module, die nicht mal ihre eigenen Overrides erkennen.

Wenn man das Risiko auf diese Weise aber fachgerecht minimiert, kann es höchstens dann mal ein Problem geben, wenn zufällig zwei Module die gleiche Funktion überschreiben wollen. Aber das Problem hast du auch, wenn du die Änderungen direkt in den Core schreibst.

Share this post


Link to post
Share on other sites
  • 0

Ich war aber auch noch auf dem Stand das overrides nur bedingt funktionieren. Deshalb habe ich meine ganzen Änderungen noch direkt in den Dateien gemacht und muss nach jedem Update meine Checkliste durchgehen.

Was ich aber komisch finde, bei mir funktioniert es ganz gut wenn alles (Shop, Kundengruppe) auf Brutto gesetz wurde. Wenn ich Netto anzeigen will allerdings garnicht. Werde mir deine Änderung später nochmal genauer ansehen und gucken ob ich neben dem Netto Preis dann an den wichtigen Stellen auch den Brutto eingeblendet bekomme.

Share this post


Link to post
Share on other sites
  • 0

Das ist seltsam. habe gestern abend dazu einen frischen 1.7.2.4 installiert und das Problem auch ohne das PS_LEGAL Modul nachstellen können. Bei uns tritt es bei allen 1.7 Installationen auf.  

Share this post


Link to post
Share on other sites
  • 0

Nur nochmal für die anderen, ist bei mir genauso -,-

Werde also gleich schonmal die Änderung für die Mail übernehmen und mich nach dem wochenende mal dran setzen ob ich im Frontend etwas erreichen kann.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×