Remplacement de Montant par Value
Rétablissement des explications simu salarié
Possibilité de définir des objegtifs secondaires qui sont calculés mais
pas affichés par targetSelectuon
Car quand on parse et qu'on tombe sur une variable, on ne rentre pas
dans cette variable. Elle sera traitée par la suite dans le parseAll.
Ainsi on ne peut pas connaître son unité si elle a une formule
A = B * C
B = D / E
C unité km
D unité €
E unité km
Quand on tombe sur B dans A, B n'est pas encore parsée, et donc on ne
peut pas savoir que B est en € / km.
Il faudrait parser B, ce qui serait trop couteux. On pourrait
implémenter un cache au parsing, implémenter les unités comme des fonctions, ou encore gérer les unités lors de l'éval (ce qui est bête, car on n'a pas besoin des valeurs pour inférer les unités)
plutôt que de le charger dans le bundle principale.
- Permet d'avoir une estimation du temps de chargement
- Peut-être que le problème du nombre d'entrance plus faible que le nombre de visite sera ainsi reglé
Pour les simulateurs de revenu AS et indépendant, on ajoute après le bloc de revenu, un bloc entreprise, qui introduit les notions de charge et de chiffre d'affaires minimum.
Pour l'instant, on implémente via une deuxième variable identique à la première. Lorsque l'on aura un mécanisme d'extension de la base de règle (comme évoqué dans #566), on pourra imaginer avoir un nom différent en fonction du contexte de la simulation.
Suite aux retours utilisateurs rassemblé par l'Acoss (cc Agnes Nardon) :
- Uniformise les nom de tous les champs entre les différents simulateurs
- Pour la comparaison des régimes, on ne parle plus du CA, mais du montant dégagé pour la rémunération du dirigeant (plus clair)
- Supprime la notion de charge pour les auto-entrepreneur
- Tant que la simulation complète de l'entreprise n'est pas développé (cf #562), on enlève la notion de chiffre d'affaires des simulateurs de revenus. Elle est en effet triviale à calculer (rem total + charges) et laisse perplexe les utilisateurs même les plus renseignés
On ne les prenait pas en compte lorsque l'on utilisait treatVariable
D'où le gros besoin de fusionner une bonne fois pour toute treatVariable et treatRuleRoot
