2011-12-17 4 views
0

Imaginons: Il existe un site Web, une sorte de tableau d'offres d'emploi. Les produits sont virtuels là-bas. Il y a des options et des frais supplémentaires pour poster une entrée.Base de données: Stockage des taxes Tarifs et informations

Maintenant, dans notre pays, il y a la TVA, des règles vraiment compliquées. Business est situé dans PL:
- utilisateurs de PL - Taux de TVA est de 23%
- utilisateurs individuels de l'UE - taux de TVA est de 23%
- les entreprises de l'UE - NP (pas appliquer)
- entreprises/utilisateurs individuels hors UE - NP (ne s'applique pas).

Maintenant je m'interroge sur la meilleure approche avec la conception de base de données. Nous avons des tables suivantes:

countries 
code VARCHAR(3) PK AI 
NAME VARCHAR(200) NN 

users 
country VARCHAR(3) FK_countries_code 
account_type TINYINT //0 - individual, 1 - company 

Lors de l'application des règles fiscales applicables peu de choses:
- emplacement de l'utilisateur
- type de compte utilisateur.

Avez-vous des suggestions pour la conception de la base de données? Je pensais à modifier la table des pays et à appliquer une dénormalisation ici - en créant quelques colonnes: vat_rate_eu_personal, etc. mais c'est une idée terrible. Je pensais aussi à la mise en œuvre de nouvelles tables: tax_rates et tax_rates_rules lorsque les informations seront stockées. Cependant n'ont aucune idée de la structure de la deuxième table.

Modifier
Pour préciser: il n'y a pas 0% règle pour moi, il est appelé NP (non applicable). Cependant, les règles fiscales ont une exigence majeure: les entreprises de l'UE doivent fournir un numéro de TVA valide. C'est pourquoi nous avons créé deux types de compte: pour les comptes d'entreprise et les utilisateurs individuels.

+0

"il n'y a pas de règle de 0% pour moi, ça s'appelle NP (ne s'applique pas)". Ce que vous appelez * la règle n'a pas vraiment d'importance. Une règle qui ne s'applique pas est effectivement de 0% pour le calcul de la TVA.Vous ne pouvez pas stocker de pourcentages et de chaînes numériques ('NP') dans la même colonne; ce sont des types de données différents avec des contraintes différentes. –

+0

Est-ce que vous déterminez si un utilisateur se trouve à l'intérieur ou à l'extérieur de l'UE en consultant l'adresse de facturation, l'adresse de livraison ou autre chose de l'utilisateur? –

+0

@Catcall - pays de l'utilisateur basé sur les détails de l'adresse fournie - c'est pourquoi nous avons utilisé un tableau séparé pour les pays. – DaveW

Répondre

0

Il y a deux façons d'aborder cela.

  1. Stockez toutes les possibilités.
  2. Stocker uniquement les possibilités qui ont un taux de TVA> 0.

Je serais probablement stocker seulement les possibilités qui ont un taux de TVA> 0.

Mais vos règles me semblent vraiment simple, ayant seulement deux possibilités.

  1. Utilisateurs individuels provenant de l'UE: 23%. (Pologne est encore dans l'UE, droit?)
  2. tous les autres individus et de la société dans le monde: 0%

Vous pouvez facilement déterminer un pays utilisateurs et si cet utilisateur est une personne ou une entreprise. La seule chose qui vous manque, ce sont les membres de l'UE.

create table EU (
    country_code varchar(3) primary key references countries (code) 
); 

insert into EU values ('PL'); -- or whatever code you use. 
... 

et ainsi de suite. Ensuite, vous pouvez créer une vue pour consulter les taux d'imposition.

create view VAT_rates as 
select 0 account_type, country_code, .23 VAT_rate 
from eu; 
+0

J'ai édité ma question. Oui tu as raison. Nous avons deux taux d'imposition dans ce cas, mais je pense à stocker des règles spécifiques dans la base de données, c'est la clé :) – DaveW

Questions connexes