3. Defining Attributes

A product represents a specific service offered by your bank. For example, a certain type of account sweep, a specific type of periodic collection, etc. can be roughly termed a product. Once a product has been defined with specific attributes, individual instructions can be processed under it. This enables quick and uniform processing of instructions in all the branches of your bank.

While attributes defined for a product are applied on an instruction processed under it by default, some of them can be modified for a particular instruction. Oracle FLEXCUBE thus offers you flexibility to deal with peculiar conditions that may sometimes be applicable.

Standing Instructions are broadly grouped as follows:

These are termed product types in Oracle FLEXCUBE. For each product type, you may have many products, which represent the method in which instructions have to be processed. The product type identifies the most basic nature of a product. The subsequent specifications for a product will be based on its type.

This chapter contains the following sections:

3.1 Product Creation

This section contains the following topics:

3.1.1 Invoking the Standing Instruction Product Definition Screen

In this chapter, we shall discuss the manner in which you can define attributes specific to a Standing Instruction (SI) product.

You can create an SI product in the ‘Standing Instruction Product Definition’ screen invoked from the Application Browser. You can invoke this screen by typing ‘SIDPRMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

In this screen, you can enter basic information relating to a SI product such as the Product Code, the Description, etc.

For any product you create in Oracle FLEXCUBE, you can define generic attributes, such as branch, currency, and customer restrictions, interest details, tax details, etc., by clicking on the appropriate icon in the horizontal array of icons in this screen. For an SI product, in addition to these generic attributes, you can specifically define other attributes. These attributes are discussed in detail in this chapter.

You can define the attributes specific to an SI product in the SI Product Definition Main screen and the SI Product Preferences screen. In these screens, you can specify the product type and set the product preferences respectively.

For further information on the generic attributes that you can define for a product, please refer the following Oracle FLEXCUBE User Manuals under Modularity:

Product Code

You need to identify a standing instruction product that you are creating with a unique Product Code. This code should be unique across all the modules of Oracle FLEXCUBE. This code should be different from the Instruction Code that is given

Instruction Code

You should give the product another unique code that will be used to generate the Instruction Reference Number. This code should be different from the Product Code that will be used, to generate the contract reference number for each cycle of the instruction.

Product Group

Grouping products, according to the common features they share, helps you organize information relating to the services you provide. Product Groups also help you retrieve information easily.

You can invoke a list of the product groups that you have maintained in your bank and choose the product group to which the product that you are creating belongs.

3.1.2 Defining the Product Type

The product type identifies the most basic nature of a product. The remaining attributes that you define for a product will depend on its product type. A product that you are defining can have one of the following types:

3.1.3 Preferences Button

Preferences are the options that are available to you for defining the attributes of a product. The options you choose, ultimately, shape the product. Some of the attributes defined as preferences can be changed when an instruction is processed under the product.

Click ‘Preferences’ button to invoke the SI Product ‘Preferences’ screen.

Note

Not all product preferences are allowed to be amended, after the product has been author­ized once. So care needs to be taken before authorization of the product to ensure that the product attributes (preferences) have been maintained correctly.

3.1.3.1 Indicating the Processing Type

Only while creating a payment type (payment or variable payment) or sweep type (sweep in or sweep out) of product you have to specify the stage of end of cycle processing when an instruction under the product has to be processed. The following options are available:

When an instruction is processed under a product, with processing time as BOD or EOD, the accounting entries will be passed either during the beginning of day or end of day, on the due date.

If the processing type is EOD (end of day), the instruction will be executed when the automatic processes for the SI module is run after End of Transaction Input has been marked for the day

If the processing type is Intraday, then you need to manually sweep-in, sweep-out or range-balance the instructions created under this product. Use ‘Standing Instruction Intraday Processing/Reversal’ (SIDINDPR) screen to process manual intraday sweep.

For details on intraday sweep process, refer to the section ‘Intraday Sweep Process’ in this user manual.

Note

Intraday processing is applicable only to sweep-out, sweep-in and range-balancing sweep type of products. The system will not allow you to select ‘Intraday’ for any other type of SI product. The system displays an error message if you try to select ‘Intraday’ as the Pro­cessing Type for other product types.

3.1.3.2 Specifying SI Cycle

The SI cycle defines the frequency at which the instruction is to be executed. This can be defined in days, months or years. For example, you can choose to define a payment order on a daily basis, or every 60 days or 150 days, or a payment every three months or six months. You can also define a payment that is annual or every two years.

Rate Type

You have to specify the Rate Type that should be used for SI transactions. Click on the option list for a display of all the Rate Types maintained through the Rate Type Definition screen.

Holiday Exception Code

You should define the action that is to be taken if the due date falls on a calendar holiday. Since SI’s are processed at regular intervals, often it may happen that a due date for an instruction will be a holiday. In such a case, you can:

If the due date is brought backward or pushed forward, the value date of the accounting entry for the instruction will be the working day on which it was processed.

Minimum Sweep Amount

This applies for a sweep in and sweep out type of product. You should define the minimum amount that is to be transferred in an account sweep.

If the amount in the Sweep From account is more than the defined SI amount but the sweep amount is less than the minimum sweep amount, then the sweep will not be executed.

Action Code Amount

The SI is processed on its due date and the necessary transaction is effected, if the debit account has sufficient balance. An SI will not be processed if there are insufficient funds in the account to be debited. In such a case, the Action Code specified for the product will decide the action to be taken. It could be:

Action Code Description
Partial Liqui­dation The system will first attempt an SUXS. If SUXS fails due to insufficient funds (Available Balance < SI Amount) in the account, the SI will be exe­cuted to the extent of the funds available. This is known as partial execu­tion. The event ‘PEXC’ is triggered during a partial liquidation/execution. The rest of the amount will be collected during subsequent retries, subject to the ‘Maximum Retries’ defined for the instruction. The system will attempt SUXS only once during the day (first time). If it fails, only PEXC will be attempted on every subsequent retry. Therefore, if between the SUXS and PEXC events, the available balance increases to cater to the full SI, the PEXC event ONLY will be triggered. This means that the entire SI amount may be posted for the PEXC event as well. Thus, an SI can have many PEXC events (as many re-tries) for a cycle, whereas SUXS event will be triggered only once for a cycle. However, the event ‘PEXC’ is triggered only if the ‘Action Code’ is speci­fied as ‘Partial Liquidation’.
Full pending The SI is not executed until there are sufficient funds in the account. The system will re-execute the instruction daily, for the number of times defined as ‘Maximum Retries’. If the debit account is not funded suffi­ciently, then the system will fire the ‘REJT’ event during the first try as well as on the subsequent retries. In this case, only an ‘SUXS’ is triggered subject to the availability of funds to the extent of the SI amount. The event ‘PEXC’ will not be triggered even if partial funds are available in the account.
Ignore The current installment is not executed at all and system will fire the REJT event. The next cycle will be processed on the next due date based on the availability of funds.
Await fur­ther instruc­tions The instruction is not processed again until its action code is changed in the Instructions Due Table. The SI Cycle Details table is automatically created when the automatic processing of SIs for the day takes place (for details on this, please refer the chapter on Automatic Processing). For an instruction, you can change the action code in this table so that you may process an unsuccessful SI.
Force In this case, the instruction is executed even though the debit account has inadequate funds. This results in a negative balance in the, debit account.

For example, you have a payment order to pay USD 6000 as annual premium to an insurance company for a customer. This amount is to be transferred from her savings account on the 01 June every year. If the account balance in her account is only USD 5000, when the insurance payment is due, the SI cannot be processed, as funds are insufficient. The processing of the instruction will depend on the action code, as follows:

Action Code Description
Partial liq­uidation In this case, you would transfer USD 5000 to the insurance company.
Full pend­ing Then you would not make any insurance payment for this year. The system will re-execute the instruction daily, for the number of times defined as Max­imum retries count.
Ignore The payment to the company will not be made this year, but the next pay­ment will be processed based on the availability of funds.
Await fur­ther instruc­tions Future insurance payments for the customer will not be made until a change in the Action Code is indicated in the Instructions Due table.
Force The payment will be made, leaving a debit balance in the account.

Maximum Retry Count

The action code for a product indicates the action to be taken, when the account to be debited for an instruction does not have the requisite balance. One of the actions could be for the full amount to be kept pending and the instruction re-executed daily. However, you can fix the maximum number of times the SI should be re-executed. This number is defined as the maximum retry count. The SI for the current cycle will be skipped after this number has been reached. This number will also include the first time the system tries to execute the instruction. That is, if the maximum retry count is five, the system will try to re-execute the SI after the first try, for four times.

SI Type

The number of accounts involved in an instruction may be more than one. Typically, you would debit one customer account and credit another to execute an instruction. All the examples we have discussed so belong to this category. Under some circumstances, you may have to debit a single account and credit many accounts or vice versa. In Oracle FLEXCUBE, you have to specify this by defining the appropriate SI type for the product. The options available are:

Action Code Description
One to one One account has to be debited and one credited.
One to many One account has to be debited and more than one credited.
Many to one More than one account has to be debited and one account credited.
Many to Many More than one account has to be debited and more than one account cred­ited.

Retry Count for Advice

The system generates failure advice for Standing Instructions of Payment type with Action Code as ‘Full Pending’. Retry Count for Advice captures number of retries for failure advice generation. Retry Count for Advice should be less than Maximum Retry Count.

Execution Periodicity

You should indicate the periodicity with which the standing instruction has to be executed. You can indicate it in in days, months, years or as a combination of all three.

You can define execution periodicity for Sweep In/Sweep Out type of instructions also.

A customer can pay the insurance premium on a monthly basis, a quarterly basis or on an annual basis. This can be defined in three ways as given in the following example:

Note

For Sweep IN/Sweep OUT/Range Balancing products, the Holiday Exception will be Lapse and the Execution Periodicity is one day. If any other value is specified in these fields then the system displays the following override messages and the value gets reas­signed back to lapse with periodicity being one day.

Execution Frequency for Intraday

Multiple Executions Allowed

Check this box to allow execution of intraday instruction multiple times during an SI period.

If you check this box for a product, the instructions created under the product can be executed multiple times during the SI period. For example, if the execution periodicity for an Intra-day sweep-out instruction is one day, then the instruction can be executed more than once in a day.

The next execution value date and due date are not updated during online execution of such instructions. Instead, these values will be updated as part of an SI batch during BOD operations on the next execution date. The next execution date of the instruction is derived using the formula ‘Last execution date + Frequency’.

If you do not check ‘Multiple Execution Allowed’ check-box, then the instructions created under this product can be executed only once during the SI period. For example, if the execution periodicity for an Intraday sweep out instruction is one day, then the instruction can be executed only once a day. The next execution value date and due date of the instruction are updated during its online execution, based on the periodicity.

Note

Transfer Type

For contracts associated with the product you need to indicate whether the payment details need to be structured or whether the details can be in free format.

The format in which payment messages will be sent for all contracts involved in the product will depend on your specification in this field.

Referral Required

Referral refers to the process of handling customer transactions which force the accounts involved in such a transaction to exceed the overdraft limit. Standing Instructions are examples of typical transactions, which can force an account to move into overdraft. While maintaining the details of an SI product you can indicate whether transactions involving the product need to be considered for referral checks. Enabling this option indicates that transactions within the product need to be considered for referral.

If a product is marked for referral, the details of transactions resulting in the account (involved in the transaction) moving into Overdraft will be sent to the Referral Queue.

Note

For further details on Referrals refer to the Processing Referrals in Oracle FLEXCUBE chapter of the Core Entities manual.

Authorization Re-key

All operations on an instruction (input, modification, etc.) have to be authorized:

If the ‘Rekey Required’ check box is checked, you have to select either Rekey of Amount or Rekey of Currency or both in the product level.

While authorizing the standing instruction, system asks for the reinput of the selected Rekey fields, Authorizer has to input these values. System validates these values against the original values specified by the maker. If it matches, the instruction will be authorized otherwise the system displays the error message “Rekeyed contract amount/currency is wrong”.

If no re-key fields have been defined, the details of the instruction will be authorized immediately once the authorizer clicks the authorize button in Standing Instruction Contract Authorization screen. The re-key option also serves as a means of ensuring the accuracy of inputs.

Duplication Recognition

You can specify the following details related to duplication check for transactions. The duplication check is carried out based on the combination of the preferences maintained at the SI product level.

Product Code

Check this box to indicate that the product code needs to be considered while checking for duplicate transactions.

Cr Account

Check this box to indicate that the Cr account needs to be considered while checking for duplicate transactions.

SI Currency

Check this box to indicate that the SI currency needs to be considered while checking for duplicate transactions.

SI Amount

Check this box to indicate that the SI amount needs to be considered while checking for duplicate transactions.

Book Date

Check this box to indicate that the booking date needs to be considered while checking for duplicate transactions.

First Execution Value Date

Check this box to indicate that the value date of the first execution of the Standing Instruction needs to be considered while checking for duplicate transactions.

Execution Periodicity

Check this box to indicate that the periodicity of the Standing Instruction needs to be considered while checking for duplicate transactions.

The check for duplicate transactions is carried out based on the duplication check days maintained at Branch Parameter level. An override message gets displayed if any duplicate transaction is encountered.

Note

If none of the above checkboxes are selected, duplication check will not be performed, even if duplication check details have been specified at branch parameter level.

For more details on the duplication check preferences maintained at branch level, refer the section titled ‘Maintaining Duplication Check Details’ in Core Services user manual.