A basic set for liability types is defined in the DOKA-NG standard. They are described in detail in the liability concept of the application documentation.
In order to be able to handle the liability, the module LIAALL must be present in the transaction. The booking of the amounts and other settings take place in the method “LiaallSetTransaction” within the transaction.
In this document it is described, how additional liability types are defined or how existing liability types can be modified.
The following paragraphs describe the definitions to make it possible to use an liability type.
The name of the liability type is triple-digit alphabetically. At first, this name has to be specified and subsequently it will be decided, if must be cumulative entries or individual positions. At the same time it should already be defined, which book-ins and book-outs should take place in what transaction under specific conditions or if the new type is a variant of an existing booking type.
At first, the booking types for the new types have to be made known in the contract balance system (CBS), the following steps have to be carried out:
Module | Function | Necessary Changes |
---|---|---|
TRNISM | ACTgetsql | Define/check account type defaulting for LIACAT. which is possibly outsourced into an own function (e.g. “GetGILiaCattyp”). |
TRNISM | GetLiaActtyp | Define account type defaulting for client account type. |
LIAGET | TrnmodGetUsanceCbtpfxLst | If individual positions for maturities are used, this entry has to be add to the list. |
TRNISM | IsCbtRelevantForLia | If it is not an internal booking, the new entry has to be added to the list, that outputs TRUE. |
LETMOD | GetCnfTyp | If it is a new variant of the confirmation types in LE, the contract status of the contract to be used must be requested and the new value has to be set, if necessary. |
LETP0 | default CNFTXT | Has to be adapted, if it is a new variant of the liability types for the contingent liabilities in LE and therefore can affect the text. |
LIAALL | GetConfirmationCbtLst | If it is a new variant of the confirmation types, the new value has to be added to the list. |
LIAALLG | HasOldAccountToBeValid | This function can be used to determine, if the function, that an automatic rebooking takes place, when the account is meanwhile invalid, is active. In DOKA the function is enabled for LC and silent confirmation liabilities (AVL and AVS). Here it has to be decided for the new liability type (if necessary). |
xxTMOD | GetAllowedTypes | If it is a new variant of the confirmation types, it has to be added to the Old calculation. 'xx' represents the areas, in which the new type has to be used. |
xxTMOD | GetAllowedTypes | If there are new individual positions, the possible alternatives have to be defined depending on the contract status. 'xx' represents the areas, in which the new individual positions have to be used. |
In those transactions, in which bookings are to be made on the new liability type, respective calls of “LiaallSetCbeAmount” in “LiaallSetTransaction” have to be added, if there are completely new individual positions.
If there are added individual positions, “LiaallSetTransaction” has to be changed accordingly in those transactions, where the type has to be booked. At first, the conditions have to be defined, if the old or the new type has to be used. This has to be considered consequently in all transactions.
If the call LIAALL.StoreAll does not already exist in the CBS save option CBSSAV, it has to be added there, so that the liability modifications are also saved when saving.