TransactionTimes Business Rule

The TransactionTimes business rule has been implemented in order to provide additional controls over when certain transactions can be processed based on the time of day. If this business rule is attached to a transaction, then users can prevent the transaction from being processed as well as update the activity effective date based on certain criteria defined in the business rule.

This attached rule should not be added to the TransactionBusinessRulePacket, but will be configured as a transaction level override. This business rule is a system rule and can be found in the System folder in the Global Rules Explorer.

TransactionTimes rule is now updated to accommodate the following changes to the existing elements, their behavior and addition of new element <Prohibit> as described below. Configuration of this rule will allow a <Prohibit> element that works the opposite of <Allow>. This supports conditions that are easier to restrict rather than permit. Additionally, the <Allow> and <Prohibit> elements are repeatable to support a 'best match' scenario to find the first configured set of criteria that are all true.

<UpdateDate>:

This element designates criteria that sets the activity’s effective date field to this new value. Configuration of multiple instances of <UpdateDate> paired with same action <TYPE> (Add, Delete, Update, Recycle, Reverse, Process) are now allowed. <UpdateDate> can be executed when the test condition results to be true, If multiple tests evaluate to be true, for the same pair of <UpdateDate> and <TYPE> – the first definition should apply (processing from top to bottom in the configuration). <UpdateDate> is the first validation to execute before <Allow> or <Prohibit>

<Allow>:

This element indicates when an action <TYPE> is allowed. Configuration of multiple instances of <Allow> paired with the same action <TYPE> (Add, Delete, Update, Recycle, Reverse, Process) are now allowed. <Allow> is to be executed when the test condition results to be true, If multiple tests evaluate to be true, for the same pair of <Allow> and <TYPE> – the first definition should apply (processing from top to bottom in the configuration)

The new child element <Prohibit> to <TransactionTimes> is added and this indicates when an action <TYPE> is NOT allowed, this shall have a behavior inverse of <Allow> element. Configuration of multiple instances of <Prohibit> paired with the same action <TYPE> (Add, Delete, Update, Recycle, Reverse, Process) is now been allowed. <Prohibit> now has all the child elements and attributes as they exist for <Allow> today.

<Prohibit> is now executed when the test condition results to be true (including current system time compared to start and end time specifications if the transaction is effective current day). If multiple tests evaluate to be true, for the same pair of <Prohibit> and <TYPE> – the first definition should apply (processing from top to bottom in the configuration). Configuration of <Allow> and <Prohibit>, paired with same action <TYPE>, will not be allowed.

In case of any conflicts the system will throw an error for the conflicts type actions. Configuration of <UpdateDate> and <Prohibit>, paired with same action <TYPE>, may be allowed.

The security override buttons available for Delete, Reverse, Process, Update, and Add actions has been extended to <Prohibit> as well as <Allow> and <UpdateDate>.

Note

A complete explanation of the elements, attributes and values used to configure this business rule is included in the XML Configuration Guide. Click Help and select the option for the Configuration Guide. This business rule can be found in the System Rules section.