This optional Task Manager controls the execution of the PDX service, itself an optional service, which is used to recalculate existing transactions based on current rates. This service can only be processed by this particular Task Manager.

The service loads the transaction and carries out a complete redefault as if the transaction had been set to Repair immediately retrieved again.

The service updates all relevant rates in the transaction, opens the current terms and conditions and automatically runs a recalculation based on the new rates. The complete transaction is then saved in the database. The service replaces existing documents with newly created documents. If the transaction cannot be saved - because error messages have been issued by a check rule function, for example - the transaction is set for Repair and must be processed manually.

Errors can arise, for example, when the re-valuation takes place on the day after the transaction was captured. Here, it is possible that checks of value days no longer permit a manually set, and therefore not newly defaulted, date.

The “Settlement” panel allows the user to configure whether a recalculation of the transaction with new rates needs to be applied.

If the service is enabled in the Workflow, it must be defined as a 'node'. This means that no other service can run in parallel. If the service is executed for a transaction and if subsequent transactions exist for this transaction, these subsequent transactions will be rolled back and set to the special status of 'wait for PDX'; the service will then process the transactions automatically. If an error is encountered during the service, the transaction and the dependent subsequent transactions will be rolled back and need to be corrected manually. As long as transactions for a contract are in 'wait for PDX' status, no new transactions may be recorded.

An execution date can be entered for the PDX service on the “Settlement Details” panel. If such a date has been entered, the service is executed when this date has been reached.

If a transaction is stored again under the PDXTSK Task Manager, all warnings already read once will be ignored.

Note regarding Unix installations: If the PDXTSK Task Manager is to be integrated in the Background Manager (SYSMGR), 'pdxtsk' needs to be entered in the embedded codetable for the SYSMGR (SYSMGR:MGRNAM). The PDXTSK transaction is automatically taken into account by the scripts 'allsrvstart' and 'allsrvstop' and does not need to be adapted to these scripts.

Managers running in foreground mode always need to be started manually.

This Task Manager CANNOT be started via the “Job Manager”.

Trouble-shooting: The data of a transaction is saved in sequential files that are normally deleted by PDXTSK and newly generated with the new data. If errors or unexplained changes occur in a revaluation, the deletion of the legacy sequential files can be prevented by setting a switch in the dngpara.ini file.

In section [Debug], the entry “RenameSaveDataFiles=YES” is to be inserted. As a result, the files will not be deleted but renamed by adding a time stamp.
If no debug is to take place, then the entire entry must be deleted.

Transactions, which are being run via the PDXTSK, can be traced by starting the PDXTSK in the foreground and activating the wanted debug switches. The PDXTSK will pass its own debug switches as commandline parameters to the transactions which have been initiated by the PDXTSK.

Task Manager
Services
Recalculation