The fixed fields, that are usually used are::
The fields in brackets have a fixed name for a specific meaning denotation, but are not necessarily used in every sector. Furthermore, amounts and roles of the contract are defined in xxDGRP.
A detailed description of the standard fields can be found in Field Naming Conventions.
The Contract Status Control handles the status of the contracts in more detail. The usage of certain generic status-relevant fields shall be clarified here.
There are three date fields in a contract describing the status of a contract
CREDAT is the date at which the contract has been created technically and at which it was stored under its reference.
If this field has been set, the contract has been legally opened and can be used for business transactions. This date is logically independent from CREDAT. Depending on the sector, the OPNDAT can either be before (e.g. if the L/C was opened by a foreign bank) or after the CREDAT (e.g. if the L/C has been reserved).
If this field is set, the L/C is closed and might no longer be used for transaction processing of business transactions. Only fee settlement, common messages and re-activation are possible with contracts, in which the CLSDAT is set.
This block contains the field identifications of the fields, that have been changed manually in the contract or by receiving an incoming message. When loading the contract, these fields are automatically set to status 'Modified-2', so that the the request 'ismodified' TuRE and the re-defaulting will be avoided, also in subsequent transactions.
To keep track of the transactions which modify contract data, an additional table to organize the transaction order is established. This TRO table describes the dependencies between transactions. The table contains the following information:
This information can be used to inform the user on entry of a transaction about not released modifications of the database.
If a contract-modifying business transaction will be rejected or repaired, the other transactions, which depend on the modified data, will be rolled back automatically, as they are based on already modified data. These transactions are found by searching the TRO chain backwards and rolling them back as well.
On release, the system checks, if the PRVTRN of a transaction has already been committed (SRVCOM). Only in this case, a release (SRVPDS) of the transaction is possible. Thus, the release of the transactions has to be in the correct sequence.
Control & Release automatically shows the releasing user such transactions, whereupon a selected transaction is waiting for and suggests these kind of transactions for release (TRNP shows the dependency).
The central contract in a business transaction is the contract that is mainly be concerned. Thus, the subcontract is the central contract in a document set, even if is is just being created in the current transaction. The central contract is entered in MTABUT\REC, SETMOD\RECGRP and LIAALL\GRP.
Further contracts are all parent contracts involved and maybe loans (BP/TR).
In every business transaction all involved contracts have to be registered in Init (order 950). The following functions are used for this purpose:
| Function | Description |
|---|---|
| TRoReadExistingContract | Reads the available data when calling the contract. |
| TroLockExistingorNewContract | Checks the existence of a contract when calling a contract |
| TroLockExistingContract | Function like “TroLockExistingorNewContract.” However, this function is used, if only available contracts may be used. |
| TroLockContractForCBSOnly | When starting a transaction it checks the existence of a contract and reserves it only for saving of CBS entries. Saving the contract (xxD and xxT) is not allowed, as it is not locked in TRO. |
It is not allowed to directly read a contract with “getxxxgrp” or similar, as in this case, for example, the infotexts would not be displayed.
At first, the central contract is registered and then the high-level parent contracts. Another sequence can be used for transactions that can create subcontracts, using the special loading function TroLock“<parent>andNewOrExisting<child>”.
SETMOD and LIAALL automatically know all contracts registered with “TroLock” functions. If further contracts are to be processed in the settlement or in the liability function, they have explicitly to be registered for these modules. The best way in doing so is to directly register the additional contracts in the Init, as modified data can only be saved for registered contracts.
A main contract is a contract that can, for example, be loaded via a business transaction selection transaction (xxxSEL) (e.g. an LE contract). Several subcontracts can be assigned to one main contract (see subcontract). A main contract contains all relevant data, diaries, and parties of a business transaction. Main contracts can be created in each business sector that is available in a DOKA price list module.
A subcontract is a contract that is subordinated to a main contract and is depending on it. Thus, subcontracts can only be for an available main contract. Example: In an export letter of credit (LE) a BE contract (document set under ab export letter of credit) is a subcontract of an export L/C contract (LE contract).
In a business transaction a central contract is the contract that is mainly concerned. Thus, in document sets the central contract is the subcontract, even it is just being created in the current transaction. The central contract is always available under “\”MTABUT\REC. The following line can be used to query the business sector code of the central contract of a transaction:
$Bus = mid( RecGetObj( "\"MTABUT\REC ), 1, 2 )
Compared to an associated BE contract, an LE contract is the parent contract, i.e. the LE contract is superordinated to the BE contract. A parent contract again can be assigned to a high-level parent contract.
Example: A transfer letter of credit (LT contract) is the parent to a document set under a transfer (BT contract). The LT contract again can be subordinated to an export letter of credit (LE contract); i.e. the LE contract is the parent contract of the LT contract. Document set contracts (e.g. BE, BT, BR, etc.) must have a parent contract. An export letter of credit (LE contract) can also have an import letter of credit (LI contract) as a parent contract (quite rare: Back-To-Back-Letter of Credit).
A passed contract is an external contract, that has been passed to the business transaction. Then, the business transaction loads this contract and processes its data.
BUS is the marketing/price list module that is assigned to a business transaction. BUS is used to determine a DOKA transaction belonging to a business sector. In a business sector with subcontracts this field is set to the main contract, even in transactions, which handle the subcontract. The field is left empty in case of non-business sector transactions. So BUS is the superordinate business sector code.
Example: A contract is passed via incoming message to the transaction“Receiving Documents” (LITDCK). In this case BUS = LI for BR transactions, as a BR (import document set) is to be created.
LNKOBJ is the contract type that can be passed to this transaction.
This field is used to identify the table ID that is used by the current contract. Normally, the contracts of this type are passed to a transaction. In common business transactions this code should equal the prefix of the \MTABUT\REC instance. Subcontract-creating transactions are an exception. Optionally, the main contract or the subcontract can be passed to this transactions.
However, in the example mentioned above this is LI for an BR-creating contract, although this transaction creates a BR and contains BRDGRP as MTABUT\REC.
At the beginning of each transaction in \SYSMOD\ATP the ATP entry for the transaction just being processed will automatically be loaded, so that the own data and switch settings can be queried immediately.