Aller au contenu

Parcours financé (DPC & FIFPL)

DPC et FIFPL partagent un parcours financé générique (refactorisé pour être commun aux deux financeurs). La principale différence : le module FIFPL insère une phase d’automatisation supplémentaire (export portail + appariement + synchro HubSpot), décrite en détail dans Automatisation FIFPL.

L’opérateur saisit un numéro de session et une référence financeur (le NACPRO côté FIFPL, p. ex. S0520260010025). L’app interroge HubSpot et ne retient que les transactions à un dealstage facturable (les étapes « envoyé au financeur » / « payé » sont configurées par variables d’environnement).

Le résultat s’affiche dans un DataGrid : une ligne par transaction, avec une icône d’erreur de validation, un bouton de rafraîchissement, et une mise en surbrillance pendant la synchro.

Les sessions correspondant aux transactions trouvées sont chargées par lot depuis l’internal-api (par identifiants de deal HubSpot). Elles portent l’étudiant (avec son crmId, ses noms DPC/FIFPL, sa date de naissance, son nom de naissance), le produit, les dates et les activités.

Avant de générer quoi que ce soit, l’app confronte les propriétés des transactions HubSpot aux sessions de l’internal-api : cohérence du numéro de session, des dates, des noms, et statut des consentements (signatures approuvées ou non). Les écarts remontent en icônes d’erreur sur chaque ligne.

Une fois la validation passée, l’opérateur lance la génération du pipeline de documents puis sauvegarde le dossier (billing_file) dans l’internal-api. Voir Documents & signatures.

Pendant la recherche, un panneau de progression (FundedProgressPanel) affiche les étapes en temps réel. Le nombre d’étapes dépend du module :

  • DPC — 4 étapes : Recherche HubSpot → Chargement des sessions → Vérification des consentements → Chargement des documents.
  • FIFPL — 7 étapes : Recherche HubSpot → Chargement des sessions → Téléchargement de l’export FIFPL → Appariement des participants (Claude) → Mise à jour HubSpot → Vérification de la propagation → Finalisation.

Chaque étape visible peut regrouper plusieurs sous-états transitoires de la machine (p. ex. « Finalisation… » couvre le rafraîchissement des lignes, l’attente du webhook, la récupération de la classe virtuelle du dossier, des consentements et des documents existants).

Pour les formations à cheval sur deux années civiles (ou portant des montants montant_unite_1

  • montant_unite_2), l’app détecte le cas, construit des tables de surcharge de prix par année, et génère deux factures (la seconde incrémente automatiquement le numéro de facture suivant).

Sur une facture annulée, l’opérateur peut créer un avoir : un document « avoir » est généré et la transaction d’origine est mise à jour en conséquence.

Après une mise à jour HubSpot (en attente de propagation), l’opérateur peut rafraîchir une seule ligne. L’app re-récupère les propriétés de la transaction depuis HubSpot et la/les session(s) depuis l’internal-api, met à jour la ligne en place, et recalcule les erreurs de validation — sans relancer toute la recherche.

  • Page : applications/billing/src/pages/funded/FundedBillingPage.tsx (DataGrid, recherche, panneau de progression, génération, sauvegarde).
  • Progression : applications/billing/src/pages/funded/fundedProgressSteps.ts (FIFPL_PROGRESS_STEPS / DPC_PROGRESS_STEPS) et FundedProgressPanel.tsx. Chaque étape liste les sous-états de la machine qui s’y rattachent.
  • Validation : applications/billing/src/machines/funded-deal-validation.ts — compare propriétés HubSpot et sessions, construit la carte des statuts de consentement.
  • États de la machine impliqués : searching, fetchingSessions, fetchingConsents, fetchingExistingDocuments, refreshingRow, generatingDocument, et les sous-états FIFPL détaillés sur la page dédiée.
  • Filtrage des deals facturables : variables REACT_APP_HUBSPOT_SEND_TO_FUNDER_DEAL_STAGE et REACT_APP_HUBSPOT_PAYED_DEAL_STAGE.
  • Contrôleur tRPC : librairies/trpc/src/controller/billing/index.ts (searchFundedDeals, refreshFundedDeal, generateDocumentProps).