Fix ppe_tp_sa

[benjello]

No description provided.

[fpagnoux]

Typo dans le changelog

[fpagnoux]

Typo dans le chanbelog

[fpagnoux]

Un commentaire serait le bienvenue pour expliquer ce que ce fait ce code, l'emploi d'un while étant inhabituel sur des formules openfisca.

[benjello]

@fpagnoux : s'il faut retravailler le commit, n'hésite pas à me diriger vers la bonne pratique ;-)

[fpagnoux]

Si par le commit tu veux dire le contenu du code, je ne vois pas de helper de haut niveau qui pourrait satisfaire le besoin, ni même de helper qui pourrait nous retourner les douze mois à partir de l'année, donc la solution proposée ici avec le commentaire fait l'affaire.

Concernant l'historique, la branche est un peu en retard vis à vis de master. Un git rebase origin/master devrait te permettre sans difficulté de la remettre à jour.

Quand je vois les 4 commits, je me dis aussi qu'on pourrait tous les compresser en un seul commit, vu que les 3 derniers sont des correctifs le premier. Tu peux le faire avec git rebase origin/master --interactive ou avec gitup si tu es sous Mac (plus simple). Mais c'est un usage plus avancé, donc pas d'obligation.

Concernant le changelog, on peut essayer d'appliquer les nouvelles guidelines :

---

13.2.1 — #687

• Évolution du système socio-fiscal
• Périodes concernées : Jusqu'au 31/12/2015.
• Zones impactées :
  • revenus/activite/salarie
• Le calcul de l'indicatrice de travail à temps plein ppe_tp_sa renvoyait une valeur érronée, provoquant des erreurs dans le calcul de la prime pour l'emploi ppe.

---

@benjello n'hésite pas à me corriger sur le fond.
@MattiSG, je n'oublie rien ? On est dans un cas où d'après moi le chemin vers le fichier du modèle n'apporte pas d'information claire. On a l'impression que ça concerne tous les salariés, en fait on est dans le domaine spécifique du calcule de la PPE.

[MattiSG]

git rebase origin/master

→ git fetch --prune && git rebase origin/master 🙂

Le nouveau changelog me semble très bien (attention à l'accent en trop sur erronée). C'est encore un peu tôt pour avoir des conclusions sur ce qui est clair ou non, je pense :) prenons note et accumulons un ou deux autres exemples. Comment imaginerais-tu (imagineriez-vous) fournir une information utile en ce qui concerne les zones impactées, i.e. qui me permette de déterminer en tant que réutilisateur si je dois creuser cette modification plus avant ou non ?

ProTip section

les compresser en un seul commit

Pour info, on appelle cette opération un squash. Et, si lorsque tu crées un commit de correction tu commit avec git commit --fixup "Message du commit à corriger", la commande git rebase origin/master --autosquash le fera pour toi ! 😄 Plus d'infos. 🌟

[benjello]

@fpagnoux : this PR should be OK now

[fpagnoux]

GTM (j'ai enlevé l'upstream merge)