Mendelova univerzita v Brně Provozně ekonomická fakulta
Realizace systému evidence nabídek a zpracování kalkulací cen EMS služeb pro společnost Mikroelektronika Bakalářská práce
Vedoucí práce:
Vypracoval:
Ing. Michael Štencl, Ph.D.
Štěpán Mračko
Brno 2012
Děkuji vedoucímu bakalářské práce panu Ing. Michaelu Štenclovi, Ph.D. za cenné rady, připomínky a metodické vedení této práce.
Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a použil pouze literaturu uvedenou v přiloženém seznamu. V Brně dne 3. ledna 2012
__________________
Abstract The objective of this thesis is to design and implement a new quotation system for Mikroelektronika company in the EMS business area based on an analysis of the current methods of prices calculation and based on current quotation system. The new quotation system should eliminate the fundamental short comings of the existing system. The new system uses a relational database Microsoft SQL Server Express, and is programmed as a web application using PHP scripting language via Nette Framework. Keywords EMS, quotation system, prices calculation, Nette Framework, PHP, SQL.
Abstrakt Cílem této bakalářské práce je na základě analýzy současného způsobu tvorby nabídek a kalkulace cen služeb v podnikatelské oblasti EMS společnosti Mikroelektronika navrhnout a realizovat nový systém, který by měl odstraňovat základní nedostatky stávajícího systému. Nový systém využívá relační databázový systém Microsoft SQL Server Express a je naprogramován jako webová aplikace pomocí skriptovacího jazyka PHP za použití nástroje Nette Framework. Klíčová slova EMS, nabídkový systém, kalkulace cen, Nette Framework, PHP, SQL.
Nové workflow nabídky ........................................................................... 51
4.10 Uživatelské rozhraní ................................................................................ 51 5
Diskuse
52
6
Závěr
54
7
Literatura
56
Obsah
9
A
Popis nabízených EMS služeb
59
B
Stávající proces zpracování nabídky
61
C
Přehled funkcí kalkulačního nástroje
63
D
ERD databáze EMS
66
E
Adresářová struktura aplikace
72
F
Výchozí nastavení práv přístupu
74
G
Zdrojové kódy
77
H
Nové workflow nabídky
84
I
Popis uživatelského rozhraní
86
10
Seznam obrázků
Seznam obrázků Obr. 1
Kontextový diagram
28
Obr. 2
Systémový diagram
29
Obr. 3
DFD evidence nabídek
30
Obr. 4
DFD evidence produktu
31
Obr. 5
DFD modulu TPV
32
Obr. 6
Základní ovládací prvky aplikace
36
Obr. 7
ERD firmy
40
Obr. 8
Formulář pro zadání nové firmy
40
Obr. 9
ERD Setu režijních sazeb
41
Obr. 10
Formulář pro hromadné zadání režijních sazeb
42
Obr. 11
Kontrola CSV dat před importem
44
Obr. 12
Dotčené tabulky při importu dat
45
Obr. 13
ERD tabulek databáze ERP systému
46
Obr. 14
Způsob prohledávání tabulky zbozi databáze K2
47
Obr. 15
Náhled zobrazení komponenty VisualPaginator
48
Seznam tabulek
11
Seznam tabulek Tab. 1
Klady a nedostatky stávající aplikace
26
Tab. 2
Struktura CSV kusovníku
42
Tab. 3
Metody pro práci s CSV souborem
44
12
Úvod a cíl práce
1 Úvod a cíl práce 1.1
Úvod
Společnost Mikroelektronika působí na trhu již do roku 1991 a je vedoucí společností na trhu vývoje, výroby a instalací odbavovacích systémů ve veřejné dopravě. Kromě domácího trhu je velmi aktivní i v zahraničí. Nejvýznamnějším teritoriem, na kterém dlouhodobě velmi úspěšně působí je Latinská Amerika. Systémy z vysokomýtské společnosti jsou provozovány v Santiagu de Chile, Montevideu, Limě, Buenos Aires, Córdobě, Panama City, ale i v evropských hlavních městech jako např. Stockholm, Sofie, Záhřeb a mnoha dalších. V České republice jsou elektronickými odbavovacími systémy vybaveny prakticky všechna krajská města a velcí i menší dopravci v meziměstské i příměstské a městské dopravě. Od roku 2004 se vedení společnosti rozhodlo diversifikovat své aktivity do oblasti, která je velmi příbuzná s hlavním podnikatelským zaměřením firmy, kterou je poskytování služeb ve výrobě elektroniky pro ostatní výrobce. Společnost se postupně vybavovala kvalitní výrobní technologií pro výrobu osazených desek plošných spojů, aby výrobu svých náročných zařízení měla plně pod kontrolou a přebytečnou kapacitu těchto technologií začala nabízet dalším průmyslovým výrobcům v oblasti automotive, výroby energetických zařízení, telekomunikací, medicínských přístrojů či vojenských systémů. Odtud se nyní po sedmiletém podnikání v této oblasti rekrutují zákazníci v této podnikatelské oblasti. Vysoké kvalitativní nároky a specifické potřeby těchto zákazníků motivují firmu k dalším investicím do špičkových technologií. Podíl tržeb na celkovém firemním ročním obratu činí cca 30 %, přičemž dnes téměř 70 % kapacit technologických zařízení je využíváno zákazníky v této oblasti. Systém pro tvorbu a kalkulaci cenových nabídek v nové podnikatelské oblasti EMS (electronic manufacturing services) ve společnosti Mikroelektronika je nezbytný pro zajištění kvality služeb zejména v obchodní činnosti. V současné době se kalkulace a nabídky zpracovávají velmi pracně za pomocí aplikace MS Excel. V nabídkách se obtížně orientuje a cenotvorba materiálových položek není provázána s oddělením nákupu a ERP systémem. Jedná se o ruční přepisování hodnot cen jednotlivých materiálových položek do kalkulačního excelovského nástroje. Stávající používaný ERP systém neumožňuje komfortní tvorbu kalkulace a nabídek pro oblast EMS neboť je historicky spíše rozvíjen pro podporu výroby zařízení pro odbavovací systémy (core business).
1.2 Cíl práce Cílem této práce je na základě analýzy současného způsobu tvorby cenových nabídek a kalkulace cen služeb v podnikatelské oblasti EMS společnosti Mikroe-
Úvod a cíl práce
13
lektronika navrhnout a realizovat nový systém, který by měl odstraňovat základní zjištěné nedostatky stávajícího systému. Nový systém musí být schopen uchovávat a zpřístupňovat veškerá data týkající se tvorby cenové nabídky (kompletně oceněnou rozpisku materiálu, použité výrobní technologie vč. spotřeby času a nákladů a případné další vedlejší náklady – příprava na dávku, jednorázový materiál na dávku apod.). Měl by umožnit importovat materiálové rozpisky (zadání od zákazníka – desítky až stovky komponent na každé straně desky) do nového systému a poskytovat k nim přístup pro oddělení nákupu pro přiřazení k položkám evidovaným v ERP systému. Návaznost na číselníky stávajícího ERP je nezbytná (materiálové položky, ceny, dodavatelé apod.). Je preferováno použití databázového systému MS SQL, který je ve společnosti běžně využíván. Cenová kalkulace EMS služby či produktu sestává krom ocenění materiálových nákladů též stanovením ceny práce – ocenění spotřeby času na jednotlivých pracovištích a technologiích v procesu výroby osazené desky plošných spojů (DPS). Na těchto pracích se podílejí další oddělení společnosti – systém musí tuto kooperaci podporovat. Počet a druh jednotlivých technologií musí být v systému konfigurovatelný (nové technologie se v rámci investování do rozvoje průběžně doplňují) – každá cena se pak tvoří jednak oceněním materiálu a jednak výběrem pracovišť a technologií kudy výroba probíhá a určením spotřeby času v jednotlivých operacích strávených na pracovišti.
14
Materiál a metodika zpracování
2 Materiál a metodika zpracování Pro návrh nového systému tvorby nabídek je nutné se seznámit s technologiemi, které budou použity. K analýze problému bude využito metodiky strukturované analýzy, jejímž výstupem bude funkční a datový model v podobě diagramu datových toků, respektive entitně-relačního diagramu. Vlastní databáze bude navržena na základě ERD diagramu v prostředí MS SQL Serveru s využitím jazyka Transact-SQL a k návrhu vlastní aplikace bude použit PHP Framework Nette, který podporuje návrhový vzor MVC (Model-View-Controller).
2.1 Strukturovaná analýza Strukturovaná analýza je, jak uvádí Techopedia.com (2011), technika v systémovém inženýrství, která používá grafické vyjádření, pro snadnější představu o vyvíjeném systému, či aplikaci a snadnější komunikaci se zákazníkem při představě o jeho konečné podobě. Zaměřuje se na specifikaci, CO se vyžaduje od systému, aby dělal. Cílem je převést „business“ požadavky zákazníka do počítačové aplikace a hardwarové specifikace. Podle Yourdona (2006) k těmto účelům slouží systémovému analytikovi následující modely. a) Funkční model Funkční model je reprezentován diagramem datových toků (Data Flow Diagram, DFD). DFD je grafický modelovací nástroj pro znázornění systému jako sítě procesů, které jsou mezi sebou spojeny datovými toky a kde data jsou uložena v tzv. datových skladech. DFD tedy slouží k modelování funkcionality systému. DFD se skládá ze čtyř komponent: a.1. Procesy – jsou místo, kde dochází k transformaci vstupních dat na výstupní data. Graficky jsou znázorněny jako kolečka a musí se číslovat; a.2. Datové toky – propojují procesy, jsou to jakési trubky, kterými různými směry proudí data. Graficky jsou znázorněny jako šipky; a.3. Datové sklady – jsou místa, kde jsou data shromažďována (například databáze). Datové toky zde ukládají výstupní data z procesu, nebo datové toky odtud čerpají vstupní data do procesu. Graficky jsou znázorněna jako dvě vodorovné čáry; a.4. Terminátory – jsou lidé nebo skupina lidí, kteří komunikují se systémem, ale jsou mimo hranice našeho systému. Graficky jsou znázorněny jako obdélníky. Aby nedocházelo k situaci, že DFD diagram bude sestávat z několika desítek procesů a bude tak nečitelný, či nepřehledný, je potřeba DFD diagramy tzv. dekomponovat. To znamená, že DFD diagramy tvoří hierarchickou síť DFD, kde následující DFD diagram je detailnější, než DFD diagram předcházející. Názorně lze toto vysvětlit na atlasu map, kde nejvyšší úroveň abstrakce je
Materiál a metodika zpracování
15
mapa celého světa, dekompozicí (rozkladem) dostaneme mapy světadílu, jejichž dekompozicí dostaneme např. regiony určitého světadílu, atd., atd. Nejvyšší úroveň abstrakce u DFD je tzv. kontextový diagram, kde systém je zastoupen jedním procesem a jeho okolím, určuje hranice mezi systémem a okolím. Okolí je zde znázorněno prostřednictvím terminátorů a datových toků, které zprostředkovávají komunikaci mezi terminátory a systémem. Při dekompozici dojde ke vzniku tzv. systémového diagramu (diagram nulté úrovně), ten, jak už bylo dříve řečeno, obsahuje detailnější zobrazení systému. Oproti kontextovému diagramu se zde nacházejí datové sklady a dochází zde k přeměně vstupních dat na výstupní. Následující DFD se již označují jen číslem úrovně. b) Datový model V DFD diagramu komponenta datový sklad znázorňuje existenci skupin uložených dat, nicméně není dostatečně detailní. Nestačí pouze znát detailně, jaké informace jsou obsaženy v každém datovém skladu, ale je potřeba také vědět vztahy mezi datovými sklady. Pro tento účel slouží grafický nástroj entitně-relační digram (Entity-Relationship Diagram, ERD). ERD slouží tedy pro znázornění dat. Stejně jako DFD i ERD sestává z několika komponent (Conolly, 2009). b.1. Entita – je množina objektů se stejnými vlastnostmi, které lze označit za nezávisle existující objekty. Je to věc, která je jednoznačně identifikovatelná a schopná samostatně existovat, může být jak konkrétní, tak abstraktní. b.2. Atributy – popisují vlastnosti entit nebo relací. Kvantifikují, kvalifikují určitou entitu. Je jím právě jedna hodnota určitého datového typu, která nabývá hodnot z určité domény. b.3. Relace – je množina smysluplných spojení mezi entitami. Relace (vztah) je popsána jménem, kardinalitou (násobnost – 1:1, 1:N, M:N) a parcialitou (povinnost či volitelnost).
2.2 MS SQL a Transact-SQL Transact-SQL (T-SQL) je založeno na SQL standardu, který v roce 1992 publikoval institut ANSI, tento standard je znám také jako SQL-92. Transact-SQL nelze používat samostatně jako např. C++, je totiž součástí Microsoft SQL Server. Veškeré aplikace komunikují s instancemi SQL Serveru právě prostřednictvím T-SQL příkazů. Toto rozšíření nabízí různé datové typy, deklarace proměnných, konstant, dočasné objekty, možnost použití systémových uložených procedur nebo vytvoření svých vlastních, kurzory, kterými lze data procházet oběma směry, operátory, řídící struktury, řízení transakcí, ošetření výjimek a řízení chyb (Kline a další, 1999).
16
2.2.1
Materiál a metodika zpracování
Zpracování řádků vs. zpracování množin
Zpracování řádků (Row processing) znamená, že program postupuje řádek po řádku a zkoumá, zda záznam vyhovuje požadovaným kritériím, tento styl programování se také nazývá deklarativní. Na druhou stranu zpracování množin (Set processing), zpracovává data jako skupinu řádků. Programátor jen sděluje SQL Serveru, jaká požaduje data – tomuto přístupu se říká deklarativní programování. Například přijde do supermarketu zákazník se seznamem ingrediencí potřebných pro přípravu nějakého jídlo. Pokud nechodí často nakupovat, bude procházet uličku po uličce a pokaždé pročítat celý seznam dokud nenajde všechny ingredience. Tento přístup je právě zpracování po řádcích. Nejlepší by ovšem bylo, aby při vstupu do supermarketu zákazník pouze předal seznam jednomu z pracovníků, ať se o to postará. Zákazníka totiž nezajímá, jak jednotlivé ingredience najde, ale zda má všechny, o které žádal. Je zřejmé, že zaměstnanci supermarketu nebude tak dlouho trvat veškeré ingredience najít. Toto je právě zpracování po množinách (Kline a další, 1999). Dle Microsoft Technet (2011) T-SQL umožňuje deklarování a používaní lokálních proměnných a konstant v rámci T-SQL objektu. Tyto proměnné a konstanty musí být datového typu, který je databázi známý. Je možné si také vytvořit svoje vlastní speciální datové typy navrch systémových datových typů. Existují i speciální datové typy jako Identity, ten automaticky zvyšuje čítač v rámci určitého sloupce, nebo Timestamp, který každý řádek označí unikátní značkou. Globální proměnné umožňují uživateli získat okamžitou zpětnou vazbu od systému, mají prefix @@. T-SQL poskytuje několik užitečných dočasných objektů, které trvají jenom tak dlouho, jako současná session (dokud je uživatel připojen k databázi). Tyto objekty zahrnují jak tabulky, tak uložené procedury. Syntaxe je SELECT – INTO název tabulky, kde název tabulky má prefix #, globální dočasná tabulka má prefix ##. 2.2.2
Uložené procedury
Uložená procedura je skupina T-SQL příkazů, které byly předdefinované a předkompilované na serveru. Uložená procedura může přijímat parametry a vracet množinu výsledků či výstupní parametry do volající aplikace. Triggery jsou speciální uložené procedury, které nevolá aplikace přímo, nýbrž jsou vykonány či „spuštěny“, kdykoliv uživatel modifikuje relaci – příkazy INSERT, UPDATE, DELETE (Lacko, 2003b). 2.2.3
Řídící struktury
Umožňuje používat podmíněnou logiku IF – ELSE. Iterativní zpracování WHILE, GOTO, CONTINUE restartuje WHILE smyčku (loop), BREAK výstup z loopu, WAITFOR zastaví proceduru, dokud neuběhne stanovená doba, BEGIN – END ohraničuje blok T-SQL příkazů, které mohou být vykonány, RETURN navrátí hodnotu procedury, odchycení výjimek TRY – CATCH (Microsoft, 2011).
Materiál a metodika zpracování
2.2.4
17
Řízení chyb
Umožňuje upravit způsob, kterým SQL Server reaguje na problémy, specifikovat odpovídající akce na chyby, pokud nějaké nastanou, nebo zobrazit uživatelem definovaná chybová hlášení, která jsou pro uživatele více informativní než obecná chybová hlášení SQL Serveru (Microsoft, 2011). 2.2.5
T-SQL 2008
T-SQL 2008 je založeno na standardu SQL 2008 z července 2008. Jak uvádí Pawar (2008), tak mezi nejzásadnější novinky patří složené operátory přiřazení. Vylepšení funkce CONVERT (konverze mezi binárním datovým typem a znakem hexadecimální hodnoty). Příkaz MERGE, GROUPING SETS, nové datové typy pro datum a čas, nový datový typ Tabulka. Vložení několika řádků prostřednictvím klauzule VALUE jediným INSERT příkazem, inicializace proměnných během jejich deklarace. 2.2.6
Stránkování
Stránkování výsledných záznamů SQL dotazu je pro uživatele pohodlnější cesta, jak se orientovat v těchto záznamech. Při stránkování výsledné množiny záznamů, je potřeba zobrazit jen ty záznamy, které uživatel požaduje v závislosti na tom, na které stránce se nachází a také po kolika záznamech se výsledné záznamy SQL dotazu budou na stránce zobrazovat. Při vytváření stránkování uvádí Mitchell (2006), že je potřeba si stanovit 3 proměnné, které definují jaké záznamy je potřeba zobrazit a jak by se měly zobrazit na stránce. Index prvního řádku (IPR) je index prvního řádku každé stránky dat, který se zobrazí. Může se vypočítat tak, že se vynásobí index stránky s počtem záznamů na stránku a přičtením jedné. Například stránkujeme po 20 záznamech, pro první stránku, která má index 0, je index prvního řádku 1, protože 0×10+1=1 . Maximální počet řádků (MPR) je maximální počet záznamů pro každou stránku. Celkový počet záznamů, které se budou stránkovat. Tím, že je známé IPR a MPR, musí dostat uživatel pouze určitou podmnožinu z množiny všech záznamů. Je tedy potřeba přiřadit index každému řádku ve výsledné množině záznamů, které bude potřeba stránkovat, tak aby tyto záznamy začínaly IPR až do MPR na stránku. Řádky tabulek v databázi této práce mají sice už sloupeček s identifikátorem řádku, ale tím, že by došlo k jeho smazání, by vznikla mezera, která by tento přístup znemožnila. Proto bylo potřeba využít funkci ROW_NUMBER().
18
Materiál a metodika zpracování
Funkce ROW_NUMBER() přiřadí každému záznamu či řádku výsledné množiny SQL dotazu, který ale musí být nějakým způsobem seřazený, pořadové číslo a toto číslo je právě potřebný index pro každý řádek. Dotaz vypadá následovně: SELECT seznamSloupcu, ROW_NUMBER() OVER (ORDER BY klauzule) FROM nazevTabulky.
Výsledné očíslované záznamy, ale nelze přímo omezit klauzulí WHERE, což je potřeba pro výběr konkrétní podmnožiny. Proto je nutné dotaz s ROW_NUMBER vnořit do jiného, který poté klauzulí WHERE omezí výběr na konkrétní záznamy tím, že operátor BETWEEN definuje interval, do něhož musí spadat číslo řádku, aby byl výsledek predikátu pravdivý (Gruber, 2004). Tyto výše zmíněné postupy byly využity pro funkci zobrazující položky stránkovaně. Vstupní parametry funkce jsou $limit(MPR) a $offset(IPR). Číslo aktuální stránky získáme z rovnice: . Samotné stránkování poté zajistí následující SQL dotaz. SELECT * FROM (SELECT ROW_NUMBER() OVER(ORDER BY id) AS RowNum, * FROM zbozi) tmp WHERE tmp.RowNum BETWEEN ($page−1)*$limit+1 AND $page*$limit;
2.3 Dibi Dibi je databázová vrstva, která slouží ke zjednodušenému zápisu SQL příkazů. Jedná se o PHP knihovnu, která obsahuje ovladače až pro osm databází (MySQL, MySQLi, PostgreSQL, SQLite, ODBC, MS SQL, Oracle a PDO) a která má, jak uvádí Grudl (2007), za cíl: asistovat při psaní SQL dotazů, přehledný zápis SQL příkazů, snadný přístup k metodám, přenositelnost mezi databázovými systémy – uvozování identifikátorů, automatické formátování specifických typů, sjednocení základnách funkcí (připojení k databázi, vykonání příkazů, získávání výsledků). Připojení k databázi zajišťuje objekt DibiConnection prostřednictvím driveru pro konkrétní databázi. Zápis SQL příkazů je ve stylu fluent interface (plynulé rozhraní). Fluent interface je implementací objektově orientovaného API, jehož cílem je zpřehlednit napsaný kód (Fluent interface, 2007). Běžně je tento přístup implementován tím, že jednotlivé metody, objekty jsou na sebe řetězovitě navázány tak, aby kontext informací zůstal zachovaný pro navazující volání.
Materiál a metodika zpracování
19
Např. select ('*')->from('produkty')->orderBy('nazev') vypíše všechna data z tabulky produkty, kde produkty budou seřazeny sestupně podle názvu. Samotné SQL příkazy se zapisují jako série parametrů a před vložením proměnné je potřeba uvést modifikátor, který databázi sdělí jakého je proměnná typu a naformátuje se do výsledného SQL podle pravidel databáze. Příkaz select('*')->from('material')->where('id=%i', $id) vypíše z tabulky material veškerá data pro konkrétní ID materiálu, %i značí, že proměnná $id je typu integer. Dále je možné aplikovat modifikátor na všechny prvky pole, postupně skládat dotaz, použít podmíněné příkazy pomocí klíčových slov %if, %else a %end, specifikovat datové typy jednotlivých sloupců a mnoho dalších možností (Nette foundation, 2011a).
2.4 Model-View-Presenter (MVP) a Nette Framework Nette Framework (NFW) je výkonný framework od českého tvůrce sloužící pro vytváření webových aplikací v PHP 5. Cílem tohoto frameworku je znovupoužitelnost kódu, eliminace bezpečnostních rizik, srozumitelnost syntaxe, snadné tvoření aplikací. V dalším textu bude popisována verze 2.0 beta, která byla rovněž použita při implementaci, použitý zdroj je Nette foundation (2011b). Nette Framework podporuje návrhový vzor Model-View-Controller (MVC), kde ale místo slova controller používá slovo presenter. Cílem tohoto vzoru je rozdělení aplikace na tři části, které je tak možné udržovat samostatně, což vede ke snadnější údržbě, k zpřehlednění a flexibilitě aplikace (Pecinovský, 2007). Principem MVP je to, že uživatel vyšle požadavek na aplikaci, příslušný presenter tento požadavek přeložený z http požadavku uživatele zpracuje a pošle do modelu požadavek na data, která od něj potřebuje. a) Presenter V aplikaci může být několik presenterů, které mohou tvořit hierarchie a každý presenter může mít několik akcí, pomocí kterých se aplikace řídí. Každý presenter by měl inicializovat model, zavolat nějakou akci modelu, inicializovat pohled, předat výstup z modelu do pohledu a přikázat pohledu vykreslení dat. Každá akce by měla reagovat na jeden druh požadavku od uživatele. Presenter je třída, která dědí od Nette třídy presenter, může být abstrakt, pokud od ní někdo dědí nebo final. Její název je ve tvaru NazevPresenter, kde počáteční písmeno je velké, soubor se jmenuje také NazevPresenter.php a nachází se v adresáři app a jeho podadresáři presenters. b) Model Model je datovým a funkčním základem celé aplikace. Slouží k dolování dat z databáze a k jejich následnému předání presenteru, který o ně požádal.
20
Materiál a metodika zpracování
Kterákoli uživatelova akce představuje také akci modelu. Model si spravuje svůj vnitřní stav, který lze zjišťovat či měnit voláním funkcí rozhraní. c) Pohled (šablona) Pohled neboli šablona slouží k zobrazení dat uživateli. Každý pohled patří jedné akci jednoho presenteru, kde název pohledu je stejný jako název akce, ale s malým počátečním písmenem. Pohled se nachází v adresáři, jehož název je jméno příslušného presenteru a obsahuje informace o tom, co má ona akce vypsat na obrazovku prostřednictvím HTML. Nette Framework umožňuje dvoufázové renderování šablon. To znamená, že každá akce kromě šablony dané akce, má ještě jednu šablonu, v které se nacházejí části webové stránky, které se v akcích opakují, např. nadpis, logo. Těmto částem, společných pro určité akce i napříč presentery, se říká layout, který má na začátku názvu @. Příkaz {include nazev} vkládá do šablon jiné šablony, kde nazev je relativní nebo absolutní cesta k souboru, nebo je možné pomocí znaku # vkládat pojmenovaný blok. Šablony v Nette Frameworku mají příponu latte, což je šablonovací systém. 2.4.1
Makra v šablonách
Nette Framework umožňuje v šablonách psaní maker díky Latte Filtru. Mezi nejpoužívanější makra patří {block}, {link} – generuje odkaz na jiný presenter, {include} – vkládá buď soubor nebo blok, {extends} – nastavuje nadřazenou šablonu, pokud šablona nedědí od layoutu, {if} {else} {/if}, {foreach} {/foreach} – pro podmínky a iterace, {control} – pro vykreslení komponent a formulářů. Do šablon se předává proměnná z presenteru např. takto: $this->template->osoba=$osoba Proměnné lze vypisovat následovně {$osoba} s tím, že je lze formátovat a to pomocí tzv. helperů. Osobu naformátuje tak, že první písmeno ve slově bude velké, ostatní malá {$osoba|capitalize}. V okamžiku, kdy se proměnná vypíše, tak se automaticky escapuje. 2.4.2
Signály
Signály jsou metody presenteru, které něco mění, např. mazání, odeslání formuláře. Po provedení signálu je potřeba provést přesměrování, tzv. redirect, a to například na předchozí stránku. Zde se obvykle také využívá funkce flashMessage, která uživateli zobrazí libovolnou zprávu předanou v parametru funkce. 2.4.3
Formuláře
Formuláře se vytvářejí v presenteru tím, že uvnitř funkce definujeme pole formuláře, jejich pravidla a tlačítka. Název komponenty k vytvoření formuláře mu-
Materiál a metodika zpracování
21
sí být ve tvaru createComponentNazev, textové pole se vytváří pomocí $form->addText(), na které lze navázat pravidla addRule() nebo setRequired() a přidání tlačítka lze pomocí addSubmit(). Zde je ještě nutné navázat callback na událost při odeslání formuláře (to se samozřejmě stane, když jsou veškerá pravidla splněna) kde se zavolá funkce, která formulář zpracuje. Příklad formuláře. protected function createComponentOsobaForm(){ $form = new Form; $form->addText('jmeno', 'Jméno:') ->setRequired('Uveďte jméno.'); $form->addText('prijmeni', 'Přijmení:') ->setRule(Form::FILLED,'Uveďte přijmení.'); $form->addSubmit('save', 'Uložit') ->setAttribute('class','default'); $form->addSubmit('cancel', 'Storno') ->setValidationScope(NULL); $form->onSuccess[] = callback($this, 'osFormSubmitted'); return $form; }
2.4.4
Ladění a zpracování chyb
Pro ladění a zpracování chyb je uživateli v Nette Framewoku po ruce ladící nástroj Nette\Diagnostics\Debugger. Debugger se nastavuje v bootstrapu, aby byl k dispozici hned po startu aplikace. Zde je možné nastavit debugger na produkční nebo vývojový režim, pokud se tak nestane, tak se režim nastavuje automaticky podle IP adresy serveru. Ve vývojovém režimu je chyba, respektive výjimka, dostatečně zvýrazněna s informací, o kterou chybu se jedná, kde k ní došlo a je i možné si zobrazit detailnější podrobnosti o chybě. V produkčním režimu nic takového na uživatele nemůže „vyskočit“ a proto jsou veškeré zachycené výjimky zaznamenávány do textového logu, který může být poté e-mailem odeslán správci, který chyby opraví. 2.4.5
Autentizace a autorizace
Autentizace je proces ověření identity osoby přistupující k systému. Nejčastěji se toto děje při porovnávání hodnot atributů uživatelské jméno a heslo, kde se uživatelem vkládané hodnoty porovnají s těmi, které jsou v databázi. K těmto účelům slouží v Nette instance třídy Nette\Http\User user. K přihlášení uživatele do systému dojde pomocí metody login() následovně $user->($username, $password), kde parametry jsou uživatelské jméno a heslo uživatele. Uživatel přihlašující se do systému musí mít povolené cookies z důvodu bezpečnosti přihlášení. Dále lze využít metody isLoggedIn() pro zjištění, zda je uživatel přihlášen, logout() pro odhlášení,
22
Materiál a metodika zpracování
setExpriration() pro stanovení časového intervalu, po jehož uplynutí, dojde k odhlášení uživatele, nebo dojde k odhlášení při zavření prohlížeče. Autorizace nastává po úspěšném přihlášení uživatele a ověřuje jeho práva. Pro účely této práce bylo jako autorizační nástroj zvoleno statické ACL (Access Control List). ACL je tedy seznam oprávnění k přístupu k nějakému objektu. Tento seznam určí kdo má povolení k přístupu k onomu objektu a jaké operace může s objektem provádět. Systém ACL je založený na třech komponentách. Role – role, které může uživatel mít, jako správce, host, atd. Zdroj – objekt, prvek webu jako např. produkt, stránka, článek Privilegium – operace, kterou může zdroj vykonat (např. smazání, editace). Statické ACL znamená, že veškeré role, zdroje a privilegia jsou napsaná v PHP souboru. Role jsou uloženy v databázi. Oprávnění je možné dědit. například správce dědí veškerá práva hosta plus má nějaká další privilegia, lze tak vytvářet stromy oprávnění. 2.4.6
Routování
Routování je obousměrné překládání mezi URL a akcí presenteru. Obousměrné je tím, že z URL je možné odvodit akci presenteru a také je právě možné akci vygenerovat odpovídající URL. To znamená, že není potřeba do šablon zapisovat URL, ale jen se odkazovat na akci presenteru a framework zajistí vygenerování URL. Tvar URL pro konkrétní akci je možné vytvářet ve chvíli, kdy je aplikace hotová. Požadovaný tvar URL adres určuje router, který je definovaný v bootstrap.php. Objekt třídy Route má dva parametry, kde první parametr je maska cesty a druhý je výchozí akce presenteru, která je zapsaná jako řetězec nebo pole. Nette framework touto funkcí přispívá k optimalizaci nalezitelnosti na internetu tím, že zabraňuje existenci duplicitních URL, které vedou na stejný obsah. (Nette foundation, 2011c).
2.5 Highcharts Highcharts je knihovna, pomocí které je možné vytvářet interaktivní grafy pro webové stránky a webové aplikace. Tato knihovna byla vytvořena v JavaScriptu norskou společností Highsoft Solutions AS v roce 2009. Highcharts podporuje typy grafů jako koláčový, sloupcový, liniový, křivkový, bodový, plošný. Knihovna funguje ve všech dnešních webových prohlížečích, ve kterých je pro rendering grafiky použito SVG a u Internet Exploreru (od verze 6) je vykreslení grafiky pomocí VML. Výhodou knihovny je Open Source kód, což znamená, že uživatel si při jakémkoliv typu licence může zdrojový kód modifikovat, a tím si přizpůsobovat knihovnu podle svého. Nastavení Highcharts nevyžaduje žádné speciální programovací znalosti, neboť možnosti nastavení vycházejí ze struktury zápisu objektů JavaScriptu. Tedy zápis je pomocí sady klíčových slov a hodnot spojených dvojtečkami, oddě-
Materiál a metodika zpracování
23
lené středníky a seskupené mezi složenými závorkami. I poté, co je graf vytvořen, je možné přidávat, odebírat či modifikovat řady a body. Veškeré nastavení grafu může být nastaveno individuálně včetně otočení grafu, změny pozice grafu nebo stylu grafu. Graf je možné exportovat do PNG, JPG, PDF nebo SVG formátu, je možné i graf zoomovat nebo veškeré popisky, včetně popisků os či bodů lze rotovat pod jakýmkoliv úhlem (Highsoft, 2011).
2.6 Stanovení nákladů pro výpočet cen Analýza nákladů je pro podnik velice důležitá, neboť přímo ovlivňuje zisk společnosti, což je patrné ze vztahu Zisk = výnosy − náklady. Pokud jsou výnosy větší než náklady, vzniká zisk, pokud je tomu naopak, tedy, že náklady jsou větší než výnosy, vzniká ztráta. Co si vlastně pod tak důležitým pojmem jako jsou náklady, máme představit. Dle Pavlíkové (1998) jsou náklady: „Ekonomické zdroje vynaložené v jednotlivých aktivitách mají hodnotu, která je založena na množství peněz vynaložených na jejich zajištění. Jejich vynaložení v dané aktivitě je výsledkem volního rozhodnutí, v jehož důsledku jsou zdroje účelově obětovány za účelem jejich užitečného zužitkování.“ Pro sledování a výpočet nákladů je dobré si je rozdělit do skupin např. podle a) druhů nákladů a.1. náklady odpovídající vynaložené živé práci (mzdy), a.2. odpovídající spotřebě hmotných prostředků (spotřeba materiálu), a.3. odpovídající opotřebení investičního majetku (odpisy), a.4. odpovídající spotřebě a použití prací a služeb externích subjektů (dopravné), a.5. odpovídající bezprostřední peněžní úhradě (pojistné), b) vztahu ke sledovanému objektu b.1. náklady přímé – vztahují se na konkrétní výstup, b.2. náklady nepřímé – vztahují se na celkové kalkulované množství, c) závislosti na změně v objemu c.1. variabilní – rostou s vyšší výrobou, c.2. fixní – téměř nerostou s vyšší výrobou, podnik má náklady, i když nevyrábí. Dále pak je možné dělení i podle místa vzniku, vztahu k hlavní činnosti, dělení pro účely kalkulací. Součtem jednotlivých nákladů těchto skupin dostaneme celkové náklady, např. , kde Q je množství, jelikož se jedná o variabilní náklady. (Král, 1997)
24
Analýza současného stavu
3 Analýza současného stavu 3.1 Stručný popis nabízených služeb Pro bližší představu, jaké služby společnost v oblasti EMS svým zákazníkům nabízí, byl ve spolupráci s obchodním manažerem sestaven stručný popis nabízených služeb, který je uveden v příloze A.
3.2 Stávající způsob tvorby nabídek a kalkulace cen služeb 3.2.1
Proces zpracování nabídky
Stávající proces zpracování nabídky v ME lze nejlépe charakterizovat prostřednictvím diagramu, který je uveden i s popisem v příloze B. 3.2.2
Kalkulace ceny materiálu
Kalkulace prodejní ceny materiálu je postavena především na zjištění nákupních cen komponent, které jsou ze strany zákazníka předány ve formě materiálové rozpisky (BOM – bill of material). Velice často se stává, že získané podklady jsou předány ve formě excelovských tabulek či CSV souborů (jako nejběžnější exportní formát návrhových systémů). Používané názvosloví se velice liší a je třeba obvykle z polí názvu a hodnot specifikovat použitou komponentu tak, jak je zavedena v ERP systému společnosti (K2). Tato činnost je obvykle nejpracnější a znamená ruční prohledávání číselníku materiálových položek v systému a následné přiřazení jednoznačného identifikačního čísla položce v BOMu. Pokud takováto položka v systému dosud neexistuje, je obvykle referentem nákupu (RN) do systému založena (obzvláště tehdy, pokud je velká pravděpodobnost, že se bude daná nabídka následně realizovat – zejména v případě stávajících zákazníků). Následně pro zadané očekávané množství (spotřebu) se ze systému zvolí cena, pakliže její poslední zjištěná hodnota je aktualizovaná. V případě nových, nebo dosud neoceněných položek zjišťuje nákup jejich ceny u schválených dodavatelů (nebo požadovaných od zákazníka) a to pro dané množství, zároveň ověřuje dostupnost komponenty (dodací lhůty, zda není v alokaci apod.) – všechny tyto údaje zadává RN do ERP systému a do výstupní excelovské tabulky určené pro zpracovatele nabídky (OM). V případě DPS poptá dodavatele na základě předaných elektronických dat exportovaných z návrhového systému, tzv. Gerber formát dat (Gerber format, 2004). OM následně ocení materiál prodejní cenou zakalkulováním zásobovací režie (přirážka k nákupní ceně) a zohledněním kurzového rizika mezi nákupní cenou (často v cizí měně: EUR, USD, JPY) a prodejní cenou (obvykle v CZK nebo EUR či USD). Výslednou kalkulaci materiálových nákladů ukládá OM do adresářové struktury na sdíleném úložišti na firemním serveru.
Analýza současného stavu
3.2.3
25
Kalkulace ceny prací
Dříve, než je možné započít kalkulovat cenu práce – tedy náklady na ruční a strojní výrobu osazené DPS je potřeba na základě předané technické dokumentace od zákazníka stanovit předběžný technologický postup výroby. Jedná se tedy o stanovení sledu výrobních operací dle obecných zvyklostí, požadavků zákazníků a norem (IPC) v návaznosti na technologické možnosti a vybavenost. Výběr těchto operací a stanovení časů potřebných na jejich provedení je v kompetenci oddělení technologické přípravy výroby, technologů (RT). V případě stanovení výrobních časů na SMT linkách, technologii pájení vlnou či ručních operací slouží OM (či RT) „kalkulátor“ spotřeby času v podobě jednoduché excelovské aplikace. Tato aplikace byla vytvořena cca před pěti lety a postupně byla upravována do podoby, která je cca 2 roky zakonzervovaná. V další části analýzy je podrobněji rozebrán tento kalkulační nástroj zejména z pohledu sbíraných dat a možností práce s nimi. 3.2.4
Kalkulační nástroj ceny prací
Aplikace, která je napsána v Excelu slouží pro výpočet cen, uchovává data v externím souboru Databaze.xls s pevnou datovou strukturou, každý řádek v databázi představuje jeden oceněný produkt – identifikační údaje nabídky (číslo, zákazník apod.) se opakují tolikrát, kolik je v nabídce oceněno produktů. Všechny údaje v této pevné datové struktuře tak, jak budou popsány v následujícím textu, jsou v tomto řádku databáze uloženy. Z databáze je možno nabídku načíst (vždy jeden produkt) do vstupního formuláře, provést zde změny a tyto následně přepsat namísto původních hodnot. Nabídku lze vytisknou prostřednictvím výstupního formuláře (jsou nadefinovány 3 varianty výstupu, přičemž se aktuálně používá jen jedna – často se jen vypočtené hodnoty ručně kopírují do obchodního dopisu či mailové zprávy). V příloze C je detailně popsána podoba jednotlivých částí této aplikace. Ostatní technologie, které byly v průběhu posledních let pořízeny či byly dodatečně zákazníky požadovány, se počítají separátně a k výsledné ceně se připočítávají. Jedná se zejména o automatickou linku selektivního pájení vývodových komponent, vnitroobvodový test ICT, práce na automatizovaném opravárenském pracovišti pro BGA komponenty, některé další specifické práce a služby, dále výstupní logistika, balení apod. 3.2.5
Zhodnocení stávajícího způsobu kalkulace cen
Stávající způsob tvorby cen EMS služeb, který je stále používán má z pohledu aktuálních potřeb společnosti řadu nevýhod, které vedly k potřebě navrhnout a realizovat nový nástroj nejen pro kalkulaci ceny, ale i pro správu nabídek. Tento systém má však díky použité technologii (MS Excel) i jisté přednosti, které je potřeba vzít v potaz při návrhu nového řešení. Následující tabulka shrnuje klady
26
Analýza současného stavu
a nedostatky tohoto způsobu cenotvorby na základě výše uvedeného popisu i na základě konzultací s pracovníky firmy. Tab. 1
Klady a nedostatky stávající aplikace
Klady vstupní i výstupní data na jednom místě (listu) rychlé změny – okamžitá odezva na výsledek snadná simulace dopadu na změnu vstupních hodnot snadná definice výstupního formuláře – snadné formátování všechna data kdykoli k dispozici (mobilní data) snadná kalkulace spotřeby času SMT linek pro pracovníky TPV Nedostatky obtížné sdílení dat s jinými odděleními/uživateli (nákup, TPV) nezabezpečená data – bezpečnostní riziko např. při odcizení NTB (velmi citlivá data pro konkurenci) uzavřený systém – nemožnost doplnit ocenění nových služeb / technologií separátní výpočty nových služeb/technologií a hlavně materiálových nákladů (BOM v oddělených souborech kdesi ve filesystému) nemožnost dalšího rozvoje (spoluautor již ve firmě nepracuje, špatná čitelnost kódu maker) žádné workflow nabídky snadnost tvorby chyb ve výpočtech nemožnost analyzovat strukturu nákladů a dopad výše režijních sazeb na výslednou cenu (režie jsou „rozpuštěny“ v hodinových sazbách prací) minimální parametrizovatelnost sazeb – obtížně zjistitelná historie omezená kapacita databáze (sloupce/řádky), obtížné prohledávání (data na různých místech – databáze.xls, „servis list“ aplikace) nulová provázanost se stávajícím ERP systémem při oceňování materiálových položek
3.3 Neformální a formální specifikace 3.3.1
Neformální specifikace
Neformální specifikace představuje zadání této práce a je rovněž popsána v kapitole 1.2 Cíl práce. Předchozí kapitola analyzovala stávající systém práce s nabídkami a závěrečné shrnutí výhod a nevýhod stávajícího systému ukazují na základní vlastnosti, které by měl nový systém splňovat. Jsou to zejména tyto důvody, proč se společnost rozhodla, že je potřeba zavést nový nabídkový systém: bezpečnost dat s možností přístupu „zvenčí“ (zabezpečeným kanálem VPN), rozšiřitelnost pro nové služby a výrobní technologie,
Analýza současného stavu
27
sdílení práce/dat s dotčenými odděleními, sledování stavu nabídek (rozpracovanost, akceptace/odmítnutí), přístup ke stávajícímu ERP systému při oceňování materiálu, snadná analýza nákladů a podmínek, ze kterých byly ceny vypočteny. 3.3.2
Formální specifikace
Funkční požadavky Evidence nabídek o Evidence režijních a hodinových sazeb pro výpočet nákladů a cen; o Evidence kurzů; o Export nabídky do PDF. Evidence produktů o Výpočet nákladů a cen. Evidence zákazníků o Evidence osob zastupujících zákazníky. Evidence operací o Stanovení ceny práce. Rozpiska materiálu o Ocenění rozpisky materiálu; o Import *.csv souboru s variabilním množstvím sloupců; o Propojení s ERP systémem. Kooperace oddělení o Vymezení přístupových práv uživatelů podle oddělení. Nefunkční požadavky Požadavky na HW: o Databázový server; o Pracovní stanice; o Síťová přístupnost; o Internetová přístupnost. Požadavky na SW: o Operační systém Windows pro server i stanice; o Apache http server; o PHP verze 5.3; o MS SQL Server 2008. Požadavky na systém: o Webová aplikace běžící na vlastním hostitelském serveru; o Implementováno v PHP; o Webová aplikace použitelná v běžně dostupném prohlížeči; o Modulární členění; o Jednoduchá použitelnost.
28
Návrhová část
4 Návrhová část 4.1 Funkční model Systém pro evidenci nabídek a zpracování kalkulací cen EMS služeb byl navržen prostřednictvím modelovacího nástroje PowerDesigner ProcessAnalyst od Sybase, Inc. 4.1.1
Kontextový diagram
ERP EKONOM ICKY UTVAR
VYROBA CENA MATERIALU UDAJE O VYROBNICH TECHNOLOGIICH
REZIJNI PARAMETRY A KALKULACNI ZASADY SAZBY PRACOVNICH TRID
1 SYSTEM NABIDEK
+
POZADAVEK NA ZPRACOVANI NABIDKY INFORM ACE O ODBERATELI ODBERATELE
PERSONALISTIKA NABIDKA
Obr. 1
Kontextový diagram
V tomto diagramu je zobrazen celý systém jako jediný proces a jeho okolí, s kterým systém komunikuje. Terminátor Ekonomický útvar poskytuje režijní parametry a kalkulační zásady potřebné pro kalkulaci nákladů a cen produktů, ERP systém poskytuje ceny materiálu potřebné k ocenění materiálového rozpadu produktu, Výroba poskytuje údaje o výrobních technologiích potřebných k vytvoření příslušných operací, Personalistika poskytuje sazby platových tříd pro výpočet nákladů týkajících se osobních nákladů výrobních operací a Odběratel (zákazník) zasílá požadavek na zpracování nabídky, přijímá odeslanou nabídku a vyjadřuje se k ní.
Návrhová část
4.1.2
29
Systémový diagram 1.5 [SAZBY PRACOVNICH TRID]
TPV
PERSONALISTIKA
[UDAJE O VYROBNICH TECHNOLOGIICH]
+ OPERACE
VYROBA
PRODUKT ERP
1.2 [CENA MATERIALU]
EVIDENCE PRODUKTU
PRODUKTY PRODUKTY
+
EKONOM ICKY UTVAR
MATERIALOVA SKLADBA PRODUKTU NAKLADY PRODUKTU
[REZIJNI PARAM ETRY A KALKULACNI ZASADY] ODBERATELE [NABIDKA]
1.1 ODBERATELE
[POZADAVEK NA ZPRACOVANI NABIDKY]
EVIDENCE NABIDEK
ODBERATELE ODBERATELE
NABIDKY NABIDKY [INFORMACE O ODBERATELI] ODBERATELE
Obr. 2
+
ODBERATELE 1.3
EVIDENCE ODBERATELU
Systémový diagram
Společně se zaslaným požadavkem na zpracování nabídky od odběratele získá firma také informace o odběrateli. V případě, že zákazník není v databázi, založí obchodní manažer veškeré potřebné údaje o zákazníkovi. Tímto lze popsat proces Evidence odběratelů a datový sklad odběratelé. Nacházejí se zde také procesy Evidence nabídek, Evidence produktu a TPV, tyto procesy jsou detailněji popsány dále.
30
Návrhová část
4.1.3
Evidence nabídek
ODBERATELE
EVIDENCE PRODUKTU [MATERIALOVA SKLADBA PRODUKTU] NABIDKY
[POZADAVEK NA ZPRACOVANI NABIDKY]
ODBERATELE
NABIDKA 1.1.2
[NABIDKY]
ZPRACOVANI NABIDEK
[NABIDKA] ODBERATELE
[ODBERATELE] UDAJE O PRODUKTU NABIDKY
CENY CENY
1.1.1 [NAKLADY PRODUKTU]
KALKULACE CENY
CENY
EVIDENCE PRODUKTU KALKULACNI PARAMETRY
EKONOM ICKY UTVAR SAZBY REZII
KALKULACNI PARAMETRY
Obr. 3
1.1.3 SPRAVA KALKULACI [REZIJNI PARAM ETRY A KALKULACNI ZASADY]
DFD evidence nabídek
Obchodní manažer (OM) obdrží od zákazníka požadavek na zpracování nabídky na výrobu osazené desky plošných spojů (DPS). Součástí podkladů od zákazníka je materiálová rozpiska (kusovník nebo také BOM – bill of material) – zde je uvedeno označení komponenty (elektronická součástka) její počet na desce (spotřeba na 1 kus DPS) Tyto údaje musí být dostatečné pro konkretizaci položky a ocenění materiálových nákladů. Materiálová rozpiska je poslána do procesu Evidence produktu k výpočtu nákladů produktu. OM založí nabídku do systému (datový sklad nabídky) – vyplní její popis do poznámky, datum přijetí poptávky, požadované datum zpracování nabídky a dále do poznámky např. uloží kopii emailové poptávky. Po vypočtení nákladů (viz proces Evidence produktu) je možné provést výpočet cen. OM si zvolí příslušnou sadu kalkulačních sazeb (aktuálně platnou nebo ji zaktualizuje) tzn., že nastaví výši výrobní režie, správní režie, materiálové přirážky (zásobovací režie), míru zisku a přirážky k jednorázovým a ostatním nákladům, které jsou v datovém skladu kalkulační parametry. Pomocí těchto sazeb se následně spočítají jednotlivé části výsledné prodejní ceny produktu, tj. jednotlivé typy cen, které se nacházejí v datovém skladu ceny (cena přímého materiálu, cena ručních prací, cena strojních prací, cena ostatních služeb, správní režie, zisk, prodejní cena produktu a prodejní cena jednorázových nákladů). Pokud je prodejní cena požadovaná v cizí měně, použije se pro výpočet
Návrhová část
31
prodejní kurz příslušné měny z aktuálního kurzovního lístku. Nabídku ve formě výstupní sestavy (PDF) odešle OM po jejím schválení zákazníkovi. 4.1.4
Evidence produktu POZADOVANY MATERIAL 1.2.1 ERP OCENENI MATERIALU [CENA MATERIALU]
MATERIAL
MATERIAL POZADAVEK NA OCENENI
[OPERACE]
TPV [PRODUKT]
1.2.3 TPV MATERIAL
MATERIAL
SKLADBA PRODUKTU
[PRODUKTY] PRODUKTY
[NAKLADY PRODUKTU]
Obr. 4
EVIDENCE NABIDEK
DFD evidence produktu
PRODUKTY
[MATERIALOVA SKLADBA PRODUKTU]
EVIDENCE NABIDEK
Zde nejdříve OM k nabídce založí poptávaný produkt (datový sklad produkty) a k příslušnému produktu zadá (ručně nebo importem z excelovského souboru *.csv) materiálový kusovník – rozpisku (BOM). Po naimportování materiálového kusovníku, může dojít k přiřazení těchto položek s položkami v ERP systému a jejich ocenění materiálu (dle předpokládaného vyráběného množství). Pracovník nákupu si zobrazí seznam produktů, které je potřeba ocenit a zvolí si produkt, pro který bude oceňovat materiálový kusovník. Pracovníkovi nákupu se zobrazí seznam materiálových položek vybraného produktu a pro každou položku požadované množství pro výrobní dávku popř. roční spotřeba položky (toto množství je rozhodující pro cenu). Položky, které nejsou přiřazeny položkám z ERP, jsou podle názvu položky dohledány v ERP systému K2 (musí být zabezpečeny práva přístupu k specifikovaným pohledům na ERP data), přiřadí jim toto číslo a po přiřazení vybere z ERP systému odpovídající cenu, měnu ceny (poslední aktualizovanou pro dané množství), popř. ji zjistí u svého dodavatele. Oceněný materiál je následně uložen v datovém skladu materiál. Produkt, který má dokončeno ocenění materiálu a dokončené TPV (viz proces TPV), je možné ocenit. OM provede výpočet nákladů – pro jednotlivé nákladové typy, kde pro každý produkt budou spočteny následující typy nákladů – materiálové náklady, náklady na operace – odděleně ruční a strojní a to náklady na jeden kus a náklady na výrobní dávku (viz časy tP), náklady ostatní (doprava, balení) a náklady jednorázové (přípravky, programování strojů apod.). Pro oceněné materiálové položky v cizích měnách si musí OM nastavit správný kurzovní lístek – nákupní kurzy použitých cizích měn (zde nákupní kurzy znamenají obvykle vyšší sazbu za cizí menu při nákupu komponent, např. kurzy pro stanovení
32
Návrhová část
nákupních cen jsou o 10 % vyšší než kurzy pro stanovení prodejních cen – tím je částečně eliminováno kurzové riziko). 4.1.5
TPV VYROBA
[UDAJE O VYROBNICH TECHNOLOGIICH]
PERSONALISTIKA
1.5.1 SPRAVA TYPOVYCH OPERACI
[SAZBY PRACOVNICH TRID] TYPOVE OPERACE
OPERACE PRODUKTU
1.5.2 OPERACE TVORBA OPERACI OPERACE PRODUKTU
TYPOVE OPERACE
TYPOVE OPERACE
[PRODUKT] [OPERACE]
Obr. 5
DFD modulu TPV EVIDENCE PRODUKTU
EVIDENCE PRODUKTU
Nezávisle na dokončeném ocenění materiálových položek může pracovník technologie (TPV) tvořit seznam operací (rámcový technologický postup), které budou pro výrobu daného produktu potřebné (datový sklad operace produktu). Ke každému produktu u operace zadá předpokládaný čas v minutách pro přípravu operace (tP čas) a vlastní čas operace na 1 kus (tA čas). Vychází přitom z typového číselníku operací, který udržuje oddělení TPV (např. ruční operace: osazování, ruční pájení, montáž, oživování, testování, kontrola; nebo strojní operace: osazování na SMT lince, AOI (automatická optická inspekce) – kontrola kvality, selektivní pájení na lince, pájení vlnou, vnitroobvodový test ICT; ostatní operace: balení, doprava; jednorázové: jednoúčelové přípravky, sítotiskové šablony, programování strojů). Ruční, strojní, ostatní i jednorázové operace jsou považovány za jednotlivé druhy typových operací. Jednotlivé typové operace mají stanovenou aktuálně platnou sazbu za jednu minutu. U jednorázových operací není zadáván čas, ale je zadáván přímo náklad. Sazby jednotkových nákladů typových operací jsou obvykle platné 1 rok, avšak můžou být pro ocenění produktu u konkrétní nabídky jiné. Je potřeba, aby bylo zpětně dohledatelné, jaké sazby typových operací byly použity pro ocenění produktu příslušné nabídky.
4.2 Datový model Datový model představuje ERD diagram. Datový model byl pro lepší pochopení rozdělen do několika logických částí a pro zjednodušení byly vynechány některé číselníky a atributy tabulek (ERD je v příloze D). Jak je dále uvedeno v odstavci 4.4.1, je celá aplikace rozdělena do čtyř modulů, přičemž část ERD kontakty a obchod je soustředěna v modulu obchod, část uživatelé je součástí modulu správa a ostatní dvě části odpovídají názvům zbývajících dvou modulů aplikace, tedy nákup a TPV.
Návrhová část
33
4.3 Použitá technologie Pro implementaci nově navrženého systému pro zpracování nabídek byly zvolené technologie dle požadavku zadání a rozboru problematiky v teoretické části této práce. Vývoj aplikace probíhal v prostředí webového serveru Apache ver. 2.2.21, který byl nainstalován pomocí instalačního balíku XAMPP for Windows jehož součástí je podpora skriptovacího jazyk PHP (zde ve verzi 5.3.8). K samotné tvorbě PHP kódu webové aplikace byl využit framework Nette ve verzi 2.0 Beta. Jako databáze byl použit Microsoft SQL Server v bezplatné edici Express 2008 R2. Použití technologie SQL Server bylo zvoleno také proto, že ve společnosti je tato platforma hojně využívána jak u ERP systému K2, tak i při vývoji vlastních aplikací v rámci hlavního předmětu podnikání. Jako databázová vrstva, která je velmi dobře podporována Nette byla použita knihovna Dibi ver. 1.5rc. Vývojové prostředí (IDE), které bylo použito je velmi oblíbený nástroj Netbeans (Netbeans.org, 2011) ve verzi 7.0.1, který byl doplněn o podporu Nette a phpDoc (dokumentování kódu).
4.4 Struktura aplikace Detailní popis implementace celé aplikace vytvořené ve skriptovacím jazyce PHP za pomocí frameworku Nette by znamenal rozsah, který by jistě překročil rámec této práce. Proto se v další části této kapitoly zaměříme jednak na strukturu celé aplikace a její rozdělení do modulů, podrobněji bude popsána otázka implementace přístupových práv a tam, kde to bude účelné, bude detailněji vysvětlen způsob, jakým byl konkrétní problém řešen. 4.4.1
Rozdělení aplikace do modulů
Tak jak bylo v kapitole 4.2 uvedeno, je vhodné rozdělit celou aplikaci do několika modulů, které jsou relativně na sobě nezávislé, avšak mají mezi sebou jednoznačně popsané interakce. FW Nette práci s takovými moduly podporuje. Aplikace je rozdělena v souladu s dříve provedeným návrhem do těchto modulů: Obchod – hlavní modul aplikace – obsahuje všechny důležité činnosti OM. Odtud je proces nové nabídky spuštěn a po celou dobu jejího „života“ je řízen. Zde dochází k založení nabídky a produktů, dále jsou zde spravováni zákazníci a kontaktní osoby, kurzy měn a sazby režií (potřebné pro výpočet cen produktů) a sety těchto režijních sazeb (dle období platnosti). TPV – zde probíhá sestavení technologického postupu výroby produktu zadáním potřebných operací podle předpřipravených typových operací. Dále jsou zde spravovány sazby typových operací a sety těchto sazeb (dle platnosti v zadaném období). Nákup – hlavní úlohou tohoto modulu je získání seznamu materiálových položek a jejich následné ocenění. Seznam položek je do databáze nejčastěji
34
Návrhová část
importován ze zákazníkem dodaného materiálového rozpadu produktu (tzv. BOM obvykle ve formátu MS Excel), který je po kontrole s dodanou dokumentací převeden do CSV souboru. Ocenění těchto položek probíhá přímým dotazem do ERP systému, kde je položka vyhledávána dle svých atributů a po její identifikaci s položkami v ERP je oceněna. Správa – v tomto modulu jsou spravováni uživatelé systému (jsou jim přidělovány role v systému), dále některé společné číselníky (státy, kraje, obce a další). Base – výchozí (základní) modul – obsahuje z pohledu využití Nette technologie důležité společné předky tříd presenterů (BasePresenter – rodič presenter, obsahuje společné metody využitelné v potomcích této třídy, SecuredPresenter – rodič presenterů v neveřejné části aplikace – ověřuje mj. přístupová práva), dále presentery Homepage (domácí stránka aplikace), Error (chybové stránky), Sign (přihlášení uživatele do aplikace), předka modelu (základní model – obsahuje metody využitelné v ostatních děděných třídách tohoto modelu) a model User (zjištění vlastností přihlášeného uživatele). 4.4.2
Sandbox aplikace
V terminologii Nette frameworku tento výraz v podstatě znamená adresářovou strukturu projektu aplikace, ve které jsou k dispozici některé základní soubory obsahující např. definice tříd některých presenterů (Base, Homepage, Error, Sign), základního modelu, zaváděcí skripty index.php a bootstrap.php, konfigurační soubor a další. Tento „prázdný projekt“ sandbox (někdy též „skeleton“) je použit před zahájením vlastní práce na vývoji aplikace (NEON sandbox, 2011). Adresářová struktura aplikace (sandbox) je uvedena v příloze E.
4.5 Konfigurace a spuštění aplikace Statická konfigurace aplikace je zajištěna prostřednictvím konfiguračního souboru config.neon umístěném ve složce app/, který mj. obsahuje tyto konfigurační parametry: nastavení časové zóny PHP serveru (php), sestavení připojení k databázi aplikace i k databázi ERP systému (database, k2), název a adresu uživatele aplikace (pro výstupní sestavy) či jiné „vlastní“ parametry (company, myvar), identifikaci tříd (služeb) pro autentikaci a autorizaci (tzv. továrny – services), expirační dobu pro session (services:session).
Návrhová část
35
Při zápisu parametrů do souboru config.neon je nutné striktně dodržovat hierarchii (jako by byly staticky definovány pole proměnných v různých úrovních vnoření). Při zápisu hierarchicky uspořádaných parametrů je nutné jako oddělovač úrovní používat buď tabulátor (doporučeno), nebo mezery – nikdy ne jejich kombinaci. Při spuštění aplikace se nejprve z veřejného adresáře www/ spustí soubor index.php (ten prakticky obsahuje jen definice k systémovým složkám (app, _Libs, upload, log) a spouští ze složky app/ zavaděč bootstrap. require $params['appDir'] . '/bootstrap.php';
Ten nejprve načtou potřebné knihovny Nette Framework a Dibi layer, potom se aktivuje debugger a logování a následně se vytvoří Dependency injection kontext načtením konfiguračního souboru config.neon do systémového kontejneru: // Load libraries
V další fázi bootstrap nastavuje základní routování (překlad URL do srozumitelnější podoby). V případě, že není serverem podporován mod_rewrite je použit tzv. SimpleRouter: if (function_exists('apache_get_modules') && in_array('mod_rewrite',apache_get_modules())) { $container->router = new RouteList; $container->router[] = new Route('index.php', 'Homepage:default', Route::ONE_WAY); $container->router[] = new route('<presenter>/ [/]','Homepage:default'); } else { $container->router = new SimpleRouter('Homepage:default'); }
36
Návrhová část
Následuje připojení k databázi aplikace prostřednictvím Dibi a spuštění vlastní aplikace: dibi::connect($container->params['database']); $container->application->run();
4.6 Base Presenter a Model BasePresenter – (pra)rodič všech presenterů v rámci architektury MVC, které zajišťují zpracování požadavků uživatele. Prostřednictvím modelu získávají data, které ve vrstvě view pomocí šablon uživateli zobrazují. BasePresenter této aplikace soustřeďuje společné funkce, které mohou jeho potomci dědit. Jsou to následující nejdůležitější metody: metoda startup – načtení údajů o aktuálně přihlášeném uživateli, obsah systémového kontejneru context, hlavní menu aplikace – továrna createComponentNavigation z pole menu aktivního modulu vytvoří pás hlavní nabídky (viz Obr. 6), metody pro práci s nastavením aktuálních hodnot komponenty „MySetting“, což představuje stále přístupnou informaci uživatele o rozpracovanosti či poslední návštěvě konkrétního produktu v rámci nabídky, ve které je obsažen pro příslušného zákazníka (aktuální kontaktní osobu) – tyto hodnoty se ukládají v rámci relace (v datovém úložišti session na straně serveru); hodnoty MySetting se pokud je to možné, aktualizují automaticky při volbě jakékoli položky ze čtveřice sledovaných parametrů (Firma– Osoba–Nabídka–Produkt) – náhled je zřejmý viz Obr. 6.
Obr. 6
Základní ovládací prvky aplikace
Model je rodičovská třída všech modelů aplikace. Ve svém konstruktoru vrací veřejnou proměnnou $connection = dibi::getConnection() pro zajištění přístupu ostatních modelů k databázi aplikace.
Návrhová část
37
Ve třídě Model je soustředěna celá řada metod pro přístup k datům, které jsou pro děděné modely a jejich presentery potřebné (budou tedy přístupné v rámci instance aktuálního modelu), jsou to zejména: továrna na autentikační službu – vrací objekt Authenticator naplněný seznamem uživatelů pro následné ověření přihlašujícího se uživatele, metody pro naplnění číselníků ve vstupních formulářích (Nette prvek addSelect vytvářející select box, čili html tag <select>), metody pro insert a update pro různé tabulky databáze používané u kombinovaných formulářů, formátovací funkce pro ukládání datových typů date a float z formulářů do databáze, historie stavů nabídek/produktů, aktuální sazby kurzů, sazeb režií, údaje o nákladech, cenách a mnoho dalších.
4.7 Zajištění přístupu a ACL Přihlášení uživatele se odehrává prostřednictvím SignPresenteru, který obsahuje továrnu na komponentu přihlašovacího formuláře SignInForm. Ověření platnosti uživatelského jména a hesla zajišťuje autentikační služba, která je spuštěna v Modelu po spuštění aplikace. Důležitou roli při ověřování oprávnění přístupu sehrává SecuredPresenter. Tento presenter je potomkem BasePresenteru a rodičovskou třídou ostatních presenterů v neveřejné části webové aplikace (tj. všech modulů vyjma Homepage v Base modulu). Jeho hlavní úlohou je zajistit kontrolu přístupových práv v implementovaném statickém ACL (access control list). V metodě startup je ověřováno, zda je uživatel přihlášen a pokud ne volí se akce in v SignPresenteru: if (!$this->user->isLoggedIn()) { $backlink = $this->getApplication()->storeRequest(); $this->redirect('Sign:in',array('backlink'=>$backlink)); }
Dále je v každém presenteru, po požadavku na akci uživatele ověřováno, zda má aktivní uživatel právo přístupu ke zvolené akci či nikoli. Princip logiky této kontroly je zhruba tento: public function startup(){ if (!$this->getUser()->isAllowed($this->name, $this->action)){ $this->flashMessage('Nemáte dostatečná oprávnění!'); return false; } return true; }
38
Návrhová část
Ve třídě Nette\Http\User je volána metoda isAllowed, které se předá název aktuálního presenteru a zvolené akce a ta v objektu Nette\Security\Permission ověří, zda uživatel má právo přístupu. Objekt byl při startu aplikace naplněn ve třídě AuthorizatorFactory ze statického pole zdroje (seznam všech dostupných presenterů a akcí, ke kterým mají mít příslušné role přístup). Pole zdroje je staticky zapsáno v metodě create třídy Authorizatorfaktory následovně: use Nette\Security\Permission; class AuthorizatorFactory extends Nette\Object{ public function create(){ $permission = new Permission; $zdroje = array('Homepage'=> array('Homepage'=>array('default'), 'Sign'=>array('in'),), 'Obchod'=>array('Obchod'=>array('default','dash'), 'Firma'=>array('default','detail', 'add','edit',...), ... 'Nakup'=>array('Nakup'=> array('default','material'), 'Firma'=>array('default','detail'), 'Material'=>array('default','add', 'edit',...), ...
Princip zápisu tohoto pole statického ACL spočívá v tom, že nejvyšší úroveň Homepage, Obchod, Nakup,… představují moduly aplikace, v nižší úrovni jsou názvy presenterů a v nejnižší úrovni jsou pole s názvy akcí (actionXxx, renderXxx), které by měly být v rámci modulu přístupné. Následně jsou v metodě create definovány role (ty jsou ve správě uživatelů – modul Sprava/Uzivatel – přiřazeny každému uživateli; názvy rolí odpovídají názvům modulů – vyjma role quest, a Admin) pomocí metody addRole ve třídě Nette\Security\Permission. Metoda setResources z pole zdroje vytvoří rovněž v této třídě kolekci objektů Resources takto: if(!$this->permission->hasResource($presenter.':'.$action)){ $this->permission->addResource($presenter .':'. $action); }
Nyní již zbývá v ACL jen nastavení práv pro jednotlivé zdroje. To zajišťuje v naší třídě AuthorizatorFactory metoda setPrivileges, která podle struktury pole zdroje nastavuje oprávnění přístupu následovně: $this->permission->allow($role, $presenter, $action); $this->permission->allow($role, $presenter .':'. $action,
Návrhová část
39
Permission::ALL);
Druhý řádek slouží v případě, že je volána akce z jiného presenteru odkazem v šabloně např.: id">Vybrat produkt
Tímto je zajištěno, že uživatel má nastavena oprávnění jen k těm presenterům a akcím, které jsou v seznamu pro jeho roli v poli zdroje. Klikne-li na odkaz, kam nemá oprávnění nebo se pokusí zadáním url dostat do míst bez práv, vypíše se chybové hlášení „Nemáte dostatečná oprávnění“. Globální přístup pro administrátora systému je řešen v Nette velmi elegantně takto: $this->permission->allow('Admin', Permission::ALL, Permission::ALL);
Tzn. uživatel s rolí Admin má právo ke všem presenterům aplikace a ke všem jejich akcím. Toto by ovšem nestačilo – jistě nevypadá pěkně, když uživatel vidí odkazy na akce, ke kterým nemá přístup. Nette prozatím tuto záležitost neřeší i když se poměrně dlouze diskutuje o latte makru Link, které by zajistilo vykreslování odkazů v šabloně pouze, pokud má uživatel právo akci použít. Tento problém byl v šabloně řešen tedy následujícím způsobem pomocí latte makra n:if: isAllowed('Produkt','delete')" n:href="delete, $prod->id">Odstranit
