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 don't care in "decimal" level. They do productions of thousands of Kg and if the produced quantity can't be splitted exactly by the number of packages (for example, 5.000 Kg in 12 packages) the function in stock_split raise exception. In issue 4067 you argue that its "a feature" because if the original quantity (5000) can't be splitted by the quantity introduced by user (or, in my case, calculted by the system) the user must to be adviced to choose a valid quantity. I accept this argument so I implement an split by number of resulting moves. In this use case, I think it makes sense to don't care of little differences in quantity of splitted moves because the request is to split in a number of moves. This method should raise exception if you try to split a quantity by an impossible number of moves; for example if you try so split a 10 Units (without decimals) in 12 moves what result in 2 moves with quantity=0 => error So, I think there are two use case which require two different methods. > > 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. If there is interest to add "split_by_number()" to Move API I will supply a review and we can discuss about its implementation. > By the way, I think stock_split is missing some ronding call. I don't fix/improve/change stock_split because of you message 17573 (which I think it's a valid argument, as I explained above). 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... [1] https://bitbucket.org/nantic/trytond-farm/src/63359258798aca17f8162304a3c754b1729b4f42/events/feed_inventory.py?at=default -- Guillem Barba http://www.guillem.alcarrer.net
