SERVICE CONTRACTS What is service contract?

Oracle Service Contracts provides a complete contract authoring execution solution to manage warranties, extended warranties, usage, subscription services, as well as complex service agreements. A contract in Oracle Service Contracts comprises: a header one or more lines one or more sub lines Header: The header is where you enter a brief description and specify the contract duration. Header consists of: Parties: Enter information about the customer, including the bill to and ship to information for the contract. Pricing/Billing: Assign a price list and various accounting rules for pricing and\billing contracts. Renewals: Define the renewal rules applied during manual or automatic renewal of the contract. Administration: Define administrative components used to process the contract, such as the QA checklist, contract groups, and workflow. Security/Text: Grant contract access by the resource group or user level. Lines: Lines list the individual service, usage, and subscription items included in the contract. A single contract can have multiple lines. There are three types of lines: Service lines: Cover a broad category of items that can include activities such as field service, depot repair, call center, technical support, or any other user-defined business activities Usage lines: Charge customers for usage. For example, a photo copier company might wish to charge for the number of copies made within a period. Subscription lines: Cover subscriptions for both tangible and intangible items.

What are tangible items? Tangible items include magazines, collateral, or any other physical item that can be shipped through Oracle Order Management. What are intangible items? Intangible items can be collateral sent via e-mail. Sub lines

Sub lines specify what the service covers or the counters where the usage is tracked. It consists of: Service lines: Sub lines for service lines specify what the service covers. A service line can cover a party, a customer, a site, a system, a product, or an item. Usage lines: Sub lines for usage lines specify the counters where the usage is tracked. Subscription lines: Subscription lines do not have sub lines. Service contract life cycle: Creating a Contract Approving Contracts Extending and Renewing Contracts Terminating Contracts Managing the Contract Lifecycle Creating a Contract You can create a contract manually. In addition, a contract can be created automatically through Oracle Order Management or by creating a product that has a warranty in Oracle Install Base. Creating a Template from a Contract A template makes it possible for you to speed up the contract creation process by filling in frequently used values. Approving Contracts This group of topics explains the contract approval process. Oracle Service Contracts leverages Oracle Workflow to automate the contract approval process. After you author a contract you must: Submit the contract for approval. Secure approval on the contract. Obtain a signature on the contract. The Submit for Approval function launches the quality assurance (QA) check. If the QA check is successful you can continue the approval process, which submits the contract to the approval workflow. Extending and renewing contracts: Contract Extensions: Oracle Service Contracts allows you to extend the duration of a contract or a contract line without having to submit the contract to the approval workflow. A contract must be in a status of Active, Signed, or Expired to be extended. Contracts in a status of Entered, Canceled, or Terminated are examples of contracts that cannot be extended. Contract Renewals The process of renewing a contract involves making a copy of an existing, active contract at a point in time. The dates are changed to reflect a period of time similar to the existing contract; beginning on the first day after the existing contract expires. Terminating Contracts

You can terminate a contract, a contract line, or a contract subline. The termination date must fall between the start and end date of the service or services being terminated . Managing the Contract Lifecycle: You must manage your contracts on an ongoing basis. You may need to change coverage, durations, versions You can streamline and control administrative processes, by leveraging functionality that manages updates and changes. Which tables and views contains the contract lines, billings schedule and invoices of a service contracts? Table: OKC_K_HEADERS_B,OKS_K_HEADERS_B Product: OKC - Contracts Core Description: Top level of a contract structure and groups all the lines and terms and conditions of a contract. Implementation/DBA Data: OKC.OKC_K_HEADERS_B Sts_code,id,contract_number,start_date and end_date Table: OKC_K_ITEMS object_id1csi_item_instances.instance_id Product: OKC - Contracts Core Description: Contract items Implementation/DBA Data: OKC.OKC_K_ITEMS Table: OKC_K_LINES_B Product: OKC - Contracts Core Description: Deliverable ITEMS grouped into a logical set usually defined by unitary price, delivery or some other classification. Implementation/DBA Data: OKC.OKC_K_LINES_B Chr_iddnz_chr_id,cle_id Table: OKS_BILL_SUB_LINES Product: OKS - Service Contracts Description: Related to a lower level contract line eg. coverage level or product. Implementation/DBA Data: OKS.OKS_BILL_SUB_LINES Table: OKS_BILL_CONT_LINES Product: OKS - Service Contracts Description: Records which are sent to AR. Implementation/DBA Data: OKS.OKS_BILL_CONT_LINES Table: OKS_BILL_SUB_LINE_DTLS Product: OKS - Service Contracts Description: The detail of quantities and monetary amounts either regular or adjustment. Implementation/DBA Data: OKS.OKS_BILL_SUB_LINE_DTLS Table: OKS_BILL_TRANSACTIONS

Product: OKS - Service Contracts Description: The transaction (invoice, credit etc.) which is eventually received from AR. Implementation/DBA Data: OKS.OKS_BILL_TRANSACTIONS Table: OKS_BILL_TXN_LINES Product: OKS - Service Contracts Description: Holds the actual transaction amount and tax returned from AR. Implementation/DBA Data: OKS.OKS_BILL_TXN_LINES

Table: OKS_STREAM_LEVELS_B Product: OKS - Service Contracts Description: Service Contracts Billing Stream Levels Implementation/DBA Data: OKS.OKS_STREAM_LEVELS_B APIS IN SERVICE CONTRACTS: OKS_CONTRACTS_PUB.Create_Contract_Header: This API is used to create contract header information. The API is called using P_K_Header_Rec, P_Header_Contacts_Tbl, P_Header_Sales_Crd_Tbl and P_Header_Articles_Tbl. These contracts can be brought in as ENTERED, which would mean the process owners would have to submit the contract for approval using Contracts Approval Workflow. OKS_CONTRACTS_PUB.Create_Service_Line This API is used to create Contract Service Line for each contract header. The API is called using P_K_Line_Rec, P_Contact_Tbl and P_Line_Sales_Crd_Tbl. OKS_CONTRACTS_PUB.Create_Covered_Line This API is used to create Covered Lines for each service line you create. Before you call this API you are required to set values for P_K_Covered_Rec and P_Price_Attribs_In. The link from contract to order is stored in OKC_K_REL_OBJS. It can do both Service Header - Order Header and Service Line - Order Line. Standard APIs in SC Module OKC_CONTRACT_PUB (headers, lines, sub-lines) This is used for creating Headers etc. OKC_RULE_PUB (rule groups, rules) OKC_CONTRACT_ITEM_PUB (items) OKC_CONTRACT_PARTY_PUB (customers, contacts) OKC_CONTRACT_GROUP_PUB (groupings) OKS_SALES_CREDIT_PUB (sales credits) OKS_CONTRACTS_PUB (billing schedule)

Core Tables OKC.OKC_K_HEADERS_B OKC_K_HEADERS_TL OKC.OKC_K_LINES_B OKC.OKC_K_LINES_TL OKC.OKC_RULE_GROUPS_B OKC.OKC_K_RULES_B OKC.OKC_K_ITEMS OKC.OKC_K_GRPINGS OKC.OKC_K_PARTY_ROLES_B OKC.OKC_K_HISTORY_B OKC.OKC_K_PROCESSES OKS.OKS_K_SALES_CREDITS OKS.OKS_LEVEL_ELEMENTS To create billing schedules through the API: OKS_CONTRACTS_PUB.CREATE_BILL_SCHEDULE. This API creates billing schedules for both sub line and service line. It creates billing streams and individual billing lines. For updating billing schedules, we can use: OKS_BILL_SCH.CREATE_BILL_SCH_RULES. This API also creates billing schedules for both sub line and service line The only difference between the two APIs is that the second API always deletes already existing billing schedules if present and then creates fresh ones. When schedule is already created and if you call OKS_BILL_SCH.CREATE_BILL_SCH_RULES for updating then what would happen is it would create additional billing streams and one would get to see two billing streams instead of a single one. Billing Schedules : A billing schedule determines when the customer is billed for the services they receive. For contracts with service lines you can bill the customer either at the line level or the subline level, but for contracts with usage lines you can bill only at line level. For service lines, this means that you can bill at the level of the service that is sold to the customer (called the Top Level in the application) or individually at the level of each of the items that is covered by that service (Covered Level), be it an individual item, a system, a covered location, an account, or party.

APIs availability in Oracle Service Contracts(OKS)

Line Creation : You creating lines you can this api OKS_CONTRACTS_PUB.CREATE_SERVICE_LINE Sub Line Creation : This is important when underline item is IB track able then we can create covered product sub line with IB link established. API you can use is: OKS_CONTRACTS_PUB.CREATE_COVERED_LINE UPDATING CONTRACT HEADER - You can use okc_contract_pub.update_contract_header API to Update contract Header okc_contract_pub.update_contract_header ( p_api_version => 1.0, p_init_msg_list => okc_api.g_true, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data, p_restricted_update => okc_api.g_false, p_chrv_tbl => l_chrv_tbl_in, x_chrv_tbl => l_chrv_tbl_out); UPDATING CONTRACT LINE - You can use okc_contract_pub.update_contract_line API to Update contract Lines okc_contract_pub.update_contract_line ( p_api_version => 1, p_init_msg_list => OKC_API.G_TRUE, p_restricted_update => OKC_API.G_FALSE, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data, p_clev_tbl => l_clev_tbl, x_clev_tbl => l_x_clev_tbl ); CASCADE DATE -You can use oks_bill_sch.cascade_dates_sll to cascase date in billing agreement(schedule). You just need to pass only the contract line ID oks_bill_sch.cascade_dates_sll ( p_top_line_id => <OKS Contract Line ID>, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data );

DEFAULTING ATTRIBUTES FROM LINES TO SUBLINES : You can use below API for daulting attributes oks_attr_defaults_pvt.default_lines_to_sublines ( lines_sublines_tbl => l_line_table, x_return_status => l_return_status, x_msg_tbl => l_msg_tbl ); CREATING CONTACT AT CONTRACT HEADER LEVEL :You can use okc_contract_party_pub.create_contact to create contact at header. okc_contract_party_pub.create_contact ( p_api_version => 1, p_init_msg_list => fnd_api.g_true, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data, p_ctcv_rec => l_ctcv_rec, x_ctcv_rec => l_x_ctcv_rec ); UPDATING CONTACT AT CONTRACT HEADER LEVEL :You can use okc_contract_party_pub.update_contact to create contact at header. okc_contract_party_pub.update_contact ( p_api_version => 1, p_init_msg_list => OKC_API.G_FALSE, x_return_status => l_return_status, x_msg_count => l_msg_count, x_msg_data => l_msg_data, p_ctcv_rec => l_ctcv_rec, x_ctcv_rec => l_x_ctcv_rec ); CREATING CONTACT E-MAIL ADDRESS AT CONTRACT HEADER LEVEL :You can use OKS_EXTWAR_UTIL_PUB.Contact_Point to create contact at header. OKS_EXTWAR_UTIL_PUB.Contact_Point ( p_api_version => 1, p_init_msg_list => 'T', P_commit => 'F', P_contact_point_rec => l_cpoint_rec, x_return_status => l_return_status, x_msg_count => l_msg_count,

x_msg_data => l_msg_data, x_contact_point_id => l_x_contact_point_id ); Sales Credit : For creating sales credit separately, we will have to use API:OKS_SALES_CREDIT_PUB.INSERT_SALES_CREDIT.

INSTALL BASE Install Base is a product to track an Item from Cradle to grave. Lets say you want to track a component hard drive in a computer, you can do so once you have the item set up in Inventory as trackable. Oracle Install Base is an item instance life cycle tracking application that facilitates enterprise-wide life cycle item management and tracking capability. Oracle Install Base tracks an instance from the time that it is received in inventory, in work in process, in projects, at customer sites, and throughout the return and repair process. It records a history of changes to tracked items and supports the creation and maintenance of Oracle Install Base configurations. Oracle Install Base is a centralized repository of information for an item instance and its tracking details including location, status, ownership, party, account and contact relationships, configuration data, and the change history of customer items or corporate assets. The application includes drill-down capability to obtain details of inventory, work in process, and order management transactions affecting an item's tracking attributes. Oracle Install Base provides links to detailed information from contracts, service requests, repair orders initiated for an item instance, and counters associated with the item instance. FEATURES OF ORACLE INSTALLED BASE Oracle Installed Base is an item instance life cycle tracking application that facilitates enterprise-wide life cycle item management and tracking capability Basic Tracking You specify which items you want to track in the Master Item list in Oracle Inventory. Subsequently, when a particular real-world instance of the item is created, an item instance record is created in Oracle Installed Base. Any significant changes to the item instance will also be recorded in Oracle Installed Base. Item Instance Movement Tracking Oracle Installed Base can track an item instance from the time that it is received in inventory, in work in process, in projects, at customer sites, and throughout the return and repair process

Tangible Items Item instances can be used to track tangible items, that is, physical, real-world objects, that can be assembled and shipped, such as computers, engines, machine parts, and soon. Intangible Items Item instances can be used to track intangible items such as software, services, licenses, and agreements. For example, a telephone number can have different services such as call waiting and conference call. These can all be defined and tracked as components of the telephone service. Serialized Items When a trackable item is defined in Oracle Inventory as serialized, each item instance derived from that item requires a unique serial number and individual tracking. The item instance will always have a quantity of 1. Non-Serialized Items When a trackable item is defined in Oracle Inventory as non-serialized, it is typically for smaller objects whose real-world instances do not require individual tracking. For example, a screw could be defined as a non-serialized, trackable item; an order for 100screws would result, after order shipping, in the creation of one item instance, with quantity 100. See also Serialization and Levels of Tracking
Instance Records the Item Instance Details of an IB instance Table: CSI_ITEM_INSTANCES Transaction Install Base Transaction Log Table: CSI_TRANSACTIONS Csi_transactions Transaction_id Transaction_type_id Csi_txn_types Transaction_type_id Csi_item_instances_h Instance_history_id Instance_id Transaction_id Csi_item_instances Instance_id Inventory_item_id Valid_organization_id Serial_number Instance_status_id Location_id Instance Relationship Defines the instance to instance relationships Table: CSI_II_RELATIONSHIPS Csi_item_instances Instance_id Csi_ii_relationships Relationship_id

Subject_id Relationship_type_code Object_id Csi_ii_relation_types Relationship_type_code Csi_ii_relationships_h Relationship_history_id Relationship_id Transaction_Id Csi_transactions Transaction_id Instance Party relationship Defines the relationship between Instance and party Table: CSI_II_PARTIES Instance Party accounts Defines the Instance to account (party account) association Table: CSI_IP_ACCOUNTS Csi_item_instances Instance_id Csi_ip_accounts_h Ip_account_history_id Ip_account_id Transaction_id Csi_ip_accounts Ip_account_id Instance_party_id Party_account_id Csi_i_parties Instance_party_id Relationship_type_code Instance_id Party_id Csi_transactions Transaction_id Csi_i_parties_h Instance_party_history_id Instance_party_id Transaction_id

API's
CSI_ITEM_INSTANCE_PUB Create Item Instance Update Item Instance Expire Item Instance Get Item Instance Get Item Instance Details

Copy Item Instance CSI_II_RELATIONSHIPS_PUB Create Relationship Update Relationship Expire Relationship CSI_SYSTEMS_PUB Create System Update System Expire System Get System