Creating Rule Sets Page 1 of 1

Creating Rule Sets

A Rule Set contains a series of conditions and actions that you want to apply to the data entered for a SunSystems function. Rule sets are defined for an event profile using Rule
Sets (RST).

If you are not familiar with the concept of rule sets, see What are Rule Sets? for further details. For actual rule set examples, see Some Example Rule Sets.

You must define an event profile using Event Profiles (EVP) before you can define the business rules for the profile.

Note: Before you define the rule set for an event profile you must ensure the event profile details are correct, in particular that you have chosen the correct function code. It can
be difficult to change the event profile once the rules have been defined. See Amending Event Profiles.

The following steps are required to create a rule set:

1. Select the Rule Sets form (RST).

2. Enter or select the event profile code that identifies the system function and other conditions for which the new rule set is required.

3. Enter a new rule set code.

4. Enter a description of the rule set.

5. Click Detail to display the Rule Sets - Details form.

6. Click Create to add a new rule to the rule set.

7. Enter the following fields to define the condition or action statement required: Command, Value 1, Operator , Value 2 and the appropriate Decision Columns.

You must click OK after each field to move to the next field.

After you have entered all of the rule details, this new rule appears in the rule set list section in the bottom part of the form.

8. To enter another rule statement after the final statement displayed on the form, click Create and then enter the rule details.

Tip: Use the Insert command to add a new rule statement above the current statement. See Amending Rule Sets.

9. When you have entered all of the required rules, click Exit to return to the Rule Sets form.

10. You can then add or maintain another rule set, or click Exit to leave the function.

mk:@MSITStore:C:\Program%20Files%20(x86)\Infor\SunSystems\01AdministratorGuid... 12/10/2014
Using the Rule Sets Form Page 1 of 1

Using the Rule Sets Form

A Rule Set contains a series of conditions and actions to apply to the data entered for a SunSystems function. Rules sets are defined using Rule Set (RST).

See What are Rule Sets? for an explanation of rule sets. See Creating Rule Sets or Amending Rule Sets for the steps required to create or change a rule set using Rule Sets
(RST).

Tip: You must define the event profile for the rule set before you can define the rule set. The event profile identifies the SunSystems function and other conditions that determine
when the rule set is used.

Rule Sets (RST)

Event Code
Enter the event code to which this rule set applies, as defined in Event Profiles (EVP).

Rule Code
Enter a unique code for this rule set.

Note: You can define more than one rule code for an event profile. If these rule sets need to be performed in a particular sequence, you must set the rule sets
accordingly.

Description
Enter a description for this rule set.

Click Detail to specify the conditions and actions for the specified rule set, for the event profile.

Tip: You must click OK after each of the following fields to accept the choice you make.

Command
Select a command to operate on this rule set line. The commands available depend on the type of statement you are defining. If you are defining a condition statement, the
command is either IF or OR. If you are defining an action statement, several different commands are available; for example CALCULATE, SET and DISPLAY.

See Understanding Action Statements for a complete list of the action commands.

Value 1
Enter or select a record type from the Data Dictionary Lookup window, which lists the valid record types available. Once you have selected the record type, you can choose from
a list of data items associated with that record type. See Selecting Items from the Data Dictionary.

If you select a rule data set, Value 2 is set automatically to the keyword EXISTS and only the decision columns need to be defined.

Tip: To view the source of the data item selected here, click Val 1 Hierarchy History. This identifies how the data item was selected from the data dictionary hierarchy.

Operator
Enter an operator to be used in the rule set. Operators depend on the command used and only apply to the IF/CALCULATE conditions.

Value 2
Enter or select a record type from the Data Dictionary Lookup window, which lists the valid record types available. Once you have selected the record type, you can choose from
a list of data items associated with that record type. See Selecting Items from the Data Dictionary.

Tip: To view the source of the data item selected for Value 2, click Val 2 Hierarchy History. This identifies how the data item was selected from the data dictionary
hierarchy.

Decision Columns
Enter the parameter required in the appropriate decision column, depending on the type of statement you are defining. For a detailed explanation, see Understanding Decision
Columns.

For an If condition statement, the entry in a decision column identifies the result of the condition. The following options are available:

N - No

Y - Yes

For an action statement, an X is entered in the decision column for the appropriate condition statement result.

Tip: An X is always required on an action statement, even when no conditions have been entered.

mk:@MSITStore:C:\Program%20Files%20(x86)\Infor\SunSystems\01AdministratorGuid... 12/10/2014
Understanding Condition Statements Page 1 of 7

Understanding Condition Statements

Condition statements are defined in Event Profiles and Rule Sets. A condition statement uses the IF command and produces a Yes or No result. The
statement may be continued using an OR command.

A condition statement contains some or all of the following fields, depending on the command: Command, Value 1, Operator , Value 2.

For example:

Command Value 1 Operator Value 2

IF Account Code = 64050

An IF condition statement enables a selected data item, identified in Value 1, to be compared against any of the following in Value 2:

z another data item - for example, If Account Code = Supplier Code

z a literal value - for example, IF Account Code >= 64000

z a masked literal value - for example, IF Account Code = 64***

z a workspace value - for example, IF Transaction Date >= Work Space Date 1

z a keyword - for example, IF Account Code = SPACE.

Literal Values

A condition statement can compare a data item value with a value that you enter on the statement. For example, to enable you to check for a particular
business unit code or account code. You should enter the literal value exactly as it would appear in the data item. Do not embed the value in quotes.

Some data items values are held in uppercase, for example, business unit codes and currency codes. If literal values are used on conditions for these data
items, the literal values must also be entered in uppercase.

Top of Page

Masked Values

If a condition statement is comparing a data item value to a literal value, a masking character can be used to ignore selected parts of the literal value. The
masking character, or wildcard character, is '*' asterisk.

For example, to check a five character account code for codes only beginning with 81, the condition statement would be IF Account Code = 81***.

Top of Page

Keywords

Any of the following keywords can be used on an IF statement to check the general characteristics of the data item selected in Value 1:

z SPACE - checks for a blank value

z ZERO - checks for a value of zero

z NUMERIC - checks for a numeric value.

The EXISTS keyword can only be used in conjunction with a rule data set. A rule data set contains valid combinations of codes for a predefined group of
data items. It acts as a lookup table for the data item combination. The EXISTS keyword determines whether or not the codes entered on the current record
are a valid combination for the rule data set.

Tip: The data items that make up the combination are determined by the rule data set keys for the rule data set.

Top of Page

IF/OR Condition Statements

A condition statement can contain IF and OR commands. An OR statement acts as a continuation of the preceding IF statement. It allows the IF statement to
compare more than one value against the Value 1 data item, using the same Operator.

An IF statement can be followed by one or more OR statements. The results of the IF statement, which are identified in the Decision Columns, are only
entered on the IF statement.

file:///C:/Users/RTA/AppData/Local/Temp/~hh5BB.htm 12/10/2014
Understanding Condition Statements Page 2 of 7

For example, if a business rule only applies when ledger analysis code 5 is either P01, P02 or P05, the rules would be represented as follows:

Command Value 1 Operator Value 2 Decision Column 1

IF Ledger Analysis 5 = P01 Y
OR P02
OR P05

A rule set can contain more than one IF statement. In this case, the entries in the decision columns for each IF statement determine whether or not the IF
statements are related. If a decision column is left blank the IF statement is ignored.

For more information on the use of decision columns and the use of multiple IF statements, see Understanding Decision Columns.

Understanding Action Statements

Action statements are entered as part of a Rule Set (RST). An action statement identifies an action that is required, and may be linked to the results of one or
more condition statements.

For example, a business rule is required to ensure that a product code is always entered in Ledger Analysis 5. In this simple case the IF condition
statement checks the value in the Ledger Analysis 5 field, and if the value is blank the resulting action displays an error message.

The rule set condition and action statements would look like this, where the DISPLAY command line is the action statement and decision column 1
links the condition result and the required action:

Command Value 1 Operator Value 2 Decision Col 1

IF Ledger Analysis 5 = SPACE Y
DISPLAY ProductCodeMissingErrorMessage X

Tip: The error message is defined separately using Rule Messages.

An action statement always includes a Command, and Value 1. It may also contain an Operator and Value 2 depending on the command.

Action Statement Commands

The following commands are available for an action statement:

Command Used to
CALCULATE Perform an arithmetic operation using numeric data items and values. During the calculation process, the calculated values are
held in Work space areas. See Using the SET and CALCULATE Action Commands.
CALL Call a COBOL program, for example to enable additional validation to be performed. See Using the RUN and CALL Action
Commands.
DISPLAY Show a user defined warning or information message, or the current value of a selected data item. The operator is able to
continue entering data once the information is displayed.

For example:

DISPLAY WARNINGMSG
displays the message defined in Rule Messages (RMG) as WARNINGMSG.

DISPLAY Address Line 1

displays the first line of address for the account referenced in the current transaction.

See also Specifying Rule Messages.

ERROR Display a user defined message during data entry, or report an error in an import function. The operator is unable to continue
entering data after the message is displayed.

See also Specifying Rule Messages.

MATCH To automatically match items in Reconciliation Manager. See Using Rule Sets with Reconciliation Manager.
RUN Enable an external application to be run with runtime parameters if required. See Using the RUN and CALL Action Commands.
SET Force the value of a selected data item to be set to the value of another data item, work space area, or user defined literal value.
See Using the SET and CALCULATE Action Commands, and Using the SET Action Command to Insert Data.
APPEND Add alphanumeric characters to the end of the contents of the selected work space. You can only append to general work spaces.
You can append text, keywords, the contents of another work space, or data from the function data hierarchy. For example:

file:///C:/Users/RTA/AppData/Local/Temp/~hh5BB.htm 12/10/2014
Understanding Condition Statements Page 3 of 7

APPEND General Work Space 1 Account Code

adds the alphanumeric characters of the account code specified in the current transaction to the end of the contents of General
Work Space 1.

Using the SET and CALCULATE Action Commands

Using the SET and CALCULATE action statements the value of the data item referenced as Value 1 is updated, overwriting any current value. Therefore,
when you are using these commands you must be very careful that you do not update original data entry values in error.

You must use work space areas to store the data values.

Consider the following separate examples:

Command Value 1 Operator Value 2 Result

SET Amount Work Space 1 = Base amount The base amount is stored in amount work
space 1.
CALCULATE Amount Work Space 1 * 0.2 20% of the base amount is calculated and stored
in amount work space 1.
CALCULATE Transaction Amount * 1.1 The transaction amount is increased by 10%
and the original transaction amount is lost!

For more information on using the work space areas, see Understanding Work Space Areas.

Using the SET Action Command to Insert Data

You can use the SET action command in a Rule Set to 'insert' data, or force certain fields to take specific values whilst data is entered.

For example, during Ledger Entry (LEN) you could SET a particular ledger analysis code to a specific value, or in Chart of Accounts (COA) you could SET
the Short Heading to take the same value as that entered for the Account Code. These separate examples are as shown in the following table:

Command Value 1 Operator Value 2 Result

SET Ledger Analysis 1 = N1C0 Regardless of what the operator enters in Ledger
Analysis 1, the code N1C0 will be inserted.
SET Short Heading = Account Code Regardless of what the operator enters in the
Short Heading field, it will be given the same
value as the Account Code.

Note: When using the SET action command in a Rule Set to insert line data for Ledger Entry and/or Ledger Import, you must specify one of a set of special
Call Points in the Event Profile, otherwise the SET action is ineffective during data entry/import. For details, see Financials Call Points and Actions.

Which Fields Can be Inserted with the SET Action Command?

When defining a Rule Set to insert data with the SET action command, most of the fields that can be checked by a business rule can also be inserted or
changed by the business rule. However, certain data items in each function cannot be changed or inserted with the SET command.

Fields that are unique keys to a record must be created during data entry. Such fields cannot be SET by a business rule, even though they can be checked for
validity by the business rule. A few examples of such unique key fields in static data maintenance are: Account Code, Asset Code, Asset Subcode, Bank
Code, and Bank Subcode; all of which must be created by the operator during data entry. In another example, Ledger Entry, the Journal Number cannot be
SET by a business rule, because it is a unique numeric key to the journal created by SunSystems during posting.

Note: If you need to set a value for a data item, you must ensure that the value is allowed to be entered on the transaction for the data item, for the
appropriate function. For example, for the Ledger Entry function, if you want to set a ledger analysis dimension code you must ensure that the code exists,
and that the analysis dimension is allowed to be entered on the relevant journal type.

Using the RUN and CALL Action Commands

The CALL and RUN action commands allow a business rule to execute external COBOL programs, known as Process Extensions, or applications.

CALL Command

The CALL command is used to execute a COBOL process extension, (previously referred to as a user hook). This can be useful if complex processing is
required to validate and update the transaction details, and where external data must be accessed.

For example, the business rules attached to the sales order entry function may need to ensure there is adequate stock on hand to meet a sales order, and a
separate COBOL program (VALIDATE) has been developed to do this.

Command Value 1 Operator Value 2 Result

CALL VALIDATE The VALIDATE.GNT cobol program is executed.

Note: The COBOL program must be held in the SunSystems default top level directory.

file:///C:/Users/RTA/AppData/Local/Temp/~hh5BB.htm 12/10/2014
Understanding Condition Statements Page 4 of 7

When the CALL command is executed, the current transaction being processed by the rule is passed to the COBOL program with other information in the
LINKAGE SECTION. If the transaction details are updated by the COBOL program, the modified transaction details can be returned to the business rules.

These COBOL process extensions must be developed by trained COBOL programmers who have a good understanding of the SunSystems data structures
and processes. If you require further information please contact SunSystems Technical Support.

Note: SunSystems always maintains the integrity of its accounting data. Any data that is returned to a system function from a process extension is always
fully revalidated. If a CALL to a COBOL program is made after the transaction details have been validated or posted, any changes the program makes to
restricted data items on the transaction details are ignored.

RUN Command

The RUN command runs an external Windows or other application from within business rules. For example, after an error message is displayed the RUN
command could be used to initiate MS Notepad to enable the user to make a note of the error message.

Runtime parameters can be entered for the application in the Value 2 field. For example, the business rule might run MS Excel and pass the name of the
worksheet to be updated as the parameter.

Understanding Decision Columns

Decision Columns are used to identify the actions that are required when particular conditions are, or are not, met. They allow the action to be varied
according to the result of the condition. There are up to ten decision columns available in a rule set.

Note: It is vital that you analyze your rule set conditions and actions in detail and plan the use of the decision columns before you begin creating the rule
sets.

The result of a condition is always either Yes or No, and a different action may be required for each result. The result of a condition is entered as Y or N in
the decision columns for the condition. The action required for a result is identified with an X in the same decision column on the appropriate action
statement.

For example, a business rule is required to check the value in ledger analysis 5. If it contains the value P01, the rule should set the value of ledger
analysis 6 to ABC. If ledger analysis 5 contains any other value, ledger analysis 6 should be set to 123.

In this example, decision column 1 is used to identify the action if the result of the condition is Yes, and decision column 2 is used to identify the
action if the result is No.

Command Value 1 Operator Value 2 Decision Column Decision Column 2

1
IF Ledger Analysis 5 = P01 Y N
SET Ledger Analysis 6 = ABC X
SET Ledger Analysis 6 = 123 X

Using Multiple IFs and Decision Columns

You can include multiple IF condition statements in a rule set to check different data items. If you use the same decision columns on each statement, the
results of the IF statements are linked. Alternatively, if you use separate decision columns, the IF statements are treated separately.

An Example of Multiple, Related IF Statements

The following rule set displays an error message if a journal description has not been entered when the account code is P01.

Tip: This rule does nothing if the account code is not P01, or if the description is not blank, because these results have not been identified in decision
columns.

Command Value 1 Operator Value 2 Decision Column 1

IF Account Code = P01 Y
IF Description = SPACE Y
DISPLAY Desc-Required_Message X

An Example of Multiple, Unrelated IF Statements

In this example the first two IF statements are related because decision columns 1 and 2 are used for both statements. The rule checks the contents of
BOTH the account type and address code items before deciding on the action required, that is to either display an error message or display address
line 1.

file:///C:/Users/RTA/AppData/Local/Temp/~hh5BB.htm 12/10/2014
Understanding Condition Statements Page 5 of 7

The third IF statement is unrelated and is treated separately because it references a different decision column (3). Ledger analysis code 4 is checked
and an error message is displayed if it is missing, regardless of the account type and address code values.

Command Value 1 Operator Value Decision Decision Decision

2 Col 1 Col 2 Col 3
IF Account = Debtor Y Y
Type
IF Address = SPACE Y N
Code
IF Ledger = SPACE Y
Analysis
4
DISPLAY Error X
Msg -
Address
Code
required
DISPLAY Address X
Line 1
DISPLAY Error X
Msg -
Analysis
Code 4
required

The example above is extended below to illustrate the use of the OR statement. The decision column results are not entered on the OR statements
because they are simply the continuation of the preceding IF statement.

Command Value 1 Operator Value 2 Decision Decision Decision

Col 1 Col 2 Col 3
IF Account = Debtor Y Y
Type
OR = Creditor
OR = Client
IF Address = SPACE Y N
Code
IF Ledger = SPACE Y
Analysis
4
DISPLAY Error X
Msg -
Address
Code
required
DISPLAY Address X
Line 1
DISPLAY Error X
Msg -
Analysis
Code 4
required

Further examples are provided in Some Example Rule Sets.

Understanding Work Space Areas

Work space areas provide an area of temporary working storage for data values. Five work space areas are provided for each of the following data types:

z Amount

z General

z Date

file:///C:/Users/RTA/AppData/Local/Temp/~hh5BB.htm 12/10/2014
Understanding Condition Statements Page 6 of 7

z Period.

Work space areas are used most commonly with the CALCULATE action statement, where a data value is SET to a work space slot.

For example, if you want to calculate the due date for a transaction by adding 30 days to the transaction date you must first copy the transaction date into a
work space area.

Command Value 1 Operator Value 2

SET Date Work Space 1 = Transaction Date
CALCULATE Date Work Space 1 + 30
SET Due Date = Date Work Space 1

Note: The work space areas are shared by all of the business rules that are active for a system function. This enables work space area values to be passed
from one rule set to another within the same, or different, event profiles.

Some Example Rule Sets

The following example Rule Sets may help you to understand how business rules can be applied in practice. They also provide examples of how you might
plan and document your business rule requirements before you begin creating the Rule Sets in the system.

Example 1: Resetting Analysis Codes on Stock Cost of Sales Interface

The following rule ensures the analysis entered on transactions flowing across the Stock Cost of Sales interface, identified by Journal Type GJSTK, comply
with the analysis requirements. Where an analysis code is not required, but exists on a transaction, the code is set to N/A.

Note: Analysis code N/A is created as a valid code for all analysis dimensions that require a code to be entered. If an analysis dimension has been defined
as mandatory a valid analysis code must be entered. If an analysis code is not known, or not applicable, the N/A code is used.

Rule LA001
Command Value 1 Operator Value 2 Decision Column Decision Column 2
1
IF Journal Type = GJSTK Y Y
IF Account Code = 500110 Y
IF Account Code = 120150 Y
SET Ledger Analysis 1 = N/A X
SET Ledger Analysis 2 = N/A X X
SET Ledger Analysis 3 = N/A X X
SET Ledger Analysis 4 = N/A X
SET Ledger Analysis 5 = N/A X
SET Ledger Analysis 9 = N/A X X

Example 2: Setting an Analysis Code

This rule sets the correct cost centre code in Ledger Analysis 1 for transactions posting to account 530140, if the journal type is FAIMG or INT20.

Rule LA002
Command Value 1 Operator Value 2 Decision Column Decision Column 2
1
IF Journal Type = FAIMG Y N
IF Journal Type = INT20 N Y
IF Account Code = 530140 Y Y
SET Ledger Analysis 1 = DPG41 X X

Example 3: Validating Sales Order Processing Revenue Transactions

This rule ensures all transactions entered for sales order posting to a revenue account reference an item code. Revenue accounts are identified by a 4 in the
first character in the account code, and a redefined data item of A/C Code-Pos 1 has been created to identify this.

Message SOPE1 reads: Accounts beginning with 4 MUST reference an item code.

file:///C:/Users/RTA/AppData/Local/Temp/~hh5BB.htm 12/10/2014
Understanding Condition Statements Page 7 of 7

Rule SOP001
Command Value 1 Operator Value 2 Decision Column 1
IF A/C Code-Pos 1 = 4 Y
IF Item Code = SPACE Y
OR -
ERROR Msg SOPE1 X

Example 4: Assigning Destination and Flow Codes

This rule ensures that the correct type of destination code (ledger analysis 4) is entered on transactions posting to profit and loss or balance sheet accounts.
For profit and loss postings, a two character Destination code is required, whereas for balance sheet postings a three character Flow code is required.

The rule uses the Ledger Analysis Usage flag to determine whether or not a code has been entered. It then checks to see whether a third character is present
to determine whether a two or three character code has been entered.

Message SOPE2 reads: This account requires a two character Destination code.
Message SOPE3 reads: This account requires a three character Flow code.

Rule SOP002
Command Value 1 Operator Value 2 Decision Decision
Column 1 Column 2
IF Ledger Analysis Usage Flag - Ledger = Yes Y Y
Analysis 4
IF Account Type = Profit and Loss Y
IF Account Type = Balance Sheet Y
IF Customer-AD4 - Pos 3 = SPACE N Y
ERROR Msg SOPE2 X
ERROR Msg SOPE3 X

file:///C:/Users/RTA/AppData/Local/Temp/~hh5BB.htm 12/10/2014