Tronc commun · Anim'Gest × Cockpit'Gest
OCR Eliot : lecture des chèques et dissociation payeur / bénéficiaire.
Étendre le moteur Eliot à la lecture des chèques, et acter un principe métier structurant pour tout le B to C : celui qui paie n'est pas toujours celui qui bénéficie. Une brique générique, réutilisable par l'ensemble des logiciels du groupe.
Note de l'éditeur
Célia, merci pour cette demande — elle est validée et inscrite à notre feuille de route pour un développement à venir. C'est précisément ce genre de retour, venu directement du terrain, qui fait grandir nos outils : une brique importante, née de votre métier et co-construite avec vous, jamais à votre place. Au plaisir de la voir prendre forme, ensemble.
Contexte
Le tronc commun d'Anim'Gest et Cockpit'Gest mutualise progressivement les composants métier, pour constituer un socle réutilisable par l'ensemble des logiciels édités par No Sage's Editor.
Une première brique existe déjà autour de l'OCR Eliot : la lecture automatisée des notes de frais. L'étape suivante étend ce moteur à la lecture des chèques, pour en faciliter l'intégration et la comptabilisation.
Cette évolution ne répond pas qu'à Anim'Gest. C'est une fonction transverse pour tous les métiers B to C, où le titulaire du moyen de paiement est très souvent différent du bénéficiaire réel de la prestation. Cette réalité doit être prise en compte dès la conception.
Constat métier
Dans les métiers B to C, la personne qui règle une prestation n'est pas toujours celle qui en bénéficie. Le système ne peut donc pas considérer que le titulaire du chèque est le titulaire de la facture. Cette distinction est le principe fondamental de l'évolution.
Qui règle — le payeur
- un parent, un grand-parent
- un parrain, une marraine
- un conjoint, un proche
- une entreprise, un comité d'entreprise
- une collectivité, une association
- un organisme financeur
Qui bénéficie — le bénéficiaire
- un enfant
- un licencié, un adhérent
- un élève, un patient
- un client
- un propriétaire d'animal
- toute personne bénéficiant de la prestation
Problématique
Un rapprochement automatique fondé sur le seul nom du titulaire du chèque serait inadapté. Aucune correspondance ne peut être garantie entre le titulaire du compte bancaire, le nom porté sur le chèque, le bénéficiaire de la prestation et le titulaire des factures.
Le système doit donc constater un règlement indépendamment de l'identité du bénéficiaire, puis laisser l'utilisateur l'affecter librement aux factures concernées.
Objectifs
Permettre à l'OCR Eliot de :
- lire automatiquement les informations d'un chèque ;
- créer un règlement dans le logiciel ;
- identifier le titulaire du chèque comme tiers payeur ;
- distinguer ce tiers payeur du bénéficiaire de la prestation ;
- permettre l'affectation manuelle du règlement ;
- gérer un règlement sur une ou plusieurs factures ;
- gérer les règlements partiels ;
- conserver tous les mécanismes actuels de suivi des créances.
Fonctionnement attendu
Après lecture OCR, le système extrait notamment le numéro du chèque, la banque, la date, le montant et le titulaire du compte. Ces informations créent automatiquement un règlement, et le titulaire du chèque est enregistré comme tiers payeur.
En revanche, aucune tentative de rapprochement automatique n'est faite sur son identité. L'utilisateur accède ensuite à une interface pour sélectionner librement une facture, plusieurs factures, ou un bénéficiaire différent du tiers payeur.
Nouveau modèle fonctionnel
Le système distingue désormais deux notions indépendantes. Le tiers payeur trace le paiement ; il ne modifie jamais le titulaire des factures.
Le bénéficiaire
Titulaire juridique
La personne qui bénéficie de la prestation. Elle reste :
- titulaire de la facture
- débiteur de la créance
- destinataire des relances
Le tiers payeur
Traçabilité du paiement
La personne ou l'organisme ayant réellement payé — parent, entreprise, association, collectivité, comité d'entreprise, financeur…
- information de traçabilité
- conservé pour consultation
- ne change pas le titulaire de la facture
Gestion des règlements
Le système autorise une ventilation totalement libre. Un règlement pourra :
- solder totalement une facture ;
- régler partiellement une facture ;
- être réparti sur plusieurs factures ;
- être complété ultérieurement par d'autres règlements.
Inversement, une facture pourra recevoir plusieurs règlements successifs — au plus près des pratiques réelles du B to C.
Cas d'usage
Un parrain offre l'année d'équitation de sa filleule. Le chèque est établi au nom du parrain ; les factures concernent exclusivement la filleule. Les noms sont totalement différents. Eliot lit le chèque — 1 000,00 € — et crée le règlement.
Factures existantes
| Facture | Montant |
|---|---|
| Licence | 100,00 € |
| Abonnement annuel | 50,00 € |
| Cours annuels | 1 250,00 € |
Ventilation choisie par l'utilisateur
| Facture | Affectation | État |
|---|---|---|
| Licence | 100,00 € | Payée |
| Abonnement | 50,00 € | Payée |
| Cours annuels | 850,00 € | Règlement partiel |
| Total affecté | 1 000,00 € |
Gestion des relances
Le règlement partiel n'interrompt pas le cycle de gestion des créances. Le solde restant continue d'être visible dans les impayés, pris en compte dans les balances âgées, intégré aux relances automatiques et soumis aux pénalités si elles sont activées.
Le système raisonne donc sur le solde restant dû, jamais sur le montant initial de la facture.
Données OCR à exploiter
Eliot extrait, lorsque l'information est disponible :
- banque émettrice ;
- numéro du chèque ;
- date ;
- montant ;
- titulaire du compte ;
- le cas échéant, le numéro de compte ou les informations utiles au rapprochement bancaire.
Ces données servent à créer le règlement, tracer le paiement et préparer le rapprochement bancaire ultérieur.
Règles de gestion
- Le titulaire du chèque devient le tiers payeur.
- Le tiers payeur peut être totalement différent du bénéficiaire.
- Aucun rapprochement automatique sur le seul nom du payeur.
- Un règlement peut être réparti sur plusieurs factures.
- Une facture peut recevoir plusieurs règlements.
- Les règlements partiels sont gérés nativement.
- Les relances portent uniquement sur le solde restant dû.
- Le bénéficiaire demeure le titulaire juridique de la facture.
- Le tiers payeur est conservé pour la traçabilité comptable.
Impacts fonctionnels
Composants du tronc commun à adapter — conçus de manière générique, pour être réutilisables par toutes les solutions du socle :
Bénéfices attendus
- Mutualisation du moteur OCR Eliot.
- Réduction des saisies manuelles.
- Gestion fidèle des situations réelles du B to C.
- Prise en charge native des tiers payeurs.
- Traçabilité complète des règlements et ventilation libre des paiements.
- Gestion native des règlements partiels, mécanismes de relance conservés.
- Réutilisation immédiate dans tous les logiciels No Sage's Editor.
- Évolution pérenne du tronc commun, sans développement spécifique par métier.
Une notion métier structurante, pas seulement une lecture OCR.
Cette évolution dépasse la lecture des chèques : elle introduit la dissociation entre bénéficiaire et tiers payeur pour l'ensemble des applications B to C. Intégrée directement dans le tronc commun, elle dote No Sage's Editor d'une architecture assez générique pour la formation, le sport, les loisirs, l'événementiel, la santé, les services à la personne, les associations — partout où un tiers finance une prestation.
À la clé : une meilleure expérience utilisateur, une traçabilité renforcée des paiements, et une brique réutilisable immédiatement dans toutes les solutions présentes et futures du groupe.