Okruh riešenia Adm = „Administrácia systému“ pracuje so spoločnými dátami a ich položkami a taktiež s konfiguračnými položkami a číselníkmi. Evidencia založená v tomto okruhu sa používa v celom rade ďalších okruhov.

Množstvo informácií k týmto témam je v prevádzkovej dokumentácii (Prevádzková dokumentácia) resp. v úvode (Úvod spoločný)

2 Dáta okruhu „Adm“

V tejto časti si popíšeme dátové položky a ich skupiny, ktoré sú sledované v rámci okruhu „Adm“.

2.1 Hierarchia členenia spracovávanej organizácie

Organizáciu z hľadiska spracovania našim systémom hierarchicky členíme na

- organizácia

- správna jednotka (SJ)

- správny oddiel (SO)

Význam jednotlivých článkov a ich vzťah je uvedený v technologických poznámkach.

2.1.1 Organizácia

Použitie pojmov organizácie – viď resp. formulár pre správu údajov o Organizáciách Adm21

Kód organizácie

Kód organizácie alebo používateľa nášho systému

Názov

Názov organizácie používaný napríklad v zostavách. Eviduje sa názov

- bežný pre interné zostavy a potreby

- oficiálny pre externé výstupy

Adresa

Adresa organizácie; skladá sa z položiek:

- Názov - použije sa vyššie uvedený oficiálny názov

- ulica

- číslo domu - orientačné/popisné

- PSČ

- Mesto, obec

Dátum implementácie

Dátum implementovania systému

Legislatíva

Označenie legislatívy, pod ktorú systém pre správnu jednotku beží. Zadáva sa podľa riešiteľského číselníku legislatíva s hodnotami:

- CZ česká

- SK slovenská

Ak nie je legislatíva definovaná v tejto položke, je potreba ju definovať u jednotlivých správnych jednotiek.

Časové pásmo organizácie

Hl. organizácia

V prípade, že zákazník používa multiorganizačnú štruktúru, je potrebné definovať, ktorá z organizácií je hlavnou.

Implicitný kód jazyka

Nastavuje jazyk, ktorý sa má implicitne používať pre organizácii. Jazyk sa zisťuje kaskádou: implicitný kód jazyka -> legislatíva organizácie -> jazyk z parametra. Toto nastavenie ovplyvňuje užívateľské zostavy alebo workflow notifikácie.

Zak.

Interné označenie klienta definované autorom SW - na toto označenie môžu byť viazané niektoré úpravy programu špecifické pre konkrétneho zákazníka.

Parametre organizácie

Na úrovni organizácie sa zadáva a eviduje množstvo ďalších parametrov, ktoré sú spoločné pre celú spracovávanú organizáciu a to bez ohľadu na správnu jednotku alebo správny oddiel. Jedná sa o parametre – viď ďalej.

2.1.2 Správna jednotka

Číslo správnej jednotky

Jednoznačná identifikácia správnej jednotky vo vnútri organizácie.

Organizácia

Názov organizácie, pod ktorú vybraná správna jednotka patrí

Názov

Názov správnej jednotky používaný napríklad v zostavách. Eviduje sa názov

- bežný pre interné zostavy a potreby

- oficiálny pre externé výstupy

Legislatíva

Označenie legislatívy, pod ktorou funguje systém pre správnu jednotku. Zadáva sa podľa riešiteľského číselníka legislatíva s hodnotami:

CZ česká

SK slovenská

Platnosť od - do

Vymedzenie obdobia platnosti správnej jednotky. Využije sa napríklad pri reorganizácii.

Adresa

Adresa a kontaktné údaje správnej jednotky; zahŕňa položky:

- názov adresáta

- ulica

- číslo domu - orientačné/popisné

- PSČ

- Mesto, obec

- Štát

- Telefón

- Fax

- E-mail

IČO

Identifikačné číslo organizácie. Vyberá sa z číselníka vykazovacích jednotiek na formulári Adm21, záložka č.IČO

DIČ

Daňové identifikačné číslo organizácie

CZ_NACE, SK_NACE

Prevažujúca odborová kvalifikácia ekonomických činností

Kód územia (NUTS, LAU)

Kód územnej jednotky (okresu), v ktorej má správna jednotka sídlo. Číselník vydáva ŠÚ SR.

CZ parametre :

Kód finančnej kontroly

Kód pre rozlíšenie finančnej kontroly ekonomického subjektu podľa direktívy EU 80/723/EEC pre ISCP/Trexima. Vyplňuje sa podľa číselníka riešiteľa.

Typ kolektívnej zmluvy

Typ kolektívnej zmluvy ekonomického subjektu pre ISCP/Trexima. Vyplňuje sa podľa číselníka riešiteľa.

Právna forma ekonomického subjektu

Vyplňuje sa pre účely sledovania ISP podľa číselníka ŠÚ SR.

Kód kolektívnej zmluvy

Vypĺňa sa pre účely sledovania ISP.

Kód zariadenia bez vlastného IČ

Vyplňuje sa pre účely sledovania ISP správna jednotka bez vlastného IČO.

Číslo správneho úradu

Vypĺňa pre účely sledovania ISoSS správna jednotka, ktorá podáva hlásenie za zamestnancov pracujúcich v služobnom pomere.

Kód OVM

Vypĺňa sa kód organizácie výkonnej moci. Ponúkajú sa položky používateľského JPC sluz_ovm.

VŠ – číslo RID

... Pole pre zadanie RID vysoké školy v prípade, že parameter na formulári Adm01 - "VŠ, fakulta - umiestnenie RID" má hodnotu 1.

Parametre správnej jednotky

Na úrovni správnej jednotky sa zadáva a eviduje množstvo parametrov, ktoré sú spoločné pre celú správnu jednotku, t.j. pre všetky podriadené správne oddiely. Jedná sa o parametre – viď ďalej.

2.1.3 Správny oddiel

Číslo správneho oddielu

Jednoznačné určenie správneho oddielu; vyjadruje taktiež číselné poradie spracovania oddielov v rámci správnej jednotky.

Číslo správnej jednotky

Číslo správnej jednotky, pod ktorú správny oddiel spadá.

Názov

Názov správneho oddielu používaný napríklad v zostavách. Eviduje sa názov bežný pre interné zostavy a potreby.

Platnosť od - do

Vymedzenie obdobia platnosti správneho oddielu.

Adresa

Adresa správneho oddielu; skladá sa z položiek:

- ulica

- číslo domu

- PSČ

- Mesto, obec

VŠ – číslo RID (CZ)

… pole pre zadanie RID vysokej školy v prípade, že parameter „VŠ, fakulta – umiestnenie RID“ má hodnotu 2.

Parametre správneho oddielu

Na úrovni správneho oddielu sa zadávajú a evidujú niektoré parametre – viď ďalej zoznam.

3 Štandardné riešenie okruhu „Adm“

V nasledujúcej tabuľke je uvedený zoznam objektov zaradených do okruhu Adm. V prvom stĺpci je kód objektu, v druhom označenie druhu objektu (F = formulár, P = proces, Z = zostava). Tretí stĺpec popisuje obsah objektu.

Tučným písmom sú označené už riešené a zdokumentované objekty.

Adm01	F	Užívatelia
Adm02	F	Profily (abstraktní užívatelia)
Adm03	F	Role (práva k objektom)
Adm04	F	Objekty práv, konfigurácia
Adm05	F	Objekty práv - menu
Adm06	F	Skupiny riadkových práv (pre číselníky a štruktúry)
Adm07	Z	Užívatelia - práva k riadkom
Adm08	Z	Profily, objektové práva
Adm09	Z	Položky v generátore dotazov
Adm10	F	Užívatelia, Profily, Autentizačný server
Adm11	F	Správa osôb a PV
Adm12	F	Užívatelia Webu
Adm13	F	Ochrana osobných údajov
Adm14	F	Konfigurácia Elanor Workflow
Adm15	F	Zastupovanie vlastnej osoby
Adm17	Z	Užívatelia - export pre audit (excel export)
Adm19	F	Klasifikácia výstupov EGJE
Adm20	F	Pokyny k stiahnutiu
Adm21	F	Konfigurácia – organizácia
Adm22	F	Konfigurácia - správne jednotky
Adm23	F	Konfigurácia - správne oddiely
Adm24	F	Kurzový lístok
Adm25	F	Export číselníkov
Adm26	F	Nastavenie šifrovania a SFTP
Adm27	F	Evidencia certifikátov
Adm28	F	Externé organizácie
Adm31	F	Konfigurácia používateľských položiek
Adm32	F	Konfigurácia hlásení výpočtu
Adm33	F	Konfigurácia textov (pozvánky, kalendár ...)
Adm34	F	Zákaznícke help odkazy
Adm40	Z	Profily, objekty, detaily práv k formulárom
Adm42	F	Nastavení a pojmenování dlaždic HR Portálu
Adm51	F	Zmenové riadenie databázy
Adm52	F	Audit
Adm53	F	Úlohy na AS
Adm54	F	Špeciálny audit
Adm55	F	API a prostriedky
Adm56	F	Definícia pomocníka
Adm57	F	Autentizácia
Adm58	F	Notifikácie na koniec daňových zľav
Adm60	F	Parametrizácia podaní
Adm61	F	Dávky tlačových zostáv
Adm62	F	Správa žiadaní o dokument
Adm63	F	Definícia regulárnych výrazov pre kontrolu vstupných polí
Adm64	F	Definícia štandardných regulárnych výrazov pre výber v menu
Adm70	F	Konfigurácia
Adm71	F	Konfigurácia konštánt – pohľad od kombinácie
Adm76	F	Kontrola platnosti bezpečnostných kľúčov a certifikátov
Adm77	F	Kontrola platnosti delegovaných profilov
Adm78	S	API konfigurace
Adm79	S	Evidencia certifikátov
Ftp01	F	Výmena súborov a dokumentov
Ftp02	F	Výmena súborov a dokumentov – konfigurácia
Xpw01	F	Správa hesla (LDAP)
Xpw02	F	Správa hesla pre VL
Xpw03	F	Správa hesla pre VL - generovanie

3.1 Adm01 – Adm05

Objekty sú celkovo popísané v prevádzkovej dokumentácii EGJE_provdoc. Opis je začlenený do procesu vytvárania používateľa a definície jeho práv.

Adm01 je pohľad vychádzajúci zo zoznamu profilov priradených jednotlivým používateľom. Jeho špecialitou je záložka Dostupná PV, ktorá zobrazuje osoby a PV, ktoré bude konkrétny používateľ vďaka profilu mať prístupné. Zobrazenie je k referenčnému dátumu a rešpektuje aj "Limit dní vyhodnocovanie práv na PV do budúcnosti:" (štandardne 40). Inými slovami ak posuniete referenčný dátum viac dopredu, ako je tento limit, budú práva počítaná k tomuto limitu. To je z viacerých dôvodov, napr. že práva často závisí na štruktúrach a tie sa pripravujú dopredu a ich budúca podoba nie je vždy v optimálnom stave.

Tiež záložky Objekty a práva a Prístupné ZLM zobrazujú práva a ZLM, ktoré používateľovi zaradenému na profil prislúcha. Objekty získa používateľ pomocou rolí (Adm03), ZLM sú potom definované v Adm06.

Adm02 je základným definičným formulárom prístupového profilu. To je taký abstraktný používateľ. Profil je popísaný právami k riadkom (hneď prvá záložka) a tiež priradenými rolami (záložka Role profilu), tie zasa definujú objektové práva.

Tie sú definované na formulári Adm03.

Tu máme role v správe Elanor (0-499) a role zákaznícke (500-999). Zákaznícke role si definuje používateľ. Podrobnejší popis je v EGJE_provdoc odstavec Vytvorenie a editácia role

Adm04 je pohľad na práva cez navigáciu objektov, teda kde sa ktorý objekt uplatňuje. Zaujímavu informáciu poskytuje u používateľskej zostavy. Tu je uvedené, ktorá jej verzia je aktuálna. EGJE totiž štandardne uchováva aj dve predchádzajúce verzie používateľskej zostavy a tu je možné miesto tej najnovšej urobiť aktívnu miesto nej nejakú staršiu verziu.

U formulárov umožňuje zadávať pokyny pre prácu s formulárom viď Adm20.

Konfiguračné aj na roli založené skrývanie celých objektov a ich častí je popísané v EGJE_provdoc.

Adm05 je primárne zoznamom menu uzlov referentského rozhrania (prvky MENU_) a uzlov rozhrania HR Portál (prvky MENUDL_). U prvkov (štvorcov) v menu HR Portál tu umožňujeme správcovi predefinovať ich poradie a tiež názov, ktorý sa vo štvorci zobrazuje. Pri zmenách názvov však postupujte opatrne, tak aby sa názov príliš nevzdialil od fixného názvu, ktorý je v referentskom rozhraní, helpu, dokumentácii a ktorý je tiež styčným prvkom pre helpdesk.

Názvy sú viacjazyčné (cz, sk, en).

Na záložke Dlaždice s parametrami sa dajú zadávať dlaždice odkazujúce na formuláre Epr01, Epr05. Pri každej dlaždice možno nastaviť názov a parametre wflep_skup a wflep_typ pre skupinu a typ eProposal. Takto vytvorená dlaždice otvorí formulár Epr01, Epr05 a rovno spustí proces zadávania nového eProposal pre skupinu a typ z parametra.

3.2 A dm06 - Skupiny riadkových práv (pre číselníky a štruktúry)

3.2.1 Obecné skupiny riadkových práv (záložka 1)

Formulár umožňuje definovať skupiny práv a tie potom priraďovať v rôznych číselníkoch a s ich pomocou potom na profile (Adm02) obmedzovať riadkový prístup k ďalším dátovým osiam (než len doposiaľ používané osy: Osoby a PV, Uchádzači, Typy štruktúr, Statusy uchádzača).

Adm06 - definícia skupín

Adm02 - Profily - použitie skupín riadkových práv:

kde

Obmedzenie číselníkov podľa skupín RP – používateľ uvidí (obvykle v ponukových ComboBoxoch) len tie hodnoty z príslušného číselníka, ktoré sú označené touto skupinou (výpočet oddeľovaný čiarkou), alebo nie sú označené skupinou žiadnou.

Pridať vlastnú skupinu z Org.štr. - pridá ku skupinám v predchádzajúcom riadku ešte tú skupinu, ktorá je uvedená v organizačnom stredisku, do ktorého je používateľ zaradený.

Obmedzenie editácie číselníkov podľa skupín RP - pre používateľov, ktorí editujú číselníky - musia tu mať výpočet všetkých skupín, nimi označené riadky v číselníku majú vidieť a editovať (inak vidí len riadky bez označenia skupinou)

Pridať vlastnú sk. z Org.štr. - editácia - dtto úvodné dvojice, ale pre účel editácie číselníkov

Obmedzenie editácie číselníka štruktúr (výpočet typov) - výpočet typov štruktúry (navigácia Str01), ktoré používateľ môže editovať. Napr. 2,3 spôsobí, že používateľ v Str01 uvidí a môže editovať len Organizačnú štruktúru (2) a Pracovné miesta (3).
To môže byť skombinované s obmedzením editácie len niektorých riadkov (pomocou predchádzajúcich dvoch parametrov)

Systém je komplexný a jeho nastavenie odporúčame vykonať s konzultantmi Elanor.

Uplatnenie zápisové skupiny "Obmedzenie editácie číselníkov podľa skupín RP" (voliteľne doplnené o vlastné skupiny z org. štruktúry) definuje, kde je možné skupinu priradiť resp. ktorý prvok, skupinou označený, môže používateľ editovať:

· Combo Str01 / Štruktúra hierarchicky / Detail / Číslo skupiny riadkových práv
(naviac je tu tlačidlo Skupina RP do podriadených prvkov, ktoré propaguje skupinu priradenú k aktuálnej položke do všetkých jej podriadených - obvykle strediskám)

· Combo Str02 / Detail / Číslo skupiny riadkových práv

+ vlastný navigačný zoznam formulár

· Navigačný zoznam PM, teda Pmi01, Pmi02, Pmi07, Pmi08, Pmi09, Pom03, Utk03, Utp03

· Navigačný zoznam Prof, tedy Pro01

· Navigačné zoznamy pre štruktúry 30-32, 34, 37, 39

· Str06

· Jpc01 / Číselník / Číslo skupiny riadkových práv

+ navigačný zoznam, naviac je v navigačnom zozname filter Prístupné pre zápis

· Cmt01 / Tarifná stupnica / Číslo skupiny riadkových práv

+ obsah záložiek Stupnica, Zoznam tabuliek, Tarify v tabuľkách, Archív

· Slm02 / Popis započiteteľnosti / Číslo skupiny riadkových práv

+ navigačný zoznam

Výpočet "Obmedzenie číselníkov podľa skupín VP" (voliteľne doplnené o vlastné skupiny z org. štruktúry) je použitý pre obmedzenie zobrazovaných záznamov na :

Opv01 Záložka štruktúry / combo štruktúr

Opv04 combo štruktúr

Vyp01 combo štruktúr

Pozn. ponúka typov štruktúr na

Opv01/Štruktúry

Opv04/ Štruktúry

Opv05/ Štruktúry

Opv50fkb/ Štruktúry

Cdc01f/ Štruktúry

potom zároveň podlieha aj voliteľnému obmedzeniu výpočtom Adm02 / PV výpočet typov štruktúry, povolenie priradenia.

Opv01, Opv05 ponuka voľných PM

Opv09

Pla03, Pla04, Pla20, Pla21

Sto02

Ovp01, Opv04, Opv05, Dcm01 comba tarifných stupníc

Str10

Adm54 - navigácia štruktúr

Str05 – navigácia

tlačové zostavy - argument

vlastné dáta zostavy

Kon05, Kva20, Mdo07f, Opv13, Opv14, Opv14f, Opv15f, Pla12, Pmi28, Sto03, Sto04, Sto05, Str11, Vyp21

3.2.2 Práva na skupiny ZLM (záložka 2 a 3)

Nastavenie týchto záložiek umožňuje modifikovať implicitne nastavenú prístupnosť zložiek miezd pre čítanie a zápis na nasledujúcich formulároch:

Vyp01

Opv02

Sra01

Dav01

Dcd01 + Dcu01, Denná evidencia

Dcm01 + Dcu01, Mesačná evidencia

Dcv01

Dca02

Dcu06 (EGJE WP)

Dov05/Dov06

Obecne rozlišujeme právo záznamy s určitou ZLM na formulári vidieť a právo mať možnosť záznam s určitou ZLM zadať (teda tie ZLM, ktoré sa ponúkajú v combu pri vypĺňaní položky ZLM).

Pre nastavenie aparátu najprv definujeme na záložke 2 Skupiny ZLM, ktoré potom môžeme používať pre jednotlivé formuláre a profily (záložka 3).

Skupina ZLM má kód a

buď položku:

Zoznam ZLM nahradiť implicitné - zoznam nahradí implicitné správanie formulára (v mantineloch dostupných IA podľa rozhodnutia Elanor)

alebo jednu či obe položky

Zoznam ZLM odobrať z implicitných-zoznam zakázaných ZLM oproti implicitnému správaniu

Zoznam ZLM pridať k implicitným - ZLM naviac oproti implicitnému správania

pričom zoznam ZLM označuje jednotlivé ZLM oddelené čiarkou resp. ich intervaly s oddeľovačom pomlčka

Pr.: 21-26,31,51-56

Na 3. priraďovacie záložke potom zadávame vždy:

Objekt práv - každý z výše uvedených formulárov tu má svoje čítacie a zapisovacie objekty

Skupina ZLM - priradenie skupiny ZLM definované na predchádzajúcu záložke

Fakultatívne položky:

Profil práv - ak nevyplníme - platí pre všetkých používateľov (tj bez rozlíšenia profilu práv)

ak vyplníme definujeme prístupnosť pre používateľov s konkrétnym profilom (toto nastavenie má prednosť)

Organizácia - len pre tzv. multiorganizačné databázy - vyplnenie umožní odlíšiť nastavenia pre jednotlivé organizácie. Nevyplnenie potom platnosť pre všetky.

Práva nastavujte vždy tak, aby zápisové práva neboli väčšie ako práva čítacie, inak používateľ novo urobenú ZLM neuvidí!

Objekty a ich funkčnosť:

1- Dca02 - dlhodobé odchýlky - čítanie

ktoré ZLM sú v záložke zobrazované

akceptované sú ZLM platné pre legislatívu, dochádzku a obdobie formulára

ZLM s IA 21,26,27,41,42,51,56,61,62,998,999

ale nie 904

2- Dca02 - dlhodobé odchýlky - zápis

ktoré ZLM môže používateľ v tejto záložke zadať (tj. sú v ponukovom combe)

detto jako skupina č. 1

3- Dcd01, Dcv01 - vstupy - čítanie

u Dcv01 sa nastavenie týka záložky Denný

používa sa tiež pre Dcu01, Vstupy denné

akceptované sú ZLM platné pre legislatívu, dochádzku a obdobie formulára

Použitie ZLM podľa IA nie je obmedzené

4- Dcd01 - vstupy – zápis

používa sa tiež pre Dcu01, Vstupy denné

akceptované sú ZLM platné pre legislatívu, dochádzku a obdobie formulára

súčasne musia byť povolené pre skupinu ZLM č.3

ZLM s IA 13, 14, 21, 26, 27, 31, 41, 42, 51, 56, 61, 62, 151, 901, 904, 998, 999, 1002, 1006, 1008, 2121, 2122, 2131, 2132 , 5101

5- Dcm01, Dcv01 - vstupy, vstupy detail – čítanie

u Dcv01 sa nastavenie týka záložky Mesačné

používa sa tiež pre Dcu01, Vstupy mesačné

akceptované sú ZLM platné pre legislatívu, dochádzku a obdobie formulára

Použitie ZLM podľa IA nie je obmedzené

6- Dcm01 - vstupy – zápis

používa sa tiež pre Dcu01, Vstupy mesačné

akceptované sú ZLM platné pre legislatívu, dochádzku a obdobie formulára

súčasne musia byť povolené pre skupinu ZLM č.5

ZLM s IA 13, 14, 21, 26, 27, 31, 41, 42, 51, 56, 151, 1002, 1003, 1004, 1008, 1111, 1112, 1113, 1116, 1131, 1132, 1133, 1134, 1135 , 1136, 1143, 1151, 1152, 1153, 1171, 1176, 2121, 2122, 2131, 2132, 2404, 5101, 5102, 5103

ale nie 904

7- Schvaľovanie ZLM vstupov Doch / DOV - dátum a poldni (SlmSchvalD)

určená pre formuláre Dov05 / Dov06 / Dov16, Dcu06

akceptované sú ZLM s IA 11 až 899, 998, 999, 1001 až 1006, 1101 až 1154, 2121 až 2199 a 5101 a vyššie

ale nie 31, 51 až 59, 101 až 151, 1111,1116,1132,1143

pri nedefinovaní skupiny ZLM s IA 21

8- Schvaľovanie ZLM jednodňových vstupov Doch / DOV - dátum a čas od, do (SlmSchvalT)

určená pre formuláre Dov05 / Dov06 / Dov16

akceptované sú ZLM s IA 11, 12, 13, 14, 21, 999, 1003, 1004, 1111, 1116, 1132, 1143, 2121, 2122

9- Dav01 – Dochádzka a výkony

akceptované sú platné pre dochádzku a obdobie formulára

ZLM s IA 13,14,21,26,27,31,41,42,51,56,61 až 66, 151,901 až 999, 1002, 1003, 1004, 1008, 1111, 1112, 1113, 1116, 1131, 1132 , 1133, 1134, 1135, 1136, 1143, 1151, 1152, 1153, 1154, 1171, 1176, 2121, 2122, 2131, 2132, 2404, 5101, 5102, 5103, 5152, 5153, 5154

ale nie 904

10- Vyp01,18,25,26,Dcv01- čítanie

užívateľovi sú zobrazované len záznamy s uvedenými ZLM (u Dcv01 sa nastavenia týka záložky Mzdové vstupy)

11- Vyp01 - vstupy - zápis

ktoré ZLM môže používateľ v tejto záložke zadať (tj sú v ponukovom combe)

12 - Vst15 čiastka – zápis, (Vst.castka_W)

13 - Vst15 hodiny – zápis, (Vst.hodiny_W)

14 - Vst15 zmeny – zápis, (Vst.smeny_W)

15- Sra01 - čítanie

16- Sra01 - zápis

17- Schvaľovanie ZLM vstupov Doch / DOV – len dátumy (SlmSchvalD2)

akceptované sú ZLM s IA 11 až 899, 998, 999, 1001 až 1006, 1101 až 1154, 2121 až 2199 a 5101 a vyššie

ale nie 31, 51 až 59, 101 až 151, 1111,1116,1132,1143

18– Schvaľovanie ZLM vstupov Doch / DOV - dátumy a čas od resp. do (SlmSchvalT2)

akceptované sú ZLM s IA 11 až 899, 998, 999, 1001 až 1006, 1101 až 1154, 2121 až 2199 a 5101 a vyššie

ale nie 21, 31, 51 až 59, 101 až 151, 11,13,21,22,1111,1116,1132,1143

19- Dav01 zmeny – zápis

je určená pre definíciu ZLM, pre ktoré je možné na záložke Dav01, Vstupy,

užívateľom zadať pracovné zmeny

pokiaľ nie je založená, je povolené zadanie prac. zmien iba pre ZLM s IA 950

akceptované sú len ZLM s IA 21 až 66, 91 až 162, 998, 999, 950, 1009, 2405, 4306, 5101, 5104.

20- Opv02, Opv01/tar. zaradenie - čítanie

spoločné nastavenia aj pre zobrazovanie premietanie tarifných ZLM do Opv01

21- Opv02 – zápis

22- Jednodenné vstupy DOCH-Kalendár - s časom od, do (bez schvaľovania.) (SlmDoch1a)

je určená pre Dcu06 (WP), záznam denné evidencie

akceptované sú len ZLM s IA 11 až 1009 ale bez IA 903, 904, 950

a ďalej IA 1111 až 1116, 1131 až 1136, 1143 až 1154, 2121 až 2132 a 5101

23- Jednodenné vstupy DOCH-Kalendár - s časťou zmeny alebo hodinami (bez schvaľovania) (SlmDoch1b)

určená pre Dcu06 (WP), záznam denné evidencie

akceptované sú len ZLM s IA 11 až 1009 ale bez IA 903, 904, 950

a ďalej IA 1111 až 1116, 1131 až 1136, 1143 až 1154, 2121 až 2132 a 5101

24- Jedno a viacdňové vstupy DOCH-Kalendár - celodenný (bez schvaľovania) (SlmDoch2a)

určená pre Dcu06 (WP), záznam mesačné evidencie

akceptované sú len ZLM s IA 12, 14, 15, 21, 22, 26, 27, 31, 41, 42, 51..59, 61..162, 903, 906, 998, 999, 1001, 1002, 2131, 2132, 5101, 5104

25- Jedno a viacdňové vstupy DOCH-Kalendár - s poldni (bez schvaľovania) (SlmDoch2b)

určená pre Dcu06 (WP), záznam mesačné evidencie

akceptované sú len ZLM s IA 12, 14, 15, 21, 22, 26, 27, 41, 42, 61..66 , 1001, 1002, 5101, 5104

26- Viacdenné vstupy DOCH-Kalendár - s časom od, do (bez schvaľovania) (SlmDoch2c)

určená pre Dcu06 (WP), záznam mesačné evidencie

akceptované sú len ZLM s IA 61, 62, 63, 64, 65, 2121, 2122, 5101, 5104

29- SlmDoch1c - Jednodňové vstupy DOCH-Kalendár (bez schvaľovania), iba čítanie

určená pre formulár Dcu06 pre oblasť neschvaľovaných záznamov v dennej evidencii, ZLM tu zaradené sú na formulári iba zobrazované (nie je možné zadať ako nový, aktualizovať ani zmazať)

predvolenia: žiadna ZLM

obmedzenia: povolené ZLM (ako skupina 22) akceptované sú iba ZLM s IA 11 až 1009 ale bez IA 903, 904, 950

a ďalej IA 1111 až 1116, 1131 až 1136, 1143 až 1154, 2121 až 2132 a 5101

30 - SlmDoch2d - Jedno a viacdenné vstupy DOCH-Kalendár, len čítanie

určená pre formulár Dcu06 pre oblasť neschvaľovaných záznamov v mesačnej evidencii, ZLM tu zaradené sú na formulári iba zobrazované (nie je možné zadať ako nový, aktualizovať ani zmazať)

predvolenia: žiadna ZLM

obmedzenia: povolené ZLM (ako skupina 24) akceptované sú iba ZLM s IA 12, 14, 15, 21, 22, 26, 27, 31, 41, 42, 51..59, 61..162, 903, 906, 998 , 999, 1001, 1002, 2131, 2132, 5101, 5104

31 - Dcm01.Vstupy_půlky - Dcm01, Dcu01 - Vstupy (mesačné) - s polkami dňa

Zoznam ZLM, pre ktoré je možné na Dcm01 zadať polovičky zmeny.

Štandardne nie je povolené vloženie polovičky zmien pre žiadnu ZLM.

32 - Dcm01.Vstupy_časy - Dcm01, Dcu01 - Vstupy (mesačné) - s časom od / do

Zoznam ZLM, pre ktoré je možné na Dcm01 zadať Čas od / do.

Štandardne nie je povolené vloženie polovičky zmien pre žiadnu ZLM.

33 - Jednodňový mesačný vstup DOCH-Kalendár - s hodiny / zmeny (bez schváľ.)

kód: SlmDoch2e

Učená pre Dcu06 (WP), záznam iba do mesačnej evidencie so zadaním iba celkového počtu zmien alebo hodín (dátum v zázname je iba evidenčný pre zobrazenie záznamu v Dcu06).

ZLM sa nezobrazí v Dcd01 a iných formulároch dennej evidencie dochádzky.

Použité ZLM musia mať povinne nastavený Kód doby = B.

default povolená ZLM s IA 950

akceptované sú iba ZLM s IA 62, 63, 64, 65, 950, 1003, 1111, 1113, 1114, 1135, 1154, 2131, 2132, 5101 až 5104

34 - Mesačný vstup DOCH-Kalendár s nepovinnou prílohou (bez schváľ.)

kód: SlmDochPril

určená pre Dca11, Dcu06 (WP), záznam mesačnej evidencie s nepovinnou prílohou

default nie je žiadna ZLM

akceptované sú iba ZLM s IA 21, 26, 41 až 66, 5101, 5104, 5151

V rámci Dcu06 určená len pre mesačné neschvaľované odchýlky (režim vstupu 24,25,26).

35 - Mesačný vstup DOCH-Kalendár s povinnou prílohou (bez schváľ.)

kód: SlmDochPrilPov

určená pre Dca11, Dcu06 (WP), záznam mesačnej evidencie s povinnou prílohou

default nie je žiadna ZLM

akceptované sú iba ZLM s IA 21, 26, 41 až 66, 5101, 5104, 5151

V rámci Dcu06 určená len pre mesačné neschvaľované odchýlky (režim vstupu 24,25,26).

36 - ZLM z plánu neprítomnosti

Kód: SlmPlan

Určená na zadanie plánovanej odchýlky dovolenky do Dcp01 z Dcu06.

povolené len pre SLM s IA 21, 22, 26, 5151

odchýlka do plánu sa zakladá iba v režime celý deň + poldeň (rovnaké ako v Dov16)

37 - ZLM s možnosťou vyplniť štruktúru

Zoznam ZLM u ktorých je možné doplniť priradenie na štruktúru na určených formulároch DOCH.

Default: žiadna ZLM Obmedzenie: žiadna ZLM

38 - ZLM s povinnosťou vyplniť štruktúru

Zoznam ZLM u ktorých je povinnosť priradenia na štruktúru na určených formulároch DOCH.

Default: žiadna ZLM Obmedzenie: žiadna ZLM

39 - (ZlmDoch39) - ZLM s povinnosťou vyplniť Poznámka

Dcu06, Povinnosť vyplniť pole Poznámka, Poznámka 1 + Poznámka 2 ak je zobrazené na dialógu editácie.

Default: žiadna ZLM Obmedzenie: žiadna ZLM

40 - (ZlmDoch40) - ZLM s opakovaným uložením

Dcu06. Zoznam ZLM, pri ktorých je možné použiť funkciu opakovaného generovania schvaľovanej odchýlky.

Default: žiadna ZLM Obmedzenie: žiadna ZLM

41 - ZLM povolené pre plán ZLM

Zoznam ZLM, ktoré sú dostupné pre Plán ZLM (Dcp01, Dcp02, Dov16, Dcu06).

Default: existujúce pre Dcp01 Obmedzenie: existujúce pre Dcp01

111 - Vyp22 ZLM v absenčnej karte

116 - Vst15 schval. čiastka cez WFL 16

Zoznam SLM, ktoré je možné následne použiť na formulári Vst15, záložka Schvaľované čiastkou, pre WFL 16.

117 - Vst15 schval. čiastka cez WFL 17

Zoznam SLM, ktoré je možné následne použiť na formulári Vst15, záložka Schvaľované čiastkou, pre WFL 17.

121 - Dcf03/Dcf15 schval. čiastka cez WFL 21

Zoznam SLM, ktoré je možné následne použiť na formulároch Dcf03, Dcf04 a Dcf15 - Odmeňovanie. Bez tohto nastavenia nie je možné na spomínaných formulároch vybrať ZLM pre generovanie odmien.

3.3 Adm10 - Používatelia, profily, autentizačný server

Používatelia idú štandardne vytvoriť a spravovať na Adm01, Adm01p.
Tento formulár však ponúka jednoduché priradenie používateľského profilu a autentizačného reťazca (Logname) existujúcim osobám. Osoby i profily jsou zde bez omezení. Jediné obmedzenie, ktoré sa tu uplatňuje je obmedzenie organizáciou (u viacej-organizačných inštalácií).

Záložka Audit logname dáva prehľad o všetkých zmenách údaje Logname, či už boli vykonané prostredníctvom akéhokoľvek formulára (Adm01, Adm01f, Adm10, Adm12).

3.4 Adm11 - Správa osôb a PV

Prehľadový formulár, ktorý zobrazuje všetky osoby a ich PV. Jediné obmedzenie, ktoré sa tu uplatňuje je obmedzenie organizáciou (u viacej-organizačných inštalácií).
Nezobrazuje citlivé údaje, len identifikáciu a priradenie.
Niektoré štandardné role ho majú priradený pre čítanie, len správca ho má pre zápis. Keďže má navigáciu osôb a nie štandardné Osoba + PV, je v ňom napr. dobre rozlíšiteľné, či je to jedna a tá istá osoba, alebo či je evidovaná v systéme ako osoba viackrát.
Je to tiež jediné miesto, kde môže správca osobu / PV zmazať, ak už nebola použitá napríklad v mzdách alebo vo vzdelávaní a nie je na nej nejaká podobná väzba z ďalších častí systému.
Ak je, tak je vhodné miesto zmazanie zmeniť na PV Dátum nástupu a Dátum ukončenia napríklad na 1.1.1950 a Status vzťahu osoba - organizácia na 10 - Personálne evidencia bližšie neurčené a vymazať položku Druh právneho vzťahu.
Detailne je možnosť zmazať osobu v minulosti počítanú takáto:

Existuje právo Adm11mazaniSpoc - Právo mazať osoby spočítané predvlani a skôr.

Majú ho iba štandardné role 1 a 3.

Vyhodnocujeme obdobie tento rok a vlani, kedy, ak je v ňom vypočítané & uzavreté, formulár zmazať osobu resp. PV nedovolí.

Ak je ale najnovší výpočet & uzavretie v predminulom roku resp. staršom, smie osobu mazať ten používateľ, ktorý má to právo Adm11mazaniSpoc.

Formulár je naozaj pre zápis vhodný len pre správcov, nie pre personalistu alebo mzdovú účtovníčku.

3.5 Adm12 - Používatelia Webu, profily, autentizačný server

Užívateľov je možné štandardne vytvoriť a spravovať na Adm01, Adm01p.

Tento formulár ponúka jednoduché priradenie používateľského profilu (obvykle zamestnaneckého alebo manažérskeho alebo obidvoch) ktorémukoľvek zamestnancovi. Na rozdiel od Adm10 sú tu osoby v navigačnom zoznam obmedzené prístupovými právami používateľa. Štandardne tiež platí obmedzenie na Status PV 1 - 3. Toto obmedzenie však je možno vypnúť na "Adm21 / Konfiguračné parametre / Navigácia Adm12 - všetky statusy" zadaním hodnoty "Áno".

Dôležitou podmienkou je to, ak je osoba správcom, tj. Ak má zapisovať práva na jeden z formulárov Adm01, Adm02, Adm03 alebo Adm10.

Ak nie je, formulár ponúka iba profily, ktoré obsahujú objekt Adm12Combo - Profil smie priradiť v Adm12, Adm01p (aj keď nie je správcom).

Navyše sa používateľovi neponúkajú tie profily, ktoré majú právo na jeden z uvedených Adm formulárov. A osoby s takým profilom už priradeným tiež nemôže používateľ, ktorý nie je správcom na Adm12, editovať tj. Pridávať, meniť mazať profily aj loginy.

Užívateľ, ktorý nie je správcom, tiež nesmie žiadny profil priradiť sebe, tzn. osobe, pod ktorou je teraz prihlásený.

Pozn. Táto reštrikcia platí aj pre sprievodcu Adm01p.

Vzhľadom k obmedzenej funkčnosti je formulár dobre delegovateľný.

Formulár tiež slúži na vytváranie autentizačných účtov Microsoft AD domény správcom priamo z EGJE.
Funkčnosť je k dispozícii v individuálnej aj hromadnej podobe. Používa sa pri nej LDAP prístupu k Windows doméne. Je teda potrebné mať v EGJE nastavenú LDAP autentizáciu.
Správca teda môže vytvárať používateľov do repository Microsft AD.
K tomu sú použité jednak parametre z Configurator / zálož. Overenie, ktoré sa týkajú pripojenia k LDAP a ďalej parametre v Adm21 / Konfiguračné parametre / Vytváranie používateľov LDAP / AD, ktoré definujú parametre do repository vytváraného používateľa.
Na záložke Prihlásenie - autentizácia je okrem vyplnenia autentizačného Logname možné ho rovno v AD vytvoriť (tlačidlo Vytvoriť logname na aut.serveru), resp. používateľovi toto heslo zmeniť (tlačidlo Zmena hesla). Ďalej je tu funkcia "Vytvorenie autentizácia", ktorá spojí obe akcie tzn. vytvorí Logname a zavedie ho do AD. Režim a dialóg je zhodný ako je opísaný ďalej v hromadných akciách.
Pozn.: tvar Logname je popísaný v Prevádzkovej dokumentácii (kap. Založenie používateľa - stručné zhrnutie).
Na záložke Hromadné akcie je funkcia „Hromadné vytvorenie neexistujúcich autentizácií“, po spustení rovnomenného tlačidla nasleduje dialóg umožňujúci zvoliť / zadať:

režim tvorby autentizačného Logname
zadať doménu
zadať atribút EmployeeNumber
zadať Typ autentifikácierežim hesla
zadať pevnú časť hesla

Ak sú uvedené v Configurator / Overenie parametre "LDAP - používateľ s právami na čítanie" + jeho heslo (parametre sú používané v lDAPsearch autentizácii), tak celú prácu s LDAP v Adm12 (hlavne zakladanie AD používateľov indiv. i hromád.) systém robí pod týmto používateľom. Potom je možné nastaviť práva na zakladanie používateľov v AD tak, že bežní používatelia ich nemajú, ale práva má tento jeden uvedený používateľ. Tento používateľ je používaný práve a len vo formulári Adm12. Nastavenie prístupových práv k Adm12 určuje prístup používateľa EGJE k tejto funkcionalite.
V Adm21 / Konfiguračné parametre / Vytváranie používateľov LDAP / AD sa nastavujú parametre hromadného generovania. Tieto parametre definujú presnejšie kam a ako bude používateľ do repository vytváraný.

Generovanie je istené proti vytvorenie duplicitného účtu v AD resp. proti prepisovaniu jedného účtu iným používateľom.
Pri vytváraní loginu do Active Directory sa do AD položky s kódom employeeID uloží interné ID osoby v EGJE (id_toso). Tak je možné spoznať, či je už login osoby v AD vytvorený. Keď nie je a generované logname je už obsadené, vytvára logname s 2 na konci (resp. 3, 4. ..) a to tak dlho, kým nenájde neobsadený logname.

Ďalej vytváranie dokáže pri vyplnení Adm21 parametra "LDAP - hľadať osobu s RČ" = Áno reagovať na situáciu, keď je jedna osoba v EGJE db viackrát (typicky v rôznych organizáciách alebo SJ s iným IČO). Potom v prípade, že osobu nájde, ju už znova nevytvára.

Pozn.: rodné číslo EGJE ukladá do AD položky s kódom userParameters.

Pri vytváraní je možné do AD položky s kódom EmployeeNumber uložiť užívateľské dáta. Predvyplnenie položky je možné zadať v Adm21 / Konfiguračné parametre / Vytváranie užívateľov LDAP / AD / LDAP - atribút EmployeeNumber. Okrem textu je možné zadať aj makrá:

%LEG% - doplní legislatívu (CZ / SK), pod ktorú spadá zamestnanec.

%OSC% - časť z OSČPV zamestnanca pred bodkou.

Jeden z režimov generovania hesla a to „4 - Heslo podľa hesla pre VL (Xpw03)“ heslo pre prihlásenie do EGJE prevezme z hesla vygenerovaného v Xpw03. Ak toto heslo vygenerované nie je, vygenerujeme ho a uložíme do Xpw03 v tomto kroku.

Zákazníci používajúci tieto heslá je zvyčajne tlačia na skryté výplatné pásky pomocou používateľskej zostavy Xpw03fq.

Záložka Adm12 / Hromadné akcie tiež obsahuje tlačidlo Hromadná zmena hesiel, ktoré vytvorí podľa zvoleného algoritmu heslo znova aj v Active Directory už vytvoreným používateľom.

Pri tvorbe používateľov resp. zmene hesiel umožňujeme nastaviť pomocou LDAP v Active Directory atribút Zmeniť heslo pri ďalšom prihlásení.

Na formulári Adm12, na záložkách „Prihlásenie a autentizácia“ a „Hromadné akcie“ boli pridané tlačidlá „Generuj logname podľa Adm21“ a na hromadných akciách je to tlačidlo „Generuj chýbajúce logname“ pre generovanie logname bez Active Directory. Funkcionalita spolupracuje s nastavením na formulári Adm21  záložka Konfiguračné parametre. Tu je výberový rolldown menu, z ktorého sa dá vybrať, ako bude generovaný logname vyzerať a po vygenerovaní funkcionalita tento logname zapíše do aplikácie EGJE. Túto funkcionalitu môžu využiť klienti bez Active Directory.

Poznámka: Algoritmus generovania logname bol upravený tak, aby logname neobsahoval žiadne špeciálne znaky. Tie sú odstránené a pre logname sa vezmú iba písmená. Nepoužijú sa teda znaky ako pomlčka alebo apostrof atď., ktoré môžu byť súčasťou mien a priezviska.

Na formulári Adm12, karty Prihlásenie – autentizácia a Hromadné akcie pribudol Stĺpec Typ autentifikácie a tlačidlo Odoslať registračný e-mail. Typ autentifikácie je predvolený prázdny alebo má hodnotu 0 a nijak neovplyvňuje prácu s vygenerovaným logname alebo jeho využitie pre autentifikáciu. Iba v prípade ASP klientov je tu iná hodnota. Tlačidlo Odoslať registračný e-mail. Toto tlačidlo je spojené s definovanými ZakId (ASP klienti) a objektovým právom na Adm12RegisterCombo, podrobný popis nájdete v dokumentácii EGJE_distribuciaHesielASPklientom.

3.6 Adm13 - Ochrana osobných údajov

Formulár slúži k správe údajov o bývalých zamestnancoch a uchádzačoch a k selektívnemu vymazávaniu ich údajov.

Premazanie "nepotrebných" údajov bývalých zamestnancov a uchádzačov je cestou k naplneniu zásad zákona o ochrane osobných údajov 428/2002 Z.z.

Formulár je určený pre správcu aplikácie a vykonáva premazanie pre celú databázu.

Týka sa týchto údajov:

Záložka „Správa premazania“

V záhlaví sa určí doba t.j. pomocou dátumu sa určia osoby, ktoré svoj posledný PV ukončili pred tým dátumom. Dátum musí byť starší než jeden a pol roka pred dnešným dátumom.
V podzáložke Zamestnanci k premazaniu a Uchádzači k premazaniu sa môžeme presvedčiť, kto do procesu premazania bude spadať.

podzáložka "Popis premazania"

Oddiel "Bývalí zamestnanci“ má časti :

platby (povinné)

Opv02 - všetky o osobe

Opv01 - tarifné zaradenie

zrážky (povinne zaškrtnuté)

Sra01- všetky o osobe s IA 4101-4699, vrátane mazania Vyp01 / Vstupy (režim Všetky vstupy),

vynechávajú sa osoby s rentou (Poj25)

audit zrážok

WFL zrážok (Sra21)

rodinní príslušníci (povinne zaškrtnuté)

Všetci z Osb02 pre osobu

údaje o priemeroch pre náhrady (povinne zaškrtnuté)

Všetky údaje z Pru01 pre osobu

Vynechávajú sa osoby s rentou (Poj25)

údaje o dovolenke

Všetky údaje o dovolenke a korekciách z Dov01 a o pracovnom voľne Dov02 pre osobu

údaje o zamestnaneckých výhodách a hodnotenie

Údaje z formulára Ben*, Hod*, ktoré sa viažu k osobe

údaje rozširujúce údaje o osobe (záväzky a pohľadávky, CO, voj. evid.)

Ďalšie rozširujúce údaje z Osb02.

Kariéra Kar01,

Rekond. pobyty SK (Opv18)

Pracovné pomôcky (Pom1x)

údaje o spôsobilostiach a kompetenciách

Údaje osoby z Kva01 od 3 záložky ďalej a údaje z Kom01.

Údaje o škole a praxi Kva01

Riziko (Bzp02)

údaje o štruktúrach uložené bez odkazu do číselníka (povinne zaškrtnuté)

Údaje v Opv01 Zaradenie na štruktúry sú uložené v inej forme (priamo kódy a názvy štruktúr, nie odkazy na číselník - tak sú číselníkové hodnoty uvoľnené pre ďalšie použitie resp. vymazanie).

Prípadné zaradenie na štruktúru 3, sa zovšeobecnie na zaradenie na štruktúru 2,

zaradenie na štruktúru 4 je vymazané.

kontakty

Osb02 - komunikácia vrátane auditu

Preukazy (osobné: mimo druhy 0,2,3,4; PV: všetky):

Osb02 - Pasy - osoba aj PV

Dokumenty osoba PV

Opv31

Dochádzka (DCD, Dcm) vrátane archívu (Dcu09)

Toto mazanie je vlastne aditívnym na mazanie k priebežnému periodickému mazaniu definovanému v Adm21 / Konfiguračné parametre

Oddiel "Uchádzači"

Voľba :

Ponechať identifikáciu a status

Úplné vymazanie údaja o uchádzačovi

pre úplné vymazanie

Sú vymazané všetky dáta (t.j. v navigácii Rea01 už uchádzač nebude mať údaj)

pre ponechanie identifikácie

o uchádzačovi sú ponechané iba základné identifikačné údaje

(t.j. meno, priezvisko, tituly, rodné číslo, pohlavie, väzba na osobu, výberové konanie, údaje o prijatí, mailová adresa, status, SO)

Výkonné tlačidlá sú v

Správa premazania / Zamestnanci k premazaní

Ponúkajú sa tí zamestnanci, ktorí majú

Opv01 / Popis / Status vzťahu osoba- zamestnanec hodnotu 3 - PV nespočítateľné

a nemajú iný PV so statusom 1, 2 a majú dátum ukončenia menší ako dátum z hlavičky.

Správa premazania / Uchádzači k premazaní

Položku Rea01/Odstrániť do berieme pre toto mazanie ako nadradenú.

Režim Úplné zmazanie údajov o uchádzačovi berieme ako "silnejší" takže ním dovolíme spracovávať aj uchádzačov, ktorí už prešli mazaním v režime "Ponechať identifikácie a status".

Na záložkách Promazané u zamestnancov (uchádzačov) je potom vidieť, kto procesom mazania prešiel.

Výnimkou sú úplne zmazaní uchádzači, ktorí sú zmazaný naozaj úplne.

Zamestnanec môže tiež mazacím procesom prejsť viackrát (pokiaľ mu v prvom mazania bolo zmazané menej vecí, ako bolo potrebné). K tomu slúži na záložke Premazané u zamestnancov: tlačidlo "Vrátiť akt. Osobu medzi nepromazané".

3.7 Adm14 - Konfigurácia Elanor Workflow

Okno slúži k podrobnému popisu akcií pri jednotlivých krokoch procesného workflow.

3.7.1 Definícia workflow

Správca nastavuje pre jednotlivé workflow v každej v db spracovávanej organizácii (Adm21) resp. možno nastaviť aj spoločný workflow popis pre všetky organizácie:

• každé workflow používa konkrétny, aplikácií (najčastejšie nejakým JPC) danej hodnoty

• na kroku workflow sa definuje, kto je adresátom ďalšieho kroku (pomocou pravidiel)

• a aká informácia má ísť (maska správy) a jej kanál (interná pošta / externý pošta)

• adresátov delíme na primárne a sekundárne, tí sa môžu účastní schvaľovania a ďalší, ktorí len dostanú informáciu. V prípade odoslania notifikácie na e-mail primárneho príjemcu a sekundárneho a ďalšieho príjemcu je možné nastaviť typ e-mailu, na ktorý má byť notifikácia odoslaná. Ak má osoba, na ktorú má byť e-mail odoslaný, zadaný typ e-mailu uvedený ako primárny typ, notifikácia bude odoslaná na tento typ e-mailu. V prípade, že nemá primárny typ e-mailu zadaný, notifikácia bude odoslaná na sekundárny typ e-mailu

• v popise nasledujúceho kroku sa potom pomocou položky Typ schvaľovanie určuje charakter spracovania:

0 Iba oznámenia

1 Schválenie 1. primárnym príjemcom z min.kroku

Je potrebné, aby pravidlo určovalo jednoznačne jednu osobu, inak aparát vyberie jednu náhodnú z tých, ktoré pravidlo vráti

2 Schvaľ. viacerými prim. a sek. príjemcami z min.kroku (vyjadrí sa všetci, musia schváliť)

Viacerých príjemcov môže vzniknúť buď tým, že ich pravidlo vráti viac, alebo tým, že je definovaný primárny a sekundárny príjemcu.

11 Schvaľ. viacerými prim. a sek. príjemcami z min.kroku (postačí, keď odpovie jeden)

Viac príjemcov môže vzniknúť buď tým, že ich pravidlo vráti viac, alebo tým, že je definovaný primárny a sekundárny príjemca.

12 Schválenie viacerými prim. a sek. príjemcami z min.kroku (postačí, keď jeden zamietne)

Pozn. pre 2,11,12: Viac (primárnych) príjemcov môže vzniknúť buď tým, že ich pravidlo vráti viac, alebo tým, že je definovaný primárny a sekundárny príjemca.

Obvyklý postup je nastavovať workflow počas implementácie z predlohy dodanej konzultantom vo forme zmenového skriptu a jeho následným prispôsobením.

Plný zoznam workflow je v číselníku Jpc01 / wfl_akce
Konkrétne popisy realizovaných workflow:

pozri "Akcia workflow" 11 - Schvaľovanie cestovného príkazu Cep_uzdoc kap. 4.3.3 obsahuje aj podrobný popis nastavenia)
viď "Akcia workflow" 101 – 129 Eproposal Epr_uzdoc.

Správa, ktorú krok workflow definuje, sa zapisuje do poľa "Návrh oznámenia".

U krokov s definovaným schvaľovaním sa môže použiť aj "Návrh oznámenia - zamietnutie".

Keď vyplnená predloha u schvaľovania nie je, použije sa "Návrh oznámenia" ako spoločná predloha. Hodnota schválenie / neschválenie sa potom v texte premieta pomocou makra pre Status.

Predmet e-mailu a názov (kroku) workflow zobrazený v prehľade workflow pre mobilné zariadenia a v detaile workflow na HR Portáli sa preberá z položky. Aj tu je možné používať tá istá makrá, ktorá ponúka editor pre dané workflow v predlohe oznámenia.

Pr. U WFL 15, krok 0 => 15 je možné napríklad dať do Názvu workflow kroku text:

% NAME_CELE% - žiadosť o schválenie SLM% SLM_NAZEV %% DATUM_OD% -% DATUM_DO%.

Pozn. Pokiaľ má organizácia vyplneného univerzálneho odosielateľa všetkých EGJE e-mailov (Adm21 / Par. komunikácie / Adresa odosielateľa všetkých e-mailov z EGJE (volit.))

je na koniec e-mailu automatizovane pridávaný Od / From: a skutočný odosielateľ, aby bolo zrejmé, od koho vlastne e-mail je. Do tohto poľa sa vkladá iba emailová adresa bez ďalšieho textu. Pokiaľ by bolo požadované vložiť doplnkový text, ako je napríklad Administrátor<admin@ccc.cz>, je možné tento doplnkový text vložiť do poľa „Popis e-mailu:“ a tento popis bude následne pridaný a zobrazený vo vyššie uvedenom príklade (tučne) .

Obsah obrázku text, snímek obrazovky, číslo, software

Popis byl vytvořen automaticky

V Adm14 sa evidujú 2 typy workflow akcií:

Akcia schvaľované pomocou formulára Wflow (resp. Pomocou tlačidiel na spec. Formulároch):

1-4, 11-130

Akcia kde sa workflow aparát používa hlavne pre definície hlásenia a kde neprebieha žiadny schvaľovací proces, ale procesy sú volány buď z formulára (napr. Kva06 * alebo z úlohy Adm53) sa editujú na Adm33

5-8

Workflow sa dá tiež ladiť tzn. neodosielať správy alebo odosielať a logovať správy.

To sa nastavuje položkou Režim ladenia workflow: s hodnotami:

1 - Štandard - Odosielať workflow správy

2 - Workflow správy odosielať a logovať

3 - Workflow správy neodosielať a logovať

V záložke Log je potom prezeranie zapísaných informácií.

Upozornenie: používajte logovanie iba krátkodobo pre ladenie alebo riešenie problémov, nie trvalo, generuje veľké množstvo dát!

3.7.2 Pravidlá výberu príjemcu kroku workflow

Pravidlo sa používa pre:

určenie, kto bude vykonávať schvaľovanie dané ďalším krokom
určenie, kto obdrží správu (e-mail resp. interní EGJE Mail)

Ø Režim odosielania zástupcovi

Na formulári Adm14, na karte „Kroky workflow“ - „Detail“ - položka „Režim odosielania zástupcovi:“, je možnosť pozastaviť možnosť odosielania emailu zástupcovi. V prípade, že nastavený zástupca pre príjem emailu, je možné touto voľbou pre krok WFL nastaviť, aby práve v tomto kroku nebol odoslaný na zástupcu (napr. pokiaľ je nutné odosielať všetku poštu na zástupcu, okrem pozvánok na školenie) a nebol zástupcovi sprístupnený na formulári Wflow. Táto možnosť práve dovoľuje toto možnosť nastaviť.

Štandardne, ak nie je uvedené inak, pravidlá vyhľadávajú výsledok u časových priradení k referenčnému dátumu.

Typy pravidiel (JPČ wfl_pravidlo_typ):

Typ	Názov typu	Sprievodné parametre
1	Manažér štruktúry (vlastnej alebo uvedenej v zozname) Pozn. ide o manažéra definovaného na Str01/Str02 záložka Manažér/Osoba v EGJE (platné PV)	Typ štruktúry - povinný Zoznam prvkov štruktúry - nepovinný (nevyplnené => vlastný vzhľadom k PV) Minimálna hladina – nepovinný Pozn. Bez minimálnej hladiny hľadá a nájde vždy iba jedného Manažéra / Osobu, ale v prípade že by to mal byť sám zamestnanec, stúpa po stromu vyššie. Zatiaľ čo ak uvedieme hladinu, a ak je táto hladina vyššia, nájde toto pravidlo z Manažérov / Osoby príslušnej nadradenej hladiny. Ak je nižšia, vráti aktuálneho manažéra. U štruktúr, kde je povolené viac paralelných manažérov (Str01 / Meno štruktúra a ich hladín / Smie byť paralelne viac manažérov / osôb) sa dá "zapnúť" režim viacerých osôb - je potom ale v ďalšom kroku potrebné zvoliť typ schvaľovania 2,11,12 viď minulú kapitolu. Hot znak% je vhodný len pre eProposal. Vyberie všetkých Manažérov / Osoby a %ORG všetky ale v rámci jednej organizácie. Manažér je hľadaný k referenčnému dátumu.
2	Osoba s konkrétnou štruktúrou (typicky PM) (platné PV)	Typ štruktúry – povinný Výčet prvkov štruktúry - nepovinný (nevyplnené => vlastný vzhľadom k PV)
3	Manažér štruktúry cestovného príkazu	Typ štruktúry - povinný Výpočet prvkov štruktúry - nepovinný (nevyplnené => vlastné vzhľadom na PV) Pozn. Ide o manažérov štruktúr, ktoré sú definované na CEP v dátovom okne Špecifické zaradenie do štruktúr.
4	Osoba/PV na nadriadenom PM akt. PV	Typ štruktúry – nepovinný (ak nie je, berie sa 3) Pozn. Vychádza z aktuálneho PV a hľadá PV na nadriadenom PM. Pokiaľ na nadriadenom PM nie je PV, ide ešte o hladinu vyššie, ale ďalej už nie. PM nemajú hladiny v obvyklom zmysle, nemôžeme ich teda použiť na obmedzenie hľadania.
5	Osoba, o ktorej workflow je
6	Autor workflow záznamu
7	Uvedená osoba	Osoba – povinný
8	Vzdelávacia akcia - lektori
9	Vzdelávacia akcia - kontaktné osoby
10	Vzdelávacia akcia - autor požiadavky
11	Manažér nadriadeného strediska (prvku štruktúry) Pozn. ide o manažéra definovaného na Str01/Str02 záložka Manažér/Osoba v EGJE (platné PV)	Typ štruktúry - povinný Výčet prvkov štruktúry - nepovinný (nevyplnené => vlastný vzhľadom k PV) Minimálna hladina – nepovinný. Tiež sa tu kontroluje, či manažér zamestnanca, o ktorom je workflow, a manažér nadriadeného strediska nie je tá istá osoba. Ak áno, hľadá sa manažér nadriadeného strediska tak dlho, kým sa nenarazí na iného manažéra, resp. na najvyššiu hladinu.
12	Zástupcovia manažéra Pozn. ide o zástupcov definovaných na Str01/Str02 záložka Zástupcovia (platné PV)	Typ štruktúry - povinný Výčet prvkov štruktúry - nepovinný (nevyplnené => vlastný vzhľadom k PV) Minimálna hladina - nepovinný
13	Držitelia kompetencie (vo výčte) podľa štruktúry (z celého stromu) Šplhá po zvolenej štruktúre (obvykle organizačnej) a hľadá osoby, ktoré buď priamo nebo cezs PM majú určitú kompetenciu. Určené hlavne pre eProposal.	Typ štruktúry - povinný Výčet prvkov štruktúry/kompetencií – povinný
14	Držitelia kompetencie (vo výpočte) podľa štruktúry (prvá nájdená hladina) Šplhá po zvolenej štruktúre (obvykle organizačné) a hľadá osoby, ktoré buď priamo alebo cez PM majú určitú kompetenciu. Hľadanie je zastavené na tej hladine štruktúry, na ktoré je nájdená prvá osoba s určitou kompetenciou. Pokiaľ je na hladine nájdených viac osôb s určitou kompetenciou a Typ schvaľovania je 1 - Schválenie 1. primárnym príjemcom z min. kroku, potom je vrátená osoba s najnižším OSČPV (neplatí pre eProposal). Zo zoznamu nájdených osôb sú vyradené osoby / PV, o ktorých je workflow, alebo ktoré sedia na PM, o ktorom je workflow. Pozn. kompetencie sa eviduje na PM v Pmi01 u Osôb potom v Kva02.	Typ štruktúry - povinný Výpočet prvkov štruktúry / kompetencií – povinný.
15	Držitelia kompetencie (vo výpočte) podľa stru. s min. hladinou (z celého stromu) vracia unikátny a zotriedený zoznam schvaľovateľov, ktorí majú priradenú zadanú kompetenciu. Kompetencie môže byť priradená buď priamo, alebo cez pracovné miesto. Zoznam schvaľovateľov je zostavený na základe priechodu prvkov zadaného typu štruktúry. Pri tom sa hľadajú osoby s priradenou kompetenciou, ktoré sú zaradené na navštívené prvky štruktúry. Prehľadávanie prvkov štruktúry prebieha nasledujúcim spôsobom: o Ako východiskový prvok štruktúry sa použije prvok, na ktorý je priradený zamestnanec či pracovné miesto, o ktorom je schvaľované workflow. o Z tohto prvku sa postupuje po stromu štruktúry nahor, kým nie je dosiahnutá nastavená minimálna hladina. o Následne sa ešte preskúmajú všetky prvky daného typu štruktúry, ktoré leží na zadanej hladine.	Typ štruktúry - povinný Výpočet prvkov štruktúry / kompetencií - povinný Minimálna hladina - povinný
24	Držiteľ kompetencie (nad manažérom uchádzača podľa stru 2 - prvý nájdený) Analogické pravidlu 14 so špecifikovanou štruktúrou 2 s tým, že východiskovou osobou je uchádzač a nie osoba / PV. Je to použiteľné, keď sa uchádzač hlási na Výberové konanie (Rec01) definované na PM (resp. priamo na org. stredisko, čo sa ale nepoužíva). Východiskovým bodom hľadania nahor (po štruktúre 2 a na nich zaradených PM a Osobách) opísanom v kroku 14 je teda org. Stredisko, na ktorom je toto PM.	Zoznam prvkov štruktúry / kompetencií - povinný Pozn. štruktúra je vždy 2.
31	Manažér zadávateľa - vychádza zo zadávateľa a nie z osoby, o ktorej je workflow.	Pravidlo pracuje s manažérmi štruktúry. Toto pravidlo síce vychádza z osoby, ale na rozdiel od ostatných pravidiel, ktoré vždy vychádzajú z osoby, o ktorej workflow je, toto pravidlo vychádza z osoby, ktorá workflow zadáva. U pravidla je rešpektovaná minimálna hladina štruktúry a tiež je u neho zohľadnené, aby pravidlom vrátená osoba bola rôzna od osoby, ktorá workflow zadáva. Kým nie je, hľadáme (opakovane) manažéra na hladine o jednu vyšší.
51	Manažér štruktúry k dátumu od zo schvaľovaného záznamu	Primárne pre schvaľovanie dovoleniek (WFL 15), manažér je hľadaný k dátumu od schvaľovanej dovolenky. Ďalšie workflow - ktorý dátum je bratý: 1 - Prechod medzi strediskami Referenčný dátum 2 - Finančné schvaľovanie vzdelávánia AKCE OD 3 - Schvaľovanie požiadavky na vzdelávanie PLÁN OD (cehtosozpuspoz.plan_od) 4 - Schvaľovanie účasti na vzdelávacej akcii AKCE OD 5 - Pozvánky na vzdelávaciu akciu AKCE OD 6 - Správa o nedosiahnutí min. počtu na vzdel. akciu - 7 - Správa o odhlásení zo vzdelávacej akcie AKCE OD 8 - Správa o exšpirácii period. spôsobilosti PLATNOST DO (cehtosozpus.platnost_do) 11 - Schvaľovanie cestovného príkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 12 - Špecif. schvaľovanie zahraničného cestovného príkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 15 - Schvaľovanie ZLM I. až 20 - Schvaľovanie ZLM VI. DATUM OD (cedmes.datum_od) 30 - Schvaľovanie žiadosti o podpisové kompetencie a vzory ŽÁDOST OD (cehtosokzad.datum_od) 32 - Schvaľovanie žiadosti o mobilitu KB JSEM PŘIPRAVEN NA MOBILITU OD: (cetpvmobkbpoz.datum) 33 - Schvaľovanie požiadavky na vzd. obecné kurzy PLÁN OD (cehtosozpuspoz.plan_od) 34 - Schvaľovanie benefitov I. a 35 - Schvaľovanie benefitov II. PRVNÍHO Z cehtosobencerpwfl.kod_obd 40 - Schvaľovanie uchádzača DAT.NÁSTUPU REŠP. PREDPOKL.NÁSTUPU (coalesce(ceroso.dat_nast,ceroso.dat_nast_predpokl) 59 - Správy o zmenách pers. údajov SKA DATUM ZMĚNY (cetpvwflska.dat_zmeny) 61 - Vyhlásenie poplatníka 1.1.ROKU, keď ide o budúci rok (cetdanprohl.rok) 62 - Ročné zúčtovanie dane 1.1.ROKU, keď ide o budúci rok (cetdan.rok) 211 - Schvaľovanie predschváľeného cestovného príkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 212 - Schvaľovanie predschváleného zahraničného cestovného príkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 301 - Obeh dokumentov 01 až 399 - Obeh dokumentov 99 PLATNOST OD (cetpvdok.platnost_od)
111	Chová sa ako pravidlo 11 pred e201805	Dočasné pravidlo. Plánujeme ho zrušiť v e201809 či e201811.

U pravidiel 1,11,12 tj. typ manažér, sa vychádza z osoby / PV, o ktorej krok workflow je, zistí sa, na ktorý prvok štruktúry (pre typ štruktúry) je priradená. Pre tento prvok sa potom zisťuje konkrétna osoba / osoby, ktoré sú uvedené na záložkách Manažér / Osoba v EGJE resp. Zástupcovia formulárov Str01 / STR02. Táto osoba bude adresátom kroku workflow / správy.

Najčastejšie ide o štruktúru typu 2 - Organizačná štruktúra, alebo štruktúru, ktorá ju supluje.

Suplujúca štruktúra býva často priradená k Organizačnej štruktúre (tj. nepriamo stupeň 2) a výnimky, potom sa uvádza na štruktúre 3 - Pracovné miesto respektíve priamo na PV.

U organizačnej štruktúry nie je povolené, aby na jednom prvku štruktúry bolo viac osôb manažérov,

avšak u niektorých, hlavne referentských štruktúr tomu tak je.

V tomto prípade je potrebné použiť definíciu typu schvaľovania pre viac osôb (pozri min. kapitolu, pravidlá 2, 12, 22).

Pre oblasť eProposal, kde výber príjemcu ovplyvňuje autor eProposal, je možné u pravidlá 1 použiť symbolický zoznamu štruktúr "%". Zadávateľ eProposal potom manažéra vyberá z comba všetkých manažérov resp. "% ORG", ktorý umožní to isté, ale s obmedzením podľa príslušnosti manažéra (osoba/PV) k organizácii.

U pravidiel 13 a 14 je dôležité rozlišovať, či kompetencia je pridelená priamo osobe, alebo je pridelená cez PM.

V prípade, že je kompetencia pridelená priamo osobe, tak hľadanie povoľujúcich osôb prebieha tak, že sa najprv nájde predvolené stredisko z Typu štruktúry, tzn. stredisko, z ktorého sa začína hľadať, a postupne sa nazbierajú všetky jeho nadriadená strediska až k prvej hladine Typu štruktúry. K zoznamu nájdených stredísk sa vyhľadajú len tie osoby, ktoré majú platné PV a majú platnú niektorú z platných kompetencií uvedených v zozname.

V prípade, že je kompetencia pridelená osobe cez PM, tak hľadanie povoľujúcich osôb prebieha tak, že sa najprv nájde predvolené stredisko z Typu štruktúry, tzn. stredisko, z ktorého sa začína hľadať, a postupne sa nazbierajú všetky jeho nadriadená strediska až k prvej hladine Typu štruktúry. K zoznamu nájdených stredísk sa vyhľadajú všetky platné PM, ktoré majú platnú niektorú z platných kompetencií uvedených v zozname. A k takto získaným PM sa následne vyhľadajú len tie osoby, ktoré majú platné PV.

Východiskovým strediskom pre workfow o osobe / PV je stredisko, ku ktorému má zadávané PV osoby platné priradenie a východiskovým strediskom pre workflow o PM je stredisko, ku ktorému má zadávané PM platné priradenie.

Častou situáciou je použiť pre primárneho príjemcu (tj. príjemcu, ktorý schvaľuje) pravidlo 1 - Manažér a pre Sekundárnych resp. Ďalších príjemcov pravidlo 12 - Zástupcovia manažéra. Zástupca manažéra sa teda o žiadosti dozvie, ale primárne sa mu vo Wflow k odsúhlaseniu neponúka. Iba ak dostal profil pre zastupovanie manažéra (Adm15, Adm01), môže, ak sa pod ním prihlási, vykonať vo Wflow príslušné prihlásení miesto manažéra.

3.7.3 Makrá predlôh oznámenia

Predlohy oznámenia sú jazykovo sledované texty. Jazyk sa ale určuje podľa odosielateľa kroku. Niektorí teda vytvárajú dvojjazyčné texty.

Vlastné predlohy sú buď textové alebo html. Do html však nedávajte žiadne grafiku / obrázky priamo. Vždy iba odkazom.

Od e201503 je text e-mailu, interného mailu resp. Wflow generovaný pre WF 11-20 v jazyku príjemcu.
Aparát workflow sa pre akcie 11-20 tj. CEP a schvaľovanie ZLM snažia podľa príjemcu a jeho jazyka uvedeného u priradených profilov, zistiť aký je jazyk príjemcu a v ňom potom správu vytvoriť.
Celé je to však podmienené existenciou predlohy správy (Adm14) v tomto jazyku.

V java klientovi v editore predlohy sú ponúkaná makrá aj s popisom v lokálnom menu.

Evidenční workflow 5-10, která pouze drží předlohu pro e-mail, jsou nyní editovány v speciálním zjednodušeném formuláři Adm33.

Makrá použiteľná v Predlohách oznámenia, resp. v Názve workflow kroku (ide do predmetu e-mailu):

Najprv funkčnosť platná pre všetky predlohy:

Ak makro %TEXT% v predlohe uvedenej nie je, dôjde k jeho pripojeniu na koniec textu správy. Toto platí pre úplne všetky workflow.

V makre TEXT, pokiaľ nie je ďalej uvedené inak, býva najčastejšie textová poznámka pri schvaľovaní.

Makra pre všetky workflow:

%ID_SWORKFLOW2% ID - unikátny identifikátor workflow kroku

%JMENO_BEZTIT% - osoba, o ktorej je WFL v tvare Meno Priezvisko

%JMENO_CELE% - osoba, o ktorej je WFL v tvare Priezvisko Meno Tituly

%JMENO_CELE_BEZTIT% - osoba, o ktorej je WFL v tvare Priezvisko Meno

%ROZHODL% cesworkflow2.id_toso_rozhodl Priezvisko Meno OSCPV(z kmen. PV)

používateľa, ktorý rozhodol (tj schválil resp. zamietol) krok workflow

%ROZHODL_JMENO_BEZTIT% tj. %ROZHODL% ale vo formáte Meno Priezvisko%ROZHODL_JMENO_CELE% tj. %ROZHODL% ale vo formáte Priezvisko Meno Tituly

%ROZHODL_JMENO_CELE BEZTIT% tj. %ROZHODL% ale ale vo formáte Priezvisko Meno

EMPNR_ROZHODL% - osobní číslo

%AUTOR% - Autor v tvare Priezvisko Meno OSCPV(z kmen. PV)

resp. %AUTOR_JMENO_BEZ_TIT%, %AUTOR_JMENO_CELE%, %AUTOR_JMENO_CELE_BEZ_TIT% - anal.

%STATUS_NEW% - hodnota statusu po odsúhlasení/zamietnutí

%STATUS_NEW_EN% - vždy anglický text, bez ohľadu na jazyk príjemcu

%STATUS_NEW_SK% - vždy slovenský text, bez ohľadu na jazyk príjemcu

%STATUS_OLD% - pôvodná hodnota statusu

%STATUS_OLD_EN% - vždy anglický text, bez ohľadu na jazyk príjemcu

%STATUS_OLD_SK% - vždy slovenský text, bez ohľadu na jazyk príjemcu

%WEB2% odkaz na EGJEWEB2 z Adm21 - v html riešený vrátane uzatvorenia do <a> a </a>

%WEB2URL% odkaz na EGJEWEB2 z Adm21 - bez uzatvorenia <a> a </a>
Pro doplnenie odkazu o formulár atp.
prik.: %WEB2URL%/#form=Wflow&formParams=%ID_SWORKFLOW2%

vede na https://xxxxx.cz/#form=Wflow&formParams=15929388
Prípadne, ak máte v Adm21 / Parametre komunikácie / http (s) adresa EGJEWeb(2) uvedenú adresu s lomkou na konci, už ho nedávajte do adresy tu. Teda napr.: %WEB2URL%#form=Wflow

WF 1 - Prechod medzi strediskami

%EMPNR% - osobné číslo

%STATUS_NEW% hodnota štatusu akcie

%TEXT% text akcie

WF 2 - Finančné schvaľovanie vzdelávania

+ WF 4 - Schvaľovanie účasti na vzdelávacej akcii

makrá WF 5 a ďalej:

%EMPNR% - osobné číslo

%PRICE_ORG% - cena organizácie

%MANAGER_MAIL% - e-mail manažéra

%MANAGER_ID_TOSO% - manažér

%STATUS_NEW% - hodnota štatusu po odsúhlasení/zamietnutí

%STATUS_OLD% - pôvodná hodnota štatusu

%TEXT% - textová poznámka pri schvaľovaní

%ID_HZPUS% = cehzpus.id_hzpus spôsobilosť (kurzu)

%ID_HZPAKCE% = cehzpakce.id_hzpakce Vzdelávacia akcia

%REFERENT_JMENO% (len Meno, Priezvisko)

%REFERENT_PMI% (str3, len názov prac. miesta)

%REFERENT_TEL% (druh komunikácie 12, iba hodnota)

%NAHR_POCET% - Počet aktuálne prihlásených náhradníkov

%ESTIMATED_COSTS% - Cena za jedného účastníka: Kva06/Náklady na vzdelávanie/Cena za jedného účastníka

WF 4 - Schvaľovanie účasti na vzdelávacej akcii

má naviac:

%KB_STRAVA_ZADOST% - atribút žiadosti Kva16fkb

%KB_UBYTOVANI% - atribút žiadosti Kva16fkb

%KB_DOPRAVA% - atribút žiadosti Kva16fkb

%KB_SPECIFIKACE% - atribút žiadosti Kva16fkb

%KB_POZNAMKA% - atribút žiadosti Kva16fkb

WF 3 - Schvaľovanie požiadavky na vzdelávanie

%OSCPV% - osoba OSCPV

%KOD_ZPUS% - kód spôsobilosti

%NAZEV_ZPUS% - názov spôsobilosti

%SOUHRN_ELA% - súhrnné údaje o požiadavke

%MISTO_KON% - miesto konania

%PLAN_DO% - plán od (požiadavka)

%PLAN_OD% - plán do (požiadavka)

%REF_VZDEL% - referent vzdelávania

%REF_VZDEL_NAZEV% tj. %REF_VZDEL% ale bez kódu

%SPEC_KURZ% - špecifikácia požiadavke

%NAZEV_AKCE% - zvolená akcia

%AKCE_OD% - akcia od

%AKCE_DO% - akcie do

%ID_DODAVATEL% = cehzpus.id_hzporgskol

%CENA_ORIENT%= cehzpus.cena_orient

%TEXT% - textová poznámka pri schvaľovaní

%ID_HZPUS% = cehzpus.id_hzpus spôsobilosť (kurzu)

%AUTOR% = cehtosozpuspoz.id_toso_autor Kva07/Autor (požiadavky)

Oscpv Priezvisko Meno Status_PV

WF 3 a WF 5 Pozvánky na vzdelávaciu akciu

%EDU_PLACE_ADR% Miesto škol. adresa

%HOURS_FROM_TO% Hodiny od – do

%SPECIF% Špecifikácia (body obsahu)

%EDU_ORG% Školiaca organizácia

%LECTORS% Lektor (resp. Lektori) prizvisko, meno, tituly.

%CONT_PER% Zoznam kontaktných osôb – keď ich je viacej, vypíše všetkých

%NR_DAYS% Počet dní

%NR_HOURS% Počet hodín

%HOURS_FROM_TO% Hodiny od – do

%HTML_LINK% - Odkaz (web, zo spôsobilosti)

%CONTENT% - Obsah kurzu (zo spôsobilosti)

%LITER% - Literatúra (zo spôsobilosti)

%PARTIC% Počet účastníkov

%MIN_PARTIC% Minimálny počet účastníkov

%ESTIMATED_COSTS% - Predpokladané náklady (cena_jeden)

WF 11, 12 Schvaľovanie cestovného príkazu

%CISLO_CP% - číslo cestovného príkazu
%CP_DESC% - pracovná cesta - plný popis

%CP_DESC_MINI% - pracovná cesta - zkrátený popis
% CP_DESC_PRU% - klon makrá% CP_DESC%, ktorý u dátumových (dátum začiatku cesty, dátum ukončenia cesty), časových (čas začiatku cesty, čas ukončenia cesty) a lokalitu (miesto konca cesty) špecifikujúcich hodnôt vychádza z priebehu cesty.

%TEXT% - textová poznámka pri schvaľovaní
%ZALOHA_POZ% - požadovaná záloha
%STATUS_NEW% - hodnota štatútu po odsúhlasení / zamietnutí
%STATUS_OLD% - pôvodná hodnota statusu
%ID_VAL% - interný jednoznačný identifikátor pracovnej cesty

WF 15-20 Schvaľovanie dovolenky a iných ZLM vedúcim

%SLM_NR% %SLM_NAZEV% - číslo a názov schvaľovanej ZLM

%DATUM_OD%% DATUM_DO% - začiatok a koniec dovolenky (resp. inej ZLM)
%DETAIL_OD% %DETAIL_DO% - detail

%POZN% - textová poznámka pri schvaľovaní (obsahuje aj generované info o prečerpaní nároku)

Pozor, nepotláča tlač komentára na koniec textového bloku

% TEXT% - textová poznámka pri schvaľovaní (obsahuje aj generované info o prečerpaní nároku)

Jeho použitie potláča tlač komentára na konci textového bloku

%STATUS_NEW% - hodnota štatútu po odsúhlasení / zamietnutí
%STATUS_OLD% - pôvodná hodnota statusu
%ID_VAL% - interný jednoznačný identifikátor dovolenky (resp. inej ZLM)

Makrá s priamym určením jazyka:

%SLM_NAZEV_EN%,%SLM_NAZEV_CZ% %SLM_NAZEV_SK%

%DETAIL_OD_EN% %DETAIL_OD_CZ% %DETAIL_OD_SK%

%DETAIL_DO_EN% %DETAIL_DO_CZ% %DETAIL_DO_SK%

%CASTKA% (WF 16, 17)

%STATUS_NEW_EN% %STATUS_NEW_CZ% %STATUS_NEW_SK%

%STATUS_OLD_EN% %STATUS_OLD_CZ% %STATUS_OLD_SK%

%ROZHODL% cesworkflow2.id_toso_rozhodl Priezvisko Meno Oscpv (z kmeň. PV)

% STRU% - K zadanému prvku štruktúry zobrazí KÓD - NAZEV a keď štruktúra na požiadavke nie je, tak pole zostane prázdne.

(Štruktúru je možné zadať na Vst15, typ sa určí na Adm21)

WF 21 Schvaľovanie SLM IV.

%STATUS_NEW% - hodnota statusu po odsúhlasení/zamietnutí

%TEXT% - začiatok a koniec dovolenky (resp. iné SLM)

%ALL_RECORDS% - zobrazuje hodnoty osčv – meno – suma

%ALL_RECORDS_POZN% - zobrazuje hodnoty osčv – meno – suma - poznámka

%KOD_DOKLADU% - kód dokladu

%NAZEV_DOKLADU% - názov dokladu

%KOD_OBDOBI_DOKLADU% - kód obdobia dokladu

WF 32 – Schvaľovanie žiadosti o mobilitu KB

%MOBPOZ_DATUM%, %MOBPOZ_TYP%, %MOBPOZ_STATUS%

resp. štandardné typu %OSCPV%, %JMENO_CELE%

WFL 34, 35 - Žiadosť o benefit

% BEN_KOD% - kód benefitu (z Bec01)

% BEN_NAZEV% - názov benefitu (z Bec01)

% POZN% - poznámka z žiadosti (Ben07)

WFL 40 – Uchádzači Rew01

% JMENO_CELE% - celé priezvisko a meno uchádzača (s titulmi)

% EMAIL% - e-mail uchádzača pre výberové konanie

% VYB_RIZ% - názov výberového konania

% VYB_RIZ_OD% výberové konanie od

% VYB_RIZ_DO% výberové konanie do

% DAT_NAST_PREDPOKL% predpokladaný dátum nástupu

% DAT_NAST% dátum nástupu

% REF_UCHA% - referent uchádzača

% STATUS_NEW% - hodnota statusu po odsúhlasení / zamietnutí

% STATUS_OLD% - pôvodná hodnota statusu

WF 101 - 126 eProposal

Keďže eProposalov je veľa typov, veľmi často sa používa implicitný text oznámenia, ktorý aplikácia vytvorí, keď je predloha prázdna.

%JMENO_CELE% - celé meno osoby, o ktorej je eProposal (iba u zmenových eProposalov o osobe a PV).

%SKUPINA_EPR% - názov skupiny eProposalu

%TYP_EPR% - číslo/výčet typu eProposalu

%VALID_FROM% - platnosť Od daného eProposalu

%VALID_TO% - platnosť Do daného eProposalu

%DETAIL% - detailný výpis hodnôt v danom eProposalu

%STATUS_NEW% - hodnota štatusu workflow po odsúhlasení/zamietnutí

%STATUS_OLD% - hodnota pôvodného štatus workflow

%TEXT% - obsah položky "Ďalšie upresnenie" aj s popiskom, pokiaľ je vyplnený.

%ID_EPROPOSAL% - číselné ID daného eProposalu (konkrétne hodnota DB položky cesworkflow1.id_sworkflow1)

%AKT_SCHVALUJE% - aktuálny schvaľujúci daného kroku eProposalu.

%ROZHODL% cesworkflow2.id_toso_rozhodl Priezvisko Meno Oscpv (z kmeň. PV)

WF 301 - 399 Dokument

%JMENO_CELE% - celé meno osoby

%PLATNOST_OD% - platnosť Od dokumentu

% PLATNOST_DO% - platnosť Do dokumentu

%STATUS_NEW% - hodnota statusu workflow po odsúhlasení / zamietnutí

%STATUS_OLD% - hodnota pôvodného statusu workflow

%SOUBOR% - Názov súboru z dokumentu

%TYP_SOUBORU% - Typ súboru z dokumentu

%TYP_DOKUMENTU% - Typ dokumentu

%ROZHODL% cesworkflow2.id_toso_rozhodl Priezvisko Meno Oscpv(z kmen. PV)

%VSECHNYPOZN% - vypíše všetky poznámky od všetkých schvaľovateľov s komentárom.

%TEXT2_POZN% - zapisuje auditnú stopu aj v prípade, že nie je vyplnený komentár k schváleniu dokumentu

Upozornenie: Workflow používa (voliteľne) komunikáciu pomocou externej pošty (e-mailu). Aby boli e-maily zo systému odosielané, je potrebné nastaviť "Konfiguráciu pripojenia k poštovému serveru" - viď EGJE_provdoc_sk.

3.7.4 iCalendar

Na záložke "Č. iCalendar "možno upraviť obsah správy pre iCalendar.

Možno vyplniť položku "Predmet správy". V položke možno použiť rovnaké makrá ako v predlohe oznámenia. Pre zrušenie správy sa k predmetu automaticky pridá prípona "- zrušenie".

Pokiaľ je vyplnená položka "Posun notifikácie iCalendar ..." nastaví upozornenie o XX minút pred začiatkom udalosti.

V tabuľke idú zadávať parametre a ich hodnoty, ktoré sa do správy majú vložiť. Možno nastaviť parametre pre MS Outlook napríklad X-MICROSOFT-CDO-BUSYSTATUS s hodnotou WORKINGELSEWHERE. Viac informácií nájdete v dokumentácii k parametrom MS.

3.7.5 Konkrétne workflow

V kapitole popisujeme workflow, ktoré nie sú opísané inde.

3.7.5.1 Akcia 15-20 Schvaľovanie dovolenky a ďalších neprítomností

Akcia je popísaná v Dov_uzdoc/ Dov05.

A to vrátane možnosti zápisu do kalendára pomocou generovania správ iCalendar pre definované ZLM a možnosti pridať k niektorým žiadostiam prílohu.

3.7.5.2 Akcia 32 - Schvaľovanie žiadosti o mobilitu KB

Workflow figuruje vo formulároch Mob01 a Wflow.

Odvíja sa okolo statusu mobpob_status:

0 Koncept

1 Zamietnuté

2 Ukončené

3 Neaktuálne

4 Neprijatie ponuky

10 Odoslané na schválenie

19 Editácia konzultantom

20 Schválené

21 Schválené (po editácii)

30 Vytvoril

Žiadosť sa podáva na záložkách Záver a odoslanie a v Adm14 je popísaná krokom 0 => 10

jeho príjemcu potom schvaľuje nasledujúcim krokom 10 => 20 (1 zamietnuté).

Na záložkách Konzultant potom sú tlačidlá, ktoré umožňujú úpravu workflow konzultantom.

tj. akcia 20 => 19 a následné uloženie zmeny s potvrdením zadaných zmien 19 => 21 resp. návrat k pôvodným hodnotám 19 => 20.

Konečná úprava sa vykonáva na záložkách HR, kde sú dostupné akcie zo statusu

20 (resp. 21) => 30 (realizácia workflow)

alebo na 3 alebo 4.

Tabuľka krokov workflow je teda taká:

*Hodnota WFL statusu*	*Konečný status*	*Konečný status - zamietnuté*	*Názov workflow kroku*
0 – Koncept	10 - Odoslané k schváleniu		Vytvorenie požiadavky na mobilitu
10 - Odoslané k schváleniu	20 – Schválené	1 – Zamietnuté	Schválení požadavky na mobilitu
19 - Editácia konzultantom	20 – Schválené		Zrušenie editácie požiadavky na mobilitu konzultantom
19 - Editácia konzultantom	21 - Schválené (po editácii)		Koniec editácie požiadavky na mobilitu konzultantom
20 – Schválené	19 - Editácia konzultantom		Editácia požiadavky na mobilitu konzultantom
20 – Schválené	3 – Neaktuálne		HR zapísalo požiadavke na mobilitu status neaktuálna
20 – Schválené	30 – Realizované		HR zapísalo realizáciu požiadavky na mobilitu
20 – Schválené	4 - Neprijatie ponuky		HR zapísalo požiadavke na mobilitu status Neprijatie ponuky
21 - Schválené (po editácii)	3 – Neaktuálne		HR zapísalo požiadavke na mobilitu status neaktuálna
21 - Schválené (po editácii)	30 – Realizované		HR zapísalo realizáciu požiadavky na mobilitu
21 - Schválené (po editácii)	4 - Neprijatie ponuky		HR zapísalo požiadavke na mobilitu status Neprijatie ponuky

Poznámky k formuláru Mob01:

• žiadosť sa smie kopírovať iba v statuse 4 a to používateľom HR

• užívateľ s právom VL_OSO (tj. zamestnanec):

o nikdy nevidí a needituje komentáre záložiek Konzultant a HR

o komentár schvaľovateľ vidia, ale needituje

o editovať dáta smie len v statuse 0

• manažér - mal by na formulár mať iba právo 1 čítania (svoj komentár vyplní vo Wflow)

• konzultant - má špeciálny objekt práv Mob01konzultant

o keď má toto právo, tak všetko má len na čítanie s výnimkou záložky Konzultant

o ďalej potom smie stlačiť v statuse 20 tlačidlo Otvoriť k úprave (zál. Konzultant) - to prepne status do 19

o a v statuse 19 potom tlačidlo "Ukončiť úpravy" (status => 21) alebo "Uzavrieť úpravu - bez zmeny" (status späť na 20 s návratom hodnôt uložených pri predchádzajúcej akcii)

o v statuse 19 smie konzultant editovať všetko, okrem záložiek Schvaľovateľ a HR.

• HR - má špeciálny objekt práv Mob01hr

o keď má toto právo, tak všetko má len na čítanie s výnimkou záložky HR

o v statuse 20, 21 má k dispozícii tlačidlá

- Realizovať (status => 30)

- Neaktuálne (status => 3)

- Neprijatie ponuky (status => 4)

o Pozn. všetky tri tlačidlá cez worfklow generujú správy na všetky zúčastnené

o Vo statusu 4 má povolenú funkciu kópia - vytvorí sa nová žiadosť so statusom 20

Sú skopírované hodnoty okrem komentárov + aktualizácia dátumu požiadavky. Do komentára HR o pohovoru je vložený Kópia požiadavky + dátum.

• admin má špeciálny objekt Mob01statusAdmin

o smie editovať status, nech je v ňom akákoľvek hodnota

3.7.5.3 Akcia 82 - 85 - Hodnotenie

Nové hodnotenie spojené s workflow. V súčasnosti máme 4 samostatné schvaľovania:

- 82 – Sebahodnotenie

- 83 – Hodnotenie osoby manažérom

- 84 – Sebahodnotenie cieľov

- 85 – Hodnotenie cieľov manažérom

Dvojice 82 a 84 majú rovnaké stavy workflow:

- 0 Koncept

- 50 Odoslanie notifikácie

- 100 Vyplnené zamestnancom

- 105 Kalibrácia

- 110 Vrátené do opravy manažérom

- 120 Vrátené do opravy schvaľovateľom

- 130 Žiadosť o stiahnutie

- 200 Poslané na schválenie

- 250 Prizvanie schvaľovateľov

- 300 Schválené

Resp. 83 a 85:

- 0 Koncept

- 50 Odoslanie notifikácie

- 300 Vyplnené manažérom

- 305 Kalibrácia

- 320 Vrátené do opravy schvaľovateľom

- 400 Prizvanie schvaľovateľov

3.7.5.4 Akcia 301-399 - dokument Workflow

Dokument workflow je samostatne obchodovaná komponenta a majú ju sprístupnené len tí zákazníci, ktorí ho zakúpili.

Stručne: dokument môže podliehať worfkflow, ak je záznam v Opv31 s takým typom dokumentu, u ktorého je v Jpc01, uchaz_dok_typ označené workflow ako dobrovoľné alebo povinné.

Ďalšou podmienkou je zaradenie typu pod jednu z workflow akcií tu, v Adm14.

Vlastné nastavenie v Adm14

Na Detaile definície workflow je možné nastaviť, či má byť pri spustení workflow dokumentu vykonaná konverzia jeho formátu (pole Konvertovať formát dokumentu) a ak áno, na aký formát (pole Spôsob konverzie formátu dokumentu, aktuálne možno konvertovať Rtf na Pdf)WFL akcie 301-399 obsahuje položky:

Rtf2 * ukladané do Opv31 poslať do schvaľovania - Áno / Nie default Nie

Obmedziť len na SJ: (voliteľné obmedzenia)

WFL sa smie zúčastniť zastupujúci: JPC dok_zastup:

0 - Nie

1- Áno, odosielať aj pôvodnému adresátovi,

2- Áno, neodosielať pôvodnému adresátovi

a podzáložky:

Záložka Typy dokumentov:

Tabuľka umožňuje zadať typy dokumentov (JPC uchaz_dok_typ), ktoré budú pod workflow spadať. Jeden typ dokumentu smie byť podriadený iba jednému workflow.

Upozornenie: každý typ dokumentu, ktorý tu uvádzate, musia mať tiež definované v Jpc01, číselník "uchaz_dok_typ", teda tam kde je typ dokumentu definovaný, hodnotu

"Opv31 - typ schvaľovanie dokumentu:"

1 - Môže a nemusí byť schvaľovaný/podpisovaný

alebo

2 - Musí byť schvaľovaný/podpisovaný

Podľa toho je potom jeho odoslanie na schvaľovací proces z Opv31 dobrovoľné alebo povinné.

Záložka Statusy

Tabuľka umožňuje zadať zoznam / číselník statusov tejto akcie

Pre tvorbu statusov platia tieto pravidlá:

• schválený dokument nech má vždy status 30

• Zamietnutý musí mať štatút <0, (status -99 je alokovaný pre neštandardné ukončenie workflow, viď dokumentácia pre elektronické podpisy ElPo_uzdoc, kapitola Akcia pre užívateľov so špeciálnym oprávnením)

• Koncept má status 0

Adm14 sa potom v časti kroky riadi týmito používateľskými statusmi.

Predlohy oznámenia potom ponúka niekoľko makier pre tieto workflow.

Opv31 / Workflow je opísaný v Opv_uzdoc

Zostavy Rtf2x

Zostava nastaví u uloženého dokumentu status worfklow = 0 - Koncept v prípade že:

• používateľ chce výsledok zostavy uložiť do Opv31

• je vybraný typ dokumentu, u ktorého je v Adm14 nastavené

Rtf2 * ukladané do Opv31 poslať do schvaľovania = Áno

Dokument je potom možné z Opv31 odoslať do príslušného workflow.

3.8 Adm15 - Zastupovanie vlastnej osoby

Umožňuje zadať časovo obmedzené zastupovanie na vlastnom profile inej osobe a pomocou tlačidla

"Poslať správu o zastupovaní" odoslať správu v tvare:

Oznámení o zastupovaní

Zastupovaná osoba: celé meno

Profil: profil

Od: dátum_od

Do: dátum_do

Technicky je zastupovanie na profile popísané v EGJE_Provdoc kap. Zastupovanie používateľa na profile.

Tu popíšeme len položku "Odosielať WFL e-maily", kde má manažér na výber jeden z režimov:

0 - Neodosielať

1 - Odosielať pre všetky workflow (mimo prav. vl. Osoba 5,6)

2 - Dtto 1, ale neodosielať pôvodnému adresátovi

3 - Poslať iba schvaľovanie ZLM WFL15 (tiež mimo prav. 5,6)

4 - Dtto 3, ale neodosielať pôvodnému adresátovi

5 - Odosielať všetko okrem CEP WFL11,12 (tiež mimo prav. 5,6)

6 - Dtto 5, ale neodosielať pôvodnému adresátovi

7 - Poslať iba CEP WFL11-14 (tiež mimo prav. 5,6)

8 - Dtto 7, ale neodosielať pôvodnému adresátovi

9 - Odosielať všetko okrem WFL15 - dovolenka ai. (tiež mimo prav. 5,6)

10 - Dtto 9, ale neodosielať pôvodnému adresátovi

11 - Poslať iba info správy o schválenej ZLM a prac.cestě

Hodnotou> 0 teda zariadi to, že určité e-maily z workflow bude dostávať aj tu, v Adm15, uvedený zástupca.

Hodnoty 1 - 10 sú určené pre tých zástupcov, ktorí zastupovanie v EGJE skutočne vykonávajú,

zatiaľ čo hodnota 11 je určená tým, ktorí len majú byť informovaní o tom, že nejakému zamestnancovi bola schválená ZLM (zvyčajne ide o dovolenku) resp. o tom, že niekomu bola schválená pracovná cesta.

Pozn.: Takému používateľovi nie je nutné priraďovať profil, cez ktorý sa ako zástupca do EGJE prihlási, je to ale možné.

Režimy 3-6 potom vedú k tomu, že zástupca vo formulári Wflow (resp. pruhu Správy základnej obrazovky HR Portál) vidí len určité typy workflow.

V akých profiloch môže byť manažér zastupovaný?

V tých, ktoré má priradené a ktoré majú v Adm02 vyplnenú položku "Zastupovanie profilom". Jeho profil teda buď nie je určený na zastupovanie, alebo môže byť zastúpený tým samým profilom, alebo môže byť zastúpený iným profilom (zvyčajne s obmedzenými objektovými právami).

3.9 Adm19 – Klasifikácia výstupov EGJE

Formulár umožňuje na VOPRED určených zostavách definovať text, ktorý sa následne bude zobrazovať v záhlaví zostavy. Okrem textu je možné zvoliť jeho farbu, veľkosť, či má byť text tučný, podčiarknutý alebo kurzívou a platnosť zobrazenia. Jedná sa napr. o klasifikáciu „VEREJNÉ“, „NEVEREJNÉ“, „TAJNÉ“. Ďalej je možné použiť daný text aj ako vodoznak. Okrem samotného nastavenia na Adm19 musí zo strany Elanoru dôjsť k úprave samotnej zostavy. Prevažne sa jedná o užívateľské zostavy, štandardné zostavy zatiaľ podporované nie sú.

3.10 Adm20 - Pokyny k stiahnutiu

Nový formulár, umožňuje vkladať súbory (do veľkosti 5 MB) obsahujúce pokyny k jednotlivým formulárom/zostavám. Namiesto súboru možno vyplniť položku Prepojenie (web). V takom prípade sa vo webovom prehliadači otvorí daný odkaz. Pri existencii súboru pre daný formulár/zostavu sa na formulári/zostave objaví tlačidlo, pomocou ktorého možno súbor stiahnuť a otvoriť.

Možno zvoliť jazyk súboru, kedy sa prednostne vyhľadáva súbor s jazykom používateľa, ak taký nie je potom súbor s jazykom CS, ak neexistuje tak s EN, ak neexistuje tak s nevyplneným jazykom.

Ak sa vyberie správna jednotka, musí mať užívateľ kmeňové PV na danej správnej jednotke. Pri nevyplnení je súbor spoločný pre všetkých.

Pri vyplnení organizácie musí byť profil užívateľa obmedzený organizáciou. V prípade multiorganizačného profilu musí ísť o hlavnú organizáciu. Pri nevyplnení je súbor spoločný pre všetkých.

Dokumenty majú dátumovú platnosť, načítajú sa k referenčnému dátumu.

Pokyny sa otvárajú tlačidlom "STIAHNUŤ POKYNY":

U štandardného klienta:

- na formulári - umiestneným v hornej lište vedľa tlačidla pre vyhľadávanie.

- v dialógu - umiestneným v hornej lište vedľa editačných tlačidiel, ak dialóg hornú lištu nemá, tlačidlo sa nezobrazí.

U webového klienta:

V referentskom rozhraní:

- Na formulári - umiestneným v hornej lište vedľa tlačidla pre vyhľadávanie

V HR Portálu:

- umiestneným v dolnej lište vedľa tlačidla "Aktualizácia"

V dialógu pre referentské rozhraniE i HR Portál:

- Malou ikonou otáznika naľavo od ikony na zväčšenie / zmenšenie dialógu.

- Tlačidlom pravej hornej časti dialógu.

3.11 Adm21 – Konfigurácia - organizácia

Individuálny formulár o dátach organizácie

Navigácia: Zoznam organizácií

Formulár umožňuje prácu s dátami a parametrami spoločnými pre celú spracovávanú organizáciu.

Vlastné dáta o organizácii sú organizované v záložkách.

Pozor! Podľa toho, či je v db jedna organizácia alebo viac, sa systém EGJE správa ako jedno organizačný alebo viac organizačný. Táto informácia je zisťovaná na začiatku každého sedenia a u jedno organizačných pre zjednodušenie býva často položka Organizácia zatienená a je vyplňovaná automaticky tou jedinou organizáciou, ktorá v db je.

Zmena typu databázy jedno <=> viacej organizačná je závažnou zmenou pre správanie aplikácie. Odporúčame po kompletnom vykonanie tejto zmeny reštartovať AS resp. WEB EGJE server. Pre nastavenie / zmenu legislatívy organizácie / SJ platí to isté.

Záložka „Údaje o organizácii“

Obsluha: Popis, základné atribúty organizácie

Položky:

Kód organizácie

Názov bežný pre interné zostavy a potreby

Názov oficiálny pre externé výstupy

Časové pásmo organizácie

Hl. organizácia

Implicitný kód jazyka

Zak.

Generovanie osobného čísla

Štandardný zpôsob, kedy osobné číslo je generované vzostupne z číselných hodnôt (maximálna plus jedna) je doplnený o ďalšie režimy.

Zvolený režim sa nastavuje pomocou položiek:

OSCPV - režim generovaní - s hodnotami:

0 - Štandard (číselný so suffixom .pv),

1 - Konfigurovateľný - suffix .pv,

2 - Konfigurovateľný - bez sufixu.

3 - Režim prefixu zo SJ (rôzne IČO)

4 - Režim prefixu zo SJ (rôzna IČO) + spoločný rad

5 - Režim prefixu SJ bez oddeľovača (rôzne IČO)

Pre režimy 1 a 2 potom režim špecifikujú doplňujúce položky:

OSCPV - dĺžka suffixu - iba pre režim 2 - povolené hodnoty 2 nebo 3 - suffix je používaný pre číslo PV v rámci osoby,

OSCPV - celk.max. dĺžka - určuje celkovú maximálnu dĺžku (obe časti a oddeľovač),

OSCPV - dopĺňať na max. dĺžku - Áno / Nie
prípadné dopĺňanie sa vykonáva ľavostrano pomocou hodnoty nula „0“
To umožní, aby znakové osobné číslo PV bolo klasifikované zhodne s jeho číselným významom,

OSCPV - prefix pre organizáciu
Položka umožňuje zadať až 3-miestný prefix, ktorý bude pre danú organizáciu predsazovaný pred generované číslo. Prefix je využiteľný predovšetkým v režime multiorganizácie (viacej organizácií v jednej inštalácii EGJE),

OSCPV - generovať do medzier - Áno / Nie
Nová hodnota oscpv nie je hľadaná pomocou maximálnej hodnoty, ale je prechádzaná celá použitá rada a nové oscpv je generované do prvej medzery, ako prvej dosiaľ nepoužité oscpv.

Uvedené algoritmy používa pre generovanie OSCPV Opv04 i Opv05.

Opv05 tiež vyžaduje, keď je nakonfigurovaný režim, že OSCPV sa skladá z OSC bodky a PV, aby OSC bolo u všetkých PV osoby (statusy 1-10) zhodné.

Režimy generovanie OSČPV 3 - režim prefixu zo SJ (rôzne IČO), 5 - Režim prefixu SJ bez oddeľovača (rôzne IČO)

Opv05 (Opv04, Epr01, Rea01) používa rad v rámci SJ s použitím údajov:

Adm22 / Konf.par. / Prefix SJ pre účtovníctvo resp. OSCPV

Adm22 / Konf.par. / Súčasné OSC (režim 3)

K režimu 4 sa na Adm21 viažu ešte prvky

Adm21 / Údaje o org. / OSC dĺžka

Adm21 / Údaje o org. / OSČPV - délkaea Suffix pre PV

Režimy 3, 5 na vyžiadanie zákazníka, ktorý ale má niektoré diskutabilné prvky, pretože zaradenie na SO / SJ je časovo meniteľné.

Na rozdiel od bežných režimov v rámci nemenného zaradenia osoby na organizáciu tu používame "počítadlo" umiestnené na SJ (Adm22 / Konf.par. / Súčasné OSC).

Pri každom započatí zadávaní novej osoby ho o 1 zvýšime a to vo chvíli, keď už v tejto situácii poznáme zaradenie na SO / SJ.

Po prevodoch dát je teda potrebné uvedené údaje nastaviť, aby ručne zadávané osoby naviazali na prevedená dáta.

K uvedenému sa viažu aj parametre použiteľné aj pre ostatné režimy generovanie OSČPV:

Adm21 / Údaje o org. /

Užívateľ - v Adm01p ponechať záporné OSCPV:

Lektor - v Kva06 * ponechať záporné OSCPV:

Zatiaľ čo pre režim 3 je nastavenie uvedených hodnôt na Áno povinné, pretože používatelia a lektori sa v týchto procesoch na SO / SJ ani nezaraďujú, pre ostatné režimy generovanie OSCPV ide o novú možnosť, keď tieto osoby sú podľa záporného OSCPV jasne rozpoznateľné a nezdieľajú číselný rad sa zamestnancami.

Ďalej je možné zadať ešte výrazy pre kontrolu OSCPV:

Sekundárna kontrola OSCPV - statusy 1,2,3 (regul.výraz):

Sekundárna kontrola OSCPV - status 10 (regul.výraz):

Sekundárna kontrola OSCPV - ostatné statusy (regul.výraz):

To sú regulárne výrazy pre záverečnú kontrolu OSCPV tesne pred uložením do databázy.

Uplatnené sú v Opv01, Opv05, Opv04, Adm11.

V EGJE je použitá implementácia reg. výrazov, ktorá je v java JRE tzn. java.util.regex

https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html

tu je uvedený zoznam aj touto implementáciou podporovaných riadiacich kódov.

Príklad 1:

^-{0,1}[0-9]{4,8}\.{1}[0-9]{2}$ znamená, že

oscpv môže, ale nemusí začínať "-"

potom 4 až 8 číslic,

povinná bodka,

a 2 číslice za ňou.

znak ^ znamená začiatok

$ Koniec

v hranatých zátvorkách je množina znakov (často intervalovo s pomlčkou, inak na husto bez oddeľovačov)

v zložených zátvorkách počet opakovaní tu je rozsah oddelený čiarkou teda {0,1} znamená že tam môže a nemusí byť a {4,8} znamená že znakov musí byť medzi 4 a 8.

znak "." sa musí písať s ECAP tzn \.

V regulárnych výrazoch býva viac možností ako napísať podmienku - popisovaný príklad možno napr. zapísať aj takto ^-?\d{4,8}\.{1}\d{2}$

Príklad 2:

^(aa|bb)[A-Z]\d{4,6}\.{1}\d{2}$ znamená, že

musí začínať aa alebo bb,

ďalej musí nasledovať ľubovoľné veľké písmeno,

potom 4 až 6 číslic,

ďalej musí byť.

a za ňou 2 číslice

Materiály

tutorial k java regex http://www.vogella.com/tutorials/JavaRegularExpressions/article.html

použiť ide aj tento český (aj keď je k Perl nie java implementáciu) http://www.regularnivyrazy.info/regularni-vyrazy-zaklady.html

testovať je to možné na celej rade miest, napr. tu:

http://www.regexplanet.com/advanced/java/index.html

kde do Regular expression zadáte výraz pripravovaný pre Adm21 a do vstup1 testované oscpv a tlačidlom Test sa vykoná test či oscpv výraz spĺňa.

Záložka č.IČO

Výstupy celoštátnych výkazov a štatistík bývajú často vyžadované za "vykazovaciu jednotku", ktorou je organizácia.

Skôr využívaný model vychádzal z predpokladov, že základnou jednotou pre styk s okolím je správna jednotka (SJ). To však spôsobovalo problém organizáciám, ktoré majú viac SJ s rovnakým IČO a spoločne tak tvoria vykazovaciu jednotku.

Preto bol založený tento nový číselník "vykazovacích jednotiek".

Záložka „Konfiguračné parametre“

Obsluha: Práca s konfiguračnými parametrami organizácie

Položky:

Parametre organizácie a ich zoznam

Záložka "Mazanie"

Zadáva sa pri hlavnej organizácii.

Definujú sa tu plošné odmazávanie starších nepotrebných dát z pracovných tabuliek, mzdových importov, vstupov, dochádzky, cestovných príkazov, exportných dávok.

Nový parameter pre mazanie starých eProposals bol pridaný do tejto záložky pod názvom „Zmazať eProposaly staršie ako (mesiacov)“. Viac informácií nájdete v dokumentácii pre eProposal.

Záložka „EZM“

Iba pre zákazníkov EZM Elanor

Typ zákazníka - hlavné rozlíšenie pre určenie konvencie pomenovania súborov.

Záložka "Parametre komunikácie"

Nastavenie je popísané v EGJE_provdoc - kapitola "Konfigurácia pripojenia k poštovnému serveru.

Ďalej obsahuje položky opísané v Parametre komunikácie.

V prípade napojenia na podpisový modul Signi je potrebné mať nastavený parameter: http(s) adresa EGJEWeb(2)

Záložka "Self service“

Umožní zadať detailnejšie požiadavky u zamestnaneckých žiadostí:

Zoznam druhov adries pre Pkz21:

Výpočet druhov kontaktov pre Pkz21:

Vyžadovať prílohu pre zmenu priezviska, mena alebo rodinného stavu v Pkz21:

Vyžadovať prílohu pre zmenu zdravotnej poisťovne v Pkz21:

Vyžadovať prílohu zadania občianskeho preukazu v Pkz21:

Vyžadovať prílohu pre zadanie rodinného príslušníka v Pkz21:

Vyžadovať overenie doložených príloh pri schvaľovaní v Pkz23:

Obmedzenie vzdelávacích akcií – počet mesiacov v Pkz21:

Max veľkosť prílohy

Záložka "HR portál" - prispôsobenie dizajnu organizácii

Na úrovni organizácie je možné v novej záložke HR Portál zadať niekoľko voliteľných parametrov pre grafické odlíšenie obrazoviek so spúšťacím menu HR Portál.

Niektoré parametre je možné meniť aj na úrovni SJ (Adm22) a SO (Adm23).Záložka je rozdelená na sekcie podľa konfigurovaného objektu.

Sekcia „Výplatné lístky“

V tejto sekcii sa dá pomocou parametra „Rozpísať ZLM na VLI:“ zaistiť rozpis ZLM na výplatných lístkoch pre formuláre Vyp11,Vyp11fq alebo Vyp31, Vyp31fq. Na týchto formulároch na HR Portále nebolo možné definovať rozpis ZLM, preto bol tento parameter vytiahnutý ako definovateľný na Adm21  záložka “HR Portál”. Do parametra sa vypĺňa hodnota Áno alebo Nie. Pokiaľ nie je nič vyplnené, systém automaticky berie hodnotu Nie. Obsah obrázku text, snímek obrazovky, software, číslo

Popis byl vytvořen automaticky

PkzZ01

Konfigurácia formulára Pkz01 - Personálna karta zamestnanca - obsahuje nasledujúce položky

Pkz- výpočet typov štruktúr referentov pre Kontaktné osoby:

Zoznam typov štruktúr oddelený čiarkami

Pkz - zamestnanie / V organizácii / štruktúra pre 1. stĺpec: štandardne 2 - Organizačný

Pkz - zamestnanie / V organizácii / štruktúra pre 2. stĺpec: štandardne 3 - PM

Pkz - zamestnanie / V organizácii / štruktúra pre 3. stĺpec: štandardne 4 - Profesia

Konfiguruje, ktoré typy štruktúr majú byť v záložke zobrazované. Obvykle 2.

Dov16 - Dovolenka

Konfigurácia formulára Dov16 - Dovolenka - obsahuje nasledujúce položky:

Dov16 - nemazať Plán po prevedení na žiadosť:

Dov16 - možnosť uzatvorenia ročného plánu:

Dov16 - skryť záložku Plán

Podrobnejší popis viď EGJE_web_uzdoc_sk._

Domovská obrazovka HR Portál

Je možné sem umiestniť logo organizácie a to buď do prvého štvorca, alebo na podklad celej obrazovky.

Ďalej je možné meniť rôzne farby.

U viacero organizačnej inštalácie je možné mať viac nastavení. Používateľ bez obmedzenia organizácií má potom nastavený dizajn použitý pre hlavnú organizáciu.

Ide o položky:

"Vzhľady Crisp * - farba textu štvorcov (hexa číslo začínajúce #)"

Príklad # 008b00

"Vzhľady Crisp * - farba podkladu štvorcov (hexa číslo začínajúce #)"

Príklad # d6ead6

"Logo do prvého štvorca (150 x 150 px; objekt práv MENUDL_Home):"

JPG, PNG alebo GIF (teoreticky aj pohyblivý GIF, ale nie je to moc prívetivé a veľmi skoro to omrzí)

"Logo - odkaz na domovské stránky (url)"

Odkaz je nepovinný - pokiaľ je v novej záložke zadaný, je po kliknutí na štvorec otváraná táto adresa.

"Vzhľady Crisp * - farba nadpisu v stĺpci WFL & amp; Správy a odkazy (#hexa)"

Príklad # 008b00

"Logo na pozadí menu HR Portál"

Veľké logo za celú "deviatku" štvorcov. Bude štvorcami čiastočne zakryté.

K prispôsobeniu sa viaže objekt prístupových práv

"MENUDL_Home" - "Logo - 1. štvorec"

jeho priradenie používateľovi (role => profil) spôsobí, že prvým štvorcom portálového menu bude štvorec s logom organizácie

MHRP

Výpočet WFL akcií, ktoré spracuje MHRP (čiarky, pomlčky):

URL adresa aplikácie MHRP:

Dcu06 – Dochádzka

Dcu06 - načítanie navigačného zoznamu podľa aktuálneho obdobia:

Voľba režimu vytvárania nav. zoznamu pre formulár Dcu06.

Áno - navigačný zoznam sa naplní PV platných pre zobrazované obdobie (štandard DOCH)

Nie alebo nevyplnené – navigačný zoznam sa naplní PV platných k referenčnému dátumu

Poznámka: položka nie je dostupná na Adm22.

Dca11 - Dochádzkový terminál

Konfigurácia formulára Dca11obsahuje nasledujúce položky:

Logo na pozadí záložiek Dca11

Odkaz na obrázok, ktorý sa zobrazuje ako podklad pre niektoré záložky Dca11 (záložky s tlačidlami). Obsah sa zobrazí po použití zodpovedajúceho tlačidla.

Farba podkladu štvorcov priechodov (hexa začínajúce #)

Farba použitá pre tlačidlá formulára Dca11, záložka Evidencia príchodov / odchodov

Príklad #d6ead6

Farba podkladu štvorcov žiadosti (hexa začínajúce #)

Farba použitá pre tlačidlá formulára Dca11, záložka Žiadosti o výnimky a Posielanie správ

Príklad #fad6d6

E-mail adresa - pre doručenie správ

e-mail adresa pre odosielanie správ pre tlačidlá formulára Dca11, záložka Posielanie správ

Záložka „Dochádzka“

Na záložke sú parametre určené pre oblasť dochádzky (viac viď. DOCH_dopl_uzdoc_sk, Adm21, Záložka - Docházka).

Záložka „Strava“

Na záložke sú parametre spojené s generovaním nárokov príspevkov na stravu ako i následné vyhodnotenie odobratej stravy resp. stravných lístkov (viac viď. DOCH_dopl_uzdoc, Adm21, Záložka - Strava.

Záložka „Personálne“

Obsahuje položku Výpočet skupín pre workflow 3. Tá umožňuje definovať skupiny (Zpu02), ktoré sa budú workflow zúčastňovať.

Parameter "Prepis mena hodnotiteľa" má priamu väzbu na formulár Hod01.

Záložka „Záložka osoby a mzdy“

Štatistické informácie o počtoch zamestnancov v organizácii na jednotlivých SO za jednotlivé zúčtovacie obdobia.

Záložka "Cestovní príkazy "je popísaná v Cep_uzdoc.

Záložka “Konf.Adm70/71”

Záložka obsahuje v needitovateľnej podobe konfigurácie, ktoré sú nastavené na Adm70/71

Pokiaľ je v navigačnom zozname vybraná hlavná organizácia, potom sa zobrazia na tejto záložke všetky konfigurácie konštanty typu “Aplikačné” a tie konfigurácie konštánt typu “Organizačné”, “Organizácia+SJ+SO”, kde je organizácia rovná hlavnej organizácii a SJ = NULL a SO = NULL

Pokiaľ je v navigačnom zozname vybraná iná ako hlavná organizácia, potom sa zobrazia na tejto záložke tie konfigurácie konštánt typu “Organizačné”, “Organizácia+SJ+SO”, kde je organizácia rovná vybranej organizácii a SJ = NULL a SO = NULL

3.12 Adm22 – Konfigurácia – správne jednotky

Individuálny formulár o dátach správnych jednotiek

Navigácia: Zoznam správnych jednotiek

Formulár umožňuje prácu s dátami a parametrami spoločnými pre správnu jednotku

Vlastné dáta formulára sú organizované v záložkách

Záložka „Údaje o správnej jednotke“

Obsluha: Popis, základné atribúty správnej jednotky

Položky:

Číslo správnej jednotky

Názov bežný pre interné zostavy a potreby

Názov oficiálny pre externé výstupy

Adresa - názov adresáta

Adresa - dourčenie adresáta, ktorý bližšie určuje správnu jednotku v jej položke názov

OKEČ(NACE)

Telefón

Fax

E-mail

ID datovej schránky

Zamestnávateľ odmeňujúci platom (§ 109 odst. 3 ZP) (iba pre pro CZ SJ)

Regionálne školstvo – druh činností škôl a školských zariadení (číselník Druh činností škôl a školských zariadení – regionálne školstvo)

Zriaďovateľ organizácie – štátna správa (číselník Zriaďovateľ organizácie – štátna správa)

Predkladateľ IČO (ISP)

Názov predkladateľa (ISP)

Záložka „Konfiguračné parametre“

Obsluha: Práca s konfiguračnými parametrami správnej jednotky

Položky:

Parametre správnej jednotky

Záložka "Dochádzka"
Na záložke sú parametre určené pre oblasť dochádzky (viac viď. DOCH_dopl_uzdoc).

Záložka Self-service

Obsahuje parametre:

Pkz21mob - zmena personálnych údajov:
=> Osb02

Hodnoty: 1 - Premietané referentom
- referent schvaľuje/premietana Pkz23

2 - Priamy zápis
- zapisuje sa priamo do kmeňa - auditované

3 - Evidenčný zápis
- zostáva iba ako evidovaná žiadosť – bez propisu

4 - Nie je prístupné
- základný spôsob skrytia možnosti zmenu zadať

Nasledujúce parametre majú rovnaké možnosti (číselník) nastavenia:

Pkz21mob - zmena zdravotnej poisťovne:

=> Poj01

Pkz21mob - zmena rodinných príslušníkov
=> Osb02

Pkz21mob - zmena občianskeho preukazu:
=> Osb02

Pkz21mob - zmena dokumentov:
=> Opv31

Pkz21mob - zmena zbrojného preukazu:
zákaznícke riešenie

Pkz21mob - zmena osvedčenia/certifikátu:
zákaznícke riešenie

Pkz21mob - zmena účtu pre dobierku

Pkz21mob - banková cesta - dobierka:

Výber z bankovej cesty priraďovanej dobierkedo Sra01
ála Opv05

Pkz21mob - SLM - dobierka:
Výber SLM priraďovanej dobierke do Sra01
ála Opv05

Záložka “Konf.Adm70/71”

Záložka obsahuje v needitovateľnej podobe konfigurácie konštánt typu “Organizácia+SJ+SO”, ktoré sú nastavené na Adm70/71

Ak je v navigačnom zozname vybraná dan8 SJ, potom sa zobrazia tie konfigurácie týchto konštánt, pre ktoré SJ <> NULL a SO = NULL

3.13 Adm23 – Konfigurácia – správne oddiely

Individuálny formulár o dátach správnych oddielov

Navigácia: Zoznam správnych oddielov

Formulár umožňuje prácu s dátami a parametrami spoločnými pre správny oddiel.

Vlastné dáta formulára sú organizované v záložkách

Záložka „Údaje o správnom oddiele“

Obsluha: Popis, základné atribúty správneho oddielu

Položky:

Číslo správneho oddielu

Názov bežný pre interné zostavy a potreby

Číslo správnej jednotky

Záložka „Konfiguračné parametre“

Obsluha: Práca s konfiguračnými parametrami správneho oddielu

Položky:

Parametre správneho oddielu

Záložka „e-Daňovka“

Žiadosť o RZD možná do (dd.mm)

Pri premietaní Vyhlásení nerezidenta prepisovať evidenciu v Osb02

Záložka „HR Portál“

Dátum uvolnení/vykonaní RZD (dd.mm)

Záložka „Užív.položky“

Záložka “Konf.Adm70/71”

Záložka obsahuje v needitovateľnej podobe konfigurácie konštánt typu “Organizácia+SJ+SO”, ktoré sú nastavené na Adm70/71

Ak je v navigačnom zozname vybrané dané SO, potom sa zobrazia tie konfigurácie konštánt, pre ktoré SO <> NULL

3.14 Adm24 – Kurzový lístok

Formulár pre správu kurzového lístka mien (využitie pre cestovné príkazy)

Navigácia: Kalendárne dni

Formulár umožňuje prácu s evidenciou kurzov mien.

Položky:

Dátum od–do – dátum platnosti uvedeného menového kurzu

Koľko (mena)

Je za 1 (menu)

Kurz – udáva koľko meny XXX uvedené v položke „Koľko“ je za 1 jednotku meny uvedenej v položke „Je za“

Uvedenú kurzovú tabuľku je možné udržiavať buď ručne, alebo je možné využiť funkčného tlačidla „Import z webu“, ktoré naplní tabuľku údajmi z ročného kurzového lístka uvedeného na webu ČNB (pre ČR) alebo na webu NBS (pre SK). Podľa nastavenej legislatívy u organizácie na Adm21, je možné pomocou checkboxu "Obmedziť kurzový lístok podľa legislatívy" nastaviť import len z jedného zdroja.

Odkaz pre ČR :

https://www.cnb.cz/cs/financni-trhy/devizovy-trh/kurzy-devizoveho-trhu/kurzy-devizoveho-trhu/

Odkaz pre SR :

https://nbs.sk/export/sk/exchange-rate-annual/

Aktualizované sú iba meny už uvedené v kurzovnom lístku a ktorých záznam v Adm24:

· Dátum OD nie je starší ako 2 mesiace

· Je vyplnená legislatíva (buď CZ alebo SK)

· V položke Koľko[mena] je pre CZ legislatívu vyplnená hodnota „CZK“,
zatiaľ čo u SK legislatívy je tomu presne naopak - je potrebné vyplniť Euro do položky Je za[mena]
Dôvodom je odchylná stavba tabuliek ČNB a NBS.

· Majú vyplnenú cieľovú menu (druhá položka pre menu)

CZ - ďalšie kurzy:

Okrem kurzov v základnej kurzovej tabuľke existujú aj menej často aktualizované kurzy pre neštandardné meny (napr. Ukrajina UAH) .Ak v tabuľke nejaký taký kurz je uvedený Adm24 / Import z webu teraz hľadá aj v týchto kurzoch (pozri https://www.cnb.cz/cs/financni-trhy/devizovy-trh/kurzy-ostatnich-men/))

Pozn.: K tomu je potrebný prístup na internet, vrátane prípadného dodefinovania proxy (pozri EGJE_Provdoc / 3.3 Stanica používateľa pre štandardného klienta

Pozn.: Sledované meny sú definované v JPC cp_meny. Definíciu používateľom individuálne sledovaných mien je možné zadať na formulári Jpc01 v číselníku cp_meny do časti Hodnoty používateľ (EGJE definuje iba meny, ktoré sa týkajú spracovávanej legislatívy, teda CZK a EUR (SKK))

Pozn.2: Kedy sú kurzy aktuálne (podľa webov národných bánk):

CZ: Kurzy devízového trhu (aktuálne dáta sú k dispozícii po 14:30 hod)

SK: Jednotlivé referenčné výmenné kurzy sú stanovované na základe telekonferencie medzi národnými centrálnymi bankami, ktorá sa zvyčajne koná o 14:15 SEČ

Pozn.3: V niektorých organizáciách používajú používateľskú zostavu Adm24f, ktorá pri svojom spustení vykoná tú istú funkčnosť ako Adm24 / Import z Webu. Zostavu potom majú umiestnenú na Adm53, aby sa spúšťala sama periodicky. Obvyklým problémom potom je, že zostava beží na aplikačnom serveri alebo na serveri EGJEWEB (2) a tento server teda musí mať prístup na internet resp. na aspoň vyššie uvedené adresy. Zabezpečenie prístupu je úlohou správcu v konkrétnej organizácii.

Treba si uvedomiť, že vyššie uvedené adresy sa jednak môžu meniť a tiež môžu iba presmerovávať na iné skutočné url adresy.

3.15 Adm25 – Export číselníkov

Na formulári Adm25, záložka Export pravidiel WFL sa dá nastaviť export rôznych WFL a ich pravidiel. Export sa robí výberom WFL v zozname na ľavej strane a pravidiel na pravej.

3.16 Adm26 – nastavenie šifrovania a SFTP

Na formulári Adm26 je možné nastaviť šifrovanie, SFTP konektivitu a komprimáciu súborov opatrenú šifrovaním. V prípade SFTP je možné využiť PGP šifrovanie.

3.16.1 Nastavenie SFTP prenosu

Po stlačení tlačidla „Nový“ sa musí najprv vybrať „Profil“. Ak je zvolený profil „SFTP“, bude sa pre prenos súborov využívať SFTP konektivita.

Následne je potrebné vyplniť názov profilu. Tento názov bude neskôr zobrazovaný pre výber na formulári Adm53, kde sa nastavuje automatické spustenie zostáv, ktoré budú definované SFTP spojenie využívať.

Pre SFTP spojenie sa vypĺňajú nasledovné údaje „SFTP“:

URL servera – obsahuje adresu servera, kde je SFTP
Port – číslo portu pre komunikáciu, ak sa nevyplní, použije sa port 22
Login – používateľské meno pre prihlásenie k SFTP
Metóda autentizácie – tu sa následne vyberá, či bude autentizácia heslom alebo certifikátom. Po výbere metódy sa zobrazia ďalšie polia, kde je možné zadať buď heslo alebo vybrať certifikát.

Heslo (podľa výberu metódy autentizácie) – heslo pre autentizáciu
Certifikát (podľa výberu metódy autentizácie) – certifikát je vygenerovaný SSH kľúč a importuje sa jeho privátna časť. EGJE nepodporuje kľúč vo formáte ppk (používa sa napríklad pre WinSCP), je potrebné naimportovať certifikáty typu DSA, RSA alebo ECDSA (iné nie sú podporované). Certifikát má dve voľby, buď s heslom alebo bez hesla (určuje sa pri generovaní).

Zložka na SFTP serveri – tu je možné nadefinovať adresár na vzdialenom úložisku, odkiaľ alebo kam sa má súbor odosielať alebo sťahovať.
Zložka na local/server – slúži pre definíciu adresára na lokálnom počítači alebo serveri

Povinné položky pre SFTP:

URL servera, Login, Metóda autentizácie, Heslo alebo Certifikát

Poznámka: Profil SFTP možno využívať bez šifrovania, iba pre prenosy súborov.

Po nadefinovaní všetkých údajov je potrebné daný profil uložiť. Týmto je dokončená definícia spojenia SFTP. Ak je potrebné daný súbor/y prenášať pomocou SFTP a ešte šifrovať či dešifrovať, je potrebné vyplniť údaje o šifrovaní v bloku „Šifra“.

3.16.2 Nastavenie šifrovania

Pri výbere profilu „Šifrovať/dešifrovať“ sa vypĺňajú údaje o šifrovaní, a to v závislosti od zvoleného typu:

· Typ šifrovania PGP

o Od – Do – do týchto položiek sa nastavuje platnosť šifrovacieho kľúča. Tieto položky sa automaticky vyplnia po stlačení tlačidla „Generuj kľúče“. Štandardná platnosť kľúča je od dátumu generovania po dobu dvoch rokov. Ak by však bolo požadované, skrátiť možnosť využitia kľúča napríklad na rok, je možné posunúť dátum „DO“ na danú hodnotu jedného roka. Táto možnosť zabezpečí, aby kľúč nebol využívaný po celý čas dvoch rokov. Pre kontrolu platnosti slúži OKO zostava Adm76 (nastavenie Adm76 ďalej v tomto dokumente). Ak by však boli dodané kľúče od poskytovateľa, je nutné doplniť dátumy „Od“ a „Do“ ručne. Tieto položky sú povinné a bez nich šifrovanie nebude funkčné.

o Identita – je možné zadať ľubovoľný text, pole sa využíva na určenie identity, ktorá šifruje daný prenos (väčšinou e-mail).

o Šifrovanie – RSA

o Heslo

o Generuj kľúče - tlačidlo slúži na vygenerovanie súkromného a verejného kľúča na šifrovanie a dešifrovanie

o Zašifruj súbor - tlačidlo slúži na overenie a možnosť daný súbor zašifrovať

o Dešifruj súbor - tlačidlo slúži na overenie a možnosť daný súbor dešifrovať

o Verejný kľúč klienta - tlačidlom “Nahraj” je možné uložiť verejný kľúč klienta, ak je poskytnutý

o Súkromný kľúč klienta - tlačidlom “Nahraj” je možné uložiť súkromný kľúč klienta, ak je poskytnutý

· Typ šifrovania – AES-256

o Od – Do – platnosť symetrickej šifry

o Mód symetrickej šifry: ECB, OFB alebo GCM

o Spôsob generovania SK: spôsob generovania secret key

o Heslo: položka editovateľná iba ak Spôsob generovania SK = 1 – Odvodenie z daného hesla. V prípade spôsobu 2 – Generovanie z náhodného čísla je položka needitovateľná a na tvorbu hesla je potrebné využiť tlačidlo Generuj heslo

o Generuj Iniciačný vektor – tlačidlo dostupné iba ak položka Spôsobu generovania SK = 2 – Generovanie z náhodného čísla

Nasledujúce 2 položky „Zdroj“ a „Cieľ“ v tejto chvíli nie sú potrebné a budú sa do budúcna odstraňovať. Po pridaní tlačidiel „Zašifruj súbor a „Dešifruj súbor“ tieto tlačidlá nahradili funkcionalitu polí. Cesta k súboru sa vyberá týmito tlačidlami.

Importné a exportné zostavy je potrebné pre SFTP a šifrovanie špecificky upraviť. V prípade záujmu kontaktujte helpdesk.

3.16.3 Záložka Šifra - ZIP

Táto záložka umožňuje definovať šifrovanie na ochranu ZIP archívu šifrou a heslom. Záložka je určená iba na nastavenie možnosti šifrovať archív a je tu možné vykonať iba výber šifrovania (ZipCrypto, AES-128, AES-256). Samotný proces šifrovania ZIP archívu sa spúšťa v rámci príslušného procesu (odosielanie ZIPovaného dokumentu na e-mail v rámci workflow obehu dokumentov rozšíreného o komponentu elektronického podpisu dokumentu).

Na aktiváciu šifrovania je potrebné založiť nový „Profil“ s názvom ZIP.

3.17 Adm27 – Evidencia certifikátov

Formulár Adm27 „Evidencia certifikátov“ je určený pre komplexnú správu všetkých digitálnych certifikátov – osobných aj systémových. Certifikáty sú tu evidované v základnej štruktúre certifikačného oprávnenia a naviazané certifikáty vydané. Certifikáty vydané (prvý vydaný certifikát a nadväzné obnovené certifikáty) evidujú najmä všetky náležitosti spojené s konkrétnym vydaným certifikátom. Certifikačné oprávnenie potom zastrešuje prvý vydaný certifikát a nadväzné certifikáty obnovené a je nositeľom informácií všeobecnej kategorizácie certifikátov a zároveň aj väzieb na ďalšie dátové objekty.

Navigácia: Zoznam Certifikačných oprávnení

Riadkové práva sú aplikované v dvoch režimoch: Profil s plnými oprávneniami má prístup ku všetkým záznamom certifikátov, teda ku certifikátom viazaným na Org/SJ, aj k neviazaným. Profil aplikujúci priradenie používateľa k ORG/SJ sprístupňuje používateľovi tie záznamy na Adm27, ktoré sú priradené k ORG/SJ, ku ktorým má profil prístup, a záznamy nepriradené k ORG/SJ.

Záložka Certifikačné oprávnenie

Záložka obsahuje informácie slúžiace:

- k základnej kategorizácii certifikačného oprávnenia pomocou setu kategórií, ktoré umožňujú vybrať certifikát zodpovedajúci požiadavkám daného procesu

- na nastavenie väzieb na ďalšie evidované objekty využívané v rámci procesov EGJE. Ide najmä o väzbu na držiteľa. Certifikáty vydané na organizácii a/alebo jej pracovníka sú priradené k organizačnej štruktúre (Organizácia, Správna jednotka) a osobe, certifikáty tretích strán (orgány verejnej moci, ďalej OVM) potom majú väzbu na evidenciu externých organizácií (úrady, zdravotné poisťovne atď.)

Atribúty certifikačného oprávnenia

- Názov certifikátu: v rámci importu sa predvyplnia vybrané identifikačné údaje držiteľa certifikátu, užívateľ môže upraviť

- Popis: zadané užívateľom

- Typ certifikátu: v rámci importu sa podľa vybraných parametrov certifikátov predvyplní typ. Pokiaľ by sa z dostupných dát certifikátu v rámci importu nepodarilo certifikát kategorizovať vôbec alebo by došlo k nepresnej kategorizácii, užívateľ môže editovať. Základné typy:

o Osobný: certifikát vydaný konkrétnej fyzickej osobe

o Osobný pre organizáciu: certifikát vydaný konkrétnej fyzickej osobe a organizácii (typicky zamestnávateľ vyhotoví podpisové certifikáty pre svojich pracovníkov, ktorí certifikátom podpisujú firemnú komunikáciu, doklady)

o Systémový – značka: certifikát vydaný organizácii

o Serverový (technologický): je určený predovšetkým pre vzájomnú zabezpečenú komunikáciu serverov.

- Úroveň dôvery

o Kvalifikovaná – certifikát vydaný akreditovanou kvalifikovanou certifikačnou autoritou na kvalifikovanom prostriedku

o Uznávaná – certifikát vydaný akreditovanou kvalifikovanou certifikačnou autoritou na nekvalifikovanom prostriedku. Pri importe certifikátu vystaveným kvalifikovanou certifikačnou autoritou sa vstupne nastavuje táto úroveň dôvery. Pokiaľ ide o certifikát na kvalifikovanom prostriedku, potom editovať na úroveň Kvalifikovaná.

o Zaručená – certifikát vydaný neakreditovanou (komerčnou) certifikačnou autoritou

- Druh kľúča

o Verejný – k certifikátu evidujeme iba časť verejného kľúča, ide najmä o certifikáty tretích strán

o Súkromný – certifikát obsahuje verejný aj privátny kľúč

- Organizácia, Správna jednotka: pokiaľ je držiteľom certifikátu správna jednotka, evidujeme väzbu na organizačnú štruktúru firmy (Organizácia, SJ)

- Osoba: Ak je držiteľom zamestnanec, evidujeme väzbu na osobu

- Organizácia 3.strany: pokiaľ je certifikát vystavený na externý subjekt, potom nadviažeme na organizáciu evidovanú v rámci číselníka Externých subjektov (Adm28)

- Platnosť záznamu od: dátum založenia certifikačného oprávnenia

- Platnosť záznamov do: pri importe certifikátu je načítaná platnosť importovaného certifikátu vydaného, je možné editovať užívateľom (napr. ak je s pracovníkom ukončený pracovný pomer)

- Dátum revokácie: pokiaľ došlo k revokácii aktuálne platného certifikátu vydaného, potom evidujeme dátum a čas zneplatnenia

Na záložke sú dostupné akcie na načítanie certifikátov

- Akcia Vyberte certifikát zo súboru

- Akcia Vyberte certifikát zo systémového úložiska – táto akcia je určená na načítanie kvalifikovaného certifikátu zo systémového úložiska Windows Keystore

Pokiaľ evidujeme prvý certifikát, potom založíme nové certifikačné oprávnenie a načítame vydaný certifikát pomocou akcie Vyberte certifikát zo súboru/ Vyberte certifikát zo systémového úložiska. Týmto dôjde k predvyplneniu vybraných atribútov certifikačného oprávnenia a pod dané certifikačné oprávnenie sa na záložku Certifikáty vydané založí prvý záznam certifikátu vydaného.

Pokiaľ evidujeme k danému certifikačnému oprávneniu obnovený certifikát, potom pod dané certifikačné oprávnenie založíme nový záznam certifikátu vydaného.

V rámci ďalšej špecifikácie certifikačného oprávnenia potom na jednotlivých podzáložkách certifikačného oprávnenia môžeme evidovať účely použitia a priradenia certifikátu k API.

Záložka Účely použitia

Záložka eviduje použitie certifikátov (pre aké účely bol certifikát vystavený). Vychádza sa zo špecifikácie certifikátu uvedeného v rámci Použitie kľúča (Key usage) a Použitie rozšíreného kľúča (Extended key usage).

Záložka Priradenie k API

Pokiaľ je certifikát určený pre zabezpečenie komunikácie s treťou stranou prostredníctvom API, potom na záložke Priradenie API evidujeme väzbu príslušného certifikátu k danému API (definovanému na Adm55)

Záložka Certifikáty vydané

Na záložke „Certifikáty vydané“ sú evidované jednotlivé vydané certifikáty, teda prvý vydaný a nadväzné obnovené certifikáty. Väčšina informácií tu evidovaných je načítaná priamo zo súboru certifikátu a nie je editovateľná užívateľom. Ide o tieto oblasti dát

- identifikačné údaje certifikátu – sériové číslo certifikátu

- certifikačná autorita, ktorá certifikát vydala

- identifikácia držiteľa certifikátu

- platnosť certifikátu

- informácie k miestu uloženia certifikátu pre využitie v rámci systému EGJE (databáza, Windows Keystore)

- informácie k hierarchii certifikátu: či ide o koncový certifikát a úroveň hierarchie certifikátu

Záložka Registrácia certifikátu

Pokiaľ ide o certifikáty vydané zamestnancom organizácie komunikujúce s OVM elektronicky, potom tieto certifikáty podliehajú registrácii splnomocnenia na týchto úradoch. OVM si k týmto certifikátom registrujem splnomocnenie pre firmy, ktoré má pracovník s daným certifikátom oprávnenie zastupovať v elektronickej komunikácii s úradom (napr. spracováva a podpisuje e-Podanie). K vydaným certifikátom tak môžeme na podzáložke „Registrácia certifikátu“ evidovať OVM, pri ktorých bol certifikát zaregistrovaný a na záložke „Zmocnenie“ potom evidujeme pre aké SJ bolo splnomocnenie na OVM registrované. Pokiaľ je v rámci vybraných procesov požadované vyhodnocovať pri výbere certifikátu, či je daný certifikát registrovaný u OVM, potom sa zohľadní toto nastavenie.

Základné procesy

Evidencia prvého vydaného certifikátu

Pokiaľ evidujeme prvý vydaný certifikát daného typu a daného držiteľa, potom postupujeme následne:

- Založíme nové Certifikačné oprávnenie

- Spustíme akciu na načítanie certifikátu: Vyberte certifikát zo súboru alebo Vyberte certifikát zo systémového úložiska

- EGJE načíta dáta z certifikátu a týmito dátami potom

o Aktualizuje vybrané atribúty na Certifikačnom oprávnení

o Načíta Účely použitia k Certifikačnému oprávneniu

o Založí nový Certifikát vydaný av rámci neho všetky parametre, ktorých údaje je možné z certifikátu načítať

- Užívateľ eviduje na Certifikačnom oprávnení ďalšie náležitosti podľa typu certifikátu, ktorý je evidovaný

o Upraví Názov, pokiaľ názov vytvorený na základe dát z certifikátu chce zmeniť

o Doplní Popis

o Pokiaľ ide o certifikát, ktorého držiteľom je organizácia (správna jednotka) a/alebo zamestnanec zadá Organizáciu, SJ av prípade osobných certifikátov aj Osobu, na ktorej je certifikát vystavený

o Pokiaľ ide o certifikát organizácie tretích strán (OVM), potom zadá väzbu na číselník v rámci poľa Organizácia 3.strany

o Zreviduje predvyplnenú kategorizáciu Certifikačného oprávnenia: Typ certifikátu, Druh kľúča, Druh certifikátu, Úroveň dôveryhodnosti

- Užívateľ prejde na záložku Certifikáty vydané a na novo založenom zázname Certifikátu vydaného upraví Názov, pokiaľ názov vytvorený na základe dát načítaných z certifikátu chce zmeniť, prípadne zreviduje ďalšie predvyplnené hodnoty v editačnom móde

- Pokiaľ ide o certifikát registrovaný u OVM, potom na záložke Registrácia certifikátu zadá OVM, u ktorých prebehla registrácia certifikátu a na záložke Splnomocnenie zaeviduje SJ, pre ktoré bolo k certifikátu nahlásené OVM splnomocnenie

Evidencia obnoveného certifikátu

Certifikáty sú vydávané pre definované obdobie platnosti (napr. pri osobných certifikátoch ide spravidla o 1 rok alebo 3 roky). Pokiaľ chceme platnosť certifikátu predĺžiť, potom je nutné pred vypršaním platnosti existujúceho certifikátu požiadať CA o obnovenie certifikátu.

V prípade evidencie obnoveného certifikátu v EGJE postupujeme následne

- Prejdeme na záznam Certifikačného oprávnenia, u ktorého došlo k obnoveniu aktuálne platného certifikátu

- Prejdeme na záložku Certifikáty vydané a cez akciu Nový založíme nový záznam Certifikátu vydaného

o Podľa miesta uloženia certifikátu načítame certifikát pomocou akcie Vyberte certifikát zo súboru alebo Vyberte certifikát zo systémového úložiska

o EGJE načíta dáta z certifikátu a týmito dátami potom aktualizuje Certifikát vydaný a vybrané údaje Certifikačného oprávnenia (Platnosť do)

o Užívateľ môže upraviť Názov, pokiaľ názov vytvorený na základe dát načítaných z certifikátu chce zmeniť, prípadne zreviduje ďalšie predvyplnené hodnoty v editačnom móde

Revokácia certifikátu

Pokiaľ dôjde k udalosti, ktorá vedie k revokácii platného certifikátu (napr. strata nosiča s certifikátom), potom je potrebné požiadať o zneplatnenie certifikátu vydávajúceho CA.

V rámci EGJE nadväzne nastavíte na Certifikačnom oprávnení Dátum revokácie.

Pri vydaní nového certifikátu potom zakladáme nové Certifikačné oprávnenie.

3.18 Adm28 – Externé organizácie

Formulár Adm28 „Externá organizácia“ slúži na správu základných identifikačných a kontaktných informácií k subjektom tretích strán. S ohľadom na implementované procesy EGJE ide o evidenciu orgánov verejnej moci (OVM) na účely e-Podania. Formulár obsahuje dve základné evidenčné oblasti týchto subjektov

- Všeobecný číselník externých organizácií – záložka Externej organizácie

- Štruktúru pobočiek organizácie – záložka Štruktúra pobočiek

Záložka Externá organizácia

Evidujeme tu základné identifikačné a klasifikačné parametre externého subjektu:

- Skratka názvu: skratka pre označenie organizácie

- Názov: názov organizácie

- Typ organizácie: Štátna správa/Zdravotné poisťovne/…..

- Zdravotná poisťovňa: pokiaľ evidovaným subjektom je ZP, potom previažeme na číselník ZP

- Externé ID organizácie: ide o Identifikátor OVM

- Vlastník: ak je záznam založený Elanor a.s., potom = E, ak je záznam založený užívateľom, potom = U.

- Legislatíva - určuje, pre akú legislatívu je organizácia určená

Oblasť dát Registrácia certifikátu

Táto časť sa týka oblasti registrácie certifikátov v OVM. Certifikáty vydané pre firmu/zamestnanca určené na komunikáciu s daným OVM môžu podliehať procesom registrácie a splnomocnenia. Aktuálne prebieha registrácia na jednotlivých OVM samostatne, do budúcnosti sa predpokladá evidencia na jednom centrálnom mieste. V rámci evidencie Externých organizácií tak je umožnené nastaviť:

- Subjekt, ktorý je centrálnym registrom certifikátov pre iné OVM, bude mať nastavený Centrálny register certifikátu = Áno

- Subjekt, ktorý bude využívať centrálny register, bude mať nastavený parameter Napojenie na centrálny register certifikátov = organizáciu zaisťujúcu funkciu centrálneho registra

V rámci procesu výberu certifikátu pre spracovanie dát v rámci príslušného e-Podania v EGJE, môže byť nastavené, aby sa overovalo registrácia splnomocnenia k certifikátu pre príslušnú SJ, za ktorú sú dáta spracovávané. Pokiaľ je požadované, aby sa táto kontrola pri komunikácii s daným OVM aplikovala, potom Kontrola splnomocnenia k certifikátu = Áno. Kontrola sa vykonáva voči evidencii Registrácií a ich Splnomocnenia evidovaných na certifikáte (Adm27)

Záložka Štruktúra pobočiek

V rámci Štruktúry pobočiek je možné evidovať štruktúru pobočiek daného subjektu (OVM) a kontaktné informácie k jednotlivým pobočkám. Záznamy sú pre používateľa odfiltrované podľa nastavenia legislatívy na externej organizácii.

Detail pobočky

Pokiaľ zakladáme prvú úroveň štruktúry (koreň stromu), potom novú položku zakladáme pomocou akcie Nová koreňová pobočka. Pokiaľ zakladáme podriadenú pobočku, potom v strome označíme uzol, pod ktorý chceme vložiť podriadenú pobočku a zvolíme akciu Nová podriadená pobočka.

- Úroveň štruktúry: založí sa automaticky

- Externá organizácia: v prípade založenia koreňa stromu zadáme väzbu na všeobecný číselník externých organizácií, pri podriadených pobočkách sa externá organizácia preberá z koreňovej položky.

- Názov: vložíme názov pobočky

- Skratka názvu: skratka pre označenie pobočky

- Číslo okresu ČSSZ: pokiaľ evidujeme štruktúru ČSSZ, potom môžeme previazať na číselník okresov ČSSZ

- Externé ID organizácie: ide o Identifikátor OVM

- Platnosť od

- Platnosť do

Dáta pre OVM, pre ktoré sú v rámci EGJE implementované e-Podanie, sú v databáze na centrálnej úrovni štruktúry OVM spravované Elanor a.s.

3.19 Adm31 – Konfigurácia používateľských položiek

Formulárom sa dajú nastaviť názvy používateľských položiek použitých na formulároch :

· Osb01, Osb02

· Opv01

· Pmi01

· Pro01

a to vždy v záložke používateľské údaje.

Pre editáciu je prístupná trojica nadpisov. Kľúčový je ten druhý, ktorý je použitý v záložke formulára.

Pokiaľ je pri položke uvedený odkaz na jednopoložkový číselník, je možné tento číselník editovať vo formulári Jpc01 (viď EGJE_úvod).

Formulár tiež umožňuje nastaviť použitie či nepoužitie číselníkov pre

· titul pred menom a za menom. Implicitný je doterajší stav - nepoužitie titulov. Pri použití titulov je tieto nutné vyplniť do Jpc01 - číselníky a_titul, v_titul - vypĺňajte stĺpce hodnota a Kód. V stĺpci hodnota ľubovoľnú číselnú radu, v stĺpci Kód potom celý titul, stĺpec názov ponechávajte prázdny.Oba režimy sú dátovo kompatibilné - tj. už priradené tituly zostávajú zachované.

· PSČ. Pri použití číselníka je potrebné mať vyplnený číselník na formulári Psc01. Oba režimy sú dátovo kompatibilné - tj už priradené tituly zostávajú zachované. Upozornenie - použitie číselníku PSČ spomaľuje načítanie formulárov, kde je PSČ použité. Týka sa to zobrazenia PSČ v osobných adresách, adresách SJ, SO, PM, akciách.

· pracovné miesta na formulároch Pmi01 a Opv01.Při použitie číselníku je potrebné vyplniť číselník pracovných miest na f Pmi06. Oba režimy sú dátovo kompatibilné - tj už priradená pracovné miesta zostávajú zachované.

Upozornenie - po prestavení režimu titulov, pracovných miest a PSČ je vhodné klientskú aplikáciu uzatvoriť a znova otvoriť, aby sa zmena premietla do všetkých ich častí, resp. reštartovať AS či Web aplikáciu (Tomcat) pri použití týchto komponent.

"Ďalšie konfigurácie" / Multiorganizácia

Nastavenia, keď osobné číslo PV je unikátne len v rámci organizácie a nie v rámci celej databázy je určené iba pre multiorganizační databázy Elanor Outsourcing.

Rovnako tak je tomu u unikátnosti kódov štruktúr.

Záložka „Doch.-číselníky“

Umožňuje na formulári „Kal01, Dochádzka“ a „Dcd01, Vstupy, Detail“ používateľsky upraviť názov nepomenovaných príplatkov.

3.20 Adm32 - Konfigurácia hlásenia výpočtu

Obsahuje zoznam hlásení použitých v jednotlivých oblastiach a umožňuje jemné nastavenie hlášok, ktoré majú možnosť úpravy úrovne hlásenia zo strany zákazníka.

Formulár je rozčlenený do troch záložiek, pričom každá záložka je rozdelená na dve podzáložky.

podzáložka Užívateľské nastavenie

obsahuje zoznam hlásení, ktoré si užívateľ definoval pre použitie pre danú oblasť s obsahom

Kód - kód a text hlásenia

Úroveň - užívateľom nastavená úroveň hlásenia

podzáložka Štandardné nastavenie - obsahuje plný zoznam používaných hlásenia, pre danú oblasť s obsahom:

Kód - kód a text hlásenia

Štandardná úroveň - štandardná úroveň hlásenia

Užívateľská úroveň - užívateľom nastavená úroveň hlásenia

Jednotlivé hlásenia sa zobrazujú farebne podľa úrovne hlásenia. Pre hlásenie s užívateľom nastavenou úrovňou, je farba zobrazenia stanovená podľa užívateľskej úrovne.

Použité farbenie je rovnaké ako použité pre zobrazenie protokolov na Vyp01.

Záložka „Výpočet miezd“

Umožňuje jemné nastavenie hlásenia výpočtu mzdy - nastavením úrovne hlásenia sa dá určiť, ktoré hlásenie výpočet ukončí a ktoré nie.

Každé hlásenie má svoju „úroveň“, tj. jednu z nasledujúcich hodnôt (viď tiež Jpc01, číselník urov_chyby):

0 nie je chyba, sprievodné či prevádzkové hlásenie (napr. zahájenie výpočtu),

1 informácia … informácia pre používateľa,

2 varovanie … varovná informácia pre používateľa; chyba nízkej úrovne,

3 chyba … chyba strednej až vyššej úrovne, ktorej existencia však umožňuje dokončenie výpočtu mzdy zamestnanca,

4 fatálna chyba … chyba vysokej úrovne, ktorej existencia neumožňuje dokončenie výpočtu mzdy zamestnanca.

V praxi je však mnohokrát ťažké rozhodnúť, či vzniknutá situácia je informáciou, bežnou chybou či chybou závažnou či dokonca fatálnou. Autori výpočtového programu tak konajú podľa svojho posúdenia danou praxou a prípadne pripomienkami väčšiny používateľov. Aj tak môže dôjsť k tomu, že niektorý zákazník má svoje zvyky a potreby a úroveň hlásenia mu nevyhovuje.

Úroveň hlásenia je viazaná na kód hlásenia. Ten je súčasťou textu správy výpočtu a to ako jeho prvá časť. Napríklad z hlásenia:

„VYP550 Daňové zvýhodnenie na dieťa …“

sa za kód hlásenia považuje „VYP550“. Text hlásenia je možné vidieť na textových protokoloch z výpočtu alebo na formulári Vyp01, záložka Protokol. Je tiež novo vidieť z kontextovej nápovedy formulára Adm32 či ako súčasť používateľskej príručky.

Do formulára používateľ, ktorý k tomu dostane prístupové práva, jednoduchou formou zadáva tie hlásenia, ktorých úroveň chce zmeniť. Zadáva sa:

kód hlásenia …prostá textová položka (napr. VYP550), nápoveda kontextová,

úroveň hlásenia … zvolená iná úroveň než je štandard (číselník urov_chyby).

Pre hlásenia, ktoré nemajú zaevidovanú odchylnú úroveň, zostáva štandardná úroveň podľa autorov výpočtového programu.

Táto vlastnosť nie je však možná pre tie hlásenia, ktoré sú z hľadiska riešiteľov označené ako fatálna chyba, tj. zmeniť úroveň takého hlásenia nie je možné. Pri fatálnej chybe totiž nemá zmysel pokračovať vo výpočte a ten tým končí.

Naopak však je možné preradiť hlásenie s úrovňou menšou ako fatálna na úroveň fatálnej. Tým je možné dosiahnuť to, že výpočet mzdy zamestnanca pri situácii hlásenej týmto hlásením je súčasne so správou ukončený. Je možné to napríklad využiť pri riešení situácie zadaní náhrady pri dočasnej pracovnej neschopnosti na viac ako 14 dní (21 dní od 1.1.2011) (pre CZ). Štandardná úroveň je chyba a výpočet pokračuje. Pri prestavení na fatálnu chybu však výpočet končí.

Prenastavenie úrovne hlásení na hodnotu 0 spôsobí to, že sa hlásenie nevytvára.

Záložka „Dochádzka“ a „Dochádzka a výkony“

Umožňuje používateľskú modifikáciu štandardne stanovenej úrovne hlásenia pre dodávateľom stanovený zoznam hlásení z oblastí Dochádzka/Dochádzka a výkony.

Princípy použitia a obsluha je rovnaká ako na záložke „Výpočet miezd“ s výnimkou, že používateľ má k dispozícii zoznam hlásení, pri ktorých je možné zmeniť úroveň.

Podrobnejší popis viď Doch_dopl_uzdoc, kapitolu Adm32.

3.21 Adm33 - Konfigurácia textov (pozvánky, kalendár ...)

Formulár slúži na evidenciu a zadávanie predlôh e-mailových oznámeniach používaných v Kva06, Adm53 a iných objektoch.

Umožňuje v hlavičke vybrať editor pre oznámenia:

Textový editor - štandardný "bezproblémový"

HTML editor - závisí od klienta JAVA/WEB2 (v prípade java klienta aj od verzie JRE)

obsahuje obmedzenú podmnožinu html, môžu byť problémy aj s veľkosťou fontov alebo vloženou grafikou - všetko treba vyskúšať - nemôžeme garantovať kompletnú html kompatibilitu,

Obsahuje tlačidlá:

· Generovanie všetkých krokov - zobrazí dialóg pre výber organizácie a akcie workflow, po odsúhlasení vytvorí kroky so všetkými statusy daného workflow okrem statusu 0. Ten sa typicky používa ako predvolené status. Nenastavujú sa príjemcovia ani predloha oznámenia.

· Kópia vrátane krokov - zobrazí sa dialóg pre výber organizácie prípadne výber akcie workflow, po odsúhlasení vytvoria kópií nové kroky workflow a nastaví im organizáciu a akciu z parametrov v dialógu.

· Nastavenie organizácie všetkým krokom - zobrazí dialóg pre výber organizácie, po odsúhlasení pre vybratý krok workflow nájde všetky kroky s rovnakou akciou workflow a organizáciou a zmení im organizáciu na organizáciu z parametra v dialógu.

3.21.1 Podporované work flow

WF 5 Pozvánka na vzdelávaciu akciu

Pozvánky sú odoslané z Kva06 / Účastníci / Odoslať pozvánky

Pozn. Konečný status 1.

Okrem štandardných príjemcov, účastníkov akcie, umožňuje zadať pravidlá pre ďalších príjemcov pozvánky.

WF 6 Správa o nedosiahnutí min. počtu na vzdel. akcii

Úloha Adm53, kde je také popísaná.

WF 7 Správa o odhláseniu zo vzdelávacej akcie

Správa o odhlásení zamestnanca zo vzdelávacej akcie má tieto podtypy:

1 - Odhlásenie z akcie zamestnancom - volanie z Kva15

2 - Odhlásenie z akcie manažérom - volanie z Kva03

3 - Odhlásenie z akcie referentom - volanie z Kva06 - tlačidlom Zmazať účastníka + Poslať oznámenie. Alternatívou je zmazanie štandardným tlačidlom, kedy e-mail neodchádza.

Pozn. V Kva06.mts je tu ešte otázka na dôvod. V Kva06.allsk sa odosiela oznámenie vždy aj pri štandardnom mazaní.

WF 8 Správa o exspirácii periód. spôsobilosti

Úloha Adm53, kde je také popísaná.

WF 9 Pozvánka na lekársku prehliadku

Pozvánky sú odosielané z Kva05f / Zaradenie na prehliadku / Odoslať pozvánku

Pozn. Konečný štatút 1.

Okrem štandardných príjemcov, účastníkov akcie, umožňuje zadať pravidlá pre ďalších príjemcov pozvánky.

WF 56 Správy o zmene zbrojného preukazu (zákazník CZUB)

Konfigurácia mailových notifikácií v rámci formulárov Pkz21, Pkz23. Je potrebné nastaviť pre všetky typy statusov personálnych zmien:

1 – Zamietnuté, stornované

10 – Odoslaná

30 – Schválené a premietnuté do Personálnych údajov

WF 57 Správy o zmenách zrážky

Konfigurácia mailových notifikácií v rámci formulárov Sra21, Sra23. Je potrebné nastaviť pre všetky typy statusov zmien zrážok:

1 – Zamietnuté, stornované

10 – Odoslané na revíziu ban. cesty

20 – Schválené MÚ

30 – Schválené a premietnuté do zrážok

WF 58 Správy o zmenách pers. údajov

Konfigurácia mailových notifikácií v rámci formulárov Pkz21, Pkz23. Je potrebné nastaviť pre všetky typy statusov personálnych zmien:

1 – Zamietnuté, stornované

10 – Odoslaná

30 – Schválené a premietnuté do Personálnych údajov

WF 61 vyhlásenie poplatníka CZ

Konfigurácia mailových notifikácií v rámci elektronickej daňovky CZ. Je potrebné nastaviť pre všetky typy statusov vyhlásenie:

10 – Odoslané MÚ

11 – Odoslaná oprava

12 – Vrátený na doplnenie/opravu

14 – Zmeny zamietnuté

20 – Schválene MÚ

30 – Premietnuté do Dan01

WF 57 Zprávy o změnách srážky

Konfigurace mailových notifikací v rámci formulářů Sra21, Sra23. Je třeba nastavit pro všechny typy statusů změn srážek:

1 – Zamítnuto, stornováno

10 – Odesláno k revizi ban. cesty

20 – Schváleno MÚ

30 – Schváleno a promítnuto do srážek

WF 58 Zprávy o změnách pers. údajů

Konfigurace mailových notifikací v rámci formulářů Pkz21, Pkz23. Je třeba nastavit pro všechny typy statusů personálních změn:

1 – Zamítnuto, stornováno

10 – Odeslána

30 – Schváleno a promítnuto do Personálních dat

WF 62 Ročné zúčtovanie dane CZ

Konfigurácia mailových notifikácií v rámci elektronickej daňovky CZ. Je potrebné nastaviť pre všetky typy statusov žiadosti o ročné zúčtovanie dane:

10 – Odoslané MÚ

11 – Odoslaná oprava

12 – Vrátený na doplnenie/opravu

14 – Zmeny zamietnuté

16 – Žiadosť o potvrdení príjmu

18 – Potvrdení príjmu vystavené

20 – Schválene MÚ

30 – Premietnuté do Dan01

WF 63 Žiadosti o dokument

Workflow slúži správcovi na nastavenie pravidiel príjemcov notifikácií (ak nie je nastavené na Adm62) a sprievodných textov notifikácií v e-maile v rámci samostatného okruhu Dokumenty zamestnanca.

1 - Storno

10 - Žiadosť

14 - Zamietnuté žiadosť

18 - Vybavenie žiadosti

WF 64 Vystavenie dokumentu bez žiadosti

23 - Bez žiadosti

(Makrá pre text notifikácií WFL 63 a 64 sú uvedené v dokumentácii Zam_dok_uzdoc)

WF 65 Vyhlásenie poplatníka SK

Konfigurácia mailových notifikácií v rámci elektronickej daňovky SK. Je potrebné nastaviť pre všetky typy statusov vyhlásení:

1 - Storno

10 – Odoslané MÚ

11 – Odoslaná oprava

12 – Vrátené na doplnenie/opravu

13 – Vzaté späť na opravu/doplnenie

14 – Zmeny zamietnuté

15 – Požiadané o vrátenie na opravu/doplnenie

20 – Schválené MÚ

21 – Opätovné schválené MÚ

30 – Premietnuté do Das01

40 – Spracované ručne MÚ

98 – Avízo-nový nástup

WF 66 Ročné zúčtovanie dane SK

Konfigurácia mailových notifikácií v rámci elektronickej daňovky SK. Je potrebné nastaviť pre všetky typy statusov žiadosti o ročné zúčtovanie dane:

10 – Odoslané MÚ

11 – Odoslaná oprava

12 – Vrátené na doplnenie/opravu

13 – Vzaté späť na opravu/doplnenie

14 – Zmeny zamietnuté

15 – Požiadané o vrátenie na opravu/doplnenie

16 – Žiadosť o potvrdenie príjmov

18 – Potvrdenie príjmov vystavené

20 – Schválené MÚ

21 – Opätovné schválené MÚ

25 - Žiadosť o RZD anulovaná zamestnancom

26 - Zamestnanec požiadal o anuláciu žiadosti

27 - Anulácia žiadosti o RZD schválená MÚ

30 – Premietnuté do Das01

40 – Spracované ručne MÚ

96 - Vrátenie anulácie (zam.)

97 - Zamietnutie anulácie (MÚ)

WF 67 Končiace daňové zľavy

Konfigurácia emailových notifikácií na končiace daňové zľavy. Je nutné nadefinovať pre všetky konečné statusy (spojené s Adm58 a Kon07).

1 – Avízo - 1. upozornenie

2 – Avízo – 2. upozornenie

3 – Avízo – 3. upozornenie

4 – Avízo – Mzdové účtovníčky

WF 68 Notifikácia pri odoslaní internej pošty

Toto workflow slúži na odosielanie notifikácie na email typu o tom, že došla správa internou poštou ako

Workflow je potrebné založiť s parametrami:

• Odosielať správy z workflow = Áno

• Zaslať e-mail prim. príjemcu ext. = Áno

• Primárny typ e-mailu = 31

• Čísla pravidiel nie je nutné vyplňovať

Pre toto WFL je možné do záložky „Predloha oznámenia“ vložiť makro %MSG_TEXT%, ktoré skopíruje text správy z formulára Mail  záložka „Nová správa“  text správy

WF 69 Registračný e-mail (iba interné WFL)
Tento workflow slúži na odosielanie registračného e-mailu z EGJE do ESP z formulára Adm12 v súvislosti s vygenerovanými prístupmi a heslami externých používateľov AD Elanoru. Súčasťou tohto WFL budou aj nová makra %REGISTRACE_URL% a %REGISTRACE_LOGNAME%
Podrobný popis nájdete v dokumentácii EGJE_distribuciaHesielASPklientom.

WF 70 Expirácia hesla
Tento workflow slúži na odosielanie notifikácie na e-mail s informáciou, že dôjde k expirácii hesla zadaného na formulári (napr. Adm57 alebo Xpw02/03). Počet dní pre upozornenie na expiráciu hesla musí byť nastavený v Adm70 s väzbou na konkrétny formulár. Ďalej je potrebné nastaviť Adm53 s jobom 70, ktorý výpočet podľa konfigurácie a dátumu expirácie hesiel spočíta a pomocou tohto workflow odošle informácie definovanému používateľovi.
Súčasťou WFL 70 by mala byť Predloha oznámenia v tomto formáte:

Tabuľka: %TABLE_NAME%, ID záznamu: %ID_RADKU%, identifikácia: %IDENTIF%, dátum vzniku: %PASS_DATUM_VZNIKU%, dátum expirácie: %DATUM_EXPIRACE%

(podrobnejšie pozri Makra)

WF 77 Notifikácia o uvoľnení VL

Tento workflow slúži na zaslanie notifikácie týkajúcej sa uvoľnenia VL v systéme. Celá funkcionalita sa spúšťa z formulára Vyp02, zo záložky „Uzávierka“. Existujú 2 možnosti, kedy je možné túto notifikáciu odoslať. Buď tlačidlom „Uzavreté – sprístupniť VL zamestnancom“. Toto tlačidlo sa zobrazuje v statusu 4 výplatného termínu (Status VT = 4).
Druhou možnosťou je tlačidlo „Odoslať notifikáciu o uvoľnení VL“, ktoré sa zobrazuje v statusu 6 výplatného termínu (status VT = 6).
Na WFL je potrebné nastaviť „Názov workflow“, akciu workflow, konečný status, nastaviť primárny typ e-mailu (30, 31, 32, 33) a označiť, že sa majú odosielať správy z workflow (Áno).

WF 78 - Oznámenie zamestnávateľovi o potrebe OSE/DLO/PPM/OPP

Tento workflow slúži na komunikáciu zamestnanca s mzdovou účtárňou (mzdovou účtovníčkou) v prípade vyplnenia zamestnancom (Poj71) Oznámenia zamestnávateľovi o potrebe OSE /DLO/PPM/OPP.

WF 90 Neschvaľovaná ZLM do ICALL

Pre WFL sa zobrazuje záložka iCalendar.

Workflow je určené pre potreby prenosu informácie o neschvaľované odchýlke z Dcu06 do kalendára typu Outlook / LN a iných podporovaných.

WFL negeneruje žiadne notifikačné správy pre užívateľov ani iných adresátov, nedochádza k žiadnych akciám užívateľov v rámci WFL. Slúži iba na zaslanie správy do ICALL pre zobrazenie / zrušenie odchýlky (predovšetkým OUTLOOK).

Pre WFL sú definované 2 kroky:

a / zapísanie správy do ICALL

konečný stav 23 (Zobrazenie v Kalendári) + vygenerovanie správy do ICALL

b / zrušenie správy z ICALL

konečný stav 2 (Zrušenie z Kalendára) + vygenerovanie zrušenia správy do ICALL

WF 91 Nepodarilo sa odoslať súbor do DMS

Workflow je určené pre odoslanie správy o neúspešnom prenose súboru do DMS zo zostavy Dms01fkb.

WF 95 - Notifikačné zostavy DOCH/DAV - notifikačné správy

WFL je určené pre definíciu a prípadnú modifikáciu notifikačných správ z notifikačných zostáv z oblasti DOCH/DAV.

Podrobnejší popis viď v Doch_uzdoc, kapitola Notifikačnej zostavy DOCH, napojenie na Adm33.

WF 250 – Notifikačný e-mail s overovacím URL odkazom

Táto akcia workflow slúži pre odosielanie overovacieho URL pri zmene e-mailovej adresy

WF 500 – Odosielanie akceptovaných dokumentov na e-mail zamestnanca

Táto úloha workflow slúži na odosielanie akceptovaných dokumentov na e-mail zamestnanca. Táto úloha je viazaná na funkcionalitu elektronických podpisov implementovanú v rámci workflow 301-399.

Pri založení záznamu úlohy pre wfl_akcie = 500 sa vstupne nastaví atribút Režim odoslania zástupcovi = 0 – Neodosielať.

3.21.2 Elektronické podpisy v rámci workflow Vyhlásenie poplatníka a RZD

V oblasti e-Daňovka sú dve zásadné workflow:

workflow „Vyhlásenie poplatníka“ realizované postupnosťou krokov na Dan 31->33->34 resp. Das 31->33->34

Dan/Das 31:

Výstupom použitia týchto formulárov zamestnancom je „Vyhlásenie poplatníka“.
Používateľ, t.j. zamestnanec, dnes vyplnením checkboxu potvrdzuje pravdivosť údajov na vyššie spomenutom vyhlásení.

Dan/Das33:

Vybrané položky z „Vyhlásenia poplatníka“ sú ďalej zobrazené na Dan33/Das33 mzdovej účtovníčke (MÚ), ktorá overuje zamestnancom vložené dáta.
Používateľ (v tomto prípade MÚ) dnes vyplnením checkboxu potvrdzuje pravdivosť zobrazených údajov.

Dan/Das34:

Tlač „Vyhlásenie poplatníka“ schváleného MÚ sa vykonáva cez Dan34/Das34.

workflow „Žiadosť o RZD“ a „Žiadosť o vystavenie potvrdenia o zdaniteľných príjmoch“ realizované postupnosťou krokov na Dan 32->36->37 a Das 32->36->37

Dan/Das32:

Výstupom použitia týchto formulárov zamestnancom je „Žiadosť o RZD“ alebo „Žiadosť o vystavenie potvrdenia o zdaniteľných príjmoch“.

Dan/Das 36:

MÚ na týchto formulároch:

vystavuje/tlačí “Potvrdenie o zdaniteľných príjmoch ”

spracováva ročné zúčtování daní

Dan/Das 37:

MÚ na týchto formulároch tlačí opis zamestnancovej „Žiadosti o RZD“

Niektorí zákazníci si však prajú namiesto zaškrtnutia checkboxu na vyššie spomenutých formulároch pripojiť k akcii schválenia dát sken podpisu zamestnanca/MÚ.

Tento sken je buď už dostupný na Opv31:

sken zaměstnancovho podpisu pod Jpc01/uchaz_dok_typ = “4 - Podpisový vzor”

sken podpisu MÚ pod Jpc01/uchaz_dok_typ =“11 - Pečiatka a podpis”

alebo sa v danej akcii formulára umožní zamestnancovi/MÚ z ich diskov uložiť taký sken na Opv31 vo formátoch “gif”, “jpg”, “jpeg”, “png”.

Konfigurácia spôsobu schvaľovania dát na formulároch v danom kroku workflow:
Na Adm33 v záložke Detail pre vyššie uvedené dotknuté kroky workflow vznikli tieto nové

polia:

“Podpis“

Áno/Nie, nepovinné

“Typ“

Ak je hodnota poľa „Podpis“ = Áno, potom sa pre vyplnenie tohto poľa ponúknu používateľovi z comboboxu nasledujúce hodnoty z číselníka Jpc01/seiad_typ: „10 - Elektronický podpis prostý“.
Ak je hodnota poľa „Podpis“ = Áno, potom pole „Typ“ musí byť vyplnené.
Ak je hodnota poľa „Podpis“ = Nie alebo je toto pole nevyplnené, potom sa pole „Typ“ deaktivuje.
„Metóda“
Ak je hodnota poľa „Podpis“ = Áno, potom sa pre vyplnenie tohto poľa ponúknu používateľovi z comboboxu hodnoty z číselníka Jpc01/seaid_metoda, pre ktoré Jpc01/seaid_metoda.kod2 = „Podpis_metoda“,
čo sú dnes tie záznamy, pre ktoré platí Jpc01/seaid_metoda.hodnota = 101, 102, 103.
Ak je hodnota poľa „Podpis“ = Áno, potom pole „Metóda“ musí byť vyplnené.
Ak je hodnota poľa „Podpis“ = Nie alebo je toto pole nevyplnené, potom sa pole „Metóda“ deaktivuje.
Predvolené hodnoty týchto nových polí zobrazených používateľovi sú nevyplnené.

Evidencia párovania skenu podpisu s krokom workflow na frontende:
Na záložke „Audit“ formulárov Dan/Das31/32/33/36 bol do tabuľky pridaný stĺpec „Podpis“, kde je zobrazený preklik na blob použitý podpis v cepdok.

3.21.3 Makra:

WF 5 Pozvánka na vzdelávaciu akciu

+ WF 6 Správa o nedosiahnutí min. počtu na vzdel. akcii

+ WF 7 Správa o odhlásení zo vzdelávacej akcie

%ACTION_LABEL% Komerčný názov akcie

%SPECIF% Špecifikácia (body obsahu)

%DATE_FROM% Akcia od

%DATE_TO% Akcia do

%EDU_ORG% Školiaca organizácia

%EDU_PLACE_ADR% Miesto škol. adresa

%LECTORS% Lektor (Lektori)

%REFERENT% Referent vzdelávania

%CONT_PER% Zoznam kontaktných osôb – ak bude viac, tak napíše všetkých

%NR_DAYS% Počet dní

%NR_HOURS% Počet hodín

%HOURS_FROM_TO% Hodiny od – do

%HTML_LINK% - Odkaz (web, zo spôsobilosti)

%CONTENT% - Obsah kurzu (zo spôsobilosti)

%LITER% - Literatúra (zo spôsobilosti)

%PARTIC% Počet účastníkov

%MIN_PARTIC% Minimálny počet účastníkov

%ESTIMATED_COSTS% - Predpokladané náklady (cena_jeden)

%CENA_ORIENT% - Orientačná cena (cena_orient)

WF 7 Správa o odhláseniu zo vzdelávacej akcie

%REFERENT_JMENO% (len Meno, Priezvisko)

%REFERENT_PMI% (str3, len názov prac. miesta)

%REFERENT_TEL% (druh komunikácie 12, iba hodnota)

%NAHR_POCET% - Počet aktuálne prihlásených náhradníkov

%ESTIMATED_COSTS% - Cena za jedného účastníka: Kva06/Náklady na vzdelávanie/Cena za jedného účastníka

WF 8 Správa o exspirácii periód. spôsobilosti

%JMENO_CELE% resp. %WHOLE_NAME% - celé meno zamestnanca

%OSCPV% - osoba OSCPV

%DATE_TO% Platnosť do

%ZPUS% Kód a názov spôsobilosti

%INVITE_TO% Pozvať do

WF 9 Pozvánka na lekársku prehliadku

%NAZEV_LP% - Názov spôsobilosti

%DRUH_VYS_LP% - Druh vyšetrenia - LP

%DATUM_PROHL% - Dátum prehliadky

%CAS_PROHL_OD% - Čas prehliadky od

%CAS_PROHL_DO% - Čas prehliadky do

%ZDRAV_ZARIZENI% - Zdravotné zariadenie

%LEKAR% - Lekár

%LEKAR_ADRESA% - Adresa (lekár)

%LEKAR_TEL% - Telefón (lekár)

%PLATNOST_DO% - Platnosť do

%POZVAT_DO% - Pozvať na prehliadku do

%DOBA_PRED_LP% - Čas predstihu LP

%DOBA_PRED_PSV% - Doba predstihu PsV

%PRIZNAK_PRIRAZ% - Príznak priradenia

%PERIODA% - Perióda preskúšania

%POZNAMKA_LP% - Poznámka

%DRUH_VYS_PSV% - Druh vyšetrenia-PsV

%PSYCHOLOG% - Psychológ

%MISTO_VYSETRENI_PSV% - Miesto absolvovania psych. Vyšetrenie

WF 54 Správy o nahratí osvedčenia/certifikátu

%DAT_ZMENY% -ID záznamu

%TOSOWFL% - Typ zrážky

%TEXT% - Spracovať v období

%WFL_OSO_TYP% - Ukončiť v období

%WFL_OSO_POZN_PERS% - Poznámka

%WFL_TIMESTAMP% - Časová značka

%KVA_ACTION_LABEL% - Komerčný názov akcie

%KVA_CONT_PER% - Zoznam kontaktných osôb

%KVA_CONTENT% - Obsah kuru

%KVA_DATE_FROM% -Akcia od

%KVA_DATE_TO% - Akcia do

%KVA_EDU_ORG% - Školiaca organizácia

%KVA_EDU_PLACE_ADR% - Miesto škôl. adresa

%KVA_ESTIMATED_COSTS% - Predpokladané náklady

%KVA_CENA_ORIENT% - Orientačná cena

%KVA_HOURS_FROM_TO% - Hodiny od - do

%KVA_HTML_LINK% - Odkaz (web)

%KVA_LECTORS% - Lektor (Lektori)

%KVA_LITER% - Literatúra

%KVA_NR_DAYS% - Počet dní

%KVA_NR_HOURS% - Počet hodín

%KVA_MIN_PARTIC% - Minimálny počet účastníkov

%KVA_PARTIC% - Počet účastníkov

%KVA_REFERENT% - Referent vzdelávania

%KVA_SPECIF% - Špecifikácia (body obsahu)

WF 55 Schvaľovanie ID karty (zákaznícke workflow)

%DAT_NAST% - Dátum nástupu

%PM% - Pracovné miesto

%KARTA_OD% - Platnosť od ID karty

%KARTA_DO% - Platnosť do ID Karty

WF 56 Správy o zmene zbrojného preukazu (zákaznícke workflow)

%ID_TOSOWFL% - ID záznamu

%DAT_ZMENY% -Dátum zmeny

%WFL_OSO_TYP% - Typ zmeny osôb. údajov

%WFL_OSO_POZN% - Poznámka zamestnanca

%WFL_OSO_POZN_PERS% - Poznámka personalistu

%WFL_TIMESTAMP% - Časová značka

WF 57 Správa o zmenách zrážky

%ID_TSRAZKYWFL% -ID záznamu

%SRAZKA_TYP% -Typ zrážky

%SRAZKA_KOD_OBD% - Spracovať v období

%SRAZKA_KOD_OBD_DO% - Ukončiť v období

%SRAZKA_POZN% - Poznámka

%WFL_TIMESTAMP% - Časová značka

WF 58 Správa o zmenách personálnych údajov

%ID_TOSOWFL% - ID záznamu

%DAT_ZMENY% -Dátum zmeny

%WFL_OSO_TYP% - Typ zmeny osôb. údajov

%WFL_OSO_POZN% - Poznámka zamestnanca

%WFL_OSO_POZN_PERS% - Poznámka personalistu

%WFL_TIMESTAMP% - Časová značka

WF 70 Expirácia hesel

%TABLE_NAME% – názov tabuľky, v ktorej je heslo uložené

%ID_RADKU% – ID záznamu z tabuľky (pozri vyššie)

%IDENTIF% – názov položky formulára Adm57 – Autentizácia alebo meno a priezvisko za

mestnanca v prípade formulára Xpw0x (x = 2 alebo 3)

%PASS_DATUM_VZNIKU% – dátum vzniku hesla

%DATUM_EXPIRACE% – dátum expirácie hesla

WF 91 Nepodarilo sa odoslať súbor do DMS

%ZOZNAM_DOKUMENTU% - zoznam neodoslaných dokumentov do DMS

WF 95 - Notifikačné zostavy DOCH/DAV - notifikačné správy

%EMPLOYEES% =Zoznam zamestnancov (Osčpv, Meno)

%EMPLOYEES_COMP_TIME_OFF_HOUR% =Zoznam zamestnancov (Osčpv, Meno, Rozdiel NV)

%EMPLOYEES_MESSAGE% =Zoznam zamestnancov (Osčpv, Meno, Kód hlásenia)

%EMPLOYEES_MESSAGE_DATETIME% =Zoznam zamestnancov (Osčpv, Meno, Kód hlásenia, %Dátum a čas)

%DATETIME_FROM% =Dátum a čas od

%DATETIME_TO% =Dátum a čas do

%DATE% =Dátum

%MSG_CODE% =Kód hlásenia

%PERIOD% = Obdobie

3.21.4 Poznámky k prevádzke:

Workflow sa dá tiež ladiť tzn. neodosielať správy alebo odosielať a logovať správy.

To sa nastavuje položkou Režim ladenia workflow: s hodnotami:

1 - Standard - Odosielať workflow správy

2 - Workflow správy odosielať a logovať

3 - Workflow správy neodosielať a logovať

V záložke Log je potom prezeranie zapísaných informácií.

Upozornenie: používajte logovanie iba krátkodobo pre ladenie alebo riešenie problémov, nie trvalo, generuje veľké množstvo dát!

Režim odosielania zástupcovi

Na formulári Adm33, na karte „Detail“  položka „Režim odosielania zástupcovi:“, je možnosť pozastaviť možnosť odosielania emailu zástupcovi. V prípade, že nastavený zástupca pre príjem emailu, je možné, touto wolbou, pre krok WFL nastaviť, aby práve tento krok nebol odoslaný na zástupcu (napr. pokiaľ je nutné odosielať všetku poštu na zástupcu, okrem pozvánok na školenia). Táto možnosť práve dovoľuje toto možnosť nastaviť.

3.22 Adm34 - Zákaznícke help odkazy

EGJE HR Portál volá zákaznícke help stránky. K tomu je potrebné, aby ich správca pre formulár, zostavu alebo menu definoval.

Adresovanie menu HR Portál:

Základné stránky HR Portál reprezentujú objekty

11 - HR portál - rozhranie zamestnanec

12 - HR portál - rozhranie manažér

Podmenu sú potom reprezentované objekty MENUDL

- Napr: MENUDL_Doch - HR portál - Dochádzka

Pozn. Volá sa help stránka už otvoreného objektu. Teda, aby sa používateľ dostal na stránku podmenu Dochádzka, musí najprv podmenu Dochádzka otvoriť. To isté platí aj pre okná a zostavy.

3.23 Adm42 – Nastavenie a pomenovanie dlaždíc HR Portálu

Tento formulár je súčasťou riešenia redesignu HR Portálu. Pre prehľadnosť jednotlivých dlaždíc, formulárov, zostáv a ich úrovní je na ľavej strane formulára vykreslená štruktúra, kde sa na nulovej úrovni nachádza rozdelenie menu na MANA (dlaždice v manažérskom prístupe používateľa) a EMP (dlaždice v zamestnaneckom prístupe používateľa). Na prvej úrovni sú dlaždice, ktoré obsahujú pridelené formuláre a zostavy alebo (nové) už ďalšie úrovne dlaždíc.
Na pravej strane formulára sa nachádza detail každej dlaždice/formulára/zostavy a náhľad na priradenie do rolí vrátane práva.

Formulár Detailu umožnuje:

- Pridanie novej dlaždice:

i. Môžu sa pridávať nové dlaždice alebo priraďovať existujúce formuláre/zostavy v rámci existujúcich dlaždíc

ii. Nová položka sa vždy pridá pod dlaždicu, na ktorej používateľ stojí v rámci stromovej štruktúry na ľavej strane formulára

iii. Nové dlaždice, prípadne priradenie existujúceho formulára/zostavy pod dlaždicu sa ukladajú ako používateľský záznam, t.j. je možné takúto dlaždicu/priradenie aj zmazať

iv. Nie je možné pridávať novú nulovú úroveň a nie je možné pridávať nové položky pod formuláre a zostavy – tieto už sú konečné v rámci stromovej štruktúry.

v. Pri vytváraní novej dlaždice systém predvyplní časť jej názvu (MENUDL_) a používateľ len vytvára názov za podtržítkom. Platí, že názov objektu musí byť unikátny v rámci celej nulovej úrovne MANA alebo EMP.

- Editácia stávajúcích dlaždíc:

i. Dlaždicu alebo formulár alebo zostavu možno:

1. používateľsky premenovať

2. zmeniť poradie pre zobrazenie na domovskej obrazovke

3. zadať ikonu, ktorá bude zobrazená na domovskej obrazovke

Zadané ikony na Adm42, pretože sú typu SVG, sa prejavia na dlaždiciach iba za predpokladu, že je aktivovaný redesign (tj nahraný JSON súbor na Adm70/priradené akcie 250 a 251).

4. zmeniť nadradenú dlaždicu (možno iba u formulárov a zostáv, nie u dlaždíc)

ii. Objekty možno priradiť k používateľským rolám a zmeniť im hodnotu práva

Takto vystavená štruktúra objektov je následne aplikovaná na domovskej obrazovke s ohľadom na objektové práva prihláseného používateľa.
Ak by pri presúvaní formulárov došlo k tomu, že niektorá dlaždica by nemala podriadené formuláre, nemožno ju zmazať, ale možno v rámci Adm04 nastaviť práva tak, že sa nebude na domovskej obrazovke zobrazovať (karta Konfigurácia použitia, Hodnota vyradenia).

3.24 Adm51 – Zmenové riadenie databázy, štatistiky, AS

Na záložke "Zmena Db" sa vykonáva po vydaní verzie príp. patchu zmenové riadenie databázy.

viď Prevádzková dokumentácia

3.25 A dm52 - Audit

3.25.1 Dátový audit v EGJE všeobecne

Rôzne druhy prevádzkových auditov a logov sú popísané v EGJE_Provdoc.

Tu sa budeme zaoberať dátovým auditom.

Dátové formuláre EGJE v lokálnom menu ponúkajú voľbu Auditné údaje záznamu.

V nej sú údaje o zázname, a nie o každej položke, a nie o každej zmene záznamu, je tu iba jeho vytvorenie a posledná úprava nejaké položky z neho. Vždy používateľ a dátum a čas.

Ak je úprava dát vykonaná mimo formulár EGJE, je miesto používateľa uvedený db používateľ a session.

Pozn.: v niektorých oknách je ešte spodná časť okna venovaná vlastnej položke, z ktorej bol dialóg zavolaný, jej hodnote, číselníku, ale sú to údaje o obsahu položky, nie jej auditu / zmenách.

Záznam, to je väčšia či menšia sada položiek - a tie majú spoločné audítorskú "pečiatku". Z auditu sa teda vie iba to, kedy naposledy niekto zmenil jednu z mnohých položiek, ktoré záznam zdieľajú.

Preto tiež neponúkame tieto informácie na spoločných údajoch o osobe, o PV resp. o organizácii.

Lebo sú spoločné veľkému množstvu položiek a používateľ by mal tendenciu si ich vysvetľovať mylne a robiť z nich nesprávne závery, kto, kedy čo zmenil.

Sú ale miesta v EGJE, kde je aplikovaný podrobnejší audit.

Najviac je ho zobrazené na špeciálnom formulári Adm54. Tu je viac prepínateľných auditou os.

Audit prihlásenia a spúšťania kľúčových akcií a formulárov je na Adm52.

Na rade ďalších formulárov sú potom špeciálne auditné záložky s detailným auditom vybraných položiek a akcií. Často, ale nie vždy, sa dátovo prekrývajú s Adm54.

Patrí sem Adm10, Adm11, Adm12, Adm53, Vyp01, Vyp12, Dcm01, Dcd01.

Nastavenie dĺžky uchovávania dát v týchto audítorských tabuľkách sa vykonáva v Adm21.

Tiež databázy poskytujú rôzne stupne archivácie dátových zmien.

U Oracle ide o režim ARCHIVELOG nahrávajúci všetky zmeny na archívne zariadení. Pomocou utility Logminer je potom možné tento archív prezerať. Ide ale o dosť náročnú a odbornú vec. Zvážiť je tiež potreba výkonnostný dopad režimu ARCHIVELOG.

U Microsoft SQL Serveru sa podobný režim volá Full Recovery Mode.

EGJE opatruje SQL manipulačné príkazy komentárom odkiaľ príkaz je (dátový zdroj).

Od e201709 je tento komentár doplnený auditom, kto a odkiaľ príkaz inicioval (ak to v tej chvíli aplikačný server vie).

Údaje sú štruktúrované takto:

/ * U $: používateľ C $: zdroj údajov ip * /

3.25.2 Vlastný formulár Adm52

Formulár zobrazuje údaje, ktoré (tiež nové) zhromažďujeme v databáze o základných akciách používateľov v systéme.

V audite sú tieto akcie:

· Login - autentizácia klienta

(v objekte práv je typ klienta: EGJE, EGJE-AS, EGJE-WEB, EGJE-WEB2)

· SessionEnd - odhlásenie klienta

· ChooseProfil - výber profilu (v objekte práv je verzia javy, v popise Profil)

· Report - spustenie tlačovej zostavy

· Form - spustenie formulára

· IndVyp - spustenie individuálneho výpočtu mzdy

· HroVyp - spustenie hromadného výpočtu mzdy

· MesUza - spustenie mesačnej uzávierky

· CepUza - uzávierka cestovných príkazov

· RocUza - spustenie ročnej uzávierky

· kopPv - mesačná kópia PV

· kopCis - mesačná kópia číselníkov ZLM a štruktúr

· obeImp - import mzdových vstupov Vst06

· ucto - výstup do účtovníctva

· TaskNapocet - Per01 nápočet dôb, tarifných stupňov, tarifov

· TaskPromitnuti - premietnutie tarifných stupníc na Osoby + PV

· aktualizaceSTR - aktualizácia štruktúr

· davUzavriOtevriAktualizuj

· davZpetnyVyp

· dochDelCedmes

· dochDelPruchodu

· dochGenDD

· dochGenDZ

· dochGenMV

· dochHZPruchodu

· dochKalkulaceOdmen

· dochPrevodDDMV

· dochStravaGSRA

· dochStravaVYHOD

· dochUzavriOtevriAktualizujMV

· dochUzavriOtevriAktualizujPS

· dochVypEvidHodin

· dochZruseniPrevoduDDMV

· Prof.insert - priradenie profilu prístupových práv používateľovi

· Prof.update - zmena priradenia profilu používateľa

· Prof.delete - zrušenie priradenia profilu používateľa

· Ropr.insert - priradenie role do profilu

· Ropr.update - zmena priradenia role v profile

· Ropr.delete - zrušenie priradenia role v profile

· Roel.insert - priradenie objektu práv do role

· Roel.update - zmena priradenia objektu práv role

· Roel.delete - zrušenie priradenia objektu práv role

· Elcfg.insert - založenie definície (ne)použitia objektu v organizácii

· Elcfg.update - zmena definície (ne)použitia objektu v organizácii

· Elcfg.delete - zrušenie definície (ne)použitia objektu v organizácii

· DeleteWorkTab – mazanie obsahu pracovných tabuliek
(podľa nastavenia v Adm21 / Konfiguračné parametre)

· SouhlasFotoYes/ SouhlasFotoNo - zmena údaje Osb02/Foto/ Súhlas s využitím fotografie, kde kód objektu je potom ID osoby

Akcia (zmenové skripty, exporty číselníkov) vykonávané utilitou SuperConfigurator sú tiež zapisované do auditu. Kód elementu je potom "SuperConfigurator" a používateľ je vzatý z používateľov operačného systému používateľa, ktorý SuperConfigurator spustil (s prefixom SC :)

"SC: doména \ používateľ" pre windows,

"SC: používateľ" pre linux.

V auditu môžu byť aj ďalšie akcie (hlavne ide o zákaznícke a interfaceové).

Ďalšie zaznamenávané položky:

Užívateľ (autentizácia): autentizačný reťazec, pomocou ktorého sa používateľ / proces prihlásil

Meno: predchádzajúcu (v dátach uloženú) autentizáciu tu zobrazujeme ako osobu, ktorá ju má priradenú. Ak ich je viac, nie je to obyčajne správne, znamená to, že správca priradil jednu autentizáciu viacerým osobám (výnimkou je, keď je napr. jedna mzdová účtovníčka zavedená vo viacerých organizáciách jednej db - potom je tu ako osoba viackrát (avšak by mala mať to samé meno a priezvisko)

Server IP, sedenie: IP adresa (y) AS resp. EGJEWEB. U pripojenia java klienta bez AS je tu klientská IP.

Sedenie je nejaké poradové číslo EGJE, ktoré spája všetky akcie v jednom sedení (či už ide o AS, EGJEWEB či klienta bez AS)

Klient IP: IP adresa (adresy) klientske stanice, tj. stanice, u ktorej sedí používateľ.

U serverových akcií (Adm53) vyplnená nie je.

Trvania akcie [s]: U tlačové zostavy, ktorá úspešne dobehla, je tu uvedená doba jej vytvárania.

Popis: Doplňujúce informácie

U akcie Login sú tu údaje o klientovi, ktorý sa prihlasuje (líši sa podľa Typu aplikácie)

U akcie ChooseProfile je tu kód profilu, cez ktorý sa používateľ hlási.

Číslo správnej jednotky: Je vyplnené u používateľa, ktorý je obmedzený vďaka profilu na jednu SJ

Správne oddiel: dtto pre SO

Organizácia: dtto pre Organizáciu (s tým, že organizácia nie je súčasťou profilu, ale priradenia profilu - Adm01 / Adm10)

Vlastná osoba: Je vyplnené u používateľa, ktorý má prístup len k dátam vlastnej osoby (riadková práva VL_OSO)

Dátum a čas akcie: Kedy akcia prebehla, resp. bola zaznamenaná.

Audit label: Audítorská pečiatka tohto audítorského záznamu.

Profil autorizácie: Profil používateľa (v auditu sa od súčasného naspäť hľadá akcia ChooseProfil pre konkrétneho používateľa a jeho sedenie).

Autorizácia v: Dátum a čas tejto akcie.

Typ aplikácie: EGJE, EGJE-AS, EGJE-WEB2 - podľa klienta, cez ktorého je používateľ prihlásený. U java klienta rozlišujeme prihlásenie cez AS a bez neho.

Je zistený z predchádzajúcej používateľove autentizácie (akcie Login).

Autentizácia v: Dátum a čas tejto akcie.

Tabuľka parametrov:

Obsahuje parametre spustenej zostavy / procesu, len ak je centrálne zaškrtnutá položka "Vykonávať audit parametrov akcií" a to tu na záložke Nastavenie.

Nastavenie:

Vykonávať audit spustenia formulárov: implicitne zaškrtnuté - zaznamenávať do Adm52

Vykonávať audit spustenia reportov: implicitne zaškrtnuté - zaznamenávať do Adm52

Vykonávať audit parametrov akcií: implicitne nie je zaškrtnuté - pozri Tabuľku parametrov opísaná v predchádzajúcom bode.

Pozn.: automatické premazávanie auditnej tabuľky (súčasť mesačnej uzávierky):

· Výkonové záznamy PERF * (spustené len u niektorých zákazníkov)

Ponechávame iba posledný mesiac.

· Štandardné záznamy
ponechávame posledných 6 mesiacov
Mazanie je možné potlačiť parametrom Adm21 / Konfiguračné parametre / Potlačiť mazanie audit tabuľky (Adm52).
Sme však presvedčení, že mazanie je vhodné a činnosť formulára Adm52 na neho spolieha. Pri jeho potlačení môže byť nutné pracovať s auditorskou tabuľkou (cesaudit) mimo systému EGJE. Tabuľka tiež ovplyvňuje veľkosť dát pri zálohovaní db.

Výkonové logovanie sa spúšťa parametrami logSlowDBRequests, logSlowWebRequests (hodnoty milisekúnd definujúce dlhú odozvu) v súbore config_local.properties.
A je dobré ich ihneď po ukončení merania zase odstrániť z konfiguračného súboru Web / Štandardné aplikácie.

Pozn. 2 : premazávanie starých auditných údajov systém vykonáva každý mesiac v mesačnej uzávierke (za celú databázu).
Výkonové dáta sa ponechávajú vždy len za posledný mesiac, ostatné auditné dáta sa ponechávajú 6 mesiacov. Toto premazávanie je možné vypnúť na Adm21 / Konfiguračné údaje / Potlačiť mazanie auditu tabuľky (Adm52). Toto však odporúčame len vtedy, ak db správca odkladá dáta z tabuľky cesaudit ručne do iného úložiska.

3.26 Adm53 - Úlohy na AS

Formulár umožňuje nastaviť / spravovať úlohy, ktoré majú prebiehať periodicky.
Typické použitie je inštalácia EGJE s AS, kedy do položky Spustiť na serveri s IP vypĺňame IP v4 adresu aplikačného servera (nie host name). Môžeme tu tiež uviesť ich zoznam, ak máme AS viac. Ako oddeľovací IPv4 adries sa používa čiarka.

Medzi AS je tiež potrebné počítať EGJEWEB server, ten je tiež z pohľadu Adm53 aplikačným serverom. IP adresa slúži k tomu, aby EGJE server zistil, že je uvedený medzi IP adresami a že sa teda má pokúsiť spustiť v daný čas úlohu. EGJE obsahuje mechanizmus, aby jednu zaevidovanú úlohu nespustilo viac serverov.

Ak máte potrebné AS a EGJEWEB na rovnakej IP adrese a nechcete, aby napr. EGJEWEB úlohy spúšťal. Je možné do jeho config_local.properties pridať parameter:

suppressjobs = true

ktorý konkrétny inštanciu EGJE servera vo spúšťanie úloh zabráni.

Elegantnou možnosťou sú makrá AS (db) resp. WEB (db), kde db je povinný parameter odkazujúci na databázu. Vyplňujeme je miesto zoznamu IP adries.

Pr. AS (Elanor@egjeprod)

Keď je používateľ prihlásený ako klient AS je pri zadávaní novej úlohy v Adm53 údaj predvyplnený.

Vyplnenie makrom je praktické z týchto pohľadov:

• pri kópii db do testovacieho prostredia, ktoré beží proti inej db, dôjde k žiaducemu zastaveniu úloh (hlavne tých nebezpečných integračných)

• pri zmene IP adresy AS resp. pridanie ďalšieho netreba nič prestavovať

• odlíši AS a WEB server - čo je obzvlášť užitočné, keď sú na jednom stroji

• keď je AS spustený na tomcat / EGJEWEB, server sa hlási ako AS(db) a preberá kontrolu spúšťanie úloh od EGJEWEB aplikácie

Teoreticky je síce možné pri inštalácii bez AS aj zadať IP stanice, ktoré budú bežať stále, ale toto je vyložene náhradné riešenie.
U denného spúšťania sa nastavuje čas (v 24-hodinovom formáte) v položke "Čas spúšťania (denne)". Pri potrebe inej periodicity sa vypĺňa položka "Čas spustenia (Cron formát)", kde sa do položky zadáva štandardný formát unix - cron viď ďalej Poznámka.

Položka Budúce spustenie potom umožňuje správcovi budúce spustenie periodicky spúšťanej akcie odsunúť na neskôr. To môže byť vhodne napr. pre odstavenie spracovanie priechodov po dobu zmenového riadenia apod. Avšak majte túto položku na zreteli, keď napríklad meníte čas spustenia, môže byť vhodné obsah položky Budúce spustenie v tomto prípade vymazať.

Funkcia "Spustiť teraz" spúšťa úlohu na aktuálnom aplikačnom serveri, ku ktorému je používateľ v tú chvíľu pripojený, nie na serveri, ktorý je vyplnený pomocou IP adresy.

Pre vyskúšanie naplánovanie akcie teda zapíšte do "Čas spúšťania (denne)" čas, ktorý nastane za niekoľko minút:

· ak je aplikačný server jeden (tzn. zhodný s komunikačným) tak postačí pre test dať napríklad čas za 2 minúty

· ak je aplikačných serverov viac, zadajte čas väčší ako za 5 minút (to je doba, kedy si každý AS načítava zoznam úloh znova)

Dočasné pozastavenie je možné vykonať vyplnením poľa Budúce spustenie dátumom a časom, po ktorom má byť spúšťanie obnovené.

Parametre "Organizácia" a "Profil práva spúšťané úlohy", umožňujú definovať prístupové práva (hlavne k riadkom), spúšťané úlohy, teda obmedzenia, nad akými dátami pobeží.

Akcia Hromadné akcie / Nastavenie IPs resp.makra všetkým úlohám v navigačnom zozname

je určená pre hromadné vyplnenie tejto položky všetkým úlohám (v rámci výberu, ak bol vykonaný)

Ďalšie Hromadné akcie:

Hromadné vypnutie

Hromadné zapnutie

umožňujú aktívne hromadné akcie vypnúť / zapnúť, resp. dočasne vypnúť - hromadné vypnutie totiž nastavuje status -1 - Vypnuté hromadne, takže je potom možné neskôr zase akcie s týmto nastavením vybrať a Hromadne zapnúť.

Hromadné vypnutie všetkého sa hodí pre testovacie prostredie po inštalácii novej kópie produkčné db.

Pozn. Perióda spúšťania -formát unix cron

Popis formátu, ktorý je implementovaný :

http://www.sauronsoftware.it/projects/cron4j/manual.php#p02

Pre lepšiu orientáciu v samotnom cron formáte uvádzame popis jednotlivých pozícií, čo označuje:

• Prvá * => minúty (*, 0 … 60)

• Druhá * => hodiny (*,0 … 24)

• Tretia * => deň v mesiaci (*, 0 … 31)

• Štvrtá * => mesiac (*, 0 … 12)

• Piata * => deň v týždni (*, 0 – Sunday, 6 - Saturday,….)

Vždy sa musia dávať medzery medzi jednotlivé časti.

Odporúčame pre presnejšie nastavenie uvádzať aj 0 v minútových častiach i hodinových častiach, pokiaľ ide o jednociferné číslo v určení hodín.

Príklady použitia Cron formátu :

*/15 * * * * každých 15 minút

*/15 6-18 * * * znamená každých 15 minút, ale iba medzi 6:00 a 18:00

30 0 1 * * proces spustí v 0:30 hodín vždy každého prvého v mesiaci

30 20 L * * proces spustí v 20:30 v poslednom dni mesiaca (písmeno L).

30 2 * * Mon proces spustí v 2:30 každý pondelok

30 10 15 12 * proces spustí v 10:30 15.decembra

Periodicky je možné spustiť tieto akcie:

1 - Zostava (tlačová, import, export, klient WS)

2 - Zostava prístupná ako Webová služba

6 - Správa o nedosiahnutí min. počtu na vzdelávaciu akciu

8 - Správa o exspirácii periód. spôsobilosti

9 - Zasielanie správ prihláseným používateľom

10 - Upozornenie na workflow

11 - Obsadenie akcií (vrátanie náhradníkov)

15 - Notifikácie RZD (nezaložené, neodoslané) (pre Dan40)

20 - Generovanie Poj17 – zmeny ZP CZ

31 - Kalkulácia dennej dochádzky za deň podľa režimu

32 - Kalkulácia dennej dochádzky od 1. dňa do dňa podľa režimu

33 - Otvorenie zúčtovacieho obdobia (typicky mesačne)

34 - Hromadné spracovanie priechodov

35 - Kalkulácia úkolovej mzdy

36 – Kalkulácia priechodov

70 – Expirácia hesla (väzba na WFL Adm33, Akcia 70)

101 Kontrola platnosti spôsobilosti podľa veku (zákaznícka hodnota)

102 Generovanie požiadaviek zdravotnej spôsobilosti (kontrola na 50 rokov veku)

103 Úprava platnosti zdravotnej spôsobilosti (podľa Platnosť DO a 50 rokov veku)

104 Generovanie požiadaviek na per. Školenie (podľa Pozvať do)

105 Upozornenie na požiadavky na vzd. akciu

106 Úprava platnosti zdravotnej spôsobilosti (prvý prepočet nad 50 rokov fixný)

107 Generovanie požiadavky nadväzného periodického školenia

108 Požiadavka na zdravotnú spôsobilosť

109 - Vzdelávanie - automatizácia náhradníkov

110 - Upozornení na termíny adaptácie

111 - Správa o termíne vyplnenia hodnotenia

Podrobný popis procesov z oblasti dochádzka (31, 32, 34, 35, 36) viď. Doch_dopl_uzivdoc_sk.

Pozn.: Predvyplnenie parametrov resp. pridanie nových parametrov u už jestvujúcich úlohy realizuje funkcie "Generuj parametre".

Na tomto formulári Adm53 à na karte Parametre à Formulárový pohľad ide vybrať ako jednu z položiek „Profil“. Pokiaľ je tento profil nastavený na formulári Adm26, potom zaisťuje možnosť SFTP prenosu a tiež možnosť šifrovania či dešifrovania súboru.

3.26.1 1 - Zostava (tlačová, import, export, klient WS)

Parametre pre úlohu 1.

Pokiaľ sa periodicky spúšťa zostava, potom je potrebné/možné zadať nasledujúce parametre:

*Meno parametra*	*Typ parametra*	*hodnoty a popis*
report	String	Kód zostavy
report_format	String	["pdf", "rtf", "html", "txt", "xls", "xlsx", "docx", "odt", "xlsx_formatted", "csv", "zip", "xls_old"] - v prípade neuvedenia parametra je default pdf Mnoho zostáv podporuje len niektoré formáty.
output_folder	String	Zložka výstupného súboru(ov)
r_nazov_sub	String	Meno výstupného súboru
path	String	Parameter sa zadáva iba u štandardnej zostavy, a to vždy s hodnotou cz.elanor.eman.reports
...		Ďalšie parametre tlačovej zostavy (viď. súbor report.xml elementy parameter atribut name) U štandardnej zostavy ich správca zaistí buď tak, že z nich skopíruje používateľskú zostavu a pozrie sa do pracovného adresára alebo vstúpi do balíku eman.jar ako do zip súboru (napr.Ctrl+PageDn v Total commanderi) a súbor nájde na ceste cz/elanor/eman/report/report/report.xml
r_send4error2ext r_send4err_level r_send4error2ext2 r_send4err_level2 r_send2prof_int r_send2prof_ext r_send2oso_int r_send2oso_ext r_send2ext r_mail_from		Parametre pre odoslanie výsledku zostavy rešp. protokolu o procese
r_jiny_soubor r_jina_slozka r_jina r_ftp01_slozka r_ftp01_poznamka r_ftp01_kategorie r_ftp01		Parametre pre ukladanie výsledku do Ftp01 alebo na iné ďalšie serverové miesto (pozri Adm61 a Agenda výmeny súborov)

Parameter pre akciu generujúcu protokol (typicky dochádzka)

*Meno parametra*	*Typ parametra*	*hodnoty a popis*
max_protocols	Long	Počet protokolov z vykonanej akcie, ktoré majú byť zachované (ďalšie staršie sú zmazané)

Stručný popis:

3.26.2 2 - používateľská zostava ako WS

3.26.3 3 – Webová služba REST (realizovaná uživ. zostavou)

Pre typ AS úlohy 3 – WEBová služba REST na Adm53 bola vykonaná zmena kontroly z nastaveného užívateľa (Osoba – autor) prípadne „Zmenu vykonal“, pokiaľ nebol Osoba – autor zadaný, na užívateľa podľa nastaveného profilu „Profil práv po spustení úlohy“ tak, aby sa kontroloval voči autentizovanému užívateľovi. Jedinou výnimkou je situácia, kedy je na Adm57 nastavená autentizácia pomocou API key. To bude prebiehať kontrola podľa nastavenej osoby na Adm53  Osoba – autor.

Spôsob nastavenia Adm53 v prípade typu AS úlohy = 3 je popísaný v dokumentácii EGJE_SW_provdoc.

Spôsob nastavenia autentifikácie pomocou Adm57 je popísaný v tejto dokumentácii, pozri časť 3.30.

3.26.4 6 - Správa o nedosiahnutí min. počtu na vzdel. akciu

Parametre pre úlohu 6 Správa o nedosiahnutí min. počtu na vzdel. akciu

*Meno parametra*	*Typ parametra*	*hodnoty a popis*
r_days_before	Long	Počet dní pred začiatkom akcie, kedy sa kontrola vykoná

Vlastné upozornenie je definované v Adm14 ako workflow akcia č. 6. Zmena hodnoty z 0 na 1.

3.26.5 8 - Správa o exšpirácii period. spôsobilosti

Kontrola prechádza spôsobilosti osoby (Kva01) v rámci riadkových práv a kontroluje platnosť spôsobilosti vzhľadom k dnešnému dňu.
Proces zapíše údaj Pozvať do (cehtosozpus.pozvat_do), ktorý vypočíta ako Platnosť do - doba predstihu (tzn. ako na Kva01 per.škol. pri uložení)
Proces sa zaoberá spôsobilosťami týchto druhov: 12, 13, 31, 32, 41 (jpč druh_zpus), ktoré však majú v číselníku Zpu01 vyplnenú periódu (cehzpus.perioda)
Vlastné upozornenia je definované v Adm33 ako workflow akcie č 8. Zmena hodnoty z 0 na 1.

Akcia prechádza spôsobilosti prechádzajúce v období od dnešného dátumu mínus počet dní zadaný parametrom r_kontr_zpus_x_dni. Ak parameter nie je vyplnený, kontrola berie obdobie od 1. v mesiaci do aktuálneho dátumu.

Kontrola zohľadňuje, že po expirovanej spôsobilosti má zamestnanec zadanú rovnakú spôsobilosť, ktorá nadväzuje resp. je k aktuálnemu dátumu platná.

Ďalej má úloha parameter "r_id_toso_recips" - Miesto príjemcu z Adm14 odoslať na e-mail osoby.

Ak u úlohy vyplníte tohto príjemcu, dostáva oznámenia on a nie osoby určené pravidlami v Adm33 / akcie 8 / krok 0 => 1

Parameter r_status_to - "Výber textu e-mailu (z Adm33, implicitné je 1):

určuje, ktorý opis z Adm33 má byť použitý ako predloha správy:

0 - Univerzálny štartovný bod

1 - Expirácia text 1

2 – Expirácia text 2

3 – Expiráia text 3

Vecne jednotlivé hodnoty číselníku zodpovedajú rôznym adresátom upozornenia.

Parameter Výber textu e-mailu. Nadväzuje na rozšírenie číselníku u rovnaké úlohy v Adm33 - číselník parametra je zhodný s uvedeným číselníkom. Implicitné nastavenie hodnotou 1.

Spracovanie príjemca pridaného u úlohy 8 priamo v Adm53 (ktorý teda nie je určený pravidlom).

Doteraz tento príjemca dostal každé zistenie zvlášť, teraz je to spojené do jedného e-mailu.

Obsahuje tiež parameter "Potlačiť zápis Pozvať do" súhlas default Nie.

Parametre úlohy dovoľovali posúvať s dátumom, od kedy sa má nesúlad zisťovať (r_kontr_zpus_x_dni), ale už nie do kedy. K tomu slúži nový parameter, ktorý to dopĺňa:

r_kontr_zpus_bud_dni s názvom "a ktoré prejdú v najbližších x dňoch (-1 = tento mesiac, -2 = budúci mesiac)"

Pri nevyplneniu niektorého z nich sa systém chová takto:

· Keď r_kontr_zpus_x_dni = null and r_kontr_zpus_bud_dni = -1, tak datum_od = 1. akt. mes. datum_do = posledného akt. mes.

· Keď r_kontr_zpus_x_dni = null and r_kontr_zpus_bud_dni = -2, tak datum_od = 1. budúci mes. a datum_do = posledného budúci mes.

Parameter "Rozšíriť o kontrolu voči požiadavkám z Pmi01". Ak je parameter nastavený na hodnotu Áno, potom budú doteraz kontrolované spôsobilosti rozšírené o tie, ktoré sú zadané na Pmi01 ako platné požiadavky. Toto rozšírenie platí len druh spôsobilosti 11 a 12.

Parameter "Respektovať Pozastavenie od-do". V rámci expirácie berie do úvahy nastavenie pozastavenia spôsobilosti na Kva01. Pre správne fungovanie pozastavenia je potrebné vyplniť oba dva dátumy.
Parameter Posielať notifikácie jednotlivé. V prípade, že jeden zamestnanec má viac spôsobilostí, ktorým končí platnosť spôsobilostí v ten istý deň, je nově možné notifikáciu posielať každú zvlášť v samostatnom e-maile.

3.26.6 9 - Zasielanie správy prihláseným používateľom

Zákazníkom s AS či EGJEWEB umožňuje nastaviť periodické rozoslanie upozorňujúce správy (napr. pred pravidelným reštartom serverov), pričom správa sa napíše do Parametre - parameter message ako hodnota.

Profil ani jazyk nemá na správu vplyv.

Túto akciu je možné používať aj pomocou funkcie Spustiť teraz (napr. pre aktuálne reštart).

3.26.7 10 - Upozornenie na workflow

Akcia e-mailom upozorňuje manažérov na workflow, ktoré by mali zodpovedať.

Štandardné parametre:

· Odoslať protokol na e-mail - možnosť dozoruj správcom

· Minimálna úroveň chyby pre odoslanie protokolu - podrobnosť protokolu

Parametre akcie sú:

· Workflow požiadavka - možnosť obmedziť na konkrétny workflow (nepovinný par.)

· Workflow požiadavka do (nepovinný) – možnosť zadať rozsah do požiadaviek (typicky pre 301-399 – Dokumenty). „Od“ je predchádzajúci parameter.

· Číslo notifikácie - Eskalačné upozornenia týmto dostanú maximálny počet upozornení pre jedno workflow. Prvé uspornenie je to pri vzniku workflow, tu začíname druhým.

· Odosielateľ - e-mail odosielateľa zadaný pomocou osoby a jej kontaktu (Osb01,02 / Komunícia)

· Režim ladenia - umožní cvičné spustenie bez generovaných e-mailov (keď bez e-mailu, tak bez zápisu, že bolo odoslané)

· Zvýšené logovanie do Protokol – do záložky Protokol je generovaných viac údajov. Nezapínajte na dlhší čas, generuje veľa dát do údajov Adm53!

Vlastné logovanie e-mailov potom smeruje do Adm54 / E-maily, ak je Režimom ladenia zvolené logovanie workflow, potom je ukladané do Adm14/konkrétny wfl /Definícia workflow/Log

3.26.8 12 - Odosielanie zlúčených správ

Úloha umožňuje používateľom (typicky manažérom), aby notifikačné e-maily na jednotlivé workflow nedostávali individuálne, ale hromadne vo zvolených časoch.

Typicky sa to týka workflow Dokumenty (akcia 301-399).

Predpoklady a konfigurovateľnosť:

· parametre organizácie – Adm21 / Parametre komunikácie:

o Zlučovať e-maily - druhy e-mailov - Výpočet hodnôt Jpc01 (oddeľovač čiarka) - druh_komún – keď nie je vyplnený, berie sa 30,31,32,33,34

o Zlučovať e-maily týchto WFL - Výpočet (oddeľovač čiarka a pomlčka) hodnôt Jpc01 - wfl_akce - keď nie je vyplnený, berie sa 301-399

· Užívateľ manažér

o má pri sebe (Osb01,Osb02 / Komunikácia) uvedený e-mail príslušného druhu, ktorý je použitý v definíciách kroku na Adm14

o otvorí si Adm15 / Zlučovanie notifikácií a uvedie, pre ktoré maily chce notifikácie zlučovať a tiež prípadne, v ktorých časoch ich chce obdržať (hodina a štvrťhodina)

Keď povie, že chce zlučovať, ale nepovie kedy, je použitý čas(y), ktorý správca nastaví v parametroch úlohy 12 na Adm53 (viď ďalej)

Štandardné parametre:

· Odoslať protokol na e-mail - možnosť dozoruj správcom

· Minimálna úroveň chyby pre odoslanie protokolu - podrobnosť protokolu

Parametre akcie sú:

· Osoba/kontakt nemá čas odoslania - použi tento (1): pokiaľ si užívateľ na Adm15 / Zlučovanie nastaví, že chce zlučovať ale nenastaví si čas doručenia, použije sa tento čas

· Osoba/kontakt nemá čas odoslania - použi tento (2): dtto – ďalší čas

· Osoba/kontakt nemá čas odoslania - použi tento (3): dtto – ďalší čas

· Predmet správy: použitý pre e-mail

· Odosielateľ e-mailu: tu je možnosť zadať priamo e-mailovú adresu odosielateľa (nie okľukou cez osobu, ako je to v ďalších úlohách a kde to tak pre kompatibilitu nechávame)

· Režim odosielania e-mailov: umožní cvičné spustenie bez generovaných e-mailov (keď bez e-mailu, tak bez zápisu, že bolo odoslané)

· Test režim: všetko na tento e-mail (aj už odoslané e-maily) – vyplnením svojho e-mailu má správca možnosť akciu a generovanie vyskúšať aj pred tým ako si to používatelia nastavia a vzniknúť nová workflow. Použijú sa logované staršie správy.

· Odosielateľ e-mailu: tu je možnosť zadať priamo e-mailovú adresu odosielateľa (nie okľukou cez osobu, ako je to v ďalších úlohách a kde to tak pre kompatibilitu nechávame)

· Režim odosielania e-mailov: umožní cvičné spustenie bez generovaných e-mailov (keď bez e-mailu, tak bez zápisu, že bolo odoslané)

3.26.9 33 - Otvorenie zúčtovacieho obdobia (typicky mesačne)

Úloha vytvorí výplatné termíny pre nasledujúci mesiac, a to pre tie SO/SJ, ku ktorým má profil prístup (viď Vyp02, Dcu02, Cep02) a ktoré sú v otváranom období platné.

Vytvára tie záznamy, ktoré boli v minulom mesiaci a sú platné aj pre zakladané obdobie alebo sú novo platné v zakladanom období, rešpektuje teda aj skladbu typov VT.

Postup generovania (opakovane pre každé požadované obdobie):

Vytvoríme zoznam platných SO pre obdobie generovania (pre dobierkové VT) .

Pokiaľ sa jedná o SO platné v predchádzajúcom období - skopírujeme z predošlého obdobia

Pokiaľ sa jedná o nový SO - vytvoríme nový záznam s nastavením podľa Adm22 (do protokolu sa zobrazí hlásenie a je potrebné doplniť nastavenie podľa potrieb organizácie)

Potom pre každé SO v zozname nastavíme:

Status VT 1 alebo 2 - podľa voľby.

Dátum výplatného termínu podľa konfigurácie.

Pre každé obdobie potom sa vykoná:

Mesačné kópie číselníkov SLM a štruktúr (pre všetky ORG, SO za obdobie) - pokiaľ je povolené, v rozsahu Vyp02

Hromadné generovanie kalendárov (pre všetky ORG, SO za obdobie) - pokiaľ je povolené, v rozsahu Vyp02

Pre DOCH inštalácie, hromadné generovanie dochádzky osobám/Pv s

Opv01 / Režim / Režim spracovania dochádzky = 10 - Generovanie prítomnosti dopredu (z kalendára).

Pre inštalácie bez dochádzky (nemajú nastavenú položku Adm21, Dochádzka, Zlm pre evidenciu odpracovanej doby) sa otvára štandardne jedno obdobie (viď parametre), pre inštaláciu s dochádzkou sa štandardne otvárajú 2 obdobia. Pre druhé otvárané obdobie sa nevykonáva mazanie historických dát pracovných tabuliek.

Pokiaľ sa jedná o inštaláciu typu multiorganizácie, zisťujeme nastavenie pre dochádzku pre hlavnú Organizáciu, pokiaľ je nevyplnené, tak vyhľadávame na všetkých organizáciách - pokiaľ je nastavené aspoň na jednej, považujeme za DOCH.

Poznámky k prevádzke:

Ak sa spúšťa pre viacero období, vymazanie historických dát podľa stanovených podmienok na Adm21 sa vykonáva iba pre prvé.

Parametre:

Dátum generovania (r_datum_gener)

nastavenie bez pamäťového efektu, slúži iba pre jedno spustenie.

ak je vyplnený Dátum generovania, spustiť pre tento dátum, pokiaľ je nevyplnený, tak z referenčného dátumu profilu)

formát na zadanie: rrrr-mm-dd

Status výplatného termínu: - default 1 (pamäťový efekt)

Voľba 1 alebo 2

nastavenie pre nové SO/obdobie

Deň výplatného termínu v BM: - povolená hodnota 1 - 32 (pamäťový efekt)

pri nevyplnení - položka sa nenaplní

pri zadaní dňa na neplatný deň mesiaca - položka sa nenaplní (napr. 31 na február)

pri zadaní na deň sviatku - posun na predošlý/nasl. prac. deň

(sviatok stanovený z číselníka sviatku a LEG pre SO, pre Typ sviatku = 1)

pri zadaní na voľný deň - posun na predošlý/nasl. prac. deň (za voľný deň budeme považovať So/Nie)

pri zadaní:

= 32 tak deň sa nastaví na posledný deň v nasledujúcom období po otváranom období

= -32 tak deň sa nastaví na posledný deň v otváranom období

>= 0 potom dátum je v nasledujúcom období po otváranom období

< 0 potom dátum je v otváranom období

Pokiaľ je parameter vyplnený, tak pre nové SO/obdobie nastavíme položku na zadaný deň v období

Pokiaľ deň padne na deň sviatku alebo So/Nie, posunieme dátum podľa akt. obsahu parametra Posun výplatného termínu pri SV a nepri. dni

Posun výplatného termínu pri SV a nepri. dni - posun deň výplaty na najbližší pracovný deň, default = 1 (pamäťový efekt)

Číselník:

0 - bez posunu

vždy sa použije dátum určeného dňa

1 - posun na najbližší predošlý pracovný deň

ak spočítaný dátum padne na deň SV alebo So/Nie - posunieme na dátum predošlého pracovného dňa

2 - posun na najbližší nasledujúci deň pracovný deň

ak spočítaný dátum padne na deň SV alebo So/Nie - posunieme na dátum nasledujúceho pracovného dňa

Mesačné kópie číselníkov SLM a štruktúr - voľba Áno/nie, default Nie (pamäťový efekt)

funkcie v rozsahu Vyp02, Popis, Mesačné kópie číselníkov SLM a štruktúr (pre všetky ORG, SO za obdobie)

ak je Nie - tak sa kópia číselníka nevykonáva

ak je Áno - tak sa kópie vykonávajú

Hromadné generovanie kalendárov - voľba Áno/Nie, default Nie (pamäťový efekt)

funkcie v rozsahu Vyp02, Popis, Hromadné generovanie kalendárov (pre všetky ORG, SO za obdobie)

ak je Áno - tak sa kalendáre generujú a zároveň sa mažú historické údaje z tabuliek

ak je Nie - tak sa kalendáre negenerujú, ale tiež sa nečistia historické dáta

Zoznam SO, pre ktoré neotvárať obdobie - default nevyplnené (pamäťový efekt)

ak je SO v zozname, tak bude vylúčené z generovania

Počet otváraných období: (r_pocet_mes_predstihu)

Počet mesiacov predstihu, povolená hodnota 1 až 12)

pri spustení skontroluje / vytvorí dopredu viac období a v nich vygeneruje kalendáre

Max. počet uložených protokolov: (max_protocols)

Počet protokolov, ktoré majú byť zachované v systéme

Štandardné parametre formulára Adm53:

Odoslať protokol na e-mail: (r_send4error2ext)

Minimálna úroveň chyby pre odoslanie protokolu: (r_send4error2ext)

Adresár na uloženie výstupu:

Názov súboru:

Odosielateľ e-mailu:

Odoslať výsledok osobe internou poštou:

Odoslať výsledok osobe e-mailom:

Odoslať výsledok na e-maily:

Odoslať výsledok osobám na profile internou poštou:

Odoslať výsledok osobám na profile e-mailom:

3.26.9.1 Poznámky k prevádzke

Hlásenie o „existujúcom“ období

Pokiaľ pri otváraní obdobia sa zistí, že obdobie je už otvorené, zobrazí sa hlásenie:

Obd. <obd> pre SJ <sj>, SO <so>, Typ VT <typ> je už otvorené

a pokračuje sa k funkcii generovania kalendárov pre obdobie.

Hlásenie o „neexistujúcich“ SO k „otvoreniu“ pre obdobie

Pokiaľ pri otváraní obdobia sa zistí, že zoznam SO pre otvorenie je prázdny (nie sú žiadne SO pre ktoré je potrebné otvoriť obdobie), zobrazí sa hlásenie:

Pre obdobie <obd> nenájdené žiadne obdobie pre otváranie !

a funkcia sa ukončí.

Upresnenie funkcie, pokiaľ nie je “zaškrtnutá” voľba voliteľných krokov:

Keď parameter nie je uvedený parametroch úlohy 33 pre Adm53 (historicky založené záznamy, alebo chybná aktivácia úlohy):

• Hromadné generovanie kalendárov sa chová ako by bolo zaškrtnuté

• Mesačné kópie číselníka SLM a štruktúr sa chová ako by nebolo zaškrtnuté

• Generovanie kalendárov pre budúce obdobie do konca roka sa chová ako by nebolo zaškrtnuté

Keď je parameter uvedený v parametroch chová sa podľa toho, či je zaškrtnutý alebo nie.

Obmedzenie "mazania historických dát"

Pokiaľ sa súčasne otvára viac období (nastavený parameter Počet otváraných období) tak sa mazanie vykoná pri každom otváranom období v rámci funkcie Hromadné generovanie kalendárov.

Pokiaľ je zapnutá funkcia Generovanie kalendárov pre budúce obdobie do konca roka, tak sa mazanie pre iba aktualizované obdobie, mazanie nevykonáva.

Voľba obdobia spustenia (pri kontrole resp. opätovnej požiadavke na otváranie)

Aby bolo možné otvárať aj neskôr ako v akt. obdobie, je k dispozícii parameter:

Obdobie pre výber: - referenčné obdobie na spustenie úlohy

Nevyplnené (default) - potom sa použije obdobie podľa ref. obdobia

Vyplnené, tak sa použije na výber obdobia, podľa ktorého budeme otvárať

Pozor: Pre uzavreté obdobie pre SO sa nesmie spúšťať hromadné funkcie akt. kalendárov/číselníky.

Otváranie “nových SO”

Vytvoríme zoznam o SO, ktoré sú v Adm23, sú nové pre obdobie “referenčné + 1” a nemajú záznam vo Vyp02.

Pre každé SO v tomto zozname zobrazíme hlásenie:

Nový SO <so> platný pre <obd>, založený pre Vyp02

doplníme do základného zoznamu obdobia na otváranie a položky nastavíme podľa parametrov úloh.

Súbežné spustenie úlohy

Pri spustení sa vykonáva kontrola pre súbežné spustenie úlohy Adm53/33 a predovšetkým zabránenie súčasného kopírovania číselníka v rámci otvárania obdobia.

Pri súbežnom spustení, keď jeden proces už beží, tak si druhý proces ošetrí stav, preskočí blokujúcu úlohu a do protokolu vloží hlásenie:

sk.elanor.eman.datasource.remoteCompute.LockerException: Akciu nemožno vykonať. Užívateľ práve vykonáva iné akcie, ktoré ju blokujú proti spusteniu.

Blokujúca úloha: "Hromadné generovanie kalendárov"

parametre: "Hromadné generovanie kalendárov (pre všetky SO za obdobie ) 2024-01=r_kod_obd"

" spustená užívateľom:, čas spustenia:29.12.2023 20:19."

a proces sa korektne ukončí.

3.26.10 70 Expirácia hesla

Úlohu 70 je potrebné definovať v súvislosti s Adm33 a akciou workflow 70 a ďalej v nadväznosti na konfiguráciu 105 – Expirácia hesla vo formulári Adm70.

Kontrola prechádza tabuľkami definovanými v rámci Adm70 v rámci konfiguračnej položky 105. Z tejto položky si načíta počet kalendárnych dní. Následne prechádza záznamy v týchto DB tabuľkách a od hodnoty expirácie hesiel odpočíta načítaný počet kalendárnych dní. Ak nájde záznam, kde dátum expirácie mínus počet dní je menší alebo rovný aktuálnemu dátumu, vygeneruje tento záznam do logu. Log následne so všetkými položkami odošle na predom definovaného používateľa – buď priamo na Adm53 alebo podľa nastavení v Adm33.

Parametre pre úlohu 70:

· Kontrola x kalendárnych dní pred expiráciou → r_kontr_kal_dni - editovateľné pole pre zadanie kladného celého čísla (definícia počtu dní, ktoré sa zadajú pre výpočet dátumu upozornenia na končiacu platnosť hesla). Parametr je povinný, predvolený je 10 dní.

· E-mail príjemca → r_typ_kontaktu_recips - položky číselníka komun_druh (len položky 30-39). Ak nie je vyplnené, predvolené je 31 – E-mail v zamestnaní. Parametr nie je povinný, ak nie je vyplnený a nie je ani vyplnená hodnota r_id_toso_recips, berú sa prednostne hodnoty z Adm33.

Miesto príjemca z Adm33 odoslať na e-mail osoby → r_id_toso_recips - zoznam osôb s možnosťou vybrať jednu konkrétnu. Parametr nie je povinný, ak nie je vyplnený, berú sa hodnoty z Adm33. Ponúkajú sa len živí používatelia aplikácie (pre cetpv.kmenovy = 1 platí, že aktuálny dátum je medzi dat_nast a dat_ukon).

3.26.11 101 Kontrola platnosti spôsobilosti podľa veku (zákaznícka hodnota)

Zákaznícka úloha, ktorá kontroluje zdravotné spôsobilosti podľa nastavení v číselníku Zpu03.

Nastavuje u nich údaje Platnosť do, Pozvať do, Perióda – ručná úprava.

Výpočet dátumu Platnosť do u poslednej platnej spôsobilosti vzniká kópií z dátumu predchádzajúce zhodnej spôsobilosti, a to hodnôt deň a mesiac.

Parameter: Prepočet platnosti do podľa aktuálne nastaveného parametra (jednorazová úprava). Tento parameter slúži pre jednorazový prepočet hodnoty Platnosť do v prípadoch, keď chce používateľ zmeniť podmienky pre výpočet dátumu pre položku Platnosť do, a to zmenou vstupného parametra "r_gener_platnost_do" tejto úlohy.

Parameter: Generovať platnosť podľa 373/2011 Sb. [CZ] nastavuje spôsob generovania Platnosti do. Pri nevyplnené a Áno sa chová tak, ako je popísané vyššie, pri nastavení na Nie, iba prepočíta periódu v závislosti na veku a Zpu03.

3.26.12 102 Generovanie požiadaviek zdr. / Psych. spôsobilosti (podľa Pozvať do)

Úloha vytvorená pre každodenné spúšťanie. Generuje požiadavky do Kva05f / Požiadavky - zdravotnej spôsobilosti pre Osoby / Pv ktoré majú definovanú platnú zdravotnú a psychologickú spôsobilosť v Kva01, a ktorej dátum Pozvať do je dnešným dátumom (tj. dátumom, kedy je úloha spustená).

Proces u požiadavke vyplní spôsobilosť a hodnotu Plán do (použije dátum Pozvať do zo spôsobilosti osoby).

Ak už uvedená požiadavka existuje, nie je generovaný.

3.26.13 103 Generovanie požiadaviek zdravotnej spôsobilosti (podľa Platnosť do a 50 let veku)

V rozmedzí od dátumu spustenia + 3 mesiace kontroluje osoby s platným PV, ktoré dosiahnu v tomto období vek = 50 rokov (pozri dátum narodenia).

Ak takú osobu v tomto časovom úseku nájde, dočasne ukladá dátum, v ktorom osoba dosiahla vek 50 rokov ako parameter pre porovnanie

Ďalej porovnáva tento dátum s najvyššou Platnosť do (pozri db tab <cehtosozpus>) u záznamov zdravotnej spôsobilosti (druh spôsobilosti = 31)

Ak je dátum Platnosti do zhodné alebo nižší ako dátum jubilea, potom túto Platnosť do prepisuje dátumom tohto jubilea.

3.26.14 104 Generovanie požiadaviek na per . školenie (podľa Pozvať do )

Úloha pre Periodické školenia robí to isté, čo robí úloha 102 pre zdrav . / Psych . spôsobilosti.

Tzn. spracuje spôsobilosti, ktoré majú Pozvať do = DNES a Platnosť do > = DNES a to pre spôsobilosť s druhom 12 - Periodické školenia.

Úloha je bez parametrov a je určená pre každodenné spúšťanie. Jej použitie predpokladá korektne vyplnené položky Pozvať do, Platnosť do.

Úloha je spúšťaná bez parametrov začiatku a konca určená na každodenné spúšťanie s parametrami umožňuje napr. mesačné spúšťanie.

Má tieto voliteľné parametre:

Začiatok vyhodnocovanie (počet dní pred dnešným dátumom):

Koniec vyhodnocovanie (počet dní pred dnešným dátumom):

Pr .: Vyplnenie 31 a -2 potom znamená testovať prepadnuté (vrátane predstihu tj. Pozvať do) v posledných 31 dňoch až do tých, ktoré prejdú za 2 dni.

Pri nevyplnenie oboch sa potom testuje to, čo má Pozvať do = DNES a je ešte platné teda Platnosť do> = DNES.

Skupina

Výpočet podskupín (ala Adm02)

Výpočet spôsobilosťou (len periodické)

Jej použitie predpokladá korektne vyplnené položky Pozvať do, Platnosť do.

Jej výsledkom sú Požiadavky na periodické školenia (Kva06, Kva07, Kva08).

3.26.15 105 Upozornenie na požiadavky na vzd. akciu

Upozorňuje na požiadavky, ktoré zostali v statuse 0 a 3, keď dnešný dátum > dátum Plán do.

Generuje e-mail autorovi požiadavky a zamestnancovi, o ktorom je požiadavka ( ak v Osb02 má zadaný e-mail do zamestnania) .

Týka sa požiadaviek s druhom spôsobilosti 11-21 a 41.

11 Znalosti a schopnosti

12 Profesijné periodické školenia

13 Znalostná moduly

14 Odborná spôsobilosť

21 Jazyky

41 BOZP

Úloha rešpektuje nepovinnú konfiguráciu adm21 / Vzdelávanie / Zoznam skupín pre workflow 3 Ak nie je vyplnená, týka sa akcia všetkých skupín.

(vzd_wfl3_skup_list)

3.26.16 106 Úprava platnosti zdravotnej spôsobilosti (prvý prepočet nad 50 rokov fixný)

Periodicky spúšťaná Úloha 101 kontroluje pri každej aktívnej zdravotnej prehliadke zamestnanca, či perióda preskúšania zodpovedá nastaveniu na SPU03 podľa aktuálneho veku zamestnanca. Nastavenie Zpu03 vychádza z ust. §11 vyhlášky č. 79/2013 Zb., kde sa konštanta 50 rokov veku vyskytuje v predpisoch periodických prehliadok väčšiny pracovných kategórií.

Úloha 106 má u vybraných klientov nahradiť používanie úlohy 101. Úloha 106 funguje rovnako ako úloha 101 s tým rozdielom, že pri aktívnych prehliadkach zamestnancov starších ako 50 rokov neupdatuje periódu preskúšania tých z nich, ktoré zamestnanec absolvoval pred dosiahnutím veku 50 rokov.

Podobne ako pri úlohe 101 je pre úlohu 106 na Adm53/Parametre (Formulárový pohľad) zaradený parameter “Generovanie platnosti do podľa 373/2011 Zb.”, ktorým sa Platnosť_do úlohou spracovávanej prehliadky upravuje v DD.MM. podľa zamestnancovej predchádzajúcej zdravotnej prehliadky rovnakého typu.

3.26.17 107 Generovanie požiadavky nadväzného periodického školenia

1) generuje požiadavku (Kva07/Periodické školenia)

- Plán OD = dátum spúšťania jobu,

- Plán DO = impl. maska 3.3.3333,

- povinná Spôsobilosť = hodnota nadväzného kurzu

pre všetky osoby s platným PV, ktoré majú dátum platnosti DO (druh_zpus = 12) < 3.3.3333 a zároveň je hodnota Náväzný kurz z a Zpu01 vyplnená.

2) ukončuje platnosť DO u osoby/pôvodného kurzu -> tým ho vyradí z ďalších kôl generovania, ale zostáva ďalej platný.

3.26.18 108 Požiadavka na zdravotnú spôsobilosť

Tento typ AS úlohy pri nastavení automatiky generuje požiadavku na zdravotnú spôsobilosť, ktorá sa následne prepíše na formulár Kva05f. Proces vygeneruje zoznam osôb, ktoré nemajú platnú zdravotnú spôsobilosť a vygeneruje pre nich nové žiadanky. Tento proces nahrádza funkcionalitu formulára Hod05, kde sa žiadanky museli vystavovať manuálne. Pri spojení procesu s Adm53 je to automatický proces, kde nie je nutné manuálne generovanie.

3.26.19 109 Vzdelávanie - automatizácia náhradníkov

Úloha 109, ktorá v používateľom určených časových intervaloch identifikuje voľné miesta na vzdelávacích akciách a v prípade, že také miesto bude nájdené a daný priebeh akcie bude evidovať zoznam náhradníkov podľa poradia, v akom sa ako náhradníci prihlasovali, bude meniť ich status z náhradníka na účastníka (zo stavu 9 na 4). Okrem parametrov začiatok a koniec vyhodnocovania (vzhľadom na dnešný dátum), možno špecifikovať Skupinu, výčet podskupín a prípadne aj výčet spôsobilostí, ktoré má sledovať."

3.26.20 110 Upozornenie na termíny adaptácie

Pomocou tejto úlohy sa spúšťa notifikácia na blížiace sa termíny adaptácie. V rámci parametrov je možné nastaviť predstih v dňoch, či chceme sledovať termíny čiastkových úloh alebo termín celého formulára. Tu je možné zvoliť sledovanie jednotlivých fáz. Predvolené nastavenie počíta iba so sledovaním úloh a 1. fázou adaptácie. Pre predlohy správ sú určené workflow akcie 630, 631,632, 633 na formulári Adm33.

3.26.21 111 Správa o termíne vyplnenia hodnotenia

Pomocou úlohy 111 je možné rozosielať upozornenia na blížiaci sa termín vyplnenia hodnotenia. Táto notifikácia je viazaná na nové hodnotenie s workflow na formulári Hod04. Ide o workflow akcie 82 až 87, kde na Adm14, v rámci nastavenia krokov wfl, slúži stav 55 ako predloha správy. Pri tejto úlohe je možné nastaviť niekoľko parametrov. Je možné nastaviť až 3 termíny upozornenia a ďalej, podľa checkboxov zodpovedajúcim wfl akciám, ktoré časti hodnotenia má úloha strážiť. Ide o hodnotenie osoby, hodnotenie úloh a hodnotenie kompetencií (u každého vždy sebahodnotenie a hodnotenie manažérom). Termíny vyplnenia sa zadávajú na formulári Hod11/Formulár/Ďalšie nastavenia.

3.27 Adm54 - Špeciálny audit

Formulár zobrazuje auditovanej situácia z oblasti štruktúr (Str01, STR02), zrážok (Sra01) a údajov o osobe (Osb01, Osb02)

a niektoré audítorskej údaje už zobrazované na Vyp01 / Audit resp. Adm11.

Okrem ďalej uvedených údajov je v zázname vždy kto a kedy zmenu urobil, prípadne o aký typ akcie išlo (vloženie, editácia, zmazanie).

Formulár používa prepínateľné navigačné zoznamy:

nav.sez. 1. Osoby

Záložky

Osoba - údaje:

Rodné číslo:

Celé priezvisko a meno:

Globálny identifikátor osoby:

Dátum od mena / priezviska:

Dátum do mena / priezviska:

Komunikácia - údaje z Vyp01 Audit / E-mail ale tu pre všetky druhy komunikácie

Zrážky - údaje

Zrážka: (ID)

Zložka mzdy:

Predčíslie:

Číslo účtu:

Kód banky:

IBAN:

Variabilný symbol:

nav.sez. 2. Osoby / PV

záložky z Vyp01

Audit / Platby

Audit / Tarifa

Audit / Pv

a z Adm11 / Zmazaná PV

nav.sez. 3 Bankové cesty - údaje

Banková cesta: (ID)

Číslo správnej jednotky:

Druh príjemcu:

Spôsob úhrady:

Spôsob zasielania prevod. príkazu:

Správny oddiel:

Nadriadený záznam za SJ:

Účet odosielateľa:

Forma sprievod. zoznamu hr. úhrady:

Číslo dávky prevod. príkazov:

Platnosť:

Účet hromadnej úhrady:

IČO hr. príjemcu:

Konšt. symbol hrom. úhrady:

Predčíslie hromadnej úhrady:

Banka hromadnej úhrady:

IBAN hromadného príjemcu:

BIC kód (SWIFT) hrom. príjemcu:

Špec.symbol hrom. úhrady:

Variabilný symbol hrom. úhrady:

Číslo zdravotnej poisťovne:

nav.sez. 4. Štruktúry - audituje zmeny prvku štruktúry a jeho väzieb

Odkaz na štruktúru:

Typ štruktúry:

Dátum / čas zmeny stavu:

Užívateľský kód:

Dátum vzniku (evidenčne):

Dátum zániku (evidenčne):

Hladina-ručná úprava:

Číslo skupiny riadkových práv:

Viaže sa na prvok štruktúry:

Nadriadený typ štruktúry:

Kód nadriadeného záznamu:

Dátum od väzby:

Dátum do väzby:

3.28 Adm55 – API a prostriedky

Formulár Adm55 umožňuje nastaviť konfiguráciu implementovaných API a prostriedkov poskytovateľov služieb pre oblasť elektronických podpisov, identifikácie a doručenia. Konfigurácia API a ich prostriedkov bude využívaná na realizáciu plánovaných funkcionalít nových, samostatne uvoľňovaných komponentov pre elektronické podpisy (spoplatnená oblasť) a elektronického podania.

Záložka API

Táto záložka obsahuje základné parametre rozhrania pre jednotlivé prostredia (Konfigurácia API). Ide o parametre potrebné na pripojenie k danému rozhraniu – URL, port, požadovaný typ šifrovania dát, typ autentizácie a autentizačný kľúč, prístupový účet a heslo atďV prípade definície API podpisových prostriedkov je potrebné vyplniť Poskytovateľa (parametrizácia API pre podpis Dokumentov PV je popísaná v dokumentácii ElPo_uzdoc)Záložka Prostriedky

Jednotlivé rozhrania môžu poskytovať set služieb, ktoré zaisťujú pre dané oblasti elektronickej komunikácie medzi subjektmi. Tieto pre dané API definujeme na záložke Prostriedky. Súčasťou je aj priradenie organizácie a SJ, ktoré môžu daný prostriedok využívať.

Parametre

Na úrovni API, Prostriedkov i priradených Organizácií a SJ je možné dynamicky nastaviť ďalšie parametre potrebné na využívanie služieb daného API. Napr. ide o tokeny, ďalšie URL (napr. pre autentizáciu). Hodnoty týchto parametrov je možné evidovať v nešifrovanom alebo šifrovanom režime.

Konkrétne nastavenia pre jednotlivé API a ich prostriedky sú súčasťou implementačných pokynov viazaných na funkcionality EGJE, ktoré využívajú tieto služby.

Odporúčané nastavenia pre elektronické podanie VREP na ČSSZ. Kódy API, konfiguráciu API, prostriedky API sa odporúča používať podľa nasledujúcej tabuľky buď na testovacie, alebo produkčné účely. API prostriedky musia mať platný záznam pre ORG a SJ, pre ktoré sa bude elektronické podanie spracovávať.

Adm55 - API		Adm55 - Konfigurace API		Adm55 - Prostredky API
KOD API	API Api poskytovatel	CFG typ prostredi	CFG URL	Prostredek oblast	Prostredek typ_služby	Prostredek metoda
VREP SUBMIT	1 - VREP CSSZ	20-testovaci	https://t-epodani.cssz.cz/VREP/submission	3	32	320
VREP POLL	1 - VREP CSSZ	20-testovaci	https://t-epodani.cssz.cz/VREP/poll	3	33	330
VREP SUBMIT	1 - VREP CSSZ	40-produkční	https://epodani.cssz.cz/VREP/submission	3	32	320
VREP POLL	1 - VREP CSSZ	40-produkční	https://epodani.cssz.cz/VREP/poll	3	33	330

Odporúčané nastavenia agendy ISDS. Odporúčame používať kódy API, konfiguráciu API, prostriedky API podľa nasledujúcej tabuľky. API prostriedky musia mať platný záznam pre ORG a SJ (Adm55 - API prostriedky - nižšie), pre ktoré sa bude agenda ISDS spracovávať. Od verzie e202311 je možné spracovať výzvy ISDS prijaté z úradu práce v EGJE ručne podľa popisu v zmenovej dokumentácii.

Adm55 - API		Adm55 - Konfigurace API		Adm55 - Prostredky API
KOD API	API poskytovatel	CFG typ prostředí	CFG URL	Prostředek oblast	Prostředek typ služby	Prostředek metoda
ISDS	2 - ISDS	40-produkční	Prázdne (bude dopnené pre potreby ISDS v budúcnosti)	3	30	300

Pre komunikáciu cez dátovú schránku je potrebný certifikát ISDS na zabezpečenú komunikáciu medzi servermi. Tento certifikát môže byť načítaný z dátových štruktúr EGJE alebo môže byť uložený a načítaný zo systémového úložiska. Ak sa na uloženie certifikátu ISDS použije systémové úložisko, cesta k adresáru s certifikátom je evidovaná v atribúte API\Konfigurácia API: Cesta k úložisku certifikátu (CA). Ak je certifikát chránený heslom, heslo je evidované v rámci atribútu Heslo k certifikátu (CA). Povinný názov certifikátu v systémovom úložisku je: pre produkčné prostredie isds_prod.jks, pre testovacie prostredie isds_test.jks.

ePN (SK) - služba B2B Sociálnej poisťovne

Doporučené nastavenie pre agendu ePN (SK) - služba B2B Sociálnej poisťovne. Nastavenie obsahuje URL adresy, pre ktoré je nutné povoliť komunikáciu z EGJE (firewall, proxy). Uvádzame koreňové URL z dôvodu, že v medzikroku sa získava access token z inej vetvy URL adresy, ako samotná komunikácia (viď nižšie konfigurácia a parametre):

· esluzby.socpoist.sk pre produkčné použitie

· test.socpoist.sk pre prípadné testy (toto prostredie je určené pre SW spoločnosti)

Adm55 - API		Adm55 - Konfigurace API		Adm55 - Prostredky API
KOD API	API poskytovatel	CFG typ prostředí	CFG URL	Prostředek oblast	Prostředek typ služby	Prostředek metoda
SpSkB2B	200	40-produkční	https://esluzby.socpoist.sk/portal/b2b/	3	32	prázdne

Dalšie parametre API

Pre každé prostredie je definovaná sada technických parametrov. Pre produkčný beh je to nasledujúci zoznam. Adm55-Prostriedky - parametre priradenia prostriedku (pre každú SJ samostatne):

Typ parametru	Hodnota parametru
52 - API Call AuthValue	ICZ zaměstnavatele (pro identifikaci klienta)
20 - OFFLINE token	Token získan z portálu SP

Na funkčné pripojenie k SP (SK) je potrebné na strane klienta poskytnúť offline token na autentifikáciu k uvedenej službe. Viď https://esluzby.socpoist.sk/portal/swagger-ui/index.html#/Elektronick%C3%A1%20PN.

Potom zadajte do skriptom pripraveného parametra (vyplňte pole hodnota parametra, alebo hodnota parametra zašifrovaná podľa aktívnej položky). Adm55 - Vyplňte hodnotu parametra prostriedku (pre každú SJ zvlášť) ručne:

· AuthValue - ICZ zamestnávateľa, (alebo iný dodaný identifikátor na tento účel)

· Offline token - token z portálu SP podľa pokynov SP.

Adm55 API – Parametre API (odlišuje sa len URL podľa typu prostredia):

Typ parametru	Hodnota parametru	Prostredie
40 - URL pro autentizaci	https://esluzby.socpoist.sk/idm/auth/realms/b2b/protocol/openid-connect/token	P
40 - URL pro autentizaci	https://test.socpoist.sk/idm/auth/realms/b2b/protocol/openid-connect/token	T
1 - Autentizace Client ID	b2b	P,T
41 - Autentizace Grant_type	refresh_token	P,T
50 - API Call Content-Type	-H "Content-Type: application/json"	P,T
51 - API Call Authorization	-H "Authorization: Bearer ${acces_token}"	P,T

Parametre bolo možné importovať do Adm51 pomocou inicializačného skriptu distribuovaného s verziou 202405.

Vo verzii 202409 sú nastavenia API vyplnené plošne automaticky inštalačným skriptom. Účelom je vyhnúť sa chybám pri ručnom vypĺňaní.

Poznámka: Na nastavenie funkčného podania ePn SK sú nastavenia Adm60 Adm28 a Adm55 prepojené z dôvodu vzájomnej väzby.

3.29 Adm56 – Definícia pomocníka

Formulár Adm56 slúži na definovanie pomocníka, ktorá sa zobrazí pri zvolenom zobrazovanom elemente na formulári.

Upozorňujeme, že toto je zatiaľ pilotná funkčnosť a zobrazenie sa bude ešte v priebehu času upravovať podľa zistených možných problémov a požiadaviek zákazníkov. Ako prvá sa táto funkcionalita bude optimalizovať pre formuláre týkajúce sa daňových formuláru (Dan31, Dan32, Das31 a Das32). Je možné, že by mohlo vďaka zobrazeniu alebo naopak nezobrazeniu „Pomocníka“ dôjsť k posunutiu zarovnania riadkov či textov. V takom prípade, ak sa nebude toto zobrazenie páčiť, je možné doplniť chýbajúcu nápovedu pre tento riadok, napríklad len nápoveďou s popisom názvu poľa.

Je čisto na uvážení zákazníka, či bude chcieť tiež popisovať celé bloky, ktoré môžu spôsobiť posunutie zobrazenia na celej stránke. Takýto blok ide jednoducho identifikovať, pretože má vedľa seba nápis pomocníka.

Formulár obsahuje v pravej časti navigačný zoznam s výberom formulárov, pre ktoré ide nadefinovať pomocníka. Ďalej potom v hornej časti je zoznam, elementov zvoleného formulára. Po kliknutí na tento element sa dá vytvoriť popis v k nemu definovanom jazyku. Pokiaľ je takto vytvorený popis uložený, funkcionalita zaistí, že sa pri danom elemente na formulári vytvorí ikonka, na ktorú sa dá kliknúť a daný sa popis sa zobrazí ako pomocník k danému formulárovému elementu. Celá funkcionalita bude funkčná od verzie e202311, kde sa dodá automatické zobrazovanie nápovedy na formulároch, ktoré budú mať túto nápovedu nadefinovanú na Adm56.

Všeobecný postup

• v navigačnom zozname vybrať formulár, na ktorom sa má vytvárať pomocník

• v hornom zozname sa načítali všetky položky z vybraného formulára z navigačného menu a kliknutím na danú položku formulára, sa položka označí na editáciu pomocníka

Obsah obrázku text, snímek obrazovky, software, displej

Popis byl vytvořen automaticky Pokiaľ už existuje pri položke popisok s pomocníkom, bude možné ju editovať, inak iba zadať nový popisok pomocníka

· následne sa vyberá jazyk popisku zo zoznamu (rolldown menu)

· Do poľa „Popis:“ sa zadáva popis nápovedy vo zvolenom jazyku (k jazykovej kontrole nedochádza, takže pokiaľ je vybraný jazyk a popis mu nezodpovedá, bude takto nápoveda uložená do DB

Pozn. V prípade, že neexistuje preklad pre AJ mutáciu, bude zobrazená nápoveda v CZ jazykovej mutácii.

Poznámka:

čo je hotovo:

• záložky

• pole na ploche (v maľbe)

• hlavičky tabuliek

Ďalšie komponenty sa budú dodávať v nasledujúcich verziách.

Pre formulár bol zakázaný Export pomocou ponuky vyvolanej pravým tlačidlom myši.

3.30 Adm57 – Overenie

Nový formulár umožňuje nastaviť konfiguráciu autentizácie WS, ktorá sa až do verzie e202401 dala nastaviť iba v konfigurátore. V ňom teraz možno nastaviť, kde sa má WS overovať. Či v aplikácii (t.j. tu na formulári Adm57), v konfigurátore, alebo prípadne oboje – popísané v rámci samostatnej dokumentácie EGJE_WS_provdoc. Na Adm53 je potom možné vybrať autentifikáciu pre konkrétnu Rst zostavu – viď 3.26.3.

Formulár obsahuje zoznam autentifikácií a detailný formulár pre zadanie a editáciu nastavenia. Povinné položky na založenie záznamu sú Kód (ktorý musí byť jedinečný v rámci tohto formulára a nastavenia), Overenie (ktoré sa riadi číselníkom CisAuth) a platnosť záznamu. Podľa číselníka Spôsob overenia sú konfiguračné parametre rozdelené do troch oblastí: NT Login/2 JCIfs, LDAP a APIKey a dynamicky menia zadanie detailu vybranej konkrétnej autentizácie. Pri záznamoch, ktoré sú definované ako NTL* a mswin_ntl*, je možné v rámci položky Účet počítača pre pripojenie k DC (NT Login2) – Heslo definovať konfiguračné parametre pre tvorbu a editáciu hesla – popísané v dokumentácii v časti 3.37.1. Rovnakým spôsobom je možné definovať tieto konfiguračné parametre aj pri záznamoch definovaných ako API key, a to v prípade položky API – Heslo.

Ako vyplniť položky v rámci jednotlivých autentizácií je popísané v rámci EGJE_provdoc, časť Overenie.

3.31 Adm58 – nastavenie notifikácií na daňové zľavy

Tento formulár slúži na nastavenie sledovania končiacich daňových zliav zamestnancov. Je funkčne prepojený s Kon07, kde sa spúšťa spracovanie a vyhodnotenie končiacich daňových zliav.

Na Adm58 sa skladá zo zoznamu, kde sa zobrazujú nadefinované daňové zľavy, ktoré sa majú vyhodnocovať ak napojeniu na odosielanie notifikácií, ktoré prebieha pomocou nastavenia workflow na Adm33, kde sú definované konečné statusy pre odoslanie notifikácií.

Adm58 používa štandardné tlačidlá aplikácie EGJE na vytvorenie, editáciu či zmazanie nastavených zliav a ich parametrov.

Na Adm58 sa ďalej nachádza tieto polia:

Formulár – Slúži na výber oblasti z akej sa majú kontrolovať daňové zľavy (napr.: Dan/Das01)

Vyber zľavu – toto pole slúži na výber sledovanej daňovej zľavy a ide nastaviť sledovanie týchto zliav

• 1 – Študent

• 2 – Dieťa

• 3 – Dieťa ZŤP/P

• 4 – Invalidita 1. alebo 2. stupňa

• 5 – Invalidita 3. stupňa

• 6 – Držiteľ preukazu ZŤP/P

Zadaj názov – pole slúži k možnosti užívateľského pomenovania danej zľavy

Akcia workflow – v tomto poli sa zadáva workflow, ktoré bude odosielať dané nadefinované notifikácie na email (napr.: pre Dan/Das01 je to WFL67).

Konečný status – toto pole je späté s daným WFL a definuje sa v ňom telo odosielanej notifikácie. Definícia prebieha na Adm33 pre danú akciu workflow. Tu sa ponúkajú už nadefinované konečné statusy WFL.

Zadaj jednotku času a hodnota – v týchto poliach sa definuje jednotka času a v spojení s hodnotou (následné pole) toto definuje, aký časový úsek dopredu sa má zasielať notifikácia

Na výber je:

• Minúta

• Hodina

• Deň

Do následného poľa Hodnota sa zadá číselný údaj

3.32 Adm60 – Parametrizácia podania

Jednotlivé procesy e-Podania sú definované sledom krokov a setom parametrov, ktoré špecifikujú náležitosti daného procesu. Čo je predmetom podania (formát, obsah a štruktúra dát, ktoré sú zasielané/prijímané), akým komunikačným kanálom výmena dát prebieha (ISDS, API), voči akému subjektu komunikácie prebieha, aké sú požiadavky na zabezpečenie komunikácie, čo sa požaduje auditovať atď.

Formulár Adm60 „Parametrizácia podania“ je určený pre definíciu nastavenia jednotlivých podaní, ktoré je potom nadväzne využívané jednotlivými metódami EGJE zaisťujúcimi túto komunikáciu s tretími stranami.

Navigácia

Zoznam podaní

Záložka Detail podania

Obsahuje základné nastavenie podania ako celku:

- Externá organizácia: adresát podania (zoznam podaní je pre daného používateľa filtrovaný podľa priradenia organizácie k legislatíve)

- Pobočka: určenie pobočky organizácie, ktorá podanie rieši

- Agenda podania: širšia oblasť podania, pod ktorou môže spadať viac jednotlivých podaní (formulárov)

- Druh podania: konkrétny predmet podania (formulár podania)

- Komunikačný kanál: API, DS

- Externý kód podania: kód, pod ktorým je podanie (formulár) evidovaný na strane organizácie, ktorej je podanie smerované

- Názov a Popis podania

Záložka Kroky

Samotné podanie môže prebiehať v niekoľkých krokoch, napr. stiahnutie výzvy na doloženie dát a odpoveď na výzvu (odoslanie požadovaných dát). Na záložke Kroky je pre každý krok nastavené, cez aké rozhranie prebieha komunikácia (väzba na definíciu API na Adm55), akým spôsobom je definované podacie miesto a ďalšie kategorizačné náležitosti kroku (typ kroku, poradie, názov, popis)

Parametre podania, Parametre kroku

Na úrovni podania aj jeho krokov môžu byť nastavené ďalšie špecifické požiadavky na parametrizáciu procesu v rámci podania ako takého, alebo jeho konkrétneho kroku. Napr. požiadavky na zabezpečenie dát (šifrovanie, podpis) a súvisiace požiadavky na certifikát, ktorý má byť k tomuto použitý, požiadavky na auditovanie atď.

Táto parametrizácia e-podania je úzko naviazaná na metódy a zostavy EGJE implementované pre jednotlivé podania, preto nastavenie parametrizácie e-Podanie na Adm60 je metodicky plne v správe Elanor a.s. a prípadné zmeny nastavenia by mali byť vždy realizované len na základe implementačného pokynu.

Nasleduje doporučené nastavenie pre agendu ePn SK (opis parametrov ktoré sú plnené inicializačným skriptom dodaným vo verzii 202405. Poznámka: Pre úplné nastavenie podania ePn SK je potrebné naimportovať skriptom, alebo zadať všetky nastavenia Adm60, Adm28 a Adm55

Adm60 - Detail	Záznam č 1	Záznam č 2
Externí organizace	Sociálna poisťovňa (SK)	Sociálna poisťovňa (SK)
Pobočka	Sociálna poisťovňa (SK)	Sociálna poisťovňa (SK)
Agenda podání	200 - Sociálna poisťovňa SK (ePN)	200 - Sociálna poisťovňa SK (ePN)
Komunikační kanál podání	10 - API	10 - API
Druh podání	200 - SpSK - ePn Seznam	201 - SpSK - ePn Detail
Externí kód podání	SpSkEpnSeznam	SpSkEpnDetail
Název podání	Soc. Poisťovňa SK Epn Zoznam	Soc. Poisťovňa SK Epn Detail
Zkratka názvu	SpSkEpnZoznam	SpSkEpnDetail
Popis podání	Zoznam aktualizovaných PN získaných za každý deň osobitne	Detailný výpis PN podľa IDPN
Platnost od	1.1.1910	1.1.1910
Platnost do	3.3.3333	3.3.3333
Suffix podání pro API	epn/epn/	epn/epn/${ID_PN}
Adm60 – Parametry podání
Typ parametru	24 - Data podání - ID položky
Specifikace parametru	responsedata
Audit parametru	1 - Auditovať nešifrovane
Adm60 - Kroky podání
Prostředek API	B2B služba Sociálna Poisťovna (SK)	B2B služba Sociálna Poisťovna (SK)
Typový krok podání	Dotaz na dáta	Dotaz na dáta
Pořadí kroku	1	1
Název kroku	Zoznam PN k datumu (GET ePn )	Dotaz na dáta (GET ePn ID)

3.33 Adm61 - Dávky tlačových zostáv

Častým prípadom hlavne v mzdovej praxi býva periodická tlač viacerých zostáv.

Dávku tlačových zostáv je možné v tomto konfiguračnom formulári vytvoriť, pomenovať a zaradiť do menu.

V menu potom môže aj iný používateľ (ak mu pridelená práva) spúšťať takto pripravenú dávku, pričom parametre všetkých zostáv zadáva naraz.

Podľa položky "Zoskupovať parametre zostáv" sú zostavy prezentované:

Áno – ako združené, tzn. parameter so zhodným interným názvom v dávke používateľ vypĺňa len raz a je platný pre viac zostáv

Nie - každá zostava v dávke má svoj odsek a v ňom všetky svoje parametre. Táto voľba sa hodí napríklad v prípade, že chceme do dávky dať jednu zostavu viackrát a zakaždým ju spúšťať s inými parametrami (typicky za inú štruktúru).

Pozn. Viac obvyklé je nezoskupovanie parametrov.

Špeciálnym prípadom sú Typ dávky zostáv

2 - Serverová dávka ADP s možnosťou serverových úložísk

3 - Serverová dávka Elanor s možnosťou serverových úložísk

Tieto dávky majú pri spúšťaní navyše špeciálnu hlavičku so spoločným zadaním organizácie, obdobia od a do a SJ.

Dávky sa spracovávajú na serveri a súbory v nich majú špeciálne pomenovanie. Výsledkom dávky je zip súbor tiež s pomenovávaciami pravidlami a ten býva umiestňovaný do úložiska "Iné". To má AS mapované pomocou údaje Ftp02 - Iná zložka na výmenu súborov (mimo Ftp01) - prístup z AS.

K rozlíšení zákazníkov outsourcingu na režim EZM štandard, ADP a NGA sa používa údaj:

Adm21 / EZM / Typ zákazníka EZM.

0-EZM štandard

1-ADP

2-NGA

U outsourcingového režimu ADP, NGA EGJE uplatňuje iné pravidlá pomenovania vytvoreného súboru zostavy aj keď mzdová účtovníčka zostavu tlačí mimo dávku Elanor. Ale keďže pri tomto spúšťaní nie sú k dispozícii hodnoty parametrov z hlavičky dávky, je ich vyplnenie možné iba v prípade, že sú tieto parametre obsiahnuté priamo v zostave a sú štandardne pomenované.

Pre serverovú dávku NGA (podľa obrázku: typ 4 a objekt 4) pribudlo pole s názvom „Zip v zipse s názvom podľa poradia zostavy“. Do tohto poľa ide zadať číslo zostavy a názvoslovie sa bude riešiť podľa poradia zostavy v dávke (na záložke Adm61  Zostavy). Toto pole tiež zaisťuje, že bude vytvorený zipsovaný súbor, ktorý bude v sebe obsahovať ďalší zips s výstupom/výstupmi zostáv.

Obsah obrázku text, snímek obrazovky, software, číslo

Popis byl vytvořen automaticky

Pre 0-EZM štandard ešte v Adm02 / Profil / Právo k riadkom - ďalšie objekty existuje položka

"Alt. Kód organizácie pre súbory 0-EZM štandard"

Pokiaľ ho správca vyplní, je tento kód používaný u používateľa prihláseného na tento profil miesto kódu organizácie z Adm21 / Údaje / Kód organizácie. Týka sa to názvové konvencie pomenovania balíka i jednotlivých zostáv v dávkach typu 0-EZM štandard.

Hlavným účelom je možnosť špecifikovať v rámci organizácie ďalšie delenia príjemcov dávok, či už je to cez SJ alebo cez nejaké rozdelenie pomocou štruktúr.

3.33.1 Serverové dávky

Toto je rozšírenie pre používateľa internej výmeny súborov Ftp01 (viď nasledujúca kapitola). Je prevádzkovateľné pri práci cez AS alebo EGJEWeb .

U definície dávky zostáv zostavovanej v Adm61 môžeme vyplniť tieto položky :

Typ dávky zostáv:

1 - Serverová dávka s možnosťou serverových úložísk

2 - Serverová dávka ADP s možnosťou serverových úložísk

3 - Serverová dávka Elanor s možnosťou serverových úložísk

4 - Serverová dávka NGA s možnosťou serverových úložísk

Užívateľ smie prepísať serverové cesty (iba pre typ 2)

Pokiaľ u dávky zostáv zadáme, že je Serverová, bude jednak vykonávaná na AS a ďalej sa potom jej produkty uloží na serverové úložisko definované vo Ftp02 .

Presnú špecifikáciu uloženia potom zadávame jednak pri zadávaní zostavy do dávky, tu v Adm61, respektíve, ak je u dávky zaškrtnuté aj " používateľ smie prepísať serverové cesty ", tak môže tieto údaje používateľ meniť aj pri spúšťaní dávky. Vždy sa však môže rozhodnúť, či dávku púšťa cvične alebo či naozaj už sa má na server uložiť (vrátane prípadných notifikácií vo Ftp02 definovaným príjemcom).

Pre milovníkov zložitých projektov a protokolov je vo Ftp02 ešte ďalší atribút " Iná zložka pre výmenu súborov ( mimo Ftp01 ) - prístup z AS " a u definície zostavy v dávke je checkbox

" Uložiť do Ďalšie serverové zložky ", ktorý vytvorený súbor (resp. protokol exportu / importu) ešte navyše uloží do ďalšieho adresára a tu sa dá aj definovať, že pod iným názvom (parameter " Názov súboru ( bez cesty ) pre Inou zložku " ) .

3.33.2 Serverová dávka ADP, ELANOR, NGA s možnosťou serverových úložísk

Tieto typy dávok používajú tzv. iné úložisko definované vo Ftp02 a zostavy pomenúva podľa špeciálnych algoritmov ADP/ELANOR/NGA. Do úložiska je umiestni ako ZIP súbor(y).

Pričom ZIP s výplatnými lístkami je vždy samostatný. Podporu pre ZIP s VL majú VL zostavy Vyp11fq a Vyp31fq. Pri zaradení do dávky ponúkajú špeciálny formát 10 - "Výstup do PDF zip".

Dávka je všeobecná a môže obsahovať aj exporty. Tie však často generujú viac typov súborov naraz, z ktorých nie všetky majú ísť do výstupu. K ich špecifikáciu slúži položka "Maska súborov ukladaných na server (maska s *?) - Iná sl .:", ktorá z vytvorených súborov filtruje len tie, ktoré do dávky patrí.

To sa týka dávok VL aj dávok ostatných zostáv a exportov.

Poznámka:

U všetkých typov serverových dávok si používateľ volí Výstupný formát zostavy. Zatiaľ čo u interaktívneho spúšťanie zostavy je formát XLS / XLSX / CSV určený podľa lokálneho nastavenia používateľa, tak u serverových dávok je výhodnejšie zadať konkrétne formát priamo v zadaní dávky, tzn. jeden z typov:

5 - Výstup do XLSX (iba dáta)

9 - Výstup do CSV (iba dáta)

11 - Výstup do XLS (iba dáta)

U voľby 4 - Výstup do XLS / XLSX / CSV (iba dáta) je formát určený z nastavenia klienta, ktorý dávku spúšťa. Túto voľbu teda neodporúčame.

Odporúčanie: Kódy dávok v Adm61 robte krátke, inak sa u dávok Elanor nezmestia do maximálnej dĺžky názvu súboru ZIP a budú rôzne skracované. Nepoužívajte v nich tiež diakritiku a niektoré problémy odpadnú, keď v nich nebudú ani medzery.

3.34 Adm62 - Správa žiadaní o dokument

Na formulári Adm62 správcu nastavuje zoznam dokumentov (zostáv), o ktoré možno žiadať (formulár Osb62) a ktoré možno referentom či mzdovú účtovníčku (ďalej len MU) pomocou tohto nového aparátu vystavovať (formulár Vyk62).

Ide o:

žiadosť o zostavu, ktorá ako jeden z parametrov má Osobu alebo Osobu / PV (žiadosť zamestnanca),
alebo o vystavenie dokumentu bez žiadosti, kde je vyplnené "Iný dokument od organizácie bez žiadania (napr. Hromadný ELDP) = Áno" (MU generuje súbor bez žiadosti).
možnosť vystaviť zostavy, ktoré sa tlačia priamo z formulárov (v súčasnosti Dan/Das36)

Ide o súčasť samostatného okruhu, viac informácií v dokumentácii Zam_dok_uzdoc.

3.35 Adm63 – Validácia vstupných polí

Tento formulár slúži na kontrolu nastavených regulárnych výrazov, nastavených na kontrolu vstupných polí. Funkcionalita beží v pilotnej prevádzke a bude ešte naďalej optimalizovaná. Táto kontrola bude fungovať aj pre AreaTextEditor, čo je viacriadkový editor. Regulárne výrazy sa načítajú pri spustení Aplikácie / Aplikačného Servera / WEB Servera a uložia sa do pamäte (nakešujú sa). Prenačítať sú buď reštartovaním aplikácie alebo na formulári Adm51  záložka Zmena DB  tlačidlo „Prenačítať“ pri poli s názvom Prenačítať repository na všetkých AS / EGJEWEB(2):

Na Pkz11fkb nie sú štandardné daformy, ale zmeny sa vykonávajú pomocou param. panelu v dialógu a teda tam chýba priama väzba na položku v tabuľke, kde je uložená nápoveda, preto je pridaná ďalšia kontrola v systéme, takže sa zle zadaná položka kontrolovaná regulárnym výrazom neuloží, ale vyskočí chybové hlásenie:

V rôznych častiach aplikácie toto môže mať mierne inú podobu, ale dôležité je, že sa chybná hodnota neuloží do DB. U štandardných. formulárov sa táto hláška nevyskytuje a nepovolené znaky sa nedajú ani zadať.

Je tu mierny rozdiel v správaní na Tlstom a WEB klientovi.

Tučný klient:

- v prípade že hodnota položky nespĺňa regulárny výraz (napr. u už skôr uloženého textu), tak sa nenačíta a zobrazí sa prázdne pole. Pokiaľ užívateľ spustí editáciu a potom sa pokúsi uložiť, uloží sa opäť len prázdna hodnota a pôvodný text je stratený.

Web klient:

- na WEB klientovi sa hodnota normálne zobrazí, ale pri úprave už nepôjde uložiť

Treba myslieť aj na to, že v správach pre workflow sa pre makrá používa znak %, takže ho musí regulárny výraz povoľovať a zároveň pokiaľ správa obsahuje HTML znaky, napr. <>\=, musia byť povolené aj tieto znaky.

Obsahuje navigačný zoznam, zobrazujúci tabuľky databázy. Po výbere tabuľky, sa do zoznamu na formulári načítajú detaily o všetkých položkách, do ktorých sa zadávajú dáta a je možné nastaviť regulárny výraz pre kontrolu vstupnej hodnoty pre vybranú položku. Toto zodpovedá 1. fáze vývoja.

Pretože je ale zadávanie regulárnych výrazov veľmi zložité, nadväzuje na tento formulár 2. fáza vývoja, ktorá umožní vyberať z nadefinovaných podmienok a nebude tak nutné priamo generovať regulárny výraz kvôli jeho zložitosti.

3.35.1 Tlačidlo „Prenačítať repository“

Toto tlačidlo zaistí, pri zadaní nového regulárneho výrazu, pre načítanie tohto výrazu do cache (repository). Tieto regulárne výrazy a kontroly sú pri spustení aplikácie EGJE prednačítané do cache, čo spôsobovalo, že po zadaní novej kontroly bolo nutné aplikáciu ukončiť a znova spustiť, aby sa nový regulárny výraz stal aktívnym a načítal sa cache aplikácie. Teraz po zadaní nového výrazu alebo jeho zmene stačí repository pre načítať tlačidlom. Daný formulár, pre ktorý je regulárny výraz určený sa musí zavrieť (ak je otvorený) a spustiť znova. Ale nie je nutné aplikáciu ukončovať.

3.35.2 Kontextové volanie

Pribudlo kontextové volanie na regulárny výraz definovaný na Adm64. Pokiaľ je zvolený regulárny výraz na Adm63 definovaný na formulári Adm64, ide pomocou kontextového menu zavolať a prejsť na formulár Adm64, kde je definovaný

3.36 Adm64 - Regulárne výrazy na overovanie vstupných polí

Formulár Adm64 slúži rovnako ako Adm63 na zadávanie regulárnych výrazov pre overovanie vstupných polí.

Rozdiel medzi týmito formulármi spočíva v tom, že Adm64 umožňuje zadať sadu regulárnych výrazov, ktoré následne možno vybrať z rolovacieho menu na formulári Adm63. Naopak, Adm63 umožňuje zadanie iba konkrétneho regulárneho výrazu pre jedno vstupné pole.

Formulár Adm64 je teda určený na správu regulárnych výrazov.

Z formulára Adm64 funguje kontextové volanie na formulár Adm63, ktoré sú funkčne prepojené.

Tu je prehľad základných regulárnych výrazov a ich definície:

3.36.1 Čo je regulárny výraz?

Regulárny výraz (anglicky regular expression, často skrátene regex) je špeciálny spôsob zápisu textových vzorov, ktorý slúži na vyhľadávanie, porovnávanie alebo úpravy textu. V podstate si ho môžeme predstaviť ako „inteligentnejšie“ hľadanie textu s využitím určitých pravidiel a zástupných znakov.

3.36.2 Zástupné znaky (metaznaky)

Regulárne výrazy používajú rôzne symboly, ktoré majú špeciálny význam. Niektoré základné:

• "." (bodka) – predstavuje akýkoľvek znak.

• "*" (hviezdička) – znamená "nula alebo viac výskytov predchádzajúceho znaku".

• "?" – znamená "nula alebo jeden výskyt predchádzajúceho znaku".

• "[]" – skupina znakov, ktoré chceme povoliť.

• "^" – značí začiatok riadku alebo textu.

• "$" – značí koniec riadku alebo textu.

Príklad s metaznakmi: Pokiaľ chcete nájsť všetky slová, ktoré začínajú na "k" a majú akýkoľvek jeden ďalší znak, napr. "ka", "ko", "ki" a pod., použili by ste regulárny výraz: "k.". Bodka tu nahrádza akýkoľvek znak.

3.36.3 Základné regulárne príkazy

· [a-z] – definuje iba malé písmená abecedy (príklad: abeceda)

· [a-zA-Z] – definuje malé a veľké písmená abecedy (príklad: AbeCeda)

· [0-9] – definuje iba čísla od 0 do 9 (príklad: 123458)

· [a-z0-9] – definuje malé písmená abecedy a čísla od 0 do 9 (príklad: abeceda123)

· [a-zA-Z0-9] – definuje malé a veľké písmená abecedy a čísla od 0 do 9 (príklad: Heslo123)

Tieto regulárne výrazy môžu byť rôzne kombinované. Ale každá kombinácia bude obsahovať zložitejší regulárny výraz.

Ako príklad je uvedený regulárny výraz pre definíciu hesla, ktorý obsahuje podmienky. Heslo musí obsahovať:

• malé a veľké písmená

• číslo

• špeciálny znak z sady (!@#$%^&*)

• minimálna dĺžka je 8 znakov

Takýto regulárny výraz môžeme zostaviť takto:

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*])[A-Za-z\d!@#$%^&*]{8,}$

Vysvetlivky:

• ^ – začiatok reťazca

• (?=.*[a-z]) – zaisťuje, že heslo obsahuje aspoň jedno malé písmeno

• (?=.*[A-Z]) – zaisťuje, že heslo obsahuje aspoň jedno veľké písmeno

• (?=.*\d) – zaisťuje, že heslo obsahuje aspoň jednu číslicu (zástupný znak pre číslo je \d).

• (?=.*[!@#$%^&*]) – zaisťuje, že heslo obsahuje aspoň jeden špeciálny znak z definovanej sady !@#$%^&*.

• [A-Za-z\d!@#$%^&*]{8,} – povoľuje iba znaky malej a veľkej abecedy, číslice a špeciálne znaky, a zároveň zaisťuje, že heslo má aspoň 8 znakov.

• $ – koniec reťazca.

3.36.4 Zhrnutie:

Regulárny výraz je mocný nástroj, ktorý dokáže vyhľadávať a manipulovať s textom pomocou špeciálnych vzorov. Namiesto obyčajného hľadania slova vám umožňuje definovať pravidlá, aké textové vzory chcete nájsť alebo definovať vzor, ako má text v danom poli vyzerať, definovať písmená, čísla alebo znaky, ktoré môžu byť vložené.

3.36.5 Upozornenie

Regulárne výrazy sú naozaj mocný nástroj, ale pri zlom zadaní alebo ich zlej znalosti je možné týmto nástrojom znemožniť zadanie validnej hodnoty do potrebného poľa. Odporúčaním je konzultovať so systémovým administrátorom pred vložením či umiestnením regulárneho výrazu ako definícia na formulári Adm64 a jeho napojením do systému na formulári Adm63.

3.37 Adm70 – Konfigurácia

Formulár umožňujúci nastavovanie konfiguračných položiek v rámci celého EGJE s väzbou buď na aplikáciu alebo príslušnú organizáciu, správnu jednotku alebo správny oddiel (riadené číselníkom konfig_typ). Položky sú definované číselníkom konfig_nazov a sú združované do skupín podľa hodnoty kód 2 – viď tabuľka nižšie.

Rovnakým spôsobom sú definované aj typy konfiguračných položiek (v tomto prípade sa jedná o číselník konfig_detail_typ), tj ku každej položke číselníku konfig_nazov je priradený typ, ktorý určuje, akým spôsobom bude položka definovaná a táto hodnota sa nedá zmeniť.

Formulár umožňuje filtrovať položky v navigačnom zozname podľa typu (viď jednotlivé podkapitoly).

Funkčnosť každej jednej položky je popísaná v jednotlivých podkapitolách. Systém neobsahuje žiadne predvyplnené konfiguračné položky, je čisto na používateľoch, či ich založí, a podľa ich definície potom budú používať pre príslušné oblasti.

Konfigurácie využívajú číselníky:

Číselník konfig_typ:

- 1 – Aplikačný

- 2 – Organizačný

- 3 – SJ

- 4 – SO

- 5 – Organizačný + SJ + SO

Číselník konfig_detail_typ:

- 10 – celé číslo

- 20 – Text

- 30 – Dni

- 40 – Logická hodnota Áno/Nie

- 50 – Hodiny

- 60 – Číselníková položka

- 70 – Súbor (json)

A ďalej konfig_nazev_kod2 a konfig_detail_kombinace_typ.

3.37.1 Heslá

Každá položka tejto skupiny je ešte definovaná s väzbou na inštancie tabuľky cespol a to také, ktoré majú definovanú hodnotu is_pass = 1. Zatiaľ sa jedná iba o tabuľku cehtoso (položka /cehtoso.dalsi_xml/@indpw) a cesautenti (položka apikey_password). Tzn. že napríklad definíciu hesla na formulároch Xpw02/03 možno ovplyvniť pomocou konfiguračných položiek 100 – 105. Rovnako tak je možné ovplyvniť definíciu hesiel na formulári Adm57. Ak konfiguračné položky nebudú zadané, definícia hesiel na vyššie uvedených formulároch nebude podliehať žiadnej kontrole a užívateľ môže heslo zadať ľubovoľne.

Číselník konfig_nazov

Kód	Názov	Kód 2	Cel. č. – konfig_detail_typ	Des.h. – konfig_typ
100	Dĺžka hesla	Heslo	10	1	Minimálna dĺžka hesla, v prípade automatického vygenerovania hesla sa jedná o počet znakov takto vygenerovaného hesla
101	Heslo obsahuje číslice	Heslo	40	1	Ak je definovaná ako hodnota Áno, potom v rámci hesla musí existovať aspoň 1 znak číslice. Pokiaľ je definovaná Nie alebo nie je definovaná vôbec, číslica sa v rámci hesla nekontroluje
102	Heslo obsahuje špeciálne znaky	Heslo	40	1	Ak je definovaná ako hodnota Áno, potom v rámci hesla musí existovať minimálne jeden špeciálny znak. Ak je definovaná Nie alebo nie je definovaná vôbec, špec. znak sa v rámci hesla nekontroluje
103	Heslo obsahuje veľké písmená	Heslo	40	1	Ak je definovaná ako hodnota Áno, potom v rámci hesla musí existovať minimálne jedno veľké písmeno. Pokiaľ je definovaná Nie alebo nie je definovaná vôbec, veľké písmeno sa v rámci hesla nekontroluje
104	Heslo obsahuje malá písmená	Heslo	40	1	Ak je definovaná ako hodnota Áno, potom v rámci hesla musí existovať aspoň jedno malé písmeno. Ak je definovaná Nie alebo nie je definovaná vôbec, malé písmená sa v rámci hesla nekontrolujú
105	Dĺžka platnosti hesla (v dňoch)	Heslo	30	1	Počet dní platnosti zadaného/vygenerovaného hesla. Ak položka nie je vôbec definovaná, kontrola sa nevykonáva. Pre úplnú funkčnosť tejto konfigurácie je potrebné ešte definovať WFL na Adm33 – akcie 70 a job 70 na Adm53

3.37.2 ESP (Iba interná konfigurácia)

Kód	Názov	Kód 2	Cel. č. – konfig_detail_typ	Des.h. – konfig_typ
200	URL do ESP	ESP	20	1	URL aplikácie ESP s entrypoint pre registráciu /register
201	Platnosť tokenu	ESP	50	1	Platnosť tokenu v hodinách v rámci registračného e-mailu do ESP pre externých používateľov
202	Typ kontaktu pre registračný e-mail	ESP	60	2	Typ kontaktu pre registračný e-mail. Konfigurácia je definovaná pre každú organizáciu zvlášť. Pokiaľ nie je vyplnené, použije sa typ kontaktu 31
203	Reset API request do ESP	ESP	20	1	REST POST API pre registráciu záznamu v ESP Skladá sa zo základnej URL ESP bez entrypoint /main + samotnej API, ktorá je /api/v1/egje/registerExternalUser
204	Prihlasovací dialógs URL do ESP	ESP	40	1	Zobrazenie odkazu na Zmenu hesla alebo Zabudnuté heslo na prihlasovacom dialógu EGJE. Ak je nastavené na hodnotu 1 (a ďalej je nastavená aj konfiguračná položka 205 – pozri riadok nižšie) – dôjde k zobrazeniu na prihlasovacom dialógu webového rozhrania. Ak je nastavené na hodnotu 0 alebo položka vôbec neexistuje alebo neexistuje v kombinácii s položkou 205 – na prihlasovacom dialógu nie je žiadny odkaz.
205	URL do ESP pre zmenu hesla	ESP	20	1	URL, ktorá bude slúžiť na presmerovanie do ESP pri zmene hesla externého používateľa. Táto konfiguračná položka bude vyhodnocovaná spolu s položkou 204.

3.37.3 Dlaždice

Kód	Název	Kód 2	Cel. č. – konfig_detail_typ	Des.h. – konfig_typ
250	Dlaždice cez Adm42	Dlazdice	40	1	Povolenie práce s dlaždicami cez formulár Adm42
251	Dlaždice – json soubor	Dlazdice	70	1	Uloženie json súboru pre novú prácu s dlaždicami

Bližšie pozri dokumentáciu EGJE_web_uzdoc.

3.37.4 DokForm

Kód	Názov	Kód 2	Cel. č. – konfig_detail_typ	Des.h. – konfig_typ
300	Dokumenty na Dan31	DokForm	40	5
301	Dokumenty na Dan32	DokForm	40	5
302	Dokumenty na Dan33	DokForm	40	5
303	Dokumenty na Dan34	DokForm	40	5
304	Dokumenty na Das31	DokForm	40	5
305	Dokumenty na Das32	DokForm	40	5
306	Dokumenty na Das33	DokForm	40	5
307	Dokumenty na Das34	DokForm	40	5

3.38 Adm71 – Konfigurácia konštánt – pohľad od kombinácie

Zmyslom existencie tohto formulára (rovnako ako formulára Adm70) je, aby si administrátor zákazníka mohol nastaviť hodnoty konštánt, ktoré sa vyskytujú v kóde EGJE. Pri zmene tohto nastavenia sa potom nemusí čakať na ďalší výdaj EGJE, ale zmena prebehne okamžite na úrovni databázy. Rozdielom formulárov Adm70 a Adm71 je spôsob, akým zobrazujú dáta z podkladových databázových tabuliek (tieto podkladové tabuľky sú pre oba formuláre rovnaké:

• Adm70 pre vybranú konštantu (tj. konfiguráciu) ukazuje hodnoty, ktoré táto konštanta nadobúda pre definované kombinácie vstupných parametrov

• Adm71 pre vybranú kombináciu vstupných parametrov ukazuje hodnoty všetkých konštánt (danej tematickej oblasti EGJE), ktoré sú pre túto kombináciu

3.39 Adm76 – kontrola platnosti bezpečnostných kľúčov a certifikátov

Na účely kontroly platnosti bezpečnostných kľúčov a certifikátov sa môže použiť zostava Adm76, ktorú zle spustiť buď priamo alebo sa môže nadefinovať na Adm53 a bude následne spúšťaná denne automaticky. Na tejto zostave ide nastaviť dátum a predstih. Zostava potom v danom termíne pred koncom platnosti kľúča/certifikátu pošle emailové upozornenie na danú osobu/y.

· Dátum – koniec platnosti kľúča/certifikátu

· Predstih – koľko dní pred koncom platnosti má byť zaslané upozornenie

· Predmet emailu – je možné nadefinovať predmet (napr.: Končí platnosť kľúča!!!)

· Výpočet príjemcov (email) – tu sa dá zadať viacero emailových príjemcov oddelených čiarkami

3.40 Adm77 – Kontrola platnosti delegovaných profilov

Táto zostava umožňuje zistiť a vypíše upozornenie ( do súboru) na všetky profily, ktoré boli delegované na zástupcu, ale užívateľovi, ktorý tento profil delegoval už bol profil ukončený.

Výstup do súboru je možné na stavať na formát PDF alebo XLSX pomocou rádiobuttónu.

Zostava iba tieto profily vypisuje, následne je nutná manuálna ukončenie delegovania užívateľom.

3.41 Agenda výmeny súborov a dokumentov

Výmena dokumentov pomocou serverového adresára.

Realizované pre klienta AS resp. pre EGJEWeb.

Riešenie obsahuje:

Konfiguračný formulár Ftp02.

Užívateľský formulár Ftp01.

3.41.1 Ftp02 - Výmena súborov a dokumentov - konfigurácia

Záložka Konfigurácia - zaevidovanie ciest pre prístup z AS a EGJEWEB do adresára pre uloženie súborov, indikácia ich prístupnosti.

Záložka Zložky - popis položiek v súborovom systému. Umožní nastavení práv používateľov k nim na jednotlivé akcie - tie umožnia:

§ vkladať súbor

§ čítať súbor

§ dostať oznámenie o novom súbore

§ mazať uložený súbor

Adresár i Zložky sa v súborovom systéme zakladajú mimo EGJE, tu sa len zaevidujú.

3.41.2 Ftp01 - Výmena súborov a dokumentov

Tlačidlo Nahrať umožní vybrať a vložiť nový súbor. Ten je potom uložený na serverový adresár.

Pozri popis v nasledujúcej kapitole.

Súbor popisujúci položka Kategória je definovaná používateľským JPČ "kateg_ftp".

Formulár zobrazuje v navigačnom zozname všetky súbory z používateľovi prístupných zložiek. K dispozícii je štandardná funkčnosť hľadania, výberu a triedenia.

Keďže sú sprievodné informácie ukladané do metasúbora, tak zostanú v aplikácii prístupné i po zmazaniu vlastného evidovaného súboru.

3.41.3 Stručný popis konfigurácie a použitia Ftp01, Ftp02

· správca serverov vytvorí adresár dostupný z AS i EGJEWEB serverov, používatelia, pod ktorými servery beží, tu majú právo na čítanie i zápis

· tu vytvorí ešte podadresáre do_ela a z_ela (práva dtto)

· správca aplikácie otvorí Ftp02 a zaeviduje

o na záložke Konfigurácia hlavne zložky pre prístup z web serveru a to isté pre prístup z AS

o na záložke Zložky potom zložky (typicky do_ela a z_ela) a priradí tu používateľov EGJE, ktorí smú do zložky súbory:

§ vkladať

§ čítať

§ dostanú oznámenie o novom súbore

§ odstrániť uložený súbor

o objektové právo FtpAdmin

§ užívateľ majúci toto právo nemusí byť evidovaný pre jednotlivé činnosti so súbormi, ale má nad všetkými zložkami práva na všetky akcie, ktoré EGJE ponúka

· užívateľ, ktorý chce vložiť súbor, otvorí Ftp01 a

o tlačidlom "Nahrať" nový súbor vyberie a vloží do systémového adresára a jeho vybrané používateľovi prístupné Zložky.

Pri pokuse o uloženie súboru s názvom, ktorý už v serverovej zložke je, ponúkneme používateľovi nový názov, pod ktorým môže súbor uložiť. Nový názov je vytvorený z pôvodného názvu pridaním časovej značky (pr. Potvrdenie_201302185016.doc)

o používatelia, ktorí pre takúto zložku majú nastavené, že majú dostávať oznámenia o vložení nového súboru, dostanú oznámenie e-mailom na adresu z Osb02 (druh komunikácie 31 – E-mail v zamestnaní)

o používatelia, ktorí dostávajú oznámenia, majú tiež možnosť súbor spracovať (Ftp01 tlačidlo Spracovať). Súbor je zaevidovaný ako spracovaný, ak ho spracuje jeden z týchto používateľov.

· užívateľ, ktorý má prístup na čítanie zo zložky, po otvorení Ftp01 súbory, uvidí tento nový i starší súbory v navigačnom zozname tohto formulára.

· Ftp02, Ftp01 - kontrolné mechanizmy

1. Adresár pre výmenu dokumentov (zadávaný vo Ftp02) musí mať pre zákazníkov Elanor Outsourcing (zákazníci s kódom začínajúcim q), v koreni adresára súbor ftp.ftp, v ktorom bude práve a len zákaznícky kód. Ten je novo zobrazený aj na poslednej záložke Adm51.

Túto kontrolu môžu ale nemusia využiť aj SW zákazníci

2. Taktiež pri otváraní Ftp01 je vykonaná analogická kontrola

3. Kontrola prebieha i pri spustení servera AS / EGJEWEB s tým, že chyby sú zaznamenané v logu ako ERROR.

4. Ftp01 - obsahuje kontrolu, či ukladaný súbor má menej ako 20MB.

3.42 Xpw01 - Správa hesla (LDAP)

Okno umožňuje vykonať zmenu hesla na externom autentizačnom serveri.
Okno je funkčné a testované iba pre autentizáciu LDAPOnly voči doménovému serveru Windows. Popis potrebných parametrov je v EGJE_provdoc kap. 5.1.5 - okrem štandardných parametrov pre autentizáciu sa pre zmenu hesla používajú ešte parametre:
Web - ldap base s maxPwdAge (zmena hesla)
LDAP / Web - doba (počet dní) predstihu pred vypršaním hesla
LDAP / Web - správa - heslo nespĺňa pravidlá
Do Xpw01 je premietaná hlásenie o bezpečnostnej politike definovaná v Configurator / Overenie / Doplnková správa po zadaní požiadavky na reset hesla.
Okno je primárne určený pre novú web aplikáciu.

3.43 Xpw02 - Správa hesla pre VL

Formulár umožní koncovému používateľovi zmeniť svoje heslo pre prevzatie kryptovaného PDF s výplatným lístkom. Túto funkčnosť v súčasnosti ponúka len zákaznícky výplatný lístok Vyp11q.

Na druhej záložke je možné jednak "Vybrať PV bez zadaného hesla"
a tiež je tu možnosť vykonať "Hromadné naplnenie hesiel pre VL zo súboru oscpv,heslo" Od verzie e202409 je možné definíciu aj generovanie hesiel ovplyvniť konfiguračnými položkami – pozri Adm70, časť Hesla. Súbor musí byť uložený s kódováním ANSI. Štruktúra súboru je bez hlavičky.

Príklad súboru:

00000681.01,Heslo123

00000675.01,JABADABA234

00000680.01,8stsDDS3

3.44 Xpw03 - Správa hesla pre VL - generovanie

Formulár umožní koncovému používateľovi zmeniť svoje heslo pre prevzatie kryptovaného PDF s výplatným lístkom.

Heslo používateľ nezadáva, ale generuje. Túto funkčnosť vykonáva vstavaný generátor hesiel.

Algoritmus využíva náhodné číslo a následne generuje heslo obsahujúce veľké a malé písmená, číslice a špeciálne znaky, dĺžka je 10 znakov.

Na záložke Hromadné akcie je možné vykonať výber osôb bez hesla resp. uskutočniť hromadné generovanie hesiel. . Od verze e202409 lze generování hesel ovlivnit konfiguračními položkami – viz Adm70, část Hesla. Pokud nejsou nastavené, tak platí výše uvedená funkčnost.

Heslo vie využívať aj formulár Adm12 pri generovaní prístupu do systému pomocou AD (režim generovanie hesla a to "4 - Heslo podľa hesla pre VL (Xpw03)"), viď. vyššie uvedený popis tohto formulára.

Nie je povolené pre heslo používať písmená s diakritikou. Adobe Reader potom nevie takýto súbor otvoriť).

3.45 Tlačové zostavy

3.45.1 Adm07 - Používatelia - práva k riadkom

Výpis všetkých používateľov a im sprístupnených profilov, vrátane nastavení riadkových práv na profile a systémového logname.

Predpokladáme skôr využitie tabuľkového XLS formátu zostavy.

3.45.2 Adm08 - Profily, priradené objektové práva

Veľmi rozsiahla a dlhá zostava do .xlsx, ktorá vypisuje profily a všetky ich zadané objektová práva. Je možné ju obmedziť na profily jedného používateľa, tiež zisťovanie zozname všetkých používateľov pre objekt v úlohe je voliteľné.

3.45.3 Adm09 - Položky v generátore otázok

Výpis tabuliek a položiek ponúkaných v generátore otázok.

3.45.4 Adm17 - Používatelia - export pre audit (excel export)

Excel export všetkých evidovaných prístupových profilov priradených používateľovi. Slúži pre označenie tých prístupov, ktoré majú byť zrušené (stĺpec Ukončiť účet (0/1)).

3.45.5 Adm40 - Profily, objekty, detaily práv k formulárom

Analogická zostava ako Adm08, ale vypisuje všetky detailné objekty prístupových práv, nielen tie zadané. Vyhodnotenie práv k detailným podobjektom formulára vykonáva rovnaký aparát, ktorý formulár a objekty na ňom sprístupňuje. Keď je teda do profilu formulár priradený viackrát, je tu uvedená už tá výsledná hodnota práv na detailných podobjektoch.

Tiež je to veľmi rozsiahly a dlhý .xlsx export, odporúčame vždy vyplniť aspoň jeden z parametrov zostavy. Teda buď profil, alebo objekt.

Pri objekte v profile sú jednak všetky role, ktoré profil obsahuje (Role profilu) a potom role, v ktorých je konkrétny objekt s nejakou hodnotou práv uvedený (Role s objektom)..

3.45.6 Adm78 – API konfigurácia

Zostava umožňuje tlač nastavení API definovaných na Adm55 a prehľad certifikátov (Adm27) a podaní (Adm60) naviazaných na dané API. Vstupnými parametrami zostavy sú API a Iba platné. Ak nie je API zadané, výstup obsahuje dáta pre všetky API definované na Adm55. Parametr Iba platné sa aplikuje s väzbou na platnosť záznamov definície API (Adm55: Záložka API: Dátum od, Dátum do).

Výstup dát je vo formáte xlsx. Súbor obsahuje 5 listov:

· Konfigurácia API: základné nastavenie API (Adm55: API a Konfigurácia API)

· Služby a prostriedky API: pohľad na služby a prostriedky poskytované daným API a prehľad ORG a SJ s prístupom k týmto službám API (Adm55: Prostriedky a Priame priradenie prostriedku organizácii a SJ)

· Parametre API: nastavenie špecifických parametrov na úrovni API, prostriedku alebo ORG/SJ (Adm55: záložky Parametre pre jednotlivé úrovne nastavenia – API/Prostriedok/Priame priradenie prostriedku ORG a SJ)

· Certifikáty napojené na API: Ak sú na dané API naviazané certifikáty (Adm27), zostava uvádza ich výčet. Priradenie certifikátu k API je definované na Adm27, záložke Certifikačné oprávnenie, a tu Priradenie k API

· ePodanie využívajúce služby API: zoznam služieb/prostriedkov API, ktoré sú využívané niektorým krokom podania definovaným na Adm60 (väzba podania na službu API je u parametrov podania definovaná na záložke Kroky podania)

3.45.7 Adm79 – Evidence certifikátov

Súhrn umožňuje tlač certifikačných oprávnení a naviazaných vydaných certifikátov evidovaných na formulári Adm27 a ich priradenie k API. Súhrn je vstupne prístupný iba administrátorským profilom (rolia 1) a v prípade sprístupnenia súhrnu iným profilom je odporúčané vychádzať z nastavenia prístupu k Adm27.

Vstupnými parametrami sú:

· Dátum: ak je zadaný, súhrn načíta záznamy certifikátov, ktoré boli v daný deň platné a zároveň sa uvedený dátum aplikuje aj na záznamy priradenia certifikátov k API a registráciu certifikátov u externých organizácií.

· Organizácia a Správna jednotka: Ak používateľ nevyberie tieto parametre (predvolené = NULL), súhrn načíta všetky záznamy, na ktoré má používateľ práva (riadkové práva sú aplikované rovnakým spôsobom ako na formulári Adm27). Ak používateľ tieto parametre zadá, súhrn obmedzí záznamy, na ktoré má používateľ práva, podľa nastavených hodnôt vstupných parametrov súhrnu ORG/SJ.

· Typ certifikátu

Výstup dát je vo formáte XLSX. Súbor obsahuje 3 listy:

· Certifikáty: výčet certifikačných oprávnení a na ne naviazaných vydaných certifikátov.

· Priradenie certifikátov k API: výčet certifikačných oprávnení rozšírený o informáciu o ich priradení k API.

· Registrácia certifikátov u externých organizácií: k vydaným certifikátom sú načítané informácie o ich registráciách u orgánov verejnej správy, ak je táto registrácia zaevidovaná na Adm27, záložka Registrácia certifikátov.

3.46 Hierarchia členenia spracovávanej organizácie

Organizácia -> Správna jednotka -> Správny oddiel

3.46.1 Organizácia

Organizácia má právnu subjektivitu. Vo svojej existencii vychádza z Obchodného zákonníka a je uvádzaná v Obchodnom registri. Pojem organizácia má blízko k vlastníckym vzťahom, pretože organizácia má svojich majiteľov, ktorí sami alebo prostredníctvom určených "radov" organizáciu riadia. Ďalším používaným pojmom je firma, ale ten sa používa skôr v podnikateľskej sfére. Organizácia vytvára celé pracovné prostredie, interné predpisy v rámci platnej legislatívy. Na tejto úrovni býva spracovaná kolektívna zmluva.

Organizácia sa vnútorne delí, pokiaľ je to potrebné, na čiastkové časti a to podľa potrieb riadenia. Princípy členenia bývajú rôzne, napríklad geografické, odborové, prevádzkové a pod.

3.46.2 Správna jednotka

Jedným z spôsobov rozdelenia organizácie je rozdelenie podľa jednotiek, ktoré vystupujú samostatne navonok voči orgánom štátnej správy a to hlavne v mzdovej oblasti. Pre toto rozdelenie sa v našich predchádzajúcich systémoch vžil pojem "Správna jednotka", skrátene SJ. Správna jednotka sa prihlasuje napríklad v sociálnom zabezpečení (poistenie), zdravotnom poistení, pre daňové účely a je pre tieto orgány vykazovanou jednotkou. Vykazuje svoje výsledky voči štatistickým orgánom a vykazuje odvody poistného a daní. Súčasne pri vykonávaní kontrolnej činnosti sa tieto orgány obracajú na odborných referentov práve z konkrétnej SJ.

V praxi väčšinou zodpovedá rozdelenie na SJ geografickému rozdeleniu. SJ majú možnosť samostatnej tvorby kolektívnej zmluvy a to v rámci nadriadenej kolektívnej zmluvy organizácie.

V skutočnosti však takéto delenie na SJ nemusí vôbec zodpovedať štruktúre kolektívnych zmlúv. Tie môžu byť napísané napríklad odborovo. Ale keďže sa kolektívne zmluvy zaoberajú aj bežnými prevádzkovými problémami a podmienkami, vo väčšine prípadov zodpovedajú organizačnému rozčleneniu organizácie na najvyššej úrovni. Aj keď SJ nemusia byť prvou úrovňou organizačného členenia, veľmi často tomu tak je.

3.46.3 Správny oddiel

Správny oddiel (SO) vyjadruje rozdelenie správnej jednotky na časti (oddiely), ktoré vyhovujú požiadavkám na postupné uzatváranie miezd vo vopred stanovených termínoch. Napríklad ako prvý oddiel môžu byť spracovaní TH pracovníci, ktorých vstupy pre zúčtovanie sú jednoduchšie a potom ako druhý oddiel ostatní, ktorých mzdové podklady vychádzajúce z prevádzky a prevádzkových výsledkov sú zložitejšie.

Pojem správneho oddielu vyjadruje vnútorné interné členenie podľa vnútorných potrieb. Nemôže sa prejaviť vo funkčnosti správnej jednotky.

Dôvodom k zavedeniu SO je fakt, že sa v praxi vyskytuje, že sa časť miezd spracováva v jednom termíne a iná časť v druhom. Spracovaním sa nemyslí len výpočet mzdy, ale komplexné spracovanie až po zasielanie výplaty zamestnancom a prípadne aj prevod do účtovníctva. Požiadavka spracovania vo viacerých oddelených dávkach vzniká často pre firmy so zahraničnou účasťou, kde sa striktne vyžadujú (a to pomerne skoro po ukončení mesiaca) výsledky z oblasti miezd. Ďalším dôvodom existencie uvedenej línie môže byť rozdelenie spracovania SJ na čiastkové celky, napr. po bývalých SJ po zlúčení. Nemalo by ich však byť mnoho. Dôvodom môže byť

- väčšia výkonnosť systému (akcie môžu prebiehať paralelne)

- určitá konfigurovateľnosť na úrovni nižšej ako SJ

Z hľadiska ďalšieho použitia by SO mal mať číselnú identifikáciu, ktorá vyjadruje poradie spracovania SO v rámci SJ.

3.46.4 Zásady pri práci so SO a SJ

Pravidlá

- každý počítaný PV je povinne priradený k SO

- problém nastane pri zamestnancoch s viacerými PV. V tomto prípade musí byť zamestnanec ako osoba zaradený do SO podľa PV, ktorý je zaradený do posledného SO. Pozor, vôbec to nemusí byť kmeňový PV.

- rovnaký princíp rozdelenia na SO sa použije na všetky typy VT, t.j. ako pre dobierku, tak pre zálohy

Zásady pre výpočet miezd

- pre osobu s viacerými PV sa musia vyhodnotiť parametre pre každé PV podľa jeho priradení na SO

- pre osobu sa program snaží vypočítať vždy všetky PV, ktoré sú v rovnakom poradí (v rámci celej DB); pokiaľ už neostáva žiadne ďalšie PV k vypočítaniu v ďalších poradiach, vypočítajú sa až do zrážkovej bilancie. Pokiaľ je medzi počítanými PV kmeňový PV, potom sa zrážková bilancia smeruje naňho. Všeobecne to nemusí byť kmeňový PV, na ktorom sa dopočíta zrážková bilancia a tým celá osoba a sú naňho smerované zrážky. Potom musia aj používatelia príslušne nastaviť strediská (napríklad výplatné miesto).

- počítať vždy iba PV z rovnakého poradia (bez ohľadu na priradenie k rôznym referentom); PV z predchádzajúcich termínov sa neprepočítavajú, iba sa načítajú z DB.

- nepovoliť výpočet PV v termíne "n", pokiaľ PV z termínu < "n" ešte nie sú vypočítané

- každé PV účtovne dorovnávať; t.j.

- pre „neposledné“ počítané PV (nerobí zrážkovú bilanciu) spočítať príjmové ZLM a vygenerovať ZLM_A "odčítať prevod príjmov (k zúčtovaniu a odvodom)"

- pre posledné počítané PV (robí zrážkovú bilanciu) vygenerovať opačné ZLM k ZLM_A ako ZLM_B "pripočítať prevod príjmov (k zúčtovaniu a odvodom)"

Zásady pre uzávierku miezd

- uzávierka miezd (PU) sa spracováva za SO

- pri štarte PU za SO sa zistí, či je to posledný SO za SJ; pokiaľ áno, vykoná sa s týmto SO aj dopočítanie zaokrúhľovanej chyby poistného do SP v SR, a to z dát celej SJ a zaokrúhľovaný rozdiel sa premietne v rámci SO

Tento princíp sa použije aj v prípadoch opakovania PU za SO, aj keď na nej pri prvom spracovaní PU nebolo zaokrúhľovanie počítané

- v SR sa poistenie do SP počíta zo sumy vymeriavacích základov všetkých zamestnancov SJ. Preto musí byť zabezpečené, aby odvody za SJ boli v správnej výške, a to vrátane vyrovnania zaokrúhľovanej chyby. Preto existuje aj súčasť mzdovej uzávierky = PU SP, ktoré vyrovnajú ono euro či dve (zrejme u niektorého PV z posledného oddielu)

- malo by byť nastaviteľné, či poistné a dane odosielať s každým SO alebo až pri uzatvorení celej SJ

- mzdovú uzávierku e možné spúšťať za SJ. V takomto prípade

- najskôr sa vykoná výpočet PU SO

- a ak sú už spracované všetky SO z SJ nakoniec sa vykoná PU SP

- celá SJ je uzavretá, pokiaľ sú uzavreté všetky podriadené SO

Exporty:

- exporty navonok do okolia organizácie musia byť dátovo za organizáciu alebo SJ, ale vykonávať ich je možné po častiach za SO a to podľa termínov spracovanie uzávierky za SO

- export do účtovníctva by mal byť vykonávaný po SO, prípadne hromadne za viac SO.

Zostavy:

- obsah pojmu správny oddiel sa musí zvážiť pri každej zostave. Zostavy potom bude možné tlačiť

- za SO

- za SJ

- za organizáciu

(a navyše vždy podľa prístupových práv)

- podľa príslušnosti zostavy a dátového objektu je potrebné meniť aj hlavičku zostavy (za SO, za SJ, za organizáciu)

3.47 Parametre

Tu uvádzame parametre pre jednotlivé úrovne. Pokiaľ je určitý parameter povolený k evidencii na viacerých úrovniach, má prednosť tá hodnota, ktorá je uvedená na najnižšej úrovni. T.j. prednosť má hodnota pre SO, potom SJ a nakoniec za organizáciu.

3.47.1 Konfiguračné parametre sledované na úrovni organizácie

· Platenie poistného na GP (iba SK)

· Režim evidenčného stavu

0 – podľa trvania PV a úväzkov

1 – Odpracované hodiny / Fond pracovnej doby

2 – Odpracované hodiny / Hodiny prítomnosti + neprítomnosti

3 – Hodiny prítomnosti + neprítomnosti / Fond pracovnej doby

4 – Odprac. a neodprac. hodiny bez nadčasu a nadúväzku / Stanovený fond prac. doby

5 – Kombinovaný spôsob č.1

· Zaokrúhlenie hotovostnej dobierky …. spôsob zaokrúhľovania dobierky v hotovosti.

Vypĺňa sa podľa číselníku riešiteľa s hodnotami:

0 Nezaokrúhľovať

1 Na základňu hore

2 Od polovice nahor

3 Od polovice dole

4 Na základňu dole

pričom základ je daný nasledujúcim parametrom

· Základ pre zaokrúhlenie hotovostnej dobierky .. číselná hodnota, na ktorú sa hotovostná dobierka zaokrúhľuje; napr. 10 zaokrúhli na desaťkoruny/desať eurocentov.

· Spôsob zaokrúhlenia mesačnej tarify pri krátení podľa úväzku

Vypĺňa sa podľa číselníku riešiteľa s hodnotami:

5 Nezaokrúhľovať

6 Na základňu hore

7 Od polovice nahor

8 Od polovice dole

9 Na základňu dole

pričom základ je daný nasledujúcim parametrom

· Základ zaokrúhlenia mes tarify pri krátení podľa úväzku (CZ / Euro) .. číselná hodnota, na ktorú sa hotovostná dobierka zaokrúhľuje; napr. 10 zaokrúhli na desaťkoruny, nebo na 10 eurocentov.

· Nadčas počítať z priemerného fondu (Áno) nebo aktuálneho v mesiaci (Nie)

· Režim pravdepodobného priemerného zárobku

Vypĺňa sa podľa číselníku riešiteľa s hodnotami:

0 Pravdepodobný zárobok nie je počítaný

1 Pravdepodobný zárobok je počítaný zo zúčtovaných podkladov

2 Pravdepodobný zárobok podľa predchádzajúceho priemeru.

3 Pravdepodobný zárobok podľa evidovaného tarifu a priemerného mesačného fondu pracovnej doby

4 Režim Idea A – zo zúčtovaných podkladov, rešp. podľa predchádzajúceho

5 Režim DP Praha – DoVP/DoPČ, zo zúčt. podkladov, ostatné nepočítať

Pozn.: Jednotlivé režimy sú viac popísané v časti používateľskej dokumentácie Pru_uzdoc_sk - kapitola Konfigurácia.

· Priemerný zárobok minimálne vo výške min. mzdového nároku (Áno / Nie) [iba SK]

Slúži na určenie (len pre SK legislatívu), či sa má vypočítaný priemerný hodinový zárobok dorovnávať na hodnotu minimálneho mzdového nároku (odmeňovanie teda nie je dohodnuté v KZ) alebo iba na hodnotu minimálnej mzdy (odmeňovanie je dohodnuté v KZ).

· Otáčať zápory do účtovníctva (záporné čiastky sa zaúčtujú na opačné strany MD – DAL)

0 Nie

1 Áno (účty a položky 1)

2 Áno (účty a položky 1,2)

3 Áno (účty a položky 1,2,3)

· Posledný deň prevodu medzi strediskami

· Mesiac prevodu (relatívne – 0 súčasný, 1-nasledujúci..)

· NP Počet dávok, ktoré si zachovávajú úplný stav … Prihlášky k NP v ČR/ RLFO v SR.

3.47.1.1 Parametre mazania obsahu dátových a pracovných tabuliek

Parametre sú definované na hlavnej organizácii (u multiorganizačných inštalácií) na záložke Adm21 / Mazanie.
Mazanie sa vykonáva v akcii Vyp02 / Hromadné generovanie kalendárov, a to v prípade, že aktuálny dátum je medzi 21. dňom predchádzajúceho mesiaca a 20.dňom súčasného mesiaca (oboje vzhľadom k obdobiu, pre ktoré je kalendár generovaný). Mazanie je vykonávané za celú databázu.
Ide o samostatný proces, ktorý nasleduje po vygenerovaní kalendárov. Nie je teda nutné na jeho skončení čakať, je možné pri ňom pracovať.

Mazanie je ale možné pomocou parametra

Presmerovať mazanie do Gdp14 (implicitne prebieha v generovaní kalendárov): Áno

presmerovať do GDPR aparátu - procesné zostavy Gdp14.

V dokumentácii Gdp_uzdoc je aj toto mazanie podrobne popísané.

Tu je popísané len mazanie obsahu pracovných tabuliek.

Mazanie nijako nezasahuje do hlavného výsledku mzdového spracovania. Výplatné lístky ani ich nákladovej začlenenie nie sú vymazané.
Mazanie pomáha rýchlosti niektorých akcií, napr. mzdových importov, výberového aparátu, zostáv.
Zabezpečí, aby veľkosť databázy nerástla viac ako je nutné, čo uvítajú hlavne osoby zodpovedné za zálohovanie databázy.

Až na posledný parameter sú všetky parametre zadávané počtom mesiacov. Ak hodnotu zmažete, mazanie príslušnej časti nebude vykonávané. Pozn.: zmazanie je niečo iné ako vyplnenie na "0".

Druhou možnosťou je zväčšenie počtu mesiacov, za ktoré dáta ponecháte (napr. na 120 mesiacov).
Parametre:

· Mzdové importy - počet mesiacov uchovávaných dát
Predvyplnené hodnotou 12.
Ide o tabuľky cemdavky, cemdavky2, cemimpslm. Obsluhujú sa pomocou Vst06 resp. Vst11.

· Mzdové vstupy - počet mesiacov uchovávaných dát
Predvyplnené hodnotou 60.
Ide o tabuľky cemvstupy_hist, cemvstupy. Vyp01 / Vstupy
Ponechávané sú záznamy generované zo zrážok (zo Sra01). Majú Pôvod vzniku 99 a 100. Formulár je zobrazuje len pri zapnutom checkboxe Všetky vstupy (čítanie).

· Prevodné príkazy - počet mesiacov uchovávaných dát
Predvyplnené hodnotou 60.
Ide o tabuľku cemprikazy. Údaje zobrazuje napr. Ban07.

· Výstup do účtovníctva - počet mesiacov uchovávaných dát
Predvyplnené hodnotou 60.
Ide o tabuľku cemucto. Údaje zobrazuje formulár Uct02.

· Export do DWH - počet mesiacov uchovávaných dát
Predvyplnené hodnotou 12.
Ide o tabuľky cewcdckmen, cewcdcmzdy, cewcdczdrav

· Pracovné dáta výberov - počet mesiacov uchovávaných dát
Predvyplnené hodnotou 12.
Ide o tabuľky cetpravavyb *. Údaje zobrazuje Správa výberov.

· Dochádzka - priechody - počet mesiacov uchovávaných dát

Predvyplnené hodnotou 6.

Ide o tabuľku cedasd.

· Dochádzka - denné a mesačné dáta - počet mesiacov uchovávaných dát

Predvyplnené hodnotou 18.

Ide o tabuľky cedden *, cedmes *, ceddokl *. Tu ale pred mazaním vždy prebehne archivácia do cedarch (Dcu09)

· Doklady cestovných príkazov - počet mesiacov uchovávaných dát

Parameter zatiaľ nie je funkčný.

· Auditorské personálne záznamy - počet mesiacov uchovávaných dát

Ide o tabuľky cetoso_hist, cetpv_hist, cetsrazky_hist, cecbcesty_hist, cetmt_hist, cetosokomun_hist, cetplatby_hist, cetlogon_hist.

· Audítorská záznamy o štruktúrach - počet mesiacov uchovávaných dát

Ide o tabuľku cecstr_hist.

· Potlačiť mazanie audit tabuľky (Adm52) … (Áno/Nie)

Parameter je popísaný u formulára Adm52 (Pozn.2)

3.47.1.2 Ďalšie parametre

· Limit dní vyhodnocovania práv na PV do budúcnosti

Pri posúvaní referenčného dáta sa vyhodnocujú práva ako v minulosti, tak aj do budúcnosti. Implicitne je súčasné maximum dnešný deň + 40 dní.

Záporné hodnoty nie sú akceptované, maximum je 9999.

V praxi to zvyčajne umožňuje si pripravovať údaje pre budúce obdobie s použitím tých zaradenie, ktorá v budúcom období budú platné.

· Typ štruktúry považovaný za organizačnú

Implicitne je nastavená štruktúra 2 - organizačná štruktúra. Je ale možné nastaviť, že za organizačnú štruktúru pre výkazníctvo je považovaná aj iná štruktúra.

Iba pre CZ legislatívu :

· Potlačenie zľav na poistenie SZ za zamestnávateľa (Áno/Nie) – iba pre CZ legislatívu

· VŠ, fakulta – umiestnenie RID … parameter slúži na definovaní úrovní, vo ktorých bude vykazovaný identifikátor RID u vysokých škôl.

1 Organizácia SJ – v kódu SJ (vysoká škola je evidovaná na úrovni organizácie, fakulta na úrovni SJ)

2 SJ/SO – v kódu SO (vysoká škola je evidovaná na úrovni SJ a fakulta na úrovni SO)

· VŠ – číslo RID … pole pre zadanie RID vysokej školy v prípade, že parameter „VŠ, fakulta – umiestnenie RID“ má hodnotu 1.

· Režim platového automatu

1 Štandard

2 Min_do

3 FNB

4 CDC

5 ČVUT

6 IDC

7 Tesco

(bližšie informácie v dokumente Opv_uzdoc kapitola Väzba na režimy výpočtu - Adm21

· Logo pre používateľské zostavy

Logo je primárne určené pre zákaznícke výplatné lístky Vyp11fq resp. Vyp31fq

Je možné toto logo použiť aj v iných používateľských zostavách. V štandardných zostavách to technicky nie je možné.

Nepoužívajte logo väčšie ako cca 100KB, výrazne to zvyšuje pamäťovú záťaž spracovania zostavy a môže viesť až k ukončeniu celého procesu pre nedostatok pamäti.

Logo na úrovni SJ a SO je možno zadať na Adm22, Adm23. Pri použití sa prechádza kaskáda SO, SJ, Organizácia.

· Počítadlo pre používateľskú zostavu 1-3

· Identifikácia zákazníka pre úpravy v zostave Ban29 - len pre SK legislatívu. Zadaním hodnoty JPC ban29_rezim do tohto parametra sú aktivované zákaznícke úpravy pri generovaní XML súboru vytváraného zostavou Ban29 - Export prevodných príkazov vo formáte SEPA SK.

· Vytváranie používateľov LDAP/AD

o LDAP – uzol pre vytváranie používateľov

o LDAP – prefix – zákaznícke číslo

o LDAP - atribut employeeNumber

o LDAP – režim generovania

o LDAP – režim hesla

o LDAP – pevná časť hesla

o LDAP - hľadať osobu s RČ

Parametre sa využívajú v Adm12

· Parameter "Navigácia Adm12 - všetky statusy" potom umožňuje sprístupniť v navigačnom zozname Adm12 potencionálne aj Osoby / PV so statusom iným ako 1 - 3, ak na ne používateľ má práva.

3.47.1.3 Ďalšie parametre – samostatná záložka Parametre komunikácie

Vlastné pripojenie k e-mailovému serveru a konfigurácia odosielateľa je popísaná v EGJE_Provdoc

/ Kap. 3.6 Konfigurácia pripojenia k poštovému serveru.

Ďalšie parametre

· http(s) adresa EGJE Web:

Parameter je používaný pri generovaní e-mailov, ktoré vedú príjemcu na nejakú akciu v EGJEWEB. Odkaz býva v poslednej časti e-mailu.

Štandardné vyplnenie adresy je vrátane znaku "/" na konci adresy. V aplikácii síce v niektorých miestach, kde sa adresa používa a predlžuje. kontrola na chýbajúce "/" je, ale z rady technických dôvodov nemôže byť úplne všade.

· EGJEWEB - zobrazovať zostavy PDF, HTML v prehliadači:

Primárne sú zostavy PDF a HTML zobrazované priamo v prehliadači v novej aplikačnej záložke EGJEWEB.

PDF zostava je zobrazovaná pomocou Adobe plugin.

Záložka má ikonu so šípkou smerujúcou doprava nahor – otvorí zostavu do samostatného okna resp. záložky prehliadača.

V tomto parametru je možné nastaviť:

0 – Download zostavy = zostava je serverom poslané ako download.

1 - V záložke EGJEWEB (u PDF pomocou Adobe plugin) = implicitné správanie

2 - V záložke EGJEWEB (u PDF pomocou html5) = analogické režimu 1, ale s použitím iného prehliadača PDF (podľa štandardu html5)

Pozn.: Pre uplatnenie vykonanej zmeny v bežiacej aplikácii EGJEWEB je potrebné v prehliadači aplikáciu reštartovať (F5) tzn. znovu sa prihlásiť.

Pozn 2.: html5 podporujú iba novšie prehliadače, nič menej je to vstavaná funkčnosť.

Tento html5 PDF prehliadač je nastavený tak, že neponúka tlačidlo uložiť dokument (nič menej toto je pomerne slabá ochrana proti uloženiu na lokálny disk, ale pre mnohých môže byť i toto zaujímavým rozdielom)

· HTML editory pre Workflow: Áno / Nie, implicitne Nie.

Parameter určuje, či pole Wflow / Akcia je zobrazované pomocou HTML editora alebo štandardného textového viacriadkového poľa.

HTML editor má zmysel iba vtedy, keď Adm14 / Predlohy oznámenia sú vyplnené s html značkami resp. odkazy.

Pozn. V štandardnom java klientovi html editor vyžaduje nainštalovanú java 8.

· HTML editory pre Popisy: Áno / Nie, implicitne Nie.

Parameter určuje, či pole

Zpu01 / Popis / Obsah kurzu

Pmi01 / Popis

Pro01 * / Popis, Detailný popis

Rea02 / Vytvor správu

sú zobrazované pomocou HTML editora alebo štandardného textového viacriadkového poľa.

Je dobré toto zladiť s prípadnými už vytvorenými používateľskými zostavami z týchto oblastí.

Každý výstup konvertuje obsah buď do štandardného textu, alebo do html poľa v závislosti na tom, ako bol vytvorený v Jasper Reports resp. ako je deklarovaný dátovom zdroji exportné zostavy.

Pozn. V štandardnom java klientovi html editor vyžaduje nainštalovanú java 8.

· "Režim (ne)odosielania e-mailov:" s hodnotami:

1 E-maily odosielať,

2 E-maily odosielať a logovať (ukladá veľké množstvo dát!),

3 E-maily neodosielať a logovať (ukladá veľké množstvo dát!),

4 E-maily neodosielať (typicky testovacie db).

slúži k centrálnemu vypnutiu odosielania e-mailov.

To môže byť zaujímavé predovšetkým pre testovaciu prevádzku / prostredia.

Pozn.: Neodosielanie blokuje všetko, ale logovanie loguje iba veci mimo workflow, teda toho, čo sa dá logovať pomocou Adm14.

Logy zobrazuje Adm54 / navigácia E-maily.

· WFL - pri nenájdení e-mailu osoby (typ 31) poslať internú správu:

U niektorých zákazníkov nemajú všetci zamestnanci E-mail v zamestnaní (Osb02 ... Druh 31).

Ak je však worklflow EGJE v Adm14 nastavené na e-mailová oznámenia, zobrazuje spracovanie chybové upozornenia.

Nastavením tohto parametra na hodnotou Áno môže správca nastaviť, že pri nenájdení e-mailu osoby (typ 31) systém pošle internú správu.

Internú správu číta používateľ pomocou aplikačného okna Mail.

Na záložke pribudla nová sekcia „Kontrolo vloženého e-mailu pred verifikáciou“, kde sú 2 definovateľné polia. Táto funkcionalita umožnuje nadefinovať doménu e-mailu a typ e-mailu (napr. 31 – e-mail v zamestnaní) voči ktorému sa vykonáva kontrola, či vložený email zodpovedá parametrom zvoleným organizáciou. V tejto chvíli je táto funkcionalita spojená iba s užívateľmi, ktorí ju majú prepojenú s ďalšími formulármi.

V prípade vyplnenia týchto polí, ale bez napojenia na ďalší formulár, sa funkcionalita neprejaví. Pokiaľ by bol prípadný záujem o kontrolu vkladaného e-mailu, je najskôr nutné napojiť funkcionalitu na vopred dohodnutý formulár a dohodnúť typy vykonávaných kontrol.

3.47.2 Konfiguračné parametre sledované navyše na úrovni správnej jednotky

· Platenie poistného na GP (iba SK)

· Zaokrúhľovanie príjmových ZLM

0 Matematicky

1 Nahor

· Zaokrúhľovanie hotovostnej dobierky

0 nezaokrúhľovať

1 Na základňu hore

2 Od polovice nahor

3 Od polovice dole

4 Na základňu dole

· Základ pre zaokrúhľovanie hotovostnej dobierky (CZK/Euro)

.. číselná hodnota, na ktorú sa hotovostná dobierka zaokrúhľuje; napr. 10 zaokrúhli na desaťkoruny, alebo 10 eurocentov

· Nadčas počítať z priemerného fondu (Áno) nebo aktuálneho v mesiaci (Nie)

· Spôsob zaokrúhlenia mesačnej tarify pri krátení podľa úväzku.

Vypĺňa sa podľa číselníka riešiteľa s hodnotami:

0 Nezaokrúhľovať

1 Na základňu hore

2 Od polovice hore

3 Od polovice dole

4 Na základňu dole

pričom základ je daný nasledujúcim parametrom.

· Základ zaokrúhlenia mes. tarify pri krátení podľa úväzku (CZ / Euro)

.. číselná hodnota, na ktorú sa hotovostné dobierka zaokrúhľuje; napr. 10 zaokrúhli na desaťkoruny, alebo na 10 eurocentov.

· Otáčať zápory do účtovníctva (záporné sumy sa zaúčtujú na opačnej strany MD - DAL)

0 Nie

1 Áno (účty a položky 1)

2 Áno (účty a položky 1,2)

3 Áno (účty a položky 1,2,3)

· Prefix správnej jednotky pre účtovníctvo

· Skratka názvu SJ pre exporty

.. textová skratka názvu SJ používaná v makrách pre tvorbu názvov zostáv

· Automaticky preplácať nevyčerpanú dovolenku ako ZLM

· Aut. zraziť prečerpanú dovolenku ako ZLM

· Aut. preplácať nevyčerpanú časť dovolenky minulého roku (nad 4 týždne) ako ZLM …položka sa využíva k definícii konkrétnej ZLM, na ktorú bude automaticky preplatená uvedená nevyčerpaná časť dovolenky a súčasne slúži k aktivácii funkcie automatického preplatení nevyčerpanej časti dovolenky minulého roku, pokiaľ je tato časť vyššia ako 4 týždne.

Pre CZ : do roka 2011 § 222 ZP odst.2

Pre SK: § 116 ZP odst.2

Poznámka: Táto ZLM slúži aj v opačnom prípade, keď je posudzovaný stav, že si zamestnanec "nemohol vyčerpať dovolenku" a preto je mu prevádzaný celý zostatok z minulého roka do roku ďalšieho.

Pokiaľ tento parameter nie je vyplnený, uvedený automatizmus nefunguje – viď Dov_uzdoc, kap. 4.5 Preplácanie nevyčerpanej dovolenky na konci roka

· Automaticky generovať doplatok do minimálnej/zaručenej mzdy

· Neplatné strediska ZLM pri spätnom prepočte nahradiť aktuálnymi

· Evidenčné členenie dodatkovej dovolenky z minulého roku ako ZLM

· Evidenčné členenie dodatkovej dovolenky z bežného roku ako ZLM

· Evidenčné členenie riadnej dovolenky z minulého roku ako ZLM

· Evidenčné členenie riadnej dovolenky od predchádzajúceho zamestnávateľa ako ZLM

· Evidenčné členenie ostatnej dovolenky ako ZLM

· Evidenčné členenie riadnej dovolenky z bežného roku ako ZLM

· Obmedzenie taríf pre SJ zahŕňa položky

o Výpočet tarifných stupníc povolených pre SJ:

o Výpočet tarifných stupňov povolených pre SJ:

o Výpočet ďalšieho členenia povolený pre SJ:

V prípade vyplnenia konkrétnymi zoznamy, sú potom tieto použité ako filtre pre zadávanie na Opv01, Opv05.

o Kód doby pre nastavenie tarify podľa tar. zaradenia:

· CZ benefity od 2024 pre SJ zahŕňa položky:

o Suma poskytnutých benefitov od začiatku roka (SLM s IA 5533) - vyčíslovať vo výpočte každý mesiac (Áno/Nie)

· Zoznam ZLM prac. voľna s povinným limitom

Slúži na definíciu tých SLM pracovného voľna, pri ktorých by mal byť zadaný limit na f. Dov02. Pokiaľ nie je na f. Dov02 u týchto SLM zadaný žiadny limit, je ako limit určený fiktívne nulový limit, na ktorý je u nich pri ich zúčtovaní výpočtom vykonávaná kontrola.

Iba pre CZ legislatívu :

· Číslo okresu pre hlásenie o ONZ

· Názov okresu pre hlásenie o ONZ

· Na dokladoch pre ČSSZ uvádzať meno aj s titulom (Áno/Nie)

· Štát, v ktorom je činnosť vykonávaná

· Promile zák. poistenia zodpovednosti.. stanovené promile pre odvod poistného

· Príspevok na FKSP z nákladov generovať ako ZLM (bližšie informácie v dokumente EGJE_uvod_mzdy odsek Príspevky do FKSP)

· Príspevok na FKSP zo zisku generovať ako ZLM (bližšie informácie v dokumente EGJE_uvod_mzdy odsek Príspevky do FKSP)

· Evid. ZLM poistenia zamestnancov na SZ - zam. bez dôch. sporenia

· Evid. ZLM poistenia zamestnancov na SZ - zam. s dôch. sporením

· Evid. ZLM pre vym. základ zamestnávateľa na SZ - zam. s dôch. spor. aj bez

· Evid. ZLM pre časť dane 15% bez solidárneho navýšenia

· Evid. ZLM pre časť dane 7% solidárneho navýšenia

· Viac ako 50% zamestnancov so zdravotným postihnutím pre ZP (Áno / Nie)

Iba pre SK legislatívu

· Zaokrúhľovanie príjmových ZLM

0 Matematicky

1 Hore

· Automaticky generovať zmeny v ZP (Áno / Nie)

· Dni výkonu práce dohôd sú zadávané (IA 5138), (Áno / Nie)

· Vyššia náhrada pri DPN je zjednaná v kolektívnej zmluve (Áno/Nie)

Tento parameter eviduje, či je prípadné navýšenie náhrady príjmu pri DPN nad základnú výšku stanovenú zákonom zjednané v kolektívnej zmluve a či teda podlieha zdaneniu či nie.

Pre Treximu SK

· právna forma

· kód vlastníctva

· odvetvie

· kód odborového zväzu

· typ kolektívnej zmluvy

· hlavný trh výrobkov

Pre tvorbu sociálneho fondu (SF)

· príspevok do SF z nákladov generovať ako ZLM (bližšie informácie v dokumente EGJE_uvod_mzdy.doc odsek Príspevky do sociálneho fondu)

· príspevok do SF zo zisku generovať ako ZLM (bližšie informácie v dokumente EGJE_uvod_mzdy.doc odsek Príspevky do sociálneho fondu)

Ďalšie parametre

· Logo pre užívateľské zostavy

Obdoba loga na pre úroveň organizácie, ale pre úroveň SJ. Pri použití sa prechádza kaskáda SO, SJ, Organizácia.

3.47.3 Konfiguračné parametre sledované navyše na úrovni správneho oddielu

· Zaokrúhľovanie príjmových ZLM

0 Matematicky

1 Nahor

· Zaokrúhľovanie hotovostnej dobierky

0 Nezaokrúhľovať

1 Na základňu hore

2 Od polovice nahor

3 Od polovice dole

4 Na základňu dole

· Základ pre zaokrúhľovanie hotovostnej dobierky (CZK/Euro)

.. číselná hodnota, na ktorú sa hotovostná dobierka zaokrúhľuje; napr. 10 zaokrúhli na desaťkoruny, alebo 10 eurocentov

· Otáčať zápory do účtovníctva (záporné sumy sa zaúčtujú na opačnej strany MD - DAL)

0 Nie

1 Áno (účty a položky 1)

2 Áno (účty a položky 1,2)

3 Áno (účty a položky 1,2,3)

· Prefix správneho oddielu pre účtovníctvo

· Skratka názvu SO pre exporty

.. textová skratka názvu SO používaná v makrách pre tvorbu názvov zostáv

· Automaticky preplácať nevyčerpanú dovolenku ako ZLM

· Aut. zraziť prečerpanú dovolenku ako ZLM

· Aut. preplácať nevyčerpanú časť dovolenky minulého roku (nad 4 týždne) ako ZLM …položka sa využíva k definícii konkrétnej ZLM, na ktorú bude automaticky preplatená uvedená nevyčerpaná časť dovolenky a súčasne slúži k aktivácii funkcie automatického preplatení nevyčerpanej časti dovolenky minulého roku, pokiaľ je tato časť vyššia ako 4 týždne.

Pre CZ : $222 ZP odst.2

Pre SK: $116 ZP odst.2

· Automaticky generovať doplatok do minimálnej/zaručenej mzdy

· Percento pre určenie stálej mzdy v rámci konta pracovného času - položka sa používa v prípadoch, keď zamestnávateľ využíva prácu v režime konta pracovného času, pre automatický výpočet výšky Stálej mzdy pri zaradení PV na vyrovnávacie obdobie. Podľa legislatívy hodnota nesmie byť menšia než 80%. Podrobné informácie k princípom práce v režime konta pracovného času sú uvedené v samostatnom dokumente Kpd_uzdoc.doc. Len pre CZ legislatívu.

· Počítať saldo v rámci konta PČ - položka udáva, či sa pri výpočte v režime konta pracovného času (KPČ) má počítať aj saldo doby, ktoré je súčasťou účtu konta pracovného času. Hodnota NIE sa užíva v prípade, keďže saldo doby je evidované v inom (napr. dochádzkovom) systéme.

· Automaticky vyrovnávať záporný odvod preddavkov na daň - hodnota ÁNO udáva, že ak vznikne preplatok na preddavkoch na daň (odvedená suma by bola záporná), bude tento preplatok automaticky uplatnený v budúcom období.

· Zoznam ZLM prac. voľna s povinným limitom

Ďalšie parametre

· Logo pre užívateľské zostavy

Obdoba loga na pre úroveň organizácie, ale pre úroveň SO. Pri použití sa prechádza kaskáda SO, SJ, Organizácia.

Záložka e-Daňovka

Obsahuje parametre určené pre užívateľov eDaňovky (Prehlásenie/ Žiadosť o RZD)

· Žiadať o RZD možno do (dd.mm)

Interný termín, do ktorého môže zamestnanec prostredníctvom eDaňovky odoslať Žiadosť o RZD mzdovej účtovnej – pokiaľ nevyplnený, je termín daný zákonom na 15.2.

· Pri premietaní Vyhlásenia nerezidenta prepisovať aj evidenciu v Osb02

Príznak, či v prípade nerezidenta majú byť údaje o nerezidentovi uvedené v Vyhlásení automaticky premietnuté aj do záložky Cudzí štátni príslušníci na f. Osb02

· Kontrolovať platnosť zľavy na poplatníka do konca roka?

Pokiaľ je tento parameter nastavený na hodnotu Áno, kontroluje sa v sprievodcovi tvorbou Vyhlásenia na f. Dan31, či zamestnanec uplatňuje zľavu na daňovníka do konca roka.

Pokiaľ nie, je na to v takom prípade upozornený (pri odchode z príslušnej stránky) hláškou

„Základná zľava netrvá celý kal. rok – pokračovať?“ (A/N)

ktorá mu umožní sa nad zadaným údajom zamyslieť a prípadne ho upraviť.

3.47.4 Ďalšie konfiguračné parametre

Na tejto záložke pribudla sekcia „Vytvoriť logname podľa podmienok Adm21 (bez AD)“. Tento parameter sa nastavuje pre použitie funkcionality na formulári Adm12 (záložky „Prihlásenie autentizácie“ a „Hromadné akcie“. Špecifikuje, ako ma vyzerať formát generovaného logname v prípade, že klient nemá Active Directory. Táto funkcionalita sa spúšťa novými tlačidlami na na formulári Adm12 na záložkách uvedených vyššie Tlačidlá „Generuj logname podľa Adm21“ a „Generuj chýbajúce logname podľa Adm21“.

3.47.5 Konfigurácia výstupného formátu protokolu z Adm53

Týmto parametrom na formulári Adm21 à záložka „Konf.par.“ s názvom „Výstupný formát protokolu (Adm53):“ sa dá nastaviť výstupný formát protokolu, ktorý sa generuje na formulári Adm53. Pokiaľ je na Adm53 nadefinovaná akcia a na záložke „Parametre“ à „Tabuľkový pohľad“ je zadaný parameter „r_send4error2ext“ alebo je možné ho zadať na záložke „Formulárový pohľad“ je to parameter s názvom „Odoslať protokol na email“ (ide o rovnaký parameter, ale zobrazovaný na iných záložkách), tak pomocou parametra „Výstupný formát protokolu (Adm53):“ sa dá nastaviť v akom formáte sa má daný protokol vytvoriť a odoslať.

3.47.6 Parameter „Zobrazovať navigačný zoznam“

Tento parameter slúži na možnosť vypnutia a zapnutia navigačného zoznamu, ktorý sa zobrazuje na WEB klientovi. Pre mobilné zariadenia alebo tablety, táto lišta zaberá príliš veľa miesta aj v minimálnom zobrazení a týmto parametrom sa dá potlačiť.

V prípade, keď bude mať používateľ len jedno PV, nie je v takom prípade nutné toto menu vôbec zobrazovať a preto bude zobrazenie lišty, v takom prípade, úplne potlačené.

4 Upozornenie

Zoznam prístupných častí dokumentácie je tu.