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

(zpoplatněná část programu)

Obsah

1 Úvod........................................................................................................................ 4

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

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

1.3 Základní procesy....................................................................................................................... 5

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

1.3.1.1 Podpisový krok.................................................................................................................... 6

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

2 Parametrizace podpisového workflow.................................................................. 7

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

2.1.1 Struktury.................................................................................................................................... 7

2.1.2 Nastavení osoby....................................................................................................................... 7

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

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

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

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

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

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

2.1.5 Logování.................................................................................................................................. 10

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

2.2.1 Příprava dokumentu.............................................................................................................. 12

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

2.2.1.2 Typ dokumentu (Jpc01)..................................................................................................... 12

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

2.2.2.1 Parametrizace na úrovni workflow..................................................................................... 13

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

2.2.2.3 Parametrizace obsahu e-mailu........................................................................................... 15

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

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

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

2.2.4.2 Akce Storno dokumentu.................................................................................................... 17

2.2.4.3 Akce Odeslat dokument..................................................................................................... 17

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

3 Integrace EGJE na podpisový modul...................................................................... 19

3.1 Výchozí předpoklady řešení integrace............................................................................ 19

3.2 Registrace v Signi a podpisové workflow..................................................................... 19

3.3 API SIgni...................................................................................................................................... 21

3.4 Rámcový popis procesu elektronického podpisu........................................................ 21

3.4.1 Akce Podepsat\Podepsat zaměstnanec................................................................................ 23

3.4.2 Proces podpisu........................................................................................................................ 23

4 Typový příklad konfigurace podpisového workflow........................................... 24

4.1 Základní proces...................................................................................................................... 24

4.1.1 Systémové nastavení............................................................................................................. 24

4.1.2 Proces...................................................................................................................................... 24

4.2 Konfigurace............................................................................................................................. 25

4.2.1 Organizace a systém.............................................................................................................. 25

4.2.1.1 Nastavení struktur (Str01, Str02)........................................................................................ 25

4.2.1.2 API a podpisové prostředky (Adm55)................................................................................. 25

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

4.2.2 Uživatelé................................................................................................................................. 26

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

4.2.2.2 Typové profily a uživatelé.................................................................................................. 26

4.2.3 Dokumenty............................................................................................................................. 27

4.2.4 Workflow podpisu dokumentu.............................................................................................. 28

4.2.4.1 Prodloužení pracovní smlouvy........................................................................................... 28

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
HR (Human Resources)	Lidské zdroje
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ů

Obsah obrázku text, diagram, snímek obrazovky, řada/pruh

Popis byl vytvořen automaticky

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.

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.

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ž odeslán zaměstnanci na e-mail, nelze stav změnit. Uživatel s tímto oprávněním bude mít přístupnou akci Storno dokumentu v případě, kdy dokument je na podpisovém kroku a dokument bylo odeslán k podpisu do podpisového modulu. Jde o ošetření nestandardních situací, kdy je potřeba provést opravu dokumentu zaslaného k podpisu z důvodu zjištěné chyby.

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í. 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 budou definován elektronický podpis prostý a certifikovaný podpis.

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í nastavit vazbu na logovací soubor

· Obsah obrázku text, Písmo, řada/pruh, číslo

Obsah vygenerovaný umělou inteligencí může být nesprávný.

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í 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

· 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 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). Uživatel se speciálním oprávněním pak má možnost vrátit workflow dokumentu do stavu 0 - Koncept prostřednictvím Akce Storno dokumentu.

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).

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 neafektuje 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řístupni 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 je uživatel 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 Storno dokumentu

Tato akce je aktivní pro uživatele se speciálním oprávněním Opv31statsuAdmin za situace, kdy byl dokument odeslán k podpisu do podpisového modulu a ještě nebyl nahrán podepsaný zpět do EGJE. Jde o prostředek řešení nestandardní situace, kdy při podpisu bylo zjištěno, že dokument je chybný 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.4.3 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 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, včetně zástupného spuštění akce Podepsat zaměstnanec	ANO	ANO
Pkz01\ Dokumenty PV	ANO, včetně zástupného spuštění akce Podepsat zaměstnanec	ANO	NE
Wflow	ANO, 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

3 Integrace EGJE na podpisový modul

3.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.

3.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í.

3.3 API SIgni

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.

3.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

Obsah obrázku diagram

Popis byl vytvořen automaticky

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.

3.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 vyexpirovala): Dokument znovu odešle k podpisu do podpisového modulu (POST Create contract) a zahájí proces podpisu (Proces podpisu).

· 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.

3.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 Typový příklad konfigurace podpisového workflow

4.1 Základní proces

4.1.1 Systémové nastavení

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

4.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

4.2 Konfigurace

4.2.1 Organizace a systém

4.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.

4.2.1.2 API a podpisové prostředky (Adm55)

4.2.1.2.1 Signi

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

· Poskytovatel: 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

4.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í.

4.2.2 Uživatelé

4.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

4.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

4.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é.

4.2.4 Workflow podpisu dokumentu

4.2.4.1 Prodloužení pracovní smlouvy

4.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

4.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.

4.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%

4.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