Tout d’abord bravo à tout l’équipe derrière Dolibarr pour ce travail remarquable.
Néanmoins, je rencontre deux soucis lors de la mise en place du système.
Premièrement, l’idée est d’ajouter quatre champs supplémentaires sur la fiche client.
Pour cela je vais dans Configuration → Modules → Tiers → Configuration → Attributs supplémentaires (tiers), et là, j’ajoute mes champs et leurs libellés, à savoir
company_phone2,
company_phone3,
company_email2,
company_email3.
Vous l’aurez compris, certains clients en ont souvent plusieurs. J’ai tenté de suivre la logique des champs originaux.
Cette étape-là, pas de problème. C’est lorsque que je veux faire apparaître ces champs dans mon modèle de propale (ou de facture) au format ODT que je n’y arrive pas. En suivant la page du wiki sur la création de template ODT, il m’a semblé que la syntaxe est :
{object_options_company_phone2}
Mais non. Dans le doute, et suite à certains messages lus sur le forum, j’ai tenté des syntaxes telles que :
{object_thirdparty_company_phone2}
{company_options_company_phone2}
Sans plus de résultats concrets. Il faut dire que je ne suis pas un expert, je suis plus dans la réparation/dépannage informatique.
Au cas où, j’ai aussi essayé de faire un ODT depuis la fiche Tiers, des fois que ces champs ne soient pas repris dans les autres modules. Même résultat.
Ma première question est donc : quelle est la syntaxe correcte pour afficher les attributs supplémentaires du module Tiers dans une proposition commerciale ou une facture au format ODT ?
Ensuite, cette installation de Dolibarr est prévue pour de l’événementiel. Je prévois donc de rajouter des attributs supplémentaires correspondant à la date de début, l’heure, et le nombre de personne dans les modules ‹ ‹ Propositions commerciales › › et ‹ ‹ Factures › ›.
Seconde question : peut-on (facilement) récupérer les attributs supplémentaires d’une propale pour les mettre dans une facture ?
Voilà, merci de m’avoir lu. Et si possible de me donner une piste.
Effectivement, en créant un nouveau champ dans le module de proposition commerciale, nommé « Nombre de personnes » et ayant pour code « nbpers », le champ {object_options_nbpers} me retourne bien le nombre indiqué sur mon document odt.
Dois-je conclure que seuls les champs créés pour les modules Proposition commerciale et Facture sont exportables sur un document ODT (et donc pas ceux issus des Tiers) ?
Dans mes différentes recherches sur les templates ODT j’ai pu noter que les noms de variable extrafields définis en majuscule ne fonctionnaient pas.
Faites un essai avec une variable définie en minuscule (ce qui est en tous les cas préférable pour les extrafields)
je viens de tester la version 3.5.4 et il semble bien que les attributs supplémentaires du module TIERS ne peuvent toujours pas être utilisés sans développement spécifique, dans un odt…
Je suis toujours dans ce cas, et je n’ai franchement aucune solution, pensez-vous que les ODT sont a abandonner pour passer
sur une version PHP plus lourde a mettre en place ?
J’ai essayé en minuscule et majuscule pour les variables extrafields, mais même résultat.
C’est quand même dommage, l’idée était trés bonne.
Je viens de vérifier dans le code et normalement les attributs supplémentaires de tiers doivent être disponible dans les ODT sous la forme « company_options_XXX » où xxx est le code de l’attribut.
au temps pour moi… je viens de vérifier et la chaîne à utiliser est en réalité: {company_options_XXX} où xxx est le code de l’attribut… cela fonctionne bien en v3.5.4
Pour les attributs supplémentaires produit, cela ne peut fonctionner actuellement car le produit n’est pas chargé dans le document. Les informations qui sont chargés sont celles du document, des lignes du document, du tiers associé au document, de la société utilisatrice (mycompany).
Pour que cela fonctionne il faudrait pour chaque ligne, charger le produit associé (s’il y en a un) et les attributs supplémentaires associés.
Je vais regarder ce que ça donne d’un point de vue dev et vous donnerais les infos.
Pour les adresses lié au contact vous pensez que l’on peut utiliser : htdocs/monmodule/core/substitutions/functions_mymodule.lib.php
si c’est simple je peux aussi l’uitliser dans les ligne spour remonter les extrafields.
Vous n’auriez pas un exemple de codage pour cette fonction, pour remonter un de mes extrafields par exemple …
function mymodule_completesubstitutionarray_lines(&$substitutionarray,$langs,$object,$line) {
{
global $conf,$db;
$myvalue=‹ Put here calculated value to insert ›;
$substitutionarray[‹ myowntag ›]=$myvalue;
}
Je bute également sur la génération d’un code créé.
Je crée un nouveau champ dans le module Tiers : « Adresse de livraison » ayant pour code « adliv »,
Dans un modele openoffice:
le champ {object_options_adliv} me retourne le texte {object_options_adliv}?
le champ {company_options_adliv} me retourne le texte {company_options_adliv}?
à moins d’avoir loupé quelque chose … je ne sais plus quoi faire, auriez vous une idée.
J’ai testé d’autres codes standard et ça fonctionne mais pas mon code ???
Bonsoir
J’ai travaillé sur les ODT au point de développer un module (extraODT) permettant d’ajouter des champs et surtout des listes supplémentaires, mais aussi la possibilité de filtrer les listes (en nombre et en valeur) selon des valeurs présents dans l’ODT
si vous voulez connaitre les champs présents nativement il faut aller dans le fichier /core/class/commundocgenerator.class.php
Je précise que la fonction de transfert entre les ODT et le parseur est maintenant intégré dans le core https://github.com/Dolibarr/dolibarr/pull/1997
Petite question en passant: y a t-il une possibilité de tester le module avant de passer à l’achat sur dolistore. Je ne parle pas uniquement de ton module mais des modules généralement en ventes sur dolistore?
C’est dommage de ne pouvoir tester, autant pour un module à 5€ ça passe mais à 60 voir plus, on réfléchi à 2 fois avant de se lancer!
Nous avons un environnement de démonstration pour tester nos modules ainsi qu’une documentation présenteant ceux-ci .
Ensuite, je n’ai pas d’état d’âme à envoyer une version pour tester … je considère plus leur commercialisation sur le dolistore comme du sponsoring… La vente de modules n’est pas ma principale source de revenu (bien que chaque mois ca augmente
