Attachserial et les options de produits

Bonjour,

Je viens de découvrir que attachserial, lorsque l'on sélectionne le champ de type "Product" + {order_product.order_product_name} ne tient pas compte des éventuelles options commandées avec le produit principal. Il affiche bien le produit parent mais ne fait pas de boucle sur les produits enfants liés... on ne retrouve donc pas la liste des options sur le ticket.

Il y a bien un champ "order_product_option_parent_id" dans la table "__hikashop_order_product" qui sert à cela mais case 'product' à la ligne 326 n'en tient pas compte.

Et je ne peux pas utiliser le case 'order_product' pour les mêmes raisons. Pire encore si le client a acheté plusieurs produits principaux, chaque ticket va lister tous les produits faisant partie de la même commande... sans faire de distinction.

Est-ce que vous voyez ce que je veux dire par là ? J'avoue ne pas savoir comment overrider cela...

Merci

Didier

Merci de m'avoir répondu si vite (et un dimanche !) !!

Oui, en effet, le tableau issu d'une requête jointe permettrait d'isoler les produits "enfants" commandés avec le produit parent. Toutes les tables concernées contiennent une partie des informations nécessaires. Je m'explique :
- dans une commande on a un (ou plusieurs) produit(s)
- tel quel, le plugin attacheserial affiche bien le nom du produit sur le ticket. Mais seulement le nom du produit "parent", pour chaque ticket
- si j'ajoute des options à ce produit (d'autres produits liés prévus en option), le code les ignore.
- le besoin est bien d'avoir, sur le ticket, le nom du produit "parent" et, en dessous, un produit "enfant" par ligne... si des produits enfants existent dans cette commande.

En fait, je pensais reproduire le code prévu pour 'order_product' (ligne 297) où l'on a bien une boucle foreach mais seulement destinée aux commandes à produits multiples, si j'ai tout bien compris... or si je passe par là, mon ticket aura tous les produits de toute la commande sur le même ticket, non ?

Mon idéal serait d'étendre le code prévu pour le case 'product' (ligne 236) en ajoutant une boucle foreach sur le champ "order_product_option_parent_id" de la table "__hikashop_order_product", obtenant ainsi un tableau des options (s'il y en a), si ce champ est != 0 et == order_product_id
Mais j'avoue ne pas savoir comment écrire cette boucle dans le code en place en utilisant les variables déjà présentes. Je n'ai pas fait de tour assez profond pour cela...

J'obtiendrai donc un chèque cadeau plus explicite pour le client final car il affichera sa "valeur réelle" : le produit + ses options

J'espère ne pas être trop confus dans mes explications

Bonsoir,

Oui, je comprends

Cas concret : mon client vend des Chèques Cadeaux pour ses cours (ateliers) de cuisine depuis une boutique Hikashop paramétrée pour cela. Hikaserial & attachserial se chargent de générer les tickets envoyés à l'acheteur (qui, lui, les imprime et les offre à qui il veut).
Or j'utilise JSE Event pour gérer les réservations à ces ateliers. Des ateliers qui ont un prix et les Chèques Cadeaux doivent pouvoir venir en déduction pour celui qui utilise le code unique du ticket. Là est la relation entre les tables coupons dont je vous avais parlé dans un autre post... mais là n'est pas la question.

Il y a 3 types d'ateliers avec 2 options chacun :
- les ateliers de cuisine pour les adultes à 75 € le cours / personne
- les ateliers pour les enfants à 45 € le cours / personne
- les ateliers "sushi" à 65 € le cours / personne

Lors de l'achat d'un Chèque Cadeau on laisse la possibilité d'ajouter 2 options :
- cours Duo, suivre le cours à 2 et la seconde personne paie moins cher (+ 55 €)
- inviter une personne en fin de cours pour la dégustation (= un accompagnant) : + 30 €

Concrètement si j'offre un Chèque Cadeau Adulte + les 2 options, je paie 75 + 55 + 30 soit 160 €. J'ai bien un seul attachserial de 160 € et un seul ticket à imprimer.
Mais ça fait bien 3 produits que je voudrais retrouver "en clair" sur le ticket car, sinon, la personne qui reçoit mon cadeau ne saura pas qu'elle peut s'offrir aussi les options du cours grâce à son code unique (elle n'aura pas la facture, ni la commande) !

A moins que je me sois complètement planté dans mon workflow Hikashop-Hikaserial, je ne vois pas d'autre solution que d'étendre le plugin attachserial pour qu'il détecte (et affiche) les produits optionnels commandés avec un produit parent...

Bonjour,

Oui, j'avais pensé aux caractéristiques & variantes que j'utilise pour un autre type de produit. Mais cela m'oblige de revoir tous les paramètres des chèques cadeau déjà en place - ce qui représente pas mal de boulot - pour un résultat "frontal" moins explicite pour le consommateur. Si je comprends votre raisonnement, une variante ne représente qu'une seule ligne de texte à inclure dans l'image au final ? La ligne de texte serait plus longue (le produit optionné) et je devrai refaire aussi toutes les images de fond des tickets !! Ouch ! Cette approche ne me semblait pas adaptée.

La seconde partie de votre réponse m'a fait tilter ! Attachserial, dans sa fonction "displayTextBox", a besoin de dessiner des emplacements précis (les lignes avec coordonnées et formattage) et supprime les retours charriot provenant des variables $text... je comprends désormais pourquoi on ne peut pas balancer comme ça un tableau de valeurs ! Je n'avais pas vu cela.

Disons que j'oblige le webmaster à limiter le nombre d'options à maxi 4 par exemple. On dessine le ticket en réservant une zone suffisante pour 5 lignes (le produit + 4 options maxi). Et dans Attachserial, on crée un "dynamic text " pour le produit parent + 4 lignes spécifiques aux options. C'est bien cela ? Le script va chercher les produits enfants un par un : ça ok, on a des exemples de code notamment dans /order/tmpl/show.php dès la ligne 220... mais après je n'ai plus d'idée pour modifier attachserial en conséquence

Cordialement

Wow ! Et moi qui était en train de bricoler un nouveau case 'product_option': dans mon coin !!! Superbe évolution Jerome !

A première vue, en plus d'avoir ajouté l'image du produit (c'est top), vous avez donc prévu 2 types d'options : pour produit et commande ? Cela va au delà de ce que je phosphorais... il faut que je teste !!! Notamment les paramètres à ajouter ou non, ça je n'ai pas encore compris juste en lisant le code...

Je teste cela et reviens vers vous

Non, je n'ai pas compris les réglages

A première vue c'est "option_order" qui m'intéresse mais le ticket n'affiche rien. J'ai loupé le paramètre, j'en suis sûr !

Je mets quoi ? J'ai essayé :
- {order_product.order_product_name} KO
- order_product_name KO

Bonsoir,

Si par position vous entendez la ligne de tableau (array), 0 = la 1ère option, 1 = la seconde ...etc ?
Alors, malheureusement, je n'ai aucune sortie texte sur mon ticket... je suis désolé.

Désirez-vous un accès admin par MP ?

Bonjour,

Merci, je vais corriger cela et en voir les possibilités

Pendant ce temps j'en ai profité pour compléter le code, toujours en fonction de mes besoins mais peut être cela peut-il vous servir...

Lorsque l'on ajoute les lignes d'options - s'il y en a - sur le ticket, il est utile que le client comprenne que ce sont des options qu'il pourra commander par la suite en déduisant leur valeur. J'ai juste ajouté "en dur" un libellé (pas propre, je sais) dans le case 'option_product' :

return "+ Option : ".$full_product->$field;

case 'product_price':
	if(empty($serial)) return null;
	   $opid = 0; $pid = (int)$serial->product_id;
	   if(!empty($serial->serial_order_product_id)) {
		$opid = (int)$serial->serial_order_product_id;
	   }
           $price = 0;
	   foreach($order->products as $product) {
		if(($opid > 0 && $product->order_product_id == $opid) || ($opid == 0 && $product->product_id == $pid)) {
			$price += $product->order_product_price;
			if($field == 'incvat') {
				$price += $product->order_product_tax;
			}
                }
                if($product->order_product_option_parent_id == $opid) {
                        $price += $product->order_product_price;
			if($field == 'incvat') {
				$price += $product->order_product_tax;
                        }
                 }
	   }
           return $price;
	   break;

Le dynamic text est une bonne idée car beaucoup plus généraliste que ma solution.

Mais il faudrait en ce cas aussi parser les strings de lang (comme le type Traduction) : les utilisateurs pourraient mettre ce qu'ils veulent comme texte, toutes langues comprises...

Jerome wrote: Oui oui, le système est extrèmement flexible (peut être même trop) !

{_.HIKASHOP_OPTION}: {option_order.0.order_product_name}

MY_TRANSLATION_ATTACHSERIAL="Option :  {option_order.0.order_product_name}"