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" <[EMAIL PROTECTED] >
To: <dev@ofbiz.apache.org>
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



Reply via email to