Suite à un retour demandant quel était le type de dépense à mettre dans la case 'dépense'.
C'est ce qu'on veut éviter à tout prix : faire planner le doute sur les dépenses déductible
Par ailleurs, cela rajoute une charge cognitive (combien je vais dépenser), pas forcément necessaire.
On préfère clarifier qu'il faut bien penser à déduire les dépenses liée à l'activité pour avoir le revenu disponible
Gros changements en perspective :
- Supprime la notion de période, au bénéfice de celle d'unité
(`période : mensuelle` devient `unité: €/mois`)
- Améliore les rapports d'erreur avec des messages plus clair
- Ajoute un avertissement lorsque des types ne sont pas compatible
- Ajoute la conversion automatique d'unité dans le moteur
- Ajoute une notion d'unité par défaut de la simulation,
c'est l'unité vers laquelle les règles qui ne spécifient pas
d'unité seront converties
- Ajoute une notion d'unité par défaut des règles, qui spécifie
l'unité de la règle qui prévaut lorsque qu'il n'y a pas
d'unité par défaut de la simulation (utile pour les question ou
pour s'assurer du bon type d'une règle)
Et pour faire passer les tests jest au passage.
A noter : il faudra vraiment se pencher sur la notion d'applicable / non applicable
Une variable non applicable a une valeur '0' / 'false', mais une variable
à false n'est pas considérée comme non applicable. Je pense qu'il serait avantageux
de simplifier le modèle en introduisant une symetrie entre applicable si et la valeur
d'une variable.
Dans 16ae29bdc, j'avais supprimé la cotisation de 1% sur les CDD pour
financer le CIF. Cette cotisation n'avait en fait pas été supprimée mais
remplacée par une cotisation pour financer le CPF...
This reverts commit 16ae29bdcc.
Le paramètre SMIC utilisé dans le calcul des réductions, en particulier
de la réduction générale, doit prendre en compte les heures supplémentaires.
Cette non prise en compte nous conduisait à sur-estimer le montant des
cotisations sociales sur les heures supplémentaires.
Ajout de tests de non-regressions des calculs afin d'éviter de déployer
silencieusement des effets de bord non-désirés dans les règles de calculs.
J'ai ajouté Jest pour sa fonction de snapshot testing qui est
particulièrement adaptée pour ce type de cas (voir #717). J'ai essayé
avec mocha-snapshot sans succès.
J'ai eu un petit peu de mal à configurer Jest, car il n'est pas possible
de ré-utiliser la configuration Webpack, qu'il faut alors dupliquer. C'est
pourquoi j'ai limité l'utilisation de Jest aux seuls tests de snapshot.
À voir s'il y a un intérêt à migrer les tests Mocha vers Jest ultérieurement.
Fixes#717