Najlepszy sposób na przechowywanie informacji o podatku obrotowym

Question

Czy przy projektowaniu systemu baz danych do zarządzania zapasami dla sprzedaży i zakupów byłby to najlepszy sposób na przechowywanie różnych podatków i innych takich kwot?

Kilka pól, które mogą być zapisane są:

• cena jednostkowa bez podatku
• Cena katalogowa tym podatku
• podatkowa za sztukę
• Razem z wyłączeniem podatku (w zaokrągleniu do 2 miejsc po przecinku)
• Razem z podatkiem (w zaokrągleniu do 2 miejsc po przecinku)
• Podatek całkowity (w zaokrągleniu do 2 miejsc po przecinku)
• procent podatku
• Fk link do% podatku (a nie przechowywać kwotę podatku)

Obecnie najbardziej rozsądnym rozwiązaniem do tej pory jest przechowywanie w dół (w przybliżeniu) pozycja, ilość całkowita bez podatku VAT (w zaokrągleniu) , a całkowity podatek (w zaokrągleniu).

Czy istnieje lepszy sposób przechowywania tych danych dla ogólnego systemu?

Biorąc pod uwagę, że system musi być solidny, co należy zrobić, jeśli istnieje wiele wartości podatkowych, które mogą wymagać oddzielenia (np. Stan i miasto)? W takim przypadku osobna tabela byłaby w porządku, ale czy uznanie za niepoprawne wartości parametru rowID i niektóre identyfikatory taxID do kolumny totalTax byłoby zbyteczne?

Dla wyjaśnienia: wyjściowa jak przechowywać dane dotyczące poszczególnych transakcji i drugiej strony; nie tyle szczegóły na temat stawek podatkowych.

Answer 1

Problem z podejściem polega na tym, że jeżeli zmiany podatkowe, VAT (podatek obrotowy) w Wielkiej Brytanii zmienił się dwukrotnie w ciągu ostatnich 12 miesięcy.

Kiedy pracowałem na stronach internetowych handlu elektronicznego, mieliśmy tabelę Tax_Rate, która zawierała różne stawki podatkowe, którymi sklep zajmowałby się np.

1. TaxFree - 0%
2. VAT - 17,5%
3. DiscountedVat - 15%
4. etc ...

a następnie swój czas pola tabeli może mieć

• ItemId
• CenaJednostkowa
• fk_TaxRate

tabela invoice_detail rząd będzie

• f k_OrderId
• fk_ItemId
• PerItemPriceCharged (nieznormalizowana)
• TaxRateCharged (nieznormalizowana)
• QuantityOrdered

tabela faktura będzie

• idZamówienia
• fk_CustomerId

Gdzie fk_dluga obcego klucza. Pamiętaj, że OrderId nie będzie unikalny w tabeli wierszy faktury.

EDYCJE: Głowa jest dziś wszędzie.

Musisz denormalizować sumę wiersza faktury i sumę podatku, ponieważ nie chcesz, aby przyszłe zmiany ceny produktu lub stawki podatkowej wpływały na faktury historyczne.