-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix(rgcp/lodeom) : correction des erreurs de calcul avec régularisation annuelle #3325
Conversation
✅ Deploy Preview for nostalgic-mahavira-52b682 canceled.
|
🚀 La branche est déployée !
|
ac4b698
to
b079bca
Compare
contexte[heuresComplémentairesDottedName] = options.heuresComplémentaires | ||
} | ||
|
||
let SMIC = engine.evaluate({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je préfère éviter les let
qui peuvent être sources d’erreur…
Je suggère ici :
const SMICMensuel = engine.evaluate({
Puis dans le if (options.rémunérationETP) {
on peut :
return SMICMensuel * prorata +
SMICHoraire *
(options.heuresSupplémentaires + options.heuresComplémentaires)
et après le if
:
return SMICMensuel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok ! J'ai préféré inverser les return
en changeant le if
en if (!options.rémunérationETP) {
. De cette façon, le contenu du if
est plus court. C'est plus lisible selon moi mais c'est personnel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
En général, il est recommandé d’éviter les conditions négatives, mais on peut mettre tout le monde à l’aise très simplement :
const pleinTemps = !options.rémunérationETP;
if (pleinTemps) {
Ça a l’air tout bête comme ça, mais en vrai à la lecture ça évite une surcharge mentale qui peut induire en erreur.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
J'ai créé une issue #3344 pour ne pas oublier 😉
b079bca
to
0e15d46
Compare
…ets avec la régul annuelle
0e15d46
to
971139d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Petite question de logique métier :
Au lieu de partir du principe que le salaire brut renseigné est celui du mois incomplet, ne serait-il pas mieux que celui-ci soit toujours celui inscrit dans le contrat de travail. On pourrait ainsi calculer le la rémunération pour le mois incomplet grâce aux règles de la loi, plutôt que de le laisser à la charge de l'utilisateur. En demandant par exemple, le nombre de jours d'absence, ou alors le nombre de jours travaillés et la durée du mois.
Cela permettrait d'ailleurs de calculer le prorata du PSS, qui est basé sur le nombre d'heures.
produit: | ||
- rémunération de base mois incomplet | ||
- 1 / rémunération équivalente mois complet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On peut écrire :
salarié . mois incomplet . prorata:
valeur: rémunération de base mois incomplet / rémunération équivalente mois complet
@johangirod je ne suis pas confiante dans notre capacité à calculer le bon montant de cette façon. De plus, le simulateur va peut-être être décomissioné finalement. Il me semble donc préférable d'éviter d'y travailler davantage (hors bugs bien sûr) tant que cette question n'aura pas été tranchée. |
Résoud #3265