| chat.freenode.net #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 https://bitbucket.org/ukoma/account_invoice_cash_discount/issues/new 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 product.py 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(~paul@a83-163-46-103.adsl.xs4all.nl) 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 ldlc.be, 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 ldlc-pro.be, 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: ldlc.be has the right behaviour for b2c, and ldlc-pro.be 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 invoice.py ? | ||
| 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: invoice.py 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 irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!