IRC logs of #tryton for Wednesday, 2012-02-01 #tryton log beginning Wed Feb 1 00:00:01 CET 2012
gltrippdoes anybody know some tricks on the cash_discount module ?13:24
cedkgltripp: it seems that virtual-things did not yet make any release of it13:27
gltrippi've version 2.1.0 of this module, which i got installed on tryton 2.2 without any warnings13:28
gltrippbut in the payment term formular, there is no option to define discounts. so the form won't let me save anything13:30
cedkgltripp: I guess it needs some tuning13:30
cedkudono, yangoon ping13:30
yangoon gltripp pushed, please write your issue at including the error message13:52
margaHi!  I'm an OpenERP user (thus OpenERP hater) and when I face ugliness I usually look at tryton to see how you resolved the issues I encounter.14:01
margaYesterday I realized that OpenERP does a couple of queries each time I want to access the stock of a product. Today I checked Tryton and found out it's the same.14:02
margaNow, I wonder, how is it that nobody finds it terribly inefficient to be summing again and again and again all the moves in the DB ?14:03
nicoemarga: Tryton does not sum all the moves14:35
nicoeThere is some sort of historization taking place in order to avoid recomputing previous period14:36
marganicoe: I reviewed the code in the "stock" module.  To calculate the "quantity", it does a sum of all movements.14:36
marganicoe: please, then, point me to where the historization is.14:37
cedkmarga: it is in stock.period14:38
margawhich module? stock? or something else?14:41
margaAh, found it.  I was looking at an old copy of tryton, that didn't include this.  Glad to see that you fix it :)14:42
nicoemarga: look for internal_quantity in there is a SQL query to compute according to a cache14:42
cedkmarga: also stock.move store the quantity in the default_uom like that there is not unit convertion to do14:49
-!- pjstevns( has left #tryton14:57
jcmnicoe: do you mean that we should periodically create stock.periods to reset the total of stocks and speed up queries ?15:20
nicoeIf you don't create period there will be no cache :)15:25
gueuxun bug de xkbcomp, je peux plus utiliser le bépo correctement :16:02
gueuxoups, sorry, wrong chan :16:02
jcmnicoe: good to know ! should be added to doc, cf issue242716:20
navishello, as suggested by jcm yesterday, I tried to augment the precision of calculations to solve the problems of tax included prices in most cases17:30
navisso I put rounding at 0.0001 in the € currency17:30
navisit works in my tests in sales, amount are correct, but I can't invoice anymore17:31
navisI get 'The field "Amount" on "Invoice Tax" has too many decimal digits' when I try to create an invoice17:31
navisbe it from sale or directly17:32
cedknavis: you must not increase the rounding of €17:32
naviscedk: I see that :-)17:33
navisso I'm back at the start17:36
navisjcm: do you have an example of the problematic case that you raised yesterday ?17:36
navisjcm: or another explanation on #tryton-fr if easier ?17:37
bechamelcedk, navis: I was thinking about this issue today, what if we keep all the decimals everywhere and do the rounding only to show the amounts ? Will it solve the problem ?17:39
cedkbechamel: no17:40
cedkbechamel: because in computed world, multiplcation and division are not assosiatif17:43
navisbechamel: there will always be a choice to make17:44
navisbechamel: an invoice is exact with or without taxes, not both17:44
bechamelbecause I was thinking that would explain the 10 items limit on ldlc17:45
navisbechamel: it is 100, I don't think it is related, their calculations are exact in both cases17:45
navisbechamel: but you can choose which case has to be exact17:46
navisbechamel: put something in a basket, and you can choose to see it with or without taxes17:46
navisbechamel: which changes the way they calculate it17:47
navisbechamel: that's what I'd like in tryton :-)17:47
bechamelnavis: except that when I ask a price without tax on ldlc and then I compute the tax included price myself it does not match the tax included price they give me ..17:50
navisbechamel: do you have an example ? it works for me with hp ink 5718:02
navisbechamel: 13,34 ht = 16,14 tvac18:03
navisbechamel: they are actually a bit more precise than that, they might be the perfect example of how to do it18:10
navisbechamel: on, the retail b2c site, calculations are always made on tax included prices, even when you see the basket without taxes18:11
navisbechamel: on, the b2b site, the same calculations are made on tax excluded prices18:12
navisbechamel: put 10x C6657GE in a basket on both sites, and see the difference18:13
navisbechamel: on pro, 10x 13,34 = 133,40 so price without tax is exact18:14
navisbechamel: on non b2c, 10x 13,34 = 133,39, which is 161,40/1,2118:14
navisbechamel: so even if the basket can be shown without taxes, the rounded price is still the one with tax18:15
navisbechamel: has the right behaviour for b2c, and for b2b18:16
cedknavis: but we know excatly what must be done, the only remaining point is how to implement in tryton18:17
naviscedk: am I right when I think that most real calculations are coded in ?18:18
cedknavis: yes18:18
naviscedk: so if we can get invoices right, the rest should be piece of cake18:20
cedknavis: no, the issue is storing information18:20
naviscedk: hu ?18:21
naviscedk: what storing issue ?18:23
cedknavis: information18:24
naviscedk: there can be a 'b2c' flag on invoices and sales that modifies the behaviour when true18:44
naviscedk: and a flag in product that says if the price is tax included or not18:44
naviscedk: is there anything else needed ?18:45
cedknavis: I don't like the flags idea18:45
cedknavis: but if you can provide a clean code, why not18:46
naviscedk: the alternative for the document is to create new objects, like you proposed, but also for invoice then18:47
naviscedk: but then there is no way to decide programatically which behaviour to use, the user must decide18:48
naviscedk: on the product,.... well there can be two fields, but we need a way to tell tryton which price is "master"18:49
cedknavis: no need for invoice18:49
cedknavis: you can fix the taxes value18:49
naviscedk: needs to be heavily modified, which in the case of sale was the reason why you prefer a separate object18:51
naviscedk: to keep sale simpler and cleaner18:52
naviscedk: this does not apply to invoice ?18:52
cedknavis: no, invoice doesn't need to be modified, invoice works only with unit_price without taxes18:55
naviscedk: I don't understand, the bulk of the work happens in invoice, so this is where most modifications will happen18:57
naviscedk: sales only uses code which is in invoice18:58
cedknavis: it is possible to write a correct invoice now18:59
cedknavis: so no need to change it18:59
naviscedk: correct yes, but not b2c safe18:59
cedknavis: don't care, you don't edit b2c invoice19:01
naviscedk: lol, of course you do :-)19:03
cedknavis: no, I don't care once the invoice is generated by the sale b2c19:07

Generated by 2.11.0 by Marius Gedminas - find it at!