[Module Custom] Bug Prix 0€ (Confirmation) + Duplication Champs Perso sur Produit Simple

[Manu_manu]

Bonjour à tous,

Je sollicite votre expertise concernant un comportement spécifique sur un module que j'essais de développer pour mon shop (compatible PrestaShop 1.7 à 8/9, développé sans override).

1. Le Cas Concret (Pourquoi ce module ?) Pour bien comprendre la logique, prenons l'exemple d'une Plaque de Plexiglass (Produit Principal).

Mon Stock : J'ai 1 seule plaque en stock physique.

Le Besoin Client : Le client veut acheter cette plaque mais y ajouter une prestation : "Forfait 3 découpes" + un champ texte pour me donner les cotes.

Pourquoi je n'utilise pas les déclinaisons natives ? Si je crée des déclinaisons (Plaque seule, Plaque + 1 découpe, Plaque + 2 découpes...), PrestaShop divise mon stock. Si je vends la "Plaque + 1 découpe", le stock de la "Plaque seule" ne bouge pas. C'est ingérable logistiquement car c'est le même objet physique. De plus, j'ai besoin d'un Code Produit (SKU) unique pour chaque type de découpe (Option 1, Option 2, etc.) pour ma comptabilité analytique.

2. La Solution Technique du Module

Les Options (Découpes) : Ce sont des Produits Virtuels ajoutés au panier via le module (hookActionCartSave) en même temps que le produit principal. Cela garde les stocks indépendants.

Le Texte (Cotes) : Le module injecte la personnalisation programmatiquement dans la BDD (ps_customization + ps_customized_data) pour éviter le rechargement de page natif.

3. Les Problèmes Rencontrés Tout fonctionne (Ajout panier, déstockage, Total commande, Facture). Mais je bute sur deux points bloquants :

Problème A : Affichage Prix 0€ (Uniquement sur Confirmation) Sur la page order-confirmation, la ligne de ma Plaque de Plexiglass s'affiche à 0,00 €.

Le prix de l'option "Découpe" s'affiche correctement.

Le Total à payer de la commande est EXACT.

Sur la facture PDF et dans le Back-Office, le prix de la plaque est correct.

Le souci est uniquement visuel sur le résumé final.

Problème B : Duplication des Champs de Personnalisation À chaque nouvelle commande d'un client qui remplit le champ texte "Cotes", un nouveau champ est créé dans la fiche produit (table ps_customization_field).

Je me retrouve avec des dizaines de champs "Cotes" dupliqués dans le Back-Office du produit Plexiglass.

Mon code semble recréer un label (createLabels) à chaque fois au lieu de réutiliser l'existant.

4. Analyse Technique (État BDD) Le produit principal (Plaque) est un Produit Simple. Sur la ligne posant problème :

id_product_attribute est à 0 (normal pour un produit simple).

id_customization est bien renseigné et lié au panier.

L'adresse de livraison est correcte.

5. Mes Questions

Affichage : Est-ce que le OrderPresenter natif a du mal à afficher le prix unitaire d'un produit simple (attribute=0) qui possède une personnalisation ? Y a-t-il une astuce pour corriger ce rendu visuel sans toucher au cœur ?

Duplication : Quelle est la bonne pratique dans le hookActionCartSave pour vérifier si un champ de personnalisation existe déjà pour ce produit avant d'en insérer un nouveau ?

Merci infiniment pour votre temps et vos pistes !

PS. pour une raison que je ne connais pas, je n'arrive pas à mettre en ligne mon fichier, cela me fais une erreur 200

Edited Sunday at 01:06 PM by Manu_manu (see edit history)

[wepresta]

Bonjour,

1) Prix à 0€ sur order-confirmation uniquement

C’est quasi toujours un problème de “donnée affichée”, pas de calcul : la confirmation récupère un champ de prix “présenté” qui peut être vide/0 avec une customization injectée, alors que le total/BO/PDF utilisent le bon prix.

Solution propre : adapter le template de confirmation pour afficher un champ fiable (ex. total/qty), ou vérifier dans order.products quel champ est à 0 et en utiliser un autre.

2) Duplication des champs ps_customization_field

Ne créez pas le champ à chaque hookActionCartSave.
Bonne pratique : créer 1 seule fois (install ou 1er passage), puis réutiliser le même id_customization_field (lookup en BDD, ou stocker l’ID en table module/Configuration).

Edited yesterday at 08:40 AM by wepresta (see edit history)