Open APIs

 View Only

  • 1.  Feedback on Shopping Cart Transition to Order

    TM Forum Member
    Posted Nov 25, 2019 16:37

    Hi Experts,

    I would like to get your feedback on: TMF663 Rest API Specification for shopping cart (https://projects.tmforum.org/wiki/download/attachments/114641002/TMF663_Shopping_Cart_API_REST_Specification_R19.0.1.pdf?api=v2).  

    On page 6 we have a picture of a prospect purchasing a product, step 4 is to checkout the shopping cart i.e. the shopping cart becomes read only and is transformed into an order
    What API should I be using to checkout this shopping cart to create an order?

     

    In addition, I looked into TMF622 Product Ordering Management API REST Specification (https://projects.tmforum.org/wiki/download/attachments/114640797/TMF622_Product_Ordering_Management_API_REST_Specification_R19.0.1.pdf?api=v2) and I did not see a reference to shopping cart in these specification.


    In both the specifications I see basic operations to create, modify, get and delete entities, but not an API to transition the state of one entity to the other which is needed for the Buying experience (i.e. transition from cart to order) hence the above question.


    Many thanks!
    Sajitha



    ------------------------------
    Sajitha Nair
    Oracle Corporation
    ------------------------------


  • 2.  RE: Feedback on Shopping Cart Transition to Order

    TM Forum Member
    Posted Nov 26, 2019 03:45
    Hi Sajitha

    Looping in @Jacob Avraham, lead for Shopping Cart, and @Ludovic Robert, lead for Product Order.

    In general​, the Open API set does not deal with orchestration between different functional areas, it is expected that the consumer will handle that.

    Thus one can imagine that the consumer would call PATCH on Shopping Cart to set the status to checked out, and POST on Product Order to create the order with the content from the cart.

    You could of course create an orchestration layer that would expose a composite API that would take as input a shopping cart reference and return as output a created product order, while at the same time setting the cart status to checked out.

    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


  • 3.  RE: Feedback on Shopping Cart Transition to Order

    TM Forum Member
    Posted Nov 26, 2019 04:40
    Hello Sajitha, Jonathan,

    I will agree with Jonathan about dealing with API Orchestration  -> I expect the work done in the ODA team to help us on this and define interactions between component.

    On this one shoppingCart to productOrder transition  I still remember that we spend a lot of time discuss this transition - all company involved not completly aligned on the transition point from SC to PO.

    Probably a second round could occur with ODA inputs....

    Just speaking from perspective they are (at least) 3 distinct sequential events in buying process: 1/ A sales is detected  2/ Requester validated a cart (valid configured offerings priced) and 3/ Operater validated this cart (Party identified if not yet, address filled, payment captured, link to Billing Account, etc).
    Only this third event should trigger order fullfilment.  I tend to think that event 1 trigger a shopping cart (or retrieveing existing SC), and event 3 requires a productOrder (or a productOrder state change) but the management of event 2 could be discussed with ODA (right now with current API the PO is created and SC patched to remone ordered item... keeping only in SC the "save for later" item).

    Hope it helps.

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

    Original Message


  • 4.  RE: Feedback on Shopping Cart Transition to Order

    TM Forum Member
    Posted Nov 26, 2019 18:04
    Hi Johanathan, Ludovic,

    Thank you for the quick response.   What next steps do I take to get a sneak peak on the decisions made in the ODA team? 

    I am agreeing with the feedback you have Ludovic, but wanted to ask for a quick clarification - when the party address details are entered, am I understanding this step correctly in that these end up being updates to the cart entity and then there is a transition where the cart becomes read  only and is transitioned into an order entity?

    Many thanks!
    Sajitha

    ------------------------------
    Sajitha Nair
    Oracle Corporation
    ------------------------------

    Original Message


  • 5.  RE: Feedback on Shopping Cart Transition to Order

    TM Forum Member
    Posted Nov 27, 2019 02:31
    Hi Sajitha

    For more on ODA, best to engage with an ODA architect such as @Dave Milham.

    The party address details would be stored as contact medium on the party itself - both the cart and the order have a reference to the party​, so updating an address would not directly affect the cart or the order. Need to be careful here, since it is possible that an address change might affect the business or technical qualification and render an offering in the cart no longer valid. This of course depends on the detailed implementation and business requirements of the service provider.

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


  • 6.  RE: Feedback on Shopping Cart Transition to Order

    TM Forum Member
    Posted Nov 28, 2019 03:06
    Hello Sajitha
    To get back on your perspective: "when the party address details are entered, am I understanding this step correctly in that these end up being updates to the cart entity and then there is a transition where the cart becomes read only and is transitioned into an order entity?"
    My view is little bit different. I will probably remove the item from the shopping cart once they have been ordered (at least not visible by customer)  but shopping card will be still updateable for item(s) that has(ve) not yet been ordered ('save for later' as we often saw on eCommerce platform). I will not link the lifecycle of a shopping cart to a product order but more imagine a loose decoupling where a shopping cart will be 'always' active and order items will be built from it (each time a offer is ordered the corresponding SC item should not be anymore present in the SC).
    Just my perspective and I imagine other scenarios are possible.

    Hope it helps

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

    Original Message


  • 7.  RE: Feedback on Shopping Cart Transition to Order

    Posted Nov 27, 2019 03:46

    Hi Sajitha,

     

    At this time, to a larger extend TMF provides REST API design guidelines to support CRUD operations (sometimes task operations).

     

    Maybe you can leverage HATEOS pattern of extension and on POST/ submit of shopping card, the response can contain an entity of purchase order being returned.

     

    ------------------------------
    Javed

    Oracle CX Communications Industry Solutions,
    Any suggestions, recommendations, opinions and statements made by me on this forum are purely my personal, and do not reflect the position of the TM Forum or my employer.
    ------------------------------



    ------------------------------
    syed javed
    Oracle Corporation
    ------------------------------

    Original Message


  • 8.  RE: Feedback on Shopping Cart Transition to Order

    TM Forum Member
    Posted Nov 27, 2019 09:42

    Hi Sajitha and rest of the Experts!

    This is my first posting here, so forgive me potentially 'noobish' questions regarding the 'shopping basket'.

    1. Would the 'shopping basket' model be generic for all sort of sales including e.g. quoting based e.g. for b2b markets?
    2. Does shopping basket model allow separation of mandatory vs. optionalities'rows' ?
      1. meaning the shopping basket is accepted by customer itself or proxy-user configuring the basket, so that e.g. the choices are valid for e.g. order
    3. If shopping basket contains rows which have action to e.g. upgrade existing customers existing 'asset', how the 'asset' is linked in the data?
    4. How about relation offering-asset-(order specific information like addresses),
    5. how the versioning is handled e.g. if the order(s) event(s) will occur during the 'contracted period' ? E.g. offerings with end of new-sales can be still ordered because they were agreed once-upon-a-time and they can be found from the 'customer accepted' shopping basket?
    6. The REST json has 'hard coded' price variables, but how to enable variable definitions so that e.g. formats, decimals, units etc. can be presented in the data?
    7. Which of the variables are 'calculated' and 'to be recalculated in order' depending what options are chosen to the order from the 'shopping basket'?
    8. The REST json has the number values as numbers and this can pose a problem when the variables should be presented later on with all the 'decimals'. So should they be wrapped in "123,0000" string style?
    9. Is there toggle for language selection or similar for the json e.g. decimal etc. separators differ based on it? And how translations of the 'core generic shopping basket' will be done e.g. if the order needs to be 'localized'?
    10. When folding the cart content, is there parent_id for creating the hiearchy?
    11. If the shopping cart contains 'quantity' type of 'agreed limits' for creating e.g. orders, how those could be taken into account:
      1. e.g. minimum/maximum quantity to be ordered (e.g. could 0 for minimum quantity mean optionality?)
    12. If certain prices in the shopping cart are 'todays prices' e.g. when the order takes place the price should be based on that days price? How that will be marked in the shopping cart?
    13. If there are 'fast orderers benefits' e.g. certain prices are valid for certain amount of time from the time of 'accepting the cart/quote' how those will be treated in the transition for both sunny day (benefits valid) and rainy day (benefits expired)?
    14. Also in general could there be version of the shopping cart so that it can be said to be 'order entry validated' and which 'rows/cart items' require manual intervention when making order?
      1. this could be the case when the shopping cart configuration consists of 'solutions' coming from heterogenous systems/sources e.g. partly manually created not only via webshop catalogued approach?

    15. Also if the agreed options could be preconfigured for customers self-service based on the shopping basket, then how the agreed (valid) options would be carried over to later steps for the ordered (mandatory configuration). Sort of obey the spirit of the 'agreed cart'?

    16. Also if potentially possible to think about not copying (errorprone) information in steps from quote-contract-order but rather link/reference the ordered 'offerings' prices to 'contracted prices'.

    17. Also from the tracking point of view how to handle the handover to order so that it is easy to detect when certain 'shopping basket' is indeed ordered?

    Again sorry to step so late to this matter, but eagerly seeking 'one-size-fits-all' shopping basket implementation and regularly looking the awesum TMF rest api specs for light :)

    rgrds Paavo



    ------------------------------
    Paavo Muranen
    Telia Company
    ------------------------------

    Original Message