Bonjour à tous,

J'ai besoin de gérer la TVA dans un de mes projets, et je me pose la question du changement de taux.

Comment gérez-vous le changements et l'enregistrement de la TVA pour une ligne.

Pour l'instant, voici le schéma que je compte mettre en place, tous retour d'expérience sera le bienvenue

Une table TVA (id, label), une table PERIODE (id, date_debut, date_fin) et enfin une table TVA_has_PERIODE (tva_id, periode_id, taux), ce qui me permettra de gérer tous les changements de TVA historique.

Le but étant, de gérer des postes de dépenses (à partir d'un référentiel dans lequel je définirais la TVA) dans des notes de frais (qui seront historiées), que je puisse ressortir les bons taux pour les postes de dépenses des notes passées, en fournissant le bon taux en fonction de la période bon moment (si je défini que ma TVA générique est de 25% à partir du 1 janvier 2016, il faut que le poste de dépense dont la date est le 5 Janvier utilise ce taux).

Je me demande s'il ne vaudrait mieux pas enregistrer la TVA dans le poste de dépense de la note de frais, cela m'éviterait moult jointure et donnerait surement de meilleure performance SQL.

Qu'en pensez-vous?



Vous remerciant par avance de votre aide.

Pourquoi plusieurs tables? je suis un grand fan du cécoupage objet pour la modélisation de base mais pour le coup je ne suis pas sur de l'interêt de plusieurs table, d'une part parce que le nombre d'enregistrements ne sera jamais important, d'autre part chaque changement de taux est fonction d'une période et est un enregistrement à part. Enfin le différentiateur des taux de TVA est fonction de la nature du produit vendu ce qui n'est pas représenté dans tes tables.

Donc je pense que tout merger au sein d'une même table serait non seulement plus logique, plus performant, mais aussi plus exploitable.

Pourquoi plusieurs tables? je suis un grand fan du cécoupage objet pour la modélisation de base mais pour le coup je ne suis pas sur de l'interêt de plusieurs table, d'une part parce que le nombre d'enregistrements ne sera jamais important, d'autre part chaque changement de taux est fonction d'une période et est un enregistrement à part. Enfin le différentiateur des taux de TVA est fonction de la nature du produit vendu ce qui n'est pas représenté dans tes tables.

Donc je pense que tout merger au sein d'une même table serait non seulement plus logique, plus performant, mais aussi plus exploitable.

Donc en gros, la TVA définie à un instant T pour un poste de dépense doit être copier dans la table dépense ? ainsi si la TVA change le mois suivant, la tva définie pour le poste de dépense ne change pas, c'est bien ça ?

Ce qui donne:

Table TVA (id, label, taux), table DEPENSE (id, label, tva, etc...) -- ou la tva est le taux de la table TVA --

La table dépense doit avoir une clef étrangère qui est un id de la table TVA, et idéalement contient le prix HT, en cas de changement du taux de la TVA on ajoute une entrée dans la table TVA avec le nouveau taux et on refère à la nouvelle TVA, du coup tu gardes tes dépenses précendentes avec la TVA de l'époque et tu as les nouvelles dépenses avec la TVA correcte.

Donc en fait la réponse est oui

La table dépense doit avoir une clef étrangère qui est un id de la table TVA, et idéalement contient le prix HT, en cas de changement du taux de la TVA on ajoute une entrée dans la table TVA avec le nouveau taux et on refère à la nouvelle TVA, du coup tu gardes tes dépenses précendentes avec la TVA de l'époque et tu as les nouvelles dépenses avec la TVA correcte.

Donc en fait la réponse est oui

On est d'accord. Merci pour ce retour d'expérience Nagol.

Par expérience, j'ai toujours stocké les prix calculé, quitte à péter une forme normale.
Dans la compta française, il faut savoir toujours afficher le même montant, quelque soit la BDD, le serveur, la version de PHP utilisée.

Pour ma part, dans l'application sur laquelle je travaille depuis pas mal de temps, j'ai défini une table pour stocker les taux de TVA avec un id auto-incrémenté, un taux, une date de début de validité et une date de fin de validité.

Selon le type de donnée affectée par un taux de TVA et la table dans laquelle elle est stockée, cette table va avoir un tva_id en clé étrangère et il n'y a aucun casse-tête puisque quelle que soit la date à laquelle j'édite les informations sur une donnée quelconque, j'aurai le taux qui lui a été appliqué à ce moment là. Quant aux dates de début et de fin de validité, elle sont utiles au moment d'enregistrer de nouvelles données pour appliquer un taux à tout le moins existant à ce moment là.

My 2¢