IRC logs of #tryton for Friday, 2008-07-25 #tryton log beginning Fri Jul 25 00:00:02 CEST 2008
-!- beta_max(i=betamax@gateway/tor/x-589dba96ca2cb922) has joined #tryton05:28
-!- Timitos(n=Timitos@ has joined #tryton08:01
CIA-53tryton: Timitos roundup * #212/Re-Open Journals - Periods seems not to work: [new] I closed and reopened a period. Then I noticed that all Journals-Periods of this period where still closed. Then I tried to reopen a journal ...08:23
CIA-53tryton: Timitos roundup * #213/Bank Statements inverted: [new] when entering statements debit and credit are inverted. for expample: for a negative value (company is paying) bank account must have value ...08:33
CIA-53tryton: Timitos roundup * #214/IndexError: list index out of range: [new] Traceback (most recent call last): File "/tryton/gui/window/view_form/view/form_gtk/", line 105, in _sig_remove self.scree ...08:34
CIA-53tryton: Timitos roundup * #214/IndexError: list index out of range: [chatting] this error occurs if i click on "remove" in many2many-widget without selecting a record before. perhaps the behavior could be changed ...08:37
CIA-53tryton: Timitos roundup * #215/tax computation of invoice and purchase is different: [new] perhaps rounding is not optimized in purchase module08:40
CIA-53tryton: Timitos roundup * #216/cannot add line in purchase in existing and updated database: [new] cursor jumps to product field if i try to add a purchase line, but there is no error and no line is created. i added a backup of my db08:53
-!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton08:57
FWiesingcedk: I update my system - now it works09:28
cedkFWiesing: ok you can close the issue09:30
-!- bechamel( has joined #tryton09:59
CIA-53tryton: C?dric Krier <> default * 159:2ec5a0a6a0b6 account/ Fix re-open journal-period for issue21210:10
CIA-53tryton: C?dric Krier <> default * 160:7c17d73057dc account/: merge10:10
CIA-53tryton: ced roundup * #212/Re-Open Journals - Periods seems not to work: [resolved] Fix with changeset 2ec5a0a6a0b610:10
CIA-53tryton: C?dric Krier <> default * 45:2e6141f89399 account_statement/ Invert debit/credit in statement for issue21310:18
CIA-53tryton: ced roundup * #213/Bank Statements inverted: [resolved] Fix with changeset 2e6141f8939910:19
cedkbechamel: why objects in account_statement are named instead of ?10:20
CIA-53tryton: C?dric Krier <> default * 556:f1bc9c2efd2f tryton/tryton/gui/window/view_form/screen/ Fix screen remove when there is no row selected for issue21410:26
CIA-53tryton: ced roundup * #214/IndexError: list index out of range: Fix with changeset f1bc9c2efd2f I don't make it to remove the only record if there is only one, and don't like to have this kind of implicit behavior.10:27
CIA-53tryton: htgoebel roundup * #193/printing as pdf fails: This is obviously a problem of your or openoffice.interact installation. As I'm the developer of both openoffice.interact and tryto ...10:43
bechamelcedk: it's an error10:46
cedkbechamel: ok I will fix10:46
CIA-53tryton: htgoebel roundup * #193/printing as pdf fails: [resolved] since this is a problem of openoffice.interact, I'll close this issue fpor tryton. Reporter: If you find any problems, please report t ...10:51
-!- kultviech( has joined #tryton10:55
CIA-53tryton: C?dric Krier <> default * 7:d17a08331453 analytic_invoice/invoice.xml: Use name analytic_accounts for group10:56
CIA-53tryton: C?dric Krier <> default * 8:fd0292fbc198 analytic_invoice/
CIA-53tryton: Remove required on analytic_accounts10:56
CIA-53tryton: Fix interger ids for write/unlink10:56
CIA-53tryton: C?dric Krier <> default * 7:5ed929f0ed36 analytic_purchase/
CIA-53tryton: Remove required on analytic_accounts for issue21610:56
CIA-53tryton: Fix integer ids in write/unlink10:56
CIA-53tryton: ced roundup * #216/cannot add line in purchase in existing and updated database: [resolved] Fix with changeset 5ed929f0ed36 I drop the not null constraints on analytic_accounts so you must update your database manually.10:58
cedkTimitos: ping11:13
cedkfor issue215 I find the problem11:19
cedkbut I don't know which solution is right11:19
cedkon the purchase we round the result of the computation of taxes on each purchase lines and once globaly11:20
cedkon the invoice we round only once globaly11:20
cedkso what do you think guys?11:21
cedkI think I will round on each line because we need to write the tax amount of each line in the accounting for tax report11:27
cedkbut so what we have is tax: 7%, base: 700, amout: 48.9711:30
cedkis it a problem?11:30
cedkbechamel: ping11:33
bechamelcedk: i was always told that each line must be rounded11:43
bechamelcedk: iirc, on a legal point of view both are ok, isn't it ?11:50
cedkbechamel: yes but it can be strange to have the line above 7% 700 48.9711:51
bechamelcedk: and also the way the rouding is made is also ok (as long as there is less than one cent of difference)11:52
cedkbecause it is different from 0.0311:52
cedkor 0.0211:52
cedkit is because we have rounding 12 lines so 12 * 0.005 =0.0611:53
cedkthese is the maximum error we can have11:54
bechamelcedk: one can imagine rouding each line _and_ rounding the total with respect to the non-rouded lines11:54
cedkbut we will have difference between the amount in the account line and the amount in the tax charts11:55
cedkI think this is wrong11:55
bechamelso finaly the purchase is ok but not the invoice11:56
cedkthe only problems that I see it is that the 48.97 is not wrong but it can look wrong, so we will have many reports about the fact that tryton doesn't compute right11:57
cedkyes invoice will generate amount in account line that doesn't match the amount in the tax report11:58
cedkso I will fix the invoice and round each lines12:02
CIA-53tryton: C?dric Krier <> default * 80:3e47bd68dcad account_invoice/ Round base and tax amount on each lines of invoice for issue21512:03
-!- udono( has joined #tryton12:04
CIA-53tryton: ced roundup * #215/tax computation of invoice and purchase is different: [resolved] Fix with changeset 3e47bd68dcad12:04
udonohi all12:04
FWiesingudono: hi12:10
udonohi FWiesing12:10
-!- markusleist( has joined #tryton12:16
-!- kultviech( has left #tryton12:48
CIA-53tryton: C?dric Krier <> default * 753:7f92b13001dc trytond/trytond/ (21 files in 10 dirs): Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 161:194a4266b73a account/ (8 files): Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 81:9405bb22f675 account_invoice/ ( invoice.xml): Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 46:7f9a12af2139 account_statement/ (journal.xml statement.xml): Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 14:b8a7e7456c1a analytic_account/account.xml: Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 9:0cbe18714397 analytic_invoice/ Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 8:0bd3690ce4d0 analytic_purchase/ Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 10:392150302682 currency/currency.xml: Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 62:00b7bf83fbfe product/ (category.xml product.xml uom.xml): Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 9:0cdba91dfda0 project/work.xml: Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 46:acbee1d25f29 purchase/purchase.xml: Change unlink to delete for issue20112:52
CIA-53tryton: C?dric Krier <> default * 112:d479bd1b4b50 relationship/ (category.xml country.xml party.xml): Change unlink to delete for issue20112:53
CIA-53tryton: C?dric Krier <> default * 171:ac1b67337f0f stock/ (location.xml Change unlink to delete for issue20112:53
CIA-53tryton: C?dric Krier <> default * 36:3ff5b7cdd34e timesheet/work.xml: Change unlink to delete for issue20112:53
CIA-53tryton: C?dric Krier <> default * 557:a5a9b4b18871 tryton/tryton/gui/window/ (7 files in 3 dirs): Change unlink to delete for issue20112:53
CIA-53tryton: ced roundup * #201/Change unlink to delete in the kernel: [resolved] Fixed12:53
Timitoscedk: i am here only for a short while13:23
Timitoscedk: your solution for purchase and invoice computing of tax is not correct in my eyes.13:24
Timitosi would have prefered exactly the other way.13:24
Timitosperhaps we should discuss the computation of tax over tax codes too.13:24
Timitosperhaps it would be better to find another solution for computation of tax for tax report.13:25
Timitosthe solution you choosed will not fit to the needs of our customers.13:25
-!- kultviech( has joined #tryton13:27
Timitoscedk: will be back later in the evening13:33
bechamelTimitos, cedk :   one can imagine that the rouding on the lines take care of the total rouding, ie force rounding  above or under to match the total rouding. I think i's legal (but this will look funny if the price tax included are printed for each line)13:33
Timitosbechamel: i think price tax included for each line is not important. but there are some questions we need to discuss.13:36
Timitosbechamel: i think for tax computation the net sum of all positions of an invoice with the same tax are the base for tax computation. i think we need to see an invoice as one entity for tax computation and not the lines of an invoice.13:37
Timitosthe other point is that we will always have few differences. i need to search for the correct way to do the tax report query. this will be important if we switch back to the computation method of the invoice before the today change of cedk13:39
cedkTimitos: What is wrong with the solution?14:01
cedkTimitos: you are allowed to round tax on lines14:02
Timitoscedk: you wrote: the only problems that I see it is that the 48.97 is not wrong but it can look wrong, so we will have many reports about the fact that tryton doesn't compute right14:03
cedkTimitos: any store works like that14:03
cedkTimitos: yes it is not wrong14:03
Timitoscedk: and there must be a way to prevent this.14:04
Timitosyes. but this way you won´t get any customer for tryton in germany.14:04
cedkTimitos: yes not put together all invoice line tax14:04
cedkTimitos: why? Is it illegal in germany to round on line14:05
Timitosfor me it is only important that i get an invoice with 700 749 and not 700 748,97. the kind of solution is for me not so important.14:07
Timitosbut as I see the german law you must see all lines of an invoice as one action and tax is computed from this one action and not from lines. but i need to talk about this with a tax advisor14:07
cedkTimitos: so you will have different tax amount if you have one invoice with many lines or many invoice with one lin14:09
Timitoscedk: why?14:10
cedkTimitos: because of rounding14:10
Timitosif i sum up the net prices and compute the tax value from this sum? i don´t think so.14:11
cedkTimitos: if you have one invoice with 10 lines or 10 invoice with 1 lines, you will have different tax amount14:11
cedkTimitos: because grouping lines increase the precision of the computation14:12
cedkso for me there is not one good solution, there is two possibilities wich have pro and cons14:13
cedkand if you want to have tax line accounting on the account lines, you must round on lines14:13
Timitoscedk: i have to leave now as i am to late for about 30 minutes to my appointment just in the moment. can we continue this discussion in the evening or tomorrow?14:16
cedkTimitos: yes14:16
Timitoscedk: ok. i will ping you in the evening perhaps.14:16
-!- Gedd(n=ged@ has joined #tryton15:13
-!- FWiesing(n=Wiesinge@ has left #tryton15:48
udonocedk: about the rounding: If you round each line single, than you cummulate the rounding-error. And you are right, if there are a lot of lines, the roundingerror is rising high. In Germany its - afaik- usual to have just one cent differences by roundings. Withe the rounding like in purchase, there can cummulate more than one cent. The best way is to sum up all amounts with all possible significance and round this sum at last. There is no16:15
udonoed to round each line in Belgique, than you have to carry the rounding error from each line to the next line, and so on... In the german article about rounding is this discribed: but there is no english article about this...16:15
-!- FWiesing(n=Wiesinge@ has joined #tryton16:17
cedkudono: I was thinking about that, and in fact there is no problem for report to not round at each lines16:17
Timitoscedk: +116:17
cedkso i fix the purchase to not compute taxes by rounding on each lines16:18
Timitoscedk: i just checked this. i think it is the best solution not  to round at each line but at the end16:18
Timitoscedk: +116:18
Timitoscedk: i think  you need to revert your changes to  invoice too ,or not?16:19
udonocedk: which precision does our amount have?16:20
cedkudono: it is Decimal object16:21
udonocedk: does it mean it is as exact as the computer can calculate?16:23
cedkudono: yes it is not float16:23
cedkudono: it makes compute like you do by hand :-)16:23
cedkudono: it is standard to use Decimal for currency16:24
cedkudono: and it is also recommended in the python doc16:24
-!- Timitos(n=Timitos@ has joined #tryton16:25
cedkudono: and that why we don't have to care to not round at each lines16:26
cedkudono: if it was in float, that can create errors16:26
udonocedk: good design decision!16:27
udonocedk: so we dont have to worry about if we create in future a module for tax included pricings for the b2c market. With a fine precision there wont come up a rounding problem, too.16:29
cedkudono: I know this problem, I worked for a company that makes software for bank (in COBOL :-))16:30
cedkudono: no for tax included it will always have rounding problem16:30
cedkudono: but we have some thoughts about how to make a kind of POS that will work16:31
udonocedk: the standard rounding error in calculate the netprice is no problem, because it is impossible to calculate exact...16:32
udonocedk: problem is just if we are more unexact than this rounding-error...16:32
udonoBye guys, Iam traveling back home now, see you on monday...16:33
udonocedk: I know this module, it has all the stuff, bookeepers need for calculating amounts.16:34
Timitosudono: cu16:38
udonoTimitos: cu16:38
cedkI push the fix, but CIA seems to be down16:52
Timitoscedk: thx. i will test.16:53
-!- Timitos(n=Timitos@ has joined #tryton17:07
-!- beta_max(i=betamax@gateway/tor/x-ab2f0062204bd053) has joined #tryton18:01
cedkis someone find a real improvement with psyco module?18:04
Timitoscedk: what shall we look for?18:05
bechamelcedk: i tried psycho several month ago and it was a matter of 10 or 15% improvement18:08
cedkTimitos: it is a module that add somethings like JIT compiler18:08
cedkI add in tryton the import if the module is there18:08
Timitoscedk: so i should try to install the module on my server?18:09
cedkthe doc says that it can improve speed 10x to 100x18:09
cedkI don't find any instability with it18:10
cedkjust it doesn't work with pax MPROTECT but that is not really a problem18:10
Timitosbechamel: i can´t enter a bank statement with the new solution. something is wrong with the statement.journal but i don´t know what. there is no error message.18:11
Timitoscedk: i will install it on my testserver18:12
cedkTimitos: it increase the memory usage18:15
Timitoscedk: ok. this should not be a problem for my installation18:15
cedkTimitos: and not for tryton because it depends of the size of the code18:16
cedkand tryton doesn't have soo much code18:16
Timitoscedk: there is really some speed improvement with this module.18:17
cedkTimitos: on my dual core, I don't see much difference18:19
Timitoscedk: no not much. my server is a vm.18:21
Timitosi think the value of bechamel 10-15% is quite near18:21
bechamelcedk: if you want to check you can try simply with "print time.clock()"18:23
cedkbechamel: it is not a real test, because it compile python function18:23
cedkbechamel: so in tryton, we have many function and some are often called18:24
bechamelcedk: and ?18:24
cedkbechamel: there will be more improvement than just the call of clock18:27
bechamelcedk: i hope :), to test you have to put print time.clock() at several places. e.g. at the beginning and at the end of a big function and check the time spent between18:29
bechamelcedk: pyscopg generate this: ALTER TABLE E'ir_ui_menu' ADD FOREIGN KEY (E'parent') REFERE...18:30
bechamelcedk: and i dont understand where these "E" comes from ?!18:31
CIA-53tryton: Timitos roundup * #218/cannot enter bank_statement when in name of account.journal is an umlaut: [new] if the name of an account.journal has an umlaut like ä ö ü i cannot make a new bank statement. if i click on validate there is no functio ...18:31
bechamelcedk: i think i already saw them but i dont remember in which condition18:31
cedkbechamel: copy/paste the code18:32
bechamelcedk: more complete one :
cedkbechamel: don't use %s for table name and put " " between18:35
cedkbechamel: and the same for FOREIGN KEY18:35
cedkbechamel: and also for ON DELETE18:36
cedkTimitos: You don't have traceback for issue218?18:36
CIA-53tryton: C?dric Krier <> default * 47:72e820339786 account_statement/ ( journal.xml statement.xml): Use account as first name for object and fix some guidelines18:39
cedkTimitos: by the way I just push a change of name for all the module account_statement18:40
cedkTimitos: so you will not be able to use your current DB18:40
Timitoscedk: sorry. there is no traceback. but i am a litte bit confused now. it is working now and i don´t know why :-)18:40
Timitoscedk: ok18:41
bechamelcedk: you mean "ALTER ... " + table_name + " ADD .." ?18:41
cedkbechamel: yes18:41
cedkbechamel: there is no problem of sql injection as table_name comes from code18:41
bechamelcedk: yes18:41
cedkbechamel: %s is for formating values not any string in the query18:42
CIA-53tryton: Timitos roundup * #218/cannot enter bank_statement when in name of account.journal is an umlaut: [resolved] i close this issue as it is working now. i could not reproduce the error18:57
-!- CIA-54( has joined #tryton22:09
-!- betamax_(i=betamax@gateway/tor/x-1915eabf6bd06d9b) has joined #tryton22:48
-!- kultviech( has joined #tryton22:53

Generated by 2.11.0 by Marius Gedminas - find it at!