Aller au contenu

Phase 1 — Étapes et soumission

Référence pour le parcours Présentation → Documents → Emprunteur (project owner company) avant passage en analyse.

Deux phases, deux sources de statut

Phase Étapes (UI PDP) Source du statut affiché
Phase 1 presentation, documents, borrower API GET /projects → steps (persisté par entité)
Phase 2 analysis, offer, collect, signature API GET /projects → steps via compute-project-financing-request-steps.ts. L'app PDP lit ces statuts tels quels (getSteps)

Macro-statuts (ownerProjectStatusSchema) : draft, in-analysis, blocked, offer, finalization, completed, rejected.

Phase 2 côté API — compute-project-financing-request-steps.ts :

  • steps.analysis : dérivé du macro-statut (unavailable en draft ; draft en in-analysis / blocked / rejected ; completed dès offer+).
  • steps.offer : dérivé du macro-statut (draft en offer ; completed dès finalization).
  • steps.finalization et steps.signature : le macro-statut reste finalization pendant toute la fenêtre signature ; c'est le statut de la société emprunteuse qui discrimine — finalized (posé par POST …/finalization/complete) fige le dossier : finalisation completed, signature draft. Projet completed → les deux completed.
  • POST …/finalization/complete renvoie { status, steps } (comme submit et accept-offer) pour que le front ouvre la signature sans refetch.
  • L'app PDP mappe la clé API finalization → libellé UI collect.

Phase 1 — statuts indépendants

Chaque étape possède son propre status (unavailable | draft | completed). Aucune cascade : compléter ou rééditer une étape ne re-verrouille pas les autres.

Logique : compute-project-financing-request-steps.ts.

Présentation

  • Toujours draft tant que non complétée (création auto au premier GET).
  • PUT …/presentation/:id/complete → completed et ouvre Documents (documentsStep.status : unavailable → draft, idempotent).

Documents

  • Démarre unavailable ; s'ouvre en draft quand la présentation est complétée une première fois.
  • Checklist expectedDocuments (9 clés) : guide UX, pas bloquante pour PUT …/documents/complete.
  • Complétion : au moins un fichier uploadé → documentsStep.status = 'completed'.
  • Toute modification (upload, commentaire, toggle checklist) après complétion repasse l'étape en draft.

Emprunteur (project owner company)

  • Statut = statut de la société emprunteuse (draft | completed), ou unavailable si aucune société encore créée.
  • GET …/project-owner-company crée une société vide en draft si absente.
  • PUT …/project-owner-company/:id/complete valide les champs requis et verrouille la société.
  • Facultatif pour la soumission : seules présentation + documents sont requises. La société peut être complétée plus tard (jusqu'au macro-statut finalization inclus, tant qu'elle n'est pas completed) — voir is-borrower-editable.ts et project owner company.
  • isBorrowerStepDeferred : posé à true à la soumission si la société n'était pas completed (POST /submit). Immutable ensuite — compléter la société plus tard ne le remet pas à false. Exposé côté API sur steps.borrower.isDeferred ; l'app PDP déplace l'étape emprunteur en phase 2 (après offer) quand le flag est actif.

Soumission en analyse

Endpoint dédié : POST /project-financing-request/:projectId/submit (project-submission.service.ts).

POST /submit (projet draft)
  → lock projet + relecture présentation
  → canSubmitToAnalysis(presentation completed, documents completed) ?
       oui → status = in-analysis + notify Projet Analyse + steps recalculés
       non → 409 project-phase-one-incomplete

Prérequis : presentation.status === 'completed' et documentsStep.status === 'completed'. La société n'est pas requise.

Erreur HTTP Cause
project-not-found 404 Projet inconnu
project-not-draft 409 Déjà soumis
project-phase-one-incomplete 409 Présentation ou documents pas completed

Effets :

  • Le projet quitte draft : documentsStep n'existe plus sur le JSON (discriminated union).
  • Présentation n'est plus éditable (ProjectEditabilityService → project-not-editable).
  • La société reste éditable tant que isBorrowerEditable le permet (macro-statuts in-analysis / blocked / offer / finalization tant que la société est encore draft).
  • Les documents restent uploadables (hors guard d'éditabilité phase 1).

Côté app PDP : l'écran emprunteur expose un flux skip (skipAction → POST /submit sans compléter la société) ou un flux submit (save + PUT …/project-owner-company/complete puis POST /submit).

Phase 2 — stepper app PDP

getSteps lit project.steps depuis l'API. Guards, progression et ProjectStepsBar consomment ce helper unique — plus de dérivation locale depuis project.status. La step signature est désormais servie par le contrat, mais getSteps l'écrase encore en unavailable tant que le réalignement front (suppression de l'injection locale, isProjectFinished → signature, OWNER_PROJECT_STEP_KEYS) n'est pas fait.

La barre d'étapes affiche phase 1 ou phase 2 selon l'URL courante (PHASE_1_STEPS / PHASE_2_STEPS, cette dernière inclut signature). Les étapes unavailable ne sont pas cliquables ; en phase 2, les étapes déjà completed sont aussi désactivées (lecture seule).

Nommage : le contrat API utilise finalization comme clé d'étape et macro-statut ; l'app PDP l'affiche comme collect (collecte de fonds). Voir data-reference.md pour la cible complète (offre signée, documents, etc.).

Éditabilité après soumission

Ressource Éditable après soumission ?
Présentation Non (draft uniquement)
Société emprunteuse Selon isBorrowerEditable (voir project owner company)
Fichiers documents Oui (upload, commentaires)
Checklist onboarding Non (draft uniquement)
Compléments analyse Oui en blocked (toggle + validate)

Liens