On 21/03/10 15:52 -0700, Ian Wilson wrote: > Hello, > > I had some questions and comments. First off you are specifically > talking about the account_tax table, right?
Yes and also account.tax.rule
>
> That entire function would be stored as raw text in the new field?
Yes.
> Why not just store the name or path to the function and let the
> function reside in a module?
I think we should let the user customize the computation because I think it is
really part of the business of a company.
>
> Placing the function in raw text seems like it would make it hard to
> debug and extend.
We could at _constraints that ensure the code will run without exception. And
why not a wizard to let the user test it with a set of values.
And normally for simple usage, this function will be quite simple.
> For example how would additional inputs be passed
> to functions if a module adds more functionality?
I think we should fine a way to allow modules to extend the data passed to the
function. Perhaps the function signature must be:
def compute(*args, *kwargs):
This will allow any kind of values.
> For example the
> store where the sale was made. Would all functions need to be
> regenerated that wanted to utilize this?
Yes but anyway, I think if the company requires very specific tax computation,
it must be written for it.
>
> 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.
For me json format is not enough because it is static and we fail back into
the current implementation pattern.
The goals is to provide a customization with a full featured programming
language.
> Your function seems like it could
> be configured with an account(401), a percentage(0.21) and a list of
> tax codes(a, b).
Only account() and tax_code() because we need to have the ids of this records
for the company account chart. But perhaps for simplicity for the user, it
could be simple strings and a decorator function will transform them into ids.
> 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.
Yes, but all function in Tryton modules has the same properties: "you can not
modify it". Instead we decorate it (it is what is called "inheritage").
>
> 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.
I suppose you did it for the sale location so I think with this change it will
be more flexible.
--
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/
pgpvv3DYJTx21.pgp
Description: PGP signature
