OKS_CONTRACTS_PUB.

Create_Contract_Header:
This API is used to create contract header information.
The API is called using P_K_Header_Rec,P_Header_Contacts_Tbl,
P_Header_Sales_Crd_Tbl and P_Header_Articles_Tbl.
Depending on your conversion needs and the available information in the legacy
application you would be required to populate each of these
in-parameters.
However if no information is available for sales credit or contract articles you
could leave the P_Header_Sales_Crd_Tbl and P_Header_Articles_Tbl NULL.
However it is a must that you populate the P_K_Header_Rec with all the values.
At least 1 contact information for the vendor should be created in
P_Header_Contacts_Tbl.
The value for the contact_object_code would be OKX_SALESPERS. If you need to
create additional parties on the contract header
depending on your billing requirements and other entity relationships you may have
to call Okc_Contract_Party_Pub.Create_K_Party_Role.
Also you would need to determine in advance how do you wish to bring these
contracts into the Application.
These contracts can be brought in as ENTERED, which would mean the process owners
would have to submit the contract for approval
using Contracts Approval Workflow.

OKS_CONTRACTS_PUB.Create_Service_Line

This API is used to create Contract Service Line for each contract header. The API
is called using P_K_Line_Rec,
P_Contact_Tbl and P_Line_Sales_Crd_Tbl. Again depending on your needs and available
information you would
populate each of these parameters. However if no information were available for the
P_Contact_Tbl and
P_Line_Sales_Crd_Tbl, it would be okay to let them be NULL from conversion
perspective. The key aspect of
service line API is to understand the relationships between the shipping entity and
the billing entity. Especially
if the item is serviceable with a usage component and has been leased out using a
third party company. Also
important is to attach this item with the appropriate Install Base record if
Install Base application is in use.

OKS_CONTRACTS_PUB.Create_Covered_Line
This API is used to create Covered Lines for each service line you create. Before
you call this API you are
required to set values for P_K_Covered_Rec and P_Price_Attribs_In. Depending on
your pricing needs values for
P_Price_Attribs_In will have to be set. If there is no complex pricing requirements
it is okay to leave the value
for this record type null. Values of certain columns of P_K_Covered_Rec should be
same as P_K_Line_Rec e.g.
value for PERIOD in the record should be same as the value for the
P_K_Line_Rec.Usage_Type or value for
Line_Renewal_Type should be either FUL/DNR/KEP.

Oracle Core Contract Conversion

Below setps provides you an approach for Oracle Core Contract Conversion.
Here it's covered about the Setups, General approach and APIs used for the
Conversion process.
The parameters to be passed to the APIs and the tables populated by the APIs is
discussed in detail.
Following topics are covered :
? Oracle Core Contract Conversion
? Business requirement
? Conversion Approach
? Setups required (with screenshots) for Conversion
? APIs 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 APIs 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 its 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 APIs were used for the Contract conversion. The Details of the APIS 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.
Its 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 APIs
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;

Its 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 APIs 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 APIs 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
);