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
