Surprise surprise, j'ai voulu vendre un objet en quantité non entière, et bien c'est pas possible.
(ici un abonnement au prorata temporis, mais ça pourrait être une prestation horaire au temps passé, de la farine au kilo etc…)
Cause : sur les tables spip_paniers_liens et spip_commandes_details le champs de quantité est de type
'int not null default 1' pour les paniers
'int not null default 0' pour les commandes
(on notera la subtile incohérence sur la valeur par défaut)
A moins que je n'ai raté quelque chose, il me semble que c'est une grosse erreur de conception très limitante.
Sauf objection expresse, je vais donc être obligé de patcher tout ça avec upgrade à la clé et revue de code pour essayer de ne rien casser et pas se retrouver avec des arrondis pénibles.
Je pensais mettre un decimal(8,3) ce qui permet une représentation des nombres entre 0 et 99999.999 (j'omets la partie négative, symétrique qui ne nous interesse pas trop ici), avec donc une précision de 3 décimales.
Peut-être vaut-il mieux brancher les trunks actuels et faire un saut de version majeure sur cette évolution, pour éviter les dégats et permettre de tester intensivement avant upgrade en production chez les utilisateurs ?
Ou bien véto catégorique, car le monde est entier ou n'est pas ?
Je vais réfléchir dans cette direction, quitte à faire évoluer les plugins là où ça pourrait coincer en mettant des fonctions surchargeables qui vont bien.
--
Cédric
Cédric Morin a écrit :
Toc, toc badaboum me revoilà !
Surprise surprise, j'ai voulu vendre un objet en quantité non entière,
et bien c'est pas possible.
(ici un abonnement au prorata temporis, mais ça pourrait être une
prestation horaire au temps passé, de la farine au kilo etc…)
Cause : sur les tables spip_paniers_liens et spip_commandes_details le
champs de quantité est de type
'int not null default 1' pour les paniers
'int not null default 0' pour les commandes
(on notera la subtile incohérence sur la valeur par défaut)
A moins que je n'ai raté quelque chose, il me semble que c'est une
grosse erreur de conception très limitante.
Sauf objection expresse, je vais donc être obligé de patcher tout ça
avec upgrade à la clé et revue de code pour essayer de ne rien casser et
pas se retrouver avec des arrondis pénibles.
Je pensais mettre un decimal(8,3) ce qui permet une représentation des
nombres entre 0 et 99999.999 (j'omets la partie négative, symétrique qui
ne nous interesse pas trop ici), avec donc une précision de 3 décimales.
Peut-être vaut-il mieux brancher les trunks actuels et faire un saut de
version majeure sur cette évolution, pour éviter les dégats et permettre
de tester intensivement avant upgrade en production chez les utilisateurs ?
Ou bien véto catégorique, car le monde est entier ou n'est pas ?
Est ce que ça ne serait pas une logique d'unité et de correspondance
entre elle ? gramme/livre/kilo/ , minute/heure/jour/mois , litre/... ,
....
Dans ce cas l'unité reste toujours entière.
Manifestement chez Drupal Commerce on a la même chose : par défaut quantités entières et un plugin pour passer à des quantités decimales Commerce Modules | Drupal Commerce
Dans Prestashop les quantités sont entières.
Dans thelia 2, elles sont en FLOAT. Du coup, ils gèrent aussi les stocks de produit en float, logique.
Mais côté front, avec le template natif, quand tu saisis 1.5 ou 1,5 pour l'ajout au panier, la valeur est refusée.
Pire, en modifiant la valeur dans la base, le panier arrondit à l'entier.
Du coup, je comprends pas bien ce qu'ils ont cherché à faire.
C'est peut être plus sage de gérer ça en plugin, sinon tu imposes à toute la chaine des plugins commerce de gérer les quantités en float : stocks bien sûr, mais potentiellement calcul de frais de ports ou promos basés sur des quantités de produits, et autres joyeusetés...
J'aime beaucoup l'idée de gérer le prix des éléments en fonction de
l'unité de mesure. Vendre des choses au litre ou au kilo. C'est beaucoup
plus clair pour le consommateur.
Cependant, je ne suis pas d'accord de dire que l'unité reste entière,
car si un steak est à 20€/kg, 500g cela fait 0.5*20€/kg.
Il faudra donc toujours gérer des unités float.
Didier
Le 02/06/17 à 17:20, cam.lafit@azerttyu.net a écrit :
Salut
Est ce que ça ne serait pas une logique d'unité et de correspondance
entre elle ? gramme/livre/kilo/ , minute/heure/jour/mois , litre/... ,
....
Dans ce cas l'unité reste toujours entière.
J'aime beaucoup l'idée de gérer le prix des éléments en fonction de
l'unité de mesure. Vendre des choses au litre ou au kilo. C'est beaucoup
plus clair pour le consommateur.
Cependant, je ne suis pas d'accord de dire que l'unité reste entière,
car si un steak est à 20€/kg, 500g cela fait 0.5*20€/kg.
Il faudra donc toujours gérer des unités float.
J'ai travaillé sur pas mal de boutiques pour des métiers différents, et je n'ai jamais eu à gérer des quantités à décimales.
Pour l'exemple que tu donnes, tu définis que le produit est à 2€ l'unité, et qu'il fait 100g. Ou 0,2€ les 10g si tu as besoin de plus de précision.
Et côté front, tu affiches les infos dans une autre unité (20 € le Kg), et tu laisses les visiteurs choisir la quantité.
Dans le cas d'un abonnement, il a par exemple une unité d'un mois et tu laisses choisir le nombre de mois, etc.
J'aime beaucoup l'idée de gérer le prix des éléments en fonction de
l'unité de mesure. Vendre des choses au litre ou au kilo. C'est beaucoup
plus clair pour le consommateur.
Cependant, je ne suis pas d'accord de dire que l'unité reste entière,
car si un steak est à 20€/kg, 500g cela fait 0.5*20€/kg.
Il faudra donc toujours gérer des unités float.
Didier
Le 02/06/17 à 17:20, cam.lafit@azerttyu.net a écrit :
Salut
Est ce que ça ne serait pas une logique d'unité et de correspondance
entre elle ? gramme/livre/kilo/ , minute/heure/jour/mois , litre/... ,
....
Dans ce cas l'unité reste toujours entière.
Je rebondi juste pour le retour utilisateur ou intégration.
Quand je fais des boutiques j'ai pas de demi produits on est daccord.
Quand je travaille prestation de service (graphiste/webaster/indépendant/artisan) je vends des heures et des taux / horaires, donc des services/prestations quantifiable en unité float : 1.15 a x€/h ça éxiste.
donc une unité peut ne pas être un entier, c'est comme ça dans Dolibarr par exemple, on as le choix entre produit ou service.
A moins qu'on ne décide que une heure entamé est due, et dans ce cas je suis partant !! c'est une idée
Oui du coup j'ai bien fait d'en parler merci tous.
A priori j'ai tout le code fonctionnel là avec un plugin qui modifie les types des champs, ça impacte finalement assez peu paniers et commandes.
Je vais tester proprement, documenter le code pour que ça reste stable dans le temps et j'enverrai tout ça mardi sûrement.
Cédric
Le 2 juin 2017 à 19:30, nicod_ <nicolas.dorigny@gmail.com> a écrit :
Le 02/06/2017 à 19:06, nicod_ a écrit :
et autres joyeusetés...
Par exemple, des échanges potentiels avec d'autres systèmes (imports exports vers des ERP, compta etc.)
Est ce que ça ne serait pas une logique d'unité et de correspondance
entre elle ? gramme/livre/kilo/ , minute/heure/jour/mois , litre/... ,
....
Dans ce cas l'unité reste toujours entière.
Cependant, je ne suis pas d'accord de dire que l'unité reste entière,
car si un steak est à 20€/kg, 500g cela fait 0.5*20€/kg.
Il faudra donc toujours gérer des unités float.
Pas obligatoirement comme indiqué par nico précédemment.
Quand je travaille prestation de service
(graphiste/webaster/indépendant/artisan) je vends des heures et des taux /
horaires, donc des services/prestations quantifiable en unité float : 1.15 a
x€/h ça éxiste.
donc une unité peut ne pas être un entier, c'est comme ça dans Dolibarr par
exemple, on as le choix entre produit ou service.
1.15h c'est 69minutes donc traduisible en unité entière.
Tu peux même gérer certains irrationnels ce qui n'est pas possible
avec un flottant (enfin la valeur dans ce cas est imprécise/tronquée).
0,3333 != 1/3 mais 1/3heure == 20minutes
Chez Tryton c'est de mémoire uniquement en valeur d'unité que tout se calcule.
on est daccord.