Adapter un template pdf pour une commande fournisseur

Développer avec Dolibarr
1

Bonjour,

Pour adopter Dolibarr, je cherche à créer les modèles de documents pour ma société.
J’ai vu la possibilité d’utiliser un modèle au format odt, l’inconvénient c’est la conversion pdf et certains calculs impossible après le rendu ce que semble permettre la construction direct en pdf.
Je me tourne donc vers l’adaptation d’un modèle pdf, mais j’ai peur de n’être restreint qu’à une modification en surface…

Concernant mon exemple sur la commande fournisseur, j’aimerai modifier la forme et le fond de la description d’un produit, à savoir mettre entre crochet la référence du produit/service, utiliser une police différente pour la référence + label que pour la description qui suivra, ajouter si existant la référence et le nom du fabricant (attribut supplémentaire ajouté aux produits)… etc

Je parcours donc le code du modèle que je cherche à copier comme base de départ, à savoir www\dolibarr\htdocs\core\modules\supplier_order\pdf\pdf_muscadet.modules.php et là, c’est le drame !

Si je comprend bien, le contenu de la cellule « Désignation » est obtenu par l’appel à la fonction pdf_writelinedesc du fichier www\dolibarr\htdocs\core\lib\pdf.lib.php qui fait elle même appel à la fonction pdf_getlinedesc du même fichier, soit bien ancré au fin fond du core de Dolibarr…

Est-il possible de surcharger ces fonctions sans aller casser le coeur de Dolibarr ?
Il me semble que c’est un boulot de dingue la quantité de code à reprendre et à modifier, la complexité de ce qu’il faut gérer, juste pour adapter le rendu d’un petit bout de texte sur ces documents ! Peut-être suis-je parti dans une mauvaise direction ?

Merci de m’éclairer !

2

Bonjour,

Oui vous pouvez tout à fait écrire un fonction pdf_writelinedesc_moi dans votre modéle PDF

Il y a malheureusement pas beaucoup d’alternatives :

  1. modifier un modéme PDF
  2. Passer à l’ODT
  3. Prendre un pack tout fait qui peu peut-etre collé un peu plus à vos besoin : Rubis, InfraSpack, UltimatePDF, etc.
3

Merci pour la réponse.

Je vois que les modèles utilisent des mises en forme commune avec le reste du logiciel, d’où le fait que ces fonctions fassent partie du coeur de l’ERP, mais niveau souplesse d’édition, c’est vraiment pas génial, on peut ajouter des données, mais dès lors qu’on veut modifier ce qui est déjà afficher c’est vraiment très lourd !

Je devrais peut-être ouvrir un autre fil, mais j’ai à priori un problème avec la mise en page de mon modèle PDF, à savoir que je n’arrive pas à centrer le compteur de page dans une cellule…
Si je comprend le problème, le nombre total de page est un alias spécial ($pdf->getAliasNbPages()) qui est remplacé à la fin du calcul du PDF pour savoir combien il y a de page et donc remplace cet alias temporaire par le véritable nombre. Du coup lors du calcul du centrage de mon texte, c’est l’alias temporaire qui est bien plus long qu’un simple nombre à 1 chiffre dans la plupart des cas qui est utilisé pour le calcul de position du texte et qui casse le centrage de mon compteur de page.
Est-ce un bug ? Y a-t-il un moyen de le contourner ?

Pour information, mon texte que j’essaie de centrer est : $page = $pdf->PageNo().'/'.$pdf->getAliasNbPages(); et le texte apparaît au bord gauche de la cellule au lieu d’être centré, ce qui aurait un sens si l’alias de nombre de page est assez grand…
En revanche en essayant avec la syntaxe suivante : $page = $pdf->getAliasNumPage().'/'.$pdf->getAliasNbPages(); le décalage vers la gauche est encore plus important, ce que je ne m’explique pas…

EDIT : j’ai trouvé la fonction $pdf->getAliasRightShift() mais je ne trouve pas la combinaison pour obtenir le centrage correct de l’affichage du compteur de apge…

4

Bonjour,
Vous devez pouvoir centrer avec $pdf->writeHTMLCell :wink:
@+

5

Bizarrement, en utilisant $pdf->writeHTMLCell ou directement $pdf->MultiCell qui est appelé par writeHTMLCell la substitution ne se fait pas et les alias sont affichés au lieu de leur valeur…

6

Un extrait de votre code ?
@+

7

Merci pour l’aide !

J’espère mettre le strict nécessaire pour reproduire le phénomène :

	$w = 13;
	$h = 7;
	$fontSizeValue = 11;
	$pdf->SetXY($posx, $posy);
	$pdf->SetFont('', 'B', $fontSizeValue);
	$page = $pdf->getAliasRightShift().$pdf->getAliasNumPage().'/'.$pdf->getAliasNbPages().$pdf->getAliasRightShift().'   ';
	$pdf->Cell($w, $h, $page, 0, 0, 'C', false, '', 0, false, 'T', 'T');

Ceci est mon code actuel qui donne un bon résultat, néanmoins j’ai du ajouter 3 espaces en fin de texte pour que le centrage soit bon, dans le code de la fonction getAliasRightShift le caractère ajouté ‹ / › n’est pas pris en compte, ce qui influe possibleemnt le résultat, à moins que ce ne soit à cause de la police (par défaut dans mon cas) vu qu’il est indiqué en commentaire de la fonction replaceRightShiftPageNumAliases :

  • Replace right shift page number aliases with spaces to correct right alignment.
  • This works perfectly only when using monospaced fonts.

A moins que celà soit dû à l’ajout de 3 caractères { (pour chacun des 3 alias) non prévus comme l’indiquerait le commentaire de la fonction getAliasRightShift:

  • If the current font is unicode type, the returned string wil contain an additional open curly brace.

Concernant les autres fonctions, le code utilisé était le suivant à la place de l’appel à la fonction Cell :

	$pdf->writeHTMLCell ($w, $h, '','', $page);

ou directement :

	$pdf->MultiCell($w, $h, $page, 0,'C', false);

A noter qu’avec les multicell la case étant trop étroite pour les alias il y a des retours à la ligne qui sont peut-être la cause du non remplacement si les retours à la ligne cassent les alias non reconnus par la suite, ce qui maintenant que je l’écris me semble être la cause probable.