Rules for the assignment of printers on the launch of a report 

Introduction

At the time of the launch of a report, a default value can be proposed automatically as a function of the context to indicate the destination of the report (printer, file, e-mail...). This default value can come from the user, the report, the site.... with a group of sophisticated priority rules. This document describes the rules and printer assignment priorities as a function of the context.

Prerequisites

Different parameters can be described in order to manage the printer assignments :

*    The destinations table is used to define the printers available to the users, as well as the associated output type. Remembering that the output type is the local menu number 22, which can be set up.

*    The user setup that is used to define a destinations table by default and by type, either directly, or making reference to another user.

*    The reports dictionary defines the reports with a destination by default, an output type which will serve as a filter (except if the first value is a catch-all), and a formula making it possible to express the supplementary value described below.

*    The destinations by user table, which defines the most detailed assignment rules for a destination (by the triplet - user, supplement, report).

Option/Assignment rules

Before going further a comment must be made. Before all destination assignments, two particular cases are used to define a printer in a specific fashion :

* The entry point DEFIMP is used by a specific/custom development, the code called can impose a destination from specific rules. This priority entry point, is called at the end of an algorithm (from this the printer that should be chosen by default in applying all the other rules is known).

* The calling program (if the print is called directly by a process) can also impose the destination.

Keeping in mind these two specific cases, the assignment rules are defined below. The algorithm starts by determining the three following values :

*  In the report dictionary, an Output type is defined. The determination algorithm below only looks for a destination of the corresponding type if the requested type in the report is not the first in the list (in other words, if the destination found is not of a good type, the search continues). Of course it is necessary that the destination is active, and that the user has the right to use it - it is the access on execution of the access code associated to the destination. If the destination does not fulfil these requirements the search continues.

*  If the Additional formula field is assigned in the report dictionary, the result of the formula is evaluated, which is called supplement. The supplement can for example be a site code, if the launched report starts for data from a site. In this way the destination used can depend on the site concerned with the print. If the Additional formula field is not assigned, the Supplement value is considered empty. In the calculation formula used, the following can be included: constants, functions, the setup value of the report from the syntax PARAM(NAMEPARAM), where NAMEPARAM is the setup code as it is defined in the report dictionary, the variables where they are assigned in context - for example the default site for a user for a given module, that can be found in the GFCYDEF table...

* Finally, the connected user code is used as a determination setup, except if, in the record, there exists another user code in the User destinations field (this is to make it possible to define that a user has the same assignment rules as another template user). There may be successive attempts on the user code, but in the case of blockage in the list, the issuing user is used for the code.

The three values (output type found, supplement code value, user code) being determined, the determination rule is the following :  

* The user destinations table is referenced. If there is a line in this table for the current report, the user code concerned, and the supplement value calculated previously, it is the destination defined on the line that will be used.

*  If no value is found for the triplet, and if the evaluated supplement value is not empty, the same table is still referenced looking for a line with a user code and a suitable report code and with the supplement field empty (if the supplement being empty, the search will have taken place previously). If a line exists, the corresponding destination is taken.

* By default, the destination defined in the report record is taken (if it exists).

* If the destination is still not found, a destination of the correct type defined in the user record (if it exists) is used.

*  If the destination is still not found, the search continues for the correct type of the destination associated to the site by default for the user (PRT1, PRT2, PRT3, PRT4 parameters). The default site by user depends both on its function profile and on the module to which it is attached. This search is made using the normal hierarchy rules - site/company/folder for the setup values.

* By default, if a batch launch is made, the first destination of the correct type is chosen. If this is on direct print from a workstation, the first destination of the type Preview will be proposed.

If the destination has been defined in the destinations table by user or in the reports dictionary, a Mandatory box is associated with it. If this is not ticked, the destination thus determined is not mandatory, and the user can change the destination or can redefine it by choosing the destination/server/printer name/characteristics. A destination determined from other rules is never considered as mandatory.

Tables used

The working files are APRINTER [AIM] (destinations table, APRINTDES [AID] (destinations table, supplement), APRTAUS [AIA] (table associating a destination with a triplet [ report code, user code, supplement code] ).