# Budget v2 spés tech

## Vue d'ensemble Budget 1.0

### MCD

@startuml
hide circle 
skinparam class {
  BackgroundColor White
  BorderColor Black
  ArrowColor Black
}

class Plan {
    Id
    ...
    AverageCostPerHourTarget
    TrainingHourTarget
    BudgetPolicy
}

class PlanFinancing {
    Id
    PlanId
    FinancingSourceId
    AmountExcludingTaxes_Value
    AmountExcludingTaxes_CurrencyCode
    Conditions
    AuthorId
    CreatedAt
}

class FinancingSource {
    Id
    Type
    AuthorId
    CreatedAt
}

Plan -l- PlanFinancing
PlanFinancing -l- FinancingSource

@enduml

### API

// ça permet de calculer le totalBudget qui n'est pas stoqué en base
GET api/plans/{id}/budget-synthesis

{
  "trainingHourTarget": 0,
  "averageCostPerHourTarget": {
    "value": 0,
    "currencySymbol": "string",
    "currencyCode": 8
  },
  "totalBudget": {
    "value": 0,
    "currencySymbol": "string",
    "currencyCode": 8
  }
}

GET api/plans/{id}
{
  "id": 0,
  ...
  "trainingHourTarget": 0,
  "averageCostPerHourTarget": 0,
  "budgetPolicy": "string"
}

PUT api/plans/{id}
{
  "name": "string",
  "startOn": {
    "year": 0,
    "month": 0,
    "day": 0,
    "dayOfWeek": 0
  },
  "ownerId": 0,
  "establishmentIds": [
    0
  ],
  "trainingHourTarget": 0,
  "averageCostPerHourTarget": 0,
  "budgetPolicy": "string"
}

## Impactes de la version 2

## MCD
La table Plan devra persister **TotalBudget**

@startuml
hide circle 
skinparam class {
  BackgroundColor White
  BorderColor Black
  ArrowColor Black
}

class Plan {
    Id
    ...
    //suppression - AverageCostPerHourTarget
    TrainingHourTarget
    BudgetPolicy
    **TotalBudget**
}

class PlanFinancing {
    Id
    PlanId
    FinancingSourceId
    AmountExcludingTaxes_Value
    AmountExcludingTaxes_CurrencyCode
    Conditions
    AuthorId
    CreatedAt
}

class FinancingSource {
    Id
    Type
    AuthorId
    CreatedAt
}

Plan -l- PlanFinancing
PlanFinancing -l- FinancingSource

@enduml

## API

GET api/plans/{id}/budget-synthesis
>devienne obsolete

GET api/plan/{id}/financings
GET api/plan/{id}/financings-synthesis
GET api/plan/{id}/budget-monitoring
GET api/plans/{id}/budget-monitoring/financing/equity/remaining
> doivent revoir leur mode d'inferer le financement fonds propres

### Validation
L'api PUT prends les 3 valeurs : budget total, cout par heure et objectif en heure et verifie que c'est coherent.
#### Comment garantir la coherence ?
- Option 1 : l'api valide
- Option 2 : Option 1 + On ajout des contraintes en base

### Nouveau contract de l'api plans

GET api/plans/{id}
{
  "id": 0,
  ...
  "trainingHourTarget": 0,
  "averageCostPerHourTarget": 0,
  "budgetPolicy": "string",
  // on ajoute totalBudget
  "totalBudget": 0
}

PUT api/plans/{id}
{
  "name": "string",
  "startOn": {
    "year": 0,
    "month": 0,
    "day": 0,
    "dayOfWeek": 0
  },
  "ownerId": 0,
  "establishmentIds": [
    0
  ],
  "trainingHourTarget": 0,
  "averageCostPerHourTarget": 0,
  "budgetPolicy": "string",
  // on ajoute totalBudget
  "totalBudget": 0
}

### Migration
- Il faut ajouter une colonne totalBudget
- Il faut remplir la colonne totalBudget avec la bonne valeur

### Strategie de developpement
L'enjeux est de trovuer une solution pour qu'on puisse garantir que la version actuel du budget continue de fonctionner toujours en production pendant qu'on développe et on merge petit à petit les chantier du budget 2.

#### Etape 1
Ajouter le colonne totalBudget en base de donnée et faire en sorte que à l'édition du plan, la colonne soit toujours mise à jour.

> Il faut absoluement que cette etape soit indivisible dans une seule PR

> À cette etape totalBudget n'est pris en compte par les autres api en lecture pour faire leur calcules sur le fonds propres.

#### Etape 2
Mise en place d'un toggle feature "BudgetV2" qui permet de :
- Basculer coté front de l'interface V1 à l'interface V2
- Basculer coté back du fonctionneent V1 à V2

Pour ce qui concerne le back, on peut à cette etape déja modifier le contract de l'api budget en ajoutant la propriété totalBudget. Dans le cas ou le toggle ne sera pas activé, tout simplement tel propriété ne sera pas utilisé ni prise en compte par le vieux fonctionnement.

#### Etape 3
Développement de la feature.

À ce stade on peut mettre en production à tout moment un travail partiel car le toggle feature et la strategie mise en place permet de ne pas avoir des impactes sur la V1 du budget (sauf regressions).

> Impossible de commencer le developpement des User Stories fonctionnels sans que l'étape 2 ne soit pas mergé sur `main`

> Ecrire des test unitaires qui prenne en compte le double fonctionnement des api en fonction du feature toggle actif ou pas peut s'avverer couteux, attention à ne pas créer une machine à gas, il faut bien réflechir sur ce point quite à y passer du temps (qu'il faut prévoir).

#### Etape 4
La feature est prete, nous pouvons ouvrire les vannes et basculer sur la nouvelle version.

#### Etape 5
Si le résultat est satisfaisant, on peut nettoyer le code et supprimer toutes reminiscences de la v1 du budget + le toggle feature.

> Supprimer aussi à ce moment *`GET api/plans/{id}/budget-synthesis`*