Oracle CRM Service Contracts Queries

Oracle CRM Service Contracts Queries

SERVICE CONTRACTS QUERIES..................................................................3 SERVICE CONTRACT HEADER – TABLE OKC_K_HEADERS_ALL_B................7 SERVICE CONTRACT HEADER – ITEM VALIDATION ORGANIZATION............8 SERVICE CONTRACT HEADER – OKS_K_HEADERS_B..................................9 SERVICE CONTRACT HEADER – PARTY INFORMATION..............................11 SERVICE CONTRACT HEADER – BILL TO / SHIP TO INFORMATION............12 SERVICE CONTRACT HEADER – CUSTOMER CONTACT INFORMATION......13 SERVICE CONTRACT HEADER – VENDOR CONTACT INFORMATION..........14 SERVICE CONTRACT HEADER – PRICING / BILLING INFORMATION...........15 SERVICE CONTRACT HEADER – RENEWAL TAB........................................19 SERVICE CONTRACT HEADER – RENEWAL TAB........................................21 SERVICE CONTRACT HEADER – RENEWAL TAB........................................22 SERVICE CONTRACT HEADER – ADMIN TAB.............................................24 SERVICE CONTRACT LINES – INFORMATION.............................................25 SERVICE CONTRACT LINES – COVERAGE INFORMATION..........................27 SERVICE CONTRACT LINES – COVERAGE INFORMATION..........................28 SERVICE CONTRACT LINES – HOW TO IDENTIFY COVERAGE FOR A LINE. 29 SERVICE CONTRACT LINES – RELATIONSHIP BETWEEN COVERAGE HEADER AND LINE.........................................................................................................30 SERVICE COVERAGE; COMPLEX COVERAGE QUERY.................................31 SERVICE COVERAGE; COMPLEX COVERAGE QUERY.................................32 SERVICE CONTRACT LINES – ACCOUNTS TAB (ITEM NAME).....................34 SERVICE CONTRACT LINES – ACCOUNTS TAB (BILL TO / SHIP TO)...........35 SERVICE CONTRACT LINES – EFFECTIVITIES TAB (INVOICE TEXT)............36 SERVICE CONTRACT LINES – ACCOUNTS TAB (CONTACT INFORMATION).37 SERVICE CONTRACT LINES – ACCOUNTS TAB (CONTACT INFORMATION).38 SERVICE CONTRACT LINES – ACCOUNTS TAB (CONTACT INFORMATION).39 SERVICE CONTRACT SUBLINES – (COVERED) PRODUCT INFORMATION...40 SERVICE CONTRACT LINES – BILLING STREAM.........................................44 SERVICE CONTRACT LINES – BILLING STREAM.........................................45 SERVICE CONTRACT LINES – BILLING SCHEDULE.....................................46 SERVICE CONTRACT LINES – STREAM / SCHEDULE QUERY......................47 SERVICE CONTRACT LINES – STREAM / SCHEDULE QUERY......................48 SERVICE CONTRACT BILLING TABLES......................................................50 SERVICE CONTRACT BILLING TABLES......................................................51 SERVICE CONTRACT BILLING TABLES......................................................52 SERVICE CONTRACT BILLING TABLES......................................................53 E. Receivables Interface Data..................................................................55 G. Order Details for Contracts Created from Order Management............56


SERVICE CONTRACTS QUERIES We will create a Service Agreement. In each step of the process we will examine the rows that are created in each table and pertinent columns that are frequently referenced. How to query service contracts tables and tables from other schemas to find underlying data about contract headers, lines, sublines and contract billing in 11.5.10. (For R12 queries please see Note 816374.1). This note gives a variety of queries which can be used to find the required data for a particular contract. In the SQL statements given, represents text that needs to be replaced with the actual values indicated between the brackets. For example, if you want to execute a query for a contract with number Test1, then whenever you see in the SQL below, replace it with Test1.

Sections in this note are: A. Contract Header Data B. Contract Line Data C. Contract Subline Data D. Contract Billing Data E. Receivables Interface Data F. Subscription Contracts

Table: OKC_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 Table: OKC_K_ITEMS 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 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 Table: OKS_REV_DISTRIBUTIONS Product: OKS - Service Contracts Description: Database table used for storing revenue distribution information for service contract lines.


Implementation/DBA Data: OKS.OKS_REV_DISTRIBUTIONS Further information on these tables can be found on eTRM Technical Reference available via My Oracle Support. The eTRM contains also the following information of the tables and ERD Diagrams: - OKS - Service Contracts - R11510 Service Contracts ERD.pdf - sub_erd_billing.pdf - sub_erd_billing_profile.pdf - sub_erd_defaults.pdf - sub_erd_order_details.pdf - sub_erd_sales_credit.pdf When AutoInvoice has been run program RAXTRX takes transactions that are on table RA_INTERFACE_LINES_ALL, validates them and if valid, passes the information into the AR tables, - RA_CUSTOMER_TRX_ALL - RA_CUSTOMER_TRX_LINES_ALL - RA_CUST_TRX_LINE_GL_DIST_ALL - RA_SALESCREDITS_ALL - AR_PAYMENT_SCHEDULES_ALL For terminations, transactions also create records on AR_RECEIVABLE_APPLICATIONS_ALL. An example of a query can be: SELECT rcta.trx_number invoice_no, rctla.line_number invoice_line_no, txn.bill_instance_number, rctla.inventory_item_id, oks_hd.contract_number, oks_hd.contract_number_modifier, oks_ln.line_number cont_line_no, cii_oks.instance_id, cii_oks.serial_number sn FROM okc_k_headers_b oks_hd, okc_k_lines_b oks_ln, oks_k_lines_b oks_ln_sub, okc_k_items oki, oks_bill_txn_lines txn, oks_bill_sub_lines bsl,


okx_install_items_v ocsi, csi_item_instances cii_oks, ra_customer_trx_all rcta, ra_customer_trx_lines_all rctla WHERE rctla.customer_trx_id = rcta.customer_trx_id AND rctla.interface_line_attribute1 = oks_hd.contract_number(+) AND NVL (rctla.interface_line_attribute2, '') = NVL (oks_hd.contract_number_modifier(+),'') AND rctla.interface_line_attribute3 = txn.bill_instance_number(+) AND bsl.cle_id = oks_ln.ID AND NVL (txn.bsl_id, 999) = DECODE (txn.bsl_id, NULL, 999, bsl.ID) AND txn.bcl_id = bsl.bcl_id AND oks_ln.ID = oks_ln_sub.cle_id(+) AND oks_ln.ID = oki.cle_id(+) AND oki.object1_id1 = ocsi.id1(+) AND oki.object1_id2 = ocsi.id2(+) AND ocsi.instance_id = cii_oks.instance_id(+) AND rcta.trx_number = '&your_trans_num' AND oks_hd.contract_number = '&your_contr_num'


SERVICE CONTRACT HEADER – TABLE OKC_K_HEADERS_ALL_B NAV: Contract Administration / Launchpad using the Service Contracts Manager responsibility. Enter the header information and nothing more.

This query provides some of the header level information: R12 select * from OKC_K_HEADERS_ALL_B where contract_number = '23572'; 11i select * from OKC_K_HEADERS_B where contract_number = '23572'; Two important columns in OKC_K_HEADERS_ALL_B are the authoring_org_id and the inv_organization_id. The authoring_org_id will always be the org id that matches the Vendor name. The inv_organization_id is the inventory validation org, a value that can be seen in Order Management. Note: In release 11.5.10, the table name is OKC_K_HEADERS_B. In R12, the table name is OKC_K_HEADERS_ALL_B. This was done so that Service Contracts can use the MO: Security Profile to control which organizations are accessible from a given responsibility. There is a synonym from OKC_K_HEADERS_B to OKC_K_HEADERS_ALL_B. Queries in R12 should reference OKC_K_HEADERS_ALL_B unless client_info is set to the appropriate organization. A. Contract Header Data SELECT * FROM okc_k_headers_b WHERE contract_number = '&contract_number' AND contract_number_modifier = '&contract_modifier';


SERVICE CONTRACT HEADER – ITEM VALIDATION ORGANIZATION NAV: Setup / System Parameters / Values. All services and products must be defined / assigned to this organization. Use this method to identify the Item Validation organization for an operating unit. The Operating Unit that appears in this form is the profile setting MO: Operating Unit.


SERVICE CONTRACT HEADER – OKS_K_HEADERS_B OKS_K_HEADERS_B has information that was once stored in the rules tables in early product releases. Rule Groups had one or more rules. Information such as credit card numbers, tax codes, invoicing rules, etc. were stored in individual rows in OKC_RULES_B. Similar rules were consolidated in OKC_RULE_GROUPS_B. Due to performance issues, this information was moved to OKS_K_HEADERS_B (and OKS_K_LINES_B at the line level). It is a good idea to run queries from both tables and save them in a spreadsheet so that changes can be observed as additional information is entered in the contract. select oks.* from OKC_K_HEADERS_ALL_B k, OKS_K_HEADERS_B oks where contract_number = '23572' and k.id = oks.chr_id; In most tables, the column dnz_chr_id maps to the column id in OKC_K_HEADERS_ALL_B. In this table, the column is chr_id. A. Contract Header Data A1. This SQL takes data from views rather than from actual contracts tables and is useful for reviewing data but not ideal for verifying if base tables hold correct data. SELECT CONTRACT_NUMBER "Contract" , TO_CHAR( id ) "Id" , SHORT_DESCRIPTION "Description" , INV_ORGANIZATION_ID "Organization Id" , STS_CODE "Status", scs_code , CURRENCY_CODE "Currency" , TO_CHAR( DATE_TERMINATED, 'DDMONYYYY' ) "Date Terminated" , TRN_CODE , TO_CHAR( START_DATE, 'DDMONYYYY' ) "Start Date" , TO_CHAR( END_DATE, 'DDMONYYYY' ) " End Date" , UPG_ORIG_SYSTEM_REF , PRICE_LIST_ID , BILL_TO_SITE_USE_ID , SHIP_TO_SITE_USE_ID , PAYMENT_TERM_ID , ACCT_RULE_ID , INV_RULE_ID , AR_INTERFACE_YN , CLASS_MEANING , TEMPLATE_YN , HOLD_BILLING FROM oks_auth_headers_v WHERE CONTRACT_NUMBER like '';


OKS_AUTH_HEADERS_V is not a table but a view. This view is comprised of table OKC_K_HEADERS_B , OKC_K_HEADERS_TL , OKC_STATUSES_V and OKC_SUBCLASSES_V. SERVICE CONTRACT HEADER – PARTY INFORMATION The vendor party is automatically populated when the cursor is positioned in the Parties tab. Select the entry for party role = Customer.

Run this query: select pty.rle_code, pty.object1_id1 from OKC_K_HEADERS_ALL_B k, OKC_K_PARTY_ROLES_B pty where k.id = pty.dnz_chr_id and pty.cle_id is null and k.contract_number = '23572'; This information is returned: RLE_CODE OBJECT1_ID1 ----------------- -----------------VENDOR 204 CUSTOMER 4429 As you can see, object1_id1 lists the org_id for a vendor and the party number for a customer.


SERVICE CONTRACT HEADER – BILL TO / SHIP TO INFORMATION Run this query before and after entering the Bill To and Ship To Information in your contract. select bill_to_site_use_id, ship_to_site_use_id from OKC_K_HEADERS_ALL_B where contract_number = '23572'; As you can see, the information is stored in OKC_K_HEADERS_ALL_B.


SERVICE CONTRACT HEADER – CUSTOMER CONTACT INFORMATION Create a customer contact.

Run this query to identify the contact: select cro_code "Contact Role", ct.jtot_object1_code, object1_id1 "Contact ID" from OKC_CONTACTS ct, OKC_K_HEADERS_ALL_B k where k.id = ct.dnz_chr_id and jtot_object1_code = 'OKX_PCONTACT' and k.contract_number = '23572'; This information is returned: Contact Role jtot_object1_code Contact ID ----------------- ------------------------ -------------BUYER OKX_PCONTACT 401670 Run this query to get the contact information: select * from hz_parties where party_id = 401670;


SERVICE CONTRACT HEADER – VENDOR CONTACT INFORMATION Now create a contact for the Vendor.

Rerun this query: select cro_code "Contact Role", ct.jtot_object1_code, object1_id1 "Contact ID" from OKC_CONTACTS ct, OKC_K_HEADERS_ALL_B k where k.id = ct.dnz_chr_id and k.contract_number = '23572'; This information is returned. Notice that the jtot_object1_code for the new entry is OKX_RESOURCE. The results will be different when you run this query because line level contacts are created later in this presentation. Contact Role ----------------BUYER ADMIN

jtot_object1_code Contact ID ------------------------ -------------OKX_PCONTACT 401670 OKX_RESOURCE 10199

The resource information is located in a table and a view. Either of these queries will return the information: select * from OKX_RESOURCES_V where id1 = 10199; select * from JTF_RS_RESOURCE_EXTNS where resource_id = 10199;


SERVICE CONTRACT HEADER – PRICING / BILLING INFORMATION Let’s progress to the Pricing / Billing tab for the contract. Enter the Price List, Payment Terms, Accounting Rule, Invoicing Rule, Hold Credits checkbox and Summary Transactions checkbox.

The information is stored in OKC_K_HEADERS_ALL_B and some is stored in OKS_K_HEADERS_B. select k.price_list_id, k.payment_term_id, oks.acct_rule_id, k.inv_rule_id, oks.hold_billing "Hold Credits", oks.summary_trx_yn "Summary Transactions" from OKC_K_HEADERS_ALL_B k, OKS_K_HEADERS_B oks where contract_number = '23572' and k.id = oks.chr_id; The values are the id’s in other tables. For example, this query returns the Corporate price list: select name from QP_LIST_HEADERS_B pl, QP_LIST_HEADERS_TL tl where pl.list_header_id = 1000 and pl.list_header_id = tl.list_header_id; This query returns the invoicing and accounting rules: select name, decode (type, 'A', 'Accounting Rule', 'I', 'Invoicing Rule') "Rule Type" from ra_rules where rule_id in (1, 2)


D. Contract Billing Data D1. This query shows the billing invoice details. Note that -99 will be shown for invoice number if the 'Service Contracts Fetch Receivables Info For Billing' concurrent program has not been run after Autoinvoice has been run. SELECT DISTINCT d.contract_number ,a.trx_number "Invoice Number" ,TO_CHAR( b.date_billed_from, 'DDMONYYYY HH24MI' ) "Bill From" ,TO_CHAR( b.date_billed_to, 'DDMONYYYY HH24MI' ) "Bill To" ,b.amount FROM oks_bill_transactions a , oks_bill_txn_lines aa , oks_bill_cont_lines b , okc_k_lines_b c , okc_k_headers_b d WHERE A.ID = AA.BTN_ID AND AA.BCL_ID = B.ID AND B.CLE_ID = C.CLE_ID AND C.DNZ_CHR_ID = D.ID AND d.id = ; D2. This query shows the billing transaction details. The data in this table is shown in the History tab of the Billing Schedule form in the contract. For the bill_action, the codes have the following meanings: Regular Invoice -RI, Termination Credit - TR, Averaging - AV, Settlement Invoice - SRI, Settlement Credit - STR. SELECT hdr.contract_number "Contract" , hdr.contract_number_modifier "Modifier" , hdr.id , TO_CHAR( cont.creation_date, 'DDMONYYYY HH24:MI') "Creation Date" , bill_action , btn_id "Billing Transaction ID" , amount , TO_CHAR( DATE_BILLED_FROM, 'DDMONYYYY' ) "Date Billed From" , TO_CHAR( DATE_BILLED_TO, 'DDMONYYYY' ) "Date Billed To" FROM oks_bill_cont_lines cont , okc_k_lines_b line , okc_k_headers_b hdr WHERE hdr.id = line.dnz_chr_id AND cont.cle_id = line.id AND hdr.id = ORDER BY cont.creation_date;


D3. This query returns data about the contract Line ids corresponding to each invoice as well as invoice details. SELECT BCL.id ,BCL.cle_id ,BCL.btn_id ,BCL.bill_action ,OKL.id "Line id" ,OKH.id "Contract id" , BTN.TRX_NUMBER "Invoice" ,bcl.date_billed_from , bcl.date_billed_to FROM OKS_BILL_CONT_LINES BCL, OKC_K_LINES_B OKL, OKC_K_HEADERS_B OKH, OKS_BILL_TRANSACTIONS BTN, OKS_BILL_TXN_LINES BTL WHERE OKH.contract_number = '' And OKH.ID = OKL.DNZ_CHR_ID And OKL.CLE_ID IS NULL And OKL.ID = BCL.CLE_ID And BTN.ID = BCL.BTN_ID And BTL.BTN_ID = BTN.ID And BTL.BILL_INSTANCE_NUMBER IS NOT NULL ; D4. This query returns information about what the contract billing schedule for a contract and can be used to investigate amounts expected to be billed in a billing period. SELECT TO_CHAR(bcl.id) , TO_CHAR(bsl.id) , TO_CHAR(lvl.id) , lvl.date_start , bsl.date_billed_from , lvl.date_end , bsl.date_billed_to , bcl.DATE_NEXT_INVOICE , lvl.DATE_TRANSACTION , lvl.DATE_TO_INTERFACE , lvl.DATE_COMPLETED , TO_CHAR(RUL_ID) , TO_CHAR(lvl.PARENT_CLE_ID) , bsl.amount FROM oks_bill_sub_lines bsl ,oks_bill_cont_lines bcl ,oks_level_elements lvl


,okc_K_LINES_B kl ,okc_k_headers_b kh WHERE kh.contract_number = '&enter_contract_number' AND kl.dnz_chr_id = kh.id AND lvl.dnz_chr_id = kh.id AND bcl.cle_id = kl.id AND bcl.id = bsl.bcl_id AND lvl.cle_id = bsl.cle_id ;


SERVICE CONTRACT HEADER – RENEWAL TAB Let’s review the top portion of the Renewals tab.

This query returns the Renewal Process: select k.contract_number, fnd.meaning "Renewal Type" from OKC_K_HEADERS_ALL_B k, FND_LOOKUP_VALUES fnd where k.renewal_type_code = fnd.lookup_code and fnd.lookup_type = 'OKS_RENEWAL_TYPE' and k.contract_number = '23572'; The Approval (Required) is returned by running this query. The value is ‘Y’ when approval is required. select approval_type from OKC_K_HEADERS_ALL_B where contract_number = '23572'; The price list information is stored in QP_LIST_HEADERS_B, but this query will provide the list header name. select pr.name from OKC_K_HEADERS_ALL_B k, QP_LIST_HEADERS_TL pr where k.price_list_id = pr.list_header_id and pr.source_lang = 'US' and k.contract_number = '23572'; This query returns the Billing Profile: select bp.profile_number "Billing Profile" from OKC_K_HEADERS_ALL_B k, OKS_K_HEADERS_B oks, oks_billing_profiles_v bp where k.id = oks.chr_id and oks.billing_profile_id = bp.id and contract_number = '23572';


SERVICE CONTRACT HEADER – RENEWAL TAB Let’s review the middle portion of the Renewals tab.

This query returns the desired information. select oks.renewal_po_number, oks.renewal_grace_duration, oks.renewal_grace_period, oks.renewal_est_rev_percent, oks.renewal_est_rev_duration, oks.renewal_est_rev_period from OKC_K_HEADERS_ALL_B k, OKS_K_HEADERS_B oks where k.id = oks.chr_id and contract_number = '23572';


SERVICE CONTRACT HEADER – RENEWAL TAB Let’s review the Quote To portion of the Renewals tab.

This query returns the Quote To information. It is a single query from multiple tables. The query can be simplified to return specific fields. select substr(okc.contract_number,1,30) "Contract Number", hca.account_number "Account Number", substr(hca.account_name,1,40) "Account Name", substr(csv.description,1,60) "Quote To Address", substr(hp.party_name,1,40) "Contact Party Name", substr(cp.email_address,1,30) "Email Address", oks.quote_to_contact_id, car.cust_account_role_id, car.party_id, car.cust_account_id from OKS_K_HEADERS_B oks, OKC_K_HEADERS_ALL_B okc, HZ_CUST_ACCOUNT_ROLES car , HZ_CUST_ACCOUNTS hca, HZ_CONTACT_POINTS cp, HZ_PARTIES hp, OKX_CUST_SITES_V csv where oks.chr_id = okc.id and oks.quote_to_contact_id = car.cust_account_role_id and oks.quote_to_email_id = cp.contact_point_id and hp.party_id = car.party_id and car.cust_account_id = hca.cust_account_id and oks.quote_to_site_id = csv.id1 and okc.contract_number = '23572'; The quote_to_contact_id in OKS_K_HEADERS_B maps to HZ_CUST_ACCOUNT_ROLES, which then maps to HZ_CONTACT_POINTS. The quote_to_email_id maps in OKS_K_HEADERS_B maps to HZ_CONTACT_POINTS The quote_to_site_id in oks_k_headers_b is mapped to OKX_CUST_SITES_V Refer to Note 471398.1 , How to Find the Quote To Party ID in a Service Agreement, for additional information.


SERVICE CONTRACT HEADER – ADMIN TAB The contract group is stored in OKC_K_GRPINGS.

This query can be used to obtain the contract group(s) for a contract. select substr(k.contract_number,1,25) "Contract Number", substr(k.contract_number_modifier,1,25) "Modifier", substr(tl.name,1,25) "Group Name" from OKC_K_HEADERS_ALL_B k, OKC_K_GRPINGS gp, OKC_K_GROUPS_TL tl where gp.included_chr_id = k.id and k.contract_number_modifier is null and tl.language = 'US' AND gp.cgp_parent_id = tl.id and k.contract_number = '23572'; Contract Number ----------------------23572

Modifier Group Name ------------- -----------------AL


SERVICE CONTRACT LINES – INFORMATION The contract line information is stored in OKC_K_LINES_B and OKS_K_LINES_B. Create a service line.

select ls.lty_code, l.bill_to_site_use_id, l.ship_to_site_use_id from okc_k_headers_all_b k, OKC_K_LINES_B l, OKS_K_LINES_B okls, OKC_LINE_STYLES_B ls where k.id = l.dnz_chr_id and l.id = okls.cle_id and l.lse_id = ls.id and k.contract_number = '23572'; From this query you can see that the relationship between OKC_K_LINES_B and OKS_K_LINES_B is similar to the relationship for the corresponding tables at the header level. The cle_id in OKS_K_LINES_B points to the id in OKC_K_LINES_B. A new table is introduced, OKC_LINE_STYLES_B. This table has descriptions for the lse_id, an important identifier in a contract line. From this query you see that the lse_id indicates that this is a service line. LTY_CODE BILL_TO_SITE_USE_ID SHIP_TO_SITE_USE_ID -------------- ----------------------------- ---------------------SERVICE 3731 6798 B. Contract Line Data Note: in OKC_K_LINES_B the chr_id field is only populated with the contract header id for contract lines. For contract sublines, this value is NULL. Dnz_chr_id is populated with the contract header id for both lines and sublines. B1. This SQL takes data from views rather than from actual contracts tables and is useful for reviewing data but not ideal for verifying if base tables hold correct data SELECT DISTINCT oal.LINE_NUMBER , oll.lse_name , oal.STS_CODE "Status" , oal.TRN_CODE, oal.LSE_ID, old.service_name , oal.CURRENCY_CODE "Currency|Code" , TO_CHAR( oal.START_DATE, 'DDMONYYYY' ) "Start Date" , TO_CHAR( oal.END_DATE, 'DDMONYYYY' ) "End Date"


, qpl.NAME "Price List Name" , CUST_ACCT_ID , BILL_TO_SITE_USE_ID , INV_RULE_ID , SHIP_TO_SITE_USE_ID , SHIP_TO_SITE_USE_ID , ACCT_RULE_ID , USAGE_PERIOD , USAGE_TYPE , UOM_QUANTIFIED , BILLING_SCHEDULE_TYPE , INVOICE_TEXT FROM oks_auth_lines_v oal , okc_launch_lgrid_v oll , qp_pricelists_lov_v qpl , oks_line_details_v old WHERE oal.id = oll.id AND cle_id IS NULL AND qpl.PRICE_LIST_ID = oal.PRICE_LIST_ID AND old.CONTRACT_ID = oll.chr_id AND oll.chr_id = '' ORDER BY to_number(line_number); B2. Data taken directly from contract table. (Note that this query may appear to return duplicate lines, as the query on okc_k_headers_b will return more than one contract if the contract has been renewed). select * from OKC_K_LINES_B where CHR_ID IN (select id from okc_k_headers_b where contract_number = '');


SERVICE CONTRACT LINES – COVERAGE INFORMATION Let’s examine the coverage for this line. Open the Effectivities tab for the line and press the Details button. Use Help / Diagnostics / Examine to get the id for the coverage header.

Exit the contract and navigate to Setup / Contract / Standard Coverage. Search for the Gold coverage. Again use Help / Diagnostics / Examine to review the id. Notice that the values are the same. This is a new feature in R12. The coverages for all contract lines reference a standard coverage. This allows users to change all contract coverages simply by modifying the standard coverage.


SERVICE CONTRACT LINES – COVERAGE INFORMATION To illustrate the difference, modify the coverage for this line, changing it to a custom coverage. Open the coverage Details and press the Customize button. Use Help / Diagnostics / Examine again. Generating a custom coverage causes the application to create a new coverage record, one that is specific to this contract.


SERVICE CONTRACT LINES – HOW TO IDENTIFY COVERAGE FOR A LINE So how does the application know which coverage to use? Where is the information likely to be located? My guess is OKS_K_LINES_B. Why? Because this is the type of information that was probably placed in a rules table at one time. My next guess would be OKC_K_LINES_B. Use Help / Diagnostics / Examine from the contract line to get the ID:

Now run this query: select coverage_id, standard_cov_yn from OKS_K_LINES_B where cle_id = 224040514744789738490100474035657399323; This is returned: COVERAGE_ID STANDARD_COV_YN ------------------------------------------------224040514744793365267559317923181517851 N For reference purposes, run a similar query for a contract line that uses a standard coverage. You will see that the coverage_id is the id for the standard coverage.


SERVICE CONTRACT LINES – RELATIONSHIP BETWEEN COVERAGE HEADER AND LINE In a previous page we found that the id for the coverage is 224040514744793365267559317923181517851. This query demonstrates how the cle_id can be used to find the parent. Notice that OKC_K_LINES_B is queried twice. This is because the coverage information and the line information are stored in the same table. select to_char(coverage.id), covls.lty_code, to_char(topline.id), toplinels.lty_code from OKC_K_LINES_B coverage, OKC_K_LINES_B topline, OKC_LINE_STYLES_B covls, OKC_LINE_STYLES_B toplinels where coverage.id = 224040514744793365267559317923181517851 and coverage.lse_id = covls.id and coverage.cle_id = topline.id and topline.lse_id = toplinels.id; The first two columns in the result are from the coverage record. The cle_id in the coverage points to it’s parent, in this case, the top line. TO_CHAR(COVERAGE.ID) LTY_CODE TO_CHAR(TOPLINE.ID) LTY_CODE ----------------------------------------------------------------------------------------224040514744793365267559317923181517851 COVERAGE 224040514744789738490100474035657399323 SERVICE The same pattern can be seen throughout the coverage template. Position the cursor in the Time Zone. Use Help / Diagnostics / Examine to get the cle_id. Now position the cursor in the Business Process. The id for this line is the cle_id for the child Time Zone record. The cle_id for the Business Process is the id for it’s parent, the Coverage (Name). Later, we will see the same relationship between a contract subline and it’s parent, a contract line.


SERVICE COVERAGE; COMPLEX COVERAGE QUERY Now that we know how to identify the coverage id, let’s expand the query to show much of the information that appears in the Coverage Details form. This is a complicated query, one that accesses the table okc_k_lines_b many times. We first obtain the coverage_id for the contract line from oks_k_lines_b. This leads us to the coverage in okc_k_lines_b. The id for this record allows us to identify the business processes (via business process cle_id); the id for the business processes allows us to identify the reaction times (again, via cle_id). The full query is on the next page.


SERVICE COVERAGE; COMPLEX COVERAGE QUERY select substr(hdr.contract_number,1,20) "Contract Number", substr(hdr.contract_number_modifier,1,25) "Contract Modifier", substr(line.line_number,1,15) "Line Number", substr(mtl.segment1,1,20) "Service Name", substr(covtl.name,1,15) "Coverage Name", substr(bproc.name,1,25) "Business Process Name", css.name "Severity Name", at.uom_code "Reaction UOM", at.mon_duration "Monday Duration", at.tue_duration "Tuesday Duration", at.wed_duration "Wednesday Duration", at.thu_duration "Thursday Duration", at.fri_duration "Friday Duration", at.sat_duration "Saturday Duration", at.sun_duration "Sunday Duration" from OKC_K_HEADERS_ALL_B hdr, OKC_K_LINES_B line, OKS_K_LINES_B oksline, OKC_K_ITEMS it, MTL_SYSTEM_ITEMS_B mtl, OKC_K_LINES_B covline, OKC_K_LINES_TL covtl, OKC_K_LINES_B bpline, OKS_K_LINES_B reactoksline, OKC_K_ITEMS itbp, CS_BUSINESS_PROCESSES bproc, OKC_K_LINES_B reactline, OKS_ACTION_TIMES at, OKS_ACTION_TIME_TYPES att, CS_INCIDENT_SEVERITIES css where hdr.contract_number = '23572' and hdr.id = line.dnz_chr_id and line.lse_id = '1' and line.id = it.cle_id and it.object1_id1 = mtl.inventory_item_id and hdr.inv_organization_id = mtl.organization_id and line.id = oksline.cle_id and covline.id = oksline.coverage_id and covline.lse_id = '2' and covline.id = covtl.id and covtl.language = 'US' and bpline.cle_id = covline.id and bpline.lse_id = '3' and bpline.id = itbp.cle_id


and itbp.object1_id1 = bproc.business_process_id and reactline.cle_id = bpline.id and reactline.lse_id = 4 and reactline.id = at.cle_id and reactline.id = reactoksline.cle_id and at.cov_action_type_id = att.id and att.cle_id = reactline.id and att.action_type_code = 'RCN' and reactoksline.incident_severity_id = css.incident_severity_id;


SERVICE CONTRACT LINES – ACCOUNTS TAB (ITEM NAME)

Let’s examine several of the fields at the line level. How do you identify the item name? The item information for a contract topline is stored in okc_k_items. The column object1_id1 has the inventory_item_id, a value that is mapped to the table mtl_system_items_b. The column object1_id2, is the org_id. The org_id is also stored in okc_k_headers_all_b. select substr(k.contract_number,1,25) "Contract Number", substr(k.contract_number_modifier,1,25) "Modifier Number", substr(mtl.segment1,1,30) "Service Name", it.jtot_object1_code "Object Code" from OKC_K_HEADERS_ALL_B k, OKC_K_LINES_B okc, MTL_SYSTEM_ITEMS_B mtl, OKC_K_ITEMS it where k.contract_number = '23572' and k.id = okc.dnz_chr_id and okc.lse_id = '1' and okc.id = it.cle_id and it.object1_id1 = mtl.inventory_item_id and it.object1_id2 = mtl.organization_id; Contract Number Modifier Number Service Name Object Code ------------------------ ------------------------ ------------------- ----------------23572 WRTEST OKX_SERVICE The value for object_code isn’t that important for this query, but we will see other object_code values are used to identify the line or subline type.


SERVICE CONTRACT LINES – ACCOUNTS TAB (BILL TO / SHIP TO)

You may see similarities to a previous header level query. The Bill To and Site information are stored in OKC_K_LINES_B. select substr(k.contract_number,1,25) "Contract Number", substr(okc.line_number,1,10) "Line Number", okc.bill_to_site_use_id "Bill To", okc.ship_to_site_use_id "Ship To" from OKC_K_HEADERS_ALL_B k, OKC_K_LINES_B okc, OKS_K_LINES_B oks where k.contract_number = '23572' and k.id = okc.dnz_chr_id and okc.id = oks.cle_id and okc.lse_id = '1'; Why did I restrict the query to lse_id = 1? The top line lse_id for a Service Line in a Service Agreement is ‘1’. When in doubt about the values, remember to check the values in OKC_LINE_STYLES_B.


SERVICE CONTRACT LINES – EFFECTIVITIES TAB (INVOICE TEXT)

This query displays the invoice text. The text is located in OKS_K_LINES_TL a translation table for OKS_K_LINES_B. To obtain the information, join the contract header to the line, the line to the oks line and then the oks line to the translation table. select substr(k.contract_number,1,25) "Contract Number", substr(okc.line_number,1,10) "Line Number", substr(tl.invoice_text,1,30) "Invoice Text" from OKC_K_HEADERS_ALL_B k, OKC_K_LINES_B okc, OKS_K_LINES_B oks, OKS_K_LINES_TL tl where k.contract_number = '23572' and k.id = okc.dnz_chr_id and okc.lse_id = '1' and okc.id = oks.cle_id and oks.id = tl.id;


SERVICE CONTRACT LINES – ACCOUNTS TAB (CONTACT INFORMATION)

The contact information is in okc_contacts. Two main okc tables retain the data. The cle_id (contract line id) is in OKC_K_PARTY_ROLES_B. select cle_id, rle_code, object1_id1 from OKC_K_PARTY_ROLES_B where cle_id = 224040514744789738490100474035657399323; This query returns the party_id, a link to hz_parties for the customer record. CLE_ID RLE_CODE OBJECT1_ID1 ---------------------------------------------------------------- --------------------------------------------------------------------224040514744789738490100474035657399323 CUSTOMER 4429 Use the cle_id to find the entry in okc_contacts: select contact.cro_code, contact.object1_id1 from OKC_K_PARTY_ROLES_B pr, OKC_CONTACTS contact where contact.cpl_id = pr.id and pr.cle_id = 224040514744789738490100474035657399323 CRO_CODE OBJECT1_ID1 ------------------------------ -----------------CUST_BILLING 56854 CUST_SHIPPING 3736


SERVICE CONTRACT LINES – ACCOUNTS TAB (CONTACT INFORMATION) The object1_id1 links to hz_cust_account_roles, which then links to hz_parties. The query actually references tables, but this is one way to identify the contacts. select contact.cro_code, substr(hp.party_name,1,25), hz.party_id, hz.cust_account_id from OKC_K_PARTY_ROLES_B pr, OKC_CONTACTS contact, HZ_CUST_ACCOUNT_ROLES hz, HZ_PARTIES hp where pr.id = contact.cpl_id and contact.object1_id1 = hz.cust_account_role_id and hp.party_id = hz.party_id and pr.cle_id = 224040514744789738490100474035657399323; CRO_CODE SUBSTR(HP.PARTY_NAME,1,25) PARTY_ID CUST_ACCOUNT_ID ------------------------ -------------------------- ------------------------------------------CUST_BILLING Ray Adams-Business World- 4554 3347 CUST_SHIPPING Nicole Burg-Business Worl 4452 3347


SERVICE CONTRACT LINES – ACCOUNTS TAB (CONTACT INFORMATION) The tax information is in OKS_K_LINES_B. This is a sample query, but it will return no information because the tax information is not entered in this contract. select tax_code, tax_exemption_id from OKS_K_LINES_B where cle_id = 224040514744789738490100474035657399323;

The payment information is also stored in OKS_K_LINES_B. Refer to Note 459982.1, Where Is Commitment, Purchase Order and Credit Card Information Stored in the Service Contracts Tables? The Note describes the location in OKS_K_HEADERS_ALL_B. The same information is stored at the line level in OKS_K_LINES_B.


SERVICE CONTRACT SUBLINES – (COVERED) PRODUCT INFORMATION Let’s create a contract subline, one for a covered product.

To identify the product name, we again need to establish a link to MTL_SYTEM_ITEMS_B. select substr(okc.line_number,1,15) "Subline Number", substr(ks.NAME,1,15) "Covered Level", mtl.segment1 "Item Name", csi.instance_number from OKC_K_HEADERS_ALL_B k, OKC_K_LINES_B okc, OKC_K_ITEMS ki, OKC_LINE_STYLES_V ks, CSI_ITEM_INSTANCES csi, MTL_SYSTEM_ITEMS_B mtl where k.contract_number_modifier IS NULL and k.ID = okc.dnz_chr_id and k.ID = ki.dnz_chr_id and okc.ID = ki.cle_id and okc.lse_id = ks.id and ki.jtot_object1_code IN ('OKX_CUSTPROD') and csi.last_vld_organization_id = mtl.organization_id and TO_NUMBER(ki.object1_id1) = csi.instance_id and csi.inventory_item_id = mtl.inventory_item_id and k.contract_number = '23572'; Let’s review this query in detail: OKC_K_ITEMS is referenced again. This time the object1_id1 has the instance_id Jtot_objecdt1_code has the value ‘OKX_CUSTPROD’. This is used to identify the subline type. Modifications in the query are needed to obtain the information for covered item, covered customer, etc. The query does not need to access CSI_ITEM_INSTANCES, but the table is included in case other columns from that table are needed. Run this query to get a general idea of the type of content in OKC_K_ITEMS. You will see the object codes that are used to identify usage items, covered system, etc. select distinct jtot_object1_code from OKC_K_ITEMS; C. Contract Subline Data Note: When you add a subline to a contract OKC_K_LINES_B is populated with data,


some of the data created there for each subline is internal data. Use the LSE_ID to restrict the data returned when querying. C1. Query for all the sublines on a contract with a Level type that can be seen when authoring the contract (i.e. restricts to lines which have Level of Product, Site, Item, System, Customer or Site). (Note that this query may appear to return duplicate lines, as the query on okc_k_headers_b will return more than one contract if the contract has been renewed). select id , line_number , cle_id , sts_code , hidden_ind , decode(lse_id, 8, 'Party', 7, 'Item', 9, 'Product', 10, 'Site', 11, 'System', 35, 'Customer') "Level" , object_version_number , price_negotiated , price_level_ind , price_unit , price_unit_percent , price_type , currency_code , price_list_id , price_list_line_id , item_to_price_YN , pricing_date , date_terminated , start_date , end_date from OKC_K_LINES_B where DNZ_CHR_ID IN (select id from okc_k_headers_b where contract_number = '') and lse_id IN(8, 7, 9, 10, 11, 35); C2. Query for contract sublines for a given contract line only. Replace with the line number of the required contract line (e.g. 1, 2. 3), taken either from the contract form, or from query B2. (Note that this query may appear to return


duplicate lines, as the query on okc_k_headers_b will return more than one contract if the contract has been renewed). select id , line_number , cle_id , sts_code , decode(lse_id, 8, 'Party', 7, 'Item', 9, 'Product', 10, 'Site', 11, 'System', 35, 'Customer') "Level" , object_version_number , price_negotiated , price_level_ind , price_unit , price_unit_percent , price_type , currency_code , price_list_id , price_list_line_id , item_to_price_YN , pricing_date , date_terminated , start_date , end_date from OKC_K_LINES_B where DNZ_CHR_ID IN (select id from okc_k_headers_b where contract_number = '') and cle_id IN (select id from okc_k_lines_b where chr_id IN (select id from okc_k_headers_b where contract_number = '') and line_number = ) and lse_id IN(8, 7, 9, 10, 11, 35); C3. This query returns the inventory item for a given contract subline where the Level = Product (i.e. the subline is for a particular install base instance). SELECT kl.line_number, ks.NAME , i.segment1


FROM okc_k_headers_b kh, okc_k_lines_b kl, okc_k_items ki, okc_line_styles_v ks, csi_item_instances c, mtl_system_items_b i WHERE kh.contract_number = '' AND kh.contract_number_modifier IS NULL can be populated AND kh.ID = kl.dnz_chr_id AND kh.ID = ki.dnz_chr_id AND kl.ID = ki.cle_id AND kl.lse_id = ks.ID AND ki.jtot_object1_code IN ('OKX_CUSTPROD') AND c.last_vld_organization_id = i.organization_id AND TO_NUMBER(ki.object1_id1) = c.instance_id AND c.inventory_item_id = i.inventory_item_id ;


SERVICE CONTRACT LINES – BILLING STREAM Let’s begin with the information that appears at the top of the Billing Schedule. The invoicing rule (for the line) is stored in OKC_K_HEADERS_B. The accounting rule and billing schedule type are stored in OKS_K_HEADERS_B.

We know the line id from previous queries. This query returns the information that appears at the top of the Billing Schedule form. select okc.inv_rule_id, oks.acct_rule_id, oks.billing_schedule_type from OKC_K_LINES_B okc, OKS_K_LINES_B oks where okc.id = oks.cle_id and okc.id = 224040514744789738490100474035657399323; INV_RULE_ID ACCT_RULE_ID BILLING_SCHEDULE_TYPE --------------------------------------------------------------------2 1 T The unbilled, credit, suppressed credit amount, etc. are also stored in OKS_K_LINES_B.


SERVICE CONTRACT LINES – BILLING STREAM

There are two billing streams in this example. This query returns the pertinent information. select sequence_no, level_periods, start_date, end_date, uom_per_period, uom_code from OKS_STREAM_LEVELS_B where cle_id = 224040514744789738490100474035657399323; SEQUENCE_NO LEVEL_PERIODS START_DATE END_DATE UOM_PER_PERIOD UOM_CODE ------------------------------------------------------------------------------------------------------------------1 1 11-MAY-10 10-NOV-10 6 MTH 2 2 11-NOV-10 10-MAY-11 1 QRT Remember that these billing streams exist at the subline level too.


SERVICE CONTRACT LINES – BILLING SCHEDULE Press the Schedule button to generate the billing schedules.

This query displays the schedule information. Again, remember that this information appears at the subline level too. select substr(sequence_number,1,15) "Sequence Number", date_start, date_end, amount, date_completed from OKS_LEVEL_ELEMENTS where cle_id = 224040514744789738490100474035657399323 order by sequence_number, date_start; Sequence Number DATE_START DATE_COMPLETED ------------------------- -----------------------------------------1 11-MAY-10 1 11-NOV-10 2 11-FEB-11

DATE_END

AMOUNT

---------------

--------------

10-NOV-10 10-FEB-11 10-MAY-11

55 27.5 27.5

The date_completed is not populated. This is a critical field in the table. This column is populated when an invoice is generated for the contract.


SERVICE CONTRACT LINES – STREAM / SCHEDULE QUERY Identifying why schedules are corrupt can be difficult. Let’s assume that you know the line id, that you feel there is corruption with one of the streams, but you are not sure which one. In many cases there are multiple sublines. A query is sometimes needed to show the information for the top line and all of the subline streams. This query links the tables OKS_STREAM_LEVELS_B and OKS_LEVEL_ELEMENTS based on the common column cle_id. select strm.sequence_no "Stream Number", substr(lvl.sequence_number,1,15) "Sequence Number", to_char(lvl.parent_cle_id) "Top Level Line ID", to_char(lvl.cle_id) "Level Element Line ID", lvl.date_start, lvl.date_end, lvl.amount, lvl.date_completed from OKS_STREAM_LEVELS_B strm, OKS_LEVEL_ELEMENTS lvl where strm.cle_id = lvl.cle_id and strm.cle_id = 224040514744789738490100474035657399323; This is insufficient though because it does not show the information for the sublines. The level elements table also has a column parent_cle_id, one that is populated with 224040514744789738490100474035657399323 for all of the sublines. A minor change in the query allows us to display the information for all of the sublines. select strm.sequence_no "Stream Number", substr(lvl.sequence_number,1,15) "Sequence Number", to_char(lvl.parent_cle_id) "Top Level Line ID", to_char(lvl.cle_id) "Level Element Line ID", lvl.date_start, lvl.date_end, lvl.amount, lvl.date_completed from OKS_STREAM_LEVELS_B strm, OKS_LEVEL_ELEMENTS lvl where strm.cle_id = lvl.cle_id and lvl.parent_cle_id = 224040514744789738490100474035657399323;


SERVICE CONTRACT LINES – STREAM / SCHEDULE QUERY Let’s combine the two and sort them so that the topline schedule is followed immediately by all of the subline schedule entries for that line. select strm.sequence_no "Stream Number", substr(lvl.sequence_number,1,15) "Sequence Number", to_char(lvl.parent_cle_id) "Top Level Line ID", to_char(lvl.cle_id) "Level Element Line ID", lvl.date_start, lvl.date_end, lvl.amount, lvl.date_completed from OKS_STREAM_LEVELS_B strm, OKS_LEVEL_ELEMENTS lvl where strm.cle_id = lvl.cle_id and strm.cle_id = 224040514744789738490100474035657399323 UNION select strm.sequence_no "Stream Number", substr(lvl.sequence_number,1,15) "Sequence Number", to_char(lvl.parent_cle_id) "Top Level Line ID", to_char(lvl.cle_id) "Level Element Line ID", lvl.date_start, lvl.date_end, lvl.amount, lvl.date_completed from OKS_STREAM_LEVELS_B strm, OKS_LEVEL_ELEMENTS lvl where strm.cle_id = lvl.cle_id and lvl.parent_cle_id = 224040514744789738490100474035657399323 order by 1, 2, 5; Stream Number Sequence Number Top Level Line ID Level Element Line ID DATE_START AMOUNT DATE_COMPLETED ---------------------------------------------- ------------------------------------------------------------------------------------------------------1 1 224040514744789738490100474035657399323 224040514744789738490100474035657399323 11-MAY-10 55 1 1 224040514744789738490100474035657399323 224654994456990219633500215272306024339 11-MAY-10 55 1 1 224040514744789738490100474035657399323

DATE_END ---------------

10-NOV-10

10-NOV-10


224040514744789738490100474035657399323 11-NOV-10 27.5 1 1 224040514744789738490100474035657399323 224654994456990219633500215272306024339 11-NOV-10 27.5

10-FEB-11

10-FEB-11

The first entry is for the top line. Notice that the Top Level Line ID and Level Element Line ID have the same value. The second entry is for the subline, the schedule entry for May 11 to Nov 10.


Lines 3 and 4 are for the next schedule entry for stream 1, the billing schedule for Nov 11 to Feb 11, 2011.SERVICE CONTRACT BILLING TABLES Let’s run Main Billing for the first Billing Period. One invoice has been generated.

See what happens to the level elements when this query is rerun after billing. select substr(sequence_number,1,15) "Sequence Number", date_start, date_end, amount, date_completed from OKS_LEVEL_ELEMENTS where cle_id = 224040514744789738490100474035657399323 order by sequence_number, date_start; Sequence Number DATE_START DATE_COMPLETED ------------------------- -----------------------------------------1 11-MAY-10 10-NOV-10 1 11-NOV-10 2 11-FEB-11

DATE_END

AMOUNT

---------------

--------------

10-NOV-10 10-FEB-11 10-MAY-11

55 27.5 27.5

The date_completed is now populated. We know from this query that an invoice has been generated for schedule entry 1.


SERVICE CONTRACT BILLING TABLES Now, let’s examine other billing tables. select substr(hdr.contract_number,1,15) "Contract Number", substr(hdr.contract_number_modifier,1,15) "Modifier", to_char(bcl.creation_date,'MM/DD/YYYY HH24:MI:SS') "Creation Date", to_char(bcl.btn_id), to_char(bcl.cle_id), bill_action, amount from OKC_K_HEADERS_ALL_B hdr, OKC_K_LINES_B line, OKS_BILL_CONT_LINES bcl where bcl.cle_id = line.id and line.dnz_chr_id = hdr.id and contract_number = '23572' order by hdr.contract_number; Contract Number Modifier Creation Date TO_CHAR(BCL.BTN_ID) TO_CHAR(BCL.CLE_ID) BILL_ACTION AMOUNT ----------------------- -------------------------------------------------------------------------------------------------------------------- -------------23572 05/19/2010 17:29:24 224763666759272367907400019617050675714 224040514744789738490100474035657399323 RI 55 What to look for in this table: The btn_id is populated when Main Billing has processed the transaction. The btn_id will be -44 under two circumstances. The value is -44 when a contract line is terminated and the credits are suppressed. It also has this value when the entry is created a Sales Order. Services for sales order lines are invoiced via integration from OM to Receivables; this value tells Main Billing to ignore the entry. The bill_action is generally RI, for regular invoice, and TR, for termination.


SERVICE CONTRACT BILLING TABLES Let’s terminate the contract subline and run Main Billing again.

Run the same query again. Notice that there is another entry, a termination, TR, transaction. The btn_id is not populated. Because it is not yet populated, I know that Main Billing has not picked up the transaction. Contract Number Modifier Creation Date TO_CHAR(BCL.BTN_ID) TO_CHAR(BCL.CLE_ID) BILL_ACTION AMOUNT ----------------------- -------------------------------------------------------------------------------------------------------------------- -------------23572 05/19/2010 17:29:24 224763666759272367907400019617050675714 224040514744789738490100474035657399323 RI 55 23572 05/19/2010 17:57:30 224040514744789738490100474035657399323 TR -52.61


SERVICE CONTRACT BILLING TABLES As a final action, run this query again. select strm.sequence_no "Stream Number", substr(lvl.sequence_number,1,15) "Sequence Number", to_char(lvl.parent_cle_id) "Top Level Line ID", to_char(lvl.cle_id) "Level Element Line ID", lvl.date_start, lvl.date_end, lvl.amount, lvl.date_completed from OKS_STREAM_LEVELS_B strm, OKS_LEVEL_ELEMENTS lvl where strm.cle_id = lvl.cle_id and strm.cle_id = 224040514744789738490100474035657399323 UNION select strm.sequence_no "Stream Number", substr(lvl.sequence_number,1,15) "Sequence Number", to_char(lvl.parent_cle_id) "Top Level Line ID", to_char(lvl.cle_id) "Level Element Line ID", lvl.date_start, lvl.date_end, lvl.amount, lvl.date_completed from OKS_STREAM_LEVELS_B strm, OKS_LEVEL_ELEMENTS lvl where strm.cle_id = lvl.cle_id and lvl.parent_cle_id = 224040514744789738490100474035657399323 order by 1, 2, 5; Stream Number Sequence Number Top Level Line ID Level Element Line ID DATE_START AMOUNT DATE_COMPLETED ---------------------------------------------- ------------------------------------------------------------------------------------------------------1 1 224040514744789738490100474035657399323 224040514744789738490100474035657399323 11-MAY-10 55 1 1 224040514744789738490100474035657399323 224654994456990219633500215272306024339 11-MAY-10 55 1 1 224040514744789738490100474035657399323

DATE_END ---------------

10-NOV-10

10-NOV-10


224040514744789738490100474035657399323 11-NOV-10 0

10-FEB-11

If you compare this result to the one that was run earlier you will see that the Nov 11 entry for the subline, cle_id 224654994456990219633500215272306024339, no longer exists. The termination process truncated all of the schedule entries if the date_start is greater than the termination date. The entry still exists at the line level, only because the subline was terminated, not the line.


E. Receivables Interface Data E1. Query to return all the data in the RA interface table for a given service contract. This will return the data populated into the table by Service Contracts Main Billing. Note that this query will not return any data if Autoinvoice has been run since the records are deleted from this table once they have been successfully processed by Autoinvoice. SELECT * FROM ra_interface_lines_all WHERE sales_order = '' ; F. Subscription Contracts F1. How to find the install base instance created for the subscription line item. (Note that when you enter a subscription line, the application automatically creates an Oracle Install Base item instance. This is what this query is retrieving). SELECT osh.instance_id, okh.contract_number, okh.contract_number_modifier, okl.line_number FROM oks_subscr_header_b osh, okc_k_headers_b okh, okc_k_lines_b okl WHERE osh.dnz_chr_id = okh.id AND osh.cle_id = okl.id AND okl.chr_id = okh.id AND okh.contract_number = '' AND NVL(okh.contract_number_modifier,'') = NVL('',''); F2. Query to find the install base instances created by a Subscription Contract as a result of subscription fulfillment. SELECT csi.instance_number FROM oks_subscr_elements ose, csi_item_instances csi WHERE ose.dnz_chr_id IN (SELECT id FROM okc_k_headers_b WHERE contract_number = '' AND NVL(contract_number_modifier,'') = Nvl('','')) AND ose.order_line_id = csi.last_oe_order_line_id; F3. Query to find which subscription contract line created the install base instance, for a subscription fulfillment. SELECT okh.contract_number, okh.contract_number_modifier, okl.line_number FROM oks_subscr_elements ose, csi_item_instances csi,


okc_k_headers_b okh, okc_k_lines_b okl WHERE csi.instance_number = '' AND ose.order_line_id = csi.last_oe_order_line_id AND okh.id = ose.dnz_chr_id AND okl.chr_id = okh.id AND okl.id = ose.dnz_cle_id; G. Order Details for Contracts Created from Order Management G1. Query which retrieves the order header id and order line id for a given contract. object1_id1 gives the order header id where jtot_object1_code = OKX_ORDERHEAD and the order line id where jtot_object1_code = OKX_ORDERLINE select okl.id Subline , okl.cle_id Service_Line , okl.dnz_chr_id , obj.object1_id1 , obj.jtot_object1_code from okc_k_lines_b okl , okc_k_rel_objs_v obj where okl.dnz_chr_id = obj.chr_id and okl.dnz_chr_id = and lse_id in (7, 8, 9, 10, 11,18, 25,35); G2. The table OKS_K_ORDER_DETAILS captures service contract details when a service is ordered in Order Management. SELECT * FROM OKS_K_ORDER_DETAILS WHERE CHR_ID =


Service Contract Coverage and Price Information The hardest part in Service Contract module is that it is pretty new relative to the other modules such as the Order Management, Inventory, Receivables, etc. The result of this is being not too familiar on how the tables are related and how to come up with information. An example of a requirement is to produce an active contracts with price and covered item information. This is a sample script. There could be an enhancement to this but this can be a good basis to extract information which is Install Baseddriven. select /*+ INDEX(grpings, OKC_K_GRPINGS_N1) INDEX(k, OKC_K_HEADERS_B_N4) INDEX(okc, OKC_K_LINES_B_N6) INDEX(ki OKC_K_ITEMS_N2) */ k.contract_number, k.start_date, k.end_date, hp.party_name customer_name, hcsu.location, hl.address1, hl.address2, hl.address3, hl.city, hl.state, hl.postal_code, hl.country, csi.serial_number, mtl.segment1 item , mtl.description item_des, okct.line_number||'.'||okc.line_number line_number, okc.price_negotiated from OKC_K_HEADERS_B k, OKC_K_LINES_B okc, OKC_K_LINES_B okct, OKC_K_ITEMS ki, okc_k_groups_tl groups1, okc_k_grpings grpings, CSI_ITEM_INSTANCES csi, MTL_SYSTEM_ITEMS_B mtl, hz_cust_accounts_all hca, hz_parties hp, hz_cust_site_uses_all hcsu, hz_locations hl, hz_party_sites hps,


hz_cust_acct_sites_all hcas where 1 = 1 and groups1.name = 'GROUP NAME' and groups1.language = 'US' and groups1.id = grpings.cgp_parent_id and grpings.included_chr_id = k.id and k.ship_to_site_use_id = hcsu.site_use_id and hcsu.site_use_code = 'SHIP_TO' and hca.party_id = hp.party_id and hps.party_id = hp.party_id and hps.location_id = hl.location_id and hcsu.cust_acct_site_id = hcas.cust_acct_site_id and hcas.party_site_id = hps.party_site_id and k.ID = okc.dnz_chr_id and k.ID = ki.dnz_chr_id and okc.lse_id = 9 and okc.ID = ki.cle_id and okct.ID = okc.cle_id and okc.start_date <= SYSDATE and okc.end_date > SYSDATE AND k.start_date <= SYSDATE aND k.end_Date >= SYSDATE and okct.start_date <= SYSDATE and okct.end_Date >= SYSDATE and NVL(okc.date_terminated, SYSDATE + 1) > SYSDATE and NVL(k.date_terminated, SYSDATE + 1) > SYSDATE and ki.jtot_object1_code IN ('OKX_CUSTPROD') and csi.last_vld_organization_id = mtl.organization_id and TO_NUMBER(ki.object1_id1) = csi.instance_id and csi.inventory_item_id = mtl.inventory_item_id Another option without considering the termination date as the filter but just select the termination date would be: SELECT k.contract_number, k.start_date, k.end_date,hp.party_name customer_name, hcsu.location,hl.address1, hl.address2,hl.address3, hl.city, hl.state, hl.postal_code, hl.country, cii.serial_number, mtl.segment1 item , mtl.description item_des,okct.line_number||'.'||okc.line_number, ocl.service_name , k.date_terminated FROM csi_item_instances cii, OKC_K_ITEMS ki, OKC_K_LINES_B okc, apps.OKS_AUTH_LINES_V okct, apps.OKS_LINE_DETAILS_V ocl, OKC_K_HEADERS_B k,


mtl_system_items mtl, okc_k_grpings grpings, hz_cust_accounts_all hca,hz_parties hp, hz_cust_site_uses_all hcsu, hz_locations hl, hz_party_sites hps, hz_cust_acct_sites_all hcas WHERE 1 = 1 AND TO_NUMBER(ki.object1_id1) = cii.instance_id AND ki.jtot_object1_code IN ('OKX_CUSTPROD') AND cii.inv_master_organization_id = 104 Parent Organization ID AND okct.ID = okc.cle_id AND okct.id = ocl.line_id (+) AND okc.lse_id = 9 AND okc.ID = ki.cle_id AND k.ID = okc.dnz_chr_id AND k.start_date <= TO_DATE('31DEC2011', 'DDMONYYYY') AND k.start_date >= TO_DATE('01JAN2011', 'DDMONYYYY') AND cii.inventory_item_id = mtl.inventory_item_id AND mtl.organization_id = last_vld_organization_id AND grpings.cgp_parent_id = 10000 or you can replace this with a list of Group IDs or all IDs AND grpings.included_chr_id = k.id AND k.ship_to_site_use_id = hcsu.site_use_id AND hcsu.site_use_code = 'SHIP_TO' AND hca.party_id = hp.party_id AND hps.party_id = hp.party_id AND hps.location_id = hl.location_id AND hcsu.cust_acct_site_id = hcas.cust_acct_site_id AND hcas.party_site_id = hps.party_site_id AND hcsu.org_id = 116

Oracle CRM Service Contracts Queries

Recommend Documents