Internetové portálové aplikace a jejich využití v praxi

Bankovní institut vysoká škola Praha Katedra informačních technologií

Internetové portálové aplikace a jejich využití v praxi Bakalářská práce

Autor:

Michal Hrbáč Studijní obor bankovnictví, specializace správce IS

Vedoucí práce:

Michal Hrbáč

Doc.Ing.Stanislav Horný,CSc

Březen 2009

Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury.

V Praze, 30.3.2009

Michal Hrbáč

Poděkování: Chtěl bych tímto poděkovat vedoucímu práce Doc.Ing.Stanislav Hornému,CSc za konzultace, vstřícnost a cenné rady, které vedly k úspěšnému dokončení této bakalářské práce.

Anotace:

Hlavním cílem této práce je na konkrétním příkladu z praxe ukázat, jaké jsou některé z možností, jak využít portálové aplikace v prostředí podniku. Většina této práce je zaměřena na popis provozního informačního systému, který je využíván jednou soukromou firmou. V závěru je poté zhodnocen přínos nasazení této aplikace a také již plánované možnosti rozšíření funkcionality.

Annotation:

The main goal of this work is to show the possibilities of using internet portal applications in a company. Most of this work is focused on describing an information system used by a private company. The last part evaluates the benefits of employing this application and also the planned options of its extended features.

Obsah 1. Analýza problematiky a historie internetových aplikací............................................................. 9 1.1. Co je Internet?...................................................................................................................................... 9 1.2. Historie internetu ................................................................................................................................. 9 1.3. Co je to internetová aplikace.............................................................................................................. 10 Co je to portál.................................................................................................................................................... 11 2. Typy portálových aplikací ............................................................................................................ 12 2.1. B2E – Business to employee – portál pro zaměstnance ..................................................................... 12 2.2. B2B – Business to business – portál pro obchodní partnery .............................................................. 12 2.3. B2C – Business to customers – portál pro zákazníky ........................................................................ 13 3. Možnosti portálových aplikací..................................................................................................... 14 3.1. Úvod do problematiky aplikace ......................................................................................................... 14 4. Shrnutí a obsah technické specifikace....................................................................................... 16 5. Seznam pojmů a zkratek .............................................................................................................. 17 6. Požadavky na Portál Provozního Systému ................................................................................ 18 6.1. Základní požadavky ........................................................................................................................... 18 6.2. Spolupráce s dalšími firmami............................................................................................................. 19 6.3. Technologické požadavky.................................................................................................................. 19 7. Základní pojmy .............................................................................................................................. 20 7.1. Hierarchie zakázek v Heliosu............................................................................................................. 20 7.2. Organizační struktura......................................................................................................................... 20 7.3. Odlišnosti práce jednotlivých divizí................................................................................................... 21 8. Návrh technického řešení ............................................................................................................ 22 8.1. Databázová vrstva .............................................................................................................................. 22 8.1.1. Primární klíče ................................................................................................................................ 23 8.1.2. Práce s UNICODE znakovou sadou.............................................................................................. 23 8.1.3. Vedení historie záznamů ............................................................................................................... 23 8.2. Vrstva aplikačního serveru................................................................................................................. 23 8.3. Vrstva webového prohlížeče .............................................................................................................. 24 8.3.1. Design oken................................................................................................................................... 24 8.3.2. Navigace mezi okny ...................................................................................................................... 24 8.3.3. Kontroly dat ve formulářích .......................................................................................................... 25 8.3.4. Odlišnost pro prohlížeč Mozilla Firefox ....................................................................................... 25 9. Zabezpečení přístupu k datům .................................................................................................... 26 9.1. Uživatelské role ................................................................................................................................. 26 9.2. Přístup k zakázkám ............................................................................................................................ 26 9.3. Přístup uživatele k zaměstnancům ..................................................................................................... 27 9.4. Zapůjčování zaměstnanců .................................................................................................................. 27 10. Zaměstnanci .................................................................................................................................. 28 10.1. Typy pracovních poměrů ................................................................................................................... 28 10.1.1. Hlavní pracovní poměr (HPP)....................................................................................................... 28 10.1.2. Dohoda o provedení práce (DPP).................................................................................................. 30 10.1.3. Dohoda o pracovní činnosti (DPČ) ............................................................................................... 30 10.2. Pracovní poměr v BAS ...................................................................................................................... 30 10.3. Způsoby odměňování zaměstnanců ................................................................................................... 30 10.4. Nepřítomnosti .................................................................................................................................... 32 10.5. Prohlídky PMS................................................................................................................................... 32 10.6. Dovednosti ......................................................................................................................................... 33 10.7. Fotografie zaměstnance...................................................................................................................... 33 10.8. Poznámky k zaměstnanci ................................................................................................................... 33 10.9. Měřenkový list ................................................................................................................................... 33 10.10. Kmenová zakázka .............................................................................................................................. 34 10.11. Půjčování jiným manažerům.............................................................................................................. 34 10.12. Pracovní úvazky a parametry pro mzdy............................................................................................. 34 10.13. Přebírání dat ....................................................................................................................................... 36 11. Zákazníci ........................................................................................................................................ 37 11.1. Fakturační položky a statistická zakázka ........................................................................................... 37 11.2. Způsob fakturace................................................................................................................................ 38 11.2.1. Rozdělovat faktury na paušální položky a ostatní ......................................................................... 38 11.2.2. Rozdělovat faktury podle čísel objednávek ve fakturačních položkách........................................ 38

11.2.3. Nerozdělovat podle zakázek a produktů........................................................................................ 39 11.2.4. Rozdělovat faktury podle zakázek................................................................................................. 39 11.2.5. Rozdělovat faktury podle nadřízených zakázek ............................................................................ 39 11.2.6. Rozdělovat faktury podle produktů ............................................................................................... 39 11.2.7. Kombinace parametrů rozdělování fakturačních položek ............................................................. 39 11.3. Četnost fakturace ............................................................................................................................... 39 11.4. Seznam zakázek ................................................................................................................................. 40 11.5. Soubory.............................................................................................................................................. 40 11.6. Poznámky........................................................................................................................................... 40 11.7. Přebírání dat ....................................................................................................................................... 40 12. Výjezdovky..................................................................................................................................... 41 12.1. Základní údaje.................................................................................................................................... 41 12.2. Smluvní podmínky............................................................................................................................. 41 12.3. Seznam zakázek ................................................................................................................................. 41 12.4. Soubory.............................................................................................................................................. 42 12.5. Poznámky........................................................................................................................................... 42 12.6. Přebírání dat ....................................................................................................................................... 42 13. Agentury poskytující brigádníky ................................................................................................. 43 13.1. Základní údaje.................................................................................................................................... 43 13.2. Cena služeb ........................................................................................................................................ 44 13.3. Brigádníci........................................................................................................................................... 45 13.4. Seznam zakázek ................................................................................................................................. 45 13.5. Soubory.............................................................................................................................................. 46 13.6. Poznámky........................................................................................................................................... 46 13.7. Výkazy ............................................................................................................................................... 46 13.8. Aktuální měsíc ................................................................................................................................... 47 13.9. Přebírání dat ....................................................................................................................................... 47 14. Brigádníci....................................................................................................................................... 48 15. Zakázky .......................................................................................................................................... 50 15.1. Definice zakázky................................................................................................................................ 50 15.2. Základní informace ............................................................................................................................ 50 15.3. Ceník zakázky.................................................................................................................................... 51 15.3.1. Ceník plán ..................................................................................................................................... 51 15.3.2. Ceník paušál .................................................................................................................................. 54 15.3.3. Ceník extra .................................................................................................................................... 54 15.4. Agentury ............................................................................................................................................ 55 15.5. Ceny za služby agentury .................................................................................................................... 55 15.6. Brigádníci........................................................................................................................................... 55 15.7. Výjezdovky ........................................................................................................................................ 56 15.8. Soubory.............................................................................................................................................. 56 15.9. Poznámky........................................................................................................................................... 56 15.10. Přebírání dat ....................................................................................................................................... 56 16. Práce s plány ................................................................................................................................. 57 16.1. Tvorba plánů zakázky ........................................................................................................................ 57 16.2. Obsazení plánů zaměstnanci (plánování směn).................................................................................. 57 16.2.1. Základní způsob plánování směn .................................................................................................. 57 16.2.2. Specifikace pracovníka ................................................................................................................. 58 16.2.3. Draft plánu .................................................................................................................................... 59 16.2.4. Finalizace a kontrola plánu ........................................................................................................... 59 16.3. Průběžný zápis skutečnosti ................................................................................................................ 59 16.3.1. Práce dispečera na začátku směny................................................................................................. 59 16.3.2. Automatické ukončování............................................................................................................... 60 16.3.3. Řešení problémů dispečerem......................................................................................................... 60 16.3.4. Vyřešení anomálií manažerem ...................................................................................................... 60 16.4. Kontrola plánů před uzavřením měsíce.............................................................................................. 60 17. Podklady pro fakturaci ................................................................................................................. 62 17.1. Příprava podkladů pro fakturaci manažerem zakázky ....................................................................... 62 17.1.1. Celkový přehled ............................................................................................................................ 62 17.1.2. Standardní položky........................................................................................................................ 62 17.1.3. Extra položky ................................................................................................................................ 63

17.1.4. Extra položky z minulé fakturace.................................................................................................. 63 17.1.5. Přehled minulých faktur ................................................................................................................ 64 17.1.6. Přehled poznámek ......................................................................................................................... 64 17.1.7. Uzavření podkladů pro fakturaci................................................................................................... 64 17.2. Příprava podkladů pro fakturaci finančním kontrolorem ................................................................... 65 18. Podklady pro mzdy ....................................................................................................................... 66 18.1. Vstup podkladů pro mzdy .................................................................................................................. 66 18.2. Úprava podkladů (snížení či zvýšení skutečně vykázaných podkladů) ............................................. 67 18.3. Návrh docházky ................................................................................................................................. 67 18.3.1. Docházka BA ................................................................................................................................ 67 18.3.2. Docházka BAS .............................................................................................................................. 68 18.3.3. Prémie ........................................................................................................................................... 68 18.3.4. Ruční úprava docházky ................................................................................................................. 68 18.3.5. Kontrola docházky ........................................................................................................................ 68 18.3.6. Ruční vložení mzdových složek.................................................................................................... 68 18.3.7. Uzavření podkladů pro mzdy ........................................................................................................ 68 18.4. Návrh mzdy........................................................................................................................................ 68 19. Rozhraní na Helios........................................................................................................................ 70 19.1. Data přebíraná z Heliosu do PS ......................................................................................................... 70 19.1.1. Organizační struktura - TabStrom................................................................................................. 70 19.1.2. Zakázky - TabZakazka .................................................................................................................. 70 19.1.3. Zákazníci - TabCisOrg .................................................................................................................. 71 19.1.4. Agentury - TabCisOrg................................................................................................................... 71 19.1.5. Výjezdovky - TabCisOrg .............................................................................................................. 72 19.1.6. Fakturační položky - TabKmenZbozi ........................................................................................... 72 19.1.7. Číselné řady faktur - TabDruhDokZbo ......................................................................................... 73 19.1.8. Produkt - TabZakIdent .................................................................................................................. 73 19.1.9. Segment - TabDruhCinnosti.......................................................................................................... 73 19.2. Data předávaná z PS do Heliosu ........................................................................................................ 74 19.2.1. Hlavička faktury - expInvHeader .................................................................................................. 74 19.2.2. Položky faktury - expInvDetail ..................................................................................................... 74 20. Rozhraní na PMS........................................................................................................................... 75 20.1. Data přebíraná z PMS do PS.............................................................................................................. 75 20.2. Data předávaná z PS do PMS............................................................................................................. 75 21. Sestavy........................................................................................................................................... 76 21.1. Docházkový list – skutečný ............................................................................................................... 76 21.2. Docházkový list – úřední pro THP..................................................................................................... 76 21.3. Docházkový list – úřední ................................................................................................................... 77 21.4. Přehled stravenek ............................................................................................................................... 77 21.5. Přehled nepřítomnosti BA/BAS......................................................................................................... 77 21.6. Přehled výjezdových služeb............................................................................................................... 78 21.7. Zvýšení ceny ...................................................................................................................................... 78 21.8. Nefakturované zakázky...................................................................................................................... 78 21.9. Zobrazení CB1 ................................................................................................................................... 78 21.9.1. Zakázka ......................................................................................................................................... 78 21.9.2. Zaměstnanec.................................................................................................................................. 78 21.9.3. Podklady pro mzdy........................................................................................................................ 78 21.10. Export položek do MS Excel, případně do PDF ................................................................................ 79 21.11. Rozpis služeb na den.......................................................................................................................... 79 21.12. Zůstatky dovolené.............................................................................................................................. 79 21.13. Končící platnosti školení a prohlídek................................................................................................. 79 21.14. Data narozenin u podřízených............................................................................................................ 79 22. Závěrečné shrnutí a doporučené postupy ................................................................................. 80 22.1. Shrnutí................................................................................................................................................ 80 22.1.1. Výhody.......................................................................................................................................... 80 22.1.2. Nevýhody ...................................................................................................................................... 80 22.2. Doporučené postupy .......................................................................................................................... 81 23. Literatura........................................................................................................................................ 82

11.. A Annaallýýzzaa pprroobblleem maattiikkyy aa hhiissttoorriiee iinntteerrnneettoovvýýcchh aapplliikkaaccíí 1.1. Co je Internet? Různé zdroje se většinou shodují na tom, že internet je globální (celosvětový) systém spolu propojených počítačových sítí, v nichž počítače mezi sebou komunikují prostřednictvím protokolu TCP/IP. Internet poskytuje celou řadu služeb, z nichž mezi nejpoužívanější patří např. www, emailová komunikace či ftp.

1.2. Historie internetu V následujícím článku, publikovaným Vladimírem Brabcem1 na stránkách serveru lupa.cz, je velmi podrobně popsán počátek internetu. ,,Počátečních pokusů bylo mnoho. Jedním z prvních z nich byla Distribuovaná komunikace agentury RAND Corporation. Následovaly tři nejdůležitější: , britská síť NPL, americká síť ARPANET a francouzská síť CYCLADES. Na základě zakázky od U.S. Air Force dostal Paul Baran z RAND Corporation úkol vypracovat studii jak zajistit řízení raket a letadel v případě jaderného napadení. Souhrnný výsledek své čtyřleté práce, návrh sítě s přepojováním paketů (packet switching network), prezentoval v roce 1964 v jedné ze studií On Distributed Communications. Pro úplnost připomeňme, že Baran pojem sítě s přepojováním paketů nezavedl, použil označení "distributed adaptive message block switching". Pojem paket (packet) byl zaveden později, až při budování sítě NPL. Podstatou koncepce přepojování paketů je fragmentace přenášené zprávy do posloupnosti dílčích datových elementů - paketů, které jsou opatřeny mimo jiné i adresou cíle a zdroje, jakož i identifikací příslušnosti k dané posloupnosti a pořadí v ní. V síti jsou nezávisle na sobě přenášeny od počítače k počítači, až dosáhnou cíle, kde jsou opět složeny v původní zprávu. Ztratí-li se nebo poškodí-li se nějaký paket, je požadováno jeho nové přenesení. Koncepce přepojování paketů se liší od koncepce přepojování kanálů používané například v telefonii tím, že není třeba před přenosem zprávy sestavit v síti celou cestu - kanál a rezervovat ji pro přenos zprávy. Anthony Anderberg ve své History of the Internet and Web se domnívá, že mýtus o budování Internetu s cílem, aby jako síť odolal jadernému útoku, byl vyvolán právě Baranovými pracemi. Skutečnost by však byla jiná. Jaderná válka by s největší pravděpodobností vedla ke zničení celé naší civilizace, tedy i Internetu. V britské NPL (National Physical Labolatory) probíhaly v druhé polovině šedesátých let minulého století nezávislé práce na projektu počítačové sítě pracující na principu přepojování paketů. Práce vedl Donald Davies. První verze sítě, MARK 1, byla uvedena do provozu v roce 1971 a byla považována za prvou praktickou implementaci LAN (Local Area Network). Po dvou letech byla nahrazena další verzí, MARK 2. Ta ukončila svou činnost až v roce 1986. Síťové aktivity NPL obohatily teorii i praxi sítí s přepojováním paketů, bohužel nebyly sponzorovány takovým způsobem, aby mohly vznikající americké síti ARPANET úspěšně konkurovat. ARPANET je prvá realizace velké počítačové sítě s přepojováním paketů. Je rovněž pokládána za prvou implementaci WAN (Wide Area Network). Její vznik je spjat s vládní agenturou ARPA (později přejmenovanou na DARPA) , ustavenou v roce 1957 jako reakce USA na vypuštění prvé sovětské družice SPUTNIK. Cílem činnosti této agentury bylo zabezpečit USA vědecko-technické prvenství zaměřené na vojenské aplikace. Původní návrh sítě ARPANET z roku 1966 byl založen na využití specializovaných počítačů umístěných mezi hostitelské počítače (hosts) a komunikační síť. Byly označovány jako IMP (Interface Message Processor) a měly zajišťovat potřebné operace pro přepojování paketů, včetně směrování. Jejich vývoj a výroba byla v roce 1968 svěřena firmě BBN (Bolt Beranek and Newman Inc.), která za základ IMP použila minipočítače firmy Honeywell. Pro dopracování potřebného technického a programového vybavení vytvářela se na UCLA (University of California at Los Angeles) kolem Leonarda Kleinrocka skupina asi 40 lidí označovaná jako NWG (Network Working Group). Její programátorskou část, pracující zejména na protokolech IMP-HOST a 1

Brabec Vladimír: Co bylo, než vznikl český Internet? 13.8.2002, dokument je dostupný na http://www.lupa.cz/clanky/cobylo-nez-vznikl-cesky-internet/

9

HOST-HOST (Network Control Protocol), byla vedena Steve Crockerem, který se také stal autorem prvého informačního materiálu řady RFC (Request for Comments), považované dnes za studnici oficiálních internetových dokumentů. Práce skupiny se účastnili i osobnosti, jejichž jména se později velmi proslavila a která zná dnes celý internetový svět. Patřili k nim například Vinton Cerf (otec Internetu), Jonathan Postel (editor RFC, spoluautor TCP/IP a pozdější vládce IANA (Internet Assigned Numbers Authority)) a řada dalších. V druhé polovině roku 1969 byla zahájena fyzická výstavba sítě ARPANET. Ke konci roku 1969 představovala propojení čtyř hostitelských počítačů umístěných v UCLA, SRI (Stanford Research Institute), UCSB (University of California Santa Barbara) a UU (University of Utah). Propojeny byly pronajatými okruhy pracujícími s rychlostmi 50 Kb/s. UCLA v síti plnila funkci měřícího střediska (Network Measurement Center) a SRI funkci informačního střediska (Network Information Center). Proslulým se stalo ručně nakreslené schéma tohoto prvopočátku sítě ARPANET. Připomeňme i slavný Kleinrockův interview "This is login", ve kterém v roce 1999 přitažlivě vzpomíná na počátky sítě ARPANET při příležitosti třicetiletého výročí zahájení její výstavby. Zajímavá je odlišnost architektury sítě ARPANET od sítí NPL a CYCLADES. Počítače IMP byly vedle směrování zodpovědné i za bezchybný přenos zprávy od zdrojového IMP až po cílový IMP. Tedy fragmentace a defragmentace přenášených zpráv včetně zotavovacích akcí při chybách se prováděly nikoliv na hostitelských počítačích, nýbrž na počítačích IMP. Základní aplikace, kterou počáteční ARPANET dovolovala, byl terminálový přístup ke vzdálenému počítači, TELNET. V roce 1972 byla síť doplněna o další specializované počítače, TIP (Terminal Interface Processor), které umožňovaly přímý přístup terminálů do sítě. V tomtéž roce se ARPANET rozšířila o tichomořskou paketovou radiovou síť ALOHA. Síťové aplikace byly rozšířeny o přenos souborů, FTP (File Transfer Protocol) a o elektronickou poštu. Málo známé je, že elektronickou poštu sítě ARPANET použila v roce 1976 i britská královna. V roce 1973 se ARPANET propojila i mezinárodně. S pozorovací stanicí v Norsku a s londýnskou University College. V roce 1980 bylo do sítě ARPANET zapojeno přes dvě stovky hostitelských systémů a v průměru každých dvaceti dnů se rozšiřovala o další hostitelský systém. V roce 1983 se sada protokolů TCP/IP stala oficiálními protokoly sítě ARPANET. V tomtéž roce se od této sítě oddělila její vojenská část a vytvořila síť MILNET. Svou činnost ukončila ARPANET v roce 1989. Francouzská síť CYCLADES navazuje na svůj americký vzor - síť ARPANET. Institut INRIA (Institut de Recherche d'Informatique et d'Automatique) se ujal vývoje této sítě. Ředitelem projektu se stal Louis Pouzin. Síť začala pracovat v roce 1972 a svou dvacítkou hostitelských systémů byla v provozu ještě i v osmdesátých letech minulého století. Její architektonické řešení přispělo k problematice počítačových sítí především komunikačním podsystémem CIGAL, ve kterém se podařilo vytvořit a ověřit směrování a přenos tzv. datagramů s tím, že fragmentace zpráv do datagramů a defragmentace datagramů do původních zpráv včetně zotavovacích akcích při chybách byly na rozdíl od sítě ARPANET funkčně přesunuta na hostitelské systémy. Většímu rozšíření sítě CYCLADES bránila evropská a zejména francouzská orientace na standardy X.25“.

1.3. Co je to internetová aplikace Internetovou aplikaci můžeme definovat jako aplikaci, která je přístupná pouze prostřednictvím internetového prohlížeče bez nutnosti instalace dalších programových součástí. Takovéto řešení aplikací má výhodu především v tom, že jsou snadno distribuovatelné mezi uživatele, ve většině případů se nemusí u uživatelů řešit přechod na novější verze aplikace a především, jsou multiplatformní, tzn. že se dají provozovat na nejrůznějších operačních systémech2. Ve většině případů tyto aplikace vyžadují pouze správnou verzi prohlížeče a některých podpůrných systémů, jako je např. Java.

2

Lacko Luboslav, Web a databáze programujeme internetové aplikace 10

Co je to portál Portál je, jak už sám název říká, brána. V prostředí internetu resp. intranetu můžeme říci, že portál je brána k informacím. Ve většině případů se jedná o webovou aplikaci, která má za úkol integrovat informace z různých zdrojů a v nějaké ucelené a přehledné formě je nabídnout uživateli. Podle Freda Manhartsbergera3 lze podnikový portál definovat takto: „enterprise portál je víceúrovňový technologický systém, který integruje procesy, aplikace a data, a vytváří jedno celistvé prostředí, jež umožňuje společnostem poskytnout jednotný komunikační kanál všem, kdo se chtějí zúčastnit jejich obchodních aktivit.“ Každý uživatel internetu portál zná, protože ve většině případů je to to první, kam směřují jeho kroky. Mnoho uživatelů má portály jako jsou Yahoo či Seznam nastaveny jako svou domovskou stránku a jejich prostřednictvím začínají svou práci či zábavu na internetu. Možnosti portálů jsou samozřejmě mnohem vyšší, jak bude demonstrováno na konkrétním příkladu v druhé části této práce. Portál agreguje data z různých zdrojů a aplikací. Uživatel ve většině případů potřebuje pouze jediný způsob přihlášení, aby se na jeho základě dostal k informacím, které jsou určené právě jemu. V mnoha případech umožňují portály uživateli nastavení vlastního vzhledu stránek, jazykové mutace nebo i obsahu zobrazovaných dat. Tím je práce s daty pro uživatele efektivnější . Portály jsou tedy často tzv. userfriendly, uživatelé s nimi rádi pracují, protože si pracovní prostředí mohou přizpůsobit dle svých potřeb. Není výjimkou, že stejný portál se stejnými daty vypadá v podání dvou uživatelských profilů jako 2 zcela odlišné aplikace.

3

Manhartsberger Fred: Portály se prosazují - zkuste to s nimi. Dokument je dostupný na URL http://www.pcworld.cz/ (duben 2006).

11

22.. TTyyppyy ppoorrttáálloovvýýcchh aapplliikkaaccíí Podle typů a zaměření na různé cílové skupiny můžeme portály rozdělit na tyto skupiny - firemní - vládní a regionální - sportovní, vědecké, kulturní - osobní, komunitní Název typů výstižně říká, co můžeme na kterých typech portálů hledat. Pro potřeby této práce se budu dál zabývat pouze portály firemními. Mnoho firem považuje portál za centrální přístupový bod ke všem informacím. Dříve tomu tak ale nebylo, protože vznikaly portály, které byly zaměřeny pouze na jednu oblast, tzv. vertikální formáty. Jako příklad můžeme uvést portál pro řešení skladu a skladových zásob. Časem ale vznikla potřeba tyto portály integrovat s informacemi z jiných zdrojů a to pomocí horizontálních portálů. Ty mohou např. sloužit jako jediný přístupový bod pro všechny zaměstnance firmy. Shrneme-li to, tak vertikální portály jsou úzce zaměřené na jednu oblast, zatímco horizontální portály integrují velké množství informací a služeb. Ve firemním prostředí můžeme najít tyto typy portálových aplikací: - B2E – portál pro zaměstnance - B2B – portál pro obchodní partnery - B2C – portál pro zákazníky - kumulace dvou nebo všech typů portálů

2.1. B2E – Business to employee – portál pro zaměstnance Cílem portálů tohoto typu je dát k dispozici zaměstnancům veškeré informace, které potřebují ke své práci a jejich správné a efektivní fungování v rámci firmy. Na jednom místě tak má většinou pracovník k dispozici všechny důležité firemní dokumenty, jako jsou normy, interní sdělení, nařízení, kterými se musí řídit, informace o aktuálním dění ve firmě, informace o benefitech, kariérním růstu, vzdělávání, atp. Portál v tomto případě hraje významnou roli v tom, že pracovník má všechny informace na jednom místě, věcně setříděné a nemusí složitě pátrat, které oddělení má tu či jinou agendu na starosti. Zajímá-li ho např. možnost kurzů na PC, vyhledá si jej a je přímo nasměrován na konkrétní oddělení či osobu, která tuto problematiku řeší. Pracovník se v tomto případě také dozví, v jakém rozsahu jsou kurzy na PC organizovány, jak je kurz začleněn do jeho kariérního růstu, kolik jej bude kurz stát, atp. Samozřejmostí jsou informace jako organizační struktura společnosti, telefonní seznam, a vzájemná vazba mezi seznamem pracovníků, organizační strukturou a např. popisem činnosti jednotlivých oddělení. Portály ale informace pouze nenabízejí, umožňují samozřejmě zaměstnancům také vyřizovat běžnou agendu, jako je vyplnění žádosti o dovolenou, přihlásit se na školení řidičů, vyplnit libovolnou anketu, atp. Některé informace může např. pomocí emailu distribuovat portál pracovníkům sám. Můžou to být např. informace o vyúčtování závodního stravování, o termínu příštího školení, o tom, že mu vyprší platnost zdravotní prohlídky, atp.

2.2. B2B – Business to business – portál pro obchodní partnery Koncept B2B je nejstarší složkou elektronického podnikání (e-business). Zkratka B2B pochází z anglického termínu Business to Business (obchodník → obchodník), koncept B2B se tedy týká obchodních vztahů a vzájemné komunikace mezi dvěma společnostmi. B2B vztahy většinou fungují na principu elektronické výměny dat. Těmi mohou být základní informace (např. objednávky, faktury), jejichž elektronická podoba umožňuje snížit náklady, automatizovat celý proces a zvýšit jeho rychlost. Vyšším stupněm B2B obchodování jsou různá B2B internetová tržiště, jejich hlavním úkolem je zprostředkování obchodů. Nejsložitější B2B systémy potom fungují jako komunikační a distribuční sítě, sloužící především k regulaci již navázaných obchodních vztahů. Častým případem je i přímé napojení takovýchto B2B systémů na další programy v rámci softwarové struktury prodávající firmy, což přináší úspory a zvyšuje efektivitu celého prodejního procesu.

12

Zajímavé je, že většina současných B2B systémů je svou kvalitou na mnohem nižší úrovni než B2C systémy určené koncovým zákazníkům (možná právě proto, že B2B zákazníka předem známe a zdánlivě jej tedy není nutné o ničem přesvědčovat).

2.3. B2C – Business to customers – portál pro zákazníky B2C je patrně nejrozšířenějším modelem internetového podnikání (e-business). Zkratka B2C pochází z anglického termínu Business to Customer (obchodník → zákazník). Segment B2C tedy zahrnuje především přímý prodej koncovým zákazníkům či alespoň jeho podporu. Obvykle se rozlišují tři úrovně B2C modelu. Základem služeb B2C je snaha informovat o produktech, webová stránka zde vlastně plní funkci jakéhosi letáku či elektronického katalogu. Vyšší úroveň B2C služeb přidává interaktivní formuláře, např. možnost zpětné vazby. Nejvyšší úrovní B2C je potom samozřejmě samotný internetový obchod, nejlépe s možností rovnou zaplatit objednané zboží online.

13

33.. M Moožžnnoossttii ppoorrttáálloovvýýcchh aapplliikkaaccíí Jak už jsem naznačil, portálové aplikace jsou v dnešní době používány v celé řadě organizací, institucí , veřejném i soukromém sektoru, nekomerční sféře a také pro zábavu běžných uživatelů. Jsou fenoménem dnešní doby a neustále se rozvíjí jejich možnosti a funkcionalita. Pro praktickou konkrétní ukázku tvorby portálové aplikace jsem použil projekt, na jehož tvorbě jsem se v posledních letech spolupodílel. Jeho poslední fází byla tvorba portálového provozního systému, který je popsán v následujících kapitolách.

3.1. Úvod do problematiky aplikace V průběhu minulých měsíců jsem měl možnost zúčastnit se zadání, analýzy, vývoje, testování a implementace speciální portálové aplikace, vyvíjené pro potřeby soukromé bezpečnostní agentury. Cílem této aplikace bylo využít poznatků z aplikací minulých a použít je v aplikaci nové, která je výchozím bodem pro další rozšiřování tohoto systému. V minulých letech byly touto bezpečnostní agenturou používány různé systémy. Základní zadání bylo, aby aplikace umožnila uživatelům připravit elektronická data pro fakturaci a mzdy pracovníků. Firma používala jiný systém pro finanční účetnictví a jiný systém pro personální a mzdovou agendu. Data se pořizovala pouze ručně vyplněním daných formulářů a musela být účetními přepisována do obou systémů. Vše bylo velmi pracné a chybovost byla velmi vysoká. V průběhu roku 2000 byla oslovena firma, která prováděla implementaci nového účetního programu, aby vyvinula systém, který by tuto manuální činnost ve větší míře zautomatizoval. Důraz byl kladen na to, aby data pořízená touto aplikací bylo možno dávkově přenést do účetního a mzdového systému. Vznikla první verze, která byla vyvinuta v prostředí MS Access 7. Na každém regionu, ve kterém bezpečnostní agentura měla pobočku, byla umístěna společná databáze a klientské aplikace přistupovaly do této společné regionální databáze. Při měsíční uzávěrce byla administrátorem vyexportována data za konkrétní měsíc, tato data byla následně neimportována do speciální databáze, z níž se poté pomocí importních mechanizmů importovala do účetních, resp. mzdových systémů. Tento produkt se po přibližně ročním používání jevil jako nedostatečný, protože měl celou řadu nedostatků. Mezi hlavní patřily např. nedostatečný výkon aplikace a především nemožnost provázání databází MS Access s databázemi personálního a mzdového systému. V tehdejší době nebyly k dispozici rychlé a levné internetové spoje a po technické a finanční stránce bylo vlastně nemožné používat tzv. online systém. Tedy společnou databázi pro všechny klienty této aplikace. Vznikla proto potřeba tento nedostatek odstranit a tak autor této aplikace navrhnul migraci klientské části do prostředí MS Access 2000 a jako databázi použít MS SQL 2000. Toto řešení umožnilo odstranění mnoha nedostatků z verze předchozí. Hlavní výhodou bylo, že personální data bylo možné načítat z personálního systému a tím pádem nedocházelo k chybám, při zadávání pracovníků aplikace. Bylo již možno pořizovat plány směn pro každou zakázku, pořizovat dle těchto plánů skutečnou docházku pracovníků a dle této docházky poté připravit elektronické podklady pro mzdy i pro fakturaci. I v této verzi však byly nedostatky, které nešly jednoduše řešit. Nedošlo k nahrazení lokálních databází na úrovni regionů, na každém regionu byl nainstalován MS SQL server, který bylo nutno udržovat. Díky velkému množství uživatelů bylo velmi komplikované zajistit rychlou instalaci nových verzí aplikace. Importy dat byly i nadále poměrně časově náročnou operací. V roce 2006 došlo k rozhodnutí, že stávající účetního systém je nahrazen systémem jiným, a tak společnost začala od 1.1.2007 používat systém Helios Orange. Se změnou tohoto účetního systému muselo dojít buď k úpravě nebo ke změně provozní aplikace. Společnost se rozhodla přejít k aplikaci jiné, která je vycházet z aplikace původní, ale odstraní již zmíněné nedostatky. V průběhu roku 2006 začala tedy vznikat platforma pro první portálové řešení. Jako datová platforma byla použita databáze MS SQL 2000, aplikace byla vyvíjena v PHP, Javě a AJAX. Původní záměr byl zprovoznit tento systém spolu se zavedením Helios Orange, nakonec ale díky špatně řízenému projektu došlo pouze k částečnému zprovoznění a s ročním zpožděním. Díky tomu se společnost rozhodla nepokračovat ve spolupráci s původním dodavatelem systému a v roce 2007 vyhlásila výběrové řízení na dodavatele portálového provozního systému (PS), který měl splňovat tato hlavní kritéria: aplikace spustitelná v internetovém prohlížeči kompatibilním s IE7 a vyšším a Firefox 2.0 a vyšším zabezpečený přístup pro uživatele, možnost definovat uživatelské role a pomocí nich řídit, jakou část aplikace může uživatel používat přístup k datům musí kopírovat organizační strukturu společnosti data o zákaznících, zakázkách a dodavatelích budou do PS načítána z Helios Orange

14

data o pracovních budou do PS načítána z personálního programu PS umožní na každou zakázku vytvořit plán služeb, který je korespondovat se smlouvou se zákazníkem, a to jak rozsahem, tak cenou za vykonanou službu PS zajistí do plánu služeb zadat na každé období konkrétní pracovníky, kteří mají službu odpracovat PS umožní potvrdit, změnit či zrušit předem naplánovanou službu PS v každý okamžik může nabídnout každému uživateli seznam pracovníků, kteří jsou pro konkrétní službu k dispozici Po potvrzení docházky PS umožní zpracovat zaevidované služby a připraví data pro fakturaci Po potvrzení docházky PS umožní zpracovat zaevidované služby a připraví data pro mzdy PS nabídne uživatelům sestavy, které jim pomohou při zpracování celé agendy PS je sloužit jako zdroj dat, pro již zavedený reportingový systém DWH Toto zadání bylo rozesláno několika firmám, které se zabývají vývojem portálových aplikací. Jejich nabídky byly vyhodnoceny. Vybrána byla nakonec společnost, která již s bezpečnostní agenturou dříve spolupracovala na projektu DWH. Jejich znalost prostředí a problematiky bezpečnostní agentury a také zkušenosti s podobným projektem pro firmu provozující v ČR hustou síť prodejen byly hlavním důvodem jejich výběru. Na základě zadání byla provedena velmi pečlivá analýza jednotlivých bodů, které má aplikace zajišťovat. V následujících kapitolách je popsána technická specifikace aplikace, na níž jsem pracoval společně s dodavatelem aplikace.

15

44.. S Shhrrnnuuttíí aa oobbssaahh tteecchhnniicckkéé ssppeecciiffiikkaaccee Kapitola 4 zachycuje požadavky na Provozního Systém (dále jen PS). Pojmy určující způsob organizace dat jsou prezentovány v kapitole 5. V kapitole 6 jsou navrženy základní části technického řešení – PS je realizován v architektuře tenkého klienta, kdy uživatel je pracovat prostřednictvím webového prohlížeče a data budou poskytována aplikačním serverem. Jedná se o v současné době nejpoužívanější architekturu pro vývoj aplikačních řešení. Jsou zde zmíněna pravidla pro vlastní programovou realizaci díla. Aplikační řešení zajistí řízený přístup k datům prostřednictvím bezpečnostních standardů centrální definice uživatelů a členství v rolích, které jsou popsány v kapitole 7. Informace o zaměstnancích potřebné pro zabezpečení funkčních požadavků kladených na PS zachycuje kapitola 8, včetně popisu možností způsobu zaměstnávání a odměňování pracovníků bezpečnostní agentury (BA). Tato kapitola rovněž popisuje základní propojení PS a personálního a mzdového systému (PMS). Problematiku evidence zákazníků a dodavatelů služeb (výjezdovky, agentury a brigádníky) shrnují kapitoly 9 až 12. Hlavní funkcionalita PS je soustředěna v oblasti práce se zakázkami, která je podrobně rozepsána v kapitolách 13 až 16. Jsou zde popsány jednotlivé části práce se zakázkami v celém rozsahu, od evidence základních údajů o zakázce, přes zachycení smluvních podmínek, evidenci plánů a vykázaných služeb, podkladů pro fakturaci. Popisuje způsob uzavření docházky a mezd, přípravu podkladů pro fakturaci a způsob předání dat k dalšímu zpracování. Dále je zde obsažena algoritmizace procesu tvorby docházkových listů. Popis obsahuje také návrh uživatelského rozhraní formou ukázek z formulářů, které budou využity v PS. Kapitoly 17 a 18 technologicky popisují způsob výměny dat s okolními systémy – PMS a Helios Orange. Požadavek na výstupy je zpracován v kapitole 19 formou ukázek sestav a popisu jejich obsahu.

Klíčové požadavky lze shrnout jednou větou: BA požaduje systém, který je podporovat jeho provozní proces, je dostupný, rychlý a uživatelsky přívětivý.

16

55.. S Seezznnaam m ppoojjm můů aa zzkkrraatteekk Zkratka/pojem BA CSS DIČ DPČ DPP ERP GPRS GSM Helios HPP HTML IČO IIS IT LDAP MS PCO PS SMS SQL THP

Význam/popis Bezpečnostní agentura Cascaded Style Sheets Daňové identifikační číslo organizace Dohoda o praconí činnosti Dohoda o provedení práce Enterprise Resources Plannning General Packet Radio Service Global System for Mobile Communication Helios Orange Hlavní pracovní poměr Hypertext Markup Language Identifikační číslo organizace Microsoft Internet Information Server Information Technology Lightweight Directory Access Protocol Microsoft Corporation Pult centrální ochrany Provozní systém Short Messaging System Structured Query Language Technicko-hospodářský pracovník

17

66.. P Syyssttéém Poožžaaddaavvkkyy nnaa P muu Poorrttááll P Prroovvoozznnííhhoo S 6.1. Základní požadavky BA poskytuje svým zákazníkům bezpečnostní služby. Interně je BA rozdělena do pěti divizí, z nichž čtyři poskytují přímé bezpečnostní služby zákazníkům (Guarding, Bank Security, Mobile Patrols, Monitoring & Alarms). Provozní Systém (dále jen PS) má za úkol podpořit manažery jednotlivých zakázek při přípravě podkladů pro fakturaci zákazníkům a při přípravě podkladů pro výplatu mezd zaměstnancům. Dále PS centralizuje evidenci informací o jednotlivých zakázkách, nahradí řadu rutinních ručně prováděných činností a poskytne informace pro další činnosti, jako je například kontrola oprávněnosti fakturovaných částek dodavateli služeb na jednotlivých zakázkách atd. V neposlední řadě PS zmenší potřebu ručního přepisu informací a zjednoduší předávání informací mezi pracovníky BA. PS musí být schopen pokrýt požadavky jednotlivých divizí, které jsou s ohledem na způsob jejich práce v určitých ohledech různorodé, neboť divize Guarding a Bank Security fungují v odlišném režimu než zbývající dvě divize. PS musí být schopen spolupracovat s dalšími IT systémy v rámci BA, zejména pak s ERP systémem Helios Orange, ve kterém je vedeno účetnictví společnosti. Dalším klíčovým systémem, se kterým musí být PS schopen spolupracovat, je PMS, ve kterém je zpracovávána oblast personální a mzdové agendy společnosti. Pro komunikaci s manažery jednotlivých zakázek je PS v určitých případech, které jsou popsány dále v tomto dokumentu, komunikovat prostřednictvím elektronické pošty a nebo prostřednictvím GSM brány je zasílat vybraným osobám SMS zprávy. Dalším systémem, který je čerpat z PS informace je reportovací systém.

18

6.2. Spolupráce s dalšími firmami Jak jsme již uvedl, BA poskytuje své služby zákazníkům prostřednictvím zakázek. S každým zákazníkem může být současně aktivní libovolný počet zakázek, nicméně každá zakázka je vždy spojena jen s jedním zákazníkem. Pokud je zapotřebí poskytovat zákazníkovi služby z více divizí (např. přes den požaduje zákazník na své pobočce službu strážného a přes noc je napojen na PCO), jsou pro jednotlivé služby vytvořeny samostatné zakázky pro příslušné divize. Každá zakázka je tedy přiřazena jedné z divizí a ve většině případů jsou všechny služby spojené s realizací dané zakázky prováděny příslušnou divizí. V určitých případech však může dojít k situaci, kdy jsou služby provedeny i jinou divizí - v tom případě je možné volitelně dodatečně realizované služby přesunout na zakázku dotyčné divize. Typicky se jedná o situaci, kdy je zákazník připojen na PCO - máme tedy zakázku divize Monitoring & Alarms - a po nahlášení narušení objektu provede výjezd divize Mobile Patrols. Vzhledem k potřebě pokrytí celé ČR spolupracuje BA s dalšími společnostmi, které provádějí na vyžádání výjezdy autohlídek (Externí výjezdovkou nebo Policie ČR). Pro každou zakázku je určen seznam výjezdovek, které tuto službu pro BA zajišťují a v případě výjezdu tento fakturují BA k proplacení předem dohodnutých částek. Částky mohou být dohodnuty s danou výjezdovkou pro každou zakázku individuálně. Více výjezdovek k jedné zakázce je evidováno v podstatě pouze pro velká obchodní centra, typicky je k jedné zakázce pouze jedna výjezdovka. Pro případ nedostatku vlastních pracovníků spolupracuje BA s dalšími společnostmi (Agenturami), které jí dodávají brigádníky. Pod pojmem brigádník tedy jeme nadále rozumět zaměstnance jiné společnosti. Pokud je člověk v určitém pracovním vztahu přímo se BA (byť i na krátkodobý pracovní poměr), mluvím o takovém člověku jako o zaměstnanci. S ohledem na omezení vyplývajícího z platné legislativy spolupracuje BA se společností BAS. Většina pracovníků BA má dohodu o pracovní činnosti (DPČ) ve společnosti BAS a část mzdy je vyplácena právě prostřednictvím této společnosti.

6.3. Technologické požadavky Základní požadavkem na PS je realizace ve formě tzv. tenkého klienta, kdy uživatelé pracují s daty pouze prostřednictvím webového prohlížeče, neboť pracují i na počítačích zákazníků, kam není možné instalovat klientskou část aplikace. Jako webové prohlížeče jsou pro realizaci tohoto projektu stanoveny prohlížeče MS Internet Explorer verze 6.x nebo verze 7.x nebo Mozilla FireFox verze 2.x Rozlišení monitorů pracovních stanic je dohodnuté minimálně 1024x768 pixelů, proto je design aplikace navrhován tak, aby uživatelé s tímto rozlišením mohli s PS pracovat. Aplikační řešení samozřejmě podporuje rolování v oknech. Někteří uživatelé jsou připojeni prostřednictvím málo průchodných technologií (GPRS, málokapacitní připojení do internetu), proto musí být PS realizován tak, aby s ním i tito uživatelé mohli pracovat v přiměřených dobách odezvy.

19

77.. ZZáákkllaaddnníí ppoojjm myy 7.1. Hierarchie zakázek v Heliosu Zakázky jsou v rámci BA vytvářeny a evidovány tak, že tvoří stromovou hierarchii, která je určena číslem zakázky. Na nejnižší úrovni jsou běžné zakázky pro koncové zákazníky. Číslo takové zakázky se skládá z pěti číslic a začíná číslicí 0 až 8 (jedná se tedy o čísla zakázek 00001 až 89999). Zakázka tohoto typu má obvykle zadanou takzvanou nadřízenou zakázku, nebo přímo zakázku určující manažera zakázky. Nadřízená zakázka slouží v podstatě pouze ke sdružení příbuzných zakázek z důvodu snadnějšího účtování. Čísla nadřízených zakázek jsou šestimístná a v současné době začínají jedničkou. Jedná se tedy o čísla zakázek větší než 100000. Zakázka typu „Manažer zakázky“ sdružuje své podřízené zakázky a je většinou přiřazena jednomu konkrétnímu zaměstnanci BA, nicméně existují i takové zakázky, které náleží více osobám (jedna zakázka typu Manažer představuje ve skutečnosti více osob). Pro upřesnění uvádíme, že některé zakázky typu manažer jsou specifické a slouží pro potřeby rozčlenění účetních zápisů v systému Heliosu (protože to Helios jinak neumí) – mezi takové patří např. zakázka 99999 - Režie THP U každého záznamu typu Zakázka je v Heliosu zadán produkt, středisko, zákazník, datum začátku a ukončení (plánované i skutečné). Pro potřeby PS jeme přebírat několik základních údajů k zakázce, řadu dalších jeme zadávat až v PS. Podrobněji je práce se zakázkami popsána dále v této technické specifikaci.

7.2. Organizační struktura Každá organizační jednotka má přiřazen svůj jednoznačný identifikátor. V tomto identifikátoru je obsaženo číslo divize, číslo oblasti a číslo útvaru. Identifikátor se typicky skládá z 11 znaků – první tři znaky jsou stále stejné, další tři znaky určují divizi, další dva oblast a poslední tři útvar. Pokud některý identifikátor je kratší než 11 znaků, není chybějící část použita (např. pozice generální ředitel má pouze první tři znaky, čímž je signalizováno, že zbytek BA spadá pod generálního řiditele). V současné době je následující struktura divizí, oblastí a útvarů:

Na dalším obrázku je ukázka části organizační struktury podle definice v Heliosu. Pro potřeby PS nejeme v tuto chvíli potřebovat z identifikátoru organizační jednotky zjistit žádné údaje. Jedinou výjimkou je hledání zaměstnance z určitého regionu. V tom případě jeme hledat zaměstnance, jejichž organizační jednotka (uvedená ve kmenové zakázce těchto zaměstnanců) má shodný region jako kmenová zakázka uživatele, který provádí hledání. Každý uživatel tedy je spojen s určitým regionem.

20

7.3. Odlišnosti práce jednotlivých divizí Protože se způsob poskytování služeb jednotlivými divizemi zákazníkům liší, zmíníme se o způsobu jejich práce podrobněji. V podstatě nejjednodušším případem je poskytnutí jednorázové služby (EXTRA) v případě potřeby – např. nainstalování vysílače pro komunikaci s PCO, výjezd zásahového vozidla apod. Tyto jednorázové služby jsou nazývány Extra službami. Na jejich realizaci nejsou předem alokováni v rámci PS žádní pracovníci (realizují tyto služby v rámci své běžné pracovní doby nebo se jedná o dodávku třetí stranou) a zákazníkovi jsou fakturovány v případě jejich skutečného provedení. Druhým poměrně jednoduchým případem jsou služby poskytované zákazníkovi v rámci předem stanoveného paušálu (PAUŠÁL). Se zákazníkem je dohodnuta konkrétní služba a zákazník platí paušální částku za určité období, kterým hradí poskytování této služby. Perioda fakturace může být měsíční nebo za jiné delší období (dva měsíce, čtvrtletí, pololetí, rok). Může se fakturovat nejen na konci období, ale i v jeho průběhu, na jeho začátku nebo v krajním případě i před začátkem (zákazník si předplatí službu na další měsíc). Třetím případem je poskytování služeb typu ostraha (VÝKAZY), kdy zákazník platí skutečně odsloužené hodiny jednotlivých strážných (nejedná se pouze o strážné, ale také např. recepční, velitele objektů apod.). Zde zákazník požaduje zajištění určitého počtu postů v konkrétních časech, BA je musí pokrýt zaměstnanci (nebo brigádníky) a po odpracování může skutečně odsloužené hodiny na zakázce fakturovat. Samozřejmě je možná kombinace všech tří případů i v rámci jedné zakázky, nicméně ve většině případů jsou v rámci zakázky používány buď Extra + Paušály nebo Extra + Výkazy. Způsoby práce s těmito typy služeb budou popsány později.

21

88.. N Náávvrrhh tteecchhnniicckkééhhoo řřeeššeenníí Aplikace je vyvíjena ve třívrstvé architektuře. Základní vrstvu představuje databázový server, kde jsou data ukládána do relační databáze MS SQL Server 2005 Standard Edition. Přístup k jednotlivým tabulkám pro změnu dat neje povolen, veškeré změny jsou prováděny prostřednictvím uložených procedur (podrobněji jsou důvody popsány dále v tomto dokumentu). Druhou vrstvu představuje aplikační server, v tomto projektu MS Internet Information Server. V rámci aplikačního serveru jsou spouštěny komponenty vyvinuté v prostředí .NET (pokud není řečeno v dokumentu jinak, pak vždy pro .NET Framework 2.0). Třetí vrstvu představuje webový prohlížeč, v rámci kterého je provozována klientská část aplikace. S ohledem na některé specifické požadavky na aplikační řešení může být zapotřebí upravit nastavení prohlížeče – toto nastavení může záviset na požadované funkcionalitě a je uvedeno v administrátorské příručce příslušné části aplikace (např. musí být vždy povoleno použití skriptování na straně klienta). Jednotlivé vrstvy můžeme ještě dále rozdělit do menších komponent a skupin. Např. v databázové vrstvě jsou použity tabulky pro uložení dat, uložené procedury pro modifikaci a získávání dat, pohledy (view) pro upravený pohled na data, databázové funkce, triggery apod. V rámci aplikačního serveru je vytvořena řada komponent, např. pro zjednodušení práce s databází, práci s logy apod. Na klienstké straně jsou jako dílčí části použity CSS styly, JavaScriptové funkce a samozřejmě vlastní HTML kód (generovaný .NET Frameworkem a MS IIS).

8.1. Databázová vrstva Databázová vrstva slouží k ukládání dat a zabezpečuje jejich zpřístupnění uživatelům pomocí definovaného rozhraní. Změny dat nejsou prováděny z vyšší vrstvy (tedy z aplikačního serveru) přímo SQL příkazy typu INSERT, UPDATE, DELETE, ale jsou prováděny prostřednictvím uložených procedur. Nad každou tabulkou nebo sadou tabulek je vytvořena skupina uložených procedur, která tyto operace zajistí. Výhodou tohoto principu je zabezpečení řízeného přístupu k datům – procedura nejprve zkontroluje, zda uživatel má právo provádět příslušnou operaci (např. zda má právo založit nový záznam na základě členství v uživatelské roli v rámci aplikace), poté provede další potřebné kontroly (např. vyplnění logicky povinných položek, existence očekávaných dat v dalších tabulkách), provede změny nejen v dotyčné tabulce ale i v dalších souvisejících tabulkách (např. vytvoří záznam v historii). Další výhodou je, že uživatel nemusí mít fyzická práva k práci s tabulkou na úrovni databáze (např. členství ve skupině data_reader nebo data_writer), ale stačí mu práva spouštět příslušnou uloženou proceduru. Nevýhodou tohoto principu je vyšší pracnost tvorby aplikace a nemožnost číst data mimo rozhraní vytvořenými procedurami. Z toho důvodu může být vhodné některé uživatele zařadit do skupiny data_reader, díky čemuž je mít právo číst libovolná data, ale změny je opět muset provádět prostřednictvím uložených procedur. Uživatelé s PS pracují pod svým MS Windows účtem (princip Single Sign On) stejně tak pracují i s databází pod svým skutečným uživatelským účtem (Integrated security). Díky tomu lze až v uložených procedurách identifikovat uživatele podle jeho uživatelského jména a tento údaj se nemusí předávat mezi jednotlivými vrstvami a zamezí se podvržení identity uživatele.

22

8.1.1.

Primární klíče

Primární klíč je určen pro identifikaci každého záznamu v tabulce MS SQL. Primární klíče jsou generovány automaticky a pro nastavování hodnot umělých primárních klíčů v tabulkách je využita možnost automatického generování v rámci MS SQL využitím IDENTITY. Datový typ každého primárního klíče je BIGINT a to i pro tabulky, kde je předpokládán malý počet záznamů (číselníky). Při ukládání dat do tabulek je ponecháno automatické generování hodnot vždy, pokud je to možné – ruční vkládání ovlivněné nastavením SET IDENTITY_INSERT je využíváno opravdu vyjímečně. Pokud je pro některé záznamy primární klíč typu řetězec (VARCHAR), není v takovém případě automatické generování použito. 8.1.2.

Práce s UNICODE znakovou sadou

S ohledem na současný stav, kdy není nutné ukládat znaky z UNICODE znakové sady, jsou všechny části PS řešeny tak, že UNICODE znaky nejsou zpracovávány a je zpracovávána pouze znaková sada Windows 1250. 8.1.3.

Vedení historie záznamů

Pro řadu informací požadujeme vedení jejich historie, tedy sledování změn v průběhu času pro jednotlivé záznamy. Tato evidence je realizována formou tzv. historických tabulek, kdy ke každé tabulce obsahující data (která chceme takto sledovat) je vytvořena další tabulka (její název je se sufixem _HIST). Historická tabulka obsahuje všechny sloupce z původní tabulky, doplněné dalšími informacemi – např. autor, datum a čas zápisu záznamu neje v původní tabulce, ale pouze v historické. Historické tabulky standardně neobsahují žádné cizí klíče ani indexy z důvodu rychlejšího zápisu – cizí klíče jsou definovány pro zabezpečení integrity databáze. Pokud budou data z HIST tabulek zobrazována, budou vytvořeny pouze takové indexy, které zajistí rychlé zobrazení dat (např. podle primárního klíče původní tabulky). Historická tabulka by měla obsahovat unikátní sloupec s hodnotami generovanými pomocí Identity – tento sloupec může nebo nemusí být nastaven jako primární klíč. V HIST tabulkách je např. opakovaně zapisována informace o jedné zakázce vždy, když jsou informace v hlavním záznamu editovány. Zápisy do historických tabulek můžeme v principu provádět dvěma způsoby: 1. prostřednictvím triggerů 2. z uložených procedur Pro potřeby PS jeme využívat druhý způsob, tedy vytváření historie prostřednictvím uložených procedur.

8.2. Vrstva aplikačního serveru Ve vrstvě aplikačního serveru je vytvořeno několik komponent, jako např. komponenty pro práci s databází, GSM bránou, odesílání pošty apod. V rámci tohoto dokumentu nepovažujeme za vhodné provádět podrobný návrh všech komponent pokrývajících celou požadovanou funkcionalitu PS. Na obrázku je zobrazena ukázka rozhraní jedné z komponent, konkrétně komponenty pro práci s databází MS SQL.

23

8.3. Vrstva webového prohlížeče 8.3.1.

Design oken

Jako základní barva pozadí jednotlivých oken je použita systémová barva tlačítek dle nastavení MS Windows BUTTONFACE (#ECE9D8). Všechny ostatní prvky mimo DataGridu mají zachovánu standardní barvu popředí, pozadí i textu. Tlačítka v oknech jsou situována doprava nahoru, zarovnaná buď svisle nebo vodorovně. Každé okno musí mít nadpis, který určuje, jaká část aplikace je spuštěna. Popisky (Labels) jednotlivých polí jsou zarovnány pod sebe na levý okraj. Pole, která nejsou editovatelná mají nastavený atribut ReadOnly na hodnotu True. Aby bylo možné kopírovat texty z jednotlivých polí pro využití ClipBoard, je ponechána hodnota Enabled = True. Pokud je to možné, je vhodné signalizovat povinná pole změnou atributů popisky – tučným fontem a fontem odlišné barvy (modrá barva Navy). Okno aplikace je otevíráno do okna, ve kterém nejsou běžné prvky prohlížeče – menu, toolbar, adress bar apod. Aplikace se tedy je tvářit jako opravdová aplikace.

Na obrázcích je znázorněn rozdíl designu aplikací v klasickém okně prohlížeče – levý obrázek a v okně bez navigačních prvků – pravý obrázek. Mimo jiné získáme také větší prostor pro vlastní aplikaci. Samozřejmě musíme mít na paměti, že zkušenější uživatelé snadno otevřou aplikaci i do obvyklého designu – tomuto však nelze zamezit a proto se tímto problémem nejeme zabývat. 8.3.2.

Navigace mezi okny

Uživatel může prostřednictvím aplikačního menu v horní části okna prohlížeče zobrazit v drtivé většině případů seznam záznamů. V seznamu je možné změnit řazení záznamů klepnutím na záhlaví seznamu. Nad seznamem jsou pole pro definici filtrů, pomocí kterých můžeme vyhledat jen určitou sadu záznamů (odfiltrovat nežádoucí záznamy). Hledání je možné buď přes přesné zadání hodnoty určitého sloupce v seznamu, nebo pomocí části textu, jak je znázorněno na ilustrativním obrázku. Řazení i vyhledávání (filtrace) záznamů je možné přes všechny sloupce ze seznamu. Opakovaným klepnutím na záhlaví sloupce dojde ke změně pořadí řazení (vzestupně, sestupně).

24

Pokud je v seznamu více záznamů, je zobrazen vždy pouze omezený počet záznamů a další sada je zobrazena na vyžádání uživatelem (tzv. stránkování záznamů). Stránkování může být v některých formulářích záměrně potlačeno, v tom případě, pokud seznam obsahuje více záznamů, než je možné zobrazit na monitoru je nutné v okně rolovat. Ze seznamu je možné přejít na detail záznamu. Detail nerozlišuje režim zobrazení a editace – pokud má uživatel práva editovat záznam, je rovnou v režimu editace. Samozřejmě pokud má pouze právo záznam zobrazit (např. protože je záznam aktualizován v Heliosu a do PS je pouze přebírán), nemůže záznam editovat a všechna pole jsou pouze pro čtení. Případné mazání (rušení) záznamů je realizováno opět z detailu záznamu a není možné provést jej ze seznamu. Vyvolání formuláře pro založení nového záznamu je možné buď ze seznamu, nebo z detailu záznamu. Přechod mezi formuláři seznamu, nového záznamu a detailu je schématicky znázorněn na obrázku. Mezi určitými formuláři je možné přecházet přímo do detailu určitého záznamu – např. do detailu zakázky jsou přímé odskoky z přípravy podkladů pro fakturaci i mzdy. 8.3.3.

Kontroly dat ve formulářích

Ve formulářích je prováděno několik typů kontrol ještě před odesláním na server, aby se zmenšila zátěž serveru a také snížila komunikaci po síti. Typické kontroly jsou: 1. kontrola zadání povinných hodnot 2. zadaná data jsou správného datového typu 3. zadaná data jsou v povolených rozsazích Všechny kontroly jsou realizovány prostředky .NET frameworku. Na každé stránce, kde jsou realizovány kontroly, je umístěn objekt ValidationSummary. Umístěn je vždy poblíž tlačítek pro odeslání dat. Jako barva textu (ForeColor) je nastavena červená (Red), volba ShowMessageBox je nastavena na True. DisplayMode zůstává BulletList. Jednotlivé kontroly jsou poté vytvořeny tak, aby byly zobrazovány do společného místa (Display = None). 8.3.4.

Odlišnost pro prohlížeč Mozilla Firefox

Vzhledem k vlastnosti prohlížeče Mozilla Firefox musí uživatelé pracující s tímto prohlížečem zadat při spuštění aplikace své uživatelské jméno a heslo. Firefox tyto informace neumí převzít z MS Windows, ale požaduje jejich zadání. Poté je předá aplikačnímu serveru IIS a uživatel je dále pracovat bez nutnosti znovu je zadávat. Mozilla Firefox neumožňuje vyvolání modálního dialogu pomocí funkce ShowModalDialog. Proto jsou editační okna otevřena do okna, které vypadá jako modální dialogové okno, nicméně pokročilý uživatel se dokáže přepnout do základního okna aplikace.

25

99.. ZZaabbeezzppeeččeenníí ppřřííssttuuppuu kk ddaattůům m Uživatelé PS budou pracovat s aplikací prostřednictvím internetového prohlížeče. V rámci PS není samostatná evidence a správa hesel uživatelů, ale přihlašovací údaje jsou přebírány z LDAP databáze (Centrální správa uživatelů). Pokud v rámci práce na PC již jsou přihlášeni do domény BA, je jejich uživatelské jméno z MS Windows použito jako přihlašovací jméno do PS a uživatelé tedy již nemusí zadávat své přihlašovací údaje. Pokud nejsou přihlášeni do domény (např. pracují na počítači u zákazníka), vynutí si zadání přihlašovacích údajů již webový server (při spuštění PS v prohlížeči) a provede ověření zadaných údajů proti informacím, které si PS převzal z databáze LDAP. S PS tedy vždy pracují již ověření uživatelé. Díky tomu není nutné řešit v rámci PS ukládání a ochranu hesel uživatelů, čímž se zvýší zabezpečení celého systému. Pro definici seznamu uživatelů, kteří mají mít přístup k PS, je v rámci LDAP vytvořena speciální skupina uživatelů. Pouze pro tuto skupinu uživatelů je v rámci nastavení virtuálního adresáře na IIS povolen přístup k PS a seznam uživatelů z této skupiny je přebírán do databáze uživatelů PS. V rámci PS je možné provést zablokování uživatelského účtu, které způsobí okamžité znemožnění práce daného uživatele (další databázový příkaz již neje proveden).

9.1. Uživatelské role Uživatelské role zprostředkovávají uživatelům přístup k jednotlivým funkcionalitám PS. K jaké funkcionalitě PS má mít uživatel přístup, závisí na jemu přidělených uživatelských rolích. Uživatel může mít přiděleno více rolí najednou, v průběhu času se může přidělení rolí měnit a samozřejmě mu také nemusí být přidělena žádné role – v takovém případě nemůže s PS pracovat, stejně jako kdyby nebyl vůbec uživatelem aplikace. Zařazování uživatelů do jednotlivých rolí je prováděno v rámci PS a není přebíráno z centrální databáze LDAP. Zařazování je možné provádět buď z formuláře detailu uživatele (jako je znázorněno na obrázku), nebo obdobným způsobem je možné v detailu role přidávat a odebírat jednotlivé uživatele do dané role. Seznam rolí je pevně spojen s funkcionalitou PS a není možné jej měnit uživatelsky, je definován dodavatelem PS. Stejně tak není možné uživatelsky měnit, které činnosti smí provádět ta která role, i toto je zabudováno v aplikaci a případná změna vyžaduje zásah do zdrojového kódu aplikace či do nastavení, které není přístupné uživatelům.

9.2. Přístup k zakázkám Každý uživatel má nadefinovaný seznam zakázek, se kterými může pracovat. Přiřazené role jsou platné pro všechny zakázky, není možné provést individuální změnu pro jednu zakázku (tedy pokud je uživatel Personalistou a Velitelem objektu, pak má obě tyto role na všechny přiřazené zakázky a není možné, aby na některých zakázkách vystupoval v roli Personalista a na některých v roli Velitel objektu). Definice seznamu přiřazených zakázek se provádí opět ve formuláři detailu uživatele, případně v detailu zakázky je možné určit, kteří uživatelé mají mít k dané zakázce přístup. Vzhledem k hierarchii zakázek (která je popsána v kapitole 7.1 Hierarchie zakázek v Heliosu) má uživatel přístup i do zakázek podřízených přímo přiřazené zakázce – manažer zakázky tedy přiřazením

26

své zakázky získá přístup i do ostatních podřízených zakázek automaticky. Pokud tedy v zobrazeném příkladu zadáme přístup uživateli do zakázky 90162, získá automaticky přístup i do dalších sedmi zakázek.

9.3. Přístup uživatele k zaměstnancům Jak bylo uvedeno v kapitole 10.10 Kmenová zakázka, má každý zaměstnanec přiřazenu kmenovou zakázku. A každý uživatel má nadefinován seznam zakázek, se kterými může aktivně pracovat. Díky kombinaci těchto dvou základních údajů získáme seznam zaměstnanců, se kterými může uživatel PS pracovat – může pracovat s těmi zaměstnanci, kteří mají jako svou kmenovou zakázku určenu jednu ze zakázek, do kterých má uživatel PS přístup. Takového zaměstnance může uživatel použít při zadávání docházky, může pro něj zpracovávat mzdy, může vyplňovat jeho personální údaje či další personální evidence (např. nepřítomnosti) – opět podle toho, v jaké uživatelské roli je uživatel zařazen a zda tedy má oprávnění danou funkcionalitu PS použít. Samozřejmě musí být možné při pokrývání plánů použít i zaměstnance, kteří spadají pod jiného manažera. V takovém případě však nemůžeme zaměstnance použít rovnou, ale musíme požádat o jeho zapůjčení.

9.4. Zapůjčování zaměstnanců V případě, kdy zjistíme že potřebujeme mít k dispozici zaměstnance od jiného manažera, musíme se s tímto manažerem domluvit na zapůjčení zaměstnance. Tato domluva není řešena v rámci PS, ale je řešena např. telefonicky. PS pouze umožní náhled na volné zaměstnance na jiných zakázkách. Pokud druhý manažer souhlasí se zapůjčením svého zaměstnance, musí v PS vytvořit zápůjčku zaměstnance, kde uvede datum platnosti zápůjčky (od – do) a cílovou zakázku, na kterou tohoto zaměstnance půjčuje. Jako žádající manažer musíme zapůjčení zaměstnance na naší zakázku schválit – dokud není zapůjčení schváleno, není zapůjčení platné a může být zrušeno půjčujícím manažerem. Pokud zapůjčení akceptujeme, máme zaměstnance po zadanou dobu k dispozici jako svého kmenového zaměstnance. Oba manažeři, jak půjčující tak i cílový budou mít na hlavní stránce PS příznak, že mají nějakého zaměstnance na dosud neschválené zápůjčce a že je tedy nutné operaci dokončit. PS automaticky zruší všechny zápůjčky, které nebudou schváleny cílovým manažerem před začátkem platnosti zápůjčky. Aby bylo možné realizovat zápůjčky operativně i v případě, kdy není manažer zaměstnance dostupný, budou moci celou agendu se zapůjčováním provádět také dispečeři zakázek a to plnohodnotně (nabízet k zapůjčení i přijímat zapůjčené). U každého zaměstnance je možné zobrazit historii zapůjčení a případně zrušit zapůjčení, které dosud nebylo akceptováno cílovým manažerem. Nový manažer nemá právo jakkoli pracovat s dalšími informacemi zaměstnance, pouze jej může použít pro pokrývání pracovních plánů.

27

1100.. ZZaam měěssttnnaannccii V současné době jsou personální a mzdové agendy zpracovávány v PMS jak v BA, tak v BAS. Protože se jedná o dvě nezávislé společnosti, jsou i databáze nezávislé a stejná osoba zaměstnaná u obou společností má u každé jiné osobní číslo a další evidenční údaje. Také je samozřejmě možný případ, kdy je člověk zaměstnaný jen u jedné z těchto firem nebo kdy v průběhu času opakovaně nastoupí do jedné z těchto společností. Z toho důvodu musí PS umožňovat vedení více pracovních úvazků k jedné osobě v průběhu času a minimálně dva souběžně – BA a BAS. Pokud osoba nemá pracovní úvazek v BA, není považována za zaměstnance, ale z pohledu PS se jedná o brigádníka a neje pro něj možné vést další agendy v rámci PS. V rámci pracovního poměru musí být evidována celá řada informací dle platné legislativy. Pro potřeby PS se je část z nich přebírat, některé pro potřeby výpočtů mezd (např. základní mzdu, hodinový průměr, denní či týdenní fond pracovní doby, počet dní dovolené) a jiné pro další práci se systémem či pro zobrazení informací v rámci portálu (např. měřenkový list). Některé informace budou zadávány v PS a budou přenášeny zpět do PMS (nepřítomnosti).

10.1. Typy pracovních poměrů V rámci BA může mít zaměstnanec v podstatě 3 typy pracovního poměru: Hlavní pracovní poměr (HPP), Dohoda o provedení práce (DPP) a Dohoda o pracovní činnosti (DPČ). Každý z pracovních úvazků je zpracováván odlišným způsobem, proto zde nyní zmíníme hlavní rozdíly mezi těmito typy poměrů. Typy zaměstnaneckých poměrů jednotlivých zaměstnanců budou přebírány z PMS. 10.1.1. Hlavní pracovní poměr (HPP) Základní typ pracovního poměru v BA. Zaměstnanec pracující na tento typ má daný denní nebo týdenní fond pracovní doby. Pokud má zadaný týdenní, je přepočten pro potřeby PS jednoduchým vydělením pěti (obvyklý počet pracovních dnů v týdnu) čímž je získán denní fond pracovní doby, tedy počet hodin v pracovním dnu, které by měl odpracovat a za které by měl dostat odměnu. Protože je běžné, že zaměstnanci BA odpracují více hodin, než kolik odpovídá jejich fondu pracovní doby, je nutné tyto hodiny nějakým způsobem zaměstnanci proplatit. S ohledem na platnou legislativu a požadavky BA je PS navrhovat řešení pro tyto hodiny tak, aby oficiální výkazy BA (docházkové listy zaměstnanců) odpovídaly legislativě (přestávky v práci, počet odpracovaných hodin, přestávka mezi směnami atd.), ale aby všechny odpracované hodiny byly proplaceny. Zaměstnanci mohou dostávat část mzdy proplacenu ve formě takzvaně daňově uznatelných příplatků, tj. příplatků, ze kterých zaměstnavatel ani zaměstnanec neodvádí sociální pojištění, zdravotní pojištění a daň z příjmu. Jedná se např. o příspěvek na dopravné, ošatné, ubytování. V rámci BA je stanoveno, jaká je maximální výše těchto příspěvků pro jednoho zaměstnance a tím je určena maximální hodnota příplatků, kterou by zaměstnanci mohli dostávat. Někteří zaměstnanci mají stanovenu hodnotu příplatků, na které jsou jim skutečně propláceny, které tedy dostávají v rámci své běžné měsíční mzdy. V rámci PS je možné nadefinovat seznam daňově uznatelných Možné příspěvky v rámci SČR příspěvků, tedy příplatků pro zaměstnance. U každého je Druh příspěvku Max částka možné zadat, jaká je maximální hodnota v rámci BA. Pro Ošatné 1500 každého zaměstnance je možné zadat dvě hodnoty tohoto Dopravné 600 příspěvku - zda má na něj nárok a jaká je maximální individuální výše tohoto příspěvku. Druhá hodnota je standardně nabízena ve výši, v jaké je zadána pro celou firmu v definici příspěvku, ale je ji možné snížit pro konkrétního zaměstnance (pokud není změněna, je stejná jaká je stanovena pro celou firmu). Rozdíl mezi nárokovou a maximální výší příspěvku slouží k vyplacení části odměny zaměstnanci náhradním způsobem mimo běžnou mzdu Potom je na základě hodinové mzdy zaměstnance (převzaté z PMS) určitý počet hodin převeden na příspěvek. Např. pokud má zaměstnanec možnost dostat až 600 Kč jako příspěvek na dopravné a má hodinovou mzdu 50 Kč, potom můžeme 12 hodin vyplatit

28

jako příspěvek na dopravné. Tento způsob propočtu PS navrhovuje na základě přímého požadavku BA na funkcionalitu PS. Zaměstnanec samozřejmě může trvat i na tom, že bude dostávat pouze běžnou mzdu a přesouvání části odměny do těchto příspěvků nechce používat. V tom případě je maximální možná hodnota i nárok buď nula (nedostává žádné příspěvky), nebo budou stejné kladné číslo (do výše dané v rámci BA předchozím nastavením) – v tom případě bude dostávat konstantní příspěvek a odpracované hodiny bude dostávat obvyklým způsobem případně jako přesčasy. Různé způsoby jsou pro názornost naznačeny v tabulce. První zaměstnanec dostává pouze příspěvek na ošatné, žádné hodiny nejsou placeny formou příspěvků. Druhý dostává konstantní příspěvek a část hodin ve formě příspěvku. Třetí zaměstnanec nemá nárok na žádný příspěvek, ale může jej dostat jako náhradu za odpracované hodiny. Nastavení příspěvků pro zaměstnance Jméno Druh Nárok Max. výše Vysvětlení Zaměstnanec první Ošatné 200 200 Každý měsíc dostane příspěvek na ošatné ve výši 200 Kč navíc k odměně za práci Dopravné 0 0 Příspěvek na dopravné nebude dostávat nikdy Zaměstnanec druhý Ošatné 200 1500 Každý měsíc dostane automaticky příspěvek na ošatné ve výši 200 Kč navíc k odměně. Dalších až 1300 Kč příspěvku na ošatné může dostat jako náhradní způsob zaplacení odměny za odpracované hodiny (např. 26 hodin po 50Kč) Dopravné 300 600 Každý měsíc dostane automaticky příspěvek na dopravné ve výši 300 Kč navíc k odměně. Dalších až 300 Kč příspěvku na dopravné může dostat jako náhradní způsob zaplacení odměny za odpracované hodiny (např. 6 hodin po 50Kč) Zaměstnanec třetí Ošatné 0 1500 Automaticky nedostává žádný příspěvek na ošatné, ale až 1500 Kč může dostat jako náhradní způsob zaplacení odměny za odpracované hodiny (např. 30 hodin po 50Kč) Dopravné 0 600 Automaticky nedostává žádný příspěvek na dopravné, ale až 1500 Kč může dostat jako náhradní způsob zaplacení odměny za odpracované hodiny (např. 12 hodin po 50Kč)

Obdobným způsobem jako jsme nyní zmínili příspěvek na ošatné, ubytování a dopravné, je možné zaměstnancům dávat stravenky. I zde je určena maximální možná výše stravenky, nicméně její hodnota je stanovena zákonem. Dále je zákonem stanoveno, že část hodnoty stravenky si hradí zaměstnanec (v současné době 45%). Při používání stravenky jako náhrady za vyplacení odměny tedy musí být zaměstnanci zaplaceno jen 55% nominální hodnoty stravenky (např. pro stravenku ve výši 80Kč dostane zaměstnanec ve skutečnosti jen 44Kč. Rozdíl částek (zde tedy 36Kč) je zaměstnanci ihned stržen jako příspěvek zaměstnance na stravenky. Pracovník tedy dostane 80 Kč stravenku, která ale ve skutečnosti představuje pouze 44 Kč odměny navíc. V rámci PS tedy je evidováno, v jaké výši má zaměstnanec stravenky dostávat a na jaký počet jich má nárok. Dále je uveden maximální počet, které může měsíčně dostat. PS si interně přepočte, jakou hodnotu má ve skutečnosti stravenka pro zaměstnance a s touto potom pracuje. Samozřejmě pro vyplácení příspěvků ve formě stravenek i ostatních jsou stanovena další pravidla – nárok na příspěvek závisí na tom, zda zaměstnanec odpracoval určitý počet hodin ve směně (např. stravenka může být vyplacena pouze za směny delší než 3,5 hodiny). Stejně tak se nárok na příspěvky krátí podle nepřítomnosti (pokud má např. měsíc 20 pracovních dní a zaměstnanec má 5 dní dovolenou a dalších 5 dní nemoc, může zaměstnanec dostat pouze poloviční příspěvky - odpracoval 10 z 20 dnů). Možné příspěvky tedy závisí na

29

oficiálním počtu odpracovaných směn v poměru k maximálnímu počtu směn v měsíci (podrobněji je tato problematiku popsána později). 10.1.2. Dohoda o provedení práce (DPP) Zaměstnanec pracující na tento druh pracovního poměru může dle aktuálně platné legislativy odpracovat pro jednoho zaměstnavatele maximálně 150 hodin za rok. Protože praxe v BA ukazuje, že zaměstnanci s tímto typem poměru odpracují více hodin, musí PS pracovat pro zaměstnance s tímto poměrem na žádost BA nestandardně. DPP se v portálu PS neřeší. Eviduje se pouze skutečně odpracované hodiny a sazba za hodinu dohodnutá, skutečně proplacená hodinová sazba a počet hodin uvedených na DPP řeší mzdová účtárna. S ohledem na nutnost měnit počet odpracovaných hodin v podstatě pro každého zaměstnance, je v rámci PS provedena pouze první část výpočtu (jakou odměnu by zaměstnanec měl dostat) a je vytvořena tisková sestava, kde je uvedena tato částka spolu s dalšími informacemi (kolik hodin v rámci roku již zaměstnanec podle evidence v IIS vyčerpal). Žádné další výpočty ani evidence pro zaměstnance s tímto druhem pracovního úvazku PS neprovádí. Podklady pro výpočet mezd pro tento typ úvazku nejsou prozatím přenášeny z PS do PMS automaticky, ale jsou zpracovávány ručně . 10.1.3. Dohoda o pracovní činnosti (DPČ) Dohoda o pracovní činnosti umožňuje zaměstnanci odpracovat omezený počet hodin (v současnosti cca polovinu úvazku proti HPP). Jinak se jedná o obdobu HPP i v tom smyslu, že zaměstnanec může dostávat stravenky, příspěvek na ošatné, ubytování, dopravné atd. PS tedy je s tímto typem pracovního poměru zacházet stejně jako s HPP.

10.2. Pracovní poměr v BAS Jak jsme již uvedli dříve, většina zaměstnanců BA má ještě DPČ v BAS. S ohledem na problémy s legislativou jsou prostřednictvím tohoto pracovního poměru propláceny zaměstnancům hodiny navíc, které není možné jednoduše proplatit v BA, neboť by při jejich proplacení docházelo mimo jiné k navýšení průměru a navíc by vznikal velký nepoměr mezi základní mzdou a odměnami. Proto je část mzdy v rámci fondu pracovní doby proplacena přímo prostřednictvím BA a část prostřednictvím BAS. Podrobněji způsob evidence podkladů pro výpočet mzdy bude popsán později, nicméně na tomto místě je nutné si uvědomit, že všechny údaje evidované pro potřeby výpočtu mzdy v BA musejí být evidovány i pro pracovní poměr v BAS, včetně definice všech možných použitelných příplatků apod. Ještě je nutno zmínit i variantu, kdy zaměstnanec nemá pracovní poměr u BA, ale má jej u BAS. Takový zaměstnanec není považován za zaměstnance BA, ale je s ním zacházeno v rámci PS jako s brigádníkem z externí agentury poskytující brigádníky (podrobněji je toto opět popsáno dále v tomto dokumentu). Zaměstnancem je tedy jen takového člověk, který má u BA alespoň jeden ze tří výše uvedených typů pracovních poměrů.

10.3. Způsoby odměňování zaměstnanců Každý zaměstnanec má v rámci svého pracovního úvazku dohodnutý způsob odměňování. Dvěma základními způsoby odměňování v BA je buď hodinová mzda nebo měsíční mzda. V případě hodinové mzdy dostává zaměstnanec odměnu vypočtenou jako počet skutečně odpracovaných hodin vynásobenou dohodnutou hodinovou sazbou. V případě měsíční mzdy dostává zaměstnanec každý měsíc určitou částku. Protože však existuje několik variant zacházení se skutečně vykázanými hodinami, budou nyní popsány jednotlivé varianty podrobněji. Ve skutečnosti totiž existuje z pohledu PS v podstatě 5 způsobů přípravy podkladů pro výpočet mezd. • Hodinová mzda – obvyklý způsob odměňování např. pro strážné. Podle počtu odsloužených hodin dostávají mzdu musí odpracovat fond pracovní doby. • Měsíční mzda – zaměstnanec má dohodnutu měsíční výši mzdy. Podle povahy práce se buď může jednat o tzv. THP zaměstnance nebo o strážné s tímto způsobem výpočtu mzdy. Tuto skupinu tedy dále můžeme rozdělit na: o THP pracovník – obvykle dostává svou měsíční mzdu a odpracované hodiny nejsou v rámci PS evidovány. Nicméně i takový zaměstnanec může odpracovat v rámci tohoto svého úvazku určitý počet hodin. Hodiny může odpracovat buď ve své běžné pracovní době, nebo mimo běžnou pracovní dobu. Podle toho, který způsob je častější, můžeme opět tento způsob rozdělit na dva:

30

ƒ

o

Vykázané hodiny jsou standardně již zahrnuty v měsíční odměně – takový pracovník většinou odpracuje evidované hodiny ve své běžné pracovní době a nedostává za ně žádnou odměnu navíc ƒ Vykázané hodiny jsou navíc k měsíční odměně - takový pracovník většinou odpracuje evidované hodiny mimo svou běžnou pracovní dobu a tyto hodiny tedy dostane zaplaceny navíc Strážný – z nějakého důvodu nemá hodinovou mzdu, ale plánují se pro něj hodiny služby a poté se vykazují skutečně odsloužené hodiny. Pokud takový zaměstnanec odpracuje méně hodin, než činí jeho měsíční fond pracovní doby, stejně dostane sjednanou paušální odměnu (pro jednoduchost zde neuvažujeme nepřítomnosti). Pokud odpracuje více hodin, opět mohou nastat dva případy: ƒ Hodiny navíc dostane zaměstnanec zaplaceny na základě přepočtené hodinové sazby ve formě přesčasů nebo odměn (prémií) ƒ Hodiny navíc zaměstnanec nedostane proplaceny, dostane jen dohodnutou měsíční paušální částku. Tento případ v současné době zřejmě není v BA použit, nicméně jeho výskyt nemůžeme do budoucna vyloučit

Pracovní úvazek

Hodinová mzda

Měsíční mzda

Strážný Odpracovaná doba je standardně evidována

Hodiny navíc proplácet

THP Odpracovaná doba není standardně evidována

Hodiny navíc neproplácet

Vykázané hodiny jsou standardně propláceny

Vykázané hodiny nejsou standardně propláceny

Ze zde uvedených variant je tedy zřejmé, že pro zaměstnance placené měsíční částkou je nutné v rámci PS zvolit, jakým způsobem mají být vykázané hodiny zahrnuty do výpočtů podkladů pro mzdy. Podle těchto pravidel bude PS zacházet s hodinami při návrhu docházkových listů a návrhu prémií a přesčasů, nicméně příslušný manažer zaměstnance vždy může provést ruční korekci. Např. zaměstnanec standardně pracuje jako THP a v PS má nastaveno, že vykázané hodiny jsou zahrnuty v měsíční odměně (standardně nejsou propláceny). Pracovník odpracuje jeden den v průběhu své běžné pracovní doby 8 hodin jako strážný na zakázce A. Druhý den po své pracovní době odpracuje navíc 4 hodiny na zakázce B. PS automaticky hodiny vykázané na zakázky A i B bude ignorovat při výpočtu podkladů pro mzdy. Manažer ale může určit, že 4 hodiny ze zakázky B mají být zaměstnanci proplaceny a musí určit, zda formou přesčasů či odměn (prémií). V tomto případě by tedy manažer zadal do podkladů pro mzdy + prémie 4hodiny * 50Kč = 200Kč Pro zaměstnance s paušální měsíční mzdou tedy je nutné zadat způsob standardního zpracování hodin evidovaných v rámci PS a dále je možné zadat maximální počet přesčasů v jednom měsíci, které zaměstnanci může PS použít pro výpočet odměny. Legislativa totiž omezuje počet přesčasových hodin odpracovaných zaměstnancem a proto nelze všechny hodiny automaticky platit formou přesčasů. Nicméně pokud je pro daného zaměstnance, jemuž mají být hodiny navíc propláceny, zadáno povolené použití přesčasů, použije je PS a v podkladech pro výpočet mezd bude figurovat položka Přesčasy. Tyto přesčasy budou také zohledněny v oficiálních pracovních výkazech. Ostatní hodiny navíc budou proplaceny zaměstnanci dle pravidel popsaných dále v tomto dokumentu.

31

10.4. Nepřítomnosti V rámci PS je možné pro jednotlivé zaměstnance evidovat nepřítomnosti v práci. Nepřítomnosti může do PS zadávat řada uživatelů – personalistka, asistentka, dispečer, manažer zakázky. Všechny nepřítomnosti evidované v rámci PS budou zkracovat fond pracovní doby, pokud je to dáno charakterem nepřítomnosti. Při zadání nepřítomnosti je nutné určit zaměstnance, vybrat ze seznamu typ nepřítomnosti, určit datum od kdy je nepřítomnost platná. Nepovinně je možné zadat datum konce nepřítomnosti (např. pro nemoc nemusí být datum konce známo). Pokud je datum začátku i konce shodné, je možné upravit počet hodin nepřítomnosti s možností jednoduše zadat půlden. Pokud nepřítomnost zasahuje do více dnů, vždy jsou zahrnuty celé dny a není možné zadat hodiny či půlden. Ve formuláři pro zobrazení detailních informací o zaměstnanci je možné zobrazit seznam evidovaných nepřítomností a je možné odsud vyvolat formulář pro zadání nepřítomnosti k tomuto zaměstnanci. Při zadání nepřítomnosti v případě, že zaměstnanec má už naplánované směny, je vytvořena e-mailová zpráva s popisem kolizí (tj. zakázka, datum a čas a popis kolize), kde je zaměstnanec naplánován. Tato zpráva je odeslána manažerovi a dispečerovi příslušné zakázky a ten musí ručně provést potřebné korekce – PS sám neprovádí žádné změny v plánech.

Seznam nepřítomností v aktuálním měsíci je předáván z PS do PMS vždy současně s podklady pro výpočet mezd po uzavření podkladů pro mzdy manažerem. Nepřítomnosti jsou tedy evidovány pouze v PS a do PMS zadávány být nesmějí, pokud nemá dojít k nekonzistenci evidencí. Seznam důvodů nepřítomnosti má vazbu na důvody nepřítomnosti v PMS, protože pro výpočet mezd je důležitý konkrétní důvod nepřítomnosti (je rozdíl mezi dovolenou, nemocí a např. neomluvenou absencí). V PS je možné definovat seznam důvodů a každý z nich musí mít vazbu na položku v PMS.

10.5. Prohlídky PMS V rámci PMS je sledováno několik termínů prohlídek. Tyto budou zobrazovány v PS na záložce Prohlídky PMS. Budou pouze přebírány z PMS a nebude je možné editovat v rámci PS. PS bude hlídat vypršení termínů a bude signalizovat překročení termínu (Datum + Počet měsíců). Na obrázku je ukázka zvýraznění termínu, u kterého má být sledována doba expirace a který již je v nastaveném termínu upozornění.

Z PS je možné zobrazit přehled všech zaměstnanců, kterým již vypršela expirace jednoho ze sledovaných záznamů, nebo kde doba expirace je v nejbližším období (standardně v nejbližších 30 dnech).

32

10.6. Dovednosti V rámci PS je možné evidovat pro každého zaměstnance přehled o jeho dovednostech, které mohou být vyžadovány při práci na zakázkách. Je vytvořen číselník s jednotlivými záznamy, jež chceme evidovat (např. jazykové vybavení, pes pro strážní službu). V detailu zaměstnance je v příslušné záložce možné zadávat aktuální hodnoty, tedy zda dovednost má či nikoliv, a doplnit krátkou poznámkou. Zde není možné žádným způsobem hlídat termíny, protože dovednost zaměstnanec buď má, nebo nemá.

10.7. Fotografie zaměstnance Pro každého zaměstnance je možné zadat do PS jeho fotografii. PS je tuto fotografii zobrazovat ve formuláři se zobrazením detailních informací o zaměstnanci. Velikost fotografie je 200px na šířku a 250px na výšku. Fotografie je uložena do databáze PS a neje pro běžné uživatele dostupná jinak, než prostřednictvím PS.

10.8. Poznámky k zaměstnanci K zaměstnanci je možné připojit poznámku. PS automaticky evidue datum vytvoření a autora poznámky. Poznámka může být až 2000 znaků dlouhá.

10.9. Měřenkový list Z PMS jsou přebrány při spuštění PS základní míry zaměstnance, např. pro uniformu, obuv atd. Tyto míry je možné zobrazit na jedné ze záložek ve formuláři pro zobrazení detailu kmenových dat zaměstnance. .

33

10.10.Kmenová zakázka Každý zaměstnanec BA má definovánu kmenovou zakázku. Na této zakázce jsou evidovány nepřímé náklady na daného zaměstnance, proto má každý zaměstnanec přiřazenou právě jednu kmenovou zakázku, a to takovou, na které odpracuje převážnou část fondu pracovní doby – typicky 100%. Kmenovou zakázku je možné změnit vždy k prvnímu dni v měsíci. Zadání změny je provedeno v PS a je přeneseno do PMS. Změnu kmenové zakázky je možné zadat kdykoliv před datem požadované změny. Pokud bude docházet ke změně kmenové zakázky v rámci zakázek daného manažera (tj. manažer trvale přesouvá pracovníka na jinou svou zakázku), PS nevyžaduje provedení žádné další činnosti (schválení změny). Pokud půjde o převod pod jiného manažera zakázky, musí tento převod schválit i budoucí manažer kmenové zakázky (princip převzetí pracovníka). Schválení musí provést před požadovaným datem změny, jinak přesun zaměstnance není proveden a požadavek je zrušen.

10.11.Půjčování jiným manažerům Zatímco změna kmenové zakázky představuje změnu trvalou, zapůjčování zaměstnance jinému manažerovi řeší případ, kdy manažer není schopen obsadit zakázku svými lidmi a musí si je vypůjčit od jiného manažera, tato změna je dočasná a nemá vliv na přiřazenou kmenovou zakázku. Pro podporu této činnosti nabízí PS při obsazování plánu pracovníky jako jednu z možností i přehled zaměstnanců jiných manažerů, kteří by potencionálně mohli na zakázce pracovat, protože nejsou v požadované době alokováni na jiných zakázkách. Manažer nebo dispečer se poté mohou telefonicky spojit s manažerem nebo dispečerem příslušného zaměstnance a dohodnout si jeho zapůjčení na konkrétní dobu. PS podporuje pouze proces vypůjčení a navrácení pracovníka dohadovací proces probíhá mimo PS. Proces akceptace zapůjčení je obdobný jako proces přijetí při změně kmenové zakázky pracovníka, tj. pokud jde o půjčení od jednoho manažera k druhému, musí půjčující manažer nabídnout pracovníka cílovému manažerovi a ten musí zapůjčení přijmout před okamžikem zahájení zápůjčky. Pokud nedojde ke schválení zápůjčky, je dohodnutá zápůjčka automaticky zrušena. Při zapůjčení musí půjčující manažer určit dobu zapůjčení, nelze provádět půjčování na dobu neurčitou (bez zadání koncového data). V případě předčasného ukončení zapůjčení může cílový manažer změnit datum konce. Nemůže však datum konce prodloužit – takový případ se musí řešit jako nová zápůjčka. Zaměstnanec může mít v podstatě neomezený počet zápůjček v průběhu času, v jeden okamžik však pouze jednu platnou – nelze jej paralelně půjčit na více zakázek, ani jej nelze půjčovat dále dalším manažerům. PS žádným způsobem neomezuje délku zápůjčky. Po dobu zapůjčení nedochází ke změně kmenové zakázky, v rámci účetnictví tedy všechny náklady na zaměstnance budou účtovány na jeho kmenovou zakázku.

10.12.Pracovní úvazky a parametry pro mzdy Pro zpracování podkladů pro mzdy jsou v systému vedeny potřebné parametry, které je možné rozdělit do několika skupin: • Zákonné parametry – jsou definovány zákonem a při zpracování docházky a výpočtu parametrů pro mzdy musí být zohledněny. Jedná se o: o Maximální počet hodin odpracovaných za týden – počet hodin, které může jeden pracovník maximálně odpracovat v rámci kalendářního týdne. ƒ Současná hodnota: 48 hodin. o Minimální trvání přestávky na jídlo a oddech – počet minut, kolik minimálně musí trvat přestávka na jídlo a oddech. Přerušení práce kratší, než je tato doba, nelze počítat jako přestávku na jídlo a oddech. ƒ Současná hodnota: 30 minut. o Počet minut, po jejichž uplynutí musí být povinná přestávka – počet minut práce, po jejichž uplynutí nejpozději musí následovat přestávka na jídlo a oddech. Přestávka může nastat i po uplynutí menšího počtu minut. Přestávka nesmí být čerpána na začátku ani na konci pracovní směny. ƒ Současná hodnota: 360 minut. o Nepřetržité volno v týdnu – počet hodin, po který má pracovník nepřetržité volno v rámci týdne. ƒ Současná hodnota: 30 hodin. o Povinná přestávka mezi dvěma směnami – počet hodin, které musí u pracovníka uplynout mezi ukončením pracovní směny a nástupem na směnu následující. ƒ Současná hodnota: 12 hodin.

34

Minimální odpracovaná doba pro nárok na stravenku – minimální počet hodin odpracovaných v rámci jednoho dne, který zakládá pracovníkovi nárok na stravenku za tento den. ƒ Současná hodnota: 3,5 hodiny. o Příplatky za práci mimo běžnou pracovní směnu: ƒ Příplatek za noční směnu ƒ Příplatek za denní směnu o víkendu ƒ Příplatek za noční směnu o víkendu ƒ Příplatek za denní směnu ve svátek ƒ Příplatek za noční směnu ve svátek Pro každý typ příplatku se budou evidovat následující údaje: ƒ Základ pro výpočet – uvede se, zda se příplatek počítá z hodinové nebo z průměrné mzdy. ƒ Procento navýšení – hodnota v procentech, o kterou se zvýší hodinová resp. průměrná mzda (např. hodnota 10 znamená zvýšení o 10 %). Konkrétní hodnoty jednotlivých parametrů jsou dány zákonem a předpokládá se jejich změna pouze výjimečně (po změně zákona). Globální parametry – vycházejí ze směrnic a nařízení BA a jsou společné pro všechny pracovníky. Jedná se o: o Nominální hodnota stravenky – běžná nominální hodnota stravenky, která je poskytována pracovníkům společnosti. o Maximální částka ošatného – maximální částka, která je pracovníkům společnosti poskytována jako příspěvek na ošacení. o Maximální částka příspěvku na ubytování – maximální částka, která je pracovníkům společnosti poskytována jako příspěvek na ubytování. o Maximální částka dopravného – maximální částka, která je pracovníkům společnosti poskytována jako příspěvek na dopravu. Parametry jsou koncipovány jako „defaultní hodnoty“ – pokud není u konkrétního pracovníka specifikováno jinak, dostane tuto částku (tento počet stravenek). Vzhledem k tomu, že může docházet v rámci určitých skupin pracovníků k odchylkám od těchto parametrů (např. regionálním – v Praze může být příspěvek jiný než např. v Plzni), umožní aplikace změnit u specifikovaných skupin pracovníků libovolný z těchto parametrů. Předpokládáme, že ke změnám těchto parametrů dochází po uplynutí delších období a tyto změny by měly souviset se změnou nebo vydáním směrnice či nařízení. Personální parametry – jsou definovány pro každého pracovníka zvlášť a je možno je dále rozdělit do následujících podskupin: o Parametry vycházející z pracovní smlouvy konkrétního pracovníka. Jedná se o: ƒ Denní úvazek pracovníka BA – hodnota denního úvazku (v hodinách) pracovníka ve společnosti BA. ƒ Hodinová mzda pracovníka BA – hodnota hodinové mzdy (v Kč) pracovníka ve společnosti BA. ƒ Průměrná mzda pracovníka BA – hodnota průměrné mzdy (v Kč) pracovníka ve společnosti BA. ƒ Denní úvazek pracovníka BAS – hodnota denního úvazku (v hodinách) pracovníka ve společnosti BAS. ƒ Hodinová mzda pracovníka BAS – hodnota hodinové mzdy (v Kč) pracovníka ve společnosti BAS. ƒ Průměrná mzda pracovníka BAS – hodnota průměrné mzdy (v Kč) pracovníka ve společnosti BAS. Změna těchto parametrů je možná pouze se změnou pracovní smlouvy, příp. s podepsáním jejího dodatku. Tyto parametry budou přebírány z PMS. o Měsíční parametry. Jedná se o: ƒ Počet nárokových stravenek za příslušný měsíc. ƒ Nároková částka příspěvku na ošacení vyplacená pracovníkovi za příslušný měsíc. ƒ Nároková částka příspěvku na bydlení vyplacená pracovníkovi za příslušný měsíc. ƒ Nároková částka příspěvku na dopravu vyplacená pracovníkovi za příslušný měsíc. o

•

•

35

Tyto parametry mají charakter veličiny proměnné pro každý měsíc. Vyjadřují stav jednotlivých příspěvků, na které má pracovník nárok. o Parametry, které určuje nadřízený pracovníka. Jedná se o: ƒ Maximální počet stravenek pro vydání pracovníkovi – počet stravenek, které lze maximálně vydat pracovníkovi. ƒ Maximální částka ošatného pro uplatnění odpracovaných hodin – maximální částka příspěvku na ošacení, kterou lze použít pro pokrytí části odpracovaných hodin. Hodnotu parametru lze nastavit v rozmezí 0 až maximální hodnota, která může být pracovníkovi poskytnuta (viz globální parametry výše). ƒ Maximální částka příspěvku na ubytování pro uplatnění odpracovaných hodin – maximální částka příspěvku na ubytování, kterou lze použít pro pokrytí části odpracovaných hodin. Hodnotu parametru lze nastavit v rozmezí 0 až maximální hodnota, která může být pracovníkovi poskytnuta (viz globální parametry výše). ƒ Maximální částka příspěvku na dopravu pro uplatnění odpracovaných hodin – maximální částka příspěvku na dopravu, kterou lze použít pro pokrytí části odpracovaných hodin. Hodnotu parametru lze nastavit v rozmezí 0 až maximální hodnota, která může být pracovníkovi poskytnuta (viz globální parametry výše). Tyto parametry mají charakter veličiny konstantní v rámci určitého časového období (např. rok, kvartál, …). Jejich změnu může provádět nadřízený pracovníka prakticky libovolně (např. po dohodě s pracovníkem). Rozdíl této hodnoty a hodnoty nárokové lze použít pro pokrytí části odpracovaných hodin. Každý z parametrů je opatřen obdobím platnosti, což umožní bez vlivu na chod systému v předstihu provádět změny, které jsou dopředu známy (např. zahájení platnosti nového zákona nebo směrnice apod.).

10.13.Přebírání dat Pro zaměstnance jsou přebírána data o jeho pracovních úvazcích a také o dalších parametrech, které je nutné sledovat pro potřeby výpočtu docházky a podkladů pro mzdy. Podrobně jsou tyto parametry pospány v kapitole 18 Podklady pro mzdy

36

1111.. ZZáákkaazznnííccii Pod pojmem zákazníci rozumíme v rámci projektu PS skupinu firem, které jsou odběrateli služeb poskytovaných BA. Seznam zákazníků je přebírán z Heliosu a v PS je možné k zákazníkům evidovat řadu informací navíc. Základní informace o zákazníkovi je možné zobrazit na první ze záložek formuláře detailu zákazníka. Základní informace jsou pouze pro čtení. Zákazníka není možné v PS založit, musí být nejprve založen v Heliosu a v rámci přebírání dat dojde k vytvoření zákazníka i v PS. Pro zákazníka je možné v PS nastavit číselnou řadu (knihu), v rámci které Helios čísluje faktury tohoto zákazníka. Tuto výchozí číselnou řadu je možné změnit buď při rozdělování faktur, nebo udělat výjimku pro určitou zakázku. Dále je možné pro zákazníka určit, jaký je maximální počet položek na jedné faktuře. PS nepovolí na jednu fakturu umístit více položek, než je uvedeno zde (pokud chceme umožnit neomezený počet, zadáme hodnotu nula nebo pole necháme prázdné). Pro některé zákazníky se provádějí ještě další kumulace v rámci tisku faktur. Výsledný počet položek na vytištěné faktuře může být výrazně menší než je hodnota parametru počtu položek na faktuře.

Protože zákazníci mají různé požadavky ohledně vystavování faktur za služby ze strany BA, je možné pro každého zákazníka definovat řadu parametrů týkajících se fakturace. Na obrázku je znázorněna záložka definice podkladů pro fakturaci. Vybrané hodnoty jsou nastaveny jako výchozí pro zákazníky a uživatel PS je může změnit.

11.1. Fakturační položky a statistická zakázka Z Heliosu jsou přebírány fakturační položky, které mohou být použity v jednotlivých zakázkách – číselník TabKmenZbozi. Pro každého zákazníka je možné definovat ke každé fakturační položce statistickou zakázku. Jde o další identifikátor položky, která je určena pro identifikaci fakturační položky při dalším zpracování v informačním systému zákazníka. Pro každého zákazníka je možné definovat, zda se mají statistické zakázky předávat do položek faktur v Heliosu, odkud by byly předávány zákazníkům. Statistická zakázka by v případě této volby byla vkládána do pole poznámka k položce faktury na začátek před běžnou poznámku. U zákazníka jsou zobrazeny všechny fakturační položky, které jsou převzaty z Heliosu. Příznak ukazuje, zda-li je daná položka použita alespoň v jedné ze zakázek daného zákazníka (sloupec Použito). Tyto položky jsou zařazeny na začátku seznamu, dále jsou zařazeny položky aktuálně nepoužité. Položky jsou dále seřazeny podle registračního čísla.

37

11.2. Způsob fakturace Pro některé zákazníky je vytvářena jedna faktura pro všechny zakázky za fakturační období, pro jiné je vytvářeno faktur několik. PS bude na základě volby připravovat podklady pro fakturaci tak, aby byla většina podkladů rozdělena do faktur správně. V případech, které nebude možné rozdělit automatizovaně, bude mít uživatel v roli Finanční kontrolor možnost provést ručně přerozdělení položek do jednotlivých faktur – podrobněji je tato funkcionalita popsána v kapitole 0 Po zkontrolování správnosti podkladů pro fakturaci dané zakázky a případném doplnění extra položek může manažer nastavit podklady pro fakturaci jako uzavřené. Toto provede buď změnou příznaku na první záložce formuláře pro přípravu faktur, nebo je možné tento příznak hromadně nastavit pro vybrané zakázky daného manažera (každý manažer je muset tento krok udělat pro své zakázky). Po nastavení příznaku již není možné provádět žádné změny v podkladech pro fakturaci, které byly do dané faktury zahrnuté. Manažer zakázky však může tento příznak zrušit a otevřít tak znovu fakturu pro změny. Otevření fakturace je možné až do doby, než je faktura předána do kontrolingu. Po předání do kontrolingu může v případě potřeby Finanční kontrolor vrátit fakturaci zpět manažerovi zakázky tím, že zruší příznak Předáno do kontrolingu. Pokud však již od Finančního kontrolora byla faktura předána do Heliosu, může jí (ve výjimečných případech a po ověření, že faktura byla odstraněna z Heliosu) znovu obnovit administrátor. Tento případ je zmiňován pouze jako krajní možnost, kdy je až po zaúčtování faktury objevena chyba v podkladech (chybné částky položek apod.). Příprava podkladů pro fakturaci finančním kontrolorem 11.2.1. Rozdělovat faktury na paušální položky a ostatní Protože někteří zákazníci mají delší schvalovací řízení některých došlých faktur, požaduje BA dílčí vytváření faktur například zvlášť pro paušální platby (u kterých odběratel nemá důvod ke složitému schvalování, protože tyto platby jsou v podstatě konstantní) a zvlášť pro ostatní položky, u kterých dochází ke schvalování oprávněnou osobou na straně odběratele. PS tedy automaticky rozdělí paušální platby do samostatné faktury. 11.2.2. Rozdělovat faktury podle čísel objednávek ve fakturačních položkách Pro každou fakturační položku v rámci zakázky je možné zadat číslo objednávky zákazníka (podrobněji viz dále), na základě které BA poskytuje danou službu. Protože někteří zákazníci nepovolují přijmout fakturu, která by obsahovala fakturační položky z více objednávek, je při použití této volby fakturace připravena tak, aby na každé faktuře byly pouze položky pro jednu objednávku zákazníka.

38

11.2.3. Nerozdělovat podle zakázek a produktů Na základě čísel zakázek nejsou faktury nijak děleny (nejsou děleny podle zakázek ani nadřízených zakázek). Faktura je celková – souhrnná. Může se uplatnit pouze pravidlo o počtu položek na faktuře, pokud je vyplněn parametr pro maximální počet položek faktury. 11.2.4. Rozdělovat faktury podle zakázek Pro každou zakázku je vytvořena samostatná faktura. Pro zákazníka je navrženo tolik faktur, kolik má zakázek k fakturaci. Tato volba je opakem volby Rozdělovat faktury podle nadřízených zakázek 11.2.5. Rozdělovat faktury podle nadřízených zakázek Protože nadřízené zakázky slouží v podstatě k regionálnímu členění zakázek, BA požaduje pro některé zákazníky rozdělování faktur podle jednotlivých oblastí. Zde tedy dostaneme nikoliv rozdělení podle zakázek, ale sdružení faktur podle nadřízených zakázek přes "podřízené" zakázky jednotlivých zákazníků. Tato volba je opakem proti volbě Rozdělovat faktury podle zakázek 11.2.6. Rozdělovat faktury podle produktů Pro každý produkt je vytvořena samostatná faktura. Jsou tedy sdruženy produkty z jednotlivých zakázek od daného zákazníka. V tomto případě můžeme ještě pro jednotlivé produkty určit číselnou řadu faktur (z Heliosu), která je přiřazena pro vytvořené faktury a na základě které později Helios přiřadí faktuře její číslo. 11.2.7. Kombinace parametrů rozdělování fakturačních položek Jednotlivé volby rozdělování je možné kombinovat. Pokud např. máme dvě zakázky a pro každou máme dvě objednávky, pak můžeme dostat až čtyři různé způsoby rozdělování faktur: 1. Vše na jednu fakturu – pak zvolíme nerozdělovat faktury 2. Každá zakázka na jinou fakturu – pak zvolíme rozdělování podle zakázek 3. Každá objednávka na jinou fakturu (bez ohledu na zakázku) – pak zvolíme pouze rozdělování podle čísel objednávek 4. Každá objednávka na jinou fakturu (se zohledněním dělby podle zakázek) – pak zvolíme současně rozdělování podle čísel objednávek i podle zakázek

11.3. Četnost fakturace Pro některé zákazníky není běžná paušální fakturace prováděna měsíčně, ale je prováděna v delším intervalu (jednou za dva měsíce, čtvrtletí, pololetí nebo rok). V rámci PS je možné určit četnost fakturace a termín vystavování faktur (na začátku fakturovaného období, na konci nebo jinak). Protože pro zákazníka mohou vzniknout i jiné položky k fakturaci než paušální (např. výjezdy), je možné určit, zda tyto položky budou běžně fakturovány na konci měsíce, nebo zda budou tyto položky zahrnuty do faktur až v okamžiku fakturace paušálních položek v daném intervalu. Např. se zákazníkem dohodneme čtvrtletní fakturaci napojení na PCO s tím, že je faktura vystavována vždy uprostřed druhého měsíce. Ale pokud by došlo k výjezdu zásahového vozidla, budou takové faktury vystavovány každý měsíc. V takovémto případě bychom zvolili nastavení dle připojeného obrázku. 45 dní představuje jeden a půl průměrného měsíce, tedy prostředek druhého měsíce ze čtvrtletí. Pokud bychom chtěli nastavit vystavení faktury ještě před začátkem období (např. faktura je vystavena vždy v předchozím měsíci se splatností do začátku daného období), můžeme zadat záporný počet dní. Příklad pro vystavování faktur vždy v polovině předchozího měsíce pro měsíční fakturaci je na obrázku.

39

Jednotlivé položky pro fakturaci pro zákazníka jsou shromažďovány v PS na základě podkladů z jednotlivých zakázek i v případě, že jsou schváleny manažery zakázek a do fakturace se promítnou až v době, která je určena tímto nastavením. Do Heliosu budou přenášeny vždy celé faktury, nebudou posílány průběžně položky z jednotlivých faktur.

11.4. Seznam zakázek Pro zákazníka je možné zobrazit seznam jeho zakázek a z tohoto seznamu je možné přejít do formuláře detailu dané zakázky.

11.5. Soubory K zákazníkovi je možné připojit libovolný počet souborů. Protože se zákazníkem mohou být dohodnuty podmínky ve formě smluv nebo dodatků ke smlouvám apod., nebo může být zapotřebí k zákazníkovi přiřadit další dokumenty typu formuláře, směrnice, šablony atd. Soubory je možné z PS zobrazit, takže není nutné řešit ukládání dokumentů vážících se k zákazníkovi na sdílený disk. PS dokumenty ukládá do databáze. Zakládat dokumenty, číst je, nebo je rušit, mohou pouze uživatelé na základě přístupových práv. Pozn.: Soubory je možné připojovat také k jednotlivým zakázkám. U zákazníka by tedy měly být pouze soubory, které nemají přímou vazbu pouze k jedné ze zakázek.

11.6. Poznámky K zákazníkovi je možné připojit libovolný počet poznámek. PS automaticky eviduje datum vytvoření a autora poznámky. Poznámka je navržena na maximálně 2000 znaků.

11.7. Přebírání dat Z Heliosu je přebírán seznam zákazníků z tabulky TabCisOrg, pro které je hodnota sloupce JeOdberatel = 1. Podrobný popis přebíraných dat je v kapitole 19.1.3 Zákazníci

40

1122.. V Výýjjeezzddoovvkkyy Protože je v rámci některých zakázek zapotřebí zajišťovat výjezdy zásahových vozidel, které nezajišťují přímo zaměstnanci BA z divize Mobile Patrols, jsou pro tuto službu najímány externí firmy, tzv. „Výjezdovky“. Tyto firmy potom zabezpečují výjezdy na zakázky v případě potřeby na pokyn dispečinku divize Monitoring BA. S každou Výjezdovkou je dohodnuta sazba za realizované výjezdy na jednotlivých zakázkách a na konci měsíce Výjezdovka zasílá do BA fakturu, kde shrne jednotlivé výjezdy. Tyto výjezdy je nutné evidovat v PS pro zajištění fakturace zákazníkům. Některé Výjezdovky působí pouze v určitém regionu, jiné mají celorepublikovou působnost. Některé tedy spolupracují s BA pouze na jedné zakázce, jiné mohou spolupracovat na realizaci více zakázek. Sjednané podmínky s danou Výjezdovkou mohou být dohodnuty buď na úrovni celé společnosti BA, nebo mohou být odlišné pro konkrétní zakázku. V rámci PS tedy evidujeme seznam Výjezdovek a pro každou z nich je možné evidovat nákupní cenu, za kterou poskytuje služby typu výjezd. Tato evidence je nejen na úrovni Výjezdovky, ale také pro jednotlivé zakázky. Do jednotlivých zakázek budou přebírány nákupní ceny dohodnuté v rámci celé BA, pokud pro konkrétní zakázku nebudou stanoveny odlišné nákupní ceny. V PS jsou evidovány pro konkrétní zakázky výjezdy - která Výjezdovka a kdy výjezd realizovala. Tyto informace využívají manažeři zakázek ke kontrole faktur došlých do BA při schvalování proplacení těchto faktur. Dále je možné na základě počtu výjezdů připravit podklady pro fakturaci zákazníkům.

12.1. Základní údaje Při prvotním naplnění dat PS je ručně vydefinován seznam Výjezdovek, kterými je naplněna databáze PS. Protože v Heliosu není žádným způsobem možné určit, zda je záznam v číselníku organizací výjezdovkou a samozřejmě může nastat i případ, kdy je nutné zaevidovat novou Výjezdovku. PS umožňuje zadat novou Výjezdovku, u které je nutné zadat IČO a název. Přes IČO je následně (po zadání do Heliosu) v rámci přebírání dat z Heliosu svázán příslušný záznam a dojde k přenosu dalších informací o Výjezdovce. Novou Výjezdovku je tedy nutné zadat dvakrát, jednou IČO a Název do PS a podruhé kompletně do Heliosu. Pokud by bylo možné rozlišit v Heliosu Výjezdovky, bylo by možné přebírat i ty, které dosud nejsou v PS, ale již jsou v Heliosu. Tato funkcionalita (přebírání nových Výjezdovek) však není předmětem realizace PS v této fázi.

12.2. Smluvní podmínky V rámci PS je evidována cena, za kterou výjezdovka poskytuje služby typu výjezd. Protože ceny mohou být odlišné pro běžné pracovní dny, víkendy, svátky a ještě mohou být různé pro denní nebo noční dobu, je možné evidovat pro každou službu až 6 různých cen. Ceny se samozřejmě mohou v průběhu doby měnit.

12.3. Seznam zakázek Pro Výjezdovku je možné zobrazit seznam zakázek, na kterých jsou její služby využívány (resp. u kterých mohou být její služby využívány) a z tohoto seznamu je možné přejít do formuláře detailu dané zakázky.

41

12.4. Soubory Obdobně jako k zákazníkovi je možné k Výjezdovce připojovat libovolný počet souborů. Funkcionalita u Výjezdovky je shodná s funkcionalitou u Zákazníka

12.5. Poznámky Obdobně jako k zákazníkovi je možné k Výjezdovce přidat libovolný počet poznámek. PS automaticky eviduje datum vytvoření a autora poznámky. Poznámka může být až 2000 znaků dlouhá.

12.6. Přebírání dat Z Heliosu je přebírán seznam výjezdovek z tabulky TabCisOrg, pro které je hodnota sloupce JeDodavatel = 1 a které jsou evidovány v PS jako výjezdovka. Podrobný popis přebíraných dat je v kapitole 19.1.5 Výjezdovky

42

1133.. A Aggeennttuurryy ppoosskkyyttuujjííccíí bbrriiggááddnnííkkyy Protože společnost BA nemá k dispozici dostatek vlastních kapacit, aby mohla trvale pokrývat veškeré požadavky zákazníků na služby svými vlastními zaměstnanci, spolupracuje s dalšími firmami – tzv. Agenturami, které jí poskytují brigádníky (zaměstnance agentury). Brigádníci vystupují ve vztahu k zákazníkům jako zaměstnanci BA. Z pohledu PS budou zajímaví pouze brigádníci, kteří pracují na postech, u kterých evidujeme skutečnou službu – typicky se tedy jedná o služby divizí Guarding a Bank Security, nicméně v principu takovou službu mohou poskytnout všechny divize. BA má s každou agenturou smluvně dohodnuty podmínky, za kterých Agentura poskytuje brigádníky na jednotlivé zakázky. Nákupní hodinová cena za poskytnutí brigádníka může být individuální pro každou zakázku i pro každého brigádníka. Stejně tak může být dohodnuta individuální cena za obsazení postu (strážný za 80Kč, recepční za 100Kč, …). V rámci PS je možné nadefinovat standardní cenu za brigádníka od Agentury. Dále je možné určit individuální cenu za brigádníka na určitém pracovním postu buď pro konkrétní zakázku, nebo pro všechny ostatní zakázky (na zakázce XY platíme za strážné 100Kč, ale na ostatních jenom 90Kč). V PS jsou evidováni všichni pracovníci dané Agentury a u každého je možné stanovit cenu za hodinu obecně pro všechny zakázky, nebo u konkrétní zakázky je možné zadat odlišnou cenu. Stejně tak je možné pro brigádníka určit různé ceny, pokud by pracoval na různých postech (platí se za něj agentuře jiná cena, pokud pracuje jako strážný a jiná pokud pracuje jako recepční). Cena se nemění v průběhu dne, je tedy stejná bez ohledu na to, zda brigádník pracoval v pracovní den přes den, v noci nebo o svátku. Samozřejmě se cena může měnit v průběhu času. Pro každého brigádníka je nutné v PS evidovat údaje o odsloužených směnách – na které zakázce a kolik hodin sloužil. Tento výkaz slouží k přípravě sestavy pro agenturu, kde je zřejmé, jak velkou částku může agentura fakturovat BA. Na základě těchto informací je možné zkontrolovat, že došlá faktura je v pořádku. V evidenci skutečně odsloužených směn se tedy zadává, který konkrétní brigádník z Agentury odsloužil danou směnu.

13.1. Základní údaje Při prvotním naplnění dat PS je ručně vydefinován seznam Agentur, kterými je naplněna databáze PS. Protože v Heliosu není žádným způsobem možné určit, zda je záznam v číselníku organizací Agenturou a samozřejmě může nastat i případ, kdy je nutné operativně zaevidovat novou Agenturu, bude PS umožňovat zadat novou Agenturu, u které je nutné zadat IČO a název. Přes IČO je následně (po zadání do Heliosu) v rámci přebírání dat z Heliosu svázán příslušný záznam a dojde k přenosu dalších informací o Agentuře. Novou Agenturu tedy je nutné zadat dvakrát, jednou IČO a Název do PS a podruhé kompletně do Heliosu. Jakmile dojde k prvnímu přenosu informací o Agentuře z Heliosu do PS, není již možné v PS změnit IČO a název agentury. Do prvního přenosu dat je možné provádět v těchto údajích změny (např. oprava chybně zadaného IČO agentury). Pokud by bylo možné rozlišit v Heliosu Agentury, bylo by možné přebírat i ty, které dosud nejsou v PS ale již jsou v Heliosu. Tato funkcionalita (přebírání nových Agentur) však není předmětem realizace PS v této fázi. Pro agenturu je možné zadat standardní cenu za pronájem brigádníka. Tato cena je použita vždy, pokud není dohodnuta jiná cena – způsob definice výjimek proti této ceně je popsán v následujících dvou kapitolách. Na následujícím obrázku vidíme, že standardní cena pro brigánníky z této agentury je 80Kč.

43

13.2. Cena služeb BA se může s Agenturou dohodnout, že bude za určité pracovní posty platit jiné ceny, než za ostatní. Například pokud se od Agentury XY berou strážní za 80Kč, může se za recepční platit 100Kč. Tato odlišná cena může platit obecně pro všechny zakázky, nebo ještě může být upravena pro určité zakázky. V tomto příkladu se tedy za recepční obecně platí 100Kč, ale pokud budou pracovat na zakázce ABC, pak budeme agentuře platit 110Kč a za recepční na zakázce DEF budeme platit 120Kč. V rámci PS je možné tento způsob platby zaevidovat poměrně jednoduše. Již máme zadánu standardní cenu za všechny brigádníky. Pokud chceme zadat změnu pro určitý post, určíme, pro který post je změna platná a jaká je upravená cena. Přitom můžeme určit, že je změna platná pouze pro určitou zakázku, nebo zakázku nezadáme a pak platí pro všechny zakázky, které jsme individuálně nenastavili. V příkladu na obrázku vidíme příklad. Standardní cena za brigádníka od agentury je 80Kč. Pokud ale pracuje na zakázce 01284, pak se za něj platí agentuře 105Kč bez ohledu na post, který vykonává. Pro zakázku 07038 je dohodnuta běžná cena 110Kč, ale za post recepční na této zakázce se platí 130Kč a za post velitele směny 115Kč. Za recepční na všech ostatních zakázkách se platí 100Kč. Za velitele směny na ostatních zakázkách se platí také 100Kč.

44

13.3. Brigádníci Pro Agenturu je možné evidovat jednotlivé brigádníky – konkrétní osoby. Pro každého brigádníka jsou evidovány pouze základní informace, protože pro něj nejsou tvořeny podklady pro mzdy ani docházkové listy, jde pouze o informace umožňující identifikaci osob, přípravu jejich pracovních výkazů a přípravu podkladů pro faktury od agentur. Podrobnější popis evidence brigádníků je v kapitole 14 Brigádníci. Každý brigádník může mít stanovenu svou individuální cenu, za kterou jej agentura poskytuje. Tato individuální cena může být určena buď pro brigádníka bez ohledu na post který vykonává, nebo pro konkrétní post (např. pan XY je pro nás pracovat za 115Kč na hodinu, ale pokud je na postu velitele objektu, je za 140Kč). Dále je možné zadat individuální cenu pro určitou zakázku – standardně je za 115Kč, ale pokud pracuje na zakázce ABC, je za 130Kč. Samozřejmě je možné toto i kombinovat. Pokud není cena u brigádníka zadána, pak je přebírána z ceny za daný post (viz předchozí popis), případně za standardní cenu pro celou agenturu (pokud není změna pro daný post). Díky volnosti, kterou PS poskytuje při definici cen jednotlivých brigádníků je snadné obsáhnout varianty od jednoduché (všichni brigádníci jsou za stejnou cenu) až po velmi komplikovanou (brigádník má individuálně dohodnutou cenu pro konkrétní post na konkrétní zakázce). Na obrázku vidíme, že pan Brigádník Antonín v současnosti pracuje za 115Kč. Pokud je na zakázce 01284, pracuje za 120Kč. Pokud je na zakázce 07038, pak je buď za 125Kč, nebo za 130Kč (pokud je na postu velitele směny).

13.4. Seznam zakázek Pro Agenturu je možné zobrazit seznam zakázek, na kterých jsou její služby využívány (resp. u kterých mohou být její služby využívány) a z tohoto seznamu je možné přejít do formuláře detailu dané zakázky.

45

13.5. Soubory Obdobně jako k zákazníkovi je možné k Agentuře připojovat libovolný počet souborů. Funkcionalita u Agentury je shodná s funkcionalitou Zákazníka

13.6. Poznámky Obdobně jako k zákazníkovi je možné k Agentuře přidat libovolný počet poznámek. PS je automaticky evidovat datum vytvoření a autora poznámky. Poznámka může být až 2000 znaků dlouhá.

13.7. Výkazy Přechodem na detail záznamu je zobrazena podrobnější informace o podkladech – výpis konkrétních zakázek a konkrétních postů, na kterých brigádníci z agentury pracovali. Zde je zobrazena v záhlaví celková částka napříč zakázkami, ale manažer zakázek uvidí v seznamu pouze zakázky, do kterých má přístup. Součet hodin a částky v záhlaví tedy nemusí odpovídat součtu jednotlivých řádek tabulky.

Přechodem na detail záznamu zobrazíme podrobnější informace o podkladech – výpisu konkrétních zakázek a konkrétních postů, na kterých brigádníci z agentury pracovali. Zde je zobrazena v záhlaví celková částka napříč zakázkami, ale manažer zakázek uvidí v seznamu pouze zakázky, do kterých má přístup. Součet hodin a částky v záhlaví tedy nemusí odpovídat součtu jednotlivých řádek tabulky.

46

13.8. Aktuální měsíc Na poslední ze záložek je zobrazena podrobnější informace o datech z aktuálního měsíce – zde budou uplatněna stejná pravidla, která byla popsána v předchozí kapitole.

13.9. Přebírání dat Z Heliosu je přebírán seznam Agentur z tabulky TabCisOrg, pro které je hodnota sloupce JeDodavatel = 1 a které jsou evidovány v PS jako Agentura. Podrobný popis přebíraných dat je v kapitole 19.1.4 Agentury

47

1144.. B Brriiggááddnnííccii Jak jsme uvedli dříve v kapitole 13 Agentury poskytující brigádníky, jsou v rámci PS evidováni pro jednotlivé agentury brigádníci. Pro brigádníka v rámci agentury evidujeme pouze základní informace. Pokud je brigádník v průběhu času evidován u více agentur, je pro nás každý z těchto záznamů nezávislý a PS neumožní propojení těchto záznamů. Stejně tak pokud se z brigádníka stane zaměstnanec, neumožní PS žádné propojení evidovaných údajů – jedná se o samostatné evidence. V rámci každé agentury je brigádník evidován pouze jednou. V rámci PS je podstatné v podstatě pouze jméno brigádníka a další údaje (identifikační číslo) pouze usnadní jeho jednoznačnou identifikaci.

Brigádník může pracovat na libovolném počtu zakázek souběžně. Pro každou ze zakázek může být s agenturou dohodnuta individuální cena, která buď závisí na zastávaném postu, na zakázce, nebo je opravdu dohodnuta pouze pro daného brigádníka. Na obrázku je zobrazen příklad, kdy brigádník má individuální dohodnutou cenu 115Kč za hodinu, ale pokud pracuje na zakázce 01284, bude se za něj agentuře platit 120Kč, a pokud bude pracovat na zakázce 07038, pak za něj bude platit 125Kč nebo 130Kč – to pokud by zastával post velitele směny.

Pro brigádníka můžeme zobrazit seznam jeho měsíčních výkazů, kde je průběžně doplňován i výkaz z aktuálního měsíce.

48

Ze seznamu výkazů můžeme pro vybraný měsíc zobrazit podrobný výkaz směn brigádníka. Tento výkaz může sloužit jako podklad pro fakturaci, stejně tak jej může manažer zakázky podepsaný předat brigádníkovi jako potvrzení odpracovaných směn na konci měsíce.

Ve formuláři „Detail brigádníka“ je možné na jedné ze záložek zobrazit podrobné informace o aktuálním měsíci – tento výpis je obsahově shodný s předchozím příkladem, pokud bychom v seznamu vybrali aktuální měsíc.

49

1155.. ZZaakkáázzkkyy Zakázky, o kterých se mluví v této kapitole představují běžné zakázky, zakázky nejnižší úrovně (viz kapitolu 7.1 Hierarchie zakázek v Heliosu). S těmito zakázkami v PS lze pracovat v různých částech různým způsobem a je možno je znázornit následujícím obrázkem: Definice zakázky - Informace z Heliosu - Poznámky - Soubory - Způsob fakturace - Agentury - Výjezdovky - Služby k zakázce (ceník) Manažer zakázky

Práce s plány (Guarding) - Obsazování plánů - zaměstnanci - agenturami Manažer zakázky

Změny v plánech (Guarding) - Zachycení skutečnosti - nástup do směny - ukončení směny - anomálie - Evidence brigádníků - Neodsloužené směny - nefakturovat - fakturovat Dispečer, Manažer zakázky

Zakázka Služby k zakázce (Extra) - Výjezdy - autohlídky - revíry - návozy klíčů - Montážní poplatky - Instalace ... Dispečer, Manažer zakázky

Příprava fakturace - Kontrola vykázaných položek - Dodatečné položky Manažer zakázky

Příprava mezd - Kontrola vykázaných položek - Dodatečné položky Manažer zakázky

Přímo z menu je možné vybrat formulář pro konkrétní činnost. Zároveň je pro snadnou navigaci na každém z těchto formulářů odkaz na formuláře ostatních činností na zakázce.

15.1. Definice zakázky Základní údaje o zakázkách jsou přebírány z Heliosu. Zakázku nelze v PS založit. Zakázka musí být založena v Heliosu a následně je převzata do systému PS. V okamžiku, kdy je zakázka přenesena do PS, je možné s ní pracovat. Manažer zakázky doplní fakturační údaje o zakázce, nadefinuje ceníkové (fakturační) položky, přiřadí spolupracující agentury a výjezdovky. Po prvotní definici zakázky je možné v PS sledovat realizaci služeb na této zakázce. Informace zadané v definici zakázky jsou relativně statické. Pracuje se s nimi při vzniku nové zakázky, nebo při změnách v definici zakázky.

15.2. Základní informace Na záložce základní údaje jsou důležité informace o zakázce z Heliosu (číslo, název, zákazník, produkt ..). Tyto údaje jsou zobrazeny pouze pro čtení, nelze je v PS měnit. Pro zakázku je možné určit, zda se má četnost fakturace převzít z nastavení u zákazníka, ke kterému se zakázka vztahuje, nebo je možné specifikovat jinou četnost fakturace, než je definována u zákazníka. Pomocí tohoto nastavení je možné vyřešit například situaci, kdy zákazník má standardně nastavenou čtvrtletní četnost fakturace paušálních plateb, ale na jedné konkrétní zakázce chce fakturovat měsíčně. Samotné určení četnosti fakturace je detailně popsáno v kapitole 11.2 Způsob fakturace. Pro zakázku (pro produkt, který je na zakázce vždy právě jeden) je možné specifikovat číselnou řadu faktur. V podobném duchu jako u četnosti fakturace je možné změnit standardní definici, uvedenou u zákazníka, nastavením na zakázce.

50

K zakázkám, které mají v Heliosu uveden produkt 3 – Monitoring, je možné navíc evidovat přerušení zakázky a informace o Objektu. V případě přerušení zakázky se jedná o přerušení na úrovni PS (v Heliosu je zakázka stále aktivní). Pro přerušenou zakázku jsou pozastaveny fakturace a zastaví se automatická příprava paušálních položek pro fakturaci (paušální platby jsou kráceny o pozastavenou dobu). Případné extra položky (standardně by neměly žádné nastat, výjimečně může jít o opakovanou instalaci vysílače, který byl pro dobu pozastavení odinstalován) jsou kumulovány až do opětovného spuštění zakázky, kdy jsou v prvním období po spuštění nabídnuty do podkladů pro fakturaci. Pro informace o objektu je připravena sada textových polí. Informace o objektu jsou zde jen evidovány, dále se s nimi nijak nepracuje. Komplexní funkcionalitu pro evidenci zařízení obsahuje samostatný modul pro evidenci majetku, který není součástí PS.

15.3. Ceník zakázky Ceníky u zakázky představují seznamy položek, které je možné použít v rámci přípravy fakturačních podkladů v PS. Na to, aby bylo možné položku na zakázce přidat do fakturačních podkladů, musí být zadána v ceníku. Existují tři různé druhy ceníků, kdy v každém se evidují jiné informace a s každým se následně v PS jinak pracuje. 15.3.1. Ceník plán

51

Ceník plán osahuje seznam ceníkových (fakturačních) položek definovaných na zakázce. Položky z ceníku plán jsou specifické tím, že se pro ně plánují pracovníci do směn.

To znamená, že manažer zakázky při zadávání detailu položky musí definovat fakturační položku (post), kterou ceníková položka představuje. Při definici zadá Čas od a Čas do, čímž ji vymezí v rámci dne. Pomocí sady zaškrtávacích polí jednoduchým způsobem určí dny v týdnu, pro které je směna definována. Zaškrtnutím pole Pracovní dny se automaticky zaškrtne pondělí až pátek, jak je naznačeno v příkladu. Označením pole Svátek je možné určit, že směna je plánována také na dny v týdnu, na které připadá den státního svátku. Dále můžeme stanovit počet pracovníků, kteří budou na směnu plánování souběžně. Např. číslo 2 znamená, že ve vygenerovaných plánech je připraven požadavek na dva strážné ve stejném čase. Na každé ceníkové položce je možné zadat číslo objednávky, na základě které je služba společností BA poskytována klientovi. Číslo objednávky je v rámci přenosu do Heliosu přeneseno do účetního systému a je v poli poznámka zobrazeno na faktuře pro klienta. V některých případech je důležité pro konkrétní ceníkovou položku určit jiné středisko než je na zakázce. K tomuto účelu slouží pole středisko. V případě, že je vyplněno do účetního systému, je fakturační položka přenášena s jiným střediskem, než je na zakázce. Dále je nutné zadat datum od a volitelně do kdy je ceníková položka platná. V čase mezi datem od a datem do je pro ceníkovou položku typu plán automaticky generován plán směn. Mimo toto období je položka neplatná a je v PS jen evidována, ale dále se s ní nepracuje a není ji možné používat. K ceníkové položce je možné evidovat poznámku, poznámka je v rozsahu maximálně 500 znaků. Příklad na obrázku představuje ceníkovou položku typu plán. Má definovanou fakturační položku „Běžná ostraha – strážný“. Jedná se o střežení předního vchodu dvěma strážnými 24 hodin denně v pracovní dny, a to i ve svátek, od 1.května 2006. K ceníkové položce typu plán je možné evidovat neomezený počet různých cen. Každá cena je určena časovým vymezením v rámci dne a definicí, pro které dny je platná (je použit stejný výše popsaný způsob definice dnů). Na obrázku je zadána cena pro pracovní dny (pondělí až pátek) od 6:00 ráno do 22:00 večer. Výše ceny má dopad na fakturovanou částku za poskytnutou službu (ostrahu). K ceníkové položce typu plán je možné evidovat neomezený počet přestávek. Přestávky jsou určeny časem od – do. Zaškrtnuté pole Fakturovat přestávku znamená, že přestávka je klientovi fakturována stejným způsobem jako aktivní čas služby. V případě, že pole Fakturovat není zaškrtnuto, jsou o dobu přestávky zkráceny fakturované hodiny. Zaškrtnutím pole

52

Proplatit přestávku se přidává zaměstnanci čas přestávek do odpracovaného času, který je zahrnut do podkladů pro mzdy. V opačném případě zaměstnanec nemá přestávku proplacenou.

Na obrázku je uvedena půlhodinová přestávka od 12:00 do 12:30, která je proplacena zaměstnanci a zároveň je fakturována klientovi.

V případě potřeby je možné k položce typu plán evidovat neomezený počet příplatků. Příplatky představují specifické dovednosti pracovníků požadované zákazníkem k dané službě. V případě, že dovednost není nutně vyžadována (je možná ale ne nutná), příplatek není označen jako povinný. V takovém případě jde do fakturačních podkladů hodinová sazba navýšená o cenu příplatku jen v situaci, že na službu nastoupí člověk s požadovanou dovedností. V případě, že slouží člověk, který dovednost nemá, je fakturována cena bez příplatku.

V případě, že zákazník požaduje příplatkovou dovednost a její cena je zahrnuta již v základní sazbě, zadá se povinný příplatek s nulovou cenou.

53

15.3.2. Ceník paušál K zakázce je možné definovat neomezený počet ceníkových položek typu paušál. Paušální položky jsou specifické tím, že v čase své platnosti jsou automaticky připravovány do podkladů pro fakturaci na základě definice četnosti fakturace paušálních položek u zakázky nebo u zákazníka.

Pro ceníkovou položku typu paušál jsou evidována stejná pole, jako pro položky Ceník plán popsané v předchozí kapitole. Jiným způsobem u paušálních položek definujeme cenu, která je v dobu platnosti právě jedna aktivní. Cena je vždy vztažena k období jednoho měsíce. V rámci paušálu mohou být se zákazníkem domluveny položky, které jsou v ceně tohoto paušálu (výjezdy, návozy klíčů … ). Tyto položky jsou zobrazeny v seznamu jako položky v ceně. Pro ostré výjezdy, které jsou svou povahou specifické, je samostatné zaškrtávací pole pro zahrnutí do ceny paušálu. Na obrázku je znázorněn příklad paušálního Monitorovacího poplatku – TLF za cenu 4500,- Kč. Poplatek je na zakázce platný od 1.5.2006. V ceně poplatku jsou všechny ostré výjezdy, od 20.10.2007 dva „plané“ výjezdy a od stejného data 3 návozy klíčů. Položky v ceně jsou stejně jako cena paušálu vždy vztaženy k období jednoho měsíce.

15.3.3. Ceník extra Ceník extra položek obsahuje ceníkové položky a jejich ceny, které jsou domluveny se zákazníkem. Tyto položky nejsou do podkladů pro fakturaci zahrnuty automaticky. Děje se tak na základě nějakého podnětu. Například výjezd je zaevidován do PS dispečerem a tím podle dalších nastavení (ostrý/planý, počet výjezdů v ceně) je připraven do fakturačních podkladů. Extra položka Instalační poplatek nebo Integrační poplatek musí být přidán ručně manažerem zakázky do podkladů pro fakturaci.

Na obrázku je zadána extra položka Výjezd za cenu 620,- Kč a je možné jej na zakázce použít od 17.11.2006. Tento výjezd je do

54

účetního systému přenesen s číslem střediska 10030011210 a s číslem objednávky 8976857429.

15.4. Agentury Jak již bylo zmíněno v kapitole 13 Agentury poskytující brigádníky, je možno k zakázce připojit agentury, od kterých se používají brigádníci. Agentura může mít dohodnutu standardní cenu napříč zakázkami, ale pro konkrétní zakázku se může s agenturou nastavit jiná cena. Pokud je tedy u agentury v zakázce zadaná cena, je používána tato cena. Pokud cenu zadaná není, je použita cena zadaná na úrovni agentury.

15.5. Ceny za služby agentury S agenturou je možno mít dohodnuté různé ceny za jednotlivé pracovní posty, opět buď na úrovni celé agentury, nebo pro danou zakázku. Pokud máme pro zakázku dohodnuté jiné ceny za obsazení pracovních postů pracovníky agentury, je možno je zaevidovat do PS na příslušné záložce. Pokud použijeme brigádníka z agentury na pracovní post, který nemá uvedenu zvláštní cenu na úrovni zakázky, použije se zvláštní cena agentury v rámci zakázky. Teprve pokud ani tam není stanovena zvláštní dohodnutá cena, použijí se standardní hodnoty z agentury v pořadí pracovní pozice – obecná cena.

15.6. Brigádníci Pro zakázku se eviduje seznam brigádníků z dané agentury. Pro každého z nich se zadává časový úsek, po který je možno jej na zakázce přiřadit do směny. Dále je možno dohodnout pro daného brigádníka zvláštní cenu za práci na zakázce buď obecně, nebo za určitý pracovní post. Při zjišťování ceny brigádníka PS nejprve zjistí, zda má brigádník cenu za daný pracovní post na této zakázce. Pokud ne, pak zda má brigádník cenu pro zakázku. Pokud ne, zjistí, zda je zadána cena za pracovní post na zakázce. Pokud ne, zda je zadána zvláštní cena za agenturu na zakázce. Pokud ne, zda má daný brigádník dohodnutou zvláštní cenu za daný post v rámci agentury. Pokud ne, zda má brigádník dohodnutou zvláštní cenu v rámci agentury bez rozlišení postu. Pokud ne, zda je pro agenturu dohodnuta zvláštní cena za daný post. Pokud ne, použije se standardní cena agentury.

55

Při přidávání brigádníka do agentury jej uživatel vybere ze seznamu brigádníků evidovaných u agentury. Pokud by ještě nebyl v PS evidovaný, může otevřít okno pro přidání brigádníka k agentuře přímo z tohoto výběrového seznamu.

15.7. Výjezdovky Obdobně jako agentury je možno pro zakázku evidovat výjezdovky. Pro každou výjezdovku lze mít v průběhu času dohodnuté individuální ceny za výjezd. Podrobnější informace o výjezdovkách jsme již uvedli v kapitole 12 Výjezdovky

15.8. Soubory Obdobně jako k zákazníkovi, je možné k Zakázce připojovat libovolný počet souborů. Funkcionalita u Zakázky je shodná s funkcionalitou u Zákazníka

15.9. Poznámky Obdobně jako k zákazníkovi, je možné k Zakázce přidat libovolný počet poznámek. PS automaticky eviduje datum vytvoření a autora poznámky. Poznámka může být až 2000 znaků dlouhá.

15.10.Přebírání dat Z Heliosu je přebírán seznam Zakázek z tabulky TabZakazka. Podrobný popis přebíraných dat je v kapitole 19.1.2 Zakázky - TabZakazka.

56

1166.. P Prrááccee ss pplláánnyy 16.1. Tvorba plánů zakázky Plány na konkrétní měsíc vznikají automaticky na základě zadání v zakázce, jak je popsáno v předchozí kapitole. Přístup ke všem vygenerovaným měsíčním plánům je ze záložky „Práce s plány“. Klepnutím na řádek příslušného měsíce se zobrazí přehled detailního plánu pro zvolený měsíc. Každý den v měsíci obsahuje tolik řádků, kolik konkrétních pozic je nutné obsazovat na základě zakázky. Graficky (barevně) pak jsou v jednotlivých řádcích vyznačeny jednotlivé časové úseky: • Úseky, které se nemají obsazovat. • Úseky, které se mají obsazovat a nejsou ještě obsazeny. • Úseky, které jsou již obsazeny, včetně jména přiděleného pracovníka, příp. agentury.

16.2. Obsazení plánů zaměstnanci (plánování směn) 16.2.1. Základní způsob plánování směn Každý vytvořený plán musí manažer zakázky obsadit konkrétními zaměstnanci – plánování směn. Ve formuláři „Plán služeb – přehled“ stiskne tlačítko „Editovat“. Tím se plán služeb přepne do režimu pro úpravy.

57

V tomto režimu je umožněna úprava údajů u jednotlivých dnů. Automaticky je vždy pro každou požadovanou pozici zobrazen řádek s vyplněnými časovými údaji „Od“ a „Do“ pokrývající celou požadovanou směnu. Pokud manažer hodlá obsadit celou směnu jedním pracovníkem, specifikuje ho u příslušného řádku (viz níže). Manažer však může posunout čas začátku nebo konce směny a obsadit konkrétním pracovníkem pouze její část. V takovém případě se automaticky přidají řádky s předvyplněnými časovými údaji tak, aby stále byla obsažena celá požadovaná směna. Příklad – viz obrázek nahoře: Pro pozici „Běžná ostraha – strážný“ je požadována směna od 8:00 do 17:00. Na začátku se v okně zobrazí jeden řádek s vyplněnými údaji „Od“ = 8:00 a „Do“ = 17:00. Manažer upraví začátek a konec směny na „Od“ = 10:00, „Do“ = 15:00 a přiřadí konkrétního pracovníka. Aplikace automaticky přidá na začátek dne neobsazený řádek „Od“ = 8:00, „Do“ = 10:00 a na konec dne neobsazený řádek „Od“ = 15:00, „Do“ = 17:00. 16.2.2. Specifikace pracovníka Každý řádek s částí směny musí být v konečném důsledku obsazen. Aplikace umožní specifikovat pracovníka jedním z následujících způsobů: • Pracovník BA může být určen vepsáním jeho osobního čísla do příslušného políčka. Pokud je číslo nalezeno v databázi pracovníků, doplní se automaticky vedle jeho jméno. Toto pole je dostupné pouze v případě, že je v poli „Agentura“ uvedeno „BA“. • Výběrem z nabídky dostupných pracovníků BA – uživatel a zobrazí se mu dialogové okno pro klepne na tlačítko výběr pracovníka. Do něj se automaticky přenesou časové údaje z políček „Od“ a „Do“. Okno umožní uživateli zobrazit přehled pracovníků podle několika kategorií: o Moji volní lidé s požadovanou kvalifikací – zobrazí seznam pracovníků, kteří mají v požadovanou dobu volno, jsou přímo podřízení aktivnímu uživateli (manažerovi) a mají požadovanou kvalifikaci. o Moji volní lidé bez požadované kvalifikace – zobrazí seznam pracovníků, kteří mají v požadovanou dobu volno, jsou přímo podřízení aktivnímu uživateli (manažerovi), ale nemají požadovanou kvalifikaci. o Moji lidé s nepřítomností – zobrazí seznam pracovníků, kteří jsou přímo podřízení aktivnímu uživateli (manažerovi), ale mají na požadovanou dobu uvedenu nepřítomnost. o Ostatní region – zobrazí seznam ostatních pracovníků ze stejného regionu, jako je obsazovaná zakázka. o Ostatní ČR – zobrazí seznam ostatních pracovníků ze všech ostatních regionů ČR, než je obsazovaná zakázka. Jako první nám je nabídnut seznam pracovníků z kategorie „Moji volní lidé s požadovanou kvalifikací“. Pokud si můžeme vybrat z této kategorie, provedeme její změnu. PS provede nový dotaz na server a zobrazí jeho výsledek – seznam pracovníků v nově vybrané kategorii.

58

•

Uživatel pak může libovolného pracovníka v seznamu označit a stiskem tlačítka „OK“ jej obsadit ke konkrétnímu řádku. Upozornění: Pracovníky z kategorií „Ostatní region“ a „Ostatní ČR“ nelze použít přímo, je nutné nejprve provést jejich zapůjčení, které je podrobněji popsáno v kapitole 10.11 Půjčování jiným manažerům. Obsazení pracovníkem smluvní agentury – pokud je požadavek na obsazení příslušného řádku pracovníkem smluvní agentury (jiné než SecuBAS), uvede uživatel název této agentury. Současně může vyplnit jméno konkrétního pracovníka z této agentury, pokud je známo, nebo uvede speciální položku „neurčeno“. V takovém případě uvede konkrétní jméno pracovníka až dispečer při jeho nástupu na směnu.

16.2.3. Draft plánu Uživatel může rozpracovaný plán průběžně uložit jako draft tlačítkem „Uložit“ a nadále pokračovat v práci (otevřené okno se nezavře) nebo „Uložit a zavřít“ (otevřené okno se zavře). V takovém případě se provedené změny uloží do databáze bez dalších kontrol. Tato tlačítka slouží především k tomu, aby uživatel při delší úpravě plánu nepřišel z důvodu havárie o již provedené změny. Data se ukládají do samostatné tabulky draftů. 16.2.4. Finalizace a kontrola plánu Jakmile uživatel klepne na tlačítko „Finalizovat a zavřít“, proběhnou kontroly vyplněných údajů: • Logická správnost vložených údajů. • Duplicity – pokud byl jeden konkrétní pracovník přiřazen na více pozicích ve stejnou dobu, je tento řádek označen jako chybný. Kontrola se provádí přes všechny existující zakázky, nikoliv pouze pro upravovanou. Jako chybný přitom je označen pouze řádek v aktuálně editovaném plánu. Plán obsahující chyby je možné finalizovat. Manažer zakázky pak musí nejprve chyby odstranit. Finalizovaný plán je uložen do tabulky finalizovaných plánů a pokud byl již předtím uložen do tabulky draftů, je z ní vymazán. Tabulka finalizovaných plánů tak je vždy obsahovat validní plány bez chyb.

16.3. Průběžný zápis skutečnosti 16.3.1. Práce dispečera na začátku směny Na základě vytvořených plánů pracovníci nastupují na jednotlivé směny. Konkrétní nástupy na směnu resp. odchody ze směny hlásí běžným způsobem příslušnému dispečerovi (telefonicky). Dispečer pracuje v aplikaci ve speciální části, která je uzpůsobena specifikům jeho činnosti.

Základní činností dispečera s aplikací je zadávání skutečných nástupů na směny a případných odchodů ze směn a řešení problémových stavů. Okno automaticky zobrazuje s určitým předstihem seznam všech plánovaných nástupů s těmito údaji: datum, plánovaný čas nástupu, zakázka, agentura, pracovník. Dobu předstihu je možno konfigurovat každým dispečerem podle konkrétního stylu práce – např. 5 minut, 15 minut, 30 minut apod. Po nahlášení nástupu pracovníkem dispečer vyhledá pracovníka v seznamu plánovaných nástupů a stisknutím tlačítka provede záznam nástupu. Pokud na plánovanou směnu nastupuje jiný pracovník, může dispečer vybrat a přiřadit jiného pracovníka. Alternativní možností je zápis jména (nebo části klepnutím na tlačítko jména) pracovníka do políčka „Nástup jiného zaměstnance“ a stisknutí tlačítka „Nástup“ – v takovém případě PS prohledá aktuální plány všech zakázek, které dispečer zpracovává. Kritériem prohledávání je: „Hledej všechny plány, kde je plánován nástup v rozmezí plus/mínus jedné hodiny od aktuálního času a kde jméno pracovníka odpovídá zadání“ (není testována pouze exaktní shoda, ale použije se operátor „LIKE“, takže např. pro zadání „nová*“ nalezne i „Novák“, „Nováček“ apod.).

59

PS následně zobrazí dispečerovi zobrazí okno, kde buď je zobrazeno jméno zvoleného pracovníka (v prvním případě) anebo seznam všech nalezených pracovníků (v druhém případě). Vždy je také zobrazen plánovaný čas nástupu. Dispečer může provést následující operace: • V případě seznamu nalezených pracovníků výběr jednoho konkrétního, jehož nástup se je vkládat. Pokud je výsledkem výběru jeden pracovník, je automaticky vybrán. • Volba času nástupu: Dispečer může volit mezi dvěma základními možnostmi: o Plánovaný čas – automaticky se převezme naplánovaný čas nástupu. o Konkrétní čas – dispečerovi se zpřístupní pole pro zadání konkrétního času. Automaticky je vyplněno aktuálním časem počítače, ale dispečer jej může libovolně změnit. • Označení anomálie: V běžném provozu se implicitně počítá s tím, že pracovníci nastupují na směny a odcházejí z nich v naplánovaném čase. Proto pokud byla zvolena možnost „Konkrétní čas“, může dispečer zaškrtnout volbu „Anomálie“. Tím označí nástup jako anomální a ten musí být následně zpracován manažerem. Potvrzením tohoto okna se provede vlastní zápis nástupu do databáze. Do databáze se z důvodu dalších možných statických přehledů zapíší oba časy – čas skutečného nahlášení nástupu (např. 7:47) a čas zvolený dispečerem (např. 8:00). Obdobně může dispečer postupovat v případě, že je nahlášen odchod ze směny, pouze s tím rozdílem, že po uvedení jména stiskne tlačítko „Odchod“. Tato situace však je méně častá, protože pracovníci typicky odchod ze směny nenahlašují, nicméně pokud se tak stane, může dispečer nahlášený odchod zaznamenat. 16.3.2. Automatické ukončování Vzhledem k tomu, že pracovníci typicky nenahlašují odchod ze směny, aplikace disponuje funkcí automatického ukončování. V okamžiku zapisování nástupu na směnu funkce automaticky zkontroluje, zda existuje směna se stejnými parametry (zakázka, pozice), která má plánovaný odchod ve stejnou dobu jako je nástup na zapisovanou pozici. Pokud ano, provede její automatické ukončení na čas nástupu zapisované směny. Tím se pokryjí situace, kdy jeden strážný střídá svého kolegu. Funkce periodicky kontroluje všechny nástupy na směnu, u kterých není uveden odchod. Následně je porovná s odchodem uvedeným na příslušném plánu. Pokud od plánovaného odchodu již uplynula „ochranná doba“, která je specifikována v systému (např. 1 hodina), zapíše automaticky odchod na čas uvedený v plánu. Tím se pokryjí situace, kdy strážný končí směnu, aniž by byl střídán. 16.3.3. Řešení problémů dispečerem Kromě zaznamenávání skutečných nástupů resp. odchodů spočívá práce dispečera v řešení neočekávaných situací. Aplikace přináší dispečerům podporu pro řešení těchto situací, aniž by jejich pozornost zbytečně zatěžovala. Pracovní plocha se ve stanoveném intervalu obnovuje a zobrazuje aktuální data (viz výše). Pokud byl naplánovaný nástup na směnu a ve stanoveném předstihu (např. 5 minut) nebyl ještě nahlášen skutečný nástup, zvýrazní se taková informace v seznamu. Dispečer pak má možnost zjišťovat příčiny a případně zařídit nápravu. PS umožní zadat 2 časy předstihů, viz obrázek výše, a ke každému jinou zvýrazňovací barvu. 16.3.4. Vyřešení anomálií manažerem Všechny anomálie, které dispečer nebyl schopen vyřešit, musí zpracovat manažer zakázky. Ve speciálním pohledu se mu zobrazí všechny nevyřešené anomálie, které se týkají jemu přidělených zakázek. PS automaticky zkontroluje skutečné nástupy na směny a odchody s plánem a v případě, že zjistí nějaké neobsazené úseky (mezery), vytvoří pro ně speciální položku, ve které automaticky vyplní čas nástupu a odchodu podle nalezené mezery a zobrazí tuto položku v seznamu. Manažer musí každou anomálii nějakým způsobem vyřešit a označit jako vyřešenou.

16.4. Kontrola plánů před uzavřením měsíce Před uzavřením skutečných výkazů musí být v PS splněny dvě základní podmínky: 1. Všechny části požadavku zákazníka (plánu) musejí být pokryty vykázanou službou. Pokud nikdo v určitou dobu nesloužil, musí být po tuto dobu v PS zadán NOBODY buď ve variantě FAKTUROVAT nebo NEFAKTUROVAT

60

2.

Nesmějí být žádné anomálie, které manažer zakázky neoznačil jako vyřešené

PS tedy nepovolí uzavřít podklady pro fakturaci ani podklady pro mzdy, dokud tyto dvě podmínky nebudou splněny. V rámci PS je možné zobrazit seznam zakázek, které nejsou připraveny k uzavření.

61

1177.. P Pooddkkllaaddyy pprroo ffaakkttuurraaccii Na základě vykázaných odsloužených hodin, paušálních plateb a dalších extra položek jsou vytvářeny podklady pro fakturaci. V této kapitole se zaměřím pouze na faktury vydané, které vystavuje BA. Tuto činnost lze shrnout do dvou kroků. V prvním připraví manažeři zakázek podklady pro fakturaci, přičemž plně zodpovídají za úplnost dat zahrnutých do fakturace (připraví obsah faktury). Takto připravené podklady v druhém kroku přejdou k finančnímu kontrolorovi, který rozdělí položky k fakturaci do jednotlivých faktur podle dohody se zákazníkem (např. zvlášť paušální položky a ostatní položky, podle nadřízených zakázek atd.).

17.1. Příprava podkladů pro fakturaci manažerem zakázky Podklady pro fakturaci z pohledu manažera zakázky znamenají v podstatě pouze doplnění extra fakturovaných položek, jako např. mimořádné hodiny na základě dohody se zákazníkem (ať už přidání nebo ubrání), mimořádné fakturační položky (sleva nebo přirážka). PS zajistí, že odsloužené služby se v podkladech pro fakturaci objeví automaticky (po případném uzavření anomálií, které bylo popsáno dříve v tomto dokumentu). Automaticky se každý měsíc objevují i paušály, které jsou v daném fakturačním období připraveny k fakturaci. Stejně tak se objeví v PS automaticky některé extra položky typu výjezd, návoz klíčů atd. na základě evidence operátorů a dispečerů atd.. Pokud tedy k zakázce není zapotřebí doplnit extra fakturační položky, může manažer pouze uzavřít podklady pro fakturaci (viz popis v kapitole 17.1.7 - Uzavření podkladů pro fakturaci) bez provedení jakéhokoli úkonu na dané zakázce. 17.1.1. Celkový přehled PS zobrazí podklady pro fakturaci v samostatném okně v několika záložkách. Na první záložce je celkový přehled, který shrnuje informace uvedené na dalších záložkách a představuje aktuální částku připravenou k fakturaci. Na této záložce není možné provádět změny s výjimkou zapsání krátké poznámky (100 znaků). Změny položek je možné provádět na jednotlivých záložkách, případně je nutné upravit podklady v prvotních evidencích (např. docházka).

17.1.2. Standardní položky Na druhé záložce budou zobrazeny standardní položky. Zde mohou být v podstatě dva typy položek. První jsou součty skutečně vykázaných odsloužených hodin strážnými, které jsou sečtené podle fakturačních položek a částek fakturovaných za hodinu. Druhým typem jsou paušální částky, ať už se jedná o paušály za strážní službu, nebo např. za výjezdy.

62

PS umožní paušální a vykazované položky libovolně kombinovat, proto fakturace podle uvedeného příkladu je zcela v pořádku. Na této záložce máme souhrn informací a dopočítané položky z jiných oblastí PS. Jedná se o informace, které jsou převzaty z prvotních evidencí. Zobrazené kumulované údaje nejsou určené pro editaci. 17.1.3. Extra položky Další záložkou jsou Extra položky. Některé z těchto položek jsou opět automaticky připravovány v PS na základě dat zadávaných v jiné části systému – např. pokud operátor zaeviduje návoz klíčů, je tento automaticky přidán do extra položek k fakturaci.

Zde může manažer označit, které položky mají být fakturovány a které fakturovány být nemají. U některých položek je automaticky nastaveno, že se nemají fakturovat na základě definice podmínek smlouvy u zakázky (např. první tři výjezdy jsou v rámci paušálu zdarma, ostré výjezdy se nefakturují atd.). Manažer také může přidávat další extra položky. Přidat může pouze takové položky, které jsou předem nadefinovány u zakázky, nemůže tedy přidávat položky zcela libovolně. Nejprve musí u zakázky povolit použití fakturační položky a teprve následně ji může použít pro konkrétní fakturaci. Tento postup práce je zde zcela záměrný. Nejprve jsou se zákazníkem domluveny služby, které si u BA objednal nebo chce využívat – přitom jsou objednané služby (fakturační položky) přidány do seznamu možných fakturačních položek u zakázky. Manažer následně pro fakturaci přidává jen položky ze seznamu fakturačních položek u zakázky, tedy může fakturovat pouze předem sjednané služby. Manažer může tímto způsobem také zadat mimořádné změny hodin nebo slevy doplněním další fakturační položky – vždy tedy provede změnu fakturace prostřednictvím fakturační položky v této záložce. Extra položky jsou vždy vytvářeny ručně manažerem, který zadá počet jednotek a sazbu za jednotku (zde tedy může změnit jednotkovou cenu). Počet jednotek i cena mohou být i záporná čísla, čímž můžeme v konečném součtu buď ovlivnit počet jednotek za danou fakturační položku, nebo vytvořit novou samostatnou – tohoto využijeme například při zadávání slev. 17.1.4. Extra položky z minulé fakturace Na další záložce jsou pro lepší orientaci manažera zobrazeny extra položky z minulé fakturace, aby se manažer mohl podívat, jaké extra položky byly fakturovány v předchozím období.

63

17.1.5. Přehled minulých faktur Dále je zobrazen informativní přehled všech předchozích podkladů pro fakturaci a poznámky k faktuře. Zde si tedy uživatel je moci připomenout, zda si nezapsal poznámky týkající se přípravy faktur.

17.1.6. Přehled poznámek Na poslední záložce je přehled poznámek k zakázce, kde by opět mohly být informace relevantní pro přípravu fakturace.

17.1.7. Uzavření podkladů pro fakturaci Po zkontrolování správnosti podkladů pro fakturaci dané zakázky a případném doplnění extra položek může manažer nastavit podklady pro fakturaci jako uzavřené. Toto provede buď změnou příznaku na první záložce formuláře pro přípravu faktur, nebo je možné tento příznak hromadně nastavit pro vybrané zakázky daného manažera (každý manažer je muset tento krok udělat pro své zakázky). Po nastavení příznaku již není možné provádět žádné změny v podkladech pro fakturaci, které byly do dané faktury zahrnuté. Manažer zakázky však může tento příznak zrušit a otevřít tak znovu fakturu pro změny. Otevření fakturace je možné až do doby, než je faktura předána do kontrolingu. Po předání do kontrolingu může v případě potřeby Finanční kontrolor vrátit fakturaci zpět manažerovi zakázky tím, že zruší příznak Předáno do kontrolingu. Pokud však již od Finančního kontrolora byla faktura předána do Heliosu, může jí (ve výjimečných případech a po ověření, že faktura byla odstraněna z Heliosu) znovu obnovit administrátor. Tento případ je

64

zmiňován pouze jako krajní možnost, kdy je až po zaúčtování faktury objevena chyba v podkladech (chybné částky položek apod.).

17.2. Příprava podkladů pro fakturaci finančním kontrolorem Po uzavření podkladů pro fakturaci manažery jednotlivých zakázek pro zákazníka provádí Finanční kontrolor kontrolu správnosti fakturace. Zároveň kontrolor provádí rozdělení fakturačních položek do jednotlivých faktur. PS po uzavření všech zakázek daného zákazníka umožní Finančnímu kontrolorovi nahlížet do podkladů pro fakturaci (přitom může kontrolor pracovat v podstatě se shodným formulářem, jaký jsme popisovali v minulé kapitole, jen nesmí provádět žádné změny). Navíc má kontrolor k dispozici formulář, ve kterém jsou zobrazeny všechny fakturační položky z jednotlivých zakázek pro vybraného zákazníka. Fakturační položky jsou automatizovaně rozděleny do jednotlivých faktur na základě nastavení kritérií rozdělování u zákazníka (toto nastavení jsme podrobně popsali v kapitole 11.2 Způsob fakturace). Kontrolor může ručně změnit rozdělení položek do jednotlivých faktur, stejně tak může změnit číselnou řadu pro danou fakturu, na základě které Helios přidělí následně faktuře její pořadové číslo. Kontrolor může zjistit, že jsou v podkladech připravených manažery zakázek chyby. V tom případě může určitou zakázku „odemknout“ a vrátit ji zpět manažerovi k nápravě nedostatků. Po provedení nápravy a uzavření dané zakázky může kontrolor opět pokračovat v práci se zákazníkem. Pokud kontrolor považuje fakturaci zákazníkovi za správnou, může všechny faktury pro daného zákazníka označit k předání do Heliosu (toto je možné provést i hromadně a pro více zákazníků najednou, odpovědnost za správné určení množiny zákazníků je na Finančním kontrolorovi). Po předání do Heliosu je nastaven na všechny faktury zákazníka v PS pomocný příznak a kontrolor již nemůže s fakturací pro zákazníka provádět žádné změny. Ve výjimečných případech může administrátor provést zpětné nastavení tohoto příznaku a kontrolor smí provést nové rozdělení nebo vrácení manažerovi. Administrátor má zodpovědnost za to, že toto provede až po vymazání faktur z Heliosu.

65

1188.. P Pooddkkllaaddyy pprroo m mzzddyy V následující kapitole je popsán mechanismus výpočtu podkladů pro mzdy z reálných dat (skutečné nástupy na službu, odchody ze služby, nepřítomnosti). Graficky celý postup shrnuje následující schéma:

Skutečná docházka

Skutečná docházka

Další hodiny Korigované součty

Oficiální docházka Další hodiny

Další peníze

Uzavření podkladů pro mzdy

Korekce od manažera Mzda na základě ofic. docházky Další mzdové položky Podklady pro mzdy

Vstupem do procesu je skutečná docházka uložená v systému. K těmto údajům může manažer provést korekci hodin na základě vlastního uvážení. Skutečná docházka a korekce hodin jsou pak podkladem pro návrh oficiální docházky. Po schválení oficiální docházky manažer provede uzavření podkladů pro mzdy. V těchto schválených podkladech pak může ještě provádět jednotlivé korekce peněz – příplatky, srážky apod. Výsledné údaje jsou na závěr předány do Heliosu.

18.1. Vstup podkladů pro mzdy Pro výpočet podkladů pro mzdy jsou u každého pracovníka důležité následující údaje: • Hodiny odpracované na denní směně v pracovní den. • Hodiny odpracované na noční směně v pracovní den. • Hodiny odpracované na denní směně o víkendu. • Hodiny odpracované na noční směně o víkendu. • Hodiny odpracované na denní směně ve svátek. • Hodiny odpracované na noční směně ve svátek. Podle způsobu odměňování jednotlivých pracovníků budou data získána různým způsobem: • Hodinová mzda – všechny odpracované hodiny existují v systému v evidenci odpracovaných hodin. Součty hodin v jednotlivých kategoriích aplikace provede automaticky z této evidence a všechny tyto hodiny budou použity pro výpočet podkladů pro mzdy (proplaceny). • Měsíční mzda – pracovník má stanoven měsíční fond pracovní doby a jemu odpovídající paušální měsíční mzdu. o Strážný – všechny odpracované hodiny existují v systému v evidenci odpracovaných hodin. Součty hodin v jednotlivých kategoriích aplikace provede automaticky. Všechny hodiny do výše měsíčního fondu budou použity pro výpočet podkladů pro mzdy (proplaceny). S hodinami odpracovanými nad měsíční fond aplikace naloží dvojím způsobem (podle parametrů konkrétního pracovníka):

66

ƒ

o

Hodiny nad měsíční fond pracovní doby jsou standardně propláceny – hodiny odpracované nad měsíční fond budou automaticky použity pro výpočet podkladů pro mzdy (proplaceny). ƒ Hodiny nad měsíční fond pracovní doby nejsou standardně propláceny – hodiny odpracované nad měsíční fond nebudou automaticky použity pro výpočet podkladů pro mzdy (proplaceny). THP – evidence odpracovaných hodin v rámci měsíčního fondu v systému neexistuje. Počty odpracovaných hodin v rámci měsíčního fondu jsou do systému vloženy ručně pomocí speciálního formuláře. V systému jsou evidovány pouze hodiny odpracované navíc, např. jako záskok na nějaké zakázce. S těmito hodinami aplikace naloží dvojím způsobem (podle parametrů konkrétního pracovníka): ƒ Hodiny nad měsíční fond pracovní doby jsou standardně propláceny – hodiny odpracované nad měsíční fond budou automaticky použity pro výpočet podkladů pro mzdy (proplaceny). ƒ Hodiny nad měsíční fond pracovní doby nejsou standardně propláceny – hodiny odpracované nad měsíční fond nebudou automaticky použity pro výpočet podkladů pro mzdy (proplaceny).

18.2. Úprava podkladů (snížení či zvýšení skutečně vykázaných

podkladů) Uplatněním principů uvedených v předchozí kapitole jsou u každého pracovníka známy tyto údaje: 1. Součty odpracovaných hodin v jednotlivých kategoriích maximálně do výše měsíčního fondu. 2. Součty odpracovaných hodin v jednotlivých kategoriích nad měsíční fond, z toho pak a. Součty hodin, které jsou navrženy pro použití pro výpočet podkladů pro mzdy (jsou navrženy k proplacení) b. Součty hodin, které nejsou navrženy pro použití pro výpočet podkladů pro mzdy (nejsou navrženy k proplacení) Tyto údaje si manažer zakázky zobrazí výběrem příkazu z aplikačního menu. Před započetím procesu návrhu podkladů pro mzdy může také provést ruční korekci těchto navržených údajů. Korekci provede vložením korekčního záznamu, u kterého musí vyplnit následující údaje: • Identifikace pracovníka – automaticky se vyplní podle pracovníka, který je aktuálně zpracováván. • Měsíc a rok – automaticky se vyplní podle měsíce a roku, který je aktuálně zpracováván. • Kategorie hodin – výběr ze seznamu výše vyjmenovaných kategorií • Počet hodin korekce – číslo, které může být jak kladné (manažer přidá pracovníkovi hodiny nad rámec odpracovaných), tak i záporné (manažer ubere pracovníkovi hodiny). • Způsob korekce – způsob, jakým se korekce má projevit. U kladné korekce (přidání hodin) lze vybrat z možností přesčas, prémie, odměna; u záporné korekce (odebrání hodin) se způsob neuvádí. • Důvod korekce – manažer popíše důvody k udělení korekce. Počet korekčních záznamů k pracovníkovi není omezen.

18.3. Návrh docházky Na základě upravených podkladů provede systém návrh docházky pracovníka. K tomuto účelu použije součet hodin podle bodů 1 a 2.a v jednotlivých kategoriích upravený o případné korekce (viz předchozí kapitola). 18.3.1. Docházka BA Na základě plánovacího kalendáře pro zpracovávaný měsíc (zohlednění víkendů a státních svátků) provede PS návrh docházky pracovníka ve společnosti BA. Docházka zohledňuje zákonné předpisy v této oblasti (maximální počty odpracovaných hodin, volno mezi směnami apod.). Při tvorbě docházky se také zohledňují zadané nepřítomnosti – pokud měl pracovník na nějaký den zadanou nepřítomnost (dovolená, nemoc, jiný důvod), není mu na tento den navržena žádná směna.

67

18.3.2. Docházka BAS Pokud se výše uvedeným způsobem nedaří pokrýt všechny odpracované hodiny, vytvoří aplikace docházku pracovníka ve společnosti BAS. Při vytváření této docházky již bere v potaz i docházku pracovníka ve společnosti BA: • Pokud se v docházce pro BA nachází na příslušný den denní směna, je možné v docházce pro BAS uvést pouze noční směnu. • Pokud se v docházce pro BA nachází na příslušný den noční směna, je možné v docházce pro BAS uvést pouze denní směnu. • Pokud se v docházce pro BAS nachází na příslušný den 24hodinová směna, není možné v docházce pro BAS uvést žádnou směnu. Na základě těchto omezení vytvoří aplikace docházku pro společnost BAS. Upozornění: Aplikace vytvoří docházku pro společnost BAS pouze u těch pracovníků, kteří mají nenulovou hodnotu parametru „Denní úvazek pracovníka BAS“. 18.3.3. Prémie Pokud se ani po uplatnění všech výše uvedených postupů nepodaří uplatnit všechny odpracované hodiny pracovníka, všechny neuplatněné hodiny se přepočítají na prémie. Pokud pracovník má nenulovou hodnotu parametru „Denní úvazek pracovníka BAS“, budou tyto prémie vyplaceny v BAS, pro ostatní budou vyplaceny v BA. 18.3.4. Ruční úprava docházky Manažer zakázky může provést následnou úpravu navržených docházek. Pomocí speciálního formuláře může provádět úpravu příchodů a odchodů, zahájení a ukončení přestávek, evidovaných nepřítomností apod. Po každé změně je provedena kontrola správnosti docházky a případné chyby jsou vyznačeny. Po každé změně docházky pro BA jsou následně přepočítány údaje podle odstavců Chyba! Nenalezen zdroj odkazů., 18.3.2, 18.3.3, protože mohlo dojít ke změně vstupních údajů pro tyto výpočty. Po každé změně docházky pro BAS jsou následně přepočítány údaje podle odstavce 18.3.3. 18.3.5. Kontrola docházky Upravená docházka (jak pro BA, tak pro BAS) je podrobena kontrole, zda je v souladu se zákonnými požadavky (maximální počty odpracovaných hodin, přestávky na jídlo a oddych, přestávky mezi směnami atd.). Pokud je zjištěn nesoulad s těmito předpisy, jsou takové docházky označeny jako chybné. Manažer zakázky pak musí provést ruční úpravu těchto docházek. 18.3.6. Ruční vložení mzdových složek Po automatickém návrhu docházky a podkladů pro mzdy může manažer zakázky ještě ručně vkládat některé úpravy mzdových složek (příplatky, srážky). Jedná se o podobné korekční záznamy jako v případě ruční úpravy odpracovaných hodin. Každá ruční úprava mzdové složky musí být založena samostatně a opatřena důvodem jejího vložení. 18.3.7. Uzavření podkladů pro mzdy Jakmile jsou podklady v požadované podobě, manažer zakázky provede jejich uzavření zvolením příslušného příkazu. Uzavřít nelze docházku, která obsahuje chyby. V případě nutnosti lze dodatečně provést odemčení podkladů, změnit požadované parametry a provést následné uzavření. Uzavření podkladů má následující souvislosti: • V případě požadavků na změnu skutečné docházky nesmí být uzavřeny podklady pro mzdy ani fakturace. • V případě požadavků na vkládání dalších hodin a peněz (korekční záznamy) nesmí být uzavřeny podklady pro mzdy. • Pokud jsou uzavřeny podklady pro mzdy, nelze provádět žádné změny.

18.4. Návrh mzdy Po uplatnění postupů uvedených v předchozích kapitolách budou pro každého pracovníka známy následující údaje: • Finalizovaná docházka ve společnosti BA.

68

• • • • •

Počet stravenek Částka ošatného Částka příspěvku na bydlení Částka dopravného. Finalizovaná docházka ve společnosti BAS (pouze u pracovníků, kteří mají definován denní úvazek u společnosti BAS). • Zbylé neuplatněné odpracované hodiny (použijí se k přepočtu na prémie). • Součet hodin korekcí typu „prémie“. • Součet hodin korekcí typu „odměna“. • Součet hodin korekcí typu „přesčas“. Z tohoto pravidla existují následující výjimky: 1. Pokud pracovník ve zpracovávaný měsíc končí pracovní poměr u společnosti BA, není počítána docházka pro společnost BAS. Všechny neuplatněné hodiny se převedou na prémie ve společnosti BA.

69

1199.. R Roozzhhrraanníí nnaa H Heelliiooss 19.1. Data přebíraná z Heliosu do PS Z Heliosu jsou do PS přebírány zejména informace o zakázkách, zákaznících, agenturách a výjezdovkách. Dále je přebíráno několik číselníků. Základní podmínkou pro přebírání dat a udržení konzistence mezi daty v Heliosu a v PS je zachování identifikátorů jednotlivých záznamů v Heliosu beze změny – nesmí tedy dojít ke změně čísla zákazníka, zakázky, atd. 19.1.1. Organizační struktura - TabStrom Organizační struktura je v PS používána pouze pro získání identifikátoru regionu, ve kterém je zakázka realizována. Podrobnější popis organizační struktury je v kapitole 7.2 Organizační struktura. Organizační struktura je přebírána z tabulky TabStrom Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Pro PS neje nastaven primární klíč Cislo Varchar(30) Ano Číselné označení organizační jednotky ve struktuře popsané dříve v tomto dokumentu. V PS je tato hodnota nastavena jako jednoznačný, časově neměnný identifikátor. Tato hodnota tedy nesmí být v Heliosu změněna či odstraněna. Nazev Varchar(40) Ano Název organizační jednotky 19.1.2. Zakázky - TabZakazka Z Heliosu je přebírán seznam zakázek. K zakázkám jsou přebírány pouze informace využívané v PS, řada informací je evidována pouze v PS a nebudou v Heliosu. Při importu zakázek je nutné aktualizovat také strom přístupů jednotlivých uživatelů, neboť může dojít ke změně nadřízené zakázky Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Pro PS neje nastaven primární klíč CisloZakazky Varchar(15) Ano Číslo zakázky přidělené Heliosem. Číslo signalizuje typ zakázky podle principu popsaného dříve. Pro PS je nastaven jako unikátní časově neměnný identifikátor zboží (primární klíč), nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat Nazev Varchar(100) Ano Název zakázky DruhyNazev Varchar(100) Ve většině případů obsahuje adresu realizace zakázky nebo jméno manažera Prijemce Integer Ano Číslo zákazníka z tabulky TabCisOrg (sloupec CisloOrg) Stredisko Integer Číslo organizační jednotky z tabulky TabStrom sloupec Cislo) NadrizenaZak Varchar(15) ID nadřízené zakázky. V PS přímo doplníme informace o nadřízené zakázce a o manažerovi zakázky k podřízenému záznamu Identifikator Varchar(15) Ne Číslo produktu. Vazba na tabulku TabZakIdent.Cislo V PS jeme přebírat do jednoho sloupce i TabZakIdent.Popis Varchar(30) DatumStartPlan Datetime Ne Plánované datum začátku zakázky DatumStartReal Datetime Ne Skutečné datum začátku zakázky DatumKonecPlan Datetime Ne Plánované datum ukončení zakázky DatumKonecReal Datetime Ne Skutečné datum ukončení zakázky Ukoncena Bit Ne Zda je zakázka logicky ukončena (1) nebo ne (0)

70

19.1.3. Zákazníci - TabCisOrg Z Heliosu je přebírán seznam zákazníků z tabulky TabCisOrg, pro které je hodnota sloupce JeOdberatel = 1. Jsou přebírány sloupce: Sloupec Helios CisloOrg

Datový typ Integer

Povinný Ano

Nazev

Varchar(100)

Ano

DruhyNazev

Varchar(100)

Ano

ICO DIC DruhCinnosti

Varchar(20) Varchar(15) Integer

Ne Ne Ne

Místo PostovniAdresa Poznamka

Varchar(100) Varchar(255) Text

Ano Ne Ne

Poznámka Číslo zákazníka, pod kterým jsou často uživatelé zákazníka identifikovat. Pro PS je nastaven jako unikátní časově neměnný identifikátor zákazníka (primární klíč), nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat Název zákazníka, slouží k jeho identifikaci. Ve většině formulářů je v PS zobrazován za číslem zákazníka V Heliosu téměř vždy prázdný, proto v PS je nepovinný Identifikační číslo organizace Daňové identifikační číslo organizace Číslo segmentu. V PS je ukládáno spolu s popisem segmentu v jednom sloupci typu Segment datového typu Varchar(35). Popis segmentu je přebírán z tabulky TabDruhCinnosti, ze sloupce Nazev Varchar(30). Obec z poštovní adresy zákazníka Poštovní adresa Interní poznámka v Heliosu. Do PS je přebíráno pouze prvních 255 znaků (v současnosti v Heliosu maximální délka poznámky činí 127 znaků a obsahuje informaci o změně názvu zákazníka)

19.1.4. Agentury - TabCisOrg Z Heliosu jsou aktualizována data v téměř všech základních informacích o Agentuře z tabulky TabCisOrg na základě shodného IČO. Jsou přebírány sloupce: Sloupec Helios CisloOrg

Datový typ Integer

Povinný Ano

Nazev

Varchar(100)

Ano

DruhyNazev

Varchar(100)

Ano

ICO

Varchar(20)

Ne

DIC DruhCinnosti

Varchar(15) Integer

Ne Ne

Místo PostovniAdresa Poznamka

Varchar(100) Varchar(255) Text

Ano Ne Ne

Poznámka Číslo Firmy. Pro PS je nastaven jako unikátní časově neměnný identifikátor zákazníka, nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat. V PS toto neje primární klíč, protože při ručním zadání neje známa hodnota. Název firmy, slouží k jeho identifikaci. Ve většině formulářů je v PS zobrazován za číslem zákazníka V Heliosu téměř vždy prázdný, proto v PS je nepovinný Identifikační číslo organizace. Na základě této hodnoty je provedeno propojení mezi PS a Heliosem, nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat Daňové identifikační číslo organizace Číslo segmentu. Pro Výjezdovku zřejmě není využíváno. V PS je ukládáno spolu s popisem segmentu v jednom sloupci typu Segment datového typu Varchar(35). Popis segmentu je přebírán z tabulky TabDruhCinnosti, ze sloupce Nazev Varchar(30). Obec z poštovní adresy firmy Poštovní adresa Interní poznámka v Heliosu. Do PS je přebíráno

71

pouze prvních 255 znaků (v současnosti v Heliosu maximální délka poznámky činí 127 znaků a obsahuje informaci o změně názvu firmy) 19.1.5. Výjezdovky - TabCisOrg Z Heliosu jsou aktualizována data v téměř všech základních informacích o Výjezdovce z tabulky TabCisOrg na základě shodného IČO. Jsou přebírány sloupce: Sloupec Helios CisloOrg

Datový typ Integer

Povinný Ano

Nazev

Varchar(100)

Ano

DruhyNazev

Varchar(100)

Ano

ICO

Varchar(20)

Ne

DIC DruhCinnosti

Varchar(15) Integer

Ne Ne

Místo PostovniAdresa Poznamka

Varchar(100) Varchar(255) Text

Ano Ne Ne

Poznámka Číslo Firmy. Pro PS je nastaven jako unikátní časově neměnný identifikátor zákazníka, nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat. V PS toto neje primární klíč, protože při ručním zadání neje známa hodnota. Název firmy, slouží k jeho identifikaci. Ve většině formulářů je v PS zobrazován za číslem zákazníka V Heliosu téměř vždy prázdný, proto v PS je nepovinný Identifikační číslo organizace. Na základě této hodnoty je provedeno propojení mezi PS a Heliosem, nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat Daňové identifikační číslo organizace Číslo segmentu. Pro Výjezdovku zřejmě není využíváno. V PS je ukládáno spolu s popisem segmentu v jednom sloupci typu Segment datového typu Varchar(35). Popis segmentu je přebírán z tabulky TabDruhCinnosti, ze sloupce Nazev Varchar(30). Obec z poštovní adresy firmy Poštovní adresa Interní poznámka v Heliosu. Do PS je přebíráno pouze prvních 255 znaků (v současnosti v Heliosu maximální délka poznámky činí 127 znaků a obsahuje informaci o změně názvu firmy)

19.1.6. Fakturační položky - TabKmenZbozi Seznam fakturačních položek je přebírán z tabulky TabKmenZbozi. Jsou přebírány pouze ty záznamy, které mají hodnotu sloupce SkupZbo číselnou. Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Pro PS neje nastaven primární klíč SkupZbo Varchar(3) Ano Číselný nebo znakový kód skupiny zboží. Do PS budou přebírány pouze takové záznamy, kde je tato hodnota číselná. V PS je použit pouze při přenosu položek faktur do Heliosu RegCis Varchar(30) Ano Pomocný identifikátor záznamu, složený z hodnoty SkupZbo a pořadového čísla v rámci skupiny. Pro PS je nastaven jako unikátní časově neměnný identifikátor zboží (primární klíč), nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat. V PS neje zobrazován Nazev1 Varchar(30) Ano Název skupiny zboží,slouží jako identifikace ve výběrových seznamech v PS.

72

19.1.7. Číselné řady faktur - TabDruhDokZbo Při generování čísel faktur využívá Helios číselné řady, které určují způsob vytvoření pořadového čísla faktury. Pro potřeby PS jeme přebírat pouze několik záznamů Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Pro PS neje nastaven primární klíč RadaDokladu Varchar(3) Ano Tříznakový identifikátor číselné řady. Do PS budou přebírány pouze takové záznamy, kde je tato hodnota 110, 111, 120, 130 nebo 180. Pro PS je nastaven jako unikátní časově neměnný identifikátor zboží (primární klíč), nelze jej tedy nikdy změnit v Heliosu, došlo by k nekonzistenci dat Nazev Varchar(40) Ano Název číselné řady, slouží jako identifikace ve výběrových seznamech v PS. 19.1.8. Produkt - TabZakIdent Z této tabulky je přebírán název produktu. Tato tabulka není fyzicky kopírována do databáze PS, hodnota je ukládána do tabulky s přebíranými daty zakázek Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Pro PS neje přebírán Cislo Varchar(15) Ano Číslo produktu, vazba do TabZakazka.Identifikator Popis Varchar(30) Ano Název produktu 19.1.9. Segment - TabDruhCinnosti Z této tabulky je přebírán název segmentu. Tato tabulka není fyzicky kopírována do databáze PS, hodnota je ukládána do tabulky s přebíranými daty zákazníků, agentur a výjezdovek Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Pro PS neje přebírán. Vazba do TabCisOrg.DruhCinnosti Nazev Varchar(30) Ano Název segmentu

73

19.2. Data předávaná z PS do Heliosu Do Heliosu jsou z PS předávány pouze připravené vydané faktury. Pro tyto potřeby je na straně Heliosu vytvořena dvojice tabulek expInvHeader a expInvDetail 19.2.1. Hlavička faktury - expInvHeader Tabulka pro uložení hlavičky faktury, která má být importována do Heliosu. Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Přes tento sloupec je vazba do tabulky expInvDetail. Generováno automaticky (Identity) Cislo_organizace Integer Ano Vazba na tabulku TabCisOrg. Hodnota sloupce CisloOrg Obdobi_od Datetime Ne Datum počátku období, pro které ja faktura vytvářena Odbobi_do Datetime Ano Datum konce období, pro které je faktura vytvářena Ciselna_rada Varchar(3) Ano Číselná řada faktur, na základě které vygeneruje Helios číslo faktury. Vazba na TabDruhDokZbo.RadaDokladu Vysledek_zpracovani Varchar(200) Ne Po importu faktury do Heliosu je zde v případě chyby její popis. Pokud k chybě nedojde, je faktura z pracovních tabulek smazána. Při přenosu faktur k chybám nesmí docházet po odladění přenosů z PS. 19.2.2. Položky faktury - expInvDetail Tabulka pro uložení položek faktury, která má být importována do Heliosu. Sloupec Helios Datový typ Povinný Poznámka ID Integer Ano Unikátní identifikátor záznamu v Heliosu. Generováno automaticky (Identity) Id_header Integer Ano Vazba do tabulky expInvHeader Cislo_zakazky Varchar(15) Ano Číslo zakázky, ke které se váže položka faktury. Vazba na TabZakazka. CisloZakazky Skupina_zbozi Char(3) Ano Skupina zboží. Vazba na TabKmenZbozi.SkupZbo Reg_cislo_zbozi Varchar(30) Ano Identifikátor fakturační položky. Vazba na TabKmenZbozi.RegCis Kod_mj Varchar(10) Ano Kód měrné jednotky Jedn_cena Numeric(19,6) Ano Jednotková cena Mnozstvi Numeric(19,6) Ano Počet měrných jednotek Stredisko Varchar(30) Ano Organizační jednotka. Vazba na TabStrom.Cislo Specifikace Varchar(200) Ne Poznámka k položce, která může být tisknuta na faktury. Pokud jsou pro zákazníka exportovány statistické zakázky, jsou součástí tohoto sloupce (nejprve je statistická zakázka, potom mezera a nakonec poznámka k položce faktury).

74

2200.. R Roozzhhrraanníí nnaa P PM MS S 20.1. Data přebíraná z PMS do PS Z databáze PMS je přebírána celá řada informací souvisejících s personalistikou a mzdami. Zejména se jedná o seznam zaměstnanců, jejich pracovních úvazků, seznam prohlídek zaměstnanců, měřenkový list, číselník mzdových složek atd. Z databáze PMS jsou přebíraná data zejména z následujících tabulek: • PM01 - Seznam zaměstnanců s ročními daty • PM04 - Seznam zaměstnanců • PM12 - Mzdy • PM18 - Číselník mzdových složek • PM23 - Tabulka výpovědí • PM68 - Měřenkový list Z databáze PMS mohou být přebírána i data z následujících tabulek: • PM36 - Seznam absolvovaných školení • PM38 - Seznam školení

20.2. Data předávaná z PS do PMS Do PMS jsou předávány zejména podklady pro výpočet mezd, nepřítomnosti zaměstnanců, měřenkový list.

75

2211.. S Seessttaavvyy Z PS je možné zobrazit některé formuláře připravené jako tiskové sestavy, které budou mít upravený design pro tisk na tiskárně. S ohledem na specifické požadavky může vyvstat požadavek na úpravu výchozího nastavení prohlížeče – např. MS Internet Explorer standardně netiskne rámečky tabulek a barvu pozadí tabulek, což při tisku sestavy může být požadované a proto je nutné toto nastavení prohlížeče změnit. Před použitím zvolené sestavy se musí vybrat záznam, pro který má být sestava vytvořena – např. před tiskem docházkového listu musíme vybrat zaměstnance či brigádníka apod.

21.1. Docházkový

list

–

skutečný Jedná se o přehled skutečně odpracovaných směn zaměstnance nebo brigádníka za jeden měsíc na jednotlivých zakázkách. V PS již je uvažován obdobný přehled, jehož příklad jsme již popisovali například v kapitole 14 Brigádníci Pro brigádníky je možné zobrazit sestavu ve verzi s cenou za odsloužené hodiny (pro potřeby manažera zakázky) i ve verzi bez ceny (jako potvrzení o odpracovaných hodinách pro brigádníka). Pro zaměstnance je jen jedna verze, která odpovídá zobrazenému vzoru mimo sloupce Kód, který není zobrazován vůbec.

21.2. Docházkový

list

–

úřední pro THP Jedná se o přehled docházky po úpravě na úřední docházkový list. Jde o jeden ze dvou úředních výkazů docházky (spolu s následující sestavou), proto jsou některé části designově shodné Ve spodní části jsou zobrazeny součtové informace u jednotlivých důvodů nepřítomnosti. Uvedeny mohou být jen ty nepřítomnosti, které byly v daném měsíci použity.

76

21.3. Docházkový list – úřední Jedná se o přehled docházky po úpravě na docházkový list. Jde o variantu předchozí sestavy pouze s uvedením podrobnější informace o odpracovaných hodinách a s informací o zakázce. V součtové části jsou navíc také informace o navržených odměnách.

21.4. Přehled stravenek V rámci PS je vytvořena sestava s počtem navržených stravenek pro jednotlivé zaměstnance v rámci manažera zakázky. Tato sestava odpovídá vzoru. Co se týká změn počtu stravenek až při výpočtu mzdy ve mzdovém systému, je předpoklad, že se jedná o mizivé procento případů a manažer zakázky je upozorněn mzdovou účetní mailem mimo PS o provedené změně proti návrhu manažera. Přehled rozdílů mezi podklady a skutečností v tom případě musí řešit sestava, kterou poskytuje mzdový systém a nesouvisí se zajištěním provozních činností v rámci PS. Návrh: mzdový systém vytvoří sestavy např. ve formátu PDF a uloží je do PS databáze jako připojený soubor k zakázce typu manažer zakázky. Sestava bude zobrazovat zaměstnance dle vybrané kmenové zakázky.

21.5. Přehled

nepřítomnosti

BA/BAS Sestava zobrazuje přehled nepřítomností zaměstnanců za vybrané období pro vybranou kmenovou zakázku. Budou zobrazovány dva počty dní – kalendářní dny a pracovní dny (pondělí až pátek, na které nepřipadá svátek). Ve sloupci Důvod je zobrazována hodnota zadaná v evidenci nepřítomností, jak je popsáno v kapitole 10.4 Nepřítomnosti. V sestavě pro BAS nejsou zobrazováni zaměstnanci, kteří mají pracovní úvazek pouze v BA a nemají jej v BAS. Pracovníci zaměstnaní pouze v BAS v sestavě také nejsou, protože PS s nimi zachází jako s brigádníky, pro které se nepřítomnosti neevidují.

77

21.6. Přehled výjezdových služeb V této sestavě je zobrazen seznam všech výjezdovek evidovaných v PS a pro každou z nich je pro zadaný měsíc načten evidovaný počet výjezdů a vypočtena cena, která výjezdovkám dle evidence v PS přísluší. Místo sloupce Počet objektů je zobrazen sloupec Počet zakázek, což je počet zakázek, ke kterým je výjezdovka v daném měsíci přiřazena.

21.7. Zvýšení ceny Jedná se o sestavu Nový a ztracený prodej, která je řešena v rámci reportů z DWH.

21.8. Nefakturované zakázky Sestava obsahuje výčet zakázek, které jsou aktivní a u kterých se v aktuálním období neprovedla žádná fakturace.

21.9. Zobrazení CB1 Požadavek: Zobrazení CB1 na zakázce, zákazníkovi, nadřízené zakázce, regionu, tzn. porovnání nákladů a výnosů u dané zakázky, zákazníka, nadřízené zakázky (všech zakázek pod manažerem zakázky) a regionu Řešení: Tento požadavek není řešen sestavou, ale má dopad do různých částí PS. Zde zmiňované principy a informace nejsou zachyceny v předchozích kapitolách. Jde o rozdíl nákladů a výnosů. Tato hodnota je zobrazována přímo ve formuláři pro zakázky. Pro ostatní požadované evidence (nadřízená zakázka, manažer zakázky, zákazník) je tato informace načtena z podkladových dat na vyžádání (stisk tlačítka otevře okno s požadovanou informací). 21.9.1. Zakázka Na zakázce jsou zobrazovány informace o součtu hrubých nákladů a výnosů zakázky. Výnosy představují součet fakturačních položek pro danou zakázku, které jsou průběžně aktualizovány dle dat evidovaných v PS. Náklady zahrnují platby agenturám za brigádníky a výjezdovkám za výjezdy dle evidovaných cen (např. 3 výjezdy po 500Kč + 4 brigádníci celkem 82 hodin po 80Kč = 8060Kč). Pro zaměstnance pracující na zakázce je započtena podle odsloužených hodin jeho hodinová mzda. Protože v PS je evidována pouze hrubá hodinová mzda (není zde přehled např. zákonných odvodů za zaměstnance, který je vypočten až ve mzdovém systému), dochází k určitému zkreslení. PS proto umožní vynásobit hrubou hodinovou mzdu zaměstnance zadaným koeficientem (např. +70%), aby bylo možné dostávat alespoň přibližně reálné hodnoty o nákladech za zaměstnance. 21.9.2. Zaměstnanec Pro zaměstnance je v rámci PS možné zadat Koeficient režie. Jedná se o procentuální vyjádření dalších režijních nákladů, které je nutné připočítat ke hrubé hodinové mzdě za odsloužené hodiny. Koeficient je zadaný také hromadně pro BA, pokud není u zaměstnance nadefinována výjimka, je použit tento společný koeficient přepočtu režijních nákladů. 21.9.3. Podklady pro mzdy Při zadávání mimořádných odměn (odměny, prémie, …) je tato započtena na kmenovou zakázku zaměstnance.

78

21.10.Export položek do MS Excel, případně do PDF Určené formuláře jsou doplněny tlačítkem po jehož stištění se data z formuláře uloží do excelové tabulky. Převod formuláře do formátu pdf je řešen pomocí tisku na virtuální tiskárnu, která převod do požadovaného formátu zajistí.

21.11.Rozpis služeb na den Jde o sestavu, ve které jsou dle předplánování uvedeny všechny služby na příslušný den s uvedením zakázky, pozice, času začátku a konce směny a místo na poznámku, do které se zapíše jméno pracovníka. Tato sestava je zmiňována v rámci návrhu řešení 16 Práce s plány

21.12.Zůstatky dovolené Manažer zakázky může zobrazit pro své zaměstnance informaci o zůstatku dovolené. Zobrazován je aktuální počet získaný z PMS

21.13.Končící platnosti školení a prohlídek Manažer zakázky je moci zobrazit pro dané období seznam svých zaměstnanců, kterým končí sledovaná prohlídka v tomto období. Seznam prohlídek je přebírán z PMS, jak je uvedeno v kapitole 10.5 Prohlídky .

21.14.Data narozenin u podřízených Manažer zakázky může zobrazit pro dané období seznam svých zaměstnanců, kteří mají v tomto období narozeniny.

79

2222.. ZZáávvěěrreeččnnéé sshhrrnnuuttíí aa ddooppoorruuččeennéé ppoossttuuppyy 22.1. Shrnutí Bakalářská práce ,,Internetové portálové aplikace a jejich využití v praxi“ se v úvodu zaměřuje na historii internetu a portálových aplikací, jejich typy a členění. V druhé části je práce zaměřena na popis portálového systému, na jehož vývoji jsem se podílel a který byl implementován v průběhu let 2007-2009. Primární funkcí tohoto portálového systému je evidence docházky pracovníků ve firmě s celorepublikovou působností a to na mnoha stovkách provozoven. Takto pořízená data jsou systémem při pravidelných měsíčních uzávěrkách zpracována a předána k následnému zpracování do účetních a mzdových systémů. Při zavádění systému pomocí portálového řešení vyplynula řada výhod a také nevýhod. Pokusím se stručně shrnout některé z nich. 22.1.1. Výhody -

dostupnost pro uživatele pouze s využitím relativně pomalého připojení na internet bez nutnosti další dodatečné instalace nějakých softwarových komponent nezávislost na platformě nezávislost na operačním systému nezávislost na typu internetového prohlížeče jednoduchá vazba na všechny důležité části IS a zprostředkování dat směrem k uživatelům pouze jediné pořizování dat, které slouží pro potřeby generování podkladů pro fakturaci i mzdy uživatelsky přívětivý systém bez nutnosti dlouhých školení uživatelů možnost rozšíření o další moduly, dle potřeby společnosti (biometrické bezdrátové automatické terminály pro nahlašování/odhlašování pracovníků do/ze služeb, portál pro zákazníky, portál pro dodavatele, atp.) snadná údržba a zálohování, bezproblémový provoz na jakémkoliv „železe“ zabezpečený přístup k informacím možnost řídit pomocí rolí přístup pouze k určitým datům či částem portálu obrovská úspora času při zpracování podkladů při uzávěrkách (v některých případech až 2 dny práce) okamžitý přehled o všech pracovnících, kteří jsou momentálně na pracovišti, kteří jsou po směně, kteří se na směnu chystají přehledy o nepřítomnostech, nemocenské, dovolené přehledy exspirace pravidelných prohlídek, školení, atp. okamžité přehledy stavu jednotlivých zakázek z hlediska výnosů a nákladů snadná evidence mimořádných událostí na pracovištích veškerá dokumentace spojená s výkonem služby na pracovišti je nyní elektronicky dostupná pomocí portálu

22.1.2. Nevýhody -

-

portálový systém není klasická klient-server aplikace, data jsou zpracovávána pouze na úrovni prohlížeče, dojde-li ke ztrátě spojení, dojde i k neuložení rozpracovaných dat při načítání složitějších formulářů může na pomalejších linkách docházet k vyšším časovým prodlevám oproti specifikaci. Tento problém je řešen možností nastavení redukce objemu přenášených dat (např. nenačítají se plány služeb na celý měsíc, ale pouze na jeden týden) potřeba kvalitní internetové linky na úrovni serveru nebo umístění aplikačního a databázového serveru v housingovém centru providera z důvodů vytížení SQL serveru je doporučeno pro portálový server využívat samostatný

80

22.2. Doporučené postupy Jak už jsem uvedl, podílel jsem se na vývoji portálového systému, který je od 1.1.2009 nasazen v ostrém provozu. V aplikaci jsou využity veškeré poznatky, které jsem v průběhu posledních 8 let získal při implementaci předchozích ne-portálových řešení. V práci je popsána celá funkcionalita portálového systému Můj podíl na vývoji systému byl především v tom, že jsem velmi dobře znal celou problematiku všech předchozích verzí, dovedl jsem správně formulovat zadání a mohl jsem dohlížet na to, aby nový portálový systém splňoval všechny parametry, které byly požadovány. Zde je prostor, abych čtenáři této práce nabídnul doporučené postupy pro zavádění portálové aplikace podobného rozsahu, jako je zmíněna v předchozích kapitolách. - velmi důležité je velmi dobře si rozmyslet, co má aplikace dělat a co od ní očekáváte. Nad analýzou jsme strávili řadu měsíců a nebyl to promarněný čas. Vyspecifikovali jsme celou řadu bodů, které vedly k efektivnější práci analytiků a programátorů dodavatele a výsledkem je aplikace, která se velmi blíží tomu, co jsme od ní očekávali. - dalším důležitým bodem je výběr správného dodavatele. Výběrové řízení provádějte pečlivě, doporučuji partnera, který má s aplikacemi tohoto typu zkušenosti. Není nic horšího než dodavatel, který se na vás bude učit. - Definujte tým klíčových uživatelů, pokud možno z každého úseku firmy, která bude v budoucnu s aplikací pracovat a zaangažujte jej do práce na projektu. Celou řadu budoucích problému tímto krokem eliminujete. - Provádějte pravidelně kontrolní dny, kde prověřujte, zda je dodržován plán projektu a konzultujte veškeré problémy přímo s klíčovými uživateli. - Pečlivě testujte všechny nové funkční celky a nezapomínejte při tom testovat i ty už dříve otestované. Není vyloučeno, že nově zakomponovaná funkcionalita má nějaký negativní dopad na nějakou již dříve odzkoušenou. - Udělejte si dostatečnou časovou rezervu na testovací provoz, pokud má portálová aplikace dopad i na jiné systémy, tak si udělejte rezervu na souběžný provoz původních systémů a nového portálu. Tímto jsem splnil všechny vytyčené cíle práce, které jsem uvedl v zadání. Samozřejmě, že portálový systém je stále ve vývoji, protože přicházejí požadavky na další funkcionalitu, jako již zmíněná integrace biometrických bezdrátových automatických vstupně/výstupních terminálů, přístup pro dodavatele a pro zákazníky, atd. Předpokládám, že finální verze portálové aplikace se všemi zmíněnými prvky bude v ostrém provozu od 1.1.2011.

81

2233.. LLiitteerraattuurraa

[1] Brabec Vladimír: Co bylo, než vznikl český Internet?, dokument je dostupný na http://www.lupa.cz/clanky/co-bylo-nez-vznikl-cesky-internet/ (13.8.2002) [2] LACKO Luboslav: Web a databáze – programujeme internetové aplikace, Computer Press, Praha, 2001, ISBN 80-7226-555-5 [3] Manhartsberger Fred: Portály se prosazují - zkuste to s nimi. Dokument je dostupný na http://www.pcworld.cz/ (duben 2006).

82