and thanks for the further details; maybe for now we could phrase out
the "WHERE to WHERE" requirement in the following way:
* add the ability to specify the tax rules associated to a given
(internal) organization
The above could be done using the geoId of the "bill from address" (as
you are suggesting) or directly specifying the partyId of the internal
organization for which we are defining the tax rule.
Is it ok?
Yes it is ok :)
bout "global order/invoice adjustments": is it true that if you use
promotions applicable to the order total then you'll end up with a global
adjustments; however most of the adjustments (including tax adjustments)
can and are already calculated/stored for each item.
I think that promotions applicable to order total can be applied to
per line basis to.
Discount 10% on invoice total can be applied to each line.
Same on $20 discount which can be calculated as % of invoice total.
There is one more problem which escaped me (there will be more for sure)
Is orderAdjustment good place to hold VAT tax ? There is need to reference
tax rate so it must be new column there . The same thing applies to invoice.
Maybe adding new column is ok. Or maybe it would be better to make separate
table for it.
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
