Systém pro správu prodejů DVD

Transkript

1 ii

2 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce Bakalářská práce Systém pro správu prodejů DVD Pavel IVON Vedoucí práce: Ing. Martin Klíma, Ph.D. Studijní program: Softwarové technologie a management Obor: Web a multimédia 27. května 2011

3 iv

4 v Poděkování Na tomto místě bych rád poděkoval všem, kteří stáli při mně v průběhu studia a psaní této práce. Především bych rád poděkoval vedoucímu této práce Ing. Martinu Klímovi za jeho rady a připomínky.

5 vi

6 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). V Praze dne 27. května 2011

7 viii

8 Abstract This bachelor thesis deals with the analysis, design and implementation of DVD sales management system. Created application, based on web technologies provides an environment for managing vendors, customers, various types of sales and product transfers. Finally, the application includes tools for making vendors inventories and generating sales reports. During the application design emphasis was placed on simplicity and usability, with regard to the fact that users will be ordinary unskilled computer users. Abstrakt Tato bakalářská práce se zabývá analýzou, návrhem a implementací aplikace pro správu prodejů DVD. Vytvořená aplikace, postavená na webových technologiích, nabízí prostředí pro správu prodejců, zákazníků, různých druhů prodejů a převodů zboží. V neposlední řadě aplikace obsahuje nástroje pro tvorbu inventur jednotlivých prodejců a generování přehledů prodejů. Při návrhu a vytváření aplikace byl kladen důraz na jednoduchost a použitelnost s ohledem na to, že uživateli aplikace budou běžní uživatelé počítače. ix

9 x

10 Obsah 1. Úvod... 1 Motivace Popis problému, specifikace cíle... 3 Cíl bakalářské práce Analýza... 5 Existující řešení... 5 Definice pojmů... 5 Funkční požadavky... 5 Nefunkční požadavky... 8 Uživatelské role Guest OZ ASM Manager Admin Návrh řešení Výběr implementačních technologií Zend Framework Databáze jquery jquery UI Navigační model Datový model Realizace Vytvoření databáze Vytvoření projektu Architektura aplikace Mapování URL adres Využívané komponenty Zend Frameworku Zend_Layout Zend_View Zend_Auth Zend_Acl Zend_Form xi

11 xii OBSAH Zend_Validate ZendX_JQuery Využívané komponenty jquery frameworku Dialog Autocomplete Datepicker Externí pluginy jquery frameworku DataTables jquery Form Plugin Testování Testování kompatibility mezi prohlížeči Testování uživateli Závěr Literatura A. Seznam použitých zkratek B. Instalační příručka B.1. Vytvoření databáze B.2. Instalace aplikace B.3. Nastavení serveru B.4. Konfigurace aplikace C. Uživatelská příručka C.1. Přihlášení C.2. Hlavní menu C.3. Správa uživatelů C.4. Přímý prodej C.5. Seznam přímých prodejů C.6. Komisní prodej C.7. Vklady do banky C.8. Vklady do pokladny C.9. Převody zboží OZ sklad a OZ OZ C.10. Inventura C.11. Reporty D. SQL skript pro vytvoření struktury databáze E. Obsah přiloženého CD... 51

12 Seznam obrázků Obrázek 1: Uživatelské role v systému... 8 Obrázek 2: Diagram případů užití role OZ... 9 Obrázek 3: Diagram případů užití role ASM Obrázek 4: Diagram případů užití role Manager Obrázek 5: Diagram případů užití role Admin Obrázek 6: Diagram technologie MVC [33] Obrázek 7: Prototyp - Přihlašovací dialog Obrázek 8: Prototyp Hlavní menu Obrázek 9: Prototyp Správa uživatelů Obrázek 10: Prototyp Přímý prodej na fakturu Obrázek 11: Prototyp Komisní prodej na fakturu Obrázek 12: Datový model Obrázek 13: jquery Dialog Obrázek 14: jquery Autocomplete Obrázek 15: jquery Datepicker Obrázek 16: jquery plugin DataTables Obrázek 17: jquery Form Plugin Obrázek C. 1: Hlavní menu aplikace Obrázek C. 2: Správa uživatelů Obrázek C. 3: Přidat uživatele Obrázek C. 4: Přímý prodej Obrázek C. 5: Seznam přímých prodejů Obrázek C. 6: Komisní prodej Obrázek C. 7: Vklad do banky Obrázek C. 8: Převod zboží mezi OZ Obrázek C. 9: Inventura Obrázek C. 10: Reporty xiii

13 xiv SEZNAM OBRÁZKŮ

14 Kapitola 1 Úvod Každý z nás se jistě již setkal s - v poslední době tolik rozšířenými levnými DVD, která jsou ve svých papírových obalech vidět na stojanech před každou trafikou, či na pultech s časopisy v každém supermarketu. Většina z nás si jistě takovéto DVD nejednou zakoupila. Než se tyto filmové disky dostanou na pulty obchodů urazí ovšem dlouhou cestu a o jejich dodání se stará mnoho lidí. V rámci této práce jsem dostal možnost vytvořit aplikaci pro společnost, která se právě distribucí těchto DVD zabývá. Motivace Hlavní motivací pro vytvoření této aplikace byla nutnost zavést efektivnější technologie pro správu rozsáhlé distribuční sítě DVD disků. Zadavatelem tohoto projektu je osoba, která se v tomto oboru přímo pohybuje, což bylo samozřejmě výhodou, protože zde byla možnost se kdykoli se zadavatelem spojit a aplikaci maximálně přizpůsobit svému účelu. V současné době firma neužívá žádnou podobnou aplikaci a veškeré transakce, prodeje, přesuny DVD mezi obchodníky či převody peněz jsou zaznamenávány pouze v papírové podobě, tedy v dnešní době velmi nešikovně a nešťastně. Stejně tak nelze mít jednoduše přehled o pohybu a prodejích DVD. Tento druh záznamů je běžný u nově vzniklých a rychle rostoucích firem. Právě tento problém má tato práce za cíl změnit k lepšímu. Aplikace nabízí přehledné prostředí pro správu prodejců v distribuční síti i jejich zákazníků. Dále aplikace uchovává seznam nabízených produktů a díky tomu i to, kolik DVD má který prodejce u sebe, či kolik peněz za prodaná DVD utržil. V neposlední řadě potom aplikace nabízí nástroje pro manažera, který má neustálý přehled o tom, kolik DVD jeho distribuční síť za určité časové období prodala. 1

15 2 KAPITOLA 1. ÚVOD

16 Kapitola 2 Popis problému, specifikace cíle Cíl bakalářské práce Cílem této bakalářské práce je navrhnout, implementovat a otestovat aplikaci pro správu prodejů DVD v rámci distribuční sítě. Podmínky, co vše musí aplikace umět, byly předem dány, protože se jedná o aplikaci vytvářenou pro firmu, která se zabývá právě distribucí DVD. Výhodou tohoto je, že je možné všechny problémy konzultovat se zadavatelem a přizpůsobit tak aplikaci přesně jeho potřebám a potřebám obchodníků zapojených v této distribuční síti. Dále bude možné zadavatele průběžně informovat o postupu vytváření aplikace. Zadavatel bude moci aplikaci postupně testovat a zasílat zpět připomínky a požadavky na vylepšení. Aplikace bude umožňovat správu zákazníků, obchodníků zapojeních do distribuční sítě a nabízených produktů. Dále bude možné zaznamenávat následující transakce: prodeje produktů o přímé o komisní převody mezi obchodníkem a skladem zboží (tam i zpět) převody mezi obchodníky vzájemně Stejně jako převody zboží bude možné zaznamenávat i převody peněz v případech, kdy obchodník vkládá utržené peníze do banky, či do pokladny. V případě všech transakcí bude aplikace umožňovat zobrazení jejich historie v přehledných tabulkách s možnostmi filtrování dle vybraných kritérií a řazení. Takto vyfiltrovaná a seřazená data bude umět aplikace exportovat pro pozdější využití v jiných aplikacích. V neposlední řadě bude aplikace umožňovat vytvářet inventury obchodníků a reporty prodejů u jednotlivých zákazníků za určitá období, opět s možností exportu dat pro pozdější využití. Aplikace bude koncipována jako víceuživatelská, postavená na webových technologiích. Bude tedy nutné, aby aplikace řešila i správu uživatelů, jejich uživatelské role, přihlašování a autorizaci uživatelů k jednotlivým akcím. Zároveň je třeba, aby aplikace uchovávala informaci o tom, který obchodník provedl který prodej atd. 3

17 4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE Protože se jedná o aplikaci pro využití v praxi, je součástí práce i její nasazení na veřejně přístupném webovém serveru, díky čemuž bude možné do aplikace přistupovat téměř odkudkoli.

18 Kapitola 3 Analýza Tato kapitola má za úkol analyzovat problém a připravit základnu pro jeho vyřešení. V kapitole jsou uvedena existující řešení daného problému, funkční a nefunkční požadavky na aplikaci a přehled uživatelských rolí systému. Existující řešení Po nějaké době hledání se jsem nalezl aplikace pro správu prodejů, nicméně ani po delším hledání se nepodařilo nalézt tuzemskou ani zahraniční aplikaci zabývající se přesně řešením tohoto problému. Nicméně se není čemu divit, protože požadavky na aplikaci jsou velice specifické. Jediným možným řešením tedy je vytvořit aplikaci přesně na míru, dle požadavků zadavatele. Definice pojmů Následují definice pojmů využívaných dále v práci: Systém, aplikace Výrazy systém nebo aplikace se rozumí systém pro správu prodejů DVD předmět této práce. Uživatel Uživatel systému s přidělenými přihlašovacími údaji. OZ Obchodní zástupce, obchodník distribuční sítě, uživatel s rolí OZ. ASM Nadřízený OZ Zboží, produkt DVD, které jsou předmětem prodeje v distribuční síti. Zákazník Osoba nebo firma odebírající zboží od distribuční sitě. Sklad Fyzický sklad DVD, který je ve správě zadavatele. Sledovat zboží na skladě není úkolem této aplikace. Funkční požadavky Následuje detailní výpis všech funkčních požadavků. Aplikace musí být nepřístupná nepovolaným osobám. Všichni uživatelé se přihlašují uživatelským jménem a heslem. Každý uživatel je přiřazen k jedné uživatelské roli. 5

19 6 KAPITOLA 3. ANALÝZA Uživatel má pouze taková oprávnění, jaká oprávnění má jeho role. Aplikace umožňuje správu uživatelů, jejich přidávání, mazání, upravování, aktivování a deaktivování. Neaktivní uživatel se nemůže přihlásit do systému. Každý uživatel OZ má přiřazeného ASM, který má přehled o jeho transakcích. Aplikace umožňuje správu zákazníků, jejich přidávání, mazání, upravování, aktivování a deaktivování. Neaktivní zákazníci jsou po dobu své neaktivity vyřazeni ze systému (nelze jim prodávat zboží atd.) Každý zákazník má přiděleného OZ, který k danému zákazníkovi distribuuje zboží. Každý zákazník může mít nastavenou vedoucí pobočku. Toto nastává ve chvíli, kdy OZ distribuuje zboží zákazníkovi, který je součástí sítě poboček. Zákazníci mohou být filtrováni podle jejich aktivity. Každý zákazník může mít nastavenou defaultní slevu, která se bude automaticky vyplňovat v prodejích, které se ho týkají Aplikace umožňuje správu prodávaného zboží, jeho přidávání, mazání, upravování, aktivování a deaktivování. Neaktivní zboží se nezobrazuje v systému. U každého zboží bude možnost nastavit cenu za kus a DPH. Aplikace musí umožňovat zaznamenání následujících prodejů zboží: o Přímý prodej V hotovosti Faktura se splatností Dodací list o Komisní prodej V hotovosti Faktura se splatností Dodací list U každého prodeje musí aplikace uchovávat informaci, ke kterému zákazníkovi a OZ prodej patře, kdy prodej proběhl, kolik bylo prodáno zboží. U přímých prodejů se zaznamenává u každého druhu zboží počet prodaných kusů. U komisních prodejů se zaznamenává počáteční stav (počet ks každého zboží na pobočce před dnešním dodáním), počet dodaných kusů.

20 KAPITOLA 3. ANALÝZA 7 U komisních prodejů se dle historie dopočítá koncový stav naposled (počet ks každého zboží na pobočce po minulém dodání). Přímé prodeje a komisní prodeje budou vypsány zvlášť. Prodeje mohou být filtrovány podle jejich typu (V hotovosti, Na fakturu se splatností, Dodací list), data uskutečnění zdanitelného plnění, OZ a zákazníka (mezi kterými prodej proběhl). Aplikace umožňuje zadávat informace o vkladu do pokladny a do banky. Vklady do pokladny a do banky mohou být filtrovány podle data a OZ. Vklady do pokladny mohou být dvou typů: o Hotovost o Náklady na provoz Pro každého OZ bude možno zaznamenávat výdeje ze skladu a vratky do skladu. Aplikace bude umožňovat ukládat vzájemné transakce mezi OZ. U transakcí mezi OZ a skladem nebo OZ a OZ bude zaznamenán počet kusů od každého zboží, který byl převeden. Transakce mezi OZ a skladem nebo OZ a OZ bude možno filtrovat dle data uskutečnění a OZ. U všech transakcí se bude ukládat, kdo transakci provedl (uložil do systému). O každé transakcí bude možno si zobrazit její detailní informace. Aplikace bude umožňovat provést inventuru nad OZ k dnešnímu datu, či k datu v historii. Inventura zobrazí informace o tom, kolik ks každého druhu zboží má OZ u sebe, kolik ks u zákazníka a kolik hotovosti z prodeje má u sebe. Aplikace bude evidovat historii inventur s možností zobrazení detailu. Aplikace bude umožňovat provedení následujících reportů: o Přehled obratu zákazníků po měsících Hotovost a faktury Dodací listy Vše o Přehled obratu zákazníků po týdnech Hotovost a faktury Dodací listy

21 8 KAPITOLA 3. ANALÝZA Vše Reporty bude možno exportovat do CSV. Historie transakcí budou zobrazeny v tabulkách s možností řazení. Vybrané vyfiltrované transakce bude možno exportovat do CSV. Nefunkční požadavky Aplikace bude založena na webových technologiích. Aplikace bude přístupná na veřejně přístupném webovém serveru, aby bylo možno ji využívat z různých míst pomocí běžného softwarového vybavení každého běžného počítače (webový prohlížeč). Aplikace bude pro ukládání dat využívat databázi. Aplikace se bude korektně zobrazovat v posledních verzích hlavních zástupců prohlížečů (Mozilla Firefox, Internet Explorer, Google Chrome). Protože se jedná o aplikaci z praxe, je nezbytné zajistit udržitelnost vývoje a budoucích rozšíření. Uživatelské role Uživatelé se mohou v systému vyskytovat ve čtyřech rolích. Rolemi jsou určena přístupová práva k částem a funkcím aplikace. Každý uživatel může mít přiřazenu pouze jednu uživatelskou roli. Vzájemné závislosti mezi rolemi jsou uvedeny na obrázku Obrázek 1: Uživatelské role v systému. Obrázek 1: Uživatelské role v systému

22 KAPITOLA 3. ANALÝZA 9 Guest Host, uživatel bez ověření. Může se pouze přihlásit, pokud má přiřazeno uživatelské jméno a heslo. Diagram případů užití role Guest není uveden, protože by obsahoval pouze přihlášení. OZ OZ je základní role systému s nejnižšími právy. Tato role bude přidělena obchodníkům v distribuční síti. Uživatel má možnost zaznamenávat všechny druhy prodejů. Ve formulářích prodejů se mu zobrazí pouze zákazníci, které má na starosti. Stejně tak si může zobrazit historii jím provedených prodejů včetně filtrování a zobrazení detailních informací o každém prodeji. Dále může OZ provést vklad do banky. Jedná se o odevzdání hotovosti v bance, která peníze zašle na účet firmy. Opět si může zobrazit historii jím provedených vkladů do banky. Obrázek 2: Diagram případů užití role OZ

23 10 KAPITOLA 3. ANALÝZA ASM ASM dědí všechna oprávnění od role OZ. Může tedy sám provádět prodeje, či vklady do banky. Může ovšem také provádět prodeje a vklady do banky jménem jemu podřízených OZ. Stejně tak si může zobrazit historii svých transakcí i transakcí svých podřízených. Navíc může ASM provést vklad do pokladny. OZ vklady do pokladny provádět nemůže, vklady do pokladny obchodníků za ně provádí vždy jejich nadřízený ASM. Opět si ASM může zobrazit historii těchto vkladů do pokladny. Dále může ASM provést převod zboží mezi jím samotným a skladem, či OZ a skladem a to v obou směrech. Stejně jako u jiných transakcí lze i zde vypsat historii převodů. Obrázek 3: Diagram případů užití role ASM Manager Tato role je určena pro manažera firmy. Dědí všechna oprávnění role ASM s tím, že má kompletní přehled o všech transakcích všech OZ a ASM. Navíc má možnost provést převod zboží mezi jednotlivými OZ a jako vždy zobrazit historii těchto transakcí. Oproti ostatním rolím může manažer spravovat zákazníky, uživatele a produkty v systému. Může je přidávat, provádět jejich úpravy, aktivace, deaktivace a mazat je.

24 KAPITOLA 3. ANALÝZA 11 Manažer může dále provádět inventury jednotlivých ASM a OZ. Zjistit kolik kusů kterého zboží mají aktuálně u sebe a jemu přidělených zákazníků a kolik utržených peněz mají u sebe. V neposlední řadě může také manažer provádět reporty provedených prodejů dle zadání ve funkčních požadavcích. Tyto reporty může exportovat do formátu CSV pro další použití. Obrázek 4: Diagram případů užití role Manager Admin Admin role s nejvyššími oprávněními v systému dědí všechna oprávnění role Manager. Navíc k těmto oprávněním má admin možnost obnovovat smazané uživatele, zákazníky a produkty.

25 12 KAPITOLA 3. ANALÝZA Obrázek 5: Diagram případů užití role Admin

26 Kapitola 4 Návrh řešení Výběr implementačních technologií Jedním z nefunkčních požadavků je, aby byla aplikace postavena na webových technologiích. Protože výsledkem má být aplikace připravená pro nasazení v praxi, je hlavním cílem využít pro návrh a tvorbu aplikace dobré vlastnosti a nápady získané v průběhu studia a při zkoumání a tvorbě jiných podobných aplikací. Vhodným jazykem pro implementaci aplikace tohoto rozsahu je PHP [1], konkrétně ve verzi 5. Je zbytečné pro aplikaci tohoto typu využívat technologie jako Java EE [2], či ASP.NET [3]. Mimo jiné si myslím, že mám s jazykem PHP5 daleko větší zkušenosti. Samozřejmě je nezbytné při využití PHP5 využít objektově orientovaného programování, pro lepší přehlednost a strukturu kódu. V minulosti se mi pro vývoj podobných aplikací vyplatilo využít Zend Framework [4] právě díky jeho podpoře pro objektově orientované PHP. Mimo to Zend Framework nabízí ve své distribuci rozsáhlou knihovnu, která programování podobných aplikací velmi zjednodušuje. Aplikace bude také vyžadovat perzistentní úložiště dat databázi. Jako databáze byla vybrána MySQL [5] opět proto, že s ní mám již zkušenosti a pro potřeby této aplikace je zcela vyhovující. Při vývoji aplikace je nutné dbát na jednoduchost a pohodlnost použití. Z tohoto důvodu bude nezbytné při vývoji využít skriptování na straně klienta pomocí skriptovacího jazyka JavaScript [6]. Díky JavaScriptu je možné využít další technologii AJAX [7], která zajistí plynulejší chod aplikace bez nutnosti stále načítat celou stránku. Protože jsou možnosti využití JavaScriptu a AJAXu velice rozsáhlé, je vhodné využít vhodný framework i pro tyto technologie. V tomto případě byl využit framework jquery [8] a jeho komponenty uživatelského rozhraní jquery UI [9]. Zend Framework Zend Framework je open source [10], objektově orientovaný framework pro psaní webových aplikací v PHP5. Zend Framework využívá návrhový vzor MVC [11] (Model View Controller). Tento návrhový vzor dělí aplikaci na tři vrstvy: 13

27 14 KAPITOLA 4. NÁVRH ŘEŠENÍ Model vrstva spravující data aplikace a práci s nimi, zapisuje a čte data z databáze. View vrstva připravuje data pro prezentaci uživateli. Controller vrstva obsluhuje čtení vstupu od uživatele, komunikuje s vrstvou Model, pro získání dat a předává data do View pro prezentaci uživateli. Obrázek 6: Diagram technologie MVC, zdroj: [33] Mimo výhody MVC architektury nabízí Zend Framework rozsáhlou knihovnu komponent pro tvorbu aplikace. V aplikaci bude výhodné využít mnoho z nich jako například: Zend_Layout Zend_View Zend_Db, Zend_Db_Table Zend_Registry Zend_Date Zend_Form Zend_Validate a další [12] Zend Framework ve verzi 1.10 má ovšem také určité požadavky na systém, na kterém bude pracovat [13]: PHP ve verzi alespoň 5.2.4

28 KAPITOLA 4. NÁVRH ŘEŠENÍ 15 PHP rozšíření MySQL [14] pro připojení k databázi MySQL PHP rozšíření PDO_MySQL [15] pro připojení k databázi MySQL pomocí PHP Data Objects (PDO) interface direktiva document_root virtuálního serveru, kde aplikace poběží nastavena na složku /public Databáze Jako úložiště dat pro aplikaci jsem zvolil databázi MySQL ve verzi 5.1. Jako engine je zvolen MyISAM. Do databáze bude aplikace přistupovat pomocí UTF-8 [16], kvůli podpoře češtiny. Všechny tabulky budou mít nastaveno charset na utf8 a collation na utf8_czech_ci. jquery jquery je JavaScriptová knihovna s dlouholetou tradicí vývoje. jquery v dnešní době využívá veliká spousta webových aplikací. Knihovna nabízí jednoduché nástroje pro přístup k HTML elementům, manipulaci s nimi. Dále poskytuje rozsáhlé nástroje pro animace, odchytávání událostí, AJAXová volání a mnoho dalších. jquery je také velice snadno rozšířitelná díky existenci obrovského množství pluginů [17]. jquery UI jquery UI je JavaScriptový framework využívající jquery pro jednoduchou implementaci pokročilých efektů a elementů do webových aplikací. Díky tomuto frameworku lze vytvářet aplikace, které nabízejí uživateli větší komfort a interaktivitu než běžné webové aplikace. Mimo jiné nabízí jquery UI také nástroj zvaný ThemeRoller [18], díky kterému lze jednoduše sestavit grafický styl, kterým se budou veškeré elementy jquery UI zobrazovat. ThemeRoller obsahuje také galerii již připravených vyvážených témat. Navigační model Pro vytvoření jednoduchého, omezeně funkčního prototypu a představy o navigačním modelu byla využita aplikace Balsamiq Mockups [19]. Tato aplikace nabízí výborné prostředí pro tvorbu jednoduchých prototypů díky množství elementů, které lze v prototypu využít. Navíc lze vytvořit například několik obrazovek a pomocí odkazů mezi nimi přecházet, díky čemuž se prototyp chová alespoň částečně reálně a je možné si udělat představu o budoucí aplikaci. Navíc lze již ve fázi prototypu rozhodnout jakým způsobem se bude aplikace chovat, jaké bude využívat elementy a jak bude celkově vypadat. Na následujících obrázcích jsou zobrazeny části prototypu:

29 16 KAPITOLA 4. NÁVRH ŘEŠENÍ Obrázek 7: Prototyp - Přihlašovací dialog Na obrázku Obrázek 7 je vyobrazen dialog, pomocí kterého se budou uživatelé do systému přihlašovat. Přihlášení do systému bude možné pouze pro uživatele, kteří mají přiděleny přihlašovací údaje. Obrázek 8: Prototyp Hlavní menu Na obrázku Obrázek 8 je část prototypu, kde je vyobrazeno hlavní menu aplikace. Tato stránka se zobrazí po přihlášení všech uživatelů. Složení stránky se bude měnit podle role přihlášeného uživatele.

30 KAPITOLA 4. NÁVRH ŘEŠENÍ 17 Obrázek 9: Prototyp Správa uživatelů Na obrázku Obrázek 9 je zobrazena navržená stránka se správou uživatelů. V podobných tabulkách se budou zobrazovat historie prodejů, transakci a podobně. Obrázek 10: Prototyp Přímý prodej na fakturu Na obrázku Obrázek 10 je návrh formuláře pro zadání přímého prodeje do systému. Možnost volit obchodního zástupce bude zpřístupněna pouze uživatelům s rolí ASM a vyšší. Uživatelé s rolí OZ mohou zadávat prodeje pouze za sebe. Do formuláře pro přímý prodej lze pro každý druh zboží zadat pouze počet kusů, které byly prodány.

31 18 KAPITOLA 4. NÁVRH ŘEŠENÍ Na obrázku Obrázek 11 je pro přehled zobrazen formulář pro zadání komisního prodeje. Liší se v tom, že je nutné pro každý druh zboží zadat počáteční stav dnes a počet dodaných kusů. Ostatní položky se dopočítají automaticky. Obrázek 11: Prototyp Komisní prodej na fakturu

32 KAPITOLA 4. NÁVRH ŘEŠENÍ 19 Datový model Datový model je vyobrazen na obrázku Obrázek 12. Diagram byl vytvořen pomocí nástroje Microsoft Visio. Obrázek 12: Datový model Entita user představuje uživatele, který má přístup do systému. Každý uživatel může mít nadřízeného uživatele, čímž vznikne vztah M:N mezi tabulkami user a user. Tento vztah je dekomponován pomocí tabulky user_leader, která uchovává který uživatel byl kterému nadřízený a od kdy do kdy. Další základní entitou je customer, představující zákazníka odběratele distribuční sítě. Každý zákazník má přiřazeného uživatele, který ho má na starosti. Tím vzniká další vztah M:N mezi tabulkami customer a user. Tento vztah je dekomponován tabulkou assigned_user, která obsahuje opět atributy od kdy a do kdy byl daný uživatel danému zákazníkovi přiřazen. Entita product představuje druh zboží v systému. Důležitou entitou je product_transfer, která reprezentuje převod zboží. U převodu zboží je třeba ukládat kdo ho provedl, kdy a jakého byl typu. K entitě product_transfer existují entity user_customer_transfer, store_user_transfer a user_user_transfer, které obsahují již přesné informace o tom, které zboží a v kolika kusech bylo převáděno. Entita user_customer_transfer představuje převod zboží od uživatele k zákazníkovi. Jedná se o prodej, je tedy nezbytné uchovávat informace o tom, jakého typu byl prodej, kolik zboží

33 20 KAPITOLA 4. NÁVRH ŘEŠENÍ bylo prodáno, za kolik a s jakým DPH. Zároveň je samozřejmě třeba vědět, který uživatel prodej provedl, s jakým zákazníkem. A nakonec je zde také vztah s entitou product_transfer. Entita store_user_transfer reprezentuje převody zboží mezi skladem a uživatelem. V tomto případě je nutné u každého typu zboží si pamatovat pouze počet převáděného zboží a samozřejmě id převodu, kvůli vztahu s entitou product_transfer. Poslední entitou uchovávající převody zboží je entita user_customer_transfer, která uchovává převody zboží mezi dvěma uživateli systému. Zde je opět nutné pamatovat si pouze počet převáděného zboží. Další entitou je cash_transfer. Tato entita uchovává informace o vkladech hotovosti do pokladny. Zde je důležité pamatovat datum, částku, typ vkladu a případně komentář. Zároveň je třeba vědět, který uživatel odváděl peníze a který uživatel převod peněz schválil. Podobnou entitou je bank_transfer, která uchovává informace o vkladech do banky. Posledními entitami jsou product_inventory a money_inventory, do kterých se ukládají průběžné inventury každého OZ. Do product_inventory se při inventuře uloží kolik kusů každého druhu zboží má uživatel u sebe. Do money_inventory se uloží aktuální výše hotovosti, kterou má OZ u sebe. Tyto tabulky slouží pro rychlejší výpočet aktuálního počtu kusů zboží u OZ a výpočet výše hotovosti, kterou má u sebe.

34 Kapitola 5 Realizace Protože byla aplikace vyvíjena na operačním systému Windows [20], byl využit balíček XAMPP, který obsahuje webový server Apache, databázový server MySQL a další aplikace vhodné pro vývoj webových aplikací na platformě Windows. Jako implementační prostředí byla použita aplikace NetBeans [21] ve verzi 7.0 pro její podporu tvorby aplikací v PHP i Zend Frameworku. Vytvoření databáze Databázi s příslušnými entitami byla vytvořena na základě výše uvedeného datového modelu. SQL skript pro vytvoření databáze je uveden v příloze D. Vytvoření projektu Zend framework nabízí ve své distribuci šikovný nástroj zvaný ZF Command Line Tool [22], využívající prostředí příkazové řádky. Tento nástroj velmi ulehčuje vytvoření adresářové struktury projektu. Je vhodné přidat cestu k tomuto nástroji do systémové proměnné PATH pro pohodlnější využití. Poté stačí v příkazovém řádku otevřít umístění, kde má být projekt umístěn a spustit následující příkaz: %> zf create project dvd-levne Po vykonání příkazu je v daném umístění vytvořen adresář s názvem projektu a následující adresářovou strukturou: 21

35 22 KAPITOLA 5. REALIZACE dvd-levne -- application -- Bootstrap.php -- configs -- controllers -- models `-- views -- library -- public `-- tests Po vytvoření této adresářové struktury je nutné do adresáře library zkopírovat knihovnu komponent Zend Frameworku, která je šířena společně s distribucí ZF. Architektura aplikace Pro vytvoření aplikace byla využita modulární struktura. Bylo tedy nutné nejdříve upravit adresářovou strukturu aplikace. Po úpravě vypadá struktura následovně:

36 KAPITOLA 5. REALIZACE 23 dvd-levne -- application -- Bootstrap.php -- configs -- layouts -- langs -- models `-- modules -- admin -- controllers -- forms -- models -- views `-- Bootstrap.php -- default -- controllers -- forms -- models -- views `-- Bootstrap.php `-- store -- controllers -- forms -- models -- views `-- Bootstrap.php -- library -- public `-- tests Adresář application obsahuje hlavní třídy rozdělené dle modulů a MVC architektury. Aplikace je rozdělena do tří modulů: Default v tomto modulu jsou umístěny základní funkce aplikace autentizace a hlavní menu. Admin zde je umístěna funkce pro správu uživatelů. Store v tomto modulu jsou umístěny ostatní funkce aplikace, které se svým účelem týkají přímo požadované funkčnosti aplikace. Každý z těchto modulů obsahuje vlastní adresářovou strukturu podle MVC architektury. Dále každý modul obsahuje adresář forms, kde jsou umístěny třídy formulářů využívaných v daném modulu. Adresář aplikace dále obsahuje složku library, kde je umístěn adresář Zend obsahující knihovnu Zend Frameworku a adresář ZendX obsahující další knihovny rozšiřující framework.

37 24 KAPITOLA 5. REALIZACE Dalším adresářem v projektu aplikace je public. V tomto adresáři jsou umístěny soubory, které mají být veřejně přístupné, tedy obrázky, zdrojové kódy JavaScriptu, knihovna jquery, CSS styly [23] a soubor index.php, který se volá při každém požadavku na aplikaci. Mapování URL adres Každá URL adresa směrovaná na aplikaci, obsahuje informaci o tom, který modul, controller a která action se má vykonat. Toto je zajištěno direktivami v souboru /public/.htaccess. Při každém volání se zavolá soubor /public/index.php, který inicializuje logiku aplikace a dle URL zavolá příslušný modul, controller a action. Využívané komponenty Zend Frameworku Díky tomu, že je aplikace postavena na Zend Frameworku lze využít jeho komponent. Díky tomu lze navíc lépe strukturovat a zpřehlednit kód aplikace. Názvy veškerých komponent z knihovny Zend Frameworku začínají prefixem Zend_. Zend_Layout Ve složce /application/layouts/scripts je umístěn soubor layout.phtml obsahující šablonu vzhledu aplikace. Tato šablona obsahuje vizuální části aplikace, které jsou společné pro všechny stránky. Komponenta Zend_Layout se stará o korektní vykreslení společních částí aplikace. V souboru šablony je řádek s následujícím kódem: <?php echo $this->layout()->content;?> V místě tohoto kódu se budou umisťovat pohledy vytvořené pomocí Zend_View komponenty. Zend_View V adresáři každého modulu je adresář views, obsahující pohledy pro akce kontrolerů v tomto modulu. Komponenta Zend_View navíc nabízí helpery pro snadnější psaní kódu, například escape helper, který escapuje výstupní data. Dalším helperem je url, který pomáhá sestavovat URL adresy pro odkazy v rámci aplikace určením modulu, kontroleru a akce, kam má směřovat. Zend_Auth Pomocí komponenty Zend_Auth lze jednoduše přihlásit uživatele a kdekoli v rámci aplikace získat informace o aktuálně přihlášeném uživateli.

38 KAPITOLA 5. REALIZACE 25 Zend_Acl Komponenta Zend_Acl nabízí možnost vytvořit třídu, která bude obsahovat seznam funkcí aplikace, uživatelských rolí a seznam povolení či zamítnutí přístupu uživatelů s danou rolí k dané funkci. V aplikaci je tato třída umístěna v souboru /application/modules/default/models/applicationacl.php. Zend_Form Komponenta Zend_Form umožňuje jednoduché vytváření HTML formulářů pomocí PHP objektů. Tyto objekty lze poté jednoduše vypsat do stránky, čímž dojde k vykreslení formuláře. Navíc komponenta umožňuje využití dalších komponent pro pokročilou práci s formuláři, například Zend_Filter a Zend_Validate. Zend_Validate Komponenta Zend_Validate umožňuje společně s využitím Zend_Form jednoduché validování hodnot zadaných uživatelem. V distribuci Zend Frameworku je zahrnuto množství připravených tříd pro validaci. Mezi takové patří: Zend_Validate_Alnum pouze alfanumerické znaky Zend_Validate_Num pouze číslice Zend_Validate_Float reálné číslo Zend_Validate_Db_NoRecordExists ověří, že se v určené tabulce nevyskytuje stejný záznam Zend_Validate_ Address validuje ovou adresu Zend_Validate_Date validace data podle určených locale a další Všechny tyto třídy umožňují nastavení vlastních chybových zpráv. Dále tato komponenta umožňuje vytvoření vlastní validační třídy. Toho jsem využil při vytvoření třídy pro validaci dvou zadaných hesel. ZendX_JQuery Komponentou ZendX_JQuery umožňuje framework integraci jquery a nabízí helpery pro použití této JavaScriptové knihovny. Nakonec jsem se tuto komponentu rozhodl v práci využít pouze pro zjednodušení práce se zdroji JavaScriptového kódu.

39 26 KAPITOLA 5. REALIZACE Využívané komponenty jquery frameworku Pro pohodlnější a efektivnější práci s aplikací jsou využity některé komponenty knihovny jquery a jquery UI. Dialog Komponenta Dialog vykresluje plovoucí panel se záhlavím. Dialog lze přesouvat, měnit jeho velikost a hlavně dynamicky pomocí AJAXu načítat jeho obsah. V aplikaci jsou dialogy využity pro formuláře, informační okna, dotazovací okna apod., aby byl uživatel co nejvíce ušetřen načítání celé stránky. Obrázek 13: jquery Dialog Autocomplete Widget Autocomplete nabízí funkci našeptávání. Zatímco uživatel vyplní jen několik písmen z hledaného textu, widget mu nabídne seznam odpovídajících výsledků. Obrázek 14: jquery Autocomplete

40 KAPITOLA 5. REALIZACE 27 Datepicker Plugin Datepicker nabízí uživateli možnost jednoduchý způsob, jak vybrat datum, bez nutnosti ho ručně psát. Navíc tento plugin validuje případné ručně zadané datum, podporuje češtinu, umožňuje omezit období, které půjde zvolit. Pro větší pohodlí uživatelů je u každého formulářového pole pro výběr data zobrazena ikona kalendáře, po jejímž stisknutí se plugin zobrazí. Obrázek 15: jquery Datepicker Externí pluginy jquery frameworku DataTables Plugin pro jquery DataTables [24] je propracovaný nástroj, který HTML tabulku doplňuje o množství interaktivních prvků. Tento plugin je v aplikaci využit hned na několika místech. Doplňuje tabulku o možnosti řazení dle sloupců, stránkování a průběžného stahování dat ze serveru. Není tedy nutné stahovat ze serveru pokaždé všechna data, ale stahují se vždy pouze data, která je třeba zobrazit. Samozřejmě je nutné, aby v aplikaci byl PHP skript, který data pro tabulku připravuje. Data jsou ze serveru stahována AJAXem ve formátu JSON [25]. Obrázek 16: jquery plugin DataTables

41 28 KAPITOLA 5. REALIZACE jquery Form Plugin jquery Form Plugin [26] nabízí možnost jak jednoduše přidat HTML formulářům možnost odesílat je pomocí AJAXu, tedy bez nutnosti po odeslání načítat celou stránku. Tento plugin je v aplikaci využit pro odesílání všech formulářů. Odeslaný formulář je na serveru validován a v případě, že validací neprojde, je pomocí AJAXu vrácen vyplněný zpět uživateli k opravě. Poté je možné formulář na pozadí znovu odeslat. Obrázek 17: jquery Form Plugin

42 Kapitola 6 Testování Aplikace byla testována na aplikačním serveru Apache verze a s nainstalovaným PHP ve verzi a 5.3.3, MySQL verze a Testování kompatibility mezi prohlížeči Aplikace byla vyvíjena v prohlížeči Mozilla Firefox [27] ve verzi 3. V tomto prohlížeči funguje bezchybně přesně jak má. I v další, 4. verzi prohlížeče Mozilla Firefox pracuje aplikace dle očekávání. V prohlížeči Google Chrome 7 [28] aplikace funguje dle očekávání. Jediným neočekávaným prvkem je automatické označování aktivních polí formuláře prohlížečem. Toto není naštěstí velikým problémem a lze tuto funkci vypnout. V prohlížeči Opera 10 [29] funguje aplikace dle očekávání až na drobné rozdíly ve vykreslování některých částí aplikace. Nejedná se ovšem o žádný problém. V prohlížeči Internet Explorer [30] verze funguje aplikace dle očekávání. Internet Explorer nepodporuje zaoblení rohů elementů pomocí CSS, proto se v tomto prohlížeči aplikace vizuálně liší. Na funkčnost aplikace to ovšem nemá vliv. Testování uživateli Z důvodu, že se jedná o aplikaci pro využití v praxi probíhalo průběžné testování již během vývoje. Aplikace byla vždy po přidání dalších funkcí otestována vedoucím práce. Ve chvíli, kdy byl vývoj aplikace v konečné fázi, byla aplikace zpřístupněna zadavateli a ten sám provedl testování a zaslal zpět své připomínky a návrhy na zlepšení. 29

43 30 KAPITOLA 6. TESTOVÁNÍ

44 Kapitola 7 Závěr Cílem této bakalářské práce bylo navrhnout, implementovat a otestovat aplikaci pro správu prodejů DVD v rámci distribuční sítě. Podmínky zadavatele na aplikaci byly splněny včetně úprav, které se projevily jako nezbytné v průběhu tvorby aplikace. V současné době byla aplikace nasazena na virtuální server, zakoupený speciálně pro tuto aplikace. Na tomto serveru je případně možno na žádost připravit spuštění aplikace v další instanci s vlastní databází, která může být využita pro testování a další vývoj. Společnost DVD-LEVNE s.r.o. [31] zadavatel aplikace - v současné době dodává DVD na více než prodejních míst. Vytvořená aplikace nebyla pro mne první podobného typu. Již v minulosti jsem vytvořil podobnou aplikaci. Ovšem psaním této aplikace jsem nepochybně získal další zkušenosti pro budoucnost. Do budoucna se počítá s možným dalším vývojem dle pokynu a požadavků zadavatele. Funkce, která bude do systému v budoucnu implementována je například spolupráce s ekonomickým systémem Pohoda [32]. Rád se tohoto dalšího vývoje aplikace zúčastním. 31

45 32 KAPITOLA 7. ZÁVĚR

46 Literatura [1] PHP: Hypertext Preprocessor [2] Java EE [3] ASP.NET [4] Zend Framework [5] MySQL [6] JavaScript [7] AJAX [8] jquery [9] jquery UI [10] open source [11] MVC learning.quickstart.intro.html [12] ZF components reference.html 33

47 34 LITERATURA [13] ZF requirements requirements.introduction.html [14] MySQL extension for PHP [15] MySQL_PDO extension for PHP [16] UTF [17] jquery Plugins [18] jquery ThemeRoller [19] Balsamiq Mockups [20] Windows [21] NetBeans [22] ZF Command Line Tool [23] CSS zend.tool.framework.clitool.html [24] jquery DataTables [25] JSON [26] jquery Form Plugin [27] Mozilla Firefox

48 LITERATURA 35 [28] Google Chrome [29] Opera [30] Internet Explorer [31] DVD-LEVNE s.r.o. [32] Ekonomický systém Pohoda

49 36 LITERATURA

50 Příloha A Seznam použitých zkratek DVD UI URL CSV PHP MVC PDO Digital Video Disc User Interface Uniform Resource Locator Comma-Separated Values Hypertext Preprocessor Model View Controller PHP Data Objects HTML Hypertext Markup Language SQL ZF CSS Structured Query Language Zend Framework Cascading Style Sheets AJAX Asynchronous XML and JavaScript JSON JavaScript Object Notation XML Extensible Markup Language 37

51 38 PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

52 Příloha B Instalační příručka Aplikace byla testována na aplikačním serveru Apache verze a s nainstalovaným PHP ve verzi a 5.3.3, MySQL verze a Instalace aplikace spočívá ve třech základních krocích: zkopírování aplikace na webový server nastavení serveru vytvoření databáze nastavení konfiguračních souborů aplikace Vytvoření databáze Na serveru vytvořte novou databázi a pomocí skriptu v příloze D v ní vytvořte požadovanou strukturu tabulek. Instalace aplikace Na server zkopírujte do vybraného umístěný všechen obsah adresáře dvd-levne. Nastavení serveru V konfiguraci serveru je nezbytné nastavit direktivu document_root na adresář dvdlevne/public. Dále je třeba nastavit direktivu AllowOverride na hodnotu All, pro umožnění využití souboru.htaccess pro přepisování URL adres. Konfigurace aplikace V rámci konfigurace aplikace je nezbytné nastavit v souboru dvdlevne/application/configs/application.ini parametry pro přístup k databázi. 39

53 40 PŘÍLOHA B. INSTALAČNÍ PŘÍRUČKA

54 Příloha C Uživatelská příručka V této příloze je příručka, která uživateli představí základní funkce aplikace. Přihlášení Pro přihlášení musí uživatel zadat své přihlašovací údaje. Přihlašovací údaje musí uživateli sdělit administrátor nebo manažer, který jeho uživatelský účet vytvořil. Hlavní menu V hlavním menu aplikace jsou tlačítka pro přístup ke všem funkcím systému. V menu jsou zobrazena tlačítka dle role uživatele a jeho práv. Obrázek C. 1: Hlavní menu aplikace Správa uživatelů Na obrazovce správa uživatelů jsou v tabulce vypsáni všichni uživatelé v systému. Na každém řádku s uživatelem jsou o něm uvedeny základní informace, jeho role a ikony pro rychlé smazání či aktivování/deaktivování. Kliknutím na přihlašovací jméno uživatele se otevře dialog pro editaci uživatele. 41

55 42 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA Obrázek C. 2: Správa uživatelů Po kliknutí na tlačítko Přidat uživatele se otevře dialog pro přidání nového uživatele. Obrázek C. 3: Přidat uživatele Správa zákazníků a správa zboží fungují stejně jako správa uživatelů. Přímý prodej Ve formuláři pro přímý prodej je třeba vyplnit obchodního zástupce, který prodej provedl, odběratele, datum vystavení a DUZP, koncové číslo dokladu a u každého druhu zboží počet kusů, které byly prodány. Pro uživatele s rolí OZ je v poli Obchodní zástupce vyplněno jeho jméno a odběratelé jsou omezeni pouze na zákazníky, kteří jsou k danému OZ přiřazeni. Po vyplnění všech položek lze formulář odeslat pomocí tlačítka Uložit. Stisknutím tlačítka Uložit a další se prodej uloží a ihned se otevře nový formulář pro nový prodej.

56 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 43 Obrázek C. 4: Přímý prodej Seznam přímých prodejů V tabulce je vypsána celá historie přímých prodejů. Pro zobrazení detailních informací o prodeji je na každém řádku umístěno tlačítko info. Nad tabulkou jsou uvedeny filtry, kterými lze zobrazit pouze vybrané prodeje. Pod tabulkou je umístěno tlačítko Export do CSV. Tato funkce vyexportuje aktuálně vyfiltrované prodeje do CSV souboru, který nabídne ke stažení. Obrázek C. 5: Seznam přímých prodejů Komisní prodej Formulář pro přidání komisního prodeje funguje převážně stejně jako formulář pro přímý prodej. Navíc je zde nutné vyplnit u každého druhu zboží Počáteční stav dnes, díky kterému lze vypočítat, kolik zboží bylo od posledního prodeje prodáno.

57 44 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA Obrázek C. 6: Komisní prodej Vklady do banky Historie vkladů do banky je opět zobrazena v tabulce. Formulář pro vklad do banky je jednoduchý. Obrázek C. 7: Vklad do banky Vklady do pokladny Vklady do pokladny fungují podobným způsobem jako vklady do banky. Převody zboží OZ sklad a OZ OZ Převody mezi skladem a OZ nebo převody mezi OZ fungují podobným způsobem jako prodeje. Pro převody mezi obchodními zástupci je nutné vyprat OZ zdroj a OZ cíl. Pro převody z/do skladu je třeba určit směr převodu. Poté musí uživatel pro každý druh zboží počet kusů k převodu.

58 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA 45 Obrázek C. 8: Převod zboží mezi OZ Inventura Pro každého OZ v systému je možné provést inventuru k jakémukoli datu v minulosti. Formulář pro novou inventuru je na obrázku Obrázek C. 9: Inventura. U inventury lze označit, zda se má uložit nebo ne. Uložené inventury je možné zpětně zobrazit. Obrázek C. 9: Inventura Reporty Uživatel s rolí manager má přístup k funkci reporty. Zde lze získat tržby v průběhu týdnů či měsíců. Tyto reporty lze opět exportovat do souboru CSV pro další použití například v tabulkovém procesoru. Obrázek C. 10: Reporty

59 46 PŘÍLOHA C. UŽIVATELSKÁ PŘÍRUČKA

60 Příloha D SQL skript pro vytvoření struktury databáze DROP TABLE IF EXISTS `mraza`.`assigned_user`; CREATE TABLE `mraza`.`assigned_user` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_id` int(10) unsigned NOT NULL, `customer_id` int(10) unsigned NOT NULL, `since` datetime NOT NULL, `to` datetime DEFAULT NULL, `relation_type` varchar(20) COLLATE utf8_czech_ci DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`bank_transfer`; CREATE TABLE `mraza`.`bank_transfer` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_id` int(10) unsigned NOT NULL, `proceed_user_id` int(10) unsigned NOT NULL, `date` datetime NOT NULL, `amount` double NOT NULL, `comment` text COLLATE utf8_czech_ci, `created_date` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; 47

61 48 PŘÍLOHA D. SQL SKRIPT PRO VYTVOŘENÍ STRUKTURY DATABÁZE DROP TABLE IF EXISTS `mraza`.`cash_transfer`; CREATE TABLE `mraza`.`cash_transfer` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_id` int(10) unsigned NOT NULL, `proceed_user_id` int(10) unsigned NOT NULL, `date` datetime NOT NULL, `amount` double NOT NULL, `type` varchar(20) COLLATE utf8_czech_ci NOT NULL, `comment` text COLLATE utf8_czech_ci, `created_date` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`customer`; CREATE TABLE `mraza`.`customer` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `super_customer_id` int(10) unsigned DEFAULT NULL, `title` varchar(50) COLLATE utf8_czech_ci NOT NULL, `contact_name` varchar(20) COLLATE utf8_czech_ci DEFAULT NULL, `contact_surname` varchar(30) COLLATE utf8_czech_ci DEFAULT NULL, `street` varchar(25) COLLATE utf8_czech_ci NOT NULL, `city` varchar(25) COLLATE utf8_czech_ci NOT NULL, `postal_code` varchar(6) COLLATE utf8_czech_ci NOT NULL, `ico` varchar(20) COLLATE utf8_czech_ci DEFAULT NULL, `phone` varchar(16) COLLATE utf8_czech_ci DEFAULT NULL, ` ` varchar(50) COLLATE utf8_czech_ci DEFAULT NULL, `active` tinyint(1) NOT NULL, `deleted_date` datetime DEFAULT NULL, `default_discount` float NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`inventory`; CREATE TABLE `mraza`.`inventory` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_id` varchar(45) COLLATE utf8_czech_ci NOT NULL, `amount` double NOT NULL, `date` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;

62 PŘÍLOHA D. SQL SKRIPT PRO VYTVOŘENÍ STRUKTURY DATABÁZE 49 DROP TABLE IF EXISTS `mraza`.`product`; CREATE TABLE `mraza`.`product` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `title` varchar(50) COLLATE utf8_czech_ci NOT NULL, `price` double NOT NULL, `active` tinyint(1) NOT NULL, `deleted_date` datetime DEFAULT NULL, `vat` double NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`product_inventory`; CREATE TABLE `mraza`.`product_inventory` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `inventory_id` int(10) unsigned NOT NULL, `product_id` int(10) unsigned NOT NULL, `count` int(10) unsigned NOT NULL, `count_customers` int(10) unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=35 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`product_transfer`; CREATE TABLE `mraza`.`product_transfer` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `created_user_id` int(10) unsigned NOT NULL, `type` varchar(30) COLLATE utf8_czech_ci NOT NULL, `date` datetime NOT NULL, `created_date` datetime NOT NULL, `duzp_date` datetime DEFAULT NULL, `maturity_date` datetime DEFAULT NULL, `sale_number` varchar(15) COLLATE utf8_czech_ci DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=2287 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;

63 50 PŘÍLOHA D. SQL SKRIPT PRO VYTVOŘENÍ STRUKTURY DATABÁZE DROP TABLE IF EXISTS `mraza`.`store_user_transfer`; CREATE TABLE `mraza`.`store_user_transfer` ( `product_transfer_id` int(10) unsigned NOT NULL, `product_id` int(10) unsigned NOT NULL, `user_id` int(10) unsigned NOT NULL, `count` int(10) NOT NULL, `compensation` tinyint(1) NOT NULL, `order` int(10) unsigned NOT NULL, PRIMARY KEY (`product_transfer_id`,`product_id`,`user_id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`user`; CREATE TABLE `mraza`.`user` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `username` varchar(20) COLLATE utf8_czech_ci NOT NULL, `password` varchar(50) COLLATE utf8_czech_ci NOT NULL, `name` varchar(20) COLLATE utf8_czech_ci DEFAULT NULL, `surname` varchar(30) COLLATE utf8_czech_ci DEFAULT NULL, `street` varchar(25) COLLATE utf8_czech_ci DEFAULT NULL, `city` varchar(25) COLLATE utf8_czech_ci DEFAULT NULL, `postal` varchar(6) COLLATE utf8_czech_ci DEFAULT NULL, `store_number` int(10) unsigned DEFAULT NULL, `last_inventory` datetime DEFAULT NULL, `role` varchar(20) COLLATE utf8_czech_ci NOT NULL, `active` tinyint(1) NOT NULL DEFAULT '1', `deleted_date` datetime DEFAULT NULL, `user_number` varchar(5) COLLATE utf8_czech_ci DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;

64 PŘÍLOHA D. SQL SKRIPT PRO VYTVOŘENÍ STRUKTURY DATABÁZE 51 DROP TABLE IF EXISTS `mraza`.`user_customer_transfer`; CREATE TABLE `mraza`.`user_customer_transfer` ( `product_transfer_id` int(10) unsigned NOT NULL, `user_id` int(10) unsigned NOT NULL, `customer_id` int(10) unsigned NOT NULL, `product_id` int(10) unsigned NOT NULL, `type` varchar(20) COLLATE utf8_czech_ci NOT NULL, `product_count_detected` int(10) DEFAULT NULL, `count` int(10) NOT NULL, `price` double NOT NULL, `vat` double NOT NULL, `order` int(10) unsigned NOT NULL, `discount` double NOT NULL, `sold_count` int(10) DEFAULT NULL, PRIMARY KEY (`product_transfer_id`,`user_id`,`customer_id`,`product_id` ) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`user_leader`; CREATE TABLE `mraza`.`user_leader` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_id` int(10) unsigned NOT NULL, `leader_user_id` int(10) unsigned NOT NULL, `since` datetime NOT NULL, `to` datetime DEFAULT NULL, `relation_type` varchar(20) COLLATE utf8_czech_ci DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=11 DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci; DROP TABLE IF EXISTS `mraza`.`user_user_transfer`; CREATE TABLE `mraza`.`user_user_transfer` ( `product_transfer_id` int(10) unsigned NOT NULL, `source_user_id` int(10) unsigned NOT NULL, `destination_user_id` int(10) unsigned NOT NULL, `product_id` int(10) unsigned NOT NULL, `count` int(10) NOT NULL, `order` int(10) unsigned NOT NULL, PRIMARY KEY (`product_transfer_id`,`source_user_id`,`destination_user_i d`,`product_id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;