Inhoud

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, <xxx> 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 <contract number> 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, 'DD-MON-YYYY' ) "Date Terminated"
, TRN_CODE
, TO_CHAR( START_DATE, 'DD-MON-YYYY' ) "Start Date"
, TO_CHAR( END_DATE, 'DD-MON-YYYY' ) " 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 '<contract number>';

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 jtot_object1_code Contact ID

----------------- ------------------------ --------------
BUYER OKX_PCONTACT 401670
ADMIN 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, 'DD-MON-YYYY HH24-MI' ) "Bill From"
,TO_CHAR( b.date_billed_to, 'DD-MON-YYYY HH24-MI' ) "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 = <contract id from query A1>;

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, 'DD-MON-YYYY HH24:MI') "Creation Date"
, bill_action
, btn_id "Billing Transaction ID"
, amount
, TO_CHAR( DATE_BILLED_FROM, 'DD-MON-YYYY' ) "Date Billed From"
, TO_CHAR( DATE_BILLED_TO, 'DD-MON-YYYY' ) "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 = <contract id from query A1>
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 = '<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 Modifier Group Name

----------------------- ------------- ------------------
23572 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, 'DD-MON-YYYY' ) "Start Date"
, TO_CHAR( oal.END_DATE, 'DD-MON-YYYY' ) "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 = '<value of id taken from query A1>'
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 = '<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 = '<contract number>')
and lse_id IN(8, 7, 9, 10, 11, 35);

C2. Query for contract sublines for a given contract line only. Replace <parent line number>
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 = '<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 = '<contract number>')
and line_number = <parent 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 = '<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_END AMOUNT

DATE_COMPLETED
------------------------- ------------------ --------------- --------------
-------------------------
1 11-MAY-10 10-NOV-10 55
1 11-NOV-10 10-FEB-11 27.5
2 11-FEB-11 10-MAY-11 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 DATE_END
AMOUNT DATE_COMPLETED
---------------------- ------------------------- ----------------------
---------------------------- ------------------ ---------------
------------- --------------------------
1 1 224040514744789738490100474035657399323
224040514744789738490100474035657399323 11-MAY-10 10-NOV-10 55
1 1 224040514744789738490100474035657399323
224654994456990219633500215272306024339 11-MAY-10 10-NOV-10 55
1 1 224040514744789738490100474035657399323
224040514744789738490100474035657399323 11-NOV-10 10-FEB-11
27.5
1 1 224040514744789738490100474035657399323
224654994456990219633500215272306024339 11-NOV-10 10-FEB-11
27.5

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_END AMOUNT

DATE_COMPLETED
------------------------- ------------------ --------------- --------------
-------------------------
1 11-MAY-10 10-NOV-10 55 10-
NOV-10
1 11-NOV-10 10-FEB-11 27.5
2 11-FEB-11 10-MAY-11 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
DATE_END AMOUNT DATE_COMPLETED
---------------------- ------------------------- ----------------------
----------------------------
------------------ --------------- -------------
--------------------------
1 1
224040514744789738490100474035657399323 224040514744789738490100474035657399323 11-
MAY-10 10-NOV-10 55
1 1
224040514744789738490100474035657399323 224654994456990219633500215272306024339 11-
MAY-10 10-NOV-10 55
1 1
224040514744789738490100474035657399323 224040514744789738490100474035657399323 11-
NOV-10 10-FEB-11 0

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 = '<contract number>' ;

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 = '<contract number>'
AND NVL(okh.contract_number_modifier,'-') = NVL('<contract modifier>','-');

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 = '<contract number>'
AND NVL(contract_number_modifier,'-') = Nvl('<contract modifier>','-'))
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 = '<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 = <contract id from query A1>
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 =<contract id from query A1>
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 Based-driven.

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('31-DEC-2011', 'DD-MON-YYYY')
AND k.start_date >= TO_DATE('01-JAN-2011', 'DD-MON-YYYY')
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