Product catalog data model for Order Management and its Important Points to Remember at initial Setup.

[Kailash Bhange]

The catalog data model provides a framework that allows service providers to define the products and services. It includes different entities that separate the customer-facing information from the technical information.

• Product: market information; customer facing
• Service: can be both customer and non-customer facing
• Resource: technical information; non-customer facing

Below are the Product catalog data model entities and should be setup in the similar approach defined here.

1. Product Offering Catalog.
2. Specification Category.
3. Characteristic
4. Characteristic-Options.
5. Resource Specification including characteristics mapping, Specification Relationships and then publish it.
6. Service Specification including characteristics mapping and then publish it.
7. Product Specification including characteristics mapping, Specification Relationships and then publish it.
8. Product Offering with required Product specification.

For more details on these entities, please refer the documentation here.

Most Important pints to be noted during the catalog data model setup: -

• The relationship type between PS-PS should be used as per business requirements.
• PS should be marked as ‘composite = true’, which will have child PS related to it.
• While defining the characteristics of type choice, yes_no, and checkbox, should be marked as ‘Mandatory’ true.
• Cross validating if all the characteristics from PS level have been pulled at PO level or not.

To more understand the above four points, let us consider below data model as an example.

 

Let us try to understand the four points with help of model in above image.

1. The PS-PS relationship type should be defined carefully,
   1. For example, if we define it as ‘Bundles’ in case of PS_001 to PS_002 it will generate both Product Order and Service Order for Order line item of PS_002 specification.
   2. If we define it as ‘Composed of’ in case of PS_001 to PS_002 it will generate only Service Order for Order line item of PS_002 specification.
2. PS_001 should be marked as ‘Composite’ True because it is related to PS_002 and both PS_001, PS_002 have characteristics defined on them and all of them will be auto pulled on product offering once you link PS_001 on PO_001.
3. Choice, yes_no, and checkbox type characteristics should be marked as mandatory because in the backend flow it validates the characteristics defined at PS level with the characteristics at PO_001 level (They should match so that you can pass the values for them in payload/request-body of Open API and system will allow the generated ORD to be approved).
4. Cross validation of the characteristics counts on PO_001 should be done so that all of them from PS_001, PS_002 are pulled (ORD generated will not allow to be approved if the count does not match as it is considered as mandatory in the back-end flow for Rome version).

Note: - The behavior mentioned in the Article is specific to the Rome Version and might be different for upcoming versions.

Hope this helps.
If you think this has helped you or can be helpful for other, please mark it as Helpful, Bookmark it, and Share it.

Thank You!
Regards,
Kailash

[Rajesh_Bhise]

All is fine. Good Info. Thanks Kailas...!!!

[Tom Schnarr]

Great article - thank you Kailash, you provided great insights.

I would like to add a couple of clarifications

1. (Clarification to Kailash's points) The PS-PS relationship type should be defined carefully,
   1. For example, if we define it as ‘Bundles’ in case of PS_001 to PS_002 it will generate both Product Order and Service Order for Order line item of PS_002 specification. 
   • The result of decomposition will be 4 Domain Orders :
   • ProdOrder for PS_001
   • ProdOrder for PS_002
   • ServiceOrder for SS_001
   • ServiceOrder for SS_002.
   2. If we define it as ‘Composed of’ in case of PS_001 to PS_002 it will generate only Service Order for Order line item of PS_002 specification.
   • The result of decomposition will be 4 Domain Orders :
   • ProdOrder for PS_001 (Which also needs to fulfill the request for PS_002)
   • ServiceOrder for SS_001
   • ServiceOrder for SS_002.
2.  
3. here it is mentioned that the characteristics should be marked as mandatory.  That is true if the chars are passed from above, but in some cases these characteristics should be populated as part of order enrichment.  Imagine a choice characteristic of technology - but the flow needs to call inventory to determine which technology to use - 'GPON' is returned which then may trigger a subsequent decomposition - this is the heart of the 'staggered decomposition' which was introduced in San Diego.
4.   

As you mentioned your comments were specific to Rome and my clarification on #3 is part of San Diego.

[vijaykumar_k]

Hi Kailash,

Nice explanation. In Utah version, Can we do quantity decomposition from PS_001 to PS_002?  Based on characteristic value at PS_001 we decompose into PS_002. (for example, if the characteristic value at PS_001 is selected is 2, we get 2 ProductOrders and 2 ServiceOrders for PS_002.)

[ShashankInamdar]

Hello @vijaykumar_k , Product to Product decomposition is not supported by Order Management. Based on TMF SID, it is assumed that a Product Spec is always made available via an Offering. For composite Products, the TMF622 payload must have an Order Line Item unless it is an optional Product.

To meet your requirements, via configuration, it should be possible to submit an order with an Order Line Item for PS001 and enrich it to add additional Order Line Items for PS002 based on a char value. In the background a subflow can be initiated that does the job of reading the PS001 char and adding additional OLIs for PS002.

Regards

Shashank

[vijaykumar_k]

Thanks @ShashankInamdar for the clarification and the option.