Sjednocení a redesign redak ního a informa ního systému autobazaru. Bc. Jind ich Hulín-Mihalec

Rozměr: px
Začít zobrazení ze stránky:

Download "Sjednocení a redesign redak ního a informa ního systému autobazaru. Bc. Jind ich Hulín-Mihalec"

Transkript

1 ƒeské vysoké u ení technické v Praze Fakulta informa ních technologií Katedra softwarového inºenýrství Diplomová práce Sjednocení a redesign redak ního a informa ního systému autobazaru Bc. Jind ich Hulín-Mihalec Vedoucí práce: Ing. Milan šaloudek Studijní program: Informatika Obor: Webové a softwarové inºenýrství (magisterský) 6. kv tna 2013

2 iv

3 v Pod kování Na tomto míst bych cht l p edev²ím pod kovat vedoucímu a zárove zadavateli své práce Ing. Milanu šaloudkovi za pomoc a uºite né rady a moºnost realizace toho projektu. Také bych cht l velmi pod kovat v²em len m své rodiny a svým p átel m za podporu b hem psaní této práce.

4 vi

5 vii Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). Jind ich Hulín-Mihalec

6 viii

7 Abstract The objective of this work is to design and imlement new information system of an used car company which will unife existing content management system of their websites and sales system. The work at the rst place describes the company, its needs, internal processes and current state of their system they've been using. Afterwards the funcionality of the systems takes its place as well as their bright and dark sides or functions of the systems which need to be kept or expanded and those which need to be changed or removed. In connection with the current state the problem is described in the next chapter together with the requirements to the new system. According to these requirements the analysis of the new system has been made and the next chapter is dedicated to that. It consists of description of requirements of the new system, description of users' roles and entites of the system and their relationships. At the end of this chapter some complicated precesses are described. The analysis closely follows a next chapter which deals with the design of the system and on the basis of requirements and analysis determines exact solutions for implementation. In the following chapter the implementation of the solution is parsed and described. Mainly it's about structure of the system and how it works in general. It's place in this chapter has also security of the application. The last chapter is about company's websites. A part of the assignment was to make necessary modications of the websites to connect them to the new system and also connect them to the Facebook page of the company. Keywords Information system, Used car company, Content management system, Web analysis, System analysis, System design, System imlementation, Facebook ix

8 x

9 Abstrakt Cílem této práce je navrhnout a implementovat nový informa ní systém autobazaru, který bude sjednocovat dosavadní redak ní systém webových stránek a prodejní systém. Práce na prvním míst popisuje samotný autobazar, jeho pot eby, interní procesy a sou asný stav systém, které pouºívá. Dále je popsána jeho funkcionalita, jeho sv tlé i stinné stránky, které funkce systému je pot eba zachovat nebo roz²í it a které naopak zm nit nebo dokonce zru²it. V návaznosti na popsaný sou asný stav je v dal²í kapitole popsán samotný problém a poºadavky na nový systém. Na základ t chto poºadavk je pak provedena d kladná analýza, která je v nována dal²í kapitola. Analýza zahrnuje popsání uºivatelských rolí, entit a jejich vztah a návrh databáze. Na konci se tato kapitola zabývá rozborem n kterých sloºit j²ích proces. Na analýzu úzce navazuje dal²í kapitola, která e²í návrh systému a na základ poºadavk a analýzy ur uje konkrétní e²ení, která budou pouºita p i implementaci. V následující kapitole je jiº rozebrána a popsána samotná implementace e²ení. Popsána struktura systému a to, jak celkov funguje. Sv j prostor v této kapitole má i zabezpe ení aplikace. Poslední kapitola se v nuje webu spole nosti. Sou ástí zadání bylo také provedení pot ebných úprav webových stránek spole nosti pro propojení s novým systémem a s Facebook stránkou spole nosti. Klí ová slova Informa ní systém, Autobazar, Redak ní systém, Webová analýza, Analýza systému, Návrh systému, Implementace systému, Facebook xi

10 xii

11 Obsah 1 Úvod 1 2 Cíl práce 3 3 Stávající systém a jeho historie Webové stránky Z pohledu uºivatele Z pohledu programátora Redak ní systém Z pohledu uºivatele Z pohledu programátora Account - systém pro prodejce Z pohledu uºivatele Z pohledu programátora Popis problému Pro nový systém? Funk ní poºadavky Jednotný systém pro administrátory i prodejce Uºivatelské a jejich role P ihla²ování do IS Vyhledávání v IS Volba prodejny prodejce Editace hlavi ky a pati ky webu Správa multimédií Mapy Bannery Správa voz Správa objednávek Správa dokument objednávek Dlouhodobé pronájmy Správa prodejen a prodejc Zákazníci Komunikace se zákazníky Alarmy xiii

12 xiv OBSAH ƒlánky Skrývání poloºek Propojení stránek s Facebookem spole nosti Nefunk ní poºadavky UI systému Zabezpe ení systému a dat Roz²i itelnost systému Optimalizace pro mobilní za ízení Technologie Analýza nového systému Entit systému a jejich vztahy V z Zna ka Model Skupina voz Typ historie Historie vozu Zm na ceny vozu Typ p íslu²enství P íslu²enství vozu Výbava vozu Parametr Jednotka Hodnota parametru Hodnota parametru vozu Prodejna Prodejce Administrátor Právo administrátora Komunikace Dotaz vozu Poptávka nancování Hlídací pes Odeslaný v z Kontakt Zákazník Poznámka komunikace Typ komunikace Zdroj zákazníka Objednávka Poloºka objednávky Úprava vozu Banka Poji² ovna Faktura

13 OBSAH xv Zp sob platby Smlouva Protokol P esun vozu ƒlánek Sloºka lánk Obrázek Sloºka obrázk Soubor Sloºka soubor Mapa Místo mapy Banner Spole nost Stát Kraj Okres Poloºka menu Uºivatelské role Superadmin Hlavní administrátor Administrátor voz Administrátor komunikace se zákazníky Administrátor lánk a multimédií Prodejce Interní procesy P esun vozu Objednávka vozu Komunikace se zákazníkem Návrh e²ení nového systému Prost edky a technologie PHP HTML CSS JavaScript AJAX SQL MySQL Moduly jquery Bootstrap jquery File Upload prettyphoto CKEditor mpdf

14 xvi OBSAH PHPMailer Webové sluºby Google Maps API Facebook API AddThis Uºivatelské rozhraní a navigace Struktura a architektura systému Databáze Adminer Implementace nového systému Sloºky a soubory systému T ídy Generování stránky Pouºití modul a sluºeb jquery Bootstrap CKEditor prettyphoto mpdf PHPMailer Google Mapy Zabezpe ení Úpravy webových stránek Úvodní stránka Katalog voz Detail vozu ƒlánky Formulá e Sociální sít a jejich propojení s webem Záv r 77 A Seznam pouºitých zkratek 85 B Obsah p iloºeného CD 87

15 Kapitola 1 Úvod Toto téma jsem si vybral pro svou diplomovou práci, protoºe jsem v n m vid l skv lou p íleºitost spojit znalosti a zku²enosti z r zných oblastí, které jsem do té doby nabyl a uº b hem studia a práce, r zných brigád nebo jen pomocí v rodinné rm. B hem práce na informa ním systému jsem p edev²ím vyuºil n kolikaleté zku²enosti s vývojem CMS, internetových obchod a jiných webových aplikací. Navíc jde o informa ní systém autobazaru, kdy mohu pro lep²í porozum ní pot eb spole nosti nebo interních proces uplatnit zku²enosti z letní brigády v autobazaru. Sou ástí informa ního systému je i práce s objednávkami, fakturami a dal²ími dokumenty, ve kterých se bez problému orientuji a vím jaké mají mít náleºitosti nebo jak se ú tuje DPH, protoºe jiº od gymnázia pomáhám v rodinné rm, pro kterou v sou asnosti spravuji i internetový obchod, kde se paragony a faktury také vyskytují. Podobné projekty jsem tedy jiº e²il a mám také zku²enosti vhodné pro projekt sjednocení a implementace informa ního systému autobazaru. Nikdy jsem ale ne e²il spojení v²ech t chto v cí dohromady. Výb r tohoto projektu byl pro m jak výzva, tak moºnost získání dal²ích zku²eností. Systém se bude vyvíjet pro reálný a fungující autobazar, který si z r zných d vod nep ál být v práci jmenován, bude tedy p ípadn ozna ován jako Autobazar AB. Autobazar jiº funguje p ibliºn 10 let, b hem kterých pro²el mnohými zm nami, jako jsou jsou otevírání a ru²ení prodejen, zavedení franchizingu, vykupování voz nebo roz²í ení svých sluºeb nap. o dlouhodobé pronájmy nebo nabízení prodlouºené záruky. M ºe vypadat divn, ºe jsem nezmínil vykupování voz, coº je u autobazar b ºná v c. Autobazar AB ale nakupuje vozy p edev²ím ze zahrani í, dováºí je do ƒech, kde je podrobuje d kladnému p edprodejnímu servisu. Ze za átku své innosti se spole nost cht la tvá it více jako autosalon a slovo autobazar rad ji nepouºívat. Po nástupu krize a sníºení prodej voz ale museli zm nit strategii prodeje, nabídku voz i své sluºby. Na za átku nap. byla k vozu poskytována záruka 1 rok, nyní pouze nabízejí moºnost si záruku dokoupit. V sou asnosti má spole nost jen jednu prodejnu v Praze, kde má vystavenu v t²inu voz. Sídlo spole nosti je ale v m ste ku za Prahou, kde má servisní st edisko, centrální sklad a kancelá e. Abych se vrátil zpátky k informa nímu systému, tak autobazar stále pouºívá stejný systém jako na za átku. Samoz ejm stejn jako autobazar, tak i tento systém pro²el mnohými zm nami. Z p vodního systému, který umoº oval spravovat v podstat jen katalog voz a obsah webu na úrovni text a obrázk, se stal systém nep eberných nan ních a komunika ních p ehled, objednávek, dokument a velkého mnoºství r zných dat. Protoºe toto 1

16 2 KAPITOLA 1. ÚVOD na za átku nikdo nep edpokládal a i b hem vývoje a roz²i ování funkcionalit bylo obtíºné p edpovídat, jakým sm rem se bude systém ubírat dál, vznikl za t ch 10 let jeho fungování v systému trochu chaos a ob as to podle slov vedení autobazaru dokonce vypadalo, ºe si systém za íná ºít vlastním ºivotem. V posledních letech se systém poda ilo stabilizovat, ale pot eba jeho upgradu byla ím dál tím v t²í, protoºe n které v ci v n m ne²ly ud lat nebo by náklady na n byly p íli² vysoké. Podrobn ji je stávající systém popsán v následující kapitole Stávající systém. Celkov je práce rozd lena do ²esti kapitol, úvod a záv r nepo ítaje. První kapitola jiº byla zmín na, pojednává o vlastnostech, funkcích a neduzích stávajícího systému. Zmi uje ale i n která dobrá e²ení problému, ze kterých se pak vychází p i vývoji nového systému. V dal²í kapitole je popsán samotný problém, který se e²í, a p edev²ím pak poºadavky na nový systém. Na základ t chto poºadavk je v dal²í kapitole nový systém d kladn zanalyzován, jsou popsány a denovány uºivatelské role, entity a jejich vztahy a jsou rozebrány interní procesy. Následující kapitola pak podle poºadavk a analýzy sestavuje návrh e²ení. Kapitola se zabývá navigací, jaké prost edky budou pouºity, nebo jakou strukturu bude mít databáze. V p edposlední kapitole je popsána samotná implementace systému, ukázána jeho struktura, uvedeny a popsány pouºité prost edky, technologie a externí moduly, kterých systém vyuºívá. Poslední kapitola e²í úpravy webových stránek v návaznosti na nasazení nového systému. Na úplném konci je v záv ru mimo jiné popsána reakce uºivatel, coº jsou p edev²ím zam stnanci autobazaru, na nový systém a zku²enosti z vývoje toho systému. Na záv r úvodu bych je²t vysv tlil n které pojmy a výrazy, které jsou v textu práce pouºívány. ƒasto se pouºívá výraz "správa"n jakých poloºek, nap. vozu, objednávek nebo lánku. Tento pojem hromadn ozna uje moºnost p idávání, editace a mazání poloºek a p ípadn dal²ích operací, které jsou pro dané poloºky dostupné. Dal²ími výrazy jsou web, webové stránky nebo front-end, které ozna ují jedno a to samé a to ve ejnou ást systému pro nep ihlá²ené uºivatele. U stávajícího e²ení v²ak tato ást obsahuje i neve ejnou sekci pro p ihlá²ené zákazníky a prodejce. Opa ným pojmem je back-end, který ozna uje neve ejnou ást systému, která pro vstup vyºaduje autentizaci uºivatele. U stávájícího systému pojem back-end ozna uje jak redak ní systém, tak systém pro prodejce. U nového systému je to pak celý informa ní systém. Pojem informa ní systém (IS) si také zaslouºí krátké vysv tlení. V p ípad Autobazaru AB jde o systém, který umoº uje správu v²ech poloºek, které jsou pouºívané na webu (vozy, lánky apod.) a zárove e²í n které interní systémy, jako je vy izování objednávek, komunikaci se zákazníky nebo p esuny voz mezi prodejnami.

17 Kapitola 2 Cíl práce Cílem této práce je vytvo it nový informa ní systém pro autobazar, který nahradí dosavadní zastaralé a ²patn spravovatelné systémy, které autobazar nyní pouºívá. Cílem samoz ejm není jen samotné vytvo ení a nasazení systému, ale p edev²ím zefektivn ní práce zam stnanc, zjednodu²ení p ístupu k dat m a zavedení po ádku do jejich evidence. Do stávajícího systému se tedy b hem 10 let jeho fungování p id lávalo mnoho v cí, které se asem bu zm nily nebo se i p estaly pouºívat. Od nového systému se tedy o ekává i to, ºe v n m nebudou ºádné p ebyte né a zastaralé funkce nebo sekce a tím se celkov zjednodu²í a zp ehlední. A na konec dva nejd leºit j²í cíle této práce, které jsou zárove i hlavními d vody autobazaru pro nákup nového systému, jsou sníºení náklad, reºie a zvý²ení zisk. Toho by m lo být dosaºeno zefektivn ním práce, které nový systému umoºní, a získáním nových zákazník p edev²ím ze sociálních sítí. Náklady se pak sníºí tím, ºe údrºba systému a p ípadné roz²í ení budou v novém systému mnohem jednodu²²í neº v dosavadních dvou, kdy se ada v cí musí d lat duplicitn. 3

18 4 KAPITOLA 2. CÍL PRÁCE

19 Kapitola 3 Stávající systém a jeho historie Tato kapitola popisuje stávající e²ení systém, se kterými se v Autobazaru AB pracuje. Jde o t i systémy, které pracují se stejnou databází a jsou v mnoha ástech propojené. Konkrétn to je systém front-endu, tedy webové stránky, a dva systémy back-endu - redak ní systém a systém pro prodejce nazývaný Account. P vodn byly pouze webové stránky a redak ní systém. Account vznikl dodate n a jeho sou asná verze je dokonce jiº druhá. Jde tedy z t chto t í systému o ten nejnov j²í. Byla snaha n které v ci z redak ního systému p esunout pod nov j²í a spolehliv j²í systém Accounta. To se ale ne vºdy povedlo, protoºe vedení spole nosti bylo zvyklé na redak ní systém a jeho propojení s Accoutem nebylo v n kterých p ípadech snadno e²itelné, a mnoho v cí se tak dlouho odkládalo nebo v bec neud lalo. Nyní je situace taková, ºe se ada v cí e²í jak v redak ním systému, tak v Accountu, a jsou tedy duplicitn, a kdyº se n co upravuje, musí se to d lat nadvakrát. Tato kapitola neanalyzuje ani ne e²í problém stávajícího s systému, ale pouze ho popisuje, a to kaºdý systém zvlá² a ve dvou ástech. V první ásti je systém popsán z pohledu uºivatele a v druhé z pohledu programátora. 3.1 Webové stránky Z pohledu uºivatele V sou asné dob má autobazar webové stránky, kde hlavní a zárove výchozí stránkou je katalog voz. Vozy v katalogu lze ltrovat podle mnoha r zných parametr, zna kou a cenou po ínaje a pohonem 4x4 nebo typem záruky kon e. Proklikem p es poloºku se vstoupí na detail vozu, kde jsou na jednom míst ve²keré informace o voze. Ve ejn p ístupné jsou fotograe, název, popis, parametry, výbava, p íslu²enství, soubory a dal²í. Jsou zde také kontakty na prodejní místo, prodejce a odkazy na adu formulá pro rezervaci, dotaz na prodejce nebo zadání poptávky jiného vozu. Stránky mají také neve ejnou ást pro p ihlá²ené prodejce, kte í mohou p es dal²í formulá e v kart vozu ºádat o p esun vozu na prodejnu, vytvá et rezervace a objednávky voz pro n jakého zákazníka, nebo p idat k vozu dotaz, kdyº zákazník kontaktuje prodejce ne p es web, ale p es telefon, nebo osobn. P ihlá²ený prodejce si v detailu vozu m ºe 5

20 6 KAPITOLA 3. STÁVAJÍCÍ SYSTÉM A JEHO HISTORIE také zobrazit historii vozu, kde vidí historii cen, co se s vozem d lo p ed nasazením do prodeje, jaké na n j byly poptávky, kdy a kam byl p esouván a také d leºité interní soubory. Dále jsou na webu stránky s formulá i pro výkup voz a zadání poptávky na n jaký v z ur itých parametr. A je²t na stránce Franchizing je schovaný formulá pro zájem o spolupráci. Ten se ale jiº nevyuºívá, protoºe spole nost po n kolika ²patných zku²enostech od franchizingu upou²tí. Zbylé stránky jsou vesm s oby ejné lánky, kde lze najít informace o spole nosti a jejích sluºbách nebo informace o vozech, nap. jaký je rozdíl mezi automatickou a manuální p evodovkou. Trochu speciálním lánkem je stránka Napsali o nás, kam se dopl ovaly informace, kdyº se Autobazar AB objevil n kde v médiích. Stránka je uº ale n kolik let neaktualizovaná. Odli²nou kapitolou je je²t sekce kontakty, která je trochu d laná ve stylu katalogu, kdy na úvodu je seznam prodejen obohacený o bannery infolinky, centrály a servisního st ediska a v detailu prodejny jsou pak fotograe, její prodejci, mapa a dal²í informace. V sou asné dob, kdy je pouze jedna prodejna, ale seznam trochu postrádá smysl. Podobn jako mají prodejci svou neve ejnou ást, existuje neve ejná ást i pro registrované zákazníky. V tomto zákaznickém rozhraní m ºe uºivatel editovat své osobní údaje, které se pak pouºívají pro jeho p ípadné kontaktování autobazarem nebo p i vystavování r zných dokument. Také má k dispozici svou zákaznickou historii u Autobazaru AB, to znamená p ehled ve²keré poptávky, které provedl p es formulá e na webu, objednávky nebo koup vozu. Bohuºel moºnost se zaregistrovat není náv²t vníky webu moc vyuºívána. V sou- asné dob je z celkových cca 3000 zákazník zaregistrováno pouhých Z pohledu programátora Stránky (stejn jako i redak ní systém) byly p vodn jednovrstvé architektury, tedy v jednou souboru se odehrávalo v²e - SQL dotazy na databázi, zpracovávání dat i sestavování HTML kódu. Coº je velice nesystémové a náro né na orientaci v kódu. Nap. skript pro administraci voz má takto cca 4500 ádk. N které skripty jiº byly p ed lány do t ívrstvé architektury, ale zrovna administrace voz, která to uº dlouhou dobu pot ebuje nejvíce, ji práv kv li svému rozsahu nemá. U webu byly nap íklad p ed lány skripty katalogu, detailu vozu a v t²iny formulá v etn výkupu a hlídacího psa (poptávka). V²echny ostatní stránky jsou ale stále nep ed lané a a jde o stránky, které mají v podstat stejnou strukturu, tak z hlediska databáze, skript a administrace nemají jedinou v c spole nou. Úpln na za átku totiº neexistovalo nic jako entita oby ejný lánek, který by bylo moºné pouºít na r zných místech systému, ale ke kaºdé stránce systému se p istupovalo individuáln. Na za átku byly nap. jen lánky o spole nosti, které byly v DB v tabulce o_spolecnosti. ƒasem se d laly lánky o vozech, které se v databázi nazvaly dulezite_informace a takto se po pokra ovalo i p i dal²ích roz²í eních nejen u lánk. Skripty, které byly p ed lány do t ívrstvé architektury, jsou relativn nové, dob e a p ehledn psané a p edev²ím se v nich jiº pracuje s objekty. Ty byly poprvé nadenovány v samostatném (alespo co se skript týká) systému pro prodejce zvaném Account, který je zhruba t i roky starý. Práce s objekty velice usnadnila práci jak v samotném Accountu, tak na stránkách a v redak ním systému, kam jsou t ídy includovány, a je tak moºné v nich s nim pracovat. Systém Account je podrobn popsán na konci této kapitoly.

21 3.2. REDAKƒNÍ SYSTÉM Redak ní systém V redak ním systému Autobazaru AB je n kolik uºivatelský rolí nap. pro editaci voz nebo sledování a správu poptávek a komunikace se zákazníky. Uºivatelské role ale v této kapitole probírány nebudou, protoºe jde vºdy v podstat jen o omezení práv super administrátora.nedávno do²lo ve spole nosti k n kolika personálním zm nám a uºivatelské role v sou asnosti p esn neodpovídají práv m jednotlivých zam stnanc pro p ístup k dat m v systému. Redak ní systém bude tedy popsán komplexn bez ohledu na uºivatelské role Z pohledu uºivatele Redak ní systém je rozd len do sedmi hlavních sekcí - Katalog, Objednávky a p esuny, P ehledy, Prodejny, Oslovení zákazník, Kariéra a Obrázky. Sekce Katalog má mnoho podsekcí jako jsou Zna ky a modely, Dodavatelé, Banky a jiné správy poloºek více i mén souvisejících s vozy. Hlavními podsekcemi jsou ale katalogy voz, které se d lí na ekonomické, p edvád cí, nové, v komisním prodeji a vozy classic (veteráni). Pro uºivatele takto rozd lené katalogy nejsou úpln ideální. ƒasto se totiº stává, ºe n jaký v z je v jiném katalogu, neº si uºivatel myslí, a v kombinaci s mnoha moºnostmi ltrování je pro n j problém v z najít. Dál se v katalogu dají editovat vozy, jejich obrázky, soubory, dotazy zákazník a prohlíºet historii. P ímo v editaci vozu je jeden extrémn dlouhý formulá, kterým se na jednom míst e²í parametry vozu, jeho nancování, p edprodejní servis, d leºitá data o voze, systémové v ci, p íslu²enství a výbavu. Toto si uºivatelé op t zrovna nechválí uº jen proto, ºe jediné tla ítko pro uloºení je aº naspodu formulá e a také chybí varianta pro uloºení a z stání ve formulá i. Vedle toho není ani moºné p ejít z edita ního formulá e nap íklad k obrázk m vozu. Je t eba se vrátit zp t do seznamu voz a tam kliknout na p íslu²nou ikonku. Obrázky i soubory je pak sice moºné nahrát hromadn, ale jen po deseti a kaºdý soubor musí být na disku vybrán samostatn, coº je v p ípad nahrávání t eba i 70 fotograí dost zdlouhavé. Dotazy na v z budou popsány pozd ji spole n s dal²ími typy komunikace se zákazníky. Dal²í podsekce sekce Katalog jsou nap. Dodavatelé, Banky, Poji² ovny, Zna ky a modely nebo Skupiny voz. V²echny tyto sekce mají spole né to, ºe na jejich úvodu je seznam poloºek, ze kterého je pak moºné se dostat k p idávání poloºek, editaci nebo mazání. Poloºky se pak p i azují v edita ním formulá i vozu. Dal²í sekcí po Katalogu jsou Prodejny. V této ásti redak ního systému se spravují jak prodejny, tak prodejci. Jedna prodejna m ºe mít více prodejc a to samé platí i naopak, protoºe nap. obchodní editel je jako prodejce u v²ech prodejen uº jen proto, aby byl uveden v kaºdém detailu vozu a prodejny. Administrace prodejen a prodejc je celkem dob e ud laná aº pár v cí, jako je historická moºnost zadávat jazykové mutace nebo n kolik zahrani ních sklad mezi prodejnami, které se uº dávno nikde nepouºívají. Trochu v t²í nedostatek je, ºe nelze p i azovat prodejce k prodejnám, lze to pouze naopak. V sekci Objednávky a p esuny jsou, jak název napovídá, odkazy na p ehledy objednávek a p esun voz mezi prodejnami a vedle toho také p ehledy prodej a dokument, které s objednávkami a prodeji souvisí, tedy faktury, smlouvy a prodejní protokoly. Tento p ehled ale vznikl jakýmsi nedorozum ním a zákazník ho vlastn v bec necht l a nepouºívá ho. Nicmén se tam uº nechal. Co se týká p ehled objednávek a prodej, tak jde pouze o strohý p ehled, a pokud chce administrátor s poloºkou n co d lat, je odkázán do systému pro prodejce.

22 8 KAPITOLA 3. STÁVAJÍCÍ SYSTÉM A JEHO HISTORIE V podsekci p ehledy má pak ve²keré p esuny voz, které se kdy uskute nily, ale i ty, které se je²t neuskute nily. Ty také m ºe schválit nebo zamítnout. Samoz ejm je v p ehledu (jako i v jiných) moºnost ltrace podle stavu a data vytvo ení. Velmi jednoduchá sekce Kariéra pracuje pouze s pár lánky, i p esto má ale t i podsekce. Franchizing, Volná místa a Externí spolupracovník. V kaºdé v t chto podsekcích je seznam lánk. V posledních dvou je ale lánek jen jeden. V podsekci Franchizing jich je sice více, ale na stránkách se pak stejn zobrazují v podstat jako jeden na jedné stránce pod sebou. A v této podsekci se ani ne e²í poptávky na franchizing zadané p es formulá. Ty jsou z n jakého d vodu v sekci P ehledy. Ve v²ech podsekcích pak lze lánky p idávat, editovat i mazat. U lánku lze ale zadat jen název, text a obrázek. Sekce Oslovení zákazník je pom rn r znorodá. P lku podsekcí tvo í r zné lánky, o kterých by se dalo íct, ºe mají oslovit zákazníky a p im t je koupit si v z v Autobazaru AB. Tro²ku úsm vné je, ºe vedle t ch n kolika podsekcí s r znými lánky je zde i samotná podsekce nazvaná ƒlánky. Dále v této sekci je správa typ komunikace nebo druh reklamní kampan, coº je n co jako "kde se o nás zákazník dozv d l". Dal²í podsekce shromaº uje ve²keré y zákazník sesbírané ze v²ech formulá, kde se zákazníka vkládá. Dal²í podsekce pak na tuto navazuje a vytvá í se tam mail pro hromadnou rozesílku. Zákazník v²ak toto sám nevyuºívá, ale rozeslání mailu vºdy zadá rm DIS Media s.r.o., která mail sestaví, provede testování a pak mail roze²le. Poslední podsekcí je sekce Alarmy, kde jsou poznámky, které si vytvá ejí v t²inou sami prodejci p es Account, aby nap. kontaktovali n jakého zákazníka kv li n jakému vozu, který poptával, nebo aby nezapomn li p ipravit v z p ed domluvenou zku²ební jízdou. Ve zvolený as pak systém pomocí webcronu po²le prodejci mail. Takovou upomínku m ºe prodejci zadat i administrátor v této podsekci Alarmy p es redak ní systém. P ehledy související s vozy, jejich prodejem a se zákazníky jsou v p edposlední sekci P ehledy. Konkrétn jsou zde p ehledy nakoupených, neprodaných a prodaných voz. Podsekce Prodané vozy navíc obsahuje hned n kolik p ehled podle r zných souvislostí, nap. prodané vozy v daném období nebo na dané prodejn. Také je zde v podstat duplicitní p ehled rezervací. Tém totoºný p ehled je v sekci Objednávky a prodeje. V této sekci jsou p ehledy komunikace zvlá². Kaºdý formulá, kterým m ºe zákazník kontaktovat autobazar, má svou stránku s p ehledem a nechybí ani p ehled sdruºující v²echny tyto poptávky a dotazy. Ke kaºdé komunikaci se zákazníkem lze p es redak ní systém i p es Account dopl ovat poznámky v etn soubor. Vedle komunikace se zákazníky je zde i správa zákazník, kde je moºné je editovat, mazat a prohlíºet jejich historii, ímº se p edev²ím myslí objednávky, poptávky apod. K dispozici je také p ehled upomínek prodejc m, které se automaticky zasílají, kdyº prodejce del²í dobu nereaguje na poptávku od zákazníka. Posledním p ehledem jsou nabídky zadané p es formulá na webu na stránce Franchizing. V²echny zmín né p ehledy, p edev²ím pak ty s komunikací a vozy, mají nespo et r zných ltr. Poslední sekcí jsou Obrázky. Zde jsou jen dv podsekce - Obrázky pro web a Obrázky press. Do obrázk pro web jsou nahrávány obrázky, které se pak p idávají ke lánk, p i azují k prodejc m nebo prodejnám. Obrázky k voz m jsou, jak jiº bylo zmín no, e²eny samostatn. Obrázky pro web jsou t íd ny do sloºek. Jsou zde ale jen jednoduché operace p idání, editace a mazání sloºky. To samé je u obrázk jen s tím rozdílem, ºe lze nahrát více obrázku najednou, je to ale stejn ne²ikovn jako u voz. Podsekce Obrázky press je totoºné struktury jako Obrázky pro web, akorát tyto obrázky se pouºívají pro stránku Napsali o nás.

23 3.2. REDAKƒNÍ SYSTÉM 9 Poslední v c, kterou je z uºivatelského hlediska pot eba zmínit, je p ihla²ování uºivatele a jeho údaje. P i p ihlá²ení do systému uºivatel zadává uºivatelské jméno a heslo. Pro p ihlá²ení má z bezpe nostních d vod t i pokusy, pokud se ani napot etí nep ihlásí, p ihla²ování se zablokuje a uºivatel musí kontaktovat správce systému. P ihla²ování má jeden hlavní nedostatek, ºe si nepamatuje poslední zadané uºivatelské jméno a administrátor ho tedy p i kaºdém p ihlá²ení musí zadat znovu. Po p ihlá²ení si uºivatel m ºe heslo do systému zm nit, editace jiných údaj není k dispozici Z pohledu programátora Redak ní systém bereme jako samostatný systém, ale mnoho ástí má spole ných s frontendem. Nap. inicializa ní soubor, soubor s funkcemi nebo r zné moduly. Jde ale jen o ásti, které by nebyl problém ud lat pro oba systém zvlá². Není to ale nutné, není to zdroj ºádných problém. První místo v této podkapitole mají op t katalogy voz. Ale vzhledem k tomu, ºe je na n nahlíºeno o ima programátora, jde o jeden katalog, protoºe v²echny katalogy zpracovává jeden skript. A to zcela doslova, protoºe celý katalog je e²en jediným souborem, ve kterém se míchají SQL dotazy na databázi, zpracování dat a výpis HTML kódu. Tento soubor má p ibliºn 4500 ádk kódu. Rozd lení jednotlivých ástí kódu je velmi chabé, slab okomentované a bez jakékoliv ádu. V kombinaci s pom rn ²patn psaným kódem je pro programátora celý skript velmi nep ehledný. Nijak zabaleno do funkce i t ídy není ani hromadné nahrání soubor nebo obrázk. V tomto souboru není vid t ºádné pouºití objekt nebo znovupouºití kódu, kdyº se nepo ítá includování souboru hlavi ky a pati ky, které se provádí v kaºdé ásti, která vypisuje n jaký HTML kódu. Tento jednovrstvý p ístup není v redak ním systému nijak ojedin lý. Katalog je ale jediný, který je jednovrstvé architektury a ve kterém se stále pravideln n co upravuje. Podle slov programátora z rmy DIS Media s.r.o. nebyly zatím prost edky, ani as a ani odvaha ve stávajícím systému ten skript p ed lat. Ostatní skripty nap. pro p ehledy komunikace nebo objednávky a prodeje byly p ed lány na dvouvrstvou nebo nov ji t ívrstvou architekturu, kdy se vyuºívá t íd denovaných v systému pro prodejce. Dvou i t ívrstvé e²ení mají spole né to, ºe jeden soubor e²í aplika ní logiku stránky a ten druhý prezenta ní. U dvouvrstvé architektury se pro získávání dat z DB nevyuºívá t íd, ale dotazuje se p ímo v aplika ní logice. Soubory s dvouvrstvou architekturou vznikaly t sn p edtím, neº vznikla druhá verze Accounta, která uº je celá e²ena t ívrstv a SQL dotazy se nevyskytují jinde neº ve t ídách. U v t²iny výpis poloºek v systému je n jaký ltr. Formulá e t chto ltr jsou odesílány metodou POST a jejich stavy se ukládají do session. Toto e²ení je sice elegantní, ale neudrºuje stav ltru p i p eposílání adres. P i programátorských pracích na redak ním systému se samoz ejm hodn pracuje i s databází. Jak jiº bylo zmín no, databáze je pro v²echny systémy autobazaru jen jedna, protoºe se ve v²ech systémech pracuje v t²inou se stejnými data. V databázi je nyní 98 tabulek, které dohromady obsahují p ibliºn 15 MB dat. N kolik tabulek je nepouºívaných, eventueln pouze tak, ºe udrºují n jaká historická data. Nap. sou asné objednávky jsou v tabulce objednavky_2. V tabulce objednavky jsou objednávky první verze systému pro prodejce. U nov tvo ených nebo upravených tabulek se ºádné poloºky nemaºou, ale pouze ozna ují jako smazané, aby se data dala p ípadn obnovit. Toto je velice uºite né u tabulky katalog,

24 10 KAPITOLA 3. STÁVAJÍCÍ SYSTÉM A JEHO HISTORIE které obsahuje vozy. Pro zajímavost - tato tabulka má 111 sloupe k a 8 dal²ích tabulek s p idruºenými daty. V tabulce jsou totiº sloupe ky pro zadávání údaj o servise, nancích a jiných v cech, které by si zaslouºily samostatnou tabulku. 3.3 Account - systém pro prodejce Systém pro prodejce Account e²í v²echny pot eby prodejen a potaºmo jejich prodejc pro prodej voz a komunikaci se zákazníky. Toto jsou dv hlavní v ci, které prodejci pro svou práci pot ebují. V systému je také správa a p ehled p esun voz, p ehled upomínek ke komunikaci se zákazníky a moºnost si vytvá et p ipomínky, které se zasílají mailem. Tento systém je pro uºivatele daleko p ív tiv j²í neº webové stránky a redak ní systém. A z hlediska programátora je rozdíl systém je²t výrazn j²í. Kdyby p edchozí dva systémy byly e²ené stejn jako Account, tedy ºe jejich architektura by byla t ívrstvá a pouºívaly se t ídy a objekty, pak by bylo moºné vývoj a nasazení nového systému je²t o pár let odloºit Z pohledu uºivatele Jelikoº redak ní systém a Account jsou dva odd lené systém, je i p ihla²ování e²eno zvlá² a p ihla²ovací údaje jsou pro jednoho zam stnance jiné, i kdyº má p ístup do obou systém. Tyto údaje jsou mezi sebou propojeny, a pokud se administrátor z redak ního systému snaºí dostat do Accounta, ale není do n j p ihlá²en, systém ho automaticky p ihlásí. Samotné p ihla²ování do systému pro prodejce je jiº o t ídu vý²e. Pokud se uºivateli poda í systém zablokovat n kolika nesprávnými pokusy o p ihlá²ení, ale zadal alespo správné uºivatelské jméno a má vypln ny , je mu na n j poslán odkaz pro odblokování. P i p ihla²ování si prodejce také m ºe vybrat prodejnu, pod kterou se chce p ihlásit, pokud je samoz ejm p i azen k více prodejnám. Výb r prodejen se okamºit upravuje podle zadaného uºivatelské jména. Po p ihlá²ení je moºné prodejnu zm nit v hlavi ce systému. Oproti redak nímu systému má prodejce v Accountu moºnost zm ny více osobních údaj. Mezi jinými i uºivatelské jméno nebo , na který se mu p ípadn posílá odkaz pro odblokování p ihla²ování. V menu jsou ty i poloºky - Vozy, Zákazníci, Komunikace se zákazníky a Alarmy. Sekce Vozy a Komunikace se zákazníky mají n kolik podsekcí. Sekce Zákazníci a Alarmy odkazují rovnou na správu a p ehled daných poloºek. V sekci Vozy jsou do samotných podsekcí odd leny rezervace, objednávky a prodeje i kdyº jde v podstat o jednu entitu akorát v r zném stavu. Ve v²ech t ech podsekcích je na první stránce seznam poloºek se základními informacemi, nejd leºit j²í jsou ty o vozu a zákazníkovi. Dále je u kaºdé poloºky odkaz na vypln ní údaj k objednávce, které zahrnují p edm t prodeje (v z, p íslu²enství, prodlouºena záruka apod.), smluvní strany a nancování. Pokud jde o objednávku (potvrzenou rezervaci) nebo prodej, je zárove umoºn n p ístup do manaºeru dokument, kde se spravují faktury, smlouvy a protokoly. Ve t chto dokumentech se pak pracuje s údaji, které byly vypln ny u objednávky. Nap. u faktury se automaticky p edvyplní údaje o dodavateli a odb rateli a poloºky faktury se vybírají z poloºek objednávky, které byly zvoleny v p edm tu prodeje. Dal²í podsekce je v nována dlouhodobým pronájm m, coº je opravdu kapitola sama pro sebe. Na moºnosti vy izovat dlouhodobé pronájmy p es Accounta se pracovalo asi dva

25 3.3. ACCOUNT - SYSTÉM PRO PRODEJCE 11 roky. Toto roz²í ení sice m lo velkou prioritu, ale vºdy se objevilo n co, co m lo vy²²í. Po dvou letech, kdy se tento úkol dokon il za ala spole nost od dlouhodobých pronájm upou²t t. Co se týká této funkcionality, tak je velice podobná objednávkám. Nejv t²í rozdíly jsou, ºe se navíc e²í ukon ování pronájm, p ejímací protokoly nebo splátkový kalendá. Poslední podsekcí jsou P esuny vozu, kde je pouze p ehled p esun vázaných na prodejnu, kterou má prodejce zrovna zvolenou, a moºnost editovat a prohlíºet protokoly. Editovat m ºe jen p edávací nebo p ejímací podle toho, jestli v z p edává nebo p ejímá. Na tomto míst nelze o p esun ºádat, to je pot eba ud lat v detailu vozu na webu. Sekci Zákazníci není t eba popisovat, protoºe je úpln stejná jako ta, co je v redak ním systému. Jde o jedu z n kolika v cí, která je kv li nesjednocení Accounta a redak ního systému e²ena duplicitn. Problém duplicit je i u v²ech podsekcí sekce Komunikace se zákazníky krom jedné a tou jsou upomínky, které prodejci nebo prodejn chodí automatiky, pokud na komunikaci dlouho nereagují. P vodní vize vedení Autobazaru AB byla ta, ºe pokud bude odeslána t etí upomínka, budou z toho vyvozovány n jaké d sledky. V praxi to ale zatím moc nefunguje. Tato funkcionalita tedy spí² jen zaji² uje, aby se prodejce nezapomn l n jakému zákazníkovi ozvat, pokud si sám nevytvo il p ipomínku v sekci Alarmy. Jen ve zkratce k ostatním podsekcím Komunikace se zákazníky. K dispozici jsou tedy jednotlivé p ehledy v²ech typ komunikací se zákazníky a zárove p ehled, kde jsou v²echny typy na jednom míst. P ehledy jednotlivých typ tedy nemají moc smysl, ale celkový p ehled se d lal relativn nedávno a ty ostatní se nechaly být. Stejn jako v redak ním systému lze i v Accountu ke kaºdému vláknu komunikace p idávat poznámky i se soubory. Jediný rozdíl oproti redak nímu systému je, ºe prodejce vidí pouze komunikace, které spadají pod prodejnou, pod kterou je zrovna p ihlá²en. Poslední sekcí jsou Alarmy, které uº také byly zmín ny u redak ního systému a v podstat jsou také duplicitní. Rozdíl je podobn jako u komunikace, ºe prodejce vidí jen alarmy, které se týkají jeho (sám si je vytvo il nebo mu je vytvo il administrátor) nebo celé prodejny, kterou má práv zvolenou. Alarmy mohou být samostatn nebo mohou být p i azeny k ur ité komunikaci Z pohledu programátora Jak jiº bylo zmín no, sou asné verze systému pro prodejce je jiº druhá v po adí. První verze by se dala nazvat samostatným systém jen st ºí. Byla to spí²e sou ást front-endu jako jeho neve ejná ást. Ze za átku Account slouºil jen pro jednoduchou správu objednávek. ƒasem ale p ibylo vystavování faktur a smluv a za aly p ibývat problémy, které se staly sou ástí kaºdého dne a neda ilo se je rozumn e²it, protoºe systém byl od za átku ²patn navrºen. Za al se tedy p ipravovat nový systém. V po áte ním návrhu druhé verze se jen po ítalo s dvouvrstvou architekturou. Pak se ale ve rm DIS Media p e²lo na OOP. Na²t stí to bylo v po átku vývoje systému, takºe se jen upravily návrhy a systém se za al vyvíjet uº jako t ívrstvý. Byly nadenovány t ídy pro kaºdou entitu, se kterou se po ítalo v systému pro prodejce. Mezi t mito entitami byla samoz ejm i entita V z, která je st ºejní i pro ostatní dva systémy. Obecn vytvo ení t íd neusnadnilo práci jen s Accountem, ale i s webem a redak ním systémem, protoºe se t ídy naincludovaly i tam. Postupn se dodenovávaly dal²í t ídy, se

26 12 KAPITOLA 3. STÁVAJÍCÍ SYSTÉM A JEHO HISTORIE kterými se sice v Accountu nepracuje, ale ze systémového hlediska bylo lep²í je vytvá et v rámci jednoho systému a v ostatních systémech si je pouze "p j ovat". V sou asné dob existují t ídy tém pro v²echny entity vyskytující se nap í v²emi systémy Autobazaru AB. Výjimkou jsou r zné typy lánk, kterým se od jejich vzniku nikdo moc nev noval, takºe zatím ani nebyla pot eba je p ed lávat tak, jako tomu bylo nap. u Hlídacího psa nebo p edtím výkupu voz. "P edtím"proto, ºe p ed n jakou dobou výkupy p estaly být st edem zájmu spole nosti, o emº uº bylo psáno v Úvodu.

27 Kapitola 4 Popis problému V této kapitole je popsáno, pro se vlastn vyvíjí nový systém, co je d vodem a co vedlo Autobazar k této investici. Dále jsou v této kapitole uvedeny poºadavky zadavatele a Autobazaru AB na systém, které zjednodu²en popisují jeho základní funkce. 4.1 Pro nový systém? Po p e tení p edchozí kapitoly je d vod asi z ejmý. B hem t ch deseti let, co sou asný systém funguje, se z n j stala zm nejednotných skript, tabulek v databázi, sloºek a soubor. Pokra ovat dál s tímto systémem je jen cesta k n jakému problému, a kdyº ne to, tak minimáln k vysokým náklad m na údrºbu. Jakákoliv úprava je totiº uº te dosti nákladná a uº proto, ºe se d lá ve starém jednovrstvém kódu, nebo proto, ºe se d lá nadvakrát pro redak ní systém a pro Accounta. Náklady na po ízení nového systému jsou sice pom rn vysoké, ale kaºdý m síc autobazar u²et í za výdaje na údrºbu. Dal²í d vod je, ºe UI systému není tak p átelské, jak by mohlo s pouºitím dne²ních technologií být. To zpomaluje práci jak vedení, kdyº pracuje s redak ním systémem, tak ale p edev²ím prodejc m p i jejich kaºdodenní práci s Accountem. Sníºená efektivita práce s sebou také samoz ejm nese ur ité náklady. Nepo ádek v databázi a celkové pro i²t ní systému od funkcionalit, které se jiº dávno nevyuºívají, je také jedním z d vod, pro se autobazar rozhodl od stávájícího systému upustit. V jedné v t shrnuto - Autobazar si od nového systému slibuje sníºení náklad, zvý²ení efektivity práce se systémem a zavedení po ádku v datech. 4.2 Funk ní poºadavky Funk ní poºadavky popisují operace, které m ºe uºivatel v systému provád t. Funkce, které m ºe vyuºívat, a vlastnosti systému, které uºivatel p i práci s ním p ímo poci uje. 13

28 14 KAPITOLA 4. POPIS PROBLÉMU Jednotný systém pro administrátory i prodejce Uº nebudou ºádné dva back-end systémy pro prodejce a administrátory webu ani neve ejná ást front-endu, které asto duplikovala to, co bylo dostupné v back-endu. Bude pouze jeden systém, který bude umoº ovat spravovat uºivatele a jejich práva pro vstup do ur itých sekcí a moºnosti provád ní operací s daty a poloºkami v systému. Informace a dokumenty k voz m, které byly dostupné v neve ejné sekci front-endu, budou v novém IS dostupné ve správ voz Uºivatelské a jejich role Náv²t vník webu má moºnost pouze prohlíºet katalog voz, jejich detaily, lánky a odesílat formulá e pro n j ur ené. Moºnost registrace a p ihla²ování náv²t vník se prozatím v novém systému d lat nebude. Dal²ím uºivatelem systému je prodejce, který se m ºe p ihla²ovat informa ního systému, a tam spravovat ve²keré poloºky ur ené jemu, prodejn, pod kterou je p ihlá²en, nebo prohlíºet poloºky pot ebné k prodeji, jako jsou t eba vozy. V ºádném p ípad je ale nesmí editovat. Stejn tak nesmí prodejce spravovat obsah front-endu, ani jakékoliv jiné údaje o spole nosti, nebo vid t nan ní detaily voz nebo prodej. Finan ními detaily se myslí p edev²ím nákupní ceny, výdaje a zisky. Prodejce také nesmí spravovat ºádné dal²í uºivatele systému. Dal²ími uºivateli budou administráto i pro r zné sekce. Jedním bude administrátor voz, který se bude starat od p idávání a editaci voz a o údaje a data k nim p i azená. Dal²í administrátor se bude starat o obsah webu nepo ítaje katalog voz. M l by mít tedy moºnost spravovat jednotlivé kapitoly, texty a obrázky na webu. Posledním administrátorem s omezenými právy bude správce komunikace se zákazníky. Na rozdíl od prodejce ale uvidí komunikace v²ech prodejen najednou (samoz ejm s moºností ltrování). Posledním b ºným uºivatelem systému bude hlavní administrátor, který bude mít p ístup v²ude a bez omezení pro prodejny nebo prodejce. Také bude mít moºnost spravovat v²echny administrátory a prodejce. Pochopiteln od zadavatele, tedy od rmy DIS Media, je poºadavek je²t na jednu roli, a tou je Superadmin, který bude stát je²t nad hlavním administrátorem. U kaºdého uºivatele musí mít nad ízený administrátor moºnost denovat jeho práva v systému podle individuálních pot eb. Uºivatelské role tedy nejsou pevn dané P ihla²ování do IS P ihla²ování do systému jiº nebude moºné z webových stránek. Systém (a tím pádem i jeho p ihla²ování by) m l být umíst n na neobvyklé adrese, nic jako /admin, /account, /cms nebo n co podobného. Adresa na systém by ani nem la být nikde uvád na, m li by ji znát jen zam stnanci spole nosti. P ihla²ování musí být dostate n zabezpe eno proti napadení hackery. P ihla²ování si musí pamatovat uºivatelské jméno a prodejnu z posledního p ihlá²ení. P i automatickém odhlá²ení, kdy vypr²ela session, si systém musí pamatovat adresu, ze které uºivatele odhlásil, a po p ihlá²ení ho na ní vrátit.

29 4.2. FUNKƒNÍ POšADAVKY 15 Neexistuje nic jako trvalé p ihlá²ení nebo moºnost neodhla²ovat a ani moºnosti zaslání nového hesla v p ípad jeho zapomenutí. V takovém p ípad musí uºivatel kontaktovat správce systému Vyhledávání v IS Moºnost vyhledávání nejd leºit j²ích poloºek v systému, to jsou - vozy, lánky, objednávky, komunikace a multimédia Volba prodejny prodejce Pokud je uºivatel prodejce a je p i azen k více prodejnám, musí mít jiº p i p ihla²ování moºnost si vybrat, pod kterou prodejnou se chce p ihlásit. Po p ihlá²ení musí mít moºnost toto snadno zm nit Editace hlavi ky a pati ky webu Administrátor musí mít moºnost editovat údaje v hlavi ce webu a tím se myslí jak údaje, které budou zobrazované náv²t vník, tak ty, které budou v hlavi ce HTML kódu, p edev²ím tag title a metatag description. Do hlavi ky webu se po ítá i hlavní menu, jehoº editace musí být administrátorovi také umoºn na. Poloºky menu mohou mít jednu úrove podpoloºek. Po adí v²ech poloºek musí jít libovoln ur ovat a musí být moºné poloºky v menu p e azovat pod jiné poloºky nebo do první úrovn. Stejnou moºnost editovat údaje musí mít administrátor i pro pati ku webu, kde budou základní údaje spole nosti a copyright ve tvaru rok_od - rok_do. Editovat by se m l jen po áte ní rok_od, rok_do by se m l na ítat automaticky podle aktuálního roku Správa multimédií Informa ní systém musí administrátor m umoº ovat práci s obrázky a soubory. Ty pak musí jít p i azovat k poloºkám r zného typu ( lánek, v z atd.). Obrázk a soubor se p edpokládá velké mnoºství, takºe musí být moºné vytvá et nekone nou stromovou strukturu sloºek, do kterých se budou dát poloºky adit. S azením do sloºek ale musí být moºnost hromadných operací jako je p idávání, mazání, kopírování a p esouvání poloºek i celých sloºek Mapy U lánk by m la být moºnost vloºit mapu. Vedle Kontakt, kde by mohla být mapa napevno, m ºe být vytvo en lánek nap. o výstav, které se Autobazar AB ú astní a chce vloºit mapu s lokací výstavy. U map by m la být moºnost do nich vkládat neomezený po et míst, ke kterým by se m ly dát p idat obrázky, popisky a odkazy.

30 16 KAPITOLA 4. POPIS PROBLÉMU Bannery Na webu spole nosti se p ipravuje umis ování banner a to nejen r zných partner, ale p edev²ím upoutávek na sluºby, produkty a vozy autobazaru. Správa t chto banner by také m la být sou ástí IS Správa voz K vozu se v základu vedou údaje jako zna ka, model, VIN, cena a mnoho dal²ích údaj popisujících v z a jeho stav a vybavenost. N které poloºky, které jsou napevno dané jako zna ky nebo paliva nebo poloºky, se kterými se pracuje i jinde neº u vozu (jako jsou t eba banky), by m lo být moºné p ípadn p idávat, editovat nebo mazat. Dále musí být u vozu moºnost dopl ovat jeho historii, zm ny cen nebo opravy a to v etn moºnosti dopln ní nan ních údaj. Vozy se adí do skupin a to tak, ºe jeden v z m ºe být i v n kolika skupinách najednou. K voz m ºe být také n jaké p íslu²enství jako zahrádka nebo zimní pneumatiky, které se musí dát do systému zadat. D leºitou sou ástí vozu jsou jeho fotograe, které musí být moºné pohodln p idávat, protoºe jich je kolikrát n kolik desítek. Soubor je u voz mén, ale musí se dát rozli²ovat na ve ejné a neve ejné, kdy neve ejné soubory mohou vid t pouze prodejci. V²echny vozy by m ly být pohromad v jednom p ehledu, ale samoz ejm s moºností ltrování. Nejd leºit j²í je ltrování podle zna ky a modelu, podle VINu a podle skupiny Správa objednávek Objednávky musí být rozd lené podle stavu, které jsou t i. První je rezervace, coº je vlastn nepotvrzená objednávka, kdy je prodej vozu teprve ve fázi jednání. Rezervaci m ºe provád t i zákazník p es formulá na webu. Rezervací na jeden v z m ºe být i více. Dal²í fáze objednávky je, kdyº je potvrzena n jakým prodejce, coº znamená, ºe prodej vozu uº se uskute uje. Objednávce v takovém stavu se íká práv objednávka. Objednávka v tomto stavu uº m ºe být pouze jedna. Nicmén rezervace je dále moºné vytvá et pro p ípad, ºe by i tak z obchodu se²lo. V této fázi se uº vystavují v²echny dokumenty pot ebné k prodeji. A posledním stavem je prodej, kdy se po p edání vozu p esune objednávka mezi vy ízené, tedy prodané. I v této fázi musí jít ale editovat v²echny údaje a dokumenty pro p ípadné opravy nebo dodate né zm ny. Údaje, které se u rezervací a objednávek vypl ují, musí z stat stejné jako ve stávajícím systému. V první ad o p edm t prodeje, kde jsou ve²keré poloºky, které jsou p edm tem obchodu - v z, prodlouºená záruka, úpravy vozu, p íslu²enství a dal²í. Dal²í skupinou údaj jsou smluvní strany, kde se dopl ují údaje o odb rateli, tedy zákazníkovi, a dodavateli, kterým je prodejna a konkrétní prodejce. Poslední jsou údaje o nancování koup vozu. U platby hotovostí nebo p evodem se ºádné údaje nedopl ují. Jinak je tomu ale u úv ru a leasingu. U rezervací se editují pouze údaje smluvních stran a pár údaj k samotné rezervaci.

31 4.2. FUNKƒNÍ POšADAVKY Správa dokument objednávek U potvrzený objednávek a prodej se spravují dokumenty pot ebné k prodeji vozu. T mi jsou faktury, smlouvy a protokoly. Texty a forma t chto dokument musí z stat zachovány, tím pádem musí z stat stejné i ve²keré údaje, které se u dokument vypl ují. Dokumenty jsou na výstupu tak, jak mají být. Zachovány musejí z stat také v²echny typy dokument. Faktura m ºe být typu zálohové, prodejní nebo dobropisu. Smlouvy mohou být rezerva ní nebo kupní a ob jsou závislé na faktu e. Rezerva ní smlouva je závislá na zálohové faktu e a kupní smlouva na prodejní faktu e. Bez ur ení, ke které faktu e smlouva pat í, nesmí být smlouva vystavena. Posledním dokumentem je protokol a ten je pouze jednoho typu a to prodejního. Tento dokument má výjimku v tom, ºe se mohou zm nit vypl ovaná data a forma dokumentu. Nicmén musí n jakým zp sobem z stat moºnost ve²keré pot ebné údaje do protokolu zadat Dlouhodobé pronájmy S dlouhodobými pronájmy se zatím v novém systému nepo ítá, protoºe by se nevyuºily. Systém by m l být ale navrºen s ohledem na to, ºe v budoucnu je bude pot eba dod lat Správa prodejen a prodejc U prodejny se musí pro pot eby webu zadávat údaje jako adresa, otevírací doba a p i azovat prodejci. Také se na webu musí prodejna zobrazovat na map a musí u ní být fotky. Pro interní pot eby je d leºitý kód prodejny, podle kterého se generují ísla faktur, a typ, který se zatím bude vyuºívat je pro rozli²ení, jestli jde prodejnu, sklad nebo servis. V budoucnu se budou pro r zné typy ur ovat r zná práva a operace, které mohou v systému provád t. Prodejci nesou pouze jméno, kontaktní údaje, funkci a obrázek. Ur ování vztahu mezi prodejci a prodejnami musí být moºné v obou sm rech. Jak u prodejen musí jít p i adit prodejci, tak u prodejc prodejny. A to p edev²ím proto, ºe kdyº p ibude nová prodejna nebo nový prodejce, tak aby bylo moºné najednou ur it vztahy a nemuselo se nap. u kaºdé prodejny zvlá² p i azovat nového prodejce Zákazníci Údaje o zákaznících se sbírají ze v²ech formulá, které mohou uºivatelé na webu odesílat. Systém musí být schopný stejné zákazníky, kte í autobazar kontaktují vícekrát, sdruºovat. Moºnost registrace zákazníka a jeho p ihla²ování se na stránkách, kde pak m l uºivatelskou sekci se svou historií a kontaktní formulá e se mu p edvypl ovaly, se zru²í. Jak jiº bylo zmín no, v databázi je nyní 3000 zákazník, ale jen 15 registrovaných a pravd podobn jen málo z nich p ihla²ování v bec vyuºívá. Zachovávat tuto funkcionalitu tedy nemá smysl. V informa ním systému musí být kompletní p ehled v²ech zákazník, kde bude také moºnost editovat jejich údaje a prohlíºet jejich historii - poptávky, hlídací psi nebo objednávky.

32 18 KAPITOLA 4. POPIS PROBLÉMU Komunikace se zákazníky Komunikace zpravidla vzniká odesláním n jakého formulá e na webu zákazníkem. Komunikaci m ºe ale také zaloºit prodejce, kdyº zákazník nap. p ijde na prodejnu a poptává v z. Prodejce tedy musí mít moºnost takovéto dotazy sám zadat do systému. Komunikací je tedy n kolik typ : dotazy na v z do zákazníka, dotazy na v z zadané prodejcem, rezervace vozu zákazníkem, rezervace nebo objednávka vozu vytvo ená prodejcem, poptávka na nancování vozu, hlídací pes (poptávka vozu ur itých parametr ). V novém systému by oproti stávajícímu uº nem ly být p ehledy jednotlivých typ, ale celkový p ehled v²ech komunikací. Ke kaºdé komunikaci musí být moºné psát libovolný po et poznámek a p idávat k nim soubory. Po ukon ení komunikace by m l systém umoº ovat komunikaci uzav ít, aby bylo jasné, ºe byla vy ízena. U komunikací zadávaných prodejci a stejn tak u poznámek je pot eba ur ovat typ komunikace se zákazníkem (mailem, osobn, telefonicky apod.). Samoz ejm v p ehledu komunikací musí být moºnost ltrování a to p edev²ím podle vozu, zákazníka a prodejny. Ve stávajícím systému se také e²í upomínání prodejc, pokud dlouho nereagují na n jakou komunikaci tedy, ºe dlouho nedoplnili ºádnou poznámku nebo komunikaci neuzav eli. Tato funkcionalita zatím v novém systému e²ena nebude, protoºe se v praxi neosv d ila. Do budoucna by m la fungovat pouze na bázi p ipomínání. O tom více v dal²í podkapitole Alarmy Alarmy Alarmy, jak se nazývají p ipomínky ve stávajícím systému, se v novém zatím d lat nebudou. Kaºdý zam stnance Autobazaru AB je nyní vybaven by i jednoduchým telefonem se systémem Android, aby mohl vyuºívat sluºeb Google odkudkoliv. P ipomínky se nyní e²í p es Google Kalendá a alarmy ve stávájícím systému se nevyuºívají ƒlánky Jednoduché stránky webu by m ly být jednotné a snadno editovatelné. M ly by do nich jít jednodu²e p idávat obrázky, ale i soubory nebo mapu. Formátování textu by m lo být zaji²t no n jakým textovým editorem, který bude um t pracovat i s obrázky, odkazy a tabulkami.

33 4.3. NEFUNKƒNÍ POšADAVKY Skrývání poloºek Tém ve²keré poloºky by m lo být moºné skrývat p ed uºivateli, kterým se vypisují. V p ípad lánk nebo voz to jsou náv²t vníci webových stránek. V p ípad systémových poloºek jsou tito uºivatelé sami prodejci nebo administráto i. To proto, aby je poloºky, které nejsou nap. aktuální, nemátly p i n jakém zadávání údaj Propojení stránek s Facebookem spole nosti Nov zaloºené Facebook stránky Autobazaru AB by se m ly propojit s webem spole nosti. Hlavním propojením by m l být velký box, kde bude jak tla ítko "Líbí se mi", tak p ísp vky p idané na FB stránky a obli eje lidí, kterým se stránka líbí. Stránky by s FB m ly být propojené i pomocí odkaz pro sdílení na kaºdé stránce. 4.3 Nefunk ní poºadavky Nefunk ní poºadavky popisují dal²í vlastnosti systému a poºadavky na n j, které uºivatel nemusí p ímo poci ovat nebo si je uv domovat UI systému Uºivatelské rozhraní systému by m lo být jednotné a intuitivní. Ovládací prvky by m ly být dob e a jasn popsané, aby bylo jasné, co se stane p i jejich pouºití. Systém by m l být dob e provázán, aby se snad dostávalo do jiných ástí systému, kterou jsou na dané stránce relevantní, a ke v²em akcím, které jsou pro danou poloºku nebo poloºky k dispozici. V systému by se také nem ly objevovat obrovské formulá e nebo "nekone né"seznamy poloºek. Velké stránky by m ly být rozd leny na men²í, ale tak aby mezi sebou byly snadno dostupné. A seznamy poloºek by m ly být p i velkém po tu stránkované. V u seznam poloºek by také m lo být ltrování podle relevantních parametr, kterým je tém vºdy alespo název. Stejn tak by m la být v seznamech moºnost azení, pokud existuje více sloupe ku, podle kterých má azení význam. Práce se systémem by m la být jednoduchá, co nejpohodln j²í, rychlá a efektivní. V IS v pati ce stránky by m la být doba generování stránky na serveru, aby uºivatel v d l, ºe p ípadné dlouhé na ítání je zp sobené spojením se serverem a ne n jaký problémem v systému Zabezpe ení systému a dat Zabezpe ení systému a dat, se kterými se v n m pracuje je velice d leºité a m la by mu být kladena vysoká priorita. Systém by m l být chrán n jak proti útok m z venku (hacke i, roboti, spamy), tak zevnit. Ochranou zevnit se myslí p edev²ím to, aby se minimalizovalo riziko, ºe n jaký uºivatel napáchá v systému nevratné ²kody a uº schváln nebo omylem. Uºivatel by hlavn nem l mít moºnost se jakkoliv dostat tam, kam nemá oprávn ný p ístup.

34 20 KAPITOLA 4. POPIS PROBLÉMU Roz²i itelnost systému Autobazar AB je ºivá spole nost, která p ichází s novými produkty a sluºbami a r zn se m ní. Je tedy pot eba, aby se i s tím p i vývoji systému po ítalo a byl exibilní, aby nebyl problém s p ípadnými roz²í eními i zm nami. Také musí jít znovu pouºívat jiº vytvo ené komponenty systému Optimalizace pro mobilní za ízení Systém musí pracovat a být pouºitelný i na mobilních za ízeních a to p edev²ím na tabletech, protoºe prodejny byly vybaveny tablety, které pouºívají nap. p i obcházení voz se zákazníkem Technologie Systém pob ºí na serveru rmy DIS Media, kde je nainstalován Apache s PHP 5.3 a s databází MySQL 5. Plánuje se ale v blízké dob upgrade na verzi PHP 5.4. P i vývoji a implementaci systému se s tím tedy musí po ítat a v podstat systém vyvíjet pro tuto vy²²í verzi, aby po upgradu systém bez problému fungoval. Systém by m l také vyuºívat, pokud je to moºné, jiº hotových modul, které jsou jiº odzkou²ené a mají dobrou dokumentaci.

35 Kapitola 5 Analýza nového systému V této kapitole je popsána analýza celého systému, která je provedena na základ poºadavk popsaných v p edchozí kapitole a která poslouºí jako podklad pro návrh a implementaci. Metod pro analýzu webových aplikací je sice celá ada, p i analýze informa ního systému Autobazaru AB ale nebylo pln vyuºito ºádné. Nejvíce v²ak bylo vycházeno z metodiky WebML[27]. Ta dnes v podstat jiº neexistuje, protoºe se zm nila na IFML[13], coº je nový standard p ijatý OMG[20] pro modelování UI. První místo v analýze zaujímá popis v²ech entit vyskytujících se v systému, vý et jejich hlavních atribut a popis vztah s jinými entitami. Pro znázorn ní vztah sloºí n kolik diagram. Dal²í podkapitolou analýzy jsou Uºivatelské role, kde jsou popsáni jednotliví uºivatelé systému, jejich hierarchie a práva. Tato podkapitola je dopln na Use-Case diagramy, které zobrazují práva a moºnosti uºivatel v systému. Poté jsou v dal²í ásti rozebrány interní procesy autobazaru dopln né o Activity Diagramy. Ve²keré diagramy, které jsou v této kapitole, byly vytvo eny online nástrojem Gliy 1, který umí vytvá et r zné druhy diagram. Pro pot ebu této kapitoly sta ily diagramy typu UML, BPMN a ERD. 5.1 Entit systému a jejich vztahy V této ásti jsou popsány ve²keré entity, se kterými se v systému pracuje, a jejich v vzájemné vztahy. Jelikoº je entit pom rn dost (cca 50) a n které vztahy jsou relativn komplikované a rozsáhlé, jsou pro lep²í orientaci v t chto vztazích a závislostech p iloºeny Entity Relationship Diagramy. Pro popsání kardinalit v ERD byla pouºita notace Information Engineering[8] V z V z je jedna z nejv t²ích entit v systému. Nejv t²ích my²leno tak, ºe se u ní vede nejvíce dat a má nejvíce vazeb na dal²í entity. Hlavními atributy jsou VIN, cena, DPH, popis a n kolik p íznak nap. jestli je moºný odpo et DPH, instalace LPG nebo si dokoupit prodlouºenou záruku

36 22 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU Entita má také dal²í atributy, které slouºí k propojení s následujícími entitami - Zna ka, Model, Obrázek, Banka a Prodejna. Obrázek u vozu samoz ejm není jeden, ale atribut obrazek_id ur uje hlavní obrázek vozu, který je jednodu²e p ístupný a pouºitelný kdekoliv je t eba. Vazba k entita Banka ur uje, v p ípad ºe v z není nancován vlastními prost edky autobazaru, jaká banka v z nancuje. Prodejna pak dává informaci, jakému prodejnímu místo v z náleºí. Dále má entita V z vazbu na entitu Skupina voz, kdy jeden v z m ºe být ve více skupinách (nap. ojeté vozy a o-road). Dal²í vazba je s entitou Zm na ceny vozu, která hovo í o cenové historii vozu. Vazba s entitou Historie vozu ur uje konkrétní událost spojením Typu historie a dopln ním dal²ích údaj. Podobn fungující a áste n související je i vazba Vozu na P íslu²enství. Vazby s ob ma t mito entitami budou je²t blíºe rozebrány v jejich popisu. Dal²ími vazbami jsou spojení mezi Vozem a Výbavou, Vozem a Obrázky a Vozem a Soubory, kdy v²echny zmín né entity mohou mít libovolné mnoºství spojení s prot j²í entitou. Je pot eba dodat, ºe V z m ºe mít stejné spojení i se entitami Sloºka obrázk a Sloºka soubor, aby nemusely být obrázky a soubory p i azovány jen samostatn, ale i po sloºkách. Tyto dv vazby nejsou v ER Diagramu uvedeny kv li jeho uº tak velkému rozsahu. V z má je²t dal²í vazby s entitami Hodnota parametru vozu, Odeslané vozy hlídacího psa, Komunikace, Objednávka, Faktura, Smlouva a Protokol. Tyto vazby budou ale podrobn popsány dál v této kapitole u p íslu²ných entit. Skupina ZměnaCeny původni cena nová cena vytvořeno Historie datum tachometr cena dph TypHistorie Prodejna Příslušenstvi TypPřislušenství Značka Vůz Výbava Model Hodnota ParametruVozu Parametr Banka financuje Obrázek Soubor Zna ka Obrázek 5.1: Diagram vztah entit (ERD) pro v z Na rozdíl od Vozu je entita Zna ka jedna z t ch nejjednodu²²ích. Obsahuje jediný d leºitý atribut a tím je název. Vazby na dal²í entity má pak jen dv. Jednou je o ekávan vazba na V z a druhou vazba na Modely vozu, kdy jich zna ka m ºe mít libovolné mnoºství.

37 5.1. ENTIT SYSTÉMU A JEJICH VZTAHY Model Entita Model je v podstat stejná jako entita Zna ka, jediný rozdíl je ten, ºe musí mít vazbu na práv jednu Zna ku Skupina voz Skupina voz je entita, která umoº uje ur ovat, jestli v z pat í mezi osobní vozy, jestli je nový, p edvád cí nebo ojetý nebo t eba jestli má náhon 4x4. Toto by samoz ejm ²lo e²it p es n jaké atributy nebo parametry vozu, ale skupiny poskytují v t²í volnost a mají více moºností vyuºití Typ historie Typ historie denuje jednotlivé události v "ºivot "vozu u Autobazaru AB. Takovou událostí m ºe být nákup, p edprodejní servis, nasazení do prodeje nebo prodej vozu. Jedinou vazbou této entity je spojení s entitou Historie vozu, která ur uje konkrétní událost, která nastala Historie vozu Tato entita má vyuºití ve vedení historie vozu, kdy se ur uje o jakou událost (nákup, oprava, prodej) ²lo, kdy to bylo, kolik to stálo a kolik m l v té dob v z najeto. Z t chto informací pak lze sestavovat jak istou historii vozu, tak nan ní p ehledy Zm na ceny vozu K nan ním p ehled, které jsou ale i pro zákazníka slouºí entita Zm na ceny vozu, která pomocí údaj o p vodní a nové cen a datum zm ny zaznamenává cenovou historii vozu Typ p íslu²enství Typ p íslu²enství slouºí k denování p íslu²enství, která mohou k voz m být. T mi mohou být nap. pneumatiky, zahrádka, zimní et zy nebo kobere ky pod nohy. Typ p íslu²enství má samoz ejm název a je²t stojí za zmínku atribut po adí, který ur uje po adí p íslu²enství p i výpise, aby se nap. p ední pneumatiky nevypisovali za zadními. Podobn jako Typ historie i tato entita má pouze jednu vazbu a to s konkrétním P íslu²enstvím vozu P íslu²enství vozu Tato entita jiº pracuje s konkrétním p íslu²enstvím, které pat í k ur itému vozu. Spojuje Typ vozu, V z samotný a dopl uje údaje jako popis, nákupní cena, prodejní cena a DPH. M ºe se tedy p idat k Historii vozu jako k entit, ze které lze získat n jaké informace o nancích.

38 24 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU Výbava vozu Entita Výbava vozu stojí samostatn bez nutnosti ur ování n jakého typu a dopl ování dal²ích údaj jako je tomu u P íslu²enství. Tato entita má pouze jednu vazbu s entitou V z a to tak, ºe V z m ºe mít libovolných po et vazeb s entitou Výbava. Naopak to samoz ejm platí také. Atributy jsou zde akorát dva zásadní a to název a po adí, pomocí n hoº se op t ur uje po adí poloºek na výstupu a tedy jejich priorita a atraktivita u voz Parametr Entita V z v dosavadním systému má 111 atribut, kdy pár desítek t chto atribut by mohlo být ozna eno parametry vozu. Takovými atributy m ºe být stav tachometru, barva, palivo nebo p evodovka. Proto je v novém systému navrºena entita Parametr, která takovéto atributy sdruºuje. Jelikoº ale mezi atributy (nap. tachometr a barva) jsou zásadní rozdíly a to v typu jejich hodnoty a v tom, ºe n které mají jednotku a jiné ne, je entita Parametr a její vazby trochu komplikovan j²í. Parametr má tedy atributy název a popis, který íká konkrétn ji, o em daný parametr je. Dále má atributy typ hodnoty a po adí. Typ hodnoty ur uje, jakého typu je hodnota parametru, jestli jde o íslu, interval, text, výb r n jaké hodnoty, plochu a nebo prostor. Atribut po adí má stejnou funkci jako u entity Výbava vozu. Entita m ºe mít vazbu na entitu Jednotka a ur it tak, ºe nap. u stavu tachometru má být uvedeno, ºe daná hodnota je v kilometrech. Pokud má Parametr typ hodnoty nastavený na výb r, denují se vazby je²t na entitu Hodnota parametru. Hodnota Parametru Jednotka název zkratka Parametr typ hodnoty Hodnota ParametruVozu hodnota nebo ID hodnoty Vůz Jednotka Obrázek 5.2: Diagram vztah entit (ERD) pro parametr vozu Jednotka má pouze atribut název a zkratka. Zkratka je to, co se p idává za hodnotu parametru, nap. u kilometru je to tedy km. Vazba na Parametr je jediná vazba, kterou entita má. Jedna jednotka ale m ºe být p i azena více parametr m, protoºe nap. kilometry mohou být jak u stavu tachometru, tak u záruky omezené kilometry Hodnota parametru Tato entita se pouºívá s entitou Parametr pouze tehdy, kdyº má Parametr atribut typ hodnoty výb r, coº znamená, ºe p i zadávání hodnoty parametru u vozu se hodnota vybírá

39 5.1. ENTIT SYSTÉMU A JEJICH VZTAHY 25 z n jaké nadenované mnoºiny hodnot. Toto lze vyuºít nap. u parametru barva, kde se nadenují hodnoty bílá, erná, modrá atd. U hodnot je moºné ur ovat po adí, aby bylo moºné nejvíce pouºívanou hodnotu dát na za átek výb ru. Hodnota musí být p i azena práv jednomu parametru a m ºe mít vazbu s entitou Hodnota parametru vozu Hodnota parametru vozu Pokud se zvolí n jaká hodnota parametru u n jakého vozu, má jí tato entita na starost. Má n kolik atribut pro hodnoty v²ech typ - íslo, interval (od, do), text, výb r (vazba na entitu Hodnota parametru), plocha (²í ka, vý²ka) a prostor (²í ka, vý²ka, hloubka). Entita má tedy vazbu jak na Parametr, tak na V z a v p ípad typu hodnoty výb r je²t na Hodnotu parametru Prodejna Entita Prodejna nemusí reprezentovat pouze prodejnu, ale i sklad nebo servis autobazaru, to rozli²uje atribut typ. Primárn je ale entita vyuºívána pro prodejny, u kterých se ur uje název a kód pro interní pot eby spole nosti. Kontaktní údaje prodejny jako jsou adresa, telefon nebo jsou e²eny propojením s entitou Kontakt. Podobn je e²en i obrázek prodejny projením s entitou Obrázek. Rozdíl je ale ten, ºe obrázek prodejna mít nemusí, ale kontaktní údaje ano. Prodejna má také vazbu s Prodejcem, kdy Prodejna m ºe mít libovoln prodejc. Dal²í vazby m ºe mít na entity Objednávka a Komunikace a samoz ejm na V z, coº jiº bylo uvedeno. Vůz Prodejna Kontakt Objednávka Prodejce Obrázek Komunikace Administrátor Obrázek 5.3: Diagram vztah entit (ERD) pro prodejnu

40 26 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU Prodejce Prodejce reprezentuje zam stnance autobazaru, který je na n jaké prodejn, kde komunikuje se zákazníky a prodává vozy. Od toho se také odvíjejí jeho vazby na dal²í entity. Jakousi hlavní vazbu má na entitu Prodejna, kdy ale jeden prodejce m ºe být p i azen více prodejnám. Dal²í vazbu má prodejce na komunikace, ale ne p ímo, nýbrº p es entitu Poznámka komunikace. Dal²í vazby má pak na entity týkající se prodeje voz a t mi jsou Objednávka, Faktura, Smlouva a Protokol. Entita má vcelku podobné atributy jako Prodejna, akorát samoz ejm nemá název. Jméno a p íjmení jsou sou ástí entity Kontakt, se kterou je Prodejce propojen. Také nemá ºádný atribut kód, ale navíc má ur ení své funkce ve spole nosti, protoºe podobn jako Prodejna, nemusí ani Prodejce vºdy reprezentovat konkrétn prodejce, ale nap. servisního technika, to je ale zatím spí² pohled do budoucna. V sou asnosti název p esn odpovídá tomu, co v systému reprezentuje. Pozornost si je²t zaslouºí vazba entity na entitu Administrátor. Tato vazba zaji² uje prodejci p ístup do systému. Prodejce má v systému p eddenovaná práva, která je moºné upravovat podle jeho reálných oprávn ní jako zam stnance Administrátor Tato entita reprezentuje uºivatele systému a denuje pro n j údaje pro p ihlá²ení, coº je uºivatelské jméno a heslo, a podobn jako u prodejce kontaktní údaje p es entitu Kontakt. Jak jiº bylo zmín no, tato entita m ºe mít také vazbu na entitu Prodejce. Administrátorovi jsou také denována práva, která mohou být nad ízenými administrátory m n na. To jestli je administrátor vý²e neº jiný ur uje atribut role Právo administrátora Právo administrátora denuje jeho oprávn ní pro p ístup do n jaké sekce systému nebo oprávn ní pro n jakou operaci s poloºkami systému. Nap. lze íci, ºe má administrátor právo pro p ístup pouze do seznamu poloºek a tam je jen mazat, nem ºe je ale uº p idávat nebo editovat. Nebo lze naopak zadat, ºe má p ístup v²ude a právo provád t v²echny operace. Kaºdopádn je ale t eba brát v potaz roli administrátora, která stojí nad právy. Pokud tedy existuje n jaké omezení pro danou roli, nadenováním práv to nelze zm nit Komunikace Komunikace sdruºuje entity Dotaz vozu, Poptávka nancování, Hlídací pes a Objednávka. Tyto entity mají mnoho spole né, coº je p edev²ím to, ºe se jedná o komunikaci se zákazníky a krom Hlídacího psa je do komunikace také zapojen V z a Prodejna. Dal²í dv vazby entity ur ují zákazníka. Jedna je p ímo na entitu Zákazník a druhá na entitu Kontakt. Zákazník a jeho kontaktní údaje se u Komunikace vedou odd len, protoºe vazba s entitou Zákazník ur uje o jakého zákazníka jde a vazba s entitou Kontakt ur uje kontaktní údaje zákazníka pro danou komunikaci.

41 5.1. ENTIT SYSTÉMU A JEJICH VZTAHY 27 U komunikace se také vedou informace o datu vytvo ení, poslední odpov di a datu uzav ení vlákna komunikace. T eba také zmínit, ºe ke komunikaci si prodejci pí²í poznámky o pr b hu jednání se zákazníkem. Toto je blíºe popsáno u entity Poznámka komunikace Dotaz vozu Dotaz vozu je entita p edstavující zákazník v dotaz nebo zájem o v z, který m ºe zadat p ímo on p es formulá na webu nebo ho za n j m ºe zadat prodejce p es IS. Atribut je zde v podstat pouze jeden a tím je text dotazu. Entita má v²echny vazby, které byly popsány u entity Komunikace vý²e. Vztah s Prodejnou je dán tím, kam zákazník p i²el nebo pod kterou dotaz spadl, protoºe na ní je dotazovaný v z. Entita má je²t jedno propojení a to s Typem komunikace, které se vyuºívá, kdyº dotaz za zákazníka zadává prodejce Poptávka nancování Poptávka nancování je oproti Komunikaci roz²í ena o atributy typ nancování (úv r nebo leasing), akontace, doba nancování a poji²t ní (ano/ne). Vůz Odeslané Vozy HlídacíPes DotazVozu Komunikace Soubor Objednávka vytvořeno odpovězeno uzavřeno TypKomunikace Poznámka Komunikace vyřizuje Poptávka Financování Zákazník Prodejna Prodejce Obrázek 5.4: Diagram vztah entit (ERD) pro komunikaci se zákazníky Hlídací pes Hlídací pes je trochu atypickým druhem komunikace, protoºe se p i ní nekomunikuje se zákazníkem o jednom voze. Zákazník zadá kritéria vozu, který poºaduje, a systém mu automaticky posílá nabídky. Voz v jednání tedy m ºe být hned n kolik. Jelikoº nejde jen o jeden

42 28 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU v z, nelze ur it ani prodejnu, pod kterou komunikace spadá, komunikace je tedy p ístupná v²em. Entita má n kolik atribut pro ur ení kritérií poºadovaného vozu - zna ka, model, palivo, rok výroby, p evodovka, cena (od - do), tachometr (od - do) a dále uº jen poznámku, kterou m ºe zákazník zadat. Ur ení zna ky a modelu je napojeno na entity Zna ka a Model. Atributy palivo, rok výroby, p evodovka a tachometr jsou napojeny na entitu Hodnota parametru vozu. A poslední atribut cena se pojí s atributem cena u entity V z Odeslaný v z Tato entita je jakýmsi pojítkem mezi entitou Hlídací pes a V z, která je²t navíc nese informaci o datu a ase, kdy byl v z na základ poºadavk zákazníka systém odeslán. Jeden v z m ºe být odeslán stejnému zákazníkovi i vícekrát a to v p ípad, kdy se zm nila cena vozu nebo zvý²il stav tachometru Kontakt Entita Kontakt jiº byla mnohokrát zmi ována. Je to entita reprezentující kontaktní údaje na n jakou osobu nebo spole nost. Uvád t ve²keré atributy by asi bylo zbyte né a dlouhé, ale jsou jimi jak základní kontaktní údaje jako jméno, adresa, telefon a , tak i nap. íslo ú tu. Entita m ºe mít vazby na entity Stát, Kraj a Okres, význam není t eba vysv tlovat. Kontakt je trochu zvlá²tní entitou v tom, ºe se nikde v systému nepouºívá samostatn, ale vºdy v souvislosti s jinou entitou Zákazník Entita Zákazník je ur ena nejen reálnému zákazníkovi, který provedl u Autobazaru AB n jakou koupi vozu, ale i t eba jen náv²t vníkovi webových stránek, který vyplní a ode²le n jaký formulá. Tím se automaticky dostává do databáze zákazník spole nosti. Jelikoº je povinný, lze sledovat, jestli zákazník kontaktoval autobazar poprvé nebo má jiº n jakou historii. U zákazníka se také sleduje, odkud se o autobazaru dozv d l. Pro tento ú el slouºí entita Zdroj zákazníka. Ve²keré kontaktní údaje zákazníka spadají pod entitu Kontakt, se kterou existuje spojení. Dal²í vazby jsou se v²emi typy komunikace. Jeden typ komunikace ale zatím nebyl popsán a tím je Objednávka. K entit Objednávka se váºí entity Faktura, Smlouva a Protokol, se kterými má zákazník také vazbu. Vazby jsou p ímé a ne p es entitu Objednávka, kv li snaz²í orientaci a p ístupu dat m Poznámka komunikace Poznámka komunikace reprezentuje text o komunikaci se zákazníkem, který prodejce zadává ke vláknu komunikace. Spolu s textem také zadává, jakým zp sobem se zákazníkem komunikoval, ímº vzniká vazba s entitou Typ komunikace. Entita má také vztah k entit Soubor, protoºe k textu musejí jít p ikládat soubory. Kdyº nap. prodejce po²le zákazníkovy jiº konkrétní nabídku nancování v DOC nebo PDF, p iloºí jí k poznámce.

43 5.1. ENTIT SYSTÉMU A JEJICH VZTAHY Typ komunikace Jak jiº bylo nastín no, takto entita íká jakým zp sobem komunikace se zákazníkem probíhala, jestli telefonicky, mailem, osobn nebo jinak. Váºe se pouze na entity Poznámka komunikace a Dotaz vozu Zdroj zákazníka Tato entita jiº také byla zmín na a vyuºívá se u zákazníka, kde ur uje, jakým zp sobem se zákazník o Autobazaru AB dozv d l. Moºnosti mohou být nap. od známého, z billboardu, z rádia atd Objednávka Entita Objednávka reprezentuje jak objednávky, tak rezervace a prodeje, kdy jde pouze o rozdílné stavy téºe v ci. Entita má atributy potvrzeno a prodáno. Nepotvrzená objednávka je rezervace a prodaná objednávka je prodej. Z pohledu komunikace se zákazníky je entita normálním typem komunikace, takºe má i stejné vazby a atributy jako ostatní typy komunikace. Navíc má vazbu na Prodejce, která íká, který prodejce objednávku vy izuje. Dal²ím atributem je typ poji²t ní, které m ºe být povinné, havarijní, obojí nebo ºádné. Pokud n jaké je, vzniká vazba s entitou Poji² ovna, která denuje, p es kterou poji² ovnu je poji²t ní sjednáváno. Podobn je to i s nancováním koup vozu. Pokud je p es úv r nebo leasing, ur uje se Banka. Také se v takovém p ípad vyuºívá atribut íslo úv rové smlouvy a akontace. S p edm tem prodeje souvisí atributy záruka a bonus. Záruka íká, jestli je sjednávána prodlouºená záruka vozu a bonus je ást, kterou dostane autobazar od banky za zprost edkování nancování. Pro rezervaci jsou je²t dva atributy konec rezervace a termín prohlídky. D leºitou vazbou entity je spojení s entitou Poloºka objednávky. Dále pak s entitami dokument Faktura, Smlouva a Protokol.

44 30 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU ÚpravaVozu Příslušenství Položka Objednávky financuje vůz Banka Zakazník pojišťuje vůz Pojišťovna Vůz Objednávka Prodejna Kontakt Prodejce Protokol Faktura Způsob Platby Smlouva Obrázek 5.5: Diagram vztah entit (ERD) pro objednávku vozu Poloºka objednávky Poloºka objednávky reprezentuje p edm t prodeje. P i prodeji vozu je p edm t více a tato entita je sdruºuje. Tím hlavním je samoz ejm V z, ale pat í tam i prodlouºená záruka, poji²t ní, Úprava vozu nebo P íslu²enství. Poloºky jsou poté pouºity p i vytvá ení faktury Úprava vozu Autobazar nabízí dodate né úpravy vozu jako je instalace taºného za ízení nebo xenonových sv tlomet. Atributy této entity jsou název úpravy, referen ní íslo, cena, po izovací cena a DPH. Tyto úpravy v základ stojí samostatn, kdy jsou nabízeny na webu ke kaºdému vozu. Nemá ale smysl nabízet úpravu, kdyº uº v z nap. taºné za ízení má. Entita má tedy vazbu na entitu Výbava, která íká, jaké výbav úprava odpovídá a podle toho se u vozu nabízela nebo ne. Také je moºné díky atributu po adí ur ovat posloupnost výpisu úprav na webu.

45 5.1. ENTIT SYSTÉMU A JEJICH VZTAHY Banka Tato entita reprezentuje bankovní ústav, p es který autobazar nancuje své vozy a nabízí p es n nancování zákazník m. Eviduje se název, p es entitu Kontakt kontaktní údaje a také, jestli banka nabízí nancování úv rem nebo leasing. Vazby této entity jiº byly zmín ny - jsou s entitami V z a Objednávka. V prvním p ípad vazba íká, p es kterou banku nancuje autobazar nákup vozu a v druhém, p es kterou nancuje nákup zákazník Poji² ovna V p ípad, kdy má zákazník zájem rovnou p i koupi vozu sjednat poji²t ní, vybere se i poji² ovna, u které bude poji²t ní sjednáno. Toto popisuje jedinou vazbu Poji² ovny na entitu Objednávka. Atributy jsou podobné jako u Banky, akorát odpadají samoz ejm typy nancování, ale p ibývá atribut sleva, ur ující sníºení ceny poji²t ní pro Autobazar AB Faktura Pro prodej vozu a souvisejících poloºek musí být vystavena faktura se v²emi náleºitostmi danými zákonem. Nejd leºit j²í u faktury jsou tedy samotné poloºky a informace o dodavateli (Autobazar AB) a odb rateli (zákazník). V p ípad leasing je ale odb ratelem banka, která koupi nancuje, a zákazník je uveden jako nájemce. Informace o odb rateli jsou dány entitou Spole nost, informace o zákazníkovi pak vazbou na entitu Kontakt. Ne Zákazník, protoºe faktura ní údaje mohou být úpln jiné neº kontaktní údaje zákazníka. Pokud je odb ratelem banka, ur ují se faktura ní údaje podle Banky, která má vazbu s danou objednávkou. Spojení s Fakturou je tedy nep ímé. Faktura m ºe být n kolika typ - zálohová, prodejní a dobropis. V p ípad prodejní faktury m ºe být spojena jak se zálohovými fakturami, tak dobropisy. Podle t chto spojení a poloºek faktury se ur uje ástka dané faktury, coº je vedle typu dal²í z atribut entity. D leºitým atributem je íslo faktury, které se generuje p i vystavování faktury podle kódu Prodejny, roku vystavení a po adí v ad fakturu pro daný rok. Faktura také m ºe mít interní popis a pro vystavení musí mít uvedená data vystavení, splatnosti a zdanitelného pln ní. K faktu e také m ºe být zadána poznámka a zvoleno, jestli se mají vypisovat informace o voze. Také se u faktury vedou údaje o uhrazení a to o datu a ástce. D leºité je také zmínit, ºe faktura m ºe být stornována, k emuº slouºí atribut stornováno. Vazba s entitou Prodejna jiº byla nastín na, je d leºitá pro ur ení ísla faktury a pro interní evidenci prodej na daných prodejnách. Faktura má také vazbu na Prodejce, který fakturu vystavil Zp sob platby Tato entita reprezentuje zp sob, jakým bude Faktura uhrazena. Moºnosti mohou být hotovostí, p evodem, leasingem nebo úv rem, coº je i jediný atribut entity - název.

46 32 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU Smlouva Entita Smlouva je co do struktury áste n podobná Faktu e. Jsou zde také smluvní strany, akorát u smlouvy není v ºádném p ípad druhou smluvní stranou banka, ale vºdy zákazník. Rozdíl smlouvy je také v tom, ºe je závislá na Faktu e a má stejné íslo jako ona. Smlouva tedy nem ºe být uzav ena bez ur ení, ke které smlouv pat í. ƒíslo smlouvy je ale i p es p ímou vazbu na Fakturu samostatným atributem pro snaz²í p ístup k tomuto d leºitému údaji. Smlouva m ºe být rezerva ní nebo kupní. Rezerva ní smlouva m ºe mít spojení pouze se zálohovou fakturou a kupní pouze s prodejní. Smlouva nemá ºádné poloºky ani ástku, ale eviduje údaje o konci rezervace a termínu prohlídky pro pot eby rezerva ní smlouvy a informace o tom, jestli je k vozu sjednávána prodlouºená záruka pro kupní smlouvu. Stejn jako faktura má i smlouva p ímou vazbu na objednávku, k níº je vystavována Protokol Entita Protokol je rozdílná od Faktury a Smlouvy, protoºe má vyuºití jak u objednávek, tak u p esunu voz. Typy protokol jsou prodejní, p edávací a p ejímací. Prodejní a p edávací mají spole né to, ºe podrobn popisují p edávaný v z a jeho aktuální stav. P ejímací pak uº jen stav p edaného vozu potvrzuje, p íp. uvádí výhrady. V p ípad prodejního protokolu je p edávajícím prodejna, kde se obchod uskute uje, spole n s prodejcem, který prodej vy izuje, a p ejímajícím je zákazník. U p edávacího protokolu je p ejímajícím prodejna, kam se v z p esouvá a prodejce, který v z p ejímá. U p ejímacího protokolu jsou p edávající a p ejímající opa n. Protokol má n kolik atribut pro popis vozu - technický stav, karoserie, interier, pneumatiky, výbava, p íslu²enství, dokumentace, chybí, závady a poznámky. Pro p ejímajícího je pak jen atribut výhrady. Také se vedou informace o datum, ase a míst p edání a stejn tak p ijetí P esun vozu P esun vozu m ºe probíhat jak samostatn, tak v závislosti na objednávce/rezervaci, kdy si zákazník chce v z prohlédnout nebo rovnou koupit a je tedy pot eba ho p esunout na danou prodejnu. Entita má dvojí vazbu na Prodejnu a to, ze které prodejny na jakou se v z p esouvá. Vazba na V z je samoz ejmostí a dále m ºe mít tedy vazbu na Objednávku. Atributy jsou pak doprava (vlastní nebo za ízená autobazarem) a data p edání a p evzetí vozu. Úpln na za átku musí být p esun schválen vedením, k tomu slouºí atributy schváleno a datum schválení. Celý proces p edávání vozu je podrobn popsán v dal²í podkapitole Interní procesy ƒlánek ƒlánek reprezentuje klasickou webovou stránku, která ve v t²in p ípad obsahuje jen text a obrázky. Entita ƒlánek má ale je²t vazby na entity Soubor a Mapu. Na stránce autobazaru tedy mohou být jak obrázky, soubory, tak i mapa ukazující lokalitu, o které stránka

47 5.1. ENTIT SYSTÉMU A JEJICH VZTAHY 33 pojednává. Obrázk a soubor m ºe být libovolné mnoºství a je moºné spojit se lánkem i celé sloºky. ƒlánek má klasicky n jaký název, popis, text. Rozdíl mezi popisem a textem je ten, ºe text se zobrazuje na stránce lánku a popis je na ní jen jako metatag description v HTML kódu. U lánku se také p i azuje náhledový obrázek, který se spolu s název a popisem vyuºívá v seznamu lánk Sloºka lánk ƒlánky lze t ídit do r zných sloºek podle témat. Sloºka ale zárove m ºe být i samostatnou stránkou, která má oproti lánku navíc seznam podstránek ( lánk ). Entita Sloºka lánk má tedy stejn vazby a atributy jako ƒlánek. Soubor Složka Souborů Kontakt SložkaČlánků Článek Mapa Obrázek Složka Obrázků MístoMapy Obrázek 5.6: Diagram vztah entit (ERD) vztahujících se ke lánk m Obrázek Co p edstavuje tato entita není t eba vysv tlovat. Jejími jedinými atributy jsou název, název souboru a po adí, které p edur uje po adí p i p ípadném p i azení k jiné entit. Vazby entity jsou velice rozsáhlé - ƒlánek, V z, Prodejce atd Sloºka obrázk Význam této entity také není t eba nijak rozebírat. Entita má pouze název a po adí, které má stejnou funkci jako u Obrázku, protoºe p i hromadném p i azování obrázk lze p i adit i celé sloºky. Je to z toho d vodu, ºe kdyº se p i adí celá sloºka a dodate n se do ní p idá n jaký obrázek, projeví se to v²ude, kde je sloºka p i azená. Pokud by se p i azovaly jen jednotlivé obrázky sloºky, musela by se pak v²echna p i azení aktualizovat.

48 34 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU Soubor Soubor je v podstat ze systémového hlediska stejný jako Obrázek, akorát má navíc atribut popis, který nahrazuje graku obrázku a popisuje podrobn ji neº název, co soubor obsahuje Sloºka soubor Mezi touto entitou a entitou Sloºka obrázk není z hlediska systému ºádný rozdíl, akorát se nepojí s entitou Obrázek, ale Soubor Mapa Mapa reprezentuje gracké rozhraní mapy, na kterém jsou vyzna ená n jaká místa, která jsou relevantní pro stránku, kde se mapa vyskytuje. Mapa pot ebuje relativn hodn údaj. T mi základními jsou název a popis, které mohou být vyuºity uº na stránce, ale p edev²ím slouºí v p ípad, pokud je mapa zobrazována na samostatné stránce. Pro ur ení st edu mapy slouºí bu GPS nebo spojení s entitou Kontakt, kdy se p es adresu ur í místo, kde má být st ed mapy. Nakonec se u mapy ur uje jaký má mít výchozí zoom a jestli se má její název zobrazovat uº na stránce lánku, ke kterému je p i azená Místo mapy Místo mapy má mnoho stejných atribut jako Mapa - název, popis, GPS a stejn má i vazbu na Kontakt. Navíc je u entity atribut odkaz a vazba na Obrázek. Název, popis, odkaz a obrázek se pak zobrazují v detailu místa na map Banner Banner reprezentuje reklamní upoutávku na sluºby a produkty spole nosti nebo i na její partnery. Banner se zobrazuje na stránkách jako obrázek r zných formát a na r zných místech, která jsou p edem denovaná. Entita má tedy vazbu na Obrázek a atributy název, popis, odkaz a umíst ní a po adí ur ující, na jakém míst v daném umíst ní se banner zobrazuje Spole nost Tato entita reprezentuje ve²keré kontaktní údaje Autobazaru AB, které se pak vyuºívají nap. p i vystavování dokument nebo v hlavi ce a pati ce stránek Stát Tato entita má vazbu k entit Kontakt, kdy lze u kontaktních údaj k dokument m nebo komunikacím se zákazníkem ur it stát z mnoºiny t ch, které jsou v systému. Sou ástí entity jsou také atributy rozloha, po et obyvatel a EU, které do budoucna mohou umoºnit vytvá ení r zných statistik.

49 5.2. UšIVATELSKÉ ROLE Kraj Kraj je v podstat stejný entita jako Stát, akorát nemá atribut EU a má vztah práv je²t k entit Stát a to takový, ºe Kraj musí pat it práv k jednomu Státu Okres Okres naprosto stejný jako Kraj, akorát samoz ejm p ibývá vazba na na tuto entitu Poloºka menu Na webu je hlavní menu dvou úrovní a tato entita reprezentuje odkaz v tomto menu. Poloºky první úrovn tedy mohou mít je²t podpoloºky, dál pak uº ne. Atributy jsou pak pouze název a odkaz. 5.2 Uºivatelské role Do systému m ºe p istupovat mnoho r zných uºivatel, kaºdý má ale jiná práva, co m ºe v systému vid t, kam se v n m dostat a co spravovat. Za ú elem rozli²ení jednotlivých uºivatel a stanovení jejich práv jsou denovány uºivatelské role. V novém informa ním systému Autobazaru AB je celkem 6 rolí a systém funguje tak, ºe nad azení uºivatelé mohou editovat ty níºe postavené. Hierarchii uºivatel systému znázor uje následující UML diagram. Administrátor vozů Administrátor článků a multimédií Superadmin Hlavní administrátor Administrátor komunikace se zákazníky Prodejce Obrázek 5.7: UML diagram znázor ující hierarchii uºivatel IS Superadmin Superadmin je uºivatel, který nemá ºádné omezení práv a m ºe systém vyuºívat na 100% a spravovat tak ve²keré popsané entity. Tato role je v nována pouze správci systému.

50 36 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU Hlavní administrátor Tato role pat í vedení spole nosti. Jeho práva jsou velice podobná t m, která má Superadmin. Hlavní administrátor ale nem ºe spravovat n které systémové v ci nebo t eba p idávat dal²í hlavní administrátory Administrátor voz Uºivatel mající práva pro správu voz m ºe pracovat se v²emi entitami, které souvisejí s vozem, ale nesouvisejí s prodejem a komunikací. U voz tedy m ºe spravovat ve²keré jeho údaje, výbavu, p íslu²enství, parametry atd. V souvislosti s tím m ºe editovat i entity nesoucí mnoºinu údaj, které se p i azují k vozu, t mi jsou nap. typy p íslu²enství, zna ky a modely nebo úpravy vozu. Administrátor voz nesmí vid t ºádné informace o nákupních cenách a ziscích. Toto platí obecn pro v²echny administrátory niº²í role neº má hlavní administrátor, ºe nesmí vid t ºádné nan ní p ehledy spole nosti. Spravovat parametry Spravovat historii <<extend>> <<extend>> Spravovat příslušenství <<extend>> Spravovat vozy <<extend>> Spravovat výbavu Administrátor vozů <<extend>> <<extend>> <<extend>> Spravovat skupiny Spravovat obrázky Spravovat soubory Obrázek 5.8: Use-Case diagram administrátora voz Administrátor komunikace se zákazníky Role Administrátor komunikace existuje, aby mohl spravovat, korigovat a hlídat komunikaci prodejc a zákazník a není omezen ºádnou prodejnou. Spravovat m ºe v²echny typy komunikace a v souvislosti s tím i samotné zákazníky. Stejn jako prodejci m ºe p idávat poznámky

51 5.2. UšIVATELSKÉ ROLE 37 k vlákn m komunikace a v p ípad pot eby prodejnu nebo prodejce p ed zákazníkem zastupovat. UML diagram níºe vykresluje moºnosti a práva tohoto uºivatele, které v IS má. Spravovat zákazníky Spravovat objednávky <<extend>> Spravovat komunikace <<extend>> <<extend>> Spravovat dotazy na vůz Administrátor komunikace se zákazníky <<extend>> <<extend>> <<extend>> Spravovat poptávky financování Spravovat poznámky Spravovat hlídací psi Obrázek 5.9: Use-Case diagram administrátora komunikace se zákazníky Administrátor lánk a multimédií Z administrátor je poslední ten, který se stará o obsah webových stránek spole nosti. Do jeho kompetence v²ech nespadá katalog voz, který je v reºii hlavního administrátora a administrátora voz. Tento administrátor m ºe spravovat pouze oby ejné stránky, jejich texty, obrázky a zve ejn né soubory. Spolu s tím má samoz ejm moºnost pracovat s multimédii a to v etn banner.

52 38 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU Spravovat bannery Spravovat obrázky <<extend>> Spravovat články Administrátor článků a multimédií <<extend>> Spravovat mapy Spravovat soubory <<extend>> Prodejce Obrázek 5.10: Use-Case diagram administrátora lánk a multimédií Prodejce je specickým druhem administrátora, který má práva uzp sobená k tomu, aby mohl prodávat vozy a komunikovat se zákazníky. Prodejce má tedy podobná práva jako Administrátor komunikací se zákazníky, navíc je ale omezen svou p íslu²ností k prodejn, takºe nem ºe zasahovat do záleºitostí jiných neº, které náleºí jeho prodejn. Oproti administrátorovi komunikací má ale p ístup k p esunu voz, které se ho týkají a to tak, ºe bu ºádá o p esun vozu nebo vozidlo p edává jiné prodejn. 5.3 Interní procesy Jako kaºdá spole nost tak i Autobazar AB má n jaké interní procesy. V t²ina interních proces jsou specické pro kaºdou spole nost. V této kapitole budou popsány hlavní procesy autobazaru, které se týkají IS, jeho entit a mají vliv na práva uºivatel. Jelikoº samotné popisy proces by mohly být nejasné, jsou dopln ny o Activity Diagramy P esun vozu P esun vozu se uskute uje z r zných d vod - vyrovnání stavu voz na prodejn, zájem zákazníka o v z, který je jinde, nebo i p esun vozu do servisu kv li n jaké závad. V p ípad, kdy n jaký prodejce pot ebuje dostat v z k sob na prodejnu, zadá si poºadavek a systém informuje hlavního administrátora, který musí poºadavek potvrdit. Pokud ho neschválí, systém pouze informuje prodejce a nic se ned je. Pokud ano, systém informuje prodejce i prodejnu, která má v z p edat, aby vystavila p edávací protokol a v z p ipravila k p esunu. Jakmile se v z dostane na cílovou prodejnu, p ejímající prodejce vystaví p ejímací protokol, který

53 5.4. OBJEDNÁVKA VOZU 39 je v podstat dopln ním p edávacího protokolu, kam se prodejce vyjád í k tomu, jestli stav vozidla souhlasí s tím, jak byl popsán p edávající prodejnou, tím proces kon í. Ob prodejny pak mohou kdykoliv i zp tn nahlíºet do obou vystavených protokol. Proces přesunu vozu na jinou prodejnu Žádající prodejce Předávající prodejce Administrátor upozornění mailem Vytvoření požadavku Přijetí požadavku upozornění mailem Schválení Přijetí výsledku schválení upozornění mailem Přijetí požadavku schváleno Přijetí vozu zamítnuto Vystavení předávacího protokolu Vystavení přejímacího protokolu Předání vozu Obrázek 5.11: Activity Diagram - p esun vozu 5.4 Objednávka vozu Objednávka m ºe být zapo ata dv ma zp soby. První je vytvo ením rezervace, kterou m ºe ud lat jak zákazník p es web, tak prodejce p es IS. Aby mohl být prodej uskute n n, je rezervaci t eba potvrdit a ud lat tím z ní objednávku. Druhým zp sob je, ºe prodejce vytvo í rovnou potvrzenou rezervaci, tedy objednávku. V tu chvíli je v z blokovaný a není moºné vytvá et na n j jiné objednávky.

54 40 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU P ed vystavování dokument je t eba objednávku vyplnit, coº je rozd leno na n kolik krok. V prvním se zadává p edm t prodeje, kde je jiº na za átku objednaný v z a je moºnost p idat nap. prodlouºenou záruku, poji²t ní, p íslu²enství nebo dodate né úpravy vozu. Poté se zadají smluvní strany, které jsou jiº p edvypln né tím, co se vyplnilo p i vytvá ení rezervace nebo objednávky. A v posledním kroku se vybere zp sob nancování, kde se u moºnosti hotovost nebo p evodem nevypl uje uº nic jiného, ale u moºností úv r a leasing je t eba zadat akontaci, banku a íslo úv rové smlouvy. Poté, co je objednávka vypln na, je moºné za íst vytvá et dokumenty pot ebné k prodeji. To m ºe za ít tak, ºe se vystaví rovnou prodejní faktura a kupní smlouva nebo tak, ºe se nejd íve vystaví zálohová faktura a spolu s ní rezerva ní faktura a zákazník pak má 14 dní na zaplacení zbytku nebo zaplacení dal²í zálohy. Pokud ani jedno zákazník do 14 dn neud lá, objednávka i zaplacené zálohy propadají. Pokud v²e prob hne, jak má, vystaví se prodejní faktura, ve které jsou zálohy ode teny, poté se uzav e kupní smlouva. Na konci celého procesu se vystaví prodejní protokol o stavu vozu a s ním p edávaných v cech. Vytvoření objednávky Vyplnění předmětu prodeje Vyplnění smluvních stran Vytvoření rezervace Potvrzení rezervace Vystavení zálohové faktury Výběr financování Propadnutí objednávky a zaplacených záloh Uzavření rezervační smlouvy zákazník nedoplatí zbylou částku zákazník doplatí zbylou částku Přesunutí objednávky mezi prodeje Vystavení prodejního protokolu Uzavření kupní smlouvy Vystavení prodejní faktury Obrázek 5.12: Activity Diagram - objednávka

55 5.5. KOMUNIKACE SE ZÁKAZNÍKEM Komunikace se zákazníkem Proces komunikace zahajuje v podstat sám zákazník a to tím, ºe n jakým zp sobem kontaktuje Autobazar AB. To m ºe být bu prost ednictvím webových stránek, kde vyplní a ode²le n jaký formulá, nebo osobn, telefonicky i em kontaktuje p ímo n jakou prodejnu. V takovém p ípad pak z pohledu IS zahajuje komunikaci prodejce, který za zákazníka zaloºí vlákno komunikace. Poté je moºné ke komunikaci p idávat dal²í poznámky o tom, jak komunikace se zákazníkem pokra uje. Kdyº komunikace skon í a uº úsp ²n prodejem vozu nebo neúsp ²n, vlákno komunikace se uzav e. Založení vlákna komunikace prodejcem za zákazníka Založení vlákna komunikace zákazníkem - odeslání formuláře Přidávání poznámek ke komunikace prodejcem Uzavření komunikace po úspěšné obchodu Uzavření komunikace bez obchodu Obrázek 5.13: Activity Diagram - komunikace se zákazníky

56 42 KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU

57 Kapitola 6 Návrh e²ení nového systému V návaznosti na uºivatelské role a interní procesy analyzované v p edchozí kapitole je v této kapitole proveden návrh navigace v systému. P edposlední podkapitola je pak v nována krátkému pohledu na architekturu systému, která je znázorn na diagramem nasazení. A kapitolu analýza nakonec uzavírá návrh databáze. 6.1 Prost edky a technologie V této sekci jsou popsány prost edky a technologie pouºité pro implementaci IS. D vod pouºití práv t chto prost edk je bu na základ poºadavk zadavatele, nebo na základ standard WWW a komunity a podpory t chto prost edk PHP PHP je ²iroce pouºívaný mnohoú elový skriptovací jazyk, který je obzvlá²t vhodný pro vývoj webových aplikací a lze jej zapouzd it do HTML.[21] Tento jazyk byl zvolen pro vývoj systému, protoºe ani nebyla jiná moºnost. Zadavatel má sv j server, kde b ºí Apache, a ve²keré webové aplikace, které vyvíjí, jsou psané v PHP. PHP má navíc mnoho výhod, ale samoz ejm i nevýhod. Jednou z kladných stránek je jednoduchost a volnost p i psaní kódu a práci s HTML. To ale p iná²í úskalí v psaní dobrého kódu, je tedy t eba mít a udrºovat n jaký systém. U verze 5 se také výrazn zlep²ila podpora OOP, stále se to ale nedá porovnávat nap. s jazykem Java. Uº i tak je práce s objekty p íjemná a velmi usnad ující. Nejv t²í výhodou PHP je jeho roz²í enost a ²iroká komunita uºivatel. To s sebou p iná²í také celou adu nejr zn j²ích modul, roz²í ení a hotových e²ení nejr zn j²ích problém HTML HTML je publikující jazyk WWW[12] a v podstat jde o jediný jazyk pro vytvá ení klasických webových stránek. Jeho pouºití je op t relativn jednoduché. Mezi tagy, které jsou denované, nebo do jejich atribut se umis uje obsah, který na stránce chceme zobrazit. V n kterých p ípadech jako t eba u obrázk se do tagu zadává URL a to jako hodnota 43

58 44 KAPITOLA 6. NÁVRH E ENÍ NOVÉHO SYSTÉMU parametru. Nová verze HTML 5 pak roz²i uje mnoºinu tag, které lze pouºít a také roz²i uje moºnosti práce s multimédii CSS Kaskádové styly (CSS) je jednoduchý mechanismus pro p idání stylu (nap. fonty, barvy, ádkování) do webových dokument.[7] CCS umoº uje pozicovat HTML elementy, ur ovat vzhled textu, tabulek, ur ovat pozadí nebo ohrani ení element a mnoho dal²ího. Verze CSS 3 uº také poskytuje celou ²kálu moºností pro rozhýbání webových stránek. Mnoho funkcí ale stále není n kterými prohlíºe i podporováno nebo je kaºdý prohlíºe zobrazuje jinak. Tradi n nejvíce práce je vyladit styly pro v²echny aktuáln pouºívané verze Internet Exploreru 2, protoºe i nejnov j²í verze je vºdy oproti jiným prohlíºe m v podpo e nejnov j²ích technologií pozadu a navíc kaºdá verze IE asto zobrazuje stejné stránky jinak JavaScript JavaScript je skriptovací jazyk na webu a je pouºíván v miliardách webových stránek k p idání funkcí, ov ování formulá, komunikování se serverem a mnoho dal²ího.[17] Je moºné pomocí n j ud lat stránky dynamické a interaktivní a to bez nutnosti znovu na ítat stránku, protoºe se skript zpracovává na stran klienta v jeho prohlíºe i. To ov²em stejn jako u CSS p iná²í problémy se závislostí na prohlíºe i, jeho verzi a podpo e r zných funkcí. JavaScript má také základní vlastnosti objektov orientovaného jazyka. JavaScript se asto spojuje s jazykem Java, se kterým ale krom ísti názvu a áste n podobné syntaxi nemá nic spole ného. JavaSkcript je interpretovaný jazyk, kdeºto Java se musí p ed interpretací zkompilovat AJAX AJAX (Asynchronous JavaScript and XML) není nový programovací jazyk, ale nový zp sob jak pouºívat existující standardy. AJAX je um ní vým ny dat se serverem a aktualizace ástí webové stránky bez znovu na ítání celé stránky.[4] AJAX posílá poºadavek na n jaká data na server a poté, co je získá, s nimi m ºe dál pracovat. V názvu je slovo "asynchronní"proto, ºe skript, který posílá poºadavek na server, b ºí asynchronn od zbylého skriptu. Zatímco zbylý skript mohl dávno prob hnout, ten ºádající o data na n m ºe je²t ekat. XML v názvu je trochu zavád jící, jde o jeden z formát, který umí AJAX zpracovat jako odpov. Odpov dí ale m ºe být i oby ejný text nebo JSON SQL SQL je standardní jazyk pro p istupování k databázi[26], který umoº uje manipulaci dat v DB a jejich získávání odtud. Jazyk také umí manipulovat i se samotnou databází a její strukturou. SQL je ur ený pro rela ní databázové systémy a je ²iroce podporován v etn spole ností Oracle 3 i Microsoft 4. 2 Jeden z nejpouºívan j²ích prohlíºe od spole nosti Microsoft

59 6.2. MODULY MySQL MySQL je sv tov nejpopulárn j²í open source databáze.[19] Jde o RDBMS, coº je systém ízení báze dat, který b ºí jako server poskytující p ístup více uºivatel m najednou k libovolnému po tu databází. MySQL uº podle názvu pracuje s jazykem SQL a je asto pouºíván dohromady s PHP, kde má vysokou podporu. 6.2 Moduly V této ásti jsou popsány moduly, coº jsou hotová e²ení r zných problém, které by se jinak v systému musely e²it. Takovými je nap. nahrávání obrázk nebo generování PDF. Moduly byly vybrány na základ jejich vlastností, dokumentace, roz²í ení, podpo e a zku²enostech jiných uºivatel. Tyto kritéria zahrnují i poºadavky zadavatele, kterému ²lo o to, aby se neexperimentovalo a do systému se nezavád li n jaké neodzkou²ené pluginy. Moduly pracují na bázi vý²e popsaných technologii (jedné nebo i více) a n které moduly spolupracují i s jinými moduly jquery jquery je rychlá, malá a na funkce bohatá JavaScript knihovna. D lá v ci jako pr chod HTML dokumentem a manipulaci, zpracování událostí, animaci a AJAX mnohem jednodu²í s snadno pouºitelným API, které pracuje nap í mnoha prohlíºe i. Zkombinování v²estrannosti a roz²i itelnosti jquery zm nilo psaní JavaScriptu tak, ºe ho nyní pí²í miliony lidí.[14] jquery je rozd leno na n kolik balík, kdy hlavní balík samotné jquery umoº uje práci s JS. Dal²í hojn pouºívaný balík je jquery UI, který obohacuje jquery o moºnosti práce s uºivatelským rozhraním. jquery UI je organizovaný soubor interakcí uºivatelského rozhraní, efekt, widget a motiv postavených na vrcholu knihovny jquery.[16] Pomocí jquery UI lze ud lat vysoce interaktivní webové aplikace, ale i jen p idat kalendá do textového pole pro zadání data. jquery poskytuje i dal²í balí ky, kdy z t ch nejnov j²ích je v sou asnosti asi nejzajímav j²í a nejpropracovan j²í jquery Mobile. Jde o jednotný na HTML 5 zaloºený systém uºivatelského rozhraní pro v²echny platformy populárních mobilních za ízení postavený na skálopevném jquery a jquery UI. Jeho lehký kód je postaven s postupným roz²i ováním a má exibilní a snadno upravitelný design.[15] Bootstrap Bootstrap je elegantní, intuitivní a výkonný front-end framework pro rychlej²í a snadn j²í vývoj webových aplikací.[5] Tento framework vznikl p vodn jako sada nástroj pro Twitter 5. ƒasem se ale Bootstrap roz²í il a spoluprací mnoha lidí se roz²í ily i moºnosti jeho vyuºití. Pomocí CSS a HTML denuje jednotnou typograi, jednotný vzhled formulá, tabulek, tla ítek, navigace a dal²ího. Bootstrap také asem za al vyuºívat JavaScript, resp. jquery a e²it r zné vysouvací menu, vyskakovací okénka nebo bublinové popisky. 5 Sociální sí (

60 46 KAPITOLA 6. NÁVRH E ENÍ NOVÉHO SYSTÉMU Bootstrap po ítá i s vyuºitím na mobilních za ízení, a proto zohled uje i relativn nový trend ve vývoji webových aplikací Responsive Web Design (RWD)[24]. Pokud je n jaká stránka e²ena tzv. responsivn, neznamená to, ºe má speciální verzi pro mobilní za ízení, ale ºe se její obsah p izp sobuje velikosti obrazovky, tak aby byl i na nejmen²ích obrazovkách mobilních telefon pohodln itelný a pr chozí. Ve²keré prvky, které Bootstrap navrhuje, se p i implementování balí k, které RWD zohled ují, zobrazují responsivn jquery File Upload jquery File Upload je widget pro nahrávání soubor s podporou výb ru více soubor, drag&drop, grackého znázorn ní pr b hu nahrávání, zm nou velikostí obrázk a mnoha platforem v etn PHP.[10] Jak jiº název napovídá, modul vyuºívá jquery, ale také Bootstrap, takºe je velice uºivatelsky p ív tivé. Tento modul je velice uºite ný jak pro programátory, tak pro uºivatele. Z programátorského hlediska je vytvo ení dobrého nahrávání obrázk a soubor velmi t ºkým úkolem, coº nasazením File Uploaderu odpadá, a uºivatel m ºe pohodln nahrávat libovolný po et soubor najednou prettyphoto Obrázek 6.1: Ukázka nahrávání obrázk p es jquery File Upload prettyphoto je jquery lightbox 6 klon.[23] Nejen, ºe podporuje obrázky, ale také videa, ash, YouTube 7, iframy a AJAX. Je to plnohodnotný média lightbox. Stejn jako lightbox je i prettyphoto velice snadno pouºitelný, do stránky se vloºí jeden JS, jedno CSS a k danému odkazu se p idá jeden atribut a je v podstat hotovo. Tento modul pak umoº uje, aby se v²e odehrávalo na dané stránce, a není t eba sm rovat odkazy do nových nebo pop-up oken CKEditor CKEditor je snadno pouºití HTML textový editor navrºený ke zjednodu²ení vytvá ení webového obsahu. Je to WYSIWYG editor, který p iná²í b ºné funkce textového procesoru p ímo na webové stránky.[6] CKEditor pracuje primárn na bázi JS, HTML a CSS. Jde 6 JS prohlíºe obrázk ( 7 Server pro sdílení videí (

61 6.2. MODULY 47 o velice rozsáhlou aplikaci, která ²irokou ²kálu p izp sobení funk nosti, kongurace a doinstalování nejr zn j²ích modul. Z nejd leºit j²ích moºností kongurace je nastavení panelu nástroj a nadenování styl jak pro textové pole, ve kterém se obsah spravuje, tak pro výb r styl, které m ºe uºivatel pouºívat. Nejv t²ím konkurentem CKEditoru je TinyMCE. Kaºdý z t chto editor má n co a mezi webovými vývojá i není v podstat jednotný názor na to, který editor je lep²í. Takový názor nebyl ani v dob FCKEditoru, coº je p edch dce CKEditoru. Editory jsou si, co se UI týká, velice podobné. CKEditor se ale vyvinul p edev²ím v oblasti vytvá ení HTML kódu. Tato verze uº je ale na sv te pár let a od té doby se vyvinul i TinyMCE, takºe ani upgradem FCKEditoru na CKEditor se v konkuren ním boji nic nezm nilo. Nicmén v IS Autobazaru AB bude pouºit CKEditor. Jde o p ání zadavatele, protoºe spole nost DIS Media pouºívá výhradn práv tento editor mpdf Obrázek 6.2: Ukázka CKEditoru mpdf je PHP t ída, která vytvá í PDF soubory z HTML dokument kódovaných UTF-8. T ída je zaloºena na FPDF 8 a HTML2FPDF 9, ale s adou vylep²ení.[18] Generování PDF pomocí této t ídy je velice snadné, protoºe sta í vytvo it HTML stránku s vno enými styly a t ída podle ní vygeneruje PDF. Toto je velká výhoda, protoºe v p ípad, kdy je pot eba stejný obsah odeslat nap. i mailem, nemusí se vytvá et dva r zné kódy. T ída navíc zavádí dal²í tagy a funkce, které zohled ují, ºe PDF je oproti HTML stránkované. Jedním z takových tag je nap. <pagebreak />, který ukon uje jednu stránku PDF a za íná novou

62 48 KAPITOLA 6. NÁVRH E ENÍ NOVÉHO SYSTÉMU FPDF a HTML2FPDF, na nichº je mpdf stav ná, sice poskytují více mén to samé, ale v dale mén pohodlné form. Dal²í moºností, jak v PHP generovat PDF je PHP knihovna PDFlib 10. Psaní kódu pro generování PDF pomocí toho roz²í ení ale není o nic jednodu²²í neº u FPDF a HTML2FPDF. Jednoduchost generování PDF z HTML asi jen tak nic nep ed í. mpdf m lo jednu nevýhodu, ºe vygenerované soubory byly velké (1 MB a více), to jiº ale bylo upraveno a nyní dvou nebo t ístránkové dokumenty mají kolem 50 KB PHPMailer PHPMailer je pravd podobn sv tov nejpouºívan j²í kód pro posílání pomocí PHP.[22] Tuto t ídu vyuºívají i velké a roz²í ené systémy jako Drupal nebo Joomla. V PHP sice existuje funkce mail(), která odesílání mail e²í, ale pokud má být mail trochu sostikovan j²í, je p inejmen²ím nelehké v²e ádn o²et it. PHPMailer podporuje HTML formát mailu, CSS, p ílohy, zasílání více adresát m na jednou nebo má i intergrované SMTP bez nutnosti lokálního SMTP serveru. 6.3 Webové sluºby Webová sluºba je metoda komunikace mezi dv ma elektronickými za ízeními p es WWW. Jde o softwarovou funkci poskytovanou na ur ité adrese p es web nebo cloud a tato sluºba je vºdy p ístupná podle konceptu ve ejných sluºeb.[29] Webová sluºba umoº uje jiným systém m vyuºívat funkcionalit systému, který sluºbu poskytuje a to p es programátorské rozhraní (API) Google Maps API Google Mapy mají ²irokou ²kálu API, které umoº ují vloºit robustní funk nost a kaºdodenní uºite nost Google Map do vlastní webové stránky a aplikace a p ekrýt je vlastními daty.[11] Google Maps API umoº uje ur ovat ovládací prvky mapy, její chování a vlastnosti a data (resp. místa), která se mají na map zobrazovat Facebook API Programátorské rozhraní Facebooku umoº uje vkládat na stránku tla ítka "To se mi líbí", tla ítka pro odesílání, vkládání p ísp vk a dal²í pluginy. API také umoº uje p ihla²ování na FB, se který se pak dá v rámci systému pracovat.[9] Pomocí FB API lze propojit web jak s konkrétním prolem na FB, tak i jen dát uºivatel m moºnost se o stránku na FB pod lit. Pomocí p ihla²ování lze pak uºivatel m zp ístupnit neve ejné sekce, kdy se nemusí registrovat a pamatovat dal²í z mnoha p ihla²ovacích údaj, které pouºívají. 10

63 6.4. UšIVATELSKÉ ROZHRANÍ A NAVIGACE AddThis AddThis je e²ení pro inzerenty jak pouºít perfektní kombinaci v dy dat a lidského poznání, které pomohou získat nové zákazníky, angaºovanost a inteligenci marketingovým plán m.[2] AddThis poskytuje nejr zn j²í pluginy pro celou ²kálu sociálních sítí a získat nejr zn j²í záznamy, p ehledy, grafy a diagramy o aktivit náv²t vník na webu, jejich zájmu o n j a vyuºívání daných plugin. 6.4 Uºivatelské rozhraní a navigace P i tvorb uºivatelského rozhraní a navigace v nové IS budou pouºity p edev²ím UI prvky, které poskytuje Bootstrap. Tyto prvky mají jednotný a moderní vzhled, jsou uºivatelsky p ív tivé, snadno pouºitelné a jejich celá ada nejr zn j²ích typ a variant. Bootstrap poskytuje typy UI prvk od nejmen²ích tla ítek, p es záloºky, vysouvací menu, formulá ová poli ka aº po vyskakovací dialogová okna nebo r zné bublinové nápov dy a popisky. Pro hlavní panel bude pouºita ²ablona, která obsahuje titulek stránky, hlavní menu, vyhledávací pole a podruºné menu, které m ºe být pouºito nap. jako menu uºivatele. Obrázek 6.3: Ukázka Bootstrap hlavního panelu Boostrap nabízí i jednoduchou drobe kou navigaci, která slouºí k informování, v jaké ásti systému se uºivatel nachází, a poskytuje rychlý zp sob, jak se dostat do vy²²ích úrovní. Obrázek 6.4: Ukázka Bootstrap drobe kové navigace Pro rozd lení stránek nebo velkých formulá na logické celky se velice hodí záloºky, které jasn ukazují, jaké podsekce jsou na stránce dostupné a umoº uje snadné p echázení mezi nimi. Obrázek 6.5: Ukázka Bootstrap ºáloºek Výpis poloºek se standardn e²í pomocí tabulky, která dob e a p ehledn zobrazuje a organizuje i velké mnoºství dat.

64 50 KAPITOLA 6. NÁVRH E ENÍ NOVÉHO SYSTÉMU Obrázek 6.6: Ukázka Bootstrap tabulky Výpis poloºek m ºe být ale ob as nep ijateln dlouhý a zp sobovat nep ehlednost a zp - sobovat dlouhé na ítání stránky. To se e²í pomocí stránkování. Boostrap nabízí navigaci i pro tento p ípad. Obrázek 6.7: Ukázka Bootstrap stránkování Odkazy na akce a operace je standardní e²it pomocí odkaz z ikonek a tla ítek. Boostrap e²í celou adu variant tla ítek, které mohou mít r zné barvy, mohou obsahovat text, ikonku nebo mohou být skrývat i vysouvací menu. Obrázek 6.8: Ukázka Bootstrap tla ítek Tla ítka v kombinaci s ikonkami a bez text jsou velice vhodná do výpisu poloºek, kde nebývá místa k plýtvání a kde fungují odkazy na operace, které je moºné s poloºkami d lat. Texty vedle ikonek jsou t ídy, které se pak ur ují u elementu, kde má ikonka být. Obrázek 6.9: Ukázka Bootstrap ikonek Bootstrap poskytuje celou adu formulá ových prvk op t r zných variant a velikostí. Na obrázku níºe je oby ejné textové pole, ale ve stavu, kdy v n m po odeslání formulá e byla nalezena chyba. Obrázek 6.10: Ukázka Bootstrap informování výskytu chyby ve formulá ovém polí ku

65 6.5. STRUKTURA A ARCHITEKTURA SYSTÉMU 51 Nezbytnou sou ástí UI je i informování uºivatele o tom, jak daná akce prob hla. Následující dva obrázky ukazují dv nejb ºn j²í varianty - úsp ²n a neúsp ²n. Obrázek 6.11: Ukázka Bootstrap informování o výskytu chyby Obrázek 6.12: Ukázka Bootstrap informování o úsp ²n provedené akci Ob as je pot eba, aby uºivatel n co potvrdil, nap. poºadavek na smazání n jaké poloºky, aby nemohlo dojít k n jaké nevratné zm n kv li pouhému p ekliknutí. Také m ºe být t eba uºivatele o n em informovat tak, aby bylo jist, ºe to nep ehlédne. Pro oba tyto p ípady se velmi hodí dialogové okno, které se objeví v úplném pop edí stránky a zablokuje UI pod ním, dokud uºivatel okno n jaký zp sobem (potvrzení nebo zru²ení) nezav e. Obrázek 6.13: Ukázka Bootstrap dialogového okna 6.5 Struktura a architektura systému Nový informa ní systém je navrºen na bázi t ívrstvé architektury, která zavádí do kódu ád a jasn rozd luje funkce jednotlivých ástí skript. První vrstva je datová, ta se stará o data, komunikuje s databází a ídí p ístup k nim. Druhá je aplika ní vrstva, která se stará o zpracování akcí, a uº je to poºadavek výpis dat nebo odeslání formulá e. Poslední vrstva je prezenta ní, ta e²í výstup dat a jak budou uºivateli zobrazena. Komunikace s databází a získávání dat z ní je e²eno podle návrhového vzoru Active Record. Jde o architektonický vzor pouºívaný u aplikací, které ukládají data do rela ních databází. Aby rozhraní objektu vyhovovalo tomuto vzoru, m lo by zahrnovat funkce IN- SERT, UPDATE, DELETE a vlastnosti, které více mén odpovídají sloupc m tabulky v databázi.[1] P i pouºití tohoto vzoru jde o to, ºe p ístup k dat m je zabalen do t íd. Instance této t ídy pak odpovídá ádku z tabulky v databázi. Komunikace uºivatele, v²ech t í vrstev a databáze je znázorn na na následujícím sekven ním diagramu.

66 52 KAPITOLA 6. NÁVRH E ENÍ NOVÉHO SYSTÉMU Klient Prezentační vrstva Aplikační vrstva Datová vrstva Databáze požadavek vyvolání akce provedení požadavku SQL dotaz na databázi vrácení dat zpracování dat stažení stránky sestavení stránky Obrázek 6.14: Sekven ní diagram komunikace vrstev systému Celý systém je umíst n na serveru, kde beºí Apache 11 s PHP a databází MySQL. S klientem se komunikuje pomocí protokolu HTTP a odesílá se mu stránka sloºena z HTML, CSS a JavaScriptu. Pomocí Javascriptu se na stran klienta pak komunikuje s Facebook API a Google Maps API p es protokol HTTPS. Prohlížeč Server HTML HTTP PHP MySQL CSS Uživatel Google Server Facebook Server Javascript HTTPS Maps API API HTTPS Obrázek 6.15: Diagram nasazení 11

67 6.6. DATABÁZE Databáze P i návrhu databáze se v t²inou vytvá í diagram databáze. V p ípad tohoto IS by byl ale velice rozsáhlý a lze vyjít z popisu entit a jejich vztah. Diagram databáze pak nahradí jednotlivé ERD. P i vytvá ení databáze je t eba postupovat tak, ºe pokud je kardinalita many-to-many, musí se vytvo it vztahová tabulka s atributy pro ID z obou tabulek. Pokud se mají dát tyto poloºky adit, musí p ibýt i atribut poradi. Pokud je kardinalita jiná, sta í tabulky provázat p es atribut nap. tabulka_id. V t²ina dat se z databáze ve skute nosti nemaºe, ale ozna uje jako smazaná, a je tedy t eba p idat atribut smazano. Pouze pro informaci a p ípadn i dal²í pouºití se p idává i atribut vytvoreno, který se p i vytvá ení nastaví na aktuální datum a as. Tyto atributy nejsou u vztahových tabulek a atribut smazano není ani u tabulek obrazky a soubory, protoºe ádky z t chto tabulek se doopravdy vymazávají stejn jako dané soubory, aby nezabíraly místo na serveru. Citlivá data jako jsou hesla se nesmí v databázi objevovat v neza²ifrované podob. V²echna hesla jsou tedy ²ifrována pomocí SHA 12. Databázové jádro tabulek databáze je MyISAM 13, které je pro MySQL výchozí. Pro kódování data je pak pouºito nejnov j²í utf8mb4_unicode_ci Adminer Adminer je pln vybavený nástroj pro správu databáze napsaný v PHP. Na rozdíl od php- MyAdmin, se skládají z jediného souboru p ipraveného k nasazení na cílový server. Adminer je k dispozici pro MySQL, PostgreSQL, SQLite, MS SQL a Oracle.[3] Pro práci s databází systému se vyuºívá práv tento nástroj, protoºe správa databáze a dat v ní je s ním velmi efektivní. Oproti phpmyadmin má mnoho r zných vylep²ení a moºností správy tabulek a dat jako t eba správa dat p ímo ve výpise po dvojkliku na polí ko, moºnosti dodate ného azení sloupc tabulky nebo plná editace pohled. Velice ²ikovné jsou i odkazy na tabulky a na dokumentaci v SQL kódu. Obrázek 6.16: Adminer

68 54 KAPITOLA 6. NÁVRH E ENÍ NOVÉHO SYSTÉMU

69 Kapitola 7 Implementace nového systému V této kapitole je popsána implementace nového informa ního systému spole nosti Autobazar AB, která probíhala na základ poºadavk zadavatele, analýzy a návrhu, které byly popsány v p edchozích kapitolách. V této kapitole je jiº rozebráno samotné e²ení a výsledná struktura systému. Pro ukázku jsou uvedeny i n které zajímavé kódy. První ást této kapitoly se zabývá funkcí jednotlivých sloºek a soubor systému. Dal²í kapitola je zam ena na t ídy, kdy jsou popsány spí²e obecn, jak jsou len né a jaké obecn obsahují funkce. T etí podsekce rozebírá generování stránky, jaké skripty a v jaké posloupnosti se na ítají. V dal²í ásti je popsáno jak byly pouºity jednotlivé moduly, které byly popsány v návrhu. A poslední podkapitola pak pojednává o zabezpe ení systému. 7.1 Sloºky a soubory systému Ko enová sloºka je ur ena výhradn soubor m aplika ní a prezenta ní vrstvy webu a souboru.htaccess. Soubory aplika ní a prezenta ní vrstvy informa ního systému jsou ve sloºce admin123. V této sloºce jsou také podsloºky se soubory, které jsou výhradn pro IS. T mi jsou styly a javascript pro prezenta ní vrstvu IS. Dal²í sloºkou systému je ajax, kde jsou uloºené soubory s PHP skripty, pomocí kterých komunikuje AJAX se serverem. Takovým skriptem m ºe skript, který vrací JSON s modely konkrétní zna ky. V dal²í sloºce classes jsou uloºené ve²keré t ídy reprezentující tabulky v databázi. T ídy jsou pak blíºe popsané v dal²í podkapitole. Dal²í sloºka css je ur ena pro styly webu. V této sloºce nejsou CSS soubory ºádných modul, ty jsou vºdy s daným modulem pohromad. Sloºka documents je ur ena pro ve²keré dokumenty vytvá ené systémem. Protoºe systém vystavuje více typ soubor, má tato sloºka podsloºky orders pro faktury, contracts pro smlouvy a protocols pro protokoly. Následující sloºka les obsahuje soubory nahrané p es sekci Soubory, který je v IS. Tato sloºka v²ak neobsahuje obrázky, které se spravují v sekci Obrázky, ty mají vlastní sloºku images. V ko enu této sloºky jsou uloºené obrázky v nejv t²ím formátu denovaném v systému. Dále jsou pak ve sloºce podsloºky thumbs1-3 pro t i men²í formáty obrázk a podsloºka org, kde jsou obrázky ve velikosti v jaké byly nahrávány. Sloºka js jiº byla zmín na u IS, kde jsou v ní javascripty, v ko enové sloºce má stejný ú el, akorát javascripty v ní jsou ur ené pro web. 55

70 56 KAPITOLA 7. IMPLEMENTACE NOVÉHO SYSTÉMU Jednou z velmi d leºitých sloºek je sloºka modules, který obsahuje v²echny moduly popsané v návrhu systému a dal²í pluginy, widgety apod. Dal²í sloºka pics slouºí jako úloºi²t gracký prvk jako jsou vlaje ky, ikonky, loga a jiné obrázky, které se pouºívají v IS i na webu. Sloºka temp uzavírající adu sloºek slouºí pouze jako do asné úloºi²t pro nahrávání soubor. Po dokon ení procesu jsou soubory z této sloºky okamºit smazány. V popisu sloºek byla jedna sloºka vynechána a to sloºka includes. Jde o jednu ze st ºejních sloºek systému, resp. obsahující st ºejní soubory. T mi jsou cong.php, functions.php, db.php a action-report.php. Soubor cong.php obsahuje PHP skript, který je pot eba vloºit na za átek kaºdého skriptu, který je v systému spou²t n. Jde o inicializa ní soubor systému. Deklarují se v n m konstanty s URL a cestami k systémovým sloºkám, s údaji pro p ipojení s databází a jinými systémovými údaji jako je t eba aktuální datum a as nebo IP adresa klienta. Nastavuje se zde session pomocí funkcí pro zm nu php.ini, coº je kongura ní soubor PHP na serveru. Také se v souboru includují v²echny nezbytné soubory systému v etn v²ech t íd se sloºky classes a vytvá í se objekty pro práci s databází a pro vytvá ení systémových hlá²ek a upozorn ní. Na úplném za átku se také zji² uje as za átku spu²t ní skriptu s p esností na milisekundy, který pak spolu s asem ukon ení b hu skriptu vypo ítává dobu generování stránky, která se pak zobrazuje v pati ce stránky pro informování uºivatele. Tento soubor se také stará o to, jestli je uºivatel do systému p ihlá²en jako administrátor nebo prodejce. V p ípad ºe je, na te ve²keré údaje o administrátorovi. Pro n které údaje se vytvo í konstanty, aby se zabezpe ily hodnoty v rámci systému. Také inicializuje pole s údaji o tom, kam má uºivatel v systému p ístup. Pokud ºádný administrátor p ihlá²en není, nastaví se pot ebné prom nné a konstanty na NULL. Celý PHP kód pro zpracování p ihlá²ení administrátora je ukázán níºe. Na konci souboru se také na ítají údaje o spole nosti. U konstant nehrozí problém p epsání, ale bohuºel do konstant nelze vloºit pole nebo na íst objekt. Proto je t eba ve v²ech dal²ích skriptech pod tímto inicializa ním dávat pozor, aby systémové prom nné nebyly nep epsány. Soubor functions.php je souborem funkcí, které dost asto nahrazují nativní PHP funkce, které n jakým zp sobem upravují nebo roz²i ují. Funkcí v tomto souboru je n kolik desítek, je mezi nimi funkce pro vytvo ení javascriptu Google Mapy, odeslání mailu, p evedení ísla na slovo, vytvo ení stránkování a mnoho dal²ích. Pokud se u funkce pracuje s mnoha parametry nebo se po ítá s tím, ºe se asem m ºe roz²í it, má funkce denován pouze jeden parametr args, který musí být pole, které obsahuje ve²keré parametry, které by jinak musely být u funkce jednotliv denované.

71 7.1. SLOšKY A SOUBORY SYSTÉMU 57 if (isset($_session['admin_id'])) { $admin = new Administrator($_SESSION['admin_id']); // vytvoreni objektu administratora $_SESSION['admin_id'] = $admin->get_id(); // prepis session // zjisteni, jestli administrator opravdu existuje a~oznacen jako aktivni if ($admin->get_id() && $admin->get_aktivni() &&!$admin->get_smazano()) { define('admin_id', $admin->get_id()); define('admin_role', $admin->get_role()); define('admin_prodejna_id', $admin->get_prodejna_id()); define('admin_prodejce_id', $admin->get_prodejce_id()); $admin_kontakt = new Kontakt($admin->get_kontakt_id()); // nacteni kontaktnich udaju // nacteni prav uzivatele $args['where']['aktivni'] = 1; // doplneni $args $admin_prava = $admin->get_prava($args); unset($args); $admin_stranky = array(); // z~prav uzivatele se vytahnou stranky, ke kterym ma pristup a~podle toho se pak probere menu // pokud vnejakem pravu ma uzivatel nastaveno, ze ma pristup ke vsem strankam, je jasno if (check_array($admin_prava)) { foreach ($admin_prava as $row) { if ($row['stranka'] == '*') { $admin_stranky = '*'; break; } else { $admin_stranky[] = $row['stranka']; } } } } else { $no_admin = true; } } else { $no_admin = true; } // nastaveni promennych na~null, kdyz administrator prihlaseni neni if ($no_admin) { unset($admin); unset($_session['admin_id']); define('admin_id', null); define('admin_role', null); define('admin_prodejna_id', null); define('admin_prodejce_id', null); $admin_stranky = false; } Ukázka kódu 1: Zpracování administrátorského p ístupu do IS v souboru cong.php Soubory db.php a action-report.php mají jedno spole né. Ob obsahují t ídy, které jsou typu Singleton, coº je návrhový vzor, který omezuje instance t ídy na jeden objekt. To je uºite né, kdyº práv jeden objekt je pot eba ke koordinaci akcí nap í celým systémem.[25] U obou t íd se objekt vytvá í p es statickou metodu get_instance(). Ukázka této metody ze t ídy DB je níºe. T ída DB se pomocí n kolika funkcí stará o ve²kerou komunikaci s databází. Po áte ní spojení je tedy provedeno jiº ve funkci get_instance(), kde se p ipojuje k databázi pomocí

72 58 KAPITOLA 7. IMPLEMENTACE NOVÉHO SYSTÉMU funkce connect(), která se p ipojuje za pouºití p ihla²ovacích údaj denovaných v souboru cong.php. Hned po p ipojení se pomocí n kolika SQL dotaz nastavuje kódování pro spojení s databází, které se nastavuje na UTF-8. Dal²ími funkce t ída e²í dotazování se na databázi pomocí SQL, napl ování dat do polí, získání pouze konkrétního údaje nebo po tu získaných ádk. Tyto funkce v t²inou obalují nativní funkce PHP pro MySQL. Sou ástí souboru db.php je také t ída DBException, které je roz²í ením t ídy Exception a o²et uje výjimky, které se mohou vyskytnout p i spojení a dotazování na databázi. public static function get_instance() { if (self::$instance == null) { self::$instance = new DB(); self::$instance->connect(); } self::$instance->query("set character_set_client=utf8mb4"); self::$instance->query("set collation_connection=utf8mb4_unicode_ci"); self::$instance->query("set character_set_connection=utf8mb4"); self::$instance->query("set character_set_results=utf8mb4"); } return self::$instance; Ukázka kódu 2: Funkce pro vytvo ení objektu t ídy DB T ída ActionReport e²í upozorn ní a hlá²ky systému, které se objevují po provedení n jaké akce, nap. po p idání nebo smazání poloºky. T ída pracuje s globální prom nnou $_SESSION, coº je pole reprezentující session a do které t ída ukládá údaje o hlá²ce, aby se p enesly i p es p esm rování po úsp ²ném prob hnutí akce. T ída má t i funkce a to pro nastavení hlá²ky, které se provádí p i provád ní akce, pro získání hlá²ky p i následujícím výpise a funkci pro zji²t ní, jestli je n jaká hlá²ka nastavená nebo ne. U hlá²ek uvádí text hlá²ky, její úsp ²nost nebo neúsp ²nost, jestli jde o hlá²ku pro front-end nebo back-end a umíst ní hlá²ky na stránce. public function set($report, $success = false, $admin = true, $location = '') { if ($admin) { $prefix = 'admin_'; } } $_SESSION[$prefix.'action_report'] = $report; $_SESSION[$prefix.'action_report_success'] = $success; $_SESSION[$prefix.'action_report_location'] = $location; Ukázka kódu 3: Funkce pro nastavení hlá²ky

73 7.2. T ÍDY T ídy Jak jiº bylo zmín no, t ídy reprezentují entity systému a tím pádem souvisí i s tabulkami databáze, kam se ukládájí data k t mto entitám. Atributy t ídy kopírují sloupce tabulky a funkce t ídy pak obalují operace, které lze s daty v tabulce provád t. Jak bylo popsáno v návrhu, toto e²ení odpovídá návrhovému vzoru Active Record. P ítomny jsou funkce pro p idávání ádk do tabulky, pro aktualizaci dat, pro na ítání a samoz ejm i pro mazání. Funkce pro mazání u v t²iny t íd neobsahuje SQL dotaz obsahující formuli DELETE FROM, která ádky z tabulky doopravdy maºe, ale ádku se pouze nastaví hodnota u sloupce snazano na 1. Data, krom t ch, které reprezentují soubory a obrázky a zabírají místo na serveru, se pouze ozna ují jako smazaná, aby byla p ípadn snadno obnovitelná. To ale p iná²í problém p i na ítání dat z tabulky, protoºe je pot eba u SQL dotaz p edev²ím typu SELECT, u kterých musí být vºdy p ítomna podmínka WHERE smazano = 0. T ídy mají funkcí v t²inou daleko víc, které e²í vazby s dal²ími tabulkami. P íkladem m ºe být vazba tabulky clanky a obrazky, která je e²ena funkcí load_obrazky(), která získává obrázky p i azené lánku. T ída obecn vypadá tak, ºe na jejím za átku jsou deklarované její atributy jako privátní prom nné s výchozími hodnotami v t²inou 0 nebo null. Dal²í v ad je konstruktor, který má jeden tribut a to ID, které se váºe is ID ádku v tabulce v DB. Pak nap. $clanek = new Clanek(1) vytvo í instanci t ídy objekt, ve které jsou data ke lánku, které má v databázi v tabulce clanky ID rovno 1. Po konstruktoru následují ve t íd denice tzv. getter a setter, coº jsou funkce, slouºící pro získávání a nastavování hodnota atribut t ídy, které jsou denované jako privátní a p ímo s nimi m ºe pracovat pouze sama t ída. Tyto funkce pak umoº ují korigovat, co práci s hodnotami atribut t ídy. K t mto funkcím jsou i denované funkce, které umoº ují hromadné získávání a nastavování hodnot pomocí pole. Funkce get_vars_array() pro hromadné získání hodnota je velice jednoduchá, protoºe vyuºívá nativní PHP funkce get_object_vars(), která d lá p esn to, ºe atributy a hodnoty objektu p evede na pole a to tak, ºe názvy atribut jsou pak klí e pole. Druhá funkce pro nastavování hodnot set_vars_array() je trochu komplikovan j²í, protoºe se musí kaºdá hodnota nastavit zvlá² a vyuºít k tomu p íslu²ného setteru, aby byla daná hodnota nastavena ádným zp - sobem. public function set_vars_array($vars) { if (isset($vars['id'])) { $this->set_id($vars['id']); } if (isset($vars['nazev'])) { $this->set_nazev($vars['nazev']); } if (isset($vars['obrazek_id'])) { $this->set_obrazek_id($vars['obrazek_id']); } if (isset($vars['poradi'])) { $this->set_poradi($vars['poradi']); } if (isset($vars['zobrazovat'])) { $this->set_zobrazovat($vars['zobrazovat']); } if (isset($vars['vytvoreno'])) { $this->set_vytvoreno($vars['vytvoreno']); } if (isset($vars['smazano'])) { $this->set_smazano($vars['smazano']); } } public function get_vars_array() { return get_object_vars($this); } Ukázka kódu 4: Funkce pro hormadné nastavování a získání hodnot atribut t ídy pomocí pole

74 60 KAPITOLA 7. IMPLEMENTACE NOVÉHO SYSTÉMU Funkce pro na tení dat z ur itého ádku v tabulce v DB a nastavení instance má ve t ídách název load(). Tato funkce se vyuºívá v konstruktoru p i vytvo ení instance t ídy. Funkce má pouze jediný parametr a to $args, který se napl uje vícerozm rným polem. Toto e²ení jiº bylo zmín no a u funkcí t íd je hojn pouºíváno, protoºe mnoºství parametr je bývá velké. Ve funkci load() bývá pouze jedno podpole a to where, které denuje omezení pro výb r dat z DB a sestavuje tak SQL formuli WHERE. Pro nastavení hodnot se pak vyuºívá vý²e popsaná funkce set_vars_array(). public function load($args = null) { global $db; $types = ""; $params = array(); if (check_array($args['where'])) { foreach ($args['where'] as $key => $value) { switch ($key) { case 'id' : $where.= " AND clanky.id =?"; $types.= 'i'; $params[] = $value; break; case 'nazev' : $where.= " AND clanky.nazev "; if (empty($value)) { $where.= "IS NULL"; } else { $where.= "=?"; $types.= 's'; $params[] = $value; } break; case 'obrazek_id' : $where.= " AND clanky.obrazek_id "; if (empty($value)) { $where.= "IS NULL"; } else { $where.= "=?"; $types.= 'i'; $params[] = $value; } break; case 'poradi' : $where.= " AND clanky.poradi =?"; $types.= 'i'; $params[] = $value; break; case 'slozka_id' : $where.= " AND clanky.slozka_id =?"; $types.= 'i'; $params[] = $value; break; case 'zobrazovat' : $where.= " AND clanky.zobrazovat =?"; $types.= 'i'; $params[] = $value; break; case 'smazano' : $where.= " AND clanky.smazano =?"; $types.= 'i'; $params[] = $value; break; } } } if (empty($where)) { $where = "id =?"; $types = "i"; $params = $this->id; } else { $where = substr($where, 5); } $db->execute_query("select * FROM clanky WHERE ".$where, $types, $params); if ($db->num_rows()) { $row = $db->fetch_assoc(); $this->set_vars_array($row); return true; } else { return false; } } Ukázka kódu 5: Funkce pro získání dat instance t ídy z DB a nastavení hodnot atribut

75 7.2. T ÍDY 61 Funkce pro ukládání dat instance t ídy se provádí pomocí funkce save(), která podle atribut a jejich hodnot a typ t chto hodnot sestavuje SQL dotaz pro vloºení dat do DB. Vloºení m ºe být pomocí SQL p íkazu INSERT INTO nebo UPDATE podle toho, jestli ádek dané instance v DB jiº existuje nebo ne, coº se zji² uje podle toho, jestli je nastavena hodnota atribudu id. Pokud se instance ukládá poprve a t ída má atribut poradi, ur íse po áte ní hodnota pomocí funkce get_max_poradi(). Pokud se entita reprezentovaná t ídou adí do sloºek, kontroluje se, jestli se neukládá kam nemá a p íp. se ur uje nové po adí. public function save() { global $db; // objekt pro~praci s DB if (!$this->id) { // urceni poradi, pokud insert $this->poradi = self::get_max_poradi($this->slozka_id)+1; } else { // kontrola, jestli se clanek neuklada do jine slozky a~prip. urceni noveho poradi $query = "SELECT slozka_id FROM clanky WHERE id =?"; $type = "i"; $param = $this->id; $db->execute_query($query, $type, $param); if ($db->result()!= $this->slozka_id) { $this->poradi = self::get_max_poradi($this->slozka_id)+1; } } $query = ""; $types = ""; $params = array(); $query.= "id =?, "; $types.= "i"; $params[] = $this->id; if (!empty($this->nazev)) { $query.= "nazev =?, "; $types.= "s"; $params[] = $this->nazev; } else { $query.= "nazev = NULL, "; } if (!empty($this->obrazek_id)) { $query.= "obrazek_id =?, "; $types.= "i"; $params[] = $this->obrazek_id; } else { $query.= "obrazek_id = NULL, "; } $query.= "poradi =?, "; $types.= "i"; $params[] = $this->poradi; $query.= "slozka_id =?, "; $types.= "i"; $params[] = $this->slozka_id; $query.= "zobrazovat =?, "; $types.= "i"; $params[] = $this->zobrazovat; if (!empty($this->vytvoreno)) { $query.= "vytvoreno =?, "; $types.= "s"; $params[] = $this->vytvoreno; } else { $query.= "vytvoreno = NOW(), "; } $query.= "smazano =?, "; $types.= "i"; $params[] = $this->smazano; $query = substr($query, 0, -2); if ($this->id) { $types.= "i"; $params[] = $this->id; $db->execute_query("update clanky SET ".$query." WHERE id =?", $types, $params); } else { $db->execute_query("insert INTO clanky SET ".$query."", $types, $params); $this->id = $db->insert_id(); } } return true; Ukázka kódu 6: Funkce pro uloºení instance t ídy do DB

76 62 KAPITOLA 7. IMPLEMENTACE NOVÉHO SYSTÉMU Dal²í standardní funkcí t ídy je funkce delete(), která e²í mazání poloºky a ve které se v t²inou pomocí SQL p íkazu UPDATE nastavuje hodnota ve sloupci smazano na 1. Pokud tento sloupec neexistuje, maºe se ádek v tabulce úpln pomocí DELETE FROM. V takové p ípad je pak pot eba e²it je²t ru²ení existujících spojení na dal²í tabulky. Funkce check() slouºí ke kontrole dat p i p idávání nebo editace. Kontrolují se stanovené povinné údaje a p íp. správnost a smysluplnost t chto údaj. Klasickým p íkladem je kontrola ové adresy, jestli obsahuje a te ku p ed posledními n kolika písmeny. ƒastá je také kontrola, jestli se název poloºky uº neexistuje nap. ve sloºce, kam se poloºka ukládá. Funkce check() v p ípad nalezení n jaké chyby vrací pole s chybovými hlá²kami. Indexy tohoto pole jsou názvy atribut, u nichº byla chyba nalezena. Funkce se pouºívá v aplika ní logice p ed volání funkce save(). Hlá²ky v poli se pak vypisují u jednotlivých poloºek edita ního formulá e. public function check() { $form_errors = array(); if (empty($this->nazev)) { $form_errors['nazev'] = '<span class="form_error">udaj musi byt zadan.</span>'; } else if (!$this->check_nazev()) { $form_errors['nazev'] = '<span class="form_error">tento nazev jiz ve slozce existuje.</span>'; } if (empty($this-> )) { $form_errors[' '] = '<span class="form_error">udaj musi byt zadan.</span>'; } else if (!is_ ($this-> )) { $form_errors[' '] = '<span class="form_error"> musi mit spravny format.</span>'; } } return $form_errors; Ukázka kódu 7: Funkce pro zji²t ni chyb v zadaných údajích instance Ve t íd je dal²í b ºnou funkcí statická funkce pro hromadné na ítání poloºek, která vrací více rozm rné pole. Funkce se nazývá load_polozky(), kdy "polozky"ve v t²in p ípad nahrazuje název tabulky DB. Tato funkce je áste n podobná funkci load() a to p edev²ím kv li e²ení parametr a sestavování podmínek pro výb r poloºek. Protoºe ale jde seznam poloºek, e²í se zde i azení pomocí formule ORDER BY nebo omezení po tu poloºek p es formuli LIMIT. Podobn jako je funkce pro hromadné na ítání, existuje ve t íd i funkce pro hromadné mazání, která vyuºívá funkce delete(). Pokud se poloºky dají adit i do sloºek, existují i funkce pro hromadné kopírování a p esouvání. Funkce pro p esouvání je jednoduchá, u kaºdé poloºky se pouze zkontroluje, jestli se nep esouvá kam nemá a pak je uº jen zm ní reference na sloºku. U kopírování jde o trochu sloºit j²í proces, protoºe se musí e²it i kopírování vazeb a pokud se na poloºku váºe i soubor na serveru, musí se e²it i zkopírování tohoto souboru. Je-li umoºn no azení, existuje v t íd atribut poradi a p idávání, kopírování nebo p esouvání se musí e²it po adí vzhledem k ostatním poloºkám. Pokud se mezi poloºky n jakým

77 7.3. GENEROVÁNÍ STRÁNKY 63 zp sobem p idává nová, umis uje se automaticky na konec a k tomu slouºí statická funkce get_max_poradi(), která vrací maximální po adí n jakého celku (nap. sloºky). Dal²í standardní funkcí ve t íd j get_page_url(), která ur uje stránku seznamu poloºek, na které se poloºka vyskytuje, aby nap. po editaci, kdy systém sm ruje na seznam, nebyl uºivatel p esm rován na za átek, ale tam odkud do editace p e²el. Ve t íd je také b ºná funkce get_url(), která vrací nap. URL lánku nebo vozu. ƒasté jsou také funkce na formátování údaj jako jsou cena nebo datum. Cena se nap. rozd luje po t ech íslech a p idá se m na, datum se pak zformátuje pomocí funkce format_date(), ze souboru functions.php, ze systémového formátu rrrr-mm-dd do eského d.m.rrrr. 7.3 Generování stránky Generování b ºné stránky v systému je primárn ízeno souborem index.php, kterému se v URL parametru zadá poºadovaná stránka pro zobrazení. Na prvním míst se v souboru index.php na te soubor cong.php, ve kterém jsou deklarované ve²keré pot ebné prom nné a konstanty a na teny soubory pot ebné pro b h skriptu IS. Poté se zji² uje, jestli je zadán poºadavek na stránku, jinak se p esm rovává na úvodní stránku. Poºadavek je zadán, kontroluje se, jestli existují soubory s aplika ní a prezenta ní logikou pro poºadovanou stránku. Pokud ne, prob hne p esm rování na stránku o²et ující stavové HTTP kódy 4xx, v tomto p ípad 404 (Stránka nenalezena). Pokud soubory prezenta ní a aplika ní logiky existují naincludují se soubory hlavi ky, dané stránky a pati ky, které obsahují aplika ní logiku a poté ve stejném po adí soubory s prezenta ní logikou, ímº je sestavování skriptu pro generování stránky hotové. INDEX.PHP CONFIG.PHP HEADER.PHP HEADER.HTML.PHP DB.PHP FUNCTIONS.PHP - PAGE -.PHP - PAGE -.HTML.PHP ACTION-REPORT.PHP FOOTER.PHP FOOTER.HTML.PHP - CLASSES -.PHP Obrázek 7.1: Znázorn ní posloupnosti na ítání soubor systému (shora dol, zleva doprava)

78 64 KAPITOLA 7. IMPLEMENTACE NOVÉHO SYSTÉMU Soubor index.php o²et uje a zpracovává i jiné systémové záleºitosti a události. Kontroluje, jestli je v bec n jaký uºivatel p ihlá²ený a má tedy p ístup k n jaké stránce. Pokud ne, p esm ruje ho na p ihlá²ení. Stejn tak e²í, jestli k poºadované stránce má uºivatel v bec práva pro p ístup. V tomto souboru se také o²et uje zm na prodejny prodejce. Také se e²í otevírání stránek v pop-up okn nebo v modulu prettyphoto, ve kterých by se nem la objevovat hlavi ka stránky. Soubor s aplika ní logikou stránky je rozd len na dv ásti. Jedna se stará o zpracování akcí jako je odeslání formulá pro p idání nebo editaci poloºky, poºadavek na smazání nebo hromadné operace a jiné dal²í operace, které jsou s poloºkami moºné. Druhá ást e²í na ítání a zpracování dat výpis do stránek, p ipravuje tedy data pro prezenta ní vrstvu. V prezenta ní vrstv se uº jen podle parametr v URL ur uje, jaký HTML kód se má vypsat. Soubory hlavi ky a pati ky jsou podobné, akorát aplika ní soubor není nijak rozd len na dv ásti, protoºe se v n m ºádné akce nezpracovávají. Uºivatelská práva jsou e²ena tak, ºe kaºdý administrátor má denované jaké stránky a jaké akce m ºe na stránce provád t. Toto se kontroluje jak v aplika ní vrstv, kde se poºadováná stránka a akce porovnávají s právy uºivatele, tak v prezenta ní, kde se bu pomocí PHP skrývají poloºky menu a dal²í ovládací prvky odkazující na dané stránky nebo se akce zakazují pomocí jquery. To je e²eno tím zp sobem, ºe je odkaz bu odebrán nebo deaktivován s oznámením, ºe uºivatel nemá pro daný odkaz oprávn ní. jquery porovnává práva uºivatele pomocí AJAX. public static function check_prava_administratora($stranka, $akce) { // situace, kdy ma uzivatel pristup vzdy if (ADMIN_ROLE == 1 $stranka == 'uvod' $stranka == 'http-chyby' empty($stranka)) { return true; } // nacteni platnych prav administratora pro~danou stranku a~akci $args['where']['stranka_or_all'] = $stranka; $args['where']['akce_or_all'] = ($akce? $akce : '#'); // # znamena uvod stranky (napr. vypis polozek) $args['where']['administrator_id'] = ADMIN_ID; $args['where']['aktivni'] = 1; $args['where']['smazano'] = 0; $prava = PravoAdministratora::load_prava($args); unset($args); // pokud se neco nacetlo, administrator prava ma, jinak ne if (check_array($prava)) { return true; } else { return false; } } Ukázka kódu 8: Funkce t ídy Administrátor pro zji²t ní práv uºivatele pro konkrétní stránku a akci

79 7.4. POUšITÍ MODUL A SLUšEB Pouºití modul a sluºeb jquery V systému je za pouºití jquery a Javascriptu e²eno mnoho v cí jako je skrývání poloºek, úprava vlastností HTML element, potvrzování zdánliv nevratných operací a mnoho dal²ích v cí, které by jinak ani e²it ne²ly nebo by e²ení bylo komplikované. P íkladem m ºe být upozorn ní uºivatele, kdyº chce opustit stránku s formulá em, do kterého jiº doplnil nebo v n m pozm nil data. Kód toho e²ení je ukázán níºe. Zajímavostí je e²ení pro CKEditor, do kterého se musel nainstalovat modul, aby se dala zm na dat v n m zjistit. window.formchangesmade = false; $(window).load(function(e) { if (window.top.length < 2) { jquery("form.check-changes input, form.check-changes textarea").on('keyup', function(e) { window.formchangesmade = true; }); jquery("form.check-changes input, form.check-changes textarea").on('mouseup', function(e) { window.formchangesmade = true; }); jquery("form.check-changes select").on('change', function(e) { window.formchangesmade = true; }); for (var i~in CKEDITOR.instances) { CKEDITOR.instances[i].on('change', function(e) { window.formchangesmade = true; }); } // pokud se klika na tlaticko ulozit, hlaska se neukazuje ani kdyz byly provedeny zmeny jquery("form.check-changes input[type=submit]").on('click', function(e) { window.formchangesmade = false; }); } }); jquery(window).bind('beforeunload', function (e) { if (window.formchangesmade) { e.preventdefault(); } }); var message = 'Vami zadana data mohou byt ztracena.'; return message; e.cancelbubble = true; e.returnvalue = message; //e.stoppropagation works in Firefox. if (e.stoppropagation) { e.stoppropagation(); } Ukázka kódu 9: Funkce pro zji²t ni chyb v zadaných údajích instance

80 66 KAPITOLA 7. IMPLEMENTACE NOVÉHO SYSTÉMU Bootstrap Pomocí modulu Bootstrap je e²ené celé uºivatelské rozhraní systému. Modul spolupracuje také s jquery a stejn jednodu²e je i nasaditelný pouze p idáním odkaz na p íslu²né soubory do HTML hlavi ky stránky. Vzhled nadenovaných prvk není problém upravit a p izp sobit vlastními styly. Obrázek 7.2: Ukázka uºivatelského rozhraní systému e²eného pomocí Bootstrapu CKEditor CKEditor je v systému pouºit pro formátování text lánk. Pomocí kongura ního souboru byl nadenován panel nástroj, který pokrývá ve²keré pot eby uºivatel. Také bylo provedeno propojení s databází obrázk a soubor, aby bylo moºné vkládat obrázky a odkazy na soubory, které jiº v systému existují a nebo je pohodln nahrát zp sobem, na který jsou uºivatelé zvyklí. U odkaz byly také p idány moºnosti odkazovat do modulu prettyphoto prettyphoto Modul prettyphoto je nejen vyuºit pro prohlíºení obrázk, ale také pro otevírání r zných stránek. Vyuºívá se nap. p i p i azování obrázk, kdy se v tomto modulu otev e stránka obrázky v reºimu, kdy je moºné vybrat libovolné obrázky a hromadn je p i adit t eba vozu nebo lánku. Jindy se prettyphoto vyuºívá pro prohlíºení nebo editaci poloºek, které jsou v seznamu jiných poloºek (nap. prodejna v seznamu objednávek, viz obrázek níºe) a normální odkaz by byl nesystémový kv li vracení se na daný výpis poloºek. Takto se otev e edita ní formulá nad seznamem, poloºka se upraví a po zav ení prettyphoto se seznam poloºek obnoví, aby se projevily p ípadné zm ny, které editace zp sobila.

81 7.4. POUšITÍ MODUL A SLUšEB 67 Obrázek 7.3: Ukázka edita ního formulá e na teného vprettyphoto mpdf T ída mpdf slouºí v systému k vytvá ení PDF faktur, smluv a protokol, kdy se tyto PDF ukládají na server. Generování PDF zaji² uje v t ídách reprezentujících dané dokumenty funkce create_pdf(). V této funkci se na ítají a zpracovávají údaje pot ebné pro dokument se sestavuje se HTML kód, ze kterého je pak PDF vytvo eno. require_once(modules_path.'mpdf/mpdf.php'); // nacteni souboru se tridou mpdf $mpdf = new mpdf('utf-8'); $mpdf->setfooter('cislo faktury: '.$this->cislo.' Stranka: {PAGENO}/{nb}'); // nastaveni paticky PDF $mpdf->writehtml($html); // vlozeni HTML kodu, ze ktereho je vygenerovan obsah PDF $mpdf->output(documents_path.'invoices/faktura-'.$this->cislo.'.pdf', 'F'); // ulozeni souboru Ukázka kódu 10: Kód pro vytvo ení PDF z HTML pomocí t ídy mpdf PHPMailer V souboru functions.php je denována funkce send_mail() ur ená k odesílání mail za jakýmkoliv u elem. Ve funkci se pracuje s mnoha parametry a v budoucnu mohou p ibýt dal²í, takºe má op t jediný parametr $args, který ve²keré parametry sdruºuje v poli. Hlavní parametry jsou odesílatele a p íjmence, p edm t a text mailu. Ukázka toho, jak se ve funkci send_mail() pracuje a vyuºívá t ídy PHPMailer je níºe.

Specifikace systému ESHOP

Specifikace systému ESHOP Nabídka: Specifikace systému ESHOP březen 2009 Obsah 1 Strana zákazníka 1 1.1 Nabídka produkt, strom kategorií..................... 1 1.2 Objednávka a ko²ík.............................. 1 1.3 Registrace

Více

BOZP - akcepta ní testy

BOZP - akcepta ní testy BOZP - akcepta ní testy Kristýna Streitová Zadavatel: Ing. Ji í Chludil 13. prosince 2011 Obsah 1 Úvod 2 1.1 Popis test....................................... 2 2 Testy 3 2.1 ID - 1 P ihlá²ení do systému.............................

Více

Vektory. Vektorové veli iny

Vektory. Vektorové veli iny Vektor je veli ina, která má jak velikost tak i sm r. Ob tyto vlastnosti musí být uvedeny, aby byl vektor stanoven úpln. V této ásti je návod, jak vektory zapsat, jak je s ítat a od ítat a jak je pouºívat

Více

Uºivatelská p íru ka Octopus

Uºivatelská p íru ka Octopus Uºivatelská p íru ka Octopus Jan Bojko 11. prosince 2014 Abstrakt Uºivatelská p íru ka k aplikaci Octopus. Obsah 1 Úvod 2 2 P ihlá²ení 2 3 Naviga ní menu 2 4 Práce s tabulkou 3 5 Editace 6 5.1 Nový záznam.............................

Více

29 Evidence smluv. Popis modulu. Záložka Evidence smluv

29 Evidence smluv. Popis modulu. Záložka Evidence smluv 29 Evidence smluv Uživatelský modul Evidence smluv slouží ke správě a evidenci smluv organizace s možností připojení vlastní smlouvy v elektronické podobě včetně přidělování závazků ze smluv jednotlivým

Více

Novinky verzí SKLADNÍK 4.24 a 4.25

Novinky verzí SKLADNÍK 4.24 a 4.25 Novinky verzí SKLADNÍK 4.24 a 4.25 Zakázky standardní přehled 1. Možnosti výběru 2. Zobrazení, funkce Zakázky přehled prací 1. Možnosti výběru 2. Mistři podle skupin 3. Tisk sumářů a skupin Zakázky ostatní

Více

INTERNETOVÝ TRH S POHLEDÁVKAMI. Uživatelská příručka

INTERNETOVÝ TRH S POHLEDÁVKAMI. Uživatelská příručka INTERNETOVÝ TRH S POHLEDÁVKAMI Uživatelská příručka 1. března 2013 Obsah Registrace... 3 Registrace fyzické osoby... 3 Registrace právnické osoby... 6 Uživatelské role v systému... 8 Přihlášení do systému...

Více

Termíny zkoušek Komise Komise. subkomise 1 (obhaj.) :30 B subkomise 2 (obhaj.) :30 B8 120

Termíny zkoušek Komise Komise. subkomise 1 (obhaj.) :30 B subkomise 2 (obhaj.) :30 B8 120 Základní informace o struktu e dat: Komise (nadkomise) obsahují leny schválené VR (po jejich identifikaci v SIS, p íp. dopln ní budou obsahovat všechny schválené leny, po novém za azení se vyplní datum

Více

Manuál Kentico CMSDesk pro KDU-ČSL

Manuál Kentico CMSDesk pro KDU-ČSL Manuál Kentico CMSDesk pro KDU-ČSL 2011 KDU-ČSL Obsah 1 Obecně... 3 1.1 Přihlašování... 3 1.2 Uživatelské prostředí... 4 2 Stránky... 4 2.1 Vytvoření nové stránky... 4 2.1.1 Texty... 7 2.1.2 Styly textu...

Více

Integrování jako opak derivování

Integrování jako opak derivování Integrování jako opak derivování V tomto dokumentu budete seznámeni s derivováním b ºných funkcí a budete mít moºnost vyzkou²et mnoho zp sob derivace. Jedním z nich je proces derivování v opa ném po adí.

Více

Programový komplet pro evidence provozu jídelny v. 2.55. modul Sklad. 2001 Sviták Bechyně Ladislav Sviták hotline: 608/253 642

Programový komplet pro evidence provozu jídelny v. 2.55. modul Sklad. 2001 Sviták Bechyně Ladislav Sviták hotline: 608/253 642 Programový komplet pro evidence provozu jídelny v. 2.55 modul Sklad 2001 Sviták Bechyně Ladislav Sviták hotline: 608/253 642 Obsah 1 Programový komplet pro evidenci provozu jídelny modul SKLAD...3 1.1

Více

Limity funkcí v nevlastních bodech. Obsah

Limity funkcí v nevlastních bodech. Obsah Limity funkcí v nevlastních bodech V tomto letáku si vysv tlíme, co znamená, kdyº funkce mí í do nekone na, mínus nekone na nebo se blíºí ke konkrétnímu reálnému íslu, zatímco x jde do nekone na nebo mínus

Více

Integrovaný Ekonomický Systém Zakázkový list - IES WIN 2006

Integrovaný Ekonomický Systém Zakázkový list - IES WIN 2006 Úvod...2 1. Zakázkový list...2 1.1. Identifikační údaje...2 1.2. Položková část...2 1.3. Rezervace (materiálu, resp. zboží)...3 1.4. Materiálové náklady (resp. Výdej nebo Prodej ze skladu)...3 1.5. Běžné

Více

VEŘEJNÁ DRAŽEBNÍ VYHLÁŠKA (opakované dražební jednání)

VEŘEJNÁ DRAŽEBNÍ VYHLÁŠKA (opakované dražební jednání) Číslo jednací: 085 EX 5412/11-230 U s n e s e n í o nařízení opakovaného dražebního jednání - elektronická dražba Soudní exekutor JUDr. Milan Suchánek, Exekutorský úřad Praha 9 se sídlem Pod Pekárnami

Více

Skalární sou in. Úvod. Denice skalárního sou inu

Skalární sou in. Úvod. Denice skalárního sou inu Skalární sou in Jedním ze zp sob, jak m ºeme dva vektory kombinovat, je skalární sou in. Výsledkem skalárního sou inu dvou vektor, jak jiº název napovídá, je skalár. V tomto letáku se nau íte, jak vypo

Více

DeepBurner (testování UI)

DeepBurner (testování UI) ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Semestrální práce DeepBurner (testování UI) Blaºej, Friebel, Olexová, Volf P edm t: Testování uºivatelských rozhraní Obor: Softwarové inºenýrství

Více

městské části Praha 3 pro rok 2016 připravila

městské části Praha 3 pro rok 2016 připravila městské části Praha 3 pro rok 2016 připravila městské části Praha 3 pro rok 2016 - Návrh projektu k 3. 2. 2016 Obsah Obsah... 2 1. KONTEXT... 3 2. CÍLE A VÝSTUPY PROJEKTU... 4 3. POSTUP PŘÍPRAVY PARTICIPAČNÍHO

Více

Binární operace. Úvod. Pomocný text

Binární operace. Úvod. Pomocný text Pomocný text Binární operace Úvod Milí e²itelé, binární operace je pom rn abstraktní téma, a tak bude ob as pot eba odprostit se od konkrétních p íklad a podívat se na v c s ur itým nadhledem. Nicmén e²ení

Více

Návod k použití aplikace MARKETINGOVÉ PRŮZKUMY.CZ

Návod k použití aplikace MARKETINGOVÉ PRŮZKUMY.CZ www.marketingovepruzkumy.cz Návod k použití aplikace MARKETINGOVÉ PRŮZKUMY.CZ 28.4.2011 Miloš Voborník Obsah 1. Uživatelská příručka... 1 1.1. Běžný uživatel... 1 1.1.1. Celkové rozvržení, úvodní strana...

Více

SPECIFIKACE ZADÁNÍ. 1. Identifikační údaje zadavatele. 2. Předmět veřejné zakázky malého rozsahu. 1.1. Základní údaje. 1.2. Oprávněné osoby zadavatele

SPECIFIKACE ZADÁNÍ. 1. Identifikační údaje zadavatele. 2. Předmět veřejné zakázky malého rozsahu. 1.1. Základní údaje. 1.2. Oprávněné osoby zadavatele SPECIFIKACE ZADÁNÍ veřejné zakázky malého rozsahu Mobilní telekomunikační služby (dále jen zakázka ) V souladu s ustanovením 18 odst. 5 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších

Více

Vodafone promo kit uživatelský manuál http://promo.vodafone.cz/ Uživatelský manuál pro aplikaci. Vodafone promo kit. Verze dokumentu: 2.

Vodafone promo kit uživatelský manuál http://promo.vodafone.cz/ Uživatelský manuál pro aplikaci. Vodafone promo kit. Verze dokumentu: 2. Uživatelský manuál pro aplikaci Vodafone promo kit Verze dokumentu: 2.1 Vytvořeno: V Praze dne 8. 9. 2011 1 Obsah Vodafone promo kit uživatelský manuál Webové rozhraní aplikace Vodafone promo kit... 4

Více

Jak vytvářet síť prostřednictvím OpenAdvert.com. 1. Jděte na adresu OpenAdvert.com

Jak vytvářet síť prostřednictvím OpenAdvert.com. 1. Jděte na adresu OpenAdvert.com Jak vytvářet síť prostřednictvím OpenAdvert.com 1. Jděte na adresu OpenAdvert.com 2. Vyberte jazykovou verzi projektu (během nejbližší doby bude spuštěno nejméně 5 dalších jazykových verzí. 3. Klikněte

Více

Návod k používání registračního systému ČSLH www.hokejovaregistrace.cz

Návod k používání registračního systému ČSLH www.hokejovaregistrace.cz Návod k používání registračního systému ČSLH www.hokejovaregistrace.cz Osnova Přihlášení do systému Základní obrazovka Správa hráčů Přihlášky hráčů k registraci Žádosti o prodloužení registrace Žádosti

Více

Ovoce do škol Příručka pro žadatele

Ovoce do škol Příručka pro žadatele Ve smečkách 33, 110 00 Praha 1 tel.: 222 871 556 fax: 296 326 111 e-mail: info@szif.cz Ovoce do škol Příručka pro žadatele OBSAH 1. Základní informace 2. Schválení pro dodávání produktů 3. Stanovení limitu

Více

Uživatelská příručka Rejstřík státních zaměstnanců

Uživatelská příručka Rejstřík státních zaměstnanců Informační systém o státní službě (ISoSS) Název dokumentu: Verze dokumentu: 1.2 (z 9. 12. 2015) Strana: 1/35 Historie dokumentu Historie revizí Číslo revize Datum revize Popis revize Změny označeny 1.0

Více

ízení Tvorba kritéria 2. prosince 2014

ízení Tvorba kritéria 2. prosince 2014 ízení. prosince 014 Spousta lidí má pocit, ºe by m la n co ídit. A n kdy to bývá pravda. Kdyº uº nás my²lenky na ízení napadají, m li bychom si poloºit následující t i otázky: ídit? Obrovskou zku²eností

Více

ZADÁVACÍ DOKUMENTACE

ZADÁVACÍ DOKUMENTACE ZADÁVACÍ DOKUMENTACE ve smyslu 44 zákona.137/2006 Sb., o ve ejných zakázkách, ve zn ní pozd jších p edpis (dále jen zákon ) Název ve ejné zakázky Rozší ení personálního ešení MMR Zadavatel ve ejné zakázky:

Více

T i hlavní v ty pravd podobnosti

T i hlavní v ty pravd podobnosti T i hlavní v ty pravd podobnosti 15. kv tna 2015 První p íklad P edstavme si, ºe máme atomy typu A, které se samovolným radioaktivním rozpadem rozpadají na atomy typu B. Pr m rná doba rozpadu je 3 hodiny.

Více

Marketing. Modul 7 Internetový marketing

Marketing. Modul 7 Internetový marketing Marketing Modul 7 Internetový marketing Výukový materiál vzdělávacích kurzů v rámci projektu Zvýšení adaptability zaměstnanců organizací působících v sekci kultura Tento materiál je spolufinancován z Evropského

Více

Programování se seznamy v Imagine

Programování se seznamy v Imagine Programování se seznamy v Imagine Jiří Komínek PaedDr. Jiří Vaníček Ph.D. Školní rok: 2008-09 Abstrakt V mé diplomové práci se zabývám programováním se seznamy v prostředí Imagine Logo. Práce by měla pomoci

Více

3 nadbytek. 4 bez starostí

3 nadbytek. 4 bez starostí Metody měření spokojenosti zákazníka Postupy měření spokojenosti zákazníků jsou nejefektivnější činnosti při naplňování principu tzv. zpětné vazby. Tento princip patří k základním principům jakéhokoliv

Více

t a k t o : www.e-drazby.cz Uvedené nemovité věci tvoří jeden funkční celek a jako jeden celek budou draženy.

t a k t o : www.e-drazby.cz Uvedené nemovité věci tvoří jeden funkční celek a jako jeden celek budou draženy. Číslo jednací: 156 EX 4683/13-54 Uvádějte při veškeré korespondenci Značka oprávněného: Ederová - 170495/1 U s n e s e n í Soudní exekutor JUDr. Milan Makarius Exekutorského úřadu Praha-západ, se sídlem

Více

Vektor náhodných veli in - práce s více prom nnými

Vektor náhodných veli in - práce s více prom nnými Vektor náhodných veli in - práce s více prom nnými 12. kv tna 2015 N kdy k popisu n jaké situace pot ebujeme více neº jednu náhodnou veli inu. Nap. v k, hmotnost, vý²ku. Mezi t mito veli inami mohou být

Více

Pomocník diabetika Uživatelská příručka

Pomocník diabetika Uživatelská příručka Pomocník diabetika Uživatelská příručka Úvod Pomocník diabetika je označení pro webovou aplikaci určenou pro diabetiky zejména prvního typu. Webová aplikace je taková aplikace, se kterou můžete pracovat

Více

Poukázky v obálkách. MOJESODEXO.CZ - Poukázky v obálkách Uživatelská příručka MOJESODEXO.CZ. Uživatelská příručka. Strana 1 / 1. Verze aplikace: 1.4.

Poukázky v obálkách. MOJESODEXO.CZ - Poukázky v obálkách Uživatelská příručka MOJESODEXO.CZ. Uživatelská příručka. Strana 1 / 1. Verze aplikace: 1.4. MOJESODEXO.CZ Poukázky v obálkách Verze aplikace: 1.4.0 Aktualizováno: 22. 9. 2014 17:44 Strana 1 / 1 OBSAH DOKUMENTU 1. ÚVOD... 2 1.1. CO JSOU TO POUKÁZKY V OBÁLKÁCH?... 2 1.2. JAKÉ POUKÁZKY MOHOU BÝT

Více

Testovací aplikace Matematika není věda

Testovací aplikace Matematika není věda Testovací aplikace Matematika není věda Příručka k http://matematika.komenacek.cz/ Příručka k portálu http://matematika.komenacek.cz/ 2 Uživatelská příručka k portálu 202 BrusTech s.r.o. Všechna práva

Více

Výstup. Registrační číslo projektu CZ.01.07/1.1.01/01.0004. PaedDr. Vladimír Hůlka, PaedDr. Zdenka Kınigsmarková

Výstup. Registrační číslo projektu CZ.01.07/1.1.01/01.0004. PaedDr. Vladimír Hůlka, PaedDr. Zdenka Kınigsmarková Projekt: Přispějme k ještě kvalitnější a modernější výuce na ZŠ Chotěboř Buttulova Registrační číslo projektu CZ.01.07/1.1.01/01.0004 Tento projekt je spolufinancován Evropským sociálním fondem a státním

Více

IP kamerový systém Catr - uºivatelský návod k obsluze

IP kamerový systém Catr - uºivatelský návod k obsluze IP kamerový systém Catr - uºivatelský návod k obsluze Obsah P ipoj se k nám! Úvod 3 P ístup do systému 3 Po íta s Windows 3 Prvotní instalace 3 Ovládání kamerového systému na po íta i 5 šivý náhled...................................................

Více

Specialista pro vytvá řenívztahů Specialist for Creating Relations

Specialista pro vytvá řenívztahů Specialist for Creating Relations Specialista pro vytvá řenívztahů Specialist for Creating Relations Roman KOZEL If universities want to succeed on the market, they have to deal with higher assertivity their graduates. They need a specialist,

Více

A. PODÍL JEDNOTLIVÝCH DRUHŮ DOPRAVY NA DĚLBĚ PŘEPRAVNÍ PRÁCE A VLIV DÉLKY VYKONANÉ CESTY NA POUŽITÍ DOPRAVNÍHO PROSTŘEDKU

A. PODÍL JEDNOTLIVÝCH DRUHŮ DOPRAVY NA DĚLBĚ PŘEPRAVNÍ PRÁCE A VLIV DÉLKY VYKONANÉ CESTY NA POUŽITÍ DOPRAVNÍHO PROSTŘEDKU A. PODÍL JEDNOTLIVÝCH DRUHŮ DOPRAVY NA DĚLBĚ PŘEPRAVNÍ PRÁCE A VLIV DÉLKY VYKONANÉ CESTY NA POUŽITÍ DOPRAVNÍHO PROSTŘEDKU Ing. Jiří Čarský, Ph.D. (Duben 2007) Komplexní přehled o podílu jednotlivých druhů

Více

Tisíce uživatelů v bance pracují lépe díky využití okamžitých informací o stavu kritických systémů

Tisíce uživatelů v bance pracují lépe díky využití okamžitých informací o stavu kritických systémů Tisíce uživatelů v bance pracují lépe díky využití okamžitých informací o stavu kritických systémů Cleverlance dodala Komerční bance systém, který za pomoci nejmodernějších technologií proaktivně pomáhá

Více

Android Elizabeth. Verze: 1.3

Android Elizabeth. Verze: 1.3 Android Elizabeth Program pro měření mezičasů na zařízeních s OS Android Verze: 1.3 Naposledy upraveno: 12. března 2014 alesrazym.cz Aleš Razým fb.com/androidelizabeth Historie verzí Verze Datum Popis

Více

D R A Ž E B N Í V Y H L Á Š K U

D R A Ž E B N Í V Y H L Á Š K U JUDr. Jiří Bulvas, soudní exekutor Exekutorský úřad Praha 1 sídlo: Jablonecká 322, 190 00 Praha 9 e-mail: podatelna@exekutorpraha1.cz tel.: 286 028 058 web: www.exekutorpraha1.cz č. ú. pro platby povinných

Více

P íklad 1 (Náhodná veli ina)

P íklad 1 (Náhodná veli ina) P íklad 1 (Náhodná veli ina) Uvaºujeme experiment: házení mincí. Výsledkem pokusu je rub nebo líc, ºe padne hrana neuvaºujeme. Pokud hovo íme o náhodné veli in, musíme p epsat výsledky pokusu do mnoºiny

Více

ODPOVĚDI KOMISE NA VÝROČNÍ ZPRÁVU ÚČETNÍHO DVORA ZA ROK 2011 KAPITOLA 6 ZAMĚSTNANOST A SOCIÁLNÍ VĚCI

ODPOVĚDI KOMISE NA VÝROČNÍ ZPRÁVU ÚČETNÍHO DVORA ZA ROK 2011 KAPITOLA 6 ZAMĚSTNANOST A SOCIÁLNÍ VĚCI EVROPSKÁ KOMISE V Bruselu dne 30.8.2012 COM(2012) 479 final ODPOVĚDI KOMISE NA VÝROČNÍ ZPRÁVU ÚČETNÍHO DVORA ZA ROK 2011 KAPITOLA 6 ZAMĚSTNANOST A SOCIÁLNÍ VĚCI CS CS ÚVOD ODPOVĚDI KOMISE NA VÝROČNÍ ZPRÁVU

Více

U s n e s e n í o nařízení dražebního jednání - elektronická dražba VEŘEJNÁ DRAŽEBNÍ VYHLÁŠKA

U s n e s e n í o nařízení dražebního jednání - elektronická dražba VEŘEJNÁ DRAŽEBNÍ VYHLÁŠKA U s n e s e n í o nařízení dražebního jednání - elektronická dražba Číslo jednací: 085 EX 8767/12-136 Soudní exekutor JUDr. Milan Suchánek, Exekutorský úřad Praha 9 se sídlem Pod Pekárnami 245/10, 190

Více

Prohlíºe médií [NA-PROHLIZEC] Mács Daniel (macsdani) 16. íjna 2011

Prohlíºe médií [NA-PROHLIZEC] Mács Daniel (macsdani) 16. íjna 2011 Prohlíºe médií [NA-PROHLIZEC] Mács Daniel (macsdani) 16. íjna 2011 1 Úvod Cílem této práce, tvo ené v rámci p edm tu Návrh uºivatelského rozhraní, je navrhnout uºivatelské rozhraní set-top boxu (zobrazené

Více

VÝSTUPY Z DOTAZNÍKU SPOKOJENOSTI. Setkání zpracovatelů projektů v rámci programu KLASTRY CzechInvest, Praha, Štěpánská 15 29.

VÝSTUPY Z DOTAZNÍKU SPOKOJENOSTI. Setkání zpracovatelů projektů v rámci programu KLASTRY CzechInvest, Praha, Štěpánská 15 29. VÝSTUPY Z DOTAZNÍKU SPOKOJENOSTI Setkání zpracovatelů projektů v rámci programu KLASTRY CzechInvest, Praha, Štěpánská 15 29. června 2006 Dotazník vyplnilo celkem 13 ze 14 účastníků setkání. Výsledné bodové

Více

Usnesení o nařízení dražebního roku (dražební vyhláška) elektronická dražba

Usnesení o nařízení dražebního roku (dražební vyhláška) elektronická dražba EXEKUTORSKÝ ÚŘAD JESENÍK, Mgr. Alan Havlice, soudní exekutor Otakara Březiny 229/5, 790 01 Jeseník; tel: 584 411 112, 581 112 200; fax: 584 450 309; IČ: 03372537 DIČ: CZ6608111400; e-mail: info@exekutor-jesenik.cz,

Více

Zásady a podmínky pro poskytování dotací na program Podpora implementace Evropské charty regionálních či menšinových jazyků 2011

Zásady a podmínky pro poskytování dotací na program Podpora implementace Evropské charty regionálních či menšinových jazyků 2011 Zásady a podmínky pro poskytování dotací na program Podpora implementace Evropské charty regionálních či menšinových jazyků 2011 Článek 1 Úvodní ustanovení 1. Zásady a podmínky pro poskytování dotací na

Více

U S N E S E N Í. D r a ž e b n í v y h l á š k u o provedení elektronické dražby nemovité věci

U S N E S E N Í. D r a ž e b n í v y h l á š k u o provedení elektronické dražby nemovité věci 0998.0240283669 Exekutorský úřad Přerov soudní exekutor JUDr. Lukáš Jícha 750 02 Přerov, Komenského 38 tel: 588 003 999 fax: 588 003 990 e-mail: urad@eujicha.cz internet: www.eujicha.cz ID datové schránky:

Více

usnesení o nařízení elektronického dražebního jednání (dražební vyhláška)

usnesení o nařízení elektronického dražebního jednání (dražební vyhláška) Exekutorský úřad Chomutov Mgr. Jan Peroutka,soudní exekutor Revoluční 48, 430 01 Chomutov, IČ: 66225108, DIČ: CZ6805280988 Tel/Fax: 474 335 579, e-mail: info@exekucecv.cz, mobil : 775081383, DS: n7tg8u3

Více

účetních informací státu při přenosu účetního záznamu,

účetních informací státu při přenosu účetního záznamu, Strana 6230 Sbírka zákonů č. 383 / 2009 Částka 124 383 VYHLÁŠKA ze dne 27. října 2009 o účetních záznamech v technické formě vybraných účetních jednotek a jejich předávání do centrálního systému účetních

Více

HW vybavení nov vybudovaného datového centra SSZ (Zvýšení kapacity Datového úložišt )

HW vybavení nov vybudovaného datového centra SSZ (Zvýšení kapacity Datového úložišt ) OD VODN NÍ VE EJNÉ ZAKÁZKY HW vybavení nov vybudovaného datového centra SSZ (Zvýšení kapacity Datového úložišt ) Od vodn ní ve ejné zakázky pro ú ely p edb žného oznámení Od vodn ní ú elnosti ve ejné zakázky

Více

V této části manuálu bude popsán postup jak vytvářet a modifikovat stránky v publikačním systému Moris a jak plně využít všech možností systému.

V této části manuálu bude popsán postup jak vytvářet a modifikovat stránky v publikačním systému Moris a jak plně využít všech možností systému. V této části manuálu bude popsán postup jak vytvářet a modifikovat stránky v publikačním systému Moris a jak plně využít všech možností systému. MENU Tvorba základního menu Ikona Menu umožňuje vytvořit

Více

Městská část Praha - Ďáblice Rada městské části. USNESENÍ č. 228/15/RMČ k uzavření smlouvy na administraci veřejné zakázky Dostavba a přístavba ZŠ

Městská část Praha - Ďáblice Rada městské části. USNESENÍ č. 228/15/RMČ k uzavření smlouvy na administraci veřejné zakázky Dostavba a přístavba ZŠ Městská část Praha - Ďáblice Rada městské části 28. zasedání dne 30. 11. 2015 USNESENÍ č. 228/15/RMČ k uzavření smlouvy na administraci veřejné zakázky Dostavba a přístavba ZŠ RMČ po projednání: I. souhlasí

Více

The University of Plymouth

The University of Plymouth The University of Plymouth Jmenuji se Lukáš Widomski, je mi 19 let a tento rok jsem udělal maturitu na SPŠ EI Kratochvílova 7. Označil bych se jako průměrný, cílevědomý student, který vzal osud do svých

Více

Usnesení o nařízení dražební jednání elektronická dražba

Usnesení o nařízení dražební jednání elektronická dražba Exekutorský úřad České Budějovice soudní exekutor JUDr. Milan Bronec Šumavská ul. 17, 370 01 České Budějovice, tel: 387436038, e-mail: urad@exekutor-cb.cz www.exekutor-cb.cz, datová schránka: 64ug78z č.j.

Více

WEBDISPEČINK NA MOBILNÍCH ZAŘÍZENÍCH PŘÍRUČKA PRO WD MOBILE

WEBDISPEČINK NA MOBILNÍCH ZAŘÍZENÍCH PŘÍRUČKA PRO WD MOBILE WEBDISPEČINK NA MOBILNÍCH ZAŘÍZENÍCH PŘÍRUČKA PRO WD MOBILE Úvodem WD je mobilní verze klasického WEBDISPEČINKU, která je určena pro chytré telefony a tablety. Je k dispozici pro platformy ios a Android,

Více

ČÁST PÁTÁ POZEMKY V KATASTRU NEMOVITOSTÍ

ČÁST PÁTÁ POZEMKY V KATASTRU NEMOVITOSTÍ ČÁST PÁTÁ POZEMKY V KATASTRU NEMOVITOSTÍ Pozemkem se podle 2 písm. a) katastrálního zákona rozumí část zemského povrchu, a to část taková, která je od sousedních částí zemského povrchu (sousedních pozemků)

Více

Mobilní aplikace. Dokument nepopisuje administrační rozhraní (backend) ani napojení na příbuzné databáze.

Mobilní aplikace. Dokument nepopisuje administrační rozhraní (backend) ani napojení na příbuzné databáze. oolczechguide Mobilní aplikace! O dokumentu Tento dokument popisuje uživatelské rozhraní nativní mobilní aplikace CoolCzechGuide pro operační systémy Android (verze 4 a výše) a ios (verze 7 a výše). Popisuje

Více

Cenová kalkulace a stravovací služby v zařízeních školního stravování

Cenová kalkulace a stravovací služby v zařízeních školního stravování Cenová kalkulace a stravovací služby v zařízeních školního stravování Školní stravování, závodní stravování v příspěvkových organizacích zřizovaných územně samosprávným celkem v oblasti školství. (metodika

Více

Vyhlášení opakované veřejné soutěže 1/6

Vyhlášení opakované veřejné soutěže 1/6 Vyhlášení opakované veřejné soutěže 1/6 MINISTERSTVO OBRANY ČR SEKCE VYZBROJOVÁNÍ V Y H L Á Š E N Í OPAKOVANÉ VEŘEJNÉ SOUTĚŽE III. VE VÝZKUMU, VÝVOJI A INOVACÍCH NA VÝBĚR PROJEKTŮ DO PROGRAMU OBRANNÉHO

Více

Návod pro vzdálené p ipojení do sít UP pomocí VPN pro MS Windows 7

Návod pro vzdálené p ipojení do sít UP pomocí VPN pro MS Windows 7 Návod pro vzdálené p ipojení do sít UP pomocí VPN pro MS Windows 7 1. Úvod nezbytné kroky ne se p ipojíte 2. Jak si vytvo it heslo 3. Nastavení VPN p ipojení pro Windows 7 1. Úvod Slu ba VPN umo uje vstoupit

Více

Všeobecné obchodní podmínky portálu pomocsukolem.cz platné dnem 5. ledna 2015

Všeobecné obchodní podmínky portálu pomocsukolem.cz platné dnem 5. ledna 2015 Všeobecné obchodní podmínky portálu pomocsukolem.cz platné dnem 5. ledna 2015 1. Základní ustanovení 1.1 Pomocsukolem.cz je portál zprostředkovávající mezi lektory a studenty služby, které usnadňují proces

Více

Příloha č. 54. Specifikace hromadné aktualizace SMS-KLAS

Příloha č. 54. Specifikace hromadné aktualizace SMS-KLAS Název projektu: Redesign Statistického informačního systému v návaznosti na zavádění egovernmentu v ČR Příjemce: Česká republika Český statistický úřad Registrační číslo projektu: CZ.1.06/1.1.00/07.06396

Více

JUDr. Ladislav Navrátil, soudní exekutor USNESENÍ. Dražební vyhlášku o provedení elektronické dražby dobrovolné

JUDr. Ladislav Navrátil, soudní exekutor USNESENÍ. Dražební vyhlášku o provedení elektronické dražby dobrovolné JUDr. Ladislav Navrátil, soudní exekutor Exekutorský úřad Pardubice, Sladkovského 592, 530 02 Pardubice tel. 606 050 465, 727 954 056 podatelna@exekuce-pardubice.cz, www.exekuce-pardubice.cz č. j. 052

Více

1 Data. 2 Výsledky m ení velikostí. Statistika velikostí výtrus. Roman Ma ák

1 Data. 2 Výsledky m ení velikostí. Statistika velikostí výtrus. Roman Ma ák Statistika velikostí výtrus Roman Ma ák 6.2.216 1 Data Velikost výtrus (udávaná obvykle v µm) pat í u hub k významným ur ovacím znak m, mnohdy se dva druhy makromycet li²í dokonce pouze touto veli inou.

Více

Správa požadavků. Semestrální práce

Správa požadavků. Semestrální práce Správa požadavků Semestrální práce Tomáš Náhlovský 12. březen 2013 Obsah I.METODIKA SPRÁVY POŽADAVKŮ 1.1 SBĚR POŽADAVKŮ 3 1.2 EVIDENCE POŽADAVKŮ 3 1.3 ZMĚNY POŽADAVKŮ 3 1.4 POSUZOVÁNÍ POŽADAVKŮ 3 1.5 KONTROLA

Více

VÝZVA K PODÁNÍ NABÍDKY A PROKÁZÁNÍ SPLN NÍ KVALIFIKACE ZADÁVACÍ DOKUMENTACE ZADÁVACÍ DOKUMENTACE

VÝZVA K PODÁNÍ NABÍDKY A PROKÁZÁNÍ SPLN NÍ KVALIFIKACE ZADÁVACÍ DOKUMENTACE ZADÁVACÍ DOKUMENTACE VÝZVA K PODÁNÍ NABÍDKY A PROKÁZÁNÍ SPLN NÍ KVALIFIKACE ZADÁVACÍ DOKUMENTACE ve smyslu 38 zákona. 137/2006 Sb., o ve ejných zakázkách, v platném zn ní (dále jen zákon) a ZADÁVACÍ DOKUMENTACE ve smyslu 44

Více

Pokyny pro vypln ní elektronické žádosti podprogram 117D51300 Podpora výstavby technické infrastruktury

Pokyny pro vypln ní elektronické žádosti podprogram 117D51300 Podpora výstavby technické infrastruktury Pokyny pro vypln ní elektronické žádosti podprogram 117D51300 Podpora výstavby technické infrastruktury Elektronická žádost je umíst na na internetové adrese http://www3.mmr.cz/zad a lze na ni vstoupit

Více

-1- N á v r h ČÁST PRVNÍ OBECNÁ USTANOVENÍ. 1 Předmět úpravy

-1- N á v r h ČÁST PRVNÍ OBECNÁ USTANOVENÍ. 1 Předmět úpravy -1- I I. N á v r h VYHLÁŠKY ze dne 2009 o účetních záznamech v technické formě vybraných účetních jednotek a jejich předávání do centrálního systému účetních informací státu a o požadavcích na technické

Více

Posilování sociálního dialogu v místním a regionálním správním sektoru. Diskusní dokument

Posilování sociálního dialogu v místním a regionálním správním sektoru. Diskusní dokument EPSU/CEMR seminář 11. prosince 2008, Bratislava 1) Co je sociální dialog? Je důležité vysvětlit, co znamená sociální dialog, protože tento termín se obvykle nepoužívá ve všech evropských zemích pro popis

Více

ORGANIZAČNÍ ŘÁD I. ÚVODNÍ USTANOVENÍ

ORGANIZAČNÍ ŘÁD I. ÚVODNÍ USTANOVENÍ ORGANIZAČNÍ ŘÁD I. ÚVODNÍ USTANOVENÍ 1. Organizační řád Střední průmyslové školy, Klatovy, nábřeží Kpt. Nálepky 362 upravuje organizační strukturu a řízení, formy a metody práce školy a práva a povinnosti

Více

Čtvrtletní výkaz o zaměstnancích a mzdových prostředcích v regionálním školství a škol v přímé působnosti MŠMT za 1. -.

Čtvrtletní výkaz o zaměstnancích a mzdových prostředcích v regionálním školství a škol v přímé působnosti MŠMT za 1. -. Škol (MŠMT) P 1-04 Čtvrtletní výkaz o zaměstnancích a mzdových prostředcích v regionálním školství a škol v přímé působnosti MŠMT za 1. -. čtvrtletí 2010 Pokyny a vysvětlivky pro vyplnění Do nadpisu výkazu

Více

Zadávací dokumentace k veřejné zakázce

Zadávací dokumentace k veřejné zakázce Zadávací dokumentace k veřejné zakázce Otevřené řízení Tato veřejná zakázka na stejnokroj pánský a dámský je zadávána v otevřeném zadávacím řízení podle 21 odst. 1 písm. a) zákona č. 137/2006 Sb. o veřejných

Více

usnesení o nařízení elektronického dražebního jednání (dražební vyhláška)

usnesení o nařízení elektronického dražebního jednání (dražební vyhláška) Exekutorský úřad Chomutov Mgr. Jan Peroutka,soudní exekutor Revoluční 48, 430 01 Chomutov, IČ: 66225108, DIČ: CZ6805280988 Tel/Fax: 474 335 579, e-mail: info@exekucecv.cz, mobil : 774 760 744, DS: n7tg8u3

Více

Kelvin v kapkový generátor

Kelvin v kapkový generátor Kelvin v kapkový generátor Kry²tof Kadlec 1, Luká² Kune² 2, Luká² N me ek 3 1 Gymnázium Franti²ka Palackého, Vala²ské Mezi í í, krystoof.2@seznam.cz 2 Gymnázium, Zlatá stezka 137, Prachatice, kunamars@seznam.cz

Více

Česká republika Ministerstvo práce a sociálních věcí Na Poříčním právu 1, 128 01 Praha 2. vyzývá

Česká republika Ministerstvo práce a sociálních věcí Na Poříčním právu 1, 128 01 Praha 2. vyzývá Česká republika Ministerstvo práce a sociálních věcí Na Poříčním právu 1, 128 01 Praha 2 v zájmu zajištění potřeb Ministerstva práce a sociálních věcí (dále jen MPSV) a v souladu s ustanovením 6 zákona

Více

117D813 Podpora rozvoje strukturálně postižených regionů

117D813 Podpora rozvoje strukturálně postižených regionů 117D813 Podpora rozvoje strukturálně postižených regionů Zásady podprogramu pro poskytování dotací v roce 2014 (dále jen Zásady ) Správce programu: Určená banka: Ministerstvo pro místní rozvoj (dále jen

Více

*** Co Vás přivedlo k tomu založit v České republice občanské sdružení?

*** Co Vás přivedlo k tomu založit v České republice občanské sdružení? březen 2009 Kvůli permanentní nejistotě s vízy nemůže být mongolská komunita v ČR stabilní a rozvíjet se. Rozhovor s Ariunjurgal Dashnyam, ředitelkou Česko-mongolské společnosti Abstrakt: Tereza Rejšková

Více

DODATEČNÉ INFORMACE Č. 4 K ZADÁVACÍM PODMÍNKÁM VEŘEJNÉ ZAKÁZKY

DODATEČNÉ INFORMACE Č. 4 K ZADÁVACÍM PODMÍNKÁM VEŘEJNÉ ZAKÁZKY DODATEČNÉ INFORMACE Č. 4 K ZADÁVACÍM PODMÍNKÁM VEŘEJNÉ ZAKÁZKY Komplexní servis prádla a oděvů pro Nemocnici Jihlava Nadlimitní zakázka na služby zadávaná v otevřeném řízení dle zákona 137/2006 Sb., o

Více

USNESENÍ. Dražební vyhlášku o provedení elektronické dražby nemovitých věcí

USNESENÍ. Dražební vyhlášku o provedení elektronické dražby nemovitých věcí EXEKUTORSKÝ ÚŘAD ŠUMPERK soudní exekutor JUDr. Jiří Petruň IČ: 47844582, DIČ: CZ460603459 K.H.Máchy 1294/2, 787 01 Šumperk tel: 583 301 464, e-mail: podatelna@exekutor-sumperk.cz, www.exekutor-sumperk.cz,

Více

Číslo jednací: 156 EX 4791/13-49 Uvádějte při veškeré korespondenci Značka oprávněného: Ederová - 235684/1. U s n e s e n í

Číslo jednací: 156 EX 4791/13-49 Uvádějte při veškeré korespondenci Značka oprávněného: Ederová - 235684/1. U s n e s e n í U s n e s e n í Číslo jednací: 156 EX 4791/13-49 Uvádějte při veškeré korespondenci Značka oprávněného: Ederová - 235684/1 Soudní exekutor JUDr. Milan Makarius Exekutorského úřadu Praha-západ, se sídlem

Více

Jak na KOTLÍKOVÉ DOTACE? JEDNODUCHÝ RÁDCE PRO ZÁKAZNÍKY

Jak na KOTLÍKOVÉ DOTACE? JEDNODUCHÝ RÁDCE PRO ZÁKAZNÍKY Jak na KOTLÍKOVÉ DOTACE? JEDNODUCHÝ RÁDCE PRO ZÁKAZNÍKY KOTLÍKOVÉ DOTACE pokračují! Máte doma starý kotel na uhlí, dřevo a jiná tuhá paliva? Pak jsou kotlíkové dotace určeny právě pro Vás! Pokud máte doma

Více

Seminá e. Ing. Michal Valenta PhD. Databázové systémy BI-DBS ZS 2010/11, sem. 1-13

Seminá e. Ing. Michal Valenta PhD. Databázové systémy BI-DBS ZS 2010/11, sem. 1-13 Seminá e Ing. Michal Valenta PhD. Katedra softwarového inºenýrství Fakulta informa ních technologií ƒeské vysoké u ení technické v Praze c Michal Valenta, 2010 Databázové systémy BI-DBS ZS 2010/11, sem.

Více

INFORMACE O NĚKTERÝCH OBLASTECH K ŘEŠENÍ VE VĚCI JEDNOTEK SBORŮ DOBROVOLNÝCH HASIČŮ OBCÍ A SPOLKŮ PŮSOBÍCÍCH NA ÚSEKU POŢÁRNÍ OCHRANY

INFORMACE O NĚKTERÝCH OBLASTECH K ŘEŠENÍ VE VĚCI JEDNOTEK SBORŮ DOBROVOLNÝCH HASIČŮ OBCÍ A SPOLKŮ PŮSOBÍCÍCH NA ÚSEKU POŢÁRNÍ OCHRANY II. INFORMACE O NĚKTERÝCH OBLASTECH K ŘEŠENÍ VE VĚCI JEDNOTEK SBORŮ DOBROVOLNÝCH HASIČŮ OBCÍ A SPOLKŮ PŮSOBÍCÍCH NA ÚSEKU POŢÁRNÍ OCHRANY Podnětem ke zpracování tohoto materiálu je změna působení jednotek

Více

VNITŘNÍ NORMA (Směrnice) č. 4/2010

VNITŘNÍ NORMA (Směrnice) č. 4/2010 Město Štramberk Náměstí 9, 742 66 VNITŘNÍ NORMA (Směrnice) č. 4/2010 Oběh účetních dokladů Platnost: od roku 2010 Pro účetní případy roku 2010, použití od zahájení účtování účetních případů roku 2010.

Více

1. Informace o předmětu zakázky Stručný textový popis zakázky, technická specifikace

1. Informace o předmětu zakázky Stručný textový popis zakázky, technická specifikace VÝZVA K PODÁNÍ NABÍDKY Veřejná zakázka malého rozsahu zadávaná v souladu s 12 odst. 3 a 18 odst. 3 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen zákona o veřejných

Více

U s n e s e n í o nařízení dražebního jednání - elektronická dražba VEŘEJNÁ DRAŽEBNÍ VYHLÁŠKA

U s n e s e n í o nařízení dražebního jednání - elektronická dražba VEŘEJNÁ DRAŽEBNÍ VYHLÁŠKA U s n e s e n í o nařízení dražebního jednání - elektronická dražba Číslo jednací: 085 EX 8954/11-224 Soudní exekutor JUDr. Milan Suchánek, Exekutorský úřad Praha 9 se sídlem Pod Pekárnami 245/10, 190

Více

Úvod, terminologie. Ing. Michal Valenta PhD. Databázové systémy BI-DBS ZS 2010/11, P edn. 1

Úvod, terminologie. Ing. Michal Valenta PhD. Databázové systémy BI-DBS ZS 2010/11, P edn. 1 Úvod, terminologie Ing. Michal Valenta PhD. Katedra softwarového inºenýrství Fakulta informa ních technologií ƒeské vysoké u ení technické v Praze c Michal Valenta, 2010 Databázové systémy BI-DBS ZS 2010/11,

Více

Pokusné ověřování Hodina pohybu navíc. Často kladené otázky

Pokusné ověřování Hodina pohybu navíc. Často kladené otázky MINISTERSTVO ŠKOLSTVÍ, MLÁDEŽE A TĚLOVÝCHOVY ČESKÉ REPUBLIKY Karmelitská 7, 118 12 Praha 1 - Malá Strana Pokusné ověřování Hodina pohybu navíc Často kladené otázky Dotazy k celému PO: Dotaz: Co to přesně

Více

Případové studie: 53-41-M/01 Zdravotnický asistent Škola: Střední zdravotnická škola, Prostějov, Vápenice 3, 796 01 Prostějov

Případové studie: 53-41-M/01 Zdravotnický asistent Škola: Střední zdravotnická škola, Prostějov, Vápenice 3, 796 01 Prostějov 1 Případové studie: 53-41-M/01 Zdravotnický asistent Škola: Střední zdravotnická škola, Prostějov, Vápenice 3, 796 01 Prostějov Úvodní komentář k případové studii: Střední zdravotnická škola působí v regionu

Více

P r a v i d l a. Odstranění škod po jarní povodni v roce 2006 na hrázích a objektech rybníků.

P r a v i d l a. Odstranění škod po jarní povodni v roce 2006 na hrázích a objektech rybníků. P r a v i d l a České republiky - Ministerstva zemědělství č. j. 21179/2006 16000 pro poskytování a čerpání přímých dotací vodnímu hospodářství na úhradu odstranění škod po jarní povodni 2006 na hrázích

Více

Evko - uºivatelská p íru ka verze 5.1.0

Evko - uºivatelská p íru ka verze 5.1.0 Evko - uºivatelská p íru ka verze 5.1.0 22. ervna 2005 2 Kapitola 1 Úvod Program EVKO je ur en jako pomocník p edev²ím pro montáºní a servisní rmy p i plánování a evidenci pravidelných revizí, kontrol,

Více

Česká zemědělská univerzita v Praze Fakulta provozně ekonomická. Obor veřejná správa a regionální rozvoj. Diplomová práce

Česká zemědělská univerzita v Praze Fakulta provozně ekonomická. Obor veřejná správa a regionální rozvoj. Diplomová práce Česká zemědělská univerzita v Praze Fakulta provozně ekonomická Obor veřejná správa a regionální rozvoj Diplomová práce Problémy obce při zpracování rozpočtu obce TEZE Diplomant: Vedoucí diplomové práce:

Více

Memoria Mundi Series Bohemica z trezoru na Internet

Memoria Mundi Series Bohemica z trezoru na Internet Memoria Mundi Series Bohemica z trezoru na Internet Ing. Stanislav Psohlavec AiP Beroun s.r.o. Pilíře projektu MMSB... 1 Digitalizace, digitální dokumenty, digitální knihovna... 1 MASTER... 1 Využívání

Více

Výzva k podání nabídky a k prokázání kvalifikace pro VZ malého rozsahu

Výzva k podání nabídky a k prokázání kvalifikace pro VZ malého rozsahu Výzva k podání nabídky a k prokázání kvalifikace pro VZ malého rozsahu Název veřejné zakázky: Ušití stejnokrojových součástí pro OLO v letech 2015-2018 Identifikace zadavatele: Zadavatel: Řízení letového

Více

Inovace (praxe) 1 Úvod, p edstavení rmy, omezení práce. 16. listopadu 2010, Organizace a informace. Karel Kohout

Inovace (praxe) 1 Úvod, p edstavení rmy, omezení práce. 16. listopadu 2010, Organizace a informace. Karel Kohout Inovace (praxe) 1 Úvod, p edstavení rmy, omezení práce V rámci seminární práce jsou rozebrány t i inovace, realizované záºitkovou agenturou FAN MOTION 1. Dv z nich jsou spí²e technického rázu (sb r údaj

Více

Směrnice DSO Horní Dunajovice a Želetice - tlaková kanalizace a intenzifikace ČOV. Dlouhodobý majetek. Typ vnitřní normy: Identifikační znak: Název:

Směrnice DSO Horní Dunajovice a Želetice - tlaková kanalizace a intenzifikace ČOV. Dlouhodobý majetek. Typ vnitřní normy: Identifikační znak: Název: Typ vnitřní normy: Směrnice DSO Horní Dunajovice a Želetice - tlaková kanalizace a intenzifikace ČOV Identifikační znak: Název: Dlouhodobý majetek Vazba na legislativu: Závazné pro: Zákon č. 563/1991 Sb.,

Více