IRC logs of #tryton for Friday, 2013-04-05 #tryton log beginning Fri Apr 5 00:00:02 CEST 2013
2013-04-05 12:43 <katr> cedk: Concerning your comments about the financial analysis blueprint: Do you mean, that the ratios, values or indicators or whatever they are called should be hardcoded in source files?
2013-04-05 12:51 <cedk> katr: yes, we should not expect user to write the code
2013-04-05 12:52 <katr> cedk: Agreed, the user should not be forced to write the code himself.
2013-04-05 12:53 <katr> cedk: As I have written in the blue print, the user is not expected to write the code: There are value templates which extend a specif COA.
2013-04-05 12:53 <cedk> katr: and most of the "indicator" can be deduced from the current schema
2013-04-05 12:56 <katr> cedk: I see following problem with the hardcoding idea: Accounts, taxes etc are all db configurable. Taxes are something that is regulated by laws and one specific definition should fit one country.
2013-04-05 12:57 <cedk> katr: don't see any problem
2013-04-05 12:57 <cedk> katr: don't understand neither why you are talking about taxes in discussion about accounting indicators
2013-04-05 12:58 <katr> cedk: Nonetheless it's configurable and not hardcoded. There are no regulations for ratios. One definition for one company might not fit the definition of another company.
2013-04-05 12:59 <cedk> katr: don't agree
2013-04-05 12:59 <katr> cedk: Even in one company different persons might have different definitions of one indicator.
2013-04-05 13:01 <cedk> katr: then it is different indicator
2013-04-05 13:02 <katr> cedk: But you expect an accountant or a manager to write a Tryton module for his indicator?
2013-04-05 13:03 <cedk> katr: no
2013-04-05 13:04 <katr> cedk: But how can you then add an indicator?
2013-04-05 13:04 <cedk> katr: you can not
2013-04-05 13:05 <katr> cedk: I.e. you only make pre-existing indicator configurable through the account type?
2013-04-05 13:07 <cedk> katr: yes ket just create the few one that fit 90% of the cases
2013-04-05 13:10 <katr> cedk: As it seems that there is not a broad interest in that topic, this might more than enough for what most people need.
2013-04-05 13:13 <cedk> katr: I'm pretty sure you can compute them without having to change the current data of chart of account
2013-04-05 13:14 <cedk> katr: it is just a matter of creating a wizard to setup the context as I said
2013-04-05 13:14 <cedk> dates, period , company etc.
2013-04-05 13:14 <cedk> writing the different function field that compute the key indicators base on account, account type, account kind etc.
2013-04-05 13:15 <cedk> for me, the main work to do is to collect and agree on the default indicators
2013-04-05 13:15 <cedk> and how to compute them
2013-04-05 13:16 <katr> cedk: I don't understand why you want to change any data from the COA.
2013-04-05 13:16 <cedk> katr: i don't want to change
2013-04-05 13:17 <katr> katr: But the blueprint doesn't propose to do so either.
2013-04-05 13:19 <katr> cedk: And the implementation of the default indicators will be done as an extension to a specific COA?
2013-04-05 13:36 <cedk> katr: I think it is wrong
2013-04-05 13:38 <katr> cedk: And how will they be implemented/defined then?
2013-04-05 13:39 <cedk> katr: I can not tell you how will all the indicator be computed
2013-04-05 13:39 <cedk> katr: I repeat first step is to name which ones will be implemented
2013-04-05 13:42 <katr> cedk: What I meant was by what means they would be implemented not how they are calculated exactly.
2013-04-05 13:42 <cedk> katr: i don't understand the difference
2013-04-05 13:43 <katr> cedk: Should this be a customization module specific for every customer?
2013-04-05 13:44 <katr> cedk: Or could it be reused between different users of the same COA or even across user of different COAs?
2013-04-05 13:44 <cedk> katr: there are many generic indicators that can be in the base
2013-04-05 13:44 <cedk> katr: indicators are not linked to COA
2013-04-05 13:46 <katr> cedk: But how to you map the standard set of indicator to specific accounts in the database?
2013-04-05 13:46 <cedk> katr: which one ?
2013-04-05 13:48 <katr> cedk: Just let us pick one from the Wikipedia as an example: Return on equity
2013-04-05 13:48 <katr> cedk: We need the account balances to calculate the ROI. Do you agree?
2013-04-05 13:49 <katr>
2013-04-05 13:52 <cedk> katr: formula is pretty simple, just take the two values
2013-04-05 13:53 <cedk> katr: net income is in the account type and shareholder equity is in the GL
2013-04-05 13:54 <katr> cedk: Exactly, but the two values is something that we have to extract from our accounting moves, which in turn results to the account balances. Do you agree?
2013-04-05 13:55 <katr> cedk: As I have written in the blueprint and in the email both can be simply calculated from the account balances easily.
2013-04-05 13:56 <cedk> katr: you will not convice me that your bleuprint is good
2013-04-05 13:56 <cedk> katr: user should never code nor store code in the database
2013-04-05 13:57 <cedk> katr: the computation is dam simple to do
2013-04-05 13:57 <cedk> katr: in the worst case it just need a singleton to point to the right accout, accoutn type
2013-04-05 13:57 <katr> cedk: I will no try to convince you, I want to get out what your alternative would be.
2013-04-05 13:58 <cedk> katr: I already explain
2013-04-05 13:59 <katr> cedk: But never the less the definition is linked to accounts or COA.
2013-04-05 14:02 <katr> cedk: And replacing the Python stuff with simple arithmetic expressions is still to complicate?
2013-04-05 14:39 <coeps> Hi, I would like to generate a report in a state-transition or by using a button. Is there an example in the modules somewhere? If not can someone give me a hint what has to be called to execute a report-generation?
2013-04-05 14:41 <cedk> katr: yes for me nothing should be done by the user
2013-04-05 14:43 <katr> coeps: Grep for e.g. "print_ = StateAction("
2013-04-05 14:43 <coeps> cedk: Thanks
2013-04-05 14:46 <katr> cedk: And the template mechanism which defines them for the user doesn't address your concerns?
2013-04-05 14:47 <cedk> katr: no
2013-04-05 14:47 <katr> cedk: Ok
2013-04-05 14:49 <mrechte> Hello. I wonder why the ModelStorage.validate() method is called after the data has been sent to the database and not before ? It would allow to alter some fields before.
2013-04-05 14:51 <katr> mrechte: IIRC the whole thing is running in database transaction which gets rolled back if the validation fails.
2013-04-05 14:51 <cedk> mrechte: validation is an after process
2013-04-05 14:53 <cedk> mrechte: and it will be a bad design that validation process change the things it is validating
2013-04-05 14:53 <mrechte> katr: ok, so where should I put code to alter fields before they are sent to database, in create/write methods ?
2013-04-05 14:55 <katr> mrechte: Yes
2013-04-05 14:55 <mrechte> cedk: no prevalidate() method (not talking of pre_validate) ?
2013-04-05 14:55 <cedk> mrechte: to prevalidate what ?
2013-04-05 14:56 <cedk> mrechte: you should use function fields probaly
2013-04-05 15:01 <mrechte> cedk: ok, to give a practical example, in a modified version of :), the client just displays the period (read only field) according to the date entered. Therefore the client does not send back the period value to the server when creating/updating a move. I need to default the period field according to the date returned before it sent to the database. I did not find any other location to put my code apart in create/write methods.
2013-04-05 15:03 <mrechte> cedk: This more or less same code is duplicated in three locations (client, create/write): not very efficient...
2013-04-05 15:05 <cedk> mrechte: it is not the right way to do, period should not be readonly and change it via on_change calls
2013-04-05 15:09 <mrechte> cedk: thanks. I think this is how I started but I was faced with the problem of having the cursor located in that field (in red), when entering the form, because I have no default value to provide.
2013-04-05 15:18 <mrechte> Why is the client putting emphasis on a required field (many2one) when entering the form ?
2013-04-05 15:19 <cedk> mrechte: already explain in the bugtracker
2013-04-05 15:30 <cedk> mrechte:
2013-04-05 15:35 <mrechte> cedk: thanks I was looking for it ! However I am not very clear. I know that the proposed patch was not good, but what prevents the client to wait the user has input some value before raising that error ?
2013-04-05 15:36 <cedk> mrechte: because there is a domain that said the period field must have a period from the company
2013-04-05 15:36 <cedk> mrechte: so being empty is not valid because empty is not from the company
2013-04-05 15:41 <mrechte> cedk: please where is that declared ?
2013-04-05 15:45 <cedk> mrechte: it is the domain on the act_window
2013-04-05 16:08 <mrechte> cedk: ok. But why can't this be checked when the user validate the record ?
2013-04-05 16:09 <cedk> mrechte: domain validation is done on the fly at any time
2013-04-05 16:10 <cedk> mrechte: because it helps user to fill the right data without mistake instead of warning after the error
2013-04-05 16:14 <mrechte> cedk: so may be the domain expression can be altered to allow the None value ?
2013-04-05 16:17 <cedk> mrechte: it could but I don't find it valid as the field is required
2013-04-05 16:17 <cedk> mrechte: and anyway, the issue exists because of a misconfiguration
2013-04-05 16:23 <mrechte> cedk: this is just an example. Anyway it does not satisfy my request: I have a required field that is derived from another one (in the same model). Only one should be writeable by the client, the other one being just displayed for information only. The only way I found is to put the derived field as readonly, with the drawback of the client not sending it back to the server.
2013-04-05 16:24 <mrechte> cedk: what would be the implication of the client sending all the fields back to the server ?
2013-04-05 16:25 <cedk> mrechte: client will never send readonly field
2013-04-05 16:25 <cedk> mrechte: if you have 2 fields directly correlated then drop one of them
2013-04-05 16:26 <mrechte> cedk: why not ?
2013-04-05 16:28 <cedk> mrechte: because it is data duplication
2013-04-05 16:34 <cedk> mrechte: but the field period and date on account move are not duplicate information because they could be many periods for one date
2013-04-05 16:35 <cedk> mrechte: so making the field period readonly is a mistake
2013-04-05 16:47 <mrechte> cedk: wouldn't it be a misconfiguration ?
2013-04-05 16:57 <katr> cedk: So the steps after agreeing upon a set standard ratios is to have a singleton which defines them for the "account" module?
2013-04-05 16:58 <katr> cedk: Than e.g. account_XY can define them for it's own accounts and account types?
2013-04-05 16:59 <cedk> mrechte: no there are standard period and adjustement period
2013-04-05 16:59 <cedk> katr: first need to figure out which info we are missing and see how we can define it
2013-04-05 17:06 <mrechte> cedk: ok. Talking of data duplication, tracing the SQL statements sent by the server to the database is just amazing: so many statements (some identical it seems) for validating just a single date field ! I wonder what would be the performance with several users working in parallel.
2013-04-05 17:08 <mrechte> cedk: especially ir_session seems much solicited
2013-04-05 17:09 <cedk> mrechte: Are there identical or not ?
2013-04-05 17:09 <cedk> mrechte: ir_session is just query for each requests
2013-04-05 17:10 <katr> cedk: Ok, I think what is missing will be apparent as soon some other people express their demands for that functionality.
2013-04-05 17:11 <cedk> mrechte: also I don't know what you're talking about "validate a date" ?
2013-04-05 17:25 <mrechte> cedk: an on_change_with_period ['date'] that is calling Period.find to return the period_id
2013-04-05 17:31 <mrechte> cedk: 77 SQL statements where issued just for that action !
2013-04-05 17:33 <cedk> mrechte: and do you find queries that should not be done ?
2013-04-05 17:42 <cedk> mrechte: also such requests are run on a readonly transation so no lock at all
2013-04-05 17:54 <mrechte> cedk: I can see 16x BEGIN, x14 COMMIT, x2 ROLLBACK, x14 identical select from ir_session, another x2identical select from ir_session, x2 SET TRANSACTION READ ONLY, x16 SHOW, x2 UPDATE ir_session default_transaction_isolation, 2x SELECT related to my on_change_with
2013-04-05 17:54 <cedk> mrechte: you don't look at one query
2013-04-05 17:55 <mrechte> cedk: yes just the consequence of pressing tab after changing the date field
2013-04-05 17:57 <cedk> mrechte: and did you use the last version ?
2013-04-05 17:57 <cedk> mrechte: I'm pretty sure no
2013-04-05 17:58 <mrechte> cedk: more or less (27/3/13)
2013-04-05 17:59 <cedk> mrechte: so your analysis is wrong
2013-04-05 18:00 <mrechte> cedk: depends when
2013-04-05 18:01 <mrechte> cedk: I'll check again to see the difference
2013-04-05 18:27 <mrechte> cedk: OK dropped to 32 statements: x5 BEGIN, x4 COMMIT, x2 ROLLBACK, x3 (x2 identical SELECT from ir_session), x2 SET TRANSACTION READ ONLY, x6 SHOW default_transaction_isolation, x2 UPDATE ir_session
2013-04-05 18:28 <mrechte> cedk: and 2x SELECT related to the on_change_with_
2013-04-05 18:29 <cedk> mrechte: sounds normal if you have 2 calls
2013-04-05 18:31 <mrechte> cedk: Do you think sending the readonly fields from the client to the server would really impact the performance ?
2013-04-05 18:32 <cedk> mrechte: it is not about performance but design
2013-04-05 18:32 <cedk> mrechte: if it is readonly, the user could not have change it so no need to send it
2013-04-05 18:33 <mrechte> cedk: the user no, but an on_change_with_ yes :)
2013-04-05 18:34 <cedk> mrechte: than it is not a readonly field but a function field
2013-04-05 18:35 <cedk> mrechte: as it doesn't depend on the input of the user, it doesn't contain any new information
2013-04-05 18:38 <cedk> mrechte: I don't want to change this principle in Tryton, I have seen so much issue with your proposal on OpenERP because the value of such field will depend on the input flow of the user
2013-04-05 18:44 <mrechte> cedk: ok that is clear. Just for the fun (and is you have some more free time !) 1) sending back the readonly fields would it cause a problem in the existing modules ? 2) where is that handled in tryton code ? Thanks
2013-04-05 19:03 <cedk> mrechte: it is somewhere in Record.get of the client
2013-04-05 19:06 <mrechte> cedk: thanks. Have a nice week-end.
2013-04-05 19:22 -!- mrechte1( has left #tryton

Generated by 2.17.3 by Marius Gedminas - find it at!