/
Change Contract Status

Change Contract Status

Owned by Lango: Language and translation manager
Last updated: Dec 18, 2024Version comment
23 min read

The wizard is used to change the detailed status of the contract (e.g. in case of early termination of the contract, return of the financed object, after financial settlement, etc.). The Action – Change Contract wizard option opens the Change Contract Wizard. In the first step of this wizard, the user selects a change in the "Change Type Code" field with the Wizard Object Number equal to 4046867. The "Change Contract" wizard is described in detail in the Změny smlouvy - změnové kopie / varianty

After completing the initial wizard, the "Change Detailed Status Wizard" opens:

Step 1/5

Field:

  • Financing Contract No.

    • Automatically fills in the OC contract number (change copies/variants)

  • Financing Type

    • Adds OC automatically from the contract.

  • Customer No.

    • Adds OC automatically from the contract.

  • Customer Name

    • Adds OC automatically from the contract.

  • Object Handover Date

    • Adds OC automatically from the contract.

  • Detailed Contract Status

    • Adds OC automatically from the contract.

  • Change at Date

    • By default, the current working date is displayed. The user has the option to enter the date on which he wants to make the change.

    • Note: it is necessary to enter the date on which you want to change the detailed status:

      • Early termination: date of removal, date of confirmation of total, etc. This date is then entered in the Early Termination Date field on the contract or on the subject (single-object contract) – if the target detailed contract status is Fill Early Termination Date. For multi-object contracts, writes the early termination date on those courses that have a detailed object status with field values

        • Early Terminated=N

        • After Fin.Resolution=N

        • After archiving=N.

      • After Financial Settlement: the date the financial settlement was created. This date is then entered in the Financial Settlement Date field on the contract or on the object (single-object contract) – if the target detailed contract status is Fill Fin. Settlement Date. In the case of multi-subject contracts, the system does not write this date to the courses (the user fills in manually).

      • After Archiving: The archive date. This date is then entered in the Actual Termination Date field on the contract, respectively. Archiving Date on Object (Single-Object Contract) – if it is on the target detailed contract status Fill Actual Termination Date.. In the case of multi-subject contracts, the system does not write this date to the courses (the user fills in manually).

    • In the case of reverse changes, it deletes the relevant dates as follows:

      • Single-object contract – deletes the relevant date on the contract and on the subject

      • Multi-subject contract – can delete dates only on the contract, the user must delete them manually on courses.

  • Financed Object Return

    • Default N

    • Change the user to A if he/she wants to change the detailed status due to the return of the financed object, i.e. if he/she wants to add e.g. the odometer status to the item when returning it (this may concern the return/removal of the item, or even a total accident)

    • Switching to A changes the Object Return Date field to editable

    • Switch to N

      • Changes the Object Return Date field to non-editable, or deletes the value of the field as well

      • Deletes the value in the New Detailed Contract Status field, if the field has been filled in

  • Financed Object Return Date

    • Editable if Financed Object Return=A, otherwise not

    • The user enters the date of return of the object (e.g. from the acceptance protocol)

  • New Contract Detail Status

    • After clicking, the Detailed Status Sequence Definition table is displayed, from which the user selects the target detailed status (new desired status) – a lookup to the Det.Contr.Status Seq API. Def. (4046812) with filters:

      • Original Det. Status Code (1) = Current Det. Contract Status

      • Financed Object Return = value from wizard

        • If Financed Object Return = N, then it is filtered to allowed det. status transitions that have Financed Object Return=N

        • If Financed Object Return = A, then it is filtered to allowed status transitions that have Financed Object Return =A

      • Allow Manual Status Change (10) = N – select only those details that do not have manual status change enabled

      • If the Financing with Services (4026780) field is in the contract:

        • N – will filter to those transitions that have Financing with Services=All or N

        • Y – will filter to those transitions that have Financing with Services=All or Y

  • Early Termination Reason

    • The OC will add an early termination code if Fill Termination Date=Y has been entered in the Detailed Contract Statuses table for the given target detailed status and if the Fill Termination Date=Y is on the given status

    • Editable if Fill Termination Date=Y is on the target detailed status, the user can manually delete or select another reason

    • The wizard then writes this value into the field of the same name in the contract header only if the target detailed status is Fill Termination Date=Y (otherwise not).

  • Create Partial Payment Credit

    • The OC will display the flag for the new detailed status according to the settings on the detailed contract status

    • The field is non-editable

  • Delete Partial Payment Credit

    • OC displays the flag for the new detailed according to the status setting on the detailed contract status

    • The field is non-editable

When the Next button is pressed, the system will perform the following checks:

  • Check for the existence of an allowed transition from the original Detailed Contract Status to the New Contract Detail Status.

    • If there is, it proceeds to the next check.

    • If it does not exist, it displays an error message and does not continue

  • If Financed Object Return = Y, the system will perform checks:

    • If Object Return Date is entered:

      • If it is, it goes on

      • If it is not, it will display a message and will not allow you to continue: "Item return date is empty!"

  • Object Return Date>=Object Handover Date

    • If it is valid, it proceeds to the next check

    • If it doesn't apply, it displays a message and doesn't allow you to continue:

      image-20240619-122529.png

      image-20240619-122540.png

  • If the New Contract Detail Status flag is Fill Termination Date=Y, the system will check the existence of the posted payment in the month of termination:

    • If the last posted regular payment (Posted=Y, Canceled=N, Partial Credit=N, Rec.Settlement=N) < Change at Date, the system terminates the task and displays the message: EN: There is no posted payment in the month of change. ENG: Posted payment does not exist in the month of change.

    • Note: a check is that the contract cannot be terminated in advance until an unposted month.

  • If Allow Partial Credit=Y is selected on the Contract Financing Model, it will perform checks:

    • If it's on the new baby. Contract Status set Create Partial Credit = Yes, checks insurance and services - if there are records in the Status and Insurance Product Relation table and in the Detailed Status and Service Relation table:

      • Insurance check – there must be an object to the contract,

        • If it does not exist, the check ends without an error message.

        • If it exists, it searches for insurance contracts in status=Active that have Valid until>Change at Date from the wizard. For each insurance contract found, it searches for a record in the Insurance Product and Status Relation table – there must be a record where:

          • Det. Contract Status = New Det. status

          • Object Category = Object Category from Financed Object,

          • Catalogue group = Catalogue group from financed object or empty

          • Insurance Product No. = Insurance Product No. from the insurance contract

          • Terminate Insurance = Yes

        • If it doesn't find the insurance policy, it's not a mistake. It goes on.

        • If it finds an insurance contract and there is no record in the relational table for the new detailed status, it displays an error and the process stops.

      • Service Check – Searches for services for a given financing contract that meet the requirements that Valid To after Extension > Change Date and Service Status=Active. For each service found, it checks whether there is a record in the table Relationship of Detailed Status and Services – there must be a record where:

        • Det. Contract Status = New Det. status

        • Service Kind = Service Kind from the service found

        • Service Type Code = Service Type Code from the found service or is empty

        • Service Code = Service Code from the found service or is empty (applies to Replacement Car, Highway Sticker, Fee, Fuel Card services)

        • Tire service = Tire service from found service or is empty (applies to tire service service)

      •  If it finds a record in a relational table for the service, it continues

      •  If there is no record for the service, it displays an error and the process stops.

    • If it's on the new baby. Contract Status Set Create Partial Credit=Yes or Delete Partial Credit=Yes, so it checks if there is a posted SPK line with flag Partial Credit=A. If it exists, it displays the message: "Partial Credit has already been posted" and does not allow to continue.

    • If it's on the new baby. Contract Status Set Create Partial Credit=Yes and at the same time Delete Partial Credit=No, so it checks if there is a non-posted SPK line with flag Partial Credit=A. If it exists, it displays the message: "Partial Credit has already been created." and does not allow continuing.

    • If Create partial credit = Y is set on the new contract detail status, the system will check the validity of contract services that have the following in Contract Services:

      • Contract No. (10)=same as Financing Contract No. from wizard

      • Service Status=Active

      • Valid From>=Change at Date

      • If such a Service does not exist:

        • Continues on to the next check

      • If there is:

        • For the first unsatisfactory service, the system displays the message "Service ... service number...: Change at Date must be greater than Valid From." "EN: Service... Service Number...: Date Change must be greater than Date From." and does not continue.

      • Note: Checking is required to keep service dates consistent. This means that we will not allow the contract to be terminated at an earlier date than the start of active services.

    • Checks if Change at Date< Date From posledného zapostovaného RS riadka (Recalculation Settlement = YES, Posted=Y a Canceled=N) is available. If they are valid, the system displays a message in and does not continue: EN: There is a posted line for recalculation settlement. / ENG: Posted Recalculation Settlement line exists.

      • Note: the user then has to manually cancel the RS line payment, then he can run the wizard again.

    • Looking for active insurance contracts that have Valid until >= Change at date

      • for each found insurance contract, it searches for the last line in the calendar for the insurance company with the flag Reported=Y. If it finds one, it checks if there is a Period From > Date of Change on such a line. If so, the error message that Reported must be N.

      • It then searches the same calendar for the last line with the flag Blocked=Y. If it finds one, it checks whether the Period To>Date has been changed. If so, the error message that Blocked must be N.

      • Then it looks for the last line in the insurance commission calendar with the flag Open=N, if it finds one, it checks it to see if Period To > Date of change. If so, the error message that Open must be Y.

This is the end of the block of checks, which applies if the Contract Financing Model is Allow partial credit = A. If value = N, the following checks are performed:

  • searches for the last posted line (Posted=Y) of the Payment Bill (any – regular, RS, partial credit...). If it finds it, it checks to see if Valid From > Date Changed on it. If so, it will display an error message that this line must not have a flag that it is posted.

  • performs the same check as the last one in the Model block. Allow partial credit=A for insurance company calendar and insurance commission calendar, with the only difference being that when searching for active insurance contracts, it still deploys the filter Valid from is <= Date of change. Subsequently, he checks the insurance company's calendar and commission calendar in the same way as in the previous block.

Step 2/5:

This step is displayed only if in Step 1/5 there was flag Financed Object Return=A, otherwise not.

Field:

  • Mileage upon Return

    • The user enters the odometer status, e.g. according to the return protocol

  • Object Taken Over By

    • selects the user from his/her own employees if the object was taken over by an employee of the leasing company (ID from User Settings)

  • The item was taken over by the contractual partner

    • Selects by the user from among the vendors, if the object has been taken over by a contractual partner

  • Second set of wheels returned

    • Turns on to A if the second set of wheels has also been returned

  • Inspection Date

    • Inspection date, if transferred

  • Excessive Wear Excl. VAT

    • Estimation of excessive wear, if the height was estimated during the inspection

  • Excessive Wear Correction

    • checked, if the repair will be handled via maintenance permission, then the wear and tear will be included in the financial settlement from the service operation

    • Not checked, if the repair is not carried out via maintenance permission, then the wear and tear will be filled in the financial settlement from the previous field, which will be written to the financed object

    • Note: the condition is the creation of a financial compensation functionality for the given leasing company, the system standard only includes financial settlements for demonstration purposes.

  • Inspected By

    • selects the user from his/her own employees if the inspection was performed by an employee of the leasing company (ID from User Settings)

  • The inspection was carried out by the contractual partner

    • selects by the user from among the suppliers, if the inspection was carried out by a contractual partner

Note: after the wizard is finished, the entered values will be overwritten to the financed object - to the Termination tab:

Step No. 3/5

Step No. 3 is displayed only if the target detailed status is set to terminate an insurance contract in the relational table.

In this window, the OC will display basic information about the contract.

Meaning of the other fields:

Number of Insurance Contracts to Be Terminated

  • OC displays the number of insurance contracts on the financing contract in Active status to be closed. After clicking on the number, the Insurance Contract List will be displayed.

Terminate Insurance Contracts on Date:

  • The system prefills the date based on the "Create partial credit memo" flag (Create Partial Payment Credit) in step 1/5. If the value is:

    • No – adds the "Period To" date (Valid To) from the last posted payment

    • Yes – adds the date from the "Change to date" field (Change At Date) From step 1/5

  • The field is editable. The user can change. E.g. in the case of a change in status, when the insurance policies of the removed items are terminated and a credit note is not issued, but the insurance policies must be terminated on the date of the change.

Note: the selection of contracts is determined by the settings in the Insurance Product and Status Relation table

The system checks the entered date in the Terminate Insurance Contracts field on the following date:

  • If

    • The requested end date is at the time of the posted payment, the system prints the message: "Client's insurance payment calendar has already been processed as of date: DD.MM.YY. Insurance contract number: XY."

    • The requested date extends into the period of the reported report to the insurance company with the following message: "Client's insurance payment calendar has already been processed as of date: DD.MM.YY. Insurance contract number: XY."

  • The user has to reconcile the end date of the insurance contracts with respect to the posted payment and the reported master statement to the insurance company

  • When the policy is terminated, the system also checks the continuity of the insurance policies of the same insurance product on the contract. If the fuses do not connect smoothly to each other, the following will be notified: "The insurance contract is not a continuation of the insurance contract XY valid until DD.MM.YY. Continue?"

Step No. 4/5

This step is displayed if an insurance policy to be created is defined in the Insurance Product and Status Relation to Detailed Status.

Field:

  • Third-party liability

    • Whether to create a new third-party insurance contract

    • On the financed object, the field Third-party liability = Yes must be checked, i.e. the object is subject to the obligation to have third-party liability insurance.

  • Property Insurance

    •  Whether to create a contract for additional property insurance

  • Effective date of new contracts

    • The system will fill in according to the Insurance Reporting flag. Online on the insurance framework agreement that is set up in the Insurance Product and Status relation to create a new insurance contract. If the value of the field is:

      • Yes

        • On at least one framework agreement = Current date + 1

      • No

        • On all framework agreements = Terminate insurance contracts on date (from previous step) + 1

Note: New insurance contracts are defined in the Insurance Product And Status Relation table (Framework Agreement No. - Liability Insurance and Framework Agreement No. - Property). If the "mandatory product" checkbox is entered in the "Insurance Product and Status Relation" settings, the system will check for the existence of an insurance policy for the mandatory product after pressing the Complete button and will not allow the process to be completed if it is not valid

Step No. 5/5

Field:

  • Number of Insurance Contracts to Be Terminated

    • The OC will display the number of insurance contracts that will be terminated.

  • Number of new insurance contracts

    • The OC displays the number of new insurance contracts created when the contract status changes.

  • Number of terminated services

    • The OC displays the number of services that the wizard will terminate according to the settings in the Relations of Detailed Status and Services table:

    • Number of services from the tempo table, those that have Service Status=Active and there is a record for them in the table Relation det. health and services with the flag Terminate Service=Y.

    • Note: The selection of services to terminate is determined by the setting in the Relationship of Detail Status and Services table. It is also possible to set the reason for discarding the fuel card.

  • Number of blocked fuel cards

    • The OC displays the number of fuel cards for which the wizard sets the blocking date after transferring the change copy or variant. The important thing is that in the table Relations of Detailed Status and Services the Fuel Card service has been set to terminate and there is a valid and not yet blocked fuel card on the object.

Note: The selection of services to terminate is determined by the setting in the Relationship of Detail Status and Services table. It is also possible to set the reason for discarding the fuel card.

After pressing the Finish button in case it is a Vehicle Return. The system checks the odometer status and records it in history. In the event of an error, it displays the error message: "Invalid Mileage. Save the record?"

If the user presses YES, he/she writes the odometer status and marks it as incorrect. If he presses NO, the odometer reading is not recorded. In both cases, it continues.

If the "Mandatory Product" check mark is entered in the "Insurance Product and Status Relation" setting, another check of the creation or existence of a mandatory product follows. Either a new insurance policy for this product is ready (it will be created after completing the wizard), or the original one has not been terminated.

If the check finds that the insurance policy for the mandatory product is not and will not be created by the wizard, it will display an error message - "There is no insurance policy for the mandatory product!"

The new check notifies you if in step 4/5:

  • Car Insurance = No

  • Date "Create Insurance Contracts at Date" is empty.

In the event of this error, the system will not allow you to continue. In order to complete the wizard, the user must return to step 4/5 and correct the reason for the error. (For a check, see. CR103)

When the wizard is finished, the OC will make the following changes - the Finish button:

  • Changes the status and detailed status of the contract

  • The detailed status of the contract will be written to the subject

  • According to the detailed status of the contract, the detailed status of the subject will be added (according to the settings of the detailed status of the contract):

    • Single-Object Contract – Always

    • More Object Contract – changes the detailed status of the object only on courses that have a detailed status of the object with Early Terminated=N, After Fin. Settlement=N and After Archiving=N. I.e. when changing the detailed contract status to after financial settlement or archiving, the dates must be filled in manually by the user,

  • Checks the Check Unclosed Guarantee flag on the detailed status specified in the New Detailed Contract Status field. If:

    • No

      • OC continues

    • Yes

      • The OC will check all the guarantees of the contract:

        • if they have Status = Completed and

        • Filled in Guarantee To field

      • If also a guarantee that does not meet the conditions:

        • displays the message "There is an unclosed guarantee on the contract: xxx, xxx, xxx... Do you want to continue?", where xxx will be the Guarantee Type Code

        • The user confirms:

          • No

            • OC stops archiving the contract. The user can terminate the guarantee manually and then run the wizard for archiving the contract again

          • Yes

            • The OC on the guarantees for the contract in a different state from Terminated shall add:

            • Guarantee to = date from the Change to date field from the dialog box

            • Status = Finished

  • terminates the original or creates new insurance contracts according to the settings in the Insurance Product and Status Relation table.

    • The system completes Change at date do Platnosti do na poistke a přecaluje poistku (zánegativný riadok s hodnotu celkový dobropisu pre klienta a prekondára kalendára poišťovní.

  • terminates services according to the settings in the table Relations of Detailed Status and Services: changes the Valid until according to the specified effective date of the change (leaves the service status to Active).

    • v tab. API Contract Service (4026681) na službách, ktoré sú v stave Active, zapíše Change at Date do Valid To a Valid To after Extension

Note: the "Fuel Card Number" fields (Card No. To. Exclusion) and the 'reason for the exclusion of the TK', (Card Exclusion Reason) where the wizard saves the values when the fuel card service ends. At the moment of "flipping" the change copy/variant or variant, the Fuel Card will be blocked according to these fields, including the reason for exclusion. (Then there is no need to add the Fuel Card table (4026756) to the change copy).

  • fills/deletes early termination data on the contract (Early Termination Date, Date After Financial Settlement, Actual Termination Date), such as in the settings in the Detailed Contract Status table

  • Adds the Early Termination Reason Code from step 1/5 of the wizard to the financing contract, the Early Termination Reason field only if Fill Termination Date=Y is on the new detailed status (otherwise not).

  • creates a record in the Odometer Status History, where it fills in (if Mileage when returning <>0):

    • Mileage=Mileage upon Return

    • Mileage Date=Object Return Date

  • to the course (Termination tab) will fill in the data entered in step 2/5 (if it is a return of the course). At the same time, it adopts the field values from the Odometer Status History to the subject:

    • Planned Mileage

    • Upper Tolerance %

    • Upper Tolerance

    • Lower Tolerance %

    • Lower Tolerance

    • Km Under/Over Limit

  • Creating a PC Line in Payment Calendars

    • The system will only perform this step if:

      • on the Financing Model, Allow Partial Payment Credit=Y and at the same time

      • in step 1, the value of Create Partial Payment was Credit=Y (assuming they passed the checks after step 1).

    • If both conditions are met, the system will create a new PC line in the payment calendar with the Partial Credit=Y flag, in which the credit payments will be calculated as follows:

    • It searches for the last posted line with flags Posted=Y, Recalculation Settlement=N, Partial Payment Credit=N, so that it can place a new line after it.

    •  If it finds one, it creates a new line as a copy of it:

      • 'PC' is added after the installment number

      • "Date From" sets as "Contract Termination Date + 1D"

      • "Date To" – set it as the last day in the same month as the "Date From" (at the end of the process it changes it as "Date To" from the last posted line, but for the calculation it must leave the last day of the month).

        • On this new line, he resets the amounts and goes to calculate the values he will use for him:

        • If the last posted line satisfies that Date From <= Contract Termination Date<=Date To:

          • Thus, only this payment (the so-called source line) will be used for the calculation. See Example 1

        • If this is not met (there are subsequent posted instalments):

          • Searches for all posted regular payments where Date To > = Contract Termination Date.

          • He goes through these and creates a filter with the numbers of all installments, which are either partially or completely credited.

          • If the payment meets Date From <= Contract Termination Date <= Date To, he will note that it is a payment from which he will take a proportional part, from the others he will take the entire amount of principal and interest. See Example 2

    • The new values are then calculated as follows:

    • Principal

      • Calculates the corresponding part from the source line as follows:

        • if the Termination Date<>is the last day of the month, it executes:

          • detects the number of payment days as the difference Date To – Date From + 1 on the PC line.

          • Next, it finds out the number of days that the month has in total. With this ratio, the number of repayment days / the number of days in a month multiplies the principal on the source line and thus calculates the part of the principal that will be credited from that line.

        • If Termination Date=last day of the month, it does not perform this calculation and continues to search for whole amounts.

      • To this, it adds the full principal amounts from any subsequent posted installments. This total value is written with a negative sign to the PC line in the Principal field

    • Interest

      • analogously, it just takes values from the Interest field

    • Services

      • searches for contract services that have status=Active and Reflect Aliquot=Y (Example 1).

        • for each service found, it looks for a line in the payment calendar that has the same Contract Payment No. as the source payment of the SPK.

        • If it finds such a line, it is possible to create a new PC line in the SPK service:

          • The dates are filled in the same as the PC line in the Contract Payment Sheet

          • The amounts will be filled in similarly

            • It takes a proportional part of the amount from the line that corresponds to the source line, and the entire amount of the payment/costs from the following lines (matching filter for the contract payment number).

            • Currency amounts are calculated using the currency factor.

            • The total amount from all created PC service lines is entered into the GAK of the contract with a negative sign in the Service field

      • Searches for contract services that have status=Active and Reflect Aliquot=N (see Example 2).

        • for each service found, it looks for a line in the payment calendar that has the same Contract Payment No. as the source payment of the SPK.

        • If it finds such a line, it is possible to create a new PC line in the SPK service:

          • The dates are filled in the same as the PC line in the Contract Payment Sheet

          • Amounts to fill in

          • It doesn't take any part of the amount from the line that corresponds to the source line.

          • from the following (corresponding filter to the contract payment number) the entire amount of the installment/costs.

          • Currency amounts are calculated using the currency factor.

      • The total amount from all created PC service lines is entered into the GAK of the contract with a negative sign in the Service field

    • Insurance

    • searches for insurance contracts that have a Valid to the same as the Termination Date on the financing contract header.

    • Filters the client's calendar to rows that match the filter for Payment Numbers and Period To >= Contract End Date.

    • The last line is copied to the new one:

      • adds 'PC' to the payment number

      • Dates populated from the PC line from the Payment Bill

      • He calculates the amounts as follows:

        • if the Termination Date<>is the last day of the month, then it takes a proportional portion of the payment that corresponds to the source line, the entire value of the Amount and Amount (LCY) fields from the following rows.

          • The proportional part here is calculated differently than for principal, interest and services. Calculates the daily coefficient using Period From and To on a new line and taking into account the value of the "Daily Rate Calculation" field on the insurance company's product. This coefficient is multiplied by the value of "Annual Client Premium" on the insurance contract card.

        • The proportional part (if calculated) is added to the full amounts from subsequent installments and the sum is written into the client's PC calendar line. Calculates the VAT amount. When generating these rows, it stores accumulated values in variables according to the type of basic product and insurance in total.

        • These values are then written to the PC line in the GAC of the contract in the fields Insurance, Liabilty Insurance Amount, Crash Insurance Amount and Other Insurance Amount.

      •  Finally, in the PC line of the Bill of the contract, it validates the Amount and Balance fields in order to recalculate the Total Amount and Amount Including VAT and Balance fields.

      •  if the Termination Date is the last day of the month and it is also the last posted month, the created PC line (which is all zero) is deleted.

  • If there is a flag on the target detailed state Generate VAT Credit Memo - Delivery of Goods on Change of Status = Yes and the contract shows Leasing with Delivery of Goods = Y, Generates a calculation input for the balance of the tax liability (the tax document is then generated and posted when the change copy is transferred).

 

Example 1 – PC line for the last posted payment

Termination Date=11/10/2023, at that time in the last posted month. - there are no curved services in the PC that had Reflect Aliquot=N

 

Calculation of the share of services: The sum of services that have Reflect Aliquot YES = 2788.76. 20-day share = 1859.17, which corresponds to the value of the PC row in the Maintenance field.

Services that have Reflect Aliquot YES

Example 2 – PC line for multiple months

Termination Date = 10/09/2023. On PC, the whole months are 11 and 10/23 (complete payment including all services) + aliquot 9/23 (services without Reflect Aliquot=N).

Example 3 – PC row in the same month as RS row

Rekalk (RS) and posting. Spl. in 12/2023, in the same month also termination, i.e. in PC only an aliquot of the month of the last month. 

Change status the reactivating Contract after extraordinary Contract termination

In the event that an extraordinary termination occurred by mistake and the partial credit for the last fully posted payment has not yet been posted, the user can run the Change Contract Status wizard and change the status to Active again. The goal is to delete partial credit memos that arose during extraordinary termination.

An important condition for deleting a credit memo is that the Delete partial credit = Yes field is checked on the detailed status for Active contract and at the same time the Allow partial credit is checked on the contract model.

The user starts the Status Change Wizard.

In step 1/5, enter Change at date (Change at data) the same date that was entered at the time of the extraordinary termination as Return of the Car or Termination of the Contract.

Non-editable flag Delete Partial Credit (Delete Partial Payment Credit) It shows that the settings on the detailed status and model are satisfactory and the wizard deletes the partial credit.

Since the active detail state is not set to close fuses or create new fuses, pressing the Next button (Next) The last step 5/5 with a recap.

The new detail status will be Active, Change as of Date will void the termination and delete the partial credit, it will not terminate insurance policies, it will not create new insurance policies, it will not terminate services or it will not block fuel cards.

If fuses for the "removed item" were created during the extraordinary termination, the system will notify you of the existence of these fuses after the Complete button:

Result of reactivation:

  • In the payment calendar, the system deleted the partial credit note

Insurance Contracts:

  • On the original insurance contract, the system returned to the Valid From field (Valid To) original Expected Termination Date (Expected Termination Date). If insurance policies were created for a removed item during the emergency termination, they are already in the Active status and cannot be deleted. The user must set the status of Unrealized on these fuses (Declined).

Contract Services:

  • On contract services, the system returned to the Valid To field (Valid To) and Valid after Extension (Valid To after Extension) Original Expected Termination Date (Expected Termination Date).

Contract – Termination Tab:

  • Change Status Wizard Back to Active deleted Termination Date (Termination Date).

Other actions related to the reactivation of the contract must be checked and performed manually by the user.