Extensibilité par ensembles de champs
Le mécanisme d’extension le plus puissant de REDA Financials ne nécessite aucun code et survit à chaque mise à niveau : les ensembles de champs. Ajoutez votre champ personnalisé au bon ensemble et il apparaît sur les formulaires de saisie, circule jusqu’au grand livre, filtre les rapports et s’imprime sur les PDF — les écrans et les moteurs du package lisent les ensembles à l’exécution. Plus de quarante ensembles sont livrés sur les objets transactionnels, répartis en trois familles.
Les trois familles
| Famille | Où elle apparaît | Usage classique |
|---|---|---|
| Interface | Colonnes/champs supplémentaires dans les formulaires de saisie packagés (lignes de facture, lignes d’écriture, formulaires d’encaissement…) | Les dimensions propres à votre secteur — Meridian a ajouté Property__c aux lignes de facture ; il apparaît dans la grille du formulaire comme s’il en avait toujours fait partie (et le même ensemble de lignes étend même les lignes de modèle récurrent) |
| Posting_Mapping | Reporte les valeurs de dimension des documents sur les Transactions comptables — et de là vers les filtres de rapport, les explorations du détail et les imputations à concordance de dimensions | Le même Property__c qui circule jusqu’au grand livre, pour que le compte de résultat puisse être produit par bien |
| PDF Template | Lignes d’en-tête / détails de ligne supplémentaires sur les documents générés (détails) | Mode de paiement sur les encaissements, codes projet sur les factures |
S’y ajoute l’ensemble Account Ledger sur Transaction comptable — des colonnes supplémentaires pour les grands livres de tiers et les relevés.
Si cela fonctionne, c’est parce que la plateforme laisse délibérément les ensembles de champs des objets gérés modifiables par l’administrateur. Vos modifications de la composition des ensembles sont des métadonnées de l’organisation — le package lit à l’exécution ce que contiennent les ensembles : c’est pourquoi il s’agit du principal mécanisme d’extensibilité sans code, et pourquoi il survit intact à chaque mise à niveau.
La recette de bout en bout (une nouvelle dimension en ~15 minutes)
Créez le champ là où il est saisi — et là où il arrive
Le champ personnalisé sur la ligne du document (par exemple Bien sur Ligne de facture de vente) et un champ portant le même nom d’API sur Transaction comptable. Des noms d’API identiques constituent le contrat qui permet aux valeurs de circuler.
Ajoutez-le à Interface (saisie) et à Posting_Mapping (circulation)
Gestionnaire d’objet → Ensembles de champs → faites glisser le champ dans l’ensemble. Le formulaire l’affiche immédiatement ; les comptabilisations commencent à le reporter ; la section Dimensions du panneau de rapport et les explorations du détail le prennent en compte automatiquement.
En option : l’imprimer, filtrer et faire concorder selon ce champ
Ensemble PDF Template → il s’imprime. Il apparaît parmi les filtres de dimension des rapports. Et les fonctionnalités qui tiennent compte des dimensions (concordance des imputations, clôture annuelle par dimension) le traitent comme le centre de coûts natif.
Selon les propres termes du package
Les ensembles de champs se documentent eux-mêmes — leurs descriptions packagées expriment l’intention de conception, mot pour mot. L’ensemble Interface de Ligne de facture de vente indique : « Add client-specific accounting dimensions here (e.g. Property__c, Cost_Centre__c, Sub_Property__c) » — ce ne sont que les exemples livrés ; les mêmes emplacements accueillent toutes les dimensions que suit votre secteur (centres de coûts, projets, services, fonds), et c’est exactement ainsi qu’une société comme Meridian les utilise pour ses biens. Quarante-trois ensembles de champs sont livrés sur les objets transactionnels ; le schéma se répète pour chaque objet, de sorte que le formulaire, la circulation vers le grand livre et le PDF de chaque type de document sont extensibles indépendamment.
Deux contrats sous-tendent les ensembles — l’un dans les descriptions packagées, l’autre dans le moteur lui-même — et méritent d’être énoncés clairement :
- La correspondance des noms est la tuyauterie. La circulation vers le grand livre se fait par nom d’API — tout comme la concordance des imputations : lorsque des imputations à concordance de dimensions entrent en jeu, le moteur exige que « API names match between the two Posting_Mapping FieldSets » sur les documents mis en correspondance. Un champ, un nom, partout.
- Les colonnes standard restent à l’écart. Les ensembles Interface sont réservés à vos seuls ajouts ; les colonnes packagées sont déjà affichées par les formulaires, et les rajouter duplique la colonne.
La dimension Bien de Meridian, partout à la fois
Un seul champ personnalisé — Property__c — ajouté selon la recette ci-dessus, et voici tous les endroits où il apparaît désormais sans une minute de configuration supplémentaire :
| Surface | Ce que voit Meridian |
|---|---|
| Formulaire de facture de vente | Une colonne Bien dans la grille des lignes, renseignée pour chaque ligne de loyer |
| Modèles récurrents | La même colonne sur les lignes de modèle — l’ensemble Interface des lignes étend les deux, si bien que le modèle de loyer mensuel porte lui aussi le bien |
| Le grand livre | La Transaction comptable de chaque ligne comptabilisée porte la valeur du bien (Posting_Mapping) |
| Rapports | Bien apparaît parmi les filtres de dimension — compte de résultat par immeuble, exploration du détail comprise |
| PDF générés | Le bien s’imprime sur les factures des locataires (ensemble PDF Template) |
| Extraction par IA | Le catalogue de champs OCR l’inclut — sur les factures fournisseurs importées, l’IA peut renseigner le bien lorsque le document l’indique implicitement |
Erreurs courantes à éviter
| Erreur | Pourquoi c’est pénalisant | À faire à la place |
|---|---|---|
| Des noms d’API différents sur le champ du document et sur son jumeau de Transaction comptable | La correspondance se fait par nom — les valeurs s’arrêtent silencieusement au document et n’atteignent jamais le grand livre | Créez les deux champs avec des noms d’API identiques avant de toucher aux ensembles |
| Ajouter à Interface mais pas à Posting_Mapping | Les utilisateurs renseignent consciencieusement un champ qui n’atteint jamais les rapports — on s’en aperçoit à la clôture mensuelle | Raisonnez par paires : saisie (Interface) et circulation (Posting_Mapping) ensemble |
| Rajouter des colonnes standard à un ensemble Interface | Les colonnes en double dans la grille perturbent le formulaire | Les ensembles Interface ne contiennent que vos champs |
| Renommer un champ de dimension après des mois de comptabilisations | Les anciennes lignes du grand livre conservent l’ancien champ ; les rapports scindent une dimension en deux | Choisissez les noms avec autant de soin que les comptes généraux ; un renommage est un projet de migration de données, pas une simple modification |
| Faire l’impasse sur la question des champs obligatoires | Les ensembles de champs rendent les champs disponibles, pas obligatoires — les dimensions facultatives finissent renseignées à 60 % | Associez la modification de l’ensemble de champs à une validation ou à un processus d’équipe qui rend la dimension fiable |
Pour aller plus loin
- Colonnes de PDF configurables par l’administrateur — la famille d’impression en détail.
- Dimensions de comptabilisation — la théorie comptable des dimensions.
- Lightning Web Components — quand les ensembles de champs ne suffisent pas.
Questions fréquentes
Les formulaires packagés sont des interfaces personnalisées (grilles, assistants), pas des présentations standard — les ensembles de champs sont le moyen par lequel un package géré vous permet d’étendre les écrans qui lui appartiennent. Même idée, surfaces plus riches : les formulaires, les moteurs, les rapports et les PDF les lisent tous.
Oui — vos modifications de la composition des ensembles sont des métadonnées de l’organisation, conservées d’une version du package à l’autre. C’est précisément pour cela que c’est la voie d’extension recommandée.
Techniquement, la marge est large ; en pratique, chaque dimension est un champ que les utilisateurs doivent renseigner et selon lequel les rapports doivent ventiler les chiffres. Deux ou trois dimensions bien gouvernées valent mieux que huit à moitié renseignées — c’est une décision de politique comptable plus qu’une décision technique.
Ni code, ni déploiement : c’est du pointer-cliquer dans le Gestionnaire d’objet, effectif immédiatement. Encadrez-la malgré tout comme tout changement de configuration — en sandbox d’abord, car un formulaire en production gagne une colonne dès que vous enregistrez.
Interface — les mêmes ensembles qui étendent les champs du formulaire de facture d’achat sont lus lorsque l’IA construit son catalogue de champs ; étendre le formulaire fait donc automatiquement connaître le nouveau champ à l’extracteur. Une seule définition, pour tous les consommateurs.
Oui. Tout champ personnalisé que vous avez ajouté et qui ne fait pas partie de l’ensemble de champs Posting Mapping reste modifiable dans tous les états — brouillon, comptabilisé, annulé, voire extourné. REDA ne verrouille que ses propres champs, les champs standard et tout champ dont vous avez fait une dimension de comptabilisation (ceux-ci sont écrits dans le grand livre lors de la comptabilisation de l’enregistrement, ils se figent donc avec lui). Les simples indicateurs, notes et clés d’intégration sont à vous et modifiables à tout moment. Une précision : « à vous » désigne un champ de l’espace de noms de votre propre organisation. Un champ personnalisé provenant d’un autre package géré installé porte un espace de noms ; le contrôle le traite donc comme gouverné plutôt que libre.
Cet article vous a-t-il été utile ?