Oracle Business Applications

This is a good feature some of the industries can use to manage profitability of service or repairs. Especially industries where the service is resource and time intensive, it is good to track profitability of each service request.

This functionality is not integrated with GL in the form of journal entries yet. It just comes in the form of a report which can be run from the service request screen.

One of the limitation of this feature (as documented) is that this functionality only works with Standard Costing Method. Disappointed, I started tinkering to make this to work with average costing.  Essentially there are two issues in how the cost was sourced.
First issue is that org_id (operating unit) was passed instead of organization_id (inventory organization) to get the cost. If the operating unit is also classified as inventory org and you define cost for the item then there is no issue. But it is hardly true in real world (operating unit also classified as Inventory organization).

Second one is (not essentially a bug), costing method is not passed to the cst_cost_api to get the cost. When you do not pass this API simply assumes standard costing method. My argument is, if we know the organization to get the cost for the item, how hard it is to get the costing method and pass it to this API?

Once I fixed these two in the cs_cost_details_pvt (of course it is standard code), it simply works.

We just need to make sure to update the cost of these non-ttransactable items using average cost update process.

You can see the presentation here.

Here is the summary of all the articles that talk about service contracts integration with OM. Click on each link to see individual arcticles.

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 module’s 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!

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 call oe_line_fullfill.process_fulfillement. This in turn calls oe_line_fulfill.fulfill_line. This is exactly where the row gets inserted into oks_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.

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.

We all buy different kinds of stuff all the time. Especially when we buy high ticketed items like a computer, we expect that the vendor cover us for free for some time so that we can get any issue fixed free of cost. This is called warranty. Warranty is always free for a customer. Of course vendor covers this cost of risk in product pricing, which is not explicitly told. This quick article tells you what you need to create a warranty contract in Oracle.

What we need to create a warranty?
You basically need one coverage, two items, one Bill of Material and a sales order to ship.

Required Item Attributes Setup

The process is pretty simple. Once these setups are done just create a sales order and ship it. You will instance is either updated (if that was in inventory before which you shipped it) or you just fulfill the order (without shipping) and IB is created and warranty is created.

Some FAQ
Where is the warranty item taken from to create a warranty contract?
We do not enter warranty item in the order. It automatically is taken from the BOM for warranty creation.
If the product is fulfilled in different organizations, can they have different warranty periods?
Yes, you probably need a patch. Log a service request with support.
Do we have to ship the order line in order to create instance?
No. You can just fulfill the order which creates the IB instance (you need to use a workflow that has creation of instance as part of the workflow).
If this is a serial controlled item without shipping how is IB updated?
Upon fulfillment, instance is created without serial number. Instance can be updated later with a serial number later. This is a practice in software industry where we have nothing to ship as the orders can be fulfilled online. If that is the case, once the license key is registered, IB can be updated.