Requirement Processing Sample
Requirements can be added to transactions to control the situation that must be present in order for the transaction to process as an activity in OIPA. When the transaction is added as an activity, OIPA will check to make sure the requirement conditions are met before allowing the activity to process. If the requirements are not met, a requirement icon will appear next to the activity and it will not process. The activity will then go to Requirement Pending status rather than Active status.
Scenario
CSR selects the ContractSign activity and enters an Activity Effective Date of Feb 15, 2010. The CoSign Checkbox is left Unchecked. The requirements attached to this transaction require that the activity only process when the Co-sign checkbox is checked or the Effective Date is greater than March 1, 2010. A requirement icon appears next to the activity and it does not process.
Configuration Requirements
There are three AsCode tables created for requirements:
-
AsCodeRequirementCategory: holds requirement category options.
-
AsCodeRequirementType: holds requirement types.
-
AsCodeRequirementStatus: holds requirement status options.
There are seven database tables used for requirements:
-
AsRequirement: holds information on existing requirement instances.
-
AsRequirementActivity: holds the activity GUID and requirement GUID.
-
AsRequirementCriteria: holds the requirement criteria entered when configuring a new requirement.
-
AsRequirementDefinition: holds the information entered while creating a new requirement definition.
-
AsRequirementField: holds requirement field information.
-
AsRequirementGroup: holds the requirement group information entered when configuring a new requirement.
-
AsRequirementPolicy: holds the policy GUID and requirement GUID.
There are three business rules that need to be configured:
-
ActivityRequirementScreen: the global rule should exist, but does not need to be configured. This rule should be overridden at the company level and attached to the transaction. This rule does not need to contain configuration, as the fixed fields are defined by base Java code.
-
DeliveryRequirements: this rule should be overridden at the transaction level and attached to the transaction.
-
GeneratePendingRequirements: this rule should be attached to a transaction. It should be listed before the DeliveryRequirements rule in the Attached Rules section.
There is one optional business rule:
-
CopyToRequirementFields: this rule is attached to copy data to the requirement fields of another transaction’s requirement(s).
Requirement definitions should be created with specific requirement criteria to satisfy.
A transaction is needed to demonstrate requirements.
Prototype Samples
The following pieces of configuration were added to the Prototype Company to demonstrate requirements processing:
-
Three transactions were created. Navigate to Main Explorer and open Companies | Prototype Company | Subsidiary Companies | Prototype Child Company | Plans | Functional Prototype Plan | Transactions | Policy Transactions.
-
ContractSign: A requirement called CoSign will generate if the activity Effective Date is less than March 1, 2010 and the CoSign checkbox is unchecked. The requirement will not generate if the activity Effective Date is greater than March 1, 2010 and/or the CoSign checkbox is checked. When CoSign is satisfied, ContractSign is configured to update the activity Effective Date to the date when the requirement was satisfied.
-
ContractRenew: This activity always generates a requirement called IRSCheck. The Effective Date remains the same even after the requirement is satisfied. The requirement will generate with a Due Date three months after the Contract Renew Effective Date. The Due Date is not enforced. There is no restriction around adding a Close Date greater than the Due Date.
-
ContractUpdateReq: This activity is used to satisfy the generated requirements for ContractSign and ContractRenew by updating their Close Date. The Effective Date will be forced to the Effective Date of the activity with the requirement that is being updated. This activity will satisfy one requirement: one requirement for one activity.
Requirement Processing Prototype Transactions in Main Explorer
-
There are two requirement definitions that are used to demonstrate requirement processing. These definitions are referenced from the transactions and represent a requirement that must be filled. The criteria are listed below. Navigate to Admin Explorer and open Administration | Requirements | Prototype Child Company to see the requirement definitions.
-
CoSign: this requirement needs three criteria to be met:
-
Date
-
Checkbox: The CoSign requirement will generate if the ContractSign activity Effective Date is less than March 1, 2010 and the CoSign Checkbox is unchecked. The Cosign requirement will not generate if activity Effective Date is greater than March 1, 2010 and/or the CoSign Checkbox is checked. When CoSign is satisfied, ContractSign is configured so that the ContractSign EffectiveDate is updated to the date that the requirement was satisfied.
-
PlanGUID: PlanGuid must match the PlanGUID of the Functional Prototype Plan. This criterion should always be met when processing an activity in the Functional Prototype Plan.
-
IRSCheck: this requirement requires only one criteria be met:
-
PlanGUID: PlanGuid must match the PlanGUID of the Functional Prototype Plan. This criterion should always be met when processing an activity in the Functional Prototype Plan.
Requirement Definitions in Admin Explorer
-
Three business rules were used to demonstrate requirements processing. Navigate in the Global Rules Explorer to Business Rules | Attached. Open the folder for each rule and then open the Transaction Overrides folder.
-
GeneratePendingRequirements: This rule will be attached to both transactions generating requirements. In Contract Renew this rule will be used to add the Due Date. In Contract Sign it will define the conditions under which the CoSign requirement is created. This rule will actually generate the requirement.
-
DeliveryRequirements: This rule will be attached to both Contract Renew and Contract Sign. It will define whether the Effective Date is updated when the requirements are satisfied.
-
CopyToRequirementFields: This rule will be attached to ContractUpdateReq. This rule will update the Close Date for the requirement that is selected by Contract Update Req to be satisfied.
Requirement Business Rules in Global Rules Explorer
Copyright © 2009, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices