Revalorisation des allocations familiales au 1er janvier 2019 #1248

mtifarine · 2019-01-04T10:23:08Z

Évolution du système socio-fiscal.mineur.
Périodes concernées : à partir du 01/01/2019.
Zones impactées : prestations/prestations_familiales/af/modulation.
Détails :
- Revalorisation des plafonds de ressources et de la majoration du plafond par enfant dans le calcul de l'Allocation Familiale.

guillett · 2019-01-04T15:15:01Z

Merci beaucoup pour ta contribution ! Penses-tu pouvoir faire un refactoring de ces paramètres pour qu'ils correspondent davantage à ce qui es présent dans la législation.

Je pense en particulier à modulation.plafond_tranche_1 et modulation.plafond_tranche_2 qui sont calculés et pas directement lisible sur legifrance.gouv.fr Leur utilisation est très limitée et un refactoring serait bien venu

Searching 3263 files for "plafond_tranche_1" (regex)

openfisca_france/model/prestations/prestations_familiales/af.py:
  132  
  133          plafond1 = (
  134:             modulation.plafond_tranche_1
  135              + max_(af_nbenf - 2, 0)
  136              * modulation.majoration_plafond_par_enfant_supplementaire
  ...
  168  
  169          plafond1 = (
  170:             modulation.plafond_tranche_1
  171              + max_(nb_enf_tot - 2, 0)
  172              * modulation.majoration_plafond_par_enfant_supplementaire
  ...
  288  
  289          plafond1 = (
  290:             modulation.plafond_tranche_1
  291              + max_(af_nbenf - 2, 0)
  292              * modulation.majoration_plafond_par_enfant_supplementaire
  ...
  328  
  329          plafond1 = (
  330:             modulation.plafond_tranche_1
  331              + max_(af_nbenf - 2, 0)
  332              * modulation.majoration_plafond_par_enfant_supplementaire

openfisca_france/scripts/parameters/baremes_ipp/transform_ipp_tree.py:
  889      modulation['majoration_plafond_par_enfant_supplementaire'] = modulation_ipp.pop(
  890          'majoration_ressource_par_enfant_supplementaire')
  891:     modulation['plafond_tranche_1'] = modulation_ipp.pop('plafond_de_ressources_tranche_1')
  892      modulation['plafond_tranche_2'] = modulation_ipp.pop('plafond_de_ressources_tranche_2')
  893      af['majoration'] = prestations.pop('af_maj')

OpenFisca_France.egg-info/SOURCES.txt:
 2450  openfisca_france/parameters/prestations/prestations_familiales/af/modulation/index.yaml
 2451  openfisca_france/parameters/prestations/prestations_familiales/af/modulation/majoration_plafond_par_enfant_supplementaire.yaml
 2452: openfisca_france/parameters/prestations/prestations_familiales/af/modulation/plafond_tranche_1.yaml
 2453  openfisca_france/parameters/prestations/prestations_familiales/af/modulation/plafond_tranche_2.yaml
 2454  openfisca_france/parameters/prestations/prestations_familiales/af/modulation/taux_tranche_1.yaml

6 matches across 3 files

Qu'en penses-tu ? Merci !

mtifarine · 2019-01-04T16:14:16Z

@guillett effectivement, il faut voir avec @JenniferTelep pour récupérer toutes les valeurs des plafonds de ressources.
Pour info @jmdallais

guillett · 2019-01-04T16:18:48Z

Pour 2015
https://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=A255A658F13C8E33683829D842D23613.tplgfr38s_1?cidTexte=JORFTEXT000031632853&idArticle=LEGIARTI000031634884&dateTexte=20151217&categorieLien=cid#LEGIARTI000031634884

Morendil · 2019-01-07T10:15:54Z

(Rebase et suppression du commit modifiant CHANGELOG/setup - il vaut mieux ne pousser ce commit qu'au dernier moment, quand on est 100% certains de merger la PR dans la foulée.)

guillett · 2019-01-07T10:16:08Z

@JenniferTelep, @jmdallais comment voyez vous les choses ? Le refactoring est limité mais permettrait de rapprocher OpenFisca de la législation.

guillett · 2019-01-08T09:12:34Z

@frtomas pourrais-tu faire une première review ?

frtomas · 2019-01-08T09:45:06Z

@guillett Je regarde ça^^

guillett · 2019-01-08T09:45:43Z

Super merci !

guillett · 2019-01-14T16:33:54Z

@frtomas as-tu pu regarder ça ? Merci beaucoup !

frtomas · 2019-01-15T13:16:00Z

openfisca_france/model/prestations/prestations_familiales/af.py

+class af_montant_plafond_tranche_1(Variable):
+    value_type = float
+    entity = Famille
+    label = u"Plafond annuel de ressources n°1"


Peut être modifier un peu la description pour plus de clarté, quelque chose comme "Plafond annuel de ressources de la première tranche" ?

frtomas · 2019-01-15T13:17:19Z

openfisca_france/model/prestations/prestations_familiales/af.py

+class af_montant_plafond_tranche_2(Variable):
+    value_type = float
+    entity = Famille
+    label = u"Plafond annuel de ressources n°2"


Même chose, "Plafond annuel de ressources de la deuxième tranche" ?

frtomas · 2019-01-15T13:18:45Z

openfisca_france/model/prestations/prestations_familiales/af.py

    value_type = float
    entity = Famille
-    label = u"AF - Complément dégressif en cas de dépassement du plafond"
+    label = u"Depassement mentuel de ressources"


Corriger "Depassement mentuel de ressources" en "Depassement mensuel de ressources"

frtomas · 2019-01-15T13:27:47Z

...ca_france/parameters/prestations/prestations_familiales/af/modulation/plafond_tranche_1.yaml

@@ -3,9 +3,13 @@ reference: https://www.ipp.eu/outils/baremes-ipp/
 unit: currency
 values:
  2015-07-01:
-    value: 67140.0
+    value: 55950.0


Est-ce qu'il existe une référence pour cette valeur ?

Non, j'ai pas trouvé la référence pour cette valeur.

Ceci je pense: https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000030674064&dateTexte=&categorieLien=id

frtomas · 2019-01-15T13:27:54Z

...ca_france/parameters/prestations/prestations_familiales/af/modulation/plafond_tranche_2.yaml

@@ -3,9 +3,13 @@ reference: https://www.ipp.eu/outils/baremes-ipp/
 unit: currency
 values:
  2015-07-01:
-    value: 89490.0
+    value: 78300.0


Est-ce qu'il existe une référence pour cette valeur ?

Non, j'ai pas trouvé la référence pour cette valeur.

frtomas · 2019-01-15T13:30:42Z

tests/formulas/af_2019_01.yaml

@@ -0,0 +1,110 @@
+- name: Cas N°1 Allocations familiales - Couple, 2 enfants de moins de 14 ans


Il me semble qu'il avait été évoqué de ne pas ajouter de tests au projet pour de simples revalorisations, particulièrement quand elles sont appuyées par des références législatives simples et claires.

Ces tests ont un intérêt pendant la phase de dev pour s'assurer de la justesse et de la fiabilité des calculs mais selon moi ils ne représentent pas assez de valeur ajoutée pour être livrés.

frtomas · 2019-01-15T13:32:49Z

openfisca_france/model/prestations/prestations_familiales/af.py

@@ -166,17 +185,9 @@ def formula_2015_07_01(famille, period, parameters):
        base_ressources = famille('prestations_familiales_base_ressources', period)
        modulation = pfam.modulation

-        plafond1 = (
-            modulation.plafond_tranche_1
-            + max_(nb_enf_tot - 2, 0)


Quelle est la raison de la disparition de ce max_(nb_enf_tot - 2, 0) au profit du simple nb_enf_tot ?

Les anciennes valeurs des paramètres modulation.plafond_tranche_1 et modulation.plafond_tranche_2 sont calculées pour une famille de 2 enfants et ne sont pas les valeurs de base présentes dans la législation.

Merci pour cette réponse @mtifarine
Effectivement avec cette explication et en regardant à nouveau les anciens commentaires des plafonds tel que 56286 + 5628 * 2 je comprends mieux la modificaiton.

@mtifarine @guillett @frtomas Oui c'est vraiment mieux comme ça: d'une part on peut lire les articles de loi pointés par les références législatives, et faire le lien avec les paramètres; d'autre part on n'a plus besoin de recourir à ces commentaires qui auraient empêché d'utiliser le texte des références dans le legislation explorer (qui les traite comme des URL).

Je suis un peu réservé sur l'introduction de nouvelles variables, et je vois encore des possibilités de factorisation, ça vous convient si je reprends la main pour faire une proposition de formulation sans ajout de variables ? Je ne suis pas certain que ça soit possible, ou que ça mène au meilleur résultat, mais je suis curieux de voir ce qu'on peut faire. Si je ne trouve pas mieux on intègrera cette version.

Par ailleurs je vous invite à ne pas modifier vous-même setup.py et CHANGELOG.md, je continue à trouver ça plus simple pour la personne qui relit une PR et la mène jusqu'au merge de le faire au tout dernier moment. Autrement, on doit rentrer dans une correction de conflits Git à chaque fois qu'une autre PR a été mergée entre la demande de revue et la revue elle-même, c'est un travail inutile. Je le fais assez souvent pour le ressentir comme une friction :)

Il reste important de bien décrire les modifications apportées dans le commentaire de la PR.

Je profite de cette conversation pour évoquer un sujet qu'on avait abordé à l'oral avec @ThibaultCCMSA lors de notre rencontre à la DSS, mais que je n'avais pas eu l'occasion de traiter entre trève des confiseurs et urgences diverses. (J'associe à la conversation @guillett @frtomas @JenniferTelep - si j'oublie quelqu'un n'hésitez pas à les mentionner dans le fil.)

Je sais que le mode de fonctionnement actuel sur Github avait été adopté d'un commun accord, et il me semble que le début d'année est une bonne occasion pour le revisiter, il y a un point notamment sur lequel je souhaiterais une évolution.

L'idée est la suivante: il est intéressant pour nous d'évaluer l'efficacité du processus de traitement des issues en général sur OpenFisca France en mesurant (entre autres) le temps écoulé entre l'ouverture et la fermeture des issues, ainsi que le "stock" d'issues ouvertes à un moment donné (34 au moment d'écrire ces lignes). Je souhaite maintenir un stock bas et piloter par un temps de traitement le plus court possible.

Avoir une issue globale "Roadmap MSA" qui (par exception) restera ouverte un certain temps est tout à fait compatible avec ce mode de pilotage, et c'est quelque chose qui a bien fonctionné en 2018. Par contre c'est plus pénalisant de maintenir ouvertes de nombreuses issues. Ma préférence serait de ne pas ouvrir d'issue tant que le travail n'est pas démarré; en fait dans ce cas il suffit d'initialiser une PR directement, sans passer par l'étape de création d'une issue.

Seriez-vous OK pour que nous fermions les issues correspondant à la Roadmap MSA #1130, en prévoyant de les ré-ouvrir au fur et à mesure que le travail sur chacune est commencé (et les fermer à nouveau lorsqu'il est terminé) ?

Si vous préférez, on peut garder le stock actuel sans les fermer, et je serais alors demandeur qu'on adopte ce nouveau mode de fonctionnement pour les travaux futurs: une seule issue "roadmap" pour consolider le calendrier des travaux à venir, déclinées seulement en PR lorsque le travail commence.

Je suis à l'écoute de vos remarques bien entendu :)

@Morendil si tu as une idée de factorisation du code ne nécessitant pas d'ajout de variables, on te laisse volontiers reprendre la main et vérifier la faisabilité.

Concernant le second point, il faut effectivement voir ça avec @JenniferTelep et @ThibaultCCMSA.

frtomas · 2019-01-15T13:34:30Z

openfisca_france/model/prestations/prestations_familiales/af.py

-            + max_(nb_enf_tot - 2, 0)
-            * modulation.majoration_plafond_par_enfant_supplementaire
-            )
+        plafond1 = modulation.plafond_tranche_1 + nb_enf_tot * modulation.majoration_plafond_par_enfant_supplementaire


Pourquoi ne pas réemployer ces appels : plafond1 = famille('af_montant_plafond_tranche_1', period) ?

A moins que je rate quelque chose à la lecture, il me semble qu'il s'agit exactement de la même formule.

Pas le même nombre d'enfants : nb_enf_tot = af_nbenf + af_forfaitaire_nbenf

benjello · 2019-01-24T11:20:55Z

Désolé d'arriver après la bataille mais je pense qu'il faut faire attention quand on modifie les défnitions de certains paramètres. Je pense au plafond qui était donnée précédemment par le plafond pour 2 enfants (car il n'est pas possible d'avoir des AF pour 0 ou 1 enfant donc la valeur retenue était celle qui avait le plus de sens) et qui a été remplacée par la valeur "hors enfants". Sans arbitrer sur le fond, je pense qu'il vaut mieux créer des paramètres sous un nouveau nom plutôt que modifier des anciens paramètres notamment quad la référence est bareme-ipp. En tout cas cela me semble préférable avant le grand merge à venir.

guillett · 2019-01-24T12:48:32Z

@benjello je suis d'accord avec toi et je pense que cette PR devra faire l'objet d'un changement de version majeure. My 2cts.

frtomas · 2019-01-25T14:13:18Z

@benjello @guillett Telles que j'avais compris les choses, nous essayons de nous rapprocher au mieux des textes.
Dans ces conditions, je ne suis pas certain de voir la pertinence à maintenir des paramètres qui sont non pas des montants "de base", existants tels quels dans les références législatives, mais des montants "précalculés", obtenus à partir des montants et taux présent dans la législation et nécessitant un commentaire en plus de la référence pour être compris.
De plus comme l'a fait remarqué @Morendil, en utilisant la version avec les montants de bases :

d'une part on peut lire les articles de loi pointés par les références législatives, et faire le lien avec les paramètres; d'autre part on n'a plus besoin de recourir à ces commentaires qui auraient empêché d'utiliser le texte des références dans le legislation explorer (qui les traite comme des URL).

C’est la vision que j'en avais, mais on se pliera au choix du plus grand nombre ^^

benjello · 2019-01-25T14:20:55Z

@mtifarine : je suis d'accord avec toi sur le principe qu'il faille coller aux textes.

Pour être plus explicite, ma remarque s'appuie sur deux éléments:

le principe de moindre surprise : ne pas changer le concept sans changer le nom sans faire un GROS warning
il va y a avoir, normalement à court-moyen terme, une fusion de bases où les noms sont des clés entre les deux bases et détériorer cet information peut-être dommageable

Je préfère donc que l'on préserve les noms actuels, et le fonctionnement actuel sans surprise et que m'on adopte un objectif de meilleure qualité des paramètres ex-post.

guillett · 2019-01-25T14:27:42Z

Pour clarification, je soutiens le refactoring qui a été fait (car il a beaucoup de valeur étant donné qu'il permet de coller aux textes à la lettre) et la montée en version (pour le principe de moindre surprise).

benjello · 2019-01-25T14:34:45Z

Pour clarification sur la clarification de @guillett : ok aussi mais attention sur le nom des paramètres.
Après on peut noter cela dans un coin pour s'en souvenir quand on fusionnera mais si on peut à moindre coût ne pas se créer des confusions pour plus tard ...

sandcha · 2019-01-29T10:48:48Z

L'intégration continue/CircleCI a évolué pour builder sur python 3 uniquement.
Cette branche serait donc à rebaser pour voir le bon statut CircleCI.
Je n'ose le faire sur ce travail en cours mais je reste disponible pour aider si besoin. 🙂

Morendil · 2019-01-30T09:58:57Z

@mtifarine Je pense qu'on a eu un souci de coordination sur cette PR, j'avais force-pushé des commits à un moment et tu as poussé ~~une version antérieure~~ d'autres commits par dessus. Rien de grave, je pense avoir la bonne version.

Comme on en avait déjà discuté je vais pousser une nouvelle version avec une autre façon de factoriser les parties de code en commun, qui sera un helper; ça n'est pas une solution satisfaisante sur le long terme et c'est sans doute la meilleure tant qu'on a pas lancé des travaux sur Core pour permettre de traiter plus facilement la situation où on est ici, c'est-à-dire de pouvoir appeler depuis une formule une autre formule avec des valeurs différentes pour la quantité "nombre d'enfants" (nb_enf_tot ou af_nb_enf_).

Je garde donc la main sur cette PR et elle devrait aboutir dans la semaine.

Morendil · 2019-01-30T10:07:00Z

@benjello Bien vu, on a effectivement changé le sens du paramètre en lui gardant le même nom. On pourrait effectivement garder en parallèle les anciens paramètres et les nouveaux. Je vais étudier l'option.

Morendil · 2019-02-01T10:22:39Z

@mtifarine @guillett @benjello @frtomas J'ai l'intention de merger en fin de journée cette dernière version qui complète le travail de @mtifarine avec:

renommage des plafonds dont le sens est modifié afin d'éviter une montée de version majeure
factorisation des parties communes dans des helpers

J'attire votre attention sur la line 260 de cette version modifée, on calcule nb_enf_tot mais on ne s'en sert pas (comme le signale le marqueur noqa). Il est possible qu'il s'agisse d'un bug. Si c'est le cas il était présent avant cette PR, ce n'est donc pas une régression, et par conséquent pas bloquant pour merger mais je vous invite à analyser ce fonctionnement.

mtifarine added the contrib:msa Identification des sujets MSA label Jan 4, 2019

Morendil force-pushed the msa_af_2019 branch from 2028596 to b0ec6e3 Compare January 7, 2019 10:14

Morendil added flow:discovery and removed flow:discovery labels Jan 10, 2019

frtomas reviewed Jan 15, 2019

View reviewed changes

Morendil force-pushed the msa_af_2019 branch 4 times, most recently from 082d8ec to f910f9d Compare February 1, 2019 10:07

Revalorise les paramètres AF au 01-01-2019

6ca12d7

mtifarine and others added 4 commits February 1, 2019 18:58

Refactoring les paramètres plafond_tranche_1 et plafond_tranche_2

8fb5b2b

Réorganise le code pour faciliter la compréhension

1b5bd55

Prend en compte les remarques en relecture

1064f2d

Modifie CHANGELOG.md et setup.py

4227658

Morendil force-pushed the msa_af_2019 branch from f910f9d to 4227658 Compare February 1, 2019 18:01

Morendil approved these changes Feb 1, 2019

View reviewed changes

Morendil merged commit 66c3302 into master Feb 1, 2019

Morendil deleted the msa_af_2019 branch February 1, 2019 18:10

This was referenced Feb 6, 2019

Revalorisation des allocations familiales au 1er janvier 2019 #1238

Closed

Roadmap OF MSA jusqu'à février 2019 #1130

Closed

		@@ -0,0 +1,110 @@
		- name: Cas N°1 Allocations familiales - Couple, 2 enfants de moins de 14 ans

Revalorisation des allocations familiales au 1er janvier 2019 #1248

Revalorisation des allocations familiales au 1er janvier 2019 #1248

Conversation

mtifarine commented Jan 4, 2019

guillett commented Jan 4, 2019

mtifarine commented Jan 4, 2019

guillett commented Jan 4, 2019

Morendil commented Jan 7, 2019

guillett commented Jan 7, 2019

guillett commented Jan 8, 2019

frtomas commented Jan 8, 2019

guillett commented Jan 8, 2019

guillett commented Jan 14, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benjello commented Jan 24, 2019

guillett commented Jan 24, 2019

frtomas commented Jan 25, 2019

benjello commented Jan 25, 2019

guillett commented Jan 25, 2019 • edited Loading

benjello commented Jan 25, 2019

sandcha commented Jan 29, 2019

Morendil commented Jan 30, 2019 • edited Loading

Morendil commented Jan 30, 2019

Morendil commented Feb 1, 2019

guillett commented Jan 25, 2019 •

edited

Loading

Morendil commented Jan 30, 2019 •

edited

Loading