Repricing
If the account or person attributes are changed, the system allows you to recalculate and persist the interest rate for rate type price items. This process is known as Repricing. The Repricing process is triggered in the following scenarios when:
-
You edit the attributes and characteristics of an account.
-
You add or delete the usage amount and counter details of an account.
-
You edit the attributes and characteristics of a person.
-
You add or delete the usage amount and counter details of a person.
-
You define or edit the price item pricing of an active price list which is assigned to an account or a person.
-
You define, edit, override, or copy the price item pricing of an account or a person.
-
You assign a price list to an account or a person, or edit the price list assignment details of an account or a person.
The system behaves in the following manner in the above scenarios:
| Scenario | System Behaviour |
|---|---|
| On editing the attributes and characteristics of an account | The system checks whether the account is eligible for repricing.
If the account is eligible for repricing, the system checks whether
a parameter for the account attribute or characteristic whichever
is changed is already defined in the system. If the required parameters
are available in the system, the system creates a repricing request
for the account and effective date combination in the CI_REPRC_REQ_DTL table. On executing the Process Repricing Request and
Persist Pricing for an Account (C1-REPC2) batch, you can
recalculate and persist the rate for the account in the CI_PRCE_CALC table. Note: On editing the account attributes,
the effective date is set to the date when you edit the account attributes.
However, on editing the account's characteristic, the effective date
is set to the date from when the characteristic is effective for the
account.
|
| On adding or deleting the usage amount and counter details of an account | The system checks whether the account is eligible for repricing.
If the account is eligible for repricing, the system checks whether
a parameter for the usage amount or counter whichever is changed is
already defined in the system. If the required parameters are available
in the system, the system creates a repricing request for the account
and effective date combination in the CI_REPRC_REQ_DTL table. On executing the Process Repricing Request and
Persist Pricing for an Account (C1-REPC2) batch, you can
recalculate and persist the rate for the account in the CI_PRCE_CALC table. Note: The effective date is set to
the date from when the usage amount or counter is effective for the
account.
|
| On editing the attributes and characteristics of a person | The system identifies all accounts which belong to the person
and its child persons, and then checks whether the identified accounts
are eligible for repricing. If one or more accounts are eligible for
repricing, the system checks whether a parameter for the person attribute
or characteristic whichever is changed is already defined in the system.
If the required parameters are available in the system, the system
creates a repricing request for the account and effective date combination
in the CI_REPRC_REQ_DTL table. On executing
the Process Repricing Request and Persist Pricing for an
Account (C1-REPC2) batch, you can recalculate and persist
the rate for the account in the CI_PRCE_CALC table. Note:
Only accounts where the person and child person are the main customers are considered for repricing. On editing the person attributes, the effective date is set to the date when you edit the person attributes. However, on editing the person's characteristic, the effective date is set to the date from when the characteristic is effective for the person. |
| On adding or deleting the usage amount and counter details of a person | The system identifies all accounts which belong to the person
and its child persons, and then checks whether the identified accounts
are eligible for repricing. If one or more accounts are eligible for
repricing, the system checks whether a parameter for the usage amount
or counter whichever is changed is already defined in the system.
If the required parameters are available in the system, the system
creates a repricing request for the account and effective date combination
in the CI_REPRC_REQ_DTL table. On executing
the Process Repricing Request and Persist Pricing for an
Account (C1-REPC2) batch, you can recalculate and persist
the rate for the account in the CI_PRCE_CALC table. Note:
Only accounts where the person and child person are the main customers are considered for repricing. The effective date is set to the date from when the usage amount or counter is effective for the person. |
| On assigning a price list to an account or editing the price list assignment details of an account | The system creates a repricing request for the account, price
item, and effective date combination in the CI_REPRC_REQ_DTL table. If the price assignment end date and/or price list assignment
end date is available, the system creates two repricing requests -
one request where the effective date is set to the start date and
another request where the effective date is set to the end date. The
effective date is set to the price assignment start date or price
list assignment start date depending on the following conditions:
However, the effective date is set to the price assignment end date or price list assignment end date depending on the following conditions:
On executing the Process Repricing Request and Persist Pricing for an Account (C1-REPC2) batch, you can recalculate and persist the rate for the account in the CI_PRCE_CALC table. Note: The system creates the repricing
request for the account irrespective of whether the account is eligible
for repricing or not.
|
| On assigning a price list to a person or editing the price list assignment details of a person | The system identifies all accounts which belong to the person
and its child persons, and then creates a repricing request for the
account, price item, and effective date combination in the CI_REPRC_REQ_DTL table. If the price assignment end date
and/or price list assignment end date is available, the system creates
two repricing requests - one request where the effective date is set
to the start date and another request where the effective date is
set to the end date. The effective date is set to the price assignment
start date or price list assignment start date depending on the following
conditions:
However, the effective date is set to the price assignment end date or price list assignment end date depending on the following conditions:
Note: If the Price List Assignment Start Date and Price List
Assignment End Date are earlier than the current date, repricing requests
for the accounts are not created in the CI_REPRC_REQ_DTL table.
On executing the Process Repricing Request and Persist Pricing for an Account (C1-REPC2) batch, you can recalculate and persist the rate for the account in the CI_PRCE_CALC table. Note:
Only accounts where the person and child person are the main customers are considered for repricing. The system creates the repricing request for the account irrespective of whether the account is eligible for repricing or not. |
| On defining, editing, overriding, or copying the price item pricing of an account | The system creates a repricing request for the account, price
item, and effective date combination in the CI_REPRC_REQ_DTL table. If the price assignment end date is specified, the system
creates two repricing requests - one request where the effective date
is set to the price assignment start date and another request where
the effective date is set to the price assignment end date + 1 Day.
On executing the Process Repricing Request and Persist
Pricing for an Account (C1-REPC2) batch, you can recalculate
and persist the rate for the account in the CI_PRCE_CALC table. Note: The system creates the repricing request for the account
irrespective of whether the account is eligible for repricing or not.
|
| On defining, editing, overriding, or copying the price item pricing of a person | The system identifies all accounts which belong to the person
and its child persons, and then creates a repricing request for the
account, price item, and effective date combination in the CI_REPRC_REQ_DTL table. If the price assignment end date
is specified, the system creates two repricing requests - one request
where the effective date is set to the price assignment start date
and another request where the effective date is set to the price assignment
end date + 1 Day. On executing the Process Repricing Request
and Persist Pricing for an Account (C1-REPC2) batch, you
can recalculate and persist the rate for the account in the CI_PRCE_CALC table. Note:
Only accounts where the person and child person are the main customers are considered for repricing. The system creates the repricing request for the account irrespective of whether the account is eligible for repricing or not. |
| On defining or editing the price item pricing of an active price list which is assigned to an account or a person | The system creates an entry for the price item pricing in
the CI_REPRC_ENTITY_DTL table. On executing
the Identify Accounts for Repricing (C1-REPC1) batch, the system identifies the following in the specified order:
Once the accounts are identified, the system checks whether the identified accounts are eligible for repricing. If one or more accounts are eligible for repricing, a repricing request is created for the account, price item, and effective date combination in the CI_REPRC_REQ_DTL table. If the price assignment end date is specified, the system creates two repricing requests - one request where the effective date is set to the price assignment start date and another request where the effective date is set to the price assignment end date + 1 Day. On executing the Process Repricing Request and Persist Pricing for an Account (C1-REPC2) batch, you can recalculate and persist the rate for the account in the CI_PRCE_CALC table. Note: Only accounts where the
person and child person are the main customers are considered for
repricing.
|
For more information about the Identify Accounts for Repricing (C1-REPC1) and Process Repricing Request and Persist Pricing for an Account (C1-REPC2) batches, refer to Oracle Revenue Management and Billing Batch Guide.
To enable the repricing feature, you need to do the following:
-
Define an algorithm using the C1-REPRCACCT algorithm type and attach it to the Audit algorithm spot of the C1-AccountBO business object
-
Define an algorithm using the C1-REPRCACBC algorithm type and attach it to the Audit algorithm spot of the C1-ACCBALCNT business object
-
Define an algorithm using the C1-REPRCPERS algorithm type and attach it to the Audit algorithm spot of the C1_PERSON_BO business object
-
Define an algorithm using the C1-REPRCPEBC algorithm type and attach it to the Audit algorithm spot of the C1-PERBALCNT business object
-
Define an algorithm using the C1_PLASGNAUD algorithm type and attach it to the Audit algorithm spot of the C1_PLASGNADD and C1_PLASGNEDIT business objects
-
Define an algorithm using the C1-PRCASGNAD algorithm type and attach it to the Audit algorithm spot of the C1_PRICEASGN_BO business object
-
Define an algorithm using the C1-REPRCPLPA algorithm type and attach it to the Audit algorithm spot of the C1_PRICEASGN_BO business object
-
Define the required parameters for the account and person attributes, characteristics, usage amount and usage counter