IRC logs of #tryton for Wednesday, 2009-05-06

chat.freenode.net #tryton log beginning Wed May 6 00:00:02 CEST 2009
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton00:17
-!- yangoon1(n=mathiasb@p549F49B1.dip.t-dialin.net) has joined #tryton00:17
CIA-48ced roundup * #1036/AttributeError: 'Screen' object has no attribute 'views': [need-eg] I could not succeed to reproduce the issue.00:20
CIA-48http://bugs.tryton.org/roundup/issue103600:20
CIA-48ced roundup * #1039/expand button on tree view: [invalid] It is not possible because we can have unlimited tree. You can still selecte all the records with CTRL+A and open it with right arrow. T ...00:23
CIA-48http://bugs.tryton.org/roundup/issue103900:23
CIA-48matb roundup * #749/Website: distribution packages: [closed] Closed, because meanwhile outdated, partially solved and partially superseeded by issue914.01:25
CIA-48http://bugs.tryton.org/roundup/issue74901:25
-!- johbo(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton02:40
-!- WiesingerF(n=ubuntu@194-208-185-012.tele.net) has left #tryton04:44
-!- yangoon(n=mathiasb@p549F511A.dip.t-dialin.net) has joined #tryton05:19
-!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) has joined #tryton06:08
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton07:03
CIA-48Timitos roundup * #878/problem when creating record and setting inherited record manually: [chatting] you can find the code of the module there: http://mercurial.intuxication.org/hg/product_variant/07:07
CIA-48http://bugs.tryton.org/roundup/issue87807:07
-!- LordVan(n=lordvan@gentoo/developer/LordVan) has joined #tryton08:06
-!- paepke(n=paepke@mail.metaldyne.de) has joined #tryton08:09
-!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) has joined #tryton08:38
-!- racke(n=racke@a89-182-94-28.net-htp.de) has joined #tryton08:41
-!- racke1(n=racke@a89-182-94-28.net-htp.de) has joined #tryton08:46
-!- racke(n=racke@a89-182-72-4.net-htp.de) has joined #tryton09:10
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton09:13
-!- bechamel(n=user@host-85-201-74-27.brutele.be) has joined #tryton09:38
-!- pascal(n=pascal@gruyere.kerlabs.com) has joined #tryton10:02
cedkhttp://bazaar.launchpad.net/%7Eopenerp-commiter/openobject-addons/trunk-extra-addons/files/head%3A/google_translate/10:40
cedkfunny10:40
cedkudono1: hi, did you test the last GroupDAV sync?11:09
-!- carlos(n=carlos@89.7.24.44) has joined #tryton11:30
carlosmorning11:30
carloscedk, bechamel: I have a question about the way you define taxes in account_be11:31
carloscedk, bechamel: Do you have 5-10 minutes to talk about it?11:32
cedkcarlos: ok12:04
carloscedk: From what I saw, you define it only in general, per services, goods, etc...12:22
cedkcarlos: because it is needed for tax reports12:23
carloscedk: I know12:23
carloscedk: however, at least in Spain, it makes more sense to do it as12:23
carlosservices with 7% of VAT, services with 16% of VAT, goods with 7% of VAT, etc..12:24
carlosbecause the VAT percentage depends on the product itself12:24
carlosso I cannot just put all VAT related taxes for services in the services group12:26
carlosbecause when I do the replacement in the party side, which percentage am I going to select if it depends on the product?12:27
carloscedk: am I missing something?12:28
cedkcarlos: you define the default tax on the product12:29
cedkcarlos: so create different group is only needed for rules12:29
carlosand the substitution depends on the group of that default tax12:30
carloslet me put you an example12:30
carlosin Spain, we need to split the purchases/sells done with a company member of our own group of companies from the other companies in Spain12:31
carlosthe VAT applied is exactly the same, is just that the tax report has a different field for it12:32
carlosIf I have two products that such party buys from me, one with 7% of VAT and the other with a 16% of VAT12:32
carloshow am I supposed to configure the rules if all VAT taxes for goods share the same group?12:33
carlosusing your account_be codes, the only group I would have is group_tva_vente_biens12:34
carlosso I'm only able to set either 16% VAT or 7% VAT for that party12:35
carlosno matter which product they buy from me12:35
carlosin the other hand, if you have, for example, group_tva_vente_biens_16 and group_tva_vente_biens_7, this problems disappears12:37
carlosI know this introduces a dependency on the kind of tax in the tax group12:37
carlosbut I really don't see any way to solve this problem12:37
carlosother than what I'm suggesting12:38
cedkcarlos: I think that company groups are an exception so you must extend the rules to use it12:48
carloscedk: we have another example with a surcharge VAT, which adds an extra tax depending on the VAT rate the product has12:50
carloscedk: what do you mean with extend? to use groups like I described  or extending the tax group code?12:50
cedkcarlos: adding code in tax rules12:51
carlosI see12:52
carloscedk: I don't think I will be able to do it right now, so I will keep using my current workaround and think on the code extension later12:55
carloscedk: thanks for your input12:55
cedkcarlos: no need to write too specific stuffs13:05
CIA-48C?dric Krier <ced@b2ck.com> default * 1798:eea22f7da546 trytond/trytond/backend/postgresql/database.py: rollback closing cursor and commit init cursor to have a fresh cursor from the Pool13:14
CIA-48http://hg.tryton.org/trytond/rev/eea22f7da54613:14
CIA-48C?dric Krier <ced@b2ck.com> default * 1799:67edc40055d5 trytond/trytond/protocols/webdav.py:13:14
CIA-48Use one transaction per webdav request13:14
CIA-48Remove the use of baseuri13:14
CIA-48http://hg.tryton.org/trytond/rev/67edc40055d513:14
-!- racke(n=racke@a89-182-72-4.net-htp.de) has left #tryton13:20
udono1Hi all. Did someone have experience with the image widget, relatorio and openoffice? I try the example from relatorio with the image widget of Tryton, but it doesn't work for me.13:35
udono1Oh, I see, it can not work. They need a fileobject and a mimetype to create a Picture in OpenOffice. Maybe it is possible to change the report parser for this...14:02
cedkudono1: I did it14:08
cedkwith: image: (StringIO(decodestring(article.barcode)), 'image/png')14:08
cedkin the Options>Name of the image14:09
udono1cedk: :-) great14:09
cedkudono1: it was sometimes ago, but it must still work14:10
cedkudono1: where article is a BrowseRecord and barcode a function field of type binary14:12
-!- _TiN_(n=TiN@190.189.9.80) has joined #tryton14:18
udono1cedk: yeah, works! Thanks a lot14:18
-!- gremly(n=gremly@190.156.161.162) has joined #tryton14:21
-!- gremly(n=gremly@190.156.161.162) has joined #tryton14:53
-!- woakas(n=woakas@190.144.69.234) has joined #tryton15:15
-!- paepke(n=paepke@imap.metaldyne.de) has joined #tryton15:58
Timitoscedk: hi16:08
Timitoscedk: i would like to prepare the release of the german account chart but there are two points left to discuss16:09
Timitosthe naming of the module and the translation of the root template record of tax rules and tax groups16:10
Timitosi expect that the translation issue could not be solved for 1.2. so i would easily change the name of the two root template records back to german language. for account and account type the english term is ok because the german name is copied from the templates when german language is used while running the wizard16:12
Timitosfor the naming i we should discuss this shortly16:13
Timitosfor me the naming with the iso code in capital letter would be ok, but i am not sure if carlos would agree for this16:16
carlosTimitos: that's also ok for me16:18
Timitoscarlos: great. thx16:18
carlosTimitos: however, I thought it should be always lowercase to follow python policy16:19
carlosalso, the naming issue I raised is not an issue directly for me or people from Spain but for people from other countries that speak spanish too, I already pointed them to the issue, if no one raised any big concern, I will accept whatever you decide :-P16:20
Timitoscarlos: with lowercase we perhaps come into struggling because of the relation to the language codes as you meant in the issue, or don't you think so?16:20
Timitoscarlos: for me it is important that we find an agreement together16:21
carlosTimitos: btw, doesn't the same issue apply to German and Austria?16:21
carlosTimitos: yeah, I see it as a problem, but If we don't reach an agreement, I don't see it as a blocker issue16:22
Timitoscarlos: we planned to create the austria module like this first: account_at_skr0716:22
Timitosso i automaticly started to use iso code16:23
yangooncarlos: for me isocode in lowercase was not the big problem, bit it seemed, that you were concerned about it16:23
Timitosbut i do understand your note to language code and country code16:23
yangooncarlos: to differentiate between language and country16:24
carlosyangoon: I am concerned, because it's not really correct, but I'm not going to block that decision, given that the confusion it introduces doesn't affect me directly and I already warned the people that may be directly affected by that. If there is no agreement on something better, I'm not going to be the one blocking this16:25
Timitosok. so i would recommend to stay with the lower case iso code. there is enough place in the description to point out for what country the module is intended16:25
yangoonTimitos: carlos I don't know about python policy, from the point of view of correct using the isocode, capital letters should be indeed better16:27
yangoonTimitos: carlos OTOH reading the existing module names I never supposed them to be language, but regional descriptions (for charts of accounts)16:30
Timitosyangoon: i think we should have a rule for the naming. regional description is for me not a standard.16:32
yangooncarlos: in which way did you have to prevent people?16:32
yangoonTimitos: language_COUNTRY is a standard, but since we are using only country, I agree with you16:34
carlosyangoon: I didn't have any user confused by the current naming schema, if that's what you mean16:34
yangooncarlos: yes, that was my question16:34
carlosyangoon: I just saw it as a possible problem based on my previous l10n/i18n work at GNOME and Canonical/Ubuntu16:35
carlosyangoon: so I talked about it with people from other countries that speak spanish at #tryton-es16:36
carlosbut they didn't see it as a big deal, otherwise we should have more comments on the tryton's issue we open for this16:36
carlosthat's why I'm not so strong against current schema any more16:37
yangooncarlos: ok, great16:39
Timitosso for me this topic is solved. we stay with the currenct schema16:40
yangoonTimitos: carlos sorry, lastquestion: so should we stay with the current naming schema, or should we point out, that they are chart collections?16:41
carlosaccount_chart_.... ?16:42
carlosor chart_account_....16:42
carlos?16:42
Timitosit is more than the chart16:42
yangoonaccount_charts_16:42
carlosI really don't know... I added 'chart' to the Spanish one16:43
carlosbut as Timitos pointed, is not just a chart16:43
carlosyou have taxes16:43
yangoonthey are also charts16:43
carlosand you may add also some other local specific information16:43
Timitosbut for germany we will not be able to put all necessary adaptions for german accounting into one module because some of them depend on the account chart used and others not.16:43
carlosyangoon: I don't see it as a chart of accounts, at least as it's defined in Spain...16:44
Timitosso i think we will later need a module account_de for all adaptions that are chart independent16:44
carlosTimitos: same thing in Spain16:44
yangoonso exactly for that reason it would be good to point out, in which module are the charts16:45
Timitosyangoon: but for our german module the skr03 does this. everyone is searching for this phrase when he is searching his account chart. or skr04 or ikr if he needs another one16:46
carlosso for our case, we would get account_es (with taxes and things common to all char of accounts) and account_chart_es_abbreviated, account_chart_es_full, etc... ?16:47
Timitoscarlos: taxes depend on the account chart as you need to define the account for the tax.16:47
carlosTimitos: good point... hmm, I should review account_be, I saw something that was not linked to the chart of accounts so that's why I thought about the split too...16:48
Timitosfor the moment i do not need such a module but we should keep the possibility for something like this16:49
carlosyangoon: we cannot put all account charts inside the same module, it takes a lot of time to get that module installed. I already tried it and it's not a good idea, so if we use account_charts_... it should be account_chart_.... in singular16:49
Timitos+116:50
Timitosbut i think it is not needed16:50
yangooncarlos if I say charts, I mean chart of accounts, account types, tax codes, tax rules...16:51
carlosTimitos: maybe you would need it for the Income Statement report (if it needs to be specific for your country)16:51
Timitoscarlos: yes. this could be a part for this module16:51
carlosat least for Spain, I think I don't need one for each chart of accounts, a common one that iterates the tree would be enough16:52
Timitoscarlos: but you will fill a database with unneeded account templates and account type templates. i would always try to separate them. but this is my personal opinion.16:53
carlosTimitos: I'm talking about the report16:54
carlosTimitos: nothing in the database16:54
carlosthe .odt16:54
Timitoscarlos: ah ok. i missed that.16:54
Timitosi thougt you were talking about account charts16:54
carlosyangoon: hmmm, that may be a good argument, but I don't see it as need from the Spanish point of view but I think it's more related with English terminology and my knowledge of it16:54
Timitosi also think that the report itself could be chart independent16:55
carlosTimitos: btw, skr03 means it was changed in 2003 ?16:55
carloswe got a new chart of accounts last year, so I'm thinking on the way I should note it in the Spanish one16:56
Timitoscarlos: no it means special account chart number 3. there is also special account chart number 4 and 7. and some others16:56
yangooncarlos it would just point out, that in such module you only find raw data for all kind of charts related to an accounting schema16:56
carlosTimitos: ok, so that's something like our 'Abbreviated' one16:56
Timitoscarlos: we have also changes in the account chart every year. we will always provide the newest one16:57
carlosyangoon: ok16:57
Timitoscarlos: if somebody needs some special account he can easily create them himself.16:58
carlosTimitos: the same applies in Spain, but usually only for taxes, we got a big review that changed accounts numbers, and the account types16:58
carlosbut that was after 12 years using the same16:59
Timitosok. i think that you should point this out in __tryton__.py16:59
Timitosi think it is not necessary for the module name16:59
Timitosfor later we have all possibilities with the currenct schema.17:00
carlosTimitos: so we should use module version to note such changes, right?17:00
Timitoscarlos: yes17:01
carlosI guess it makes sense... The only problem I see there is if someone wants to migrate an older accounting information into Tryton, it's not possible, without doing some 'magic' (install an old version, create the old chart of accounts, and then install the newer one for future years)17:02
Timitoscarlos: don't forget that you only provide templates. the user decides himself when he wants to update his account chart with the wizard17:02
carlosyeah, that's why I say they need to install an old one17:03
carloscreate a new chart of accounts17:03
carlosand then upgrade to get latest templates for current accounting17:03
Timitosi think this is only an issue if tryton is used by an accountant in account only mode.17:04
Timitosand i think we need to work on tryton for a while to get an accountant to use it for such a case17:05
Timitosand if it would be really needed it would not break the naming schema17:06
yangooncarlos I think it is a major issue to get old accounting data into tryton, we should have historization for accounting data first17:06
Timitoswe could extend it with the year17:06
carloswell, my company's use case would a good example, we used to use tinyerp, when we switch to Tryton, we need old data and the new one. If the switch were done last year (2007 -> 2008) instead of this year (2008-> 2009)17:07
carlosTimitos: the one in tinyerp would be a completely different chart of accounts17:08
carlosso I would need to have both versions, the one to migrate and the new one for this year17:08
carlosyangoon: hmm, do we really need historization ? isn't current templates enough?17:09
carlosyangoon: as far as I know, account data changes only from year to year17:09
carlosso you have it splitted in different fiscal years17:09
Timitoscarlos: yes. this is correct. and if you think this is still an issue for spain i really would provide both versions.17:09
yangooncarlos: in Germany single accounts can have different meanings in different years17:10
Timitosi think it need to be a kind of historization but different from the way account_invoice_history it does17:10
carlosTimitos: Well, it may be an issue, but I'm not going to work on it unless we get a customer that needs it, given that is not common, many companies just keep the old software around until they are allowed to remove that information17:11
carlosTimitos: so I was just pointing that it may be needed, and I guess at that point, we should raise again the point of moving the version to the package name17:12
Timitoscarlos: thats clear for me17:12
Timitoscarlos: yes17:12
carlosyangoon: yeah, that's my point, given that it's different years, you have different fiscal years, and thus, a different set of accounts based on different templates (given that I assume that you upgrade the chart of accounts to get latest templates)17:13
Timitoscarlos: but if you update the chart for the moment the account will also be named in the previos years like it is changed for the new fiscal year. and this is the problem. especially for some export interfaces we plan to develop17:14
carlosTimitos: yeah, I just realise of that17:15
carlosyangoon: sorry, I misunderstood the template upgrade, I just checked that it upgrades all, current and old ones17:15
yangooncarlos: ok17:16
carlosI guess 1.4 should fix that, or opening 2010 would cause problems if you keep using the same database17:16
Timitosi really would be good to have that for 1.417:17
Timitoss/i/it17:17
yangoonTimitos: carlos ack17:17
yangoonTimitos: carlos back to naming: what is your preference?17:17
carlosaccount_charts_countrycode_freetext is ok for me17:23
Timitosi just think of what we had before. maybe there will modules like account_es and account_de for common adaptions. so i think it would be better to leave out the _charts_ part because then all module having to do with one country would be listed together when the list is sorted by module name17:28
Timitosthe other way i maybe would have to search a bit. but in most cases you only would put the correct modules into the module directory but not the others unneeded ones.17:29
yangoonTimitos: ok, good point, and we could possibly name common adaptions like account_es_common, account_de_common to show the difference17:31
Timitosfor me the common would be not necessary because if there is not freetext it is for me common. and i still will check the module description.17:32
Timitosah. but i understand your proposal. i saw this common on many packages.17:33
Timitoswould be ok for me.17:33
Timitosyangoon: carlos: so our proposal would be: account_countrycode_freetext and account_countrycode_common for common modules17:35
Timitos?17:35
yangoonok for me, +117:35
carlosok for me too, however if we have the account_de_common one installed, what's the utility of account_de ?17:37
Timitoscarlos: i think the future name of account_de would be account_de_common. there will be no account_de module then.17:40
carlosok17:41
carlosthat makes more sense, I was confused17:41
Timitoscedk: bechamel: so this is our proposal for naming the country dependent account modules: ´╗┐account_countrycode_freetext and account_countrycode_common for common modules17:43
-!- gremly1(n=gremly@190.156.161.162) has joined #tryton17:44
bechamelimho account_countrycode is implicitly account_countrycode_common (there are no party_common or staock_common, etc)17:45
Timitosbechamel: this is correct. so it is maybe better to leave out the _common and name it only account_countrycode as before. i think there is no much difference.17:50
Timitosbechamel: but many distribution packages are named with this _common way17:51
-!- enlightx(n=enlightx@217.202.53.131) has joined #tryton17:51
bechamelTimitos: cmiiw, from my experience in debian there are *-common package when a meta package is available (emacs is emacs-common and emacs-gtk)17:54
-!- paepke(n=paepke@R9280.r.pppool.de) has joined #tryton17:54
yangoonbechamel: you currently only have account_be and it looks then like a common package17:59
yangoonthere is a difference between common packages to some charts and standalone chart packages18:00
bechamelyangoon: if there is a need of a separate module for a specific account chart (but i don't see why it would be needed)  it's still possible to name it account_xx_specific_chart18:02
Timitosbechamel: so you only have one chart in belgium?18:03
yangoonbechamel: thats not my point: account_de will contain common adaptions for all charts and not contain any chart at all, account_be will contain the charts and is not a common package to others18:05
bechamelTimitos: actually I don't know but one can put several charts in one module18:06
Timitosbechamel: ok. but there are so many possibilities for charts in combination with different ways to relate them to account types. this would be overkill for german module.18:08
Timitosbrb18:10
yangoonbechamel: Timitos and it would be a huge module containing chart types you don't want to use18:10
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton18:11
carlosbechamel: from my own experience, more than one chart of accounts per module is not a good idea, it takes a lot of time to complete, because it's done in a single database transaction and you have a lot of rows18:18
bechamelcarlos: more than the 35000 lines of country.xml ? :)18:19
carlosbechamel: well, right now it's 10326 lines long, but the problem is not only the size, but the cross references it has18:34
Timitosi also have about 10000 lines18:35
Timitosand i don't see any reason why i should put some account charts into my database which i will not need18:36
-!- [pre](n=preCTWO@orkan.Informatik.Uni-Oldenburg.DE) has joined #tryton18:45
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton18:45
-!- _TiN_(n=TiN@190.189.9.80) has joined #tryton18:45
-!- woakas(n=woakas@190.144.69.234) has joined #tryton18:45
-!- bechamel(n=user@host-85-201-74-27.brutele.be) has joined #tryton18:45
-!- udono1(n=udono@dynamic-unidsl-85-197-24-95.westend.de) has joined #tryton18:45
-!- saxa_(n=sasa@host242-95-static.223-217-b.business.telecomitalia.it) has joined #tryton18:45
-!- panthera(n=daniel@static.88-198-196-34.clients.your-server.de) has joined #tryton18:45
-!- CIA-48(n=CIA@208.69.182.149.simpli.biz) has joined #tryton18:46
-!- Timitos(n=Timitos@88.217.184.172) has joined #tryton18:46
-!- gremly(n=gremly@190.156.161.162) has joined #tryton18:46
-!- carlos(n=carlos@89.7.24.44) has joined #tryton18:46
-!- yangoon(n=mathiasb@p549F511A.dip.t-dialin.net) has joined #tryton18:46
-!- ChanServ(ChanServ@services.) has joined #tryton18:46
-!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) has joined #tryton18:57
CIA-48Timitos roundup * #1036/AttributeError: 'Screen' object has no attribute 'views': seems to be related with issue 870 but i also cannot give you a reproducable example for now19:13
CIA-48http://bugs.tryton.org/roundup/issue103619:13
carlosWhy Account Statement module doesn't add a 'New Account Statement' entry to the menu?19:16
-!- gremly(n=gremly@190.156.161.162) has joined #tryton19:21
bechamelcarlos: good question, it's missing19:25
carlosok19:27
CIA-48carlos roundup * #1040/account_statement misses a 'New account statement' menu entry: [new] Right now, the only way to create a new account statement is to open a list of draft, valid, confirmed, and all and then, click over the 'Ne ...19:30
CIA-48http://bugs.tryton.org/roundup/issue104019:30
CIA-48Timitos roundup * #1025/Translation: account.tax.code.template do not appear in ir_translation: @cedk: as this problem blocks the 1.2 release of account_de_skr03 it would be great if we could find a solution for this. i propose to reset the n ...19:31
CIA-48http://bugs.tryton.org/roundup/issue102519:31
CIA-48Bertrand Chenal <bch@b2ck.com> default * 130:88203a815df5 account_statement/statement.xml: Added 'New Statement' menuitem19:31
CIA-48http://hg.tryton.org/modules/account_statement/rev/88203a815df519:31
bechamelcarlos: ^^19:32
carlosbechamel: that's what I call being fast :-P19:32
carlosI filed the bug so I don't forget to add it myself, as soon as I finish with my current work19:33
carlosso it's time to close it :P19:33
carlosbechamel: thanks19:33
carlosbechamel: what's the procedure to get that cherrypicked into 1.2 series so it's included in 1.2.1 release?19:34
bechamelcarlos: I didn't expect that you would be also fast to add it on the tracker :)19:34
carlosIf I don't add it as soon as I know it's a bug, I tend to forget it to do it later... :_D19:35
bechamelcarlos: if it's considered has a bug it will be backported19:35
carlosok19:36
bechamelcarlos: cedk check changelog on trunk from time to time and backport them, and once there is certain amount of fix a new release is made19:38
bechamelcarlos: maybe I should have add "fix" in front of the changelog message19:38
carlosmaybe, yes...19:39
Timitosbechamel: carlos: i thought that only fixes would be backported that do not need a database update. but perhaps i misunderstood something19:40
carlosTimitos: hmm, I would say it makes sense such policy for schema changes or deep db changes19:41
carlosTimitos: otherwise, any translation or .xml change would be seen as 'database update'19:41
carlosdoes it mean no translation update is allowed after 1.2 is released?19:42
Timitoscarlos: yes. i understood a comment of cedk like this. but maybe it is a mistake19:44
bechamelTimitos: yes you are right I always forget this rule19:45
Timitosbechamel: thx19:45
-!- sharkcz(n=dan@plz1-v-4-17.static.adsl.vol.cz) has joined #tryton19:53
carlosbechamel: btw, are we supposed to handle cash movements with account_statement too or is it only useful for bank movements?19:54
Timitoscarlos: you can also use it for cash movements19:55
carloshmm, could we then remove the CASH journal?19:56
carlosno, given that it's part of the base system19:59
Timitosyes. with account_statement the cash journal seems to be not usable. but i do not see a good solution for this problem in the moment.20:00
carlosTimitos: I guess you are using it20:03
carlosright?20:03
Timitoscarlos: i am just in the beginning as i learned many things about the accounting in tryton when testing for 1.220:04
carloswhat would you suggest to me to use it?  We have two bank accounts + cash moves. I'm planning to use 3 Statement Journals linked to the same journal of type statement20:04
carlosTimitos: so we are at the same stage...20:04
carloshmm, terminology is a bit confusing....20:05
Timitoscarlos: your plan sounds good. i would do it the same way20:05
carloscool, at least seems like I'm getting it :P20:07
Timitos:-)20:07
-!- oversize(n=manuel@dslb-094-219-061-234.pools.arcor-ip.net) has joined #tryton21:07
carlosI'm confused, How's that the reference value for account moves created with account_statement is the move date instead of the usual sequence number?21:08
carlosbechamel, cedk: ^^^^21:08
carlosTimitos: did you see the same behaviour?21:09
Timitoscarlos: you are looking one level to high. look into Financial Management-> Entries ->Account Moves. You will find the move with a correct reference value there21:21
Timitossorry. i must correct. what you see on statements are the account move lines but not the account move you expected21:22
carlosTimitos: indeed21:31
carlosalso, I forgot to confirm the moves, so in the journal, the reference was empty, which confused me even more21:31
carlosTimitos: thanks21:31
-!- johbo(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton23:13
-!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) has left #tryton23:51

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