Page Comparison

Základní funkce ne podporu zjednodušené migrace smluv o financování jsou umístěny v centru rolí OneCore – migrace (OneCore – Migration).

Aktuální obsah centra rolí:

Funkce a přehledy jsou popsány dále v jednotlivých kapitolách.

Migrace základních entit zahrnuje import dat z původního informačního systému (pokud data byla již dříve zpracovávána v tomto systému).

Týká se to zejména oblastí dat:

• Kontakty a zákazníci

• Smlouvy o financování a jejich náležitosti

• Počáteční stavy finanční evidence

Existují 2 základní metody, jejichž volba závisí napočtu záznamů jednotlivých entit a dostupnosti dat.

Metody jsou:

• Ruční vstup

• Migrace s použitím prostředků RapidStart (Konfiguračních balíčků)

Založení kalkulace/smlouvy (Create Calculation/ Contract)

Pokud se migravané smlouvy zadávají do nového systému manuálně, OC umožnuje založení smlouvy (tzn. ne nabídky, ale smlouvy) s ručně zadaným (existujícím) číslem. Tato možnost existuje pouze pro smlouvy bez služeb.

Smlouvu je možné založit Průvodcem vytvořením kalkulace/smlouvy.

Pole Číslo smlouvy (No.) je uvolněné k zadání manuálního čísla smlouvy za následujících podmínek:

• Typ=Smlouva (tzn. není možné založení kalkulace s ručním číslem)

• Číslo produktu financování = produkt financování obsahuje Vzor financování s Modelem financování, který má nastavenou Číselnou řadou smluv tak, že Číselná řada má nastaveno Výchozí čísla=N.

Po stisknutí tlačítka Další systém OC vykoná kontroly:

• Pokud uživatel nevyplní Číslo smlouvy a potvrdí tlačítko Další, OC zobrazí hlášku že číslo smlouvy nemůže být prázdné.

• Pokud uživatel vyplní Číslo smlouvy a potvrdí tlačítko Další, OC vykoná kontrolu, jestli v systému neexistuje smlouva (kalkulace) se zadaným číslom. Pokud existuje, zobrazí hlášku že číslo smlouvy již existuje.

• Pokud kontroly vyhovují, užívatel pokračuje v založení smlouvy bežným postupem, v kroku 2/3 a 3/3 již neexistuje speciální nastavení pro migrované smlouvy.

Karta smlouvy a aktivace smlouvy (Contract Card and Contract Activation)

Pokud smlouvy byla založena s produktem financování, který měl nastavený příznak Migrovaná smlouva, smlouva bude mít stejný příznak.

Pokud byla smlouva aktivována a na Produktu financování smlouvy byly nastaveny příznaky:

...

Neúčtovat akontace při aktivaci (Down Payment Posting Blocked) = A

...

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

OC v rámci aktivace nezaúčtuje akontaci resp. vstupní poplatek (zásadní požadavek pro migraci).

Pokud smlouva na Splátkový prodej byla aktivována a na Produktu financování smlouvy byl nastaven příznak:

...

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 (pro Typ financování =  Splátkový prodej)

(případně i Neúčtovat vstupní poplatek při aktivaci), OC v rámci aktivace nezaúčtuje fakturu na splátkový prodej (resp. vstupní poplatek).

Pozn: kopírování migrované smlouvy je zakázano kvůli Výchozí číslo=N – při kopírování není možné zadání ručního čísla.

Migrace smluv s použitím Rapidstart (Contract migration using RapidStart)

Alternativou k zakládání „migrovaných“ smluv ručně je použití prostředků funkcionality Rapid Start – Konfiguračních balíčků (Configuration Package).

Konfigurační balíčky představují univerzální prostředek pro import dat z jiných systémů / ručně připravených do systému BC prostřednictvím dat uložených v tabulkách formátu XLSX (Excel).

Předpokladem k použití tohoto postupu je dokončené nastavení systému a použití údajů z nastavení v migrovaných datech.

Zpracování importu dat pomocí Konfiguračních balíčků probíhá následujícím postupem:

• Vytvoření seznamu tabulek BC, které se mají migrovat pomocí balíčků

• Vytvoření balíčků v prostředí BC:

  • Zadání tabulky

  • Definice polí, která se budou migrovat

  • Definice pořadí polí

  • Definice validací (zda se má pole validovat standardními funkcemi BC)

Doporučení: rozdělit tabulky s migrovanými daty do více balíčků podle návaznosti dat; každá tabulka představuje v excelu samostatný list

• Testování balíčků:

  • Vytvoření formátu Excelové tabulky pro data (Export do Excelu)

  • Naplnění Excelové tabulky daty migrovaných smluv (při prvních testech postačí vzorky dat)

  • Import dat z Excelové tabulky do vnitřních struktur BC pro data konfiguračního balíčku

  • Zpracování dat do tabulek BC, kam se migrovaná data nahrávají

  • Analýza případných chyb ze zpracování importu

  • Kontrola a test dat v prostředí BC

  • Zpracování dat, pokud to vyžaduje proces pro použití dané migrované oblasti (např. zaúčtování Finančních deníků (General Journals) s importovanými daty počátečních účetních stavů).

Doporučení: definovat v rámci UAT (User Acceptance Test) testy nad migrovanými daty a těmito UAT předpisy řídit testování migrovaných dat.

• Zpracování vlastní migrace – příprava a zpracování všech připravených a předem otestovaných souborů dat pro naplnění databáze daty nutnými k spuštění rutinního provozu (go-live).

Poznámka: pořadí polí v balíčku stanovuje i pořadí polí při zadávání hodnot do migrovaného záznamu v tabulce. Pořadí je závislé na vnitřní logice validací, pokud jsou použity. Které pole validovat a v jakém pořadí je importovat do záznamu tabulky je součástí procesu ladění a testování balíčku, neboť není zcela jednoznačné, jakým způsobem zkombinovat:

• Businessová specifika daného zákazníka (jaké Typy financování používá atd.)

• Jaké údaje má k dispozici z původního systému 

• jak jsou kompatibilní s datovým modelem BC

• v jakém pořadí importovat jednotlivé tabulky a zajistit návaznosti mezi nimi (relace, „cizí“ klíče apod.)

Příklad migrace pomocí konfiguračních balíčků:

...

Název balíčku

...

Tabulky / tabulky obsažené

...

Datové entity

...

Poznámka

...

SIM_CONTACT

...

18  Customer

5050      Contact

5051      Contact Alt. Address

5054      Contact Business Relation

...

Zákazník

Kontakt

Adresa kontaktu

Vazba kontaktu a zákazník

...

• 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/ (informace k 15information as of 15.10.2022) a jednotlivé balíčky jsou exportovány včetně vzorové Excelové tabulky v adresářích:

...

Typ souboru

...

Adresář

...

Poznámka

...

and individual packages are exported including a sample Excel table in the following directories:

Poznámka Note 2: za určitých okolností (např. změny v tabulce) může dojít ke změně pořadí sloupců v seznamu polí migrované tabulky – změněné požadí se přečísluje podle pořadových čísel polí; pořadí je přitom neoddělitelnou součástí definice balíčku a musí být použito přesně podle definice v balíčku, resp. v Excelové tabulce, která z balíčku vznikla, a nikoliv podle tohoto výchozího nastavení.

Tento problém lze řešit pomcí exportu a importu polí tabulky konfiguračního balíčku pomocí jiného konfiguračního balíčku pro tabulku č. 8616 Config. Package Field, pomocí jejíhož exportu a importu obsahu lze pořadí zachovat.

Přepočet výše splátek (Payments Recalculation)

Pro kontrolu výše splátky po rekalkulaci migrovaných smluv je k dispozici dávková úloha Rekalkulace migrovaných smluv 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). Tato úloha umožňuje po importu dat smluv kontrolu výšky splátky smluv pomocí standardní rekalkulace.

Centrum rolí: OneCore - Migrace

...

Předpokladem spuštění úlohy je, že stav smluv po importu umožňuje rekalkulaci smlouvy (např. smlouvy jsou ve stavu Podepsaná). Program přeskakuje nezávisle na zadaném filtru smlouvy, kde Stav (Status) >=Aktivní.

...

Úloha provede na vybraných smlouvách funkci Výpočet splátky a výsledek uloží do hlavičky smlouvy, kde lze po skončení běhu částky zkontrolovat na kartě smlouvy na záložce Kalkulace.

...

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)), do kterého je proveden zápis i při úspěšném provedení rekalkulace.

Poznámka: Vzhledem k tomu, že rekalkulace provede přepis polí na hlavičce smlouvy, která mohla obsahovat původní částky splátky z migrace, je třeba v porovnání výše splátky před a po rekalkulaci kombinovat původní data (např. vstupní datat do migrace) a výsledná data po rekalkulaci.

Dávková aktivace smluv (Batch Contract Activation)

...

• 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. the migration input data) and the resulting data after the 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).

Centrum rolíRole Center: OneCore - Migrace

...

Předpokladem spuštění úlohy je, že stav smluv po importu umožňuje aktivaci smlouvy podle nastavení Detailních stavů smlouvy a jejich posloupností.

...

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

Příklad loguExample of a log:

...

Po aktivaci jsou smlouvy připraveny ke zpracování.

Poznámka:

Pokud smlouva byla aktivována a na Produktu financování smlouvy byly nastaveny příznaky:

...

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

• Neúčtovat vstupní poplatek při aktivaci Don't Allow Initial Fee Posting Blocked on Activation (Initial Fee Posting Blocked) = A

OC v rámci aktivace nezaúčtuje akontace resp. vstupní poplatek.

Pokud smlouva na Splátkový prodej byla aktivována a na Produktu financování smlouvy byl nastaven příznak:

...

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 (pro Typ financování =  Splátkový prodej)

(případně i Neúčtovat vstupní poplatek při aktivaci), OC v rámci aktivace nezaúčtuje fakturu na splátkový prodej (resp. vstupní poplatek).

Označení splátek za zaúčtované (Marking Payments as Posted)

...

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

Nastavení je možné 2 způsoby:

• Interaktivně v formuláři se splátkovým kalendářem smlouvy (viz další popis v této kapitole)

• Dávkově na základě předem připravených dat (kapitola BATCH NA OZNAČENÍ SPLÁTEK ZA ZAÚČTOVANÉ)

Interaktivní označení splátek za zaúčtované:

Pokud v smlouvě je příznak Migrovaná smlouva=A, na formuláři Splátkového kalendáře smlouvy bude viditelné tlačítko Označit splátky jako zaúčtované:

Uživatel pak označí potřebné splátky a stiskne tlačítko Označit splátky jako zaúčtované. OC následne provede kontroly:

...

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

• pole Změnová kopie (Change Copy (107)) = N, a zároveňpole Změnová kopia existuje (and at the same time

• field Change Copy Exists (105)) = N, a zároveňpole Varianta kalkulace (and at the same time

• field Calculation Variant (20000)) = N, a zároveňpole Stav (and at the same time

• Status (18) ) field >= Účinná, a zároveňpokud je na smlouvě vyplněné pole Datum ukončení (Effective, and at the same time

• if the Termination Date (19035) ): pole Od data (field is filled in on the contract: the From Date (28) ) na poslední označené splátce je =< Datum ukončenínesmí být označena splátka s vyšším Číslem splátky (field on the last selected payment is =< Termination Date

• A payment with a higher Part Payment No. (2) , aniž by byly označeny všechny předchozí splátky s nižším číslemnesmí být označena splátka se Zúčtovacím datem (must not be marked without all previous payments with a lower number being marked

• a payment with an OPosting Date (4)) vyšším než je Datum migrace (higher than the Migration Date (800)) (poslední den před the last day before GOLIVE) z Nastavení must not be marked from OneCore (nové pole viz datový model); pole Zúčtovací datum současně nesmí být prázdné!

• pokud se pustí funkce na již označený řádek (reverz), pak:

• nesmí se jednat o řádek, kde byl skutečně zaúčtován dokladem (existuje účtovaná prodejní faktura s číslem dokladu); na tento účel je funkce Storno

• nesmí se zrušit příznak tak, že na některé ze splátek zůstane příznak Zaúčtováno nastaven

• Funkce Účtovat na splátce / v dávkových úlohách pro účtování splátek bude naopak pro řádky se Zúčtovacím datem <= Datum migrace (poslední den před GOLIVE) z Nastavení OneCore zablokována.

Pokud nevyhovuje byť jen jedna podmínka, OC zobrazí hlášku že není možné provést označení a proces zastaví.

Pokud všechny podmínky vyhovují, OC na označených splátkách doplní:

• Číslo dokladu (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) ) = podle nastavení tvorby čísel dokladů z tabulky Model smlouvy o financování (= according to the document number creation setting from the API Financing Model (4026416) ) pro danou smlouvu, pole Doklad splátky (table for the contract, the Part Payment Document (80) )field

• Doplní Účtováno (Posted (50))=A

Současně systém označí jako zaúčtované související:

...

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

• Calculator Lines Posted (Posted (110)) = A (podle funkce MarkCalculationLinesAsPosted z CU 4046890)Řádky klientského kalendáře pojištění Účtováno AND (according to the function MarkCalculationLinesAsPosted from CU 4046890)

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

• Řádky časového rozlišení smlouvy svázané s touto splátkou (Řádky ČR smlouvy pro danou smlouvu, které mají stejné Číslo splátky smlouvy (Contract accrual lines linked to this payment (CZ contract lines for the contract that have the same Contract Payment No. (40)) , jako značená splátka, příznak Účtováno (as the marked payment, flag Posted (60))); současně doplní Číslo dokladu (at the same time, fills in the Document No. (75)) z číselné řady dokladů na Modelu financování smlouvy určených pro číslování Časového rozlišení smlouvy (Číselná řada účtování řádků časového rozlišení smlouvy (Contrfrom 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)))Řádky časového rozlišení kalkulačních vstupů svázané s touto splátkou (Řádky ČR KV pro danou smlouvu, které mají stejné Číslo splátky smlouvy (

• Calculation input accrual lines linked to this payment (CZ CI lines for a given contract that have the same Contract Payment No. (40)) , jako značená splátka, příznak Účtováno (as the marked payment, flag Posted (55)))

...

Marking Calculation Inputs as Posted

...

Doplnění tlačítka Označit jako zaúčtované / nezaúčtované

na formuláři Přehled – kalkulační vstupy smlouvy je doplněné nové tlačítko (volba) Označit jako zaúčtované / nezaúčtované. OC po stisknutí tlačítka za podmínek, že smlouva je ve stavu vyšším nebo rovném stavu Účinná (aktivní), není to změnová kopie ani k ní změnová kopie neexistuje a Datum vstupu do kalkulace je nižší nebo rovné pracovnímu datu:

...

• 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) = Ano)a podle nastavení doplní Číslo dokladu (č.pole Yes)

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

  • tlačítko bude po dokončení migraci z přehledu kalkulačních vstupů odstraněnéThe button will be removed from the list of calculation inputs after the migration is complete