Priority tip: creating business rules with functions

Priority comes equipped with something called a 'business rule generator'; this allows a user to define actions to be taken dependent on certain conditions, without having to program a trigger. For example, in the 'Customer Shipments' screen, I defined a rule

If 'Billable?' is equal to N 
and 'To ConsignmtWarehs' is blank
then Display error message
"Not able to close shipment form when 'billable' is not set"

(this is a rough translation of the Hebrew text). One is able to set up to three different conditions (in the rule above, the first condition is that field 'Billable?' is equal to N), which is sufficient for most cases. Unfortunately, every now and then, one would like to write a rule which is dependent on four conditions, or one condition is complex (e.g. display an error message when the agent number is not '031' or '046', where the numbers are not contiguous).

I'm not sure that I have a solution yet for four conditions, but I have discovered (by means of the Israeli Priority Users Forum) a technique for complex conditions. Existing functionality enables one to define an expression to be used in a condition, but as usual, this functionality is only partly documented.

One presses the button marked in yellow to display an 'enter expression form'.

Pressing any of the buttons on this form brings up data connected with dates - for example, the documentation shows how to use an expression to display an error message when the supply date of an order is less than five days from today.

In order to display an error when the consignment warehouse is not one of the values '23' or '999', one has to do the following: the rule has to read 'Display an error message when the value of consignment warehouse differs from', with the following expression

(:$.TOWARHSNAME IN ('23', '999') ? :$.TOWARHSNAME : '!!!')

Translated into English, this means: if the value of 'consignment warehouse' is either '23' or '999' then return the value of 'consignment warehouse', else return the value '!!!'. If the value of the warehouse were '12', then this expression would return '!!!' which is different from the value of the warehouse ('12') and so an error message would be displayed. This is an example of the convoluted logic with which us Priority developers have to struggle every day. Most importantly, the 'screen name' of the variable (:$.TOWARHSNAME) must be used and not its title ('Consignment warehouse').

Having documented this, I now need to find a real life example. There are certain advantages to using this technique over using a trigger, as well as some disadvantages. These are listed below in the order of thinking of them.

Advantages:

1. Theoretically, 'anyone' can do this, not only developers, although I'd like to see them try!
2. No need to 'build the form'
3. The rule can be defined for specific users in specific companies 

Disadvantages:

1. No ability to add comments
2. Difficult to see the rule (a trigger can be viewed in a code editor)
3. Not easily copied

[SO: 4442; 5,21,43
MPP: 802; 1,4,6
ELL: 926; 0,2,7]