SMLOUVA O DODÁVCE A IMPLEMENTACI ERP A POSKYTOVÁNÍ SLUŽEB
SMLOUVA O DODÁVCE A IMPLEMENTACI ERP A POSKYTOVÁNÍ SLUŽEB
Dnešního dne následující smluvní strany:
Objednatel: Kroměřížská nemocnice a.s.
zastoupená: Ing. Xxxxxx Xxxxxxxx, MBA, místopředsedou představenstva Zapsána v obchodním rejstříku u Krajského soudu v Brně, sp. zn. B 4416
se sídlem: Havlíčkova 660/69, 767 01 Kroměříž
IČO: 27660532
DIČ: CZ27660532
bankovní spojení: XXX
číslo účtu: XXX
a
Poskytovatel: OR-NEXT spol. s r.o.
se sídlem: Hlinky 40/102, 603 00 Brno
IČO: 26284146
DIČ: CZ26284146
bankovní spojení: XXX
číslo účtu: XXX
zastoupena: Ing. Xxxxxx Xxxxxxxx, jednatelem
zapsaná v obchodním rejstříku vedeném Krajským soudem v Brně, sp. zn. C 41856 (dále jen „Poskytovatel“)
(Objednatel a Poskytovatel dále jednotlivě též jen „Smluvní strana“ nebo společně „Smluvní strany“)
uzavírají v souladu s § 1746 odst. 2 zák. č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „OZ“) s přihlédnutím k § 2586 a násl. OZ tuto
Smlouvu o dodávce a implementaci ekonomického informačního systému a
poskytování služeb (dále jen „Smlouva“)
I. ÚVODNÍ USTANOVENÍ
1.1 Smlouva se mezi výše uvedenými Smluvními stranami uzavírá na základě výsledku zadávacího řízení na veřejnou zakázku s názvem „Ekonomický informační systém pro nemocnice Zlínského kraje“ zadávanou Objednatelem jako zadavatelem ve smyslu zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „ZZVZ“), v němž byla nabídka Poskytovatele vybrána jako nejvýhodnější (dále jen „Veřejná zakázka“).
1.2 Smluvní strany prohlašují, že osoby podepisující Smlouvu jsou k tomuto úkonu oprávněny.
1.3 Poskytovatel prohlašuje, že se seznámil se zadávací dokumentací Veřejné zakázky, včetně všech jejích příloh (dále jen „Zadávací dokumentace“), že ji považuje za dostatečný podklad pro plnění Veřejné zakázky, a to zejména v rozsahu nezbytném pro plnění předmětu Smlouvy, přičemž mu nejsou známy žádné nejasnosti či pochybnosti, které by znemožňovaly řádné plnění jeho závazku dle Xxxxxxx.
1.4 Poskytovatel dále prohlašuje, že se detailně seznámil s rozsahem a povahou předmětu plnění Smlouvy, že jsou mu známy veškeré relevantní technické, kvalitativní a jiné podmínky nezbytné pro realizaci předmětu plnění Smlouvy, a že disponuje takovými kapacitami a odbornými znalostmi, které jsou nezbytné pro realizaci předmětu plnění Smlouvy za dohodnuté maximální smluvní ceny uvedené ve Smlouvě, a to rovněž ve vazbě na jím prokázanou kvalifikaci pro plnění Veřejné zakázky a informace doložené za účelem hodnocení nabídky dle kritéria hodnocení „Kvalita realizačního týmu“.
1.5 Poskytovatel dále prohlašuje, že jím poskytované plnění odpovídá všem požadavkům vyplývajícím z platných právních předpisů, které se na plnění vztahují.
1.6 Pojmy s velkými počátečními písmeny definované ve Xxxxxxx budou mít význam, jenž je jim ve Xxxxxxx, včetně jejích příloh a dodatků, připisován. Pro vyloučení jakýchkoliv pochybností se Smluvní strany dále dohodly, že:
• v případě jakékoliv nejistoty ohledně výkladu ustanovení Smlouvy budou tato ustanovení vykládána tak, aby v co nejširší míře zohledňovala účel Veřejné zakázky vyjádřený Zadávací dokumentací;
• Poskytovatel je vázán svou nabídkou předloženou Objednateli v rámci zadávacího řízení Veřejné zakázky, která se pro úpravu vzájemných vztahů vyplývajících ze Smlouvy použije subsidiárně.
1.7 Není-li výslovně ve Smlouvě u lhůt či dob uvedeno, že příslušné dny jsou pracovní, jedná se o dny kalendářní.
II. ÚČEL SMLOUVY
2.1 Základním účelem, k jehož dosažení se Smlouva uzavírá, je řádné poskytování plnění Poskytovatelem spočívající v dodávce a implementaci informačního systému (dále jen
„ERP“) dle specifikace obsažené v této smlouvě a zajištění podpory implementovaného ERP.
III. PŘEDMĚT SMLOUVY
3.1 Předmětem plnění je dodávka, implementace a následná údržba a podpora provozu (dále jen „Podpora“) a rozvoj ERP.
3.2 ERP bude dodán dle nabídky Poskytovatele, kterou Poskytovatel podal v Zadávacím řízení, jež je Přílohou 2 Smlouvy.
3.3 Požadavky na dodání EIS, včetně HW, licence základního SW, DB a Aplikačního SW, na počet uživatelů a na implementaci, jsou definovány v Příloze č. 1.1 Smlouvy a v Příloze
1.2 Smlouvy.
3.4 Postup implementace ERP je definován Přílohou 1.3 Smlouvy.
3.5 Úroveň Poskytovatelem zajišťované Podpora je definovaná Přílohou 1.4 Smlouvy.
3.6 Poskytovatel se zavazuje poskytovat plnění v souladu s platnými právními předpisy, jakož i v souladu se všemi relevantními normami obsahujícími technické specifikace a technická řešení, technické a technologické postupy nebo jiná určující kritéria k zajištění, že materiály, výrobky, postupy a služby vyhovují předmětu Smlouvy a veškerým podmínkám uvedeným v Zadávací dokumentaci.
3.7 Poskytovatel prohlašuje, že předmět plnění dle Smlouvy není plněním nemožným, a že Xxxxxxx uzavírá po pečlivém zvážení všech možných důsledků. Poskytovatel dále prohlašuje, že se seznámil s předmětem plnění dle Smlouvy, a že plnění může být poskytnuto způsobem a v termínech stanovených ve Smlouvě.
3.8 Objednatel se zavazuje zaplatit Poskytovateli za řádně poskytnuté plnění v souladu se všemi podmínkami Smlouvy sjednanou cenu dle Smlouvy.
IV. LHŮTA A MÍSTO PLNĚNÍ
4.1 Poskytovatel se zavazuje poskytnout plnění vyjma Podpory nejpozději ve lhůtě do 36 týdnů od nabytí účinnosti Smlouvy. Poskytovatel bere podpisem Xxxxxxx na vědomí, že plnění musí být poskytnuto (předáno a Objednatelem převzato) tak, aby nebylo ohroženo kofinancování předmětu plnění dle podmínek poskytovatele dotace. Proto bude Objednatel oprávněn písemně odstoupit od Smlouvy, pokud od Poskytovatele neobdrží bez zbytečného odkladu po výzvě Objednatele jednoznačnou garanci toho, že je schopen řádně provést plnění i ve lhůtě kratší, než je uvedeno v první větě tohoto odstavce a nebude tak svým plnění schopen zachovat podmínky pro poskytnutí dotace Objednateli. Součástí takové garance Poskytovatele musí rovněž být příslušný (aktualizovaný) harmonogram plnění, který bude deklarovat schopnost řádného a včasného plnění v souladu s podmínkami poskytovatele dotace.
Služby Podpory a služby rozvoje budou poskytovány na dobu neurčitou.
4.2 Místem předání a převzetí plnění je sídlo Objednatele, není-li mezi Smluvními stranami výslovně dohodnuto jinak. Přípravné a programovací práce je Poskytovatel oprávněn realizovat na svém vlastním technickém vybavení, což však nezakládá jakýkoliv nárok Poskytovatele na navýšení ceny plnění v souvislosti s převodem na cílovou infrastrukturu Objednatele. Pokud to povaha konkrétního plnění umožňuje, bude Poskytovatel
oprávněn poskytovat plnění také vzdáleným přístupem, přičemž Poskytovatel vždy zajistí adekvátní bezpečnost připojení a odpovídající ochranu zařízení, které použije pro vzdálený přístup na základě dohody s Objednatelem.
4.3 Veškeré písemné výstupy, které je podle Xxxxxxx Poskytovatel povinen vytvořit a/nebo které při plnění Smlouvy vzniknou, budou Poskytovatelem Objednateli předány v sídle Objednatele, nebude-li mezi Smluvními stranami v konkrétním případě dohodnuto jinak.
V. CENA PLNĚNÍ A PLATEBNÍ PODMÍNKY
5.1 Cena za poskytování plnění je sjednána dohodou Smluvních stran následovně:
Položka | Cena (Kč bez DPH) | Platební podmínky | Cena Podpory na 5 let (Kč bez DPH) |
Hardware | 1.250.000,- | 100 % ceny po dodání | v ceně pořízení |
Licence základního SW | v řádku níže | 100 % ceny po dodání | v řádku níže |
Licence aplikačního SW a DB | 2.850.000,- | 100 % ceny po dodání | 2.232.000,- |
Implementační práce, vč. integrace do prostředí zadavatele, migrace a školení | 4.330.000,- | Po akceptaci jednotlivých fází: - fáze 1: 20 % - fáze 2: 30 % - fáze 3: 20 % - fáze 4: 10 % - fáze 5: 20 % (definice fází je obsažena v Příloze č. 1.3 Smlouvy) | 1.960.000,- |
Cena celkem | 8.430.000,- | 4.192.000,- |
Cena za poskytování služeb Podpory bude fakturována měsíčně od prvního měsíce následujícího po podpisu předávacího protokolu. Výše hrazené měsíční částky bude jedna šedesátina ceny za Podporu na pět let ve výše uvedené tabulce.
Práce na požadavcích uživatelských úprav, opravy chyb a služby rozvoje dle Přílohy 1.4 se účtují hodinovou sazbou. Sazby těchto prací jsou uvedeny v následující tabulce. Sazby obsahují veškeré vedlejší náklady. Účtuje se každá započatá půlhodina. Minimální účtované množství je půl hodina pro práci vzdáleně a 4 hodiny pro práci na místě. Práce se fakturují vždy po uplynutí 3 měsíců, a to po potvrzení výkazu práce Objednatelem.
Cena za poskytnutí služeb rozvoje je stanovena jako jednotková cena, kdy jednotkou je jedna člověkohodina a činí 500,- Kč bez DPH, tj. 605,- Kč včetně DPH ve výši 21 % za jednu člověkohodinu služeb rozvoje.
5.2 Součástí cen uvedených v tomto článku Smlouvy jsou i služby a dodávky nezbytné pro řádné a úplné poskytování předmětu plnění. Poskytovatel nese veškeré náklady nutně nebo účelně vynaložené při plnění závazků ze Smlouvy včetně správních poplatků a nákladů souvisejících (zejména daně, pojištění, veškeré dopravní náklady, včetně nákladů souvisejících s provedením všech zkoušek a testů prokazujících dodržení předepsané kvality a parametrů předmětu plnění dle Smlouvy, jakož nákladů souvisejících se zajištěním dalších podkladů, předpisů apod.).
5.3 Není-li výslovně uvedeno jinak, veškeré ceny uvedené v tomto článku Smlouvy jsou ceny v korunách českých (CZK). Stane-li se v průběhu trvání Smlouvy Česká republika členem Evropské měnové unie a bude-li v závazně stanoven koeficient pro přepočet CZK na EUR, budou ceny sjednané v CZK přepočteny do EUR na základě odpovídajícího koeficientu sjednaného v mezinárodních úmluvách, kterými bude Česká republika vázána, jakož i v souladu s případnou tomu odpovídající vnitrostátní právní úpravou České republiky.
5.4 Veškeré ceny uvedené v tomto článku Smlouvy jsou cenami maximálními, nejvýše přípustnými, nepřekročitelnými a jsou platné a konstantní po celou dobu platnosti Smlouvy, není-li uvedeno jinak. Cenu plnění je možné změnit v případě změny výše sazby DPH v důsledku změny právních předpisů. V případě změny sazby DPH je Poskytovatel povinen k ceně bez DPH účtovat DPH v platné výši. Smluvní strany se dohodly, že v případě změny ceny v důsledku změny sazby DPH není nutno ke Smlouvě uzavírat dodatek. Poskytovatel odpovídá za to, že sazba daně z přidané hodnoty je stanovena v souladu s platnými právními předpisy.
5.5 Ceny dle Smlouvy budou hrazeny na základě daňových dokladů vystavených Poskytovatelem (dále jen „Faktura“ či „Faktury“).
5.6 Kopie příslušných akceptačních protokolů podepsaných pověřenými zástupci obou Smluvních stran jsou povinnou náležitostí každé Faktury vystavené Poskytovatelem za poskytnutí plnění (či jeho části) dle Smlouvy. V případě, že plnění není akceptováno některým z uvedených způsobů, Poskytovatel není oprávněn vystavit příslušnou Fakturu, není-li výslovně uvedeno jinak.
5.7 Faktury musí obsahovat evidenční číslo Smlouvy a veškeré údaje vyžadované právními předpisy, zejména zákonem č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, a § 435 OZ.
5.8 Splatnost Faktur je stanovena do 30 (třiceti) dnů ode dne doručení Faktury Objednateli. Cena za poskytnutí plnění či jeho části se považuje za uhrazenou okamžikem odepsání fakturované ceny z bankovního účtu Objednatele ve prospěch účtu Poskytovatele. Uvedený bankovní účet musí být zveřejněn správcem daně způsobem umožňujícím dálkový přístup. V případě, že účet tímto způsobem zveřejněn nebude, je Objednatel
oprávněn uhradit Poskytovateli cenu na úrovni bez DPH, DPH Objednatel poukáže správci daně. Stane-li se Poskytovatel nespolehlivým plátcem ve smyslu § 106a zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, je povinen neprodleně o tomto písemně informovat Objednatele.
5.9 Nebude-li jakákoliv Faktura obsahovat některou povinnou nebo dohodnutou náležitost nebo bude-li chybně vyúčtována cena nebo DPH, je Objednatel oprávněn tuto fakturu před uplynutím lhůty splatnosti bez zaplacení vrátit Poskytovateli k provedení opravy s vyznačením důvodu vrácení. Poskytovatel provede opravu vystavením nové faktury. Vrácením vadné faktury Poskytovateli přestává běžet původní lhůta splatnosti. Nová lhůta splatnosti běží ode dne vystavení nové faktury.
5.10 Objednatel neposkytuje Poskytovateli na cenu předmětu plnění jakékoliv zálohy.
5.11 Poskytovatel není oprávněn započíst jakékoliv pohledávky proti nárokům Objednatele. Pohledávky a nároky Poskytovatele vzniklé v souvislosti se Smlouvou nesmějí být postoupeny třetím osobám, zastaveny, nebo s nimi jinak disponováno. Jakýkoliv právní úkon učiněný Poskytovatelem v rozporu s tímto ustanovením Smlouvy bude považován za příčící se dobrým mravům.
5.12 Objednatel si vyhrazuje právo změny závazku z této smlouvy ve smyslu ustanovení bodu
8.2. Zadávací dokumentace. Poskytovatel prohlašuje, že si je této výhrady vědom, a pro případ uplatnění tohoto práva Objednatelem se zavazuje postupovat v souladu s takovou změnou závazku.
VI. PŘEDÁVÁNÍ A PŘEVZETÍ PLNĚNÍ
6.1 Postup předávání a přebírání plnění (fáze 1 – 5) je dán Přílohou 1.3 Smlouvy.
6.2 Postup zadávání a přebírání služeb Podpory a služeb rozvoje je dán Přílohou 1.4 Smlouvy.
VII. DALŠÍ PRÁVA A POVINNOSTI SMLUVNÍCH STRAN
7.1 Poskytovatel je povinen:
7.1.1 poskytovat řádně a včas plnění podle Xxxxxxx bez faktických a právních vad;
7.1.2 postupovat při plnění předmětu Xxxxxxx s odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy Objednatele a postupovat v souladu s jeho pokyny a interními předpisy souvisejícími s předmětem plnění Xxxxxxx (či jeho dílčí části), které Objednatel Poskytovateli poskytne, nebo s pokyny jím pověřených osob;
7.1.3 bez zbytečného odkladu oznámit Objednateli veškeré skutečnosti, které mohou mít vliv na povahu nebo na podmínky poskytování plnění dle Smlouvy. Zejména je povinen neprodleně písemně oznámit Objednateli změny svého majetkoprávního postavení, jako je např. přeměna společnosti, vstup do likvidace, úpadek či prohlášení konkurzu;
7.1.4 informovat bezodkladně Objednatele o jakýchkoliv zjištěných překážkách plnění, byť by za ně Poskytovatel neodpovídal, o vznesených požadavcích orgánů
státního dozoru a o uplatněných nárocích třetích osob, které by mohly plnění dle Smlouvy ovlivnit;
7.1.5 poskytnout Objednateli veškerou nezbytnou součinnost k naplnění účelu Smlouvy;
7.1.6 na žádost Objednatele spolupracovat či poskytnout součinnost dalším dodavatelům Objednatele;
7.1.7 provádět svoje činnosti tak, aby nebyl v nadbytečném rozsahu omezen provoz dotčených pracovišť Objednatele;
7.1.8 dodržovat provozní řád v místě plnění a provádět svoje činnosti tak, aby nebyl v nadbytečném rozsahu omezen provoz na pracovištích Objednatele. Poskytovatel zajistí, aby všechny osoby, které se na jeho straně podílí na plnění předmětu Smlouvy, a které budou přítomny v prostorách Objednatele, dodržovaly všechny bezpečnostní a provozní předpisy tak, jak s nimi byly seznámeny Objednatelem;
7.1.9 informovat Objednatele na jeho žádost o průběhu plnění předmětu Xxxxxxx a akceptovat jeho pokyny a připomínky k plnění předmětu Smlouvy;
7.1.10 použít veškeré podklady předané mu Objednatelem pouze pro účely Smlouvy a zabezpečit jejich řádné vrácení Objednateli, bude-li to objektivně možné vzhledem k jejich povaze a způsobu použití.
7.2 Objednatel se zavazuje poskytnout Poskytovateli součinnost potřebnou k řádné realizaci předmětu Smlouvy, kterou je po něm Poskytovatel jako osoba, která disponuje takovými kapacitami a odbornými znalostmi, které jsou nezbytné pro realizaci předmětu plnění Smlouvy, oprávněna požadovat.
7.3 Objednatel je v souvislosti s plněním předmětu Smlouvy oprávněn zejména udělovat Poskytovateli závazné pokyny pro výkon všech činností, ke kterým se Poskytovatel na základě Smlouvy zavázal; tyto pokyny jsou závazné, není tím však dotčena odpovědnost Poskytovatele za včasné upozornění Objednatele na jejich nevhodnou povahu.
7.4 Objednatel má právo přesvědčit se kdykoliv v průběhu realizace plnění Smlouvy o stavu realizace plnění a Poskytovatel mu k tomuto musí vytvořit přiměřené podmínky, případné náklady nese Poskytovatel.
7.5 Pokud se Smluvní strany nedohodnou jinak, součinnost zaměstnanců Objednatele dle Smlouvy bude poskytována pouze v pracovní dny v pracovní době (od 8:00 do 15:00) a u jednotlivých rolí bude omezena na max. tři dny v týdnu. Poskytovatel je povinen vyzvat k poskytnutí přiměřené součinnosti v předstihu.
VIII. PODDODAVATELÉ, REALIZAČNÍ TÝM A OPRÁVNĚNÉ OSOBY
8.1 Poddodavatelé
8.1.1 Poskytovatel se zavazuje plnění předmětu Smlouvy provést sám, nebo s využitím poddodavatelů, uvedených spolu s rozsahem jejich plnění v Příloze č. 4 Smlouvy. Poskytovatel je povinen písemně informovat Objednatele o všech svých poddodavatelích (včetně jejich identifikačních a kontaktních údajů a o
tom, které služby pro něj v rámci předmětu plnění každý z poddodavatelů poskytuje) a o jejich změně, a to ve smyslu ust. § 105 odst. 3 ZZVZ.
8.1.2 Poskytovatel je oprávněn změnit poddodavatele, pomocí něhož prokázal část splnění kvalifikace v rámci zadávacího řízení Veřejné zakázky, na základě něhož byla uzavřena Smlouva, jen z vážných objektivních důvodů a s předchozím písemným souhlasem Objednatele, přičemž nový poddodavatel musí disponovat kvalifikací ve stejném či větším rozsahu, který původní poddodavatel prokázal za Poskytovatele. Objednatel nesmí souhlas se změnou poddodavatele bez objektivních důvodů odmítnout, pokud mu budou příslušné doklady ve stanovené lhůtě předloženy.
8.1.3 Zadání provedení části plnění dle Smlouvy poddodavateli Poskytovatelem nezbavuje Poskytovatele jeho výlučné odpovědnosti za řádné provedení plnění dle Smlouvy vůči Objednateli. Poskytovatel odpovídá Objednateli za plnění předmětu Smlouvy, které svěřil poddodavateli, ve stejném rozsahu, jako by jej poskytoval sám.
8.2 Realizační tým
8.2.1 Poskytovatel určuje k plnění předmětu Smlouvy realizační tým. Jmenné složení realizačního týmu je uvedeno v Příloze č. 5 Smlouvy (dále jen „Realizační tým“). Poskytovatel se zavazuje zachovávat po celou dobu plnění předmětu Smlouvy profesionální složení Realizačního týmu v souladu s požadavky stanovenými ve Smlouvě.
8.3 Oprávněné osoby
8.3.1 Každá ze Smluvních stran dále jmenuje oprávněné osoby, které budou vystupovat jako zástupci Smluvních stran. Oprávněné osoby zastupují Smluvní stranu ve smluvních a technických záležitostech souvisejících s plněním předmětu Smlouvy, zejména podávají a přijímají informace o průběhu plnění Smlouvy a dále:
- osoby oprávněné ve věcech smluvních jsou oprávněny vést s druhou Smluvní stranou jednání obchodního charakteru, jednat v rámci akceptačních procedur při předávání a převzetí plnění dle čl. VI Smlouvy, zejména podepisovat příslušné akceptační či jiné protokoly dle Smlouvy.
8.3.2 Oprávněné osoby budou oprávněny činit rozhodnutí závazná pro Smluvní strany ve vztahu ke Smlouvě v rámci své pravomoci. Oprávněné osoby, nejsou-li statutárními orgány, však nejsou oprávněny provádět změny ani zrušení Smlouvy, nebude-li jim udělena speciální plná moc.
8.3.3 Oprávněnými osobami za Objednatele jsou:
i) ve věcech smluvních: Xxx. Xxxxxxx Xxxx, projektový manažer
ii) ve věcech technických: Xxx. Xxxxxxx Xxxx, projektový manažer
8.3.4 Oprávněnými osobami za Poskytovatele jsou:
(i) ve věcech smluvních: Xxx. Xxxx Xxxxxxx, jednatel
(ii) ve věcech technických: Xxx. Xxxxxx Xxxxxxxxxx, projektový manažer
Xxxxxxxx Xxxxxx, zástupce projektového manažera
8.3.5 Každá ze Smluvních stran má právo změnit jí jmenované oprávněné osoby, musí však o každé změně vyrozumět písemně druhou Smluvní stranu. Změna oprávněných osob je vůči druhé Smluvní straně účinná okamžikem, kdy o ní byla písemně vyrozuměna.
IX. VLASTNICKÉ PRÁVO, NEBEZPEČÍ ŠKODY NA VĚCI A PRÁVO UŽITÍ
9.1 Poskytovatel prohlašuje, že vlastnické právo a nebezpečí škody na věci ke všem hmotným součástem plnění předmětu Smlouvy předaným Poskytovatelem Objednateli v souvislosti s plněním předmětu Smlouvy přechází na Objednatele dnem jejich předání Objednateli. Poskytovatel prohlašuje, že právo k software (licence), jež jsou součástí plnění předmětu Smlouvy poskytnuty Poskytovatelem Objednateli, přechází na Objednatele dnem jejich předání Objednateli.
9.2 Vzhledem k tomu, že součástí plnění dle Smlouvy je i plnění, které může naplňovat znaky autorského díla ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech
souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů (dále jen „AZ“), je k těmto součástem plnění poskytována licence za podmínek sjednaných dále v tomto článku Smlouvy.
9.2.1 Objednatel je oprávněn veškeré součásti plnění Poskytovatele považované za autorské dílo ve smyslu AZ (dále jen „Autorské dílo“) užívat dle níže uvedených podmínek.
9.2.2 Objednatel je oprávněn Autorské dílo užívat dle níže uvedených licenčních podmínek (dále jen „Licence“), a to od okamžiku účinnosti poskytnutí Licence, přičemž Poskytovatel poskytuje Objednateli Licenci s účinností, která nastává okamžikem předání plnění či jeho části, jehož je Autorské dílo součástí.
9.2.3 Nevyplývá-li z příloh Smlouvy jinak, je Licence udělena jako nevýhradní k užití Autorského díla Objednatelem k jakémukoliv účelu a v rozsahu, v jakém uzná za nezbytné, vhodné či přiměřené. Pro vyloučení všech pochybností to znamená, že:
- Licence je udělena jako neodvolatelná;
- Licence je dále udělena na dobu určitou, a to po celou dobu trvání majetkových práv autorských k Autorskému dílu, bez omezení územního rozsahu;
- v případě SW, který je součástí plnění, se Licence vztahuje ve stejném rozsahu i na případné další verze tohoto SW upraveného na základě Smlouvy;
- Objednatel je bez potřeby jakéhokoliv dalšího svolení Poskytovatele oprávněn udělit třetí osobě podlicenci k užití Autorského díla nebo svoje oprávnění k jejímu užití třetí osobě postoupit;
- Licence je převoditelná pro případ, že dojde ke sloučení (fúzi či jinému spojení) Objednatele s jiným nemocničním zařízením(i) na území Zlínského kraje (tedy změny IČO);
- Licenci není Objednatel povinen využít, a to ani zčásti.
9.2.4 Současně Poskytovatel uděluje Objednateli souhlas ode dne účinnosti poskytnuté Licence dle Xxxxxxx provádět jakékoliv modifikace, úpravy, změny Autorského díla a dle svého uvážení do něj zasahovat, zapracovávat jej do dalších autorských děl, zařazovat jej do děl souborných či do databází apod., a to i prostřednictvím třetích osob.
9.2.5 V souvislosti s poskytnutou Licencí je Poskytovatel povinen, s výjimkami uvedenými v odst. 9.3 Smlouvy a 9.4 Smlouvy, nejpozději ke dni ukončení akceptace plnění či jeho části předat Objednateli zdrojový kód každé jednotlivé části Autorského díla, která je počítačovým programem, a která je Objednateli poskytována na základě plnění dle Smlouvy jako customizované plnění, aby s ním mohl Objednatel libovolně nakládat. Pro účely této Smlouvy se customizovaným plněním rozumí veškeré úpravy řešení dle požadavků Objednatele. Zdrojový kód musí být spustitelný v prostředí Objednatele a zaručovat možnost ověření, že je kompletní a ve správné verzi, tzn. umožňující kompilaci, instalaci, spuštění a
ověření funkcionality, a to včetně podrobné dokumentace zdrojového kódu. Zdrojový kód bude Objednateli Poskytovatelem předán na nepřepisovatelném technickém nosiči dat s viditelně označeným názvem „Zdrojový kód“ a označením počítačového programu či její části a jeho verze a dne předání zdrojového kódu. O předání technického nosiče dat bude oběma Smluvními stranami sepsán a podepsán písemný předávací protokol.
9.3 Je-li součástí plnění tzv. proprietární software (dále jen „Proprietární software“), u kterého Poskytovatel nemůže poskytnout Objednateli oprávnění dle odst. 9.2.1 až 9.2.5 Smlouvy nebo to po něm nelze spravedlivě požadovat, postačí, aby Objednatel nabyl k takovému software nevýhradní oprávnění užít jej jakýmkoli způsobem nejméně po dobu trvání Smlouvy, bez územního omezení a v množstevním rozsahu, který je nezbytný pro pokrytí potřeb Objednatele ke dni uzavření Smlouvy. Smluvní strany výslovně uvádějí, že součástí takového nevýhradního oprávnění nemusí být právo provádět modifikace, úpravy či změny Proprietárního software či dle svého uvážení Objednatele do něj zasahovat, zapracovávat ho do dalších autorských děl, zařazovat ho do děl souborných či do databází apod., a to i prostřednictvím třetích osob, ani se u Proprietárního software nezbytně nevyžaduje poskytnutí zdrojových kódů k takovému software; v případě, že Poskytovatel oprávnění ve shora uvedeném rozsahu poskytuje, Objednatel je oprávněn je využít. Konkrétní rozsah udělovaných práv k Proprietárnímu software je vymezen společně s dalšími údaji o tomto software v Příloze č. 7 této Smlouvy.
9.4 Je-li součástí plnění tzv. open source software, u kterého Poskytovatel nemůže poskytnout Objednateli oprávnění dle odst. 9.2.1 až 9.2.5 Smlouvy nebo dle odst. 9.3 Smlouvy nebo to po něm nelze spravedlivě požadovat, je Poskytovatel povinen zajistit, aby se jednalo o open source software, který je veřejnosti poskytován zdarma, včetně zdrojových kódů, úplné původní uživatelské, provozní a administrátorské dokumentace a práva takový software měnit.
9.5 Udělení veškerých práv uvedených v tomto článku Smlouvy nelze ze strany Poskytovatele vypovědět a na jejich udělení nemá vliv ukončení účinnosti Smlouvy.
9.6 Poskytovatel prohlašuje, že veškeré jím dodané plnění podle Xxxxxxx bude prosté právních vad a zavazuje se odškodnit v plné výši Objednatele v případě, že třetí osoba úspěšně uplatní autorskoprávní nebo jiný nárok plynoucí z právní vady poskytnutého plnění dle Xxxxxxx. V případě, že by nárok třetí osoby vzniklý v souvislosti s plněním Poskytovatele podle Xxxxxxx, bez ohledu na jeho oprávněnost, vedl k dočasnému či trvalému soudnímu zákazu či omezení užívání ERP či jeho části, zavazuje se Poskytovatel zajistit náhradní řešení a minimalizovat dopady takovéto situace, a to bez dopadu na cenu plnění sjednanou podle Smlouvy, přičemž současně nebudou dotčeny ani nároky Objednatele na náhradu škody.
9.7 S nositeli chráněných práv duševního vlastnictví vzniklých v souvislosti s realizací plnění dle Smlouvy je Poskytovatel povinen vždy smluvně zajistit možnost nakládání s těmito právy Objednatelem v rozsahu definovaném tímto článkem Smlouvy.
9.8 Poskytovatel podpisem Smlouvy výslovně prohlašuje, že odměna za veškerá oprávnění poskytnutá Objednateli dle tohoto článku Smlouvy je již zahrnuta v ceně za poskytování plnění dle Smlouvy.
9.9 Poskytovatel je povinen Objednateli uhradit jakékoli majetkové a nemajetkové újmy, vzniklé v důsledku toho, že Objednatel v rozporu s tímto článkem Smlouvy nemohl předmět plnění Smlouvy (Autorské dílo) užívat řádně a nerušeně.
X. ODPOVĚDNOST ZA ŠKODU, ODPOVĚDNOST ZA VADY, ZÁRUKA
10.1 Smluvní strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod. Smluvní strany nesou odpovědnost za škodu dle platných a účinných právních předpisů a Smlouvy. Poskytovatel odpovídá za škodu rovněž v případě, že část plnění poskytuje prostřednictvím poddodavatele.
10.2 Žádná ze stran není odpovědná za škodu vzniklou porušením povinnosti ze Smlouvy, prokáže-li, že mu ve splnění povinnosti ze Smlouvy dočasně nebo trvale zabránila mimořádná nepředvídatelná a nepřekonatelná překážka vzniklá nezávisle na jeho vůli. Překážka vzniklá ze škůdcových osobních poměrů nebo vzniklá až v době, kdy byl škůdce s plněním povinnosti ze Smlouvy v prodlení, ani překážka, kterou byl škůdce podle Xxxxxxx povinen překonat, ho však povinnosti k náhradě nezprostí. Smluvní strany se zavazují upozornit druhou stranu bez zbytečného odkladu na vzniklé překážky bránící řádnému plnění Smlouvy a dále se zavazují k vyvinutí maximálního úsilí k jejich odvrácení a překonání.
10.3 Poskytovatel odpovídá za škodu do výše celkové sjednané ceny plnění za fáze 1 – 5 (bez DPH). Škoda se hradí v penězích, nebo, je-li to možné nebo účelné, uvedením do předešlého stavu podle volby poškozené strany v konkrétním případě.
10.5 Poskytovatel přebírá závazek a odpovědnost za vady plnění, jež bude mít plnění (či jeho dílčí část) v době jeho předání Objednateli a dále za vady, které se na plnění (či jeho dílčí části) vyskytnou v průběhu záruční doby. Poskytovatel v souvislosti s odpovědností za vady plnění poskytuje Objednateli níže specifikovanou záruku.
10.6 Poskytovatel poskytuje Objednateli ve smyslu § 2619 OZ záruku za jakost v min. délce 6 (slovy: šest) měsíců na to, že předané plnění bude mít vlastnosti stanovené Smlouvou a Cílovým konceptem (u části plnění odpovídající službám rozvoje případně i vlastnosti stanovené příslušnou objednávkou), bude bez jakýchkoliv nedodělků či vad. Záruční
doba počíná běžet u části plnění odpovídajícího Fázi 1 až Fázi 5 ode dne předání a převzetí fáze 5 Objednatelem, u části plnění odpovídající službám rozvoje vždy ode dne předání a převzetí příslušného plnění.
10.7 Záruční doba neběží po dobu, po kterou Objednatel nemůže užívat plnění či jeho část pro vady, za které odpovídá Poskytovatel. Veškeré činnosti nutné či související s vyřízením reklamací vad činí Poskytovatel sám na své náklady v součinnosti s Objednatelem a v jeho provozní době tak, aby svými činnostmi neohrozil nebo neomezil činnost Objednatele.
10.8 Není-li mezi Smluvními stranami sjednáno jinak, je Poskytovatel povinen jakékoliv vady Plnění či jeho části, které vzniknou v době trvání záruky odstraňovat na své náklady, a to v souladu s definicí Podpory uvedenou v Příloze 1.4 této Smlouvy.
XI. SANKČNÍ UJEDNÁNÍ
11.1 Smluvní pokuty:
i) v případě prodlení Poskytovatele s implementací ve lhůtě stanovené v čl. IV. odst.
4.1 anebo určené postupem tam uvedeným Smlouvy je Poskytovatel povinen uhradit Objednateli smluvní pokutu ve výši 1.000.000,- Kč (slovy: jeden milion korun českých);
ii) v případě prodlení Poskytovatele s poskytnutím služeb rozvoje v termínu dle příslušné objednávky je Poskytovatel povinen uhradit Objednateli smluvní pokutu ve výši 5.000,- Kč (slovy: pět tisíc korun českých), a to za každý i započatý den prodlení;
iii) v případě porušení povinnosti poskytování služeb Podpory v požadované kvalitě, tj. dle požadavků uvedených v Příloze č. 1.4 Xxxxxxx, se uplatní smluvní pokuty způsobem a v rozsahu dle Přílohy č. 1.4 Xxxxxxx;
iv) v případě jakéhokoliv nedodržení lhůt pro odstranění vad či nedodělků předaného (akceptovaného) plnění je Poskytovatel povinen Objednateli uhradit následující smluvní pokuty ve výši 5.000,- Kč (slovy: pět tisíc korun českých) za každý i započatý den prodlení a jednotlivou vadu;
v) v případě porušení povinnosti Poskytovatele udržovat v platnosti a účinnosti po celou dobu účinnosti Smlouvy pojistnou smlouvu dle odst. 10.4 Smlouvy je Poskytovatel povinen zaplatit Objednateli smluvní pokutu ve výši 100.000,- Kč (slovy: jedno sto tisíc korun českých) za každý i započatý měsíc, v němž nebude mít uzavřenou pojistnou smlouvu se stanovenými parametry;
vi) provede-li Poskytovatel změnu v realizačním týmu v rozporu s odst. 8.2.2 Smlouvy anebo neprovede změnu v realizačním týmu v souladu s požadavky Objednatele dle odst. 8.2.3 Smlouvy, má Objednatel právo na smluvní pokutu ve výši 100.000,- Kč (slovy: jedno sto tisíc korun českých) za každý jednotlivý případ porušení, a to i opakovaně;
vii) v případě porušení závazku ochrany důvěrných informací nebo mlčenlivosti Poskytovatelem ve smyslu čl. XII. Smlouvy, má Objednatel právo na smluvní pokutu
ve výši 100.000,- Kč (slovy: jedno sto tisíc korun českých) za každý jednotlivý případ porušení, a to i opakovaně.
11.2 V případě prodlení kterékoliv Smluvní strany se zaplacením peněžité částky vzniká oprávněné Smluvní straně nárok na úrok z prodlení ve výši jedné desetiny procenta z dlužné částky za každý i započatý den prodlení.
11.3 Zaplacením smluvní pokuty není jakkoliv dotčen nárok Objednatele na náhradu škody; nárok na náhradu škody je Objednatel oprávněn uplatnit vedle smluvní pokuty v plné výši. Zaplacením smluvní pokuty není dotčena povinnost splnění povinnosti, která je prostřednictvím smluvní pokuty utvrzena, pokud oprávněná strana nestanoví jinak.
11.4 Smluvní pokuta i úrok z prodlení jsou splatné do třiceti (30) dnů po obdržení jejich vyúčtování.
11.5 Výše smluvních pokut je limitována celkovou sjednanou cenou plnění za fáze 1 – 5 (bez DPH).
XII. OCHRANA DŮVĚRNÝCH INFORMACÍ A OCHRANA OSOBNÍCH ÚDAJŮ
12.1 Smluvní strany se dohodly, že veškeré informace, které si sdělily v rámci uzavírání a plnění Smlouvy, dále informace, které si sdělí nebo jinak vyplynou i z jejího plnění, jsou důvěrné (dále jen „Důvěrné informace“). Smluvní strany sjednávají, že Důvěrnými informacemi jsou veškeré Objednatelem poskytnuté informace, podklady a dokumenty, pokud nejsou běžně dostupné ve veřejných zdrojích.
12.2 Smluvní strany se dohodly, že Důvěrné informace nikomu neprozradí a přijmou taková opatření, která znemožní jejich přístupnost třetím osobám. Ustanovení předchozí věty se nevztahuje na případy, kdy:
12.2.1 Smluvní strany mají povinnost stanovenou právním předpisem, a/nebo
12.2.2 takové informace sdělí osobám, které mají ze zákona stanovenou povinnost mlčenlivosti, a/nebo
12.2.3 se takové informace stanou veřejně známými či dostupnými jinak než porušením povinností vyplývajících z tohoto článku Smlouvy.
12.3 Vyjma výše uvedeného se Poskytovatel zavazuje, že bude chránit a utajovat před třetími osobami skutečnosti tvořící obchodní tajemství, Důvěrné informace a jiné skutečnosti, které mu byly poskytnuty v rámci smluvního vztahu s Objednatelem.
12.4 Pokud je sdělení Důvěrných informací třetí osobě nezbytné pro plnění závazků Poskytovatele vyplývajících mu ze Smlouvy, může Poskytovatel tyto Důvěrné informace poskytnout pouze s předchozím písemným souhlasem Objednatele a za předpokladu, že tato třetí osoba před započetím činnosti písemně potvrdí svůj závazek zachování mlčenlivosti a ochrany Důvěrných informací, jinak je za toto porušení odpovědný v plném rozsahu Poskytovatel.
12.5 V případě uplatnění smluvních pokut a náhrady škody není dotčena hmotná a trestní odpovědnost fyzických osob, které za Poskytovatele jednaly a závazek mlčenlivosti a ochrany Důvěrných informací nedodržely.
12.6 Závazek k mlčenlivosti a ochraně Důvěrnosti informací je platný bez ohledu na ukončení účinnosti Smlouvy.
12.7 Vzhledem k veřejnoprávnímu charakteru Objednatele Poskytovatel výslovně prohlašuje, že je s touto skutečností obeznámen a souhlasí se zveřejněním smluvních podmínek obsažených ve Smlouvě v rozsahu a za podmínek vyplývajících z příslušných právních předpisů.
12.8 V případě, že bude při plnění Smlouvy docházet ke zpracování osobních údajů a Poskytovatel bude zpracovatelem, Smluvní strany se zavazují uzavřít smlouvu o zpracování osobních údajů dle vzoru, který je Přílohou č. 6 Smlouvy.
XIII. DOBA TRVÁNÍ SMLOUVY, MOŽNOSTI UKONČENÍ SMLOUVY
13.1 Smlouva je uzavřena na dobu neurčitou.
13.2 Smlouva může být ukončena písemnou dohodou Smluvních stran.
13.3 Objednatel je oprávněn od Smlouvy, event. její části písemně odstoupit z důvodu jejího podstatného porušení Poskytovatelem, přičemž za podstatné porušení Smlouvy se bude považovat:
a) prodlení Poskytovatele s poskytováním plnění či jeho části ve sjednaných termínech delší než 14 (slovy: čtrnáct) dnů, pokud Poskytovatel nezjedná nápravu ani v dodatečné přiměřené lhůtě, kterou mu k tomu Objednatel poskytne v písemné výzvě ke splnění povinnosti, přičemž tato lhůta nesmí být kratší než 10 pracovních dnů od doručení takovéto výzvy; důvod pro odstoupení od Xxxxxxx podle čl. IX. odst.
4.1 Xxxxxxx tímto není dotčen;
b) neakceptace Cílového konceptu Objednatelem v souladu s podmínkami Xxxxxxx;
c) v provozní fázi plnění opakovaně (ve třech po sobě jdoucích měsících) vykazuje vady kategorie A, anebo ve třech po sobě jdoucích měsících není dodrženo stanovené SLA.
d) další případy, o kterých tak výslovně stanoví Smlouva.
13.4 Objednatel je rovněž oprávněn odstoupit od Smlouvy v případě, že:
a) v insolvenčním řízení bude zjištěn úpadek Poskytovatele nebo insolvenční návrh bude zamítnut pro nedostatek majetku Poskytovatele v souladu se zněním zákona č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů. Objednatel je rovněž oprávněn odstoupit od Smlouvy v případě, že Poskytovatel vstoupí do likvidace; nebo
b) proti Poskytovateli je zahájeno trestní stíhání pro trestný čin podle zákona č. 418/2011 Sb., o trestní odpovědnosti právnických osob, ve znění pozdějších předpisů.
c) Poskytovatel neposkytne Objednateli garanci včasného plnění dle čl. IV. odst. 4.1 smlouvy či nesplní další povinnosti dle uvedeného článku Smlouvy. Objednatel je v takovém případě oprávněn provést změnu Poskytovatele (nahrazení Poskytovatele) tak, že uzavře Smlouvu s účastníkem zadávacího řízení na Veřejnou zakázku, který se dle výsledku hodnocení umístil druhý v pořadí, pokud takový (nový) Poskytovatel souhlasí s tím, že poskytne Objednateli plnění v souladu se svou nabídkou na Veřejnou zakázku a ve lhůtě v souladu s požadavky uvedenými v odst. 4.1 Smlouvy.
Pokud účastník zadávacího řízení, který se dle výsledku hodnocení umístil druhý v pořadí, odmítne poskytnout včasné plnění namísto původního Poskytovatele, je zadavatel oprávněn obrátit se na účastníka zadávacího řízení na Veřejnou zakázku, který se umístil jako třetí v pořadí, zaváže-li se tento k poskytnutí plnění v souladu se svou nabídkou na Xxxxxxxx zakázku a v souladu s požadavky uvedenými v odst. 4.1 smlouvy na plnění veřejné zakázky.
13.5 Poskytovatel je oprávněn od Xxxxxxx písemně odstoupit z důvodu jejího podstatného porušení Objednatelem, za což se považuje prodlení Objednatele s úhradou ceny za plnění předmětu dle Smlouvy o více než 60 (slovy: šedesát) dní.
13.6 Odstoupení od Smlouvy ze strany Objednatele nesmí být spojeno s uložením jakékoliv sankce k tíži Objednatele.
13.7 Smluvní strany se dále dohodly, že odstoupení od Smlouvy musí být písemné, jinak je neplatné. Odstoupení je účinné ode dne, kdy bylo doručeno druhé Smluvní straně.
13.8 Objednatel i Poskytovatel jsou oprávněni Smlouvu vypovědět, a to i bez udání důvodu, a Smlouva skončí uplynutím příslušného roku (výročí) poskytování služeb Podpory a služeb rozvoje, přičemž toto oprávnění mohou Smluvní strany uplatnit až v rámci fáze Podpory a rozvoje; Poskytovatel je oprávněn výpověď využít nejdříve po uplynutí 5 let od zahájení služeb Podpory a služeb rozvoje. V případě výpovědi Objednatele musí být písemná výpověď Poskytovateli doručena nejpozději 30 (slovy: třicet) dní před uplynutím příslušného roku (výročí) poskytování služeb Podpory dle Smlouvy, v případě výpovědi Poskytovatele musí být písemná výpověď Objednateli doručena nejpozději 6 (slovy: šest) měsíců před uplynutím příslušného roku (výročí) poskytování služeb Podpory dle Xxxxxxx, jinak se k výpovědi nepřihlíží.
13.9 Objednatel je oprávněn v průběhu anebo bez zbytečného odkladu po ukončení fáze 1 Analýza rozhodnout, že další fáze nebudou realizovány, a to zejména z důvodu nemožnosti kofinancování implementace z Integrovaného operačního programu.
13.10 Ukončením Smlouvy nejsou dotčena ustanovení o odpovědnosti za škodu, nároky na uplatnění smluvních pokut, ustanovení o ochraně důvěrných informací, jakož i ostatní práva a povinnosti založená Smlouvou, která mají podle zákona nebo Smlouvy trvat i po jejím zrušení.
XIV. SOUČINNOST A VZÁJEMNÁ KOMUNIKACE
14.1 Smluvní strany se zavazují vzájemně spolupracovat a poskytovat si veškeré informace potřebné pro řádné plnění svých závazků. Smluvní strany jsou povinny informovat druhou Smluvní stranu o veškerých skutečnostech, které jsou nebo mohou být důležité pro řádné plnění Smlouvy.
14.2 Smluvní strany jsou povinny plnit své závazky vyplývající ze Smlouvy tak, aby nedocházelo k prodlení s plněním jednotlivých termínů a s prodlením splatnosti jednotlivých peněžních závazků.
14.3 Veškerá komunikace mezi smluvními stranami bude probíhat prostřednictvím oprávněných osob uvedených v čl. VIII Smlouvy nebo na jeho základě, pověřených pracovníků nebo statutárních zástupců Smluvních stran.
14.4 Veškerá oznámení, tj. jakákoliv komunikace na základě Smlouvy, bude probíhat v souladu s tímto článkem Smlouvy. Jakékoli oznámení, žádost či jiné sdělení, jež má být učiněno či dáno Smluvní straně dle Smlouvy, bude učiněno či dáno písemně. Kromě jiných způsobů komunikace dohodnutých mezi stranami se za účinné považují osobní doručování, doručování doporučenou poštou, kurýrní službou, datovou schránkou či elektronickou poštou, a to na adresy Smluvních stran uvedené v záhlaví Smlouvy, nebo na takové adresy, které si Smluvní strany vzájemně písemně oznámí.
14.5 Oznámení správně adresovaná se považují za doručená
• dnem, o němž tak stanoví zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů (dále jen „ZDS“), je-li oznámení zasíláno prostřednictvím datové zprávy do datové schránky ve smyslu ZDS; nebo
• dnem fyzického předání oznámení, je-li oznámení zasíláno prostřednictvím kurýra nebo doručováno osobně; nebo
• dnem doručení potvrzeným na doručence, je-li oznámení zasíláno doporučenou poštou; nebo
• dnem, kdy bude, v případě, že doručení výše uvedeným způsobem nebude z jakéhokoli důvodu možné, oznámení zasláno doporučenou poštou na adresu Smluvní strany, avšak k jeho převzetí z jakéhokoli důvodu nedojde, a to ani ve lhůtě tří (3) pracovních dnů od jeho uložení na příslušné pobočce pošty.
14.6 Informace a materiály, které obsahují osobní údaje či důvěrné informace, budou doručovány buď osobně, nebo zasílány elektronicky a šifrovány. Šifra pro elektronickou komunikaci bude určena před zahájením realizace plnění Smlouvy.
XV. ZÁVĚREČNÁ USTANOVENÍ
15.1 Poskytovatel bere na vědomí, že Objednatel hodlá předmět plnění dle Smlouvy spolufinancovat s využitím prostředků Integrovaného regionálního operačního programu. Poskytovatel se zavazuje učinit veškeré nezbytné úkony a opatření vedoucí ke splnění všech podmínek plynoucích z uvedeného programu v rámci plnění svých povinností ze Smlouvy, a to zejména:
a) umožnit zaměstnancům nebo zmocněncům Objednatele, CRR, Ministerstvu pro místní rozvoj, auditnímu orgánu, Evropské komisi, Evropskému účetnímu dvoru, Nejvyššímu kontrolnímu úřadu, finančnímu úřadu, Národnímu fondu, Evropskému úřadu pro potírání podvodného jednání a dalším oprávněným orgánům státní správy vstup do objektů dotčené projektem a dále umožnit fyzickou kontrolu realizace projektu, jakož i kontrolu veškerých dokladů souvisejících s projektem;
b) vytvořit podmínky k provedení kontroly vztahující se k realizaci projektu,
poskytnout veškeré doklady vážící se k realizaci projektu, umožnit průběžné ověřování souladu údajů o realizaci projektu se skutečným stavem v místě jeho realizace a poskytnout součinnost všem shora uvedeným osobám oprávněným k provádění kontroly projektu;
c) uchovávat odpovídajícím způsobem v souladu se zákonem č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů, a to minimálně do konce roku 2029 veškeré originály účetních záznamů vztahujících se k projektu;
d) uchovávat odpovídajícím způsobem v souladu se zákonem č. 499/2004 Sb.,
o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů, a v souladu s pravidly pro žadatele a příjemce smlouvy včetně jejích dodatků a další originály dokumentů, vztahující se k projektu, a to minimálně do konce roku 2029.
e) dodržovat pravidla publicity, resp. poskytnout nezbytnou součinnost Objednateli k jejich provádění, v rozsahu vyplývajícím z nařízení Evropské komise, kterým se stanoví prováděcí pravidla k ustanovením týkajícím se Evropského fondu pro regionální rozvoj, Evropského sociálního fondu a Fondu soudržnosti.
15.2 Smluvní strany si podpisem Xxxxxxx sjednávají (pokud Xxxxxxx nestanoví jinak), že závazky Smlouvou založené budou vykládány výhradně podle obsahu Xxxxxxx, bez přihlédnutí k jakékoli skutečnosti, která nastala a/nebo byla sdělena, jednou stranou druhé straně před uzavřením Smlouvy.
15.3 Smlouva představuje úplnou dohodu Smluvních stran o předmětu Smlouvy a všech náležitostech, které Smluvní strany měly a chtěly ve Smlouvě ujednat, a které považují za důležité pro závaznost Smlouvy. Žádný projev stran učiněný po uzavření Xxxxxxx nesmí být vykládán v rozporu s výslovnými ustanoveními Smlouvy a nezakládá žádný závazek žádné ze Smluvních stran. Smlouvu je možné měnit pouze písemnou dohodou Smluvních stran ve formě číslovaných dodatků Smlouvy, podepsaných oprávněnými zástupci obou Smluvních stran.
15.4 Smluvní strany se podpisem Smlouvy dohodly, že vylučují aplikaci ustanovení § 557 OZ.
15.5 Smluvní strany si nepřejí, aby nad rámec výslovných ustanovení Smlouvy byla jakákoliv práva a povinnosti dovozovány z dosavadní či budoucí praxe zavedené mezi smluvními stranami či zvyklostí zachovávaných obecně či v odvětví týkajícím se předmětu plnění Smlouvy, ledaže je ve Smlouvě výslovně sjednáno jinak.
15.6 Smluvní strany si sdělily všechny skutkové a právní okolnosti, o nichž k datu podpisu Xxxxxxx věděly nebo vědět musely, a které jsou relevantní ve vztahu k uzavření Smlouvy.
15.7 Pro vyloučení pochybností Poskytovatel výslovně potvrzuje, že je podnikatelem, uzavírá Xxxxxxx při svém podnikání, a na Smlouvu se tudíž neuplatní ustanovení § 1793 OZ.
15.8 Poskytovatel na sebe v souladu s ustanovením § 1765 odst. 2 OZ přebírá nebezpečí změny okolností. Tímto však nejsou nikterak dotčena práva Smluvních stran upravená ve Smlouvě.
15.9 Práva vyplývající ze Smlouvy či jejího porušení se promlčují ve lhůtě 4 let ode dne, kdy právo mohlo být uplatněno poprvé.
15.10 Není-li stanoveno jinak, jednacím jazykem mezi Objednatelem a Poskytovatelem bude pro veškerá plnění vyplývající ze Smlouvy výhradně jazyk český, případně slovenský, a to včetně veškeré dokumentace vztahující se k předmětu Smlouvy.
15.11 Stane-li se jakékoli ustanovení Smlouvy neplatným, nezákonným nebo nevynutitelným, netýká se tato neplatnost a nevynutitelnost zbývajících ustanovení Smlouvy. Smluvní strany se tímto zavazují nahradit do 5 (pěti) pracovních dnů po doručení výzvy druhé Smluvní strany jakékoli takové neplatné, nezákonné nebo nevynutitelné ustanovení ustanovením, které je platné, zákonné a vynutitelné a má stejný nebo alespoň podobný obchodní a právní význam.
15.12 Vztahy Smluvních stran Smlouvou výslovně neupravené se řídí českým právním řádem, zejména OZ. Veškeré případné spory ze Smlouvy budou v prvé řadě řešeny smírem. Pokud smíru nebude dosaženo během 30 (třiceti) dnů, všechny spory ze Smlouvy a v souvislosti s ní budou řešeny věcně a místně příslušným soudem.
15.13 Žádné ustanovení Smlouvy nesmí být vykládáno tak, aby omezovalo oprávnění Objednatele uvedená v Zadávací dokumentaci Veřejné zakázky.
15.14 Xxxxxxx je vyhotovena též ve 4 (slovy: čtyřech) listinných vyhotoveních, z nichž každá ze Smluvních stran obdrží po 2 (slovy: dvou) vyhotoveních.
15.15 Pokud Smlouva podléhá uveřejnění v registru smluv dle zákona č. zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv), Smluvní strany se dohodly, že Xxxxxxx zašle k uveřejnění v registru smluv Objednatel.
15.16 Nedílnou součástí Smlouvy jsou následující přílohy:
• Příloha č. 1
1.1 Technické požadavky
1.2 Funkční požadavky
1.3 Metodika implementace
1.4 Služby Podpory a služby rozvoje
• Příloha č. 2 – Specifikace návrhu řešení
• Příloha č. 3 - Specifikace ceny
• Příloha č. 4 - Seznam poddodavatelů (vč. rozsahu jejich plnění)
• Příloha č. 5 - Realizační tým
• Příloha č. 6 – Smlouva o zpracování osobních údajů - vzor
• Příloha č. 7 – Specifikace Proprietárního software
Smluvní strany shodně prohlašují, že si Xxxxxxx před jejím podpisem přečetly a že byla uzavřena po podle jejich pravé a svobodné vůle, určitě, vážně a srozumitelně, což stvrzují svými podpisy.
V Kroměříži dne 12. 6. 2020 za Objednatele: | V Brně dne 9. 6. 2020 za Poskytovatele: | |
Xxx. Xxxx Xxxxxx, MBA, místopředseda představenstva | Xxx. Xxxx Xxxxxxx Jednatel |
Příloha č. 1.1 Technické požadavky
1 Specifikace díla
Předkládaný projekt řeší vybudování informační a telekomunikační technologie (ICT) pro zadavatele. Pořizované technologické prvky budou využívány v rámci elektronizace
zdravotnictví.
V souladu s podmínkami výzvy č. 28 IROP je cílem vybudovat informační prostředí
organizace, umožňující zrychlení a zjednodušení vnitřních procesů a elektronizaci vnitřních procesů organizace a zvýšení spolehlivosti, bezpečnosti a dostupnosti provozních
informačních systémů.
Součástí projektu bude i komunikační infrastruktura potřebná pro implementaci požadovaných informačních systémů:
• virtualizační cluster pro provoz požadovaných informačních systémů,
• datová úložiště o dostatečné kapacitě pro provoz požadovaných informačních systémů,
• základní SW potřebný pro provoz požadovaných informačních systémů (OS, DB, apod.).
Obecné požadavky:
• systém musí být lokalizován do českého jazyka ve všech svých částech včetně nápovědy,
• systém musí odpovídat platné a účinné právní úpravě v ČR, zejména v oblasti výkaznictví vůči zřizovateli a státu (povinné výkazy),
• systém musí umožňovat oboustrannou integraci na aplikace třetích stran ve zdravotnickém zařízení (NIS, LIS, Lékárna, …),
• Jednotlivé moduly systému musí splňovat podmínku jednotných přihlašovacích údajů uživatelů a musí být provozovány jednotně přes uživatelské rozhraní nebo relaci prohlížeče dostupné v operačním systému Microsoft Windows.
• Umožnit vlastní uživatelské úpravy formou přístupu k API systému
• Dostupnost všech relevantních informací v reálném čase
• Moderní ERP systému umožňující práci prostřednictvím standardního klienta, webového klienta, portálového přístupu apod.
2 Procesní oblasti řešení
Předmětem plnění je řešení jsou následujících funkčních oblastí. Jejich podrobný popis je uveden v samostatné příloze.
1. Finance a účetnictví
o Účetnictví dle platné a účinné legislativy
o Pokladna
o Banka
2. Manažerské účetnictví
o Plánování rozpočtů nákladů a výnosů
o Rozpouštění nákladů
o Zúčtování nákladů a výkonů
3. Nákup, prodej, žádankový systém
o Databáze odběratelů je určena pro zdravotní pojišťovny i pro import pacientů z NIS
o Upomínkování, výpočet penále, sledování stavu pohledávek, splátkové kalendáře
o Zápočty
o Správa finančních kont pacientů
o Fakturace dodávek materiálu a služeb
o Vystavování, schvalování a kontrola žádanek na nákup
o Kontrola z evidence ARES
o Vazba objednávek na smlouvy
o Periodické objednávky
o Workflow k likvidaci došlých faktur
4. Sklady
o Skladová evidence na úrovni materiál/sklad
o Inventarizace
o Způsob oceňování zásob nastavitelné na úrovni materiálu
o Evidence šarží, jejich expirace a výdej podle expirace
o Evidence sériových čísel
o Popora příjmu, výdeje a inventarizace pomocí čteček čárových kódů
o Vedení konsignačních zásob
o Žádanka a workflow na výdej ze skladu, spojená s rezervací výdeje
o Generování objednávek podle limitů skladových zásob
o Možnost dočasných pohybů s materiálem na příjmovém skladu bez jeho ocenění
o Možnost implementace řízených skladů
5. Evidence majetku
o Evidence majetku, včetně řazení do celků a včetně operativní evidence drobného majetku a ochranných pomůcek, přiřazení odpovědných osob k majetku
o Odpisové plány, účtování odpisů na střediska
o Inventarizace majetku s využitím čárových kódů
o Hromadné změny
o Evidence nájemních vztahů k majetku – vazba na smlouvy
6. Doprava
o Evidence vozidel a řidičů, záznamy o údržbě vozidel, seskupování vozidel do skupin
o Evidence jízd a čerpání PHM
o Zpracování cestovních příkazů
o Úhrada cestovních nákladů
o Přiznání k silniční dani
o Provázání s kartou majetku
o Sledování údržby vozidel, pojištění, oprav
o Cestovní příkazy
8. Workflow
o Uživatelsky nastavitelné schvalovací procesy
o Oprávnění přes skupiny uživatelů, zástupy
o Upozorňování emailem
o Při schválení možnost účtování dokladů do ERP.
o Workflow pro externí komunikaci bude řešeno samostatným modulem, viz kapitola 11
9. Správa a údržba budov
o Nástroje pro prostorovou evidenci nemovitého majetku, založenou na členění do areálů, budov, podlaží a místností.
o Evidence odpovědných osob
o Evidence elektronické dokumentace včetně prohlížeče a editoru
o Vedení provozní knihy
o Správa pasportních údajů
o Evidence stavebně technických prvků včetně jejich historie a záručních dob
o Specifikace prvků požární bezpečnosti
o Periodické činnosti, revize a kontroly
10. Řízení projektů
o Struktura projektu na úrovni projekt, etapa, úkol / podúkol
o Možnost provázání na projekt v ERP
o Vizuální plánování projektu, včetně návaznosti úkolů v rámci etapy
o Vizuální přehled stavu a plnění úkolů
o Správa příloh k projektu a komunikace
o Přístup z mobilní aplikace v OS Android nebo iOS
o Upozorňování v emailu
o Propojení s kalendářem
11. Spisová služba mimo zdravotnickou dokumentaci
o Korespondence
o Evidence a zveřejňování smluv
o Uchovávání elektronické dokumentace z datových schránek
o Naplňování požadavků platné a účinné legislativy pro spisové služby
o Komplexní řešení SS včetně pořizování elektronických verzí dokumentů
3 Rozhraní
Součástí řešení jsou i rozhraní na stávající systémy podle tabulky uvedené níže. U rozhraní
předpokládáme export / import souborů na úrovni účetního zápisu, ideálně ve formátu xml. Systém ale musí umožňovat i rozhraní pomocí Web service pro případ on-line vazby mezi systémy.
Oblast | Systém | Dodavatel | Rozhraní | Kroměříž |
Externí logistika | ||||
Doctis | Sophis | Potvrzení operace a spotřeba materiálu | X | |
Navision | Navertica | |||
Evidence zdravotnických prostředků | ||||
FaMa | TescoSW | |||
Veřejná lékárna | ||||
Farmis | Farmis | Účetní zápis | X | |
Lekis | Lekis | |||
NIS | ||||
Akord | Stapro | |||
Tree | ProSoft Kroměříž | X | ||
AMIS*H | ICZ | |||
Mzdy | ||||
Vema | Účetní zápis | |||
Perm | Účetní zápis | X | ||
Stravování | ||||
Stapro H | Stapro | |||
Kredit | Anete | X | ||
Kromě rozhraní na stávající systémy je součástí implementace i
• EDI zpracování faktury ve formátu isdoc
• Email link na potvrzení objednávky dodavatelem
Více podrobností k požadovaným funkcionalitám v tabulce funkčních požadavků v Příloze 1.2
4 HW, virtualizace a OS
Projekt bude implementován v centrálním virtualizovaném technickém prostředí organizace, které slouží pro provoz všech IT systémů a aplikaci. Virtualizované prostředí je tvořeno dvěma nezávislými fyzickými lokalitami.
Základem návrhu a předmětem dodávky jsou dva kvalitní virtualizační servery s procesory poslední generace ve spojení s moderním výkonným zrcadleným datovým úložištěm
určených pro umístění v racku. Předpokládá se instalace do dvou oddělených rovnocenných lokalit. Servery a datové úložiště jsou koncipovány jako rozšiřitelné s cílem pokrytí potřeb
organizace na minimálně 5 - 7 let. Tyto servery budou uspořádány do vysoce dostupného clusteru. Tato koncepce umožní bez problému rozdělit jednotlivé nody vysoce dostupného clusteru do dvou lokalit a tím minimalizovat riziko přerušení provozu z libovolných příčin.
Pro ukládání strukturovaných i nestrukturovaných dat bude použito rozšiřitelné datové úložiště s minimálně dvěma nezávislými nody pro ukládání dat s možností zrcadlení.
Pro zálohování bude použit zálohovací systém, který umožní zálohovat kompletní virtuální stroje na libovolné úložiště a dále musí být možnost zálohy jednotlivých souborů a adresářů virtuálních strojů. Systém musí umožnit rychlé obnovení virtuálního stroje stroj ze zálohy.
Propojení obou lokalit bude realizováno optickým spojem, který bude součástí lokální sítě Ethernet. Toto propojení není předmětem dodávky.
Model technologické architektury – pohled struktury IT technologické architektury
5 Počty uživatelů a dokladů
Pro nacenění licencí použijte prosím tyto počty jmenných uživatelů:
V případě, že je systém licencován podle současně běžících uživatelů, přepočet prosím odhadněte podle zkušeností z jiných projektů.
V případě různých cen pro různé typy uživatelů (například plný uživatel, informační uživatel, vývojář), použijte prosím rozdělení do těchto skupin podle zkušeností z jiných projektů
Funkční oblasti - moduly | Kroměříž | Poznámky pro definici uživatelů | |
1. | Ekonomika - finance a účetnictví | 20 | |
2. | Manažerské účetnictví | 10 | |
3. | Nákupa a prodej | 20 | Z této položky byly odstraněny žádanky - ty jsou řešeny v rámci workflow. |
4. | Sklady | 20 | |
5. | Evidence majetku | 5 | |
6. | Doprava | 5 | Pouze odd. dopravy, ostatní v rámci workflow. |
8. | Workflow | 150 | Tady musí být zahrnutí všichni uživatelé, kteří pracují s žádankami, vč. žádanek na léky (v UHN např. mají oprávnění schvalit žádanku na léky všichni lékaři). Zde předpokládáme jiný typ licence než plná licence ERP. |
9. | Správa a údržba budov | 10 | Pouze správci nemovitostí, ostatní v rámci workflow. |
10. | Řízení projektů | 20 | |
11. | Spisová služba mimo zdravotnickou dokumentaci | 5 | Pouze správci spisové služby, ostatní v rámci workflow. |
Správa systému | |||
IT Administrace | 5 | Administrace systému, úpravy a vývoj, podpora | |
Technické účty | 5 | Rozhraní, dávkové zpracování | |
Přístupové licence Microsoft Windows CAL nejsou předmětem dodávky
Příloha č. 1.2 Funkční požadavky
Funkční oblasti | ||||
1. Finance a účetnictví | ||||
1.1. Obecné specifikace | Požadavek | Splňuje | Popis | |
1 | Systém musí zahrnovat v oblasti účetnictví a financí platnou legislativu s přihlédnutím ke specifickým požadavkům, zákonům a předpisům platným pro zdravotnické zařízení, vč. vyhlášky č.500/2002 Sb. v platném znění. | Implementace | 1. je standardní funkcionalita aplikace | Výrobce ERP garantuje platnou legislativu pro funkcionalitu, která je obsažena ve standardu ERP systému. Specifické požadavky, které vyplývají z předpisů platných pro zdravotnická zařízení a která jsou součástí standardu ERP (QI je implementováno v různých právních formách zdravotnických zařízení jako jsou akciové společnosti, příspěvkové organizace zřizované krajem nebo Ministerstvem zdravotnictví a v neziskové organizaci) také podléhají aktualizaci legislativy ze strany výrobce ERP systému. V případě zakázkové úpravy dle požadavku zákazníka s dopadem na legislativu, přebírá garanci implementační partner. |
2 | Podpora české legislativy – legislativní změny budou automaticky bez požadavku zapracovány do systému po zveřejnění ve sbírce zákonů. | Implementace | 1. je standardní funkcionalita aplikace | Výrobce ERP systému sleduje legislativní změny, prostřednictvím včasného zapracování těchto změn s dopady do oblastí účetnictví a financí vydává novou verzi ERP systému pro zákazníky s popsanou metodikou odrazu této změny. Na aktuální verzi ERP systému s platnou legislativou instalovanou u zákazníka přebírá garanci implementační partner. |
3 | V oblasti účetnictví musí umožňovat definici účtového rozvrhu s volitelnou strukturou (s možností omezení v případě centrální správy účtového rozvrhu). Každý účetní zápis musí vždy obsahovat datum a číslo účtu a musí být možné definovat další atributy účetních zápisů (např. nákladové středisko) a pravidla pro jejich použití (např. povinnost zadat nákladové středisko při účtování na určitý účet). Musí být možné doplnit textový komentář u dokladu a osmimístné číslo účtu. | Implementace | 1. je standardní funkcionalita aplikace | Standard ERP systému umožňuje definici uspořádání směrné účtové osnovy a označení účtových tříd, účtových skupin, syntetických účtů, v případě potřeby uspořádání a označení analytických účtů a podrozvahových účtů, je možné definovat účtový rozvrh pro každé účetní období a je možné tento rozvrh v průběhu účetního období kdykoliv doplňovat tak, jak je stanoveno v § 14 ZoÚ v platném znění. V případě centrální správy účtového rozvrhu v samostatné instanci nejsou tyto změny uživateli povoleny, změny jsou provedeny centrálně a následně přeneseny do jednotlivých QI. V konfiguraci lze nastavit požadovanou délku analytického účtu a dále lze jednotlivým účtům nastavit další atributy jako je např. povinnost vyplnění dimenzí (střediska, akce, kalkulační jednice, zdroj, okruh, obor), rozpad počátečních stavů na dimenze, typ účtů z pohledu rozvahy, daňové uznatelnosti apod. Každý účetní záznam obsahuje unikátní evidenční číslo dokladu, datum dokladu, okamžik zaúčtování, čísla účtů, textový komentář, který lze doplňovat. |
4 | Systém musí umožňovat účtování a evidenci DPH i do více období na základě povolení pro uživatele a také musí obsahovat funkce pro provedení účetní závěrky. Musí umožnit dodatečné přiznání a krátící koeficient. Při použití krátácáho koeficientu DPH zaúčtovat zbývající části DPH k příslušným nákladovým účtům se základem daně. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Uživatelé s nastaveným oprávněním mohou pořizovat doklady (účetní i daňové) do více období. Vše je navázáno na uzavření/otevření účetního období/DPH období (samostatné uzávěrky) a na oprávnění uživatele. Funkce účetní závěrky (kontroly před uzávěrkou, uzavírací a otevírací zápisy, počáteční stavy,... ) jsou standardní součástí modulu účetnictví. Funkce závěrky DPH (včetně dodatečných přiznání a krátícího koeficientu) jsou standardní součástí modulu financí. Zbývající část DPH při použití kráceného koeficientu lze uživatelsky (ručně) rozúčtovat na příslušné nákladové účty k základu daně. Předmětem úpravy aplikace bude funkcionalita, která zajistí automatický rozpad položek DPH dle sazeb a dle rozpadu dimenzí pro všechny položky přijatých plnění a provede jejich rozúčtování v poměru dle koeficientu DPH minulého období, který se používá pro výpočet kráceného nároku na odpočet. Nákladové účty MD budou převzaty z příslušné položky základu daně. |
5 | Požadavkem na systém je také nabídka různých pohledů na účty a pohyby na účtech za určité období, i přes atributy celkové i položkové, sestavy pokrývající oblast účetnictví a dále podpora sestavení výkazů dle požadavků státu, kraje a vlastních požadavků. | Implementace | 1. je standardní funkcionalita aplikace | V modulu účetnictví jsou k dispozici formuláře zobrazující data pro předvahu, rozvahu, výsledovku, kumulativní výsledovku, hlavní knihu,… Uživatel může pomocí jednoduchého dialogu před spuštěním formuláře definovat období, skupiny účtů, dimenzí (střediska, akce, kalkulační jednice, obory, zdroje a okruhy), indexy DPH apod. Nad formuláři jsou pak k dispozici tiskové výstupy obvykle v detailu nebo v součtech. Tyto tiskové výstupy lze jednoduchým uživatelským postupem modifikovat dle konkrétních potřeb. |
6 | Systém musí umožňovat současné zpracování více účetních a více fiskálních období. Možnost uzavřít nastavené fiskální období, kontrola při účtování na uzavřené fiskální období (případně identifikace účetní položky, která vznikla do uzavřeného období). | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | V systému lze pracovat s několika obdobími současně. Uživatel s přístupovými právy k této oblasti si definuje možnosti práce s daným obdobím. Každé období lze uzavřít tzv. auditem - pak lze jednoznačně identifikovat položky, které vznikly do takto uzavřeného období. Období lze také uzavřít závěrkou, do uzavřeného období nemůže běžný uživatel zaúčtovat. V případě potřeby zaúčtování položky do uzavřeného období může uživatel s patřičným oprávněním uzávěrku editovat a položku zaúčtovat. |
7 | Kontrola spolehlivosti plátců DPH vč. kontroly čísel účtů, včetně aktualizací, on line kontrola a možnost dávkové kontroly. | Implementace | 1. je standardní funkcionalita aplikace | Datum a čas poslední aktualizace spolehlivosti plátce DPH provedené pomocí webové služby registru plátců DPH jsou uloženy u každého obchodního partnera. Tuto aktualizaci lze provést dávkově. Pro daného plátce DPH jsou tedy k datumu a času uloženy aktuální informace o spolehlivosti plátce a o jeho registrovaných účtech (týká se pouze těch účtů, které jsou evidovány v databázi QI pro daného obchodního partnera). Kontrola se také spouští v on-line režimu v případě spuštění funkce oprávněným uživatelem, pokud je časová známka kontroly spolehlivosti starší než 24 hodin. Výrobce softwaru nedrží garanci nad daty uveřejněnými na webovém rozhraní. |
8 | Definování jednotného účtového rozvrhu v libovolné číselné struktuře s možností uživatelských změn (v případě centrální správy možnost jejich omezení). | Implementace | 1. je standardní funkcionalita aplikace | Je možné definovat účtový rozvrh pro každé účetní období a je možné tento rozvrh v průběhu účetního období kdykoliv uživatelsky měnit v závislosti na nastavení uživatelského oprávnění. Omezení možnosti provádění změn v účtovém rozvrhu je běžná funkcionalita standardu ERP. V případě centrální správy účtového rozvrhu v samostatné instanci nejsou tyto změny uživateli povoleny vůbec, změny jsou provedeny centrálně a následně přeneseny do jednotlivých QI. Tím je zajištěna možnost jednotného účtového rozvrhu ve více organizacích. |
9 | Možnost definovat uživatelský číselník rozšiřujících atributů (např. nákladových středisek, projektů, zakázek, zdrojů financování) - min. 5 atributů (dimenzí). Rozšiřující atributy představují další pohled na účetní data, kde je možné evidovat libovolný počet atributů na jednom účetním zápisu. | Implementace | 1. je standardní funkcionalita aplikace | Účetní zápis obsahuje kromě standardních údajů (evidenční číslo dokladu, datum zaúčtování, popis, částka, poznámka, číslo účtu MD, DAL, ...) další atributy, které jsou napojené na uživatelské číselníky. Jsou jimi nákladové středisko, akce (zakázka, projekt), kalkulační jednice, obor, okruh a zdroj. Číselníky dimenzí rozšiřujících účetní zápis jsou uživatelsky definovatelné, lze je neomezeně rozšiřovat o další hodnoty a společně se stromovou strukturou nabízejí uživateli možnosti pro získání přehledů nad účetními a finančními daty v různém rozsahu a detailu. |
10 | Způsob zajištění automatického zaúčtování účetní operace generované v jiných modulech (prodej, nákup, sklad) pomocí využití účtových skupin | Implementace | 1. je standardní funkcionalita aplikace | Jednotlivé moduly systému automaticky generují účetní položky, na které se aplikuje systém předkontací. Každý modul může využívat trochu jiného systému pro co nejpřesnější předkontaci dle typu dat. Modul sklady využívá znalosti o druhu pohybu, čísla skladu a rozdělení položek do účetních skupin. Zařazení položek do účtových skupin se provádí v katalogu zboží (definice účetní skupiny druhu zásob, služby) která zajistí správný rozpad účtování. Například modul financí využívá pro předkontace kombinaci údajů jako je typ dokladu, dokladová řada, index DPH, případně výběr konkrétní předkontace. Modul Majetek využívá pro předkontace znalost druhu pohybu majetku, typu účetní položky a skupiny/podskupiny majetku včetně návaznosti na kódy PAP/PKP. |
11 | Možnost blokování použití účtu, nastavení podmínek při účtování na daný účet a použití atributů (např.: nutné nákladové středisko). | Implementace | 1. je standardní funkcionalita aplikace | Platnost účtu lze omezit pro celé účetní období nebo jen pro jeho část s časovým nastavením platnosti od/do. Dále lze nastavit povinnost vyplnění účetních dimenzí (středisko, akce, kalkulační jednice, obor, okruh, zdroj) a to nastavením hodnoty ANO v příslušném atributu analytického účtu. |
12 | Možnost on-line informace o stavu nebo pohybu na účtu včetně jejich sledování ve zvoleném období a více obdobích. Možnost nastavení platnosti účtu. | Implementace | 1. je standardní funkcionalita aplikace | Informace o stavu a pohybu účtu jsou dostupné online v členění na jen zaúčtované zápisy nebo včetně tzv. žádostí o zaúčtování. Omezení platnosti účtu viz bod 11. Veškeré výstupy nad účetnictvím lze omezit datem s časovou filtrací od do tak, aby uživatel dostal jen požadované informace. |
13 | Účetní transakce vzniklé v ostatních modulech jsou účtovány automaticky do účetních knih včetně párovacích vazeb. | Implementace | 1. je standardní funkcionalita aplikace | Jedná se o standardní funkcionalitu systému. |
14 | Možnost nastavení účetního období oprávněným uživatelem (dle rolí, oprávnění) včetně možnosti účetní období nastavit na konkrétního uživatele (možnost nastavit různá období jednotlivým uživatelům). Kontrola při účtování na nastavené období a zamezení účtování do nepovoleného období. | Implementace | 1. je standardní funkcionalita aplikace | Účetní období je systémově nastaveno pro vkládání nových dokladů, přepnutí uživatele mezi obdobími je možné v konfiguraci uživatele a je řízeno přístupovými právy. Každý uživatel může mít nastaveno pro práci jiné období bez ohledu na aktuální období v souvislosti s datem a časem. Kontroly na účtování mimo nastavené účetní období jsou nastaveny. |
15 | Využití atributů pro možnost detailnějšího třídění účetních operací a následného vyhodnocení dat. Dle použitých atributů vytvářet pohledy na účetní data, včetně možnosti porovnání s nastaveným rozpočtem a porovnání ve zvolených obdobích. | Implementace | 1. je standardní funkcionalita aplikace | Třídit účetní zápisy lze podle všech dostupných atributů na formulářích. Účetní a finanční přehledy nabízejí možnost práce s účetními zápisy zvoleného období a jejich porovnání na vybraný rozpočet. Obsah každého formuláře lze také exportovat do MS Excel. Do tiskových výstupů lze vkládat funkce, které mohou provést další matematické operace nad dostupnými hodnotami (procenta plnění, rozdíl absolutních hodnot, sumarizace za třídící klíče apod.). Rozdílem hodnot tak lze zobrazovat porovnání plánovaných (rozpočtovaných) hodnot a skutečnosti nebo skutečnosti v různých obdobích. |
16 | Nástroje pro sestavení účetních výkazů. Možnost změny a údržby oprávněným uživatelem bez zásahu programátora, včetně definice sloupců a řádků výkazu. | Implementace | 1. je standardní funkcionalita aplikace | Pro sestavení účetních výkazů je k dispozici aparát pro tvorbu a použití tzv. definovaných účetních sestav. Sestavy jsou v systému předdefinovány v rozsahu, který definuje vyhláška. Uživatel má nástroje pro modifikaci výkazů dle potřeb analytického členění účtů nebo dle jiných potřeb. Uživatel má k dispozici i nástroje pro tvorbu vlastního výkazu. Po základním školení aparátu pro tvorbu a správu účetních výkazů si může oprávněný uživatel provádět správu sám bez |
zásahu programátora - řádky, sloupce, vzorce, funkce (sčítání, dělení,…) | ||||
17 | Možnost sestavení výkazů za jiné než účetní období, rychlý přehled o zůstatcích na účtech v rámci zvoleného časového hlediska (data, od data, do data). | Implementace | 1. je standardní funkcionalita aplikace | Každý přehled nad účetnictvím je vytvářen dynamicky za uživatelem zvolené období, které nijak nemusí souviset s účetními obdobími ať už aktuálním nebo minulými. |
18 | Možnost zjistit stav výsledkového i rozvahového účtu zpětně k libovolnému datu v minulosti mj. pomoci filtrů na účetní osnově | Implementace | 1. je standardní funkcionalita aplikace | Viz bod 17, v přehledu lze na sloupci účet použít filtraci např. účet začíná na "xxx", konkrétní pozice účtu "_5 ", výčet účtů) |
19 | Hlavní kniha, podklady pro inventarizaci jednotlivých účtů včetně možnosti tisku. Hlavní knihu lze zobrazit (vytisknout) on-line v průběhu období bez nutnosti uzavření období. | Implementace | 1. je standardní funkcionalita aplikace | Hlavní kniha je součástí modulu účetnictví. Pohled na data je tvořen dynamicky a uzavření období není podmínkou pro získání dat a tvorbu podkladu. Hlavní knihu lze přímo vytisknout i převést do formátu xls. |
20 | Možnost uložení rozpracovaného účetního případu (dokladu) bez zaúčtování. | Implementace | 1. je standardní funkcionalita aplikace | Rozpracované doklady lze uložit a jejich předpřipravené účetní položky, které nemusejí být úplné z hlediska dimenzí nebo předkontací (nejsou v daném okamžiku zvoleny) jsou zobrazeny v tzv. žádostech o zaúčtování. V této fázi lze doklad libovolně upravovat a následně dokončit a dle zvolené kontace doklad zaúčtovat. |
21 | Možnost definice opakujících se účetních operací a jejich pravidelné účtování (např. jednou měsíčně), vytváření vzorů z kopií předchozích dokladů. | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Systém umožňuje přes funkcionalitu "odvození dokladu" vytvořit kopie dokladu (odvození z pohledu datumových položek, protože nový doklad je tvořen do aktuálního nebo uživatelem zvoleného období - kopie datumů není žádoucí, kopie z hlediska položek, které lze v případě potřeby při tvorbě dokladu upravit). Uživatel může také použít šablony již existujících dokladů. Např. interních dokladů nebo faktur přijatých. Dále existuje možnost automatického generování dokladů v rámci aparátu rozpouštění a přeúčtování nákladů nebo při využití automatického generování dokladů ze smluv. |
22 | Vytváření opakujících se účetních operací, které rozúčtují zadanou částku na jednom účtu mezi několik dalších účtů, nebo atributů podle zadaného poměrového klíče. Možnost nastavit frekvenci opakování a pořadí těchto operací. | Implementace | 1. je standardní funkcionalita aplikace | Systém ERP obsahuje nástroj na přeúčtování nákladů a rozúčtování dokladů. Pro jednotlivé definice lze specifikovat název s poznámkou o frekvenci provádění, pořadí operací, platnost definice, poměrový klíč (pokud je často měněn, lze ho také importovat), dále se definuje základna pro rozpuštění, spojovací účet pro rozúčtování a dále lze definovat, zda bude rozúčtování provedeno kladně, záporně nebo zda se má základna odúčtovat nebo ne. |
23 | Účetní uzávěrka musí být provedena ve zvláštním datu, aby bylo možné účetní zápisy závěrky dohledat a filtrovat. Účetní závěrka v systému musí být realizována dle příslušných zákonných předpisů. Možnost provádět účetní závěrku i dle zvolených atributů. | Implementace | 1. je standardní funkcionalita aplikace | Postupy účetní závěrky jsou v souladu s platnou legislativou garantovanou výrobcem ERP. Veškeré operace lze zpětně doložit s notifikačními daty. |
24 | Provedení neomezeného počtu testovacích a uzavíracích operací před finálním uzavřením účetního období. | Implementace | 1. je standardní funkcionalita aplikace | Systém ERP umožňuje uzavření období opakovaně ať už v testovacím režimu nebo v rámci finálního zpracování. Účetní závěrku lze zrušit a opětovně provést znovu. Samozřejmě s respektováním všech věcných a časových souvislostí a oprávnění uživatele. |
25 | Možnost ponechat předchozí účetní období otevřené až do uzavření, přičemž není omezena práce s aktuálním obdobím. Včetně správné práce s novou číselnou řadou dokladů dle aktuálního data. | Implementace | 1. je standardní funkcionalita aplikace | Uzavírání resp. opětovné otevření období provádí odpovědný uživatel s příslušným oprávněním, možnost opětovného otevření uzavřeného období je uživatelsky komfortní, bez omezení práce se aktuálním obdobím a s respektování samostatných číselných řad pro obě období. Změny provedené v předchozím období mají vliv na hodnoty počátečních stavů, ale neovlivňují vlastní práci uživatelů v období následujícím. Tyto operace mají dopad pouze na již existující tiskové výstupy. |
26 | Účetní operace generované v jiných modulech (prodej, nákup, bankovní výpisy, pokladna, dlouhodobý majetek) musí být automaticky zaúčtovány pomocí účetních předkontací. | Implementace | 1. je standardní funkcionalita aplikace | V rámci implementace jsou pro jednotlivé moduly a jejich typické operace definovány předkontace tak, aby běžní uživatelé o probíhajícím účtování v ideálním případě nevěděli nebo vybírali z omezeného a jasného rozsahu případů. Předkontace lze v průběhu používání systému doplňovat a upravovat. V rámci účetnictví by mělo docházet pouze ke kontrolním činnostem a řešení případných mimořádných nových operací. Náplní by nemělo být účtování základních operací. Doplňující informace o základních principech předkontací jsou uvedeny také v odpovědi na bod 10. |
27 | Vytvoření analytických účtů a DPH předkontací pro účtování různých typů DPH (snížená, základní sazba, koeficient DPH, zpětné vrácení apod.) a podpora automatického účtování na tyto účty pomocí DPH předkontací z ostatních modulů. | Implementace | 1. je standardní funkcionalita aplikace | V ERP systému lze vytvořenou analytiku přiřadit k předkontaci, kde lze určit takzvaný "index" DPH, který určuje sazbu/koeficient/řádek v přiznání DPH a následně definuje charakter zápisu z pohledu DPH, zpracováním účetního dokladu se automaticky děje na úrovni dokladu výběru předkontace bez ohledu na místo pořízení (moduly ERP) s vazbou na analytický účet a výkaz DPH. Způsob zachycení celého rozsahu případů DPH je řešeno standardem resp. výrobcem ERP systému. |
28 | U každé účetní položky musí být přiřazeno datum uskutečnění účetního případu, nikoliv obecný údaj (například číslo | Implementace | 1. je standardní funkcionalita aplikace | Každá účetní položka eviduje: datum vzniku/zaevidování dokladu, datum zaúčtování, datum a čas zaúčtování položky do účetního deníku, všechny uvedené položky jsou povinné. |
měsíce). Systém musí kontrolovat vyplněný datum uskutečnění účetního případu. | ||||
29 | Možnost zjistit stav výsledkového i rozvahového účtu zpětně k libovolnému datu, bez nutnosti uzavření období. | Implementace | 1. je standardní funkcionalita aplikace | Každý přehled nad účetnictvím lze získat dynamicky na základě uživatelem zvoleného filtru data "od do" bez jakéhokoliv omezení. |
30 | Možnost vytvořit libovolný počet měn a pro každou měnu nastavit účetní předkontaci pro účtování kurzové ztráty nebo zisku. Možnost pracovat s uživatelem definovaným kurzem pro každou měnu. Při zadání měny do dokladu automatické přenesení platného kurzu a možnost jeho následné změny. | Implementace | 1. je standardní funkcionalita aplikace | V ERP systému lze pro každou měnu nastavit a při tvorbě kurzového rozdílu použít/vybrat předkontaci na úrovni vytvářeného dokladu. Definovaný kurz je pro danou měnu a období stanoven pro celý systém a přednaplňuje se do vytvářených všech dokladů v cizí měně, uživatel může měnit kurz dle potřeby na vybraných dokladech. |
31 | Vkládání a udržování denního kurzového lístku pro minulá i aktuální období. Uchování historie kurzovních lístků. | Implementace | 1. je standardní funkcionalita aplikace | Denní kurzový lístek je automaticky importován pro aktuální období a archivován pro minulé období. Přístupovým oprávněním uživatele lze umožnit editaci kurzového lístku nebo náhled na archiv kurzů. |
32 | Automatizované načítání denního kurzového lístku podle údajů České národní banky, automatické účtování kurzových rozdílů. | Implementace | 1. je standardní funkcionalita aplikace | Import kurzového lístku lze nastavit na časovač jako plánovanou úlohu, program provede načtení sám nebo lze ponechat načtení lístku uživatelem dle potřeby. V konfiguraci lze určit, zda se importují všechny měny, které ČNB zveřejňuje nebo se načte kurz pouze pro měny, které organizace využívá a definuje v číselníku měn. Výpočet a zaúčtování kurzových rozdílů probíhá automaticky při spárování úhrady s předpisem. Generování kurzových rozdílů nerealizovaných k datu účetní závěrky probíhá dávkově na pokyn uživatele. |
33 | Možnost přepočítání závazků, pohledávek, zůstatků bankovních účtů a pokladen kurzem platným ke zvolenému datu (např. ke dni účetní závěrky). | Implementace | 1. je standardní funkcionalita aplikace | Do kurzovního lístku lze pro daný den vložit tzv. rozhodný kurz k datu (je shodný s kurzem ČNB). Kurzové rozdíly nerealizované pro pohledávky, závazky, banky, pokladny pak provedou přepočet k rozhodnému dni daným kurzem. |
34 | Možnost sestavení, tisku a exportu ve formátu XLS a XML státních výkazů Rozvaha, Výkaz zisků a ztrát a Cash flow. | Implementace | 1. je standardní funkcionalita aplikace | Výrobce ERP garantuje podle platné legislativy uvedené výkazy ve formátu xls a xml. |
35 | Možnost sestavení a tisku podkladů a výkazu DPH a | Implementace | 1. je standardní | Výrobce ERP systému garantuje podle platné legislativy pro oblast DPH sestavení výkazu DPH, |
výkazu Souhrnné hlášení, dále možnost vytvoření elektronických souborů ve formátech XLS a XML s těmito výkazy (formáty musí umožňovat odeslání přes portál daňové správy). Kontroly výpočtu DPH - základ plus DPH oproti celkové částce dokladu. | funkcionalita aplikace | Souhrnného hlášení, Kontrolního hlášení a vytvoření elektronických souborů ve formátech XLS, XML pro odeslání přes datovou schránku, přes portál daňové správy. ERP systém disponuje i vlastní datovou schránku, kterou lze k tomuto účelu využít. Kontroly zpracování DPH a tisk podkladů pro DPH jsou nastaveny výrobcem. | ||
36 | Podpora uživatelských filtrů (soukromé a veřejné) | Implementace | 1. je standardní funkcionalita aplikace | V systému ERP lze filtry nastavit jako soukromé pro jednoho uživatele aplikace /formuláře nebo jako veřejné. Lze vytvářet jak jednoduché rychlé filtry (řetězit vyhledávací kritéria v rámci sloupců) nebo složitější pojmenované filtry (víceřádkové s logickými podmínkami AND, OR, vyhodnocení závorek apod.). |
37 | Podpora úpravy tabulkových formulářů (viditelnost a pořadí sloupců, třídění) | Implementace | 1. je standardní funkcionalita aplikace | Jde o nastavení tabulkových formulářů na úrovni uživatele, které si každý uživatel může provést sám. Zobrazovaná data ve sloupcích (včetně viditelnosti sloupce), pořadí sloupců, jejich šířka a třídění lze uživatelsky upravovat. Nastavení formulářů je uloženo pro uživatele v databázi. A uživatel tak bude mít svoje prostředí všude, kde se přihlásí pod svým přihlašovacím účtem. Nastavení formulářů lze převzít i k jiným uživatelským účtům. |
38 | Modifikace reportů a formulářů pro administrátory ERP | Implementace | 1. je standardní funkcionalita aplikace | Jde o obecnou funkčnost ERP systému, provádíme zaškolení administrátora, aby dle požadavků organizace zvládl sám tyto formuláře/reporty modifikovat. Samozřejmě při složitějších modifikací v případě nutnosti poskytujeme podporu jako implementační partner. |
39 | Drill-down analýza dat, pohyb po návazných dokladech (výdejka- příjemka-dodací list- objednávka ...) | Implementace | 1. je standardní funkcionalita aplikace | ERP systém je postaven na vazbách mezi doklady bez ohledu na jejich příslušnost do modulů. Uživatel může jednoduše sledovat souvislosti mezi jednotlivými doklady. Např. z hlavní knihy se přes výpis účtu a konkrétní doklad a jeho položky může dostat k informacím z modulu sklad, prodej a nákup apod. a to buď tlačítkovou formou přes samotné zobrazování informace v dokladu nebo vybraných údajů seznamového výčtu dokladů proklikem na požadované informace. |
40 | Sledování hlavní a vedlejší činnosti. V rámci měsíčního zpracování je nutné oddělení hlavní a vedlejší činnosti. | Implementace | 1. je standardní funkcionalita aplikace | Členění hlavní a doplňkové činnosti je zajištěno dvěma vrcholovými akcemi. Každá akce v IS je pak podřízena příslušnému stromu. Každý nákladový a výnosový účet má povinnost vyplnění dimenze akce. Tato funkcionalita je k dispozici i ostatním právním formám, nejen příspěvkovým organizacím. Funkcionalitu členění akcí do stromové struktury lze využít k sledování rozsáhlých investičních projektů nebo jiných aktivit, které na sebe v rámci času vážou doklady a náklady, například sledování nákladů na servis a údržbu, vzdělávání zaměstnanců apod. |
41 | Víceúrovňové rozpouštění nákladů a výnosů. Oddělení hlavní a vedlejší činnosti pro výnosy a náklady (první krok v rámci měsíčního zpracování dle zákona). Systém musí být schopen vykazovat stavy účtů před i po rozpuštění první úrovně (oddělení hlavní a vedlejší činnost) | Implementace | 1. je standardní funkcionalita aplikace | Hlavní a vedlejší činnost je vždy odlišena dimenzí akce a to jak pro prvotní tak i pro druhotný okruh. Rozpouštění lze provádět do druhotného okruhu tak, aby systém vždy doložil zůstatky za prvotní okruh bez rozpouštění nebo včetně druhotného po rozpouštění. |
42 | Minimalizace pořizováni dat-překlápění či generace návazných dokladů (žádanka-objednávka; objednávka -dodací list- příjemka) | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Jedná se o základní vlastnost a princip ERP systému s důrazem na časovou efektivnost zpracování dat. Minimalizace dat, které musí uživatel vkládat - jedná se obvykle pouze o primární doklad v návaznosti dalšího užití, další doklady v procesní řadě zpracování s vazbou na primární doklad, jsou překlápěny a odvozovány a uživatel pouze provádí jejich potvrzení nebo korekci minimálního počtu atributů dle skutečnosti. |
43 | Členění na střediska a zakázky | Implementace | 1. je standardní funkcionalita aplikace | ERP umožňuje definovat a následně sledovat neomezené množství středisek a akcí charakteru zakázek. |
44 | Možnost sestavit statistické výkazy - běžné (ČSÚ, ÚZIS) a také pro MF za veřejnou instituci (zákon 25/2017 Sb.) a za konsolidovanou jednotku státu. | Implementace | 1. je standardní funkcionalita aplikace | Pomocný konsolidační přehled (všech 6 částí včetně exportu do XML) je součástí standardu. Možnost sestavit statistické výkazy, pokud nejsou k dispozici v konkrétním modulu, existuje v rámci využití definovaných účetních sestav. Uživatel může vytvořit také vlastní výkaz dle vzoru a připravit přednaplnění daty ze systému. Ručním vstupem lze doplnit i hodnoty, které nelze získat v účetnictví (obvykle se jedná o nominální hodnoty). Takový výkaz pak lze tisknout či exportovat včetně formátu XML. QI poskytuje podporu pro naplnění a export výkazů uvedených v zákonu 25/2017Sb. pro Výkaz příjmů a výdajů, Přehled poskytnutých garancích a Přehled o projektech partnerství |
45 | Při použití krátícího koeficientu DPH účtovat zbylou část k příslušným nákladovým účtům se základem daně. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Zbývající část DPH při použití kráceného koeficientu lze uživatelsky (ručně) rozúčtovat na příslušné nákladové účty k základu daně. Předmětem úpravy aplikace bude funkcionalita, která zajistí automatický rozpad položek DPH dle sazeb a dle rozpadu dimenzí pro všechny položky přijatých plnění a provede jejich rozúčtování v poměru dle koeficientu DPH minulého období, který se používá pro výpočet kráceného nároku na odpočet. Nákladové účty MD budou převzaty z příslušné položky základu daně. |
1.2. Pokladna | Požadavek | Splňuje | Popis | |
1 | Systém musí podporovat zpracování a tisk pokladních dokladů na více pokladnách. Kdykoli musí být možné zjistit stav pokladny, provést inventarizaci, vytisknout pokladní knihu nebo předat odpovědnost jinému uživateli. | Implementace | 1. je standardní funkcionalita aplikace | Počet pokladen není systémem limitován. Uživatel si z jemu přístupných pokladen vybere konkrétní pokladnu k práci. Bez omezení může zjistit stav, tisknout pokladní knihu, provést inventarizaci, vkládat doklady (příjem, výdej) včetně jejich tisku. |
2 | Pokladny musí být možné vést v cizích měnách, musí být zajištěno účtování pokladních dokladů a zápis do evidence DPH dle definovaných předkontací. Potvrzení pokladního dokladu a jeho zaúčtování musí být možné provést odděleně. | Implementace | 1. je standardní funkcionalita aplikace | Každá pokladna má v rámci definice určenu měnu, ve které je vedena. Zpracování DPH probíhá principiálně stejně jako u finančních dokladů (faktura přijatá, vydaná) včetně tvorby účetních položek, užití předkontací a oddělené účtování přes žádosti o zaúčtování. |
3 | Možnost evidence libovolného počtu pokladen. Zajištění účetní předkontace jednotlivých pokladen. Zpracování tuzemské i cizí měny na pokladních dokladech. Zjištění stavu pokladny kdykoliv v průběhu práce s pokladnou. Možnost nastavení minimálního limitu na pokladně s upozorněním při jejím nižším zůstatku na pokladně. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Počet pokladen není omezen, účetní předkontace lze definovat pro jednotlivé dokladové řady, které mohou být oddělené pro jednotlivé pokladny a mít tak zcela oddělenou definici předkontací. Práce s cizí měnou v pokladně vedené v dané měně je standard. Nastavení minimálního zůstatku pokladny a upozornění při nižším zůstatku hotovosti bude předmětem úpravy. |
4 | Vytváření příjmových a výdajových dokladů, včetně účtování. Možnost odlišit příjem, výdej na pokladně od procesu účtování (oddělit roli pokladní od role uživatele, který účtuje pokladní doklad, tedy vytváří účetní zápis). Po potvrzení pokladního dokladu uživatelem s rolí pokladní, neumožnit změnu celkové částky dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Při uzavření hlavičky dokladu (pokladní příjemka, pokladní výdejka) dochází k tvorbě účetních položek. Lze oddělit roli účtování od vlastního pořízení dokladu. V případě účtování v žádostech o zaúčtování lze doklad zaúčtovat, rozúčtovat bez možnosti měnit původní výši dokladu. Editace vytvořených dokladů lze uživatelsky nastavit oprávněním. |
5 | Pokladní kniha – zpracování, zobrazení, tisky, zpětné zjištění stavu k určitému dni. Možnost odložit vytvořený pokladní doklad pro pozdější dokončení. Možnost zadání účelu platby, vyplaceno komu v případě výdejního pokladního dokladu, nebo převzato od v případě příjmového pokladního dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Pokladní kniha je dostupná kdykoliv pro prohlížení i tisk za libovolné období. Hlavičkové údaje (Předal, Převzal, Předmět, Poznámka) lze doplnit později bez vlivu na výši dokladu. |
6 | Vedení více pokladen s vazbou na konkrétního odpovědného uživatele. Evidence předání odpovědnosti mezi uživateli. | Implementace | 1. je standardní funkcionalita aplikace | Každý doklad v systému eviduje v hlavičce, jaký uživatel ho vytvořil, evidence předání odpovědnosti mezi uživateli je řešena fyzickou inventurou (výčetkou). Přístupovými právy lze zajistit, že k dané pokladně má právo přístupu pouze vybraná skupina uživatelů nebo konkrétní uživatelé. |
7 | Možnost zvolit pro každou pokladu jinou číselnou řadu. Možnost oddělit číslování příjmových dokladů od číslování výdajových dokladů. | Implementace | 1. je standardní funkcionalita aplikace | Každá pokladna odlišuje doklady vlastní číselnou řadou a odlišuje číslování pokladních příjemek a výdejek nastavením zkratky dokladu (např. PP pro pokladní příjemky a PV pro pokladní výdejky) v konfiguraci aplikace. |
8 | Realizace uzávěrky pokladny. Tisk pokladní knihy nebo výčetky kdykoliv v průběhu práce s pokladnou. Možnost denní inventarizace pokladny. | Implementace | 1. je standardní funkcionalita aplikace | Funkce Pokladní kniha je dostupná na tlačítko bez omezení pro každou pokladnu. Stejně tak funkce Inventury s vazbou na výčetku je dostupná na tlačítko kdykoliv v průběhu práce s pokladnou. |
9 | Vazba pokladny na saldokonta dodavatelů i odběratelů. | Implementace | 1. je standardní funkcionalita aplikace | Pokladní příjmové/výdajové doklady typu úhrada pohledávky nebo závazku mají vazbu na saldo včetně automatického přebírání saldokontního účtu. |
10 | Uživatelsky nastavitelné účetní předkontace pro opakující se pokladní operace včetně vazby na účetnictví a vazby na předefinované atributy. | Implementace | 1. je standardní funkcionalita aplikace | Účetní předkontace jsou při implementaci nastaveny a oprávněný uživatel může přidávat nebo měnit předkontace v průběhu práce se systémem tak, aby pokrývaly všechny i nově zavedené typické případy. |
11 | EET - Elektronická evidence tržeb | Implementace | 1. je standardní funkcionalita aplikace | Systém ERP splňuje legislativní podmínky pro EET - elektronickou evidenci tržeb včetně všech povinných náležitostí a činností. |
12 | Možnost opakovaného tisku pokladních dokladů po vydání pokladního dokladu i po zaúčtování. Evidence historie pokladních dokladů. | Implementace | 1. je standardní funkcionalita aplikace | Historie všech pokladních dokladů je dostupná pro oprávněné uživatele vždy. Opakovaný tisk pokladního dokladu je možný. |
13 | Možnost připojení terminálu pro platby platebními kartami včetně propojení s modulem pokladny, včetně tisku daňového dokladu po platbě kartou. | Implementace | 1. je standardní funkcionalita aplikace | Systém disponuje rozhraním na pokladní systém s terminálem pro platební karty. |
1.3 Banka | Požadavek | Splňuje | Popis | |
1 | Systém musí umožňovat zpracování bankovních příkazů a výpisů včetně zajištění elektronické komunikace s bankou (tedy exportu bankovních příkazů a importu bankovních výpisů), musí umožnit souběžně práci s více bankami. | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | V rámci importu lze (v závislosti na tom, zda banka danou funkčnost podporuje) importovat bankovní výpisy nebo importovat rozpis platby, pokud se jedná o souhrnnou platbu a plátce poskytnul rozpis. V oblasti exportu lze použít běžný export, inkasní export, export SIPO a export rozpisu příkazu. Systém ve standardu komunikuje s bankami ve formátech (CSV, ABO, GEMINI, SWIFT, Multicash, Gopay, FV ČNB a ve specifických formátech například pro platební karty KB apod.) Na straně exportu příkazů k úhradě je komunikace v obdobném rozsahu. |
2 | Podpora automatického navrhování bankovních příkazů, párování položek bankovních výpisů a jejich účtování dle definovaných předkontací. | Implementace | 1. je standardní funkcionalita aplikace | Systém obsahuje funkce pro práci se závazky. Bankovní příkazy se tvoří multivýběrem ze schválených závazků na základě uživatelských filtrů a nastavení (dle data úhrady, dle částky, splátkového kalendáře, souhrnných příkazů, vratek,...). Párování probíhá na základě variabilního symbolu, variantně pak dle dlužné částky, tolerance dlužné částky a dle doplňujících údajů z prodejních a nákupních smluv (nejstarší, nejmladší, nejbližší,...) |
3 | Možnost definice libovolného počtu bankovních účtů a zajištění účetní předkontace jednotlivých bankovních účtů. Zpracování tuzemské i cizí měny. Zjištění stavu bankovního účtu kdykoliv v průběhu práce. | Implementace | 1. je standardní funkcionalita aplikace | Počet bankovních účtů není omezen, účetní předkontace lze definovat odděleně pro typy pohybů (poplatky, převody peněz,...) a odděleně pro analytické účty bankovních účtů. Práce s cizí měnou pro účet vedený v dané měně je standard. Zjištění stavu bankovního účtu je dostupné kdykoliv dle potřeby se systému, není nutné se připojovat do bankovní aplikace. |
6 | Elektronická komunikace s bankami při platebním styku. Vytvářet elektronicky čitelné příkazy, které lze nahrát do bankovních aplikací banky. Možnost importovat elektronické výpisy z bankovních aplikací banky do systému. | Implementace | 1. je standardní funkcionalita aplikace | Vytvořené příkazy k úhradě jsou exportovány v požadovaném formátu, dle konfigurace konkrétní banky a stejně tak probíhá i import bankovního výpisu případně rozpisu plateb. |
7 | Využití IBAN a SWIFT jak na straně příkazu, tak i výpisu. | Implementace | 1. je standardní funkcionalita aplikace | Jedná se o standardní funkcionalitu systému. |
8 | Ruční i automatické pořizování bankovních výpisů. Při automatickém pořizování výpisu do systému možnost zpracovat i výpis, který obsahuje více účtů. | Implementace | 1. je standardní funkcionalita aplikace | Bankovní výpisy lze importovat i pořizovat ručně nebo oba postupy na jednom účtu kombinovat. V jednom kroku lze importovat výpisy pro více účtů, které jsou zadány jako kmenové účty účetní jednotky. |
9 | Možnost ruční i automatické tvorby platebních příkazů dle neuhrazených závazků, údaje pro provedení úhrady se přitom musí dotáhnout ze zdrojového dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Bankovní příkazy se tvoří multivýběrem ze schválených a neuhrazených závazků. Systém přednabídne k úhradě buď celou dlužnou částku, nebo respektuje splátkový kalendář (datum, částka) ze zdrojového dokladu. Uživatel s oprávněním může přednaplněné údaje upravit požadovaným způsobem (obvykle snížení částky k úhradě). |
10 | Při automatickém pořizování příkazu k úhradě nenavrhovat opakovaně platby, které jsou na jiných příkazech, možnost ruční blokace platby. Při ručním zadání upozornit na položku, která je již na jiném příkaze. | Implementace | 1. je standardní funkcionalita aplikace | Systém do příkazu k úhradě nenabídne doklady, na které je vystaven příkaz k úhradě, z důvodu nechtěného přeplacení závazku. Při ručním zadání platby je uživatel informován o částce Zbývá k úhradě, která je snížena o částky, na které je zadán příkaz k úhradě. Blokace platby je možná nastavením Neschváleno pro daný doklad. Atribut lze následně modifikovat dle potřeby. |
11 | Možnost uživatelské editace částky k úhradě, kterou navrhne systém, včetně možnosti odstranění položek, které nebudou předmětem daného příkazu. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje editaci bankovního příkazu z hlediska částky (snížení/zvýšení), odmazání řádku platebního příkazu nebo přidání nového a to i opakovaně. Oprávněný uživatel může položky upravovat, přidávat, mazat do doby než odešle příkaz v el. podobě odešle ke zpracování bance. |
12 | Možnost zadání libovolné položky do bankovního příkazu bez vazby na účtovaný doklad. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje do platebního příkazu přidat řádek bez vazby na pohledávky a závazky. |
13 | Možnost sloučit platby pro jednotlivé dodavatele včetně volby variabilního symbolu, možnost rozložit úhradu do více odběratelských faktur. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje uživateli tvorbu souhrnné platby, která sloučí platby do jednoho řádku příkazu pro banku, umožňuje rozúčtování přijaté platby od odběratele za více faktur vydaných a spárování jednotlivých částí úhrad na doklady u salda odběratele. |
14 | Automatické i ruční párování s možností úpravy automatického navržení párování před zaúčtováním, hromadná platba několika faktur. | Implementace | 1. je standardní funkcionalita aplikace | Systém provádí automatické párování, lze párovat i ručně (výběrem). Doklady jsou automaticky předkontovány (analytický účet bankovního účtu a saldokontní účet párovaného dokladu). Hromadná platba několika faktur je možná rozpisem/výběrem jednotlivých dokladů za účelem spárování a zaúčtování. |
15 | Funkcionalita automatického párování plateb dle analytických účtů zdravotních pojišťoven. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje na základě zaúčtovaných pohledávek a závazků vůči zdravotním pojišťovnám automatické párování plateb a tím i přiřazení správného analytického účtu dle konkrétní zdravotní pojišťovny. |
16 | Možnost úhrady u neresidentních účtů (zahraniční platby). | Implementace | 1. je standardní funkcionalita aplikace | Zahraniční platby jsou standardní funkcionalitou systému. |
17 | Možnost inkasních příkazů vůči odběratelům. | Implementace | 1. je standardní funkcionalita aplikace | V oblasti exportu lze použít běžný export, inkasní export, export SIPO a export rozpisu příkazu. |
2. Manažerské účetnictví | Požadavek | Splňuje | Popis | |
1 | Systém musí podporovat procesy plánování rozpočtů nákladů a výnosů. | Implementace | 1. je standardní funkcionalita aplikace | Systém podporuje ve standardní verzi práci s rozpočtem - poskytuje údaje pro přípravu rozpočtu, schválení rozpočtu a operativní rozbory nad rozpočtem, import i export údajů rozpočtů nákladů a výnosů. |
2 | Součástí musí být i vedení manažerského účetnictví včetně alokace nákladů a výnosů až na úroveň nákladových středisek nebo jiných atributů. | Implementace | 1. je standardní funkcionalita aplikace | Pro manažerské účetnictví jsou k dispozici veškeré nástroje vnitropodnikového účetnictví včetně standardních atributů a doplňkových nositelů (kalkulační jednice, akce, středisko, obor, okruh, zdroj). |
3 | Dále musí systém nabízet různé pohledy na účty nebo skupiny účtů za určité období i přes atributy, definovat a sledovat různé ukazatele, poskytovat výkazy pro management. V pohledech, sestavách i výkazech musí být možné porovnávat skutečnost s rozpočtem. | Implementace | 1. je standardní funkcionalita aplikace | Systém poskytuje "standardní" pohledy na účetnictví bez omezení obdobím nebo atributy. Mimo to je k dispozici uživatelský nástroj pro vytváření a modifikování libovolných sestav včetně možnosti porovnání s rozpočtem. |
4 | Správa plánů a rozpočtů včetně verzování. Možnost práce s neomezeným počtem rozpočtů a vyhodnocování skutečnosti proti zvolenému rozpočtu. | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Systém pracuje s neomezeným počtem variant rozpočtu. Umožňuje ve standardní verzi vyhodnocování skutečnosti proti zvolenému rozpočtu. |
5 | Možnost sestavit rozpočet se zvolenou mírou detailu – na jednotlivé účty nebo skupiny účtů, jednotlivá nákladová střediska nebo jejich skupiny (např. oddělení) nebo jiné atributy a pro libovolné | Implementace | 1. je standardní funkcionalita aplikace | QI pracuje s rozpočtem ve stejné míře detailu jako s účetními daty i s časovou strukturou. |
časové období (např. rok, měsíc). | ||||
6 | Porovnání plánu a skutečnosti pro všechny sledované ukazatele a v rámci organizační struktury organizace. Rozpad až na detail - účet, atributy, období (den, týden, měsíc, kvartál, pololetí, rok). | Implementace | 1. je standardní funkcionalita aplikace | Plánovat lze v systému až na jednotlivé dimenze účetního zápisu (např. kalkulační jednice). Pro zobrazení lze využívat veškeré nástroje filtrací a zobrazení jako pro zobrazení skutečnosti. |
7 | Vytváření rozpočtů kopírováním z jiného rozpočtu, z jiné verze rozpočtu, načítáním poměrů ze skutečného čerpání. | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Systém pracuje s neomezeným počtem variant rozpočtu. Rozpočet lze vytvořit kopií rozpočtu, odvozením rozpočtu, tvorbou z účetnictví nebo importem dat, kdy zdroj může být mimo systém QI. |
8 | Možnosti datových vstupů z ostatních používaných informačních systémů organizace. Minimálně standardní rozhraní ve formátech CSV, XML, TXT, XLS. Připravené rozhraní pro import dat z jiných IS - nemocniční informační systém (regulační poplatky), systém pro zdravotní pojišťovny, systém pro stravovací provoz, atd. | Implementace | 1. je standardní funkcionalita aplikace | Systém podporuje import dat v uvedených formátech. Konkrétní formát a struktura dat je odvozena od konkrétní importní funkce. |
9 | Možnost rozpočty exportovat (nejlépe do formátu MS Excel), provést změny a následně importovat zpět do systému. | Implementace | 1. je standardní funkcionalita aplikace | Systém podporuje import i export rozpočtů. |
10 | Rozúčtování nákladů v manažerském účetnictví – rozpouštění nákladů režijních středisek dle definovaných klíčů až na úroveň nákladových středisek. | Implementace | 1. je standardní funkcionalita aplikace | Systém podporuje vedení manažerského účetnictví nad finančním účetnictvím včetně požadovaných operací nad stanovenými atributy. |
11 | Možnost kalkulace cen výrobků a služeb | Implementace | 1. je standardní funkcionalita aplikace | Je řešeno formou definovaných účetních sestav. |
3. Nákup, prodej, žádankový systém | Požadavek | Splňuje | Popis | |
1 | Systém musí zajistit evidenci odběratelů, jejich saldokonta a veškerých souvisejících dokladů (objednávky, faktury, dobropisy, zálohové doklady, platby). Do evidence odběratelů musí být možné importovat pacienty z NIS a jako odběratele evidovat také zdravotní pojišťovny. | Implementace | 1. je standardní funkcionalita aplikace | Obousměrné propojení "firma - doklad". Import z NIS - naplnění standardní šablony pro import do agendy Obchodní partneři. |
2 | Systém musí řešit evidenci upomínek a penále s možností automatického generování. | Implementace | 1. je standardní funkcionalita aplikace | Automatické generování upomínek a penalizačních faktur na pokyn uživatele. |
3 | Sledování stavu pohledávek za jednotlivé zdravotní pojišťovny a za Zdravotní pojišťovny celkem. | Implementace | 1. je standardní funkcionalita aplikace | Podpora sledování všech dokladů typu pohledávka. Možnost sledování za vybrané obchodní partnery. Možnost filtrování dle typu odběratele. |
4 | Možnost vytvářet dodávky z prodejních objednávek bez nutnosti účtování faktury. Umožnit z jedné prodejní objednávky vytvořit libovolný počet dodávek | Implementace | 1. je standardní funkcionalita aplikace | Použití dokladu typu Dodací list, Proforma faktura. Možnost částečného (postupného) plnění. |
5 | Možnost vytvářet jednu dodávku nebo fakturu z libovlného počtu prodejních objednávek | Implementace | 1. je standardní funkcionalita aplikace | Možnost sloučit položky z více objednávek do Dodacího listu, Proforma faktury. |
6 | Možnost vytvořit více druhů šablon pro opakující se texty na prodejních dokladech a tyto texty umožnit zadat pro jakýkoliv následný prodejní doklad. Možnost kopie již jednou vytvořeného dokladu do nového, případně umožnit vytvořit šablonu pro opakující se případy | Implementace | 1. je standardní funkcionalita aplikace | Více variant pro tvorbu šablon dokladů. Možnost odvodit "doklad z dokladu". |
7 | Možnost přiřadit zálohovou platbu zúčtovací faktuře, umožnit přiřadit zálohu jen částečně. Při zúčtování zálohové platby je automaticky účtováno | Implementace | 1. je standardní funkcionalita aplikace | K platbám zálohových listů, které dosud nebyly vyčerpány do finančního dokladu do výše zaplacení, které obsahují nenulovou DPH a ke kterým zatím nebyly vytvořeny daňové doklady na celou částku platby, jsou vytvářeny daňové doklady. |
DPH. Možnost stornovat zaplacenou zálohu. | ||||
8 | Účtování prodejních dokladů a zápis do evidence DPH musí probíhat automaticky na základě definovaných předkontací. | Implementace | 1. je standardní funkcionalita aplikace | Účtování prodejních dokladů je zajištěno aparátem předkontací. Předkontacemi je řešeno i účtování o DPH. Evidence DPH je zajištěna daňovými položkami. Vše probíhá automaticky ze zdrojového dokladu. |
3.1 Evidence odběratelů | Požadavek | Splňuje | Popis | |
1 | Možnost evidence libovolného počtu odběratelů. Evidence a vyhledávání odběratele na základě různých kritérií a identifikátorů. Možnost zatřiďování dodavatelů do skupin, vyhledávání dle skupin. | Implementace | 1. je standardní funkcionalita aplikace | Rozsáhlá podpora CRM. Možnost třídění dle libovolného kritéria. |
2 | Pro odběratele možnost zadat další adresy, které jsou odlišné od adresy uvedené na kartě odběratele. | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Možnost zadání více adres a jejich následné uplatnění v dokladech. |
3 | Umožnit automatický import odběratelů např. přenosem čísel pacientů a identifikačních údajů z NIS pro účel importu regulačních poplatků a fakturace provedených výkonů. | Implementace | 1. je standardní funkcionalita aplikace | QI obsahuje standardizovaný import obchodních partnerů. Pokud se NIS může přizpůsobit tak, aby poskytoval data podle definované struktury, není potřeba na straně QI dělat úpravy. Pokud ne, pak by úprava importu proběhla formou dopracování aplikace ve QI. |
4 | Možnost evidovat jako odběratele zdravotní pojišťovny s možností importu podkladů pro fakturaci. | Implementace | 1. je standardní funkcionalita aplikace | Zdravotní pojišťovna je evidována v obchodních partnerech jako odběratel. Import podkladů pro fakturaci je připraven (data připravuje NIS). |
5 | Možnost kontroly a doplnění údajů o odběrateli z evidence XXXX, Insolvenčního rejstříku, nespolehlivý plátce DPH. | Implementace | 1. je standardní funkcionalita aplikace | Interaktivní podpora všech požadovaných registrů. |
6 | On-line informace o saldokontu, stavu otevřených (aktivních) pohledávek. Možnost automatického i ručního párování otevřených pohledávek. Možnost párování zrušit a provést párování nové. | Implementace | 1. je standardní funkcionalita aplikace | Standardní uživatelský postup. V rámci formuláře saldokontní kniha jsou k dispozici tlačítka pro ruční spárování nebo rozpárování dokladů ve skupině. Uživatel označuje řádky (doklady) na kterých potřebuje operaci provést. |
7 | Identifikace odběratele podle: IČ, názvu, více DIČ, IČZ. Možnost dle zmíněných identifikací filtrovat a hledat. | Implementace | 1. je standardní funkcionalita aplikace | Vyhledávat a třídit lze podle všech zobrazených sloupců v přehledech závazků. Uživatelsky definované filtry případně profily jsou ukládány pro uživatele v rámci kontextu - lze je kdykoliv vyvolat a systém si automaticky pro daný formulář pamatuje poslední použitý filtr. Uživatel pro předefinované filtry zadává pouze hodnoty, které se mění pro konkrétní přehled. |
8 | Možnost nastavení výchozího způsobu upomínání a výpočtu penále. | Implementace | 1. je standardní funkcionalita aplikace | Zadáno základní konfigurací IS. Definuje se počet upomínek a počet dní, kdy se jednotlivé upomínky generují od doby, kdy byla vygenerována předchozí upomínka. Penalizaci je možné provádět jako průběžnou nebo konečnou. Procenta penále vycházejí z konfigurace dokladů, obchodních partnerů nebo celého systému. |
9 | Možnost evidence všech prodejních dokladů (objednávky, faktury, dobropisy, zálohy) včetně všech souvisejících údajů. Umožnit při zadání odběratele na doklad doplnění adresy, bez nutnosti ručního zápisu adresy. | Implementace | 1. je standardní funkcionalita aplikace | Automatická funkce na základě propojení databáze Obchodních partnerů a souvisejících dokladů. |
10 | Evidence saldokonta odběratele v domácí měně i cizích měnách, pokud jsou u daného odběratele používány. Možnost nastavit upozornění na odběratele, který má vysoké pohledávky. | Implementace | 1. je standardní funkcionalita aplikace | Sledování platební morálky odběratele dle atributů (dluh, povolený počet dnů po splatnosti,...) lze používat v úrovní upozornění při tvorbě nového dokladu nebo zákazu vystavení prodejního dokladu pro konkrétního uživatele. V případě povolení odpovědné osoby lze doklad vystavit. |
11 | Sestavení výkazů pohledávek před/po splatnosti dle období. Možnost sestavit výkaz v libovolném čase bez nutnosti uzavírat otevřené období. | Implementace | 1. je standardní funkcionalita aplikace | Rozbor stavu pohledávek "ke dni" nezávislý na aktuálním účetním období. Je zpracováván on-line ke zvolenému datu. |
12 | Možnost z objednávek vytvářet dodávky bez nutnosti účtování faktury. Umožnit z jedné prodejní objednávky vytvořit libovolný počet dodávek. | Implementace | 1. je standardní funkcionalita aplikace | Z objednávky přijaté lze překlápěním tvořit dodací listy vydané (jeden či více). Fakturaci dodacích listů vydaných lze spouštět následně hromadně (jedna faktura na více dodacích listů) |
13 | Přepočet částky v cizí měně pomocí automatického nebo ručně zadaného kurzu. Možnost zobrazit částky dokladu v cizí i domácí měně. | Implementace | 1. je standardní funkcionalita aplikace | Možnost vedení a zobrazení dokladu ve dvou měnách. Automatický přepočet měny na základě kurzu. |
14 | Možnost vytvářet zálohové doklady v domácí i cizí měně s možností zadání DPH, které je automaticky vypočteno a zaúčtováno při uhrazení zálohy. | Implementace | 1. je standardní funkcionalita aplikace | Zálohové listy lze vystavit v účetní měně i v cizí měně. Údaje vztahující se k DPH jsou využity buď pro automatickou tvorbu daňové dokladu k přijaté platbě, nebo ke správnému vyúčtování DPH při čerpání zálohového listu u vydané faktury. |
15 | Možnost přiřadit zálohovou platbu zúčtovací faktuře, umožnit přiřadit zálohu jen částečně. Při zúčtování zálohové platby je automaticky účtováno DPH. Možnost stornovat zaplacenou zálohu. | Implementace | 1. je standardní funkcionalita aplikace | K platbám zálohových listů, které dosud nebyly vyčerpány do finančního dokladu do výše zaplacení, které obsahují nenulovou DPH a ke kterým zatím nebyly vytvořeny daňové doklady na celou částku platby, jsou vytvářeny daňové doklady. |
16 | Možnost definice různých způsobů upomínání, penalizace a výpočtu úroků z prodlení. Nastavit parametry libovolného počtu úrovní upomínek a možnost přiřadit další náklady související s vytvořením upomínky. Automatické vytváření upomínek dle data. Evidence všech vystavených upomínek k danému odběrateli, možnost opakovaného tisku upomínky. | Implementace | 1. je standardní funkcionalita aplikace | Stupně upomínek, jejich počet, jejich pravidla pro vznik (dny po splatnosti nebo od předcházejícího stupně upomínky) jsou definovány v rámci konfigurace modulu Finance. Upomínky jsou na pokyn uživatele (výběr typu upomínky) tvořeny automaticky a hromadně. Upomínky jsou tvořeny obdobně jako jiné finanční doklady, mají tedy dokladovou řadu, jednoznačné číslo a lze je kdykoliv v historii dohledat a opakovaně tisknout a to včetně údajů, které byly ke dni vystavení upomínky platné. |
17 | Možnost sestavit zápočet (pouze pro odběratele nebo odběratel – dodavatel) a následně jej zaúčtovat dle předkontace. | Implementace | 1. je standardní funkcionalita aplikace | IS QI disponuje nástrojem pro přípravu i zaúčtování zápočtů (pro pohledávky a závazky jednoho obchodního partnera nebo tzv. třístranný zápočet). |
18 | Uživatelský číselník způsobu úhrady a platební podmínky s vazbou na doplnění data splatnosti dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Číselník způsobů úhrady. Doplnění data splatnosti dokladu má QI standardně postaveno na základě nastavení pro systém, partnera nebo smlouvy, na základě které je fakturováno. |
19 | Předdefinování bankovního účtu na dokladech. Možnost v případě potřeby zvolit jiný bankovní účet. | Implementace | 1. je standardní funkcionalita aplikace | Bankovní účet lze předefinovat pro uživatele, který doklad vystavuje, pro konkrétního obchodního partnera, např. v závislosti na domluvené měně, ve které se doklady vystavují. Přednaplněný účet vlastní organizace lze ručně upravit na každém dokladu. |
20 | Evidence a správa finančních kont pacientů. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Ve QI může být nositelem obchodního vztahu také Osoba. Přes vazbu dokladů a partnera (obvykle se jedná o pokladní příjemky a výdejky) je zajištěno sledování konta pacienta. Pokladní kniha může být rozšířena o upravené tiskové výstupy tak, aby byl pro konkrétního pacienta k dispozici jednoduchý přehled o počátečním stavu konta, pohybech a zůstatku. Takovéto výstupy nejsou standardem QI, v minulosti jsme je realizovali formou zakázkových úprav pro naše zákazníky. |
21 | Možnost tvorby opravných položek k pohledávkám (jak účetních, tak daňových) a jejich účtování dle předkontací. | Implementace | 1. je standardní funkcionalita aplikace | Systém podporuje tvorbu opravných položek s kontrolou na aktuálně platnou legislativní normu. O účetních OP lze účtovat. |
22 | Evidence fyzických osob - klientů protialkoholní záchytné stanice včetně reportů pro kraj. | Implementace | 1. je standardní funkcionalita aplikace | Standardní funkčnost modulu Obchodní partneři, Osoby. |
3.2 Faktury | Požadavek | Splňuje | Popis | |
1 | Možnost fakturovat dodávky materiálu nebo služby, včetně fakturace nepojištěných pacientů. | Implementace | 1. je standardní funkcionalita aplikace | V systému je možné vystavovat faktury za materiál i služby. Fakturovat lze i na subjekt bez vazby na číselník Obchodních partnerů. V případě nepojištěných pacientů se může organizace rozhodnout, zda nepojištěného pacienta zadá do číselníků obchodních partnerů a bude tak využívat v budoucnu další funkcionality systému, které doklady s identifikátorem partnera umožňují (např. hlídání limitu partnera pro tvorbu opravných položek apod.) nebo vystaví doklad přímo bez vazby na číselník a bude s doklady pracovat individuálně. |
2 | Možnost nastavení volitelného období uzávěrek knihy faktur (k současnému dni, v rozmezí od-do). | Implementace | 1. je standardní funkcionalita aplikace | Účetní závěrku lze spustit za libovolný časový interval, který spadá do zvoleného účetního období. Také lze položky faktur v deníku auditovat a tím uzavřít záznamy v deníku samostatně od dalších evidencí. |
3 | Možnost fakturovat jednou fakturou více dodávek nebo pro jednu dodávku vytvořit více faktur (postupné fakturování dodávky po dílčích částech). | Implementace | 1. je standardní funkcionalita aplikace | Dokladem pro dodávku je ve QI dodací list vydaný. Fakturovat lze dodací listy jedna k jedné nebo lze tvořit jednu fakturu k více dodacím listům nebo naopak více faktur k jednomu dodacímu listu. |
4 | Minimálně 20 dokladových řad faktur, kontrola číselné dodavatelských faktur. | Implementace | 1. je standardní funkcionalita aplikace | Počet dokladových řad faktur není ve QI omezen. Evidenční číslo dokladu je ve QI jedinečné. Kontrola číselných řad na straně dodavatele je obvykle kontrolována na variabilní symbol nebo smlouvu. |
5 | Možnost vystavení penalizační faktury za pozdní platby s použitím různých sazeb definovaných uživatelem včetně platnosti sazby (2T repo sazby). Umožnit automatické navržení penalizačních faktur pro vybranou skupinu odběratelů nebo pro všechny odběratele v systému. Tisk penalizačních faktur včetně opakovaného tisku. Možnost penalizační faktury účtovat nebo pouze evidovat bez účtování. Automatický výpočet opravné položky k pohledávkám. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožnuje penalizaci, dle nastavení v konfiguraci - penalizace průběžná či konečná. Používaný způsob penalizace je možné nastavit zvlášť pro každého obchodního partnera. Při spuštění funkce tvorby penalizačních faktur systém navrhne partnery, kde jsou splněny podmínky pro penalizaci. Uživatel pak rozhodne, zda vytvoří doklady ke všem navrženým partnerům nebo provede vlastní výběr. Kromě tiskového výstupu lze penalizační faktury i exportovat (PDF). Nastavení účtování probíhá na základně dokladových řad. Funkcionalita tvorby opravných položek k pohledávkám (zákonných i nad rámec zákona) je standardem modulu Finance. |
6 | Vytvoření přehledu všech otevřených (neuhrazených) faktur odběratele. Vytvoření sestavy všech částečně uhrazených faktur odběratele (neúplně zaplacené faktury) včetně možnosti zobrazení platby k faktuře, i zpětně k datu. | Implementace | 1. je standardní funkcionalita aplikace | Přehledy faktur jsou dostupné bez ohledu na období a to včetně všech souvisejících informací (DPH, účtování, úhrady - zápočty, opravné daňové doklady….). |
7 | Účtování částečné úhrady k otevřeným položkám. Možnost fakturu vyrovnat více platbami. Možnost zrušit vyrovnání faktury s platbami a nastavit vyrovnání nové. | Implementace | 1. je standardní funkcionalita aplikace | Postup účtování úhrad a práce s platbou je řešena prostřednictvím základních funkčností systému QI, požadované možnosti jsou ve QI možné. |
8 | Automatické zúčtování kurzových zisků a ztrát a účtování odchylek při párování plateb a faktur na základě parametrizace. | Implementace | 1. je standardní funkcionalita aplikace | Automatické zúčtování kurzových zisků a ztrát je standardem QI. Účtování odchylek po párování probíhá automaticky a to hromadnou tvorbou interního dokladu - platby, který zajistí vyrovnání pohledávky dle parametrů (od, do, datumový rozhodný údaj - vystavení, zaúčtování, splatnost, období DPH, maximální výše vyrovnání, datum zaúčtování odchylky) |
9 | Možnost parametrizace DPH pro prodejní doklady (DPH na výstupu) včetně sazeb a účtů z účtového rozvrhu Možnost nastavení platnosti DPH sazeb. | Implementace | 1. je standardní funkcionalita aplikace | Parametrizace DPH probíhá v systému na základě přiřazení unikátního indexu DPH (dle typu dokladu, místa plnění, sazby DPH,…). Dle nich je možné definovat i účetní souvztažnost. Platnosti sazeb DPH jsou součástí základního číselníku. |
10 | Libovolný počet sazeb DPH, včetně nulové, pomocí DPH předkontací. Možnost v případě potřeby ruční úpravy - změna sazby DPH na řádku dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje libovolný počet sazeb DPH, včetně nulové, pomocí DPH předkontací, vč. ruční úpravy - změny sazby DPH na řádku dokladu. |
11 | Využití více sazeb DPH na jedné faktuře, dobropisu. | Implementace | 1. je standardní funkcionalita aplikace | Na jedné faktuře či dobropisu je možné evidovat více sazeb DPH. |
12 | Automatický výpočet DPH pro každou fakturu bez možnosti zásahu běžným uživatelem. Vypočtena je celková částka DPH a DPH dle jednotlivých sazeb. Možnost nastavení zaokrouhlení. | Implementace | 1. je standardní funkcionalita aplikace | Výpočet DPH probíhá automaticky pro každou fakturu bez možnosti zásahu běžným uživatelem. Vypočtena je celková částka DPH a DPH dle jednotlivých sazeb. Zaokrouhlování prodejních cen s DPH/ prodejních cen bez DPH, zaokrouhlování DPH za doklad, typ zaokrouhlování DPH apod. jsou konfigurační parametry globálního nastavení systému. |
13 | Možnost zadat jiné datum dokladu pro evidenci DPH a pro účetní evidenci. | Implementace | 1. je standardní funkcionalita aplikace | Na hlavičce faktury je možné vyplnit datum zaevidování, datum zd. plnění, datum uplatnění zd. plnění a datum zaúčtování. O DPH lze účtovat dle data přijetí dokladu. |
14 | Možnost definovaných (v šabloně) i nedefinovaných textů na faktuře. | Implementace | 1. je standardní funkcionalita aplikace | Na faktuře je možné doplnit poznámku a také využít číselník vzorových textů, který obsahuje uživatelsky definovaná data, a ta mohou být následně používána také v tiskových výstupech dokladů. |
15 | Možnost kontroly konsolidace - vazba na PKP (pomocný konsolidační přehled). | Implementace | 1. je standardní funkcionalita aplikace | Systém QI obsahuje aparát pro tvorbu výkazů PKP, které jsou generovány ve formátu XML. Rozpad sledovaných účtů zařazených do PKP dle IČ obchodního partnera se definuje jako vlastnost účtu účtového rozvrhu pro PKP. Kromě sledování IČ na účtech lze sledovat také doplňkový druh "Finanční" spojený s pohybem peněz a "Veřejná zakázka" pro sledování veřejných zakázek. |
16 | Výkaz o peněžních příjmech a výdejích MF. | Implementace | 1. je standardní funkcionalita aplikace | Výkaz peněžních příjmů a výdajů je součástí definovaných účetních sestav. Výkaz se odevzdá formou samostatného XML souboru, které se po zašifrování odešle na portál státní pokladny. |
17 | Kontrola výpočtu základu daně a DPH. | Implementace | 1. je standardní funkcionalita aplikace | Systém dle nastavení v konfiguraci hlídá nesrovnalosti a upozorňuje uživatele na rozdíly. |
18 | Při likvidaci dodavatelské faktury nebo její části výpočet rozdílu ceny oproti objednávce, zvýraznění rozdílových položek. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Fakturu a objednávku / objednávky lze navzájem propojit přímo z hlavičky dokladu. V seznamu připojených objednávek je zobrazena částka dokladu a stav vydané objednávky (nevykryto/částečně vykryto). Zcela vykryté objednávky se uživateli nenabízejí. Doklad lze zobrazit. Doporučujeme však využít jinou možnost pořízení dokladu a tou je tvorba dodacího listu z objednávky (nebo tvorba dodacího listu multivýběrem objednávek), kdy dojde ke kontrole věcné správnosti objednávky (použití jak pro zboží, tak i pro služby). Faktura se pak tvoří buď z odsouhlaseného dodacího listu a nebo se propojí faktura (může již být v systému zaevidovaná např. ze spisové služby, ISDOC a čeká na likvidaci) s dodacím listem a systém zobrazí odchylku (rozdíl z ocenění) celého dokladu. Uživatel pak rozhoduje, jak s odchylkou dále pracuje. Zda se jedná o chybu dodavatele nebo se jedná o související náklady, které se budou rozpouštět do položky dokladu nebo celého dokladu nebo se jedná o jiný případ. V tomto procesu nebývá potřeba dalšího zvýrazňování položek pro uživatele. Uživateli jsou všechny případné odchylky zřetelně zobrazeny. Pokud by požadavek přetrval, bude zvýraznění položek předmětem programové úpravy. |
19 | Možnost exportu faktury do pdf a odeslání e- mailem. | Implementace | 1. je standardní funkcionalita aplikace | Podporované formáty pro export dokladů: rtf, html, pdf, isdoc. Uživateli je možné v konfiguraci nastavit odesílání e-mailem. |
3.3. Nákup a závazky | Požadavek | Splňuje | Popis | |
1 | Systém musí zajistit evidenci dodavatelů, jejich saldokonta a spravování všech dokladů souvisejících s dodavatelem (poptávky, objednávky, faktury, zálohové faktury, dobropisy, platby, smlouvy). | Implementace | 1. je standardní funkcionalita aplikace | Propojení všech souvisejících dokladů (zobrazení "dokladu z dokladu". Komplexní správa Dodavatelů v modulu Obchodní partneři. Podpora CRM. |
2 | Pro efektivní řízení nákupů je nutná provázanost žádankového systému, objednávek, smluv a došlých faktur. K požadovanému zajištění elektronického (bezpapírového) oběhu dokladů je nutné, aby nad jednotlivými agendami bylo možné definovat WorkFlow a k jednotlivým | Implementace | 1. je standardní funkcionalita aplikace | Celý proces nákupu je v IS QI dokladově provázán. Standardem je řízený schvalovací proces (workflow) a související dokumenty (DMS). |
dokladům připojit odkazy na související dokumenty. | ||||
3 | Účtování nákupních dokladů a zápis do evidence DPH musí probíhat automaticky na základě definovaných předkontací. | Implementace | 1. je standardní funkcionalita aplikace | Jedná se o standardní funkcionalitu systému. |
4 | Systém musí umožňovat zápočty. | Implementace | 1. je standardní funkcionalita aplikace | Jedná se o standardní funkcionalitu systému. |
5 | Evidence výběrových řízení, vazba na produkty, aktuální info o plnění smlouvy (peníze nebo čas). Generování zadání, návrhu smlouvy, evidence zaslaných nabídek + potvrzení přijetí, evidence došlých nabídek, zápis o výběru - generování, xxxxxxxx | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Standardní poptávkový a nabídkový systém s možností rozšíření. Komplexní modul na evidenci a řízení smluv. |
3.4 Evidence dodavatelů | Požadavek | Splňuje | Popis | |
1 | Možnost evidence libovolného počtu dodavatelů. Evidence a vyhledávání dodavatele na základě různých údajů (IČO, název, bankovní účet, apod.), vazba na PKP (pomocný konsolidační přehled). | Implementace | 1. je standardní funkcionalita aplikace | Jedná se o standardní funkcionalitu systému. |
2 | Podpora zobrazení on-line saldokonta dodavatele, evidence všech transakcí, které byly uskutečněny s daným dodavatelem. | Implementace | 1. je standardní funkcionalita aplikace | Identická funkčnost jako na straně Odběratelů. |
3 | Možnost nastavení libovolného počtu bankovních účtů pro dodavatele. Možnost zadat další adresy pro dodavatele, které jsou odlišné od adresy uvedené na kartě dodavatele. | Implementace | 1. je standardní funkcionalita aplikace | Identická funkčnost jako na straně Odběratelů. |
4 | Možnost kontroly a doplnění údajů o dodavateli z evidence XXXX, kontrola na Insolvenční rejstřík a plátce | Implementace | 1. je standardní funkcionalita aplikace | Identická funkčnost jako na straně Odběratelů. |
DPH, pro zahraniční kontrola VIES. | ||||
5 | Uložení všech údajů bankovního účtu nezbytných pro vytvoření platebního příkazu (název banky, pobočka, číslo účtu, IBAN a SWIFT kód u zahraničních dodavatelů atd.). | Implementace | 1. je standardní funkcionalita aplikace | Uvedené atributy jsou součástí definice Bankovního spojení u partnera. Do dokladu se přednaplní účet dle konfigurace. Úplné informace o bankovním spojení se pak použijí pří tvorbě příkazu k úhradě. |
6 | Možnost zadání více bankovních účtů dodavatele bez nutnosti zakládat více karet dodavatele. Kontrola správnosti bankovního účtu (tzv. "modulo 11"). | Implementace | 1. je standardní funkcionalita aplikace | Počet bankovních účtů dodavatele není omezen. Standard kontroluje modulo 11 jen ve mzdách. Lze připojit kontrolu i na účty partnerů vedené v CZK v číselníku obchodních partnerů. |
7 | Sledování stavu závazků za jednotlivé zdravotní pojišťovny a za Zdravotní pojišťovny celkem. | Implementace | 1. je standardní funkcionalita aplikace | Stav závazků lze sledovat za libovolného partnera, včetně zdr. pojišťoven. |
8 | Zadávání dalších relevantních údajů o dodavateli (slevy, adresy objednávek, možnost vazby dodavatel karta zboží - číslo zboží dodavatele, možnost zvolit pro dodavatele výchozí měnu). | Implementace | 1. je standardní funkcionalita aplikace | Komplexní nastavení pomocí Dodacích podmínek dodavatele. |
3.5 Žádanky a objednávky | Požadavek | Splňuje | Popis | |
1 | Možnost vytvářet nákupní objednávky v libovolném počtu a sledovat stav plnění - objednáno, v případě materiálu nebo zboží sledovat přijaté množství a množství zbývající k příjmu. Pro jednoho dodavatele možnost vystavit libovolný počet objednávek, případně objednávku s postupným plněním. Možnost libovolného počtu číselných řad pro objednávky. Možnost připojit přílohu k objednávce (např. cenová | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Nabízený systém zahrnuje možnost vytvářet nákupní objednávky v libovolném počtu a sledovat stav plnění pomocí workflow stavů a sledovat přijaté množství a množství zbývající k příjmu. Umožňuje vystavit libovolné množství objednávek v libovolném počtu číselných řad. Objednávky lze postupně plnit. Do objednávky lze přenést poznámku ze žádanky. K objednávce je možné připojit dokument(y). Připojený(é) dokument(y) k objednávce lze odeslat. |
nabídka), možno přenést poznámku u položky ze žádanky do dodavatelské objednávky (např. upřesnění velikosti materiálu). | ||||
2 | Objednávka musí nést základní informace o dodavateli, od kterého je požadována dodávka materiálu nebo služby. Možnost zadat odpovědnou osobu za nákup a další atributy (např. nákladové středisko). Do objednávky je možné zadat libovolný počet objednávaného materiálu, možnost zadat pouze textovou specifikaci objednávky. Možnost textové žádanky bez vazby na kmenový záznam materiálu. Objednávka má vazbu na žádanku z oddělení (lze snadno dohledat, pro koho byl materiál objednán). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Nabízené řešení umožňuje evidovat u objednávky informace o dodavateli, odpovědné osobě za nákup, nákladové středisko, zdroj financování a další potřebné informace. Objednávka může obsahovat libovolný počet položek, případně pouze textovou specifikaci objednávky. Systém umožňuje zadávat textové žádanky bez vazby na materiál skladu. Objednávka má vazbu na žádanku(y) z oddělení, pro koho byl materiál objednán, kterou lze snadno dohledat. |
3 | Možnost nastavit nad objednávkou WorkFlow pro schválení objednávky. Workflow má možnost několikastupňového schvalování. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Nabízené řešení umožňuje pomocí workflow nastavit několika stupňový schvalovací proces nad objednávkou např. v závislosti na limitech vztažených k objednací ceně či druhu objednávky (různé uživatelské role mohou schvalovat různé druhy objednávek atd.). |
4 | Možnost vytvořit skladovou žádanku a nastavit nad ní WorkFlow. Objednávku pak generovat ze schválené žádanky, generování více objednávek z jedné žádanky a generování objednávky z více žádanek, možnost zadat pouze textovou žádanku, možnost řídit úrovně schvalování podle limitů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Nabízené řešení umožňuje vytvořit skladovou žádanku se schvalovacím workflow procesem a generovat z ní jednu nebo více objednávek, nebo generovat jednu objednávku z více žádanek, zadat pouze textovou žádanku a schvalovací proces řídit např. dle cenových limitů apod. |
5 | Možnost vazby objednávky na smlouvu. Umožnit evidovat smlouvy ve více číselných řadách dle typu | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Objednávky umožňují vazbu na smlouvy výběrových řízení. Smlouvy lze evidovat ve více číselných řadách, připojit ke smlouvě dokumenty a definovat workflow. |
smlouvy. Možnost připojit ke smlouvě odkazy na související dokumenty, včetně těch, které jsou uložený ve spisové službě, a definovat nad smlouvou WorkFlow. | ||||
6 | Generování příjemky z objednávky. Při příjmu materiálu umožnit z objednávky - částečný příjem (příjem pouze části objednaného materiálu), s evidencí o nedodaném materiálu, - více příjemek - změnu položky při příjmu (např. při vykrytí alternativním materiálem) při zachování vazby na žádanku - příjem a výdej na oddělení bez faktury, při zaúčtování faktury pak systém umožní aktualizaci ocenění materiálu a zpracování cenových rozdílů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Při příjmu lze udělat - Částečný příjem, - Evidovat nedodaný materiál - Vytvořit více příjemek z jedné objednávky - Změnit položku při příjmu alternativním materiálem Jako metodicky správný postup doporučujeme: změnit položku v rezervacích, z rezervací vygenerovat objednávku a příjem vygenerovat na základě objednávky - Příjem na sklad bez existence faktury se realizuje příjmem na příjmový sklad bez cen. Z příjmového skladu lze následně vydávat (také bez nacenění). Při následné likvidaci KDF z příjmu na příjmovém skladu dojde k aktualizaci cen materiálu a automatickému převodu pohybů do centrálního skladu včetně nacenění návazně zrealizovaných výdejů. |
7 | Evidence otevřených - nedodaných a nefakturovaných objednávek. Možnost zobrazení nedodaného materiálu včetně možnosti zobrazení položek, které byly již dodané, ale nebyly vyfakturované. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek, umožňuje u objednávky evidovat i nedodané a nefakturované objednávky, nedodaný materiál a zobrazuje položky materiálu na příjmovém skladu, které byly dodané, ale nebyly vyfakturované. |
8 | Vytváření objednávek na opakovaná plnění, možnost uživatelského vytvoření šablon pro opakované, periodické objednávky. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožnuje tvořit tzv. uživatelské šablony objednávek s předem definovanými texty pro vkládání do dodavatelských objednávek. Šablony si může každý uživatel vytvářet sám, příp. implicitně, tzn., že šablona je dostupná všem uživatelům. U skladových žádanek je k dispozici i možnost vytváření šablon žádanek pro usnadnění práce při opakovaném zadávání obdobných (periodických) žádanek a následně ze žádanky generovat objednávku. |
9 | Vazba objednávky, příjemky a následné faktury. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. V případě, že je příjem vytvářen z objednávky, systém zajistí automatickou vazbu objednávky, příjemky a došlé faktury. Související doklady je možné sledovat na přehledových formulářích využitím filtrace, třídění a exportů do formátu .xls. |
10 | Workflow na schválení nového materiálu. Workflow je vícestupňové, je možné zadat více položek do jednoho formuláře, o výsledku schvalování jde zpětná vazba žadateli. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek a je možné v katalogu materiálu vícestupňově schvalovat založení nových položek pomocí workflow. Formou e- mailové notifikace je výsledek schvalování možné zasílat kterémukoliv uživateli, který je zúčastněn daného procesu. |
11 | Nastavení limitů nákladového střediska pro schvalování žádanek na nákup materiálu. Limity - objednávající vidí aktuání stav limitu, hodnotu objednávky, hodnotu materiálu již dodaného (spotřebovaného), hodnotu materiálu "na cestě" (objednaný, ale zatím nedodaný materiál) ; upozornění při překročení limitu; oznámení schvalujícímu do e-mailu o potřebě schválení žádanky ; přehled čepání limitů nákladových středisek při přihlášení do programu (pro každého uživatele za nákladová střediska, na která má práva). Limity lze zadat v celé struktuře nemocnice - klinika - nákladové středisko - sklad. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek a u nákladových středisek je možné definovat rozpočet pro žádanky na materiál (limity). Objednávající - žadatel - při přihlášení do programu vidí: - aktuální stav svého limitu (dle nákladového střediska na které má přístupová práva a pod kterým žádanku vystavuje), - hodnotu dodaného materiálu, - hodnotu objednaného ale nedodaného materiálu. Kontrola čerpání limitu může být jak měkká (pouze upozornění) nebo tvrdá (systém nedovolí vytvořit žádanku v případě překročení limitu). Požadavek na schválení může být avizován formou e- mailové notifikace schvalovateli. Limity lze zadat v celé struktuře nemocnice - klinika - nákladové středisko - sklad resp. objednací místo. |
12 | Priorita žádanek - normální, vysoká, statim | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. U žádanek je možné pracovat s atributem Priorita v libovolném členění. |
13 | Lze vystavit objednávku z vazboiu na nákladové středisko. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. U objednávek je možné pracovat s atributem Nákladové středisko jak v hlavičce objednávky, tak v položkách objednávky. |
14 | Systém umožňuje implementaci elektronické komunikace s dodavateli. | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Objednávky je možné odeslat formou e-mailů na kontaktní adresy dodavatele. Rozšířenou komunikaci s dodavateli řeší modul Obchodní korespondence. |
3.6 Došlé Faktury | Požadavek | Splňuje | Popis | |
1 | Evidence dodavatelských faktur ve formě knihy došlých faktur a následná možnost vytvoření nákupního dokladu bez nutnosti zadávání duplicitních údajů. V knize došlých faktur evidovat částky (v měně), datum přijetí, datum uskutečnění zdanitelného plnění, datum splatnosti, údaje o objednávkách, libovolný text. Kontrola duplicity variabilního symbolu přijatých faktur. | Implementace | 1. je standardní funkcionalita aplikace | Při evidenci faktur přijatých je možno připojit dodací listy, zálohy, objednávky. Nákupní doklad (dodací list přijatý) lze zaevidovat v jednom kroku při pořizování faktury přijaté, aniž by docházelo k duplicitnímu zadávání údajů ať už o partnerovi nebo o položkách dokladu. Na hlavičce dokladu uživatel vyplňuje Obchodního partnera, částku, datum zaevidování, datum uskutečnění zdanitelného plnění, datum splatnosti, poznámku (libovolný text či výběr ze vzorových textů) atd... Kontrola duplicity variabilního symbolu probíhá automaticky a systém uživatele na tento fakt upozorní. |
2 | Možnost definovat WorkFlow nad knihou došlých faktur s evidencí jednotlivých schvalovacích kroků. Tisk knihy došlých faktur. Možnost elektronického podepisováni v rámci schvalovacích kroků. | Implementace | 1. je standardní funkcionalita aplikace | Nad dokladovou řadou faktur a v kombinaci s finančním objemem, dodavatelem nebo tzv. klíčovým slovem lze definovat vícestupňové schvalovací schéma. V historii schvalování každého dokladu je možné sledovat elektronické schválení jednotlivými stupni - datum, čas, uživatel. Jedná se o časovou známku a uložení uživatelského účtu, který schválení provedl. Tento záznam je neměnný. Tisk přehledů je možný nad každým formulářem. |
3 | V průběhu schvalování WorkFlow musí být připojený nascanovaný originál faktury u faktury v systému ERP. | Implementace | 1. je standardní funkcionalita aplikace | V přílohách faktury přijaté může být scan originálu faktury uložen formou odkazu na dokument nebo přímo vložený dokument s využitím modulu DMS. |
4 | Tvorba přehledu závazků | Implementace | 1. je standardní funkcionalita aplikace | Systém QI umožňuje zobrazení několika přehledových sestav závazků - kniha závazků, neuhrazené závazky, závazky ke schválení, přeplacené závazky, kniha závazků ke dni, časová struktura závazků, závazky v insolvenci atd. |
5 | Vedení více číselných řad došlých faktur i dobropisů. Umožnit uzamčení číselných řad včetně filtrování dle tohoto nastavení. | Implementace | 1. je standardní funkcionalita aplikace | Lze definovat více číselných řad došlých faktur i dobropisů. Jejich uzamčení se provádí v konfiguraci, a to nastavením atributu "Aktivní řada". Uzamčené řady se dále nenabízejí při tvorbě nového dokladu. |
6 | Fakturace v cizí měně, automatický přepočet pomocí kurzovního lístku. | Implementace | 1. je standardní | Kurz je přednaplněn z kurzovního lístku (import z ČNB ručně nebo na časovač) a je možné jej uživatelsky |
V případě nutnosti možnost změnit kurz na dokladu. Možnost zobrazit částky dokladu v domácí i cizí měně. | funkcionalita aplikace | změnit. Na dokladu jsou zobrazeny částky jak v cizí měně, tak i v účetní měně dokladu (domácí). | ||
7 | Rozložení fakturované částky v řádcích došlé faktury na více účtů a atributů. Možnost zadat na fakturu více řádků s uvedením účtu, možnost kombinace charakteru řádku účet a materiál včetně možnosti zadání prostého textu i rozsáhlejší poznámky. | Implementace | 1. je standardní funkcionalita aplikace | Počet řádků finančního dokladu není nijak omezen. Rozpis na více nákladových účtů je možný přímo při prvotním pořízení dokladu. Uživatelský popis položky je podporován číselníkem Vzorových textů. K položkám faktury přijaté je možné připojit aparát poznámek k položce dokladu. |
8 | On-line vyhledání a výběr dodavatelské faktury a dalších dokladů (platba, dobropis, záloha) podle uživatelských kritérií. | Implementace | 1. je standardní funkcionalita aplikace | Přehledy faktur jsou dostupné bez ohledu na období a to včetně všech souvisejících informací (DPH, účtování, úhrady - zápočty, opravné daňové doklady….) |
9 | Evidence částky, zaplacené dodavatelům – fyzickým osobám v průběhu roku pro povinné hlášení finančnímu úřadu. | Implementace | 1. je standardní funkcionalita aplikace | Prostřednictvím formuláře "Platby závazků" je možné získat přehled plateb za určité období, skupinu dokladů nebo za partnery, apod. |
10 | Možnost zadání variabilního symbolu, který je rozdílný od čísla faktury dodavatele. Možnost zadat na fakturu jakýkoliv bankovní účet, který je evidován u dodavatele. | Implementace | 1. je standardní funkcionalita aplikace | Variabilní symbol a číslo faktury dodavatele jsou dva rozdílné atributy. Na fakturu lze zadat jakýkoliv bankovní účet, který je evidován u dodavatele. |
11 | Evidence zálohových dokladů s možnosti zadat částku s DPH i bez DPH. Možnost vytvářet zálohové faktury i cizí měně. Možnost vytvořit libovolný počet záloh k jednomu dodavateli. | Implementace | 1. je standardní funkcionalita aplikace | Zálohový list se eviduje bez vazby na DPH, tedy pouze jako částka, která má být dodavateli uhrazena. Samotná problematika DPH je pak řešena v rámci daňového dokladu k zaplacené záloze nebo vyúčtovací faktury. Počet vystavených zálohových listů na jednoho dodavatele není omezen. |
12 | Účtovat úhrady záloh (zálohové platby) na samostatný účet dle předkontace u dodavatele. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje účtovat úhrady záloh (zálohové platby) na samostatný účet dle předkontace u dodavatele. |
13 | Párování zálohových plateb s později došlými zúčtovacími fakturami. Možnost přiřadit k zúčtovací faktuře část zálohové platby nebo více | Implementace | 1. je standardní funkcionalita aplikace | V okamžiku tvorby faktury přijaté systém upozorní, že jsou na daného dodavatele evidovány zaplacené a nevyčerpané zálohy. Uživatel může k jedné zúčtovací faktuře čerpat jednu nebo více záloh. |
zálohových plateb přiřadit k jedné zúčtovací faktuře. | ||||
14 | Účtování DPH v okamžiku přijetí daňového dokladu, možnost stanovit částku a částku DPH dle daňového dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Hlavička daňového dokladu obsahuje datum zaevidování, datum zd. plnění, datum uplatnění zd. plnění a datum zaúčtování. O DPH lze účtovat dle data přijetí dokladu. |
15 | Možnost sestavit zápočet (pouze pro dodavatele nebo odběratel – dodavatel) a následně jej zaúčtovat dle předkontace. | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Systém umožňuje sestavit zápočet pohledávek a závazků jednoho obchodního partnera nebo lze vytvořit i vícestranný zápočet. Účtování probíhá na základě nastavené předkontace v číselníku typů dokladů. |
16 | Možnost parametrizace DPH pro nákupní doklady (DPH na vstupu) včetně sazeb a předkontace. Z dokladu možnost zobrazit informaci o celkové částce a celkové částce DPH a detailně dle sazeb DPH. | Implementace | 1. je standardní funkcionalita aplikace | Parametrizace DPH probíhá na základě přiřazených indexů DPH a účetní souvztažnosti. V účetních a daňových položkách dokladu je možné zobrazení částek detailně i dle sazeb DPH. |
17 | Akceptace více sazeb DPH, včetně nulové sazby na jedné faktuře. Možnost v případě potřeby ruční úpravy - změna sazby DPH na řádku dokladu. Možnost stanovit výši, do jaké je možné provádět úpravu částky DPH. Nastavení sazby DPH jednotlivých položek ze skladových karet s vazbou na aktuálního dodavatele. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje libovolný počet sazeb DPH na jednom dokladu, včetně nulové. Sazby DPH lze na řádku dokladu ručně upravit. V číselníku zboží je nastaven atribut sazby DPH i aktuální dodavatel. Maximální hodnota úpravy částky (odchylka od výpočtu) je konfigurační parametr. |
18 | Možnost parametrizace DPH pro zpětné vrácení neuplatnění DPH na vstupu nebo krácení koeficientem na vstupu. | Implementace | 1. je standardní funkcionalita aplikace | Dle typu dokladu, místa plnění, výše sazby,… jsou přiřazeny položkám indexy DPH. U přijatých zdanitelných plnění uvádí uživatel nárok na odpočet Plný, Krátit, Nemá. V případě hodnoty Krátit dochází k uplatnění DPH ve výši zálohového koeficientu uvedeného v nastavení DPH. |
19 | Uživatelský číselník způsobu úhrady a platební podmínky s vazbou na doplnění data splatnosti dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Číselník „Způsob úhrady“ obsahuje seznam používaných způsobů úhrady, které vyjadřují, jak je realizována platba za zboží. V číselníku se evidují jak hotovostní tak bezhotovostní způsoby úhrady. Přednaplnění splatnosti dokladu provede systém na základě konfigurace modulu (obecná splatnost) nebo dle nastavení podmínek u obchodního partnera. |
20 | Automatické zúčtování kurzových zisků a ztrát a účtování odchylek při párování plateb a faktur na základě parametrizace. | Implementace | 1. je standardní funkcionalita aplikace | Automatické zúčtování kurzových zisků a ztrát je standardem QI. Účtování odchylek po párování probíhá automaticky a to hromadnou tvorbou interního dokladu - platby, který zajistí vyrovnání pohledávky dle parametrů (od, do, datumový rozhodný údaj - vystavení, zaúčtování, splatnost, období DPH, maximální výše vyrovnání, datum zaúčtování odchylky) |
21 | Možnost vytvoření splátkového kalendáře k faktuře, vazba na XXX | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Splátkový kalendář k faktuře lze vytvořit zcela dle potřeb. Počet plateb nebo rozsah datumů splátkového kalendáře není omezen. Jednotlivé splátky jsou respektovány v přehledových sestavách (dle splatnosti,…). Rozpad sledovaných účtů zařazených do PKP dle IČ obchodního partnera se definuje jako vlastnost účtu účtového rozvrhu pro PKP. Kromě sledování IČ na účtech lze sledovat také doplňkový druh "Finanční" spojený s pohybem peněz a "Veřejná zakázka" pro sledování veřejných zakázek. |
22 | Zpracování došlé faktury. Formát - isdoc xml Uživatel z email nahraje přílohu do ERP, tím se založí došlá faktura a vznikne první krok schvalovacího workflow. V případě, že v email je přiloženo pdf, nikoliv xml, po nahrání do systému vznikne založená prázdná faktura s přílohou. Workflow dále pokračuje věcným a účetním schválením. | Implementace | 1. je standardní funkcionalita aplikace | Po provedení importu ze souboru ISDOC.xml je vytvořen předběžný doklad, který má na základě konfigurace elektronické fakturace předvyplněny hlavičkové údaje (obchodní partner, datumy, odpočet DPH, plnění DPH) a zaevidovány položky dokladu. Položky dokladu mohou být tvořeny jednotlivě nebo mohou být sumarizovány. Soubor ISDOC je připojen k dokladu formou přílohy. Uživatel ho může zobrazit v čitelné podobě pomocí programu ISDOCReader. Tímto způsobem lze evidovat tyto typy přijatých dokladů - faktura přijatá, dobropis přijatý, záloha přijatá, daňový doklad k platbě. Zadání faktury přijaté na základě souboru pdf. lze provádět v seznamu předběžných dokladů ručně, v příloze vytvořeného dokladu je pak připojena příloha ve formátu PDF. Z předběžného dokladu je doklad vytvářen uživatelem. Funkce se spouští tlačítkem z předběžného dokladu. Tato funkce provede uživatele výběrem dokladové řady (povinný krok pro přidělení evidenčního čísla dokladu a zařazení dokladu do příslušné evidence) a předkontací dokladu (předkontace není povinným krokem). Po zaevidování dokladů spustí uživatel definované workflow, kdy projde faktura postupně schvalovacím procesem pro věcnou a účetní správnost. |
4. Sklady | Požadavek | Splňuje | Popis | |
1 | Systém musí zajišťovat vedení skladové evidence - skladových karet včetně pohybů zásob, sledování hodnoty zásob ve skladu a dostupnosti zásob. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje vedení skladové evidence na více skladech (centrální, příruční, konsignační, příjmový). Materiály jsou vedeny na skladových kartách včetně možnosti detailního rozčlenění podle položek materiálu. Součástí řešení je komplexní správa pohybů zásob (příjmy na sklad, výdeje ze skladu, převody mezi sklady, příjmy do spotřeby, skladové rezervace), sledování hodnoty zásob a jejich dostupnosti. Všechny pohyby vztažené ke konkrétní kartě materiálu jsou z karty zobrazitelné s možností dohledání původu vzniku pomocí třídění a filtrace dle atributů pohybových dokladů. |
2 | Do skladové evidence musí mít návaznost procesy nákupu od žádanky přes objednávku, příjemku až po spotřebu (výdej), i případný prodej jiným subjektům. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek a procesy žádanek, nákupů a veškeré skladové operace jsou navázané na skladovou evidenci a to i včetně prodejů externím subjektům. |
3 | Systém musí podporovat zaúčtování uskutečněných skladových pohybů do účetní evidence na základě předkontací. Musí být možná evidence zásob na libovolném množství skladů a systém musí podporovat jejich inventarizaci. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek a umožňuje správu předkontací skladových pohybů a zajišťuje okontování uskutečněných skladových pohybů. Umožňuje také vedení skladové evidence na více skladech různych typů (centrální, příruční, konsignační, příjmový) a provádění inventarizace dle platné legislativy. |
4 | Možnost evidence zboží nebo materiálu na skladových kartách, kde je na každé kartě zadána předkontace a tím nastaveno propojení na účetnictví pro jednotlivé druhy pohybu. Při vytváření skladové karty přenášet předkontaci dle jednoduchých nastavitelných pravidel pro uživatele ve skladu. Možnost ke skladové kartě přiřadit více měrných jednotek. Definovat skupiny skladových karet. U každé skladové karty možnost evidovat i katalogové názvy a čísla dodavatelů s možností vazby na nákupní doklad | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek a umožňuje správu předkontací skladových pohybů (druh pohybu x materiálová skupina x účet zásob x účet protistrany) a zajišťuje okontování uskutečněných skladových pohybů. Předkontace jsou definovány na druzích skladových pohybů. V katalogu materiálu lze definovat více povolených měrných jednotek, které lze při zařazení materiálu na sklad vybrat. U skladové karty lze evidovat katalogový název a čísla dodavatelů s možnosti provazby na objednávku. Systém umožňuje definovat skupiny skladových karet. Problematiku Podskupin je možné řešit pomocí atributu Typ materiálu, který umožňuje tvořit hierarchickou strukturu s libovolným počtem úrovní. Třída ZP je umístěna na katalogu materiálu. Kód SUKL je možné umístit na katalog materiálu. Počet KS v balení je uveden na skladové kartě. Při vystavování požadavků na skladový materiál vidí uživatel cenu za KS a zadává množství v KS. Pomocí parametrického nastavení je možné: - ignorovat počty KS v balení |
(tedy vytvářet objednávky, které obsluhují i dodavatelské názvy a čísla). Katalog produktů: skupiny skladových karet; podskupiny napříč skupinami; označení třídy zdravotnického prostředku; kód SUKL ; možnost zadální počtu kusů např. v balení pro objednávání celého balení nebo jeho násobků (oddělení vidí v žádance cenu za kus, ale nemůže objednat méně než celé balení) | - kontrolovat a upozorňovat, že množství KS neodpovídá balení - automaticky zaokrouhlovat množství na nejbližší násobek KS v balení. | |||
5 | Možnost na skladové kartě nastavit metodu oceňování zásob - FIFO, průměrná cena, pevná cena. On-line dostupná informace o ceně zásob včetně množství zásob celkem i dle skladů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje nastavit požadované metody oceňování materiálu. Oceňování lze realizovat metodou průměrných cen nebo metodou postupné spotřeby - FIFO. V případě FIFO jsou skladové karty rozděleny na jednotlivé položky příjmu a z těchto se provádí výdej. Dostupnost informací o ceně a množství zásob na jednotlivých skladech je součástí řešení, a to buď na přehledových formulářích, kde se dají dělat uživatelské filtrace a sumace, nebo na tiskových sestavách, které jsou součástí standardního řešení. |
6 | Možnost evidovat při příjmu šarži a datum exspirace, při výdeji možnost vydání dle nejstaršího data exspirace. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje evidovat při příjmu šarži a datum exspirace a při výdeji možnost vybrat položku s nejstarším datem exspirace. |
7 | Možnost nastavit parametry plánu pro doplňování zásob. Plán lze nastavit pro každou kartu individuálně. Na základě parametrů plánu možnost navrhnout doplnění zásob, provést jeho případné úpravy a následně přenést do nákupních objednávek. Možnost nastavený plán měnit v průběhu používání skladové karty. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje řídit doplňování zásob pro individuální materiál s ohledem na stavy zásob, průměrnou spotřebu, limitní hodnoty materiálu na skladu a dodací lhůty. Lze nastavit kritéria pro objednání materiálu včetně určení vhodného množství k objednání (dosažení limitního množství, průměrná spotřeba, maximální množství). Nastavení je možné v průběhu životního cyklu materiálové karty měnit. |
8 | Ze skladové karty musí být možné zobrazit veškeré vzniklé doklady nebo pohyby s možností rychlého dohledání původu vzniku, přehled | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Všechny pohyby vztažené ke konkrétní kartě materiálu (příjmy nebo výdaje) jsou z karty zobrazitelné s možností dohledání pomocí třídění a filtrace dle atributů pohybových dokladů např. zvolené období. |
jednotlivých příjmů a výdajů za zvolené období kliknutím z produktového katalogu. | ||||
9 | Možnost evidovat libovolný počet skladů a provádět mezi nimi převody – konfigurace jednotlivých skladů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje definovat neomezený počet skladů typu centrální, příjmový, příruční a konsignační a převádět mezi nimi materiál formou převodů mezi sklady (převod-příjem, převod-výdej). |
10 | Možnost evidovat zásoby na konsignačních skladech. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje práci s konsignačními sklady konkrétních dodavatelů, na nichž lze provádět standardní skladové operace. Řešení poskytuje podklady pro fakturaci na základě vydaného materiálu. Řešení poskytuje i možnost zajištění automatického přenosu dokladů výdejů z konsignačního skladu na nadřízený centrální sklad včetně jejich ocenění, a to vše na základě uskutečněného příjmu z konsignační objednávky na příslušném centrálním skladě. |
11 | Možnost výdeje zásob ze skladu a tisk výdejky. Vystavené doklady výdejek musí být evidovány. Možnost hromadného výdeje na více nákladových středisek, následně hromadný tisk výdejek. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení při výdeji zásob ze skladu vytváří záznam výdeje a umožňuje vytisknout příslušnou výdejku. Systém obsahuje nástroje pro hromadné vyskladnění z rezervací (i různých nákladových středisek) včetně následného tisku výdejek. |
12 | Ke skladovým pohybům možnost přiřadit atributy (např. k výdejce nákladové středisko) a poté zjistit pohyby s určitým atributem (např. všechny výdeje, tedy spotřebu, určitého nákladového střediska nebo dodavatele). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje evidovat u skladových pohybů atributy (např. Nákladové středisko a zdroj financování u výdejky) a následnou filtrací zobrazit pohyby dle atributů pohybových dokladů. |
13 | Provázanost skladové evidence s evidencí majetku a evidencí osobních ochranných pomůcek. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Nabízené řešení je provázáno s evidencí majetku. Systém umožňuje generování inventárního čísla jednoznačnou číselnou řadou s volně nastavitelnými prefixy a s ohledem na identifikaci druhu majetku (žádný, DHM- DM, DDHM-DDNM, OOP, atd.) na katalogu materiálu. U pohybu výdeje majetku je možné uvést i odebírajícího pracovníka (uživatele majetku), kterému je tento majetek vydáván. Spolu s účetním podkladem pro zaevidování nového majetku do ekonomického systému může odcházet název majetku, dodavatel, výrobce, servis, nákladové středisko, zdroj financování, uživatel majetku, inventární číslo, výrobní číslo, atd. |
14 | Možnost vytvořit skladovou žádanku a nastavit nad ní WorkFlow. Podpora procesu, kdy skladový referent schválenou žádanku dle skladové zásoby vykryje a vydá materiál ze skladu. V případě nedostatečné zásoby je žádanka využita jako podklad pro objednávku. Po příjmu je žádanka vykryta příjmem a materiál je vydán žádajícímu. Při příjmu kontrola cen (max. úhrada VZP, poslední příjem). Na schválené žádance může skladník zaměnit nebo zamítnout určitý materiál, změnit jeho množství, vybraný materiál přeposlat do jiného skladu. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Celý žádankový proces je řízen pomocí WorkFlow nastaveného v rámci implementace dle potřeb organizace. Řešení umožňuje zpracování žádanek na materiál prostřednictvím skladových rezervací, výdejem, objednáním, záměnou materiálu, příjmem objednaného materiálu. Řešení poskytuje zpětně informace žadateli s detaily o stavu zpracování k jednotlivým položkám žádanky. Řešení umožňuje tvorbu objednávek využívající metody obnovování zásob založené na aktuálním stavu materiálu, minimálním množství zásob, na definované průměrné spotřebě a případně dodacích lhůtách dodavatelů. Řešení umožňuje řízenou tvorbu objednávek na základě skladových rezervací, které nemohou být vykryty skladovými zásobami. Objednané množství lze optimalizovat na základě maximálního povoleného množství zásob materiálu. Vytvořené objednávky lze dodavateli odesílat formou emailových zpráv včetně tiskové sestavy objednávky ve formátu pdf. Při příjmu může probíhat kontrola cen (smluvní cena, max. cena VZP, poslední příjem). Na schválené žádance může skladník zaměnit nebo zamítnout určitý materiál, změnit jeho množství, vybraný materiál převést do jiného skladu. |
15 | On-line dostupné informace nejen o stavu zásob na skladě, ale také o následné dostupnosti zásob z nákupních objednávek. Možnost tisknout hodnotu zásob i zásoby, kdykoliv v průběhu období bez nutnosti uzavírání období. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení poskytuje informace jak o okamžitém stavu materiálu na skladech, tak i o stavu objednaného materiálu. Řešení umožňuje tisknout hodnotu zásob i zásoby kdykoliv v průběhu období bez nutnosti jeho uzavírání. |
16 | Možnosti vytvářet přehledy stavu a obratů zásob podle různých kritérií (sklady, druhy materiálu atd.) v návaznosti na zvolené období. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje vytvářet přehledy stavu a obratů zásob podle různých kritérií (sklady, druhy materiálu atd.) v návaznosti na zvolené období. |
17 | Inventarizace zásob kdykoliv v průběhu období, inventarizaci lze spustit pro kterýkoliv sklad. Tisk inventarizačního dokladu. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Je umožněno provádění pravidelných i nepravidelných inventur skladů dle platné legislativy. Inventury je možno provádět za kterýkoli sklad i s využitím výběru materiálové skupiny. Možnost tiskových sestav jako podkladů při fyzické inventuře i dokladů o provedení inventury a výsledcích inventury. |
18 | Možnost sledování šarží a sériových čísel pro skladové karty. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Možnost sledování šarží a sériových čísel je pro jednotlivé příjmy skladových položek v rámci konkrétní skladové karty. |
19 | Podpora příjmu, výdeje a inventarizace položek skladu pomocí čárových kódů a čtečky | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje inventarizaci položek skladu pomocí technologie snímání čárových kódů a přenosu fyzického stavu do evidenčního stavu vedeného v systému. |
20 | Vedení a správa dodavatelů k jednotlivým položkám materiálu včetně jejich preferencí (preferovaný dodavatel, výhradní dodavatel, ostatní dodavatelé), rozšířené sledování vlastností dodavatele (dodací lhůty, smluvní ceny, zajištění dodávek, označení materiálu dodavatele, … atd.). Do produktového kapatlogu možnost nastavení dodavatele z posledního příjmu - využití pro náhradní plnění. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Vedení a správu dodavatelů k jednotlivým položkám materiálu včetně jejich preferencí a označení materiálu dodavatele je možno provádět na katalogu materiálu. Součástí řešení je i rozšířené sledování výkonnosti dodavatelů (dodací lhůty, smluvní ceny, způsob zajištění dodávek atd.). Do produktového katalogu je možné nastavit dodavatele z posledního příjmu - využití pro náhradní plnění. |
21 | Podpora hromadného importu položek materiálu včetně definice dodavatele a skladové karty (např. z ceníku dodavatelské firmy). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení obsahuje nástroje pro import položek materiálu včetně importu dodavatelů a skladových karet. |
22 | Skladové karty obsahují množstevní limity – automatické hlídání a upozornění při překročení limitní hranice. Dle limitů lze generovat objednávky se systémem optimalizovaným množstvím na nákup. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje automatické hlídání a upozornění při překročení limitní hranice množství materiálu a tvorbu objednávek využívající metody obnovování zásob založené na aktuálním stavu materiálu, minimálním množství zásob, na definované průměrné spotřebě a případně dodacích lhůtách dodavatelů. |
23 | Podpora zákonem definovaného výpočtu DPH v dokladech tak, aby vzniklo automatické dopočítání druhé z cen (s DPH / bez DPH) v příjmových dokladech a možnost nastavení krátícího koeficientu. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje evidovat v cenách s DPH/bez DPH, přičemž lze nastavit automatický dopočet druhé z cen (například u příjmu). Skladové pohyby nesou příznak odpočtu DPH (bez odpočtu, krátící koeficient, plný odpočet) pomocí kterého dochází k přepočtu částky DPH, která se předává do ekonomického systému. |
24 | Podpora volby vedení materiálu na skladě v cenách s DPH / bez DPH. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Materiál lze vést v cenách s DPH/bez DPH, přičemž lze nastavit automatický dopočet druhé z cen. Možnost nastavit si u daného materiálu sazbu DPH, popř. osvobození od DPH. |
25 | Podpora upozorňování na výraznou změnu ceny při nákupu materiálu (větší než definované procento) vzhledem k poslednímu nákupu daného materiálu nebo jiné kontrolní ceně (např. cena VZP). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení upozorňuje při nákupu materiálu na výraznou změnu vzhledem k poslednímu přímu nebo např. kontrolní ceně VZP. |
26 | Na položkách skladových karet lze evidovat doplňkové informace (datum expirace, výrobní číslo, inventární číslo, výrobce, servisní organizace, …) | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje na položkách skladových karet evidovat požadované informace (výrobní číslo, inventární číslo, výrobce, servisní organizace, datum expirace, datum výroby, záruční servis, země původu, atd.). |
27 | Podpora tvorby standardních opravných dokladů – storna (zrušení celého dokladu), vratky (zrušení části dokladu) všech skladových dokladů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení podporuje zakládání opravných dokladů (vratky, stornodoklady) pro všechny druhy skladových dokladů s vazbou na zdrojový doklad. |
28 | Podpora tvorby speciálních opravných dokladů pro nastavení změny ceny v příjmových dokladech s přenesením změny ceny i do všech navázaných výdejových dokladů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení podporuje zakládání speciálních dokladů (tzv. opravka) pro opravu ceny materiálu v příjmových dokladech. Změněná cena je přenesena do všech navázaných výdejových dokladů. |
29 | Přehledy o zaúčtování materiálu podle různých kritérií pro detailní kontroly přenosů do účetního systému. Kontrola obratů na účtech. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje tvorbu přehledů pro detailní kontroly přenosů dokladů do účetního systému. K dispozici jsou např. kontrolní sestavy obratů na účtech a kontrolní sestavy přenosů do finančního deníku. |
30 | Přehledy o objednaném a nedodaném materiálu dle dodavatelů. Přehled o materiálu nedodaném v termínu dle dodavatelů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje tvorbu přehledů o nevyřízených položkách objednávek za zvolené období a s ohledem na zvoleného dodavatele. Dále je možné v případě objednávek na materiál u každého dodavatele materiálu zaevidovat dodavatelskou lhůtu a následně vytvářet přehled o nedodaném materiálu jednotlivých dodavatelů nebo o zpožděných dodávkách materiálu dle jednotlivých dodavatelů s ohledem na zvolenou délku intervalu pro nedodání. Součástí řešení je i možnost hodnocení bonity dodavatele na základě kritéria hodnocení bonity a výčtem možných hodnot |
hodnocení. Následně je možné každého dodavatele ohodnotit v daném kritériu a s ohledem na období. | ||||
31 | Podpora tvorby objednávek generováním z položek nevykrytých skladových rezervací. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje řízenou tvorbu objednávek na základě skladových rezervací, které nemohou být vykryty skladovými zásobami. |
32 | Řízená tvorba objednávek s ohledem na stavy, průměrnou spotřebu, limitní hodnoty materiálu na skladu – volba kritéria pro vyhodnocení materiálu vhodného k objednání včetně určení vhodného množství k objednání (podlimitní množství, průměrná spotřeba). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje tvorbu objednávek využívající metody obnovování zásob založené na aktuálním stavu materiálu, minimálním množství zásob, na definované průměrné spotřebě a případně dodacích lhůtách dodavatelů. Lze optimalizovat objednané množství na základě maximálního povoleného množství zásob materiálu. |
33 | Podpora odesílání objednávky dodavateli emailem. Email obsahuje: - pdf s objednávkou - link, na jehož rozkliknutí dojde k potvrzení objednávky. V případě, že dodavatel nepotvrzuje celou objednávku, dopisuje rozdíl textem do poznámky. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje pomocí nastavení odpovídajících procesů ve workflow odesílání vystavených objednávek emailem na dodavatele včetně sestavy objednávky ve formátu .pdf. Na objednávce může být indikován stav např. „Odesláno“ (automatické odeslání objednávky na dodavatele systémem), „Odesláno ručně“ (objednávka uživatelem vytištěna a odeslána poštou). Tyto procesy jsou volitelně nastavitelné dle druhů objednávek, dle objednacích míst, dle přání zákazníka. Dodavateli je možné zaslat emailovou notifikaci s URL odkazem na publikovaný formulář, kde může pomocí WF potvrdit objednávku. Alternativním postupem je potvrzení objednávky dodavatelem pomocí plně automatizovaného zpracování příchozího emailu od dodavatele, který musí splňovat dohodnutá pravidla. Obsah akceptace je uveden v textové části emailu. Příchozí akceptace je následně automaticky připojena k objednávce. Akceptace může být zařazena (většinou po úpravách typu anonymizace) do procesu zveřejňování na registru smluv. Systém workflow zajišťuje patřičné notifikace určeným osobám, které se účastní daného procesu. |
34 | Podpora tvorby rezervací na materiál s možností hromadného zpracování – výdej, objednání, zamítnutí, záměna materiálu. Podpora zpracování rezervací dle pořadí zakládání rezervací. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje zakládání rezervací materiálu s možností hromadného výdeje rezervovaného materiálu nebo v případě nevykrytých rezervací vystavením objednávky rezervovaného materiálu. Řešení umožňuje rovněž odmítnutí výdeje či nákupu rezervovaného materiálu, případně provádět záměnu za jiný materiál. V případě potřeby systém umožňuje provést i částečné zamítnutí či částečnou záměnu položky rezervace, a to v případě potřeby vydání jiného počtu kusů než je požadováno. Řešení podporuje chronologické |
zpracování rezervací v pořadí, v jakém byl materiál nárokován. | ||||
35 | Podpora tvorby inventur – možnost provádění inventury za konkrétní materiálové skupiny, sklad. Podpora tiskových sestav jako podkladů při fyzické inventuře i dokladů o provedení inventury. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje pravidelné i nepravidelné provádění inventury jak za celý sklad tak za konkrétní materiálové skupiny. Řešení poskytuje tištěné podklady pro provádění inventury fyzického množství materiálu i doklady o provedení inventury. Řešení rovněž podporuje tvorbu pohybů a dokladů pro zaznamenání inventurních rozdílů. V případě inventury konsignačních skladů je možnost provést ocenění evidenčního a fyzického stavu pomocí smluvních cen vedených ke konkrétním materiálovým položkám. |
36 | Podpora práce s rozšířenými typy skladů – konsignační sklad s možností provádět běžné skladové operace. Sklad materiálu konkrétního dodavatele, vznik na základě smlouvy o konsignaci. Fakturace až po výdeji materiálu. Zajištění automatického přenosu dokladů konsignačního skladu na nadřízený centrální sklad včetně jejich ocenění. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje práci s konsignačními sklady konkrétních dodavatelů, na nichž lze provádět standardní skladové operace. Řešení poskytuje podklady pro fakturaci na základě vydaného materiálu. Řešení poskytuje i možnost zajištění automatického přenosu dokladů výdejů z konsignačního skladu na nadřízený centrální sklad včetně jejich ocenění, a to vše na základě uskutečněného příjmu z konsignační objednávky na příslušném centrálním skladě. Řešení umožňuje tiskové výstupy jako podklady pro fakturaci a zároveň jako podklady pro dodání materiálu na konsignační sklad, vše na základě tiskových předloh zadavatele, tzv. konsignační objednávky. |
37 | Podpora práce s rozšířenými typy skladů – příjmový sklad. Možnost vedení materiálu dočasně bez jeho ocenění a provádět nad ním běžné pohyby. Zajištění automatického přenosu dočasných dokladů na nadřízený centrální sklad včetně jejich ocenění. Možnost vedení dodavatelských konsignačních skladů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Možnost vedení materiálu dočasně bez jeho ocenění a provádět nad ním běžné pohyby lze pomocí příjmového skladu. Zajištění automatického přenosu dočasných dokladů na nadřízený centrální sklad včetně jejich ocenění. Možnost vedení dodavatelských konsignačních skladů - popsáno v bodě 36. |
38 | Podpora práce s rozšířenými typy skladů – příruční sklad. Vedení skladové agendy na menších skladech, které jsou závislé na skladě centrálním - příjem na sklad převodem z centrálního skladu. Podpora vedení stavu na skladech včetně cen. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje vedení skladové evidence na více skladech (centrální, příruční, konsignační, příjmový). Materiály jsou vedeny na skladových kartách včetně možnosti detailního rozčlenění podle položek materiálu. Součástí řešení je komplexní správa pohybů zásob (příjmy na sklad, výdeje ze skladu, převody mezi sklady, skladové rezervace), sledování hodnoty zásob a jejich dostupnosti. Všechny pohyby vztažené ke konkrétní kartě materiálu jsou z karty zobrazitelné s možností dohledání původu vzniku pomocí třídění a filtrace dle atributů pohybových dokladů. Systém umožňuje vedení stavu na skladech i včetně cen. |
39 | Podpora vytváření různých přehledů o příjmech materiálu – objem dle dodavatelů, skladů, materiálových skupin, klasifikace CPV. Speciální přehledy o příjmech VZP materiálu. CPV, VZP. Speciální přehled o vývoji ceny materiálu při nákupu od dodavatelů. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení podporuje vytváření přehledů o příjmech materiálu - objem dle dodavatelů, skladů, materiálových skupin, klasifikace CPV. Systém umožňuje generovat sestavu o příjmech VZP materiálu. Systém obsahuje číselníky CPV a VZP. |
40 | Podpora vytváření různých přehledů o výdejích materiálu – objem dle středisek, dle zdrojů financování (dotace, granty), skladů, materiálových skupin. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení podporuje vytváření přehledů o výdejích materiálu – přehled výdejů dle materiálu, dle středisek, dle zdrojů financování (dotace, granty, atd.), dle skladů, dle materiálových skupin. |
41 | Podpora vytváření centrálních přehledů o zásobách podle jednotlivých druhů materiálu ve skladech – aktuální stav materiálu na skladě, aktuální stav dle materiálových skupin, přehled materiálu, u kterého za poslední dobu nebyl žádný obrat. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení podporuje vytváření centrálních přehledů o zásobách podle jednotlivých druhů materiálu ve skladech např. aktuální stavy materiálu na skladě (sestava Přehled aktuálního stavu skladů ke dni volání sestavy), aktuální stavy dle materiálových skupin (sestava Spotřeba po skupinách), přehled bezobratového materiálu (sestava Seznam bezobratových karet). |
42 | Podpora určení konkrétního skladového materiálu, který může vstupovat do žádanek. Podpora omezení výběru materiálu pouze na materiál, který je aktuálně skladem / podpora rezervace materiálu, který není skladem. Možnost | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje určení materiálu, který může/nemůže vstupovat do žádanek. Řešení podporuje výběr materiálu, který je aktuálně skladem a podporuje rezervaci materiálu, který skladem není. Systém umožňuje nastavení pozitivního listu na středisko a tedy u skladových karet uvádět nákladová střediska, která mají povolení žádat daný materiál. Funkcionalitu negativního listu je možné zapracovat v rámci realizace implementace. |
nastavení pozitivního / negativního listu na úrovni jednotlivých středisek. | ||||
43 | Podpora víceúrovňového schvalování (funkce pro vytvoření žádanky, funkce pro schvalování, vrácení, případně předání žádanky na sklad v podobě rezervace). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje vytváření žádanek na materiál formou tzv. nákupního košíku. Žádanky se vystavují obdobně jako při nakupování na internetu (snadné, jednoznačné, téměř bez možnosti nesprávného zadání). Celý žádankový proces je řízen pomocí Workflow nastaveného v rámci implementace dle potřeb organizace. Součástí workflow může být víceúrovňové schvalování, vrácení, případně předání žádanky na sklad v podobě rezervace. Žádankový systém je integrován na skladové hospodářství, odkud využívá skladové karty určené skladem k nabízení a rozdělení těchto karet dle skladů. Sklady je možné v nákupním košíku kompetenčně omezit, např. materiál ze skladu údržby mohou žádat pouze údržbáři. |
44 | Podpora zpracování žádanek prostřednictvím skladových rezervací – výdej, objednání, záměna materiálu. Podpora zpětně informace s detaily o stavu zpracování k jednotlivým položkám žádanky pro zadavatele. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje zpracování žádanek na materiál prostřednictvím skladových rezervací, výdejem, objednáním, záměnou materiálu, příjmem objednaného materiálu. Řešení poskytuje zpětně informace žadateli s detaily o stavu zpracování k jednotlivým položkám žádanky. |
45 | Podpora vytváření šablon žádanek pro usnadnění práce při opakovaném zadávání obdobných (periodických) žádanek. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení disponuje možností vytvářet šablony žádanek v nákupním košíku pro usnadnění práce při opakovaném zadávání obdobných (periodických) žádanek. |
46 | Při příjmu možnost kontroly ceny oproti: - objednávce - VZP max, úhrada pojišťovny - cena posledního příjmu | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení upozorňuje při nákupu materiálu na cenový rozdíl vzhledem k smluvní ceně (která se přebírá do objednávky), ceně VZP a ceně posledního příjmu. Pořadí priorit lze parametricky nastavit. |
47 | Možnost příjmu od dodavatelů přímo na jednotlivá oddělení - více příjmových skladů, příjmový sklad definován objednávkou. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje definovat více příjmových skladů, které jsou navázany na konkrétní centrální sklady a propojeny s objednávkou z konkrétního centrálního skladu. |
48 | Speciální zdravotní materiál (nebere se na sklad)- přednostní zpracování při příjmu. Označení materiálu jako "speciál" v katalogu; možnost vyfiltrování, který "speciál" je skladem a na jakou žádanku, následně přednostní vydání tohoto materiálu ze skladu. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. V rámci řešení je umožněn speciální zrychlený pohyb přímo od dodavatele na oddělení tzv. příjem do spotřeby, který vytváří větu jak příjmovou, tak výdejovou včetně provazby na objednávku a fakturu. Volné universální atributy katalogu materiálu je možné využít pro specifické označení např. "speciál". Tento atribut lze zobrazit na formulářích (generátorech), filtrovat a třídit podle něj. |
49 | Vytváření karet materiálu z číselníku SUKL a VZP, dá se vyhledávat podle číselníku SUKL a VZP, tyto číselníky se musí aktualizovat. Možnost vytvořit novou kartu materiálu kopií stávající. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje vytváření karet materiálu podle číselníku VZP a vyhledávání dle tohoto číselníku. Číselník VZP může být automaticky aktualizován dle souboru uloženého v definovaném lokálním úložišti. Obdobným způsobem je možné rozšířit katalog materiálu o odkaz na číselník SUKL. Nová karta se dá vytvořit kopírováním existující karty, je ale nutné zachovat princip vazby jedné skladové karty na jednom skladu vůči jedné položce katalogu materiálu. |
50 | Možnost příjmu do spotřeby | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. V rámci řešení je umožněn tzv. příjem do spotřeby, který vytváří automaticky větu jak příjmovou, tak výdejovou včetně provazby na objednávku a fakturu. |
51 | U položek se ZUM kodem možnost dodatečné úpravy ceny (bonus), komunikace s vykazováním zdrav.pojišťovnám. Hlídání bonusů implementovat jako report s možností vytváření dobropisů dodavatelům. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. Systém disponuje nástroji pro definování dodatečných slev a bonusů na základě smluv s dodavateli nebo výrobci včetně možnosti importovat do systému skladové pohyby příjmů jiných IS (např. lékáren). Na základě těchto pohybů systém generuje sestavu, ve které vypočítává za zvolené období dodatečné slevy a bonusy. Interní report je možné na základě zadání modifikovat i jako výstupní sestavu pro dodavatele, která může být podkladem pro vytvoření dobropisu. Systém obsahuje přehled vykazovaných cen materiálů VZP. |
52 | Napojení na IS na operačních sálech. Potvrzením operace se potvrzuje i seznam použitého materiálu, který se odešle do ERP. V ERP je možné tento seznam ručně doplnit a potvrdit výdej na operaci. Tím startují další dva procesy: - Výdej materiálu do spotřeby. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. Po operaci se nahraje použitý materiál jako žádanka na výdej materiálu (manuálně nebo automatizovanými procesy integračních vazeb). Následuje automatické rozdělení žádanky podle skladů, ze kterých bude použitý materiál čerpán, automatická rezervace a vygenerování pohybů výdeje do spotřeby. Nad procesem je možné vytvořit řízený proces (Workflow) podle zadání. |
- Objednávka a převod materiálu z konsignace. | ||||
53 | Přímé závozy materiálu na oddělení - možno vytvářet dodavatelské objednávky na jednotlivá nákladová střediska - na objednávce je uvedeno místo a kontaktní osoba s telefonem, kam se má materiál zavést | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje vytvářet dodavatelské objednávky na jednotlivá nákladová střediska s uvedením místa doručení a kontaktními údaji na osobu a telefon |
54 | Sklad doprava - možnost evidence spotřeby materiálu (náhradní díly, olej, aj.) na konkrétní auto | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Pokud je v rámci pasportů majetku vedena evidence dopravních prostředků, je možné ve skladech definovat materiály, u kterých bude následně při výdeji vynuceno zadání SPZ konkrétního auta. Tímto lze sledovat, kolik materiálu bylo využito na údržbu konkrétního auta. |
55 | Externí výdejky - prodej jiným subjektům - možnost nastavení marže, která bude automaticky dopočítána | Implementace | 1. je standardní funkcionalita aplikace | V systému možné definovat marži k materiálu pro konkrétní druh pohybu (tj. může být definováno více druhů pohybů s různou marží podle toho, komu se materiál prodává). Případně je možné definovat prodejní cenu přímo v katalogu materiálu jako pevnou cenu. Skladové doklady se vytváří se skladovou cenou, podklad fakturace pak s cenou prodejní. |
56 | Sestavy (příjmy, výdeje dle skupin či podskupin materiálů, dle dodavatele, nákladových středisek, ve vztahu k limitům na nákladových střediskách či klinikách, ceny materiálů, úhrady VZP, přehledy dokladů a účtů, stavy skladů, analýza skutečných nákupních cen, analýza spotřeby), možnost vygenerování sestav do excelu s hlavičkou zadání. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje vytvářet výstupní sestavy nebo přehledy příjmů či výdejů dle uvedené specifikace do výstupních formátů PDF, DOC resp XLS/CSV. Vstupní parametry u sestav jsou umístěny do hlaviček sestav. |
57 | Náklady na dodání - poštovné, doprava, montáž - rozpočet ceny do jednotlivých materiálů bez ovlivnění katalogové ceny materiálu. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje zpracovat související náklady formou - rozpouštění dodatečných souvisejících nákladů do příjmaných materiálů bez změny katalogové ceny nebo - evidencí na hlavičce příjmového dokladu (bez rozpouštění). |
58 | Rozpočtové skupiny materiálů dle limitů - lze např. označit materiál, který není do limitu započítáván | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje označení materiálu pomocí skladové skupiny která není přiřazena limitu, Tento materiál není započítáván do čerpání limitu. |
59 | Možnost evidence a hlídání cen materiálů z rámcových smluv uzavřených na dodávku konkrétních materiálů, import položek ze smlouvy s označením smlouvy, cenou, objednacím kódem atd. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje evidenci dodavatelských smluv. V rámci této evidence je k dispozici kontrolní rutina na sledování čerpání smluv. Při vystavování objednávek systém kontroluje: - platnost smlouvy - kontrolu cen položek na objednávce vůči smluvní ceně Na výstupní sestavu objednávky je možné umístit objednací kódy dodavatele. Pomocí standardních importních rutin lze na základě importních šablon importovat položky smluv s označením smlouvy, cenou a objednacím kódem smluvního dodavatele. |
60 | Možnost implementace funkcí řízeného skladu: - Rozhraní na čtečky čárového kódy - Práce s manipulačními jednotkam - Definice procesů pro práci se čtečkami - Skladová evidence na úrovni přihrádekc | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém disponuje rozhraním pro práci se čtečkami čárových kódů, QR kódů a RFID, které pracují jako klávesový vstup. Pro materiál, u kterého je potřebné sledovat výrobní číslo, šarži či exspiraci, se používá standardizovaný čárový kód GS1, pomocí kterého je možné tyto informace rozklíčovat načtením jednoho ČK a uložit do systému (při příjmu) do odpovídajících atributů nebo na základě nich dohledat a definovat konkrétní materiál (při výdeji). Čárový kód je tedy možné využít při příjmu, výdeji nebo při operativním získávání informací o materiálu. Datová struktura systému je připravena pro práci s místy uložení. |
5. Evidence majetku | Požadavek | Splňuje | Popis | |
1 | Systém musí zajistit evidenci informací o majetku včetně souborů majetku, jeho zatřídění a definice způsobu odepisování. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje evidovat informace kvalifikační, operativní, účetní a daňové včetně souborů majetku a způsobu odepisování. |
2 | Dále musí být možné zaznamenávat jednotlivé pohyby majetku s možností účtování dle definovatelných předkontací. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Každá provedená změna na kartě majetku je uložena s uvedením původní a nové hodnoty. Pro účetní pohyby lze nadefinovat uživatelsky předkontaci. |
3 | Možnost evidovat, změnit a sledovat umístění majetku a odpovědné osoby a podporovat inventarizaci majetku. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje změnit umístění a odpovědnou osobu na kartě majetku buď jednotlivě nebo hromadně. Systém podporuje i inventarizaci majetku a to ručně nebo pomocí čárových kódů. |
4 | V systému musí být možné pro drobný majetek vést operativní evidenci a evidovat osobní ochranné | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém podporuje evidenci veškerého majetku - dlouhodobý hmotný a nehmotný, drobný hmotný a nehmotný, operativní evidenci včetně evidence osobního užívání. |
pracovní pomůcky v návaznosti na zaměstnance. | ||||
5 | Možnost evidence různých druhů majetku - dlouhodobý nehmotný majetek, dlouhodobý hmotný majetek. Evidence libovolného počtu karet majetku. Možnost začlenit majetek do společných celků. Možnost členění majetku dle tříd a podtříd. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém podporuje evidenci veškerého majetku - dlouhodobý hmotný a nehmotný, drobný hmotný a nehmotný, operativní evidenci včetně evidence osobního užívání s možností členění majetků dle tříd a podtříd a začleňování majetku do společných celků. Počet karet majetku není omezen. |
6 | Integrovaný modul majetku do účetnictví. Možnost definice účetních předkontací pro jednotlivé pohyby majetku (zařazení, technické zhodnocení, odpis, vyřazení). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje definovat tzv. úččtoskupiny k jednotlivým třídám majetku. Účtoskupina definuje účet pořízení, majetkový, odpisový a oprávkový účet. |
7 | Evidence základních informací o majetku při jeho nabytí jako je: zdroj nákupu, nákupní – pořizovací cena, datum nákupu – pořízení, výrobní číslo / inventární číslo, způsob účetního a daňového odepisování; přiřazení odpovídající předkontace. Možnost přiřadit majetek určitému inventárnímu úseku. Umožnit rozšíření o další doplňující údaje o majetku, dle kterých bude možno majetek i filtrovat. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje evidenci požadovaných základních informací o majetku jako je zdroj nákupu, pořizovací cena, datum pořízení, výrobní číslo, inventární číslo, způsob účetního a daňového odepisování, přiřazení odpovídající předkontace, inventární úsek a další. Za každou položku uvedenou na kartě majetku lze filtrovat. |
8 | Uživatelsky definovatelné metody odpisu majetku pro účetní i daňové účely případně jiné. Možnost uživatelské definice způsobu odepisování. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje metody odepisování nastavit v souladu s příslušnými účetními a daňovými zákony případně souvisejícími předpisy. |
9 | Evidence majetku dle jednotlivých součástí celku - komponentní přístup (definice hlavní karty majetku a jejích komponent). | Implementace | 1. je standardní funkcionalita aplikace | Funkčnost bude předmětem customizace a bude nasazena pokud analýza nasazení prokáže její využitelnost pro zadavatele. |
10 | Možnost zařazení majetku do inventárního úseku, určení odpovědné osoby a nákladového úseku. Vytváření převodů mezi úseky nebo odpovědnými osobami. Možnost evidence historie úseků a odpovědných osob. Možnost provázat inventární úsek na odpovědnou osobu. Možnost zobrazit majetek dle úseků a odpovědných osob. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje k jednotlivým kartám majetku přiřadit inventární úsek, odpovědnou osobu, umístění, nákladové středisko a další doplňující údaje včetně možnosti změny těchto údajů se zaznamenáváním změny inventárního úseku nebo odpovědné osoby. Systém také umožňuje určit odpovědnou osobu inventárního úseku. Pomocí filtrování, dle inventárních úseků, odpovědných osob ale i dalších položek, lze zobrazit odpovídající majetek. |
11 | Možnost provádění hromadných změn | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje provádět hromadné změny položek na kartě majetku. |
12 | Účtování pohybů majetku s atributy (např. nákladové středisko). Možnost kdykoliv spustit odepisování majetku bez nutnosti účtování. Možnost spustit odpisové plány. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Nákladové středisko je součástí účetního záznamu i pohybu. Systém umožňuje kdykoliv spustit funkci pro vytvoření odpisového plánu. Dále umožňuje spočítat předběžné odpisy, o kterých se neúčtuje. |
13 | Třídění majetku dle potřeb organizace. Nutnost variability dle přání organizací. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje třídění majetku dle potřeb organizace. |
14 | Funkce sledování výdajů na modernizace a rekonstrukce, technické zhodnocení majetku. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Je umožněno sledování výdajů na modernizaci, rekonstrukci i technické zhodnocení majetku. |
15 | Způsob sledování přírůstků a úbytků majetku za určité uživatelem definované období. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje sledování přírůstků a úbytků majetku formou výstupních sestav. |
16 | Systém musí zajistit evidenci informací o majetku včetně souborů majetku, jeho zatřídění a definice způsobu odepisování. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje evidovat informace kvalifikační, operativní, účetní a daňové včetně souborů majetku a způsobu odepisování. |
17 | Dále musí být možné zaznamenávat jednotlivé pohyby majetku s možností účtování dle definovatelných předkontací. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Každá provedená změna na kartě majetku je uložena s uvedením původní a nové hodnoty. Pro účetní pohyby lze nadefinovat uživatelsky předkontaci. |
18 | Možnost evidovat, změnit a sledovat umístění majetku a odpovědné osoby a podporovat inventarizaci majetku. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje změnit umístění a odpovědnou osobu na kartě majetku buď jednotlivě nebo hromadně. Systém podporuje i inventarizaci majetku a to ručně nebo pomocí čárových kódů. |
19 | V systému musí být možné pro drobný majetek vést operativní evidenci a evidovat osobní ochranné pracovní pomůcky v návaznosti na zaměstnance. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém podporuje evidenci veškerého majetku - dlouhodobý hmotný a nehmotný, drobný hmotný a nehmotný, operativní evidenci včetně evidence osobního užívání. |
20 | Možnost evidence různých druhů majetku - dlouhodobý nehmotný majetek, dlouhodobý hmotný majetek. Evidence libovolného počtu karet majetku. Možnost začlenit majetek do společných celků. Možnost členění majetku dle tříd a podtříd. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém podporuje evidenci veškerého majetku - dlouhodobý hmotný a nehmotný, drobný hmotný a nehmotný, operativní evidenci včetně evidence osobního užívání. Počet karet majetku není omezen. |
21 | Integrovaný modul majetku do účetnictví. Možnost definice účetních předkontací pro jednotlivé pohyby majetku (zařazení, technické zhodnocení, odpis, vyřazení). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje definovat tzv. úččtoskupiny k jednotlivým třídám majetku. Účtoskupina definuje účet pořízení, majetkový, odpisový a oprávkový účet. |
22 | Evidence základních informací o majetku při jeho nabytí jako je: zdroj nákupu, nákupní – pořizovací cena, datum nákupu – pořízení, výrobní číslo / inventární číslo, způsob účetního a daňového odepisování; přiřazení odpovídající předkontace. Možnost přiřadit majetek určitému inventárnímu úseku. Umožnit rozšíření o další doplňující údaje o majetku, dle kterých bude možno majetek i filtrovat. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje evidenci požadovaných základních informací o majetku jako je zdroj nákupu, pořizovací cena, datum pořízení, výrobní číslo, inventární číslo, způsob účetního a daňového odepisování, přiřazení odpovídající předkontace, inventární úsek a další. Za každou položku uvedenou na kartě majetku lze filtrovat. |
23 | Uživatelsky definovatelné metody odpisu majetku pro účetní i daňové účely případně jiné. Možnost uživatelské definice způsobu odepisování. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Metody odepisování lze nastavit v souladu s příslušnými účetními a daňovými zákony případně souvisejícími předpisy. |
6. Doprava | Požadavek | Splňuje | Popis | |
1 | Systém musí podporovat vedení evidence vozidel a řidičů, přiřadit k nim další informace a zaznamenávat údržbu vozidel. | Implementace | 1. je standardní funkcionalita aplikace | Komplexní správa evidence, sledování a údržby vozidel. |
2 | Možnost evidence soukromých a služebních jízd v knize jízd vozidla se zaznamenáním řidiče a možností zadání čerpání PHM a dalších nákladů na provoz vozidla. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje evidenci soukromých a služebních jízd v knize jízd vozidla se zaznamenáním řidiče a možností zadání čerpání PHM a dalších nákladů na provoz vozidla. |
3 | Zajištění zpracování tuzemských i zahraničních cestovních příkazů, včetně schvalovacího workflow, výpočtu případně zadání dalších nákladů, jejich zaúčtování s využitím předkontací a proplacení. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje evidenci soukromých a služebních jízd v knize jízd vozidla se zaznamenáním řidiče a možností zadání čerpání PHM a dalších nákladů na provoz vozidla. |
4 | Možnost definovat pro jednotlivá vozidla kartu s uvedením specifikace vozidla včetně údajů pro sestavení přiznání k silniční dani. Vozidla lze sdružovat do skupin, případně kartu vozidla propojit s evidencí majetku. | Implementace | 1. je standardní funkcionalita aplikace | Pro jednotlivá vozidla v evidenci je možné kromě technických údajů (registrační značka, typ, objem, spotřeba, náprav, rychlosti…) sledovat také související provozní náklady spojené se servisem a údržbou. Evidenci silničních vozidel je možné napojit na evidenci majetku a zachovat tak princip QI, kdy jeden záznam je v systému evidován pouze jednou a jednotlivé moduly pouze doplňují potřebné atributy pro vlastní funkcionalitu. Evidence vozidel je také napojena na zpracování silniční daně v modulu Finance. |
5 | Možnost evidovat řidiče a informace o jejich kvalifikaci včetně platnosti. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje evidovat řidiče a informace o jejich kvalifikaci včetně platnosti. Pro tuto evidenci se využívá oblast personalistiky - evidence charakteristik a jejich časové platnosti. Tuto evidenci lze dále rozšířit i o evidenci konkrétních školení a kurzů, které souvisejí s platností charakteristiky řidiče. |
6 | Možnost sledovat údržbu vozidel s uvedením data provedení případně platnosti (např. pro STK), evidovat platební karty, pojištění, opravy a další informace o vozidle. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje evidovat řidiče a informace o jejich kvalifikaci včetně platnosti. Pro tuto evidenci se využívá oblast personalistiky - evidence charakteristik a jejich časové platnosti. Tuto evidenci lze dále rozšířit i o evidenci konkrétních školení a kurzů, které souvisejí s platností charakteristiky řidiče. |
7 | Evidence a vyhodnocení požadavků na dopravu, zobrazení kapacitního vytížení vozidel a řidičů, evidence příkazů na dopravu a zaznamenání | Implementace | 1. je standardní funkcionalita aplikace | Požadavky na dopravu jsou realizovány objednávkami, zobrazení kapacitního vytížení vozidel lze sledovat v rámci plánovacího kalendáře, evidence příkazů na dopravu je řešena částí aplikace s názvem cestovní příkazy a skutečnost je sledována v rámci záznamů o provozu. |
skutečně provedené dopravy. | ||||
8 | Vedení knihy jízd pro evidenci soukromých a služebních jízd konkrétního vozidla za dané období a řidiče. V návaznosti na knihu jízd možnost evidovat odběr pohonných hmot (jejich množství a cenu) a ostatní náklady spojené s provozem vozidla. Možnost využití platebních karet (zejména CCS). | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje vedení knihy jízd pro evidenci soukromých a služebních jízd konkrétního vozidla za dané období a řidiče. V návaznosti na knihu jízd systém umožňuje evidovat odběr pohonných hmot (jejich množství a cenu) a ostatní náklady spojené s provozem vozidla. Systém umožňuje využití platebních karet CCS. |
9 | Možnost pořizování, zpracování a tisku cestovních příkazů pro evidenci plánované a uskutečněné pracovní tuzemské nebo zahraniční cesty zaměstnance. | Imxxxxxxxxxx | 0. xe standardní funkcionalita aplikace | IS QI zajišťuje evidenci služebních cest (tuzemských a zahraničních) s možností plánování účasti osob na služební cestě a zadání rámce služební cesty (čas od, do, předpokládaný dopravní prostředek). Dále zajišťuje evidenci účastníků služební cesty s vazbou na pracovně právní vztah u zaměstnanců (následně případně i s vazbou na aktivitu účastníků) a také evidenci spolucestujících osob. Umožňuje tvořit cestovní příkazy pro všechny zúčastněné osoby včetně přiznání záloh. IS QI zajišťuje tvorbu cestovních výkazů ke služební cestě s možností načtení rozpisu průběhu z cestovního příkazu. Jsou sledovány všechny související náklady i stravné. Cestovní výkaz je uzavírán vyúčtováním a schválením, kdy může dojít k ručním korekcím. Na základě vyúčtování vzniká ostatní závazek. |
10 | Možnost uhradit zaměstnanci cestovné bankou nebo pokladnou. | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje uhradit vytvořený ostatní závazek zaměstnanci libovolnou metodou, obvykle bankou - příkazem k úhradě nebo hotovostně přes pokladnu. |
11 | Workflow objednání, schválení přepravy až po fakturaci | Implementace | 1. je standardní funkcionalita aplikace | Obdoba standardního procesu tvorby a procesu workflow. |
12 | ADR přeprava (infekční materiály) - odesílání hlášení do ISPOP | Implementace | 1. je standardní funkcionalita aplikace | V rámci modulu Prodej a nákup / Odpady Uživatel má uživatel k dispozici formuláře "Tvorba hlášení o přepravě nebezpečného odpadu" a "Seznam hlášení o přepravě nebezpečného odpadu", ze kterých lze spouštět jednotlivé webové služby, které komunikují s modulem SEPNO |
13 | Provázanost na sledovací systém - kilometrovník.a dispečerský systém (zpracovává žádanku a vrací údaje k vyúčtování) | Implementace | 1. je standardní funkcionalita aplikace | Komplexní správa evidence, sledování a údržby vozidel. |
8. WorkFlow | Požadavek | Splňuje | Popis | |
1 | Systém musí umožnit definovat WorkFlow v přehledné formě, uživatelsky nastavitelné podle procesů organizace. | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Jednotlivé procesy mohou být definovány ve WorkFlow definici v přehledné grafické formě a tímto jsou implementačně nastavitelné, tzn. že je uchazeč může nastavit podle zvyklostí organizace bez programových úprav. Definiční část WorkFlow obsahuje přehledné grafické rozhraní pro nastavení jednotlivých kroků a popisu požadované funkčnosti. |
2 | Je požadována jednotná parametrizace schvalovacích procesů. | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Workflow umožňuje nastavit jednotné schvalovací procesy pro různé druhy žádanek. |
3 | Možnost nastavení oprávnění ke schvalování přes skupiny uživatelů. | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Xxxxxxx pracuje a řídí schvalovací proces na základě přidělených uživatelských rolí, které jsou přiděleny uživatelům a tímto jsou vymezeny skupiny uživatelů. |
4 | Možnost definice zástupu za uživatele bez nutnosti redefinovat schvalovací proces | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Jakékoliv role včetně kompetencí je možné přidělit dočasně zastupujícím uživatelům. Workflow umožňuje monitoring procesu s dohledatelností, kdo akci provedl. |
5 | Možnost nastavit schvalovací proces jako paralelní, sériový nebo kombinovaný. | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Workflow ze své podstaty umožňuje sériové procesy, nicméně umožňuje i podporu paralelních procesů avšak vždy s jednotnou indikací stavu dokladu, např. ve schvalování. Sériový a paralelní průchod je možné kombinovat. |
6 | Schvalovací proces může být podmíněný libovolným polem schvalovaného záznamu (např. u objednávky: cenou, nákladovým střediskem) případně složitější podmínkou (např. kontrola ceny objednávky proti rozpočtu). | Vlastnost | 2. je předmětem úpravy (dopracování) aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje podmínit schvalovací proces dle libovolného atributu záznamu a řídit tak např. výběr schvalovatele (např. různé role mohou schvalovat různé výše cen – vedoucí do 10.000, náměstek do 100.000, ředitel nad 100.000) či druhu objednávky (různé role mohou schvalovat různé druhy objednávek – IT objednávky náměstek IT, MTZ objednávky ekonomický náměstek, ZT objednávky technický náměstek, atd.) případně řídit proces dle složitějších podmínek. |
7 | Ke schvalovanému záznamu možnost připojení odkazů na související dokumenty (HTML, PDF, XLS). | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. K záznamům lze evidovat související dokumentaci v uvedených formátech včetně ukládání dokumentů do centrální databáze a umožnit k nim řízený přístup. Pro snazší orientaci a vyhledávání lze dokumenty kategorizovat podle obsahu s uvedením doplňujících informací o dokumentu. K dokumentům lze přistupovat jak z konkrétního záznamu, tak z centrální evidence dokumentů. Dalším způsobem je připojení dokumentace prostřednictvím URL odkazů na sdílená úložiště. |
8 | Možnost upozorňování e- mailem. | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Upozorňování (notifikace) na události hraje při řízení procesů významnou roli. Typickými událostmi jsou např. potřeba schválení vystaveného dokladu, žádosti nebo objednávky, upozornění na nový komentář, překročení rozpočtu, opoždění provedení činnosti atd. Řešení podporuje několik způsobů upozorňování např. odesláním notifikačních e-mailových zpráv či odesíláním sms zpráv určeným adresátům. Notifikace obsahují odkaz na notifikovaný objekt, který lze bezprostředně načíst. Řešení podporuje tvorbu e- mailových šablon. Obsah e-mailů je možné definovat prostým textem, nebo využít HTML formátování. V rámci e-mailu je možné dynamicky doplňovat obsah e- mailu informacemi z atributů entit (např. požadavků). Definiční část notifikací umožňuje dále definovat rozsah jejích adresátů. Je možné zadat přímou e- mailovou adresu, dotahovat adresu z atributů záznamů i přes vazby z jiných záznamů. Jako adresáty je možné definovat členy pracovních skupin, rolí, konkrétní účastníky Workflow nebo i např. všechny uživatele, kteří mají kompetenci záznam vidět. |
9 | Schvalování záznamů v prostředí ERP systému. | Vlastnost | 1. je standardní funkcionalita aplikace | Nástroje pro definování procesů Workflow umožňují schvalování implementačně definovaných záznamů |
10 | Možnost víceúrovňového schvalování | Vlastnost | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Celý žádankový proces je řízen pomocí WorkFlow nastaveného v rámci implementace dle potřeb organizace. Součástí workflow může být víceúrovňové schvalování před samotným odesláním k řešení. |
11 | Skener a OCR sw pro zpracování vstupních dokumentů | Vlastnost | 2. je předmětem úpravy (dopracování) aplikace | Funkčnost OCR bude předmětem customizace a bude nasazena pokud analýza nasazení prokáže její využitelnost pro zadavatele. |
9. Správa a údržba budov | Požadavek | Splňuje | Popis | |
1 | Řešení poskytne nástroje pro popis prostorové evidence nemovitého majetku zadavatele, které zajistí správu hierarchicky organizované struktury, založené na členění do areálů, budov, podlaží a místností. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení obsahuje nástroje pro vedení prostorové evidence nemovitého majetku zadavatele. Prostorové objekty je možné evidovat do hierarchicky organizované struktury s využitím navigačního stromu (Areál- >Budova->Podlaží->Místnost). Hierarchie lze přizpůsobovat specifickému prostorovému členění každé nemovitosti. |
2 | Řešení umožní podporu pro sjednocení a automatizované přiřazení jednoznačné identifikace (kódování) pro každou lokalitu, budovu, podlaží a místnost podle zvolené metodiky. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Prostorové objekty lze kódovat manuálně s kontrolou na duplicitu zadaných kódů nebo lze využít funkcionalitu automatického generování kódů podle definovaných pravidel. Každý typ prostorového objektu (budova, podlaží, místnost) může mít vlastní strukturu kódování. |
3 | Řešení umožní evidenci zaměstnanců v závislosti na vztahu k prostorovým objektům (správců, uživatelů). Vazba na centrální číselník zaměstnanců. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje vést evidenci zaměstnanců včetně umístění jeho pracoviště a definice profese. Následně je možné z prostorového objektu sledovat seznam pracovníků přiřazených ke konkrétní ploše. |
4 | Řešení umožní evidenci elektronické dokumentace včetně fotografií souvisejících s nemovitostmi. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Ke každé nemovitosti v katalogu lze evidovat související dokumentaci včetně ukládání dokumentů do centrální databáze a umožnit k nim řízený přístup. Pro snazší orientaci a vyhledávání lze dokumenty kategorizovat podle obsahu s uvedením doplňujících informací o dokumentu. K dokumentům lze přistupovat jak z katalogu nemovitostí, tak z centrální evidence dokumentů. |
5 | Řešení umožní vedení provozní knihy k prostorovým objektům se zápisy o údržbě, kontrolách a opravách. Možnost automatického i ručního zápisu do provozní knihy. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Ke každému prostorovému objektu je umožněno vést jeho provozní knihu včetně možnosti automatických (při provedení opakované činnosti, při realizaci zakázky, atd.) či ručních zápisů. |
6 | Řešení umožní centrálně definovat a spravovat potřebné pasportní údaje (včetně zadání měrných jednotek, datového formátu hodnoty, příp. výčtu přípustných hodnot) k prostorovým objektům s možností rozšiřování a redukce množství těchto údajů na implementační bázi, tj. bez nutnosti programových úprav. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Pro každý sledovaný pasportní údaj lze volně nadefinovat potřebné charakteristiky. Při zadávání skutečných hodnot je kontrolováno, zda jsou požadované charakteristiky dodrženy. Tím jsou výrazně omezeny možnosti chybného zadání hodnoty pasportního údaje uživatelem. Množinu lze v průběhu nasazení systému řízeným způsobem rozšiřovat. Nově definované parametry se flexibilně připojí na prostorové objekty - není třeba provádět programové úpravy. |
7 | Řešení umožní definovat disjunktní množiny pasportních údajů v závislosti na typech prostorových objektů (např. jiná množina pasportních údajů k | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Pro každý typ prostorového objektu lze volitelně nadefinovat množinu pasportních údajů (jinou množinu pro budovu, jinou množinu pro podlaží, atd.). |
budově, jiná množina k místnosti). | ||||
8 | Řešení bude podporovat provádění on-line kumulace hodnot vybraných parametrů z koncových uzlů na vrcholové v souladu s prostorovou hierarchií případně provádění rozpadu hodnot vybraných parametrů z vrcholových uzlů na koncové podle uspořádání prostorové hierarchie a koeficientů rozpadu. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. U vybraných pasportních údajů lze nadefinovat provádění kumulace jejich hodnot z koncových uzlů směrem nahoru při respektování prostorové hierarchie pomocí nástroje Funkce. Na vrcholových uzlech jsou potom vygenerovány tytéž pasportní údaje obsahující součtové hodnoty z údajů na nižších úrovních. Systém umožňuje uživateli snadné rozlišení původu hodnoty (zdrojová, kumulovaná). |
9 | Řešení bude podporovat evidenci stavebně- technických prvků (dveře, okna, fasády, klempířské prvky, dlažby,…) prostorových objektů včetně jejich historie | Imxxxxxxxxxx | 0. xe standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Využitím evidence parametrů k prostorovým objektům, je možné vést evidenci stavebně -technických prvků jako jsou např. dveře, okna, fasády, klempířské prvky, dlažby, atd. včetně uvedení hodnoty v aktuálním období a zaznamenání historie hodnot daných parametrů. |
10 | Řešení umožní kategorizaci stavebně-technických prvků na základě centrálně spravovaného registru typů stavebně-konstrukčních prvků, možnost rozlišovat skupinové a individuální stavební konstrukční prvky a sledovat životnost prvků a datum obnovy. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje nastavení hierarchické typizace stavebně- technických prvků. Řešení obsahuje přehledový formulář Typy konstrukčních prvků, z kterého je možné zobrazovat v hierarchické struktuře jednotlivé typy včetně konkrétních prvků k tomuto typu přidělených. Systém umožňuje rozlišování skupinových a individuálních stavebních konstrukčních prvků na základě typizace. U konstrukčních prvků je možné sledovat jejich délku životnosti včetně termínů obnovy a prodloužení cyklu obnovy. |
11 | Řešení umožní sledování záruční doby stavebně technických prvků s podporou grafické vizualizace zařízení v záruční době pro rozhodování o jeho servisu a opravách. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje na kartě stavebně-technického prvku vést evidenci záruční doby. Údaj záruky je možné sledovat jak z pohledu datumové značky, tak i barevné signalizace při blížícím se konci záruky a při ukončené záruční době. |
12 | Řešení umožní evidenci a kategorizaci technických zařízení založenou na základě centrálně spravovaného registru typů technických zařízení. Možnost sledování životnosti zařízení, příp. dalších údajů jako je výrobce, dodavatel, servisní organizace. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje nastavení hierarchické typizace technických zařízení. Řešení obsahuje přehledový formulář Typy technologických zařízení, ze kterého je možné zobrazovat v hierarchické struktuře jednotlivé typy včetně konkrétních zařízení k tomuto typu přidělených. U zařízení je umožněno sledovat řadu údajů: datum použitelnosti, zařazení do majetku, vyřazení z majetku, datum instalace, atd. Na kartě zařízení je možné uvést výrobce, dodavatele a servisní organizaci. |
13 | Řešení umožní tisk štítků čárových kódů s evidenčními údaji o technickém zařízení. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje tisk čárových kódů technických zařízení s evidenčními údaji o zařízení. Při tisku čárového kódu je možné označit zařízení časovou značkou s informací, že čárový kód pro zařízení byl již jednou vytištěn. Součástí nabízeného řešení je i tisk čárového kódu místnosti. Tisk štítků je umožněn z konkrétního zařízení, či hromadně z přehledu všech zařízení. |
14 | Řešení umožní automatické sledování termínů periodických činností, barevnou signalizaci blížících se či prošlých termínů a odesílání e- mailových avíz správcům technologických zařízení | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje automatické sledování a to nastavením barevné vizualizace blížících se či prošlých (neprovedených) termínů (zelená – OK, žlutá – blíží se termín projití, červená – prošlá) periodických činností, odesílání e-mailových avíz správcům objektů či správcům druhů opakovaných činností, jak na procházející, tak prošlé periodické činnosti. |
15 | Řešení umožní dokladovat provedení periodických činností a bude poskytovat centrální úložiště pro revizní zprávy a dokumentaci o výsledcích realizace periodických činností u technických zařízení | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje připojit elektronické verze výstupních dokumentů pořízených při realizaci opakovaných činností k opakované činnosti resp. k technickému zařízení. Všechny takto elektronicky připojené dokumenty je možné sledovat a zobrazovat z odpovídajících přehledových formulářů včetně možnosti filtrace např. dle připojeného zařízení, druhu dokumentu, data založení, atd. |
16 | Řešení umožní evidenci a správu výkresové dokumentace nemovitostí | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje evidenci a správu výkresové dokumentace nemovitostí. |
17 | Součástí řešení bude integrovaný prohlížeč pro zobrazování digitalizované stavební a výkresové dokumentace s jednoznačnou identifikací objektů (zařízení, pracovníků) na plochách včetně jejich prostorových souvislostí. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení obsahuje nástroj pro grafickou prezentaci dat, které umožňuje prohlížení objektů pasportizace (ZP, zařízení, pracovník, atd.) na zdigitalizovaných plochách |
18 | Řešení bude využívat barevné palety obarvování ploch pro zobrazení/vyhledávání ve výkresové dokumentaci dle uživatelsky definovaných výběrových kritérií (organizační úseky, typ a účel plochy,…). | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje v Grafické prezentaci dat použít obarvení vybraného rozsahu ploch. Obarvení je na základě výběrových kritérií např. organizační úseky, typy a účely ploch, atd. kdy je možné každé hodnotě výběrového kritéria přiřadit barvu z palety barev. |
19 | Řešení umožní tisk výkresové dokumentace vybraným uživatelům přímo v nativním prostředí aplikace v režimu výřez nebo celý výkres. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Uživatelům s oprávněním tisku v grafické prezentaci dat je umožněn tisk výkresové dokumentace přímo nad vybranými daty (celý výkres, vybraný úsek). |
20 | Nástroj pro úpravu grafických dat bude obsahovat prostředky pro vytváření a aktualizaci grafických prvků pro zachycení reálných prostorových a technických objektů, a to zejména: • Bod, úsečka, kružnice, kruhový oblouk • Lomená čára, mnohoúhelník, pravoúhelník • Text, symbol, ikona • Hladká křivka | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje pořízení, správu a manipulaci s vektorovými objekty, práci s mapami a plány v různých měřítcích. Pružné filtrování grafických objektů a široké možnosti způsobu jejich výběru. Vytváření a editaci vektorových grafických prvků pro zakreslení objektů reálného světa. |
21 | Řešení umožní přesnou pasportizační specifikaci prvků požární bezpečnosti a možnost zobrazení jejich umístění na výkresech stavebních objektů | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje zakládání karet pro prvky požární bezpečnosti včetně uvedení jejich pasportních údajů jako např. umístění v prostorových objektech, hierarchické typizace, přiřazení k NS, Inventárnímu úseku, organizačnímu útvaru, atd. Pokud je prvek bezpečnosti přiřazen ke konkrétnímu prostorovému objektu, který je zdigitalizován je umožněno jeho zobrazení na výkresu. |
22 | Řešení umožní evidovat požární úseky, smyčky EPS a bezpečnostní postupy | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje evidenci jak požárních úseků, smyček EPS, tak bezpečnostních postupů. Součástí evidence bezpečnostního postupu je i definice potřebných zdrojů (materiál, externí služba, práce, technické zdroje, úkoly) včetně odhadu náročnosti v hodinách a Kč. |
23 | Řešení umožní evidenci provedených revizí a kontrol prvků bezpečnosti včetně systému sledování lhůt revizí a kontrol. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Ke kartě bezpečnostního prvku je možné zaevidovat i jeho pravidelné revize a kontroly včetně lhůt, které k prvku je potřeba sledovat. Systém obsahuje nástroje pro sledování a upozorňování na tyto lhůty (barevné vizualizace, emailové upozornění, atd.). Při potvrzení |
provedení revize či kontroly dochází k zápisu výsledku do provozní knihy bezpečnostního prvku včetně možnosti připojení dokumentace v elektronické podobě (protokol, revizní zpráva, plán rozmístění prvku). | ||||
24 | Řešení umožní definovat plány opakovaných kontrol provozuschopnosti požárně-bezpečnostních zařízení a jejich revizí | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Řešení umožňuje pomocí definic pravidelných opakovaných činností k bezpečnostním prvkům sestavit plán kontrol požárně-bezpečnostních zařízení. Systém umožňuje tisk či jednoduchý export tohoto plánu. |
25 | Řešení umožní automatické generování souboru (schématu) obnovy stavebně-konstrukčních prvků a jejich množství vycházející z celkové pořizovací ceny objektu nebo na základě zadání základních technicko- provozních údajů | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém na základě parametrů (cena objektu, rok pořízení, sklon střechy, výška, šířka, délka objektu, atd.) stavby a konstrukčních prvků připadajících na tento typ stavby umožňuje automaticky vytvořit rozpis obnovy prvků včetně nákladů vynaložených na obnovu. |
26 | Žádanky na opravu a jejich schvalování ve workflow. Možnost ze žádanky generovat objednávku na externí služby a skladovou výdejku. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Systém umožňuje vytvářet žádanky na opravy včetně jejich schvalování prostřednictvím workflow. Ze žádanky je možné generovat objednávku na externí služby, nebo skladovou výdejku. |
10. Systém na řízení projektů | Požadavek | Splňuje | Popis | |
1 | Systém musí umožnit vytvářet strukturu projektu na úrovni projekt, etapa, úkol, pod-úkol bez omezení množství | Implementace | 1. je standardní funkcionalita aplikace | nástroj mind map - vizuální mapa celého projektu umožní vytvářet libovolně rozsáhlou strukturu projektu |
2 | Identifikátorem projektu by měl být nejen název, ale také kód projektu. Ke každému projektu umožnit přiřadit odpovědnou osobu za projekt a projektový tým | Implementace | 1. je standardní funkcionalita aplikace | Identifikátorem projektu může být jak název tak kód projektu. Nastavení projektu umožní přiřadit projektu odpovědnou osobu i projektový tým. |
3 | Možnost nastavit termín dokončení projektu včetně nastavení úkolů od-do, termíny milníků odvozovat automaticky od termínů zadaných úkolů | Implementace | 1. je standardní funkcionalita aplikace | Termín dokončení projektu je možné nastavit v masterplánu projektu. Systém umožňuje nastavit termíny úkolů od do a odvozovat termíny milníků |
4 | Umožnit projekt vizuálně plánovat ve více propojených pohledech. Propojených znamená, že veškeré změny provedené v jednom pohledu se ihned | Implementace | 1. je standardní funkcionalita aplikace | Synchronizované zobrazení u vizuální mapa projektu, časová osa projektu, dlouhodový plán projektu |
projeví i ve druhém pohledu | ||||
5 | Vizuální plánování rozsahu projektu. Projekt musí být možné vizuálně rozdělit na jednotlivé etapy a do těchto etap následně vkládat jednotlivé úkoly | Implementace | 1. je standardní funkcionalita aplikace | Umožňuje vizuální mapa projektu, časová osa projektu, dlouhodový plán projektu |
6 | Vizuální zobrazení musí být možné přibližovat a vzdalovat, aby mohl uživatel přejít od detailu po celkový přehled nad projektem | Implementace | 1. je standardní funkcionalita aplikace | Umožněno funkcí zoom |
7 | Jednotlivé úkoly(podúkoly) musí být na první pohled jednoznačně odlišené názvem, odpovědnou osobou a stavem | Implementace | 1. je standardní funkcionalita aplikace | Podúkoly lze přiřadit nezávisle odpovědné osobě, měnit stav, i popis |
8 | V rámci vizuálního zobrazení projektu musí systém umožnit vytvářet návaznosti jednotlivých úkolů v rámci jednotlivých etap. Tyto návaznosti bude možné vytvářet i mazat a automaticky se budou přenášet do zobrazení projektu v čase. Vytváření těchto vazeb musí probíhat jednoduše a intuitivně pomocí propojení jednotlivých úkolů tažením myši. Vazby vytvářené zadáváním hodnot to formulářů nebudou akceptovány z uživatelského hlediska. | Implementace | 1. je standardní funkcionalita aplikace | Časová osa umožňuje vytvářet vizuálně návaznosti úkolů. |
9 | Ve vizuálním zobrazení musí být na první pohled patrné stavy úkolů a to barevně odlišené. Stejně tak musí být úkoly odlišeny i ve zobrazení projektu v čase a také v přehledu úkolů jednotlivých uživatelů. | Implementace | 1. je standardní funkcionalita aplikace | Barvy je možné odlišit ve vizuální mapa projektu, časová osa projektu, task list |
10 | Vizuální plánování musí umožňovat interaktivní práci s projektem. Tzn. Přesouvání jednotlivých etap mezi sebou, přesouvání úkolů mezi etapami, libovolné řazení úkolů v rámci etap, vytváření a mazání vazeb mezi úkoly, to vše jednoduchým přetažením myší tzv. drag and drop | Implementace | 1. je standardní funkcionalita aplikace | vizuální mapa projektu, časová osa projektu - operace s objekty pomocí myši |
11 | Vedle zobrazení projektu na obrazovce musí systém umožňovat zobrazení projektu v časové ose včetně etap a souvisejících úkolů. Na této časové ose musí také úkoly odlišeny barevně dle stavu. | Implementace | 1. je standardní funkcionalita aplikace | časová osa projektu - operace s objekty pomocí myši |
12 | Zobrazení etapy na časové ose musí obsahovat také ukazatel procentního plnění úkolů v rámci dané etapy. | Implementace | 1. je standardní funkcionalita aplikace | ukazatel plnění etapy je dostupný na kartě s detailem etapy projektu |
13 | Všechny úkoly, které nebudou k aktuálnímu datu označeny jako dokončené musí mít indikovánu značku, že jsou po termínu | Implementace | 1. je standardní funkcionalita aplikace | Nad stavem úkolu je možné vytvořit filtr |
14 | Přesouvání jednotlivých úkolů v čase musí probíhat jednoduchým přetažením myši "drag and drop" | Implementace | 1. je standardní funkcionalita aplikace | časová osa projektu - operace s objekty pomocí myši |
15 | Návaznosti úkolů vytvořené ve vizuálním zobrazení projektu musí být zobrazeny také na časové ose, aby bylo jednoznačně patrné pořadí ve kterém je nutné jednotlivé úkoly plnit. | Implementace | 1. je standardní funkcionalita aplikace | časová osa projektu - operace s objekty pomocí myši |
16 | Jednotlivé etapy a jejich úkoly se mohou řadit pod sebe, pokud se však termíny jednotlivých úkolů v etapách nepřekrývají zařadí se etapy za sebe na časovou osu. | Implementace | 1. je standardní funkcionalita aplikace | časová osa projektu - perspektiva zobrazení v čase |
17 | Systém umožní vkládání příloh a přístup ke všem přílohám projektu | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu a práce s přílohami |
18 | Úkoly a pod-úkoly budou zobrazeny společně na kartě/ploše | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu |
19 | Tato karta musí být přístupná ze všech zobrazení projektu klikem na vybraný úkol | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu je přístupná ze všech zobrazní projektu |
20 | Úkol bude možné nastavovat s časovou náročností od-do. | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu - parametry úkolu |
21 | Časovou náročnost úkolu od do bude možné měnit natažením úkolu na časové ose, současně systém umožní úkol na časové ose také přesunou v čase, to vše systémem "drag and drop" | Implementace | 1. je standardní funkcionalita aplikace | časová osa projektu - operace s objekty pomocí myši |
22 | Možnost přiřazovat k úkolům jednu odpovědnou osobu a také spolupracující uživatele. Zadat název úkolu, popis, označit úkol jako oblíbený a možnost přiřazovat k úkolu přílohy. Označením zařadit úkol do zvláštního seznamu oblíbených. | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu - parametry úkolu |
23 | Možnost vytvářet pod- úkoly k jednotlivým úkolům na projektech. Tyto podúkoly zobrazit na detailu úkolu. Možnost přiřazovat odpovědnou osobu k pod-úkolu. Odpovědnou osobu k pod- úkolu vybírat ze seznamu spolupracujících uživatelů na úkolu. | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu - parametry úkolu |
24 | Na detailu úkolu mít k dispozici seznam pod- úkolů. Nad tímto seznamen zobrazit procentuelně vyjádřené množství splněných pod-úkolů. Plnění počítat poměrovně z | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu - parametry úkolu |
celkového počtu pod- úkolů. | ||||
25 | Možnost přiřazovat jednotlivé stavy úkolů. K úkolu mít možnost přiřadit 4 stavy. | Implementace | 1. je standardní funkcionalita aplikace | vlastní atributy k úkolu - definovatelné pro každý projekt individuálně |
26 | odstraněno | Implementace | ||
27 | Možnost komunikace k úkolu formou komentářů. Možnost reagovat na tyto komentáře. Umožnit ke komentářům přikládat také přílohy. | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu - diskuze k úkolu |
28 | Každý uživatel musí mít svůj přehled úkolů dostupný na jednom místě, aby okamžitě viděl svoje úkoly napříč všemy projekty. Přehled úkolů pro jednotlivé uživatele zobrazit na časové ose s možností změny termínu jednotlivých úkolů pomocí funkce drag and drop | Implementace | 1. je standardní funkcionalita aplikace | část aplikace - moje úkoly |
29 | Na časové ose uživatele indikovat aktuální den, Odlišit zobrazení víkendových dní | Implementace | 1. je standardní funkcionalita aplikace | část aplikace - moje úkoly |
30 | Umožnit v řádkovém seznamu tzv."to-do listu" filtrovat úkoly, dle parametrů oblíbené/po termínu. Zobrazit také úkoly s podúkolem | Implementace | 1. je standardní funkcionalita aplikace | task list - vlastní atributy k úkolu |
31 | Mimo úkoly na projektu umožnit vytvářet soukromé úkoly obsahující název, popis, datum, čas, trvání, připomenutí a možnost změny stavu dokončené/nedokončené | Implementace | 1. je standardní funkcionalita aplikace | Soukromé úkoly je možné vytvářet v rámci tzv. private project |
32 | Možnost vytvářet v systému také schůzky. Schůzka bude obsahovat parametry název, popis, datum konání, čas konání, trvání a připomenutí. Mimo to umožní také přizvat ostatní uživatele aplikace ke schůzce, ale také jiné | Implementace | 1. je standardní funkcionalita aplikace | Systém umožňuje vytvořit samostatný projekt pro organizaci schůzek a nastavit libovolné parametry k jednotlivýcm schůzkám |
účastníky na základě emailové adresy. Účastníkům mimo systém zašle systém automaticky email s informací o plánované schůzce a s obsahem všech výše uvedených parametrů | ||||
33 | Systém musí obsahovat přehled a filtr jednotlivých pracovníků a jejich úkolů v čase | Implementace | 1. je standardní funkcionalita aplikace | přehled uživatelů - přehled zdrojů |
34 | Zobrazení vytížení uživatelů musí obsahovat indikaci dnešního dne | Implementace | 1. je standardní funkcionalita aplikace | přehled uživatelů - přehled zdrojů |
35 | Jednotlivé úkoly musí být možné mezi sebou funkcí drag and drop přeplánovat nejen v čase, ale také je přesunout mezi jednotlivými členy týmu, čímž dojde ke změně odpovědné osoby | Implementace | 1. je standardní funkcionalita aplikace | časová osa projektu - operace s objekty pomocí myši |
36 | Možnost přiřazovat role k jednotlivým projektům. Projektový manažer má možnost editovat vše v daném projektu, členové projektového týmu mají možnost editovat pouze svoje úkoly nebo úkoly, ke kterým jsou přiřazeni jako spolupracující. | Implementace | 1. je standardní funkcionalita aplikace | nastavení projektu - rozdělení na privátní a veřejné projekty |
37 | Nejvyšší role admin systému má možnost nahlížet a editovat vše v systému. | Implementace | 1. je standardní funkcionalita aplikace | uživatelské role v systému |
38 | Systém bude ukládat všechny změny a v případě potřeby bude možné dohledat k jakým změnám došlo, kdy a kdo je v systému provedl. | Implementace | 1. je standardní funkcionalita aplikace | karta s detailem úkolu - log aktivit úkolu |
39 | Uživatelé budou mít přehled o úkolech na projektu ke kterému jsou přiřazeni, aby znali návaznosti jednotlivých úkolů, nebudou mít však možnost nahlížet do detailu těchto úkolů, ke | Implementace | 1. je standardní funkcionalita aplikace | vizuální mapa projektu, časová osa projektu, task list |
kterým nebudou přímo přiřazeni | ||||
40 | Možnost vytvářet šablony projektů | Implementace | 1. je standardní funkcionalita aplikace | nastavení projektu - kopírování projektu jako šablony včetně dat projektu |
41 | Systém bude obsahovat notifikace a jejich filtrování ,se kterými bude možné pracovat a označovat je jak přečtené/nepřečtené, každá notifikace bude vypovídat o změně která proběhla na projektech a úkolech ke kterým je daný uživatel přiřazen. Notifikace umožní přímý proklik na konkrétní změnu ke které na daném úkolu/projektu došlo, současně bude v přehledu notifikací krátký popis dané změny. | Implementace | 1. je standardní funkcionalita aplikace | Funkce personalizované notifikace |
42 | Mobilní aplikace umožňující přehled svých úkolů napříč projekty, zasílající upozornění při změnách stavu úkolů | Implementace | 1. je standardní funkcionalita aplikace | mobilní aplikace |
43 | Systém bude obsahovat vyhledávání, které umožní najít klíčová slova v názvech, popisech, komentářích, ale také v názvech příloh k jednotlivým úkolům | Implementace | 1. je standardní funkcionalita aplikace | vyhledávání v datech napříč projekty |
44 | Systém bude obsahovat funkci poznámek, kam si bude moct každý uživatel zapisovat svoje poznámky, tyto poznámky budou přístupné jak v systému, tak v mobilní aplikaci a budou automaticky oboustranně synchronizované | Implementace | 1. je standardní funkcionalita aplikace | Nastavení poznámek v rámci privátního projekltu |
45 | Propojení s centrálním úložištěm dokumentů, vytváření obrazu dokumentu v projektech | Implementace | 1. je standardní funkcionalita aplikace | Systém obsahuje úložiště souborů. Systém je také možné napojit na úložiště zákazníka, dle potřeby. |
46 | Automatický import uživatelů z ERP systému, omezení přístupu v případě ukončení pracovního poměru atd. | Implementace | 1. je standardní funkcionalita aplikace | Umožněno přes správu uživatelů |
47 | Možnost integrace s emailem a kalendářem - emailovou komunikaci automaticky přenášet k úkolům v projektech | Implementace | 1. je standardní funkcionalita aplikace | Funkce integrace |
11. Spisová služba mimo zdravotnickou dokumentaci | Požadavek | Splňuje | Popis | |
1. | Korespondence - evidence na vstupu, předání k vyřízení | Implementace | 1. je standardní funkcionalita aplikace | Požadavek splněn standardní funkčností nabízeného SW |
2. | Evidence a zveřejňování smluv | Implementace | 1. je standardní funkcionalita aplikace | Evidence smluv bude řešena v rámci FaMa+ TPIS a Spisové služby. Komunikace s registrem smluv bude probíhat přes spisovou službu. Xxxxxx mimo evidenci nemá žádné funkčnosti z hlediska oběhu, schvalování apod. |
3. | Uchovávání elektronických dokumentů z datových schránek | Implementace | 1. je standardní funkcionalita aplikace | Požadavek splněn standardní funkčností nabízeného SW |
4. | Systém musí splňovat parametry definované v platné legislativě, a to zejména: • Zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, v platném znění • Zákon č. 500/2004 Sb., správní řád, v platném znění • Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, v platném znění • Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, v platném znění • Zákon č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční kontrole), v platném znění | Implementace | 1. je standardní funkcionalita aplikace | nabízený SW splňuje platnou legislativu týkající se spisové služby |
• Zákon č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv), v platném znění • Národní standard pro Elektronické systémy spisové služby MV 101/2010 a část 57/2017. • Vyhláška 259/2012 Sb. o podrobnostech výkonu spisové služby v platném znění • Nařízení Evropského parlamentu a Rady (EU) č. 910/2014 (eiDAS) • Xxxxx s ETSI normy | ||||
5. | Podporované komunikační kanály: | Implementace | ||
• Datová schránka | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | ||
• Papírová pošta | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Elektronické dokumenty předané na pevném nosiči (CD, DVD, USB, …) | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Dokumenty vložené přímo do spisové služby interními uživateli | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Dokumenty aplikací třetích stran (minimálně formát .doc(x), .xls(x), txt a .pdf) | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
6. | Systém musí podporovat všechny fáze životního cyklu dokumentu: | Implementace | ||
• Příjem | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
• Předávání | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Evidenci | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Začleňování do spisů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Zpracování písemností | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Vypravení dokumentu | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Archivaci a skartaci | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
7. | Ověření pravosti dokumentu – kontrola platnosti elektronických podpisů a časových razítek připojených k dokumentu (o každém proběhlém ověření dokumentu je automaticky vyhotoven záznam). | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
8. | Pravidla pro reakci na zjištění, že dokument není pravý, určuje správce systému. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
9. | Pravidla mohou zahrnovat vyřazení dokumentu, upozornění interního uživatele nebo odeslání automatické odpovědi s upozorněním pro odesílatele. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
10. | Zaevidování dokumentu - založení záznamu o dokumentu s automatickým přidělením jednoznačného identifikátoru, popř. jednacího čísla. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
11. | Založení spisu – založení spisu k dokumentu. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
12. | Identifikace dokumentů, podpora čárových kódů – vkládání, vyhledávání. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Spisová služba podporuje identifikaci dokumentů pomocí JID. Problematika podpory čárových kódů bude v rámci části řešení evidence smluv dořešena v rámci analýzy. |
13. | Vytvoření kopie – vytvoření kopie dokumentu. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
14. | Zařazení/vyřazení dokumentu do/ze spisu. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
15. | Možnost přidělení dokumentu/spisu funkčnímu místu nebo organizační jednotce. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
16. | Převzetí (Odmítnutí / Odvolání předání) dokumentu nebo spisu. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
17. | Nastavení přístupových práv k dokumentu /spisu – uživatel může přidat přístupová práva dalším funkčním místům, skupinám nebo organizačním jednotkám. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
18. | Přidělení spisového, skartačního znaku, lhůty vyřazení dle spisového a skartačního plánu. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
19. | Vyřízení a uzavření spisu a dokumentů. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
20. | Sledování a zobrazení historie zpracování a provedených operací s dokumentem. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
21. | Nastavení avíza – nastavení upozornění na blížící se nebo překročený termín nebo změnu přidělení dokumentu. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Část řešení evidence smluv umožňuje odesílání avíz na blížící se nebo překročený termín nebo změnu přidělení dokumentu. |
22. | Předání k vypravení – předání dokumentu k expedici na uvedenou adresu příjemce a uvedeným způsobem vypravení. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
23. | Vypravení dokumentu – provedení expedice dokumentu na výpravně. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
24. | Ukládání – zakládání, úprava, předávání do spisoven v ucelených jednotkách. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
25. | Práce se spisovnou - příjem vyřízených dokumentů a uzavřených spisů. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
26. | Podpora skartačního řízení (vytváření skartačních seznamů, sledování skartačních lhůt, upozorňování na vypršení skartačních lhůt a eskalace, příprava seznamů pro Národní archiv, příprava na elektronickou výměnu dat s Národním archivem, tisk a export skartačního seznamu, prodlužování skartačních lhůt). | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
27. | Vyhledávání: | Implementace | ||
• Rychlé vyhledávání podle jedné položky | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Vyhledávání podle kombinace položek | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Vyhledávání podle vyhledávacího formuláře | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení v rámci evidence smluv splňuje uvedený požadavek. Každý formulář obsahuje vyhledávací řádek. | |
• Fulltextové vyhledávání | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
28. | Tisk - tiskové sestavy, tisk přehledů, poštovní obálky, spisové obálky a sběrného archu spisu. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
29. | Přehledy - zobrazení zvoleného přehledu dokumentů nad složkou. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
30. | Práce s elektronickým dokumentem - vložení, zobrazení, úprava/verzování a podepisování el. dokumentů. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
31. | Správa číselníků a nastavení ESSS – změna uživatelského nastavení, nastavení avíza. | Implementace | 1. je standardní funkcionalita aplikace | Správa nesystémových číselníků je v řešení spisové služby podporována. Nastavení avíz je podporováno v rámci části řešení evidence smluv. |
32. | Možnost naskenování dokumentu, uložení naskenovaného obrázku k zaevidovanému dokumentu a vytvoření digitálního dokumentu ve formátu dle platné legislativy. | Implementace | 3. řešeno standardním produktem třetí strany | Naskenování dokumentu včetně převodu do výstupního datového formátu proběhne v rámci aplikace skenovacího HW. Spisová služba přebere tento dokument přičemž zkontroluje formát přílohy při předání do spisovny. |
33. | Poskytování přehledů a statistik datových zpráv (ISDS). | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
34. | Evidence externích písemností přijatých organizací, skenování příchozích dokumentů. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Příjem dokumentů proběhne ve spisové službě. Naskenování příchozích dokumentů proběhne v rámci aplikace skenovacího HW. |
35. | Evidence a vypravování písemností z organizace na externí partnery, použití čárových kódů. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Evidence a vypravování písemností z organizace na externí partnery proběhne v řešení spisová služba. Čárové kódy lze využít v rámci části řešení Evidence smluv. |
36. | Evidence písemností vzniklých z činnosti organizace (interní dokumenty). | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
37. | Rozdělení písemností na důležité (č.j.), běžnou poštu a neevidované. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
38. | Oběh písemností v organizaci, předávání a vyřizování v rámci agendy, ukládání vyřízených dokumentů do spisovny. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
39. | Napojení na e-mail, možnost výběru, zda elektronický dokument ve spisové službě evidovat či ne. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
40. | Napojení na datové schránky. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
41. | Nastavování přístupových práv uživatelů, dle organizační struktury zadavatele. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
42. | Historie dokumentu musí být kdykoli dohledatelná, v závislosti na přístupových právech uživatelů. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
43. | Možnost dokumenty zařazovat do spisů. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
44. | Jednoduchý tisk obálek, včetně tisku čárových kódů a podacího razítka. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Podpora tisku obálek (včetně tisku čárových kódů v rámci evidence smluv), podací razítko vytiskne franovací stroj. |
45. | Musí umožňovat podepisování připojených dokumentů interním elektronickým podpisem za účelem autorizace uživatele. | Implementace | 1. je standardní funkcionalita aplikace | Nabízené řešení splňuje uvedený požadavek. Připojené dokumenty lze podepisovat interním elektronickým podpisem. |
46. | Napojení frankovacího stroje na spisovou službu (umožňuje kontrolu nad náklady za odesílání dle jednotlivých středisek). | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
47. | Systém musí umožňovat napojení scanneru přímo na spisovou službu (elektronizace dokumentů). | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Řešení spisové služby bude napojeno přímo na scanner, na kterém poběží nativní aplikace tohoto HW zařízení, která bude zajišťovat skenování. Řešení bude upřesněno v rámci analýzy. |
48. | Nastavení uživatelských přístupů. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
49. | Migrace dat ze stávajících systémů není požadována. | Implementace | 1. je standardní funkcionalita aplikace | Respektujeme a plníme tento požadavek. |
50. | Zajištění možnosti spolupráce/integrace s interními agendovýmy systémy (faktury, registr smluv, směrnice, žádanky) – systém musí disponovat standardním rozhraním (nejlépe formou webových služeb), které bude umožňovat napojení externích systémů, součástí dodávky je popis poskytovaných integračních služeb řešení | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
51. | Napojení datových schránek a úředních e- mailů, oběh a ukládání těchto dokumentů v rámci organizace. | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
52. | Funkcionalita pro datové schránky (DS) – příjem dokumentů: | Implementace | ||
• Plně automatická kontrola datové schránky | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Zajištění příjmu dokumentu ve formátu tak jak byl dodán do DS včetně opatřených metadat, příloh, elektronických podpisů a časových razítek | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Po vyřízení dokumentu ukládání dokumentů včetně všech příloh v nezměněné podobě do úložiště | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Označování dokumentů v den doručení jednoznačným identifikátorem, označení originálů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Zajištění evidence dokumentu a záznamu o dokumentu včetně evidence data dodání a doručení | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Vyhledávání v seznamu DS | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
• Zajištění kontrol dle platných právních předpisů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
53. | Funkcionalita pro datové schránky (DS) – odesílání dokumentů: | Implementace | ||
• Předávání dokumentů k odeslání prostřednictvím datové schránky | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Zajištění kontrol dle platných právních předpisů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Odesílání dokumentů prostřednictvím DS určenému adresátu | Xxxxxxxxxxxx | 0. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Evidence odeslaných dokumentů, označení originálů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Příjem a evidence doručenek k odeslaným dokumentům | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Párování doručenek s odeslanými dokumenty | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Vedení spisových znaků pro skartaci | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Zajištění kontrol dle platných právních předpisů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Zajištění případného doplnění neúplného dokumentu metadaty | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Po vyřízení dokumentu uložení odeslaných dokumentů (datových zpráv) v nezměněné podobě do úložiště | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Uložení doručenek v nezměněné podobě do úložiště | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |
54. | Funkcionalita pro listinnou poštu – příjem dokumentu: | Implementace | ||
• Možnost označení listinného dokumentu identifikátorem (čárovým kódem). Nalepení čárového kódu | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Spisová služba podporuje identifikaci dokumentů pomocí JID. Problematika podpory čárových kódů bude v rámci části řešení evidence smluv dořešena v rámci analýzy. | |
• Vedení deníku o zařazení (druhu) podání, přidělení a vyřízení (přidělení č. j.) | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Práce s dokumenty s využitím čárového kódu. | Implementace | 2. je předmětem úpravy (dopracování) aplikace | Spisová služba podporuje identifikaci dokumentů pomocí JID. Problematika podpory čárových kódů bude v rámci části řešení evidence smluv dořešena v rámci analýzy. | |
55. | Funkcionalita pro listinnou poštu – odesílání dokumentu: | Implementace | ||
• Vedení deníku, evidence způsobu a datum odeslání | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Evidence data a způsobu doručení (doručenky), pokud jsou údaje k dispozici | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Tisk evidenčních listů pro Českou poštu | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
56. | Požadavky na administraci systému spisové služby: | Implementace | ||
• Správa šablon, dokumentů a číselníků, včetně jejich napojení na metadata | Implementace | 1. je standardní funkcionalita aplikace | Správu šablon, dokumentů a číselníků, včetně jejich napojení na metadata lze v rámci řešení Spisové služby provádět. | |
• Správa spisových plánů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Nastavování lhůt pro vyřízení, včetně vazby na typy spisů a dokumentů | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW | |
• Logování všech aktivit | Implementace | 1. je standardní funkcionalita aplikace | požadavek splněn standardní funkčností nabízeného SW |