Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Can data be 'over-normalized'?
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00468334
Message ID:
00469830
Vues:
35
>>No the tax code is only in the taxcode table. Points to the customer (has a tax code key) points to a tax rate (ergo reads) in the tax table. Some rates, like late penalties, or price breaks would be in the customer table since they may be customer specific. List link as much as possible.
>
>Terry,
>
>So how does the customer table "point" to the tax code table? Probably using the TaxCode Attribute Right? And the Invoice table also uses the TaxCode Attribute to "point to" the tax code table. Are these two TaxCode attribute (the one in the customer and invoice tables) redundant? Example;

TaxCode Table
Code  Description    Rate
TXA   State Tax       .05 
TXB   Exise Tax      .065
TXC   NonProfiy      .00
Customer Table
CusKey  Name           TaxCode
CUSA    Ms. A            TXA         
CUSB    Mr B Inc.        TXB
CUSC    Mr C              TXC
There is a small issue. Rates change. If the sale was prior to the rate change date, and user required the functionality to void a sale, receipt, or even the tax amount, How would those parts of the transaction be cleared or backed out. If the invoice or invoice lines are the sales records against which receipts are made or voided, and the amount, but not the rate, is maintained in the sales record, then the adjustments routines would have to be more elegant. Also, in the grocery store, some line items are taxable, some are not.

Our discussion has been about maintaining tax rates in the customer header. But it may not be inappropriate or a violation of 'normalization', to associate the tax rate with the invoice or line items. The alternative would be to maintain date pointers in the tax code table. This implies some sort of date-range check be serviced when looking up a rate. Example: Is this sale date TXA code between this or that date? That would work. But the minimalist inside me cringes <g>. If the rates were maintained (stored) in the sales line items, the void or 'back out' routines could be fairly automated, because they are only dependent on what the sales item carries.

Inventory Table
Item#  Decscription    Amount
ITA     Widget A            45.99
Sales Line Items
Cust     Item   QtySold   UnitPrice  Total Price    TaxCode TaxRate   TaxAmnt      Total
CUSA   ITA               2        45.99         91.98     TXA               .05         4.60      96.58
>
>
>TaxCode Table
>
>Fields
>TaxCode PK
>Tax Rate
>Effectivedate
>
>Customer Table
>CustID PK
>...
>TaxCode FK to Taxcode (A)
>
>Invoice Table
>InvNo  PK
>TaxCode FK to Taxcode Table (B)
>
>
>
>Now are the two fields marked A and B redundant?
Imagination is more important than knowledge
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform