Écart fonctionnel & business : modules NGO vs Odoo Enterprise 19
Ce que la suite NGO ajoute objectivement au-dessus d'Odoo Enterprise 19 sur la chaîne de collecte de fonds : dons réguliers SDD, encaissement, lettrage, base donateurs, marketing on/offline et service donateurs.
www.blueseamless.com · contact@blueseamless.com · Août 2026
ngo-19.0 · 18 modules analysés
odoo-ee-19.0 · 768 addons Enterprise
Périmètre NGO : ≈ 26 700 lignes Python + ≈ 20 300 lignes XML/JS
M
Méthode, périmètre et lecture
Sources. Comparaison réalisée par lecture directe du code des trois archives fournies : la suite NGO (v19.0) et Odoo Enterprise 19.0 (socle technique inclus). Aucune capacité n'est supposée : chaque ligne des tableaux correspond à des modèles, champs, crons, assistants ou contrôleurs identifiés dans le code.
Principe de lecture. La suite NGO ne remplace pas Odoo : elle s'appuie sur les rails Enterprise (mandats SEPA, lots de paiement, abonnements, lettrage, helpdesk, CODA) et ajoute la couche d'automatisation et de métier « collecte de fonds » qui n'existe pas nativement. Les tableaux distinguent donc ce qui est réutilisé du natif et ce qui est apporté.
Natif Odoo Enterprise 19
Apporté par la suite NGO
Absent / chemin manuel
Partiel (brique générique, pas le flux métier)
V
Vue d'ensemble — où se situe la valeur
Fig. V1 — Position de la suite : une couche métier « collecte de fonds » posée sur les rails Enterprise. Elle n'en réécrit aucun ; elle les alimente, les orchestre et les complète.
Fig. V2 — Chaîne de valeur du donateur. Chaque étape est couverte par au moins un bloc NGO (bleu) ; les rails Enterprise (prune) fournissent la mécanique standard sous-jacente.
Matrice de couverture par thème
| Thème (trame demandée) | Odoo Enterprise 19 | Enterprise + suite NGO |
|---|---|---|
| 1 · SDD Automation — enrôlement en masse des donateurs réguliers | ||
| 2 · SDD Batch — constitution planifiée des lots de prélèvement | ||
| 3 · SDD Reject — traitement des R-transactions SEPA | ||
| 4 · Payment Entries — lettrage des dons depuis le relevé | ||
| 5 · Partner Field Enlargement — fiche donateur | ||
| 6 · Partner Sync Marketing — source de vérité & RGPD | ||
| 7 · Online Fundraising — campagnes de dons en ligne | ||
| 8 · Offline Fundraising — publipostage postal & retours | ||
| 9 · Donor Care — guichet donateurs outillé |
Lecture : absent · partiel (briques génériques, pas le processus métier) · processus complet. Les points « partiels » sont détaillés ligne par ligne dans chaque thème ci-dessous.
1
SDD Automation — enrôlement en masse des donateurs réguliers
Modules
bs_sdd_automation
s'appuie sur
account_sepa_direct_debitpayment_sepa_direct_debitsale_subscriptionhelpdesk
Fig. 1 — De la ligne CSV au donateur régulier facturable. En natif, les 5 objets du bas existent mais doivent être créés et reliés à la main, écran par écran, pour chaque donateur.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Mandat SDD : modèle, états, échéance, PDF, XML pain.008 | Natif | Réutilisé+ code mandat externe (agence) |
| Don récurrent = abonnement facturé automatiquement | Natif | Réutiliséplans / jour de facturation centralisés |
| Import en masse de bulletins de domiciliation (CSV multi-agences) | Absent | Apportédossiers surveillés, mapping de colonnes par source, archivage processed / error / rejects |
| Alimentation hors interface : dépôt de fichiers FTP dans des dossiers surveillés | Absentimport = téléversement manuel dans l'UI | Apporté1 sous-dossier par fournisseur, traitement en tâche de fond (cron + verrou) — aucune charge sur l'interface Odoo |
| Rattachement automatique de chaque abonnement créé : journal + UTM | Absent | Apportéjournal de facturation dédié, médium SDD, source UTM = nom du fichier importé → traçabilité par fournisseur / vague |
| Purge programmée des fichiers importés (RGPD) | Absent | Apportécron quotidien activable, délai de rétention paramétrable sur les CSV traités |
| Couche d'import dédiée : fichiers et lignes avec statuts, sans toucher au standard | Absent | Apportésdd.import.file (brouillon / en cours / terminé / partiel / erreur) + sdd.entry (brouillon / en attente / traité / doublon / quarantaine / rejeté) — les objets natifs ne sont créés qu'à la validation |
| Journal d'audit des traitements | Absent | Apportéchatter + historique des changements d'état sur chaque fichier et chaque ligne (mail.thread, tracking) ; suivi suspendu pendant l'import de masse pour la performance |
| Import des PDF de mandats signés, rattachés au mandat standard | Absentpièce jointe manuelle au cas par cas | Apportédossier surveillé, correspondance par code mandat, cron paramétrable + synchro manuelle, archivage processed — le PDF signé rejoint le sdd.mandate natif |
| Contrôle qualité paramétrable des entrées | Absent | Apportérègles typées (IBAN SEPA, fréquences, champs requis, date de signature, unicité mandat, contrôle de champ avec opérateurs et dates relatives) + sévérité |
| Création automatique de la chaîne donateur (5 objets) | Partielsaisie manuelle objet par objet | Apportépipeline transactionnel : tout ou rien, erreur = quarantaine motivée |
| Détection de doublons dédiée au flux (contacts candidats, abonnement déjà actif) | Partieldata_cleaning générique | Apportéétat « doublon » avec candidats proposés, distinct de la quarantaine |
| Boucle qualité vers l'externe : escalade ticket, export des rejets à l'agence | Absent | Apportéwizards ticket / rejet / bypass / export, journal RGPD masqué (IBAN, email) |
Plus-value objective.
- Le natif fournit les objets (mandat, abonnement) ; il ne fournit aucun flux : chaque donateur recruté en rue exigerait la création manuelle et le chaînage de 5 enregistrements dans 4 applications.
- La qualité de données devient un processus tracé et audité — chaque changement d'état est historisé — (règles, quarantaine, doublons, retour agence) au lieu d'un contrôle humain implicite — condition de fiabilité des prélèvements ultérieurs.
- L'atomicité (savepoint) garantit qu'aucun donateur « à moitié créé » ne pollue la base en cas d'erreur.
- L'alimentation par dépôt FTP et la purge automatique des CSV nominatifs déchargent l'interface et intègrent la rétention RGPD au flux — chaque don importé arrive déjà rattaché à son journal et à ses UTM, donc mesurable par fournisseur sans retraitement.
2
SDD — Batch : constitution planifiée des lots de prélèvement
Modules
bs_batch_paiement_automation
s'appuie sur
account_batch_paymentaccount_iso20022account_sepa_direct_debitsale_subscriptionqueue_job (OCA)
Fig. 2 — La date de collecte est calculée en jours ouvrés TARGET2 ; le lot et le fichier bancaire s'appuient sur la mécanique native. En natif, la sélection des paiements et la création du lot restent des opérations manuelles, sans calendrier interbancaire ni journal d'exécution.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Lots de paiements + fichiers SEPA (pain.008 / pain.001) | Natif | Réutilisé |
| Constitution automatique et planifiée des lots (par journal, par schéma) | Partielcréation manuelle uniquement | Apportéjobs héritant d'ir.cron, prélèvements clients et virements fournisseurs |
| Calcul des dates en jours ouvrés interbancaires | Absent | Apportécalendrier TARGET2 (BCE) administrable, offset de collecte D-n |
| Prévision d'encaissement SDD | Absent | Apportévue SQL : factures dues + factures projetées des abonnements, horizon 365 j |
| Traçabilité des exécutions | Absent | Apportéruns horodatés, montants, factures écartées avec motif, alertes email |
Plus-value objective.
- Supprime une tâche comptable récurrente (constituer les lots à la bonne date) et le risque de collecte un jour non ouvré — cause classique de rejets techniques.
- Donne à la trésorerie une visibilité chiffrée des encaissements SDD à venir, y compris sur des factures pas encore émises.
- L'audit trail des runs rend la chaîne de prélèvement contrôlable (qui, quand, combien, ce qui a été écarté et pourquoi).
3
SDD — Reject : traitement des R-transactions SEPA
Modules
bs_sdd_rejectsbs_parse_file
s'appuie sur
l10n_be_codaaccount_accountantaccount_batch_payment
Fig. 3 — Chaque rejet devient un dossier qualifié avec actions guidées. Odoo Enterprise 19 n'offre aucune détection ni gestion des R-transactions : la ligne de rejet apparaît dans le relevé comme un mouvement quelconque, à investiguer manuellement. La détection repose sur les champs exposés par le parseur enrichi (bs_parse_file) — le même socle qui alimente le lettrage (thème 4) et la boucle VCS du publipostage (thème 8).
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Import du relevé bancaire CODA | Natif | Réutiliséparseur enrichi (codes, contrepartie, VCS) |
| Détection automatique des rejets / retours / remboursements / contrepassations | Absent | Apportéfondée sur les champs du parseur enrichi (motif de rejet, type de R-transaction, références), validée contre le référentiel des motifs SEPA |
| Référentiel des motifs SEPA avec pilotage | Absent | Apportécode → catégorie métier, sévérité, action recommandée, action serveur associée |
| Rattachement automatique au dossier d'origine | Absent | Apportélot, paiement, mandat, facture, abonnement, contact |
| Résolution outillée | Absent | Apportééchéance selon sévérité, replanification du prélèvement, avoir, états nouveau → clôturé |
| Visibilité des rejets côté abonnement / donateur | Absent | Apporté |
Plus-value objective.
- Les rejets (provision insuffisante, compte clos, contestation) sont le principal point de fuite d'un programme de dons réguliers ; sans outil, chaque cas exige une enquête manuelle multi-écrans.
- La distinction récupérable / non récupérable (sévérité + action recommandée) transforme un travail comptable en processus de rétention du donateur.
- Les délais de re-présentation et l'historique par mandat deviennent mesurables — base d'un pilotage du taux d'attrition.
4
Payment Entries — lettrage des dons depuis le relevé bancaire
Modules
bs_donation_bank_reconciliationbs_parse_filebs_invoice_enrichment
s'appuie sur
account_accountantl10n_be_coda
Fig. 4 — Du mouvement bancaire brut à un don comptabilisé, lettré et attribué à son appel. Les règles de lettrage natives (account.reconcile.model) savent pointer une écriture ; elles ne créent ni donateur, ni facture de don, ni lien avec la campagne.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Widget de lettrage + règles de rapprochement génériques | Natif | Réutiliséwidget patché pour le flux don |
| Exposition complète des données CODA | Partielparse minimal (montant, libellé, partenaire) | Apportéchamps structurés : contrepartie, IBAN/BIC, adresse, VCS + type, codes transaction, dates valeur, JSON brut |
| Décodage VCS → mailing d'appel + contact + donateur | Absent | Apporté |
| File de traitement des dons (transaction par ligne, états, tableau de bord) | Absent | Apporté |
| Création / mise à jour du donateur depuis le relevé (nom, IBAN, adresse) | Absent | Apporté+ correspondances « références permanentes » historiques |
| Règles de classification métier du don | Partielrègles comptables, sans logique donateur | Apportéconnu / inconnu, particulier / société, seuils, mots-clés, opérateur ET/OU, règle par défaut |
| Facturation en masse des dons + lettrage | Absent | Apporté |
| Attribution du don à la campagne (UTM sur facture) | Absent | Apporté |
| Dates de paiement banque visibles sur la facture | Absent | Apportébs_invoice_enrichment |
Plus-value objective.
- Les dons par virement arrivent par centaines de lignes ; le natif impose de traiter chaque ligne comme une écriture comptable anonyme. Ici chaque ligne devient un don identifié, comptabilisé et rattaché à son appel.
- L'attribution VCS → mailing fournit le ROI réel par campagne sans saisie — impossible nativement.
- La facture de don sur produit marqué + registre national + titulaire fiscal du foyer (thème 5) constitue le socle de calcul des attestations fiscales.
5
Partner Field Enlargement — la fiche donateur
Modules
bs_partner_extendedbs_partner_extend_marketing_bridg
s'appuie sur
contactspartnershipdata_cleaning
Fig. 5 — Le socle natif gère un contact commercial ; la couche NGO en fait une fiche donateur : identité complète, foyer fiscal, identifiants officiels et segmentation. Odoo 19 a même retiré la civilité, que la suite restaure.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Fiche contact de base, étiquettes, comptes bancaires | Natif | Réutilisé |
| Grades de membres / cotisations | Natifpartnership | Réutilisé |
| Prénom / nom séparés, nom de naissance, nom d'usage | Absent | Apporté |
| Civilité, abréviation, formule de salutation | Absentretiré en v19 | Apportérestauré + référentiels |
| Naissance, âge, tranche d'âge, genre, nationalité, décès | Absent | Apportédécès = coupure marketing automatique |
| Adresse décomposée (rue / n° / boîte) | Absent | Apportéindispensable au publipostage et aux imports |
| N° de registre national validé | Absent | Apportéprérequis attestations fiscales / Belcotax |
| Données d'entreprise BCE / KBO, codes NACE | Partielpartner_autocomplete (IAP) | Apportéréférentiel dédié BE + contrôle d'adresse |
| Foyers / couples avec titulaire fiscal | Absent | Apporté |
| Relations typées entre contacts | Absent | Apporté |
Plus-value objective.
- Une base donateurs vit des courriers nominatifs, des reçus fiscaux et de la segmentation : aucun de ces trois usages n'est possible avec la fiche native (pas de civilité, pas d'adresse décomposée, pas d'identifiant fiscal, pas de foyer).
- Le couple / foyer avec titulaire fiscal résout un cas réel : deux conjoints donnent ensemble, l'attestation doit viser une personne physique identifiée.
- La gestion du décès protège la réputation (arrêt automatique des sollicitations) — risque très concret en collecte.
6
Partner Sync Marketing — source de vérité unique & RGPD
Modules
bs_mailing_hubbs_partner_extend_marketing_bridg
s'appuie sur
mass_mailingdata_cleaningdocuments
Fig. 6 — Le donateur n'existe qu'une fois ; le marketing en consomme une projection gouvernée, avec des consentements opposables par canal.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Listes de diffusion, contacts marketing, blacklist email globale | Natif | Réutilisé |
| Synchronisation res.partner ↔ mailing.contact | Absentdeux silos | Apporté1 contact par partenaire / société, champs protégés à l'ORM |
| Gouvernance : opt-in explicite, exclusion des contacts système, archivage sûr | Absent | Apportéblacklist automatique de l'email à l'archivage, restauration contrôlée |
| Consentement par canal, horodaté, sourcé, avec preuve documentaire | Absent | Apportéemail · SMS · téléphone · postal · WhatsApp ; synthèse lecture seule sur la fiche |
| Motifs de blacklist administrables | Absent | Apporté |
| Déduplication | Natifdata_cleaning | Étendudétection par email + orchestration depuis la fiche |
Plus-value objective.
- Sans synchronisation, toute organisation qui segmente sérieusement finit avec deux bases divergentes (adresses, décès, opt-out non répercutés) — risque opérationnel et légal.
- Le consentement par canal avec date, source et pièce jointe rend la conformité RGPD démontrable, pas seulement déclarée.
- La blacklist motivée et l'archivage sûr évitent le pire scénario du secteur : réécrire à un donateur qui a demandé l'oubli.
7
Online Fundraising — campagnes de dons en ligne
Modules
bs_ad_fundraisingbs_utm_dimension
appui email
bs_mass_mailing_snippetsbs_mass_mailing_device_visibilitybs_email_marketing_sale_config
s'appuie sur
websitepaymentmass_mailing
Fig. 7 — Une page de don pilotée par un objet campagne, avec bascule ponctuel / récurrent, comptabilisation et attribution fine des canaux.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Formulaire de don : montants prédéfinis + montant libre, paiement en ligne | Partielsnippet « Donation » basique | Remplacé / étendusnippet OWL configurable, hero, FAQ stylable, variantes d'images |
| Objet campagne : objectif, montant collecté, progression, période, responsable, états | Absent | Apporté |
| Don récurrent en ligne (mandat + abonnement) dans le parcours donateur | Partielbriques présentes (payment_sepa_direct_debit, sale_subscription) mais non assemblées en parcours de don | Apportéproduit ponctuel / produit récurrence par campagne |
| Traçage comptable du don en ligne | Partielpayment.transaction seulement | Apportétransaction de collecte séquencée, reliée au paiement, base de facturation |
| Attribution multi-dimensions | PartielUTM : campagne / source / médium | Apportédimensions supplémentaires définies par le métier, pivotables comme le natif |
| Industrialisation des emails d'appel | Partielbuilder générique | Apportébibliothèque de sections, visibilité desktop / mobile par bloc, journal-produit-analytique par mailing |
Plus-value objective.
- Le don natif est un paiement anonyme sans pilotage : ni objectif affiché, ni suivi de campagne, ni document comptable — insuffisant pour rendre compte à un conseil d'administration ou à un bailleur.
- Le récurrent en ligne est l'enjeu économique majeur (valeur vie du donateur) : la suite assemble les briques Enterprise en un parcours effectif.
- Les dimensions UTM supplémentaires permettent d'analyser la collecte selon les axes du métier (thématique, segment, vague…) sans développement.
8
Offline Fundraising — publipostage postal & retours
Modules
bs_direct_mailingbs_mailing_return
boucle retour via
bs_parse_filebs_donation_bank_reconciliation
s'appuie sur
mass_mailingutm
Fig. 8 — La boucle complète : de l'export imprimeur à l'attribution du don et au nettoyage NPAI. Le natif ne couvre que l'email (mass_mailing) et la lettre unitaire via service payant (snailmail) — aucune campagne postale, aucune référence de paiement par destinataire, aucune gestion des retours.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Campagnes email / SMS | NatifSMS via crédits IAP · marketing_automation | Réutilisé |
| Lettre unitaire (facture, relance) via service en ligne | Natifsnailmail (IAP) | Hors sujetusage différent du publipostage |
| Campagne postale de masse (workflow, ciblage, coût, tableau de bord) | Absent | Apporté |
| Export imprimeur : CSV à colonnes paramétrables + dépôt FTP / SFTP sécurisé | Absent | Apportépréréglages VCS / QR, vérification d'empreinte du serveur |
| Référence de paiement unique par destinataire (VCS + QR) | Absent | Apportéclé de toute la mesure de retour |
| Attribution automatique des dons reçus au mailing | Absent | Apportéboucle CODA / VCS avec le thème 4 |
| Gestion des retours NPAI | Absent | Apportéwizard scanner, motifs → actions serveur, stats par mailing / campagne |
Plus-value objective.
- Le publipostage reste le premier canal de collecte de nombreuses ONG ; nativement, Odoo ne sait ni le produire, ni le mesurer.
- La référence VCS par destinataire ferme la boucle : chaque euro reçu est rattaché à son appel sans aucune saisie — le taux de retour devient un fait comptable, pas une estimation.
- Le traitement NPAI convertit un coût récurrent (courriers perdus à chaque vague) en amélioration continue de la base.
9
Donor Care — guichet donateurs outillé
Modules
bs_help_donor_carebs_sdd_donor_care
s'appuie sur
helpdeskbs_sdd_automation
Fig. 9 — Un agent au téléphone crée un donateur régulier complet depuis le ticket, avec les mêmes garde-fous que l'import de masse — sans naviguer dans quatre applications ni polluer les écrans d'import.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Helpdesk : équipes, étapes, SLA, portail, rapports | Natif | Réutilisé |
| Équipe « Donor Care » prête à l'emploi | Absent | Apportéconfiguration livrée, étapes natives réutilisées |
| Création guidée de la chaîne donateur depuis un ticket | Absent | Apportépipeline dédié réutilisant la configuration SDD, sans créer d'entrées d'import |
| Garde-fous du guichet (doublon d'abonnement actif, plan / jour de facturation) | Absent | Apporté |
| Tickets automatiques depuis les anomalies (quarantaine, rejets) | Absent | Apportévia les thèmes 1 et 3 |
Plus-value objective.
- Le service donateurs devient un canal d'enrôlement à part entière (téléphone, courrier) avec la même rigueur que l'import de masse.
- Les anomalies des chaînes SDD (quarantaine, rejets) arrivent comme tickets qualifiés : le back-office et la relation donateur travaillent dans le même outil.
- Sans la suite, un agent devrait créer et relier manuellement 5 objets dans 4 applications par donateur pris au téléphone.
S
Synthèse & points d'objectivité
Fig. S1 — L'effort se concentre là où le natif s'arrête : enrôlement de masse, collecte en ligne, lettrage des dons.
Ce que montre objectivement la comparaison
Sur les 9 thèmes, Odoo Enterprise 19 fournit des briques génériques solides (mandats, lots, XML SEPA, abonnements, lettrage, helpdesk, email marketing) mais aucun processus de collecte de fonds : pas d'enrôlement en masse, aucune gestion des rejets SEPA, pas de lettrage « don » avec attribution, une fiche contact commerciale, deux référentiels marketing non synchronisés, un don en ligne réduit à un paiement, aucun publipostage postal, un helpdesk sans lien avec le donateur. La suite NGO couvre précisément ces neuf écarts en réutilisant systématiquement les rails Enterprise plutôt qu'en les dupliquant — c'est vérifiable dans les dépendances déclarées de chaque module.
Limites et conditions — à énoncer pour rester objectif
Applications requises. La suite s'installe au-dessus d'Odoo Enterprise 19 et s'appuie notamment sur account_accountant, account_batch_payment, account_sepa_direct_debit, account_iso20022, sale_subscription, helpdesk, l10n_be_coda, data_cleaning, documents.
Dépendances externes. queue_job (OCA) pour le thème 2 ; bibliothèques Python paramiko (SFTP) et python-stdnum (registre national).
Ancrage belge. CODA, communication structurée VCS, BCE/KBO et registre national sont des standards belges : accélérateur majeur en Belgique, adaptation nécessaire pour d'autres pays (le SEPA — mandats, lots, rejets, TARGET2 — reste, lui, paneuropéen).
Répartition de la valeur. Là où le natif excelle (génération XML, moteur d'abonnement, widget de lettrage, envoi d'emails), la suite ne réécrit rien : la plus-value est l'orchestration métier et l'automatisation de volume, pas la technologie de base.
Ce que la suite NGO ajoute objectivement au-dessus d'Odoo Enterprise 19 sur la chaîne de collecte de fonds : dons réguliers SDD, encaissement, lettrage, base donateurs, marketing on/offline et service donateurs.
www.blueseamless.com · contact@blueseamless.com · Août 2026
ngo-19.0 · 18 modules analysés
odoo-ee-19.0 · 768 addons Enterprise
Périmètre NGO : ≈ 26 700 lignes Python + ≈ 20 300 lignes XML/JS
M
Méthode, périmètre et lecture
Sources. Comparaison réalisée par lecture directe du code des trois archives fournies : la suite NGO (v19.0) et Odoo Enterprise 19.0 (socle technique inclus). Aucune capacité n'est supposée : chaque ligne des tableaux correspond à des modèles, champs, crons, assistants ou contrôleurs identifiés dans le code.
Principe de lecture. La suite NGO ne remplace pas Odoo : elle s'appuie sur les rails Enterprise (mandats SEPA, lots de paiement, abonnements, lettrage, helpdesk, CODA) et ajoute la couche d'automatisation et de métier « collecte de fonds » qui n'existe pas nativement. Les tableaux distinguent donc ce qui est réutilisé du natif et ce qui est apporté.
Natif Odoo Enterprise 19
Apporté par la suite NGO
Absent / chemin manuel
Partiel (brique générique, pas le flux métier)
V
Vue d'ensemble — où se situe la valeur
Fig. V1 — Position de la suite : une couche métier « collecte de fonds » posée sur les rails Enterprise. Elle n'en réécrit aucun ; elle les alimente, les orchestre et les complète.
Fig. V2 — Chaîne de valeur du donateur. Chaque étape est couverte par au moins un bloc NGO (bleu) ; les rails Enterprise (prune) fournissent la mécanique standard sous-jacente.
Matrice de couverture par thème
| Thème (trame demandée) | Odoo Enterprise 19 | Enterprise + suite NGO |
|---|---|---|
| 1 · SDD Automation — enrôlement en masse des donateurs réguliers | ||
| 2 · SDD Batch — constitution planifiée des lots de prélèvement | ||
| 3 · SDD Reject — traitement des R-transactions SEPA | ||
| 4 · Payment Entries — lettrage des dons depuis le relevé | ||
| 5 · Partner Field Enlargement — fiche donateur | ||
| 6 · Partner Sync Marketing — source de vérité & RGPD | ||
| 7 · Online Fundraising — campagnes de dons en ligne | ||
| 8 · Offline Fundraising — publipostage postal & retours | ||
| 9 · Donor Care — guichet donateurs outillé |
Lecture : absent · partiel (briques génériques, pas le processus métier) · processus complet. Les points « partiels » sont détaillés ligne par ligne dans chaque thème ci-dessous.
1
SDD Automation — enrôlement en masse des donateurs réguliers
Modules
bs_sdd_automation
s'appuie sur
account_sepa_direct_debitpayment_sepa_direct_debitsale_subscriptionhelpdesk
Fig. 1 — De la ligne CSV au donateur régulier facturable. En natif, les 5 objets du bas existent mais doivent être créés et reliés à la main, écran par écran, pour chaque donateur.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Mandat SDD : modèle, états, échéance, PDF, XML pain.008 | Natif | Réutilisé+ code mandat externe (agence) |
| Don récurrent = abonnement facturé automatiquement | Natif | Réutiliséplans / jour de facturation centralisés |
| Import en masse de bulletins de domiciliation (CSV multi-agences) | Absent | Apportédossiers surveillés, mapping de colonnes par source, archivage processed / error / rejects |
| Alimentation hors interface : dépôt de fichiers FTP dans des dossiers surveillés | Absentimport = téléversement manuel dans l'UI | Apporté1 sous-dossier par fournisseur, traitement en tâche de fond (cron + verrou) — aucune charge sur l'interface Odoo |
| Rattachement automatique de chaque abonnement créé : journal + UTM | Absent | Apportéjournal de facturation dédié, médium SDD, source UTM = nom du fichier importé → traçabilité par fournisseur / vague |
| Purge programmée des fichiers importés (RGPD) | Absent | Apportécron quotidien activable, délai de rétention paramétrable sur les CSV traités |
| Couche d'import dédiée : fichiers et lignes avec statuts, sans toucher au standard | Absent | Apportésdd.import.file (brouillon / en cours / terminé / partiel / erreur) + sdd.entry (brouillon / en attente / traité / doublon / quarantaine / rejeté) — les objets natifs ne sont créés qu'à la validation |
| Journal d'audit des traitements | Absent | Apportéchatter + historique des changements d'état sur chaque fichier et chaque ligne (mail.thread, tracking) ; suivi suspendu pendant l'import de masse pour la performance |
| Import des PDF de mandats signés, rattachés au mandat standard | Absentpièce jointe manuelle au cas par cas | Apportédossier surveillé, correspondance par code mandat, cron paramétrable + synchro manuelle, archivage processed — le PDF signé rejoint le sdd.mandate natif |
| Contrôle qualité paramétrable des entrées | Absent | Apportérègles typées (IBAN SEPA, fréquences, champs requis, date de signature, unicité mandat, contrôle de champ avec opérateurs et dates relatives) + sévérité |
| Création automatique de la chaîne donateur (5 objets) | Partielsaisie manuelle objet par objet | Apportépipeline transactionnel : tout ou rien, erreur = quarantaine motivée |
| Détection de doublons dédiée au flux (contacts candidats, abonnement déjà actif) | Partieldata_cleaning générique | Apportéétat « doublon » avec candidats proposés, distinct de la quarantaine |
| Boucle qualité vers l'externe : escalade ticket, export des rejets à l'agence | Absent | Apportéwizards ticket / rejet / bypass / export, journal RGPD masqué (IBAN, email) |
Plus-value objective.
- Le natif fournit les objets (mandat, abonnement) ; il ne fournit aucun flux : chaque donateur recruté en rue exigerait la création manuelle et le chaînage de 5 enregistrements dans 4 applications.
- La qualité de données devient un processus tracé et audité — chaque changement d'état est historisé — (règles, quarantaine, doublons, retour agence) au lieu d'un contrôle humain implicite — condition de fiabilité des prélèvements ultérieurs.
- L'atomicité (savepoint) garantit qu'aucun donateur « à moitié créé » ne pollue la base en cas d'erreur.
- L'alimentation par dépôt FTP et la purge automatique des CSV nominatifs déchargent l'interface et intègrent la rétention RGPD au flux — chaque don importé arrive déjà rattaché à son journal et à ses UTM, donc mesurable par fournisseur sans retraitement.
2
SDD — Batch : constitution planifiée des lots de prélèvement
Modules
bs_batch_paiement_automation
s'appuie sur
account_batch_paymentaccount_iso20022account_sepa_direct_debitsale_subscriptionqueue_job (OCA)
Fig. 2 — La date de collecte est calculée en jours ouvrés TARGET2 ; le lot et le fichier bancaire s'appuient sur la mécanique native. En natif, la sélection des paiements et la création du lot restent des opérations manuelles, sans calendrier interbancaire ni journal d'exécution.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Lots de paiements + fichiers SEPA (pain.008 / pain.001) | Natif | Réutilisé |
| Constitution automatique et planifiée des lots (par journal, par schéma) | Partielcréation manuelle uniquement | Apportéjobs héritant d'ir.cron, prélèvements clients et virements fournisseurs |
| Calcul des dates en jours ouvrés interbancaires | Absent | Apportécalendrier TARGET2 (BCE) administrable, offset de collecte D-n |
| Prévision d'encaissement SDD | Absent | Apportévue SQL : factures dues + factures projetées des abonnements, horizon 365 j |
| Traçabilité des exécutions | Absent | Apportéruns horodatés, montants, factures écartées avec motif, alertes email |
Plus-value objective.
- Supprime une tâche comptable récurrente (constituer les lots à la bonne date) et le risque de collecte un jour non ouvré — cause classique de rejets techniques.
- Donne à la trésorerie une visibilité chiffrée des encaissements SDD à venir, y compris sur des factures pas encore émises.
- L'audit trail des runs rend la chaîne de prélèvement contrôlable (qui, quand, combien, ce qui a été écarté et pourquoi).
3
SDD — Reject : traitement des R-transactions SEPA
Modules
bs_sdd_rejectsbs_parse_file
s'appuie sur
l10n_be_codaaccount_accountantaccount_batch_payment
Fig. 3 — Chaque rejet devient un dossier qualifié avec actions guidées. Odoo Enterprise 19 n'offre aucune détection ni gestion des R-transactions : la ligne de rejet apparaît dans le relevé comme un mouvement quelconque, à investiguer manuellement. La détection repose sur les champs exposés par le parseur enrichi (bs_parse_file) — le même socle qui alimente le lettrage (thème 4) et la boucle VCS du publipostage (thème 8).
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Import du relevé bancaire CODA | Natif | Réutiliséparseur enrichi (codes, contrepartie, VCS) |
| Détection automatique des rejets / retours / remboursements / contrepassations | Absent | Apportéfondée sur les champs du parseur enrichi (motif de rejet, type de R-transaction, références), validée contre le référentiel des motifs SEPA |
| Référentiel des motifs SEPA avec pilotage | Absent | Apportécode → catégorie métier, sévérité, action recommandée, action serveur associée |
| Rattachement automatique au dossier d'origine | Absent | Apportélot, paiement, mandat, facture, abonnement, contact |
| Résolution outillée | Absent | Apportééchéance selon sévérité, replanification du prélèvement, avoir, états nouveau → clôturé |
| Visibilité des rejets côté abonnement / donateur | Absent | Apporté |
Plus-value objective.
- Les rejets (provision insuffisante, compte clos, contestation) sont le principal point de fuite d'un programme de dons réguliers ; sans outil, chaque cas exige une enquête manuelle multi-écrans.
- La distinction récupérable / non récupérable (sévérité + action recommandée) transforme un travail comptable en processus de rétention du donateur.
- Les délais de re-présentation et l'historique par mandat deviennent mesurables — base d'un pilotage du taux d'attrition.
4
Payment Entries — lettrage des dons depuis le relevé bancaire
Modules
bs_donation_bank_reconciliationbs_parse_filebs_invoice_enrichment
s'appuie sur
account_accountantl10n_be_coda
Fig. 4 — Du mouvement bancaire brut à un don comptabilisé, lettré et attribué à son appel. Les règles de lettrage natives (account.reconcile.model) savent pointer une écriture ; elles ne créent ni donateur, ni facture de don, ni lien avec la campagne.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Widget de lettrage + règles de rapprochement génériques | Natif | Réutiliséwidget patché pour le flux don |
| Exposition complète des données CODA | Partielparse minimal (montant, libellé, partenaire) | Apportéchamps structurés : contrepartie, IBAN/BIC, adresse, VCS + type, codes transaction, dates valeur, JSON brut |
| Décodage VCS → mailing d'appel + contact + donateur | Absent | Apporté |
| File de traitement des dons (transaction par ligne, états, tableau de bord) | Absent | Apporté |
| Création / mise à jour du donateur depuis le relevé (nom, IBAN, adresse) | Absent | Apporté+ correspondances « références permanentes » historiques |
| Règles de classification métier du don | Partielrègles comptables, sans logique donateur | Apportéconnu / inconnu, particulier / société, seuils, mots-clés, opérateur ET/OU, règle par défaut |
| Facturation en masse des dons + lettrage | Absent | Apporté |
| Attribution du don à la campagne (UTM sur facture) | Absent | Apporté |
| Dates de paiement banque visibles sur la facture | Absent | Apportébs_invoice_enrichment |
Plus-value objective.
- Les dons par virement arrivent par centaines de lignes ; le natif impose de traiter chaque ligne comme une écriture comptable anonyme. Ici chaque ligne devient un don identifié, comptabilisé et rattaché à son appel.
- L'attribution VCS → mailing fournit le ROI réel par campagne sans saisie — impossible nativement.
- La facture de don sur produit marqué + registre national + titulaire fiscal du foyer (thème 5) constitue le socle de calcul des attestations fiscales.
5
Partner Field Enlargement — la fiche donateur
Modules
bs_partner_extendedbs_partner_extend_marketing_bridg
s'appuie sur
contactspartnershipdata_cleaning
Fig. 5 — Le socle natif gère un contact commercial ; la couche NGO en fait une fiche donateur : identité complète, foyer fiscal, identifiants officiels et segmentation. Odoo 19 a même retiré la civilité, que la suite restaure.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Fiche contact de base, étiquettes, comptes bancaires | Natif | Réutilisé |
| Grades de membres / cotisations | Natifpartnership | Réutilisé |
| Prénom / nom séparés, nom de naissance, nom d'usage | Absent | Apporté |
| Civilité, abréviation, formule de salutation | Absentretiré en v19 | Apportérestauré + référentiels |
| Naissance, âge, tranche d'âge, genre, nationalité, décès | Absent | Apportédécès = coupure marketing automatique |
| Adresse décomposée (rue / n° / boîte) | Absent | Apportéindispensable au publipostage et aux imports |
| N° de registre national validé | Absent | Apportéprérequis attestations fiscales / Belcotax |
| Données d'entreprise BCE / KBO, codes NACE | Partielpartner_autocomplete (IAP) | Apportéréférentiel dédié BE + contrôle d'adresse |
| Foyers / couples avec titulaire fiscal | Absent | Apporté |
| Relations typées entre contacts | Absent | Apporté |
Plus-value objective.
- Une base donateurs vit des courriers nominatifs, des reçus fiscaux et de la segmentation : aucun de ces trois usages n'est possible avec la fiche native (pas de civilité, pas d'adresse décomposée, pas d'identifiant fiscal, pas de foyer).
- Le couple / foyer avec titulaire fiscal résout un cas réel : deux conjoints donnent ensemble, l'attestation doit viser une personne physique identifiée.
- La gestion du décès protège la réputation (arrêt automatique des sollicitations) — risque très concret en collecte.
6
Partner Sync Marketing — source de vérité unique & RGPD
Modules
bs_mailing_hubbs_partner_extend_marketing_bridg
s'appuie sur
mass_mailingdata_cleaningdocuments
Fig. 6 — Le donateur n'existe qu'une fois ; le marketing en consomme une projection gouvernée, avec des consentements opposables par canal.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Listes de diffusion, contacts marketing, blacklist email globale | Natif | Réutilisé |
| Synchronisation res.partner ↔ mailing.contact | Absentdeux silos | Apporté1 contact par partenaire / société, champs protégés à l'ORM |
| Gouvernance : opt-in explicite, exclusion des contacts système, archivage sûr | Absent | Apportéblacklist automatique de l'email à l'archivage, restauration contrôlée |
| Consentement par canal, horodaté, sourcé, avec preuve documentaire | Absent | Apportéemail · SMS · téléphone · postal · WhatsApp ; synthèse lecture seule sur la fiche |
| Motifs de blacklist administrables | Absent | Apporté |
| Déduplication | Natifdata_cleaning | Étendudétection par email + orchestration depuis la fiche |
Plus-value objective.
- Sans synchronisation, toute organisation qui segmente sérieusement finit avec deux bases divergentes (adresses, décès, opt-out non répercutés) — risque opérationnel et légal.
- Le consentement par canal avec date, source et pièce jointe rend la conformité RGPD démontrable, pas seulement déclarée.
- La blacklist motivée et l'archivage sûr évitent le pire scénario du secteur : réécrire à un donateur qui a demandé l'oubli.
7
Online Fundraising — campagnes de dons en ligne
Modules
bs_ad_fundraisingbs_utm_dimension
appui email
bs_mass_mailing_snippetsbs_mass_mailing_device_visibilitybs_email_marketing_sale_config
s'appuie sur
websitepaymentmass_mailing
Fig. 7 — Une page de don pilotée par un objet campagne, avec bascule ponctuel / récurrent, comptabilisation et attribution fine des canaux.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Formulaire de don : montants prédéfinis + montant libre, paiement en ligne | Partielsnippet « Donation » basique | Remplacé / étendusnippet OWL configurable, hero, FAQ stylable, variantes d'images |
| Objet campagne : objectif, montant collecté, progression, période, responsable, états | Absent | Apporté |
| Don récurrent en ligne (mandat + abonnement) dans le parcours donateur | Partielbriques présentes (payment_sepa_direct_debit, sale_subscription) mais non assemblées en parcours de don | Apportéproduit ponctuel / produit récurrence par campagne |
| Traçage comptable du don en ligne | Partielpayment.transaction seulement | Apportétransaction de collecte séquencée, reliée au paiement, base de facturation |
| Attribution multi-dimensions | PartielUTM : campagne / source / médium | Apportédimensions supplémentaires définies par le métier, pivotables comme le natif |
| Industrialisation des emails d'appel | Partielbuilder générique | Apportébibliothèque de sections, visibilité desktop / mobile par bloc, journal-produit-analytique par mailing |
Plus-value objective.
- Le don natif est un paiement anonyme sans pilotage : ni objectif affiché, ni suivi de campagne, ni document comptable — insuffisant pour rendre compte à un conseil d'administration ou à un bailleur.
- Le récurrent en ligne est l'enjeu économique majeur (valeur vie du donateur) : la suite assemble les briques Enterprise en un parcours effectif.
- Les dimensions UTM supplémentaires permettent d'analyser la collecte selon les axes du métier (thématique, segment, vague…) sans développement.
8
Offline Fundraising — publipostage postal & retours
Modules
bs_direct_mailingbs_mailing_return
boucle retour via
bs_parse_filebs_donation_bank_reconciliation
s'appuie sur
mass_mailingutm
Fig. 8 — La boucle complète : de l'export imprimeur à l'attribution du don et au nettoyage NPAI. Le natif ne couvre que l'email (mass_mailing) et la lettre unitaire via service payant (snailmail) — aucune campagne postale, aucune référence de paiement par destinataire, aucune gestion des retours.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Campagnes email / SMS | NatifSMS via crédits IAP · marketing_automation | Réutilisé |
| Lettre unitaire (facture, relance) via service en ligne | Natifsnailmail (IAP) | Hors sujetusage différent du publipostage |
| Campagne postale de masse (workflow, ciblage, coût, tableau de bord) | Absent | Apporté |
| Export imprimeur : CSV à colonnes paramétrables + dépôt FTP / SFTP sécurisé | Absent | Apportépréréglages VCS / QR, vérification d'empreinte du serveur |
| Référence de paiement unique par destinataire (VCS + QR) | Absent | Apportéclé de toute la mesure de retour |
| Attribution automatique des dons reçus au mailing | Absent | Apportéboucle CODA / VCS avec le thème 4 |
| Gestion des retours NPAI | Absent | Apportéwizard scanner, motifs → actions serveur, stats par mailing / campagne |
Plus-value objective.
- Le publipostage reste le premier canal de collecte de nombreuses ONG ; nativement, Odoo ne sait ni le produire, ni le mesurer.
- La référence VCS par destinataire ferme la boucle : chaque euro reçu est rattaché à son appel sans aucune saisie — le taux de retour devient un fait comptable, pas une estimation.
- Le traitement NPAI convertit un coût récurrent (courriers perdus à chaque vague) en amélioration continue de la base.
9
Donor Care — guichet donateurs outillé
Modules
bs_help_donor_carebs_sdd_donor_care
s'appuie sur
helpdeskbs_sdd_automation
Fig. 9 — Un agent au téléphone crée un donateur régulier complet depuis le ticket, avec les mêmes garde-fous que l'import de masse — sans naviguer dans quatre applications ni polluer les écrans d'import.
| Capacité | Odoo Enterprise 19 | Suite NGO |
|---|---|---|
| Helpdesk : équipes, étapes, SLA, portail, rapports | Natif | Réutilisé |
| Équipe « Donor Care » prête à l'emploi | Absent | Apportéconfiguration livrée, étapes natives réutilisées |
| Création guidée de la chaîne donateur depuis un ticket | Absent | Apportépipeline dédié réutilisant la configuration SDD, sans créer d'entrées d'import |
| Garde-fous du guichet (doublon d'abonnement actif, plan / jour de facturation) | Absent | Apporté |
| Tickets automatiques depuis les anomalies (quarantaine, rejets) | Absent | Apportévia les thèmes 1 et 3 |
Plus-value objective.
- Le service donateurs devient un canal d'enrôlement à part entière (téléphone, courrier) avec la même rigueur que l'import de masse.
- Les anomalies des chaînes SDD (quarantaine, rejets) arrivent comme tickets qualifiés : le back-office et la relation donateur travaillent dans le même outil.
- Sans la suite, un agent devrait créer et relier manuellement 5 objets dans 4 applications par donateur pris au téléphone.
S
Synthèse & points d'objectivité
Fig. S1 — L'effort se concentre là où le natif s'arrête : enrôlement de masse, collecte en ligne, lettrage des dons.
Ce que montre objectivement la comparaison
Sur les 9 thèmes, Odoo Enterprise 19 fournit des briques génériques solides (mandats, lots, XML SEPA, abonnements, lettrage, helpdesk, email marketing) mais aucun processus de collecte de fonds : pas d'enrôlement en masse, aucune gestion des rejets SEPA, pas de lettrage « don » avec attribution, une fiche contact commerciale, deux référentiels marketing non synchronisés, un don en ligne réduit à un paiement, aucun publipostage postal, un helpdesk sans lien avec le donateur. La suite NGO couvre précisément ces neuf écarts en réutilisant systématiquement les rails Enterprise plutôt qu'en les dupliquant — c'est vérifiable dans les dépendances déclarées de chaque module.
Limites et conditions — à énoncer pour rester objectif
Applications requises. La suite s'installe au-dessus d'Odoo Enterprise 19 et s'appuie notamment sur account_accountant, account_batch_payment, account_sepa_direct_debit, account_iso20022, sale_subscription, helpdesk, l10n_be_coda, data_cleaning, documents.
Dépendances externes. queue_job (OCA) pour le thème 2 ; bibliothèques Python paramiko (SFTP) et python-stdnum (registre national).
Ancrage belge. CODA, communication structurée VCS, BCE/KBO et registre national sont des standards belges : accélérateur majeur en Belgique, adaptation nécessaire pour d'autres pays (le SEPA — mandats, lots, rejets, TARGET2 — reste, lui, paneuropéen).
Répartition de la valeur. Là où le natif excelle (génération XML, moteur d'abonnement, widget de lettrage, envoi d'emails), la suite ne réécrit rien : la plus-value est l'orchestration métier et l'automatisation de volume, pas la technologie de base.