Open APIs

 View Only
  • 1.  TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    TM Forum Member
    Posted Sep 06, 2022 06:50
    Edited by Moustafa Elkady Sep 06, 2022 06:55
    Hello,

    As defined at "TMF630_REST_API_Design_Guidelines_4.2.0" Chapter 4. EntityRefOrValue pattern: When an object (or list of objects) exists in the server side then it can be referred to by its reference; when the object (or list of objects) does not exist then it can only be referenced by its value. The EntityRefOrValue pattern is useful when there is a need to pass to the server an object (or a list of objects) in either existence state.

    so ProductOfferingPriceRefOrValue could have ProductOfferingPrice ref (id, href) or the value, so ProductOfferingPrice object and ProductOfferingPriceRefOrValue object should be the same if I used the expand directive or if I decided to show the value instead of the Ref because RefOrValue give me the permission to do that.

    the problem is that ProductOfferingPrice Entity is different than ProductOfferingPriceRefOrValue 
    • ProductOfferingPrice.price is a Money Entity, so it should be like that
    "productOfferingPrice": [
        {
            "price": {
                "unit": "string",
                "value": 0
            }
        }
    ]​

    • ProductOfferingPriceRefOrValue.price is a ProductPriceValue Entity, so it should be like this
    "productOfferingPrice": [
        {
            "price": {
                "percentage": 0,
                "taxCategory": "string",
                "taxRate": 0,
                "dutyFreeAmount": {
                    "unit": "string",
                    "value": 0
                },
                "taxIncludedAmount": {
                    "unit": "string",
                    "value": 0
                }
            }
        }
    ]​


    This is misleading to me, Should I use the ProductOfferingPrice as a RefOrValue and not use expand to expand it? even if i did that, it still misleading for me because the price at /ProductOffering endpoint will be different than /ProductOfferingPrice endpoint and they have the same ID, so it should be the exact same object.



  • 2.  RE: TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    TM Forum Member
    Posted Sep 11, 2022 08:40
    anyone?


  • 3.  RE: TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    TM Forum Member
    Posted Oct 17, 2022 07:34
    + 1
    I see several questions on RefOrValue pattern and we ourselves wondering how it works.
    Hopefully, TM Forum API team can provide some help.

    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 4.  RE: TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    TM Forum Member
    Posted Oct 19, 2022 05:51
    Hi

    In almost all APIs where we have RefOrValue, the json schema file for the RefOrValue is very simple, it does allOf of the entity schema and the entityref schema.
    ProductOfferingPrice is an exception to this. As part of the development of Product Catalog API v4.0, we created a reusable and separately manageable entity for price, ProductOfferingPrice. However, there was a demand from the community to keep also the previous embedded (by value) price concept. So in v4.1, @Kamal Maghsoudlou constructed a very delicate modification that preserved the v4.0 work (i.e. ProductOfferingPriceRef) while restoring the embedded price (represented by POPCharge and its sub-entities).

    Hope this is clear, perhaps Kamal can provide additional insights.​

    P.S. We've maintained this for the time being in the v5 beta for TMF620, it's worth considering whether the time has now come to remove the embedded price from the API.

    ------------------------------
    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.
    ------------------------------



  • 5.  RE: TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    TM Forum Member
    Posted Nov 10, 2022 04:47
    Hello Jonathan,
    Thank you for your replay
    I'm still confused, I think ProductOfferingPriceRefOrValue.price and ProductPriceValue.price should share the same schema.
    which schema should I use when expanding the productOfferingPrice ref?



  • 6.  RE: TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    TM Forum Member
    Posted Nov 27, 2022 15:08
    Hi Moustafa
    I'm not sure what I can add. I gave a hopefully clear explanation of why ProductOfferingPrice does not implement the RefOrValue pattern in the same way as all the other <Entity>RefOrValue.

    ------------------------------
    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.
    ------------------------------



  • 7.  RE: TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    Posted Feb 14, 2023 22:15

    ProductOfferingPrice.price (Money).  The TaxItem is used for the other fields of the legacy embedded ProducePriceValue tax fields.

    Unfortunately the examples in TMF620 at the end of the document are still referring to the embedded ProductOfferingPrice mechanism.



    ------------------------------
    Dan d'Albuquerque
    TO BE VERIFIED
    ------------------------------



  • 8.  RE: TMF620 - Why ProductOfferingPriceRefOrValue is different than ProductOfferingPrice

    TM Forum Member
    Posted Feb 20, 2023 10:30

    Looks like I have homework, to add an example or two showing the referred and reused POP. Hopefully in v5 ...



    ------------------------------
    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.
    ------------------------------