This table holds one entry of every entry for which an accruing could
take place.
Name | Description | Data Type | Len | Dec. | View lines | View type | Inst. | Visible | Codetable |
---|---|---|---|---|---|---|---|---|---|
INR | Internal Unique ID | Text | 8 | 1 | Edit | Yes | Public | ||
OBJTYP | Contract Type | Text | 6 | 1 | Edit | Yes | Public | ||
OBJINR | INR of Contract | Text | 8 | 1 | Edit | Yes | Public | ||
DAT1 | Date 1 | Date | 12 | 0 | Date | Yes | Public | ||
DAT2 | Date 2 | Date | 12 | 0 | Date | Yes | Public | ||
PTYINR | INR of Party Paying | Text | 8 | 1 | Edit | Yes | Public | ||
CRETRNINR | Transaction Creating Entry (Modification Date on Modifications) | Text | 8 | 1 | Edit | Yes | Public | ||
CREDAT | Date of Creation | Date | 12 | 0 | Date | Yes | Public | ||
ACRDAT | Date of Last Accruing | Date | 12 | 0 | Date | Yes | Public | ||
SETTYP | Type of Settlement | Text | 1 | 1 | Edit | Yes | Public | Embedded | |
FECINR | INR of Condition Used | Text | 8 | 1 | Edit | Yes | Public | ||
FEEINR | INR of Fee Used | Text | 8 | 1 | Edit | Yes | Public | ||
ACC | Account | Text | 34 | 1 | Edit | Yes | Public | ||
ACCACR | Accruing Account | Text | 34 | 1 | Edit | Yes | Public | ||
CUR | Currency | Text | 3 | 1 | Edit | Yes | Public | CURTXT | |
DIFAMT | Difference between ACTAMT and Last Booking | Numeric | 18 | 3 | Edit | Yes | Public | ||
ACTAMT | Actual Accrued Amount | Numeric | 18 | 3 | Edit | Yes | Public | ||
VER | Version Counter | Text | 4 | 1 | Edit | Yes | Public | ||
ETYEXTKEY | Entity holding Transaction | Text | 8 | 1 | Edit | Yes | Public |
Name | Fields | Properties |
---|---|---|
ACR_INR | INR | Unique |
ACR_OBJIDX | OBJTYP, OBJINR | |
ACR_PTYINR | PTYINR |
/
INR
The INR is used to uniquely identify a database entry within a 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.
Type of contract the entry is associated to. Usually “PTE” as commissions are fees associated to liability entries.
The type of contract for the relevant entry. This is usually “PTE” as commissions are fees associated with liability entries.
INR to identify the object the entry is operating on. The table to be used is identified by OBJTYP.
The identification number (INR) used to identify the object the entry is working on. The table to be used is identified by the object type.
Begin date from which the fee is to be settled/accrued. Usually start date of contract.
Starting date for the fee to be settled/accrued. This usually corresponds to the starting date of the contract.
Date until the fee has to be accrued. Usually the end date of contract. CAUTION: Like in FEP DAT2 is the last date to be settled for, not like ENDDAT in other tables the first date following that date.
End date for the accrual of the fee. This usually corresponds to the end date of contract.
This INR identifies the party paying this fee.
This identification number (INR) identifies the party paying this fee.
INR of the transaction which created this accruing entry, i.e. a transaction, which is first settling the fee for that contract.
The internal unique ID (INR) of the transaction that created this accrual entry, i.e. a transaction, which first settles the fee for this contract.
Date when this entry was created (Date of transaction CRETRNINR).
This date field identifies the date the entry was physically added to the database.
Date of last accruing.
Date of last accrual.
The type of settlement is taken from the fee conditions used and describes the point in time when the fee is settled.
The type of settlement is taken from the fee conditions used and describes the point in time when the fee is settled.
Code | Text |
---|---|
A | in Advance |
E | at the end |
Pointer identifying the related FEC entry.
This field contains the identification number (INR) of the condition for the used fee.
Pointer identifying the related FEE entry.
This field contains the identification number (INR) of the fee used.
Account from FEE\ACC the accruing debits.
Usually an interim account credited in transaction and debited in accruing.
The accruing creates one transfer booking for all entries with same ACC and ACCACR and currency.
An account for accrued debits.
This is usually an interim account credited in the transaction and debited to accruals.
Account from FEE\ACCACR the accruing debits.
The final profit account for the fee credited in accruing.
The accruing creates one transfer booking for all entries with same ACC and ACCACR and currency.
Account for accrued debits.
The revenue account for fees credited in accruals.
The accrual creates one transfer booking for all entries with same Account, Accruals Account and currency.
Currency of fee necessary to group entries in accruing.
Currency of the fee necessary to group accrual entries.
If counter values are stored, the converted amount is stored here. The associated currency is stored in the field XRFCUR.
If counter values are stored, the converted amount is stored here. The associated currency is stored in the Currency of Converted Amount field.
This field hold the amount actual accrued.
This field holds the actual accrued amount.
This table is defined on entity level with separate entries for each entity. This field holds the EXTKEY of the owning entity to identify the logical owner of this entry. This field is filled automatically during insert and is used as filter when accessing the database. Without special implementation only entries of the currently active entity are visible to the user.
This field holds the external key of the owning entity to identify the logical owner of this entry.
This field is filled automatically during insert and is used as filter when accessing the database. Without special implementation only entries of the currently active entity are visible to the user.
This field holds the version counter to keep track of the version history of an ACR entry. The individual versions are controlled by entries in the SLG table.
This field holds the version counter used to keep track of the history of an entry of this table. The individual versions are managed by entries in the SLG table.