On 15/02/13 12:20 +0100, Mathias Behrle wrote: > * Betr.: " Re: [tryton] analitic on product/category" (Thu, 14 Feb 2013 > 22:24:52 +0100): > > > On 14/02/13 21:31 +0100, Jordi Esteve wrote: > > > On 14/02/13 21:16, Cédric Krier wrote: > > > >On 14/02/13 21:10 +0100, Jordi Esteve wrote: > > > >>>>These criteria can be combined, for example to set an analytic > > > >>>>account for an specific partner and company. > > > >>>> > > > >>>>I think this kind of module is very flexible and could be useful for > > > >>>>several people. It is worth to code it for Tryton. > > > >>>As I already explain, such behavior doesn't add any information to the > > > >>>system indeed it just duplicate it which is always bad. > > > >>> > > > >>>So it does not solve the real issue which is? I don't know. > > > >>Sergi has explained it before: To propose automatically analytic > > > >>accounts in invoice lines, for example. Some companies fills > > > >>analytic accounts by user, by company, by partner, by product. For > > > >>the user is more comfortable and it prevents user errors. > > > >Wrong design! Such information can be already found in the system, no > > > >need otf analytic for that. > > > >*Duplicate* information is always wrong. > > > > > > > > > > Not always the information is duplicated. I said that it can > > > *propose* automatically analytic accounts in invoice lines, but then > > > the user can change the proposed analytic account with a different > > > analytic account. So the final analytic moves could be related to an > > > user, a company, a partner, a product, or not related to any of > > > them. > > > > This is even worst because with prefilled value you will never have > > users to change it (users are lazy as any good developers). > > If it is important information, you have to force the user to fill it > > (by making required and not fill by default, like the quantity on sale > > line). This is how you build good (error prone) UI. > > It is a random decision to not provide defaults in this case, but to do it in > some others (like payment term on invoice).
It is not because for the invoice payment term is a value that can be changed on the party over time but can not be changed on the invoice once the process is started. Don't forget we talk here about analytic for which the purpose is reporting so any constraint over the time is required, indeed it is just the opposite as I explained previously it is better to have it dynamic. -- 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/
pgpB9GhxFjXhT.pgp
Description: PGP signature
