A Dijous, 26 de gener de 2012 00:54:21, Cédric Krier va escriure: > On 25/01/12 19:52 +0100, Albert Cervera i Areny wrote: > > A Dimecres, 25 de gener de 2012 14:17:35, Cédric Krier va escriure: > > > > I think it should. Of course, we can discuss on what's the best > > > > default behaviour of stock_lot module, but I'm sure that many > > > > companies will need to be sure that the current stock levels are ok > > > > and that includes the exact lots available. If you cannot rely on > > > > that, it has no sense to manage lots (at least, in many use cases). > > > > > > For me, I see it as a blocking stuffs that will be very annoying. > > > If the user pick a product with the wrong lot number, the next guys who > > > will need to pick the same product, the system will prevent him to do > > > it because it is the wrong number. > > > > Take into account that in many cases it is the system that creates the > > lot number. You're probably thinking on a use case of a > > If it is the system that create such number then their are useless as > any information is generated.
It is not. For example, in several of our customers, if the purchased product has a lot number, that is introduced manually by the user but the system creates a new lot number and that is attached with a label to the incomming product. From there on, the numbers used are those created by the system. > > > For me, it should really be like a tag and even we should be able to > > > modify it after the move was done. And it makes no sense to have the > > > system telling to the user to pick the lot number X out of thousand of > > > same products from a location. > > > > I fully disagree. We've got installs in which it is the system that tells > > the users what lot they should use and it is a hard requirement. The lot > > can bring other information such as Expiry Date which may determine > > which lot is used. > > Of course the system can make proposal but I really think it is a bad > practice. The problematic of expiration date should be managed with a > good organization. A good system must be flexible. I don't mean we necessarily should impose such restriction to the default module, but lot is very important in some cases. Of course, we can decide not to make assign_try() take care of this in the more generic modules, but it will be definitely necessary in some cases. > > Also note that in many places which lot was used is very important. If > > the user did not put the correct lot when the product arrived, then it > > must be corrected. The same way you make an inventory when stock is not > > correct. > > If there is no way to detect wrong encoding, this is utopian to think it > will be corrected at more it will be corrected for the future. If the lot is labeled in the product it can be corrected by creating inventory moves. Those moves record that you had some problems in your stock and thus can be analyzed the way many users expect: You should not sell a product lot that you have never received. Note that I'm mixing several use cases here, but will try add the different requirements in the wiki page. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
