IRC logs of #tryton for Wednesday, 2009-05-06 #tryton log beginning Wed May 6 00:00:02 CEST 2009
2009-05-06 00:17 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton
2009-05-06 00:17 -!- yangoon1( has joined #tryton
2009-05-06 00:20 <CIA-48> ced roundup * #1036/AttributeError: 'Screen' object has no attribute 'views': [need-eg] I could not succeed to reproduce the issue.
2009-05-06 00:20 <CIA-48>
2009-05-06 00:23 <CIA-48> ced 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 ...
2009-05-06 00:23 <CIA-48>
2009-05-06 01:25 <CIA-48> matb roundup * #749/Website: distribution packages: [closed] Closed, because meanwhile outdated, partially solved and partially superseeded by issue914.
2009-05-06 01:25 <CIA-48>
2009-05-06 02:40 -!- johbo( has joined #tryton
2009-05-06 04:44 -!- WiesingerF( has left #tryton
2009-05-06 05:19 -!- yangoon( has joined #tryton
2009-05-06 06:08 -!- vengfulsquirrel( has joined #tryton
2009-05-06 07:03 -!- Timitos(n=Timitos@ has joined #tryton
2009-05-06 07:07 <CIA-48> Timitos roundup * #878/problem when creating record and setting inherited record manually: [chatting] you can find the code of the module there:
2009-05-06 07:07 <CIA-48>
2009-05-06 08:06 -!- LordVan(n=lordvan@gentoo/developer/LordVan) has joined #tryton
2009-05-06 08:09 -!- paepke( has joined #tryton
2009-05-06 08:38 -!- vengfulsquirrel( has joined #tryton
2009-05-06 08:41 -!- racke( has joined #tryton
2009-05-06 08:46 -!- racke1( has joined #tryton
2009-05-06 09:10 -!- racke( has joined #tryton
2009-05-06 09:13 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton
2009-05-06 09:38 -!- bechamel( has joined #tryton
2009-05-06 10:02 -!- pascal( has joined #tryton
2009-05-06 10:40 <cedk>
2009-05-06 10:40 <cedk> funny
2009-05-06 11:09 <cedk> udono1: hi, did you test the last GroupDAV sync?
2009-05-06 11:30 -!- carlos(n=carlos@ has joined #tryton
2009-05-06 11:30 <carlos> morning
2009-05-06 11:31 <carlos> cedk, bechamel: I have a question about the way you define taxes in account_be
2009-05-06 11:32 <carlos> cedk, bechamel: Do you have 5-10 minutes to talk about it?
2009-05-06 12:04 <cedk> carlos: ok
2009-05-06 12:22 <carlos> cedk: From what I saw, you define it only in general, per services, goods, etc...
2009-05-06 12:23 <cedk> carlos: because it is needed for tax reports
2009-05-06 12:23 <carlos> cedk: I know
2009-05-06 12:23 <carlos> cedk: however, at least in Spain, it makes more sense to do it as
2009-05-06 12:24 <carlos> services with 7% of VAT, services with 16% of VAT, goods with 7% of VAT, etc..
2009-05-06 12:24 <carlos> because the VAT percentage depends on the product itself
2009-05-06 12:26 <carlos> so I cannot just put all VAT related taxes for services in the services group
2009-05-06 12:27 <carlos> because when I do the replacement in the party side, which percentage am I going to select if it depends on the product?
2009-05-06 12:28 <carlos> cedk: am I missing something?
2009-05-06 12:29 <cedk> carlos: you define the default tax on the product
2009-05-06 12:29 <cedk> carlos: so create different group is only needed for rules
2009-05-06 12:30 <carlos> and the substitution depends on the group of that default tax
2009-05-06 12:30 <carlos> let me put you an example
2009-05-06 12:31 <carlos> in Spain, we need to split the purchases/sells done with a company member of our own group of companies from the other companies in Spain
2009-05-06 12:32 <carlos> the VAT applied is exactly the same, is just that the tax report has a different field for it
2009-05-06 12:32 <carlos> If I have two products that such party buys from me, one with 7% of VAT and the other with a 16% of VAT
2009-05-06 12:33 <carlos> how am I supposed to configure the rules if all VAT taxes for goods share the same group?
2009-05-06 12:34 <carlos> using your account_be codes, the only group I would have is group_tva_vente_biens
2009-05-06 12:35 <carlos> so I'm only able to set either 16% VAT or 7% VAT for that party
2009-05-06 12:35 <carlos> no matter which product they buy from me
2009-05-06 12:37 <carlos> in the other hand, if you have, for example, group_tva_vente_biens_16 and group_tva_vente_biens_7, this problems disappears
2009-05-06 12:37 <carlos> I know this introduces a dependency on the kind of tax in the tax group
2009-05-06 12:37 <carlos> but I really don't see any way to solve this problem
2009-05-06 12:38 <carlos> other than what I'm suggesting
2009-05-06 12:48 <cedk> carlos: I think that company groups are an exception so you must extend the rules to use it
2009-05-06 12:50 <carlos> cedk: we have another example with a surcharge VAT, which adds an extra tax depending on the VAT rate the product has
2009-05-06 12:50 <carlos> cedk: what do you mean with extend? to use groups like I described or extending the tax group code?
2009-05-06 12:51 <cedk> carlos: adding code in tax rules
2009-05-06 12:52 <carlos> I see
2009-05-06 12:55 <carlos> cedk: 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 later
2009-05-06 12:55 <carlos> cedk: thanks for your input
2009-05-06 13:05 <cedk> carlos: no need to write too specific stuffs
2009-05-06 13:14 <CIA-48> C?dric Krier <> default * 1798:eea22f7da546 trytond/trytond/backend/postgresql/ rollback closing cursor and commit init cursor to have a fresh cursor from the Pool
2009-05-06 13:14 <CIA-48>
2009-05-06 13:14 <CIA-48> C?dric Krier <> default * 1799:67edc40055d5 trytond/trytond/protocols/
2009-05-06 13:14 <CIA-48> Use one transaction per webdav request
2009-05-06 13:14 <CIA-48> Remove the use of baseuri
2009-05-06 13:14 <CIA-48>
2009-05-06 13:20 -!- racke( has left #tryton
2009-05-06 13:35 <udono1> Hi 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.
2009-05-06 14:02 <udono1> Oh, 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...
2009-05-06 14:08 <cedk> udono1: I did it
2009-05-06 14:08 <cedk> with: image: (StringIO(decodestring(article.barcode)), 'image/png')
2009-05-06 14:09 <cedk> in the Options>Name of the image
2009-05-06 14:09 <udono1> cedk: :-) great
2009-05-06 14:10 <cedk> udono1: it was sometimes ago, but it must still work
2009-05-06 14:12 <cedk> udono1: where article is a BrowseRecord and barcode a function field of type binary
2009-05-06 14:18 -!- _TiN_(n=TiN@ has joined #tryton
2009-05-06 14:18 <udono1> cedk: yeah, works! Thanks a lot
2009-05-06 14:21 -!- gremly(n=gremly@ has joined #tryton
2009-05-06 14:53 -!- gremly(n=gremly@ has joined #tryton
2009-05-06 15:15 -!- woakas(n=woakas@ has joined #tryton
2009-05-06 15:58 -!- paepke( has joined #tryton
2009-05-06 16:08 <Timitos> cedk: hi
2009-05-06 16:09 <Timitos> cedk: i would like to prepare the release of the german account chart but there are two points left to discuss
2009-05-06 16:10 <Timitos> the naming of the module and the translation of the root template record of tax rules and tax groups
2009-05-06 16:12 <Timitos> i 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 wizard
2009-05-06 16:13 <Timitos> for the naming i we should discuss this shortly
2009-05-06 16:16 <Timitos> for me the naming with the iso code in capital letter would be ok, but i am not sure if carlos would agree for this
2009-05-06 16:18 <carlos> Timitos: that's also ok for me
2009-05-06 16:18 <Timitos> carlos: great. thx
2009-05-06 16:19 <carlos> Timitos: however, I thought it should be always lowercase to follow python policy
2009-05-06 16:20 <carlos> also, 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 :-P
2009-05-06 16:20 <Timitos> carlos: 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?
2009-05-06 16:21 <Timitos> carlos: for me it is important that we find an agreement together
2009-05-06 16:21 <carlos> Timitos: btw, doesn't the same issue apply to German and Austria?
2009-05-06 16:22 <carlos> Timitos: yeah, I see it as a problem, but If we don't reach an agreement, I don't see it as a blocker issue
2009-05-06 16:22 <Timitos> carlos: we planned to create the austria module like this first: account_at_skr07
2009-05-06 16:23 <Timitos> so i automaticly started to use iso code
2009-05-06 16:23 <yangoon> carlos: for me isocode in lowercase was not the big problem, bit it seemed, that you were concerned about it
2009-05-06 16:23 <Timitos> but i do understand your note to language code and country code
2009-05-06 16:24 <yangoon> carlos: to differentiate between language and country
2009-05-06 16:25 <carlos> yangoon: 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 this
2009-05-06 16:25 <Timitos> ok. 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 intended
2009-05-06 16:27 <yangoon> Timitos: carlos I don't know about python policy, from the point of view of correct using the isocode, capital letters should be indeed better
2009-05-06 16:30 <yangoon> Timitos: carlos OTOH reading the existing module names I never supposed them to be language, but regional descriptions (for charts of accounts)
2009-05-06 16:32 <Timitos> yangoon: i think we should have a rule for the naming. regional description is for me not a standard.
2009-05-06 16:32 <yangoon> carlos: in which way did you have to prevent people?
2009-05-06 16:34 <yangoon> Timitos: language_COUNTRY is a standard, but since we are using only country, I agree with you
2009-05-06 16:34 <carlos> yangoon: I didn't have any user confused by the current naming schema, if that's what you mean
2009-05-06 16:34 <yangoon> carlos: yes, that was my question
2009-05-06 16:35 <carlos> yangoon: I just saw it as a possible problem based on my previous l10n/i18n work at GNOME and Canonical/Ubuntu
2009-05-06 16:36 <carlos> yangoon: so I talked about it with people from other countries that speak spanish at #tryton-es
2009-05-06 16:36 <carlos> but they didn't see it as a big deal, otherwise we should have more comments on the tryton's issue we open for this
2009-05-06 16:37 <carlos> that's why I'm not so strong against current schema any more
2009-05-06 16:39 <yangoon> carlos: ok, great
2009-05-06 16:40 <Timitos> so for me this topic is solved. we stay with the currenct schema
2009-05-06 16:41 <yangoon> Timitos: carlos sorry, lastquestion: so should we stay with the current naming schema, or should we point out, that they are chart collections?
2009-05-06 16:42 <carlos> account_chart_.... ?
2009-05-06 16:42 <carlos> or chart_account_....
2009-05-06 16:42 <carlos> ?
2009-05-06 16:42 <Timitos> it is more than the chart
2009-05-06 16:42 <yangoon> account_charts_
2009-05-06 16:43 <carlos> I really don't know... I added 'chart' to the Spanish one
2009-05-06 16:43 <carlos> but as Timitos pointed, is not just a chart
2009-05-06 16:43 <carlos> you have taxes
2009-05-06 16:43 <yangoon> they are also charts
2009-05-06 16:43 <carlos> and you may add also some other local specific information
2009-05-06 16:43 <Timitos> but 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.
2009-05-06 16:44 <carlos> yangoon: I don't see it as a chart of accounts, at least as it's defined in Spain...
2009-05-06 16:44 <Timitos> so i think we will later need a module account_de for all adaptions that are chart independent
2009-05-06 16:44 <carlos> Timitos: same thing in Spain
2009-05-06 16:45 <yangoon> so exactly for that reason it would be good to point out, in which module are the charts
2009-05-06 16:46 <Timitos> yangoon: 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 one
2009-05-06 16:47 <carlos> so 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... ?
2009-05-06 16:47 <Timitos> carlos: taxes depend on the account chart as you need to define the account for the tax.
2009-05-06 16:48 <carlos> Timitos: 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...
2009-05-06 16:49 <Timitos> for the moment i do not need such a module but we should keep the possibility for something like this
2009-05-06 16:49 <carlos> yangoon: 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 singular
2009-05-06 16:50 <Timitos> +1
2009-05-06 16:50 <Timitos> but i think it is not needed
2009-05-06 16:51 <yangoon> carlos if I say charts, I mean chart of accounts, account types, tax codes, tax rules...
2009-05-06 16:51 <carlos> Timitos: maybe you would need it for the Income Statement report (if it needs to be specific for your country)
2009-05-06 16:51 <Timitos> carlos: yes. this could be a part for this module
2009-05-06 16:52 <carlos> at least for Spain, I think I don't need one for each chart of accounts, a common one that iterates the tree would be enough
2009-05-06 16:53 <Timitos> carlos: 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.
2009-05-06 16:54 <carlos> Timitos: I'm talking about the report
2009-05-06 16:54 <carlos> Timitos: nothing in the database
2009-05-06 16:54 <carlos> the .odt
2009-05-06 16:54 <Timitos> carlos: ah ok. i missed that.
2009-05-06 16:54 <Timitos> i thougt you were talking about account charts
2009-05-06 16:54 <carlos> yangoon: 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 it
2009-05-06 16:55 <Timitos> i also think that the report itself could be chart independent
2009-05-06 16:55 <carlos> Timitos: btw, skr03 means it was changed in 2003 ?
2009-05-06 16:56 <carlos> we got a new chart of accounts last year, so I'm thinking on the way I should note it in the Spanish one
2009-05-06 16:56 <Timitos> carlos: no it means special account chart number 3. there is also special account chart number 4 and 7. and some others
2009-05-06 16:56 <yangoon> carlos it would just point out, that in such module you only find raw data for all kind of charts related to an accounting schema
2009-05-06 16:56 <carlos> Timitos: ok, so that's something like our 'Abbreviated' one
2009-05-06 16:57 <Timitos> carlos: we have also changes in the account chart every year. we will always provide the newest one
2009-05-06 16:57 <carlos> yangoon: ok
2009-05-06 16:58 <Timitos> carlos: if somebody needs some special account he can easily create them himself.
2009-05-06 16:58 <carlos> Timitos: the same applies in Spain, but usually only for taxes, we got a big review that changed accounts numbers, and the account types
2009-05-06 16:59 <carlos> but that was after 12 years using the same
2009-05-06 16:59 <Timitos> ok. i think that you should point this out in
2009-05-06 16:59 <Timitos> i think it is not necessary for the module name
2009-05-06 17:00 <Timitos> for later we have all possibilities with the currenct schema.
2009-05-06 17:00 <carlos> Timitos: so we should use module version to note such changes, right?
2009-05-06 17:01 <Timitos> carlos: yes
2009-05-06 17:02 <carlos> I 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)
2009-05-06 17:02 <Timitos> carlos: don't forget that you only provide templates. the user decides himself when he wants to update his account chart with the wizard
2009-05-06 17:03 <carlos> yeah, that's why I say they need to install an old one
2009-05-06 17:03 <carlos> create a new chart of accounts
2009-05-06 17:03 <carlos> and then upgrade to get latest templates for current accounting
2009-05-06 17:04 <Timitos> i think this is only an issue if tryton is used by an accountant in account only mode.
2009-05-06 17:05 <Timitos> and i think we need to work on tryton for a while to get an accountant to use it for such a case
2009-05-06 17:06 <Timitos> and if it would be really needed it would not break the naming schema
2009-05-06 17:06 <yangoon> carlos I think it is a major issue to get old accounting data into tryton, we should have historization for accounting data first
2009-05-06 17:06 <Timitos> we could extend it with the year
2009-05-06 17:07 <carlos> well, 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)
2009-05-06 17:08 <carlos> Timitos: the one in tinyerp would be a completely different chart of accounts
2009-05-06 17:08 <carlos> so I would need to have both versions, the one to migrate and the new one for this year
2009-05-06 17:09 <carlos> yangoon: hmm, do we really need historization ? isn't current templates enough?
2009-05-06 17:09 <carlos> yangoon: as far as I know, account data changes only from year to year
2009-05-06 17:09 <carlos> so you have it splitted in different fiscal years
2009-05-06 17:09 <Timitos> carlos: yes. this is correct. and if you think this is still an issue for spain i really would provide both versions.
2009-05-06 17:10 <yangoon> carlos: in Germany single accounts can have different meanings in different years
2009-05-06 17:10 <Timitos> i think it need to be a kind of historization but different from the way account_invoice_history it does
2009-05-06 17:11 <carlos> Timitos: 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 information
2009-05-06 17:12 <carlos> Timitos: 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 name
2009-05-06 17:12 <Timitos> carlos: thats clear for me
2009-05-06 17:12 <Timitos> carlos: yes
2009-05-06 17:13 <carlos> yangoon: 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)
2009-05-06 17:14 <Timitos> carlos: 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 develop
2009-05-06 17:15 <carlos> Timitos: yeah, I just realise of that
2009-05-06 17:15 <carlos> yangoon: sorry, I misunderstood the template upgrade, I just checked that it upgrades all, current and old ones
2009-05-06 17:16 <yangoon> carlos: ok
2009-05-06 17:16 <carlos> I guess 1.4 should fix that, or opening 2010 would cause problems if you keep using the same database
2009-05-06 17:17 <Timitos> i really would be good to have that for 1.4
2009-05-06 17:17 <Timitos> s/i/it
2009-05-06 17:17 <yangoon> Timitos: carlos ack
2009-05-06 17:17 <yangoon> Timitos: carlos back to naming: what is your preference?
2009-05-06 17:23 <carlos> account_charts_countrycode_freetext is ok for me
2009-05-06 17:28 <Timitos> i 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 name
2009-05-06 17:29 <Timitos> the 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.
2009-05-06 17:31 <yangoon> Timitos: ok, good point, and we could possibly name common adaptions like account_es_common, account_de_common to show the difference
2009-05-06 17:32 <Timitos> for 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.
2009-05-06 17:33 <Timitos> ah. but i understand your proposal. i saw this common on many packages.
2009-05-06 17:33 <Timitos> would be ok for me.
2009-05-06 17:35 <Timitos> yangoon: carlos: so our proposal would be: account_countrycode_freetext and account_countrycode_common for common modules
2009-05-06 17:35 <Timitos> ?
2009-05-06 17:35 <yangoon> ok for me, +1
2009-05-06 17:37 <carlos> ok for me too, however if we have the account_de_common one installed, what's the utility of account_de ?
2009-05-06 17:40 <Timitos> carlos: i think the future name of account_de would be account_de_common. there will be no account_de module then.
2009-05-06 17:41 <carlos> ok
2009-05-06 17:41 <carlos> that makes more sense, I was confused
2009-05-06 17:43 <Timitos> cedk: bechamel: so this is our proposal for naming the country dependent account modules: ´╗┐account_countrycode_freetext and account_countrycode_common for common modules
2009-05-06 17:44 -!- gremly1(n=gremly@ has joined #tryton
2009-05-06 17:45 <bechamel> imho account_countrycode is implicitly account_countrycode_common (there are no party_common or staock_common, etc)
2009-05-06 17:50 <Timitos> bechamel: 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.
2009-05-06 17:51 <Timitos> bechamel: but many distribution packages are named with this _common way
2009-05-06 17:51 -!- enlightx(n=enlightx@ has joined #tryton
2009-05-06 17:54 <bechamel> Timitos: cmiiw, from my experience in debian there are *-common package when a meta package is available (emacs is emacs-common and emacs-gtk)
2009-05-06 17:54 -!- paepke( has joined #tryton
2009-05-06 17:59 <yangoon> bechamel: you currently only have account_be and it looks then like a common package
2009-05-06 18:00 <yangoon> there is a difference between common packages to some charts and standalone chart packages
2009-05-06 18:02 <bechamel> yangoon: 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_chart
2009-05-06 18:03 <Timitos> bechamel: so you only have one chart in belgium?
2009-05-06 18:05 <yangoon> bechamel: 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 others
2009-05-06 18:06 <bechamel> Timitos: actually I don't know but one can put several charts in one module
2009-05-06 18:08 <Timitos> bechamel: 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.
2009-05-06 18:10 <Timitos> brb
2009-05-06 18:10 <yangoon> bechamel: Timitos and it would be a huge module containing chart types you don't want to use
2009-05-06 18:11 -!- Timitos(n=Timitos@ has joined #tryton
2009-05-06 18:18 <carlos> bechamel: 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 rows
2009-05-06 18:19 <bechamel> carlos: more than the 35000 lines of country.xml ? :)
2009-05-06 18:34 <carlos> bechamel: well, right now it's 10326 lines long, but the problem is not only the size, but the cross references it has
2009-05-06 18:35 <Timitos> i also have about 10000 lines
2009-05-06 18:36 <Timitos> and i don't see any reason why i should put some account charts into my database which i will not need
2009-05-06 18:45 -!- [pre](n=preCTWO@orkan.Informatik.Uni-Oldenburg.DE) has joined #tryton
2009-05-06 18:45 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton
2009-05-06 18:45 -!- _TiN_(n=TiN@ has joined #tryton
2009-05-06 18:45 -!- woakas(n=woakas@ has joined #tryton
2009-05-06 18:45 -!- bechamel( has joined #tryton
2009-05-06 18:45 -!- udono1( has joined #tryton
2009-05-06 18:45 -!- saxa_( has joined #tryton
2009-05-06 18:45 -!- panthera( has joined #tryton
2009-05-06 18:46 -!- CIA-48( has joined #tryton
2009-05-06 18:46 -!- Timitos(n=Timitos@ has joined #tryton
2009-05-06 18:46 -!- gremly(n=gremly@ has joined #tryton
2009-05-06 18:46 -!- carlos(n=carlos@ has joined #tryton
2009-05-06 18:46 -!- yangoon( has joined #tryton
2009-05-06 18:46 -!- ChanServ(ChanServ@services.) has joined #tryton
2009-05-06 18:57 -!- vengfulsquirrel( has joined #tryton
2009-05-06 19:13 <CIA-48> Timitos 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 now
2009-05-06 19:13 <CIA-48>
2009-05-06 19:16 <carlos> Why Account Statement module doesn't add a 'New Account Statement' entry to the menu?
2009-05-06 19:21 -!- gremly(n=gremly@ has joined #tryton
2009-05-06 19:25 <bechamel> carlos: good question, it's missing
2009-05-06 19:27 <carlos> ok
2009-05-06 19:30 <CIA-48> carlos 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 ...
2009-05-06 19:30 <CIA-48>
2009-05-06 19:31 <CIA-48> Timitos roundup * #1025/Translation: 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 ...
2009-05-06 19:31 <CIA-48>
2009-05-06 19:31 <CIA-48> Bertrand Chenal <> default * 130:88203a815df5 account_statement/statement.xml: Added 'New Statement' menuitem
2009-05-06 19:31 <CIA-48>
2009-05-06 19:32 <bechamel> carlos: ^^
2009-05-06 19:32 <carlos> bechamel: that's what I call being fast :-P
2009-05-06 19:33 <carlos> I filed the bug so I don't forget to add it myself, as soon as I finish with my current work
2009-05-06 19:33 <carlos> so it's time to close it :P
2009-05-06 19:33 <carlos> bechamel: thanks
2009-05-06 19:34 <carlos> bechamel: what's the procedure to get that cherrypicked into 1.2 series so it's included in 1.2.1 release?
2009-05-06 19:34 <bechamel> carlos: I didn't expect that you would be also fast to add it on the tracker :)
2009-05-06 19:35 <carlos> If I don't add it as soon as I know it's a bug, I tend to forget it to do it later... :_D
2009-05-06 19:35 <bechamel> carlos: if it's considered has a bug it will be backported
2009-05-06 19:36 <carlos> ok
2009-05-06 19:38 <bechamel> carlos: cedk check changelog on trunk from time to time and backport them, and once there is certain amount of fix a new release is made
2009-05-06 19:38 <bechamel> carlos: maybe I should have add "fix" in front of the changelog message
2009-05-06 19:39 <carlos> maybe, yes...
2009-05-06 19:40 <Timitos> bechamel: carlos: i thought that only fixes would be backported that do not need a database update. but perhaps i misunderstood something
2009-05-06 19:41 <carlos> Timitos: hmm, I would say it makes sense such policy for schema changes or deep db changes
2009-05-06 19:41 <carlos> Timitos: otherwise, any translation or .xml change would be seen as 'database update'
2009-05-06 19:42 <carlos> does it mean no translation update is allowed after 1.2 is released?
2009-05-06 19:44 <Timitos> carlos: yes. i understood a comment of cedk like this. but maybe it is a mistake
2009-05-06 19:45 <bechamel> Timitos: yes you are right I always forget this rule
2009-05-06 19:45 <Timitos> bechamel: thx
2009-05-06 19:53 -!- sharkcz( has joined #tryton
2009-05-06 19:54 <carlos> bechamel: btw, are we supposed to handle cash movements with account_statement too or is it only useful for bank movements?
2009-05-06 19:55 <Timitos> carlos: you can also use it for cash movements
2009-05-06 19:56 <carlos> hmm, could we then remove the CASH journal?
2009-05-06 19:59 <carlos> no, given that it's part of the base system
2009-05-06 20:00 <Timitos> yes. 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.
2009-05-06 20:03 <carlos> Timitos: I guess you are using it
2009-05-06 20:03 <carlos> right?
2009-05-06 20:04 <Timitos> carlos: i am just in the beginning as i learned many things about the accounting in tryton when testing for 1.2
2009-05-06 20:04 <carlos> what 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 statement
2009-05-06 20:04 <carlos> Timitos: so we are at the same stage...
2009-05-06 20:05 <carlos> hmm, terminology is a bit confusing....
2009-05-06 20:05 <Timitos> carlos: your plan sounds good. i would do it the same way
2009-05-06 20:07 <carlos> cool, at least seems like I'm getting it :P
2009-05-06 20:07 <Timitos> :-)
2009-05-06 21:07 -!- oversize( has joined #tryton
2009-05-06 21:08 <carlos> I'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?
2009-05-06 21:08 <carlos> bechamel, cedk: ^^^^
2009-05-06 21:09 <carlos> Timitos: did you see the same behaviour?
2009-05-06 21:21 <Timitos> carlos: you are looking one level to high. look into Financial Management-> Entries ->Account Moves. You will find the move with a correct reference value there
2009-05-06 21:22 <Timitos> sorry. i must correct. what you see on statements are the account move lines but not the account move you expected
2009-05-06 21:31 <carlos> Timitos: indeed
2009-05-06 21:31 <carlos> also, I forgot to confirm the moves, so in the journal, the reference was empty, which confused me even more
2009-05-06 21:31 <carlos> Timitos: thanks
2009-05-06 23:13 -!- johbo( has joined #tryton
2009-05-06 23:51 -!- vengfulsquirrel( has left #tryton

Generated by 2.17.3 by Marius Gedminas - find it at!