openfisca / openfisca-france

French tax and benefit system for OpenFisca
https://openfisca.org/fr
256 stars 97 forks source link

Gérer la date de demande dans les prestations sociales #629

Closed adrienpacifico closed 6 years ago

adrienpacifico commented 7 years ago

Bonjour,

Problématique

Les prestations sociales doivent souvent faire l’objet d’une demande pour être accordées, et la date de la demande est importante car elle détermine le montant de la prestation.

Exemple RSA

Exemple formel

Pour quelqu’un faisant une demande de RSA, sa situation du mois courant, ainsi que les 3 mois précédant sa demande seront pris en compte. Pour faire court le revenu moyen des trois mois précédents seront utilisé pour calculer le montant du RSA. Si une demande fait l’objet d’un montant non-nul, alors le RSA sera versé sur les trois mois suivant la date de la demande. Toute nouvelle demande faite dans un délai inférieur à trois mois suivant une demande ayant aboutit à un montant non-null de versement, ne sera pas considérée.

Exemple appliqué

Si je fais ma demande en avril pour le RSA, mes revenus de janvier, février et mars seront pris en considération pour calculer le montant du RSA. Ce montant (si non null) amènera à un versement au début du mois de mai, juin et juillet du RSA. Les demandes de RSA faites en mai ou en juin ne pourront pas donner, lui, à une modification du montant du RSA.

Constat

Aujourd’hui le RSA, semble-t-il codé assez rigoureusement par l’équipe de MesAides ne prend (sauf erreur de ma part) pas en considérations la date de la demande : un test-case pour un mois donné prendra les revenus des trois mois précédent et donnera le montant du RSA pour le mois de la demande.

Cela pose un problème en terme d’exploitation avec des données (ou sur des test case annuel avec des données infra): Le montant calculé du mois M sera fait avec une prestation calculée en “moyenne mobile”, alors que celle-ci devrait être calculé par “wagon” de trois mois.

J'ai comité un test qui ne passe pas ici

Implementation dans OpenFisca ?

Je ne vois pas d’autre solution que d’introduire une variable de demande de prestation pour gérer la chose. En contrôlant (ou pas) qu’une demande n’a pas été faite il y a moins de 3 mois.

Les simulations sur données et les tests case devraient mettre une date de demande de chaque prestation (par exemple tous les trois mois) .

J’avoue ne pas saisir comment fonctionne les extra-params. Et ai du mal à imaginer qu’ils sont indispensable étant donné le fonctionnement actuel des périodes dans OpenFisca qu’il ne soit pas possible de s’en passer. Il faudrait par contre soit interdire la mise en cache sur certaines variables (ppa_fictive ) par exemple en mettant une option au sein classe de la formule :

class ppa_fictive(Variable):
    column = FloatCol
    entity = Famille
    put_in_cache = False
    label = u”ppa fictive”

    def function(self, etc):
        …

        return period, ppa_fictive

Questions :

@laem @fpagnoux @Cbenz

fpagnoux commented 7 years ago

Est-ce que je raconte des bêtises ?

Non. Nous faisons toujours l'hypothèse pour mes-aides que le RSA est demandé le mois où la personne fait sa simulation. Donc on ne se préoccupe pas du problème moyenne glissante vs wagon, mais ton analyse est correcte.

Est-ce une priorité pour certains ?

Pour mes-aides, pas vraiment. Ces problématiques se posent pour les organismes qui payent vraiment les prestations, et qui doivent verser un montant qui peut évoluer dans le temps. Pour mes-aides, on répond simplement à la question : "Si je vais aujourd'hui demander du RSA, est-ce qu'on va me l'attribuer, et si oui combien ? " et on ne gère pas l'évolution des montants une fois l'aide attribuée.

Mais on sera très content si quelqu'un avance sur cette problématique :)

J’avoue ne pas saisir comment fonctionne les extra-params. Et ai du mal à imaginer qu’ils sont indispensable étant donné le fonctionnement actuel des périodes dans OpenFisca qu’il ne soit pas possible de s’en passer.

Le challenge pour proposer une implémentation de la PPA sans extra-params est toujours ouvert ;).

En fait, les extra-params sont arrivés justement suite au besoin de connaître la date de la demande. On avait le problème suivant:

On est d'accord que si on pouvait connaître la date de demande autrement, on aurait pas besoin de paramètre supplémentaire.

Mais si la date de demande est un champs indépendant alors ça suppose implicitement qu'il y a une demande unique pour la simulation, et qu'on ne pourra calculer la PPA qu'une seule fois. C'est pas un problème pour mes-aides, mais je ne suis pas sûr que ça colle aux simulations sur la durée que d'autres utilisateurs openfisca font.

Une implémentation sous forme de variable booléenne qui vaut True quand il y a demande te permet de gérer plusieurs demandes. Mais tout la mécanique derrière va être un peu lourde. Rien d'infaisable, mais il faudra balancer le coût d'une telle implémentation avec les bénéfices qu'on peut en retirer.

benjello commented 7 years ago

Il faut arriver à trouver une solution pour pouvoir faire des simulations sur la durée. L'idéal serait de trouver une solution générique et pas trop lourde.

fpagnoux commented 6 years ago

Juste une reflexion sur cette bien veille issue, for the record:

Je ne vois pas d’autre solution que d’introduire une variable de demande de prestation pour gérer la chose.

Un point bloquant à cette approche est que si la date de demande de prestation est une variable, alors elle est a priori vectorielle.

Or cette date de demande est utilisée comme période dans certains calculs, et il est loin d'être évident de calculer une variable pour un vecteur de périodes...

adrienpacifico commented 6 years ago

@fpagnoux je vois dans le les fonctions du rsa, une variable mois_demande et mois_courant. Est-ce que ça n'implique pas qu'OpenFisca utilise maintenant une date de demande ?

Morendil commented 6 years ago

@adrienpacifico C'est effectivement implémenté via une fonctionnalité extra_params des définitions de formule (non documentée, mais testée) mais il me semble que c'était déjà le cas au moment où tu avais soulevé cette question.

Bien que cette fonctionnalité ne soit implémentée que pour RSA et PPA, il me semble qu'elle fait le job pour ces deux cas, mais aussi qu'elle met à mal le modèle de propagation des valeurs dans les calculs. Je serais d'avis d'indiquer par un commentaire qu'il existe des réserves sur la généralisation de extra_params (quelque chose comme "Ceci est un hack, ne pas utiliser"), afin de forcer la prochaine personne qui rencontrera ce besoin à venir en discuter.

@fpagnoux Qu'en penses-tu ?

fpagnoux commented 6 years ago

Totalement d'accord.

La gestion des extra params apporte beaucoup de complexité côté Core, est mal documentée, et n'est pas implémentée partout (e.g. web API, tests YAML)

J'ai bon espoir qu'on s'en débarasse dans un avenir proche (j'avais commencé à faire un POC qui utiliserait une autre solution sans hack côté Core), mais en attendant 👍 pour le warning.

Morendil commented 6 years ago

PR soumise, je ferme l'issue.

adrienpacifico commented 6 years ago

https://github.com/openfisca/openfisca-france/pull/1154