Quotient Familial : réformer le mode de calcul

Created by: 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.