Re: VAT - tax authority

[Jacopo Cappellato]

On Jul 14, 2008, at 3:08 PM, 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:




Is it ok?

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

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.

Yes, of course you can already setup equivalent item level promotions.

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.

Jacopo

There should be already everything we need: taxAuthorityRateSeqId, taxAuthGeoId, taxAuthPartyId...

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