/
Mass Contract Services Change On Active Contracts

Mass Contract Services Change On Active Contracts

Owned by Lango: Language and translation manager
Last updated: Feb 04, 2025Version comment
20 min read

Mass changes to some services On active contracts (including auto-renewal contracts) is done via the Contract Services Change function, which can be found in the viewfinder or from the relevant Role Center via the Changing menu.

Changes will always be made to the change copy of the contract in such a way that if the contract is processed, a change copy will be created on it, it will be recalculated, then this change copy will be included in a special queue (Contract Change Queue). Then the user has the option to check, transfer or delete these change copies in bulk – due to the complexity of the change process, we recommend it only to tested users.

After clicking, a dialog window opens (API Contract Services Change (4026638, Report) for specification of the performed task or contracts)

Options section:

  • Change Type

    • The user manually selects what type of action he wants to perform

    • The field contains the following values: Add To Queue, Terminate, Reprice, Replace, Add:

      • switching to Replace unlocks the New Service Code field to edit

      • switching to Reprice and/or Replace unlocks the Keep Correction field for editing

    • Informative description (see below for detailed description):

      • Add To Queue

        • It creates change copies for the found contracts and adds them to the contract change list (Contr. Change Queue List code is selected by the user). The user can then change the individual agreements manually.

      • Terminate

        • Terminates the service on the last day of the last posted period.

      • Reprice (Reprice)

        • Makes a change in the price of the service. A typical situation is that there is a change in the price of the service. The user terminates the validity of the original rate in the given price list, creates a new rate and runs this task.

        • The original service is terminated (as in the case of Terminate) and a new one is created from the 1st day of the following unposted period.

      • Replace

        • terminates the original service and creates a new service with a different service code (e.g. replacing the MID of the replacement vehicle to HIGH)

      • Add

        • It will add a new service to contracts valid from the 1st day of the next payment period.

  • Service Kind

    • The field contains the following values, such as on a contract or in the services of a financing product.

    • Mass change can only be made for service type:

      • Replacement Car

      • Road Tax - only for CZ / SK

      • Highway Ticket

      • Fee/Service Service (Fee/Service)

If the user selects a different type of service, then he will receive an error message:

image-20240621-084507.png
image-20240621-084521.png

Changing the service kind clears the Service Type Code and Service Code values.

  • Service Type Code

    • The user manually selects the service type code of the service being edited, looks up to API Service Type (4026705) with filter to Service Kind

    • Changing the value erases the value in Service Code

    • Mandatory field for Replacement Vehicle, Highway Sticker and Fee/Service (see post-launch checks below)

    • Blank and non-editable for Road Tax

  • Service Code

    • Blank and non-editable for Road Tax

    • For other types of services, the user manually selects the service code of the service to be modified, looking into the relevant price list:

      • For Service Kind=Replacement Car:

        • API Repl. Vehicle Pricelist (4026655)

      • For Service Kind=Highway Ticket:

        • API Highway Ticket Pricelist (4026653)

      • For Service Kind=Fee/Service:

        • API Fee and Service Pricelist (4026651)

    • The relevant price list will always open with the following filters:

      • Service Type Code Same

      • Valid From<=workday system<=Valid To (can also be empty), i.e. it is possible to select only a valid service

    • Mandatory field (see post-launch checks below)

  • New Service Code

    • Editable only for Change Kind=Replace and if Service Kind<>Road Tax is

    • The user manually selects the service code of the new service to replace the original service. Lookup to the relevant price list:

      • For Service Kind=Replacement Car:

        • API Repl. Vehicle Pricelist (4026655)

      • For Service Kind=Highway Ticket:

        • API Highway Ticket Pricelist (4026653)

      • For Service Kind=Fee/Service:

        • API Fee and Service Pricelist (4026651)

    • The relevant price list will always open with the following filters:

      • Service Type Code Same

      • Valid From<=workdate system<=Valid To (can also be empty), i.e. it is possible to select only a valid service

  • Contr. Change Queue List Code (Contr. Change Queue List Code)

    • Editable for every type of change

    • The user selects the code of the change queue into which he wants to include the created change copies of contracts after the change has been processed.

    • Lookup do API Contr. Change Queue Batch (4046846)

    • Mandatory field (see post-launch checks below)

    • Recommendation:

      • For each task run, we recommend that you create a new contract change sheet, so that the team can more easily identify the changes made by the task

  • Keep Correction

    • Default N

    • Editable only if Change Type=Reprice and/or Replace and if Service Kind<>Road Tax is

    • In these types of changes, the system creates a new service by copying so. Then, in the case of N, any correction in the daily service is deleted, in the case of Y, the value of the correction from the original service is preserved.

  • Contract Change Type

    • The user selects the contract change type code, which will then be written to the Contract Change History (Change Code field)

    • lookup to API Contract Change Type (4046856)/API Contract Change Types (4046856, List) with filter:

      • Object ID wizard (15)=empty (i.e. we do not allow to select a change that is triggered by the wizard)

  • Contract Change Reason

    • New Field, Code 10

    • the user selects the reason code for the contract change, which will then be written to the Contract Change History (Reason Code field)

      • lookup do API Contract Change Reason (4046857)/API Contract Change Reasons (4046857, List)

  • Comment

    • new field, Text 120

    • empty by default

    • the user adds a text note, which is then written by the task into the Contract Change History (Comment field).

Filter: Financing Contract Header section

In this section, the user can set filters above all fields of the financing contract header, some of which are pulled out 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

  • No. (No.)

    • 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 button +Filter.

The general principles of filtering in Business Central are described here:

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

The task also has fixed filters for the contract header – only contracts that meet:

  • Financing with Services=Y

  • Calc.Variant=N

  • Change Copy=N

  • Change Copy Exists=N

  • Status=Active

When setting 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 a user filter e.g. to Status=Closed, contracts in this status 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, runs interactively (displays possible messages) under the given user. If the task is started by a button Schedule..., the execution itself is performed via the job queue (scheduler) – the messages are suppressed, or after starting, it is no longer necessary for the user to be logged in (description below).

When the task starts, it performs the following steps:

  • If a combination of Change Type=Replace and Service Kind=Road Tax has been entered in the request form, it displays the message "Road Tax cannot be replaced." and does not continue. If it is triggered :

    •  

    • When starting via Schedule... sa hláška nezobrazí. The system stops the job (Status=Error) and writes an entry to the Error Messages of the job in Job Queue Entries (it can be opened via the Show Error button from Job Queue Entries):

      •  

  • Checks if the Contr.Change Queue List Code is filled in for all Change Type (pre-team this check was only for Add To Queue):

    • if it is not filled in, it displays an error message and does not continue (when running via Schedule... the message is suppressed):

    • When starting via Schedule... sa hláška nezobrazí. The system stops the job (Status=Error) and writes an entry to the Error Messages of the job in Job Queue Entries (it can be opened via the Show Error button from Job Queue Entries):

    • if it is filled in, it continues

  • To check if the Contract Change Type is filled in for all Change Type:

    • If it is not filled in, it displays an error message and does not continue: "Contract Change Type must be entered. EN: Contract Change Type must be entered."

    • Note: The Contract Change Code is mandatory for creating a change copy

    • When starting via Schedule... sa hláška nezobrazí. The system stops the job (Status=Error) and writes an entry to the Error Messages of the job in Job Queue Entries (it can be opened via the Show Error button from Job Queue Entries).

  • If Service Type Code and/or Service Code is empty, it displays an error message and does not continue:

    • When starting via Schedule... sa hláška nezobrazí. The system stops the job (Status=Error) and writes an entry to the Error Messages of the job in Job Queue Entries (it can be opened via the Show Error button from Job Queue Entries).

  • If Change Type=Replace, it checks to see if the New Service Code is filled in:

    • if not, it displays an error message and does not continue: "New Service Code must be entered."

      • When starting via Schedule... sa hláška nezobrazí. The system stops the job (Status=Error) and writes an entry to the Error Messages of the job in Job Queue Entries (it can be opened via the Show Error button from Job Queue Entries).

    • If it is, it continues to be filled.

  • If all checks are error-free, the job runs and iterates through the funding contract headers. Searches for contracts through fixed filters (goes through contracts that have):

    • Financing with Services=Y

    • Calc.Variant=N

    • Change Copy=N

    • Change Copy Exists=N

    • Status=Active

    • despite the filters that have been entered by the user in the Filter section: Financing Contract Header

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

    • Filters:

      • Financing Contract No. (1)=same

      • Type (6)=Payment

      • Aliqout Payment(810)=Y

    • If it exists, the check is posted, i.e. Posted=Y:

      • 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 writes it into the Contract Change Log:

        • does not create a change copy

        • 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 the existence of the RS line (see below).

    • If there is no aliquot payment (Handover Date=1st day in the month), it continues to check the properly posted payment.

  • It will then check the found contracts to see if the contract has at least one posted regular payment in the API Financing Contract Line (4026398) payment calendar:

    • Financing Contract No. (1)=same

    • Type (6)=Payment

    • Down Payment Line (19307)=N

    • 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 and before the first regular payment is posted), then this contract is not processed or it is written into the Contract Change Log:

      • does not create a change copy on it

      • 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 payment.)

      • Continues to the next contract.

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

  • It then checks the found contracts to see if the contract has an unposted RS (Recalculation Settlement) payment in the API Financing Contract Line (4026398) payment calendar:

    • Financing Contract No. (1)=same

    • Type (6)=Payment

    • Aliqout Payment(810)=N

    • Recalculation Settlement (3045)=Y

    • Partial Payment Credit (3055)=N

    • Posted (50)=N

    • If such a payment exists (i.e. the contract is after recalculation and before posting the RS payment and the first payment after recalculation), then it does not process this contract or writes it into the Contrac Change Log:

      • does not create a change copy on it

      • writes the contract to the Contract Change Log with Recalculation Result=Fail and Error Detail=Unposted recalculation settlement exists. (EN: There is an unposted recalculation settlement.)

      • Continues to the next contract.

    • If there is no such payment, it continues.

  • It will then check the found contracts to see if there is an unposted regular payment for the given contract in the API Financing Contract Line (4026398) payment calendar:

    • 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 this contract will not be processed or it will be recorded in the Contract Change Log:

      • does not create a change copy on it

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

      • Continues to the next contract.

    • If such an installment exists, it continues.

  • If Change Type<>Add is, it checks if there is a Service for the found contract according to the filters specified by the user (for Service Kind<>Road Tax: Service Kind, Service Type Code, Service Code. For Service Kind=Road Tax only Service Kind) and at the same time:

    • Service Status=Active

    • Valid From<=workday<=Valid To After Extension

    • If such a Service does not exist for the contract and Service Kind=Road Tax has not been selected in the request form, the error is logged with Result=Error, Error Detail="There is no service .. code... with type ... type code... At.. date." and continues to the next contract. If Service Service Kind=Road Ta a taka does not exist in the contract has been selected, the Error Detail reads "There is no service with Road Tax at...".

    • If such a Service exists, the system checks whether there is a posted Service in the month Workdate for the service in the payment schedule of the service:

      • Service No. = Same

      • Posted = Y

      • Period From<=workday<=Period To

    • if such a payment does not exist, the contract is logged with the error Result=Fail, Description=Second modification of the same service in the same month is not posssible. EN: A second modification of the same service in the same month cannot be performed. It does not process the contract any further, it continues to the next contract.

      • If such an installment exists, it continues.

  • If Change is Type=Add, it checks for the found contract whether Service exists according to the filters specified by the user

    • Service Kind of request form

    • Service Type Code from request form (not for Service Kind=Road Tax)

    • Service Code from request form (not for Service Kind=Road Tax)

    • Status=Active and

    • Valid From<=workday<Valid To After Extension

    • If such a Service exists, it logs an error with Result=Fail and Error Description=Identified service still exists. EN: The identification Service already exists.

    • If such a Service does not exist, it proceeds to create a change copy.

  • Then he proceeds to create a change copy:

    • The principle is that the task will not work with the original contracts, but will create change copies for it and work with it.

    • The system creates a change copy for a found contract that meets all the above checks as follows:

      • does not open wizard to create change copy/variant API Change Contract Wizard (4046862, NavigatePage)

      • When processing the contract, it displays the message: "Working on it... Contract..."

      • When creating a change copy, the following values (field names from the wizard) will be used to create an entry in the API Contract Change History (4046858):

        • Contract Change Process = Change Copy

        • 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)

      • updates the value of Reference Date (4047010) = system work date in API Financing Contract (4026396, Card) on the change copy

      • The change copy is included in the Contract Change Queue List and the Mass Change field is switched to Y. To write to the Contract Change Queue, it calls the existing function for creating a row, which is also used in the Contracts with Outrange Odometer Status report.

      • On the change copy, it will perform processing according to the Change Type.

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

Change copy processing according to Change Type:

  • Change Type=Add To Queue:

    • It just creates a change copy as described above and puts it into the Contract Change Queue List table without further processing.

    • When the process is complete, it just displays the message "x Contract(s) inserted into the queue.":

  • Change Type=Terminate:

    • traces Date To from the last posted payment (Posted=Y, Canceled=N, Down Payment Line=N, Recalculation Settlement=N, Partial Payment Credit=N).

      • if it does not find one, it ends with an error, which is written into the Contract Change Log. Note: this should not happen. This is a duplicate check with a check for the existence of at least a posted aliquot payment.

    • Then it looks for a service that has:

      • If Service Kind<>Road Tax has been selected in the request form:

        • Service Code= same as entered in the request page and

        • Valid To After Extension > Date To from the last posted payment.

      • if it does not find one, it ends with an error, which is written into the Contract Change Log.

        • Note: This should not happen. Duplicitná kontrola s kontrolu pre Change Type<>Add na existenciu služby.

      • If it finds such a service, it fills in the following information on the service it finds:

        • in Contract Services, add Valid To=Valid To after Extension = Date To from the last posted regular payment

        • according to the posted lines of the service payment calendar, then fill in the Invoiced Amount Excl.VAT as the sum of Amount without aliquot payment

        • proceeds to calculate the Invoiced Payments Margin:

          • filters the posted rows of the service's payment calendar (Posted=Y and Aliquot Payment=N)

          • It goes through them and stores the difference from each line (Amount-Cost Amount) in the variable.

          • the resulting (sum) value is entered into the Invoiced Payments Margin (160) field in Contract Services and Margin Total (85)

          • Writes the sum of the Cost Amount to the Purchase Price Total Excl.VAT

        • Continue in Contract Services:

          • fills in Calculation Amount Total = Invoiced Amount Excl. VAT

          • sets Service Status=Terminated

          • Recalculates the payment schedule of the stopped service.

      • If Service Kind=Road Tax has been selected in the request form:

        • finds services with Service Kind=Road Tax. Then:

        • Invalid services will not be processed by:

          • Valid To after Extension<Date To from the last posted payment

        • Processing of the currently valid service:

          • Valid From<Date To from the last posted payment<Valid To after Extension (currently valid Service)

        • if it does not find one, it ends with an error, which is written into the Contract Change Log.

          • Note: This should not happen. Duplicitná kontrola s kontrolu pre Change Type<>Add na existenciu služby.

        • If it finds such a service, it fills in the following information on the service it finds:

          • in Contract Services, add Valid To=Valid To after Extension = Date To from the last posted regular payment

          • according to the posted lines of the service payment calendar, then fill in the Invoiced Amount Excl.VAT as the sum of Amount without aliquot payment

          • calculation of invoiced margin (Road Tax has no margin)

          • Continue in Contract Services:

            • fills in Calculation Amount Total = Invoiced Amount Excl. VAT

            • sets Service Status=Terminated

            • Recalculates the payment schedule of the stopped service.

        • Processing of future services (I can exist if Service Road Tax was created according to discount bands):

          • Valid From > Date To From Last Posted Payment

          • If services also exist, delete them in:

            • Contract Services

            • Their Detail

            • their repayment schedules.

  • Change Type=Reprice

    • termination of the service as for Terminate above, including the calculation of the payment schedule of the terminated service

    • Service Kind=Road Tax:

      • To create a new service, it calls the same function as for manually creating a service without opening the calculation window (i.e. it searches for the currently valid service code in the price list, the rate, discounts, creates a service, detail, payment calendar for services, etc.).

      • adds Service Type Code from Contract with Services Setup to the service (not from request form)

    • Service Kind<>Road Tax:

    • creates a new service in Contract Services by copying the terminated service. On this new service, they set:

      • Service Status=Preparation

      • Valid From = date on which the original service was terminated +1D

      • Valid To = Valid To after Extension = Expec. Term. Date after Ext. (10105) from the contract header.

    • After creating a new service, they also create a service detail:

      • Service Kind = Replacement Car:

        • The new detail is copied from the detail of the original service

        • updates Service No, Service No, and Service Code

        • By validating Service Code, the API Repl. Vehicle Pricelist (4026655) according to Service Code will be taken over:

          • Replacement Car Type

          • Replacement Car Description

          • Make Code (hidden field)

          • Model Line Code (Hidden Field)

          • Model Code (Hidden Field)

          • Vendor No.

          • Vendor Name

          • Note (hidden field)

          • Contracting Days Per Year

          • Contracting Days Per Duration is recalculated according to the duration of the service

        • furthermore, according to the Service Code, valid values (Valid From<=Reference Date from the contract header<=Valid To can also be empty) are taken from the API Replacement Vehicle Rate (4047003)

          • Customer Price Excl.VAT (LCY) in detail = Fee Amount Excl.VAT (LCY)

          • Purchase Price Excl.VAT (LCY) in detail = Purchase Price Excl.VAT (LCY)

            • Note: if it finds a zero value in the rates, it will fill that value as well. They recommend that you check the applicable rates before running the job.

        • revalidates the Correction field (+-%), which calculates the fields with amounts on the detail. If the Keep Correcion value was:

          • N - deletes the existing correction (sets the value to 0)

          • Y - Retains the existing correction.

        • calculates the payment calendar of the new service

      • Service Kind = Highway Ticket:

        • The new detail is copied from the detail of the original service

        • updates Service No, Service No, and Service Code

        • By validating the Service Code, the following are taken from the API Highway Ticket Pricelist (4026653) according to Service Code:

          • Country/Region Code

          • Highway Ticket Type

          • Description

        • Furthermore, according to Service Code, valid values (Valid From<=Reference Date from the contract header<=Valid It can also be empty) are taken from the API Highway Ticket Rate (4047004):

          • Value Excl.VAT (LCY) in detail = Fee Amount Excl.VAT (LCY)

          • Purchase Price Excl.VAT (LCY) in detail = Purchase Price Excl.VAT (LCY)

            • Note: if it finds a zero value in the rates, it will fill that value as well. They recommend that you check the applicable rates before running the job.

        • Depending on the validity of the new service, it calculates the number of vignettes. If it gets a non-zero value, it writes it in detail in the Quantity field, otherwise it writes the value from the original detail.

        • revalidates the Correction field (+-%), which calculates the amount fields. If the Keep Correction value was:

          • N - deletes the existing correction (sets the value to 0)

          • Y - Retains the existing correction.

      • Service Kind = Fee/Service:

        • The new detail is copied from the detail of the original service

        • updates Service No, Service No, and Service Code

        • By validating the Service Code, the following are taken from the API Fee and Service Pricelist (4026651) according to Service Code:

          • Vendor No.

          • Fee Period

          • Premium Fee

        • furthermore, according to the Service Code, valid values (Valid From<=Reference Date from the contract header<=Valid To can also be empty) are taken from the API Fee and Service Rate (4047002)

          • Fee Amount Excl.VAT (LCY) in detail = Fee Amount Excl.VAT (LCY)

          • Purchase Price Excl.VAT (LCY) in detail = Purchase Price Excl.VAT (LCY)

            • Note: if it finds a zero value in the rates, it will fill that value as well. They recommend that you check the applicable rates before running the job.

        • On the service detail, it validates the fields Purchase Price Excl.VAT (LCY) and Correction (+-), which calculates the fields with amounts. If the Keep Correcion value was:

          • N - deletes the existing correction (sets the value to 0)

          • Y - Retains the existing correction.

  • Change Type=Replace

    • for Service Kind=Road Tax, this option is disabled. For other services, it proceeds as described below.

    • termination of the service as for Terminate above, including the calculation of the payment schedule of the terminated service

    • creates a new service in Contract Services by copying the terminated service. On this new service, they set:

      • Service Status=Preparation

      • Service Code = New Service Code from request page

      • Valid From = date on which the original service was terminated +1D

      • Valid To = Valid To after Extension = Expec. Term. Date after Ext. (10105).

    • creating a new detail in the same way as for Reprice (including keeping/not keeping the correction), the only difference is that the new service detail will be created with the service code already with the New Service Code from the request page

    • Depending on the validity of the new service, it calculates the number of vignettes. If it gets a non-zero value, it writes it in detail in the Quantity field, otherwise it writes the value from the original detail.

    • calculation of the service payment schedule in the same way as for Reprice

  • Change Type=Add

    • traces Date To from the last posted payment (Posted=Y, Canceled=N, Down Payment Line=N, Recalculation Settlement=N, Partial Payment Credit=N).

      • if it does not find one, it ends with an error, which is written into the Contract Change Log. Note: this should not happen. This is a duplicate check with a check for the existence of at least an accounted aliquot or regular payment.

    • If Service Kind=Road Tax:

      • as described for Reprice

    • If Service Kind<>Road Tax, it proceeds as described:

    • Creates a new service in Contract Services for the given Service Kind, Service Type Code, and Service Code. On this new service, they set:

      • Service Status=Preparation

      • then validates the Contract No. field, the team populates with the field:

        • Curr.Exchange Rate Date

        • Currency Exchange Rate

        • Currency Code

        • Gen.Bus.Posting Group

        • VAT. Bus.Posting Group

        • Service Payment Period

        • Valid From = Date To of Last Posted Payment +1D

        • Valid To = Valid To after Extension = Expected Termination Date from the contract header. This fulfillment will be adjusted by adding Expec. Term. Date after Ext. (10105).

      • then invokes Service Kind, this causes:

        • if Service is Kind<>Fee/Service, populate Reflect Aliquot=N

        • if Service is Kind=Road Tax or Highway Ticket, it fills Reinvoice=N. For other services, it will always be N, because the default value of the flag is N.

      • then validates the Service Type Code, which causes:

        • filling in fields Gen. Prod. Posting Group and VAT Prod. Posting Group from the Service Type code list

        • It then validates the Service Code field with the value specified by the user. This causes:

        • populating the Reflect Aliquot and Full Aliquot Payment fields for the Fee/Service service from the fee pricelist

      • After creating a new service, the service detail will also be created using the same functionality as in the case of manual creation via the Detail button:

        • Rates search for Reference Date

        • Correction (+-%) fills from the Default Serv field. Corr. (Perc.) from Contract Services and because this is zero, the value will be zero on the detail.

          • Note: it is therefore true that the system does not look at the product/template services when they are created, so that there is no need to create a new service into the products/template. This means that the values that are normally taken from the product will be empty (e.g. Reinvoiced, Charge, ... Default Correction, etc).

      • Calculation of the payment calendar is the same as above.

  • If Change Type<>Add To Queue is, at the end of the contract processing, the task executes:

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

    • Deploys amounts from service calendars to SPL. Contract calendars (without running the financial calculator)

    • 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

    • based on the values from the first unaccounted regular payment in the T&Cs of the contract.

    • after processing the change copy from the change copy, add New Payment Excl.VAT

    • creates an entry in the Contract Change Log (see below)

    • displays the message "The change has been made in X contract(s). There was an error in the Y contract(s)."

Subpages: