Hello, I had some questions and comments. First off you are specifically talking about the account_tax table, right?
That entire function would be stored as raw text in the new field? Why not just store the name or path to the function and let the function reside in a module? Placing the function in raw text seems like it would make it hard to debug and extend. For example how would additional inputs be passed to functions if a module adds more functionality? For example the store where the sale was made. Would all functions need to be regenerated that wanted to utilize this? Maybe a link to a function or class could be stored and then an optional configuration json string so that functions/classes could be reused in different configurations. Your function seems like it could be configured with an account(401), a percentage(0.21) and a list of tax codes(a, b). A json string would allow for heavy customization but also be extendable and easily updatable compared to a raw text function which would always need to be replaced entirely. I hope I didn't misunderstand your proposal, I will have to look into the tax system more, I had to monkey-patch it to get it to allow my weird setup in the past but maybe it has improved. -Ian On Sun, Mar 21, 2010 at 12:35 PM, Cédric Krier <[email protected]> wrote: > 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/ > -- [email protected] mailing list To unsubscribe from this group, send email to tryton-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
