Open APIs

Expand all | Collapse all

Cease Reason / Instruction in order Management API

  • 1.  Cease Reason / Instruction in order Management API

    Posted Oct 20, 2021 05:08
    Hi All,
    Is there any guidance on how we send the Cease Reason / Instruction in the Order Management API's so that systems like Billing platform can be advised on whether to apply any termination charges or Contract related charges?

    ------------------------------
    Saravana Kumar
    ------------------------------


  • 2.  RE: Cease Reason / Instruction in order Management API

    TM Forum Member
    Posted Oct 21, 2021 05:01
    Before giving my thoughts i was wondering which order API is it you are referring to​, 622? 641?

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 3.  RE: Cease Reason / Instruction in order Management API

    Posted Oct 21, 2021 08:38
    Hi David, My use case is mainly for TMF622, but i think as a pattern it works for both? Though it doesn't make any real value for 641.

    ------------------------------
    Saravana Kumar
    ------------------------------



  • 4.  RE: Cease Reason / Instruction in order Management API

    TM Forum Member
    Posted Oct 21, 2021 11:03
    We can create an NRC in ordering system and  add it when those reasons are selected. the NRC part number will be sent to billing and customer will be charged price of that.

    ------------------------------
    Asjad Mohammad
    Accenture
    ------------------------------



  • 5.  RE: Cease Reason / Instruction in order Management API

    Posted Oct 22, 2021 00:46
    Asjad,
    Thanks for your comments.

    When offers are defined, it would have
    • Recurring Charge
    • One-Time activation charge
    • Termination Charge
    • Contract and HTT Charge [Ie if customer breaks contract then the customer has to pay based on the contract term that's left]
    And these are then downloaded to CRM and Billing Systems. At the moment the rules to calculate and apply Termination Charge and HTT Charge is within Billing. And this can be applies by default or can be overridden based on some inputs like Cease Reason / Instruction. For example if the
    • Cease Reason / Instruction is Default, then apply Termination Charge and HTT Charge.
    • Cease Reason / Instruction is Transfer-out, then apply Termination Charge and HTT Charge.
    • Cease Reason / Instruction is Bereavement, then don't apply Termination Charge and HTT Charge.
    • Cease Reason / Instruction is Price Rise, then don't apply Termination Charge and HTT Charge.
    So when i send a Cease Order to Billing, i need a way to send these information so that they can apply the business rules accordingly.

    What you are saying is let the CRM system have these rules and then let Billing whether to apply these or not. May be that's an option, but i am trying to find an option for the above implementation.

    ------------------------------
    Saravana Kumar
    ------------------------------



  • 6.  RE: Cease Reason / Instruction in order Management API

    TM Forum Member
    Posted Oct 22, 2021 00:31
    I think it depends on how you model the Order Structure. One way to implement the Termination Charge is to create it as a separate Line Item and add it in the Terminate Order. For the cases where the Termination charge don't apply, this line item will not be added to the Order and Billing System will not apply this charge. This approach will provide a clean decoupling and will provide more flexibility to the Customer Care Agent to submit the right Orders from CRM itself.

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 7.  RE: Cease Reason / Instruction in order Management API

    Posted Oct 22, 2021 06:18
    I think this is an interesting question in the context of the usage of the APIs.

    When these APIs are internal to a business the relevant application or agent can make the decision about one off termination charges and create the order accordingly.

    In a B2B2X scenario I would suggest that you don't want the other party to be to necessarily decide what they are to be charged. So then you do need to know explicitly why they are terminating a service early.


    ------------------------------
    Derrick Evans
    ------------------------------



  • 8.  RE: Cease Reason / Instruction in order Management API

    TM Forum Member
    Posted Oct 22, 2021 07:23
    Edited by Matthieu Hattab Oct 22, 2021 09:44
    there are many possible processes in regards to charge customers termination fees (both for the amount value and for the charge)

    but since your question is specific to passing the termination reason to billing you could use API 622's cancellationReason (which can be also used as "termination reason" or any other use case (annulment, change offer etc)).
    Nah, that's an Order header field and should only be use to cancel the order itself, not the products.

    ------------------------------
    Matthieu Hattab
    Altibox AS
    ------------------------------



  • 9.  RE: Cease Reason / Instruction in order Management API

    Posted Oct 22, 2021 07:58
    Hello
    I noticed cancellation reason in the spec. It is a reasonable suggestion to reuse that field but I suspect it could lead to confusion. For example what happens if one wishes to cancel an order which is to terminate a service?

    I suspect an extension is in order here but let me describe another scenario not directly related to see if it provokes other thoughts.

    In the UK there are APIs for B2B2X scenarios where a 'cessation reason' to is expressly used.

    In one scenario it allows a reseller to say why the service is being terminated early. Bereavement is one example but poor service is another.

    But there is also another related to gaining provider led transfer of service from an existing provider as part of service portability.

    In this scenario the gaining provider raises an order to take over the service. The underlying network provider then orchestrates the creation of a cease/termination order for the existing provider to notify them of the loss of a customer.

    In this scenario the network provider advises of the reason for the loss in the cessation reason stating the end user customer is taking their business elsewhere.

    Moreover if the losing provider can legitimately claim the transfer is incorrect they can cancel the cease order giving a separate cancellation reason. These can include claims that the customer has been missold something or that the customer is being held to their contract and has refused to pay termination charges choosing to stay instead.

    ------------------------------
    Derrick Evans
    ------------------------------



  • 10.  RE: Cease Reason / Instruction in order Management API

    Posted Oct 22, 2021 08:02
    Hi Matthieu, Thanks for your comments.

    I thought about cancellationReason. And I thought it should be used when you are posting cancelProductOrder.
    cancellationReason --  A string. Reason why the order is cancelled. This is used when order is cancelled.

    So what should be used when you POST productOrder where you got productOrderItem.action as delete.

    Is your recommendation reuse cancellationReason in both the scenarios?


    ------------------------------
    Saravana Kumar
    ------------------------------



  • 11.  RE: Cease Reason / Instruction in order Management API

    TM Forum Member
    Posted Oct 22, 2021 09:41
    Hi Saravana,
    Good catch!
    Do keep cancellationReason together with cancellationdate and State to properly manage the order lifecycle.
    This would be in line the use case described by @Derrick Evans

    In the past, we changed our Order API we extended the resource model to include 3 new fields: ReasonForTerminationL1, ReasonForTerminationL2 and ReasonForTerminationL3. You can add your field in the ProductRefOrValue resource, next to... TerminationDate!


    ------------------------------
    Matthieu Hattab
    Altibox AS
    ------------------------------



  • 12.  RE: Cease Reason / Instruction in order Management API

    TM Forum Member
    Posted Oct 25, 2021 05:46
    Edited by Harry Chen Oct 25, 2021 05:46
    A product order can have one to many product order items, which in turn (optionally) have many sub product order items.

    1. Termination can happen at the order level. It means all product order items and sub items must have the same termination reason and date. order cancellation is at this level. product termination really should be at the order item level as far as I understand the intention of the product order API.
    2. Termination can happen at the (root) order item level as well. It means different (root) order items may have different termination reasons and dates. Extension is expected at this level as @Matthieu Hattab mentioned.
    3. Termination at the sub order item level is modification of product order item.

    Harry Chen
    Hansen Technologies​​

    ------------------------------
    Harry Chen
    Hansen Technologies
    ------------------------------



  • 13.  RE: Cease Reason / Instruction in order Management API

    TM Forum Member
    Posted Oct 25, 2021 05:48
    Very interesting discussion. For clarity, let's distinguish between canceling an ProductOrder and ceasing (terminating, canceling, etc.) a Product.

    Canceling ProductOrder
    • Canceling a ProductOrder means that the customer is no longer interested in continuing with the order and its contained items (which may be for new Products, changing Products, suspending Products, etc.).
    • For this we have a task resource CancelProductOrder, and the resource includes an attribute cancellationReason.
    • Order cancellation may or may not be possible, depending on if points of not return have been reached
    • Order cancellation may (in principle) have associated fees, although in the current Open API model I'm not sure that this is represented.
    Ceasing Product
    • Means the customer is no longer interested in receiving the Product's benefits and paying for the Product
    • As mentioned in this thread, there may be termination fees, including due to breaking of commitment, damage to CPE, etc.
    • These fees would be modeled in the catalog (TMF620) as ProductOfferingPrice, and need to be instantiated only when the order item action type represents termination. I'm not sure that ProductOfferingPrice allows this to be sufficiently specified, although maybe the attribute priceType is good enough.
    • An additional field on order item could be added, reason, which would allow refinement of the rules as to when to instantiate the termination fees (e.g. reason Deceased would presumably cause fees to be waived).
    So the basic structures are there to support the business use cases, but some details are still missing from the Open API model.
    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.
    ------------------------------