Révisions taux 2018
guillaume-sainthillier opened this issue · 11 comments
J'ouvre une issue pour discuter des travaux à faire pour updater l'app aux modalités 2018.
A discuter, je pourrais proposer des PR si j'arrive à comprendre les méthodes de calculs ;-)
Hello, j'ai créé une branche 2018 sur mon repo local avec pas mal de modifs. Peux-tu créer une branche sur ton repo pour que je propose une PR?
Pour info, tu as un aperçu sur https://guillaume-sainthillier.github.io/eurl-sasu/
Hello, désolé pour le délai de réponse, je suis en vacances dans les Alpes :-)
Je me demande s'il ne serait pas mieux de faire un repo à part pour la version 2018. Et dans ce sens, mieux documenter le repo actuel en précisant bien partout (readme et header de la page HTML) qu'il s'agit des modalités fiscales et sociales de 2017.
En même temps, une branche permet de comparer diverses années, mais je ne sais pas si ça a vraiment un intérêt. Tu as une opinion là dessus ?
Hello, je pense que ça serait compliqué de comparer les diverses années si la structure de l'appli change entre temps (ex sur le calcul de l'IS : https://github.com/AntoineViau/eurl-sasu/blob/master/impot-societe.ts 2017 vs https://github.com/guillaume-sainthillier/eurl-sasu/blob/master/impot-societe.ts 2018).
IMO, dans l'idéal il faudrait faire varier l'IHM des paramètres en fonction de l'année choisie (ex: la flat tax dispo uniquement à partir 2018), et maintenir un fichier de calcul IS / IR / CS / documentation par année (en utilisant l'héritage de TypeScript). Ca fait un peu de duplication de code, mais les avantages seraient doubles :
- On peut comparer les résultats d'une année à l'autre pour un même CA / charge etc
- Une seule IHM à maintenir, donc si on ajoute des infos sur le détail des calculs toutes les années pourraient en bénéficier
Sinon, figer une release 2017 et l'intégrer dans un dossier de l'app de sorte à y faire un lien depuis la v2018 (est-ce vraiment nécéssaire de conserver les années < N - 1 ?).
Qu'en penses-tu ?
Je penche plus pour la seconde solution. Les évolutions des lois de finances peuvent amener des modes de calculs totalement différents, donc une structure de code différente et une IHM différente. Si on maintient toutes les années dans un seul repo (un seul logiciel) je pense qu'on va se retrouver dans un plat de spaghettis de plus en plus ingérable.
Je vois trois options :
- Figer la 2017 et la mettre dans un dossier à part, faire un dossier 2018, 2019, etc. et mettre un wrapper qui permet de basculer d'une année à l'autre via une IHM.
- Figer la 2017 via un tag Git ou dans une branche et continuer le repo actuel.
- Forker la 2017 dans un repo 2018 et repartir de là.
J'ai une préférence pour la 1.
Je pense à quelque chose d'assez bourrin : chaque année est une app isolée (et tant pis pour le DRY) qui peut être buildée et lancée séparément. Les technos peuvent même être différentes (JS, TS, Angular, React, etc.) et on cherchera juste à maintenir un semblant de cohérence graphique (Bootstrap natif et c'est tout).
Le wrapper va simplement servir à automatiser les builds sur toutes les années et offrir un IHM pour basculer de l'une à l'autre. Je suis prêt à envisager un iframe (mais avec honte :-))
Hello,
Désolé pour le retard ;-(
Je vois que tu as opté pour la solution 1, je trouve cette solution très bien également, bien qu'un mélange des solutions 1 & 2 aurait été parfait AMHA.
En attendant, je peux te proposer quelques PR pour réparer la prod sur la version 2018 et faire un premier draft du swicher d'années ;-)
Ah oui, j'ai complètement oublié le tag Git :-)
Pour le switcher, finalement je ne pense pas que ça soit nécessaire : deux onglets dans le navigateur suffisent pour comparer deux années (c'est comme ça que je fais :-)). Mais si tu te sens motivé, pourquoi pas.
Je pense qu'il faudrait quand même une micro IHM pour rediriger l'utilisateur quand il arrive sur http://antoineviau.com/eurl-sasu/
PS : Du coup pourquoi conserver dans le master la version 2017 alors qu'on peut le stocker et le mettre à jour dans une branche 2017 ? :-)
-
la version sur mon site n'est là que pour rendre service. Elle a quelques modifs locales (genre le base href, ou éventuellement un script Google Analytics). Donc j'ai bricolé un truc vite fait, et comme tu peux le voir la version 2018 n'est pas listée, alors que si tu changes 2017 dans l'URL par 2018, tu as une version 2018. Bref, ne te base pas sur mon site pour avoir une vision complète de l'appli.
-
Justement, je préfère tout garder "à plat" dans la même branche. Ce sont deux dossiers différents, a priori pas de code partagé, c'est plus clair de voir ça au premier coup d'oeil.
-
OK, j'avais juste pour objectif de minimiser l'effort d'intégration lors du déploiement de l'app sur un serveur (ou même via les github pages).
-
Pas de problèmes, je vais me rebaser sur la nouvelle structure et te re soumettre des PR pour les 2 années si tu n'as pas déjà commencé à y travailler en local.
Hello,
Je suis tombé sur cet outil : https://demo.mon-entreprise.fr/s%C3%A9curit%C3%A9-sociale
Il est vraiment complet, à jour et open source. J'ai comparé quelques simulations et les résultats sont après proches à quelques centaines d'euros :-)