Je suis curieux de savoir quelle est la meilleure pratique. Par exemple, nous avons une entité de produit, il a deux champs: prix et TVA. Que sauvegarder la valeur de prix? Prix de base, puis calculez le prix de résultat basé sur le prix de base et le code de TVA. Ou enregistrer le prix calculé et enregistrer la TVA juste à des fins d'information.
7 Réponses :
Sans TVA, puisqu'il peut changer de manière indépendante des prix.
Comment alors faire des prix comme 4.99?
@MIKE Si la TVA change, les entreprises ré-calculeront des prix de toute façon pour avoir des prix «jolis».
Je ne suis pas sûr de suivre? Vous voulez dire comment stocker le 4.99 dans la base de données?
Le problème que je vois, nous avons calculé le prix 4.99. Imprimé par exemple sur de grandes planches. Puis un jour, la TVA a changé. Je n'ai probablement pas envie d'avoir l'idée d'avoir tous les prix changés automatiquement.
Non, il veut dire comment une entreprise calculille-t-elle "joli" prix de 4,99, si la DB stocke EX-TVA. Facile, @Mike, ce que vous stockez dans la DB et ce qu'ils fonctionnent avec le système d'envoi avant, ne doivent pas nécessairement être la même chose. J'ai fait des systèmes qui permettent à l'utilisateur de manipuler le prix (Inc-TVA ou Ex-TVA) et nous calculons automatiquement l'autre pour eux. Ensuite, nous stockons Ex-TVA dans la DB. (Modifier: Oh, le problème Mikes est différent, peu importe)
Et aussi ANAX a raison, mieux de classer les produits, puis de stocker des tarifs de TVA une fois par catégorie dans une table séparée. Il n'y a que 4 catégories (si je me souviens bien), donc ce n'est pas difficile.
Depuis que la TVA peut changer, je recommande de stocker le prix de base et le pourcentage de TVA au moment de la vente. Ensuite, vous pouvez afficher le prix calculé et le pourcentage de TVA en fonction de ce que vous devez faire rapport.
Bien que ce soit une violation 3NF pour stocker le prix de base, la TVA et le prix total, il est généralement plus simple de se désolorer et de conserver les trois données. Vous seulement besoin deux des trois et peut toujours dériver le troisième. Mais c'est souvent un groupe de multiplications gaspillées car la vente est un fait historique et ne peut pas être facilement changé.
@ S.Lott: Cela me donne un sentiment sale de le dire, mais vous faites un argument assez convaincant que la dénormalisation est appropriée dans ce cas.
@meador: C'est l'approche de l'entreposage de données: 3NF Seul s'applique si les éléments de données peuvent être mis à jour. Les faits historiques (comme les recettes de vente) ne peuvent jamais être mis à jour. Un autre reçu peut inverser la transaction, mais que la réception existe pour toujours.
TVA au Royaume-Uni a varié plusieurs fois au cours de la dernière année environ. Je garderais le prix de base séparé de la TVA variable.
Naah, cela fait 17,5% pour au moins une décennie. Votre point de base reste toujours cependant.
Non, cela n'a pas, c'était 15% pendant un moment assez récemment
@Pekka - Djna et Rob sont à la fois juste. C'était 17,5% depuis plusieurs années, puis il y a environ un an et demi, il a été réduit à 15%. Maintenant, son dos à 17,5% et on dirait que cela allait jusqu'à 20%.
Les prix des produits sont mieux sauvegardés sans TVA, comme le fait que le taux de TVA déjà mentionné peut changer de prix indépendamment des prix, de nombreuses bases de données que je travaille ont le (s) taux de TVA stocké (s) de TVA (s) dans une table séparée, le prix + la TVA est ensuite calculé en cueillette. un taux de TVA de la table de TVA.
Les modifications sont plus faciles à mettre en œuvre de cette manière aussi, telles que si le taux de TVA est passé de 17,5% à 20%, il vous suffit de changer une ligne pour que tous vos prix soient mis à jour en conséquence, plutôt que de modifier tous les prix individuels.
Si vous stockez Price + TVA, l'intégrité de votre base de données peut être comprise si vous mettez à jour la TVA et oubliez de mettre à jour le prix + TVA. Cela ne se produira pas si vous stockez le prix brut. En bref, il vaut mieux ne pas stocker des valeurs pouvant être obtenues par un calcul sur les colonnes d'une rangée.
Sauf si vous stockez des données historiques, par exemple des données qui ont été lues à partir d'un système EPOS. Il n'y a rien à gagné en calculant le prix net ou brut au moment de l'exécution lorsqu'il peut être stocké. De plus, le taux de TVA appliqué à une vente est immuable une fois la vente effectuée.
de côté : le taux standard de la TVA au Royaume-Uni devrait changer au début de janvier 2011 de 17,5% à 20%, toute solution devrait gérer ce type de changement. La solution que j'ai utilisée précédemment est d'avoir ce qui suit:
produit :
netprice (argent, non null)
VATHATEID (INT, NOT NULL, FK -> Vatrate.Vatrateid)
VATRATATE
VATHATEID (INT, PK NON NULL)
Description (texte non null)
VATRATATEVALUE
VATHVALUEID (INT, PK Pas null)
Vatre (argent pas null)
Effectiveodate (DateTime Nullable)De cette façon, je peux stocker que produit X a un prix net de 1,00, avec un taux de TVA de {1, TVA tarifaire standard}, qui appliquera les tarifs suivants {17,5% jusqu'en 2010 / 12/31, 20% par la suite}
La seule chose que cette solution ne s'adresse pas à ce que vous changez le prix du produit pour vous assurer que, quel que soit le taux de TVA actuel, le prix restant toujours à un certain «point de prix» tel que 4.99. Ce que vous pourriez faire ici, pour la flexibilité maximale (avec une complexité accrue), déplacez le champ NetPrice à partir du produit (code> d'entité sur un
productrice entité:productprice
Produitpriceid (int, pk non null)
Productible (int, pas null, fk -> produit.productid)
Prix (argent, non null)
Effectiveodate (DateTime Nullable)
Dans les situations où il y a trois valeurs à stocker dans une base de données, telle que la connaissance de deux peut calculer le troisième, je préfère parfois stocker les trois valeurs avec un indicateur dont deux sont "réels" et lequel est calculé. Les trois valeurs doivent toujours être égales; S'ils ne sont pas, il faut examiner ce qui se passe et savoir pourquoi.
Par exemple, il peut être utile de stocker des horodatages comme fuseau horaire, UTC et heure locale, ainsi qu'un indicateur "Qu'est-ce que l'on sait". Par exemple, si certains timbres de temps ont été constatés à être enregistrés à l'aide du mauvais fuseau horaire, le «ce qui est connu» peut être utilisé pour déterminer si l'UTC ou l'heure locale doit être ajustée.
En ce qui concerne les informations prospectives plutôt que historiques, je penserais qu'il pourrait être utile de stocker le prix exclusif de la TVA, la TVA attendue et le prix de la TVA, ainsi qu'un drapeau de mode indiquant divers scénarios, tels que
Fondamentalement, déterminez ce qui devrait arriver si la TVA change et ajuste les choses en conséquence.
Quelles sont vos exigences - pour stocker le prix actuel que vous souhaitez facturer et la valeur de la TVA à lister sur une facture, ou de suivre les prix au fil du temps, ou autre chose?