Hi Varun
Firstly, an observation. In the Information Framework (the SID), there are many different subclasses of ProductOfferingPrice, with a deep hierarchy, allowing distinguishing between onetime (non-recurring) charges (OC), usage, recurring (RC), discounts, and more. So properties that apply only to RC will be in the appropriate subclass that reflects RC.
The Open API pattern (in all parts of the model, not just here) is to dispense with extreme normalization and deep class hierarchies, in favor of simplicity. As a side-effect, you will find that some fields are not relevant in all cases.
I see no reason to place these fields in the payload if they are empty, neither in input nor in output. Let's try to minimize the size of payloads where possible.
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.
------------------------------