On 24 Jul 14:33, Guillem Barba Domingo wrote: > 2014-07-24 12:12 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>: > > > On 24 Jul 11:21, Guillem Barba Domingo wrote: > > > 2014-07-23 22:44 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>: > > > > > > > On 23 Jul 18:39, Guillem Barba Domingo wrote: > > > > > Hi, > > > > > we have the requirement to split a move in a defined number of moves > > > > > despite of split by quantity (the goal of stock_split module). > > > > > The move is splitted in the most similar quantities per each move: it > > > > > divides the quantity by the number of moves getting the "floor" > > value in > > > > > division (using the decimals of UoM) and the last move have the extra > > > > > decimal to get the total quantity of original move. > > > > > > > > > > We don't need any user interface to do that because it is called as > > part > > > > of > > > > > other development. > > > > > Now, we have this function in the module that implements that > > > > functionality > > > > > but I think it could be added in the API of stock.move to don't > > repeat > > > > the > > > > > code (which it is not trivial). It should be added in 'stock' module > > or > > > > > 'stock_split'. > > > > > > > > > > What do you think? > > > > > > > > As far as I don't see any rational for such behavior, I don't give a > > > > thought. > > > > > > > > > > The quantity produced should be divided in N packages. After the > > automatic > > > division, the user reviews the weight of each package (worrying more or > > > less about the decimals, depending of produced material). > > > > I still don't understand. You care or not about the weight of each > > packages? Where does "N" come from? > > > The "N" comes from new field in production (Package number), which it comes > from sale. > As I said, it is part of an specific development, but the need of divide
I still don't understand. > > > First, I tried to use the split by quantity function, but I found some > > > issues because of decimal precision so I had to implement the "split by > > > number" function. I think it could be a requirement for other use case. > > > > I guess you are refering to https://bugs.tryton.org/issue4067 > > But dividing per number of package will not change the issue. > > > > Of course. My implementation of "split per number" use Decimal and call > "round" or "Uom.compute_qty(..., round=True)" more often to avoid this kind > of issues. No need of Decimal. > If there is interest to add "split_by_number()" to Move API I will supply a > review and we can discuss about its implementation. Can not find interest as far there are no example of usage. > A little bit Off-topic of this thread, I think we could use Decimal also > for quantities, not only for currency-related amounts. > As you can see in 'farm' module [1], when you need to do "advanced" > operations with stock quantities, you need to convert it to Decimal to > avoid problems with rounding and missing decimals. > But the change done to have the digits definition in config file makes me > think that it could generate performance issues... There are no need of Decimal for quantities. Decimal doesn't magicaly fix the rounding issues. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgplXolhxCMkW.pgp
Description: PGP signature
