Smlouva o dílo
Smlouva o dílo
uzavřena dle zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen
„občanský zákoník“)
1. Smluvní strany
Západočeská univerzita v Plzni
se sídlem Univerzitní 8, 306 14 Plzeň
zastoupená: Doc. Dr. RNDr. Xxxxxxxxxx Xxxxxxxx, rektorem IČ 49777513, DIČ CZ49777513
veřejná vysoká škola, nezapisuje se do OR
bankovní spojení: Komerční banka a.s., Plzeň – město č. účtu: 4811530257/0100
(dále jen „Objednatel“)
a
ApS Brno, s. r. o.
se sídlem Božetěchova 2, 612 66 Brno
zastoupená Ing. Xxxxxxx Xxxxxx, jednatelem společnosti IČ: 00543535, DIČ: CZ00543535
zapsaný u Krajského soudu v Brně pod sp. zn. C 35 bankovní spojení: Komerční banka a.s., Brno – město č.ú.: 113545621/0100
(dále jen „Zhotovitel“)
2. Předmět plnění
2.1. Předmětem veřejné zakázky je provedení a poskytnutí upgrade software ISKaM z roku 2008 na verzi ISKaM4 pro potřebu Západočeské univerzity (software ISKaM tvoří moduly: jádro systému, kolejní systém, stravovací systém, jednotné univerzitní konto, servisní moduly).
Součástí předmětu plnění je také:
a) upgrade jednotlivých modulů systému:
• implementace informačního systému na jednu referenční stanici jednotlivé stanice;
• implementace informačního systému na servery;
• upgrade napojení na ekonomický systém ZČU v Plzni;
• upgrade napojení na studijní informační systém ZČU v Plzni;
• upgrade napojení na tiskový systém ZČU v Plzni;
• upgrade napojení na systém autentizace uživatelů a systém evidence osob ZČU v Plzni;
b) převod dat z systému ISKaM do ISKaM4,
c) proškolení provozního personálu, managementu a administrátora systému,
d) záruka na jakost díla po dobu 24 měsíců od předání díla a jeho převzetí Objednatelem,
e) zajištění pozáručního servisu na dobu neurčitou dle detailních podmínek uvedených v servisní smlouvě, která bude se Zhotovitelem následně uzavřena.
Strana 1
2.2. Členění předmětu díla:
2.2.1. Dodávka programového vybavení
2.2.1.1. Definice funkcí systému dle přílohy č.1 Smlouvy o dílo
2.2.1.2. Software informačního systému
2.2.1.3. Uživatelský manuál v elektronické podobě
2.2.2. Implementace programového vybavení v prostředí Objednatele
2.2.3. Školení - v rozsahu
2.2.3.1. 2 dny pro administrátory
2.2.3.2. 2 dny pro vrátné a ubytovatelky
2.2.3.3. 2 dny pro vedení a ekonomy Objednatele.
2.2.3.4. 2 dny obsluhu stravovacích zařízení.
3. Doba a místo plnění
3.1. Dílo bude předáno Objednateli nejpozději do dne 01. 09. 2016.
Ostatní termíny upravuje Příloha č. 2 „Harmonogram nasazení systému ISKaM4“.
3.2. Místem plnění je ZČU v Plzni, Univerzitní 8, Plzeň a jednotlivé objekty ZČU, kde se používá software ISKaM.
4. Cena díla a způsob placení
4.1. Cena je stanovena dohodou smluvních stran ve výši [DOPLNÍ ZÁJEMCE] Kč bez DPH (slovy: [DOPLNÍ ZÁJEMCE]).
DPH činí [DOPLNÍ ZÁJEMCE] %, tj. [DOPLNÍ ZÁJEMCE] Kč (slovy: [DOPLNÍ ZÁJEMCE]).
Cena včetně DPH činí [DOPLNÍ ZÁJEMCE] Kč (slovy: [DOPLNÍ ZÁJEMCE]).
4.2. Cena je cenou nejvýše přípustnou a zahrnuje veškerá související plnění definovaná v čl. 2 této smlouvy, jakož i ostatní práce a výkony výslovně touto smlouvou neuvedené, avšak Xxxxxxxxxx s ohledem na své odborné znalosti a zkušenosti věděl nebo vědět měl či mohl, že jejich provedení je nutné pro řádné splnění díla.
4.3. Cenu je možné překročit pouze v souvislosti se změnou daňových předpisů týkajících se DPH.
4.4. Cena díla bude uhrazena jako jednorázová platba v české měně na základě daňového dokladu – faktury vystavené Zhotovitelem.
4.5. Nárok Xxxxxxxxx na uhrazení ceny za dílo vzniká až v okamžiku řádného splnění díla v souladu s čl. 7 Smlouvy. Dílo se pokládá za řádně splněné i při výskytu vad nebránících funkčnosti díla.
4.6. Splatnost faktury je 30 kalendářních dnů od jejího prokazatelného doručení Objednateli. K faktuře bude přiložen zápis o převzetí díla včetně zápisu o odstranění vad a nedodělků bránících v řádném provozování díla, pokud se takové při předání díla vyskytly.
4.7. Daňový doklad – faktura musí obsahovat všechny náležitosti řádného účetního a daňového dokladu ve smyslu příslušných právních předpisů, zejména zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů. V případě, že faktura nebude mít odpovídající náležitosti, je Objednatel oprávněn ji vrátit ve lhůtě splatnosti zpět Zhotoviteli k doplnění, aniž se tak dostane do prodlení se splatností. Lhůta splatnosti počíná běžet znovu od opětovného doručení náležitě doplněné či opravené faktury Objednateli.
4.8. Cena díla bude Objednatelem uhrazena na bankovní účet Zhotovitele uvedený v čl. 1 Smlouvy. Povinnost uhradit smluvní odměnu bude Objednatelem splněna v okamžiku připsání celé výše smluvní odměny na bankovní účet Zhotovitele.
4.9. Objednatel neposkytuje zálohy.
Strana 2
5. Práva a povinnosti smluvních stran
5.1. Zhotovitel není oprávněn postoupit jakákoliv práva anebo povinnosti z této Smlouvy na třetí osoby bez předchozího písemného souhlasu Objednatele.
5.2. Práva a povinnosti z této Smlouvy, resp. práva a povinnosti, přecházejí při zániku Xxxxxxxxxxx na jeho právního nástupce.
5.3. Smluvní strany se dohodly, že osobou oprávněnou k jednání za Xxxxxxxxxxx ve věcech, které se týkají této Smlouvy a její realizace, je:
jméno: [DOPLNÍ ZÁJEMCE]
tel.: [DOPLNÍ ZÁJEMCE]
e-mail: [DOPLNÍ ZÁJEMCE]
Změna této osoby musí být Objednateli neprodleně písemně oznámena, přičemž je účinná okamžikem doručení tohoto písemného oznámení Objednateli.
Smluvní strany se dohodly, že osobami oprávněnými k jednání za Objednatele ve věcech, které se týkají této Smlouvy a její realizace, jsou:
jméno: Xxxxxx Xxxxxxxxxxx
tel.: x000 000 000 000
e-mail: xxxxxxxx@xxx.xxx.xx
jméno: Xxx. Xxxxxxxxx Xxxx
tel.: x000 000 000 000
e-mail: xxxxx@xxx.xxx.xx
Změny těchto osob musí být Zhotoviteli neprodleně písemně oznámeny, přičemž jsou účinné okamžikem doručení tohoto písemného oznámení Zhotoviteli.
5.4. Zhotovitel bere na vědomí, že podle § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě, je osobou povinnou spolupůsobit při výkonu finanční kontroly.
5.5. Zhotovitel se zavazuje, že pokud v souvislosti s realizací této Xxxxxxx při plnění svých povinností přijdou jeho pověření pracovníci do styku s osobními/citlivými údaji ve smyslu zákona č. 101/2000 Sb., o ochraně osobních údajů, v platném znění, učiní veškerá opatření, aby nedošlo k neoprávněnému nebo nahodilému přístupu k těmto údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování, jakož i k jejich jinému zneužití.
5.6. Xxxxxxxxxx bere na vědomí a souhlasí s tím, že tato Xxxxxxx bude uveřejněna na profilu zadavatele Objednatele ve smyslu ust. § 147a zákona č. 137/2006 Sb., o veřejných zakázkách, v platném znění (dále jen „ZVZ“), stejně tak jako bude uveřejněna výše skutečně uhrazené ceny za plnění předmětu této Smlouvy, a to ve lhůtách a způsobem uvedeným v ust. § 147a ZVZ. Zhotovitel je ve smyslu ust. § 147a odst. 4 a 5 ZVZ povinen předkládat Objednateli seznam subdodavatelů v termínech a rozsahu tam uvedeném. V případě porušení zákonných povinností stanovených Zhotoviteli v ust. § 147a odst. 4 a 5 ZVZ odpovídá Zhotovitel za škodu způsobenou porušením povinnosti Objednateli v plné výši.
5.7. Objednatel dává na vědomí a Zhotovitel bere na vědomí, že Objednatel není v daném smluvním vztahu podnikatelem.
Strana 3
6. Součinnost stran
6.1. Vzhledem k povaze díla se smluvní strany zavazují poskytnout si vzájemnou součinnost při provádění předmětu smlouvy. Objednatel poskytne Zhotoviteli veškeré informace nezbytné pro implementaci programu do prostředí Objednatele. Minimální rozsah těchto informací je:
• struktury katalogů a číselníků
• popis struktur katalogů a číselníků
• definice a forma předávání výstupních údajů k přenosu do IS školy požadovaných Objednatelem
• definice softwarového okolí
Tyto informace poskytne Objednatel zhotoviteli do 30 dní od podpisu.
6.2. Objednatel zabezpečí Zhotoviteli přístup k uvedeným datům a součinnost se zodpovědnými osobami jakož i dodavatelem IS školy.
6.3. Případné další požadavky uplatní Zhotovitel e-mailem nebo písemně na adresu kontaktní osoby s uvedením nejzazší lhůty pro odpověď.
6.4. Nebude-li možno pro prodlení na straně Objednatele v práci na díle pokračovat, určí další postup pověřené osoby Objednatele a Zhotovitele.
6.5. Smluvní strany se zavazují vyvinout veškeré úsilí k zajištění nezbytného toku informací. V případě potřeby bude sjednán režim pravidelných kontaktů.
6.6. Postup při implementaci je obsahem Přílohy č. 2. „Harmonogram nasazení systému ISKaM4“ této smlouvy.
6.7. Objednatel se zavazuje zajistit potřebný hardware i software na úrovni typické konfigurace uvedené v Příloze č. 3 „Hardwarové a softwarové požadavky na systém ISKaM4“ této smlouvy.
7. Splnění díla
7.1. Dílo se pokládá za splněné řádným provedením, tzn. musí být zhotoveno v souladu se zadáním, implementováno do prostředí Objednatele a zajištěna jeho funkčnost a dále proškolením zaměstnanců Objednatele ve stanoveném rozsahu.
7.2. Termín splnění se prodlužuje o dobu, po kterou nebylo možno výlučně z důvodů na straně Objednatele realizovat implementační procedury dle Přílohy č. 2. „Harmonogram nasazení systému ISKaM4“ této smlouvy.
7.3. Nejpozději 5 dnů před termínem splnění vyzve Xxxxxxxxxx Objednatele k převzetí díla. Převzetí proběhne na zařízení Objednatele tak, aby byly ověřeny všechny sjednané parametry díla. O převzetí se pořídí zápis, ve kterém budou popsány eventuelní závady nebránící provozu s uvedením termínu jejich odstranění. Dílo se pokládá za splněné též tehdy, bude-li převzetí zmařeno v důsledku neposkytnutí součinnosti Objednatele nebo pokud Objednatel bezdůvodně převzetí odepře.
8. Práva k užití díla
8.1. Vzhledem ke své povaze podléhá dílo režimu autorského zákona. Zaplacením díla vzniká licenční smlouva na nevýhradní užití předmětu díla v ubytovacích a stravovacích zařízeních provozovaných Objednatelem ke dni podpisu smlouvy s maximálním počtem lůžek 3 161 ve všech ubytovacích zařízeních Objednatele a počtem hlavních jídel 566 000 za rok ve všech stravovacích zařízeních Objednatele. Překročení o více jak 10% si vyžaduje dodatek k licenční smlouvě. Zhotovitel jako poskytovatel licence výslovně prohlašuje, že je na základě svého právního vztahu s autorem/vykonavatelem majetkových práv k výše uvedenému softwaru
Strana 4
oprávněn poskytnout nebo zprostředkovat poskytnutí licence. Za pravdivost tohoto prohlášení nese Zhotovitel jako poskytovatel plnou odpovědnost.
9. Odpovědnost za vady
9.1. Zhotovitel odpovídá za vady díla v záruční době, kterými je každá odchylka od zadání sjednaného předmětu plnění resp. od dokumentovaných modifikací (upgradů), a to po dobu 2 let od předání díla.
9.2. Zhotovitel odstraní každou vadu, o které bude písemně vyrozuměn prostřednictvím internetových stránek Zhotovitele na adrese xxxx://xxxxxxx.xxx-xxxx.xx, a to bezplatně ve lhůtách dle tabulky. V případě nefunkčnosti výše uvedených stránek lze o vadě vyrozumnět e-mailem nebo telefonicky na uvedený kontakt dle čl. 5.4. Smlouvy. Lhůty uvedené v tabulce počínají běžet od okamžiku písemného nebo telefonického nahlášení vady Zhotoviteli.
Smluvní strany se dohodly na klasifikaci vad takto:
Kritické vady – vady, které znemožňují práci s aplikačním SW nebo jeho částí a nelze použít alternativní postup
Méně závažné vady – vady, které omezují práci s aplikačním SW nebo jeho částí, ale lze použít alternativní postup.
Vady neohrožující funkčnost – vady, které neohrožují funkčnost aplikačního SW nebo jeho částí.
Xxxxxxx | Xxxxxxxx vady | Méně závažné vady | Vady neohrožující funkčnost |
Poskytnutí informace Objednateli, jakým způsobem bude Zhotovitel závadu řešit | 0:30 hod. | 2 hod. | 8 hod. |
Zprovoznění systému alespoň náhradním způsobem pro zajištění jeho základních funkcí (tj. ne úplné odstranění závady) | 1 hod. | 8 hod. | 24 hod. |
Úplné odstranění závady (tj. dosažení stavu, ve kterém byl systém před závadou) | 8 hod. | 40 hod. | 160 hod. |
Veškeré lhůty jsou vázány na pracovní dobu v pracovní dny od 8:00 do 16:00 hod.
10. Sankce a odstoupení od smlouvy
10.1. Smluvní strany si sjednávají tyto smluvní pokuty:
Xxxxxx 0
10.1.1. Za každý den prodlení s předáním díla 5.000,- Kč
10.1.2. Za každou započatou hodinu prodlení s odstraněním
záruční vady „kritické“ uvedené v čl. 9 Smlouvy 200,- Kč
10.1.3. Za každou započatou hodinu prodlení s odstraněním
záruční vady „méně závažné“ uvedené v čl. 9 Smlouvy 100,- Kč
10.1.4. Za každou započatou hodinu prodlení s odstraněním
záruční vady „neohrožující funkčnost“ uvedené v čl. 9 Smlouvy 50,- Kč
10.2. V případě porušení povinností uvedených v čl. 5.5 Smlouvy je sjednána smluvní pokuta ve výši 100 000,- Kč za každé takové porušení.
10.3. V případě prodlení Objednatele s úhradou vystavené faktury za zhotovení díla je Xxxxxxxxxx oprávněn uplatnit vůči Objednateli úrok z prodlení ve výši 0,5 % z odměny bez DPH (čl. 4.1. Smlouvy) za každý i jen započatý den prodlení.
10.4. V případě neposkytnutí součinnosti ze strany Objednatele v termínu uvedeném v čl. 6.1 Xxxxxxx, je Zhotovitel oprávněn požadovat smluvní pokutu za každý i jen započatý den prodlení ve výši 5.000,- Kč.
10.5. Smluvní pokuty uplatňované dle této Smlouvy jsou splatné do 30 (třiceti) dnů od data, kdy byla povinné straně doručena písemná výzva k zaplacení smluvní pokuty ze strany oprávněné strany, a to na účet oprávněné strany uvedený v čl. 1 této Smlouvy.
10.6. Od této Smlouvy může smluvní strana dotčená porušením povinnosti jednostranně odstoupit pro podstatné porušení této Smlouvy, přičemž za podstatné porušení této Smlouvy se zejména považuje:
a) na straně Objednatele nezaplacení ceny podle této Smlouvy ve lhůtě delší 30 dní po dni splatnosti příslušné faktury;
b) na straně Zhotovitele, jestliže Zhotovitel bude v prodlení s řádným poskytnutím předmětu Smlouvy po dobu delší než 30 dnů,
c) na straně Zhotovitele, jestliže předmět plnění nebude mít vlastnosti deklarované Zhotovitelem v této Smlouvě, resp. v jejích přílohách, a Zhotovitel neuvede vlastnosti předmětu plnění do souladu se Smlouvou do 1 měsíce od doručení písemné výzvy Objednatele.
10.7. Obě smluvní strany berou na vědomí, že odstoupení je jednostranný právní úkon, jehož účinky nastávají doručením projevu vůle oprávněné strany odstoupit druhé straně, pokud v této Smlouvě není sjednáno jinak. Odstoupení Objednatele se nedotýká nároku na náhradu újmy Objednatele (majetkové i nemajetkové) vzniklé porušením Smlouvy, nároku na zaplacení smluvních pokut a dalších práv a povinností, u nichž to vyplývá z příslušných ustanovení zákona č. 89/2012 Sb., občanského zákoníku, ve znění pozdějších předpisů nebo z ustanovení Smlouvy, která podle projevené vůle stran nebo vzhledem ke své povaze mají trvat i po ukončení Smlouvy ve smyslu ust. § 2005 zákona č. 89/2012 Sb., občanského zákoníku, ve znění pozdějších předpisů, není-li výslovně sjednáno v této Smlouvě jinak.
11. Společná a závěrečná ustanovení
11.1. Tato Smlouva nabývá platnosti a účinnosti dnem jejího uzavření, tzn. dnem podpisu Smlouvy oprávněnými zástupci obou smluvních stran.
11.2. Podpisem této smlouvy zanikají veškerá předchozí ujednání.
11.3. Vztahy zde neupravené se řídí občanským zákoníkem.
11.4. Veškeré změny či doplnění Smlouvy lze učinit pouze na základě písemné dohody smluvních stran. Takové dohody musí mít podobu datovaných, číslovaných a oběma smluvními stranami podepsaných dodatků Smlouvy.
Xxxxxx 0
11.5. Nastanou-li u některé ze stran skutečnosti bránící řádnému plnění této Smlouvy, je povinna to ihned bez zbytečného odkladu oznámit druhé straně a vyvolat jednání zástupců Objednatele a Zhotovitele.
11.6. Smluvní strany si sjednávají, že pokud v důsledku změny či odlišného výkladu právních předpisů a/nebo judikatury soudů bude u některého ujednání této Smlouvy shledán důvod neplatnosti či neúčinnosti právního jednání, Smlouva jako celek nadále platí, přičemž za neplatnou či neúčinnou bude možné považovat pouze tu část, které se důvod neplatnosti či neúčinnosti přímo týká.
11.7. Smluvní strany budou vždy usilovat o smírné urovnání případných sporů vzniklých ze Smlouvy. Případné spory vzniklé z této Smlouvy budou řešeny podle platné právní úpravy věcně a místně příslušnými orgány České republiky. Smluvní strany sjednávají pro spory vyplývající z této Smlouvy či s touto Smlouvou související místní příslušnost Okresního soudu Plzeň – město, resp. Krajského soudu v Plzni.
11.8. Nedílnou součástí předmětné Smlouvy jsou také následující přílohy:
a) Příloha č. 1 „Popis požadované funkcionality“,
b) Příloha č. 2 „Harmonogram nasazení systému ISKaM4“,
c) Příloha č. 3 „Hardwarové a softwarové požadavky na systém ISKaM4“.
11.9. Smlouva se sepisuje ve čtyřech vyhotoveních, po dvou pro každou stranu.
11.10. Smluvní strany prohlašují, že si Xxxxxxx před jejím podpisem přečetly a s jejím obsahem bez výhrad souhlasí. Smlouva je vyjádřením jejich pravé, skutečné, svobodné a vážné vůle. Na důkaz pravosti a pravdivosti těchto prohlášení připojují oprávnění zástupci smluvních stran své podpisy.
V Plzni dne V [DOPLNÍ ZÁJEMCE] dne [DOPLNÍ ZÁJEMCE]
za Objednatele za Zhotovitele
doc. Dr. RNDr. Xxxxxxxx Xxxxxxx, rektor [DOPLNÍ ZÁJEMCE]
Xxxxxx 0
Příloha č. 1 - Popis požadované funkcionality
1. Uživatelské rozhraní
1.1. Program disponuje intuitivním, přehledným a graficky zpracovaným uživatelským rozhraním
1.2. Obsluha se dostane na každý související údaj v databázi s minimálním počtem úkonů (např. od klienta na ubytování, od ubytování na konto, atp.)
1.3. Fulltextové vyhledávání v databázi aplikace
a) Vyhledávání funguje nad všemi uživatelsky významnými daty současně (obsluha tak současně najde např. jak klienta, tak jeho ubytování, žádosti,
…)
b) Vyhledávání je nezávislé na diakritice
c) Z výsledků vyhledávání se uživatel dostane přímo k nalezenému záznamu
d) Uživatel může omezit vyhledávání jen na vybraný katalog
e) Výsledky vyhledávání jsou seřazené dle relevance a dle priorit katalogů
f) Vyhledávání je závislé na oprávněních uživatelů k přístupu ke katalogům
g) Vyhledávání funguje i na názvy dialogů
1.4. Uživatelé si mohou v aplikaci vzájemně posílat úkoly
a) Úkol obsahuje odkaz na konkrétní obrazovku, příjemce úkolu tak nemusí nic hledat
b) Úkol lze přiřadit více uživatelům, jakmile je úkol splněn, tak se přestane zobrazovat všem příjemcům (tj. úkol splní první z uživatelů, který se jej ujme)
1.5. Program podporuje čtečky čipových karet klientů
a) Karty studentů a zaměstnanců jsou zpravidla importovány z informačního systému školy
b) Do systému lze karty zadávat i ručně (užitečné např. pro studenty jiných vysokých škol, ale klientům lze přiřadit i např. OpenCard, bezkontaktní bankovní karty, atp.)
c) Při načtení karty zadané v systému se automaticky vyhledá aktuální ubytování klienta, pokud neexistuje, tak karta klienta
1.6. Program podporuje čtečky strojově čitelných dat dokladů
a) Lze načíst všechny moderní typy občanských průkazů a pasů
b) Rychlé a přesné údaje zejména u komerčních hostů ze zahraničí
c) Nulová chybovost ve vztahu k hlášením pro cizineckou policii
1.7. Systém uchovává a zpřístupňuje historii navštívených záznamů
1.8. Uživatelé mají možnost definovat své „oblíbené“ položky a rychle k nim přistupovat (typicky např. často používané přehledy)
1.9. Pro usnadnění obsluhy je k dispozici též doplněk do Outlooku, kdy se obsluze z Outlooku otevře dialog s klientem, pokud tento existuje v databázi.
2. Struktura, katalogy
2.1. Stromová struktura organizace až na úroveň bloků
a) Neomezená úroveň vnoření
1
b) Typy provozů: obecný provoz, kolej, blok, menza, bufet
2.2. Každý blok může mít přiřazeno nákladové středisko
2.3. Katalog pokojů obsahuje tyto položky
a) odkaz na blok, do nějž náleží
b) číslo pokoje
c) patro
d) poznámku
e) hodnoty atributů pokoje (dle bodu 6), časově proměnné
f) typ pokoje
g) cenovou skupinu
2.4. Pro každý typ pokoje lze nastavit, které typy osob v něm smí bydlet (časově proměnné)
2.5. Katalog atributů pokojů
a) Uživatelsky rozšiřitelný
b) Pouze binární atributy (pokoj je buď má, nebo nemá)
c) Každá položka obsahuje přirážku k ceně lůžka
d) Xxxx přirážka smí být záporná
e) Tato přirážka je závislá na typu ubytované osoby
f) Přirážka se automaticky přičítá k ceně ubytování každé osoby na pokoji
2.6. Katalog služeb
a) Uživatelsky rozšiřitelný
b) Obsahuje popis
c) Příznak, zda se má zahrnout do ceny ubytování
d) U stravovacích služeb provoz, kde se bude osoba stravovat
2.7. Pokoje lze dočasně vyřadit z provozu
2.8. Seznam operací s pokojem (např. převleky)
a) Uživatelsky rozšiřitelný
b) Název operace
c) Provést každý X-tý den ubytování
d) Provést při ubytování
e) Provést při odhlášení
f) Možnost zadat provedení jednorázově kdykoliv
g) Výstupem je seznam akcí k provedení daný den
2.9. Katalog kritérií, který omezuje osoby, které se smí na pokoj
a) ubytovat pomocí webového rozhraní"
2.10. Katalog cen služeb
a) Smí měnit pouze oprávněná osoba
b) Existují i služby, kde cenu zadává obsluha
c) Ceny se mohou lišit podle typu ubytované osoby
2.11. Katalog výpůjček
a) Uživatelsky rozšiřitelný
b) Obsahuje seznam věcí, které lze zapůjčit
2.12. Katalog cenových skupin obsahuje
2
3. Klienti
a) Název a zkratku
b) Počet lůžek na pokoji
3.1. O klientech budou uchovávány tyto vlastnosti (vyplnění není povinné)
a) Jméno
b) Příjmení
c) Titul
d) Rodné číslo
e) Číslo dokladu
f) Trvalé bydliště
g) Ulice a ČP
h) PSČ
i) Obec
j) Státní příslušnost
k) Telefon
l) Seznam interních poznámek
m) Seznam veřejných poznámek (bude viditelná pro klienta)
n) Seznam upozorňovacích poznámek - bude zobrazena při počátku a konci ubytování
o) Všechny poznámky jsou automaticky opatřeny informací o tom, kdo a kdy je zadal, lze je jednotlivě mazat
p) E-mail
q) Předpokládaný konec studia
3.2. Informace o studentech jsou získávány z databází škol
3.3. Katalog typů osob
a) Uživatelsky rozšiřitelný
b) Definuje typy osob pro ubytování
c) Obsahuje:
• zkratku
• název
• zdroj pro ubytování
4. Ceníky, tvorba cen
4.1. Základní vlastnosti
a) Xxxx je za lůžko a noc
b) Časově omezená platnost (tj. lze zadat, že bude od budoucího data jiná)
4.2. Základní cena
a) Lze nastavit cenu pro každou kombinaci typu osoby a cenové skupiny pokoje
4.3. Další modifikace
a) Přirážky dle atributů pokoje
b) Jiné ceny při ne zcela zaplněném pokoji (např. třílůžkový pokoj obsazený jedním či dvěma hosty)
c) Ceny pro přistýlky (lze využít i pro návštěvy u studentů)
3
4.4. V cenících jsou koncové ceny včetně DPH, výpočet DPH probíhá "zpětně" dle postupu uvedeném v zákoně o DPH
4.5. Systém podporuje i tzv. měsíční ceny, kdy cena za noc je určena jako podíl této zadané ceny a počtu nocí v měsíci
a) U každého typu osoby lze specifikovat, zda se pro něj mají používat měsíční nebo denní ceny
5. Objednávky
5.1. Jedna objednávka obsahuje řadu různých skupin v různých termínech
5.2. Objednávka obsahuje
a) Číslo objednávky (automaticky generované)
b) Objednatele
c) Způsob úhrady
d) Kontaktní adresu
e) Kontaktní e-mail
f) Kontaktní telefon
g) Slevu (procentuálně proti katalogovým cenám)
5.3. Skupina obsahuje
a) Počet osob
b) Počet osob na pokojích
c) Typ ubytovaných osob (může být různý pro různé osoby v objednávce)
d) Služby k ubytování
e) Popis skupiny (usnadňuje orientaci ve skupinách)
5.4. Systém umožňuje práci se skupinou v intuitivním grafickém rozhraní, které umožňuje např.
a) Prodlužování/zkracování jednotlivých, všech nebo vybraných ubytování
b) Xxxxxxxxx, odebírání a služeb, jejich prodlužování a zkracování
c) Změna typu osob
d) Xxxxx s přistýlkami a neobsazenými lůžky
5.5. Rezervace na kapacitu
a) V době přijímání a potvrzování objednávek je možné pracovat pouze s rezervacemi na kapacitu
b) V tomto režimu není nutné specifikovat konkrétní pokoj, ale pouze kombinaci cenové skupiny a typu pokoje
c) I v tomto režimu je k dispozici cena výsledného ubytování včetně služeb a případných slev
d) Je možné pracovat s tzv. "přebookem", tj. přijmout více rezervací, než je kapacita
5.6. Potvrzení objednávky
a) Podmíněno alokací dostatečného počtu lůžek
b) Program vypočítá cenu objednávky dle bodu C.
c) Oprávněná osoba může cenu změnit zadáním slevy (bod D2g)
d) Xxxx ubytování je pak závazná a nezmění se ani při změně ceníku
5.7. K objednávce je možné vystavit
4
b) Uživatelsky konfigurovatelný seznam dokumentů (lze nastavit i vzhled)
5.8. Objednávky mají své veřejně dostupné webové rozhraní (webservice)
5.9. Lze vystavit doklad na přijatou platbu, pokud to klient požaduje
5.10. Slevu (D2g) smí změnit pouze oprávněná osoba
5.11. Možnost odesílání dokumentů e-mailem, popř. SMS
5.12. Zrušení alokace
a) U každého ubytování je možné zadat datum a čas, do kdy musí klient nastoupit, jinak je alokace zrušena
b) Automatické zrušení "propadlých" alokací
c) Objednávka se tímto neruší
6. Ubytování a služby
6.1. Ubytování je obsazení lůžka hostem na určitou dobu. Obsahuje:
a) Odkaz na pokoj
b) Odkaz na hosta
c) Datum zahájení
d) Datum ukončení
e) Typ ubytované osoby
f) Stav ubytování, tj. postupně rezervace/ubytován/odhlášen
g) Další služby k ubytování
h) Vyúčtování ubytování a služeb
i) Plátce ubytování, pokud není shodný s hostem
6.2. Systém umožňuje ubytování hosta bez objednávky (v takovém případě neumožňuje platbu fakturou)
6.3. Při ubytování hosta jsou všechny údaje převzaty z objednávky
6.4. Systém umožňuje zadat přijetí ubytovací kauce a počítá její požadovanou výši
6.5. Při odhlášení je:
a) provedeno vyúčtování služeb a ubytování
b) host uhradí nedoplatek popř. je mu vrácen přeplatek kauce
c) neuhrazení nedoplatku nebrání ukončení ubytování - zůstává dlužník
6.6. Na odebrané služby lze vystavit daňový doklad
a) Lze zvolit, které služby se na dokladu mají objevit
b) Na jednu službu lze vystavit pouze jeden doklad
6.7. Vyúčtování lze provést i před ukončením ubytování
6.8. Pro ubytování delší než nastavený počet dní se provádí vyúčtování měsíčně
a) Okamžik provedení výpočtu vyúčtování lze naplánovat
b) Počítá se volitelně aktuální, předchozí nebo následující měsíc
c) Výsledné vyúčtování má nastaveno datum, do kdy má být uhrazeno
d) Do tohoto vyúčtování se nezapočítá kauce
e) Interval vyúčtování končí vždy posledního příslušného měsíce, noc na prvního je tak vždy součástí "následujícího" měsíce
6.9. Během trvání ubytování je možné přidávat a rušit dosud nevyúčtované služby
5
6.10. Program umožňuje zadat přestěhování
a) Realizováno ukončením jednoho ubytování a započetím dalšího
b) Program umožňuje přestěhovat na volné lůžko
c) Program umožňuje stěhování formou výměny lůžek dvou klientů
6.11. Vyúčtované a zaplacené služby již nelze stornovat
a) Je však možné stornovat nejprve vyúčtování a následně samotnou službu
b) Vyúčtování nelze stornovat, pokud byl vystaven doklad
c) Doklad je však také možné zrušit a stornovat
6.12. K ubytování se váže seznam zápůjček
a) Předměty k zapůjčení jsou definovány v katalogu
b) Eviduje se kdo a kdy předmět půjčil, kdo a kdy jej převzal a kdy má být vrácen
c) Systém nekontroluje dostupnost předmětu (např. počet kusů ložního prádla)
6.13. Systém umožňuje zadat procentuální slevu ke službě
6.14. Systém umožňuje zadat procentuální slevu k jednotlivému ubytování
6.15. Systém umožňuje zadat individuální cenu ubytování bez ohledu na ceníky
6.16. Systém obsahuje zobrazení časové závislosti obsazenosti pokojů a lůžek
a) Zobrazuje jak aktuální a minulá ubytování i rezervace
b) Existuje rychlá možnost tvorby objednávek z tzv. rezervace na kapacitu
c) Existuje rychlá možnost ubytování ze štaflí
6.17. Systém obsahuje grafické znázornění aktuální obsazenosti (přehledné zobrazení celé kapacity)
a) Toto zobrazení je možné i pro jiné než aktuální datum
b) Lze zobrazit i "kumulativní" obsazenost za určité období, kdy jako volná jsou prezentována pouze lůžka volná po celé takové období
c) Systém umožňuje rychlou možnost tvorby ubytování z tohoto zobrazení
6.18. Systém umožňuje ruční korekci všech vyúčtování
7. Způsoby úhrady
7.1. Pro každou objednávku lze zadat způsob úhrady:
a) Hotově
b) Fakturou
c) Inkasem
7.2. Hotovostní platby lze alternativně realizovat také
a) Platbou platební kartou (nutná spolupráce s bankou)
b) Převodem na účet (např. jednorázový nebo trvalý příkaz)
c) On-line platbou přes platební bránu GoPay
7.3. Dosud nezpracované inkaso (nebyl vytvořen příkaz do banky) lze uhradit hotově
7.4. Položku k fakturaci (nebyla dosud vystavena) lze uhradit hotově
6
8. Pořadníky
8.1. Systém obsahuje řešení pro evidenci žádostí a jejich zpracování
8.2. Základním kritériem je dojezdová doba do obce bydliště, přepočtená na body (obvykle 1:1, ale není to podmínkou). Dalším ne jediným kritériem je prospěch, který je importován ze studijního systému STAG.
8.3. Lze definovat libovolné množství dalších kritérií (typu ANO/NE i číselných), které mohou být bodově ohodnoceny, popř. mohou procentuálně upravovat body za dojezdnost (lze tedy např. říci, že u držitelů průkazu ZTP se dojezdové body násobí dvěma)
8.4. Velmi flexibilní poloautomatické zpracování žádostí umožňuje žádosti postupně uspokojovat (v tzv. kolech) resp. zamítat dle bodů i dle jednotlivých kritérií (lze tedy např. přednostně uspokojit klienty s průzem ZTP bez ohledu na jejich bodové ohodnocení)
8.5. Systém umožňuje definování kapacity, která má na jednotlivých ubytovacích zařízeních zůstat volná pro jiné/pozdější využití (typicky např. v prvních kolech se nechává kapacita pro budoucí první ročníky, popř. pro studenty výměnných programů atp.)
8.6. Systém automaticky hlídá, aby v jednom pokoji (resp. buňce) nebyli ubytovaní muži a ženy současně (je však možné, aby takové ubytování zadala explicitně obsluha)
8.7. Klienti mohou podávat žádosti a dělat veškeré úkony (výběr preferované koleje, alokace konkrétního pokoje, podpisy smluv, atp.) prostřednictvím webového rozhraní (viz níže)
9. Evidence poštovních zásilek
9.1. Evidence doručených poštovních zásilek pro ubytované klienty
9.2. E-mailová/nebo SMS-ková notifikace o doručené zásilce
9.3. Informace o doručené zásilce je zobrazena i ve webovém rozhraní
10. Směnárna
10.1. Systém obsahuje řešení obousměrné směnárny
10.2. Směnu lze uskutečnit v jednom kroku společně s platbou
10.3. Obsahuje veškeré sestavy pro účetnictví i kontrolní orgány
10.4. Směna není omezena jen na ubytované klienty
10.5. Automatické načítání kurzů ze zvolené banky včetně úpravy kurzu s ohledem na obchodní marži
10.6. Tisk kurzovního lístku pro zveřejnění klientům
11. Vazba na ekonomické systémy
11.1. Systém vystavuje tyto typy dokladů:
7
a) Faktury
b) Vnitrofaktury
c) Doklady o použití
d) Faktury placené v hotovosti
e) Doklady na přijatou platbu
f) Dobropisy
g) Zjednodušené daňové doklady (daňové doklady v předpisu)
h) Příjmové pokladní doklady
i) Výdajové pokladní doklady
j) Vratky
11.2. Vzhled dokladů je uživatelsky plně konfigurovatelný
11.3. Doklady g-j jsou určeny pro tisk na znakové tiskárně na doklady
11.4. Systém uchovává o dokladu
a) Souhrnné údaje (částka s a bez DPH, odběratel,…)
b) Vzhled dokumentu - lze kdykoliv vystavit duplikát
11.5. Každý typ dokladu může mít samostatnou číselnou řadu
11.6. Několik různých typů dokladů může sdílet stejnou číselnou řadu
11.7. Číslování dokladů probíhá automaticky, řada je nepřerušená
11.8. Systém umožňuje zobrazit náhled dokladů před uložením (lze potlačit)
11.9. Vystavený doklad nelze vymazat, lze jej ale
a) Označit jako zrušený a na služby vystavit jiný doklad (s dalším číslem)
b) Xxxxxxxxx, tj. vystavit dobropis k dokladům a-d, vratku k dokladu g
11.10. Doklady a-f chceme přenášet do ES-Magion zadavatele.
11.11. Pro ostatní platby se přenášejí pouze souhrnná data. K tomu slouží sestavy:
a) Předpis plateb (pro odvod DPH a rozúčtování výnosů na střediska)
b) Úhrady pohledávek
c) Přehled nabíjení a vybíjení dle způsobů úhrad
d) Souhrn pohybů na účtu jistin
11.12. Systém poskytuje vestavěné sestavy
a) Předpis plateb hrazených fakturou v hotovosti
b) Rozúčtování plateb hrazených fakturou v hotovosti
c) Přehled tržeb dle zdrojů a středisek (bez ohledu na způsob úhrady)
d) Přehled vybrané hotovosti a plateb kartou dle uživatele
11.13. Systém zobrazuje stav
a) Jistin (k libovolnému datu)
b) Záloh (k libovolnému datu)
c) Pohledávek (k libovolnému datu)
d) Sumy položek k fakturaci, které dosud nebyly vyfakturovány (aktuální stav)
12. Vazba na bankovní systémy
12.1. Systém umožňuje načtení elektronického výpisu z účtu ve všech běžných bankovních formátech
8
12.2. Systém provádí párování načtených plateb
a) Systém umožňuje ruční provedení i opravu párování
12.3. Systém generuje inkasní příkazy
a) Lze vystavit inkasní příkazy různým bankám
b) Lze zvolit, klienti kterých bank mají být obsaženi v příkazu
c) Systém umožňuje zobrazit data příkazu před uložením
d) Export do všech běžných bankovních formátů
13. Vazba na další systémy
13.1. Systém je vybaven možností importu těchto dat
a) Osobní údaje klientů IDM, CRO
b) Údaje o firmách z ES Magion
c) Další importy jsou předmětem STAG (uchazeči)
13.2. Export dat pro cizineckou policii (formát UNL)
13.3. Případné exporty do jiných systémů jsou předmětem implementace Stag (informace o ubytování)
13.4. Program obsahuje přímé propojení s rezervačním systémem Xxxxxxx.xxx (jako jediný v ČR)
a) Automatické nabízení vybrané volné kapacity na serveru Xxxxxxx.xxx
b) Automatické aktualizace cen za ubytování (včetně možnosti akčních cen a sezónních cen při zvýšeném zájmu o ubytování (např. velikonoční svátky))
c) Automatický on-line přenos rezervace z Xxxxxxx.xxx do ubytovacího programu
d) Automatický přenos storna/změny objednávky
e) Rezervace je přenesena kompletní včetně zadaných osobních údajů, údajů o platební kartě atp.
13.5. Program obsahuje napojení na platební bránu GoPay
a) Umožňuje on-line platby za ubytování (okamžitá úhrada dluhu odkudkoliv na světě)
b) Snadné složení ubytovací/rezervační kauce i pro zahraniční studenty (bez vysokých poplatků za zahraniční platby)
c) Uživatelsky volitelné způsoby úhrady zahrnují platby kartou, bankovní tlačítka českých bank, platby z PayPal účtu a další
d) Platbu přes GoPay je možné zpoplatnit a přenést tak náklady spojené
s touto službou na klienta (procentuální přirážka)
13.6. Systém obsahuje vazbu na mobilní brány (např. xxxx://xxx.xxxxxxxxxxx.xxx/) umožňující poslání SMS zpráv
a) Zprávy mohou být posílány jednotlivě i hromadně
b) Hromadné posílání zpráv je možné z libovolného přehledu ubytování (i uživatelsky definovaných)
c) Zaslání SMS může být klientovi zpoplatněno (typicky SMS upomínka dlužníkům)
d) Systém eviduje odeslané SMS volitelně včetně doručenek
13.7. Prostřednictvím webových služeb webového rozhraní je možné zpřístupnit konto klientů systémům třetích stran, realizovaná řešení zahrnují (tato řešení
9
a) Tiskové řešení SafeQ od firmy Ysoft umožňuje bezhotovostní řešení tisků a kopírování
b) Obchodní centrum platby za kurzy a skripta, propagační předměty
c) Některé studijní agendy řeší tímto způsobem poplatky za studium a platby v knihovnách.
d) Napojení tzv. tankomatů, tedy automatů pro vklad hotovosti zatím nemáme řešeno
14. Přehledy a sestavy
14.1. Systém je vybaven samostatným modulem, který umožňuje tvorbu sestav
14.2. Sestavy lze vytisknout a exportovat do XLS pro další zpracování
14.3. Vytvořené sestavy lze uložit pro jejich opětovné použití
14.4. Uložené sestavy lze sdílet mezi uživateli
14.5. V systému je předdefinováno několik desítek nejběžnějších sestav
15. Webové rozhraní
15.1. Součástí systému je webové rozhraní
15.2. Studenti VŠ objednatele se zpravidla ověřují prostřednictvím standardní autorizace dané VŠ (nemusí si tak pamatovat další heslo, je možný např.
„proklik“ z portálu studijního systému, atp).
15.3. Je možná i autorizace pomocí loginu a hesla evidovaného v systému
15.4. Existují i speciální zjednodušené autorizace např. pro studenty budoucích prvních ročníků (např. podle čísla přihlášky, atp., v závislosti na dostupných informacích z informačního systému STAG
15.5. Součástí webového rozhraní je i registrační formulář pro zcela nové klienty (mimo VŠ)
15.6. Autorizovaný uživatel má k dispozici náhled na veškeré operace, které se ho týkají, zejména:
a) Osobní údaje, s možností zadání/změny kontaktního e-mailu, čísla mobilního telefonu, čísla bankovního účtu.
b) Splatné i nesplatné pohledávky, veškeré platby
c) Přehled aktuálního a minulých ubytování i plánované budoucí rezervace, včetně možnost rezervaci vytvořit (je-li to povoleno a při splnění konfigurovatelných podmínek)
d) Žádosti o ubytování včetně možnosti je zadat, editovat a sledovat proces vyhodnocení
e) Elektronicky podepisovat ubytovací smlouvy
f) Uhradit dluh nebo kauci on-line (při propojení s platební bránou GoPay, viz 13.5)
15.7. Systém obsahuje možnost náhledu na volnou kapacitu
15.8. Kromě rezervací jednotlivců existuje i možnost zadání objednávky zejména pro komerční ubytování
15.9. Součástí webového rozhraní je i sada webservice pro napojení na systémy
10
11
Stravovací systém
1. Úvod
Tento dokument obsahuje zadávací dokumentaci k modulu Stravování informačního systému.
Systém je určen primárně pro evidenci výdeje stravy, k tomu ovšem nutně patří další
činnosti, jako je doplňkový prodej, systém objednávek, evidence identifikačních průkazů – všechny tyto činnosti modul zajišťuje buď sám, nebo využívá služeb jiných částí tohoto informačního systému.
Jednotlivé kapitoly jsou provázané a o některých vlastnostech systému se hovoří na více místech. Na některých místech může proto dojít k zdánlivému nesouladu textu – např. věta
„Strávníkem může být kdokoli“ je v rozporu s omezeními vyplývajícími z blokace karty. Proto platí vždy ta nejvíce omezující podmínka (zde tedy ta o blokaci karty).
2. Strávníci
• Strávník je označení toho uživatele systému, který odebírá stravu. Strávníkem může být více osob (pokud používají společně kartu/y).
• Strávníkem může být kdokoli.
• Strávník má v systému právě jedno konto. Není možné mít společné konto pro více strávníků, je ale možné rozlišovat odběry podle jednotlivých karet (viz kapitoly Ceny,Výdej a Vstupy a výstupy).
• Systém umožní pracovat s anonymními strávníky – strávníky, kteří mají kartu, ale nejsou známy jejich osobní údaje
• Systém neřeší problematiku zákona č. 101/2000 Sb. nad rámec toho, že zpřístupní osobní informace v systému právě osobám oprávněným se systémem pracovat
• Systém podporuje hotovostní strávníky – strávníky, kteří nemají žádnou kartu
• Strávníky eviduje společná část systému, je tedy společný s ostatními moduly (např.s Ubytováním)
A. Karty
• Karta je libovolný prostředek, kterým se strávník identifikuje (nejčastěji čipová karta).
• Typy karet (z hlediska použité technologie) shrnuje kapitola Způsoby identifikace strávníků
• Strávník může mít více karet
• Platnost karty může být časově omezena
• Systém musí umožnit zablokování a odblokování karty.
• Pro usnadnění některých operací (zejména tvorby vyúčtování) dělí systém karty do skupin, zpravidla podle příslušnosti k odběrateli.
• Platnost skupiny karet lze omezit na část organizační struktury systému (provoz či nákladové středisko).
• Systém bude evidovat výdej karet
• Systém umožní pravidelnou aktualizaci databáze karet (nebo její části) z externího zdroje (bude-li tento přístupný a zdokumentovaný).
B. Způsoby identifikace strávníků
• čipová karta
• průkaz s čárovým kódem
• stravenka s čárovým kódem (nepřímá identifikace)
• bez identifikace („cizí“ strávník)
12
• ověření třetí stranou (při přístupu přes virtuální terminál)
• systém umožňuje použít i jiné ověření strávníka (biometrický údaj, ...). Podmínkou je
• funkční připojení čtečky k pracovišti (COM, USB+ovladače) a specifikace
• komunikačního protokolu.
• V systému je možné použití více metod současně
C. Objednávky a podobjednávky
• Informaci o podmínkách výdeje stravy váže systém na objednávky a podobjednávky
• Objednávka má jednu a více podobjednávek2
• Podobjednávka určuje Ceník3,Příspěvky na stravu4, Omezení příspěvků a výdeje5
2 Příklad – provozovatel systému uzavře smlouvu s firmou Jedlik s.r.o., na základě té zadá obsluha do systému objednávku. Provozovatel bude poskytovat zaměstnancům stravu za běžných podmínek (jedna podobjednávka), zatímco vedení firmy a jejím VIP zákazníkům za podmínek jiných (druhá podobjednávka)
3 Jeden ceník může (a bude) sloužit pro více různých podobjednávek
4 Příspěvky jsou samy o sobě evidovány bez vazby na plátce, uvádí se jen jejich výše (vizte kapitolu Ceny, podkapitolu Příspěvky na stravu). Teprve v kombinaci s podobjednávkou je uveden plátce příspěvku.
5 Omezení příspěvků i výdeje jsou opět evidovány samostatně a poté přiřazovány podobjednávkám
13
3. Terminály
• Terminál – zařízení na místě, kde dochází k interakci strávníka a systému. Zařízení komunikuje se systémem a zobrazuje odpovídající informace z něj a/nebo informace do systému vkládá, upravuje je v něm a/nebo maže. Terminál může provádět jen některé z uvedených aktivit (komunikuje vždy).
• Terminál má jednu nebo více z těchto základních funkcí:
o Pokladna – umožňuje strávníkovi složit peníze na konto a čerpat z něj. K tomu je schopna identifikovat strávníka či objednávku stravy (stravenku).
o Výdejní místo – slouží ke kontrole, zda je možno stravu strávníkovi vydat (např. zda strávník odebírá stravu, kterou si objednal) a k evidenci výdeje. Umožňuje identifikovat strávníka i objednávku stravy (stravenku).
o Objednávkový terminál strávníka – umožňuje zadávat a rušit vlastní objednávky, používat burzu stravenek. Umožňuje tisk stravenek.
o Objednávkový terminál obsluhy – umožňuje zadávat, prohlížet a vyúčtovat objednávky strávníkům, kteří se u terminálu identifikují6. Umožňuje tisk stravenek.
o Prohlížení jídelníčku – zobrazuje jídelníček na aktuální den, umožňuje-li to hardware pak i na jiné, uživatelem vybrané dny7.
o Správa konta strávníka – umožňuje strávníkovi zobrazovat stav konta a přehled odběrů za zvolené období.
o Virtuální terminál – webová stránka s funkcemi objednávkového terminálu strávníka, prohlížení jídelníčku a správu konta strávníka.
o Správa – umožňuje veškeré činnosti systému včetně funkcí uvedených v kapitole Správa
A. Podporovaná periferní zařízení
• Systém bude určitě pracovat s těmito zařízeními:
o Čtečka čipových karet
o Čtečka čárového kódu
o Terminál platební karty
o Elektronická váha
o Elektronická pokladna (displej, šuplík, tiskárna)
• Tiskárna dokladů
6 Typické zařízení – přenosný terminál obsluhy restauračního provozu.
7 Tabule na výdejně bude typicky zobrazovat denní jídelníček, webový prohlížeč umožní vybrat den pro zobrazení jídelníčku
14
4. Strava
Strava – jakákoli položka, jejíž tok (výdej) bude systém sledovat. Nejedná se nutně o potravinu
• Systém bude sledovat výdej stravy – kdy, kde, komu a za jakou cenu byla strava vydána.
• Systém bude evidovat výdej stravy v běžných jednotkách – v kusech (nejčastěji), v litrech a v kilogramech
• Ve spojení s elektronickou váhou (ale i bez spojení) bude systém schopen vydávat po
částech měrné jednotky (např. uzeniny či saláty)8
• Systém umožní vést jako jednu položku výdeje i více fyzických věcí současně (např. menu – polévka, hlavní jídlo a nápoj)
• Systém bude odlišovat různé skupiny stravy – zejména pro účely zpřehlednění výdeje.
• Skupiny stravy budou mít hierarchickou (víceúrovňovou) strukturu9.
X. Xxxxxxxxxx
• Systém bude umožňovat tvorbu a správu jídelníčků
• Jídelníček bude obsahovat položky výdeje s časovou platností doby vydávání či bez ní (např. den, týden, stále). Časová platnost položky se uvádí ve dnech.
• Jídelníčku bude možno přiřadit kategorii, seznam kategorií bude hierarchický a bude možno jej rozšiřovat a upravovat. Bude rovněž možno používat kategorie z modulu Sklad.
• Jídelníček se bude vztahovat na jeden provoz. Pro jiné provozy půjde zkopírovat.
• Položku jídelníčku bude možno zařadit jako tzv. společné jídlo k jiné položce, tzv. hlavnímu jídlu – společná jídla bude možno vydávat pouze s hlavním jídlem. Příklad – polévku je možno vydat pouze s hlavním jídlem.
• Při pokusu o odběr společného jídla bez jídla hlavního zobrazí systém varování, odběr však umožní. Řešení situace je na obsluze.
• Jídelníček bude možno vytvářet ve více jazycích, u zobrazení bude možno vybrat jazyk či zobrazovat více jazyků současně. Jeden jazyk je hlavní, systém podporuje zadat přes dvě stě jazyků jídelníčku.
8 Tj. části kil a litrů jako 24dkg salátu, nikoli kusů (půl rohlíku)
9 Skupiny stravy budou společné s modulem Sklad, změny bude možno provádět v něm
15
5. Cena
• Systém bude evidovat různé ceníky (kategorie cen)
0
• Ceník bude společný vždy pro celou podobjednávku1
• Více podobjednávek může používat stejný ceník
• Systém může být provozován jako limitní či jako bez-limitní
• Ceník bude přiřazovat každé stravní položce vzorec (v případě limitního způsobu provozu bude vzorec konstantní, v případě bez-limitního bude záviset na každé vydávané položce11).
• Položky bez definované ceny (bez vzorce) nebude možno strávníkům (patřícím do podobjednávek používajících tento ceník) vydat.
• Ceník bude možno měnit v čase, bude si uchovávat historii změn.
• Systém bude podporovat hromadné nastavování cen (pro celou skupinu stravy, pro všechny vybrané položky, apod.)
• Cena jídla je platná v době objednávky, v bezobjednávkovém provozu v době výdeje.
• Změna ceny položky po objednání stravy nebude mít vliv na objednanou stravu12
• Systém nebude (nemůže) řešit situaci, kdy je cena stravy známa až po provedení objednávky. Pro kombinaci bezlimitního a objednávkového provozu je proto silně doporučen modul Normování.
3
• V bezlimitním bezobjednávkovém provozu bude systém podporovat fixaci ceny – ve stanoveném období se prodejní cena nezmění, pokud se neodchýlí o danou část od první či předchozí ceny v období.1
A. Příspěvky na stravu14
• Systém bude evidovat příspěvky na stravu.
• Výše příspěvku bude zadána vzorcem – bude to buď fixní částka nebo proměnná část ceny odebírané stravy.
• Systém bude schopen pro každý příspěvek a každou podobjednávku sledovat:
5
o Plátce příspěvku (strávník, firma, provozovatel1 , dodatečné určení16)
o Na jakou stravu lze příspěvek použít
o Jak často je možno příspěvek poskytnout (nejvýše N za období – den, týden, měsíc; maximálně N-krát počet pracovních dní příspěvků v měsíci). Systém
podporuje více kritérií, při stanovení více než jednoho musí být splněna všechna.
• Systém umožní poskytnutí více příspěvků na jeden odběr současně
B. Konto a platby
• Veškeré transakce se zúčtují vůči kontu strávníka
• Konto lze dobíjet hotovostně nebo platební kartou.
• Konto lze dobíjet i převodem či inkasem, pokud bude k dispozici soubor z banky ve zdokumentovaném formátu, který bude obsahovat údaje nutné k určení konta a částky.
• Pokladna umí zpracovat operace v hotovosti, platební kartou a srážkou z konta strávníka.
• Uživatel má možnost nastavit si preferovaný způsob dobíjení konta – v případě inkasa i podmínku, za které dojde k jeho provedení.
7
• Systém nebude umožňovat omezení horní hranice konta – při překročení zobrazí systém varování, situaci však musí řešit obsluha1 . Úroveň varování půjde nastavit pro
každou podobjednávku.
16
• Systém nebude umožňovat omezení dolní hranice konta – při přečerpání zobrazí systém varování, situaci však musí řešit obsluha (donutit strávníka k platbě). Úroveň varování půjde nastavit pro každou podobjednávku
10 Má-li strávník více karet, cena se může lišit podle toho, kterou z nich použije.
11 Pro bez-limitní způsob je silně doporučen modul Normování, bez tohoto modulu bude práce v bez-limitním způsobu stravování velmi náročná na obsluhu – bude nutné pro každé vyrobené jídlo zadávat cenu. Při použití modulu normování se vezme jako základ pro vzorec cena, za kterou se vynormuje.
12 Pokud někdo v lednu objedná jídlo na červen za 50Kč a v únoru se cena zvýší, strávník přesto v červnu odebere stravu za 50Kč
13 Řízek bude stát v pondělí a celý týden 22,50Kč, i když bude v úterý vyroben za 21,90, ve středu za 23,00
14 Příklad: máme dva příspěvky, „20 Kč“ a „50% z ceny“. Tyto příspěvky bude provozovatel poskytovat strávníkům spadajícím do podobjednávek (PodO.) 1,2 a 3, odeberou-li jídla Oběd 1 nebo Oběd 2 následujícím způsobem:
PodO. 1 – 20Kč na Oběd 1, 50% na Oběd 2 PodO. 2 – 20Kč na Oběd 1 i Oběd 2
PodO. 3 – 50% na Oběd 1 i Oběd 2
Systém bude evidovat 2 příspěvky, jejich přiřazení položkám a plátce bude záležitostí podobjednávek (systém je samozřejmě bude evidovat také).
15 Půjde o slevu z ceny stravy
16 Nelze určit v okamžiku odběru – např. u odběrů stravy zaměstnanci
C. Vzorce
• Systém používá pro výpočet ceny stravy a výše příspěvku vzorce
8
• Vzorec je aritmetický výraz obsahující kromě čísel, operátorů a funkcí tzv. „klíčová slova“1
9
• Klíčová slova budou při výpočtu nahrazena číslem1 , poté bude vzorec vyhodnocen
• U vzorce je dále uvedeno zaokrouhlení – desetinné číslo, na jehož celočíselný násobek bude výsledek zaokrouhlen
• Ve vzorcích je možno použít:
0
o Klíčová slova [Cena], [DPH]2
o Funkce Min, Max
o Operátory + - × ÷
o Číselné konstanty
17 Systém to nemůže řešit, má-li být schopen přijímat na konto platby bankovním převodem
18 Příklady:
[Cena] * 1,1
Min(20,[Cena] * 0,5)
19 [Cena] je skladová cena položky (bez DPH)
[DPH] je násobitel pro aktuální sazbu DPH, tj. 1,0 1,05 nebo 1,19
20 Seznam klíčových slov je možno rozšířit
17
6. Výdej
• Systém musí umožnit strávníkovi s platnou kartou a kontem odběr.
• Systém musí zablokovat odběr bez platné katy a konta.
• Při identifikaci je strávník přiřazen k podobjednávce, na základě toho je potom určena cena, příspěvek (příspěvky) na stravu a omezení příspěvků i výdeje.
• Rozhodnutí o provedení transakce navzdory omezení je možno nechat na obsluze – každé omezení bude mít nastavení „tvrdé“ (omezení platí) nebo „měkké“ (obsluha může odběr povolit).
• Omezení konta budou definována pro podobjednávku, může tedy záležet na tom, jakou kartu strávník při odběru použije21
2
• Je-li na provoze definován jídelníček, systém umožní odebrat stravu z platného jídelníčku. V případě pokusu o odběr stravy která není v jídelníčku na tomto provoze, systém nechá rozhodnutí o povolení odběru na obsluze.2
3
• Systém umožní evidovat odběry dodatečně (např. u zaměstnanců zařízení). Oprávnění zadávat odběr dodatečně bude mít pouze vybraná skupina uživatelů2 .
• Systém umožní oprávněnému uživateli stornovat vybraný odběr. Oprávnění stornovat odběr bude rovněž povoleno pouze vybrané skupině uživatelů.
A. Objednávkový provoz
• Systém bude umět pracovat i v čistě objednávkovém režimu.
• Systém bude umět přijímat objednávky na stravu
• Systém přijme objednávku právě jen na stravu, která je v jídelníčku na zvolený den
• Systém umožní omezit počet objednávek (například počtem položek na skladě)
• Provedení objednávky strávníkem je považováno za okamžik uskutečnění zdanitelného plnění.
• Při provedení objednávky se cena stravy strhne z uživatelova konta.
• Systém zajistí kontrolu správnosti odběru a umožní vydat pouze stravu, kterou si strávník objednal.
• Systém může podporovat systém pro tisk stravenek s čárovým kódem, stejně jako zařízení pro jejich čtení
• Systém umožní zrušení objednávky
• Systém umožní nastavit dobu, po kterou lze objednávku zrušit.
1. „Burza“ stravenek
• Systém umožní vést „burzu“ stravenek – seznam objednávek, které nelze zrušit, ale které původní strávník nebude moci odebrat.
• Stravenku nabídnutou do burzy může jiný strávník koupit za cenu platnou pro něj (nového strávníka) v okamžiku nákupu.
• Neprodanou stravenku lze z „burzy“ stáhnout.
• Systém nebude evidovat historii prodeje stravenek přes „burzu“.
21 Může nastat situace, že mu bude na jednu kartu odběr zakázán, ale na jinou povolen
22 Obsluha např. vydá 101 porcí stravy, která byla v jídelníčku pouze ve 100 porcích a vydáním sté porce tedy z jídelníčku zmizí
23 Typicky pouze provozním menz a pracovníkům reklamačního oddělení
18
B. Bezobjednávkový provoz
• Systém bude umět pracovat i v čistě bezobjednávkovém režimu.
• V tomto režimu strávník nejprve odebere stravu, poté se identifikuje systému. V okamžiku identifikace určí systém cenu a zda je možno stravu vydat. Pokud ano,
strávníkovi je odběr potvrzen a cena stržena ze strávníkova konta. Pokud ne, obsluha musí strávníka přimět k vrácení stravy a odběr zrušit.
• Okamžik potvrzení odběru je okamžikem uskutečnění zdanitelného plnění.
• Systém umožní v případě nemožnosti vydat stravu z důvodů omezení buď
o Nevydat stravu, nebo
o Vydat stravu bez příspěvku (strávník hradí plnou cenu)
o Vydat stravu podle ceníku pro hotovostní strávníky
• Správce může určit, že je možná pouze některá z uvedených variant
C. Kombinovaný objednávkový a bezobjednávkový provoz
• V kombinovaném provozu zajistí systém jak funkčnost objednávkového systému tak bezobjednávkového
• Navíc zajistí rezervaci jídel strávníkům, kteří si jídla objednali
• Je-li zbývající počet jídel menší, než počet dosud nevydaných objednaných jídel, zobrazí systém při pokusu o odběr objednané stravy strávníkem bez objednávky varování. O vydání či nevydání stravy rozhodne obsluha. Tato funkčnost bude omezená v off-line režimu.
D. Restaurační provoz
• Speciálním případem kombinovaného objednávkového provozu je provoz restaurační
• Obsluha v tomto případě přijímá objednávky stravy podle jednotlivých stolů
• Objednávku je možno zaplatit po částech (každý host svoji část účtu)
• Systém lze pro zrychlení dovybavit kuchyňskou tiskárnou objednávek
E. Offline provoz
• V případě přerušení spojení mezi databázovým serverem a terminálem bude systém bez přerušení pokračovat v práci (přejde do off-line režimu). Systém bude off-line pracovat v omezeném režimu.
• Funkce systému v offline režimu je zaručena do konce dne. Další provoz v tomto režimu není garantován a je silně nedoporučen.
• Systém uživatele informuje o přechodu do off-line režimu, ale nebude vyžadovat jeho součinnost.
• V off-line režimu budou dostupné funkce terminálu Pokladna a Výdejní místo.
• Funkce terminálu Výdejní místo bude v offline kombinovaném provozu omezena – při více výdejních místech nemůže systém hlídat počty rezervovaných (vydaných) jídel.
• Dostupnost funkcí jiných typů terminálů není při přerušení spojení s databází zaručena.
19
7. Správa
• Uživatel je každý, kdo pracuje se systémem.
• Obsluha je uživatel, který není strávník.
• Systém eviduje a ověřuje ve vlastní režii uživatele, kteří s ním pracují pomocí aplikace.
• K ověření uživatelů přistupujících přes webové rozhraní využívá služeb webového serveru. Pro toto ověření poskytne systém rozhraní.
• Obsluhu dělí systém do skupin dle oprávnění
• Skupiny je možno vytvářet a měnit
• Uživatel je členem právě jedné skupiny
• Skupině i uživateli lze přidělit či odebrat oprávnění
• Oprávnění může měnit správce a uživatelé s patřičným oprávněním
• Oprávnění mohou být omezena na některý konkrétní terminál nebo na aktuální terminál
• Systém umožní uživateli právě ty činnosti, které odpovídají uživatelovým oprávněním v době pokusu o tyto činnosti.
• Změna práv probíhá při přihlášení a připojení k databázi, časová historie se nevede.
A. Seznam uživatelských oprávnění
• Evidovat odběry
• Zadávat odběry dodatečně
• Rušit odběry
• Vytvářet a měnit položky jídelníčku
• Cenotvorba, tj. vytváření a změna následujícíh objektů a jejich vzájemných vazeb
o Objednávek a podobjednávek
o Ceníků
o Příspěvků
o Omezení
• Nastavovat oprávnění
20
8. Vstupy a výstupy
X. Xxxxx na sklady a normování
• Systém bude při výdeji používat modul Sklady
• Při výdeji bude systém odepisovat zboží ze skladu
• Systém bude umožňovat export údajů o pohybech stravy v XML formátu
• Je-li nainstalován, bude systém používat modul Normování. Systém bude fungovat i bez modulu Normování.
• Normování bude automaticky vytvářet jídelníčky včetně počtu vydávaných jídel
B. Výstupní sestavy
• Informační systém (jeho společná část) umožní tisk
o dokladu pro každý odběr
o faktur příspěvků na stravu
o faktur odběrů (u pohybů neplacených srážkou z konta)
• Modul stravování umožní tisk sestav sumarizujících počty odběrů za zvolené období podle těchto kategorií:
o ceník
o firma
o podobjednávka
o typ karty
• Sestav sumarizujících tržby za zvolené období podle uvedených kategorií
• Systém bude obsahovat nástroj pro tvorbu uživatelských sestav
C. Import
• Systém bude schopen jednorázově či pravidelně importovat
o Seznam karet nebo jeho část
o Seznam firem
o Přehled nároků na příspěvky
D. Export
• Systém bude připraven pro export údajů do SAP – podmínkou pro funkčnost je součinnost implementátora SAP (poskytnutí formátu vět).
• Systém bude umožňovat export souhrnných sestav do .xml a .xls formátu
• Systém může umožňovat export těchto sestav i do databázové tabulky
X. Xxxxxxxxxx srážek ze mzdy
• Systém bude umožňovat import podkladů pro srážky ze mzdy (tzv. nároky) ze mzdové agendy.
• Na základě tohoto importu a údajů o odebrané stravě systém určí částku, která se má vyžadovat po klientovi – zaměstnanci – formou srážky ze mzdy.
9. Podpora
• Součástí předání systému je instalace u zákazníka
• Součástí předání systému je zaškolení uživatelů
• Reklamace bude řešit smlouva o dílo
• Rozšíření systému se budou řídit (budoucí) smlouvou o podpoře, případně dalšími smlouvami.
21
10. Evidované údaje
X. Xxxxxxx odběru
Jedna účtovatelná položka odběru, například polévka, menu, apod.. Zobrazuje se v jídelníčku, přiřazuje se jí cena (vizte ceníky).
• Zkratka
• Název
• Kategorie
• Je odebíráno?
• Je vydáváno?
• Jde-li o složený odběr (menu)
o Seznam položek a variant
• Je-li jídelníček vytvářen ve více jazycích
o Název v každém z použitých jazyků
B. Odběr
Informace o jednom konkrétním odebrání položky odběru, které je někomu (nejčastěji strávníkovi) naúčtováno
• Datum
• Karta
• Terminál
• Položka odběru
• Počet
• PodObjednávka
• Je zadáno dodatečně?
• Zadal
• Zadáno
• Je vydáno v určené sazbě DPH?
• Sazba DPH
• Je to odběr objednané stravy?
• Objednávka stravy
• Je to stornující odběr?
• Stornovaný odběr
• Jde-li o složený odběr (menu)
o Seznam skutečně odebraných položek
C. Objednávka stravy
V objednávkovém provozu si strávníci objednávají stravu – o objednávce stravy se evidují tyto údaje:
• Karta
• Položka jídelníčku
• Objednáno
• Provoz
• Datum odběru
• Je strava nabídnuta v burze?
• Je strava odebrána?
• Kdy odebráno
• Je zrušena?
• Kdy zrušeno
22
X. Xxxxxxxxxx
Seznam a obsah všech jídelníčků
• Položka odběru
• Platí od
• Platí do
• Provoz
• Počet porcí
• Vydáno porcí
• Pokud jde o společné jídlo (jídlo vydávané pouze k jinému jídlu)
o Seznam položek odběru, ke které je možno tuto položku jídelníčku vydat
E. Objednávky
Objednávky (nikoli stravy) – organizační záležitost, údaje o dohodě se strávníkem, že bude odebírat stravu
• Popis
• Datum od
• Datum do
• Seznam podobjednávek
F. Podobjednávky
Upřesnění konkrétních podmínek výdeje stravy, opět v obecné rovině. Jedna objednávka může mít více podobjednávek, mohou používat různé ceníky či s jiné příspěvky či omezení.
• Popis
• Datum od
• Datum do
• Ceník
• Typ identifikace strávníka
o Kartou
o Osoba (nejvýše jedna podobjednávka na osobu)
o Firma (nejvýše jedna podobjednávka na firmu)
• Seznam příspěvků
• Seznam omezení
X. Xxxxx
Ceník přiřazuje cenu položkám odběru. U každého ceníku se budou evidovat následující údaje:
• Zkratka
• Název
• Poznámka
• Seznam položek
H. Položky ceníku
Položka ceníku je v podstatě přiřazení ceny a časové platnosti položce odběru (v daném ceníku)
• Položka odběru
• Vzorec pro výpočet
• Platnost od
• Zadáno
• Zadal
23
• Zrušeno
• Zrušil
I. Příspěvky
Eviduje příspěvky – pouze seznam názvů a velikostí, přiřazení k odběrům je věcí podobjednávky
• Zkratka
• Název
• Vzorec
• Kategorie
• Je účtován později (např. u odběrů zaměstnanců, kdy se v okamžiku odběru neví, zda bude odběr v limitu)?
J. Omezení
Eviduje omezení – opět pouze seznam, jehož položky jsou přiřazovány konkrétním podobjednávkám
• Počet odběrů
• Časový interval
• Poznámka
• Kategorie
K. Vzorce
Seznam vzorců. Vzorec může obsahovat „proměnné“ (např. [Cena]) v aritmetickém výrazu. Přiřazení vzorců položkám odběru je záležitost ceníku
• Zkratka
• Název
• Vzorec
• Zaokrouhlení
• Poznámka
• Kategorie
24
Sklady
1. Úvod
Modul Sklady je určen k evidenci skladového hospodářství – umožňuje evidovat příjmy a výdeje ze skladu, buď na jiné sklady v systému nebo externím subjektům. Evidenci dodavatelů a odběratelů sdílí celý systém. Systém umožňuje i běžné skladové činnosti jako je inventura, uzávěrka a tisk potřebných sestav (karta boží, stav skladu, seznam dokladů, podklady pro zaúčtování).
2. Terminály
• Terminál je zařízení na místě, kde dochází k interakci uživatele a systému.
• Terminál má jednu nebo více z těchto základních funkcí:
o Výdej/příjem – umožňuje evidovat příjem a výdej zboží. Pracuje s čtečkou čárového kódu a elektronickou váhou.
o Provoz – umožňuje dělat inventury a uzávěrky a tisknout souhrnné sestavy
o Správa – umožňuje veškeré činnosti systému včetně vytváření a tisku sestav
• Systém bude na každém terminálu jako výchozí nabízet provoz, pod který terminál patří
A. Podporovaná periferní zařízení
• Systém bude pracovat s těmito zařízeními:
o Čtečka čárového kódu
o Elektronická váha
o Tiskárna
3. Skladové položky
• Systém bude evidovat komodity. Komodita je jeden konkrétní druh evidovaných entit, např. hovězí maso přední, hrášková polévka s uzeninou apod..
• Systém bude evidovat skladové položky. Skladová položka je jedno konkrétní balení komodity – např. mouka hladká á 50kg, rajský protlak á 3,5kg apod.1.
• Pro jednu komoditu může být více skladových položek
• Pohyb na skladě je evidován podle skladových položek
X. Xxxxxxxx
• Systém bude pracovat s běžnými jednotkami (kg, ks, l)
• Systém nebude podporovat převody jednotek
B. Kategorie skladových položek
• Každá evidovaná komodita bude mít přiřazenu kategorii.
• Systém kategorií bude hierarchický – např. kategorie Maso se bude dále dělit na kategorie Hovězí, Vepřové, ….
• Komoditě půjde přiřadit pouze nejkonkrétnější kategorie ve struktuře – např. Maso hovězí přední bude v kategorii Maso hovězí, nikoli pouze Xxxx.
• Každá kategorie bude mít svůj kód.
• Kód kategorie bude respektovat strukturu – bude-li kód kategorie Maso 02, pak kód kategorie Maso hovězí bude např. 0201, Maso vepřové 0202, apod..
25
• Kód bude mít i komodita. Kód komodity bude rovněž respektovat strukturu.
• Podle kódu komodity půjde vyhledávat.
C. Čárový kód
• Systém bude podporovat čárový kód skladových položek.
• Jedna skladová položka bude moci mít více čárových kódů
• Systém bude připraven pro jiné podobné metody identifikace skladových položek, např. RFID.
4. Sklady
• Systém umožní evidovat ke každému provozu jeden a více skladů. Provozy eviduje společná část systému, sklady tento modul.
• Sklad může pracovat v režimu průměrných cen nebo FIFO. Každý sklad může pracovat v libovolném režimu, režim lze změnit.
A. Inventury
• Inventura je srovnání stavu skladů v systému s reálným stavem
• Inventura probíhá ve třech krocích – zahájení, provedení, potvrzení.
• Při zahájení zamyká inventura sklad k datu inventury2.
• Nepotvrzenou inventuru je možno zrušit. Systém o tom povede záznam. Ke zrušení musí mít uživatel oprávnění.
• Potvrzení inventury je možno zrušit. Systém o tom povede záznam. Ke zrušení musí mít uživatel oprávnění.
• Systém rozeznává dva druhy inventur – řádné a mimořádné. Toto rozdělení je čistě
pro přehlednost, oba druhy inventur jsou v systému rovnocenné
• Řádná inventura slouží k pravidelnému zjištění rozdílů na skladě, např. na prodejně.
• Řádná inventura může proběhnout k aktuálnímu datu, nebo k datu v minulosti.
• Mimořádná inventura slouží zejména pro kontrolu hospodaření, provádí se náhodně
• Mimořádná inventura může proběhnout pouze k aktuálnímu datu
• Uživatel, který zahájil inventuru, může zadat pohyb na inventarizovaném skladě i v období před datem inventury. Systém jej na tuto skutečnost upozorní3.
B. Uzávěrky
• Systém umožní provádění uzávěrky skladů
• Uzávěrka proběhne k aktuálnímu datu nebo datu v minulosti a uzamkne sklad k tomuto datu
• Uzávěrku je možno zrušit
• K provedení uzávěrky či k jejímu zrušení musí mít uživatel oprávnění
• Systém umožní tisk uzávěrkových sestav,
5. Pohyby na skladech
• Systém bude evidovat příjmy na sklad a výdej ze skladu.
• Systém bude evidovat pohyby na skladech a to jak externí tak interní. Externí pohyb je příjem od dodavatele nebo výdej odběrateli, interní je přesun ze skladu na sklad.
• Pro interní výdej systém automaticky vytvoří příjmový doklad na cílovém skladu. Systém bude volitelně požadovat potvrzení příjmu na cílovém skladě (tento požadavek půjde vypnout).
26
X. Xxxxxxx
• Systém bude pracovat v zásadě se čtyřmi typy dokladů – externí příjem, externí výdej, interní příjem a interní výdej.
• Pro zpřehlednění bude systém pracovat s řadami dokladů – pro jeden typ může existovat více řad (např. převodka a výdej do výroby pro interní výdej)
• Řada dokladů je určena typem dokladu, doklady v řadě jsou pak bez přerušení
číslovány v rámci roku, např. VYR06001, VYR06002, …)
• Doklad je po vytvoření nutno potvrdit, tím dojde k změně skladu podle tohoto dokladu. Po potvrzení dokladu v něm není možné nic měnit.
• Nepotvrzený doklad je možno smazat
• Doklad je možno stornovat – pohyby uvedené v dokladu se zruší (skladové položky se vrátí zpět na sklad nebo se z něj odepíší).
• Pohyby vyvolané stornem dokladu proběhnou k datu stornování4
• Storno dokladu zruší jeho potvrzení. Stornodoklady jsou potvrzené a nelze je stornovat
B. Zamykání skladu
• Systém umožní ke zvolenému datu (aktuálnímu nebo v minulosti) zamknout sklad.
• Zamykání bude probíhat pouze prostřednictvím operací inventura a uzávěrka (vizte předchozí kapitolu)
• Po uzamčení skladu není možné zadávat pohyby na tomto skladu s datem shodným nebo menším s datem zámku.
• O uzamčení skladu povede systém záznam, k provedení zamykající operace musí mít uživatel oprávnění.
• Výjimka – správce systému může nastavit, že uživatel provádějící inventuru může zadávat pohyby na inventarizovaný sklad
X. Xxxxxxxxxxx
• Do systému bude možno doimplementovat možnost evidovat datum naskladnění a exspirace skladových položek
• V případě výdeje pak bude systém nabízet k vyskladnění položky s nejkratší trvanlivostí. Uživatel bude moci vydat i jinou položku.
4 Storno dokladu vytvoří na skladě nový doklad (Stornodoklad), který bude mít opačný směr, jako stornovaný doklad a stejné položky.
27
6. Správa
• Systém umožní povolit/zakázat zadání pohybu inventarizujícímu na inventarizovaném skladě
• Systém umožní nastavit, zda bude nutné potvrzovat příjmy u interních převodů
• Bude-li implementována podpora exspirace položek, půjde zapnout/vypnout sledování jejich trvanlivosti
• Systém bude používat následující seznam uživatelských oprávnění
o Měnit seznam komodit a skladových položek
o Zadávat pohyby na skladě na vlastním provoze
o Zadávat pohyby na skladě na všech provozech
o Provést inventuru, zrušit potvrzení inventury
o Provést uzávěrku, zrušit uzávěrku
o Nastavovat oprávnění
7. Vstupy a výstupy
X. Xxxxx na ostatní moduly
• Modul bude poskytovat služby modulům Prodejna, Normování a Stravování
• Modul je připraven poskytovat služby i dalším, zatím neexistujícím modulům
• Tyto moduly budou měnit stav skladu a používat jména a strukturu komodit
• Sklad bude evidovat požadavky (rezervace) vzniklé v rámci těchto modulů
B. Výstupní sestavy
• U skladové položky bude systém zobrazovat její název, jednotku, balení, jednotkovou cenu bez DPH5, množství skladem a celkovou cenu bez DPH. Volitelně bude
zobrazovat rezervované množství, dostupné množství (celkem – rezervováno) a celkovou cenu dostupného množství.
• U souhrnu bude systém zobrazovat cenu a počet položek. U externího dokladu bude uvedeno rozúčtování DPH.
• Uváděné sestavy budou odpovídat sestavám v programu NormApS
• Systém bude tisknout následující sestavy:
• Uzávěrkové sestavy
o Stav skladu včetně položek a souhrnu
o Souhrn stavu všech skladů na provoze
• Inventurní sestavy
o Inventarizační seznam
o Stav po inventuře
o Souhrnný přehled
• Doklady
o Jeden doklad včetně položek a souhrnu
o Vybrané doklady včetně položek a souhrnu
o Souhrn dokladů na skladě za období
o Všechny doklady jedné řady na skladě za období
• Pohyby komodity
o Seznam dokladů, na kterých se komodita vyskytla, včetně množství a ceny
• Stav skladu – jako uzávěrkové sestavy
o Stav skladu k datu včetně položek a souhrnu
28
o Souhrnný stav všech skladů na provoze k datu
• Skladové karty
o Stav komodity na všech skladech (rozepsáno po skladových položkách)
5 U FIFO skladu budou položky rozděleny podle ceny, u skladu v průměrných cenách bude cena jedna
C. Import
• Systém umožní při nasazení jednorázový import stavu skladu z programu NormApS. Systém poskytne nástroj pro podporu importu seznamu komodit z programu
NormApS.
D. Export
• Systém bude umožňovat export souhrnných sestav do .xml a .xls formátu
• Systém může umožňovat export těchto sestav i do databázové tabulky
29
8. Evidované údaje
A. Sklad
• Zkratka
• Název
• Provoz
• Typ skladu
• FIFO/průměrné ceny
• Uzamčeno k datu
• Pořadí
B. Komodita
• Název
• Kategorie
o Kód
o Odkaz na rodiče
X. Xxxxxxxx položka
• Komodita
• Jednotka
• Balení
• Zaokrouhlení
X. Xxxxxxx skladem
• Sklad
• Skladová položka
• Cena
• Množství
• Poznámka
E. Doklad
• Číslo dokladu
• Datum vystavení
• Cena bez DPH
• Částka DPH
• Externí doklad
o Firma
o Dodací list
• Interní doklad
o Protisklad
o Protidoklad
• Položky
o Skladová položka
o Množství
o Jednotková cena bez DPH
o Jednotková částka DPH
o Sazba DPH
30
X. Xxxxxxxxx
• Sklad
• Datum provedení
• Datum inventarizace
• Kdo inventarizoval
• Při potvrzení
o Kdo potvrdil
o Kdy potvrdil
o Doklad manka
o Doklad přebytku
• Při zrušení
o Kdo zrušil
o Kdy zrušil
• Položky
o Skladová položka
o Přijato od poslední inventury
o Předpokládaný stav
o Skutečný stav
o Cena
X. Xxxxxxxx
• Sklad
• Datum provedení
• Datum uzavření
• Kdo uzavřel
• V případě zrušení
▪ Kdo zrušil
▪ Kdy zrušil
31
Normování
1. Terminály
• Terminál je zařízení na místě, kde dochází k interakci uživatele a systému.
• Terminál má jednu nebo více z těchto základních funkcí:
o Normování – umožňuje normovat a tisknout normy
o Provoz – umožňuje zadávat, měnit a tisknout receptury
o Správa – umožňuje veškeré činnosti systému včetně vytváření a tisku sestav
• Systém bude na každém terminálu jako výchozí nabízet provoz, pod který terminál patří
A. Podporovaná periferní zařízení
• Systém bude pracovat s těmito zařízeními:
o Tiskárna
32
2. Receptury
• Receptura je předpis výroby výrobku z jedné či více surovin
• Receptura eviduje u každé suroviny množství potřebné na 100 kusů výrobku
• Množství se zadává v kg, ks nebo l.
• U každé receptury je možno mít několik hmotnostních norem, které se mohou lišit
složením i obsahem jednotlivých surovin
• Pro každou hmotnostní normu se eviduje výtěžnost
3. Normy
• Norma je konkrétní předpis pro výrobu podle zvolené receptury a hmotnostní normy
• U normy se určuje receptura, počet výrobků, hmotnostní normu, datum výroby, zdrojový a cílový sklad a konkrétní výtěžnost.
• Při vytvoření normy, nebo změně počtu výrobků či hmotnostní normy systém přepočítá potřebné množství surovin.
• Systém spočítá počet balení, je-li receptura zadána v kg resp. l a surovina je na skladě
v balení v kg resp. l.
• Suroviny a jejich množství uvedené v normě je možno měnit.
• U výrobků určených k výdeji/prodeji se zobrazí i prodejní cena.
• Za stanovení prodejní ceny zodpovídá modul Prodejna, je-li zakoupen, bude tato
funkčnost zpřístupněna i z Normování
A. Výroba
• Výroba je proces vyskladnění surovin a naskladnění výrobků
• Z uživatelského pohledu probíhá výroba ve třech krocích
o výroba (v Normování)
o potvrzení výdejky surovin (Sklad)
o potvrzení příjemky výrobků (Sklad)
• Výroba vytvoří výdejku surovin a příjemku výrobků.
• Normy je možno vyrobit hromadně podle kritérií (od, do, zdrojový, cílový sklad) a
výběrem
• Normu je možno vyrobit částečně. Částečným vyrobením se norma rozdělí na dvě
normy – vyrobenou a nevyrobenou.
Pro jeden den, zdrojový a cílový sklad vznikne jedna výdejka surovin pro všechny normy. Obdobně vznikne příjemka výrobků.
• Potvrzení výdejky surovin provede uživatel v modulu Sklad. Před potvrzením
je
možno výdejku měnit. Změny výdejky se promítnou v příjemce výrobků.
• Systém umožní zobrazit rozdíly mezi vynormovaným a vydaným množstvím surovin
• Příjemku výrobků je nutné potvrdit. V systému lze nastavit, že se potvrzuje
33
automaticky s výdejkou surovin
• Jednotlivé kroky výroby je možno stornovat v opačném pořadí, než proběhly. Stornopohyb na skladu vznikne k datu storna, o stornování se povede záznam. Ke stornování je nutno mít oprávnění
B. Normování pro jiný provoz
• Normování umožní zjednodušit výrobu s následným přesunem (normování + převodka) a přesun s následnou výrobou (převodka + normování) při normování na
jiný provoz
• Normování v prvním případě vytvoří normu a vzniklé výrobky pak převede na další
sklad, v druhém převede suroviny a na cílovém skladě vytvoří normu
• K vytvoření převodky dojde při výrobě normy, při úpravě výdejky či příjemky se
upraví i převodka
• Tato funkce nahradí Dovářky z programu NormApS
• Tuto činnost lze samozřejmě udělat pomocí standardní převodky a normování, tato
funkce to pouze zjednodušuje do jednoho kroku
4. Správa
• V systému lze nastavit,
o zda je možné měnit příjemku výrobků
o zda bude potvrzení výdejky potvrzovat i příjemku surovin
• Systém bude používat následující seznam uživatelských oprávnění
o Normovat
o Vyrábět normy
o Odvyrábět normy
o Měnit receptury
5. Vstupy a výstupy
X. Xxxxx na ostatní moduly
• Sklady
o Tvorba
• Stravování
o Při vytvoření normy dá Normování pokyn Stravování k vytvoření jídelníčku
o Před vytvořením normy zobrazí Normování seznam nevyformovaných položek
jídelníčku
B. Výstupní sestavy
• Seznam norem podle zadaných kritérií (od, do, dle zdrojového a cílového skladu,
vyrobené / nevyrobené). Tiskne se
o Název a číslo normy
o Datum výroby
34
o Zdrojový a cílový sklad
o Množství
o Výrobní cena
o Skutečná výtěžnost
• Seznam norem se surovinami. Stejné možnosti výběru jako u předchozí sestavy, navíc
je každé normy seznam surovin. Navíc se tiskne seznam surovin, který obsahuje:
o Název a kód položky
o Jednotku a balení
o Množství požadované recepturou a vynormované
• Výčetka surovin podle stejných kritérií. Výčetka zobrazí seznam surovin, které se mají
vydat, nebude obsahovat informace o normách. Vytisknou se stejné údaje jako u
surovin v předchozím bodě.
C. Import
• Systém nebude importovat data z vnějších systémů
D. Export
• Systém bude umožňovat export souhrnných sestav do .xml a .xls formátu
• Systém může umožňovat export těchto sestav i do databázové tabulky
6. Evidované údaje
A. Receptura
• Komodita
• Provoz
• Hmotnostní norma
• Výtěžnost
• Poznámka
• Položky
o Komodita
o Množství
o Jednotky
B. Norma
• Komodita
• Název
• Počet porcí
• Hmotnostní norma
• Datum výroby
• Jednotková cena
• Číslo normodokladu
• Sklad surovin
• Sklad výrobků
• Skutečná výtěžnost
• Položky
35
o Skladová položka
o Množství dle receptury
o Použité množství
o Cena
C. Výroba
• Údaje o normách a jejich položkách (vizte předchozí podkapitolu)
• Odkaz na normu
• Odkaz na výdejku a příjemku, u položek na položku výdeje
• Počet vyrobených kusů
• Datum provedení
36
Harmonogram nasazení systému ISKaM4
Úkol Zodpovídá Termín
Příprava databáze, nastavení periodického překlápění dat z ISKaM 2008 Zhotovitel do 10.7.2016 Příjem specifických požadavků Objednatel do 10.7.2016
Nastavení základních parametrů systému Zhotovitel do 12.7.2016
Implementace specifických požadavků Zhotovitel do 29.8.2016
Instalace terminálů, uživatelé, oprávnění Objednatel do 21.8.2016 Zhotovitel,
Školení administrátorů Školení vedení
Školení provozních pracovníků
Objednatel do 23.7.2016 Zhotovitel,
Objednatel do 23.7.2016 Zhotovitel,
Objednatel do 26.8.2016
Předání programu Zhotovitel do 29.8.2016
Finální provoz Objednatel od 1.9.2016
Hardwarové a softwarové požadavky na systém ISKaM4
Dokument shrnuje minimální a doporučené konfigurace hardware a software pro provoz systému ISKaM4.
Všechny servery mohou být virtuální, Objednatel dokonce toto řešení preferuje z důvodů možného navýšení prostředků v budoucnu v případě potřeby.
Databázový - SQL Server hardware CPU: alespoň dvoujádrový procesor, nejlépe na úrovni Intel Xeon a výše RAM: čím více, tím lépe, protože pro SQL server je paměť důležitější nežli procesor.
Minimální konfigurace je: 4GB + 0,5GB/1000 lůžek + 2GB/100 tis. hlavních jídel ročně. DISK: určitě rychlé SSD disky a samozřejmě je zapojit do raid, aby byly redundantní.
Data budou postupně narůstat, navíc má Objednatel ze zákona povinnost je udržovat po dobu 10 let. Doporučená velikost paměti na disku je: 40GB+5GB/1000 lůžek + 18GB/100 tis. hlavních jídel ročně. Software Operační systém:
mininimálně Windows 2008 R2 server, doporučujeme poslední verze serverového operačního systému.
SQL Server: poslední verze SQL serveru, minimálně MS SQL 2008 server.
Plně postačuje edice Standard, nejsou potřeba jakékoli další doplňky typu Analysis Services, Reporting Services.
Webový server V praxi se z bezpečnostních důvodů nedoporučuje provoz webového serveru na stejném stroji, kde sídlí SQL server.
Pro běh IIS serveru není zapotřebí tak vysoká konfigurace jako u SQL serveru. 8GB paměti, disk postačí o velikosti cca 60GB.
Pro ISKaM4 je zapotřebí Microsoft Internet Information Server 7.0 a vyšší. Je standardní součástí OS Microsoft Windows 2008 Server.
Klientská stanice
Základní podmínkou pro klientskou stanici je běh .NET Frameworku 4.5.
Minimální konfigurace dle xxxxx://xxxx.xxxxxxxxx.xxx/xx-/xxxxxxx/0x0xxxxx%00xxxx.000%00.xxxx. Pro rozumný běh ISKaM4 konfiguraci:
hardware CPU - alespoň 2GHz RAM - 4GB Disk - alespoň 128GB
Monitor - 22„ a vyšší na těch pracovištích, které často pracují se štaflemi a ubytovacím průvodcem. software Windows 7 a vyšší dotykové monitory
Z pohledu ISKaMu4 je dotykový monitor kombinace monitoru a myši.
Obecně Objednatel doporučuje se zaměřit na stabilitu a robustnost konstrukce zařízení a kvalitu zobrazování.
Čtečky čipových karet ISKaM4 umí pracovat s běžnými čtečkami čipových karet - ať již sériovými či meziklávesnicovými (HID). Obecně sériové (dnes se již typicky sériové s konektorem na sériový port nevyrábí, hojně se však dodávají s USB konektorem a ovladačem, který sériový port emuluje).
Servisní smlouva
uzavřena dle zák. č. 89/2012 Sb., občanský zákoník ve znění pozdějších předpisů (dále jen občanský zákoník)
1. Smluvní strany
Západočeská univerzita v Plzni
se sídlem Univerzitní 8, 306 14 Plzeň
zastoupená doc. Dr. RNDr. Xxxxxxxxxx Xxxxxxxx, rektorem IČ 49777513, DIČ CZ49777513
veřejná vysoká škola, nezapisuje se do OR
bankovní spojení: Komerční banka a.s., Plzeň – město č. účtu: 4811530257/0100
(dále jen „Objednatel“)
a
ApS Brno, s. r. o.
se sídlem Božetěchova 2, 612 66 Brno
zastoupená Ing. Xxxxxxx Xxxxxx, jednatelem společnosti IČ: 00543535, DIČ: CZ00543535
zapsaný u Krajského soudu v Brně pod sp. zn. C 35 bankovní spojení: Komerční banka a.s., Brno – město č.ú.: 113545621/0100
(dále jen „Poskytovatel“)
2. Předmět smlouvy
2.1. Předmětem smlouvy je úplatné poskytování servisních úkonů nezbytných pro řádnou funkci informačního systému ISKaM4, dodaného na základě smlouvy o dílo ze dne 2016
(dále jen „smlouva o dílo“). Servisním úkonem není úprava software na žádost Objednatele, vyjma úpravy software v souvislosti se změnami právních předpisů, vyhlášených ve Sbírce zákonů ČR dle § 1 zákona č. 309/1999 Sb., o Sbírce zákonů a o Sbírce mezinárodních smluv, ve znění pozdějších předpisů.
2.2. Servisní smlouva se nevztahuje na úkony vyplývající ze smlouvy o dílo a na úkony činěné v rámci platné záruky stanovené zmíněnou smlouvou o dílo. Po uplynutí záruční doby přejdou předmětné úkony pod podmínky dané touto servisní smlouvou za cenu započtenou v měsíčním paušálu bez DPH uvedeném v čl. 6.1. smlouvy.
3. Výkon servisní činnosti
3.1. Úkony nepravidelné
3.1.1. Poskytovatel se zavazuje reagovat v přiměřené lhůtě na žádost Objednatele o odstranění vzniklých vad. S odpovídajícím servisním úkonem musí být započato od doručení požadavku v souladu s čl. 4 a 5 Přílohy č. 1 této smlouvy:
3.1.1.1. do 60-ti minut, v době mezi 8:00 a 16:00 pracovního dne, jinak do 9:00 následujícího pracovního dne, a to v případech urgentní povahy.
3.1.1.2. do 2 pracovních dnů v ostatních případech.
3.1.2. Poskytovatel bude poskytovat Objednateli nové verze ISKaM4 vzniklé na základě legislativních změn, verze vzniklé na základě odstranění vad nebo vyřešení požadavků Objednatele a aplikační SW, nahrazující stávající provozované aplikace. Poskytovatel dodá nové verze aplikací s příslušným popisem provedených úprav a aktuální dokumentací (uživatelská, administrátorská). Součástí těchto nových verzí je i jejich implementace u Objednatele, rozdílové školení administrátorů a klíčových uživatelů, pokud vzhledem k povaze změny bude nezbytné.
3.2. Úkony pravidelné
3.2.1. Strany sjednávají 1měsíční periodicitu pro soubor rutinních servisních úkonů, které mají zajišíovat provozuschopnost systémů. Tyto pravidelné servisní úkony zahrnují:
3.2.1.1. Třikrát týdně sledování bezpečnostních záznamů a detekce možných průniků do dodaného systému a zajištění okamžité nápravy při zjištění incidentu, pokud je závada důsledkem vady díla. V ostatních případech neprodleně upozorní na tuto skutečnost Objednatele.
3.2.1.2. Třikrát týdně sledování a analýza logu chyb a zajištění co nejrychlejší nápravy.
3.2.1.3. O bodech 3.2.1.1, 3.2.1.2 a 3.2.1.4 předávat Objednateli zprávy včetně protokolů (logů apod.) v případech nikoli rutinní povahy.
3.2.1.4. Aktualizace software. O změně verze a datu, ke kterému byla implementována spolu se stručnou charakteristikou nové funkcionality, bude Objednatel neprodleně informován elektronickou cestou.
3.2.1.5. Úpravy vyplývající z legislativních změn.
3.2.1.6. Poradenská činnost při nastavení systému, využití nových funkcí vycházejících ze
„servisních upgradů“,
4. Termín plnění
4.1. Termín zahájení servisní podpory plynně navazuje na termín plnění s dodávkou a implementací ISKaM4 ze smlouvy o dílo, tj. servisní úkony budou zahájeny prvého dne předání a převzetí implementovaného softwaru ze smlouvy o dílo, nejpozději však ode dne 1. 9. 2016.
5. Součinnost smluvních stran
5.1. Objednatel musí co nejpřesněji popsat charakter a projevy zjištěné vady a tyto skutečnosti zaznamená v souladu s čl. 4 a 5 přílohy č. 1 této smlouvy.
5.2. Při následném dálkovém kontaktu s Poskytovatelem musí Objednatel zajistit realizaci pokynů Poskytovatele a poskytnout mu vzdálený přístup k systému, bude-li o to požádán.
5.3. Prioritu žádosti o servisní úkon určuje Objednatel, kdy prioritu takové žádosti musí patřičně odůvodnit. V případě odlišného názoru Poskytovatele, je Poskytovatel povinen tuto informaci neprodleně sdělit Objednateli dle čl. 4 a 5 přílohy č. 1 této smlouvy. V případě rozporu s určením priority servisního úkonu a nedohodnou-li se smluvní strany jinak, platí priorita určená Objednavatelem.
6. Cena a způsob placení
6.1. Cena za předmět plnění je sjednána ve formě měsíčního paušálu ve výši [DOPLNÍ ZÁJEMCE] Kč bez DPH (slovy: [DOPLNÍ ZÁJEMCE]), DPH činí [DOPLNÍ ZÁJEMCE] %, tj. [DOPLNÍ ZÁJEMCE] Kč (slovy: [DOPLNÍ ZÁJEMCE]). Cena včetně DPH činí [DOPLNÍ ZÁJEMCE] Kč (slovy: [DOPLNÍ ZÁJEMCE]).
6.2. Sjednaný měsíční paušál zahrnuje:
- úkony přecházející ze smlouvy o dílo uvedené v příloze č. 1 (popis funkcionalit) po skončení záruční doby v souladu s čl. 2.2. této smlouvy,
- úkony uvedené v čl. 3 této smlouvy,
- jednu cestu autem k Objednateli měsíčně.
6.3. Sjednaný měsíční paušál nezahrnuje:
- úpravu software na žádost Objednatele, která není prováděna na základě legislativních změn,
- servisní úkony výslovně nesjednané v této smlouvě.
Za takové úkony je Poskytovatel oprávněn účtovat cenu [DOPLNÍ ZÁJEMCE] Kč bez DPH za jednu člověkohodinu.
- další cesty autem k Objednateli, které budou účtovány dle skutečně vynaložených nákladů, které budou Objednateli před vlastní jízdou kalkulovány a Objednatelem odsouhlaseny.
6.4. Splatnost faktur je 30 kalendářních dnů od jejich prokazatelného doručení Objednateli. Faktury budou vystaveny ze strany Poskytovatele vždy zpětně za jednotlivý předchozí měsíc.
6.5. Daňový doklad – faktura musí obsahovat všechny náležitosti řádného účetního a daňového dokladu ve smyslu příslušných právních předpisů, zejména zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů. V případě, že faktura nebude mít odpovídající náležitosti, je Objednatel oprávněn ji vrátit ve lhůtě splatnosti zpět Poskytovateli k doplnění, aniž se tak dostane do prodlení se splatností. Lhůta splatnosti počíná běžet znovu od opětovného doručení náležitě doplněné či opravené faktury Objednateli.
6.6. Faktura bude Objednatelem uhrazena na bankovní účet Poskytovatele uvedený na faktuře. Povinnost uhradit fakturovanou cenu bude Objednatelem splněna v okamžiku připsání její výše na bankovní účet Poskytovatele.
7. Sankce
7.1. Smluvní strany sjednávají tyto smluvní pokuty:
7.1.1. na vzniklé případy vztahující se po uplynutí záruční doby sjednané ve smlouvě o dílo a čl. 2.2. této smlouvy ve výši:
a) za každou započatou hodinu prodlení s odstraněním záruční vady „kritické“ 200,- Kč
b) za každou započatou hodinu prodlení s odstraněním záruční vady „méně závažné“ 100,- Kč
c) za každou započatou hodinu prodlení s odstraněním záruční vady „neohrožující funkčnost“ 50,- Kč
7.1.2. na vzniklé případy vztahující se od účinnosti předmětné servisní smlouvy na úkony
• nepravidelné
a) za každou započatou hodinu prodlení s odstraněním urgentní vady ve výši 100,- Kč
b) za každý započatý den z prodlení s odstraněním vady v ostatních případech ve výši 50,- Kč
• pravidelné
a) za každý započatý den z prodlení s odstraněním vady v ostatních případech ve výši 100,- Kč
Lhůty a postup při odstraňování vad se řídí přílohou č. 1 této smlouvy.
7.2. Sjednává se smluvní pokuta ve výši 1% z celkové roční ceny podpory za jednotlivý případ v případě nedodržení termínu provedení profylaxe dle vzájemně odsouhlaseného harmonogramu.
7.3. V případě porušení povinností stanovených v čl. 8 je Poskytovatel povinen uhradit Objednateli smluvní pokutu ve výši 100 000,- Kč za každé takové porušení. Ustanovením o smluvní pokutě není dotčeno právo Objednatele na náhradu škody.
7.4. V případě prodlení Objednatele s úhradou vystavené faktury je Poskytovatel oprávněn uplatnit vůči Objednateli úrok z prodlení ve výši 0,5 % z fakturované částky v Kč bez DPH za každý i jen započatý den prodlení.
7.5. Smluvní pokuty uplatňované dle této Smlouvy jsou splatné do 30 (třiceti) dnů od data, kdy byla povinné straně doručena písemná výzva k zaplacení smluvní pokuty ze strany oprávněné strany, a to na účet oprávněné strany uvedený v čl. 1 této smlouvy.
8. Xxxxxxx osobních údajů a informací
8.1. Poskytovatel se zavazuje, že pokud v souvislosti s realizací této smlouvy při plnění svých povinností přijdou jeho pověření pracovníci do styku s osobními nebo citlivými údaji ve smyslu zákona č. 101/2000 Sb., o ochraně osobních údajů, v platném znění, učiní veškerá opatření, aby nedošlo k neoprávněnému nebo nahodilému přístupu k těmto údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování jakož i k jejich jinému zneužití, jinak odpovídá Objednateli za způsobenou škodu. Poskytovatel nese plnou odpovědnost za případné porušení této povinnosti z jeho strany.
8.2. Veškeré informace získané v souvislosti s plněním této smlouvy a které nejsou běžně dostupné či veřejně známé, se považují za důvěrné. Smluvní strany se zavazují, že tyto informace jiným subjektům nesdělí, nezpřístupní ani nevyužijí pro sebe nebo jinou osobu. Porušením povinnosti mlčenlivosti není poskytnutí informací ke splnění zákonné povinnosti.
8.3. Ustanovení obou předchozích odstavců nejsou dotčena ukončením účinnosti této smlouvy z jakéhokoliv důvodu a jejich účinnost platí i do budoucna bez jakéhokoliv časového omezení.
8.4. Poskytovatel je povinen po ukončení platnosti této smlouvy předat Objednateli neprodleně veškerá data a informace, která získal v souvislosti s plněním předmětu této smlouvy. Stejně tak je Poskytovatel povinen odstranit veškerá data a informace získané v souvislosti s plněním předmětu této smlouvy ze svých interních informačních systémů bez ohledu na to, zda jsou v elektronické či jiné podobě.
9. Společná a závěrečná ustanovení
9.1. Tato smlouva nabývá platnosti a účinnosti dnem jejího uzavření, tzn. dnem podpisu smlouvy oprávněnými zástupci obou smluvních stran. Dnem nabytí účinnosti této smlouvy současně končí platnost servisní smlouvy uzavřené dne 2. 6. 2008 na provoz informačního systému ISKaM 2008.
9.2. Smlouva se sjednává na dobu neurčitou s šestiměsíční výpovědní lhůtou. Objednatel může smlouvu vypovědět bez udání důvodu. Poskytovatel může uplatnit výpověď pouze v případech, že Objednatel hrubě poruší ustanovení této smlouvy, zejména se ocitne v prodlení s placením delším než tři měsíce. V době záruky sjednané ve smlouvě o dílo, tj. po dobu 2 let, nesmí Poskytovatel vypovědět tuto smlouvu.
9.3. Nedílnou součástí předmětné smlouvy je také:
• Příloha č. 1
9.4. Smluvní strany budou vždy usilovat o smírné urovnání případných sporů vzniklých ze smlouvy. Případné spory vzniklé z této smlouvy budou řešeny podle platné právní úpravy věcně a místně příslušnými orgány České republiky. Smluvní strany sjednávají pro spory vyplývající z této
smlouvy či s touto smlouvou související místní příslušnost Okresního soudu Plzeň – město, resp. Krajského soudu v Plzni.
9.5. Smlouva se sepisuje ve čtyřech vyhotoveních, po dvou pro každou stranu.
9.6. Smluvní strany prohlašují, že si smlouvu před jejím podpisem přečetly a s jejím obsahem bez výhrad souhlasí. Smlouva je vyjádřením jejich pravé, skutečné, svobodné a vážné vůle. Na důkaz pravosti a pravdivosti těchto prohlášení připojují oprávnění zástupci smluvních stran své podpisy.
V Plzni dne V [DOPLNÍ ZÁJEMCE] dne
[DOPLNÍ ZÁJEMCE]
za Objednatele za Poskytovatele
doc. Dr. RNDr. Xxxxxxxx Xxxxxxx, rektor [DOPLNÍ ZÁJEMCE]
Příloha č. 1 Servisní smlouvy
A) Zásady součinnosti při podpoře provozu systému ISKaM4
1. Účel
1.1. Tyto zásady jsou určeny pro postup Objednatele (osob v jeho řídicí působnosti) při využívání podpory Poskytovatele.
2. Oprávněné osoby Objednatele
2.1. Oprávněnými osobami Objednatele, jež mohou využívat kontaktu dle těchto zásad, jsou:
⮚ kvestor
⮚ ředitel kolejí a menz
⮚ vedoucí ubytovacího úseku
⮚ vedoucí kolejí
⮚ vedoucí menzy
⮚ správce sítě
⮚ administrátor systému výdeje stravy
⮚ pověřená osoba a její zástupce
2.2. V odůvodněných a naléhavých případech, kdy hrozí nebezpečí škody z prodlení nebo kdy není žádná z oprávněných osob dostupná, je oprávněn využít kontaktu každý uživatel, který je účasten na zajišíování jeho provozní funkčnosti.
3. Indikace podpory
3.1. Důvodem k vyžádání podpory dle tohoto pokynu může být zejména:
⮚ vada v systému
⮚ naléhavý provozní dotaz
⮚ návrh na změnu v systému
⮚ žádost o konzultaci
⮚ poskytnutí námětu na vylepšení systému
⮚ případně jiný vážný důvod, který nelze řešit jinak než prostřednictvím podpory.
3.2. Podpora, na niž se vztahují záruční podmínky ze smlouvy o dílo, je poskytována bezplatně.
4. Elektronický kontakt a řešení incidentu
4.1. Pro podporu byl vyvinut systém sledování incidentů prostřednictvím internetových stránek na adrese xxxx://xxxxxxx.xxx-xxxx.xx. Poskytovatel poskytne oprávněným pracovníkům přístup s patřičným oprávněním, který jim umožní zadat incident včetně jeho priority a sledovat stav řešení problému.
4.2. Při následném dálkovém kontaktu s Poskytovatelem musí Objednatel zajistit realizaci pokynů Poskytovatele a zajistit mu vzdálený přístup k systému, bude-li o to požádán.
4.3. Jakmile je problém vyřešen, Objednatel tuto skutečnost potvrdí a incident uzavře. Systém sleduje dobu strávenou řešením problému, odezvu na incident a jeho vyřešení. Na základě těchto údajů a odsouhlasení Objednatelem proběhne fakturace.
5. Telefonický kontakt
5.1. V případě nefunkčnosti elektronického kontaktu lze podnět uplatnit na těchto telefonních číslech:
sekretariát ApS | 000 000 000, 541 240 398 |
technici společnosti ApS Brno s.r.o. | 603 427 409 |
xxx. Xxxxxxx | 604 223 200 |
B) Termíny plnění odstraňování závad
Kritické vady – vady, které znemožňují práci s aplikačním SW nebo jeho částí a nelze použít alternativní postup
Méně závažné vady – vady, které omezují práci s aplikačním SW nebo jeho částí, ale lze použít alternativní postup.
Vady neohrožující funkčnost – vady, které neohrožují funkčnost aplikačního SW nebo jeho částí.
Xxxxxxx | Xxxxxxxx vady | Méně závažné vady | Vady neohrožující funkčnost |
Poskytnutí informace Objednateli, jakým způsobem bude Poskytovatel závadu řešit | 0:30 hod. | 2 hod. | 8 hod. |
Zprovoznění systému alespoň náhradním způsobem pro zajištění jeho základních funkcí (tj. ne úplné odstranění závady) | 1 hod. | 8 hod. | 24 hod. |
Úplné odstranění závady (tj. dosažení stavu, ve kterém byl systém před závadou) | 8 hod. | 40 hod. | 160 hod. |
Veškeré lhůty jsou vázány na pracovní dobu v pracovní dny od 8:00 do 16:00 hod.