The SPRMOD module that is included in the MDxBUT routines centrally controls the 4-eye control.
Further details about the implementation of the 4-eye control (also, 4-eye principle) can be found under '4 Eye Control - Implementation' and 'MDxBUT - Static Data System'.
When the 4-eye control is enabled, modifications are not stored directly in the database. Instead, an SPT with the special status PUR (Pending Update Waiting for Release) is created that is waiting for release and a release administration record in table SPR. In addition, this administration record contains information relevant to the release.
On startup the routines check that no SPT is available for the desired object. This avoids multiple modifications of a record, providing that a modification has been entered but not yet been released.
The release transaction SPTREL then allows selective access to various modifications to be released and ensures that the user who enters a modification and the user who releases it do not have the same user ID. A display image of the input panel can be retrieved displaying the modified fields so that the releasing user can check the registered items. Additionally, it is possible to retrieve the Info system for each respective record so that the history of the data can be displayed.
Within the release process, the releasing user can release the modification (= to make a PUP-SPT out of a PUR-SPT) or he can send the modification 'To correction' (= to make a PEN-SPT out of a PUR-SPT) or he can discard the modification completely (= to make a DEL-SPT out of a PUR-SPT).
After the release, the released modifications of the static data are assigned another SPT status, which can be automatically processed by SPTTSK. In order to to so, the original transaction is retrieved by SPTTSK and because of the special SPT status the MDxBUT routines will execute the real storage routines. Additionally is run to determine whether the static data record has not been changed when compared to the original version. If problems occur during saving, the PUP-SPT is re-stored as PEN-SPT or as DEL-SPT. The SPTTSK sets the registering user to the SPT owner for the processing transaction, so that the original registering user is displayed in the SLG with the actual final storing time after the release.
As a side effect, static data modifications can also be interrupted by clicking [Break]. When picking up such an SPT a check is run to determine whether the original data has been changed. If modifications are detected, they will be discarded with a notice and the SPT is set to a DEL-SPT.
The MDxBUT routine looks for the method “GetSprRelLev” in the instance RECPAN (normally the xxxP module), which returns the release relevance to the “Rec” or “RecGroup” that are linked to MDxBUT. The fact that this routine exists and that it provides a value unequal 'blank' activates the 4-eye control when this panel is saved.
The result of this G“etSprRelLev” call is stored internally in SPRMOD in field SPR.RELLEV and is thus also available in this module at a later stage.
Addresses can be added as static data. In this case the 4-eye control is to be used (i.e. addresses have to be released using SPTREL and SPTTSK). In contrast, temporary addresses are defined when capturing the contract and therefore do not have to pass through SPTREL and SPTTSK
If the 4-eye control is activated in the address static data system (DBxPTY, DBxPTA), a decision has to be made on a case-by-case basis how temporary addresses in business transaction are to be dealt with. Either they can still be edited, or the editing/use of temporary addresses has to be completely switched off because the 4-eye control in business transactions is not possible.
This can be determined by the user. If temporary addresses are not to be edited while capturing transactions (i.e. the 4-eye control is active), the user needs to set the flag (at Level 6 in the INIT of the PTSP module) to edit temporary addresses - TMPADREDTFLG - to a non-empty value. In other words,
TMPADREDTFLG is not set –> temporary addresses can be amended and added
TMPADREDTFLG is set –> temporary addresses cannot be amended or added.
Similar to retrieving GetSprRelLev in the static data, by setting TMPADREDTFLG the handling of temporary addresses when editing business transactions is controlled, because 4-eye control is not possible.
When loading a record that contains a modification that has not been released, all GETs display a note relating to the open modification.
Recognizing double registrations does not work when creating new records, as it is not ensured, whether the search key has already been filled completely and correctly.