IRC logs of #tryton for Friday, 2013-04-05 #tryton log beginning Fri Apr 5 00:00:02 CEST 2013
katrcedk: 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?12:43
cedkkatr: yes, we should not expect user to write the code12:51
katrcedk: Agreed, the user should not be forced to write the code himself.12:52
katrcedk: 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.12:53
cedkkatr: and most of the "indicator" can be deduced from the current schema12:53
katrcedk: 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.12:56
cedkkatr: don't see any problem12:57
cedkkatr: don't understand neither why you are talking about taxes in discussion about accounting indicators12:57
katrcedk: 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.12:58
cedkkatr: don't agree12:59
katrcedk: Even in one company different persons might have different definitions of one indicator.12:59
cedkkatr: then it is different indicator13:01
katrcedk: But you expect an accountant or a manager to write a Tryton module for his indicator?13:02
cedkkatr: no13:03
katrcedk: But how can you then add an indicator?13:04
cedkkatr: you can not13:04
katrcedk: I.e. you only make pre-existing indicator configurable through the account type?13:05
cedkkatr: yes ket just create the few one that fit 90% of the cases13:07
katrcedk: As it seems that there is not a broad interest in that topic, this might more than enough for what most people need.13:10
cedkkatr: I'm pretty sure you can compute them without having to change the current data of chart of account13:13
cedkkatr: it is just a matter of creating a wizard to setup the context as I said13:14
cedkdates, period , company etc.13:14
cedkwriting the different function field that compute the key indicators base on account, account type, account kind etc.13:14
cedkfor me, the main work to do is to collect and agree on the default indicators13:15
cedkand how to compute them13:15
katrcedk: I don't understand why you want to change any data from the COA.13:16
cedkkatr: i don't want to change13:16
katrkatr: But the blueprint doesn't propose to do so either.13:17
katrcedk: And the implementation of the default indicators will be done as an extension to a specific COA?13:19
cedkkatr: I think it is wrong13:36
katrcedk: And how will they be implemented/defined then?13:38
cedkkatr: I can not tell you how will all the indicator be computed13:39
cedkkatr: I repeat first step is to name which ones will be implemented13:39
katrcedk: What I meant was by what means they would be implemented not how they are calculated exactly.13:42
cedkkatr: i don't understand the difference13:42
katrcedk: Should this be a customization module specific for every customer?13:43
katrcedk: Or could it be reused between different users of the same COA or even across user of different COAs?13:44
cedkkatr: there are many generic indicators that can be in the base13:44
cedkkatr: indicators are not linked to COA13:44
katrcedk: But how to you map the standard set of indicator to specific accounts in the database?13:46
cedkkatr: which one ?13:46
katrcedk: Just let us pick one from the Wikipedia as an example: Return on equity13:48
katrcedk: We need the account balances to calculate the ROI. Do you agree?13:48
cedkkatr: formula is pretty simple, just take the two values13:52
cedkkatr: net income is in the account type and shareholder equity is in the GL13:53
katrcedk: 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?13:54
katrcedk: As I have written in the blueprint and in the email both can be simply calculated from the account balances easily.13:55
cedkkatr: you will not convice me that your bleuprint is good13:56
cedkkatr: user should never code nor store code in the database13:56
cedkkatr: the computation is dam simple to do13:57
cedkkatr: in the worst case it just need a singleton to point to the right accout, accoutn type13:57
katrcedk: I will no try to convince you, I want to get out what your alternative would be.13:57
cedkkatr: I already explain13:58
katrcedk: But never the less the definition is linked to accounts or COA.13:59
katrcedk: And replacing the Python stuff with simple arithmetic expressions is still to complicate?14:02
coepsHi, 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?14:39
cedkkatr: yes for me nothing should be done by the user14:41
katrcoeps: Grep for e.g. "print_ = StateAction("14:43
coepscedk: Thanks14:43
katrcedk: And the template mechanism which defines them for the user doesn't address your concerns?14:46
cedkkatr: no14:47
katrcedk: Ok14:47
mrechteHello. 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.14:49
katrmrechte: IIRC the whole thing is running in database transaction which gets rolled back if the validation fails.14:51
cedkmrechte: validation is an after process14:51
cedkmrechte: and it will be a bad design that validation process change the things it is validating14:53
mrechtekatr: ok, so where should I put code to alter fields before they are sent to database, in create/write methods ?14:53
katrmrechte: Yes14:55
mrechtecedk: no prevalidate() method (not talking of pre_validate) ?14:55
cedkmrechte: to prevalidate what ?14:55
cedkmrechte: you should use function fields probaly14:56
mrechtecedk: 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.15:01
mrechtecedk: This more or less same code is duplicated in three locations (client, create/write): not very efficient...15:03
cedkmrechte: it is not the right way to do, period should not be readonly and change it via on_change calls15:05
mrechtecedk: 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.15:09
mrechteWhy is the client putting emphasis on a required field (many2one) when entering the form ?15:18
cedkmrechte: already explain in the bugtracker15:19
mrechtecedk: 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 ?15:35
cedkmrechte: because there is a domain that said the period field must have a period from the company15:36
cedkmrechte: so being empty is not valid because empty is not from the company15:36
mrechtecedk: please where is that declared ?15:41
cedkmrechte: it is the domain on the act_window15:45
mrechtecedk: ok. But why can't this be checked when the user validate the record ?16:08
cedkmrechte: domain validation is done on the fly at any time16:09
cedkmrechte: because it helps user to fill the right data without mistake instead of warning after the error16:10
mrechtecedk: so may be the domain expression can be altered to allow the None value ?16:14
cedkmrechte: it could but I don't find it valid as the field is required16:17
cedkmrechte: and anyway, the issue exists because of a misconfiguration16:17
mrechtecedk: 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.16:23
mrechtecedk: what would be the implication of the client sending all the fields back to the server ?16:24
cedkmrechte: client will never send readonly field16:25
cedkmrechte: if you have 2 fields directly correlated then drop one of them16:25
mrechtecedk: why not ?16:26
cedkmrechte: because it is data duplication16:28
cedkmrechte: but the field period and date on account move are not duplicate information because they could be many periods for one date16:34
cedkmrechte: so making the field period readonly is a mistake16:35
mrechtecedk: wouldn't it be a misconfiguration ?16:47
katrcedk: So the steps after agreeing upon a set standard ratios is to have a singleton which defines them for the "account" module?16:57
katrcedk: Than e.g. account_XY can define them for it's own accounts and account types?16:58
cedkmrechte: no there are standard period and adjustement period16:59
cedkkatr: first need to figure out which info we are missing and see how we can define it16:59
mrechtecedk: 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.17:06
mrechtecedk: especially ir_session seems much solicited17:08
cedkmrechte: Are there identical or not ?17:09
cedkmrechte: ir_session is just query for each requests17:09
katrcedk: Ok, I think what is missing will be apparent as soon some other people express their demands for that functionality.17:10
cedkmrechte: also I don't know what you're talking about "validate a date" ?17:11
mrechtecedk: an on_change_with_period ['date'] that is calling Period.find to return the period_id17:25
mrechtecedk: 77 SQL statements where issued just for that action !17:31
cedkmrechte: and do you find queries that should not be done ?17:33
cedkmrechte: also such requests are run on a readonly transation so no lock at all17:42
mrechtecedk: 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_with17:54
cedkmrechte: you don't look at one query17:54
mrechtecedk: yes just the consequence of pressing tab after changing the date field17:55
cedkmrechte: and did you use the last version ?17:57
cedkmrechte: I'm pretty sure no17:57
mrechtecedk: more or less (27/3/13)17:58
cedkmrechte: so your analysis is wrong17:59
mrechtecedk: depends when18:00
mrechtecedk: I'll check again to see the difference18:01
mrechtecedk: 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_session18:27
mrechtecedk: and 2x SELECT related to the on_change_with_18:28
cedkmrechte: sounds normal if you have 2 calls18:29
mrechtecedk: Do you think sending the readonly fields from the client to the server would really impact the performance ?18:31
cedkmrechte: it is not about performance but design18:32
cedkmrechte: if it is readonly, the user could not have change it so no need to send it18:32
mrechtecedk: the user no, but an on_change_with_ yes :)18:33
cedkmrechte: than it is not a readonly field but a function field18:34
cedkmrechte: as it doesn't depend on the input of the user, it doesn't contain any new information18:35
cedkmrechte: 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 user18:38
mrechtecedk: 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 ? Thanks18:44
cedkmrechte: it is somewhere in Record.get of the client19:03
mrechtecedk: thanks. Have a nice week-end.19:06
-!- mrechte1( has left #tryton19:22

Generated by 2.11.0 by Marius Gedminas - find it at!