The required signatures for every transaction - depending on the type and content of the transaction - are calculated when the transaction is stored within the transaction record. For every transaction a set of up to three required signatures can be stored.
If required, the user creating a transaction can automatically add his signature.
In the Control & Release transaction, the signature authorization of the current user for the current transaction is evaluated, and - if sufficient - one of the required signatures is marked as fulfilled.
On creation and for every signature an event is created in the eventtable. For every signature a reference to the event and the user is stored within the transaction.
When all required signatures of a transaction are fulfilled, the transaction is marked as released. In this case, the transaction status flag in the transaction is set to 'R'eleased and the workflow entry for service 'Release' is set to 'D'one.
If a transaction is rejected, this is marked in the transaction as an 'R' (for rejected) signature. The workflow entry for service 'release' is set to 'E' for error. The transaction is marked with 'N' in the status field and stored in the deleted items queue.
If a transaction is sent back for correction this is marked in the transaction as a 'C' (for 'to correct') signature. The workflow entry for service 'release' is set to 'E' for error. The transaction is marked with 'N' in the status field and stored in the pending items queue.
The release group is a code assigned to every user in the user profile. This value describes the authorization class, a user belongs to (e.g. “Clerk” or “Officer”). The table for these codes is the 'embedded keytable' to field USR/RELGRP.
The release amount for a user is the maximum amount up to which the signature of this user is valid. This value together with the user release group is used during Control&Release to determine the user's valid signature for a specific transaction.
A signature is a one-letter code describing type and qualification of one signature applied to a transaction.
Code 'R' is reserved for rejection of a transaction.
Code 'C' is reserved for 'Sent to Correction'.
Codes 'A' and 'B' are typically used for signatures of different quality which can be requested for a transaction.
The use of other codes than 'R' and 'C' depends on the classification of signatures used in an installation. The keytable for these codes is RELSIG.
The data field 'required signatures' (field TRN\RELREQ) of a transaction contains the signatures this transaction requires in order to be released for further processing. This field has to be filled by the “TRNISM.SetRelRequestxxx” methods on storage of a transaction.
The data field 'applied signatures' (field TRN\RELRES) of a transaction contains the signatures applied to this transaction. This field is amended by any signature applied either during Control & Release or creation of the transaction.
The valid signature describes the signature for a transaction (i.e. transaction record) the current user may add to this transaction: The valid signature is determined by rule “TRNSIG.SigUsrRelFlg” from the users' release group and release amount and the relevant amount of the transaction. If these amounts are not in the same currency, they are converted using today's rate and conversion type 'M'.
The position of a signature in the sequence of required or applied signatures (i.e. 1st, 2nd, or 3rd signature).
In Control & Release the signature position is evaluated either manually or automatically. The system automatically uses the rule TRNSIG.SigGetUseIdx to search for the highest requested signature where the allowed signature would be sufficient. That means an overqualified signature might be used to satisfy a request.
A transaction as a whole is released, if the applied signatures are identical with the required signatures. If required and applied signatures are identical, the transaction status TRN\RELFLG is set to 'R'eleased. If a workflow entry for release exists (row in table WFE with service entry REL), the status of this entry is changed to 'D'one.
The release procedure is controlled via the application transaction profile. It can be defined or changed via the fields 'Release Method' and 'Relevant Amount' in the transaction “Maintaining Entity Group Transaction Profiles” (DBIETP).
All installation specific modification for control and release are to be done in module TRNSIG.
Rule “TRNSIG.SigUsrRelFlg” is used to determine, what signature the user could apply to this transaction. For this purpose the relevant amount is converted into the currency (USR\RELCUR) in which the release threshold for this user is defined (USR\RELAMT). Depending on the comparison of these amounts and the release group (USR\RELGRP), SigUsrRelFlg returns the maximum signature value this user could apply to this transaction.
Rule “TRNSIG.SigGetUseIdx” determines from requested signatures (TRN\RELREQ) and the release result reached so far (TRN\RELRES), which position in the signature result (TRN\RELRES) the signature of the quality determined with UsrRelFlg could take. If the user already attached any signature to this transaction or created the transaction himself, this function will return zero (i.e. no signature applicable).
Rule “TRNSIG.SigCheckUseIdx” checks whether a specified signature can be applied in a specified position. This rule is only used to check the manual entry of the signature position in Control & Release.
Rule “TRNISM.SetWorkFlow” creates the actual workflow entries. If a signature for the user who creates the transaction should be applied, this could be coded here following the call of “wfm.create”, which creates the workflow entries.