VAT - tax authority

[Marek Mosiewicz-2]

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

[Jacopo Cappellato-3]

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

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%)
>>>
>>> If that would be done I see basic sales VAT support be ready to do.
>>>
>>> Cheers,
>>>  Marek
>>>  http://www.jotel.com.pl
>>>
>>
>

[David E Jones]

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. 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 <[hidden email]> 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
>>> 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.
>>
>
> 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%)
>>>>
>>>> If that would be done I see basic sales VAT support be ready to do.
>>>>
>>>> Cheers,
>>>>  Marek
>>>>  http://www.jotel.com.pl
>>>>
>>>
>>
>
>
>

[Jacopo Cappellato-3]

David,

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

On Jul 14, 2008, at 10:44 PM, <[hidden email]> <[hidden email]
 > 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.

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:
taxAuthPartyId |  geoId                | rate
============================
ITA_GOV           |  EUR-NO-ITA  | 20%
ITA_GOV           |  ITA                    | 20%

And then set the PartyTaxAuthInfo.isExempt flag to Y for all the EU  
non Italian customers with a valid taxId.
Does it make sense?

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.
We could add a TaxAuthorityRateProduct.partyId field to manage them.
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.

Jacopo

> 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 <[hidden email]
> > 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
>>>> 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.
>>>
>>
>> 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%)
>>>>>
>>>>> If that would be done I see basic sales VAT support be ready to  
>>>>> do.
>>>>>
>>>>> Cheers,
>>>>> Marek
>>>>> http://www.jotel.com.pl
>>>>>
>>>>
>>>
>>
>>
>>
>

[Rashko Rejmer]

Hi Jacopo,

I also noticed that the system can not handle situation when different
rates apply to some customers.

This is also the case in Colombia where tax rate depends on the
combination of buyer and seller social activities. For example if a "big
contributor" sells to a "government organization" the rate of the tax is
different from the rate that applies when "big contributor" sells to
another "big contributor".

I have solved this requirement by party classifications and small DB
extension. I added the table:
TaxAuthRateProductAppl
- taxAuthorityRateSeqId
- fromPartyClassifGroupId
- toPartyClassifGroupId
For every specific rate I add new TaxAuthorityRateProduct record and
also TaxAuthRateProductAppl records that define for what combination of
party classification is applicable current TaxAuthorityRateProduct
record(rate).

If this makes sense and is a good approach I can contribute this
enhancement to the project.

Regards,
Rashko Rejmer

On Tue, 2008-07-15 at 15:11 +0200, Jacopo Cappellato wrote:

>
> 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.
> We could add a TaxAuthorityRateProduct.partyId field to manage them.
> 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.
>
> Jacopo

[Jacques Le Roux]

From: "Rashko Rejmer" <[hidden email]>

> Hi Jacopo,
>
> I also noticed that the system can not handle situation when different
> rates apply to some customers.
>
> This is also the case in Colombia where tax rate depends on the
> combination of buyer and seller social activities. For example if a "big
> contributor" sells to a "government organization" the rate of the tax is
> different from the rate that applies when "big contributor" sells to
> another "big contributor".
>
> I have solved this requirement by party classifications and small DB
> extension. I added the table:
> TaxAuthRateProductAppl
> - taxAuthorityRateSeqId
> - fromPartyClassifGroupId
> - toPartyClassifGroupId
> For every specific rate I add new TaxAuthorityRateProduct record and
> also TaxAuthRateProductAppl records that define for what combination of
> party classification is applicable current TaxAuthorityRateProduct
> record(rate).
>
> If this makes sense and is a good approach I can contribute this
> enhancement to the project.

This looks like a generalisation of the case Jacopo explained and proposed a solution for (TaxAuthorityRateProduct.partyId field).
It sounds good to me? Though both could be used as Jacopo's solution is easier to use.

Jacques

> Regards,
> Rashko Rejmer
>
> On Tue, 2008-07-15 at 15:11 +0200, Jacopo Cappellato wrote:
>>
>> 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.
>> We could add a TaxAuthorityRateProduct.partyId field to manage them.
>> 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.
>>
>> Jacopo
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Rashko Rejmer" <[hidden email]>
>> Hi Jacopo,
>>
>> I also noticed that the system can not handle situation when different
>> rates apply to some customers.
>>
>> This is also the case in Colombia where tax rate depends on the
>> combination of buyer and seller social activities. For example if a "big
>> contributor" sells to a "government organization" the rate of the tax is
>> different from the rate that applies when "big contributor" sells to
>> another "big contributor".
>>
>> I have solved this requirement by party classifications and small DB
>> extension. I added the table:
>> TaxAuthRateProductAppl
>> - taxAuthorityRateSeqId
>> - fromPartyClassifGroupId
>> - toPartyClassifGroupId
>> For every specific rate I add new TaxAuthorityRateProduct record and
>> also TaxAuthRateProductAppl records that define for what combination of
>> party classification is applicable current TaxAuthorityRateProduct
>> record(rate).
>>
>> If this makes sense and is a good approach I can contribute this
>> enhancement to the project.
>
> This looks like a generalisation of the case Jacopo explained and proposed a solution for (TaxAuthorityRateProduct.partyId field).
> It sounds good to me? Though both could be used as Jacopo's solution is easier to use.

Sorry, the question mark above is a typo should be a dot

Jacques

> Jacques
>
>> Regards,
>> Rashko Rejmer
>>
>> On Tue, 2008-07-15 at 15:11 +0200, Jacopo Cappellato wrote:
>>>
>>> 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.
>>> We could add a TaxAuthorityRateProduct.partyId field to manage them.
>>> 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.
>>>
>>> Jacopo
>>
>

[David E Jones]

On Jul 15, 2008, at 7:11 AM, Jacopo Cappellato wrote:

> David,
>
> thanks for your valuable information; please see my comments below:
>
> On Jul 14, 2008, at 10:44 PM, <[hidden email]> <[hidden email]
> > 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.
>
> 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:
> taxAuthPartyId |  geoId                | rate
> ============================
> ITA_GOV           |  EUR-NO-ITA  | 20%
> ITA_GOV           |  ITA                    | 20%
>
> And then set the PartyTaxAuthInfo.isExempt flag to Y for all the EU  
> non Italian customers with a valid taxId.
> Does it make sense?

Yes, that makes good sense.

> 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.
> We could add a TaxAuthorityRateProduct.partyId field to manage them.
> 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.

Let me bounce this back and see how the model might fit.

There are organizations, or possibly individuals, that in different  
groups and those groups qualify for lower rates either in general or  
for certain products.

With this and the partyId on the TaxAuthorityRateProduct I guess we  
would look for any of the tax rate party groups (perhaps by them being  
associated with the TaxAuthority directly) that the current Party is  
associated with, and if so look for TaxAuthorityRateProduct records  
for that group partyId, and if none are found look for  
TaxAuthorityRateProduct where the partyId is null.

Is that kind of what you had in mind? I'm wondering if it might be  
easier to add something to the PartyTaxAuthInfo entity for this, but  
maybe not... in fact forget it I guess because the important  
association is between the customer Party and the tax rate PartyGroup,  
and then from the tax rate PartyGroup to the TaxAuthorityRateProduct  
record.

-David

[Jacopo Cappellato-3]

On Jul 18, 2008, at 8:53 AM, David E Jones wrote:

>
> On Jul 15, 2008, at 7:11 AM, Jacopo Cappellato wrote:
>
>> David,
>>
>> thanks for your valuable information; please see my comments below:
>>
>> On Jul 14, 2008, at 10:44 PM, <[hidden email]> <[hidden email]
>> > 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.
>>
>> 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:
>> taxAuthPartyId |  geoId                | rate
>> ============================
>> ITA_GOV           |  EUR-NO-ITA  | 20%
>> ITA_GOV           |  ITA                    | 20%
>>
>> And then set the PartyTaxAuthInfo.isExempt flag to Y for all the EU  
>> non Italian customers with a valid taxId.
>> Does it make sense?
>
> Yes, that makes good sense.
>
>> 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.
>> We could add a TaxAuthorityRateProduct.partyId field to manage them.
>> 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.
>
> Let me bounce this back and see how the model might fit.
>
> There are organizations, or possibly individuals, that in different  
> groups and those groups qualify for lower rates either in general or  
> for certain products.
>
> With this and the partyId on the TaxAuthorityRateProduct I guess we  
> would look for any of the tax rate party groups (perhaps by them  
> being associated with the TaxAuthority directly) that the current  
> Party is associated with, and if so look for TaxAuthorityRateProduct  
> records for that group partyId, and if none are found look for  
> TaxAuthorityRateProduct where the partyId is null.
>
> Is that kind of what you had in mind? I'm wondering if it might be  
> easier to add something to the PartyTaxAuthInfo entity for this, but  
> maybe not... in fact forget it I guess because the important  
> association is between the customer Party and the tax rate  
> PartyGroup, and then from the tax rate PartyGroup to the  
> TaxAuthorityRateProduct record.
>

Let me see if I am interpreting your comments in the right way:

PartyGroup: "Government Agencies" - this is the group that contains  
all the customers that are Government Agencies
PartyGroup: "Government Agency XYZ" - this is a customer
PartyRelationship: "Government Agency XYZ" is a company that belongs  
to the "Government Agencies" group (is this the right way to model  
this structure?)
TaxAuthority: ITA_GOV / ITA
TaxAuthorityRateProduct: generic record with 20% rate for partyId =  
null (all parties)
TaxAuthorityRateProduct: specific record with 15% rate for party =  
"Government Agencies"

When computing taxes the system will:

1) retrieve all the tax groups for the customer "Government Agency  
XYZ" (should we identify tax group relationship by a special assoc  
type?)
2) retrieve the bill to address for "Government Agency XYZ" and select  
all the TaxAuthorities relevant for that GEO
3) for each TaxAuthority found, search for TaxAuthorityRateProduct  
with productId equals to one of the groups at #1
4) if none is found, then use the standard TaxAuthorityRateProduct  
with partyId = null

Does this make sense?

Jacopo


> -David
>
>
>

[RolandH-2]

Hi Marek, hi all,

what's your point of view to that:
http://www.nabble.com/GST-VAT-on-invoiced-time-entries-tt18498937.html

If everyone only would selling goods through orders, nobody has a problem.
But from a more general point of view, I think tax should be calculated
independendly of the 'document type' used, in germany we have to include the
tax calculations in every type i can think of:
orders, invoices, quotes, credit note
(on invoices and credit notes for tax auth. tasks; on orders and quotes for
showing gros prices to customers)

Is this of interest to others here, or do you mainly sell goods through
orders?

--Roland

On Monday 14 July 2008 11:35, Marek Mosiewicz wrote:

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

[Marek Mosiewicz-2]

Hi all

I think there is no problem to calculate tax for any tape of document.

By the way I found that 0% VAT is only applicable to goods (and BP has valid
VAT ID)

Most services are taxed with appropriate VAT rate and are not deductible on
purchase
if customer does not have branch in same country as seller. Little
nightmare.

Please check if it is same in different countries in EU.


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

----- Original Message -----
From: "Roland" <[hidden email]>
To: <[hidden email]>
Sent: Friday, July 18, 2008 12:00 PM
Subject: Re: VAT - tax authority

> Hi Marek, hi all,
>
> what's your point of view to that:
> http://www.nabble.com/GST-VAT-on-invoiced-time-entries-tt18498937.html
>
> If everyone only would selling goods through orders, nobody has a problem.
> But from a more general point of view, I think tax should be calculated
> independendly of the 'document type' used, in germany we have to include
> the
> tax calculations in every type i can think of:
> orders, invoices, quotes, credit note
> (on invoices and credit notes for tax auth. tasks; on orders and quotes
> for
> showing gros prices to customers)
>
> Is this of interest to others here, or do you mainly sell goods through
> orders?
>
> --Roland
>
> On Monday 14 July 2008 11:35, Marek Mosiewicz wrote:
>> 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.
>
>
>

[Jacques Le Roux]

Hi Marek, Roland,

About no taxes on invoice without passing by an order stage before : as it was already explained, the reason is obviously that most
of the companies using OFBiz so far have not been interested by directly invoicing with taxes, like for services indeed.

From: "Marek Mosiewicz" <[hidden email]>
> Hi all
>
> I think there is no problem to calculate tax for any tape of document.

What do you mean ? Not in OFBiz I guess, but at large I suppose?

> By the way I found that 0% VAT is only applicable to goods (and BP has valid VAT ID)

How, why and when 0% is used ? I thought exemption was the way in such cases.

> Most services are taxed with appropriate VAT rate and are not deductible on purchase
> if customer does not have branch in same country as seller. Little nightmare.
>
> Please check if it is same in different countries in EU.

I'm not sure to understand the meaning of this last paragraph as we have already discussed the case of companies VAT numbers in EU,
for instance, which allow to not charge any VAT (is this related to the 0% rate ?)

Jacques

>
> Marek
> http://www.jotel.com.pl
>
> ----- Original Message -----
> From: "Roland" <[hidden email]>
> To: <[hidden email]>
> Sent: Friday, July 18, 2008 12:00 PM
> Subject: Re: VAT - tax authority
>
>
>> Hi Marek, hi all,
>>
>> what's your point of view to that:
>> http://www.nabble.com/GST-VAT-on-invoiced-time-entries-tt18498937.html
>>
>> If everyone only would selling goods through orders, nobody has a problem.
>> But from a more general point of view, I think tax should be calculated
>> independendly of the 'document type' used, in germany we have to include the
>> tax calculations in every type i can think of:
>> orders, invoices, quotes, credit note
>> (on invoices and credit notes for tax auth. tasks; on orders and quotes for
>> showing gros prices to customers)
>>
>> Is this of interest to others here, or do you mainly sell goods through
>> orders?
>>
>> --Roland
>>
>> On Monday 14 July 2008 11:35, Marek Mosiewicz wrote:
>>> 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.
>>
>>
>>
>