/
Functions Of The Variant

Functions Of The Variant

Owned by Lango: Language and translation manager
Last updated: Oct 26, 2024Version comment
9 min read

Original Contract and variant

If the creation wizard was launched from the original contract, the original will be opened even after the variant is created. The created variant is automatically assigned to the contract.

The list of variants can be opened from the original contract:

  • No. of Calculation Variants

    • If there are variants for the contract, the calculated field will show the number of variants.

    • Then, after clicking, an overview of these variants will open (regardless of their variant status).

Then, after opening, we see the variant:

The variant number will be in the form XXXXXXX_Vx, where XXXXXXX is the contract number, _V is the suffix (postfix) for distinguishing variants (from OneCore Setup) and x is the serial number of the calculation variant.

  • Last Change Code displays the code from the line belonging to the variant from the Contract Change History

  • Change copy to contract shows the number of the original contract

  • The change copy user ID contains the ID of the user who created the variation. Unlike a change copy, another user can also work with the variant.

  • The created variant will have Calculation Variant Status=Active.

  • The significance of the Date and Time of Calculation creation is obvious.

The user makes the necessary changes to the created calculation variant and starts the recalculation of installments (if necessary).

  • On the calculation variant form, the user can make a change using a wizard (if there is a change for the given type and it has the flag Allowed for variant=A) or manually.

  • It is not possible to create a change copy in the Calculation Variant independently of the parameterization of the detailed status

  • It is not possible to create an individual invoice for the calculation variant

  • It is not possible to post/cancel a payment calendar or perform other accounting operations for the calculation variant

  • Certain types of changes are prohibited in the Calculation Variant (especially those within which an invoice or posting can be created, e.g. transfer to another customer, etc.) according to the setting of the Allowed flag for Calculation Variant from the Contract Change Types table

After confirmation of the calculation variant by the customer, the user activates (transfers) the calculations to the contract.

Variant transfer

The transfer of the variant to the contract is performed by the user using the Transfer Variant (Transfer Variant):

Transfer Variant does the following:

  • The user selects the calculation variant that he wants to transfer to the original contract (activate)

  • The system checks whether the user is initiating variant transfer from the variant (flag Calculation Variant=N/Y):

    • if Y (i.e. the user has started the transfer of the variant from the variant), it continues to the next check

    • if N (i.e. the user started the variant transfer differently), it displays an error message and does not continue

      image-20240619-111856.png

  • The system will check the Status of the variant:

    • If Active proceeds to the next step

    • if another one is Active, it displays an error message and does not continue (variant can be transferred only one time)

      image-20240619-111920.png

Note: Payment posting toggles variant status to Inactive. Also, the transfer of the active variant switches the other Active to Inactive.

  • Checks if there are insurance contracts for the financing contract to be reported or unsubscribed online.

    • To report a new insurance policy The system checks whether the insurance contract contains:

      • Insurance Reporting OnLine = Yes

      • Insurance Company Check-in Date = empty

      • Termination Code = Empty

    • If there is an insurance policy that meets these conditions, it checks whether the insurance framework contract contains the flag Insurance Company Verification Required = Yes. If:

      • Yes

        • Checks if the Verified = Yes fields are present on the insurance contract if:

          • No

            • Displays the error message "Verified must be Yes on insurance contract XY" and stops the change copy transfer process

          • Yes

            • Checks if the fuse Valid From < the current date. If:

              o Yes - Displays the error message "Insurance XXX. Valid from must be >= current date!" And the transfer of the change copy stops

              o No - in the OC there is a preparation for calling the service for reporting the insurance policy (reporting addition), the process of transferring the change copy continues

    • To unsubscribe from an insurance policy online, the system checks whether the insurance contract includes:

      • OnLine Reporting = Yes

      • Insurance Company Check-out Date = blank

      • Termination Code = non-empty, or Early Termination = Yes

    • When there is an insurance policy that meets these conditions, it checks:

      • If the policy says Valid To < the current date. If:

        • Yes

          • Checks on Termination Code whether it has Allowed to terminate retroactively = Yes. If:

            • Yes

              o Preparation for calling the service to unsubscribe the insurance policy (attrition reporting). The proclamation takes place in the background.

            • No or Termination Code is not filled in

              o Displays the error message "Insurance XXX. Valid to must be>= current date!" and the change copy transfer stops

        • No

          • Preparation for calling the service to unsubscribe the insurance policy (report attrition). The proclamation takes place in the background.

    • If there is no policy on the contract that meets the conditions for unsubscribing or reporting, it proceeds to the next check

  • Checking the Strict Changes List Policy flag in OneCore Setup:

    • If n

      • On the last line in the Contract Change History, toggles:

        • flag Closed on Y

        • Customer Approval flag on Y

        • Cust.Approval Date=sysdate

        • add date Approved On=sysdate

    • If Y

      • Checks if the flag is Closed=Y (i.e. it was toggled by the user to approve the change before the transfer)

      •  If Y

        • Performs a change copy transfer

      • If n

        • Displays a message and does not transfer the change copy:

        • The user then opens the Contract Change History on the change copy, closes the line and transfers the change copy.

  • The system checks whether the calculation variant has been calculated, including all related parts (insurance policies, services), symptoms:

    • Service-Updated (150)=Y and

    • Insurance-Updated (151)=Y and

    • Payments-Updated (152)=Y– all three must be Y, otherwise it will display the message:

    • It does not transfer the variant – the user must first recalculate the contract.

  • Checks if there are non-rollover variants for the contract (Variant Status=Active):

    • If there are any, it will ask if the user wants to continue: "There are variants that have not been transferred to the contract, do you want to continue?"

      • If he confirms, he continues. After the transfer is performed, the status of the other active variants switches to Inactive.

    • If they don't exist, it continues.

  • check if there is a Change Copy Exists for the original (Change Copy Exists=N/Y on the original contract):

    • if N, it continues

    • if Y (i.e. there is a change copy to the original), it displays an error message and does not continue further (note: the change copy takes precedence over the variant):

  • Check if there has been any change in the contract after the variant was created:

    • To perform this check, the system compares the SystemModifiedAt value in the Original Contract, Object, and Fuse tables with Calc. Var. Creation Datetime from Variant

    • if a change has occurred in any of the tables ((SystemModifiedAt in the original table > Calc. Var.Creation Date from variant), displays a message and does not allow the variant to be transferred.

    • The following tables are checked:

      • API Financing Contract Header (4026397)

      • API Financing Contract Line (4026398) – the message is different because the system switches active variants to Inactive when posting installments

      • Contract Accrual Line (Table 4026842 API Contract Accrual Line)

      • Contract Calculation Inputs (Table 4026450 API Contract Calculation Input)

      • API Contract Guarantee (4026447) for each guarantee

      • Then he searches for the objects of the contract, and for each object:

        • Odometer Status History API (4026583)

        • API Object Tire (4026675)

        • API Object Security System (4026581)

        • API License Plate History (4026584)

        • API Object Revision Validity (4026678)

        • API Object External Check (4026691)

        • API Object Rim (4026676)

        • API Evid. of Obj. Sales Price (4026585)

        • API Financed Object (4026560)

      • Then it goes to the next object, if it exists.

      • Then he goes on to the insurance policy:

        • API Insurance Contract

        • API Ins. Client Payment Cal.

        • API Ins. Company Payment Cal.

        • API Ins.Comm. Payment Calendar

    • If no change has been made, it will ask if the user wants to overwrite the contract

    • and after confirmation, it will start transferring the variant to the contract.

    • Performs a check:

      • in the ReplacebyVariant function, the check is again if Complete Calculation=Y:

      • Service-Updated (150)=Y and

      • Insurance-Updated (151)=Y and

      • Payments-Updated (152)=Y and

      • Calculation Lines-Updated=Y and Complete Calculation=Y– all must be Y, otherwise they will display the message:

        • Changes requiring recalculation have been made to the variant. Please run recalculation before transferring the variant.

    • The system transfers the variant to the contract. Further:

      • deletes the transferred variant

      • if there were other variants of the contract in the Active status, it sets their status to Inactive.

      • Displays a message about variant transfer: "Variant No. XXX has been transfered."

Remove variant

Deleting Calculation Variants It is possible to select the action - Delete Variant (Remove Variant).

The system deletes a variant only if the variant has not been transferred to the contract (it does not have a record in the contract history).

At the push of a button, the system performs checks:

  • The system checks whether the user triggers the deletion of the variant from the variant (flag Calculation Variant=N/Y):

    • if Y (i.e. the user has triggered the deletion of the variant from the variant), it continues to the next check

    • if N (i.e. the user triggered the deletion of the variant in a different way), it displays an error message and does not continue

  • The system deletes the variant, including all components (related tables).

  • If a user closes the change history manually and then deletes the change copy/variant instead of transferring it, then we no longer have the last open line. In this case, we delete the last corresponding closed line, namely the one that was created on the same day as the change copy/variant was created.