search

openfisca / openfisca-tunisia

Tunisian tax and benefit system for OpenFisca
http://www.openfisca.tn
15 stars 7 forks source link

Ajout des SMIG et du SMAG 2018 et 2019 #102

Closed sandcha closed 5 years ago

sandcha commented 5 years ago

Ajout des dernières valeurs en vigueur pour les SMIG et le SMAG.

sandcha commented 5 years ago

@benjello Testé dans le commit ci-dessus (aka option 1).

Il y a eu un sujet sur cette transition mais pas de consensus. D'ailleurs, la documentation est plutôt sur la version précédente (ou floue) mais la transition des clefs unit et reference vers une section metadata a été encouragée dans le code de core.

À toi l'honneur de trancher 🙂. Pour ma part, ça me semble plus verbeux et je vois la multiplication de sections datées comme une source d'erreur ; en même temps, la séparation data/metadata (vue comme une section à structure plus libre) est intéressante et cela ne pose de problème ni à l'API web ni à l'explorateur.

benjello commented 5 years ago

Je pensais plutôt à la séparation entre l'entrée title et la href mais je suis d'accord que ce n'est pas optimal de tout mettre dans les metadata. Qu'en pense @fpagnoux ?

sandcha commented 5 years ago

Aujourd'hui, les noms autorisés de clefs pour les petits enfants de values sont fixes. Donc, on ne peut par exemple pas mettre title au même niveau que value.

Exemple de message d'erreur : Unexpected property 'title' in 'cotisations_sociales.gen.smig_40h_horaire[2019-05-01]'. Allowed properties are ['unit', 'metadata', 'reference', 'value'] (où, par ailleurs, unit et reference ont vocation à disparaître dans le temps ; cf. ce commentaire dans Core).

Par contre, on peut indiquer un champ metadata à côté de value. Ca donnerait quelque chose comme cette 2ème option :

values:
  ...autres années...
  2019-05-01:
    metadata:
      title: Décret gouvernemental n°2019-454 du 28 mai 2019
      href: http://www.legislation.tn/fr/detailtexte/Décret%20Gouvernemental-num-2019-454-du----jort-2019-043__20190430045432?shorten=m5lq
    value: 1.984

Mais, ces données seront aujourd'hui perdues pour l'API web (contrairement à l'option 1, où le bloc de metadata est repris dans l'API web). Néanmoins, comme on ne les exploite pas encore pour les pages des paramètres dans le legislation explorer, la perte est limitée.

Est-ce qu'on reste sur la situation actuelle de master, la 1ère option ou la 2ème ? :) J'ai une préférence pour la 2ème mais on s'éloigne du choix de @fpagnoux et de ce qui a été appliqué pour l'IPP.

fpagnoux commented 5 years ago

J'ai une préférence pour la 2ème mais on s'éloigne du choix de @fpagnoux et de ce qui a été appliqué pour l'IPP.

Le choix de regrouper les références au niveau du node plutôt qu'au niveau des valeurs n'est pas une décision technique, mais une conséquence du format tabulaire: dans les Excel, une référence était renseignée par ligne, et pas pour une valeur en particulier.

Si les références sont propres aux valeurs, je préconiserais aussi la 2e option comme @sandcha. (Et sans doute qu'il faudra modifier la web API pour qu'elle expose ces métadatas)

benjello commented 5 years ago

Donc 2e option @sandcha