La formule que j’aimerais faire fonctionner :
($objectoffield->array_options['options_tauxdalcool']*($objectoffield->qty)*($reloadedobj->array_options['volume'])*3.51)/100;
Pour l’instant ça me renvoie 0, si je retire $reloadedobj->array_options['volume'] j’ai un résultat calculé et juste… Ce qui me fait tiquer c’est que si j’ai bien compris array_options rassemble les attributs personnalisés, or ici le volume est un attribut par défaut du produit…
Bonjour,
A priori c’est normal quand dans votre formule $reloadobject n’est pas rechargé
Essayez un
(($reloadedobj = new Product($db)) && ($reloadedobj->fetchNoCompute($objectoffield->id ? $objectoffield->id : ($objectoffield->rowid ? $objectoffield->rowid : $object->id)) > 0)) ? ($objectoffield->array_options['options_tauxdalcool']*($objectoffield->qty)*($reloadedobj->array_options['options_volume'])*3.51)/100 : echo('Echec');
Ça ne renvoie aucune résultat, le champs reste vide 
Je crois avoir compris quelque chose :
J’avais laissé un var_dump($objectoffield); dans les attributs personnalisés produit. C’est pourquoi les attributs produits apparaissaient tous en vrac dans le champs produit de la page GPAO.
Ce qui m’a laissé croire que lesdits attributs étaient chargés par la formule sensée le faire, mais il n’en est rien…
Vous parlez à la fois de produit et de page gpao, difficile de suivre.
Dans quel module avez-vous défini votre champ calculé ? L’objet disponible dans un champ calculé n’est pas le même selon le module utilisé. Pour charger un objet produit il vous faut l’id de ce produit, et la méthode pour obtenir l’id d’un produit va dépendre de l’objet de base qui est disponible dans votre champ calculé.
C’est vrai, c’est confus. Je clarifie : ce qui m’intéresse c’est de calculer des trucs dans le module GPAO en faisant appel entre autre à des attributs du produit fabriqué.
Pour comprendre mieux ce que je faisais et repérer où chercher ce qui m’intéresse, je suis allé mettre un champs calculé var_dump($objectoffield); dans le module produit. Ça a donc dumpé tous les attributs du produit dans le champs produit sur la fiche de production du module GPAO. J’ai donc cru à tort que grâce aux formules que vous m’avez proposées les attributs du produit étaient chargés et disponibles pour calculer ce que je veux avec.
Ce qui marche actuellement :
Ce qui ne marche pas :
Il y a sur cette capture tout ce qui m’intéresse :
L’id du produit, son volume, le taux d’alcool, la quantité à produire. Je n’arrive juste pas à remettre les pièces dans le bon ordre.
Je pense qu’il n’est pas possible dans un champ calculé d’un ordre de fabrication d’accéder au Produit fabriqué. La création d’un objet Product n’y est pas possible, car dans le code source la classe Product n’est pas chargée.
Bonjour,
J’ai regardé en détail le fonctionnement des champs calculés dans le code source, avec notamment l’utilisation de la variable $objectoffield.
Un point crucial m’avait échappé, et c’est la ligne suivante
$objectoffield désigne le dernier objet « fetché », ce qui va tout simplifier en fait.
La formule suivante devrait fonctionner (sous réserve que j’ai bien reproduit le nom de vos extrafields). J’y ai ajouté une constante (avec valeur à 0.5 pour l’exemple) qui si j’ai bien compris est nécessaire pour votre formule, il vous faudra donc mettre la bonne valeur.
(!empty( $constante = 0.5)) && ($r = $objectoffield->array_options['options_volume'] * $objectoffield->array_options['options_tauxdalcool']) && ($objectoffield->fetch_product()) ? ($constante * $r * $objectoffield->qty) : 'Valeur non définie'
Bonjour,
Merci pour la clarification et les recherches ! En effet quand on fait var_dump($objectoffield) on trouve bien tous les champs qui m’intéressent.
Cependant, votre formule retourne 0 que j’utilise $objectoffield->array_options['volume'] ou $objectoffield->volume. En fait elle retourne 0 même en supprimant toute allusion au volume donc il doit rester un truc qui cloche…
Le volume à produire il est défini sur l’ordre de production ou sur le produit ?
Je n’ai pas la structure de votre base de données, donc je ne peux vous aider qu’en tâtonnant à l’aveugle.
Le volume de chaque produit est un attribut défini sur la fiche du produit. Ça n’est pas un attribut personnalisé mais un attribut par défaut de dolibarr.
Le volume à produire lui n’est pas défini ni calculé : lors d’une production je saisis que je produis x fûts de tel produit, dans ce produit étant défini y litres. C’est pour ça que dans ma formule j’appelle la quantité à produire et le volume du produit.
D’accord, si vous n’avez pas d’attribut personnalisé sur la fiche produit, on ne vas pas rentrer dans la partie du code qui va attribuer l’objet produit à $objectoffield, mais on va avoir le produit affecté au champ product de l’ordre de fabrication. On récupère donc le volume avec $objectoffield->product->volume
On peut également déplacer la constante dans la formule de calcul finale.
J’ai testé cette formule qui fonctionne en essayant de reproduire votre configuration produit et ordre de fabrication
($objectoffield->fetch_product()) ? 0.5 * $objectoffield->qty * $objectoffield->array_options['options_tauxdalcool'] * $objectoffield->product->volume : 'Valeur non définie'
Bonjour,
Ah ben voila je comprends mieux!!!
J’allais crier victoire avec le long paragraphe (masqué à la fin de ce post), puis j’ai rechargé la page et tout était à 0. J’ai malgré tout réussi à faire fonctionner quelque chose mais ça me semble bancal : il y a maintenant deux attributs personnalisés à calculer dans le module GPAO :
(3.51 * $objectoffield->qty * $objectoffield->array_options['options_tauxdalcool'] * $objectoffield->product->volume)/100;
($objectoffield->fetch_product()) ? 3.51 * $objectoffield->qty * $objectoffield->array_options['options_tauxdalcool'] * $objectoffield->product->volume : 'Valeur non définie';
Ce que je peine à comprendre c’est que :
Je me suis dit que ça avait à voir avec cette histoire de fetch_product(), mais je n’arrive pas à le manipuler correctement…
Bonjour !
Victoire !
J’ai pu utiliser la formule la plus simple possible et je vais la décomposer et expliquer ce que j’ai compris.
(3.51 * $objectoffield->qty * $objectoffield->array_options['options_tauxdalcool'] * $objectoffield->product->volume)/100;
3.51 : la constante en utilisant un . comme séparateur de décimales parce que les américains$objectoffield->qty : le champs « quantité à produire » qu’on complète lors de la création de l’ordre de fabrication$objectoffield->array_options['options_tauxdalcool'] : appel à une variable personnalisée, ici taux d’alcool (déclarée comme attributs décimal, obligatoire et à compléter lors de la création de l’ordre de fabrication)$objectoffield->product->volume le volume du produit concerné par l’ordre de fabrication, attribut déclaré lors de la création d’un produitUn des éléments qui a tout changé c’est le type d’attribut personnalisé : on ne peut pas faire d’opérations de calcul dans un champ texte. Ça parait logique mais il y a tellement à défricher et à comprendre qu’on peut passer à côté, en tous cas je suis passé à côté.
Le var_dump($objectoffield); a aussi beaucoup aidé : en le mettant en forme (un attribut par ligne avec l’indentation des { } ) et en comprenant comment les attributs sont listés, imbriqués et déclarés on arrive à comprendre comme les appeler.
Un autre truc à prendre en compte : il faut valider pour qu’un champs personnalisé soit calculé. Je ne sais pas si c’est valable ailleurs que dans la GPAO, mais sur un brouillon les champs à calculer restent à 0.
fetch_product va récupérer les données du produit et les affecter à la propriété product de l’objet objectoffield qui est ici l’ordre de fabrication.
En supprimant drmtxt vous n’avez plus de fetch_product donc objectoffield->product est vide, et au final drm (qui doit sans doute être évalué après drmtxt) sera égal à zéro
Ce que vous faites dans un champ calculé va avoir une influence sur l’autre car objectoffield est un objet déclaré de manière globale.
Pour résumer fetch_product est nécessaire
C’est ce que je me disais. Mais pourquoi alors la formule que vous m’aviez proposée plus tôt ne fonctionne pas toute seule ? (Attention c’est pas une critique, je râle pas j’essaie de comprendre 
)
($objectoffield->fetch_product()) ? 3.51 * $objectoffield->qty * $objectoffield->array_options['options_tauxdalcool'] * $objectoffield->product->volume : 'Valeur non définie';
Il y a pourtant tout dedans, mais elle renvoie 0…
Si il faut obligatoirement séparer les deux fonctions, y a t-il un moyen d’avoir un champs calculé (masqué) qui ne fait que le fetch_product() et un autre qui ne fait que le calcul ?
Salut à tous, me revoilà à la charge !
J’ai poursuivi mes expérimentations et surprise : mon champs calculé est à 0.
En fait le calcul fonctionne, l’appel aux attributs produit fonctionne, mais uniquement lorsqu’on vient de valider l’ordre de fabrication. Si on ressort de la GPAO pour aller faire quoi que ce soit d’autre et qu’on revient dans le module, les champs calculés sont à 0. Seule solution : réouvrir l’ordre de fabrication puis le revalider. Pas possible donc d’utiliser ça dans un environnement de production.
Je présume que c’est parce que les attributs personnalisés de la GPAO ne rechargent les attributs produit que ponctuellement, comment faire pour que ça soit permanent ?
Je suis revenu de vacances, je reviens avec plein de questions !
Je rencontre toujours le comportement du champs personnalisé décrit dans mon dernier post, à savoir :
Un conseil pour corriger ça ? Merci !
Je bumpe de manière innocente et respectueuse
Bonjour,
Désolé j’ai survolé le post donc je vais peut-être répondre à coté. A vue de nez, je serai tenter de dire que la valeur de votre champ calculé ne s’enregistre pas dans la base de données
Bonjour,
Merci ça semble tout à fait pertinent, mais comment faire alors pour qu’elle s’y enregistre ?
