Présentation de l’API
Cette section s’adresse aux administrateurs et aux développeurs d’intégrations — le seul endroit de cette base de connaissances où les noms de classes Apex ont leur place.
REDA Financials est natif Salesforce jusqu’à la moelle : chaque document est un objet personnalisé, chaque comptabilisation est un changement d’état piloté par un déclencheur, et chaque API Salesforce standard fonctionne donc d’emblée sur vos données comptables. Au-dessus de cette surface de plateforme, le package expose un petit ensemble délibéré de contrats stables. Cette présentation cartographie l’ensemble du paysage d’intégration.
Les quatre couches d’intégration
| Couche | Ce que c’est | Article |
|---|---|---|
| API Salesforce standard | REST, Bulk et Streaming (activé au niveau de l’organisation) sur les objets refin__ — CRUD, requêtes, chargement en masse. La couche qui fait l’essentiel du travail. | REST · Bulk · Streaming |
| L’API Apex globale | Cinq classes globales stables (ci-dessous) pour le calcul des taxes, la génération de PDF, la réception d’e-mails et les contrats d’extension destinés aux prestataires. | Développement Apex |
| Points d’ancrage déclaratifs | Une action Flow packagée (« Generate PDF Document ») ainsi que le principe selon lequel comptabiliser = une mise à jour du champ de statut que n’importe quel flux peut effectuer. | Intégration avec les flux |
| Extensibilité sans code | Des ensembles de champs qui étendent les formulaires, les dimensions du grand livre et les PDF sans toucher au code. | Extensibilité par ensembles de champs |
Tout ce qui est livré — et tout ce qui ne l’est délibérément pas
La planification d’une intégration commence par un inventaire honnête. Voici la surface packagée complète — et, tout aussi utile, les éléments que vous pourriez chercher et qui ne s’y trouvent pas, parce que la plateforme standard les fournit déjà :
| Surface | Ce qui est livré | Où c’est traité |
|---|---|---|
| Classes Apex globales | Cinq : refin.GlobalTaxService, refin.PDFGeneratorAPI, refin.BankFeedProvider, refin.EInvoiceProvider, refin.OCREmailHandler | Développement Apex · Packages d’extension |
| Actions invocables Flow | Une seule : Generate PDF Document (catégorie « REDA Financials ») | Intégration avec les flux |
| Objets et champs personnalisés | Chaque document, chaque ligne et chaque enregistrement du grand livre est un objet personnalisé refin__ ordinaire — CRUD complet et requêtes via les API standard | REST · Bulk |
| Ensembles de champs | 43 ensembles de champs packagés sur les objets transactionnels, répartis en trois familles (Interface, Posting_Mapping, PDF_Template) — modifiables par l’administrateur, sans code | Extensibilité par ensembles de champs |
| Points de terminaison REST personnalisés | Aucun — aucune classe @RestResource n’est livrée ; les points de terminaison standard sObject, query et composite constituent la surface REST | API REST |
| Événements de plateforme / CDC | Aucun dans le package ; la capture des données de modification (CDC) sur les objets refin__ est une fonctionnalité standard de l’organisation que votre administrateur peut activer | Streaming |
| Informations d’identification nommées / applications connectées | Aucune n’est livrée — les intégrations s’authentifient via l’application connectée et le flux OAuth propres à votre organisation, régis par vos politiques | — |
| Appels sortants | Exactement deux : le service d’IA de REDA pour les fonctionnalités d’IA (inclus dans la licence REDA Financials AI) et Open Exchange Rates pour la synchronisation quotidienne des taux de change | Fonctionnalités d’IA · Synchronisation FX |
La surface Apex globale — la liste complète
Treize types globaux constituent le contrat Apex stable du package. Cinq sont les points d’entrée du quotidien :
refin.GlobalTaxService— calculer par programme la taxe indirecte et la retenue à la source, sans DML, avec des résultats dont les comptes généraux sont entièrement résolus.refin.PDFGeneratorAPI— générer le PDF d’un document depuis Apex ou Flow.refin.BankFeedProvider— le contrat abstrait qu’implémentent les packages d’extension de flux bancaire.refin.EInvoiceProvider— le contrat abstrait qu’implémentent les prestataires de facturation électronique.refin.OCREmailHandler— le gestionnaire d’e-mails entrants derrière la facture par e-mail ; faites pointer un service de messagerie Salesforce vers lui.
Les huit restants existent pour les packages d’extension — les contrats de facturation électronique et les types qu’ils échangent, plus deux points d’entrée que vous appelez directement :
refin.EInvoiceQueueProvider,refin.EInvoiceDocumentProvider,refin.EInvoiceProvisioner— interfaces globales ajoutées à côté deEInvoiceProvider, car une classe abstraite globale publiée ne peut pas recevoir de nouvelles méthodes sans casser les packages qui l’étendent déjà.refin.EInvoiceDocument,refin.EInvoiceEvent,refin.EInvoiceProvisionResult— les types de transfert de données que ces contrats transmettent et renvoient.refin.EInvoiceStatusPollSchedulable— planifiez l’Interrogation du statut de facturation électronique selon votre propre planning cron plutôt que via la carte de la console d’administration.refin.EInvoiceTrailCreator— créez un Historique de facturation électronique pour les factures de vente comptabilisées ; également exposée comme action Flow.
Tout le reste du package est public — interne, invisible d’un espace de noms à l’autre et susceptible de changer. Si une classe ne figure pas dans cette liste, ne construisez rien qui en dépende.
Les services internes ne sont pas une API — même lorsque vous pouvez les voir
En lisant les journaux de débogage et les ensembles d’autorisations, vous rencontrerez des classes de service internes derrière les actions courantes — comptabilisation, rendu des PDF, import des relevés bancaires, appels externes d’IA et de taux de change, initialisation du contenu fiscal. Elles sont public, et non global — le code Apex des abonnés et des extensions ne peut pas les appeler au-delà de la frontière de l’espace de noms, et leur structure interne peut changer à chaque version ; rien de ce que vous construisez ne doit donc y faire référence par son nom :
| Ce qui se passe en interne | La voie prise en charge à la place |
|---|---|
| Le moteur de comptabilisation derrière chaque transition Brouillon → Comptabilisé | Définissez refin__Status__c sur 'Posted' — le déclencheur exécute le moteur pour vous |
| Le moteur derrière l’action de vue de liste Mise à jour groupée des statuts, qui ne contourne jamais les contrôles de comptabilisation standard | L’action de vue de liste, ou vos propres mises à jour de statut en masse via les API |
| Les mécanismes internes de rendu des PDF | refin.PDFGeneratorAPI.generateOne ou l’action Flow |
| Les mécanismes internes d’import des relevés bancaires | Le contrat BankFeedProvider et les opérations d’écriture via les API standard |
| Les deux chemins d’appels sortants (IA, taux de change) | Pilotez-les depuis la console d’administration ; ce ne sont pas des surfaces appelables |
| L’initialisation du contenu fiscal par pays derrière l’Assistant d’initialisation des taxes | Exécutez l’assistant dans l’interface utilisateur |
refin.PDFGeneratorAPI et refin.EInvoiceTrailCreator — les deux qui sous-tendent des actions Flow packagées. refin.GlobalTaxService, refin.BankFeedProvider, refin.OCREmailHandler et les types de contrat de facturation électronique ne sont accordés par aucun ensemble d’autorisations packagé ; accordez-les vous-même lorsque le contexte de votre flux ou de votre code Apex l’exige.
Gestion des versions et sécurité des mises à niveau
Les classes d’API du package sont compilées avec la version 65.0 de l’API Salesforce — refin.GlobalTaxService se déclare « @since API v65.0 ». La règle des packages gérés est la colonne vertébrale de votre planification :
- Global, c’est pour toujours : une fois publiées, les classes, méthodes et variables membres globales ne peuvent être ni supprimées ni voir leur signature modifiée par l’éditeur. Les treize types ci-dessus, les actions Flow qu’ils exposent et chaque objet et champ
refin__publié constituent votre surface stable. - Public signifie privé, en pratique : les classes internes peuvent être renommées, remaniées ou supprimées à chaque version — et comme elles sont invisibles d’un espace de noms à l’autre, rien de ce que vous livrez ne peut casser en dépendant d’elles, parce que rien de ce que vous livrez ne peut dépendre d’elles.
- Le comportement passe par les déclencheurs : les 52 déclencheurs packagés s’exécutent de manière identique sur les opérations DML de l’API, d’une mise à niveau à l’autre — il n’y a aucun indicateur de contournement à perdre, aucun mode spécial à retester.
Une intégration type, en esquisse
Le système de gestion immobilière de Meridian Properties Group facture les locataires ; REDA tient la comptabilité. L’intégration nocturne s’authentifie via la propre application connectée de Meridian, en tant qu’utilisateur d’intégration disposant de Accounts Receivable, insère chaque facture en brouillon de refin__Sales_Invoice__c avec ses lignes, puis passe chacune au statut Comptabilisé lors d’un second appel. Les numéros de document sont attribués à partir des séquences de l’entité à l’insertion, les valeurs par défaut de l’entité sont renseignées, et la comptabilisation exécute le moteur complet — taxes, taux de change, contrôles de période. Lorsqu’un enregistrement échoue (une période clôturée, par exemple), le message d’erreur renvoyé par l’API est la même phrase que celle qu’un utilisateur lirait à l’écran, ce qui raccourcit les échanges avec le support. Code personnalisé total dans REDA : aucun.
Le principe unique qui facilite l’intégration
L’API et l’interface utilisateur sont la même machine. Insérez une facture en brouillon via REST et elle reçoit son numéro de document, les valeurs par défaut de l’entité et ses validations exactement comme si elle avait été saisie. Passez son statut à Comptabilisé et le moteur de comptabilisation complet s’exécute — taxes, retenue à la source, taux de change, tous les contrôles. Il n’existe aucune porte dérobée d’intégration, ce qui signifie qu’il n’y a rien de particulier à apprendre : ce qu’un utilisateur peut faire, un utilisateur d’API peut le faire, selon les mêmes règles et avec les mêmes ensembles d’autorisations.
Pour aller plus loin
- API REST pour les données comptables — l’intégration du premier jour.
- Développement Apex sur REDA — les classes globales en détail.
- Packages d’extension — les contrats des prestataires.
Questions fréquentes
Oui — c’est précisément ce que signifie global dans un package géré : les signatures globales publiées ne peuvent être ni supprimées ni modifiées. C’est justement à cause de cette garantie que la surface reste réduite.
Du même ensemble d’autorisations packagé que détiendrait une personne effectuant ce travail (une intégration comptes fournisseurs comptabilise des factures d’achat → Accounts Payable). Les déclencheurs appliquent des règles identiques aux modifications faites via l’API et via l’interface utilisateur ; il n’y a pas de profil d’intégration distinct à inventer.
Configuration → Gestionnaire d’objet — chaque objet REDA y figure sous le préfixe refin__ (par exemple refin__Sales_Invoice__c, refin__Status__c). Les appels describe standard fonctionnent aussi, bien entendu.
Non — il est public, donc la plateforme elle-même le rend invisible depuis votre espace de noms. La voie prise en charge (et tout aussi adaptée aux traitements en masse) est la mise à jour du champ de statut : le déclencheur appelle le moteur avec l’ensemble des contrôles.
Exactement deux destinations d’appels externes sont livrées : le service d’IA de REDA (les fonctionnalités d’IA, incluses dans la licence REDA Financials AI) et Open Exchange Rates (synchronisation FX quotidienne, organisations multidevises). Pas de webhooks, aucun autre point de terminaison — tout ce que vous voyez d’autre lors d’une revue de sécurité ne provient pas de REDA.
Cet article vous a-t-il été utile ?