Les Dates de demande de devis, devis et police

Fonctionnement de chaque date dans la base de données

Comment fonctionne la “StartDate” ?
Il s’agit de la date de début de couverture demandée par le client. Une StartDate doit être insérée dès la QuoteRequest. Elle transite via la Quote jusqu’à la Policy, il n’y a pas besoin de la mentionner à nouveau. Dans certains cas, vous pouvez ne pas vouloir demander, ou ne pas avoir besoin d’une startDate (c’est rare), et dans ce cas vous pouvez ne pas la demander dans le parcours, et décider que la startDate == now. La StartDate insérée dans la QuoteReuqest est donc copiée en data dans la Quote. Au moment de la création d’un Police, vous pouvez over-rider la StartDate qui découle de la Quote à une autre date (si par exemple le client a changé d’avis sur sa demande de date de début de couverture). Il faut aujourd’hui vous assurer que la start date n’est pas dans le passé, ce qui bloquerait la request de création d’une Police.

Les dates de Demande de devis (Quote Request)

  • startDate : date de début du contrat. Champ libre, choisit par le souscripteur et modifiable par le gestionnaire des demandes de devis si besoin.
  • endDate : date de fin du contrat. Elle est configurable dans le produit d’assurance et sert à calculer le montant de la prime totale. Il existe plusieurs cas pratiques :
    • endDate = Date de début du contrat + 1 an
    • endDate = 31 décembre de l’année en cours
    • endDate = Date précise (celle d’un évènement type concert, voyage, etc…)
  • createdAt : date de création de la demande de devis (lorsque le prospect termine le parcours)
  • updatedAt : date de la dernière modification de la demande de devis. Par exemple, ajout d’information par le gestionnaire avant envoi du devis au prospect

Les dates de Devis (Quote)

  • createdAt : date et heure de création du devis
  • updatedAt : date et heure de la dernière modification du devis
  • finalizedAt : date de finalisation, date à laquelle je finalise ma quote. Le courtier a fait tous ses A/Rs avec l'assureur. Et là ils sont bons, et ils cliquent sur finaliser. Cette action est trackée. Le statut de la quote changes to "Finalized"
  • DocumentsGeneratedAt : le subscription form (saved in DB) et on prépare les templates. date of sucess
  • ValidatedAt : when the status passes into Validate, after the docs are created. It's when the entire "package" is good, with the email content. After that, we'll validate and then send the email to the prospect.
  • EmailProspectSentAt : when the email was sent and was successful
  • ApprovedAt : when the client clicks on "Go". Either API, or in each parcours it's very specific (ex: on Appia, it's automated from "validated")
  • PolicyCreatedAt : this should be removed from the quote --> to delete
  • rejectedAt : if the client rejected the devis, we have an end point, never implemented (useful). Need two types of rejected (from prospect and from broker, ou "abandonné" = même avant d'avoir reçu un devis)
  • startsAt : when the policy should start. Inherited from the quote-request, but interdit de changer. Si on veut vouloir changer, y'a moyen que ça change le prix. Il faudra re-calculer le prix.
  • endAt : when the policy should start. Inherited from the quote-request, but interdit de changer

Les date de Policies

  • CreatedAt
  • UpdatedAt
  • EndDate (rename to EndAt) : inherited from quote when the policy is created
  • StartDate (rename to StartAt) : inherited from quote when the policy is created
  • SubscriptionDate : au moment de la génération de certificats, qu'on set la date. Comme la signature est optionelle, on utilise la génération de certificats comme "moment"
Explication des dates visibles dans dans l’application Seyna
Sur la page de détail d’une police
  • Date de souscription -> SubscriptionDate from Policy
  • Date de début de contrat -> StartDate from Policy
  • Date de fin de contrat -> EndDate from Policy