/
Change of VAT rate on Active contracts

Change of VAT rate on Active contracts

Owned by Lango: Language and translation manager
Last updated: Jan 10, 2025Version comment
12 min read

For this purpose, a bulk task is added to the system Convert VAT Rate in Active Contracts (API Change VAT Group Aft. Act. (78001)). This task ensures the exchange / conversion of VAT product posting groups on contracts in the Active status, both in the contract header and in other tables that are related to the contract and have an impact on the VAT calculation. I.e. the change will also be made for related services, insurance and calendars.

This modification takes place without the use of change copies directly on the originals of these contracts and is based on the logic of the API Contract Services Change (4026638) task.

Button Convert Active Contracts to run the job, it is added to the VAT Rate Change Setup page. It is also possible to search for a task using the system magnifier.

image-20241128-125236.png

Request Form

When the task starts, a dialog box opens Convert VAT Rate in Active Contracts To specify criteria and filters:

image-20241128-125123.png

In the section "Options" are the fields:

  • VAT Change Date

    • Date type, empty by default

    • The user enters the date from which the change of the VAT rate is valid and the system assesses posted and unposted lines in the contract payment calendar according to this date. Job Process Description

    • Mandatory field (see post-launch checks below)

  • Contract Change Type

    • Lookup to the Contract Change Types table (4046856) with filter Object ID wizard (15)=empty (i.e. it is not possible to select the change that is triggered by the wizard)

    • The user selects the Contract Change Type Code, which the task then writes to the Contract Change History, in the Change Code field

    • Required, see checks after the job has started

  • Contract Change Reason

    • Lookup to the Contract Change Reasons table (4046857)

    • The user selects the Contract Change Reason Code, which is then written by the task to the Contract Change History, in the Reason for Making Change field

  • Comment

    • Text 120, empty by default

    • The user adds a text note, which the task then writes in the Contract Change History, in the Note field.

In the section "Filter: Financing Contract Header" are the filters:

User filters are all empty by default

  • Financing Product Type Code

    • If empty, it is not filtered to the given value

  • Financing Product No.

    • If empty, it is not filtered to the given value

  • Customer No.

    • If empty, it is not filtered to the given value

  • Well.

    • Financing Contract No.

    • If empty, it is not filtered to the given value

  • Migrated Contract

    • Option

      • Empty – not filtered to the given value

      • No – filtered to the N value in the contract

      • Yes – filtered to the Y value in the contract

  • additional filters can be added by the user via the + Filter button...

The general principles of filtering in BC are described here:

Sorting, Searching, and Filtering Lists - Business Central | Microsoft Learn

It also has a role to play in Fixed filters per contract header – only contracts that meet:

  • Calc.Variant=N

  • Change Copy=N

  • Change Copy Exists=N

  • Status=Active.

When setting up user filters, the user must also take into account fixed filters that are in the code and cannot be modified by the user – i.e. if the user has set the user filter to e.g. Status=Closed, contracts in this state will not be processed, because the fixed filter Status=Active takes precedence over user filters.

The task can be started by clicking OK or Schedule... (Schedule...). If the task is started by the OK button, it runs interactively (displays possible messages) under the given user. If the task is started by the Schedule... button, the execution itself is executed via the job queue (scheduler) – the messages are suppressed, or it is no longer necessary for the user to be logged in after the start (description below).

Job Process

After starting the task with the "OK" or "Schedule" button, the system executes:

  • Checks if VAT Change Date is filled in

    • If it is not filled in, it will display an error message "VAT Change Date must be entered. EN: VAT change date must be entered. SK: VAT changes must be entered." And it doesn't go any further. Likewise, when running via Schedule...

    • If it is filled in, it continues to the next check

  • Check if the Contract Change Type is filled in

    • If it is not filled in, it will display the error message "Contract Change Type must be entered. EN: Contract change type must be entered." and it doesn't go any further. Likewise, when running via Schedule...

    • If they are filled in, it continues

  • If all checks are error-free, the job runs and iterates through the funding contract headers. It looks for contracts that meet:

    • Fixed filters:

      • Calc.Variant=N

      • Change Copy=N

      • Change Copy Exists=N

      • Status=Active

    • Filters that have been entered by the user in the Task dialog box in the Filter: Financing Contract Header section

  • It will then check the found contracts to see if there is an aliquot payment in the API Financing Contract Line (4026398) payment schedule:

    • Financing Contract No. (1)=same

      • Type (6)=Payment

      • Aliqout Payment(810)=Y

    • If it exists, it checks to see if this payment is posted. That is, in the Posted=Y field.

      • if it is not posted (i.e. the contract is after activation and before the aliquot is posted), then it does not process this contract, or it writes it into the Contract Change Log:

        • writes the contract to the Contract Change Log with Recalculation Result=Fail and Error Detail=Posted aliquot payment does not exist. (EN: Posted aliquot payment does not exist.)

        • Continues to the next contract

      • if it is posted, it continues to check VAT Reporting Date (see below)

    • If there is no aliquot payment (Handover Date=1st day of the month), it will check if the contract has at least one posted regular payment or down payment in the contract payment calendar API Financing Contract Line (4026398):

      • Financing Contract No. (1)=same

      • Type (6)=Payment

      • Aliqout Payment(810)=N

      • Recalculation Settlement (3045)=N

      • Partial Payment Credit (3055)=N

      • Posted (50)=Y

      • If such a payment does not exist (i.e. the contract is after activation, without aliquot and before posting the down payment or the first regular payment), then it does not process this contract, or it is written into the Contract Change Log:

        • writes the contract to the Contract Change Log with Recalculation Result=Fail and Error Detail=Posted regular payment does not exist. (EN: There is no posted regular installment.)

        • Continues to the next contract

      • If such an installment exists, it continues to be checked VAT Reporting Date (see below)

  • It will then check the found contracts to see if they exist for the given contract Posted regular payment in the API Financing Contract Line (4026398) payment schedule, which has VAT Reporting Date (850) or VAT Date (CZ/SK: 4027520) greater than or equal to the specified VAT Change Date from the task dialog box:

    • Financing Contract No. (1)=same

    • Type (6)=Payment

    • Aliqout Payment(810)=N

    • Recalculation Settlement (3045)=N

    • Partial Payment Credit (3055)=N

    • Posted (50)=Y

    • VAT Date (CZ/SK: 4027520) or VAT Reporting Date (850) => VAT Change Date

    • If such a payment exists (i.e. the contract has a posted payment with a VAT date greater than the VAT change date), then it does not process this contract, or it writes it into the Contract Change Log:

      • writes the contract to the Contract Change Log with Recalculation Result=Fail a Error Detail=The contract must not include posted payment with a VAT Date higher than or equel to the VAT Change Date. (EN: The contract must not contain a posted payment with a VAT date higher than or equal to the VAT change date. SK: Na zmluve nesmie byť zakalovaná splatá s dátumom DPH vyšší alebo rovným ako je dátum zmeny DPH.)

      • Continues to the next contract

    • If no such payment exists, it continues to the next check

  • It will then check the found contracts to see if they exist for the given contract Unposted regular payment in the API Financing Contract Line (4026398) payment schedule,

    • Financing Contract No. (1)=same

    • Type (6)=Payment

    • Aliqout Payment(810)=N

    • Recalculation Settlement (3045)=N

    • Partial Payment Credit (3055)=N

    • Posted (50)=N

    • If such a payment does not exist (i.e. the contract is in the last month of regular duration and before the automatic extension), then it does not process this contract, or writes it into the Contract Change Log:

      • writes the contract to the Contract Change Log with Recalculation Result=Fail and Error Detail=Unposted payment does not exist. (CZ/SK: Unposted payment does not exist.)

      • Continues to the next contract

    • If such an installment exists, a check is made that first Unposted Payment it also has a VAT Reporting Date (850) or VAT Date (SK/CZ: 4027520) greater than or equal to the specified VAT Change Date from the task dialog box. If the condition:

      • IS fulfilled, so proceeds on to process the original contract (see below)

      • NOT met, so:

        • writes the contract to the Contract Change Log with Recalculation Result=Fail a Error Detail=The first unposted payment does not have a VAT Date higher than or equal to the VAT Change Date. (EN: The first unposted payment does not have a VAT Date greater than or equal to the VAT Change Date. SK: The first unposted payment does not have a Dátum DPH vyšší alebo rovný Dátumu zmeny DPH.)

        • Continues to the next contract

  • Then he proceeds to process the original contract:

Processing of the original contract

Task:

  • find out what conversion will be done in the VAT Rate Change Conversion table (551) by going through all rows and replacing the value from the From Code field with the value in the To Code field

  • writes a new VAT product posting group on the contract header according to the found value in the To Code field from the conversion table to these fields so that the change is made only in those fields in which it finds the same value as in the conversion table in the From Code field:

    • VAT Posting Group Principal, W1 Field 310

    • VAT Posting Group Interest, W1 Field 311

    • VAT Posting Group Simple Service, W1 Field 315

    • VAT Posting Group Special Mode – Tax (VAT P.Gr. Special Mode Tax), SK Field 4027530, CZ Field 4047510

    • VAT Posting Group Whole Paym., W1 Field 322

    • VAT Posting Group Simple Ins., W1 Field 318

    • VAT Posting Group Simple Fee, W1 Field 316

    • VAT Posting Group Deposit, W1 field 320

    • VAT Prod. Post. Gr. Del. Goods, SK field 19610

    • VAT Prod. Post. Gr. Correction, SK pole 19615

  • In the API Contract Service (4026681) table, it finds the following services:

    • Filters:

      • Service Contract Type (5, Option, PK)=Contract

      • Contract No. (10, Code[20])=same

      • Service Status (20, Option)=Active

    • If he doesn't find any services, he continues to the insurance policy

    • On all services found, the conversion of the VAT posting group will be performed in the same way as in the contract header:

      • VAT Prod. Posting Group (125)=same value as Code From field

    • In the payment calendars of the found services, it finds unposted lines Line Type (5)=Payment and Posted (75)=N and updated:

      • VAT Prod. Posting Group (120) = VAT Prod. Posting Group (125) from the header of the service

      • VAT % (125) = according to the VAT Bus combination. Posting Group a VAT Prod. Posting Group (standard)

      • VAT Amount (130) = recalculated according to the new VAT rate.

    • Upon completion of all services, proceeds to the insurance policy

  • In the API Insurance Contract table (4027100) it finds the following insurance policies:

    • Filters:

      • Financing Contract No. (50, Code[20])=same

      • Status (60, Option)=Active

      • Valid To >= VAT Change Date from Task Dialog Box

      • Insurance Type (910, Option) <> Individual

    • If it does not find any fuses, it proceeds to the next step.

    • On all found insurance policies, the conversion of the VAT posting group will be performed in the same way as in the contract header:

      • VAT Prod. Posting Group (915, Code[20])=same value as Code From field

    • It continues to the client calendars of the found insurance policies in the API Ins. Client Payment Cal. (4027105) and on the unposted lines, i.e. the value of the field Posted (80)=N, it performs an update:

      • VAT Prod. Posting Group (910) = VAT Prod. Posting Group (915) from the header of the policy

      • VAT % (915) = according to the VAT Bus combination. Posting Group a VAT Prod. Posting Group (standard)

      • VAT Amount (955) = recalculated according to the new VAT rate.

    • It continues to the insurance company calendars of the insurance policies found in the API Ins. Company Payment Cal. (4027106) and on the unblocked lines, i.e. the value of the field Blocked (70)=N, it performs an update:

      • VAT Prod. Posting Group (915) = VAT Prod. Posting Group (915) from the header of the policy

      • VAT % (950) = according to the VAT Bus combination. Posting Group a VAT Prod. Posting Group (standard)

      • VAT Amount (955) = recalculated according to the new VAT rate.

    • Once all fuses have been processed, proceed to the next step

  • if there is a Paym flag in the API Financing Contract Header (4026397) header. Calendar Is Tax Document (19032, Boolean)=Y, sets the value of the new Prn. VAT queue field to Y.

  • At the end of the contract processing, the task is performed:

    • deactivates existing contract variants by toggling their Calc. Variant Status on Inactive

    • Contract Payment Calendar Update:

      • if APICZ VAT Special Mode (4047500, Boolean)=Y in the contract header, it will recalculate the contract payment calendar (so-called recalculation branch). Note: these contracts have to be recalculated, the special VAT regime cannot be resolved in any other way.

      • if N, it will update the fields in the contract payment calendar without starting the financial calculator and setting the payment calendar (note: the reason is contracts with Contract Extension=Y):

        • VAT Posting Group Principal (310, Code[20]) - take from contract header if not empty in header

        • VAT Posting Group Interest (311, Code[20]) - take from contract header if not empty in header

        • VAT Posting Group Service (315, Code[20]) - take from contract header if not empty in header

        • VAT Posting Group Simple Ins. (318, Code[20]) - take from contract header if not empty in header

        • VAT Posting Group Simple Fee (319, Code[20]) - take from contract header if not empty in header

        • APICZ VAT P.Gr.Sp.Mode Non-Tax (4047560, Code[) - take from contract header if not empty in header

        • APICZ VAT Pos.Gr.Spec.Mode Tax (4047565, Code[20]) - take from contract header if not empty in header

        • VAT Principal (12, Decimal)

        • Amount VAT Interest (18, Decimal)

        • Amount VAT Insurance (21, Decimal)

        • Amount VAT Service (24, Decimal)

        • Amount VAT Simple Fee (422, Decimal)

        • Amount VAT Selling Price (3010, Decimal)

        • Amount Excl. VAT Aliquot (3020, Decimal)

        • APICZ VAT Base Special Mode (4047550, Decimal)

        • APICZ VAT Amount Special Mode (4047555, Decimal)

        • Amount (34)

        • Amount VAT Deposit (40, Decimal)

    • in the contract header updates the field values based on the values from the first non-posted regular payment in the contract GAC:

      • Annuity Excl.VAT

      • Services Excl. VAT

      • Insurance Excl. VAT

      • Simple Fee Excl. VAT

      • Payment Excl.VAT

      • Payment Incl.VAT

      • Deposit Including VAT (42, Decimal)

    • in these fields, sets the flags to Y:

      • Service - Updated (150, Boolean)

      • Insurance - Updated (151, Boolean)

      • Payments - Updated (152, Boolean)

      • Calculation Lines - Updated (153, Boolean)

      • Calc. Inputs - Updated (154, Boolean)

      • Annuity Updated (4047070, Boolean)

      • Insurance Input Updated (4047075, Boolean).

Entry in the history of contract changes

To create an entry in the API Contract Change History (4046858), it uses the following values:

  • Change Type Code = Contract Change Type z request form

  • Approved By = ID of the user who runs the task

  • Approval Date = System Work Date

  • Change Reason Code = Contract Change Reason z request form

  • Change Valid From = system work date

  • Change Date = Date To from the last posted payment (Posted=Y, Canceled=N, Aliqout Payment=N, Recalculation Settlement=N, Partial Payment Credit=N)

  • Comment = Comment from request form

  • Closed (15)=Y (so that approval is required for the transfer)

  • Upon completion, it creates an entry in the Contract Change Log with Recalculation Result=Success.

 

Starting a task via the job queue, the Schedule... button, the Contract Change Queue and the Contract Change Log are described in PD https://iao.atlassian.net/wiki/x/jADVAQhttps://iao.atlassian.net/wiki/x/nADVAQ https://iao.atlassian.net/wiki/x/wADWAQ.

Example of logs for this task: