Okruh řešení Adm = „Administrace systému“ pracuje se společnými daty a jejich položkami a rovněž s konfiguračními položkami a číselníky. Evidence založená v tomto okruhu se používá v celé řadě dalších okruhů.

Řada informací k těmto tématům je v provozní dokumentaci (Provozní dokumentace) resp. v úvodu

(Úvod společný)

2 Data okruhu „Adm“

V této části si popíšeme datové položky a jejich skupiny, které jsou sledovány v rámci okruhu „Adm“.

2.1 Hierarchie členění zpracovávané organizace

Organizaci z hlediska zpracování naším systémem hierarchicky členíme na

- organizace

- správní jednotka (SJ)

- správní oddíl (SO)

Význam jednotlivých článků a jejich vztah je uveden v technologických poznámkách.

2.1.1 Organizace

Použití pojmů organizace – viz resp. formulář pro správu údajů o Organizacích Adm21

Kód organizace

Kód organizace či uživatele našeho systému

Název

Název organizace používaný například v sestavách. Eviduje se název

- běžný pro interní sestavy a potřeby

- oficiální pro externí výstupy

Adresa

Adresa organizace; skládá se z položek:

- název - použije se výše uvedený oficiální název

- ulice

- číslo domu – orientační, popisné

- PSČ

- místo, obec

Datum implementace

Datum implementování systému.

Legislativa

Označení legislativy, pod kterou systém pro správní jednotku běží. Zadává se podle řešitelského číselníku legislativa s hodnotami:

CZ česká

SK slovenská

Není-li legislativa definována v této položce, je potřeba ji definovat u jednotlivých správních jednotek.

Časové pásmo organizace

Hl. organizace

V případě, že zákazník používá multiorganizační strukturu, je nutné definovat, která z organizací je hlavní.

Implicitní kód jazyka

Nastavuje jazyk, který se má implicitně používat pro organizaci. Jazyk se zjišťuje kaskádou: implicitní kód jazyka -> legislativa organizace -> jazyk z parametru. Toto nastavení ovlivňuje uživatelské sestavy nebo workflow notifikace.

Zak.

Interní označení zákazníka definované autorem SW – na toto označení mohou být vázané některé úpravy programu specifické pro konkrétního zákazníka.

Parametry organizace

Na úrovni organizace se zadává a eviduje řada dalších parametrů, které jsou společné pro celou zpracovávanou organizaci a to bez ohledu na správní jednotku či správní oddíl. Jedná se o parametry – viz dále seznam.

2.1.2 Správní jednotka

Číslo správní jednotky

Jednoznačná identifikace správní jednotky uvnitř organizace

Organizace

Název organizace, pod kterou vybraná SJ náleží.

Název

Název správní jednotky používaný například v sestavách. Eviduje se název

- běžný pro interní sestavy a potřeby

- oficiální pro externí výstupy

Legislativa

Označení legislativy, pod kterou systém pro správní jednotku běží. Zadává se podle řešitelského číselníku legislativa s hodnotami:

CZ česká

SK slovenská

Platnost od - do

Rozmezí období platnosti správní jednotky. Využije se například při reorganizaci.

Adresa

Adresa a kontaktní údaje správní jednotky; zahrnuje položky:

- název adresáta

- ulice

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

- PSČ

- Místo, obec

- Stát

- Telefon

- Fax

- E-mail

IČO

Identifikační číslo organizace. Vybírá se z číselníku Vykazovacích jednotek na formuláři Adm21, záložka č.IČO

DIČ

Daňové identifikační číslo organizace

CZ_NACE, SK_NACE

Převažující oborová kvalifikace ekonomických činností

Kód území (NUTS, LAU)

Kód územní jednotky (okresu) v němž má správní jednotka sídlo. Číselník vydává ČSU/Slovenský štat. úrad.

CZ parametry:

Kód finanční kontroly

Kód pro rozlišení finanční kontroly ekonomického subjektu podle direktivy EU 80/723/EEC pro ISCP/Trexima. Vyplňuje se podle číselníku řešitele.

Typ kolektivní smlouvy

Typ kolektivní smlouvy ekonomického subjektu pro ISCP/Trexima. Vyplňuje se podle číselníku řešitele.

Právní forma ekonomického subjektu

Vyplňuje se pro účely šetření ISP a to podle číselníku ČSU.

Kód kolektivní smlouvy

Vyplňuje se pro účely šetření ISP.

Kód zařízení bez vlastního IČ

Vyplňuje pro účely šetření ISP správní jednotka bez vlastního IČO.

Číslo správního úřadu

Vyplňuje pro účely šetření ISoSS správní jednotka, která podává hlášení za zaměstnance pracující ve služebním poměru

Kód OVM

Vyplňuje se kód organizace výkonné moci. Nabízí se položky uživatelského JPC sluz_ovm

VŠ – číslo RID

… pole pro zadání RID vysoké školy v případě, že parametr na formuláři Adm01 - „VŠ, fakulta – umístění RID“ má hodnotu 1.

Parametry správní jednotky

Na úrovni správní jednotky se zadává a eviduje řada parametrů, které jsou společné pro celou správní jednotku, tj. pro všechny podřízené správní oddíly. Jedná se o parametry – viz dále.

2.1.3 Správní oddíl

Číslo správního oddílu

Jednoznačné určení správního oddílu; vyjadřuje rovněž číselné pořadí zpracování oddílů v rámci správní jednotky

Číslo správní jednotky

Číslo správní jednotky, pod kterou správní oddíl spadá.

Název

Název správního oddílu používaný například v sestavách. Eviduje se název běžný pro interní sestavy a potřeby

Platnost od - do

Rozmezí období platnosti správního oddílu.

Adresa

Adresa správního oddílu; skládá se z položek:

- ulice

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

- PSČ

- Místo, obec

VŠ – číslo RID

… pole pro zadání RID vysoké školy v případě, že parametr „VŠ, fakulta – umístění RID“ má hodnotu 2.

Parametry správního oddílu

Na úrovni správního oddílu se zadávají a evidují některé parametry – viz dále.

3 Standardní řešení okruhu „Adm“

V následující tabulce je uveden seznam objektů zařazených do okruhu Adm. V první sloupci je kód objektu, ve druhém označení druhu objektu (F = formulář, P = proces, S = sestava). Třetí sloupec popisuje obsah objektu

Tučným písmem jsou označeny již řešené a zdokumentované objekty

Adm01	F	Uživatelé
Adm01p	P	Nový uživatel
Adm02	F	Profily (abstraktní uživatelé)
Adm03	F	Role (práva k objektům)
Adm04	F	Objekty práv, konfigurace
Adm05	F	Objekty práv – menu
Adm06	F	Skupiny řádkových práv (pro číselníky a struktury)
Adm07	S	Uživatelé - práva k řádkům
Adm08	S	Profily, objektová práva
Adm09	S	Položky v generátoru dotazů
Adm10	F	Uživatelé, Profily, Autentizační server
Adm12	F	Uživatelé Webu
Adm13	F	Ochrana osobních údajů
Adm14	F	Konfigurace Elanor Workflow
Adm17	S	Uživatelé - export pro audit (excel export)
Adm20	F	Pokyny ke stažení
Adm21	F	Konfigurace - organizace
Adm22	F	Konfigurace - správní jednotky
Adm23	F	Konfigurace - správní oddíly
Adm24	F	Kurzovní lístek
Adm25	F	Export číselníků
Adm26	F	Nastavení šifrování
Adm27	F	Certifikáty
Adm28	F	Externí organizace
Adm31	F	Konfigurace uživatelských položek
Adm32	F	Konfigurace hlášení výpočtu
Adm33	F	Konfigurace textů (pozvánky, kalendář ...)
Adm34	F	Zákaznické help odkazy
Adm40	S	Profily, objekty, detaily práv k formulářům
Adm42	F	Nastavení a pojmenování dlaždic HR Portálu
Adm51	F	Změnové řízení databáze
Adm52	F	Audit
Adm53	F	Úlohy na AS
Adm54	F	Audit změn
Adm55	F	API a prostředky
Adm56	F	Definice nápovědy
Adm57	F	Autentizace
Adm58	F	Notifikace na konec daňových slev
Adm60	F	Parametrizace podání
Adm61	F	Dávky tiskových sestav
Adm62	F	Správa žádání o dokument
Adm63	F	Definice regulárních výrazů pro kontrolu vstupních polí
Adm64	F	Definice standardních regulárních výrazu pro výběr z menu
Adm71	F	Konfigurace konstant – pohled od kombinace
Adm76	F	Kontrola platnosti bezpečnostních klíčů a certifikátů
Adm77	F	Kontrola platnosti delegovaných profilů
Adm78	S	API konfigurace
Adm79	S	Evidence certifikátů
Ftp01	F	Výměna souborů a dokumentů
Ftp02	F	Výměna souborů a dokumentů - konfigurace
Xpw01	F	Správa hesla (LDAP)
Xpw02	F	Správa hesla pro VL
Xpw03	F	Správa hesla pro VL - generování

3.1 Adm01 – Adm05

Objekty jsou souhrnně popsány v provozní dokumentaci EGJE_provdoc. Popis je začleněn do postupu vytváření uživatele a definice jeho práv.

Adm01 je pohled vycházející ze seznamu profilů přiřazených jednotlivým uživatelům. Jeho specialitou je záložka Přístupná PV, která zobrazuje osoby a PV, která bude konkrétní uživatel díky profilu mít přístupná. Zobrazení je k referenčnímu datumu a respektuje i "Limit dní vyhodnocování práv na PV do budoucnosti:" (standardně 40). Jinými slovy posunete-li referenční datum více dopředu, než je tento limit, budou práva počítána k tomuto limitu. To je z řady důvodů, např. že práva často závisí na strukturách a ty se připravují dopředu a jejich budoucí podoba není vždy v optimálním stavu.

Také záložky Objekty a práva a Přístupné SLM zobrazují práva a SLM, které uživateli zařazenému na profil přísluší. Objekty získá uživatel pomocí rolí (Adm03), SLM jsou pak definovány v Adm06.

Adm02 je základním definičním formulářem přístupového profilu. To je takový abstraktní uživatel. Profil je popsán právy k řádkům (hned první záložka) a také přiřazenými rolemi (záložka Role profilu), ty zase definují objektová práva.

Ta jsou definována na formuláři Adm03.

Zde máme role ve správě Elanor (0-499) a role zákaznické (500-999). Zákaznické role si definuje uživatel. Podrobnější popis je v EGJE_provdoc odstavec Vytvoření a editace role

Adm04 je pohled na práva přes navigaci objektů, tedy kde se který objekt uplatňuje. Zajímavou informaci poskytuje u uživatelské sestavy. Zde je uvedeno, která její verze je aktuální. EGJE totiž standardně uchovává i dvě předchozí verze uživatelské sestavy a zde je možné místo té nejnovější udělat aktivní místo ní nějakou starší verzi.

U formulářů umožňuje zadávat pokyny pro práci s formulářem viz Adm20.

Konfigurační i na roli založené skrývání celých objektů a jejich částí je popsáno v EGJE_provdoc.

Adm05 je primárně seznamem menu uzlů referentského rozhraní (prvky MENU_ ) a uzlů rozhraní HR Portál (prvky MENUDL_). U prvků (čtverců) v menu HR Portál zde umožňujeme správci předefinovat jejich pořadí a také název, který se ve čtverci zobrazuje. U změn názvů však postupujte obezřetně, tak aby se název příliš nevzdálil od fixního názvu, který je v referentském rozhraní, helpu, dokumentaci a který je také styčným prvkem pro helpdesk.

Názvy jsou vícejazyčné (cs, sk, en).

Na záložce Dlaždice s parametry se dají zadávat dlaždice odkazující na formuláře Epr01, Epr05. U každé dlaždice lze nastavit název a parametry wflep_skup a wflep_typ pro skupinu a typ eProposalu. Takto vytvořená dlaždice otevře formulář Epr01, Epr05 a rovnou spustí proces zadávání nového eProposalu pro skupinu a typ z parametru.

3.2 A dm06 - Skupiny řádkových práv (pro číselníky a struktury)

3.2.1 Obecné skupiny řádkových práva (záložka 1)

Formulář umožňuje definovat skupiny práv a ty pak přiřazovat v různých číselnících a s jejich pomocí pak na profilu (Adm02) omezovat řádkový přístup k dalším datovým osám (než jen dosud používané osy: Osoby a PV, Uchazeči, Typy struktur, Statusy uchazeče).

Adm06 - definice skupin

Adm02 - Profily - použití skupin řádkových práv:

kde

Omezení číselníků dle skupin ŘP - uživatel uvidí (obvykle v nabídkových ComboBoxech) jen ty hodnoty z příslušného číselníku, které jsou označeny touto skupinou (výčet oddělovaný čárkou) nebo nejsou označeny skupinou žádnou.

Přidat vlastní skupinu z Org.str. - přidá ke skupinám v předchozím řádku ještě tu skupinu, která je uvedena u organizačního střediska, na které je uživatel zařazen.

Omezení editace číselníků dle skupin ŘP - pro uživatele, kteří editují číselníky - musí zde mít výčet všech skupin, jimiž označené řádky v číselníku mají vidět a editovat (jinak vidí jen řádky bez označení skupinou)

Přidat vlastní sk. z Org.str. - editace - dtto úvodní dvojice, ale pro účel editace číselníků

Omezení editace číselníku struktur (výčet typů) - výčet typů struktury (navigace Str01), které uživatel smí editovat. Např. 2,3 způsobí, že uživatel v Str01 uvidí a může editovat pouze Organizační strukturu (2) a Pracovní místa (3).
To může být zkombinováno s omezením editace jen některých řádků (pomocí předchozích dvou parametrů)

Systém je komplexní a jeho nastavení doporučujeme provádět s konzultanty Elanor.

Uplatnění zápisové skupiny "Omezení editace číselníků dle skupin ŘP" (volitelně doplněné o vlastní skupiny z org. struktury) definuje, kde jde skupinu přiřadit resp. který prvek, skupinou označený, může uživatel editovat

· Combo Str01 / Struktura hierarchicky / Detail / Číslo skupiny řádkových práv
(navíc je zde tlačítko Skupina ŘP do podřízených prvků, které propaguje skupinu přiřazenou na aktuální položce do všech jejich podřízených - obvykle středisek)

· Combo Str02 / Detail / Číslo skupiny řádkových práv
+ vlastní navigační seznam formulář

· navigační seznam PM, tedy Pmi01, Pmi02, Pmi07, Pmi08, Pmi09, Pom03, Utk03, Utp03

· navigační seznam Prof, tedy Pro01

· navigační seznamy pro struktury 30-32, 34, 37, 39

· Str06

· Jpc01 / Číselník / Číslo skupiny řádkových práv
+ navigační seznam, navíc je v navigačním seznamu filtr Přístupné pro zápis

· Cmt01 / Tarifní stupnice / Číslo skupiny řádkových práv
+ obsah záložek Stupnice, Seznam tabulek, Tarify v tabulkách, Archiv

· Slm02 / Popis započitatelnosti / Číslo skupiny řádkových práv
+ navigační seznam

Výčet "Omezení číselníků dle skupin ŘP" (volitelně doplněné o vlastní skupiny z org.struktury) je použit pro omezení zobrazovaných záznamů na:

Opv01 Záložka struktury / combo struktur Opv04 combo struktur

Vyp01 combo struktur

Pozn. nabídka typů struktur na

Opv01/Struktury

Opv04/Struktury

Opv05/Struktury

Opv50fkb/Struktury

Cdc01f/Struktury

pak zároveň podléhá také volitelnému omezení výčtem Adm02 / PV výčet typů struktury, povolení přiřazení.

Opv01, Opv05 nabídka volných PM

Opv09

Pla03, Pla04, Pla20, Pla21

Sto02

Ovp01, Opv04, Opv05, Dcm01 comba tarifních stupnicStr10

Adm54 - navigace struktur

Str05 - navigace

tiskové sestavy - argument

vlastní data sestavy:

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

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

Nastavení těchto záložek umožňuje modifikovat implicitně nastavenou přístupnost složek mezd pro čtení a zápis na následujících formulářích:

Vyp01

Opv02

Sra01

Dav01

Dcd01 + Dcu01, Denní evidence

Dcm01 + Dcu01, Měsíční evidence

Dcv01

Dca02

Dcu06 (EGJE WP)

Dov05/Dov06

Obecně rozlišujeme právo záznamy s určitou SLM na formuláři vidět a právo mít možnost záznam s určitou SLM zadat (tedy ty SLM, které se nabízejí v combu při vyplňování položky SLM).

Pro nastavení aparátu nejprve definujeme na záložce 2 Skupiny SLM, které pak můžeme používat pro jednotlivé formuláře a profily (záložka 3).

Skupina SLM má kód a

buď položku :

Výčet SLM nahradit implicitní - výčet nahradí implicitní chování formuláře (v mantinelech dostupných IA dle rozhodnutí Elanor)

nebo jednu či obě položky

Výčet SLM odebrat z implicitních- výčet zakázaných SLM oproti implicitnímu chování

Výčet SLM přidat k implicitním - SLM navíc oproti implicitnímu chování

přičemž výčet SLM znamená jednotlivé SLM oddělené čárkou resp. jejich intervaly s oddělovačem pomlčka

Př.: 21-26,31,51-56

Na 3. přiřazovací záložce pak zadáváme vždy:

Objekt práv - každý z výše uvedených formulářů zde má své čtecí a zápisové objekty

Skupina SLM - přiřazení skupiny SLM definované na předchozí záložce

Nepovinné položky:

Profil práv - pokud nevyplníme - platí pro všechny uživatele (tj. bez rozlišení profilu práv)

pokud vyplníme, definujeme přístupnost pro uživatele s konkrétním profilem (toto nastavení má přednost)

Organizace- pouze pro tzv. multiorganizační databáze - vyplnění umožní odlišit nastavení pro jednotlivé organizace. Nevyplnění pak platnost pro všechny.

Práva nastavujte vždy tak, aby zápisová práva nebyla větší než práva čtecí, jinak uživatel nově pořízenou SLM neuvidí!

Objekty a jejich funkčnost:

1- Dca02 - dlouhodobé odchylky - čtení

které SLM jsou v záložce zobrazovány

akceptovány jsou SLM platné pro legislativu, docházku a období formuláře

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

ale ne 904

2- Dca02 - dlouhodobé odchylky - zápis

které SLM může uživatel v této záložce zadat (tj. jsou v nabídkovém combu)

detto jako skupina č. 1

3- Dcd01, Dcv01 - vstupy - čtení

u Dcv01 se nastavení týká záložky Denní, používá se také pro Dcu01, Vstupy denní

akceptovány jsou SLM platné pro legislativu, docházku a období formuláře

Použití SLM podle IA není omezeno

4- Dcd01 - vstupy – zápis

používá se také pro Dcu01, Vstupy denní

akceptovány jsou SLM platné pro legislativu, docházku a období formuláře

současně musí být povolené pro skupinu SLM č.3

SLM 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 - čtení

u Dcv01 se nastavení týká záložky Měsíční

používá se také pro Dcu01, Vstupy měsíční

akceptovány jsou SLM platné pro legislativu, docházku a období formuláře

Použití SLM podle IA není omezeno

6- Dcm01 - vstupy – zápis

používá se také pro Dcu01, Vstupy měsíční

akceptovány jsou SLM platné pro legislativu, docházku a období formuláře

současně musí být povolené pro skupinu SLM č.5

SLM 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 ne 904

7- Schvalování SLM vstupů DOCH/DOV - datum a půldny (SlmSchvalD)

určená pro formuláře Dov05/Dov06/Dov16, Dcu06
akceptovány jsou SLM s IA 11 až 899, 998, 999, 1001 až 1006, 1101 až 1154, 2121 až 2199 a 5101 a vyšší

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

při nedefinování skupiny SLM s IA 21

8- Schvalování SLM jednoden. vstupů DOCH/DOV - datum a čas od, do (SlmSchvalT)

určená pro formuláře Dov05/Dov06, Dcu06
akceptovány jsou SLM s IA 11, 12, 13, 14, 21, 999, 1003, 1004, 1111, 1116, 1132, 1143, 2121, 2122

9- Dav01 – Docházka a výkony

akceptovány jsou platné pro docházku a období formuláře

SLM 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 ne 904

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

uživateli jsou zobrazovány pouze záznamy s uvedenými SLM (u Dcv01 se nastavení týká záložky Mzdové vstupy)

11- Vyp01 – vstupy – zápis

které SLM může uživatel v této záložce zadat (tj. jsou v nabídkovém combu)

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

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

14 - Vst15 směny – zápis (Vst.smeny_W)

15- Sra01 - čtení

16- Sra01 – zápis

17- Schvalování SLM vstupů DOCH/DOV – pouze datumy (SlmSchvalD2)

akceptovány jsou SLM s IA 11 až 899, 998, 999, 1001 až 1006, 1101 až 1154, 2121 až 2199 a 5101 a vyšší

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

18- Schvalování SLM vstupů DOCH/DOV - datumy a čas od resp. Do (SlmSchvalT2)

akceptovány jsou SLM s IA 11 až 899, 998, 999, 1001 až 1006, 1101 až 1154, 2121 až 2199 a 5101 a vyšší

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

19- Dav01 - směny – zápis

je určena pro definici SLM, pro které je možno na záložce Dav01, Vstupy, uživatelem zadat prac. směny.

pokud není založena, je povoleno zadání prac. směn pouze pro SLM s IA 950

akceptovány jsou pouze SLM s IA 21 až 66, 91 až 162, 998, 999, 950, 1009, 2405, 4306, 5101, 5104.

20- Opv02, Opv01/tar. zařazení - čtení

společné nastavení i pro zobrazování promítání tarifních SLM do Opv01

21- Opv02 – zápis

22- Jednodenní vstupy DOCH-Kalendář - s časem od, do (bez schval.) (SlmDoch1a)

určená pro Dcu06 (WP), záznam denní evidence
akceptovány jsou pouze SLM s IA 11 až 1009 ale bez IA 903, 904, 950

a dále IA 1111 až 1116, 1131 až 1136, 1143 až 1154, 2121 až 2132 a 5101

23- Jednodenní vstupy DOCH-Kalendář - s částí směny nebo hodinami (bez schval.) (SlmDoch1b)

určená pro Dcu06 (WP), záznam denní evidence
akceptovány jsou pouze SLM s IA 11 až 1009 ale bez IA 903, 904, 950

a dále IA 1111 až 1116, 1131 až 1136, 1143 až 1154, 2121 až 2132 a 5101

24- Jedno a vícedenní vstupy DOCH-Kalendář - celodenní (bez schval.) (SlmDoch2a)

určená pro Dcu06 (WP), záznam měsíční evidence

akceptovány jsou pouze SLM 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 vícedenní vstupy DOCH-Kalendář - s půldny (bez schval.) (SlmDoch2b)

určená pro Dcu06 (WP), záznam měsíční evidence

akceptovány jsou pouze SLM s IA 12, 14, 15, 21, 22, 26, 27, 41, 42, 61..66, 1001, 1002, 5101, 5104

26- Vícedenní vstupy DOCH-Kalendář - s časem od, do (bez schval.) (SlmDoch2c)

určená pro Dcu06 (WP), záznam měsíční evidence

akceptovány jsou pouze SLM s IA 61, 62, 63, 64, 65, 2121, 2122, 5101, 5104

29 - SlmDoch1c - Jednodenní vstupy DOCH-Kalendář (bez schval.), pouze čtení

určená pro formulář Dcu06 pro oblast neschvalovaných záznamů v denní evidenci, SLM zde zařazené jsou na formuláři pouze zobrazované (nelze zadat jako nový, aktualizovat ani smazat)

předvolení: žádná SLM
omezení: povolené SLM (jako skupina 22) akceptovány jsou pouze SLM s IA 11 až 1009 ale bez IA 903, 904, 950
a dále IA 1111 až 1116, 1131 až 1136, 1143 až 1154, 2121 až 2132 a 5101

30 - SlmDoch2d - Jedno a vícedenní vstupy DOCH-Kalendář, pouze čtení

určená pro formulář Dcu06 pro oblast neschvalovaných záznamů v měsíční evidenci, SLM zde zařazené jsou na formuláři pouze zobrazované (nelze zadat jako nový, aktualizovat ani smazat)

předvolení: žádná SLM
omezení: povolené SLM (jako skupina 24) akceptovány jsou pouze SLM 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 (měsíční) - s půlkami dne

Seznam SLM, pro které je možné na Dcm01 zadat půlky směny.

Standardně není povolené vložení půlky směn pro žádnou SLM.

32 - Dcm01.Vstupy_časy - Dcm01, Dcu01 - Vstupy (měsíční) - s časem od/do

Seznam SLM, pro které je možné na Dcm01 zadat Čas od/do.
Standardně není povolené vložení půlky směn pro žádnou SLM.

33 - Jednodenní měsíční vstup DOCH-Kalendář - s hodiny/směny (bez schval.)
kód: SlmDoch2e

Určená pro Dcu06 (WP), záznam pouze do měsíční evidence se zadáním pouze celkového počtu směn nebo hodin (datum v zázname je pouze evidenční pro zobrazení záznamu v Dcu06).
SLM se nezobrazí v Dcd01 a jiných formulářích denní evidence docházky.
Použité SLM musí mýt povinně nastaven Kód doby = B.

default povolená SLM s IA 950

akceptovány jsou pouze SLM s IA 62, 63, 64, 65, 950, 1003, 1111, 1113, 1114, 1135, 1154, 2131, 2132, 5101 až 5104

34 - Měsíční vstup DOCH-Kalendář s nepovinnou přílohou (bez schval.)
kód: SlmDochPril

určená pro Dca11, Dcu06 (WP), záznam měsíční evidence s nepovinnou přílohou

default není žádná SLM

akceptovány jsou pouze SLM s IA 21, 26, 41 až 66, 5101, 5104, 5151

V rámci Dcu06 určená pouze pro měsíční neschvalované odchylky (režim vstupu 24,25,26).

35 - Měsíční vstup DOCH-Kalendář s povinnou přílohou (bez schval.)
kód: SlmDochPrilPov

určená pro Dca11, Dcu06 (WP), záznam měsíční evidence s povinnou přílohou

default není žádná SLM

akceptovány jsou pouze SLM s IA 21, 26, 41 až 66, 5101, 5104, 5151

V rámci Dcu06 určená pouze pro měsíční neschvalované odchylky (režim vstupu 24,25,26).

36 - SLM z plánu nepřítomnosti

Kód: SlmPlan

Určená pro zadání plánované odchylky dovolené do Dcp01 z Dcu06.

povolené jen pro SLM s IA 21, 22, 26, 5151

odchylka do plánu se zakládá pouze v režimu celý den + půlden (stejné jako v Dov16)

37 - SLM s možností vyplnit strukturu

Seznam SLM u kterých je možné doplnit přiřazení na strukturu na určených formulářích DOCH.

Default: žádná SLM Omezení: žádná SLM

38 - SLM s povinností vyplnit strukturu

Seznam SLM u kterých je povinnost přiřazení na strukturu na určených formulářích DOCH.

Default: žádná SLM Omezení: žádná SLM

39 - (SlmDoch39) - SLM s povinností vyplnit Poznámka

Dcu06, Povinnost vyplnit pole Poznámka, Poznamka1 + Poznamka2 pokud je zobrazeno na dialogu editace.

Default: žádná SLM Omezení: žádná SLM

40 - (SlmDoch40) - SLM s opakovaným uložením

Dcu06. Seznam SLM, u kterých je možné použít funkci opakovaného generování schvalované odchylky.

Default: žádná SLM Omezení: žádná SLM

111 - Vyp22 SLM v absenční kartě

116 - Vst15 schval. Částka přes WFL 16

Seznam SLM, které lze následně použít na formuláři Vst15, záložka Schvalované částkou, pro WFL 16.

117 - Vst15 schval. Částka přes WFL 17

Seznam SLM, které lze následně použít na formuláři Vst15, záložka Schvalované částkou, pro WFL 17.

121 - Dcf03/Dcf15 schval. částka přes WFL 21

Seznam SLM, které lze následně použít na formulářích Dcf03, Dcf04 a Dcf15 - Odměňování. Bez tohoto nastavení nelze na zmíněných formulářích vybrat SLM pro generování odměn.

3.3 Adm10 - Uživatelé, profily, autentizační server

Uživatelé jdou standardně vytvořit a spravovat na Adm01, Adm01p.

Tento formulář však nabízí jednoduché přiřazení uživatelského profilu a autentizačního řetězce (Logname) existujícím osobám. Osoby i profily jsou zde bez omezení. Jediné omezení, které se zde uplatňuje je omezení organizací (u víceorganizačních instalací).

Záložka Audit logname dává přehled o všech změnách údaje Logname, ať již byly provedeny prostřednictvím jakéhokoliv formuláře (Adm01, Adm01f, Adm10, Adm12).

3.4 Adm11 - Správa osob a PV

Přehledový formulář, který zobrazuje všechny osoby a jejich PV. Jediné omezení, které se zde uplatňuje je omezení organizací (u víceorganizačních instalací).

Nezobrazuje citlivé údaje pouze identifikaci a přiřazení.

Některé standardní role jej mají přiřazen pro čtení, pouze správce jej má pro zápis. Jelikož má navigaci osob a nikoliv standardní Osoba+PV je v něm např. dobře rozlišitelné, zda-li je to jedna a tatáž osoba nebo je-li evidována v systému jako osoba vícekrát.

Je to také jediné místo, kde může správce osobu/PV smazat, pokud již nebyla použita např. ve mzdách nebo ve vzdělávání a není na ní nějaká podobná vazba z dalších částí systému.

Pokud je, tak je vhodné místo smazání změnit na PV Datum nástupu a Datum ukončení např. na 1.1.1950 a Status vztahu osoba - organizace na 10 - Personální evidence blíže neurčeno a vymazat položku Druh právního vztahu.

Detailně je možnost smazat osobu v minulosti počítanou takováto:

Existuje právo Adm11mazaniSpoc - Právo mazat osoby spočtené předloni a dříve.

Mají jej pouze standardní role 1 a 3.

Vyhodnocujeme období letos a vloni, kdy, je-li v něm spočteno&uzavřeno, formulář smazat osobu resp. PV nedovolí.

Je-li ale nejnovější výpočet&uzavření z předloňska resp. starší, smí osobu mazat ten uživatel, který má to právo Adm11mazaniSpoc.Formulář je opravdu pro zápis vhodný pouze pro správce nikoliv pro personalistu nebo mzdovou účetní.

3.5 Adm 12 - Uživatelé Webu, profily, autentizační server

Uživatelé jdou standardně vytvořit a spravovat na Adm01, Adm01p.

Tento formulář však nabízí jednoduché přiřazení uživatelského profilu (obvykle zaměstnaneckého či manažerského či obou) jakémukoliv zaměstnanci. Na rozdíl od Adm10 jsou zde osoby v navigačním seznamu omezeny přístupovými právy uživatele. Standardně také platí omezení na Status PV 1 – 3. Toto omezení však zde vypnout na „Adm21 / Konfigurační parametry / Navigace Adm12 – všechny statusy“ zadáním hodnoty „Ano“.

Důležitou podmínkou je to, je-li osoba správcem, tj. má-li zápisová práva na jeden z formulářů Adm01, Adm02, Adm03 nebo Adm10.

Pokud není, formulář nabízí pouze ty profily, které obsahují objekt Adm12Combo - Profil smí přiřadit v Adm12, Adm01p (i když není správcem).

Navíc se uživateli nenabízejí ty profily, které mají právo na jeden z uvedených Adm formulářů. A osoby s takovým profilem již přiřazeným také nemůže uživatel, který není správcem na Adm12, editovat tj. přidávat, měnit mazat profily i loginy.

Uživatel, který není správcem, také nesmí žádný profil přiřadit sobě, tzn. osobě, pod kterou je nyní přihlášen.

Pozn. tato restrikce platí i pro průvodce Adm01p.

Vzhledem k omezené funkčnosti je formulář dobře delegovatelný.

Formulář také slouží k vytváření autentizačních účtů Microsoft AD domény správcem přímo z EGJE.

Funkčnost je k dispozici v individuální i hromadné podobě. Používá se při ní LDAP přístupu k Windows doméně. Je tedy třeba mít v EGJE nastavenou LDAP autentizaci.

Správce tedy může vytvářet uživatele do repository Microsoft AD.

K tomu jsou použity jednak parametry z Configuratoru / zál. Ověření, které se týkají připojení ke LDAP a dále parametry v Adm21 / Konfigurační parametry / Vytváření uživatelů LDAP/AD, které definují parametry do repository vytvářeného uživatele.

Na záložce Přihlášení - autentizace je kromě vyplnění autentizačního Logname možné jej rovnou v AD vytvořit (tlačítko Vytvořit logname na aut.serveru) resp. uživateli toto heslo změnit (tlačítko Změna hesla). Dále je zde funkce "Vytvoření autentizace", která spojí obě akce tzn. vytvoří Logname a zavede jej do AD. Režim a dialog jse shodný jak je popsán dále v hromadných akcích.

Pozn.: tvar Logname je popsán v Provozní dokumentaci (kap. Založení uživatele stručné shrnutí).

Na záložce Hromadné akce je funkce Hromadné vytvoření neexistujících autentizací, po spuštění stejnojmenného tlačítka následuje dialog umožňující zvolit/zadat:

· režim tvorby autentizačního Logname

· zadat doménu

· zadat atribut employeeNumber

· zadat Typ autentizace

· režim hesla

· zadat pevnou část hesla

Pokud jsou uvedeny v Configuratoru / Ověření parametry "LDAP - uživatel s právy na čtení" + jeho heslo (parametry jsou používány v LDAPSearch autentizaci),

tak celou práci s LDAP v Adm12 (hlavně zakládání AD uživatelů indiv. i hromad.) systém dělá pod tímto uživatelem. Pak je možné nastavit práva na zakládání uživatelů v AD tak, že běžní uživatelé je nemají, ale práva má tento jeden uvedený uživatel. Tento uživatel je používán právě a pouze ve formuláři Adm12. Nastavení přístupových práv k Adm12 určuje přístup uživatele EGJE k této funkcionalitě.

V Adm21 / Konfigurační parametry / Vytváření uživatelů LDAP/AD se nastavují parametry hromadného generování. Tyto parametry definují přesněji kam a jak bude uživatel do repository vytvářen.

Generování je jištěno proti vytvoření duplicitního účtu v AD resp. proti přepisování jednoho účtu jiným uživatelem.

Při vytváření loginu do Active Directory se do AD položky s kódem employeeID uloží interní ID osoby v EGJE (id_toso). Tak je možné poznat, zda je již login osoby v AD vytvořen. Když není a generované logname je již obsazeno, vytváří logname s 2 na konci (resp. 3, 4...) a to tak dlouho, dokud nenajde neobsazený logname.

Dále vytváření dokáže při vyplnění Adm21 parametru "LDAP - hledat osobu s RČ"=Ano reagovat na situaci, kdy je jedna osoba v egje db vícekrát (typicky v různých organizacích či SJ s jiným IČO). Potom v případě, že osobu nalezne, ji již znovu nevytváří.
Pozn.: rodné číslo EGJE ukládá do AD položky s kódem userParameters.

Při vytváření je možno do AD položky s kódem employeeNumber uložit uživatelská data. Předvyplnění položky je možno zadat v Adm21 / Konfigurační parametry / Vytváření uživatelů LDAP/AD / LDAP - atribut employeeNumber. Kromě textu je možno zadat i makra:

%LEG% - doplní legislativu (CZ/SK), pod kterou spadá zaměstnanec.

%OSC% - část z OSČPV zaměstnance před tečkou.

Jeden z režimů generování hesla a to „4 - Heslo dle hesla pro VL (Xpw03)“ heslo pro přihlášení do EGJE převezme z hesla vygenerovaného v Xpw03. Pokud toto heslo vygenerováno není, vygenerujeme jej a uložíme do Xpw03 v tomto kroku.

Zákazníci používající tato hesla je obvykle tisknou na skryté výplatní pásky pomocí uživatelské sestavy Xpw03fq.

Záložka Adm12 / Hromadné akce také obsahuje tlačítko Hromadná změna hesel, které vytvoří dle zvoleného algoritmu heslo znovu i v Active Directory již vytvořeným uživatelům.

Při tvorbě uživatelů resp. změně hesel umožňujeme nastavit pomocí LDAP v Active Directory atribut Změnit heslo při příštím přihlášení.

Na formuláři Adm12, na záložkách „Přihlášení a autentizace“ a “Hromadné akce“ byla přidána tlačítka „Generuj logname dle Adm21“ a na hromadných akcích je to tlačítko „Generuj chybějící logname“ pro generování logname bez Active Directory. Funkcionalita spolupracuje s nastavením na formuláři Adm21 à záložka Konfigurační parametry. Zde je výběrový rolldown menu, ze kterého se dá vybrat, jak bude generovaný logname vypadat a po vygenerování funkcionalita tento logname zapíše do aplikace EGJE. Tuto funkcionalitu můžou využít klienti bez Active Directory.

Poznámka: Algoritmus generování logname byl upraven tak, aby logname neobsahoval žádné speciální znaky. Ty jsou odstraněný a pro logname se vezmou pouze písmena. Nepoužijí se tedy znaky jako pomlčka nebo apostrof atd., která mouho být součásti jmen a příjmení.

Na formuláři Adm12, karty Přihlášení – autentizace a Hromadné akce přibyl sloupec Typ autentizace a tlačítko Odeslat registrační e-mail. Typ autentizace je defaultně prázdný nebo roven hodnotě 0 a nijak nemění práci s vygenerováním logname nebo s jeho využitím pro autentizaci. Pouze v případě ASP klientů je zde jiná hodnota. Tlačítko je spojené s definovanými ZakId (ASP klienti) a objektovým právem Adm12RegisterCombo, detailní popis viz dokumentace EGJE_distribuceHeselASPklientum

3.6 A dm13 - Ochrana osobních údajů

Formulář slouží k správě údajů o bývalých zaměstnancích a uchazečích a k selektivnímu mazání jejich údajů.

Promazání "nepotřebných" údajů bývalých zaměstnanců a uchazečů je cestou k naplnění zásad zákona o ochraně osobních údajů 101/2000 Sb.

Formulář je určen pro správce aplikace a provádí promazání pro celou databázi.

Týká se těchto údajů:

Záložka „Správa promazání“

V záhlaví se určí doba tj. pomocí datumu se určí osoby, které svůj poslední PV ukončily před tím datem. Datum musí být starší než jeden a půl roku před dnešním datem.
V podzáložce Zaměstnanci k promazání a Uchazeči k promazání se můžeme přesvědčit, kdo do procesu promazání bude spadat.

podzáložka "Popis promazání"

Oddíl "Bývalí zaměstnanci“ má části:

platby (povinné)

Opv02 - všechny o osobě

Opv01 - tarifní zařazení

srážky (povinně zaškrtnuto)

Sra01- všechny o osobě s IA 4101-4699, včetně mazání Vyp01 / Vstupy (režim Všechny vstupy), vynechávají se osoby s rentou (Poj25)

Audit srážek

WFL srážek (Sra21)

rodinní příslušníci (povinně zaškrtnuto)

Všichni z Osb02 pro osobu

údaje o průměrech pro náhrady (povinně zaškrtnuto)

Všechny údaje z Pru01 pro osobu

Vynechávají se osoby s rentou (Poj25)

údaje o dovolené

Všechny údaje o dovolené a korekcích z Dov01 a o pracovním volnu Dov02 pro osobu

údaje o zaměstnaneckých výhodách a hodnocení

Údaje z formulářů Ben*, Hod*, které se váží k osobě

údaje rozšiřující údaje o osobě (závazky a pohledávky, CO, voj.evid.)

Další rozšiřující údaje z Osb02.

Kariéra Kar01,

Rekond. pobyty SK (Opv18)

Pracovní pomůcky (Pom1x) údaje o způsobilostech a kompetencích

Údaje osoby z Kva01 od 3 záložky dále a údaje z Kom01.

Údaje o škole a praxi Kva01Riziko (Bzp02)

údaje o strukturách uloženy bez odkazu do číselníku (povinně zaškrtnuto)

Údaje v Opv01 Zařazení na struktury jsou uloženy v jiné formě (přímo kódy a názvy struktur, nikoliv odkazy na číselník - tak jsou číselníkové hodnoty uvolněny pro další použití resp. smazání).

Případné zařazení na strukturu 3, se zobecní na zařazení na strukturu 2,

zařazení na strukturu 4 je smazáno.

Kontakty

Osb02 – komunikace včetně auditu

Průkazy (osobní: mimo druhy 0,2,3,4; PV: všechny):

Osb02 – Průkazy – osoba i PV

Dokumenty osoba PV

Opv31

Docházka (Dcd, Dcm) včetně archivu (Dcu09)

Toto mazání je vlastně aditivním k mazání k průběžnému periodickému mazání definovanému v Adm21 / Konfigurační parametry

Oddíl "Uchazeči"

Volba :

Ponechat identifikaci a status

Úplné smazání údaje o uchazeči

pro úplné smazání

Jsou smazána všechna data (tj. v navigaci Rea01 již uchazeč mít údaj nebude)

pro ponechání identifikace

o uchazeči jsou ponechány pouze základní identifikační údaje

(tj. jméno příjmení tituly, rodné číslo, pohlaví, vazba na osobu, výběrové řízení, údaje o přijetí, mailová adresa, status, SO)

Výkonná tlačítka jsou v

Správa promazání / Zaměstnanci k promazání

Nabízejí se ti zaměstnanci, kteří mají

Opv01/Popis/Status vztahu osoba zaměstnanec hodnotu 3 - PV nepočítané

a nemají jiný PV se statusem 1, 2 a mají datum ukončení menší než datum z hlavičky.

Správa promazání / Uchazeči k promazání

Položku Rea01 / Smazat do bereme pro toto mazání jako nadřazenou.

Režim Úplné smazání údajů o uchazeči bereme jako "silnější" takže jím dovolíme zpracovávat i uchazeče, kteří již prošli mazáním v režimu "Ponechat identifikace a status".

Na záložkách Promazáno u zaměstnanců (uchazečů) je pak vidět, kdo procesem mazání prošel.

Výjimkou jsou úplně smazaní uchazeči, kteří jsou smazání opravdu úplně.

Zaměstnanec může také mazacím procesem projít vícekrát (pokud mu v prvním mazání bylo smazáno méně věcí, než bylo potřeba). K tomu slouží na záložce Promazáno u zaměstnanců: tlačítko "Vrátit akt. osobu mezi nepromazané".

3.7 Adm14 - Konfigurace Elanor Workflow

Okno slouží k podrobnému popisu akcí při jednotlivých krocích procesního workflow.

3.7.1 Definice workflow

Správce nastavuje pro jednotlivá workflow v každé v db zpracovávané organizaci (Adm21) resp. lze nastavit i společný workflow popis pro všechny organizace:

· každé workflow používá konkrétní, aplikací (nejčastěji nějakým JPČ) dané hodnoty

· na kroku workflow se definuje, kdo je adresátem dalšího kroku (pomocí pravidel)

· a jaká informace má jít (maska zprávy) a její kanál (interní pošta / externí pošta)

· adresáty dělíme na primární a sekundární, ti se mohou účastni schvalování a další, kteří pouze obdrží informaci. V případě odeslání notifikace na e-mail primárního příjemce a sekundárního a dalšího příjemce je možné nastavit typ e-mailu, na který má být notifikace odeslána. Pokud má osoba, na kterou má být e-mail odeslán, zadán typ e-mailu uvedený jako primární typ, notifikace bude odeslána na tento typ e-mailu. V případě, že nemá primární typ e-mailu zadán, notifikace bude odeslána na sekundární typ e-mailu

· v popisu následujícího kroku se pak pomocí položky Typ schvalování určuje charakter zpracování:

0 Pouze oznámení

1 Schválení 1. primárním příjemcem z min.kroku

Je potřeba, aby pravidlo určovalo jednoznačně jednu osobu, jinak aparát vybere jednu náhodnou z těch, které pravidlo vrátí

2 Schvalování více prim. a sek. příjemci z min.kroku (vyjádří se všichni, musí schválit)

11 Schval. více prim. a sek. příjemci z min.kroku (postačí, když odpoví jeden)

12 Schval. více prim. a sek. příjemci z min.kroku (postačí, když jeden zamítne)

Pozn. pro 2,11,12:

Více příjemců může vzniknout buď tím, že jich pravidlo (primárního) příjemce jich vrátí více, nebo tím, že je definovaný primární a sekundární příjemce.

Obvyklý postup je nastavovat workflow během implementace z předlohy dodané konzultantem ve formě změnového skriptu a jeho následným přizpůsobení.

Plný výčet workflow je v číselníku Jpc01 / wfl_akce

Konkrétní popisy realizovaných workflow:

viz „Akce workflow“ 11 - Schvalování cestovního příkazu (Cep_uzdoc kap. 4.3.3 obsahuje i podrobný popis nastavení)

viz "Akce workflow" 101 - 129 eProposal (Epr_uzdoc)

Zpráva, kterou krok workflow definuje, se zapisuje do pole "Předloha oznámení".

U kroků s definovaným schvalováním se může použít i "Předloha oznámení - zamítnutí".

Když předloha vyplněna u schvalování není, použije se "Předloha oznámení" jako společná předloha. Hodnota schválení/neschválení se pak v textu promítá pomocí makra pro Status.

Předmět e-mailu a název (kroku) workflow zobrazující se v přehledu workflow pro mobilní zařízení a detailu workflow na HR Portálu se přebírá z položky "Název workflow kroku". I zde je možné používat ta samá makra, která nabízí editor pro dané workflow v Předloze oznámení.

Př. U WFL 15, krok 0=>15 je možné například dát do Názvu workflow kroku text:
%JMENO_CELE% - Žádost o schválení SLM %SLM_NAZEV% %DATUM_OD%-%DATUM_DO%.

Pozn. Pokud má organizace vyplněného univerzálního odesílatele všech EGJE e-mailů (Adm21/Par.komunikace/Adresa odesilatele všech e-mailů z EGJE (nepov.))
je na konec e-mailu automatizovaně přidáván Od/From: a skutečný odesílatel, aby bylo patrné, od koho vlastně e-mail je. Do tohoto pole se vkládá pouze emailová adresa bez dalšího textu. Pokud by bylo požadováno vložit doplňkový text, jako je například Administrátor<admin@ccc.cz>, je možné tento doplňkový text vložit do pole „Popisek e-mailu:“ a tento popisek bude následně přidán a zobrazen ve výše uvedeném příkladu (tučně).
Obsah obrázku text, snímek obrazovky, číslo, software

Popis byl vytvořen automaticky

V Adm14 se evidují 2 typy workflow akcí:

Akce schvalované pomocí formuláře Wflow (resp. pomocí tlačítek na spec. formulářích):

1-4, 11-130

Akce kde se workflow aparát používá hlavně pro definice hlášení a kde neprobíhá žádný schvalovací proces, ale procesy jsou volány buď z formuláře (např. Kva06* nebo z úlohy Adm53) se editují na Adm33

5-8

Workflow se dá také ladit tzn. neodesílat zprávy nebo odesílat a logovat správy.

To se nastavuje položkou Režim ladění workflow: s hodnotami:

1 - Standard - Odesílat workflow zprávy

2 - Workflow zprávy odesílat a logovat

3 - Workflow zprávy neodesílat a logovat

V záložce Log je potom prohlížení zapsaných informací.

Upozornění: používejte logování pouze krátkodobě pro ladění nebo řešení potíží, nikoliv trvale, generuje velké množství dat!

3.7.2 Pravidla výběru příjemce kroku workflow

Pravidlo se používá pro:

· určení, kdo bude provádět schvalování dané dalším krokem

· určení, kdo obdrží zprávu (e-mail resp. interní EGJE Mail)

Ø Režim odesílání zástupci
Na formuláři Adm14, na kartě „Kroky workflow“ à „Detail“ à položka „Režim odesílání zástupci:“, je možnost pozastavit možnost odesílání emailu zástupci. V případě, že nastaven zástupce pro příjem emailu, je možno, touto volbou, pro krok WFL nastavit, aby právě v tomto kroku nebyl odeslán na zástupce (např. pokud je nutné odesílat veškerou poštu na zástupce, kromě pozvánek na školení) a nebyl zástupci zpřístupněn na formuláři Wflow. Tato možnost právě dovoluje toto možnost nastavit.

Standardně, pokud není uvedeno jinak, pravidla vyhledávají výsledek u časových přiřazení k referenčnímu datu.

Typy pravidel (JPČ wfl_pravidlo_typ):

Typ	Název typu	Doprovodné parametry
1	Manažer struktury (vlastní nebo uvedené ve výčtu) Pozn. jde o manažera definovaného na Str01/Str02 záložka Manažer/Osoba v EGJE (platné PV)	Typ struktury - povinný Výčet prvků struktury - nepovinný (nevyplněno => vlastní vzhledem k PV) Minimální hladina – nepovinný Pozn. Bez minimální hladiny hledá a najde vždy pouze jednoho Manažera/Osobu, ale v případě, že by to měl být sám zaměstnanec, stoupá po stromu výše. Zatímco uvedeme-li hladinu, a je-li tato hladina vyšší, nalezne pravidlo Manažery/Osoby z příslušné nadřízené hladiny. Je-li nižší, vrátí aktuálního manažera. U struktur, kde je povoleno více paralelních manažerů (Str01/Jméno struktura a jejich hladin/Smí být paralelně více manažerů/osob) se dá „zapnout“ režim více osob – je pak ale v dalším kroku potřeba zvolit typ schvalování 2,11,12 viz minulá kapitola. Hot znak % je vhodný pouze pro eProposal. Vybere všechny Manažery/Osoby a %ORG všechny, ale v rámci jedné organizace. Manažer je hledán k referenčnímu datu.
2	Osoba s konkrétní strukturou (typicky PM) (platné PV)	Typ struktury - povinný Výčet prvků struktury - nepovinný (nevyplněno => vlastní vzhledem k PV)
3	Manažer struktury cestovního příkazu	Typ struktury - povinný Výčet prvků struktury - nepovinný (nevyplněno => vlastní vzhledem k PV) Pozn. Jde o manažery struktur, které jsou definované na CEP v datovém okně Specifické zařazení do struktur.
5	Osoba, o níž workflow je
6	Autor workflow záznamu
7	Uvedená osoba	Osoba - povinný
8	Vzdělávací akce – lektoři
9	Vzdělávací akce - kontaktní osoby
10	Vzdělávací akce - autor požadavku
11	Manažer nadřízeného střediska (prvku struktury) Pozn. jde o manažera definovaného na Str01/Str02 záložka Manažer/Osoba v EGJE (platné PV)	Typ struktury - povinný Výčet prvků struktury - nepovinný (nevyplněno => vlastní vzhledem k PV) Minimální hladina – nepovinný Také zde se kontroluje, zdali manažer zaměstnance, o kterém je workflow, a manažer nadřízeného střediska není ta samá osoba. Pokud ano, hledá se manažer nadřízeného střediska tak dlouho dokud se nenarazí na jiného manažera, resp. na nejvyšší hladinu.
12	Zástupci manažera Pozn. jde o zástupce definované na Str01/Str02 záložka Zástupci (platné PV)	Typ struktury - povinný Výčet prvků struktury - nepovinný (nevyplněno => vlastní vzhledem k PV) Minimální hladina - nepovinný
13	Držitelé kompetence (ve výčtu) dle struktury (z celého stromu) Šplhá po zvolené struktuře (obvykle organizační) a hledá osoby, které buď přímo nebo přes PM mají určitou kompetenci. Určeno hlavně pro eProposal.	Typ struktury - povinný Výčet prvků struktury/kompetencí - povinný
14	Držitelé kompetence (ve výčtu) dle struktury (první nalezená hladina) Šplhá po zvolené struktuře (obvykle organizační) a hledá osoby, které buď přímo nebo přes PM mají určitou kompetenci. Hledání je zastaveno na té hladině struktury, na které je nalezena první osoba s určitou kompetencí. Pokud je na hladině nalezeno více osob s určitou kompetencí a Typ schvalování je 1 - Schválení 1. primárním příjemcem z min. kroku, pak je vrácena osoba s nejnižším OSČPV (neplatí pro eProposal). Ze seznamu nalezených osob jsou vyřazeny osoby/PV, o kterých je workflow, nebo které sedí na PM, o kterém je workflow. Pozn. kompetence se eviduje na PM v Pmi01 u Osob pak v Kva02.	Typ struktury - povinný Výčet prvků struktury/kompetencí – povinný
15	Držitelé kompetence (ve výčtu) dle stru. s min. hladinou (z celého stromu) vrací unikátní a setříděný seznam schvalovatelů, kteří mají přiřazenou zadanou kompetenci. Kompetence může být přiřazena buď přímo, nebo přes pracovní místo. Seznam schvalovatelů je sestaven na základě průchodu prvků zadaného typu struktury. Při tom se hledají osoby s přiřazenou kompetencí, které jsou zařazeny na navštívené prvky struktury. Prohledávání prvků struktury probíhá následujícím způsobem: o Jako výchozí prvek struktury se použije prvek, na který je přiřazen zaměstnanec či pracovní místo, o němž je schvalované workflow. o Z tohoto prvku se postupuje po stromu struktury vzhůru, dokud není dosažena nastavená minimální hladina. o Následně se ještě prozkoumají všechny prvky daného typu struktury, které leží na zadané hladině.	Typ struktury – povinný Výčet prvků struktury/kompetencí – povinný Minimální hladina – povinný
24	Držitel kompetence (nad manažerem uchazeče dle stru 2 - první nalezený) Analogické pravidlu 14 se specifikovanou strukturou 2 s tím, že výchozí osobou je uchazeč a nikoliv osoba/PV. Je to použitelné, když se uchazeč hlásí na Výběrové řízení (Rec01) definované na PM (resp. přímo na org. středisko, což se ale nepoužívá). Výchozím bodem hledání vzhůru (po struktuře 2 a na nich zařazených PM a Osobách) popsaném v kroku 14 je tedy org. středisko, na kterém je toto PM.	Výčet prvků struktury/kompetencí – povinný Pozn. struktura je vždy 2.
31	Manažer zadavatele – vychází ze zadavatele a nikoliv z osoby, o které je workflow	Pravidlo pracuje s manažery struktury. Toto pravidlo sice vychází z osoby, ale na rozdíl od ostatních pravidel, která vždy vycházejí z osoby, o které workflow je, toto pravidlo vychází z osoby, která workflow zadává. U pravidla je respektována minimální hladina struktury a také je u něj zohledněno, aby pravidlem vrácená osoba byla různá od osoby, která workflow zadává. Dokud není, hledáme (opakovaně) manažera na hladině o jednu vyšší.
51	Manažer struktury k datu od ze schvalovaného záznamu	Primárně pro schvalování dovolených (WFL 15), manažer je hledán k datumu od schvalované dovolené. Další workflow - které datum je bráno: 1 - Přechod mezi středisky Referenční datum 2 - Finanční schvalování vzdělávání AKCE OD 3 - Schvalování požadavku na vzdělávání PLÁN OD (cehtosozpuspoz.plan_od) 4 - Schvalování účasti na vzdělávací akci AKCE OD 5 - Pozvánky na vzdělávací akci AKCE OD 6 - Zpráva o nedosažení min. počtu na vzděl. akci - 7 - Zpráva o odhlášení ze vzdělávací akce AKCE OD 8 - Zpráva o expiraci period. způsobilosti PLATNOST DO (cehtosozpus.platnost_do) 11 - Schvalování cestovního příkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 12 - Specif. schvalování zahraničního cestovního příkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 15 - Schvalování SLM I. až 20 - Schvalování SLM VI. DATUM OD (cedmes.datum_od) 30 - Schvalování žádosti o podpisové kompetence a vzory ŽÁDOST OD (cehtosokzad.datum_od) 32 - Schvalování žádosti o mobilitu KB JSEM PŘIPRAVEN NA MOBILITU OD: (cetpvmobkbpoz.datum) 33 - Schvalování požadavku na vzd. obecné kurzy PLÁN OD (cehtosozpuspoz.plan_od) 34 - Schvalování benefitů I. a 35 - Schvalování benefitů II. PRVNÍHO Z cehtosobencerpwfl.kod_obd 40 - Schvalování uchazeče DAT.NÁSTUPU RESP. PŘEDPOKL.NÁSTUPU (coalesce(ceroso.dat_nast,ceroso.dat_nast_predpokl) 59 - Zprávy o změnách pers. údajů SKA DATUM ZMĚNY (cetpvwflska.dat_zmeny) 61 - Prohlášení poplatníka 1.1.ROKU, když jde budoucí rok (cetdanprohl.rok) 62 - Roční zúčtování daně 1.1.ROKU, když jde budoucí rok (cetdan.rok) 211 - Schvalování předschváleného cestovního příkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 212 - Schvalování předschváleného zahraničního cestovního příkazu DAT.ZAHÁJENÍ (cepprik.datum_od) 301 - Oběh dokumentů 01 až 399 - Oběh dokumentů 99 PLATNOST OD (cetpvdok.platnost_od)
111	Chová se jako pravidlo 11 před e201805	Dočasné pravidlo. Plánujeme jej zrušit v e201809 či e201811.

U pravidel 1,11,12 tj. typ manažer, se vychází z osoby/PV, o které krok workflow je, zjistí se, na který prvek struktury (pro typ struktury) je přiřazena. Pro tento prvek se pak zjišťuje konkrétní osoba/osoby, které jsou uvedené na záložkách Manažer / Osoba v EGJE resp. Zástupci formulářů Str01/Str02. Tato osoba bude adresátem kroku workflow/zprávy.

Nejčastěji jde o strukturu typu 2 - Organizační struktura, nebo strukturu, která ji supluje.

Suplující struktura bývá často přiřazena k Organizační struktuře (tj. nepřímo stupeň 2) a výjimky pak se uvádí na struktuře 3 - Pracovní místo respektive přímo na PV.

U organizační struktury není povoleno, aby na jednom prvku struktury bylo více osob manažerů,

nicméně u některých, hlavně referentských, struktur tomu tak je.

V tomto případě je třeba použít definici typu schvalování pro více osob (viz min. kapitola, pravidla 2, 12, 22).

Pro oblast eProposal, kde výběr příjemce ovlivňuje autor eProposalu, je možné u pravidla 1 použít symbolický výčet struktur "%". Zadavatel eProposal pak manažera vybírá z comba všech manažerů resp. "%ORG", který umožní totéž, ale s omezením dle příslušnosti manažera (osoba/PV) k organizaci.

U pravidel 13 a 14 je důležité rozlišovat, zda kompetence je přidělena přímo osobě, anebo je přidělena přes PM.

V případě, že je kompetence přidělená přímo osobě, tak hledání schvalujících osob probíhá tak, že se nejprve najde výchozí středisko z Typu struktury, tzn. středisko, ze kterého se začíná hledat, a postupně se nasbírají všechna jeho nadřízená střediska až k první hladině Typu struktury. K seznamu nalezených středisek se dohledají jen ty osoby, které mají platné PV a mají platnou některou z platných kompetencí uvedených ve výčtu.

V případě, že je kompetence přidělená osobě přes PM, tak hledání schvalujících osob probíhá tak, že se nejprve najde výchozí středisko z Typu struktury, tzn. středisko, ze kterého se začíná hledat, a postupně se nasbírají všechna jeho nadřízená střediska až k první hladině Typu struktury. K seznamu nalezených středisek se dohledají všechna platná PM, která mají platnou některou z platných kompetencí uvedených ve výčtu. A k takto získaným PM se následně dohledají jen ty osoby, které mají platné PV.

Výchozím střediskem pro workfow o osobě/PV je středisko, ke kterému má zadávané PV osoby platné přiřazení a výchozím střediskem pro workflow o PM je středisko, ke kterému má zadávané PM platné přiřazení.

Častou situací je použít pro primárního příjemce (tj. příjemce, který schvaluje) pravidlo 1 - Manažer a pro Sekundární resp. Další příjemce pravidlo 12 - Zástupci manažera. Zástupce manažera se tedy o žádosti dozví, ale primárně se mu ve Wflow k odsouhlasení nenabízí. Pouze pokud dostal profil pro zastupování manažera (Adm15, Adm01), může, pokud se pod ním přihlásí provést ve Wflow příslušné přihlášení místo manažera.

3.7.3 Makra předloh oznámení

Předlohy oznámení jsou jazykově sledované texty. Jazyk se ale určuje dle odesilatele kroku. Někteří tedy vytvářejí dvojjazyčné texty.

Vlastní předlohy jsou buď textové, nebo html. Do html však nedávejte žádné grafiku/obrázky přímo. Vždy pouze odkazem.

Od e201503 je text e-mailu, interního mailu resp. Wflow generován pro WF 11-20 v jazyce příjemce.

Aparát workflow se pro akce 11-20 tj. CEP a schvalování SLM snaží podle příjemce a jeho jazyka uvedeného u přiřazení profilů, zjistit jaký je jazyk příjemce a v něm pak zprávu vytvořit.

Celé je to ovšem podmíněno existencí předlohy zprávy (Adm14) v tomto jazyce.

V java klientu v editoru předlohy jsou nabízena makra i s popisem v lokálním 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.

Makra použitelná v Předlohách oznámení resp. v Názvu workflow kroku (jde do předmětu e-mailu):

Nejprve funkčnost platná pro všechny předlohy:

Pokud makro %TEXT% v předloze uvedené není, dojde k jeho připojení na konec textu zprávy. Toto platí pro úplně všechna workflow.

V makru TEXT, pokud není dále uvedeno jinak, bývá nejčastěji textová poznámka při schvalování.

Makra pro všechna workflow:

%ID_SWORKFLOW2% ID - unikátní identifikátor workflow kroku

%JMENO_BEZTIT% - osoba, o které je WFL ve tvaru Jméno Příjmení

%JMENO_CELE% - osoba, o které je WFL ve tvaru Příjmení Jméno Tituly

%JMENO_CELE_BEZTIT% - osoba, o které je WFL ve tvaru Příjmení Jméno

%ROZHODL% cesworkflow2.id_toso_rozhodl Příjmení Jméno OSCPV(z kmen. PV) uživatele, který rozhodl (tj schválil resp. zamítl) krok workflow

%ROZHODL_JMENO_BEZTIT% tj. %ROZHODL% ale ve formátu Jméno Příjmení

%ROZHODL_JMENO_CELE% tj. %ROZHODL% ale ve formátu Příjmení Jméno Tituly

%ROZHODL_JMENO_CELE BEZTIT% tj. %ROZHODL% ale ve formátu Příjmení Jméno

%EMPNR_ROZHODL% - osobní číslo

%AUTOR% - Autor ve tvaru Příjmení Jméno OSCPV(z kmen. PV)

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

%STATUS_NEW% - hodnota statusu po odsouhlasení/zamítnutí

%STATUS_NEW_EN% - vždy anglický text, bez ohledu na jazyk příjemce

%STATUS_NEW_SK% - vždy slovenský text, bez ohledu na jazyk příjemce

%STATUS_OLD% - původní hodnota statusu

%STATUS_OLD_EN% - vždy anglický text, bez ohledu na jazyk příjemce

%STATUS_OLD_SK% - vždy slovenský text, bez ohledu na jazyk příjemce

%WEB2% odkaz na EGJEWEB2 z Adm21 - v html řešen včetně uzavření do <a> a </a>

%WEB2URL% odkaz na EGJEWEB2 z Adm21 - bez uzavření <a> a </a>
Pro doplnění odkazu o formulář atp.
př. %WEB2URL%/#form=Wflow&formParams=%ID_SWORKFLOW2%

vede na https://xxxxx.cz/#form=Wflow&formParams=15929388

Případně, pokud máte v Adm21/Parametry komunikace/ http(s) adresa EGJEWeb(2) uvedenou adresu s lomítkem na konci, již ho nedávejte do adresy zde. Tedy např.:

%WEB2URL%#form=Wflow

WF 1 - Přechod mezi středisky

%EMPNR% - osobní číslo

%STATUS_NEW% hodnota statusu akce

%TEXT% text akce

WF 2 - Finanční schvalování vzdělávání

+ WF 4 - Schvalování účasti na vzdělávací akci

makra WF 5 a dále:

%EMPNR% - osobní číslo

%PRICE_ORG% - cena organizace

%MANAGER_MAIL% - e-mail manažera

%MANAGER_ID_TOSO% - manažer

%STATUS_NEW% - hodnota statusu po odsouhlasení/zamítnutí

%STATUS_OLD% - původní hodnota statusu

%TEXT% - textová poznámka při schvalování

%ID_HZPUS% = cehzpus.id_hzpus Způsobilost (kurzu)

%ID_HZPAKCE% = cehzpakce.id_hzpakce Vzdělávací akce

%REFERENT_JMENO% (pouze Jméno, Příjmení)

%REFERENT_PMI% (str3, pouze název prac. místa)

%REFERENT_TEL% (druh komunikace 12, pouze hodnota)

%NAHR_POCET% - Počet aktuálně přihlášených náhradníků

%ESTIMATED_COSTS% - Cena za jednoho účastníka: Kva06/Náklady na vzdělávání/Cena za jednoho účastníka

WF 4 - Schvalování účasti na vzdělávací akci
má navíc:

%KB_STRAVA_ZADOST% - atribut žádosti Kva16fkb

%KB_UBYTOVANI% - atribut žádosti Kva16fkb

%KB_DOPRAVA% - atribut žádosti Kva16fkb

%KB_SPECIFIKACE% - atribut žádosti Kva16fkb

%KB_POZNAMKA% - atribut žádosti Kva16fkb

WF 3 - Schvalování požadavku na vzdělávání

%OSCPV% - osoba OSCPV

%KOD_ZPUS% - kód způsobilosti

%NAZEV_ZPUS% - název způsobilosti

%SOUHRN_ELA% - souhrnné údaje o požadavku

%MISTO_KON% - místo konání

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

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

%REF_VZDEL% - referent vzdělávání

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

%SPEC_KURZ% - specifikace požadavku

%NAZEV_AKCE% - zvolená akce

%AKCE_OD% - akce od

%AKCE_DO% - akce do

%ID_DODAVATEL% = cehzpus.id_hzporgskol

%CENA_ORIENT%= cehzpus.cena_orient

%TEXT% - textová poznámka při schvalování

%ID_HZPUS% = cehzpus.id_hzpus Způsobilost (kurz)

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

Oscpv Příjmení Jméno Status_PV

WF 3 a WF 5 Pozvánky na vzdělávací akci

%EDU_PLACE_ADR% Místo škol. adresa

%HOURS_FROM_TO% Hodiny od – do

%SPECIF% Specifikace (body obsahu)

%EDU_ORG% Školící organizace

%LECTORS% Lektor (resp. Lektoři) - příjmení jméno tituly.

%CONT_PER% Seznam kontaktních osob – když jich je více, vypíše všechny

%NR_DAYS% Počet dní

%NR_HOURS% Počet hodin

%HOURS_FROM_TO% Hodiny od – do

%HTML_LINK% - Odkaz (web, ze způsobilosti)

%CONTENT% - Obsah kurzu (ze způsobilosti)

%LITER% - Literatura (ze způsobilosti)

%PARTIC% Počet účastníků

%MIN_PARTIC% Minimální počet účastníků

%ESTIMATED_COSTS% - Předpokládané náklady (cena_jeden)

WF 11, 12 Schvalování cestovního příkazu

%CISLO_CP% - číslo cestovního příkazu

%CP_DESC% - pracovní cesta - plný popis

%CP_DESC_MINI% - pracovní cesta - zkrácený popis

%CP_DESC_PRU% - klon makra %CP_DESC%, který u datumových (datum zahájení cesty, datum ukončení cesty), časových (čas zahájení cesty, čas ukončení cesty) a lokalitu (místo konce cesty) specifikujících hodnot vychází z průběhu cesty.

%TEXT% - textová poznámka při schvalování

%ZALOHA_POZ% - požadovaná záloha

%STATUS_NEW% - hodnota statusu po odsouhlasení/zamítnutí

%STATUS_OLD% - původní hodnota statusu

%ID_VAL% - interní jednoznačný identifikátor pracovní cesty

WF 15 - 20 Schvalování dovolené a jiných SLM vedoucím

%SLM_NR% %SLM_NAZEV% - číslo a název schvalované SLM

%DATUM_OD% %DATUM_DO% - začátek a konec dovolené (resp. jiné SLM)

%DETAIL_OD% %DETAIL_DO% - detail

%POZN% - textová poznámka při schvalování (obsahuje i generované info o přečerpání nároku)
Pozor, nepotlačuje tisk komentáře na konec textového bloku

%TEXT% - textová poznámka při schvalování (obsahuje i generované info o přečerpání nároku)
Jeho použití potlačuje tisk komentáře na konci textového bloku

%STATUS_NEW% - hodnota statusu po odsouhlasení/zamítnutí

%STATUS_OLD% - původní hodnota statusu

%ID_VAL% - interní jednoznačný identifikátor dovolené (resp. jiné SLM)

Makra s přímým 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 Příjmení Jméno Oscpv(z kmen. PV)

%STRU% - K zadanému prvku struktury zobrazí KOD – NAZEV a když struktura na požadavku není, tak pole zůstane prázdné
(strukturu lze zadat na Vst15, typ se určí na Adm21)

WF 21 Schvalování SLM IV.

%STATUS_NEW% - hodnota statusu po odsouhlasení/zamítnutí

%TEXT% - začátek a konec dovolené (resp. jiné SLM)

%ALL_RECORDS% - zobrazuje hodnoty osčv – jméno – částka

%ALL_RECORDS_POZN% - zobrazuje hodnoty osčv – jméno – částka - poznámka

%KOD_DOKLADU% - kód dokladu

%NAZEV_DOKLADU% - název dokladu

%KOD_OBDOBI_DOKLADU% - kód období dokladu

WF 32 - Schvalování žádosti o mobilitu KB

%MOBPOZ_DATUM%, %MOBPOZ_TYP%, %MOBPOZ_STATUS%

resp. standardní typu %OSCPV%, %JMENO_CELE%

WFL 34, 35 – Žádost o benefit

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

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

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

WFL 40 – Uchazeči Rew01

%JMENO_CELE% - celé příjmení a jméno uchazeče (s tituly)

%EMAIL% - e-mail uchazeče pro výběrové řízení

%VYB_RIZ% - název výběrového řízení

%VYB_RIZ_OD% výběrové řízení od

%VYB_RIZ_DO% výběrové řízení do

%DAT_NAST_PREDPOKL% předpokládané datum nástupu

%DAT_NAST% datum nástupu

%REF_UCHA% - referent uchazeče

%STATUS_NEW% - hodnota statusu po odsouhlasení/zamítnutí

%STATUS_OLD% - původní hodnota statusu

WF 101 - 126 eProposal

Jelikož eProposalů je hodně typů, velmi často se používá implicitní text oznámení, který aplikace vytvoří, když je předloha prázdná.

%JMENO_CELE% - celé jméno osoby, o níž je eProposal (pouze u změnových eProposalů o osobě a PV).

%SKUPINA_EPR% - název skupiny eProposalu

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

%VALID_FROM% - platnost Od daného eProposalu

%VALID_TO% - platnost Do daného eProposalu

%DETAIL% - detailní výpis hodnot v daném eProposalu

%STATUS_NEW% - hodnota statusu workflow po odsouhlasení/zamítnutí

%STATUS_OLD% - hodnota původního status workflow

%TEXT% - obsah položky "Další upřesnění" i s popiskem, pokud je vyplněna.

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

%AKT_SCHVALUJE% - aktuální schvalující daného kroku eProposalu.

%ROZHODL% cesworkflow2.id_toso_rozhodl Příjmení Jméno Oscpv(z kmen. PV)

WF 301 - 399 Dokument

%JMENO_CELE% - celé jméno osoby

%PLATNOST_OD% - platnost Od dokumentu

% PLATNOST_DO% - platnost Do dokumentu

%STATUS_NEW% - hodnota statusu workflow po odsouhlasení/zamítnutí

%STATUS_OLD% - hodnota původního status workflow

%SOUBOR% - Název souboru z dokumentu

%TYP_SOUBORU% - Typ souboru z dokumentu

%TYP_DOKUMENTU% - Typ dokumentu

%ROZHODL% cesworkflow2.id_toso_rozhodl Příjmení Jméno Oscpv(z kmen. PV)

%VSECHNYPOZN% - vypíše všechny poznámky od všech schvalovatelů s komentářem

%TEXT2_POZN% - zapíše auditní stopu i v případě, že nemá vyplněný komentář

ke schválení dokumentu

Upozornění: Workflow používá (volitelně) komunikaci pomocí externí pošty (e-mailu). Aby byly e-maily ze systému odesílány je zapotřebí nastavit "Konfiguraci připojení k poštovnímu serveru" - viz EGJE_provdoc.

3.7.4 iCalendar

Na záložce „Č. iCalendar“ lze upravit obsah zprávy pro iCalendar.

Lze vyplnit položku „Předmět zprávy“. V položce lze použít stejná makra jako v předloze oznámení. Pro zrušení zprávy se k předmětu automaticky přidá sufix „ – zrušení“.

Pokud je vyplněná položka „Posun notifikace iCalendar…“ nastaví upozornění o XX minut před začátkem události.

Lze zadat organizace, pokud je nevyplněná je záznam platný pro všechny organizace.

V tabulce jdou zadávat parametry a jejich hodnoty které se do zprávy mají vložit. Lze nastavit parametry pro MS Outlook například X-MICROSOFT-CDO-BUSYSTATUS s hodnotou WORKINGELSEWHERE. Více informací viz dokumentace k parametrům MS.

3.7.5 Konkrétní workflow

V kapitole popisujeme workflow, která nejsou popsána jinde.

3.7.5.1 Akce 15-20 Schvalování dovolené a dalších nepřítomností

Akce je popsána v Dov_uzdoc/ Dov05.

A to včetně možnosti zápisu do kalendáře pomocí generování zpráv iCalendar pro definované SLM a možnosti přidat k některým žádostem přílohu.

3.7.5.2 Akce 32 - Schvalování žádosti o mobilitu KB

Workflow figuruje ve formulářích Mob01 a Wflow.

Odvíjí se okolo statusu mobpob_status:

0 Koncept

1 Zamítnuto

2 Ukončeno

3 Neaktuální

4 Nepřijetí nabídky

10 Odesláno ke schválení

19 Editace konzultantem

20 Schváleno

21 Schváleno (po editaci)

30 Realizováno

Žádost se podává na záložkách Závěr a odeslání a v Adm14 je popsána krokem 0 => 10

jeho příjemce pak schvaluje následujícím krokem 10 => 20 (1 zamítnuto).

Na záložkách Konzultant pak jsou tlačítka, která umožňující úpravu workflow konzultantem.

tj. akce 20 => 19 a následné uložení změny s potvrzením zadaných změn 19 => 21 resp. návrat k původním hodnotám 19 => 20.

Konečná úprava se provádí na záložkách HR, kde jsou dispozici akce ze statusu

20 (resp. 21) => 30 (realizace workflow)

nebo na 3 či 4.

Tabulka kroků workflow je tedy taková:

*Hodnota WFL statusu*	*Konečný status*	*Konečný status - zamítnuto*	*Název workflow kroku*
0 - Koncept	10 - Odesláno ke schválení		Vytvoření požadavku na mobilitu
10 - Odesláno ke schválení	20 - Schváleno	1 - Zamítnuto	Schválení požadavku na mobilitu
19 - Editace konzultantem	20 - Schváleno		Zrušení editace požadavku na mobilitu konzultantem
19 - Editace konzultantem	21 - Schváleno (po editaci)		Konec editace požadavku na mobilitu konzultantem
20 - Schváleno	19 - Editace konzultantem		Editace požadavku na mobilitu konzultantem
20 - Schváleno	3 - Neaktuální		HR zapsalo požadavku na mobilitu status neaktuální
20 - Schváleno	30 - Realizováno		HR zapsalo realizaci požadavku na mobilitu
20 - Schváleno	4 - Nepřijetí nabídky		HR zapsalo požadavku na mobilitu status Nepřijetí nabídky
21 - Schváleno (po editaci)	3 - Neaktuální		HR zapsalo požadavku na mobilitu status neaktuální
21 - Schváleno (po editaci)	30 - Realizováno		HR zapsalo realizaci požadavku na mobilitu
21 - Schváleno (po editaci)	4 - Nepřijetí nabídky		HR zapsalo požadavku na mobilitu status Nepřijetí nabídky

Poznámky k formuláři Mob01:

· žádost se smí kopírovat pouze ve statusu 4 a to uživatelem HR

· uživatel s právem VL_OSO (tj. zaměstnanec):

o nikdy nevidí a needituje komentáře záložek Konzultant a HR

o komentář schvalovatel vidí, ale needituje

o editovat data smí jen ve statusu 0

· manažer - měl by na formulář mít pouze právo 1 čtení (svůj komentář vyplní ve Wflow)

· konzultant - má speciální objekt práv Mob01konzultant

o když má toto právo, tak vše má pouze pro čtení s výjimkou záložky Konzultant

o dále pak smí stisknout ve statusu 20 tlačítko Otevřít k úpravě (zál. Konzultant) - to přepne status do 19

o a ve status 19 pak tlačítko "Ukončit úpravy" (status => 21) nebo "Uzavřít úpravu - beze změny" (status zpět na 20 s návratem hodnot uložených při předchozí akci)

o ve statusu 19 smí konzultant editovat vše, krom záložek Schvalovatel a HR.

· HR - má speciální objekt práv Mob01hr

o když má toto právo, tak vše má pouze pro čtení s výjimkou záložky HR

o ve statusu 20, 21 má k dispozici tlačítka

· Realizovat (status => 30 )

§ Neaktuální (status => 3)

§ Nepřijetí nabídky (status => 4)

o Pozn. všechny tři tlačítka přes worfklow generují zprávy na všechny zúčastněné

o Ve statusu 4 má povolenou funkci kopie - vytvoří se nová žádost se statusem 20
Jsou zkopírovány hodnoty kromě komentářů + aktualizace datumu požadavku. Do komentáře HR o pohovoru je vložen Kopie požadavku + datum.

· admin má speciální objekt Mob01statusAdmin

o smí editovat status, ať je v něm jakákoliv hodnota

3.7.5.3 Akce 82 - 85 - Hodnocení

· Nové hodnocení spojené s workflow. V současnosti máme 4 samostatná schvalování:

o 82 – Sebehodnocení

o 83 – Hodnocení osoby manažerem

o 84 – Sebehodnocení cílů

o 85 – Hodnocení cílů manažerem

· Dvojice 82 a 84 mají stejné stavy workflow:

- 0 Koncept

- 50 Odeslání notifikace

- 100 Vyplněno zaměstnancem

- 105 Kalibrace

- 110 Vráceno do opravy manažerem

- 120 Vráceno do opravy schvalovatelem

- 130 Žádost o stažení

- 200 Posláno ke schválení

- 250 Přizvání schvalovatelů

- 300 Schváleno

· Resp. 83 a 85:

- 0 Koncept

- 50 Odeslání notifikace

- 300 Vyplněno manažerem

- 305 Kalibrace

- 320 Vráceno do opravy schvalovatelem

- 400 Přizvání schvalovatelů

- 500 Schváleno

3.7.5.4 Akce 301-399 - dokument Workflow

· Dokument workflow je samostatně obchodovaná komponenta a mají ji zpřístupněnu jen ti zákazníci, kteří jej zakoupili

· Stručně: dokument může podléhat worfkflow, pokud je záznam v Opv31 s takovým typem dokumentu, u kterého je v Jpc01, uchaz_dok_typ označeno workflow jako dobrovolné nebo povinné.
Další podmínkou je zařazení typu pod jednu z workflow akcí zde, v Adm14.

· Vlastní nastavení v Adm14

WFL akce 301-399 obsahuje položky:

Rtf2* ukládané do Opv31 poslat do schvalování - Ano/Ne default Ne

Omezit pouze na SJ: (volitelné omezení)

WFL se smí účastnit zastupující: JPČ dok_zastup:

0 - Ne

1- Ano, odesílat i původnímu adresátovi,

2- Ano, neodesílat původnímu adresátovi

a podzáložky:

Záložka Typy dokumentů:

Tabulka umožňuje zadat typy dokumentů (JPČ uchaz_dok_typ), které budou pod workflow spadat. Jeden typ dokumentu smí být podřízen pouze jednomu workflow.

Upozornění: každý typ dokumentu, který zde uvádíte, musí mít také definováno v Jpc01, číselník "uchaz_dok_typ", tedy tam kde je typ dokumentu definován, hodnotu

"Opv31 - typ schvalování dokumentu:"

1 - Může a nemusí být schvalovaný/podepisovaný

nebo

2 - Musí být schvalovaný/podepisovaný

Dle toho je pak jeho odeslání na schvalovací proces z Opv31 dobrovolné nebo povinné.

Záložka Statusy

Tabulka umožňuje zadat seznam/číselník statusů této akce

Pro tvorbu statusů platí tato pravidla:

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

· Zamítnutý musí mít status <0

· Koncept má status 0

Adm14 se pak v části kroky řídí těmito uživatelskými statusy.

Předlohy oznámení pak nabízí několik maker pro tato workflow.

· Opv31 / Workflow je popsán v Opv_uzdoc

· Sestavy Rtf2x

Sestava nastaví u uloženého dokumentu status worfklow = 0 - Koncept v případě že:

· uživatel chce výsledek sestavy uložit do Opv31

· je vybrán typ dokumentu, u nějž je v Adm14 nastaveno

Rtf2* ukládané do Opv31 poslat do schvalování = Ano

Dokument je pak možné z Opv31 odeslat do příslušného workflow.

3.8 Adm15 - Zastupování vlastní osoby

Umožňuje zadat časově omezené zastupování na vlastním profilu jiné osobě a pomocí tlačítka

"Odeslat zprávu o zastupování" odeslat zprávu ve tvaru:

Oznámení o zastupování

Zastupovaná osoba: celé jméno

Profil: profil

Od: datum_od

Do: datum_do

Technicky je zastupování na profilu popsáno v EGJE_Provdoc kap. Zastupování uživatele na profilu.

Zde popíšeme pouze položku "Odesílat WFL e-maily", kde má manažer na výběr jeden z režimů:

0 - Neodesílat

1 - Odesílat pro všechna workflow (mimo prav. vl. osoba 5,6)

2 - Dtto 1, ale neodesílat původnímu adresátovi

3 - Odesílat pouze schvalování SLM WFL15 (také mimo prav. 5,6)

4 - Dtto 3, ale neodesílat původnímu adresátovi

5 - Odesílat vše kromě CEP WFL11,12 (také mimo prav. 5,6)

6 - Dtto 5, ale neodesílat původnímu adresátovi

7 - Odesílat pouze CEP WFL11-14 (také mimo prav. 5,6)

8 - Dtto 7, ale neodesílat původnímu adresátovi

9 - Odesílat vše kromě WFL15 - dovolená aj. (také mimo prav. 5,6)

10 - Dtto 9, ale neodesílat původnímu adresátovi

11 - Odesílat pouze info zprávy o schválené SLM a prac.cestě

Hodnotou > 0 tedy zařídí to, že určité e-maily z workflow bude dostávat také zde, v Adm15, uvedený zástupce.

Hodnoty 1 - 10 jsou určeny pro ty zástupce, kteří zastupování v EGJE skutečně vykonávají,

zatímco hodnota 11 je určena těm, kteří pouze mají být informování o tom, že nějakému zaměstnanci byla schválena SLM (obvykle jde o dovolenou) resp. o tom, že někomu byla schválena pracovní cesta.

Pozn.: Takovému uživateli není nutné přiřazovat profil, přes který se jako zástupce do EGJE přihlásí, je to ale možné.

Režimy 3-6 pak vedou k tomu, že zástupce ve formuláři Wflow (resp. pruhu Zprávy základní obrazovky HR Portál) vidí jen určité typy workflow.

V jakých profilech může být manažer zastupován?

V těch, které má přiřazené a které mají v Adm02 vyplněnu položku "Zastupováno profilem". Jeho profil tedy buď není určen k zastupování, nebo může být zastupován tím samým profilem, nebo může být zastupován jiným profilem (obvykle s omezenými objektovými právy).

3.9 Adm19 – Klasifikace výstupů EGJE

Formulář umožňuje na PŘEDEM určených sestavách definovat text, který se následně bude zobrazovat v záhlaví sestavy. Kromě textu lze zvolit jeho barvu a platnost zobrazení. Jedná se např. o klasifikaci „VEŘEJNÉ“, „NEVEŘEJNÉ“, „TAJNÉ“. Kromě samotného nastavení na Adm19 musí ze strany Elanoru dojit k úpravě samotné sestavy. Převážně se jedná o uživatelské sestavy, standardní sestavy zatím podporované nebudou.

3.10 Adm20 – Pokyny ke stažení

Nový formulář, umožňuje vkládat soubory (do velikosti 5 MB) obsahující pokyny k jednotlivým formulářům/sestavám. Místo souboru lze vyplnit položku Odkaz(web). V takovém případě se ve webovém prohlížeči otevře daný odkaz. Při existenci souboru pro daný formulář/sestavu se na formuláři/sestavě objeví tlačítko, pomocí kterého lze soubor stáhnout a otevřít.

Lze zvolit jazyk souboru, kdy se přednostně vyhledává soubor s jazykem uživatele, pokud takový není potom soubor s jazykem CS, pokud neexistuje tak s EN, pokud neexistuje tak s nevyplněným jazykem.

Pokud se vybere správní jednotka, musí mít uživatel kmenové PV na dané správní jednotce. Při nevyplnění je soubor společný pro všechny.

Při vyplnění organizace musí být profil uživatele omezený organizací. V případě multiorganizačního profilu se musí jednat o hlavní organizaci. Při nevyplnění je soubor společný pro všechny.

Dokumenty mají datumovou platnost, načítají se k referenčnímu datumu.

Pokyny se otevírají tlačítkem „STÁHNOUT POKYNY“:

U standartního klienta :

- na formuláři - umístěným v horní liště vedle tlačítka pro vyhledávání.

- V dialogu - umístěným v horní liště vedle editačních tlačítek, pokud dialog horní lištu nemá, tlačítko se nezobrazí.

U webového klienta:

V referentském rozhraní:

- Na formuláři - umístěným v horní liště vedle tlačítka pro vyhledávání

V HR Portálu:

- umístěným v dolní liště vedle tlačítka „Aktualizace“

V dialogu pro referentské rozhraní i HR Portál:

- Malou ikonou otazníku nalevo od ikony na zvětšení/zmenšení dialogu.

- Tlačítkem pravé horní části dialogu.

3.11 Adm21 – Konfigurace - organizace

Individuální formulář o datech organizace

Navigace: Seznam organizací

Formulář umožňuje práci s daty a parametry společné pro celou zpracovávanou organizaci

Vlastní data o organizaci jsou organizována v záložkách.

Pozor! Podle toho, jestli je v db jedna organizace nebo více se systém EGJE chová jako jednoorganizační nebo více organizační. Tato informace je zjišťována na začátku každého sezení a u jednoorganizačních pro zjednodušení bývá často položka Organizace zastíněna a je vyplňována automatizovaně tou jedinou organizací, která v db je.

Změna typu databáze jedno<=>více organizační je závažnou změnou pro chování aplikace. Doporučujeme po kompletním provedení této změny restartovat AS resp. WEB EGJE server. Pro nastavení/změnu legislativy organizace / SJ platí totéž.

Záložka „Údaje o organizaci“

Obsluha: Popis, základní atributy organizace

Položky:

Kód organizace

Název (běžný pro interní sestavy a potřeby)

Název pro oficiální externí výstupy

Časové pásmo organizace

Hl. organizace

Implicitní kod jazyka

Zak

· Generování osobního čísla

Standardní způsob, kdy osobní číslo je generováno vzestupně z číselných hodnot (maximální plus jedna) je doplněn o další režimy.

Zvolený režim se nastavuje pomocí položek:

OSCPV - režim generování - s hodnotami:

0 - Standard (číselný se suffixem .pv),

1 - Konfigurovatelný - suffix .pv,

2 - Konfigurovatelný - bez sufixu.

3 - Režim prefixu ze SJ (různá IČO)

4 - Režim prefixu ze SJ (různá IČO) + společná řada

5 - Režim prefixu SJ bez oddělovače (různá IČO)

Pro režimy 1 a 2 potom režim specifikují doplňující položky:

OSCPV - délka suffixu - pouze pro režim 2 - povolené hodnoty 2 nebo 3 - suffix je používán pro číslo PV v rámci osoby,

OSCPV - celk.max.délka - určuje celkovou maximální délku (obě části a oddělovač),

OSCPV - doplňovat na max.délku - Ano / Ne
případné doplňování se provádí levostranně pomocí hodnoty nula „0“
To umožní, aby znakové osobní číslo PV bylo tříděno shodně s jeho číselným významem,

OSCPV - prefix pro organizaci
Položka umožňuje zadat až 3-místný prefix, který bude pro danou organizaci předsazován před generované číslo. Prefix je využitelný hlavně v režimu multiorganizace (více organizací v jedné instalaci EGJE),

OSCPV - generovat do proluk - Ano / Ne
Nová hodnota oscpv není hledána pomocí maximální hodnoty, ale je procházena celá použitá řada a nové oscpv je generováno do první proluky, jako první dosud nepoužité oscpv.

Uvedené algoritmy používá pro generování OSCPV Opv04 i Opv05.

Opv05 také vyžaduje, když je nakonfigurován režim, že OSCPV se skládá z OSC tečky a PV, aby OSC bylo u všech PV osoby (statusy 1-10) shodné.

Režimy generování OSČPV 3 - Režim prefixu ze SJ (různá IČO), 5 - Režim prefixu SJ bez oddělovače (různá IČO)

Opv05 (Opv04, Epr01, Rea01) používá řadu v rámci SJ s použitím údajů:

Adm22 / Konf.par. / Prefix SJ pro účetnictví resp. OSCPV

Adm22 / Konf.par. / Současné OSČ (režim 3)

K režimu 4 se na Adm21 váží ještě prvky

Adm21 / Údaje o org. / OSC délka

Adm21 / Údaje o org. / OSČPV - délka suffixu pro PV

Režimy 3, 5 na vyžádání zákazníka, který ale má některé diskutabilní prvky, neboť zařazení na SO/SJ je časově měnitelné.

Na rozdíl od běžných režimů v rámci neměnného zařazení osoby na organizaci zde používáme "počítadlo" umístěné na SJ (Adm22 / Konf.par. / Současné OSČ).

Při každém započetí zadávání nové osoby jej o 1 zvýšíme a to ve chvíli, kdy již v této situaci známe zařazení na SO/SJ.

Po převodech dat je tedy potřeba uvedené údaje nastavit, aby ručně zadávané osoby navázaly na převedená data.

K uvedenému se váží i parametry použitelné i pro ostatní režimy generování OSČPV:

Adm21 / Údaje o org. /

Uživatel - v Adm01p ponechat záporné OSCPV:

Lektor - v Kva06* ponechat záporné OSCPV:

Zatímco pro režim 3 je nastavení uvedených hodnot na Ano povinné, neboť uživatelé a lektoři se v těchto procesech na SO/SJ ani nezařazují, pro ostatní režimy generování OSCPV jde o novou možnost, kdy tyto osoby jsou dle záporného OSCPV jasně rozpoznatelné a nesdílejí číselnou řadu se zaměstnanci.

Dále je možné zadat ještě výrazy pro kontrolu OSCPV:

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

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

Sekundární kontrola OSCPV - ostatní statusy (regul.výraz):

To jsou regulární výrazy pro závěrečnou kontrolu OSCPV těsně před uložením do databáze.

Uplatněny jsou v Opv01, Opv05, Opv04, Adm11.

V EGJE je použita implementace reg. výrazů, která je v java JRE tzn. java.util.regex

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

zde je uveden seznam touto implementací podporovaných řídících kódů.

Příklad 1:

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

znamená, že oscpv může, ale nemusí začínat "-" pak 4 až 8 číslic. Povinná tečka. A 2 číslice za ní.

znak ^ znamená začátek

$ konec

v hranatých závorkách je množina znaků (často intervalově s pomlčkou, jinak na husto bez oddělovačů)

ve složených závorkách počet opakování zde je rozsah oddělen čárkou tedy {0,1} znamená že tam může a nemusí být a {4,8} znamená že znaků musí být mezi 4 a 8.

znak "." se musí psát s ecape tzn \.

V regulárních výrazech bývá více možností jak napsat podmínku - popisovaný příklad lze např. zapsat i takto ^-?\d{4,8}\.{1}\d{2}$

Příklad 2:

^(aa|bb)[A-Z]\d{4,6}\.{1}\d{2}$ znamená že musí začínat aa nebo bb, dále musí následovat libovolné velké písmeno, poté 4 až 6 číslic, dále musí být . a za ní 2 číslice

Materiály

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

použít jde i tento český (i když je k Perl nikoliv java implementaci) http://www.regularnivyrazy.info/regularni-vyrazy-zaklady.html

testovat je to možné na celé řadě míst, např. zde:

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

kde do Regular expression zadáte výraz připravovaný pro Adm21 a do Input1 testované oscpv a tlačítkem Test se provede test jestli oscpv výraz splňuje.

Záložka č. IČO

Výstupy celostátních výkazů a statistik bývají často vyžadovány za „vykazovací jednotku“, kterou je organizace.

Dříve využívaný model vycházel z předpokladů, že základní jednotou pro styk s okolím je správní jednotka (SJ). To však způsobovalo problém organizacím, které mají více SJ se stejným IČO a společně tak tvoří vykazovací jednotku.

Proto byl založen tento nový číselník „vykazovacích jednotek“.

Záložka „Konfigurační parametry“

Obsluha: Práce s konfiguračními parametry organizace

Položky:

Parametry organizace a jejich seznam

Záložka "Mazání"

Zadává se u hlavní organizace.

Definují se zde plošná odmazávání starších nepotřebných dat z pracovních tabulek, mzdových importů, vstupů, docházky, cestovních příkazů, exportních dávek.

Nově byl do této záložky přidán parametr pro mazání starých eProposals s názvem „Smazat eProposaly starší než (měsíců)“. Více v dokumentaci pro eProposal.

Záložka "EZM"

Pouze pro zákazníky EZM Elanor

Typ zákazníka - hlavní rozlišení pro určení konvence pojmenování souborů.

Záložka "Parametry komunikace"

Nastavení je popsáno v EGJE_provdoc - kapitola "Konfigurace připojení k poštovnímu serveru".

Dále obsahuje položky popsané v Parametry komunikace

V případě napojení na podpisový modul Signi je potřeba mít nastaven parametr: http(s) adresa EGJEWeb(2)

Záložka "Self service"

Umožní zadat detailnější požadavky u zaměstnaneckých žádostí:

Výčet druhů adres pro Pkz21:

Výčet druhů kontaktů pro Pkz21:

Vyžadovat přílohu pro změnu příjmení, jména nebo rodinného stavu v Pkz21:

Vyžadovat přílohu pro změnu zdravotní pojišťovny v Pkz21:

Vyžadovat přílohu zadání občanského průkazu v Pkz21:

Vyžadovat přílohu pro zadání rodinného příslušníka v Pkz21:

Vyžadovat ověření doložených příloh při schvalování v Pkz23:

Max velikost přílohy

Záložka "HR portál" - přizpůsobení designu organizaci

Na úrovni organizace je možné v nové záložce HR Portál zadat několik volitelných parametrů pro grafické odlišení obrazovek se spouštěcím menu HR Portál.

Záložka je rozdělená na sekce podle konfigurovaného objektu.

Sekce „Výplatní lístky“

V této sekci se dá pomocí parametru „Rozepsat SLM na VLI:“ zajistit rozpis SLM na výplatních lístcích pro formuláře Vyp11, Vyp11fq nebo Vyp31, Vyp31fq. Na těchto formulářích na HR Portále nebylo možné definovat rozpis SLM, proto byl tento parametr vytažen jako definovatelný na Adm21 à záložka “HR Portál”. Do parametru se vyplňuje hodnota Ano nebo Ne. Pokud není nic vyplněno, systém automaticky bere hodnotu Ne.

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

Popis byl vytvořen automaticky

PkzZ01

Konfigurace formuláře Pkz01 – Personální karta zaměstnance – obsahuje následující položky

Pkz - výčet typů struktur referentů pro Kontaktní osoby:

Seznam typů struktur oddělený čárkami

Pkz – zaměstnání / V organizaci / struktura pro 1. sloupec: standardně 2 - Organizační

Pkz – zaměstnání / V organizaci / struktura pro 2. sloupec: standardně 3 - PM

Pkz – zaměstnání / V organizaci / struktura pro 3. sloupec: standardně 4 - Profese

Konfiguruje, které typy struktur mají být v záložce zobrazovány. Obvykle 2,

Dov16 - Dovolená

Konfigurace formuláře Dov16 - Dovolená – obsahuje následující položky:

Dov16 - nemazat Plán po převedení na žádost:

Dov16 - možnost uzavření ročního plánu:

Dov16 - skrýt záložku Plán

Podrobnější popis viz EGJE_web_uzdoc

Domovská obrazovka HR Portál

Lze sem umístit logo organizace a to buď do prvního čtverce, nebo na podklad celé obrazovky.

Dále je možné měnit různé barvy.

U víceorganizační instalace je možné mít více nastavení. Uživatel bez omezení organizací má potom nastavený design použitý pro hlavní organizaci.

Jde o položky:

"Vzhledy Crisp* - barva textu čtverců (hexa číslo uvozeno #)"

Příklad #008b00

"Vzhledy Crisp* - barva podkladu čtverců (hexa číslo uvozeno #)"

Příklad #d6ead6

"Logo do prvního čtverce (150 x 150 px; objekt práv MENUDL_Home):"

JPG, PNG nebo GIF (teoreticky i pohyblivý GIF, ale není to moc přívětivé a velmi brzy to omrzí)

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

Odkaz je nepovinný - pokud je v nové záložce zadaný, je po kliknutí na čtverec otevírána tato adresa.

"Vzhledy Crisp* - barva nadpisu v sloupci WFL& Zprávy a odkazy (#hexa)"

Příklad #008b00

"Logo na pozadí menu HR Portál"

Velké logo za celou "devítku" čtverců. Bude čtverci částečně zakryto.

K přizpůsobení se váže objekt přístupových práv

"MENUDL_Home" - "Logo - 1. čtverec"

jehož přiřazení uživateli (role=>profil) způsobí, že prvním čtvercem portálového menu bude čtverec s logem organizace

MHRP

Výčet WFL akcí, které zpracuje MHRP (čárky, pomlčky):

URL adresa aplikace MHRP:

Dcu06 – Docházka

Dcu06 - načtení navigačního seznamu podle aktuálního období:

Volba režimu vytváření nav. seznamu pro formulář Dcu06.

Ano - navigační seznam se naplní PV platných pro zobrazované období (standard DOCH)

Ne nebo nevyplněno – navigační seznam se naplní PV platných k referenčnímu datu

Poznámka: položka není dostupná na Adm22.

Dca11 - Docházkový terminál

Konfigurace formuláře Dca11 obsahuje následující položky:

Logo na pozadí záložek Dca11

Odkaz na obrázek, který se zobrazuje jako podklad pro některé záložky Dca11 (záložky s tlačítky). Obsah uložení se zobrazí po použití odpovídajícího tlačítka.

Barva podkladu čtverců průchodů (hexa uvozeno #)

Barva použitá pro tlačítka formuláře Dca11, záložka Evidence příchodů/odchodů

Příklad #d6ead6

Barva podkladu čtverců žádosti (hexa uvozeno #)

Barva použitá pro tlačítka formuláře Dca11, záložka Žádosti o odchylky a Posílání zpráv

Příklad #fad6d6

E-mail adresa - pro doručení zpráv

e-mail adresa pro odesílání zpráv pro tlačítka formuláře Dca11, záložka Posílání zpráv

Záložka „Docházka“

Na záložce jsou parametry určené pro oblast docházky (více viz. DOCH_dopl_uzdoc, Adm21, Záložka - Docházka).

Záložka „Strava“

Na záložce jsou parametry spojené s generováním nároků příspěvků na stravu jako i následné vyhodnocení odebrané stravy resp. stravných lístků (více viz. DOCH_dopl_uzdoc, Adm21, Záložka - Strava).

Záložka „Personální“

Obsahuje položku Výčet skupin pro workflow 3. Ta umožňuje definovat skupiny (Zpu02), které se budou workflow účastnit.

Parametr „Přepis jména hodnotitele“ má přímou vazbu na formulář Hod01.

Záložka „Osoby a mzdy“

Statistické informace o počtech zaměstnanců v organizaci na jednotlivých SO za jednotlivá zúčtovací období.

Záložka "Cestovní příkazy" je popsána v Cep_uzdoc.

3.12 Adm22 – Konfigurace – správní jednotky

Individuální formulář o datech správních jednotek

Navigace: Seznam správních jednotek

Formulář umožňuje práci s daty a parametry společné pro správní jednotku

Vlastní data formuláře jsou organizována v záložkách

Záložka „Údaje o správní jednotce“

Obsluha: Popis, základní atributy správní jednotky

Položky:

Číslo správní jednotky

Název běžný pro interní sestavy a potřeby

Název oficiální pro externí výstupy

Adresa - název adresáta

Adresa - dourčení adresáta, který blíže určuje správní jednotku v její položce název

OKEČ (NACE)

Telefon

Fax

E-mail

ID datové schránky

Zaměstnavatel odměňující platem (§ 109 odst. 3 ZP) (pouze pro CZ SJ)

Regionální školství – druh činností škol a školských zařízení (číselník Druh činností škol a školských zařízení – regionální školství)

Zřizovatel organizace – státní správa (číselník Zřizovatel organizace – státní správa)

Předkladatel IČO (ISP)

Název předkladatele (ISP)

Záložka „Konfigurační parametry“

Obsluha: Práce s konfiguračními parametry správní jednotky

Položky:

Parametry správní jednotky

Záložka „Docházka“

Na záložce jsou parametry určené pro oblast docházky (více viz. DOCH_dopl_uzdoc).

3.13 Adm23 – Konfigurace – správní oddíly

Individuální formulář o datech správních oddílů

Navigace: Seznam správních oddílů

Formulář umožňuje práci s daty a parametry společné pro správní oddíl.

Vlastní data formuláře jsou organizována v záložkách

Záložka „Údaje o správním oddílu“

Obsluha: Popis, základní atributy správního oddílu

Položky:

Číslo správního oddílu

Název běžný pro interní sestavy a potřeby

Číslo správní jednotky

Záložka „Konfigurační parametry“

Obsluha: Práce s konfiguračními parametry správního oddílu

Položky:

Parametry správního oddílu

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

Žádost o RZD lze do (dd.mm)

Při promítání Prohlášení nerezidenta přepisovat evidenci v Osb02

Záložka „HR Portál“

Datum uvolnění/provedení RZD (dd.mm)

Záložka „Uživ.položky“

3.14 Adm2 4 – Kurzovní lístek

Formulář pro správu kurzovního lístku měn (využití pro cestovní příkazy)

Navigace: Kalendářní dny

Formulář umožňuje práci s evidencí kurzů měn.

Položky:

Datum od–do – datum platnosti uvedeného měnového kurzu

Kolik (měna)

Je za 1 (měnu)

Kurz – udává kolik měny XXX uvedené v položce „Kolik“ je za 1 jednotku měny uvedené v položce „Je za“

Uvedenou kurzovní tabulku je možno udržovat buď ručně, nebo je možno využít funkčního tlačítka „Import z webu“, které naplní tabulku údaji z ročního kurzovního lístku uvedeného na webu ČNB (pro ČR) nebo na webu NBS (pro SK). Podle nastavené legislativy u organizace na Adm21, lze pomocí checkboxu “Omezit kurzovní lístek podle legislativy“ nastavit import jen z jednoho zdroje.

Odkaz pro ČR :

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

Odkaz pro SR :

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

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

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

Aktualizovány jsou pouze měny již uvedené v kurzovním lístku, a jejichž záznam v Adm24:

· Datum od není starší než 2 měsíce

· Je vyplněna legislativa (buď CZ nebo SK)

· V položce Kolik[měna] je pro CZ legislativu CZK
zatímco u SK legislativy je tomu přesně obráceně je třeba vyplnit Euro do Je za[měna]
Důvodem je odlišná stavba tabulek ČNB a NBS

· Mají vyplněnu cílovou měnu (druhá položka pro měnu)

CZ - další kurzy:

Kromě kurzů v základní kurzové tabulce existují i méně často aktualizované kurzy pro nestandardní měny (např. Ukrajina UAH). Pokud v tabulce nějaký takový kurz je uveden, Adm24 / Import z webu nyní hledá i v těchto kurzech (viz https://www.cnb.cz/cs/financni-trhy/devizovy-trh/kurzy-ostatnich-men/)

Pozn.: K tomu je nezbytný přístup na internet, včetně případného dodefinování proxy (viz EGJE_Provdoc / 3.3 Stanice uživatele pro standardního klienta

Pozn.: Sledované měny jsou definovány v JPC cp_meny. Definici zákazníkem individuálně sledovaných měn lze zadat na formuláři Jpc01 v číselníku cp_meny do části Hodnoty uživatel (EGJE definuje pouze měny, týkající se zpracovávané legislativy, tedy CZK a EUR (SKK))

Pozn.2: Kdy jsou kurzy aktuální (dle webů národních bank):

CZ: Kurzy devizového trhu (aktuální data jsou k dispozici po 14:30 hod)

SK: Jednotlivé referenční výměnné kurzy jsou stanovované na základě telekonference mezi národními centrálními bankami, které se obvykle konají v 14:15 SEČ

Pozn.3: V některých organizacích používají uživatelskou sestavu Adm24f, která při svém spuštění provede tu samou funkčnost jako Adm24 / Import z Webu. Sestavu pak mají umístěnou na Adm53, aby se spouštěla sama periodicky. Obvyklým problémem pak je, že sestava běží na aplikačním serveru nebo na serveru EGJEWEB(2) a tento server tedy musí mít přístup na internet resp. na alespoň výše uvedené adresy. Zabezpečení přístupu je úkolem správce v konkrétní organizaci.

Je třeba si uvědomit, že výše uvedené adresy se jednak mohou měnit a také mohou pouze přesměrovávat na jiné skutečné url adresy.

3.15 Adm25 – Export číselníků

Na formuláři Adm25 à záložka Export pravidel WFL se dá nastavit export různých WFL a jejich pravidel. Export se dělá výběrem WFL v seznamu na levé straně a pravidel na pravé.

3.16 Adm26 – nastavení šifrování a SFTP

Na formuláři Adm26 lze nastavit šifrovaní, SFTP konektivita a komprimace souborů opatřená šifrováním. V případě SFTP je možné využít PGP šifrování.

3.16.1 Nastavení SFTP přenosu

Po stisku tlačítka „Nový“ se musí nejprve vybrat „Profil“. Pokud je zvolen profil „SFTP“ bude se pro přenos souborů využívat SFTP konektivita.

Následně je nutné vyplnit název profilu. Tento název bude nadále zobrazován pro výběr na formuláři Adm53, kde se nastavuje automatické spuštění sestav, které budou definované SFTP spojení využívat.

Pro SFTP spojení se vyplňují následující údaje „SFTP“.

· URL serveru – obsahuje adresu serveru, kde je SFTP

· Port – číslo portu pro komunikaci, pokud se nevyplní použije se port 22

· Login – uživatelské jméno pro přihlášení k SFTP

· Metoda autentizace – zde se následně vybírá, zda bude autentizace heslem nebo certifikátem. Po výběru metody se zobrazí další pole, kde půjde buď zadat heslo nebo vybrat certifikát.

o Heslo (dle výběru metody autentizace) – heslo pro autentizaci

o Certifikát (dle výběru metody autentizace) – certifikát je vygenerovaný SSH klíč a importuje se jeho privátní část, EGJE nepodporuje klíč ve formátu ppk (používá se například pro WinSCP), je nutné naimportovat certifikáty typu DSA, RSA nebo ECDSA (jiné nejsou podporovány). Certifikát má dvě volby, buď s heslem nebo bez hesla (určuje se při generování).

· Složka na SFTP serveru – zde je možné nadefinovat adresář na vzdáleném uložišti odkud nebo kam se má soubor odesílat nebo stahovat.

· Slozka na local/server – slouží pro definici adresáře na lokálním počítači či serveru

Povinné položky pro SFTP:

URL Serveru, Login, Metoda autentizace, Heslo nebo Cerifikát

Poznámka: Profil SFTP jde využívat bez šifrování. Pouze pro přenosy souborů.

Po nadefinování všech údajů, je třeba daný profil uložit. Tímto je dokončena definice spojení SFTP.

Pokud je nutno dané soubor/y přenášet pomocí SFTP, a ještě šifrovat či dešifrovat, je nutné vyplnit údaje ohledně šifrování v v bloku „Šifra“.

3.16.2 Nastavení šifrování

Při výběru profilu „Šifrovat/dešifrovat“ se vyplní údaje ohledně šifrování a to v závislosti na zvoleném typu

· Typ šifrování PGP

o Od – Do – do těchto položek se nastavuje platnost šifrovacího klíče. Tyto položky se automaticky vyplní po stisknutí na tlačítko „Generuj klíče“. Standardní platnost klíče je od data generování po dobu dvou let. Nicméně pokud by bylo požadováno, zkrátit možnost využití klíče například na rok, je možné posunout datum „DO“ na danou hodnotu jednoho roku. Tato možnost pak zajistí, aby nebyl klíč využíván po celou bobu dvou let. Pro kontrolu platnosti slouží OKO sestava Adm76 (nastavení Adm76 dále v tomto dokumentu). Pokud by ale byly dodány klíče od poskytovatele, tak je nutné doplnit datumy „Od“ a „Do“ ručně. Tyto položky jsou povinné a bez nich šifrování nebude funkční.

o Identita – lze zadat jakýkoli text, pole se využívá k určení identity, která šifruje daný přenos (vetšinou email)

o Šifrování – RSA

o Heslo

o Generuj klíče - tlačítko slouží k vygenerování soukromého a veřejného klíče k šifrování a dešifrování

o Zašifruj soubor - tlačítko slouží k ověření a možnosti daný soubor zašifrovat

o Dešifruj soubor - tlačítko slouží k ověření a možnosti daný soubor dešifrovat

o Veřejný klíč klienta - tlačítkem “Nahraj”, jde uložit veřejný klíč klienta pokud je poskytnut

o Soukromý klíč klienta - tlačítkem “Nahraj”, jde uložit soukromý klíč klienta pokud je poskytnut

· Typ šifrování – AES-256

o Od – Do – platnost symetrické šifry

o Mód symetrické šifry: ECB nebo GCM

o Způsob generování SK: způsob generování secret key

o Heslo: položka editovatelná pouze pokud Způsob generování SK = 1 – Odvození z daného hesla. V případně způsobu 2 – Generování z náhodného čísla je položka needitovatelná a pro tvorbu hesla je nutné využít tlačítko Generuj heslo

o Generuj Iniciační vektor – tlačítko dostupné pouze pokud položka Způsobu generování SK = 2 – Generování z náhodného čísla

Následné 2 položky „Zdroj“ a „Cíl“ v této chvíli nejsou potřeba a budou se do budoucna odstraňovat. Po přidání tlačítek „Zašifruj soubor a „Dešifruj soubor“ tato tlačítka nahradila funkcionalitu polí. Cesta k souboru se vybírá těmito tlačítky.

Importní a Exportní sestavy je třeba pro SFTP a šifrování specificky upravit. V případě zájmu kontaktujte helpdesk.

3.16.3 Záložka Šifra - ZIP

Tato záložka umožňuje definovat šifrování pro ochranu ZIP archívu šifrou a heslem.

Záložka je určena pouze pro nastavení možnosti šifrovat archív a je zde možné provést pouze výběr šifrování (ZipCrypto, AES-128, AES-256). Samotný proces šifrování ZIP archivu se spouští v rámci příslušného procesu (odesílání ZIPovaného dokumentu na e-mail v rámci workflow oběhu dokumentů rozšířeného o komponentu elektronického podpisu dokumentu).

Pro aktivaci šifrování je nutné založit nový „Profil“ s názvem ZIP.

3.17 Adm27 – Evidence certifikátů

Formulář Adm27 „Evidence certifikátů“ je určen pro komplexní správu všech digitálních certifikátů – osobních i systémových. Certifikáty jsou zde evidovány v základní struktuře certifikační oprávnění a navázané certifikáty vydané. Certifikáty vydané (první vydaný certifikát a návazné obnovené certifikáty) evidují zejména všechny náležitosti spojené s konkrétním vydaným certifikátem. Certifikační oprávnění pak zastřešuje první vydaný certifikát a návazné certifikáty obnovené a je nositelem informací obecné kategorizace certifikátů a zároveň i vazeb na další datové objekty.

Navigace: Seznam Certifikačních oprávnění

Řádková práva jsou aplikována ve dvou modech: Profil s plným oprávněním má přístup ke všem záznamům certifikátů, tedy k certifikátům vázaným na Org/SJ, i nevázaným. Profil aplikující přiřazení uživatele k ORG/SJ zpřístupňuje uživateli ty záznamy na Adm27, které jsou přiřazeny k ORG /SJ, ke kterým má profil přístup a záznamy nepřiřazené k ORG, SJ

Záložka Certifikační oprávnění

Záložka obsahuje informace sloužící:

· k základní kategorizaci certifikačního oprávnění pomocí setu kategorií, které umožňují vybrat certifikát odpovídající požadavkům daného procesu

· k nastavení vazeb na další evidované objekty využívané v rámci procesů EGJE. Jde zejména o vazbu na držitele. Certifikáty vydané na organizaci a/nebo jejího pracovníka jsou přiřazeny k organizační struktuře (Organizace, Správní jednotka) a osobě, certifikáty třetích stran (orgány veřejné moci, dále OVM) pak mají vazbu na evidenci externích organizací (úřady, zdravotní pojišťovny atd.)

Atributy certifikačního oprávnění

· Název certifikátu: v rámci importu se předvyplní vybrané identifikační údaje držitele certifikátu, uživatel může upravit

· Popis: zadáno uživatelem

· Typ certifikátu: v rámci importu se dle vybraných parametrů certifikátů předvyplní typ. Pokud by se z dostupných dat certifikátu v rámci importu nepodařilo certifikát kategorizovat vůbec nebo by došlo k nepřesné kategorizaci, uživatel může editovat. Základní typy:

o Osobní: certifikát vydaný konkrétní fyzické osobě

o Osobní pro organizaci: certifikát vydaný konkrétní fyzické osobě a organizaci (typicky zaměstnavatel pořídí podpisové certifikáty pro své pracovníky, kteří certifikátem podepisují firemní komunikaci, doklady)

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

o Serverový (technologický): je určen především pro vzájemnou zabezpečenou komunikaci serverů.

· Úroveň důvěry

o Kvalifikovaná – certifikát vydaný akreditovanou kvalifikovanou certifikační autoritou na kvalifikovaném prostředku

o Uznávaná – certifikát vydaný akreditovanou kvalifikovanou certifikační autoritou na nekvalifikovaném prostředku. Při importu certifikátu vydaného kvalifikovanou certifikační autoritou se vstupně nastavuje tato úroveň důvěry. Pokud jde o certifikát na kvalifikovaném prostředku, pak editovat na úroveň Kvalifikovaná.

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

· Druh klíče

o Veřejný – k certifikátu evidujeme pouze část veřejného klíče, jde zejména o certifikáty třetích stran

o Soukromý – certifikát obsahuje veřejný i privátní klíč

· Organizace, Správní jednotka: pokud je držitelem certifikátu správní jednotka, evidujeme vazbu na organizační strukturu firmy (Organizace, SJ)

· Osoba: Pokud je držitelem zaměstnanec, evidujeme vazbu na osobu

· Organizace 3.strany: pokud je certifikát vystaven na externí subjekt, pak navážeme na organizaci evidovanou v rámci číselníku Externích subjektů (Adm28)

· Platnost záznamu od: datum založení certifikačního oprávnění

· Platnost záznamů do: při importu certifikátu je načtena platnost importovaného certifikátu vydaného, lze editovat uživatelem (např. pokud je s pracovníkem ukončen pracovní poměr)

· Datum revokace: pokud došlo k revokaci aktuálně platného certifikátu vydaného, pak evidujeme datum a čas zneplatnění

Na záložce jsou dostupné akce pro načtení certifikátů

· Akce Vyberte certifikát ze souboru

· Akce Vyberte certifikát ze systémového úložiště – tato akce je určena k načtení kvalifikovaného certifikátu ze systémového úložiště Windows Keystore

Pokud evidujeme první certifikát, pak založíme nové certifikační oprávnění a načteme vydaný certifikát pomocí akce Vyberte certifikát ze souboru/ Vyberte certifikát ze systémového úložiště. Tímto dojde k předvyplnění vybraných atributů certifikačního oprávnění a pod dané certifikační oprávnění se na záložku Certifikáty vydané založí první záznam certifikátu vydaného.

Pokud evidujeme k danému certifikačnímu oprávnění obnovený certifikát, pak pod dané certifikační oprávnění založíme nový záznam certifikátu vydaného.

V rámci další specifikace certifikačního oprávnění pak na jednotlivých podzáložkách certifikačního oprávnění můžeme evidovat účely užití a přiřazení certifikátu k API.

Záložka Účely užití

Záložka eviduje užití certifikátů (pro jaké účely byl certifikát vystaven). Vychází se ze specifikace certifikátu uvedeného v rámci Použití klíče (Key usage) a Použití rozšířeného klíče (Extended key usage).

Záložka Přiřazení k API

Pokud je certifikát určen pro zabezpečení komunikace se třetí stranou prostřednictvím API, pak na záložce Přiřazení API evidujeme vazbu příslušného certifikátu k danému API (definovanému na Adm55)

Záložka Certifikáty vydané

Na záložce „Certifikáty vydané“ jsou evidovány jednotlivé vydané certifikáty, tedy první vydaný a návazné obnovené certifikáty. Většina informací zde evidovaných je načtena přímo ze souboru certifikátu a není editovatelná uživatelem. Jde o tyto oblasti dat

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

· certifikační autorita, která certifikát vydala

· identifikace držitele certifikátu

· platnost certifikátu

· informace k místu uložení certifikátu pro využití v rámci systému EGJE (databáze, Windows Keystore)

· informace k hierarchii certifikátu: zda jde o koncový certifikát a úroveň hierarchie certifikátu

Záložka Registrace certifikátu

Pokud jde o certifikáty vydané zaměstnancům organizace komunikující s OVM elektronicky, pak tyto certifikáty podléhají registraci zplnomocnění na těchto úřadech. OVM si k těmto certifikátům registruji zplnomocnění pro firmy, jež má pracovník s daným certifikátem oprávnění zastupovat v elektronické komunikace s úřadem (např. zpracovává a podepisuje e-Podání). K vydaným certifikátům tak můžeme na podzáložce „Registrace certifikátu“ evidovat OVM, u kterých byl certifikát zaregistrován a na záložce „Zmocnění“ pak evidujeme pro jaké SJ bylo zplnomocnění na OVM registrováno. Pokud je v rámci vybraných procesů požadováno vyhodnocovat při výběru certifikátu, zda je daný certifikát registrován u OVM, pak se zohlední toto nastavení.

Základní procesy

Evidence prvního vydaného certifikátu

Pokud evidujeme první vydaný certifikát daného typu a daného držitele, pak postupujeme následně:

· Založíme nové Certifikační oprávnění

· Spustíme akci na načtení certifikátu: Vyberte certifikát ze souboru nebo Vyberte certifikát ze systémového úložiště

· EGJE načte data z certifikátu a těmito daty pak

o Aktualizuje vybrané atributy na Certifikačním oprávnění

o Načte Účely užití k Certifikačnímu oprávnění

o Založí nový Certifikát vydaný a v rámci něj všechny parametry, jejichž údaje lze z certifikátu načíst

· Uživatel eviduje na Certifikačním oprávnění další náležitosti dle typu certifikátu, který je evidován

o Upraví Název, pokud název vytvořený na základě dat z certifikátu chce změnit

o Doplní Popis

o Pokud jde o certifikát, jehož držitelem je organizace (správní jednotka) a/nebo zaměstnanec zadá Organizaci, SJ a v případě osobních certifikátu i Osobu, na níž je certifikát vystaven

o Pokud jde o certifikát organizace třetích stran (OVM), pak zadá vazbu na číselník v rámci pole Organizace 3.strany

o Zreviduje předvyplněnou kategorizaci Certifikačního oprávnění: Typ certifikátu, Druh klíče, Druh certifikátu, Úroveň důvěryhodnosti

· Uživatel přejde na záložku Certifikáty vydané a na nově založeném záznamu Certifikátu vydaného upraví Název, pokud název vytvořený na základě dat načtených z certifikátu chce změnit, případně zreviduje další předvyplněné hodnoty v editačním modu

· Pokud jde o certifikát registrovaný u OVM, pak na záložce Registrace certifikátu zadá OVM, u kterých proběhla registrace certifikátu a na záložce Zmocnění zaeviduje SJ, pro které bylo k certifikátu nahlášené OVM zmocnění

Evidence obnoveného certifikátu

Certifikáty jsou vydávány pro definované období platnosti (např. u osobních certifikátu jde zpravidla o 1 rok nebo 3 roky). Pokud chceme platnost certifikátu prodloužit, pak je nutné před vypršením platnosti stávajícího certifikátu požádat CA o obnovení certifikátu.

V případě evidence obnoveného certifikátu v EGJE postupujeme následně

· Přejdeme na záznam Certifikačního oprávnění, u něhož došlo k obnovení aktuálně platného certifikátu

· Přejdeme na záložku Certifikáty vydané a přes akci Nový založíme nový záznam Certifikátu vydaného

o Dle místa uložení certifikátu načteme certifikát pomocí akce Vyberte certifikát ze souboru nebo Vyberte certifikát ze systémového úložiště

o EGJE načte data z certifikátu a těmito daty pak aktualizuje Certifikát vydaný a vybrané údaje Certifikačního oprávnění (Platnost do)

o Uživatel může upravit Název, pokud název vytvořený na základě dat načtených z certifikátu chce změnit, případně zreviduje další předvyplněné hodnoty v editačním modu

Revokace certifikátu

Pokud dojde k události, která vede k revokaci platného certifikátu (např. ztráta nosiče s certifikátem), pak je potřeba požádat o zneplatnění certifikátu vydávající CA.

V rámci EGJE návazně nastavíte na Certifikačním oprávnění Datum revokace.

Při vydání nového certifikátu pak zakládáme nové Certifikační oprávnění.

3.18 Adm28 – Externí organizace

Formulář Adm28 „Externí organizace“ slouží ke správě základních identifikačních a kontaktních informací k subjektům třetích stran. S ohledem na implementované procesy EGJE jde o evidenci orgánů veřejné moci (OVM) pro účely e-Podání. Formulář obsahuje dvě základní evidenční oblasti těchto subjektů

· Obecný číselník externích organizací – záložka Externí organizace

· Strukturu poboček organizace – záložka Struktura poboček

Záložka Externí organizace

Evidujeme zde základní identifikační a klasifikační parametry externího subjektu:

· Zkratka názvu: zkratka pro označení organizace

· Název: název organizace

· Typ organizace: Státní správa/Zdravotní pojišťovny/…..

· Zdravotní pojišťovna: pokud evidovaným subjektem je ZP, pak provážeme na číselník ZP

· Externí ID organizace: jde o Identifikátor OVM

· Vlastník: pokud je záznam založen Elanor a.s., pak = E, pokud je záznam založen uživatelem, pak = U.

· Legislativa – určuje, pro jakou legislativu je organizace určena

Oblast dat Registrace certifikátu

Tato část se týká oblasti registrace certifikátů u OVM. Certifikáty vydané pro firmu/zaměstnance určené pro komunikaci s daným OVM mohou podléhat procesům registrace a zplnomocnění. Aktuálně probíhá registrace na jednotlivých OVM samostatně, do budoucna se předpokládá evidence na jednom centrálním místě. V rámci evidence Externích organizací tak je umožněno nastavit:

· Subjekt, který je centrální registrem certifikátů pro jiné OVM, bude mít nastaven Centrální registr certifikátu = Ano

· Subjekt, který bude využívat centrální registr, bude mít nastaven parametr Napojení na centrální registr certifikátů = organizaci zajišťující funkci centrálního registru

V rámci procesu výběru certifikátu pro zpracování dat v rámci příslušného e-Podání v EGJE, může být nastaveno, aby se ověřovalo registrace zmocnění k certifikátu pro příslušnou SJ, za kterou jsou data zpracovávaná. Pokud je požadováno, aby se tato kontrola při komunikaci s daným OVM aplikovala, pak Kontrola zmocnění k certifikátu = Ano. Kontrola se provádí vůči evidenci Registrací a jejich Zplnomocnění evidovaných na certifikátu (Adm27)

Záložka Struktura poboček

V rámci Struktury poboček je možné evidovat strukturu poboček daného subjektu (OVM) a kontaktní informace k jednotlivým pobočkám. Záznamy jsou pro uživatele odfiltrovány dle nastavení legislativy na externí organizaci.

Detail pobočky

Pokud zakládáme první úroveň struktury (kořen stromu), pak novou položku zakládáme pomocí akce Nová kořenová pobočka. Pokud zakládáme podřízenou pobočku, pak ve stromu označíme uzel, pod který chceme vložit podřízenou pobočku a zvolíme akci Nová podřízená pobočka.

· Úroveň struktury: založí se automaticky

· Externí organizace: v případě založení kořenu stromu zadáme vazbu na obecný číselník externích organizací, u podřízených poboček se externí organizace přebírá z kořenové položky.

· Název: vložíme název pobočky

· Zkratka názvu: zkratka pro označení pobočky

· Číslo okresu ČSSZ: pokud evidujeme strukturu ČSSZ, pak můžeme provázat na číselník okresů ČSSZ

· Externí ID organizace: jde o Identifikátor OVM

· Platnost od

· Platnost do

Data pro OVM, pro která jsou v rámci EGJE implementovaná e-Podání, jsou v databázi na centrální úrovni struktury OVM spravována Elanor a.s.

3.19 Adm31 – Konfigurace uživatelských položek

Formulářem se dají nastavit názvy uživatelských položek použitých na formulářích:

· Osb01, Osb02

· Opv01

· Pmi01

· Pro01

a to vždy v záložce Uživatelské údaje.

Pro editaci je přístupná trojice nadpisů. Klíčový je ten druhý, ten je použit v záložce formuláře.

Pokud je u položky uveden odkaz na jednopoložkový číselník je možné tento číselník editovat ve formuláři Jpc01 (viz EGJE_uvod).

Formulář také umožňuje nastavit použití a nepoužití číselníků pro

· titul před jménem a za jménem

Implicitní je dosavadní stav - nepoužití titulů.

Při použití titulů je tyto třeba vyplnit do Jpc01 - číselníky a_titul, v_titul - vyplňujte sloupce hodnota a Kód.

Ve sloupci hodnota libovolnou číselnou řadu, ve sloupci Kód pak celý titul, sloupec název ponechávejte prázdný.

Oba režimy jsou datově kompatibilní - tj. již přiřazené tituly zůstávají zachovány.

· PSČ. Při použití číselníku je potřeba mít vyplněný číselník na formuláři Psc01. Oba režimy jsou datově kompatibilní - tj. již přiřazené tituly zůstávají zachovány. Upozornění – použití číselníku PSČ zpomaluje načítání formulářů, kde je PSČ použito. Týká se to zobrazení PSČ v osobních adresách, adresách SJ, SO, PM, akcích.

· pracovní místa na formulářích Pmi01 a Opv01.Při použití číselníku je potřeba vyplnit číselník pracovních míst na f. Pmi06. Oba režimy jsou datově kompatibilní - tj. již přiřazená pracovní místa zůstávají zachovány.

Upozornění - po přestavění režimu titulů a pracovních míst a PSČ je vhodné klientskou aplikaci zavřít a znovu otevřít, aby se změna promítla do všech jejích částí, resp. restartovat AS či Web aplikaci (Tomcat) při použití těchto komponent.

"Další konfigurace" / Multiorganizace

Nastavení, kdy osobní číslo PV je unikátní pouze v rámci organizace a nikoliv v rámci celé databáze je určeno pouze pro multiorganizační databáze Elanor Outsourcing.

Stejně tak je tomu u unikátnosti kódů struktur.

Záložka „Doch.-číselníky“

Umožňuje na formuláři „Kal01, Docházka“ a „Dcd01, Vstupy, Detail“ uživatelsky upravit název nepojmenovaných příplatků.

3.20 Adm32 - Konfigurace hlášení výpočtu

Obsahuje seznam hlášení použitých v jednotlivých oblastech a umožňuje jemné nastavení hlášek, které mají možnost úpravy úrovně hlášení ze strany zákazníka.

Formulář je rozčleněn do třech záložek, přičemž každá záložka je rozdělená na dvě podzáložky.

podzáložka Uživatelské nastavení

obsahuje seznam hlášení, které si uživatel definoval pro použití pro danou oblast s obsahem

Kód - kód a text hlášení

Úroveň - uživatelem nastavená úroveň hlášení

podzáložka Standardní nastavení - obsahuje plný seznam používaných hlášení, pro danou oblast s obsahem:

Kód - kód a text hlášení

Standardní úroveň - standardní úroveň hlášení

Uživatelská úroveň - uživatelem nastavená úroveň hlášení

Jednotlivá hlášení se zobrazují barevně podle úrovně hlášení. Pro hlášení s uživatelem nastavenou úrovní je barva zobrazení stanovená podle uživatelské úrovně.

Použité barvení je stejné jako použité pro zobrazení protokolů na Vyp01.

Záložka „Výpočet mezd“

Umožňuje jemné nastavení hlášek výpočtu mzdy - nastavením úrovně hlášky se dá také určit, která hláška výpočet ukončí a která nikoliv.

Každé hlášení má svou „úroveň“, tj. jednu z následujících hodnot (viz též Jpc01, číselník urov_chyby):

0 není chyba, průvodní či provozní hlášení (např. zahájení výpočtu),

1 informace … informace pro uživatele,

2 varování … varovná informace pro uživatele; chyba nízké úrovně,

3 chyba … chyba střední až vyšší úrovně, jejíž existence však umožňuje dokončení výpočtu mzdy zaměstnance,

4 fatální chyba … chyba vysoké úrovně, její existence neumožňuje dokončení výpočtu mzdy zaměstnance.

V praxi je však mnohdy těžké rozhodnout, zda vzniklá situace je informací, běžnou chybou či chybou závažnou či dokonce fatální. Autoři výpočetního programu tak činí podle svého posouzení dané praxí a případně připomínkami většiny uživatelů. Přesto může dojít k tomu, že některý zákazník má své zvyky a potřeby a úroveň hlášení mu nevyhovuje.

Úroveň hlášení je vázána na kód hlášení. Ten je součástí textu zprávy výpočtu a to jako jeho první část. Například z hlášení:

„VYP550 Daňové zvýhodnění na dítě …“

se za kód hlášení považuje „VYP550“. Text hlášení lze vidět na textových protokolech z výpočtu nebo na formuláři Vyp01, záložka Protokol. Je také nově vidět z kontextové nápovědy formuláře Adm32 či jako součást uživatelské příručky.

Do formuláře uživatel, který k tomu dostane přístupová práva, jednoduchou formou zadává ta hlášení, jejichž úroveň chce změnit. Zadává se:

kód hlášení …prostá textová položka (např. VYP550), nápověda kontextová,

úroveň hlášení … zvolená jiná úroveň než je standard (číselník urov_chyby).

Pro hlášení, která nemají zaevidovanou odchylnou úroveň, zůstává standardní úroveň podle autorů výpočetního programu.

Tato vlastnost není však možná pro ta hlášení, která jsou z hlediska řešitelů označena jako fatální chyba, tj. změnit úroveň takovéhoto hlášení nelze. Při fatální chybě totiž nemá smysl pokračovat ve výpočtu a ten tím končí.

Naopak však lze přeřadit hlášení s úrovní menší než fatální na úroveň fatální. Tím lze dosáhnout toho, že výpočet mzdy zaměstnance při situaci hlášené tímto hlášením je současně se zprávou ukončen. Lze to například využít při řešení situace zadání náhrady při dočasné pracovní neschopnosti na více než 14 dnů (21 dnů od roku 2011). Standardní úroveň je chyba a výpočet pokračuje. Při přestavení na fatální chyba však výpočet končí.

Přenastavení úrovně hlášení na hodnotu 0 způsobí to, že se hlášení nevytváří.

Záložka „Docházka“ a „Docházka a výkony“

Umožňuje uživatelskou modifikaci standardně stanovené úrovně hlášení pro dodavatelem stanovený seznam hlášení z oblastí Docházka / Docházka a výkony.

Principy použití a obsluha je shodná se záložkou „Výpočet mezd“ s výjimkou, že uživatel má k dispozici seznam hlášení, u kterých je možné změnit úroveň.

Podrobnější popis viz Doch_dopl_uzdoc, kapitola Adm32.

3.21 Adm33 - Konfigurace textů (pozvánky, kalendář ...)

Formulář slouží pro evidenci a zadávání předloh e-mailových oznámeních používaných v Kva06, Adm53 a jiných objektech.

Umožňuje v záhlaví vybrat editor pro oznámení:

Textový editor - standardní "bezproblémový"

HTML editor - závisí na klientu JAVA/WEB2 (v případě java klienta i na verzi JRE)

obsahuje omezenou podmnožinu html, mohou být problémy i s velikostí fontů nebo vloženou grafikou - vše je třeba vyzkoušet - nemůžeme garantovat kompletní html kompatibilitu

Obsahuje tlačítka:

· Generování všech kroků – zobrazí dialog pro výběr organizace a akce workflow, po odsouhlasení vytvoří kroky se všemi statusy daného workflow kromě statusu 0. Ten se typicky používá jako výchozí status. Nenastavují se příjemci ani předloha oznámení.

· Kopie včetně kroků – zobrazí se dialog pro výběr organizace a případně výběr akce workflow, po odsouhlasení vytvoří kopií nové kroky workflow a nastaví jim organizaci a akci z parametrů v dialogu.

· Nastavení organizace všem krokům – zobrazí dialog pro výběr organizace, po odsouhlasení pro vybraný krok workflow najde všechny kroky se stejnou akcí workflow a organizací a změní jim organizaci na organizaci z parametru v dialogu.

3.21.1 Podporované work flow.

WF 5 Pozvánka na vzdělávací akci

Pozvánky jsou odesílány z Kva06 / Účastníci / Odeslat pozvánky

Pozn. Konečný status 1.

Krom standardních příjemců, účastníků akce, umožňuje zadat pravidla pro další příjemce pozvánky.

WF 6 Zpráva o nedosažení min. počtu na vzděl. akci

Úloha Adm53, kde je také popsána.

WF 7 Zpráva o odhlášení ze vzdělávací akce

Zpráva o odhlášení zaměstnance ze vzdělávací akce má tyto podtypy:

1 - Odhlášení z akce zaměstnancem - volání z Kva15

2 - Odhlášení z akce manažerem - volání z Kva03

3 - Odhlášení z akce referentem - volání z Kva06 - tlačítkem Smazat účastníka + Poslat oznámení. Alternativou je smazání standardním tlačítkem, kdy e-mail neodchází.

Pozn. V Kva06.mts je zde ještě dotaz na důvod. V Kva06.allsk se odesílá oznámení vždy i při standardním mazání.

WF 8 Zpráva o expiraci period. způsobilosti

Úloha Adm53, kde je také popsána.

WF 9 Pozvánka na lékařskou prohlídku

Pozvánky jsou odesílány z Kva05f / Zařazení na prohlídku / Odeslat pozvánku

Pozn. Konečný status 1.

Krom standardních příjemců, účastníků akce, umožňuje zadat pravidla pro další příjemce pozvánky.

WF 56 Zprávy o změně zbrojního průkazu (zákazník CZUB)

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 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 61 Prohlášení poplatníka CZ

Konfigurace mailových notifikací v rámci elektronické daňovky CZ. Je třeba nastavit pro všechny typy statusů prohlášení:

10 – Odesláno MÚ

11 – Odeslána oprava

12 – Vráceno k doplnění/opravě

14 – Změny zamítnuty

20 – Schváleno MÚ

30 – Promítnuto do Dan01

WF 62 Roční zúčtování daně CZ

Konfigurace mailových notifikací v rámci elektronické daňovky CZ. Je třeba nastavit pro všechny typy statusů žádosti o roční zúčtování daně:

10 – Odesláno MÚ

11 – Odeslána oprava

12 – Vráceno k doplnění/opravě

14 – Změny zamítnuty

16 – Žádost o potvrzení příjmů

18 – Potvrzení příjmů vystaveno

20 – Schváleno MÚ

30 – Promítnuto do Dan01

WF 63 Žádosti o dokument

Workflow slouží správci k nastavení pravidel příjemců notifikací (pokud není nastaveno na Adm62) a průvodních textů notifikací v mailu v rámci samostatného okruhu Dokumenty zaměstnance.

1 - Storno

10 – Žádost

14 – Zamítnutá žádost

18 – Vyřízená žádost

WF 64 Vystavení dokumentu bez žádosti

23 – Bez žádosti

(Makra pro text notifikací WFL 63 a 64 jsou uvedena v dokumentaci Zam_dok_uzdoc)

WF 65 Prohlášení poplatníka SK

Konfigurace mailových notifikací v rámci elektronické daňovky SK. Je třeba nastavit pro všechny typy statusů prohlášení:

1 - Storno

10 – Odesláno MÚ

11 – Odeslána oprava

12 – Vráceno k doplnění/opravě

13 – Vzato zpět k opravě/doplnění

14 – Změny zamítnuty

15 – Požádáno o vrácení k opravě/doplnění

20 – Schváleno MÚ

21 – Opětovné schváleno MÚ

30 – Promítnuto do Das01

40 – Zpracováno ručně MÚ

98 – Avízo-nový nástup

WF 66 Roční zúčtování daně SK

Konfigurace mailových notifikací v rámci elektronické daňovky SK. Je třeba nastavit pro všechny typy statusů žádosti o roční zúčtování daně:

10 – Odesláno MÚ

11 – Odeslána oprava

12 – Vráceno k doplnění/opravě

13 – Vzato zpět k opravě/doplnění

14 – Změny zamítnuty

15 – Požádáno o vrácení k opravě/doplnění

16 – Žádost o potvrzení příjmů

18 – Potvrzení příjmů vystaveno

20 – Schváleno MÚ

21 – Opětovné schváleno MÚ

25 - Žádost o RZD anulována zaměstnancem

26 - Zaměstnanec požádal o anulaci žádosti

27 - Anulace žádosti o RZD schválena MÚ

30 – Promítnuto do Das01

40 – Zpracováno ručně MÚ

96 - Vrácení anulace (zam.)

97 - Zamítnutí anulace (MÚ)

WF 67 Končící daňové slevy

Konfigurace emailových notifikací na končící daňové slevy. Je nutné nadefinovat pro všechny konečné statusy (spojeno s Adm58 a Kon07).

1 – Avízo - 1. upozornění

2 – Avízo – 2. upozornění

3 – Avízo – 3. upozornění

4 – Avízo – Mzdové účetní

WF 68 Notifikace při odeslání interní pošty

Toto workflow slouží pro odesílání notifikace na email typu o tom, že došla zpráva interní poštou jako

Workflow je třeba založit s parametry:

- Odesílat zprávy z workflow = Ano

- Zaslat e-mail prim. příjemce ext. = Ano

- Primární typ e-mailu = 31

- Čísla pravidel není nutno vyplňovat

Pro toto WFL je možno do záložky „Předloha oznámení“ vložit makro %MSG_TEXT%, které zkopíruje text zprávy z formuláře Mail à záložka „Nová zpráva“ à text zprávy

WF 69 Registrační e-mail (pouze interní WFL)

Toto workflow slouží pro odeslání registračního e-mailu z EGJE do ESP z formuláře Adm12 v souvislosti s vygenerovanými přístupy a hesly externích uživatelů AD Elanoru. Součástí tohoto WFL jsou i nová makra %REGISTRACE_URL% a %REGISTRACE_LOGNAME%
Detailní popis viz dokumentace EGJE_distribuceHeselASPklientum

WF 70 Expirace hesla

Toto workflow slouží pro odesílání notifikace na email s informací, že dojde k expiraci hesla zadaného na formuláři (např. Adm57 nebo Xpw02/03). Počet dní pro upozornění na expiraci hesla musí být nastaven v Adm70 s vazbou na konkrétní formulář. Dále je třeba nastavit Adm53 s jobem 70, který výpočet dle konfigurace a datumu expirace hesel spočte a pomocí tohoto workflow odešle informace definovanému uživateli. Součástí WFL 70 by měla být Předloha oznámení v tomto formátu:

Tabulka: %TABLE_NAME%, id zaznamu : %ID_RADKU%, identifikace : %IDENTIF%, datum vzniku : %PASS_DATUM_VZNIKU%, datum expirace : %DATUM_EXPIRACE%

(podrobněji viz Makra)

WF 77 Notifikace o uvolnění VL

Toto workflow slouží pro zaslání notifikace ohledně uvolnění VL v systému. Celá funkcionalita se spouští z formuláře Vyp02, ze záložky „Uzávěrka“. Jsou 2 možnosti, kdy jde tuto notifikaci odeslat. Buď tlačítkem „Uzavřeno – zpřístupnit VL zaměstnancům“. Toto tlačítko se zobrazuje ve statusu 4 výplatního termínu (Status VT = 4).

Druhou možností je tlačítko „Odeslat notifikaci o uvolnění VL“, které se zobrazuje ve statusu 6 výplatního termínu (status VT = 6).

Na WFL je potřeba nastavit „Název workflow“, akci workflow, konečný status, nastavit primární typ e-mailu (30, 31, 32, 33) a označit, že se mají odesílat zprávy z workflow (Ano).

WF 78 - Oznámení zaměstnavateli o potřebě OSE/DLO/PPM/OPP

Toto workflow slouží ke komunikaci zaměstnance se mzdovou účtárnou (mzdovou účetní) v případě vyplnění zaměstnancem (Poj71) Oznámení zaměstnavateli o potřeba OSE /DLO/PPM/OPP.

WF 90 Neschvalovaná SLM do iCall

Pro wfl se zobrazuje záložka iCalendar.

Workflow je určené pro potřeby přenosu informace o neschvalované odchylce z Dcu06 do kalendáře typu Outlook/LN a jiných podporovaných.

Wfl negeneruje žádné notifikační zprávy pro uživatele ani jiné adresáty, nedochází k žádných akcím uživatelů v rámci wfl. Slouží pouze na zaslání zprávy do iCall pro zobrazení/zrušení odchylky (především OUTLOOK).
Pro wfl jsou definované 2 kroky:
a/ zapsání zprávy do iCall
konečný stav 23 (Zobrazeno v Kalendáři) + vygenerování zprávy do iCall
b/ zrušení zprávy z iCall
konečný stav 2 (Zrušeno z Kalendáře) + vygenerování zrušení zprávy do iCall

WF 91 Nepovedlo se odeslat soubor do DMS

Workflow je určené pro odeslání zprávy o neúspěšném přenosu souboru do DMS ze sestavy Dms01fkb.

WF 95 - Notifikační sestavy DOCH/DAV - notifikační zprávy

WFL je určené pro definici a případnou modifikaci notifikačních správ z notifikačních sestáv z oblasti DOCH/DAV.

Podrobnější popis viz v Doch_uzdoc, kapitola Notifikační sestavy DOCH, napojení na Adm33.

WF 250 – Notifikační e-mail s ověřovacím URL odkazem

Tato akce workflow slouží pro odesílání ověřovacího URL při změně emailové adresy.

WF 500 – Odesílání akceptovaných dokumentů na e-mail zaměstnance

Tato úloha workflow slouží pro odesílání akceptovaných dokumentů na e-mail zaměstnance. Tato úloha je vázána na funkcionalitu elektronických podpisů implementovanou rámci workflow 301-399.

Při založení záznamu úlohy pro wfl_akce = 500 se vstupně nastaví atribut Režim odeslání zástupci = 0 – Neodesílat.

3.21.2 Elektronické podpisy v rámci workflow Prohlášení poplatníka a RZD

V oblasti e-daňovka jsou dvě zásadní workflow:

workflow „Prohlášení poplatníka“ realizované posloupností kroků na Dan 31->33->34 resp. Das 31->33->34

Dan/Das 31:

Výstupem použití těchto formulářů zaměstnancem je “Prohlášení poplatníka”

Uživatel tj. zaměstnanec dnes vyplněním checkboxu potvrzuje pravdivost údajů na výše zmíněném prohlášení

Dan/Das33:

Vybrané položky z “Prohlášení poplatníka” jsou dále zobrazeny na Dan33/Das33 mzdové účetní (MÚ), která zaměstnancem vložená data ověřuje

Uživatel (v tomto případě MÚ) dnes vyplněním checkboxu potvrzuje pravdivost údajů zobrazených údajů

Dan/Das34:

Tisk “Prohlášení poplatníka” schváleného MÚ se děje přes Dan34/Das34

workflow Žádost o RZD” a “Žádost o vystavení potvrzení o zdanitelných příjmech” realizované posloupností kroků na Dan 32->36->37 a Das 32->36->37

Dan/Das32:

výstupem použití těchto formulářů zaměstnancem je “Žádost o RZD” nebo “Žádost o vystavení potvrzení o zdanitelných příjmech”

Dan/Das 36:

MÚ na těchto formulářích:

vystavuje/tiskne “Potvrzení o zdanitelných příjmech”

procesuje roční zúčtování daní

Dan/Das 37:

MÚ na těchto formulářích tiskne opis zaměstnancovy “Žádosti o RZD”

Ale někteří zákazníci si přejí místo zatržení checkboxu na výše zmíněných formulářích navázat na akci schválení dat sken podpisu zaměstnance/MÚ.

Tento sken je buď už dostupný na Opv31:

sken zaměstnancova podpisu pod Jpc01/uchaz_dok_typ = “4 - Podpisový vzor”

sken podpisu MÚ pod Jpc01/uchaz_dok_typ =“11 - Razítko a podpis”

nebo se v dané akci formuláře umožní zaměstnanci/MÚ z jejich disků takový sken na Opv31 uložit a to ve formátech “gif”, “jpg”, “jpeg”, “png”, “tif”, tiff”.

Konfigurace způsobu schvalování dat na formulářích v daném kroku workflow:

Na Adm33 v záložce Detail pro výše vyjmenované dotčené kroky workflow vznikla tato nová pole:

“Podpis“

Ano/Ne, nepovinné

“Typ“

Je-li hodnota pole “Podpis“ = Ano, pak se pro vyplnění tohoto pole nabídnou uživateli z comboxu následující hodnoty z číselníku Jpc01/seiad_typ: “10 - Elektronický podpis prostý“

Je-li hodnota pole “Podpis“ = Ano, pak pole “Typ“ musí být vyplněno

Je-li hodnota pole “Podpis“ = Ne nebo je toto pole nevyplněno, pak se pole “Typ“ zneaktivní

“Metoda“

Je-li hodnota pole “Podpis“ = Ano, pak se pro vyplnění tohoto pole nabídnou uživateli z comboxu hodnoty z číselníku Jpc01/seaid_metoda, pro které Jpc01/seaid_metoda.kod2 = “Podpis_metoda“

což jsou dnes ty záznamy, pro které platí Jpc01/seaid_metoda.hodnota = 101, 102, 103

Je-li hodnota pole “Podpis“ = Ano, pak pole “Metoda“ musí být vyplněno

Je-li hodnota pole “Podpis“ = Ne nebo je toto pole nevyplněno, pak se pole “Metoda“ zneaktivní

Defaultní hodnoty těchto nových polí zobrazených uživateli jsou nevyplněny.

Evidence spárování skenu podpisu s krokem workflow na frontendu:

Na záložce “Audit“ formulářů Dan/Das31/32/33/36 byl do tabulky přidán sloupec “Podpis“, kde je zobrazen proklik na blob použitého podpisu v cepdok.

3.21.3 Makra:

WF 5 Pozvánka na vzdělávací akci

+ WF 6 Zpráva o nedosažení min. počtu na vzděl. akci

+ WF 7 Zpráva o odhlášení ze vzdělávací akce

%ACTION_LABEL% Komerční název akce

%SPECIF% Specifikace (body obsahu)

%DATE_FROM% Akce od

%DATE_TO% Akce do

%EDU_ORG% Školící organizace

%EDU_PLACE_ADR% Místo škol. adresa

%LECTORS% Lektor (Lektoři)

%REFERENT% Referent vzdělávání

%CONT_PER% Seznam kontaktních osob – když jich je více, vypíše všechny

%NR_DAYS% Počet dní

%NR_HOURS% Počet hodin

%HOURS_FROM_TO% Hodiny od – do

%HTML_LINK% - Odkaz (web, ze způsobilosti)

%CONTENT% - Obsah kurzu (ze způsobilosti)

%LITER% - Literatura (ze způsobilosti)

%PARTIC% Počet účastníků

%MIN_PARTIC% Minimální počet účastníků

%ESTIMATED_COSTS% - Předpokládané náklady (cena_jeden)

%CENA_ORIENT% - Orientační cena (cena_orient)

WF 7 Zpráva o odhlášení ze vzdělávací akce

%REFERENT_JMENO% (pouze Jméno, Příjmení)

%REFERENT_PMI% (str3, pouze název prac. místa)

%REFERENT_TEL% (druh komunikace 12, pouze hodnota)

%NAHR_POCET% - Počet aktuálně přihlášených náhradníků

%ESTIMATED_COSTS% - Cena za jednoho účastníka: Kva06/Náklady na vzdělávání/Cena za jednoho účastníka

WF 8 Zpráva o expiraci period. způsobilosti

%JMENO_CELE% resp. %WHOLE_NAME% - celé jméno zaměstnance

%OSCPV% - osoba OSCPV

%DATE_TO% Platnost do

%ZPUS% Kód a název způsobilosti

%INVITE_TO% Pozvat do

WF 9 Pozvánka na lékařskou prohlídku

%NAZEV_LP% - Název způsobilosti

%DRUH_VYS_LP% - Druh vyšetření - LP

%DATUM_PROHL% - Datum prohlídky

%CAS_PROHL_OD% - Čas prohlídky od

%CAS_PROHL_DO% - Čas prohlídky do

%ZDRAV_ZARIZENI% - Zdravotní zařízení

%LEKAR% - Lékař

%LEKAR_ADRESA% - Adresa (lékař)

%LEKAR_TEL% - Telefon (lékař)

%PLATNOST_DO% - Platnost do

%POZVAT_DO% - Pozvat na prohlídku do

%DOBA_PRED_LP% - Doba předstihu LP

%DOBA_PRED_PSV% - Doba předstihu PsV

%PRIZNAK_PRIRAZ% - Příznak přiřazení

%PERIODA% - Perioda přezkoušení

%POZNAMKA_LP% - Poznámka

%DRUH_VYS_PSV% - Druh vyšetření-PsV

%PSYCHOLOG% - Psycholog

%MISTO_VYSETRENI_PSV% - Místo absolvování psych. vyšetření

WF 70 Expirace hesel

%TABLE_NAME% - název tabulky, ve které je heslo uloženo

%ID_RADKU%, - id záznamu z tabulky (viz výše)

%IDENTIF%, - název položky formuláře Adm57 – Autentizace nebo jméno a příjmení zaměstnance v případě formuláře Xpw0x (x = 2 nebo 3)

%PASS_DATUM_VZNIKU% - datum vzniku hesla

%DATUM_EXPIRACE% - datum expirace hesla

WF 91 Nepovedlo se odeslat soubor do DMS

%SEZNAM_DOKUMENTU% - seznam neodeslaných dokumentů do DMS

WF 95 - Notifikační sestavy DOCH/DAV - notifikační zprávy

%EMPLOYEES% =Seznam zaměstnanců (Osčpv, Jméno)

%EMPLOYEES_COMP_TIME_OFF_HOUR% =Seznam zaměstnanců (Osčpv, Jméno, Rozdíl NV)

%EMPLOYEES_MESSAGE% =Seznam zaměstnanců (Osčpv, Jméno, Kód hlášení)

%EMPLOYEES_MESSAGE_DATETIME% =Seznam zaměstnanců (Osčpv, Jméno, Kód hlášení, %Datum a čas)

%DATETIME_FROM% =Datum a čas od

%DATETIME_TO% =Datum a čas do

%DATE% =Datum

%MSG_CODE% =Kód hlášení

%PERIOD% = Období

3.21.4 Poznámky k provozu:

Workflow se dá také ladit tzn. neodesílat zprávy nebo odesílat a logovat správy.

To se nastavuje položkou Režim ladění workflow: s hodnotami:

1 - Standard - Odesílat workflow zprávy

2 - Workflow zprávy odesílat a logovat

3 - Workflow zprávy neodesílat a logovat

V záložce Log je potom prohlížení zapsaných informací.

Upozornění: používejte logování pouze krátkodobě pro ladění nebo řešení potíží, nikoliv trvale, generuje velké množství dat!

Režim odesílání zástupci

Na formuláři Adm33, na kartě „Detail“ à položka „Režim odesílání zástupci:“, je možnost pozastavit možnost odesílání emailu zástupci. V případě, že nastaven zástupce pro příjem emailu, je možno, touto wolbou, pro krok WFL nastavit, aby právě tento krok nebyl odeslán na zástupce (např. pokud je nutné odesílat veškerou poštu na zástupce, kromě pozvánek na školení). Tato možnost právě dovoluje toto možnost nastavit.

3.22 Adm34 - Zákaznické help odkazy

EGJE HR Portál volá zákaznické help stránky. K tomu je potřeba, aby je správce pro formulář, sestavu či menu definoval.

Adresování menu HR Portál:

Základní stránky HR Portál reprezentují objekty

11 - HR portál - rozhraní zaměstnanec

12 - HR portál - rozhraní manažer

Podmenu jsou pak reprezentovány objekty MENUDL
- např: MENUDL_Doch - HR portál - Docházka

Pozn. Volá se help stránka již otevřeného objektu. Tedy, aby se uživatel dostal na stránku podmenu Docházka, musí nejprve podmenu Docházka otevřít. To samé platí i pro okna a sestavy.

3.23 Adm42 - Nastavení a pojmenování dlaždic HR Portálu

Tento formulář je součástí řešení redesignu HR Portálu.

Pro přehlednost jednotlivých dlaždic, formulářů, sestav a jejich úrovní je v levé části formuláře vykreslena struktura, kde se na nulté úrovni nachází rozdělení menu na MANA (dlaždice v manažerském přístupu uživatele) a EMP (dlaždice v zaměstnaneckém přístupu uživatele). Na první úrovni jsou dlaždice, které obsahují přiřazené formuláře a sestavy nebo (nově) již další úrovně dlaždic.

V pravé části formuláře se nachází detail každé dlaždice/formuláře/sestavy a náhled na přiřazení do rolí včetně práva.

Formulář Detailu umožnuje:

- Přidání nové dlaždice:

i. Lze přidávat nové dlaždice nebo přiřazovat existující formuláře/sestavy v rámci existujících dlaždic

ii. Nová položka se vždy přidá pod dlaždici, na které uživatel stojí v rámci stromové struktury v levé části formuláře

iii. Nové dlaždice, případně přiřazení existujícího formuláře/sestavy pod dlaždici je ukládáno jako uživatelský záznam, tj. je možné takovou dlaždici/přiřazení i smazat

iv. Není možné přidávat novou nultou úroveň a není možné přidávat nové položky pod formuláře a sestavy – tyto už jsou konečné v rámci stromové struktury.

v. Při tvorbě nové dlaždice systém předvyplní část jejího názvu (MENUDL_) a uživatel pouze vytváří název za podtržítkem. Platí, že název objektu musí být unikátní v rámci celé nulté úrovně MANA nebo EMP

- Editaci stávajících dlaždic:

i. Dlaždici nebo formulář nebo sestavu lze:

1. uživatelsky přejmenovat

2. změnit pořadí pro zobrazení na homescreeně

3. zadat ikonku, která bude zobrazena na homescreeně

4. změnit nadřazenou dlaždici (lze pouze u formulářů a sestav, nelze u dlaždic)

ii. Objekty lze přiřadit k uživatelským rolím a změnit jim hodnotu práva

Takto vystavená struktura objektů je pak následně aplikována na homescreeně s přihlédnutím na objektová práva přihlášeného uživatele.

Pokud by přesuny formulářů došlo k tomu, že některá dlaždice by neměla podřízené formuláře, nelze ji smazat, ale lze v rámci Adm04 nastavit práva tak, že se nebude na homescreeně zobrazovat (karta Konfigurace použití, Hodnota vyřazení)

3.24 Adm51 – Změnové řízení databáze, statistiky, AS

Na záložce "Změna Db" se provádí po výdeji verze resp. patche změnové řízení databáze.

viz Provozní dokumentace.

3.25 A dm52 - Audit

3.25.1 Datový audit v EGJE obecně

Různé druhy provozních auditů a logů jsou popsány v EGJE_Provdoc.

Zde se budeme zabývat datovým auditem.

Datové formuláře EGJE v lokálním menu nabízejí volbu Auditní údaje záznamu.

V ní jsou údaje o záznamu, a ne o každé položce, a ne o každé změně záznamu, je zde pouze jeho vytvoření a poslední úprava nějaké položky z něj. Vždy uživatel a datum a čas.

Pokud je úprava dat provedena mimo formuláře EGJE, je místo uživatele uveden db uživatel a session.

Pozn.: v některých oknech je ještě spodní část okna věnována vlastní položce, ze které byl dialog zavolán, její hodnotě, číselníku, ale jsou to údaje o obsahu položky, nikoliv jejím auditu/změnách.

Záznam, to je větší či menší sada položek - a ty mají společné auditní "razítko". Z auditu se tedy ví pouze to, kdy naposled někdo změnil jednu z mnoha položek, které záznam sdílejí.

Proto také nenabízíme tyto informace na společných údajích o osobě, o PV resp. o Organizaci.

Neboť jsou společné velkému množství položek a uživatel by měl tendenci si je vysvětlovat mylně a dělat z nich nesprávné závěry kdo, kdy, co změnil.

Jsou ale místa v EGJE, kde je aplikován podrobnější audit.

Nejvíce je ho zobrazeno na speciálním formuláři Adm54. Zde je více přepínatelných auditních os.

Audit přihlášení a spouštění klíčových akcí a formulářů je na Adm52.

Na řadě dalších formulářů jsou pak speciální auditní záložky s detailním auditem vybraných položek a akcí. Často ale ne vždy se datově překrývají s Adm54.

Patří sem Adm10, Adm11, Adm12, Adm53, Vyp01, Vyp12, Dcm01, Dcd01.

Nastavení délky uchovávání dat v těchto auditních tabulkách se provádí v Adm21.

Také databáze poskytují různé stupně archivace datových změn.

U Oracle jde o režim ARCHIVELOG nahrávající všechny změny na archivní zařízení. Pomocí utility Logminer je pak možné tento archiv prohlížet. Jde ale o dost náročnou a odbornou věc. Zvážit je také potřeba výkonnostní dopad režimu ARCHIVELOG.

U Microsoft SQL Serveru se podobný režim jmenuje Full Recovery Mode.

EGJE opatřuje SQL manipulační příkazy komentářem odkud příkaz je (datový zdroj).

Od e201709 je tento komentář doplněn auditem, kdo a odkud příkaz inicioval (pokud to v tu chvíli aplikační server ví).

Údaje jsou strukturovány takto:

/* U$:uživatel C$:ip datový zdroj */

3.25.2 Vlastní formulář Adm52

Formulář zobrazuje údaje, které (také nově) shromažďujeme v databázi o základních akcích uživatelů v systému.

V auditu jsou tyto akce:

· Login - autentizace klienta
(v objektu práv je typ klienta: EGJE, EGJE-AS, EGJE-WEB, EGJE-WEB2)

· SessionEnd- odhlášení klienta

· ChooseProfil - výběr profilu (v objektu práv je verze javy, v popisu Profil)

· Report - spuštění tiskové sestavy

· Form - spuštění formuláře

· IndVyp - spuštění individálního výpočtu mzdy

· HroVyp - spuštění hromadného výpočtu mzdy

· MesUza - spuštění měsíční uzávěrky

· CepUza - uzávěrka cestovních příkazů

· RocUza - spuštění roční uzávěrky

· kopPv - měsíční kopie PV

· kopCis - měsíční kopie číselníků SLM a struktur

· obeImp - import mzdových vstupů Vst06

· ucto - výstup do účetnictví

· TaskNapocet - Per01 nápočet dob, tarifních stupňů, tarifů

· TaskPromitnuti - promítnutí tarifních stupnic na Osoby + PV

· aktualizaceSTR - aktualizace struktur

· davUzavriOtevriAktualizuj

· davZpetnyVyp

· dochDelCedmes

· dochDelPruchodu

· dochGenDD

· dochGenDZ

· dochGenMV

· dochHZPruchodu

· dochKalkulaceOdmen

· dochPrevodDDMV

· dochStravaGSRA

· dochStravaVYHOD

· dochUzavriOtevriAktualizujMV

· dochUzavriOtevriAktualizujPS

· dochVypEvidHodin

· dochZruseniPrevoduDDMV

· Prof.insert - přiřazení profilu přístupových práv uživateli

· Prof.update - změna přiřazení profilu uživateli

· Prof.delete - zrušení přiřazení profilu uživateli

· Ropr.insert - přiřazení role do profilu

· Ropr.update - změna přiřazení role do profilu

· Ropr.delete - zrušení přiřazení role do profilu

· Roel.insert - přiřazení objektu práv do role

· Roel.update - změna přiřazení objektu práv do role

· Roel.delete - zrušení přiřazení objektu práv do role

· Elcfg.insert - založení definice (ne)použití objektu v organizaci

· Elcfg.update - změna definice (ne)použití objektu v organizaci

· Elcfg.delete - zrušení definice (ne)použití objektu v organizaci

· DeleteWorkTab – mazání obsahu pracovních tabulek

(dle nastavení v Adm21 / Konfigurační parametry)

· SouhlasFotoYes/ SouhlasFotoNo - změna údaje Osb02/Foto/ Souhlas s využitím fotografie, kde kód objektu je potom ID osoby

Akce (změnové skripty, exporty číselníků) prováděné utilitou SuperConfigurator jsou také zapisovány do auditu. Kód elementu je pak „SuperConfigurator“ a uživatel je vzat z uživatele operačního systému uživatele, který SuperConfigurator spustil (s prefixem SC:)

"SC:doména\uživatel" pro windows,

"SC:uživatel" pro linux.

V auditu mohou být i další akce (hlavně jde o zákaznické a interfaceové).

Další zaznamenávané položky:

Uživatel (autentizace) : autentizační řetěžec, pomocí kterého se uživatel / proces přihlásil

Jméno : předchozí (v datech uloženou) autentizaci zde zobrazujeme jako osobu, která ji má přiřazenou. Pokud jich je více, není to obvykle správné, znamená to, že správce přiřadil jednu autentizaci více osobám (výjimkou je, když je např. jedna mzdová účetní zavedena ve více organizacích jedné db – pak je zde jako osoba vícekrát (nicméně měla by mít to samé jméno a příjmení)

Server IP, sezení: IP adresa(y) AS resp. EGJEWEB. U připojení java klienta bez AS je zde klientská IP.
Sezení je nějaké pořadové číslo EGJE, které spojuje všechny akce v jednom sezení (ať již jde o AS, EGJEWEB či klienta bez AS)

Klient IP: IP adresa (adresy) klientské stanice, tj. stanice, u které sedí uživatel.
U serverových akcí (Adm53) vyplněna není.

Trvání akce [s]: U tiskové sestavy, která úspěšně doběhla, je zde uvedena doba jejího vytváření.

Popis: Doplňující informace

U akce Login jsou zde údaje o klientovi, který se přihlašuje (liší se dle Typu aplikace)
U akce ChooseProfile je zde kód profilu, přes který se uživatel hlásí.

Číslo správní jednotky: Je vyplněno u uživatele, který je omezen díky profilu na jednu SJ

Správní oddíl: dtto pro SO

Organizace: dtto pro Organizaci (s tím, že organizace není součástí profilu, ale přiřazení profilu – Adm01/Adm10)

Vlastní osoba: Je vyplněno u uživatele, který má přístup pouze k datům vlastní osoby (řádková práva VL_OSO)

Datum a čas akce: Kdy akce proběhla, resp. byla zaznamenána.

Audit label: Auditní razítko tohoto auditního záznamu.

Profil autorizace: Profil uživatele (v auditu se od současného nazpátek hledá akce ChooseProfil pro konkrétního uživatele a jeho sezení).

Autorizace v: Datum a čas této akce.

Typ aplikace: EGJE, EGJE-AS, EGJE-WEB2 – podle klienta, přes kterého je uživatel přihlášen. U java klienta rozlišujeme přihlášení přes AS a bez něj.
Je zjištěn z předchozí uživatelovi autentizace (akce Login).

Autentizace v: Datum a čas této akce.

Tabulka parametrů:

Obsahuje parametry spuštěné sestavy/procesu, ale jen pokud je centrálně zaškrtnuta položka "Provádět audit parametrů akcí" a to zde na záložce Nastavení.

Nastavení:

Provádět audit spuštění formulářů: implicitně zaškrtnuto – zaznamenávat do Adm52

Provádět audit spuštění reportů: implicitně zaškrtnuto – zaznamenávat do Adm52

Provádět audit parametrů akcí: implicitně není zaškrtnuto – viz Tabulka parametrů popsaná v předchozím bodu.

Pozn.: automatické promazávání auditní tabulky (součást měsíční uzávěrky):

· Výkonové záznamy PERF* (spuštěné jen u některých zákazníků)
Ponecháváme pouze poslední měsíc.

· Standardní záznamy
ponecháváme posledních 6 měsíců
Mazání lze potlačit parametrem Adm21 / Konfigurační parametry / Potlačit mazání audit tabulky (Adm52).
Jsme však přesvědčeni, že mazání je vhodné a činnost formuláře Adm52 na něj spoléhá. Při jeho potlačení může být nutné pracovat s auditní tabulkou (cesaudit) mimo systém EGJE. Tabulka také ovlivňuje velikost dat při zálohování db.

Výkonové logování se spouští parametry logSlowDBRequests, logSlowWebRequests (hodnoty milisekund definující dlouhou odezvu) v souboru config_local.properties.

A je dobré je ihned po ukončení měření zase odstranit z konfiguračního souboru Web/Standardní aplikace.

Pozn. 2: promazávání starých auditních údajů systém provádí každý měsíc v měsíční uzávěrce (za celou databázi).

Výkonová data se ponechávají vždy jen za poslední měsíc, ostatní auditní data se ponechávají 6 měsíců. Toto promazávání lze vypnout na Adm21 / Konfigurační údaje / Potlačit mazání auditní tabulky (Adm52). Toto však doporučujeme pouze tehdy, pokud db správce odkládá data z tabulky cesaudit ručně do jiného úložiště.

3.26 Adm53 - Úlohy na AS

Formulář umožňuje nastavit/spravovat úlohy, které mají probíhat periodicky.

Typické použití je instalace EGJE s AS, kdy do položky Spustit na serveru s IP vyplňujeme IPv4 adresu aplikačního serveru (nikoliv host name). Můžeme zde také uvést jejich výčet, pokud máme AS více. Jako oddělovač IPv4 adres se používá čárka.

Mezi AS je také potřeba počítat EGJEWEB server, ten je také z pohledu Adm53 aplikačním serverem. IP adresa slouží k tomu, aby EGJE server zjistil, že je uveden mezi IP adresami a že se tedy má pokusit spustit v daný čas úlohu. EGJE obsahuje mechanismus, aby jednu zaevidovanou úlohu nespustilo více serverů.

Pokud máte třeba AS a EGJEWEB na stejné IP adrese a nechcete, aby např. EGJEWEB úlohy spouštěl. Je možné do jeho config_local.properties přidat parametr:

suppressjobs=true

který konkrétní instanci EGJE serveru ve spouštění úloh zabrání.

Elegantní možností jsou makra AS(db) resp. WEB(db), kde db je povinný parametr odkazující na databázi. Vyplňujeme je místo výčtu IP adres.

Př. AS(ELANOR@egjeprod)

Když je uživatel přihlášen jako klient AS, je při zadávání nové úlohy v Adm53 údaj předvyplněn.

Vyplnění makrem je praktické z těchto pohledů:

· při kopii db do testovacího prostředí, které běží proti jiné db, dojde k žádoucímu zastavení úloh (hlavně těch nebezpečných integračních)

· při změně IP adresy AS resp. přidání dalšího není třeba nic přestavovat

· odliší AS a WEB server - což je zvlášť užitečné, když jsou na jednom stroji

· když je AS spuštěný na tomcat / EGJEWEB, server se hlásí jako AS(db) a přebírá kontrolu spouštění úloh od EGJEWEB aplikace

Teoreticky je sice možné u instalací bez AS i zadat IP stanice, která bude běžet stále, ale toto je vyloženě náhradní řešení.

U denního spouštění se nastavuje čas (v 24-hodinovém formátu) v položce "Čas spouštění (denně)". Při potřebě jiné periodicity se vyplňuje položka "Čas spouštění (Cron formát)", kde se do položky zadává standardní formát unix - cron viz dále Poznámka.

Položka Příští spuštění pak umožňuje správci příští spuštění periodicky spouštěné akce odsunout na pozdější dobu. To může být vhodně např. pro odstavení zpracování průchodů po dobu změnového řízení apod. Nicméně mějte tuto položku na zřeteli, když například měníte čas spuštění, může být vhodné obsah položky Příští spuštění v tomto případě vymazat.

Funkce "Spustit nyní" spouští úlohu na aktuálním aplikačním serveru, ke kterému je uživatel v tu chvíli připojen, nikoliv na serveru, který je vyplněn pomocí IP adresy.

Pro vyzkoušení naplánovaní akce tedy zapište do "Čas spouštění (denně)" čas, který nastane za několik minut:

· pokud je aplikačních server jeden (tzn. shodný s komunikačním) tak postačí pro test dát například čas za 2 minuty

· pokud je aplikačních serverů více zadejte, čas větší než za 5 minut (to je doba, kdy si každý AS načítá seznam úloh znovu)

Dočasné pozastavení je možné provést vyplněním pole Příští spuštění datumem a časem, po kterém má být spouštění obnoveno.

Parametry "Organizace" a "Profil práva spouštěné úlohy" umožňují vymezit přístupová práva (hlavně k řádkům) spouštěné úlohy, tedy omezení nad jakými daty poběží.

Akce Hromadné akce / Nastavení IPs resp.makra všem úlohám v navigačním seznamu

je určena pro hromadné vyplnění této položky všem úlohám (v rámci výběru, byl-li proveden)

Další Hromadné akce:

Hromadné vypnutí

Hromadné zapnutí

umožňují aktivní hromadné akce vypnout / zapnout, resp. dočasně vypnout – hromadné vypnutí totiž nastavuje status -1 – Vypnuto hromadně, takže je pak možné později zase akce s tímto nastavením vybrat a Hromadně zapnout.

Hromadné vypnutí všeho se hodí pro testovací prostředí po instalaci nové kopie produkční db.

Pozn. Perioda spouštění -formát unix cron

Popis formátu, který je implementován:

http://www.sauronsoftware.it/projects/cron4j/manual.php#p02

Pro lepší orientaci v samotném cron formátu uvádíme popis jednotlivých pozic, co která označuje:

· První * => minuty (*, 0 … 60)

· Druhá * => hodiny (*,0 … 24 uvádět s nulou před danou hodinou, pokud je jednociferné číslo)

· Třetí * => den v měsíci (*, 0 … 31)

· Čtvrtá * => měsíc (*, 0 … 12)

· Pátá * => den v týdnu (*, 0 – Sunday, 6 - Saturday,….)

Vždy se musí dávat mezery mezi jednotlivé části.

Doporučujeme pro přesnější nastavení uvádět i 0 v minutových částech a v hodinových částech, pokud jde o jednociferné číslo v určení hodin.

Příklady použití Cron formátu :

*/15 * * * * každých 15 minut

*/15 6-18 * * * znamená každých 15 minut ale jen mezi 6:00 a 18:00)

30 0 1 * * proces spustí v 0:30 hodin vždy každého prvního v měsíci

30 20 L * * proces spustí v 20:30 v posledním dni měsíce (písmeno L).

30 2 * * Mon proces spustí v 2:30 každé pondělí

30 10 15 12 * proces spustí v 10:30 15.prosince

Pozn.: Více masek lze spojovat pomocí znaku "|" př. 30 10 15 12 *|30 10 14 12 *

Periodicky lze spustit tyto akce:

1 - Sestava (tisková, import, export, klient WS)

2 - Sestava přístupná jako Webová služba

6 - Zpráva o nedosažení min. počtu na vzděl. akci

8 - Zpráva o expiraci period. způsobilosti

9 - Zaslání zprávy přihlášeným uživatelům

10 - Upozornění na workflow

11 - Obsazení akce (vč. náhradníků)

15 - Notifikace RZD (nezaložené, neodeslané) (pro Dan40)

20 - Generování Poj17 – změny ZP CZ

31 - Kalkulace denní docházky za den dle režimu

32 - Kalkulace denní docházky od 1. dne do dne dle režimu

33 - Otevření zúčtovacího období (typicky měsíčně)

34 - Hromadné zpracování průchodů

35 - Kalkulace úkolové mzdy

36 - Kalkulace průchodů

70 - Expirace hesla (vazba na WFL Adm33, Akce 70)

101 - Úprava platnosti zdravotní způsobilosti podle věku (Zpu03)

102 - Generování požadavků zdr./psych. způsobilosti (dle Pozvat do)

103 - Úprava platnosti zdravotní způsobilosti (dle Platnost DO a 50 let věku)

104 - Generování požadavků na per. školení (dle Pozvat do)

105 - Upozornění na požadavky na vzd.akci

106 - Úprava platnosti zdravotní způsobilosti (první přepočet nad 50 let fixní)

107 - Generování požadavku návazného periodického školení

108 - Požadavek na zdravotní způsobilost

109 - Vzdělávání - automatizace náhradníků

Podrobný popis procesů z oblasti docházka (31, 32, 34, 35, 36) viz. Doch_dopl_uzivdoc.docx.

Pozn. Předvyplnění parametrů resp. přidání nových parametrů u už exitující úlohy realizuje funkce "Generuj parametry".

Na tomto formuláři Adm53 à na kartě Parametry àFormulářový pohled jde vybrat jako jednu z položek „Profil“. Pokud je tento profil nastavený na formuláři Adm26, pak zajišťuje možnost SFTP přenosu a taky možnost šifrování či dešifrování souboru.

3.26.1 1 - Sestava (tisková, import, export, klient WS)

Parametry pro úlohu 1.

Pokud se periodicky spouští sestava, pak je potřeba/možné zadat následující parametry:

*Jméno parametru*	*Typ parametru*	*hodnoty a popis*
Report	String	Kód sestavy
report_format	String	["pdf", "rtf", "html", "txt", "xls", "xlsx", "docx", "odt", "xlsx_formatted", "csv", "zip", "xls_old"] - v případě neuvedení parametru je default pdf Řada sestav podporuje jen některé formáty.
output_folder	String	Složka výstupního souboru(ů)
r_nazev_soub	String	Jméno výstupního souboru
Path	String	Parametr se zadává pouze u standardní sestavy a to vždy s hodnotou cz.elanor.eman.reports
...		Další parametry tiskové sestavy (viz soubor report.xml elementy parameter atribut name) U standardní sestavy je správce zjistí buď tak, že z ní zkopíruje uživatelskou sestavu a podívá se do pracovního adresáře nebo vstoupí do balíku eman.jar jako do zip souboru (např.Ctrl+PageDn v Total commanderu) a soubor nalezne na cestě 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		Parametry pro odeslání výsledku sestavy resp. protokolu o procesu
r_jiny_soubor r_jina_slozka r_jina r_ftp01_slozka r_ftp01_poznamka r_ftp01_kategorie r_ftp01		Parametry pro ukládání výsledku do Ftp01 nebo na jiné další serverové místo (viz Adm61 a Agenda výměny souborů)

Parametr pro akce generující protokol (typicky docházka)

*Jméno parametru*	*Typ parametru*	*hodnoty a popis*
max_protocols	Long	Počet protokolů z provedení akce, které mají být zachované (další starší jsou mazány)

Stručný popis:

3.26.2 2 - Uživatelská sestava jako WS

3.26.3 3 – Webová služba REST (realizovaná uživ. sestavou)

Pro typ AS úlohy 3 – WEBová služba REST na Adm53 byla provedena změna kontroly z nastaveného uživatele (Osoba – autor) případně „Změnu provedl“, pokud nebyl Osoba – autor zadán, na uživatele dle nastaveného profilu „Profil práv po spuštění úlohy“ tak, aby se kontroloval vůči autentizovanému uživateli. Jedinou výjimkou je situace, kdy je na Adm57 nastavena autentizace pomocí API key. To bude probíhat kontrola dle nastavené osoby na Adm53 à Osoba – autor.

Jakým způsobem nastavit Adm53 v případě typu AS úlohy = 3 je popsáno v dokumentaci EGJE_SW_provdoc.

Jakým způsobem nastavit autentizaci pomocí Adm57 je popsáno v této dokumentaci viz část 3.30

3.26.4 6 - Zpráva o nedosažení min. počtu na vzděl. akci

Parametry pro úlohu 6 Zpráva o nedosažení min. počtu na vzděl. akci

*Jméno parametru*	*Typ parametru*	*hodnoty a popis*
r_days_before	Long	Počet dní před začátkem akce, kdy se kontrola provede

Vlastní upozornění je definováno v Adm14 jako workflow akce č. 6. Změna hodnoty z 0 na 1.

3.26.5 8 - Zpráva o expiraci period. způsobilosti

Kontrola prochází Způsobilosti osoby (Kva01) v rámci řádkových práv a kontroluje platnost způsobilosti vzhledem k dnešnímu datu.

Proces zapíše údaj Pozvat do (cehtosozpus.pozvat_do), který vypočítá jako Platnost do – doba předstihu (tzn. jako na Kva01 per.škol. při uložení)

Proces se zabývá způsobilostmi těchto druhů: 12, 13, 31, 32, 41 (jpč druh_zpus), které ovšem mají v číselníku Zpu01 vyplněnou periodu (cehzpus.perioda)

Vlastní upozornění je definováno v Adm33 jako workflow akce č. 8. Změna hodnoty z 0 na 1.

Akce prochází způsobilosti procházející v období od dnešního data mínus počet dní zadaný parametrem r_kontr_zpus_x_dni. Pokud parametr není vyplněn, kontrola bere období od 1. v měsíci do aktuálního data

Kontrola zohledňuje, že po expirované způsobilosti má zaměstnanec zadanou stejnou způsobilost, která navazuje resp. je k aktuálnímu datu platná.

Dále má úloha parametr "r_id_toso_recips" - Místo příjemce z Adm14 odeslat na e-mail osoby:.

Pokud u úlohy vyplníte tohoto příjemce, dostává oznámení on a nikoliv osoby určené pravidly v Adm33 / akce 8 / krok 0=>1

Parametr r_status_to - "Výběr textu e-mailu (z Adm33, implicitní je 1):

určuje, který popis z Adm33 má být použit jako předloha zprávy:

0 - Univerzální startovní bod

1 - Expirace text 1

2 - Expirace text 2

3 - Expirace text 3

Věcně jednotlivé hodnoty číselníku odpovídají různým adresátům upozornění.

Parametr Výběr textu e-mailu. Navazuje na rozšíření číselníku u stejné úlohy v Adm33 – číselník parametru je shodný s uvedeným číselníkem. Implicitní nastavení hodnotou 1.

Zpracování příjemce přidaného u úlohy 8 přímo v Adm53 (který tedy není určen pravidlem).

Dosud tento příjemce obdržel každé zjištění zvlášť, nyní je to spojeno do jednoho e-mailu.

Obsahuje také parametr "Potlačit zápis Pozvat do" souhlas default Ne.

Parametry úlohy dovolovaly posunovat s datem, od kdy se má nesoulad zjišťovat (r_kontr_zpus_x_dni), ale už nikoliv do kdy. K tomu slouží nový parametr, který to doplňuje:

r_kontr_zpus_bud_dni s názvem "a které projdou v příštích x dnech (-1 = tento měsíc, -2 = příští měsíc)"

Při nevyplnění některého z nich se systém chová takto:

· Když r_kontr_zpus_x_dni = null and r_kontr_zpus_bud_dn i= -1,

tak datum_od = 1. akt. měs. datum_do = posledního akt. měs.

· Když r_kontr_zpus_x_dni = null and r_kontr_zpus_bud_dni = -2,

tak datum_od = 1. příští měs. a datum_do = posledního příští měs.

Parametr "Rozšířit o kontrolu vůči požadavkům z Pmi01". Pokud je parametr nastaven na hodnotu Ano, pak budou dosud kontrolované způsobilosti rozšířeny o ty, které jsou zadány na Pmi01 jako platné požadavky. Toto rozšíření platí pouze druh způsobilosti 11 a 12.

Parametr "Respektovat Pozastavení od-do”. V rámci expirace bere v potaz nastavení pozastavení způsobilosti na Kva01.

Parametr Posílat notifikace jednotlivě. V případě, že jeden zaměstnanec má více způsobilostí, kterým končí platnost způsobilostí ve stejný den, tak je nově možné notifikaci rozesílat každou zvlášť v samostatném e-mailu.

3.26.6 9 - Zasílání zprávy přihlášeným uživatelům

Zákazníkům s AS či EGJEWEB umožňuje nastavit periodické rozeslání upozorňující zprávy (např. před pravidelným restartem serverů), přičemž zpráva se napíše do Parametry – parametr message jako hodnota.

Profil ani jazyk nemá na zprávu vliv.

Tuto akci lze používat i pomocí funkce Spustit nyní (např. pro aktuální restart).

3.26.7 10 - Upozornění na workflow

Akce e-mailem upozorňuje manažery na workflow, které by měli zodpovědět.

Parametry akce jsou:

· Workflow požadavek - možnost omezit na konkrétní workflow (nepovinný par.)

· Číslo notifikace - odeslaná upozornění se u workflow ukládají, parametr umožní zvolit, kolikáté upozornění má být vzato do výběru a odesláno.
Není-li uvedeno, akce provádí první upozornění.

· Odesilatel - e-mail odesilatele

· Režim ladění - umožní cvičné spuštění bez generovaných e-mailů

3.26.8 33 - Otevření zúčtovacího období (typicky měsíčně)

Úloha vytvoří výplatní termíny pro následující měsíc, a to pro ty SO/SJ, ke kterým má profil přístup (viz Vyp02, Dcu02, Cep02) a které jsou v otevíraném období platné.

Vytváří ty záznamy, které byly v minulém měsíci a jsou platné i pro zakládané období nebo jsou nově platné v zakládaném období, respektuje tedy i skladbu typů VT.

Postup generování (opakovaně pro každé požadované období):

Vytvoříme seznam platných SO pro období generování (pro dobírkové VT) .

Pokud se jedná o SO platné v předešlém období - zkopírujeme z předešlého období

Pokud se jedná o nový SO - vytvoříme nový záznam s nastavením podle Adm22 (do protokolu se zobrazí hlášení a je potřeba doplnit nastavení podle potřeb organizace)

Potom pro každé SO v seznamu nastavíme:

Status VT 1 nebo 2 - podle volby.

Datum výplatního termínu podle konfigurace.

Pro každé období pak se provede:

Měsíční kopie číselníků SLM a struktur (pro všechny ORG, SO za období) - pokud je povoleno, v rozsahu Vyp02

Hromadné generování kalendářů (pro všechny ORG, SO za období) - pokud je povoleno, v rozsahu Vyp02

Pro DOCH instalace, hromadné generování docházky osobám/Pv s
Opv01 / Režim / Režim zpracování docházky = 10 - Generování přítomnosti dopředu (z kalendáře).

Pro instalace bez docházky (nemají nastavenou položku Adm21, Docházka, Slm pro evidenci odpracované doby) se otevírá standardně jedno období (viz parametry), pro instalaci s docházkou se standardně otevírají 2 období. Pro druhé otevírané období se neprovádí mazání historických dat pracovních tabulek.

Pokud se jedná o instalaci typu multiorganizace, zjišťujeme nastavení pro docházku pro hlavní Organizaci, pokud je nevyplněno, tak vyhledáváme na všech organizacích - pokud je nastaveno alespoň na jedné, považujeme za DOCH.

Poznámky k provozu:

Pokud se spouští pro více období, vymazání historických dat podle stanovených podmínek na Adm21 se provádí pouze pro první.

Parametry:

Datum generování (r_datum_gener)

nastavení bez paměťového efektu, slouží pouze pro jedno spuštění.

pokud je vyplněn Datum generování, spustit pro tento datum, pokud je nevyplněn, tak z referenčního data profilu)

formát pro zadání: rrrr-mm-dd

Status výplatního termínu: - default 1 (paměťový efekt)

Volba 1 nebo 2

nastavení pro nové SO/období

Den výplatního termínu v BM: - povolená hodnota 1 - 32 (paměťový efekt)

při nevyplnění - položka se nenaplní

při zadání dne na neplatný den měsíce - položka se nenaplní (např. 31 na únor)

při zadání na den svátku - posun na předešlý/násl. prac. den

(svátek stanoven z číselníku svátku a LEG pro SO, pro Typ svátku = 1)

při zadání na volný den - posun na předešlý/násl. prac. den (za volný den budeme považovat So/Ne)

při zadání:

= 32 tak den se nastaví na poslední den v následujícím období po otevíraném období

= -32 tak den se nastaví na poslední den v otevíraném období

>= 0 pak datum je v následujícím období po otevíraném období

< 0 pak datum je v otevíraném období

Pokud je parametr vyplněn, tak pro nové SO/období nastavíme položku na zadaný den v období

Pokud den padne na den svátku nebo So/Ne, posuneme datum podle akt. obsahu parametru Posun výplatního termínu při SV a nepř. dni

Posun výplatního termínu při SV a nepř. dni - posun den výplaty na nejbližší pracovní den, default = 1 (paměťový efekt)

Číselník:

0 - bez posunu

vždy se použije datum určeného dne

1 - posun na nejbližší předešlý pracovní den

pokud spočtený datum padne na den SV nebo So/Ne - posuneme na datum předešlého pracovního dne

2 - posun na nejbližší následující den pracovní den

pokud spočtený datum padne na den SV nebo So/Ne - posuneme na datum následujícího pracovního dne

Měsíční kopie číselníků SLM a struktur - volba Ano/ne, default Ne (paměťový efekt)

funkce v rozsahu Vyp02, Popis, Měsíční kopie číselníků SLM a struktur (pro všechny ORG, SO za období)

pokud je Ne - tak se kopie číselníku neprovádí

pokud je Ano - tak se kopie provádějí

Hromadné generování kalendářů - volba Ano/ne, default Ne (paměťový efekt)

funkce v rozsahu Vyp02, Popis, Hromadné generování kalendářů (pro všechny ORG, SO za období)

pokud je Ano - tak se kalendáře generují a zároveň se mažou historické údaje z tabulek

pokud je Ne - tak se kalendáře negenerují, ale také se nečistí historické data

Seznam SO, pro které neotvírat období - default nevyplněno (paměťový efekt)

pokud je SO v seznamu, tak bude vyloučeno z generování

Počet otevíraných období: (r_pocet_mes_predstihu)

Počet měsíců předstihu, povolená hodnota 1 až 12)

při spuštění zkontroluje / vytvoří dopředu více období a v nich vygeneruje kalendáře

Max. počet uložených protokolů: (max_protocols)

Počet protokolů, které mají být zachované v systému

Standardní parametry formuláře Adm53:

Odeslat protokol na e-mail: (r_send4error2ext)

Minimální úroveň chyby pro odeslání protokolu: (r_send4error2ext)

Adresář pro uložení výstupu:

Název souboru:

Odesílatel e-mailu:

Odeslat výsledek osobě interní poštou:

Odeslat výsledek osobě e-mailem:

Odeslat výsledek na e-maily:

Odeslat výsledek osobám na profilu interní poštou:

Odeslat výsledek osobám na profilu e-mailem:

3.26.8.1 Poznámky k provozu

Hlášení o “existujícím” období

Pokud při otevírání období se zjistí, že období je již otevřené, zobrazí se hlášení:

Obd. <obd> pro SJ <sj>, SO <so>, Typ VT <typ> je již otevřeno

a pokračuje se k funkci generování kalendářů pro období.

Hlášení o “neexistujících” SO k „otevření“ pro období

Pokud při otevírání období se zjistí, že seznam SO pro otevření je prázdný (nejsou žádné SO pro které je potřeba otevřít období), zobrazí se hlášení:

Pro období <obd> nenalezeno žádné období pro otevírání !

a funkce se ukončí.

Upřesnění funkce, pokud není “zaškrtnutá” volba volitelných kroků:

Když parametr není uvedený parametrech úlohy 33 pro Adm53 (historicky založené záznamy, nebo chybná aktivace úkolu):

· Hromadné generování kalendářů se chová jako by bylo zaškrtnuto

· Měsíční kopie číselníku SLM a struktur se chová jako by nebylo zaškrtnuto

· Generování kalendářů pro budoucí období do konce roku se chová jako by nebylo zaškrtnuto

Když je parametr uvedený v parametrech chová se podle toho, zda je zaškrtnutý nebo ne.

Omezení “mazání historických dat”

Pokud se současně otevírá více období (nastaven parametr Počet otevíraných období) tak se mazaní provede při každém otevíraném období v rámci funkce Hromadné generování kalendářů.

Pokud je zapnutá funkce Generování kalendářů pro budoucí období do konce roku, tak se mazaní pro pouze aktualizované období, mazaní neprovádí.

Volba období spuštění (při kontrole resp. opětovném požadavku na otevírání)

Aby bylo možné otevírat i později než v akt. období, je k dispozici parametr:

Období pro výběr: - referenční období pro spuštění úkolu

Nevyplněno (default) - pak se použije období podle ref. období

Vyplněno, tak se použije pro výběr období, podle kterého budeme otevírat

Pozor: Pro uzavřené období pro SO se nesmí spouštět hromadné funkce akt. kalendářů/číselníky.

Otevírání “nových SO”

Vytvoříme seznam o SO, které jsou v Adm23, jsou nové pro období “referenční + 1” a nemají záznam ve Vyp02.

Pro každé SO v tomto seznamu zobrazíme hlášení:

Nový SO <so> platný pro <obd>, založen pro Vyp02

doplníme do základního seznamu období pro otevírání a položky nastavíme podle parametrů úkolů.

Souběžné spuštění úlohy

Při spuštění se provádí kontrola pro souběžné spuštění úlohy Adm53/33 a především zabránění současného kopírování číselníku v rámci otevíraní období.

Při souběžném spuštění, kdy jeden proces již běží, tak si druhý proces ošetří stav, přeskočí blokující úkol a do protokolu vloží hlášení:

cz.elanor.eman.datasource.remoteCompute.LockerException: Akci nelze provést. Uživatel právě provádí jiné akce, které ji blokují proti spuštění.

Blokující úloha: "Hromadné generování kalendářů"

parametry: "Hromadné generování kalendářů (pro všechny SO za období ) 2024-01=r_kod_obd"

" spuštěna uživatelem:, čas spuštění:29.12.2023 20:19."

a proces se korektně ukončí.

3.26.9 70 Expirace hesla

Úlohu 70 je třeba definovat v souvislosti s Adm33 a akcí workflow 70 a dále v návaznosti na konfiguraci 105 – Expirace hesla ve formuláři Adm70.

Kontrola prochází tabulky definované v rámci Adm70 v rámci konfigurační položky 105. Z této položky si načte počet kalendářních dní. Následně prochází záznamy v těchto DB tabulkách a odečítá hodnotu načteného počtu kalendářních dní od hodnoty expirace hesel. Pokud najde záznam, kde datum expirace mínus počet KD je menší nebo rovno aktuálnímu datu, vygeneruje tento záznam do logu. Log následně se všemi položkami odesílá na předem definovaného uživatele – buď přímo na Adm53 nebo dle nastavení v Adm33.

Parametry pro úlohu 70:

· Kontrola x kalendářních dní před expirací → r_kontr_kal_dni - editační pole pro zadání kladného celého čísla (definice počtu dní, které se zadají pro výpočet datumu upozornění na končící platnost hesla). Parametr je povinný, default je 10 dní

· E-mail příjemce → r_typ_kontaktu_recips - položky číselníku komun_druh (pouze položky 30-39). Pokud není vyplněno, default je 31 - E-mail v zaměstnání. Parametr není povinný, pokud není vyplněn a není ani vyplněna hodnota r_id_toso_recips, bere se přednostně z Adm33

· Místo příjemce z Adm33 odeslat na e-mail osoby → r_id_toso_recips - seznam osob s možností vybrat jednu konkrétní, parametr není povinný, pokud není vyplněn, berou se hodnoty z Adm33. Nabízí se pouze živí uživatelé aplikace (pro cetpv.kmenovy = 1 platí, že aktuální datum je mezi dat_nast a dat_ukon)

3.26.10 101 Úprava platnosti zdravotní způsobilosti podle věku (Zpu03)

Úloha kontroluje zdravotní způsobilosti podle nastavení v číselníku Zpu03.

Nastavuje u nich údaje Platnost do, Pozvat do, Perioda – ruční úprava.

Výpočet datumu Platnost do u poslední platné způsobilosti vzniká kopií z datumu předchozí shodné způsobilosti, a to hodnot den a měsíc.

Parametr: Přepočet platnosti do podle aktuálně nastaveného parametru (jednorázová úprava). Tento parametr slouží pro jednorázový přepočet hodnoty Platnost do v případech, kdy chce uživatel změnit podmínky pro výpočet datumu u položky Platnost do, a to změnou vstupního parametru "r_gener_platnost_do" této úlohy.

Parametr: Generovat platnost podle 373/2011 Sb. [CZ] nastavuje způsob generování Platnosti do. Při nevyplněno a Ano se chová tak, jak je popsáno výše, při nastavení na Ne, pouze přepočítá periodu v závislosti na věku a Zpu03.

3.26.11 102 Generování požadavků zdr./psych. způsobilosti (dle Pozvat do)

Úloha vytvořená pro každodenní spouštění. Generuje požadavky do Kva05f / Požadavky – zdravotní způsobilosti pro Osoby/Pv které mají definovanou platnou zdravotní a psychologickou způsobilost v Kva01, a jejíž datum Pozvat do je dnešním datumem (tj. datumem, kdy je úloha spuštěna).

Proces u požadavku vyplní způsobilost a hodnotu Plán do (použije datum Pozvat do ze způsobilosti osoby).

Pokud už uvedený požadavek existuje, není generován.

3.26.12 103 Generování požadavků zdravotní způsobilosti (dle Platnost do a 50 let věku)

V rozmezí od datumu spuštění + 3 měsíce kontroluje osoby s platným PV, které dosáhnou v tomto období věk = 50 let (viz datum narození).

Pokud takovou osobu v tomto časovém úseku najde, dočasně ukládá datum, ve kterém osoba dosáhla věku 50 let jako parametr pro porovnání

Dále porovnává toto datum s nejvyšší Platností do ( viz db tab <cehtosozpus>) u záznamů zdravotní způsobilosti (druh způsobilosti = 31)

Pokud je datum Platnosti do shodné nebo nižší než datum jubilea, pak tuto Platnost do přepisuje datumem tohoto jubilea.

3.26.13 104 Generování požadavků na per. školení (dle Pozvat do)

Úloha pro Periodická školení dělá to samé, co dělá úloha 102 pro zdrav./psych. způsobilosti.

Tzn. zpracuje způsobilosti, které mají Pozvat do =DNES a Platnost do >=DNES a to pro způsobilost s druhem 12 – Periodická školení.

Úloha je spouštěná bez parametrů začátku a konce určena pro každodenní spouštění s parametry umožňuje např. měsíční spouštění.

Má tyto nepovinné parametry:

Začátek vyhodnocování (počet dní před dnešním datem):

Konec vyhodnocování (počet dní před dnešním datem):

Př.: Vyplnění 31 a -2 pak znamená testovat propadlé (včetně předstihu tj. Pozvat do) v posledních 31 dnech až do těch, které projdou za 2 dny.

Při nevyplnění obou se pak testuje to, co má Pozvat do = DNES a je ještě platné tedy Platnost do >= DNES.

Skupina

Výčet podskupin (ala Adm02)

Výčet způsobilostí (jen periodické)

Její použití předpokládá korektně vyplněné položky Pozvat do, Platnost do.

Jejím výsledkem jsou Požadavky na periodická školení (Kva06, Kva07, Kva08)

3.26.14 105 Upozornění na požadavky na vzd. akci

Upozorňuje na požadavky, které zůstaly ve statusu 0 a 3, když dnešní datum > datum Plán do.

Generuje e-mail autorovi požadavku a zaměstnanci, o kterém je požadavek (pokud v Osb02 má zadaný e-mail do zaměstnání).

Týká se požadavků s druhem způsobilosti 11-21 a 41.

11 Znalosti a schopnosti

12 Profesní periodická školení

13 Znalostní moduly

14 Odborná způsobilost

21 Jazyky

41 BOZP

Úloha respektuje nepovinnou konfiguraci adm21 / Vzdělávání / Výčet skupin pro workflow 3. Pokud není vyplněná, týká se akce všech skupin.

(vzd_wfl3_skup_list)

3.26.15 106 Úprava platnosti zdravotní způsobilosti (první přepočet nad 50 let fixní)

Periodicky spouštěná Úloha 101 kontroluje u každé aktivní zdravotní prohlídky zaměstnance, jestli perioda přezkoušení odpovídá nastavení na Zpu03 podle aktuálního věku zaměstnance. Nastavení Zpu03 vychází z ust. §11 vyhlášky č. 79/2013 Sb., kde se konstanta 50 let věku vyskytuje v předpisech periodických prohlídek většiny pracovních kategorií.

Úloha 106 má u vybraných klientů nahradit používání úlohy 101. Úloha 106 funguje stejně jako jako úloha 101 s tím rozdílem, že u aktivních prohlídek zaměstnanců starších 50 let neupdatuje periodu přezkoušení těch z nich, které zaměstnanec absolvoval před dosažením věku 50 let.

Podobně jako u úlohy 101 je pro úlohu 106 na Adm53/Parametry (Formulářový pohled) zařazen parametr “Generování platnosti do podle 373/2011 Sb.“, kterým se Platnost_do úlohou zpracovávané prohlídky upravuje v DD.MM. podle zaměstnancovy předchozí zravotní prohlídky stejného typu.

3.26.16 107 Generování požadavku návazného periodického školení

1) generuje požadavek (Kva07/Periodická školení)

- Plán OD = datum spouštění jobu,

- Plán DO = impl. maska 3.3.3333,

- povinná Způsobilost = hodnota návazného kurzu

pro všechny osoby s platným PV, které mají datum platnosti DO (druh_zpus = 12) < 3.3.3333 a zároveň je hodnota Návazný kurz z a Zpu01 vyplněna.

2) ukončuje platnost DO u osoby/původního kurzu -> tím ho vyřadí z dalších kol generování, ale zůstává dál platný.

3.26.17 108 Požadavek na zdravotní způsobilost

Tento typ AS úlohy při nastavení automatiky generuje požadavek na zdravotní způsobilost, který se následně propíše na formulář Kva05f. Proces vygeneruje seznam osob, které nemají platnou zdravotní způsobilost a vygeneruje pro ně nové žádanky. Tento proces nahrazuje funkcionalitu formuláře Hod05, kde se žádanky musely vystavovat manuálně. Při spojení procesu s Adm53 je to automatický proces, kde není nutné manuální generování.

3.26.18 109 Vzdělávání - automatizace náhradníků

Úlohu 109, která v uživatelem určených časových intervalech identifikuje volná místa na vzdělávacích akcích a v případě, že takové místo bude nalezeno a daný běh akce bude evidovat seznam náhradníků, dle pořadí, v jakém se coby náhradníci přihlašovali, bude měnit jejich status z náhradníka na účastníka (ze stavu 9 na 4). Kromě parametrů začátek a konec vyhodnocování (vůči dnešnímu datu), lze specifikovat Skupinu, výčet podskupin a případně i výčet způsobilostí, které má sledovat.

3.27 Adm54 - Speciální audit

Formulář zobrazuje auditované situace z oblasti struktur (Str01, Str02), srážek (Sra01) a údajů o osobě (Osb01, Osb02)

a některé auditní údaje již zobrazované na Vyp01/Audit resp. Adm11.

Kromě dále uvedených údajů je v záznamu vždy kdo a kdy změnu provedl, případně o jaký typ akce šlo (vložení, editace, smazání).

Formulář používá přepínatelné navigační seznamy:

nav.sez. 1. Osoby

Záložky

Osoba - údaje:

Rodné číslo:

Celé příjmení a jméno:

Globální identifikátor osoby:

Datum od jména/příjmení:

Datum do jména/příjmení:

Komunikace - údaje z Vyp01 Audit/E-mail ale zde pro všechny druhy komunikace

Srážky - údaje

Srážka: (ID)

Složka mzdy:

Předčíslí:

Číslo účtu:

Směrový kód banky:

IBAN:

Variabilní symbol:

nav.sez. 2. Osoby / PV

záložky z Vyp01

Audit / Platby

Audit / Tarif

Audit / Pv

a z Adm11 / Smazaná PV

nav.sez. 3 Bankovní cesty - údaje

Bankovní cesta: (ID)

Číslo správní jednotky:

Druh příjemce:

Způsob úhrady:

Způsob zasílání převod. příkazu:

Správní oddíl:

Nadřízený záznam za SJ:

Účet odesilatele:

Forma doprov. seznamu hr. úhrady:

Číslo dávky převod. příkazů:

Platnost:

Účet hromadné úhrady:

IČO hr. příjemce:

Konst. symbol hrom. úhrady:

Předčíslí hromadné úhrady:

Banka hromadné úhrady:

IBAN hromadného příjemce:

BIC kód (SWIFT) hrom. příjemce:

Spec.symbol hrom. úhrady:

Variabilní symbol hrom. úhrady:

Číslo zdravotní pojišťovny:

nav.sez. 4. Struktury - audituje změny prvku struktury a jeho vazeb

Odkaz na strukturu:

Typ struktury:

Datum/čas změny stavu:

Uživatelský kód:

Datum vzniku (evidenčně):

Datum zániku (evidenčně):

Hladina-ruční úprava:

Číslo skupiny řádkových práv:

Váže se na prvek struktury:

Nadřízený typ struktury:

Kód nadřízeného záznamu:

Datum od vazby:

Datum do vazby:

3.28 Adm55 – API a prostředky

Formulář Adm55 umožňuje nastavit konfiguraci implementovaných API a prostředků poskytovatelů služeb pro oblast elektronických podpisů, identifikace a doručení. Konfigurace API a jejich prostředků bude využívána pro realizaci plánovaných funkcionalit nových, samostatně uvolňovaných komponent pro elektronické podpisy (zpoplatněná oblast) a elektronického podání.

Záložka API

Tato záložka obsahuje základní parametry rozhraní pro jednotlivá prostředí (Konfigurace API). Jde o parametry potřebné pro připojení k danému rozhraní – URL, port, požadovaný typ šifrování dat, typ autentizace a autentizační klíč, přístupový účet a heslo atd.

Záložka Prostředky

Jednotlivá rozhraní mohou poskytovat set služeb, které zajištují pro dané oblasti elektronické komunikace mezi subjekty. Tyto pro dané API definujeme na záložce Prostředky. Součástí je i přiřazení organizace a SJ, které mohou daný prostředek využívat.

Parametry

Na úrovni API, Prostředků i přiřazených Organizací a SJ je možné dynamicky nastavit další parametry potřebné pro využívání služeb daného API. Např. jde o tokeny, další URL (např. pro autentizaci). Hodnoty těchto parametrů je možné evidovat v nešifrovaném nebo šifrovaném režimu.

Konkrétní nastavení pro jednotlivá API a jejich prostředky jsou součástí implementačních pokynů vázaných na funkcionality EGJE, která využívají tyto služby.

Doporučené nastavení pro VREP e-Podání na ČSSZ. Kódy pro API, Konfiguraci API, Prostředky API doporučujeme používat podle tabulky níže buď pro testovací, nebo pro produkční účely. Prostředky API musí mít platný záznam pro ORG a SJ, pro kterou bude zpracovávaná agenda e-Podáni.

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

Doporučené nastavení pro ISDS agendu. Kódy pro API, Konfiguraci API, Prostředky API doporučujeme používat podle tabulky dole. Prostředky API musí mít platný záznam pro ORG a SJ (Adm55 – Prostředky API - dole), pro kterou bude zpracovávaná agenda ISDS. Od verze e202311 je možné zpracovávat výzvy doručené ISDS z Úřadu práce v EGJE manuálně podle popisu ve změnové dokumentaci.

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í		3	30	300

Pro komunikaci přes datovou schránku je potřeba certifikát ISDS pro zabezpečenou komunikaci mezi servery. Tento může být načítán z datových struktur EGJE nebo může být uložen a načten ze systémové úložiště. Pokud pro uložení certifikátu ISDS bude použito systémové úložiště, cesta k adresáři s certifikátem je evidována v atributu API\Konfigurace API: Cesta k úložišti certifikátu (CA). Pokud je certifikát opatřen heslem, pak heslo se eviduje v rámci atributu Heslo k certifikátu (CA). Závazný název certifikátu v systémovém úložišti je: pro produkční prostředí isds_prod.jks, pro testovací prostředí isds_test.jks

ePN (SK) - služba B2B Sociální pojišťovny

Doporučené nastavení pro agendu ePN (SK) - služba B2B Sociální pojišťovny. Nastavení obsahuje URL adresy pro které je nutné povolit komunikaci z EGJE (firewall, proxy).Uvádíme kořenové URL z důvodu, že v mezikroku se získává access token z jiné větve URL adresy, jako samotná komunikace(viz níže konfigurace a parametry):

· esluzby.socpoist.sk pro produkční běh

· test.socpoist.sk pro případné testy (toto prostředí je určeno pouze pro SW společ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/

prázdne

Další parametry API

Pro každé prostředí je definovaná sada technických parametrů. Pro produkční beh je to následovný seznam. Adm55-Prostredky - parametry přirazeni prostredku (pro každou SJ samostatné):

Typ parametru	Hodnota parametru
52 - API Call AuthValue	ICZ zaměstnavatele (pro identifikaci klienta)
20 - OFFLINE token	Token získan z portálu SP

Pro funkční propojení do SP (SK) je nutné zajistit offline token na straně klienta pro autentizaci vůči výše uvedené službě. Viz https://esluzby.socpoist.sk/portal/swagger-ui/index.html#/Elektronick%C3%A1%20PN.

Poté zadejte do skriptem připraveného parametru (vyplňte pole hodnota parametru, nebo hodnota parametru šifrovaná podle aktívní položky)

Adm55 – Doplňte hodnotu parametru prostředku (pro každou SJ zvlášť) manuálně:

· AuthValue - ICZ zaměstnavatele, (nebo jiný dodaný identifikátor pro tento účel)

· Offline token - token z portálu SP dle pokynů SP.

Adm55 API – Parametry API (odlišuje se pouze URL podle typu prostředí):

Typ parametru	Hodnota parametru	Prostredi
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

Parametry bylo možné importovat v Adm51 pomocí inicializačního skriptu distribuovaného s verzí 202405.

Ve verzi 202409 je nastavení API naplněno plošně instalačním skriptem automaticky. Účelem je, aby se zabránilo vzniku chyb při manuálním plnění.

Poznámka: Pro nastavení funkčního podání ePn SK je z důvodů vazeb propojeno nastavení Adm60 Adm28 a Adm55.

3.29 Adm56 – Definice nápovědy

Formulář Adm56 slouží pro definování nápovědy, která se zobrazí u zvoleného zobrazovaného elementu na formuláři – formou hintu.

Upozorňujeme, že toto je prozatím pilotní funkčnost a zobrazení se bude ještě v průběhu času upravovat dle zjištěných možných problémů a požadavků zákazníků. Jako první se tato funkcionalita bude optimalizovat pro formuláře týkající se daňovky (Dan31, Dan32, Das31 a Das32). Je možné, že by mohlo díky zobrazení nebo naopak nezobrazení „Nápovědy“ dojít k posunutí zarovnání řádků či textů. Z takovém případě, pokud se nebude toto zobrazení zamlouvat, je možno doplnit chybějící nápovědu pro tento řádek, například jen nápovědou s popiskem názvu pole.

Je čistě na uvážení zákazníka, zda bude chtít také popisovat celé bloky, které mohou způsobit posunutí zobrazení na celé stránce. Takový blok jde jednoduše identifikovat, protože má vedle sebe nápis nápověda.

Formulář obsahuje v pravé části navigační seznam s výběrem formulářů, pro které jde nadefinovat nápověda. Dále pak v horní části je seznam, elementů zvoleného formuláře. Po kliknutí na tento element se dá vytvořit popisek v k němu definovaném jazyce. Pokud je takto vytvořený popisek uložen, funkcionalita zajistí, že se u daného elementu na formuláři vytvoří ikonka, na kterou se dá kliknout a daný se popisek se zobrazí jako nápověda k danému formulářovému elementu.
Celá funkcionalita bude funkční od verze e202311, kde se dodá automatické zobrazování nápovědy na formulářích, které budou mít tuto nápovědu nadefinovanou na Adm56.

Obecný postup

· v navigačním seznamu vybrat formulář, na kterém se má vytvářet nápověda

· v horním seznamu se načetly všechny položky z vybraného formuláře z navigačního menu a kliknutím na danou položku formuláře, se položka označí k editaci nápovědy
Obsah obrázku text, snímek obrazovky, software, displej

Popis byl vytvořen automaticky
Pokud už existuje u položky popisek s nápovědou, bude možné ji editovat, jinak pouze zadat nový popisek nápovědy

· následně se vybírá jazyk popisku ze seznamu (rolldown menu)

· Do pole „Popis:“ se zadává popis nápovědy ve zvoleném jazyce (k jazykové kontrole nedochází, takže pokud je vybrán jazyk a popisek mu neodpovídá, bude takto nápověda uložena do DB

Pozn. V případě, že neexistuje překlad pro AJ mutaci, bude zobrazena nápověda v CZ jazykové mutaci.

3.29.1 Export Hintů do jiné DB

Pomocí této funkcionality půjde exportovat Hinty do jiné DB. Na stránce Adm56

3.30 Adm57 – Ověření

Nový formulář umožňuje nastavit konfiguraci autentizace WS, která se až do verze e202401 dala nastavit pouze v konfigurátoru.V něm nyní lze nastavit, kde se má WS ověřovat. Zda v aplikaci (tj. zde na formuláři Adm57) nebo v konfigurátoru nebo případně obojí – popsáno v rámci samostatné dokumentace EGJE_WS_provdoc.

Na Adm53 pak lze vybrat autentizaci pro konkrétní Rst sestavu – viz 3.26.3

Formulář obsahuje seznam autentizací a detailový formulář pro zadání a editaci nastavení.

Povinné položky k založení záznamu jsou Kód (který musí být unikátní v rámci tohoto formuláře a nastavení), Ověření (který se řídí číselníkem CisAuth) a platnost záznamu.

Dle číselníku Způsob ověření jsou konfigurační parametry rozděleny do tří oblastí: NT Login/2 JCIfs, LDAP a APIKey a dynamicky mění zadání detailu vybrané konkrétní autentizace.

U záznamů, které jsou definovány jako NTL* a mswin_ntl*, je možné v rámci položky Účet počítače pro připojení k DC (NT Login2) – Heslo definovat konfigurační parametry pro tvorbu a editaci hesla – popsáno v dokumentaci v části 3.37.1.

Stejně tak je možné definovat tyto konfigurační parametry i u záznamů definovaných jako API key a to v případě položky API – Heslo.

Jak vyplnit položky v rámci jednotlivých autentizací je popsáno v rámci EGJE_provdoc část Ověření.

3.31 Adm58 – nastavení notifikací na daňové slevy

Tento formulář slouží pro nastavení sledování končících daňových slev zaměstnanců. Je funkčně propojen s Kon07, kde se spouští zpracování a vyhodnocení končících daňový slev.

Na Adm58 se skládá ze seznamu, kde se zobrazují nadefinované daňové slevy, která se mají vyhodnocovat a k napojení na odesílání notifikací, které probíhá pomocí nastavení workflow na Adm33, kde jsou definované konečné statusy pro odeslání notifikací.

Adm58 používá standardní tlačítka aplikace EGJE k vytvoření, editaci či smazání nastavených slev a jejich parametrů.

Na Adm58 se dále nachází tyto pole:

Formulář – Slouží pro výběr oblasti z jaké se mají kontrolovat daňové slevy (např.: Dan/Das01)

Vyber slevu – toto pole slouží k výběru sledované daňové slevy a jde nastavit sledování těchto slev

· 1 – Student

· 2 – Dítě

· 3 – Dítě ZTP/P

· 4 – Invalidita 1. nebo 2. stupně

· 5 – Invalidita 3. stupně

· 6 – Držitel průkazu ZTP/P

Zadej název – pole slouží k možnosti uživatelského pojmenování dané slevy

Akce workflow – v tomto poli se zadává workflow, které bude odesílat dané nadefinované notifikace na email (např.: pro Dan/Das01 je to WFL67).

Konečný status – toto pole je spjato s daným WFL a definuje se v něm tělo odesílané notifikace. Definice probíhá na Adm33 pro danou akci workflow. Zde se nabízí již nadefinované konečné statusy WFL.

Zadej jednotku času a hodnota – v těchto polích se definuje jednotka času a ve spojení s hodnotou (následné pole) toto definuje, jaký časový úsek dopředu se má zasílat notifikace

Na výběr je:

· Minuta

· Hodina

· Den

Do následného pole Hodnota se zadá číselný údaj

3.32 Adm60 – Parametrizace podání

Jednotlivé procesy e-Podání jsou definovány sledem kroků a setem parametrů, které specifikují náležitosti daného procesu. Co je předmětem podání (formát, obsah a struktura dat, která jsou zasílána/přijímána), jakým komunikačním kanálem výměna dat probíhá (ISDS, API), vůči jakému subjektu komunikace probíhá, jaké jsou požadavky na zabezpečení komunikace, co je požadováno auditovat atd.

Formulář Adm60 „Parametrizace podání“ je určen pro definici nastavení jednotlivých podání, které je pak návazně využíváno jednotlivými metodami EGJE zajišťujícími tuto komunikaci s třetími stranami.

Navigace

Seznam podání

Záložka Detail podání

Obsahuje základní nastavení podání jako celku:

· Externí organizace: adresát podání (seznam podání je pro daného uživatele odfiltrován dle přiřazení organizace k legislativě)

· Pobočka: určení pobočky organizace, která podání řeší

· Agenda podání: širší oblast podání, pod kterou může spadat více jednotlivých podání (formulářů)

· Druh podání: konkrétní předmět podání (formulář podání)

· Komunikační kanál: API, DS

· Externí kód podání: kód, pod kterým je podání (formulář) evidován na straně organizace, které je podání směřováno

· Název a Popis podání

Záložka Kroky

Samotné podání může probíhat v několika krocích, např. stažení výzvy na doložení dat a odpověď na výzvu (odeslání požadovaných dat). Na záložce Kroky je pro každý krok nastaveno, přes jaké rozhraní probíhá komunikace (vazba na definici API na Adm55), jakým způsobem je definováno podací místo a další kategorizační náležitosti kroku (typ kroku, pořadí, název, popis)

Parametry podání, Parametry kroku

Na úrovni podání i jeho kroků mohou být nastaveny další specifické požadavky na parametrizaci procesu v rámci podání jako takového, nebo jeho konkrétního kroku. Např. požadavky na zabezpečení dat (šifrování, podpis) a související požadavky na certifikát, který má být k tomuto použit, požadavky na auditování atd.

Tato parametrizace e-podání je úzce navázána na metody a sestavy EGJE implementované pro jednotlivá podání, proto nastavení parametrizace e-Podání na Adm60 je metodicky plně ve správě Elanor a.s. a případné změny nastavení by měly být vždy realizovány jen na základě implementačního pokynu.

Následuje doporučené nastavení pro agendu ePn SK (opis parametrů které jsou plněné inicializačním skriptem dodaným ve verzi 202405.

Poznámka: Agenda je propojena s nastavením 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 - Auditovat nešifrovaně
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 data	Dotaz na data
Pořadí kroku	1	1
Název kroku	Seznam PN k datumu (GET ePn )	Dotaz na data (GET ePn ID)

3.33 Adm61 - Dávky tiskových sestav

Častým případem hlavně v mzdové praxi bývá periodický tisk více sestav.

Dávku tiskových sestav lze v tomto konfiguračním formuláři vytvořit, pojmenovat a zařadit do menu.

V menu pak může i jiný uživatel (jsou-li mu přidělena práva) spouštět takto připravenou dávku, přičemž parametry všech sestav zadává najednou.

Podle položky "Seskupovat parametry sestav" jsou sestavy prezentovány:

Ano - sdruženě, tzn. parametr se shodným interním názvem v dávce uživatel vyplňuje pouze jednou a je platný pro víc sestav

Ne - každá sestava v dávce má svůj odstavec a v něm všechny svoje parametry. Tato volba se hodí např. v případě, že chceme do dávky dát jednu sestavu vícekrát a pokaždé ji spouštět s jinými parametry (typicky za jinou strukturu).

Pozn. Více obvyklé je neseskupování parametrů.

Speciálním případem jsou Typ dávky sestav

2 - Serverová dávka ADP s možností serverových úložišť

3 - Serverová dávka ELANOR s možností serverových úložišť

Tyto dávky mají při spouštění navíc speciální hlavičku se společným zadáním organizace, období od a do a SJ.

Dávky se zpracovávají na serveru a soubory v nich mají speciální pojmenování. Výsledkem dávky je zip soubor také s pojmenovávacími pravidly a ten bývá umísťován do úložiště "Jiné". To má AS mapované pomocí údaje Ftp02 - Jiná složka pro výměnu souborů (mimo Ftp01) - přístup z AS.

K rozlišení zákazníků outsourcingu na režim EZM standard, ADP a NGA se používá údaj:

Adm21 / EZM / Typ zákazníka EZM:

0-EZM standard

1-ADP

2-NGA

U outsourcingového režimu ADP, NGA EGJE uplatňuje jiná pravidla pojmenování vytvořeného souboru sestavy i když mzdová účetní sestavu tiskne mimo dávku Elanor. Ale jelikož při tomto spouštění nejsou k dispozici hodnoty parametrů z hlavičky dávky, je jejich vyplnění možné pouze v případě, že jsou v tyto parametry obsaženy přímo v sestavě a jsou standardně pojmenovány.

Pro serverovou dávku NGA (dle obrázku: typ 4 a objekt 4) přibylo pole s názvem „Zip v zipu s názvem dle pořadí sestavy“. Do tohoto pole jde zadat číslo sestavy a názvosloví se bude řešit dle pořadí sestavy v dávce (na záložce Adm61 à Sestavy). Toto pole taky zajišťuje, že bude vytvořen zipovaný soubor, který bude v sobě obsahovat další zip s výstupem/výstupy sestav.

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

Popis byl vytvořen automaticky

Pro 0-EZM standard ještě v Adm02/Profil/Práva k řádkům - další objekty existuje položka

"Alt. kód organizace pro soubory 0-EZM standard"

Pokud jej správce vyplní, je tento kód používán u uživatele přihlášeného na tento profil místo kódu organizace z Adm21 / Údaje / Kód organizace. Týká se to názvové konvence pojmenování balíku i jednotlivých sestav v dávkách typu 0-EZM standard.

Hlavním účelem je možnost specifikovat v rámci organizace další dělení příjemců dávek, ať už je to přes SJ nebo přes nějaké rozdělení pomocí struktur.

3.33.1 Serverové dávky

Toto je rozšíření pro uživatele interní výměny souborů Ftp01 (viz následující kapitola). Je provozovatelné při práci přes AS nebo EGJEWeb.

U definice dávky sestav sestavované v Adm61 můžeme vyplnit tyto položky:

Typ dávky sestav:

1 - Serverová dávka s možností serverových úložišť

2 - Serverová dávka ADP s možností serverových úložišť

3 - Serverová dávka ELANOR s možností serverových úložišť

4 - Serverová dávka NGA s možností serverových úložišť

Uživatel smí přepsat serverové cesty (pouze pro typ 2)

Pokud u dávky sestav zadáme, že je Serverová, bude jednak vykonávána na AS a dále se pak její produkty uloží na serverové úložiště definované ve Ftp02.

Přesnou specifikaci uložení pak zadáváme jednak při zadávání sestavy do dávky, zde v Adm61, respektive, pokud je u dávky zatrženo i "Uživatel smí přepsat serverové cesty", tak může tyto údaje uživatel měnit i při spouštění dávky. Vždy se však může rozhodnout, jestli dávku pouští cvičně nebo jestli opravdu již se má na server uložit (včetně případných notifikací ve Ftp02 definovaným příjemcům).

Pro milovníky složitých projektů a protokolů je ve Ftp02 ještě další atribut "Jiná složka pro výměnu souborů (mimo Ftp01) - přístup z AS" a u definice sestavy v dávce je checkbox
"Uložit do Jiné serverové složky", který vytvořený soubor (resp. protokol exportu/importu) ještě navíc uloží do dalšího adresáře a zde se dá i definovat, že pod jiným názvem (parametr " Název souboru (bez cesty) pro Jinou složku").

3.33.2 Serverová dávka ADP, ELANOR, NGA s možností serverových úložišť

Tyto typy dávek používají tzv. "jiné úložiště" definované ve Ftp02 a sestavy pojmenovává podle speciálních algoritmů ADP/ELANOR/NGA.

Do úložiště je umístí jako ZIP soubor(y).

Přičemž ZIP s výplatními lístky je vždy samostatný.

Podporu pro zip s VL mají VL sestavy Vyp11fq a Vyp31fq. Při zařazení do dávky nabízejí speciální formát 10 - "Výstup do PDF zip".

Dávka je obecná a může obsahovat i exporty. Ty ovšem často generují více typů souborů naráz, z nichž ne všechny mají jít do výstupu. K jejich specifikaci slouží položka " Maska souborů ukládaných na server (maska s * ?) - jiná sl.:", která z vytvořených souborů filtruje jen ty, které do dávky patří.

To se týká dávek VL i dávek ostatních sestav a exportů.

Poznámka:

U všech typů serverových dávek si uživatel volí Výstupní formát sestavy. Zatímco u interaktivního spouštění sestavy je formát XLS/XLSX/CSV určen dle lokálního nastavení uživatele, tak u serverových dávek je výhodnější zadat konkrétní formát přímo v zadání dávky, tzn. jeden z typů:

5 - Výstup do XLSX (pouze data)

9 - Výstup do CSV (pouze data)

11 - Výstup do XLS (pouze data)

U volby 4 - Výstup do XLS/XLSX/CSV (pouze data)je formát určen z nastavení klienta, který dávku spouští. Tuto volbu tudíž nedoporučujeme.

Doporučení: Kódy dávek v Adm61 dělejte krátké, jinak se u dávek ELANOR nevejdou do maximální délky názvu souboru ZIP a budou různě zkracovány. Nepoužívejte v nich také diakritiku a některé problémy odpadnou, když v nich nebudou ani mezery.

3.34 Adm62 – Správa žádání o dokument

Na formuláři Adm62 správce nastavuje seznam dokumentů (sestav), o které lze žádat (formulář Osb62) a které lze referentem či mzdovou účetní (dále jen MU) pomocí tohoto nového aparátu vystavovat (formulář Vyk62).

Jedná se o:

• žádost o sestavu, která jako jeden z parametrů má Osobu nebo Osobu / PV (žádost zaměstnance),

• nebo o vystavení dokumentu bez žádosti, kde je vyplněno „Jiný dokument od organizace bez žádání (např. hromadný ELDP) = Ano“ (MU generuje soubor bez žádosti).

• možnost vystavit sestavy, které se tisknou přímo z formulářů (v současnosti Dan/Das36)

Jedná se o součást samostatného okruhu, více informací v dokumentaci Zam_dok_uzdoc.

3.35 Adm63 – Validace vstupních polí

Tento formulář slouží pro kontrolu nastavených regulárních výrazů, nastavených pro kontrolu vstupních polí. Funkcionalita běží v pilotním provozu a bude ještě nadále optimalizována. Tato kontrola bude fungovat i pro AreaTextEditor, což je víceřádkový editor. Regulární výrazy se načítají při spuštění Aplikace / Aplikačního Serveru / WEB Serveru a uloží se do paměti (nakešují se). Přenačíst jsou buď restartováním alikace nebo na formuláři Adm51 à záložka Změna DB à tlačítko „Přenačíst“ u pole s názvem Přenačíst repository na všech AS / EGJEWEB(2):

Na Pkz11fkb nejsou standartní daformy, ale změny se provádějí pomocí param. panelu v dialogu a tudíž tam chybí přímá vazba na položku v tabulce, kde je uložena nápověda, proto je přidána další kontrola v systému, takže se špatně zadaná položka kontrolovaná regulárním výrazem neuloží, ale vyskočí chybová hláška:

V různých částech aplikace toto může mít mírně jinou podobu, ale důležité je, že se chybná hodnota neuloží do DB. U standardních. formulářů se tato hláška nevyskytuje a nepovolené znaky se nedají ani zadat.

Je zde mírný rozdíl v chování na Tlustém a WEB klientovi.
Tlustý klient:
- v případě že hodnota položky nesplňuje regulární výraz (např. u již dříve uloženého textu), tak se nenačte a zobrazí se prázdné pole. Pokud uživatel spustí editaci a pak se pokusí uložit, uloží se opět jen prázdná hodnota a původní text je ztracen.
Web klient:
- na WEB klientovi se hodnota normálně zobrazí, ale při úpravě už nepůjde uložit
Je třeba myslet i na to, že ve zprávách pro workflow se pro makra používá znak %, takže ho musí regulární výraz povolovat a zároveň pokud zpráva obsahuje HTML znaky, např. <>\=, musí být povoleny i tyto znaky.

Obsahuje navigační seznam, zobrazující tabulky databáze. Po výběru tabulky, se do seznamu na formuláři načtou detaily o všech položkách, do kterých se zadávají data a je možno nastavit regulární výraz pro kontrolu vstupní hodnoty pro vybranou položku. Toto odpovídá 1. fázi vývoje.
Protože je ale zadávání regulárních výrazu velmi složité, navazuje na tento formulář 2. fáze vývoje, která umožní vybírat z nadefinovaných podmínek a nebude tak nutné, přímo generovat regulární výraz kvůli jeho složitosti.

3.35.1 Tlačítko „Přenačíst repository“

Toto tlačítko zajistí, při zadání nového regulárního výrazu, pře načtení tohoto výrazu do cache (repository). Tyto regulární výrazy a kontroly jsou při spuštění aplikace EGJE před-načteny do cache, což způsobovalo, že po zadání nové kontroly bylo nutné aplikaci ukončit a znova spustit, aby se nový regulární výraz stal aktivním a načetl se cache aplikace. Nyní po zadání nového výrazu nebo jeho změně stačí repository pře načíst tlačítkem. Daný formulář, pro který je regulární výraz určen se musí zavřít (pokud je otevřen) a spustit znova. Ale není nutné aplikaci ukončovat.

3.35.2 Kontextové volání

Přibylo kontextové volání na regulární výraz definovaný na Adm64. Pokud je zvolený regulární výraz na Adm63 definován na formuláři Adm64, jde z pomocí kontextového menu zavolat a přejít na formulář Adm64, kde je definován

Obsah obrázku text, snímek obrazovky, software, Počítačová ikona

Popis byl vytvořen automaticky

3.36 Adm64 – Regulární výrazy pro validaci vstupních polí

Formulář Adm64 slouží stejně jako Adm63 pro zadávání regulárních výrazů pro validaci vstupních polí.

Rozdílem v těchto formulářích je, že Adm64 umožnuje zadat sadu regulárních výrazů, které se následně dají vybrat z rolldown menu na Adm63. Kdežto Adm63 umožňuje zadat jen konkrétní regulární výraz pro jedno vstupní pole.

Formulář Adm64 slouží k managementu regulárních výrazů.

Z formuláře Adm64 funguje kontextové volání na formulář Adm63, které jsou funkčně propojeny.

Zde je základní přehled regulárních výrazů a jejich základní definice:

3.36.1 Co je regulární výraz?

Regulární výraz (anglicky regular expression, často zkracováno na regex) je speciální způsob zápisu textových vzorů, který slouží k vyhledávání, porovnávání nebo úpravám textu. V podstatě si ho můžeme představit jako "chytřejší" hledání textu s využitím určitých pravidel a zástupných znaků.

3.36.2 Zástupné znaky (metaznaky)

Regulární výrazy používají různé symboly, které mají speciální význam. Některé základní:

"." (tečka) – představuje jakýkoliv znak.
"*" (hvězdička) – znamená "nula nebo více výskytů předchozího znaku".
"?" – znamená "nula nebo jeden výskyt předchozího znaku".
"[]" – skupina znaků, které chceme povolit.
"^" – značí začátek řádku nebo textu.
"$" – značí konec řádku nebo textu.

Příklad s metaznaky:

Pokud chcete najít všechna slova, která začínají na "k" a mají jakýkoliv jeden další znak, např. "ka", "ko", "ki" apod., použili byste regulární výraz: "k.". Tečka zde nahrazuje jakýkoliv znak.

3.36.3 Základní regulární příkazy

· [a-z] – definuje pouze malá písmena abecedy (příklad: abeceda)

· [a-zA-Z] – definuje malá a velká písmena abecedy (příklad: AbeCeda)

· [0-9] – definuje pouze čísla od 0 do 9 (příklad: 123458)

· [a-z0-9] – definuje malá písmena abecedy a čísla od 0 do 9 (příklad: abeceda123)

· [a-zA-Z0-9] – definuje malá a velká písmena abecedy a čísla od 0 do 9 (příklad: Heslo123)

Tyto regulární výrazy mohou být různě kombinovány. Ale každá kombinace bude obsahovat složitější regulární výraz.

Jak příklad je uveden regulární výraz pro definici hesla, který obsahuje podmínky. Heslo musí obsahovat:

· malá a velká písmena

· číslo

· speciální znak z sady (!@#$%^&*)

· minimální délka je 8 znaků

Takový regulární výraz můžeme sestavit takto:

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*])[A-Za-z\d!@#$%^&*]{8,}$

Vysvětlivky:

· ^ – začátek řetězce

· (?=.*[a-z]) – zajišťuje, že heslo obsahuje alespoň jedno malé písmeno

· (?=.*[A-Z]) – zajišťuje, že heslo obsahuje alespoň jedno velké písmeno

· (?=.*\d) – zajišťuje, že heslo obsahuje alespoň jednu číslici (zástupný znak pro číslo je \d).

· (?=.*[!@#$%^&*]) – zajišťuje, že heslo obsahuje alespoň jeden speciální znak z definované sady !@#$%^&*.

· [A-Za-z\d!@#$%^&*]{8,} – povoluje pouze znaky malé a velké abecedy, číslice a speciální znaky, a zároveň zajišťuje, že heslo má alespoň 8 znaků.

· $ – konec řetězce.

3.36.4 Shrnutí:

Regulární výraz je mocný nástroj, který dokáže vyhledávat a manipulovat s textem pomocí speciálních vzorů. Místo obyčejného hledání slova vám umožňuje definovat pravidla, jaké textové vzory chcete najít nebo definovat vzor, jak má text v daném poli vypadat, definovat písmena, čísla či znaky, které mohou byt vloženy.

3.36.5 Upozornění

Regulární výrazy jsou opravdu mocný nástroj, ale při špatném zadaní nebo jejich špatné znalosti je možné tímto nástrojem znemožnit zadání validní hodnoty do potřebného pole. Doporučením je konzultovat s systémovým administrátorem před vložením či umístěním regulárního výrazu jako definice na formuláři Adm64 a jeho napojením do systému na formuláři Adm63.

3.37 Adm70 – Konfigurace

Formulář umožňující nastavování konfiguračních položek v rámci celého EGJE s vazbou buď na aplikaci nebo příslušnou organizaci, správní jednotku či správní oddíl (řízeno číselníkem konfig_typ). Položky jsou definovány číselníkem konfig_nazev a jsou sdružovány do skupin dle hodnoty kód 2 – viz tabulka níže.

Stejným způsobem jsou definovány i typy konfiguračních položek (v tomto případě se jedná o číselník konfig_detail_typ), tj. ke každé položce číselníku konfig_nazev je přiřazen typ, který určuje, jakým způsobem bude položka definována a tato hodnota nelze změnit.

Formulář umožňuje filtrovat položky v navigačním seznamu dle typu (viz jednotlivé podkapitoly).

Funkčnost každé jedné položky je popsána v jednotlivých podkapitolách. Systém neobsahuje žádné předvyplněné konfigurační položky, je čistě na uživatelích, zda je založí, a dle jejich definice pak budou používat pro příslušné oblasti.

Konfigurace využívají číselníky:

Číselník konfig_typ:

- 1 – Aplikační

- 2 – Organizační

- 3 – SJ

- 4 – SO

- 5 – Organizační + SJ

Číselník konfig_detail_typ:

- 10 – celé číslo

- 20 – Text

- 30 – Dny

- 40 – Logická hodnota Ano/Ne

- 50 – Hodiny

- 60 – Číselníková položka

- 70 – Soubor (json)

A dále konfig_nazev_kod2 a konfig_detail_kombinace_typ.

3.37.1 Hesla

Každá položka této skupiny je ještě definována s vazbou na instance tabulky cespol a to takové, které mají definovánu hodnotu is_pass = 1. Prozatím se jedná pouze o tabulku cehtoso (položka /cehtoso.dalsi_xml/@indpw) a cesautenti (položka apikey_password). Tzn. že například definici hesla na formulářích Xpw02/03 lze ovlivnit pomocí konfiguračních položek 100 – 105. Stejně tak lze ovlivnit definici hesel na formuláři Adm57. Pokud konfigurační položky nebudou zadány, definice hesel na výše uvedených formulářích nebude podléhat žádné kontrole a uživatel může heslo zadat libovolně.

Číselník konfig_nazev

Kód	Název	Kód 2	Cel. č. – konfig_detail_typ	Des.h. – konfig_typ
100	Délka hesla	Heslo	10	1	Minimální délka hesla, v případě automatického vygenerování hesla se jedná o počet znaků takto vygenerovaného hesla
101	Heslo obsahuje číslice	Heslo	40	1	Pokud je definována jako hodnota Ano, pak v rámci hesla musí existovat alespoň 1 znak číslice. Pokud je definována Ne nebo není definována vůbec, číslice v rámci hesla není nekontrolována
102	Heslo obsahuje speciální znaky	Heslo	40	1	Pokud je definována jako hodnota Ano, pak v rámci hesla musí existovat minimálně jeden speciální znak. Pokud je definována Ne nebo není definována vůbec, spec. znak v rámci hesla se nekontroluje
103	Heslo obsahuje velká písmena	Heslo	40	1	Pokud je definována jako hodnota Ano, pak v rámci hesla musí existovat minimálně jedno velké písmeno. Pokud je definována Ne nebo není definována vůbec, velké písmeno v rámci hesla se nekontroluje
104	Heslo obsahuje malá písmena	Heslo	40	1	Pokud je definována jako hodnota Ano, pak v rámci hesla musí existovat alespoň jedno malé písmeno. Pokud je definována Ne nebo není definována vůbec, malá písmena se v rámci hesla nekontrolují
105	Délka platnosti hesla (ve dnech)	Heslo	30	1	Počet dní platnosti zadaného/vygenerovaného hesla. Pokud položka není vůbec definována, kontrola se neprovádí. Pro úplnou funkčnost této konfigurace je třeba ještě definovat WFL na Adm33 – akce 70 a job 70 na Adm53

3.37.2 ESP (Pouze interní konfigurace)

Detailní popis viz dokumentace EGJE_distribuceHeselASPklientum

Kód	Název	Kód 2	Cel. č. – konfig_detail_typ	Des.h. – konfig_typ
200	URL do ESP	ESP	20	1	URL aplikace ESP s entrypoint pro registraci /register
201	Platnost tokenu	ESP	50	1	Platnost tokenu v hodinách v rámci registračního e-mailu do ESP pro externí uživatele
202	Typ kontaktu pro registrační e-mail	ESP	60	2	Typ kontaktu pro registrační e-mail. Konfigurace je definována pro každou organizaci zvlášť. Pokud není vyplněno, použije se typ kontaktu 31
203	Rest API Request do ESP	ESP	20	1	REST POST API pro registraci záznamu v ESP Skládá se ze základní URL ESP bez entrypoint /main + samotné API, které je /api/v1/egje/registerExternalUser
204	Přihlašovací dialog s URL do ESP	ESP	40	1	Zobrazení odkazu na Změnu hesla nebo Zapomenuté heslo na přihlašovací dialog EGJE. Pokud je nastaveno na hodnotu 1 (a dále je nastavena i konfigurační položka 205 – viz řádek níže) – dojde k zobrazení na přihlašovacím dialogu webového rozhraní. Pokud je nastaveno na hodnotu 0 nebo položka vůbec neexistuje nebo neexistuje v kombinaci s položkou 205 – na přihlašovacím dialogu není žádný odkaz.
205	URL do ESP pro změnu hesla	ESP	20	1	URL, která bude sloužit pro přesměrování do ESP při změně hesla externího uživatele. Tato konfigurační položka bude vyhodnocována 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 přes Adm42	Dlazdice	40	1	Povolení práce s dlaždicemi přes formulář Adm42
251	Dlaždice – json soubor	Dlazdice	70	1	Uložení json souboru pro novou práci s dlaždicemi

Blíže viz dokumentace EGJE_web_uzdoc.

3.37.4 DokForm

Kód	Název	Kód 2	Cel. č. – konfig_detail_typ	Des.h. – konfig_typ
300	Dokumenty na Dan31	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Dan31
301	Dokumenty na Dan32	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Dan31
302	Dokumenty na Dan33	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Dan33
303	Dokumenty na Dan34	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Dan34
304	Dokumenty na Das31	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Das31
305	Dokumenty na Das32	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Das32
306	Dokumenty na Das33	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Das33
307	Dokumenty na Das34	DokForm	40	5	Pokud je definována jako hodnota Ano, pak daný dokument bude nabízen k výběru na Das34

3.38 Adm71 – Konfigurace konstant – pohled od kombinace

Smyslem existence tohoto formuláře (stejně jako formuláře Adm70) je, aby si administrátor zákazníka mohl nastavit hodnoty konstant, které se vyskytují v kódu EGJE. Při změně tohoto nastavení se pak nemusí čekat na další výdej EGJE, ale změna proběhne okamžitě na úrovni databáze.

Rozdílem formulářů Adm70 a Adm71 je způsob, jakým zobrazují data z podkladových databázových tabulek (tyto podkladové tabulky jsou pro oba formuláře stejné:

· Adm70 pro vybranou konstantu (tj. konfiguraci) ukazuje hodnoty, kterých tato konstanta nabývá pro definované kombinace vstupních parametrů

· Adm71 pro vybranou kombinaci vstupních parametrů ukazuje hodnoty všech konstant (dané tematické oblasti EGJE), které jsou pro tuto kombinaci nastavené

3.39 Adm76 – kontrola platnosti bezpečnostních klíčů a certifikátů

Pro účely kontroly platnosti bezpečnostních klíčů a certifikátů se může použít sestava Adm76, kterou zle spustit buď přímo nebo se může nadefinovat na Adm53 a bude následně spouštěna denně automaticky. Na této sestavě jde nastavit datum a předstih. Sestava pak v daném termínu před koncem platnosti klíče/certifikátu pošle emailové upozornění na danou osobu/y.

· Datum – konec platnosti klíče/certifikátu

· Předstih – kolik dnů před koncem platnosti má být zaslano upozornění

· Předmět emailu – je možno nadefinovat předmět (např.: Končí platnost klíče!!!)

· Výčet příjemců (email) – zde se dá zadat více emailových příjemců oddělených čárkami

3.40 Adm77 – Kontrola platnosti delegovaných profilů

Tato sestava umožnuje zjistit a vypíše upozornění ( do souboru) na všechny profily, které byly delegovány na zástupce, ale uživateli, který tento profil delegoval již byl profil ukončen.

Výstup do souboru je možné na stavit na formát PDF nebo XLSX pomocí radiobuttonu.

Sestava pouze tyto profily vypisuje, následně je nutná manuální ukončení delegování uživatelem.

3.41 Agenda výměny souborů a dokumentů

Výměna dokumentů pomocí serverového adresáře.

Realizováno pro klienta AS resp. pro EGJEWeb.

Řešení obsahuje:

Konfigurační formulář Ftp02.

Uživatelský formulář Ftp01.

3.41.1 Ftp02 - Výměna souborů a dokumentů - konfigurace

Záložka Konfigurace - zaevidování cest pro přístup z AS a EGJEWEB do adresáře pro uložení souborů, indikace jejich přístupnosti.

Záložka Složky - popis položek v souborovém systému. Umožní nastavení práv uživatelů k nim na jednotlivé akce - ty umožní:

§ vkládat soubor

§ číst soubor

§ obdržet oznámení o novém souboru

§ mazat uložený soubor

Adresář i Složky se v souborovém systému zakládají mimo EGJE, zde se pouze zaevidují

3.41.2 Ftp01 - Výměna souborů a dokumentů

Tlačítko Nahrát umožní vybrat a vložit nový soubor. Ten je pak uložen na serverový adresář.

Viz popis v následující kapitole.

Soubor popisující položka Kategorie je definována uživatelským JPČ "kateg_ftp".

Formulář zobrazuje v navigačním seznamu všechny soubory z uživateli přístupných složek. K dispozici je standardní funkčnost hledání, výběru a třídění.

Jelikož jsou doprovodné informace ukládány do metasouboru, tak zůstanou v aplikaci přístupné i po smazání vlastního evidovaného souboru.

3.41.3 Stručný popis konfigurace a použití Ftp01, Ftp02

· správce serverů vytvoří adresář dostupný z AS i EGJEWEB serverů, uživatelé, pod kterými servery běží, zde mají právo pro čtení i zápis

· zde vytvoří ještě podadresáře do_ela a z_ela (práva dtto)

· správce aplikace otevře Ftp02 a zaeviduje

o na záložce Konfigurace hlavní složku pro přístup z web serveru a to samé pro přístup z AS

o na záložce Složky pak složky (typicky do_ela a z_ela) a přiřadí zde uživatele EGJE, kteří smí do složky soubory:

§ vkládat

§ číst

§ dostanou oznámení o novém souboru

§ mazat uložený soubor

o objektové právo FtpAdmin

§ uživatel mající toto právo nemusí být evidován pro jednotlivé činnosti se soubory, ale má nad všemi složkami práva na všechny akce, které EGJE nabízí

· uživatel, který chce vložit soubor, otevře Ftp01 a

o tlačítkem "Nahrát" nový soubor vybere a vloží do systémového adresáře a jeho vybrané, uživateli přístupné, Složky.
Při pokusu o uložení souboru s názvem, který již v serverové složce je, nabídneme uživateli nový název, pod kterým může soubor uložit. Nový název je vytvořen z původního názvu přidáním časové značky (př. Potvrzeni_201302185016.doc)

o uživatelé, kteří pro takovou složku mají nastaveno, že mají dostávat oznámení o vložení nového souboru, obdrží oznámení e-mailem na adresu z Osb02 (druh komunikace 31 - E-mail v zaměstnání)

o uživatelé, kteří dostávají oznámení, mají také možnost soubor zpracovat (Ftp01 tlačítko Zpracovat). Soubor je zaevidován jako zpracovaný, pokud jej zpracuje jeden z těchto uživatelů.

· uživatel, který má přístup ke čtení ze složky, po otevření Ftp01 soubory uvidí tento nový i starší soubory v navigačním seznamu tohoto formuláře.

· Ftp02, Ftp01 - kontrolní mechanismy

1. Adresář pro výměnu dokumentů (zadávaný ve Ftp02) musí mít pro zákazníky Elanor Outsourcing (zákazníci s kódem začínajícím q), v kořeni adresáře soubor ftp.ftp, ve kterém bude právě a pouze zákaznický kód. Ten je nově zobrazen i na poslední záložce Adm51.
Tuto kontrolu mohou ale nemusí využít i SW zákazníci.

2. Také při otevírání Ftp01 je provedena analogická kontrola

3. Kontrola probíhá i při spuštění serveru AS/EGJEWEB s tím, že chyby jsou zaznamenány v logu jako ERROR.

4. Ftp01 - obsahuje kontrolu, zdali ukládaný soubor má méně než 20MB.

3.42 Xpw01 - Správa hesla (LDAP)

Okno umožňuje provést změnu hesla na externím autentizačním serveru.

Okno je funkční a testované pouze pro autentizaci LDAPOnly vůči doménovému serveru Windows. Popis potřebných parametrů je v EGJE_provdoc kap. 5.1.5 - kromě standardních parametrů pro autentizaci se pro změnu hesla používají ještě parametry:

Web - ldap base s maxPwdAge (změna hesla)

LDAP/Web - doba (počet dní) předstihu před vypršením hesla

LDAP/Web - zpráva - heslo nesplňuje pravidla

Do Xpw01 je promítána hláška o bezpečnostní politice definovaná v Configuratoru / Ověření / Doplňující zpráva po zadání požadavku na reset hesla.

Okno je primárně určeno pro novou web aplikaci.

3.43 Xpw02 - Správa hesla pro VL

Formulář umožní koncovému uživateli změnit svoje heslo pro převzetí kryptovaného PDF s výplatním lístkem. Tuto funkčnost v současné době nabízí pouze zákaznický výplatní lístek Vyp11q.

Na druhé záložce je možné jednak "Vybrat PV bez zadaného hesla"

a také je tu možnost provést "Hromadné naplnění hesel pro VL ze souboru oscpv, heslo". Od verze e202409 lze definici i generování hesel ovlivnit konfiguračními položkami – viz Adm70, část Hesla.

Soubor musí být uložen s kódováním ANSI. Struktura souboru je bez hlavičky.

Příklad souboru:

00000681.01,Heslo123

00000675.01,JABADABA234

00000680.01,8stsDDS3

3.44 Xpw03 - Správa hesla pro VL - generování

Formulář umožní koncovému uživateli změnit svoje heslo pro převzetí kryptovaného PDF s výplatním lístkem. Heslo uživatel nezadává, ale generuje. Tuto funkčnost provádí vestavěný generátor hesel.

Algoritmus využívá náhodné číslo a následně generuje heslo obsahující velká a malá písmena, číslice a speciální znaky, délka je 10 znaků.Na záložce Hromadné akce je možné provést výběr osob bez hesla resp. provést hromadné generování hesel. 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 umí využívat i formulář Adm12 při generování přístupu do systému pomocí AD (režim generování hesla a to „4 - Heslo dle hesla pro VL (Xpw03)“), viz. výše uvedený popis tohoto formuláře.

Není povoleno pro heslo používat písmena s diakritikou. Adobe Reader potom neumí takový soubor otevřít).

3.45 Tiskové sestavy

3.45.1 Adm07 - Uživatelé - práva k řádkům

Výpis všech uživatelů a jim zpřístupněných profilů, včetně nastavení řádkových práv na profilu a systémového logname.

Předpokládáme spíše využité tabulkového XLS formátu sestavy.

3.45.2 Adm08 - Profily, přiřazená objektová práva

Velmi rozsáhlá a dlouhá sestava do XLSX, která vypisuje profily a všechna jejich zadaná objektová práva. Je možno ji omezit na profily jednoho uživatele, také zjišťování výčtu všech uživatelů pro objekt v roli je volitelné.

3.45.3 Adm09 - Položky v generátoru dotazů

Výpis tabulek a položek nabízených v generátoru dotazů.

3.45.4 Adm17 - Uživatelé - export pro audit (excel export)

Excel export všech evidovaných přístupových profilů přiřazených uživateli. Slouží pro označení těch přístupů, které mají být zneplatněny (sloupec Ukončit účet (0/1)). Technologické poznámky a postupy pro uživatele.

3.45.5 Adm40 - Profily, objekty, detaily práv k formulářům

Analogická sestava jako Adm08, ale vypisuje všechny detailní objekty přístupových práv, nejenom ty zadané. Vyhodnocení práv k detailním podobjektům formuláře provádí stejný aparát, který formulář a objekty na něm zpřístupňuje. Když je tedy do profilu formulář přiřazen vícekrát, je zde uvedena již ta výsledná hodnota práv na detailní podobjekt.

Také je to velmi rozsáhlý a dlouhý XLSX export, doporučujeme vždy vyplnit alespoň jeden z parametrů sestavy. Tedy buď profil, nebo objekt.

U objektu v profilu jsou jednak všechny role, které profil obsahuje (Role profilu) a pak role, ve kterých je konkrétní objekt s nějakou hodnotou práv uveden (Role s objektem).

3.45.6 Adm78 – API konfigurace

Sestava umožňuje tisk nastavení API definovaných na Adm55 a přehledu certifikátů (Adm27) a podání (Adm60) navázaných na dané API.

Vstupními parametry sestavy jsou API a Jen platné. Pokud je API nezadáno, výstup obsahuje data pro všechna API definovaná na Adm55. Parametr Jen platné se aplikuje s vazbou na platnost záznamů definice API (Adm55: Záložka API: Datum od, Datum do),

Výstup dat je ve formátu xlsx. Soubor obsahuje 5 listů:

· Konfigurace API: základní nastavení API (Adm55: API a Konfigurace API)

· Služby a prostředky API: pohled na služby a prostředky poskytované daným API a přehled ORG a SJ s přístupem k těmto službám API (Adm55: Prostředky a Přiřazení prostředku organizaci a SJ)

· Parametry API: nastavení specifických parametrů na úrovni API, prostředku nebo ORG/SJ (Adm55: záložky Parametry pro jednotlivé úrovně nastavení – API/Prostředek/Přiřazení prostředku ORG a SJ)

· Certifikáty napojené na API: Pokud jsou na dané API navázané certifikáty (Adm27), pak sestava uvádí jejich výčet. Přiřazení certifikátu k API je definováno na Adm27, záložce Certifikační oprávnění, a zde Přiřazení k API

· E-podání využívající služby API: seznam služeb/prostředků API které jsou využívány některým krokem podání definovaným na Adm60 (vazba podání na službu API je u parametrizace podání definována na záložce Kroky podání)

3.45.7 Adm79 – Evidence certifikátů

Sestava umožňuje tisk certifikačních oprávnění a navázaných vydaných certifikátů evidovaných na formuláři Adm27 a jejich přiřazení k API. Sestava je vstupně přístupná pouze admin profilům (role 1) a v případě zpřístupnění sestavy na jiné profily je doporučeno vycházet z nastavení přístupu k Adm27.

Vstupními parametry jsou:

· Datum: pokud je zadáno, pak sestava načte záznamy certifikátů, které byly v daný den platné a zároveň se uvedený datum aplikuje i na záznamy přiřazení certifikátů k API a registrace certifikátu u externích organizací

· Organizace a Správní jednotka: Pokud uživatel nevybere tyto parametry (default = NULL), pak sestava načte všechny záznamy, na které má uživatel práva (řádková práva jsou zde aplikována stejným způsobem jako na formuláři Adm27). Pokud uživatel tyto parametry zadá, pak sestava omezí záznamy, na které má uživatel práva, dle nastavené hodnoty vstupních parametrů sestavy ORG/SJ

· Typ certifikátu

Výstup dat je ve formátu XLSX. Soubor obsahuje 3 listy:

· Certifikáty: výčet certifikačních oprávnění a na ně navázaných vydaných certifikátů

· Přiřazení certifikátů k API: výčet certifikačních oprávnění rozšířen o informaci o jejich přiřazení k API

· Registrace certifikátů u externích organizací: k vydaným certifikátům jsou načteny informace k jejich registracím u orgánů veřejné správy, pokud tato registrace je zaevidována na Adm27, záložka Registrace certifikátů

3.46 Hierarchie členění zpracovávané organizace

Organizace -> Správní jednotka -> Správní oddíl

3.46.1 Organizace

Organizace má právní subjektivitu. Ve své existenci vychází z Obchodního zákoníku a je uváděna v obchodním rejstříku. Pojem organizace tak má blízko k vlastnickým vztahům, neboť organizace má své majitele, kteří sami nebo prostřednictvím určených "rad" organizaci řídí. Dalším používaným pojmem je firma, ale ten se používá spíše v podnikatelské sféře. Organizace vytváří celé pracovní prostředí, vnitřní předpisy v rámci platné legislativy. Na této úrovni bývá zpracována kolektivní smlouva.

Organizace se vnitřně dělí, pokud je to zapotřebí, na dílčí části, a to podle potřeb řízení. Principy členění bývají různé, například geografické, oborové, provozní apod.

3.46.2 Správní jednotka

Jedním z rozdělení organizace, je rozdělení podle jednotek, které vystupují samostatně navenek vůči orgánům státní správy, a to hlavně ve mzdové oblasti. Pro toto rozdělení se v našich předchozích systémech vžil pojem "Správní jednotka", zkráceně SJ. Správní jednotka se přihlašuje například v Sociálním zabezpečení (pojištění), Zdravotním pojištění, pro daňové účely a je pro tyto orgány vykazovací jednotkou. Vykazuje své výsledky vůči statistickým orgánům a provádí odvody pojistného a daní. Současně při vykonávání kontrolní činnosti se tyto orgány obracejí na odborné referenty právě za konkrétní SJ.

V praxi většinou odpovídá rozdělení na SJ rozdělení geografickému (pojem v daňové oblasti "správcova pokladna"). SJ mívají možnost samostatné tvorby kolektivní smlouvy, a to v rámci nadřízené kolektivní smlouvy organizace.

Po pravdě řečeno ale takovéto dělení na SJ nemusí vůbec odpovídat struktuře kolektivních smluv. Ty mohou být sepsány například oborově. Ale protože se kolektivní smlouvy zaobírají i běžnými provozními problémy a podmínkami, ve většině případů odpovídají organizačnímu rozčlenění organizace na nejvyšší úrovni. I když SJ nakonec nemusí být 1. úrovní organizačního členění, velmi často tomu tak je.

3.46.3 Správní oddíl

Správní oddíl (SO) vyjadřuje rozdělení správní jednotky na části (oddíly), které vyhovují požadavkům na postupné uzavírání mezd v předem stanovených termínech. Například jako první oddíl mohou být zpracování TH pracovníci, jejichž vstupy pro zúčtování jsou jednodušší a jako druhý oddíl pak ostatní, jejichž mzdové podklady vycházející z provozu a provozních výsledků jsou složitější.

Pojem správního oddílu tak vyjadřuje vnitřní interní členění podle vnitřních potřeb. Nesmí se projevit ve funkčnosti správní jednotky.

Důvodem k zavedení SO je fakt, že se v praxi objevuje to, že se část mezd zpracovává v jednom termínu a jiná část v druhém. Zpracováním se tím nemyslí pouze výpočet mzdy, ale komplexní zpracování až do zasílání výplaty zaměstnancům a případně i převod do účetnictví. Požadavek zpracování ve více oddělených dávkách vzniká často pro firmy se zahraniční účastí, kde se striktně vyžadují (a to poměrně brzo po ukončení měsíce) výsledky z oblasti mezd. Dalším důvodem existence uvedené linie může být rozdělení zpracování SJ na dílčí celky, např. po bývalých SJ po sloučení. Nemělo by jich však mnoho. Důvodem může být

- větší výkonnost systému (akce mohou probíhat paralelně)

- určitá konfigurovatelnost na úrovni nižší než SJ

Z hlediska dalšího použití by SO měl mít číselnou identifikaci, která vyjadřuje pořadí zpracování SO v rámci SJ

3.46.4 Zásady při práci se SO a SJ

Pravidla

- každé počítané PV je povinně přiřazeno k SO

- problém je u zaměstnanců s více PV. Zde musí být zaměstnanec jakožto osoba zařazen do SO podle PV, které je zařazeno do posledního SO. Pozor, vůbec to nemusí být kmenový PV.

- stejný princip rozdělení na SO se použije na všechny typy VT, tj. jak pro dobírku, tak pro zálohy

Zásady pro výpočet mezd

- pro osobu s více PV se musí vyhodnotit parametry pro každé PV podle jeho přiřazení na SO

- pro osobu se program snaží spočítat vždy všechna PV, která jsou ve stejném pořadí (v rámci celé DB); pokud už nezbývá žádné další PV ke spočítání v dalších pořadích, spočtou se až do srážkové bilance. Pokud je mezi počítanými PV kmenové PV, pak se srážková bilance směřuje na něj. Obecně ale nemusí to být kmenové PV, které dopočte srážkovou bilanci a tím celou osobu a jsou na něj směřovány srážky. Pak také uživatelé musejí příslušně nastavit střediska (například výplatní místo).

- počítat vždy pouze PV ze stejného pořadí (bez ohledu na přiřazení k různým referentům); PV z předchozích termínů se nepřepočítávají, pouze načítají z DB.

- nepovolit výpočet PV v termínu "n", pokud PV z termínů <"n" ještě nejsou vypočtena

- každé PV účetně dorovnávat; tj.

- pro neposlední počítané PV (nedělá srážkovou bilanci) sečíst příjmové SLM a vygenerovat SLM_A "odečíst převod příjmů (k zúčtování a odvodům)"

- pro poslední počítané PV (dělá srážkovou bilanci) vygenerovat SLM opačné k SLM_A jako SLM_B "přičíst převod příjmů (k zúčtování a odvodům)"

Zásady pro uzávěrku mezd (PU)

- uzávěrka mezd se zpracovává za SO

- při startu PU za SO se zjistí, zda je to poslední SO za SJ; pokud ano, provede se s tímto SO i dopočet zaokrouhlovací chyby pojistného na SZ v ČR a to z dat celé SJ a zaokrouhlovací rozdíl se promítne v rámci SO

Tento princip se použije i v případech opakování PU za SO, ačkoliv na ní při prvním zpracování PU nebylo zaokrouhlování počítáno

- v ČR se pojištění na SZ počítá ze sumy vyměřovacích základů všech zaměstnanců SJ. Proto musí být zabezpečeno, aby odvody za SJ byly ve správné výši, a to včetně vyrovnání zaokrouhlovací chyby. Proto nechť existuje i součást mzdové uzávěrky = PU SZ, které vyrovnají onu korunu či dvě (zřejmě u některého PV z posledního oddílu)

- mělo by být nastavitelné, zda pojistné a daně odesílat s každým SO nebo až při uzavření celé SJ

- mzdovou uzávěrku lze spouštět za více SO. V takovém případě

- nejprve se provede výpočet PU SO

- a pokud jsou již zpracovány všechny SO z SJ, nakonec se provede PU SZ

- celá SJ je uzavřena, pokud jsou uzavřeny všechny podřízené SO

Exporty:

- exporty navenek do okolí organizace musejí být datově za organizaci či SJ, ale provádět je lze po částech za SO, a to podle termínů zpracování uzávěrky za SO

- export do účetnictví by měl být prováděn po SO, případně hromadně za více SO.

Sestavy:

- obsah pojmu správní oddíl se musí zvážit u každé sestavy. Sestavy tak bude možno tisknout

- za SO

- za SJ

- za organizaci

(a navíc vždy podle přístupových práv)

- podle příslušnosti sestavy a datového objektu je zapotřebí měnit i hlavičku sestavy (za SO, za SJ, za organizaci)

3.47 Parametry

Zde uvádíme parametry pro jednotlivé úrovně. Pokud je určitý parametr povolen evidenci na více úrovních, má přednost ta hodnota, které je uvedena na nejhlubší úrovni. Tj. přednost má hodnota pro SO, pak SJ a pak za organizaci.

3.47.1 Konfigurační parametry sledované na úrovni organizace

· Placení pojistného na GP (pouze SK)

· Režim evidenčního stavu

0 – podle trvání PV a úvazků

1 – Odpracované hodiny / Fond pracovní doby

2 – Odpracované hodiny / Hodiny přítomnosti + nepřítomnosti

3 – Hodiny přítomnosti + nepřítomnosti / Fond pracovní doby

4 – Odprac. a neodprac. hodiny bez přesčasu a nadúvazku / Stanovený fond prac. doby

5 – Kombinovaný způsob č.1

· Zaokrouhlení hotovostní dobírky …. způsob zaokrouhlování dobírky v hotovosti.

Vyplňuje se podle číselníku řešitele s hodnotami:

0 Nezaokrouhlovat

1 Na základnu nahoru

2 Od poloviny nahoru

3 Od poloviny dolů

4 Na základnu dolu

přičemž základ je dán následujícím parametrem

· Základ pro zaokrouhlení hotovostní dobírky .. číselná hodnota, na kterou se hotovostní dobírka zaokrouhluje; např. 10 zaokrouhlí na desetikoruny, nebo 10 eurocentů

· Způsob zaokrouhlení měsíčního tarifu při krácení dle úvazku.

Vyplňuje se podle číselníku řešitele s hodnotami:

1. Nezaokrouhlovat

2. Na základnu nahoru

3. Od poloviny nahoru

4. Od poloviny dolů

5. Na základnu dolů

přičemž základ je dán následujícím parametrem

· Základ zaokrouhlení měs. tarifu při krácení dle úvazku (CZ/Euro).. číselná hodnota, na kterou se hotovostní dobírka zaokrouhluje; např. 10 zaokrouhlí na desetikoruny, nebo na 10 eurocentů.

· Přesčas počítat z průměrného fondu (Ano) nebo aktuálního v měsíci (Ne)

· Režim pravděpodobného průměrného výdělku

Vyplňuje se podle číselníku řešitele s hodnotami:

0 Pravděpodobný výdělek není počítán,

1 Pravděpodobný výdělek je počítán ze zúčtovaných podkladů,

2 Pravděpodobný výdělek podle předchozího průměru.

3 Pravděpodobný výdělek podle evidovaného tarifu a průměrného měsíčního fondu pracovní doby

4 Režim Ideal A. - ze zúčt. podkladů, resp. dle předchozího

5 Režim DP Praha - DPP/DPČ-ze zúčt. podkladů, ostatní nepočítat

Pozn.: Jednotlivé režimy jsou více popsány v části uživatelské dokumentace Pru_uzdoc – kapitola Konfigurace.

· Průměrný výdělek minimálně ve výšce min. mzdového nároku (Ano/Ne) [pouze SK].

Slouží k určení (pouze pro SK legislativu), zda se má vypočtený průměrný hodinový výdělek dorovnávat na hodnotu minimálního mzdového nároku (odměňování tedy není dohodnuto v KS) nebo pouze na hodnotu minimální mzdy (odměňování je dohodnuto v KS).

· Otáčet zápory do účetnictví (záporné částky se zaúčtují na opačné strany MD – DAL)

0 Ne

1 Ano (účty a položky 1)

2 Ano (účty a položky 1,2)

3 Ano (účty a položky 1,2,3)

· Poslední den převodu mezi středisky

· Měsíc převodu (relativně – 0 současný, 1-příští..)

· NP Počet dávek, které si zachovávají úplný stav … Přihlášky k NP v ČR/ RLFO v SR.

3.47.1.1 Parametry mazání obsahu datových a pracovních tabulek

Parametry jsou definované na hlavní organizaci (u multiorganizačních instalací) na záložce Adm21/Mazání.

Mazání se provádí v akci Vyp02 / Hromadné generování kalendářů, a to v případě, že aktuální datum je mezi 21.dne předchozího měsíce a 20.dnem současného měsíce (obojí vzhledem k období, pro které je kalendář generován). Mazání je prováděno za celou databázi. Jde o samostatný proces, který následuje po vygenerování kalendářů. Není tedy nutné na jeho skončení čekat, je možné při něm pracovat.

Mazání je ale možné parametrem

Přesměrovat mazání do Gdp14 (implicitně probíhá v generování kalendářů): Ano

přesměrovat do GDPR aparátu – procesní sestavy Gdp14.

V dokumentaci Gdp_uzdoc je také toto mazání podrobně popsáno.

Zde je popsáno jen mazání obsahu pracovních tabulek.

Mazání nijak nezasahuje do hlavního výsledku mzdového zpracování. Výplatní lístky ani jejich nákladové začlenění se nemažou.

Mazání pomáhá rychlosti některých akcí např. mzdových importů, výběrového aparátu, sestav.

Zabezpečí, aby velikost databáze nerostla více než je nutné, což uvítají hlavně osoby zodpovědné za zálohování databáze.

Až na poslední parametr jsou všechny parametry zadávány počtem měsíců. Pokud hodnotu smažete, mazání příslušné části nebude prováděno. Pozn. smazání je něco jiného než vyplnění na "0".

Druhou možností je zvětšení počtu měsíců, za které data ponecháte (např. na 120 měsíců).

Parametry:

· Mzdové importy - počet měsíců uchovávaných dat

Předvyplněno hodnotou 12.

Jde o tabulky cemdavky, cemdavky2, cemimpslm. Obsluhují se pomocí Vst06 resp. Vst11.

· Mzdové vstupy - počet měsíců uchovávaných dat

Předvyplněno hodnotou 60.

Jde o tabulky cemvstupy_hist, cemvstupy. Vyp01 / Vstupy

Ponechávány jsou záznamy generované ze srážek (ze Sra01). Mají Původ vzniku 99 a 100. Formulář je zobrazuje pouze při zapnutém checkboxu Všechny vstupy (čtení).

· Převodní příkazy - počet měsíců uchovávaných dat

Předvyplněno hodnotou 60.

Jde o tabulku cemprikazy. Údaje zobrazuje např. Ban07.

· Výstup do účetnictví - počet měsíců uchovávaných dat

Předvyplněno hodnotou 60.

Jde o tabulku cemucto. Údaje zobrazuje formulář Uct02.

· Export do DWH - počet měsíců uchovávaných dat

Předvyplněno hodnotou 12.

Jde o tabulky cewcdckmen,cewcdcmzdy,cewcdczdrav.

· Pracovní data výběrů - počet měsíců uchovávaných dat

Předvyplněno hodnotou 12.

Jde o tabulky cetpravavyb*. Údaje zobrazuje Správa výběrů.

· Docházka - průchody - počet měsíců uchovávaných dat

Předvyplněno hodnotou 6.

Jde o tabulku cedasd.

· Docházka - denní a měsíční data - počet měsíců uchovávaných dat

Předvyplněno hodnotou 18.

Jde o tabulky cedden*, cedmes*, ceddokl*. Zde ale před mazáním vždy proběhne archivace do cedarch (Dcu09)

· Doklady cestovních příkazů - počet měsíců uchovávaných dat

Parametr zatím není funkční.

· Auditní personální záznamy - počet měsíců uchovávaných dat

Jde o tabulky cetoso_hist, cetpv_hist, cetsrazky_hist, cecbcesty_hist, cetmt_hist, cetosokomun_hist, cetplatby_hist, cetlogon_hist.

· Auditní záznamy o strukturách - počet měsíců uchovávaných dat

Jde o tabulku cecstr_hist.

· Potlačit mazání audit tabulky (Adm52) … (Ano/Ne)

Parametr je popsán u formuláře Adm52 (Pozn2)

3.47.1.2 Další parametry

· Limit dní vyhodnocování práv na PV do budoucnosti

Při posouvání referenčního data se vyhodnocují práva jak v minulosti, tak i do budoucnosti. Implicitně je současné maximum dnešní den + 40 dní.

Záporné hodnoty nejsou akceptovány, maximum je 9999.

V praxi to obvykle umožňuje si připravovat údaje pro příští období s použitím těch zařazení, která v příštím období budou platná.

· Typ struktury považovaný za organizační

Implicitně je nastavena struktura 2 – organizační struktura. Je ale možné nastavit, že za organizační strukturu pro výkaznictví je pouvažována i jiná struktura.

Pouze pro CZ legislativu :

· Potlačení slevy na pojištění SZ za zaměstnavatele (Ano/Ne)

· VŠ, fakulta – umístění RID … parametr slouží k definování úrovní, ve kterých bude vykazován identifikátor RID u vysokých škol.

1 Organizace SJ – v kódu SJ (vysoká škola je evidována na úrovni organizace, 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 pro zadání RID vysoké školy v případě, že parametr „VŠ, fakulta – umístění RID“ má hodnotu 1.

· Režim platového automatu

1 Standard

2 Min_do

3 FNB

4 CDC

5 ČVUT

6 IDC

7 Tesco

(bližší informace v dokumentu Opv_uzdoc.docx kapitola Vazba na režimy výpočtu - Adm21

· Logo pro uživatelské sestavy

Logo je primárně určeno pro zákaznické výplatní lístky Vyp11fq resp. Vyp31fq

Je možné toto logo použít i v jiných uživatelských sestavách. Ve standardních sestavách to technicky není možné.

Nepoužívejte logo větší než cca 100KB, výrazně to zvyšuje paměťovou zátěž zpracování sestavy a může vést i k ukončení celého procesu pro nedostatek paměti.

Logo na úrovni SJ a SO je možno zadat na Adm22, Adm23. Při použití se prochází kaskáda SO, SJ, Organizace.

· Čítač pro uživatelskou sestavu 1-3

· Identifikace zákazníka pro úpravy v sestavě Ban29 – pouze pro SK legislativu. Zadáním hodnoty JPC ban29_rezim do tohoto parametru jsou aktivovány zákaznické úpravy při generování XML souboru vytvářeného sestavou Ban29 – Export převodních příkazů ve formátu SEPA SK.

· Vytváření uživatelů LDAP/AD

o LDAP – uzel pro vytváření uživatelů

o LDAP – prefix – zákaznické číslo

o LDAP - atribut employeeNumber

o LDAP – režim generování

o LDAP – režim hesla

o LDAP – pevná část hesla

o LDAP - hledat osobu s RČ

Parametry se využívají v Adm12

· Parametr "Navigace Adm12 - všechny statusy" pak umožňuje zpřístupnit v navigačním seznamu Adm12 potencionálně i Osoby/PV se statusem jiným než 1 - 3, pokud na ně uživatel má práva.

3.47.1.3 Další parametry - samostatná záložka Parametry komunikace

Vlastní připojení k e-mailovému serveru a konfigurace odesílatele je popsána v EGJE_Provdoc

/ kap. 3.6 Konfigurace připojení k poštovnímu serveru.

Další parametry

· http(s) adresa EGJEWeb:

Parametr je používán při generování e-mailů, které vedou příjemce na nějakou akci v EGJEWEB. Odkaz bývá v poslední části e-mailu.
Standardní vyplnění adresy je včetně znaku "/" na konci adresy. V aplikaci sice v některých místech, kde se adresa používá a prodlužuje, kontrola na chybějící "/" je, ale z řady technických důvodů nemůže být úplně všude.

· EGJEWEB - zobrazovat sestavy PDF, HTML v prohlížeči:

Primárně jsou sestavy PDF a HTML zobrazovány přímo v prohlížeči v nové aplikační záložce EGJEWEB.

PDF sestava je zobrazována pomocí Adobe plugin.

Záložka má ikonu s šipkou směřující doprava vzhůru – otevře sestavu do samostatného okna resp. záložky prohlížeče.

V tomto parametru je možné nastavit:

0 – Download sestavy = sestava je serverem poslána jako download.

1 - V záložce EGJEWEB (u PDF pomocí Adobe plugin) = implicitní chování

2 - V záložce EGJEWEB (u PDF pomocí html5) = analogické režimu 1, ale s použitím jiného prohlížeče PDF (dle standardu html5)

Pozn. pro uplatnění provedené změny v běžící aplikaci EGJEWEB je potřeba v prohlížeči aplikaci restartovat (F5) tzn. znovu se přihlásit.

Pozn 2. html5 podporují pouze novější prohlížeče, nicméně je to vestavěná funkčnost.

Tento html5 PDF prohlížeč je nastaven tak, že nenabízí tlačítko uložit dokument (nicméně toto je poměrně slabá ochrana proti uložení na lokální disk, ale pro někoho může být i toto zajímavým rozdílem)

· HTML editory pro Workflow: Ano/Ne, implicitně Ne

Parametr určuje, jestli pole Wflow / Akce je zobrazováno pomocí HTML editoru nebo standardního textového víceřádkového pole.

HTML editor má smysl pouze tehdy, když Adm14 / Předlohy oznámení jsou vyplněny s html značkami resp. odkazy.

Pozn. v standardním java klientu html editor vyžaduje nainstalovanou java 8.

· HTML editory pro Popisy: Ano/Ne, implicitně Ne

Parametr určuje, jestli pole

Zpu01 / Popis / Obsah kurzu

Pmi01 / Popis

Pro01* / Popis, Detailní popis

Rea02 / Vytvoř zprávu

jsou zobrazovány pomocí HTML editoru nebo standardního textového víceřádkového pole.

Je dobré to sladit s případnými již vytvořenými uživatelskými sestavami z těchto oblastí.

Každý výstup konvertuje obsah buď do standardního textu, nebo do html pole v závislosti na tom, jak byl vytvořen v Jasper Reports resp. jak je deklarován datovém zdroji exportní sestavy.

Pozn. v standardním java klientu html editor vyžaduje nainstalovanou java 8.

· "Režim (ne)odesílání e-mailů:" s hodnotami:

1 E-maily odesílat,

2 E-maily odesílat a logovat (ukládá velké množství dat!),

3 E-maily neodesílat a logovat (ukládá velké množství dat!),

4 E-maily neodesílat (typicky testovací db).

slouží k centrálnímu vypnutí odesílání e-mailů.

To může být zajímavé především pro testovací provoz / prostředí.

Pozn.: Neodesílání blokuje vše, ale logování loguje pouze věci mimo workflow, tedy toho, co se dá logovat pomocí Adm14.

Logy zobrazuje Adm54 / navigace E-maily.

· "WFL - při nenalezení e-mailu osoby (typ 31) poslat interní zprávu:"

U některých zákazníků nemají všichni zaměstnanci E-mail v zaměstnání (Osb02 ... Druh 31).

Je-li však worklflow EGJE v Adm14 nastaveno na e-mailová oznámení, zobrazuje zpracování chybová upozornění.

Zde může správce hodnotou Ano nastavit, že při nenalezení e-mailu osoby (typ 31) systém pošle interní zprávu.

Interní zprávu čte uživatel pomocí aplikačního okna Mail.

· Na záložce přibyla nová sekce „Kontrolo vloženého e-mailu před verifikací“, kde jsou 2 definovatelné pole. Tato funkcionalita umožnuje nadefinovat doménu e-mailu a typ e-mailu (např. 31 – e-mail v zaměstnání) vůči kterému se provádí kontrola, zda vložený email odpovídá parametrům zvoleným organizací. V této chvíli je tato funkcionalita spojena jen s uživateli, kteří ji mají propojenu s dalšími formuláři.
V případě vyplnění těchto polí, ale bez napojení na další formulář, se funkcionalita neprojeví. Pokud by byl případný zájem o kontrolu vkládaného e-mailu, je nejprve nutné napojit funkcionalitu na předem domluvený formulář a domluvit typy prováděných kontrol.

3.47.2 Konfigurační parametry sledované navíc na úrovni správní jednotky

· Placení pojistného na GP (pouze SK)

· Zaokrouhlování příjmových SLM

0 Matematicky

1 Nahoru

· Zaokrouhlení hotovostní dobírky

0 Nezaokrouhlovat

1 Na základnu nahoru

2 Od poloviny nahoru

3 Od poloviny dolů

4 Na základnu dolů

· Základ pro zaokrouhlení hotovostní dobírky [CZK/EUR]

.. číselná hodnota, na kterou se hotovostní dobírka zaokrouhluje; např. 10 zaokrouhlí na desetikoruny, nebo 10 eurocentů

· Způsob zaokrouhlení měsíčního tarifu při krácení dle úvazku.

Vyplňuje se podle číselníku řešitele s hodnotami:

0 Nezaokrouhlovat

1 Na základnu nahoru

2 Od poloviny nahoru

3 Od poloviny dolů

4 Na základnu dolů

přičemž základ je dán následujícím parametrem

· Základ zaokrouhlení měs. tarifu při krácení dle úvazku (CZ/Euro)

.. číselná hodnota, na kterou se hotovostní dobírka zaokrouhluje; např. 10 zaokrouhlí na desetikoruny, nebo na 10 eurocentů.

· Přesčas počítat z průměrného fondu (Ano) nebo aktuálního v měsíci (Ne)

· Otáčet zápory do účetnictví (záporné částky se zaúčtují na opačné strany MD – DAL)

0 Ne

1 Ano (účty a položky 1)

2 Ano (účty a položky 1,2)

3 Ano (účty a položky 1,2,3)

· Prefix správní jednotky pro účetnictví

· Zkratka názvu SJ pro exporty

.. textová zkratka názvu SJ používaná v makrech pro tvorbu názvů sestav

· Automaticky proplácet nevyčerpanou dovolenou jako SLM

· Aut. srazit přečerpanou dovolenou jako SLM

· Aut. proplácet nevyčerpanou část dovolené minulého roku (nad 4 týdny) jako SLM …položka se využívá k definici konkrétní SLM na kterou bude automaticky proplacena uvedená nevyčerpaná část dovolené a současně slouží k aktivaci funkce automatického proplacení nevyčerpané části dovolené minulého roku, pokud je tato část vyšší než 4 týdny.

Pro CZ : § 222 ZP odst.2

Pro SK: § 116 ZP odst.2

· Automaticky generovat doplatek do minimální/zaručené mzdy

· Neplatná střediska SLM při zpětném přepočtu nahradit aktuálními

· Evidenční členění dodatkové dovolené z minulého roku jako SLM.

· Evidenční členění dodatkové dovolené z běžného roku jako SLM.

· Evidenční členění řádné dovolené z minulého roku jako SLM.

· Evidenční členění řádné dovolené od předchozího zaměstnavatele jako SLM.

· Evidenční členění ostatní dovolené jako SLM.

· Evidenční členění řádné dovolené z běžného roku jako SLM.

· Omezení tarifů pro SJ zahrnuje položky:

o Výčet tarifních stupnic povolených pro SJ:

o Výčet tarifních stupňů povolených pro SJ:

o Výčet dalšího členění povolený pro SJ:

V případě vyplnění konkrétními výčty, jsou pak tyto použity jako filtry pro zadávání na Opv01, Opv05.

o Kód doby pro nastavení tarifu podle tar. zařazení:

· CZ benefity od 2024 pro SJ zahrnuje položky:

o Suma poskytnutých benefitů od začátku roku (SLM s IA 5533) - vyčíslovat ve výpočtu každý měsíc (Ano/Ne)

· Výčet SLM prac. volna s povinným limitem

Slouží k definici těch SLM pracovního volna, u kterých by měl být zadaný limit na f. Dov02. Pokud není na f. Dov02 u těchto SLM zadán žádný limit, je jako limit určen fiktivní nulový limit, na který je u nich při jejich zúčtování výpočtem prováděna kontrola.

Pouze pro CZ legislativu :

· Promile zák. pojištění odpovědnosti.. stanovené promile pro odvod pojistného

· Příspěvek na FKSP z nákladů generovat jako SLM (bližší informace v dokumentu EGJE_uvod_mzdy.docx odstavec Příspěvky do FKSP)

· Příspěvek na FKSP ze zisku generovat jako SLM: (bližší informace v dokumentu EGJE_uvod_mzdy.docx kapitola Příspěvky do FKSP)

· Číslo okresu pro hlášení o ONZ

· Název okresu pro hlášení o ONZ

· Na dokladech pro ČSSZ uvádět jméno i s titulem (Ano/Ne)

· Stát, ve kterém je činnost vykonávána

· Evid. SLM pro pojištění zaměstnanců na SZ – zam. bez důch. spoření

· Evid. SLM pro pojištění zaměstnanců na SZ – zam. s důch. spořením

· Evid. SLM pro vym. základ zaměstnavatele na SZ – zam. s důch. spoř. i bez

· Evid. SLM pro část daně 15% bez solidárního navýšení

· Evid. SLM pro část daně 7% solidárního navýšení

· Více než 50% zaměstnanců se zdravotním postižením pro ZP (Ano/Ne)

Pouze pro SK legislativu

· Zaokrouhlování příjmových SLM

0 Matematicky

1 Nahoru

· Automaticky generovat změny v ZP (Ano/Ne)

· Dny výkonu práce dohod jsou zadávané (IA 5138), (Ano/Ne)

· Vyšší náhrada při DPN je sjednána v kolektivní smlouvě (Ano/Ne)

Tento parametr eviduje, zda je případné navýšení náhrady příjmu nad základní výši stanovenou zákonem sjednáno v kolektivní smlouvě a zda tedy podléhá zdanění či nikoli.

Pro Treximu SK

· právní forma

· kód vlastnictví

· odvětví

· kód odborového svazu

· typ kolektivní smlouvy

· hlavní trh výrobků

Pro tvorbu sociálního fondu (SF)

· příspěvek do SF z nákladů generovat jako SLM. (bližší informace v dokumentu EGJE_uvod_mzdy.docx odstavec Příspěvky do sociálního fondu)

· příspěvek do SF ze zisku generovat jako SLM. (bližší informace v dokumentu EGJE_uvod_mzdy.docx odstavec Příspěvky do sociálního fondu)

Další parametry

· Logo pro uživatelské sestavy
Obdoba loga na pro úroveň organizace, ale pro úroveň SJ. Při použití se prochází kaskáda SO, SJ, Organizace.

3.47.3 Konfigurační parametry sledované navíc na úrovni správního oddílu

· Zaokrouhlování příjmových SLM

0 Matematicky

1 Nahoru

· Zaokrouhlení hotovostní dobírky

0 Nezaokrouhlovat

1 Na základnu nahoru

2 Od poloviny nahoru

3 Od poloviny dolů

4 Na základnu dolů

· Základ pro zaokrouhlení hotovostní dobírky [CZK/EUR]

.. číselná hodnota, na kterou se hotovostní dobírka zaokrouhluje; např. 10 zaokrouhlí na desetikoruny, nebo 10 eurocentů

· Otáčet zápory do účetnictví (záporné částky se zaúčtují na opačné strany MD – DAL)

0 Ne

1 Ano (účty a položky 1)

2 Ano (účty a položky 1,2)

3 Ano (účty a položky 1,2,3)

· Prefix správního oddílu pro účetnictví

· Zkratka názvu SO pro exporty

.. textová zkratka názvu SO používaná v makrech pro tvorbu názvů sestav

· Automaticky proplácet nevyčerpanou dovolenou jako SLM

· Aut. srazit přečerpanou dovolenou jako SLM

· Aut. proplácet nevyčerpanou část dovolené minulého roku (nad 4 týdny) jako SLM …položka se využívá k definici konkrétní SLM na kterou bude automaticky proplacena uvedená nevyčerpaná část dovolené a současně slouží k aktivaci funkce automatického proplacení nevyčerpané části dovolené minulého roku, pokud je tato část vyšší než 4 týdny. Pro CZ : $222 ZP odst.2 Pro SK: $116 ZP odst.2

· Automaticky generovat doplatek do minimální/zaručené mzdy

· Procento pro určení stálé mzdy v rámci konta pracovní doby – položka se užívá v případech, kdy zaměstnavatel využívá práci v režimu konta pracovní doby, pro automatický výpočet výše Stálé mzdy při zařazení PV na vyrovnávací období. Dle legislativy hodnota nesmí být menší než 80%. Podrobné informace k principům práce v režimu konta pracovní doby jsou uvedeny v samostatném dokumentu Kpd_uzdoc.docx. Pouze pro CZ legislativu.

· Počítat saldo v rámci konta PD – položka udává, zda se při výpočtu v režimu konta pracovní doby (KPD) má počítat i saldo doby, které je součástí účtu konta pracovní doby. Hodnota NE se užívá v případě, že saldo doby je evidováno v jiném (např. docházkovém) systému.

· Automaticky vyrovnávat záporný odvod záloh na daň – hodnota ANO udává, že vznikne-li přeplatek na zálohách na daň (odvedená částka by byla záporná), bude tento přeplatek automaticky uplatněn v příštím období.

· Výčet SLM prac. volna s povinným limitem

Další parametry

· Logo pro uživatelské sestavy
Obdoba loga na Adm21 pro úroveň organizace, ale pro úroveň SO. Při použití se prochází kaskáda SO, SJ, Organizace.

Záložka e-Daňovka

Obsahuje parametry určené pro uživatele e-Daňovky (Prohlášení/ Žádost o RZD)

· Žádat o RZD lze do (dd.mm)

Interní termín, do kterého může zaměstnanec prostřednictvím e-daňovky odeslat Žádost o RZD mzdové účetní – pokud nevyplněn, je termín daný zákonem na 15.2. (případně nejbližší další pracovní den)

· Při promítání Prohlášení nerezidenta přepisovat i evidenci v Osb02

Příznak, zda v případě nerezidenta mají být údaje o nerezidentovi uvedené v Prohlášení automaticky promítnuty i do záložky Cizí státní příslušníci na f. Osb02

· Kontrolovat platnost slevy na poplatníka do konce roku?

Pokud je tento parametr nastaven na hodnotu Ano, kontroluje se v průvodci tvorbou Prohlášení na f. Dan31, zda zaměstnanec uplatňuje slevu na poplatníka do konce roku.

Pokud nikoli, je na to v takovém případě upozorněn (při odchodu z příslušné stránky) hláškou

„Základní sleva netrvá celý kal. rok - pokračovat?" (A/N)

která mu umožní se nad zadaným údajem zamyslet a případně jej upravit.

3.47.4 Další konfigurační parametry

Na této záložce přibyla sekce „Vytvořit logname dle podmínek Adm21 (bez AD)“. Tento parametr se nastavuje pro použití funkcionality na formuláři Adm12 (záložky „Přihlášení autentizace“ a „Hromadné akce“. Specifikuje, jak ma vypadat formát generovaného logname v případě, že klient nemá Active Directory. Tato funkcionalita se spouští novými tlačítky na na formuláři Adm12 na záložkách uvedených výše. Tlačítka „Generuj logname dle Adm21“ a „Generuj chybějící logname dle Adm21“.

3.47.5 Konfigurace výstupního formátu protokolu z Adm53

Tímto parametrem na formuláři Adm21 à záložka „Konf.par.“ s názvem „Výstupní formát protokolu (Adm53):“ se dá nastavit výstupní formát protokolu, který se generuje na formuláři Adm53. Pokud je tedy na Adm53 nadefinovaná akce a na záložce „Parametry“ à „Tabulkový pohled“ je zadaný parametr „r_send4error2ext“ nebo je možné ho zadat na záložce „Formulářový pohled“ je to parametr s názvem „Odeslat protokol na email“ (jde o stejný parametr, ale zobrazovaný na jiných záložkách), tak pomocí parametru „Výstupní formát protokolu (Adm53):“ se dá nastavit v jakém formátu se má daný protokol vytvořit a odeslat.

3.47.6 Parametr „Zobrazovat navigační seznam“

Tento parametr slouží k možnosti vypnutí a zapnutí navigačního seznamu, který se zobrazuje na WEB klientovi. Pro mobilní zařízení nebo tablety, tato lišta zabírá příliš mnoho místa i v minimálním zobrazení a tímto parametrem se dá potlačit.

V případě, kdy bude mít uživatel jen jedno PV, není v takovém případě nutné toto menu vůbec zobrazovat a proto bude zobrazení lišty, v takovém případě, plně potlačeno.

4 Upozornění

Seznam přístupných částí dokumentace je zde.