Draft: Modifications mineures du calcul d'ajustement PSS

[dsmadja]

Bonjour,

Essayant OpenFisca sur un cas particulier qu'il m'était impossible de simuler, je propose la modification permettant de le faire : il s'agit de l'option de renonciation à l'ajustement du PSS pour un salarié à temps partiel.

Au passage, comme il s'agissait du paragraphe suivant du BOSS, j'ai aussi intégré ici la valeur max de l'ajustement (qui ne peut pas dépasser la valuer légale du PSS)

• Changement mineur.

• Périodes concernées : toutes.

• Zones impactées : openfisca_france/model/prelevements_obligatoires/prelevements_sociaux/cotisations_sociales/travail_prive.py.

• Détails :

  • Ajout d'une variable booléenne permettant d'indiquer l'option de renonciation à l'ajustement du PSS prévue par la loi pour un salarié à temps partiel
  • Fixation du maximum en sortie de la formule d'ajustement, qui ne peut pas dépasser la valeur légale du PSS

• ---

Ces changements :

• Ajoutent une fonctionnalité (par exemple ajout d'une variable).

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

• ---

[dsmadja]

Le commit 061fac99e3e5ead58509a89bcf085d2b444a4243 permet le calcul de proratisation au prorata temporis exact, et non plus avec la méthode des 30èmes, comme prévu par l'évolution de l'art. 242-2 (https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000006749051/2018-01-01/ + https://www.urssaf.fr/accueil/employeur/cotisations/comprendre-cotisations/calcul-cotisations-employeur.html)

[sylvainipp]

(Re)Bonjour et merci pour la contribution ! Quelques petites remarques : Je suis complètement d'accord sur le fait que l'option par défaut semble être la proratisation. Sur la forme, on privilégie généralement un rebase fait juste avant de merge à des merge intermédiaire avec master, pour des raisons de lisibilité de l'arbre git et en raison du nombre de contributions élevé sur certaines périodes. Il vaut mieux créer deux formules différentes que ces inégalités sur des périodes, je vais en proposer une version et la push pour déclencher la CI. J'en profite pour éviter l'usage de calendar avec period.days qui donne le nombre de jour dans le mois. Il serait bon de rajouter un test pour vérifier tout ça, la référence boss.gouv.fr peut permettre de le faire.

[dsmadja]

Merci Sylvain pour la review et les commentaires.

Dès que j'ai un moment, je changerai donc pour créer les deux formules différentes, supprimerai l'import de calendar pour utiliser period.days, et créerai un test adéquat.

Du coup, il est préférable que je reparte sur un rebase récent et fasse une nouvelle PR à ce moment, je suppose ?

Je pense aussi isoler le commit https://github.com/openfisca/openfisca-france/commit/061fac99e3e5ead58509a89bcf085d2b444a4243 dans une autre PR. Cette modif ayant toutes les chances de mettre en erreur de précédents tests, il vaut sans doute mieux la traiter indépendamment.

Je pars là-dessus, sauf indication contraire.

Merci encore !

[dsmadja]

cf. Nouvelle PR 2382