Stav addinu: v běžném provozu
Počet uživatelů (úřadů): 10+

CAP

Česká asociace pojišťoven je zájmovým sdružením vytvořeným podle občanského zákoníku na organizaci a podporu vzájemné pomoci, spolupráce a zabezpečení zájmů pojišťoven a zajišťoven.  Jejím posláním je koordinovat, zastupovat, hájit a prosazovat společné zájmy pojišťoven ve vztahu k orgánům státní správy a dalším osobám i ve vztahu k zahraničí.

Tento addin tedy umožňuje získávat informace přímo ze systému asociace pomocí aplikace Evolio.

Subjekt

Subjekt je daná osoba nebo firma vyskytující se v registru.

Stavy subjektu

Subjekty mají stav podle toho jak je úspěšná komunikace se serverem. Mohou být následující:

Empty – žádný stav

Skipped –  Nastala chyba při zpracovaní v RC/ ICO

Error – nastala obecná chyba

RequestSend – odeslaný požadavek

Received – přijata odpověď

AllImported – všechny odpovědi jsou naimportováni

WaitingForResponses – čeká se na odpovědi z několika pojišťoven

Druhá fáze

Validuje všechny subjekty a odesílá požadavky na pojišťovně přes datové zprávy.

Vstupní parametry:

Průvodní dopis – defaultně je nahraný originální dopis, možnost přidáni vlastního
Jedinečný 3-místní kód – odpovědného zaměstnance Exekutora v rámci exekutorského úřadu

Detailní popis pro zpracovaní jednoho subjektu v HS:

1. Kontrola či má subjekt Rodné číslo(dále jen RČ)/IČO
   
2. Kontrola správnosti RČ/IČO (počet znaku, validace atd.)
   
3. V případě chybějících nebo nevalidních informací je subjekt přepnutí na stav Skipped s popisem chyby
   
4. Jestli kontrola proběhne v pořádku zařadíme do záznamu na odeslaní
   

Příprava na Odeslání

Adresa datové schránky, kam se posílají žádosti se převezme pomocí příkazu Select v databázi:

select ka.klaIdDatoveSchranky from ProcesyAdres pa
join KlientiAdresy ka on pa.klaID = ka.klaID
where pa.typ=‚CAP‘

Údaje v xml žádosti

Vygeneroval = „Evolio“ TypDotaz= „SOUC“, EUrad = select exCislo from implExExekutor
Zprava = „žádost o součinnost“;

Pro každý subjekt platí:

• Pokud má IČO a RČ vložíme jej dvakrát!
  
• Každý subjekt musí mít uvedené hodnoty ID což je RČ/IČO, TypID tentokrát text RČ/IČO, jako Název se uvádí jméno a příjmení a nakonec CJEU je číslo spisu
  
• Zapsaní stavu subjektu je do tabulky LustracePojistovny
  

Název xml

EU[kodEU][kodZamestnanca]_[datum(yyMMdd)] _[poradove cislo]_dot.xml

Tabulka LustracePojistovny

Do tabulky se vloží záznam pro každého příjemce žádosti s hodnotami v podobě:

IDKlientPovinny = číslo Klienta, PoradoveCisloZadost =číslo žadosti
IDSmlouvySpis, IDSmlouvyHS, Importovano = false, Timeouted = false
PojistovnyID- RC/ICO(hodnoty), PojistovnyIDTyp =RC/ICO(text)
DatumOdeslaniPozadavku = Now, StavZmena = Now, Stav= RequestSend
PojistovnaDatovaSchranka= id DS kam se posílá žádost
StavPopis = „Požadavek byl odeslán na pojistovnu „+ adresát

Možné stavy v tabulce LustracePojistovny

ReqestSend: Odeslaný požadavek

ResponseReceived: Přijatá odpověď

ADataImported: Odpověď naimportována

SubjectNotFound: Nedohledán v databázi u spisu jako povinný

TimeOuted: Vypršel Timeout (příliš dlouhá doba odpovědi serveru)

ImportError: Chyba při zpracovaní odpovědi

Před vložením zkontroluje, zda záznam existuje. (Při odesílaní mohlo skončit chybou, ale data již jsou v tabulce)

Odesláni datové zprávy lze provádět v transakci

1. Transakce získá průvodní dopis z Nastavení nebo přidá defaultní.
   
2. Vloží dopis do databáze. Vytvoří datovou zprávu, přiloží xml a dopis.
   
3. Datová zpráva má kategorii „Součinost“, predmět „Žádost o poskytnutí hromadné součinnosti“, a výsledek „CAP“ .
   
4. Poté odešle všem pojišťovnám a nastaví subjektům stav RequestSend
   
5. V případě chyby skončí hromadná součinnost v druhé fázi chybou Error s jejím popisem
   
6. Do Tiket.Kind se zapíše datum odesláni (aby se zbytečně nemuselo užívat databáze, kde byla hromadná součinnost vytvořena)
   

Třetí fáze

Vstupní parametry

Úkol pro (v případě nečitelného XML): –
Úkol pro (v případě neznámého CJVyzvy): –
Timeout: Importovat, když nepřijde odpověď po předem daný časový úsek. Defaultně  nastaveno 30 dní.
WorkDir: pracovní složka pro lustrace CAP

1.Část – Načtení odpovědí a aktualizace LustracePojistovny

Addin si načte všechny odpovědi přes proceduru spGetLustracePojistovnyDataboxMessages

V podatelně je pošta se sloupcem podESTyp= ‚CP‘, tuto hodnotu nastavuje trigger trFillPodEsTyp.

Pokud nejsou nalezené žádné odpovědi z pojišťovny addin končí.

Spravováni jednotlivých odpovědí

• Jestli není xml čitelné, vytvoří se úkol dle nastavení.
  
• Z odpovědi se získá CJVyzvy a jestli neexistuje v tabulce SmlouvyProdukt tak se vytvoří úkol
  
• Poté se pokusí dohledat hromadná součinnost na cestě WorkDir a název hromadné součinnost (Jestli neexistuje zkontroluje či není po Timeout-u) Pokud je po Timeout-u, tak se pošta přepne na „ZV“ a aktualizuje se záznam v LustracePojistovny na stav Timeout
  
• Začnou se zpracovávat jednotlivé odpovědi k subjektům
  

Zpracovaní jednotlivých subjektů z jedné odpovědi

1. Aktualizace tabulky LustracePojistovny
   

Vyhledá se záznam na základě parametrů: Idklient, IdSmlouvaHS, PojistovnaDatovaSchranka, PojistovnyID, PojistovnyIdTyp

Aktualizují se hodnoty: IddokumentOdpoved, StavZmena, Stav, DatumPrijetiOdpovedi, IdPodOdpoved, IDPodOdpovedAdresa,

StavPopis= „Byla přijata odpověď z pojišťovny s datovou schránkou:

Pokud se subjekt nenajde v databázi nebo záznam v LustracePojistovny, addin skončí chybou a začne číst další odpověď.

2. Aktualizace Stavu subjektu v hromadné součinnosti
   

Změní se stav subjektu na Received.

Po úspěšném zpracovaní správy se změní stav pošty na ZV.

2.Část – Aktualizace hromadné součinnosti

Vyberou se všechny součinnosti, které jsou v třetí fázi ve stavu Ready.

Jestli má některý subjekt stav Received, součinnost se přepne do čtvrté fáze.

Pokud není tak se zkontroluje Timeout. Primárně z ticket.Kind jinak z tabulky LustracePojisovny

Jestli je po TimeOut-u přepne všem subjektům stav z „RequestSend“ nebo „WaitingForResponses“ na stav „TimeOuted“.

Čtvrtá fáze

Vstupní parametry

Ukončenou smlouvu importovat jako Pozitivni_s_ukolem, Pozitivni_bez_ukolu, Negativni
Importovat událost x měsíců od zaplacení -Pokud je událost vyplacená x měsíců pozpátku bude se importovat jako pozitivní odpověď
Timeout – stejná hodnota jako v třetí fázi. Parametr pro proceduru se nazývá spLustracePojistovnySetTimeouted
Úkol pro – komu se budou generovat úkoly

Na začátku addinu se spustí spLustracePojistovnySetTimeouted, která upraví staré lustrace z tabulky LustracePojistovny na stav TimeOut.

Spravováni jednotlivých Subjektů

Subjekt se přeskakuje, když má stav AllImported.

Stav TimeOut značí, že se naimportuje se negativní odpověď s textem U subjektu se nestáhla odpověď

Naopak Skipped importuje negativní odpověď s textem chyby proč nebyl poslán do požadavku (validace RČ/IČO z druhé fáze)

Jestli má Stav Received převedou se všechny odpovědi z tabulky LustracePojistovny na základe clientID, Stav= ResponseReceived, IdsmlouvyHS, timeout=false, Import=False. Poté se zpracují jednotlivé odpovědi. Po zpracovaní se zkontroluje, zda subjekt má naimportovány všechny odpovědi taktéž z LustracePojistovny. Odpověď musí být po Timeout-u nebo Importováno. Jestli se nečeká na žádné odpovědi nastaví se stav na AlImported jinak na WaitingForResponses.

Ke konci fáze se zkontroluje, zda pro celou hromadnou součinnost má už odpovědi. Jestli má všechny odpovědi přepne se do páté fáze, nebo se zopakuje třetí fáze.

Spravováni jednotlivých odpovědi pro subjekt

1. Dojde k ověření, že XML odpověď existuje a že obsahuje data o klientovi. Jestliže neexistuje, výsledek lustrace skončí chybou.
   
2. Proběhne kontrola integrity, tj. existuje subjekt z tabulky LustracePojistovne a z XML v databázi
   
3. Uložení XML (taky vytvořeni html) odpovědi na disk (když je odpověď negativní tak se nevytváří dokumenty)
   
4. Import dat a také aktualizace tabulky LustracePojistovni
   

Import dat

a)Smlouvy

Každá smlouva z odpovědi se importuje následovně. Nejdříve se zkontroluje DatumKonce u smlouvy. Když je menší než aktuální datum, importuje se dle následného nastavení a nebere do úvahy zda je klient pojištěný či pojistník:

1. Negativní – smlouva se přeskočí (neimportuje se nic)
   
2. Pozitivní s úkolem, Pozitivní bez úkolu – princip je stejný jen v případě nové pohledávky se buď vytvoří nebo nevytvoří úkol.
   

Pokud se jedná o otevřenou smlouvu (datum konce není vyplněn nebo je v budoucnu) tak se importuje dle následovných kritérií:

• Smlouva se neimportuje, když klient není pojištěný a zároveň není pojistník
  
•  Klient je Pojištěný tak se jedná o výsledek pohledávky Pozitivní s úkolem
  
• V opačném případě jde o výsledek Pozitivní bez úkolu
  

Princip importu smlouvy:

Prvně se zkontroluje, zda pohledávka existuje v databázi. Hledá se v tabulce ExMajetkoveHodnotyPohledavky a na základe sloupců: mhprPravniDuvod – číslo Pojistné smlouvy, mhIDVlstník – ID klienta, mhtyp – “POJISTNA_SMLOUVA“. Mohou nastat 3 situace:

• V databázi není pohledávka. Importuje se nová. Vyplňují se sloupce: mhpoZadal, mhpoZadano, mhpoPlatne – dle datumKonce u smlouvy, mhpoPravniDuvod – číslo smlouvy, mhpocastka se rovná NarokCastka, mhtyp je “POJISTNA_SMLOUVA“, mhpoIDDluznik se rovná IDpojistovne, mhpoznámka – vypsané všechny informace smlouvy. Výsledek je pozitivní (buď s úkolem nebo bez úkolu) s textem {Typ pojištění} se začátkem {datum začátku} a koncem {datum konce} ve výši nároku {nárok částka}. Záleží na tom, zda je to ukončená smlouva (pak dle nastaveni), nebo otevřená (pak dle kritérií).
  
• Existuje v databázi a shoduje se částka (mhpocastka). Výsledek pohledávky je existující beze změny.
  
• Změna nastane pouze při změně hodnoty NarokCastka. V tom případě se u pohledávky změní sloupce mhpoCasta, mhpoUpraveno, mhpoUpravil. Výsledek pohledávky bude Změna s textem Změna v částce nároku z {původní částka} na {aktuální částka}.
  

Atributy Pojistné smlouvy

b)Pojistná událost (škoda)

Postup spravování pojistné události:

• Pokud je škoda uzavřená tak nás nezajímá a pohledávku přeskakujeme, ale zkontroluje se, zda existuje v databázi a pokud ano tak se zneplatní.
  
• Zavoláme proceduru GetImportSkodysp. Vstupní parametre jsou hodnoty události (Jeposkozeny, Jeprijemce, JePojistnik, JePojisteny, vyplaceno). Systém hledá v tabulce ImportSkodyCAP a vrátí informaci, jak mám událost importovat. Vráti pouze 1- pozitivní nebo 0- negativní. Když by náhodou nevrátila žádnou odpověď tak se pohledávka přeskakuje, protože nevím, jak ji importovat (nemělo by nastat, tabulka ImportSkodyCAP má 32 záznamů tj. všechny možné kombinace- „V tabulce se aktualizuje jen sloupec ImportovatJako“)
  
• Vrátí se 0 -negativní. Tak událost neimportuji (přeskakuji), ale zkontroluje se, zda existuje v databázi a pokud ano, tak se zneplatní.
  
• Jestliže vrátí 1- pozitivní zkontroluji, zda se má událost importovat dle nastavení Importovat událost x měsíců od zaplacení. (Zjistí se datum poslední platby a pokud je událost vyplacená maximálně x měsíců pozpátku, bude se importovat jako pozitivní odpověď. V případě chyby, nepodaří se získat datum, nebo uběhlo počet měsíců nebude se importovat, ale zkontroluje se, zda existuje v databázi a jestli ano tak se zneplatní.
  

Princip importu události:

Nejdříve se zkontroluje, zda pohledávka existuje v databázi. Hledá se v tabulce ExMajetkoveHodnotyPohledavky, se na základe sloupců: mhprPravniDuvod  což je číslo Pojistné smlouvy, mhIDVlstník – ID klienta a mhtyp– “POJISTNA_UDALOST“. Mohou nastat 3 situace podobně jako u smlouvy:

• V databázi není pohledávka. Importuje se nová. Vyplňují se sloupce: mhpoZadal, mhpoZadano, mhpoPlatne – true, mhpoPravniDuvod – číslo udalosti, mhpocastka= Vyplacená částka, mhtyp= “POJISTNA_ UDALOST“, mhpoIDDluznik= IDpojistovne, mhpoznámka – vypsané všechny informace události. Výsledek je pozitivní.
  
• Existuje v databázi a je stejná vyplacená částka (mhpocastka). Výsledek pohledávky je existující beze změny. Upraví se hodnoty mhpoUpraveno, mhpoUpravil
  
• Změna nastane při změně hodnoty V tom případě se u pohledávky změní sloupce mhpoCasta, mhpoUpraveno, mhpoUpravil. Výsledek pohledávky bude Změna s textem Změna ve vyplacené částce z {původní} CZK na {aktuální} CZK.
  

Atributy Pojistné Události

Atributy Platby

Výsledky Lustrací

Výsledek lustraci závisí dle importovaných smluv a škod. Možnosti výsledků zobrazuje následující tabulka.

Ukázka Html výstupu