Oracle® Rules Palette Release 9.1.0.0.0 E15811-01

# General Structure & Best Practices

General sequence of the transaction elements should be:

1. EffectiveDate

2. Allocations (if applicable)

3. Suspense

4. Withholding

5. Valuation (if applicable)

6. Fields

7. Events

8. Validation

9. Math

10. Within the <Math> section, any MathVariable constants should come first.

11. Assignments (if applicable)

12. ActivityAmounts (if applicable)

13. MultiFields

14. Spawns

Syntax standards according to the General Structure

1. EffectiveDate

1. The EffectiveDate element should be the first tag in a transaction.

2. The EffectiveDate of spawned transactions, when that spawned activity is only ever SYSTEM generated, should be Disabled.

2. Allocations

1. Allocation order of elements should be:

- FundAllocation

- AllocationFrom

- Allocation

- DefaultAllocation

3. Suspense

1. Use the OVERRIDABLE attribute to allow users to bypass suspense requirements.

4. Withholding

1. When withholding is needed, use the <Withholding> </Withholding> tags instead of creating fields for withholding.

5. Valuation

1. Do not include the <Valuation> tag in a transaction, if valuation is not necessary.

6. Fields

1. The order of field tags is:

- <Name>

- <Display>

- <ToolTip>

- <DataType>

- <Query>

- <Calculated>

- <DefaultValue>

- <RoleAssignments>

- <Tag>

- <Disabled>

- <Hidden>

2. The <DefaultValue> tag or <Calculated> tag may not be present at the same time. Use one or the other.

3. If a field is hidden, do not include a <Disabled> tag.

4. If a field is not hidden, do not include <Hidden> tag.

5. If a field is not disabled, do not include <Disabled> tag.

6. Hidden fields that are independent of other fields should be placed at the end of the <Fields> section.

- Except if the value of a hidden field is needed in a following field.

7. Suggestions for field names are listed below. This applies to MathVariable names as well.

- Capitalize the first letter of each word.

- Example: DateOfDeath not DateofDeath.

- Exception is the use of upper case in SQL reserved words.

- Exception is the use of upper case for Validation error messages that appear to the user.

8. Do not use spaces or underscores.

Example: DateOfBirth not Date_of_Birth.

9. Do not abbreviate unless the resulting word is extremely long. In that case, abbreviate but retain the meaning of word.

Examples: PolicyAnniversary not PolAnniv. NextMonRemainIssueChg for NextMonthaversaryRemainingIssueCharge.

10. Add abbreviated words to the Data Dictionary so that the meaning remains clear.

11. Field name and display value should be the same if possible.

Example: <Name>IssueDate</Name>, <Display>Issue Date</Display> not <Display>Date of Issue</Display>.

10. Filler fields should be blank for the display and DataType.

11. Combo boxes and radio buttons:

- In a combo box, start with 00 for the value followed by 01, 02, etc.

- Always use a two-digit format: 00, 01, 02, 03, etc.

- The 00 value should always stand for a not applicable value or for a Select an Option value in a combo box.

- It may not always make sense to start off a combo box with a 00 value. Please use your judgment or consult your Lead B.A.

- A combo box with a defaulted selection or one whose entry is non-required should not have a 00 selection.

- Radio buttons should have a 00 value for the negative response and 01 for the affirmative response.

- The above bullet point can apply to a combo box as well.

7. Math

1. When defining the TYPE for a MathVariable use:

- VALUE if setting a MathVariable to a constant, whether it is a numeric or non-numeric constant.

- FIELD if defining the MathVariable to a variable from the <Fields> section or if redefining another MathVariable.

- FUNCTION if using a function without an additional operation.

2. When defining the constant of Checked or UnChecked, the values should always be either CHECKED or UNCHECKED in all capital letters, respectively.

3. Use the PlanScreen business rule any time the amount or piece of information is constant for the plan you are configuring. This will allow rules to all use this value in a constant fashion. If the information should change, then only one change must be made. This eliminates the need to update every transaction or rule that hard coded constant plan values.

4. Use PlanFields any time a particular fact, amount, threshold value, etc., is tied to a product (plan), and is used in a constant fashion across multiple transactions and/or calculations. It should be defined in PlanFields rather than defined repeatedly in a transaction or calcGeneral XML.

5. XPATHs should always use the fully qualified path.

Example: /Valuation/Policy/FundList/Fund[FundGUID='$$$LoanCreditFundGUID1$$$']/CashValue not //FundList/Fund[FundGUID=’$$$LoanCreditFundGUID1$$$’]/CashValue

6. When using TYPE=”FUNCTION”, do not use double quotes around the fields.

7. Quotes aren’t needed if a MathIF is used when comparing numbers.

Example: ActiveSegmentCode=01

8. The use of Blank is not needed when blank is a previously defined field. Instead use two single quotes.

9. Use Data Dictionary defined field names for consistency across products.

10. Don’t define MathVariables that aren’t used anywhere.

11. Use Valuation:Policy to retrieve values from valuation when possible.

- When trying to retrieve CashValue from PolicyValues use TYPE=”FIELD” Valuation:Policy:CashValue.

12. Capitalize the words AND and OR when writing SQL. Use sentence case And and Or when configuring anything other then SQL statements.

13. A MathVariable should define its VARIABLENAME and TYPE attributes prior to any other attribute.

Example: <MathVariable VARIABLENAME=”Example” TYPE=”SQL” DEFAULT =”01”>

14. Only use ROUND when there is a reason.

15. Consolidate logic into a single MathVariable where appropriate.

Example: Where an intermediate calculation value is not needed &endash; don’t break the calculation into many steps.

16. Suggestions for when to use MathIF versus TYPE=”IIF”:

- Use MathIF when the value(s) of one or more MathVariables is conditional. That is &endash; if the condition is not met, the MathVariables do not need to be defined.

- MathIF also helps avoid multiple IIF’s when the desired result is one value.

- Use IIF if this specific MathVariable always needs to be evaluated but the resulting value is conditional between two values.

8. Multifields

1. Multifields must be treated separately from fields in the regular part of the transaction. You can’t cross reference fields.

2. Any Multifield field validation, other than verifying whether a field was left blank, must be done in the math of the transaction.

9. Spawns

1. Pass spawn fields in the same sequence as configured in the transaction that is being spawned.

2. Any GUID fields passed as spawn fields should be disabled in the spawned transaction.

3. Spawned transactions should use SPAWNCODE=”01” when the spawned transaction is effective on the same day as the spawning transaction.

4. See AsCode for other spawn code values.

5. DataTypes in spawn fields must match DataTypes in receiving fields.