Académique Documents
Professionnel Documents
Culture Documents
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.
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
NAV: Contract Administration / Launchpad using the Service Contracts Manager responsibility.
R12
11i
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.
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;
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.
The vendor party is automatically populated when the cursor is positioned in the Parties tab.
Select the entry for party role = Customer.
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';
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.
The resource information is located in a table and a view. Either of these queries will return the
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.
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;
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.
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.
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
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';
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
This query returns the Quote To information. It is a single query from multiple tables. The
query can be simplified to return specific fields.
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
This query can be used to obtain the contract group(s) for a contract.
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.
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.
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:
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
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
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).
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.
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.
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.
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.
This query returns the party_id, a link to hz_parties for the customer record.
CLE_ID RLE_CODE
OBJECT1_ID1
---------------------------------------------------------------- ------------------------------
----------------------------------------
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;
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
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.
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;
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;
Remember that these billing streams exist at the subline level too.
SERVICE CONTRACT LINES – BILLING SCHEDULE
This query displays the schedule information. Again, remember that this information appears at
the subline level too.
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 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.
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.
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.
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
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.
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;
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
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.
Another option without considering the termination date as the filter but just
select the termination date would be: