* 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).
The task of the application is to take care of getting all the required
informations, that are needed to fulfill the business case. It can not be the
task of the application to take care of untrained users. Wrong data provided by
untrained users are subject to better instruction, but can not be solved by
application design.
If an enterprise wants its users to type in the date each time, they just don't
need to provide/configure the default.
NB: They will be hit by the problem of untrained users in any case as soon as
those will discover = on date fields...;)
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
