Basic Entities Migration

Basic non-support functionality for simplified migration of financing contracts is located in the Role Center OneCore – Migration.

Current content of the Role Center:

Features and overviews are described later in the individual chapters.

Migration of basic entities involves importing data from the original information system (if the data has been previously processed in this system).

This applies in particular to the following data regions:

• Contacts and customers

• Financing Contracts and Their Particulars

• Opening Balances of Financial Records

There are 2 basic methods, the choice of which depends on the number of records of each entity and the availability of data.

The methods are:

• Manual Entry

• Migration using RapidStart resources (Configuration Packages)

Create Calculation/ Contract

If migravane contracts are entered into a new system manually, OC allows you to create a contract (i.e. not an offer, but a contract) with a manually entered (existing) number. This option exists only for contracts without services.

A contract can be created using the Create Calculation/Contract Wizard.

The Contract No. field is released to enter a manual contract number under the following conditions:

• Type=Contract (i.e. it is not possible to create a calculation with a manual number)

• Financing Product No. = the financing product contains a Financing Template with a Financing Model that has the Contract Numbering set so that the Number Series has Default Numbers=N.

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

• If the user does not fill in the Contract No. and confirms the Next button, the OC will display a message that the Contract No. cannot be empty.

• If the user fills in the Contract No. and confirms the Next button, the OC will check whether there is a contract (calculation) with the entered number in the system. If it exists, it will display a message that the contract number already exists.

• If the checks are passed, the user continues to create the contract as usual, in steps 2/3 and 3/3 there is no special setting for migrated contracts.

Contract Card and Contract Activation

If the contract was created with a financing product that had the Migrated Contract flag set, the contract will have the same flag.

If the contract has been activated and flags have been set on the Contract Financing Product:

• Don't Post Down Payment on Activation (Down Payment Posting Blocked) = A

• Don't Allow Initial Fee Posting Blocked on Activation (Initial Fee Posting Blocked) = A

As part of the activation, the OC does not post a down payment or entry fee (an essential requirement for migration).

If an Instalment Sales contract has been activated and flag has been set on the Contract Financing Product:

• Do Not Post Invoice to SP on Activation (IS Invoice Posting Blocked) = A (for Financing Type = Instalment Sale)

(or also Don't charge the entry fee during activation), the OC will not post an invoice for installment sale (or the entry fee) as part of the activation.

Note: copying of migrated contract is forbidden due to Default number=N – it is not possible to enter a manual number when copying.

Contract migration using RapidStart

An alternative to creating "migrated" contracts manually is to use the Rapid Start functionality resources – Configuration Packages.

Configuration packages are a universal means of importing data from other systems/manually prepared into the BC system through data stored in XLSX (Excel) tables.

To use this procedure, you must have completed the System Setup and the use of settings data in migrated data.

To process data import using Configuration Packages, follow these steps:

• Create a list of BC tables to migrate using packages

• To create packages in BC:

  • Table Input

  • Definition of the fields that will be migrated

  • Defining the Field Order

  • Definition of validations (whether the field should be validated by standard BC functions)

Recommendation: split the tables with migrated data into multiple packages according to data traceability; Each table is a separate worksheet in Excel

• To test packages:

  • Create an Excel spreadsheet format for your data (Export to Excel)

  • Populating an Excel spreadsheet with data from migrated contracts (data samples are sufficient for the first tests)

  • Import data from an Excel spreadsheet into BC internal structures for configuration package data

  • Process data into BC tables where migrated data is uploaded

  • Analysis of possible errors from import processing

  • Checking and testing data in the BC environment

  • Data processing if required by the process required to use the migrated region (e.g., posting General Journals with imported initial posting status data).

Recommendation: Define UAT (User Acceptance Test) tests over migrated data and these UAT regulations to manage testing of migrated data.

• Processing of the migration itself – preparation and processing of all prepared and pre-tested data sets to populate the database with the data necessary to start routine operation (go-live).

Note: the order of the fields in the package also determines the order of the fields when entering values into the migrated record in the table. The order is dependent on the internal logic of validations, if they are used. Which fields to validate and in what order to import them into a table record is part of the process of debugging and testing the package, as it is not entirely clear how to combine:

• Business specifics of the customer (what Types of financing are used, etc.)

• What data is available from the original system 

• how they are compatible with the BC data model

• in what order to import individual tables and ensure continuity between them (relations, "foreign" keys, etc.)

Example migration using configuration packages:

Note: This setting is available in the database with the client's web address https://onecore-test-cz.iao.seyfor.com/BC/ (information as of 15.10.2022) and individual packages are exported including a sample Excel table in the following directories:

File Type	Directory	Note
Exported Configuration Package	Open	Status as of 15.10.2022
Exported Excel file	Open	Status as of 15.10.2022

Note 2: under certain circumstances (e.g. changes in the table), the order of columns in the field list of the migrated table may be changed – the changed request is renumbered according to the sequential field numbers; The order is is an integral part of the package definition and must be used exactly as defined in the package, or in the Excel spreadsheet that was created from the package, and not according to this default setting.

This issue can be resolved by exporting and importing the config package table fields using a different config package for table no. 8616 Config. A Package Field that can be used to export and import content to maintain the order.

Payments Recalculation

A batch job is available to check the amount of the payment after recalculation of migrated contracts Recalculation of Migrated Contracts (API Migr. Recalc. Batch (4046953). This task allows you to check the amount of contract payments after importing the contract data using standard recalculation.

Role Center: OneCore - Migration

• A prerequisite for running the task is that the status of the contracts after import allows for recalculation of the contract (e.g. contracts are in the Signed status). The program skips independently of the specified contract filter, where Status >=Active.

• The task performs the Payment Calculation function on the selected contracts and saves the result in the contract header, where the amounts can be checked on the contract card on the Calculation tab after the end of the run.

• In the event of an error occurring over the migrated data, a record of the occurrence of the error is made in the Recalculation Error Log (API Recalculation Error Log (4046810)), which is also recorded in the case of successful recalculation.

Note: Due to the fact that the recalculation will overwrite the fields on the contract header, which may have contained the original payment amounts from the migration, it is necessary to combine the original data (e.g. input data to migration) and the resulting data after recalculation when comparing the payment amount before and after the recalculation.

Batch Contract Activation

If a large number of contracts are the subject of migration and it would take too much time to activate them manually according to the chapter "Contract Card and Contract Activation" manually, a batch job is available for contract activation Migrated Contracts Activation (API Migr. Cont. Batch Activ. R 4046952).

Role Center: OneCore - Migration

• A prerequisite for running the task is that the status of the contracts after import allows the contract to be activated according to the settings of Detailed Contract Statuses and their sequences.

• The task for the selected contracts activates the contract and writes the result (successful or with error) to the Migrated Contract Processing Log (API Migr. Cont. Batch Log (4046951)).

Example of a log:

Open

Once activated, the contracts are ready to be processed.

Note:

If the contract has been activated and the following flags have been set on the Contract Financing Product:

• Don't Post Down Payment on Activation (Down Payment Posting Blocked) = A

• Don't Allow Initial Fee Posting Blocked on Activation (Initial Fee Posting Blocked) = A

The OC will not charge down payments or the entry fee as part of the activation.

If an Instalment Sales contract has been activated and flag has been set on the Contract Financing Product:

• Do Not Post Invoice to SP on Activation (IS Invoice Posting Blocked) = A (for Financing Type = Instalment Sale)

(or also Don't charge the entry fee during activation), the OC will not post an invoice for installment sale (or the entry fee) as part of the activation.

Marking Payments as Posted

If, after migrating contracts in different periods of the contract life, you need to set up the history of the contract calendars so that processing can start with the 1st period after the migration date, you must set up the payment calendar and related contract calendars so that the historical payments are marked as posted (flag Posted (Posted) = Yes). Without this setting, you can't start posting the first payment after the migration date. This setting also includes the assignment of Document No. (API Financing Contract Line (4026398)).

There are 2 ways to set it up:

• Interactively in the contract payment schedule form (see further description in this chapter)

• Batch based on pre-prepared data (chapter BATCH TO MARK PAYMENTS AS POSTED)

To interactively mark payments as posted:

If the Migrated Contract=A flag is in the contract, the Mark Payments as Posted button will be visible on the Contract Payment Calendar form:

The user then marks the necessary payments and presses the Mark Payments as Posted button. Subsequently, the OC will carry out the following checks:

• Migrated Contract (800)) = A

• Change Copy (107)) = N, and at the same time

• field Change Copy Exists (105)) = N, and at the same time

• field Calculation Variant (20000)) = N, and at the same time

• Status (18) field >= Effective, and at the same time

• if the Termination Date (19035) field is filled in on the contract: the From Date (28) field on the last selected payment is =< Termination Date

• A payment with a higher Part Payment No. (2) must not be marked without all previous payments with a lower number being marked

• a payment with an OPosting Date (4)) higher than the Migration Date (800)) (the last day before GOLIVE) must not be marked from OneCore Settings (see data model for new field); field Posting date at the same time must not be empty!

• If the function is run on an already marked line (reverse), then:

• it must not be the line where the document was actually posted (there is a posted sales invoice with a document number); for this purpose, the Cancel function is

• the flag must not be cleared so that the Posted flag remains set on any of the payments

• On the other hand, the Post in installment / batch jobs function for posting payments will be blocked for lines with Posting date <= Migration date (last day before GOLIVE) from OneCore Settings.

If even one condition is not met, the OC displays a message that it is not possible to perform the marking and stops the process.

If all the conditions are met, the OC will add the following on the marked instalments:

• Document No. (9) = according to the document number creation setting from the API Financing Model (4026416) table for the contract, the Part Payment Document (80) field

• Posted (50))=A

At the same time, the system marks as posted the related:

• Calculator Lines Posted (Posted (110)) = AND (according to the function MarkCalculationLinesAsPosted from CU 4046890)

• Client Insurance Calendar Lines Posted (Posted (80) = A (according to the MarkInsuranceAsPosted function from CU 4046890)

• Contract accrual lines linked to this payment (CZ contract lines for the contract that have the same Contract Payment No. (40)) as the marked payment, flag Posted (60))); at the same time, fills in the Document No. (75)) from the number series of documents on the Contract Financing Model intended for the numbering of Contract Accrual Lines (Contract Accrual Line Posting Nos. Accrual Line Post. Nos. (4026850)))

• Calculation input accrual lines linked to this payment (CZ CI lines for a given contract that have the same Contract Payment No. (40)) as the marked payment, flag Posted (55)))

Marking Calculation Inputs as Posted

• Addition of the Mark as posted / unposted button

• On the Contract Overview – Calculation Inputs form, a new button (option) Mark as posted / unposted has been added. OC after pressing the button under the conditions that the contract is in a status higher than or equal to the status of Active, it is not a change copy or there is no change copy for it, and Calculation Enter Date is less than or equal to the working date:

  • marks the calculation input(s) as posted (flag Calculation Input Posted (Field No. 19215 Calculation Input Posted) = Yes)

  • and according to the settings fills in the Document No. (19270 Document No.)

  • The button will be removed from the list of calculation inputs after the migration is complete