R12: Service Contract from Order Management Part I

In an earlier article I discussed how to create a warranty contract from Order Management. In this article I am discussing how to sell service and how to create service contracts from order management. Presentation is here. This presentation lasts for about 7 mins.

R12: Service Contract from OM Part II

This is the third one in the series of articles that I have been discussing on this topic. First we created Warranty Contract from Order Management, next was on creating a Service Contract from OM. In this article, I will just walk you through technical details of the process of creating service contracts from order management (not warranties). Proir to R12, ASO_ORDER_FEEDBACK_T (you can find an article here in this blog on the same) queue table was used to communicate order line information to CRM applications. Starting R12 the architecture is changed (from service contract creation perspective). Obviously ASO queue approach had issues. Once the order is booked, order lines were queued to be processed later by the respective subscribers. But once the queue is dequeued, and if there are any issues, the queue was lost and contract was never created. Sometimes IB was not updated as the customer product thought the order line is shipped or fulfilled and was stuck in the IB interface errors table due to some issues. Hence this IB is not visible for the program to create as covered product.

In R12 this queue is not used any more. Though the queue is still built when the order is booked, the queue is not used anymore for this process. But if you are using this process in 11i, all the existing queue details will be migrated to the new architecture when the upgrade happens from old to new architecture.

Going into the details, a new table is introduced to capture the eligible lines for service contract creation program:oks_reprocessing. When the order is shipped and fulfilled or just fulfilled, a record is created in this table for further processing. The record is created by fulfillement logic of the order management. So without fulfillment node in the order line workflow service contract cannot be created. From code perspective, oe_fulfill_wf.start_fulfillement called in the order line workflow will

calloe_line_fullfill.process_fulfillement. This in turn calls oe_line_fulfill.fulfill_line. This is exactly where the row gets inserted intooks_reprocessing. Fulfilling process

calls oks_omint_pub.interface_service_order_lines which inserts row into this table. The row is inserted for all the service items in the order line. These lines are identified by the item_category_code in order lines which is stored as SERVICE. From implementation perspective, fulfillment is a must in the order line workflow.

Once the row is available, we run the program Service Contracts Order Processing in Service contracts to create service contract. The code behind this program oks_ocint_pub.order_reprocess. This uses this table as the base and creates contract if everything is good. If the contract cannot be created for some reason, the record is left in this table for processing at a later point of time. A new screeen is provided to see the errored records for selecting and processing.

R12: Service Contract From OM Part III

Problem: How to bill a service contract that is created from Order Management? OK, you have seen how to create a service contract from order management and some technical details so far. What we have done so far is, understanding the standard functionality. Knowing this basic functionality is the key to understanding what we are going to discuss in this article. When a service contract is created from order management service line is always billed from order management. Let us take an example. Assume that you are on a shopping binge this weekend. On the list say you have 65 TV, one Black Berry and internet connection at home. When you walk into a store to buy a TV, you might end up buying a service contract apart from warranty that comes along with the product. We all do this to protect ourselves from the risks that we might encounter with the product. When we buy the service contract, we get billed for the service right there. We pay for it and get out with the TV. To enter the same transaction in the system, this is what we do: we enter the TV item in the first line and enter the service line in the next line and assign service reference information in the service tab of order lines. Once we fulfill the transaction this line goes to the receivables interface (ra_interface_lines_all) for it to be imported into the AR. The companies can recognize the revenue over the period of service contract by using the revenue contingencies or accounting rules. Good for the retailer in this industry that the out of the box functionality works here.

Say you next move on to buy a cell phone. As the deal says, you get the instrument for about $100 and there is a two year service contract. There is a base charge for about $50 per month and if you exceed the minimum number minutes usage you will be charged 10 cents for each minute of usage. I will discuss the usage at a later point of time. Let us talk about the base charge. The agreement is that the base charge invoice for $50 should be generated and sent to you every month. This is where the problem starts. Unlike service agreement for TV retailer cannot charge one time invoice for entire service contract amount in this case. A $50 dollar invoice needs to be generated every month. So we cannot create a service contract from order management in this case as this is expected to bill from Order Management and have to create this manually in Service Contracts or you have to extend either workflow in OM or by other means to create service contract. This disjointed process hurts productivity. Think about it, we create an order for the sale and service contract has to be authored manually in order to bill from the service contract for 2 years (we call this as bill schedule).

What can be done?

With the change in the way the service contracts are created from OM starting R12, there is a flexibility to automate this process. Please see the part II of this series to understand the technical details behind this process. The code behind the program (package oks_ocint_pub) has some extendable custom package. The good thing about this package (OKS_OMIB_INT_EXTNS_PUB) is that if the contract is successfully created, it gets contract ID, topline_id and subline_id as parameters to this procedure post_integration. That is it. If you understand the service contract modules data model you can manipulate the contract to make it eligible for billing again. So, when you are creating a service line in the order, you do not invoice it there, but you will only fulfill that line so that the contract can be billed from here.

What exactly happens behind the scenes to prevent the contract from billing into AR?
Contract is created Line is created with a covered line that has item instance which was shipped in the order. Bill schedules are created with date_completed pre-populated in the oks_level_elements.

oks_bill_cont_lines is pre-populated with the with btn_id (id from oks_bill_transactions) as -44 for contract line ID (topline_id). This is the same when we suppress the credits for a termination of contract line.

And finally there is a row created in the okc_k_rel_objs for the contract line id that is created. Billing program ignores these contract lines from being billed.

So we need to do this: Take care of the tables oks_bill_cont_lines and oks_bill_sub_lines. Take care of the table oks_level_elements (since date_completed is already populated). Take care of the table where related objects are populated (okc_k_rel_objs). And finally recreate the schedule so that the billing can happen every month for the period of the contract. Created a simple package that takes the out values from the post_integration procedure of the API OKS_OMIB_INT_EXTNS_PUB and did all the above. Contract got billed! That is it folks. You can download the code here. There is table script to capture the out variables of the API. Please note that this article provides you a guideline and not a complete solution!