The Workflow engine integrated into the software is used to parameterize notifications to users, in the form of a line containing a number of information on the event of origin.

These lines can be presented in a workbench that can be parameterized by some transactions, in order to:

  • view the information that have been parameterized for it to appear in the workbench.
  • perform a zoom to a context of origin, if need be.
  • approve lines that do not require an elaborate signature process.
  • affix a signature (by choosing among a group of possible answers) when a signature process has been parameterized.

This function makes it possible to parameterize multitab workbenches in the form of transactions.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

The parameterization screen is subdivided into 8 identical tabs (this is the reason why only one tab will be presented here). Each tab corresponds to a tab in the final transaction. The number of tabs actually used is entered in the transaction header.

Header

The header is used to define the general information associated with the transaction (code and title, access restrictions, number of tabs and lines present by tab).

Block number 1

Transaction code (field WRKTRN)

This code, that identifies the screen associated with the inquiry or the screen, is entered in the record header that enables the definition of the transaction. Upon execution of the transactions and inquiries, the list of the codes that can be accessed by the user is displayed, if the entry into a default transaction has not been forced.
Description (field INTIT)

The title of the transaction, that can be available by language, is displayed in the selection window of the transaction.

Block number 2

Access code (field ACS)

When this field is not empty, the inquiry screen or the movement entry transaction is only accessible to enter data if the current user has been granted execution rights on this code. Moreover the modification (respectively viewing) of the characteristics of the transaction is only possible if the current user has been granted modification (respectively for the inquiry) rights on the code.
Number of tabs (field NBRMSK)

It defines the number of tabs present on the workbench. Based on this number, it is necessary to parameterize the available information along with the sorting and highlighting criteria on each of these tabs.
Number of lines (field NBRLIG)

It defines the maximum number of lines displayed in each tab.

Tab N Page

Each tab is used to define the characteristics of a tab in the workbench. A set of elements are described, first of all, the conditions that allow the filtering of those lines needing to appear in the tab in question (this makes it possible to allocate the lines based on the topic, the urgency or any other criterion between tabs), then the information that need to be displayed, the fields defining the order of appearance, and conditions to highlight some lines by means of styles.

Block number 1

Short description (field INTSHO)

It defines the title of the tab as it appears on the workbench.

Title (field INTLNG)

Long tab title

Filter (field SELWRK)

This condition, defined in the form of an evaluated expression, makes it possible to filter the data available in the various tabs of the workbench. Thus only part of the lines to be processed can be presented by dispatching them to each of the tabs, according to any criteria combination.

Grid Columns

Field (field FLDNAM)

The field code (as it exists in the AWRKHISSUI table) is displayed here.

Order (field FLDORD)

When the transaction is generated, the fields are proposed in the increasing order of the ranks entered in this grid. A null rank means that the field is not present.

In the parameterization function, the fields are presented in the order of the entered ranks each time the transaction is reread, with the null rank fields being placed at the bottom of the grid.
Description (field FLDDES)

The field title is displayed here: its default value comes from the data dictionary, but a right click allows this value to be modified. This is particularly interesting when the field is a generic one (for instance the VALCTX fields), such fields having content that are dependent on the Workflow event.

Grid Styles

Style (field STYLES)

Style associated with the previous condition.

Condition (field CRISTY)

These criteria, defined in the form of calculated expressions, are evaluated for each line of the workbench. The presentation style corresponding to the first verified condition is applied to the corresponding line. If no condition has been verified, the line stays in the default color. This makes it possible to conditionally highlight some lines in the tab.

 

Grid Sort order

Field (field CLEFLD)

The lines in the workbench are presented sorted out by the value of the fields specified in this grid (with equal values for a field, sorted out by the value of the next field).
Sign (field CLESNS)

For each field, it is specified whether the sorting out is performed by increasing or decreasing order of values.

Standard Rerouting Action

It is used to enter all the ranks by increment of 5 beyond the last field to be parameterized as present.

Standard Rerouting Action

It resets to zero all the ranks in the fields.

Standard Rerouting Action

It is used to enter a title set in association with the displayed field. By default, the displayed title comes from the dictionary. Yet, for this button, a specific title can be associated with the corresponding column. This is particularly useful for generic fields, like the varibales associated to the context.
Help

This function enables the display of the online help for the field defined by the line. This provides a detailed description of the usefulness of this field. As a consequence, il will be easier to decide whether it is useful to parameterize the presence of this field in the corresponding screen.

Specific Buttons

Validation

It is used to generate the screens and the window corresponding to the transaction. This operation is performed by default when the transaction is saved, but it can be useful to launch it manually, for instance after a transaction is copied, in the folder where the transaction has been recopied.
Exception delegate (field DELEXP)

When this box is checked, the user sees the notifications sent to the users for whom said user has been granted an exceptional delegation.

This box can only be checked if the user has at least one such delegation.
Recipient (field USER)

It defines the code of the user who is recipient of the Workflow events that are pending signature and need to be viewed.

This code can only be entered in two cases:

  • If the All users option is granted to the current user for the function.
  • If the Exceptional Delegate box is checked (in this case, it is possible to choose the user to whom an exceptional delegation has been granted and whose notifications need to be viewed).

If this field cannot be entered, it is by default equal to the user current value.

If this field can be entered, but no value has been assigned, the following notifications can be viewed:

  • those of the users for which there is an exceptional delegation, provided the Exceptional Delegate box has been checked.
  • otherwise those sent to all the users.
Start date (field DATDEB)

If this date is entered, only the data where the last modification or creation date is later than or equal to it are viewed in the inquiry.

It should be noted that the proposed date is by default today's date, decreased by a number of days equal to the value of the WRKDAY parameter.
End date (field DATFIN)

If this date is entered, only the data where the last modification or creation date is earlier than or equal to it are viewed in the inquiry.

By default this date is equal to today's date.