Modèle ODT devis : champ/tag entreprise erratique

CedC · Mars 18, 2021, 2:37

Bonjour,

Suite à mon poste de premier retour ici

je n’arrive pas à comprendre mon problème de devis. Je poste donc un sujet dédié afin d’obtenir, si possible un peu d’aide.

Je souhaite donc créer un template devis au format ODT (de prime abord plus simple que du PHP que je ne maitre pas, mais enfait ce n’est pas dit ).

Ce modèle est également accessible directement en PDF grâce à l’option de conversion automatique de dolibarr.

La problématique est que le champ {company_name} ne s’affiche pas sur certaines propositions mais bien sur d’autres et je ne comprends pas pourquoi.

J’ai testé avec un autre modèle trouvé sur le forum (ITSL-DEVIS-P-02-TEST) pour vérifier que le problème de vient pas de mon modèle, mais je me retrouve avec le même embarras.

Après quelques recherches, il semblerait que cela dépende du tiers :

sur certains tiers, jamais de problème
sur d’autres, systématiquement

Par ailleurs, sur le modèle azure natif, tout fonctionne bien. Le problème semble donc spécifique à tous les modèles ODT (version odt ET pdf)

Je me suis demandé si le problème ne venait pas des base avec des caractère qui poserait problème, mais rien de visible dans un export csv ouvert dans un block note.

Pour le test j’ai quand même essayé de prendre un exmple à la mode : huawei, et j’ai voulu

importer un tier (#3248)
le créer à la main (#3249)

Le tout avec bien entendu les mêmes données. Le problème apparait que sur le Huawei importé

un export des deux dernières lignes de la base donne :

3248,"Huawei Technologies Canada Co., Ltd","Huawei Canada",1,NULL,NULL,0,NULL,1,CU2103-00530,NULL,NULL,NULL,"303 Terry Fox Drive, Suite 400",K2K3J1,Ottawa,507,14,0,6135951705,NULL,www.huawei.ca,NULL,[],NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,2,NULL,NULL,,,,,,,,NULL,0,NULL,NULL,,NULL,2,0,NULL,,0,NULL,0,0,0,0,0,NULL,NULL,NULL,NULL,NULL,NULL,NULL,0,NULL,0.000,NULL,0.000,NULL,0,NULL,NULL,NULL,NULL,en_CA,NULL,NULL,NULL,0,NULL,NULL,"2021-03-17 08:38:56","2021-03-17 08:19:47",2,2,1,EUR,NULL
3249,"Huawei Technologies Canada Co., Ltd","Huawei Canada",1,NULL,NULL,0,NULL,1,CU2103-00531,NULL,NULL,NULL,"303 Terry Fox Drive, Suite 400",K2K3J1,Ottawa,507,14,0,6135951705,NULL,www.huawei.ca,NULL,[],NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,2,NULL,NULL,,,,,,,,NULL,0,NULL,NULL,,NULL,2,0,NULL,,0,NULL,0,0,0,0,0,NULL,NULL,NULL,NULL,NULL,NULL,NULL,0,NULL,0.000,NULL,0.000,NULL,0,NULL,NULL,NULL,NULL,en_CA,NULL,NULL,NULL,0,NULL,NULL,"2021-03-18 14:54:04","2021-03-18 13:56:07",2,2,1,EUR,NULL

je ne voit aucune différence et ne sait plus quoi regardé. auriez-vous des pistes ?

D’avance merci

yves57 · Mars 18, 2021, 3:11

Bonjour et bienvenue,
De ce que je vois, il n’y a pas de différence sur les deux lignes qui pourrait expliquer le comportement « erratique ». La piste est donc celle d’une information liée, qui n’apparait pas dans l’export, mais qui serait nécessaire pour fusionner le champ.
D’autres champs du tiers apparaissent-ils tout de même, ou aucun (car pas d’autre champ insérés) ?

CedC · Mars 18, 2021, 3:18

Bonjour et merci de l’intérêt porté à mon problème.
Dans mon devis, voici les champs utilisés :

REF: {object_ref}
Date: {object_date}
{mycompany_name}
{mycompany_address}
{mycompany_zip}, {mycompany_town}
{mycompany_country}
{mycompany_web}

Customer: {company_name}
{company_name_alias}
{company_address}
{company_zip}, {company_town}, {company_state}
{company_country}

[!-- BEGIN row.lines --]{line_fulldesc} {line_up_locale} {line_qty} {line_options_line_delivery_date} {line_price_ht_locale} €
[!-- END row.lines --]

{object_note_public}
{free_text}

{myuser_firstname} {myuser_lastname}
{myuser_job}
Email: {myuser_email}
Phone: {myuser_phone}

Je ne peux pas uploader le devis. j’ai donc recopié les champs, mais comme mentionné avant, avec un autre modèle trouvé sur le foum, je trouve le même résultat.
Et cela ne semble affecter que le tag {company_name}

yves57 · Mars 18, 2021, 3:24

Il arrive fréquemment, malheureusement, que les « tags » soient mal analysés lors de la fusion. Si seul le champ company_name est concerné, c’est probablement ce qu’il se passe.
La solution est d’effacer le tag et de le ressaisir, voire idéalement de le coller en tant que texte sans formatage, puis de sauvegarder le modèle.

CedC · Mars 18, 2021, 3:40

J’ai effectivement remarqué ce soucis auparavant, il affectait de nombreuses lignes (adresse, total_ht, etc.).
J’avais refait tout le modèle de la sorte (collé sans formatage) et cela avait résolus tous les soucis… sauf le tag ici mentionné qui reste récalcitrant.

si le tag était d’ailleurs mal parsé, il le serait sur toutes les propales je pense, pas simplement sur celles lié à certains tiers, si ?

yves57 · Mars 18, 2021, 5:37

C’est ce que je me disais. Mais si la fusion ne trouvait pas les données du client, elle n’en substituerait pas certaines seulement, mais aucune.
Le code qui fait la substitution est :

 $array_thirdparty = array(
            'company_name'=>$object->name,
	        'company_name_alias' => $object->name_alias,
            'company_email'=>$object->email,
            'company_phone'=>$object->phone,
            'company_fax'=>$object->fax,
            'company_address'=>$object->address,

Toutes les données sont tirées du même objet, donc si elles sont fournies pour certains champs, on peut supposer que l’objet est correct.

CedC · Mars 18, 2021, 6:55

Hum j’ai fais quelques expérience de plus. J’ai installé mysql workbench et j’ai copié / collé dans la bdd d’une ligne en changeant : le rowid (forcement) et en inversant le customer number
donc avant :

'3248', '0- Huawei Technologies Canada Co., Ltd', 'Huawei Canada', '1', NULL, NULL, '0', NULL, '1', 'CU2103-00530', NULL, NULL, NULL, '303 Terry Fox Drive, Suite 400', 'K2K3J1', 'Ottawa', '507', '14', '0', '6135951705', NULL, 'www.huawei.ca', NULL, '[]', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, '2', NULL, NULL, '', '', '', '', '', '', '', NULL, '0', NULL, NULL, '', NULL, '2', '0', NULL, '', '0', NULL, '0', '0', '0', '0', '0', NULL, NULL, NULL, NULL, NULL, NULL, NULL, '0', NULL, '0.000', NULL, '0.000', NULL, '0', NULL, NULL, NULL, NULL, 'en_CA', NULL, NULL, NULL, '0', NULL, NULL, '2021-03-18 19:29:34', '2021-03-17 08:19:47', '2', '2', '1', 'EUR', NULL

après :

'3248', '0- Huawei Technologies Canada Co., Ltd', 'Huawei Canada', '1', NULL, NULL, '0', NULL, '1', 'CU2103-00535', NULL, NULL, NULL, '303 Terry Fox Drive, Suite 400', 'K2K3J1', 'Ottawa', '507', '14', '0', '6135951705', NULL, 'www.huawei.ca', NULL, '[]', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, '2', NULL, NULL, '', '', '', '', '', '', '', NULL, '0', NULL, NULL, '', NULL, '2', '0', NULL, '', '0', NULL, '0', '0', '0', '0', '0', NULL, NULL, NULL, NULL, NULL, NULL, NULL, '0', NULL, '0.000', NULL, '0.000', NULL, '0', NULL, NULL, NULL, NULL, 'en_CA', NULL, NULL, NULL, '0', NULL, NULL, '2021-03-18 19:29:34', '2021-03-17 08:19:47', '2', '2', '1', 'EUR', NULL
'3258', 'Huawei Technologies Canada Co., Ltd', 'Huawei Canada', '1', NULL, NULL, '0', NULL, '1', 'CU2103-00530', NULL, NULL, NULL, '303 Terry Fox Drive, Suite 400', 'K2K3J1', 'Ottawa', '507', '14', '0', '6135951705', NULL, 'www.huawei.ca', NULL, '[]', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, '0', '2', '0', NULL, '', '', '', '', '', '', '', NULL, '0', NULL, NULL, '', NULL, '2', '0', NULL, '', '0', NULL, '0', '0', '0', '0', '0', NULL, NULL, NULL, NULL, NULL, NULL, NULL, '0', '0', '0.000', '0', '0.000', NULL, '0', NULL, NULL, NULL, NULL, 'en_CA', NULL, NULL, NULL, '0', NULL, NULL, '2021-03-18 19:31:17', '2021-03-17 08:19:47', '2', '2', '1', 'EUR', NULL

et deux choses étonnante :

la nouvelle ligne 3258 ne possède pas le problème (le soucis n’est a priori pas dans la table societe ?!)
le devis test sur le client CU2103-00530 ou le nom de société ne s’affiche pas. Je pensais qu’en changeant le numéro client en CU2103-00530 → CU2103-00535, plus la creation d’une nouvelle ligne avec le num CU2103-00530 le devis serait affecté au nouveau tiers 3258 / CU2103-00530 mais non il est resté sur 3248 qui a vu son num client changer. Le devis serait donc relié au rowid et pas au code_client ?

l’erreur peut-elle venir du devis en lui même ?
Nouveau test, je change le fk_soc sur le tiers qui ne marche pas vers un tiers qui fonctionne et même soucis avec le tiers qui fonctionnait. Cela confirme donc un problème sur le devis, je vais continuer à chercher, mais le même devis sur les deux tiers différent ne donnais pas le même résultat, c’est à ne rien comprendre !

CedC · Mars 18, 2021, 8:34

Bon ce n’est pas non plus le devis puisqu une duplication (sql workbench) de ligne dans la base llx_propal (chagement uniquement rowid / ref) donne un résultat qui… fonctionne.

j’ai trop mal à la tête j’arrête pour aujourd’hui !

yves57 · Mars 19, 2021, 6:16

Oui, ceci est certain. Toutes les liaisons se font avec le rowid.

CedC · Mars 19, 2021, 5:47

Bonjour, je n’arrive pas à avancer et c’est très frustrant puisque je ne peux pas tester plus amplement dolibarr.
A tester en direct dans la base je fini par briser des choses, et je passe plus de temps à revenir dessus qu’à avancer sur mon soucis. Je ne parle pas le php, mais c’est peut-être le moment de m’y mettre… où puis-je trouver le module qui converti les donnés dans la base en devis ODT sur la base d’un model ?
j’ai essayé de regarder la doc pour dev, module proposals mais je ne vois pas.
Je pense que vous devez savoir ou c’est, puisque vous m’avez indiqué ceci :

$array_thirdparty = array(
        'company_name'=>$object->name,
        'company_name_alias' => $object->name_alias,
        'company_email'=>$object->email,
        'company_phone'=>$object->phone,
        'company_fax'=>$object->fax,
        'company_address'=>$object->address,

ca pourrait me mettre sur la piste

CedC · Mars 19, 2021, 8:28

J’ai peut-être trouvé une piste : les tiers qui ont des contacts et qui ne fonctionne pas correctement (au niveau du tag company_name) se mettent à fonctionner quand je supprime les entrées les liant dans la base llx_societe_contacts

yves57 · Mars 20, 2021, 5:14

Le code que j’ai cité est dans htdocs/core/class/commondocgenerator.class.php.
La dernière info est intéressante.
Et bingo, c’est un bogue : {company_name} in ODT not filled · Issue #16323 · Dolibarr/dolibarr · GitHub
Probablement avec la version 13.

CedC · Mars 21, 2021, 9:45

Ah ! la bonne nouvelle c’est que je ne suis pas le seul à avoir le soucis et que c’est identifié.
C’est un problème quand même important donc je ne désespéré pas de voir un fix venir
Merci pour le support en tout cas,et si le soucis n’est pas réglé maintenant, je vais moins m’arracher les cheveux, ce qui n’est pas rien.

J’ai plus qu’à voir le fichier indiqué et voir si je peux identifier le soucis dans le code