Colonnes de PDF configurables par l’administrateur

Administrateur 6 min de lecture Mis à jour en juillet 2026

Toute organisation finit par vouloir un élément de plus sur ses documents — le mode de paiement sur les reçus, un code projet sur les lignes de facture, le numéro de chèque sur les bons de paiement. Dans REDA Financials, il ne s’agit pas de refondre un modèle : il suffit qu’un administrateur fasse glisser un champ dans une liste. Les mises en page PDF lisent leur contenu supplémentaire dans des ensembles de champs — des listes de champs configurables par l’administrateur — nommés PDF Template sur chaque objet de document.

Pour y accéder. L’ajout de colonnes est une tâche de Configuration Salesforce, et non un onglet REDA : depuis Configuration (l’icône d’engrenage → Configuration) → Gestionnaire d’objet → l’objet de document (par exemple Encaissement, Facture d’achat) → Ensembles de champs → l’ensemble PDF Template, puis faites-y glisser les champs. Consultez l’article Salesforce À propos des ensembles de champs pour le fonctionnement détaillé.
Accès requis. La modification des ensembles de champs est une capacité d’administrateur Salesforce (l’autorisation « Personnaliser l’application »), et non l’un des ensembles d’autorisations de REDA Financials. Les utilisateurs courants voient simplement les colonnes obtenues sur les PDF générés.

Ce qui apparaît, et où

Ensemble de champs sur…	S’affiche sous forme de…
L’en-tête du document (Facture de vente, Encaissement, Décaissement, Bon de commande)	Des lignes libellé/valeur supplémentaires dans la carte des détails du document, après les lignes standard de numéro, de date et de référence
Les lignes (lignes de facture de vente, lignes de bon de commande)	Une petite bande de détail sous chaque ligne — des paires « Libellé : valeur » sous la description, qui préservent la clarté du tableau principal

En standard, les reçus affichent déjà ainsi Imputé aux factures, Compte bancaire, Trésorerie non imputée, Mode de paiement et Type, et les bons de paiement affichent Compte bancaire, Montant imputé, Montant non imputé, Mode de paiement et Numéro de chèque — ces valeurs par défaut ne sont que des entrées de l’ensemble de champs, que vous pouvez compléter ou réduire.

Chaque objet de document possède sa propre liste ; la vue d’ensemble se présente donc ainsi :

Document	La liste d’en-tête est livrée avec…	Liste des lignes
Facture de vente	Vide — ajoutez ce dont vos factures ont besoin	Livrée avec Base de taxe ; ajoutez vos propres champs (codes projet, centres de coûts…)
Encaissement	Imputé aux factures, Compte bancaire, Trésorerie non imputée, Mode de paiement, Type	— (les reçus n’ont pas de lignes)
Décaissement	Compte bancaire, Montant imputé, Montant non imputé, Mode de paiement, Numéro de chèque	— (les bons de paiement n’ont pas de lignes)
Bon de commande	Vide	Disponible, livrée vide

Un exemple concret, avec les reçus comme cas d’école : Meridian souhaite que ses reçus de loyer indiquent sur quelle banque l’argent est arrivé. Rien à faire : Compte bancaire est déjà livré dans la liste de champs PDF Template de l’objet Encaissement, si bien que la carte des détails de chaque reçu comporte déjà une ligne « Compte bancaire : First National Bank - Operating » — le nom du compte, pas un code. C’est dans cette même liste que Meridian ajouterait un champ réellement nouveau : l’ouvrir, y faire glisser le champ, terminé. Durée totale : environ deux minutes, sans nouvelle version ni interruption de service.

Ajouter un champ (administrateur, ~2 minutes)

Ouvrez les ensembles de champs de l’objet

Configuration → Gestionnaire d’objet → l’objet de document (par exemple Encaissement) → Ensembles de champs → PDF Template.

Faites glisser le champ dans l’ensemble

Tout champ de l’objet convient — standard, packagé ou vos propres champs personnalisés. L’ordre dans l’ensemble est l’ordre sur le papier.

Régénérez et vérifiez

Aucun déploiement, aucun code — la prochaine génération le prend en compte. Vérifiez un document ; c’est terminé.

Comment les valeurs s’impriment

Les champs de relation impriment des noms — un champ Compte bancaire affiche « First National Bank - Operating », jamais un ID.
Les formats suivent les paramètres régionaux du document — dates, nombres (deux décimales pour les montants), signes de pourcentage, et Oui/Non pour les cases à cocher. Les paramètres régionaux eux-mêmes sont déterminés de façon logique : ceux du modèle lorsqu’ils sont définis, sinon ceux du client, sinon les vôtres.
Les valeurs vides disparaissent — un champ vide n’imprime rien : des données clairsemées ne produisent donc jamais de lignes de libellés vides.
Les relevés ont leur propre liste — les colonnes ajoutées à l’ensemble de champs Account Ledger apparaissent à la fois sur l’écran Relevé de compte et dans le relevé de compte exporté, entre la colonne Référence et les colonnes de montant.

Colonnes du relevé : calquez-les sur la façon dont vous découpez le grand livre. La liste Account Ledger est le seul endroit où les champs supplémentaires s’affichent en véritables colonnes — à l’écran comme sur le relevé exporté. Les choix naturels sont les dimensions selon lesquelles votre équipe filtre déjà le grand livre : le relevé imprimé répond ainsi aux mêmes questions que l’écran.

Les champs que l’utilisateur qui génère le document ne peut pas voir ne s’impriment pas. Le contenu rendu respecte les accès de la personne qui génère le document — un champ restreint de la liste est simplement ignoré, comme un champ vide. Si un champ doit figurer sur les documents remis aux clients, assurez-vous que les personnes qui génèrent ces documents peuvent le lire.

Erreurs courantes à éviter

Erreur	Pourquoi c’est un problème	À faire à la place
Ajouter le champ à la mauvaise liste	Confusion entre en-tête et ligne, ou un tout autre objet de document — le champ ne s’imprime nulle part et la modification semble ne pas fonctionner	Chaque objet de document a sa propre liste PDF Template ; ouvrez l’objet dont provient le document, et choisissez délibérément l’en-tête ou la ligne
Tester sur un enregistrement où le champ est vide	Les champs vides sont ignorés par conception : une configuration parfaitement correcte ressemble alors à un échec	Régénérez un document dont le champ contient assurément une valeur
Faire apparaître des champs internes sur les documents remis aux clients	La liste s’applique à toute l’organisation, par type de document — une marge ou un code interne ajouté « pour une seule entité » s’imprime pour toutes les entités, à destination de tous les clients	Uniquement des champs utiles au lecteur ; l’analyse interne a sa place dans les rapports, pas sur les factures
S’attendre à ce que les listes des documents alimentent les colonnes du relevé	Le relevé lit une autre liste — celle d’Account Ledger —, si bien que les modifications des listes de documents ne l’atteignent jamais	Ajoutez les colonnes du relevé à l’ensemble de champs Account Ledger ; elles s’afficheront à l’écran et dans le PDF exporté
Répondre à un souhait de mise en page par davantage de champs	Dix rangées supplémentaires par ligne noient le document que le lecteur doit réellement déchiffrer	Trois champs supplémentaires bien choisis ; passez le modèle en orientation Paysage lorsqu’un document a réellement besoin de largeur

Les ajouts se font par type de document, pour toute l’organisation. Un champ ajouté à l’ensemble de l’objet Encaissement apparaît sur les reçus de toutes les entités. Ajoutez ce qui aide réellement le lecteur — trois champs supplémentaires bien choisis informent ; dix encombrent. Pour les documents qui en nécessitent beaucoup, l’orientation Paysage du modèle offre de la largeur.

Pour aller plus loin

Configuration des modèles de PDF — la mise en forme autour de vos champs.
Coordonnées de paiement sur les PDF — instructions permanentes ou données propres à l’enregistrement.
Types de documents pris en charge — la mise en page de base de chaque document.

Questions fréquentes

Les ensembles de champs s’appliquent par type de document, à l’échelle de l’organisation — les factures de toutes les entités partagent la même liste. La présentation propre à une entité (couleurs, sections, texte) relève des modèles ; des listes de champs propres à une entité ne sont pas une combinaison prise en charge.

Deux suspects habituels : le champ est vide sur le document que vous avez testé (les champs vides sont ignorés par conception), ou il a été ajouté au mauvais ensemble (en-tête au lieu de ligne, ou mauvais objet). Testez avec un enregistrement où le champ contient assurément une valeur.

La mise en page affiche les champs supplémentaires des lignes sous forme de bande de détail sous chaque ligne — le tableau principal reste ainsi lisible, quel que soit le nombre de champs supplémentaires. Si une valeur est assez importante pour mériter une colonne, elle a généralement sa place dans la description que votre équipe rédige sur la ligne.

Non — il s’agit d’un simple glisser-déposer effectué par un administrateur dans Configuration, et la prochaine génération le prend en compte. C’est tout l’intérêt de la conception : le contenu des documents évolue au rythme de la configuration, pas à celui des versions.

Ceux qui comportent des lignes : les factures de vente (avoirs compris) et les bons de commande. Les reçus et les bons de paiement sont des documents à montant unique — tous leurs champs supplémentaires vont dans la carte des détails de l’en-tête.

Non — les fichiers existants font partie de l’historique. La prochaine génération (ou une régénération manuelle, qui crée une nouvelle version du même fichier) prend en compte le nouveau champ.

Cet article vous a-t-il été utile ?