IRC logs of #tryton for Monday, 2008-09-15

chat.freenode.net #tryton log beginning Mon Sep 15 00:00:01 CEST 2008
-!- yangoon(n=mathiasb@p549F5A56.dip.t-dialin.net) has joined #tryton05:18
-!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton08:05
-!- Gedd(n=ged@77.109.114.238) has joined #tryton08:32
-!- gadaga(n=gael@sednaco19320-gw.clients.easynet.fr) has joined #tryton09:01
gadagahi09:01
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton09:21
-!- udono(n=udono@dynamic-unidsl-85-197-22-110.westend.de) has joined #tryton09:30
-!- udono(n=udono@dynamic-unidsl-85-197-22-110.westend.de) has joined #tryton09:32
-!- udono(n=udono@dynamic-unidsl-85-197-22-110.westend.de) has joined #tryton09:43
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton09:48
Timitoshi10:01
cedkTimitos: hi10:02
Timitoscedk: hi10:02
Timitoscedk: lets start with our meeting10:03
udonohi all10:03
cedkok10:04
cedkso I think that we have with the account/account Template, type (Template) etc...10:05
CIA-52tryton: Timitos roundup * #363/cannot start trytond with newest changeset: [new] Traceback (most recent call last): File "./trytond", line 8, in <module> import trytond File "/home/kp/localdev/trytond/trytond/__in ...10:05
cedka good model for accounting10:05
cedkand a good point is that openerp take the same direction10:06
Timitoscedk: i will send you our account chart as we have some problems with the wizard creating the account chart for a company10:06
cedkso for me there is still one thing that I'm not sure10:06
cedkit is the fiscalyear closing10:06
cedkTimitos: ok10:06
cedkTimitos: don't you have a repository?10:07
CIA-52tryton: ced roundup * #363/cannot start trytond with newest changeset: [resolved] rm trytond.pyc10:08
Timitoscedk: not yet.10:08
gadagaTimitos: hi10:09
Timitosgadaga: hi10:09
cedkso for the fiscal year closing, what do you think about?10:09
cedkis it a good way to have the method on the account?10:09
cedkis there every needed methods?10:10
Timitosi didn´t get the methon to work on tryton. i took a look on openerp.10:10
Timitoscedk: i am not sure.10:10
Timitoscedk: i think we should discuss the needs from the side of an accountant.10:11
cedkTimitos: yes10:11
Timitoscedk: could you please explain the boolean field "centralized counterpart" of journal. i am not sure what it is for?10:13
cedkTimitos: in fact, I'm not sure that we must create new account move to report it in the new fiscalyear10:13
cedkTimitos: it is to force the use of only one move per period in the journal10:13
cedkTimitos: when you add a line in this journal, the system will update the counterpart line10:14
cedkTimitos: like that you have only one move per period that is always balanced10:14
Timitoscedk: so all lines in centralized counterpart and the according lines will be balanced, right? but isn´t this with all moves anyway?10:16
cedkTimitos: it is made automaticly and it will not allow more than one move per period10:16
udonocedk: does it change the opening balance for the new period?10:17
Timitosso if i need to change something i will need to change the move as i cannot create a second one?10:17
cedkTimitos: yes10:17
cedkudono: don't understand10:18
Timitoscedk: but can i change such a move or is it posted and not changeable?10:18
cedkTimitos: it is like you want, if you don't post it you can change it10:19
Timitosok.10:19
cedkTimitos: but this is a small things10:20
cedkI think we must first talk about the process of creating new move when closing fiscal year10:20
cedkfirst what is the need?10:20
Timitoscedk: yes10:21
udonocedk: closing a period contains two steps: 1. closing the old period, 2. creating opening balance/entry for the next period. My question is, did the centralized counterpart produce an opening entry for the next period?10:21
cedkudono: I don't understand the creating balance/entry?10:21
udonocedk: = creating new move10:22
Timitoscedk: lets go to the first step of closing the old fiscal year.10:22
cedkudono: currently we don't create move when closing period10:22
udonocedk: ok10:22
Timitosudono: we should not discuss to much things together. lets go step by step.10:22
udonoTimitos: I just ask, not discuss10:23
cedkwhen closing fiscal year, there is some account that needs nothings so they will start with a null balance10:23
cedkall right?10:23
Timitoscedk: closing a fiscal year means that no more posts could be done. and you are right too, but this is for me already a second step.10:24
Timitoscedk: there is another step before10:24
cedkok, we have this check, that no more moves can be created on closed fiscalyear10:24
Timitosin the end of a fiscal year there are some posts made by accountants with special rights.10:25
cedknor posted or reconciled etc...10:25
cedkTimitos: before or after the close?10:25
Timitoscedk: these are end of the year posts as i would call them.10:25
cedkTimitos: or during the close?10:26
Timitoscedk: nice question. i would say. in this time the period needs to be closed for normal accountants, but it needs to be open for preveliged accountants to make the end of the year posts10:26
Timitoscedk: no not during the close as this process can take a few days or weeks.10:27
udonocedk: in Germany we have often special periods upon the monthly periods 13,14,15 in this special periods the accountant make the closing entrys10:27
udonocedk: each period is for closing entry year and correcting the closing entrys10:27
udonocedk: but I dont know if we nesd this?10:28
Timitoscedk: the kind of posts are some having to do with assets or posts to correct some wrong posts or posts of valuation10:28
cedkok, but this is standard move like we have already10:29
Timitoscedk: these posts are really important to get a correct balance sheet in the end of the year. but in this time nomally no new standard entries should be made as there is the danger of mistake10:30
cedkyes, I understand that we must add a new state on fiscalyear10:30
Timitoscedk: i think there are two possibilities: first you can create a 13th period for these posts or a new state can be the solution, yes10:31
cedkTimitos: ok, I will check for other country if we can create extra-periods10:32
cedkbut is those move must be created manually or can be automatized?10:32
Timitoscedk: but this process of end of the year treatments has some effect on the new fiscal year i think. and here we come on the point you want to discuss i think.10:33
Timitoscedk: those moves must be created manually10:33
Timitoscedk: perhaps some posts can be automated in the future10:33
cedkit is just correction so if there was no mistake there was no need of this moves10:34
Timitoslike accrual on asstes10:34
udonoCreating of 13. 14. 15. Period with fromdate and todate 2008-12-31 is already possible in Tryton10:35
Timitosno. there are moves that to be done always. but you cannot calculate the right values always automaticly i think.10:35
Timitosudono: i think a 13th period should be enough10:35
cedkTimitos: I think that they can computed but perhaps we don't have enough information to compute it10:36
Timitoscedk: and i think it would be too much work to automate all these moves as they could be different for some countries or some type of accounting10:36
cedkTimitos: yes of course this is not the problem for now, if we can make it manually, we can create later modules that automate it10:37
Timitoscedk: yes10:37
udonocedk: Just for information: Its not only correction: In big companys period 13. is usually made by accounting department, period 14. is made and evaluated by controllers and period 15 is made and evaluated by CEO10:37
Timitoscedk: for example some of these moves have to do with value added tax.10:37
cedkthe account module must stay simple but generic10:38
Timitoscedk: in the end of the fiscal year all tax accounts need to be allocated to one account. some accountants do that. some not.10:38
Timitoscedk: yes. so i think it is the best way to do this with a 13th period.10:38
Timitoscedk: automated moves for this topic can be put in another module10:39
cedkok but it will be special period that can not be used for invoice etc...10:39
udonoTimitos: yes, you are right10:39
Timitoscedk: sounds good.10:39
udonocedk: maybe a flag on periods [x] internal10:40
Timitosudono: perhaps this can be done with a special state as cedk mentioned10:40
cedkok, we will think about a solution10:40
cedkso after that there is the moves from one fiscal year to an other ?10:41
Timitoscedk: yes10:41
cedkin fact it is not a real move because they can not be made on two different year10:41
Timitoscedk: yes. there is an account for which is not part of income sheet and balance sheet. it is out of both.10:43
cedkand as I said I'm not sure that it is a good solution to create moves10:43
Timitoscedk: this is a common way of doing this. but you are right. we should discuss that because of the architecture of accounting in tryton10:43
udonocedk: You are right, one move cant be in two different periods10:44
cedkespecially for the move line that must be reconciled (for invoice)10:44
cedkif we create new lines, then they are no more linked to the invoice and the invoice workflow will not progress any more10:44
Timitoscedk: yes. this is a problem.10:45
cedkudono: there is already the check for that :-)10:45
cedkTimitos: that is why I think the move creation is not a good solution10:45
TimitosACTION is thinking for some minutes10:45
udonocedk: but you can make one move to close the fiscal year, and another one to open a fiscal year. Both moves take the same account, we call it "Saldenvorträge" in Germany.10:46
cedkACTION thinking also10:46
udonoACTION ist talking to himself10:46
cedkudono: yes that is what it is done for now but there is some problem with lines to reconciliate10:47
udonocedk: what do you understand in 'reconciliate'?10:48
udonoJust for info the english word for german "Saldenvortrag" seems to be "balance forward account"10:49
Timitoscedk: udono: i think we should discuss the effects of these moves on the accounting in general and on the functions in tryton....10:51
udonoTimitos: ok10:51
Timitosfirst: the moves have only impact on the balance sheet, but not on the income statement10:51
Timitosso we should try to understand the impact of these moves on the balance sheet and try to find out what will happen, if we leave them out.10:52
udonoTimitos: I would say the impact is, that the balance is not equal10:53
cedkudono: no the balance will be always equal10:54
Timitosudono: why? all the accounts of the balance sheet have a value in the end of the year. these value must be used in the next fiscal year by law.10:54
udonocedk: yep, my fault ;-)10:54
Timitosudono: ok10:55
udonoAnother try: The balance will be equal, but wrong...10:55
Timitosso the balance sheet will also be correct with the existing values without those moves.10:55
Timitosudono: why?10:55
cedkone things that can be made, is to change the balance computation on account10:57
Timitoscedk: there is one argument to have these moves: if you have them you can track manipulation after closing fiscal year and you can avoid effect of manipulation in and old fiscal year on later fiscal years10:57
cedkto take all the moves from all the fiscalyear10:57
cedkTimitos: don't understand10:58
udonoTimitos: for example: the Balance of the old period contains all open invoices, but these needs to be transferred to the next period until they are paied.10:59
cedkudono: anyway, you must keep it in the balance of the account forever11:00
Timitosudono: the answer of cedk made clear that the balance will be wrong as in the moment the balance sheet is only computed of the entries of one fiscal year. so you are right. in this case the computed balance sheet will be wrong.11:00
cedkthat why I say that we can add a field on account to say use all the moves to compute11:00
udonoTimitos: Yes I know this problems from SQL-Ledger/Lx-Office11:02
cedkso account from the balance sheet will compute with all move from any fiscalyear and account from the Income statement only for the current fiscalyear11:02
cedklike that we you make reconciliation, you use the original line11:03
Timitoscedk: i can see the chances with this solution. but i think we cannot do that. i think closing a fiscal year like tryton does could be a obligation by law. i am not sure11:03
udonoACTION asks where the exact problem is?11:04
cedkTimitos: but if we avoid to change move from closed year11:04
cedkudono: it is that if we duplicate move line from one year to an other11:04
Timitoscedk: i am not sure if this is enough. need to check this.11:04
cedkudono: we lost the workflow tracking11:05
cedkTimitos: we can have an intermediary solution, we can compute the solde of each account when we close the fiscal year11:06
cedkTimitos: and use this amount to compute11:06
cedkTimitos: and let the user to reconciliate old line11:06
udonocedk: Ok, I understand. Thats not so good...11:07
cedkudono: yes, because invoices will never mark as paid11:07
cedkTimitos: do you think that we must create moves?11:07
Timitoscedk: yes. but i will check this with a tax advisor. but i cannot do this now.11:08
cedknormally, in manual accounting, you put on the next year only the balance of accounts11:09
cedkand not the moves11:09
udono@creating period: Just for the log: Period 13,14,15 with starting/endingdate on the last day of the period... it is not possible now in tryton: Error: You can not have 2 periods that overlaps!11:10
cedkudono: yes, but we must use a special flag for this periods11:11
cedkdo you know how other accounting software works for this?11:12
Timitoscedk: udono: i got an tax advisor on the phone. he says that we do NOT need those moves if we can make sure that the computation of balance sheet will be correct without them.11:13
cedkTimitos: good news :-)11:14
udonoTimitos: :-)11:14
cedkbut I think storing the balance of account at the close will be a speed improvement11:14
Timitoscedk: there is only one danger. you need to prevent that these values will get a problem, if you reopen a closed fiscal year and make some moves.11:16
cedkTimitos: we must update it each times11:17
cedkTimitos: that is better than having moves to delete and re-create11:17
Timitoscedk: and it must be possible to have more than one open fiscal year as these end of year moves we talked earlier often are made in the first month of the new year.11:17
Timitoscedk: sounds good.11:18
cedkTimitos: or we can make a historisation of account moves11:18
Timitoscedk: does historisation mean: copy moves to another table? i think this would make work more difficult for accountants?11:19
cedkTimitos: I mean we can put the balance of account after sometimes (1-2 years after closing)11:19
cedkTimitos: no not move to other table, just don't recompute the balance11:20
cedkTimitos: like a sub-total11:20
Timitoscedk: so a fiscal year like this could not be reopened again then.11:20
cedkTimitos: this can be made by the user when he is really sur that he will never re-open the fiscalyear11:21
cedkTimitos: yes11:21
Timitoscedk: sounds good11:21
cedkTimitos: but I think that in every country, there is a moment when you can no more re-open fiscal year11:21
Timitoscedk: yes11:21
cedkso we must allow to modify a move in a closed fiscal year only for reconciliation11:22
cedkand nothing else11:23
Timitoscedk: sounds good too11:23
cedkTimitos: by the way, when is the Income put in Equity?11:24
Timitoscedk: normaly for this is no move nessecary as balance is not correct if it is not put there allways.11:26
cedkTimitos: yes but accountance must create a move at a moment11:26
cedkTimitos: I suppose it is at the end of the year11:27
Timitoscedk: we already changed this with moving account types income under equity i thought11:27
cedkTimitos: yes but in accounting, you must create the move11:28
Timitoscedk: yes you are right. you can do those moves a the end of the year.11:28
Timitoscedk: yes11:28
cedkTimitos: it is dispatching the benefit, no ?11:28
Timitoscedk: i don´t understand11:29
cedkTimitos: I have one more question, it is about receivable and payable account11:29
cedkTimitos: I don't know if it is the right terms11:29
Timitoscedk: stop. i understood. yes11:29
cedkTimitos: the company must put somewhere what it has won during the year11:30
cedkTimitos: back to receivable/payable11:30
Timitoscedk: yes. had only some problem with the word "dispatch"11:30
cedkTimitos: if we follow what we say, this account will always grow up?11:30
Timitoscedk: looks like that yes. it is an balance account. so the value will always be taken into the following year.11:31
Timitosand we need the details for reconcilation11:32
cedkTimitos: because in openerp, there is the method "unreconciled" that take only the unreconciled lines11:32
Timitoscedk: but this behavior will not depend on this accounts but on the close method.11:33
cedkso openerp will get only the amount not yet paid for the next year11:33
cedkTimitos: which close method ?11:33
Timitoscedk: unreconciled or detail. in both cases it makes sense to make the account always grow up11:34
Timitoscedk: the close method unreconciled is only important if you use the way of doing moves at the end of the year.11:34
cedkTimitos: no, unreconciled will not make the account grow up always11:35
cedkTimitos: yes I know, but I try to see if we use the method we talk about, there will not be problems11:35
Timitoscedk: sure? if an invoice is paid the value of the account will decrease. if there is a new invoice the value will raise.11:36
cedkso I see that openerp have a method that we can not do11:36
Timitoscedk: is this a summary?11:36
cedkTimitos: yes so with our method, this will not be possible, it will always grow up11:36
cedkTimitos: don't understand11:37
Timitoscedk: i don´t understand. why will these accounts allways grow up? they will allways have the correct value i think.11:37
cedkTimitos: oups sorry, I forget that it will have reconciliation that make the balance going to zero11:39
Timitoscedk :-) difficult topic11:39
cedkso ok, I think we have talk about all for fiscal year closing11:40
cedkwe can now talk about periods closing11:40
Timitoscedk: so it is important that you see that this behavior is dependent on close method and not on these special account (receivable/payable). perhaps in another country more than these accounts will be set to close method "unreconciled"11:41
cedkfor now, closing a period will just avoid the creation of move on this period11:41
Timitoscedk: do you think that there is some more work to do?11:41
Timitoscedk: perhaps creating a tax report within this wizard could be interesting.11:42
cedkTimitos: but in fact we will no more have unreconciled method with the new behavior11:42
cedkTimitos: no for me the close period is good enough11:42
cedkTimitos: tax report must be separate, I think11:43
cedkTimitos: it depends of the country11:44
Timitoscedk: yes11:44
cedkTimitos: I'm not sure that in every country, the tax report is linked on the way the company handle the period11:44
cedkTimitos: in belgium, you can have tax report each month or each 3 months11:44
cedkTimitos: but you can have your company, that uses period of 1 month and make tax report every 3 months11:45
Timitoscedk: close method seems to be not so important in future of tryton accounting. i am not sure what needs to be done everything there. i think it depends of the changes we just discussed.11:45
Timitoscedk: yes. i think it is better to have tax report on a special module11:46
cedkTimitos: I think that we will have only 2 "close method":11:46
cedkTimitos: - none11:46
Timitoscedk: but if we want we can put tax report into the wizard in the new module anyway.11:46
cedkTimitos: - balance11:46
Timitoscedk: with close method we now only say if the account is part of balance or income sheet now.11:47
cedkTimitos: do you think we can generalize this ?11:48
cedkTimitos: isn't it better to have a separeted field on account11:48
Timitoscedk: i think we should have this field in the moment. but perhaps it will get obsolete later. in the moment we don´t need any account not beloging to one of these reports.11:49
Timitosbut i cannot say this for future.11:50
udonoTimitos: Saldenvorträge doesnt depend on both...11:50
cedkTimitos: we can have off-balance accounts11:50
udono:-)11:51
Timitosudono: we do not need saldenvorträge now.11:51
cedkTimitos: but if the user create it?11:51
Timitoscedk: not now with our solution. but we don´t know in future. so lets keep the field as i already said.11:51
cedkok11:52
udonoTimitos: from which account do you generate the overall staring balances?11:52
udonostarting11:52
Timitosudono: thx. i forgot. yes for this we need an off-balance account. my fault.11:52
cedkTimitos: I suppose the off-balance account will have none as closed method11:53
Timitoscedk: yes11:53
cedkok, I think that is all for now11:54
cedkI will check that with a French accountance and we will start implementing after11:54
Timitoscedk: great11:54
cedkTimitos, udono: thanks11:55
udonocedk: Timitos: thanks11:55
Timitoscedk: i will go into reconcilation deeper these days. perhaps i will have some questions about this later.11:55
Timitoscedk: udono: thanks. great meeting11:55
cedkTimitos: reconciliation is just needed to set invoices as paid11:56
Timitoscedk: i know. i had no time to check how it is working now. there are also some ways of doing this. but i will talk to you if i had time to look at it.11:57
-!- b52laptop(n=b52lapto@41.249.250.195) has joined #tryton12:08
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 968:596726e66e2e trytond/trytond/ (7 files in 4 dirs): Remove old wrong class naming12:25
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 969:1357956ba3db trytond/trytond/ir/action.py: Add module translation for actions for issue36212:25
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 769:ae99352af652 tryton/tryton/action/main.py: Add missing context to get_keyword call12:25
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 192:81c7245a14cb account/account.py: Fix typo12:25
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 193:7e34e4e872e4 account/fiscalyear.py: Fix typo12:26
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 106:753c9d0c1f6f account_invoice/invoice.py: Fix typo12:26
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 130:41f7c712c79e relationship/country.py: Add module translation for countries for issue36112:26
CIA-52tryton: ced roundup * #361/Translation: untranslated field: [resolved] Fix with changeset 41f7c712c79e12:26
CIA-52tryton: ced roundup * #362/Translation: tab headers are not translated: [resolved] Fix with changeset 1357956ba3db12:27
CIA-52tryton: Bertrand Chenal <bch@b2ck.com> default * 970:1a7e473dfdfa trytond/trytond/web_service/db.py: Typo: use level info to log db creation12:29
udonocedk: can we do selection comboboxes with nested/foldered data like in the example gtk-demo > comboboxes > Example "Where are we?"12:36
udonogtk-demo is an demo app for gtk widgets12:37
cedkudono: we don't provide this12:37
udonocedk: ok12:38
cedkudono: but if you have many selections, you can perhaps use a many2one12:38
udonocedk: Its not for many selections, mor for nested data out of a tree...12:38
cedkudono: and by the way, when you start editing the selection, you will have autocompletion12:38
udono:-)12:39
cedkudono: but I think you must selected the bottom value of the tree12:39
-!- b52lap(n=b52lapto@41.249.250.195) has joined #tryton14:11
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 208:355641267aa5 stock/move.py: Fix compute price in the on_change to pass BrowseRecord instead of id15:39
-!- gael_(n=gael@sednaco19320-gw.clients.easynet.fr) has joined #tryton16:33
CIA-52tryton: gadaga roundup * #364/TypeError: hasattr(): attribute name must be string: [new] Traceback (most recent call last): File "/trytond/netsvc.py", line 274, in run res = method(*msg[2:]) File "/trytond/web_service/obj ...16:55
CIA-52tryton: gadaga roundup * #364/TypeError: hasattr(): attribute name must be string: [resolved] resolved with changset 753c9d0c1f6f16:57
CIA-52tryton: gadaga roundup * #364/TypeError: hasattr(): attribute name must be string: [unread] problem is the same with changset 753c9d0c1f6f16:59
-!- cedk_(n=ced@224.215-246-81.adsl-dyn.isp.belgacom.be) has joined #tryton17:38
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton17:46
CIA-52tryton: C?dric Krier <ced@b2ck.com> default * 107:e11b45242dd9 account_invoice/invoice.py: Fix write on period for interger ids for issue36417:49
CIA-52tryton: ced roundup * #364/TypeError: hasattr(): attribute name must be string: [resolved] Must be fixed with changeset e11b45242dd917:49
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton19:30
udonoI have some problems with the fields.Selection definition. How can I manipulate the sequence of all entrys. Strange is, alle selections are inside a list, but the output seems unordered. Any idea?19:57
udonobechamel: cedk: ping19:58
udonoOh I found out that the order is alphabetical... hmm. but why? Wouldn't it be better to create the Selectionlist like it is defined in the module?! So if someone like to sort the selection entrys, then he may simply sort() them.20:14
bechameludono: yes i was actualy checking that they are ordered alphabeticaly20:15
bechameludono: you are right that it's easy to order it20:17
udonobechamel: Do you know where I have to look in the framework to change the selection widget?20:17
bechameludono: why is it a problem for you ? the selection must reflect a special sequence ?20:17
udonobechamel: yes, sometimes alphabetically is not a good sequence20:18
bechameludono: my guest is that the sort of the sequence is made on the client side20:19
udonobechamel: ah, ok you mean in the rendering functions under tryton/tryton/gui ... I take a look20:20
udonobechamel: I get it.20:21
udonobechamel: thx20:21
CIA-52tryton: udono roundup * #365/starting the client with --log= seems not to work in many cases: [new] Its hard to debug client-server communication without seeing the results from the server, but in any case, seeing the requests works already ...20:52

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!