Intégrations AppExchange
Exécuter votre ERP sur Salesforce procure un avantage cumulatif : le reste de vos outils se connecte probablement déjà à Salesforce. CRM, prestataires de paiement, outils de gestion des notes de frais, signature électronique, gestion documentaire — les intégrations AppExchange arrivent dans la même organisation que votre comptabilité, et « s’intégrer à REDA Financials » se résume généralement à des mappages d’enregistrements ordinaires.
Les intégrations naturelles
| Catégorie | Forme de l’intégration |
|---|---|
| CRM (natif !) | Les mêmes enregistrements Compte SONT vos clients et vos fournisseurs — passer de l’opportunité à la facture relève d’un flux, pas d’un fichier d’interface. C’est la raison première pour laquelle la finance sur Salesforce l’emporte. |
| Prestataires de paiement | Les applications de prestataires qui écrivent des enregistrements de paiement → mappez les règlements vers des encaissements (l’imputation automatique se charge de la mise en correspondance) ; les lots de versements se rapprochent comme n’importe quelle ligne bancaire. |
| Gestion des notes de frais | Notes de frais approuvées → Factures d’achat de type charge via un flux ou l’API — réglées dès leur création, correctement comptabilisées. |
| Flux bancaires / facturation électronique | Des contrats d’extension à part entière plutôt que des intégrations génériques. |
| Signature électronique / outils documentaires | Fichiers et liens sur les mêmes enregistrements — un bail signé à côté du modèle récurrent de facture qu’il autorise. |
Évaluer toute application au regard de votre comptabilité — les quatre questions
- Où l’argent entre-t-il dans le grand livre ? Toute intégration qui « crée des données financières » doit aboutir à des documents REDA (factures, encaissements, écritures comptables) comptabilisés par le moteur habituel — jamais par écriture directe de données dans les transactions comptables.
- Qui est l’utilisateur d’intégration et de quel ensemble dispose-t-il ? Les ensembles d’autorisations du package régissent les écritures de données via l’API exactement comme celles effectuées dans l’interface — une application qui comptabilise des documents fournisseurs a besoin de l’ensemble Accounts Payable, et hérite des garde-fous des comptes fournisseurs.
- Que se passe-t-il en cas d’échec ? Les contrôles de comptabilisation refusent les données incorrectes avec des messages clairs — l’application doit les afficher, pas les passer sous silence.
- Respecte-t-elle les verrous ? Immutabilité des documents comptabilisés, périodes clôturées, protection des enregistrements rapprochés — une application bien conçue traite un refus comme une réponse.
Ce que votre revue de sécurité constatera
Lorsque l’équipe de sécurité audite l’organisation avant d’approuver une nouvelle application aux côtés de REDA Financials, voici l’intégralité de l’empreinte sortante du package — assez réduite pour être retenue par cœur :
| Élément | Ce qui est livré | À quoi il sert |
|---|---|---|
Site distant OCR_API | Voir Paramètres de site distant dans votre organisation | Point de terminaison du service d’IA de REDA pour les fonctionnalités de REDA Financials AI (OCR, rapprochement bancaire) — sans rapport avec le produit distinct REDA AI |
Site distant Open_Exchange_Rates | Voir Paramètres de site distant dans votre organisation | API Open Exchange Rates pour la synchronisation quotidienne automatisée des taux de change dans DatedConversionRate, via un service interne du package |
| Informations d’identification nommées | Aucune | — |
| Applications connectées | Aucune | — |
| Webhooks entrants / points de terminaison REST personnalisés | Aucun | — |
Tout le reste de ce qui communique avec votre organisation — les callbacks de l’application de paiement, l’OAuth du middleware — relève de ces applications et de la configuration propre à votre organisation, régie par vos politiques. C’est cette séparation qui rend la revue maîtrisable : la surface propre à REDA ne s’étend jamais parce que vous avez installé quelque chose à côté.
Provisionner l’utilisateur d’intégration
| L’application… | Attribuez cet ensemble d’autorisations du package |
|---|---|
| Crée et comptabilise des documents clients (facturation, paiements entrants) | Accounts Receivable v2 |
| Crée et comptabilise des documents fournisseurs (factures, paiements sortants) | Accounts Payable v2 |
| Lit les données financières pour le reporting/la BI | Read Only v2 |
| Interfaces au niveau des écritures comptables (paie, consolidation) | Accounting Controller v2 |
| Administre la configuration par programmation | Accounting Admin v2 — avec parcimonie, et uniquement en cas de réel besoin |
Utilisez les ensembles v2. À partir de la version 1.610, ce sont eux qu’il faut attribuer, et les seuls qui peuvent être attribués à un utilisateur disposant d’une licence Salesforce Platform ; les ensembles v1 sans suffixe sont obsolètes. Ajoutez un siège de licence REDA pour tout utilisateur qui écrit des documents comptables — le contrôle de licence s’applique aux écritures de données via l’API exactement comme aux utilisateurs humains. Une application, un utilisateur, un ensemble : des identifiants « d’intégration » partagés entre applications rendent toute question d’audit impossible à résoudre.
Erreurs courantes à éviter
| Erreur | Pourquoi c’est un problème | À faire plutôt |
|---|---|---|
| Laisser une application écrire des « enregistrements financiers » uniquement dans ses propres objets | L’argent existe dans l’application mais pas dans votre comptabilité — le grand livre ne le voit pas | Exigez que l’intégration aboutisse à des documents REDA comptabilisés ; les enregistrements de l’application peuvent y être liés |
| Attribuer Accounting Admin à l’utilisateur d’intégration « par précaution » | Chaque défaillance de l’application a désormais un rayon d’impact à l’échelle de la configuration | L’ensemble du package le plus restreint qui fait le travail ; n’élargissez les droits que sur la base de preuves |
| Omettre le mappage du champ Référence | Pas de clé d’idempotence, pas de piste de rapprochement jusqu’au système source | Mappez l’identifiant de transaction de l’application dans le champ Référence de chaque document qu’elle crée |
| Supposer que l’application « gère la comptabilité » parce qu’elle comptabilise sans erreur | La comptabilisation prouve la validité des données, pas le respect des règles comptables — des mappages de comptes généraux erronés se comptabilisent sans problème | Faites examiner le mappage des documents de l’application (comptes généraux, entités, taxes) par le contrôleur de gestion avant la mise en production, puis effectuez des contrôles ponctuels chaque mois |
Pour aller plus loin
- API REST pour les données comptables — les mécanismes sous-jacents à la plupart des applications.
- Packages d’extension — les contrats conçus spécifiquement pour cet usage.
- Présentation de l’API — la carte complète, sur une seule page.
Questions fréquentes
Par l’interface d’écritures classique : le système de paie exporte la synthèse, puis une tâche planifiée (ou l’import CSV du formulaire d’écriture comptable, pour la version manuelle) crée l’écriture comptable mensuelle. Les modèles récurrents prennent en charge le schéma fixe des charges à payer entre deux paies.
La réponse durable, c’est l’architecture : tout ce qui écrit des brouillons propres via l’API s’intègre bien. Pour connaître les applications partenaires et les extensions de prestataires actuelles, interrogez REDA — les écosystèmes évoluent plus vite que les manuels.
Les deux fonctionnent — un middleware utilise les mêmes API REST/Bulk. Choisissez selon le mode de fonctionnement de votre équipe ; côté REDA, le schéma (brouillon → comptabilisation → événements) est identique dans les deux cas.
Les déclencheurs et les contrôles du package s’exécutent à chaque écriture de données, quel qu’en soit l’auteur — une autre application ne peut pas les désactiver, et il n’existe aucun indicateur de contournement qu’elle pourrait trouver. Ce qui peut entrer en conflit, c’est la logique métier : par exemple, deux systèmes qui créent chacun des encaissements pour les mêmes paiements. C’est une question de conception de l’intégration, pas un risque lié à la plateforme.
C’est le cas particulier qui dispose de contrats à part entière : au lieu d’un mappage générique d’enregistrements, les prestataires implémentent refin.BankFeedProvider ou refin.EInvoiceProvider et se déclarent dans un enregistrement de configuration. Consultez Packages d’extension — l’évaluation de ces applications part du contrat, pas des quatre questions ci-dessus.
Cet article vous a-t-il été utile ?