The word ‘product’ is frequently used in the Oracle Lending user manuals. A ‘product’ is a specific service that is offered.
This chapter contains the following sections:
The attributes that you define for a product apply on all contracts that are processed under the product. By creating a product, you construct a broad framework within which you can process contracts. This helps to minimize the details you have to capture when processing a contract.
This section contains the following topics:
In the Product Definition screen of every module, you can enter basic information about a product such as the Product Code, the Description, and so on. The Product Definition screens of the various modules of Oracle Lending are invoked from the Application Browser.
You can invoke the ‘Loans and Commitment Product Definition’ screen by typing ‘OLDPRMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
Note
Product Definition screen is specific to a module. To create an LD product, for an instance, invoke the ‘Loans and Commitment Product Definition’ screen from the Application Browser. Similarly, to create an LS product, invoke the LS Product Definition screen from the Application Browser.
In a Product Definition screen, you should specify the following details for the products you create:
A ‘Product Code’ identifies a product throughout Oracle Lending. This code should be four characters in length.
When defining a new product, you should enter a code that is unique across the different modules of Oracle Lending. For instance, if you have used LC01 for a product in the Loans and Commitment module, you cannot use it as a product code in any other module.
It may be difficult to recognize a product just by its code. In the ‘Description’ field, therefore, suitably describe the product code so that it can be easily identified. This description is displayed along with the code throughout Oracle Lending.
Product categories are referred to as ‘Product Types.’ When you create a product, you must specify the type to which it belongs. For an instance, you should specify the product type as ‘Loan’ if you are defining a lending product and ‘Commitment’ if you are defining a Funds Transfer product.
Products can be categorized into groups based on the common elements that they share. You must associate a product with a group. This would facilitate retrieval of information of a class of products at one stroke.
Product Groups are maintained in the ‘Product Group Maintenance’ screen, You can invoke the ‘Product Group Maintenance’ screen by typing ‘OLDPRGRT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
You can enter a marketing slogan line for every product you create. This slogan is printed on all advices that are sent to customers who avail of the product.
For example, if you set up a Loans product , you can enter the slogan ‘Loans On Demand.’
A product can be defined to be active over a specific period. When you create a product, you can specify a ‘Product Start Date’ and ‘Product End Date’ for it. The product can only be used within the specified period.That is, within the ‘Product Start Date’ and ‘Product End Date’.
If you do not specify the ‘Product Start Date’, the branch date is displayed as the ‘Product Start Date’.
If you do not specify an ‘Product End Date’ for a product, it can be used for an indefinite period.
When creating a product, you can enter information about the product intended for your bank’s internal reference. This information is not to be printed on any correspondence with the customer.
Once you have specified the basic details of a product, you can define the other attributes for it. From the ‘Loans and Commitment Product Definition’ main screen, you can move to the screen of your choice to define an attribute by clicking on the appropriate icon.
The other product attributes that you can define include:
Discount accrual, Accrual fee details, Diary events for a product. The product attributes that you can define depends on the module in which you are creating the product. For instance, the attributes that you define for a product in the Oracle Lending (OL) module vary significantly from the product attributes that you define in the Funds Transfer module. For products you create in the
OL module, you can define, interest, clause, and document details, whereas, these attributes cannot apply to products you create in the Funds Transfer module.
Note
There are some fields in the product definition screens in which a value must be entered. If you try to save a product without entering details in these fields, the product is not saved. You are prompted to enter all mandatory details before attempting to save the product.
For more information on fields and tabs, refer to Bilateral Loans User Manual.
In Oracle Lending, the interest that applies on a contract (say, a loan) is referred to as the interest component of the contract. Calculating the interest component for a contract is achieved by:
For more information about interest, refer to the Interest User Manual.
Click ‘Interest’ in the ‘Loans and Commitment Product Definition’ screen to invoke the ‘Interest’ screen. In this screen, you can associate the product you are creating with an Interest Rule. The attributes defined for the interest rule or class that you link to a product default to all contracts processed under the product.
Note
For products created in certain modules of Oracle Lending, you may have to specify additional interest details. These details have to be specified in the Product Preferences screen of the module. For more information about Products, refer to the respective Products User Manuals.
On the transactions and contracts you enter in Oracle Lending, you may opt to levy charges . You can calculate charges for a contract in the following manner:
You can identify the charge component for a product in the ‘ Charges Definition’ screen. Click ‘Charges’ from the ‘Loans and Commitment Product Definition’ screen to invoke this screen.
The steps involved in processing charges for a contract, that is, defining charge rules, defining charge classes, associating charge classes with a product, and amending charge details to suit a contract are explained in the Charge and Fees User Manual.
In Oracle Lending, you can compute the tax that applies on a contract or deal by:
You can identify the tax components for a product in the ‘Tax Details’ screen. Click ‘Tax’ in the ‘Loans and Commitment Product Definition’ screen of any module to invoke this screen.
The steps involved in processing tax for a contract is explained in the Tax User Manual.
In Oracle Lending, you have the option to collect and accrue a certain amount as fee, upfront at the time of booking a contract. These are the steps involved in processing contracts in Oracle Lending, for which the fee components need to be accrued:
After defining a fee component, you need to link the fee component to a product in Oracle Lending. Consequently, you can collect and accrue fees on all contracts associated with that product.
Click ‘Fees’ in the ‘Loans and Commitment Product Definition’ screen of the (for which the fee accrual functionality is applicable) to invoke the ’Fee Details’ screen to link the fee components to a product.
For details relating to upfront fee collection, refer the Processing Upfront Fee Collection and Accruals section in the relevant modules.
For more information about fee component, refer to the Charges and Fees User Manual.
This section contains the following topics:
In Oracle Lending, accounting-simplistically, posting accounting entries to the appropriate ledgers maintained in your Chart of Accounts-is automated. This is achieved by defining an intricate accounting structure that includes the Chart of Accounts, Transaction Codes and Amount Tags, and by identifying accounting roles, heads, and amount tags for the products you create at your bank. As a result, the accounting entries that are generated at the various events in the life cycle of contracts are automatically posted to the ledgers specified for the product.
Before we proceed with setting up accounting details for a product, we shall discuss a few terms that are frequently used in this section.
Accounting Head
In Oracle Lending, the different General Ledgers (GLs) and Sub-Ledgers (SLs) maintained in your Chart of Accounts are referred to as accounting heads, or, account heads.
GL Types
The GL/SLs that you have maintained in your bank can be categorized into different GL Types: Asset, Liability, Income, Expense, Contingent Asset, Contingent Liability, Position GL, Position Equivalent GL, and so on. When maintaining a GL in the Chart of Accounts, you have to identify its type.
Amount Tag
A contract would typically consist of several components. For instance, a loan contract would consist of the principal, interest, charges, tax, and so on. These amounts are referred to as the “components” of a loan contract. In Oracle Lending, a unique tag called the Amount Tag identifies each component.
Accounting Roles
Accounting Roles are tags that identify the type of accounting entry that is posted to an accounting head. For instance, in the Oracle Lending (OL) module, assume you have specified the following interest for an OL product, to be collected when issuing OLs processed under the product: INTERST1 and INTERST2. The following Accounting Roles are automatically generated in Oracle Lending to identify all possible types of accounting entries involving these interest components:
INTEREST 1 |
INTEREST 2 |
Type of Accounting Entry |
INTERST1INC |
INTERST2INC |
Income |
INTERST1EXP |
INTERST2EXP |
Expense |
INTERST1PAY |
INTERST2PAY |
Payable |
INTERST1REC |
INTERST2REC |
Receivable |
INTERST1RIA |
INTERST2RIA |
Received in Advance |
INTERST1PIA |
INTERST2PIA |
Paid in Advance |
Similarly, based on your accounting set up in a module, accounting roles are automatically generated for the other components of a contract.
You can maintain the accounting details for a product in two screens:
Before you define the accounting details for a product, you should define the various components of the contracts involving the product such as interest, charges, tax, and so on.
In the ‘Accounting Roles’ screen, a list of accounting roles are automatically generated based on the components you define for the product. You should map all the accounting roles that are available with the appropriate accounting heads.
You can invoke the ‘Accounting Roles’ screen by clicking ‘Accounting Roles’ in the ‘Loans and Commitment Product Definition’ screen.
Adopting either of the following procedures, you can specify the accounting roles and heads for a product:
Click Default From Class’ in the ‘Accounting Roles’ screen to associate the product you are maintaining with a class of mapped roles and heads. A list of the classes that you have defined specifically for the module is displayed. Choose a class with the requisite accounting heads and roles mapped.
You can select and modify the required role to head mapping details to suit the product you are defining. You can also define new role to head mapping by clicking the ‘+’ button.
The procedure for setting up an Accounting Roles to Head Mapping classes is similar to mapping accounting roles and accounting heads specifically for a product.
Mapping Accounting Roles to Heads specifically for a product
If you do not use a class to define accounting role and heads for a product, in this screen, you can define them specifically for the product you are creating.
Map Type
The mapping between an accounting role and account head can be of the following types:
Accounting Role and Description
Accounting role is used to denote the accounting function of a GL or Account. To map an accounting role to an account head, select a valid accounting role from the option list provided. This list displays the roles available for the module.
Once you choose the accounting role, the description maintained for the role is also displayed in the adjacent field. If you do not want to select a role from the option list, you can also create an accounting role for a product and specify a brief description for the same.
Account Head and Description
The account head identifies the GL or Account to which the accounting entries would be posted. Based on the type of accounting role you select (Asset, Liability so on.), the list of Account Heads (General Ledger heads) that are of the same type as that of the accounting role, becomes available in the option list provided. You can select an accounting head from this list and thus, create a role to head mapping. On selection of the Account Head, the description is also displayed in the adjacent field.
Click ‘Add’ icon to create subsequent mappings for the product. If you want to delete a role to head mapping, click ‘Delete’ icon.
Rule
If the ‘Map Type’ is ‘User Defined’, you can create a case-result rule structure based on which the entries are posted to the appropriate account head. To create a rule, click ‘Rule’ in the ‘Roles’ section of the product screen.
You can define multiple conditions and for each condition you can specify the resultant ‘Account Head’. This way you can maintain one to many mappings between an accounting role and an account head. Depending on the condition that is evaluated favourably, the corresponding account head is used for posting the entries.
To define condition you can use SDEs or UDF fields. SDEs are selected from the LOV where as UDF fields have to be manually defined using the prefix UDF@
For example, UDF@RESIDENT=’YES’.
To build a condition, click ‘Condition’ in the ‘Role Mapping’ screen. The ‘Condition Builder’ is displayed.You can build the conditions using the elements (SDEs), operators and logical operators available in the screen above.
For details on building a condition using the options available in the screen, refer ‘Defining Events and Accounting Details specifically for a Product’ section.
Note
The system ensures that all accounting roles that are applicable for the product and which have been used in the definition of the accounting entries are necessarily linked to an account head. If the mapping is not complete, an error message is displayed when you attempt to save the product.Specifying Events and Accounting Entries
A contract goes through different stages in its life cycle. In Oracle Lending, the different stages a contract passes through in its life cycle are referred to as “events”.
At an event, typically, if you want to post the accounting entries to the appropriate account heads and generate the required advices. When setting up a product, you can define the accounting entries that have to be posted and the advices that have to be generated at the various events in the life cycle of contracts involving the product. To do this, click ‘Events’ in the ‘Loans and Commitment Product Definition’ screen.
The ‘Events’ screen is displayed.
You can define the accounting entries and advices for events using either of the following methods:
You can invoke the ‘Reversal Type Maintenance’ screen by typing ‘OLDREVTP‘ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
In this screen to capture the list of allowed transaction types for the product in case of a reversal.
After you invoke this screen, you can associate new transaction codes for each transaction type. During reversal of events, the system replaces the old transaction codes with the corresponding (new) transaction codes. In case no new transaction codes are associated for the old transaction code, the entries are passed with the old transaction code.
Click ‘Default From Class’ in this screen to associate the product you are maintaining with an Events class. A list of the Events classes that you have defined specifically for the module is displayed. Choose a class with the requisite events and accounting details maintained. The product acquires the accounting entries and advices defined for the Events class you choose.
The procedure for setting up an Events class is similar to defining events and accounting details for a product.
If you do not use an events class, you should define event details specifically for the product.
Click ‘Add row’ to invoke a list of events pertaining to the module. Select an event from the list by double-clicking on it.
For every event you select, you should specify the accounting entries that should be passed and the advices that should be generated.
Click ‘Accounting Entries’ in the ‘Events’ screen to specify the accounting applicable to the event.
You can define the accounting entries based on the set of rules.
SDEs are used to define rules while creating the product. When the product is created, the rules and the accounting entries for the respective rules are also saved.
During the life cycle of a loan when an event occurs, the system does the following:
Rule No
Every rule/condition you define for a product should be assigned a unique number. The rule number can consist of a maximum of 5 digits.
Condition
You can either enter the condition here or using condition builder. If you use condition builder, the condition gets defaulted here.
Condition Builder
You can define conditions for rule using ‘Condition Builder’
Fields
You can select the SDEs from the adjoining option list. The system displays list of SDEs maintained.
Condition
The system displays the final condition that is defined.
Mathematical Operations
You can select the mathematical operations like + , - , *, \ from the drop-down list.
Operator
You can select the logical operators from the drop-down list.
Value
You can enter the value.
Using ‘And’, ‘Or’, ‘Accept’ button you build the condition. After selecting ‘Fields’, ‘Operator’ and ‘Value’ the condition gets build in the ‘Condition’ field.
For an each event, you have to maintain the following accounting entries information.
Specifying the Accounting Role
Specify the accounting role that should be used at the event. The drop-down list displays all the accounting roles specified for the product in the Accounting Role Definition screen.
Specifying the Amount Tag
Specify the tag, which identifies the component that has to be posted to the account head.
Indicating a debit or credit
Indicate whether the accounting role you specified is for the debit or credit leg of the contract event.
Indicating the Transaction Code
Every accounting entry in Oracle Lending is associated with a Transaction Code that describes the nature of the entry. Specify the transaction code that should be used to post the accounting entry to the account head.
Indicating if accounting entries can be netted
Specify whether accounting entries should be netted at an event. You can net the accounting entries that are generated at an event if the set of entries satisfy the following criteria:
If you want a particular leg of an accounting entry to be considered for netting (subject to the above criteria), select ‘Yes’ from the drop-down list in the Netting field against this leg.
You should define details for both the legs of an accounting entry. For each accounting entry, you should specify the details of the debit and the credit leg. Thus, the first two specifications are for one entry, the next two for another, and so on. The Transaction Code for the entry should be specified for both legs of the entries.
This netting of accounting entries is only for processing and not for message generation.
Netting outgoing payment instructions
You can net multiple entries posted into the same account for processing. Independent of this, you can net entries posted into the same account with a view to sending out netted payment instruction messages.
If you want a particular leg of an accounting entry to be considered for netting for messaging purpose, select ‘Yes’ from the drop-down list in the Msg Netting field against this leg.
For sending out payment instructions, the system identifies the netted amount based on entries in the Msg Netting field, and not based on entries in the Netting field. Therefore, you can specify an accounting entry to be considered for Msg Netting and not for Netting.
The validation criteria mentioned for the Netting field is same for the Msg Netting field also.
This section contains the following topics:
From the head office of your bank, you may want to establish certain controls or standardize operations across the branches of your bank. For instance, you may want to restrict the products you offer to select branches and currencies, or allow specific branches to offer products only to a specific set of customers. You can achieve these controls by maintaining restriction lists when creating a product. When you create a product, you can specify the branches of your bank that can offer it, the currencies that are allowed or disallowed for it, and the customers who can avail it.
Note
When you create a product, it is, by default, available to all the branches of your bank, in all currencies, and for all customers.
‘Preferences’ are options that you can choose to give shape to a product. You can specify your preferences for the products you create in the Product Preferences screens of the respective modules. Click ‘Preferences’ in the ‘Loans and Commitment Product Definition’ screen to invoke the Product Preferences screen.
IOF Payment Method
You can either select ‘Advance Payment’, ‘Capitalization’ from the drop-down list. By default, nothing is selected.
If you have selected ‘Advance Payment’ option, then IOF is collected upfront when loan is disbursed.
If you have selected ‘Capitalization’ option, then IOF is capitalized along with the principal amount.
Note
Apply Book Rate for VAMI
If this check box is selected, then contract booking rate it taken instead of VAMI maintained rate.
For more information about Financial Operation Tax, refer to Bilateral Loans User Manual.
If you do not use a class to indicate branch and currency restrictions, you should define these restrictions specifically for the product in the ‘Product Preferences’ screen.
You can indicate whether you are maintaining an allowed or a disallowed list type by choosing the appropriate option. You can select either ‘Allowed’ or Disallowed’ option. These values are defaulted to the ‘Bilateral Loans and Commitment Restrictions’ screen.
If you do not use a class to indicate customer restrictions, you should define these restrictions specifically for the product in the ‘Customer Restrictions’ screen.
Choosing Category Restriction
You can select either ‘Allowed’ or Disallowed’ option. These values are defaulted to the ‘Bilateral Loans and Commitment Restrictions’ screen.
Note
This section contains the following topics:
You can maintain a list of allowed/disallowed branches and currencies in ‘Bilateral Loans and Commitment Restrictions’ screen.
You can invoke the ‘Bilateral Loans and Commitment Restrictions’ screen by typing ‘OLDPRDRS’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
When defining a product, you can choose to specify Branch and Currency, and Customer Restrictions either by:
In Oracle Lending, you can define a set of branch and currency restrictions as a Branch and Currency Restrictions Class. You can maintain several restriction classes of branches and currencies.
When creating a product, you can associate it with a branch and currency restrictions class that best suits your requirement.
The manner of creating a branch and currency restrictions class is similar to defining Branch and Currency Restrictions specifically for a product.
If you want to associate a branch and currency restrictions class to a product, click ‘Default From Class’ in the ‘Bilateral Loans and Commitment Restrictions’ screen. The product acquires the restrictions defined for the class.
Branch List and Currency Restrictions
The ‘Branch List’ and ‘Currency Restrictions’ values are defaulted from the ‘Product Definition’ screen. You are not allowed to modify these values.
Branch and Currency section
You can specify branch and currency restrictions in the form of allowed lists or disallowed lists.
If you have selected ‘Allowed’ in ‘Product Definition’ screen, the product can only be offered in those branches and currencies that are part of the respective allowed lists. On the other hand, if you have selected ‘Disallowed’ lists, the product cannot be offered by the branches and currencies on the respective disallowed lists.
If you choose to maintain an allow/disallow list of branches, the column would display the branches that you opt to allow/disallow respectively.
The branch and currency codes of all the branches and currencies maintained at your bank are displayed. Using the ‘Add Row’ or ‘Delete Row’ buttons, you can modify a branch or currency to the corresponding allowed/disallowed column that you have maintained.
Example
You have a network of twenty branches. You want to exclude six branches from dealing in loans You want all other branches to deal in loans.
Since there are more branches that can offer the facility than those that cannot, you can choose to maintain a disallowed list, and include the six disallowed branches in it.
Confirming your specifications
After you maintain branch and currency restrictions for a product, click ‘Ok’ to confirm your specifications. Click ‘Exit’ to delete your specifications.
You can group your customers according to the common features that they share. For example, you can group your customers into categories such as:
You can maintain customer categories in the Customer Categories screen invoked form the Application Browser.
Maintaining Customer and Category Restrictions for a product
You can maintain customer restrictions for a product in the Product Customer and Category Restrictions sections. Click ‘Customer Restriction’ tab in the ‘Bilateral Loans and Commitment Restrictions’ screen.
Using a Customers and Categories Restrictions Class
In Oracle Lending, you can define a set of customer restrictions as a Customer Restrictions Class. You can maintain several restrictions classes of customer categories.
When creating a product, you can associate it with a customer restrictions class that best suits your requirement. The procedure for creating a customer restrictions class is similar to setting up customer restrictions for a product, as explained below.
If you want to associate a customer restrictions class to a product, click ‘Default From Class’ in the ‘Customer Restrictions’ screen. The product acquires the restrictions defined for the class.
The ‘Category Restriction’ value is defaulted from the ‘Product Definition’ screen. You are not allowed to modify this value.
Specifying the Customer Category
You can restrict customers from availing a product by maintaining an ‘Allowed’ list or a ‘Disallowed’ list of customer categories.
If you have selected ‘Allowed’ in ‘Product Definition’ screen, only customer categories that are a part of an allowed list maintained for a product can avail the product. Likewise, customer categories that are part of a disallowed list cannot avail the product or service.
Exempting specific customers
You can exempt customers, belonging to a particular allowed/disallowed category, from the allowed or disallowed list that you are maintaining for a product.
Example
You have maintained Financial Institutions as a customer category, and you do not want Financial Institutions to avail a service that you offer.
You can maintain a disallowed list in the Customers and Categories Restrictions screen, and include Financial Institutions in the list.
However, you want Cavillieri and Barrett Inc., a financial institution, to avail the product you are creating.
When you include Financial Institutions in your disallowed list, all customers belonging to this category is displayed in the Customer Access column. Move to Cavillieri and Barrett on the list, and specify the Restriction Type as allowed.
Confirming your specifications
After you maintain branch and currency restrictions for a product, click ‘Ok’ to confirm your specifications. Click ‘Exit’ to delete your specifications.
Click ‘MIS’ in the ‘Loans and Commitment Product Definition’ screen to define the MIS details for the product you are creating.
In this screen, you should capture the following MIS details for a product.
You can link a product to an MIS Group. (If you do not want to link a product to an MIS Group, you can define the individual entities under which the product should be reviewed). If you link the product to an MIS Group, the entities defined for the group is displayed; you can change these entities. For a product, only the transaction type of MIS Class applies. The specific MIS entity (in the form of an MIS Code) is picked up, by default, only if you have defined them for the group. If not, you have to indicate the appropriate MIS code for each applicable MIS class.
If an MIS Group is linked, you can indicate whether the linkage with the group should always be maintained. If so, any change done to the MIS Group is automatically be applied to the product. If not, the entities defaulted for the product is continued even if they are changed subsequently for the group.
The details defined for the product is picked up for the contracts processed under it.
The Pool Code to which the product belongs should be defined.
Note
You need to maintain ‘Ref Rate Code’, ‘Fixed Rate Type’, ‘Fixed Rate Code’ in Bilateral Loans Product Definition- MIS’ screen and the same rate codes are defaulted to Loan and Commitment-Contract Input -MIS screen. Based on these rates, ‘Refinance Rate’ will be fetched from the ‘Treasury Floating Rate Maintenance’ screen.
Identifying the Operations MIS Group
While performing revaluation you have apportion the profits between the treasury and the respective Operations department in your bank. This internal apportioning of profits requires an Operations MIS Group to be specified at the product level.
For more information, refer to the MIS and Core Services User Manuals.
Click the ’Fields’ in the ‘Loans and Commitment Product Definition’ screen to invoke the ‘Product User Defined Fields’ screen. From the list of all the fields that you created, you can choose specific fields and make them applicable to the product. Besides, you can also specify the values that should be defaulted for the field.
Fields defined in the ‘Product User Defined Fields’ screen can be made applicable to the products that you create for the front-end modules of Oracle Lending.
The list of fields that you select for a product is applied to all transactions associated with the product. At the product level you need not capture the default value for each UDF that you associate with the product. When a contract is processed under that product, you have to indicate the value of the UDF on a mandatory basis.
Example
Assume that your bank wants to know whether a customer is a Resident or Non-resident before sanctioning a loan. Therefore, you have associated a UDF called Resident/Non-Resident with the Loan scheme – Short Term loans for Individuals. Your selection as follows
Moreover, you have specified that input to this field is mandatory. Since, you are not be able to determine this at the product level, you are allowed to save the product without capturing the default value of this UDF. For transactions processed under this product you are required to capture this information.
For more information, refer to the User Defined Fields User Manual.
After building discount accrual fee classes you can associate the class with loans or bills products. Click ‘Discount Accrual’ in the ‘Loans and Commitment Product Definition’ screen. The ‘Discount Accrual Preference Association’ screen is displayed
To associate discount accrual fee class with a product, click ‘Default From Class’ in the ‘Discount Accrual Preference Association’ screen. Select the appropriate discount accrual fee class from the list of classes.
The attributes defined for the discount accrual fee class defaults to the product. You have the option to modify the attributes defined for the class, to suit the requirement of the product you are creating.
Alternatively, you can choose to define the discount accrual details for the product.
Note
When setting up a product, you should identify all possible status that contracts involving the product would move into. You should also indicate the sequence of status changes for contracts.
For more information about status control of a product, refer to Bilateral Loans User Manual.
After defining a fee component, you need to link the fee component to a product in Oracle Lending. Click ‘Accrual Fee Details’ in the ‘Loans and Commitment Product Definition’ screen.
Click ‘Add Rows’to add fee components. Click ‘Default From Class’ to associate the required fee component with the product. System defaults the parameters of the selected fee component. However, you can change the parameters according to your requirements.
You need to specify the following details:
Accrual Method
Specify the accrual method from the adjoining drop-down list. This list displays the following values:
Basis Amount
Select the basis amount on which the fee component should be calculated from the adjoining drop-down list. This list displays the following values:
Fee Type
Specify the fee type from the adjoining drop-down list. This list displays the following values:
Payment Method
Specify the fee type from the adjoining drop-down list. This list displays the following values:
Allow Method Amendment
Select this box to indicate that the amendment method is allowed for the accrual fee component.
Allow End Date input
Select this box to indicate that the fee component (if applicable for the product involved in the contract) will cease to be associated with a contract on the contract ‘End Date.
CLP Buy Price Diff
Select this box to indicate that the difference between the PAR price (100%) and actual buy price is booked as fee against that component.
In the ‘Diary Event Maintenance’ screen, you can also specify the different diary events that would need to be processed for loan contracts using a product.
You can invoke the ‘Diary Event Maintenance’ screen by typing ‘OLDDIAEV’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
In this screen, select the ‘Event’ of the diary event that you want to associate with the product, in the ‘Event Code’ field.
For more information on fields, refer to Bilateral Loans User Manual.
High value transactions requires multi-level of authorization. The levels of authorizations are defined in the ‘Product Transaction Limits’ screen. You can use the ‘Multi-level Authorization Detailed’ screen for authoring a contract n-1 times. However, final authorization can take place only in the contract screen.
When contract booked with huge amount, the contract must go for multi-level authorization. This can be done through three ways
Product limit can be further divided into 2 as follows
Transaction Limit Authorization:
In this type, you have to maintain only transaction limit and level of authorization in the ‘Product Transaction Limits Maintenance’ (OLDPLMNT) screen. When the transaction amount goes beyond the limit specified, then you have to authorize the transaction in ‘Multilevel Authorization’ screen and final authorization can be done through the transaction screen.
Role Based Authorization:
In this type you have to specify the transaction limit along with role based authorization, such that authorization can be done by the users with the roles mapped, which was specified in ‘Multilevel Authorization’ screen. This can be done in two ways with sequence and without sequence.
User limit can be maintained in three different ways through the ‘User Limits Maintenance’ (OLDUSRLM) screen, This does not move the transaction for multi authorization. The system throws an configurable error when the transaction amount goes beyond the input and authorization limit specified.
User Limits
When user limits option is selected then you can maintain, the user level input and authorization limit which is applicable for all branches.
Limits role:
Limits role option is used to maintain branch specific user and authorization limit, specific role templates can be maintained through the ‘Role Limit Maintenance’ (OLDRLLMT) screen.
No limits:
When no limits option is selected, then input and authorization limit is not used.
This can be used only when the option cumulative and minimum authorization limit specified in the screen ‘Product Transaction Limits Maintenance’ screen. This option helps to authorization the transaction when cumulatively. If minimum authorization limit in ‘Product Transaction Limits Maintenance’ screen is greater than or equal to authorization limit specified at ‘User Limits Maintenance’ screen.
Note
The system throws the validation if the authorization limit is less than the minimum authorization limit specified.
Using 'Product Transaction Limits Maintenance' screen (OLDPLMNT) and 'Multiauth Authorization Details' screen (OLDOVDEF), you can perform the following:
In ‘Product Transaction Limits’ screen, you need to maintain specific combination of fields so that the transactions belonging to this combination can be authorized based on the authorization hierarchy. The specific combination of fields are 'Module', 'Product', 'Limit Currency', 'Customer type' and 'Source Code'.
In ‘Product Transaction Limit Details’ section, you can specify transaction limit and authorization levels based on that authorization hierarchy.
In ‘Authorization Role Mapping’ section, you can define the user roles involved in authorizing the transaction. Role details should be provided for ‘primary rule’. Optionally, an ‘alternate rule’ can also be set up for the combination.
You can invoke the ‘Product Transaction Limits’ screen by typing ‘OLDPLMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
You need to specify the following:
Module
Specify the module for multi-level authorization. The list displays all the modules maintained in the system which require multilevel authorizations.
Product Code
Select the product code from the option list. The list displays all the product codes maintained in the system which require multilevel authorizations.
Limit Currency
Select the limit currency from the option list. The list displays all the limit currency maintained in the system which require multilevel authorizations.
Customer Type
You can select the customer type either as ‘ALL’, ‘Corporate’, ‘Individual’, or ‘Bank Customer’.
Module Description
The module description appears based on the module selected.
Product Description
The product description appears based on the product selected.
Source Code
Specify the source code as 'FLEXCUBE' in case of external system then source code is 'EXTSYS'.
Role Based Authorization
If this check box is selected, then ‘Level 1’, ‘Level 2’, ‘Level 3’, or ‘Level 4’ should be selected.
Follow Sequence
This option is applicable only if role based authorization is selected. When this option is selected, the system allows you to authorize the transaction only in sequence with the roles are specified.
Product Transaction Limit Details section
Transaction Limit
If the transaction is booked in excess of the maintained transaction limit then an appropriate message indicating the levels of authorization appears
Level of Authorization
Indicates the number of users to be involved in the contract authorization.
Cumulative
Select this check box to indicate whether shared authorization to be allowed for a contract’s transaction amount.
Minimum Authorization Limit
This field is applicable only when the 'Cumulative' check box is selected. The amount cannot be greater than the transaction limit. This amount is used to validate authorizer limit while authorizing the contract.
Authorization Role Mapping
Select the role as 'Primary' or 'Alternate'. In case of three level of authorization, you authorize only 2 level.
The other authorization has to be done in the main contract screen.
Authorization Role
This is applicable only role based authorization is selected, you can select either ‘Primary’ or ‘Alternate’.
Level1 to Level4
System allows you to fetch the role maintained in the 'Role Maintenance' (SMDROLDF) screen.
You can invoke the ‘Role Limit Maintenance’ screen by typing ‘OLDRLLMT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
Role ID
Specify the role ID, which has to be mapped in the screen 'User Limits Maintenance' screen.
Role Description
Specify the corresponding description.
Limit currency
Specify the Limit currency which can be fetched in the corresponding LOV.
Input limit
Specify the transaction input limit for role.
Authorization limit
Specify the authorization limit for the role.
You can invoke the ‘User Limits Maintenance’ screen by typing ‘OLDUSRLM’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
User ID
Specify the user id from adjoining LOV for which user limit to be maintained
Limits
Limits are of three types, which is specified below, select one of the following:
Limit Currency
This is applicable only when user limits selected, select the currency from the adjoining LOV.
Maximum Transaction Amount
Specify the maximum transaction amount allowed for the user.
Authorization Limit
Specify the Authorization limit for the user.
Role Details
This is applicable only if limits role option is selected.
Branch
Specify the branch for which limit role is used.
Limit ID
You have to select the limit ID from the corresponding LOV
Limit Currency, Input Limit and Authorization
The system fetches the corresponding limit ID details when limit ID is selected.
Financial centre based holiday treatment is applied to the financial centres in product and contract screens.There is no validation performed by the system for the financial centre list.
In addition to the existing holiday treatment (based on branch holiday and currency holiday), you can apply for holiday treatment based on the financial centre holidays.
One or more financial centres can be added for the holiday treatment. You can go with local and financial centre holiday treatment (working day in all the financial centres), currency and financial centre holiday treatment or both (currency and local) and financial centre holiday treatment (working day in all the financial centres).
The functionality like move forward, move backward, move across month, cascade schedules are applicable to financial centre holiday treatment as well.
These maintenances are applicable for Oracle Lending, Loan Syndication, and Secondary Loan Trading modules.
This section contains the following topics:
You can maintain the list of financial centre in 'Financial Centre Maintenance' screen.You can add new financial centres and edit the existing financial centre details.
You can invoke the ‘Financial Centre Maintenance’ screen by typing ‘OLDFCMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
Financial Centre
Specify three characters financial centre. There is no link between branch and financial centre.
Financial Centre Description
Specify the brief description of financial centre.
You can update the holiday details of each financial centre and year in ‘Financial Centre Holiday Maintenance’ screen. The default calendar is based on the branch parameters.
You can invoke the ‘Financial Centre Holiday Maintenance’ screen by typing ‘OLDFCHOL’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.
In this screen you can change a calendar day from working day to holiday and holiday to working day when the holiday changes based on the local regulations.
These maintenances (Working Day to Holiday and Holiday to Working Day) can be done in Local Holiday Maintenance (STDLOCHL), Currency Holiday Maintenance (STDCCHOL), and Financial Centre Holiday Maintenance (OLDFCHOL) screen. For more information Local Holiday Maintenance and Currency Holiday Maintenance refer to Common Core - Core Entities and Services User Manual.