Récemment
-
Erreur module block_cart en php8.2 mais pas en php7.4
Bugs & Améliorations14 -
Bug page de commande
Bugs & Améliorations4 -
Passage au Webp qui n'a pas fonctionné
Bugs & Améliorations1 -
Nouveautés possibles ?
Nouvelles fonctionnalités2 -
bug installation bdd
Questions relatives à l'installation/upgrade26 -
Configuration de wamp compatible presta.1.6.1.24 et PhenixSuite 1.6.2.25
Discussion générale61 -
Responsive sur liste des produits dans les commandes
Bugs & Améliorations2 -
affichage incorrect de produit personnalisé au panier
Bugs & Améliorations3 -
Erreur PHP à l'installation du module cedconnector
Bugs & Améliorations2 -
Problème calcul HT
Bugs & Améliorations18 -
MAJ .htaccess Apache 2.4 et 2.2
Nouvelles fonctionnalités5 -
Erreur SQL 1.6.2.23 -> 1.6.2.25
Questions relatives à l'installation/upgrade2 -
Calcul règle panier
Bugs & Améliorations1 -
Images sur les BL ne s'affichent pas
Bugs & Améliorations13 -
SQL [WARNING] MAJ 1.6.2.19 vers 1.6.2.25
Questions relatives à l'installation/upgrade3 -
Erreur - Le template d'e-mail suivant n'existe pas : /mails/fr/password_code.html [RÉSOLU]
Bugs & Améliorations3 -
Soucis ps_checkout (admin et front)
Bugs & Améliorations9 -
Erreur SQL sur le Liens Modules et Service après upgrade a 1.6.2.25
Questions relatives à l'installation/upgrade3 -
Erreur SQL sur la requête The used table type doesn't support FULLTEXT indexes
Questions relatives à l'installation/upgrade3 -
Maj de 1.6.1.20 rien ne se passe
Questions relatives à l'installation/upgrade2
Calcul des règles paniers HT/TTC [RÉSOLU]
-
Auparavant elles s'ajoutaient pourtant. Se pourrait-il que la mise à jour ait eu à voir avec la modification de ce paramètre ?
-
Auparavant quand ? A moins d'un override Prestashop n'a jamais ajouté de taxe à un transporteur qui n'en a pas.
-
A mon avis ça vient de chez nous, certains transporteurs ont bien les taxes FR, d'autres non... On s'est séparé d'un bras cassé en début d'année...
Du coup, on peut appliquer les corrections dans la foulée pour le calcul de la TVA sur les règles... ?
-
Je viens de checker d'anciennes commandes (avant la migration sur PhenixSuite) et en effet la TVA sur les FDP n'a pas été calculée (de par le fait, comme on dit chez soi).
Il n'y a donc bien que la TVA sur les règles paniers à corriger.
-
Sur une commande (payplug) j'ai ce message lorsque dans paiement je tente de rajouter le montant du remboursement (TVA non calculée sur la règle panier) :
C'est pour que la facture soit juste pour le client.
-
Je viens de m'apercevoir qu'il n'y a qu'un groupe client dont la TVA n'est pas appliquée sur les règles paniers : les professionnels dont l'affichage des prix est configuré en HT, alors qu'en bas de la commande il est indiqué :
-
@Olivier75009
Curieux, le contrôle effectué par le code me semble pourtant juste$new_sold = $order->total_paid_real + $amount; if($new_sold > $order->total_paid) { $this->errors[] = Tools::displayError('You cannot add a new payment because this order has already been paid in full'); }
Ou alors le contrôle devrait être peut-être être fait sur les arrondis.
Qu'avez-vous comme total_paid_real dans la table orders ?
-
@Olivier75009 Oui, et c'est ce que j'ai corrigé.
-
pour cette commande : 119.480000 (il y a déjà eu un remboursement de 1,82€)
-
Peut-on avoir la correction pour le calcul du groupe pro ?
-
@eolia C'est le seul cas où nous n'avons pas pu éditer la commande)
-
@Olivier75009 a dit dans Calcul des règles paniers HT/TTC :
Peut-on avoir la correction pour le calcul du groupe pro ?
Si on m'en laisse le temps et que je puisse finaliser tous les tests, la version 1.6.2.21 sera libérée ce soir.
-
Merci encore.
-
@eolia Si j'affiche $new_sold et $total_paid dans Tools::displayError : "You cannot add a new payment because this order has already been paid in full 117.66 sur 117.660000".
En ajoutant $new.'0000' > (...) l'ajout passe.
-
Correctif:
elseif(!Validate::isNegativePrice($amount)) { $this->errors[] = Tools::displayError('The amount is invalid.'); } elseif(!Validate::isGenericName(Tools::getValue('payment_method'))) { $this->errors[] = Tools::displayError('The selected payment method is invalid.'); } elseif(!Validate::isString(Tools::getValue('payment_transaction_id'))) { $this->errors[] = Tools::displayError('The transaction ID is invalid.'); } elseif(!Validate::isLoadedObject($currency)) { $this->errors[] = Tools::displayError('The selected currency is invalid.'); } elseif($order_has_invoice && !Validate::isLoadedObject($order_invoice)) { $this->errors[] = Tools::displayError('The invoice is invalid.'); } elseif(!Validate::isDate(Tools::getValue('payment_date'))) { $this->errors[] = Tools::displayError('The date is invalid'); } else { $amount = Tools::ps_round($amount, _PS_PRICE_COMPUTE_PRECISION_); $new_sold = $order->total_paid_real + $amount; if($new_sold > $order->total_paid) { $this->errors[] = Tools::displayError('You cannot add a new payment because this order has already been paid in full'); }
1ère ligne modifiée (1837) et ajout avant la ligne 1956 ($amount = Tools::ps_round($amount, PS_PRICE_COMPUTE_PRECISION);)
-
Pourquoi ne pas retirer tous les nuls (0) après les décimales ?
-
Parce que la comparaison de floats n'est pas si simple et dans votre cas précis vous êtes à 2 décimales mais certains pays sont à 3 (dinar ou ryal) ou plus et je ne sais pas ce que va rentrer le commerçant (Presta accepte jusqu'à 6 décimales)
-
Je viens de voir que sur vos tests (règles paniers avec pourcentage de réduction -> Test HT Eolia) ça s'applique à la commande. Est-ce que ça fonctionne aussi sur les produits sélectionnés lorsqu'on choisit de faire une réduction sur une ou plusieurs catégories de produits ?
Édith : nous avons créé des prix spécifiques pour le WE du black friday, certains correspondent à une catégorie réduite dans les règles paniers, et lors d'une commande, au vu de la quantité de produit, la règle n'est calculée que sur les produits n'ayants pas eu de prix spécifiques.
(Exemple : -5% sur le prix si 5 produits de la même catégorie sont dans le panier.)
-
Oui ça fonctionne pareil, ce n'est pas le type de calcul qui avait un souci, mais la façon dont le prix était calculé en TTC lors de la conversion pour le paiement.
-
Et pour l'application de la règle panier même si l'article a un prix spécifique ? (la règle s'applique bien car il y a au moins le bon nombre d'articles, mais elle n'est calculée que sur les articles de cette règle n'ayant pas de prix spécifique)