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
