# Reflexion évolution activation

## PdlActivation (ex SSR "oneShot")

Permet de suivre 1 activation d'un "site", du tout début de l'activation, jusqu'à la fin de la désactivation.

Ainsi PdlActivation est un objet très technique par opposition à l'objet Contrat.

Dates du Contrat => volonté de d'activer ou pas
Dates du PdlActivation => dates réèlles

Dans la mesure ou on pourrait avoir n PdlActivation avec n Contrats, il est nécéssaire de séparer ces objets.

### PdlActivation.statut

En cas d'erreur à n'importe quelle étape, on revient au départ et la raison et origine de l'erreur est dans "errors".

stateDiagram
[*] --> readyToRequestSwitch
readyToRequestSwitch --> switchPending: switch-ok
readyToRequestSwitch --> switchFailed: switch-ko
readyToRequestSwitch --> abandonned: abandon-in-frontend


switchPending --> switchDone: checkSwitchAffaire-ok
switchPending --> switchFailed: checkSwitchAffaire-ko

switchFailed --> switchPending: switch-in-frontend
switchFailed --> abandonned: abandon-in-frontend

switchDone --> outed 
switchDone --> kickedOut
switchDone --> stolen

stolen --> outed : stolen-acté
stolen --> [*] : newPdlActivation

Les status outed, stolen, kickedOut sont finaux.
- outed: RIC (resil initative client) ou CFN tierce dans les temps
- stolen : CFN trop tôt (cf DPContract)
- kickedOut : RIF (resil initiative fournisseur)

### Champs

#### Site

- Site.activation
- Site.activationHumanCheck
- Lors de la création "needed" pour tous les sites, sauf C5 où "unneeded"
- needed => check fail avec erreur need-Human-check
- unneeded => création du PdlActivation au moment du passage en unneeded
- checked => création du PdlActivation au moment du passage en checked
- abandonned

- Site.CurrentPdlActivation(): lien vers le PdlActivation en cours

#### PdlActivation

- PdlActivation.statut
- PdlActivation.statusUpdatedAt
- PdlActivation.statusErrorCategory (erreur dans checkTech, switch ou checkSwitchAffaire)
- PdlActivation.statusErrors (cf gestion des erreurs dans Invoice)
- PdlActivation.Site
- PdlActivation.realActivationDate
- PdlActivation.realDeactivationDate

classDiagram
PdlActivation --> Site
Site --* PdlActivation: PdlActivation "en cours"
PdlActivation : id_site
DPContract --> DeliveryPeriod
DeliveryPeriod --> Site
DeliveryPeriod : id_site
Site: humanCheckFlag

PdlActivation: statut
PdlActivation: statusUpdatedAt
PdlActivation: errors
PdlActivation: realActivationDate
PdlActivation: realDeactivationDate
PdlActivation: affaireId
PdlActivation: requestData
PdlActivation: responseData
DPContract: start
DPContract: end

Règle: il ne peut y avoir qu'1 seul PdlActivation "en cours" par Site

### Paramètres:
- delai_demande_activation correspond à
- MES:
- C2-C4: 10 jours avant Contrat.start
- C5: 10 jours avant Contrat.start
- CFN:
- C2-C4: 30 jours avant Contrat.start
- C5: 30 jours avant Contrat.start
- delai_creation_pdc_activation: 10j (= on créé le PdlActivation 10j avant date_prevue_activation)

### Règles création du PdlActivation

- comment détecter le fait qu'il faille créer une PdlActivation ?
- site non activé (champs Site.activation == 'none')
- ET date_jour >= Contrat.start - (delai_demande_activation + delai_creation_pdc_activation)
- ET
- PdlActivation non existante pour ce Site (PdlActivation.id_site)

### Actions / Commandes

- checkPdlActivationAffaire
- màj des statuts des affaires d'activation sur SGE

- switchPdlActivation
- lance l'activation

- techCheckSiteForPdlActivation

### GUI

- écran qui affiche la liste des Site qui démarrent dans moins de x jours
- 1 bouton par site pour passer en abandonned le humanCheck
- 1 bouton qui, pour chaque site,
- fait checkTech
- valide le human check
- créé la PdlActivation
(équivalenr commande techCheckSiteForPdlActivation)

- écran qui affiche
- les PdlActivation "readyToRequestSwitch" + date d'activation dans `delai_demande_activation`
- et les PdlActivation en erreur
- 1 bouton switch pour tout l'écran
(équivalent commande switchPdlActivation)
- filtre par PdlActivation.statusErrorCategory
- bouton+input pour renseigner le numéro d'affaire et màj statut (switchPending) pour les cas d'activation manuelle
- bouton "abandon"

- écran qui affiche les PdlActivation "switchPending"
- 1 bouton checkAffaire
(équivalent commande checkPdlActivationAffaire)

- écran qui affiche les PdlActivation "stolen"
- 1 bouton qui créé un nouveau PdlActivation
- 1 bouton qui passe le statut en "outed"

----------------------

## dans le check FluxX
dans le FluxX: mettre à jour active_grdf_contract

Site.activation (actuellement)

stateDiagram
[*] --> none
none --> pending: activation en cours
pending --> GRDFxxx: checkPresenceVsDp
GRDFxxx --> outed

cas possible de sortie de périmètre
- fin de contrat normal et un autre Fournisseur a pris le PRM
- fin de contrat dépassée et un autre Fournisseur

| Contract.End ? | qui a sorti | PdlActivation.status |
| ----------------- | -------------------- | -------------------- |
| arrivé ou dépassé | S/O (sans objet) | outed |
| futur | autre (activation) | stolen |
| futur | nous (désactivation) | kickedOut |

Comment gérer la schizophrénie VE/VES (VE vs autre / X12 vs X13) ??? Cas finalement expceptionnels ?? Cela demanderait une vision "globale" qu'on ne peut pas avoir dans le check FluxX qui lui ne voit de fait, que le fluxX analysé en cours.

Il faudrait poser le caser et imaginer ce qu'il se passerait

-----------------------------

- request_data (json_array du SSR)
- les données sont cherchées où elles sont:
- PRM: Site.prm
- date activation: ==Contrat.start==
- depuis SGE
- adresse de livraison
- Si CFN:
- tarif_turpe: depuis SGE (ISO)
- PS+unit: depuis SGE (ISO)
- Si MES:
- récupérer les PS sur Site.p_XXX (configuré par user)
- récupérer le tarif: (configuré par user)
- BTINF: déduire du calendrier fournisseur
- BTSUP/HTA: prendre dans Site.Tarif (prévoir l'édition du tarif)
- si_contractuel (Disco/Gingko)
- is_communicating
- Contact: contact "technique" ou sinon "administratif" ou sinon, le 1er
- NAF+activity: Site.naf
- RaisonSociale: Site.name

=> il faut pouvoir les chercher juste avant la création du PdlActivation, mais aussi avant le switch

- calendrier fournisseur
- prévoir une table dédiée
- lier cette table au Site
- calendrier_fournisseur
- id
- libelle (Heures Pleines/Creuses Saison Haute/Basse)
- code (FC000193)
- contrat_grdf (GRD-F038)
- domaine_tension (BTINF, BTSUP, HTA)
- id_default_tarif_turpe (lien vers TarifTurpe)
=> cela remplacera la config dans parameters.yml

    calendrier_fournisseur:
        BTINF:
            base: 'FC000057'
            hphc: 'FC000058'