Hi Ahmed
The important aspect (in my opinion) is not how you model your catalog internally, but rather how you expose the model to consumers (e.g. UI clients at ordering time).
The SID is not noted for being an easy model to expose using APIs, which is why the Open API models tend to be simpler (less class hierarchies, less associations), possibly at the expense of denormalization.
Specifically here, the Open API has a 0..* relationship from ProductOffering to Channel, via the ChannelRef. Unfortunately, we never defined the Channel entity in the API model, but you could build one yourself as an extension. However this would not help your use case, since you want to add the code. You could "ignore" the existing relationship and create a new association class in the API model, where the association class would have this code as a property, much as you have described for SID.
An alternative approach might be to use characteristics, which we have added to ProductOffering in v5 of the API, but using characteristics gives a weaker contract.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------