> For the taxlevel stuff you suggest:
> "
> However, these weird things could equally be accomodated by having an
extra
> tax level. Cheddar, milk, bread all level 1, Gouda, Edam, Brie level 2,
> childrens clothes level 1 OSH KOSH level 2, Nike, Hugo Boss mensware,
level
> 2. Level 2 tax rates would be 0% in many TaxAuthorities as well as Level 1
> in Australia though level 2 is taxable at 10%.
> "
>
> But I see this as a workaround and when things get complicated with lots
of taxathaurisations with lots of artificial created level to get the stuff
done then are the web-erp users stuck in a very big confusing
administration.
> A structural stable solution is to keep a separate table (looks like your
other suggestion) with two columns:
> stockid
> taxauthlevelid
Since the solution doesn't work with inventory locations invoicing in
different tax authorities most installations will only have 1 or 2 tax
authorities. In my industry, plumbing wholesale, all products are taxable at
10% in Australia - there is no need at all for this TaxLevel stuff. In the
UK only where a businesses product range spans food/healthcare/childrens
clothes and other taxable stuff would several tax levels be necessary - if
there is only local market, no export only one tax authority would be
required. If export is required at 0% then another tax authority solves this
nicely.
In Holland it sounds as though there may be a couple of TaxLevels and
possible 2 TaxAuthorities - 1 to deal with the approved customer paying the
VAT the other for normal supplies. Both tax levels would be 0% for the
Customer pay VAT Tax Authority. Potentially a 3rd tax authority for exports
although the Customer Pays VAT would probably cover that too.
The whole purpose of these tax levels is to allow different rates for
different products. I think we have a very flexible and adaptable solution
here.
>
> For this solution you should understand that in this case you have a very
storage saving technical primary key taxauthlevelid column compared to the
two columns primary key
> taxauthorizationid + level in the taxauthlevel table.
We need an index on both these fields to ensure we only have unique
TaxLevel/TaxAuthority s in any event. In fact we are actually saving space
by not having an additional and redundant index and field even in a large
table this would be the right answer - not that it really matters for a 30
row table !!
Must be keeping you up over there - must be time you were asleep!!
Phil
|
