Předání podkladů

{
"settings": {
  "signing_order": "one_at_a_time",
  "autosign_proposers": "V Praze"
},
"people": [
  {
    "is_proposer": true,
    "email": "podepisujiciobchodnik@firmanavrhujicidokument.cz",
    "contract_role": "sign"
  },
  {
    "is_proposer": false,
    "party_order": 1,
    "email": "podepisujícizakazník@firmaprotistrana.cz",
    "contract_role": "sign"
  }
],

Libovolný uživatel workpace s právem podpisu jako autor/navrhovatel dokumentu může být podepsán i automaticky. Musí ale podepisovat jako první před protistranami. Pro propojení na Signi přitom lze použít API klíč zakladatele workspace. 3 pracovníci/e v HR tak mohou být na "svých" dokumentech automaticky podepsány, pouze při volání API jsou jejich maily uváděny jako emaily navrhovatele tj. “is_proposer”: true u osoby na první místě podpisového scénáře v poli Person.

Více k tématu Jaké jsou možnosti podepisování zástupců organizace používající Signi?

Jak odeslat několik dokumentů v jedné sadě?

• Posloupnost volání

  • endpoint template {.... Last_document:false… }

  • endpoint template attachment  {.... Last_document:false… }

  • endpoint template attachment  {.... Last_document:false… }

  • endpoint template attachment  {.... Last_document:true… }
    
    

• Dokument může mít neomezené množství příloh, podpis každého je účtován jako samostatný podpis.

• Pokud má člověk podepsat více dokumentů v jedné dávce, dojde mu pouze jedna SMS a e-mail. Pak se mu ukáží jednotlivé dokumenty, které musí podepsat jeden po druhém.

Několik dokumentů odeslaných v jedné sadě - například zákazníkovi přijde jeden e-mail, po jeho rozkliknutí má přístup ke všem dokumentům v sadě viz výše a může je podepsat (např. nabídku či smlouvu) či jen schválit (např.- Všeobecné podmínky).

PŘIPRAVUJEME: Výsledek podpisu každého z dokumentů se nyní předává samostatným voláním příslušného webhooku pro daný dokument. Chceme přidat volbu, kdy se webhook bude volat jen jednou pro celou odeslanou sadu.

Jak vybrat, které typy podpisu podepisující mají použít?

Signi umožňuje podepisovat více typy podpisů viz Typy podpisů v Signi. Typy podpisu se určují pro každého podepisujícího zvlášť v sekci Person, atributu "contract_role". Možné hodnoty atributu "contract_role" a odpovídající typy podpisu:

• notice - Na vědomí - Osobě pouze odchází notifikační mail při uzavření dokumentu anebo pří všech operacích na dokumentu viz více funkce “Na vědomí” a příklad volání API.

• approve - Schválit - Podepisující musí kliknout na tlačítko “Schválit”, ale jeho podpis nikde na dokumentu není vidět viz funkce Schválení.

• sign - Biometrický podpis - Podepisuje se obdobou vlastnoručního podpisu na listinném dokumentu, součástí podpisu mohou a nemusí být citlivé osobní údaje dle nastavení workspace.

• sign_bank_id_sign - BankID SIGN - Podpis přes jednu ze služeb Bankovní identity / BankID, umožnění podpisu je třeba v Signi aktivovat, jinak se vrátí chybová hláška, pro aktivaci se obraťte na sales@signi.com, a dohodnout se na způsobu provozování - buď má navrhovatel smlouvu s Bankovní identitou a v Signi využije svá nastavení služby nebo mu může Signi službu přeprodávat.

• sign_certificate - Podpis certifikátem a kvalifikovaný podpis - Podpis kvalifikovaným nebo komerčním certifikátem, umožnění podpisu je třeba v Signi aktivovat, jinak chybová hláška

  
  

  "Contract role [sign_certificate] is not enabled for this workspace"

  
  

  Pro aktivaci se obraťte na sales@signi.com. Signi kvalifikované ani komerční certifikáty nevydává, je třeba si je zajistit u certifikačních autorit typu Post Signum, 1. CA jiné vydavatele nebo specializované služby, které vám se zřízením certifikátů pomohou.

  
  

Konkrétní příklady volání Signi API s různými typy podpisů viz Příklad 2 - Předání PDF dokumentu k podpisu.

Dočasná omezení voleb typu podpisů:

Více typů podpisu u jednoho podepisujícího
Zatím nelze u jednoho podepisujícího kombinovat více typů podpisů např. biometrický anebo BankID SIGN.

Kvalifikované podpisy
Z principu není možné automatické vložení podpisu.
V jednom podpisovém scénáři scénáři mohou být kombinované se Schválením a Na vědomí ale ne jinými typy podpisů (jinak chybová hláška "All people need to have role [approve OR sign_certificate] assigned" ).
Lze podepisovat na MS Windows a Apple Mac. Nelze podepisovat na tabletech a mobilních telefonech, která nemají nativní podporu práce s certifikáty v operačním systému, potřebná napojení na HMS pro uložení certifikátů připravujeme.
Zatím nelze kombinovat s umístěním podpisů na přidaný list Podpisového archu. Nyní předpokládáme, že s vloženým dokumentem již nelze manipulovat, pouze řídávat podpisy do podpisové vrstvy.
	
BankID SIGN
Z principu není možné automatické vložení podpisu.
V jednom podpisovém scénáři scénáři mohou být kombinované se Schválením a Na vědomí ale ne jinými typy podpisů.
Zatím nelze kombinovat s umístěním podpisů na přídaný list Podpisového archu. Nyní předpokládáme, že s vloženým dokumentem již nelze manipulovat, pouze řídávat podpisy do podpisové vrstvy.
Vkládaný dokument musí již být v podpiovém formátu PDF/A, některé banky jiný neumoňují podepsat. Konverze může vyvolat vizuální změny dokumentu, konverzi dokumentu připravujeme ji včetně jejího vynucení pří volání API.

Na vědomí	
Není ještě k dispozici na produkčním prostředí

Jak vhodně určit název dokumentu?

Název dokumentu je zároveň název souboru PDF podepsaného dokumentu, který se předává zpět do integrovaného systému anebo při stažení dokumentu z uživatelského rozhraní. Zároveň PDF soubor kontrolního list se jmenuje stejně jako PDF podepsaného dokumentu, jen v názvu je prefix KL_ .

Je tedy vhodné při integraci posílat do API v názvu dokumentu, tj. contract_name, nějakou unikátní hodnotu zároveň srozumitelnou pro podepisující. Půjde pak snadno dohledat jednoznačně jak dokument, tak jeho kontrolní list.  Zároveň je třeba myslet na to, že název dokumentu se ukazuje podepisujícím v e-mailových a SMS notifikacích, tj. není úplně vhodné posílat např. číslo samotné. Příklad správného názvu: “Čestné prohlášení k reklamaci č. 6493543”.

Jak se předávají identifikační čísla dokumentu?

• Nyní se pro identifikaci používá číslo dokumentu v Signi - Contract_ID, které je výsledkem vyvolání podpisu a je i součástí volání webhooku (v HEAD sekci).

• Pokud si chcete předávat i identifikaci dokumentu v integrovaném systému, jako workaround je možné tuto identifikaci vložit do adresy webhooků.

PŘIPRAVUJEME: Předání identifikace dokumentu v integrovaném systému v logice “vaše číslo/naše číslo” do parametrů vyvolání podpisu i webhooků.

Jdou změnit texty zasílaných e-mailů a SMS?  

• Ano, lze - je to nastavení platné pro celý workspace/pracovní prostor a může je měnit jakýkoli uživatel s přístupem do prostoru.

• Lze určit i jméno odesílatele, resp. jméno adresáta odpovědi (REPLY TO).

• Parametry v textech k záměně dle aktuálního stavu:

  • {CONTRACTNAME} - Doplní název dokumentu, pokud není vyplněn název souboru nebo použitého vzoru

  • {NAME} - Doplní celé jméno vlastníka pracovního prostoru

  • {CLIENTNAME} - Doplní celé jméno klienta - u osob jméno a příjmení, u firem?

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

• Okamžitý výsledek předání podkladů pro podpis zjistíte synchronně jako “Response” na volání příslušného endpointu.

• Pokud jsou podklady kompletní a validní, kód odezvy je 200. Chybové kódy začínají 400 , kde v body je popis chyby. Občas můžete narazit na univerzální chybu 500, snažíme se ji minimalizovat.

• V BODY odpovědi získáte i hodnotu proměnné Contract_ID, což je identifikace dokumentu v Signi. Tento údaj je pak použit ve webhooku (viz dále), lze ho použít pro stažení Kontrolního listu s průběhem podpisování dokumentu apod.

• Součástí odezvy jsou i URL unikátních adres stránek pro podpis dokumentu konkrétními podepisujícími/schvalujícími, které lze použít při integraci.

Příklady výsledků požadavku na podpis dokumentu či vzoru.