Original Contract and variant
If the wizard for creation was started 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 line code belonging to the variant from the Contract Change History
Change copy to contract shows original contract number
The user ID of the change copy 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 when the calculation was created 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 the wizard (if it exists for the given type of change and 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 Enabled flag for the 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):
The Transfer Variant function 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
The system will check the Status of the variant:
If Active proceeds to the next step
if another is Active, it displays an error message and does not continue (the variant can only be transferred one time)
Note: Posting installments toggles variant status to Inactive. Also, the transfer of the active variant switches the other Active to Inactive.
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
Approval Date=sysdate
add Approved On=sysdate
If Y
Checks if the flag is Closed=Y (i.e. it was toggled by the user as part of the change approval 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 variants that have not been transferred to the contract (Variant Status=Active):
If there are any, it will ask if the user wants to continue: "There are non-transferred variants to the contract, Do you want to continue?"
If he confirms, he continues. After the transfer is complete, 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 = 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 (note: the change copy takes precedence over the variant):
Check if there has been any change in the contract after the variant was created:
The system performs this check by comparing the SystemModifiedAt value in the original contract, object, and fuse tables with Calc. Var. Creation Datetime from Variant
if any of the tables have been changed ((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
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 proceeds 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, 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 will delete 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 has 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 row. In this case, we delete the last corresponding closed row, namely the one that was created on the same day as the change copy/variant was created.