Příloha CUBETEAM.PDF
Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
© RÁMCOVÁ SMLOUVA O DÍLO A O POSKYTOVÁNÍ SERVISNÍCH
SLUŽEB
pro vývoj, úpravy a podporu stávajících webových aplikací na platformě Lotus Notes
Domino
(dále jen „smlouva")
uzavřena v souladu s ust. $ 269 odst. 2 a ust. S 536 a násl. zákona č. 513/1991 Sb., ob-
chodní zákoník, v platném znění, mezi smluvními stranami
Agentura pro podporu podnikání a investic CzechInvest
se sídlem Štěpánská 15, PSČ: 120 00 Praha 2
IČ: 71377999
DIČ: CZ 71377999
jednající: Ing. Marian Piecha, Ph.D., generální ředitel
dále také jako „Objednatel" na straně jedné
a
CubeTeam s.r.o.
se sídlem: Šeříková 618/4, 150 00 Praha 5
IČ: 27468798
DIČ: CZ27468798
jejímž jménem jedná: Pavel Krummer, jednatel společnosti
dále také jako „Zhotovitel“ na straně druhé,
dále obě společně také jako „smluvní strany"
Úvodní ustanovení
Tato smlouva je uzavírána na základě zadávacího řízení veřejné zakázky „Vývoj, úpravy a
podpora stávajících webových aplikací na platformě Lotus Notes Domino“ ev.č. VZ/21/13.
Článek I.
Předmět smlouvy
1.1.. Zhotovitel se touto smlouvou zavazuje, na základě jednotlivých dílčích smluv
uzavřených mezi smluvními stranami, poskytovat Objednateli plnění spočívající ve
vývoji, úpravách a v technické podpoře stávajících webových aplikací Objednatele
pracujících na platformě Lotus Notes Domino (dále také jen „plnění“ nebo „dílo").
Specifikace webových aplikací je uvedena v příloze č. 1 této smlouvy a tvoří její
nedílnou součást.
12. | Konkrétní požadavky na plnění jsou shromažďovány u pověřené osoby Objednatele;
proces administrace požadavku na plnění dle této smlouvy probíhá následovně:
1.2.1. Pověřená osoba Objednatele doručí písemně Zhotoviteli výzvu k podání
nabídky na dílčí plnění včetně technické specifikace požadovaného plnění
(dále také jen „výzva"). Zhotovitel je po té povinen provést analýzu požadavku
uvedeného ve výzvě Objednatele a písemně se k němu vyjádřit; v případě, že:
a) je zadání úplné a přesné, připojí Zhotovitel ke svému vyjádření
informace © možnosti řešení požadavku, včetně © časového
harmonogramu realizace, doby dodání dílčího plnění a nabídkové
ceny dílčího plnění (dále jen „nabídka na dílčí plnění');
b) jJinak požádá pověřenou osobu Objednatele o doplňující informace tak,
aby vyjádření Zhotovitele bylo přesné a úplné. Po písemném doplnění
požadovaných informací je Zhotovitel povinen postupovat dle písm. a)
tohoto odstavce smilouvy.
1.2.2. Objednatel na základě vyjádření Zhotovitele rozhodne o způsobu řešení
požadavku. Přípravná fáze administrace výzvy je zakončena oboustranným
potvrzením detailního zadání dílčího plnění.
1.2.3. Na základě oboustranně písemně potvrzeného detailního zadání je uzavřena
dílčí smlouva o dílo na dílčí plnění sjednaná způsobem uvedeným odstavci
1.2.1 a 1.2.2. tohoto článku smlouvy (dále jen „dílčí smlouva“"). Dílčí smlouva
obsahuje alespoň:
a) číslo dílčí smlouvy;
b) detailní zadání díla sjednané způsobem uvedeným v odst. 1.2.1 a 1.2.2
tohoto článku smlouvy;
c) termín zhotovení a předání díla;
d) cenu dílčího plnění uvedenou bez/včetně DPH;
e) požadavek na délku testovacího období díla;
f) v případě požadavku Objednatele na školení k dílčímu plnění dále
specifikace obsahu a rozsahu školení (počet hodin), místo a termín
školení včetně 1x náhradního termínu;
1.2.4. Pro účely této smlouvy smluvní strany sjednaly možnost sjednávání a
uzavírání dílčích smluv prostřednictvím elektronických prostředků na kontaktní
údaje pověřených osob dle této smlouvy.
1.2.5. Zhotovitel provede dílčí smlouvou sjednané dílčí plnění, vč. instalace do
testovacího prostředí Objednatele, a protokolárně dílčí plnění předá
Objednateli k testovacímu provozu. Objednatel je povinen plnění do
testovacího provozu převzít a průběžně Zhotoviteli písemně specifikovat
zjištěné nesrovnalosti a vady dílčího plnění dle či. IV, této smlouvy. Po
ukončení sjednané testovací doby vystaví Zhotovitel (na základě
Objednatelem písemně předaného soupisu vad a nedostatků díla) protokol o
testování dílčího plnění a ve sjednané Ihůtě, nejpozději však do 20 kalen-
dářních dnů ode dne předání protokolu, provede opravu vad uvedených v
tomto protokolu.
Po odstranění vad uvedených v protokolu o testování dílčího plnění vystaví
Zhotovitel závěrečný předávací protokol, jehož přílohou bude dokumentace
řešení, tj. popis předaného díla včetně uživatelské a provozně-technické
dokumentace. Výsledkem předávacího řízení může být převzetí díla s
výhradami nebo bez výhrad Objednatele, příp. nepřevzetí díla. Po
oboustranném potvrzení závěrečného protokolu provede Zhotovitel instalaci
aplikace do tzv. produktivního provozu Objednatele.
1.2.6. Po úspěšném ukončení instalace díla do tzv. produkčního provozu
Objednatele je Objednatel povinen bez zbytečného odkladu spustit ostrý
provoz díla; Zhotovitel se zavazuje poskytovat po dobu šesti (6) měsíců po
zahájení ostrého provozu díla Objednateli technickou podporu. Cena
technické podpory je zahrnuta v dílčí ceně plnění.
1.3. Jestliže v průběhu realizace plnění sjednaného dílčí smlouvou dojde ze strany
Objednatele ke změně dílčího plnění dle dílčí smlouvy, je Objednatel povinen
požadovanou změnu Zhotoviteli písemně oznámit, včetně předložení požadovaných
1.4.
1.5.
2.1.
2.2.
2.3.
2.4.
3.1.
3.2.
změn dílčího plnění a jeho technické specifikace. Zhotovitel provede analýzu
požadované změny a písemně se k ní vyjádří; v případě, že je požadavek na změnu
dílčího plnění úplný a přesný, připojí Zhotovitel ke svému vyjádření informace o
možnosti řešení změny, včetně dopadu do časového harmonogramu, doby dodání
dílčího plnění a sjednané ceny dílčího plnění, jinak požádá pověřenou osobu
Objednatele o doplňující informace, tak aby vyjádření Zhotovitele bylo přesné a úplné.
Jestliže Objednatel písemně potvrdí navržené řešení Zhotovitele, je uzavřen mezi
smluvními stranami dodatek k dílčí smlouvě způsobem uvedeným v odst. 1.2.3 této
smlouvy.
Zhotovitel se zavazuje provést plnění v termínu stanoveném vdílčí smlouvě a v
případě řešení vad v průběhu testování dle čl. IV. této smlouvy.
Objednatel se zavazuje zajistit Zhotoviteli potřebnou součinnost. Objednatel se
zavazuje za podmínek stanovených v dílčí smlouvě a této smlouvě zaplatit Zhotoviteli
sjednanou cenu za dílčí plnění.
Článek II.
Cena a platební podmínky
Cena za dílčí plnění bude sjednaná v dílčí smlouvě a bude stanovena jako násobek
počtu hodin nezbytných k provedení dílčího plnění a sazbou 1.000,-Kč bez DPH za
jednu (1) hodinu práce Zhotovitele. Vypočtená cena bude dílčí cenou plnění na
základě dílčí smlouvy. Zhotovitel je oprávněn vystavit daňový doklad — fakturu po
protokolárním předání dílčího plnění Objednateli do tzv. produkčního provozu a
doručit ji Zhotoviteli. Přílohou každé faktury bude závěrečný předávací protokol
podepsaný pověřenými osobami smluvních stran.
Faktura musí obsahovat veškeré náležitosti stanové zákonem č. 235/2004 Sb., o dani
z přidané hodnoty, ve znění pozdějších předpisů. Pokud faktura nebude obsahovat
některou z náležitostí podle zákona č. 235/2004 Sb., o dani z přidané hodnoty, v
platném znění, bude vrácena bez zaplacení Zhotoviteli k doplnění či opravení s tím,
že lhůta splatnosti běží ode dne prokazatelného doručení doplněné (opravené)
faktury Objednateli. Po dobu doručení doplněné (opravené) faktury není Objednatel v
prodlení s placením ceny za předmět plnění.
Objednatel nebude poskytovat zálohy. Splatnost faktur činí 30 dnů ode dne
následujícího po dni doručení faktury, obsahující požadované náležitosti, Objednateli.
Platby budou probíhat v Korunách českých. Pro účely této smlouvy se faktura
považuje za uhrazenou odepsáním příslušné částky z účtu Objednatele.
V dílčí ceně plnění jsou zahrnuty veškeré náklady spojené s předmětem, místem a
časem plnění dle dílčí smlouvy a této smlouvy. Poskytovatel nese v rámci předmětu
této smlouvy veškeré náklady a poplatky související s realizací dílčí smlouvy včetně
veškerých daní a poplatků dle platných předpisů včetně případných celních,
bankovních výloh a pojištění.
Článek III.
Místo a termín plnění
Místem plnění díla je sídlo objednatele na adrese Štěpánská 15, 120 00 Praha 2.
Termín plnění je stanoven pro každé plnění v dílčí smlouvě.
4.1.
4.2.
4.3.
4.4.
4.5.
5.1.
5.2.
Článek IV.
Testování plnění
Zhotovitel je povinen instalovat dílo zhotovené dle dílčí smlouvy do testovacího
provozu Objednatele ve stanoveném místě a v termínu uvedeném v dílčí smlouvě. V
rámcí testování díla bude Objednatel ověřovat všechny funkce díla a jeho částí ve
smyslu požadovaného detailního zadání a písemně sdělovat Zhotoviteli vady a
nedostatky díla.
Případné vady a nedostatky díla jsou následovně kategorizovány:
a) Vadou s prioritou 1 se rozumí, vážná vada, která znemožňuje využívání díla
nebo způsobuje vážné provozní problémy nebo porušuje hrubě bezpečnostní
požadavky Objednatele.
b) Vadou s prioritou 2 se rozumí, střední vady, které způsobují problémy při
využívání a provozování díla, ale umožňují provoz, který nemá vliv na kvalitu
dat a výsledky zpracování, problémy lze dočasně řešit organizačními
opatřeními.
c) Vadou s prioritou 3 se rozumí - nevýznamné vady.
Kategorizací vad provádí Objednatel po konzultaci se Zhotovitelem, konečné
rozhodnutí přísluší Objednateli.
Objednatel se zavazuje oznamovat Zhotoviteli vady s prioritou 1 a 2, zjištěné v
průběhu testování, neprodleně; vady s prioritou 3 zjištěné v průběhu testování se
zavazuje oznamovat v týdenní periodě, nebude-li dohodnuto jinak. Vady bude
objednatel oznamovat prostřednictvím emailu pověřené osobě Objednatele, kam
rovněž uvede popis, kategorizaci vady a požadovaný termín odstranění vady,
přiměřený obvyklým technologickým Ihůtám pro jeho odstranění, nejdéle však do 5
kalendářních dnů ode dne oznámení vady. V průběhu testování se pověřené osoby
Objednatele a Zhotovitele zavazují průběžně projednávat způsoby a termíny řešení
vady. Pověřená osoba Objednatele je na žádost Zhotovitele povinna písemně potvrdit
datum odstranění každé vady, zjištěné v průběhu testování.
Za úspěšné ukončení testování se považuje výsledek s následujícím počtem vad:
a) 0 vad s prioritou 1
b) nejvýše 3 vady s prioritou 2 (tzn. 3 chyby jsou ještě vyhovující)
c) méně než 10 vad s prioritou 3 (tzn. 10 chyb už nevyhovuje)
Budou-li v protokolu o testování díla uvedeny chyby s prioritou 2 nebo 3, Zhotovitel je
povinen tyto vady odstranit k datu uvedenému v protokolu, nejpozději však do 20
kalendářních dnů ode dne oboustranného podpisu protokolu o testování.
V případě přerušení testování se Zhotovitel ocitá v prodlení s dodáním díla dle dílčí
smlouvy.
Článek V.
Výkon autorských práv; licenční ujednání
Každé dílo vytvořené na základě této smlouvy a jednotlivých dílčích smluv
zhotovitelem je dílem autorským ve smyslu zákona č. 121/2000 Sb., o právu
autorském, o právech souvisejících s právem autorským a o změně některých
zákonů, v platném znění, (dále jen „autorský zákon'").
Zhotovitel poskytuje touto smlouvou Objednateli výhradní licenci k užití díla jako celku
nebo jeho částí všemi způsoby uvedenými v autorském zákoně v neomezeném
rozsahu, bez jakéhokoli množstevního a územního omezení, na celou dobu trvání
ochrany majetkových práv ve smyslu autorského zákona.
95.3.
5.4.
5.5.
5.6.
ovf:
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
Objednatel tuto licenci přijímá. Objednatel není povinen licenci využít. Objednatel je
oprávněn práva tvořící součást licence poskytnout třetí osobě poustoupením celé
licence či její části a rovněž je oprávněn poskytnout tření osobě podlicenci.
Odměna za poskytnutí licence a udělení souhlasu k poskytnutí podlicence nebo k
postoupení licence je zahrnuta v ceně dle této smlouvy, resp. v ceně dle dílčích
smluv.
Objednatel je oprávněn, bezúplatně, zcela dle svého uvážení dílo nebo jeho část
zveřejnit, provádět jeho úpravy a změny, včetně změny názvu, zpracovat jej, včetně
překladu, spojit je s jiným autorským dílem a zařadit jej do díla souborného. Zhotovitel
tímto výslovně souhlasí s tím, že dílo (či kterákoliv část díla) bude uveřejněno a
šířeno jako dílo anonymní nebo pouze s označením objednatele, popř. s označením
koncového zákazníka objednatele, či jiného držitele jeho majetkových autorských
práv. :
Smluvní strany se dále dohodly, že licence k výkonu práva dílo užít trvá i po skončení
této smlouvy, resp. toto licenční ujednání je platné po celou dobu trvání autorských
práv k dílu.
Právní vztahy, které nejsou výslovně upravené v této smlouvě, se řídí příslušnými
ustanoveními autorského zákona.
Článek VI.
Práva a povinnosti smluvních stran
Objednatel se zavazuje poskytovat zhotoviteli úplné, pravdivé a včasné informace
potřebné k řádnému plnění závazků zhotovitele.
Objednatel se zavazuje zajistit pro zhotovitele potřebné technicko-organizační
podmínky vyplývající z této smlouvy nebo dohodnuté pověřenými osobami smluvních
stran.
Zhotovitel se zavazuje informovat bez zbytečného odkladu Objednatele o veškerých
skutečnostech, které jsou významné pro plnění závazků smluvních stran a zejména o
skutečnostech, které mohou být významné pro rozhodování objednatele V
jednotlivých obchodních případech týkajících se implementace upravených aplikací.
Zhotovitel se zavazuje plnit své závazky vyplývající z této smlouvy v souladu s
příslušnými normami.
Obě smluvní strany se zavazují považovat informace o veškerých skutečnostech, o
kterých se dozvěděly na základě realizace plnění podle této smlouvy nebo v
souvislosti s touto smlouvou a které nejsou veřejně známé či dostupné a z jejichž
povahy vyplývá, že smluvní strana má oprávněný zájem na jejich utajení, za
informace důvěrné a zavazují se zachovat mlčenlivost o takových skutečnostech a to
až do doby, kdy se tyto informace stanou obecně známými za předpokladu, že se tak
nestane porušením povinnosti mlčenlivosti.
Obě strany se zavazují, že při plnění předmětu této smlouvy zajistí, aby nedošlo k
porušení obchodního tajemství a ochrany osobních údajů ve smyslu zákona č.
101/2000 Sb., o ochraně osobních údajů, v platném znění. Zhotovitel si je vědom
toho, že v případě neoprávněného nakládání s osobními údaji je odpovědný dle
uvedeného zákona.
Za porušení povinnosti mlčeniivosti se nepovažuje, je-li smluvní strana povinna
důvěrnou informaci sdělit na základě zákonem stanovené povinnosti. Obě smluvní
strany jsou oprávněny také poskytnout důvěrné informace pověřeným zástupcům
6.8.
6.9.
71.
7.2.
7.3.
7.4.
7.5.
7.6.
7.8.
7.17
Objednatele a Zhotovitele, a to v rozsahu nezbytném pro realizaci plnění podle této
smlouvy. Smluvní strany jsou pro takové případy povinny zajistit; aby pověření
zástupci Objednatele a Zhotovitele zachovávali mlčenlivost o důvěrných informacích;
poruší-li pověření zástupci povinnost mlčenlivosti, odpovídá Objednatel a Zhotovitel v
rozsahu a způsobem, jako kdyby povinnost mlčenlivosti porušil sám.
V případě porušení této povinnosti milčenlivosti je druhá smluvní strana oprávněna
požadovat zaplacení smluvní pokuty ve výši 200.000,- Kč. Zaplacením smluvní
pokuty není dotčen nárok na náhradu prokazatelně vzniklé škody.
Povinnost mlčenlivosti trvá bez ohledu na ukončení účinnosti nebo platnosti této
smlouvy.
Článek VII.
Pověřené osoby
Objednatel je povinen zajistit, aby byla na straně Objednatele písemně pověřená
osoba, která bude odpovědná za sjednávání a uzavírání dílčích smluv dle této
smlouvy.
Pověření zástupci Objednatele i Zhotovitele jsou oprávněni vzájemně komunikovat,
definovat a řešit všechny problémy, které vzniknou v průběhu provádění dílčích
smluv; předkládat požadavky a návrhy druhé straně a vyjadřovat se k požadavkům a
návrhům druhé strany.
Pověření zástupci smluvních stran jsou oprávněni uzavírat dílčí smlouvy a všechny
protokoly v souvislosti s prováděním předmětu plnění dle dílčích smluv a této
smlouvy. :
Zhotovitel se zavazuje zajistit stálou dostupnost svého pověřeného zástupce a svých
odborných pracovníků v průběhu testování aplikace.
Z jednání pověřených osob obou smluvních stran budou pořizovány zápisy, které
budou archivovány vždy nejméně ve dvou stejnopisech - jeden u Zhotovitele a jeden
u Objednatele. Osobou odpovědnou za pořizování a archivování zápisů je pověřená
osoba Zhotovitele.
O předání jakéhokoliv plnění kteroukoliv smluvní stranou druhé smluvní straně bude
sepsán oboustranně podepsaný písemný protokol.
Pověřené osoby:
a) Pověřenými osobami na straně Objednatele jsou:
(i) Martin Hejret, tel. 296 342 484, email: martin.hejretGczechinvest.org
(ii) Viktor Jahna, tel. 296 342 859, email: viktor.jahna©czechinvest.org
b) Pověřenými osobami na straně Zhotovitele jsou:
(i) Pavel Krummer, tel. 775 666 985, email:pavel.krummer©cubeteam.eu
(ii) Daniel Vrána, tel. 775 666 986, email:dan.vranacubeteam.eu
Pověřené osoby a kontaktní údaje mohou být měněny jednostranným písemným
sdělením, které musí být doručeno příslušné smluvní straně, přičemž tyto změny
nabývají účinnosti po uplynutí tří (3) pracovních dnů ode dne doručení takového
sdělení.
8.1.
8.2.
8.3.
8.4.
8.5.
8.6.
9.1.
9:2
93.
9.4.
Článek VIII.
Vady díla, záruka
Zhotovitel poskytuje záruku, že plnění bude provedeno v souladu s touto smlouvou a
příslušnou dílčí smlouvou. Vadou plnění se pro účely této smlouvy rozumí rozpor mezi
sjednaným dílčím plněním v dílčí smlouvě oproti skutečnému stavu při produktivním
provozu díla.
Záruční doba plnění činí 24 měsíců a počíná běžet ode dne podpisu závěrečného
protokolu oběma smluvními stranami.
Smluvní strany se dohodly, že v případě vady plnění, kterou Objednatel uplatní v
záruční době, má objednatel především právo požadovat na zhotoviteli její bezplatné
odstranění.
Uplatnění nároku na odstranění vady musí být podáno písemně neprodleně po jejím
zjištění. Zhotovitel se zavazuje odstranit případné vady plnění bez zbytečného
odkladu od jejich uplatnění Objednatelem, nejpozději však do 15 (patnácti) pracovních
dnů. O době a předmětu odstranění vady dle tohoto ustanovení sepíší smluvní strany
písemný zápis, který obě smluvní strany podepíší.
Zhotovitel je povinen v návaznosti na Objednatelem uplatněnou vadu zahájit práce na
odstranění zjištěné vady, a to i v případě, že svoji odpovědnost za takto uplatněnou
vadu neuzná. V případě, že Zhotovitel prokáže, že za uplatněné vady neodpovídá,
budou mu následně vzniklé náklady Objednatelem uhrazeny do 21 (dvaceti jedna)
kalendářních dnů od doručení jejich písemného uplatnění Zhotovitelem.
Záruční doba zjištěné vady se prodlužuje o dobu potřebnou k odstranění zjištěné
záruční vady. :
Článek IX.
Sankce
V případě prodlení Zhotovitele s předáním plnění k testování oproti termínu
stanoveném v závazném časovém harmonogramu dle dílčí smlouvy, je Objednatel
oprávněn požadovat zaplacení smluvní pokuty ve výši 3000,- Kč za každý započatý
den prodlení.
V případě prodlení Zhotovitele s odstraněním vady zjištěné v průběhu testování
plnění ve lhůtě dle odst. 4.3 čl. IV. této smlouvy, je Objednatel oprávněn požadovat
zaplacení smluvní pokuty ve výši 1000,- Kč za každý započatý den prodlení a za
každou vadu.
V případě, že testování plnění nebude ukončeno (tj. nebude potvrzen závěrečný
protokol) v termínu stanoveném v závazném časovém harmonogramu dle dílčí
smlouvy z důvodů na straně Zhotovitele, je Objednatel oprávněn požadovat zaplacení
smluvní pokuty ve výši 5.000,- Kč za každý započatý den prodlení.
Zaplacení kterékoliv smluvní pokuty se žádným způsobem nedotýká nároku na
náhradu škody. Smluvní pokuty jsou splatné ve lhůtě 15 (patnácti) kalendářních dnů
od doručení písemné výzvy Objednatele k jejich, zaplacení. V případě prodlení
Zhotovitele se zaplacením smluvní pokuty, je Objednatel oprávněn účtovat úrok z
prodlení ve výši 0,05 % z dlužné částky za každý i započatý den prodlení. Smluvní
strany se dohodly, že splatné smluvní pokuty jsou započitatelné proti vyúčtovaným
platbám za provedení i jednotlivých částí díla.
9.5.
10.1.
10.2.
V případě prodlení Objednatele se zaplacením kterékoliv faktury, je Zhotovitel oprávněn
požadovat úroky z prodlení ve výši 0,05 % z dlužné částky za každý i započatý den
prodlení.
Článek X.
Práva duševního vlastnictví
Zhotovitel prohlašuje, že uzavřením této smlouvy, ani plněním závazků z této smlouvy
vyplývajících, neporušuje práva duševního vlastnictví, zejména pak práva autorská,
třetích osob.
V případě, že jakákoliv třetí osoba, včetně zaměstnanců nebo pracovníků Zhotovitele,
uplatní jakýkoliv nárok proti Objednateli v souvislosti s užíváním díla, Zhotovitel se
zavazuje poskytnout Objednateli veškerou pomoc k odvrácení takového nároku a
uhradit Objednateli veškeré náklady a škody, které v souvislosti s nárokem třetí osoby
Objednateli vzniknou, to vše v plné výši a bez jakýchkoliv omezení, pokud Objednatel
splní všechny níže uvedené podmínky:
a) oznámí Zhotoviteli bez zbytečného odkladu písemně uplatnění jakéhokoliv
podobného nároku třetích osob;
b) neuzná sám uplatněný nárok;
c) zplnomocní Zhotovitele na jeho žádost k vypořádání takového nároku soudní
nebo mimosoudní cestou v rozsahu povoleném právními předpisy,
a) neučiní bez předchozího písemného souhlasu Zhotovitele žádné jiné právní
úkony, které by mohly jakýmkoliv způsobem výsledek uplatnění nároků třetí
osoby ovlivnit v neprospěch Zhotovitele;
to však neplatí v případě, že Zhotovitel je nečinný nebo jeho obrana proti takto
vzneseným nárokům je neúčinná.
Článek XI
Ukončení smlouvy
Ukončení této smlouvy dříve je možné písemnou dohodou smluvních stran nebo
písemnou výpovědí jedné ze smluvních stran, i bez udání důvodů. Výpovědní lhůta
činí dva (2) měsíce a počíná běžet prvním dnem kalendářního měsíce následujícího
po doručení písemné výpovědi druhé smluvní straně.
Objednatel je oprávněn od této smlouvy písemně odstoupit v případě podstatného
porušení této smlouvy Zhotovitelem ve smyslu příslušných ustanovení obchodního
zákoníku, v platném znění. Odstoupení od smlouvy ze strany Objednatele není
spojeno s uložením jakékoli sankce k tíži Objednatele.
Objednatel je dále oprávněn písemně odstoupit od této Smlouvy, pokud Zhotovitel:
a) je v prodlení se smluvně dohodnutými termíny plnění po dobu delší než
dvacet (20) dnů; nebo
b) poruší některé ze smluvně sjednaných ustanovení, nebude-li dohodnuto
jinak.
Porušení smlouvy každým z výše uvedených důvodů je považováno za porušení
této smlouvy podstatným způsobem.
Objednatel dále může odstoupit od této smlouvy v případě, že:
a) na majetek Zhotovitele je vedeno insolvenční řízení nebo insolvenční
návrh byl zamítnut pro nedostatek majetku Zhotovitele (v souladu se
zněním zákona č. 182/2006 Sb., o úpadku a způsobech jeho řešení, ve
znění pozdějších předpisů); nebo
b) Zhotovitel vstoupí do likvidace.
12.1
12.2
12.3
12.4
12.5
12.6
Za den odstoupení od smlouvy se považuje den, kdy bylo písemné oznámení o
odstoupení oprávněné smluvní strany doručeno druhé smluvní straně.
Objednatel má dále právo odstoupit od této smlouvy i v případě, že Zhotovitel uvedl
v této smlouvě informace nebo doklady, které neodpovídají skutečnosti.
Ukončením této Smlouvy výpovědí nebo odstoupením nejsou dotčena práva
smluvních stran na úhradu splatné smluvní pokuty, úroku z prodlení a na náhradu
škody.
Článek XII.
Závěrečná ujednání
Tato smlouva se uzavírá na dobu určitou a to na 48 měsíců ode dne jejího
oboustranného podpisu.
Smluvní strany souhlasí s tím, že budou považovat údaje a dokumentaci podle této
smlouvy za obchodní tajemství, a nese odpovědnost v případě, že je využije nebo
jinému odhalí i po ukončení platnosti této smlouvy.
Všechny spory mezi smluvními stranami, vzniklé z právních vztahů založených touto
smlouvou nebo v souvislosti s ní, budou řešeny jednáním při vynaložení veškerého
úsilí ke smírnému řešení, nebo příslušným soudem.
Není-li v této smlouvě sjednáno jinak, jakékoliv informace, oznámení a sdělení, které
mají být sděleny jednou ze smluvních stran druhé smluvní straně, budou považovány
za řádně předané, pokud budou osobně proti podpisu předány druhé smluvní straně
nebo pokud budou zaslány doporučenou poštou na adresy uvedené v záhlaví smlouvy
nebo na adresy oznámené druhou smluvní stranou. Účinky doručení veškerých
informací, oznámení a sdělení zaslaných na adresy uvedené v záhlaví smlouvy nebo
na adresy oznámené druhou smluvní stranou nastávají také dnem vrácení těchto
informací, oznámení a sdělení jako nedoručitelných zásilek odesílající straně.
Smlouvu |lze měnit pouze formou písemných, oboustranně podepsaných dodatků.
Není li uvedeno jinak, adresy, telefonní a faxová čísla lze měnit i jednostranným
písemným oznámením; smluvní strany se zavazují neprodleně oznamovat změny
uvedených údajů druhé smluvní straně a v případě porušení této povinnosti se
zavazují uhradit veškeré škody a náklady, které druhé smluvní straně z porušení této
povinnosti vznikly.
Tato smlouva je vyhotovena ve třech (3) exemplářích s platností originálu, z nichž dva
(2) exempláře obdrží Objednatel a jeden (1) exemplář obdrží Zhotovitel.
12.7 Smlouva nabývá platnosti a účinnosti dnem podpisu obou smluvních stran.
12.8 Zástupci smluvních stran prohlašují, že si smlouvu přečetli, souhlasí s ní a že tato
smlouva vyjadřuje jejich pravou a svobodnou vůli, na důkaz čehož připojují své
podpisy.
Přílohy:
Příloha č. 1 — Specifikace předmětu a technických podmínek plnění včetně
modelového příkladu
Příloha č. 2 — Programátorský předpis
Příloha č. 3= Grafický standard
Příloha č. 4 - Nabídka zhotovitele s nabídkovou cenou (doplněná tabulka dle přílohy č.
4 Výzvy k podání nabídek) .
V Praze dne..ď..řž?.fí.,/.9.9?.5.%5.4...2013
Za Objednatele: É/Ž
M
Ing. Marian Piecha, Ph.D., Llé
. ž 7 468
generální ředitel : * jednatel společno t?'Č a
CZÚÁŠÚNQ
m Smomam,
m
Příloha č.1
Výzvy k podání nabídek
Specifikace předmětu a technických podmínek plnění veřejné
zakázky a modelový příklad k řešení
V rámci řízení činností zadavatele jsou využívány specifické webové aplikace, které jsou nezbytným
pracovním nástrojem pro zaměstnance zadavatele. Vzhledem k neustálým změnám v podnikatelském
prostředí je nutné pružně reagovat a přizpůsobovat tak tyto pracovní nástroje k co nejoptimálnější
funkčnosti.
i. Předmět plnění veřejné zakázky
Předmětem plnění veřejné zakázky je poskytování služeb spojených s vývojem, úpravami a
technickou podporou stávajících webových aplikací informačního systému Lotus Notes Domino
vrozsahu specifikovaném zadávacími podmínkami. Součástí plnění je zajištění všech činností
souvisejících se zajištěním požadovaných služeb. Poskytováním služeb se rozumí zejména:
a) Vývoj a úpravy stávajících webových aplikací včetně aplikací souvisejících
b) vývoj nových webových aplikací
c) tvorba webových služeb (konzumace i poskytování)
d) technická podpora a poskytování rad s administrací Lotus Notes a Lotus Notes Domino
Stávajícími webovými aplikacemi se rozumí následující aplikace:
CRM:
Aplikace CRM (Customer Relationship Management - Řízení vztahu se zákazníkem)
obsahuje externí kontakty zadavatele. Každý kontakt má definovanou odpovědnou
osobu, která zodpovídá za správnost údajů o kontaktu.
Marketingový plán:
Aplikace Marketingový plán se používá pro plánování, schvalování a evidenci marketingových
aktivit zadavatele. Marketingovou aktivitou se rozumí událost, která nějakým způsobem propaguje
zadavatele a její činnosti v prostředí, ve kterém operuje. Hlavním cílem aplikace je seskupení všech
marketingových aktivit na jednom místě. Dále aplikace řeší provázanost aktivit napříč divizemi
zadavatele a vyjasňuje workflow schvalovacích procesů v rámci zadavatele. Aplikace má za úkol
odstranit redundantní aktivity jednotlivých divizí, konkretizovat nejasnosti v kompetencích osob
zadavatele, omezit rozporná nebo nejednotná sdělení, přispět k synergii mezi jednotlivými divizemi
zadavatele a v neposlední řadě zabránit neefektivnímu vynakládání finančních prostředků a
zbytečnému zatěžování lidských zdrojů.
Projekty CI:
Aplikace Projekty CI slouží k evidenci investičních projektů, na kterých se zadavatel podílí.
Obsahuje veškeré, kontakty a informace o konkrétních projektech. Aplikace Projekty CI slouží jako
hlavní nástroj pro řízení, sledování, kontrolu a hodnocení kompletního work flow investičních
projektů. Stejně tak je základním zdrojem dat pro oficiální statistiky zadavatele.
Aplikace Projekty CI pokrývá primární činnosti divize Investice zadavatele. Od vytvoření
poptávkového dotazu až po ukončení projektu, popřípadě jeho další překlopení na AFC (Aftercare).
ATA 4
aktivně využívají všichni zaměstnanci zadavatele.
Program Board:
Aplikace slouží jako "nástěnka" jednotlivých divizí zadavatele, spolupracujících na finančních
programech. Zároveň integruje nejčastěji kladené otázky (FAOs) a jejich odpovědi do jednoho
místa. ,
Jádrem aplikace jsou Programy, ke kterým lze vytvářet podrobnější specifikace ve formě Opatření,
Novinek a Dotazů (přičemž novinky i dotazy se nemusí vždy vztahovat k publikovaným programům,
resp. opatřením).
Program Board dále eviduje a umožňuje zpracování uchazečů o pozici "Posuzovatelé“",
Nemovitosti:
Aplikace nemovitostí slouží k evidenci průmyslových zón, pozemků, nájemních hal a jiných
podnikatelských nemovitostí na území České republiky. Za pomoci aplikace vytváříme nabídku
nemovitostí pro investory, kteří zvažují zahájení svých aktivit v České republice nebo se rozhodli
expandovat. Dále aplikace zpracovává statistiky pro majitele pozemků, podává statistiky o
nemovitostech v jednotlivých krajích České republiky a bude zpracovávat statistiku o tvorbě
nabídek nemovitostí.
Monitoring tisku:
Jedná se o databázi článků z odborného denního tisku. Informační oddělení zadavatele monitoruje
denně média a vybírá z nich všechny odborné články, které jsou použitelné pro práci zadavatele.
Jedná se o cca 70 nejvýznamnějších témat (makroekonomická data, daně, PZI, sektory, země
atd.). Jednotlivé články se překopírují do databáze k daným tématům (s uvedením zdroje) a po 15.
hodině jsou tyto články automaticky rozesílány všem zaměstnancům zadavatele, kteří si dané téma
navolí.
Systém kromě rozesílání zpráv, všechny články archivuje a umožňuje zájemcům přímý přístup a
vyhledávat články podle vybraných témat i zdroje (např. všechny články z Hospodářských novin,
Lidových novin atd.)
Zaměstnanci zadavatele si mohou táké navolit témata, která chtějí, aby jim byla zasílána emailem.
Sektorové databáze:
Sektorové databáze slouží jako efektivní nástroj pro vyhledávání a třídění výrobních a vývojových
dodavatelů v České republice. Každý sektor je přehledně rozdělen do specifických třídících kritérií a
dále lze dodavatele vyhledávat dle umístění jejich společnosti a prostřednictvím fulltextu.
Systémové, setupové a číselníkové databáze.
Zadavatel poskytuje zájemcům pro informaci printscreeny webových aplikací Lotus Notes;
(printscreeny jsou uvedeny na konci této přílohy č. Výzvy)
ll. Požadavky zadavatele na technické podmínky plnění
Povinné podmínky pro dodavatele:
e © Značkovací jazyk: XHTML 1.0 Transitional dle W3C (viz. příloha Programátorský předpis)
« Využití technologií CSS, JavaScript, JSON, znalost JavaScript frameworku JAuery, Lotus
Script, Lotus Formula, Objektové programování v Lotus Scriptu, DB2, propojení s jinými
aplikacemi přes ODBC
e | Aplikace před předáním musí být zkontrolovány validátorem htip://validator.w3.org/
e Aplikace musí splňovat pravidla tvorby přístupného webu (viz. Nhitp:.//www.pravidla-
pristupnosti.cz/) - mimo body 8, 9, 11, 15, 18, 32, 33 (viz. příloha Programátorský předpis)
e | Všechny aplikace budou mít stejné standardizované grafické rozložení webové stránky (víz.
příloha Grafický standard).
e | Společně s aplikací musí dodavatel také předat zadavateli dokumentaci aplikace s informacemi
o nastavení práv pro uživatele, speciální uživatele a administrátory.
« © Jestliže v nové aplikaci existují pole se zodpovědnými osobami, aplikace musí být napojena na
delegační procesy databáze Personální Systém.
* Vpřípadě výskytu jakékoliv chyby v aplikaci zadavatel informuje dodavatele o chybě přes
interní helpdesk systém.
* © Aplikace budou přizpůsobeny rozlišení 1024x768
e © Aplikace musí plně podporovat zobrazení a práci v Internet Exploreru ver. 7,8,9,10
« © Aplikace bude vyvíjena pro Lotus Notes Domino ver. 8.0.2
I, Zadavatelem stanovený modelový příklad s požadavkem na úpravy webové
aplikace:
Požadované změny v aplikaci Marketingový plán:
Nastavení:
e | dle data- řadit od nejnovějšího k nejstaršímu
e © archiv — přesunout tam vše krom aktuálního roku
Filtrování:
e © umožnit exportovat též číslo MKT akce
Po kliknutí na ikonu MKT plán vrátit se vždy na hlavní stranu.
Rozdělit na kategorie:
Akce:
e | semináře/workshopy
« | veletrhy
e | konference
e | roadshow
* | prezentace (účast na akci, kterou nepořádá Cl)
e © jiné (vlastní akce CI, např. IR a PNR)
Následující kategorie uvidí a budou vyplňovat pouze pracovníci odboru MK!
PR:
e Inzerce
« © Média monitoring
« | Setkání s novináři
* | Tisková konference
« | Překlady
MKT aktivity:
e Tisk
Grafika
Web
Foto služby
Propagační předměty
jiné
o ae © © ©
Interní komunikace:
e | interní časopis
« © akce (heli, vánoční večírek, snídaně, atd.)
Workflow:
Současné workflow je naprosto nepřehledné a nevyhovující. Upravit dle návrhu níže:
Garant — ŘO/ŘD/NGŘ/GŘ — Divizní ekonom — pracovník MK (zašle prostřednictvím IS na MPO
ČR ke schválení) teprve poté schválí — znovu DF — Garant (Na vědomí)
Garant (pokud zadává za něj např. asistentka, musí do zodpovědné osoby uvést jméno garanta, tomu
poté přijde daná aktivita na vědomí. Ve finálním náhledu bude asistentka uvedena jako „Vyřizuje“ stejně
jako je tomu u objednávek)
Schvalování ŘO, ŘD, NGŘ či GŘ dle výše čerpání.
Zamezit možnosti, aby si např. ŘO sám schvaloval akce, které si do MKT plánu zadá sám. Pokud zadá
akci ŘO, schválit ji musí RD.
Možnost zadat též Na vědomí (např. VeO či ŘD příp. dalším zaměstnancům, kteří se podílejí na
přípravě). Pokud se jedná o akci s větším finančním plněním, kdy podepisuje např. NGR, poslat Na
vědomí RO, RD.
Umožnit garantům úpravu v aplikaci i po schválení akce (např. změna data akce).
Poté poslat Na vědomí všem osobám, které byly uvedeny ve workflow. Pokud se bude jednat o změnu
finančního plnění, nutno poslat znovu do workflow. Měla by tam však zůstat i částka původní.
Založení akce:
Typ akce — přejmenovat na Typ aktivity
Hodnocení akce:
s | Slovní hodnocení
« | Počet účastníků (nepovinná položka)
e | Přílohy (např. scan objednávky, faktury, atd.)
Celkové hodnocení — max. pět hvězdiček jako doposud, nedělit na podkategorie
Statistiky:
Akce
Typ akce — rozbalí se nabídka:
seminář/workshop
veletrh
konference
roadshow
prezentace na partnerské akci
jiné (možnost doplnit)
Název akce — vyplnit
Datum konání akce (plně vyhovuje současný kalendář)
Místo konání — rozbalí se nabídka ČR či Svět, jak je tomu doposud
ČR — rozbalí se kraje (zde beze změny) .
Svět — smazat ZZ nechat prázdné políčko k vyplnění
Město — vyplnit
Oblast zaměření — rozbalí se nabídka:
« | Investoři
e © Podpora podnikání (SF EU)
« © Nemovitosti
e | Jiné
Cílová skupina —» rozbalí se nabídka:
Investoři
Podnikatelé (žadatelé ze SF EU)
Státní správa/samospráva
Vzdělávací instituce
Jiné
U oblasti zaměření a u Cílové skupiny umožnit výběr více variant najednou.
Zodpovědná osoba — přejmenovat na Garant — jména v seznamu řadit podle příjmení a ne křestního
jména
Pokud akci zadává jiná osoba (např. asistentka) jako Garanta musí uvést osobu, která je za danou akci
zodpovědná, té potom přijde založená akce Na vědomí.
MKT podpora — za jména pracovníků MK uvést oblast, za kterou je daný pracovník odpovědný, např.
Zuzana Tůmová (web, prop. předměty) nebo Adéla Tomíčková (tiskové zprávy, PR články)
Kromě jmen přidat políčko NE. Na všechny akce není MKT podpora požadována.
Účast za CI — nechat, jak je
Odborná spolupráce externí — zrušit, není to podstatné. Toto info lze zadat do poznámky.
Poznámky — nechat, jak je
Přílohy — nechat, jak je
Stánek — odstranit (CI již stánek nemá)
PR podpora — přidat inzerci, info na web přesunout pod MKT podporu
MKT podpora — rozbalí se nabídka:
Tiskoviny
Propagační předměty
Roll-up, vlaječky, stojany, mísy
Grafické práce
Informace na webu
jiné
Množství a specifikace nechat jak je.
Plánované náklady — nechat jak je
Doplňující informace — tuto ikonu vymazat
Přílohy — např. scan objednávky či faktury
Zdroj financování — doplnit o chybějící údaje (např. CA), Zdroj financování bude hned pod plánované
náklady. DF dodá aktuální číselníky. Tuto kolonku uvidí pouze DF a bude č. MKT akce doplňovat až při
svém druhém schvalování.
Je dodavatel CI — vymazat
Přidat tyto položky:
Priorita akce — na výběr A, B, C
Zapojení MPO ČR — na výběr ANO/NE
Opakování akce — na výběr ANO/NE
Umožnit připojit k akci ostatní MKT aktivity, které s ní souvisí. Např. tisk plakátů na veletrh,
tisková konference v průběhu veletrhu. Bylo by tak jasně vidět, co se k dané akci připravovalo a
v jakých finančních nákladech.
PR
Typ aktivity — rozbalí se nabídka
« Inzerce
e | Média monitoring
e | Setkání s novináři
e © Tisková konference
« | Překlady
Datum/období
Popis — detailně popsat aktivitu
Zodpovědná osoba
Plánované náklady
MKT podpora — rozbalí se nabídka:
« | Tiskoviny
e | Propagační předměty
e — Roli-up, vlaječky, stojany, mísy
« | Grafické práce
* jiné
Množství a specifikace nechat jak je.
Priorita akce — na výběr A, B, C
Zapojení MPO ČR — na výběr ANO/NE
Opakování akce — na výběr ANO/NE
MKT aktivity
Typ aktivity — rozbalí se nabídka:
Tisk
Grafika
Web
Foto služby
Propagační předměty
jiné
Datum/období
Popis — detailně popsat aktivitu
Zodpovědná osoba
Plánované náklady
Priorita akce — na výběr A, B, C
Zapojení MPO ČR — na výběr ANO/NE
Opakování akce — na výběr ANO/NE
Interní akce
Typ aktivity — rozbalí se nabídka
* | Interní časopis
« Intranet
« | Akce pro zaměstnance
Datum/období
Popis — detailně popsat aktivitu
Zodpovědná osoba
Plánované náklady
MKT podpora — rozbalí se nabídka:
Tiskoviny
Propagační předměty
Roli-up, vlaječky, stojany, mísy
Grafické práce
jiné
Množství a specifikace nechat jak je.
Priorita akce — na výběr A, B, C
Zapojení MPO ČR > na výběr ANO/NE
Opakování akce — na výběr ANO/NE
Printscreeny webových aplikací Lotus Notes:
» Dle názvu
Dle míšta Konání
Dle zodp. osoby
Dle divize
* Dlé zdroje financování
Dle typu akče
Dlé dáta akce
Dle odlasti zaměření
© Dratty
10 Stalistika
„B Arehiv
Vše: Móle:A-B-G-D-E-E:
lež
m
£
BlO Eifápě
"Hledání nástroj podpory "23.04.2013
regionech a výsokou
nežáměstánostív
ZJakia:moritorind a žádost | 05,05.2012
o plátouvoPpPř
Jak na manitorino a fádost © 09.10.2012
o platbu voPPĚ
ZJak na monitorina a žádost
úplatu VOPPI
"Jakna monitofng a žádost 04.06.2013
o plálou v OPPI
Zlakná moniforina průjeklu a
žádosto platbu PPI
Jakůa Honitoina projekuá | 01.03.2012
žádost platbu v BEE
08,03,2013
19.01.2012
Jakna Htonitoring projektu a: -20.03.2012
žádosto platbu vOPPE
„lak ná Monitor nrdekí A ÚROK OM
>X-Y-Z- Ostatní |ilrovat
0,00 Kč
0,00 Kč
9,00 Kč
0,00 Kč
0,00 Kč
0,00 Kč
n ná kč
Nersalizováno
Uzavřeno
Uzavřěno
Uzavřená
Uzávřáno
Uzavřeno
Uzavřeno
Uzavřeno
Nereálizováno
Wravřann
+ Dle názvu
Die misla konání
Dlá z—:»Šp. osoty
Dle divizs
Dle zdroje řinanoování
Dls typu zkce
Dla dala skoa
Pa oblaztí žani
„d Drařty:
" dyStatistika
0 _P.i'DhÍ'.'
Název akce/Typ:*
z Mmu akce:“ - Je
Datum kenání: Datum konání.
Dd 1* “Ú_D š
Cilsvá skupina * Í\.':.fbertg_tá!pvou Skupini.
Oblast zaměření " |Vyběrtá oblsští záměření
| Vybar ]
Zádp. osoba > — MVartié Hejret (DVS/ITAAD) s Účastea C1
; Odhorná
spolupráce [externí) |
HT Fodpora *
Požnámky
Přilahy
Stánek:* An Č Na
PR Fodpora C Tieková zpráva L ěr
Týp-MKT Podpary |re )
Předmát Částka:s DPHv Kč - Podrohný popiš
Organeáční náklsvdy ooo Kč
02 Kč
Csnž m
CestovnéHtisty 202 Kč
Fopis o]
Ostatní náklady 000 Kč :
Cens šů
Celková náklady * 000 Kč
Přílohy
Zdroj financování
„le dodavatel C17
Objednávka
idadavatel)
Smlouva
+ Dlá názvu
Ple typu
pla regionu
Dle vytýbření
Neastivní
Nabidky
isvení-splikácé |
Ulice > Kraj Jihomoravský traj
Óbea = Okres Brno. nišsto
GP souřadnice „
Agent Vlastník
Společnost Špolačnost
Telefon Telefon
E-mail E-mail
Další kontakty
Fotografie
[4]s758.004.JFG | ([Jěrě5o07 PG | ([TJe758.008.4PG
Další soubory PI. Hablákaci lace [258 183
Gatuni Autor Poznámka
20.09.2012 | SECHM [ammeycoooeoa
13982011 kEsu. ZA
00102000 pas. EEE
07.10.2008 PAS | mmm
Historie
Celková velikost 13909 m“ | Volné: 13000 m“
„A všechny projekty
Die entity
Dle lidí vtýmu
Dle názvu
Dle nemovitosti
Dle pobídky.
Dle země projektu
Dle zodpovědné osoby
Drafty
Druh projektu
< Gehéroval
> Hřbitov
< Neaktivní
Pobídky dle akceptace
Pobídky dle čísla Jadnacího
Stádium
Typ aktivity
8 Jeslicak tlovy investiční projekt Opravárenslví: « Poptávkový dotaz On-going
Testovaci? © Now investiční projekt © Wroba Poptávkový dotaz On-golna
Celkem 2 dokumenty
Dis ké v lýmu
Stáshém
lé názvu
Dis nemovitosti
Die půbidky
Drafty
Brub projektu
GensrovsÍ
Hřbitov
Pobídky dle akčaplsté
jednacího
» Typ zkfivíty
© jobs
OPPI || Notifikace (M
Bpřikace
Vytvolsno: 12 06 2008 | Změnšné: 1206.213 | Typ projet
| Hlstuí oobiy VO Prmnonts A k ž
EZ Výroba £ Potíž
2 z $lsktrotedhniky
Česká republika
+prztnl
Jméno společnosti Htručný popis projektu
Cilový sektár aktivity
Země původu
, o Aktuálně vytvořená PIP 3102
Datum rozhodnuti 2804008 PR
Datuní: zahájení DB. ZDŠ
činnosti
Poznáníka
F pze
Země matky Generoval IPO
„Název české entity kdo Zdroj Passive / Otkar
Jihororavský Kraj, Libarecký Kraj,
Můrávéko Ký krší
Ostrava, Hrný, Jatlánev, Tretnov
Prétprovaná forma Rozhodnutý region
Břrownfisld Rozhodnutá lokalita
Procento VB tech,
"směru
Telefon E-rsail
0 u |
"Komentář
Datun
Rozhodnutá Iokalita
"Typ oznámení
| Přidat phone eat || Z Přidat nástinu |
Priorita Typ Autór Kentskly Předmět
"), „B *
Příloha č. 2
Programátorský předpis
Programátorský předpis pro vývoj aplikací na web
Rejstřík:
Použité zkratky:
PP — Programátorský Předpis
LN — Lotus Notes
LS — Lotus Script
XHTML - EXtensible HyperText Markup Language
CSS — Cascading Style Sheets
CI - CzechInvest
Použité výrazy:
Jelikož jsou některé Designové prvky v PP popsány v českém jazyce, anglické názvy lze totiž velmi špatně
skloňovat, tak jsou všechny výrazy vysvětleny v tabulce níže.
Český výraz Anglický výraz
Formulář Form Webová služba Web services
Podformulář Subform Sdílený Shared
Stránka Page Akce Actions
Šablona Template Soubor File
Pohled View Knihovna skriptů Script Library
Složka Folder Deklarace Declaration
Pole Field Průvodce Wizard
Sloupec Column
Rámy Framesets
Účel PP:
PP je směrnicí pro programátory kteří vyvíjí aplikace pro webové prostředí. Hlavním účelem PP je
zjednodušení programovacích postupů a zlepšení čitelnosti kódu pro jiné programátory než je samotný autor
kódu. Cílem používání PP je zrychlení vývoje aplikací a programátorská nahraditelnost v kterékoliv fázi
projektu.
Zdroj PP:
Výsledné PP vychází ze třech zdrojů: programátorské zkušenosti (Dan Vrána, Tomáš Bártek, Lukáš
Slavíček), Programátorský předpis vyvíjení aplikací pro Lotus Notes klienta (schválený vedením CI a
diskutovaný programátory), a Pravidla tvorby přístupného webu (http://www.pravidla-pristupnosti.cz/).
Předpis
1. Designové prvky
Tato část PP popisuje všechny designové prvky potřebné a nepotřebné pro vývoj LN aplikací. Každý
developer je s těmito prvky v průběhu své programátorské zkušenosti velmi dobře seznámen, proto tato část
obsahuje spíše rady pro vývoj pro webové aplikace a pravidla pro pojmenování designových prvků.
Obecné pravidla
Jelikož názvy formulářů a stránek jsou vždy tvořeny zkratkou celého názvu formuláře, proto všechny tyto
designové prvky musí mít vyplněnu část Comment ve vlastnostech designového prvku. Text v části
Comment musí být úplným názvem designového prvku.
Příklad: formulář DC bude mít v části Comment text Domestic clients.
Pokud si programátor není jist zda-li název designových prvků jako jsou agenti, webové služby,
podformuláře a knihovny scriptů dostatečně vystihují jejich funkci, tak je programátor povinen vysvětlit jejich
funkci ve vlastnostech designového prvku v části Comment.
Formuláře (Forms)
Používání:
Formuláře se používají jen v částech aplikace kde je třeba dlouhodobě, nebo krátkodobě shromažďovat
případně ukládat data. Pro identifikaci, jestli potřebuji formulář, existuje jednoduché pravidlo: Je-li třeba pro
stránku pole, tak potřebuji formulář. Formuláře se proto používají pro vytváření a zobrazování dokumentů (i
profile dokumentů), tvorbu průvodců, zobrazování dat v dialozích nebo grey boxech, a v neposlední řadě pro
zobrazování pohledů (což jsou tzv. $9$ViewTemplates) a jiných šablonových formulářů. V případě, že
aplikace neobsahuje žádnou Redirect stránku, která by přesměrovala uživatele na určitý formulář, nebo
pohled, tak musí být v aplikaci $$NavigatorTemplate, který se otevře jako první stránka z webu.
Pojmenování: |
Název formuláře by neměl být delší než tři písmena a měl by se skládat z počátečních písmen celého názvu
formuláře. Toto názvosloví platí pro ukládací formuláře, profile dokumenty, formuláře které se otevírají v grey
boxech, nebo formuláře které jsou podřazené jiným formulářům. V případě že je to důležité, tak podřazené
formuláře mají začátek názvu tvořen z nadřazeného formuláře.
Příklady: Domestic Client (celé jméno) - název formuláře bude DC
Trade Show (celé jméno podřazeného formuláře DC) — název formuláře bude DCTS, když
celé jméno nebude nezbytně nutné tak se formulář může jmenovat jen TS.
Speciální formuláře na zobrazování, zobrazování po smazání dokumentu, a průvodce pro tvorbu dokumentu
budou mít předponu malými písmeny a zbytek názvu bude velkými písmeny:
e dsp - zobrazovací formulář
e del—formulář po smazání dokumentu
e wiz — průvodce (wizard)
Příklady: dspHISTORY (historie), delDC (po mazání DC), wizIP (wizard pro tvorbu IP)
V případě že je se formulář používá jako průvodce (wizard) a celý průvodce se skládá z více než jednoho
formuláře, tak musí název formuláře obsahovat krok ve kterém se průvodce zobrazuje.
Příklady: wizIP1 (krok 1), wizIP2 (krok 2)
Formulář pro zobrazování pohledů a hledání ($$ViewTemplate for) má vždy za slovem „for“ celý obecný
název pro skupinu pohledů pro který se používá. Stejný název musí být napsán také v aliasech pohledů
které budou tento šablonový formulář používat.
Příklad: pro pohledy Meeting, PhoneCall, Email, Attachment — bude existovat šablonový formulář
$$ViewTemplate for Activities, a slovo Activities bude zapsáno v alliasech pohledů které formulář pro
zobrazování používají.
lgy formuláře budou mít název podle toho do jaké aplikace se data budou exportovat.
Příklad: Excel.igy
Podformuláře (Subforms)
Používání:
Podformuláře se používají jen pro části formulářů, které se velmi často opakují, nebo kde se daná část
formuláře musí vypočítat podle dat uložených v dokumentu. Podformuláře se v žádném případě nepoužívají
pro greyboxy, nebo dialogboxy.
Pojmenování:
Podformuláře jsou pojmenovány plným jménem a každé nové slovo v názvu začíná velkým písmenem.
Příklad: CommonFields, HistoryFields
Obsah:
Každý podformulář má na začátku a na konci skryté barevné textové značky pro identifikaci začátku a konce
formuláře.
Příklad: BEGIN [název podlormulářej
END [jnázev podformuláře]
Pole (Fields)
Používání:
Na rozdíl od XHTML, pole jsou do formulářů vloženy pomocí LN Designerských prvků. Velikost polí a
viditelnost pole se řeší třídami a css.
POZOR - jestliže vytvoříte nějaké z polí pouze pomocí XHTML, tak si přiděláte spoustu problémů, protože
každé passthrough pole musí mít také LN ekvivalent, jinak IE zobrazu1e Error 404. To samé platí pokud
některé z polí vypočítává chybný obsah.
Pojmenování:
Název pole musí začínat velkým písmenem, pokračovat malými písmeny a každé další slovo je opět velkým
písmenem. Název musí být bez diakritiky.
Příklad: FakturacniUlice
Pole, která jsou „computed for display“ budou obsahovat v názvu pole předponu dsp.
Příiklaď. dspFakturacniUlice
Každý formulář by měl obsahovat pole UNID ve kterém je uložen unigue ID dokumentu který bude pomocí
formuláře vytvořen. UNID jiného dokumentu (ať už nadřazeného, nebo podřazeného) musí být složeninou
názvu formuláře a slova UNID.
Příklad: SCUNID, PUNID, EPUNID
Skrytá pole je dobré obarvit červeně. Názvy polí budou česky kromě tohoto seznamu: UNID, ID, PSPATH.
Výjimkou jsou případy kdy se migrují data z jiné databáze či systému.
Stránky (Pages)
Používání:
Stránky se používají pouze pro html nebo xml dokumenty v kterých není třeba žádného formulářového
prvku, proto jsou stránky vhodným uložištěm pro Name pickery (i pro wizardy), RSS, a nebo pro Redirect
page. Stránky by v žádném případě neměli sloužit pro kaskádové styly, nebo kód JavaScriptu.
Pojmenování:
Stránky jsou pojmenovány plným jménem a každé nové slovo v názvu začíná velkým písmenem. Dále jsou
stránky ukončeny tečkou a koncovkou xml, nebo html (případně htm)
Příklad: NamePicker.html, Help.html, HelpDeskRss.xml
Pohledy, Složky (Views, Folders)
Používání:
Pohledy a složky se používají pro zobrazování části dat dokumentů, výsledky hledání a pro práci
s dokumenty na pozadí (backend práce s dokumenty). Jelikož zobrazení obsahu pohledů a složek na webu
není zrovna uživatelsky přívětivé, tak se obsah dokumentů zobrazuje pomocí zobrazovacích šablon
($$ViewTemplate for). Samotný pohled/složka musí mít ve vlastnostech vybranou položku „Treat views
content as HTML". Dále musí mít v alliasu vyplněn název který je shodný se slovem který je uveden za „for“
u zobrazovacího formuláře. No a poslední velmi důležitá věc je zobrazení samotných dat, které jsou nejlepší
zobrazit v tabulce. Proto by všechny pohledy měli obsahovat tagy ,, pro hlavičku tabulky a
, , pro obsah tabulky. Tyto a ostatní tagy v pohledech/složkách mohou být uloženy
v designovém prvku sdílené sloupce.
Pojmenování:
Veřejný pohled je pohled/složka která je viditelná pro uživatele, uživatel může otevřít pohled přes hyperlink
s koncovkou ?OpenView, a také když se pohled zobrazuje pomocí formuláře $$ViewTemplate. Jméno
pohledu se odvozuje od hodnoty která se nachází v hyperlinku. Název pohledu musí být napsán bez
diakritiky, bez mezer, a slova vnázvu jsou oddělena velkými písmeny. Pokud se pohled neotevírá
z hyperlinku, tak je pojmenování pohledu v rukou programátora. POZOR — v názvu pohledu nepoužívejte
lomítka.
Příklad: Dle mateřské společnosti pohled se bude
jmenovat DleMaterskeSpolecnosti
Skryté pohledy, což jsou pohledy které se používají pro běh kódu a pro (©Adbcolumn KAdblookup, mají
v názvu uvedeno písmeno (písmena) označující formulář, ve kterém byla data pořízena. Pokud budou data
z více formulářů, oddělí se názvy formulářů písmenem „a“. Za názvy formulářů je „by“ a po té by měl název
pokračovat názvem fieldu, podle kterého je pohled kategorizován, nebo seřazen. Název pohledu musí být
v závorkách. Pohled nesmí obsahovat akce, naprogramované metody/události a globální metody/události.
Příklad: (FbyName), (FaLbyFullName)
Skryté pohledy ve kterých se zobrazují výsledky hledání mají dva názvy: normální název a allias. Normální
název je vždy v závorkách, to aby bylo jasné že to je skrytý pohled, a název se skládá ze slova srch + název
formuláře/formulářů (oddělené „a“). Alias je naopak složenina srch + názvy formulářů za sebou.
Příklad: (srchFaL) a allias srchFL :
Pokud by mělo dojít k tomu, že budou dva pohledy ze stejným jménem, tak se na konci názvu napíše číslo
pohledu. V případě, že je to skrytý pohled, tak se číslo napíše před zpětnou závorku. Pro takové pohledy
platí, že se do komentáře napíše čím se daný pohled liší.
Příklad: DleMaterskeSpolecnosti2, (FbyName2)
POZOR - Embedded pohledy a picklist pohledy se ve webové designu nepoužívají. Embedded pohledy se
používají pouze v dolarových formulářích.
Sloupce (columns, shared columns)
Používání:
Pro sloupce pohledů ve webových aplikacích je dobré používat sdílené sloupce a to proto, že výrazně
urychlují vytváření pohledů. Můžete si takto vytvořit sloupce které se velmi často opakují, a jelikož ve web
prostředí vám jde v první řadě o data, tak si sloupec jednou nastavíte a už neřešíte jeho vlastnosti, nanejvýš
jeho obsah. Ohledně obsahu, osvědčené pravidlo při vytváření sloupců je ošetřit sloupec, pro prázdnou
hodnotu, proto je dobré do sloupce napsat anbsp; když je hodnota sloupce prázdná.
Příklad: ©!lf(InvestmentType=""; "8nbsp;“; InvestmentType)
Nevýhoda těchto sloupců je, že když je jednou přesunete pomocí drag and drop, tak se sloupci vytratí jeho
vlastnost sdílení a pak jakékoliv další změny ve sloupci nebudou aplikovány globálně (no snad to v LN brzy
opraví).
Pojmenování:
V pohledech které jsou veřejné, nebo-li pro uživatele, se názvy sloupců přidělují podle přání zákazníka, nebo
podle programátorského odhadu.
Příklad: Uživatelské jméno
V pohledech určených pro běh kódu se sloupce pojmenovávají podle toho co se ve sloupcích zobrazuje.
Takže jestli se zobrazuje ve sloupci pole UserName, tak se sloupec musí jmenovat taky UserName.
Sloupce které jsou skryté mají název taktéž podle jména pole které se v pohledu zobrazuje, a navíc obsahují
předponu [Hidden], např [Hidden] UNID.
Jestliže je sloupec sdílený, tak je třeba v názvu designového prvku sdíleného sloupce také zmínit jméno
formuláře ve kterém se pole nachází.
Příklad: (P) Uživatelské jméno — název designového prvku a sloupec se bude jmenovat Uživatelské jméno
Agenti (Agents)
Používání:
Agenti ve webovém prostředí slouží pro tři akce: agenti kteří běhají plánovaně na pozadí, agenti kteří se
spouštějí z formulářových událostí „WebOvueryOpen“ a „WebOAueryClose“, a agenti kteří se spouštějí pomocí
URL AgentName?OpenAgent.
Komentování:
Složitější agenti musí na začátku kódu napsaný komentář o tom co agent vlastně dělá a jak se chová,
případně co musí mít nastaveno aby správně fungoval.
Pojmenování:
Název agenta by měl vystihovat jeho funkcí a název formuláře pro který funguje. Název je proto složeninou
slov kde na začátku je název formuláře oddělený tečkou od názvu funkce. Funkce agenta je pojmenována
bez mezer, kde každé nové slovo začíná velkým písmenem. Pokud název agenta nevystihuje jeho funkci,
tak musí programátor vyplnit položku Comment ve vlastnostech Agenta.
Příklady: P.ChangePassword, G.RemoveDocumení
Webová služba (web services)
Používání:
Webové služby se používají pro propojení více systémů. U webové služby jsou vždy dva subjekty: první
subjekt publikuje službu, druhý subjekt volá službu a přijímá výsledky publikované službou. Webové služby
v Lotus Notes se podobají agentům, až na několik odlišností, které budou vysvětleny níže.
Pojmenování:
Tady platí stejné pravidlo jako bylo popsáno u Agentů.
Nastavení služby:
V části Options musí mít služba řádek s WINCLUDE "lsxsd.iss". Dále, služba samotná se nepíše jako agent,
ale jako třída, kde hlavní třída služby je shodná s hodnotou PortType class ve vlastnostech služby. Další
drobnost kterou je dobré vědět je, že veřejné proměnné by měli být seřazeny podle abecedy, jinak se může
stát že se služba bude chovat neadekvátně. To zda-li se příjemce bude muset do služby logovat, nebo bude
služba otevřená se řídí v ACL aplikace a ve vlastnostech služby. Hodnota „run as web user“ požaduje po
konzumentovy autentifikaci. Než službu nastavíte, tak nastavte její „security level“ na hodnotu 2,
programovací model na RPC, a SOAP message na Doc/literal. Pro další informace o webových službách se
zeptejte svých zkušenějších kolegů, koukněte na web, nebo si prohlídněte webové služby v Obee.
Pro testování webových služeb použijte prográmky které jsou zdarma, jako třeba SoapUl, nebo Eclipse.
Velmi užitečné je také používat Messagebox, který vypisuje informace do logu a na konzoli. V případě že
chyba není v kódu, ale je v SOA dotazu, tak používejte error handling WS FAULT. Skvělá ukázka tohoto
error handlingu se nachází v Obee.
Soubory, Styly (Files, Style Sheets)
Používání:
Sekce Soubory se používá pro ukládání obrázků, které se používají v aplikaci. Naproti tomu sekce Styly se
používá na ukládání kaskádových stylů. Jelikož práce s oběmi designovými prvky není zrovna
nejpohodlnější, tak na vývojovém serveru běží WebDav. WebDav umožňuje programátorům připojení
databáze jako externí disk, ale tato funkce není nejlépe podporována ve Windows a proto je dobré si pro
práci nainstalovat klienta jako třeba NetDrive. Do části stránky se designové prvky přidávají pomocí tagů
![]()
a , nebo pomocí výběru „Insert source“ v události HTML head content.
Pojmenování:
Obrázky musí být pojmenovány podle následujícího pravidla: kde-funkčnost rozlišovač.
Kde — určuje kde se obrázek nachází. Hodnota by měla být co nejvíce obecná, aby to vyhovovalo správné
identifikaci.
Příklad: header, btn, ico, table, tab
Funkčnost — určuje k čemu obrázek slouží.
Příklad: bg, close, sort, send
Rozlišovač — rozlišuje obrázky které jsou stejného charakteru.
Příklad: table-sorť up, table-sort down, menu-line ae, menu-line ae up, menu-line ae down
V případě, že hodnota „kde“ není zcela známa, tak se hodnota do názvu nezapisuje.
Příklad: key lock, key unlock
Styly musí být pojmenovány podle jejich funkčnosti. Více hodnot v názvu stylu se odděluje pomlčkou.
Příklad: resef.css, print.css, form-ae.css
Knihovny skriptů (Script Libraries)
Používání:
Knihovny skriptů, se používají ve chvíli kdy některý z kódu se používá ve více než jednom designovém
prvku. Pokud se kód používá jen na jednom místě, tak není třeba uvažovat o využití knihoven. Knihovny
skriptů mohou obsahovat kód třech programovacích jazyků: Lotus Script, Java Script, a Java. Knihovny
skriptů se do designových prvků přidávají několika způsoby:
Lotus Script — pomocí příkazu „Use“ v události Option
Java Script — pomocí výběru „Insert source“ v události JS Header, nebo pomocí tagu