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? > 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. By the way, I think stock_split is missing some ronding call. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgplh8rbylAT8.pgp
Description: PGP signature
