XML Importér Případů Praha Východ

Importér při importu případů z XML nejdříve dané XML validuje. V případě, že je XML validní, provede jeho import do Evolia. Validace se řídí různými nastaveními importéru.

od verze 7.0.3.

nelze souběžně spustit 2 importy spisů

od verze 7.0.19

nastavení -> "částky jsou včetně dph" jsou vždy při každém spuštění improtéru nastaveny na FALSE.



Validace XML

Importér předá validátoru množinu tabulek ke kontrole.Každá tabulka představuje jeden TAG z XML. Validátoru jsou tedy předávány tyto TAGy / tabulky:
  • UdajePodani
  • Opravneny
  • UdajeSubjektu
  • PravniZastupceOpravneneho

    Provádí se tyto typy validace a v pořadí jaké zde uvedeno:
  • Validace oprávněných
  • Validace právních zástupců
  • Validace případů

    Všechny výsledky z jednotlivých validací se vynásobí logickým součinem a výsledek se vrátí importéru.

Validace Oprávněných

Nejdříve nakopíruje infomace o opravněných z UdajeSubjektu do kolekce. Při kopírování kontroluje, jestli UdajeSubjektu jsou právě jednou v Opravneny. Pokud jsou 0-krát nebo více než jednou, pak funkce dokončí operaci přes všechna data a oprávněné a vrátí, že jsou data nevalidní.
Poté zkontroluje, počet různých oprávněných a podle nastavení rozhodne o podružné validitě o různosti oprávněných.
Poté zkontroluje, jestli bude importér nucen založit oprávněné do Evolia a podle nastavení rozhodne o podružné validitě o existenci oprávněných.
Výsledky všech tří validací se vynásobí logickým součinem a vrátí se výsledná validita.

Validace různosti oprávněných:

Kolekci oprávněných převede do tabulky, nad kterou provede metodu Distinct. Pokud je výsledku víc jak jeden záznam a není nastaveno Ignorovat různé oprávněné, pak se vrací nevalidita a importéru se ohlašuje chyba V importovaných datech jsou POČET různí oprávnění. Pokud je výsledku víc jak jeden záznam a je nastaveno Ignorovat různé oprávněné, pak se vrací kladná validita a importéru se ohlašuje varovani V importovaných datech jsou POČET různí oprávnění. V obou dvou případech se odešle importéru informace (Oprávněný jméno: JMENO, příjemní: PRIJMENI, název firmy: NAZEV ič: ICO, rč RC) s podrobnostmi o všech různých oprávněných z XML.
Pokud je ve výsledku, tedy i v XML, 1 oprávněný, zašle se importéru zpráva V importovaných datech je 1 oprávněný jméno: JMENO, příjemní: PRIJMENI, název firmy: NAZEV ič: ICO, rč RC a vrátí se kladná validita.{BR}
Pokud je není ve výsledku žádný oprávněný, zašle se importéru chyba V importovaných datech není žádný oprávněný a vrátí se nevalidita.

Validace Existence Oprávněných

Nad seznamem oprávněných se provede metoda Distinct nad sloupcem IC a výsledek se uloží do kolekce oprávněných dle ičo. Totéž se provede nad sloupcem RC, jehož hodnoty jsou zbaveny mezer, pomlček a lomítek, a výsledek se uloží do kolekce oprávněných s rodným číslem. Nakonec se do třetí kolekce uloží ti oprávnění, které nemají vyplněno ani rodné číslo ani ičo.
Z kolekce s ičo se poskládá podmínka pro SQL dotaz
Select zařaditjako as NAME, ičo as IC from Klienti where ičo in (IČA)
{BR}

Z kolekce s rodnými čísly se poskládá podmínka pro SQL dotaz
Select zařaditjako as NAME, rodné_čísl as RC from Klienti where replace(replace(replace(rodné_čísl,'/',''),'-',''),' ','') in (RODNA_CISLA)


Nejdřív se pošle SQL do databáze a získá se z něj tabulka naplněná ičama, která jsou součástí kolekce s ičy oprávněných z XML. S tabulkou se provede množinový rozdíl, kdy od kolekce s ičy oprávněných z XML se odečtou iča z tabulky z databáze.
Tentýž postup se provede s rodnými čísly, takže na konci existují dvě nové kolekce (ičo a rč) obsahující záznamy, které nejsou v evoliu. Pokud v některé, z těchto kolekcí, existuje více, jak 0 záznamů, pak se importéru pošle seznam oprávněných s ičo, kteří nejsou v evoliu a seznam oprávněných s rč, kteří nejsou v evoliu (Bude se do Evolia zakládat nový oprávněný jméno: JMENO, příjemní: PRIJMENI, název firmy: NAZEV ič: ICO, rč RC). A pokud je v importéru nastaveno Zastavit import při pokusu založit nový subjekt, pak se tyto hlášení vrátí jako chyba a vrátí se nevalidita. Pokud Zastavit import při pokusu založit nový subjekt nastaveno není, pak se hlášení vrátí jako varování a vrátí se kladná validita. V obou případech si ale validátor nastaví vlastnost BudouSeZakladatNoveSubjekty, aby případně mohl uživatel ještě zasáhnout před samotným importem.
Pokud se v kolekci oprávněných bez rodného čísla a iča nachází nějaké záznamy, je zasláno importéru chybové hlášení oprávněný postrádá v XML ičo a rč jméno: JMENO, příjemní: PRIJMENI, název firmy: NAZEV ič: ICO, rč RC a vrátí se nevalidita.

Validace Právního zástupce

Nakopírují se hodnoty právního zástupce z UdajeSubjektu do tabulky. S ní se provede validace kontroly existence v Evoliu, která naprosto totožná s validací Existence Oprávněných, jen se v hlášeních vrací, místo oprávněný, právní zástupce.
Pokud je v importeru nastaveno Právní zástupce: při jiné adrese téhož subjektu založ subjekt nový, pak se provede validace i podle existence adresy subjektu.
Výsledky obou validací se vynásobí logickým součinem a vrátí se výsledná hodnota validace.

Validace kontrolou existence právního zástupce dle adresy

Zde se pro každého právního zástupce z XML kontroluje, jestli existuje v Evoliu dle iča a adresy nebo ročného čísla a adresy pomocí těchto SQL dotazů.
SELECT k.číslo_klienta as id, k.IČO as ic, k.RODNÉ_ČÍSL as rc, k.ZařaditJako as name, ka.klaMesto as mesto, ka.klaUlice as ulice, ka.klaPSC as psc FROM Klienti AS k INNER JOIN KlientiAdresy AS ka ON k.ČÍSLO_KLIENTA = ka.klaIDKlient WHERE (k.IČO = '{0}') AND (replace(ka.klaMesto,' ','') = N'{1}') AND (replace(ka.klaUlice,' ','') = N'{2}') AND (replace(ka.klaPSC,' ','') = N'{3}')

SELECT k.číslo_klienta as id, k.IČO as ic, k.RODNÉ_ČÍSL as rc, k.ZařaditJako as name, ka.klaMesto as mesto, ka.klaUlice as ulice, ka.klaPSC as psc FROM Klienti AS k INNER JOIN KlientiAdresy AS ka ON k.ČÍSLO_KLIENTA = ka.klaIDKlient WHERE (replace(replace(replace(k.RODNÉ_ČÍSL,' ',''),'/',''),'-','') = '{0}') AND (replace(ka.klaMesto,' ','') = N'{1}') AND (replace(ka.klaUlice,' ','') = N'{2}') AND (replace(ka.klaPSC,' ','') = N'{3}')

Pokud je nějaký záznam nalezen v Evoliu je nastaveno v importéru Zastavit import při pokusu založit nový subjekt, pak se vrátí chybová hláška Právní zástupce v případu POPIS_PRIPADU se má založit do Evolia jméno: JMENO, příjemní: PRIJMENI, název firmy: NAZEV ič: ICO, rč RC a vrátí se nevalidita. Pokud je nějaký záznam nalezen v Evoliu a není nastaveno v importéru Zastavit import při pokusu založit nový subjekt, pak se vrátí varovná hláška s týmž obsahem a vrátí se kladná validita. V obou případech, ale nastaví validátor vlastnost BudouSeZakladatNoveSubjekty, aby mohl uživatel případně zasáhnout před samotným importem. Toto proběhne ovšem v případě, že právní zástupce má v XML v daném případě 1 adresu.

Pokud nemá adresu žádnou, pak se vrátí chybové hlášení Právní zástupce v případu POPIS_PRIPADU nemá žádné adresy jméno: JMENO, příjemní: PRIJMENI, název firmy: NAZEV ič: ICO, rč RC a vrátí se nevalidita. Nebo pokud má více právní zástupce více než 1 adresu, pak se vrátí chybové hlášení Právní zástupce v případu POPIS_PRIPADU má více než 1 adresu jméno: JMENO, příjemní: PRIJMENI, název firmy: NAZEV ič: ICO, rč RC a vrátí se nevalidita.
Pokud právní zástupce dle ičo nebo rodného čísla má v XML 1 adresu a existuje v Evoliu (dle ičo nebo rodného čísla), pak je vrácená kladná validita.

Validace na existenci případu v Evoliu

Každý případ z XML je kontrolován vůči Evoliu pomocí tohoto SQL dotazu
Select číslo_smlouvy as cislo from smlouvyprodukt where replace(replace(replace(exCisloNavrhu,'E',''),'N',''),' ','') = 'ZNACKA' and exZnacka = 'DAVKA' and produkt = 'PRODUKT'

Proměnná PRODUKT se mění dle toho, jestli jde o import spisu nebo návrhů. Pokud jde o import návrhů, pak proměnná PRODUKT má hodnotu NAVRH_NA_EXEKUCI. Pokud jde o import spisů, pak proměnná PRODUKT má hodnotu EXEKUCNI_SPIS.
Pokud neexistuje případ v Evoliu vrátí se informační hlášení Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu neexistuje.
Pokud existuje případ v Evoliu a je nastaveno v importéru Zastavit/Nespustit import, vrátí se chybové hlášení Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu existuje CISLO_PRIPADU_V_EVOLIU a nastaví se nevalidita.
Pokud existuje případ v Evoliu a není nastaveno v importéru Zastavit/Nespustit import vrátí se varovné hlášení Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu existuje CISLO_PRIPADU_V_EVOLIU.
Pokud existuje případ v Evoliu nastaví se proměnná BylyNalezenyShodnePripady,aby mohl uživatel před samotným importem ještě zasáhnout.
Na konci, kdy jsou prověřeny všechny případy v XML je vrácená validita.

Import

Uživatelem zadaný XML soubor načte jako množinu tabulek tzv. dataset. Nad tímto datasetem provede validaci pomocí validátoru. Z validátoru poslouchá všechny zprávy, které mu validátor pošle a přeposílá je dál do hlavního okna k uživateli. Hlavní okno je zasílá dál do Logu.
Pokud jsou data nevalidní, import neproběhne.
Pokud jsou data validní, pokračuje se dál.
Pokud je nastavena Vlastnost validátoru BudouSeZakladatNoveSubjekty, pak importér pošle otázku Během importu se bude zakládat oprávněný nebo jeho právní zástupce. Jste si jisti, že chcete pokračovat v importu?. Pokud odpoví kladně, pak se pokračuje dál, jinak se import ukončí.
Pokud je nastavena Vlastnost validátoru BylyNalezenyShodnePripady, pak importér pošle otázku V importovaných datech se nacházejí případy, které jsou již v Evoliu. Jste si jisti, že chcete pokračovat v importu?. Pokud odpoví kladně, pak se pokračuje dál, jinak se import ukončí.
Nyní dochází k samotnému importu dat z XML do Evolia.
V cyklu se procházejí jednotlivé případy z XML. Na začátku se z případu získá dávka a značka. Pokud uživatel před importem zadal do Číslo jednací / značka v XML a Značka / Dávka v XML nějaké hodnoty, jsou tyto hodnoty porovnávány s právě získanou dávkou a značkou z XML. Neshodné se přeskakují do první shody. Od první shody se pokračuje v importu zbývajících případů v XML. Tzn. Že uživatel v importéru může nastavit, od kterého případu se má začít importovat.
Dál se kontroluje pomocí SQL dotazu
Select id, číslo_smlouvy as cislo from smlouvyprodukt where replace(replace(replace(exCisloNavrhu,'E',''),'N',''),' ','') = 'ZNACKA' and exZnacka = 'DAVKA' and produkt = 'PRODUKT'
existence importovaného případu
Pokud případ už Evoliu existuje bude se přepisovat dle nastavení importéru. Pokud ne založí se nový případ do Evolia.

Přepisování Spisů

U přepisování shodných spisů záleží na nastavení importéru.
Pokud je nastaveno v importéru Zastavit/Nespustit import pak se import zastaví.
Pokud je nastaveno v importéru Přeskočit shodné záznamy pak se importér přeskočí shodný případ.
Pokud je nastaveno v importéru Shodné záznamy založit jako nový případ , pak v případě, že je shodný případ v Evoliu 1x, pak importér odešle otázku Případ PRODUKT se značkou ZNACKA a dávkou DAVKOU v Evoliu existuje. Chcete jej skutečně SHODNE_ZALOZIT_JAKO_NOVE? k uživateli, pokud odpoví uživatel kladně je založen spis jako nový i s novým číslem spisu. Pokud by byla odpověď záporná, pak se neděje nic. Případ se přeskočí.

Pokud je nastaveno v importéru Přepsat shodné záznamy , pak v případě, že je shodný případ v Evoliu 1x, pak importér odešle otázku Případ PRODUKT se značkou ZNACKA a dávkou DAVKOU v Evoliu existuje. Chcete jej skutečně PREPSAT_SHODNE? k uživateli, pokud odpoví uživatel kladně je spis načten i se všemi daty z Evolia. Je získáno je číslo spisu. Data spisu (dataset) je pak uložen do tabulky Log s odůvodněním XML Importér spisů Praha východ: smazání spisu z důvodu jeho přepsání daty z XML NAZEV_XML_SOUBORU (totéž chování, jako když v Evoliu uživatel maže spis nebo klienta či pracovníka). Pak je načtený Evolio případ odstraněn z Evolia a je založen zcela nový případ. Přičemž je použito čísla smazaného případu. Ale nemusí být užito, záleží na tom, jestli se importují spisy nebo návrhy.
Pokud je nalezeno více shodných případů v Evoliu s případem z XML, odešle importér uživateli otázku Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu existuje více než jednou SEZNAM_CISEL_PRIPADU_Z_EVOLIA. Chcete je skutečně ZPUSOB_PREPISOVANI_PRIPADU? Při NE se import zastaví.. Pokud odpoví uživatel negativně, import se ukončí. Pokud uživatel odpoví kladně, pokračuje se dál do cyklu, kde se prochází jednotlivé existující případy. Pokud je v importéru nastaveno Přepsat shodné záznamy, pak má uživatel možnost přepsat kterýkoliv ze shodných případů. Pokud je v importéru nastavena možnost Shodné záznamy založit jako nový případ, pak při negativních odpovědí uživatele se projde každý shodný případ. Při kladné odpovědi se založí nový případ s novým číslem a procházení je ukončeno.

Založení nového spisu

Z množiny tabulek datasetu XML se vyberou tyto tabulky UdajePodani, Opravneny, Povinny, EXTitul, Narok pro všechny případy v XML. Aby import proběhl musí být tabulky (čili i TAGy v XML) přítomny a musejí obsahovat záznamy. Výjimka je jen dovolena u EXTitul a Narok.
Každý záznam v datasetu XML má přiřazen svůj automaticky vygenerovaný jednoznačný klíč. Podle toho klíče se dají nalézt související záznamy s nadřazeným záznamen (např. vztah adresa a subjekt).
Importér poté ke konkrétnímu případu se snaží získat záznamy z tabulek UdajePodani, Opravneny, Povinny, EXTitul, Narok. Počet záznamů v UdajePodani musí být roven 1. Jiný počet není dovolen.
Pokud je tedy počet záznamů v UdajePodani musí být roven 1, založí importér nový prázdný případ. Do něj se pak importují veškeré záznamy z XML a nakonec se takový případ uloží.

Import UdajePodani

V Evoliu se týkají základních údajů případu.
Do poznámky Evolio případu se uloží věta import z XML NAZEV_XML_SOUBORU, do značky se uloží dávka z XML, do čísla návrhu se uloží značka z XML a do zahájeno datum podání exekuce (PodaniExekuce). Do oddělení se uloží hodnoty zadaná v importeru. A do pole příslušný soud (je vidět jen v návrhu) pak převede příslušný soud uvedený v XML v TAGu UdajePodani.
Pokud se importuje návrh, pak číslem případu je značka z XML s prefixem EN a případ je označen jako produkt NAVRH_NA_EXEKUCI. Pokud se importuje spis, pak je číslem případu předané číslo spisu (ať už ze smazaného spisu nebo z generátoru čísel spisů) a uloží se i stav spisu, který je zadán v importéru a případ je označen jako produkt EXEKUCNI_SPIS.

Import Opravněného

Pro každého oprávněného případu se získají nacionále z UdajeSubjektu a ty jsou převedeny do Evolia. Je vráceno Evolio ID, které pak použito pro založení oprávněného jako subjekt případu v roli oprávněný. Zároveň jsou ihned převedeni právní zástupci aktuálního oprávněného.

Import Právních zástupců

Pro každého právního zástupce (oprávněného) jsou získány je nacionále z UdajeSubjektu a jeho adresy. Pokud není nastaveno v Importéru Právní zástupce: při jiné adrese téhož subjektu založ subjekt nový, pak je právní zástupce založen stejnou cestou jako oprávnění (jako všechny subjekty v XML). Pokud je nastaveno v Importéru Právní zástupce: při jiné adrese téhož subjektu založ subjekt nový a právní zástupce má jiný počet adres než 1, pak je právní zástupce založen stejnou cestou jako oprávnění. Pokud je nastaveno v Importéru Právní zástupce: při jiné adrese téhož subjektu založ subjekt nový a právní zástupce má 1 adresu, pak je u právní zástupce zjišťováno, jestli existuje dle adresy a ičo nebo dle adresy a rč. Pokud ne, je do Evolia založen, pokud ano je použito jeho Evolio ID.
Poté je právní zástupce založen do případu jako subjekt s rolí právní zástupce oprávněného.

Import povinných

Probíhá stejně jako import oprávněných bez právních zástupců. Povinní jsou pak jednotlivě zakládáni do případu jako subjekti s rolí povinný.

Od verze 7.0.10

V této verzi došlo k úpravě vyhledávání existujících povinných v Evoliu a to dle následujících kritérií.{BR}
Nejdřív se povinný kontroluje dle ičo, pokud je vyplněno v XML. U iča se vyhledávání upřesňuje na název firmy, pokud je v XML vyplněno. Jinak se místo názvu firmy použije pro vyhledávání jméno a příjmení, pokud jsou obě vyplněna. Jinak se vyhledává pouze dle ičo.
Pokud je vyhledávání dle ičo neúspěšné, pak se přistoupí k vyhledávání dle rodného čísla. U rodného čísla se vyhledávání upřesňuje na jméno a příjmení, pokud jsou obě vyplněna. Jinak se místo jména a příjmení použije pro vyhledávání název firmy, pokud je v XML vyplněno. Jinak se vyhledává pouze dle rodného čísla.

Pokud je vyhledávání dle rodného čísla neúspěšné, pak se vyhledává dle jména a příjmení, pokud jsou obě vyplněna.
Pokud je vyhledávání dle jména a příjmení neúspěšné, pak se vyhledává dle názvu firmy, pokud je v XML vyplněno.
Pokud i toto poslední vyhledávání je neúspěšné, pak se vrátí, že subjekt neexistuje.
Přestože dle jména a příjemní nebo firmy by byl povinný nalezen, bude stejně založen jako nový, protože názvy nejsou jednoznačnými identifikátory.

Import financí

Pokud v TAGu Narok existuje TAG Jistina, pak je založena jistina. Pokud v TAGu Narok existuje TAG Prislusenstvi, pak je založeno do případu příslušenství částkou. Pokud v TAGu Narok existuje TAG DefiniceUroku, pak jsou do případu založeny úroky.

od Verze 7.0.19

Pokud je v nastavení importéru nastaveno, že částky v XML jsou včetně DPH, pak importér postupuje následujícím způsobem. Z překladové tabulky finančních položek importéru přijde druh a typ položky v Evoliu. Druh a typ pak použije pro dotazování do tabulky FinancePolozkyTypy, odkud si pro daný daný druh a typ položky načte hodnotu ze sloupce fptSDPH. Pokud je ve sloupci 1, pak se z částky v XML vypočítává základ ze zadané sazby DPH v nastavení importéru. Pro všechny ostatní případu fptSDPH = 0, položka nenalezena, tabulka nenalezena je výsledek FALSE.

Import Exekučních titulů

Nejdříve založí soud, který vydal exekuční titul. Pak se provede dotaz databáze Evolia, jestli importovaný titul už v evoliu existuje. Importér se ptá pomocí tohoto SQL dotazu
SELECT implExTituly.extID FROM implExTituly INNER JOIN implExVazbaSpisTitul ON implExTituly.extID = implExVazbaSpisTitul.vstIDTitul WHERE (replace(implExTituly.extCislo,' ','') = N'CISLO_TITULU_XML') AND (implExTituly.extIDVydal = EVOLIO_ID_SOUDU_XML)

Pokud existuje, pak se hodnota primárního klíče titulu z Evolia použije pro vazbu s importovaným případem. Pokud titul neexistuje je do případu založen.

Import Rozúčtovacího profilu

Pokud už oprávněný případu v Evoliu existuje a má u sebe nastavený rozúčtovací profil s danou platností od, které je starší než datum zahájení případu, pak je tento profil přenesen do nastavení případu v přehledu financí.

Založení Subjektu z XMl do Evolia standardizovanou cestou

Do pomocných proměnných rc (pro rodné číslo), ico (pro ičo), jmeno a prijmeni (pro jméno a příjmení), firma (pro jméno firmy) se uloží i prázdný obsah z TAGů RC (do rc), IC (do ic), Jmeno (do jmeno), Prijmeni (do prijmeni), JmenoFirmy (do firma).
Podmínkou je, že TAGy musí existovat v TAGu UdajeSubjektu. U jména příjmení musí existovat oba dva TAGy naráz.
Nyní se přistupuje k importu. Nejprve se zjišťuje, jestli existuje daný subjekt v Evoliu dle ičo nebo rodného čísla nebo názvu firmy nebo jména a přijmení (přesně v tomto pořadí, jak je zde uvedeno).
Pokud se hledá subjekt dle ičo je použit tento SQL dotaz
SELECT ČÍSLO_KLIENTA FROM Klienti WHERE IČO = N'ICO'

Pokud se hledá subjekt dle rodného čísla je použit tento SQL dotaz
SELECT ČÍSLO_KLIENTA FROM Klienti WHERE (replace(replace(replace(RODNÉ_ČÍSL,' ',''),'/',''),'-','') = N'RODNE_CISLO')

Přičemž RODNE_CISLO je zbaveno pomlček, lomítek a mezer.
Pokud se hledá subjekt dle názvu firmy je použit tento SQL dotaz
SELECT ČÍSLO_KLIENTA FROM Klienti WHERE společnost = N'FIRMA'

Pokud se hledá subjekt dle jména a příjmení je použit tento SQL dotaz
SELECT ČÍSLO_KLIENTA FROM Klienti WHERE jméno = N'JMENO' and příjmení = 'PRIJMENI'

Jaké hledání se spustí záleží, jaké hodnoty jsou vyplněné. Pokud je tedy například ičo prázdné a rodné číslo ne, hledá se dle rodného čísla.
Priorita ve vyhledávání, jak jsem na začátku této sekce předeslal, je takováto:
  1. IČO
  2. Rodné číslo
  3. Název firmy
  4. Jméno a příjmení
    Pokud je subjekt dle některých kriterií nalezen v Evoliu, pak se testuje vyplněnost proměnných rc, ico, firma, jmeno a prijemni.
    Pokud jsou prázdné firma, ico a rc, pak logicky došlo nalezení subjektu dle jména a příjmení. Importér o této situaci informuje uživatele a zároveň mu sdělí (Subjekt JMENO PRIJMENI byl nalezen v Evoliu dle jména a příjmení. Bude založen jako nový.), že založí subjekt nový. Importér založí nový subjekt.

Pokud je prázdné rc a ico a firma ne a je v importéru nastaveno, že se mají přepisovat existující subjekty, pak se importér uživatele otáže Subjekt FIRMA byl nalezen dle názvu firmy. Evolio ID Subjektu EVOLIO_ID. Chcete subjekt přepsat tento subjekt daty z importu?. Pokud odpoví uživatel kladně, pak se daný subjekt přepíše a vrátí se původní Evolio ID subjektu. Pokud uživatel odpoví negativně, pak se importér uživatele optá Subjekt FIRMA byl nalezen dle názvu firmy. Evolio ID Subjektu EVOLIO_ID. Chcete subjekt použít tento subjekt z Evolia?. Pokud uživatel odpoví kladně, vrátí se původní Evolio ID subjektu. Pokud uživatel odpoví negativně, založí se nový subjekt a vrátí se nové Evolio ID právě založeného subjetku.
Pokud je prázdné rc a ico a firma ne a není v importéru nastaveno, že se mají přepisovat existující subjekty, pak se importér uživatele otáže Subjekt FIRMA byl nalezen dle názvu firmy. Evolio ID Subjektu EVOLIO_ID. Chcete subjekt použít tento subjekt z Evolia?. Pokud uživatel odpoví kladně, vrátí se původní Evolio ID subjektu. Pokud uživatel odpoví negativně, založí se nový subjekt a vrátí se nové Evolio ID právě založeného subjetku.
Pokud je ico nebo rc neprázdné a je v importéru nastaveno, že se mají přepisovat existující subjekty, pak se daný subjekt přepíše bez ptaní (tady má importér jistotu, že skutečně nemůže o jiný subjekt, protože se shoduje v jedinečných hodnotách ičo | rodné čslo) a vrátí původní Evolio ID subjektu.
Pokud je ico nebo rc neprázdné a není v importéru nastaveno, že se mají přepisovat existující subjekty, pak se vrátí původní Evolio ID subjektu.
Toto vše se děje, když se nalezne subjekt v Evoliu dle z některého kritérií. Navíc u otázek u subjektů je implementovaná možnost automatizované odpovědi, aby uživatel nemusel odpovídat stále dokolečka to samé. Pokud tedy bude uživatel chtít uložit odpověď během importu subjektu, může tak učinit. Tato funkcionalita automatické odpovědi je pouze u importu subjektů a pamatuje se právě v jednom importu. Pro další nový import je opět uživatel vyzván k uložení automatizované odpovědi.
Pokud není subjekt z XML v Evoliu nalezen, pak je založen a je vráceno nové Evolio ID subjektu.

Převod financí

Úroky

U částek, sloužící jako základ úroku, to probíhá stejně jako u jistiny.
U výběru typu to probíhá stejnou metodikou jako u příslušenství. Výjimku tvoří položky PevnyDenniPoplatek a PevnyTydenniPoplatek , kdy se bere hodnota z Evolio3 místo Evolio2.
Interval úroku se určuje dle ZpusobuVypoctu z XML, kde:
  • Rocni = Ročně v Evoliu
  • Denni = Denně v Evoliu
  • Mesicni = Měsíčně v Evoliu
  • Tydenni = Týdně v Evoliu
  • PevnyDenniPoplatek = Denně v Evoliu
  • PevnyTydenniPoplatek = Týdně v Evoliu
  • UrokZaZapocatyMesic = Měsíčně v Evoliu
  • PevnyDenniPoplatek a PevnyTydenniPoplatek nastavuje příznak, že položka je opakovanou částkou, tím pádem se bere typ položky z Evolio3.
    U Rocni je zohledňována i metodika výpočtu a to tak, že pokud TypCas obsahuje 365, pak je roční úročení v Evoliu nastaveno na typ 365 a jinak na 360.

od Verze 7.0.14

Importér kontroluje u úroků repo sazbou, jestli je interval úročení ročně 365. Pokud ne, uživatel je varován o tomto problému a importér převede automaticky interval na ročně 365.

Úroky

U částek, sloužící jako základ úroku, to probíhá stejně jako u jistiny.
U výběru typu to probíhá stejnou metodikou jako u příslušenství. Výjimku tvoří položky PevnyDenniPoplatek a PevnyTydenniPoplatek , kdy se bere hodnota z Evolio3 místo Evolio2.
Interval úroku se určuje dle ZpusobuVypoctu z XML, kde:
  • Rocni = Ročně v Evoliu
  • Denni = Denně v Evoliu
  • Mesicni = Měsíčně v Evoliu
  • Tydenni = Týdně v Evoliu
  • PevnyDenniPoplatek = Denně v Evoliu
  • PevnyTydenniPoplatek = Týdně v Evoliu
  • UrokZaZapocatyMesic = Měsíčně v Evoliu
  • PevnyDenniPoplatek a PevnyTydenniPoplatek nastavuje příznak, že položka je opakovanou částkou, tím pádem se bere typ položky z Evolio3.
    U Rocni je zohledňována i metodika výpočtu a to tak, že pokud TypCas obsahuje 365, pak je roční úročení v Evoliu nastaveno na typ 365 a jinak na 360.

od Verze 7.0.14

Importér kontroluje u úroků repo sazbou, jestli je interval úročení ročně 365. Pokud ne, uživatel je varován o tomto problému a importér převede automaticky interval na ročně 365.

Úroky

U částek, sloužící jako základ úroku, to probíhá stejně jako u jistiny.
U výběru typu to probíhá stejnou metodikou jako u příslušenství. Výjimku tvoří položky PevnyDenniPoplatek a PevnyTydenniPoplatek , kdy se bere hodnota z Evolio3 místo Evolio2.
Interval úroku se určuje dle ZpusobuVypoctu z XML, kde:
  • Rocni = Ročně v Evoliu
  • Denni = Denně v Evoliu
  • Mesicni = Měsíčně v Evoliu
  • Tydenni = Týdně v Evoliu
  • PevnyDenniPoplatek = Denně v Evoliu
  • PevnyTydenniPoplatek = Týdně v Evoliu
  • UrokZaZapocatyMesic = Měsíčně v Evoliu
  • PevnyDenniPoplatek a PevnyTydenniPoplatek nastavuje příznak, že položka je opakovanou částkou, tím pádem se bere typ položky z Evolio3.{BR}
    U Rocni je zohledňována i metodika výpočtu a to tak, že pokud TypCas obsahuje 365, pak je roční úročení v Evoliu nastaveno na typ 365 a jinak na 360.

od Verze 7.0.14

Importér kontroluje u úroků repo sazboum jestli je interval úročení ročně 365. Pokud ne, uživatel je varován o tomto problému a importér převede automaticky interval na ročně 365.

Převod částky z řetězce

Číslo v XML je prezentováno jako řetězec. Importér nahradí případnou tečku čárkou a převede jej násilně dle českého jazykového nastavení OS na číslo. Vždy převádí dle českého jazykového nastavení a předpokládá ale, že v desetinným oddělovačem je čárka.

7.0.3

Souběžné zpracování spisů

Od verze 7.0.3 je zakázáno spustit souběžně dva importy spisů. O činnost zákazu nebo povolení se stará nová komponenta Evolio User Activity Monitor (UAM).
UAM se spustí a nakonfiguruje inhed po spuštění importéru. Zobrazuje a hlídá akce s názvem XML Import spisů. Pokud uživatel chce importovat spisy pro jistotu se importér na začátku zeptá, jestli je jediný, co importuje spisy. Pokud odpoví kladně, vytvoří se akce do UAMu s názvem XML Import spisů s dalšími podrobnostmi (uživatel Evolia a Windows, OS, PC, IP, akce, stav, aplikace, verze, začátek akce) a teprve potom vybere XML k importu. Okénko v pravé části importéru zobrazuje všechny uživatele, kteří spustili akci XML Import spisů. Zobrazení obnovuje v uživatelsky definovaném intervalu (při novém spuštění importéru vždy 60) nebo případně po stisknutí obnovovacího tlačítka. Poté, co uživatel akci ukončí, je akce vymazána a zmizí z UAMu. V UAMu importéru se zobrazují všichni uživatelé s akcí XML Import spisů.
Pokud tedy se uživatel rozhodne importovat spisy, importér se zeptá UAMu, jestli někdo druhý již tak nečiní. Pokud tak již někdo činí, je uživateli zobrazeno hlášení a import se nespustí. Poté až zmizí z UAMu všichni jiní uživatelé než aktuální, teprve potom je dovoleno aktuálnímu uživateli importovat spisy.

Souběžné zpracování je zakázáno z důvodu generování čísla spisu. V 100% případů importů by vzniklo duplicitní číslo spisu. A řešení Constraintem nad SmlouvyProdukt.Číslo_smlouvy sice zajistí jedinečnost, ale bude způsobovat vyjímky v importéru a uživatel pak naimportuje 20, 30% procent záznamů z XML a bude muset import opakovat.

Při každém spuštění importéru se UAM resetuje. Vymaže všechny akce, které se shodují v názvu akce (XML Import spisů), názvu aplikace, verze aplikace, OS ,PC ,IP a Windows uživatele. Tyto akce jsou považovány za naplatné. To zajistí, že uživatel je schopen opakovat import po náhlém pádu aplikace.{BR}

Z této funkcionality vyplývá jedna logická chyba. Souběžné zpracování může spustit pouze tentýž uživatel z téhož PC a to tak, že spustí importér a dá import spisů a čeká u výběru XML. Tady už má vytvořenou akci. Po té spustí novou instanci aplikace, čímž se mu smaže před tím vytvořená akce a může pohodlně přejít k importu spisů z XML. Zde to byla čistě volba o tom, jestli nutit zodpovědnou osobu mazat záznam ručně z tabulky wLogins po náhlém pádu aplikace a zabránit tak znovupoužitelnosti i jinde v jiných Evoliích nebo se spolehnout na to, že uživatel bude spouštět pouze jednu instanci při importu spisů.

7.0.6

Validace existence soudů v XML

Pro každý soud v exekučních titulech nebo v údajích podání se kontroluje, jestli existuje v Evoliu. Pokud neexistuje pak je soud nevalidní a je nastaveno, že se budou zakládat nové subjekty.

7.0.7

Validace povinných v XML

Pro každý subjekt z XML, který je v elementu Povinny, se kontroluje jestli existuje v Evoliu (dle ičo nebo rč). Pokud ano, kontroluje se shoda ve jméně, příjmení a společnosti. Kontrola probíhá na každou hodnotu zvlášť a to jen v případě, že tuto hodnotu má v XML subjekt vyplněnou. Čili pokud povinný bude mít vyplněno pouze JmenoFirmy, kontroluje se tedy pouze název firmy. Pokud se zjistí pro nějakou z hodnot rozdíl, pak není povinný validní a je nastaveno, že v XML existují povinní, kteří dle ičo nebo rodného čísla existují v Evoliu, ale neshodují se ve jméně, příjmení nebo společnosti.

Evolio User Activity Monitor (kdo, kdy, kde a co)

Jde o velmi jednoduchý nástroj hlídající a zobrazující aktivitu přihlášených uživatelů do aplikace. UAM pracuje s tabulkou wLogins.

Programová dokumentace




Možná hlášení XML importéru během importu a jejich význam

Načítám data ze souboru SOUBOR.

Importér se pokusí načíst data z předaného souboru.

Data ze souboru SOUBOR načteny.

Importér úspěšné načetl data z předaného souboru.

Nyní proběhne validace souboru SOUBOR.

Importér oznamuje, že provede validaci dat.

Data ve souboru SOUBOR jsou validní.

Importér oznamuje, že data jsou v pořádku a bez závažné chyby.

Během importu se bude zakládat oprávněný nebo jeho právní zástupce. Jste si jisti, že chcete pokračovat v importu?

Při validaci bylo zjištěno, že se bude zakládat do Evolia právní zástupce nebo oprávněný. Nyní je na uživateli rozhodnout, jestli chce pokračovat v importu.

V importovaných datech se nacházejí případy, které jsou již v Evoliu. Jste si jisti, že chcete pokračovat v importu?

Při validaci bylo zjištěno, že některé případy v XML již existují v Evoliu. Nyní je na uživateli rozhodnout, jestli chce pokračovat v importu.

Import ze souboru SOUBOR bude proveden.

Importér oznamuje, že provede import tohoto souboru do Evolia.

Import ze souboru SOUBOR nebude proveden.

Importér oznamuje, že neprovede import tohoto souboru do Evolia.

Data ve souboru SOUBOR nejsou validní. Import nebude proveden.

Při validaci došlo k závažné k chybě v datech a proto se importér rozhodl, že neprovede import dat do Evolia.

Chybí nastavení importéru, import nebude proveden.

Importér oznamuje, že mu chybí nastavení provedení importu dat a že se tudíž nemá podle čeho orientovat. Proto se rozhodl, že neprovede import.

Soubor SOUBOR neexistuje a proto import nebude proveden.

Soubor, který byl importéru předán na dané umístění neexistuje a tudíž nelze ani provést import dat.

Import skončil.

Importér dokončil import (úspěšný i neúspěšný) dat do Evolia.

Případ DAVKA_&_ZNACKA bude přeskočen

uživatel zadal v importéru hodnoty pro dávku a značku v XML, od kterých má importér začít importovat. Toto byl případ, který hledanému případu předcházel a proto je přeskočen.

Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu neexistuje a bude založen.

Importér nenašel importovaný případ v Evoliu a tudíž ho do něj nově založí.

Případ v pořadí {0} neobsahuje TAG UdajePodani. To je nedovolený stav. Import tohoto případu nebude proveden.

Importér případu z XML nenašel žádné základní informace o něm, podle kterých by se ho snažil najít v Evoliu a podle kterých by ho případně importoval do Evolia a proto nemohl provést ani jeho import.

Případ v pořadí PORADI obsahuje více jak 1 TAG UdajePodani. To je nedovolený stav. Import tohoto případu nebude proveden.

Importér našel více záznamů k základním informacím o případu v XML (více dávek a značek), tudíž by nedokázal jednoznačně určit, o který případ se skutečně jedná, proto import raději neprovedl.

Importovaná data neobsahují potřebný TAG UdajePodani. To je nedovolený stav. Import nebude proveden.

V importovaném XML souboru chybí úplně důležitý TAG UdajePodani, proto nebude proveden import vůbec.

Importovaná data neobsahují potřebný TAG Pripad. To je nedovolený stav Import nebude proveden.

Importér nemohl najít v XML TAG Pripad, který obsahuje informace o jednotlivých případech k importu. Zřejmě uživatel importuje nesprávné XML.

Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu existuje. Chcete jej skutečně VOLBA_CHOVANI?

Případ nalezl v Evoliu případ, který se snaží importovat z XML a ptá se uživatele, jestli s ním skutečně provést operaci zvolenou uživatelem v hlavním okně importéru.

V Evoliu existující případ PRODUKT se značkou ZNACKA a dávkou DAVKA bude přepsán.

Nalezený případ v Evoliu bude přepsán tím z XML.

V Evoliu existující případ PRODUKT se značkou ZNACKA a dávkou DAVKA bude založen jako nový.

Nalezený případ v Evoliu bude zachován a založí se nový z XML.

Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu existuje více než jednou POCET. Chcete je skutečně VOLBA_CHOVANI? Při NE se import zastaví.

Importér nalezl importovaný případ z XML v Evoliu více než jednou a ptá se uživatele, jestli má pokračovat v importu.

Chcete přepsat případ CISLO_PRIPADU v Evoliu případem se značkou ZNACKA a dávkou DAVKA z XML?

Importér se ptá uživatele, jestli skutečně chce přepsat nalezený případ v Evoliu tím z XML.

Chcete založit případ se značkou ZNACKA a dávkou DAVKA z XML, přestože takový případ už v Evoliu existuje CISLO_PRIPADU?

Importér se ptá uživatele, jestli skutečně chce nalezený případ v Evoliu ponechat a založit nový případ z XML.

Do Evolia bude založen nový případ se značkou ZNACKA a dávkou DAVKA z XML, přestože takový případ už v Evoliu existuje CISLO_PRIPADU.

Importér informuje, že založil nový případ z XML do Evolia, přestože už tam takový je.

Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu existuje SEZNAM_CISLO_PRIPADU. Import bude ukončen.

Importér našel v Evoliu k importovanému případu z XML již existující případ a proto ukončil import.

Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu existuje SEZNAM_CISLO_PRIPADU. Import bude pokračovat a případ nebude přepsán.

Importér našel v Evoliu k importovanému případu z XML již existující případ, proto importovaný případ z XML přeskočí a bude pokračovat dál v importu.

Pro případ DAVKA_&_ZNACKA s id XML_ID není přítomna nebo je prázdná tabulka (TAG): ExTitul. Import exekuční titulů nebude proveden.

Importér nenašel v XML TAG pro exekuční tituly, proto neprovede import exekučních titulů.

Pro případ DAVKA_&_ZNACKA s id XML_ID není přítomna nebo je prázdná tabulka (TAG): Narok. Import financí nebude proveden.

Importér nenašel v XML TAG pro finance, proto neprovede import financí.

Pro případ DAVKA_&_ZNACKA s id XML_ID bylo nalezeno rozdílný počet záznamů POCET v tabulce (TAGu) UdajePodani než je vyžadováno. Je vyžadován právě 1 záznam. Import nebude proveden.

Při importu případu z XML, importér zjistil, že importovaný případ má více TAGů UdajePodani než jeden. Neprovedl import tohoto případu, protože je případ v XML určen nejednoznačně.

Pro případ DAVKA_&_ZNACKA s id XML_ID není přítomna nebo je prázdná některá z těchto tabulek (TAGů): UdajePodani, Opravneny, Povinny. Import nebude proveden.

Importéru chybí důležíté TAGy pro import případu, proto případ neimportuje.

Případ DAVKA_&_ZNACKA v XML není uvedena žádná jistina. Chybí TAG Jistina.

Importér zjistil, že v importovaném případu z XML není zadána jistina.

V XML nejsou uvedeny žádné jistiny. Chybí TAG Jistina u všech případů.

Importér zjistil, že v žádném případu v XML není zadaná jistina.

Případ DAVKA_&_ZNACKA: Zpracovávám finanční položku NAZEV_FINANCNI_POLOZKY_Z_XML.

Importér převádí konkrétní položku konkrétního případu do Evolia.

Případ DAVKA_&_ZNACKA v XML není uvedeno žádné přílušenství. Chybí TAG Prislusenstvi.

Importér zjistil, že v importovaném případu z XML není zadáno příslušenství.

V XML není uvedeny žádné příslušenství. Chybí TAG Prislusenstvi u všech případů.

Importér zjistil, že v žádném případu v XML není zadáno příslušenství.

Případ DAVKA_&_ZNACKA v XML není uveden žádný úrok. Chybí TAG DefiniceUroku.

Importér zjistil, že v importovaném případu z XML není zadán úrok.

V XML není uvedeny žádné úroky. Chybí TAG DefiniceUroku u všech případů.

Importér zjistil, že v žádném případu v XML není zadán úrok.

Případ DAVKA_&_ZNACKA v XML nejsou uvedeny žádné finance. Chybí TAG Narok.

Importovaný případ nemá finance.

V XML nejsou uvedeny žádné finance. Chybí TAG Narok u všech případů.

Žádný případ z XML nemá finance.

Případ DAVKA_&_ZNACKA: U údajů subjektu k oprávněným je očekáván pouze 1 záznam. Nicméně zde je jich POCET. Oprávněný se nebude zakládat.

V importovaném případu je nejednoznačně určený oprávněný, proto ho importér nepřevedl.

Případ DAVKA_&_ZNACKA: Tabulka TAG údaje subjektu je prázdná nebo neexistuje. oprávněný se nebude zakládat.

V XML chybí nacionále subjektů.

Pro Případ DAVKA_&_ZNACKA: právní zástupce NAZEV_SUBJEKTU má více než 1 adres nebo žádnou (POCET), proto bude založen normální cestou zakládání subjektů.

Přestože je v importéru nastavena možnost Právní zástupce: při jiné adrese téhož subjektu založ subjekt nový, je právní zástupce založen standardní cestou, protože má u sebe více adres a je tudíž nemožné určit, kterého zástupce použít z Evolia.

Případ DAVKA_&_ZNACKA: U údajů subjektu k právním zástupcům je očekáván pouze 1 záznam. Nicméně zde je jich POCET. Právní zástupce se nebude zakládat.

V importovaném případu je nejednoznačně určený právní zástupce, proto ho importér nepřevedl.

Pro případ DAVKA_&_ZNACKA: Tabulka právních zástupců je prázdná nebo vůbec neexistuje. Případně chybí TAG UdajeSubjektu.

V XML chybí právní zástupci nebo chybí nacionále všech subjektů v XML.

Případ DAVKA_&_ZNACKA: U údajů subjektu k povinným je očekáván pouze 1 záznam. Nicméně zde je jich POCET. Povinný se nebude zakládat.

V importovaném případu je nejednoznačně určený povinný, proto ho importér nepřevedl.

Případ DAVKA_&_ZNACKA: Tabulka TAG údaje subjektu je prázdná nebo neexistuje. Povinný se nebude zakládat.

V XML chybí nacionále subjektů.

Případ DAVKA_&_ZNACKA: U údajů subjektu k příslušným soudům je očekáván pouze 1 záznam. Nicméně zde je jich POCET. Příslušný soud se nebude zakládat.

V importovaném případu je nejednoznačně určený příslušný soud případu, proto ho importér nepřevedl.

Případ DAVKA_&_ZNACKA: Tabulka TAG údaje subjektu je prázdná nebo neexistuje. Příslušný soud se nebude zakládat.

V XML chybí nacionále subjektů.

Případ DAVKA_&_ZNACKA: U příslušných soudů je očekáván pouze 1 záznam. Nicméně zde je jich POCET. Příslušný soud se nebude zakládat.

Importér zjistil, že importovaný případ z XML obsahuje více příslušných soudů a proto nebyl soud založen.

Případ DAVKA_&_ZNACKA: Tabulka TAG příslušných soudů je prázdná nebo neexistuje. Příslušný soud se nebude zakládat.

Všechny případy v XML nemají k sobě přiřazený příslušný soud.

Subjekt JMENO PRIJMENI byl nalezen v Evoliu dle jména a příjmení. Bude založen jako nový.

Importér našel subjekt z XML pouze dle jména a příjmení a proto ho hodlá založit znovu, protože jméno a příjmení není jednoznačné určení subjektu.

Subjekt FIRMA byl nalezen dle názvu firmy. Evolio ID Subjektu EVOLIO_ID. Chcete subjekt přepsat tento subjekt daty z importu?

Importér nalezl importovaný subjekt, dle názvu firmy v Evoliu a ptá se uživatele, jestli ho může přepsat.

Subjekt FIRMA byl nalezen dle názvu firmy. Evolio ID Subjektu EVOLIO_ID. Chcete subjekt použít tento subjekt z Evolia?

Importér nalezl importovaný subjekt, dle názvu firmy v Evoliu a ptá se uživatele, jestli může použít subjekt z Evolia.

Subjekt FIRMA_JMENO_&_PRIJMENI nebyl nalezen v Evoliu. Bude založen jako nový.

Importér informuje uživatele, že subjekt v Evoliu nenašel a že jej tedy založí do Evolia.

Adresa ULICE, MESTO, PSC v subjektu Evolia NAZEV_SUBJEKTU již existuje a proto nebude založena

Importér nenašel převáděnou adresu u subjektu v Evoliu a proto danou adresu k subjektu v Evoliu přidá.

Do Klienta NAZEV_SUBJEKTU nemohou být převedena data z Adresa, protože v datech subjektu Evolia chybí tabulka KlientiAdresy anebo v importovaných datech chybí nebo je prázdná tabulka (TAG) Adresa.

Importér nenalezl jednu ze dvou nebo obě dvě potřebné tabulky pro import adresy.

Do Klienta NAZEV_SUBJEKTU nemohou být převedena data z UdajeSubjektu, protože v datech subjektu Evolia chybí nebo je prázdná tabulka Klienti. Tabulka nesmí být prázdná ani u nového klienta.

Importér nenalezl hlavní tabulku Evolio subjektu nutnou pro převod.

Případu Značka ZNACKA, dávka DAVKA bylo přiděleno číslo spisu CISLO_PRIPADU.

Importér informuje jaké přiřadil číslo spisu v Evoliu případu z XML.

Případ CISLO_PRIPADU bude nyní z Evollia vymazán.

Importér se chystá vymazat případ z Evolia.

Případ CISLO_PRIPADU byl vymazán z Evolia

Importér vymazal případ z Evolia.

Pro případ DAVKA_&_ZNACKA z XML pro Evolio ID EVOLIO_ID nemá ve svých datech tabulku SmlouvyProdukt nebo je prázdná. Přepsání případu DAVKA_&_ZNACKA nebylo provedeno.

Importér nenašel v date případu Evolia tabulku nutnou pro převod případu.

Pro ExeTitulVydal je vice zaznamu v UdajeSubjektu. Soud k exekučnímu titulu bude chybět.

Importér nalezl více než jeden soud v exekučních titulech a proto jej nepřevedl.

Chybi TAG UdajeSubjektu v ExeTitulVydal. Soud k exekučnímu titulu bude chybět.

V XML chybí nacionále subjektů a do exekučního titulu v Evoliu se soud nedostane.

Případ DAVKA_&_ZNACKA: interval úroku INTERVAL_Z_XML není u úroku reposazbou přípustný. Bude nastaven na Rocne365.

Impotér indefikoval špatný typ úročení u úroku reposazbou. A hlásí, že ho změní dle sebe.

Možná hlášení XML importéru během validace a jejich význam

Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu už existuje (SEZNAM_CISLO_PRIPADU).

Importér informuje, že nalezl shodné případy v Evoliu k případu z XML.

Případ PRODUKT se značkou ZNACKA a dávkou DAVKA v Evoliu už neexistuje.

Importér informuje, že nenalezl žádné shodné případy v Evoliu k případu z XML.

Pro případ DAVKA_&_ZNACKA patří k právnímu zástupci více než 1 TAG UdajeSubjektu.

Právní zástupce je nejednoznačně určen.

Pro případ DAVKA_&_ZNACKA nepatří k právnímu zástupci žádný TAG UdajeSubjektu. Právní zástupce je zřejmě prázdný.

Právní zástupce nemá žádné nacionále.

DAVKA_&_ZNACKA v případu právní zástupce nemá žádné adresy jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Právnímu zástupci chybí adresa.

DAVKA_&_ZNACKA v případu právní zástupce má 1 adresu a existuje již v Evoliu a nebude tudíž založen. Jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Právní zástupce s 1 konkrétní adresou byl nalezen v Evoliu importérem a neměl by být založen.

DAVKA_&_ZNACKA v případu právní zástupce se má založit do Evolia jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Právní zástupce bude zřejmě založen do Evolia.

DAVKA_&_ZNACKA v případu právní zástupce má více než 1 adresu jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Právní zástupce má u sebe více než 1 adresu.

Pro případ DAVKA_&_ZNACKA patří k oprávněnému více než 1 TAG UdajeSubjektu.

Oprávněný je nejednoznačně určen.

Pro případ DAVKA_&_ZNACKA nepatří k oprávněnému žádný TAG UdajeSubjektu. Oprávněný je zřejmě prázdný.

Oprávněný nemá žádné nacionále.

Bude se do Evolia zakládat nový oprávněný. Jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Importér bude zřejmě zakládat nového oprávněného do Evolia.

Bude se do Evolia zakládat nový právní zástupce. Jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Importér bude zřejmě zakládat nového právního zástupce do Evolia.

Oprávněný postrádá v XML ičo a rč. Jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Importér informuje, že oprávněný nemá ičo ani rodné číslo.

Právní zástupce postrádá v XML ičo a rč. Jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Importér informuje, že právní zástupce nemá ičo ani rodné číslo.

V importovaných datech jsou POCET různí oprávnění.

V XML je více než 1 oprávněný.

Oprávněný JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

Informace o oprávněném.

V importovaných datech je 1 oprávněný. Jméno: JMENO, příjemní: PRIJMENI, název firmy: FIRMA ič: ICO, rč RC.

V XML je 1 oprávněný.

V importovaných datech není žádný oprávněný.

V XML není žádný oprávněný.