This is the streamline process of adding an entity, This article will demonstrate how to utilize it. the system will prompt options for users to select as to what to do next.
The Entity Details screen allows you to identify and manage all general details that are related to an entity. From the entity screen, users can add:
- Fee Condition
- Opening Hours
- Routing Information
- Past Due Settings
The Entity Details screen allows you to input and review the following information:
|Entity||Externally used descriptive key to identify an entity. This key has to be unique. The field is used in all tables specific to the entity to associate these entries to the entity.|
|Entity Group||This field holds the external key to identify an entity group.|
|Entity Address||The external key is used to uniquely identify an entity address. The key may consist of both letters and digits and is usually the unique ID under which an entity address is identified.|
|Entity Name||This field indicates descriptive name of the entity.|
|Name||This is the visible name of an entity group.
This name is used in selection lists and on panels used to identify an entity group.
|Own Party||External key used to identify a party as unique.|
|Bic of Entity||This BIC is used when sending SWIFT messages from different entities.
The length of this BIC is 12 digits instead of the normal 11,
because this BIC must include the Logical Terminal Code as the 9th digit.
The terminal code identifies a specific terminal connection within a destination.
It consists of one alphanumeric character ("0" and "1" are not permitted).
|TID of Entity||This TID is used when sending TradeConnect messages from different entities.|
|AllNETT/RIVO Entity /Dept||This field contains the allNETT Entity that is linked to the DOKA Entity, on
Incoming and Outgoing allNETT messages.
|AllNETT/RIVO Entity /Dept Check box 2||allNETT Department
This field contains the allNETT Department that is linked to the Doka Entity, on Incoming and Outgoing allNETT messages.
1. Implement as customer branch code
2. Implement as DOKA entity id
3. Implement as DOKA entity BIC code
|Clearing Number||The bank's own clearing ID used in payment messages using the SIC clearing system.
This is a field specific for the customer.
|User Group f.Routing||This default user group is used to route incoming messages
within this entity, if no other group can be determined.
|Applicant.Administrator||This is the technical short name used to identify a user within an installation.
This user ID might be different to the user ID used to login to the application server,
depending on the login mechanism used and the environment.
|TimeZone||The time zone for this entity. All time stamps relevant for the user are converted to this
time zone in displays. In the database, time stamps are stored in system time.
The time zone is only used, if the Time Zone system is also used.
|Default Language||The language code defines the language to be used of language dependent output
where the language is not defined by user or correspondent/document.
Used e.g. for language of 'File Copy' Header.
|Default calendar||Default Calendar for the Entity
This optional field specifies an entity-specific calender to be used for date calculations
based on working days such as in 'date' fields, or on internal functions where
no calendar is specified.
|Postflix for XSI-File||Postfix for entityspecific XSI-Files
To allow a different XSI-file for a different ETY create a XSI-file eg. "A4xxx.XSI",
where xxx is written in this field for the respective entity.
An empty field or a not available XSI-file will result in the use of
the default value of the document (eg. A4.XSI).
|Color for Charts||This field controls the color in which the entries assigned to the user
are displayed in the Dashboard charts.
|Hub Entity for Routing||This denotes the Hub/Parent entity for this specific entity. The user could select the
Hub/Parent from the selection criteria. Entities which are defined as 'Hub'
will be available for selection.
This field will be disabled for entities which are already defined as
'Hub' (Hub checkbox enabled). Also, if no specific routing logic exists for an entity,
it's Hub/Parent entity's routing will be it's default routing.
|Default Icon for Entity||Default Icon for Entity
If set, this icon is automatically used instead of the default icon.
The icon file used is specified relative to the frame partition.
|Logo File used in Letters||Logo File Used in Letterhead
The field identifies the file to be used to show the logo
in the letterhead in correspondence.
Any Bank charges set under Static data>Fee/Interest and on adding the Maintaining Fees/Fee conditions the provided fee conditions can be viewed under the Entity Panel.
The Added Fee/Fee conditions can viewed here for the respective entity.
On the Opening hours panel, the usual office hours for each weekday can be defined for the entity group selected. If the fields Time from and Time until are filled for specific days, then the difference in hours is automatically calculated. For weekdays on which the entity group is closed, the checkbox Closed must be checked.
To set the conditional specification on incoming message Without Associated Contract.
The admin User can set the Routing Information under the entity Panel as shown below
Past Due Settings
In a loan contract, if the customer fails to make the payment on/before the Maturity date, it becomes Past Due. Past due bills normally incur late fees and charges with a higher rate of interest. Financial contract becoming past due/over due will invariably affect the credit rating of the customer/borrower as payment activity usually accounts for largest portion of a credit scoring methodology.
Depending on the policies of the banks, some might immediately report a past due contract as delinquent and start charging late fees. Whereas, some banks might still provide a grace period, within which a loan can be repaid without any late fees, thereby not impacting the customer's credit rating.
Therefore, it is absolutely necessary for some of the banks to monitor the past dues, minimize the risk by categorizing past due stages and charging late fees.
Once a loan becomes past due, reclassification of the same becomes important, not only from regulatory requirement perspective but also to mitigate the risk of loan becoming delinquent. Reclassification is defined by the ageing of the loan contract. DOKA-SAAS handles reclassification from transactions Maintaining Entities and Maintaining Entity group Past due status of a loan contract is defined when it crosses the defined number of days in these setup.
Currently past due functionality is enabled only for the Loan module and is not yet available for the Advance module.
Past due stages can be defined separately for each type of loan or as a whole for all types of loans. Also, it can be set to be applicable at each entity level or also at group level. If a local/individual setup exists, it takes precedence over the group/whole level.
More details on the reclassification stages/status:
Grace Days: This is a set length of time after the due date, during which payment maybe made without any late fee. This is to provide an opportunity to the customer to make the payment before the loan classifies into its further stages. Note, this is an optional stage and if required, bank could skip this stage.
Past Due Days: This is the stage at which the contract technically becomes overdue/past due. From this day the 'Late fee/Penalty' will be charged to the customer and the normal commission accrual will be stopped. However, the calculation period for the Late fee/Penalty will start from the actual maturity date. Example: Loan maturity is 01.November and loan becomes overdue. If Grace period is defined as 1 day, the customer could repay the loan within 02.November without any late fee. However, failing so, the late fee calculation will start from 01.November. This stage is handled through Past due loan
Non Performance Days: After the loan becomes overdue/past due for a certain number of days, it becomes doubtful to be recovered and therefore reclassified as 'Non Performing'. Reclassification implies that the liability type becomes different. This is done through Liability adjustment transaction. Also, from this stage, the Late fee accrual calculation is stopped and any outstanding fee/commission is set to pool. This is also an optional stage. If the bank decides, it could skip this stage.
Write Off Days: After the defined days in Non Performance stage, if the loan is still past due, the bank could decide to write off/cancel the loan. This is done through closing transaction. This is the last stage and hence does not require any particular range of days.
Interest Capitalized: When a loan contract becomes past due, user could decide to add the existing outstanding interest/commission to the outstanding principle amount. This is enabled by selecting the Interest Capitalized checkbox in the parameter setup. However, the user could deselect the same at contract level.