Introduction
About this document
This document provides you an approach for Oracle Core Contract Conversion.This document speaks about the Setups, General approach and API’s used for the Conversion process. The parameters to be passed to the API’s and the tables populated by the API’s is discussed in detail.
Following topics are covered :
· Oracle Core Contract Conversion
· Business requirement
· Conversion Approach
· Setups required (with screenshots) for Conversion
· API’s used for the Conversion
Oracle Core Contracts Conversion
Oracle Contracts Core is designed for any business that needs to manage sales and
Procurement contracts. Oracle Contracts Core provides a means for dealing with contract information and is used to perform following functions
1. renewing or extending a contract
2. requesting a contract change
3. managing contract deliverables
4. Handling the contract-approval process.
During this Conversion the approach followed was standard three Stage approach
1. Insertion of Data into staging table from legacy Tables
2. Validation of Data
3. Insertion of Data into Oracle tables using Standard API.
The Contract conversion was done for populating following details in the Contract
1. Contract Header
2. Contract Lines
3. Attachments
4. Billing Rules
5. Party Roles
6. Details: QA Checklists
7. Details: Groups
8. Approval Workflow
Following is the detailed approach for the Contract Conversion process.
1. The Data from legacy system was put into the Staging tables. Different staging tables were used to create different parts of Contract.
The Staging tables that were created for Conversion Process are
b) Header Staging Table: Data for creating the Contract Headers and Parties
for creating role such as ‘DB Landlord’, ‘DB Franchisor’, etc… is stored in this table.
c) Line Staging Table: Data for Creating Contract Lines and Parties for creating roles like ‘DB Tenant’, etc… is stored in this table. These parties are defined corresponding to the data coming at contract lines.
d) Attachments Staging Table: Data for creating the Attachments for the
Contract Header is stored here.
2. Columns such as Process status, Error Flag and Error description were created in the staging table. The value in the Column Process status indicates the
stage at which data is being processed by the Conversion program.
Following are the Process status values that were followed during this conversion
Process
a. ‘1’ – Insertion of Data into Staging Tables
b. ‘2’ – Validation
c. ‘3’ – API insertion into the Base Tables
d. ‘4’ - Completion of Processing
The columns process status, error flag and error description were updated
whenever the errors are encountered for the record at different stages of
Processing.
3. Once the Data was inserted into the Staging Tables the process status will be updated to ‘1’. Various validations such as Business specific validations, Mandatory values, etc… were performed on the Data.
For each Contract header record corresponding line, attachment records were picked and processed. Then the next header and corresponding line, attachments records were validated.
If the record is validated successfully the process status was updated to ‘2’. Incase the record failed validation the process status was updated to ‘2’ and also the error flag and error description columns for the record were updated for the specific Validation failure message.
4. Those Contract header records which are validated successfully were picked for further processing. Corresponding to header record, line and attachment records were picked and using the standard API’s the data was inserted into the Oracle Base Tables. Incase of any errors the insertion for that particular contract record was roll back and then record was updated as process status ‘3’ along with error flag and error description.
For all successfully inserted records the process status was updates as ‘4’.
Some of the Points specific to our conversion Process were
1) Contract was created in the Active Status.
2) Converted contract will not go through the approval process.
3) QA Checks will not be performed during the conversion.
Setups for Contract Conversion
Some of the important setups required for Contract conversion are
1. Define Line Types:
This will depend upon the type of lines that will be created in the contract. This Data is stored in ‘OKC_LINE_TYPE’ lookup.
Responsibility: Contracts user
Contract>Setup>Categories & Sources>Define Line Types
2. Define Item Source:
This defines the Items that will be associated with a particular Item Source. This item source will be used for different line types of the contract.
Define Party Role Source:
This defines the Parties that will be associated with a particular role source. This party role source will be used to define the party roles.
This Data is stored in jtf_objects_vl.
Responsibility: CRM administrator
Task and Escalation Manager>Setup>Objects Meta-data
3. Define Line Styles:
For each line type a line style is defined and an item source is assigned to the Line style.
This data is stored in table OKC_LINE_STYLES_B.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Line styles
4. Define Party Roles:
Here the roles such as ‘DB Tenant’, ’DB Landlord’, etc. that are used in contracts are created. These values are stored in the lookup ‘OKC_ROLE’.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Party roles
5. Define Contact roles:
Some of the roles that need to be defined are Contract Approver, Active and passive Stakeholders, etc... These values are stored in lookup ‘OKC_CONTACT_ROLE’.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Contact roles
6. Define Role Sources:
For each party role defined above it’s required to assign the role source. This role sources are defined in point 2. Here Role source for Billing rules and Party contacts are also defined.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Role sources
7. Define the Contract Categories:
Here the Contracts categories along with the type of contract are defined. Also the Party Roles, Rules and Line Styles that were defined in previous steps are assigned to the Contract Category.
Thus for a particular Contract only those lines, rules and roles that have been assigned to that Contract category can be created for that type of Contract.
The various responsibilities that have access and the type of access for the Contract of this category can be defined in this screen.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Role sources
8. Define the Document Categories:
The Attachments that needs to be created for the contract header must have a Document Category and that is defined here. Also an Assignment is created for the document category to the form in which the attachment is to be attached. Here the form will be ‘Core Contracts Authoring’.
Responsibility: Application Developer
Attachments>Document Categories
9. Define the Workflow approval process that needs to be associated with the
Contract created by the conversion process.
10. Define the QA Checklists that will be used for creating the Contracts in the
Conversion process.
APIs used for Conversion:
Standard API’s were used for the Contract conversion. The Details of the API’S used is given below in the sequence which they were used.
1. Contract Header API:
The contract header was created using API okc_contract_pub.create_contract_header. It’s necessary to set the Org Context before calling this API.
okc_context.set_okc_org_context
Tables populated:
okc_k_headers_b
Record variables:
x_chrv_rec okc_contract_pub.chrv_rec_type;
v_chrv_rec okc_contract_pub.chrv_rec_type;
Values for the API record variable:
v_chrv_rec.sfwt_flag := 'Y';
v_chrv_rec.buy_or_sell := 'S'; --Selling Contract
v_chrv_rec.issue_or_receive := 'I'; -- Issue
v_chrv_rec.sts_code := 'ACTIVE'; --Active Status
v_chrv_rec.archived_yn := 'N';
v_chrv_rec.deleted_yn := 'N';
v_chrv_rec.template_yn := 'N';
v_chrv_rec.chr_type := 'CYA';
/*Contract Category code*/
v_chrv_rec.scs_code := 'CORPORATE1';
/*Contract Number*/
v_chrv_rec.contract_number := v_chr_contract_number;
/*Profit Center Number*/
v_chrv_rec.cognomen := c_xsch_rec.pc_num;
v_chrv_rec.attribute_category := 'CORPORATE1';
/*Start and End Date for the Contract*/
v_chrv_rec.start_date := c_xsch_rec.start_date;
v_chrv_rec.end_date := c_xsch_rec.end_date;
v_chrv_rec.estimated_amount := v_num_net_price;
v_chrv_rec.currency_code := g_chr_curr_code;
/*WHO Columns*/
v_chrv_rec.created_by := g_num_user_id;
v_chrv_rec.creation_date := SYSDATE;
v_chrv_rec.last_updated_by := g_num_user_id;
v_chrv_rec.last_update_date := SYSDATE;
v_chrv_rec.last_update_login := g_num_login_id;
v_chrv_rec.authoring_org_id := okc_context.get_okc_org_id;
v_chrv_rec.inv_organization_id := okc_context.get_okc_organization_id;
/*QA Checklist id and the Pricelist ID for the Contract*/
v_chrv_rec.qcl_id := v_num_qcl_id;
v_chrv_rec.price_list_id := v_num_price_list_id;
okc_contract_pub.create_contract_header
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => v_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_chrv_rec => v_chrv_rec
,x_chrv_rec => x_chrv_rec
);
This API returns the values of contract id as x_chrv_rec.ID . This ID will be passed to other APIs for creation of lines, Attachments for this Header.
2. Contract Group and Approval Workflow API:
For the Header contract group and approval workflow was created using the
following API’s
Contract group:
okc_contract_group_pub.create_contract_grpngs
Tables populated:
OKC_K_GRPINGS
Record variable:
v_cgcv_rec okc_contract_group_pub.cgcv_rec_type;
x_cgcv_rec okc_contract_group_pub.cgcv_rec_type;
Values for Record Variable:
/*Contract header Id*/
v_cgcv_rec.included_chr_id := x_chrv_rec.ID;
/*Group id of the Contract*/
v_cgcv_rec.cgp_parent_id := v_num_grp_id;
/*Contract category*/
v_cgcv_rec.scs_code := 'CORPORATE1';
/*WHO Columns*/
v_cgcv_rec.created_by := g_num_user_id;
v_cgcv_rec.creation_date := SYSDATE;
v_cgcv_rec.last_updated_by := g_num_user_id;
v_cgcv_rec.last_update_date := SYSDATE;
v_cgcv_rec.last_update_login := g_num_login_id;
v_return_status := NULL;
okc_contract_group_pub.create_contract_grpngs
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => v_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_cgcv_rec => v_cgcv_rec
,x_cgcv_rec => x_cgcv_rec
);
Approval workflow: okc_contract_pub.create_contract_process
Tables populated:
OKC_K_PROCESSES
Record Variable:
v_cpsv_rec okc_contract_pvt.cpsv_rec_type;
x_cpsv_rec okc_contract_pvt.cpsv_rec_type;
Values for the record variable:
/*Workflow Id*/
v_cpsv_rec.pdf_id := v_num_wf_id;
/*Header Id*/
v_cpsv_rec.chr_id := x_chrv_rec.ID;
/*WHO Columns*/
v_cpsv_rec.object_version_number := 1;
v_cpsv_rec.created_by := g_num_user_id;
v_cpsv_rec.creation_date := SYSDATE;
v_cpsv_rec.last_updated_by := g_num_user_id;
v_cpsv_rec.last_update_date := SYSDATE;
v_cpsv_rec.last_update_login := g_num_login_id;
v_return_status := NULL;
okc_contract_pub.create_contract_process
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => v_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_cpsv_rec => v_cpsv_rec
,x_cpsv_rec => x_cpsv_rec
);
3. Contract lines API:
The contract line was created using API okc_contract_pub.create_contract_line. This API was used multiple times in order to create the different types of lines for the Contract Header.
Tables populated:
OKC_K_LINES_B
Record Variables:
v_clev_rec okc_cle_pvt.clev_rec_type;
vxp_clev_rec okc_cle_pvt.clev_rec_type;
v_api_version NUMBER := 1;
v_init_msg_list VARCHAR2 (1) := 'T';
vx_msg_count NUMBER := 0;
vx_msg_data VARCHAR2 (2000);
Values for Variables:
v_clev_rec.sfwt_flag := 'N';
/*Active Status of Line*/
v_clev_rec.sts_code := 'ACTIVE';
v_clev_rec.exception_yn := 'N';
v_clev_rec.display_sequence := in_num_sequence;
v_clev_rec.line_number := in_num_line_number;
/*Line Style id*/
v_clev_rec.lse_id := in_num_line_style_id;
/*cle id is used if the line is Sub line type Otherwise it will be null*/
v_clev_rec.cle_id := NULL;
/*chr_id and dnz_chr_id is the header id obtained from header API*/
v_clev_rec.chr_id := x_chrv_rec.ID;
v_clev_rec.dnz_chr_id := x_chrv_rec.ID;
v_clev_rec.currency_code := in_chr_curr_code;
/*Name of the valid item from the Item source which is assigned to line style*/
v_clev_rec.NAME := in_chr_item_name;
/*Start date and end date of the line*/
v_clev_rec.start_date := in_dte_start_date;
v_clev_rec.end_date := in_dte_end_date;
/*Price and price list of the Item*/
v_clev_rec.price_list_id := in_num_price_list_id;
v_clev_rec.price_negotiated := in_num_net_price;
/*Standard who columns*/
v_clev_rec.created_by := g_num_user_id;
v_clev_rec.creation_date := SYSDATE;
v_clev_rec.last_updated_by := g_num_user_id;
v_clev_rec.last_update_date := SYSDATE;
v_clev_rec.request_id := g_num_conc_req_id;
v_clev_rec.last_update_login := g_num_login_id;
v_clev_rec.attribute_category := in_chr_att_category;
okc_contract_pub.create_contract_line
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => out_chr_return_status
,x_msg_count => vx_msg_count
,x_msg_data => vx_msg_data
,p_clev_rec => v_clev_rec
,x_clev_rec => vxp_clev_rec
);
This API returns the line id as vxp_clev_rec.id.
Sub lines:
The same API can be used for creation of sub line with following values
/*cle id is the ID of the line for which sub line is to be created */
v_clev_rec.cle_id := in_num_cle_id;
/*chr_id is set to Null*/
v_clev_rec.chr_id := NULL;
v_clev_rec.dnz_chr_id := x_chrv_rec.ID;
It’s also necessary to populate the Item information such as Quantity, UOM, etc… at line level into the okc_k_items table. For this another API
okc_contract_item_pub.create_contract_item was used.
Tables populated:
okc_k_items
Record variables:
v_cim_rec okc_contract_item_pub.cimv_rec_type;
vx_cim_rec okc_contract_item_pub.cimv_rec_type;
Values for the record variable:
/*Line id from line API*/
v_cim_rec.cle_id := vxp_clev_rec.ID;
/*Header id of contract*/
v_cim_rec.dnz_chr_id := in_num_dnz_chr_id;
/*Item id for the line*/
v_cim_rec.object1_id1 := in_num_item_id;
v_cim_rec.object1_id2 := in_chr_object_id2;
/*This value depends upon the Item source assigned to the line which can be obtained from column JTOT_OBJECT_CODE of okc_line_style_sources_v */
v_cim_rec.jtot_object1_code := in_chr_lse_lu_code;
/*Value of Unit of measure*/
v_cim_rec.uom_code := NULL;
/*Quantity of Item*/
v_cim_rec.number_of_items := in_num_number_of_items;
v_cim_rec.object_version_number := 1;
/*WHO Columns*/
v_cim_rec.created_by := g_num_user_id;
v_cim_rec.creation_date := SYSDATE;
v_cim_rec.last_updated_by := g_num_user_id;
v_cim_rec.last_update_date := SYSDATE;
v_cim_rec.last_update_login := g_num_login_id;
okc_contract_item_pub.create_contract_item (v_api_version
,v_init_msg_list
,out_chr_return_status
,vx_msg_count
,vx_msg_data
,v_cim_rec
,vx_cim_rec
);
4. Party Roles API:
Party Roles for the contract was created using the API okc_contract_party_pub.create_k_party_role. Depending upon whether contract role information is coming in Header staging table or line staging table this API was called at that particular level of the Conversion process.
Tables populated:
OKC_K_PARTY_ROLES_B
Record variable:
x_cplv_rec okc_contract_party_pub.cplv_rec_type;
v_cplv_rec okc_contract_party_pub.cplv_rec_type;
Values for Record Variable:
/*Header Id*/
v_cplv_rec.chr_id := in_num_chr_id;
v_cplv_rec.dnz_chr_id := v_cplv_rec.chr_id;
v_cplv_rec.sfwt_flag := 'Y';
/*Role code */
v_cplv_rec.rle_code := in_chr_role_code;
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/
v_cplv_rec.jtot_object1_code := in_chr_object_code;
/*Party id for the role*/
v_cplv_rec.object1_id1 := in_num_party_id;
v_cplv_rec.object1_id2 := in_chr_object1_id2;
/*WHO Columns*/
v_cplv_rec.created_by := fnd_global.user_id;
v_cplv_rec.creation_date := SYSDATE;
v_cplv_rec.last_update_login := g_num_login_id;
v_cplv_rec.last_updated_by := fnd_global.user_id;
v_cplv_rec.last_update_date := SYSDATE;
okc_contract_party_pub.create_k_party_role
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => out_chr_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_cplv_rec => v_cplv_rec
,x_cplv_rec => x_cplv_rec
);
5. Attachments API:
The attachments were created for the Contract header in the form of short text
document. First the short text document was created and then this
document was added as the attachment to the header.
Tables populated:
FND_ATTACHED_DOCUMENTS
FND_DOCUMENTS
FND_DOCUMENTS_SHORT_TEXT
This API creates the Short text document
oe_fnd_attachments_pub.create_short_text_document
(1.0, --version
‘Text Message’, --Text to be added as attachment
v_num_category_id, -- Attachment category id
'',
'',
V_num_security_id, --The value is 4 for no security
NULL,
'Y',
'O', -- One time usage
SYSDATE,
'',
'',
v_num_document_id, -- Document id returned by the API
v_chr_return_status,
v_num_msg_count,
v_chr_msg_data
);
The document id returned by the above API is then passed to the next API that
creates the attachment
oe_fnd_attachments_pub.add_attachment
(1.0,
in_chr_table_name, --entity name i.e.
‘OKC_K_HEADERS_B'
v_num_id, -- contract header id
'0',
'',
'',
'',
'N',
'',
v_num_document_id , --Document id from above api
v_num_attachment_id, -- output attachment id
v_chr_return_status,
v_num_msg_count,
v_chr_msg_data
);
6. Billing Rule API:
The Billing Rule information was created which includes the Bill to and Customer
Account Rule. Following API’s were used for this purpose
Tables populated
OKC_RULES_B
OKC_RULE_GROUPS_B
OKC_RG_PARTY_ROLES
Record variable:
l_rgpv_rec_type okc_rule_pub.rgpv_rec_type;
l_out_rgpv_rec_type okc_rule_pub.rgpv_rec_type;
l_rmpv_rec_type okc_rule_pub.rmpv_rec_type;
l_out_rmpv_rec_type okc_rule_pub.rmpv_rec_type;
l_num_cpl_id okc_k_party_roles_b.ID%TYPE;
l_num_rrd_id okc_rg_role_defs.sre_id%TYPE;
l_rulv_rec_type okc_rule_pub.rulv_rec_type;
l_out_rulv_rec_type okc_rule_pub.rulv_rec_type;
a. First the Billing rule group was created
l_rgpv_rec_type.rgd_code := 'BILLING';
l_rgpv_rec_type.sfwt_flag := 'N';
l_rgpv_rec_type.rgp_type := 'KRG';
/*Header id of Contract*/
l_rgpv_rec_type.chr_id := in_num_chr_id;
l_rgpv_rec_type.dnz_chr_id := in_num_chr_id;
/*Create the Billing Rule Group*/
okc_rule_pub.create_rule_group
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rgpv_rec => l_rgpv_rec_type
,x_rgpv_rec => l_out_rgpv_rec_type
);
b. Create the Subject for the party having role like 'DB_LICENSOR'
/*Output rule group id from above API*/
l_rmpv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/*Id of the party from okc_k_party_roles_b*/
l_rmpv_rec_type.cpl_id := l_num_cpl_id;
/*Get the sre id for the Contract category for the Subject*/
SELECT role_def.sre_id
INTO l_num_rrd_id
FROM okc_subclass_rg_defs sub_def
, okc_rg_role_defs role_def
WHERE sub_def.scs_code = ‘Contract Categtory code’
AND sub_def.ID = role_def.srd_id
AND role_def.subject_object_flag = 'S' --SUBJECT
l_rmpv_rec_type.rrd_id := l_num_rrd_id;
/*Header ID*/
l_rmpv_rec_type.dnz_chr_id := in_num_chr_id;
/*Create the Subject*/
okc_rule_pub.create_rg_mode_pty_role
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rmpv_rec => l_rmpv_rec_type
,x_rmpv_rec => l_out_rmpv_rec_type
);
c. For creating the Object same API’s used in creating Subject was used the
only difference is that the Subject will be created for the party having role
like ‘DB_LICENSEE’
/*Output rule group id from above API*/
l_rmpv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/*Id of the party from okc_k_party_roles_b*/
l_rmpv_rec_type.cpl_id := l_num_cpl_id;
/*Get the sre id for the Contract category for the Subject*/
SELECT role_def.sre_id
INTO l_num_rrd_id
FROM okc_subclass_rg_defs sub_def
, okc_rg_role_defs role_def
WHERE sub_def.scs_code = ‘Contract Categtory code’
AND sub_def.ID = role_def.srd_id
AND role_def.subject_object_flag = 'O' --OBJECT
l_rmpv_rec_type.rrd_id := l_num_rrd_id;
/*Header ID*/
l_rmpv_rec_type.dnz_chr_id := in_num_chr_id;
/*Create the Subject*/
okc_rule_pub.create_rg_mode_pty_role
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rmpv_rec => l_rmpv_rec_type
,x_rmpv_rec => l_out_rmpv_rec_type
);
e. Create the Customer Account rule
/*Output rule group id from rule group API*/
l_rulv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/*Cust Account id*/
l_rulv_rec_type.object1_id1 := l_num_cust_account_id;
l_rulv_rec_type.object1_id2 := '#';
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/
l_rulv_rec_type.jtot_object1_code := 'OKX_CUSTACCT';
/*Contract header id*/
l_rulv_rec_type.dnz_chr_id := in_num_chr_id;
l_rulv_rec_type.std_template_yn := 'N';
l_rulv_rec_type.warn_yn := 'N';
l_rulv_rec_type.rule_information_category := 'CAN';
/*Create Rule for Customer Account*/
okc_rule_pub.create_rule
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rulv_rec => l_rulv_rec_type
,x_rulv_rec => l_out_rulv_rec_type
);
f. Create the Bill to Address Rule
/*Output rule group id from rule group API*/
l_rulv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/* Cust Account Id*/
l_rulv_rec_type.object2_id1 := l_num_cust_account_id;
l_rulv_rec_type.object2_id2 := '#';
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/ l_rulv_rec_type.jtot_object2_code := 'OKX_CUSTACCT';
/*Site use id of the Customer site*/
l_rulv_rec_type.object1_id1 := l_num_site_use_id;
l_rulv_rec_type.object1_id2 := '#';
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/
l_rulv_rec_type.jtot_object1_code := 'OKX_BILLTO';
/*Header Id*/
l_rulv_rec_type.dnz_chr_id := in_num_chr_id;
l_rulv_rec_type.std_template_yn := 'N';
l_rulv_rec_type.warn_yn := 'N';
l_rulv_rec_type.rule_information_category:= 'BTO';
/*Create Rule for Bill to site*/
okc_rule_pub.create_rule
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rulv_rec => l_rulv_rec_type
,x_rulv_rec => l_out_rulv_rec_type
);
References
1. Oracle Core Contracts User guide.
About this document
This document provides you an approach for Oracle Core Contract Conversion.This document speaks about the Setups, General approach and API’s used for the Conversion process. The parameters to be passed to the API’s and the tables populated by the API’s is discussed in detail.
Following topics are covered :
· Oracle Core Contract Conversion
· Business requirement
· Conversion Approach
· Setups required (with screenshots) for Conversion
· API’s used for the Conversion
Oracle Core Contracts Conversion
Oracle Contracts Core is designed for any business that needs to manage sales and
Procurement contracts. Oracle Contracts Core provides a means for dealing with contract information and is used to perform following functions
1. renewing or extending a contract
2. requesting a contract change
3. managing contract deliverables
4. Handling the contract-approval process.
During this Conversion the approach followed was standard three Stage approach
1. Insertion of Data into staging table from legacy Tables
2. Validation of Data
3. Insertion of Data into Oracle tables using Standard API.
The Contract conversion was done for populating following details in the Contract
1. Contract Header
2. Contract Lines
3. Attachments
4. Billing Rules
5. Party Roles
6. Details: QA Checklists
7. Details: Groups
8. Approval Workflow
Following is the detailed approach for the Contract Conversion process.
1. The Data from legacy system was put into the Staging tables. Different staging tables were used to create different parts of Contract.
The Staging tables that were created for Conversion Process are
b) Header Staging Table: Data for creating the Contract Headers and Parties
for creating role such as ‘DB Landlord’, ‘DB Franchisor’, etc… is stored in this table.
c) Line Staging Table: Data for Creating Contract Lines and Parties for creating roles like ‘DB Tenant’, etc… is stored in this table. These parties are defined corresponding to the data coming at contract lines.
d) Attachments Staging Table: Data for creating the Attachments for the
Contract Header is stored here.
2. Columns such as Process status, Error Flag and Error description were created in the staging table. The value in the Column Process status indicates the
stage at which data is being processed by the Conversion program.
Following are the Process status values that were followed during this conversion
Process
a. ‘1’ – Insertion of Data into Staging Tables
b. ‘2’ – Validation
c. ‘3’ – API insertion into the Base Tables
d. ‘4’ - Completion of Processing
The columns process status, error flag and error description were updated
whenever the errors are encountered for the record at different stages of
Processing.
3. Once the Data was inserted into the Staging Tables the process status will be updated to ‘1’. Various validations such as Business specific validations, Mandatory values, etc… were performed on the Data.
For each Contract header record corresponding line, attachment records were picked and processed. Then the next header and corresponding line, attachments records were validated.
If the record is validated successfully the process status was updated to ‘2’. Incase the record failed validation the process status was updated to ‘2’ and also the error flag and error description columns for the record were updated for the specific Validation failure message.
4. Those Contract header records which are validated successfully were picked for further processing. Corresponding to header record, line and attachment records were picked and using the standard API’s the data was inserted into the Oracle Base Tables. Incase of any errors the insertion for that particular contract record was roll back and then record was updated as process status ‘3’ along with error flag and error description.
For all successfully inserted records the process status was updates as ‘4’.
Some of the Points specific to our conversion Process were
1) Contract was created in the Active Status.
2) Converted contract will not go through the approval process.
3) QA Checks will not be performed during the conversion.
Setups for Contract Conversion
Some of the important setups required for Contract conversion are
1. Define Line Types:
This will depend upon the type of lines that will be created in the contract. This Data is stored in ‘OKC_LINE_TYPE’ lookup.
Responsibility: Contracts user
Contract>Setup>Categories & Sources>Define Line Types
2. Define Item Source:
This defines the Items that will be associated with a particular Item Source. This item source will be used for different line types of the contract.
Define Party Role Source:
This defines the Parties that will be associated with a particular role source. This party role source will be used to define the party roles.
This Data is stored in jtf_objects_vl.
Responsibility: CRM administrator
Task and Escalation Manager>Setup>Objects Meta-data
3. Define Line Styles:
For each line type a line style is defined and an item source is assigned to the Line style.
This data is stored in table OKC_LINE_STYLES_B.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Line styles
4. Define Party Roles:
Here the roles such as ‘DB Tenant’, ’DB Landlord’, etc. that are used in contracts are created. These values are stored in the lookup ‘OKC_ROLE’.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Party roles
5. Define Contact roles:
Some of the roles that need to be defined are Contract Approver, Active and passive Stakeholders, etc... These values are stored in lookup ‘OKC_CONTACT_ROLE’.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Contact roles
6. Define Role Sources:
For each party role defined above it’s required to assign the role source. This role sources are defined in point 2. Here Role source for Billing rules and Party contacts are also defined.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Role sources
7. Define the Contract Categories:
Here the Contracts categories along with the type of contract are defined. Also the Party Roles, Rules and Line Styles that were defined in previous steps are assigned to the Contract Category.
Thus for a particular Contract only those lines, rules and roles that have been assigned to that Contract category can be created for that type of Contract.
The various responsibilities that have access and the type of access for the Contract of this category can be defined in this screen.
Responsibility: Contract user
Contract>Setup>Categories & Sources>Define Role sources
8. Define the Document Categories:
The Attachments that needs to be created for the contract header must have a Document Category and that is defined here. Also an Assignment is created for the document category to the form in which the attachment is to be attached. Here the form will be ‘Core Contracts Authoring’.
Responsibility: Application Developer
Attachments>Document Categories
9. Define the Workflow approval process that needs to be associated with the
Contract created by the conversion process.
10. Define the QA Checklists that will be used for creating the Contracts in the
Conversion process.
APIs used for Conversion:
Standard API’s were used for the Contract conversion. The Details of the API’S used is given below in the sequence which they were used.
1. Contract Header API:
The contract header was created using API okc_contract_pub.create_contract_header. It’s necessary to set the Org Context before calling this API.
okc_context.set_okc_org_context
Tables populated:
okc_k_headers_b
Record variables:
x_chrv_rec okc_contract_pub.chrv_rec_type;
v_chrv_rec okc_contract_pub.chrv_rec_type;
Values for the API record variable:
v_chrv_rec.sfwt_flag := 'Y';
v_chrv_rec.buy_or_sell := 'S'; --Selling Contract
v_chrv_rec.issue_or_receive := 'I'; -- Issue
v_chrv_rec.sts_code := 'ACTIVE'; --Active Status
v_chrv_rec.archived_yn := 'N';
v_chrv_rec.deleted_yn := 'N';
v_chrv_rec.template_yn := 'N';
v_chrv_rec.chr_type := 'CYA';
/*Contract Category code*/
v_chrv_rec.scs_code := 'CORPORATE1';
/*Contract Number*/
v_chrv_rec.contract_number := v_chr_contract_number;
/*Profit Center Number*/
v_chrv_rec.cognomen := c_xsch_rec.pc_num;
v_chrv_rec.attribute_category := 'CORPORATE1';
/*Start and End Date for the Contract*/
v_chrv_rec.start_date := c_xsch_rec.start_date;
v_chrv_rec.end_date := c_xsch_rec.end_date;
v_chrv_rec.estimated_amount := v_num_net_price;
v_chrv_rec.currency_code := g_chr_curr_code;
/*WHO Columns*/
v_chrv_rec.created_by := g_num_user_id;
v_chrv_rec.creation_date := SYSDATE;
v_chrv_rec.last_updated_by := g_num_user_id;
v_chrv_rec.last_update_date := SYSDATE;
v_chrv_rec.last_update_login := g_num_login_id;
v_chrv_rec.authoring_org_id := okc_context.get_okc_org_id;
v_chrv_rec.inv_organization_id := okc_context.get_okc_organization_id;
/*QA Checklist id and the Pricelist ID for the Contract*/
v_chrv_rec.qcl_id := v_num_qcl_id;
v_chrv_rec.price_list_id := v_num_price_list_id;
okc_contract_pub.create_contract_header
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => v_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_chrv_rec => v_chrv_rec
,x_chrv_rec => x_chrv_rec
);
This API returns the values of contract id as x_chrv_rec.ID . This ID will be passed to other APIs for creation of lines, Attachments for this Header.
2. Contract Group and Approval Workflow API:
For the Header contract group and approval workflow was created using the
following API’s
Contract group:
okc_contract_group_pub.create_contract_grpngs
Tables populated:
OKC_K_GRPINGS
Record variable:
v_cgcv_rec okc_contract_group_pub.cgcv_rec_type;
x_cgcv_rec okc_contract_group_pub.cgcv_rec_type;
Values for Record Variable:
/*Contract header Id*/
v_cgcv_rec.included_chr_id := x_chrv_rec.ID;
/*Group id of the Contract*/
v_cgcv_rec.cgp_parent_id := v_num_grp_id;
/*Contract category*/
v_cgcv_rec.scs_code := 'CORPORATE1';
/*WHO Columns*/
v_cgcv_rec.created_by := g_num_user_id;
v_cgcv_rec.creation_date := SYSDATE;
v_cgcv_rec.last_updated_by := g_num_user_id;
v_cgcv_rec.last_update_date := SYSDATE;
v_cgcv_rec.last_update_login := g_num_login_id;
v_return_status := NULL;
okc_contract_group_pub.create_contract_grpngs
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => v_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_cgcv_rec => v_cgcv_rec
,x_cgcv_rec => x_cgcv_rec
);
Approval workflow: okc_contract_pub.create_contract_process
Tables populated:
OKC_K_PROCESSES
Record Variable:
v_cpsv_rec okc_contract_pvt.cpsv_rec_type;
x_cpsv_rec okc_contract_pvt.cpsv_rec_type;
Values for the record variable:
/*Workflow Id*/
v_cpsv_rec.pdf_id := v_num_wf_id;
/*Header Id*/
v_cpsv_rec.chr_id := x_chrv_rec.ID;
/*WHO Columns*/
v_cpsv_rec.object_version_number := 1;
v_cpsv_rec.created_by := g_num_user_id;
v_cpsv_rec.creation_date := SYSDATE;
v_cpsv_rec.last_updated_by := g_num_user_id;
v_cpsv_rec.last_update_date := SYSDATE;
v_cpsv_rec.last_update_login := g_num_login_id;
v_return_status := NULL;
okc_contract_pub.create_contract_process
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => v_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_cpsv_rec => v_cpsv_rec
,x_cpsv_rec => x_cpsv_rec
);
3. Contract lines API:
The contract line was created using API okc_contract_pub.create_contract_line. This API was used multiple times in order to create the different types of lines for the Contract Header.
Tables populated:
OKC_K_LINES_B
Record Variables:
v_clev_rec okc_cle_pvt.clev_rec_type;
vxp_clev_rec okc_cle_pvt.clev_rec_type;
v_api_version NUMBER := 1;
v_init_msg_list VARCHAR2 (1) := 'T';
vx_msg_count NUMBER := 0;
vx_msg_data VARCHAR2 (2000);
Values for Variables:
v_clev_rec.sfwt_flag := 'N';
/*Active Status of Line*/
v_clev_rec.sts_code := 'ACTIVE';
v_clev_rec.exception_yn := 'N';
v_clev_rec.display_sequence := in_num_sequence;
v_clev_rec.line_number := in_num_line_number;
/*Line Style id*/
v_clev_rec.lse_id := in_num_line_style_id;
/*cle id is used if the line is Sub line type Otherwise it will be null*/
v_clev_rec.cle_id := NULL;
/*chr_id and dnz_chr_id is the header id obtained from header API*/
v_clev_rec.chr_id := x_chrv_rec.ID;
v_clev_rec.dnz_chr_id := x_chrv_rec.ID;
v_clev_rec.currency_code := in_chr_curr_code;
/*Name of the valid item from the Item source which is assigned to line style*/
v_clev_rec.NAME := in_chr_item_name;
/*Start date and end date of the line*/
v_clev_rec.start_date := in_dte_start_date;
v_clev_rec.end_date := in_dte_end_date;
/*Price and price list of the Item*/
v_clev_rec.price_list_id := in_num_price_list_id;
v_clev_rec.price_negotiated := in_num_net_price;
/*Standard who columns*/
v_clev_rec.created_by := g_num_user_id;
v_clev_rec.creation_date := SYSDATE;
v_clev_rec.last_updated_by := g_num_user_id;
v_clev_rec.last_update_date := SYSDATE;
v_clev_rec.request_id := g_num_conc_req_id;
v_clev_rec.last_update_login := g_num_login_id;
v_clev_rec.attribute_category := in_chr_att_category;
okc_contract_pub.create_contract_line
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => out_chr_return_status
,x_msg_count => vx_msg_count
,x_msg_data => vx_msg_data
,p_clev_rec => v_clev_rec
,x_clev_rec => vxp_clev_rec
);
This API returns the line id as vxp_clev_rec.id.
Sub lines:
The same API can be used for creation of sub line with following values
/*cle id is the ID of the line for which sub line is to be created */
v_clev_rec.cle_id := in_num_cle_id;
/*chr_id is set to Null*/
v_clev_rec.chr_id := NULL;
v_clev_rec.dnz_chr_id := x_chrv_rec.ID;
It’s also necessary to populate the Item information such as Quantity, UOM, etc… at line level into the okc_k_items table. For this another API
okc_contract_item_pub.create_contract_item was used.
Tables populated:
okc_k_items
Record variables:
v_cim_rec okc_contract_item_pub.cimv_rec_type;
vx_cim_rec okc_contract_item_pub.cimv_rec_type;
Values for the record variable:
/*Line id from line API*/
v_cim_rec.cle_id := vxp_clev_rec.ID;
/*Header id of contract*/
v_cim_rec.dnz_chr_id := in_num_dnz_chr_id;
/*Item id for the line*/
v_cim_rec.object1_id1 := in_num_item_id;
v_cim_rec.object1_id2 := in_chr_object_id2;
/*This value depends upon the Item source assigned to the line which can be obtained from column JTOT_OBJECT_CODE of okc_line_style_sources_v */
v_cim_rec.jtot_object1_code := in_chr_lse_lu_code;
/*Value of Unit of measure*/
v_cim_rec.uom_code := NULL;
/*Quantity of Item*/
v_cim_rec.number_of_items := in_num_number_of_items;
v_cim_rec.object_version_number := 1;
/*WHO Columns*/
v_cim_rec.created_by := g_num_user_id;
v_cim_rec.creation_date := SYSDATE;
v_cim_rec.last_updated_by := g_num_user_id;
v_cim_rec.last_update_date := SYSDATE;
v_cim_rec.last_update_login := g_num_login_id;
okc_contract_item_pub.create_contract_item (v_api_version
,v_init_msg_list
,out_chr_return_status
,vx_msg_count
,vx_msg_data
,v_cim_rec
,vx_cim_rec
);
4. Party Roles API:
Party Roles for the contract was created using the API okc_contract_party_pub.create_k_party_role. Depending upon whether contract role information is coming in Header staging table or line staging table this API was called at that particular level of the Conversion process.
Tables populated:
OKC_K_PARTY_ROLES_B
Record variable:
x_cplv_rec okc_contract_party_pub.cplv_rec_type;
v_cplv_rec okc_contract_party_pub.cplv_rec_type;
Values for Record Variable:
/*Header Id*/
v_cplv_rec.chr_id := in_num_chr_id;
v_cplv_rec.dnz_chr_id := v_cplv_rec.chr_id;
v_cplv_rec.sfwt_flag := 'Y';
/*Role code */
v_cplv_rec.rle_code := in_chr_role_code;
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/
v_cplv_rec.jtot_object1_code := in_chr_object_code;
/*Party id for the role*/
v_cplv_rec.object1_id1 := in_num_party_id;
v_cplv_rec.object1_id2 := in_chr_object1_id2;
/*WHO Columns*/
v_cplv_rec.created_by := fnd_global.user_id;
v_cplv_rec.creation_date := SYSDATE;
v_cplv_rec.last_update_login := g_num_login_id;
v_cplv_rec.last_updated_by := fnd_global.user_id;
v_cplv_rec.last_update_date := SYSDATE;
okc_contract_party_pub.create_k_party_role
(p_api_version => v_api_version
,p_init_msg_list => v_init_msg_list
,x_return_status => out_chr_return_status
,x_msg_count => v_msg_count
,x_msg_data => v_msg_data
,p_cplv_rec => v_cplv_rec
,x_cplv_rec => x_cplv_rec
);
5. Attachments API:
The attachments were created for the Contract header in the form of short text
document. First the short text document was created and then this
document was added as the attachment to the header.
Tables populated:
FND_ATTACHED_DOCUMENTS
FND_DOCUMENTS
FND_DOCUMENTS_SHORT_TEXT
This API creates the Short text document
oe_fnd_attachments_pub.create_short_text_document
(1.0, --version
‘Text Message’, --Text to be added as attachment
v_num_category_id, -- Attachment category id
'',
'',
V_num_security_id, --The value is 4 for no security
NULL,
'Y',
'O', -- One time usage
SYSDATE,
'',
'',
v_num_document_id, -- Document id returned by the API
v_chr_return_status,
v_num_msg_count,
v_chr_msg_data
);
The document id returned by the above API is then passed to the next API that
creates the attachment
oe_fnd_attachments_pub.add_attachment
(1.0,
in_chr_table_name, --entity name i.e.
‘OKC_K_HEADERS_B'
v_num_id, -- contract header id
'0',
'',
'',
'',
'N',
'',
v_num_document_id , --Document id from above api
v_num_attachment_id, -- output attachment id
v_chr_return_status,
v_num_msg_count,
v_chr_msg_data
);
6. Billing Rule API:
The Billing Rule information was created which includes the Bill to and Customer
Account Rule. Following API’s were used for this purpose
Tables populated
OKC_RULES_B
OKC_RULE_GROUPS_B
OKC_RG_PARTY_ROLES
Record variable:
l_rgpv_rec_type okc_rule_pub.rgpv_rec_type;
l_out_rgpv_rec_type okc_rule_pub.rgpv_rec_type;
l_rmpv_rec_type okc_rule_pub.rmpv_rec_type;
l_out_rmpv_rec_type okc_rule_pub.rmpv_rec_type;
l_num_cpl_id okc_k_party_roles_b.ID%TYPE;
l_num_rrd_id okc_rg_role_defs.sre_id%TYPE;
l_rulv_rec_type okc_rule_pub.rulv_rec_type;
l_out_rulv_rec_type okc_rule_pub.rulv_rec_type;
a. First the Billing rule group was created
l_rgpv_rec_type.rgd_code := 'BILLING';
l_rgpv_rec_type.sfwt_flag := 'N';
l_rgpv_rec_type.rgp_type := 'KRG';
/*Header id of Contract*/
l_rgpv_rec_type.chr_id := in_num_chr_id;
l_rgpv_rec_type.dnz_chr_id := in_num_chr_id;
/*Create the Billing Rule Group*/
okc_rule_pub.create_rule_group
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rgpv_rec => l_rgpv_rec_type
,x_rgpv_rec => l_out_rgpv_rec_type
);
b. Create the Subject for the party having role like 'DB_LICENSOR'
/*Output rule group id from above API*/
l_rmpv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/*Id of the party from okc_k_party_roles_b*/
l_rmpv_rec_type.cpl_id := l_num_cpl_id;
/*Get the sre id for the Contract category for the Subject*/
SELECT role_def.sre_id
INTO l_num_rrd_id
FROM okc_subclass_rg_defs sub_def
, okc_rg_role_defs role_def
WHERE sub_def.scs_code = ‘Contract Categtory code’
AND sub_def.ID = role_def.srd_id
AND role_def.subject_object_flag = 'S' --SUBJECT
l_rmpv_rec_type.rrd_id := l_num_rrd_id;
/*Header ID*/
l_rmpv_rec_type.dnz_chr_id := in_num_chr_id;
/*Create the Subject*/
okc_rule_pub.create_rg_mode_pty_role
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rmpv_rec => l_rmpv_rec_type
,x_rmpv_rec => l_out_rmpv_rec_type
);
c. For creating the Object same API’s used in creating Subject was used the
only difference is that the Subject will be created for the party having role
like ‘DB_LICENSEE’
/*Output rule group id from above API*/
l_rmpv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/*Id of the party from okc_k_party_roles_b*/
l_rmpv_rec_type.cpl_id := l_num_cpl_id;
/*Get the sre id for the Contract category for the Subject*/
SELECT role_def.sre_id
INTO l_num_rrd_id
FROM okc_subclass_rg_defs sub_def
, okc_rg_role_defs role_def
WHERE sub_def.scs_code = ‘Contract Categtory code’
AND sub_def.ID = role_def.srd_id
AND role_def.subject_object_flag = 'O' --OBJECT
l_rmpv_rec_type.rrd_id := l_num_rrd_id;
/*Header ID*/
l_rmpv_rec_type.dnz_chr_id := in_num_chr_id;
/*Create the Subject*/
okc_rule_pub.create_rg_mode_pty_role
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rmpv_rec => l_rmpv_rec_type
,x_rmpv_rec => l_out_rmpv_rec_type
);
e. Create the Customer Account rule
/*Output rule group id from rule group API*/
l_rulv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/*Cust Account id*/
l_rulv_rec_type.object1_id1 := l_num_cust_account_id;
l_rulv_rec_type.object1_id2 := '#';
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/
l_rulv_rec_type.jtot_object1_code := 'OKX_CUSTACCT';
/*Contract header id*/
l_rulv_rec_type.dnz_chr_id := in_num_chr_id;
l_rulv_rec_type.std_template_yn := 'N';
l_rulv_rec_type.warn_yn := 'N';
l_rulv_rec_type.rule_information_category := 'CAN';
/*Create Rule for Customer Account*/
okc_rule_pub.create_rule
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rulv_rec => l_rulv_rec_type
,x_rulv_rec => l_out_rulv_rec_type
);
f. Create the Bill to Address Rule
/*Output rule group id from rule group API*/
l_rulv_rec_type.rgp_id := l_out_rgpv_rec_type.ID;
/* Cust Account Id*/
l_rulv_rec_type.object2_id1 := l_num_cust_account_id;
l_rulv_rec_type.object2_id2 := '#';
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/ l_rulv_rec_type.jtot_object2_code := 'OKX_CUSTACCT';
/*Site use id of the Customer site*/
l_rulv_rec_type.object1_id1 := l_num_site_use_id;
l_rulv_rec_type.object1_id2 := '#';
/*JTOT_OBJECT_CODE value from okc_role_sources_v*/
l_rulv_rec_type.jtot_object1_code := 'OKX_BILLTO';
/*Header Id*/
l_rulv_rec_type.dnz_chr_id := in_num_chr_id;
l_rulv_rec_type.std_template_yn := 'N';
l_rulv_rec_type.warn_yn := 'N';
l_rulv_rec_type.rule_information_category:= 'BTO';
/*Create Rule for Bill to site*/
okc_rule_pub.create_rule
(p_api_version => 1
,p_init_msg_list => 'T'
,x_return_status => l_return_status
,x_msg_count => l_message_count
,x_msg_data => l_message_data
,p_rulv_rec => l_rulv_rec_type
,x_rulv_rec => l_out_rulv_rec_type
);
References
1. Oracle Core Contracts User guide.