...

Princip propojení se

...

Signi

Výhodou propojení aplikací a služeb s iSmlovou se Signi je jeho jednoduchost, celý proces zahrnuje 3 kroky.

...

• Ve vaší Aplikaci - ERP, CRM, DMS, webu, interní aplikaci apod. - jsou zadány požadované údaje či dokumenty o vašem klientovi / partnerovi / zaměstnanci, se kterým chcete uzavřít smlouvu přes API iSmlouva  Signi  - dokumentů k podpisu se souřadnicemi podpisů anebo vzorů s parametry

...

• a) Ve vaší Aplikaci je/přidá se funkce, která na podnět uživatele předá podklady do iSmlouva Signi a vyvolá ověření

• b) iSmlouva Signi má nebo připraví funkci, která bude přebírat podklady z vaší Aplikace a následně vyvolá ověření

...

• Ve vaší Aplikaci je/ se přidá informace o průběhu vytvoření a ověření dokumentů

...

Varianty použití Signi API

Předání podkladů

Podporujeme dva způsoby předávání podkladů při integraci:

• Předání souborů - Ve vaší Aplikace Aplikaci je vygenerován kompletní soubor ve formátu pdf, doc, docx, odt, který je s ostatními parametry odeslán do API iSmlouvy Signi k podpisu.

• Předání parametrů pro vzor - Vaše Aplikace poskytne metadata (hlavičky, obsah jednotlivých doplňovacích polí smlouvy apod.) pro doplnění vzoru dokumentu, který je vytvořen a uložen v aplikaci iSmlouvaSigni. Tato metadata společně s ostatními parametry jsou odeslány do API iSmlouvySigni. Více o vzorech zde.

Výchozí rozsah služeb iSmlouva Signi zahrnuje pouze předávání dokumentů. Použití vzorů je placené rozšíření.

Varianty vyvolání

Jsou 4 cesty vyvolání podepsání z integrované aplikace:

• 1. Distanční podpis

• 2. Podpis v integrované aplikaci

• 3. Signi jako fronta práce

• 4. Signi přes QR kod

Předávání výsledků

Zpětným voláním

Součástí předávání podkladů pro podpis jsou i tři URL adresy  tzv. “webhooků” pro každou hodnotu výsledku:

• podepsáno - signed,

• odmítnuto  - rejected,

• neověřeno - expired

kdy jeden z nich se vyvolá v okamžiku, kdy daný stav nastane.

Průběžným ověřováním stavu

Někdy lze webhooky v integrovaném  systému obtížně implementovat.

Místo toho je možné se dotazovat na aktuální stav dokumentu, a to periodicky, anebo např. při otevření detailu souvisejícího záznamu v integrovaném systému.

Toto se může hodit např. pro on-premise provozovaná řešení, která nejsou viditelná mimo firemní síť, tj. webhook nelze zrealizovat.

Více viz Jak se předávají podklady k podepisování?získám výsledek předání podkladů pro podpis

3 kroky elektronického právního jednání

Elektronické právní jednání zahrnuje 3 kroky a to vzálenou identifikaci , el. podpis a archivaci elektronických dokumentů. Všechny tři kroky se nějakým způsobem promítají i do Signi API.

• Vzdálená identifikace - v rámci podepisování v Signi probíhá standardně 2-faktorové ověření přes e-mail a telefon přes PIN zaslaný v SMS. Volitelně lze přes API vyvolat i pokročilé varianty vzdálené identifkace.

• Podepisování - lze předávat soubory k podpisu nebo parametry pro vzory v Signi

• Archivace - Dlouhodobou archivaci dokumentů lze zajistit přímo v Signi pomocí Signi Archiv . Alternativně lze jakýkoliv elektronický archiv se SIgni integrovat - podepsané uzavřené dokumenty posíoá Signi přes zpětně volané webhooky nebo si archiv dokumenty vhodné k archivaci zjiš%tuje archiv sám. Archiv dokumenty načtě, případně je může přes API ze Signi i smazat.

Způsoby autentikace

Jediný servisní účet v Signi

• Nejjednodušší scénář propojení, kdy účet v Signi má zákazník pouze jeden a slouží pouze pro vytvoření workspace a fakturaci.

• Žádný z podepisujících nemusí mít účet v Signi. 

• Stačí použít jeden API klíč k celému pracovnímu prostoru v Signi.

Účty pro podepisující v Signi

• Podepisující musí mít účet v Signi a při každém podpisu se přihlašují do Signi . 

• Výhoda je, že mohou použít předpřipravené podpisy a lze řídit práva přístupu na úrovni Signi.

• Lze stále používat jeden API klíč k celému pracovnímu prostoru v Signi. 

Připravujeme i možnost osobních API klíčů či autentikaci přes Oauth2 apod.

Navrhovatel vs. smluvní strany

Při podepisování a tedy i předávání podkladů přes API je třeba odlišit:

• Navrhovatel - Je tvůrce podepisovaného dokumentu a tedy musí mít účet v iSmlouvěSigni a právo přístupu do daného workspace / pracovního prostoru v Signi. Může a nemusí být smluvní stranou, např. u realitních makléřů. Chodí mu zpět notifikace o tom, kdo dokument podepsal, odmítl podepsat apod. Může dokument zrušit. Nový dokument vidí v Odeslaných dokumentech.  Ve variantě integrace "Jediný servisní účet" je právě tento účet tvůrcem dokumentu, který ale nepodepisuje.

• Smluvní strana Protistrany - Může a nemusí mít účet v iSmlouvěSigni. Dokument může podepsat a odmítnout. Pokud má účet v iSmlouvěSigni, nový dokument vidí v Odeslaných dokumentech , (pokud je zároveň navrhoatelem navrhovatelem), nebo v Přijatých dokumentech , pokud nikoliv(pokud není navrhovatelem).

Při integraci přes API je nejjednoudušší scénář Jediný servisní účet (viz výše). V tomto případě je automaticky navrhovatelem resp. autorem dokumentů vždy vlastník pracovního prostoru Signi, do kterého se posílá dokument k podpisu přes API. Ten na dokumentu nikde nefiguruje, ani ho nepodepisuje, ani ho neschvaluje. Podepisující či schvalovatelé, ať z firmy navrhovatele či mimo ni jsou smluvními stranami.

Existence účtu na službě

...

Signi

Člověk podepisující, resp. schvalující dokument může a nemusí  mít nemusí mít účet v SIGNISigni. Z hlediska volání API je to jedno, liší se pouze chování služby, resp. její uživatelské rozhraní před zobrazením dokumentu k podpisu. Po kliknutí na notifikační SMS a e-mail, člověku, který
Mohou tedy nastat 2 situace:  

• uživatel nemá účet v SIGNI - se Signi - po kliknutí na link v notifikační SMS / e-mailu se mu ukáže rovnou dokument k podepsání, ; až po podpisu se mu nabídne, zda si chce zřídit účet v iSmlouvěSigni,

• uživatel již má účet v SIGNI - se v Signi - po kliknutí na link v notifikační SMS / e-mailu se mu ukáže přihlašovací obrazovka iSmlouvy Signi a po přihlášení má přístup k dokumentu k podepsání.

Scénáře podepisování

Ač se to na první pohled nezdá, existuje více různých variant podepisování, resp. schvalování dokumentu, které lze navíc kombinovat pro různé zúčastněné strany:

1. Podepisuje

2. Schvaluje

3. Bianco podpis

4. Bez akce

5. Na vědomí

6. Potvrzuje pouze PINem

7. Podepisuje první / poslední / v pořadí

Podepisuje 

Člověku se odesílá notifikační SMS a e-mail, musí dokument fyzicky podepsat.

Nastavení: 

•  Is_proposer: true / false, jde-li o zástupce navrhovatele 

• "contract_role": "sign"

• "autosign_place": parametr se nepředává anebo musí být prázdný

Člověk:

• Člověk s daným e-mailem nemusí mít účet v iSmlouvě. 

• Pokud účet má a jde o zástupce navrhovatele, musí být v týmu pracovního prostoru/workspace, musí mít nastaveno právo podpisu, nemusí mít uložený grafický podpis.

• Pokud účet má a nejde o zástupce navrhovatele, nemusí mít právo podpisu, nemusí mít uložený grafický podpis, předpokládá se, že má jediný workspace, do kterého se dokument umístí.

• Ve variantě použití “Jediný servisní účet v iSmlouvě” skutečný statutární zástupce firmy není navrhovatelem tj. při volání je is_proposer = false, nesmí mít účet v iSmlouvě, jako navrhovatel bude veden servisní účet ve variantě “Bianco podpis”.

...

Navrhovateli se neodesílá notifikační SMS a e-mail, na dokumentu bude uveden jeho podpis. Příkladem použití jsou návrhy objednávek do určité výše.

Nastavení: 

• "contract_role": "sign",

• "autosign_place": je vyplněn nějaký text, např. "V Praze"

•  Is_proposer: true

Člověk: 

• Tato možnosti se týká se pouze smluvní strany, která je zároveň navrhovatelem, tvůrcem dokumentu tj. Is_proposer: true. Uživatel s daným e-mailem musí být v týmu pracovního prostoru/workspace navrhovatele, má tam nastaveno právo podpisu a musí mít uložený grafický podpis ve svém uživatelském profilu. Pokud  nemá uživatel uložený grafický podpis ve svém profilu, vrací se odpovídající chyba.

...

Člověku se neodesílá notifikační SMS a e-mail, nic nepodepisuje, pouze zmáčknutím tlačítka dokument schválí.

Nastavení: 

• "contract_role": "approve"

• "autosign_place": je vyplněn nějaký text, např. "V Praze"

Člověk:

• Člověk s daným e-mailem nemusí mít účet na iSmlouvě. 

• Pokud účet má a jde o zástupce navrhovatele tj. is_proposer=true, musí být v týmu pracovního prostoru/workspace navrhovatele, musí mít nastaveno právo podpisu, nemusí mít uložený podpis. 

Bez akce

Týká se situací, kdy někdo dokument navrhuje, ale není smluvní stranou. Příkladem je makléř v realitní kanceláři. Druhým příkladem je varianta použití  “Jediný servisní účet v iSmlouvě” při integraci. Člověku se neodesílá notifikační SMS a e-mail, na dokumentu není jeho podpis, dokument má k dispozici  pracovním prostoru.

Nastavení: 

• "is_proposer": true,

• "contract_role": "approve",

• "autosign_place": jakýkoliv text např. "V Praze"

Člověk:

• Člověk s daným e-mailem je v týmu pracovního prostoru/workspace navrhovatele, nemusí mít právo podpisovat, nemusí mít uložený grafický podpis ve svém uživatelském podpisu.

...

Připravujeme další varianty podepisování, například: 

• Na vědomí - Člověku se odesílá SMS a e-mail s odkazem na podepsaný dokument, resp. informace o jeho odmítnutí či expiraci, nijak se k dokumentu nevyjadřuje.

• Podepisuje jen PINem - Člověku se odesílá notifikační SMS a e-mail, kromě schválení zadává PIN pro 2faktorovou funkcionalizaci. 

• Podepisuje první / poslední / v pořadí - Aktuálně notifikační SMS a e-mail odejde vždy všem stranám najednou. Tím se API liší od uživatelského rozhraní, kdy v rámci přípravy nejprve podepisuje navrhovatel a pat teprve protistrany. Pořadí podepisování půjde nastavovat.

Předání výsledků

Zpětným voláním

Součástí předávání podkladů pro podpis jsou i tři URL adresy  tzv. “webhooků” pro každou hodnotu výsledku:

• podepsáno - signed,

• odmítnuto  - rejected,

• neověřeno - expired

kdy jeden z nich se vyvolá  okamžiku, kdy daný stav nastane.

Průběžným ověřováním stavu

Někdy  lze webhooky v integrovaném  systému obtížně implementovat.

Místo toho je možné se dotazovat na aktuální stav dokumentu. 

A to periodicky anebo např. při otevření detailu souvisejícího záznamu v integrovaném systému.

Více viz Jak získám výsledek předání podkladů pro podpis

Autentikace

Jediný servisní účet v SIGNI

• Nejjednodušší scénář propojení, kdy účet v SIGNI má zákazník či pouze jen jeden a slouží pouze pro vytvoření workspace a fakturaci.

• Žádný z podepisujících nemusí mít účet v iSmlouvě. 

• Stačí použít jeden API klíč k celému pracovnímu prostoru v iSmlouvě.

Účty pro podepisující v iSmlouvě

• Podepisující musí mít účet při iSmlouvě a při každém podpisu se přihlašují do iSmlouvy . 

• Výhoda je, že mohou použít předpřipravené podpisy a lze řídit práva přístupu na úrovni iSmlouvy.

• Lze stále používat jeden API klíč k celému pracovnímu prostoru v iSmlouvě. 

Připravujeme i možnost osobních API klíčů či autentikaci přes Oauth2 apod.

Jak zajistit propojení

Integrace iSmlouvy Formy vyjádření souhlasu:

Podepisuje - má podpis na dokumentu - s tím, že rypů podpisů je více
Schvaluje - jen potvrdí souhlas s dokumentem, podpis není vidět

Pořadí podepisování

1. Podepisují nejdříve navrhovatelé a pak protistrany

2. Záleží na pořadí podepisujících

Jak zajistit propojení

Integrace Signi na jiný systém může být zajištěna různými způsoby. Integraci může zajistit:

• Tým iSmlouva Signi s využitím integrační služby www.Integromat.com. Při malé náročnosti je v poplatku za využití integrace/API i zprovoznění integrace, při větší náročnosti je v poplatku časový a finanční odhad rozsahu prací.

• Implementátor systému či integrací u daného uživatele přes integrační služby Integromat , MS Power Automate / Flow a podobně nebo přímým voláním API iSmlouvySigni.  Dostane k tomu od iSmlouvy Signi všechny podklady (viz tyto stránky) a podporu.

• Interní IT uživatel přes integrační služby Integromat , MS Power Automate / Flow a podobně  nebo přímým voláním API iSmlouvySigni.  Dostane k tomu od iSmlouvy Signi všechny podklady (viz tyto stránky) a podporu.

...

Stručný tahák - Co si ujasnit před integrací SIGNI s vaším systémem

...

Odkud se vezmou kontaktní údaje na podepisující? - Jméno, Příjmení, email, telefon (ten není povinný, ale pak ho uživatel musí zadat sám, aby mu přišla SMS a on mohl být ověřen).

...

Co se bude to posílat? - Hotový dokument PDF/DOCX/HTML/XSLX nebo parametry pro vzor dokumentu uložený v SIGNI?

...

Jak se vyvolá akce podpisování? - Akce v menu na relevantním záznamu, nastavení nějakého custom pole na hodnotu "Odeslat k podpisu” apod.

...

Kde se uživateli ukáže výsledek podpisu? - Stav podepisování / výsledný dokument případně celou historii podepisování (viz kontrolní list)

...

Jak se umístí podpisy? - Nejjednodušší je statické umístění na přesné souřadnice (vhodné pro formuláře typu Evidenční list důchodového pojištění), umístění na konci dokumentu (dostupné již brzy, SIGNI vloží podpis, jméno, příjmení, místo , čas ), dynamické umístění podpisu (cílový stav, placeholdery pro podpisy v dokumentu, vyžaduje flexibilitu určení např. více smluvních stran, za každou stranu podepisuje více lidí).

...

Jak se předávají výsledky zpět? - Preferovanou variantou je webhook volající aktivně integrovaný systému s výsledkem podepisování. Alternativně se lze z integrovaného systému periodicky ptát na výsledek podepisování.

...

Jaká bude vazba mezi uživateli a pracovními prostory iSmlouvy? - Nejjednodušší scénář: V SIGNI je zavedený servisní účet pro celý integrovaný systém nebo jeho jednotlivé koncové zákazníky. Podepisující z firmy zákazníka jsou uváděni jako jedna z podepisujících stran, přijde jim email a SMS. Jinou variantou je, že si zákazníci zřídí svůj účet na SIGNI sami, mají pak možnost přístupu k dokumentům i v SIGNI, platí si svojí útratu v SIGNI a pouze se nastaví integrace přes API, která posílá dokumenty k podpisu do určeného pracovního prostoru / workspace . Další scénáře jsou možné.

...

• .