Serial Numbers on Products and Stock Moves

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.

Here is a repository of the module:

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’m wondering if we should create an access group for this, to not allow all the users in the system overrule the constraint.

Why not, it is the same as the force assignation group.

I think I’m wrongly understanding myself :cold_sweat:.
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’m wondering if it will be interesting to deactivate lots once sent to the customer, as we plan to do for movable locations.

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 for reference, this is implemented on Issue 6442: Add serial number functionalities to lot - Tryton issue tracker

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.

What is the point to have both? Serial number is finer grain of lot, so the information you can have with lot, you have it with serial number.

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.

Those two sentences are contradictory. If you can track unit, you can track a set of unit.

What you call ‘set of unit’ is lot. But it is no more available with the proposed implementation once it is used for serial numbers.

What is the point of a lot?
It is to track products.

What is the point of serial number?
It is to track product.

So if you can track one product, you can track many.

If you want to add more information on the serial number, you can add any field and you can call it “Lot number” if you want.

Perhaps best is to get into a real use case.

  • Product P4 is composed (produced out of) of Product P1 and either P2 or P3.
  • For legal reasons you have to track the usage of P1, P2 and P3 and the process, how you produced P4.

We produce the following lots of P4:

  • P4 with Serial S_P4_001 and Lot L_P4_001 produced with process 1 out of lot L_P1_001 of Product P1 and lot L_P2_001 of Product P2.
  • P4 with Serial S_P4_101 and Lot L_P4_002 produced with process 1 out of lot L_P1_001 of Product P1 and lot L_P3_001 of Product P3.
  • P4 with Serial S_P4_201 and Lot L_P4_003 produced with process 2 out of lot L_P1_001 of Product P1 and lot L_P3_001 of Product P3.

We sell to our customers:

  • S_P4_001 to customer C1
  • S_P4_101 to customer C2
  • S_P4_201 to customer C1

Now the challenges:

  • Lot L_P3_001 was of poor quality, we have to recall all lots of P4 made of L_P3_001 .
  • Process 2 was corrupt. We have to recall all lots of P4 made with process 2.

How do we map this in Tryton?

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.

I am talking about traceability with lots and serial numbers. For what else would you need serial numbers and lots if not for traceability?

I think that here we are confusing part number with serial number:

  • Part number is the one that would track the product models or manufacturing processes. (Example: Notebook models)
  • Serial number is unique for each item and it can not be reused. (Example: Mobile IMEI)