CBE - CBS Entry

This table holds all CBS booking entries. These booking entries store
all amount modifications within the contracts managed by the
application.
The booking entries are associated to a relevant object, usually a
real contract or a pseudo contract (like PTE).
Depending on the type of entry as described by the field CBT and
the external ID of field EXTID, the balances stored in the table CBB
are updated with each new entry, according to the CBS
configuration stored in CBSCONF.INI with a starting validity as
defined in the field DAT.

/

INR

Unique internal ID of a record within the table. The INR is a text field, which is created by retrieving the next valid entry from the counter CBE. The field INR is used to maintain links from other tables into this table.

Unique internal ID of a record within the table. The INR is a text field, which is created by retrieving the next valid entry from the counter of this table. The field INR is used to enable links from other tables to this table.

For contractdata the INR also links the two tables xxD and xxT as associated entries hold the same INR.

This field holds the table ID of the table of the associated object. The relevant object type may be: LID, BRD, PTE etc., i.e. the type of the contract (business sector) or the type of a pseudo contract like PTE or other object from which this entry has been originated.

This field holds the table ID of the table of the associated object.

This field holds the INR of the object entry. The associated table is identified by the field OBJTYP.

This field holds the identification number (INR) of the object entry. The associated table is identified by the Object Type field.

To be able to store multiple amounts of the same type per contract this additional field is available. The CBS subsystem always keeps track of balances per used external ID. Thus using different external IDs within a contract creates different balances. This is for example used in L/C contracts to differentiate the base amount and additional amount.

This additional field is available to be able to store multiple amounts of the same type per contract. The Contract Balance Sheet subsystem always keeps track of balances through the external ID used. Thus, using different external IDs within a contract creates different balances. This is used in L/C contracts,for example, to differentiate between the base amount and additional amount.

This type of entry defines via the CBS configuration, which columns are affected by this booking entry and whether the value shall be added to or substracted from the balance of the column.

This type of entry defines, via the Committed Balance Sheet configuration, which columns are affected by this booking entry and whether the value is to be added to or substracted from the balance of the column.

This field holds the table ID of the transaction, which created this entry. This field is currently fixed 'TRN'.

This field holds the table ID of the transaction which created this entry.

This field holds the INR of the creating transaction.

This field holds the identification number (INR) of the creating transaction.

This is the relevant date of this entry.

This is the relevant date of this entry.

This is the currency of the booked amount. Depending on the circumstances which currency is allowed it is usually fixed to one currency per contract, type of entry and external ID. In order to be able to enter bookings with a different currency, it is necessary to reduce all relevant balances to zero and then book with the new currency.

This is the currency of the amount stored in the relevant column in the Contract Balance Sheet table.

This is the booking amount of this booking entry. The relevant currency is the currency of CUR.

This field holds the booking amount of the entry.

The three possible values are in the following logical sequence.

1. preliminary 2. entered 3. released (= commited)

The status released is applied by a call of the routine CbsReleaseTrn, which switches all entered entries to released. This routine is typically called in the SRVCOM which commits a transaction.

The field indicates the status of the relevant entry in the CBS table. The three possible values are in the following logical sequence. 1. preliminary 2. entered 3. released.

This is the date when the booking entry has been created. This might be a different date than the value date of field DAT.

This date field identifies the date the entry was physically added to the database.

The application might keep track of the counter value of all amounts in another (usually the system) currency. If the counter value is stored, the currency of this converted amount is stored in this field. If the XRFCUR field is not set by the application the CBS system will defaultwise fill the field with the System currency setup.

The application can keep track of the counter value of all amounts in another (usually the system) currency. If the counter value is stored, the currency of this converted amount is stored in this field.

If counter values are stored, the converted amount is stored here. The associated currency is stored in the field XRFCUR. If the XRFAMT field is not set by the application the CBS system will defaultwise fill the field with the converted amount of the amount as of AMT. The exchange rate used is the middle rate as of the value date (DAT) of the entry.

If counter values are stored, the converted amount is stored here. The associated currency is stored in the Currency field for converted amounts.

This is the longtext booking description which might be passed by the application to identify the booking entry. This field has no technical relevance for the CBS subsystem.

This is the long text description for the booking entry.

This optional account number field might be used to store the account number used in the corresponding GL accounting entry. This information might be used when closing a balance to use the same account number as on creating the entry.

This optional account number field might be used to store the account number used in the corresponding general ledger entry. This information might be used when closing a balance to use the same account number as on creating the entry.

This optional counter account number field might be used to store the account number used in the corresponding GL accounting entry as counter account. This information might be used when closing a balance to use the same counter account number as on creating the entry.

This optional counter account number field might be used to store the account number used in the corresponding general ledger entry as counter account. This information might be used when closing a balance to use the same counter account number as on creating the entry.

This additional, optional date field might be used for different purposes. One intended usage is to be able to store the different tenor dates on amounts split between multiple tenors. For liability inbooking entries this field is used as expiry date of the liability. This date is used to fill the field MATDAT of a created LSM entry.

This additional, optional date field might be used for different purposes. One intended usage is to be able to store the different tenor dates on amounts split between multiple tenors.

To be able to get balances where a reconciliation with the General Ledger is possible the date when the originating transaction is passed to the GL might be stored here. Not used in dok5, only used in customer overlay. 'Use valdat instead of GLEDAT, as GLEDAT is not set.'

To be able to retrieve balances where reconciliation with the general ledger is possible, the date when the original transaction was passed to the general ledger can be stored here.