Payment Schedule

• A Payment Schedule is comprised of one or more payment definitions with conditions such as:
  • Type
  • Method
  • Pay Freq
  • Properties
  • Start
  • End
  • Amount
• Temenos Transact provides a mechanism through AA.PAYMENT.TYPE by which users can define the standard payment types that can be used by a Product.
• Type (specifies payment type) is required for every Payment Schedule definition.
• Method—On designating the Payment Type, the user can specify whether the amount is due (to or from the customer) or capitalised or paid to the customer or specify the actual amount to be maintained.
  • Valid inputs are CAPITALISE, DUE, PAY and MAINTAIN.
• Pay Freq —This attribute indicates the frequency at which the payments are to be made due. The actual payment date moves forward or backward depending on the values in the Date Adjustment and Date Convention attributes.
  • The user can also define a holiday period for the payment with the combination of the following fields:
    • Start Date
    • No of Payments
    • Payment Frequency
  • M 01 31. M = Monthly. 01 = one monthly intervals. 31 = the last day of the month.
  • M 03 31 M = Monthly. 03 = three monthly intervals. 31 = the last day of the month.
  • M 01 10 M=Monthly, 01 = at monthly intervals.10 = 10th of the month.
  • 31 MAR 2006 W, where W= weekly. In this case, the first schedule would fall on 31 March 2006.
  • 31 Mar 2006 BSNSS, where BSNSS = every business day. In this case, the first schedule would fall on 31 March 2006.
  • The frequency is specified as a Temenos Transact recurrence attribute.
  • Input prohibited for a date prior to the system date.
• Properties—Indicates the Property to be given for the Payment Type Property Class.
• Bill Type —The user defines the Sys Bill Type field in AA.BILL.TYPE which decides the type of the bill. The Bill Type can be ACT.CHARGE, COMMISSION, DEF.CHARGE, DISBURSEMENT, EXPECTED, INFO, PAYMENT, PR.CHARGE or TRANCHE.
• Prog %—This field allows the user to specify the progressive percentage with which the system calculated payment amount has to progress on every payment.
  • This is valid only for payment types whose Calc Type field is set to PROGRESSIVE. This requires additional setup as defining the MAKEDUE Activity in the On Activity field and setting RECALCULATE option as PROGRESSIVE.PAYMENT.
• Percentage —This allows the user to specify the percentage that is applied on the outstanding balances and made due.
  • Only the percentage of the amount is issued in the bill and made due. The remaining amount remains on their respective balances and any further calculation is based on this balance.
• In Adv—This field allows the user to specify the number of working days prior to the due date when the bill needs to be produced. When this is not set, by default, the bill is made due on the frequency specified.
• Issue —This field allows the user to indicate whether the system should run ISSUEBILL and MAKEDUE separately or together. If the attribute is set to NO, then both are combined and there is no ISSUEBILL Activity, but only Make Due Action.

  Validations:

  • It is left blank by default, which means ISSUEBILL Activity always runs.
  • If it is set to NO, then In Adv should be set to 0.
• Defer By — This field allows the user to define the deferment period from the original payment. Bill is generated for same value, however deferred for specified number of days before due, pay or capitalise. Bill status is maintained as DEFER for the deferred period.
• Num — When a frequency has been specified, the user can specify either an end date (in End attribute) or number of payments (in Num attribute) to indicate the system when the payments should terminate.
• Amount —There can be two amounts for each payment definition: Calculated Amount and Actual Amount.
  • The user can enter the actual amount to override the calculated amount or manual payments. When ad hoc payments are defined, the user has to define the actual amount for each payment date.
  • This is part of a multi-value set of attributes with Start, End and Num.

A Minimum Payment Amount is primarily required in the US financial market for Lines of Credit to define a minimum repayment amount. When such a line of credit is backed by a mortgage, then it is called as Home Equity Lines of Credit (HELOC).

• AA supports to capture a Minimum Payment Amount based on Bill Type. This gives the flexibility for the users to group Properties by bill type and assign a minimum payment amount for them.
• If the calculated payment amount for the given bill type is less than the minimum payment amount, then the bill would be raised of the minimum payment amount. The difference is billed as principal (ACCOUNT Property).
• This is allowed only for scheduled payments not for Activity based charges or break rule charges.
• Minimum payment amount calculation is considered during Payment Schedule projections and simulations.
• There are two attributes required for indicating a minimum amount for an arrangement.
• The bill type for which the minimum amount has to be applied with the Type attribute.
• The minimum bill amount with the Amount attribute.
• On the scheduled payment date, when a bill is raised for the bill type mentioned in Type, the system evaluates the calculated payment amount against the minimum amount specified.
• If the calculated amount is greater than or equal to the minimum amount, then calculated amount is billed
• If the calculated amount is less than the minimum amount, then the minimum amount is billed. The differential amount is billed as ACCOUNT (Property).

The Property attribute is part of the Minimum Payment set of attributes to capture the Minimum Invoice Component (MIC). This is mutually exclusive with Amount attribute. Bill Type wise MIC can be defined using the Group Bill type and Group Min Property set of attributes for Fixed Equal Repayment (FEP) type of contracts to define the MIC.

For Products that have constant payments, the user may want to fix the payment amount for a period regardless of any changes to the arrangement (for example, principal increase, interest rate change, and so on). In such cases, the user can specify a payment using Recalc Frequency attribute so that the constant amount can be recalculated periodically to take into consideration any of these changes.

• The user must specify the recalculation if that should be performed on certain Activities (changes of payment components) that occur on the arrangement. These activities are input into the On Activity attribute.
• The following Activity Classes may require a recalculation:
  • Change – Charge
  • Change – Interest
  • Change – Payment Schedule
  • Change Term – Term Amount
  • Increase – Term Amount
  • Decrease – Term Amount
• For each component specified on the Payment Schedule, the resulting Action must be specified in Recalculate attribute. The recalculation types are:
  • Payment – Indicates that the payment amount is changed.
  • Term – Indicates that the arrangement term is altered.
  • Residual – Indicates that the residual amount is changed.
  • Nothing – Indicates that the payments, term, and residual are unchanged. In this case, a recalculation frequency has to be specified.
  • Progressive Payment - The payment amount is incremented and decremented from the CALC.AMOUNT based on the percentage mentioned in the Prog Pay Perc field.
  • Maturity then Payment - For a product that is set to cap the maturity date at a maximum term, when the term is recalculated based on the current annuity amount and it breaches the cap, the system caps the maturity date to the maximum term and recalculates the annuity amount.

When the user performs an activity such as prepayment or disbursement or change in the interest and so on, on an arrangement with forward dated conditions, the system can be configured to recalculate the ‘Term’ or ‘Payment’ or ‘Maturity then payment’ using the Recalculate field of the payment schedule condition.

Read Working with Scheduling Payments to know more on how recalculation is processed in arrangements with forward dated conditions.

Combine Bills attribute – When two payment types have the same payment date and are produced on the same date, it can be combined. When two payment types have the same payment date but different payment method say DUE or CAPITALISE, then the bills are not combined.

Include All Payments attribute allows the user to specify if the Principal Payments (additional principal payments) need to be considered when deriving the constant payment amounts.

• If set to Yes along with CONSTANT (annuity) and other payment types which has user defined amounts for principal payments, then the system arrives at a CONSTANT amount such that it includes all these ad hoc payments and then arrives at a Calc Amount.
• If it is left blank, the Calc Amount does not consider these ad hoc user defined amounts in its calculation.

The Include Future Disb attribute is used to indicate if future disbursements scheduled must be considered for calculating the constant installment amount. This is applicable for CONSTANT or LINEAR payment type. The Include All Payments and Include Future Disb attributes are mutually exclusive.

This attribute allows the user to specify if the future scheduled disbursements need to be considered for deriving at the projected payment amount.

• No - Recalculates the payment amount based on the disbursed amount and this is the default option
• Yes - Recalculates one payment amount from the start date until the maturity date of the contract by considering the total commitment of the loan on the arrangement date.
• Progressive - Recalculates the payment amount by considering the disbursed and the future disbursement on the arrangement date. The projection changes in the payment schedule is progressive

Repay from Credit Balance attribute is used to specify the Activity to be triggered for adjusting the credit balance.

If a specific amount needs to be collected on the final schedule date, it can be specified by entering a value in Amortisation Term attribute with which Transact can calculate payments and any residual or by entering the amount directly against Residual Amount. This amount is:

• Exclusive of any scheduled calculated amount on the payment schedule.
• Always associated with the ACCOUNT property.
• Recorded in bills under a special Residual Principal payment type.
• Automatically made due on the payment end date.

The Residual Amount always supersedes the Residual Percentage. If the Residual Percentage is specified and Residual Amount is left blank, then the system calculates the amount based on the defined percentage and considers the default value for Residual Amount.

• In the Payment Schedule Property, the user can define the required accounting and consolidated entries.
• The Consolidate Class and Consolidate Property attributes can be used to define Interest Property Classes and Properties that can be used in the process. Consolidation only happens for bills that have matching payment dates, payment methods (Pay, Due or Capitalise) as well as matching defer dates.
• When specified, all bill properties of this Property Class are consolidated into the Property which has the largest overall contribution.
• Consolidation only happens for bills having matching payment dates, payment methods (PAY or DUE or CAPITALISE) as well as matching defer dates.
• Must be a valid Property Class. Currently only INTEREST Property Class is supported.

It is used in connection with CONSOLIDATE.CLASS to limit the properties selected for consolidation to the ones specified here.

• At least the following two properties must be specified.
• It must belong to the Property Class specified in CONSOLIDATE.CLASS.
• It must have a schedule defined.
• If a property selected for consolidation has tax attached, then tax netting for this property must also be enabled.
• Optional sub-value field.

Any change in the scheduled payment amount between the issue bill date and payment date is effective only from the next payment date. However, the issued bill can be modified using flexible repayment definition.

The Finalise Bills attribute defines the period until which an issued bill can be modified. It can be defined only when Bill Produced is defined. This has to be less than the Bill Produced.

Scenario: Assume the following conditions on a loan.

The system issues the bills, five working days (5D) before the payment date and finalises the bills two working days(2D) before. The bill amount can be modified until finalisation.

For each payment that is due from a customer, Temenos Transact creates a bill record and optionally a bill notice. The bill contains the details of the amounts due, the due date, and so on. This bill record is also the basis of the AA Overdue processing.

• The Bill Type is soft coded so that aging rules may be defined based on AA.PAYMENT.TYPE by choosing a soft Bill Type in Payment Schedule.
• Bill Type is kept as DISBURSEMENT for scheduled disbursements.
• By default, Temenos Transact creates the bill on the due date; however, for Products that require a Bill notice to be sent in advance of the due date, the user may enter the number of days prior in Bill Produced. This results in the due amounts being projected and recorded on the bill.
• On the bill issue date, the system considers any forward-dated changes between the issue bill date and payment date to schedule and calculate the bill amount for the current period.
  • Any forward-dated change between the issue bill date and payment date, that is input after the bill is issued is effective only from the next payment date.
    • For any floating or periodic rate changes from the BASIC.INTEREST or PERIODIC.INTEREST respectively, with a configuration to trigger a recalculation in the payment schedule, the system updates the bill issue amount automatically on the bill issue date.
    • For any fixed rate change or any other forward-dated activity in the Interest condition (at product or arrangement levels) the system requires a corresponding forward-dated activity in the Payment Schedule to recalculate the payment amount while the bill is issued in advance (to consider the scheduled rate change).
  • Additionally, if the bill is produced prior to the due date, the user can specify when the bill is considered final (that is, the bill does not alter based on changes to the arrangement).
  • If there is any change in the payment frequency or payment type through a forward-dated condition between the issue bill and make-due, the bill is not generated on that issue bill date. On reaching the forward-dated condition date for the Payment Schedule, the make-due of Payment Schedule is rescheduled accordingly and the bill is issued based on this revised make-due date.
• Temenos Transact can also combine bills by selecting Yes in Bills Combined, which have the same due date and are produced on the same date. This provides, for example, the ability to combine a monthly annuity loan repayment with a monthly charge to provide the user with a single bill amount.

Holiday Restrict Type and Holiday Restrict Item attributes are used to define the Payment Type or Bill Type or Property Class or Property that can be restricted from having a Payment Holiday.

It is possible to define that all charges be paid on a scheduled basis, – that is, on a monthly or quarterly basis. This is scheduled in the Payment .Schedule Property, but the user must define which charges applyies to which Activities.

During Charge Capitalisation, if account has insufficient funds to capitalise the charge, the pending amount is invoiced to the customer. The system retries capitalising the invoiced charge automatically at regular intervals using Transaction Cycler facility in Settlement Condition.

For Savings Plan Products, definition of Account Property is mandatory in the Payment Schedule, and the bill type has to be expected meaning the amount is expected from the customer on the dates defined in the Payment Schedule. Interest schedules are not mandatory and for both interest and principal, PAY bill gets created on maturity denoting that the amounts are to be paid to the customer.

The notional payment is defined in the Payment Schedule, these notional due payments Bill Type is flagged as EXPECTED.

The below screenshot displays Notional payments, Interest and Bonus schedules.

On maturity, the outstanding principal which was being paid by the customer on a defined frequency is part of a PAY type bill to be paid back to the customer. PAY bill for interest is also created on maturity.

Payment Types are stored in AA.PAYMENT.TYPE, which can be accessed through the AA Product Builder. The Payment Types can be created by the users.

In Payment Type, AA supports the following types for scheduled disbursements:

• AA.PAYMENT.TYPE > DISBURSEMENT.AMT
• AA.PAYMENT.TYPE > DISBURSEMENT.%

The options listed below can be used to automatically disburse loans:

• Online – It results in online or instant disbursement of a loan. It is used when the loan is to be credited automatically to the customer’s account on the successful creation.
• Service - It results in disbursing a loan when the service is run once the loan is created successfully . When a new loan is created, it is updated in the list of contracts for which service must be run for disbursement (AA.PROCESS.ACTIVITIES.LIST). The loan is disbursed when the AA.PROCESS.ACTIVITIES service is run (user-initiated) or during the COB.

In Payment Type, AA supports the following calculation types:

• Constant: This results in constant repayments, that is, Principal plus Interest repayment are constant. This is used for Annuity arrangements. This requires both an Account and Interest Property to be specified in the Payment Schedule. Charge Property is optionally added.

• Linear: Here, Principal repayment remains fixed over lifetime of the arrangement. Optional properties such as Interest, Charge and Tax may be included. The actual amounts calculated by these properties are added to the fixed principal amount repayment.

• Actual: When Type is Manual, then only allowed calculation type is Actual, in which case the user has to specify an amount in the arrangement for the Payment Type arrangement an Amount. When the type is calculated, Actual is normally used for repayment of calculated Property Classes (for example, Interest, Charge, and Tax) and the amount is determined on each payment schedule date. It can be also used in conjunction with Account Property Class, such as, Principal, when a percentage need to be specified in the Payment Schedule.

• Accelerated: It is similar to Annuity payments, but payment frequency is Bi-weekly or Weekly.

• Percentage: In this calc type, the repayment is linearly distributed for the percentage defined over the period. This is allowed for both Principal and Interest properties together for blended payments and just the Account property for Principal-only payments.

• Fixed Equal Repayment: Defines a manual repayment amount for the loan that is, it is a fixed repayment amount given by the user. In addition it is also possible to specify the component that has to be fully invoiced which could supersede the fixed equal repayment amount defined by the user. Read scheduling payment types for more information.

• Progressive: On choosing this type, a progressive percentage should be defined in the Prog Pay Perc field. The system calculates an amount which is progressing by the rate specified in Prog Pay Perc. Exactly same as CONSTANT type when Prog Pay Perc is defined as 0. Optionally the user routine could be attached for this type.

• Transaction: Generates a due bill whenever there is a Disbursement activity on a loan arrangement and the due amount calculated based on the disbursement amount. The Account Property Class and Schedule type are mandatory.

• Other: This is a user routine attached to the Calculation Routine attribute.

• Cal Routine : It is used to build the principal and interest schedules for the Rule 78 payment schedules. The following are the two calculation routines (Cal Routine) provided by Transact. Refer Scheduling Payments for more information.

  • AA.CALCULATE.RULE78.PRIN.AMOUNT
  • AA.CALCULATE.RULE78.INTEREST.AMOUNT

For Calc Type as Actual in AA.PAYMENT.TYPE, the mandatory Property Class is not specified for which the Property in Payment Schedule can be specified as any Interest, Charge or Tax Property used in the Product.

The Combine bill at parent is used in Lending and Guarantee arrangements under a facility. When there are bills produced on the underlying lending and guarantee arrangements on the same day, a combined bill is issued at the facility. This combined bill is an information bill that gives an idea of the combined total bill amount of all the underlying bills produced on the same day.

Extend Cycle

The Extend Cycle field in AA.PAYMENT.TYPE enables extending the cycle for interest, scheduled charges and periodic charges to collect them after the loan maturity or the payment end date. By default, interest is extended beyond the cycle. The allowed Property Classes are Interest, Charge and Periodic Charges. The arrangement moves to Pending Closure status only when there are no further periodic charges, interest, or scheduled charge bills to be cycled. When Extend Cycle is not set, additional cycling of periodic charges, interest, or scheduled charges, after the maturity date of the loan does not happen.

Overriding Capitalisation Amount

For CAPITALISE payment method, it is possible to cap to the extent of available balance and invoice the rest, thereby restricting the account from being overdrawn. This is configured by setting Alt Payment Method to Cap and Inv.

It is possible to attach a user API to check additional conditions during capitalisation process. This is defined in the Alt Payment Routine attribute and is currently allowed only when Alt Payment Method is set to Cap and Inv.

Accelerated Payment

A calculation type Accelerated can be chosen to calculate the accelerated payment amounts based on the frequency defined in the Payment Schedule Condition.

When Accelerated Payment Type is used in the Payment Schedule, the validation process restricts the input of payment frequencies other than Bi-Weekly and Weekly. An error message appears if others (monthly or semi-monthly) are chosen.

The chart below illustrates how the customer is benefited by choosing an accelerated payment frequency.

Loan Amount: 100,000 USD and Interest Rate: 10.5241%

Payment Type for Fixed Equal Payments

The payment type for Fixed Equal Payments is FIXED.EQUAL. It is used in a loan arrangement to indicate a Fixed Equal Repayment (FEP) schedule.

This payment type has the calculation type as Manual. The mandatory Property Classes are Account (Principal) and Interest.

Key differences between Annuity and Fixed Equal Payment Type are shown in the following table.

Percentage Based Calculation

Based on the user- defined percentage, the system calculates the repayment amount on sum of outstanding principal and remaining interest amount.

Repayment Amount = Percentage Defined * (Total Profit + Principal)

For example, loan amount is 200,000 and remaining interest amount to be scheduled is 5,608.8. If the user has given the percentage as 10%, then the system calculates the repayment amount based on the following formula:,

Repayment Amount = 10% * (200,000 + 5608.8) = 20560

For scheduled Disbursements, the following payment types are available:

• AA.PAYMENT.TYPE>DISBURSEMENT.AMT
• AA.PAYMENT.TYPE>DISBURSEMENT.%

Alternate Payment Method

The Alt Payment Method attribute has two options:

1. Cap and Inv

   During capitalisation,

   • If the account balance is more than the capitalisation bill amount, the bill is capitalised.
   • If the account balance is less than the capitalisation bill amount, the system capitalises the amount upto the balance in account and invoices the remaining amount as a due bill.
2. Due and Cap

   In a lending product with annuity payment type, when the actual amount is given in the payment schedule, that amount is made due. Any accrual for that period which is not made due is capitalised to the principal of the loan.

   • If the actual amount is less than the accruals for that period, then the actual amount is raised as due bill and the remaining amount is raised as a separate bill that is capitalised to the principal.
   • If the actual amount is more than the accruals for the period, then the remaining amount is billed towards to the principal.
   • If the actual amount is specified as zero, then the accruals for the period are fully capitalised. This option is available for both conventional and Islamic banking contracts.

The AA.BILL.DETAILS table stores the details of bills that are generated on the scheduled date. This table can be used in generating payment advices and chaser notice to the customer.

The AA.BILL.DETAILS table has three sets of attributes related to bill settlement.

• Bill .Status – Bills are issued, made due or paid or deferred, then capitalised or settled. Bill status also takes the Ageing status but it is not applicable for Accounts.
• Settlement – The new bills issued are in a status UNPAID status till they move to REPAID status (SETTLED in the case of capitalise option).
• Ageing – Bills The age of bills are based on the Overdue Property Class setup. It is not applicable for accounts that. Accounts have overdraft facility. Ageing for OD is part of the Limit Property Class.

This table also contains the Original Amount, Outstanding Amount and Adjusted Amount for every Property in the Bill and also in Total.

The Payment .Schedule Property is used in the following Product Lines Lending, Deposits and Accounts. For all the Product Lines, it can be used to either repay/pay interest and charges, capitalise and rollover deposits. These events happen on a frequency as defined in the Payment Freq attribute. In each case, a bill is produced for the customer to either receive or pay the interest as required.

The following relative events can be defined:

• START - First deposit, first disbursement.
• MATURITY - Maturity of Arrangement.
• RENEWAL - Renewal date for Arrangement
• Statement - Statement date of Statement Cycle 1

System calculates the relative date during New Arrangement, Update Statement, Change Payment Schedule Activities and cycles forward the next schedule date.

The actual statement date is used for scheduling and no adjustments based on Date Convention is done in this case.

• Each negotiation rule is defined using a multi-value set of attributes which begin with Nr Attribute. Nr Attribute does not clearly define the attribute for which the negotiation rule applies.
  • This enhancement provides a mechanism helps to specify which Nr .Attribute the negotiation rule applies to. This is accomplished by adding an additional Nr .Attribute .Rule attribute in which a user specifies a rule defining a value or values within a multi-value and/or sub- value set to pinpoint the specific attribute.
  • The same mechanism is used for Progressive Disclosure to define these rules. Attribute Rules can be specified based upon the value of a single attribute or the values from multiple attributes. The user can then specify comparison operators (that is,. ==, !=. <, <=, >, >=), AND or OR, as well as brackets or parentheses for grouping.
  • It should be noted that in the Negotiation Rule set of attributes, users can set up multiple rules per attribute; negotiable, non-negotiable, mandatory, resetting, non-resetting, fix value, and override on change of default. The new Attribute Rule applies for all of these options.
  • The following are some examples of rules which could apply for negotiation:
    • Key: Attribute Name, Comparison Operator, Literal Value, Boolean Operator, Brackets

To know how the repayment schedule works when it falls on a holiday read Date Convention and Adjustment in the Account Property Class.

Payments that are scheduled for the during last few days of month will have a change in schedule date for the month of February.

Consider a schedule is every month on 30th. For February, it moves to 28,Feb (to 29, Feb if the year is a leap year. In this scenario it is a non-leap year). The next schedule falls on 28, Mar automatically considering the monthly frequency. This is incorrect when the schedule agreed with customer is the 30th of the month.

Base Day Key in Payment Schedule decides if the next schedule after February is:

• Option Previous: Based on the previous schedule date the next schedule will fall on 28 March.
• Option Base: Based on the given base date in payment schedule that is every month 30th schedule, the next schedule will fall on 30th March.

This feature can be enabled when:

• Date Convention is selected as Forward, Forward Same Month or Backward, with Date Adjustment as Period.
  • Does not get enabled when Date Convention is Calendar.
  • Does not get enabled when Date Adjustment is Value.
• This feature is applicable only for recurrence pattern monthly in the frequency.
  • During a new arrangement creation, the start date of schedule can be a specific or relative date. If that points to a month end schedule and Base Day Key is set to Base then the schedule date will be continued after February.
  • Does not apply for weekly, daily, yearly, defined frequency, advanced.
  • Does not apply to “Day “specified in Monthly frequencies. For example this feature does not apply for “e0Y e1M e0W o30D e0F”
• The option for Base Day Key field can be input only for NEW and TAKEOVER activities.
• The Base Day Key is reset in the following scenarios:
  • Start Date is provided/removed during an amendment activity
  • Payment frequency is changed and is no longer monthly
  • For CHANGE SCHEDULE activity, the system continues with the existing arrangement behaviour.

  If the Base Day Key field is changed at arrangement level, then the system throws an error.

  • For Renewal activities like CHANGE.PRODUCT the system calculates the repayment cycle date as per the old product payment schedule even though the Resetting attribute is configured as Yes and the new product payment schedule is changed.
  • For ROLL OVER activity, the system continues the payment schedule as per the old product.

Below is an example where the Base Day Key is set to Base and the Date Convention is Forward. 28 Feb, 29 Feb, 01 Mar, 28 Mar, 29 Mar are holidays. So the schedule dates are 29 Jan, 2 Mar, 30 Mar and 29 April and thereon.

Some of the configuration is taken out of the Payment Schedule property conditions to allow for clearly definable and reusable configurations which can then be used within the conditions where the changes are not required for every arrangement.

The following mirror of attributes from the Payment Schedule conditions can be defined in AA.PAYMENT.TYPE

• Payment Method –Specifies if the payment should be Capitalised, Paid, Due, etc.
• Payment Frequency –Specifies the frequency at which the payments will be made.
• Prog Pay Perc –Specifies the progressive percentage at which the repayment amount can be incremented for every repayment. The input to this attribute is valid only for PROGRESSIVE CALC TYPE.
• Percentage –Allows the user to define the percentage allowed on the balances
• Start Date –Specifies the date when the actual payment starts
• End Date – Specifies the date when the payments should be terminated
• Num Payments –Specifies the number of payments to be done from the start date

• Bill Type –Accepts the values for soft coding through EB.LOOKUP so that aging rules may be defined based on Payment Type and Bill Type
• Bill Produced –Specifies the number of working days prior to Due Date when the bill needs to be produced. When it is not defined, the bill is made due on the frequency specified.
• Finalise Bill –Specifies the number of working days prior to which the actual payment bill needs to be finalised.
• Issue Bill –Specifies if the system should run ISSUEBILL and MAKEDUE together. When this field is defined as NO, then both the actions are combined and only MAKEDUE is executed.
• Property – Specifies the Property to be given for the Payment Type.

An API is triggered at the validation of the Payment Type attribute at the arrangement to default the values from the aforementioned fields in AA.PAYMENT.TYPE to the Payment Schedule product condition without having to construct it manually for every arrangement.

When scheduling a payment (like overpayment), it is possible to define that the frequency and payment method for this payment should be same as that of another scheduled payment in that arrangement. This Refer Schedule attribute is allowed only for overpayment schedules instructing it to refer to another payment type(for its billing frequency and payment method).