- Plus d'indications/aides dans l'UI pour expliquer ce que l'on attend
- Version mobile avec la barre de droite en bas
- Ajouter l'intégralité des champs concernés
- Latence quand on clique sur une option
- Gestion des erreurs de saisie
- Navigation au clavier, gestion du focus
Est-ce le bon modèle ?
La TVA n'a normalement pas d’influence dans la comptabilité d'une
entreprise. L'entreprise est seulement collecteur pour le compte de
l’État. Néanmoins dans le cas des auto-entreprises, il existe un seuil
de franchise de TVA qui peut avoir des conséquences et qu'il est donc
pertinent de l'afficher.
Tous les éléments à traduire (via la balise <Trans> ou la fonction 't')
sont analysé statiquement. Si il manque une traduction, la PR est bloquée
Ajoute un script de traduction automatique via `yarn run i18n:ui:translate`
Met à jour CONTRIBUTING.md avec les infos sur la traduction
* Retouche des descriptions sur le simulateur AA
* 🎨 Mode light pour le simulateur AA
* Ajout de l'intégration iframe pour le simulateur AA
* Revert "Ajout de l'inscription newsletter sur les intégrations"
This reverts commit 18ef20f7eb.
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
Cette nouvelle section s'accompagne d'un bandeau qui s'affiche quand une
nouvelle version est publiée sur GitHub.
Les données sont téléchargées depuis l'API GitHub en GraphQL au moment
du build du site puis persistées dans un fichier Json statique.
La mises à jour de valeurs précises calculées dans les tests unitaires
n'est pas une solution satisfaisante. Je le fait dans ce commit mais à
terme je pense qu'il faudra déléguer intégralité de ces tests sur des
valeurs précises aux tests de régressions `yarn run test-regressions`
qui peuvent être mis à jour facilement et conserver les tests unitaires
pour des cas où la valeur précise calculée n'importe pas.
J'ai essayé de supprimer complétement la variable entreprise . effectif
(numérique) pour la remplacer par une variable seuil qui soit la "source
de vérité" utilisée dans les formules de calcul. Malheureusement il y a
quelques endroits où persistent des anciens seuil, et où la valeur
précise de l'effectif est utilisée (taxe sur les salaires par exemple,
bien que l'utilisation dans cette formule soit une approximation assez
grossière).
En attendant d'améliorer notre gestion des variables à l’échelle de
l'entreprise, l’implémentation retenue permet de simplifier la saisie
(on clique sur un seuil plutôt que de saisir une effectif précis à
l'unité près) sans cassé les formules existantes.
Ajout des paramètres strictNullChecks et strictPropertyInitialization
dans la configuration TypeScript et correction des environ 70 erreurs
de typage résultantes.
Cela permet l'inférence de type à partir des fichiers js qui ne sont pas
encore convertis en TypeScript.
Par ailleurs suppression des dernières traces de Flow.
Ajout d'options plus strictes pour dans la config tsconfig.js
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)
Johan Girod
Maxime Quandalle
Maxime Quandalle
Marcelo Cardoso