Constraint

The Type field indicates the constraint type. The options allowed are:

• DATE - Indicates a date prior to which back dating is restricted.
• FINANCIAL.YEAR - When this option is chosen, any activity prior to the last year end date is restricted. The last date of the previous financial year is determined by the value stored in the Last Year End field of the COMPANY table pertaining to the arrangement. The financial year frequency is defined in the Financial Year End field.
• INTEREST.PERIOD - Activity is restricted and governed by the Interest period of the arrangement. For example, to restrict any activity past the billing period, this option is used.
  • Interest period check is done only for interest properties defined in the payment schedule conditions. If there are multiple interest properties defined in the payment schedule, then the latest interest ending period is considered as the allowed date.
  • In case of retail accounts, if Debit and Credit interest are defined in the schedule and capitalisation date is on different frequencies, then the latest interest ending period is checked for restricting backdated activity.
• PERIOD - The user can state a specific period (e.g, 1M, 6M, etc.) to indicate specific periods before which the activity is restricted. The system calculates the allowed date based on the period defined and validates the effective date of the backdated activity.
• RENEWAL - When this option is chosen, any activity prior to the last renewal date is restricted. When an arrangement is set to change product or reset or rollover, then the last renewal date gets updated in AA.ACCOUNT.DETAILS. If the backdated activity is prior to this date, then it can be restricted.
• STATEMENT.PERIOD - Constraint is based on when the statement was last generated for this account. If multiple statements are generated (including special ones), then the latest statement date is taken and any date prior to that gets restricted.

The Period field indicates the actual period of constraint and allows the user to enter a valid numerical value or a period allowed based on the option selected in the Type field. The options are:

• If Type is STATEMENT.PERIOD, DATE, FINANCIAL.YEAR, or RENEWAL, then no input is allowed in this field.
• If Type is INTEREST.PERIOD, then a numeric value is allowed in this field (for example, no backdating prior to three interest periods). If nothing is stated, system allows any backdating prior to current interest period by default.
• If Type is PERIOD, then a valid IN2PERIOD value should be stated in this field. The field is mandatory with this option.
• If Type is NULL, then the Period field cannot be updated.

The Date field indicates a hard date prior to which backdating is restricted. The field may be used when the user wants to restrict backdating from a specific date. This field is allowed only if DATE option is selected in the Type field.

The Detail field indicates further details to support the value selected from the Type field. This is to be used only when the Type field has the value INTEREST.PERIOD.

If INTEREST.PERIOD is selected, then a valid Interest property with associated billing consideration needs to be stated here. If the Property Type is set as Accrue by Bills for Penalty Interest Property, then the interest property is not allowed in the Detail field.

The Function field indicates the type of activity function for which the constraint restrictions need to be applied. This field is not allowed for input if the Type field in the corresponding multivalue set is NULL. The options available for this field are:

• INPUT- The restrictions are applied only if current activity is Input of new transaction.
• REVERSE - The restrictions are applied only if current activity is reversal of an authorized transaction.
• NULL- The restrictions are applied to any activity irrespective of action.

The Result field indicates the outcome of the restriction. This field is mandatory only when the Type field is chosen. The options are:

• ERROR - Any violation of constraint results in an error and stops the activity.
• OVERRIDE - Any violation of constraint results in override and requires approval to proceed with the activity. The override could be converted to an error if need be in OVERRIDE application.

The Error Message field is used to differentiate one error from other when the different options are chosen from the Type field. If the option selected from the Result field is Error, then a user defined EB.ERROR may be stated in theError Message field. If no message is stated, a default generic error message from AA.CONSTRAINT.VIOLATED is used.

The Override Message field is used to differentiate one error from other when the different options are chosen from the Type field. If the option selected from the Result field is Override, then a user defined override message may be stated here. If no message is stated, a default generic override message from AA.CONSTRAINT.VIOLATED is used.

• A personal loan arrangement is created, which has the constraint property restricting the back dating activity based on period.
• The constraint period is changed to 3D and Result is given as Override. The effective date is 27 March 2013. A user could do a back dated activity 3 days prior to this date. If it goes beyond 3 days, then an override message is displayed.
• As the activity is triggered prior to 5 days of the effective date, the system triggers the override message for breaking the restricted backdated activity of 3 days.

Scenario 1: Multiple Constraints with Override

Two different overrides (pertaining to two different constraint types) that are displayed by the system, when a back value dated activity (new arrangement activity in this case) is being attempted by the user, are given below.

Current Date: 17 Apr 2017

Arrangement Effective Date: 28 Dec 2016

Financial Year End (for the related Company record in Company table): 31 Dec 2016

• The first override displayed pertains to the constraint type – ‘Period’ (90D or 90 days). The number of days between the above mentioned current date (17 Apr 2017) and the activity effective date (28 Dec 2016) is 110 days which is over and above the 90 days constraint that is set. The below override is displayed to the user:
  NOTE: Activity should not be backdated past the ‘PERIOD’ constraint.

• The second override displayed pertains to the constraint type – ‘Financial Year’ (Current Financial Year, since Period field is left blank). The below override is displayed to the user:
  NOTE: Activity should not be backdated past the ‘FINANCIAL.YEAR’ constraint.

Scenario 2a: Multiple Constraints with Error

Consider that the two constraints as mentioned in Scenario 1 are configured with the Result ‘Error’.

When the user tries to create a new arrangement, the system displays the most restrictive constraint that is the period constraint of 90 days when the Effective date is entered as 17 Apr 2016. The below error is displayed to the user:

NOTE: Effective Date cannot be backdate activity due to ‘PERIOD’ constraint.

Scenario 2b: Multiple Constraints with Error

Consider the Period constraint = 180 days and the two constraints as mentioned in Scenario 1 are configured with the Result ‘Error’.

The more restrictive of the two constraints in this case is the ‘Financial Year’ constraint and hence the system displays the related error message. The below error is displayed to the user:

NOTE: Effective Date cannot be backdate activity due to ‘FINANCIAL.YEAR’ constraint.