Bonjour,
merci pour cette réponse constructive:
je ne peux pas joindre le fichier et ce qu’il contient est pour moi du chinois!
Il a été généré par dolibarr!
Vous ne vous adressez pas à un informaticien mais à un utilisateur, qui certes a quelques connaissances d’informatique et de comptabilité, mais qui remontent pour certaines à plus de 20 ans!
Cordialement
Bonjour,
Avez-vous lu la deuxième partie de mon message.
Je vous donne des pistes.
Le fichier odt, est-ce vous qui l’avez créé ?
Vous voyez en nous donnant ce type d’information on peut vous aiguiller plus facilement
Désolé si je vous ai blessé.
D’autres personnes ici sauront mieux vous répondre.
Bonjour,
j’ai indiqué que le fichier avait été créé par Dolibarr!
Je ne peux malheureusement rien dire d’autre
Cordialement
Bonjour,
Nouvelle fonctionnalité de Dolibarr ? Il créé des fichiers odt maintenant?
Je ne savais pas.
Désolé alors j’ai mal compris votre question.
Cordialement
A ma connaissance c’était toujours le cas
Cordialement
Bonjour,
J’ai déjà rencontré ce type de problème. Chez moi, la cause était un fichier odt mal préparé.
En procédant ainsi
j’ai pu obtenir un odt fonctionnel
Bon week-end
1 « J'aime »
Ah ! Pour moi le process est le suivant:
Modèle existant dans Dolibarr : la génération des factures … se fait en PDF
Modèle que l’on créé en odt : la génération se fait en …pdf.
Ce n’est pas Dolibarr qui créé un odt. C’est l’utilisateur qui créé un odt pour le générer en PDF.
Je peux me tromper
Cdt
Bonjour
La solution est assez simple 
Pas d’inquiétude à avoir. Cela arrive quand le modèle ODT initial à un formatage xml indigeste pour dolibarr.
Pour corriger l’odt obtenu, il faut (j’essaye de donner un pas à pas):
- télécharger le fichier
- changer l’extension en .zip
- extraire le contenu dans un répertoire vierge
- ouvrir le fichier content.xml avec un éditeur de texte (cf remarque plus bas)
- chercher la ligne 2 , colonne 19689
- identifier la balise xml mal formée et la corriger (cf exemple un peu plus bas).
- sauvegarder le fichier
- refaire une archive zip du répertoire
- changer l’extension zip en odt
- ouvrir avec libreoffice
- et voilà
- sinon recommencer du début
Remarque 1 : il vaut mieux un éditeur de texte qui sache lire et formater le xml, cela améliore la lisibilité (visual code, gedit , notepad++, …)
Remarque 2 : un exemple de xml à corriger :
<text:p><text:span text:style-name="T5">26230</text:p></text:span>
Le balisage est erroné car le text:p est inclus dans le text:span, la correction pourrait être :
<text:p><text:span text:style-name="T5">26230</text:span></text:p>
Enfin pour corriger le problème plus globalement, il faut faire la même manipulation avec l’odt source. Dans ce cas on rechercher les balise de remplacement de la forme :
<text:p><text:span text:style-name="T5">{ </text:span> balise_dolibarr }</text:p>
Il faut alors corriger en regroupant toute la balise dolibarr dans la même balise xml par exemple :
<text:p><text:span text:style-name="T5">{ balise_dolibarr } </text:span> </text:p>
Dans ce cas le problème ne devrait plus se reproduire par la suite. En tout cas chez moi cela fonctionne proprement depuis que les correctifs ont été fait
Waouh !
Ça c’est de l’enquête.
Sait-on dans quelles conditions ces balises <text:span> sont insérées ? Isamuse et Romain indiquent comment éviter ce genre de souci, en faisant un copier-coller depuis un éditeur de texte, mais est-ce vraiment la seule solution ?
Bonjour,
merci à tous. Cela dépasse mes compétences car je ne connais rien à ce problème, étant un bête utilisateur.
J’espère que cela permettra de résoudre ce problème d’une manière générale pour tous les utilisateurs de Dolibarr dans une prochaine révision.
Quant-à moi j’ai utilisé le pdf et retouché celui-ci avec un logiciel pdf
Merci encore
Cordialement
Bonjour
Cela dépend de comment on rédige son modèle odt. Pour faire simple et parce que je ne connais pas par bien le fonctionnement du format xml, on peut dire que dès qu’on saisi un caractère dans un fichier celui ci va être encapsuler dans un <span> le contexte permet ensuite d’englober l’ensemble du texte saisi. Dans la plupart des cas le span va englober alors l’ensemble de la balise dolibarr {ma_balise_dolibarr}.
Malheureusement il y a des cas moisis où cela ne se passe pas comme ça. Sur la base de mon expérience, cela peut se produire assez facilement lorsqu’on fait une boucle pour afficher les lignes d’une devis ou d’une facture.
On a un gros mélange d’espace, saut de ligne, colonne, … et là le formatage à parfois du mal à suivre.
Une autre astuce si on ne veut pas modifier directement le xml c’est de ressaisir dans l’éditeur le contenu de la balise dolibarr. On part du milieu du texte on ajoute le début et la fin et on supprime ensuite les caractères en doublon. Dans ce cas cela peut nettoyer les span qui se baladeraient dans le bloc de texte.
Pour ma part j’utilise les modèles odt et la génération à la volée en pdf. Cela fonctionne très bien. L’édition du modèle initial règle (via le content.xml) le problème en général une bonne fois pour toute. Ce n’est pas pire que d’éditer une page html lambda
1 « J'aime »
Hello
Corriger à la base le modèle odt reste quand même la solution la plus pérenne.
Le problème se reproduira probablement à moyen terme.
Merci azerttyu pour cette solution pour corriger les fichiers odt.
J’avais aussi constaté que ce type de message survenait lors de l’utilisation de conditions dans la génération des odt.
Ca me permettra d’aller plus vite pour retrouver mes erreurs la prochaine fois !
Pourquoi si le modèle de base a été corrigé ?!?
dans ce cas tout ira bien en effet 
Bonjour,
la génération de facture odt ne me semble pas une solution pérenne au vu de l’évolution de la législatio.
Cordialement
Hello
Je ne vois pas en quoi ? Il n’y a aucune différence avec les gabarits par défaut. Si la remarque concerne l’ODT en soit :
- il est toujours reproductible à l’identique depuis dolibarr (via la bouton générer et si on respecte la loi)
- on peut configurer dolibarr pour n’avoir que le pdf de stocké. (mais on peut toujours le regénérer avec le bouton)
