Améliore les mesures économiques

[bfabre01]

• Évolution du système socio-fiscal non rétrocompatible
• Périodes concernées : toutes.
• Zones impactées:
  • mesures.py
  • prelevements_obligatoires/prelevements_sociaux/contributions_sociales/csg_crds.py
• Détails :
  • Ajoute des mesures de revenu super brut au niveau du ménage
  • Corrige le calcul de minima_sociaux (pour prendre en compte la CRDS sur ces revenus, comme c'est le cas pour aides_logement et prestations_familiales.
  • Corrige le calcul de la variable csg pour inclure la CSG sur les revenus non salariés
  • Modifie le calcul de la variable revenus_nets_du_travail
  • Renomme la variable plus_values_revenus_nets_du_capital en plus_values_base_large

• Supprime les variables:
  • niveau_de_vie_net
  • revenu_net
  • revenu_net_individu

[Morendil]

Merci @bfabre01 ! et @claireleroy à la review tenons bien compte du fait qu'il s'agit ici non pas d'un changement mineur mais bien d'un "breaking change" (et non des moindres, on a beaucoup de réutilisations qui utilisent directement revenu_disponible). Je ne suis pas certain de la valeur de certains de ces renommages, par exemple dans la mesure ou revenu_disponible est précisément rattachée à Menage, quel est la plus-value apportée par le suffixe correspondant à l'entité ?

Je prendrai le temps d'une review un peu plus approfondie dans les jours à venir et toute précision sur les tenants et aboutissants d'ici là sera la bienvenue…

[bfabre01]

@Morendil : merci pour ton retour. Je pense qu'ajouter le suffixe _menage permet de clarifier l'entité à laquelle on se réfère. Cette variable est construite à partir de variables regroupant toutes les entitées (prestations au niveau famille, impôts au niveau foyer fiscal, etc.), et cela permet de clarifier le choix de cette entité utilisée en bout de course pour les utilisateurs. Et ce d'autant plus qu'un utilisateur peut être également intéressé par un revenu disponible calculé au niveau famille plutôt que ménage par exemple. En tout cas, d'expérience, ce suffixe clarifie les choses pour nous dans TAXIPP.

[fpagnoux]

Comme @Morendil , je suis assez circonspect sur l'ajout du suffixe _menage, pour les raisons suivantes:

• On n'ajoute des suffixes "entités" que très rarement aux variables. loyer ne s'appelle pas loyer_menage, par exemple. Les ajouter ici réduit la cohérence du nommage.
• Il n'y a aujourd'hui qu'un seul revenu_disponible défini dans OpenFisca, et aucun au niveau de la famille ou de l'individu. Il n'y a donc pas d'ambiguité aujourd'hui.
• La variable revenu_disponible est sans doute la variable la plus utilisée dans les exemples d'OpenFisca France disséminés ici et là. Ce renommage impose d'adapter tous ces exemples et probablement d'utiliser une autre variable au nom plus simple.

Dans l'ensemble, je crois qu'il y a plus de désagréments que de bénéfices à effectuer ce changement 🙂

[bfabre01]

@Morendil @fpagnoux : merci pour vos retours. On avait fait ce renommage sous taxipp, car on décline de notre côté certaines variables (comme revenu_disponible) au niveau famille, et aussi surtout, on crée beaucoup de variables exprimées en ménage par unité de consommation (pour décomposer la variable niveau_de_vie), d'où la lisibilité apportée par ce suffixe de notre côté. Ceci dit, je suis d'accord avec vous. Je comprends les désagréments au niveau de la communauté. On va reprendre la PR avec @claireleroy , et supprimer ces renommages.

[claireleroy]

@bfabre01 Du coup comme changements effectués :

• j'ai supprimé les renommages
• j'ai supprimé les modifs sur les aides au logement (déjà gérés dans une autre PR)
• et j'ai supprimé une partie du commit sur la gestion des revenus non salariaux dans revenus_nets_du_travail. Suite à un test qui ne passait pas sur ces revenus, j'ai regardé un peu et je ne crois pas que rpns_individu (cf. la formule) soit déjà net de cotisations non salarie comme le disait le commentaire, il faut bien les déduire des revenus du travail pour obtenir le revenu net.
  Je rajouterais un test et ça devrait être bon!

[Morendil]

Il me semble qu'on a encore un breaking en l'état (b8c2f44) car on supprime:

• credits_impot_sur_valeurs_etrangeres
• niveau_de_vie_net
• plus_values_revenus_nets_du_capital
• revenu_net
• revenu_net_individu

[claireleroy]

@Morendil Yes

• pour niveau_de_vie_net, revenu_netet revenu_net_individu, l'argument était que ces variables ne semblaient pas être utilisées (dans OF-France) du coup si personne ne les utilise chez les réutilisateurs d'OF-France je pense qu'on peut supprimer, mais on peut aussi les garder si vous préférez ?
• pour plus_values_revenus_nets_du_capital, ce n'est pas une suppression mais un renommage, c'est effectivement un breaking mais qui peut se justifier
• pour credits_impots_sur_valeurs_etrangeres, je ne vois pas où on supprime.. ?

[Morendil]

@claireleroy Oui il n'y a pas de souci pour supprimer des variables qui semblent superflues, on peut se faire confiance là dessus, ou pour des renommages en général (sauf certains cas particuliers sur lesquels on peut avoir des avis divergents), et comme on ne peut pas savoir quelles variables sont exploitées par les applis ou modules qui dépendent d'OpenFisca, on s'oblige à respecter le contrat Semver et déclarer un breaking, même s'il nous semble peu probable qu'il y ait vraiment des effets délétères. Comme ça tous ceux dont le setup.py qui spécifient un openfisca-france < 30.0 sont tranquilles.

[Morendil]

pour credits_impots_sur_valeurs_etrangeres, je ne vois pas où on supprime.. ?

En tout cas on ne le trouve plus sur la branche ! A vérifier…

[claireleroy]

@Morendil Ok merci pour les précisions, j'ai updaté le numéro de version en ce sens !

[bfabre01]

@claireleroy :

• pour les aides au logement, il me semble qu'on retrouve après ton commit le double compte de la CRDS logement qu'on avait repéré : la variable crds_logement est ajoutée (sachant que la variable est négative) à la fois dans aide_logement_montant (qui est injectée dans alf, als et apl) et dans aides_logement (qui somme alf, als et apl).
• Concernant rpns_individu, j'avais fait cette supposition du fait de la variable assiette_csg_crds_non_salarie qui, pour calculer l'assiette des cotisation, part de rpns_individu et ajoute les cotisations sociales (ou certaines...), ce qui veut dire que rpns_individu serait après cotisations. Peut-être que @benjello peut nous éclairer ? En tout cas, si on suit ton commit, il faut appliquer la même logique à revenus_travail_super_bruts_menage dans lequel j'avais fait la même hypothèse sur rpns_individu.

[bfabre01]

@claireleroy @Morendil : concernant credits_impots_sur_valeurs_etrangeres, elle n'est pas supprimée, mais prend un autre nom sur cette branche (avoirs_credits_fiscaux). C'est juste que cette branche n'est pas rebasée sur master, et qu'entre-temps, il y a eu ce renommage qui a été fait.

[claireleroy]

@bfabre01

• Pour les AL oui il y'a double compte mais dans une autre PR j'ai corrigé cela, donc après rebase et merge ce sera bon :)
• Pour les rpns_individu je pense qu'il faut se baser sur la formule de cette variable plutôt que sur son utilisation par assiette_csg_crds_non_salarie cela me parait plus sûr. Dans son calcul, il ne semble pas qu'on enlève les cotisations non salarie. De plus, pour calculer cotisations_non_salarie, on part d'une base fiscale qui est celle des rpns_individu. Cela montre bien que rpns_individu est brutes de cotisations non salariées.
  Par contre, pas besoin d'enlever cotisations_non_salarie dans revenus_travail_super_bruts_menage car il y aurait double compte (on enlève déjà cotisations_sociales_menage qui inclut cotisations_non_salarie !)

[bfabre01]

@claireleroy : ok ça marche, partons du fait que rpns_individu est avant tout prélèvement, ce qui est en effet cohérent avec la définition de cotisations_non_salarie. Mais ceci reste incohérent avec assiette_csg_crds_non_salarie, si je ne me trompe pas. En fait, je ne suis pas au clair avec la notion de revenus non-salariés à renseigner sur la feuille d'impôt. Mais ça doit faire l'objet d'une PR à part. J'ouvre une issue.

[Morendil]

@bfabre01 @claireleroy Je reprends la main pour rebaser la PR afin d'éliminer l'erreur PyTest 4. Pensez à reprendre cette version de la branche si vous avez à ajouter des commits

[Morendil]

@bfabre01 @claireleroy J'ai supprimé les modifications sur Changelog et setup.py: ça simplifie le rebase, et les rebase futurs - il est possible que cette PR traîne encore un peu et d'autres PR peuvent passer devant (edit #1199 est passée devant). Je les réintègrerai juste avant de merger.

[Morendil]

@claireleroy @bfabre01 Je vous laisse merger ou vous rends la main s'il y avait encore des modifications très mineures. (Si c'est plus substantiel, ouvrir une nouvelle PR serait plus indiqué.)