Re: VAT - tax authority
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: dev@ofbiz.apache.org 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.
Re: VAT - tax authority
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 [EMAIL PROTECTED] To: dev@ofbiz.apache.org 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.
Re: VAT - tax authority
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, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The from and to Geo discussion is interesting from a requirements perspective, but I'm wondering if it is really the best way to look at things. I may be biased though, given that I designed the current TaxAuthority model and understand better the various world- wide requirements that went into that. The general idea with the TaxAuthority is that you model different agencies that you must pay tax to and the geographic boundary that they charge for taxes in. For pretty much the entire world all companies need to worry about is Tax Authorities that govern places where they have locations. 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
Re: VAT - tax authority
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, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The from and to Geo discussion is interesting from a requirements perspective, but I'm wondering if it is really the best way to look at things. I may be biased though, given that I designed the current TaxAuthority model and understand better the various world- wide requirements that went into that. The general idea with the TaxAuthority is that you model different agencies that you must pay tax to and the geographic boundary that they charge for taxes in. For pretty much the entire world all companies need to worry about is Tax Authorities that govern places where they have locations. 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 smime.p7s Description: S/MIME cryptographic signature
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.
Re: VAT - tax authority
From: Rashko Rejmer [EMAIL PROTECTED] 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
Re: VAT - tax authority
From: Jacques Le Roux [EMAIL PROTECTED] From: Rashko Rejmer [EMAIL PROTECTED] 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
Re: VAT - tax authority
David, thanks for your valuable information; please see my comments below: On Jul 14, 2008, at 10:44 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The from and to Geo discussion is interesting from a requirements perspective, but I'm wondering if it is really the best way to look at things. I may be biased though, given that I designed the current TaxAuthority model and understand better the various world-wide requirements that went into that. The general idea with the TaxAuthority is that you model different agencies that you must pay tax to and the geographic boundary that they charge for taxes in. For pretty much the entire world all companies need to worry about is Tax Authorities that govern places where they have locations. 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 [EMAIL PROTECTED] wrote: On Jul 14, 2008, at 3:08 PM, Marek Mosiewicz wrote: and thanks for the further details; maybe for now we could phrase out the WHERE to WHERE requirement in the following way: * add the ability to specify the tax rules associated to a given (internal) organization The above could be done using the geoId of the bill from address (as you are suggesting) or directly specifying the partyId 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
Re: VAT - tax authority
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
Re: VAT - tax authority
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 [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...) * 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
Re: VAT - tax authority
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 [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...) * 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 smime.p7s Description: S/MIME cryptographic signature
Re: VAT - tax authority
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
Re: VAT - tax authority
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 smime.p7s Description: S/MIME cryptographic signature
Re: VAT - tax authority
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
Re: VAT - tax authority
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 smime.p7s Description: S/MIME cryptographic signature
Re: VAT - tax authority
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 [EMAIL PROTECTED] wrote: On Jul 14, 2008, at 3:08 PM, Marek Mosiewicz wrote: and thanks for the further details; maybe for now we could phrase out the WHERE to WHERE requirement in the following way: * add the ability to specify the tax rules associated to a given (internal) organization The above could be done using the geoId of the bill from address (as you are suggesting) or directly specifying the partyId 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
Re: VAT - tax authority
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 [EMAIL PROTECTED] To: dev@ofbiz.apache.org 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
Re: VAT - tax authority
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
Re: VAT - tax authority
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
Re: VAT - tax authority
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
Re: VAT - tax authority
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
Re: VAT - tax authority
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 [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...) * 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
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
Re: VAT - tax authority
What is the meaning of WU? 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
Re: VAT - tax authority
From: Roland [EMAIL PROTECTED] 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
VAT - tax authority
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
Re: VAT - tax authority
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
Re: VAT - tax authority
From: Jacopo Cappellato [EMAIL PROTECTED] 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
