Conversation
🐛⚙️ et corrige un bug dans le moteur lorsque plusieurs règles en, remplace une autre
…ssait pas dans les missings variables
|
Merci @johangirod pour la présentation super détaillée ! Ça me semble très intéressant, utile et de toute façon inévitable. Par contre je ne comprends pas l'exemple 1 (pourquoi 33 jours et pas 31 ?) et l'exemple 2 (pourquoi 0 jours alors que la réduction est "active" ?). |
|
Oups effectivement, ce sont des coquilles, je corrige ça. De manière générale, je suis de plus en plus persuadé qu'avoir une gestion des période plus subtile va s'imposer. Notamment pour le mécanisme de régularisation progressive sur plusieurs mois (par exemple : la réduction générale). On profite de la réduction jusqu'à un certain plafond (1,6 SMIC par an). C'est un sujet parallèle, mais c'est un gros chantier, et important si on veut être un moteur de calcul de cotisations. |
There was a problem hiding this comment.
Je suis d'accord avec toi : la gestion des pro-ratisations est fonctionnalité centrale du domaine que l'on traite et il faut une intégration directement au niveau du moteur.
Ce qui me gêne un peu avec ce mécanisme prorata temporis c'est qu'il complique la lecture de certaines règles avec une notion de pro-ratisation qui ne semble pas strictement nécessaire pour le calcul. J'ai annoté dans le code les endroits où ce mécanisme me paraît superflu dans la définition des règles.
Je trouve très intéressante l'idée de remplacer les enums de type "moins d'un an" / "moins de deux ans" / "moins de 3 ans" par un type date et un système de tranches sur les périodes. C'est sémantiquement plus proche du fonctionnement de ces mécanismes, et cela permettra de gérer à la fois les simulateurs et des formulaires de déclaration où l'on précise les dates exactes (là ou les enums sont de simples chaînes de caractères que l'on ne peut pas exploiter aussi finement).
En particulier dans le cadre du simulateur on peut continuer à proposer un choix de type "première année" / "deuxième année" sans demander la date d'effet précise et donc d'une certaine manière ignorer la date d'effet pour rester dans une logique de simulation où l'on privilégie une réponse rapide à une réponse exacte au jour près (réponse que l'utilisateur n'a pas forcément sous la main). Et même dans ce cadre simplifié de simulation, avoir une compréhension des dates d'effet au niveau du moteur permet d'éviter de poser plusieurs fois les mêmes questions, par exemple si deux dispositifs sont comptés à partir de la date de création de l'entreprise (mettons ACRE et ZFU) et que l'on dit que l'on est dans la première année pour l'ACRE, on en déduit que l'on est aussi dans la première année pour ZFU et on peut ne pas reposer une question pour ce dispositif. Par ailleurs, si l'entreprise est renseignée et que l'on connaît la date de création, on peut pré-remplir automatiquement les réponses à ces questions. Je ne sais pas si je suis très clair, mais l'idée c'est simplement que spécifier les dispositifs d'exonérations avec une date de début/d'effet et une durée permet une exploitation bien plus fine qu'avec de simples enums.
Je n'ai pas encore assez réfléchi pour faire une contre-proposition, mais il me semble que si l'on annote uniquement les dispositifs d'exonérations avec date d'effet + durée, il n'est pas nécessaire de modifier les autres règles pour préciser que leur mode de calcul est pro-ratisé.
Juste un mot sur la solution "hors moteur". L'idée était plutôt d'avoir une couche au dessus du moteur qui permette de prendre en compte des changements de situation au cours du temps, en faisant une combinaison linéaire de chaque situation avec un coefficient correspondant à la durée du cette situation. Par exemple [6 mois] × [salaire : 3000€/mois, acre: oui] + [6 mois] × [salaire : 3000€/mois, acre: non]. Je ne crois pas que cette solution pose un problème de complexité de calcul, même avec plusieurs dispositifs se chevauchant, et surtout il me semble que l'on est de toute façon obligés de décomposer par sous-période et de recombiner ensuite, et ce quelle que soit la méthode de calcul employée. Il me semble aussi que cette logique pourrait être utile dans le cadre de l'API paie pour les salariés (changement du nombre d'heures travaillés d'une semaine sur l'autre, changement de statut, etc.). Il ne me semble pas possible d'intégrer tous les changements de situations envisageables au niveau de la définition des règles, et qu'une couche au dessus de ces définitions pour combiner une situation évoluant au cours du temps est une abstraction utile. De plus il est possible d'afficher cette abstraction dans les pages de documentations via une barre en-tête (un peu comme « assimilé salarié | indépendant | auto-entrepreneur » dans le comparatif de régimes) qui permet de sélectionner la période / situation que l'on visualise.
Mon intuition serait donc d'ajouter un type date et un type durée au moteur comme tu le proposes, et de spécifier les dispositifs d'exonération avec une date d'effet et une durée. Je pense qu'il ne faut pas modifier la définition des autres règles, et que le calcul en lui même devrait se faire par décomposition en sous-périodes. Bien évidemment je suis totalement ouvert à d'autres solutions.
source/règles/base.yaml
Outdated
| prorata temporis: | ||
| assiette: plafond sécurité sociale temps plein / impôt . abattement . taux inversé | ||
| début d'effet: entreprise . date de création | ||
| durée: 3 ans |
There was a problem hiding this comment.
Je ne comprends pas l'utilisation de prorata temporis ici. Est-il nécessaire de re-spécifier la durée de 3 ans au niveau du plafonnement (elle est déjà indiquée au niveau de l'aide / du taux de réduction). Par ailleurs intuitivement, la proratisation devrait plutôt se faire sur le plafond sécurité sociale temps plein que sur cette formule non ?
There was a problem hiding this comment.
C'est la toute la subtilité. Dans certains cas, on voudra la valeur proratisée du PSS par rapport à l'année en cours, d'en d'autres cas, on voudra sa valeur complète.
There was a problem hiding this comment.
Je pense que c'est probablement le cas, ceci dit tu as un exemple en tête où le PSS n'est pas proratisé à la durée de la période considérée ?
There was a problem hiding this comment.
Je me posais la question tout à l'heure. Et je n'ai pas la réponse. Si le PSS est le plus souvent proratisé à la période de simulation, ça simplifie la définition des règles.
Si on pousse l'utilisation du module de recherche d'entreprise existante, la date de création sera pré-remplie. Pour le reste, on peut imaginer se servir des suggestions au dessus du champs date pour aller plus vite "il y a un an", "il y a deux ans", etc.
Effectivement, après reflexions, je partage cette intuition. Il ne devrait pas y avoir besoin du mécanisme de prorata temporis, juste ajouter un début d'effet et une durée pour certaine variable. Je vais tenter une contre-proposition en me basant sur ces remarques.
Le problème, c'est que certaines règles legislatives ont pour objet une situation qui évolue. En séparant le coté "dynamique" dans une surcouche, on se prive de la possibilité de les exprimer dans un langage clair. D'où ma volonté qu'elle soient intégrées d'une manière ou d'une autre dans la définition des règles. On commence avec les proratisations temporelle, mais on peut imaginer qu'il en ira de même avec d'autres lois qui se basent sur une évolution. La difficulté, je te rejoins là dessus, c'est de ne pas surcharger la définition des règles. |
|
Oui, effectivement le problème avec une API de type En fait ma réserve concernait le fait de surcharger inutilement la définition de certaines règles. Sur l'API du moteur je pense qu'il faut effectivement donner une situation et une période en entrée, et que le moteur puisse gérer le calcul et l’explication des aides temporaires sans données/interactions supplémentaires. |
johangirod
force-pushed
the
mécanisme-prorata
branch
from
1696b12 to
7a727d5
Compare
|
J'ai revu la proposition en prenant en compte les retours. Je pense que c'est beaucoup plus clair ainsi. Reste le vocabulaire : cela me gêne d'introduire la notion de variable, un peu trop orienté programmation, dans un langage qui était plus proche du domaine juridique / social. J'ai pensé à :
Mais rien ne me convient à 100% |
|
|
J'aime bien "calendrier", c'est court, simple, et ça implique directement l'idée d'une variable temporelle. Effectivement, pour les changements legislatifs, on peut imaginer via un mécanisme de remplacement, ou pour certains cas, via le mécanisme de calendrier : PSS:
période: année
formule:
calendrier:
périodes:
- en: 2018
montant: 42 932 €
- en: 2019
montant: 43 918 €
- en: 2020
montant: 44 121 €
Ca me va ! Je modifie la proposition dans ce sens. |
johangirod
force-pushed
the
couverture-legislative-independants
branch
2 times, most recently
from
36c6caa to
3225955
Compare
johangirod
force-pushed
the
couverture-legislative-independants
branch
11 times, most recently
from
fc4955e to
e5d84c4
Compare
|
Voir #866 |
Dans le cadre de l'implémentation des exonérations, nous arrivons à une limite du moteur : ces dernières sont définies à partir d'une date de début d'effet et eventuellement une date de fin d'effet. Elles ne doivent pas être pris en compte pour le calcul des cotisations en dehors de leur période d'effet.
Première idée
Cette introduction de la temporalité dans le moteur nous a apparu dans un premier temps trop hasardeuse, et nous étions partis avec @mquandalle sur une solution se basant sur une surcouche au moteur. Cette dernière ferait une simulation par combinaison de dispositifs actif sur l'année, qu'elle sommerait ensuite, pondéré par la période d'effet.
Néanmoins, cette solution souffre de deux inconvénients majeurs
Une extension de la définition de "période"
L'idée est d'étendre la notion de période de simulation : "année" / "mois", pour la rendre plus précise. Une période, c'est une date de début et une date de fin. Lorsque l'on clique sur "année" sur les simulateurs, on initialise la période à l'année courante :
On peut donc imaginer simuler des cotisations (et salaire) sur des période diverses : quelques semaines, quelques jours, plusieurs mois, plusieurs années...
La clé
période: flexibledans les variables ferait donc echo au fait que la valeur de cette variable est naturellement proratisée à la période de simulation. On peut d'ailleurs considérer que c'est le comportement par défaut, et supprimer le besoin d'expliciter à chaque fois la période d'une variableLa période de simulation, entrée du moteur
Période devient une entrée de premier niveau pour le moteur de calcul. On veut pouvoir remettre à zéro une situation sans forcément changer la période à calculer.
Les variables sont pro-ratisées par défaut :
On étend la gestion des périodes. Mois / année étaient proratisée dans une variable "flexible". Ce sera également le cas pour des périodes plus précises :
VOIR L'ANCIENNE PROPOSITION
Proposition d'un nouveau mécanisme :
prorata temporisLe mécanisme prorata temporis fonctionne en faisant calculant le prorata temporel entre la période de la variable et la période précisée en paramètre.
Syntaxe de base :
Exemple 1
Exemple 2
Exemple 3
Syntaxe dévelopée
Dans le cas d'exonération degressive (ZFU, ACRE), on voudrait pouvoir spécifier d'un coup différent taux pour chaque année. Je propose la syntaxe suivante :
Nouvelle proposition : mécanisme
variable temporelleSyntaxe par défaut
date d'effetdate d'effetAvec durée
date d'effetdate d'effetetdate d'effet + 1 anAvec périodes
date d'effetdate d'effetetdate d'effet + 1 andate d'effet + 1 anetdate d'effet + 2 an67.86% = 100% * (10 / 28) + 50% * (18 / 28)
Implications et questionnement