Hello Jacopo
Hi Marek,
and thank you for your comments.
However, I'd suggest that, before we focus on the data model
definitions and changes, we focus on the definition of requirements
from an higher level perspective.
In this way we will focus on the definition of our goals (aha
requirements) instead on the means to accomplish them (this will be
done once the requirements are in place).
Trying to translate your mail into a list of requirements:
1) add the ability to specify a custom service (formula) for the
computation of taxes (for greater flexibility)
2) distinguish between tax rules/rates applicable to sales and
purchase orders
That it's what I mean. But also it is important to distinguish tax
based on source geo. This is where my problem begins -
there is now no ability to find what tax applys for given region
without knowing productStore.
About the "WHERE to WHERE" thing: could you please explain how it will
be used? I am not sure to understand what you mean.
I mean table where we can find geos definitions of tax type.
US - > US : SALES_TAX (id of tax in TaxAuthorityRateType)
US -> World : EXPORT_TAX
Poland -> Poland : VAT (or VAT_PL)
Poland -> EU : VAT (or VAT_PL or VAT_PL_EU)
Germany -> Germany : VAT or something more specialized
In fact it can be table TaxAuthorityRateProduct,
but there must be fromGeo there. productStore
is not good to detect fromGeo for VAT (e.g. purchase).
Then in TaxAuthorityRateType would be definitions of
tax calcluation service used for given tax.
I think that this is the most basic step forward VAT.
The next step is the problem of Order and Invoice layout.
Global invoice adjustements must be calculated down
to line level becouse of possible different VAT rates
for different products (e.g. one line 22% and another line
7%)
If that would be done I see basic sales VAT support be ready to do.
Cheers,
Marek
http://www.jotel.com.pl
