Re: VAT - tax authority

[Jacopo Cappellato]

Hi Marek,

and thank you for your comments.



Trying to translate your mail into a list of requirements:





Thanks,

Jacopo


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

However, I'd suggest that, before we focus on the data model definitions and changes, we focus on the definition of requirements from an higher level perspective. In this way we will focus on the definition of our goals (aha requirements) instead on the means to accomplish them (this will be done once the requirements are in place). 1) add the ability to specify a custom service (formula) for the computation of taxes (for greater flexibility) 2) distinguish between tax rules/rates applicable to sales and purchase orders About the "WHERE to WHERE" thing: could you please explain how it will be used? I am not sure to understand what you mean.

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


this way we can have very

taxes if necessery. Any additional taxes can be added in this way.




To: <dev@ofbiz.apache.org>
Sent: Thursday, July 03, 2008 12:27 PM
Subject: Re: VAT - tax authority

Sales and Purchase Tax service is name of service which calculates tax. In flexible way to handle tax. Any country can have its own way to calculate ----- Original Message ----- From: "Jacopo Cappellato" <[EMAIL PROTECTED] >

This is an interesting thread.

comments.

model changes.

Here is an example for some requirements:


but also on the type of product  and on the from and to parties (add
details here...)

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:

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 As soon as we have defined a list of requirements, we can go on with data * the application of a VAT tax rate may depend on the billing address, * 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

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


Jacopo

TaxAuthorityRateType: we should add a new entry there for "VAT taxes"

I do not know. In TaxAuthorittyRateType TaxAuthGeoId is for DESTINATION

(as I understand - becouse tax sales depends on destination addres)

case our company

is SALES TAX.
Maybe it is just enought to add fromTaxAuthGeoId (replacing
productStoreId-

can be



Marek

But we need to know what type of taxman is for our(SOURCE) company. In is VAT taxman we should to behave little differently than if our taxman it is not good in VAT to use productStoreId for purchase invoices as it general invoice where there is no store - eg invoice for fixed asset)

smime.p7s
Description: S/MIME cryptographic signature