IRC logs of #tryton for Wednesday, 2012-02-01 #tryton log beginning Wed Feb 1 00:00:01 CET 2012
2012-02-01 13:24 <gltripp> does anybody know some tricks on the cash_discount module ?
2012-02-01 13:27 <cedk> gltripp: it seems that virtual-things did not yet make any release of it
2012-02-01 13:28 <gltripp> i've version 2.1.0 of this module, which i got installed on tryton 2.2 without any warnings
2012-02-01 13:30 <gltripp> but in the payment term formular, there is no option to define discounts. so the form won't let me save anything
2012-02-01 13:30 <cedk> gltripp: I guess it needs some tuning
2012-02-01 13:30 <cedk> udono, yangoon ping
2012-02-01 13:52 <yangoon> gltripp pushed, please write your issue at including the error message
2012-02-01 14:01 <marga> Hi! 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.
2012-02-01 14:02 <marga> Yesterday 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.
2012-02-01 14:03 <marga> Now, 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 ?
2012-02-01 14:35 <nicoe> marga: Tryton does not sum all the moves
2012-02-01 14:36 <nicoe> There is some sort of historization taking place in order to avoid recomputing previous period
2012-02-01 14:36 <marga> nicoe: I reviewed the code in the "stock" module. To calculate the "quantity", it does a sum of all movements.
2012-02-01 14:37 <marga> nicoe: please, then, point me to where the historization is.
2012-02-01 14:38 <cedk> marga: it is in stock.period
2012-02-01 14:41 <marga> which module? stock? or something else?
2012-02-01 14:42 <marga> Ah, found it. I was looking at an old copy of tryton, that didn't include this. Glad to see that you fix it :)
2012-02-01 14:42 <nicoe> marga: look for internal_quantity in there is a SQL query to compute according to a cache
2012-02-01 14:49 <cedk> marga: also stock.move store the quantity in the default_uom like that there is not unit convertion to do
2012-02-01 14:55 <marga> right
2012-02-01 14:57 -!- pjstevns( has left #tryton
2012-02-01 15:20 <jcm> nicoe: do you mean that we should periodically create stock.periods to reset the total of stocks and speed up queries ?
2012-02-01 15:25 <nicoe> If you don't create period there will be no cache :)
2012-02-01 16:02 <gueux> un bug de xkbcomp, je peux plus utiliser le bépo correctement :
2012-02-01 16:02 <gueux> oups, sorry, wrong chan :
2012-02-01 16:20 <jcm> nicoe: good to know ! should be added to doc, cf issue2427
2012-02-01 17:30 <navis> hello, as suggested by jcm yesterday, I tried to augment the precision of calculations to solve the problems of tax included prices in most cases
2012-02-01 17:30 <navis> so I put rounding at 0.0001 in the € currency
2012-02-01 17:31 <navis> it works in my tests in sales, amount are correct, but I can't invoice anymore
2012-02-01 17:31 <navis> I get 'The field "Amount" on "Invoice Tax" has too many decimal digits' when I try to create an invoice
2012-02-01 17:32 <navis> be it from sale or directly
2012-02-01 17:32 <cedk> navis: you must not increase the rounding of €
2012-02-01 17:33 <navis> cedk: I see that :-)
2012-02-01 17:36 <navis> so I'm back at the start
2012-02-01 17:36 <navis> jcm: do you have an example of the problematic case that you raised yesterday ?
2012-02-01 17:37 <navis> jcm: or another explanation on #tryton-fr if easier ?
2012-02-01 17:39 <bechamel> cedk, 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 ?
2012-02-01 17:40 <cedk> bechamel: no
2012-02-01 17:43 <cedk> bechamel: because in computed world, multiplcation and division are not assosiatif
2012-02-01 17:44 <navis> bechamel: there will always be a choice to make
2012-02-01 17:44 <navis> bechamel: an invoice is exact with or without taxes, not both
2012-02-01 17:45 <bechamel> because I was thinking that would explain the 10 items limit on ldlc
2012-02-01 17:45 <navis> bechamel: it is 100, I don't think it is related, their calculations are exact in both cases
2012-02-01 17:46 <navis> bechamel: but you can choose which case has to be exact
2012-02-01 17:46 <navis> bechamel: put something in a basket, and you can choose to see it with or without taxes
2012-02-01 17:47 <navis> bechamel: which changes the way they calculate it
2012-02-01 17:47 <navis> bechamel: that's what I'd like in tryton :-)
2012-02-01 17:50 <bechamel> navis: 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 ..
2012-02-01 18:02 <navis> bechamel: do you have an example ? it works for me with hp ink 57
2012-02-01 18:03 <navis> bechamel: 13,34 ht = 16,14 tvac
2012-02-01 18:10 <navis> bechamel: they are actually a bit more precise than that, they might be the perfect example of how to do it
2012-02-01 18:11 <navis> bechamel: on, the retail b2c site, calculations are always made on tax included prices, even when you see the basket without taxes
2012-02-01 18:12 <navis> bechamel: on, the b2b site, the same calculations are made on tax excluded prices
2012-02-01 18:13 <navis> bechamel: put 10x C6657GE in a basket on both sites, and see the difference
2012-02-01 18:14 <navis> bechamel: on pro, 10x 13,34 = 133,40 so price without tax is exact
2012-02-01 18:14 <navis> bechamel: on non b2c, 10x 13,34 = 133,39, which is 161,40/1,21
2012-02-01 18:15 <navis> bechamel: so even if the basket can be shown without taxes, the rounded price is still the one with tax
2012-02-01 18:16 <navis> bechamel: has the right behaviour for b2c, and for b2b
2012-02-01 18:17 <cedk> navis: but we know excatly what must be done, the only remaining point is how to implement in tryton
2012-02-01 18:18 <navis> cedk: am I right when I think that most real calculations are coded in ?
2012-02-01 18:18 <cedk> navis: yes
2012-02-01 18:20 <navis> cedk: so if we can get invoices right, the rest should be piece of cake
2012-02-01 18:20 <cedk> navis: no, the issue is storing information
2012-02-01 18:21 <navis> cedk: hu ?
2012-02-01 18:23 <navis> cedk: what storing issue ?
2012-02-01 18:24 <cedk> navis: information
2012-02-01 18:44 <navis> cedk: there can be a 'b2c' flag on invoices and sales that modifies the behaviour when true
2012-02-01 18:44 <navis> cedk: and a flag in product that says if the price is tax included or not
2012-02-01 18:45 <navis> cedk: is there anything else needed ?
2012-02-01 18:45 <cedk> navis: I don't like the flags idea
2012-02-01 18:46 <cedk> navis: but if you can provide a clean code, why not
2012-02-01 18:47 <navis> cedk: the alternative for the document is to create new objects, like you proposed, but also for invoice then
2012-02-01 18:48 <navis> cedk: but then there is no way to decide programatically which behaviour to use, the user must decide
2012-02-01 18:49 <navis> cedk: on the product,.... well there can be two fields, but we need a way to tell tryton which price is "master"
2012-02-01 18:49 <cedk> navis: no need for invoice
2012-02-01 18:49 <cedk> navis: you can fix the taxes value
2012-02-01 18:51 <navis> cedk: needs to be heavily modified, which in the case of sale was the reason why you prefer a separate object
2012-02-01 18:52 <navis> cedk: to keep sale simpler and cleaner
2012-02-01 18:52 <navis> cedk: this does not apply to invoice ?
2012-02-01 18:55 <cedk> navis: no, invoice doesn't need to be modified, invoice works only with unit_price without taxes
2012-02-01 18:57 <navis> cedk: I don't understand, the bulk of the work happens in invoice, so this is where most modifications will happen
2012-02-01 18:58 <navis> cedk: sales only uses code which is in invoice
2012-02-01 18:59 <cedk> navis: it is possible to write a correct invoice now
2012-02-01 18:59 <cedk> navis: so no need to change it
2012-02-01 18:59 <navis> cedk: correct yes, but not b2c safe
2012-02-01 19:01 <cedk> navis: don't care, you don't edit b2c invoice
2012-02-01 19:03 <navis> cedk: lol, of course you do :-)
2012-02-01 19:07 <cedk> navis: no, I don't care once the invoice is generated by the sale b2c

Generated by 2.17.3 by Marius Gedminas - find it at!