IRC logs of #tryton for Monday, 2008-09-15 #tryton log beginning Mon Sep 15 00:00:01 CEST 2008
2008-09-15 05:18 -!- yangoon( has joined #tryton
2008-09-15 08:05 -!- bechamel( has joined #tryton
2008-09-15 08:32 -!- Gedd(n=ged@ has joined #tryton
2008-09-15 09:01 -!- gadaga( has joined #tryton
2008-09-15 09:01 <gadaga> hi
2008-09-15 09:21 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton
2008-09-15 09:30 -!- udono( has joined #tryton
2008-09-15 09:32 -!- udono( has joined #tryton
2008-09-15 09:43 -!- udono( has joined #tryton
2008-09-15 09:48 -!- Timitos(n=Timitos@ has joined #tryton
2008-09-15 10:01 <Timitos> hi
2008-09-15 10:02 <cedk> Timitos: hi
2008-09-15 10:02 <Timitos> cedk: hi
2008-09-15 10:03 <Timitos> cedk: lets start with our meeting
2008-09-15 10:03 <udono> hi all
2008-09-15 10:04 <cedk> ok
2008-09-15 10:05 <cedk> so I think that we have with the account/account Template, type (Template) etc...
2008-09-15 10:05 <CIA-52> tryton: 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 ...
2008-09-15 10:05 <cedk> a good model for accounting
2008-09-15 10:06 <cedk> and a good point is that openerp take the same direction
2008-09-15 10:06 <Timitos> cedk: i will send you our account chart as we have some problems with the wizard creating the account chart for a company
2008-09-15 10:06 <cedk> so for me there is still one thing that I'm not sure
2008-09-15 10:06 <cedk> it is the fiscalyear closing
2008-09-15 10:06 <cedk> Timitos: ok
2008-09-15 10:07 <cedk> Timitos: don't you have a repository?
2008-09-15 10:08 <CIA-52> tryton: ced roundup * #363/cannot start trytond with newest changeset: [resolved] rm trytond.pyc
2008-09-15 10:08 <Timitos> cedk: not yet.
2008-09-15 10:09 <gadaga> Timitos: hi
2008-09-15 10:09 <Timitos> gadaga: hi
2008-09-15 10:09 <cedk> so for the fiscal year closing, what do you think about?
2008-09-15 10:09 <cedk> is it a good way to have the method on the account?
2008-09-15 10:10 <cedk> is there every needed methods?
2008-09-15 10:10 <Timitos> i didn´t get the methon to work on tryton. i took a look on openerp.
2008-09-15 10:10 <Timitos> cedk: i am not sure.
2008-09-15 10:11 <Timitos> cedk: i think we should discuss the needs from the side of an accountant.
2008-09-15 10:11 <cedk> Timitos: yes
2008-09-15 10:13 <Timitos> cedk: could you please explain the boolean field "centralized counterpart" of journal. i am not sure what it is for?
2008-09-15 10:13 <cedk> Timitos: in fact, I'm not sure that we must create new account move to report it in the new fiscalyear
2008-09-15 10:13 <cedk> Timitos: it is to force the use of only one move per period in the journal
2008-09-15 10:14 <cedk> Timitos: when you add a line in this journal, the system will update the counterpart line
2008-09-15 10:14 <cedk> Timitos: like that you have only one move per period that is always balanced
2008-09-15 10:16 <Timitos> cedk: so all lines in centralized counterpart and the according lines will be balanced, right? but isn´t this with all moves anyway?
2008-09-15 10:16 <cedk> Timitos: it is made automaticly and it will not allow more than one move per period
2008-09-15 10:17 <udono> cedk: does it change the opening balance for the new period?
2008-09-15 10:17 <Timitos> so if i need to change something i will need to change the move as i cannot create a second one?
2008-09-15 10:17 <cedk> Timitos: yes
2008-09-15 10:18 <cedk> udono: don't understand
2008-09-15 10:18 <Timitos> cedk: but can i change such a move or is it posted and not changeable?
2008-09-15 10:19 <cedk> Timitos: it is like you want, if you don't post it you can change it
2008-09-15 10:19 <Timitos> ok.
2008-09-15 10:20 <cedk> Timitos: but this is a small things
2008-09-15 10:20 <cedk> I think we must first talk about the process of creating new move when closing fiscal year
2008-09-15 10:20 <cedk> first what is the need?
2008-09-15 10:21 <Timitos> cedk: yes
2008-09-15 10:21 <udono> cedk: 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?
2008-09-15 10:21 <cedk> udono: I don't understand the creating balance/entry?
2008-09-15 10:22 <udono> cedk: = creating new move
2008-09-15 10:22 <Timitos> cedk: lets go to the first step of closing the old fiscal year.
2008-09-15 10:22 <cedk> udono: currently we don't create move when closing period
2008-09-15 10:22 <udono> cedk: ok
2008-09-15 10:22 <Timitos> udono: we should not discuss to much things together. lets go step by step.
2008-09-15 10:23 <udono> Timitos: I just ask, not discuss
2008-09-15 10:23 <cedk> when closing fiscal year, there is some account that needs nothings so they will start with a null balance
2008-09-15 10:23 <cedk> all right?
2008-09-15 10:24 <Timitos> cedk: 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.
2008-09-15 10:24 <Timitos> cedk: there is another step before
2008-09-15 10:24 <cedk> ok, we have this check, that no more moves can be created on closed fiscalyear
2008-09-15 10:25 <Timitos> in the end of a fiscal year there are some posts made by accountants with special rights.
2008-09-15 10:25 <cedk> nor posted or reconciled etc...
2008-09-15 10:25 <cedk> Timitos: before or after the close?
2008-09-15 10:25 <Timitos> cedk: these are end of the year posts as i would call them.
2008-09-15 10:26 <cedk> Timitos: or during the close?
2008-09-15 10:26 <Timitos> cedk: 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 posts
2008-09-15 10:27 <Timitos> cedk: no not during the close as this process can take a few days or weeks.
2008-09-15 10:27 <udono> cedk: in Germany we have often special periods upon the monthly periods 13,14,15 in this special periods the accountant make the closing entrys
2008-09-15 10:27 <udono> cedk: each period is for closing entry year and correcting the closing entrys
2008-09-15 10:28 <udono> cedk: but I dont know if we nesd this?
2008-09-15 10:28 <Timitos> cedk: the kind of posts are some having to do with assets or posts to correct some wrong posts or posts of valuation
2008-09-15 10:29 <cedk> ok, but this is standard move like we have already
2008-09-15 10:30 <Timitos> cedk: 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 mistake
2008-09-15 10:30 <cedk> yes, I understand that we must add a new state on fiscalyear
2008-09-15 10:31 <Timitos> cedk: i think there are two possibilities: first you can create a 13th period for these posts or a new state can be the solution, yes
2008-09-15 10:32 <cedk> Timitos: ok, I will check for other country if we can create extra-periods
2008-09-15 10:32 <cedk> but is those move must be created manually or can be automatized?
2008-09-15 10:33 <Timitos> cedk: 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.
2008-09-15 10:33 <Timitos> cedk: those moves must be created manually
2008-09-15 10:33 <Timitos> cedk: perhaps some posts can be automated in the future
2008-09-15 10:34 <cedk> it is just correction so if there was no mistake there was no need of this moves
2008-09-15 10:34 <Timitos> like accrual on asstes
2008-09-15 10:35 <udono> Creating of 13. 14. 15. Period with fromdate and todate 2008-12-31 is already possible in Tryton
2008-09-15 10:35 <Timitos> no. there are moves that to be done always. but you cannot calculate the right values always automaticly i think.
2008-09-15 10:35 <Timitos> udono: i think a 13th period should be enough
2008-09-15 10:36 <cedk> Timitos: I think that they can computed but perhaps we don't have enough information to compute it
2008-09-15 10:36 <Timitos> cedk: 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 accounting
2008-09-15 10:37 <cedk> Timitos: yes of course this is not the problem for now, if we can make it manually, we can create later modules that automate it
2008-09-15 10:37 <Timitos> cedk: yes
2008-09-15 10:37 <udono> cedk: 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 CEO
2008-09-15 10:37 <Timitos> cedk: for example some of these moves have to do with value added tax.
2008-09-15 10:38 <cedk> the account module must stay simple but generic
2008-09-15 10:38 <Timitos> cedk: in the end of the fiscal year all tax accounts need to be allocated to one account. some accountants do that. some not.
2008-09-15 10:38 <Timitos> cedk: yes. so i think it is the best way to do this with a 13th period.
2008-09-15 10:39 <Timitos> cedk: automated moves for this topic can be put in another module
2008-09-15 10:39 <cedk> ok but it will be special period that can not be used for invoice etc...
2008-09-15 10:39 <udono> Timitos: yes, you are right
2008-09-15 10:39 <Timitos> cedk: sounds good.
2008-09-15 10:40 <udono> cedk: maybe a flag on periods [x] internal
2008-09-15 10:40 <Timitos> udono: perhaps this can be done with a special state as cedk mentioned
2008-09-15 10:40 <cedk> ok, we will think about a solution
2008-09-15 10:41 <cedk> so after that there is the moves from one fiscal year to an other ?
2008-09-15 10:41 <Timitos> cedk: yes
2008-09-15 10:41 <cedk> in fact it is not a real move because they can not be made on two different year
2008-09-15 10:43 <Timitos> cedk: yes. there is an account for which is not part of income sheet and balance sheet. it is out of both.
2008-09-15 10:43 <cedk> and as I said I'm not sure that it is a good solution to create moves
2008-09-15 10:43 <Timitos> cedk: this is a common way of doing this. but you are right. we should discuss that because of the architecture of accounting in tryton
2008-09-15 10:44 <udono> cedk: You are right, one move cant be in two different periods
2008-09-15 10:44 <cedk> especially for the move line that must be reconciled (for invoice)
2008-09-15 10:44 <cedk> if we create new lines, then they are no more linked to the invoice and the invoice workflow will not progress any more
2008-09-15 10:45 <Timitos> cedk: yes. this is a problem.
2008-09-15 10:45 <cedk> udono: there is already the check for that :-)
2008-09-15 10:45 <cedk> Timitos: that is why I think the move creation is not a good solution
2008-09-15 10:45 <Timitos> ACTION is thinking for some minutes
2008-09-15 10:46 <udono> cedk: 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.
2008-09-15 10:46 <cedk> ACTION thinking also
2008-09-15 10:46 <udono> ACTION ist talking to himself
2008-09-15 10:47 <cedk> udono: yes that is what it is done for now but there is some problem with lines to reconciliate
2008-09-15 10:48 <udono> cedk: what do you understand in 'reconciliate'?
2008-09-15 10:49 <udono> Just for info the english word for german "Saldenvortrag" seems to be "balance forward account"
2008-09-15 10:51 <Timitos> cedk: udono: i think we should discuss the effects of these moves on the accounting in general and on the functions in tryton....
2008-09-15 10:51 <udono> Timitos: ok
2008-09-15 10:51 <Timitos> first: the moves have only impact on the balance sheet, but not on the income statement
2008-09-15 10:52 <Timitos> so 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.
2008-09-15 10:53 <udono> Timitos: I would say the impact is, that the balance is not equal
2008-09-15 10:54 <cedk> udono: no the balance will be always equal
2008-09-15 10:54 <Timitos> udono: 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.
2008-09-15 10:54 <udono> cedk: yep, my fault ;-)
2008-09-15 10:55 <Timitos> udono: ok
2008-09-15 10:55 <udono> Another try: The balance will be equal, but wrong...
2008-09-15 10:55 <Timitos> so the balance sheet will also be correct with the existing values without those moves.
2008-09-15 10:55 <Timitos> udono: why?
2008-09-15 10:57 <cedk> one things that can be made, is to change the balance computation on account
2008-09-15 10:57 <Timitos> cedk: 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 years
2008-09-15 10:57 <cedk> to take all the moves from all the fiscalyear
2008-09-15 10:58 <cedk> Timitos: don't understand
2008-09-15 10:59 <udono> Timitos: 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.
2008-09-15 11:00 <cedk> udono: anyway, you must keep it in the balance of the account forever
2008-09-15 11:00 <Timitos> udono: 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.
2008-09-15 11:00 <cedk> that why I say that we can add a field on account to say use all the moves to compute
2008-09-15 11:02 <udono> Timitos: Yes I know this problems from SQL-Ledger/Lx-Office
2008-09-15 11:02 <cedk> so account from the balance sheet will compute with all move from any fiscalyear and account from the Income statement only for the current fiscalyear
2008-09-15 11:03 <cedk> like that we you make reconciliation, you use the original line
2008-09-15 11:03 <Timitos> cedk: 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 sure
2008-09-15 11:04 <udono> ACTION asks where the exact problem is?
2008-09-15 11:04 <cedk> Timitos: but if we avoid to change move from closed year
2008-09-15 11:04 <cedk> udono: it is that if we duplicate move line from one year to an other
2008-09-15 11:04 <Timitos> cedk: i am not sure if this is enough. need to check this.
2008-09-15 11:05 <cedk> udono: we lost the workflow tracking
2008-09-15 11:06 <cedk> Timitos: we can have an intermediary solution, we can compute the solde of each account when we close the fiscal year
2008-09-15 11:06 <cedk> Timitos: and use this amount to compute
2008-09-15 11:06 <cedk> Timitos: and let the user to reconciliate old line
2008-09-15 11:07 <udono> cedk: Ok, I understand. Thats not so good...
2008-09-15 11:07 <cedk> udono: yes, because invoices will never mark as paid
2008-09-15 11:07 <cedk> Timitos: do you think that we must create moves?
2008-09-15 11:08 <Timitos> cedk: yes. but i will check this with a tax advisor. but i cannot do this now.
2008-09-15 11:09 <cedk> normally, in manual accounting, you put on the next year only the balance of accounts
2008-09-15 11:09 <cedk> and not the moves
2008-09-15 11:10 <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!
2008-09-15 11:11 <cedk> udono: yes, but we must use a special flag for this periods
2008-09-15 11:12 <cedk> do you know how other accounting software works for this?
2008-09-15 11:13 <Timitos> cedk: 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.
2008-09-15 11:14 <cedk> Timitos: good news :-)
2008-09-15 11:14 <udono> Timitos: :-)
2008-09-15 11:14 <cedk> but I think storing the balance of account at the close will be a speed improvement
2008-09-15 11:16 <Timitos> cedk: 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.
2008-09-15 11:17 <cedk> Timitos: we must update it each times
2008-09-15 11:17 <cedk> Timitos: that is better than having moves to delete and re-create
2008-09-15 11:17 <Timitos> cedk: 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.
2008-09-15 11:18 <Timitos> cedk: sounds good.
2008-09-15 11:18 <cedk> Timitos: or we can make a historisation of account moves
2008-09-15 11:19 <Timitos> cedk: does historisation mean: copy moves to another table? i think this would make work more difficult for accountants?
2008-09-15 11:19 <cedk> Timitos: I mean we can put the balance of account after sometimes (1-2 years after closing)
2008-09-15 11:20 <cedk> Timitos: no not move to other table, just don't recompute the balance
2008-09-15 11:20 <cedk> Timitos: like a sub-total
2008-09-15 11:20 <Timitos> cedk: so a fiscal year like this could not be reopened again then.
2008-09-15 11:21 <cedk> Timitos: this can be made by the user when he is really sur that he will never re-open the fiscalyear
2008-09-15 11:21 <cedk> Timitos: yes
2008-09-15 11:21 <Timitos> cedk: sounds good
2008-09-15 11:21 <cedk> Timitos: but I think that in every country, there is a moment when you can no more re-open fiscal year
2008-09-15 11:21 <Timitos> cedk: yes
2008-09-15 11:22 <cedk> so we must allow to modify a move in a closed fiscal year only for reconciliation
2008-09-15 11:23 <cedk> and nothing else
2008-09-15 11:23 <Timitos> cedk: sounds good too
2008-09-15 11:24 <cedk> Timitos: by the way, when is the Income put in Equity?
2008-09-15 11:26 <Timitos> cedk: normaly for this is no move nessecary as balance is not correct if it is not put there allways.
2008-09-15 11:26 <cedk> Timitos: yes but accountance must create a move at a moment
2008-09-15 11:27 <cedk> Timitos: I suppose it is at the end of the year
2008-09-15 11:27 <Timitos> cedk: we already changed this with moving account types income under equity i thought
2008-09-15 11:28 <cedk> Timitos: yes but in accounting, you must create the move
2008-09-15 11:28 <Timitos> cedk: yes you are right. you can do those moves a the end of the year.
2008-09-15 11:28 <Timitos> cedk: yes
2008-09-15 11:28 <cedk> Timitos: it is dispatching the benefit, no ?
2008-09-15 11:29 <Timitos> cedk: i don´t understand
2008-09-15 11:29 <cedk> Timitos: I have one more question, it is about receivable and payable account
2008-09-15 11:29 <cedk> Timitos: I don't know if it is the right terms
2008-09-15 11:29 <Timitos> cedk: stop. i understood. yes
2008-09-15 11:30 <cedk> Timitos: the company must put somewhere what it has won during the year
2008-09-15 11:30 <cedk> Timitos: back to receivable/payable
2008-09-15 11:30 <Timitos> cedk: yes. had only some problem with the word "dispatch"
2008-09-15 11:30 <cedk> Timitos: if we follow what we say, this account will always grow up?
2008-09-15 11:31 <Timitos> cedk: looks like that yes. it is an balance account. so the value will always be taken into the following year.
2008-09-15 11:32 <Timitos> and we need the details for reconcilation
2008-09-15 11:32 <cedk> Timitos: because in openerp, there is the method "unreconciled" that take only the unreconciled lines
2008-09-15 11:33 <Timitos> cedk: but this behavior will not depend on this accounts but on the close method.
2008-09-15 11:33 <cedk> so openerp will get only the amount not yet paid for the next year
2008-09-15 11:33 <cedk> Timitos: which close method ?
2008-09-15 11:34 <Timitos> cedk: unreconciled or detail. in both cases it makes sense to make the account always grow up
2008-09-15 11:34 <Timitos> cedk: the close method unreconciled is only important if you use the way of doing moves at the end of the year.
2008-09-15 11:35 <cedk> Timitos: no, unreconciled will not make the account grow up always
2008-09-15 11:35 <cedk> Timitos: yes I know, but I try to see if we use the method we talk about, there will not be problems
2008-09-15 11:36 <Timitos> cedk: sure? if an invoice is paid the value of the account will decrease. if there is a new invoice the value will raise.
2008-09-15 11:36 <cedk> so I see that openerp have a method that we can not do
2008-09-15 11:36 <Timitos> cedk: is this a summary?
2008-09-15 11:36 <cedk> Timitos: yes so with our method, this will not be possible, it will always grow up
2008-09-15 11:37 <cedk> Timitos: don't understand
2008-09-15 11:37 <Timitos> cedk: i don´t understand. why will these accounts allways grow up? they will allways have the correct value i think.
2008-09-15 11:39 <cedk> Timitos: oups sorry, I forget that it will have reconciliation that make the balance going to zero
2008-09-15 11:39 <Timitos> cedk :-) difficult topic
2008-09-15 11:40 <cedk> so ok, I think we have talk about all for fiscal year closing
2008-09-15 11:40 <cedk> we can now talk about periods closing
2008-09-15 11:41 <Timitos> cedk: 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"
2008-09-15 11:41 <cedk> for now, closing a period will just avoid the creation of move on this period
2008-09-15 11:41 <Timitos> cedk: do you think that there is some more work to do?
2008-09-15 11:42 <Timitos> cedk: perhaps creating a tax report within this wizard could be interesting.
2008-09-15 11:42 <cedk> Timitos: but in fact we will no more have unreconciled method with the new behavior
2008-09-15 11:42 <cedk> Timitos: no for me the close period is good enough
2008-09-15 11:43 <cedk> Timitos: tax report must be separate, I think
2008-09-15 11:44 <cedk> Timitos: it depends of the country
2008-09-15 11:44 <Timitos> cedk: yes
2008-09-15 11:44 <cedk> Timitos: I'm not sure that in every country, the tax report is linked on the way the company handle the period
2008-09-15 11:44 <cedk> Timitos: in belgium, you can have tax report each month or each 3 months
2008-09-15 11:45 <cedk> Timitos: but you can have your company, that uses period of 1 month and make tax report every 3 months
2008-09-15 11:45 <Timitos> cedk: 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.
2008-09-15 11:46 <Timitos> cedk: yes. i think it is better to have tax report on a special module
2008-09-15 11:46 <cedk> Timitos: I think that we will have only 2 "close method":
2008-09-15 11:46 <cedk> Timitos: - none
2008-09-15 11:46 <Timitos> cedk: but if we want we can put tax report into the wizard in the new module anyway.
2008-09-15 11:46 <cedk> Timitos: - balance
2008-09-15 11:47 <Timitos> cedk: with close method we now only say if the account is part of balance or income sheet now.
2008-09-15 11:48 <cedk> Timitos: do you think we can generalize this ?
2008-09-15 11:48 <cedk> Timitos: isn't it better to have a separeted field on account
2008-09-15 11:49 <Timitos> cedk: 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.
2008-09-15 11:50 <Timitos> but i cannot say this for future.
2008-09-15 11:50 <udono> Timitos: Saldenvorträge doesnt depend on both...
2008-09-15 11:50 <cedk> Timitos: we can have off-balance accounts
2008-09-15 11:51 <udono> :-)
2008-09-15 11:51 <Timitos> udono: we do not need saldenvorträge now.
2008-09-15 11:51 <cedk> Timitos: but if the user create it?
2008-09-15 11:51 <Timitos> cedk: not now with our solution. but we don´t know in future. so lets keep the field as i already said.
2008-09-15 11:52 <cedk> ok
2008-09-15 11:52 <udono> Timitos: from which account do you generate the overall staring balances?
2008-09-15 11:52 <udono> starting
2008-09-15 11:52 <Timitos> udono: thx. i forgot. yes for this we need an off-balance account. my fault.
2008-09-15 11:53 <cedk> Timitos: I suppose the off-balance account will have none as closed method
2008-09-15 11:53 <Timitos> cedk: yes
2008-09-15 11:54 <cedk> ok, I think that is all for now
2008-09-15 11:54 <cedk> I will check that with a French accountance and we will start implementing after
2008-09-15 11:54 <Timitos> cedk: great
2008-09-15 11:55 <cedk> Timitos, udono: thanks
2008-09-15 11:55 <udono> cedk: Timitos: thanks
2008-09-15 11:55 <Timitos> cedk: i will go into reconcilation deeper these days. perhaps i will have some questions about this later.
2008-09-15 11:55 <Timitos> cedk: udono: thanks. great meeting
2008-09-15 11:56 <cedk> Timitos: reconciliation is just needed to set invoices as paid
2008-09-15 11:57 <Timitos> cedk: 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.
2008-09-15 12:08 -!- b52laptop(n=b52lapto@ has joined #tryton
2008-09-15 12:25 <CIA-52> tryton: C?dric Krier <> default * 968:596726e66e2e trytond/trytond/ (7 files in 4 dirs): Remove old wrong class naming
2008-09-15 12:25 <CIA-52> tryton: C?dric Krier <> default * 969:1357956ba3db trytond/trytond/ir/ Add module translation for actions for issue362
2008-09-15 12:25 <CIA-52> tryton: C?dric Krier <> default * 769:ae99352af652 tryton/tryton/action/ Add missing context to get_keyword call
2008-09-15 12:25 <CIA-52> tryton: C?dric Krier <> default * 192:81c7245a14cb account/ Fix typo
2008-09-15 12:26 <CIA-52> tryton: C?dric Krier <> default * 193:7e34e4e872e4 account/ Fix typo
2008-09-15 12:26 <CIA-52> tryton: C?dric Krier <> default * 106:753c9d0c1f6f account_invoice/ Fix typo
2008-09-15 12:26 <CIA-52> tryton: C?dric Krier <> default * 130:41f7c712c79e relationship/ Add module translation for countries for issue361
2008-09-15 12:26 <CIA-52> tryton: ced roundup * #361/Translation: untranslated field: [resolved] Fix with changeset 41f7c712c79e
2008-09-15 12:27 <CIA-52> tryton: ced roundup * #362/Translation: tab headers are not translated: [resolved] Fix with changeset 1357956ba3db
2008-09-15 12:29 <CIA-52> tryton: Bertrand Chenal <> default * 970:1a7e473dfdfa trytond/trytond/web_service/ Typo: use level info to log db creation
2008-09-15 12:36 <udono> cedk: can we do selection comboboxes with nested/foldered data like in the example gtk-demo > comboboxes > Example "Where are we?"
2008-09-15 12:37 <udono> gtk-demo is an demo app for gtk widgets
2008-09-15 12:37 <cedk> udono: we don't provide this
2008-09-15 12:38 <udono> cedk: ok
2008-09-15 12:38 <cedk> udono: but if you have many selections, you can perhaps use a many2one
2008-09-15 12:38 <udono> cedk: Its not for many selections, mor for nested data out of a tree...
2008-09-15 12:38 <cedk> udono: and by the way, when you start editing the selection, you will have autocompletion
2008-09-15 12:39 <udono> :-)
2008-09-15 12:39 <cedk> udono: but I think you must selected the bottom value of the tree
2008-09-15 14:11 -!- b52lap(n=b52lapto@ has joined #tryton
2008-09-15 15:39 <CIA-52> tryton: C?dric Krier <> default * 208:355641267aa5 stock/ Fix compute price in the on_change to pass BrowseRecord instead of id
2008-09-15 16:33 -!- gael_( has joined #tryton
2008-09-15 16:55 <CIA-52> tryton: gadaga roundup * #364/TypeError: hasattr(): attribute name must be string: [new] Traceback (most recent call last): File "/trytond/", line 274, in run res = method(*msg[2:]) File "/trytond/web_service/obj ...
2008-09-15 16:57 <CIA-52> tryton: gadaga roundup * #364/TypeError: hasattr(): attribute name must be string: [resolved] resolved with changset 753c9d0c1f6f
2008-09-15 16:59 <CIA-52> tryton: gadaga roundup * #364/TypeError: hasattr(): attribute name must be string: [unread] problem is the same with changset 753c9d0c1f6f
2008-09-15 17:38 -!- cedk_( has joined #tryton
2008-09-15 17:46 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton
2008-09-15 17:49 <CIA-52> tryton: C?dric Krier <> default * 107:e11b45242dd9 account_invoice/ Fix write on period for interger ids for issue364
2008-09-15 17:49 <CIA-52> tryton: ced roundup * #364/TypeError: hasattr(): attribute name must be string: [resolved] Must be fixed with changeset e11b45242dd9
2008-09-15 19:30 -!- Timitos(n=Timitos@ has joined #tryton
2008-09-15 19:57 <udono> I 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?
2008-09-15 19:58 <udono> bechamel: cedk: ping
2008-09-15 20:14 <udono> Oh 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.
2008-09-15 20:15 <bechamel> udono: yes i was actualy checking that they are ordered alphabeticaly
2008-09-15 20:17 <bechamel> udono: you are right that it's easy to order it
2008-09-15 20:17 <udono> bechamel: Do you know where I have to look in the framework to change the selection widget?
2008-09-15 20:17 <bechamel> udono: why is it a problem for you ? the selection must reflect a special sequence ?
2008-09-15 20:18 <udono> bechamel: yes, sometimes alphabetically is not a good sequence
2008-09-15 20:19 <bechamel> udono: my guest is that the sort of the sequence is made on the client side
2008-09-15 20:20 <udono> bechamel: ah, ok you mean in the rendering functions under tryton/tryton/gui ... I take a look
2008-09-15 20:21 <udono> bechamel: I get it.
2008-09-15 20:21 <udono> bechamel: thx
2008-09-15 20:52 <CIA-52> tryton: 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 ...

Generated by 2.17.3 by Marius Gedminas - find it at!