Openerp Devis, facture et colisage sur plusieurs pages
Par SISalp le samedi 13 février 2010, - Administrer Odoo - Lien permanent
Les documents devis, facture et listes de colisage d'OpenERP peuvent comporter plusieurs pages. Dans leur version de base, les pages qui suivent la première ne répètent pas les informations essentielles d'entête qui permettent de regrouper le document. Voici comment améliorer ces documents.
Temps d'exécution de la procédure :
- Environ 30 mn
Difficulté :
- Niveau avancé
- Savoir éditer un fichier de type texte, avoir des notions sur le balisage des documents xml.
Risque :
- Limité
- sauvegardez logiciel et données avant toute intervention.
Principe.
Le fichier qui formate le document pdf produit par OpenERP est au format .rml
L'exercice consiste à modifier ce fichier pour utiliser l'attribut repeatRows du langage rml, dont l'objet est précisément de répéter des éléments d'une page à l'autre quand un document comporte plusieurs pages.
Remarque : Certains documents d'origine comportent déjà cet attribut, mais celui-ci est mal utilisé et ne produit pas l'effet escompté. Attention, cependant, ceci va peut être être corrigé dans une version future, auquel cas cette procédure n'aura plus lieu d'être éxécutée.
Exemple appliqué à la facture client.
Nous allons éditer le document rml qui se trouve dans server/bin/addons/account/report/invoice.rml
Les mêmes instructions peuvent être également transposées pour les autres documents, en particulier le devis client et la liste de colisage.
Document d'origine
Avant modification, la facture OpenERP se présente de la façon suivante quand la liste des articles est suffisamment longue pour qu'un saut de page soit nécessaire. (Cliquer dessus pour l'agrandir)
Sur la première page nous trouvons les informations clés de la facture, le nom du client, son numéro de TVA intracommunautaire, le numéro de la facture, la date de facturation et le début de la liste des articles.
Sur la deuxième page, nous trouvons la fin de la liste des articles, les totaux hors taxe et ttc, le rapport de TVA.
Une fois imprimées, ces deux pages peuvent se trouver séparées ou mal classées, rien n'indique qu'elles constituent une seule et même facture.
Document modifié
Pour le besoin de cet exposé, nous décidons de rappeler un partie des informations d'entête en haut de chaque page et d'obtenir le document suivant :
Dans ce document, nous choisissons de recopier page à page le cartouche du haut de la facture et les entêtes de colonnes.
Vous pouvez bien sûr appliquer la même technique pour recopier l'adresse de facturation et le numéro de facture sur chaque page.
Par exemple, SISalp utilise un cartouche modifié dans lequel est répété le numéro de facture et le nom du client y remplace son code.
Adaptation du fichier de description de la facture
Dans le fichier server/bin/addons/account/report/invoice.rml, nous allons tout d'abord intégrer l'ensemble des informations qui suivent la zone que nous ne voulons pas recopier dans un grad tableau.
Pour cela nous ajoutons la balise <blockTable> dans la section <story>, juste avant la zone que nous voulons recopier, et la balise </blockTable> à la fin du document, au dessus de la balise </story>.
Les tables rml fonctionnent comme les tables html, c'est à dire que les contenus sont précédés par les balises <tr><td> et suivis par les balises </td></tr>. Ces balises indiquent l'ouverture et la fermeture d'une rangée dans la table. Nous allons donc encadrer la zone que nous voulons recopier par ces balises et cette zone constitue donc la première rangée de la table. Nous encadrons le reste du document par les mêmes balises qui constituent donc la deuxième rangée de la table.
Ajoutons maintenant l'attribut repeatRows="1" à la balise <blockTable>, redémarrons le serveur OpenERP et constatons le résultat. Tant que ça plante, vérifiez que vous avez bien suivi ces instructions. Elles ont fonctionné sur la version 5.0.7.
Application de la modification
L'adaptation d'un fichier rml n'a pas d'effet sur le contenu de la base de données et cette opération comporte peu de risque. Appliquez les précautions d'usage avant toute intervention sur le code, sauvegardez ancien code et bases de données.
Une fois le fichier modifié, documentez bien votre travail ou créez un module qui substitue ce nouveau format de facture à l'ancien, car sinon, vous risquez de perdre vos adaptations lors d'une mise à jour du logiciel. Ceci est un autre sujet.
Détail des adaptations
Voici le résultat de la commande diff -u entre les fichiers invoice.rml qui correspondent aux deux documents des illustrations de cet article.
--- invoice.rml.original 2010-02-13 10:54:59.000000000 +0100 +++ invoice.rml.modified 2010-02-13 01:00:50.483357447 +0100 @@ -260,6 +260,10 @@ <para style="terp_header">Supplier Refund [[ (o.type=='in_refund' or removeParentNode('para')) and '' ]] [[ o.number ]]</para> <para style="terp_header">Supplier Invoice [[ (o.type=='in_invoice' or removeParentNode('para')) and '' ]] [[ o.number ]]</para> <para style="P8"><font color="white"> </font></para> + +<blockTable repeatRows="1" > +<tr> +<td> <blockTable colWidths="177.0,177.0,177.0" style="Table_Invoice_General_Header"> <tr> <td><para style="terp_tblheader_General_Centre">Document</para></td> @@ -286,7 +290,11 @@ <td><para style="terp_tblheader_Details_Centre">Price</para></td> </tr> </blockTable> - <section> +</td> +</tr> +<tr> +<td> + <para style="terp_default_8">[[ repeatIn(o.invoice_line,'l') ]]</para> <blockTable colWidths="211.0,62.0,36.0,27.0,63.0,36.0,62.0,26.0" style="Table_Invoice_Line_Content"> <tr> @@ -310,7 +318,10 @@ <td><para style="terp_default_Note"><font color="white"> </font></para></td> </tr> </blockTable> - </section> +</td> +</tr> +<tr> +<td> <blockTable colWidths="371.0,153.0" style="Table_Format_2"> <tr> <td> @@ -417,6 +428,8 @@ <para style="terp_default_2"> <font color="white"> </font> </para> - +</td> +</tr> +</blockTable> </story> </document>