Standardně IISSP akceptuje certifikáty od následujících certifikačních autorit: První certifikační autorita (ICA), PostSignum a E-identity.

Komerční certifikát slouží k přihlášení EKISu na Portál IISSP - nahrazuje to zadávání uživatelského jména a hesla.

Kvalifikovaný certifikát slouží pro elektronické podepisování aplikačních dat (např. rezervací) zakládaných uživatelem.
Ohledně konkrétního použití kvalifikovaných certifikátů je nutné se domluvit s dodavatelem vašeho EKISu:

• Pro automatickou komunikaci platí: pokud budou uživatelé podepisovat aplikační data za sebe jako za osobu, pak musí mít osobní kvalifikovaný certifikát. Pokud EKIS zajistí vytváření digitálního podpisu na úrovni serveru pomocí kvalifikovaného serverového certifikátu, uživatelé již nemusí mít osobní certifikáty.
• Pro manuální zadávání dat nebo nahrávání dávkových souborů platí: uživatel musí vždy podepsat aplikační data, a to buď ve zdrojovém EKIS při přípravě exportního souboru nebo při vkládání/nahrávání dat na portálu IISSP.

Souhrn dalších informací k elektronickým podpisům a příslušným certifikátům naleznete ve FAQ č. 1.32.

Systém IISSP nepřiděluje přístupy do systému ABO-K České národní banky. Pokud bude Váš pracovník znát číslo rezervace např. přímo z Vašeho EKIS, není zapotřebí jej v IISSP registrovat na žádného TU. Pokud Váš pracovník potřebuje mít možnost nahlížet na stavy rezervací přímo v IISSP, pak jej registrujte na TU "Výkazník rezervací (OSS)".

Souhrn dalších informací k elektronickým podpisům a příslušným certifikátům naleznete ve FAQ č. 1.32.

Tento bod bude ještě předmětem dalších jednání.

Na základě novely zákona 218/2000 Sb. bude povinné zadávat víceleté rezervace. Státní pokladna ale nebude automaticky převádět víceleté rezervace do jednoletých v příslušném roce. Důvodem je, že pro založení takové jednoleté rezervace je nutné provést finanční kontrolu.

Víceleté rezervace budou zakládány až pro rok 2014 a další.

Minimálně pro rok 2013 se s UCB počítá, alespoň co se týče záloh na dotace. Rezervace na výdaje z těchto účtů nebudou potřeba (nejedná se o výdaje z výdajových rozpočtových účtů vedených u ČNB).

Jaké kroky máme učinit, abychom mohli testovat oblast RISRE-PS včetně integrace na ČNB?

Pro začátek testování funkcionality RISRE-PS formou end-to-end testů včetně provázání na ABO-K je třeba, aby organizační jednotka provedla následující činnosti:

• Organizační jednotka musí využívat elektronické bankovnictví ČNB (ABO-K).
• Organizační jednotka požádá standardním způsobem příslušnou pobočku ČNB o zahájení ověřování plateb v Integrovaném informačním systému Státní pokladny (IISSP) v testovacím prostředí ABO-K.
• Organizační jednotka si zvolí, které z jejích účtů bude používat v testovacím režimu pro testování rozhraní na IISSP.

V IISSP tato možnost není. Určitou možnost nabízí nastavení pravidel v rámci e-mailové komunikace v ABO-K mezi OSS a ČNB. V aplikaci IISSP RISRE-PS je k dispozici výstup zamítnutých platebních příkazů, který mohou uživatelé kdykoli spouštět a kontrolovat zamítnuté příkazy k platbě. Jak je uvedeno výše, ani tento výstup nezajišťuje aktivní odesílání informace v případě zamítnutí platebního příkazu.

4.41/
20.11.2012

K čemu je určena Předběžná rezervace? Jak ji mohu použít v praxi?

Předběžné uložení rezervace může být použito v případě, kdy uživatel není schopen zadat všechny údaje do zadávaného dokladu, resp. by tento nebylo možné uložit, protože neprojde přes všechny kontroly aplikované při "normálním" uložení dokladu. K předběžně uloženým dokladům je možné se kdykoli vrátit, dopracovat je a finálně uložit (tzn. elektronický podpis, vygenerování XML a PDF souboru).

Kromě toho je funkce předběžného pořízení použita vždy při manuálním zadávání dokladu. V okamžiku, kdy uživatel klikne na tlačítko Uložení rezervace, je provedeno nejprve předběžné uložení, následně je vyvolán applet pro elektronické podepsání dokladu, a pokud toto projde, je vygenerován odpovídající XML a PDF soubor (a tyto jsou uloženy na filesystem). V případě, kdy by v procesu autorizace a uložení rezervace došlo k jakékoli chybě (chybný certifikát, chybné heslo, chyby při generování XML apod.) a proces ukládání rezervace by nebyl korektně dokončen, uživatel má VŽDY k dispozici minimálně předběžně uložený doklad, ke kterému se může kdykoli později vrátit a dokončit přerušený proces autorizace (nepřijde tedy o zadaná data).

1. Aby bylo možné zadat příkaz k úhradě, musí existovat rezervace v IISSP. Číslo rezervace je jedním z povinných údajů pro pořízení a odeslání příkazu k platbě z rozpočtového bankovního účtu v ČNB.
2. Rezervace je v IISSP založena on-line v řádu jednotek sekund.
3. ČNB platební příkaz proti IISSP ověřuje bezprostředně po přijetí do systému ABO-K - v řádu jednotek, max. desítek minut dle množství platebních příkazů. U cizoměnových platebních příkazů je navíc ještě prováděno ověření těsně před provedením platby v den splatnosti.

Z pohledu možného načasování kroků (výdej stravenek zaměstnanci, platba faktury SODEXHO, příp. jiné společnosti, srážka ze mzdy zaměstnanci) atd., vycházíme z následujícího předpokladu (se zaměřením na přelom FR):

Nastoupí-li zaměstnanec do pracovního poměru např. 1. 12., první stravenky dostane až po ukončení prosince podle toho, na kolik stravenek má nárok. Zaměstnavatel tedy koupí tyto stravenky v lednu následujícího roku (dostane stravenky a zároveň fakturu se splatností 14 dnů). Během těch 14 dnů by měl zaměstnavatel převést odpovídající částku z účtu FKSP na výdajový rozpočtový účet (na IK, ze které bude platit fakturu), dále by měl zaměstnanci srazit příslušnou částku z výplaty a tu převést opět na IK, ze které bude platit fakturu (převodem z depozitního účtu, na kterém je celá hrubá mzda včetně příslušenství, na výdajový rozpočtový účet). Výplatní termíny jsou v první polovině měsíce, takže dříve než je splatnost faktury, proto by s tím neměl být žádný problém.

Tímto způsobem bude na příslušné IK, ze které má být uhrazena faktura rozpočet na 1/3 ceny stravenek a současně přijatou částku ve výši 2/3 ceny stravenek. Pak lze provést rezervaci a úhradu faktury.

V měsíci prosinci obdrží zaměstnavatel stravenky za listopad, rozpočet by mu měl zbývat pouze na 1/3 ceny pořízených stravenek, splatnost faktury po 15. 12. Převod z FKSP může provést bez problému, srážky z platu může udělat při zúčtování výplat za listopad, tedy v první půlce prosince. 15. 12. by tak měl mít na příslušné IK disponibilitu na celou fakturu.

Pokud je celé načasování jednotlivých kroků jiné, prosíme o upřesnění.

Lze pořídit dávkový výstup z EKISu a jako soubor jej nahrát do IISSP?

Ano, tento alternativní způsob přenosu dat mezi EKIS a IISSP je podporován. Podrobnější popis je uveden v Technickém manuálu RISRE.
Dávkově je možné přenášet:

• založení rozpočtového opatření
• založení rezervace rozpočtu
• aktualizace rezervace rozpočtu
• přeúčtování skutečnosti
  

Připravujeme pro své uživatele výstup příkazu k úhradě ve formátu FS5. Prosím o informaci, zda se pro jeden příkaz k úhradě provádí v rozpočtovém systému jedna rezervace na celkovou částku příkazu nebo se provádí více rezervací pro jednotlivé záznamy příkazu k úhradě (např. příkaz ze mzdového systému činí 300000 Kč a je tvořen záznamy:
odvod sociálního pojištění 30000, zdravotního pojištění 15000, srážkové daně 20000, zálohové daně 25000 + jednotlivé dobírky zaměstnanců).
Vytvoří se jedna rezervace na celkovou částku 300000, kterou vyplníme do záznamu příkazu k úhradě formátu FS5, nebo se vytváří více rezervací?

Poskytuje Státní pokladna IISSP bankovní výpisy?

Do UCB bude možné zasílat zálohy na dotace z výdajového rozpočtového účtu pouze na konkrétní akce, na které bylo vydáno Rozhodnutí o poskytnutí dotace. Zálohy budou hrazeny přímo z identifikací koruny (IK) daných akcí na základě založených rezervací. Výplatou zálohy dojde k čerpání rozpočtu na akci. Při konečném vyúčtování akce bude nutno vypořádat zálohu (na konci roku nutno vypořádat všechny poskytnuté zálohy) následovně:

• bude-li záloha spotřebována v plném rozsahu a ve struktuře IK, jak byla vyplacena – pak se již nic neprovádí (čerpání rozpočtu v IISSP odpovídá skutečnosti)
• bude-li záloha spotřebována v plném rozsahu, ale v jiné struktuře IK – pak je nutno provést přeúčtování skutečnosti a opravit čerpání v jednotlivých IK
• nebude-li celá záloha spotřebována – pak je nutno na dané akci snížit čerpání – buď vrácením peněz z UCB nebo přeúčtováním na zálohu jiné akce.

Pro přeúčtování skutečnosti musí být založena rezervace na té IK, na které se mají zvýšit výdaje.

Pro podepisování dokumentů a transakcí jsou podporovány SHA256 kvalifikované osobní certifikáty, resp. kvalifikované systémové certifikáty v případě externích systémů, vydané jednou z následujících certifikačních autorit: První certifikační autorita (I.CA), PostSignum a E-identity.

Souhrn dalších informací k elektronickým podpisům a příslušným certifikátům naleznete ve FAQ č. 1.32.

Aplikační data vyžadující elektronický podpis :
V Rozpočtovém informačním systému (RIS) je nutné bez výjimky elektronicky podepisovat následující aplikační data:

• Rezervace;
• Přeúčtování skutečnosti.

Podporované certifikáty:
Pro elektronické podepisování výše uvedených aplikačních dat je nutné mít kvalifikovaný certifikát vystavený jednou z následujících akreditovaných certifikačních autorit ČR (viz také Technický manuál RISRE):

• První certifikační autorita a.s. (ICA) – http://www.ica.cz/
• Česká pošta s.p. – https://qca.postsignum.cz/
• eIdentity a.s. – http://www.eidentity.cz/.

Zasílání dat přes automatizované rozhraní:
Pro zasílání dat přes rozhraní je nutno použít jednu z uvedených možností:

• kvalifikovaný osobní certifikát uživatele zodpovědného za daná aplikační data,
• kvalifikovaný systémový certifikát (elektronickou značku) serveru (EKIS), který data zasílá.

Zasílání nebo zadávání dat přes Portál IISSP:
V případě podpisu aplikačních dat uživatelem na Portálu IISSP musí být kvalifikovaný osobní certifikát dostupný podepisovací komponentě IISSP jedním z uvedených způsobů:

• ve standardním systémovém úložišti MS Windows;
• v úložišti JKS (Java Key Store);
• na lokálním, USB nebo síťovém disku ve formátu .p12 nebo .pfx;
• na hardwarovém bezpečném úložišti:
• čipových kartách ICA spolu s implementací dodávaného software „Secure store“;
• klíči Postsignum spolu s implementací software dodávaný spolu s bezpečným USB klíčem „Rainbow“;
• čipových kartách .NET GEMALTO s příslušnými ovladači.

V případě použití čipových karet je nutné, aby byl nainstalován příslušný ovladač specifický této kartě (implementace pkcs#11).

Pokud umožňuje SW dodávaný spolu s čipovou kartu mapovat obsah karty do systémového úložiště MS Windows, bude s největší pravděpodobností podepisování na Portále IISSP funkční taktéž.  

Pokud masově používáte jiný typ čipové karty, která nespolupracuje s RIS  a tento problém jste navzdory doporučenému postupu neodhalili již během testování na prostředí Testování třetích stran RISRE, zadejte svůj případný požadavek na rozšíření existujících způsobů elektronického podepisování dat RIS na ServiceDesk STC. Do požadavku je nutné uvést všechny potřebné související informace: typ karty, dodavatele karty, certifikační autoritu a předpokládaný počet pracovních stanic, na kterých je předpokládaná implementace. Do případného vyřešení zmíněného požadavku je ovšem nutné zajistit elektronické podepisování dat .

Dále upozorňujeme, že pokud je k pracovní stanici uživatele RIS připojeno více čteček, nemusí elektronické podepisování pracovat korektně. V takovém případě odpojte všechny nepoužívané čtečky a ponechte pouze jednu čtečku podporovanou ze strany RIS.