chat.freenode.net #tryton log beginning Mon Sep 15 00:00:01 CEST 2008 | ||
2008-09-15 05:18 -!- yangoon(n=mathiasb@p549F5A56.dip.t-dialin.net) has joined #tryton | ||
2008-09-15 08:05 -!- bechamel(n=user@user-85-201-14-207.tvcablenet.be) has joined #tryton | ||
2008-09-15 08:32 -!- Gedd(n=ged@77.109.114.238) has joined #tryton | ||
2008-09-15 09:01 -!- gadaga(n=gael@sednaco19320-gw.clients.easynet.fr) 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(n=udono@dynamic-unidsl-85-197-22-110.westend.de) has joined #tryton | ||
2008-09-15 09:32 -!- udono(n=udono@dynamic-unidsl-85-197-22-110.westend.de) has joined #tryton | ||
2008-09-15 09:43 -!- udono(n=udono@dynamic-unidsl-85-197-22-110.westend.de) has joined #tryton | ||
2008-09-15 09:48 -!- Timitos(n=Timitos@88.217.184.172) 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@41.249.250.195) has joined #tryton | ||
2008-09-15 12:25 <CIA-52> tryton: C?dric Krier <ced@b2ck.com> 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 <ced@b2ck.com> default * 969:1357956ba3db trytond/trytond/ir/action.py: Add module translation for actions for issue362 | ||
2008-09-15 12:25 <CIA-52> tryton: C?dric Krier <ced@b2ck.com> default * 769:ae99352af652 tryton/tryton/action/main.py: Add missing context to get_keyword call | ||
2008-09-15 12:25 <CIA-52> tryton: C?dric Krier <ced@b2ck.com> default * 192:81c7245a14cb account/account.py: Fix typo | ||
2008-09-15 12:26 <CIA-52> tryton: C?dric Krier <ced@b2ck.com> default * 193:7e34e4e872e4 account/fiscalyear.py: Fix typo | ||
2008-09-15 12:26 <CIA-52> tryton: C?dric Krier <ced@b2ck.com> default * 106:753c9d0c1f6f account_invoice/invoice.py: Fix typo | ||
2008-09-15 12:26 <CIA-52> tryton: C?dric Krier <ced@b2ck.com> default * 130:41f7c712c79e relationship/country.py: 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 <bch@b2ck.com> default * 970:1a7e473dfdfa trytond/trytond/web_service/db.py: 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@41.249.250.195) has joined #tryton | ||
2008-09-15 15:39 <CIA-52> tryton: C?dric Krier <ced@b2ck.com> default * 208:355641267aa5 stock/move.py: Fix compute price in the on_change to pass BrowseRecord instead of id | ||
2008-09-15 16:33 -!- gael_(n=gael@sednaco19320-gw.clients.easynet.fr) 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/netsvc.py", 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_(n=ced@224.215-246-81.adsl-dyn.isp.belgacom.be) 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 <ced@b2ck.com> default * 107:e11b45242dd9 account_invoice/invoice.py: 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@88.217.184.172) 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 irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!