VAT - tax authority

[Marek Mosiewicz-2]

Currently VAT/Tax sales switch is based on showPricesWithVatTax in productStore. But in fact it should be based on taxAuthority table. There is the place where we could know if it is VAT or not. It would be also important in purchase order where there is no need for store.

Marek

[Jacopo Cappellato-3]

Hi Marek,

On Jul 2, 2008, at 3:58 PM, Marek Mosiewicz wrote:

> Currently VAT/Tax sales switch is based on showPricesWithVatTax in  
> productStore. But in fact it should be based on taxAuthority table.  
> There is the place where we could know if it is VAT or not. It would  
> be also important in purchase order where there is no need for store.
>
> Marek

This subject is interesting and has been discussed a few times in  
these lists, but I think that there is some confusion around this  
subject.

The product store flag you mention is not mandatory for VAT taxes: I  
mean that using a VAT tax doesn't mean that you want to show your  
product's prices with VAT included (this is only true for some  
retailers).

So, I'd suggest to ignore that flag for now; IMO the best way to  
distinguish vat taxes from sales taxes is thru the  is thru the  
TaxAuthorityRateType: we should add a new entry there for "VAT taxes"

Jacopo

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>

> Hi Marek,
>
> On Jul 2, 2008, at 3:58 PM, Marek Mosiewicz wrote:
>
>> Currently VAT/Tax sales switch is based on showPricesWithVatTax in  productStore. But in fact it should be based on taxAuthority
>> table.  There is the place where we could know if it is VAT or not. It would  be also important in purchase order where there is
>> no need for store.
>>
>> Marek
>
> This subject is interesting and has been discussed a few times in  these lists, but I think that there is some confusion around
> this  subject.
>
> The product store flag you mention is not mandatory for VAT taxes: I  mean that using a VAT tax doesn't mean that you want to show
> your  product's prices with VAT included (this is only true for some  retailers).

Yes, but it's true that in some countries (like France) if you sell to public (B2C vs B2B) you must show your prices with VAT
included (actually with all taxes included). So in some cases it's a must have...

Also there starts to be some environmental taxes for some kind of products (electronic for instance) too. It's verys specific and
nothing is yet needed to be shown but an explanation about those taxes. I think this will become more and more present,
everywhere...

Jacques

> So, I'd suggest to ignore that flag for now; IMO the best way to  distinguish vat taxes from sales taxes is thru the  is thru the
> TaxAuthorityRateType: we should add a new entry there for "VAT taxes"
>
> Jacopo
>

[Marek Mosiewicz-2]

> So, I'd suggest to ignore that flag for now; IMO the best way to
> distinguish vat taxes from sales taxes is thru the  is thru the
> TaxAuthorityRateType: we should add a new entry there for "VAT taxes"
>
> Jacopo
>
I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for DESTINATION
(as I understand - becouse tax sales depends on destination addres)
But we need to know what type of taxman is for our(SOURCE) company. In case
our company
is VAT taxman we should to behave little differently than if our taxman is
SALES TAX.
Maybe it is just enought to add fromTaxAuthGeoId (replacing productStoreId-
it is not good in VAT to use productStoreId for purchase invoices as it can
be
general invoice where there is no store - eg invoice for fixed asset)


Marek

[Jacopo Cappellato-3]

This is an interesting thread.
I'd suggest, before we start to discuss how to change the data model,  
to go one step back and properly define all the requirements relevant  
for VAT tax calculation. I am sure others will be interested in adding  
their comments.
As soon as we have defined a list of requirements, we can go on with  
data model changes.

Here is an example for some requirements:

* the application of a VAT tax rate may depend on the billing address,  
but also on the type of product  and on the from and to parties (add  
details here...)
* periodically (usually on a monthly bases) the company have to  
provide a VAT Tax report: for each Tax Authority, the total VAT tax  
collected and VAT Tax paid by the company is shown (the difference  
between collected and paid is what is due to the tax authority; if the  
difference is negative, the amount will be usually used in the next  
VAT Tax report
* some countries may require that, prices for B2C sales are shown VAT  
included (from Jacques Le Roux)
* etc... etc...

What do you think?

Jacopo

PS: useful resources:

http://docs.ofbiz.org/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model
http://en.wikipedia.org/wiki/VAT

http://docs.ofbiz.org/display/OFBIZ/VAT
http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-PricesWithVAT



On Jul 3, 2008, at 10:33 AM, Marek Mosiewicz wrote:

>> So, I'd suggest to ignore that flag for now; IMO the best way to  
>> distinguish vat taxes from sales taxes is thru the  is thru the  
>> TaxAuthorityRateType: we should add a new entry there for "VAT taxes"
>>
>> Jacopo
>>
> I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for  
> DESTINATION
> (as I understand - becouse tax sales depends on destination addres)
> But we need to know what type of taxman is for our(SOURCE) company.  
> In case our company
> is VAT taxman we should to behave little differently than if our  
> taxman is SALES TAX.
> Maybe it is just enought to add fromTaxAuthGeoId (replacing  
> productStoreId-
> it is not good in VAT to use productStoreId for purchase invoices as  
> it can be
> general invoice where there is no store - eg invoice for fixed asset)
>
>
> Marek

[Marek Mosiewicz-2]

----- Original Message -----
From: "Jacopo Cappellato" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, July 03, 2008 12:27 PM
Subject: Re: VAT - tax authority

> This is an interesting thread.
> I'd suggest, before we start to discuss how to change the data model,  to
> go one step back and properly define all the requirements relevant  for
> VAT tax calculation. I am sure others will be interested in adding  their
> comments.
> As soon as we have defined a list of requirements, we can go on with  data
> model changes.
>
> Here is an example for some requirements:
>
> * the application of a VAT tax rate may depend on the billing address,
> but also on the type of product  and on the from and to parties (add
> details here...)

Algorithm:
if seller is VAT aware seller
        if byuer is from my country take vat% from product category
        if buyer is from EU and is valid VAT company
                    take vat%=0
        if buyer is from WU and is not valid VAT company
                 take vat% from product category ????
        if buyer is form World and is company
                    take vat%=0
        if buyer is from World and is person
                    take vat%=0
 what else ????? I will check it once more tomorrow
> * periodically (usually on a monthly bases) the company have to  provide a
> VAT Tax report: for each Tax Authority, the total VAT tax  collected and
> VAT Tax paid by the company is shown (the difference  between collected
> and paid is what is due to the tax authority; if the  difference is
> negative, the amount will be usually used in the next  VAT Tax report
At least in Poland purchase invoice in some cases can not be included in
VAT report or must be reported in later month. (field taxDate in
invoice would be enough)
VAT tax report in Poland must be grouped by region of sale and type of sale
by so called "registry" (seller/buyer * Poland/EU/World). This is enough
from curernt data.
However some people use more specific grouping (e.g. products/fixed assets)
If it is more common it would be nice to include it too.
> * some countries may require that, prices for B2C sales are shown VAT
> included (from Jacques Le Roux)
In Poland is the same. In product details page it is usually shown also
netto amount (without tax)
as separate price for company users to instant know the price.

> * etc... etc...
>
> What do you think?
>
> Jacopo
>
> PS: useful resources:
>
> http://docs.ofbiz.org/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model
> http://en.wikipedia.org/wiki/VAT
>
> http://docs.ofbiz.org/display/OFBIZ/VAT
> http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-PricesWithVAT
>
>
>
> On Jul 3, 2008, at 10:33 AM, Marek Mosiewicz wrote:
>
>>> So, I'd suggest to ignore that flag for now; IMO the best way to
>>> distinguish vat taxes from sales taxes is thru the  is thru the
>>> TaxAuthorityRateType: we should add a new entry there for "VAT taxes"
>>>
>>> Jacopo
>>>
>> I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for  DESTINATION
>> (as I understand - becouse tax sales depends on destination addres)
>> But we need to know what type of taxman is for our(SOURCE) company.  In
>> case our company
>> is VAT taxman we should to behave little differently than if our  taxman
>> is SALES TAX.
>> Maybe it is just enought to add fromTaxAuthGeoId (replacing
>> productStoreId-
>> it is not good in VAT to use productStoreId for purchase invoices as  it
>> can be
>> general invoice where there is no store - eg invoice for fixed asset)
>>
>>
>> Marek
>
>

[Jacopo Cappellato-3]

What is the meaning of "WU"?

Jacopo

On Jul 3, 2008, at 3:37 PM, Marek Mosiewicz wrote:

>
> ----- Original Message ----- From: "Jacopo Cappellato" <[hidden email]
> >
> To: <[hidden email]>
> Sent: Thursday, July 03, 2008 12:27 PM
> Subject: Re: VAT - tax authority
>
>
>> This is an interesting thread.
>> I'd suggest, before we start to discuss how to change the data  
>> model,  to go one step back and properly define all the  
>> requirements relevant  for VAT tax calculation. I am sure others  
>> will be interested in adding  their comments.
>> As soon as we have defined a list of requirements, we can go on  
>> with  data model changes.
>>
>> Here is an example for some requirements:
>>
>> * the application of a VAT tax rate may depend on the billing  
>> address, but also on the type of product  and on the from and to  
>> parties (add details here...)
> Algorithm:
> if seller is VAT aware seller
>       if byuer is from my country take vat% from product category
>       if buyer is from EU and is valid VAT company
>                   take vat%=0
>       if buyer is from WU and is not valid VAT company
>                take vat% from product category ????
>       if buyer is form World and is company
>                   take vat%=0
>       if buyer is from World and is person
>                   take vat%=0
> what else ????? I will check it once more tomorrow
>> * periodically (usually on a monthly bases) the company have to  
>> provide a VAT Tax report: for each Tax Authority, the total VAT  
>> tax  collected and VAT Tax paid by the company is shown (the  
>> difference  between collected and paid is what is due to the tax  
>> authority; if the  difference is negative, the amount will be  
>> usually used in the next  VAT Tax report
> At least in Poland purchase invoice in some cases can not be  
> included in
> VAT report or must be reported in later month. (field taxDate in
> invoice would be enough)
> VAT tax report in Poland must be grouped by region of sale and type  
> of sale
> by so called "registry" (seller/buyer * Poland/EU/World). This is  
> enough from curernt data.
> However some people use more specific grouping (e.g. products/fixed  
> assets)
> If it is more common it would be nice to include it too.
>> * some countries may require that, prices for B2C sales are shown  
>> VAT included (from Jacques Le Roux)
> In Poland is the same. In product details page it is usually shown  
> also netto amount (without tax)
> as separate price for company users to instant know the price.
>> * etc... etc...
>>
>> What do you think?
>>
>> Jacopo
>>
>> PS: useful resources:
>>
>> http://docs.ofbiz.org/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model
>> http://en.wikipedia.org/wiki/VAT
>>
>> http://docs.ofbiz.org/display/OFBIZ/VAT
>> http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-PricesWithVAT
>>
>>
>>
>> On Jul 3, 2008, at 10:33 AM, Marek Mosiewicz wrote:
>>
>>>> So, I'd suggest to ignore that flag for now; IMO the best way to  
>>>> distinguish vat taxes from sales taxes is thru the  is thru the  
>>>> TaxAuthorityRateType: we should add a new entry there for "VAT  
>>>> taxes"
>>>>
>>>> Jacopo
>>>>
>>> I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for  
>>> DESTINATION
>>> (as I understand - becouse tax sales depends on destination addres)
>>> But we need to know what type of taxman is for our(SOURCE)  
>>> company.  In case our company
>>> is VAT taxman we should to behave little differently than if our  
>>> taxman is SALES TAX.
>>> Maybe it is just enought to add fromTaxAuthGeoId (replacing  
>>> productStoreId-
>>> it is not good in VAT to use productStoreId for purchase invoices  
>>> as  it can be
>>> general invoice where there is no store - eg invoice for fixed  
>>> asset)
>>>
>>>
>>> Marek
>>
>

[Jacopo Cappellato-3]

Ah... after re-reading your post I guess it was just a typo for EU.

Jacopo

On Jul 3, 2008, at 3:37 PM, Marek Mosiewicz wrote:

>
> ----- Original Message ----- From: "Jacopo Cappellato" <[hidden email]
> >
> To: <[hidden email]>
> Sent: Thursday, July 03, 2008 12:27 PM
> Subject: Re: VAT - tax authority
>
>
>> This is an interesting thread.
>> I'd suggest, before we start to discuss how to change the data  
>> model,  to go one step back and properly define all the  
>> requirements relevant  for VAT tax calculation. I am sure others  
>> will be interested in adding  their comments.
>> As soon as we have defined a list of requirements, we can go on  
>> with  data model changes.
>>
>> Here is an example for some requirements:
>>
>> * the application of a VAT tax rate may depend on the billing  
>> address, but also on the type of product  and on the from and to  
>> parties (add details here...)
> Algorithm:
> if seller is VAT aware seller
>       if byuer is from my country take vat% from product category
>       if buyer is from EU and is valid VAT company
>                   take vat%=0
>       if buyer is from WU and is not valid VAT company
>                take vat% from product category ????
>       if buyer is form World and is company
>                   take vat%=0
>       if buyer is from World and is person
>                   take vat%=0
> what else ????? I will check it once more tomorrow
>> * periodically (usually on a monthly bases) the company have to  
>> provide a VAT Tax report: for each Tax Authority, the total VAT  
>> tax  collected and VAT Tax paid by the company is shown (the  
>> difference  between collected and paid is what is due to the tax  
>> authority; if the  difference is negative, the amount will be  
>> usually used in the next  VAT Tax report
> At least in Poland purchase invoice in some cases can not be  
> included in
> VAT report or must be reported in later month. (field taxDate in
> invoice would be enough)
> VAT tax report in Poland must be grouped by region of sale and type  
> of sale
> by so called "registry" (seller/buyer * Poland/EU/World). This is  
> enough from curernt data.
> However some people use more specific grouping (e.g. products/fixed  
> assets)
> If it is more common it would be nice to include it too.
>> * some countries may require that, prices for B2C sales are shown  
>> VAT included (from Jacques Le Roux)
> In Poland is the same. In product details page it is usually shown  
> also netto amount (without tax)
> as separate price for company users to instant know the price.
>> * etc... etc...
>>
>> What do you think?
>>
>> Jacopo
>>
>> PS: useful resources:
>>
>> http://docs.ofbiz.org/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model
>> http://en.wikipedia.org/wiki/VAT
>>
>> http://docs.ofbiz.org/display/OFBIZ/VAT
>> http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-PricesWithVAT
>>
>>
>>
>> On Jul 3, 2008, at 10:33 AM, Marek Mosiewicz wrote:
>>
>>>> So, I'd suggest to ignore that flag for now; IMO the best way to  
>>>> distinguish vat taxes from sales taxes is thru the  is thru the  
>>>> TaxAuthorityRateType: we should add a new entry there for "VAT  
>>>> taxes"
>>>>
>>>> Jacopo
>>>>
>>> I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for  
>>> DESTINATION
>>> (as I understand - becouse tax sales depends on destination addres)
>>> But we need to know what type of taxman is for our(SOURCE)  
>>> company.  In case our company
>>> is VAT taxman we should to behave little differently than if our  
>>> taxman is SALES TAX.
>>> Maybe it is just enought to add fromTaxAuthGeoId (replacing  
>>> productStoreId-
>>> it is not good in VAT to use productStoreId for purchase invoices  
>>> as  it can be
>>> general invoice where there is no store - eg invoice for fixed  
>>> asset)
>>>
>>>
>>> Marek
>>
>

[RolandH-2]

Hi all,

see inline...

On Thursday 03 July 2008 15:37, Marek Mosiewicz wrote:
> Algorithm:
> if seller is VAT aware seller
>         if byuer is from my country take vat% from product category
>         if buyer is from EU and is valid VAT company
>                     take vat%=0
>         if buyer is from EU and is not valid VAT company
>                  take vat% from product category ????
yes for germany
>         if buyer is form World and is company
>                     take vat%=0
>         if buyer is from World and is person
>                     take vat%=0
both wrong for germany: take product category vat%
(there may be exemptions to that, depending on Customs Auth. maybe we get this
more configurable somehow)


[from Jacques email yesterday:]
> > The product store flag you mention is not mandatory for VAT taxes: I
> >  mean that using a VAT tax doesn't mean that you want to show your
> >  product's prices with VAT included (this is only true for some
> >  retailers).
>
> Yes, but it's true that in some countries (like France) if you sell to
> public (B2C vs B2B) you must show your prices with VAT included (actually
> with all taxes included). So in some cases it's a must have...

I'll think: make the product store flag what it sounds like: 'show products
with vat in that ecommerce store' not more, not less (even, don't remove it,
it's needed if you run 2 sites, one B2B one B2C)

--Roland

[Jacques Le Roux]

From: "Roland" <[hidden email]>

> Hi all,
>
> see inline...
>
> On Thursday 03 July 2008 15:37, Marek Mosiewicz wrote:
>> Algorithm:
>> if seller is VAT aware seller
>>         if byuer is from my country take vat% from product category
>>         if buyer is from EU and is valid VAT company
>>                     take vat%=0
>>         if buyer is from EU and is not valid VAT company
>>                  take vat% from product category ????
> yes for germany
>>         if buyer is form World and is company
>>                     take vat%=0
>>         if buyer is from World and is person
>>                     take vat%=0
> both wrong for germany: take product category vat%
> (there may be exemptions to that, depending on Customs Auth. maybe we get this
> more configurable somehow)

In each party, exemption may be defined.

>
> [from Jacques email yesterday:]
>> > The product store flag you mention is not mandatory for VAT taxes: I
>> > mean that using a VAT tax doesn't mean that you want to show your
>> > product's prices with VAT included (this is only true for some
>> > retailers).
>>
>> Yes, but it's true that in some countries (like France) if you sell to
>> public (B2C vs B2B) you must show your prices with VAT included (actually
>> with all taxes included). So in some cases it's a must have...
>
> I'll think: make the product store flag what it sounds like: 'show products
> with vat in that ecommerce store' not more, not less (even, don't remove it,
> it's needed if you run 2 sites, one B2B one B2C)

+1 (I did that (clear label meaning) in French : "Montrer les prix avec la TVA incluse (TTC)" in English it could be "Show Prices
With Vat Tax included" instead of "Show Prices With Vat Tax". Anyway, it's I just did it, change it if you think it's not good.

Jacques

> --Roland
>

[Marek Mosiewicz-2]

Is there global exemption for cutomer ?

In Poland we have sometimes exemption per product per person type  (e.g.
accomodation costs for persons are tax free)
But we handle this usually as separate product. (we have product
accomodation 0% and accomodation 22%)
Maybe we can do this more gently. Any ideas ?

I have consulted with accountant yesterday. In fact algorithm is some more
complicated.

There is need for spedition documents for EU to have vat 0% so it can be
sometimes thet there will be not vat0% or it will be not vat 0% at the
beginning and later it will be corrected to 0% as documents will arrive.
Same can be with World salles.
To make things more complicated VAT report will have to be corrected too.
In current software this is done usually manually.


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


Hi all,

see inline...

On Thursday 03 July 2008 15:37, Marek Mosiewicz wrote:
> Algorithm:
> if seller is VAT aware seller
>         if byuer is from my country take vat% from product category
>         if buyer is from EU and is valid VAT company
>                     take vat%=0
>         if buyer is from EU and is not valid VAT company
>                  take vat% from product category ????
yes for germany
>         if buyer is form World and is company
>                     take vat%=0
>         if buyer is from World and is person
>                     take vat%=0
both wrong for germany: take product category vat%
(there may be exemptions to that, depending on Customs Auth. maybe we get
this
more configurable somehow)


[from Jacques email yesterday:]
> > The product store flag you mention is not mandatory for VAT taxes: I
> > mean that using a VAT tax doesn't mean that you want to show your
> > product's prices with VAT included (this is only true for some
> > retailers).
>
> Yes, but it's true that in some countries (like France) if you sell to
> public (B2C vs B2B) you must show your prices with VAT included (actually
> with all taxes included). So in some cases it's a must have...

I'll think: make the product store flag what it sounds like: 'show products
with vat in that ecommerce store' not more, not less (even, don't remove it,
it's needed if you run 2 sites, one B2B one B2C)

--Roland

[RolandH-2]

Hi Marek,

see inline

Marek Mosiewicz wrote:
> Is there global exemption for cutomer ?
sorry, i don't understand?
> In Poland we have sometimes exemption per product per person type  
> (e.g. accomodation costs for persons are tax free)
> But we handle this usually as separate product. (we have product
> accomodation 0% and accomodation 22%)
> Maybe we can do this more gently. Any ideas ?
we have something similar with our 7% VAT on food: going to McD*****, or
any other fast food restaurant, you have to answer: is this for take
away, or do you want to eat here?
that question isn't only for packing your food, it's for VAT: if you
stay, they have to calculate normal (19%) VAT, if you take away, they
can get along with 7%, because it's handled like food purchases in
supermarkets :)
This is solved by different products here, too. I think you shouldn't
try to solve this in an other way, if necessary hide things like this in
your frontend (maybe by relating 2 products to each other one for case A
one for case B)

> I have consulted with accountant yesterday. In fact algorithm is some
> more complicated.
>
> There is need for spedition documents for EU to have vat 0% so it can
> be sometimes thet there will be not vat0% or it will be not vat 0% at
> the beginning and later it will be corrected to 0% as documents will
> arrive. Same can be with World salles.
> To make things more complicated VAT report will have to be corrected too.
> In current software this is done usually manually.
manually? like changing the report by hand?
i have to reread the accounting (GL) entities, for having a good idea
about that.
there should be something like that, i think:
- post VAT amount to GL account (account is depending on: VAT type,
invoice_to.country, invoice_from.country, maybe some others)
- if report is done, mark entries as 'reported'
- so it should be possible to generate something like an 'correction report'
[that's not really complete nor conclusive...]

--Roland

[Jacopo Cappellato-3]

On Jul 4, 2008, at 9:36 AM, Roland wrote:

> Hi Marek,
>
> see inline
>
> Marek Mosiewicz wrote:
>> Is there global exemption for cutomer ?
> sorry, i don't understand?
>> In Poland we have sometimes exemption per product per person type  
>> (e.g. accomodation costs for persons are tax free)
>> But we handle this usually as separate product. (we have product  
>> accomodation 0% and accomodation 22%)
>> Maybe we can do this more gently. Any ideas ?
> we have something similar with our 7% VAT on food: going to  
> McD*****, or any other fast food restaurant, you have to answer: is  
> this for take away, or do you want to eat here?
> that question isn't only for packing your food, it's for VAT: if you  
> stay, they have to calculate normal (19%) VAT, if you take away,  
> they can get along with 7%, because it's handled like food purchases  
> in supermarkets :)
> This is solved by different products here, too. I think you  
> shouldn't try to solve this in an other way, if necessary hide  
> things like this in your frontend (maybe by relating 2 products to  
> each other one for case A one for case B)
>
>> I have consulted with accountant yesterday. In fact algorithm is  
>> some more complicated.
>>
>> There is need for spedition documents for EU to have vat 0% so it  
>> can be sometimes thet there will be not vat0% or it will be not vat  
>> 0% at the beginning and later it will be corrected to 0% as  
>> documents will arrive. Same can be with World salles.
>> To make things more complicated VAT report will have to be  
>> corrected too.
>> In current software this is done usually manually.
> manually? like changing the report by hand?
> i have to reread the accounting (GL) entities, for having a good  
> idea about that.
> there should be something like that, i think:
> - post VAT amount to GL account (account is depending on: VAT type,  
> invoice_to.country, invoice_from.country, maybe some others)
> - if report is done, mark entries as 'reported'

Yes, we have a reconcileStatusId field in the accounting transaction  
entry table that we can use for this (reconciliated/not reconciliated)

>
> - so it should be possible to generate something like an 'correction  
> report'
> [that's not really complete nor conclusive...]
>
> --Roland
>
>
>

[Marek Mosiewicz-2]

> see inline
>
> Marek Mosiewicz wrote:
>> Is there global exemption for cutomer ?
> sorry, i don't understand?
>> In Poland we have sometimes exemption per product per person type  (e.g.
>> accomodation costs for persons are tax free)
>> But we handle this usually as separate product. (we have product
>> accomodation 0% and accomodation 22%)
>> Maybe we can do this more gently. Any ideas ?
> we have something similar with our 7% VAT on food: going to McD*****, or
> any other fast food restaurant, you have to answer: is this for take away,
> or do you want to eat here?
> that question isn't only for packing your food, it's for VAT: if you stay,
> they have to calculate normal (19%) VAT, if you take away, they can get
> along with 7%, because it's handled like food purchases in supermarkets :)
> This is solved by different products here, too. I think you shouldn't try
> to solve this in an other way, if necessary hide things like this in your
> frontend (maybe by relating 2 products to each other one for case A one
> for case B)
>
>> I have consulted with accountant yesterday. In fact algorithm is some
>> more complicated.
>>
>> There is need for spedition documents for EU to have vat 0% so it can be
>> sometimes thet there will be not vat0% or it will be not vat 0% at the
>> beginning and later it will be corrected to 0% as documents will arrive.
>> Same can be with World salles.
>> To make things more complicated VAT report will have to be corrected too.
>> In current software this is done usually manually.
> manually? like changing the report by hand?
> i have to reread the accounting (GL) entities, for having a good idea
> about that.
> there should be something like that, i think:
> - post VAT amount to GL account (account is depending on: VAT type,
> invoice_to.country, invoice_from.country, maybe some others)
> - if report is done, mark entries as 'reported'
> - so it should be possible to generate something like an 'correction
> report'
> [that's not really complete nor conclusive...]
>

Mostly yes. People do make correction on paper only. ANd do make manual
entries in GL
I do  not know if it is Polish only specific. Is ther in Germany any
document
needed to identify that sell was outside of Germany (e.g. EU) ?
Becouse if there is thera are simillar problems like in Poland (we can
determine
real VAT % only by the user)

Maybe it is only Poland. Poland has nightmare accounting law
and even SAP nor Navision do not really support it ocrrectly as far as I
heard.
So maybe we should concentrate on different countires(non only EU) and see
if there is something
simillar.
Do we have someone in Mexico, Canada, Japan, South Africa, New Zeland,
Peru, Swizeraland, Ukraine, .......... ?
If there are simillar requirements like in Poland we can add them if not it
is
we can skip it.

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





> --Roland
>
>
>
>

[Jacopo Cappellato-3]

On Jul 4, 2008, at 11:54 AM, Marek Mosiewicz wrote:

>> see inline
>>
>> Marek Mosiewicz wrote:
>>> Is there global exemption for cutomer ?
>> sorry, i don't understand?
>>> In Poland we have sometimes exemption per product per person type  
>>> (e.g. accomodation costs for persons are tax free)
>>> But we handle this usually as separate product. (we have product  
>>> accomodation 0% and accomodation 22%)
>>> Maybe we can do this more gently. Any ideas ?
>> we have something similar with our 7% VAT on food: going to  
>> McD*****, or any other fast food restaurant, you have to answer: is  
>> this for take away, or do you want to eat here?
>> that question isn't only for packing your food, it's for VAT: if  
>> you stay, they have to calculate normal (19%) VAT, if you take  
>> away, they can get along with 7%, because it's handled like food  
>> purchases in supermarkets :)
>> This is solved by different products here, too. I think you  
>> shouldn't try to solve this in an other way, if necessary hide  
>> things like this in your frontend (maybe by relating 2 products to  
>> each other one for case A one for case B)
>>
>>> I have consulted with accountant yesterday. In fact algorithm is  
>>> some more complicated.
>>>
>>> There is need for spedition documents for EU to have vat 0% so it  
>>> can be sometimes thet there will be not vat0% or it will be not  
>>> vat 0% at the beginning and later it will be corrected to 0% as  
>>> documents will arrive. Same can be with World salles.
>>> To make things more complicated VAT report will have to be  
>>> corrected too.
>>> In current software this is done usually manually.
>> manually? like changing the report by hand?
>> i have to reread the accounting (GL) entities, for having a good  
>> idea about that.
>> there should be something like that, i think:
>> - post VAT amount to GL account (account is depending on: VAT type,  
>> invoice_to.country, invoice_from.country, maybe some others)
>> - if report is done, mark entries as 'reported'
>> - so it should be possible to generate something like an  
>> 'correction report'
>> [that's not really complete nor conclusive...]
>>
> Mostly yes. People do make correction on paper only. ANd do make  
> manual
> entries in GL

Yes, you could add a manual adjustment entry and then mark the  
original one as "reconciled" (see my last post).

Jacopo

>
> I do  not know if it is Polish only specific. Is ther in Germany any  
> document
> needed to identify that sell was outside of Germany (e.g. EU) ?
> Becouse if there is thera are simillar problems like in Poland (we  
> can determine
> real VAT % only by the user)
>
> Maybe it is only Poland. Poland has nightmare accounting law
> and even SAP nor Navision do not really support it ocrrectly as far  
> as I heard.
> So maybe we should concentrate on different countires(non only EU)  
> and see if there is something
> simillar.
> Do we have someone in Mexico, Canada, Japan, South Africa, New Zeland,
> Peru, Swizeraland, Ukraine, .......... ?
> If there are simillar requirements like in Poland we can add them if  
> not it is
> we can skip it.
>
> Marek Mosiewicz
> http://www.jotel.com.pl
>
>
>
>
>
>> --Roland
>>
>>
>>
>

[Marek Mosiewicz-2]

I have send "call" for requirements for user group too.
I will upgrade VAT page with questions we know


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

----- Original Message -----
From: "Jacopo Cappellato" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, July 03, 2008 12:27 PM
Subject: Re: VAT - tax authority

> This is an interesting thread.
> I'd suggest, before we start to discuss how to change the data model,  to
> go one step back and properly define all the requirements relevant  for
> VAT tax calculation. I am sure others will be interested in adding  their
> comments.
> As soon as we have defined a list of requirements, we can go on with  data
> model changes.
>
> Here is an example for some requirements:
>
> * the application of a VAT tax rate may depend on the billing address,
> but also on the type of product  and on the from and to parties (add
> details here...)
> * periodically (usually on a monthly bases) the company have to  provide a
> VAT Tax report: for each Tax Authority, the total VAT tax  collected and
> VAT Tax paid by the company is shown (the difference  between collected
> and paid is what is due to the tax authority; if the  difference is
> negative, the amount will be usually used in the next  VAT Tax report
> * some countries may require that, prices for B2C sales are shown VAT
> included (from Jacques Le Roux)
> * etc... etc...
>
> What do you think?
>
> Jacopo
>
> PS: useful resources:
>
> http://docs.ofbiz.org/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model
> http://en.wikipedia.org/wiki/VAT
>
> http://docs.ofbiz.org/display/OFBIZ/VAT
> http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-PricesWithVAT
>
>
>
> On Jul 3, 2008, at 10:33 AM, Marek Mosiewicz wrote:
>
>>> So, I'd suggest to ignore that flag for now; IMO the best way to
>>> distinguish vat taxes from sales taxes is thru the  is thru the
>>> TaxAuthorityRateType: we should add a new entry there for "VAT taxes"
>>>
>>> Jacopo
>>>
>> I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for  DESTINATION
>> (as I understand - becouse tax sales depends on destination addres)
>> But we need to know what type of taxman is for our(SOURCE) company.  In
>> case our company
>> is VAT taxman we should to behave little differently than if our  taxman
>> is SALES TAX.
>> Maybe it is just enought to add fromTaxAuthGeoId (replacing
>> productStoreId-
>> it is not good in VAT to use productStoreId for purchase invoices as  it
>> can be
>> general invoice where there is no store - eg invoice for fixed asset)
>>
>>
>> Marek
>
>

[Marek Mosiewicz-2]

Maybe what we need is table where we can find from WHERE to WHERE what kind
of tax is used.
So there is need for table where is:
1. geoFrom
2. geoTo
3. salesTaxTypeId
And second table salesTaxType
1.salesTaxTypeId
2.salesTaxService
3.purchaseTaxService

Sales and Purchase Tax service is name of service which calculates tax. In
this way we can have very
flexible way to handle tax. Any country can have its own way to calculate
taxes if necessery. Any additional taxes can be added in this way.



----- Original Message -----
From: "Jacopo Cappellato" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, July 03, 2008 12:27 PM
Subject: Re: VAT - tax authority

> This is an interesting thread.
> I'd suggest, before we start to discuss how to change the data model,  to
> go one step back and properly define all the requirements relevant  for
> VAT tax calculation. I am sure others will be interested in adding  their
> comments.
> As soon as we have defined a list of requirements, we can go on with  data
> model changes.
>
> Here is an example for some requirements:
>
> * the application of a VAT tax rate may depend on the billing address,
> but also on the type of product  and on the from and to parties (add
> details here...)
> * periodically (usually on a monthly bases) the company have to  provide a
> VAT Tax report: for each Tax Authority, the total VAT tax  collected and
> VAT Tax paid by the company is shown (the difference  between collected
> and paid is what is due to the tax authority; if the  difference is
> negative, the amount will be usually used in the next  VAT Tax report
> * some countries may require that, prices for B2C sales are shown VAT
> included (from Jacques Le Roux)
> * etc... etc...
>
> What do you think?
>
> Jacopo
>
> PS: useful resources:
>
> http://docs.ofbiz.org/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model
> http://en.wikipedia.org/wiki/VAT
>
> http://docs.ofbiz.org/display/OFBIZ/VAT
> http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-PricesWithVAT
>
>
>
> On Jul 3, 2008, at 10:33 AM, Marek Mosiewicz wrote:
>
>>> So, I'd suggest to ignore that flag for now; IMO the best way to
>>> distinguish vat taxes from sales taxes is thru the  is thru the
>>> TaxAuthorityRateType: we should add a new entry there for "VAT taxes"
>>>
>>> Jacopo
>>>
>> I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for  DESTINATION
>> (as I understand - becouse tax sales depends on destination addres)
>> But we need to know what type of taxman is for our(SOURCE) company.  In
>> case our company
>> is VAT taxman we should to behave little differently than if our  taxman
>> is SALES TAX.
>> Maybe it is just enought to add fromTaxAuthGeoId (replacing
>> productStoreId-
>> it is not good in VAT to use productStoreId for purchase invoices as  it
>> can be
>> general invoice where there is no store - eg invoice for fixed asset)
>>
>>
>> Marek
>
>

[Jacopo Cappellato-3]

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

About the "WHERE to WHERE" thing: could you please explain how it will  
be used? I am not sure to understand what you mean.

Thanks,

Jacopo


On Jul 14, 2008, at 10:31 AM, Marek Mosiewicz wrote:

> Maybe what we need is table where we can find from WHERE to WHERE  
> what kind of tax is used.
> So there is need for table where is:
> 1. geoFrom
> 2. geoTo
> 3. salesTaxTypeId
> And second table salesTaxType
> 1.salesTaxTypeId
> 2.salesTaxService
> 3.purchaseTaxService
>
> Sales and Purchase Tax service is name of service which calculates  
> tax. In
> this way we can have very
> flexible way to handle tax. Any country can have its own way to  
> calculate
> taxes if necessery. Any additional taxes can be added in this way.
>
>
>
> ----- Original Message ----- From: "Jacopo Cappellato" <[hidden email]
> >
> To: <[hidden email]>
> Sent: Thursday, July 03, 2008 12:27 PM
> Subject: Re: VAT - tax authority
>
>
>> This is an interesting thread.
>> I'd suggest, before we start to discuss how to change the data  
>> model,  to
>> go one step back and properly define all the requirements relevant  
>> for
>> VAT tax calculation. I am sure others will be interested in adding  
>> their
>> comments.
>> As soon as we have defined a list of requirements, we can go on  
>> with  data
>> model changes.
>>
>> Here is an example for some requirements:
>>
>> * the application of a VAT tax rate may depend on the billing  
>> address,
>> but also on the type of product  and on the from and to parties (add
>> details here...)
>> * periodically (usually on a monthly bases) the company have to  
>> provide a
>> VAT Tax report: for each Tax Authority, the total VAT tax  
>> collected and
>> VAT Tax paid by the company is shown (the difference  between  
>> collected
>> and paid is what is due to the tax authority; if the  difference is
>> negative, the amount will be usually used in the next  VAT Tax report
>> * some countries may require that, prices for B2C sales are shown VAT
>> included (from Jacques Le Roux)
>> * etc... etc...
>>
>> What do you think?
>>
>> Jacopo
>>
>> PS: useful resources:
>>
>> http://docs.ofbiz.org/display/OFBTECH/OFBiz%27s+Tax+Authority+Data+Model
>> http://en.wikipedia.org/wiki/VAT
>>
>> http://docs.ofbiz.org/display/OFBIZ/VAT
>> http://docs.ofbiz.org/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-PricesWithVAT
>>
>>
>>
>> On Jul 3, 2008, at 10:33 AM, Marek Mosiewicz wrote:
>>
>>>> So, I'd suggest to ignore that flag for now; IMO the best way to
>>>> distinguish vat taxes from sales taxes is thru the  is thru the
>>>> TaxAuthorityRateType: we should add a new entry there for "VAT  
>>>> taxes"
>>>>
>>>> Jacopo
>>>>
>>> I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for  
>>> DESTINATION
>>> (as I understand - becouse tax sales depends on destination addres)
>>> But we need to know what type of taxman is for our(SOURCE)  
>>> company.  In
>>> case our company
>>> is VAT taxman we should to behave little differently than if our  
>>> taxman
>>> is SALES TAX.
>>> Maybe it is just enought to add fromTaxAuthGeoId (replacing
>>> productStoreId-
>>> it is not good in VAT to use productStoreId for purchase invoices  
>>> as  it
>>> can be
>>> general invoice where there is no store - eg invoice for fixed  
>>> asset)
>>>
>>>
>>> Marek
>>
>>
>

[Marek Mosiewicz-2]

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]

Hi Marek,

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?

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.

Jacopo


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

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