Calcul prix spécifique pour déclinaison

[nicooos]

Bonjour,

 

nous rencontrons un problème au niveau des calculs de prix spécifiques.

 

Je m'explique.

 

Avant de mettre en place des prix spécifique

Nous avons mis en place un produit Voile du temps.

Le prix de ce produit est de 0€ (nous gérons les prix au niveau des déclinaisons car plus simple à gérer ainsi).

Nous avons donc, pour chaque déclinaison fixé un prix pour chaque déclinaison en renseignant le champ : Impact sur le prix

 

Ainsi, pour chaque déclinaison de notre produit nous avons bien le bon prix lors de la sélection de la déclinaison associé.

 

 

Il y a deux attribut dans la déclinaison :

·         Couleur

·         Poids

 

Le problème intervient lorsque nous souhaitons mettre en place des promos.

 

Après mise en place des prix spécifique

Pour certaines déclinaisons, nous souhaitons mettre en place des promos:

 

Les prix affiché dans la liste des produits sont de 0€ (pour les produits concernés par la promos).

 

Dans la fiche produit, le prix est correct.

 

Dans le panier, le prix est de 0€ … et du coup la facture aussi.

 

Un topic a peu prêt similaire parlé de ce genre de problème : (https://www.prestashop.com/forums/topic/4664[spam-filter]prix-fixe-d%C3%A9clinaison/)

Mais pas vraiment dans le même cas car mon produit d’origine est de 0€

Je ne sais pas comment Prestashop gère les prix. Normalement, cela me semble correcte.

 

Dans le contrôleur ProductController,  le calcul me semble correcte dans la méthode assignAttributesGroupes() :

 

if (!isset($combination_prices_set[(int)$row['id_product_attribute']])) {
    Product::getPriceStatic((int)$this->product->id, false, $row['id_product_attribute'], 6, null, false, true, 1, false, null, null, null, $combination_specific_price);
    $combination_prices_set[(int)$row['id_product_attribute']] = true;
    $combinations[$row['id_product_attribute']]['specific_price'] = $combination_specific_price;
}

 

Mais je ne sais pas si c’est vraiment cette méthode qui est appelé mais la logique est pourtant bonne.

 

Je voulais savoir si comme ça vous détecté des erreurs de saisie ?

Est-ce que le process de création de promotion est bonne ?

Est-ce un Bug ?

 

Merci de votre temps.

 

Cordialement,

Nicolas.

Edited March 23, 2016 by nicooos (see edit history)

[GuillaumeCW]

Il me semble avoir vu le sujet quelques fois, si je ne trompe pas. Si votre produit à 0 € n'a pas de déclinaison par défaut qui lui soit attribué, il sera inévitablement commandé voire affiché à 0 €. Dans la fiche produit, l'affichage du prix est probablement géré par du code Javascript, dont la logique ne se soucie pas de savoir s'il y a ou non une déclinaison par défaut (car il doit y en avoir une, de toute manière), donc il choisit la première venue, en quelques sortes.

[nicooos]

Et surtout, dans ce cas là, si pour un produit à 0€ si on ne fixe pas le prix HT dans le prix spécifique il prend le prix par défaut : 0€ ...

Edited April 20, 2016 by nicooos (see edit history)

[nicooos]

Bonjour,

 

je reviens sur le sujet, en ayant compris les points précédents, mais en pointant sur un autre point ...

Car en effet j'ai un autre problème avec les déclinaisons.

 

Dans mon cas c'est uniquement sur la déclinaison par défaut que le problème intervient.

Cela n'est pas un problème de calcul "front" (sur le thème) mais bien au niveau du controller, mais alors où .... 

 

pour un prix spécifique modifié à la main (20€ HT) et une réduction de 20%, on devrait avoir les prix suivants : 24€ TTC & 19.20€ avec la remise.

Hors c'est les éléments suivant qui sont affichés: 19,20€ TTC & 15.36 € avec remise.

 

lorsque l'on affiche les données transmis avec le controller, pour le prix spécifique, j'ai 16€ au lieu d'avoir 20€ comme définis dans le BO.

 

Si quelqu'un est dans le même cas ?

 

En vous remerciant d'avoir lu mon cas.

 

Cordialement,

Nicolas

[nicooos]

Alors si vous avez le même problème que moi, j'ai trouvé d'où vient le problème.

 

Il vient en faite du cache concernant les prix présent dans la classe Product.php.

Dans la fonction static priceCalculation, à la ligne 2978, il y a ce bout de code : 

 

if (isset(self::$_prices[$cache_id])) {
/* Affect reference before returning cache */
if (isset($specific_price['price']) && $specific_price['price'] > 0) {
$specific_price['price'] = self::$_prices[$cache_id];
}
return self::$_prices[$cache_id];
 

Si le prix spécifique est  > 0 alors on prend le prix en cache.

Or, le prix en cache est erroné.

 

Du coup, en commentant la ligne $specific_price['price'] = self::$_prices[$cache_id];  le problème est résolu car on garde le prix qui est saisie en BO.

 

J'espère que ce post pourra vous aider.

 

Cordialement,

Nicolas

[insaneness]

Ceci pourrait être lié à ma question de ce topic peut être ?
 

[GuillaumeCW]

Dans la mesure où la valeur du prix est extraite du cache, ce qui semble être le cas de la variable $result dans la partie du code où vous avez fait des modifications, et dans la mesure où cette valeur serait incorrecte, oui. Mais désolé, je n'ai pas eu le courage de plonger dans la logique où s'effectue votre correction, ni dans celle où intervient la solution apportée par Nicooos. Mais je confirme le problème qu'il a soulevé, c'est à dire dans le cas d'un prix spécifique avec un changement du prix de vente HT. Je n'ai pas pu comprendre/trouver toutes les informations pour reproduire votre exemple.

Edited July 8, 2016 by GuillaumeCW (see edit history)

[nicooos]

Bonjour,

 

en plus de cela, car dans mon cas ça retournait bien une erreur au niveau du prix, il faut voir aussi au niveau du thème que vous utilisez.

En effet, le calcul du prix se fait aussi en javascript !

 

fais un tour dans le fichier /themes/[TON_THEME]/js/product.js en cas ...