Re: VAT - tax authority

[Jacopo Cappellato]

David,

thanks for your valuable information; please see my comments below:

On Jul 14, 2008, at 10:44 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED] > wrote:

The from and to Geo discussion is interesting from a requirements perspective, but I'm wondering if it is really the best way to look at things. I may be biased though, given that I designed the current TaxAuthority model and understand better the various world-wide requirements that went into that. The general idea with the TaxAuthority is that you model different agencies that you must pay tax to and the geographic boundary that they charge for taxes in. For pretty much the entire world all companies need to worry about is Tax Authorities that govern places where they have locations.

taxAuthPartyId |  geoId                | rate
============================
ITA_GOV           |  EUR-NO-ITA  | 20%
ITA_GOV           |  ITA                    | 20%


Does it make sense?


We could add a TaxAuthorityRateProduct.partyId field to manage them.


Jacopo

This is slightly (just slightly) different (from the information I could gather) in Europe. For example, if an Italian company/store sells something to an EU customer (non Italian) and the customer doesn't provide a taxId, then the Italian Government will charge taxes as if it was an Italian customer; on the other hand, if the EU customer provides a taxId then no taxes will be applied. But this can be easily implemented in OFBiz by setting up TaxAuthorities like the following ones: And then set the PartyTaxAuthInfo.isExempt flag to Y for all the EU non Italian customers with a valid taxId. The only feature I don't see supported by the existing data model, is the ability to specify customer specific rates. For example, there are some special customers (for example Government departments or customers belonging to special industries) that pay a different (lower) tax rates but they are not completely exempt. And this field could even be used to define the rates for taxes to be paid to suppliers by the Company (partyId=Company) if we want to use different records (rates) for tax rules for sales and purchase orders.

If a customer is in a location that charges a tax for the purchase, that is usually the customer's responsibility to manage (ie a use tax sort of thing, not a sales tax or a tax on value added).

The way this is modeled in OFBiz is that your internal organization (like the "Company" Party) is associated with TaxAuthority and on that association the isNexus flag is set to true, meaning the organization has a sufficient presence in the jurisdiction of the tax authority and needs to collect taxes on behalf of the tax authority. That is the "geoFrom" if you will. The geoId that is part of the 2-part identifier for a TaxAuthority, along with a partyId, is the Geo where taxes need to be charged if something is shipping to that area (or in some cases is billed to that area if there is no "shipping"). While I'm not familiar with all of these particular cases or the laws around them, let me take a stab at the scenarios you mentioned:

US - > US : SALES_TAX (id of tax in TaxAuthorityRateType)

Actually it's more complex than this. There is USA sales tax, just sales tax in different states. At the minute retailers only need to collect tax for states, counties, cities, and other jurisdictions where they have a nexus. That may change in the future.

US -> World : EXPORT_TAX

I don't believe that USA companies are required to collect these taxes, but I could be wrong.

Poland -> Poland : VAT (or VAT_PL)

Simple TaxAuthority setup for Poland.

Poland -> EU : VAT (or VAT_PL or VAT_PL_EU)

Are the taxes collected on behalf of Poland, or of the EU?

Either way, a separate TaxAuthority record is the way to go, with the partyId pointing to either Poland or the EU, and a geoId pointing to all of the EU except Poland.

Germany -> Germany  : VAT or something more specialized

Again, a simple TaxAuthority record for sales from and to Germany.

-David

On Mon, 14 Jul 2008 15:19:13 +0200, Jacopo Cappellato <[EMAIL PROTECTED] > wrote:

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:

* 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

Is it ok?

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.

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

Jacopo

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



Cheers,
Marek
http://www.jotel.com.pl

If that would be done I see basic sales VAT support be ready to do.

smime.p7s
Description: S/MIME cryptographic signature