Návrh objednávkového modulu pro pokladní systém

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh objednávkového modulu pro pokladní systém Diplomová práce

Vedoucí práce: doc. Ing. Oldřich Trenz, Ph.D.

Brno 2016

Bc. Lukáš Zachoval

Zadání diplomové práce.

Poděkování Tímto bych chtěl poděkovat panu doc. Ing. Oldřichu Trenzovi, Ph.D. za poskytnutí cenných rad a informací při tvorbě diplomové práce. Děkuji také rodině a všem za podporu během studia.

Čestné prohlášení Prohlašuji, že jsem práci: Návrh objednávkového modulu pro pokladní systém vypracoval samostatně a veškeré použité prameny a informace uvádím v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 20. května 2016

_______________________________

Abstract ZACHOVAL, L., Design of order module for POS system. Master thesis. Brno: Mendel University in Brno, 2016. The thesis deals with analysis of available POS systems. They are investigated options of ordering using several tools. Subsequently a design of the order module is created and implemented. The resulting application is available via web. Keywords POS system, delivery, orders, PHP, MySQL, analysis, design, implementation.

Abstrakt ZACHOVAL, L., Návrh objednávkového modulu pro pokladní systém. Diplomová práce. Brno: Mendelova univerzita v Brně, 2016. Práce se zabývá analýzou dostupných pokladních systému. Jsou zkoumány možnosti objednávání za pomoci několika nástrojů. Následně je proveden návrh objednávkového modulu, který je implementován. Aplikace je dostupná přes webové prostředí. Klíčová slova Pokladní systém, rozvoz, objednávky, PHP, MySQL, analýza, návrh, implementace.

Obsah

6

Obsah 1

2

3

4

Úvod a cíl práce

11

1.1

Úvod .......................................................................................................................................... 11

1.2

Cíl práce ................................................................................................................................... 11

Metodika práce

13

2.1

Úvod do metodiky ............................................................................................................... 13

2.2

Specifikace metodiky v bodech ..................................................................................... 13

Pokladní systémy

15

3.1

Skladové hospodářství...................................................................................................... 15

3.2

Ceníkové položky ................................................................................................................ 19

3.3

Uskutečnění prodeje .......................................................................................................... 21

3.4

Hardware a periferie ......................................................................................................... 22

Zkoumané společnosti

23

4.1

ABX software s.r.o. .............................................................................................................. 24

4.2

AGNIS s.r.o. ............................................................................................................................. 26

4.3

Amax com s.r.o. .................................................................................................................... 28

4.4

ASW Systems a.s. ................................................................................................................. 30

4.5

AWIS Holding, a.s. ............................................................................................................... 32

4.6

CÍGLER SOFTWARE, a. s. .................................................................................................. 34

4.7

Dotykačka s.r.o. .................................................................................................................... 35

4.8

i-Technologies s.r.o............................................................................................................. 37

4.9

Origin Soft s.r.o. .................................................................................................................... 38

4.10 PROFIREST s. r. o................................................................................................................. 39 4.11 QPOS systems s.r.o.............................................................................................................. 41 4.12 Smart software s.r.o. .......................................................................................................... 43 4.13 storyous.com s.r.o. .............................................................................................................. 45 4.14 Vectron Systems CZ s.r.o. ................................................................................................. 47 4.15 WinShop Software s.r.o. ................................................................................................... 48

Obsah

5

Analýza 5.1

6

7

Hloubková analýza ............................................................................................................. 52

5.1.1

Rozvoz ........................................................................................................................... 52

5.1.2

Propojení s www ...................................................................................................... 54

5.1.3

Propojení s damejidlo.cz ........................................................................................ 58

Návrh 6.1

Specifikace požadavků ...................................................................................................... 59 Funkční požadavky .................................................................................................. 59

6.1.2

Nefunkční požadavky.............................................................................................. 59

Funkční model ...................................................................................................................... 60

6.2.1

Kontextový diagram ................................................................................................ 60

6.2.2

Systémový diagram.................................................................................................. 61

6.3

Datový model ........................................................................................................................ 62

6.3.1

Entitně relační model .............................................................................................. 62

Implementace 7.1

66

Pohled administrátora ...................................................................................................... 66

7.1.1

Rozvozci ........................................................................................................................ 66

7.1.2

Objednávky .................................................................................................................. 67

7.1.3

Mapa k rozvozu.......................................................................................................... 68

7.1.4

Nabídka ......................................................................................................................... 68

7.1.5

Zákazníci ....................................................................................................................... 68

7.1.6

Statistika ....................................................................................................................... 69

7.2

8

59

6.1.1 6.2

7

49

Pohled rozvozce ................................................................................................................... 70

7.2.1

Objednávky .................................................................................................................. 70

7.2.2

Mapa k rozvozu.......................................................................................................... 71

7.2.3

Nabídka ......................................................................................................................... 72

7.2.4

Zákazníci ....................................................................................................................... 72

7.2.5

Statistika ....................................................................................................................... 73

Závěr 8.1

74

Ekonomické zhodnocení .................................................................................................. 75

Obsah

8

9

Literatura

77

A

CD

81

Seznam obrázků

9

Seznam obrázků Obr. 1

Hlavní obrazovka ABX software s.r.o.

25

Obr. 2

Hlavní obrazovka AGNIS s.r.o.

27

Obr. 3

Hlavní obrazovka Amax com s.r.o.

29

Obr. 4

Hlavní obrazovka ASW Systems a.s.

31

Obr. 5

Hlavní obrazovka AWIS Holding, a.s.

33

Obr. 6

Hlavní obrazovka CÍGLER SOFTWARE, a. s.

34

Obr. 7

Hlavní obrazovka Dotykačka s.r.o.

36

Obr. 8

Hlavní obrazovka i-Technologies s.r.o.

37

Obr. 9

Hlavní obrazovka Origin Soft s.r.o.

38

Obr. 10

Hlavní obrazovka PROFIREST s. r. o.

40

Obr. 11

Hlavní obrazovka QPOS systems s.r.o.

42

Obr. 12

Hlavní obrazovka Smart software s.r.o.

44

Obr. 13

Hlavní obrazovka storyous.com s.r.o.

46

Obr. 14

Hlavní obrazovka Vectron Systems CZ s.r.o.

47

Obr. 15

Hlavní obrazovka WinShop Software s.r.o.

48

Obr. 16

Možnosti připojení mobilního telefonu

53

Obr. 17

Propojení s www

57

Obr. 18

Kontextový diagram

60

Obr. 19

Systémový diagram

61

Obr. 20

Entitně relační diagram

63

Obr. 21

Moduly administrátora

66

Obr. 22

Správa uživatelů

67

Seznam obrázků

10

Obr. 23

Nabídka sortimentu

68

Obr. 24

Statistika administrátora

69

Obr. 25

Moduly rozvozce

70

Obr. 26

Objednávky

71

Obr. 27

Mapa k rozvozu

72

Obr. 28

Zákazníci

72

Úvod a cíl práce

11

1 Úvod a cíl práce 1.1

Úvod

V dnešní moderní době je nutné v co nejkratší době reagovat na požadavky zákazníků. Někdy o výsledné spokojenosti rozhodují i minuty. Jeden z důvodů, proč se zákazníci vrací ke stejnému dodavateli je jejich spokojenost. Na trhu je celá řada systémů, které pomáhají s odbavením zákazníků, nicméně každý z nich má své klady a zápory. Ideálním stavem by byl systém, který by pokryl veškeré požadavky. Prakticky není možné obsáhnout všechny požadavky, které by tvořily jeden systém. Je možné navrhnout systém, který, bude rozdělen do modulů, které mezi sebou budou vzájemně komunikovat. V daném objednávkovém procesu je obsaženo mnoho subjektů a aspektů, které mohou výsledek jakkoliv ovlivnit. Jedním prvkem je forma objednávky, která celý objednávkový proces spouští. Objednávkový proces bude dopodrobna rozebrán v následujících odstavcích.

1.2 Cíl práce Cílem diplomové práce je provést analýzu dostupných variant pokladních systémů a navrhnout obecné řešení objednávkového modulu, které bude možné implementovat do každého ze zkoumaných subjektů. Bude vysvětlena základní logika pokladních systému, přes skladové hospodářství, vytvoření složení, směsí, ceníkových skupin, přiřazení položek k danému účtu až po vytisknutí dokladu. Součástí bude i grafická reprezentace pro jednodušší pochopení. Poté proběhne analýza českého trhu s pokladními systémy. Bude vybráno několik společností, které nabízí pokladny. U každého subjektu budou zmíněny jeho přednosti, které budou dopodrobna rozebrány. Bude tedy vysvětlena základní logika pokladních systému, což ocení čtenáři, kteří zatím nemají žádné zkušenosti s pokladnami. Následně nad vybranými subjekty proběhne analýza, která vyčlení ty, které mají v sobě implementovanou jakoukoliv možnost objednávky, která je alespoň částečně automatizovaná. Součástí kapitoly bude i vysvětlení možností objednávkového procesu, kde bude celý proces dopodrobna rozebrán a podrobně vysvětlen. Po obecné analýze proběhne hloubková analýza vybraného celku, což bude dopodrobna rozebráno. Budou objasněny současné principy a následně navrženy možnosti rozšíření či vylepšení, které bude možné aplikovat na jakýkoliv systém. Na základě analýzy proběhne návrh a implementace navrženého řešení. Navržené řešení bude obecné, tedy ho bude moci implementovat jakákoliv společnost. Návrh bude proveden za pomoci obecných principů, které budou vyobrazeny pomocí diagramů. Pokud bude chtít jakákoliv společnost použít navržené řešení, bude vycházet z obecných diagramů. Další možností bude použít implementovaný kód, který bude funkční na základě dané analýzy, nicméně bude nutné přizpůsobit zdrojový kód na základě struktury databáze, jelikož každý pokladní systém má jinou strukturu databáze.

Úvod a cíl práce

12

Na závěr bude navržené řešení zhodnoceno jak slovně, tak ekonomicky. Součástí bude i doporučení pro další rozvoj, které bude možné v praxi navrhnout a následně implementovat.

Metodika práce

13

2 Metodika práce 2.1 Úvod do metodiky Nejprve bude vysvětlen základní koncept pokladních systému, za pomoci knižních a internetových zdrojů. Poté bude provedena analýza českého trhu s pokladními systémy pomocí internetových zdrojů. Bude vybráno několik společností, které působí na našem území. Za pomoci internetových zdrojů budou u každé zkoumané společnosti vysvětleny některé jejich vlastnosti. Budou stanovena celkem 3 kritéria, která budou dopodrobna rozebrána u zkoumaných společností. Pro zjištění stanovených kritérií budou použity informace z internetových zdrojů. Jako kritéria šetření bylo zvoleno, jestli daná společnost nabízí alespoň částečně automatizovanou formu rozvozové objednávky, dále propojení objednávkového systému za pomoci webového rozhraní s pokladním systémem a propojení s webovým portálem damejidlo.cz. Výsledky šetření budou reprezentovány tabulkou. Výsledky této analýzy budou použity pro samotný návrh daného řešení. Návrh bude zachycen za pomoci kontextového a systémového diagramu. Oba diagramy budou slovně okomentovány. Bude použit databázový server MySQL. Struktura databáze bude zachycena pomocí entitně relačního diagramu. Nad touto databází dojde k implementaci aplikace ve webovém prostředí. Bude využito HTML, PHP, JavaScript. Jako podkladové mapy budou použity Google Maps. Navržené řešení bude obecné, což znamená, že bude možné použít u jakékoliv zkoumané společnosti. Následně bude provedeno zhodnocení celkové práce, jak po finanční stránce, tak i po funkční.

2.2 Specifikace metodiky v bodech 1.

Průzkum českého trhu s pokladními systémy.

2.

Analýza dostupných řešení.

3.

Vybrání společností, které budou zkoumaným vzorkem. Omezující podmínkou bude implementace alespoň 50pokladen.

4.

U každé společnosti ze zkoumaného vzorku budou vysvětleny vybrané vlastnosti.

5.

Proběhne stanovení kritérií pro další výzkum.

6.

Kritéria budou stanovena: 6.1. Jakákoliv forma rozvozové objednávky, která je alespoň částečně automatizovaná. 6.2. Propojení s webovým serverem, tedy jestli je propojen pokladní systém s www stránkami.

Metodika práce

14

6.3. Provázání objednávkového serveru damejidlo.cz s pokladním systémem. 7.

Dojde k ověření kritérií u každého prvku ze zkoumaného souboru.

8.

Výsledky analýzy budou shrnuty tabulkou.

9.

Na základě analýzy dojde k obecnému návrhu.

10.

Při návrhu bude využit kontextový digram a systémový diagram.

11.

Struktura databáze bude zachycena za pomoci entitně relačního diagramu. Databázový server bude MySQL.

12.

Implementace dle navrženého řešení. Bude použito HTML, PHP, JavaScript, MySQL. Jako podkladové mapy budou použity Google Maps.

13.

Závěr práce, tedy celkové shrnutí navrženého a implementovaného řešení. Zhodnocení bude jak po ekonomické, tak po funkční stránce.

Pokladní systémy

15

3 Pokladní systémy Pokladní systém je v dnešní době centrálním zdrojem informací. Shrnují informace z pokladen, které ukládají informace o skladovém hospodářství, cenách, uložených zákaznicích a poskytují ucelený obraz o prodejích v daném subjektu. Pokladní systém může být distribuován jen jako systém pro markování, bez skladového hospodářství nebo jako celek, který obsahuje i informace o pohybech na skladě. Také je možné mezi sebou propojit více systémů od různých dodavatelů, přičemž každý se specializuje na vybranou část a v případě propojení tvoří ucelený pokladní systém. Pokladnu je možné propojit s řadou periférií. V maloobchodech bývá nejčastěji využívána čtečka čárových kódů a zákaznický displej. V případě čtečky čárových kódů se využívá technologie EAN, kde musí být každý produkt označen čárovým kódem, který obsluha přiloží ke čtečce čárových kódů a pokladní systém načte informaci daného produktu. Na základě porovnání s databází zobrazí na zákaznickém displeji a monitoru název a cenu produktu. Tato technologie přinesla značné zrychlení odbavování zákazníků, jelikož obsluha nemusí znát daný produkt a jeho cenu (Mulačová a kol., 2013). Skladové hospodářství je důležitou součástí pokladního systému, kde je možné zjistit aktuální stav zásob a na základě toho stavy skladů regulovat. V případě propojení s dodavateli zásob je možné automaticky zasílat reporty, na které je schopen dodavatel reagovat zvýšením či snížením dodávaných surovin. Sklad je vhodné dělit dle skladových skupin a ke každé skladové položce i vybrat dodavatele. Nedílnou součástí maloobchodů je i propojení s váhou. Po zvážení zboží musí obsluha ručně vybrat ze seznamu zboží nebo načíst čárový kód z papírového seznamu. Profesionální čtečky čárových kódů v sobě mají již zahrnutou váhu zboží, jedná se o všesměrové čtečky. V dnešní době je již samozřejmostí přítomnost platebního terminálu. Některé pokladní systémy jsou propojeny, tedy se částka k zaplacení automaticky zobrazí na platebním terminálu, některé ne, tedy je nutné částku zadat. Pokladní systém tvoří ucelený pohled na veškeré transakce v daném subjektu (Mulačová a kol., 2013).

3.1 Skladové hospodářství Skladové hospodářství slouží k evidenci stavu zásob na skladě. Informace o stavech a obrátkovosti jsou důležité z hlediska nákupu. Pro jednodušší plánování slouží zmíněné skladové hospodářství, kde jsou uloženy veškeré informace o dané skladové položce. Integrace má přinést celkové snížení nákladů na provoz (Synek a kol., 2010). Skladovou evidenci není nutné v pokladním systému využívat, nutností je mít zavedené ceníkové položky, nicméně v subjektech, jako jsou restaurace, je to vhodné z důvodů inventarizace skladových položek. Pro vytvoření nové skladové položky bývá nejčastěji nutností uvést číslo skladové položky, které bývá generováno automaticky, tedy se automaticky zvolí číslo, které není v databázi ještě obsaženo. Samozřejmě je číslo možné ručně změnit, nicméně při uložení je

Pokladní systémy

16

číslo zkontrolováno, zdali není v databázi již obsaženo. Dalším povinným atributem je název skladové položky. Při vytváření je vhodné dbát jednotného stylu, což se později ocení při vyhledávání. Nutností je výběr měrné jednotky, tedy v jakých jednotkách budeme dané zboží evidovat, nejčastěji se jedná o evidenci v kusech, litrech a případně v kilogramech. Doporučuje se i zadání doporučeného množství, což v praxi znamená, že pokud skladová položka klesne pod zadané minimum, tak systém automaticky upozorní, že je vhodné danou položku zakoupit. Tento atribut je nepovinný, nicméně v praxi hojně využívaný pro minimalizaci nedostatku zboží. Je zde kladen důraz i na výběr DPH, tedy jaké DPH je při nákupu dané skladové položky, což se promítá při naskladnění. Mnoho pokladních systémů umožňuje sklad rozdělit do jednotlivých skupin, které slouží pro lepší identifikaci a pro vytváření dílčích inventur. Pokročilejší systémy nabízejí i více skladů, kde využití ocení podniky, které mají více částí, tedy více pokladen a u každé pokladny chtějí mít oddělené sklady, ale aby odtěžování ze skladu bylo ze společné databáze (Máče, 2012). Dalšími nepovinnými atributy bývá výběr dodavatele a čárový kód skladové položky. Uvedení dodavatele slouží pro lepší orientaci a komunikaci s dodavateli. Uživatel vidí, od jakého dodavatele zboží odebírá, tedy je schopen ihned dodavateli zaslat potřebnou objednávku zboží elektronicky. Současně se vede i evidence odebraného zboží od daného dodavatele. Čárový kód se používá nejčastěji pro rychlé vyhledání mezi skladovými položkami nebo při inventarizaci. Po vytvoření skladové položky je možné se skladovou položkou pracovat. Je možné upravit danou položku, tedy změnit veškeré zadané atributy, přidat položku do směsí, provázat ji s ceníkovou položkou, naskladnit dané zboží, provést odpis položky, provést inventuru. Aby bylo možné skladovou položku vyskladnit, je nutné ji provázat s ceníkovou položkou, jinak prodej není možné uskutečnit. Prodeji nejčastěji předchází naskladnění dané položky, tedy její zavedení na sklad. Při vytváření příjemky se zadávají položky z dodacího listu od dodavatele, tedy se ručně vybírají skladové položky, uvede se naskladňované množství a daná cena. U položek, u kterých je evidována i doba spotřeby, tak je možné uvést i dobu spotřeby, přičemž systém automaticky upozorní, že se blíží doba spotřeby a může dojít ke zlevnění. Po zadání ceny se automaticky doplní DPH, které je zadáno u skladové položky. Cena slouží poté pro vypočítání nákladovosti jednotlivých ceníkových položek. U většiny systému není nutnost položky vybírat ze seznamu, ale použít čtečku čárových kódů a po nascanování EAN kódů se položka automaticky v seznamu vyhledá a uživatel musí zadat množství a cenu. Je možné nastavit automatické předvyplňování cen, což nám dává pohled, jestli dochází ke zdražení či zlevnění dané položky. Na základě toho je možné reagovat na prodejní ceny. Předvyplněná cena při příjemce bývá nejčastěji poslední cena při naskladnění nebo průměrná cena vypočtená ze všech příjemek, na kterých byla uvedena daná položka (Novotný, 2016). Po zavedení všech položek uvedených na dodacím listu se přepočítá aktuální množství na skladě a aktuální nákladové ceny. Pokud pokladní systém umožňuje

Pokladní systémy

17

načtení QR kódu z dodacího listu, provede se naskladnění automaticky. Pokladní systém musí být kompatibilní se systémem, ve kterém byl vystaven dodací list. Druhou možností je automatické naskladnění za pomocí csv souboru, který má předem stanovený formát a po načtení souboru se provede naskladnění, které obsahuje skladové položky, které dodavatel uvedl na dodacím listu. Nutností je i zpětná úprava nebo smazání příjemky v případě zjištění nesouladu s dodacím listem. V případě změny nebo smazání je nutné dbát na to, aby došlo k přepočtu všech atributů spojených s naskladněním. V případě, že zboží je fyzicky na skladě, ale nedošlo ještě k naskladnění do pokladního systému, je možné prodej provést, jelikož pokladní systém umí skladové hospodářství vést i do záporné hodnoty, s tím že po naskladnění se hodnota automaticky srovná. U skladové položky je množství možné změnit naskladněním, tedy příjemkou, prodejem, inventurou a odpisem. Skladové položky je možné seskupovat, čímž vytváříme předdefinované receptury. Tyto receptury definuje uživatel, který uvede označení dané skupiny a zadává jednotlivá množství skladových položek, ze kterých se skupina sestavuje. Jako příklad bych uvedl recepturu, kterou označíme jako těsto na pizzu. Těsto na pizzu se skládá z několika skladových položek. Aby v ceníku nebylo nutné u každé varianty pizzy zadávat vždy složení těsta na pizzu, tak si předdefinujeme danou recepturu, kterou poté můžeme v ceníku využít jako základ, který rozšíříme o suroviny, které jsou na dané položce navíc. U každé receptury je automaticky vypočítaná i nákladovost, která je vypočtena z průměrných nákupních cen, které uživatel zadává při naskladnění. V případě zničení, vypršení trvanlivosti skladové položky je k dispozici odpisování skladu, které mění množství skladových položek. V případě odpisu se vybere daná skladová položka a zadá se odepisované množství a důvod odpisu. V případě restaurace, kde může nastat, že již připravený pokrm neodejde z nějakého důvodu k zákazníkovi, je možné provést odpis dané ceníkové položky, jelikož by bylo potřeba odepsat jednotlivě dané suroviny, z kterých se ceníková položka, tedy pokrm skládá. Nedílnou součástí pokladního systému je i systém pro inventarizaci skladových položek. V případě provádění inventury obsluha nebo manažer zadává do systému stavy, které skutečně na skladě napočítal. V případě rozdílů systém automaticky vyhodnotí nedostatek či nadměrné množství skladové položky. Součástí inventury je i přepočtení na nákladové ceny dle průměrných cen vypočtených z příjemek. Tato forma inventury bývá prováděna nejčastěji. Obsluha počítá a manažer rovnou zadává stavy do pokladního systému. V případě neúčasti manažera provede obsluha fyzickou kontrolu papírově, kterou následně manažer zadá do systému. Zadání ale musí být provedeno zpětně, jelikož nastal již pohyb na skladě, tedy by došlo k značnému rozdílu na skladě. Z tohoto důvodu mívají pokladní systémy implementovanou možnost zpětné inventury, neboli inventury na datum (Louša, 2012). Pověřená osoba vybere datum provedení inventury, tedy datum a čas, kdy obsluha fyzicky prováděla inventuru a následně dojde k zobrazení stavů na skladě,

Pokladní systémy

18

které byly k danému času a datu. Po zadání inventury do systému musí dojít k přepočítání aktuálního stavu vzhledem k prodeji mezi fyzickou inventurou a inventurou zadanou do pokladního systému. Tato operace je velice složitá, jelikož mohlo dojít k odpisům u skladové položky nebo k naskladnění nového zboží a v případě evidence doby trvanlivosti může dojít k celkovému posunu. Pokud ve skladovém hospodářství využijeme možnost rozdělení skladu do jednotlivých skupin, tak je možné jednoduchým způsobem udělat část inventury. Nejčastěji se skladové hospodářství dělí na bar a kuchyni, přičemž inventura baru se dělá mnohem častěji jak inventura kuchyně. Manažer tedy zahájí inventuru a filtrem vybere, že chce jen skladové položky, které náleží na bar nebo do kuchyně. V případě více skupin vybere, u kterých skupin chce provádět inventuru. Toto rozdělení ocení většina subjektů, jelikož je jednoduchým způsobem schopna vyexportovat danou skupinu skladu a předá formulář obsluze, která jej vyplní. V případě, že některá skladová položka klesne pod definované minimum, tak je manažer upozorněn o docházejícím zboží. V případě komplexních systémů může být dodavatel automaticky informován o nedostatku daného zboží na provozovně. U většiny ale musí být daný proces proveden automaticky, tedy zobrazení všech položek, které se nacházejí pod stanovenou hranicí a následné použití filtru, který vyselektuje položky jen od zvoleného dodavatele. Jednou z variant je přiřazení dodavatele přímo u skladové položky. U některých surovin se ale častěji mění dodavatelé, tak není nutné u skladové položky přiřazovat dodavatele, ale při naskladňování zboží se vybere dodavatel ze seznamu. Následně je u skladové položky zobrazen poslední dodavatel, u kterého proběhl nákup. Jak již bylo zmíněno, některé subjekty mohou mít oddělené databáze, což v praxi znamená, že každá pokladna si žije svým vlastním životem, tedy má každá i své vlastní skladové hospodářství. Nevýhodou ale bývá, že nákup skladových surovin bývá pro všechny pokladny společný, tedy je jen jeden dodací list. Pokud bychom provedli částečné naskladnění na jedné z pokladen, poté na další, tak by mohlo dojít k chybovosti a už není možné jednoduchým způsobem zkontrolovat příjmový doklad s příjemkou. Z tohoto důvodu mají pokročilé systémy možnost rozdělení skladů v kombinaci s hlavní pokladnou. Druhou variantou je možnost přeskladňovat zboží mezi jednotlivými provozy. V případě hlavní pokladny je vícero databází na jednom zařízení a jedna společná, která slouží pro naskladňování daných surovin. Při naskladňování může být vybráno, na kterou z pokladen příjde dané zboží, případně kolik množství z celkově naskladňovaného. V případě naskladnění veškerého zboží na server je poté nutné přesunout položky na jednotlivé pokladny. V obou případech se přesunuté zboží nachází v tzv. meziskladě, jelikož ještě nedošlo k potvrzení na jednotlivých pokladnách. Potvrzení musí provést manažer na cílové pokladně. Je to z toho důvodu, že by někdo mohl omylem přeskladnit položky, které fyzicky přesunuty nebyly. Následně by byl zjištěn schodek při inventarizaci, za kterou samozřejmě odpovídá personál.

Pokladní systémy

19

V případě neserverového řešení je princip obdobný. Není ale možné rovnou při vytváření příjemky přeskladňovat na dané pokladny, ale vytvoří se příjemka na jednu z vybraných pokladen. Následně manažer provede ruční přeskladnění na jednotlivé pokladny. Poté musí osoba odpovědná za pokladní systém příjemku potvrdit, čímž provede naskladnění. V případě zamítnutí se provede veškeré naskladnění na pokladnu, z které bylo zboží odesláno. Na kořenové i cílové stanici je možné nahlédnout do příjemek, které byly odeslány na dané pokladny a naopak na příjemky, které byly zaslány z jiných pokladen. Některé pokladní systémy v sobě nemají nutnost potvrzení přijatého zboží, což může generovat neshody ve skladovém hospodářství. Jakmile dojde k provázání skladové položky s ceníkovou, tak dochází k odtěžování množství ze skladu. Pokud je odtěžování správně nastaveno, tak je možné nahlédnout na jednotlivé skladové položky a jejich pohyby. Z pohybů je možné vypozorovat, jakým způsobem dochází k odtěžování, kdy nejčastěji a v jakém množství. Tato statistika je důležitým nástrojem pro všechny subjekty. Jsou v ní zachyceny informace o naskladnění, odtížení prodejem či odpisem. Skladové hospodářství je nedílnou součástí pokladních systémů, ač některé podniky sklad neevidují, z důvodu úspory času. Z mého pohledu pokud se jedná o subjekt zaměstnávající více osob, je skladové hospodářství nutností evidovat, jak pro vlastní potřebu, tak i pro potřebu zaměstnanců.

3.2 Ceníkové položky Pro prodej je nutné mít založenou tzv. ceníkovou položku. Ceníková položka bývá zpravidla propojena se skladovým hospodářstvím, ač to není nutnost. V případě vytváření nové ceníkové položky je požadováno PLU, což je jednoznačný identifikátor ceníkové položky. Tato hodnota bývá generována automaticky, jak je tomu v případě skladové položky, nicméně je možné změnit její hodnotu, ale nesmí být hodnota použita u jiné položky. Díky PLU je poté možné jednoduchým kódem vyhledávat ceníkové položky. Subjekty, které dříve využívaly registrační pokladny, tak měly nazpaměť naučené kódy, které představovaly jednotlivé ceníkové položky. Proto je využití PLU nedílnou součástí. Některé subjekty již své produkty znají a nevyhledávají v jednotlivých skupinách, ale rovnou napíši kód zboží, čím jej ihned vyhledají a přiřadí k danému stolu. Dalším atributem je název ceníkové položky. Je nutné dbát na typografii, jelikož se daný název tiskne i na účtence, tedy dokladu, který předáváme zákazníkovi. Nutností je výběr jednotky, v které budeme položku prodávat. Nejčastěji se jedná o kusy nebo kilogramy. V některých případech je možné nastavit i tzv. časovou jednotku. Časová jednotka slouží pro různá centra, u kterých se hradí služba za strávený čas. Je vytvořen zákazník a po namarkování časové položky se začne počítat čas. Následně se čas automaticky přepočítává na částku k úhradě. Nastavení přepočtu je závislé na manažerovi. Může být přepočet po minutách nebo po hodinách. Dále pokud zákazník opouští objekt, vytiskne se účet, který má

Pokladní systémy

20

zobrazen čas strávený v objektu. Pokud se přiřadí kusová jednotka, tak je prodáváno na kusy, což je v případě nápojů, jídla apod. Kilogramová jednotka se využívá nejčastěji v maloobchodě, kdy je nutné zadat cenu za kilogram a následně pomocí připojené váhy zvážíme surovinu. Na obrazovce vidíme váhu a po namarkování dané položky se váha přepočte s cenou zadanou za kilogram. Současně je nutné i vybrat z hladin DPH, které se tiskne na účtence. Na základě zadaného DPH se tiskne vypočtené DPH a základ DPH, který je rozdělen dle jednotlivých hladin. V případě subjektu, který rozváží svůj sortiment, je nutné u některých ceníkových položek zvolit neměnné DPH. V České republice je možné na potraviny a nealkoholické nápoje aplikovat 15% DPH, pokud konzumace neprobíhá v prostorách subjektu. U těchto položek nebudeme mít zvoleno neměnné DPH. V případě, že pokladní systém nenabízí neměnné DPH, tak je nutné vytvořit dvakrát ceníkové položky, které budou jiným způsobem identifikovány a budou mít zvolenou jinou hladinu DPH (Havit, s.r.o., [online]). Dalším důležitým atributem je přiřazení ceníkové položky do dané skupiny. Skupiny slouží obsluze k rychlejšímu nalezení v daném sortimentu. Například bývá dělení, polévky, hlavní jídla, nápoje apod. Pokud je veškerý sortiment přiřazen v jedné skupině, je hledání v seznamu poněkud chaotické. V případě maloobchodů, kde k naúčtování používají čtečku čárových kódů, tak je rozdělování do skupin zbytečné. Další dělení, které je v ceníku vhodné, tak je dělení z důvodu tisku uzávěrky dle jednotlivých skupin. Uzávěrku je možné vytisknout na základě ceníkových skupin, které slouží pro lepší orientaci obsluhy. V praxi ale bývá častěji využíváno dělení na bar a kuchyň, tedy na konci dne vyjede uzávěrka rozdělená na jednotlivé úseky, tedy na bar a kuchyň. Jako další nepovinný atribut je příznak, zdali je možné na položku aplikovat slevu. Sleva je jedna z forem odměňování věrných zákazníků a v některých případech může být sortiment, u kterého chceme zakázat možnost slevy. Bývá to z toho důvodu, že sleva se aplikuje na celý účet a není v silách obsluhy ručně vybírat na co se má sleva aplikovat a na co ne. Takto se automaticky sleva aplikuje jen na takové položky, které manažer povolil v ceníku. Pokud bychom nově vytvořenou položku uložili, tak bychom prodej uskutečnit mohli, nicméně by neproběhlo odtěžování ze skladu. Ještě před uložením je vhodné nastavit propojení skladu a ceníku. Samozřejmostí je zpětné upravení jak ceníkové položky, tak i nastavení propojení se skladovým hospodářstvím. V případě propojení se nastavuje provázání na jednu jednotku prodeje, tedy nejčastěji na jednu porci, jeden kus. Je možné využít zmíněných receptur, tedy uživatelem předdefinovaných složení. V případě, že receptury jsou nadefinované na deset porcí, tak v ceníku vybereme dané složení a zvolíme množství 1/10, tedy 0,1. V případě, že se jedná o položku, která je ve skladovém hospodářství uložena v kilogramech, uvedeme jaké množství se odtěžuje ze skladu. Pokud bychom uvedli 1, došlo by k odtěžení 1 kilogramu ze skladu a už by docházelo k mylným pohybům na skladě. Proto je vždy nutné veškeré nastavení

Pokladní systémy

21

zkontrolovat, aby byly receptury nastaveny správně. Pokud chceme ze skladu odtěžit 50 gramů, zadáme 0,05. Surovin, které se při namarkování daného pokrmu mají odtěžit, můžeme zadat nespočetné množství. Urychlení nám přinesou uživatelem definované receptury, nicméně je nutné vždy zvážit, zdali je možné recepturu využít u více ceníkových položek. Pokud ne, je zbytečné ji vytvářet, docházelo by k duplikování práce. Nutným atributem je zadání prodejní ceny. V případě více měň se druhý kurz přepočítá automaticky, ovšem záleží na nastavení. Druhý kurz je možné také zadat ručně. Další cenovou hladinu, kterou je možno zadat, je cena pro zaměstnance, případně pro zákazníky s možností snížené ceny. Jedná se o tzv. cenu pro personál. Jako cena pro personál se automaticky propíše standardní cena, tedy prodejní cena, nicméně manažer může cenu upravit. Následně po vytvoření personálního účtu v pokladně a namarkování položky dojde ke změně ceny, tedy obsluha má nárok na snížené ceny v restauraci. Vždy jen záleží na vedení, u kterých ceníkových položek provede snížení cen. Některé pokladní systémy umožňují u položek evidovat dva názvy. První název, který se tiskne zákazníkovi na účtenku, druhý název je název pro obsluhu a pro kuchyni. Jelikož jsou zvyklí používat zkratkové názvy pokrmů, tedy vyhledávání v pokladně probíhá buď ručně, tedy pomocí zkratky, PLU nebo pomocí rozkliknutí dané ceníkové skupiny a nalezení příslušné položky. Současně se zkrácený název vytiskne i kuchaři do kuchyně. Pokud jsou vytvořeny ceníkové položky a je nastaveno propojení se skladovým hospodářstvím, tak je možné začít prodávat pomocí pokladního systému. Jak již bylo ale zmíněno, propojení se skladovým hospodářstvím není nutností k prodeji položek.

3.3 Uskutečnění prodeje V části, ve které byl vytvářen sklad a ceník, tak do ní mají přístup manažeři nebo osoby mající příslušná práva. Uskutečnění prodeje probíhá pomocí pokladního systému. Účty, na které obsluha provádí markování se označují jako stoly. V maloobchodě většinou bývá jen jeden účet, protože bývá zpravidla v jeden okamžik odbaven jen jeden zákazník. Některé pokladní systémy umějí rozdělaný účet zaparkovat a obsloužit dalšího zákazníka. Poté se vrátí k rozdělanému účtu. V restauracích bývá účtů zpravidla více, které se ještě dělí do jednotlivých sekcí, úseků. Jednotlivé účty bývají označeny číslicemi, které odpovídají fyzickému označení stolů v daném úseku. Úseky mohou být například rozděleny na restauraci, terasu, personál apod. Každý úsek poté obsahuje jednotlivé stoly. Reprezentace jednotlivých stolů bývá různá. Některé systémy zobrazují účty (stoly) jako seznam po sobě jdoucích účtů, některé nabízejí tzv. mapu podniku. Mapu podniku je možné nadefinovat vlastním způsobem, což přináší pohled z perspektivy. Toto rozložení je graficky pro obsluhu přijatelnější, především oceňují noví zaměstnanci, kteří se s prostory teprve seznamují. Mapa bývá

Pokladní systémy

22

zpravidla rozdělena do jednotlivých úseků, jelikož grafické zachycení celkové restaurace by bylo na obrazovce velice malé a nepřehledné. Pokud se zákazník rozhodne zaplatit, obsluha vybere daný účet a zvolí zaplatit účet, což musí následně ještě jednou potvrdit. Než provede potvrzení bývá několik možností k výběru. Pokud má příslušná práva, může na daný účet aplikovat slevu. Sleva může být jak procentuální, tak i částkou, přičemž může být aplikována na celý účet nebo položkovitě. Sleva se projeví pouze na ty položky, které mají v ceníku možnost slevy. Pokud na některou z položek není možné slevu aplikovat, sleva se na ně neprojeví. Další možností je provést platbu zvlášť. Pokud u daného stolů sedí více zákazníků a chtějí platit odděleně, tak obsluha musí ručně zvolit, co který zákazník měl ke konzumaci a každému vytiskne zvláště doklad. Pokud dojde k vytištění dokladu u prvního zákazníka, je samozřejmě možné dál zachovat účet a ostatní zákazníci u společného stolu mohou dále objednávat. Další variantou je slučování účtů či přesouvání položek z účtu na účet. Sloučení účtů je chápáno tak, že dva účty sloučíme na třetí, tedy dojde k přesunutí dvou účtu na jeden vybraný. Tento proces můžeme provést za pomoci přesunutí účtu, kde definujeme z kterého účtu chceme položky nebo celý účet přesunout na jiný účet. Po vytisknutí účtenky ji předáme zákazníkovi k zaplacení. Pokud při tisku dojde papír, je k dispozici tisk účtenky zpětně, kterou může vytisknout jen obsluha s danými právy.

3.4 Hardware a periferie Pokud pokladní systém běží na operačním systému Windows, je možné provést instalaci na běžný počítač, notebook nebo tablet. Ve většině případů bývá obrazovka dotyková. Databáze pokladny bývá umístěna na místním disku nebo na přenosném médiu. Pokud se jedná o cloudové řešení, tak na serveru. V případě, že aplikace běží na operačním systému Android nebo iOS, tak zařízení s daným systémem. Mezi nejčastější periferie, které bývají k pokladnímu systému připojeny, zpravidla patří:  čtečka čárových kódů (ruční, všesměrová, s integrovanou váhou)  čtečka magnetických karet  čtečka RFID karet  zákaznický displej  váha


23

4 Zkoumané společnosti Mezi zkoumané společnosti bylo zařazeno celkem 15 subjektů, které nabízejí pokladní systémy na území České republiky. U každé je zmíněna minimálně jedna z vlastností, která je dopodrobna vysvětlena. Součástí každého subjektu je i grafický náhled hlavní obrazovky, kterou má k dispozici obsluha programu.


24

4.1 ABX software s.r.o. Společnost byla založena v roce 2012. Pokladní systém od této společnosti má označení Harsys, který je určený pro restaurace. Součástí je skladová evidence, která hlídá veškeré skladové pohyby, což umožňuje mít absolutní kontrolu nad skladovým hospodářstvím. Na trhu se nachází mnoho subjektů, které skladové hospodářství neevidují, proto je možné zakoupit verzi bez skladu. Samozřejmostí jsou statistiky prodejů zboží za zvolené období. Zajímavostí je automatické odesílání reportů na email či formou SMS a tzv. elektronická bonovačka, která dá informaci kuchaři, jaký pokrm má připravovat. Většina systému používá bonovací tiskárnu, což je klasická tiskárna pro tisk účtenek, většinou šířky 80 mm, přičemž vyjedou bony v pořadí, v jakém je číšník zadal do pokladního systému. Některé systémy umí vyjet tzv. bony dle jednotlivých chodů. Číšník do systému zadá vše co si daný zákazník objednal a jednotlivé chody oddělí pomocí oddělovačů. Jakmile zkonzumuje první chod, tak číšník v pokladně klikne na tlačítko další chod a do kuchyně vyjede informace o dalším pokrmu. Z informací, které jsem nalezl, tak oddělené chody pomocí tiskárny není možné dělit, ale pomocí elektronické bonovačky ano. Další předností, kterou bych uvedl je implementace modulu rozvoz, který přináší urychlení v možnosti odbavování volajících zákazníků. Výhodou je také inventura alkoholu pomocí váhy. V propojení s čtečkou čárových kódů odpadá zdlouhavé přelévání do odměrného válce a následného přelití zpět do lahve. Systém běží na operačním systému Windows a databáze je uložená přímo na dané pokladně. V nabídce je také aplikace mobilní číšník běžící na Android, která přináší značnou úsporu času obsluze. Další verze, která je určena pro obchod má označení Astor. Současně nabízí i systémy, které jsou určeny pro půjčovny aut, zastavárny a hotelová zařízení. Pokladní systém používá necelých 800 subjektů (ABX software s.r.o., [online]).


Obr. 1 Hlavní obrazovka ABX software s.r.o. Zdroj: http://www.ab-x.cz/gallery/hlavni_obrazovka_pokladny_1.png

25


26

4.2 AGNIS s.r.o. Založení společnosti bylo v roce 2003. Výhodou je možnost propojení více pokladen mezi sebou, přičemž jedna pokladna je hlavní, která obsahuje databázi a ostatní poklady, které jsou vedlejší, tak se na hlavní pokladnu připojují. Pokud se jedná o více pokladen v rámci jedné sítě, tak je lepší využít hardwarově silnější zařízení, ideálně server, kde se bude nacházet hlavní databáze, ke které se budou ostatní pokladny připojovat. Nevýhodou je to, že pokud se hlavní pokladna odpojí od sítě, tak ostatní pokladny není možné používat. Pokud by bylo na provozovně více pokladen, které by mezi sebou nebyly propojeny, tak v případě skladového hospodářství by mohl nastat problém při vytváření příjemek a následné inventarizaci celého subjektu. Pokud daný subjekt nepožaduje evidenci skladového hospodářství, tak je možné mít databáze odděleně, samozřejmě vždy záleží na rozhodnutí jednotlivce. Aplikace mobilní číšník je k dispozici na operační systém Windows a Android. Jako velkou výhodu vidím v propojení s výčepními zařízeními. V systému může být nastaveno, že použití výčepu je možné až po namarkování daného produktu na zvolený stůl. Pokud obsluha namarkuje daný nápoj, poté nápoj připraví, tak již není možné daný produkt bez příslušných práv vymazat, tedy propojení s výčepem přináší absolutní kontrolu. Dále bych zmínil využití e-stravenek, což je z mého pohledu spíše otázka budoucnosti. Samozřejmostí je i platba zvlášť, tedy pokud u jednoho stolu sedí vícero zákazníků a každý chce platit zvlášť, tak je možné vytisknout vícero účtenek, přičemž u každé vyberu, co má obsahovat. Jako výhodu vidím možnost rezervace jednotlivých stolů do přehledného kalendáře. Rezervaci není možné provést po internetu, ale musí ji někdo do systému ručně vložit. Jak je možné na obrázku č. 2 vidět, tak v základní licenci je již mapa podniku, které usnadňuje obsluze orientovat se v prostoru restaurace. Mnoho společností má mapu podniku v nabídce až za poplatek, standardně vypadá rozhraní programu jako obrázek č. 1. Pokud je možnost dokoupit mapu podniku a jedná se o provoz, který má více jak 15 stolů k sezení, tak mapa přinese opravdu zrychlení v orientaci se v prostoru, protože ihned je vidět perspektiva restaurace a není nutné počítat stoly, jak je nejčastěji na obsluze vidět. Pokladní systém používá necelých 1 400 subjektů (AGNIS s.r.o., [online]).


Obr. 2 Hlavní obrazovka AGNIS s.r.o. Zdroj: http://www.agnis.cz/media/k2/galleries/20/Stoly.jpg

27


28

4.3 Amax com s.r.o. Společnost na našem trhu působí od roku 2005. V základu je možné zakoupit systém bez skladového hospodářství, což ocení menší provozovny. Předností pokladny je při placení možnost jednoduché změny sazby DPH, jelikož je dáno, že pokud si zákazník bere produkt s sebou, tedy konzumace neprobíhá v restauraci, tak se automaticky mění sazba DPH z 21 % na 15 %. Jedná se pouze o potraviny a nealkoholické nápoje. Aplikace mobilní číšník běží na operačním systému Windows. Mobilní číšník přináší do gastro provozu značnou úsporu jak času, tak i práci obsluze. Standardně probíhá objednávka tak, že obsluha si objednávku od zákazníka zapisuje na malý bloček, přičemž následně jde k pokladně, kde objednávku zadá do systému. V případě mobilních číšníků má obsluha s sebou tablet, který běží na Windows či na Android nebo iOS. Objednávku rovnou zadává do systému, který za pomoci WiFi ukládá data přímo do databáze, tedy do hlavní pokladny. Pokud je vše korektně zadáno do systému a jsou nastaveny ideálně 2 tiskárny, tedy jedna na baru a druhá v kuchyni, tak po zadání požadavku vyjede objednávka na baru a v kuchyni, tedy se číšník nemusí vracet zpět na bar, ale jiná obsluha již může na baru připravovat dané nápoje a kuchař v kuchyni dané pokrmy. Tedy může být vyhrazena pouze jedna osoba na zadávání objednávek do systému a ostatní personál, který nápoje připravuje a obsluhuje zákazníka. Tato funkcionalita se hodí v takových provozech, kde bývá mnoho zákazníků nebo je plocha restaurace větší. Je zde kladen důraz na kvalitní zasíťování, jelikož musí být neustálý signál WiFi. V případě aplikace na Windows, tak není nutnost být neustále připojen k internetu, protože služba běží na lokální síti. Pokud se jedná o aplikaci na Android či iOS, tak je nutné být neustále připojen k internetu, což může být někdy problém, např. při neustálých výpadcích internetu. Jako výhodu vidím v implementaci na Windows tabletu, jelikož většina pokladních systému právě běží na Windows, tedy při implementaci mobilního číšníka není nutné programovat novou aplikaci pod jiné rozhraní, ale stačí pouze provést grafickou úpravu, jelikož tablety bývají nejčastěji velikosti 7" nebo 8". Pokud je k tabletu ještě připojena bluetooth tiskárna, tak vyjetí účtenky probíhá přímo u stolu zákazníka, což přináší opět úsporu času, jelikož pokud u stolu sedí více zákazníků a každý chce platit zvlášť, tak obsluha rovnou volí co bude každý zákazník platit. Často bývá zmiňováno, že kontakt se zákazníkem není značně osobní, jelikož obsluha neustále drží v ruce tablet, což může některé zákazníky odradit. Domnívám se, že se používání mobilních číšníků stane samozřejmostí, s tím že si zákazník bude rovnou z nějakého zařízení objednávat od svého stolu. Pokladní systém používá necelých 300 zákazníků (Amax com s.r.o., [online]).


Obr. 3 Hlavní obrazovka Amax com s.r.o. Zdroj: http://www.prodejpokladen.cz/478-tm_thickbox_default/kasamax-gastro-profi.jpg

29


30

4.4 ASW Systems a.s. Společnost byla založena v roce 2007. Pokladní systémy patří mezi jedny z nejdražších, nicméně jsou určeny převážně pro větší restaurace. Nastavení vzhledu pokladny je čistě na majiteli restaurace, což jiné systémy nemají. Modularita jednotlivých částí pokladny přináší konfiguraci vlastního vzhledu pokladny. Výhodou je, že aplikace se skládá ze dvou aplikací, přičemž první je pokladna, kterou používá obsluha pro markování položek. Druhá část je manažerská, která jak je z názvu již známo slouží pro manažery. Zde se zadávají jednotlivé skladové, ceníkové položky, uživatelé, práva a ostatní. Výhodou je, že je možné mít manažerskou část nainstalovanou na jiném počítači, přičemž se přes místní síť připojuje na hlavní pokladnu. Tedy veškeré zadávání příjemek, odpisů, nového sortimentu probíhá nezávisle na pokladně, což nijak nenarušuje obsluhu, tedy je možné pracovat se systémem i v pracovní době. Aplikaci je také možné nainstalovat na notebook, tedy připojení může být odkudkoliv, nicméně je to podmíněno buď veřejnou IP adresou a následném přesměrování daného portu na místní IP adresu hlavní pokladny nebo za pomoci virtuální privátní sítě, kde je v manažerské části zadána pouze místní síť hlavní pokladny. Nevýhodou je, že pokud se dělá nějaká delší operace, například je rozdělaná nová příjemka a v daný okamžik dojde k odstavení sítě, tak se přijde o veškerou rozdělanou práci. Předností systému je možnost mít jídelní lístek na iPadu, což je tablet od společnosti Apple se systémem iOS. Jedná se svým způsobem o úpravu aplikace mobilní číšník, s tím, že je celý vzhled aplikace předělán, aby byl intuitivní pro objednávající zákazníky. Výhodou je, že aplikace objednávajícího provádí veškerým objednávkovým procesem, tedy je možné zákazníkovi automaticky poradit s výběrem daného pokrmu či nápojů. Tablet je vhodné implementovat přímo do stolů zákazníků. Společnost zmiňuje, že implementací tabletů do provozů zvýšili tržby až o 15 %. Podle mého názoru to do značné míry je možné, jelikož odpadá tištěný jídelní lístek a zákazníkovi se nabídne něco nového, nečekaného, graficky lépe zpracovaného, navíc co je doplněno o obrázky jídel. Zase na druhou stranu může takový jídelní lístek působit na běžné zákazníky honosně, tedy je návštěva může odradit, jelikož si mohou myslet, že ceny v této restauraci budou značně vyšší. S ovládáním by mohli mít problém především starší ročníky, které by mohla také návštěva odradit. Nicméně je důležité spočítat si cenu na pořízení a další náklady spojené s provozem. Systém používá necelých 1 100 restaurací (ASW Systems a.s., [online]).


Obr. 4 Hlavní obrazovka ASW Systems a.s. Zdroj: http://www.lgtp.cz/wp-content/uploads/Septim-pokladna-seznam-stol%C5%AF.jpg

31


32

4.5 AWIS Holding, a.s. Společnost na našem trhu působí od roku 2010. Systém je rozdělen do svou částí, a to části manažerské a části sloužící pro obsluhu, tedy pokladny. Do manažerské sekce může mít přístup také obsluha, vždy záleží na nastavení práv danému uživateli. Předností systému je věrnostní systém pro stále zákazníky, který je synchronizován pomocí centrálního serveru, což přináší neomezenou možnost propojení provozoven z jakéhokoliv místa. Jedinou podmínkou je připojení k internetu. Variant je k dispozici několik. Nejčastější bývá varianta slevové karty, kdy se věrný zákazník uloží do systému a následně se mu přiřadí nějaký identifikátor, nejčastěji to bývá magnetická karta nebo RFID karta či RFID čip. Poté se v systému přiřadí danému zákazníkovi procentuální sleva. Karta tedy slouží pouze pro identifikaci. Karta má od výroby přiřazen nějaký identifikátor, který je v rámci společnosti jedinečný, nicméně pokud by jste kartu použili v nějakém jiném subjektu, věřím že by byla funkční, pouze by se načetl jiný zákazník. Nevýhodou je, že pokud je kód lehce zapamatovatelný, může toho obsluha využít pro aplikování slev pro vlastní obohacení. Tomuto je možné předcházet za pomoci kamerového systému. Pokud má tedy subjekt více provozoven a chce zákazníky motivovat k nákupu, tak stačí na jedné provozovně přiřadit zákaznickou kartu a na ostatní provozovny se informace o zákazníkovi propíší automaticky za pomoci serveru. Další možností jak odměňovat své zákazníky, je procentuální odměňování za provedený nákup, který se přemění v body, které je následně možné využít k uhrazení nákupu. Pokud se jedná o více provozoven, tak načtené body se automaticky mezi pobočkami synchronizují a je jedno, kde se dané body použijí k uhrazení nákupu. Samozřejmě je možné filtrovat sortiment, z kterého se body načítat nebudou, nicméně je o tom vhodné zákazníka informovat. Další možností je dobití karty, kdy za dobití dostane nějaké zvýhodnění. Zvýhodnění může být v podobě navýšení kreditu, či přiřazení slevy k dané kartě nebo možností debetu, tedy možnost nakupovat bez nutnosti hotovosti. S tím, že se poté následující měsíc veškeré transakce uhradí. Jak již bylo zmíněno, tak kontrola proti nepoctivým zaměstnancům je kamerový systém. Pokladnu je možné propojit s kamerovým systémem, což přináší urychlení ve vyhledávání v záznamu. Pokud v manažerské části se označí daný účet, u kterého je uložen i čas vytisknutí účtenky, tak se otevře záznam, který obsahuje sekvenci 15 s před a 15 s po. Tedy přesně vím, co daná obsluha u pokladny při vyjetí účtenky dělala a jsem schopen i identifikovat, jestli zákazník s danou věrnostní kartou na provozovně opravdu byl nebo ne. Pokladní systém využívá necelých 800 klientů (AWIS Holding, a.s., [online]).


Obr. 5 Hlavní obrazovka AWIS Holding, a.s. Zdroj: http://www.awiscz.com/wp-content/uploads/screenKasa03.png

33


34

4.6 CÍGLER SOFTWARE, a. s. Akciová společnost byla založen v roce 1999, nicméně společnost existuje již od roku 1990. Systém je postaven na datech, která jsou uložena v účetním programu Money S3. Systém se hodí spíše pro menší provozy. Jako výhodu vidím to, že manažer je za pomoci webového rozhraní schopen okamžitě vidět kolik položek má skladem, tedy co je nutné dokoupit. Mnoho systému tuto vlastnost nenabízí a je nutné se složitě přihlašovat do manažerské části. Výhodou je, že systém je plně propojen s účetním programem, tedy má účetní již korektní data a nemusí je žádným způsobem od subjektu získávat. Mnoho pokladních systému nabízí propojení s účetními programy, přičemž export probíhá za pomoci souboru, který je do účetního programu nahrán. Zde je řešeno vše automaticky a odpadá jakýkoliv export. Další výhodou je, že je možné přijímat hotovost v jakékoliv měně. Systém automaticky stahuje aktuální kurz měny nebo je na manažerovi, jaký kurz zadá. Pokladní systém je využíván na necelých 100 provozech (CÍGLER SOFTWARE, a.s., [online]).

Obr. 6 Hlavní obrazovka CÍGLER SOFTWARE, a. s. Zdroj: http://www.money.cz/wp-content/uploads/conto1.jpg


35

4.7 Dotykačka s.r.o. Společnost byla založena v roce 2004. Pokladní systém běží pouze na operačním systému Android. Velkou výhodou je, že zařízení s operačním systémem Android je možné koupit za zlomek ceny oproti zařízení s Windows. Nicméně je mnoho aspektů, které mohou kompatibilitu ovlivnit. Pokud výjde nová aktualizace Android, tak musí vývojový tým ihned začít řešit nutné úpravy v kódu. Dalším omezujícím aspektem je to, pro která zařízení je konkrétně vyvíjeno. Může se stát, že se bude jednat o stejnou verzi, nicméně se aplikace bude na každém zařízení chovat jinak. V dnešní době se již nemusí jednat pouze o tablety, ale o terminály, které obsahují Android a disponují všemi konektory jako běžné počítače. Přináší to možnosti připojit k pokladně váhu, platební terminál, čtečku čárových kódů či zákaznických karet. Systém od této společnosti umí i komunikovat s platebním terminálem, což je velká výhoda. Mnoho pokladních systému neumí komunikovat s platebními terminály z důvodu bezpečnosti nebo z důvodu nekompatibility s pokladním systémem. Pokud terminál není propojen, musí obsluha při platbě zadat na pokladně že se jedná o platbu kartou a částku zadat do platebního terminálu. Tato operace může generovat špatné zadání částky, což v případě propojení odpadá. Další možností je propojení s váhou. Pokud probíhá prodej na váhu, tak je nutné mít zadanou ceníkovou položku, kde je uvedeno, že se jedná o kilogramy a cenu za jeden kilogram. Poté po vložení předmětu na váhu se v pokladně zobrazí daná váha a po kliknutí na příslušnou položku v pokladním systému se daná cena přepočte v závislosti na naváženém množství. Také je možné do systému zadat ceníkovou položku, která bude časově závislá. Po namarkování k danému zákazníkovi se začne počítat doba, přičemž po překročení např. každé hodiny se cena zvýší. Veškeré nastavení závisí pouze na uživateli, který nastaví cenu za první hodinu a poté cenu za další hodiny. Vše probíhá automaticky, což mohou ocenit různé wellness centra apod. Pokladní systém využívá necelých 10 000 subjektů (Dotykačka s.r.o., [online]).


Obr. 7 Hlavní obrazovka Dotykačka s.r.o. Zdroj: https://s3.amazonaws.com/cdn.freshdesk.com/data/helpdesk/attachments/production/ 6005198987/original/blob1442305165827.jpeg?1442305167

36


37

4.8 i-Technologies s.r.o. Založení společnosti připadá na rok 2003. Jedná se o webovou aplikaci, která může běžet jak na místním počítači, tak na nějakém výkonnějším serveru. Výhodou je, že je aplikace multiplatformní. Systém automaticky eviduje docházku jednotlivým zaměstnancům. Po automatickém přihlášení do systému se začne počítat pracovní doba. Přihlášení může probíhat pomocí výběru daného uživatele a zadání hesla. Pokud je zde kladen důraz na rychlost přihlášení, mohou být využity různé zařízení, jako jsou magnetické karty, RFID karty, náramky apod. Čtečky médií pracují na velmi jednoduchém principu. Každé médium má přirazeno od výrobce nějaký kód, který po přiložení ke čtečce médií vloží do daného pole načtenou textovou informaci, která slouží pro identifikaci. Urychlení přihlašování může být, pokud na dané směně je více obsluhujících a vedení chce mít podrobné informace o každém z nich, kdo je jak výkonný apod. Tyto informace mohou mít pro vedení velkou cenu. Systém také umožňuje vytváření denních menu a následném automatickém odesílání předem vybraných zákazníků. Pokladní systém využívá necelých 50 společností (I-Technologies s.r.o., [online]).

Obr. 8 Hlavní obrazovka i-Technologies s.r.o. Zdroj: http://www.horeca-fusion.cz/photos/photos/pokladni-systemy-fusion-39.jpg


38

4.9 Origin Soft s.r.o. Společnost byla založena v roce 2009. Aplikace běží na operačním systému Windows. Ve většině pokladních systémů bývá plocha zpravidla rozdělena na jednotlivé úseky a k nim náležící stoly. Pokud se jedná o provoz, například pivnici, tak je vhodné provést rozdělení na jednotlivé židle, což mnoho systému neumí. Řešením je uvažovat, že jednotlivé stoly nahradíme jednotlivými židlemi nebo za pomoci mapy podniku vytvořit z jednotlivých stolů menší stoly, a ty pojmenovat jako židle. Pokud by součástí nebyla mapa podniku, bylo by pro obsluhu velice těžké se orientovat v prostoru. Systém také umí propojit samovýčep s grafickou prezentací, což ocení pivnice, kde si zákazník sám připravuje nápoj. Poté je možné jednotlivé soutěžní stoly vidět na obrazovce, kde se eviduje počet vytočených nápojů a mohou mezi sebou jednotlivé stoly soutěžit. Současně se vše zapisuje do pokladního systému, tedy obsluha pouze vytiskne účet. Pokladní systém využívá necelých 100 subjektů (Origin Soft s.r.o., [online]).

Obr. 9 Hlavní obrazovka Origin Soft s.r.o. Zdroj: http://www.finta.cz/create_photo.php?photo_id=188&type=big


39

4.10 PROFIREST s. r. o. Společnost na našem trhu působí od roku 2009. Jedná se o webovou aplikaci, která běží na serveru dodavatele. Velkou výhodou je, že pokladní systém může běžet na jakémkoliv zařízení. Bohužel pokud dojde k výpadku na straně poskytovatele, není možné pokladní systém jakkoliv využívat. Stejný problém nastane, pokud na straně uživatele dojde k výpadku internetu. Tento pokladní systém se spíše hodí pro pizzerie, které mají většinu svého podnikání zaměřeného spíše na rozvoz. Po objednání zákazníkem na webových stránkách dojde do restaurace email o nové objednávce, tedy je nutné nejprve založit zákazníka (pokud již není obsažen v databázi) a následně veškerou objednávku z emailu zadat do pokladního systému. Tento systém se pyšní tím, že pokud si zákazník objedná z webových stránek daný pokrm, tak se vše do pokladny propíše automaticky, což přináší velkou úsporu času. Pokud je již zákazník v databázi obsažen, nový se nevytváří, pouze se k němu přiřadí daná objednávka. Současně na účtence vyjede jméno, příjmení, telefon a adresa daného zákazníka, na kterou je nutné pokrm doručit. Další úsporou času je možnost propojení pokladny s mobilním telefonem. Standardně pokud někdo volá na mobilní telefon, tak je nutné ručně vyhledat v databázi zákazníků nebo vytvořit nového. Pokud je pokladna propojena s mobilním telefonem, tak v pokladním systému vyskočí informace o volajícím. Pokud je zákazník již v systému založen, vyskočí informace o něm a o poslední objednávce. Je možné samozřejmě stávajícího zákazníka editovat, jelikož může požadovat dodání na jinou adresu, než má standardně uvedeno. Pokud zákazník není v systému uložen, vyskočí možnost pro uložení zákazníka. Pokud zákazník si nepřeje být uložen a chce si například jídlo vyzvednout, je možnost začít účtovat ihned, tedy jako název zákazníka se použije jeho telefonní číslo. Bylo by vhodné naprogramovat i desktopovou aplikaci. Pokladní systém využívá necelých 50 subjektů (PROFIREST s. r. o., [online]).


Obr. 10 Hlavní obrazovka PROFIREST s. r. o. Zdroj: https://www.profirest.cz/files/help/main_page.png

40


41

4.11 QPOS systems s.r.o. Společnost byla založena v roce 2013. Jedná se o aplikaci pro Windows, která se skládá z části pro obsluhu, tedy pokladny a poté administrátorské části, která slouží manažerům. Předností pokladny je možnost vytvářet objednávky, tzv. předobjednávky. V praxi je využití vhodné pro různé cukrárny, které dodávají produkty na základě objednávek. Pokud si chce zákazník objednat něco na určitý den, je možné do systému zadat jeho požadavek, který se automaticky v daný den objeví v pokladně a jakmile si pro produkt dorazí zákazník, stačí pouze vytisknout účtenku. Další kladnou vlastností, kterou systém obsahuje je možnost inventury na datum. Praxe je taková, že personál provádí inventuru papírovou formou. Následně je manažer kdykoliv schopen zpětně napočítané hodnoty zadat do systému. Pokud není možnost inventury na datum, tak je inventura zaváděna rovnou do systému, nicméně musí mít daná obsluha příslušná práva. Ve všech systémech je nutnost zadat tzv. receptury pokrmů. Receptury je možné definovat a následně přiřadit u ceníkových položek. Receptury je možné opakovaně používat s tím, že nové ceníkové položky rozšíříme o některé další skladové. V praxi se nejčastěji receptury používají u produktů, u kterých se daný základ opakuje, například výroba pizzy. Těsto je neustále stejné s tím, že se pouze obměňují jednotlivé ingredience. Pokud jsou gramáže u jednotlivých receptur nastaveny chybně, dochází tak ke špatným propočtům na straně skladu. Systém od této společnosti používá necelých 400 subjektů (QPOS system s.r.o., [online]).


Obr. 11 Hlavní obrazovka QPOS systems s.r.o. Zdroj: http://www.qpokladna.cz/galerie/544.jpg

42


43

4.12 Smart software s.r.o. Společnost na našem trhu působí od roku 1998. Pokladna je k dispozici ve dvou variantách. První je cloudové řešení, druhá varianta je desktopová aplikace. Výhodou je, že pokud nejste připojeni k internetu, tak se nic neděje. V obou variantách je nastavená automatická synchronizace ve zvoleném intervalu. V nabídce je i aplikace mobilní číšník, který může pracovat i bez připojení k síti. Ceníkové položky, tedy veškerý sortiment k prodeji, je uložen v databázi v daném tabletu. Vše probíhá offline, což přináší mnoho výhod. Je možné obsluhovat i na místech, kde není k dispozici WiFi síť. Pokud je zákazník obsloužen, musí jít číšník na místo, kde se již WiFi signál nachází. Je tedy schopen obsloužit zákazníky, kde není dostatečný signál a poté stisknutím tlačítka vše odešle do hlavní databáze a na jednotlivé tiskárny. Součástí pokladny je i modul pro Business Inteligence, který má vedení usnadnit práci při rozhodování, tedy stanovení cenových hladin, různých predikcí prodejů apod. Samozřejmostí jsou výsledky v grafické reprezentaci. K dispozici je také možnost propojení kamerového systému s pokladnou. Součástí je podpora cross-sellingu, který slouží k podpoře prodeje, kde jsou obsluhujícímu nabízeny další produkty k prodeji. Systém je k dispozici ve více jazycích. Pokladní systém využívají převážně franšízové subjekty. Celkem se jedná o necelých 200 provozoven (Smart software s.r.o., [online]).


Obr. 12 Hlavní obrazovka Smart software s.r.o. Zdroj: http://enterprise.smartpos.cz/sites/default/files/fototext/Stoly.jpg

44


45

4.13 storyous.com s.r.o. Společnost byla vybudována v roce 2012. Pokladní systém je cílen převážně na kavárenské podniky. Jedná se o cloudové řešení. Výhodou je, že pokud spravujete více podniků, máte vše pod jednou správou. Je možné mezi jednotlivými podniky přesouvat skladové položky, vytvářet nabídky, které se automaticky promítnou i do ostatních, odpisovat jednotlivé položky apod. Samozřejmostí je možnost propojení s pokladní zásuvkou, která se automaticky otevře po vyjetí účtenky. Pokud by se jednalo o Windows, tak automatické otevření se provádí u ovladače tiskárny. V případě Android je nastavení přímo na tiskárně. Nevýhodou u Android je, že pokud vyjede i bon, zásuvka se automaticky otevře. Otevření nastane, pokud dojde do tiskárny informace o tisku. Na Windows je možné vytvořit kopii tiskárny, kterou jinak pojmenujeme a otevření se nastaví pouze u žádoucí tiskárny. V pokladně je možné nastavit tzv. happy hours. V předem definovaném čase dojde ke zlevnění určitého sortimentu. Danou akci je možné nastavit jednorázově nebo nastavit pravidelné opakování v určitý den s časovým omezením. Dále je možnost tisknout na bonu pořadové číslo, což ocení podniky rychlého občerstvení, kde je zákazníkovi předána vytištěná objednávka, přičemž po připravení pokrmu bon předá obsluhujícímu. Pokladní systém využívá necelých 1 000 klientů (storyous.com s.r.o., [online]).


Obr. 13 Hlavní obrazovka storyous.com s.r.o. Zdroj: http://www.czechcrunch.cz/wp-content/uploads/2014/01/storyous-objednavky.png

46


47

4.14 Vectron Systems CZ s.r.o. Společnost na našem trhu působí od roku 2002. Veškerá databáze je uložena na USB paměti, což v případě poruchy hardware přináší pouze přepojení USB do nové pokladny a veškerá data a nastavení jsou opět k dispozici. Nevýhodou ale může být, pokud odejde USB médium. Tedy předpokládám, že všechny zálohy jsou uloženy na nějakém serveru. Předností pokladny je, že pokud dojde k výpadku v síti, tak pokladnu je možné nadále používat, i když se jedná o řešení, které má více pokladen propojených mezi sebou. Data se ukládají lokálně, přičemž poté dojde ke synchronizaci. Manažer je schopen za pomocí makro funkcí přiřadit jakémukoliv tlačítku svoji vlastní funkci, což ostatní systémy neumožňují. Pokladnu je tedy možné si přizpůsobit vlastním podmínkám. Systém běží na vlastním operačním systému, což přináší značnou stabilitu a absolutní kontrolu. V nabídce je aplikace mobilní číšník, která umí fungovat i bez připojení k WiFi. Místa, která nejsou pokryta, tak pokladna ukládá objednávky do paměti zařízení, přičemž jakmile dojde ke konektivitě, vše se odešle na hlavní pokladnu. V nabídce je i pager pro zákazníky, kteří si daným zařízením přivolají ke svému stolu obsluhu. Pokladní systém využívá necelých 200 subjektů (Vectron Systems CZ s.r.o., [online]).

Obr. 14 Hlavní obrazovka Vectron Systems CZ s.r.o. Zdroj: http://www.vectron.cz/pic/pospc/pospc_545x435_02.png


48

4.15 WinShop Software s.r.o. Společnost na našem trhu působí od roku 2003. Předností systému je možnost tvorby inventur za pomocí PDA. Osoba provádějící inventuru tedy nemusí být přímo u pokladny, ale za pomoci zařízení je schopna inventuru provádět i přímo ve skladu, kde do databáze zadává rovnou naměřené hodnoty. Tato funkce šetří čas a snižuje chybovost personálu. Dále také pokladna nabízí propojení s kamerovým systémem. Předností je možnost odesílání informací o tržbách formou SMS. Společnost se ve větší míře zaměřuje na obchodní řetězce. Pokladní systém využívá necelých 4 000 společností (WinShop Software s.r.o., [online]).

Obr. 15 Hlavní obrazovka WinShop Software s.r.o. Zdroj: http://www.pokladny.com/userfiles/produkty/winshop-basic/winshop-basic-03.jpg

Analýza

49

5 Analýza Součástí analýzy bylo celkem 15 společností. U každé byly zkoumány celkem 3 atributy. Prvním atributem bylo, zdali mají implementovanou formu rozvozu, druhým aspektem propojení s webovými stránkami a posledním je propojení s webovým portálem damejidlo.cz. Formou rozvozu je myšlena implementace, kterou nabízí stávající pokladní systémy spolu s mobilním telefonem či IP ústřednou. Pokud zavolá zákazník, tak pokladní systém detektuje příchozí volání. Pokud se jedná o nového zákazníka, tak se na obrazovce pokladny zobrazí neznámé číslo, které obsluha uloží s náležitými údaji, jako je jméno, příjmení a adresa nebo zvolí možnost účtovat ihned, tedy zákazník bude uložen pouze pod daným telefonním číslem, což je možné použít například, pokud si zákazník přijde objednávku vyzvednout osobně na provozovnu. V případě, že volá klient, který je v databázi již obsažen, na obrazovce se zobrazí informace o volajícím. Samozřejmostí je zobrazení jména, příjmení a adres. Pokud jich má klient více, musí být obsluha schopna vybrat adresu dodání a v ideálním případě i poslední klientovu objednávku. Mnoho zákazníků si často objednává stejný sortiment, tedy jedním kliknutím na tlačítko se do objednávky promítne poslední objednávka, kterou je možné rozšířit o další položky. Pokud se objednávka poveze k zákazníkovi nebo zákazník si objednávku vyzvedne osobně a nebude probíhat konzumace v restauraci, tak na nealkoholické nápoje a pokrmy se vztahuje 15% DPH, tedy je nutné změnit 21% DPH na 15 %. Systém by měl tuto změnu provést automaticky, na základě toho, že se jedná o rozvozový účet. U alkoholického sortimentu by mělo být správně nastaveno 21% DPH a zvoleno, že se jedná o pevné DPH, na které nebude mít rozvozový účet žádný vliv, tedy že nedojde k automatické změně na 15 %. Samozřejmostí je, že se na účtence vytiskne jméno a adresa dodání objednávky. Nutností je také vytisknutí telefonního čísla, aby rozvozce mohl zákazníka upozornit, že se již blíží k místu dodání. V dnešní době 90 % restaurací používá termo metodu tisku, která přináší úsporu nákladů. Nevýhodou je, že termo papír je citlivý na teplo, což v případě rozvozu přináší, že pokud rozvozce přikládá účtenky k dané objednávce, bývá účtenka značně poškozena. Řešením je použití jehličkových tiskáren, u kterých se používá klasický papír, nicméně tisk trvá déle a provozní náklady jsou o něco vyšší. Mnoho objednávek bývá přes webové stránky dané restaurace. V nejčastějším případě bývá upozornění na novou objednávku formou emailu. Obsluha musí tedy nejprve vyhledat v databázi, jestli je zákazník již vytvořen nebo ne. Pokud ne, tak musí veškeré údaje z emailu ručně přepsat do pokladny, čímž vytvoří zákazníka, ke kterému může následně přiřadit danou objednávku. Tento proces je zdlouhavý a může vést k chybě, že bude objednávka doručena na chybnou adresu nebo neobjednaný sortiment. Řešením může být automatické propsání objednávky do pokladního systému. Jako jednoznačný identifikátor je vhodné použít telefonní číslo nebo emailovou adresu. Pokud je na webové stránce možná registrace uživatele, tak použít

Analýza

50

identifikátor ID zákazníka. Je to z toho důvodu, že jednou zákazník uvede adresu domů, podruhé do práce apod. Nebylo by tedy možné zákazníka jednoznačně identifikovat a databáze klientů by se neustále zvětšovala, což by přinášelo problémy ve vyhledávání a v jednoznačné identifikaci zákazníků. Propojení přináší urychlení objednávkového procesu a snížení chybovosti. Komunikace může být jednosměrná nebo obousměrná. V případě jednosměrné je důraz kladen na sjednocení identifikátorů daného sortimentu. V praxi to vypadá tak, že veškerý sortiment, který je v pokladně, tak má jednoznačný identifikátor. Tento identifikátor se musí shodovat s nabídkou na webových stránkách, jelikož z www dojede objednávka, kterou identifikujeme na základě daných ID. Pokud dojde k založení nového sortimentu na straně pokladního systému, je nutné sortiment zadat na webové stránky, kde uvedu jednoznačný identifikátor z pokladny. Dále je kladen důraz i na cenu. Ve většině případů bývá forma taková, že větší prioritu má objednávka z internetu. Tedy pokud je v pokladním systému cena vody 10 Kč a na webových stránkách 20 Kč, tak do pokladny příjde informace s cenou 20 Kč. Toto přináší výhodu u tzv. akcí 2+1 apod. Na straně www je nastaveno, že pokud je objednán daný sortiment dvakrát, je nárok na třetí zdarma. Na webu se automaticky označí třetí nejlevnější sortiment z dané objednávky, který je za cenu 0 Kč. Správně by měl být za cenu minimálně 1 Kč, jelikož není možné vystavit položku na účtence, která by byla za 0 Kč. Mnoho restaurací, se ale dopouští chyby, možná nevědomě. Pokud by byla cenová priorita menší z webových stránek, bylo by použití akcí značně obtížné, neboť by bylo nutné celý sortiment uvést znovu za cenu 1 Kč a v pokladním systému stejným způsobem. V případě obousměrné komunikace odpadá nutnost ručního propojení na základě identifikátorů, ale systém automaticky zašle sortiment z pokladního systému na webové stránky. Objednávka se do pokladního systému propíše stejným způsobem jako v případě jednosměrné komunikace. Výhodou obousměrné je také to, že obsluha může v pokladním systému přiřadit k objednávce předpokládaný čas doručení, přičemž se tato informace pošle na webové stránky, kde emailový server odešle informativní email cílovému zákazníkovi. Tuto variantu ale nemá implementovanou žádná z výše uvedených společností. Většina používá automatickou odpověď z webového serveru, že objednávka byla přijata, což se děje automaticky, aniž by bylo nějakým způsobem ověřeno, že objednávka opravdu do pokladního systému dorazila a obsluha na dané objednávce pracuje. Další chybu, kterou restaurace praktikují je nemožnost objednání mimo pracovní dobu. Pokud by byla možnost objednání i mimo pracovní dobu, s tím, že by bylo nutné specifikovat čas dodání, který by byl samozřejmě v pracovní době, by mnohým restauracím zvýšilo tržby. Posledním zkoumaným aspektem bylo propojení s objednávkovou a rozvážkovou službou damejidlo.cz. Projekt damejidlo.cz založil Tomáš Čupr v roce 2011. Ke konci roku 2015 čítá seznam restaurací, u kterých je možné

Analýza

51

objednat přes damejidlo.cz necelých 700. Tento portál měl raketový start v oblibě a je z mého pohledu v dnešní době nejvyužívanější portál pro objednání jídla. Výhodou je, že v případě nespokojenosti se obracíte na portál damejidlo.cz, tedy odpadá jakýkoliv kontakt s restaurací. Restaurace mají přísné podmínky pro dodání jídla, tudíž spolehlivost dodání se přes portál damejidlo.cz značně zvyšuje (Damejidlo.cz s.r.o., [online]). Myslím si, že je kvalita a rychlost dodání na přijatelné úrovni oproti objednání přes portál restaurace nebo telefonicky. Nevýhodou pro restaurace je procentuální odvedení z každé objednávky, která byla provedena přes daný portál. Pro restaurace je tento portál značným zviditelněním, tedy nemusí hradit velké částky za reklamu, velkou návštěvností portálu damejidlo.cz dojde ke zviditelnění restaurace (Damejidlo.cz s.r.o., [online]). S rostoucí oblibou tohoto portálu je vhodné i reagovat na potřeby zákazníků využívajících tento portál pro zvýšení svých prodejů. V případě možnosti propojení s vlastním pokladním systémem by se obliba ještě více zvýšila. Tab. 1

Analýza zkoumaných společností

Název společnosti ABX software s.r.o. AGNIS s.r.o. Amax com s.r.o. ASW Systems a.s. AWIS Holding, a.s. CÍGLER SOFTWARE, a.s. Dotykačka s.r.o. i-Technologies s.r.o. Origin Soft s.r.o. PROFIREST s. r. o. QPOS system s.r.o. Smart software s.r.o. storyous.com s.r.o. Vectron Systems CZ s.r.o. WinShop Software s.r.o.

Rozvoz ANO NE NE NE ANO NE NE NE ANO ANO NE NE NE NE ANO

Webové stránky NE ANO NE ANO ANO NE NE NE ANO ANO ANO ANO NE ANO ANO

Damejidlo.cz NE NE NE NE NE NE NE NE NE NE NE NE NE NE NE

Jak je z Tabulky č. 1 zřejmé, rozvozovou aplikací disponuje celkem 5 společností, a to ABX software s.r.o., AWIS Holding, a.s., Origin Soft s.r.o., PROFIREST s. r. o., WinShop Software s.r.o. Zajímavostí je, že propojení s webovými stránkami má celkem 9 společností z 15 zkoumaných, a to AGNIS s.r.o., ASW Systems a.s., AWIS Holding, a.s., Origin Soft s.r.o., PROFIREST s. r. o., QPOS system s.r.o., Smart software s.r.o., Vectron Systems CZ s.r.o., WinShop Software s.r.o.

Analýza

52

Propojení s portálem damejidlo.cz nenabízí žádná ze zkoumaných společností. Nastává otázka, jestli je nevůle ze strany damejidlo.cz nebo ze strany výrobců pokladních systémů. Zajímavostí je, že automatizovaný rozvoz má pouze 5 společností, zato propojení s webovými stránkami má 9 společností. Pravděpodobně to je způsobeno tím, že objednávky přes webové rozhraní jsou pro zákazníky značně pohodlnější, nemusí s nikým komunikovat, jediné co je nutné, tak je vyplnění formuláře, navolení objednávky a kontakt s dodavatelem je až při předání zboží. Možná je to také způsobeno tím, že zákazník nemusí o sobě sdělovat znovu a znovu dodací údaje. Přes webové rozhraní má vytvořený uživatelský účet, kde jen zvolí objednávku a stisknutím jednoho tlačítka odešle. Co se ale týče pizzerií, tak objednávky přes mobilní telefon stále tvoří většinu celkových objednávek. Pro tyto subjekty má propojení s mobilním telefonem značné využití.

5.1

Hloubková analýza

Nyní budou dopodrobna rozebrány 3 zkoumané atributy, které byly zkoumány u výše zmíněných společností. 5.1.1

Rozvoz

Stávající řešení, které společnosti nabízejí je využití modemu, který v sobě mají implementované starší modely mobilních telefonů od výrobce Nokia. Tato technologie se již do stávajících modelů neimplementuje, proto je řešení zastaralé, nicméně je funkční a spolehlivé. Nevýhodou je, že je nutné zakoupit použitý telefon, protože na současném trhu žádné nové telefony od výrobce Nokia s modemem nejsou k dispozici. Jako druhou nevýhodu vidím to, že telefon je nutné mít neustále za pomocí USB kabelu propojený s počítačem. Toto způsobuje nefunkčnost baterie, protože telefon pokud je připojen do USB, tak se neustále nabíjí. Pokud dojde k odpojení od počítače, tak se přeruší konektivita s pokladním systémem a pokladní systém není schopen detekovat nové příchozí hovory. Druhou variantou propojení s pokladním systémem je využití aplikace na mobilní telefon s operačním systémem Android. Stačí využít událost onCallStateChanged, která identifikuje příchozí hovor a jako parametr příjme status hovoru a telefonní číslo volajícího (Vávrů a Ujbányai, 2013). Tuto informaci můžeme zpracovat a následně odeslat na náš server, který uloží danou informaci do databáze. Pokladní systém se pravidelně na předem dané adrese dotazuje, jestli nepřibyl nějaký nový záznam. Pokud ano, tak v pokladním systému se zobrazí telefonní číslo zákazníka nebo rovnou již údaje o zákazníkovi, pokud je v databázi, která se nachází v pokladním systému již obsažen.

Analýza

Obr. 16

53

Možnosti připojení mobilního telefonu

Problém nastává kdy identifikovat příchozí hovor, a tedy kdy jej zapsat do databáze. První variantou je zapisovat veškeré příchozí hovory, tedy pokud začne na mobilním telefonu zvonit volající, tak se informace zapíše do databáze a z databáze si telefonní číslo stáhne pokladní systém. Nicméně problém nastává, pokud do právě probíhajícího hovoru začne volat další zákazník. Tato informace se také uloží do databáze, každopádně již není nijak zaručeno, že vydrží čekat na lince než obsluha dohovoří a příchozí hovor příjme. Pokud volající položí hovor, tak informace je uložena v databázi a jakmile obsluha ukončí probíhající hovor, tak v pokladním systému vyskočí informace, že volá další zájemce, nicméně na mobilním telefonu žádná zmínka o tom, že zrovna někdo volá nebude, bude tam pouze zmeškaný hovor od daného volajícího. Druhou možností je identifikovat hovor až po přijetí hovoru, čímž odpadá problém zmíněný výše. Bohužel je prodleva mezi zapsáním do databáze a dotázáním se pokladny na novou informaci. Pokud by se pokladní systém každou sekundu dotazoval, zda nepřibyla nová informace, značně by to zpomalilo celkový chod systému. Z mého pohledu je samotná druhá varianta nešťastná, jelikož do pokladny vyskočí informace až po přijetí hovoru, čímž ztrácíme možnost oslovit zákazníka příjmením. Pokud bychom druhou variantu upravili tím způsobem, že bychom nastavili obousměrnou komunikaci, tedy i komunikace pokladního systému směrem k mobilnímu telefonu, bylo by možné zákazníka oslovovat jménem. Samozřejmě, pokud volá nový klient, tak nevíme jak jej oslovit. Nastává tedy klasický proces, a to uložení nového zákazníka. Pokud volá již podruhé, zobrazí se nám údaje o něm, nicméně na mobilním telefonu je zobrazeno jen mobilní číslo, pokud nedošlo k ručnímu uložení i do mobilního telefonu. Ve většině případů obsluha ukládá volajícího pouze do pokladního systému, nikoliv do mobilního telefonu. Pokud

Analýza

54

bychom zaručili, že po uložení zákazníka do pokladního systému se telefonní kontakt propíše i do mobilního telefonu, tak při každém dalším hovoru by se na displeji zobrazil volající. Následně bychom volajícího oslovili jménem a příjmením, přičemž by se mezitím informace uložila do databáze, kterou by si obratem natáhl pokladní systém a informace zobrazil na obrazovce pokladny. Pro synchronizaci kontaktů je možné využít kontaktů od společnosti Google, které se automaticky s mobilním telefonem synchronizují, tedy by stačilo kontakty ukládat přes webové rozhraní sloužící pro náhled a úpravu kontaktů. Nevýhodou bezdrátového řešení je neustálá nutnost připojení k internetu, což může občas vést k poruchovosti, pokud dojde k přerušení připojení u pokladny či mobilního telefonu. Pokud bychom ale do mobilního telefonu ukládali informace o zákaznících, tak v případě výpadku internetu bychom mohli zákazníky jednodušeji vyhledávat dle jména a příjmení, ještě než bychom hovor přijali. Pokud by se zobrazil neznámý kontakt, bylo by nutné zákazníka klasickým způsobem uložit, s tím, že by bylo nutné ještě uložit telefonní číslo ve správném formátu pro pozdější identifikaci. 5.1.2

Propojení s www

I zde je několik variant propojení s pokladním systémem. Pokud je pokladna desktopovou aplikací, je nutné nějakým způsobem komunikovat s webovým serverem. Pokud pokladní systém běží na webovém serveru, tak je komunikace jednodušší. Nejčastější variantou je aktualizace XML souboru. V praxi to vypadá tak, že na webovém serveru je uložen XML soubor, který se neustále aktualizuje. Pokud zákazník vytvoří novou objednávku, tak dodavateli a zákazníkovi dorazí email o provedené objednávce. Současně se aktualizuje i XML soubor, který musí být v předem daném formátu. Pokladní systém v pravidelném intervalu kontroluje XML soubor, jestli nepřibyl nový záznam. Vždy si pamatuje poslední ID objednávky. Pokud je posledně uložené ID jiné než poslední ID v seznamu, pokladní systém stáhne nové informace a uloží je do databáze. Před uložením je ještě nutné zkontrolovat, zdali se zákazník již v databázi nachází či ne. Jako jednoznačný identifikátor je možné použít telefonní číslo, přičemž ve formuláři na webových stránkách musíme zajistit, aby byl vždy ve stejném formátu, tedy je vhodné dát uživateli náhled požadovaného value a následně po odeslání formuláře otestovat, jestli je pole opravdu správně vyplněno. Druhým identifikátorem může být emailová adresa zákazníka. Pokud je na straně www možnost vytvoření uživatelského účtu, je možné použít jednoznačné ID zákazníka, které je uloženo na straně www a je pro každého zákazníka jednoznačné. Pro motivaci zákazníků je vhodné za zaregistrování uživatelského účtu dát nějaké zvýhodnění, formou slevy nebo formou načítání zákaznického bonusu. Po ověření zákazníka je nutné ověřit i adresu uvedenou na objednávce. Pokud je adresa totožná se záznamem v databázi, není nutné vytvářet novou. Pokud ne, vytvoří se nový záznam v tabulce, kde bude uložen i identifikátor zákazníka pro spárování. Poté jsme schopni na straně pokladního

Analýza

55

systému zobrazit všechny adresy daného zákazníka. V případě adresy dodání je nutné použít oddělené pole pro ulici, číslo popisné a město. Dále je potřeba zkontrolovat, jestli jednoznačné identifikátory sortimentu, které se načetly z XML souboru jsou uloženy v tabulce, v které jsou uloženy ceníkové položky, tedy nabídka sortimentu pokladního systému. Pokud některý identifikátor z XML se neshoduje s identifikátorem v databázi, je nutné zobrazit chybové hlášení, protože je objednávka neplatná. Nejčastější chybou bývá chybné zadání na straně www, což způsobil správce webových stránek. Zákazník chybu provést nemohl, ten pouze objednal nabízené zboží, které někdo chybně spároval. Pokud je vše v pořádku, tak se v pokladním systému zobrazí informace o nové objednávce, tedy všechny údaje, které klient na straně www vyplnil a jeho objednané produkty. Následně stačí vytisknout účtenku, pokrm připravit a odvézt zákazníkovi na dodací adresu. Rozvozce značně zpomaluje nalezení adresy dodání. V praxi si adresu dodání ručně vyhledávají na různých mapových portálech. Částečné zrychlení by usnadnila možnost zobrazit adresu dodání v mapě. Tento proces by ale musel být před vytisknutím účtenky, kde by rozvozce zobrazil trasu dodání, což dle mě v praxi není možné. Bohužel většinu času tráví za volantem, tedy čas na vyhledávání adresy je opravdu minimální. Pokud bychom uvažovali nad vylepšením stávajího stavu, připadají v úvahu 2 varianty. První variantou je komunikace pokladního systému spolu s vestavěnou GPS navigací v automobilu. U každého zákazníka v pokladně by se zobrazil jednoznačný identifikátor. Pokaždé, pokud by v seznamu došlo k jakékoliv změně, bylo by nutné provést automatickou aktualizaci v GPS navigaci v automobilu. Samozřejmostí je, že by GPS navigace musela mít i mobilní internet. Rozvozce dostane účtenku spolu s pokrmem, přičemž by na účtence byl vytisknut i jednoznačný identifikátor. Následně by kód zákazníka zadal rozvozce do GPS navigace, kde by se zobrazily adresy, které jsou uloženy u zákazníka. Jedním stisknutím by se vypočítala trasa k zákazníkovi. Toto řešení by bylo značně drahé. Druhou variantou je využití Google Maps. V dnešní době je již pokrytí mobilním internetem na přijatelné úrovni, nicméně by bylo možné navrhnout aplikaci, která by v pravidelném intervalu stahovala aktuální data z pokladního systému. V praxi by objednávkový proces vypadal následovně: 1. Zákazník provede objednávku 2.

Objednávka dorazí do pokladního systému

3.

Přiřazení řidiči

4.

Tisk objednávky do kuchyně

5.

Vytisknutí účtenky

6.

Objednávka se zobrazí na mobilním telefonu rozvozci

7.

Rozvozce zvolí navigovat (je možné spočítat více cílů najednou, průjezd)

8.

Nyní zákazník může sledovat svoji objednávku na www

Analýza

56

Po provedení objednávky zákazníkem dorazí informace do pokladního systému. Obsluha je povinna vybrat z předem definovaných časů doručení, případně objednávku zamítnout nebo vybrat jiný čas doručení. Poté zákazníkovi dorazí email s předpokládanou dobou doručení. Následně přiřadí objednávku danému rozvozci. Každý rozvozce je nějakým způsobem identifikován, nejčastěji číslicí, přičemž má definovanou oblast, pro kterou pokrmy rozváží. Vhodné je, aby před přiřazením se obsluze zobrazil i náhled mapy, aby pro ni bylo jednodušší určit kterému rozvozci danou objednávku přiřadit. Je možné použít i automatické přiřazení, nicméně by bylo nutné mít předem definované zóny, pro které daný rozvozce rozváží a přiřazení by probíhalo automaticky. Nevýhodou ale je, že v daný okamžik může být některý rozvozce více využitý, myslím si, že je lepší přiřazení provádět ručně. Po přiřazení obluha zvolí tisk do kuchyně, kde se vytiskne objednávka daného zákazníka, na které je i uvedeno číslo rozvozce, kterému se objednávka předá. Každé rozvozové auto bude mít mobilní telefon, u kterého bude nainstalována aplikace pro rozvoz, která bude využívat Google Maps. Než dojde k přípravě pokrmu v kuchyni, tak si mobilní aplikace stáhne informace ze serveru. Stahování bude probíhat automaticky, v předem daných intervalech, tedy bude možné aplikaci použít i Offline, kde není přístup k mobilnímu internetu. Jelikož rozvozce tráví většinu času v automobilu, tak telefon bude připevněn neustále v nabíjecí stanici. K dispozici bude i aplikace pro chytré hodinky, které budou veškeré důležité informace zobrazovat na displeji, které budou aktivní i mimo vůz, v dosahu bluetooth technologie. Mobilní aplikace zobrazí všechny objednávky, které má rozvozce vyřídit. Urychlení přinese automatické zadání trasy do GPS navigace, kde kliknutím na danou objednávku se automaticky zadá i adresa. Pokud bude k dispozici více objednávek, bude možnost vypočítat optimální trasu, přičemž server vyhodnotí optimální cestu, tedy budou zvoleny průjezdové body a cílem bude počátek cesty. Dále aplikace zobrazí náhled daných objednávek, které budou položkovitě rozepsány. V aplikaci budou uvedeny adresy dodání, včetně telefonních čísel. Po kliknutí na telefonní číslo proběhne automatické vytočení zákazníka. Jakmile obsluha zvolí vytisknout účtenku dané objednávky, tak pokladní systém pošle informaci serveru, který odešle email s informací, že je objednávka již připravena a je na cestě k zákazníkovi. Součástí bude i URL adresa, s platností 60 minut, kde bude k dispozici náhled mapy, na kterém bude vyobrazena současná poloha automobilu. Není možné, aby každý zákazník viděl jen polohu vozu se svojí objednávkou, jelikož během cesty k zákazníkovi může obsloužit i jiné zákazníky, kteří jsou na dané trase. Proto bude zákazníkovi zobrazena poloha vozu daného rozvozce, který objednávku vyřizuje. Platnost bude 60 minut, což je maximální doba od vytisknutí dokladu až po předání zákazníkovi. Aplikace přinese do daného provozu ušetření nákladů spojených s integrovanými GPS v automobilech. Ve většině firemních vozů jsou integrované GPS, které slouží pro kontrolu vozu. Aplikace bude ukládat pohyb vozu

Analýza

57

pro pozdější kontrolu a řešení případných stížností. Předností bude automatizovaný rozvozový systém, který přinese zrychlení rozvozové služby, čímž se sníží doba rozvozu a bude možné obsloužit více zákazníků v kratším čase, tedy se předpokládá zvýšení tržeb společnosti. Současně se sníží i pravděpodobnost chybného zadání. Zákazník bude informován, kde se nachází jeho objednávka, tedy uvidí předpokládaný čas doručení, který svým způsobem bude velice přesný, neboť mapy v sobě mají integrovanou dopravní situaci v daném městě. Využití služby bude možné i v případě objednávky pomocí telefonu, nicméně bude nutné po zákazníkovi vyžadovat kromě jména, příjmení a adresy i emailové spojení. V případě pokladního systému běžícího jako webová služba je proces objednávky automatizován na straně www. Nevýhodou ale je, že pokud není k dispozici připojení k internetu, tak není funkční objednávková služba a současně i pokladní systém. V případě první varianty zmíněné výše nefunkčnost internetu má pouze vliv na objednávkový systém, na pokladní ne, tedy je alespoň možné provádět objednávky po telefonu, což v případě varianty běžící na webovém serveru možné není. Tuto nevýhodu mají všechny pokladní systémy běžící online. S připravovanou elektronickou evidencí tržeb bude nutné mít pokladní systém neustále připojen k internetu, z důvodu ověření účtenky. Pokud nebude v daný okamžik připojení k internetu, tak bude doklad uložen do fronty, která účtenku vytiskne, nicméně po následném připojení k internetu se informace odešle na příslušný server. Jakým způsobem budou řešeny neočekávané výpadky internetu, tak tato informace ještě známá není. Řešení bude ale muset být ještě specifikováno. Současně se zavedením elektronické evidence tržeb se chystá snížení DPH z 21 % na 15 % (Finanční správa, [online]).

Obr. 17

Propojení s www

Analýza

5.1.3

58

Propojení s damejidlo.cz

V případě propojení s objednávkovou službou damejidlo.cz připadá několik variant. Upozornění na novou objednávku chodí restauraci emailem nebo formou sms. V případě emailu by bylo možné napsat skript, který by dané informace z emailu stahoval a posílal do databáze pokladního systému. Bylo by ale nutné mít totožné názvy na straně webového serveru, tedy objednávek a pokladního systému. Párování na základě ID by v tomto případě nebylo možné. Forma sms je jedna z možností jak dostat informace o uživatelích a jejich objednávkách. Bohužel i zde nastává problém ohledně párování s ID ceníkových položek v pokladním systému. Poslední možností je přímé propojení s damejidlo.cz, ale bohužel v současné době není k dispozici žádné API, které by umožnilo komunikaci. Nad projektem damejidlo.cz, tak zůstává velký otazník, jelikož v případě spolupráce s pokladními systémy by jednak svým klientům (restauracím) ušetřili čas i práci a z mého pohledu by zvýšili i počet restaurací, které přes daný portál nabízejí. Současně by bylo možné i objednávku rychleji vyřídit, jelikož jakmile dorazí nová objednávka, tak je nutné ji nejprve ručně přepsat do pokladního systému a poté odeslat objednávku do kuchyně. Mezi těmito kroky může být nějaká časová prodleva, která svým způsobem snižuje čas dodání ke spokojenosti zákazníka.

Návrh

59

6 Návrh Důležitou částí vývoje aplikací je návrh aplikace. Bude se jednat o webovou službu, která bude zobrazovat aktuální informace z pokladního systému.

6.1 Specifikace požadavků Šilhavý a kol. (2013) definují, že „požadavky je možné popsat jako popis funkce budoucího systému nebo podmínku jeho fungování, přičemž obě tyto entity jsou definovány zadavateli.“ 6.1.1

Funkční požadavky

Funkční požadavky nám popisují služby, které byl měl systém vykonávat v závislosti na vstupech uživatele v daných situacích. Funkční požadavky mohou být obecné a také velice specifické. Vždy záleží na konkrétní části, ke které se vztahuje daná specifikace. Pokud je specifikace nepřesná, přináší to značné problémy (Sommerville, 2013). Systém bude dostupný pouze pro zvolený personál daného provozu, přičemž každý uživatel bude mít přihlašovací jméno a heslo. Uživatele bude moci odlišit dle příslušných práv. Zákazníci budou informováni emailem o stavu objednávky. Současně se jim vygeneruje adresa pro zobrazení aktuální pozice vozu. Databáze se bude aktualizovat na základě synchronizace s pokladním systémem. V pravidelném intervalu bude docházet k dotazům se pokladního systému, zdali nedošlo k nějaké změně v databázi. Následně se potřebná data přenesou na stranu serveru. Po přenesení dat dojde ke kontrole, zdali nedošlo ke změně stavu objednávky. Pokud došlo k přijetí, dojde k zakreslení do mapy. Mapa bude přístupná pouze pro uživatele s příslušnými právy. Následně je objednávka ve formě přípravy. Zákazník je informován emailem. Jakmile obsluha vytiskne doklad k objednávce, dojde ke změně stavu objednávky, ta bude již vyřízena a bude předána rozvozci. Zákazník je informován emailem, kde je příslušný odkaz, který obsahuje aktuální polohu vozidla, které objednávku veze. Současně se rozvozci zobrazí objednávka na příslušném zařízení. Zobrazení probíhá na mapovém podkladu. K dispozici jsou veškeré objednávky, které nejsou odvezeny daným rozvozcem koncovému zákazníkovi. 6.1.2

Nefunkční požadavky

Roudenský a Havlíčková (2013) specifikují, že „nefunkční požadavky popisují určité vlastnosti systému či omezující podmínky. V podstatě říkají, jaký by systém měl být.“ Pro implementaci bude využit jazyk HTML, PHP, JavaScript. Jako databázový systém bude použit MySQL. Aplikace bude dostupná přes webové rozhraní. Jako podkladové mapy budou využívány Google Maps. Automaticky vygenerované URL

Návrh

60

pro zákazníky bude k dispozici jen 60 minut. Po vyřešení objednávky rozvozcem objednávka zmizí z rozvozové mapy. Grafy budou vyobrazeny pomocí Google Charts.

6.2 Funkční model 6.2.1

Kontextový diagram

Zakaznik

Objednavka s ortimentu Nabidka sortimentu Potvrzeni vyres ene objednavky

1 Objednavky k rozvozu

Objednavka zakaznika

Rozvozc e

Pokladni sys tem

IS Rozvoz Potvrzeni objednavky

+

Prirazeni rozvozc i

Informac e o umis teni rozvozc e

Kontrola objednavky

Obs luha

Obr. 18

Kontextový diagram

Kontextový diagram obsahuje proces IS Rozvoz. Do procesu vstupují a vystupují z něj čtyři externí entity. Entita Zakaznik je uživatel, který provede objednávku přes webové rozhraní nebo za pomocí mobilního telefonu. Z dané entity vystupuje jeden datový tok, a to Objednavka sortimentu. Vstupují dva datové toky, a to Nabidka sortimentu a Potvrzeni vyresene objednavky.

Návrh

61

Entita Pokladni system je externí systém, z kterého jsou čerpána data pro plánování rozvozových tras danému rozvozci. Do entity vstupuje datový tok Objednavka zakaznika a vystupuje z ní Potvrzeni objednavky. Entita Obsluha provádí obsluhu pokladního systému. Z entity vystupuje datový tok Prirazeni rozvozci a Kontrola objednavky. Poslední entitou je Rozvozce, do které vstupuje Objednavky k rozvozu a vystupuje Informace o umisteni rozvozce. 6.2.2

Systémový diagram 2

Zakaznici

Zakaznici 4 1.1

Udaje zakaznik

Nekorektni objednavky

Evidence zakazniku

Zakaznik

Objednavky Kontaktni udaje zakaznik

[Objednavka sortimentu]

1.2

[Kontrola objednavky]

Obsluha

[Nabidka sortimentu]

Zakaznik

Evidence sort imentu Informace o potvrzene objednavce Informace zakaznik

[Potvrzeni objednavky]

Potvrzeni pripravy objednavky

Pokladni system

Evidence objednavek

Objednavky

5

Pokladni system

1.3

Veskere objednavky

ID objednavka

[Objednavka zakaznika]

ID zakaznik

3

Souradnice vozu

Souradnice Informace objednavka 1.4 Evidence pripravenych objednavek

Obsluha [Prirazeni rozvozci]

Udaje zakaznici

[Objednavky k rozvozu] Rozvozce

Umisteni rozvozce [Potvrzeni vyresene objednavky] [Informace o umisteni rozvozce]

Archivace objednavek

Zakaznik 1

Obr. 19

Objednavky rozvoz

Systémový diagram

Rozvozce

Návrh

62

Systémový diagram vznikl dekompozicí procesu IS Rozvoz v kontextovém diagramu. Skládá se celkem ze 4 procesů. Proces Evidence zakazniku slouží k přiřazení objednávky danému zákazníkovi. Všichni zákazníci jsou ukládáni do datastore Zakaznici za pomoci datového toku Zakaznici. Tímto způsobem se vytváří evidence všech zákazníků, kteří provedli objednávku. Do procesu tedy vstupuje od entity Zakaznik datový tok Udaje zakaznik a z procesu vystupuje Kontaktni udaje zakaznik. Proces Evidence sortimentu shromažduje veškerou nabídku, kterou může zákazník objednat. Daný sortiment se poté může vyskytnout na objednávce. Z procesu vystupuje datový tok Nabidka sortimentu, který vstupuje do entity Zakaznik. Proces obdrží od entity Zakaznik datový tok Objednavka sortimentu. Následně obdrží od procesu Evidence zakazniku datovy tok Kontaktni udaje zakaznik. Entita Obsluha zašle datový tok Kontrola objednavky. Entita Pokladni system zašle Potvrzeni objednavky. Nekorektní objednávky jsou uloženy do datastore Nekorektni objednavky. Do procesu Evidence objednavek vstupují datové toky Informace zakaznik a Informace o potvrzene objednavce. Proces zašle do entity Pokladni system datový tok Objednavka zakaznika. Současně je zasláno i entitě Zakaznik Potvrzeni pripravy objednavky. Do datastore Veskere objednavky vstupuje datový tok Objednavky. Z procesu vychází datové toky ID zakaznik a ID objednavka. Proces Evidence pripravenych objednavek provádí veškeré náležitosti spojené s objednávkou. Přijímá datové toky ID objednavka, ID zakaznik od procesu Evidence objednavek. Od datastore Veskere objednavky obdrží datový tok Informace objednavka. Entita Obsluha zašle informaci Prirazeni rozvozci. Od entity Rozvozce obdrží proces Informace o umisteni rozvozce. Entita Rozvozce obdrží datový tok Objednavky k rozvozu. Z datastore Souradnice vozu se synchronizují souřadnice za pomoci datového toku Souradnice. Z datastore Zakaznici obdrží proces datový tok Udaje zakaznici. Entita Zakaznik obdrží datové toky Potvrzeni vyresene objednavky a Umisteni rozvozce. Veškeré vyřízené objednávky se ukládají do datastore Objednavky rozvoz za pomoci datového toku Archivace objednavek.

6.3 Datový model 6.3.1

Entitně relační model

Model, který popisuje aplikaci za účelem zachycení struktury databáze. Jednotlivé entity (tabulky) popisujeme krátkým názvem. Entity obsahují atributy, které mají definovaný datový typ. Tedy množinu, která definuje množinu přístupných hodnot. Entity jsou mezi sebou propojeny vzájemnými vazbami (Lacko, 2011).

Návrh

Obr. 20

63

Entitně relační diagram

Výše navržený diagram zachycuje strukturu databázového systému. Entita Uzivatel ukládá informace o uživatelích systému. Jednoznačný identifikátor idUzivatel slouží k tomu, aby nebylo možné uložit více osob se stejným identifikátorem. Tento klíč se generuje automaticky, tedy při vytvoření nového uživatele systému. Povinný atribut UzivatelskeJmeno slouží pro identifikaci na straně www, kde je

Návrh

64

ošetřeno, že i tento identifikátor musí být jedinečný. Podmínka je stanovena na straně www. Dalšími povinnými atributy jsou Jmeno, Prijmeni a Heslo. Heslo je šifrováno za pomoci algoritmu SHA11. U uživatele je dále uložen cizí klíč identifikátor jeho vozu, atribut Automobil_idAutomobil, který se nachází v entitě Automobil. Entita Automobil slouží pro uložení vozů. Každý uživatel musí mít přiřazený daný vůz. Pro uložení typu vozu slouží povinný atribut Oznaceni. Entita Souradnice_vozu uchovává zeměpisnou šířku a délku o daném vozu. Tyto informace jsou uloženy v atributech Zemepisna_sirka a Zemepisna_delka. Součástí je i cizí klíč Uzivatel_idUzivatel, který vůz užívá. Je to z toho důvodu, že daný vůz může využívat více uživatelů. Součástí entity je i atribut Cas, který v případě uložení zeměpisné šířky a délky vloží aktuální čas a datum. Součástí je i cizí klíč Automobil_idAutomobil z entity Automobil. Zákazníci jsou uloženi v entitě Zakaznik, kde jsou povinnými atributy Jmeno, Prijmeni a Email. Jelikož zákazník může mít více adres a telefonních čísel, tak jsou vytvořeny entity Adresa a Telefon. Adresa obsahuje povinné atributy Ulice, Cislo_popisne, PSC a Mesto. Zemepisna_sirka a Zemepisna_delka není povinná z toho důvodu, že v případě vytvoření adresy zákazníka ještě neznáme souřadnice dané adresy. Tyto atributy se naplní, až je na straně www spuštěn skript, který zjistí souřadnice daného místa. Cizím klíčem je Zakaznik_idZakaznik, v kterém je uloženo ID zákazníka. Zákazník tedy může mít více adres. Entita Telefon slouží k uložení telefonního čísla daného zákazníka. Pro uložení slouží atribut Telefon. Cizím klíčem je Zakaznik_idZakaznik, tedy každý zákazník může mít více telefonních čísel. Sortiment ukládá jednotlivé ceníkové položky, které na straně www může zákazník objednat. Pro uložení slouží atribut idSortiment, který je zároveň i primárním klíčem. Dále Nazev pro uložení názvu sortimentu, Cena a Jednotka, která obsahuje výčet ks, kg a l. Entita Objednavka uchovává cizí klíč Zakaznik_idZakaznik a cizí klíč Adresa_idAdresa. Cizí klíč pro uložení adresy je z toho důvodu, že jak již bylo zmíněno, tak zákazník může mít více adres, tedy je nutné k objednávce přiřadit správnou adresu. Poté stav objednávky, který může mít stav nepřijato, přijato, hotovo. Pro uložení stavu slouží výčtový atribut Stav. Dále Cas_objednavky pro uložení přesného data a času vytvoření objednávky. Polozky_objednavky uchovávají cizí klíč Objednavka_idObjednavka z entity Objednavka a Sortiment_idSortiment z entity Sortiment. Primárním klíčem je idPolozkyObjednavky. Povinný atribut je Pocet, kde je uvedeno množství objednaného sortimentu. V praxi to tedy vypadá tak, že entita Objednavka může mít více položek objednávky, tedy daný zákazník je schopen objednat více než jednu položku z nabízeného sortimentu. Vždy záleží, jaký rozdílný sortiment SHA1 je šifrovací algoritmus, který zadaný řetězec zašifruje do 40znakového řetězce (Kofler, 2005). 1

Návrh

65

zákazník objedná, který se následně přiřadí pod jeden identifikátor objednávky a dané položky objednávky již obsahují identifikátory z entity Sortiment. Tedy podle počtu druhu sortimentu je vytvořeno tolik záznamů v entitě Polozky_objednavky, které obsahují jednotlivé identifikátory z entity Sortiment. Entita Rozvoz uchovává informace o objednávce a daném uživateli, tedy v našem případě rozvozci. Primárním klíčem entity je idRozvoz. Cizími klíči jsou Objednavka_idObjednavka z entity Objednavka a Udaje_rozvozce_Kod z entity Uzivatel. Poslední entitou je Udaje_restaurace, kde jsou povinnými atributy Nazev, Ulice, Cislo_popisne, PSC, Mesto, Zemepisna_sirka a Zemepisna_delka. Tato entita uchovává informace o dané restauraci, která používá objednávkový systém.

Implementace

66

7 Implementace Aplikace je dostupná ve webovém prostředí. Veškeré informace se zobrazí až po přihlášení uživatele. Systém je rozdělen celkem do dvou skupin uživatelských práv. První skupinou je administrátor, který má veškerá práva pro změny a nastavení v systému. Druhou jsou uživatelé, tedy rozvozci. Každý uživatel má vygenerované uživatelské jméno a heslo, které slouží pro přihlášení. Uživatelské jméno musí být v rámci databáze jednoznačné. Minimální délka hesla uživatele je 6 znaků.

7.1

Pohled administrátora

Administrátor má k dispozici ihned několik modulů, které může spravovat. Prvním jsou Rozvozci, kde vytváří jednotlivé uživatele. Následně spravuje Objednávky, které za pomoci modulu Mapa k rozvozu je schopen zakreslit do mapy. Nabídka zobrazuje aktuální sortiment, tedy co může zákazník objednat přes webové stránky. Modul Zákazníci zobrazují veškeré informace o zákaznících, kteří alespoň jednou provedli objednávku. Statistika zobrazuje celkové a detailní přehledy za poslední 2 týdny.

Obr. 21

Moduly administrátora

7.1.1

Rozvozci

V tomto modulu administrátor spravuje uživatele dané aplikace. Je zde zobrazen seznam všech rozvozců, kteří se mohou pod zadaným uživatelským jménem a heslem přihlásit do systému. U každého uživatele je možné změnit všechny jeho atributy, kromě uživatelského jména, protože je důraz kladen na jednoznačnost uživatelského jména. Pokud je vytvářen nový uživatel, tak je nutné vyplnit uživatelské jméno, heslo a heslo ověření, u kterého je minimální délka 6 znaků. U jména a příjmení je kladen důraz na minimální délku 4 znaků u obou atributů. Poté se vybere ze seznamu vůz, který je uživateli přiřazen. Pokud jsou veškeré parametry zadány korektně, k odeslání formuláře dojde stiskem tlačítka Vložit. S databází se porovná, zdali se uživatelské jméno ve formuláři neshoduje se záznamem v databázi. Pokud ano, je nutné zadat jiné uživatelské jméno. Pokud ne, dojde k uložení rozvozce, který se následně může pod zadanými údaji přihlásit. Pokud je nutné některé parametry změnit, tak u rozvozce zvolíme Upravit. Pole pro uživatelské jméno není možné změnit, je to z důvodu jednoznačnosti v databázi. Ostatní atributy je možné změnit, vždy se kontroluje, jestli je formulář zadán korektně. V případě smazání uživatelského účtu je u formuláře aktualizace osoby tlačítko Smaž, které vymaže daného uživatele z databáze.

Implementace

Obr. 22

Správa uživatelů

7.1.2

Objednávky

67

Administrátor má v sekci Objednávky k dispozici veškeré objednávky, se kterými může následně pracovat. U stavu objednávky je možné vybrat celkem ze 3 různých stavů, a to nepřijato, přijato a hotovo. Pokud administrátor, tedy osoba pověřená k přerozdělování objednávek zvolí stav hotovo, tak zákazníkovi automaticky dorazí email, že jeho objednávka byla přiřazena rozvozci, který objednávku doručí. Stav objednávky je také možné měnit z pozice rozvozce. Logika zasílání emailů je u rozvozce také zachována. Přiřazení objednávky rozvozci může pouze administrátor. Po rozkliknutí roletky se zobrazí seznam všech uživatelů, tedy rozvozců, kteří jsou v systému uloženi. Tlačítkem Aktualizovat dojde k uložení změněných parametrů.

Implementace

68

Pokud osoba rozdělující objednávky si není jista, kterou objednávku jakému rozvozci přiřadit, tak je k dispozici tlačítko MAPA. Následně se zobrazí náhled mapy, kde je cílová adresa umístěna špendlíkem. Po najetí na daný bod se zobrazí údaje o zákazníkovi, tedy jméno, příjmení, adresa a telefonní číslo. Je to z toho důvodu, že ve většině případů mají rozvozci přiřazené lokality, pro které rozváží a uživatel, který přerozděluje objednávky nemusí vědět, do jaké lokality zadaná adresa náleží. Tento proces by bylo možné zautomatizovat, nicméně se často stává, že některý rozvozce je časově více vytížen než jiný, tedy se objednávka přiřadí jinému. 7.1.3

Mapa k rozvozu

V této sekci jsou zobrazeny veškeré objednávky na mapovém podkladu. Po najetí na daný bod se zobrazí údaje o zákazníkovi a uživatelské jméno rozvozce. Tato mapa slouží pro lepší orientaci uživatele přiřazujícího objednávky, z které je schopen odvodit, které adresy dodání se nacházejí blízko sebe, tedy je schopen upravit rozvozce, který objednávku vyřizuje. 7.1.4

Nabídka

Přehledná tabulka sortimentu, který si může zákazník objednat. Jsou zde rozepsané jednotlivé ceny položek a jejich jednotky. Další sloupec informuje o prodejích v aktuálním týdnu. Současně je k dispozici přehled předchozího týdne a součty celkových prodejů daného sortimentu.

Obr. 23

Nabídka sortimentu

7.1.5

Zákazníci

Zobrazení všech zákazníků, kteří jsou v systému uloženi. U každého zákazníka jsou zobrazeny kontaktní údaje, jako je email, adresa dodání a telefonní číslo. V případě, že má zákazník více dodacích adres nebo telefonních čísel, jsou zobrazeny všechny uložené kontaktní údaje daného zákazníka. Dalšími informacemi, které jsou u každého zákazníka je celkový počet provedených objednávek, jeho nejoblíbenější sortiment a celková částka, za kterou zákazník provedl nákup. Veškeré hodnoty jsou vypočítány na základě aktuálních dat v databázi.

Implementace

7.1.6

69

Statistika

V této sekci je k dispozici statistika daného provozu. V první části je zobrazena celková statistika, která informuje o celkovém počtu zákazníků uložených v systému. Dále je zobrazen zákazník, který provedl nejvíce objednávek a zákazník, který v součtu objednal za největší částku. Statistika celkového počtu všech objednávek a jejich souhrnná částka. Informativně je zobrazena i nejprodávanější položka, která je vypočítaná na základě souhrnu dle počtu prodaných kusů. Součástí je i cenové přepočítání dle ceny a počtu kusů. Za pomoci grafu je vykreslena křivka obsahující součty prodejů za jednotlivé dny. K dispozici jsou dva grafy, první zobrazuje statistiku aktuálního týdne a druhý týdne předchozího. Součástí je výpočet nejprodávanější položky za daný a předchozí týden.

Obr. 24

Statistika administrátora

Implementace

70

7.2 Pohled rozvozce Rozvozce má k dispozici modul Objednávky, který zobrazuje jeho objednávky k vyřešení, Mapu k rozvozu, Nabídku sortimentu, seznam zákazníků, tedy Zákazníky a Statistiku daného rozvozce.

Obr. 25

Moduly rozvozce

7.2.1

Objednávky

Modul Objednávky je stejný jako u administrátora, nicméně jsou zobrazeny pouze ty objednávky, které má přihlášený uživatel, tedy rozvozce vyřešit. Řazení probíhá dle poslední objednávky, tedy vždy poslední objednávka je nahoře seznamu. Rozvozce má na výběr ze 3 přednastavených stavů objednávky. Pokud zvolí stav hotovo, danému zákazníkovi na email dorazí informace o objednávce. Oproti administrátorovi není schopen změnit rozvozce dané objednávky. Tuto vlastnost může pouze osoba s příslušnými administrátorskými právy. Pokud je nutné změnit rozvozce, je potřeba zkontaktovat administrátora. Změna stavu objednávky dojde výběrem hodnoty ze seznamu a následné potvrzení výběru proběhne tlačítkem Aktualizovat. Pokud si daný rozvozce není jist adresou dodání, je k dispozici tlačítko MAPA, která zobrazí cílovou adresu na mapovém podkladu, včetně informací o daném zákazníkovi. Tato funkce značně usnadní svoji práci uživatelům, kteří neznají dané město. Odpadá tedy ruční přepisování adresy do vyhledávače.

Implementace

Obr. 26

Objednávky

7.2.2

Mapa k rozvozu

71

V této sekci jsou zobrazeny veškeré objednávky, které má k řešení daný rozvozce. Zobrazení je na mapovém podkladu. Zobrazí si tedy všechny potřebné informace, které potřebuje k vyřešení objednávky. Do praxe to přináší značné urychlení celkového procesu. Rozvozce dopředu ví, kam kterou objednávku poveze, z čehož je schopen odvodit celkovou trasu. Pokud přijde nová objednávka, tak se ihned zobrazí do mapy a rozvozce je schopen na to obratem reagovat. Pokud se nová objednávka nachází poblíž adresy, na kterou má dopravit objednávku starší, je schopen setrvat a zažádat o urychlení nové objednávky, aby nebylo nutné jet na dané místo dvakrát. Toto vše značně přinese ušetření času a financí spojených s rozvozem. Pokud rozvozce najede na daný špendlík v mapě, zobrazí se mu potřebné informace o zákazníkovi.

Implementace

Obr. 27

Mapa k rozvozu

7.2.3

Nabídka

72

Nabídka je stejná jako v případě přihlášení administrátora, tedy je zobrazen veškerý sortiment včetně jednotek, prodejních cen, součtu prodejů za aktuální a předchozí týden a součet celkového prodeje dané organizace. 7.2.4

Zákazníci

Modul zákazníci zobrazuje všechny zákazníky, kteří alespoň jednou provedli objednávku. Součástí je výpis adres, telefonních čísel, počtu objednávek, nejoblíbenějšího sortimentu a celkové tržby daného zákazníka.

Obr. 28

Zákazníci

Implementace

7.2.5

73

Statistika

Přehledná statistika znázorňující celkový počet vyřešených objednávek a jejich souhrnná částka. Přehled se vztahuje k právě přihlášenému uživateli. Tyto informace jsou zobrazeny textově. Graficky jsou reprezentovány součty rozvozů daného uživatele dle jednotlivých dnů. Zobrazené období je vždy aktuální týden.

Závěr

74

8 Závěr Navržená aplikace byla implementována v rozsahu nutném pro posouzení její funkcionality. Systém je dostupný pro registrované uživatele, které je možné rozdělit na dvě skupiny dle jejich práv. První skupinou je uživatel s administrátorskými právy, který má plná práva pro administraci systému. Druhou skupinou jsou uživatelé, v našem případě rozvozci, kteří systém mohou používat pro nahlížení a editaci stavu objednávek, které k nim náleží. Výsledná aplikace je zcela nezávislá na jakémkoliv pokladním systému, z čehož vyplývá, že v případě nasazení ke koncovému zákazníkovi odpadá jakákoliv nutnost měnit logiku výsledného systému. Jediné, co je potřeba upravit, tak je komunikace mezi daným pokladním systémem a výslednou aplikací. V praxi by to znamenalo úpravu skriptu sloužícího pro komunikaci mezi koncovou pokladnou. Část pro komunikaci mezi výslednou aplikací je již hotova. Implementované řešení je postaveno na své vlastní databázi, která se dynamicky mění v závislosti na datech v pokladním systému. Pokud do pokladního systému příjde nová objednávka, tak se vše automaticky propíše do webové aplikace, tedy do navrženého a implementovaného řešení. Objednávka se do pokladního systému může vložit jako požadavek z webových stránek, tudíž někdo na straně www provede objednání daného sortimentu. Druhou možností je vložení objednávky uživatelem pokladny, tedy obsluhou pokladního systému. Nyní již záleží na osobě pověřené k přerozdělování objednávek či rozvozci, jak se k dané objednávce postaví. V prvém kroku musí administrátor, osoba spravující objednávky vybrat uživatele, v našem případě rozvozce, který danou objednávku vyřizuje. Současně je schopna i vybrat z předem stanovených stavů objednávky, a to nepřijato, přijato a hotovo. Následně se objednávka zobrazí uživateli, kterému byla přidělena. Pokud si není jist cílovou adresou zákazníka, tak jedním kliknutím zobrazí daného zákazníka na mapovém podkladu. Tato funkce odstraňuje nutnost některých rozvozců ručně vyhledávat adresu na některém z mapových portálů. Pro lepší přehled je k dispozici i celková mapa objednávek. Mapa je celkem ve dvou úrovních, přičemž první slouží pro administrátora, který vidí veškeré objednávky, jenž jsou k vyřízení a ještě nedorazily k zákazníkovi. Výhodou je, že je schopen operativně přerozdělovat dané objednávky jednotlivým rozvozcům. Ještě než přiřadí objednávku danému rozvozci, tak je schopen si ji nejprve zobrazit v mapě a až následně přidělit danému rozvozci. Současně vidí i veškeré objednávky v jednom pohledu. Druhá úroveň je pro rozvozce, kteří vidí veškeré své objednávky na jednom místě. Je schopen vyvodit, zdali na nově příchozí objednávku setrvat a urychlit tak proces její výroby, aby tak mohl efektivněji využít svoji rozvozovou trasu. Pokud administrátor, či rozvozce změní stav objednávky na hotovo, tak danému zákazníkovi dorazí email, že je jeho objednávka již hotova a bude doručena vybraným rozvozcem. Posledním prvkem v celkovém procesu je předání objednávky koncovému zákazníkovi, čímž celkový proces končí.

Závěr

75

8.1 Ekonomické zhodnocení Pro vlastní chod aplikace je nutné mít na běžném počítači nainstalovaný Apache server a databázový systém MySQL. V druhém případě je možné aplikaci rozběhnout na některém z dostupných webových serverů. Pro naplnění databáze daty je nutné systém propojit s některým z dostupných pokladních systémů. Při pořízení pokladního systému do daného subjektu vzniká objednavateli náklad. Vynaložené náklady jsou odvislé od konkrétního řešení a implementace. Vždy záleží na konkrétním subjektu, který bude pokladní systém využívat. Pokud se bude jednat o restauraci či jinou provozovnu kde zákazníci tráví déle času, tak je lepší zakoupit modernější zařízení, které musí pracovat s několika daty současně, jelikož v jeden okamžik může být obsluhováno více zákazníků současně a všechny otevřené stoly musí být uchovány než dojde k uzavření, tedy k zaplacení. Pokud se ale jedná o provoz, kde zákazník objedná a dojde ihned k zaplacení, domnívám se, že stačí řešení menšího rozsahu, protože není nutné zpracovávat několik dat současně. Samozřejmě ale vždy záleží na daném subjektu, co od pokladního systému opravdu očekává. Dne 13. 4. 2016 nabyl platnost zákon o elektronické evidenci tržeb. Z čehož vyplívá, že od 1. 12. 2016 bude nutné každý hotovostní prodej elektronicky ověřit, čímž se vystaví účtenka, která bude na webovém serveru uložena. Každá účtenka bude mít k dispozici unikátní kód. Tato povinnost se týká subjektů provozujících svoji činnost v oblasti stravování, pohostinství a ubytování. Následně tato povinnost čeká i ostatní činnosti. Nutnost zakoupit pokladní systém tedy čeká všechny subjekty (AMSP ČR, [online]). Z mého pohledu ale velké společnosti jako O2 Czech Republic a.s., T-mobile Czech Republic a.s., či Vodafone Czech Republic a.s. budou schopni nabídnout řešení, kterému budou velice těžko současní dodavatelé pokladních systému cenově konkurovat. Cílem současných dodavatelů je nabídnout koncovým zákazníkům řešení, které uspokojí jejich potřeby, přičemž jednorázovým poplatkem nebo formou nájmu či nájmu s odkupem profitovat z dodaného řešení. Veškeré jejich tržby se tedy točí kolem dodaného řešení. Pokud operátoři mobilních sítí budou nabízet řešení pokladního systému v rámci internetových balíčků zdarma, tak mnoho současných dodavatelů bude muset dle mého názoru ukončit svoji působnost na tomto poli. Záleží ale, jak se výše zmínění operátoři k dané službě postaví. Z mého pohledu je ale tato varianta značné možná, jelikož pro elektronickou evidenci tržeb je nutné mít připojení k internetu, tudíž získají nové zákazníky, kteří budou využívat jejich nabízené služby a jako bonus obdrží pokladní systém zdarma. Jediná investice, která bude subjekty čekat, tak je nákup zařízení, na kterém daná aplikace poběží a tiskárna pro tisk účtenek. Nutností bude i objednání bezdrátového internetu, pro ověření dané účenky. Jak se k řešení na našem trhu postaví operátoři, záleží pouze na nich. Pokud se vydají cestou zdarma, osloví mnohem více zákazníků, díky kterým mohou zvýšit svoje tržby ostatními službami, které jim mohou nabídnout.

Závěr

76

Samozřejmě ale vždy záleží na uživateli, co od pokladního systému očekává, tedy jaké operace bude s pokladním systémem provádět.

Literatura

77

9 Literatura ABX SOFTWARE S.R.O. [online]. [cit. 2015-08-03]. Dostupné z: http://www.ab-x.cz/ AGNIS S.R.O. [online]. [cit. 2015-08-03]. Dostupné z: http://www.agnis.cz/ AMAX COM S.R.O. [online]. http://www.prodejpokladen.cz/

[cit.

2015-08-09].

Dostupné

z:

AMAZON WEB SERVICES, INC. [online]. [cit. 2015-12-09]. Dostupné z: https://s3.amazonaws.com/cdn.freshdesk.com/data/helpdesk/attachments/ production/ 6005198987/original/blob1442305165827.jpeg?1442305167 AMSP ČR [online]. [cit. 2016-04-18]. Dostupné http://www.eltrzby.cz/cz/aktuality/88-evidence-trzeb-nabyla-platnosti

z:

ASW SYSTEMS A.S. [online]. [cit. 2015-12-05]. Dostupné z: http://www.septim.cz/ AWIS HOLDING, A.S. [online]. [cit. 2015-12-02]. Dostupné z: http://www.awiscz.com BALSAMIQ STUDIOS, LLC: Balsamiq Mockups [online]. [cit. 2015-08-12]. Dostupné z: http://www.balsamiq.com/ BRUCKNER, TOMÁŠ. Tvorba informačních systémů: principy, metodiky, architektury. Praha: Grada, 2012. Management v informační společnosti. ISBN 978-80-2474153-6. BY MICHELE E. DAVIS AND JON A. PHILLIPS. Learning PHP and MySQL. 2nd ed. Sebastopol, Calif: O'Reilly, 2007. ISBN 0596551657. CÍGLER SOFTWARE, A.S. http://www.money.cz/

[online].

[cit.

2015-10-03].

Dostupné

CZECHCRUNCH.CZ [online]. [cit. 2015-10-01]. Dostupné http://www.czechcrunch.cz/wp-content/uploads/2014/01/storyousobjednavky.png

z: z:

DAMEJIDLO.CZ S.R.O. [online]. [cit. 2016-01-15]. Dostupné z: http://www.damejidlo.cz DOTYKAČKA S.R.O. [online]. [cit. 2015-12-09]. Dostupné z: http://www.dotykacka.cz/ FINANČNÍ SPRÁVA [online]. [cit. 2016-03-10]. Dostupné z: http://www.financnisprava.cz/cs/financni-sprava/eet/casto-kladene-dotazy GOOGLE INC.: Google Charts [online]. https://developers.google.com/chart/

[cit.

2016-02-10].

Dostupné

z:

GOOGLE INC.: Google Maps Javascript API [online]. [cit. 2016-01-12]. Dostupné z: https://developers.google.com/maps HAVIT, S.R.O.: Příloha č. 3 k zákonu č. 235/2004 Sb. Seznam zboží podléhajícího první snížené sazbě daně [online]. [cit. 2015-10-08]. Dostupné z: http://business.center.cz/business/pravo/zakony/dph/priloha3.aspx

Literatura

78

HOGAN, BRIAN P. HTML5 a CSS3: výukový kurz webového vývojáře. Brno: Computer Press, 2011. ISBN 978-80-251-3576-1. HOPKINS, CALLUM. PHP okamžitě. Brno: Computer Press, 2014. ISBN 978-80-2514196-0. I-TECHNOLOGIES S.R.O. [online]. [cit. 2015-12-09]. Dostupné z: http://www.itechnologies.cz/ KEVIN TATROE, PETER MACINTYRE. Programming PHP. 3rd ed. Sebastopol, CA: O'Reilly Media, 2013. ISBN 1449365833. KOFLER, MICHAEL A TRANSLATED BY DAVID KRAMER. The definitive guide to MySQL. 3rd ed. Berkeley, CA: Apress, 2005. ISBN 1430200715. KOSEK, JIŘÍ. PHP a XML. Praha: Grada, 2009. Profesionál. ISBN 978-80-247-1116-4. LACKO, ĽUBOSLAV. 1001 tipů a triků pro SQL. Brno: Computer Press, 2011. ISBN 97880-251-3010-0. LOGOTYP S.R.O. [online]. [cit. 2015-12-05]. Dostupné z: http://www.lgtp.cz/wpcontent/uploads/Septim-pokladna-seznam-stol%C5%AF.jpg LOUŠA, FRANTIŠEK. Zásoby: komplexní průvodce účtováním a oceňováním. 4., aktualiz. vyd. Praha: Grada, 2012. Účetnictví a daně (Grada). ISBN 978-80-247-4115-4. Máče, Miroslav. Účetnictví pro územní samosprávné celky, příspěvkové organizace a organizační složky státu: aplikace v příkladech. Praha: Grada, 2012. Účetnictví a daně (Grada). ISBN 978-80-247-3637-2. MULAČOVÁ, VĚRA A PETR MULAČ. Obchodní podnikání ve 21. století. Praha: Grada, 2013. Finanční řízení. ISBN 978-80-247-4780-4. NOVOTNÝ, PAVEL. Účetnictví pro úplné začátečníky 2016 Praha: Grada Publishing, 2016. Účetnictví a daně (Grada). ORACLE CORPORATION: MySQL Workbench [online]. [cit. 2015-11-19]. Dostupné z: http://www.mysql.com/products/workbench/ ORIGIN SOFT S.R.O. [online]. [cit. 2015-11-22]. Dostupné z: http://www.finta.cz/ PROFIREST S. R. O. [online]. http://www.profirest.cz/ QPOS SYSTEM S.R.O. [online]. http://www.qpokladna.cz/

[cit. [cit.

2015-08-03]. 2015-12-02].

Dostupné

z:

Dostupné

z:

ROUDENSKÝ, PETR A ANNA HAVLÍČKOVÁ. Řízení kvality softwaru: průvodce testováním. Brno: Computer Press, 2013. ISBN 978-80-251-3816-8. ŘEPA, VÁCLAV. Podnikové procesy: procesní řízení a modelování. 2., aktualiz. a rozš. vyd. Praha: Grada, 2007. Management v informační společnosti. ISBN 978-80247-2252-8.

Literatura

79

SCHNEIDER, ROBERT D. MySQL: oficiální průvodce tvorbou, správou a laděním databází. Praha: Grada, 2006. ISBN 80-247-1516-3. SMART SOFTWARE S.R.O. [online]. [cit. 2016-01-09]. Dostupné z: http://www.smartsoftware.cz/ SOMMERVILLE, IAN. Softwarové inženýrství. Brno: Computer Press, 2013. ISBN 97880-251-3826-7. STORYOUS.COM S.R.O. [online]. http://www.storyous.com/

[cit.

2015-10-01].

Dostupné

z:

SUEHRING, STEVE. JavaScript: krok za krokem. Brno: Computer Press, 2008. Krok za krokem (Computer Press). ISBN 978-80-251-2241-9. SYNEK, MILOSLAV A EVA KISLINGEROVÁ. Podniková ekonomika. 5., přeprac. a dopl. vyd. Praha: C.H. Beck, 2010. Beckovy ekonomické učebnice. ISBN 978-80-7400336-3. ŠILHAVÝ, RADEK. Vybrané aspekty návrhu webových informačních systémů. Vsetín: Šilhavý, 2013. ISBN 978-80-904741-3-0. VÁVRŮ, JIŘÍ A MIROSLAV UJBÁNYAI. Programujeme pro Android. 2., rozš. vyd. Praha: Grada, 2013. Průvodce (Grada). ISBN 978-80-247-4863-4. VECTRON SYSTEMS CZ S.R.O. http://www.vectron.cz/

[online].

WINSHOP SOFTWARE S.R.O. [online]. http://www.pokladny.com/

[cit. [cit.

2016-01-09]. 2015-11-25].

Dostupné

z:

Dostupné

z:

Worx International Inc.: PHPMailer [online]. [cit. 2016-02-19]. Dostupné z: http://www.phpmailer.worxware.com/

Přílohy

80

Přílohy

CD

A CD Zdrojový kód se strukturou databáze na přiloženém CD.

81

Návrh objednávkového modulu pro pokladní systém

Recommend Documents