...

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 iSmlouvěSigni. Z hlediska volání API je to jedno, liší se ale 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 iSmlouvě - 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 iSmlouvě - 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í

...

Č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 iSmlouvě

• Nejjednodušší scénář propojení, kdy účet v iSmlouvě má zákazník 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í iSmlouvy 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 jaký vzor a parametry pro něj.

...

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 uživateli ukážu 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 (nyní pro formuláře), umístění na konci dokumentu (lze doplnit brzy: iSmlouva 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ář: Na iSmlouvě jen zavedený servisní účet pro celý integrovaný systém nebo jeho jednotlivé koncové firemní zákazníky. Ten se při volání API uvádí jako navrhovatel dokumentu, který pouze "schvaluje" (nic se nikde nezaškrtává). Pokud má podepisovat někdo z firmy, je pak uveden jako jedna z podepisujících stran, přijde mu email a SMS. Pro každého zákazníka je vytvořen na iSmlouvě pracovní prostor, kde jsou jeho dokumenty a který má svůj API klíč používaný pří vládání dokumentů do jeho prostoru přes API. Další scénáře jsou možné.

...

• .