| chat.freenode.net #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(n=mathiasb@p549F49B1.dip.t-dialin.net) 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> http://bugs.tryton.org/roundup/issue1036 | ||
| 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> http://bugs.tryton.org/roundup/issue1039 | ||
| 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> http://bugs.tryton.org/roundup/issue749 | ||
| 2009-05-06 02:40 -!- johbo(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton | ||
| 2009-05-06 04:44 -!- WiesingerF(n=ubuntu@194-208-185-012.tele.net) has left #tryton | ||
| 2009-05-06 05:19 -!- yangoon(n=mathiasb@p549F511A.dip.t-dialin.net) has joined #tryton | ||
| 2009-05-06 06:08 -!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) has joined #tryton | ||
| 2009-05-06 07:03 -!- Timitos(n=Timitos@88.217.184.172) 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: http://mercurial.intuxication.org/hg/product_variant/ | ||
| 2009-05-06 07:07 <CIA-48> http://bugs.tryton.org/roundup/issue878 | ||
| 2009-05-06 08:06 -!- LordVan(n=lordvan@gentoo/developer/LordVan) has joined #tryton | ||
| 2009-05-06 08:09 -!- paepke(n=paepke@mail.metaldyne.de) has joined #tryton | ||
| 2009-05-06 08:38 -!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) has joined #tryton | ||
| 2009-05-06 08:41 -!- racke(n=racke@a89-182-94-28.net-htp.de) has joined #tryton | ||
| 2009-05-06 08:46 -!- racke1(n=racke@a89-182-94-28.net-htp.de) has joined #tryton | ||
| 2009-05-06 09:10 -!- racke(n=racke@a89-182-72-4.net-htp.de) has joined #tryton | ||
| 2009-05-06 09:13 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2009-05-06 09:38 -!- bechamel(n=user@host-85-201-74-27.brutele.be) has joined #tryton | ||
| 2009-05-06 10:02 -!- pascal(n=pascal@gruyere.kerlabs.com) has joined #tryton | ||
| 2009-05-06 10:40 <cedk> http://bazaar.launchpad.net/%7Eopenerp-commiter/openobject-addons/trunk-extra-addons/files/head%3A/google_translate/ | ||
| 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@89.7.24.44) 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 <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 Pool | ||
| 2009-05-06 13:14 <CIA-48> http://hg.tryton.org/trytond/rev/eea22f7da546 | ||
| 2009-05-06 13:14 <CIA-48> C?dric Krier <ced@b2ck.com> default * 1799:67edc40055d5 trytond/trytond/protocols/webdav.py: | ||
| 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> http://hg.tryton.org/trytond/rev/67edc40055d5 | ||
| 2009-05-06 13:20 -!- racke(n=racke@a89-182-72-4.net-htp.de) 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@190.189.9.80) has joined #tryton | ||
| 2009-05-06 14:18 <udono1> cedk: yeah, works! Thanks a lot | ||
| 2009-05-06 14:21 -!- gremly(n=gremly@190.156.161.162) has joined #tryton | ||
| 2009-05-06 14:53 -!- gremly(n=gremly@190.156.161.162) has joined #tryton | ||
| 2009-05-06 15:15 -!- woakas(n=woakas@190.144.69.234) has joined #tryton | ||
| 2009-05-06 15:58 -!- paepke(n=paepke@imap.metaldyne.de) 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 __tryton__.py | ||
| 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@190.156.161.162) 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@217.202.53.131) 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(n=paepke@R9280.r.pppool.de) 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@88.217.184.172) 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@190.189.9.80) has joined #tryton | ||
| 2009-05-06 18:45 -!- woakas(n=woakas@190.144.69.234) has joined #tryton | ||
| 2009-05-06 18:45 -!- bechamel(n=user@host-85-201-74-27.brutele.be) has joined #tryton | ||
| 2009-05-06 18:45 -!- udono1(n=udono@dynamic-unidsl-85-197-24-95.westend.de) has joined #tryton | ||
| 2009-05-06 18:45 -!- saxa_(n=sasa@host242-95-static.223-217-b.business.telecomitalia.it) has joined #tryton | ||
| 2009-05-06 18:45 -!- panthera(n=daniel@static.88-198-196-34.clients.your-server.de) has joined #tryton | ||
| 2009-05-06 18:46 -!- CIA-48(n=CIA@208.69.182.149.simpli.biz) has joined #tryton | ||
| 2009-05-06 18:46 -!- Timitos(n=Timitos@88.217.184.172) has joined #tryton | ||
| 2009-05-06 18:46 -!- gremly(n=gremly@190.156.161.162) has joined #tryton | ||
| 2009-05-06 18:46 -!- carlos(n=carlos@89.7.24.44) has joined #tryton | ||
| 2009-05-06 18:46 -!- yangoon(n=mathiasb@p549F511A.dip.t-dialin.net) has joined #tryton | ||
| 2009-05-06 18:46 -!- ChanServ(ChanServ@services.) has joined #tryton | ||
| 2009-05-06 18:57 -!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) 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> http://bugs.tryton.org/roundup/issue1036 | ||
| 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@190.156.161.162) 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> http://bugs.tryton.org/roundup/issue1040 | ||
| 2009-05-06 19:31 <CIA-48> Timitos 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 ... | ||
| 2009-05-06 19:31 <CIA-48> http://bugs.tryton.org/roundup/issue1025 | ||
| 2009-05-06 19:31 <CIA-48> Bertrand Chenal <bch@b2ck.com> default * 130:88203a815df5 account_statement/statement.xml: Added 'New Statement' menuitem | ||
| 2009-05-06 19:31 <CIA-48> http://hg.tryton.org/modules/account_statement/rev/88203a815df5 | ||
| 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(n=dan@plz1-v-4-17.static.adsl.vol.cz) 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(n=manuel@dslb-094-219-061-234.pools.arcor-ip.net) 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(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton | ||
| 2009-05-06 23:51 -!- vengfulsquirrel(n=ian@c-67-160-236-234.hsd1.ca.comcast.net) has left #tryton |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!