Hi,
As I said previously, I was thinking on how to improve current tax
implementation in Tryton.
First, I think making a generic tax computation that will rule all the case
from all countries is really complicated because legislators don't write tax
laws in a rational way. They are full of exception, special cases etc. So
trying to define a relational data model is a lost cause.
The current model with account.tax, account.tax.rule etc. works pretty well
for experimented people and is easy to extend but the result is a very complex
set of datas that are hard to maintain and to evolve.
In fact, what we need when computing taxes is the definition of the move lines
to generate (including the tax lines). And this computation will depend on
many external informations like the party (country, VAT etc.), the delivery
addresse (in some case), the account date, the product (service vs stockable
etc.) etc.
So how to achieve this goal? I think we already have a powerful tool for that,
it is Python. Python was designed in part to be embeded in application and to
become a scripting language that is easy to read and to learn.
Here is my proposal. We drop all the fields related to the computation like
percentage, amount, *_account, *_code, *_sign, childs etc. We replace it by a
simple text field that will include python code to compute the tax account
moves.
The value of this field could look like this:
def compute(amount, quantity, type, date, party, delivery, ...):
if type == 'invoice':
return [{
'account': account('401'),
'debit': quantity * amount * Decimal('0.21'),
'taxe_lines': [{
'amount': quantity * amount,
'code': tax_code('a'),
}, {
'amount': quantity * amount * Decimal('0.21'),
'code': tax_code('b'),
},
],
}]
else:
...
As you can see, there is some helper function "account" and "tax_code" that
will help to get the database id of the corresponding records (based on their
code). There is some parameters define in the function like:
- type: "invoice" or "credit note"
- party
- delivery: the delivery addresse
To allow easy customization, I propose to have a second text field that will
define a decorator in the previous function. This will be edited by the users
and the previous one will be defined by accounting country modules.
I think it will be possible to create migration with a generic compute function.
Of course, this will not be available for 1.6 but for 1.8.
Please review this proposal, I will write a blueprint later.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgp7sAwjl2RUL.pgp
Description: PGP signature
