Open APIs

 View Only
  • 1.  TMF637: how to handle prices?

    TM Forum Member
    Posted Oct 13, 2020 04:31

    TMF637 product inventory offers two ways to assign prices: 
    - by specific price within "product price"
    - by reference to "product offer price"

    So my question is what's the appropriate and recommended way to implement the API?

    Pros product price:
    - enable customer specific prices
    - set price during order process. Later prices changes don't influence the order timestamp price

    Pros refererence product offer price:
    - avoid data redundancy; price changes that affect all products do not result in mass data changes
    - enable versioning of product offer prices



    ------------------------------
    Heinz Sandermann
    Deutsche Telekom IT GmbH
    ------------------------------


  • 2.  RE: TMF637: how to handle prices?

    TM Forum Member
    Posted Oct 13, 2020 10:15
    Hello Heinz,

    For me your sum-up is very clear and capture the rationale to use one or the other.
    Using ProductOfferingPrice refers product Cataog information so if you have a commercial catalog managing this data and applied 'catalog' price to the inventory this is probably the cleanest way to handle it. Oppositely if you do not have a catalog or if you have to manage tailor-made tariff (or overrrid efor whatever reason the catalog price) then the price could be useful.

    Cheers

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 3.  RE: TMF637: how to handle prices?
    Best Answer

    TM Forum Member
    Posted Oct 14, 2020 02:50
    Thanks Ludovic for this clear answer. Adding an important point:
    The Open APIs in general (and TMF637 in particular) are just that, interfaces. They don't say anything about the internal implementation of the APIs. So we should separate those concerns.

    From API perspective, I would say that the ProductPrice should always be populated on GET of Product (of course only where there is a price), so that a consumer has a clear and consistent way of understanding the prices being charged for the Product.

    From internal implementation perspective, you may decide to optimize/normalize storage in the product inventory by not storing prices in the inventory unless they were overridden. This strategy also helps when prices are updated, you make the update in a single place (the catalog).
    Alternatively, you may decide to optimize access speed and store the prices in the inventory, of course this means that market price updates will need to be replicated to the prices in the inventory.

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



  • 4.  RE: TMF637: how to handle prices?

    Posted Oct 15, 2020 03:20
    I agree wtih you all but before implementing any of the options it should be taken into account current customer installed base and its prices. Changing prices directly by reference to the catalog or doing a massive change over the different customers can have big consecuences. This is due to the fact that you may have contract restrictions with some customers so you cannot alter the prices. Commercial enrichment, bills, etc. may also be affected.

    CHeers.

    ------------------------------
    ------------------------------
    SANTIAGO LORENTE JURADO
    Pegasystems, Inc.
    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: TMF637: how to handle prices?

    TM Forum Member
    Posted Jun 09, 2021 00:50
    Edited by Anagha Gokhale Jun 09, 2021 01:53
    wrong thread