Validation des fonctionnalités
Référentiel de validation des modules de la suite NGO : chaque ONG (Action Damien, Médecins du Monde) teste puis valide indépendamment sa colonne, fonctionnalité par fonctionnalité.
www.blueseamless.com · contact@blueseamless.com · Août 2026
État au 02/08/2026 · 84 fonctionnalités · 9 modules
Statuts : À tester · Testé OK · Testé NOK · Validé · À arbitrer · N/A
S
Synthèse
compteurs par module| Module métier | Fonctionnalités | Validé AD | % validé AD | Validé MdM | % validé MdM |
|---|---|---|---|---|---|
| SDD Automation | 16 | 0 | 0 % | 0 | 0 % |
| SDD — Batch | 7 | 0 | 0 % | 0 | 0 % |
| SDD — Reject | 7 | 0 | 0 % | 0 | 0 % |
| Payment Entries (lettrage) | 9 | 0 | 0 % | 0 | 0 % |
| Partner Field Enlargement | 8 | 0 | 0 % | 0 | 0 % |
| Partner Sync Marketing | 4 | 0 | 0 % | 0 | 0 % |
| Online Fundraising | 16 | 0 | 0 % | 0 | 0 % |
| Offline Fundraising (Direct Mailing) | 11 | 0 | 0 % | 0 | 0 % |
| Donor Care | 6 | 0 | 0 % | 0 | 0 % |
| TOTAL | 84 | 0 | 0 % | 0 | 0 % |
1
SDD Automation
16 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M01-02 | Menu File History — historique des imports | Fichiers traités, statuts, volumes, consultation des lots | Fichier en état Done (ou Partial si lignes à arbitrer), compteurs Total = Valides + Doublons + Quarantaine, fichier déplacé dans processed, durée renseignée | À tester | À tester |
| M01-03 | Menu Import Errors — erreurs de fichier | Erreurs techniques (format, colonnes) et parcours de reprise | Un fichier volontairement mal formé est signalé avec un message explicite et peut être repris après correction | À tester | À tester |
| M01-04 | Menu SDD Cockpit — pilotage des entrées | Vue de suivi du traitement des lignes SDD | Les lignes en cours sont visibles avec leur état ; les passages d'état suivent le traitement réel | À tester | À tester |
| M01-05 | Menu Duplicates — correspondances détectées | Détection IBAN / email et parcours de traitement (règle de rattachement : à arbitrer) | Toute correspondance (IBAN puis email) est marquée Doublon et proposée à l'arbitrage — rattachement ou création — dans le menu dédié ; aucun rattachement automatique silencieux | À tester | À tester |
| M01-06 | Menu Quarantine — file de quarantaine | Correction manuelle et réinjection des lignes en anomalie | La ligne écartée apparaît dans le menu Quarantaine avec motif explicite (ex. [PIPELINE] Company ID must be a valid Belgian BCE number), fichier source et date ; correction puis revalidation créent les objets | À tester | À tester |
| M01-07 | Menu Warning — avertissements non bloquants | Signalements sans blocage de l'import | Les avertissements s'affichent sans bloquer ; la ligne est traitée normalement | À tester | À tester |
| M01-08 | Menu Rejections — rejets à l'admission | Dont blocage sur numéro de mandat déjà en base (règle Unique mandate code) | L'import d'un numéro de mandat déjà présent est rejeté (aucun doublon créé) avec motif affiché | À tester | À tester |
| M01-09 | Configuration — Validation Rules | Principe testé sur un échantillon de règles (une par type), sévérités et activation — pas d'exhaustivité | Sur l'échantillon : désactiver une règle change le comportement à l'import ; la sévérité appliquée correspond au paramétrage ; la politique d'activation retenue (règles actives, tolérance signature 6 mois en avertissement) est actée au comité produit | À tester | À tester |
| M01-10 | Configuration — CSV Mappings fournisseur | Mapping de colonnes par fournisseur, préconfig par défaut, colonnes multiples | Le mapping d'un fournisseur permet d'importer son format ; un champ ajouté au mapping est repris à l'import ; la préconfig s'applique | À tester | À tester |
| M01-11 | Configuration — Rejection Reasons | Motifs liés aux règles, création de ticket Helpdesk vers l'équipe Donor Care | Un rejet lié à une règle crée un ticket dans l'équipe paramétrée | À tester | À tester |
| M01-12 | Configuration — Motifs de contournement | Bypass motivé, tracé, réservé aux cas listés | Un bypass exige un motif ; motif et auteur sont tracés sur la ligne | À tester | À tester |
| M01-13 | Purge RGPD des fichiers importés | Suppression automatique des fichiers importés après la période de rétention paramétrée | Les fichiers importés sont supprimés automatiquement à l'issue de la rétention configurée ; la purge est active | À tester | À tester |
| M01-14 | Création chaînée contact → mandat → abonnement | Objets natifs créés automatiquement à l'issue de l'import validé | Section Created Objects complète : partenaire, compte bancaire, mandat validé (PDF joint si présent), token, abonnement ; date de première facture sur un jour de prélèvement configuré, jamais dans le passé | À tester | À tester |
| M01-15 | Settings — Invoicing Journal | Journal de facturation des abonnements créés par l'import SDD, configuré dans SDD Automation Settings (vide = journal par défaut) | Après import, les abonnements / factures générés portent le journal configuré (ex. SDD) ; le journal par défaut s'applique si le paramètre est vide | À tester | À tester |
| M01-16 | Settings — UTM Marketing Attribution | Marketing Medium posé sur chaque abonnement créé par l'import (medium_id natif) et option Source = Imported File Name (source_id = nom du fichier importé) | Le médium sélectionné est enregistré sur chaque abonnement créé ; option activée : source = nom du fichier importé ; désactivée : aucune source posée | À tester | À tester |
| M01-17 | Mandats importés — affichage dans la vue Mandats | Après import d'un fichier, consulter la vue des mandats SEPA : présence et contenu des mandats créés par l'import | Chaque mandat importé apparaît dans la vue Mandats, rattaché au bon donateur, avec code, IBAN et statut conformes au fichier importé | À tester | À tester |
2
SDD — Batch
7 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M02-02 | Menu Batch Jobs — jobs planifiés | Paramétrage d'un job (journal, schéma SEPA CORE/B2B, fréquence, montants min/max, auto-validation) ; exécution automatique par le planificateur (OdooBot) + Run Manually | Le job s'exécute à l'heure planifiée, attribué au planificateur (OdooBot), sans intervention ; run en Success avec nombre de factures, montant total et durée ; Run Manually produit un run identique | À tester | À tester |
| M02-03 | Menu Execution History — journal auditable | Historique des runs avec statuts (Success / Warning / Error / Skipped), rétention paramétrable | Chaque run est journalisé avec statut, volumes et horodatage ; l'historique respecte la rétention | À tester | À tester |
| M02-04 | Menu SDD Forecast — prévisionnel de collecte | Projection des échéances à venir — sert aussi de preuve observable pour les règles de dates | Le prévisionnel affiche les échéances à venir ; montants et dates correspondent aux abonnements actifs | À tester | À tester |
| M02-05 | Menu SEPA Settings — schémas CORE / B2B | Délais première collecte / récurrente (jours ouvrés), prénotification, blocage si délai insuffisant, seuil d'avertissement | Délais première collecte / récurrente / pré-notification conformes (5 / 2 / 14 j), blocage si délai insuffisant actif, seuil d'alerte appliqué | À tester | À tester |
| M02-06 | Menu SEPA Settings — calendrier TARGET2 | Jours fériés bancaires — validation par revue du paramétrage + simulation via SDD Forecast ; non testable en manipulation directe | Calendrier alimenté pour la société (fériés bootstrapés) ; une échéance tombant un férié ou un week-end est décalée au jour ouvré bancaire suivant — constaté via le prévisionnel | À tester | À tester |
| M02-07 | Notifications du job — alerting | Capacité présente (onglet Notifications) : utilisateurs à notifier, Warning, Empty Run, Success — configuration à activer ; comportement sur Error à confirmer ; démonstration en séance | Un run en Warning ou vide déclenche une notification aux utilisateurs configurés | À tester | À tester |
| M02-08 | Génération pain.008 | Fichier SEPA généré via le natif, déclenché par le batch | Batch inbound avec un paiement par facture, validé si Auto Validate ; pain.008 joint au chatter ; mémos portant le VCS des factures ; avertissement SEPA premières présentations affiché | À tester | À tester |
3
SDD — Reject
7 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M03-02 | Menu Rejects — file des refus SDD | Appariement automatique lot / paiement / facture / mandat, assignation, date de résolution calculée selon la sévérité, workflow d'états | Un rejet importé est apparié automatiquement à sa chaîne d'origine ; la date de résolution se calcule selon la sévérité ; l'assignation fonctionne | À tester | À tester |
| M03-03 | Conséquences automatisées (2 cas programmés) | MD07 débiteur décédé : clôture du dossier + annulation des prélèvements futurs · AM04 provision insuffisante : replanification J+15 + notification — à démontrer en séance | MD07 : contact clôturé, tous prélèvements futurs annulés · AM04 : échéance replanifiée à J+15, notification émise — vérifié sur cas de test | À tester | À tester |
| M03-04 | Traitement guidé des autres codes | Action recommandée + délai de traitement par sévérité (Blocking 2 j / Recoverable 5 j / Uncertain 10 j) — traitement manuel structuré | Chaque code affiche son action recommandée ; le délai appliqué correspond à la sévérité ; un dépassement est visible | À tester | À tester |
| M03-05 | Menu Configuration — SDD Reject Settings | Délais de traitement par sévérité ; option de lettrage automatique des lignes de rejet (désactivée par défaut) | La modification d'un délai se reflète sur les nouvelles dates de résolution ; le lettrage auto reste désactivé par défaut | À tester | À tester |
| M03-06 | Menu Configuration — Reject Reasons | Référentiel des codes ISO (catégorie, sévérité, action recommandée) — test par échantillon | Le référentiel correspond aux codes ISO officiels (échantillon vérifié) ; catégorie, sévérité et action cohérentes ; textes professionnels | À tester | À tester |
| M03-07 | Notes de crédit / extourne automatique | Écritures d'annulation générées — finalisation en cours (prochaine release) | Au lettrage de la facture sur la fiche rejet, l'avoir est créé et comptabilisé automatiquement sur le journal de la facture d'origine (contrepassation native liée) ; workflow En cours / Résolu / Clôturé exercé ; délais 2 / 5 / 10 j vérifiés sur pièce | À tester | À tester |
| M03-08 | Parcours STOP mandat et autorisations | Arrêt manuel contrôlé, droits associés | L'arrêt manuel exige l'autorisation prévue ; le mandat passe à l'état clôturé et sort des prochains batchs | À tester | À tester |
4
Payment Entries (lettrage)
9 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M04-02 | Menu Donation Transactions — file des transactions | Identification du donateur, statuts, traitement manuel des virements non identifiés | Les transactions apparaissent avec leur statut (Prêt / À vérifier / Traité) ; les cas douteux passent en À vérifier avec motif : VCS sans trace d'envoi (sécurité), clé mod-97 invalide, communication inconnue | À tester | À tester |
| M04-03 | Automatisation — création auto du donateur | Auto-create Donor Partner : contact créé depuis les données CODA (nom + IBAN) si aucun existant ne correspond — entre dans l'architecture de consentement avec zéro opt-in par défaut | Un virement d'un IBAN inconnu crée un contact avec nom et IBAN du CODA (réglage désactivable ; ligne sans nom ignorée) ; aucun opt-in n'est posé | À tester | À tester |
| M04-04 | Automatisation — facture de don auto-lettrée | Auto-generate Invoice : facture générée et réconciliée dès identification ; bloquée si l'IBAN CODA ne correspond pas à l'IBAN enregistré du donateur (garde-fou d'attribution) | Un virement DON est traité de bout en bout : donateur reconnu par IBAN, facture de don générée et lettrée sans intervention ; si l'IBAN CODA diffère de l'IBAN enregistré, la génération est bloquée pour revue | À tester | À tester |
| M04-05 | Configuration — Donation Settings | Produit de don par défaut ([GIFT]), paramètres par société | Le produit par défaut s'applique aux factures générées | À tester | À tester |
| M04-06 | Configuration — Classification Rules | Règles d'affectation journal / produit / compte par type de contact — test par échantillon ; référentiel à nettoyer avant prod (nommage, règle incomplète) | Règle par mot-clé (insensible à la casse et aux accents), conditions contact connu / type de partenaire / ET / OU, ordre de séquence respecté, règle par défaut unique en repli | À tester | À tester |
| M04-07 | Configuration — Legacy Communications | Mapping des communications structurées historiques (reprise legacy) — validation sur jeu d'essai | Correspondance exacte et normalisée (casse, espaces) sur les communications historiques ; unicité par société ; aucune correspondance → statut À vérifier | À tester | À tester |
| M04-08 | Concordances et garde-fous d'attribution | Indicateurs de concordance et priorité des résolveurs pour sécuriser l'attribution du don | Indicateurs nom / IBAN (multi-comptes) / adresse affichés ; priorité de résolution : partenaire de la ligne > IBAN > email ; génération refusée sans partenaire ; lettrage idempotent | À tester | À tester |
| M04-09 | Rapprochement de l'encaissement du batch | Lettrage en lot de la ligne globalisée du relevé avec le batch et ses paiements | La ligne globalisée (montant = total du batch) se rapproche avec le batch, soldant l'ensemble de ses paiements et factures | À tester | À tester |
| M04-10 | Parsing CODA enrichi | Extension du parseur officiel l10n_be par héritage — données structurées exposées | Champs bs_* alimentés (contrepartie, communication type 127 et type, codes transaction, dates, données brutes) ; partenaire résolu automatiquement, mandat et VCS décodés, proposition de lettrage déjà calculée | À tester | À tester |
5
Partner Field Enlargement
8 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M05-01 | Fiche donateur étendue — démographie | Genre, naissance, langue, profession | Champs alimentés depuis le CSV : identité (sexe, civilité, salutation générée), état civil (nationalité, n° national, naissance, âge et tranche calculés), indicateur Deceased disponible ; nom complet composé automatiquement | À tester | À tester |
| M05-02 | Statut décès et conséquences | Blocage des communications et des prélèvements | Le statut décès stoppe communications et prélèvements ; conséquence cohérente avec Return (Deceased) et SDD Reject (MD07) | À tester | À tester |
| M05-03 | Foyer / couple / relations entre contacts | Liens familiaux et ménages | Les liens se créent et s'affichent sur les deux fiches concernées | À tester | À tester |
| M05-04 | Titres de civilité | Reconstruction de res.partner.title (supprimé du standard V19) | Les titres sont disponibles et exploités dans documents et mailings | À tester | À tester |
| M05-05 | Numéro national | Champ natif citizen_identification + règles de validation belges | Le format belge est validé ; un numéro invalide est refusé avec message | À tester | À tester |
| M05-06 | Consentements RGPD par canal | Consentements positifs, datés, sourcés, par canal de communication | Chaque consentement porte date, source et canal ; conforme à la note opt-ins (source de vérité) | À tester | À tester |
| M05-07 | Historique des consentements | Traçabilité des changements | Toute modification crée une entrée datée consultable | À tester | À tester |
| M05-08 | Vue 360 donateur | Synthèse contact : dons, mandats, communications, tickets | La fiche synthétise dons, mandats, communications et tickets du contact | À tester | À tester |
6
Partner Sync Marketing
4 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M06-01 | Synchronisation contacts → liste marketing | Projection vers mailing.contact | Les contacts se synchronisent sans doublon ni divergence de données | À tester | À tester |
| M06-02 | Listes de diffusion par canal / opt-in | Mapping opt-in → liste (cf. note opt-ins) | Contact marketing créé et lié, abonné aux listes portant le SDD Code du fichier ; les quatre canaux de consentement positionnés selon les opt-ins du CSV, source « Import » | À tester | À tester |
| M06-03 | Cohérence opt-in ↔ liste | Règles de synchronisation (correctif régression en cours) | Un changement d'opt-in met la liste à jour dans les deux sens (régression du 30/07 corrigée) | À tester | À tester |
| M06-04 | Architecture cible du ciblage | Arbitrage : projection vs ciblage natif direct res.partner — comité produit | Testée selon l'option retenue par le comité produit | À tester | À tester |
7
Online Fundraising
16 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M07-01 | Menu Campaigns — cycle de vie des campagnes | États Draft → Staging → Online → Closed, responsable, période, objectif de collecte et progression | La campagne suit le cycle Draft → Staging (prévisualisation seule) → Online (publiée) → Closed | À tester | À tester |
| M07-02 | Campagne — cible et produits | Produit de don unique, récurrence activable, produit d'abonnement mensuel (SDD) par campagne | Le don unique utilise le produit configuré ; la récurrence propose l'abonnement ; objectif et progression s'actualisent | À tester | À tester |
| M07-03 | Onglet Style — personnalisation no-code | Template d'affichage, largeur, formulaire inline / page séparée, couleurs, boutons, coins, hero, FAQ — entièrement modifiable côté client, sans développement | Chaque option modifiée se reflète sur la page publiée, sans intervention technique | À tester | À tester |
| M07-04 | Onglet Hero Page | Textes, image de fond, hauteur, couleurs, overlay du bandeau | Textes, image et couleurs configurés s'affichent conformément sur la page | À tester | À tester |
| M07-05 | Onglet FAQ et badge éthique | Questions / réponses éditables par campagne, section badge (code éthique RE-EF) — contenus légaux et fiscaux : propriétaire et validation à définir côté ONG | Les Q/R s'affichent dans le style choisi ; les contenus légaux et fiscaux sont validés par l'ONG propriétaire | À tester | À tester |
| M07-06 | Configurations — moyens de paiement | Don unique par virement (communication structurée → lettrage automatique) ; récurrence par SEPA Direct Debit (création du mandat en ligne → chaîne SDD) | Don unique : virement avec communication structurée reprise par le lettrage · Récurrence : le formulaire crée mandat SEPA + abonnement entrant dans la chaîne SDD | À tester | À tester |
| M07-07 | Configurations — conformité | Numéro national obligatoire (attestations), section attestation fiscale, politique de confidentialité par campagne, multilingue FR / NL / EN | Numéro national exigé avec explication affichée ; sections attestation et confidentialité visibles ; page disponible en FR / NL / EN | À tester | À tester |
| M07-08 | Onglet Received Donations — dons de la campagne | Dons reçus, statuts (Pending → réconcilié via CODA), total collecté | Le don de test apparaît en Pending puis passe réconcilié après traitement du CODA correspondant | À tester | À tester |
| M07-09 | Menu Received Donations — vue globale | Ensemble des dons en ligne, tous canaux de campagne | La vue agrège les dons de toutes les campagnes | À tester | À tester |
| M07-10 | Menu Configuration — filtres email | Domaines email bloqués sur les formulaires de don | Un email d'un domaine bloqué est refusé avec message ; un domaine autorisé passe | À tester | À tester |
| M07-11 | Dimensions UTM étendues | Axes d'analyse complémentaires aux UTM natifs — à arbitrer (fields.Properties) | Les dimensions se renseignent et se retrouvent en reporting — selon l'arbitrage retenu | À tester | À tester |
| M07-12 | Visibilité par appareil (email builder) | Options d'affichage desktop / mobile complémentaires au natif — vérifié | Un bloc marqué mobile-only n'apparaît pas sur desktop (test d'envoi réel) | À tester | À tester |
| M07-13 | Link Tracker — dimensions UTM et valeurs (mode debug) | Menus Dimensions et Values du Link Tracker (accessibles en mode développeur) : créer une dimension (nom, campagne parente, Display In) puis ses valeurs depuis l'onglet Values | La dimension se crée avec ses valeurs rattachées à la campagne parente ; listes Dimensions et Values cohérentes (compteur de valeurs par dimension) | À tester | À tester |
| M07-14 | Link Tracker — Reporting Slots (8 emplacements) | Cocher Available in Reporting sur une dimension puis contrôler l'occupation des emplacements techniques (bs_utm_dim_1_id → bs_utm_dim_8_id) | La dimension cochée occupe un emplacement : n° de slot affiché sur la dimension, dimension visible en Occupied By ; 8 emplacements disponibles au maximum | À tester | À tester |
| M07-15 | Link Tracker — liens trackés et menu UTMs | Menus Link Tracker et UTMs : consulter / créer les liens trackés et les enregistrements UTM utilisés par les campagnes de don | Les liens et enregistrements UTM se créent et se consultent ; les valeurs renseignées restent cohérentes avec les dimensions configurées | À tester | À tester |
| M07-16 | Link Tracker — présence transversale des dimensions | Les champs de dimensions UTM se retrouvent sur tous les modules disposant d'entrées : vérifier leur présence et leur alimentation sur les enregistrements concernés de chaque module | Les dimensions configurées sont visibles sur les enregistrements des modules à entrées et portent les valeurs capturées, cohérentes d'un module à l'autre pour le reporting | À tester | À tester |
8
Offline Fundraising (Direct Mailing)
11 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M08-01 | Menu Mailings — envoi postal | Création d'un Postal Mailing : sujet, liste de destinataires, workflow Draft → Ongoing, compteurs de traces et de retours | Le Postal Mailing se crée avec sa liste ; les compteurs s'incrémentent au fil du cycle | À tester | À tester |
| M08-02 | Génération du fichier routeur | Bouton Generate Test File + fichier définitif ; mapping CSV par routeur avec champs suggérés (nom, adresse, VCS, QR) et champs personnalisés (chemin ORM) | Generate Test File produit un CSV conforme au mapping (colonnes, ordre, valeurs) — contrôle sur fichier ouvert | À tester | À tester |
| M08-03 | Communication structurée et QR de paiement | VCS et référence QR par destinataire sur le courrier — boucle avec le lettrage automatique des dons (Donation Reconciliation) | Chaque ligne porte une communication structurée / référence unique, reconnue ensuite par le lettrage (test croisé Payment Entries) | À tester | À tester |
| M08-04 | Menu Export Traces — suivi des exports | Fichiers générés, statuts, volumes, historique par campagne | Chaque génération est tracée avec statut, volume et horodatage | À tester | À tester |
| M08-05 | Stockage et dépôt FTP / SFTP | Dossier serveur par fournisseur + envoi du fichier définitif vers serveur distant (option à activer) — validation sur démonstration | Le fichier définitif est déposé dans le dossier fournisseur ; l'envoi FTP/SFTP aboutit vers le serveur de test | À tester | À tester |
| M08-06 | Onglet Attachments — fichiers générés | Téléchargement des fichiers horodatés depuis la fiche mailing | Les fichiers générés sont téléchargeables et horodatés | À tester | À tester |
| M08-07 | Menu Campaigns — campagnes postales | Regroupement et suivi des envois par campagne | Les envois se regroupent et se suivent par campagne | À tester | À tester |
| M08-08 | Menu Configuration — paramètres du module | Stockage serveur, FTP, configuration des commandes (section Sale Order Config : bloc affiché en double — correctif d'affichage à passer) | Les paramètres s'appliquent ; l'affichage de la section Sale Order Config est corrigé (plus de doublon) | À tester | À tester |
| M08-09 | Menu Mail Returns — retours enregistrés | Liste des retours courrier : motif, mailing d'origine, contact, traitement | Un retour enregistré référence le mailing, le contact et le motif | À tester | À tester |
| M08-10 | Menu Scan Returns — station de scan | Assistant de saisie rapide : scan QR / code-barres ou référence manuelle, valeurs par défaut (motif, mailing), détection automatique du retour | Le scan d'un QR / d'une référence identifie le retour ; les valeurs par défaut s'appliquent ; la saisie en série est fluide | À tester | À tester |
| M08-11 | Menu Configuration — Return Reasons | Référentiel des motifs avec action serveur automatisée (Deceased → archivage contact · NPAI → opt-out postal · Refused → tag · Moved → traitement adresse) — test par échantillon ; cohérence des conséquences décès à vérifier avec Partner Field et SDD Reject (MD07) | Chaque motif applique sa conséquence : Deceased archive, NPAI écrit un opt-out postal daté au registre de consentements, Refused pose le tag, Moved traite l'adresse (échantillon testé) | À tester | À tester |
9
Donor Care
6 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M09-02 | Trois équipes paramétrées avec alias email | New & Update SDD · Donor Care · Contact Form Online — routage des demandes entrantes par adresse ; alias actuellement sur le domaine blueseamless : bascule vers les domaines ONG avant mise en production | Un email envoyé à chaque alias crée un ticket dans la bonne équipe | À tester | À tester |
| M09-03 | Ticket SDD — bouton Create SDD Records | Création des enregistrements SDD depuis un ticket : parcours des mandats papier / postaux | Depuis un ticket SDD (mandat papier), le bouton crée contact, mandat et abonnement liés au ticket | À tester | À tester |
| M09-04 | Ticket — bouton Update Contact | Mise à jour du contact directement depuis le ticket via le bouton Update Contact — disponible sur les équipes autorisées (ex. Donor Care) ; passerelle Convert to Lead (CRM natif) | Le bouton Update Contact ouvre la fiche du contact lié pour mise à jour immédiate ; action bloquée sans contact lié ou si l'équipe n'est pas autorisée | À tester | À tester |
| M09-05 | Tickets automatiques sur anomalies SDD | Création depuis les modules SDD (import, rejets) | Une anomalie d'import ou un rejet paramétré crée automatiquement son ticket dans l'équipe prévue | À tester | À tester |
| M09-06 | Pièces jointes sur tickets | Upload de documents sur le ticket (natif) | Un document uploadé est conservé et consultable sur le ticket | À tester | À tester |
| M09-07 | Menus Tickets et Reporting | Vues et rapports natifs (listes, pivot, graphique) — modifiables côté client | Les vues liste, pivot et graphique se filtrent et se sauvegardent par utilisateur | À tester | À tester |
Référentiel de validation des modules de la suite NGO : chaque ONG (Action Damien, Médecins du Monde) teste puis valide indépendamment sa colonne, fonctionnalité par fonctionnalité.
www.blueseamless.com · contact@blueseamless.com · Août 2026
État au 02/08/2026 · 84 fonctionnalités · 9 modules
Statuts : À tester · Testé OK · Testé NOK · Validé · À arbitrer · N/A
S
Synthèse
compteurs par module| Module métier | Fonctionnalités | Validé AD | % validé AD | Validé MdM | % validé MdM |
|---|---|---|---|---|---|
| SDD Automation | 16 | 0 | 0 % | 0 | 0 % |
| SDD — Batch | 7 | 0 | 0 % | 0 | 0 % |
| SDD — Reject | 7 | 0 | 0 % | 0 | 0 % |
| Payment Entries (lettrage) | 9 | 0 | 0 % | 0 | 0 % |
| Partner Field Enlargement | 8 | 0 | 0 % | 0 | 0 % |
| Partner Sync Marketing | 4 | 0 | 0 % | 0 | 0 % |
| Online Fundraising | 16 | 0 | 0 % | 0 | 0 % |
| Offline Fundraising (Direct Mailing) | 11 | 0 | 0 % | 0 | 0 % |
| Donor Care | 6 | 0 | 0 % | 0 | 0 % |
| TOTAL | 84 | 0 | 0 % | 0 | 0 % |
1
SDD Automation
16 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M01-02 | Menu File History — historique des imports | Fichiers traités, statuts, volumes, consultation des lots | Fichier en état Done (ou Partial si lignes à arbitrer), compteurs Total = Valides + Doublons + Quarantaine, fichier déplacé dans processed, durée renseignée | À tester | À tester |
| M01-03 | Menu Import Errors — erreurs de fichier | Erreurs techniques (format, colonnes) et parcours de reprise | Un fichier volontairement mal formé est signalé avec un message explicite et peut être repris après correction | À tester | À tester |
| M01-04 | Menu SDD Cockpit — pilotage des entrées | Vue de suivi du traitement des lignes SDD | Les lignes en cours sont visibles avec leur état ; les passages d'état suivent le traitement réel | À tester | À tester |
| M01-05 | Menu Duplicates — correspondances détectées | Détection IBAN / email et parcours de traitement (règle de rattachement : à arbitrer) | Toute correspondance (IBAN puis email) est marquée Doublon et proposée à l'arbitrage — rattachement ou création — dans le menu dédié ; aucun rattachement automatique silencieux | À tester | À tester |
| M01-06 | Menu Quarantine — file de quarantaine | Correction manuelle et réinjection des lignes en anomalie | La ligne écartée apparaît dans le menu Quarantaine avec motif explicite (ex. [PIPELINE] Company ID must be a valid Belgian BCE number), fichier source et date ; correction puis revalidation créent les objets | À tester | À tester |
| M01-07 | Menu Warning — avertissements non bloquants | Signalements sans blocage de l'import | Les avertissements s'affichent sans bloquer ; la ligne est traitée normalement | À tester | À tester |
| M01-08 | Menu Rejections — rejets à l'admission | Dont blocage sur numéro de mandat déjà en base (règle Unique mandate code) | L'import d'un numéro de mandat déjà présent est rejeté (aucun doublon créé) avec motif affiché | À tester | À tester |
| M01-09 | Configuration — Validation Rules | Principe testé sur un échantillon de règles (une par type), sévérités et activation — pas d'exhaustivité | Sur l'échantillon : désactiver une règle change le comportement à l'import ; la sévérité appliquée correspond au paramétrage ; la politique d'activation retenue (règles actives, tolérance signature 6 mois en avertissement) est actée au comité produit | À tester | À tester |
| M01-10 | Configuration — CSV Mappings fournisseur | Mapping de colonnes par fournisseur, préconfig par défaut, colonnes multiples | Le mapping d'un fournisseur permet d'importer son format ; un champ ajouté au mapping est repris à l'import ; la préconfig s'applique | À tester | À tester |
| M01-11 | Configuration — Rejection Reasons | Motifs liés aux règles, création de ticket Helpdesk vers l'équipe Donor Care | Un rejet lié à une règle crée un ticket dans l'équipe paramétrée | À tester | À tester |
| M01-12 | Configuration — Motifs de contournement | Bypass motivé, tracé, réservé aux cas listés | Un bypass exige un motif ; motif et auteur sont tracés sur la ligne | À tester | À tester |
| M01-13 | Purge RGPD des fichiers importés | Suppression automatique des fichiers importés après la période de rétention paramétrée | Les fichiers importés sont supprimés automatiquement à l'issue de la rétention configurée ; la purge est active | À tester | À tester |
| M01-14 | Création chaînée contact → mandat → abonnement | Objets natifs créés automatiquement à l'issue de l'import validé | Section Created Objects complète : partenaire, compte bancaire, mandat validé (PDF joint si présent), token, abonnement ; date de première facture sur un jour de prélèvement configuré, jamais dans le passé | À tester | À tester |
| M01-15 | Settings — Invoicing Journal | Journal de facturation des abonnements créés par l'import SDD, configuré dans SDD Automation Settings (vide = journal par défaut) | Après import, les abonnements / factures générés portent le journal configuré (ex. SDD) ; le journal par défaut s'applique si le paramètre est vide | À tester | À tester |
| M01-16 | Settings — UTM Marketing Attribution | Marketing Medium posé sur chaque abonnement créé par l'import (medium_id natif) et option Source = Imported File Name (source_id = nom du fichier importé) | Le médium sélectionné est enregistré sur chaque abonnement créé ; option activée : source = nom du fichier importé ; désactivée : aucune source posée | À tester | À tester |
| M01-17 | Mandats importés — affichage dans la vue Mandats | Après import d'un fichier, consulter la vue des mandats SEPA : présence et contenu des mandats créés par l'import | Chaque mandat importé apparaît dans la vue Mandats, rattaché au bon donateur, avec code, IBAN et statut conformes au fichier importé | À tester | À tester |
2
SDD — Batch
7 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M02-02 | Menu Batch Jobs — jobs planifiés | Paramétrage d'un job (journal, schéma SEPA CORE/B2B, fréquence, montants min/max, auto-validation) ; exécution automatique par le planificateur (OdooBot) + Run Manually | Le job s'exécute à l'heure planifiée, attribué au planificateur (OdooBot), sans intervention ; run en Success avec nombre de factures, montant total et durée ; Run Manually produit un run identique | À tester | À tester |
| M02-03 | Menu Execution History — journal auditable | Historique des runs avec statuts (Success / Warning / Error / Skipped), rétention paramétrable | Chaque run est journalisé avec statut, volumes et horodatage ; l'historique respecte la rétention | À tester | À tester |
| M02-04 | Menu SDD Forecast — prévisionnel de collecte | Projection des échéances à venir — sert aussi de preuve observable pour les règles de dates | Le prévisionnel affiche les échéances à venir ; montants et dates correspondent aux abonnements actifs | À tester | À tester |
| M02-05 | Menu SEPA Settings — schémas CORE / B2B | Délais première collecte / récurrente (jours ouvrés), prénotification, blocage si délai insuffisant, seuil d'avertissement | Délais première collecte / récurrente / pré-notification conformes (5 / 2 / 14 j), blocage si délai insuffisant actif, seuil d'alerte appliqué | À tester | À tester |
| M02-06 | Menu SEPA Settings — calendrier TARGET2 | Jours fériés bancaires — validation par revue du paramétrage + simulation via SDD Forecast ; non testable en manipulation directe | Calendrier alimenté pour la société (fériés bootstrapés) ; une échéance tombant un férié ou un week-end est décalée au jour ouvré bancaire suivant — constaté via le prévisionnel | À tester | À tester |
| M02-07 | Notifications du job — alerting | Capacité présente (onglet Notifications) : utilisateurs à notifier, Warning, Empty Run, Success — configuration à activer ; comportement sur Error à confirmer ; démonstration en séance | Un run en Warning ou vide déclenche une notification aux utilisateurs configurés | À tester | À tester |
| M02-08 | Génération pain.008 | Fichier SEPA généré via le natif, déclenché par le batch | Batch inbound avec un paiement par facture, validé si Auto Validate ; pain.008 joint au chatter ; mémos portant le VCS des factures ; avertissement SEPA premières présentations affiché | À tester | À tester |
3
SDD — Reject
7 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M03-02 | Menu Rejects — file des refus SDD | Appariement automatique lot / paiement / facture / mandat, assignation, date de résolution calculée selon la sévérité, workflow d'états | Un rejet importé est apparié automatiquement à sa chaîne d'origine ; la date de résolution se calcule selon la sévérité ; l'assignation fonctionne | À tester | À tester |
| M03-03 | Conséquences automatisées (2 cas programmés) | MD07 débiteur décédé : clôture du dossier + annulation des prélèvements futurs · AM04 provision insuffisante : replanification J+15 + notification — à démontrer en séance | MD07 : contact clôturé, tous prélèvements futurs annulés · AM04 : échéance replanifiée à J+15, notification émise — vérifié sur cas de test | À tester | À tester |
| M03-04 | Traitement guidé des autres codes | Action recommandée + délai de traitement par sévérité (Blocking 2 j / Recoverable 5 j / Uncertain 10 j) — traitement manuel structuré | Chaque code affiche son action recommandée ; le délai appliqué correspond à la sévérité ; un dépassement est visible | À tester | À tester |
| M03-05 | Menu Configuration — SDD Reject Settings | Délais de traitement par sévérité ; option de lettrage automatique des lignes de rejet (désactivée par défaut) | La modification d'un délai se reflète sur les nouvelles dates de résolution ; le lettrage auto reste désactivé par défaut | À tester | À tester |
| M03-06 | Menu Configuration — Reject Reasons | Référentiel des codes ISO (catégorie, sévérité, action recommandée) — test par échantillon | Le référentiel correspond aux codes ISO officiels (échantillon vérifié) ; catégorie, sévérité et action cohérentes ; textes professionnels | À tester | À tester |
| M03-07 | Notes de crédit / extourne automatique | Écritures d'annulation générées — finalisation en cours (prochaine release) | Au lettrage de la facture sur la fiche rejet, l'avoir est créé et comptabilisé automatiquement sur le journal de la facture d'origine (contrepassation native liée) ; workflow En cours / Résolu / Clôturé exercé ; délais 2 / 5 / 10 j vérifiés sur pièce | À tester | À tester |
| M03-08 | Parcours STOP mandat et autorisations | Arrêt manuel contrôlé, droits associés | L'arrêt manuel exige l'autorisation prévue ; le mandat passe à l'état clôturé et sort des prochains batchs | À tester | À tester |
4
Payment Entries (lettrage)
9 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M04-02 | Menu Donation Transactions — file des transactions | Identification du donateur, statuts, traitement manuel des virements non identifiés | Les transactions apparaissent avec leur statut (Prêt / À vérifier / Traité) ; les cas douteux passent en À vérifier avec motif : VCS sans trace d'envoi (sécurité), clé mod-97 invalide, communication inconnue | À tester | À tester |
| M04-03 | Automatisation — création auto du donateur | Auto-create Donor Partner : contact créé depuis les données CODA (nom + IBAN) si aucun existant ne correspond — entre dans l'architecture de consentement avec zéro opt-in par défaut | Un virement d'un IBAN inconnu crée un contact avec nom et IBAN du CODA (réglage désactivable ; ligne sans nom ignorée) ; aucun opt-in n'est posé | À tester | À tester |
| M04-04 | Automatisation — facture de don auto-lettrée | Auto-generate Invoice : facture générée et réconciliée dès identification ; bloquée si l'IBAN CODA ne correspond pas à l'IBAN enregistré du donateur (garde-fou d'attribution) | Un virement DON est traité de bout en bout : donateur reconnu par IBAN, facture de don générée et lettrée sans intervention ; si l'IBAN CODA diffère de l'IBAN enregistré, la génération est bloquée pour revue | À tester | À tester |
| M04-05 | Configuration — Donation Settings | Produit de don par défaut ([GIFT]), paramètres par société | Le produit par défaut s'applique aux factures générées | À tester | À tester |
| M04-06 | Configuration — Classification Rules | Règles d'affectation journal / produit / compte par type de contact — test par échantillon ; référentiel à nettoyer avant prod (nommage, règle incomplète) | Règle par mot-clé (insensible à la casse et aux accents), conditions contact connu / type de partenaire / ET / OU, ordre de séquence respecté, règle par défaut unique en repli | À tester | À tester |
| M04-07 | Configuration — Legacy Communications | Mapping des communications structurées historiques (reprise legacy) — validation sur jeu d'essai | Correspondance exacte et normalisée (casse, espaces) sur les communications historiques ; unicité par société ; aucune correspondance → statut À vérifier | À tester | À tester |
| M04-08 | Concordances et garde-fous d'attribution | Indicateurs de concordance et priorité des résolveurs pour sécuriser l'attribution du don | Indicateurs nom / IBAN (multi-comptes) / adresse affichés ; priorité de résolution : partenaire de la ligne > IBAN > email ; génération refusée sans partenaire ; lettrage idempotent | À tester | À tester |
| M04-09 | Rapprochement de l'encaissement du batch | Lettrage en lot de la ligne globalisée du relevé avec le batch et ses paiements | La ligne globalisée (montant = total du batch) se rapproche avec le batch, soldant l'ensemble de ses paiements et factures | À tester | À tester |
| M04-10 | Parsing CODA enrichi | Extension du parseur officiel l10n_be par héritage — données structurées exposées | Champs bs_* alimentés (contrepartie, communication type 127 et type, codes transaction, dates, données brutes) ; partenaire résolu automatiquement, mandat et VCS décodés, proposition de lettrage déjà calculée | À tester | À tester |
5
Partner Field Enlargement
8 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M05-01 | Fiche donateur étendue — démographie | Genre, naissance, langue, profession | Champs alimentés depuis le CSV : identité (sexe, civilité, salutation générée), état civil (nationalité, n° national, naissance, âge et tranche calculés), indicateur Deceased disponible ; nom complet composé automatiquement | À tester | À tester |
| M05-02 | Statut décès et conséquences | Blocage des communications et des prélèvements | Le statut décès stoppe communications et prélèvements ; conséquence cohérente avec Return (Deceased) et SDD Reject (MD07) | À tester | À tester |
| M05-03 | Foyer / couple / relations entre contacts | Liens familiaux et ménages | Les liens se créent et s'affichent sur les deux fiches concernées | À tester | À tester |
| M05-04 | Titres de civilité | Reconstruction de res.partner.title (supprimé du standard V19) | Les titres sont disponibles et exploités dans documents et mailings | À tester | À tester |
| M05-05 | Numéro national | Champ natif citizen_identification + règles de validation belges | Le format belge est validé ; un numéro invalide est refusé avec message | À tester | À tester |
| M05-06 | Consentements RGPD par canal | Consentements positifs, datés, sourcés, par canal de communication | Chaque consentement porte date, source et canal ; conforme à la note opt-ins (source de vérité) | À tester | À tester |
| M05-07 | Historique des consentements | Traçabilité des changements | Toute modification crée une entrée datée consultable | À tester | À tester |
| M05-08 | Vue 360 donateur | Synthèse contact : dons, mandats, communications, tickets | La fiche synthétise dons, mandats, communications et tickets du contact | À tester | À tester |
6
Partner Sync Marketing
4 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M06-01 | Synchronisation contacts → liste marketing | Projection vers mailing.contact | Les contacts se synchronisent sans doublon ni divergence de données | À tester | À tester |
| M06-02 | Listes de diffusion par canal / opt-in | Mapping opt-in → liste (cf. note opt-ins) | Contact marketing créé et lié, abonné aux listes portant le SDD Code du fichier ; les quatre canaux de consentement positionnés selon les opt-ins du CSV, source « Import » | À tester | À tester |
| M06-03 | Cohérence opt-in ↔ liste | Règles de synchronisation (correctif régression en cours) | Un changement d'opt-in met la liste à jour dans les deux sens (régression du 30/07 corrigée) | À tester | À tester |
| M06-04 | Architecture cible du ciblage | Arbitrage : projection vs ciblage natif direct res.partner — comité produit | Testée selon l'option retenue par le comité produit | À tester | À tester |
7
Online Fundraising
16 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M07-01 | Menu Campaigns — cycle de vie des campagnes | États Draft → Staging → Online → Closed, responsable, période, objectif de collecte et progression | La campagne suit le cycle Draft → Staging (prévisualisation seule) → Online (publiée) → Closed | À tester | À tester |
| M07-02 | Campagne — cible et produits | Produit de don unique, récurrence activable, produit d'abonnement mensuel (SDD) par campagne | Le don unique utilise le produit configuré ; la récurrence propose l'abonnement ; objectif et progression s'actualisent | À tester | À tester |
| M07-03 | Onglet Style — personnalisation no-code | Template d'affichage, largeur, formulaire inline / page séparée, couleurs, boutons, coins, hero, FAQ — entièrement modifiable côté client, sans développement | Chaque option modifiée se reflète sur la page publiée, sans intervention technique | À tester | À tester |
| M07-04 | Onglet Hero Page | Textes, image de fond, hauteur, couleurs, overlay du bandeau | Textes, image et couleurs configurés s'affichent conformément sur la page | À tester | À tester |
| M07-05 | Onglet FAQ et badge éthique | Questions / réponses éditables par campagne, section badge (code éthique RE-EF) — contenus légaux et fiscaux : propriétaire et validation à définir côté ONG | Les Q/R s'affichent dans le style choisi ; les contenus légaux et fiscaux sont validés par l'ONG propriétaire | À tester | À tester |
| M07-06 | Configurations — moyens de paiement | Don unique par virement (communication structurée → lettrage automatique) ; récurrence par SEPA Direct Debit (création du mandat en ligne → chaîne SDD) | Don unique : virement avec communication structurée reprise par le lettrage · Récurrence : le formulaire crée mandat SEPA + abonnement entrant dans la chaîne SDD | À tester | À tester |
| M07-07 | Configurations — conformité | Numéro national obligatoire (attestations), section attestation fiscale, politique de confidentialité par campagne, multilingue FR / NL / EN | Numéro national exigé avec explication affichée ; sections attestation et confidentialité visibles ; page disponible en FR / NL / EN | À tester | À tester |
| M07-08 | Onglet Received Donations — dons de la campagne | Dons reçus, statuts (Pending → réconcilié via CODA), total collecté | Le don de test apparaît en Pending puis passe réconcilié après traitement du CODA correspondant | À tester | À tester |
| M07-09 | Menu Received Donations — vue globale | Ensemble des dons en ligne, tous canaux de campagne | La vue agrège les dons de toutes les campagnes | À tester | À tester |
| M07-10 | Menu Configuration — filtres email | Domaines email bloqués sur les formulaires de don | Un email d'un domaine bloqué est refusé avec message ; un domaine autorisé passe | À tester | À tester |
| M07-11 | Dimensions UTM étendues | Axes d'analyse complémentaires aux UTM natifs — à arbitrer (fields.Properties) | Les dimensions se renseignent et se retrouvent en reporting — selon l'arbitrage retenu | À tester | À tester |
| M07-12 | Visibilité par appareil (email builder) | Options d'affichage desktop / mobile complémentaires au natif — vérifié | Un bloc marqué mobile-only n'apparaît pas sur desktop (test d'envoi réel) | À tester | À tester |
| M07-13 | Link Tracker — dimensions UTM et valeurs (mode debug) | Menus Dimensions et Values du Link Tracker (accessibles en mode développeur) : créer une dimension (nom, campagne parente, Display In) puis ses valeurs depuis l'onglet Values | La dimension se crée avec ses valeurs rattachées à la campagne parente ; listes Dimensions et Values cohérentes (compteur de valeurs par dimension) | À tester | À tester |
| M07-14 | Link Tracker — Reporting Slots (8 emplacements) | Cocher Available in Reporting sur une dimension puis contrôler l'occupation des emplacements techniques (bs_utm_dim_1_id → bs_utm_dim_8_id) | La dimension cochée occupe un emplacement : n° de slot affiché sur la dimension, dimension visible en Occupied By ; 8 emplacements disponibles au maximum | À tester | À tester |
| M07-15 | Link Tracker — liens trackés et menu UTMs | Menus Link Tracker et UTMs : consulter / créer les liens trackés et les enregistrements UTM utilisés par les campagnes de don | Les liens et enregistrements UTM se créent et se consultent ; les valeurs renseignées restent cohérentes avec les dimensions configurées | À tester | À tester |
| M07-16 | Link Tracker — présence transversale des dimensions | Les champs de dimensions UTM se retrouvent sur tous les modules disposant d'entrées : vérifier leur présence et leur alimentation sur les enregistrements concernés de chaque module | Les dimensions configurées sont visibles sur les enregistrements des modules à entrées et portent les valeurs capturées, cohérentes d'un module à l'autre pour le reporting | À tester | À tester |
8
Offline Fundraising (Direct Mailing)
11 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M08-01 | Menu Mailings — envoi postal | Création d'un Postal Mailing : sujet, liste de destinataires, workflow Draft → Ongoing, compteurs de traces et de retours | Le Postal Mailing se crée avec sa liste ; les compteurs s'incrémentent au fil du cycle | À tester | À tester |
| M08-02 | Génération du fichier routeur | Bouton Generate Test File + fichier définitif ; mapping CSV par routeur avec champs suggérés (nom, adresse, VCS, QR) et champs personnalisés (chemin ORM) | Generate Test File produit un CSV conforme au mapping (colonnes, ordre, valeurs) — contrôle sur fichier ouvert | À tester | À tester |
| M08-03 | Communication structurée et QR de paiement | VCS et référence QR par destinataire sur le courrier — boucle avec le lettrage automatique des dons (Donation Reconciliation) | Chaque ligne porte une communication structurée / référence unique, reconnue ensuite par le lettrage (test croisé Payment Entries) | À tester | À tester |
| M08-04 | Menu Export Traces — suivi des exports | Fichiers générés, statuts, volumes, historique par campagne | Chaque génération est tracée avec statut, volume et horodatage | À tester | À tester |
| M08-05 | Stockage et dépôt FTP / SFTP | Dossier serveur par fournisseur + envoi du fichier définitif vers serveur distant (option à activer) — validation sur démonstration | Le fichier définitif est déposé dans le dossier fournisseur ; l'envoi FTP/SFTP aboutit vers le serveur de test | À tester | À tester |
| M08-06 | Onglet Attachments — fichiers générés | Téléchargement des fichiers horodatés depuis la fiche mailing | Les fichiers générés sont téléchargeables et horodatés | À tester | À tester |
| M08-07 | Menu Campaigns — campagnes postales | Regroupement et suivi des envois par campagne | Les envois se regroupent et se suivent par campagne | À tester | À tester |
| M08-08 | Menu Configuration — paramètres du module | Stockage serveur, FTP, configuration des commandes (section Sale Order Config : bloc affiché en double — correctif d'affichage à passer) | Les paramètres s'appliquent ; l'affichage de la section Sale Order Config est corrigé (plus de doublon) | À tester | À tester |
| M08-09 | Menu Mail Returns — retours enregistrés | Liste des retours courrier : motif, mailing d'origine, contact, traitement | Un retour enregistré référence le mailing, le contact et le motif | À tester | À tester |
| M08-10 | Menu Scan Returns — station de scan | Assistant de saisie rapide : scan QR / code-barres ou référence manuelle, valeurs par défaut (motif, mailing), détection automatique du retour | Le scan d'un QR / d'une référence identifie le retour ; les valeurs par défaut s'appliquent ; la saisie en série est fluide | À tester | À tester |
| M08-11 | Menu Configuration — Return Reasons | Référentiel des motifs avec action serveur automatisée (Deceased → archivage contact · NPAI → opt-out postal · Refused → tag · Moved → traitement adresse) — test par échantillon ; cohérence des conséquences décès à vérifier avec Partner Field et SDD Reject (MD07) | Chaque motif applique sa conséquence : Deceased archive, NPAI écrit un opt-out postal daté au registre de consentements, Refused pose le tag, Moved traite l'adresse (échantillon testé) | À tester | À tester |
9
Donor Care
6 fonctionnalités| ID | Fonctionnalité | Description | Résultat attendu | Validation AD | Validation MdM |
|---|---|---|---|---|---|
| M09-02 | Trois équipes paramétrées avec alias email | New & Update SDD · Donor Care · Contact Form Online — routage des demandes entrantes par adresse ; alias actuellement sur le domaine blueseamless : bascule vers les domaines ONG avant mise en production | Un email envoyé à chaque alias crée un ticket dans la bonne équipe | À tester | À tester |
| M09-03 | Ticket SDD — bouton Create SDD Records | Création des enregistrements SDD depuis un ticket : parcours des mandats papier / postaux | Depuis un ticket SDD (mandat papier), le bouton crée contact, mandat et abonnement liés au ticket | À tester | À tester |
| M09-04 | Ticket — bouton Update Contact | Mise à jour du contact directement depuis le ticket via le bouton Update Contact — disponible sur les équipes autorisées (ex. Donor Care) ; passerelle Convert to Lead (CRM natif) | Le bouton Update Contact ouvre la fiche du contact lié pour mise à jour immédiate ; action bloquée sans contact lié ou si l'équipe n'est pas autorisée | À tester | À tester |
| M09-05 | Tickets automatiques sur anomalies SDD | Création depuis les modules SDD (import, rejets) | Une anomalie d'import ou un rejet paramétré crée automatiquement son ticket dans l'équipe prévue | À tester | À tester |
| M09-06 | Pièces jointes sur tickets | Upload de documents sur le ticket (natif) | Un document uploadé est conservé et consultable sur le ticket | À tester | À tester |
| M09-07 | Menus Tickets et Reporting | Vues et rapports natifs (listes, pivot, graphique) — modifiables côté client | Les vues liste, pivot et graphique se filtrent et se sauvegardent par utilisateur | À tester | À tester |