For a given product offering, in which manner its validity period, specified by the the "validFor" property, can make its lifecycle status varying too?
For instance, can we consider that a product offering could be in status "Launched" whilst its validity start date has not been reached yet?
when I worked in B2B manufacturing, we had 3 validFor: for selling, servicing and repairing and the status value had to be consistent with all these dates. Changing a date would automatically change the status when that date comes (or vice versa, changing a status immediately change a date). So, "Launched" is probably inconsistent with a Start Date in the future.
We had "pre-sales" status, where offers were quotable, sometimes sellable but not installable until after the Start Date.
it's important to keep some flexiblity as each type of product offerings (intangible/tangible, one-time/subscription...) can have different relationship between the status and the date. I'm not sure there are any rules or best practices here.
You choose the status values you need and define what "validFor" means to your organisation.Lastly, I think it's also important to keep in mind that lifecycleStatus and validFor can be different for ProductOffering and for ProductSpecification, so you also need consistency between entities.
you should also check IG1228, specifically "14. Use Case UC012: Product Catalog - Launching a new Product Offering", which has state model for product lifecycle.
The TMF business process framework should also have information on product lifecycle
Thank you for the explanations ...and for the use case doc you pointed to, its really helpful!
Just as a clarification, in v5 of the API we have clarified the semantic meaning of the validity period (validFor) to refer to the period for which the offering instances (in inventory) can be maintained. The sales validity has been encapsulated in the AllowedActions, a new addition in v5, which itself has a validity period.
that's a good addition. But would it be even better to model all ValidFor under AllowedActions?
then you can have an array of actions we want (selling, change offer, servicing, maintaining...) with a ValidFor for each actionIt's seem cleaner to group them all together.
period for which the offering instances (in inventory) can be maintained
If we have very old active product (say Internet 50/50) that we want to sunset on 30.09.2023, meaning we would force existing customer with active Internet 50/50 subscriptions to migrate to another offer we would use Validfor (end date = 30.09.2023) and on that date, the lifecycle status would be set to "end of life"
The allowed actions are likely to be exposed to a UI or navigation/experience layer. It's possible, but unlikely, that an automatic upgrade would happen as a result of the main offering validity period.