| chat.freenode.net #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> http://en.wikipedia.org/wiki/Return_on_equity | ||
| 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 move.py :), 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: https://bugs.tryton.org/msg12893 | ||
| 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(~mrechte@landtrekker.com) has left #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!