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.
------------------------------
Original Message:
Sent: Mar 01, 2024 06:09
From: Varun Pandhi
Subject: Handling "recurringChargePeriodType" and "recurringChargePeriodLength" on "ProductOfferingPrice" resource for non recurring prices
Hi all,
While going through TMF 620 Product Catalog Management API User Guide, we could find that there are 2 fields "recurringChargePeriodType" and "recurringChargePeriodLength" on "ProductOfferingPrice" resource.
As we understand, these fields should never be applicable to non recurring prices.
How does TMF recommend to handle these scenarios? - Should we be always mentioning both these fields with empty string in TMF Open API request/response or should these be fields be excluded wherever not applicable like in case of non recurring prices?
------------------------------
Varun Pandhi
Infosys
------------------------------