ferrous_sapling/generation-rapports-acc
ferrous_sapling/generation-rapports-acc
1
0
Fork 0
Code Issues 5 Pull requests 1 Projects 1 Releases Packages Wiki Activity Actions

WIP: Permettre d'utiliser les données sur plusieurs mois pour générer des rapports #2

Draft
ferrous_sapling wants to merge 50 commits from données-sur-plusieurs-mois into main
pull from: données-sur-plusieurs-mois
merge into: ferrous_sapling:main
Conversation 5 Commits 50 Files changed 110 +40848 -1767
ferrous_sapling commented 2026-03-22 09:14:55 +00:00
Owner
Copy link

Cette PR introduit la capacité d'indiquer plusieurs dossiers à l'outil afin qu'il puisse générer des rapports qui prennent en compte les données de plusieurs mois. Par exemple, rendre une courbe de kWh Auto-Consommés au cours des mois.

Cette PR introduit la capacité d'indiquer plusieurs dossiers à l'outil afin qu'il puisse générer des rapports qui prennent en compte les données de plusieurs mois. Par exemple, rendre une courbe de kWh Auto-Consommés au cours des mois.
src/lib.rs : introduire les struct `InfosVenantDeEnedisPourUnePériode` et `InfosAccSurUnePériode`

src/ui.rs : choix de l'ACC visualisée et import de données en haut de la fenêtre, afficher les participants pour chaque mois connu, début de choix des rapports à générer en fonction du mois choisi

src/mémoire.rs : inclure le chemin dans les érreurs d'IO d'écriture, implémenter `std::fmt::Display` pour les erreurs d'écriture

src/rapports.rs : calculer l'autoconsommation globale d'une opération depuis les données producteur et consommateur plutôt qu'en lisant le fichier « global »

tests/lecture_fichiers_pour_rapports_mensuels.rs : ajustement tests de dérivation des infos acc à partir d'un chemin de dossier pour coller aux modifications des `struct` introduites.
src/ui.rs : simple renommage de variable intermédiare.

Cargo.toml, Cargo.lock : ajouter `itertools` comme dépendence.
- l'énumération `ÉtatGénérationRapportMensuel` à `ChoixDesRapportsÀGénérer`
- l'attribut `état` de la structure `Outil` à `état_choix`
ferrous_sapling force-pushed données-sur-plusieurs-mois from f7912563c0 to 12bb9cdc94 2026-03-28 20:24:36 +00:00 Compare 
templates/rapport_consommation_mensuel.typ : inclure les courbes de consommation ACC/Totale sur les derniers mois.

src/ui.rs : passer une copie des infos sur l'ensemble des périodes connues de l'opération d'ACC à la fonction/procédure `rapports::générer_rapports`.

src/lib.rs : implémenter `Ord` et `PartialOrd` pour la structure Période.

src/rapports.rs :
- introduire `mod courbes` contenant un début de génération de graphe des courbes de consommation (sans titre ni légende à ce stade).
- introduire `trait PeutÊtreAbrégéEnFrançais` et l'implémenter pour `time::Month`.
- dans `générer_rapports`, lire depuis le disque, rassembler, et filtrer en fonction de la période concernée par le rapport à générer, les données de consommation de chaque consommateur de l'opération d'ACC.
- dans `générer_pdf_avec_typst_rapport_mensuel_consommateur`, générer le graphe des courbes de consommation et le passer au moteur de génération de PDFs.
src/rapports.rs :
- éclater la marge unique en quatre marges séparées (haute, basse, gauche, et droite).
- ajouter titre et légende aux courbes de consommation ACC/Totale.
templates/rapport_consommation_mensuel_heures_creuses_heures_pleines.typ : Ajouter les deux courbes au rapport.

src/rapports.rs : Générer les deux courbes séparément.
templates/rapport_production_mensuel.typ : Ajouter les courbes au rapport.

src/rapports.rs : Générer les courbes de production.
ferrous_sapling commented 2026-03-31 21:59:25 +00:00
Author
Owner
Copy link

Finalement j'inclus aussi l'utilisation de ces "données sur plusieurs mois" pour générer et placer dans les rapports mensuels des courbes montrant les valeurs de consommation/production sur les périodes connues par l'outil au moment de la génération.

J'inclus également la possibilité de choisir pour quelle "période" (i.e. quel mois) générer les rapports. Les courbes rendues dans le rapport s’arrêtent au mois choisi (et donc ne vont pas dans le "futur" de cette "période" / de ce mois).

Finalement j'inclus aussi l'utilisation de ces "données sur plusieurs mois" pour générer et placer dans les rapports mensuels des courbes montrant les valeurs de consommation/production sur les périodes connues par l'outil au moment de la génération. J'inclus également la possibilité de choisir pour quelle "période" (i.e. quel mois) générer les rapports. Les courbes rendues dans le rapport s’arrêtent au mois choisi (et donc ne vont pas dans le "futur" de cette "période" / de ce mois).
ferrous_sapling commented 2026-03-31 22:00:18 +00:00
Author
Owner
Copy link

J'inclus aussi la possibilité de suivre plusieurs opérations d'ACC et de basculer entre elles à tout instant. C'est surtout une mesure de robustesse pour traiter le cas ou l'utilisateur·ice aurait des données venant de différentes opérations sur sa machine et les importerait à tour de rôle dans l'outil. En tant qu’éditeur de l'outil, je vois 2 choix possibles pour traiter ce(s) cas :

  1. On écrase/jette/oubli les données précédentes, comme fonctionnait déjà l'outil lorsqu'il ne gérait qu'une seul "période" / un seul mois à la fois.
  2. On traque chaque opération d'ACC séparément, les adressant par leur numéro de personne morale (la première partie (ACC12345678) d'un nom de fichier comme ACC12345678_01012026_31012026_Autoconso_ENERGIE.csv).

La solution 2 a été retenue, car elle offre le plus de flexibilité à l'utilisateur·ice ; non seulement elle lui permet de gérer/suivre plusieurs opérations en parallèle mais (surtout) elle n'efface pas l'intégralité des saisies existantes suite à une fausse manip'.

J'inclus aussi la possibilité de suivre plusieurs opérations d'ACC et de basculer entre elles à tout instant. C'est surtout une mesure de robustesse pour traiter le cas ou l'utilisateur·ice aurait des données venant de différentes opérations sur sa machine et les importerait à tour de rôle dans l'outil. En tant qu’éditeur de l'outil, je vois 2 choix possibles pour traiter ce(s) cas : 1. On écrase/jette/oubli les données précédentes, comme fonctionnait déjà l'outil lorsqu'il ne gérait qu'une seul "période" / un seul mois à la fois. 2. On traque chaque opération d'ACC séparément, les adressant par leur numéro de personne morale (la première partie (`ACC12345678`) d'un nom de fichier comme `ACC12345678_01012026_31012026_Autoconso_ENERGIE.csv`). La solution 2 a été retenue, car elle offre le plus de flexibilité à l'utilisateur·ice ; non seulement elle lui permet de gérer/suivre plusieurs opérations en parallèle mais (surtout) elle n'efface pas l'intégralité des saisies existantes suite à une fausse manip'.
ferrous_sapling force-pushed données-sur-plusieurs-mois from 7f8f36dd0d to 3a3348a3c6 2026-04-02 22:02:25 +00:00 Compare 
rentrer graduations abscisses dans `base()`
extraire la génération des légendes en une fonction, introduire l'alias de type `Couleur` et s'en servir partout pour les couleurs passées aux svg, supprimer la constante `TAILLE_POINT_LÉGENDE` (car elle ne sert pas/plus).
ferrous_sapling force-pushed données-sur-plusieurs-mois from d09867ab6d to 284e35109c 2026-04-04 12:17:59 +00:00 Compare
ferrous_sapling force-pushed données-sur-plusieurs-mois from 284e35109c to f8ba20a048 2026-04-04 23:14:12 +00:00 Compare
ferrous_sapling commented 2026-04-04 23:21:51 +00:00
Author
Owner
Copy link

Il manque une dernière fonctionnalité pour fusionner cette branche avec la branche principale ; la saisie des tarifs du kWh entre chaque producteur et chaque consommateur d'une opération d'ACC. Ce fut introduit dans la branche principale après le début du découpage main/ui/mémoire de celle-cie, et donc a été perdu lors des rebase successifs sur main. Il faut reprendre le code d'interface utilisateur de main et l'adapter à la nouvelle « mouture » de l'interface, ainsi que de décider comment stocker l'info saisie.

Pour l'instant je penche plutôt sur copier l'approche prise dans cette branche pour stocker l'info annotant quel(s) consommateur(s) est/sont en contrat heures pleines / heures creuses ; l'écrire dans un fichier à coté des fichiers venant d'Enedis (c'est-à-dire dans le même dossier, et donc avoir un fichier par période/mois connu de l'outil) en faisant porter à ce fichier un nom standardisé.

Il manque une dernière fonctionnalité pour fusionner cette branche avec la branche principale ; la saisie des tarifs du kWh entre chaque producteur et chaque consommateur d'une opération d'ACC. Ce fut introduit dans la branche principale après le début du découpage `main/ui/mémoire` de celle-cie, et donc a été perdu lors des rebase successifs sur `main`. Il faut reprendre le code d'interface utilisateur de `main` et l'adapter à la nouvelle « mouture » de l'interface, ainsi que de décider comment stocker l'info saisie. Pour l'instant je penche plutôt sur copier l'approche prise dans cette branche pour stocker l'info annotant quel(s) consommateur(s) est/sont en contrat heures pleines / heures creuses ; l'écrire dans un fichier à coté des fichiers venant d'Enedis (c'est-à-dire dans le même dossier, et donc avoir un fichier par période/mois connu de l'outil) en faisant porter à ce fichier un nom standardisé.
rapports.rs : Lire les tarifs unitaires dans les `infos_acc` (plutôt que comme paramètre à part) pour la fonction `générer_rapports`. Arreter d'inclure la valeur de `infos_acc` dans les logs de cette fonction. Renommer `prix_unitaires` en `tarifs_unitaires` (et `prix_unitaire` en `tarif_unitaire`).

mémoire.rs : Définir le nom de fichier utilisé pour stoquer les tarifs unitaires entre producteurs et consommateurs saisis par l'utilisateur. Lire ces tarifs depuis ce fichier lors de la dérivation de la « mémoire » de l'application depuis le disque. Ajouter des variantes à l'énumération d'erreurs d'import ; lorsqu'un PDL de producteur ou de consommateur figurant dans les tarifs n'est pas présent parmis les informations venant d'enedis. Ajouter les fonctions `écrire_tarifs_unitaires_entre_producteurs_et_consommateurs` et `lire_tarifs_unitaires_entre_producteurs_et_consommateurs`. Ajouter tests pour ces deux fonctions.

lib.rs : Ajouter une variante à l'énumération d'erreurs de lecture ; lorsque la lecture d'un fichier CSV échoue. Ajouter l'attribut `tarifs_unitaires` à la structure de données `InfosAccSurUnePériode`.

templates/tableau_facturation_mensuelle.typ : Renommer « [Pp]rix [Uu]nitaire » en « [Tt]arif [Uu]nitaire ».
ferrous_sapling commented 2026-05-09 20:39:27 +00:00
Author
Owner
Copy link

Ça y est ! La grille de saisie des tarifs est implémentée et ceux-ci sont stockés dans un fichier à part, à coté des fichiers venant d'Enedis pour la période donnée.

Fonctionnellement parlant, la génération sur plusieurs mois est faite.

Pour être mergé dans la branche principale et sorti comme v2.0, il manque maintenant une mise à jour du guide d'utilisation - qui mérite sans doute d'être sorti du README principal et relégué ailleurs. Fichier markdown dans le répo, page du wiki - à voir.

Ça serait bien de laisser l'utilisateur·ice spécifier « depuis quel mois » prendre en compte les données utilisées pour générer les courbes dans les rapports. Ça peut sans doute attendre - et consister en - la v2.1.

Ça y est ! La grille de saisie des tarifs est implémentée et ceux-ci sont stockés dans un fichier à part, à coté des fichiers venant d'Enedis pour la période donnée. Fonctionnellement parlant, la génération sur plusieurs mois est faite. Pour être mergé dans la branche principale et sorti comme `v2.0`, il manque maintenant une mise à jour du guide d'utilisation - qui mérite sans doute d'être sorti du README principal et relégué ailleurs. Fichier markdown dans le répo, page du wiki - à voir. Ça serait bien de laisser l'utilisateur·ice spécifier « depuis quel mois » prendre en compte les données utilisées pour générer les courbes dans les rapports. Ça peut sans doute attendre - et consister en - la `v2.1`.
ferrous_sapling commented 2026-05-09 20:41:48 +00:00
Author
Owner
Copy link

À noter que le changement fait dans le commit 926bdbd8b5 mériterait d'être back-porté sur la branche principal et sorti comme v1.1.2, voir v1.2 – il ne faudrait pas faire attendre la v.2.0 pour générer des rapports corrects.

À noter que le changement fait dans le commit 926bdbd8b5 mériterait d'être back-porté sur la branche principal et sorti comme `v1.1.2`, voir `v1.2` – il ne faudrait pas faire attendre la `v.2.0` pour générer des rapports corrects.
src/mémoire.rs : Améliorer le traitement des erreurs d'import et d'écriture. Ajouter `impl std::error::Error` pour `ErreurÉcriture` et `ErreurImport`. Ajouter `impl From<csv::Error> for ErreurÉcriture` et `impl From<ErreurLecture> for ErreurImport`. Lire et écrire les fichiers indiquant quels consommateurs sont en contrats heures creuses / heures pleines correctement comme des CSV. Remplacer les `.expect()` dans la lecture et écriture de fichiers CSV par une remontée d'erreurs.

src/rapports.rs : Ajouter un `.expect()` sur les valeurs venant d'autres modules qui, auparavant, effectuaient le `.expect()` en interne.

tests/lecture_fichiers_pour_rapports_mensuels.rs : Ajuster les tests au fait que les fonctions testées revoient maintenant des `Result<V, E>` plutôt que des `V`.
src/ui.rs : Empêcher les éventuelles erreurs levées par `générer_rapports` de faire planter l'outil entier, et émettre des évènements de log les contenant.
src/mémoire.rs : Propager la modification de l'énumération d'erreur de lecture.
src/ui.rs : Retirer le passage de copies d'informations à l'appel de la procédure `générer_rapports`.
src/mémoire.rs : Ajouter une variante `Désérialisation` à l'énumération `ErreurChargementMémoire` ainsi qu'une `impl From<ron::error::SpannedError> for ErreurChargementMémoire`.

src/lib.rs : Supprimer la variante `Désérialisation` de l'énunmération `ErreurLecture` - on ne désérialise plus avec `ron` depuis des fichiers.
src/ui.rs : Ajuster l'affichage de l'état de la génération. Ajuster le calcul du nombre d'étapes total en fonction du nombre de rapports producteur et consommateurs à générer.
src/rapports.rs, tests/lecture_fichiers_pour_rapports_mensuels.rs : Propager la modification aux structures de donnée `FichiersProducteur` et `FichiersConsommateurs`.
ferrous_sapling force-pushed données-sur-plusieurs-mois from d9f51bdcee to 3ac1ba0fe4 2026-05-22 12:52:18 +00:00 Compare
This pull request is marked as a work in progress.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin données-sur-plusieurs-mois:données-sur-plusieurs-mois
git switch données-sur-plusieurs-mois

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff données-sur-plusieurs-mois
git switch données-sur-plusieurs-mois
git rebase main
git switch main
git merge --ff-only données-sur-plusieurs-mois
git switch données-sur-plusieurs-mois
git rebase main
git switch main
git merge --no-ff données-sur-plusieurs-mois
git switch main
git merge --squash données-sur-plusieurs-mois
git switch main
git merge --ff-only données-sur-plusieurs-mois
git switch main
git merge données-sur-plusieurs-mois
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ferrous_sapling/generation-rapports-acc!2
No description provided.