1er point problématique : Les taux de TVA ventes / achats sont communs. Si on décide d’activer le taux à 5.5% pour un achat, on se retrouve à l’activer pour les ventes alors que 80% des sociétés ne vendent qu’à 20%…
2ème point problématique : Pour automatiser la génération des déclarations de TVA, de plus en plus de logiciels utilisent les codes lors d’un import, hors celui ci est commun dans Dolibarr pour les achats, les ventes, les immobilisations, etc… Ce qui pose problème
Rien qu’en se basant sur ces 2 points, une évolution est nécessaire à mon sens pour le futur de Dolibarr.
J’ai donc 2 solutions :
1ère solution :
Un taux de TVA = 2 colonnes codes (pour achats & ventes)
Un taux de TVA = 2 bouton d’état pour différencier la disponibilité sur le cycle achat et le cycle vente
2ème solution :
On double les taux de TVA et on rajoute un type de taux de TVA pour bien tout séparer. Ex : Achats, Ventes, Immobilisations, etc…
Votre avis ? Merci d’avance
En piochant dans le logiciel comptable Oxygène (utilise la 2ème solution) :
Hello
Mon analyse de la chose :
1 - Sortir la TVA de la gestion par dictionnaire qui est une M… infame, on garde la logique d’avoir un taux de TVA actif ou non
2 - Ajouter une table liée à la table des TVA avec une ligne pour la vente, l’achat, l’immo, … que l’on active ou non
je précise la structure de la nouvelle table :
Merci Charlène. A vrai dire, je ne cherche pas à critiquer le système de dictionnaire qui a mon sens suffit pour gérer les taux actuellement. Juste quelques évolutions mais cela va vite devenir une usine à gaz si on ne réfléchi pas en amont. Et peu importe la solution, il est nécessaire de prévoir une migration ce qui est plus compliqué.
Merci Stéphane, c’est à mon sens la meilleure mais comme précisé au-dessus, j’ai une problématique de migration des anciens Dolibarr qui n’est pas simple. Il faut lors du script de migration donner un type « Ventes » aux taux actuels et copier les taux pour leur donner un type « Achats » pour ne pas perdre du monde en chemin. Au moins, on a de la chance que ce ne soit pas le code de TVA qui soit relié au table mais le taux tout simplement donc pour la compatibilité, on est pas trop mal je crois.
Je vais attendre d’autres avis, je voudrais faire évoluer ce point, tu le sais.
Peut-être pour lever cette difficulté de migration prévoir une option pour activer une « TVA avancée » avec un mini-tuto pour guider dans la migration et les opération manuelles qui ne pourraient être automatisée
Bonjour, je suis également pour la solution 2, plus évolutive… Et effectivement réfléchir à la préconisation de @defrance pour une table dédiée, ça me paraît aller avec la juste proposition de @pscoffoni .
Je préconise la solution 2.
Pour la nouvelle colonne type de taux, il faut 3 valeurs possibles. La valeur par défaut « all » qui signifie « Vente et achat ». On définie la nouvelle colonne avec cette valeur. Il y aurait aussi possibilité de mettre la valeur « sell » ou la valeur « purchase ».
On modifie ensuite la fonction qui donne la liste des taux pour accepter le paramètre sell ou puchase.
Si sell, cela renvoi les taux avec le type « all » + « sell », si purchase on renvoi le type « all » + « purchase ».
Ainsi on est compatible avec l’existant et pour les nouveau on pourra mettre des lignes doublées une pour sell une pour purchase.
Bon, je crois que la solution 2 consistant a donner un type à un taux de TVA et à différencier achats, ventes, etc remporte l’unanimité. C’est celle que je désirai, merci pour vos retours constructifs.
@altatof@defrance Nous avons déjà une table llx_c_tva. Après qu’elle soit gérée via un dictionnaire ou un système de fiche, je vous laisse en débattre, adapter, ajouter. En tout cas le mode dictionnaire me suffit pour le moment pour ce que je veux faire évoluer pour des futures besoins comptables.
Merci @pscoffoni pour le proposition de migration vers le nouveau modèle, je crois que @eldy (Merci de ton retour précieux) a trouvé la meilleure solution avec le type ‹ all ›, comme ça on peut récupérer des Dolibarr anciens sans pour autant casser les anciennes données et préparer une transition vers le nouveau système en douceur.
Ainsi après en lien avec le module Immobilisations, création d’un type immobilisation puis ajout du multi-entité sur cette table car l’autre problème sous jacent et quand on a du multi-entité avec plusieurs pays/taux et qu’on active un taux et que tout le monde en dispose à l’affichage alors que c’est pour l’entité d’à côté… Ce dernier point est en place chez un client, c’est fonctionnel, je dois juste appeler @regis pour prévoir que lors de la création d’une nouvelle entité, il déploie des datas de base pour les taux de TVA.
Encore merci à tous pour cet échange constructif, je posterai les PR dans ce fil pour continuer d’échanger.
Bonjour @aspangaro-Inovea , est ce que le type de taux ne serait pas la même chose que le type de transaction dont nous parlions l’an dernier ? Auquel cas il faudrait qu’il puisse être étendu au delà des 3 valeurs préconisées par @eldy , il me semble.
Inconsciemment, oui cela pourrait se rapprocher du même type de problématique.
Si tu rajoutes un type ‹ location › dans les types de TVA, cela pourrait permettre d’identifier indirectement une ligne avec un type de transaction particulier pour peu que tu assignes à la ligne de la facture le taux de TVA ayant un type particulier.
Dans le PR que j’ai commencé d’après les préconisations de Laurent, c’est du fixe de chez fixe…
Smallint 0: all / 1:sell / 2:buy
Mais rien n’empêche de rajouter un Hook pour rajouter un type de TVA, j’ai prévu un array pour la liste des types
Je publierai le premier PR ce week end pour commencer à discuter, il n’est pas 100% fonctionnel pour le moment.
Des réglages à ajuster probablement et il reste les nouvelles datas à gérer à savoir créer pour les nouvelles installations le nécessaire. TVA sur les ventes et TVA sur les achats par exemple.
Une question reste en suspens : Faut-il autoriser les doubles taux de TVA ? Actuellement, deux taux à 20% ne peuvent pas exister sur le même pays à moins d’avoir 2 codes différents.
J’utilise des taux de TVA identiques avec des codes différents, pas de problème.
Je ne suis pas sûr de bien comprendre ta question. Tu veux dire que tu envisage la possibilité de créer des taux identiques avec codes identiques ? Duplication ? Quel est l’intérêt ?
Actuellement, tu ne peux pas créer 2 taux identiques avec le même code.La question était de savoir si on fait évoluer ce point. Moi ça ne me dérange pas de laisser en état car cela va être galère à gérer et si tu as un champ de type « Tous » et « Ventes » avec le même taux sans distinction.
Donc du coup ma proposition d’intégration n’est pas mal, il va falloir la tester / retester mais ce sera pour la v18, la beta de la v17 venant de s’ouvrir.
Pour moi, cela n’a pas d’intérêt. Si je crée un nouveau taux, c’est pour en avoir l’analyse par le code. Mais je n’ai peut-être compris toutes les subtilités.
Et peut-être que d’autres en ont l’utilité. À voir !
Maintenant que je sais mettre un émoji à un PR, je vais aller le faire de suite.
