If product offer provides what engagement management fills mandatorily, the engagement management can draw UI and check validation itself. Also, when pocv validates order request, it can use the product offer to validate what should be mandatory in the order request. However, I think product offer only can provide min, max cardinality for characteristics. How can I validate offer's related parties, places, agreement in order request to validate in pocv? How should I provide same validation for engagement and pocv?
The ProductConfiguration API TMF670 (https://www.tmforum.org/oda/open-apis/table) might be just what you are looking for. It saves the consumer the work of doing the validation against the catalog model. Of course you need to implement it, so there are no short cuts, but it does put the logic in the right place, in a backend pocv ODA component, rather than in the front-end or engagement layer.
Hope it helps
My idea is that if product catalog provides an offer and its mandatory fields (characteristics, related parties, place so on), an engagement app can draw what fields are mandatory. According to product offer in product catalog, I only can provide characteristics as mandatory fields using cardinalities. But for other fields like relaties parties (with roles) and place so on, I can't provide mandatory marks in the offer in product catalog. How can I provide the marks for mandatory fields in the offer? I mean that should I extend the product offer to store marks for mandatory fields in the product offer? If I provide the marks, one of SOR components like pocv or product configurator (you suggested) can validate request from the engagement app using the product offer in the product catalog and its the mandatory marks. How far is my idea from solutions of implementers of tmforum like amdocs? :)
You raise a valid question, and I don't have a good answer. To make it concrete, how is a UI/engagement management/validation component supposed to "know" that for a wireline product an installation address is mandatory while for a wireless product it is irrelevant. I would go further, how is the component supposed to know that a given RelatedPlace is actually an installation address?
I clearly cannot explain to you how we do this in Amdocs, that would be "leaking" our intellectual property. All I will say is that, like CSPs and other vendors, we extend the Open APIs where needed to match our business aims. And in many cases we have suggested our improvements as enhancements back into the standard. In this particular area we have not done this, and I don't know if we will.
product catalogue driven validation focuses on validations for the main entities (product offering, product specification, Product Offering Prices) in the product catalogue.If you data requirement concerns the product model during order capture, then you can use the product catalogue to enforce the rule. example:when we sell fiber internet, the fiber network product spec requires a characteristic to capture the termination point id, which is tied to the service address. In that case, yes, the product catalogue is the right place to make the service adress mandatory.if the rule is to capture the legal owner or a billing address then the product catalogue may not be the best place to store that rule.My understanding is that different ODA component are responsible for their own business rules.
I would recommend reading these documents that would give some insight in business rules, sales rules etc.GB922 - Product and GB922 - Common that provide examples of business rules stored in the product catalogue and some examples of using the policy functionality.