Prechod medzi systémami ABRA Gen (migrácia)
V praxi dochádza často k potrebe prechodu medzi rôznymi inštaláciami ABRA Gen. Typicky je to v prípade, kedy chce užívateľ prejsť z jedného produktu ABRA Gen na iný (napr. z produktu ABRA Gen s jednoduchým účtovníctvom na ABRA Gen s podvojným účtovníctvom, príp. z produktu ABRA Gen pre Firebird na ABRA Gen pre Oracle či ABRA Gen pre MSSQL). Dôvodom môže byť to, že užívateľ napr. požaduje nejakú funkcionalitu, ktorá nie je dodávaná k nižšej produktovej rade a chce prejsť na vyššiu, viedol jednoduché účtovníctvo, ale teraz musí začať viesť podvojné účtovníctvo, chce zmeniť databázovú platformu a prejsť na výkonnejší databázový server a pod. Prechod je teoreticky možný i obrátene, tzn. z "vyššieho" produktu na "nižší". Rovnaký prechod je možné realizovať i medzi dvoma inštaláciami toho istého systému, ak to z nejakého dôvodu potrebujete.
V prípade niektorých variantov prechodu medzi produktmi ABRA Gen môže byť potrebné urobiť ešte nejaké dodatočné kroky v dátach tak, aby bolo možné nový produkt riadne používať. Takým prípadom je prechod medzi ABRA Gen s jednoduchým účtovníctvom a iným produktom ABRA Gen s podvojným účtovníctvom. Tu skôr odporúčame, pokiaľ je to možné, tak sa prechodu pomocou DBExport popísanému v tejto kap. vyhnúť a s novým systémom začať úplne od začiatku. Pokiaľ to však nie je možné alebo vhodné (napr. v ABRA Gen s jednoduchým účtovníctvom vediete i sklady a chcete ich previesť), je potrebné počítať s nutnosťou niekoľkých dodatočných zásahov do prevedených dát. Viď Prechod medzi ABRA Gen s jednoduchým účtovníctvom a ABRA Gen s podvojným účtovníctvom.
Do verzie 10.01. vrát. bolo možné zálohu dát z jedného systému bez ďalších úprav obnoviť do iného. Od v. 10.02 zavedením inkrementálneho update, keď sa súčasťou zálohy dát stali nielen dáta, ale aj systémové objekty (metadáta), viď Zálohovanie a obnovy dát, toto už nie je možné a prechod je preto potrebné riešiť iným spôsobom.
Postup je nasledujúci:
- v zdrojovej inštalácii sa vykoná export dát zo zdrojovej databázy nasledovne:
Pomocou nástroja DBExport sa do súboru formátu databázový export (*.DBE) vyexportujú dáta z vybraného spojenia. Postup realizácie a čo je obsahom vyexportovaných dát, viď popis nástroja DBExport.
- v cieľovej inštalácii sa vytvorí nová databáza s importom týchto vyexportovaných dát nasledovne:
V nástroji DBAdmin:
- sa zvolí voľba Pridať nové spojenie na vytvorenie novej databázy v cieľovej inštalácii ABRA Gen (tým sa zabezpečí vytvorenie novej databázy podľa súboru CreateDB.DBO, tzn. vytvoria sa databázové objekty systému ABRA Gen so správnou syntaxou príslušnej platformy).
- v nasledujúcom kroku Vlastnosti spojenia je potrebné začiarknuť voľbu "Zobraziť pokročilé vlastnosti" a potom sprístupnenú voľbu "Editovať zákaznícke úpravy".
- v kroku Zákaznícke úpravy sa začiarkne voľba "Nahrať dáta zo súboru" a pripojí sa súbor *.DBE vyexportovaný z nástroja DBExport, z ktorého sa vytvorená databáza naplní dátami vyexportovanými z pôvodnej databázy
- v kroku Zákaznícke úpravy je k dispozícii tiež možnosť zadať "Adresár s DBO súbormi". Ak ju použijete, nová databáza sa vytvorí podľa *.DBO súborov v tomto adresári. Toto však pre bežný prechod medzi systémami nebudete potrebovať (je určené na riešenie špecifických servisných situácií). Viac viď popis v nástroji DBAdmin.
Ak ste v zdrojovej databáze pridávali nejaké vlastné databázové entity (stĺpce, vlastné tabuľky, procedúry, triggery, ...) a chcete ich mať aj na importnej strane, je potrebné zabezpečiť ich pridanie do novo vytvorenej databázy a to nasledovne:
- v kroku Zákaznícke úpravy pridať *.DBO súbory s vlastnými zákazníckymi úpravami. Ide o vlastné *.DBO súbory, ktoré sa majú spustiť (a operácie z nich sa majú vykonať) v rôznych fázach vytvárania novej databázy.
Samotný import pridanie takýchto entít nijako nerieši (a ani nemôže, informácie o nich nie sú obsiahnuté vo vyexportovaných dátach). Ak vyexportované dáta obsahujú dáta z užívateľských stĺpcov, tabuliek či sekvencií, ale nezabezpečíte pridanie týchto entít na importnej strane, tieto dáta nebude možné naimportovať, import sa zastaví, viď ďalej.
Ako bolo uvedené v popise nástroja DBAdmin, zatiaľ neexistuje nástroj, ktorým by bolo možné vlastné *.DBO súbory získať zo zdrojovej inštalácie automaticky a musíte si ich vytvoriť ručne pomocou nástroja DBOperations (DBO súbory sú totiž binárne súbory a užívateľ ich nemôže vytvoriť inak ako prostredníctvom nástroja DBOperations).
Ak ste zákaznícke úpravy zdrojovej databázy robili vo verzii vyššej ako 10.02, je vám postup (pomocou *.DBO súborov) už známy. Ak ste zákaznícke úpravy robili vo verzii nižšej, pracovali ste so systémom *.NXD súborov, ktorý sa pre tento účel používal predtým. Ak nebudete vedieť, ako na to a ako teraz vytvoriť potrebné zákaznícke *.DBO súbory, objednajte si ich vytvorenie v servisnom oddelení dodávateľa.
Po spustení cieľovej inštalácie s týmto novým spojením sa vytvorí nová databáza, pričom sa prípadne vykonajú zákaznícke úpravy, ak boli zadané vlastné *.DBO súbory, a naimportujú sa do nej dáta z *.DBE súboru.
V souboru NEXUS.CFG můžete změnit počet vláken procesoru, které budou použity při importu dat z *.DBE souborů. Správné nastavení tohoto parametru (vzhledem k modelu vašeho procesoru) zrychlí nahrávání do databáze. Tento a další konfigurační parametry naleznete v Konfigurační soubor Nexus.cfg - oddíly a parametry.
V priebehu importu môže nastať situácia, keď exportný súbor obsahuje tabuľku, stĺpec tabuľky alebo sekvenciu, ktorá v cieľovom spojení neexistuje. V takom prípade import zobrazí dialógové okno s voľbou Zopakovať alebo Preskočiť. Je teda možné takéto hodnoty buď vôbec do novo tvorenej databázy neimportovať (preskočiť) alebo import prerušiť, chýbajúci databázový objekt najskôr doplniť (ručne napr. pomocou nástroja DBOperations) a následne pokračovať v importe.
K takejto situácii môže dôjsť typicky v prípade, keď ste si na exportnej strane pridávali napr. vlastné tabuľky, ktorých hodnoty sú obsiahnuté v exportovaných dátach, ale nezabezpečili ste ich pridanie na importnej strane, ako bolo povedané vyššie.
Převod uživatelských definic (číselníků, DynSQL)
- V původním systému ABRA Gen spustit nástroj DynSQLEditor.exe. Importovat jen uživatelské definice a tyto definice uložit do TXT.
- V původním systému ABRA Gen spustit nástroj DefRollEditor.exe. Importovat jen uživatelské definice číselníků a tyto uložit do TXT.
- V novém systému ABRA Gen v daných nástrojích, viz body výše otevřít uložený soubor a zvolit možnost Export uživatelských definic.
Následně je třeba zkontrolovat, že uživatelská DynSQL neobsahují na platformě závislé SQL fragmenty a případně tyto fragmenty opravit na novou platformu.
Převod uživatelských definic (číselníků, DynSQL) pomocí Instalačních sad
Po vytvoření nové databáze z DBE souboru, nebude tato nová instalace obsahovat uživatelské definice uložené v repozitoři původního systému ABRA Gen (soubor Storage.STF).
Před prováděním jakýkoli změn si v nové i původní instalaci za zálohujte soubor Storage.STF.
- V původní instalaci spusťte v systému ABRA Gen agendu Instalační sady. Vytvořte novou instalační sadu a přidejte do ní všechny Definovatelné číselníky a Dynamické SQL, které chcete do nové instalace převést.
- Dokončete průvodce a funkcí Exportovat sadu uložte instalační sadu do souboru.
- V nové instalaci spusťte v systému ABRA Gen agendu Instalační sady. Vyberte funkci Importovat sadu -> Expertní import a nainstalujte všechny objekty z v předešlém kroku vytvořené instalační sady.
Převod uživatelských definic (číselníků, DynSQL) pomocí nástrojů DynSQLEditor.exe a DefRollEditor.exe
Pozor, níže uvedený původní způsob, tedy s importem a exportem jen uživatelských DynSQL, nepřenáší nastavení, kdy uživatelský objekt je použit na systémovém objektu.
Typicky kdy je uživatelské DynSQL použito v systémovém objektu Místa v programu.
- V původním systému ABRA Gen spustit nástroj DynSQLEditor.exe. Importovat jen uživatelské definice a tyto definice uložit do TXT.
- V původním systému ABRA Gen spustit nástroj DefRollEditor.exe. Importovat jen uživatelské definice číselníků a tyto uložit do TXT.
- V novém systému ABRA Gen v daných nástrojích, viz body výše otevřít uložený soubor a zvolit možnost Export uživatelských definic.
Následně je třeba zkontrolovat, že uživatelská DynSQL a další objekty uložené v databázi neobsahují na platformě závislé SQL fragmenty a případně tyto fragmenty opravit na novou platformu.
Best-practice přechodu mezi systémy ABRA Gen
Postup:
- Provést přechod do nové testovacím systému ABRA Gen určené pro odladění všech funkcí.
- Najít a upravit všechna DynSQL, která obsahují platformově závislé SQL fragmenty.
- Najít a upravit všechny uživatelské objekty v databázi, které obsahují platformově závislé SQL fragmenty.
- Uživatelské testování a kontrola pomocí SQL monitoringu.
- Vytvoření finální instalační sady obsahující všechny upravené uživatelské objekty.
- Přechod do nové ostré instalace systému ABRA Gen.
Podmínkou postupu je že v průběhu úprav a vytváření finální instalační sady nedojde ke změnám žádného z upravovaných objektů nebo vytváření nových v původním systému ABRA Gen.
Aby nemohlo dojít k potížím, kdy některý z nástrojů systému ABRA Gen nebude mít načtenu aktuální repozitoř, doporučujeme veškeré úpravy provádět v lokálním režimu. Toto se netýká se samotného vytváření databází.
Předpokladem úspěšného vytváření instalačních sad je dostupnost všech objektů, na které se jednotlivé objekty odkazují.
ad 1) Provést přechod do nového testovacího systému systému ABRA Gen určeného pro odladění všech funkcí
Vytvoření nového DBE exportu ve zdrojové ostré instalaci. Vytvoření nové instalace ABRA Gen s novou databázi z DBE a pomocí instalačních sad do ní převést uživatelské definice z DynSQL, viz. výše.
ad 2) Najít a upravit všechna DynSQL, která obsahují platformově závislé SQL fragmenty
Pro vyhledání těchto fragmentů lze použít nástroj UserCustomizationChecker.exe dodávaný v instalaci ABRA Gen. Případně si v nástroji DynSQLEditor vyexportovat všechna uživatelská DynSQL do souboru a provést vyhledání v něm. Pro úpravu použijte nástroj DynSQLEditor.
ad 3) Najít a upravit všechny uživatelské objekty v databázi, které obsahují platformově závislé SQL fragmenty
Tyto fragmenty SQL se mohou vyskytovat mimo jiné v těchto objektech:
- Balíčky skriptov
- Definice omezení a Filtry – podmínka Výraz
- Definovatelné Exporty
- Definovateľné formuláre
- Fulltextové hľadanie
- Naplánované úlohy
- Panely definovateľných údajov
- Tlačové zostavy
- Užívateľské stĺpce
- Variantné vstupné formuláre
- Kategorizačné údaje
- SCM
Pro vyhledání a kontrolu mohou sloužit:
- Nástroj UserCustomizationChecker.exe: U vybraných druhů objektů provádí automatickou kontrolu přímo vykonáním SQL. Případně umožňuje dohledat předem vytipované chybné fragmenty SQL.
- Vybrané agendy (např. Přehled omezení, Variantní formuláře apod.): Pomocí omezení v agendách lze dohledat předem vytipované chybné fragmenty SQL. Např. v agendě Definice omezení lze omezit za výraz „a.dsqlvalues like '%A.%'“ a pomocí něj dohledat všechny záznamy, které v podmínkách obsahují hodnotu „A.“
- Ruční kontrola spuštěním v ABRA: Některé neglobální uživatelské objekty jsou v ABRA Gen vidět pouze pro uživatele, kteří je vytvořili. Např. Omezení a Filtry nebo Panely definovatelných údajů. Pro kontrolu takovýchto Omezení a Filtrů jiným uživatelem je možné v agendě Přehled omezení změnit nastavení na Globální a po odladění opět vrátit zpět. Obdobně je toto možné provést u Panelů definovatelných údajů. Vzhledem k tomu že pro tyto objekty neexistuje agenda je možné je na globální přepnout pouze zásahem v databázi (tabulka CENTRALSTORAGE, dotaz PATH LIKE '%SiteDetailDefinitions%' – pokud je v user_id null je globální).
- Kontrola přímo v databázi
- Vytvoření instalační sady s danou skupinou objektů, její vyhrání do souboru a textová kontrola v tomto souboru. Od verze 24.1 jsou instalační sady výchoze vytvářeny jako zazipované soubory obsahující xml s jednotlivými uživatelskými objekty. Po rozzipování je možné tyto xml prohledat a dohledat v nich předem vytipované chybné fragmenty SQL.
ad 4) Uživatelské testování a kontrola pomocí SQL monitoringu
Po odladění všech uživatelský objektů doporučujeme vyzkoušení plné funkcionality uživateli ABRA Gen. Během tohoto testování je vhodné sledovat provoz ABRA Gen pomocí SQL monitoring (dostupný od verze 25.3.x) a odhalit případné další chybná nebo neodladěná déle trvající SQL. Zároveň doporučujeme pomocí nástroje UserCustomizationChecker.exe provést všechny zde nabízené kontroly.
ad 5) Vytvoření finálních instalační sad(y) obsahující všechny upravené uživatelské objekty
Po řádném testování je možné vytvořit novou instalační sadu, která bude použita pro finální vytvoření nové ostré instalace. Z důvodu přehlednosti je možné vytvoření více instalačních sad, v tomto případě je doporučujeme seskupovat tak jak spolu jednotlivé druhy objektů souvisí, např. Dynamické SQL a definovatelné číselníky do jedné sady. Neglobální Definice Omezení, Panely definovatelných údajů a Variantní vstupní formuláře je možné přenášet pomocí instalačních sad až od verze 25.3.x.
ad 6) Přechod do nové ostré instalace ABRA Gen
Zastavení provozu v původní nyní zdrojové instalaci ABRA Gen. Vytvoření nového DBE exportu s aktuálními daty. Vytvoření nové databáze z nového DBE exportu v nové ostré instalaci ABRA Gen. Instalace finální instalační sady obsahující všechny odladěné uživatelské objekty. Spuštění ostrého provozu v nové ostré instalaci ABRA Gen.
Často kladené otázky
Důležité rozdíly v produktech ABRA Gen
ABRA Gen pro MSSQL používá před ID prefix ~.
ABRA Gen pro Oracle oproti ABRA Gen pro Firebird a MSSQL používá jiné třídění.
Během vytváření instalační sady se zobrazuje chyba cannot create instance
Agenda instalační sady se pokouší načíst odkazovaný objekt který již neexistuje, např. Tisková sestava se odkazuje na neexistující uživatelské DynSQL, nebo uživatelské DynSQL které se dále odkazuje na neexistující uživatelské DynSQL.
Pozor v tomto případě se nedostaly do instalační sady všechny objekty a je potřeba problém nejdříve vyřešit a poté se pokusit vytvořit instalační sadu znovu.
Nejsnazším způsobem o dohledání více informací o problémovém objektu je vyhrání všech DynSQL v nástroji DynSQLEditor do souboru. A následné prohledání tohoto souboru. CLSID z chybové hlášky je před vyhledáváním nutné převést na ShortCLSID, k tomu slouží nástroj GUID conversion dostupný zde ABRA Tools.
V určitých případech, např při načítání Tiskových sestav do instalační sady se může zobrazit místo chyby s konkrétním CLSID pouze text Interface not supported.
V tomto případě (případně i jiných) lze chybný objekt dohledat dle posledních záznamů v seznamu objektů která instalační sada zobrazila. Instalační sady načítají záznamy tak jak je vrací databázový server, tedy prázdný řádek je ten chybný a lze jej v databázi určit dle předchozích záznamů. K prohlížení záznamů v databázi je nutné použít nástroj který záznamy sám výchoze neřadí např. DBeaver.
Co s neexistujícími objekty, případně jinými objekty, které se na ně odkazují?
Nejdříve je nutné ověřit, zda k problému nedošlo omylem při práci s DynSQL. Ověřte, že objekt neexistuje v původní ostré zdrojové instalaci, případně ověřte, zda se nevyskytuje v některých ze záloh systému ABRAGen. Pokud zde ani v jiných zdrojích nelze původ objektů odhalit, je možné rozhodnout o jeho zrušení, ale toto rozhodnutí bude vždy individuální. Nicméně všechny objekty navázané na chybějící v systému chybovali a nebylo možné je ani v původní ostré instalaci používat. Každopádně před smazáním nebo jakoukoliv prací doporučujeme objekt a všechny objekty na něj navázané za zálohovat (Možnost uložení definic do souboru nabízí nástroje DynSQLEditor.exe, DefRoll.exe a další, případě je možnost za zálohovat celou repozitoř).
Chyby Panelů definovatelných údajů v nástroji UserCustomizationChecker.exe
Zápis ve výpisu nástroje UserCustomizationChecker.exe (zobrazeno jako CSV):
Neznámá agenda (XXXRE20IPZDL342W01C0CX3FCC)
Nepodařilo se dohledat zdrojovou agendu panelu. Nejspíš se jedná o již neexistující definovatelný číselník.. Zkontrolujte, zda se daný GUID nevyskytuje v původní zdrojové instalaci, případně v některé ze záloh a pokračujte dle kapitoly výše.
Neznámá agenda (00000000000000000000000000) - PPC2EX0BUJD13ACP03KIU0CLP4)
Nástroj nedohledal správný zdroj dat panelu v agendě s GUID PPC2EX0BUJD13ACP03KIU0CLP4 (Faktury přijaté – lze dohledat v GenDoc.chm). Typicky se jedná o řádky dokladů.
Všechny panely pro speciální agendy, jak jsou Účetní žádosti, Mzdové listy apod. nástroj UserCustomizationChecker.exe detekuje jako chybné. Tyto panely je nutné zkontrolovat ručně.
Více o konkrétním panelu lze uživatelsky zjistit po vyexportováním instalační sady obsahující panel do souboru (více výše). V databázi lze panely dohledat pomocí dotazu do tabulky CentralStorage s podmínkou PATH LIKE %SiteDetailDefinitions%PPC2EX0BUJD13ACP03KIU0CLP4%'. Zde by mělo být poté porovnáním možné dohledat název panelu a další informace.
Viac viď kap. Nástroje.

Preto, aby bolo možné SQL dopyty pripraviť už na verziu 22.0 a prechod na Unicode verziu sa čo najviac urýchlil, bola do ABRA Gen implementovaná technológia zástupných znakov, ktoré podľa verzie ABRA Gen doplnia nové nevyhnutné časti SQL dopytov.
Od verzie 22.0.0 ServicePack 26 respektíve 22.0.1 ServicePack 24 sú tieto zástupné znaky nahradené prázdnym znakom.
Od verzie 22.1.0 ServicePack 4 respektíve 22.1.1. ServicePack 3 a vyššie sú nahradené takto:
Firebird:
@{unicodeNvarcharCast(String what, int size, boolean withCollate)} vloží len zadané ID
Ostatné zástupné znaky, pokiaľ budú použité, sú nahradené prázdnym znakom.
K prechodu medzi ABRA Gen s jednoduchým účtovníctvom a ABRA Gen s podvojným účtovníctvom
Dodatočné úpravy v dátach po prechode medzi týmito systémami plynú predovšetkým z týchto ich odlišností, ktoré sa týkajú účtovania:
- V produkte ABRA Gen s jednoduchým účtovníctvom je len jeden Typ organizácie a predvypĺňajú sa podľa neho len záznamy do definícií uzávierky miezd podľa vzorov. V ostatných produktoch je k dispozícii niekoľko typov organizácií a po prvom výbere typu organizácie sa automaticky doplnia záznamy do účtového rozvrhu, účtovných predkontácií a definícií uzávierky miezd podľa vzorov pre vybraný typ organizácie. Bez nich nie je možné účtovať. Dodatočné neskoršie zmeny je nutné riešiť ručne porovnaním s dodávanými vzormi.
- Množina typov dokladov dodávaná výrobcom v rámci inicializačných dát pre produkt ABRA Gen s jednoduchým účtovníctvom a pre ostatné produkty nie je rovnaká. V ABRA Gen s jednoduchým účtovníctvom je navyše napr. typ Ostatné zápisy a naopak niektoré typy nie sú k dispozícii, pretože pre ABRA Gen s jednoduchým účtovníctvom nemajú význam (napr. typ Interné doklady).
- V produkte ABRA Gen s jednoduchým účtovníctvom sa neúčtuje ako v podvojnom účtovníctve a všetky typy dokladov majú nastavenú položku Účtovať na Nie (čo nie je možné užívateľsky v danom číselníku meniť), takže i všetky rady dokladov budú mať nastavené Neúčtovať.
Tieto nastavenia sú súčasťou inicializačných dát pre jednotlivé produkty ABRA Gen. Ako bolo ale objasnené v rámci výkladu inicializačných dát, pri migrácii sa súbor inicializačných dát z princípu migrácie nevyužíva - initdáta sa (rovnako ako ostatné dáta) nahrajú zo súboru *.DBE presne tak, ako boli v pôvodnej databáze (čo je zámer).
Je preto potrebné iným spôsobom zabezpečiť doplnenie prevedených dát v cieľovom produkte - možným riešením je napr. vyhrať obsah všetkých potrebných tabuliek z novo vytvorenej "bežnej" databázy naplnenej aktuálne dodávanými inicializačnými dátami cieľového produktu pomocou nástroja Scripter.exe a následne ich previesť do dát prevedených z pôvodného produktu ABRA Gen (tzn. napr. do dát prevedených z produktu ABRA Gen s jednoduchým účtovníctvom). Kontaktujte servisné oddelenie výrobcu. Užívateľ si ďalej musí založiť nové rady dokladov so správne nastaveným účtovaním pre cieľový produkt a ak je cieľovým produktom produkt s podvojným účtovníctvom, musí si prevziať vzory tých účtov a predkontácií, ktoré potrebuje, postupným porovnaním s dodávanými vzormi (pokiaľ si ich nevyhral aj z príslušných tabuliek (Accounts, AccPresetDefs, AccPresetDefs2), a potom by ich stačilo len skontrolovať, prípadne upresniť podľa vlastnej potreby.
Po migrácii vyššie uvedeným postupom z produktu ABRA Gen s jednoduchým účtovníctvom sú tabuľky vzorov účtovnej osnovy MasterAccounts a predkontácií MasterAccPresetDefs a MasterAccPresetDefs2 prázdne. Preto keď užívateľ v nastavení firmy vyberie typ organizácie napr. Súkromná organizácia - podnikateľ a následne v agende účtovnej osnovy použije funkciu na porovnanie so vzorom, nenájdu sa žiadne rozdiely (rovnaká situácia je i v predkontáciách - napr. funkcia Nový podľa vzoru). Je teda nutné dáta vzorov do prevedených dát doplniť. Napr. práve vyhraním z databázy cieľového produktu pomocou nástroja Scripter .exe. Až potom je možné porovnaním so vzormi postupne získať zodpovedajúcu účtovnú osnovu a predkontácie.
V tabuľke Typy dokladov (DocumentTypes) sú ďalej všetky prevedené nastavené ako neúčtované a ich ďalšie parametre sú pre použitie v cieľovom produkte nastavené tiež nesprávne. Je ich preto potrebné zmazať (okrem typu dokladu "Ostatné zápisy (99)", na ktorý budú pravdepodobne v databáze odkazy) a doplniť aktuálne dodávané pre cieľový produkt. Čo je možné riešiť opäť vyhraním z databázy cieľového produktu pomocou nástroja Scripter.exe.
Ďalej si užívateľ založí nové rady dokladov pre podvojné účtovníctvo (účtované FV, PP, FP, PV....) a prevezme vzory tých účtov a predkontácií, ktoré potrebuje (ak si ich nevyhral tiež).