Quotient Familial : réformer le mode de calcul

[magemax]

Ajoute une prise en compte d'une réforme du calcul du quotient familial selon les modalités de l'article 194 du CGI.

Le petit bout suivant peut être rajouté aux requêtes :

"calcul_nombre_parts" : {        
    "parts_selon_nombre_personnes_a_charge":{
        "veuf":[1, 2.5, 3, 4, 5, 6, 7],
        "maries_ou_pacses":[2, 2.5, 3, 4, 5, 6, 7],
        "celibataire" : [1, 1.5, 2, 3, 4, 5, 6],
        "divorce" : [1, 1.5, 2, 3, 4, 5, 6]
    },
    "parts_par_pac_au_dela" : 1,
    "nombre_de_parts_charge_partagee":{
        "zero_charge_principale": {
            "deux_premiers" : 0.25, 
            "suivants" : 0.5
        },
        "un_charge_principale": {
            "premier" : 0.25, 
            "suivants" : 0.5
        },
        "deux_ou_plus_charge_principale" :  {
            "suivants" : 0.5
        }
    },
    "bonus_parent_isole":{
        "au_moins_un_charge_principale" : 0.5,
        "zero_principal_un_partage" : 0.25,
        "zero_principal_deux_ou_plus_partages" : 0.5
    }
}

La PR corrige aussi quelques bugs qui empêchaient le calcul correct du nbptr dans certains cas :

• Les veufs étaient comptés comme des celibs
• Les enfants en charge alternée n'étaient pas comptés correctement

Questions résiduelles :

• Quels jeux de tests pour s'assurer que tout ça fonctionne ?
  • Vérifier que la fonction nbptr custom donne bien le même résultat qu'OF sur un jeu de familles
  • Vérifier que chaque param change bien les résultats ?
  • Vérifier sur un jeu de tests qu'on obtient bien le même résultat qu'OF ? Mais pour ça il faut faire un jeu de cas types au format OF et un autre au format Leximpact
• Quel process pour s'assurer que le nbptr d'openfisca ne bouge pas sans nous ? (Probablement rien, si l'IR change on le saura a priori)
• Pas mal de paramètres dans la formule existante d'openfisca n'existent plus, on pourrait la simplifier pour la clarifier (enfin, on pourrait en retirer environ 30% à vue de nez)
• Le calculate() d'Openfisca semble arrondir par défaut, même dans le cas de variables où la virgule est assez importante, genre nbptr. J'espère que c juste l'output et pas en interne, mais c'est quand même bizarre que calculate() arrondisse sans le dire. Ptet que c une feature.
• @DorineLam En faisant ça, je me suis rendu compte qu'on tendait aux parents isolés le même piège que la déclaration d'impôt : on ne systématise pas le cochage de la case pour les personnes qui sont seules avec un enfant à charge. On pourrait le faire ou au moins warner quand c'est pas le cas. Par exemple notre exemple dans les cas types aujourd'hui le parent seul se fait avoir car il a pas coché la case "parent isolé". Est ce vrai qu'un celib/veuf/divorcé avec enfant à charge a toujours le droit à cocher la case parent isolé ? Si oui, ne devrait on pas inclure un petit warning si l'usager crée un cas type comme ça en disant "c possible mais ça décrit que le cas où le parent seul oublie de cocher la case T sur la déclaration 2042"?
• Pour l'instant, le comportement est le suivant :
  • si la requête ne contient pas le dictionnaire json ci dessus, aucun changement n'est effectué au calcul de nbptr
  • si la requête contient le dictionnaire des changements de cas types, on applique la fonction dans la réforme.
    • si un champ est manquant (ou que le nombre d'enfants du tableau n'est pas le même pour toutes les catégories de situation maritale), le calcul échoue lamentablement. On devrait plutôt renvoyer une erreur à l'usager j'imagine. Comment ?
      • Throw une exception custom (LexCeption) et l'attrapper au moment du call de l'API
      • Effectuer les checks au moment du handler de la requête? (PAs forcément adapté, ça nécessite que la partie handler soit au courant de toute la structure ce qui est ptet pas nécessaire)
• @LoicPoullain Les noms des variables sont horribles à ce stade, j'ai pas voulu trop passer de temps dessus, donc je suis chaud pour n'importe quelle suggestion que vous apporterez
• Et dans openfisca on modifie quoi?

@DorineLam Le bullet point où je t'ai taggée te concerne peut être, le reste c'est pour ta culture @sandcha fais toi plaise tous ces points sont pour toi @LoicPoullain La partie qui va t'intéresser directement c'est la structure de la requête (décrite ci dessus), et les noms de variables.

Tous les trois : lisez les parties qui vous concernent (et plus si affinité), et parlons-en pour voir comment on avance.

[DorineLam]

@magemax Merci pour ce super texte de mise en contexte. J'ai regardé plus en détail la question "parent isolé" dans notre générateur de cas type. Effectivement on a manqué un élément. Il faut par défaut que la case parent isolé soit cochée, à partir du moment où il y a un parent et au moins un enfant. C'est intéressant de se poser la question de qu'est-ce qu'il se passe pour les foyers qui bénéificie théoriquement de cette aide mais qui auraient omis de cocher la case T ? Et bien j'en sais rien du tout. Deux options :

• Soit vous avez une des données suffisamment précises dans l'ERFS FPR, qui permettent de repérer ce cas. => On permet alors de décocher la case mise par défaut.
• Soit on a pas suffisamment d'infos, et dans ce cas, je propose qu'on reste sur le cas théorique. Personnellement, je penche plutôt pour le cas numéro 2.

Voici une capture d'écran des cas dans le générateur de cas type.

[LoicPoullain]

• si un champ est manquant (ou que le nombre d'enfants du tableau n'est pas le même pour toutes les catégories de situation maritale), le calcul échoue lamentablement. On devrait plutôt renvoyer une erreur à l'usager j'imagine. Comment ?
• Throw une exception custom (LexCeption) et l'attrapper au moment du call de l'API
• Effectuer les checks au moment du handler de la requête? (PAs forcément adapté, ça nécessite que la partie handler soit au courant de toute la structure ce qui est ptet pas nécessaire)

@magemax Sur cet aspect, une technique assez courante de faire est celle-ci:

• Définir un schéma JSON qui décrit le format attendu du corps de la requête.
• Valider le corps de la requête sur ce schéma. Si le format est bon, on passe à la suite. S'il n'est pas bon, on retourne une erreur 400 - BAD REQUEST au client avec un descriptif. Il y existe déjà plein de bibliothèques spécialisées dedans qui valide un objet contre un schéma JSON et produise un descriptif de l'erreur le cas échéant.

Pour l'histoire de la validation de la longueur des tableaux, un approche plus "dev/objet" et moins maths serait la suivante. Cette nomenclature permet de faciliter l'implémentation côté front et elle peut être décrite complètement par un schéma JSON :

// Avant
{
   "veuf":[1, 2.5, 3, 4, 5, 6, 7],
    "celibataire" : [1, 1.5, 2, 3, 4, 5, 6],
}
// Après
[
  {
    "veuf": 1,
    "celibataire": 1
  },
  {
    "veuf": 2.5,
    "celibataire": 1.5
  },
  ...
]

Cet objet JSON peut ensuite être converti facilement en tableaux numériques avec 2-3 lignes python.

[LoicPoullain]

Sur le reste de la spec de l'API, j'aurais tendance à dire:

• camel case (pour pas qu'on ait à convertir les noms des variables sur le front)
• cohérence de noms entre parts_selon_nombre_personnes_a_charge et parts_par_pac_au_dela (par ex partsParPersonneACharge et partsParPersonneAChargeAuDela)

Voilà !

[magemax]

OK, l'inversion des tableaux fait du sens. J'ai camelCasé tout ça, à noter que le reste de la requête est inchangé.

On en arrive à la structure ci-dessous. Avant que je change, @LoicPoullain @sandcha des suggestions supplémentaires?

"calculNombreParts": {
    "partsSelonNombrePAC": [
        {"veuf": 1, "mariesOuPacses": 2, "celibataire": 1, "divorce": 1},
        {"veuf": 2.5, "mariesOuPacses": 2.5, "celibataire": 1.5, "divorce": 1.5},
        {"veuf": 3, "mariesOuPacses": 3, "celibataire": 2, "divorce": 2},
        {"veuf": 4, "mariesOuPacses": 4, "celibataire": 3, "divorce": 3},
        {"veuf": 5, "mariesOuPacses": 5, "celibataire": 4, "divorce": 4},
        {"veuf": 6, "mariesOuPacses": 6, "celibataire": 5, "divorce": 5},
        {"veuf": 7, "mariesOuPacses": 7, "celibataire": 6, "divorce": 6},
    ],
    "partsParPacAuDela": 1,
    "partsParPACChargePartagee": {
        "zeroChargePrincipale": {"deuxPremiers": 0.25, "suivants": 0.5},
        "unChargePrincipale": {"premier": 0.25, "suivants": 0.5},
        "deuxOuPlusChargePrincipale": {"suivants": 0.5},
    },
    "bonusParentIsole": {
        "auMoinsUnChargePrincipale": 0.5,
        "zeroChargePrincipaleUnPartage": 0.25,
        "zeroChargeprincipaleDeuxOuPlusPartage": 0.5,
    },
}

[sandcha]

Proposition : Simple, juste une unification de la casse de "personne à charge" vers PAC (majuscule puisque c'est un acronyme) :

"calculNombreParts": {
    "partsSelonNombrePAC": [
        {"veuf": 1, "mariesOuPacses": 2, "celibataire": 1, "divorce": 1},
        {"veuf": 2.5, "mariesOuPacses": 2.5, "celibataire": 1.5, "divorce": 1.5},
        {"veuf": 3, "mariesOuPacses": 3, "celibataire": 2, "divorce": 2},
        {"veuf": 4, "mariesOuPacses": 4, "celibataire": 3, "divorce": 3},
        {"veuf": 5, "mariesOuPacses": 5, "celibataire": 4, "divorce": 4},
        {"veuf": 6, "mariesOuPacses": 6, "celibataire": 5, "divorce": 5},
        {"veuf": 7, "mariesOuPacses": 7, "celibataire": 6, "divorce": 6},
    ],
    "partsParPACAuDela": 1,
    "partsParPACChargePartagee": {
        "zeroChargePrincipale": {"deuxPremiers": 0.25, "suivants": 0.5},
        "unChargePrincipale": {"premier": 0.25, "suivants": 0.5},
        "deuxOuPlusChargePrincipale": {"suivants": 0.5},
    },
    "bonusParentIsole": {
        "auMoinsUnChargePrincipale": 0.5,
        "zeroChargePrincipaleUnPartage": 0.25,
        "zeroChargeprincipaleDeuxOuPlusPartage": 0.5,
    },
}

[sandcha]

@magemax Globalement, sauf surprise sur les équations comme évoqué dans la revue, je serais en faveur de merger et de renforcer nos vérifications au fil de l'eau. 🙂