Jump to content

Problème d'arrondis dans les factures

Arnaud06

By Arnaud06
in Discussion générale

 Share

Recommended Posts

Arnaud06 Newbie

Arnaud06

Posted
Posted

Bonsoir,

J'ai une petite question : quelle est la version actuellement fiable pour mettre en production ?
J'ai de mon côté la V1.2, et voici par exemple la facture que j'ai eu aujourd'hui, et qui me laisse perplexe quant à la fiabilité de ma boutique Prestashop... (cf jpeg joint)
La version 1.4 est elle plus fiable ?

Merci pour votre aide,

AP

12142_Ta2XWDgXsWTK59qsS30D_t

Link to comment
Share on other sites
badboysdu13 Newbie

badboysdu13

Posted
Posted

aurez tu trouver pour réparer ton souci
car avec l équipe prestashop il réponde au question facile
du moin il réponde au question ou il s ont trouver la réponsse
par d autre professionel se sont des Goa’ulds il vole
le savoir des autres pour se les aproprier et se faire passer pour des génie
malgrès que se soit un logiciel pratique il manque beaucoup de finition
qui ses dans 2 ans il serra peut etre bien opérationel

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

J'ai exactement le même problème, et c'est plus que dérangeant !

Les PU affichés sont les prix de bases et non les prix dégressifs, mais le total est bon.
D'autre part, j'ai des erreur de calcul grotesques qui surviennent de plus en plus (voir photo)

J'utilise la 1.2.0.8.

La 1.2.4 résoudrait-elle le problème ?

12165_u343LotVHcVEBuIdJiR4_t

Link to comment
Share on other sites
Arnaud06 Newbie

Arnaud06

Posted
  • Author
Posted

Hello,

Pas de news la super PrestaTeam, en même temps c'est le salon du E-commerce, ils sont peut être un peu occupés.
A leur retour ce serait cool de se pencher sur le problème si nous sommes plusieurs ? C'est super d'avoir des projets plein la tête, mais ce serait aussi cool de vérouiller les projets "sur le marché". Après c'est peut être de notre faute, peut être que des modules installés créent des conflits.. je sais pas, mais c'est génant, d'autant plus que voyant que je ne suis pas le seul ca m'inquiete car je ne verifie que très rarement les calculs, et là c'est le client qui m'a tel.

Merci la super team de nous aider

Arnaud

Link to comment
Share on other sites
Patric Newbie

Patric

Posted
Posted

Les bugs des anciennes versions sont censés avoir été corrigés, si tant est qu'ils ont été signalés.
Donc si ce bug est toujours présent dans la version actuelle, merci de le remonter via l'outil pas user friendly mais qui est le seul pris en compte pour la correction des bugs.

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

T'as de la chance, moi ça le fait sur toutes les factures, mail, commandes dans le BO etc...

Pour info, y a-t-il une 1.2.5 qui doit sortir dans les tout prochains jours ?
Parce que je vais migrer vers 1.2.4 en espérant que ça réglera le problème, mais comme ça me prend 3 jours pour faire une update (beaucoup de .php modifiés par moi), je ne voudrais pas avoir une MAJ de retard avant meme d'avoir la précédente en ligne.

Link to comment
Share on other sites
antinoos Newbie

antinoos

Posted
Posted

Bonjour,

j'intègre ce poste pour éviter d'en faire un nouveau.
J'ai la version 1.1.0.5 encore pour l'instant

Sur mes factures, j'ai un petit souci d'arrondi par exemple il apparaît sur la facture du client :

LESSIVE ATOMISEE - 20kg Prix de Vente unitaire HT : 27,80 € / Nombre: 5 / TOTAL HT : 139,01 € / TOTAL TTC 166.25 €

Prestashop affiche 139.01 € !!! Un truc de fou là, le site est en prod et j'ai un client qui me demande comment c'est possible.
En back office, j'ai un prix de vente unitaire à 27,7977 € dans la fiche produits entrée par mes soins. Si on multiplie par 5 ca fait 138.99 €.
Le prix de vente TTC est de 32.246, arrondi à 33,25 € par prestashop.

Le problème c'est qu'il calcul d'un côté les montants HT sur la base du prix HT unitaire arrondi et les montants TTc sur la base du prix TTC unitaire arrondi également. Sur la facture, le 139.01 vient du calcul ex post du montant HT déduit du montant TTC (en divisant par 1.196 on obtient 139.005). Là le client se demande pourquoi 27.80x5 ca fait 139,01 sur l'affichage ??

A qui on peut faire appel pour corriger tous ces bugs, mon site est en prod et je préfère payer quelqu'un pour le faire, mais qui ?

Alex

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Je viens de faire (en local) une MAJ de la 1.2.0.8 vers la 1.2.4.

Toujours le meme problème !

Mon produit :
Prix de base du produit : 6€ TTC pour 1 exemplaire.

Je commande 10 exemplaires à 3,90 € par exemplaire (prix dégressif).
Cout du transport : offert. Donc pas un euro de plus à payer que le prix des produits.
Je me retrouve avec une facture qui dit n'importe quoi (voir screenshot).

Quand je vais dans la base, table Orders, j'ai ceci :

total_paid : 39.00
total_paid_real : 39.00
total products : 30.97

Pourquoi ????

J'espère qu'un membre de la team va pouvoir m'aider au plus vite, car la boutique est en prod. C'est TRES URGENT !!!

Merci

12213_36dnmUBIWolQwrZhE1X1_t

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Je viens de poster dans le bug tracker, mais je pense que c'est un problème lié à Presta, et non aux diverses modif que j'ai pu faire.

Je viens de faire une installation fraiche de Presta 1.2.4 avec les produits exemples.. Theme Presta et aucune modif sur la base ou les pages PHP. J'ai juste changé le prix d'un produit pour correspondre aux miens, ainsi que le port offert à partir de 10€.
Meme résultat !

Prix de base 6 €
Prix dégressif : x10 = -2.10 €
On est donc à 3.90 /pièce x10 = 39 €

Résultat : (voir image)

12215_CIaoOO09FU7B26SSgAa5_t

Link to comment
Share on other sites
Arnaud06 Newbie

Arnaud06

Posted
  • Author
Posted

C'est bizarre que ce soit un problème d'origine, calculer le montant d'une facture pour un sytème de e-commerce, c'est quand même le BA-ba (lire béaba :-)
ET nous ne serions pas les seules à avoir ce problème ...
Par ailleurs mois je n'ai pas de prix degressif.
Tchuss

Link to comment
Share on other sites
antinoos Newbie

antinoos

Posted
Posted

Bonjour juste une remarque, car j'ai le même genre de problème sur une facture sauf que moi c'est dans les lignes du produit et pas le total. Est-ce que par hasard tu utiliserais 4 chiffres après la virgule pour le prix de vente ? (au lieu de l'arrondir à deux directement comme le fait prestashop directement de toute manière).
A+
Alex

Link to comment
Share on other sites
antinoos Newbie

antinoos

Posted
Posted

Comment ca tu as mis le TTC ? Tu as mis la taxe tu veux dire ? Et il a calculé seul le TTC.
J'ia essayé dans tous les sens et je vois pas comment on arrive à 39,00. N'y aurait il pas des frais de port ? bien que ne s'affichant pas sur la facture ? Ou emballage cadeaux ou autres surplus de 1.96 € ?
Tes factures font peur en tout cas, si j'étais client, je me taperai le derrière sur la suspension !

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted
Comment ca tu as mis le TTC ? Tu as mis la taxe tu veux dire ? Et il a calculé seul le TTC.
J'ia essayé dans tous les sens et je vois pas comment on arrive à 39,00. N'y aurait il pas des frais de port ? bien que ne s'affichant pas sur la facture ? Ou emballage cadeaux ou autres surplus de 1.96 € ?
Tes factures font peur en tout cas, si j'étais client, je me taperai le derrière sur la suspension !


A la base, j'avais mis 6 € dans "TTC". Puis sélection de TVA 19.6, et Presta calcule automatiquement le prix HT, à savoir 5.016722 €

Suite à ton message, j'ai arrondi et marqué moi-meme 5.02 € dans HT. Presta calcul alors un TTC à 6.003920 €. Mais le résultat est le même > mauvais calcul de facture.

Mon produit qui est 3.90 TTC (c'est le prix dégressif pour 10 unités achetées) est affiché à 3,49 € dans les factures.
Aucun frais de port. Installation fraiche de presta sans changement, mis à part les prix.
Pourquoi ai-je donc 0.41 € qui disparaîssent du prix ??? Pourquoi cette erreur est-elle durablement inscrite dans la DB > table Orders > champs total_products ??

Merci de ton aide. Je me sens moins seul.
Link to comment
Share on other sites
antinoos Newbie

antinoos

Posted
Posted

Attends, je viens de relire tes messages. j'essaie dans ma boutique en 1.1
...

Aie là j'avoue qu'il y a un bug. voici ce que j'ai fait


Alors dans ta fiche produit le PV HT= 5.016722
PV TTC = 6 euros
Ensuite tu dis que si le client achète 10 unités, il y a une réduction de 2,10 € c'est ça ? c'est ce que j'ai fait. j'ai jamais utilisé les réductions mais a priori ca semble s'appliquer sur le prix HT.


Moi j'ai un prix unitaire de 3.26 dans la facture x10 il met 32,61. Par contre le total est comme le tien à 39,00 €

En fait il devrait mettre quoi à la place de 3.26 dans le total HT ?

il semblerait donc que le total HT dans la facture soit un peu n'importe quoi du coup...
Idem boutique en prod et là gros stress.
Je suis en 1.1 donc a priori un vieux bug

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Merci d'avoir checké, c'est sympa de ta part !

Il ne reste plus qu'à espérer que la team se penche sur le problème AU PLUS VITE !!!

Sincèrement désolé de le dire comme ça, la Team, mais j'ai franchement le feu aux f... Les commandes tombent, toutes fausses, et moi... ben je passe pour une truffe. Ne m'en veuillez donc pas. M'enfin pour une solution e-commerce, ça la fout mal quand même.

Le pire, c'est que ça s'inscrit dans la DB. Va falloir tout reprendre à la main depuis ma MAJ vers la 1.2.0.8. :down:

Link to comment
Share on other sites
antinoos Newbie

antinoos

Posted
Posted

Merci la team, pour l'instant je crois que tu devrais enlever tes prix dégressifs sur tous les produits et les clients ne se plaindront pas.
De toute manière les clients se plaignent jamais si ? lol...

Bon courage la team, jespère que vous arriverez à résoudre le problème dans la prochaine version. Je confirme en tout cas que le problème existe en 1.1.0.5 sauf erreur de ma part

Alex

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted
Merci la team, pour l'instant je crois que tu devrais enlever tes prix dégressifs sur tous les produits et les clients ne se plaindront pas.
De toute manière les clients se plaignent jamais si ? lol...

Bon courage la team, jespère que vous arriverez à résoudre le problème dans la prochaine version. Je confirme en tout cas que le problème existe en 1.1.0.5 sauf erreur de ma part

Alex


Impossible. Tout mon business model est basé sur les dégressifs.
Link to comment
Share on other sites
antinoos Newbie

antinoos

Posted
Posted

Je te soutiens, car avoir un site en développement c'est une chose, mais j'avoue que depuis la prod, mes nuits mes donnent des sueurs froides. En même temps, ne sommes-nous pas les pionniers ? Et tous ces problèmes, feront que nous maîtriseront le logiciel et plus tard devenir experts. Je suis certain que la team va résoudre le problème très vite, ils sont bons et connaissent ce qu'un magasin en prod signifie.
Alors espoir, tout problème a une solution surtout s'il est traité par le concepteur.
A+
Alex

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

1 semaine.

1 semaine que le problème a été soumis, que le bug vient forcément de Presta, que des marchands en prod éditent des factures qui relèvent du grand port'nawac, et pas une nouvelle ! Même pas un "on est sur le coup, on va tacher de résoudre ce problème majeur au plus vite". Rien !

D'ailleurs, vu le nombre de problèmes non traités dans le bug tracker, on se demande vraiment s'il y a un pilote dans l'avion. 29 lignes rouges, et ça ne semble déranger personne.

Je répète donc : ce bug est dramatique ! Je passe pour un charlot avec mes mails et factures qui expliquent que 10x3,70€ = 3,90 €. Mon produit est à 3,90€. Pourquoi ce 3,70 ?????

Mail envoyé le 23/09 par un client :

Bonjour
Je n’ose croire que vous le faites exprès, mais bien que c’est une erreur
Lisez ci dessous : 10*3,70=3,90.
Y’a rien qui vous choque ?


J'en ai encore 5 comme ça.

Serait-il possible que vous montriez un minimum de considération pour les utilisateurs de votre solution, ne serait-ce qu'en leur montrant au moins que vous êtes en vie ?
Link to comment
Share on other sites
antinoos Newbie

antinoos

Posted
Posted

En effet, il faut croire que la plupart des gens sur le forum, n'ont jamais appliqué les prix dégressifs. J'ai testé moi-même sur une install de base et c'est chaotique le résultat, imprévisible.
Espérons que la team résoudra ce problème très rapidement.

Link to comment
Share on other sites
créafée Newbie

créafée

Posted
Posted
C'est bizarre que ce soit un problème d'origine, calculer le montant d'une facture pour un sytème de e-commerce, c'est quand même le BA-ba (lire béaba :-)
ET nous ne serions pas les seules à avoir ce problème ...
Par ailleurs mois je n'ai pas de prix degressif.
Tchuss


Sauf erreur de ma part, les logiciels compta sont paramétrés pour faire calculer une somme (ht ou ttc, 2 ou 3 chiffres après la virgule) sur Presta c'est 6 chiffres après la virgule, autant dire un imbroglio "calculatoire"...
Personne, à moins d'être pharmacien ou micro chirurgien, n'effectue plus de calcul 6 chiffres après la virgule. Ceci génère ces incohérences sur les factures, et même s'il peut s'agir de quelques centimes, il y va de l'honnêteté du commerçant, voire de l'image même du e-commerce.
Sur Ciel le nombre de décimale est gérable, jusque 3 il me semble, il suffirait que la team trouve la solution pour "brider" presta à 2 ou 3 décimales après la virgule.
J'ai déjà posté à plusieurs reprises sur le sujet, sans réponse, sans même un espoir de début de solution.
Open source ne veut pas forcément dire, je t'offre un logiciel, et débrouille toi avec.. Il faudrait plus de réactivité sur les obligations légales des commerçants, même s'ils distribuent des " produits gratuits".
A bon entendeur...
Link to comment
Share on other sites
créafée Newbie

créafée

Posted
Posted
Je ne comprends pas trop ton raisonnement. Il me semble que plus les décimales sont précises, moins il y a de décalages issus de multiples calculs. En compta on arrive rapidement à des différences de quelques centimes.

d'accord avec toi mais ce n'est pas le souci du client... c'est le prix affiché qui doit être payé , pas le prix calculé par presta...
En fait c'est l'inverse qui se produit, plus tu as de décimales, plus les calculs sont faux, car le système, et le client ne voit que deux chiffres après la virgule...
Ainsi un article à 2 euros HT sera affiché à 2.392 soit si presta affiche les arrondis supérieurs: 2.40 , ce que voit le client...
Déduis 10% pour un tarif dégressif, çà donne un truc faux du genre: - 0.2392 = 2.1528, le client verra 2.15, alors que le bon total sera 2.16....
Édifiant, mais cela ne résout pas le problème et met le commerçant dans la catégorie des fraudeurs.... et l'expose à une contrôle...
Il est donc URGENT que la team réagisse......
Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Le mieux serait effectivement de s'aligner sur ce que le client voit. La loi française impose à un commerçant de faire payer le prix affiché.

Je viens de faire un test en désactivant les taxes. Là, tout se passe bien. Pas d'erreur dans les dégressifs. Le bug doit donc se cacher de ce côté. Est-ce uniquement lié aux décimales ? A vous de nous le dire....

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Heu... je ne sais trop que penser...

Généralement, je méfie un peu des solutions miracles qui viennent d'inconnus, mais je suis peut-être trop parano. C'est surement très bien.

En tout cas, ça vaudrait le coup qu'un dev de penche dessus pour nous donner le "feu vert, c'est clean".

Merci de t'être penché sur le problème !

Link to comment
Share on other sites
fch Newbie

fch

Posted
Posted

Il n'y a rien de miraculeux dans mon patch.
J'ai juste remonté l'algorithme de calcul et trouvé l'origine du problème.
Avec la version non patché, prestashop soustrait au prix unitaire normal le prix dégréssif correspondant à la quantité, que ce dernier soit exprimé en % ou en espéce.
Aucun problème dans le cas d'une remise en pourcentage, puisque la TVA n'entre pas en ligne de compte dans ce cas.
Par contre, dans le cas d'un prix dégrésssif en espèce sonnante et trébuchante, la TVA doit être prise en compte dans le calcul du prix final, ce qui n'est pas fait dans la version non patchée, d'ou le décalage constaté dans vos factures...
Mon patch ne fait que déduire du prix normal le prix dégressif augmenté de la TVA, si le prix dégressif n'est pas défini en pourcentage et si la TVA doit être prise en compte.
Enfin, j'avoue ne pas comprendre cette "méfiance" envers 10 lignes de code, mais tu dois avoir de bonnes raisons...

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Je voulais juste dire que Presta est deja tres complexe pour qui l'utilise depuis plusieurs mois et se tuyaute sur le forum. Dans le cas d'un patch, on conseille généralement d'attendre une confirmation de la compatibilité avec la solution de base.

Une variables modifiée ici ou là peut avoir des conséquences inattendues à des niveaux inattendus. Mais c'est vrai que là, ya pas de gros changements à faire. Je vais l'appliquer en local pour voir ce que ça donne.

Merci d'avoir proposé une solution, en tout cas. Vraiment !

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Je viens de faire les modifs (à la mano, sans passer par la maj automatique de tortoise)

Mon produit (rappel) :
x1 = 6€ TTC
x10 = -2.10 € TTC > 3.90x10 = 39 € TTC

Quand j'en mets 10 au panier, le panier affiche 34,88 € TTC
Page panier : PU = 2.92 € HT / Qté 10 / Total 34.88 € / Total TTC 34.88 €

Me serais-je gouré quelque part ? Sinon, ya un problème...

Link to comment
Share on other sites
fch Newbie

fch

Posted
Posted

Ton probleme vient du fait que que la réduction doit être exprimé en HT et non en TTC.
En fait, dans ton cas, tu déduis 2.10 de 5.02, qui correspond à ton prix HT (6 / 1.196).
Le calcul avec le dégressif est donc (5.02 - 2.10) * 10 = 29.2 HT, soit 34,88 TTC si on prend plus de deux chiffres derrière la virgule, donc le calcul de prestashop est bon avec ma correction.
Si tu veux arriver à 39 TTC pour 10 unités, il faut que tu fasses une réduction comprises entre 1.74 et 1.75, vu la gestion des arrondies faite par prestashop (bon courage pour trouver la bonne valeur, je te conseille la feuille excel pour faire le calcul avec au moins 6 chiffres derrière la virgule).

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Je te suis.

Donc, dans mes prix deg., je mets Qté 10 et valeur de réduc : 1.755855 (2.10/1.196)

Dans la page produit, j'obtiens : Prix deg > Qté 10 > -1,76 € (la DB enregistre 1.76 dans la table discount_quantity)
J'en mets 10 au panier : 38.95 €

D'une part, le fait que le prix deg s'affiche en HT sur le FO est problématique (pour le client). Il faudrait que ce soit affiché en TTC.
D'autre part, si je m'en tiens à une tricte conversion TTC > HT pour paramétrer mes dégressifs, le calcul du TTC à l'arrivée est erroné, puisque d'un côté, les prix de base sont enregistrés avec 6 décimales, et de l'autre les dégressifs sont enregistrés en arrondi à 2 décimales.


C'est pas gagné... :down:

Link to comment
Share on other sites
fch Newbie

fch

Posted
Posted

Je pense que la gestion des prix degressifs en montant a été implémentée un peu vite et que toute la problèmatique n'a pas été prise en compte.
Pour l'histoire du HT/TTC au niveau de la définition des dégressifs, il faudrait :
1) Tout d'abord à un niveau purement ergonomique décider si l'utilisateur saisi :
1) du HT
2) du TTC
3) du HT ou du TTC, comme dans la définition du produit (solution qui a ma préférence, mais qui nécéssite une refonte de l'interface car les
informations à saisir sont alors différentes dans le cas d'un dégressif en % et dans le cas d'un dégressif en montant).
2) Ensuite uniformiser la gestion des prixs dans prestashop pour régler une bonne fois cette histoire de nombre de chiffres derrière la virgule (qui posera toujours un problème, vue qu'en informatique l'arrondie est la régle pour les décimaux mais les comptables s'en arrange très bien).
Je peux très bien travailler sur ces deux points, mais ce n'est pas à moi de prendre ces décisions.
Par contre, pas de soucis pour fournir des patchs une fois les décisions prises.

Une solution temporaire peut être d'utiliser exclusivement les pourcentages, mais 21,23% de remise (par exemple) pour 10 pièces, ce n'est pas très vendeur...

Je peux aussi modifier mon patch pour que le calcul se fasse comme si le prix dégressif était en TTC, ce qui serait peut être le mieux.

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Oui. Le problème, c'est qu'on ne sait meme pas si la Team est en train de regarder ça, vu qu'aucun membre n'a encore donné ne serait-ce qu'un avis sur la question. Donc, comme d'hab : on ne saura rien !

Pour ma part, je pense que le mieux serait de modifier le système général de prix, et se coller à 2 décimales. Ensuite, s'attaquer aux fonctions secondaires qui dépendent de l'architecture de base, comme les prix deg.
Je le dis la mort dans l'âme, car je sais que ce process repousserait aux calendes grecques la résolution de mon problème qui dure, qui dure, qui dure.... Selon toute vraisemblance, vu la nature complexe des modifs à effectuer (tests à faire etc.), se serait corrigé dans une MAJ de Presta, donc pas avant plusieurs semaines.

J'aurais vraiment préféré qu'on trouve une solution aux prix deg. avant d'attendre une refonte du système de calcul des prix. Un rafistolage, ou meme juste un sparadra !

Maintenant, si tu crois pouvoir y faire quelque chose, tu te doutes bien que c'est pas moi qui vais t'en dissuader :cheese: Tu aurais ma plus grande reconnaissance, maintenant et à travers les ages !

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Je ne me suis pas du tout penché sur l'architecture de Presta de ce côté là, donc difficile de savoir ce que tu peux faire.

Mais il faudrait que
* les prix deg s'affichent en TTC sur le FO
* que les prix unitaires soient corrects dans Panier/factures/Mes commandes
* et de façon générale que tous les calculs soient corrects et cohérents dans Panier/factures/Mes commandes

Bref, ce que presta devrait normalement faire à la base, quoi.

Merci à toi

Link to comment
Share on other sites
fch Newbie

fch

Posted
Posted

Les prix degressifs en TTC sur le FO, c'est facile.
Un prix unitaire correct, également, surtout en stockant un TTC dans les prixs degressifs.
Par contre, faire en sorte que tout les calculs soient corrects, c'est une autre paire de manche, du moins pour le moment, d'autant qu'il n'y a pas l'ombre de la queue d'un test unitaire dans prestashop, et de plus, ca impliquerait certainement des remaniements profonds et des décisions que je n'ai pas à prendre.

Link to comment
Share on other sites
marty69 Newbie

marty69

Posted
Posted

Bonjour à vous,

Désolé pas de solution à vous apporter, mais je souhaitais néanmoins venir vous soutenir et appeler la team à se pencher sur ce pb qui me parait primordial... en tout cas donner un petit signe de vie ce serait déja chouette.

Ceci dit à mon avis il faudrait déja poster le pb dans le bug tracker si ce n'est déja fait.

Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted

Bonjour a tous,

Premierement je ne comprends pas pourquoi vous vous obstinez a dire que la team ne vous repond pas alors que Zendik/Patric vous a repondu des le lendemain de la creation du topic et a continue a participer (meme si c'etait pour insister sur le BT).

Deuxiemement nous sommes au courant de ces problemes d'arrondi, et vu la structure de PS ce n'est pas si simple que de tout reparer sans effet de bord.
Nous reflechissons donc a la meilleure solution.

Enfin juste pour confirmer la discussion c'est bien a cause de a la precision de nos calculs que ce font ces erreurs d'affichage.

Link to comment
Share on other sites
fch Newbie

fch

Posted
Posted
Bonjour a tous,
Enfin juste pour confirmer la discussion c'est bien a cause de a la precision de nos calculs que ce font ces erreurs d'affichage.


Non.
Votre calcul est faux lorsqu'il y a un prix dégressif en montant et non en pourcentage, puisque les taxes ne sont pas prises en compte.
Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted
Bonjour a tous,

Premierement je ne comprends pas pourquoi vous vous obstinez a dire que la team ne vous repond pas alors que Zendik/Patric vous a repondu des le lendemain de la creation du topic et a continue a participer (meme si c'etait pour insister sur le BT).

Deuxiemement nous sommes au courant de ces problemes d'arrondi, et vu la structure de PS ce n'est pas si simple que de tout reparer sans effet de bord.
Nous reflechissons donc a la meilleure solution.

Enfin juste pour confirmer la discussion c'est bien a cause de a la precision de nos calculs que ce font ces erreurs d'affichage.


Matthieu... Je comprends fort bien que chacun défende sa "team", mais là, c'est non.
Personne depuis le 22 septembre n'a daigné donner un avis technique ou le moindre signe d'intérêt pour cette fonction de base buggée.

J'ai lancé plusieurs appels au secours fort justifiés et personne n'a acté le problème. Aucune réponse sur le bug tracker non plus. Ce bug a été classé "Confirmed" seulement aujourd'hui.

Faire du gratuit, c'est toutefois avoir des clients, et les clients, on les informe ! Vous faîtes de l'open source, alors assumez votre business model, et soyez une société normale, c'est à dire réactive. C'est trop facile d'endormir les bug ou les problèmes qui vous casse les pieds. Je veux bien, je ne gère pas Amazon, mais mes clients, je leur réponds toujours dans la journée.

Je vous rappelle que ce forum est en accès public, et que tous les e-commerçants en quête d'une plateforme écument d'abord les forums de chaque solution avant de faire leur choix. Sur un topic comme celui-ci on voit juste qu'en cas de problème majeur, les utilisateurs peuvent être totalement livrés à eux-mêmes.

Parce que soyons honnêtes : suis-je vraiment censé croire qu'aucun dev de la team n'a lu ce topic de 4 pages depuis les 2 dernières semaines ? Forcément, des dev l'ont lu, et on choisi de faire les morts. C'est juste lamentable. Et pas besoin de diriger un service après-vente pour deviner que ça fait fuir une partie de ceux qui auraient pu choisir Presta.

Comme je l'ai déjà dit plus haut, je ne demandais rien de plus qu'un signe de vie concernant ce problème (et pas seulement pour m'entendre dire d'aller le poster ailleurs). Le plus frustrant, c'est de vous voir répondre à d'autres topic du genre "j'ai le module carousel qui fait planter mon theme". Chaque problème est important, certes, mais entre ça et "toutes nos factures sont erronées", faut quand même savoir hiérarchiser.

Attention, je ne crache pas dans la soupe. Presta est une solution fantastique, et je l'ai choisi pour ça. J'en ai d'ailleurs souvent fait l'éloge sur le forum et ailleurs. Mais quelque soit le produit/service ou le prix que l'on propose, on se doit d'informer !

Si vous "réfléchissez à la meilleure solution", dites-le ! On est pas extralucides et on peut pas le deviner.

Maintenant, je me répète, mais je n'ai pas le choix : quand et quelle solution comptez vous apporter à des prestashoppers en prod qui éditent des factures surréalistes et qui en perdent forcément chaque jour des clients ?
Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted
Matthieu... Je comprends fort bien que chacun défende sa "team", mais là, c'est non.
Personne depuis le 22 septembre n'a daigné donner un avis technique ou le moindre signe d'intérêt pour cette fonction de base buggée.

Nous ne sommes plus beaucoup sur le developpement de la solution (principalement Philippe et moi-meme) et ne pouvons donc pas forcement traiter tous les bugs report le jour ou ils sont postes.
Et meme si une semaine et demi vous semble tres long (et je comprends tres bien qu'en tant qu'utilisateur ca soit ce que vous ressentiez), pour nous ce n'est pas beaucoup de temps a consacrer a "trier" les bugs.
Il faut bien comprendre que lire les bugs du jour 1 le jour 1 c'est facile, mais les resoudre peut tres bien prendre 3 jours. Et pendant ces 3 jours de nouveaux rapports de bug arrivent, et ainsi de suite.
On arrive donc vite a des delais en semaines comme c'est le cas ici.


J'ai lancé plusieurs appels au secours fort justifiés et personne n'a acté le problème.

Je n'ai personnellement pas eu trace de ces appels auparavant, sinon j'aurai reagi comme je le fait habituellement.

Aucune réponse sur le bug tracker non plus. Ce bug a été classé "Confirmed" seulement aujourd'hui.

Oui, j'ai fait une passe sur les rapport hier et il etait dans le lot.


Faire du gratuit, c'est toutefois avoir des clients, et les clients, on les informe ! Vous faîtes de l'open source, alors assumez votre business model, et soyez une société normale, c'est à dire réactive.

Ce n'est pas nous "dev" qui decidons du temps que nous pouvons consacrer a "l'OpenSource", et je suis le premier a dire qu'ils sont trop faible.
Mais ils s'ameliorent, et meme si notre communication est tres lente a s'ameliorer, on commence enfin a voir quelques choses se mettre en place.


C'est trop facile d'endormir les bug ou les problèmes qui vous casse les pieds.

Je n'ai jamais rien endormi, au contraire, je suis plutot du genre a mettre a la lumiere les problemes de PrestaShop.
C'est moi par exemple qui ai mis en place le nouvel affichage HT/TTC des prix de la 1.2 demande depuis longtemps.


Je veux bien, je ne gère pas Amazon, mais mes clients, je leur réponds toujours dans la journée.

Eh bien nous ne pouvons pas repondre aux 400 messages quotidiens de la communaute.


Je vous rappelle que ce forum est en accès public, et que tous les e-commerçants en quête d'une plateforme écument d'abord les forums de chaque solution avant de faire leur choix. Sur un topic comme celui-ci on voit juste qu'en cas de problème majeur, les utilisateurs peuvent être totalement livrés à eux-mêmes.

Je suis personnellement tout a fait de votre avis, le probleme est qu'encore une fois, en tant que "dev" nous ne pouvons rien faire.


Parce que soyons honnêtes : suis-je vraiment censé croire qu'aucun dev de la team n'a lu ce topic de 4 pages depuis les 2 dernières semaines ?

Patric m'a fait remonte le lien du topic avant-hier soir, je l'ai donc consulte hier apres-midi pour ma part.
Pour les autres je ne sais pas.


Comme je l'ai déjà dit plus haut, je ne demandais rien de plus qu'un signe de vie concernant ce problème (et pas seulement pour m'entendre dire d'aller le poster ailleurs). Le plus frustrant, c'est de vous voir répondre à d'autres topic du genre "j'ai le module carousel qui fait planter mon theme". Chaque problème est important, certes, mais entre ça et "toutes nos factures sont erronées", faut quand même savoir hiérarchiser.

Tout depend de depuis ou ce membre provient, nous ne faisont pas toujours le tri par priorite via les nom de topics, nous venons parfois du Bug Tracker, parfois d'un autre post, ou tout simplement de l'aprecu rapide "Les 10 derniers posts du forum" (visible dans la colonne de droite quand on est sur le Bug Tracker).


Si vous "réfléchissez à la meilleure solution", dites-le !

C'est ce que je viens de faire :P


Maintenant, je me répète, mais je n'ai pas le choix : quand et quelle solution comptez vous apporter à des prestashoppers en prod qui éditent des factures surréalistes et qui en perdent forcément chaque jour des clients ?

Desole je n'avais pas vu la question.
La decision n'est pas mienne mais voici les deux possibilites :
1. On sort une 1.2.5 avec ce correctif
2. Le correctif sera disponible dans la version 1.3 alpha 1 et donc malheureusement accessible pour les boutiques en production seulement avec la 1.3 finale
Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Les lecteurs de ce topic se feront leur opinion.
Perso, je ne peux pas croire que depuis si longtemps, personne de la team n'a vu ou n'a jugé opportun de faire remonter le problème. Maintenant l'essentiel, c'est que ça se résolve durablement.

fch : je viens de tester en local, et ça semble fonctionner !!!!
Panier > OK
Facture > OK
Mes commandes > OK
total_products > OK
Affichage prix deg. en FO > OK

MEEEEERCIIIIII !!

J'attends un moment de flottement à la boutique pour faire la modif online.
Maintenant, va falloir reprendre tous les champs total_products de la table Orders et les corriger 1 par 1. Et vous ? Bon WE en perspective ?

Link to comment
Share on other sites
fch Newbie

fch

Posted
Posted

De rien :).

Content d'avoir pu dépanner.

Je persiste auprès de la team : le probleme relatif à ce topic n'est pas du uniquement à vos problèmes d'arrondie, vous avez un probleme dans votre algorithme de calcul du prix final, car la tva n'est pas prise en compte lors d'un prix dégréssif indiqué autrement qu'en pourcentage, alors qu'elle le doit !

Odjavel, il doit y avoir moyen de faire un script pour recalculer tes totaux.

A+

Link to comment
Share on other sites
Odjavel Newbie

Odjavel

Posted
Posted

Odjavel, il doit y avoir moyen de faire un script pour recalculer tes totaux.


Oui, je vais tacher de le pondre, mais je dois faire attention avec les éventuels frais de ports et autres, qui ne doivent logiquement pas apparaitre dans total_products.
Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted

Je persiste auprès de la team : le probleme relatif à ce topic n'est pas du uniquement à vos problèmes d'arrondie, vous avez un probleme dans votre algorithme de calcul du prix final, car la tva n'est pas prise en compte lors d'un prix dégréssif indiqué autrement qu'en pourcentage, alors qu'elle le doit !


J'avais bien lu dans vos deux premier posts ;-)
Link to comment
Share on other sites
Arnaud06 Newbie

Arnaud06

Posted
  • Author
Posted

Bonjour,

Je ne veux pas casser l'ambiance, mais le problème de départ n'était pas les calculs sur prix degressifs. Regardez mon jpeg, le pbm est bien plus inquiétant, il s'agit d'une somme toute bete, et l'erreur est de plus de 200 euros dans le total... et pas quelques centimes

De plus aujourd'hui encore un problème, cette fois avec les bons de réduction, qu'un client peut créer à volonté... super ! Bref j'ai mis un autre post.

Je commence à me posez des question quand même : cette solution est géniale quand on débute, mais à l'usage, c'est parfois un peu inquiétant.

Qu'en pensez vous ?

Arnaud

Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted

Bonjour Arnaud,

Je suis navre mais je ne vois vraiment pas ou sont ces 200 euros manquant sur votre screenshot.
Etes-vous sur que vous avez bien compris le fonctionnement de la ventilation des taxes ?
La ventillation affiche seulement les produits taxes.
Hors le premier de votre liste ne l'est pas.
On a donc bien : 238.30 euros + 1080.94 euros = 1339.24 euros comme indique sur la capture.

Link to comment
Share on other sites
créafée Newbie

créafée

Posted
Posted
Bonjour Arnaud,

Je suis navre mais je ne vois vraiment pas ou sont ces 200 euros manquant sur votre screenshot.
Etes-vous sur que vous avez bien compris le fonctionnement de la ventilation des taxes ?
La ventillation affiche seulement les produits taxes.
Hors le premier de votre liste ne l'est pas.
On a donc bien : 238.30 euros + 1080.94 euros = 1339.24 euros comme indique sur la capture.


Bonjour,
Peut-être serait il utile d'avoir ou d'indiquer le fonctionnement des TVA ( une TVA à 19.6 par défaut, à modifier le cas échéant) .
Toutefois, le problème de calcul existe bel et bien... le système calcule à 6 chiffres après la virgule et affiche 2 chiffres après la virgule, il y a forcément des erreurs........ j'ai une centaine de fausses factures à ce jour, prions le dieu fisc , d'ignorer les pauvres petits e-commerçants qui n'ont pas forcément les moyens de s'offrir un développeur, et les mettre à l'abri d'un contrôle lol
PS il est ou le SCREENHOST, et c'est quoi un SCREENHOST ?
Link to comment
Share on other sites
Arnaud06 Newbie

Arnaud06

Posted
  • Author
Posted

Bon il faut aussi savoi avouer ses erreurs, en l'occurence le problème était bien de mon côté : j'avais oublié de remplir le champ TVA sur ce produit...
Toutes mes excuses à la TEAM, en même temps je suis plutot content de savoir que c'est une erreur de ma part, qu'un problème de fiabilité.

J'espère qu'il en sera de même pour mon pbm de bon de réduction...

Arnaud

Link to comment
Share on other sites
Fabrice Newbie

Fabrice

Posted
Posted

ouaip, ben moi, j'ai un problème presque similaire ce soir.

c'est pas fini les gars...

produits unitaires : 199 euros
dégressif : remise 10 euros sur unité
soit 189 X 2 = 378
mais le soft me calcul = 368 euros !! première erreur - mais attendez... y'a mieux.

donc, à priori, il a été déduit 2 fois le montant de la remise :
(199-10)€ttc X 2 - 10 €ttc : 368 € Ttc

port : 5,90 €ttc

total soumis à paypal : 355,50 euros TTC
je ne vois pas comment il a trouvé ce résultat (différence de 12,50 euros avec le total faussé, et 22,50 !!!! avec le résultat attendu !)

évidemment, paypal n'a pas aimé. et retourne une erreur.

Franchement, 2 erreurs sur des calculs qui devraient être checkés plutôt deux fois qu'une, ça peut pas mettre de bonne humeur. UNE SOLUTION ?

parce que perdre près de 8% à chaque transaction (mais seulement lorsqu'il y a des prix dégressifs...) ça le fait pas.

tks !

Link to comment
Share on other sites
Fabrice Newbie

Fabrice

Posted
Posted

j'ai mieux encore !!!
en appliquant une remise en pourcentage, soit ici 5%,
1 produit 199 euros - remise 5% dès 2 produits

j'obtiens ça :
après remise :
1 produit : 189 euros (soit la remise déduite alors qu'il ne devrait la faire qu'à partir de 2 ex!!!)
2 produits et plus : 180 € donc 2 x la remise !!!

à noter : je suis en affichage HT et TTC
le panier donne bien pour 2 produits : 370 euros, soit encore une fois un résultat incohérent... ce devrait être soit 2 x 189 soit 2 x 180
ici, nous avons 185 / unité
à n'y plus rien comprendre...

Link to comment
Share on other sites
Fabrice Newbie

Fabrice

Posted
Posted

bon, j'avance : j'essaie de comprendre la logique (!) de calcul.
regardez les écrans joints. prix de base 199 €ttc

pour résumer : le soft calcul un cumul des remises.
ainsi, pour 4 ex, il calcul une remise de 5% d'abord puis cumul une autre remise de 7 % !!!
ce qui est aberrant !!
et regardez le résultat avec des tranches 1-2 et 4
c'est un peu le bordel !

12709_SNnUJIe5QyMRSdzmJEg1_t

12710_iLiFMtHKPRATaev7kXeW_t

Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted

Vous pourrez trouver la reponse officielle a ce probleme ici :
http://www.prestashop.com/forums/viewannounce/30565_6/

Et pour les non anglophones, en gros ca dit qu'on est au courant du probleme, ca l'explique en detail pour les personnes qui ne sont pas au courant et ca annonce comment on va regler ca :
Deux possibilites : soit les details produits en HT soit en TTC, mais uniquement un des deux, mais avec tout de meme les deux totaux (HT et TTC) avec en plus la ventilation des taxes.
Il y aura egalement la possibilite de regler ca par groupe de client.

Edit : Et ca fini par dire que ca ne sera pas disponible avec un patch a la maniere des versions 1.2.3, 1.2.4 mais dans une release version beta dans un premier temps, histoire de laisser le temps a tout le monde de tester. Puis quand on sera sur que le probleme n'a pas d'effets de bord une 1.2.5 sortira pour mettre a jour vos boutiques en ligne.

Link to comment
Share on other sites
Eric Lavoisier Newbie

Eric Lavoisier

Posted
Posted

Ce n'était pas sur prestashop mais sur une autre solution ecommerce, j'ai eu un problème de ce type avec les codes promos pour un de mes clients. La réduction était ventilée à concurrence du nombre d'article sur le Montant HT unitaire de chaque article. Puis en rajoutant d'autres articles, les réductions devenaient totalement farfelues. Bref ce fut assez exotique comme bug.

Fin de la paranthèse perso.

Et bon courage à tous !

Link to comment
Share on other sites
Mephivio Newbie

Mephivio

Posted
Posted

Désolé Matthieu, le bug est toujours la pour moi en dépit de ton fix 1430.
en effet, j'ai un différentiel de 2 cts d'euros par produit remisé.... pas au niveau du paiement qui lui est heureusement correct, mais au niveau de la facture PDF !
A suivre ...


ps: le bug vient du fichier PDF.php - La facture affiche dans mon exemple 129.13 eur ttc alors que le paiement effectué qui lui est correct est de 129.11 eur ttc.
je suis repassé au PDF.php du précédent svn et les choses s'améliorent presque....
me total TTC est correct mais le bug est un pb d'arrondi sur le montant HT et donc après cela déraille.
je m'explique :
mon produit a une valeur de 119.95 eur HT
il est en promo avec une décote de 10% ->soit 107.955 eur HT -> 129.11 TTC
or, prestashop arrondi à 107.96 ht -> 129.12 TTC, ce qui bien sur donne une erreur sur la facture !
la facture indique prix HT 107.96 et prix TTC 129.11 !!!!
j'attends donc le retour des autres testeurs et les prochaines modifs de la team !!!

Est ce encore et toujours cette fameuse discussion liée à la fonction number_format ? alors que la fonction donnerait de meilleurs résultats ??? (voir sujet : http://www.prestashop.com/forums/viewthread/13380/rapports_de_bugs/probleme_au_niveau_de_la_facture)

Link to comment
Share on other sites
Mephivio Newbie

Mephivio

Posted
Posted

Bon, je viens de modifier mon order.php
il semblerait que les résultats soient désormais conformes !


$row['product_price_wt'] = money_format('%8.2i',$row['product_price'] * (1 + ($row['tax_rate'] * 0.01)));
$row['total_wt'] = $row['product_quantity'] * $row['product_price_wt'];
$row['total_price'] = money_format('%8.2i',$row['total_wt'] / (1 + ($row['tax_rate'] * 0.01)));
$row['total_wt'] = money_format('%8.2i',$row['total_wt']);



Qu'en pensez vous ?


ps: on peut utiliser la fonction money_format pour les fichiers product.php et PDF.php

Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted
Désolé Matthieu, le bug est toujours la pour moi en dépit de ton fix 1430.
en effet, j'ai un différentiel de 2 cts d'euros par produit remisé.... pas au niveau du paiement qui lui est heureusement correct, mais au niveau de la facture PDF !

Arf, c'est justement la facture PDF (dans un premier temps) que j'ai rectifie.
Est-ce que c'est possible d'avoir un screen de ce PDF (rev 1430) ?

le bug vient du fichier PDF.php - La facture affiche dans mon exemple 129.13 eur ttc alors que le paiement effectué qui lui est correct est de 129.11 eur ttc.
je suis repassé au PDF.php du précédent svn et les choses s'améliorent presque....
me total TTC est correct mais le bug est un pb d'arrondi sur le montant HT et donc après cela déraille.
je m'explique :
mon produit a une valeur de 119.95 eur HT
il est en promo avec une décote de 10% ->soit 107.955 eur HT -> 129.11 TTC
or, prestashop arrondi à 107.96 ht -> 129.12 TTC, ce qui bien sur donne une erreur sur la facture !
la facture indique prix HT 107.96 et prix TTC 129.11 !!!!

Cela me semble correcte.
La version SVN corrige l'affichage du PDF mais pas les calculs effectues sur les commandes deja validees.
Il faut donc mettre de cote ce que le client a paye ou ce qu'affiche le BO pour juger seulement de la validite de l'affichage de la facture.
Une fois que cela sera correct, et seulement a ce moment la, les calculs seront egalement corriges (donc pour les futures commandes).
Le screenshot de ce PDF est donc vraiment necessaire.


Est ce encore et toujours cette fameuse discussion liée à la fonction number_format ? alors que la fonction donnerait de meilleurs résultats ??? (voir sujet : http://www.prestashop.com/forums/viewthread/13380/rapports_de_bugs/probleme_au_niveau_de_la_facture)

Malheureusement c'est bien plus complique que cela...
Link to comment
Share on other sites
  • 2 weeks later...
patgame Newbie

patgame

Posted
Posted

slt a tous
moi aussi nouveau sur ps bcp de fonctionnalités sans faire de redites c'est vrai aussi que la gestion des remises bon d'achat et transport n'est pas a la hauteur de cet excellent programme par ailleurs
pour votre probléme a premiére vue c'estt l'arrondi qui fait des siennes ça doit être simple a rectifier ça par le team

je vois QUE VOUS UTILISEZ DEPUIS UN MOMENT PS TRES MAL DOCUMENTE EN PROFONDEUR

j'aimerais vous poser une question concernant la méthode de calcul des remises et bon d'achat
admettons en cas d'école qu'un client cumul plusieures remise par exple
un bon inscription news lettrer +un parrainage +une prime fidélite et l'article du jour en promo admettons 10 % du prix que l 'on va fixer a 100 € et le tran,sport a 25 €
ce type de remises en cascade n'est pas rare
si j'ai bien tout compris tout ça va de défalquer du prix produit plus transport ( ça c du grand n'importe quoi mais passons )
ensuite les remises ou bon d'achat vont être défalqués comment ? sur les 125 de départ j'espere que non ou sur une cascade ?? c'est le grand brouillard pour les calculs
merci a vous tous de m'expliquer le fonctionnement de l'os pour cette facturation
mais le pognon c'est un peu le nerf de la guerre surtout en cas de marge sérrée

Link to comment
Share on other sites
patgame Newbie

patgame

Posted
Posted

j'ai refait aussi les calculs (j'utilise la 1.2.5 )
donc en % prix dégressif ça fonctionne je suis en prix ttc
bien sur subsiste le problème arrondi donc le prix ht et la taxe en valeur est fausse pas le total tva
peu de clients refont ce calcul il n'en demeure pas moins vrai que c'est un bug et pas un problème de fonctionnalité c'est clair et que les calculs doivent être juste respect du client et loi
de plus il serait normal et plus parlant que le prix de l'unité change ds produit pour refléter ce nouveau prix

pour le dégréssif en montant effectivement PS multiplie la remise en montant par le nombre de pièces du dégréssif pas normal mais bon il suffit de le savoir tjrs problème arrondi taxe

il n' y a plus qu ' attendre la version 1.3 moi je serais pas en prod avant plusieures semaines ( printemps peut être) donc pas trop grave mais il est vrai que pour les marchands en prod c'est dramatique niveau compta ,fiscal et surtout confiance client je crois que la team est au courant et que ça va s'arranger ils sont pris entre le marteau et l'enclume les modules payants et le libre pas facile comme équation les jpournées n'ont que 24 h
mais ils vont trouver se sont des bons et l' os est jeune
le système de mise a jour pas terrible non plus voir phpboost c'est une équipe d'étudiant qui a fait ce cms très bon ( j ai pas d'action chez eux ) directement sur le soft mise a jour théme ,noyau et module c'est le top donc cette équipe de ps en vrai professionnels est capable de nous pondre ça
on doit passer son temps sur la gestion de la boutique et l'analyse du trafic on est pas forcement développeur la il faut drôlement mettre les mains ds le cambouis ou ..;payer c pas tjrs possible mais ce soft est relativemennt complet et très relativement simple il ne s'agit pas de jeter le bébé et l'eau du bain c'est un formidable travail
moi j'ai confiance en l'équipe mais en lisant les forums il y a de quoi avoir peur espérons que ces problèmes facturation transport et loi chatel vont être réglés au plus vite ( jai bien lu que "ce soft a une portée internationale et que l'on ne peut pas s'adapter a chaque législation" ce qui n'empêche pas que légalement il doit être en conformité avec la législation locale! en dev je suis une bille mais en commerce je touche un tout petit peu quand même )

moi j'attends la suite et je reste confiant j'ai misé, aprés recherche sur PS c'est surement pas la voie la plus facile mais je joue très gros sur ce coup

une réponse de la team sur mon post méthode de calcul dans le gal m'obligerait et me permettrais d'arrêter une stratégie de calcul

bonne soiréé a tous et une pensée pour les dev qui en prennent plein la G mais qui aime bien chatie bien non lol

mais bon je suis sur le coup et je découvre petit a petit

Link to comment
Share on other sites
vins Rookie

vins

Posted
Posted

Bonjour,
J'expérimente à mon tour un problème de facturation lié au bug sur les prix dégressifs !!!
J'ai vu que Mathieu avait apporté une modif. sur le fichier PDF.php (#1430)... quels autre fichiers faut-il updater pour régler le problème ? J'ai notamment vu que la classe Group.php devait elle aussi être mise à jour... y'en a -til d'autres ?
Merci pour vos réponses...

Link to comment
Share on other sites
vins Rookie

vins

Posted
Posted

HELP !!!
J'ai récupéré le fichier PDF.php de la SVN ( #1430) et l'ai intégré à ma version (1.2.4) en production (il a fallut que j'ajoute une fonction celif dans ma classe Tools.php pour que cela fonctionne mais bon...) mais comme le montre l'image le nouveau calcul est faux !
Aujourd'hui(hui mes factures avec des prix dégressifs définis en % sont correctes à priori, les autres définies avec des prix dégressifs en -x€ sont fausses...
La team pourrait-elle nous nous donner une méthode pour corriger le problème ?
Merci de consulter l'image jointe pour s'apercevoir que cela ne fonctionne tjs pas même avec la correction... à moins que je m'y sois mal pris !
Merci pour votre aide car les clients et le comptable ne sont pas très contents !

13884_dt8gTrvkqxvzBupQkvzb_t

Link to comment
Share on other sites
Mephivio Newbie

Mephivio

Posted
Posted

idem.
le bug est toujours la...
un produit dont la valeur est 152.684 est arrondi sur la facture 152.69 (!!!)
je précise que j'utilise la dernière version de PS , couplée du dernier SVN (1478)

Autre bug plus génant encore, un bon de réduc que j'ai supprimé réapparait comme autorisé lors de l'achat par une personne avait reçue ce bon de réduc par le passé lorsqu'il était autorisé. je me suis ainsi retrouvé avec une commande validée utilisant ce bon de réduction pourtant supprimé...

Suis je le seul dans ce cas ou il y a encore des gros bugs masqués ????

D'autres part, si je ne me trompe, Prestashop part du produit TTC pour calculer le prix HT en arrondissant dans tous les angles, alors que normalement pour un business commercial, il faut partir du HT vers le TTC .... ce qui génère obligatoirement des pb d'arrondie !

Cordialement

Link to comment
Share on other sites
Mephivio Newbie

Mephivio

Posted
Posted

bon pour les arrondies la solution serait de revoir les fichiers PDF.php et order.php
il faut s'intéresser aux arrondies de la fonction ceilf

Dans mon cas, j'utilise une boutique mixte en HT et TTC
Dans le schéma Prestashop, on part du TTC pour calculer le HT donc parfois , pb d'arrondis

j'ai constaté qu'en modifiant par exemple le calcul sur 4 chiffres (PDF.php) pour la TVA, elle redevenait correcte
exemple de code modifié :

$vat = Tools::ceilf($priceBreakDown['totalsProductsWithTax'][$tax_rate] * $tax_rate / 100, 4);



Il en est de même pour les produits avec un calcul sur 3 chiffres : à titre d'exemple

$unit_without_tax = Tools::ceilf($product['product_price'], 3);



Une piste (provisoire) de réponse au problème ?
Dans tous les cas cette rustine fonctionne en attendant la Team sur ce sujet....

Link to comment
Share on other sites
fch Newbie

fch

Posted
Posted

J'ai mis à jour mon patch par rapport à la version 1485 du svn.
Il est disponible à l'adresse http://www.noparking.net/sites/all/files/prestashop/patches/prestashop.svn.1485.patch.

Rappel : il corrige le problème du cacul du prix d'un produit lorsque des prixs discounts sont exprimés en MONTANT pour le produit, il ne résoud pas les problèmes d'arrondie qui sont globaux à prestashop et qui peuvent impacter le calcul final du prix d'un produit, vu que le montant du discount est stocké avec seulement deux chiffres derrière la virgule dans la base de données de prestashop.

A+

Link to comment
Share on other sites
  • 2 weeks later...
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted

Bonjour a tous,

Tout d'abord toutes mes excuses pour le temps de reponse.
Je surveillais le topic de pres apres ma derniere reponse, mais apres 8 jours sans reponse j'ai arrete la veille et comptais sur l'email de notification de reponse (qui ne fonctionne apparement pas).

Donc me revoila ;-)

Ensuite, j'apprecierai que patgame et votreprestashop ne "polluent" pas la discussion avec des questions comme "comment sont calcules les remises ?" ou encore "le bug des prix degressifs n'est toujours pas regle". (et encore moins a "J'ai recupere quelques fichiers SVN que j'ai injecte dans ma 1.2.4, ca fonctionne pas Help !).
Ce topic s'adresse uniquement au probleme d'arrondi du aux prix HT et TTC.

Merci de creer de nouveaux topics pour ce qui concerne les autres sujet :P

Pour repondre a citrix, nous travaillons actuellement sur le probleme, et la solution a deja ete trouvee.
Un commit SVN ne devrait pas tarder a venir corrigeant tout cela.

Pour rappel, mon premier commit visait a corriger exclusivement les erreurs d'affichage de la facture PDF, et ne devait pas correspondre aux montants afficher cote FO ou BO ! Apparement mon post du 19 octobre n'etait pas assez clair.

Le prochain commit SVN (en rapport avec ce bug) changera l'integralite des affichages des prix des produits sur le Front Office. De maniere a ce qu'ils correspondent a ceux (deja corriges) de la facture PDF.

Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted

Bonjour a tous,

Comme promis je viens de commit la correction des prix.
Ceci devrait corriger l'affichage des prix FO, BO et PDF.
Cela change egalement la methode de calcul de TOUS les prix de prestashop.
Je me permet donc de vous recommander encore une fois de ne PAS utiliser la version SVN (ou pire une version hybride SVN/1.2.5) en production.

Merci d'utiliser le bug tracker pour repporter les problemes que vous rencontreriez suite a cette mise a jour.

PS : petite precision, il n'est plus possible de choisir "globalement" l'affichage (ainsi que le calcul) des prix de la boutique (HT ou TTC).
Cela se passe desormais du cote des groupes d'utilisateur (le groupe "default" ayant bien entendu herite de la valeur de votre ancienne configuration "globale").
PS2 : cette modification est (pour le moment) retro-active ! Si vous tentez d'utiliser la version SVN avec d'anciennes commandes, le resultat risque d'etre errone.
La non retro-activite sera faite ulterieurement (mais biensur avant la sortie de la 1.3 finale ;-))

Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted
Et il faudrait également modifier le titre du topic, beaucoup plus large que le probleme d'arrondie...

C'etait un oubli, ca vient d'etre corrige ;-)

PS : merci de ne PAS poster en francais dans le bug tracker
Un tres bon exemple ici, les non-francais ne peuvent pas profiter de votre patch etant donne qu'ils ne comprennent rien a ce que vous dites.
Link to comment
Share on other sites
Mephivio Newbie

Mephivio

Posted
Posted

Le SVN 1524 devait corriger les problèmes d'arrondie.
J'ai appliqué le dernier SVN sur le backup d'une boutique ...

Hélas, ce n'est pas gagné !
Les prix passent à 1 ou 2 ou 3 ou 4 euros !!!
certains sont encore bons...
Mais pour les autres.... j'ai vérifié la base, les prix sont toujours la et corrects....
J'ai restauré tous les fichiers du SVN1524 à l'état du SVN1523 et tout remarche....

c'est pas encore pour cette fois ...
Cordialement

A confirmer via d'autres testeurs bien entendu !

Link to comment
Share on other sites
Matthieu Biart Newbie

Matthieu Biart

Posted
Posted
J'ai appliqué le dernier SVN sur le backup d'une boutique ...


Pourrions-nous savoir comment vous avez procede pour faire cette "application" ?



Mais pour les autres.... j'ai vérifié la base, les prix sont toujours la et corrects....


Cette modification change la methode de calcul et d'affichage, elle ne modifie donc pas le contenu de votre base de donnee.


Une petite remarque en passant : Le theme par defaut a subit ces changements lui aussi, donc merci de faire vos tests avec celui-ci (a non pas avec un theme personnalise).
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...