You are here: Business Rules > System Rules > TransactionTimes

TransactionTimes

Description

The TransactionTimes business rule controls how an activity behaves based on the time of day it is saved or updated. The rule is attached to transactions and any portion of the rule may be configured as a CopyBook overridden at the Company or Plan levels.

TransactionTimes provides two primary elements for controlling whether or not a transaction may process when added or updated: UpdateDate and Allow. Both elements have a common optional attribute called MESSAGE that displays a configured message if any of the validation criteria fails for the primary element.

If the value of the MESSAGE attribute is equal to an entry found on the translation table, the localized (translated) version of the message is displayed to the user. Otherwise, the literal value of the message attribute is displayed.

If no MESSAGE attribute exists, a system message displays a default error message: “Screen alert message is not defined.” Unless otherwise indicated, the message appears at the top of the Activity Detail Screen. To control the messages that display, the system processes in the order UpdateDate and Allow. Failure alert messages are displayed in the order that the associated validations are processed.

The TYPE attribute for the Allow and UpdateDate elements determines when the associated validation is applied based on the screen action being performed.

Add invokes the validation when the activity is first added to the system.
Delete invokes the validation when the activity is deleted.
Process invokes the validation when the activity is processed.
Recycle invokes the validation when the activity is recycled.
Reverse invokes the validation when the activity is reversed.
Update invokes the validation when the activity is re-opened from a pending status or during the re-display of the activity when recycling.

Only one Allow element and one UpdateDate may be added for each action TYPE attribute.

New override buttons in security groups remove security configuration from the business rule and move it to security administration. The override buttons are available for Delete, Reverse, Process, Update, and Add actions.

The UpdateDate element always targets the EffectiveDate field on the transaction. The VALUE attribute identifies the source date value. The source date is always derived from the system date record for the Plan’s MarketMaker calendar. Custom values are not supported. The available date values are NextSystemDate, NextBusinessDate, NextMonthEndDate, NextQuarterEndDate, and NextYearEndDate.

Another attribute on UpdateDate is AUTO, which allows a value of Yes or No (the default being No).

If AUTO is set to Yes and the validation fails, the failure alert message is displayed and the effective date is changed to the VALUE attribute’s date reference. If there are no alert messages from other timing validations, clicking OK again on the activity’s detail screen saves the activity and closes the detail screen .

If AUTO is set to No and the validation fails, the failure alert message displays as a confirmation with an OK and Cancel option. Selecting OK sets the effective date to the VALUE attribute’s date and closes the alert message. If there are no more alert messages, the system saves the activity and closes the activity detail screen. Selecting Cancel closes the alert message and if there are no more alert messages, returns to the activity detail screen for more editing without changing the effective date.

The Allow element controls whether or not the activity can be saved based on the time date validation criteria. If all the criteria are true, the activity is saved.

TransactionTimes Element/Attribute Table

Element	Definition	Attribute	Element/Attribute Values and Description
<TransactionTimes>	The opening and closing elements for the rule.		Allowed at global, plan, company, and transaction level.
<Allow>	Optional, Repeatable: Criteria that allows the activity to process. Repeatable once for each TYPE. At least one <Allow> or <UpdateDate> element must exist in the rule.
	Required: Defines the invocation of this validation during the life cycle of an activity. Validation is applied when activity is added, deleted, processed, updated while pending, reversed, or recycled. A pending activity can be added or updated from the Activity Detail screen.	TYPE	Add – when activity is initially added to the policy. Delete – when activity is deleted. Process – when activity is processed. Recycle – when activity is recycled. Reverse – when activity is reversed. Update – when a pending activity is re-opened for activity detail modification or an active activity’s detail is presented during activity recycle.
		OVERRIDABLE	String; Required Attribute Value; The OVERRIDABLE attribute specifies a comma delimited list of security roles that may add/update a transaction during the prohibited time. This is an exception to the prohibition. Ex: OVERRIDABLE="Super, Manager"
	Optional: The message that is displayed upon validation failure.	MESSAGE	A literal value containing message text. The default message is “Screen alert message is not defined.”
<StartTime>	Optional: Identifies the earliest time an activity can be added or updated. This time validation applies for activities added on the system date. Element is required if <EndTime> is specified.		Reference of a system field (above), a ScreenMath variable or a literal value. All must express the time as an integer (900 for 9:00 AM or 2100 for 9:00 PM).
<EndTime>	Optional: Identifies the latest time an activity can be added or updated. This time validation applies for activities added on the system date. Element is required if <StartTime> is specified.		Reference of a system field (above), a ScreenMath variable or a literal value. All must express the time as an integer (900 for 9:00 AM or 2100 for 9:00 PM).
<BusinessDayIndicator>	Optional: Validate the activity’s effective date as a business day.		Yes – validation performed. No- validation not performed.
<MonthEndIndicator>	Optional: Validate the activity’s effective date as a month end.		Yes – validation performed. No- validation not performed.
<QuarterEndIndicator>	Optional: Validate the activity’s effective date as a quarter end.		Yes – validation performed. No- validation not performed.
<YearEndIndicator>	Optional: Validate the activity’s effective date as a year end.		Yes – validation performed. No- validation not performed.
<Tests>	Optional: A section for additional validation tests that should be performed.
<Test>	Required, Repeatable: The instance of an additional validation.		A literal value in the form of a conditional expression that must evaluate to true or false. System fields and MathVariables are available for the expression.
<Transactions>	Required element at the Plan, Global and Company level. This transaction configuration is ignored when the rule is an APE attached rule (i.e., transaction override)
<Transaction>	Repeatable element containing the transaction name that is restricted
<UpdateDate>	Optional, Repeatable: This element designates criteria that sets the activity’s effective date field to a new value. Only one of each TYPE is allowed. At least one <Allow> or <UpdateDate> element must exist in the rule.
	Optional: Controls the confirmation and message features.	AUTO	Yes – The date is modified upon validation failure and a message is displayed. No – (default) Confirmation is displayed upon validation failure. If confirmation is accepted, the date is modified. If the confirmation is rejected, the activity detail returns for further modification without changing the date.
	Required: Identifies the source of the replacement date value based on the plan’s MarketMaker calendar.	VALUE	NextSystemDate NextBusinessDate NextMonthEndDate NextQuarterEndDate NextYearEndDate
	Required: Defines the invocation of this validation during the life cycle of a pending activity. Validation is applied when an activity is added, deleted, processed, updated while pending, reversed, or recycled. A pending activity can be added or updated from the Activity Detail screen.	TYPE	Add – when activity is initially added to the policy. Delete – when activity is deleted. Process – when activity is processed. Recycle – when activity is recycled. Reverse – when activity is reversed. Update – when a pending activity is re-opened for activity detail modification or an active activity’s detail is presented during activity recycle.
		OVERRIDABLE	String; Required Attribute Value; The OVERRIDABLE attribute specifies a comma delimited list of security roles that may add/update a transaction during the prohibited time. This is an exception to the prohibition. Ex: OVERRIDABLE="Super, Manager"
	Optional: The message that is displayed upon validation failure.	MESSAGE	A literal value containing message text. The default message is “Screen alert message is not defined.”
<StartTime>	Optional: Identifies the earliest time an activity can be added or updated. This time validation applies for activities added on the system date. Element is required if <EndTime> is specified.		Reference of a system field (above), a ScreenMath variable or a literal value. All must express the time as an integer (900 for 9:00 AM or 2100 for 9:00 PM).
<EndTime>	Optional: Identifies the latest time an activity can be added or updated. This time validation applies for activities added on the system date. Element is required if <StartTime> is specified.		Reference of a system field (above), a ScreenMath variable or a literal value. All must express the time as an integer (900 for 9:00 AM or 2100 for 9:00 PM).
<BusinessDayIndicator>	Optional: Validate the activity’s effective date as a business day.		Yes – validation for a business date is performed. No- validation for a non-business date is performed.
<MonthEndIndicator>	Optional: Validate the activity’s effective date as a month end.		Yes – validation for a month end date is performed. No- validation for a non-month end date is performed.
<QuarterEndIndicator>	Optional: Validate the activity’s effective date as a quarter end.		Yes – validation for a quarter end date is performed. No- validation for a non-quarter end date is performed.
<YearEndIndicator>	Optional: Validate the activity’s effective date as a year end.		Yes – validation for a yearend date is performed. No- validation for a non-yearend date is performed.
<Tests>	Optional: A section for additional validation tests that should be performed.
<Test>	Required, Repeatable: The instance of an additional validation.		A literal value in the form of a conditional expression that must evaluate to true or false. System fields and math variables are available for the expression.

XML Example

<TransactionTimes>

<UpdateDate AUTO="No" VALUE="NextBusinessDate" TYPE="Add" MESSAGE="Error Message 1: The Effective Date is changing to the next business Day">

  <StartTime>0100</StartTime>

  <EndTime>2400</EndTime>

</UpdateDate>

<UpdateDate AUTO="Yes" VALUE="NextBusinessDate" TYPE="Update" MESSAGE="Error Message 2: The Effective Date is changing to the next business Day">

  <Tests>

    <Test>SystemDate:SystemDate = SystemDate:SystemDate</Test>

  </Tests>

</UpdateDate>

<UpdateDate AUTO="No" VALUE="NextBusinessDate" TYPE="Process" MESSAGE="Error Message 3: The Effective Date is changing to the next business Day"

    <StartTime>0100</StartTime>

    <EndTime>2400</EndTime>

</UpdateDate>

<Allow TYPE="Add" MESSAGE="Error Message 4: Cannot Add Transactions After 4:00">

  <BusinessDayIndicator>Yes</BusinessDayIndicator>

  <StartTime>0900</StartTime>

  <EndTime>1600</EndTime>

</Allow>

<Allow TYPE="Update" MESSAGE="Error Message 5: Cannot Add Transactions After 4:00">

  <StartTime>0900</StartTime>

  <EndTime>1600</EndTime>

</Allow>

<Allow TYPE="Process" MESSAGE="Error Message 6: Cannot Process Transactions After 4:00">

    <StartTime>0900</StartTime>

    <EndTime>1600</EndTime>

    <MonthEndIndicator>Yes</MonthEndIndicator>

</Allow>

</TransactionTimes>