Elektronické podpisy v rámci workflow oběhu dokumentů

(zpoplatněná část programu)

Obsah

1 Úvod.................................................................................................................. 3

1.1 Slovníček pojmů.......................................................................................... 3

1.2 Výchozí předpoklady řešení......................................................................... 3

1.3 Základní procesy......................................................................................... 4

1.3.1 Rozšíření workflow oběhu dokumentů o funkcionality elektronických podpisů 4

1.3.1.1 Podpisový krok................................................................................ 5

1.3.1.2 Odeslání dokumentu na e-mail zaměstnance..................................... 5

2 Parametrizace podpisového workflow................................................ 6

2.1 Systémová nastavení................................................................................... 6

2.1.1 Struktury................................................................................................ 6

2.1.2 Nastavení osoby.................................................................................... 6

2.1.3 Oprávnění.............................................................................................. 6

2.1.3.1 Objektová práva k formulářům a jejich záložkám a atributům.............. 6

2.1.3.2 Objektová práva k záznamům dokumentů......................................... 7

2.1.3.3 Objektová práva k akcím workflow.................................................... 7

2.1.3.4 Audit akcí pro uživatele se speciálním oprávněním............................. 8

2.1.4 API podpisového modulu a podpisové prostředky................................ 8

2.1.5 Logování................................................................................................ 9

2.2 Workflow oběhu dokumentů................................................................... 10

2.2.1 Příprava dokumentu........................................................................... 11

2.2.1.1 Šablona dokumentu (Rtf10, Rtf11).................................................. 11

2.2.1.2 Typ dokumentu (Jpc01).................................................................. 11

2.2.2 Nastavení workflow (Adm14, Adm33)................................................ 11

2.2.2.1 Parametrizace na úrovni workflow.................................................. 12

2.2.2.2 Záložka Kroky workflow: Parametrizace podpisu na úrovni kroku workflow 13

2.2.2.3 Parametrizace obsahu e-mailu........................................................ 14

2.2.3 Spuštění workflow............................................................................... 15

2.2.4 Akceptace dokumentu v rámci workflow............................................ 15

2.2.4.1 Akce Podepsat/Podepsat zaměstnanec............................................ 15

2.2.4.2 Akce Odeslat dokument................................................................. 16

2.2.5 Akce pro uživatele se speciálním oprávněním.................................... 17

2.2.5.1 Akce Storno dokumentu................................................................. 17

2.2.5.2 Akce Odblokovat............................................................................ 17

2.2.5.3 Akce Ukončit workflow................................................................... 17

2.2.6 Formuláře zpřístupňující workflow oběhu dokumentu....................... 17

2.3 Kontrola požadovaného termínu akceptace.............................................. 19

2.3.1 Parametrizace kontroly DEADLINE akceptace dokumentu................. 19

2.3.2 Místa aplikace kontroly DEADLINE v rámci workflow dokumentu..... 20

2.3.3 Proces ukončení workflow dokumentů z důvodu DEADLINE akceptace dokumentu....................................................................................................... 20

2.3.4 Úloha 45 - Ukončení WFL dokumentů neakceptovaných v požadovaném termínu..................................................................................... 20

2.3.5 Adm33: Akce workflow 501 - Ukončení WFL dokumentu z důvodu vypršení termínu pro akceptaci........................................................................ 21

2.3.6 Integrace na PM Signi a DEADLINE akceptace dokumentu............... 21

3 Alternativní režimy podpisu.................................................................... 24

3.1 Základní režim podpisu vs alternativní režimy podpisu............................... 24

3.2 Režim podpisu mimo HRP........................................................................... 24

3.2.1 Základní předpoklady a charakteristika Režimu podpisu mimo HRP. 24

3.2.2 Odlišnosti komunikace s PM při podpisu v režimu podpisu mimo HRP 25

3.2.2.1 Odeslání dokumentu k podpisu do PM............................................ 25

3.2.2.2 Stažení podepsaného dokumentu z PM do EGJE............................... 26

4 Integrace EGJE na podpisový modul...................................................... 28

4.1 Výchozí předpoklady řešení integrace........................................................ 28

4.2 Registrace v Signi a podpisové workflow.................................................. 29

4.3 API SIgni................................................................................................... 30

4.4 Rámcový popis procesu elektronického podpisu......................................... 30

4.4.1 Akce Podepsat\Podepsat zaměstnanec.............................................. 32

4.4.2 Proces podpisu.................................................................................... 32

4.4.3 DELETE job: mazání neaktivních dokumentů ve workspace Signi...... 32

4.5 Archivace dokumentů v PM Signi.............................................................. 33

4.5.1 Vstupní info......................................................................................... 33

4.5.2 Parametrizace Archívu PM.................................................................. 34

4.5.2.1 PM Signi........................................................................................ 34

4.5.2.2 EGJE............................................................................................. 34

4.5.3 Integrační scénář pro aktivní ARCHÍV PM........................................... 35

4.5.4 Alternativní scénáře............................................................................ 35

5 Typový příklad konfigurace podpisového workflow..................... 37

5.1 Základní proces......................................................................................... 37

5.1.1 Systémové nastavení........................................................................... 37

5.1.2 Proces.................................................................................................. 37

5.2 Konfigurace.............................................................................................. 38

5.2.1 Organizace a systém........................................................................... 38

5.2.1.1 Nastavení struktur (Str01, Str02)..................................................... 38

5.2.1.2 API a podpisové prostředky (Adm55)............................................... 38

5.2.1.3 Organizace (Adm21) – nastavení defaultního podepisovacího prostředku zaměstnance.................................................................................. 39

5.2.2 Uživatelé.............................................................................................. 39

5.2.2.1 Nastavení pro odesílání schválených dokumentů na e-mail zaměstnance................................................................................................... 39

5.2.2.2 Typové profily a uživatelé............................................................... 39

5.2.3 Dokumenty.......................................................................................... 40

5.2.4 Workflow podpisu dokumentu............................................................ 41

5.2.4.1 Prodloužení pracovní smlouvy........................................................ 41

1 Úvod

Tento dokument představuje základní funkcionalitu komponenty elektronického podpisu dokumentu v rámci workflow oběhu dokumentů a integraci na podepisovací modul.

1.1 Slovníček pojmů

Pojem	Popis
EGJE (Elanor Global Java Edition)	HR IS společnosti Elanor
HRP	EGJE HR Portál
HR (Human Resources)	Lidské zdroje
PM (Podpisový modul)	Podepisovací software
WF	Workflow

1.2 Výchozí předpoklady řešení

Výchozím předpokladem elektronického podpisu pomocí rozhraní podepisovacího modulu je:

· Podepisovat budou uživatelé pomocí EGJE HR portálu. Řešení je postaveno na tenkém klientovi (webová část, která obsahuje i HR portál).

· Workflow oběhu dokumentu i funkcionalita elektronického podpisu jsou samostatně obchodované komponenty. Zákazník, který chce tyto funkcionality využívat, musí mít zpřístupněnou komponentu workflow oběhu dokumentů a komponentu elektronických podpisů.

· Podpis je zajišťován prostřednictvím providera služby elektronického podpisu. Aktuálně je EGJE integrováno na podpisový modul Signi.

· Proces podpisu dokumentu je řízen workflow EGJE. Rozhraní podepisovacího modulu je voláno pro každého podepisujícího samostatně, tj. v rámci každého podpisového kroku workflow oběhu dokumentu definovaného v EGJE. Komunikace EGJE s podepisovacím modulem v rámci podpisu je tedy vždy uceleným procesem začínajícím předáním dokumentu do podepisovacího modulu k podpisu a končícím nahráním dokumentu podepsaného daným podepisujícím zpět do EGJE.

1.3 Základní procesy

1.3.1 Rozšíření workflow oběhu dokumentů o funkcionality elektronických podpisů

Poté, co je workflow spuštěno, prochází postupně definovaným sledem kroků. V rámci každého kroku je vyhodnoceno, zda je na daném kroku vyžadováno Schválení nebo Podpis. V případě podpisového kroku je pro parametrizaci režimu podpisu možné využít pouze Typ schvalování = 1 – Schválení 1. primárním příjemcem z min. kroku. Na základě pravidla příjemce definovaného na daném kroku workflow EGJE notifikuje uživatele, který je odpovědný za schválení/podpis dokumentu. Uživatel si může workflow otevřít na formuláři Wflow, Opv31 a formuláři Pkz01 a zde záložce Dokumenty PV.

1.3.1.1 Podpisový krok

Pokud je daný krok definován jako podpisový, workflow zpřístupní uživateli, který je podepisujícím na daném kroku, akci Podepsat. Spuštěním akce dojde k odeslání dokumentu do podpisového modulu. Podpisový modul si dokument uloží a zašle URL adresu, na které je možné dokument podepsat. Uživatel je na tuto adresu přesměrován, dokument podepíše a po podpisu je přesměrován zpět na HR portál. Podepsaný dokument se stáhne a workflow dokumentu přejde na další krok. Popis komunikace mezi EGJE a podpisovým modulem v rámci procesu podpisu viz Rámcový popis procesu elektronického podpisu.

Spuštění podpisového kroku je možné provést také v zástupném režimu, a to v případě kroku, kdy podepisujícím je zaměstnanec, tedy osoba, o které workflow dokumentu je. V rámci oprávnění je možné na zaměstnanecké profily nastavit objektové právo omezující přístupnost akce Podepsat zaměstnanec, a naopak na určené profily nastavit rozšiřující oprávnění umožňující spustit akci Podepsat zaměstnanec zástupně za zaměstnance. Tato speciální oprávnění mohou být využita, pokud zákazník chce mít podpis všech dokumentů zaměstnancem procesně nastaven tak, že se zaměstnanec osobně dostaví za svým nadřízeným nebo personalistou a zde dokument podepíše. Zástupné spuštění podpisu je možné pouze z formuláře Opv31, nikoliv z Wflow.

V rámci podpisového workflow může dojít k nestandardní situaci, kdy je dokument odeslán k podpisu do podpisového modulu, ale v rámci podpisu je zjištěna chyba a je potřeba dokument opravit a znovu odeslat opravený k podpisu. Pro tyto účely bude po odeslání dokumentu do podpisového modulu pro uživatele se speciálním oprávněním dostupná akce Storno dokumentu. Jejím spuštěním se dokument odblokuje a workflow se vrátí do stavu 0, ve kterém je možné dokument vyměnit a spustit workflow znovu.

1.3.1.2 Odeslání dokumentu na e-mail zaměstnance

Pokud je v rámci parametrizace workflow nastaveno odesílání dokumentu na e-mail zaměstnance, pak po akceptaci dokumentu (workflow bylo ukončeno ve stavu 30) dojde dle nastaveného režimu odeslání k automatickému nebo ručnímu spuštění procesu odeslání dokumentu na e-mail s parametry definovanými pro dané workflow na Adm14:

· Dokument se zazipuje

· Pokud bylo požadováno šifrování a/nebo použití hesla, pak před odesláním dojde k zašifrování zipu dokumentu a jako heslo se použije heslo uživatele spravované na formulářích Xpw02/Xpw03.

· Dokument se odešle na definovaný typ e-mailu zaměstnance. Pokud je požadováno odeslat i na další adresáty, pak je možno definovat na Adm33 (úloha 500). Zde je rovněž potřeba nastavit, pokud v případě zástupu zaměstnance nemá má být e-mail s dokumentem zaslán na zástupce zaměstnance.

· Odeslání dokumentu na e-mail se audituje a audit je dostupný na samostatné záložce workflow na Opv31

2 Parametrizace podpisového workflow

2.1 Systémová nastavení

2.1.1 Struktury

Pro nastavení schvalovatele/podepisujícího na daném kroku workflow oběhu dokumentu jsou využívány pravidla příjemce, z nichž některá určují schvalovatele/podepisujícího na základě definovaných struktur. Definice by měla obsahovat liniové struktury zařazení zaměstnanců, u kterých předpokládáme podpis dokumentů zaměstnanců za zaměstnavatele (nadřízený zaměstnance, odpovědný personalista atd.) nebo pověření k zástupnému spuštění akce podpisu za zaměstnance.

2.1.2 Nastavení osoby

V rámci odesílání notifikací a schváleného/podepsaného dokumentu zaměstnanci na e-mail je možné vybrat typ e-mailu, na který chceme zaslat. Výběr je možný z 30 - Mail pro el. doručování, 31 - E-mail v zaměstnání, příp. 32 - E-mail soukromý. Je potřeba ošetřit evidenci těchto kontaktů u zaměstnanců na formuláři Osb02.

V případě podpisu zaměstnance v Režimu mimo HRP, je podmínkou zadání e-mailu typu 30 - Mail pro el. doručování, na který jsou odesílány notifikace z PM. Samotný Režim podpisu mimo HRP je nastavován na Adm11\záložka Osoba. Zde je potřeba nastavit Režim podpisu = 10 – Podpis mimo HRP. Nevyplněné podle Režimu podpisu znamená Základní režim (standardní proces podpisu přes HRP. Pro nastavení Režimu podpisu na Osobě je potřeba speciální oprávnění fPodpisMimoHRP.

Dále při odeslání dokumentu na e-mail zaměstnance může být požadováno použití hesla. Využívá se heslo pro výplatní pásky definované na formulářích Xpw02/03. Je potřeba zajistit, aby zaměstnanec měl heslo zadané.

2.1.3 Oprávnění

V rámci nastavení procesu podpisu dokumentu je možné využít speciální oprávnění, která umožňuji zákazníkovi parametrizovat proces dle svých potřeb, a to na úrovni:

· Přístupu k formulářům, záložkám či atributům na formulářích

· přístupů k jednotlivým dokumentům ve schvalovacím režimu na Opv31, resp. Pkz01

· přístupů k akcím spojeným s podpisovým procesem na Opv31, Pkz01\Dokumenty PV, Wflow

2.1.3.1 Objektová práva k formulářům a jejich záložkám a atributům

fSeiad

Obecné oprávnění k funkcionalitě komponenty elektronických podpisů v rámci workflow oběhu dokumentů. Právo zpřístupňuje parametrizaci podpisů na definici workflow oběhu dokumentů na Adm14 (akce 300-399) a Adm33. Dále zpřístupňuje informace evidované ve vazbě na podpis a odeslání dokumentu na e-mail zaměstnanci na formulářích Opv31, Pkz01\Dokumenty PV.

Pkz01dokumenty

Právo zpřístupňuje záložku Dokumenty PV na formuláři Pkz01.

fPodpisMimoHRP

Uživatel s oprávněním fPodpisMimoHRP může u zaměstnance nastavit režim podpisu mimo HRP (Adm11, Záložka osoba).

2.1.3.2 Objektová práva k záznamům dokumentů

Na formuláři Opv31 a v rámci záložky Dokumenty PV na Pkz01 lze pro omezení přístupů k dokumentům v režimu schvalování využít nová řádková objektová práva, která dále omezí filtrování záznamů dle stavu schvalování dokumentu. Pro aplikaci těchto oprávnění i před spuštěním schvalovacího workflow je potřeba aby status schvalování dokumentu při založení byl nastaven 0 – koncept. Toto je zajištěno nastavením workflow. Toto je nastavováno parametrem Rtf2x ukládané do Opv31 poslat do schvalování = Ano (Adm14\Dokumenty).

Omezení přístupnosti dokumentů bez ohledu na stav je standardně zajištěno na Adm02 uvedením výčtu dokumentů, ke kterým má mít daný profil přístup.

Opv31omezProZam

Přihlášený uživatel bude mít omezena řádková práva na již schválené dokumenty a v případě dokumentů v procesu schvalování pak dokumenty uvidí na kroku, na kterém je schvalujícím/podepisujícím.

Opv31omezProSchval

Opv31omezNaNezahajene

Přihlášený uživatel bude mít omezena řádková práva na dokumenty se zahájeným schvalovacím procesem a schválené, tzn. neuvidí dokumenty, které ještě nebyly odeslány ke schválení.

2.1.3.3 Objektová práva k akcím workflow

Opv31omezPodpisVlastni

Přihlášený uživatel nebude mít právo na akci Podepsat zaměstnanec. Tzn. pokud přihlášený uživatel bude podepisujícím na kroku podpisu zaměstnance (tedy osoby o níž WF je), pak bude mít akci Podpis zaměstnance neaktivní.

Opv31pravoPodpisZam

Přihlášený uživatel bude mít právo na akci Podepsat zaměstnanec na krocích, kde není adresátem kroku (podepisujícím), ale adresátem kroku je osoba, o níž WF je (zaměstnanec). Tzn. pokud přihlášený uživatel není podepisujícím na kroku podpisu zaměstnance (tedy není osobou o níž WF je), pak bude moci na daném kroku spustit akci Podepsat zaměstnanec i Zamítnout.

Pokud nebudeme chtít povolit “zástupné“ spuštění akce Podpis zaměstnance uživateli s profilem s daným objektovým právem pro všechny typy dokumentů, pak musí být vytvořen nový profil pro tyto účely zástupného spuštění, kde dojde k omezení typů dokumentů (Adm02/Profil základní údaje (řádková práva a zde přístup k záznamům a akcím - řádková práva)).

Opv31pravo OdeslatNaMail

Právo spustit akci Odeslat dokument.

Opv31statusAdmin

Uživatel s právem Opv31statusAdmin může změnit stav dokumentu mimo definovanou matici povolených přechodových stavů, ale v případě, že jde o dokument, který byl již akceptován (status 30) a byl odeslán zaměstnanci na e-mail nebo byl akceptován (status 30) minimálně jedním podpisem, nelze stav změnit. Uživatel s tímto oprávněním má dále přístupné akce Storno dokumentu a Ukončit workflow .

Opv31editPlatnostDo

Uživatel s tímto oprávněním může na dokumentu v rámci Opv31 editovat pole Platnost do (CETPVDOK.PLATNOST_DO) v libovolném stavu dokumentu, mimo stav -1.

DokOdblokace

Pokud je dokument odeslán k podpisu do podpisového modulu, pak do okamžiku nahrání podepsaného dokumentu zpět do EGJE je označen jako blokován a EGJE a takový dokument nemůže být na straně EGJE aktualizován. Uživatel s právem DokOdblokace může dokument odeslaný k podpisu do podpisového modulu odblokovat.

WflowChranenaVlastni

Speciální objekt práv WflowChranenaVlastni umožňuje aplikovat na Wlfow nastavení Profilu na Adm02 v parametru: Další podmínky omezení práv k osobám a pv: PV – přístup k chráněným PV a vl.osobě. Wflow standardně zpřístupňuje uživateli seznam úkolů, které má uživatel akceptovat (schválit, podepsat) resp. zamítnout, a to včetně těch workflow, které se týkají přihlášeného uživatele nebo osoby v režimu chráněné PV. Přiřazením práva WflowChranenaVlastni na profil dojde k aplikaci nastaveného režimu v přístupu k vlastním osobě a chráněným PV.

2.1.3.4 Audit akcí pro uživatele se speciálním oprávněním

Vybrané akce uživatele se speciálním oprávněním mimo workflow jsou auditovány a audit je dostupný na Opv31 Dokumenty PV, záložka Audit akcí mimo workflow. Audit je prováděn pro tyto akce (oprávnění - akce): Opv31statusAdmin - ruční editace statusu dokumentu, Akce Storno, Opv31editPlatnostDo – editace Platnost do, DokOdblokace - akce Odblokovat. V rámci auditu je evidováno, kdo akci provedl a s jakým speciálním oprávněním, o jaký typ akce a typ změny šlo, jaká položka byla změnou ovlivněna a její výchozí a koneční hodnota.

2.1.4 API podpisového modulu a podpisové prostředky

Podpis na dokumentu je zajišťován pomocí integrace na podpisový modul. Konfigurace přístupů ke službám API podpisového modulu a podpisovým prostředkům, které nabízí, je definována na formuláři Adm55. Na záložce API jsou nastaveny parametry rozhraní. V případě napojení na podpisový modul Signi uvést Poskytovatel = 10 – Signi. Na záložce Prostředky jsou pak definovány podpisové prostředky, které daný podepisovací modul nabízí. Například poskytovatel těchto služeb nabízí prostřednictvím svého API prostý a certifikovaný podpis. V rámci prostředků tak bude definován prostředek pro elektronický podpis prostý (Oblast služeb = 1 – Podpisy a pečetě, Typ služeb = 10 – Elektronický podpis prostý) a prostředek pro certifikovaný podpis (Oblast služeb = 1 – Podpisy a pečetě, Typ služeb = 14 – Podpis certifkátem)

Prostředky je možné přiřadit na organizaci nebo správní jednotku. Na úrovni organizace nebo správní jednotky vždy nastavujeme jeden prostředek jako defaultní. Toto nastavení je využito v případě, kdy chceme omezit výběr podpisového prostředku zaměstnanci. V případě, kdy máme k dispozici více podpisových prostředků pro daný typ podpisu (např. je zajištěno napojení na dva providery prostého podpisu), se na podpisovém kroku workflow nabídne uživateli jejich výběr. Tento výběr je ale možné omezit na jediný defaultní prostředek, pokud podepisujícím je zaměstnanec (podepisuje uživatel, o kterém workflow je). Toto omezení výběru podpisového prostředku pro zaměstnance je nastavováno parametrem Zaměstnanec bez možnosti volby podpisového prostředku na formuláři Adm21, záložce Konfigurační parametry v části Další parametry.

2.1.5 Logování

Zpracování podpisového kroku workflow je standardně logováno v rámci formuláře Wfow a Opv31 – Dokumenty PV, záložka Workflow.

Odeslání podepsaného dokumentu na e-mail zaměstnance je logováno na Opv31 – Dokumenty PV, záložka Audit odeslání dokumentu.

Operace provedené se speciálními oprávněními jsou logovány na Opv31 – Dokumenty PV, záložka Audit akcí mimo workflow.

Detailní log operací uživatele a komunikace EGJE s podpisovým modulem v průběhu celého zpracování podpisu je řešen prostřednictvím souborového logu log4j (logování na úrovni info). Postup nastavení:

do adresáře s konfiguračními soubory EGJE uložit soubory log4j2.elpoWeb.xml a log4j2.elpo.xml
v rámci konfigurátoru EGJE (config_egje) na záložce Logování (zde Log4j konfigurace) nastavit vazbu na logovací soubor: v případě webového serveru (tomcat) soubor log4j2.elpoWeb.xml a v případě aplikačního sever (wrapper) soubor log4j2.elpoWeb.xml. Ukázka formátu zadání cesty: c:/wrapper/conf/log4j2.elpoWeb.xml
Po nastavení logovacích souborů provést restart tomcat a wrapper.
Webový klient má všechny logy ve složce tomcatu „logs“, Java klient má typicky serverové logy ve složce wrapperu v „logs“ a klientské logy ve složce uživatele.

Obecné nastavení logování je popsáno v dokumentaci EGJE_provdoc

2.2 Workflow oběhu dokumentů

Před samotným spuštěním workflow podpisu dokumentu pro jednotlivé zaměstnance je potřeba provést dva přípravné kroky.

Poté, co byla připravena šablona dokumentu a nastaveno podpisové workflow, je možné spustit proces akceptace dokumentu pro jednotlivé zaměstnance.

2.2.1 Příprava dokumentu

2.2.1.1 Šablona dokumentu (Rtf10, Rtf11)

Příprava šablony dokumentu probíhá v rámci formulářů Rtf10/Rtf11. Pokud chceme mít v dokumentu blok pro elektronický podpis, pak v daném místě šablony vložíme řetězec pro označení oblasti kódem podpisu (příklad: %podpis_1%, %podpis_2%), který je v rámci dokumentu jedinečný. Kód zabarvíme barvou pozadí, aby v rámci tisku nebyl viditelný. Tento kód pak bude použitý pro následnou komunikaci s podpisovým modulem. Tzn. pokud dokument obsahuje dva podpisy, např. podpis manažera a podpis zaměstnance, pak v rámci definice workflow jde o dva kroky a každý z nich bude mít uveden odpovídající kód podpisového pole (kód podpisového pole manažera bude uveden na kroku workflow, kde bude podepisujícím manažer a kód podpisového pole zaměstnance bude uveden na kroku workflow, kde bude podepisujícím zaměstnanec).

2.2.1.2 Typ dokumentu (Jpc01)

Dokument se standardně zakládá pod odpovídajícím typem číselníku Typ dokumentu (uchaz_dok_typ, formulář Jpc01). V případě typů dokumentů, které mají podléhat režimu schválení/podpisu, je potřeba pro daný typ dokumentu nastavit Kód 3 = 1 - Může a nemusí být schvalovaný/podepisovaný nebo 2 - Musí být schvalovaný/podepisovaný. V případě režimu 1 - Může a nemusí být schvalovaný/podepisovaný jsou dokumenty před spuštěním bez definovaného stavu a na dokumenty s nedefinovaným stavem se pak neaplikují speciální Objektová práva k záznamům dokumentů.

Pro každou kombinaci podepisujících (např. dokument A podepisuje zaměstnanec a za zaměstnavatele nadřízený manažer, nebo dokument B podepisuje zaměstnanec a za zaměstnavatele nadřízený personalista) nebo požadovaného typu podpisu (pokud bychom měli 2 dokumenty podepisované zaměstnancem a nadřízeným manažerem, ale u jednoho dokumentu stačí prostý podpis a u druhého dokumentu je požadován kvalifikovaný podpis) je potřeba definovat samostatný typ dokumentu a samostatnou definici workflow.

2.2.2 Nastavení workflow (Adm14, Adm33)

Workflow oběhu dokumentu je definováno na formuláři Adm14 a to pro akce workflow v rozsahu 300-399. Na úrovni workflow je parametrizace procesu podpisu řešena jak na úrovni celého workflow, tak na úrovni podpisových kroků. Obecné nastavení definice workflow je dostupné v rámci uživatelské dokumentace obecného schvalovacího workflow oběhu dokumentu. Zde uvádíme pouze ty parametrizace workflow, které jsou spojené s funkcionalitami vázanými na schvalování dokumentů prostřednictvím elektronického podpisu.

2.2.2.1 Parametrizace na úrovni workflow

2.2.2.1.1 Záložka Detail

Na záložce Detail je parametrizováno chování související s dokumentem a jeho odesláním na e-mail zaměstnanci.

Název workflow

Pokud je požadováno odeslání podepsaného dokumentu na e-mail zaměstnance, pak název e-mailu bude načten z Názvu workflow.

Konverze formátu dokumentu

Parametrem Konvertovat formát dokumentu definujeme, zda chceme při spuštění workflow konvertovat formát dokumentu.

Metoda konverze je pak nastavena parametrem Způsob konverze formátu dokumentu. Aktuálně je implementována konverze z formátu rtf na pdf.

Režim odeslání dokumentu na e-mail zaměstnance

Parametr Režim odeslání dokumentu umožňuje nastavit, zda chceme odeslat podepsaný dokument zaměstnanci na e-mail a pokud ano, v jakém režimu:

· automaticky po ukončení workflow schválením dokumentu: Režim odeslání dokumentu = 10 – Odeslat automaticky po schválení dokumentu). Odeslání zajišťuje sestava Dok10, kterou je potřeba nastavit na Adm53.

· odeslání ponechat na akci uživatele s příslušným oprávněním: Režim odeslání dokumentu = 20 – Odeslat akcí uživatele)

V případě, že nechceme schválený/podepsaný dokument odeslat na e-mail zaměstnanci, pak nastavíme Režim odeslání dokumentu = 0 - Neposílat

Způsob zabezpečení dokumentu při odeslání na e-mail

Způsob zabezpečení dokumentu při odeslání na e-mail zaměstnanci je nastaven pomocí dvou parametrů.

· Použít heslo při odeslání dokumentu na e-mail definuje požadavek na zaheslováni dokumentu. Pokud je požadováno, používá se heslo definované na formulářích Xpw02/Xpw03.

· Typ šifrování pak specifikuje požadovaný typ šifrování dokumentu. Aktuálně je implementováno šifrování ZIPu a to AES-256, AES-128, ZIPcrypto.

S ohledem na aktuálně implementované typy šifrování (šifrování ZIPu) je proces šifrování a heslování provázán. K zaheslováni ZIPu a zašifrování tak dojde v případě nastavení: Použít heslo při odeslání dokumentu na e-mail = Ano a/nebo Typ šifrování = AES-256/AES-128.

2.2.2.1.2 Záložka Dokumenty

Režim založení dokumentu na Opv31

Pokud chceme na Opv31/Pkz01 Dokumenty PV aplikovat oprávnění na záznamy dle stavu workflow, pak je potřeba zajistit, aby se dokument podléhající schvalovacímu režimu (definováno v rámci Typ dokumentu (Jpc01)) založil na Opv31 ve stavu schvalování 0 – Koncept. V tomto případě je potřeba nastavit na Adm14, záložce Dokumenty parametr Rtf2x ukládané do Opv31 poslat do schvalování = Ano.

Parametrizace statusů workflow

Na záložce Statusy definujeme set statusů, pomocí kterých definujeme sled kroků průchodu workflow oběhu dokumentu. V rámci statusů pracujeme se dvěma druhy statusů: defaultně definovanými a zákaznicky definovanými.

· Defaultně definované statusy mají obecně platné určení a interpretaci v rámci průchodu workflow

0 počátek workflow

30 workflow ukončené schválením dokumentu

–1 workflow ukončené zamítnutím

-99 status je alokován pro nestandardní ukončení workflow (status je definován na úrovni workflow dokumentu)

· Zákaznicky definované statusy (1-29) si definuje dle svých potřeb zákazník. Chování workflow není svázáno s číslem tohoto zákaznického statusu, ale parametrizací kroku na Adm14.

Workflow s elektronickým podpisem může pro schvalovací i podpisové kroky využít definici zákaznických statusů 1-29. Určení, že jde o podpis, nikoliv schválení, je pak definováno na samotném kroku (viz Záložka Kroky workflow: Parametrizace podpisu na úrovni kroku workflow)

Typy dokumentů řízených daným workflow

Jaké dokumenty se řídí příslušným workflow je definováno na záložce Typ dokumentů. Zde je potřeba uvést všechny typy dokumentů, na které se má dané workflow aplikovat. Pro každou kombinaci podepisujících nebo požadovaného typu podpisu je potřeba definovat samostatnou definici workflow (viz Typ dokumentu (Jpc01)).

2.2.2.2 Záložka Kroky workflow: Parametrizace podpisu na úrovni kroku workflow

Na úrovni kroku workflow je pro podpisový krok podporováno následující nastavení Typu schválení:

· Podepsat zaměstnanec (Adm14: Pravidlo příjemce = 5 – Osoba, o níž workflow je): podporováno nastavení Typu schvalování = 1 - Schválení 1.primárním příjemcem z min. kroku.

· Podepsat: Typ schvalování = 1 - Schválení 1.primárním příjemcem z min. kroku nebo 11 - Schval. více prim. a sek. příjemci z min. kroku (postačí, když odpoví jeden).

Pokud je pro krok s Podpisem definován Typ schválení = 11, pak když jeden z adresátů kroku spustí akci Podepsat, zahájí se proces podpisu tímto podepisujícím a po úspěšném dokončení podpisu dokumentu se worflow posune na další krok. Pokud by došlo k situaci, kdy jiný adresát kroku spustí akci Podepsat v době, kdy již byl dokument k podpisu odeslán do podpisového modulu jiným adresátem kroku a podpis nebyl v podpisovém modulu dokončen, pak EGJE vyhodnotí, že dokument již byl k podpisu odeslán jiným podepisujícím a informuje o této skutečnosti uživatele s dotazem, zda si chce převzít podpis dokumentu. Pokud potvrdí, že si chce převzít podpis dokumentu, pak bude ukončen podpisový proces stávajícího podepisujícího (smaže v podpisovém modulu dokument čekající na jeho podpis) a zašle dokument k podpisu novým podepisujícím. Pokud zamítne převzetí dokumentu k podpisu, pak podpis dokumentu na daném kroku zůstává na stávajícím podepisujícím.

Z hlediska akceptace dokumentu podpisem dále specifikujeme:

· Elektronický podpis = Ano, pokud jde o podpisový krok

· Kód podpisového pole: uvedeme kód podpisového bloku (podpisové makro) z dokumentu, který odpovídá podepisujícímu na daném kroku

· Typ podpisu: aktuálně implementován prostý podpis (10 – Elektronický podpis prostý) a podpis certifikovaný (14 – Podpis certifikátem)

· Dokument odeslat zaměstnanci na kontakt typu: tento parametr nastavujeme na posledním kroku workflow (přechod na stav 30). Jde o určení typu e-mailu, na který má být dokument zaměstnanci po schválení odeslán (pokud je na úrovni workflow odesílání na e-mail zaměstnance požadováno: Režim odeslání dokumentu = 10 – Odeslat automaticky po schválení dokumentu nebo 20 – Odeslat akcí uživatele).

· Režim odeslání zástupci: V rámci zpřístupnění workflow na formuláři Wflow je pro zástupce aplikováno nastavení parametru Režim odeslání zástupci na kroku workflow (Adm14). Pokud na kroku, kde schvalovatelem je zastupovaná osoba, nastaveno Režim odeslání zástupci = 0 – Neodesílat, pak nebude zástupci odeslána notifikace a workflow nebude zástupci na daném kroku zpřístupněno na formuláři Wflow.

2.2.2.3 Parametrizace obsahu e-mailu

Pokud je požadováno odeslat schválený/podepsaný dokument zaměstnance na e-mail, pak předmět a tělo e-mailu je definováno následně:

· Předmět e-mailu: Název workflow (Adm14), v rámci kterého je dokument schvalován/podepisován

· Zpráva e-mailu: definujeme na Adm33 pro krok workflow = 500 na záložce Předloha oznámení. Možno využít standardní makra dokumentu.

V rámci Adm33, úlohy 500 pak nastavujeme další parametry pro úlohu odeslání dokumentu na e-mail

· Pokud chceme dokument odeslat i na e-mail dalšího příjemce mimo zaměstnance, jehož se dokument týká, pak můžeme definovat pravidla příjemců

o Číslo pravidla primárního příjemce: e-mail se odešle pravidlem určenému příjemci na typ e-mailu definovaný na Adm14 v rámci posledního kroku workflow v poli Dokument odeslat zaměstnanci na kontakt typu

o Číslo pravidla sekundárního příjemce, Číslo pravidla dalšího příjemce: e-mail se odešle pravidlem určenému příjemci na typ e-mailu definovaný na Adm33 v poli Zaslat e-mail sek. a dalšímu příjemci

o Zaslat e-mail odesílateli: defaultně se odesílá na typ e-mailu 31 – E-mail v zaměstnání

o Zaslat zprávu také na e-maily (Oznámení/schválení): na tyto příjemce je odeslána jen notifikace, není přiložen dokument

· Režim odeslání zástupci: Nastavení odesílání dokumentu na zástupce zaměstnance: pokud nechceme, aby dokument byl v době, kdy je zaměstnanec zastupován, zaslán na jeho zástupce, pak je potřeba Režim odeslání zástupci nastavit na hodnotu = 0 – Neodesílat

2.2.3 Spuštění workflow

Na formulář Rtf21, resp. Rtf22 se ze šablony dokumentu vygeneruje dokument pro zaměstnance, a to s požadavkem na uložení dokumentu na Opv31 pod konkrétním typem dokumentu.

Workflow oběhu dokumentu se pak standardně spouští v rámci Opv31 nebo Dok01, a to prostřednictvím akce Odeslat ke schválení, resp. Spustit WFL. Workflow lze spustit pro dokumenty:

· ve stavu 0 – Koncept: pro dokumenty typu (uchaz_dok_typ) s definovaným režimem schvalování Kód 3 = 2 - Musí být schvalovaný/podepisovaný

· ve stavu nedefinováno: pro dokumenty typu (uchaz_dok_typ) s definovaným režimem schvalování Kód 3 = 1 - Může a nemusí být schvalovaný/podepisovaný

2.2.4 Akceptace dokumentu v rámci workflow

Standardní workflow oběhu dokumentu umožnuje akceptaci dokumentu schválením (akce Schválit/Potvrdit seznámení). Komponenta elektronického podpisu rozšiřuje akceptaci dokumentu podpisem (Akce Podepsat/Podepsat zaměstnanec) a dále umožňuje odeslání podepsaného dokumentu na e-mail zaměstnance (Akce Odeslat dokument). Akce Podepsat/Podepsat zaměstnanec

2.2.4.1 Akce Podepsat/Podepsat zaměstnanec

Pokud je daný krok workflow nastaven jako podpisový, (Adm14 - nastavení kroku workflow: Podpis = Ano a je vybrán Typ podpisu) pak v rámci workflow se uživateli, který je podepisujícím na daném kroku, nabízí akce Podpis, resp. Podpis zaměstnanec v případě, že podepisujícím je zaměstnanec (tedy osoba o které workflow je).

Pokud je pro danou organizaci nebo správní jednotku nastaveno více podpisových prostředků pro požadovaný typ podpisu (zákazník je např. integrován na dva poskytovatele prostého elektronického podpisu), uživatel si může vybrat podpisový prostředek. Tato volba může být pro zaměstnance omezena na jeden defaultní podpisový prostředek (formulář Adm21, viz. API podpisového modulu a podpisové prostředky ).

Spuštěním akce podpisu se dokument odešle do podpisového modulu a uživatel je přesměrován na podpisovou stránku. Po dokončení podpisu je přesměrován zpět do HR portálu. EGJE si stáhne podepsaný dokument a posune workflow na další krok. Dokument s alespoň jedním podpisem má pak nastaven atribut Podepsáno = Ano (záložka Detail).

Ve vybraných situacích může dojít k tomu, že dokument je odeslán k podpisu podepisujícím A, ale ten nepodepíše ihned a poté na stejném podpisovém kroku chce podepsat podepisující B. K této situaci může dojít např. u kroku s více podepisujícími (Typ schvalování = 11 - Schval. více prim. a sek. příjemci z min. kroku (postačí, když odpoví jeden) nebo u zástupu. V těchto případech je nový podepisující informován dialogovým oknem o tom, že dokument již byl k podpisu odeslán podepisujícím A. Podepisující B si může dokument převzít k podpisu, a pak je dokument zaslán k podpisu do PM pro nového podepisujícího, nebo odmítne převzít a pak dokument čeká na podpis podepisujícího A.

Pokud bychom chtěli nastavit podpis dokumentů zaměstnanci do režimu, kdy zaměstnanci podepisují dokumenty u svého nadřízeného nebo personalisty, pak toto je možno parametrizovat pomocí speciálních objektových práv:

· Na zaměstnaneckých profilech omezíme přístup k akci Podepsat zaměstnanec pomocí objektového práva Opv31omezPodpisVlastni. Právo neovlivňuje přístupnost akce Zamítnout, tu bude mít zaměstnanec přístupnou.

· Na profilech uživatelů, kteří mají být pověřeni podepisovat dokumenty se zaměstnanci a spouštět tak akci Podepsat zaměstnanec zástupně, je potřeba nastavit na profil objektové právo Opv31pravoPodpisZam. Toto objektové právo na daném kroku podpisu dokumentu zaměstnancem zpřístupní k zástupnému spuštění i akci Zamítnout (pokud je tato akce na kroku v rámci Adm14 definována).

V případě, kdy je akce podpisu spuštěna na daném kroku opakovaně a dokument již byl do podpisového modulu odeslán, pak dle aktuálního stavu dokumentu dojde k přesměrování na podpisovou stránku (dokument čeká na podpis), nebo pokud byl dokument v podpisovém modulu zamítnut, pak workflow zůstává na daném kroku a uživatel je o této skutečnosti informován.

V případě zamítnutí podpisu z důvodu chyby v dokumentu bude workflow stornováno (Akce Storno dokumentu ) uživatelem s příslušným oprávněním (Opv31statusAdmin), dokument bude opraven a následně dojde k novému spuštění workflow. Pokud jde o zamítnutí z důvodu, že podepisující nechce dokument podepsat, pak na daném kroku workflow v HR portálu zvolí akci Zamítnout a tím je workflow ukončeno zamítnutím (status = -1).

2.2.4.2 Akce Odeslat dokument

Akce je přístupná uživateli s příslušným oprávněním Opv31pravoOdeslatNaMail a to v případě:

· Jde o workflow s definovaným požadavkem na odeslání dokumentu na e-mail zaměstnance (Adm14: Režim odeslání dokumentu = 10 – Odeslat automaticky po schválení dokumentu nebo 20 – Odeslat akcí uživatele)

· Workflow je ve stavu, kdy bylo ukončeno schválením/podepsáním všemi účastníky (status dokumentu = 30).

Odeslání dokumentu na e-mail je evidováno na záložce Detail v atributu Odesláno zaměstnanci = Ano a auditováno na záložce Audit odeslání dokumentu.

2.2.5 Akce pro uživatele se speciálním oprávněním

Pokud se dokument v průběhu workflow dostane do nestandardního stavu, který neumožňuje pokračovat dále v rámci definovaného workflow, k vyřešení je možné využít některé z akcí určených pro uživatelé se speciálním oprávněním..

2.2.5.1 Akce Storno dokumentu

Tato akce je aktivní pro uživatele se speciálním oprávněním Opv31statusAdmin za situace, kdy byl dokument odeslán k podpisu do podpisového modulu a ještě nebyl nahrán podepsaný zpět do EGJE (v této době je tzv. „blokován“ pro zpracování v EGJE, příznak Blokováno = Ano). Jde o prostředek řešení nestandardní situace, kdy např. při podpisu bylo zjištěno, že dokument obsahuje chybu a je potřeba jej opravit a znovu zahájit podpisový proces.

Spuštěním akce Storno dokumentu se workflow nastaví do stavu 0 – Koncept, který umožňuje dokument vyměnit. Zároveň akcí Storno dokumentu dojde k odblokování dokumentu a dokument v EGJE již není možné aktualizovat dokumentem z podpisového modulu. Po opravě a výměně dokumentu může být workflow znovu spuštěno.

2.2.5.2 Akce Odblokovat

Akce je přístupná uživateli s oprávněním DokOdblokace. Pokud je dokument odeslán k podpisu do podpisového modulu, pak do okamžiku nahrání podepsaného dokumentu zpět do EGJE je označen jako blokován (Blokováno = Ano) a takový dokument nemůže být na straně EGJE aktualizován. Uživatel s právem DokOdblokace může dokument odeslaný k podpisu do podpisového modulu odblokovat a na daném kroku odeslat dokument k podpisu znovu. Jde např. o řešení situace, kdy v PM došlo omylem ke smazání dokumentu a chceme na daném kroku poslat k podpisu znovu.

2.2.5.3 Akce Ukončit workflow

Akce je přístupná uživateli s oprávněním Opv31statusAdmin. Podmínkou je, že dokument je ve stavu zpracování (status schválení dokumentu je ve stavech 1-29) a dané workflow dokumentu má definován status [-99] na Adm14. Pokud dojde k ukončení workflow dokumentu touto akcí, pak status dokumentu bude nastaveno = -99. Tato akce je určena primárně k nestandardnímu ukončení zpracování dokumentů např. u dokumentů zájemců o zaměstnání, kterým byly zaslány dokumenty k podpisu do PM, ale bez reakce z jejich strany.

2.2.6 Formuláře zpřístupňující workflow oběhu dokumentu

Workflow oběhu dokumentů je pro uživatele dostupné na 3 formulářích:

· Opv31 Dokumenty PV

· Pkz01 Personální karta zaměstnance a zde záložka Dokumenty PV, která je přístupná pouze s objektovým právem Pkz01dokumenty

· Wflow

Na formuláři Opv31 a v rámci záložky Dokumenty PV na Pkz01 lze pro omezení přístupů k dokumentům v režimu schvalování (tedy s vyplněným statusem schvalování dokumentu) využít nová řádková objektová práva, která dále omezí filtrování záznamů dle stavu schvalování dokumentu (viz Objektová práva k záznamům dokumentů).

Na formuláři Wflow zůstává standardní nastavení, kdy uživatel vidí všechna workflow, na kterých je adresátem, tj. schvalovatelem/podepisujícím.

Dostupnost akcí spojených s podpisem dokumentu na jednotlivých formulářích*

Formulář	Podepsat/Podepsat zaměstnanec	Odeslat na e-mail	Storno dokumentu
Opv31	ANO/ANO, včetně zástupného spuštění akce Podepsat zaměstnanec	ANO	ANO
Pkz01\ Dokumenty PV	ANO/ANO, včetně zástupného spuštění akce Podepsat zaměstnanec	ANO	NE
Wflow	ANO/NE, bez zástupného spuštění akce Podepsat zaměstnanec	ANO	NE

*za podmínky přidělení příslušného objektového práva k akci na profilu uživatele

Uživatelé se speciálním oprávněním (fSeiad, případně fPodpisMimoHRP a Opv31StatuAdmin u atributů relevantních pro tato oprávnění) mají na formulářích Dokumentů PV dostupné k náhledu rozšiřující informace k odeslání dokumentů do PM, tak k auditu odeslání podepsaného dokumentu na e-mail zaměstnance a auditu úkonů provedených v rámci Akcí pro uživatele se speciálním oprávněním.

Podpis a odeslání dokumentu k podpisu do PM

· Elektronicky podepsáno (Seznam dokumentů, záložka Detail): pokud dokument obsahuje alespoň jeden podpis, pak Elektronicky podepsáno = Ano

· Dokument je odeslán k podpisu do PM.

o Záložka Detail, atribut Blokováno: Pokud je dokument odeslán k podpisu do PM a čeká zde na podpis (tzn. v tuto dobu je „blokován“ pro zpracování v EGJE), pak Blokováno =Ano.

o Dokumenty je zároveň možné odfiltrovat jen na dokumenty odeslané k podpisu do PM (filtr nad Dokumenty PV: Jen odeslané k podpisu)

o Režim zpracování: Uvádí, v jakém režimu je dokument odeslán k podpisu do PM (1 – Základní režim, 10 – Podpis mimo HRP)

Odeslání podepsaného dokumentu na e-mail zaměstnance

· Odesláno zaměstnanci (Seznam dokumentů, záložka Detail): Pokud byl podepsaný dokument odeslán zaměstnanci na e-mail, pak Odesláno zaměstnanci = Ano

· Odeslání dokumentu na e-mail zaměstnance je auditováno na záložce Audit odeslání dokumentu na e-mail

Pokud v rámci průběhu workflow dokumentu došlo k provedení akce/í se speciálním oprávněním (Akce pro uživatele se speciálním oprávněním) pak tyto jsou auditovány na záložce Audit akcí mimo workfklow.

2.3 Kontrola požadovaného termínu akceptace

U některých typů dokumentů je požadováno, aby byly podepsány do definovaného data s vazbou na počátek jejich platnosti (datum účinnosti). Cílem rozšíření workflow akceptace dokumentů o kontrolu dodržení požadovaného termínu akceptace je umožnit pro vybrané typy dokumentů nastavit proces tak, aby nebylo možné akceptovat (podepsat/schválit/zamítnout) definované typy dokumentů, pokud již došlo k překročení tohoto termínu (= DEADLINE akceptace dokumentu).

Typickým nastavením jsou následující dva režimy akceptace dokumentu:

· Režim “půlnoc před datem účinnosti“: povolený datum akceptace < Platnost od; DEADLINE pro akceptaci dokumentu = den předcházejí datu Platnost od, čas 23:59

· Režim “půlnoc data účinnosti“: povolený datum akceptace <= Platnost od; DEADLINE pro akceptaci dokumentu = Platnost od (čas 23:59)

2.3.1 Parametrizace kontroly DEADLINE akceptace dokumentu

Kontrola DEADLINE pro akceptaci dokumentu je parametrizována na Adm70 prostřednictvím konfigurační položky 360 - Dokumenty PV: Parametrizace výpočtu deadline akceptace.

Konfigurační položka umožňuje definovat počet dní pro výpočet DEADLINE s vazbou na Platnost od dokumentu. Kontrola DEADLINE se návazně pro daný typ dokumentu aplikuje pro všechny akce workflow oběhu dokumentů, které jsou spojeny s akceptací dokumentu a je tak potřeba při jejich spuštění vyhodnotit, zda lze, s ohledem na datum a čas spuštění akce, další zpracování dokumentu v rámci workflow povolit.

Tato konfigurační položka není standardně přístupná pro všechny zákazníky, ale je uvolňována k aktivaci jen pro zákazníky s placenou funkcionalitou kontroly platnosti dokumentu. Aktivaci konfigurační položky lze provést následně:

· Na formuláři Adm70 v navigačním seznamu zatrhnout filtr Povoleno k použití

· Přejít na editaci položky 360 - Dokumenty PV: Parametrizace výpočtu deadline akceptace

· Na hlavičce parametru aktivovat položku do užívání akcí Přijmout položku a nastavit hodnotu pole !Platný záznam na hodnotu = 1 – Používáno.

Způsob nastavení a výpočtu DEADLINE akceptace dokumentu: hodnota parametru 30 - Dny uvádí počet dní, které se připočtou k datu Platnost od. DEADLINE je definován dnem a časem (DD.MM.YYYY MM:SS) a čas je vždy 23:59 daného dne. Příklad nastavení dvou výše uvedených režimů:

· Režim “půlnoc před datem účinnosti“: DEADLINE = Platnost od (CETPVDOK.PLATNOST_OD) - 1 den, tj. dokument je možné akceptovat do půlnoci dne před datem Platnost od. Tzn. Pokud platnost od = 1.7.2025, pak DEADLINE akceptace dokumentu = 30.6.2025 23:59. Hodnota parametru 37 – Dny (i záporné, celočíselné) = -1

· Režim “půlnoc data účinnosti“: DEADLINE = Platnost od (CETPVDOK.PLATNOST_OD), tj. dokument je možné akceptovat do půlnoci dne Platnost od. Tzn. Pokud Platnost od = 1.7.2025, pak DEADLINE akceptace = 1.7.2025 23:59. Hodnota parametru 37 – Dny (i záporné, celočíselné) = 0

Počet dní pro výpočet DEADLINE pro jednotlivé typy dokumentů je možno nastavit na úrovni správní jednotky, nebo organizace, případně bez vazby na organizační strukturu a pak platí pro všechny organizace a správní jednotky.

2.3.2 Místa aplikace kontroly DEADLINE v rámci workflow dokumentu

Pokud je pro daný Typ dokumentu a správní jednotku nebo organizaci zaměstnance, k němuž se daný dokument váže, definováno nastavení konfigurační položky 360 - Dokumenty PV: Parametrizace výpočtu deadline akceptace, pak se v průběhu celého workflow dokumentu ověřuje, zda již nedošlo k překročení tohoto data a času DEADLINE akceptace. Tato kontrola probíhá:

· Při spuštění akce uživatelem v průběhu workflow. Konkrétně jde o tyto akce: Spuštění workflow dokumentu a akceptační akce v průběhu workflow dokumentu (Schválení/Podpis/Zamítnutí).

· V rámci běhu plánované úlohy, která v definovaných intervalech ověřuje, zda již u některých dokumentů nevypršela lhůta pro akceptaci dokumentu. Jde o Úloha 45 - Ukončení WFL dokumentů neakceptovaných v požadovaném termínu

· Pokud je u dokumentu požadováno kontrolovat požadovaný termín akceptace, pak při odeslání dokumentu k podpisu do PM je zaslána informace o počtu dní, po které může být dokument podepsán. Poté dojde k expiraci dokumentu v PM. Výjimkou je v případě PM Signi situace, kdy podepsat lze maximálně daný den. V tomto případě PM Signi nenastavuje datum expirace. Ošetření této situace viz Integrace na PM Signi a DEADLINE akceptace dokumentu.

2.3.3 Proces ukončení workflow dokumentů z důvodu DEADLINE akceptace dokumentu

Pokud je u dokumentu vyhodnoceno, že došlo k překročení DEADLINE akceptace, pak v rámci ukončení workflow dojde k následujícím krokům:

· Workflow je ukončeno nastavením statusu dokumentu = -99 a nastavením příznaku Vypršel termín k akceptaci (Opv31 – záložka Detail).

· Pokud v době ukončení byl dokument odeslán k podpisu do PM, pak je dokument v EGJE odblokován (příznak Blokováno = 0).

· Nestandardní ukončení workflow z důvodu DEADLINE (změna statusu na -99, nastavení příznaku Vypršel termín k akceptaci a případně nastavení Blokováno = 0) je zalogováno do Auditu akcí mimo workflow.

· Pokud je nastavena notifikace k ukončení akceptace dokumentu z důvodu DEADLINE (Adm33: akce workflow 501), pak dojde k odeslání notifikace dle nastavení této akce workflow.

2.3.4 Úloha 45 - Ukončení WFL dokumentů neakceptovaných v požadovaném termínu

Plán spuštění úlohy je definován n a Adm53. V rámci úlohy lze parametrizovat

· Zasílání standardního chybového protokolu pomocí parametrů

o r_send4error2ext Odeslat protokol na e-mail

o r_sender4err_level Minimální úroveň chyby pro odeslání protokolu

o max_protocols Max. počet uložených protokolů

· Zasílání reportu workflow dokumentů ukončených v průběhu daného běhu úlohy. Report obsahuje seznam dokumentů, jejichž akceptační workflow bylo ukončenu z důvodu překročení DEADLINE akceptace dokumentů. Seznam takto ukončených workflow obsahuje informace o dokumentu (ID dokumentu, Osobu-PV, SJ, Typ dokumentu, Název dokumentu), DEADLINE dokumentu, stav dokumentu v PM (pokud je dokument v době kontroly odeslán k podpisu), stav workflow dokumentu v EGJE a datum a čas ukončení workflow dokumentu z důvodu DEADLINE. Parametry reportu:

o r_odesilat_report_ukoncenych_wfl Odesílat report ukončených workflow

o r_send_ukoncena_wfl Odeslat report ukončených workflow na mail

o r_nazev_soub_ukoncena_wfl Název souboru

Úloha postupně prochází nezahájená nebo otevřená workflow dokumentů, u kterých je požadována kontrola DEADLINE a ověřuje, zda již nedošlo k překročení požadovaného data akceptace dokumentu. Pokud ano, pak v případě, kdy dokument není v době běhu úlohy odeslán do PM k podpisu, workflow dokumentu ukončí. Pokud je dokument v průběhu kontroly odeslán k podpisu do PM, kde čeká na podpis, nebo již byl podepsán/zamítnut, ale tato informace nebyla ještě předána do EGJE, pak dokument bude zpracován dle statusu dokumentu v PM Signi, viz Integrace na PM Signi a DEADLINE akceptace dokumentu

2.3.5 Adm33: Akce workflow 501 - Ukončení WFL dokumentu z důvodu vypršení termínu pro akceptaci

Akce workflow 501 slouží k parametrizací notifikací v případě, kdy dojde k nestandardnímu ukončení workflow dokumentu z důvodu překročení DEADLINE akceptace dokumentů. Pokud bude tato akce workflow 501 nastavena na Adm33, pak bude aktivní odesílání notifikací o ukončení workflow dokumentu z důvodu překročení DEADLINE.

Nastavení Úlohy 501 - Ukončení workflow dokumentu z důvodu vypršení termínu k akceptaci

· ADRESÁTI: dle nastavení pravidel příjemců a zasílání notifikace. Pro vyhodnocení adresátů notifikace relevantních pravidel příjemců, které se vyhodnocují s vazbou na Osobu, o níž workflow je, platí že Osoba, o níž workflow je = osoba, jíž se týká dokument schvalovaný/podepisovaný v rámci workflow oběhu dokumentů, které je ukončováno z důvodu DEADLINE (tedy zaměstnanec, na kterého je daný dokument navázán na Opv31)

· PŘEDMĚT E-MAILU: Název workflow kroku (předmět e-mailu)

· TĚLO E-MAILU: Předloha oznámení. V rámci definice oznámení lze využit standardní makra definovaná pro zaměstnance, kterého se dokument z workflow oběhu dokumentu týká (např. %JMENO_CELE%, %OSCPV%, atd. ) a makra pro atributy dokumentů z WFL oběhu dokumentu (např. %SOUBOR%, %TYP_DOKUMENTU%)

2.3.6 Integrace na PM Signi a DEADLINE akceptace dokumentu

U dokumentu s požadovanou kontrolou DEADLINE akceptace je při odeslání dokumentu k podpisu do PM zaslána informace o počtu dní, po které je možno dokumentu podepsat. Poté dojde v PM k expiraci dokumentu. Výjimkou je v případě PM Signi situace, kdy dokument lze podepsat maximálně v daný den, kdy je dokument do PM k podpisu odeslán. V tomto případě PM Signi nenastavuje datum expirace. Toto situaci je potřeba ošetřit následně: nastavení úlohy na Úloha 45 - Ukončení WFL dokumentů neakceptovaných v požadovaném termínu na pravidelné spouštění každý den po půlnoci. Tato úloha pak ukončí v EGJE workflow dokumentů, kde došlo k překročení DEADLINE akceptace.

V případě dokumentu, kde není požadováno kontrolovat DEADLINE akceptace, se v PM Signi pro určení data expirace dokumentu aplikuje nastavení daného workspace.

Pokud je dokument odeslán k podpisu do PM a zároveň již došlo k vypršení DEADLINE a na straně EGJE dojde ke znovu spuštění podpisové akce uživatelem nebo dokument je zpracováván úlohou Úloha 45 - Ukončení WFL dokumentů neakceptovaných v požadovaném termínu, pak dojde k vyhodnocení dalšího postupu zpracování dokumentu na základě statusu dokumentu v PM Signi:

· Completed (= podepsáno): podepsaný dokument bude stažen a workflow dokumentu v EGJE bude posunuto na další krok.

· Rejected (= zamítnuto): dokument bude zamítnut i v EGJE (status dokumentu = -1).

· Jestliže je v PM dokument ve statusech Deleted, Expired nebo Pending, znamená to, že dokument nebyl v PM v požadovaném termínu pro akceptaci podepsán ani zamítnut a workflow dokumentu bude ukončeno z důvodu překročení DEADLINE akceptace ( Proces ukončení workflow dokumentů z důvodu DEADLINE AKCEPTACE) .

V případě zpracování dokumentů podepsaných nebo zamítnutých v PM Signi dochází v EGJE ke stažení podepsaného dokumentu, resp. jeho zamítnutí a návazně k posunu workflow. V tomto případě je posun workflow standardně zalogován na záložce Workflow (Opv31, Pkz01) a v případě posunu workflow v rámci běhu úlohy je uveden v poli Rozhodl uživatel dle nastavení úlohy na Adm53 (id_toso_autor).

2.3.6.1 Dopad kontroly DEADLINE na úlohy pro zpracování dokumentů v rámci režimu Podpisu mimo HRP

Úloha 42 - Odeslání dokumentů v režimu podpisu mimo HRP do PM

Pokud dokument podléhá režimu kontroly DEADLINE akceptace dokumentu pak bude vyhodnoceno, zda již nedošlo k překročení tohoto termínu. Pokud ne, dokument bude úlohou odeslán do PM k podpisu. V případě překročení DEADLINE akceptace dokumentu není podmínka pro podpis splněna a dokument nebude odeslán do PM k podpisu a na straně EGJE dojde k ukončení workflow tohoto dokumentu z důvodu neakceptace v požadovaném termínu.

Úloha 41 - Úloha na stažení podepsaného dokumentu

Tato úloha neobsahuje proces vyhodnocení překročení DEADLINE akceptace dokumentu. Jestliže jsou dokumenty v PM ve statusech Completed/Rejected, znamená to, že v Signi byly podepsány/zamítnuty v požadovaném termínu a dojde ke stažení podepsaného dokumentu do EGJE resp. jeho zamítnutí v EGJE (pokud byl dokument v PM zamítnut).

V případech, kdy jsou dokumenty ve statusech Expired, Pending, Deleted, pak úloha tyto dokumenty standardně přeskakuje a nezpracovává. Pokud mezi těmito dokumenty je dokument s překročeným DEADLINE, pak tento bude zpracován v rámci běhu úlohy Úloha 45 - Ukončení WFL dokumentů neakceptovaných v požadovaném termínu

3 Alternativní režimy podpisu

Dokumentace popisuje procesy a funkcionalitu podpisů v rámci workflow oběhu dokumentů z pohledu základního režimu. Pokud je některá funkcionalita odlišná z hlediska alternativních režimů podpisů, pak je zde uveden rozdíl zpracování dokumentu v rámci alternativního režimu vůči základnímu režimu.

3.1 Základní režim podpisu vs alternativní režimy podpisu

Akce podpisu Podepsat/Podepsat zaměstnanec jsou spouštěny z HRP podepisujícím nebo v případě Podepsat zaměstnanec i uživatelem s oprávněním zástupného spuštění akce Podpisu zaměstnance (Objektová práva k akcím workflow)

Uživatel je po spuštění akce podpisu přesměrován do podpisového modulu (PM Signi), kde dokument podepíše a po podpisu v PM je přesměrován zpět do HRP EGJE a EGJE si návazně stáhne podepsaný dokument

Pokud v průběhu procesu podpisu dojde k nestandardní situaci, která způsobí, že podepsaný dokument není stažen v rámci přesměrování PM → EGJE, pak je možné toto dokončit prostřednictvím opakovaného spuštění akce Podepsat/Podepsat zaměstnanec. EGJE ověří stav dokumentu v PM a v případě podepsaného dokumentu dokument stáhne.

Režim podpisu mimo HRP má oproti základnímu režimu umožnit podpis dokumentů uživatelům, kteří nemají přístup k HRP. Může jít jak o nové nástupy, kdy tito lidé před nástupem nemají zřízen přístup k informačním systémům, včetně HRP, nebo zaměstnance s již aktivním PP, nicméně bez přístupu k HRP.

3.2 Režim podpisu mimo HRP

3.2.1 Základní předpoklady a charakteristika Režimu podpisu mimo HRP

· Režim podpisu mimo HRP je implementován pro podpisový krok s nastaveným pravidlem příjemce = 5 - osoba o níž workflow je. Z hlediska akcí na formulářích je implementováno pro akci Podepsat zaměstnanec.

· Osoby podepisující v Režimu mimo HRP musí mít v rámci evidence osob v EGJE evidován e-mail pro elektronické doručování (druh komunikace = 30 - E-mail pro elektronické doručování). Tento e-mail je odesílán do PM jako e-mail pro zasílání notifikací k dokumentu.

· K osobě bude evidována informace, že podpis dokumentů běží v režimu podpisu mimo HR portál. Tato parametrizace je na formuláři Adm11\Záložka Osoba, a zde pole Režim podpisu. Pole je přístupné pouze pro uživatele s oprávněním fPodpisMimoHRP.

· V režimu podpisu mimo HRP jsou pro daného zaměstnance zpracovány všechny dokumenty s krokem Podpisu zaměstnance, kde je daný zaměstnanec podepisujícím.

· Notifikace podepisujícímu v režimu podpisu mimo HRP

o Podepisujícímu nejsou odesílány notifikace z workflow oběhu dokumentu EGJE při přechodu na jeho podpisový krok. Podepisujícímu přijdou pouze notifikace odeslané z PM po zaslání dokumentu do PM k podpisu. Podmínkou odesílání notifikací z PM je nastavení Workspace PM na režim zasílání notifikací. (V režimu neodesílání notifikací neodchází z PM Signi k dokumentu žádné notifikace žádnému podepisujícímu. Naopak v režimu zapnutých notifikací jsou zasílány notifikace všem podepisujícím. Podepisující tak jsou e-mailem notifikováni s výzvou k podpisu dokumentu, po podpisu jim je odeslána notifikace o úspěšném podepsání dokumentu. V případě expirace dokumentu pak jsou o této skutečnosti rovněž notifikováni.)

o Odeslání podepsaného dokumentu na e-mail zaměstnance: Odeslání podepsaných dokumentů na e-mail zaměstnance nerozlišuje režim podpisu, a pokud bude nastaven režim odesílání podepsaných dokumentů na e-mail zaměstnance (Záložka Kroky workflow: Parametrizace podpisu na úrovni kroku workflow, Dokument odeslat zaměstnanci na kontakt typu, Parametrizace obsahu e-mailu), pak podepsaný dokument bude odeslán bez ohledu na režim podpisu osoby (tzn. zda je podepisující v režimu Podpis mimo HRP nebo v základním režimu podpisu)

3.2.2 Odlišnosti komunikace s PM při podpisu v režimu podpisu mimo HRP

3.2.2.1 Odeslání dokumentu k podpisu do PM

Dokumenty na kroku Podpisu zaměstnance v režimu podpisu mimo HRP budou primárně odesílány do PM úlohou 42 – Odeslání dokumentů k podpisu do PM v režimu podpisu mimo HRP. Tato úloha se nastavuje na Adm53.

Úloha 42 – Odeslání dokumentů k podpisu do PM v režimu podpisu mimo HRP

Parametry úlohy

· API (r_api): API, vůči kterému bude úloha spouštěna

· Parametry pro odeslání chybového protokolu

o Odeslat protokol na e-mail (r_send4error2ext): e-mail, na který má být odesílán chybový protokol

o Minimální úroveň chyby pro odeslání protokolu (r_sender4err_level): od jaké úrovně chyb má být zasílán chybový protokol

o Max. počet uložených protokolů (max_protocols): maximální počet uložených protokolů

Zpracování dokumentů na kroku s podpisem v režimu zaměstnance mimo HRP

· Načte se seznam dokumentů splňujících podmínky nastavení úlohy a stavu dokumentu na podpisovém kroku: dokumenty mají spuštěno workflow oběhu dokumentů (300-399), jsou na kroku podpisu zaměstnance a zaměstnanec je v Režimu podpisu mimo HRP. Dokument ještě nebyl odeslán do PM k podpisu.

· Jednotlivé dokumenty splňující podmínky pro odeslání k podpisu do PM jsou odeslány. Proces předání dokumentu k podpisu do PM odpovídá odeslání dokumentu k podpisu v základním režimu, ale s těmito odlišnostmi: nepředává se adresa pro přesměrování z PM do HRP, jako e-mail podepisujícího je vždy odesílán druh komunikace = 30 - E-mail pro elektronické doručování (v případě základního režimu je zasílán druh komunikace = 31- E-mail v zaměstnání, a pokud není vyplněn, pak druh komunikace = 30)

Ruční spuštění akce Podepsat zaměstnanec

Tento způsob odeslání dokumentu do PM k podpisu zaměstnance je využíván v základním režimu podpisu, nicméně je možné jej využít i při režimu podpisu mimo HRP. Pokud dojde k ručnímu spuštění akce Podepsat zaměstnanec v HRP pro podepisujícího, který má nastaven Režim podpisu mimo HRP (toto je v rámci daného režimu, kdy zaměstnanec nemá přístup do HRP, možné v případě uživatele se speciálním oprávněním zástupného spuštění akce Podepsat zaměstnanec, což bývá typicky HR, případně manažer zaměstnance), pak pokud:

· Dokument nebyl ještě odeslán k podpisu do PM: proběhne jeho odeslání do PM a přesměrování na podpisovou stránku dokumentu. Oproti základnímu režimu ale v režimu podpisu mimo HRP jako e-mail podepisujícího je zasílán druh kontaktu = 30 - Email pro elektronické doručování ( v případě základního režimu se odesílá primárně 31 -E-mail v zaměstnání a pokud tento není vyplněn, tak 30 - Email pro elektronické doručování ) a po podpisu v PM nedojde k přesměrování na stránky HRP.

· Dokument již byl odeslán k podpisu do PM: Pak stejně jako u základního režimu dojde k ověření stavu dokumentu v PM. Pokud dokument byl již podepsán (status Completed), pak stejně jako v základním režimu si EGJE stáhne podepsaný dokument. Pokud je dokument v PM ve stavech Deleted, nebo Rejected, pak proběhne zpracování na straně EGJE stejným způsobem jako u základního režimu podpisu. V případě statusu Expired ale na rozdíl od základního režimu, kdy dochází k opakovanému odeslání dokumentu k podpisu do PM, v režimu podpisu mimo HRP může být dokument odeslán k podpisu do PM znovu jen pokud je akce Podepsat zaměstnanec spuštěna uživatelem s oprávněním zástupného spuštění akce Podepsat zaměstnanec a při spuštění je uživatelem potvrzeno, že má být dokument odeslán k podpisu znovu.

3.2.2.2 Stažení podepsaného dokumentu z PM do EGJE

V rámci základního režimu je stažení podepsaného dokumentu zajištěno primárně v rámci přesměrování podepisujícího po podpisu. Pokud z nějakého důvodu nedojde k přesměrování (např. jde o podepisujícího registrovaného v PM, v průběhu přesměrování dojde k timeout apod.) a návaznému stažení podepsaného dokumentu do EGJE, je toto možno vyvolat z EGJE znovuspuštěním akce Podepsat/Podepsat zaměstnanec. EGJE ověří stav dokumentu, a pokud byl podepsán, provede jeho stažení a návazné smazání v PM. Tato možnost stažení podepsaného dokumentu znovuspuštěním akce Podepsat zaměstnanec je možná i v režimu podpisu mimo HRP.

V případě režimu podpisu mimo HRP bude stažení podepsaného dokumentu zajištěno primárně automatickou úlohou 41 – Stažení podepsaných dokumentů z PM. Tato úloha se nastavuje na Adm53.

Úloha 41 – Stažení podepsaných dokumentů z PM

Parametry úlohy

· API (r_api): API, vůčikerému bude úloha spouštěna

· Parametry pro odeslání reportu nezpracovaných dokumentů v PM (úloha přeskakuje zpracování dokumentů, které se v PM dostaly do nestandardního statusu zpracování: Deleted, Expired). Informace o těchto dokumentech je možno zaslat na e-mail, pokud bude parametrizováno:

o Reportovat statusy (r_reported_status_dok ): výčet statusů, pro které má být report zasílán (Deleted a/nebo Expired)

o Odeslat report nezpracovaných dokumentů na mail (r_send_nezprac_dok: e-mail, na který má být odeslán report se seznamem dokumentů, které jsou v PM v definovaných statusech

o Název souboru (r_nazev_soub_nezprac_dok): Název souboru se seznamem nezpracovaných dokumentů

· Parametry pro odeslání chybového protokolu

o Odeslat protokol na e-mail (r_send4error2ext): e-mail, na který má být odesílán chybový protokol

o Minimální úroveň chyby pro odeslání protokolu (r_sender4err_level): od jaké úrovně chyb má být zasílán chybový protokol

o Max. počet uložených protokolů (max_protocols): maximální počet uložených protokolů

Úloha v definovaných časech projde všechny dokumenty, které byly odeslané k podpisu do PM v alternativním režimu zpracování a ověří jejich aktuální status v PM.

· Dokument již byl v PM podepsán (status Completed). Podepsaný dokument bude stažen do EGJE a to stejným procesem jako v základním režimu: EGJE si stáhne podepsaný dokument, posune workflow na další krok a provede smazání dokumentu v PM Signi. V rámci zpracování daného kroku v logu Workflow bude jako Rozhodl uveden uživatel definovaný v parametrizaci úlohy na Adm53 v parametru úlohy Osoba – autor (id_toso_autor).

· Dokument byl v PM zamítnut (status Rejected). Dokument bude zamítnut i v EGJE.

· Dokument v PM vyexpiroval (status Expired) nebo byl smazán (Deleted): zpracování dokumentu se přeskočí, v rámci parametrizace úlohy je možné nastavit reportování takových dokumentů a následně zajistit ruční ukončení workflow dokumentu v EGJE (Akce pro uživatele se speciálním oprávněním)

4 Integrace EGJE na podpisový modul

4.1 Výchozí předpoklady řešení integrace

Jeden dokument v EGJE může mít založeno N záznamů dokumentu v podpisovém modulu: každý podpis na dokumentu je samostatným procesem podpisu, který začíná odesláním dokumentu do podpisového modulu, kde je založen jako nový záznam souboru dokumentu, který je podepsán osobou odpovědnou za podpis na daném kroku workflow. Podpisový proces na daném kroku je ukončen předáním dokumentu s podpisem zpět do EGJE. Pro dokument s N podpisy je při základním průchodu podpisovým workflow založeno v podpisovém modulu N záznamů dokumentu.

Dokument může v rámci podpisového procesu od okamžiku zaslání k podpisu po jeho zprocesování v podpisovém modulu nabývat těchto stavů

Stav	Popis
Čeká na podpis (Pending)	Čeká na podpis: dokument je dostupný podepisujícímu k podpisu/zamítnutí na definované URL a to do doby jeho podpisu/zamítnutí podepisujícím nebo do doby vypršení expirační lhůty
Odmítnuté (Rejected)	Dokument byl podepisujícím zamítnut
Uzavřené (Completed)	Dokument byl podepisujícím podepsán
Expirované (Expired)	Dokument vyexpiroval
Smazané (Deleted)	Dokument byl smazán

V rámci workflow EGJE je každý podpis řešen v samostatném kroku workflow a jeden podpisový krok workflow EGJE tak odpovídá několika krokům podpisového workflow v podpisovém modulu (viz stavy výše). Při odeslání dokumentu k podpisu do podpisového modulu je dokument v EGJE zablokován, a to do doby zpětného nahrání dokumentu s podpisem. Zároveň v rámci podpisového procesu, tj. poté, co byl dokument odeslán k podpisu a nebyl ještě vrácen zpět do EGJE podepsaný, může dojít na straně EGJE k přerušení tohoto podpisového procesu a to:

· zamítnutím dokumentu

· nestandardním administrátorským zásahem do workflow v případě požadavku na opravu dokumentu

V případě přerušení procesu podpisu ve výše uvedených případech dojde na straně EGJE k odblokování dokumentu a v tomto případě již není možné importovat dokument z podpisového modulu zpět.

4.1.1 Nastavení workspace Signi pro Režim podpisu mimo HRP

Pokud podpisy Dokumentů PV mají mít aktivní podepisování zaměstnance v režimu Podpis v režimu mimo HRP, pak je potřeba s vazbou na odesílání notifikací nastavit workspace Signi na odesílání notifikací.

· V režimu neodesílání notifikací neodchází z PM Signi k dokumentu žádné notifikace žádnému podepisujícímu.

· Naopak v režimu zapnutých notifikací jsou zasílány notifikace všem podepisujícím. Podepisující tak jsou e-mailem notifikováni s výzvou k podpisu dokumentu, po podpisu jim je odeslána notifikace o úspěšném podepsání dokumentu. V případě expirace dokumentu pak jsou o této skutečnosti rovněž notifikováni.

4.2 Registrace v Signi a podpisové workflow

Zákazník si u společnosti Signi může zřídit několik tzv. workspace. Pro integraci EGJE a Signi je potřeba mít založen právě 1 workspace, který je určen výhradně pro zpracování podpisu dokumentů z EGJE.

Workspace je registrován na vlastníka (e-mail). V případě workspace pro integraci na EGJE je zřizovatel (vlastník) workspace veden pod admin účtem pro integraci. Tento účet vstupuje na straně EGJE do několika procesů:

· Jde o účet, pod kterým jsou metody REST API volány (Adm55\API: Přístupový účet)

· V rámci metody odesílající dokument k podpisu do Signi (POST Create contract) je tento e-mail plněn v části dat Navrhovatele (Proposer)

Každý uživatel se může registrovat do více workspace a může si založit i vlastní workspace. Dokumenty zákazníka jsou v Signi uloženy v jedné DB, a dle případné registrace podepisujícího do některého workspace, je pro něj dokument dostupný ve workspace, kde je registrován – workspace je tedy něco jako filtr nad dokumenty dané společnosti.

Z hlediska podpisu je odlišný proces pro registrovaného podepisujícího a neregistrovaného. Zde hraje klíčovou roli e-mail, pod kterým je uživatel registrován v Signi a v EGJE. EGJE odesílá k podepisujícímu e-mail evidovaný na Osobě v kontaktech. Primárně načte e-mail typu 31 – E-mail v zaměstnání, a pokud tento není vyplněn, pak e-mail typu 30 – E-mail pro elektronické doručování.

· Registrovaný podepisující

o zaměstnanec je v Signi registrován pod stejným e-mailem jako je e-mail, který EGJE odesílá k podepisujícímu do Signi při podpisu dokumentu (v rámci metody POST Create contract) v poli People pro Podepisujícího (is_proposer = false)

o V tomto případě je při spuštění požadavku na Podpis podepisující přesměrován na workspace Signi, kde je registrován a před zahájením podpisu se musí přihlásit a po ukončení podpisu není přesměrován zpět do EGJE a musí se vrátit do EGJE ručně.

· Neregistrovaný podepisující

o Zaměstnanec není registrován v Signi nebo je registrován v Signi, ale pod jiným e-mailem než je e-mail, který EGJE odesílá k podepisujícímu do Signi při podpisu dokumentu (v rámci metody POST Create contract) v poli People pro Podepisujícího (is_proposer = false)

o V tomto případě je při spuštění požadavku na Podpis podepisující přesměrován přímo na podpisovou stránku dokumentu a po ukončení podpisu je přesměrován zpět na stránku EGJE.

Pokud je žádoucí, aby uživatelé, kteří jsou registrováni do některého workspace Signi, se nemuseli při podpisu dokumentu přihlašovat a po podpisu byli zpět přesměrování do EGJE, je potřeba zajistit, aby se v Signi registrovali pod jiným e-mailem, než který EGJE k podepisujícímu odesílá do Signi při požadavku na podpis.

Dále v případě zástupného podpisu u zaměstnance, který je registrovaný podepisující, se pří zástupném podpisu musí do Signi přihlásit podepisující, ne pověřená osoba, která zástupně podpis za zaměstnance spouští.

4.3 API SIgni

Následující popis se vztahuje k základnímu režimu podpisu. Změny v komunikaci se Signi vázané na alternativní režimy podpisu jsou popsány v částech specifikace těchto režimů (Podpis v režimu mimo HRP)

Integrace EGJE a Signi je realizováno prostřednictvím REST API, které využívá následující metody:

#	metoda	parametry metody	popis
1	POST Create contract	-	Dokument je zaslán k podpisu do podpisového modulu prostřednictvím metody POST. Dokument je v podpisovém modulu založen ve stavu = Pending a je vygenerováno ID dokumentu (contractId), které je v další komunikaci používáno jako jedinečný identifikátor záznamu dokumentu. V rámci metody POST Create contract jsou do podepisovacího modulu zaslány následující skupiny informací: · Základní informace k dokumentu (název, číslo) · Parametrizace podpisového procesu · URL pro přesměrování uživatele do HR portálu po podpisu · Navrhovatel: specifikace účtu, pod kterým je dokument v podepisovacím modulu založen (e-mail, režimové konstanty) · Podepisující: set informací k osobě podepisujícího (jméno, příjmení, e-mail, typ), parametry podpisu (typ p odpisu, podpisové pole, režim doplnění datumu a místa podpisu) · Dokument k podpisu Podepisovací modul v rámci response vrací jedinečný identifikátor dokumentu (contractId) a URL na stránky podpisu dokumentu
2	GET Download contract	contractId	Metoda vrací dokument, a to bez ohledu na jeho stav, tj. je možné stáhnout nejen podepsaný dokument, ale i dokument, který ještě nebyl podepsán, nebo byl zamítnut či vyexpirován.
3	GET Get contract detail	contractId	Metoda vrací informace o dokumentu, včetně stavu dokumentu, který je v některých částech podpisového procesu využíván pro rozhodování o dalším postupu komunikace EGJE – podpisový modul.
4	DELETE Fully deleted completed contract	contractId	Metoda smaže podepsaný dokument v úložišti podepisovacího modulu.

4.4 Rámcový popis procesu elektronického podpisu

Na obrázku níže je zakreslen diagram činností pro provedení elektronického podpisu v rámci podpisového kroku workflow oběhu dokumentu, jehož aktéři jsou:

· Uživatel, který má přístup do HR Portálu EGJE pomocí prohlížeče

· IS EGJE: HR portál EGJE a EGJE WebServer

· Provider podepisovacího modulu Signi

Obrázek 1 Proces elektronického podpisu

Zahájení komunikace EGJE s podpisovým modulem probíhá prostřednictvím akce Podepsat na příslušném podpisovém kroku workflow.

4.4.1 Akce Podepsat\Podepsat zaměstnanec

Při spuštění akce Podepsat\Podepsat zaměstnanec EGJE vyhodnotí, zda již byl dokument na tomto kroku k podpisu odeslán. Pokud ne, pak dokument odešle k podpisu do podpisového modulu (POST Create contract) a zahájí proces podpisu (Proces podpisu).

Pokud v rámci daného kroku již byl dokument do podpisového modulu odeslán, pak EGJE zjistí stav jeho zpracování v podpisovém modulu (GET Get contract detail) a dle stavu provede odpovídající kroky dalšího zpracování dokumentu

· Stav = Pending (dokument čeká na podpis): Načte URL pro přesměrování na podpisovou stránku a přesměruje uživatele, který zahájí podpis (Proces podpisu).

· Stav = Expired (dokument byl odeslán k podpisu, ale k jeho podpisu nedošlo v definované lhůtě a jeho platnost v PM vyexpirovala): Dokument znovu odešle k podpisu do podpisového modulu (POST Create contract) a zahájí proces podpisu (Proces podpisu). Pokud jde o Podpis zaměstnance, který je v Režimu podpisu mimo HRP, pak v tomto případě nedojde k automatického opakovanému odeslání do PM. V tomto případě může být dokument odeslán na daném kroku k podpisu znovu jen uživatelem s právem zástupného spuštění akce Podepsat zaměstnanec.

· Stav = Completed (dokument již byl na daném kroku podepsán, nebyl ale ještě stažen podepsaný zpět do EGJE). Uživatel bude informován: Dokument byl podepsán a EGJE stáhne podepsaný dokument (GET Download contract). Po stažení dokumentu se workflow oběhu dokumentu posune na další krok a zároveň v podpisovém modulu bude odmazána verze dokumentu platná na předchozím kroku (DELETE Fully delete completed contract)

· Stav = Rejected: Uživatel bude informován o zamítnutí dokumentu. Workflow oběhu dokumentu zůstává na stejném kroku beze změny.

4.4.2 Proces podpisu

Proces podpisu je zahájen odesláním dokumentu do podpisového modulu (Akce Podepsat). Podpisový modul si uloží aktuální verzi dokumentu a předá EGJE informaci o ID dokumentu, pod kterým jej eviduje a URL, na kterém je dokument dostupný k podpisu.

Uživatel bude přesměrován na podpisovou stránku, kde může dokument podepsat nebo zamítnout.

V případě, kdy uživatel podepíše, podpisový modul po dokončení podpisu přesměruje uživatele zpět do HR portálu. EGJE si načte podepsaný dokument a posune workflow na další krok. Zároveň v podpisovém modulu smaže tuto verzi dokumentu platnou na dokončeném kroku.

Pokud uživatel v podpisovém modulu dokument zamítne, bude v podpisovém modulu nastaven jako zamítnutý (Rejected). Procesně tato situace může nastat:

· Při podpisu v podpisovém modulu byla zjištěna chyba a z tohoto důvodu byl podpis v podpisovém modulu zamítnut. V tomto případě je potřeba dokument opravit a zahájit jeho podpis znovu. Uživatel požádá mimo workflow odpovědného pracovníka s příslušným oprávněním o opravu dokumentu.

· K zamítnutí podpisu došlo z důvodu, že podepisující nechce dokument podepsat. Podepisující v rámci EGJE spustí akcí Zamítnout a workflow se ukončení se stavem schvalování = -1.

4.4.3 DELETE job: mazání neaktivních dokumentů ve workspace Signi

V rámci Adm53 je možno nastavit běh tzv. DELETE jobu, který zajistí odmazávání neaktivních dokumentů z úložiště workspace Signi. Jde o Typ úlohy AS = 40 – Mazání kontraktů v podpisovém softwaru.

Pravidla mazání dokumentů v PM Signi dle jejich statusu:

Expirované, Zamítnuté dokumenty: pro tyto dokumenty je volána metoda SOFT delete. Tato metoda nastaví dokument, který vyexpiroval nebo byl v Signi zamítnutý, do stavu Deleted. Dokument včetně pdf tak zůstává v úložišti workspace, ale nastavením jeho stavu na Deleted dojde k tomu, že dokument nebude dostupný k náhledu, ani ke stažení přes API.
Podepsané dokumenty, které nebyly po podpisu a návazném stažení do EGJE ve workspace Signi smazány. V rámci základního modu zpracování podepsaného dokumentu po stažení podepsaného dokumentu do EGJE je dokument v PM Signi smazán (HARD delete: Výsledkem této metody smazání je odmazání pdf, ve workspace Signi. Metadata k podepsanému dokumentu ale ve workspace zůstávají. Tzn. v Signi je stále evidována “obálka“ podepsaného dokumentu: stav Uzavřen, ale v rámci náhledu na detail dokumentu je odebrána příloha). Pokud by např. došlo k chybě smazání dokumentu po jeho stažení do EGJE a podepsaný dokument tak v Signi zůstal nesmazán, DELETE job provede jeho dodatečné smazání metodou HARD delete.

4.5 Archivace dokumentů v PM Signi

4.5.1 Vstupní info

Vstupní nastavení integrace EGJE – PM Signi běží v modu, kdy primárním a jediným úložištěm podepsaných dokumentů je EGJE. Poté, co je dokument v PM podepsán a podepsaný stažen do EGJE, je z úložiště PM smazán. V rámci workspace Signi zůstávají jen metadata k podepsanému dokumentu. Součástí funkcionalit PM Signi je i archív, který zajišťuje dlouhodobou údržbu podepsaných dokumentů, tj. zejména přerazítkování. Aktivaci tohoto modulu archívu PM Signi je potřeba provést jak nastavením modulu Archívu v rámci příslušného workspace, tak na straně EGJE, kde je potřeba nastavit parametr aktivního Archívu PM.

V rámci integrace EGJE na PM Signi v modu aktivního Archívu PM je zohledněna základní koncepce řízení akceptačních workflow oběhu Dokumentů PV v EGJE a workflow podpisu v PM: Jeden podpisový krok v rámci workflow EGJE = 1 podpisové workflow a 1 dokument v PM. Tzn. v rámci integrace EGJE na PM je s každým podpisovým krokem zakládán v PM nový dokument a akceptační workflow dokumentu je řízeno EGJE. Jeden dokument s N podpisy tak je v EGJE evidován v rámci 1 workflow dokumentu, zatímco v PM je založeno N dokumentů. Z této logiky pak pro integraci v modu aktivního Archívu PM vyplývá, že v PM je potřeba do archívu přesunovat jen dokumenty po podpisu na posledním podpisovém kroku.

Procesně je integrační scénář EGJE – PM Signi pro aktivní Archív PM řešen následně: Pokud je Archív PM aktivní, pak jsou v modu archívu zpracované všechny dokumenty odeslané do PM k poslednímu podpisu. Tyto dokumenty jsou archivovány v rámci workspace PM Signi za podmínek definovaných v parametrizaci Archívu pro daný workspace: archivace proběhne po uplynutí doby definované pro přesun dokumentu do archívu, a to na dobu definovanou v rámci parametru výchozí doby archivace (obojí parametrizace workspace PM Signi). Tzn. nejsou rozlišovány různé podmínky archivace dle Typu dokumentu, či jiných atributů dokumentu, všechny dokumenty jsou přesunuty do archívu PM dle stejných archivačních podmínek definovaných v rámci workspace PM Signi.

4.5.2 Parametrizace Archívu PM

4.5.2.1 PM Signi

Na straně workspace PM Signi je potřeba pro nastavení podmínek archivace definovat tyto parametry:

· Doba pro přesun dokumentu do archívu (v rámci nastavení Archívu v PM Signi jde o parametr Počet dnů, po kterém se dokument archivuje), tj. jde o období v kalendářních dnech, které uplyne od okamžiku založení dokumentu v Signi do okamžiku přesunu podepsaného dokumentu do archívu (min 1 den, max 6 měsíců)

· Doba archivace (v rámci nastavení Archívu v PM Signi jde o parametr Výchozí doba archivace): Období, po které bude dokument uchováván v archívu (min 5 let, max 100 let).

V rámci PM Signi dojde k přesunu dokumentu do archívu, pokud jsou splněny podmínky:

Workspace má aktivován archivační modul
Dokument byl podepsán a file podepsaného dokumentu zůstal v úložišti PM Signi (tzn. nebyl smazán po stažení do EGJE)
Uběhl definovaný časový interval Doby pro přesun dokumentu do archívu

4.5.2.2 EGJE

o Aktivace Archívu PM v komunikaci s PM Signi je nastavena Parametrem API na Adm55. Na záložce API\Parametry API je potřeba založit pro daný typ prostředí platný záznam s parametrem Typ parametru = 110 – PM – Režim archívu – Vše. (tzn. zadat Typ parametru, Typ prostředí, Platnost od, Platnost do) . Nastavení parametru 110 – PM – Režim archívu – Vše může provést jen uživatel s oprávněním fPodpisModulArchiv.

o Pokud je Archív PM aktivován na Adm55, pak po stažení dokumentu na posledním podpisovém kroku nedojde ke smazání podepsaného dokumentu v PM Signi a v EGJE je zaevidováno ID dokumentu v PM Signi. Tato informace je dostupná na Opv31, záložce Detail (pole ID dokumentu v Archívu PM). Toto pole je zpřístupněno k náhledu rovněž jen pro uživatele s oprávněním fPodpisModulArchiv.

4.5.3 Integrační scénář pro aktivní ARCHÍV PM

Pokud je aktivován Archív PM (na straně EGJE i PM Signi), pak na posledním podpisové kroku akceptačního workflow dokumentu po stažení podepsaného dokumentu z PM Signi do EGJE dochází k následujícím odlišnostem ve zpracování dokumentu v EGJE oproti modu bez Archívu PM:

Neaktivní Archív PM

Aktivní Archív PM

Smazání podepsaného dokumentu v PM Signi

Dokument je ve workspace Signi smazán a není archivován.

Dokument není ve workspace Signi smazán a po uplynutí Doby pro přesun dokumentu do archívu dojde k jeho archivaci, a to na definovanou Dobu archivace (parametrizace PM Signi)

Evidence ID dokumentu v PM SIgni

V EGJE není evidováno ID dokumentu v PM Signi.

Na straně EGJE je zaevidováno ID dokumentu v PM Signi. Tato informace je dostupná na Opv31, záložka Detail pro uživatele s oprávněním fPodpisModulArchiv.

V Signi jde o atribut Číslo dokumentu v náhledu na detail dokumentu.

Tyto změny zpracování dokumentu v režimu aktivního Archívu PM se aplikuji na posledním podpisovém kroku dokumentu při:

· Akci podpisu: a to jak v rámci základního režim podpisu (Základní režim podpisu vs alternativní režimy podpisu), tak i při odeslání dokumentu k podpisu v Režimu podpisu mimo HRP (Režim podpisu mimo HRP)

· V případně aktivní úlohy DELETE job: mazání neaktivních dokumentů ve workspace Signi pak i v případě posledního podpisového kroku nebude podepsaný dokument ve stavu Completed smazán

4.5.4 Alternativní scénáře

Podepsaný dokument je v PM Signi archivován před jeho stažením do EGJE

PM Signi aktuálně neumožňuje předat na dokumentu zaslaném k podpisu informaci o tom, zda je požadována archivace. Pokud podepsaný dokument splní podmínky archivace (viz PM Signi), pak bude přesunut do Archívu PM.

Procesně je požadováno, aby v modu aktivního režimu Archívu PM byly archivovány podepsané dokumenty na posledním podpisovém kroku. Pokud ale dojde k situaci, kdy bude podepsán dokument na neposledním podpisovém kroku a k jeho archivaci dojde před stažením podepsaného dokumentu do EGJE (a tedy i před smazáním podepsaného dokumentu v úložišti workspace), pak bude do archívu přesunut i dokument, který procesně nesplňuje podmínky archivace. K tomuto může dojít zejména v případě, kdy po podpisu nedojde k přesměrování na HRP EGJE a dokument je potřeba stáhnout do EGJE ručně (znovuspuštěním akce podpisu v EGJE) nebo v případě podpisu mimo HRP je dokument stažen při nejbližším běhu úlohy na Stažení podepsaného dokumentu z PM do EGJE. Pokud ke stažení podepsaného dokumentu do EGJE dojde až poté, co došlo k jeho archivaci v rámci workspace Signi pak dojde k archivaci dokumentu i na neposledním podpisovém kroku (archivované dokumenty nelze v PM mazat).

Dokument je zamítnut nebo nestandardně ukončen po podpisu všemi podepisujícími

Pokud je dokument podepsán všemi účastníky, pak bude v PM archivován a v rámci EGJE bude evidováno ID dokumentu v PM Signi. Nicméně pokud by v rámci workflow po posledním podpisovém kroku byl definován ještě další nepodpisový krok a workflow po posledním podpisu tak nepřechází do stavu 30, ale pokračuje dalším krokem na kterém dojde k zamítnutí dokumentu nebo nestandardnímu ukončení (např. z důvodu DEADLINE nebo nestandardního zásahu do workflow uživatelem se speciálním admin oprávněním – např. změna statusu dokumentu s oprávněním Opv31statusAdmin, Storno dokumentu), pak dokument bude v EGJE neakceptován, ale zůstává v archívu PM jako podepsaný dokument (archivované dokumenty nelze v PM mazat) .

5 Typový příklad konfigurace podpisového workflow

5.1 Základní proces

5.1.1 Systémové nastavení

· Zákazník má implementováno napojení na jeden podepisovací modul, a to Signi

5.1.2 Proces

Prodloužení smlouvy kmenovému zaměstnanci

· Proces akceptace smlouvy: personalista schválí a poté jde k podpisu zástupce za zaměstnavatele (manažer zaměstnance) a následně k podpisu zaměstnanci (zaměstnanec může podepsat sám nebo přijde za svým manažerem a podepíše u něj)

· Dokumenty jsou zasílány do procesu schvalování Manažerem HR oddělení

· Zaměstnanec má přístup na HR portál a má přístup ke svým dokumentům na Pkz01 (záložka Dokumenty PV)

· Odpovědný HR pracovník schvalovací proces monitoruje a od okamžiku spuštění podpisového procesu se může kdykoliv podívat na stav dokumentu. Nemá mít ale dokument dostupný před spuštěním schvalovacího procesu (tedy ve stavu dokumentu 0 – koncept)

· Podepsaný dokument bude zaslán zaměstnanci zaheslovaný a zašifrovaný na jeho pracovní e-mail a to automaticky pro akceptaci dokumentu (stav 30).

· Ruční odeslání dokumentu na e-mail zaměstnance mají přístupné HR pracovník, Manažer

5.2 Konfigurace

5.2.1 Organizace a systém

5.2.1.1 Nastavení struktur (Str01, Str02)

Pro definici pravidel příjemců wflow kroku je potřeba mít správně nastavené struktury jak pro manažery, kteří by měli mít následně přístup k dokumentům svých podřízených, tak personalisty.

Typická struktura pro určení manažerů zaměstnanců je 2 - Organizační struktura, která je přiřazena k zaměstnanci buď přímo, případně přes strukturu 3 - Pracovní místo, a na každém jejím prvku je definován manažer.

5.2.1.2 API a podpisové prostředky (Adm55)

5.2.1.2.1 Signi

Parametry rozhraní podepisovacího modulu (záložka API)

· Poskytovatel: 10 – Signi. Workflow oběhu dokumentů aktuálně umožňuje integraci na podpisový modul Signi. V případě definice podpisového prostředku Signi pro podpis Dokumentů PV je potřeba pole Poskytovatel vyplnit (akce podpisu v rámci workflow oběhu dokumentu nabízí pouze prostředky poskytovatele 10 – Signi)

· URL: https://api.signi.com/

· Port: 1

· Workspace: jméno workspace založeného pro komunikaci s EGJE

· Typ prostředí: nastavit dle konfigurátoru

· Typ autentizace = 30 - API key

· Autentizační klíč = klíč vygenerovaný pro daný workspace Signi

· Přístupový účet: e-mail vlastníka workspace

· Heslo: heslo pro přístupový účet

Podpisový prostředek

· Oblast služeb = 1 - Podpisy a pečetě

· Typ služeb = 10 - Elektronický podpis prostý

· Přiřazení prostředku na organizaci, resp. SJ: dle požadavků zákazníka

5.2.1.3 Organizace (Adm21) – nastavení defaultního podepisovacího prostředku zaměstnance

V našem příkladu využíváme napojení pouze najeden podepisovací modul a v tomto případě není potřeba řešit režim volby podepisovacího prostředku zaměstnancem.

Pokud bychom měli implementováno více jak jeden podepisovací prostředek pro daný typ podpisu, pak se v rámci podpisového kroku workflow uživateli nabídne volba, kterým prostředkem chce dokument podepsat. Volbu lze omezit pro podpis zaměstnance, a to konfigurací na Adm21 a zde záložce Konf. parametry: pokud Zaměstnanec bez možnosti volby podepisovacího prostředku = Ano, pak zaměstnanci si nebudou moci podepisovací prostředek vybrat a budou podepisovat definovaným defaultním prostředkem pro jejich organizace, resp. organizaci. Jak již je ale výše uvedeno, aktuálně je EGJE integrováno jen na 1 poskytovatele podpisů a volba prostředku podpisu uživatelem tak nyní není aktuální.

5.2.2 Uživatelé

5.2.2.1 Nastavení pro odesílání schválených dokumentů na e-mail zaměstnance

Zaměstnanec	Formulář
ZAM kmenový	Osb02/Adresy a kontakty	Zadat kontakt 31 – e-mail v zaměstnání
	Xpw02/03	Heslo
ZAM nový	Osb02/Adresy a kontakty	Zadat kontakt 30 – e-mail pro el. doručení
	Xpw02/03	Heslo

5.2.2.2 Typové profily a uživatelé

Profil	Uživatel	Přístup k datům ZAM	Speciální oprávnění
Admin	Administrátor		fSeaid, Opv31statusAdmin
ZAM kmenový	Zaměstnanec kmenový	Vlastní dokumenty	Pkz01dokument Opv31omezProZam
ZAM nový	Zaměstnanec nový	Vlastní dokumenty, ale de facto Neřešíme, nemá přístup na HRP	Opv31omezPodpisVlastni Opv31omezProZam
HR admin	HR admin	Vidí data všech ZAM	fSeaid Opv31statusAdmin
PERS	Personalista pro nové zaměstnance	Vidí data podřízených ZAM (včetně Zaměstnanec nový)	fSeaid Opv31omezNaNezahajene Opv31pravoPodpisZam Opv31pravoOdeslatNaMail
MAN	Manažer	Vidí data podřízených ZAM (včetně Zaměstnanec kmenový)	fSeaid Opv31omezProSchval Opv31pravoPodpisZam Opv31pravoOdeslatNaMail

5.2.3 Dokumenty

Dokument	Šablona	Typ dokumentu: Jpc01 uchaz_dok_typ	Typ dokumentu: Jpc01 – Kód 3
SML prodloužení	2 podpisy: %Podpis_1%,: %Podpis_2%	7 – Smlouva HPP prodloužení	Kód 3 = 2 - Musí být schvalovaný/podepisovaný
SML nová	2 podpisy: %Podpis_1%,: %Podpis_3%	6 – Smlouva HPP nová	Kód 3 = 2 - Musí být schvalovaný/podepisovaný

Ukázka části podpisových bloků

%Podpis_1%

--------------------------------------------------------

Zaměstnavatel

%Podpis_2%

--------------------------------------------------------

Zaměstnanec

V dokumentu dát kódy bloků (%Podpis_1%) barvou pozadí, aby v dokumentu nebyly viditelné.

5.2.4 Workflow podpisu dokumentu

5.2.4.1 Prodloužení pracovní smlouvy

5.2.4.1.1 Parametrizace workflow

Adm14 - Detail	Nastavení
Konvertovat formát dokumentu	Ano
Způsob konverze formátu dokumentu	10 – Rtf na Pdf
Režim odeslání dokumentu	10 – Odeslat automaticky po schválení dokumentu
Použít heslo při odeslání dokumentu na e-mail*	Ano
Typ šifrování*	AES-128 nebo AES-256
Název workflow	Prodloužení pracovní smlouvy

* Aktuálně je dostupné pouze šifrování ZIPu a v tomto případě je proces šifrování a heslování provázán. K zaheslováni ZIPu a zašifrování hesla tak dojde v případě: Použit heslo = Ano a/nebo Typ šifrování = AES-256

Adm14 - Dokumenty	Nastavení
Rtf2x ukládané doOpv31 poslat do schvalování	Ano
Typ dokumentů	6 – Smlouva HPP nová
Statusy	Viz Statusy workflow

5.2.4.1.1.1 Statusy workflow

V rámci popisu definice workflow budeme pracovat obecně s následujícími typovými kroky

Číslo	Popis	Chování kroku a parametrizace způsobu akceptace dokumentu (schválení, podpis) na kroku (Adm14)
0	Koncept dokumentu	V tomto statusu workflow čeká na spuštění. Workflow v daném kroku nabízí akci Odeslat ke schválení.
5	Dokument ke schválení PERS	Dokument čeká na schválení odpovědným personalistou. Workflow v daném kroku nabízí akci Schválit. Krok workflow bude mít na Adm14 nastaveno: · Číslo pravidla primárního příjemce: 13 - Manažer struktury - Místa · Podpis: Elektronický podpis = NE · Kód podpisového pole = NULL · Typ podpisu = NULL
10	Dokument k podpisu PERS	Dokument za zaměstnavatele podepisuje personalista. Workflow v daném kroku nabízí akci Podepsat. Krok workflow bude mít na Adm14 nastaveno: · Typ schvalování = 1 – Schválení 1.primární příjemcem z min.kroku · Číslo pravidla primárního příjemce: 13 - Manažer struktury - Místa · Podpis: Elektronický podpis = Ano · Kód podpisového pole = kód makra podpisového pole personalisty v šabloně dokumentu · Typ podpisu = dle požadavku daného dokumentu (10 - Elektronický prostý podpis/14 – Podpis certifikátem)
15	Dokument ke schválení MAN	Dokument čeká na schválení nadřízeným manažerem zaměstnance. Workflow v daném kroku nabízí akci Schválit. Krok workflow bude mít na Adm14 nastaveno: · Číslo pravidla primárního příjemce: 1 - Manažer struktury – Organizační struktura · Podpis: Elektronický podpis = NE · Kód podpisového pole = NULL · Typ podpisu = NULL
16	Dokument k podpisu MAN	Dokument čeká na podpis nadřízeného manažera zaměstnance. Workflow v daném kroku nabízí akci Podepsat. Krok workflow bude mít na Adm14 nastaveno: · Typ schvalování = 1 – Schválení 1.primární příjemcem z min.kroku · Číslo pravidla primárního příjemce: 1 - Manažer struktury – Organizační struktura · Podpis: Elektronický podpis = Ano · Kód podpisového pole = kód makra podpisového pole nadřízeného zaměstnance v šabloně dokumentu · Typ podpisu = dle požadavku daného dokumentu (10 - Elektronický prostý podpis/14 – Podpis certifikátem)
20	Dokument k podpisu ZAM	Dokument čeká na podpis zaměstnancem. Workflow v daném kroku nabízí akci Podepsat zaměstnanec. Krok workflow bude mít na Adm14 nastaveno: · Typ schvalování = 1 – Schválení 1.primární příjemcem z min.kroku · Číslo pravidla primárního příjemce: 5 - Osoba o níž WF je · Podpis: Elektronický podpis = ANO · Kód podpisového pole = kód makra podpisového pole zaměstnance v dokumentu · Typ podpisu = dle požadavku daného dokumentu (10 - Elektronický prostý podpis/14 – Podpis certifikátem)
25	Dokument k seznámení ZAM	Dokument čeká na podpis zaměstnancem. Workflow v daném kroku nabízí akci Podepsat zaměstnanec. Krok workflow bude mít na Adm14 nastaveno: · Číslo pravidla primárního příjemce: 5 - Osoba o níž WF je · Podpis: Elektronický podpis = NE · Kód podpisového pole = NULL · Typ podpisu = NULL
30	Schválený dokument/ Elektronicky podepsaný dokument	Workflow bylo ukončeno schválením/podepsáním dokumentu.
-1	Stornovaný dokument	Workflow bylo ukončeno zamítnutím dokumentu. Po stisku tlačítka Zamítnout se workflow ukončuje a nastaví se záporný status dokumentu: -1. Akce Zamítnout se nastavuje na kroku workflow na Adm14 polem Konečný status – zamítnuto.

5.2.4.1.1.2 Kroky workflow

WFL status	Konečný status	Konečný status - zamítnuto	Pravidlo – prim. příjemce	El.podpis	Kód podpis.pole
0	5		13 – Manažer struktury - Místa
5	16	-1	1 – Manažer struktury – org.struktura	Ne
16	20	-1	5 – Osoba, o níž WF je	Ano	%Podpis_1%
20	30	-1		Ano	%Podpis_2%

5.2.4.1.1.3 Parametrizace obsahu e-mailu se schváleným dokumentem

Adm14, Adm33

Nastavení

Adm14\Detail: Název workflow

Prodloužení pracovní smlouvy

Adm33\Krok workflow = 500: Předloha oznámení

Dobrý den,

v příloze zasíláme dokument: %SOUBOR%

Platnost dokumentu od: %PLATNOST_OD%

Platnost dokumentu od: %PLATNOST_DO%

Váš HR tým