Explorer l'historique de la législation #2704
mquandalle
started this conversation in
General
Replies: 1 comment
-
En fait je ne suis pas sûr de l'intérêt du mécanisme date: 17/04/2022
smic:
variations:
- si: date >= 01/05/2022
alors: 1645€
- si: date >= 01/01/2022
alors: 1603€ Inconvénient : ça ressemble un peu plus à une “implémentation” là où la philosophie des mécanismes est plutôt d'exposer des concepts de haut niveau et de garder les modalités de calculs cachées à l'intérieur du mécanisme Avantage : la dépendance à une variable |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Actuellement quand la législation évolue, on met à jour les simulateurs, mais on ne peut plus retrouver les anciens taux et relancer une simulation à une date antérieure. C'est une fonctionnalité qu'on a envie d'ajouter depuis un moment sur mon-entreprise (#34), et c'est aussi un besoin pour les utilisateurs de notre future API #1870.
Étape 1 : « variations »
Pour la mise à jour des règles au 1er janvier 2022, on a conservé les montants de 2021 derrière une condition :
mon-entreprise/modele-social/règles/base.yaml
Lines 57 to 61 in 30bc63b
Ça permet déjà de recalculer une fiche de paie avec les valeurs de l'année dernière en ajoutant un paramètre
année: 2021
dans la situation.Reste à exposer cette fonctionnalité dans l'interface, un simple
<select><option>2021</option><option>2022</option></select>
devrait faire l'affaire. #1138Étape 2 : changement en cours d'année
La législation peut aussi changer en cours d'année, par exemple le SMIC a été augmenté le 1er octobre dernier. On pourrait créer des nouvelles règles à chaque fois pour chaque période mais ça deviendrait rapidement difficile à maintenir. On a besoin d'introduire des notions calendaires du type “à partir de” et “jusqu'au"
L'intérêt c'est qu'on a plus besoin d'avoir les même “bornes” pour toutes les règles : les dates de changement du SMIC sont indépendantes de celle du plafond de la sécurité sociale ou d'une révision d'une convention collective. Et pour une date donnée on peut toujours déterminer quels dispositifs s'appliquent.
Cela nécessite l'implémentation d'un mécanisme « calendrier » dans publicodes. (discussion historique dans la PR sur les variables temporelles #793)
(edit: en fait non, il est aussi possible de rester avec le mécanisme
variations
et d'utiliser des comparaison de datedate <= 01/01/2022
)Côté UI, l'introduction de ce mécanisme peut amener 2 développements :
<select />
avec les dates pertinentes. Par exemple pas besoin d'afficher la date du 1er octobre qui correspond au changement du SMIC sur le simulateur auto-entrepreneur qui n'utilise pas cette valeur dans son calcul. Cette fonctionnalité d'inférences des bornes est implémentée sur mesaidesvelo (ici) et si on l'utilise aussi sur mon-entreprise il deviendra pertinent de l'intégrer dans publicodes Inférence de bornes pour les règles numériques publicodes/publicodes#48 (comment)Étape 3 : découpage de code
Sans découpage de code, on envoie tout l'historique de toutes les règles au client, alors qu'il n'en aura en général pas besoin. Ça rajoute du poids sur le réseau, du temps pour parser tout ça, bref c'est mal.
Là encore on aura besoin de support côté publicodes. Le plus naturel me semble être d'utiliser les fichiers comme unité de découpage. Par exemple pas besoin des règles de l'auto-entrepreneur quand je suis sur le simulateur salarié. À priori ce n'est pas trop compliqué de faire du chargement à chaud de règles avec une API du type
engine.addRules
à condition que l'on s'assure que toutes les dépendances utiles sont bien chargées.J'ai l'impression que l'on pourrait s'en sortir assez facilement en générant des imports ESM et en délégant à ViteJS la résolution du graphe.
S'agissant de l'historique des règles, ça implique aussi de déplacer les anciennes valeurs dans un fichier séparé, au moins si on veut bénéficier des performances du découpage de code. Je pense que ça peut avoir également un intérêt en terme de lisibilité des règles. En effet dans des cas simple comme l'historique du SMIC, la règle reste lisible même avec le mécanisme
calendrier
, mais ce ne sera pas le cas par exemple pour l'historique des barèmes du taux neutre #1959 (150 lignes par année)Pour pouvoir déplacer l'historique dans un fichier séparé on aura sans doute besoin d'un mécanisme de type “remplace” spécialisé dans la définition d'un historique de formules.
Étape 4 : échéanciers
Avec le mécanisme calendrier on reste dans l'évaluation d'une situation à un instant donné. L'idée ensuite serait de pouvoir évaluer une période complète en la découpant en mois ou en années. Par exemple on donne une liste de salaires versés où chaque ligne correspond à un mois et on veut prendre en compte les évolutions de la législations intervenus en cours de route pour le calcul des cotisations et impôts.
L'idée a été largement explorée et expérimentée dans la précédente implémentation des « variables temporelles » dans #866, (supprimées dans #1579). Le prérequis est de simplifier l'organisation interne des mécanismes dans publicodes publicodes/publicodes#23
Beta Was this translation helpful? Give feedback.
All reactions