User Tools
Add this page to your book 
Remove this page from your book 
Manage book (
Help Table of Contents
Limit System
Basic Concept
The Limit system is setup to provide a limit per object and the utilization of that limit amount by the different connected contracts and transactions.
The idea of the limit system is to be completely independent of the contracts and the using application.
In DOKA on the application level the liability connected to the different contracts is maintained in the liability system, which is technically implemented in the different LIA modules of DOKA.
To make sure the balances of the contracts and the balances within the limit system always match, the limit system is integrated into DOKA as part of the CBS functions. The rule “IsCbeRelevantForLimit” is used to determine for every CBS booking whether this booking is relevant for the limit system and in case it is relevant, the limit system is called to handle the relevant limits.
This central place where the “IsCbeRelevantForLimit” rule is called is the place where other external limit systems might be plugged in.
To be able to be independent of the owning application the limit system maintains own set of structural entries in multiple table to keep track of the logical linkage of the contracts, transactions, nodes etc.
Each contract is typically linked to multiple limit nodes providing the possibility to maintain multiple independent limits and combined utilizations of those limits.
As all changes to the limit system are issued by a CBS booking, the limit system referres to the originating CBE for more detailed reference.
In the original design of the limit system the limit node amounts are not kept as CBS amounts. Therefore the timewise development of the limit utilization is not directly available in that design.
To provide a better base for the utilization changes there has been a upgrade to use CBS to store the balances of LSA and LSC introduced with the exposure screen implemented within SCF-PRO.
Activation /Deactivation
- To activate/deactivate the limit handling, the rule “IsCbeRelevantForLimit” has to be adjusted. In general, it depends on the type of liability entry, if the CBE entry is relevant or not. If rule returns “FALSE”, the passed CBE entry is not relevant, so no limit handling will take place. If the rule returns “TRUE”, the passed CBE entry is relevant, so calculation of limit will be done.
- Limit system can be activated/deactivated centrally using checkbox 'Deactivate Limitsystem' from the transaction 'Maintaining System Configuration (DBISYS) . When this checkbox is set, the limit system for all business sectors as well as corresponding services in the Task Manager (MGRTSK) such as 'Limit Check (PDL)' are deactivated.
Used database table
| Table | Description | More detailed remarks |
|---|---|---|
| LSB | Limit node with limit and settings of the limit | Maintained in the masterfile maintenance of the limit system. |
| LSA | Amounts and balances of the limit utilization | Linked 1:1 to a LSB entry. Separated to the LSB table to be able to delete the dynamic data (= utilizations) by just deleting this table. |
| LSC | Balances per limit node and using currency | Linked to each pair of using currency and limit node. This additional entry provides a fast access to the sum of the utilizations per currency and avoides the need to walk through all utilizations when the limit utilization has to be calculated based on a updated exchange rate. |
| LSR | Limit requestor, which acts like a contract owning the limit utilizations | The limit requestor is automatically created per contract and limit type. |
| LSM | Limit modification below a limit requestor | Acts like a transaction which utilizes or releases the utilization of a limit node. |
| LSL | Link of using contractual object to the used limit node | The links to the limit node to be used are established when creating a new limit requestor in a rule which typically searches for limit nodes connected in a fixed hierarchy of keys. In the standard this is a limit per country, per currency, per headquarter of the relevant party and per party. |
| LSS | Signatur entry to register one of multiple possible signatures necessary to accept a limit utilization | Whenever a limit utilization requires a confirmation the assozated LSM is marked as not confirmed and each approval is registered as LSS entry with the respective approver. When the necessary approval is provided and the last LSS of a LSM gets confirmed the LSM itself gets confirmed and the checking service checking for the required approvals will get completed and allows the dependend services to execute. |
| LSE | Earmarking to keep track of temporary transfer of unused limit amounts between nodes |
Used Module
The logic to maintain and handle the limit utilization is available in the module LSCMOD which provides the access to the limit system interface and the logic used by the application intern limit system.
The limit system interface is the layer to integrate a potential interface to an external limit system.
Used Transactions
| Transaction | Description |
|---|---|
| DBxLSB | Maintaining Limits |
| CONLIM | Limit Approval for Contracts |
| REOLSB | Reorganizing Limits |
| INFLSM | Info Limit Modification |
