Použití POS a možnosti jejich integrace do ERP systémů: případová studie

Masarykova univerzita Fakulta informatiky

}

w A| y < 5 4 23 1 0 / -. , )+ ( %&' $ # !"

Æ

Použití POS a možnosti jejich integrace do ERP systémů: případová studie Diplomová práce

Bohumír Vospěl

Brno, podzim 2014

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Bohumír Vospěl

Vedoucí práce: Ing. Leonard Walletzký, Ph.D ii

Poděkování Na tomto místě bych rád poděkoval vedoucímu této diplomové práce, Ing. Leonardovi Walletzkému Ph.D., za odborné vedení a cenné rady při psaní tohoto textu. Také bych chtěl poděkovat Brunovi Rossimu Ph.D., za poskytnutí odborné konzultace. V neposlední řadě bych své díky chtěl věnovat rodině, která mě při psaní práce podporovala. Zvláštní poděkování patří mé přítelkyni, Heleně Vetešníkové, která byla mou vytrvalou psychickou oporou a poradkyní.

iii

Shrnutí Tato práce se zabývá analýzou pokladních systémů (POS) z řad otevřeného i proprietárního softwaru. Byly zde analyzovány legislativní požadavky na pokladní systémy a to včetně připravované elektronické evidence tržeb. Diskutovány byly možnosti integrace POS s ERP. V případové studii byly tyto informace využity na konkrétním případu malé obchodní společnosti.

iv

Klíčová slova Point of Sale, ERP, Integrace, iDempiere

v

Obsah 1

2 3

4

5

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Cíle práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Pokladní systémy . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Vlastnosti pokladních systémů . . . . . . . . . . . . . 1.2.2 Příslušenství pokladních systémů . . . . . . . . . . . 1.3 ERP systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 ERP iDempiere . . . . . . . . . . . . . . . . . . . . . Pokladní systémy a česká legislativa . . . . . . . . . . . . . . 2.1 Současné legislativní nároky související s POS . . . . . . . . . Připravovaná elektronická evidence tržeb . . . . . . . . . . . 3.1 Chorvatský zákon o fiskalizaci hotovostních plateb . . . . . . 3.1.1 Princip fiskalizace a vystavování účtenek . . . . . . . 3.1.2 Výjimky při vydávání unikátního identifikátoru účtenky 3.1.3 Příklad komunikace se serverem finanční správy . . . 3.1.4 Implementace fiskalizace na koncových zařízeních . . 3.2 Shrnutí chorvatského modelu . . . . . . . . . . . . . . . . . . Možnosti integrace pokladních systémů s ERP . . . . . . . 4.1 Technické možnosti integrace poskytované ERP iDempiere . . 4.1.1 Webové služby . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Java Messaging System . . . . . . . . . . . . . . . . . 4.1.3 Datová integrace . . . . . . . . . . . . . . . . . . . . . 4.1.4 iDempiere OSGi balíček . . . . . . . . . . . . . . . . . 4.2 Softwarová architektura . . . . . . . . . . . . . . . . . . . . . 4.3 Vlastnosti komponent . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Provázanost komponent . . . . . . . . . . . . . . . . . 4.3.2 Soudržnost komponent . . . . . . . . . . . . . . . . . 4.4 Architektury integrace . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Point-to-point integrace . . . . . . . . . . . . . . . . . 4.4.2 Hub-and-spoke topologie integrace . . . . . . . . . . . 4.4.3 Servisně orientovaná architektura . . . . . . . . . . . 4.4.4 Sběrnicová topologie integrace . . . . . . . . . . . . . 4.5 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analýza vybraných pokladních systémů . . . . . . . . . . . . 5.1 Pokladní systémy na trhu . . . . . . . . . . . . . . . . . . . . 5.1.1 Svobodné pokladní systémy . . . . . . . . . . . . . . UniCenta . . . . . . . . . . . . . . . . . . . . . . . . . Open Source Point of Sale . . . . . . . . . . . . . . .

3 3 4 5 6 7 9 10 10 14 14 15 16 17 17 20 21 22 22 22 23 23 23 24 24 24 24 24 26 28 29 33 34 34 34 34 36 1

5.1.2

Proprietární pokladní systémy . . . . . . . . Software A7 společnosti Apls Zlín s r.o. . . . Pokladní systémy od Cígler Software . . . . Pokladní systémy od společnosti Stormware 5.2 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . 6 Případová studie . . . . . . . . . . . . . . . . . . . . . . 6.1 Profil společnosti . . . . . . . . . . . . . . . . . . . . 6.2 Požadavky na systém . . . . . . . . . . . . . . . . . . 6.3 Návrh systému . . . . . . . . . . . . . . . . . . . . . 6.3.1 Zvolení softwarových komponent . . . . . . . ERP . . . . . . . . . . . . . . . . . . . . . . Pokladní systém . . . . . . . . . . . . . . . . Elektronická evidence tržeb . . . . . . . . . . Způsob integrace . . . . . . . . . . . . . . . . 6.3.2 Infrastruktura systému . . . . . . . . . . . . 6.3.3 Návrh pokladního počítače . . . . . . . . . . Hardware POS . . . . . . . . . . . . . . . . . Zajištění aktualizací POS . . . . . . . . . . . 6.3.4 Návrh Work breakdown structure . . . . . . 6.3.5 Nástin business plánu služby . . . . . . . . . 6.4 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . 7 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . A Snímky obrazovek . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

38 38 39 41 43 44 44 44 45 45 45 46 46 46 47 47 47 47 48 49 49 50 55 59

2

1 Úvod Téma pokladních systémů se v době psaní této práce stává čím dál více aktuálním a to díky přípravě zákona o elektronické evidenci tržeb, který by měl být účinný od roku 2016. Tento zákon plánuje zavést online elektronickou evidenci každého vystaveného daňového dokladu za hotovostní platbu. Účelem tohoto zákona je umožnění odhalování daňových úniků. Je tak velice pravděpodobné, že se v dohledné době mnoho podnikatelských subjektů, operujících s hotovostními platbami, bude muset adaptovat na tyto podmínky a pro mnoho z nich bude zakoupení nového pokladního systému nutností. V současnosti je v České republice přibližně 50 000 způsobilých pokladních systémů, u kterých lze nový zákon zavést pomocí aktualizace jejich softwaru. Dalších cca 150 000 pokladních systémů je nezpůsobilých a 290 000 podnikatelů nemá žádný pokladní systém [5]. Podle Asociace malých a středních podniků a živnostníků ČR se tak jedná až o 500 000 připojených systémů [9]. Jedním z možných řešení, pro část této množiny podniků, by mohl být elektronický pokladní systém, který nebude finančně nákladný a zároveň bude propojený s ERP tak, aby byl škálovatelný, reflektoval rozvoj jednotlivých podniků a v ideálním případě, aby tato kombinace umožnila rychlejší růst podniku. Jelikož náklady na komerční ERP systém jsou pro mnoho malých subjektů hlavní bariérou pro pořízení, budeme se v této práci zabývat integrací se svobodným ERP systémem iDempiere. Pokud by se podařilo najít vhodné technické řešení, tedy pokladní systém, který by byl integrovatelný s ERP iDempiere a zároveň by toto řešení počítalo s legislativními změnami, mohla by tato kombinace přinést zajímavý projekt pro mnoho obchodníků, kteří se budou potýkat s technickým řešením elektronické evidence tržeb. Navrhovaný pokladní systém by mohl být provozovaný jak na dotykových zařízeních jako je tablet nebo chytrý telefon, tak i na pokladních systémech s vestavěnými či běžnými osobními počítači a zároveň poskytovat propojení s ERP.

1.1

Cíle práce

V první části této práce bude objasněna funkce a vlastnosti pokladních systémů a také bude popsán ERP iDempiere. Dále se budeme zabývat analýzou současných právních náležitostí, které souvisí s pokladními systémy. Na le3

1. Úvod gislativní část navážeme analýzou chorvatského systému, jenž má sloužit jako vzor pro výše zmíněnou připravovanou elektronickou evidenci tržeb. V této části práce se budeme zabývat i technickými řešeními implementace fiskalizace v Chorvatsku z pohledu pokladních systémů. Po probrání legislativních aspektů se budeme zabývat možnostmi integrace podnikových systémů. Zaměříme se na možnosti integrace ERP systémů s pokladními systémy, které jsou předmětem této práce. V následující části bude provedena analýza existujících pokladních systémů na trhu. Zaměříme se na jejich funkční vlastnosti, na možnosti adaptace pro použití v našich legislativních podmínkách a také i na možnosti jejich integrace s ERP systémy. V poslední části se budou tyto poznatky aplikovat v případové studii na subjektu malého obchodníka.

1.2

Pokladní systémy

V této podkapitole se budeme zabývat tím, co softwarové pokladní systémy (často označované jako Point of Sale (POS) nabízí a jaké vlastnosti mají. Motivací pro zavedení elektronického pokladního systému je zjednodušení a urychlení obchodních procesů při styku se zákazníkem. Dalším motivačním faktorem může být i pořizovací cena, zejména v případě použití pokladního systému se svobodnou licencí nebo pokladního systému řešeného formou software jako služby SaaS). Mnohdy tak lze využít například starého počítače nebo tabletu a snížit tak pořizovací náklady na hardware. Opět však záleží na konkrétním případu. Zejména tehdy, kdy je kladen velký důraz na spolehlivost nebo rychlost, nemusí být nejlevnější řešení tím nejvhodnějším. Další motivací může být i současný plán na zavedení elektronické evidence tržeb, kdy se softwarový pokladní systém nabízí jako vhodný kandidát pro implementaci této nastávající změny. Podle [27] patří mezi často zmiňované výhody POS následující: přehledy o stavu zásob ve skladu, o stavu tržeb u jednotlivých druhů zboží (vyjádřeno v penězích) i jejich prodejnosti (vyjádřeno v kusech), poskytnutí rychlejšího prodeje, zkvalitnění obsluhy zákazníka, monitorování frekvence zákazníka v konkrétní době, eliminace záměny zboží v prodejním procesu, kontrola zaměstnanců a možnost jednoduchého využití dat z POS do účetnictví. Pokladní systémy musí být přizpůsobeny požadavkům a procesům konkrétního obchodu a z tohoto důvodu neexistuje pokladní systém, který je obecný a bylo by možné jej aplikovat ve všech případech. Zjednodušeně by se daly pokladní systémy rozdělit do několika kategorií: na pokladní systémy určené do maloobchodu, velkoobchodu, pohostinství a služeb. Každá z těchto kategorií lze dále dělit, ale základní charakteristiky, které budou popsané níže, se ve 4

1. Úvod většině případů budou shodovat. 1.2.1 Vlastnosti pokladních systémů Ve výkladovém Anglicko-českém obchodním slovníku [20] je akronym POS vysvětlován jako místo, kde se něco prodává. Základní vlastnost, kterou tak pokladní systém musí nabízet, je evidence zákazníkem nakupovaných položek, jejich množství, cena za kus, konečná cena a výše daně z přidané hodnoty. Tyto položky se ve většině případů načítají z databáze produktů, ze které je lze vyhledávat v kategorizovaném seznamu zboží či služeb, pomocí jejich unikátních číselných identifikátorů (např. EAN kódu) nebo zadáním klíčových slov. Další možností je ruční zadání konkrétní položky. Tento proces tak bývá navázán na systém skladových zásob a umožňuje zjednodušení přehledu o aktuálním stavu skladu a centralizovanou správu cen. Další nedílnou součástí je vystavování dokladů za markované zboží či služby. Tyto doklady musí splňovat legislativní náležitosti, kterými se zabývá podkapitola 1.3.1 Pokladní systémy a česká legislativa. Mezi další funkcionalitu se řadí možnosti stornování nebo opravy položek na dokladu. Běžnou součástí pokladních systémů bývá i vedení denních uzávěrek, tedy vytvoření souhrnného seznamu provedených plateb v jednom dni na dané pokladně, stejně tak jako aktuální evidence finančního zůstatku v pokladně. Ve fázi platby pokladní systém může nabízet výpočet sumy k vrácení, rozdělení této sumy na vhodné mince a bankovky a to ideálně v závislosti na aktuálním stavu pokladny. Další užitečnou vlastností je rozdělení položek na více účtů, ať již v případě rozpočítání účtu mezi spolusedícími hosty restaurace, tak i například v případě rozložení částky na různé metody plateb. Pokladní systém může také implementovat zákaznické účty a s nimi spojené výhody, karty, slevy a jiné. Důležitou vlastností je správa uživatelů, která může sloužit monitorování výkonnosti a chyb obsluhy pokladny, či pracovní docházky. Role uživatelů mohou umožnit nastavení pravidel na základně zodpovědností a kompetencí jednotlivých pracovníků, například pro manipulace se slevami, navrácení peněz za zboží atd. Z pohledu managementu se pokladní systém může stát důležitým zdrojem pro monitorování obchodních procesů (zejména statistik o prodejích) a lze tak pokladní systémy vnímat jako zdroj důležitých informací. Dle [27] se jedná o evidenci reklamací, záznam objemů jednotlivých nákupů a metod placení zákazníků. Ty pak například mohou souviset s ukazateli výkonnosti (Key Performance Indicator (KPI)) a prakticky vést k optimalizaci cen a marží, skladových zásob, počtu pokladních míst aj. Ve velkých prodejních řetězcích se využívají tři stupně POS. Grand mas5

1. Úvod ter pokladna slouží jako centrální počítač pro stanovování cen zboží, master pokladna se využívá na úrovni poboček pro operativní změnu ceny zboží (např. sleva) a klasické pokladny jsou používány při konečném prodeji zboží zákazníkovi v jednotlivých obchodech [27]. Stejně tak lze v obchodních řetězcích nalézt specializovaná pokladní místa určená pro samoobslužný prodej. Těmito systémy se nadále nebudeme zabývat, protože se jedná o systémy spadající do jiné kategorie, než jsou malé a střední podniky. Největším rozdílem mezi obchodními a restauračními pokladní systémy je, že restaurační navíc implementují rozdělení účtů na jednotlivé stoly, případně i židle a umožňují tak mít více otevřených účtů současně. Další funkcionalitou, která může být důležitá v případě servisu, je proces přijímání záloh a práce se zakázkami (zadávání zakázek, jejich úhrada). Mezi méně časté, ale možné, připadají v úvahu obchody, kde dochází k výkupu, například v případě bazaru, druhotných kovů aj. Mnohdy je potřeba brát v potaz i příjem zboží, platby za zboží, provize aj. Z technického hlediska se pokladní systémy liší tím, zda jsou řešené jako desktopové nebo webové aplikace a podle režimu provozu, zdali mohou pracovat offline, pouze online, či v obou případech. Z pohledu integrace s ostatními systémy lze dělit na systémy synchronizované v reálném čase nebo asynchronní. Uživatelské rozhraní bývá běžně optimalizované pro dotykové displeje a z periferií jsou standardně podporovány tiskárny účtenek, čtečky čárových kódů. Podrobněji bude příslušenství popsáno v následující podkapitole. 1.2.2 Příslušenství pokladních systémů Aby využití pokladních systémů bylo co nejvíce efektivní, lze zakoupit různorodé hardwarové příslušenství, která usnadňují či automatizují procesy v obchodě. Mezi nejběžnější se řadí čtečky kódů (např. čárového kódu), dotykový displej, pokladní tiskárny. Dalším běžným příslušenstvím bývá elektronická pokladní zásuvka (kasa), zákaznický display, displej objednávek pro kuchyni, čtečky RFID karet, váhy, čítače mincí a bankovek či platební terminály. Tento výčet zařízení není kompletní, ale je evidentní, že počet a variabilita příslušenství je velká a souvisí s různými druhy obchodu nebo služeb. Rozhraní příslušenství Z pohledu hardwarového rozhraní tato zařízení ve většině případů využívají standardních rozhraní jako je USB, RS232, LPT, Ethernet či Bluetooth. 6

1. Úvod

Obrázek 1.1: Diagram zobrazuje architekturu UnifiedPOS, převzato z [16]

Z hlediska softwarové integrace všech možných zařízení by implementace každého z nich by byla téměř nemožná a vzniklo by tak omezení pokladních systémů na konkrétní podporované příslušenství. Aby se tomuto problému zamezilo, vznikl standard od divize IT standardů působící pod National Retail Federation1 [10]. Výsledkem jejich činnosti je standard UnifiedPOS (UPOS), který je na platformě nezávislý, jak z pohledu operačních systémů, tak z pohledu programovacích jazyků. Definuje architektonickou specifikaci, která je zobrazená na 1.1 pro rozhraní aplikací, tak aby bylo možné připojit zařízení, které bylo navržené s ohledem na tento standard [16]. Je tak zajištěna kompatibilita mezi mnohými výrobci příslušenství a pokladními systémy. Konkrétní implementace standardu UnifiedPOS jsou Java for Point of Sale Devices (JavaPOS) 2 a Object Linking and Embedding for Retail Point of Sale (OPOS) 3 . Dalšími standardy jsou ESC/POS od společnosti Epson a IBM Surepos.

1.3

ERP systémy

Právě systémy ERP tvoří základ veškerých informačních systémů podniku. Jejich cílem je integrace jednotlivých funkcí podniku v jediný systémový 1. maloobchodní asociace pocházející z USA 2. vyvíjeno spol. Microsoft 3. vyvíjeno společnostmi Sun Microsystems, IBM a dalšími

7

1. Úvod

Obrázek 1.2: Znázornění kompletního balíku ERP ADempiere, ze kterého vychází iDempiere

celek. Tyto systémy tedy automatizují a integrují jednotlivé dílčí procesy podniku, sdílí a standardizují data na podnikové úrovni, umožňují přístupnost či dostupnost informací i práci s historickými daty a v neposlední řadě komplexnost přístupu k řešení informačních systémů podniku. Vzhledem k nárůstu požadavků na integraci dalších a dalších podnikových procesů, se v současné době využívají systémy druhé generace ERP II. Ty jednoduše propojují interní procesy s externími [27]. Jednotlivé systémy ERP mají vlastní architekturu, která se skládá z jednotlivých modulů. Přínosem pro podniky je, že tyto moduly bývají volitelné a lze pořídit pouze ty, jež jsou pro podnik účelné a potřebné. Mezi běžnou nabídku modulů řadíme aplikační, dokumentační, technologické a správní, implementační a kastomizační a modul vlastního vývojového prostředí [27]. 8

1. Úvod 1.3.1 ERP iDempiere iDempiere je open-source ERP systémem určeným pro malé a střední podniky, který v sobě mimo jiné integruje procesy CRM (řízení vztahu se zákazníkem), SCM (řízení dodavatelského řetězce), internetový obchod a správu skladu. Je vyvíjen pod licencí GNU GPL v2 a vznikl jako fork projektu ADempiere, oproti kterému přináší výhodu dynamického zavádění modulů. Je tak možné tento ERP systém rozšiřovat funkčními moduly, aniž by došlo k výpadkům v jeho provozu. Z technického hlediska je vyvinut na platformě Java a zmiňovaná vlastnost zavádění modulů je implementována za pomocí dynamického modulárního frameworku OSGi. Data tohoto ERP systému mohou být ukládána v podporovaných databázových systémech: Oracle, PostgreSQL a MySQL [25, 26, 7]. Součástí ERP ADempiere byl také pokladní systém Posperita, který se ale stal uzavřeným. Do iDempiere tak již nebyl integrován a vývoj se začal ubírat směrem integrace s externími aplikacemi pokladních systémů, zejména Openbravo POS. Více o funkcionalitách a nasazení ERP ADempiere a tedy potažmo iDempiere lze nalézt v diplomové práci [26]. Lze vypozorovat, že ERP a POS implementují určité shodné procesy, jako jsou management zboží, tedy seznam produktů, ceníky, skladové zásoby. POS také mnohdy zahrnují zákaznické účty, tedy určité informace z CRM, nebo správu uživatelů. Je tedy důležité, aby tyto systémy byly navzájem propojené a zabránilo se tak vzniku informačních mezer.

9

2 Pokladní systémy a česká legislativa Cílem této kapitoly je identifikovat legislativní nároky související s pokladními systémy v České republice tak, aby bylo možné stanovit kritéria pro posuzování jednotlivých řešení POS, které nejsou vždy tvořeny s ohledem na lokální podmínky. Zároveň si tato kapitola neklade za cíl vytvořit komplexní analýzu, zahrnující podnikové účetnictví aj., jelikož ty jsou součástí ERP systémů a specializovaných účetních softwarů.

2.1

Současné legislativní nároky související s POS

Obvyklou součástí pokladních systémů je možnost vydávat daňové doklady, běžně označované jako účtenky a faktury. Náležitosti těchto dokladů jsou definovány v zákoně č. 235/2004 Sb., o dani z přidané hodnoty, konkrétně v § 26 - 35a. Tuzemský plátce DPH, který vystavuje tyto doklady, je současně zodpovědný za jejich správnost, a proto je pro něho důležité, aby pokladní systém vystavoval doklady splňující zákonné požadavky [17]. V následujících odstavcích jsou vyzdviženy náležitosti, týkající se vydávání dokladů za provedenou službu, nebo prodej zboží při placení na místě, například v obchodě nebo v restauraci. Vystavováním faktur a jiných dokladů, u kterých může být např. stanovená splatnost nebo splátkový kalendář, se tato kapitola nevěnuje, protože tyto případy bývají řešeny jinými systémy. Zákon č. 235/2004 Sb., o dani z přidané hodnoty Tento zákon v §26 - §35a definuje varianty daňových dokladů, jejich účel použití a údaje, které musí obsahovat. Dále stanovuje požadavky na uchovávání těchto dokladů [17]. Následující odstavce mají za cíl vybrat z tohoto zákona definice, související s úlohou elektronických POS. Na tyto faktory bude brán ohled při posuzování jednotlivých řešení POS tak, aby byly použitelné v souladu s tuzemským zákonem. Běžný daňový doklad 1. Daňový doklad musí obsahovat tyto údaje: (a) označení (obchodní firma nebo jméno a příjmení, popřípadě název dodatek ke jménu a příjmení nebo názvu a sídlo) a daňové identifikační číslo osoby, která uskutečňuje plnění. Tyto parametry musí být uvedeny i u osoby, pro kterou se plnění uskutečňuje, pokud je jí přiděleno. 10

2. Pokladní systémy a česká legislativa (b) evidenční číslo daňového dokladu, (c) rozsah a předmět plnění, (d) den vystavení daňového dokladu, (e) den uskutečnění plnění nebo den přijetí úplaty, pokud před uskutečněním plnění vznikla povinnost ke dni přijetí úplaty přiznat daň nebo přiznat uskutečnění plnění, pokud se liší ode dne vystavení daňového dokladu, (f) jednotkovou cenu bez daně a slevu, není-li obsažena v jednotkové ceně, (g) základ daně, (h) sazbu a výši daně (Kč), nejedná-li se o plnění osvobozené od daně, nebo je-li osobou povinnou přiznat daň osoba, pro kterou je plnění uskutečněno [17]. Z bodu (a) vyplývá, že tento typ dokladu vyžaduje znát identifikační údaje zákazníka, a proto se s ním nesetkáváme u drobných každodenních Business to Customer (B2C) transakcí, jako jsou nákupy potravin, drogerie, v restauracích aj. Pro tento účel existuje zjednodušený daňový doklad, který je popsaný níže. Zjednodušený daňový doklad 1. Vystavování zjednodušeného daňového dokladu lze v případě, že: (a) celková částka za plnění na daňovém dokladu není vyšší než 10 000 Kč (b) Daňový doklad nelze vystavit jako zjednodušený daňový doklad v případě i. uskutečnění plnění, u něhož je povinna přiznat daň osoba, pro kterou se plnění uskutečňuje, nebo ii. prodeje zboží, které je předmětem spotřební daně z tabákových výrobků, za jiné než pevné ceny pro konečného spotřebitele [17]. 2. Náležitosti zjednodušeného daňového dokladu: (a) „Zjednodušený daňový doklad nemusí obsahovat i. označení osoby, pro kterou se plnění uskutečňuje, 11

2. Pokladní systémy a česká legislativa ii. daňové identifikační číslo osoby, pro kterou se plnění uskutečňuje, iii. jednotkovou cenu bez daně a slevu, není-li obsažena v jednotkové ceně, iv. základ daně, v. výši daně.“[17, §30] (b) „Neobsahuje-li zjednodušený daňový doklad výši daně, musí obsahovat částku, kterou osoba, která plnění uskutečňuje, získala nebo má získat za uskutečňované plnění celkem.“[17, §30a] Zákon dále popisuje požadavky na uchovávání a zajištění věrohodnosti, integrity obsahu dokladů. Tyto faktory jsou zde popsány z důvodu vystavení dokladů a následné možnosti jejich archivace v elektronické podobě. Zajištění věrohodnosti původu, neporušenosti obsahu a čitelnosti daňových dokladů 1. U daňového dokladu musí být od okamžiku jeho vystavení do konce lhůty stanovené pro jeho uchovávání zajištěna: (a) věrohodnost jeho původu, to znamená, že je zaručená totožnost osoby, která plnění uskutečňuje nebo která daňový doklad oprávněně vystavila, (b) neporušenost jeho obsahu, tedy že obsah dokladu nebyl změněn (c) a jeho čitelnost, po dobu nutnou tento doklad uchovávat 2. Věrohodnost původu daňového dokladu a neporušenost jeho obsahu lze dosáhnout: (a) uznávaným elektronickým podpisem, (b) uznávanou elektronickou značkou, (c) elektronickou výměnou informací (EDI), jestliže dohoda o této výměně stanoví užití postupů zaručujících věrohodnost původu a neporušenost obsahu, (d) nebo jiným kontrolním mechanismem procesů, zajišťujícím spolehlivou vazbu mezi dokladem a daným plněním [17]. 12

2. Pokladní systémy a česká legislativa Uchovávání daňových dokladů Některé pokladní systémy mohou elektronicky uchovávat interně vydané doklady a následující část této kapitoly se tak věnuje zákonem daným požadavkům pro jejich uchování. Jiné formy uchování, např. vytištěný doklad, je v režii konkrétního podnikatelského subjektu. Tato práce studuje elektronické možnosti pokladních systémů, proto se náležitostmi jiných forem nezabývá. 1. „Daňový doklad lze uchovávat elektronicky prostřednictvím elektronických prostředků pro zpracování a uchovávání dat.”[17, §35a, (2)] 2. Zároveň musí být zaručena věrohodnost původu daňových dokladů a neporušenost jejich obsahu. Metody, pomocí kterých lze těchto náležitostí dosáhnout, jsou vyjmenovány v předchozí části kapitoly 2.1. 3. Uchovatel je také povinen zajistit pro správce daně bezodkladně přístup k těmto dokladům, možnost stahovat je a používat je, pokud jde o: (a) „Daňové doklady uchovávané osobou povinnou k dani, která má sídlo nebo provozovnu v tuzemsku, nebo (b) daňové doklady za uskutečněná plnění s místem plnění v tuzemsku uchovávané osobou povinnou k dani, která nemá sídlo ani provozovnu v tuzemsku.“[17, §35a, (3), (4)]

Zhodnocení legislativních náležitostí V této kapitole byly popsány právní náležitosti, které souvisí s vydáváním a uchováváním daňových dokladů pokladnami. V první části této kapitoly byly popsány varianty daňových dokladů, které souvisí s pokladními systémy a to zejména zjednodušený daňový doklad a běžný daňový doklad. Zjednodušený daňový doklad bývá nejčastěji vydáván při obchodu s koncovým zákazníkem, který nemá DIČ a současně jím placená částka nepřevyšuje 10 000 Kč. Příkladem bývá běžný nákup potravin nebo účet z restaurace. Tento typ je tedy typickým reprezentantem účtu vydaným u pokladního místa. Navazující část se týká povinnosti obchodníka archivovat tyto účtenky po dobu deseti let a zachovat věrohodnost původu i neporušenost obsahu daňového dokladu.

13

3 Připravovaná elektronická evidence tržeb Od počátku roku 2014 se začalo Ministerstvo financí ČR zabývat možnostmi elektronické evidence tržeb, od které si slibuje efektivnější boj s daňovými úniky. V roce 2005 byl se stejnou ideou snížení daňových úniků schválen Zákon o registračních pokladnách, 15/2005 Sb., který byl ale posléze zrušen. Z technického hlediska se jednalo o nákladné řešení, kdy každý plátce DPH operující s hotovostními platbami musel mít registrační pokladnu obsahující fiskální modul, nebo elektronický POS s tiskárnou, která byla propojena s fiskálním modulem. V obou případech byl fiskální modul certifikován ministerstvem financí. Tyto moduly obsahovaly fiskální paměť, která byla nesmazatelná a musela mít dostatečnou kapacitu pro uložení všech denních závěrek po dobu čtyř let[8]. Z použité technologie plynou nevýhody tohoto systému, jakožto nízká efektivita analýzy dat, která jsou uložena pouze v pokladně a jsou offline. Každé zařízení na trhu muselo být certifikováno ministerstvem financí, což snížilo rozmanitost na trhu a zvýšilo i cenu. Navíc by bylo jen otázkou času, než by se našel způsob, jak zabezpečení fiskální modulu obejít, za účelem pozměnění dat. Proto si nadcházející zákon bere za vzor jiný systém, který bude fungovat online a je již ověřen praxí v jiném státě. Tato informace tak dává prostor pro analýzu POS z pohledu jejich možného nasazení do tohoto připravovaného systému. V době psaní této práce nebyly známy přesné detaily implementace tohoto řešení, ale je již známo, že inspirace systému pochází z Chorvatska, kde obdobný systém byl spuštěn v roce 2012 [28, 3]. Protože se jedná o zásadní změnu, která se dotkne velké části podnikatelských subjektů, následující část shrnuje informace o praxi elektronické fiskalizace v Chorvatsku, ale i technické možnosti, o kterých se v současnosti hovoří v České republice. Chorvatský systém fiskalizace hotovostních transakcí je definován zákonem „Zakon o fiskalizaciji u prometu gotovinom” z roku 2012. Aby bylo možné posoudit jednotlivé POS z pohledu adaptace na navrhovanou elektronickou evidenci tržeb, se následující část zabývá nalezením klíčových vlastností chorvatské fiskalizace, která je v současné době považována jako vzor pro elektronickou evidenci tržeb.

3.1

Chorvatský zákon o fiskalizaci hotovostních plateb

Tento zákon zavádí proces fiskalizace v Chorvatsku. Fiskalizací se míní soubor opatření, která mají za úkol online monitorovat vydávání účtenek za hotovostní transakce[3]. Jak již bylo zmíněno dříve, důvodem tohoto opatření je snížení daňových úniků. Zákon stanovuje, kdo musí implementovat fiskalizaci 14

3. Připravovaná elektronická evidence tržeb a výjimky. Mezi výjimky patří například prodejní automaty, bankovní a poštovní služby, lístky v hromadné dopravě, ale i zemědělci prodávající své vlastní produkty. Tyto subjekty musí vydávat účtenky vázané na speciální certifikovanou „knihu účtenek”. Tyto účtenky, oproti fiskálním, neobsahují unikátní kód účtenky. Tato informace se zde zmiňuje z důvodu, že v následujícím textu se budeme na tento způsob vydávání účtenek odkazovat. Samotný pojem unikátního kódu účtenky bude vysvětlen níže. 3.1.1 Princip fiskalizace a vystavování účtenek Zákon udává, že pro účely fiskalizace musí každá vydaná účtenka obsahovat datum a čas vystavení, identifikátor operátora pokladny, který provedl autorizaci platby a zadal pokyn k vystavení účtenky. Tato informace se odesílá na server správy daní proto, aby byla spojitelná s IČ subjektu fiskalizace 1 a vydanou účtenkou. Z pohledu hodnocení POS bude tedy potřeba kontrolovat, zdali je součástí i správa uživatelů, případně možnosti její implementace. Dále musí obsahovat identifikátor typu platby, tedy jedná-li se o hotovost, šek, platbu kartou aj. Ačkoliv se fiskalizace netýká bankovních převodů, týká se plateb kartou. Fiskalizační účtenka musí také obsahovat alfanumerický řetězec bezpečnostního kódu vydavatele (subjektu fiskalizace), který slouží k potvrzení vazby vydané účtenky na subjekt fiskalizace [3]. Nezbytnou položkou je identifikátor účtenky, který se skládá ze tří polí[3]: ∙ pořadové číslo vydané účtenky - pro každý rok začínají všechna pokladní zařízení znovu čítat od jedné a pokračují inkrementálně ∙ číselný identifikátor místa vydání - každé prostory, ve kterých se provádí činnost související s fiskalizací, musí být zaregistrovány u ministerstva financí ∙ číselný identifikátor pokladního zařízení V souvislosti s číselným identifikátorem místa vydání zákon stanovuje, že registrace prostorů probíhá elektronicky, pokud nastane povinnost fiskalizace, tedy před vydáním první účtenky a to jak v případě změny stávajících prostorů, tak zaevidování nových. To se děje pomocí zaslání digitálně podepsaných dat o adrese, otevírací době a jiných údajích, které jsou obratem potvrzeny nebo zamítnuty ministerstvem financí. Z tohoto důvodu se budou u zkoumaných POS hodnotit i možnosti uložení dat o provozovně, i když tato 1. subjektem fiskalizace je myšlena fyzická, nebo právnická osoba povinna implementovat metody fiskálního zákona

15

3. Připravovaná elektronická evidence tržeb informace může být implementována přímo fiskalizačním modulem. Informace o prostorách, ve kterých se uskutečňuje obchod, jsou uloženy v registru subjektů fiskalizace. Ten slouží Fiskální úřadu pro ukládání informací o subjektech fiskalizace. Jedná se o informace potřebné pro vystavování digitálních certifikátů, které subjekt fiskalizace využívá pro podepisování datových zpráv při komunikaci s webovými službami Fiskálního úřadu. Dále musí být součástí celková suma, informace o placení či neplacení DPH, sazba DPH, IČ [3]. Klíčovou položkou je unikátní identifikátor účtenky, který je nezbytnou součástí každé účtenky za přijatou hotovostní platbu, pokud nespadá do již zmiňovaných výjimek. Tento identifikátor je generován na straně serverů finančního úřadu na základě přijetí a ověření digitálně podepsané zprávy ze strany subjektu fiskalizace, obsahující výše uvedené údaje. V případě, že zpráva je podepsaná validním certifikátem a obsahuje požadované informace, webová služba finančního úřadu odesílá nazpět vygenerovaný unikátní kód účtenky. Pomocí něj může koncový zákazník zpětně ověřit zaevidování této účtenky prostřednictvím webu ministerstva financí nebo pomocí SMS. Formát zpráv a technické údaje týkající se např. protokolů, bezpečnostních protokolů, ale i formát unikátního identifikátoru účtenky stanovují zvláštní dokumenty vydané ministerstvem financí [3]. 3.1.2 Výjimky při vydávání unikátního identifikátoru účtenky Zákon definuje i jak postupovat, pokud není možné z nějakého důvodu vystavit unikátní identifikátor účtenky. Nemožnost vystavení unikátního identifikátoru účtenky V případě přerušení spojení mezi klientem a serverem by měl subjekt fiskalizace vystavit účtenku, která bude bez unikátního identifikátoru účtenky a s náležitostmi příslušícími účtenkám, které nespadají do fiskalizace a jsou svázány se speciální knihou účtenek, která je certifikována ministerstvem financí. Subjekt fiskalizace musí obnovit spojení nejpozději do dvou dnů od vzniku poruchy a odeslat všechny vystavené účtenky na Finanční úřad, který následně určí unikátní čísla účtenek, jakožto potvrzení o obdržení těchto účtenek [3]. Porucha pokladního místa V případě, že pokladní místo přestane fungovat z důvodů poruchy, tak je subjekt fiskalizace povinen znovu obnovit funkčnost registrační pokladny nejpozději do dvou dnů. Zároveň musí do tohoto termínu odeslat všechny 16

3. Připravovaná elektronická evidence tržeb vydané účtenky, ke kterým Finanční úřad vystaví unikátní identifikátory účtenek. Následně je subjekt fiskalizace povinen napsat vystavený unikátní identifikátor na kopii vystavených účtenek [3]. Nedostupnost internetového připojení V případě, že subjekt fiskalizace provádí svůj obchod v místě, kde není možné se připojit k internetu, vystavuje účtenky bez unikátního identifikátoru do doby, než bude možné se k internetu připojit. Nemožnost připojení však musí demonstrovat certifikátem vydaným Chorvatskou poštovní a elektronickou agenturou [3]. 3.1.3 Příklad komunikace se serverem finanční správy Na obrázku 3.1 se nachází sekvenční diagram, který zobrazuje příklad komunikace mezi pokladním systémem a systémem daňové správy. Aktér "Pokladní"spouští celý proces zadáním tisku daňového dokladu pro zakupované položky. Pokladní systém zpracuje položky, které mají být vytištěny a také ty, které se mají odeslat do systému daňové správy a vygeneruje číslo účtenky. Na základě těchto informací následně vytvoří XML zprávu a podepíše privátním klíčem certifikátu, který byl vydán ministerstvem financí. Následuje fáze inicializace SSL komunikace se serverem daňové správy. Po úspěšném navázání se zavolá webová služba centrálního informačního systému daňové správy a předá se XML zpráva. Na straně centrálního informačního systému daňové správy se ověří podepsaná zpráva a zpracuje se. Pokud je zpráva validní, je vygenerován unikátní identifikátor dokladu, který je zpět odeslán v podepsané XML zprávě. Na straně pokladny dojde k ověření odpovědi a je vytištěn doklad i s unikátním identifikátorem. 3.1.4 Implementace fiskalizace na koncových zařízeních Možností, jak implementovat fiskalizaci se naskýtá několik a následující řádky se věnují popisu těchto možností, včetně jejich vlastností. Současně zde zmíníme nároky na konektivitu do internetu. Tiskový ovladač Pravděpodobně jednou z nejjednodušších možností jak implementovat fiskalizaci, je vytvoření specializovaného tiskového ovladače. Ten při zadání tisku účtenky automaticky komunikuje se servery daňové správy a po obdržení 17

3. Připravovaná elektronická evidence tržeb

Obrázek 3.1: Sekvenční diagram procesu komunikace mezi pokladním systémem a informačním systémem daňové správy [6]

18

3. Připravovaná elektronická evidence tržeb unikátního identifikátoru se vytiskne účtenka, včetně unikátního identifikátoru. Není tak nutné upravovat pokladní software. Prakticky může být toto řešení implementováno jako fiskální ovladač standardu UPOS resp. OPOS/ JavaPOS, nebo přímo jako ovladač tisku v operačním systému [37]. Výhodou pak je pořizovací cena, případně nepotřebnost výměny pokladního systému za jiný, který podporuje fiskalizaci. Nevýhodou je, že tento ovladač musí být nainstalován na každý pokladní systém a každá aktualizace by mohla znamenat další výdaje a to na každém pokladním systému, zejména v případě implementace jako ovladače tiskárny. Přímá podpora v pokladním systému Další možností jak implementovat fiskalizaci je mít podporu přímo v pokladním systému, který obstará potřebnou komunikaci se servery daňové správy. Případná implementace změn fiskalizace by se pak dala řešit aktualizací pokladního systému. Problém se tak posouvá z úrovně ovladače na úroveň aplikace pokladního systému, která může mít systém automatických aktualizací. Podpora fiskalizace v podnikové infrastruktuře Aby se vyřešil problém s distribucí a aktualizacemi fiskálního řešení, bylo by možné mít centralizovaný modul, který bude například součástí ERP systému, případně by mohl fungovat jako middleware [37]. Další možností jak implementovat fiskalizaci by mohla být implementace služby na podnikové servisní sběrnici (ESB). Takovéto řešení by mohlo ale opět vyžadovat podporu v pokladním systému a může tak být dražším, než příklad s tiskovým ovladačem. Nevýhodou může být také eventuální výpadek služby zprostředkovávající fiskalizaci, kdy na jednom prvku jsou závislé ostatní systémy. Tento problém se dá ale technicky minimalizovat redundancí této služby. Platební terminál Další zvažovanou variantou je implementace fiskalizace pomocí platebních terminálů. Výhodou je, že externí platební terminály mohou být aktualizovány centrálně a jedná se o spolehlivé zařízení, které operuje s potřebnými informacemi k fiskalizaci. Konektivita těchto terminálů bývá zajištěna pomocí mobilních sítí. Je otázkou, jaký by byl poplatek za umožnění fiskalizace i hotovostních plateb. V současnosti poplatek za platby kartou přes platební terminál, která jde na vrub prodejce za každou provedenou transakci, se pohybuje v jednotkách procent z hrazené částky (přibližně dvě procenta). 19

3. Připravovaná elektronická evidence tržeb Nároky na připojení Aby fiskalizace mohla být provozována s přijatelnou odezvou, podle [6] je potřeba připojení k internetu o minimální šířce pásma 2Mb/s při zatížení čtyřiceti požadavky za vteřinu, tedy šířka pásma 50Kb/s při jednom požadavku za vteřinu. Ve stejném zdroji se ale neuvádí, zdali se jedná o šířku pásma pro upload či download. Dalo by se ale předpokládat, že se jedná o upload, jelikož zprávy odesílané na server daňové správy jsou několikrát větší než odpověď, která obsahuje pouze jedinou funkční informaci a to unikátní identifikátor.

3.2

Shrnutí chorvatského modelu

Systém v Chorvatsku funguje na principu odesílání každého vystaveného daňového dokladu na server finanční správy, kde je uložen. Na základě přijetí dokladu je vygenerován unikátní kód, který je odeslán zpět a je vytištěn na daňovém dokladu. Ten je kupující povinen převzít. Zákon zde také stanovuje maximální dobu trvání transakce na dvě vteřiny[14]. Data jsou tak uložena přímo na serverech spadajících pod finanční správu, která v nich následně může automatizovaně hledat vzory daňových úniků aj. Tato data jsou publikovaná online, aby si každý držitel dokladu mohl ověřit i jeho zaevidování u finanční správy. Toho se využívá pro dobrovolné ověřování zákazníkem, který bývá motivován finanční odměnou za nalezení nezaevidovaného dokladu. Systém má nastavenou maximálně dvoudenní prodlevu pro uveřejnění daňového dokladu a to z důvodu možnosti výpadku, který může nastat díky poruše pokladního systému, nebo v případě, že se prodej děje v místě bez konektivity k internetu. V těchto situacích je vystavitel dokladu povinen nahlásit poruchu, tu do dvou dnů odstranit a zajistit zpětné zaevidování všech vydaných dokladů. Další výhodou oproti fiskální paměti je, že zde není kladen požadavek na certifikaci každé pokladny či POS.

20

4 Možnosti integrace pokladních systémů s ERP Tato kapitola si klade za cíl prozkoumat možnosti, jak docílit integrace pokladního sytému s ERP systémem. Ačkoliv s problematikou sofistikovanějších způsobů integrace se zejména potýkají společnosti, které využívají více systémů než dva, tak s předpokladem možného vývoje a růstu i malé společnosti, může být přínosné se těmito způsoby zabývat již v počátcích. S vývojem obchodu se požadavky na obchodní procesy mohou jednoduše měnit a nárůst, či změny softwarových aplikací je tak velice pravděpodobný. Naopak je také možnost, že společnost již vlastní určitý software a bude chtít zajistit jeho integraci s nově nasazovanými systémy. Z historického hlediska je známo, že vývoj jediného a komplexního softwaru se může snadno stát neúměrně nákladným a neflexibilním řešením, protože požadavky na softwarové produkty se mohou měnit rychle, stejně jako technická infrastruktura a vývojové nástroje. Je tedy pragmatičtější plánovat podnikovou architekturu tak, aby byla flexibilní, tedy bylo možné zaměnit jednotlivé její prvky, aby byla škálovatelná a jednoduše udržovatelná. Dále by měla být odolná vůči chybám, distribuovatelná a snadno testovatelná. U dobře navrženého systému je zajištěno, aby byly jednotlivé heterogenní komponenty spolu propojené, ale zároveň měly vlastnosti slabé provázanosti a silné soudržnosti. Co se přesněji míní pojmem integrace v kontextu podnikových systémů definuje [23] jako spojování navzájem nezávislých aplikací tak, aby utvořily unifikovanou množinu funkcionality. Jinými slovy by se tato problematika dala vyjádřit jako propojení jednotlivých aplikací tak, aby utvořily smysluplný funkční celek. Integrace se tedy musí vypořádat s problémem různorodostí aplikací a platforem, na kterých jsou aplikace vyvinuty a provozovány. Integrace se musí také potýkat s aplikacemi, jež nebyly pro integraci a spolupráci s ostatními navrhnuty. Ne vždy je možné zasáhnout do kódu aplikace a připravit ji tak na integraci, ať již z důvodu obtížnosti, finanční nákladnosti, nebo nedostupnosti zdrojových kódů. A to i v případě, že aplikace byly vyvinuty interně. Často se může jednat o uzavřené aplikace třetích stran. Stejně tak se integrace v některých případech musí vyrovnat s aplikacemi, které jsou provozovány v různých geografických lokacích, eventuálně přímo u třetích stran. Je tedy třeba zvažovat i vlastnosti sítí, především jejich spolehlivost, rychlost a zdali integrace systémů vyžaduje synchronní či asynchronní transfer dat. Lze si představit případ, ve kterém je ERP systém provozován v hlavním sídle společnosti, ale pobočky a obchodní partneři jsou

21

4. Možnosti integrace pokladních systémů s ERP rozmístěni po celé Evropě. Dalším příkladem může být software jako služba, kdy si zákazník předplácí službu od třetí strany a ve většině případů ani neví, kde je software nainstalován a kde jsou uložena jeho data. Obvykle zákazník má přístup pouze k aplikačnímu rozhraní ve formě webových služeb. Na integraci se lze dívat různými pohledy. Podstatným pohledem je pohled na architekturu systému, tedy jak je systém navržen z jednotlivých distribuovaných částí. V následujících řádcích se zaměříme na technické možnosti, které pro integraci s ostatními systémy nabízí ERP iDempiere.

4.1

Technické možnosti integrace poskytované ERP iDempiere

ERP iDempiere nabízí několik způsobů, jak lze tento systém integrovat s dalšími softwarovými systémy. Konkrétně lze využít rozhraní webových služeb, messaging a integraci na datové úrovni. Tyto možnosti iDempiere zdědil od předchůdce ADempiere ERP a lze tak i vě většině případů využít dokumentaci a literaturu [18] k tomuto systému. 4.1.1 Webové služby ERP iDempiere implementuje webové služby v OSGi balíku zvaném „Webservices”, jehož aktivací se webové služby zpřístupní a v menu se zobrazí položka „Web Service Security”, díky níž lze vytvářet webové služby bez nutnosti programování. Tyto webové služby se po aktivaci stanou dostupné na adrese serveru iDempiere1 . Výchozí služby jsou Model Oriented Web Services (ModelADService) a Composite Interface. Množina služeb Model Oriented Web Services zpřístupňuje datový model iDempiere a lze díky nim vytvářet, dotazovat, číst, modifikovat a mazat záznamy z databáze. Také umožňují spouštět procesy. Composite Interface slouží ke spojování více služeb. Z technického hlediska jsou tyto služby dostupné pomocí Simple Object Access protocol (SOAP), ale i Representational state transfer (REST)[18, 7]. 4.1.2 Java Messaging System Systém iDempiere také podporuje intergraci pomocí Message Oriented Middleware. Dokumentace uvádí použití Java Messaging System v Apache ActiveMQ brokerem [18], ale teoreticky by mohl tento broker být nahrazený jiným. Možnosti JMS budou probrány níže. 1. https://host:ssl_port/ADInterface/services

22

4. Možnosti integrace pokladních systémů s ERP 4.1.3 Datová integrace ERP přímo podporuje prosté databázové soubory pro import a export dat. Konkrétně se jedná o CSV, kde jsou sloupce tabulky odděleny definovaným oddělovačem (běžně středníkem) a řádky přímo reprezentují znaky nového řádku (běžně CR LF). Tyto parametry lze upravit přes uživatelské rozhraní ERP. Do jaké tabulky se mají informace importovat se volí v menu „Import Loader Format Window”. Zde se nachází předdefinované šablony pro hlavní tabulky jako jsou: Obchodní partneři, Produkty, Ceník, Platby, Objednávky, aj. [1] Proces importu dat sestává ze dvou fází. Načtení dat do dočasné tabulky, následně jsou data zpracována a uložena do hlavní databáze. [1]

4.1.4 iDempiere OSGi balíček ERP iDempiere je postaven na Open Service Gateway initiative (OSGi), který zajišťuje dynamické zavádění balíčku s rozšiřující funkcionalitou, tedy aniž by došlo k výpadku. Lze tak vyvinout vlastní balíček, jenž bude implementovat integraci s pokladním systémem, nebo přímo pokladní systém.

4.2

Softwarová architektura

Softwarová architektura složená je podle [34] soubor základních rozhodnutí o softwarovém produktu nebo řešení, navržená tak, aby splňovala kvalitativní vlastnosti projektu (architektonické požadavky). Architektura zahrnuje hlavní komponenty, jejich hlavní vlastnosti a jejich spolupráce (interakce a chování) za účelem dosažení kvalitativních atributů projektu. Architektura může, a obvykle by měla, být v několika úrovních abstrakce, kde počet úrovní záleží na velikosti projektu a jeho komplexnosti [34]. Každý systém má architekturu, ať již vytvořenou vědomě nebo nikoliv. Příkladem vědomě budované architektury může být SOA, a pro nevědomě tvořenou by mohla být příkladem point-to-point architektura (obě dvě budou popsány níže). Architektura vzniká brzy a měla by reprezentovat základní rozhodnutí, která se obtížně mění a jsou kritická pro správnost. Architektura rozděluje systém na komponenty, stanovuje jejich hranice a obvykle nepopisuje všechny komponenty, ale zabývá se těmi podstatnými pro řešení, a jejich rozhraními. Stejně důležitou vlastností architektury je, že popisuje podstatné prvky chování komponent, jaké mají mezi sebou vztahy a jak interagují[34]. 23

4. Možnosti integrace pokladních systémů s ERP

4.3

Vlastnosti komponent

4.3.1 Provázanost komponent Provázanost, anglicky coupling, lze vysvětlit jako vzájemná vnitřní závislost dvou, nebo více komponent (aplikací, nebo systémů). Podstatné je, jak moc změna jedné komponenty ovlivní ostatní, tedy zdali si tato případná změna vyžádá i změnu u ostatních komponent. Pro integraci je ideální mít nevázané komponenty (Loose coupling) [38]. 4.3.2 Soudržnost komponent Soudržnost (koheze) je vlastnost komponenty, jak moc funkcionalita v rámci jedné komponenty spolu souvisí. Nízká soudržnost znamená, že komponenta obsahuje metody, které spolu nesouvisí. Vysoká soudržnost znamená, že komponenta zajišťuje jedinou funkci a každá část je nezbytná pro vykonávání této funkce. Vysoká koheze je tedy přínosná v rámci architektury.

4.4

Architektury integrace

Tato podkapitola se zaměří na možnosti použití jednotlivých architektur při integraci ERP iDempiere s pokladními systémy. 4.4.1 Point-to-point integrace Tato integrační architektura propojuje jednotlivé izolované systémy přímo mezi sebou. Při malém počtu systémů se může zdát tento způsob jako nejjednodušší, ale s přibývajícími systémy vznikne velice těžko udržovatelný systém. Integrace se děje pomocí těsných vazeb mezi systémy, které jsou přímo implementované v jednotlivých systémech. Pokud by bylo potřeba propojit všech n rozhraní systémů, a to pouze jednosměrně mezi sebou, vznikne 𝑛(𝑛−1) jednotlivých spojení, což již při pěti systémech znamená udržovat 2 deset spojů[23, 34]. Tato integrace se také v literatuře často označuje jako „špagetová integrace”. Tuto integraci lze realizovat mnoha způsoby, níže se ale budeme zabývat možnostmi, které souvisí s ERP iDempiere. Přenos souborů Zdrojová aplikace exportuje data do souboru, který má stanovený formát. Posléze je přenesen k cílové aplikaci, která daný soubor importuje. [23, 34] Příkladem této integrace v případě ERP iDempiere a POS může být export požadovaných dat do souboru ve formátu CSV, následný přenos za 24


Obrázek 4.1: Znázornění architektury Point-to-Point

pomocí SFTP a import do cílové aplikace. Tento proces může být pravidelně automaticky spouštěn.

Integrace databází pomocí ETL Integrace se provádí přímo mezi databázemi aplikací, pomocí datových pump (ETL). Data jsou ze zdrojové databáze načtena, následně transformována a uložena do cílové databáze [23, 34]. V případě iDempiere lze využít ETL nástrojů, které jsou podporovány databázovým systémem, kde iDempiere ukládá data, nebo využít projektů jako je Pentaho Kettle2 . Jedná se opět o synchronní dávkový proces (obě strany musí mít zajištěnou konektivitu zároveň).

Sdílená databáze V tomto případě integrované aplikace přímo přistupují do stejné databáze, ve které ukládají data. V případě iDempiere by pokladní systém musel být vytvořen nad databázovým schématem ERP [23, 34].

Webové služby Ačkoliv webové služby jsou mnohdy spojovány se servisně orientovanou architekturou, je možné s nimi vytvořit úzkou vazbu pomocí kontextově specifického rozhraní a docílit tak point-to-point integrace. V literatuře se tento případ označuje jako „Knot antipattern” [34].

2. http://community.pentaho.com/projects/data-integration/

25


Obrázek 4.2: Znázornění architektury Hub and Spoke

Specializovaný OSGi balíček Integraci point-to-point lze také implementovat jako OSGi balíček pro iDempiere [36], který bude implementovat úzkou vazbu s pokladním systémem. Konkrétní implementace bude záležet na cílovém pokladním systému, ale je možné opět využít webových služeb, RPC, přístupu do databáze, nebo jakékoliv další technologie, kterou bude pokladní systém podporovat. 4.4.2 Hub-and-spoke topologie integrace Tato architektura zavádí centrální prvek (Hub), který funguje v roli prostředníka a umožňuje tak snížit počet propojení mezi jednotlivými prvky. Nevýhodou této architektury se může stát samotný hub, který může působit jako úzké hrdlo celého systému, případně výpadek ovlivní závislé systémy. Tento problém se dá eliminovat přidáním dalších systémů a zátěž rozložit [23]. Také oproti Point-to-point integraci budou pravděpodobně vyšší pořizovací náklady. Využití datového skladu Další variantou využití datové integrace, která byla uvedena v Point-to-Point architektuře, je využití datového skladu tak, aby fungoval jako prostředník a umožnil asynchronní přenosy dat mezi integrovanými systémy (zobrazeno na obrázku4.3). Jedná se opět o silně provázané řešení. Datový sklad musí být namodelován tak, aby uchovával potřebná data pro synchronizaci, například v datových kostkách. Synchronizace mezi datovým skladem a ostatními databázemi by se docílilo pomocí ETL nástrojů. 26


Obrázek 4.3: Datová integrace

Enterprise Application Integration Příchod Enterprise Application Integration (EAI) řešení byl milník v oblasti integrace. Následující text pomůže lépe objasnit důvody vzniku Message Oriented Middleware (MOM) a také Enterprise Service Bus (ESB). EAI přináší do topologie middleware, nazývaný také jako integrační prostředník (Integration Broker) s cílem vyřešit problém komplexnosti point-to-point architektury. Tato integrace si dala za úkol umožnit neomezené sdílení byznys procesů a dat mezi jakýmikoliv aplikacemi nebo datovými zdroji v podniku. Tedy zajistit integraci heterogenních systémů a vyrovnat se s rychlostí či výpadky sítí za pomocí asynchronicity. V minulosti se jednalo o silně proprietární řešení, které bylo nákladné a kompatibilita mezi jednotlivými výrobci nebyla dobře zajištěna. Prostředník (broker) byl připojován k aplikacím pomocí proprietárních konektorů. Podle průzkumu, na který odkazuje [21], byla průměrná doba pro integrování pomocí EAI dvacet měsíců a úspěšnost byla nižší než 35%. Podle [24] nebyl problém pouze na technické úrovni, ale zároveň chyběl jednotný slovník, který by překryl mezeru mezi terminologiemi jednotlivých výrobců a usnadnil tak snížení vynaloženého času pro jednotlivé integrace. Zavedení jednotné terminologie, která umožnila spolupráci, předávání a sdílení znalostí, se podařilo v roce 2003 díky knize Enterprise Integration Patterns [23]. Tento způsob integrace a zmiňované integrační vzory dali základní podobu Message Oriented Middleware. Podle [21] se mnoho EAI produktů také začalo přetvářet více na sběrnicovou topologii (vzor Message Bus), která je v současnosti typická pro MOM a názorně je zobrazena na obrázku 4.4. Typickými 27


Obrázek 4.4: Obrázek zobrazuje EAI architekturu, využívající sběrnicovou topologii, převzato z [21]

představiteli od společností, které vyvíjí EAI, jsou TIBCO Rendezvous, IBM WebSphere MQ a Microsoft Message Queuing (MSMQ). 4.4.3 Servisně orientovaná architektura Servisně Orientovaná Architektura (SOA) je architektonický styl pro budování systémů, který je založen na interakci autonomních služeb. Služby reprezentují ucelenou funkcionalitu (silná koheze) a jsou slabě provázané. Každá služba uveřejňuje své procesy a chování přes kontrakty. Kontrakt služby se skládá ze všech zpráv, které služba uveřejňuje pro interakci s okolím. Mohou být unilaterální nebo bilaterální. Kontrakty jsou uveřejněné na koncových bodech, které jsou dostupné na konkrétníUniform Resource Identifier (URI). Kontrakty a zprávy jsou využívané tzv. odběrateli služeb. Zprávy mohou být např. HTTP Get, SOAP zprávy, JMS zprávy, nebo SMTP zprávy. Jednotlivé služby jsou řízené tzv. politikami. Politiky určují dynamické vlastnosti služeb, např. kdy a jak jsou služby dostupné pro odběratele služeb, bezpečnost (autentizaci, autorizaci, šifrování), Service-level agreement (SLA). Konkrétní aspekty politik mohou být aktualizovány za běhu. Odběratel služby je jiný software (služba, nebo aplikace klienta), který interaguje se službou pomocí zpráv. [34]. SOA tedy není možné si zakoupit, jedná se o architektonické paradigma, podle kterého lze vybudovat systém, jenž bude snadné udržovat, adaptovat a případně vhodné služby znovu použít v jiných systémech. SOA také není 28

4. Možnosti integrace pokladních systémů s ERP závislá na konkrétních technologiích. Ty lze k výstavbě systému založeného na této architektuře využít, jedná se například o často se SOA spojované webové služby (SOAP,REST a WSDL), ale i messanging (JMS) nebo OSGi. Například Web Services Description Language (WSDL) se dá využít k definování kontraktu služby a Simple Object Access protocol (SOAP) k zaslání zprávy službě. Jeden z podstatných rozdílů mezi SOA a EAI je v úrovni abstrakce. SOA je obecně procesně orientovaná, EAI je hlavně datově orientovaná a procesy jsou definovány nezávisle. EAI řešení jsou velmi komplexní a obvykle jsou vázané na uzavřené, proprietární standardy a technologie, což vytváří riziko, že vývoj bude ukončen s nemožností navázání tak, jak by tomu bylo v případě otevřených standardů a technologií. Stejně tak i dlouhodobé náklady jsou vyšší [30]. 4.4.4 Sběrnicová topologie integrace Message-oriented Middleware Message Oriented Middleware je systém, který zajišťuje spolehlivou, rychlou a asynchronní komunikaci pomocí zpráv. Tento prostředník zajišťuje asynchronnost perzistencí zpráv (obvykle jsou ukládány do interní databáze) tak, aby byla zajištěna jejich trvalost i při výpadku [23]. Na druhou stranu tato vlastnost perzistence může způsobit úzké hrdlo celého systému [31], nicméně MOM i databázové systémy jsou obvykle škálovatelné a je tak možné přidáním dalších systémů, které budou pracovat souběžně, tento problém eliminovat. Dále zprávy směruje k příjemci (unicast) nebo odběratelům (multicast) a MOM obvykle umožňuje transformovat předávané zprávy. Zprávy jsou základem komunikace a skládají se z hlavičky, která obsahuje meta-informace o zprávě (kdo je odesílatel, příjemce aj.) a slouží pro MOM. Následuje samotná zpráva, jež obsahuje libovolná přenášená data.[23] Odesílatel odesílá zprávu pomocí kanálů, ve kterém si ji příjemce vyzvedne a tím dojde k jejímu odstranění. Komunikace zjednodušeně probíhá tak, že odesílatel vytvoří zprávu a naplní ji daty. Následně ji vystaví na kanál, odkud ji MOM přenese do počítače příjemce a zpřístupní ji příjemci. Příjemce následně zprávu přečte z kanálu a extrahuje data ze zprávy.[23] Současné MOM servery jsou vyspělé a podporují širokou škálu funkcionalit. Jako příklad vezměme Apache ActiveMQ 3 , který implementuje architektonické vzory Enterprise Integration Patterns (EIP) z [23], podporuje 3. http://activemq.apache.org/

29


Obrázek 4.5: Model integrace OpenbravoPOS s ERP ADempiere, autor Redhuan D. Oon

škálování, nastavování vlastností pro doručování v závislosti na konkrétním odběrateli, zabezpečení, auditech aj. [38]. ERP iDempiere podporuje MOM tak, že implementuje Java Messanging System (JMS). JMS je na výrobci nezávislé Java API pro příjem a odesílání zpráv. Je tak možné využít libovolný MOM, který JMS podporuje. Jedním z nich je již zmiňovaný Apache ActiveMQ. JMS podporuje dva modely zasílání zpráv [31]: ∙ Point-to-point - zpráva je od odesílatele doručena virtuálním kanálem (fronta) přímo příjemci ∙ Publish-and-subscribe - vydavatel odešle zprávu všem jeho odběratelům Z pohledu implementace exportu či importu dat lze využít vlastního OSGi balíčku, který bude data zpracovávat (načítat, ukládat), transformovat do/z formátu vhodného pro přenos dat (běžně se využívá XML) a nakládat s těmito zprávami v kanálu(frontě) MOM. Druhým způsobem je využít funkcí z menu Replication Data. Toto menu nabízí funkcionality pro import a export dat a lze celý proces nastavit, aniž by bylo nutné programovat. Detailní postup, jak nastavit celý proces lze nalézt na [1]. Způsob pomocí JMS byl využit autory integrace ERP ADempiere s pokladním systémem OpenbravoPOS tak, jak je zobrazeno na obrázku 4.5. Po sléze byl tento modul adaptován jako OSGi balíček pro iDempiere. Na základě této integrace vznikly projekty WandaPOS4 a SmartPOS5 , které přináší iDempiere v kombinaci s pokladním systémem v jednom balíku. Další využití integrace pomocí JMS uvádí kniha [18] na příkladu integrace ERP ADempiere s elektronickým obchodem. 4. wandaapos.com 5. sourceforge.net/projects/smart-pos

30


Obrázek 4.6: Znázornění architektury sběrnice

Enterprise Service Bus Enterprise Service Bus (ESB) je architektonický model pro návrh a implementaci vzájemných interakcí a komunikací mezi softwarovými aplikacemi v servisně orientované architektuře [32]. Poznamenejme, že se definice z různých zdrojů liší, a proto níže uvedeme přehled charakteristik, vystihující podstatu ESB. Ve výčtu budou mimo jiné uvedeny i vlastnosti, které si ESB propůjčuje z EAI, respektive z MOM a také SOA. Oproti EAI (hub-and-spoke topologie), sběrnicová topologie umožňuje vyšší škálovatelnost a spolehlivost, zejména tím, že zátěž nekoncentruje v jednom bodě (hub/broker), ale rozprostírá ji mezi jednotlivé připojené body. Podle [19] ESB staví páteř pro implementaci SOA. V rámci této infrastruktury lze centrálně konfigurovat, nasazovat a řídit služby napříč celým podnikem. Hlavní funkce ESB jsou podle[32, 30]: ∙ Transparentnost umístění : ESB poskytuje platformu pro komunikaci (využívající messaging) mezi službami a odděluje odběratele služby, od jejího poskytovatele. Tyto služby tak nemusí znát své umístění (např. URL). Jedná se implementaci vzoru z [23] Message Bus. ∙ Protokolové adaptéry: ESB poskytuje množství adaptérů, které umožňují propojení s různými komunikačními a přenosovými protokoly (např. HTTP, FTP, POP3, SMTP) a souborovými systémy. ∙ Konverze přenosových protokolů: ESB umožňuje integrovat aplikace s různými přenosovými protokoly a zajistit jejich neviditelnou konverzi (např. HTTP na JMS). ∙ Inteligentní směrování a distribuci: ESB je prostředníkem mezi růz31

4. Možnosti integrace pokladních systémů s ERP nými službami a zprávy směřuje dynamicky podle obsahu, nebo podle statických kanálů (vzor fixed pipeline). ∙ Message Oriented Middleware: zajišťuje sběrnicovou infrastrukturu pro messaging ∙ XML Messaging: ESB, stejně tak jako MOM, umožňuje práci s binárními daty, ale pokud je to možné, preferuje se užívat zprávy ve formátu XML, které umožňují větší interoperabilitu, rozšiřitelnost, jejich validaci a také monitorování komunikace. ∙ Transformace a rozšiřování zpráv: zprávy mohou být transformovány podle potřeby, ať již transformace mezi různými schématy XML, nebo jinými formáty (např. CSV na XML). Transformace mohou být řetězeny. Zprávy také mohou být rozšiřovány o potřebné chybějící informace. ∙ Úkoly/Časovače služeb: ESB podporuje polling zdrojů (periodické dotazování) a čekání na trigger (spouštěcí událost). Lze tak pravidelně kontrolovat obsah FTP lokace za účelem zjištění nových souborů. Dalším možností je využití časovače pro spouštění dávek, např. ETL procesů. ∙ Bezpečnost: ESB by měla zajišťovat také šifrování, autorizaci, autentizaci příchozím a odchozím zprávám, stejně tak by měla předcházet zneužití ESB. ∙ Zajištění kvality služby: díky QoS lze prioritizovat zprávy a filtrovat obsah. Umožňuje také nastavení úrovní služeb např. na základě platby za ně. ∙ Monitorování a Administrace: příklady údajů, které jsou běžně monitorovány: počet přijatých zpráv počet chyb průměrný čas zpracování počet zpráv zpracovaných za jeden transport velikost fronty počet zpráv zpracovaných na jeden koncový bod, nebo proxy 32

4. Možnosti integrace pokladních systémů s ERP ∙ API pro rozšíření umožňuje implementaci rozšíření funkcionalit podle aktuálních potřeb ∙ Choreografie datových toků ESB mívá možnost vytváření sekvencí kroků (choreografie) k dokončení datového toku, ať již graficky nebo pomocí XML. Souhrnně lze říct, že ESB je charakteristická kanonickým formátem zpráv (XML), které slouží ke komunikaci mezi systémy. Každý systém je připojen ke sběrnici pomocí adaptéru, jenž formátuje data aplikace do kanonického formátu. Aplikace jsou tak odděleny sběrnicí (slabé vazby) a tato architektura je bezstavová, stav se přenáší zprávami. ESB je tak dobře přizpůsobitelná, škálovatelná spolehlivá a umožňuje integraci různých systémů. Pro přehled zmiňme několik zástupců open source ESB: Apache ServiceMix, Mule ESB (Community Edition) a JBoss ESB. Jejich porovnání z pohledu výkonnosti lze nalézt v [39].

4.5

Shrnutí

Z pohledu technických možností integrace, které ERP iDempiere nabízí, se jeví jako nejvhodnější pro integraci s POS využít JMS a webové služby, zejména z důvodu slabé provázanosti. Z architektonického hlediska se pro integraci POS a ERP, s předpokladem přidávání dalších systémů, nejlépe jeví ESB nebo SOA.

33

5 Analýza vybraných pokladních systémů 5.1

Pokladní systémy na trhu

Na současném trhu lze nalézt mnoho pokladních systémů, které jsou buď specializované na obchod nebo restaurace, ale lze nalézt i takzvaně univerzální, které se specializují pomocí modulů. Liší se také architekturou a platformou. Na trhu lze nalézt širokou nabídku od pokladních systémů provozovaných jako služba(Software as a Service) přes webové aplikace až po desktopové aplikace. 5.1.1 Svobodné pokladní systémy Cílem této podkapitoly je zmapovat trh s pokladními systémy, které jsou vyvíjeny pod svobodnou licencí a mají veřejně dostupný zdrojový kód. Typů licencí v otevřeném softwaru je velké množství a rozborem těch nejběžnějších se zabývá například práce [35], která čtenáře seznámí s touto problematikou na dostatečné úrovni, aby byl schopen rozhodnout, zdali licence, pod kterou je pokladní systém vyvíjen, vyhovuje daným potřebám. Na trhu pokladních systémů s otevřeným kódem nalezneme poměrně velké množství produktů, které se liší jak vyspělostí, zaměřením, platformou, tak již zmiňovanou licenční politikou. Důležitým faktorem je i ověření, zdali je daný produkt stále ve vývoji, nebo je již zastaralý a výrobce či komunita tento softwarový produkt dále nevyvíjí a neudržuje. UniCenta UniCenta je fork1 dříve populárního programu Openbravo POS, který vznikl akvizicí projektu Tina/Libre POS společností Openbravo, S.L.U. v roce 2007. Projekt Openbravo POS přestal výrobce postupně podporovat a poslední veřejně dostupná verze projektu Openbravo POS 2.30 je z roku 2009, respektive 2011, kdy byla vydaná poslední aktualizace 2.30.2. Proto se tomuto pokladnímu systému nebudeme věnovat, ale zmiňujeme jej z důvodu, že na základě tohoto projektu vzniklo několik alternativních větví a většina funkcionality a také dokumentace k Openbravo POS je stále platná i v těchto systémech. Jedním z nich je i UniCenta, který vychází z poslední dostupné verze projektu Openbravo POS 2.30. Pokladní systém UniCenta se aktivně udržuje a vyvíjí. V době psaní této práce byla poslední vydaná verze 3.9 1. alternativní větev projektu

34

5. Analýza vybraných pokladních systémů [22]. Podle serveru sourceforge.org2 se jedná o nejvíce populární projekt v kategorii pokladních systémů, k datu psaní této práce. Výrobce uvádí, že pokladní systém nekonkuruje velkým a nákladným pokladním systémům, ale základní funkcionalitu podporuje více než dobře. Pokladní systém může běžet samostatně nebo na více terminálech, podporuje také práci s více sklady či více lokalitami. Pokladní systém může fungovat v maloobchodě nebo pohostinství, ale také jejich spojením, čímž se stává relativně ojedinělým. Je šířen pod licencí GNU General Public License 3 [22]. UniCenta nabízí 15 jazykových mutací, mezi nimiž čeština chybí, ale je relativně jednoduché si ji vytvořit, díky odděleným textovým popiskům od programového kódu [12]. Další lokalizace tohoto programu, konkrétně nastavení kódové stránky, konvence desetinných oddělovačů, formáty dat, měny, zahrnují české prostředí[22]. Program je dobře modifikovatelný, výrobce uvádí že lze modifikovat grafické rozhraní, ale i například formát účtenky a výstup reportů. K modifikacím či vytváření nových funkcionalit lze využít interního skriptovacího jazyku, který je součástí z dob Openbravo POS. UniCenta integruje Apache Velocity Engine díky němuž lze adaptovat pokladní systém bez nutnosti kompilace celého programu a tak v případě formátu účtenky lze změny adaptovat pomocí interních skriptů. Syntakticky se jedná o jazyk podobný jazyku Java a umožňuje přístup ke všem objektům programu a také Java API[33, 22]. Navíc vzhledem k tomu, že se jedná o program s otevřeným kódem a licencí GNU GPL3, by modifikace neměly být překážkou i v případech, kdy interní skriptovací jazyk nebude vhodné či možné použít. Z technického hlediska je projekt vyvíjen v jazyce Java a je tak přenositelný mezi nejběžnějšími druhy platforem, pro které existuje Java Runtime Environment. Z pohledu funkcionality umožňuje pokladní systém vyhledávání produktu a ceny, práci se skladovými zásobami a to i na více pobočkách, vedení zákaznických účtů a věrnostních programů, slevy na položky, či na celek, navrácení peněz a úpravy položek účtenek aj. Pokladní systém umožňuje přijímání a výdej hotovosti, platbu platebními kartami, šeky či vouchery a rozdělení účtu na více účtenek. Externí platební terminály nejsou oficiálně podporované. Pokladní systém podporuje uživatelské účty a role. Umožňuje také sledování docházky personálu, resp. příchodů a odchodů obsluhy pokladen, včetně jejich přestávek. V případě použití programu jako restauračního pokladního systému, se 2. nejden z nejpopulárnějších projektů, sloužících k hostování svobodného a otevřeného software

35

5. Analýza vybraných pokladních systémů nabízí možnost vlastního rozložení stolů pro každé podlaží, a to včetně grafické reprezentace jednotlivých stolů na podlaží. Pokladní systém UniCenta také podporuje vytváření reportů o prodejích aj. Grafické rozhraní je optimalizované pro dotykové displeje, které musí minimálně podporovat rozlišení 800x600. UniCenta nabízí tři možnosti uživatelského rozhraní a to již zmiňované pro restauraci, maloobchod, ale také zjednodušené, optimalizované pro obchody, kde je potřeba rychle vyřizovat objednávky. Pohledu periferií program podporuje standard UniPOS, konkrétně implementace JavaPOS i OPOS, ale i ESC/POS od Epsonu. Výrobce uvádí, že lze připojit tiskárny účtenek, fiskální tiskárny, zákaznické displeje, čtečky čárových kódů, pokladní zásuvky, váhy, čtečku karet s magnetickým pruhem a běžné tiskárny, ať již lokální nebo síťové. Jako možnost integrace s jinými systémy UniCenta uvádí možnost přímé integrace na úrovni databáze. Samotný pokladní systém využívá vestavěnou databázi Apache Derby, která není vhodná pro nasazení v náročném prostředí a také pro integraci. Z tohoto důvodu UniCenta podporuje i jiné databáze a to Postgres SQL, HyperSQL, MySQL a Oracle[22, 11]. Původní projekt Openbravo POS ve verzi 2.30 také podporoval webové služby pomocí specializovaného modulu. Tyto služby byly ale utvořené na míru Openbravo ERP. Naskýtá se tak možnost upravit kódy těchto služeb tak, aby šly využít pro integraci i s jinými systémy. Poslední funkcionalitou, která nebyla zmíněna na stránkách pokladního systémy uniCenta je, že pro Openbravo POS také existuje možnost instalace modulu, který zpřístupní vzdálený přístup k pokladnímu systému pomocí PDA či tabletu a chytrých telefonů. Tato funkcionalita je implementovaná jako webové rozhraní a lze ji využít například v restauracích pro objednávání u stolů. Projekt lze nalézt na stránkách www.unicenta.com. Na těchto stránkach se nachází i informace o komerční podpoře. Komunitní podpora je dostupná na sourceforge. net/p/unicentaopos/support-requests/. Open Source Point of Sale Projekt Open Source Point of Sale (OSPOS) je zaměřen na maloobchod a zahrnuje moduly pokladního místa, řízení zásob a to i ve více skladech, řízení vztahů se zákazníky, sledování dodavatelů, management zaměstnanců a generování reportů. Projekt je aktivní a poslední verze 2.3 byla vydána 20. 8. 2014. Je vázán dvěma licencemi - GNU GPL v3 a MIT licencí. OSPOS je vyvíjen jako webová aplikace a back-end je psán v jazyce PHP s frameworkem CodeIg36

5. Analýza vybraných pokladních systémů niter, přičemž data se ukládají do databáze MySQL. Server by tak měl být dostatečně multiplatformní, typicky lze provozovat na jakémkoliv L/WAMP serveru. Vzhledem k využitému frameworku by použití jiné databáze nemuselo představovat velké zásahy do kódu aplikace [29]. Architektura je tak klient-server, kdy každý klient znamená samostatnou pokladnu. Je ovšem i možné provozovat klienta i server na stejném stroji offline [13]. Klientská strana je provozována jako tenký klient a měla by tak být multiplatformní, ovšem optimalizace je provedena pouze pro prohlížeč Google Chrome, který je ale dostupný pro relativně velké množství platforem. Lokalizace do češtiny chybí a výrobce na svých stránkách nabízí pomoc s technickou částí překladu, nicméně uvádí, že i přes všechnu snahu kompletní překlad není možný, díky chybám ve využitém frameworku. Většina textových popisků je oddělených od zdrojového kódu, je tedy pravděpodobné, že se situace časem zlepší [13]. Modul pokladního místa podporuje prodej i výkup. Slevy lze aplikovat na jednotlivé položky účtenky. Z metod plateb jsou podporované platby v hotovosti, šekem, dárkové poukazy, debetní a kreditní karty. K účtence je možné přiřadit již registrovaného zákazníka, případně lze přidat i komentář k prodeji. Po dokončení pokladní systém generuje účtenku, která obsahuje informace o prodejci (název společnosti, kontaktní údaje, číslo pokladny a zaměstnance, který doklad vystavil), eventuálně informace o zákazníkovi, datum vystavení, položky, výši daně a cenu před a po zdanění. Dále obsahuje typ platby, informace o možnosti navrácení zboží a také vygeneruje čárový kód účtenky. Výrobce neuvádí žádné možnosti uživatelské modifikace formátu a položek zobrazených na účtenkách, pravděpodobně tak bude nutné modifikovat zdrojový kód pokladního modulu [13]. Řízení zásob zahrnuje správu položek, které mohou být zadány přímo, nebo importovány ve formátu CSV 3 . Modul dále nabízí generování čárových kódů, správu dodavatelů, doplňování zásob. Z aktuálního stavu zásob je modul schopen vygenerovat reporty souhrnné, detailní či grafické [13]. Zákaznický modul umožňuje přidávat a upravovat záznamy o zákaznicích, jejich kontaktech, přehledy jimi zakupovaných položek včetně množství. Import informací o zákaznících je možné z CSV souboru. Modul umožňuje zasílání hromadných emailů zvoleným zákazníkům, bohužel ale není možné zákazníky kategorizovat. Modul podporuje tvorbu reportů pro jednotlivé zákazníky, ale i souhrnné reporty podle zadaných kritérií (například podle 3. CSV - Comma-separated values, hodnoty oddělené čárkami, výrobce zaměňuje v dokumentaci formát CSV a sešit aplikace MS Excel, přičemž CSV může být vytvořen se stejnými oddělovači, které používá MS Excel, i jiným programem

37

5. Analýza vybraných pokladních systémů největšího podílu na obratech, ziscích aj.). Reporty lze exportovat do CSV souboru [13]. Modul zaměstnanců zahrnuje uživatelské účty a role, díky kterým lze vymezit přístup k jednotlivým modulům v souvislosti s kompetencemi jednotlivých zaměstnanců. Např. změny v modulu zásob mohou provádět jen osoby k tomu pověřené. Modul umožňuje tvorbu souhrnných a detailních reportů o zaměstnancích, jejich prodejích a ziscích, ať již týkajících se konkrétního prodeje, nebo souhrnu celkových prodejů, zisků aj. Modul ale nepodporuje monitorování docházky, dodržování pracovní doby aj. Stejně tak jako předchozí, i tento podporuje export informací ve formátu CSV souboru [13]. Modul pro tvorbu reportů umožňuje vytváření grafických, souhrnných a detailních reportů a většina těchto reportů byla již zmíněna v předchozím textu [13]. Z pohledu možností systémové integrace výrobce nespecifikuje žádnou možnost. Je tak možné využít integraci na datové úrovni a to přímo z databáze, případně by bylo možné implementovat webové služby. Jedinou podporovanou funkcionalitou je zmiňovaný import a export ve formátu CSV souboru, který podporují některé moduly. Z pohledu podpory hardwaru tak dokumentace uvádí případ použití čtečky čárových kódů. V tomto případě se musí jednat o čtečku, která se chová jako klávesnice, tedy že načtený kód převede na sekvenci alfanumerických znaků. Podpora pak závisí na operačním systému, stejně tak u tiskáren a dotykového displeje. Výrobce explicitně neuvádí optimalizaci pro dotykové displeje. Projekt také nenabízí žádný režim pro rychlé zaučení obsluhy, nicméně nabízí jednoduchou a výstižnou dokumentaci na opensourceposguide. com a podporu lze nalézt na serveru sourceforge.net4 . 5.1.2 Proprietární pokladní systémy Z oblasti proprietárních systémů se v následujících řádcích zaměříme na produkty určené pro místní trh a to z důvodů lokalizace a souladu s českou legislativou. Pokud by produkt tyto vlastnosti neměl, cena za jejich implementaci by mohla neúměrně zvýšit cenu. Software A7 společnosti Apls Zlín s r.o. Společnost Apls s r.o. vyvíjí software v oblasti obchodních systémů a pokladních systémů. Mimo jiné je dodavatelem pokladních systémů pro řetězce Albert a AlbertHypermarket v České republice. Software A7 je obchodní sys4. sourceforge.net/p/opensourcepos/support-requests/

38

5. Analýza vybraných pokladních systémů témem, který je prodáván ve třech verzích specializovaných pro maloobchod, velkoobchod a restaurace. Jedná se o ERP systém zaměřený na obchod, který implementuje: řízení skladu, CRM, fakturace, správu uživatelů, jejich rolí a další funkcionality, které lze nalézt na webové prezentaci této společnosti [2]. Architektura aplikace A7 je klient-server a z technického pohledu je postavená na technologiích společnosti Microsoft. Front-end klientských aplikací je napsán s použitím .NET Frameworku a tyto aplikace využívají aplikační logiku ve formě uložených procedur na databázovém serveru MS SQL. Pro tisk výstupu využívají FastReports. Integrace s ostatními systémy je zajištěná na datové úrovni pomocí ETL a nástroje k tomu využívané jsou Microsoft SQL Server Intergation Services (SSIS). Pokladní systém WPOS A7 je variabilní a umožňuje nasazení v běžném obchodu, restauraci, bazaru, servisu, umožňuje práci se zakázkami, ale i například výdejní bod eshopu. Z pohledu fiskalizace v současnosti podporuje slovenské fiskalizační moduly, ale o plánované elektronické evidenci tržeb chybí kde datu psaní této kapitoly jakékoliv informace. Uživatelské rozhraní je optimalizované pro práci s dotykovým displejem, ale podporuje i práci s klávesnicí. Z pohledu funkcionality tento POS podporuje výběr zboží podle velikostí, barev, výrobních čísel, šarží. Podporované metody plateb jsou úhrada hotovostí, online platebními kartami, valutami, fakturou, zálohovou fakturou, mobilním telefonem pomocí služby Mobito, ale i splátkami a kombinací výše uvedených plateb. Z další funkcionality lze zmínit podporu Cashbacku, věrnostního programu a zákaznických karet, vouchery, bodový systém, slevy, etiketování zboží. Kontrola dokladů formou opis učtu, kopie účtu, tiskový žurnál, stav tržby, práce s reklamacemi, podpora načítání seznamu zboží z mobilních terminálů, práce s objednávkami, fakturami, zálohami. Další funkcionalitou je sledování prodavačů, docházkový systém a jiné[2]. Z uvedených zdrojů není zřejmé, zdali může pokladní systém fungovat samostatně, nebo je nutné jej provozovat zároveň s obchodním systémem A7. Pokladní systémy od Cígler Software Společnost Cígler nabízí tři produkty z oblasti softwarových pokladních systémů – Prodejna SQL, Money S3 Kasa a restaurační systém Conto. Prodejna SQL je určena pro široké spektrum prodejen různých velikostí od malých prodejen až po velké řetězce s mnoha pokladními místy. Pokladní software Prodejna SQL je možné používat samostatně a offline, ale podporuje také integraci s ostatními produkty společnosti Cígler, například se skladovým 39

5. Analýza vybraných pokladních systémů systémem Money. Související produkt Prodejna SQL Centrála umožňuje centrálně nahrávat, spravovat a monitorovat potřebné parametry prodeje. Pro integraci s jinými podnikovými systémy lze využít export a import ve formátu XML nebo PBF 5 . Další možností je využít replikací na úrovni SQL. Synchronizace může probíhat v reálném času nebo dávkově[4]. Uživatelské rozhraní pokladny je standardně optimalizované pro dotykové displeje. Podporovanými platebními metodami jsou platba v hotovosti, kartou nebo ceninou (šek, stravenka apod.) a je podporován prodej v zahraničních měnách, včetně přepočtu podle pevného,nebo denního kurzu. Podporované platební terminály jsou Ingenico a Hypercom. Zajímavou funkcí je Hold pro odložení rozpracovaného účtu a umožnění prodeje na nový účet, s možností návratu k původnímu rozpracovanému účtu. S touto funkcí souvisí možnost Koncept pro vytváření účtu, který je vystaven později. Dále je podporovaná Evidence zákazníků a související benefity. Z pohledu práce se zbožím, pokladní software umí zobrazovat náhled aktuální ceny a skladových zásob daného zboží. Zboží lze vyhledat pomocí PLU 6 nebo EAN kódu, případně podle kategorie zboží[4]. Je podporována uživatelská správa s rolemi. Neobvyklou funkcí je Tréninkový režim, který umožňuje rychle zaučit novou obsluhu pokladny. U hardwarových periferií není uvedeno, že by pokladní systém podporoval standard UnifiedPOS. Výrobce uvádí podporu všech dotykových displejů s minimálním rozlišením 1024x768. Termo tiskárny jsou podporovány OK Print, Star, Epson a jehličkové tiskárny Star a Epson. Zákaznické displeje musí podporovat standardy od spol. EPSON, a to DSP-800, CD-5225. Cena produktu Prodejna SQL byla v době psaní této práce 5990 Kč bez DPH. Dalším produktem společnosti Cígler je Money S3 Kasa, který pracuje jako on-line klient na datech vytvořených v programu Money S3. K prodeji používá standardní doklad (prodejku), výběr a odpis skladových zásob zboží. Používání cenových hladin, úhrady nepeněžními platidly a tvorba informačních sestav probíhají online s návazností na Money S3. Tento pokladní systém neumožňuje nákup a je tak nevhodný pro určité obchody, které vyžadují tuto možnost. Je také nemožné z pokladního místa upravovat ceny a měnit skladové zásoby. Ostatní funkcionalita se shoduje s Prodejnou SQL[4]. Uživatelské rozhraní je optimalizované pro dotykové displeje, ale také pro práci s klávesnicí, pomocí které lze využít klávesových zkratek k vyvolání veškerých funkcí potřebných k prodeji. 5. Protocolbuffer Binary Format - alternativa k XML od Google, která by měla být oproti XML objemově menší a rychleji zpracovatelná 6. interní kód zboží, jednodušší než EAN

40

5. Analýza vybraných pokladních systémů Z pohledu integrace s ostatními systémy je situace závislá na možnostech produktu Money S3. Ceny se liší podle zvolené varianty. Varianta Money S3 Standard je součástí produktu Money S3 a je omezená jedním tisícem skladových karet, jedním skladem a umožňuje pouze příjem hotovostních plateb. Verze Money S3 Kasa Professional nemá výše uvedené limity verze Standard a stojí 3 990 Kč a navíc vyžaduje vlastnit placený komplet Money S3 s modulem Sklady a Objednávky (minimálně komplet Lite). Posledním produktem je restaurační systém Conto, který cílí na pohostinství všech velikostí (od malých bister přes restaurace, ž po rozsáhlé jídelny). Aplikace se prodává ve třech verzích a určité funkcionality vyžadují aktivaci samostatně licencovaného modulu. Základní funkcionalita je vyhledání položek, pomoci uživatelsky definovaného zobrazení na interaktivní obrazovce. Základ taktéž podporuje platby v cizích měnách. Samostatné moduly, které vyžadují zadání licenčního čísla, jsou pro neomezené PLU, pro průvodce snadného rozúčtování, síťových provozů (přístup k informacím z více míst). Dále pro zákaznické účty pro stoly a pokoje, programovatelné přehledy prodejů, online evidenci a zobrazení stavů skladů. Také systém evidence, rezervace stolů a pokojů je formou modulu, stejně tak jako podpora mobilního terminálu a propojení s ekonomickým software Money S3[4]. Integrace s ostatními aplikacemi je umožněná pomocí sdílení informací ve formátu XML. V době psané této práce nebylo dostupné žádné informace o přípravě na elektronickou evidenci tržeb. Ceny bez DPH se pohybují od 6 900 Kč pro nejzákladnější verzi, až po 10 900 Kč po maximální verzi[4]. Pokladní systémy od společnosti Stormware Společnost Stormware nabízí tři možnosti přímého prodeje skladových zásob. První možností je využít agendu Prodejky v programu POHODA7 , další možností je využít agendu Kasa Online, která je součástí určitých verzí programu POHODA 8 . Poslední možností je zakoupit doplňkový program POHODA Kasa Offline, který slouží především pro nasazení v místech, kde není možné se spojit s programem POHODA[15]. Agenda Prodejky programu POHODA uskutečňuje rychlé vystavování prodejních dokladů a eviduje realizované vklady a výběry hotovosti v provozní pokladně. Součástí je i výdej ze skladu a tisk na pokladní tiskárně. 7. komplexní účetní a ekonomický software pro malé, střední i větší firmy 8. pro verze Jazz, Standard, Premium a Komplet

41

5. Analýza vybraných pokladních systémů Agenda Kasa Online, která je součástí programu POHODA, je určena pro maloobchodní prodej a využívá přímo data programu Pohoda, takže veškeré provedené operace jsou aktuální bez nutnosti synchronizace dat. Umožňuje realizovat vklady a výběry z provozních pokladen a zobrazení aktuálního stavu hotovosti a cenin v pokladně, práci se skladem, prodej zásob s evidenčními čísly, přihlašování uživatelů pomocí PIN a čtečkou čárového kódu, odložení rozpracované prodejky, rychlé vkládání položek do dokladu přes tlačítko pro nejčastěji prodávané zboží či tréninkový režim pro vyzkoušení funkcí při prodeji. Podporuje prodej zboží pomocí pobočkového zpracování dat nebo terminálového režimu v samotných prodejních místech. Program také umožňuje nastavení detailů o jednotlivých provozovnách a to názvu kas a provozovny, adres, kontaktů a zařazení do středisek či jednotek[15]. Licenční politika je nastavena tak, že pro více agend Kasa musí být zakoupena síťová verze programu POHODA pro tolik počítačů, na kolika bude agenda Kasa provozována. Pro případy, kde není možné provozovat agendu Prodejky systému Pohoda nebo online prodejny Kasa, je určena offline verze. Pohoda Kasa Offline je určena ideálně pro oblasti výběru zboží pomocí čtečky čárových kódů s výstupem na pokladní tiskárnu prostřednictvím offline prodejního terminálu. Podporuje veškeré funkce jako předešlá Kasa, přičemž pro prodej zboží z počítače v offline verzi není nutné mít nainstalován systém Pohoda ani být připojen do počítačové sítě s instalací tohoto programu, jelikož přenosy dat mezi počítači probíhají dávkově. Možnosti integrace jsou plně závislé na možnostech programu POHODA. Ten nabízí možnost dávkového zpracování XML pro import a export dat. Celé schéma dokumentu XML je uveřejněno ve veřejně dostupných XSD souborech. Ovládání obou dvou kas je optimalizované pro dotykové displeje s možnostmi využití klávesových zkratek. Je také podporována správa uživatelů a jejich přístupových práv. V době psaní této práce nebyly dostupné žádné informace o přípravě na elektronickou evidenci tržeb. Ne velké množství podporované hardwarové příslušenství je uvedeno na stránkách výrobce, s možností zakoupení. O implementace standardu UniPOS nebyla uvedena žádná informace. Ceny verzí programů POHODA s agendou Kasa začínají na 5 980 Kč bez DPH za verzi Jazz pro jedno PC. Síťová licence pro dva až tři počítače vychází na 8 970 Kč bez DPH. Doplňkový software POHODA Kasa Offline je možné zakoupit pouze na základě vlastnictví programu POHODA ve variantách Jazz, Standard, Premium a Komplet[15]. 42

5. Analýza vybraných pokladních systémů

5.2

Shrnutí

Většina proprietárních pokladních systémů je navržena jako doplňkový software pro hlavní produkty, kterými jsou zejména ekonomické softwary jednotlivých výrobců.

43

6 Případová studie V této kapitole demonstrujeme použití dříve analyzovaných technologií a architektur v malé obchodní společnosti. Nejprve se seznámíme s profilem společnosti, na jehož základě analyzujeme požadavky na systém. Na základě této analýzy pak navrhneme implementaci tohoto systému.

6.1

Profil společnosti

Jde o malou rodinnou firmou s personálním obsazením 5 zaměstnanců, která využívá tržní niky se specializací na výrobu pochutin, jejich maloobchodní a velkoobchodní prodej. Společnost má několik stálých dodavatelů, od kterých odebírá konkrétní zboží podle aktuální potřeby, i několik odběratelů, kterým dodávají vlastní, případně distribuují již nakoupené produkty. Pro účel výroby vlastního produktu spolupracují s ověřenou výrobnou, kde si zboží nechávají vyrábět dle svých konkrétních požadavků. Komunikace s partnery, např. realizování objednávek, probíhá pomocí telefonu nebo emailu. Správa zásob je řešená formou sdíleného sešitu. Tato společnost provozuje 2 kamenné obchody na odlišných místech ČR a e-shop. V rámci obchodní činnosti dále nepravidelně vystavují a nabízejí své produkty na různých hudebních a sportovních akcích či výstavách. Jejich vizí je do 5 let navýšit počet obchodů na 6, přičemž každý z nich bude ve větších městech po ČR, v ideálním případě i v zahraničí (EU). Pro dodávání svých výrobků koncovým zákazníkům využívá služeb sjednaného přepravního dopravce, který používá vlastní software pro zadání informací potřebných k zajištění těchto služeb, jako je adresa firmy, místo a čas vyzvednutí dodávaných balíků, jména a adresy koncových zákazníků, kterým přepravní služba balíky doručuje. S tímto softwarem je tedy firma nucena pracovat, např. zadávat adresy aktuálních příjemců. V rámci jeho užívání umožňuje program ukládání zákazníků do systému, pravidelné zákazníky je tedy možné vyhledat, nové je nutné zadat ručně.

6.2

Požadavky na systém

Společnost využívá několik oddělených systémů, které nejsou mezi sebou nijak propojeny a tím vzniká informační mezera. Aby se tato mezera zmenšila, bylo by vhodné tyto procesy propojit. Vhodným kandidátem pro řešení těchto procesů je nasazení ERP systému, jenž by vzhledem k jádru obchodu této společnosti také podporoval řízení dodavatelského řetězce (produkty, skladové 44

6. Případová studie zásoby, ceny, dodavatele, odběratele a logistiku), účetnictví,a řízení vztahů se zákazníky. Pro aktuálnost a úplnost informací o prodejích, které jsou potřeba pro řízení dodavatelského řetězce, je vhodné nasadit pokladní systémy, jenž budou napojené na tento systém. Ty by měly být připraveny na plánovanou elektronickou evidenci tržeb. Dále je nutné, aby ERP systém spolupracoval s e-shopem. S pokladními systémy a e-shopem by měl sdílet produkty, jejich skladové zásoby, maloobchodní ceny a informace o zákaznících a prodejích. Do budoucna by bylo vhodné počítat s možnostmi propojení systému s libovolným účetním programem tak, aby mohl účetní zpracovávat potřebné informace svým užívaným účetním programem. Integrace se systémy přepravních společností by usnadnila a urychlila proces odesílání objednávek zákazníků. Propojení s bankou by urychlilo proces spárování objednávek a příchozích plateb, a tím by se snížil čas potřebný pro vyřizování objednávek. V neposlední řadě by integrace se systémy dodavatelů a odběratelů by zefektivnila řízení skladových zásob. Jelikož společnost investovala značné finanční zdroje do pořízení e-shopu, zřízení a vybavení kamenných obchodů (kdy ani jeden z nich není ještě splacen), nemůže si v tuto chvíli dovolit vynaložit větší objem peněz na pořízení systému v řádu stovek tisíc korun.

6.3

Návrh systému

Z požadavků vyplývá, že projekt bude vyžadovat různé aplikace, ale zároveň nesmí přestavovat velkou počáteční investici. Z tohoto důvodu budeme volit pouze software, který je šířen jako svobodný software. Tím se vyhneme velké počáteční investici, nicméně i takovýto software bude vyžadovat náklady na nasazení, modifikaci a údržbu. 6.3.1 Zvolení softwarových komponent ERP Ve světě open source ERP lze nalézt různě specializované a rozsáhlé ERP systémy. Kromě iDempiere, kterým se v této práci zabýváme, lze zvážit např. Odoo (nový název pro OpenERP), Apache OFBiz a další. Pro naše účely byl zvolen iDempiere z několika důvodů. Především se jedná o vyspělý produkt podporující všechny požadované vlastnosti, ale i proto, že je aktivně vyvíjen a je podporován jak oficiální komunitou, tak i výzkumem v Laboratoři servisních systémů na Fakultě informatiky MU, díky němuž lze nalézt práce týkající se nasazení tohoto ERP do provozu, jeho modifikace aj. 45

6. Případová studie Pokladní systém Z analyzovaných pokladních systémů se pro náš účel nejvíce hodí pokladní systém Unicenta. Podporuje potřebnou funkcionalitu pro práci se zbožím a lokálními skladovými zásobami, podporuje zákaznické, ale i uživatelské účty a to včetně docházky. Vlastnost uživatelských účtů je důležitá pro implementaci elektronické evidence tržeb. Podporuje široké množství hardwarových periferií a je dobře přenositelný, díky implementaci v Javě. Je dostatečně přizpůsobitelný a implementace elektronické evidence tržeb by neměla být obtížnou, díky možnosti tvorby interních skriptů. Změny formátu a položky účtenky lze také jednoduše docílit. Systém bude nutné integrovat na datové úrovni, případně využít dříve implementovaných webových služeb, nebo implementovat návrhový vzor Adapter pattern, nebo Datasource Adapter pro vytvoření nového rozhraní. Bude také nutné vytvořit lokalizaci do češtiny. Elektronická evidence tržeb Elektronická evidence tržeb by mohla být implementována těmito způsoby: ∙ jako součást pokladního systému ∙ jako specializovaný tiskový ovladač ∙ jako nezávislá služba mimo POS Výhodou prvních dvou řešení je, že komunikují s webovou službou daňové správy přímo, a komunikace tak nezávisí na prostřednících, kteří v případě výpadku znemožní proces fiskalizace. Nevýhodou prvního řešení je úzká vazba na POS a změny budou vyžadovat aktualizaci POS. Další nevýhodou je, že tento modul není přenositelný na jiné systémy. Tuto nevýhodu ovšem řeší forma specializovaného tiskového ovladače, ale i nadále zde přetrvává problém aktualizace na všech bodech. Tento problém řeší třetí možnost implementace jako nezávislé služby mimo POS, ale vnáší nevýhodu závislosti na jednom bodu, což může být úzkým hrdlem systému. Pro potřeby naší společnosti jsou vhodné všechny výše zmiňované možnosti, ale v případě zajištění jednoduché aktualizovatelnosti POSů by byla nejvhodnější první varianta. Způsob integrace Aby byla zajištěna integrace všech uváděných a zvažovaných aplikací, je nutné počítat s velkou rozmanitostí systémů. A tak bude nutné se vypořádat s konverzemi protokolů a dat, asynchronními aktualizacemi dat a možnostmi 46

6. Případová studie přidání dalších systémů, zabezpečením, kvalitou služeb a škálovatelností. Proto bychom volili využití ESB architektury. Konkrétní open source projekty, které by mohly být vhodnými kandidáty, jsou Mule ESB a Apache ServiceMix. 6.3.2 Infrastruktura systému Aby se nevytvořila vysoká počáteční investice na infrastrukturu, je možné využít Infrastructure as a Service (IaaS) a Platform as a Service (PaaS). Výhodami tohoto řešení jsou kromě nízké počáteční ceny také úspory za údržbu či snadná škálovatelnost. Nevýhodou může být bezpečnost, která je ale na velmi vysoké úrovni a není tak velkým rizikem. Samotný ERP a ostatní servery by mohly být nainstalovány na virtuálních serverech u poskytovatele IaaS. Databázové servery mohou být nasazeny jako PaaS, díky čemuž se výrazně sníží nutnost údržby těchto serverů. Příkladem poskytovatelů těchto služeb jsou Amazon AWS, z českých např. VSCloud. 6.3.3 Návrh pokladního počítače V této části navrhneme teoretický základ levného a centrálně aktualizovatelného pokladního počítače. Hardware POS POS uniCenta lze provozovat i na méně výkonném hardwaru. Naskýtá se zde tak možnost vyvinout levný POS, který bude založen na hardwaru jako je např. Rapsberry PI (mikropočítač o velikosti kreditní karty), jenž je dostatečně výkonný na to, aby umožnil chod tohoto softwaru. Lze na něm provozovat operační systém Linux a je tak dostatečně adaptabilním pro potřeby související s provozem POS. Z hardwarového hlediska poskytuje tento počítač Ethernet, USB a HDMI. Výhodou je také nízká spotřeba a velikost provedení. Lze tak navrhnout i specializovanou mobilní verzi. Cena takovéhoto produktu by se mohla pohybovat kolem 5 000 Kč včetně displeje a příslušenství. Kromě této varianty lze ovšem využít i běžných PC. Zajištění aktualizací POS Aby bylo možné POS aktualizovat, případně jednoduše nahrazovat, je možné využít nástrojů pro správu konfigurací (Configuration management tool). Jedná se o centralizovanou databázi konfiguračních skriptů, která tak zajistí 47

6. Případová studie jejich aktuálnost. Pokladní počítač tak může pravidelně aktualizovat své konfigurační skripty, a lze tak modifikovat aktualizační procesy v závislosti na aktuálních podmínkách. Také těchto systémů lze využít při instalaci nových pokladních systémů, které se automaticky nakonfigurují na základě aktuálních skriptů. Typickými představiteli těchto systémů jsou Chef a Puppet. 6.3.4 Návrh Work breakdown structure 1. Analýza (a) strategie rozvoje společnosti a jejich vize (b) současného stavu (c) obchodních procesů (d) možných systémů a služeb (e) investiční náročnosti (f) rizik (g) návratnosti investice 2. Návrh (a) architektury (b) implementace a přizpůsobení (c) integrace (d) životního cyklu projektu (e) kontraktu a Service-level agreement 3. Implementace (a) akceptování kontraktu (b) přizpůsobení systémů a služeb (c) infrastruktury architektury 4. Nasazení (a) systémů a služeb (b) testování systémů a služeb (c) zaškolení uživatelů 48

6. Případová studie 5. Údržba (a) přizpůsobování aktuálním požadavkům (b) aktualizace (c) uživatelská podpora 6.3.5 Nástin business plánu služby Pro realizaci výše popisovaného systému a odstranění vysokých počátečních investic by bylo vhodné, aby existoval poskytovatel služeb, jenž umožňuje takovéto řešení. Poskytovatel těchto služeb by mohl mít připravené řešení pro běžné typy obchodní činnosti. Ty by bylo možné za úplatu rozšířit o zákazníkem požadované systémy. Samotné prototypy by obsahovaly základní funkcionalitu, která by mohla být zpoplatněna paušálně, tedy za časový úsek, nebo za počet provedených transakcí. Zdrojem informací o počtu transakcí by byla ESB, jež umožňuje monitoring jednotlivých služeb. Uveďme příklady dvou balíčků služeb, kdy první by byl zaměřen na maloobchod a obsahoval by ERP a volitelně POS, anebo e-shop. POS by byl dodán formou výše navrhovaného jednoúčelového POSu nebo formou služby jako instalace softwaru na zákazníkův hardware. Druhý balíček by byl specializován pro pohostinství a obsahoval by ERP a POS, volitelně webovou prezentaci s online rezervačním systémem.

6.4

Shrnutí

Tato studie přiblížila praktické využití této práce na příkladu malé obchodní společnosti. Byl zde využit systém ERP iDempiere, který je integrován do ESB a na které jsou také integrovány uniCenta POS, e-shop. Provoz serverů byl umístěn do IaaS. Součástí byl i návrh levného hardwaru pro POS. Na závěr byl navrhnut business plán pro poskytování služby.

49

7 Závěr Tato práce se zabývala analýzou POS z řad otevřeného i proprietárního softwaru. V úvodní kapitole byly popsány cíle práce, co jsou pokladní systémy a jejich vlastnosti. Dále byl stručně popsán ERP iDempiere. Druhá kapitola se zabývala současnými legislativními nároky na pokladní systémy v českém prostředí. Na tuto část navázala třetí kapitola, která uvedla problematiku připravované elektronické evidence tržeb a současnou podobu vzoru z Chorvatska. Čtvrtá kapitola byla zaměřená na možnosti integrace pokladních systémů s ERP. Byly zde probrány architektury integrace, ale i technické možnosti. Bohužel téma integrace je velice komplexní a nebylo možné se v rámci této práce zmíněnou problematikou zabývat hlouběji. V další kapitole byla provedena analýza dostupných pokladních systémů a to jak z řad open source, tak i proprietárních. Šestá kapitola byla věnována případové studii, ve které byly informace z předchozích kapitol využity na konkrétním případu malé obchodní společnosti. Současně zde byl také navrhnut základní byznys model služby, která by umožnila nasazení těchto systémů i v malých podnicích. V návaznosti na tuto práci by mohl například vzniknou projekt, který by vyvíjel svobodnou implementaci elektronické evidence tržeb pro otevřený pokladní systém. Kombinace svobodné implementace pokladního systému a podpory elektronické evidence tržeb by mohla usnadnit příchod této změny malým živnostníkům i společnostem a v nejlepším případě rozšíření ERP systému iDempiere do malých podniků. Současně zde byla zmíněna možnost tvorby levného pokladního počítače, založeného na mikropočítači, který by taktéž mohl vzniknout jako svobodný projekt.

50

Seznam zkratek API Application Programming Interface. 30, 33 B2C Business to Customer. 11 CRM Customer Relationship Management. 8, 39 CSV Comma-separated values. 23, 24, 37 DIČ daňové identifikační číslo. 13 DPH daň z přidané hodnoty. 10, 14 EAI Enterprise Application Integration. 26 EAN European Article Number. 5 EDI Electronic Data Interchange. 12 EIP Enterprise Integration Patterns. 29 ERP Enterprise Resource Planning. 3 ESB Enterprise Service Bus. 19, 26, 31 ESC Electronic Stability Control. 7 ETL Extract, Transform and Load. 25, 39 FTP File Transfer Protocol. 31 GNU GPL GNU’s Not Unix General Public Licence. 8, 36 HTTP Hypertext Transfer Protocol. 31 IaaS Infrastructure as a Service. 47 IČ identifikační číslo. 15 IT Informační technologie. 7 JavaPOS Java for Point of Sale Devices. 7, 19 51

7. Závěr JMS Java Messanging System. 28–30 KPI Key Performance Indicator. 5 L/WAMP Linux/Windows Apache, MySQL a PHP. 37 LPT Line Printer Terminal. 6 MIT Massachusettský technologický institut. 36 MOM Message Oriented Middleware. 26, 27, 29, 32 MS SQL Microsoft Structured Query Language. 39 MySQL My Structured Query Language. 37 OPOS Object Linking and Embedding for Retail Point of Sale. 7, 19 OSGi Open Service Gateway initiative. 9, 23 OSPOS Open Source Point of Sale. 36 PaaS Platform as a Service. 47 PBF Protocolbuffer Binary Format. 40 PDA Personal Digital Assistant. 36 PHP Hypertext Preprocessor. 36 PIN personal identification number. 42 PLU Price look-up code. 40 POP3 Post Office Protocol 3. 31 POS Point of Sale. 4 QoS Quality of Service. 32 REST Representational state transfer. 28 RPC Remote Procedure Call. 26 SaaS Software as a service. 4 52

7. Závěr SCM Supply Chain Management. 8 SFTP Secure File Transfer Protocol. 24 SLA Service-level agreement. 28, 48 SMS Short Message Service. 16 SMTP Simple Mail Transfer Protocol. 28, 31 SOA Servisně Orientovaná Architektura. 23, 28 SOAP Simple Object Access protocol. 28, 29 SSIS SQL Server Integration Services. 39 SSL Secure Sockets Layer. 17 UPOS Unified Point of Sale. 7 URI Uniform Resource Identifier. 28 URL Uniform Resource Locator. 31 USB Universal Serial Bus. 6 WSDL Web Services Description Language. 28, 29 XML Extensible Markup Language. 17, 40 XSD XML Schema Definition. 42

53

Seznam obrázků 1.2

Znázornění kompletního balíku ERP ADempiere, ze kterého vychází iDempiere 8

3.1

Sekvenční diagram procesu komunikace mezi pokladním systémem a informačním systémem daňové správy [6] 18

4.1 4.2 4.3 4.4

4.6

Znázornění architektury Point-to-Point 25 Znázornění architektury Hub and Spoke 26 Datová integrace 27 Obrázek zobrazuje EAI architekturu, využívající sběrnicovou topologii, převzato z [21] 28 Model integrace OpenbravoPOS s ERP ADempiere, autor Redhuan D. Oon 30 Znázornění architektury sběrnice 31

A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 A.10 A.11 A.12

uniCenta:: Přihlašovací obrazovka 60 uniCenta:: Maloobchod 60 uniCenta:: Platba 61 uniCenta:restaurace 61 uniCenta: účtenka 62 uniCenta: Zákazníci 63 uniCenta: Nastavení - údržba 63 uniCenta: Denní uzávěrka 64 OSPOS: Obchod 64 OSPOS: Účtenka 65 OSPOS: Sklad 65 OSPOS: Zákazníci 65

4.5

54

Reference [1] ADempiere Documentation. URL http://www.adempiere.com/ADempiere_ERP [2] Apls s r.o. Zlín, webová prezentace společnosti. URL http://www.apls.cz/ [3] The Cash Transaction Fiscalization Act. URL http://www.fiscalization.hr/en/fiscal-law [4] CÍGLER SOFTWARE, webová prezentace společnosti. URL www.money.cz/pos/pokladni-software/ prodejna-sql/ [5] Elektronické evidence tržeb ano, ale pokud podceníme přípravu, bude to fiasko. URL http://www.amsp.cz/ [6] Fiskalizacija - Tehnička specifikacija za korisnike. [7] iDempiere Documentation. URL http://wiki.idempiere.org/en/Main_Page [8] Informační leták Ministerstva financí ČR k registračním pokladnám. URL http://business.center.cz/business/finance/ ucetnictvi/registracni-pokladny.aspx [9] Ministerstvo financí vyšlo vstříc požadavku AMSP ČR: Elektronická evidence tržeb se bude zavádět postupně. URL http://www.amsp.cz/ [10] National Retail Federation website. URL http://nrf.com [11] Openbravo POS Direct Integration. URL http://wiki.openbravo.com/wiki/Projects: POS/ERP_Integration [12] Openbravo POS Localization. URL http://wiki.openbravo.com/wiki/Projects: POS/Localization 55

. Reference [13] OSPOS Guide. URL http://www.opensourceposguide.com/ [14] Rozhovor s náměstkyní pro daně a cla Simonou Hornochovou. URL http://www.mfcr.cz/cs/aktualne/v-mediich/2014/ rozhovor-s-namestkyni-pro-dane-a-cla-sim-19188 [15] STORMWARE s.r.o., webová prezentace společnosti. URL http://www.stormware.cz/ [16] UnifiedPOS Retail Peripheral Architecture. URL https://nrf.com/resources/ retail-technology-standards/unifiedpos [17] Zákon 235/2004 Sb., o dani z přidané hodnoty. URL http://portal.gov.cz/app/zakony/zakonPar.jsp? page=0&idBiblio=57849&recShow=58&nr=235~2F2004&rpp= 100#parCnt [18] AJIT, K.: ADempiere 3.6 Cookbook. Birmingham: Pack Publishing, 2011, ISBN 978-1-84951-338-8. [19] CHAPPELL, D.: Enterprise Service Bus: Theory in Practice. O’Reilly Media, 6 2004, ISBN 9780596006754. URL http://amazon.com/o/ASIN/0596006756/ [20] COLLINS, P.: Anglicko-český obchodní slovník: (výkladový). Pragoeduca, 1996. [21] DAVIS, J.: Open Source SOA. Manning Publications, 7 2009, ISBN 9781933988542. URL http://amazon.com/o/ASIN/1933988541/ [22] GERRARD, J.: uniCenta, webová prezentace projektu. URL unicenta.com [23] HOHPE, G.; WOOLF, B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, 10 2003, ISBN 9780321200686. URL http://amazon.com/o/ASIN/0321200683/ [24] IBSEN, C.; ANSTEY, J.: Camel in Action. Manning Publications, 1 2011, ISBN 9781935182368. URL http://amazon.com/o/ASIN/1935182366/ 56

. Reference [25] KRNÁČ, I.: Adaptácia ERP systému ADempiere [online]. 2012. URL http://is.muni.cz/th/325395/fi_b/ [26] KRNÁČ, I.: Příprava ERP Adempiere pro reálnou implementaci. Diplomová práce, Masarykova univerzita, Fakulta informatiky, 2013. URL http://is.muni.cz/th/325395/fi_m/ [27] MULAČOVÁ, V.; MULAČ, P.: Obchodní podnikání ve 21. století. Grada Publishing a.s.„ 2013, ISBN 9788024786384. [28] OTTO, P.: Tripartita se shodla na registraci tržeb. 2014-10-21. URL http://zpravy.e15.cz/domaci/politika/ tripartita-se-shodla-na-registraci-trzeb-1129923 [29] Pappas Technologies, L.: Open Source Point of Sale. URL http://sourceforge.net/projects/opensourcepos/ [30] Poduval, A.; Todd, D.; Gaur, H.; aj.: Do more with SOA Integration: Best of Packt. Packt Publishing, 12 2011, ISBN 9781849685726. URL http://amazon.com/o/ASIN/184968572X/ [31] RICHARDS, M.; MONSON-HAEFEL, R.; CHAPPELL, D. A.: Java Message Service. O’Reilly Media, 6 2009, ISBN 9780596522049. URL http://amazon.com/o/ASIN/0596522045/ [32] RIKKILA, J.; ROSSI, B.: Infrastructures for Open Service Oriented Architecture: ESB and Middleware, 2012. [33] ROMERO, A.: Openbravo POS Scripting Tutorial. URL http://wiki.openbravo.com/wiki/Openbravo_POS_ Scripting_Tutorial [34] ROTEM-GAL-OZ, A.: SOA Patterns. Manning Publications, 9 2012, ISBN 9781933988269. URL http://amazon.com/o/ASIN/1933988266/ [35] SEDLÁČKOVÁ, I.: Svobodný software. Diplomová práce, Masarykova univerzita, Právnická fakulta, 2012. URL http://is.muni.cz/th/256225/pravf_m/ [36] SEGÉŇ, J.: Connecting ERP and e-commerce systems. Diplomová práce, Masarykova univerzita, Fakulta informatiky, 2014. URL http://is.muni.cz/th/324891/fi_m/ 57

. Reference [37] Professional Fiscal Services and Products in Croatia. URL www.serviceplus-it.com [38] SNYDER, B.; BOSANAC, D.; DAVIES, R.: ActiveMQ in Action. Manning Publications, 3 2011, ISBN 9781933988948. URL http://amazon.com/o/ASIN/1933988940/ [39] TOVARŇÁK, D.: Směrování komunikace na ESB [online]. 2008. URL http://is.muni.cz/th/172673/fi_b/

58

A Snímky obrazovek

59

A. Snímky obrazovek

Obrázek A.1: uniCenta:: Přihlašovací obrazovka

Obrázek A.2: uniCenta:: Maloobchod

60


Obrázek A.3: uniCenta: Platba

Obrázek A.4: uniCenta: Restaurace

61


Obrázek A.5: uniCenta: Účtenka

62


Obrázek A.6: uniCenta: Zákazníci

Obrázek A.7: uniCenta: Nastavení - údržba

63


Obrázek A.8: uniCenta: Denní uzávěrka

Obrázek A.9: OSPOS: Obchod

64


Obrázek A.10: OSPOS: Účtenka

Obrázek A.11: OSPOS: Sklad

Obrázek A.12: OSPOS: Zákazníci

65

Použití POS a možnosti jejich integrace do ERP systémů: případová studie

Recommend Documents