Automatic Contract Extension

In the event that it will be required on the Model Contract parametrically, in a situation where the client does not return the vehicle by the decisive date (or the contract has not been otherwise terminated), the next instalment has been added automatically (parameter Automatic Contract Extension), when launching a new function (Batch Automatic Contract Extension within the Post Financing Payment (with services) task), the system will add two installments to the payment calendar in the case of the first extension. With subsequent extensions, there is only one payment for the extension.

The reason for this is to have one uninvoiced payment at a time. This fact will make it possible to make subsequent changes to the contract. In general, the system requires at least one uninvoiced payment for a change.

Note: When the last regular payment is posted, an extension is not yet created. The client can still return the item during this month. If the subject is not returned to the subsequent month posting, the system creates a calendar extension by two lines = months and posts the first of them when posting by batch job. With the next extension, the system always creates only one new line.

Contract Extension Batch Job:

The functionality is part of the Mass Invoicing of Post Financing Payment (with services) task of contracts with services (Financing with services = YES).

This part of the task is included before the actual invoicing of payments. If the prerequisites described above are met, the task creates extension payments. Then, the invoicing job processes the payment that matches the terms for invoicing.

Parameters of the added function:

• The task will be based on the filters for Payment Invoicing and at the same time take into account programmatically defined filters.

Procedure:

• User Runs Mass Invoicing Task

• Enter the parameters in the Options section:

  • Posting Date

    • The posting date to the created invoice, or the automatic extension of the contract is based on this date (see below)

  • VAT Date

    • VAT Date To Created Invoice

• Then you can also enter parameters for filtering customers or contracts

• When the OK button is pressed, the system performs the following actions:

  • It searches for customer contract lines, resp. which correspond to filters or other parameters for invoicing (e.g. Allow Posting from Payment Calendar=Y on the detailed contract status) - see Invoicing Sales for description

  • It then calls the function to automatically extend the contract

Programmatically defined filter for automatic renewal:

• On the detailed contract status there is Allow Posting from Payment Calendar=Y, Allow Posting Downpayment=Y or Allow Posting Partial Payment Credit=Y (conditions for posting payments from the contract payment calendar). If all three flags are N, the contract is no longer processed.

• The contract has Expected Termination Date =< than the Expected Termination Date

  • The decisive date is defined by the batch job parameter Day 1 from the Posting Date in the Invoicing Parameters section

• A new parameter is set on the Contract Model – Automatic Contract Extension=Y

• Object Return Date on the Financed Object and Termination Date on the contract are blank (if at least one field is filled in, the contract cannot be automatically extended).

The task will go through the selected contracts and if they meet the selection conditions (program and user filter at the same time), it will add another one Automatic Contract Extension Line in the payment schedules according to the described principles and adjust the related header data.

The function makes the following changes to the identified contracts:

If the conditions for contract extension are met, the system will create contracts, services and insurance policies in the payment schedule - in general:

• If the contract flag is Contract Extension=N, the system will identify the last due payment in the contract payment calendar with Aliquot Payment=N, Recalculation Settlement=N, Partial Credit=N, Contract Extension=N regardless of Posted/Canceled and create two new lines by copying this regular payment:

  • First payment for the period from the end of (Date to) the last payment + 1 day to the end of the calendar month

  • Second payment for the period from the end of (Date to) the previous payment extension + 1 day to the end of the calendar month

  •  These payments will be flagged with Contract Extension=Y.

• If the contract flag is Contract Extension=Y (i.e. second or subsequent extension), the system identifies the last due payment with Aliquot Payment=N, Recalculation Settlement=N, Partial Credit=N, Contract Extension=Y regardless of Posted/Canceled and creates one new line by copying this payment:

  • payment for the period from the end of (Date to) the last payment + 1 day until the end of the calendar month

The individual instalment items are filled in as follows:

1, Financial Calculator (Fin.Calculator Line)

In the financial calculator, automatic extension rows are created by successive copying (i.e. not by recalculation), new lines are created and will be tagged with Contract Extension=Y.

A new extension row will be added to the calculator lines for each added payment that will have a Date From Identical to Date From in the lines of the contract payment calendar, the payment number will be increased by +1 and the other values will be copied from the last payment in the calculation line (Interest Rates, Principal Debt Balance, Interest). The line will be labeled Contract Extension = YES

2, Contract Services

The system will automatically renew services that meet the following conditions:

• the service has Service Status=Active and at the same time

• Valid To=>Expected Termianation Date Contract

If the service meets these conditions, the system will add a new value Valid To after Extension = Expec.Termin.Date after Extension according to the contract header, or it will create new service installments by copying the line according to the principles of creating lines in the contract payment calendar.

If the Services do not meet these conditions, they will not be extended.

The function in the payment calendars of the found services copies the payment according to the general principle described above, including the cost, while adhering to other principles for numbering, setting dates, etc. On the lines created in this way, it then sets Contract Extension=Y.

It then sets the new Valid To after Extension date on the service header. The value of the last renewal day (the last calendar day of the renewal month).

3, Insurance

The function proceeds in the same way as with services. On insurance policies valid (Status=Active and Valid To>=Expected Termination Date) at the time of renewal, it creates a new line in the insurance payment schedule for the client, where it takes over the amount of the regular payment according to the general principle described above for the entire period. The sum of the insurance calendar rows created in this way for the client for each insurance type in the given period will be the sum of insurance in extension. The Insurance Company Payment Schedules and the Commission Payment Calendar are recalculated according to the extended "Valid To" in the policy header.

In insurance contracts, the date after extension is entered in the standard "Valid to" field. The system will store the original content of this field in the "Original Valid To" field on the "Posting" tab of the insurance contract card before it is extended. The "Original Valid To" for extended insurance policies will correspond to the expected termination date on the contract. For each policy, there is a payment schedule for the client separately. Insurance payments from these calendars are then transferred to the line of the payment calendar (according to individual insurance types).

A new "Valid To" date is set on the insurance header. It is set to the value of the last day of renewal.

On the insurance line, Contract Extension = YES

• Date From – the date of the first day following which you put To on the last payment in the payment calendar.

• Date to – date of the end of the month in which the extension is added.

• Posting Date and Maturity date it is determined according to the rules for instalments (according to the financing model)

• the line will be marked Contract Extension = YES

4, Contract Payment Calendar (Fin.Contract Line)

A contract payment calendar is created by the payment calendar deployment function, where extension lines are marked with the Contract Extension=Y flag, according to the general principle described above.

5, Fin.Contract Header

The Expec date is set on the contract header. Term. Date After Extension (Expected End Date After Extension) on the last day of the extension period.

• A new value is set on the contract header Financing Period Extended (in Months (Financing Term (in Months) including Renewal). It will represent an increase of +2 on the first contract renewal and +1 on each subsequent renewal (see above).

• Sets the contract flag Contract Extension=Y (if it hasn't already been set before).

Note: switching to N will be handled by the recalculation wizard.

• In the Contractual Distance table, the recalculation performs the field:

  • Contractual mileage. After Extension:

    • Contractual Mileage after Extencion= round((Distance per Year*Financing Period after Extension (in Months))/12; 0)+Initial Mileage (4026685) from API Financed Object (4026560)

  • Then the Contracted Mileage value. After the extension, it will also be written into the contract.

The task does not perform posting or other operations (profitability updates, etc.) or checks related to changes in the length of the contract (REFI rates, insurance rates, etc.).

Depending on the number of contracts selected, this task may take a corresponding amount of time to process.

Notification:

If the contract is in automatic extension mode (i.e. it has Contract Extension=Y), the system technically does not allow any recalculation to be performed:

• Calculator Lines (Financing Calculation)

  • After pressing the Finish or Update button, it checks the contract flag and if it is Y, it displays a message and does not execute the calculation: "Contract Extension is Y, change is not possible."

In the same way, the system performs a check, or displays the same message for wizards:

• 4046864 Change Contract Payment Terms, Fin.Charge, Reminder

• 4046866 REFI Code Change

• 4046869 Change Contract Purchase Price wizard (technical evaluation)

• 4046865 Change Contract Customer wizard.

• For a more detailed description of the control in wizards, see Contract Changes