This transaction fulfills the following tasks:

• Generating QUE entries for diary entries when these are due for processing.
• Generating QUE entries for registered transactions (RIM) when these are due for processing.
• Physically deleting QUE entries is marked as logically deleted due to settlement or elimination of the underlying task.
• Automatic prioritisation and load distribution (if parametrized).
• Release of logically blocked entries that were not automatically released due to technical problems.

As a rule, this transaction typically runs in the background.

Via the Queue, it is then possible to carry out integrated processing of all tasks known to the system via the “Selecting pending Queue Entries” (QUESEL) transaction.

N.B.: Configuration of the distribution is only visible and possible if, beyond the prioritization, the distribution target “User” or “User Group” has been selected.

The priorization of tasks determines the sequence in which these are displayed in the “Selecting pending Queue Entries”. This is intended to enable the user to determine the sequence in which processing is to take place. The priorization is newly triggered with each QUETSK run for all objects selected on the configuration panel. The priority of the individual QUE records is controlled by the entries in the lower section of the configuration panel. The rules are executed in the sequence of the numbers appearing in the first grid column. If several rules apply to a particular object, then only the first applicable rule will be used.

The object class defines the queue entry types to which the rule is to be applied. For instance, this makes it possible to always push releases in prioritization to the top of the list.

The remaining time defines how many minutes this rule is to be applied prior to reaching the target time. Only queue entries that need to be completed within the specified period of time will be observed. The value 0 means no entry, i.e. all entries will be taken into account in this case.

Via the SLA class, a rule can be restricted to a certain service level. The service levels are defined in the addresses per customer.

The priority is determined by the importance of the queue entries concerned. This is the first sort criterion in the selection of open QUE records.

The sorting within the priority class controls whether the entries are to be sorted by target time and amount, or conversely by amount and target time.

In looking at the automatic workload distribution, a distinction is drawn between the standard version and the extended function. The extension is an element of the module subject to license, namely “Management Dashboard”.
The workload distribution in each case is performed by QUETSK. In the extended version, only additional data for control purposes is taken into account.

The objective of automated workload distribution is to ensure an automatic allocation of the work orders to the individual users that is as just and fair as possible. To this end, on the one hand the working time available today is taken into account and, on the other, the expected workload associated with a particular task.

The working time still available today per user is determined on the basis of the working times stored in the Entity group (see “Maintaining Entity Groups”), Entity (see “Maintaining Entities”) and User (see “Maintaining User Profiles”). Moreover, the extension module provides an option also to record spontaneous (even hourly) absence (see “Maintaining User Absence”) of a user.

For the workload anticipated in connection with a task, the times entered in System Configuration (see “Maintaining System Configuration”) are used as a basis. Using the extension module, these times can be overridden per Service Level ( see “Maintaining Service Level Agreements”) and business transaction.

The distribution of tasks is carried out with each run of this transaction. In the process, a selection can be made as to whether tasks already assigned are to be newly examined along with the overload percentage as of which a redistribution is to be made.

With each run, first of all the queue entries are determined that need to be considered. These are prioritized and then assigned to the individual users in the order of their priority. For purposes of such assignment, it is determined per user how much time is still available to the person in question after deduction of the assigned tasks. The task will then be assigned to the user who still has the most free time at his disposal. In the process, a study is carried out as to whether the user in question is allowed to process the current task. To this end, the user profile and release authority of the user are analyzed (these settings can be made in the “Maintaining User Profiles” transaction). If there is no user with sufficient spare time, then the task will be assigned to the user with the lowest overload.

If a user is absent “today”, then he will not be assigned any work orders for the subsequent days either. With the first workload distribution on the following day, the user will immediately be assigned tasks again.

Manually assigned work orders are not automatically redistributed. If such an order is to be returned to workload distribtution, then the assignment in the manual processing of QUE sets can be canceled in the “Queue Handling” transaction.

Interrupted transactions or those set for correction are considered to have been assigned manually and are therefore not automatically redistributed. In the case of incoming messages and memos recorded manually, a user may be assigned directly. In this case, no redistribution will take place either. A releaser may likewise be assigned as early as at the business transaction stage. These work orders are not automatically redistributed either.

Load Balancer
Configuration Generation
Debug