There is a real life asymmetry that is not reflected in your model:
- a customer may order a purifier and the related package service, not knowing the serial.
- a customer may order subsequent packaged service for a purifier whose serial must be known
- a customer may have ordered and own several purifiers but may order less packaged service (because one of the ordered item is broken or is not used, or was give away as gift to a child, etc...) so that only the customer can know the serial for which the order is placed.
For this reason, I’d rather see the serial as the clue for an existing entity : the produced /delivered item. I’d therefore store it separately from the ordered service, for example in a table of delivered items, that would be related one-to-many to the ordered item (you could for example create these lines when the product is shipped).
This approach would allow to order packaged services, and create the relation between the ordered services and the serial/delivered item when it is known.
You may in a similar fashion track delivered services with a one to many relation between an ordered service for a serial and the related individual service packs delivered.
Now if you do not need to track the deliveries, your approach could work as well. It’s just that you combine information that should be independent, so you might end up with several rows for the same serial, making follow up more difficult.