When creating a document from a business object in IFS, you fill in attributes values about the document. The Document Class is used to indicate which category the document falls into, Format used to indicate the format of the file checked into the document and Language code is the language in which the document is written.
These attributes can have default values, set centrally for documents created from any object. As the user creates a new document to an object, these default values are fetched automatically.
In order to set different default values for different types of business objects, Document Basic/Document Defaults per Object Types page should be used. You can even control the default values based on the keys or other field values of the business object.
Note: In order to setup rules for this functionality you need to be granted the DEFINE SQL system privilege. This is because when creating rules you indirectly create SQL that will be run by users. It's important to be careful not to create any invalid SQL since that will result in a rule that will not work.
In order to explain the functionality in this page, the fields can roughly be divided into two categories: condition fields and attribute fields.
Condition fields
A condition field is a field where you define an expression that will be used to match against the actual attributes that the user enters when creating a document from an object. The condition fields are:
The condition fields contains conditions in the form of expressions. The expressions are evaluated when a rule is tested against the document and object attributes.
The expressions in the LU Name and Key Ref fields can contain a fixed value with alphanumerical as well as whitespace and separator characters, or it can contain standard SQL wildcards (% and _), or a combination of both. It can also contain multiple expressions like these separated with a semicolon (;).
The expression in the Object Condition field can contain a valid SQL expression and is therefore very flexible and powerful. Normally it is used to match a certain field on an object against a fixed value. For example, if LU Name is set to EquipmentFunctional, the Object Condition field could contain an expression like this: mch_type = 'SYSTEM'. Such an expression would match only equipment objects where the Mch Type field has the value SYSTEM. Mor advanced conditions is supported, including logical operators like AND, and OR, and including operators like LIKE for wildcard matching. SQL functions are also supported, which means you could have an expression like this: SUBSTR(mch_type, 1, 1) = 'S'. That expression would match all objects where the Mch Type field starts with the letter S.
Note: The condition fields LU Name and Key Ref must have values. If you do not set one, the system will set the wildcard % in the field. The Object Condition column field is optional to use and can be left empty.
Which condition fields should I use? This depends on how detailed you want to be when you match against the object. In most cases, it is enough to set LU Name to the object type you want to match against. In other cases you want to match against one of the keys in the Key Ref and in other cases you want to match against any field on the object, including custom fields and including using SQL expressions.
Attribute fields
The attribute fields keep the actual default values that should be set on the document. It is mandatory to have a value on these fields. The attribute fields are:
Apart from the fields in the two mentioned categories, there is a Config No and a Prio field. The former is just an identifier/number that can be used to refer to a certain rule. The latter is explained below.
To reduce the need for many rules, it is possible to inject dynamic values into some of the expressions in the rules. This is done using two different kinds of placeholders, for global variables and for column / field values. The following section explains how to use this optional functionality.
Global variable placeholders
Optionally, in the Key Ref, Object Condition and Document Class fields, global variable placeholders can be used. A global variable placeholder has the following format: #NAME#, where NAME is the name of the global variable. Currently the names SITE and COMPANY are supported and they stand for the user's default site as well as his default company.
Example: If you input #SITE# anywhere in the Document Class field, it will be replaced by the value of the user's default site before the final default value of the document class is set. It can be combined with normal text, so an expression like SPEC#SITE# will be evaluated to SPEC70 if the user's default site is 70 . Company works in the same way. Multiple global variable placeholders can be combined, if needed.
In the key ref and Object Condition fields, it works similary but the purpose is different. When used in the Document Class field, the global variable will be used to generate the class value itself, but in the key ref and object connection fields, it will be used in the condition, in order to find a rule that matches. Example: assume the following expression in the object connection field: #SITE# = 70. Before this rule is tested, #SITE# will be replaced by the user's default site, so the resulting expression used for testing will be 70 = 70 (which is always true), which means that there will be a match on the Object Condition. Used in the key ref field, it will work in the same way.
Column placeholders
A column placeholder is a way to access a field (column) value from the connected object, and apply it to the document class and other fields. The syntax for column placeholders is: [COLUMN_NAME]. The column/field must exist in the database view that is configured in Solution Manager / Object Connections for the LU Name. Example: for a rule on LU Name = EquipmentObject, we can use the expression [CONTRACT] (site) anywhere in the Document Class field. Assuming the site of the equipment object is 10, the expression [CONTRACT] will be replaced with 10. As with global variable placeholders, column placeholders can be combined and used multiple times. Even different columns from the same object can be used at the same time and it can also be combined with global variable placeholders.
When trying the defined rules to see if they match a certain object, they will be tried according to a calculated score. A rule with a low score gets higher priority. The rules with the highest priority (lowest score) will be tested/applied before rules with lower priority (higher score).
The priority for a rule is higher the more specific it is (lower score) and it is lower the more general it is (high score).
For each condition field in a rule that contains a wildcard, the more general it gets (since it matches a broader range of records), and the lower score and the higher priority it gets. A field value (for example PUMP) is very specific and gives a low score and high priority. A field that combines letters or numbers with a wildcard is less specific than a field with only letters and numbers but more specific than a field with only a wildcard. A field that contains multiple expressions will get lower priority than a field with only one expression.
Since the Object Condition field can contain very complex expressions, it is impossible to calculate a correct score / priority for rules that uses it (the expression can be very specific or very general.) If an Object Condition has been set, the score is modified to be very low.
In cases where the priority between rules are the same, seen by the system, or if they are not what one expects, the optional Prio field (hidden by default) can be used to affect the score and hence the priority. If the system uses a different rule than what can be expected, enter a numeric value for the Prio field on the rule you want to give higher priority. The value will affect the score of a rule, so the lower the value, the higher priority the rule will get.
To better understand the score or priority of the rules, the records are sorted in the page with the rules with the highest priority first, when the page is populated. In this way, you can experiment with a value for the Prio field until the priority is as expected. If you change the priority, populate the page again to see the new order.
If you want the Document Class attribute to have the default value 100 for the documents created from the Functional Object, you have to define the rule as given below. And select a format and a language.
| Config No | Lu Name | Key Ref | Object Condition | Document Class | Format | Language Code | Prio |
| 1 | EquipmentFunctional | % | 100 | A3 | en | ||
| 2 | PlantObject | % | [KEYA01]SPEC | A3 | en | ||
| 3 | ManSuppInvoice | % | INVOICES_#COMPANY# | A3 | en |
Above, Rule 1 is already explained. Rule 2 uses a column placeholder in the expression for what document class to use. It will combine the value of the KEYA01 column/field of the design object with the fixed text SPEC, to determine the default document class. Rule 3 used a global variable placeholder to define the default document class to be used. If the user's default company is 20, then the document class name used will be INVOICES_20.
It could also be that you want to have different default values depending on one of the key values of the business object. In the following example we have defined a special rule for functional objects on a certain site:
| Config No | Lu Name | Key Ref | Object Condition | Document Class | Format | Language Code | Prio |
| 2 | EquipmentFunctional | CONTRACT=20^MCH_CODE=%^ | 100 | A3 | en |
In the rule above, we set Document Class to 100 , Format to A3 and Language Code to en , for a document created on a functional object in site 20 .
If you want to have different default values depending on one of the value of any field on the business object, you can use the Object Condition field. It is similar to matching against keys in the key ref, but more general, since any fields, even custom fields, can be matched against. Also, all forms of SQL expressions are supported (more or less anything you could write in a WHERE clause.) Here are some examples:
| Config No | Lu Name | Key Ref | Object Condition | Document Class | Format | Language Code | Prio |
| 2 | EquipmentFunctional | % | mch_name LIKE 'Area %' | AREADOCS | A3 | en | |
| 5 | EquipmentFunctional | % | #SITE# = 70 | SITEX | A3 | en | |
| 3 | DocFolder | % | folder_name = 'Specifications' AND parent_folder_name NOT LIKE 'Project X' | SPECS | * | en | |
| 4 | DocFolder | % | folder_name = 'Specifications' AND parent_folder_name LIKE 'Project X' | SECRET | * | en |
Rule 2 above matches equipment objects where the object name starts with the word Area . Rule 3 matches document folders that has the name Specifictions but not those that has a parent folder named Project X. Rule 4 is the rule for documents connected to the secret project X. Rule 5 contains a global variable placeholder to check if the user's default site is 70.
Below are a list of rules that all match a certain document-object connection (The document class and other information to be used when creating a document from Equipment functional). However, some of the rules are more specific than the others, and that gives the rule higher priority when the system selects one:
| Config No | Lu Name | Key Ref | Object Condition | Document Class | Format | Language Code | Prio |
| 5 | EquipmentFunctional | CONTRACT=20^MCH_CODE=%^ | 100 | A3 | en | ||
| 6 | EquipmentFunctional | % | mch_type LIKE '%SYSTEM' | 200 | * | en | |
| 4 | EquipmentFunctional | % | 300 | A1 | en | ||
| 3 | % | % | 400 | * | en |
Given the rules above, rule 3 has the lowest priority, since it is the most general rule. Rule 4 is more specific, since there is a fixed value for LU Name, and therefore has higher priority than rule 3. Rule 5 has the highest priority since it is very specific in the condition fields, and will be tried before the other rules. Rule 6 has an object condition set and also has high priority (but lower then Rule 5.)