It is very important for the warehouses to be able to track the products that are stored or have left the warehouse by products’ serial numbers. This feature enables reviewing the state of a specific product - the reason and time it left the warehouse, in which warehouse it has been stored and to which it has been moved, and so on.
A solution to that problem could be a new model ‘Serial Number’ which will keep track of all this activity relating the existing ‘Stock Move’ model. Since ‘Stock Move’ already relates to a shipment and to a product and represents a product movement from or to the warehouse, we have all the information we need.
The new model ‘Serial Number’ (‘stock.move.serial_number’) will have the fields:
serial_number -> (string)
input_move -> (Many2One relationship with stock.move)
output_move -> (Many2One relationship with stock.move)
Every time a product enters the warehouse it gets a serial_number and the input_move relationship links to the input stock move.
When the product leaves the warehouse, the output_move of the serial number links to the output stock move.
Why not re-use the stock lot and allow to configure on the product a constraint that make it unique for use? Because by using the lot, you get a lot of feature for free like the required on some kind of move, the cache computation etc.
I will agree with @ced proposal, but we will have to take in account that a the configuration on product to make it unique has to take in account existing move, so maybe we must no allow to set the flag if the product already has moves with quantity greather than one.
Also I think it should be allowed to overrule the constraint.
For example, if a previous outgoing move was wrongly tagged with Number X, and now you are moving the Number X (you have in front of you). You should not be blocked (but warned).
I think I’m wrongly understanding myself .
Indeed the constraint is on the quantity of the move (kind of maximum quantity).
So we should not care about previous moves but it should not be allowed to overrule it.
I’m also thinking that if the constraint should only be about having a quantity of 1 because any other value is useless as it will bring no new information.
I think the constraint should also ensure that a unique lot can be used only once per shipment.
I do not think it is a good idea because lot are there to store information about the product moved. If there was a mistake previously when the user pick a product with a specific lot number, he must find it otherwise he will create a new lot and then we loose traceability.
Just a question if I understood correctly the proposal:
When re-using the lot functionality for serial numbers, will it still be possible to have lots and serial numbers for a product? I suppose this could be a not so random use case to have lots on products together with serial numbers.
You are right, if you track serial numbers by lots. But serial number replacing lot looses the possibility to track lots.
Just a scenario: Producing a medicament, where you want to keep track of a certain basic ingredient used for a number of products (lot). But you still have to track where each one of your products was sold (serial number). Of course serial number is a subset of lot, but you can’t track any more the lot with the current proposal.
This is not related to the previous discussion because here you are talking about traceability with production.
In this case you must trace down stream using the production moves and you must do that recursively.