UDS - Podnikový informaní systém

UDS - Podnikový informaní systém V Plzni 13.08.2010

Obsah 1 ÚVOD... 3 2 PROCESNÍ SCHÉMA... 3 3 MODULÁRNÍ EŠENÍ A ÍZENÍ LOGISTICKÉHO ETZCE... 5 3.1 Založení zakázky... 5 3.1.1 Definice hlaviky zakázky... 6 3.1.2 Definice výrobních proces... 7 3.1.3 Definice pedlohy díl... 7 3.1.4 Definice jednotlivých verzí... 8 3.2 Píjem zákaznického materiálu... 13 3.3 Peskladnní zákaznického materiálu... 15 3.4 Produkce denní výkaz spoteba materiálu... 16 3.4.1 Založení len osádky... 17 3.4.2 Odebrat lena z osádky... 18 3.4.3 Vyhledání lena v seznamu... 18 3.4.4 Založení položky výkazu... 20 3.4.5 Pihlášení na jiném terminálu... 20 3.4.6 Ukonení výkazu... 21 3.4.7 Zadání spoteby materiálu... 21 3.4.8 Podmínky a kontrola realizace spoteby... 22 3.4.9 On-line monitorování produkce... 24 3.5 Logistické operace s hotovými výrobky... 26 3.6 Expedice... 28 3.7 Fakturace... 30 3.7.1 Píprava faktury... 30 3.7.2 Kontrola faktury... 34 3.7.3 Uzavení faktury... 34 3.8 Bilancování a sledování zakázky... 34 3.8.1 Kontrola pohybu díl... 34 3.8.2 Pehled verzí výrobní statistika... 34 3.8.3 Pehled palet podle transport... 35 3.8.4 Expedice hotových výrobk... 35 3.8.5 Produkní statistika AVG (Arbeitsvorgang)... 35 3.8.6 Pehled fakturace zakázky... 35 3.8.7 Bilancování zakázky... 36 4 ZÁVR... 36 2

1 Úvod Problematika ízení výroby v odvtví polygrafického prmyslu se ve spolenosti reus s.r.o. zaala pozitivn ešit již v letech 2004, kdy stál podnik ped rozhodnutím, zda využít nkterých komerních ERP systém, které v té dob nabízel trh, ovšem bez možnosti rozsáhlých investic, napíklad do renomovaných systém jako je SAP, a nebo pistoupit zodpovdn k ízení projektu vývoje vlastního softwaru. V té dob docházelo ke zkoumání napíklad systému NAVISION, bohužel nebyl v té dob znám systém CICERO, který je dnes asi nejznámjším ERP systémem na eském trhu, který se zamuje práv na oblast polygrafické výroby. Výsledkem analýz, které byly v letech 2004 provádny, byl systém i24reus, který byl koncipován pedevším pro oblast výroby knižní vazby. Postupem asu, kdy spolenost pecházela do jiného koncernu, se ukázalo, že nkteré ovládací prvky tohoto systému nevyhovují a bylo na snadn rozhodnout, zda má dojít k jeho úprav a nebo pepracování. V roce 2008 se ukázalo, že pepracování systému by bylo nákladné a i asov nehospodárné. Spolenost pistoupila k využití svých kapacit v oblasti vývoje databázových systém a s pomocí vývojového prostedí Delphi7.0 a databáze INTERBASE zaal vznikat zcela nový informaní systém využívající dosavadních zkušeností a integrující do ešení další moduly a funkce: UDS-reus. V nkolika následujících odstavcích bude podán výklad k základním funkcím systému a pedevším bude popsán proces ízení jednotlivých oblastí logistického etzce. 2 Procesní schéma Systém UDS-reus je konceptuáln navržen jako procesn orientovaný. Mžeme jej tak adit do skupiny systém, které oznaujeme jako ERP (Enterprise Resource Planning). Díky procesnímu pístupu systém podmínen ídí jednotlivé ásti logistického etzce tak, jak následují v reálném provozu. Vzhledem k politice koncernu schlott, kam se spolenost reus s.r.o. adí, neobsahuje systém nkteré aktivní standardní moduly ízení logistického etzce pedevším potom založení poptávky a její kalkulaci. Tyto ásti lze aktivovat, ovšem v reálném provozu spolenosti to není nutné s ohledem na její postavení v koncernu. Definice zakázky a pedevším její další struktury jako je napíklad struktura díl a jednotlivých složek, je podmínkou pro založení píjmu zákaznického materiálu. Systém generuje sérii paletových lístk, kterými jsou jednotlivé palety identifikovány. Následn poté, je-li dokonena definice jednotlivých verzí zakázky, jsou do výroby distribuovány zakázkové listy a souasn je provádno peskladnní zákaznického materiálu (ZM). Uvedený pohyb je uložen formou transakcí, takže je možné v libovolném okamžiku sledovat stav zásob ZM a množství pedané do výroby, pípadn potebné dodávky od zákazníka. Oblast ízení se tím pesouvá do výroby. Zde je pomocí terminálu veden tzv. denní výkaz, který je zdrojem informací pro další výrobní statistiky, souasn je terminál vybaven diodovým idlem pro sledování vyrobených kus. Data jsou pedávána systému v dávkové podob, který je vyhodnocuje v režimu pro monitorování produkce. Souasn je provádno zpracování a vyízení materiálových požadavk na spotební materiál (SpMa), který je pomocí terminálu v urených intervalech formou inventury na pracovišti deklarován jako 3

spotebovaný. Vznikají tak transakce spoteby, které jsou v dávkové form pedávány systému SAP. V pípad vyrobení prvních kus jsou tyto stohovány na paletách, které jsou vybaveny identifikaní kartou (paletový lístek) a árovým kódem. Takto vyrobená a identifikovaná paleta je naskladnna do skladovacích prostor pomocí skenování. Systém tak získává informaci o vyrobeném množství, které je uskladnno. Souasn s definicí palet hotových výrobk vzniká informace nejen o tom, jaké množství je vyrobeno, ale pedevším jaké množství zbývá vyrobit. V pípad naskladnní hotových výrobk do skladovacích prostor je možné tyto použít k expedici. Jednotlivé palety, které jsou naváženy do návsu tahae, jsou souasn skenovány a pidružovány k pipravenému píkazu k expedici, který se ve finále mní v dodací list, jak jsou mu postupn pidružovány jednotlivé palety. Každý doklad nese pesnou informaci o konkrétní naložené palet. Expedované množství je zdrojem pro množství k fakturaci. Dokumenty mohou být vystaveny bhem expedice nebo tsn po ní. Následn je soubor vystavených úetních doklad použit pro bilancování výroby zakázky, kde se porovnávají hodnoty získané z výroby na základ denních výkaz a hodnoty z dokument fakturace. ' ) % (%./ "!"# # $'! 6)#!"#$ % # -# 0) ( 45 #! '5 ('" /'% '"/' *! ' )#+!,-% *1*,23*!!"(% # &'!!"( Obr. 2-1 Procesní schéma funkcí systému UDS 4

3 Modulární ešení a ízení logistického etzce Aplikaní ást systému je ešena modulárn, což znamená, že obsahuje dílí moduly logistického etzce jako je napíklad modul: Zakázka Logistika Výroba Fakturace Takové rozdlení aplikaní úrovn umožuje modifikovat jednotlivé aplikace pro koncové uživatele podle oblasti jejich pracovního psobení. V souasné dob umožuje systém uživatelm nahlížet do více oblastí než pouze do té ásti, která jim z hlediska jejich pracovního zaazení písluší. To má zvýšit informovanost a rozšíit možnosti získávání informací i z tch oblastí, které uživatel sice neobsluhuje nebo nevyužívá pímo, ale mže nahlížet do nkterých vlastností napíklad zakázky, pestože psobí uživatel v oddlení napíklad logistiky. Moduly jsou mezi sebou vzájemn propojeny strukturou vazeb jednotlivých tabulek databáze. Není proto možné pijímat napíklad zákaznický materiál (modul Logistika) aniž by pedtím manažer zakázky definoval nejen zakázku samotnou, ale pedevším strukturu díl, která jí písluší. (modul Zakázka) A takových píklad bychom nalezli mnoho. Tyto podmínené procesy adí UDS do skupiny ERP systém. Logistický etzec je tímto ízen podmínen a definovaná konzistentní kontrola vstupních údaj zajišuje maximální soudržnost a logickou správnost poízených dat. Systém pitom k takové kontrole pistupuje formou tzv. restrikce, tedy bu je njaká operace možná a nebo není možná vbec, neexistuje tedy možnost njakého chybného zadání. Než se budeme ízením v jednotlivých modulech UDS zabývat podrobnji, zde jeden píklad: Pedpokladem pro vystavení dodacího listu pi expedici (berme nyní hotové výrobky) je správné založení tzv. píkazu k expedici. Ten udává místo doruení výbrem uritého transportu verze zakázky. Není-li takový transport definován, není možné vytvoit zmiovaný píkaz k expedici. Pokud je tento definován, je pi vlastní nakládce zapotebí paletových lístk, které se párují k vybranému píkazu a to pouze v tom pípad, že jsou zaazeny (ve své definici) do skupiny transportu, který je vybrán v píkazu k expedici. V opaném pípad systém nemže nakládku realizovat, není pidružena žádná paleta a dodací list také nelze vyhotovit. Paletové lístky lze založit pouze k definovanému transportu urité verze zakázky. Není-li transport definován, není možné definovat paletové lístky atd. Podmínnost zmiovaného procesu nás pivádí až na samotný zaátek: K definici zakázky, odkud se odvíjí všechny další procesy logistického etzce. 3.1 Založení zakázky Proces založení zakázky je jedním ze základních proces systému UDS. Bez této ásti ízení není možné dále využívat možností systému. Jestliže je tomu tak, mžeme pedpokládat, že její založení (myšleno zakázky) je základním prvkem, kterému ve vývoji byla vnována zvláštní pée, nebo a chceme i nechceme, musíme se smíit s tím, že založení zakázky je jednou z asov nejnáronjších operací obsluhy systému UDS. 5

Manažer zakázky pipravuje živnou pdu pro všechny další uživatele, kteí na ízení participují. Objem dat, které manažer zakázky do systému zadává je dvakrát až tikrát vtší než v ostatních modulech. Proto tento modul nabízí také nejvíce výjimek v zadávání: Speciální kopírovací funkce Zadávání hromadných záznam Hromadné mazání záznam (podle nastavení práv uživatele) Nativní vytváení vazeb mezi jednotlivými tabulkami atp. Hned v prvním kroku definice zakázky mže uživatel využít kopírovací funkce a zkopírovat nové hodnoty z vybrané zakázky s možností kopie i všech podružných struktur, popípad si z této struktury mže vybrat, co chce kopírovat. Obr. 3-1 Kopírovací funkce pro zakázku Výet všech inností, které musí manažer zakázky zvládnout by obsáhla samostatná píruka pro manažery zakázek, pesto si popíšeme ty základní. Pokud není využita kopírovací funkce, je teba pro správnou funkci dalších modul systému provést: Definici hlaviky zakázky Definici výrobních proces Definici pedlohy díl (složky a další komponenty) Definici jednotlivých verzí (a všech jejích podstruktur) 3.1.1 Definice hlaviky zakázky Hlavika zakázky nese pedevším její identifikaní íslo v systému, dále pak identifikaci v systému koncernu schlott gruppe tzv. koncernové oznaení. Mezi další dležité vlastnosti, které pebírá pak napíklad modul fakturace, patí píjemce faktury a odbratel. Systém dále pracuje napíklad s nkterými daty, které slouží pro zaazení zakázky v asové ose nejen výroby, ale také vystavení dokument fakturace. 6

3.1.2 Definice výrobních proces Výrobní procesy slouží v prvé ad jako identifikátory zakázek pro externí systémy (SAP). Zde je každá zakázka rozdlena do tolika definovaných záznam, kolik je definovaných výrobních proces. Souasn je definice výrobního procesu (VP) jistým integritním omezením napíklad v definici pracovního postupu již urité verze zakázky, kde není možné vybrat stroj, který neodpovídá definovanému VP v zakázce. Jinak eeno: Jestliže máme zakázku, která spoívá ve vyhotovení knižní vazby napíklad V2 (brožura lepená), nemžeme do pracovního postupu zaadit napíklad balení do fólie, což odpovídá zcela jinému VP, který by musel být v zakázce definován. 3.1.3 Definice pedlohy díl Pedloha se skládá ze všech složek potebných pro výrobu, obálek, ale také dalších tzv. díl, které do vyhotovení koneného produktu patí. (CD, DVD, tašky, obálky, napíklad vzorové tastery atp.) Její definice je pedpokladem pro realizaci dalších operací, napíklad píjmu tchto materiál v modulu Logistika, kde uživatel vybírá z definovaného seznamu a provádí potebné transakce. Pedloha díl je pouze seznam. Nkteré definované položky pak mohou být použity v definici konené struktury bloku (katalogu) urité verze. V seznamu se tedy objevují vždy všechny složky a díly, v definici struktury bloku uritých verzí je to potom výbr z tohoto seznamu. Pitom platí, že verze mže obsahovat ve své struktue i všechny položky definované v pedloze a nebo žádné (což se nestává). Pedloha díl mže být pomrn rozsáhlá, proto systém umožuje nkteré akce, které napomáhají uživateli tuto ást definovat velmi rychle. Patí sem pedevším operace hromadného zadání, kdy systém založí hned nkolik záznam najednou, které pak uživatel rychle v tabulkovém zobrazení upraví, nebo mže použít kopírovací funkci, která vygeneruje strukturu pesn podle zvolené pedlohy jiné zakázky. Obr. 3-2 Pedloha díl a možnosti její rychlé definice 7

3.1.4 Definice jednotlivých verzí Každá zakázka se mže skládat z libovolného potu verzí, které se od sebe odlišují nejastji jazykovou mutací, je možné ovšem zakládat verze, které sice spadají pod uritou jednu zakázku, napíklad díky zákazníkovi, ale mohou se lišit i výrobní technologií. Mžeme tak mít ást nákladu voln, ást nákladu balenou do fólie. Takových píklad bychom zde mohli uvést mnoho. Verze je opt pomrn složitá struktura, která krom základních vlastností obsahuje pedevším také další podružné struktury, tabulky (v relaci 1:N a M:N): Definice struktury bloku Definice výrobního postupu v. použitých materiál Definice transport Obr. 3-3 Základní vlastnosti verze zakázky V pípad struktury bloku, která vychází z pedlohy, má možnost uživatel vybírat položky jednotliv, nebo lépe: Oznait ty položky pedlohy, které chce k definované verzi pidružit. Tato operace výrazn urychluje proces vlastní definice, což je rozhodující pro posouzení uritého komfortu systému, který tak dává uživateli mnoho nástroj k tomu, aby svou práci maximáln urychlil. Objem dat zadávaných v modulu Zakázka je rozsáhlý a nesrovnatelný s ostatními moduly systému UDS. Pi vývoji byl kladen velký draz na tvorbu takových akcí, které efektivn pracují s asem a minimalizují jej pro založení všech dat na hodnotu pijatelnou nejen z hlediska ekonomického, ale pedevším z hlediska individuálního pístupu manažera zakázky k práci, kdy mu systém otevírá vždy nkolik možností jak k zadávání pistupovat a neomezuje ho pouze na jeden jediný zpsob, který by sice mohl být optimalizován, ale ve finále by mohl psobit jako monotónní innost, která by negativn ovlivnila jeho individuální výkonnostní kivku. 8

Obr. 3-4 Možnost výbru položek pedlohy díl pro založení struktury bloku Výrobní postup definuje uživatel pro možnost pozdjší kalkulace pedbžných náklad na výrobu. Tato ást systému UDS není ve spolenosti reus využívána, nebo zakázky, které se v závod zpracovávají, jsou kalkulovány ze strany koncernu a cena pro zákazníka je tím již pevn daná. Výrobní postup, jako další struktura urité verze zakázky, slouží tedy vícemén pro zápis do technologického postupu, který se dále distribuuje jako podklad pro výrobu. Obsahuje tedy veškeré informace o provádných operacích vetn použitých stroj a materiál. Je teba dodat, že výrobní postup je možné tzv. normovat a vyjádit tak asovou náronost výroby a souasn také pedpokládanou materiálovou spotebu. Souástí výrobního postupu jsou také poznámky nkdy i nevýrobního charakteru. Ve finále pak vzniká kompletní zakázková dokumentace jako smrodatný podklad pro produkci. Aby bylo možné definici provádt rychleji, disponuje systém akcí, která zakládá položky výrobního postupu automaticky s možnosti výbru stroj, piemž je založeno tolik záznam operací, kolik je vybráno stroj. Zárove pak systém ke každé položce nadefinuje položky materiál spotebovávaných v každé definované operaci. V pípad použití více stroj pro zhotovení nákladu koriguje technolog požadované množství koeficientem (0-1) tak, aby kalkulace a výpoet asové náronosti pro výrobu požadovaného nákladu probíhal vždy pro uritou jeho ást na jednom stroji. Mžeme si to piblížit napíklad pro výrobu na dvou strojích, kdy jeden i druhý vyrábí polovinu požadovaného nákladu: Pak musí technolog (manažer zakázky) korigovat výpoet asové náronosti koeficientem 0,5 na každém stroji. 9

Obr. 3-5 Použití šablony pro založení operací výrobního postupu Dležitou souástí pro ízení výroby zakázky jsou definice jednotlivých transport vždy urité verze. Dvodem tohoto lenní je skutenost, že pi expedici hotových výrobk musíme sledovat verzi, kterou expedujeme, aby nedošlo k jejich pomíchání v rámci dodávek celé zakázky. Vzhledem k velikým objemm výroby, které se pohybují ádov ve sto tisících až miliónech kus, je ošetení expedice uritých verzí velmi dležité. Prostedkem jak toho dosáhnout je definice transportu pro uritou verzi. Transportem rozumíme záznam (vázaný na vybranou verzi relaní vazbou), který obsahuje jednak informaci o tom, co chceme transportovat (vlastnosti verze), jednak datum, kdy chceme transport provést, jednak také místo dodání. Poet položek v databázi se zvtšuje, jestliže se transport rozloží do více dn, jestliže se napíklad ást expeduje na jiných paletách atp. Lze íci, že každá zmna v uvedených vlastnostech ukazuje na nutnost založit nový transport. Na první pohled by se mohlo zdát, že je to zbytené, ale další využití takových záznam (pedevším pak v definici píkazu k expedici) ukazuje, že tomu tak není, ba naopak! Každému transportu totiž písluší automaticky generované paletové lístky (tabulka databázových záznam), které pak systém pidluje dodacímu listu, ímž jednoznan vytváí vazbu mezi dodacím listem, který vychází z píkazu k expedici, a paletou, která byla vyskladnna a naložena na návs. Jednoznan tak mžeme urit, která paleta byla transportována konkrétním vozem, idiem potažmo pepravní spoleností. Paletové lístky jsou klíovými záznamy v databázi, které nesou informaci o tom, zda bylo již požadované množství na palet vyrobeno, uloženo do skladu nebo ve finále odvezeno zákazníkovi. (Více o tom v kapitole: 3.5 Logistické operace s hotovými výrobky) 10

Objem takových záznam je veliký a jejich založení je pln automatizováno akcí, která operaci provede v pijateln krátkém ase. Záleží pitom na definici transportu, kde je teba zadat celkové množství pro daný transport a poet kus na palet. Ze znalosti tchto hodnot systém vypoítá potebný poet záznam s pedepsaným potem kus na palet. Hodnoty potu kus uložených v záznamu paletových lístk je možno mnit. Je možné záznamy v tomto smru modifikovat a dokonce ídit i poet takto vytvoených záznam. (Napíklad pidáním nebo ubráním nkolika palet.) Paletové lístky vznikají jako záznamy v databázi a je jim pidleno jednoznané identifikaní íslo, podle kterého je systém v dalších oblastech ízení vyhledává a mže s nimi dále pracovat pomocí skenování jejich árového kódu. Obr. 3-6 Základní vlastnosti transportu Paletové lístky v tištné podob slouží jako nedílná souást zakázkové dokumentace. Bez jejich definice a distribuce do výroby není možné s produkcí zaít, nebo urují poty kus, které se mají skládat na jednu paletu. Pokud systém vypoítává množství hotových výrobk v uritém stavu (nové/nevyrobené vyrobené/na sklad - expedované), vždy vychází z vlastností záznam paletových lístk. Tabulka tchto záznam barevn odlišuje ádky jednotlivých palet pro uritý stav, který mže nastat. Je tak možné nejen vizuáln posoudit, zda nkteré palety byly již vyrobeny nebo expedovány. Poskytuje hlavn zdroj dat pro vyjádení informací na otázku, jak výroba postupuje. 11

Obr. 3-7 Tabulka paletových lístk pro definovaný transport Obr. 3-8 Ukázka tisku: paletový lístek 12

3.2 Píjem zákaznického materiálu Objem dat, která jsou zadávána v oddlení logistiky, je ve srovnání se založením zakázky a všech jejích dalších struktur, pedevším potom verzí, menší, pesto nemžeme íct, že by to nebyl proces složitý. I zde bylo v prbhu vývoje systému pihlédnuto ke skutenosti, že práce musí být optimalizována a asov nenároná. Pracovníci logistiky pinášejí do systému stžejní informace o materiálovém toku. Zadávání dat tak musí probíhat rychle a pedevším je teba zajistit stabilitu systému i v obdobích, kdy je frekvence zpracování vstupních dat velmi vysoká, jak tomu je napíklad v msících kvten až záí. Dležitým bodem procesu ízení celé zakázky je evidence pohybu zákaznického materiálu. Jedná se o složky, které zakládá pracovník odbytu (manažer zakázky) jako pedlohu díl. Tento seznam slouží pracovníkovi logistiky, aby mohl pi píjmu pesn identifikovat druh polotvaru, který pichází ke zpracování do závodu. Samozejm je tato innost velmi zodpovdná, vždy na základ tchto informací ídí vedoucí pracovníci a celý výrobní proces. Píjem materiálu je operace, která procesn probíhá ve dvou krocích: Založit píjem Generovat paletové lístky Nejprve je teba urit materiál, který je pijímán. (Musí být definován v pedloze díl.) Následn se provede operace píjmu, která založí potebné transakce pohybu. Zde je teba urit, kdo je dodavatelem zboží, tiskárna a také kdo je dopravce a odkud bylo zboží dodáno. Všechny tyto vlastnosti sloužily díve pro automatické vedení správy dat pro INTRASTAT. Obr. 3-9 Píjem zákaznického materiálu (vybrány 3 položky) 13

Založení píjmu je uzpsobeno tak, aby bylo možné provést rychle a pohodln píjem i více druh složek, takže uživatel vybírá ze seznamu pedlohy díl a provádí pohyb pro všechny vybrané položky najednou s tím, že je mže pozdji kdykoli upravit v generovaném dokumentu pohybu. Ten je vytvoen automaticky a tvoí jej záhlaví s adresou místa odeslání, informací o dopravci a další. Dále obsahuje tento doklad podružné záznamy (položky), které pedstavují jednotlivé složky, které byly pro tento druh pohybu vybrány. Jednotlivým složkám systém nejprve piadí jednotný poet kus pro píjem tak, jak bylo zadáno ve formulái. Pokud se poty píjmu u jednotlivých položek reáln ovšem liší, je nutné je v dokumentu pohybu opravit, což se provede jednoduše pepisem. Z dalších možností, jak dokument upravit, si mžeme popsat napíklad identifikaci vzork. Položky dokladu mžeme zkopírovat, oznait požadované ádky jako vzorky zaškrtnutím píslušného políka v tabulce a opravit pijaté množství. Obecn platí, že píjem lze založit také pouze definováním dokumentu pohybu zvolením správné transakce. UDS umožuje nativní zadání píjmu proto, že výrazn optimalizuje proces založení tohoto pohybu a snižuje asovou náronost této operace na minimální možnou míru. Je-li píjem založen a upraven dokument pohybu, je možné pistoupit k vygenerován záznam pro paletové lístky zákaznického materiálu. Prakticky jde o jednoznanou identifikaci každé palety v systému proto, aby bylo možné provádt skenování tchto palet pi peskladnní (výdeji) do výroby a tím zajistit jednoznanou identifikaci místa, kde se paleta práv nachází. Obr. 3-10 Dokument pohybu Paletové lístky se generují pomocí akce, která je souástí kontextové nabídky položek dokumentu pohybu. Principieln dochází k automatickému založení záznam palet pro každý materiál, který je obsažen v položkách dokumentu pohybu. Poet záznam, které systém vytvoí je dán potem palet pi píjmu. Souasn je uživateli ihned pi generování tchto záznam umožnno dílí poty na jednotlivých paletách mnit, nebo není pravidlem, že pi píjmu celkového potu 15000 ks na 5 paletách je na každé z nich 3000 ks. 14

Obr. 3-11 Možnost zmny potu kus na palet pi generování paletových lístk Systém generuje paletové lístky pro každou položku v dokumentu pohybu. Jestliže dokoní proces generování, je možné paletové lístky vytisknout. Tisk se týká pak pouze tch, které jsou pidruženy k aktuálnímu dokumentu pohybu, což je dležité, nebo takových palet mže být v prbhu dne generováno nkolik vždy pro jiný píjem, tedy i jiný dokument pohybu. Tištné paletové lístky jsou pak umístny na jednotlivé palety a zajišují tak jejich identifikaci pi manipulaci. Paletový lístek je vybaven árovým kódem, který je možno skenovat. 3.3 Peskladnní zákaznického materiálu Peskladnní zákaznického materiálu, které se z vtší ásti využívá pro výdej materiálu do výroby, je realizováno na obslužném terminálovém pracovišti ve skladu u vjezdu do haly. Toto pracovišt je vybaveno skenerem a nejen verzí UDS pro skenování palet, ale také verzí pro provádní píjmu materiálu, což umožuje provádt plynule tuto operaci i v dob, kdy není na pracovišti logistiky pítomen zamstnanec. V takovém pípad provádí píjem zaškolená osoba (skladník-vozíká). Pracovišt slouží ovšem pedevším k realizaci pohybu peskladnní samozejm s možností v obou smrech! Pracovník skladu provede vývoz materiálu do výroby a sejme paletový lístek, který skenuje. Systém nejprve provede formální kontrolu po nalezení píslušného záznamu a oví, zda paleta nebyla již vydána do výroby. Teprve potom založí dokument pohybu, kterému pidruží dv položky vždy pro transakci výdeje a píjmu. Operace výdeje je provedena na pracovišti hlavního skladu, operace píjmu je provedena na produkním skladu, který pracovník zvolí. Jednotlivé palety tak systémov putují na zvolené pracovišt. Tím se poet palet na hlavním skladu sníží o jednu a zvýší na produkním skladu píslušného stroje, kam byla paleta odvezena. Souasn se tak zmní pomr množství palet a potu kus daného zákaznického materiálu pi sledování ve skladu a ve výrob. Oddlení logistiky a všichni, kteí se systémem UDS pracují pak mají v daný okamžik možnost 15

sledovat, jak se množství zákaznického materiálu odvíjí (mní) v souvislosti s jeho pohybem po závod. Je též možné rozhodnout, kolik materiálu bylo do výroby již vydáno, jaké množství zstává na hlavním skladu a popípad jaké množství je teba ješt pijmout (oekávaná dodávka), aby bylo možné produkci dokonit pro stanovený náklad. Obr. 3-12 Skenování zákaznického materiálu pi výdeji do výroby 3.4 Produkce denní výkaz spoteba materiálu Denní výkazy jsou jediným zdrojem informací pro statistická vyhodnocení produkce, ale také pro bilancování zakázky. Množství vyrobených kus zadávané pomocí terminálu slouží pouze pro statistické ukazatele výkonnosti. Jinak je pro sledování vyrobeného množství použito palet, které se skenují ve skladu, což je obsahem kapitoly: 3.5 Logistické operace s hotovými výrobky. Zpsob vedení pracovních snímk ety (denní výkaz) je dvojí: Papírová forma Terminálové on-line zadávání V pípad, že nefunguje terminálová aplikace pro zadávání denního výkazu on-li, je možné zadat výkaz v papírové podob, který je potom pepsán do systému. Taková byla první koncepce pi vývoji UDS. Produkní data získaná tímto zpsobem mohla být ovšem vyhodnocována až s uritým zpoždním. Proto byla vyvinuta terminálová aplikace UDS terminál, která umožuje zadávat data pímo a ty pak sledovat napíklad pomocí monitorovacího nástroje, který je souástí systému UDS a slouží pro ízení z místa centrálního velína. Terminál pitom plní dv základní funkce: Zápis denního výkazu Provedení odetu spoteby materiálu formou malé inventury 16

Souasn mžeme operace zápisu denního výkazu taktéž rozdlit do nkolika inností: Zápis len osádky Zápis prbhu produkce (pomocí pracovních kód) V prvním pípad jde o jmenný seznam pracovník, kteí se na produkci podílejí. Cílem je evidovat každou lovko-hodinu, která je poteba k výrob požadovaného množství. Systém tak umí rozlišit, zda se na výrob podílel zamstnanec nebo brigádník, je možné statisticky vyhodnocovat poet pracovník, kteí se na výrob podílejí a stanovovat píslušné výrobní koeficienty k posouzení výroby z hlediska plnní norem, ale také k posouzení ekonomických hledisek výroby. Toto srovnání je vyjádeno v tzv. bilanci zakázky. 3.4.1 Založení len osádky Seznam len se zakládá pomocí íselných kód lidí a smn a je ukládán do tabulky. Prostedí pro zadávání zobrazíme tlaítkem Osádka stroje z levé nabídky tlaítek. Pi založení prvního lena osádky je nutné zadat i íslo smny, v dalších zadáních zstává hodnota již pedvolena. Záznam o lenovi osádky se ukládá pomocí tlaítka Pidat. Pi správném uložení je naplnn jeden ádek tabulky na pracovní ploše. Zde je zobrazen jméno a píjmení, popis smny, asová známka píchodu a asová známka odchodu. Ta se pepoítá až ve chvíli, kdy pracovník opustí pracovišt. Obr. 3-13 Pidání nového lena do osádky stroje Systém kontroluje duplicitu v zadání len osádky. Jakmile je týž len zadán na jiném stedisku, je z pvodního stroje (pracovišt) automaticky odebrán. V tabulce záznam zstává, ale je barevn zvýraznn. To samé platí i v rámci jednoho pracovišt. Pokud zadám záznam duplicitn, systém v prvním kroku lena nejprve odebere a pak znovu pidá v asové návaznosti, ímž nedochází k duplicit hodin strávených na pracovišti. 17

3.4.2 Odebrat lena z osádky Každý len osádky mže být ze seznamu odebrán. Existují celkem dva zpsoby jak je možné lena z osádky stroje odebrat: Odepíši jej sám ze svého seznamu Pipíše si lena jiný strojmistr na jiné pracovišt V prvním pípad je nutné oznait ádek lena osádky (umístit zde kurzor), který chceme ze seznamu odebrat. Potom klávesou Del (Delete) provedeme akci, které lena v seznamu deaktivuje a barevn zvýrazní. Souasn se dopoítá as odchodu. V druhém pípad staí, když lena zapíše jiný strojmistr na jiném stroji. Jakmile aktualizujeme zobrazení tabulky (viz. další kapitola) objeví se nám zvýraznní indikující na skutenost, že osoba byla ze seznamu odebrána. Stejn jako v pedchozím pípad je i zde uložena hodnota odchodu, která je souasn hodnotou píchodu pracovníka na jiné pracovišt. Tím nevznikají v systému žádné asové prodlevy pracovník pi pecházení z jednoho pracovišt na druhé. 3.4.3 Vyhledání lena v seznamu Obr. 3-14 Odebraný len osádky (Barbora Nmejcová) V pípad, že pro zadání lena osádky neznáme personální íslo UDS, máme možnost provést vyhledání zadáním píjmení nebo jen jeho ásti. Ukažme si, jak v seznamu najít všechny Nováky, které bychom mohli do seznamu pidat. Nejprve je dležité umístit kurzor do libovolné buky tabulky len osádky. Pak stiskneme kombinaci kláves Ctrl+F. Systém zobrazí dialogové okno pro hledání, které nám umožní osoby najít (zadáním píjmení) a následn postupn do seznamu len osádky také vložit. 18

Obr. 3-15 Dialogové okno pro hledání osob Vyhledání je jednoduché: Staí zadat píjmení nebo jen jeho ást do píslušného políka a pokraovat tlaítkem Najít, které vyhledá požadované záznamy a zobrazí je v tabulce. Pomocí klávesy Tab se pak pepneme do tabulky (nebo do ní klikneme myší) a vybereme ádek, který chceme vložit do seznamu len osádky. Vložení provedeme tlaítkem: Do výkazu. Obr. 3-16 Výsledek hledání píjmení Novák Výbr ádku (osoby), který chceme vložit do seznamu len osádky se provádí bu kliknutím na libovolný sloupec v požadovaném ádku nebo pomocí šipek, které nám pohyb v tabulce umožují. Je pitom jedno, která buka v ádku je oznaena (zvýraznna modrou barvou). V našem pípad je oznaen první ádek, takže tlaítko Do výkazu by do seznamu len osádky vložilo Miroslava Nováka. Dialog pitom zstává stále aktivní, takže mžeme dále vyhledávat, nebo vybrat ze seznamu jiný ádek a opt vložit do seznamu len osádky. 19

Pokud chceme hledání ukonit, použijeme tlaítko Zavít, které zave dialogové okno pro hledání a vrátí nás zpt do zadávání denního výkazu. 3.4.4 Založení položky výkazu Položkou výkazu se rozumí zadání kombinací hodnot pracovního kódu a verze zakázky, kterou na pracovišti zpracováváme. Formulá pro zadání tchto hodnot zobrazíme nejprve tlaítkem Položky výkazu ze seznamu vlevo na pracovní ploše. Do editaních polí zadáme postupn: Pracovní kód Verzi zakázky Vždy, když opustím zadávací editaní pole, zobrazí systém popisek zadaného kódu, pokud jsou hodnoty kód zadány správn. Pokud ne, políko je prázdné, což indikuje chybu v zadání. Pak je možné, že íslo je formáln správné, systém jej ovšem nezná. Hodnoty se ukládají do tabulky pomocí tlaítka Uložit zmny. Pokud je založení provedeno úspšn, objeví se nový ádek v tabulce. Uživatelé tak neztrácejí pehled o tom, jaké hodnoty byly až do tohoto okamžiku zadány. Obr. 3-17 Zadání pracovního kódu a verze zakázky V prbhu smny je možné kódy libovoln mnit, je možné mnit i ísla zakázek. V pípad zmny pracovního kódu, kdy pvodní je tzv. produkní, vyžaduje systém zadání potu vyrobených kus. 3.4.5 Pihlášení na jiném terminálu Jestliže z jakéhokoliv dvodu potebujeme dokonit nebo jen upravit váš denní výkaz na jiném poítai (terminálu), je možné tak uinit. Pravdpodobn na jiném terminálu bude rozpracovaný jiný výkaz. V takovém pípad potebujeme zobrazit pihlašovací obrazovku, abychom se mohli pihlásit a zobrazit tak náš výkaz. 20

Z nabídky tlaítek vlevo zvolíme Pihlášení. Systém práci stávajícího výkazu neukoní, pouze jej skryje a umožní jinému uživateli, aby zobrazil svým pihlášením vlastní výkaz, který pak mže upravit. Pi každé zmn pracovního kódu nebo zakázky systém pepoítá asy postupné a vyjádí tzv. as jednotlivý, tedy v hodinách. Mže se stát, že napíklad pro hodnoty 10:00 12:00 systém vyjádí celkový jednotlivý as jako 1,5 hod. Toto není chyba! Systém z intervalu pouze odeetl pestávku na obd podle zadání v záhlaví výkazu. 3.4.6 Ukonení výkazu Denní výkaz ukonujeme v pípadech že: Strojmistr, který píše denní výkaz, koní smnu. Strojmistr pechází na jiné pracovní stanovišt. Denní výkaz ukoníme snadno pomocí tlaítka Ukonit výkaz. Systém v daném okamžiku provede nkolik operací. Nejprve se dotazuje, zda chceme výkaz opravdu ukonit. Pak ukoní aktivní záznamy len osádky a všem dopoítá as odchodu. Zkontroluje, zda je poslední zadaný pracovní kód produkní a pokud ano, vyžádá si množství. Ukoní otevený as posledního zadaného pracovního kódu, spoítá jednotlivý as a ukoní denní výkaz. Zobrazí seznam materiál, které by se mly nacházet na pracovišti a pedvolí poslední zmnný stav. Po zadání inventury (viz. následující kapitola) se zobrazí pihlašovací obrazovka. 3.4.7 Zadání spoteby materiálu Spoteba materiálu se zadává formou inventury. Strojmistr nezapisuje tedy faktickou spotebu, ale udává hodnoty stavu materiálu v daný okamžik. Systém na základ hodnoty minulé a souasné rozdílem tchto dvou vyjádí spotebu, pokud je minulá hodnota vtší než souasná. O provedení inventury je také založen záznam v podob inventárního archu. Tsn ped ukonením výkazu je zobrazen formulá pro zadání stav materiál. Zde je teba vyplnit hodnoty ve sloupci Stav. Tlaítkem Uložit zmny systém vygeneruje soubor transakcí spoteby materiálu, pokud platí, že hodnota ve sloupci Systém je menší než hodnota ve sloupci Systémový stav. Zmny se ukládají pohybem šipky dol, v posledním ádku potom pohybem šipky nahoru. 21

Obr. 3-18 Inventární zadání stavu materiál. 3.4.8 Podmínky a kontrola realizace spoteby Zadání vlastní spoteby materiálu je pro pracovníka obsluhujícího terminál pomrn jednoduché a pedevším asov nenároné. Takový stav ovšem pedpokládá, že jsou splnny nkteré podmínky, které zaruují zdárný prbh zadání spoteby. Materiál, který se v terminálu vyísluje v tabulkovém zobrazení, a u kterého se pedpokládá zadání aktuálního stavu tak, aby systém mohl provést generování transakcí spoteby na základ rozdílu hodnot skutené a systémové, se musí systémov evidovat a to pedevším ve smyslu pohybu z hlavního skladu na produkní sklad ke konkrétnímu stroji (na konkrétní pracovišt). Kmenová data materiálu jsou dávkov aktualizována podle záznam uložených v systému SAP, který v oblasti materiálového hospodáství figuruje v souboru systémových ešení závodu jako majoritní, pestože jeho výrobní moduly spolenost z finanních dvod nevyužívá (modul PP není implementován). Na druhou stranu díky autonomnímu chování UDS je možné celý proces replikovat a vracet tak získané hodnoty spoteb do SAP tak, aby etzec modulu MM byl kompletní. Dochází tak k integraci UDS do SAP a naopak, tento proces funguje automaticky v obou smrech. Systém SAP poskytuje UDS kmenová data materiál, se kterými systém dále pracuje a vrací zpt hodnoty spoteb, které vznikly na základ využívání terminálových aplikací na pracovišti. Protože je systém UDS zcela autonomní, je možné i zde realizovat veškeré pohyby spotebního materiálu. S ohledem na skutenost, že ást z nich je realizována pomocí SAP (píjem materiálu na sklad), realizuje se pomocí UDS pouze další krok pedevším vyskladnní materiálu podle požadavk výroby. Toto vyskladnní zaruí, že je možné v každém okamžiku stanovit systémový stav materiálu na konkrétním pracovišti. V porovnání se skuteným stavem pak mžeme rozdílem obou hodnot stanovit spotebu a to v libovolném okamžiku výroby. 22

Proces peskladnní spotebního materiálu (lepidlo a fólie pedevším) se provádí formou materiálové žádanky, kterou smnový mistr vystaví a pipraví tak podklad pro skladníka. Ten na základ stavu daného (nebo daných) materiálu provede vyskladnní a to bu požadovaného množství nebo množství jiného, pokud napíklad skladová zásoba požadavku nestaí. Toto množství potvrzené žádanky je smrodatné pro vznik transakce peskladnní, která je realizována opt dokumentem pohybuje se dvma položkami: Výdej z hlavního skladu Píjem na produkní sklad Výdej je realizován na hlavním skladu a snižuje stav zásoby, píjem je proveden na tom pracovišti (produkním skladu), kde byl proveden závoz. V daném okamžiku také terminál registruje zmnu stavu zásob na pracovišti. Spoteba materiálu se tak pehledn realizuje i v pípad, že je pracovišt opakovan bhem dne zaváženo spotebním materiálem. Obr. 3-19 Založení materiálové žádanky V okamžiku, kdy smnový mistr zpracuje požadavek na doplnní stavu zásob, je do logistiky odeslán automatický e-mail s pipomenutím na vyízení tohoto požadavku. Tato operace spoívá pouze v doplnní skuten vydaného množství a potvrzením, že píslušný ádek v požadavku byl zpracován. Systém pak pi uložení provedených zmn vygeneruje dokument pohybu s požadovanými transakcemi (pro každou položku požadavku vždy výdej ze skladu a píjem na produkní sklad). Tímto zpsobem se v prbhu smny aktualizuje systémový stav spotebního materiálu na všech pracovištích a zárove mže být provádnou inventurou stanovena (z rozdílu skutené a systémové hodnoty) spoteba. Spolen s dokumentem pohybu vzniká již pi zadávání inventárních hodnot pomocí terminálu záznam o provedené inventue (inventární arch), takže je možné kdykoli provit, jak byla tato innost ze strany strojmistra, který terminál obsluhuje, provedena. Je možné jednoznan urit, zda strojmistr zadání provedl, nebo jen opsal systémové hodnoty. Je totiž nepravdpodobné, že v dob produkce nedojde bhem smny k takovému úbytku napíklad 23

lepidla, aby se to neprojevilo v zadání spoteby. Inventární arch dokumentuje jednak kdo odeet provedl, na kterém pracovišti (produkním skladu) a v poznámce také pod kterým denním výkazem. Je tak možné vysledovat, jaká byla produkce dané smny a usoudit, zda odeet je reálný i nikoli. V každém pípad by pi kontrole po provedení odetu spoteby materiálu mlo být množství materiálu na pracovišti práv rovno systémové hodnot. Obr. 3-20 Inventární arch generovaný pi zakládání spoteb materiálu 3.4.9 On-line monitorování produkce Vývoj systému UDS jako podnikového informaního systému spolenosti reus s.r.o. schlott gruppe si podle projektové dokumentace kladl za cíl vytvoit efektivní sledovací nástroj, který by umožnil vedoucímu výroby nejen monitorovat vlastní produkci, ale pedevším získávat aktuální data a na základ pedané informace mít tak možnost lepšího rozhodování v operativním ízení výroby. K tomu výrazn napomáhá terminálová aplikace pro vedení snímku pracovního dne ety (pracovn nazvaném denní výkaz). Centrální on-line monitorovací modul UDS získaná data pomocí terminálu okamžit vyhodnocuje. Navíc je terminál vybaven také tecím zaízením (fotobukou), která pedává data o vyrobeném množství. Monitorovací modul a datový terminál, umístný na pracovišti, spolu vytváejí systém onli sledování výroby. V první fázi, která je závislá na obsluze terminálu, zaíná pracovník (strojmistr) zapisovat svoji smnu. Po pihlášení do terminálu, který identifikuje místo plnní jeho práce, zadá strojmistr smnu a vyplní nkteré další údaje: Definuje pracovní režim. Zapíše íslo verze zakázky, kterou zpracovává. Doplní ve jmenném seznamu všechny spolupracovníky, kteí se na výrob podílejí. 24

Následn pak v prbhu smny mže zadávat zmny ve všech uvedených kategoriích. Takováto definice uruje jednoznan položky výkazu snímku jeho pracovního dne, spolen se seznamem dalších pracovník mžeme hovoit o snímku pracovního dne ety. V okamžiku zadání pracovního kódu je spuštn asova a zárove funkce poítadla, které je tvoenou jednou fotobukou zaznamenávající prchod produkt v jejím zorném poli, piemž každý takový prchod je v terminálu zapoítán jako jeden kus. asova v uritých pravidelných intervalech odesílá data a ukládá je do databáze, odkud k nim mže uživatel okamžit pistupovat. Stejn tak je využívá i druhá ást systému a to je modul on-li sledování. Pomocí UDS uživatel zvolí ze seznamu aktuálních (otevených) denních výkaz ty, které chce sledovat. Poet monitorovacích oken, ve kterých se informace o výrob zobrazují, není omezen. Doporuuje se volit poet vhodn s ohledem na velikost obrazovky (4-6). Na jednom monitoru tak mže uživatel sledovat i 6 stroj souasn. V pípad hardwarového vybavení velína lze pedpokládat, že stedisko používá více monitor pro sledování. Pro zvolené stroje systém vyobrazí nkteré základní informace o výrob, pedevším pak: Pracovní režim Jméno strojmistra Verze a zakázka Poet len osádky stroje Poet vyrobených kus Statistické ukazatele Obr. 3-21 Obrazovka on-line monitorování produkce 25

Pracovní režim je v záhlaví tabulky barevn podkreslen, takže barva rychle indikuje základní režimy práce jako je: Seízení Produkce Ostatní pomocné a ztrátové asy Statistické ukazatele kumulovan zobrazují: Poet kus vyrobených za hodinu Poet díl zpracovaných za lovko-hodinu Poet kus zpracovaných za lovko-hodinu Aktualizace zobrazení probíhá v nastavených intervalech. Modul pro monitorování disponuje opt asovaem, který v pravidelných intervalech hledá aktuální data na serveru a následn je zobrazuje. Ve stejný okamžik dochází také k zakreslení grafických hodnot všech sledovaných veliin statistických ukazatel. Obr. 3-22 Grafické vyjádení sledovaných veliin Grafický prbh je kumulativní, takže se poslední zobrazená hodnota shoduje s íselnou hodnotou zobrazenou v tabulce. Od prbhu grafu je možné usuzovat, zda nedochází k prostojm, které by se do zobrazení promítaly klesající kivkou, jak je tomu vidt na obrázku. Souasn by také mla být v monitorovací tabulce patrná zmna pracovního režimu a to dokonce erven podkreslená. 3.5 Logistické operace s hotovými výrobky Identifikace hotových výrobk vychází z identifikace jednotlivých palet pomocí záznam paletových lístk. Ty jsou nositelem informace nejen o množství, ale pedevším také o stavu, ve kterém se paleta nachází a samozejm píslušném zaazení k uritému transportu, verzi a tudíž i k zakázce. Definice paletových lístk je souástí definice transport. V okamžiku založení paletových lístk dochází k jejich tisku. Takto vytvoené záznamy identifikují množství palet, které je teba vyrobit. Souasn jsou tyto distribuovány do výroby. Je-li vyrobena paleta 26

(první pedepsané množství), je oznaena paletovým lístkem a putuje na stanovišt, kde bývá zpravidla ovinuta fólií a zde také oznaena jako vyrobená. Protože se pracovišt nachází ve skladovacích prostorách, je každá taková paleta automaticky oznaena také jako naskladnná. (Což je formáln správné, nebo se v okamžiku ovinutí fyzicky nachází na sklad.) Proces pijmutí palety na sklad, ovinutí a oznaení daného množství jako vyrobeno zajišuje terminálová stanice umístná u balicího stroje. Obsluha nejprve sejme útržek z paletového lístku (zpravidla se distribuují lístky dva pro pozdjší skenování pi expedici) a provede skenování árového kódu, který paletu jednoznan identifikuje v systému. Tím je paleta oznaena nejen jako vyrobená, ale pedevším také naskladnná a je možné s ní dále manipulovat ve smyslu expedice. (Pozdji zjistíme, že pokud se tato procedura neprovede, systém neeviduje paletu jako vedenou ve skladu, potažmo vyrobenou a nebude možné ji expedovat. Pak je nutné tento krok uinit dodaten.) Popsaný proces je možné provádt také obrácen, to znamená vracet paletu zpt do výroby. Systém pi identifikaci palety kontroluje její stav a neumožuje naskladnit paletu dvakrát. V pípad, že se paleta již (systémov) na sklad vyskytuje, umožní pouze její vrácení do výroby nebo je možné celou operaci stornovat. Sledování výrobk na paletách v prbhu výroby vychází práv ze zmny stavu definovaných paletových lístk pro hotové výrobky. V prbhu produkce se tak množství generovaných palet ve stavu nová postupn snižuje, pibývají záznamy se stavem vyrobeno/na sklad a procesem expedice se tyto opt mní na stav expedováno. Vždy je díky konzistentní kontrole zachován celkový poet palet definovaného transportu, mní se pouze poty v jednotlivých stavech, než nakonec pejdou všechny záznamy palet do stavu expedováno. Proces je zajištn modulem pro skenování hotových výrobk, který obsluhuje pracovník na balicím stroji ve skladu. Souasn tak odpovídá za množství, které naskladnil a oznail jako vyrobené. Obr. 3-23 Skenování palet s hotovými výrobky 27

3.6 Expedice Stejn jako v pedchozím pípad je také expedice logistickým procesem hotových výrobk (potažmo palet), který vychází z definice paletových lístk v uritém transportu verze zakázky. Prakticky je tato operace ešena ve dvou krocích: Založení píkazu expedice Skenování expedovaných palet V pípad prvním je pro definici píkazu k expedici minimáln nutná definice transportu. V této ásti pracovník logistiky zakládá záznam jakéhosi pseudo-dodacího listu, který neobsahuje žádné položky k peprav, pouze definuje místo doruení a pepravní spolenost. Podobn jako v pípad definice píjmu, i zde uživatel vypluje i nkteré informace historicky se vztahující k správ pepravy výrobk a zboží v euro-zón (INTRASTAT). Píkaz k expedici definuje transport nebo skupinu transport, ze kterých mohou být palety nakládány do návsu tahae. Souasn s definicí transport, která se provádí výbrem ze seznamu podle zvolené zakázky a verze, což výrazn urychluje zpracování tohoto dokumentu, zadává pracovník také poet palet, které je teba pro konkrétní transport distribuovat. Tím je zajištno, že nedojde k zámn palet z jiných transport, ale také to, že bude do tahae naloženo práv požadované množství palet z konkrétního definovaného transportu. Výbr místa dodání mže být volen uživatelem, nebo se ídí výbrem transportu. (Opt se jedná o vlastnost systému k zefektivnní provádní této innosti, nebo každý transport vždy místo doruení obsahuje.) Poet transport, které mohou být vybrány do píkazu expedice není omezen. Obr. 3-24 Výbr transportu pro píkaz k expedici 28

Založený píkaz k expedici pracovníkem logistiky je postoupen dál pracovníkovi ve skladu, který na základ jeho definice provede naložení potebných palet. Tuto operaci provází také skenování paletových lístk hotových výrobk, piemž dochází k formální kontrole v nkolika bodech, kdy systém proví: Stav palety Transport, kterému paleta písluší Celkový naložený poet palet V prvním pípad jde o to, že není možné naložit paletu, která v systému není vedena jako na sklad/vyrobená. V takovém pípad systém hlásí chybu a je nutné toto operaci dodaten provést skenováním na pracovišti balení ve skladu. Pouze paleta, jejíž stav odpovídá, tedy byla vyrobena a nachází se na sklad, mže být dále použita pro transport. Souasn systém proví, jestli skenovaná paleta náleží transportu, který je definovaný v píkazu expedice. Pouze v pípad jednoznané shody (identifikaní íslo transportu) je proces proveden. Navíc musí být splnna ješt podmínka potu. Tato podmínka není tzv. tvrdá, takže systém uživatele pouze informuje, že napíklad pekroil povolený poet k transportu a je na jeho uvážení, zda chyba nevznikla na stran pracovníka logistiky, který poet transportovaných palet zadal chybn. Jinak eeno, v pípad neshody systém umožní uživateli pokraovat ve vyízení procesu expedice, upozoruje ho ovšem varovnou poznámkou, že množství neodpovídá definici v píkazu expedice. Pi splnní všech tí podmínek je databázový záznam skenovaného paletového lístku pidružen k píkazu expedice, ímž z nj iní formáln správný dodací list a souasn je zmnn stav palety. Opt platí pravidlo, že celkový poet palet definovaných pro transport urité verze zakázky se nemní, mní se pouze stav, takže poet palet nacházejících se ve skladu klesá, oproti tomu roste poet expedovaných. Formální zpracování píkazu k expedici mže provádt zaškolený pracovník skladu. Pomocí terminálu, který je umístn v expediní ásti skladu nejprve skenuje árový kód píkazu k expedici, který je souástí jeho tištné podoby. Následn pak dochází postupn ke skenování všech palet, které se nakládají, piemž systém vždy provádí konzistentní kontrolu, jak bylo popsáno výše. Zpracování píkazu k expedici je ukoneno v okamžiku tisku dodacího listu, který je pak pedán dopravci. Systém automaticky pipraví obrazovku pro úpravu dalšího píkazu k expedici. Dokumenty píkaz k expedici mže pracovník logistiky pipravit s pedstihem. V takovém pípad, kdy mu není známa SPZ vozidla, mže tuto ást dopracovat pracovník skladu pi zpracování píkazu. Takové pípady nastávají pi víkendových transportech, kdy jsou v pátek pracovníkem logistiky podle plánu vývozu generovány píkazy k expedici, které skladník zpracuje a doplní chybjící údaje o SPZ až v okamžiku nakládky. Pedpokládá se, že dopravce je znám. 29

3.7 Fakturace Obr. 3-25 Skenování palet hotových výrobk pi expedici Modul fakturace výrazn posiluje funknost informaního systému UDS a umožuje bilancování jednotlivých zakázek s ohledem na hodnotu skutených náklad. Navíc optimalizuje vlastní proces fakturace a snižuje procento chyb, které doposud ešilo oddlení útárny. Pitom systém neeší pouze vlastní proces vyhotovení dokladu (A už se jedná o fakturu nebo jiný druh s tím spojený jako mže být dobropis, storno dokladu, zálohová faktura aj.), ale pedevším nabízí optimalizovaný nástroj s celou adou konzistentních kontrol a kontrol formální správnosti, které v pedchozích zpsobech zpracování nebyly možné. Pínos pro hodnocení systému jako celku je zejmý: Fakturace nabízí další lánek logistického etzce a odráží další ást procesu ízení výroby, ímž dává systému UDS možnost nabídnout další pínosné informace. Vlastní fakturace probíhá v nkolika krocích, které bychom mohli strun charakterizovat jako Píprava faktury Kontrola faktury Uzavení a odeslání faktury 3.7.1 Píprava faktury Základní charakteristikou pípravné fáze vystavení faktury (celkový popis ásti systému si ukážeme na faktue, myslíme tím však i další druhy úetních doklad, které je možné pomocí UDS zhotovit) je fakt, že ji provádí pracovník odbytu, který spravuje uritou zakázku. V tomto kroku se ješt nedá mluvit o úetním dokladu, vzniká jakási pseudo-faktura, která je jistým návrhem, by již ve formálním provedení faktury. Tisková podoba (která je 30

nutná pro odeslání dokladu) je oznaena jako návrh, nelze ji proto použít jako formální úetní doklad. Manažer zakázky pi založení faktury definuje nejprve její hlaviku, kde uvádí Zakázku Zpsob úhrady Úet Obr. 3-26 Základní definice hlaviky faktury Systém podle pedchozí definice zakázky a podle znalosti kmenových dat zákazníka doplní nkteré další informace, jako je Píjemce faktury a odbratele (podle definice zakázky) Platební podmínku (podle definice píjemce faktury) Data dokladu (podle data založení a platební podmínky) 31