Re: VAT - tax authority

[Jacopo Cappellato]

Hi Marek,







Is it ok?



Jacopo


On Jul 14, 2008, at 11:35 AM, Marek Mosiewicz wrote:

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. About "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.

Hello Jacopo

Hi Marek,
and thank you for your comments.

Trying to translate your mail into a list of requirements:

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). 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

smime.p7s
Description: S/MIME cryptographic signature