Rechnung und Lieferschein mit Artikelvarianten

[[email protected]]

Hallo ich habe folgende Problem,

 

Presto shop 1.61.13

 

Ich habe auf mehre Artikel Artikelvarianten angelegt mit den jeweiligen Größen S,M,L.

 

Nun wenn ich einen  Lieferschein oder eine Rechnung ausdrucke erscheint leidere diese information nicht hinter dem Artikel sieh Bild.

 

Als Rechnungsvorlage benutze ich diese hier aus dem Forum  
https://www.prestashop.com/forums/topic/244719-tutorial-rechnungsformular-ändern-für-version-15x-und-16x/

 

 

Vielleicht kann mir ja Jemand helfen da ich keine Ahnung habe wie ich nun die Artikelvarianten mit in die Rechnung bekommen.

 

Danke LG 

Benjamin 

 

 

[[email protected]]

Inzwischen bin ich dahinter gekommen das, dass probem nicht von der Rechnung kommt. 

 

Habe gerade auf meiner trest domain den schon neu aufgespielt Artikel und großen neu angelegt und schau da sind die großen auf der Rechnung.

 

Nun ist mein problem das ich aber trotzdem in meinem hauptshop die anzeige in der Rechnung nicht bekomme wo könnte es denn noch liegen ?? 

[eleazar]

Ganz einfach! Die Anzeige von solchen Artikeldetails ist schlichtweg nicht vorgesehen. Sie wäre auch für Rechnung und Lieferschein nicht so leicht zu realisieren, da die entsprechenden Variablen an dieser Stelle nicht zur Verfügung stehen.

 

Edit: Das war einfach Unsinn!

[[email protected]]

Verstehe ich jetzt nicht ganz da, ich gerade auf einen test server den shop nochmals komplet neu aufgesetzt habe, ein paar Artikel und Varianten neu eingegeben und hier wird es angezeigt. 

 

nun ist die frage was mache ich in meinem hauptshop falsch 

 

Edited May 1, 2017 by [email protected] (see edit history)

[Netagent]

Ich muss dieses Thema auch nochmal aufgreifen.

In der Version 1.6.1.11 wurden die jeweiligen Artikelvarianten hinter dem Artikelnamen genauso dargestellt, wie es in dem letzten Post von "[email protected]" dargestellt wird.

In der Version 1.6.1.13 ist dies NICHT mehr der Fall!

Siehe auch Sreenshots...

 

Natürlich möchte ich diese Varianten weiterhin dargestellt bekommen, zumal das heutzutage Standart ist. Ich kenne keinen Online Shop, wo das nicht in der PDF Rechnung/Lieferschein aufgeführt wird.

Hat da jemand eine Idee, wie man diesen Zustand wieder herstellt, ohne downgraden zu müssen?

 

 

UPDATE: Da hier ja scheinbar niemand weiß woran es liegt, habe ich mich selbst mal auf die Suche begeben.

Es liegt an der geänderten Datenbankabfrage in Version 1.6.1.13 für die Funktion "public function getProductsDetail()" in der Datei "classes\order\OrderInvoice.php" ab Zeile 138 bis Zeile 151.

Dort wird jetzt ein zusätzliches "LEFT JOIN" in der product_lang Tabelle abgerufen.

Der Sinn des Ganzen erschließt sich mir nicht wirklich, da man eine zusätzliche Abfrage hier sich eigentlich hätte sparen können.

In der product_lang Tabelle wird jetzt mit "product_name" lediglich der Name des Artikels abgerufen, während in der order_detail Tabelle (alte Datenbankabfrage) unter "product_name" der Artikel inkl. der Varianten enthalten ist.

 

Ich hoffe, ich habe das so einigermaßen korrekt widergegeben.

In der Shop Version 1.7.0.6 sind die Varianten übrigens auch in der PDF-Rechnung zu sehen. Wie es in der neuen Version 1.7.1.1 aussieht, weiß ich nicht.

 

Bearbeitungsgrund: Update

 

 

Edited May 8, 2017 by Netagent (see edit history)

[eleazar]

Du hast völlig recht, da habe ich mich oben vertan. Es war tatsächlich bis 1.6.1.12 ok, danach nicht mehr. Es reichen übrigens folgende Änderungen:
 

public function getProductsDetail()
    {
        $id_lang = Context::getContext()->language->id;

        return Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS('
        SELECT *, pl.`name` as product_name
        FROM `'._DB_PREFIX_.'order_detail` od
        LEFT JOIN `'._DB_PREFIX_.'product` p
        ON p.id_product = od.product_id
        LEFT JOIN `'._DB_PREFIX_.'product_shop` ps ON (ps.id_product = p.id_product AND ps.id_shop = od.id_shop)
        LEFT JOIN `'._DB_PREFIX_.'product_lang` pl ON (pl.id_product = p.id_product AND pl.id_lang = '.$id_lang.' AND pl.id_shop = od.id_shop)
        WHERE od.`id_order` = '.(int)$this->id_order.'
        '.($this->id && $this->number ? ' AND od.`id_order_invoice` = '.(int)$this->id : '').' ORDER BY pl.`name` od.`product_name`');
    }

 
Im Prinzip kann man einfach die komplette Datei gegen die gleichnamige aus 1.6.1.10 - 1.6.1.12 austauschen. Wer das nicht möchte, kann folgendes Override als /override/classes/order/OrderInvoice.php hochladen:

<?php

class OrderInvoice extends OrderInvoiceCore
{
 public function getProductsDetail()
    {
        $id_lang = Context::getContext()->language->id;

        return Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS('
		SELECT *
		FROM `'._DB_PREFIX_.'order_detail` od
		LEFT JOIN `'._DB_PREFIX_.'product` p
		ON p.id_product = od.product_id
		LEFT JOIN `'._DB_PREFIX_.'product_shop` ps ON (ps.id_product = p.id_product AND ps.id_shop = od.id_shop)
		LEFT JOIN `'._DB_PREFIX_.'product_lang` pl ON (pl.id_product = p.id_product AND pl.id_lang = '.$id_lang.' AND pl.id_shop = od.id_shop)
		WHERE od.`id_order` = '.(int)$this->id_order.'
		'.($this->id && $this->number ? ' AND od.`id_order_invoice` = '.(int)$this->id : '').' ORDER BY od.`product_name`');
    }
}

Anschließend nicht vergessen, den Cache zu löschen.

Die Programmierer von 1.7 haben diesen neuen Bug noch nicht implementiert.

[eleazar]

Nachtrag:

PrestaShop bringt demnächst Version 1.6.1.14 raus, in dem man versucht,  den Bug durch eine wesentlich kompliziertere SQL-Abfrage zu beheben: https://github.com/PrestaShop/PrestaShop/pull/7858/files

public function getProductsDetail()
    {
        $id_lang = Context::getContext()->language->id;
        return Db::getInstance(_PS_USE_SQL_SLAVE_)->executeS('
		SELECT *, CONCAT(pl.`name`," - ",GROUP_CONCAT(CONCAT(agl.`name`," : ",al.`name`))) as product_name
		FROM `' . _DB_PREFIX_ . 'order_detail` od
		LEFT JOIN `' . _DB_PREFIX_ . 'product` p ON p.id_product = od.product_id
		LEFT JOIN `' . _DB_PREFIX_ . 'product_shop` ps ON (ps.id_product = p.id_product AND ps.id_shop = od.id_shop)
		LEFT JOIN `' . _DB_PREFIX_ . 'product_lang` pl ON (pl.id_product = p.id_product AND pl.id_lang = ' . $id_lang . ' AND pl.id_shop = od.id_shop)
		LEFT JOIN `' . _DB_PREFIX_ . 'product_attribute_combination` pac ON (od.`product_attribute_id` = pac.`id_product_attribute`)
		LEFT JOIN `' . _DB_PREFIX_ . 'attribute` a ON (a.`id_attribute` = pac.`id_attribute`)
		LEFT JOIN `' . _DB_PREFIX_ . 'attribute_group_lang` agl ON (agl.`id_attribute_group` = a.`id_attribute_group` AND agl.`id_lang` = ' . $id_lang . ')
		LEFT JOIN `' . _DB_PREFIX_ . 'attribute_lang` al ON (al.`id_attribute` = a.`id_attribute` AND al.`id_lang` = ' . $id_lang . ')
		WHERE od.`id_order` = ' . (int)$this->id_order . ' 
		' . ($this->id && $this->number ? ' AND od.`id_order_invoice` = ' . (int)$this->id : '') . '
		GROUP BY agl.`id_lang` 
		ORDER BY pl.`name`');
    }

Funktionieren tut das allerdings nicht. Denn ausgegeben wird dann nur der letzte Artikel mit all seinen Varianten unabhängig von der Bestellung. Es scheint wohl niemand auf die Idee gekommen zu sein, das auch mal zu testen: https://github.com/PrestaShop/PrestaShop/commit/eb237ec154febb5c03cd6243876f93e3896e6339#commitcomment-22067458

Es ist ein Trauerspiel!

[Netagent]

WTF Why?

Ich würde ja noch 3 LEFT JOIN´s dran hängen, damit es auch ganz genau wird

Und dann auch noch so eine Perfomance raubende CONCAT Abfrage, die am Ende denn eh nicht funktioniert.

Ich weiß ja nicht wie es heute so gehandhabt wird... aber als ich das programmieren gelernt hatte, hat man mir eingetrichtert, die Abfragen so schlank wie möglich zu halten. Scheinbar ist das heute wohl anders...

Wenn dann alle zukünftigen Updates so aussehen, sollte man sich wirklich überlegen auf Updates zu verzichten.

 

Ich denke, dass in diesem Fall die Override Lösung (auch für die Zukunft) sinnvoll ist.

Danke.

[Zahie]

Vielen Dank hat super geklappt, hab jetzt meine Varianten auf den Lieferschein wieder

[eleazar]

Mein Bugfix ist jetzt auch so in den PrestaShop-Core eingegangen und ist Bestandteil des nächsten Updates auf 1.6.1.14:  https://github.com/PrestaShop/PrestaShop/milestone/21

[rictools]

Wenn dann alle zukünftigen Updates so aussehen, sollte man sich wirklich überlegen auf Updates zu verzichten.

Never change a running system ...

 

Ich denke, man sollte nicht immer gleich ohne triftigen Grund auf die neueste Version upgraden, sondern erst einmal abwarten, ob es damit Probleme gibt. Hier wurde in der letzten Zeit trotz bereits vorhandener neuerer Versionen ja 1.6.1.10 als stabil empfohlen.