Corrige la taxe aurifère suite à l'évolution des entités

[sandcha]

Fixes #24

⚠️ La branche de cette PR dépend du fix d'API Web pour permettre son test par calcul d'API.

• Correction d'un crash.

• Périodes concernées : toutes.

• Zones impactées : ./variables/taxes.py

• Détails :

  • Corrige l'erreur d'entité à l'appel de taxe_guyane_brute et taxe_guyane_deduction

• ---

Ces changements :

• Corrigent ou améliorent un calcul déjà existant.

• ---

Quelques conseils à prendre en compte :

• [x] Jetez un coup d'œil au guide de contribution.
• [x] Regardez s'il n'y a pas une proposition introduisant ces mêmes changements.
• [ ] Documentez votre contribution avec des références législatives.
• [x] Mettez à jour ou ajoutez des tests correspondant à votre contribution.
• [ ] Augmentez le numéro de version dans setup.py.
• [ ] Mettez à jour le CHANGELOG.md.
• [x] Assurez-vous de bien décrire votre contribution, comme indiqué ci-dessus

[sandcha]

Attention, tu as ouvert la PR vers fix-taxe-or et pas vers master, c'est normal ?

👍 Pour la branche de référence, c'était fait exprès pour que vous puissiez tester ^^ (on note d'ordinaire un warning dans la description de la PR pour que ce ne soit pas oublié).

Aussi, il faudrait incrémenter la version de OpenFisca-France-Fiscalite-Miniere

Vu que c'est un bugfix, une 3.1.0 semble bien, qu'en penses-tu ? C'est ligne 5 dans le fichier setup.py

Le bump de version est fait post revue pour ne pas avoir à revenir dessus si une autre PR est mergée entre-temps et le changelog reprend l'essentiel du descriptif de la PR. Mais il est vrai que ces conventions sont écrites nulle part. On pourrait les ajouter au CONTRIBUTING peut-être ? 🤔

En l'état actuel de la PR qui ne modifie que la règle de calcul d'une formule, le versionnement serait plutôt en patch selon la règle par défaut qui se base sur le fait que ça n'impacte pas l'interface de réutilisation du modèle.

Ceci dit, si on change la surface_totale de place / d'entité comme dit dans les commentaires plus haut, ce sera non rétro-compatible et donc un bump majeur.

[MichaelBitard]

Attention, tu as ouvert la PR vers fix-taxe-or et pas vers master, c'est normal ?

+1 Pour la branche de référence, c'était fait exprès pour que vous puissiez tester ^^ (on note d'ordinaire un warning dans la description de la PR pour que ce ne soit pas oublié).

Merci pour l'info je ne savais pas

Aussi, il faudrait incrémenter la version de OpenFisca-France-Fiscalite-Miniere Vu que c'est un bugfix, une 3.1.0 semble bien, qu'en penses-tu ? C'est ligne 5 dans le fichier setup.py

Oui 3.1.0 nickel !

Le bump de version est fait post revue pour ne pas avoir à revenir dessus si une autre PR est mergée entre-temps et le changelog reprend l'essentiel du descriptif de la PR. Mais il est vrai que ces conventions sont écrites nulle part. On pourrait les ajouter au CONTRIBUTING peut-être ? thinking

Oui en effet on pourrait faire ça, la chose étrange c'est que la PR ne peut pas passer tant que la version n'a pas été incrémentée, et ça me fait bizarre de relire des PR rouges (mais après, c'est parce que j'ai été habitué comme ça aussi)

En l'état actuel de la PR qui ne modifie que la règle de calcul d'une formule, le versionnement serait plutôt en patch selon la règle par défaut qui se base sur le fait que ça n'impacte pas l'interface de réutilisation du modèle.

Ceci dit, si on change la surface_totale de place / d'entité comme dit dans les commentaires plus haut, ce sera non rétro-compatible et donc un bump majeur.

Bien vu !

[sandcha]

Rebase en cours.