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