Vállalati Információs Rendszerek Szakirány

Vállalati Információs Rendszerek BSc

VállalatIrányítási Rendszerek Vállalati Információs Rendszerek Szakirány

dr. Szikora Béla [email protected]

5.44 változat

Az elektronikus változat előállításában közreműködtek 2002: Deák Viktor, Demjén Ádám, Friedmann Tamás, Markó Csaba, Nagy Péter, Szegedi Miklós, Tertsch Ágnes; 2003: Balogh Csaba, Sviszt Olivér; 2004: Bodó Péter, Nagy Lajos Tamás; 2005: Kerekes József, Sviszt Olivér; 2006: Herczeg Gábor

1 / 136


Tartalom 1. VÁLLALATI INFORMÁCIÓS RENDSZEREK FEJLŐDÉSE........................................... 5 1.1. Vállalati célrendszer.............................................................................................................. 5 1.2. A vállalati működés érintettjei .............................................................................................. 7 1.3. vállalatirányítási rendszerek helye, feladata.......................................................................... 8 1.3.1. Fejlődés az üzleti munkamegosztás nézetéből ............................................................... 8 1.3.2. Vállalatirányítási rendszerek a számítógéppel integrált gyártás megközelítésében..... 10 1.3.3. Vállalatirányítási rendszer bevezetésének legnagyobb akadályai................................ 12 2. VÁLLALAT-MODELLEZÉS, AZ ÖTRÉTEGŰ MODELL .............................................. 13 2.1. Tervezés ötrétegű megközelítésben .................................................................................... 15 2.2. Tervezési stratégiák............................................................................................................. 16 2.2.1. Teljeskörű konkurens tervezés ..................................................................................... 16 2.2.2. A feldolgozó funkciók és az informatikai funkciók konkurens tervezése ................... 17 2.2.3. A feldolgozó funkciók és az informatikai funkciók sorrendi tervezése....................... 18 2.2.4. Más stratégiák .............................................................................................................. 18 2.3. Az információs funkciók és az irányítási réteg tervezése ................................................... 19 2.3.1. Az információs funkciók rétege, rendszere.................................................................. 19 2.3.2. Irányítási réteg.............................................................................................................. 20 2.3.3. Megvalósítás hierarchikus rendszerben ....................................................................... 21 3. STANDARD INTEGRÁLT VÁLLALATIRÁNYÍTÁSI RENDSZEREK ALAPJAI....... 23 3.1. Terhelésmegosztási architektúrák ....................................................................................... 25 3.2. Standard rendszerek programozási alapelvei ...................................................................... 28 3.2.1. Bizonylatok és élettörténetük ....................................................................................... 28 3.2.2. Metódusok.................................................................................................................... 30 3.2.3. Interaktív technikák...................................................................................................... 31 3.2.4. Metódusok összefogása mozgásnemekbe és tranzakciókba ........................................ 32 3.3. Integrált rendszerek adatmodellje ....................................................................................... 35 3.3.1. Vállalati törzsadatok, cégadatok .................................................................................. 36 3.3.2. Telephelyek .................................................................................................................. 37 3.3.3. Raktárak ....................................................................................................................... 37 3.3.4. Cikkek, tételek.............................................................................................................. 37 3.3.4.1. Általános törzsadatok ............................................................................................ 38 3.3.4.2. Készletezési és tervezési adatok............................................................................ 39 3.3.4.3. Főkönyvi adatok.................................................................................................... 41 3.3.4.4. Készlethelyzet változása ....................................................................................... 41 3.3.4.5. Raktári és számviteli készletérték ......................................................................... 42 3.3.5. Termékcsalád, cikkcsoport........................................................................................... 43 3.3.6. Anyagjegyzék............................................................................................................... 44 3.3.7. Készletek, készletgazdálkodás ..................................................................................... 44 3.3.7.1. Készletgazdálkodás ............................................................................................... 45 3.3.7.2. Készletezés célja ................................................................................................... 45 3.3.7.3. A készletezés költségei ......................................................................................... 46 3.3.7.4. Készletértékelési módszerek ................................................................................. 47 3.3.7.5. Készletgazdálkodási rendszerek............................................................................ 48 3.3.7.6. Tiszta, determinisztikus modellek......................................................................... 49 3.3.7.7. Készletgazdálkodási modellek a célfüggvény tartalma szerint............................. 52 3.3.7.8. Költségminimalizálás diszkrét termék diszkrét beszállítása esetén ...................... 54 3.3.7.9. ABC készletrendszer............................................................................................. 56 4. INFORMÁCIÓS FOLYAMATOK ........................................................................................ 58 4.1. Rendelésfeldolgozás............................................................................................................ 59 2 / 136

Vállalati Információs Rendszerek BSc 4.2. Szükségletszámítás, ütemezés............................................................................................. 62 4.2.1. Szükségletszámító rendszerek...................................................................................... 63 4.2.2. MRP I. - MRP II........................................................................................................... 64 4.2.3. Elosztási erőforrás tervezés .......................................................................................... 72 4.2.3.1. A DRP törzsadatai................................................................................................. 72 4.2.3.2. A DRP működése vázlatosan ................................................................................ 74 4.2.3.3. DRP és MRP együttműködése .............................................................................. 74 4.2.4. Logisztika ..................................................................................................................... 78 4.3. Beszerzés ............................................................................................................................. 81 4.3.1. Szállítói hálózat felépítése............................................................................................ 82 4.3.2. Fogalomtár ................................................................................................................... 83 4.4. Áru beérkeztetése és Minőségi átvétele .............................................................................. 84 4.4.1. Árubeérkeztetés ............................................................................................................ 84 4.4.2. Áruátkönyvelés/szállítás a szabad készletek közé ....................................................... 84 4.4.3. Fogalomtár ................................................................................................................... 85 4.5. Számlafogadás..................................................................................................................... 86 4.5.1. Számlaellenőrzés.......................................................................................................... 86 4.5.2. Számla könyvelése ....................................................................................................... 87 4.5.3. Fogalomtár ................................................................................................................... 88 4.6. Számla kifizetése................................................................................................................. 89 4.6.1. Kifizetés ....................................................................................................................... 89 4.6.2. Kifizetés könyvelése és számlaleszámítolás ................................................................ 91 4.6.3. Fogalomtár ................................................................................................................... 91 4.7. Kiszállítás és számlázás ...................................................................................................... 93 4.7.1. Szállítólevél elkészítése................................................................................................ 93 4.7.2. Szállítás ........................................................................................................................ 94 4.7.3. Számla elkészítése........................................................................................................ 94 4.7.4. Fogalomtár ................................................................................................................... 94 4.8. A számla könyvelése és kiegyenlítése ................................................................................ 95 4.8.1. Számla könyvelése ....................................................................................................... 95 4.8.2. Fizetés beérkezés könyvelése és számlaleszámítolás................................................... 97 4.8.3. Bizonylatok életciklusa ................................................................................................ 97 4.9. Előleg- és részletfizetés....................................................................................................... 98 4.9.1. Előleg-és részletfizetési követelmény .......................................................................... 98 4.9.3. Vevői végszámla elkészítése és könyvelése................................................................. 99 4.9.4. Szállítói végszámla fogadása és könyvelése .............................................................. 101 4.9.4. Bizonylatok életciklusa .............................................................................................. 103 4.9.5. Fogalomtár ................................................................................................................. 103 4.10. Befektetett eszközök kezelése......................................................................................... 104 4.10.1. A befektetett eszközök osztályai és fontosabb alosztályai....................................... 104 4.10.2. A tárgyi eszközök információs folyamatai............................................................... 105 5. SAP MYSAP ERP .................................................................................................................. 110 5.1. A mySAP ERP főbb funkcionális moduljai...................................................................... 111 5.2. A mySAP ERP rendszer alapjai ........................................................................................ 112 5.3. Rendszer, mandant (kliens), vállalat és domain................................................................ 112 5.4. A rendszer magas szintű adatmodellje .............................................................................. 115 5.5. Testreszabás ...................................................................................................................... 116 5.6. Fejlesztés ........................................................................................................................... 116 5.6.1. Data Dictionary .......................................................................................................... 117 5.6.2. Futtatható objektumok................................................................................................ 117 5.6.3. Fejlesztői Eszközök.................................................................................................... 118 5.6.4. Aktiválás..................................................................................................................... 118 3 / 136

Vállalati Információs Rendszerek BSc 5.7. Change And Transport System ......................................................................................... 119 5.8. Futtatási környezet ............................................................................................................ 122 5.8.1. Architektúra................................................................................................................ 122 5.8.2. Működés ..................................................................................................................... 123 5.8.3. Adatbázis-elérési módok, az Open SQL .................................................................... 123 5.8.4. Workprocess típusok .................................................................................................. 124 5.8.4.1. Az adatbázis-frissítés folyamata ......................................................................... 125 5.8.4.2. Zárkezelés ........................................................................................................... 126 5.8.4.3. Background batch process................................................................................... 127 5.8.4.4. Spool process ...................................................................................................... 127 5.9. Interfész technikák ............................................................................................................ 127 5.9.1. Alkalmi interfészek .................................................................................................... 127 5.9.2. Állandó interfészek .................................................................................................... 128 5.10. A mySAP ERP tulajdonságai .......................................................................................... 130 6. A QAD ENTERPRISE APPLICATION VÁLLALATIRÁNYÍTÁSI RENDSZER........ 131 7. RENDSZERINTEGRÁCIÓ.................................................................................................. 134 7.1. Az integrációs kényszer kialakulása ............................................................................. 134 7.2. Fizikai összeépítés......................................................................................................... 134 7.3. Alkalmazásintegráció .................................................................................................... 136 7.4. Szemantikával bővített vállalati alkalmazások integrációja.......................................... 136

4 / 136


1. VÁLLALATI INFORMÁCIÓS RENDSZEREK FEJLŐDÉSE A vállalat egy szervezeti rendszer, és mint ilyen, érvényesek rá a szervezeti jellemzők is. A szervezeteknek saját céljaik vannak, amelyek természetesen nem azonosak a bennük szereplő egyének céljaival, de nem is függetlenek tőlük. Az egyéni célok rendkívül változatosak lehetnek, így aligha képzelhető el olyan szervezet, amelyben a tagok valamennyi céljukat ki tudnák elégíteni. A szervezeti célok legfőbb jellemzői a következő négy csoportba foglalhatók: • A szervezeti célok hierarchikusan rendezettek. Ez szolgáltatja a szervezet számára azt a logikus és konzisztens vonatkoztatási alapot, amelyből levezethetők a szükséges tevékenységek és ezek célszerű csoportosítása, összehangolása. Minél komplexebb a szervezet, annál inkább szükség van ilyen vonatkoztatási alapra. Ennek megteremtése a menedzsment feladata. • A közös célok léte magyarázza meg a szervezetek lényegét: a szervezetek azért léteznek, mert képesek olyan dolgokat megvalósítani, amelyeket az emberek egyedül nem tudnának elérni. A közös cél fölérendelt cél, a szervezet valamennyi tagjának közös célja, amit kooperációval lehet a legjobban elérni, valamint felöleli az összes alárendelt célt is. • A szervezeti és egyéni célok kompatibilisek, ami azt jelenti, hogy szervezet hatékony működése érdekében az egyéni céloknak összeegyeztethetőknek kell lenniük a szervezet céljaival. • És végül, a célok jellemzője a kölcsönös erősítés, amelyről akkor beszélünk, ha a szervezet és a szervezet tagjai egyaránt segítik egymást céljaik elérésében: a szervezeti célok elérése hozzájárul az egyéni célok eléréséhez, és fordítva. Ha nincs kölcsönös erősítés, akkor a szervezet és a szervezet tagjai egyaránt kárt szenvednek. Az adott szervezet eredményessége attól függ, hogy a szervezet milyen mértékben éri el céljait. Valószínűleg egyetlen szervezet sem éri el valamennyi célját, ha azonban a szervezet mégis fennmarad, ez nyilvánvalóan azt jelenti, hogy a célok elérésének hatásfokát néhány személy legalább részlegesen hatékonynak tartja. Fejlett társadalmi tudattal rendelkező közösségben a morális célok követése is pozitívan hathat az eredményességre, mert a közösség honorálja az etikus viselkedést: például a fogyasztó inkább jó hírű vállalattól vásárol, vagy hajlandó megfizetni a termék környezetbarát előállításából adódó többletköltséget is.

1.1. VÁLLALATI CÉLRENDSZER A vállalati célrendszer legfőbb tulajdonsága annak többdimenziós volta. A választott nézőpont függvényében többféle célstruktúrát is meghatározhatunk, melyek saját belső logikával rendelkeznek, és egymással szorosan összekapcsolódnak. A célstruktúrák egy része hierarchizált, más nézőpontból viszont az egyes célok egymás mellé rendelve működnek. Az 1.1. ábrán bemutatjuk egy vállalat legfontosabb hierarchikus és egymás mellé rendelt funkcionális céljait. A vállalati célok jellemzésére elmondható, hogy: • a valóságban megjelenő célok a különböző nézőpontok valamilyen metszetében értelmezhetők, a többdimenziós rendszer egy pontjaként, • a konkrétan megfogalmazott céloknak a struktúrában elfoglalt helye változhat (azaz ugyanaz a cél más prioritást kaphat a feltételek változásának függvényében), • a hierarchikus rendezésben a magasabb rendű cél elérésének feltétele az alacsonyabb rendű cél(ok) elérése, 5 / 136

Vállalati Információs Rendszerek BSc •

a célok és feltételek (eszközök) között nincs éles határvonal, egymásba át is mehetnek – ami egy időpontban vagy összefüggésben cél, az a másik időpontban vagy vonatkozásban eszköz (például a folyamatos anyagellátás a logisztikai rendszer számára cél, a termelési funkció szempontjából eszköz).

1.1. ábra Vállalati célok strukturálása [Forrás: Chikán Attila, Vállalatgazdaságtan, Aula Kiadó] A célhierarchia csúcsán – ahogy azt az 1.2. ábra is mutatja – az alapvető cél, a vállalkozás üzleti célja áll. Ilyen lehet például, hogy milyen fogyasztói igények kielégítése a cél, nyereség elérésével együtt. Ehhez több tényezőre van szükség: tőkére, kielégítésre váró fogyasztói igényre, a fogyasztói igénynek megfelelő termékre/szolgáltatásra, alkalmas személyzetre stb. Reális és fontos cél lehet egy vállalat számára, hogy a költségek és az ár csökkentésével termékét egyre szélesebb kör számára tegye elérhetővé. Nagyon valószínű, hogy ennek eléréséhez a célhierarchia alsóbb szintjén rögzített folyamatfejlesztési célok hatékony megvalósítása szükséges. A vállalat küldetésében tipikusan az fogalmazódik meg, hogy a vállalat alapvető célját (a fogyasztói igények kielégítését és a nyereséget) milyen úton, milyen fő tevékenységeken keresztül, milyen működési elvekre építve szándékszik elérni. Egy vállalat küldetése általában az alábbiakat tartalmazza: • Rögzíti a vállalat működési körét, és hogy azzal milyen fogyasztók milyen igényeit kívánja kielégíteni. • Megfogalmazza jövőképét, azaz hosszabb távon milyen piaci szereplővé kíván válni. • Belső működési elveket határoz meg (pl. környezet- és minőségtudatos magatartás), és célul tűzi ki azok következetes betartását, fejlesztését. • Meghatározza a működése által érintett személyekkel (tulajdonosokkal, alkalmazottakkal, fogyasztókkal, beszállítókkal stb.) való kapcsolat alapelveit, és mint célt rögzíti az érintettekkel való harmonikus együttműködést. A vállalat küldetéséből és a vállalati működés érintettjeinek céljaiból származtathatók a vállalat átfogó, hosszú távon is tartós céljai, melyek részletezik, hogy mit kell teljesítenie a szervezetnek küldetése megvalósításához. E célok folyamatos megvalósításában az érintettek

6 / 136

Vállalati Információs Rendszerek BSc közvetlenül is érdekeltek, s ezeken keresztül váltható valóra a küldetés és végső soron az alapvető cél (nyereség, jó imázs, gyors reakciók és rövid átfutási idő, növekvő piaci részesedés stb.) is. A célok következő, az átfogó célokból levezethető szintjéhez a közvetlen, irányítási célok tartoznak, melyek például egy adott reakció vagy átfutási idő csökkentéséhez, egy reklamáció lebonyolításához vagy például az érdekeltségi rendszerhez köthetők. Végül a legalsó szinten az operatív működési célok helyezkednek el – ezek egy-egy akció eredményére vonatkoznak (például egy munkadarab legyártása, valamilyen anyag beszerzése stb.) Alapvetõ cél

Küldetés

Távlati, tartós célok

Közvetlen irányítási célok

Operatív mûködési célok

1.2. ábra A vállalati célok hierarchiája

1.2. A VÁLLALATI MŰKÖDÉS ÉRINTETTJEI A vállalati működés érintettje minden olyan személy vagy csoport, aki/amely befolyásolja a szervezet működését, és/vagy érdekelt annak következményeiben. Két nagy csoportba sorolhatjuk őket: • •

Belső érintettek: tulajdonosok, menedzserek, alkalmazottak. Külső érintettek: fogyasztók, szállítók, versenytársak, stratégiai partnerek, állami intézmények, helyi és önkéntes állampolgári közösségek, természeti környezet.

Az emberek egyéni céllal rendelkeznek, s azért kapcsolódnak a vállalathoz, azért vesznek részt tevékenységében, mert úgy vélik, ez elősegíti céljaik elérését. A belső érintettek csoportjai is eltérő érdekekkel rendelkeznek, így eltérőek azok a célok is, amelyeknek megvalósítása érdekében a vállalkozáshoz kapcsolódnak. A tulajdonosok leginkább befektetett tőkéjük növekedésében érdekeltek, a menedzserek a vállalat sokoldalúan eredményes működésében és a vállalat küldetésének megvalósításában, az alkalmazottak pedig személyes jövedelmük maximalizálásában, hosszú távon és tartósan. A belső érintettek törekvéseiből bonyolult szervezeti – szociológiai folyamatok során alakulnak ki a vállalat hosszú távon is tartós céljai, míg a külső érintettek céljaiból származtatható az a feltételrendszer, amelyben a vállalat működik, s amely hosszabb távon a vállalati célokat is befolyásolja. A külső érintettekkel való kapcsolatot és ezek hatását a vállalatra külön elmélet, a kontingencia-elmélet vizsgálja, írja le.

7 / 136


1.3. VÁLLALATIRÁNYÍTÁSI RENDSZEREK HELYE, FELADATA Helyük és feladatuk meghatározása kétféle megközelítésben tárgyalható: CIM (Computer Integrated Manufacturing – számítógéppel integrált gyártás) megközelítésben, amely a számítógépek vállalati alkalmazásának legmagasabb szintű rendező elve. Üzleti döntéstámogatás szemléletű megközelítés.

1.3.1. Fejlődés az üzleti munkamegosztás nézetéből A kezdetek: Totális rendszerek megvalósításának nem voltak meg a szükséges feltételei: - nagy teljesítményű adatbáziskezelők - stabil szervezeti struktúra - elfogadható fejlesztési és karbantartási költségek - a valódi vezetői munka pontos ismerete Később részleges információs rendszereket hoztak létre elszigetelt rendszerek szűk vállalati funkciók támogatására Fejlődésüket és alkalmazásukat az 1.3. ábra szemlélteti:

Döntés /Tett

Felsővezetők

ESS EIS

Ismeret

Elemzők

DSS DSS DSS

Információ

Funkcionális középvezetők

MIS MIS MIS

Adat

Végrehajtók

Tudás szintek

Döntési szintek

EDP

EDP

EDP

Rendszerek (részleges fejlesztések)

Tranzakcióorientált integrált rendszerek

Következő generáció

1.3. ábra Vállalati információs rendszerek kialakulása Döntési szintek Végrehajtók, operatív irányítók Szűk területen, elemi tranzakciók adattárából dolgoznak. Funkcionális középvezetők A vállalat egy-egy funkcionális területéről származó összetettebb információk birtokában operatív kérdésekben döntenek. Elemzők (controlling, marketing) A vállalat minden tevékenységét elemzik, a lehetséges stratégiai döntéseket készítik elő. A külvilág kevésbé strukturált információit összevetik a vállalat több területéről statisztikai

8 / 136

Vállalati Információs Rendszerek BSc módszerekkel nyert adataival (átlag, eltérés, trend stb.). Taktikai és folyamatszabályozási kérdésekben döntenek. Felsővezetők Eseti stratégiai döntéseket hoznak összevont vállalati adat birtokában, sok bizonytalan külső információ alapján. Ezekhez a szintekhez fejlesztettek rendszereket, megvolt a tudás és a hardware is. Rendszerek EDP (Electronic Data Processing – Számítógépes adatfeldolgozás) Célja: a manuális munka kiváltása, automatizálása. MIS (Management Information System – Vezetői információs rendszer) Adott (előre meghatározott) formátumú jelentések (pl. forgalom, nyereség) rendszeres elkészítése funkcionális középvezetők részére. DSS (Decision Support System – Döntéstámogató rendszer) Félig strukturált döntési helyzetek, bizonytalan választási lehetőségek támogatása. Átfogó, adhoc lekérdezések, várható eredmények statisztikai elemzése. Módszerei: modellezés, szimuláció, statisztikai elemzések táblázatkezelőkkel és szakértői rendszerekkel. ESS (Executive Support System – Felsővezetőket támogató rendszer) Vállalatra és személyre szabott rendszer, a vállalat múltbeli működéséből nyert összevont információkat állít elő. Ezek a rendszerek egymástól elkülönítve működtek funkcionálisan és vezetési szintenként is. Többször kell beírni ugyanazt az adatot Nem menedzselhető a változás Következmény: Az eltérő adatok alapján nem lehet következetes vezetői döntéseket hozni A vállalati folyamok nem követhetők végig Következő generáció Megoldás: tranzakcióorientált vállalatirányítási rendszerek. Horizontálisan minden funkcionális és üzleti tevékenységre kiterjednek Vertikálisan a régi értelemben vett EDP és MIS típusú rendszereket foglalják magukba és egyre inkább integrálják a DSS-t A piramis jellemzői: Moduláris felépítés, őrzik a funkcionális specializáció nyomait De: A modulok átjárhatók Közös adatbázisra támaszkodnak (ezért minden adatot csak egyszer, a keletkezés helyén kell bevinni) A folyamatok teljesen lekövethetők bennük EDP-MIS összeolvadt, nincs szükség külön EDP-re (kivéve pl. ELMŰ számlázás) Integrálják a DSS-t Megvan a lehetőség az elemzők és a felsővezetők igényeinek kielégítésére is: EIS (Executive Information System – Felsővezetői információs rendszer) (eltérőek a célok és feladatok, de azonos számítógépes rendszert (adatbázist) használnak) Döntéstámogató rendszerek átalakultak

9 / 136

Vállalati Információs Rendszerek BSc • • •

Intézmény-specifikussá váltak Nagygépről kisgépre, vagy PC-re kerültek át Új technológia jelent meg „Ad hoc” lekérdezésre lehetőség „Mi lenne, ha ...” szimulációk DSS generátorok Új technológiai alapokon (pl. Internet) kialakultak a csoportos döntéstámogató rendszerek (GDSS – Group Decision Support System), a kollektív bölcsesség felhasználására (olyan számítógép alapú információs rendszer, amely képes nem strukturált problémák megoldásához segítséget nyújtani, döntéshozók együtt dolgozó csoportjának; HW, SW, MW – (manware) humanware – módszerek együttese) Szakértői rendszerek is továbbfejlődtek, speciális területeken használatosak. Üzleti intelligencia rendszerek Az 1990-es évektől használt átfogó megnevezés. Olyan tényalapú rendszerek, melyek támogatják a döntéshozás folyamatát. Az üzleti intelligencia rendszerek alá tartozó rendszertípusok a következők: Executive Information System (EIS): Felsővezetői információs rendszer. Decision Support System (DSS): Döntéstámogató rendszer. Enterprise Information System - Enterprise Resource Planning Systems (EIS-ERP): Vállalati erőforrás-tervező információs rendszer. Online Analytical Processing (OLAP): Online adatfeldolgozó rendszer. Data & Text Mining (DTM): Adat és szövegbányászat (az utóbbi számára az internet a legnagyobb kihívás). Data Warehousing (DW): Adattárház (gyakran összeépül az adatbányászattal). Data Visualization: Adat-vizualizációs (szemléletes megjelenítő) rendszerek (gyakran beépülnek más rendszerekbe). Geographic Information System (GIS): Térinformatika.

1.3.2. Vállalatirányítási rendszerek a számítógéppel integrált gyártás megközelítésében A számítógéppel integrált (CIM) gyártás kialakulása J. Harrington Jr.: Computer Integrated Manufacturing, New York Industrial Press, 1973. Ez a könyv a következőket írja le: A gyártó vállalatok növekedésének logikus iránya a számítógépek fokozott alkalmazása. A magas szintű automatizálás bevezetésekor felül kell vizsgálni a múltban kialakult és most is működő munkamegosztást. Az optimális vállalati működés nem érhető el lokális maximumokon keresztül, hanem totális optimumot kell elérni. A vállalatoknál bevezetett számítógépes rendszerek képesek a totális optimum létrehozását kierőszakolni. Ellenállás: a menedzsment nem értett az új technológiához (a számítógépekhez), nem értette meg a kihívást. Ezért nem mozdult 1980-ig. US Air Force: Integrated Computer Aided Manufacturing – ICAM Célja: számítógépes technológia strukturált alkalmazási módszerének kifejlesztése a gyártásban, a termelékenység lehető legmagasabb szintre való emelésére. 10 / 136

Vállalati Információs Rendszerek BSc Eredménye: 3 modellezési módszer kifejlesztése A gyártó rendszer és környezetének funkcionális modellezése A rendszer és környezetének információs modellezése A rendszer időben változó tulajdonságainak dinamikus modellezése ICAM DEFinition – IDEF írja le ezeket. Sok szoftver támogatja, mert jól dokumentált. Egysége: az aktivitás, amely az absztrakció szintjétől függően egyszerű vagy összetett funkciót jelent. Az aktivitások kapcsolatát az 1.4. ábra szemlélteti. (Vízesés-modellhez hasonló)

A1 Rendszer kényszere Rendszer input

Aktivitás megnevezése A0

A2

A3

Rendszer output

A4

Rendszer erőforrás 1.4. ábra Az IDEF formalizmus. Eleme az aktivitás, az aktivitások kapcsolódása

A számítógéppel integrált gyártás főbb területeit az 1.5. ábrán mutatjuk be. Moduljai: Számítógéppel segített tervezés és szimuláció (CAD – Computer Aided Design, CAE – Computer Aided Engineering, CAPP – Computer Aided Process Planning). Számítógéppel segített gyártás (CAM). Rugalmas gyártórendszerek (FMS). Üzleti adatfeldogozó rendszer.

11 / 136

Vállalati Információs Rendszerek BSc Üzleti rendszer főbb moduljai: beszerzés, értékesítés, gyártás, készletgazdálkodás, pénzügyszámvitel Számítógéppel segített gyártás

Projekt tervezés

Gyártástervezés

Műszaki tervezés

Folyamattervezés

Gépészeti

Software

NC gépek, robotok stb. programoz.

Belépési pont

Marketing, trendek

Eladás, rendelésfeldolgozás

Eladás becslése

Ütemezés

Terméktörzs

Állóeszközök

Könyvvitel

Eladások könyvelése

Tételes könyvelés

Leltári könyvelés

Vásárlások könyvelése

Leltározás

Vásárlás

MRP

Elektromos CAQ control

Hidraulikai (...)

Anyagjegyzék Műv. tervek Idők stb.

Raktárgazdálkodás

Egyéb analízis Műhelyirányítás

Műszaki tervek

FMS irányítás

Műszaki adatok

Gyártási költségek

Gyártás adatbázis

Szerszám Részprogram Kellék stb.

Gépkarbantartás

Munkabérek

Szállítás

Késztermék Számítógéppel segített tervezés

Rugalmas gyártórendszer

Üzleti adatfeldolgozó rendszer

1.5. ábra A számítógéppel integrált gyártás főbb területei

1.3.3. Vállalatirányítási rendszer bevezetésének legnagyobb akadályai

Megértés: 23 % Vezetői támogatás hiánya: 20 % Műszaki támogatás hiánya: 15 % Lebecsülő megközelítés: 15 % Ellenállás: 11 % Pontos kép hiánya: 9 % Követelmények rossz megfogalmazása: 7 %

12 / 136


2. VÁLLALAT-MODELLEZÉS, AZ ÖTRÉTEGŰ MODELL A modellalkotás célja az összetettség csökkentése. A vállalatot több nézetben ábrázoljuk, vizsgáljuk. A nézetelemeken belül a kapcsolatok erősek, a nézetek között lazábbak. A lazulás hibás modellezéshez vezethet, ezt meg kell előzni. A modellezés öt nézőpontját és a nézetek kapcsolatát a 2.1 ábrán mutatjuk be.

Input anyagok

Berendezések Dolgozók 1. Anyagfeldolgozó réteg

Termék

Művelettervek 2. Feldolgozó funkciók rétege Szervezeti modellek 3. Szervezeti/menedzsment réteg Információs folyamatok Input információ

4. Információs funkciók rétege

Output információ

Berendezések Dolgozók 5. Irányítási réteg Kapcsolat a rétegek között

2.1. ábra A vállalat ötrétegű modellje 1. Anyagfeldolgozó réteg Gyártógépeket és gyártóberendezéseket, operátorokat és ezek elhelyezkedését írja le. 2. Feldolgozó funkciók rétege A termelő berendezésekkel elvégezhető anyagátalakítási folyamatokat írja le, ún. művelettervekkel. 3. Szervezeti/menedzsment réteg Az emberek egységbe rendeződését, a szervezeti kapcsolatokat, egymáshoz való viszonyukat írja le. 4. Információs funkciók rétege A rendszer minden számítógépes és nem számítógépes információs funkcióit és folyamatait írja le. 5. Irányítási réteg 13 / 136

Vállalati Információs Rendszerek BSc Az információt áramoltató és rendszervezérlő hardware-eket (berendezéseket, számítógépeket), operátorokat és ezek elhelyezkedését írja le. Az 1. és 5. réteg a vállalat fizikai modellje, ami leírja a rendszer látható tulajdonságait (gépeket, berendezéseket, számítógépeket, rendszereket, dolgozókat – operátorokat). A 2. és 4. réteg azt írja le, amit a rendszer csinál, megmutatja a termelőberendezésekkel elvégezhető anyagátalakító folyamatokat és a rendszer információs folyamatait. Reprezentálja a tudást, ami a rendszer működtetéséhez kell, amit a rendszer tud. A szervezeti/menedzsment réteg Az emberek egységbe rendeződését, a szervezeti kapcsolatokat, egymáshoz való viszonyukat írja le. A leírás eredménye a szervezeti keret, amely emberek rendszeres, szabályos együttműködését, a közös cél elérésére irányuló erőfeszítését is szabályozza. A szervezet szervezeti egységekre tagozódhat. A tagozódás történhet függőségi elv szerint vagy tevékenységi elv szerint. Tevékenységi elv szerint A tevékenységi elv alapján az egységeket a vállalaton belül alkalmazott munkamegosztás szerint alakítják ki, és horizontális tagozódásnak, az ilyen szervezetet pedig horizontális szervezetnek is nevezik. A munkamegosztás szerinti struktúra alapvetően a funkcionális, tárgyi vagy regionális elv szerint alakítható ki: - A funkcionális elv szerint homogén szakmai tevékenységeket - mint például a beszerzés, értékesítés, termelés - különítünk el egymástól. - A tárgyi elv a termékek (termékcsoportok), anyagok vagy vevők (vevőcsoportok) szerinti tagolást jelent. - A regionális elv a feladatok földrajzi illetve értékesítési területek szerinti elkülönítése. Attól függően, hogy a felsorolt munkamegosztási elvekből mennyit alkalmaznak egy struktúra kialakításánál, beszélhetünk egy-, két- illetve többdimenziós szervezetekről. A többdimenziós szervezetek egyik speciális esete a mátrixszervezet (kétdimenziós eset), melynek lehetséges esetei: a funkció-tárgy (termék, vevő), funkció-régió, funkció-funkció és a tárgy (termék, vevő)-régió elvek együttes alkalmazása. Függőségi elv szerint A szervezeti egységek függőségi elv szerinti rendeződését a döntési és utasítás kiadási/fogadási hatáskör alapján határozzák meg, ezért vertikális tagozódásnak, a szervezetet pedig vertikális szervezetnek is nevezik. A vertikális tagozódásban a legkisebb elem a munkakör, amelyet egy vagy több dolgozó tölthet be. Több munkakör csoporttá (műhellyé), több csoport (műhely) osztállyá (üzemmé), több osztály főosztállyá (gyáregységgé) szervezhető. A döntés és utasítás szerinti struktúrák a következők lehetnek: - Egyvonalas vagy lineáris szervezetről beszélünk, ha az alárendelt egységek (személyek) csak egy felsőbb egységtől (személytől) kapnak utasítást. - Többvonalas egy szervezet akkor, ha az alárendelt egységek (személyek) több felsőbb egységtől (személytől) kaphatnak utasítást.

14 / 136


2.1. TERVEZÉS ÖTRÉTEGŰ MEGKÖZELÍTÉSBEN A tervezés módszere és lépései: A 2.2.ábrán szemléltetett módon fokozatos átalakítással, fejlesztéssel közelítünk a végleges rendszerállapot felé. Átalakítás/fejlesztés

Kiértékelés

Tanulság

Visszacsatolás/Tanulás Vállalati célok

AS-IS rendszer

CIM felfogások

TO-BE rendszer

Átmeneti állapotok

Referenciák

Környezet megismerés

2.2. ábra Vállalati rendszerek tervezésének követelményei és eredményei Vállalati célok megismerése (pl.: költségek csökkentése, készletszint csökkentése, forgási sebesség növelése) (input) EZ VAN (AS-IS) rendszer megismerése, amennyire csak lehet (input) A környezet és a versenytársak megismerése, hatások figyelembe vétele (input) Referencia rendszerek, példák megismerése, CIM alapelvek adaptálása (input) Tervezés: a célrendszer tulajdonságainak meghatározása → TO-BE Lehetséges átmeneti állapotok sorának és a tanulás módszerének megtervezése Átmeneti állapotok irányítása a „kísérlet-kiértékelés-tanulás” ciklikus végrehajtásával Tervező csoport Csak a vállalat vezetőségének van alárendelve Képesnek kell lennie minden réteg kezelésére/tervezésére, az információk begyűjtésére és döntéshozásra

15 / 136


2.2. TERVEZÉSI STRATÉGIÁK Három stratégiát tárgyalunk részletesebben, és az informatikai funkciókat valamint az irányítási réteget részletezzük.

2.2.1. Teljeskörű konkurens tervezés Az eljárást a 2.3. ábra szemlélteti.

(átalakítás) (átalakítás)

1. réteg 2. réteg Input

Pénzügyi kiértékelés

3. réteg 4. réteg

Output optimális TO-BE rendszer és átmeneti állapotok

5. réteg 2.3. ábra Az öt réteg egyidejű, párhuzamos tervezése Jellemzők Először inputok meghatározása A tervezés egyidejűleg folyik minden rétegre és a köztük lévő kölcsönhatásokra nézve Azonnal vizsgálják a rétegek közötti kölcsönhatást is. Előnyök ☺ Egyidejűleg folyik minden réteg tervezése, ezért gyors ☺ Minden összhangba hozható ☺ Hatékony tervezési stratégia Ha kivitelezhető és ha van módszer a csoportok tökéletes összhangjának biztosítására Hátrányok Nehéz az összhang, a kommunikáció, az alkotókedv fenntartása A csoportok tagjainak a rájuk tartozó minden információt fel kell dolgozniuk, ami máshol felmerült Gyakran megbukik

16 / 136


2.2.2. A feldolgozó funkciók és az informatikai funkciók konkurens tervezése Az eljárást a 2.4. ábra szemlélteti.

(átalakítás) (átalakítás)

1. réteg 2. réteg


Input 4. réteg


3. réteg 5. réteg 2.4. ábra A funkcionális rétegek egyidejű, párhuzamos tervezése a fizikai rétegek kényszere alatt Jellemzők

Először inputok meghatározása A tervezést a funkcionális rétegek (2, 4) párhuzamos tervezésével végezzük A kölcsönhatásokat csak a 2. és 4. réteg között ütköztetjük, elemezzük Az 1. és 5. réteget inputként, kényszerként kezeljük, nem tervezzük (Olyan eszközöket tervezünk be a funkcionális tervek elkészítésekor, melyek a piacon kaphatók, nem végzünk eszköztervezést.) A 3. réteget csak a pénzügyi kiértékelés alatt tervezzük meg, az összes többi ismeretében Iterálás egy optimális megoldás előállításáig Az 1-2., valamint a 4-5. réteg tervezése egyidejűleg folyik, a kényszerek alapján 1. réteg a 2. réteggel tervez: a fizikai berendezések kényszere beépül a feldolgozó funkciók tervébe. 5. réteg a 4. réteggel tervez: a számítógépek kényszere beépül az informatikai funkciók tervébe. 2. és 4. réteg együttműködik: a funkcionális tervek összhangja biztosított. Minden réteg eredménye a pénzügyi kiértékeléshez kerül, és ekkor megtervezik a szervezetet. Előnyök és hátrányok ☺ Az egyidejűleg felmerülő kommunikációs kényszer csökken ☺ A tervezési feladatok egyszerűbbek, jobban körülhatároltak Iterációra van szükség a 2. és 4. réteg között, mert a kényszerek beépítése esetleg később történik csak meg, ezért több időt igényel Nem minden szempont kerül bele a végső tervbe (pl. lehet, hogy megérte volna kifejleszteni az eszközt)

17 / 136


2.2.3. A feldolgozó funkciók és az informatikai funkciók sorrendi tervezése Az eljárást a 2.5. ábra szemlélteti.

(átalakítás)

(átalakítás)

1. réteg Input

2. réteg

4. réteg


5. réteg


3. réteg 2.5. ábra A funkcionális rétegek sorrendi tervezése a fizikai rétegek kényszere alatt Jellemzők Először inputok meghatározása A tervezés a feldolgozó funkciók tervezésével kezdődik, az 1. réteg kényszere alatt (esetenként azzal párhuzamosan, konkurens módon) Az eredmény alapján történik az informatikai funkciók tervezése, konkurens módon az 5. réteggel, vagy annak kényszere alatt A 2. és 4. réteg iteratív fejlesztése az optimális műszaki megoldás kidolgozásáig Pénzügyi kiértékelés a 3. réteg fejlesztésével Iteráció az optimális megoldás megtalálásáig Előnyök és hátrányok ☺ A kommunikációs kényszer tovább csökken, mert az 1-2. és a 4-5. réteg közötti összhang kidolgozásán van a hangsúly Több iterációra van szükség a 2. és 4. réteg között, ezért még több időt igényel Nem minden szempont kerül bele a végső tervbe Működőképes stratégia! A feldolgozó funkciók és a termékáramlás biztosításán van a hangsúly.

2.2.4. Más stratégiák A 4-5. réteg tervezése után van, vagy nincs 1-2. réteg tervezése (nincs pl. az IT tanácsadó cégeknél) 3. réteg → 1-2. réteg → 4-5. réteg, stb.

18 / 136


2.3. AZ INFORMÁCIÓS FUNKCIÓK ÉS AZ IRÁNYÍTÁSI RÉTEG TERVEZÉSE Meg kell tervezni a rendszert, azaz a vállalatot és benne a műszaki tervezés, gazdasági tervezés, gyártás, a definiált feldolgozó funkciók, az üzleti folyamatok, valamint a minőségirányítás informatikai modelljét, és a modell működését támogató berendezéseket, valamint a modell előírt működését kikényszerítő irányító hálózatot.

2.3.1. Az információs funkciók rétege, rendszere A követelmények részletes specifikációja a vállalati modell felállításával oldható meg. (Ennek egyik eszköze az ún. ARIS rendszer.) A tervezés folyhat Top-Down és Bottom-Up megközelítésben (pl. eseményvezérelt folyamatláncok elkészítésével indulunk, és haladunk a részletektől az absztraktabb szintek felé). Szükség esetén iterációval a gyártási és az informatikai funkciókat összhangba kell hozni. A célrendszert megvalósító modellt meg kell tervezni (az átmeneti rendszerekkel együtt) és meg kell valósítani, vagy a meglévő piaci kínálatból ki kell választani a komponenseket és ezeket össze kell hangolni. Ha a cél a számítógépek alkalmazása, a nagyfokú automatizálás, akkor a számítógéppel integrált gyártás (CIM) alapelveit célszerű használni. Üzleti adatfeldolgozó rendszerek és tranzakció-orientált integrált vállalatirányítási rendszerek tervezését ugyanígy kell elvégezni.

19 / 136


2.3.2. Irányítási réteg Irányítási réteg számítógépes és nem számítógépes rendszeren keresztüli információáramoltatását a 2.6. ábrán szemléltetjük. Feladata információ áramoltatása, annak biztosítása, hogy az operátorok és a berendezések végrehajtsák a kapott feladatokat, beleértve a menedzsment funkciók kielégítését. Számítógépes hálózat: számítógépes információ áramoltatására

Működése

Operátori információ áramlás: szóban, papíron Szg

Szg

Érzékelés

Beavatkozás

Operátor Irányítás Feldolgozó vagy anyagkezelő berendezés Működtetés

Szg

2.6. ábra Irányítás számítógépes és nem számítógépes rendszeren keresztül Az irányítás és a működtetés megkülönböztetése az absztrakció szintjétől függ. Pl. irányítás : operátor letölti a szerverről a fúrófájlt, operátor indítja a fúrást működtetés : a teljes fúrást a számítógép vezérli Az irányítás és a működtetés két részből áll: 1. Érzékelés: számítógép vagy operátor érzékeli a berendezés jelzéseit 2. Beavatkozás: számítógép vagy operátor beavatkozik a berendezés működésébe (mozgat, hőmérsékletet emel stb.) Hatásláncok: 1. Irányítási réteg – Operátor – Berendezés – Anyag(változás) /manuális/ 2. Irányítási réteg – Számítógép – Berendezés – Anyag(változás) /automata/ 3. Irányítási réteg – Operátor – Számítógép – Berendezés – Anyag(változás) /félautomata/ 4. Irányítási réteg – Számítógép – Operátor – Berendezés – Anyag(változás) /manuális/ 20 / 136


2.3.3. Megvalósítás hierarchikus rendszerben Az ICAM definició (1981. US Air Force: Integrated Computer-Aided Manufacturing) szerint 5 réteg van. A rétegeket valamint ezek legfontosabb jellemzőit a.2.1. és 2.2. táblázatban foglaltuk össze. 2.1. táblázat Számítógépes hálózati rendszerek szintjei Réteg Szint Funkció # Pénzügyi tervezés, felszerelés/gyár tervezés, terméktervezés, Vállalat 4. réteg vállalatirányítás 3. réteg Üzem (alrendszer) Termelésirányítás, ütemezés, karbantartás, minőségirányítás Cellák (terület) Gépcsoport vezérlése, menedzselése, megfigyelése, felügyelete 2. réteg 1. réteg Gépek (eszközök) NC, robot, PLC, AGV vezérlők, folyamatirányítás Érzékelők és Termékmegmunkálás, termelésgépesítés, folyamatirányítás 0. réteg beavatkozók

2.2. táblázat A megoldások főbb jellemzői az egyes hálózati szinteken: Legfontosabb Hálózati Közegelérési Felsőbb rétegek Topológia jellemző szint protokoll protokolljai tulajdonság * (Bármi), de MHS, FTAM, az egyes adatbázisok, Részleges átbocsátó rétegek nem alkalmazások Vállalat összeköttetés képesség zavarhatják (JDBC, CORBA, egymást! UDBC) Sín, gyűrű, Ethernet, FTAM, MMS, átbocsátó csillag, fa, tokenes Üzem adatbázis képesség hurok, részleges (busz, ring) Ethernet, FTAM, MMS, Sín, gyűrű tokenes válaszidő Cella adatbázis (ring) Gép

Sín

Érzékelők

Sín

Tokenes

MMS

Lekérdezés, MMS részhalmaza tokenes

Kidolgozottság

magas

magas közepes/mag as

válaszidő

közepes

válaszidő

alacsony/köz epes

Néhány rövidítés: 1. MAP: Manufacturing Automation Protocol – gyártásautomatizálási protokol 2. MMS: Manufacturing Message Standard – gyártás automatizálási protokoll 3. MHS: Message Handling System – üzenetküldési rendszer 4. AGV: Automated Guided Vehicle – automata irányítású jármű 5. FTAM: File Transfer Access Management – fájl küldés/fogadás

Így alakult ki a ma is használatos rendszerszemlélet, aminek az elvi struktúráját a 2.7 ábrán szemléltetjük.

21 / 136


2.7. ábra Gyári, irodai hálózat

22 / 136


3. STANDARD INTEGRÁLT VÁLLALATIRÁNYÍTÁSI RENDSZEREK ALAPJAI Kész szoftverek, melyek valamilyen vállalatmodellt feltételezve íródtak és e vállalatmodell alapján működnek. Vállalatmodell Annak leírása, hogy hogyan mozog az anyag, az érték (pénz) és az információ a vállalat működése alatt. A választott vállalatmodell meghatározza a rendszert optimálisan alkalmazni tudó vállalatokat, azaz a fejlesztéskor és értékesítéskor megcélzott piaci szegmenst. Standard szoftvert: a felhasználó alapjaiban nem módosíthatja, de „testreszabhatja”, sőt testre is KELL szabnia - paraméterezéssel és - törzsadatokkal (statikus adatok). A testreszabás annak meghatározása, hogy milyen adatokat, adatszerkezeteket tároljon a rendszer, és hogy milyen üzleti folyamatok és azok hogyan használják fel azokat. Integrált rendszer: a vállalat összes adatfeldolgozását megvalósító, egységes információs rendszer. - Biztosítja: = a vállalat összes tranzakció-feldolgozását, = a vezetői információkat és információs funkciókat minden vezetői szinten, = a vezetői döntéstámogatást (pl. pénzügyi problémák modellezésén és szimulációján keresztül a döntési változatok előzetes elemzését). - Egységes vállalati adatmodellre épülő, egységes vállalati adatbázist használnak. - Az alrendszerek szorosan együttműködnek. - A funkciók a rendszerben nem keverednek, és nem duplikálódnak. - Nincs többszörös adatbevitel. Modulok: Az integrált rendszerek egy-egy jól körülhatárolt része, melyek támogatják a vállalat horizontális és vertikális munkamegosztásából eredő feladatok végrehajtását. Horizontálisan: az egymást követő tranzakciófeldolgozási feladatokat (értékesítés – beszerzés – termelésirányítás – készletgazdálkodás – pénzügy – számvitel – tárgyieszköz – stb.) Vertikálisan: az egymásra épülő vezetői szintek információellátási és döntés-támogatási feladatait (SAP szerint: modulok ← komponensek ← funkciók) Alkalmazáslogika: A modulokba összefogott függvénykészlet, azaz a teljes rendszer adatbázis nélkül.

23 / 136

Vállalati Információs Rendszerek BSc Rendszertechnikai modell, réteges szerkezet, amit a 3.1. ábrán szemléltetünk. Adatbázis az adatbázis-kezelővel együtt Adatbázis-interfész (köztes szoftver) – esetenként el is maradhat Alkalmazás-futtató rendszer (interpreter) – elmaradhat, de a gyors alkalmazásfejlesztést hatékonyan támogatja. Alkalmazáslogika – üzleti funkciók Kezelői felület – megjelenítés és adatbevitel Ezekből néhányat el is hagyhatunk a feltételezett vállalatmodell igényei alapján. Adatbázis

Adatbázis-interfész

Alkalmazás-futtató rendszer Alkalmazáslogika

Megjelenítés 3.1. ábra Az integrált vállalatirányítási rendszerek réteges szerkezete

24 / 136


3.1. TERHELÉSMEGOSZTÁSI ARCHITEKTÚRÁK A felosztás lehetőségeit a 3.2. ábrán mutatjuk be. Lényege: hol húzzuk meg a határvonalat a három alapkomponens (réteg) között, úgy hogy a két rész telepíthető legyen két önálló gépre. X-windows

Oracle Financial

D&B

Sybase + Powerbuilder

PC Xbase

Adatbázis

Adatbázis

Adatbázis

Adatbázis

Adatbázis

Funkció

Funkció

Funkció

Funkció

Funkció

Megjelenítés

Megjelenítés

Megjelenítés

Megjelenítés

Megjelenítés

3.2. ábra A kétrétegű architektúrák határvonalai

1. A mainframe és az X-windows stílus Adatbázis

A kliensek buta terminálok, minden feladatot a központ számítógépen futó programrendszer végez el. Mainframe + terminálok (számítások a központi gépen)

Funkció ☺ Robosztus = megbízható ☺ Standard adatbázist használhat Megjelenítés Az adatbázis és -kezelő nem cserélhető Teljesítményproblémák jelentkezhetnek a háttérben

Továbbfejlesztett változat: A kliensek X terminálok, amiket egy központi gép az X-szerver vezérel. A fentiekkel majdnem azonos megoldás, csak a kezelői felület grafikus. Kis javítás (terhelésmegosztás): külön X-Window szerver. ☺ A fenti kettő, plusz ☺ Szabványos eszközök (Motif, Openlook) A fenti kettő, plusz Marad a mainframe-es megoldás GUI-s bővítéssel

25 / 136


2. Leválasztott megjelenítési réteg (Oracle stílus) Alkalmazás logika + adatbázis együtt Adatbázis ☺ Csökkenő terhelés a háttérben ☺ Különböző kliens gépek használhatók Funkció

Megjelenítés

Az adatbázis nem változtatható Teljesítmény problémák keletkezhetnek a háttérben Mainframe-es megoldás hátrányait viseli

3. Megosztott alkalmazási réteg (Dun & Bradstreet) Adatbázis

Az adatbázis teljes egészében, az alkalmazási réteg részben a háttérben fut; az alkalmazási réteg másik része a kliensen fut. (Szerver oldali programozás)

Funkció

☺ A kliens sok terhet átvehet a szervertől ☺ Szabad a választás (a rendszer megírásakor): mi fusson a háttérben, mi a kliensen (skálázhatóság)

Megjelenítés

Teljesítményprobléma keletkezhet a kliens gépen Adatbázis nem választható vagy változtatható A két rész csak egymással tud együttműködni

4. Leválasztott adatbázis réteg Adatbázis

Az alkalmazási és megjelenítési réteg összeépül, egy gépen fut. Az adatbázis réteg a háttérben helyezkedik el.

Funkció

☺ Szabványos felületű adatbázisok alkalmazhatók, választhatók (pl. Sybase → Powerbuilder, MS Access → MS SQL Server)

Megjelenítés

Erős kliens kell Integrációs problémák keletkezhetnek Migrációs problémák keletkezhetnek Biztonságot az alkalmazásban kell garantálni

5. Megosztott adatbázis funkciók Adatbázis

Funkció

Megjelenítés

Az adatbázis marad a háttérben, a kezelését a kliensen futó program veszi át. A kliensen fut az alkalmazás és a megjelenítés is. Pl. Xbase: dBase, Clipper, FoxPro illetve ezek Windowsos változatai: Visual FoxPro, Visual dBase stb. Adatbázis: .dbf; Text: .dbt; Index: .ntx; ☺ Elterjedt, sokan és sokat tudnak róla ☺ Mindent meg lehet oldani PC-n A kliensen nagy teljesítmény és memória problémák keletkezhetnek Nem ipari szabvány az adatbázis Integrációs problémák keletkezhetnek Biztonsági problémák keletkezhetnek 26 / 136


6. Háromrétegű modell (SAP R/3) Adatbázis

Funkció

Megjelenítés

Egymástól függetlenül, más-más gépeken futtatható a három fő komponens; ezek szabványos felületen kommunikálnak. ☺ Létező szabályokon nyugszik (pl. SQL, DCE – Distributed Computing Environment) ☺ Nagyon jól méretezhető ☺ Kiemelkedően hibatűrő ☺ Biztonságos ☺ Jól integrálható ☺ Könnyű a migráció ☺ Nagy eszközkészlete van

Bonyolult a rendszer Nagy kiterjedésű hálózatban bonyolult a telepítése (csak ha a szerverek vannak messze egymástól)

7. Biztonsági kérdések A réteges felépítésnek megfelelően 5 szinten kell vizsgálni és garantálni az adatok és programok biztonságát: Felhasználó megjelenítési szintjén Alkalmazói program szintjén Adatbázis szinten Operációs rendszerek szintjén Hálózati szinten

27 / 136


3.2. STANDARD RENDSZEREK PROGRAMOZÁSI ALAPELVEI A bizonylatok üzleti objektumok, melyeken metódusok dolgoznak. A rendszerek többsége csak objektum szemléletű, mert a középpontban egy-egy üzleti bizonylat (üzleti objektum) áll, és nem objektum orientált, mert legtöbbször hiányzik pl. az informatikai értelemben vett öröklődés.

3.2.1. Bizonylatok és élettörténetük Bizonylat A gazdasági műveleteket ill. megtörténtüket hitelt érdemlően igazoló okmány. Általános elv: a gazdasági eseményekről bizonylatot kell kiállítani, könyvelni csak bizonylat alapján szabad. Minden bizonylatot könyvelni kell; ez a „bizonylati elv”. (ez a 3 kitétel) Tartalmi kellékei: Bizonylat megnevezése (pl. „Szállítólevél”), vagy a gazdasági esemény leírása A kiállító és a partner pontos megnevezése Kiállítás kelte, a gazdasági esemény, vagy teljesítés kelte (számlán ezeken kívül a fizetési határidő is esetleg) A gazdasági esemény tárgyának megjelölése, mennyisége, értéke (pozíciók) A gazdasági műveletben résztvevők aláírása Alaki kellékei: (Előzetes) szigorú sorszámozás, szigorú számadású bizonylat Tartósság: a kiállítás megváltoztathatatlansága Javítás nélküli kiállítás - ha mégis javítani kell, akkor is olvashatónak kell maradnia az eredeti feljegyzésnek Követő bizonylatban hivatkozás az előzményre Ha számítógéppel készül (számítógépes bizonylat): program azonosítója (adattár azonosítója), kódjegyzék közlése (használt kódok feloldása, hogy átlagemberek is megérthessék) Bizonylati rendszer, bizonylattár A bizonylatok kiállításának, alkalmazásának, kezelésének, ellenőrzésének, továbbításának rendjére vonatkozó előírás. Az, hogy mit használ a cég, azt eldöntheti, valamint azt is, hogy melyiket, mikor, hogyan kell kitölteni (számlán, szállítólevélen kívül). Érdemes paraméterezhetővé tenni a formátumát. A gazdasági eseményeket bizonylatok kísérik végig. A tipikus bizonylatokat a 3.1. táblázatban mutatjuk be. Ezek teszik lehetővé az események nyomon követhetőségét, a partnerek kommunikációját, és „irányítják” a könyvelést. Bizonylatokat használunk a partnerekkel (vevők, szállítók, bankok) kapcsolatos események dokumentálására, de a belső egységek (raktárak) közötti készlet és értékmozgások nyomon követéséhez is. A gazdasági eseményekhez kapcsolódó bizonylatoknak meghatározott sorrendjük van. Nem kötelező minden bizonylat használata.

Állapot, élettörténet A bizonylatok életének három szakasza, állapota van: - Aktív egy bizonylat, ha készítés/szerkesztés alatt áll, végleges tartalmát (formáját) még nem nyerte el. - Lezárt (kész), ha már végleges a tartalma, a megfelelő adatokkal feltöltötték, amelyek már nem módosíthatók. Az aktív → kész átmenetet rendszerint jóváhagyásnak nevezik, és a jóváhagyás mint bekövetkezett esemény új folyamatokat indít el.

28 / 136

Vállalati Információs Rendszerek BSc - Archív, ha „feladatát” elvégezte, a további folyamatoknak nincs szükségük sem rá, sem a közvetlenül belőle vett adatokra. A kész → archív átmenet rendszerint összetett folyamatok és ellenőrzések/beállítások végén/eredményeként megy végbe. Élettörténethez kapcsolódó legfontosabb adattípusok: - dátum, vagy - dátum és pontos időpont: létrehozás, jóváhagyás/lezárás, archiválás, - az eseményt kiváltó kezelő, - követő és/vagy megelőző bizonylat(ok), - az archiválás okának részletezése.

3.1. táblázat Tipikus bizonylatok, szerepük, archiválás Dokumentum Hatása /bizonylat Ajánlatkérés Felhívás gazdasági kapcsolat kialakítására.

Archiválás feltétele

Lejárt az érvényessége vagy elkészült az ajánlat. (Az előbbi esetben az archiválás lehet automatikus.) Ajánlat Új jogi helyzetet hoz létre: „Egyoldalú” Lejárt az érvényessége vagy elkészült a kötelezettségvállalás. megrendelés. Előbbi esetben az archiválás lehet automatikus. Megrendelés Új jogi helyzetet hoz létre: Egy vagy Elkészült a követő bizonylat. kétoldalú kötelezettségvállalás. Készletet igényel. Visszaigazolás Új jogi helyzetet hoz létre: Kétoldalú Elkészült a követő bizonylat. kötelezettségvállalás, vagy ennek megerősítése. Készletet igényel. Diszpozíció Készletet foglal (ritkábban mozgat is). Elkészült a szállítólevél vagy a számla. Szállítólevél Készletet foglal, majd mozgat Elkészült a számla (minden tételről). (kikönyvel a raktárból). Számla Értéket mozgat (és készletet is, ha nem Kifizették (teljesen). volt szállítólevele). Belső Belső egységek között új jogi helyzetet Elkészült a követő bizonylat. megrendelés hoz létre: Kétoldalú kötelezettségvállalás. Belső Készletet foglal (ritkában mozgat is). Elkészült a követő bizonylat. diszpozíció Belső Készletet mozgat. Elkönyvelték (ritkán belső számla szállítólevél (Pl. raktárak közötti szállítólevél.) archíválja). Belső számla Értéket mozgat (és készletet is, ha nem Elkönyvelték. volt szállítólevele). Leltár Készlet-nyilvántartási adatot módosít Elkönyvelték. bizonylatok mennyiségben és értékben is. (Leltártöbblet biz., leltárhiány biz.) Selejtezés Készlet-nyilvántartási adatot módosít Elkönyvelték. mennyiségben és értékben is.

29 / 136


3.2.2. Metódusok Az öröklődés A bizonylatokat az üzleti folyamatban elfoglalt relatív helyük alapján megelőző bizonylatnak és követő bizonylatnak nevezzük. A megelőző bizonylaton lévő adatokat a követő bizonylat (lásd létrehozás) részben vagy egészben örökli, átmásolja saját adatterületére. A másolás folyamatát cégenként eltérő működés szerint, szabályozni kell (testreszabáskor paraméterezéssel): - mit másoljon át, - az átmásolt értékek közül (kinek) mit lehessen módosítani, - a módosítás lefelé vagy fölfelé, vagy mindkét irányban történhessen, - a követő bizonylat milyen esetben archiválhassa a megelőző bizonylatot: kizárólag tételeinek teljes feldolgozása esetén (pl. szállítólevél és számla kapcsolat esetén a kiszállított tételeket mind le kell számlázni), vagy részleges feldolgozása (öröklése) esetén is (pl. diszpozíció és szállítólevél kapcsolatában). Létrehozás Legtöbb üzleti folyamatban testreszabáskor definiálhatók a használt bizonylatok, és ezek – esetenként „foghíjas” – sorrendje. Az előírt megelőző bizonylat meglétét a rendszer megköveteli, és így gondoskodik az előírt üzleti folyamat betartásáról. Létrehozáskor új rekord keletkezik. Megkönnyíti a munkát és növeli az adatok megbízhatóságát a másolás előzményről, a tételek importálása fájlból vagy esetleg más rendszerből. Tartalmi módosítás Aktív bizonylat: Sok, de rendszerint nem minden adata módosítható. Lezárt (kész) bizonylat: tartalma már nem módosítható. (De állapota igen, archívra.) Archív bizonylat: tartalma már nem módosítható,de állapota kivételes esetekben (stornózáskor) igen, kész állapotra. Jóváhagyás Az aktív → kész állapotváltoztatás. Rendszerint jogi következményekkel jár, és az esemény új folyamatokat indít el, ezért használatát jogosultsághoz kötik. Archiválás Az aktív → archív állapotváltoztatás: következmények nélküli „megsemmisítés”, legfeljebb egy bizonylatsorszámot használunk el feleslegesen. A kész → archív állapotváltoztatás: bizonylattól függően a funkció végrehajtható - kézzel (pl. ajánlat érdektelensége esetén), - követő bizonylat elkészültekor, vagy - stornózáskor (ami egy speciális követő bizonylatként is felfogható). Nyomtatás Bizonylat/dokumentum keletkezik, amely kikerül a rendszer hatóköréből és partnerhez küldhetik. Ezért fontos a kinyomtatás tényének feltüntetése, valamint a nyomtatás formátuma, külleme. Nyomtatási formátum: Minden bizonylathoz/dokumentumtípushoz – például ajánlathoz, megrendeléshez, szállítólevélhez, rakodási jegyhez, számlához – többféle formátumot, azaz külalakot és adattartalmat lehet meghatározni. A külalakot sablonokkal, az adattartalmat pedig aktív elemekkel, feldolgozó/módosító programokkal állítják elő, például az előlegek elszámolása, vagy az áfa-kulcsok szerinti bontást/összegzést.

30 / 136

Vállalati Információs Rendszerek BSc Könyvelés Egy bizonylat könyvelése értékmozgatást és/vagy készletmozgatást jelent. Rendszertől és konfigurációtól függően automatikusan végbemegy, vagy kézzel kell indítani. Nem a bizonylaton dolgozik, hanem annak adatait használja fel. Stornó, stornírozás (stornózás) Az eredeti állapot visszaállítására szolgáló eljárás. További követelménye a nyomon követhetőség biztosítása. Ezért nem jelenthet fizikai megsemmisítést, viszont az eredeti bizonylat összes hatását vissza kell „csinálni”. Pl. Szállítótól kapott szállítólevél stornózása (ha még nincs a szállítólevélhez kötve a számla): 1. Áru visszavétele a raktárból => készlet adminisztráció / készlet könyvelés 2. Az archivált megrendelés állapotának visszaállítása => kész állapotra. 3. Eredeti (szállítói) szállítólevél archiválása. 4. Az eredetit nem töröljük, hanem új bizonylatot készítünk.

A metódusok hatása többféle is lehet az alábbiak szerint: Jogi állapot létrehozása Mindig (kezelői) jóváhagyáskor jön létre. Kinyomtatáskor a bizonylat kikerül a rendszer hatóköréből, ezért a szigorú számadású bizonylatokat megkülönböztetve kell nyomtatni jóváhagyás előtt és után. Készletmozgatás Alapvetően a mennyiségi nyilvántartást módosítja: raktárba bevételez, vagy raktárból kiad. Mindig raktár-raktár vagy raktár-partner áll egymással szemben, de partnerre nem vezet készletet (legtöbbször). Értékmozgatás Valamely gazdasági esemény pénzben kifejezett összes értékének mozgatása. Nem jár együtt szükségszerűen valós pénzmozgással. (Pl. számla elkönyvelésekor nem, de bankkivonat könyvelésekor igen – bár ezek nem egyidejű események.) A készlet is érték, ezért ha partnerek között szállítólevél mozgat készletet, akkor azt előbb-utóbb le kell számlázni. Belső értékmozgatásokat nem feltétlenül (belső) számlákkal kell végrehajtani, hanem lehet más, de számlákhoz hasonlóan kezelt, jól megkülönböztetett bizonylatokkal is (pl. selejtezés, leltártöbblet, leltárhiány). A számviteli értékmozgatás MINDIG főkönyvi számlákon történik. Megkülönböztetjük a raktárnyilvántartás szerinti készletértéket, amely menedzsment információ és nem számviteli adat.

3.2.3. Interaktív technikák Form kezelés Új bizonylat létrehozása kézzel vagy másolással (egy vagy több előbizonylat alapján) stb. Export/import Bizonylat adattartalmának feltöltése vagy kivitele más rendszerrel összekapcsolva.

31 / 136

Vállalati Információs Rendszerek BSc Eseményvezérelt programozás megszorításokkal és triggerekkel A hagyományos, vagy más néven procedurális nyelvekben az alkalmazás határozza meg, hogy mely programrészletek és milyen sorrendben fussanak. A végrehajtás az első sorral kezdődik és az állapotváltozóknak megfelelő úton halad, szükség esetén alprogramok meghívásával. Egy eseményvezérelt alkalmazásban azonban a végrehajtás nem követ kijelölt utat, a különböző eljárások események hatására indulnak el. Az események sorrendje határozza meg, hogy a programrészletek milyen sorrendben fussanak, ezáltal a végrehajtási útvonal minden egyes futásnál különböző lehet. Az eseményeket kiválthatja felhasználói beavatkozás, rendszerüzenet vagy más alkalmazás üzenete. A leggyakrabban használt eseménycsoportok, amelyek egy-egy eleméhez triggert és így külön feldolgozó programot kapcsolnak, a következők: - a beviteli képernyőhöz (pl. belépés, elhagyás), - a beviteli képernyő mezőjéhez (pl. belépés, elhagyás), - funkcióbillentyűk lenyomásához, - grafikus képernyő gombjaihoz, és - táblázatsorokhoz rendelt eseményekhez pl. beszúrás, törlés, módosítás), - rendszerüzenet. Megszorításokat használunk -

egy mezőbe bevihető adat egyediségének biztosítására, vagy

-

a bevihető adat értéktartományának garantálására.

Sorszámgenerálás A dokumentumok sorszámozása központi kérdés a szigorú elszámolású bizonylatok esetén. A sorszám igényelt formátuma pedig igen változatos lehet. A sorszámok szegmensekből állhatnak, és legalább egy növekvő-egész-szám típusú szegmenst kell tartalmazniuk. A leggyakoribb szegmenstípusok a következők: 1. Rögzített szöveg: Tetszőleges karaktersorozat. 2. Növekvő-egész-szám: Beállítandó a minimális és a maximális számérték, valamint a túlcsorduláskor felveendő érték. Egy új sorszám kiadásakor a rendszer az aktuális értéket eggyel megnöveli, így az aktuális érték megmutatja az addig elkészített bizonylatok számát is (ha az nulláról indult). Kezelése legtöbbször szemafor-technikával történik. 3. Dátum: Az aktuális dátumot és időt tartalmazza, megadható formátumban.

3.2.4. Metódusok összefogása mozgásnemekbe és tranzakciókba Mozgásnem Minden olyan eseményt el kell különíteni, amely különböző nyilvántartási vagy elszámolási következménnyel jár. Az elkülönített eseményeket elkülönített függvényekkel, ún. mozgásnemekkel kezeljük. Például, a készletgazdálkodás során sokféle dolog történhet a cikkekkel, ezért a készletmozgatásokhoz sokféle mozgásnemre van szükség, a pénzügyben pedig sokféle pénzügyi eseményt kell megkülönböztetni, ezért ott is sok mozgásnemet kell létrehozni. Az egymáshoz kapcsolódó mozgásnemek egy-egy elkülönített/megkülönböztetett konkrét üzleti folyamatot hoznak létre. Egy mozgásnem logikailag pénzt, készletet vagy informatikai objektumot mozgat. A mozgatás során garantáltan fenntartja az adatok üzleti szintű konzisztenciáját. Megjegyzés: Pénz logikailag még kézzel is mozgatható kézi könyveléssel. Ekkor az adatok üzleti konzisztenciájának biztosítása a kezelő felelőssége.

32 / 136

Vállalati Információs Rendszerek BSc Tranzakció: paraméteresen meghatározza egy elemi üzleti funkció során végrehajtandó tevékenységeket. A paraméterek egy-egy mozgásnem definiálásakor kapnak konkrét értéket, amelyeket elfogadás előtt szintaktikailag és szemantikailag ellenőrizni kell az alapvető üzleti szabályok betartása érdekében. Például értékesítéskor a kiadó és a fogadó raktár nem lehet ugyanaz. A mozgásnemek tehát elemi üzleti funkciók, egy tranzakció pedig a hasonló mozgásnemeket foglalja össze. A paraméteres meghatározás alatt itt azt kell érteni, hogy tulajdonképpen az egy tranzakcióhoz tartozó mozgásnemeket néhány jól megszabott érték különbözteti meg egymástól, amibe ha „mást helyettesítünk be” más mozgásnemet kapunk. Például, ha az „eszköz kivezetése” a tranzakciónk, és a mozgásnemek „eladás” illetve „selejtezés” akkor a kettő között csak az a különbség, hogy az egyik a 861-es a másik a 866-os főkönyvi számlára könyvel. Ez tehát a „paraméter”. A fentiek alapján az egy tranzakcióba tartozó mozgásnemek hasonló tevékenységet végeznek. Modul (Tranzakció típus): Az integrált rendszer egy jól körülhatárolt része, amely magas szinten megvalósít egy fő értékteremtési folyamat, tartalmazza az ezt támogató összes tranzakciót. (Hasonló jellegű üzleti funkciót megvalósító tranzakciók csoportja.) A fentieket a 3.2. táblázata általánosan, a 3.3. táblázat pedig egy jellemző előfordulással szemlélteti. Felhívjuk a figyelmet, hogy nem feltétlenül tartalmaz egy üzleti folyamat mozgásnemet minden tranzakcióból. 3.2. táblázat Egy tranzakció típus tranzakcióinak és mozgásnemeinek rendszere Modul /Tranzakció típus

Tranzakció típus 1

Tranzakció

Üzleti folyamat 1

Üzleti folyamat 2

…

Üzleti folyamat n

Tranzakció 1

Mozgásnem 1,1

-

…

Mozgásnem 1,n

Tranzakció 2

Mozgásnem 2,1

Mozgásnem 2,2

…

Mozgásnem 2,n

Tranzakció 3

-

Mozgásnem 3,2

…

Mozgásnem 3,n

Tranzakció 4

Mozgásnem 4,1

Mozgásnem 4,1

…

-

Tranzakció 5

Mozgásnem 5,1

Mozgásnem 5,2

…

-

…

…

…

…

…

Tranzakció k

Mozgásnem k,1

Mozgásnem k,2

…

Mozgásnem k,n

33 / 136


3.3. táblázat Példa a kereskedelem területén használt mozgásnemekre Modul/ Tranzakció Mozgásnem Tranzakció típus Beszerzés

Sz. Ajánlat

Szállítói ajánlat új (előzmény nélkül)

Sz. Megrendelés

Megrendelés új (előzmény nélkül) Megrendelés ajánlat alapján

Szállítói szállítólevél

Bevételezés új (előzmény nélkül) Bevételezés megrendelésre Import bevételezés új (előzmény nélkül)

Szállítói szla.

Értékesítés

V. Ajánlat

Szállítói szla új (előzmény nélkül) Szállítói szla készítése bev alapján Szállítói szla megrendelés alapján Vevői ajánlat új (előzmény nélkül)

V. Megrendelés

Vevői megrendelés Vevői megrendelés ajánlat alapján

V. Szállítólevél

Vevői szállítólevél Vevői szállítólevél megrendelés alapján

V. Szla

Számla új (előzmény nélkül) Számla szállítólevél alapján

34 / 136


3.3. INTEGRÁLT RENDSZEREK ADATMODELLJE Egy integrált rendszer tárolja a vállalat összes tevékenységével kapcsolatos adatot, támogatja az adatok folyamatos, naprakész karbantartását és a feladatoktól és felelősségi köröktől függően ezekhez mindenki számára hozzáférést biztosít. A vállalati adatmodell adatait három csoportba sorolhatjuk: - konfigurációs adatok, - törzsadatok és - tranzakciós adatok. A konfigurációs adatok vagy paraméterek mint korábban már említettük, a vállalat folyamatmodelljét határozzák meg. A folyamatmodellt a rendszer bevezetésekor, testreszabásakor készítik el, és a standard rendszerek paraméterezhető eljárásait ennek megfelelően állítják be (lásd mozgásnemek). Ezekkel az adatokkal a továbbiakban nem foglalkozunk. A törzsadatok ritkán változó adatok, leírják a vállalat céges tulajdonságait, a naptárat és a munkarendet, a telephelyeket, műhelyeket, raktárakat, dolgozókat, partnereket, cikkeket és ezek felépítését (anyagjegyzék), valamint előállítási módjukat (műveletterv), a gépeket, az árakat és engedményeket, költségadatokat, főkönyvi számlaszámokat, és egyéb főkönyvi és pénzügyi alapadatokat. A törzsadatok egy részét a rendszer indítása előtt, más részüket (pl. az új üzleti partnerek vagy termékek adatait) működés alatt folyamatosan viszik be az adatbázisba. Ezt követően főként hivatkozunk rájuk, emiatt szinte minden használat közben keresünk, szelektálunk közöttük. Ennek következtében meghatározó a rekordokat azonosító strukturált kódrendszer felépítése a vállalaton belüli a számítógépes termelésirányítási rendszer (könnyű, hatékony) használhatósága szempontjából. A visszakeresést keresőrendszer támogatja, amely rendszerint egyszerre több mezőben is keres. A keresett és a megjelenített mezőket úgy kell kiválasztani, és tartalmukat úgy kell megadni, hogy a vállalatot ismerő dolgozók a legrövidebb idő alatt meg tudják találni a keresett rekordokat. Ez a rendszer használhatóságának kiindulási feltétele, és legnagyobb részt a rendszer bevezetésekor kell elvégezni. A tranzakciós adatok egy-egy funkció (vevői rendelés felvétele, szállítólevél és számla készítése, gyártási rendelés kibocsátása stb.) végrehajtása során keletkeznek és „tűnnek el”, illetve archiválódnak. Az adatok hivatkozási rendszerének középpontban a cikkek állnak, lásd 3.3. ábrát. A cikkek közötti hivatkozás legtöbbször indirekt módon, az anyagjegyzéken keresztül történik. A legmagasabb szinten a végtermékek vannak. Amelyik cikk nem hivatkozik anyagjegyzékre, az levélen van, és vásárolt cikk. Vállalatirányítási értelemben cikként definiálunk minden olyan egyedet, amelyik szállítólevélre, számlára, gyártási megrendelésre, anyagjegyzékre vagy más bizonylatra kerülhet. Belső vállalati értelmezésben az absztrakció szintjétől függ, hogy mit nevezünk cikknek: Például a tervdokumentáció is lehet cikk, ilyenkor az azt előállító művelet a tervezés. Ebben az esetben a dokumentáció elkészítésének megtervezésére is lehet alkalmazni a termelésirányítási szoftver termeléstervezési (MRP) modulját. Az anyagjegyzék előírja egy adott tételt – a szülő tételt – felépítő anyagokat, alkatrészeket és az ezekből szükséges mennyiséget. Az anyagjegyzékben hivatkozott cikkeknek is lehet anyagjegyzéke. A rekurzívan bejárható teljes mélységű anyagjegyzéket anyagjegyzékstruktúrának nevezzük. Egyes alkalmazási területeken az anyagjegyzék helyett a receptura szót használják (pl. édesipar). A receptura is lehet strukturált. 35 / 136

Vállalati Információs Rendszerek BSc ... Alkalmazottak

Részleg / osztály

Szakértelem (bércsoport)

Homogén gépcsoport

Gyártási rendelések

Műveletterv

Cikk

Vevői megrendelések

Vevők

Műveletleírás

Raktár

Beszerzési rendelések

Szállítók

Törzsadatállomány 3.3. ábra Törzsadatok és tranzakciós adatok A művelettervek az anyagjegyzék-struktúra egy-egy adott szintjére vonatkoznak, meghatározzák, hogy a szülő cikket hogyan kell előállítani alkatrészeiből (amit az anyagjegyzék határoz meg). Az adatbázis feltöltésekor lentről (a levelektől kezdve) felfelé építkezünk.

3.3.1. Vállalati törzsadatok, cégadatok A cégadatok azonosítják a céget a külső partnerek felé, és ezek jelentik az adatstruktúrák hivatkozási rendszerének leveleit: Ezek más adatokra nem hivatkoznak, de más törzsadatok ezekre hivatkoznak. A fő vállalati törzsadatok az alábbiak: Cégadatok Olyan törzsadatok, amelyeket elsőként kell megadni. A legritkábban változó adatok, például név, cím, hazája, bankja, bankszámlaszáma, pénzneme. Formátumok, szövegelemek Megszólítások, bizonylatok szövegei (számla, fizetési felszólítás, szállítási feltételek). Bércsoportok: kód, órabér (a munkaköröket is csoportosítja). Számlálók: bizonylatok jelölésére, „beszélő azonosítására” szolgálnak. Fontos a formátuma és kezdőértéke. Pl.: kibocsátott számla azonosító száma 2012/xxxxx, ahol xxxxx a sorszám, amely 1-től indul és a bevezető nullákat is ki kell írni. Beérkező belföldi szállítólevél: BS12/xxxxx, ahol xxxxx jelentése a fentiekkel megegyezik. 36 / 136


3.3.2. Telephelyek A telephelyek földrajzilag különálló egységek, ahol valamilyen tevékenység (termelés, raktározás, kereskedelem, irányítás) folyik. Adatbázisok definiálhatók egy vagy több telephelyhez. Egy adatbázisban tehát több telephelyet is definiálhatunk és on-line kapcsolaton keresztül rögzítünk, vagy két külön adatbázisba definiálunk egy-egy telephelyet és az adatokat éjjel szinkronizáljuk. Egy vagy több telephelyhez üzemek is definiálhatók, amelyek a termelés színhelyei. Mivel a termelés az üzemekben folyik, az itt felmerülő költségek, a termeléssel kapcsolatos ún. közvetett költségek (pl. fűtés) összegyűjthetők, és utólag a termékre terhelhetők. Az üzemek ilyen szempontból tehát a költségkezelés fontos eszközei, költséghelyek. (A közvetett költségeket felmerülésükkor – kifizetésükkor - nem tudjuk konkrétan a termékekhez rendelni, hanem csak később. Ekkor valamilyen termékjellemzővel arányosan szétosztjuk az összes ott termelt termék között, részletesebben később.)

3.3.3. Raktárak Anyagok tárolására szolgálnak, a kereslet vagy a termelés ingadozásának kiegyenlítése érdekében, továbbá a termelés előrehaladásának ellenőrzése is ezeken keresztül történik. A cikk akkor van kész, ha lejelentik, és ekkor a rendszer a cikkhez rendelt raktárba bevételezi a lejelentett mennyiséget. Nem kell feltétlenül fizikailag is a raktárba tenni a cikket. Ilyenkor azt mondjuk, hogy a raktár virtuális. A virtuális raktár csak az előrehaladás ellenőrzésére való. Az ellenőrzés a készletmozgás lekérdezésével történik. Hiányraktárt hozhatunk létre az ügymenetek korrigálására. Ami elvileg van raktáron a rendszer szerint, de nem találják meg fizikailag a raktárban, azt átkönyvelik a hiányraktárba. A hiányraktár tehát azt mutatja mi tűnt el, mit kell megkeresni. Selejtraktár: Ellenőrzéséig, leselejtezési bizonylatolásáig a selejtként nyilvánított termékeket valóságosan vagy virtuálisan itt tárolják. A raktárak fontos jellemzője, hogy milyen anyagok tárolhatók bennük. A raktárak tároló területe tovább bontható raktárrész, tárolóhely, polc részletezéssel az anyagok tárolási és fellelési helyének egyértelmű és gyors azonosítása érdekében. A raktárak, tároló helyek egyben a készletgazdálkodás alapeszközei.

3.3.4. Cikkek, tételek Beszerzésre, gyártásra, gyártás közbeni raktározásra, értékesítésre tervezett anyagok, alkatrészek, félkész és kész termékek neve cikk vagy tétel. (Némelyik rendszer így, némelyik úgy nevezi.) A nem anyagi jellegű, de azokhoz hasonlóan kezelt dolgokat (például egy szolgáltatást) is cikknek vagy tételnek nevezik. Virtuális cikk, pszeudocikk, szett: Definiálhatunk úgynevezett virtuális cikket is, amely a tervezésben, értékesítésben vagy a gyártásban használatos, de a tényleges anyagkezelés (raktározás, készletvezetés) csak az anyagjegyzékében szereplő cikkekkel történik meg. A virtuális cikk több cikk összefogására is alkalmas. (Például az Auchanban „fürdőszoba szettet” árulnak, mely szappanból és samponból áll. Ezeket külön szerzik be, és külön is tartják nyilván a készletet. A fürdőszoba szettre nem végeznek készletnyilvántartást, viszont amikor kivisznek egy ilyet a raktárból, azt a szettre hivatkozva közlik a rendszerrel. Az ABAS ERP-ben nem vezették be ezt a fogalmat, de lényegét megvalósították. Itt a cikk törzsadatai között van egy jelölődoboz: kivételezésnél a „darabjegyzékén keresztül” jelölődobozt be kell jelölni.) 37 / 136

Vállalati Információs Rendszerek BSc A virtuális cikkek másik gyakori alkalmazása: a CD olvasó félkész termék, mert számítógépekbe szerelik be, de szeretnének belőle eladni is, tehát egyben késztermék is kéne, hogy legyen. Ekkor felveszünk egy pszeudocikket, amit már kész terméknek minősítünk, és melynek darabjegyzékében csak a CD olvasó szerepel. Így a CD olvasót kész termékként is tudjuk „látni”. Termék: Terméknek nevezzük azokat a cikkeket, melyek a piacon figyelemfelkeltés (pl. reklámidő) megszerzés (pl. ékszerek) felhasználás (pl. szabadalmi jog, know-how) fogyasztás (pl. sör) céljára felkínálhatók, és amik valamely szükségletet vagy igényt elégítenek ki. A tárgyiasult termék négy fő tulajdonsággal rendelkezik: Tárgyi jellemzők (rendeltetés, műszaki adatok, ár stb.). Minőségszint. Márkanév. Csomagolás.

3.3.4.1. Általános törzsadatok Beszerzésre, gyártásra, értékesítésre tervezett tétel (cikk) azonosító, műszaki, gazdasági és más meghatározó adata. Leíró, azonosító adatok: Kód Megnevezés Rajzszám Érvényességi határidő (ha továbbfejlesztik a cikk konstrukcióját) Vámtarifaszám (VTSZ) Szolgáltatási termék jegyzék (SZTJ) Árképzési besorolás (milyen rendszer szerint képezzük az árát) Adóbesorolás (ÁFA, a cikk adja az alapértelmezést, de ezt a szállító illetve a vevő adóbesorolása felülbírálhatja, ugyanis vannak olyan szállítók, melyek nem adókötelesek) Súly Térfogat Szavatosság (ha értelmezett, a raktárkezelés FIFO elv szerint kell történjen) • Szállítói azonosító (alternatív azonosító) stb. Egy tétel hivatkozik: Előállításhoz szükséges anyagok jegyzékére, az anyagjegyzékre/darabjegyzékre. (Informatikailag: tartalmaz egy idegen kulcsot az azonosítására, az anyagjegyzék pedig a beépülő tételek kulcsait tartalmazza, valamint a beépülő cikkek mennyiségi előírását. Direkt-indirekt rekurziót meg kell akadályozni.) Előállítás módját meghatározó leírásra, azaz a művelettervre. Tárolási helyére, raktárra (nem kötelező).

38 / 136


3.3.4.2. Készletezési és tervezési adatok Készletezés, raktározás Kiszerelési (adagolás, csomagolás) mértékegységek és átszámításuk. Készletvezetési kiszerelés: az a mértékegység amit a készletvezetéshez szeretnénk használni (általában legnagyobb felbontású). Raktár, raktárhely meghatározása, bevételezési-kiadási raktár (a fentiek szerint ezek is idegen kulcsok). Leltározási előírás (lásd még: ABC készletkezelés, leltározási módok). (Kitérő a leltározási módokra: vak leltár: üres papírra írjon fel mindent, amit talál. Jó, mert végigmegy az összes cikken, rossz mert nem biztos hogy tudja azonosítani a cikket. Tételes leltár cikkszám-megnevezés alapján: Kinyomtatunk egy táblázatot az azonosítókkal és megnevezésével és mellé egy oszlopba írja be hányat talált. Jó, mert tudja azonosítani, de rossz, mert ha valamiből több helyen is van, az első helyen kitölti a sort, a másik helyen pedig már nem törődik vele. Esetleg ráírhatjuk a nyilvántartás szerinti készletet, hogy feltűnjön, hogy nem találta meg még az összeset, de ekkor, ha lusta csak átmásolja a „jó megoldást” papíron az üres oszlopba.) Biztonsági készletszint (Vészhelyzet van, ha ez alá csökken. „Felejtsd el, hogy van.”) Minimális készletszint (Ennyinek lennie kell, rendelést adunk fel és maximumra töltünk, ha a készletszint ez alá csökken.) Jelzési szint (Vigyázat, alacsony a készlet, jelez, hogy rendelni kéne, ha ez alá csökken.) Maximális készletszint (Ennél nagyobb készletszint nem kívánatos.) (A készletszintekkel kapcsolatos szóhasználat nem egészen konzekvens.) Készletmennyiségi és készletváltozási adatok is tárolhatók cikkekhez rendelve. • Aktuális raktárkészlet. • Várható beérkezések (a szállító visszaigazolása alapján). • Várható kiszállítások. • Foglalások (diszpozíció, szállítólevél készítés). • Szabad készletek (a kiadáskor való számítás gyorsítása érdekében). • Utolsó raktári bevétek, kivétek dátuma. Tervezési adatok A beszerzés tervezési algoritmusát, a megrendelés feladásának időpontját és a mennyiséget befolyásoló adatok: Beszerzés (vásárlás és gyártás) tervezését meghatározó adatok - Beszerzési mód (QAD EA: P/M kód): gyártott vagy vásárolt. - Beszerzési (vásárlási, gyártási) idő: rendszerint napokban van megadva. - Beszerzés tervezésének korlátozása: Beszerzést tervezi-e a rendszer, MRP tervezhet-e? Rendelési időszak: Az ezen belül keletkezett nettó igényeket, a Rendelési politika mező tartalmától függően, összevonhatja a legkorábbi dátumra. Napokban van megadva. Időhatár: Közeli időszak kizárása, ezen belülre az MRP anyagátvételt (esedékességet) nem tervez, ha szükség lenne rá, akkor is kitolja az időhatáron túlra. (Például 10 nap előírása esetén bevételezés legkorábban csak a 11-ik napra tervez.) Készletek beszerzését meghatározó algoritmust kiválasztó mező, rendelési politika. (QAD EA: POQ, FOQ, LFL, OTO, lásd részletesebben lent.) Minimális vagy biztonsági készletszint (ezt a készletezési adatok között már definiáltuk). Beszerzendő (vásárlás és gyártás) mennyiséget befolyásoló adatok: Minimális (pl. kedvezményt kapunk rá) és maximális (pl. szállítóeszköz korlátja miatt) rendelési mennyiség. Rendelési mennyiség: Ennyit rendel, ha engedélyezett. Gyártástervezés is használja. 39 / 136


Sorozatnagyság (többszörözés): ennek csak egész számú többszörösét rendelhetjük (pl. kenyeret csak kilónként kapni, nem lehet 1,45 kilót rendelni, ekkor a rendszer kettőt rendel). Cikk jelleg, vagy kiadási mód: Szett jellegű, fantom vagy pszeudocikk, amik az anyagjegyzékükben szereplő tételeket adják ki, vagy normál cikk. A beszerzett anyag/áru nyilvántartási értékét meghatározó módszer előírása, azaz a készletértékelés módszere: beszerzési áras, diktált ár vagy folyamatos átlagár. A beszerzés-tervezési módszereket vezérlő adatokat és paramétereket gyakran összevonják. Az így létrehozott vezérlő kódok készletpolitika szempontjából csoportosítják a cikkeket. Például az QAD EA-ban: POQ (Periodic Order Quantity) – Rendelés adott időszak igénye alapján. Az MRP minden futásakor a feldolgozás alatt álló tételre vonatkozó nettó igényeket esedékességük szerint időintervallumokba csoportosítja, és az egy intervallumba eső igényeket összevonja. Minden intervallum egy-egy csúszó időablak, melynek kezdő időpontját az első (a legkorábbi) nem nulla nettó szükséglet felmerülésének időpontja határoz meg. Az intervallum hosszát a tételtörzs Rendelési időszak mezőben megadott naptári napok száma írja elő. Az így rögzített időablakba eső nettó igényeket (és csak azokat) összevonja. Akkor is összevon, ha az időablak részben vagy egészben Időhatáron belülre esik. Ez lesz az összevont szükséglet. Az összevont szükséglet esedékességi dátuma az első nettó szükséglet esedékességi dátuma lesz, ha az a naptári napokban megadott Időhatáron kívülre esik. Ha belülre esne, akkor kitolja, a feladási dátumot az időhatárt követő első napra teszi. A rendelések feladási dátumát az így meghatározott esedékességi dátumból kiindulva határozza meg, levonja a beszerzési időt, gyártott alkatrész esetén munkanapokkal számolva. Ez lesz a feladási (kibocsátási) időpont még akkor is, ha ez az Időhatáron belülre esik. Következő lépésben az MRP a nagyobb értéket választja az (1) összevont szükséglet és a (2) minimális rendelési mennyiség (Minrend) közül. A ténylegesen megrendelt mennyiség végül is a Többször mezőben levő mennyiség legkisebb egész számú többszöröse lesz, amely legalább annyi, mint az előbb kiválasztott mennyiség. Ha az így meghatározott mennyiség meghalad egy előírt szintet (Maxrend), az MRP figyelmeztető üzenetet küld, de elkészíti a tervezett rendelést. Tovább folytatja az eljárást addig, ameddig az összes nettó igény ellátását be nem tervezi. FOQ (Fixed Order Quantity) – Rögzített rendelési mennyiség. Az MRP a Rendelési mennyiség és a Minimális rendelési mennyiség közül mindig a nagyobbat választja, és ezzel annyi megrendelést készít, ahánnyal a nettó szükséglet fedezhető. A Rendelési időszak mezőt figyelmen kívül hagyja, csak az egy napra eső nettó igényeket vonja össze. Az összevont vagy önálló nettó szükségletek esedékességi dátumát a naptári napokban megadott Időhatáron kívülre tolja, azaz a dátumot az időhatárt követő első napra teszi, ha belülre esne. A rendelések feladási dátumát az így meghatározott esedékességi dátumból kiindulva határozza meg, levonja a beszerzési időt, gyártott alkatrész esetén munkanapokkal számolva. Ez lesz a feladási (kibocsátási) időpont még akkor is, ha ez az Időhatáron belülre esik. Következő lépésben az MRP a nagyobb értéket választja az (1) a Rendelési mennyiség és a (2) minimális rendelési mennyiség (Minrend) közül, és ezzel annyi megrendelést készít, ahánnyal a nettó szükséglet fedezhető. Tovább folytatja az eljárást addig, ameddig az összes nettó igény ellátását be nem tervezi.

40 / 136

Vállalati Információs Rendszerek BSc LFL (Lot For Lot) – Szükséglet szerint. Az MRP minden nettó szükséglethez külön-külön készít egy-egy megrendelést. Sok tervezett rendelés keletkezhet. A Rendelési időszak mezőt figyelmen kívül hagyja, nem von össze semmit, egy napon sem. A nettó szükségletek esedékességi dátumát a naptári napokban megadott Időhatáron kívülre tolja, azaz a dátumot az időhatárt követő első napra teszi, ha belülre esne. A rendelések feladási dátumát az így meghatározott esedékességi dátumból kiindulva határozza meg, levonja a beszerzési időt, gyártott alkatrész esetén munkanapokkal számolva. Ez lesz a feladási (kibocsátási) időpont még akkor is, ha ez az Időhatáron belülre esik. A megrendelt mennyiség a nettó szükséglet és a minimális rendelési mennyiség (Minrend) közül a nagyobb lesz. A ténylegesen megrendelt mennyiség, a POQ-hoz hasonlóan, végül is a Többször mezőben levő mennyiség legkisebb egész számú többszöröse lesz, amely legalább annyi, mint az előbb kiválasztott mennyiség. Ha az így meghatározott mennyiség meghalad egy előírt szintet (Maxrend), az MRP figyelmeztető üzenetet küld, de elkészíti a rendelést. OTO (One Time Order) – Egyszeri rendelés. Ez a rendeléspolitika készletezett tételekre nem alkalmazható, csak pl. projekt tevékenységek és egyszeri események tervezésére. Az MRP egyetlen egy, egységnyi mennyiségű rendelést hoz létre.

3.3.4.3. Főkönyvi adatok Főkönyvi adatok: célja a cikkek készletezésével, beszerzésével és értékesítésével kapcsolatos helyzet és változások érték szerinti követése főkönyvi számlákon történő könyveléssel. Az érték szerinti nyilvántartás helye megadható: Közvetlenül: a főkönyvi számlaszámot a cikktörzsben cikkenként közvetlenül megadjuk. Közvetetten: a cikkek pénzügyi csoportosításával, a megfelelő pénzügyi csoport cikkenkénti megadásával, és a pénzügyi csoportok főkönyvi számlához rendelésével. Számlaosztályok: a cikkekhez közvetetten vagy közvetlenül 3 számlaosztály kapcsolódik: Készletszámlák: a készletek érték szerinti vezetésére szolgálnak (anyag, félkész-, késztermék, befejezetlen termelés). Ezek a 2. számlaosztályba tartoznak. Ráfordítás számlák: amint a fentiek szerint nyilvántartott cikkeket eladjuk, értéküket átírjuk a Ráfordítás számlaosztály egyik számlájára, a 8. számlaosztályban. Ezek lesznek (többek között) a bevétellel szemben álló költségek (pl. az ELÁBÉ-ELadott Áru Beszerzési Értékét vagy az önköltség), és ezeket a bevétellel állítjuk szembe az adóalap kiszámításánál. Bevétel számlák: 9. számlaosztály, az értékesítés nettó árbevételének kimutatására. Költség számlák: 5. számlaosztály, az anyagok, szolgáltatások, nem készletezett cikkek értékének nyilvántartására. Az egyes számlaosztályok cikkenként (cikkcsoportonként) megbonthatók részletes kimutatás céljából.

3.3.4.4. Készlethelyzet változása A készletek mindig két nézetben jelennek meg: A készletek nyilvántartásában megkülönböztetünk mennyiségi és érték szerinti nyilvántartást. A mennyiségi nyilvántartást a raktárban kötelező vezetni, az érték szerinti nyilvántartást pedig a főkönyvi számlákon. A kétféle nyilvántartás aktualizálása nem mindig azonos időpillanatban megy végbe, ez a menedzsment döntésén múlik. Kereskedés és termelés szempontból a készlet magát a raktáron lévő cikkeket jelenti, és mennyiségi egységben (leggyakrabban darabban) mérhető. A fizikai készlet azonban mindig 41 / 136

Vállalati Információs Rendszerek BSc valamilyen értéket is képvisel, ezt nevezzük készletértéknek (értékelési módszereket lásd később). Utóbbi többek között a számvitelhez fontos, hiszen például az éves mérlegben is, szerepeltetni kell. A mennyiségi és/vagy érték szerinti változtatást a készletkönyvelés hajtja végre. Erre csökkenéskor, növekedéskor, esetleg átértékeléskor kerül sor az alábbiak szerint: Eladott vagy vásárolt cikkek esetén a szállítólevél vagy a számla könyvelésekor A raktárközi mozgatás, ha a rendszer szinkronban tartja a raktári és számviteli adatokat, megtörténik a főkönyvi számlákon is: A raktárak lehetnek valódi és virtuális raktárak is. A mennyiségi bevét, kivét könyvelés a kiadó és a fogadó raktárba egyaránt szükséges. Az érték szerinti könyvelés a rendszer megfelelő beállítása esetén a megfelelő főkönyvi számlákra is megtörténhet. Bevét könyvelése gyártásból: a szülő tétel elkészülte után, a munkalap vagy a gyártási rendelés könyvelésével történik az új cikk mennyiségi készletre vétele valóságos vagy virtuális raktárba. Ezzel egy időben az érték szerinti nyilvántartás is frissíthető, de ez nem kötelező. Kivét könyvelése gyártásba: A gyártáshoz szükséges cikkek igényelt mennyiségére azonnal foglalást kell végezni. A tényleges kikönyvelés késleltethető a szülő cikk készre jelentéséig, annak bevételezésével együtt történik meg a foglalt alkatrészek kikönyvelése a raktárkészletből. Az érték szerinti nyilvántartás opcionálisan frissíthető. Leltározáskor: növekedés vagy csökkenés is lehet, az eltéréseket bizonylatolni kell. A készletváltozás köthető a selejtezéshez is, ekkor mind mennyiségbeli, mind érték szerinti csökkentés történik a hibás cikkre vonatkozóan. Bizonylatolni kell. A készletek értékét befolyásolják a rendszerint utólag megérkező költségszámlák is, melyeket könyvelni kell. Ha utólag érkezik például egy fuvarszámla a szállításról, a készletek értékét ezzel (arányosan) emelni kell. Ezek könyvelésekor tehát megváltozik a raktárban lévő cikkek értéke, de mennyisége természetesen nem. Átértékelés: a piaci értékek követése. Csak érték szerint változhat. Nyitókészlet felvitelkor: A rendszer indításakor a megfelelő mennyiségi és értékbeli adatokat fel kell vinni. A raktárkészlet és raktárbeli készletérték változik, a számviteli készletérték nem feltétlenül. (Számvitelileg általában egy összegben, egy tételben viszik fel az egész kezdő készletet.) Folyamatos, több éves üzem esetén az évzárás, évnyitás alkalmából (főkönyvi számla nyitással vagy elővezetéssel hozható létre). Ez csak érték szerinti átvitelt jelent és csak a főkönyvi számlákon történik meg. A raktári készletet és készletértéket nem érinti. (Utóbbi kettőt az év végi leltár aktualizálja, lásd fent.) Gyártásban a könyvelés időpontja köthető (részletesen később): Cikkhez, a cikkek készrejelentéséhez: erre nézve bevét, alkatrészeire nézve kivét könyvelést indít meg a megfelelő raktárban. Művelethez: valamely művelet készrejelentése a megfelelő alkatrészek kivét könyvelését indítja; az utolsó művelet a szülő tétel bevét könyvelését (is) indíthatja.

3.3.4.5. Raktári és számviteli készletérték A raktárban a készletek mennyiségi nyilvántartását mindig vezetjük, az érték szerintit nem kötelező, de az integrált rendszerek vezetik ezt is. A főkönyvben értéke szerinti nyilvántartás van, mennyiségi nincs. A raktári készletvezetés és a számviteli készletvezetés szétválasztható. Emiatt megkülönböztetünk Raktári készletértéket, és Számviteli készletértéket

42 / 136

Vállalati Információs Rendszerek BSc Ha a menedzsment döntése alapján a kétféle készletértéket nem vezetik szinkronban, akkor a raktári és a számviteli készletérték eltérhet egymástól. Az eltérést a beszámoló elkészítéséhez év végi leltár alapján meg kell szüntetni: Meg kell állapítani a tényleges készletértéket. Ez kétféle képpen történhet: Először megállapítjuk a raktárban lévő cikkek tényleges önköltségét, értékét (utókalkuláció segítségével, a cikkek tényleges bekerülési árának kiszámolásával). Ezután a raktári készletértéket átvesszük a főkönyvbe, a számviteli készletértéket beállítjuk. (A raktári készletértéket átmásoljuk.) A pénzügyi nyilvántartás alapján utólag meghatározzuk az egyes cikkek tényleges bekerülési értékét, és ezzel állítjuk be mindkét készletértéket. (Ez a diktált ár (lásd lentebb) korrekcióját jelenti az éves tényadatok alapján.) A mennyiségi adatokat ekkor is a leltár határozza meg. Mindkét készletértéket együttesen módosítjuk. Figyelem: a készlet átértékelése más művelet, azt piaci információk alapján lehet elvégezni, és más könyvelési műveleteket igényel. Itt nem a készlet átértékeléséről, hanem csak az érték pontosításáról van szó

3.3.5. Termékcsalád, cikkcsoport Az olyan, szorosan összetartozó termékek csoportját, melyek hasonló módon funkcionálnak, azonos fogyasztói csoportokat szolgálnak, ugyanolyan típusú kiskereskedelmi egységben értékesítődnek, vagy azonos ársávba esnek, termékcsaládnak, vagy cikkcsoportnak nevezzük. Közös kezelésük megkönnyíti valamely más feladat végrehajtását. Az előállító vállalat szempontjából a termékcsaládok azon termékek csoportjai, melyek tervezési mennyiségei aggregált (összevont) termelési tervvel határozhatók meg. Aggregált terv: Az egy termékcsaládba tartozó termékek összevont kezelésével létrehozott termelési terv. Például négy és ötajtós autót is gyártunk. Tudjuk, hogy a kereslet 40%-60% arányban oszlik meg ezek iránt. Ekkor négy egész hattized ajtósnak számolhatjuk az autókat a költségek és időadatok meghatározása során. Az aggregált termeléstervezéshez szükséges adatok: Összevont cikk. Erőforrások. Fajlagos erőforrásszükséglet. A csoportos kezelés segítheti (az aggregált tervezésen túl): A cikkek definiálását a cikktörzsben a közös jellemzők öröklésével, pl. • Azonosító kód formája cikkcsoporton belül legyen egységes (pl. csak szám, vagy csak kisbetű/nagybetű stb.). • Készletvezetés legyen-e raktárban (pl. szolgáltatás jellegű cikknél nem értelmezett). • Készletértéket mi alapján számoljon a rendszer (pl. elszámoló ár, súlyozott átlagár) • Vámtarifaszám, SZTJ (szolgáltatások kódja) • ÁFA kulcs • Raktározás helye • Főkönyvi adataikat vezető főkönyvi számlaszámok, készletszámlák, értékesítési számlák és ráfordítás számlák A cikkek értékesítését és beszerzését részletező kimutatások készítését: • Időszaki forgalmi kimutatások készítése • Árrések meghatározása • Értékesítési árak összevont karbantartása (pl. %-os áremelés) A cikkcsoportok hierarchikus rendszerbe is szervezhetők. 43 / 136


3.3.6. Anyagjegyzék Mint erről már szó volt, az adott tételt – a szülő tételt – felépítő anyagokat, alkatrészeket és az ezekből szükséges mennyiséget az anyagjegyzék írja elő. Az anyagjegyzékben hivatkozott cikkeknek is lehet anyagjegyzéke. A rekurzívan bejárható teljes mélységű anyagjegyzéket anyagjegyzék-struktúrának nevezzük. Egyes alkalmazási területeken az anyagjegyzék helyett a receptúra szót használják (pl. édesipar). A receptura is lehet strukturált. A tárgy keretein belül összeépülő anyagjegyzék/darabjegyzék–modellre koncentrálunk. Az anyagjegyzék fix, opcionálisan választható, és alternatív cikkeket egyaránt tartalmazhat. A fix cikkek mindig beépülnek. A választható cikkeket nem kötelező beépíteni, de lehetséges, ilyen például a klímaberendezés az autóban. Az egy opcióhoz tartozó alternatív cikkek közül pontosan egyet kell beépíteni a termékbe. Ilyen az autónál a fényezés színe. A választható és alternatív cikkek variálásával kialakítható kombinációkból a megrendeléskor ki kell választani az aktuálisan szükségeset. Ez az eljárás a variánskezelés, az ilyen cikkeket (melyek tartalmaznak választható vagy alternatív alkatrészeket) pedig a konfigurált termékeknek nevezzük. Az anyagjegyzék adatai: Azonosító kód, megnevezés – esetenként elmaradhat, de ekkor a szülő tételhez kell kötni. Érvényesség meghatározása (-tól, -ig). Beépülő tételek azonosítása és a szükséges mennyiség meghatározása. Egyéb nyilvántartási és vezérlő adatok.

3.3.7. Készletek, készletgazdálkodás Készletek: Azon cikkek, melyek mennyiségi mérőszámmal megmérhetők és raktározhatók. Számviteli értelemben a vállalat teljes készletállományát két fő csoportba és ezen belül alcsoportokba kell sorolni. 1. Vásárolt készletek Anyagok: azok a cikkek, vagyontárgyak, melyek a termék előállítása során eredeti alakjukat elvesztik, és értékük az előállított termék értékében jelenik meg. Szokásos csoportjaik: • Alapanyagok. • Segédanyagok. • Üzemanyagok. • Egyéb anyagok. Áru: változatlan formában való továbbadás céljából beszerzett termék. Betétdíjas göngyöleg: olyan csomagoló eszköz, amely • a terméket szállíthatóvá teszi vagy a terméket szállítás közben a rongálódástól megóvja, • többször felhasználható, • a kibocsátót visszaváltási kötelezettség terheli. Készletekre adott előleg: az anyag-, illetve áruszállítónak szolgáltatásra vagy anyagra/árura átadott összeg, mert most még nincs, de később készlet lesz belőle. Alvállalkozói teljesítmény: mindaz a munka, amit a termék előállítása érdekében más vállalkozó végzett el helyettünk. 2. Saját termelésű készletek: azok a készletek, amelyeket a vállalat legalább egy munkafázis elvégzésével maga állítja elő. 44 / 136

Vállalati Információs Rendszerek BSc Befejezetlen termelés: megmunkálás alatt álló anyagok, cikkek, melyeken legalább egy számottevő művelet elvégeztek, de az aktuális (művelettervben) előírt technológiai megmunkálás befejező szakaszát még nem hagyták el. Félkész termék: olyan cikk, amely • legalább egy megmunkálási szakaszon átesett, • raktárra került, • de még további megmunkálásra van szükség. A félkész termékek raktározási költségeit el lehet számolni az önköltségben. Késztermék: olyan cikk, amely • a vállalaton belül minden előírt termelési folyamaton átment, • minősége megfelel a szabványnak vagy a műszaki előírásoknak. Raktározási költségei értékesítési költségként számolhatók el, ezért nem számolhatók bele a termék önköltségébe.

3.3.7.1. Készletgazdálkodás A készletek (naturáliák) azok a vagyontárgyak, amelyek raktározhatók, mennyiségi mérőszámmal megmérhetők. A készletgazdálkodás olyan szabályok és eljárások összehangolt együttese, amely rutin jellegű döntéseket tesz lehetővé a „mikor és mennyit rendeljünk ill. termeljünk” kérdésekben annak érdekében, hogy a fogyasztók igényeit kielégítsük. Felhívja a döntéshozók figyelmét olyan nem rutin jellegű döntésekre, amelyekre ezek a szabályok nem alkalmazhatók.

3.3.7.2. Készletezés célja A termék változó keresletének kielégítése, az igényben jelentkező mennyiségi változások elnyelése, pufferelése → ütköző vagy biztonsági készlet. Alacsony költségű gyártás elérése érdekében az egyes műveletek függetlenségének fenntartása, a termelés ütemezés rugalmasságának biztosítása → hosszabb átfutási idő, de zavartalan a termékáramlás és alacsonyabb költségű a gyártás (átállási költségek miatt!) Ez lényegében a gazdaságosságot és a gyorsaságot szolgálja: Ha már egyszer a beállítási időt el kellett pazarolni, akkor gyártsunk le többet belőle előre. Ez a gondolkodás pedig mindenképpen szükségessé teszi a készletezést: Például, ha a Többször mező ki van töltve két egymástól függő termékre, és az egyiknél 150, a másodiknál 200, akkor nem lehetne készletezés nélkül megoldani a problémát, ugyanis az elsőből 300-at kell legyártani a második szükségletének kielégítésére, de abból megmarad 100.

offenzív okok

A nagyobb rendelési mennyiségből adódó előnyök kihasználása (pl. mennyiségi kedvezmény a beszállítónál). Szállítási csúszások kivédésére biztonsági tartalékok felhasználása. defenzív ok Ha a készlet túl magas, sok tőkét köt le. Ha túl alacsony, gátja lehet a magasabb árbevétel elérésének, haszonnak, magasabb költségeket és határidő-túllépéseket eredményezhet. Látható tehát, hogy az optimális készletszint nem határozható meg általánosságban, csak valamilyen elv, politika definiálása után. El kell dönteni, hogy a vállalatnak mi a fontosabb, mi a célja: minimális forgótőke használata, vagy a gyors teljesítés biztosítása. A vállalatnál az egyes funkcionális területek érdekei is különböznek Beszerzés: nagy készlet, mert így csökken a beszerzési ár (nagy tételt vehet).

45 / 136

Vállalati Információs Rendszerek BSc Termelés: nagy készlet, mert nagyobb sorozat indulhat, és így alacsonyabb az a gyártás fajlagos költsége, valamint folyamatos lehet a termelés. Értékesítés: nagy készlet, hogy mindig szállítóképes legyen, nagyobb megrendelések esetén is. Pénzügy: alacsony készletben érdekelt, hogy, kevés legyen a lekötött tőke, és alacsony legyen a raktározási költség. A készletek hátulütője: elfedik a hibákat. Remek analógiával szemlélteti a helyzetet 3.4. ábra. A készletszint és a szükséglet viszonyát úgy lehet elképzelni, mint a tengervíz és a tenger fenekén lévő zátonyokét. A tengervíz a készlet, a zátony pedig a szükséglet. Ameddig a készletszint nagy, elfedi a szükségletek jellemzőit, vagyis a víz ellepi a zátonyokat. Nem szembesülünk azzal, hogy milyen szükségletek mikor merülnek fel, nem válnak nyilvánvalóvá a termelés esetleges hibái. Lehet például, hogy a beállítási idő nagyon nagy, és emiatt nem tudnánk teljesíteni a határidőket. De mivel van készlet, onnan teljesíthető a megrendelés, nem derül fény a túlzottan nagy beállítási időre. A készletszintet 1-ről 2-re csökkentve (ábra) azonban a probléma kiderül, ugyanis „kilátszik a tengerből a zátony”. Lehetséges az is, hogy a szükségleteket le lehetne szorítani, csak eddig lusták voltak hozzá, hiszen a magas készletszint nagy kényelmet adott.

Szükséges készlet a probléma megoldására Készletszint 1

Készletszint 2

Problémafajták 3.4. ábra Tenger-zátony modell a hibák felderítéséhez

3.3.7.3. A készletezés költségei Utánpótlás költsége vagy megrendelési költség: • Közvetett: Vezetési és irodai költségek, amelyek a vásárlási vagy gyártási megrendelés előkészítésével, a megrendelések meghatározásával és kibocsátásával kapcsolatos költség → beszállítói költség. • Közvetlen: minden egyes cikkfajta külön számbavételének költsége (átvétel, minőségellenőrzés) → cikköltségnek is hívják. Készlettartási költség: • Raktárköltség: világítás, fűtés, karbantartás, ingatlan amortizációja.

46 / 136


Készlettárolási költség: berendezések és anyagmozgatás költségei, a lekötött tőke elmaradt haszna, törés, elavulás, értékcsökkenés. • Egyéb: biztosítás, igazgatás költségei, lopásból eredő kár. A készlettartási költség értéke függ a raktárkészlet mennyiségétől és a tárolás idejétől. Hiányköltségek: • Számszerűsíthető: váratlan igény, sürgős megrendelés többletköltségei (pl. szállítási költség), kötbér. • Nem számszerűsíthető: vevő elvesztése, elmaradt haszon, jó hírnév elvesztése.

3.3.7.4. Készletértékelési módszerek Kiindulási értékek: Vásárolt termékek esetén: tényleges_beszerzési_költség = vételár – engedmény + felár + szállítási_költség + vámköltség (vám + vámkezelési díj) Nem tartalmazhatja: az általános forgalmi adót, a hatósági díjakat, az illetéket, a vásárolt készletekhez közvetlenül hozzá nem rendelhető szállítási és rakodási költségeket. Ezt nevezik bekerülési vagy beszerzési értéknek. Saját előállítású készletek esetén: az előállítási önköltségből indulunk ki, ami az előkalkulációval határozható meg, illetve a projekt vagy az év végén utókalkulációval pontosítható. Természetesen ennek nem része az értékesítési költség, sem az előállítással közvetlen kapcsolatban nem lévő igazgatási és más általános költségek. A raktárban a készletek az idő folyamán csökkennek és növekednek. Ezzel együtt változnak a konkrét „termék-egyedek” a raktárban, és ezeknek beszerzési ára különbözhet. A raktárkészletet (és az éppen kivenni szándékozott terméket) az alábbi eljárásokkal kezelhetjük és értékelhetjük. (A használható eljárásokat a számviteli törvény írja elő.) Elszámoló ár: a vezetés által megszabott, deklarált ár, amelyet év elején rögzítenek az előző év alapján. Év végén ki kell számítani az átlagárat, ezt össze kell hasonlítani az elszámoló árral, és az árkülönbözettel az évközi változásokat utólag helyesbíteni kell Folyamatosan vezetett átlagár: költség alapján minden bevételezésnél súlyozott átlagárat számolunk az akkor éppen bent lévő tételek száma, aktuális átlagára valamint a bevételezésre kerülő tételek száma és aktuális ára (bekerülési értéke) alapján. Beszerzési ár: Minden tételt a szállító által leszámlázott nettó értéken tartjuk nyílván (+ a rárakódó költségekkel együtt). A kimenő tétel mindig a saját értékével csökkenti az össz készletértéket. Ekkor az aktuális készletértéket a cikkek raktári kiadási algoritmusa határozza meg: • FIFO: az elsőként beérkezett terméket használják fel előbb; a megmaradó raktárkészletet az utoljára vásárolt áruk alkotják. Monoton növő infláció esetén ez adja a legmagasabb készletértéket. • LIFO: az utoljára beérkezett termékeket adják ki előbb. Monoton növő infláció esetén ez adja a legalacsonyabb készletértéket. • HIFO: (highest-in-first-out): módszerében ugyanaz, mint a FIFO, de követi a készletelemek árváltozását, legmagasabb árról indul. Tetszőlegesen változó bekerülési árak mellett is a lehető legalacsonyabb készletértékhez vezet. A készletezés algoritmusát az év elején írásban rögzíteni kell. Év végén újat választhatunk.

47 / 136


3.3.7.5. Készletgazdálkodási rendszerek Döntési modellek, amelyek a vállalatvezetés számára a döntéshozatalt előkészítik. (Olyan döntéstámogató rendszerekről, döntési modellekről van szó, amelyek a vállalatvezetés számára a döntéshozást előkészítik.) A készletgazdálkodási rendszer feladata: a készletek fenntartásához és szabályozásához szükséges rendről és működő politikáról gondoskodni. Célja: meghatározni, hogy mikor rendeljünk és mennyit rendeljünk, illetve az elhatározott megrendelés végrehajtása. Az alábbi csoportokat különböztethetjük meg: Integrált készletezési rendszerek • Szükséglettervező rendszerek. Alap algoritmusa az MRP, MRP II, CRP, DRP. Ezeket az ERP rendszerek integrálják. A jövőt is (részben) ismerik, tudják milyen megrendelések és egyéb igények várhatók, továbbá számba veszik a várható szállításokat is. • Kanban rendszer (cetli). A készletek mérését itt is tudni kell. Jellemzői: egyszerű szabályozás, „szívás” jellegű vezérléssel. Készletek a munkahelyeken vannak a konténerekben. Keretszerződés, szükség szerinti rendelés. Cél: a készletek csökkentése, a konténerekben lévő tételek számának csökkentése, és a kanbanok (ezzel együtt a konténerek) számának csökkentése. Kanban = japán „cetli”. Egyszerű, szívásos jellegű vezérlést valósít meg. Szívásos, mert a késztermékek legyártásához a kanban kirakásával ad engedélyt a fogyasztó folyamat. Előfeltétele, hogy a vevő és a szállító egymással keretszerződést kössön éves viszonylatban, és mind a szállító mind a vevő felkészüljön arra, hogy milyen termékforgalmat kell bonyolítania. A keretmennyiségeknek a lehívását kell csak ütemezni ezután, erre szolgálnak a kanbanok. A lehívás mondja meg, mikor és mennyire van szükségünk. Ezt a szállítónak egy cetlivel jelezzük. A termelő helyeken konténerek vannak, mindegyikben valamennyi mennyiségű áru fér el. A készletek nem raktárban vannak, hanem a konténerekben. Ha kapunk egy cetlit, akkor az ezen szereplő termékből, a szintén rajta szereplő kért határidőre egy konténernyi legyártására kapunk engedélyt. Legyártjuk. Amennyiben azt látjuk, hogy saját anyagaink elfogytak, mi is adunk a szállítónknak egy cetlit. Ez csak akkor történik meg, ha elhasználtuk a konténernyi alapanyagot. Így tehát az igények egymást indukálják, láncot alkotnak. A kanbanok nem csak gyártó és szállító között használatosak, hanem a gyártás egyes folyamatai között is. A termékek előállítását az értékesítés fogja meghatározni, húzni maga felé egy kanban kiadásával. Annak érdekében, hogy a rendszer áttekinthető legyen, a cetliket egy táblára helyezik ki. Raktár nincs, a termékek a műhelyekben várakoznak a konténerekben. Van olyan rendszer, ahol a nagy mennyiségek miatt több cetlivel és ezzel együtt több konténerrel is dolgoznak egyidejűleg. Itt természetesen nagyobb a (gyártás közi) készlet. A legyártható termékek, vagyis a kihelyezett cetlik közül a közvetlen termelésirányítók választanak a termelési helyzettől függően. Keretszerződés szerint terveznek, és szükséglet szerint gyártanak. Cél: készletek csökkentése a késztermékek (kanbanok) számának csökkentésével valamint a konténerben lévő cikkek számával.

48 / 136

Vállalati Információs Rendszerek BSc Két kanbanos rendszer: ez termelési és szállítási kanbannal dolgozik (a termelési és szállítási egység konténerben van), az egy kanbanos csak eggyel, a termelésivel. A termelési kanban hatására elkezdik a termelést. A szállítók azonban nem szállítják el a teli konténert csak akkor, ha a szállítási kanban is rákerült. A szállítási kanban tehát a szállítók vezérlésére szolgál. Tiszta készletezési rendszer: múltbéli adatok alapján válaszol a kérdésekre • Determinisztikus modellek: minden adat pontosan ismert (mik voltak szükségletek stb.). • Sztochasztikus modellek: az adatok statisztikai eloszlással, vagy becslésekkel határozhatók meg

3.3.7.6. Tiszta, determinisztikus modellek Választípusok a mikor kérdésre: A rendelést rögzített időszakonként kell feladni (T). (Idő váltja ki a rendelést.) A rendelésről akkor döntünk, amikor a készlet egy meghatározott minimumszint (R) alá csökken. (Esemény váltja ki a rendelést.) Választípusok a mennyit kérdésre: A rendelési tétel nagysága rögzített (Q). A rendelés olyan mennyiségre vonatkozzon, hogy a beérkezés után a készletszint elérjen egy előre meghatározott maximális értéket (S). A készletgazdálkodási alaprendszerek ezek kombinációi, amit a 3.4. táblázatban foglaltunk össze. 3.4. táblázat: A készletgazdálkodási alaprendszerek Idő

Mennyiség

fix

fix

változó

T,Q (QAD EA: „Nem tud ilyen buta lenni”.)

R,Q (QAD EA: FOQ, de okosabb nála.)

T,S (QAD EA: POQ, Rendelési időszak mezőben meg kell adni milyen változó időközönként rendeljen - ha kell. A készletszintet viszont nem tudja maximalizálni.)

Rendelés

Idő váltja ki a megrendelést

R,S (QAD EA: Közelíthető a modell de nem lehet jól megcsinálni. A QAD EA mindig a szükségleteket fedezi. Esetleg az LFL használható.) Esemény váltja ki a megrendelést

Az alaprendszerek működésének szemléltetése Kikötjük az alábbi feltételeket: 1. A készletállomány ellenőrzése időszakos (havi, heti, kétheti, stb.), vagyis csak ilyen időközönként foglalkozik a beszerzéssel valaki a vállalatnál. Nem feltétlenül történik azonban rendelés minden ilyen alkalommal, csak ha szükséges. (Ez tehát nem a T-t jelenti.) 2. Az igény, a felhasználás folyamatos és egyenletes két ellenőrzés között. 3. A rendelés és a beérkezés folyamata ideális, vagyis a szállítás a megrendeléskor egy tételben, azonnal, a kívánt mennyiségnek megfelelően beérkezik. 4. A beérkezéskor az esetleges hiányt azonnal felszámoljuk. (Megjegyzés: A hiány azt jelenti, hogy ennyi kell még a függő megrendelések teljesítéséhez.)

49 / 136


A feltételeket elfogadva az alaprendszerek a 3.5, 3.6., 3.7. és 3.8. ábrán szemléltetett módon működnek: T,Q: mennyiség Q

idő T 3.5. ábra T-Q alapmodell működése T időközönként, a megfelelő ellenőrzési pontokon, mindig Q mennyiséget rendelünk. Az átlagos raktárkészlet ideális fogyás, összhang esetén: Q/2. Ha jól állítottuk be a rendszert, éppen nullára fogy a készlet T idő alatt. Ha viszont T alatt nulla alá csökken (hiány), továbbra is csak Q-val töltődik fel, így a hiány megmaradhat. Ugyanígy felhalmozódás is előfordulhat. Az átlagos készletszint:

≈

Q . 2

QAD EA-ban rendelési politika FOQ-val lehet megközelíteni, és T időpontokban kell futtatni, ekkor sem rendel, ha nincs rá szükség. Nem lehet ilyen merev szabályozást beállítani. T,S: mennyiség S

idő T 3.6. ábra T-S alapmodell működése A megfelelő ellenőrzési ponton feltöltjük a készletet S-re. Átlagos készletszint:

≈S−

átlagfogyás . 2

QAD EA-ban POQ, Rendelési időszak mezőt T-re kell állítani és T időközönként kell futtatni, de a készletszintet nem tudja maximális értéken tartani.

50 / 136

Vállalati Információs Rendszerek BSc R,Q: mennyiség Q

+Q

R

idő 3.7. ábra R-Q alapmodell működése

Ha egy ellenőrzési időpontban a minimális (R) alatt van a készletszint, rendelünk Q-t. Átlagos készletszint:

≈ R+

Q . 2

QAD EA-ban: biztonsági szint előírása = R, FOQ rendeléspolitika, de nagyobb igény esetén több megrendelés készül a Rendelési mennyiség mezőben megadott mennyiséggel. R,S: mennyiség S

R idő 3.8. ábra R-S alapmodell működése Ha egy ellenőrzési időpontban a minimális (R) alatt van a készletszint, rendelünk S-ig. Átlagos készletszint:

≈

R+S . 2

QAD EA-ben ilyen nincs, de ami megtehető: biztonsági készletszint és POQ, LFL időhatárok nélkül. A feltételek megváltoztatása 1M. Az időszak hossza legyen 0 – ekkor a készletszintet minden időpillanatban ismerjük. T,Q: semmi sem változik. T,S: semmi sem változik. R,Q változik: Átlagos készletszint pontosan R+Q/2 lesz. Hiány nem lesz, átlagos készletszint

=R+

Q . 2

51 / 136

Vállalati Információs Rendszerek BSc R,S változik: R alá nem tudunk lemenni, mert azonnal rendelünk. Változó időpontban, de mindig (S – R)-t rendelünk. Hiány nem lesz, az átlagos készletszint

=

R+S . 2

2M. A fogyás sebessége változik két ellenőrzési pont között. Egyiknél sem változik semmi, mert csak az ellenőrzési pontokban lévő készlet mennyisége a kérdés. 3M. A szállítási idő nem 0, és/vagy több tételben szállítanak. Megoldás: előre kell tervezni, aminek pontosságát már befolyásolhatja a fogyási sebesség változása. Pl. QAD EA-ban meg lehet adni a szállítási időt, ennyivel előbb rendel. A QAD EA viszont ismeri a jövőt is, ami nem kis teljesítmény! Ha ismerjük a szállítási időszükségletet, és egy tételben szállítanak, akkor T,Q: belekalkulálható. Ha a szállítási idő fix, a modell időben eltolódik, de nem változik. Ha a szállítási idővel előre kalkulálunk, akkor még ez sem lép fel. T,S: A rendelendő mennyiséget T időpontokban határozzuk meg, később érkezik be a megrendelt tétel. Beszállítás beérkezésekor sem lesz S a készletszint. Általában csökken az átlagos készletszint, nőhet a hiány is. Ha hamarabb rendelünk, akkor a pontos rendelési mennyiség meghatározása problémás. R,Q: A késleltetés miatt jobban lecsúszunk R alá, az átlagos készletszint csökken. A hiány fellépésének lehetősége nagy. Ez ellen magasabb R szinttel lehet védekezni. Ha előbb rendelünk, és a rendelési időpontot az időszak fogyasztása alapján becsüljük, akkor csak a fogyási sebesség ingadozása okozhat problémát. Nőhet a hiány is vagy az átlagos készletszint. R,S: Ez sem tud feltölteni S-re, a hiány esélyéhez lásd R,Q-t, az átlagos készletszint csökken. Ha előbb rendelünk, a rendelési mennyiséget becsüljük, (S-R) körül fog ingadozni. 4M. Nem számoljuk fel automatikusan a hiányt, azaz az összes rendelést eldobjuk amint a készletszint nullára csökken. Ez modellezési zavart okoz, nem értelmezett.

3.3.7.7. Készletgazdálkodási modellek a célfüggvény tartalma szerint Költségminimalizálás: a készletezéssel kapcsolatos költségek minimálisak legyenek. Ezek között determinisztikus és sztochasztikus modellek egyaránt vannak. Megbízhatósági modellek: Költségtényezők nincsenek, cél egy adott biztonsági szinten kielégíteni a keresletet. (Valószínűségi változókkal dolgozik.) Egyéb modellek: Pl. nyereség-maximalizáló modell. Az elérni kívánt célt a vállalat vezetése dönti el stratégiai szempontok szerint. A továbbiakban csak költségminimalizálással foglalkozunk. Költségminimalizálás alapmodelljei A modellezés feltételei: 1. Egy anyag készletezési problémájával foglalkozunk a [0, T] intervallumon. 2. A [0, T] intervallumban a szükséglet ismert: N. 3. Időegységre jutó szükséglet ismert, állandó:

r=

N . T

4. Hiány nem engedhető meg. 5. Utánpótlási idő 0, és a teljes mennyiséget szállítják.

52 / 136

Vállalati Információs Rendszerek BSc A modell költségtényezői a következők: 1. A beszerzés/utánpótlás költsége adott: Kr 2. A beszerzési mennyiséggel arányos költség (pl. vételár), azaz az egységköltség ismert, és konstans: Ke 3. Az egységnyi készlet időegységre jutó készlettartási költsége ismert: Kk Kérdés: mennyit rendeljünk (Q) és mikor, hogy az összes készletezési költség minimális legyen (Kö → min)? Folytonos termék, diszkrét beszállítás modellje: A beszállított mennyiség folytonos, például folyadékról van szó, amit milliliterben tudunk rendelni. (Ez a feltétel a deriváláshoz szükséges.) mennyiség Tétel: akkor minimális az összköltség, ha egyenlő nagyságú tételeket rendelünk egyenlő időközönként akkor, amikor a készletszint 0-ra csökkent. A modell működését a 3.9. ábra szemlélteti. idő 3.9. ábra Optimális rendelési politika

Kö = Ke ⋅ N + 0=−

N Q ⋅ Kr + ⋅ Kk ⋅ T Q 2

K ⋅T N ⋅ Kr + k 2 Q 2

⇒ Q=

A rendelés feladásának időpontja:

t1 =

, ezt kell Q-ra minimalizálni ⇒ deriváljuk.

2⋅ N ⋅ Kr T ⋅ Kk

Q = r

→

N = r ⋅T

Q=

2 ⋅ r ⋅ Kr Kk

.

2 ⋅ Kr . r ⋅ Kk

Érzékenységvizsgálat: A paraméterek pontatlanságának hatása mekkora? Ha pl. a rendelési mennyiséget nem ismerjük pontosan a paraméterek becslési pontatlanságának hatására:

x = α ⋅ x′ ⇒ Q = Q ′ ⋅ α . Q’: ideális rendelési mennyiség. A gyökjel miatt a hiba nagyságának hatása csak gyökösen rontja a helyes eredményt. Változtassuk meg az ötödik feltételt, miszerint az utánpótlási idő nulla, és a megrendelt tételt egyszerre szállítják. A szállító ne egy tételben szállítson, hanem folyamatosan, „adagolva” szállítsa a megrendelt mennyiséget. Folytonos termék folytonos beszállítás modellje Működését a 3.10. ábra szemlélteti. mennyiség Q

b: beszállítási sebesség r: készletfogyási sebesség b – r: készletépítési sebesség b m

y

T

idő

3.10. ábra Optimális rendelési mennyiség 53 / 136

T = x+ y

x ⋅ (b − r ) = y ⋅ r = m

m = Q⋅

r

x

m y = Q T

b−r b

a raktár maximális mennyisége

Ha a b végtelen nagy, vagyis egy tételben szállít a szállító, akkor az m tart Q-hoz. Helyettesítsük be Q helyére az átlagos készletszint tagnál m-t. Új rendelési mennyiséget kapuk:


Q′ =

2 ⋅ r ⋅ Kr 2⋅ r ⋅ Kr b = ⋅ b−r K b−r k Kk ⋅ b

3.3.7.8. Költségminimalizálás diszkrét termék diszkrét beszállítása esetén Eddig feltettük, hogy Q folytonos mennyiség. Legyen a továbbiakban Q diszkrét (n, 2n, 3n...). Kérdés a gazdaságos rendelési mennyiség. Kiindulás: ha eltérünk az optimumtól, akkor a költség nő. A diszkrét változás miatt nem lehet differenciálni. (Q az ideális rendelési mennyiséget jelöli.):

K ö (Q) ≤ K ö (Q + n) és II. K ö (Q ) ≤ K ö (Q − n) . I.

I. kifejtése:

N ⋅ Ke +

N Q N Q+n ⋅ Kr + ⋅ Kk ⋅T ≤ N ⋅ Ke + ⋅ Kr + ⋅ Kk ⋅T Q 2 Q+n 2

Q2 ⋅T Q⋅N Q ⋅ (Q + n) N ⋅ Kr + ⋅ Kk ≤ Kr + ⋅T ⋅ Kk 2 Q+n 2  Q  T ⋅ Kk  ≤ N ⋅ K r ⋅ 1 − ⋅ Q ⋅ (Q + n) − Q 2 2  Q+n

(

)

2 ⋅ N ⋅ Kr ≤ Q ⋅ (Q + n ) T ⋅ Kk A másik (II.) egyenlőtlenség hasonlóan kezelhető. Végeredményként kijön, hogy

Q ⋅ (Q − n ) ≤

2 ⋅ N ⋅ Kr ≤ Q ⋅ (Q + n ) . T ⋅ Kk

Ebbe behelyettesítve a Q = m ⋅ n diszkrét értékeket: 2 NK r m ⋅ n ⋅ (m ⋅ n − n ) ≤ ≤ m ⋅ n ⋅ (m ⋅ n + n ) TK k 2 NK r m ⋅ (m − 1) ≤ ≤ m ⋅ (m + 1) TK k n 2 2

1 2 NK r 1  1  + ≤ m +  m −  ≤ 2 2  TK k n 4  2 

2

54 / 136

Vállalati Információs Rendszerek BSc 1 2 NK r 1 1 1 ≤ + ≤m+ (a gyökvonással nincs gond: m pozitív egész, tehát m − is 2 2 TK k n 4 2 2 pozitív, illetve a gyökjel alatt is pozitív érték áll) m−

−

1 2 NK r 1 1 2 NK r 1 + + ≤m≤ + + 2 2 TK k n 4 2 TK k n 2 4

Ugyanezt grafikusan a 3.11 ábra szemlélteti: 2 2 1   2 NK r 1  1   2 NK r 1    +  ≤ 0 és 0 ≤  m +  −  +   m −  −  2   TK k n 2 4  2   TK k n 2 4    2 NK r 1 + TK k n 2 4

Vezessük be a konstansok helyett: x =

6

5.5

5

4.5

4

3.5

3

2.5

2

1.5

1

0.5 x

x

x

x

0 -2

x2

-1.5

-1

-0.5

0

0.5

1

1.5

2

m

-0.5

x

x

x

x

A megoldás ebből az intervallumból kerül ki (az intervallum hossza 1, így egy pozitív egész szám biztosan van benne)

3.11. ábra Optimális rendelési mennyiség diszkrét esetben

55 / 136


3.3.7.9. ABC készletrendszer Minden készletmozgáskor ellenőrizni kell a készletet. Alapvetően azt mondhatjuk, hogy minden készletmozgáskor ellenőrizni kell a mozgatott mennyiséget és év végén leltárt kell készíteni, de ezeknek részletessége és mikéntje az egyes cikkeknél különböző kell legyen. Mekkora legyen a szükséges ellenőrzés, milyen pontosak legyenek az adatai, mekkora költséget érdemes az ellenőrzésre fordítani? Milyen mértékegységgel célszerű mérni és nyilvántartani a készletet? A készletellenőrzés problémái: Mekkora a szükséges ellenőrzés? Mekkora erőfeszítéseket (költséget) érdemes fordítani a cikkek mennyiségének meghatározására tetszőleges típusú készletmozgáskor (raktári kivét, betét) és készletellenőrzéskor (leltár)? Milyen pontosak legyenek az adatai? Mekkora költséget érdemes az ellenőrzésre fordítani? Lehetséges ugyanis, hogy maga a leltár például több költséggel jár, mint amennyit a leltározott cikk ér. A válasz tapasztalatokon alapuló osztályozási rendszer segítségével adható meg: Pareto-elv. [Villfredo Pareto (XVIII. század, Milánó) megfigyelte, hogy a családok 20%-a rendelkezik a város vagyonának 80%-ával, további 30% a vagyon 15%-ával és a maradék vagyon a családok 50%-ának tulajdonában van. Kit érdemes adományért látogatni?] Készletgazdálkodásban a cikkek értékvolumenét tekintjük: értékvolumen = egységár * éves_mennyiség

Az ABC besorolás meghatározása 1. Meghatározandó minden cikk értékvolumene. 2. Csökkenő sorrendben kiválasztandók azok a cikkféleségek, amelyeknek legnagyobb az értékvolumene – mindaddig, amíg az összes értékvolumen kb. 80%-át el nem értük. Ezek lesznek az A jelű cikkek. 3. A maradékból kiválasztandók azon cikkféleségek, melyek az össz értékvolumen további 1020%-át adják. → B jelű cikkek. 4. A fennmaradó cikkféleségek lesznek a C jelű cikkek. A cikkféleségek aránya az egyes kategóriákban általában követik Pareto megfigyelését, amit a 3.12. ábra szemléltet. Értékvolumen

∼80%

∼15% ∼5%

Cikkféleség%

20%

50% 100% 3.12. ábra ABC készletrendszer és a Pareto-elv

56 / 136


A cikkek vállalati besorolását stratégiai megfontolások alapján felülbírálhatják, pl. a nehézkes szállítókat, a stratégiai fontosságú termékeket (pl. fő alapanyag, ha annak beszerzése nehéz) akkor is ha, ezek értékvolumene csekély. A szükséges ellenőrzés mértéke ezután nem cikkenként, hanem kategóriánként irható elő. A szükséges ellenőrzés mértéke: A: különös gonddal kell kezelni, még akkor is, ha többletköltséggel jár. Precíz mérési módszereket kell alkalmazni: megszámlálás, pontos mérés. (Mozgó tételek mennyiségének tételes ellenőrzése leltározáskor és készletmozgáskor.) B: formális eljárásokkal rutinszerű ellenőrzéseket kell végezni, pl. mintavételezéssel, darabszám helyett tömeg méréssel. C: egyszerű módszereket lehet alkalmazni, pl. becslés. A megkövetelt pontosságot is a fentiekben meghatározott csoportokra írjuk elő. A megengedett hiba az APICS(American Production and Inventory Control Society) szerint a következő: A: 0..0,2%, B: ≈ 1%, C: ≈ 5%. Ezek elfogadható költségszinten teljesíthetők.

Az ellenőrzés időpontja: Mozgó készletek esetén készletmozgáskor. Maradék készletek ellenőrzése (leltározáskor): • Cikkenként változó időszakok írhatók elő (folyamatos leltár). • Egyszerre minden cikket, de a gazdasági év végén mindenképpen (fordulónapos leltár). A leltározást azonban nem tudjuk mindig a fordulónapon megtenni. A leltár elkészítése és a fordulónap között a készletek mozoghatnak, ezért a fordulónapra kell vonatkoztatni a tényleges készlet mennyiségét, vagyis a leltár során kapott eredményt korrigálni kell a mozgási adatokkal. Az ellenőrzés technikai lebonyolítása: „Vak” leltár: üres lapra felírjuk a talált cikkeket és mennyiségeket. Előnye, hogy kényszerít a teljes átvizsgálásra, mivel mindenhova benézünk, és nem tudjuk előre, hogy mit és mennyit kéne találni. Hátránya, hogy néha olvashatatlan a kézírás, ezenkívül hiányos lehet a leltározók termékismerete, illetve félremérések is előfordulhatnak (pl. 0,1 mm különbségű lemezvastagságoknál nem nehéz ilyet csinálni). Leltározandó cikkek tételes felsorolása után a talált mennyiségeket kell csak rögzíteni. Hátránya, hogy nem fognak mindent átnézni a dolgozók, azt mondják, ennyit találtak, és kész. Előnye a cikkek pontos nyilvántartása.

57 / 136


4. INFORMÁCIÓS FOLYAMATOK A fő folyamatnak 5 lépése van:

1. Rendelésfeldolgozás a. Vevői rendelések elfogadása (ajánlatok kibocsátása). b. Saját kockázatú gyártási rendelések. (A vállalat megfelelő piackutatás elvégzése után úgy dönt, hogy egy által gyártott terméket a vezetőség által meghatározott mennyiségben érdemes gyártania, mert azt el fogja tudni adni, arra lesz nyereséget hozó kereslet.) 2. Szükségletszámítás és ütemezés a. Készletszintek szabályozása: ne legyen szükség nagy raktárkészletre, de mindig legyen elegendő anyag. b. Rendelések teljesítéséhez szükséges cikkeknek, ezek mennyiségének és a szükséglet felmerülése időpontjának meghatározása. 3. Beszerzés a. A vásárolt alkatrészek, anyagok mennyiségi biztosítása megfelelő időpontban, megfelelő mennyiségben. 4. Gyártás a. Gyártott cikkek mennyiségi biztosítása adott határidőre. 5. Kibocsátás és számlázás a. A végtermékek elosztása a vevők között (akkor van probléma, ha a gyártási kapacitás szűk). b. Ellenérték megszerzése.

58 / 136


4.1. RENDELÉSFELDOLGOZÁS A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.1. ábra szemlélteti. Vevői rendelések

Vevők

Vevői megrendelés

Rendelés elfogadás Teljesíthetőség vizsgálat Hitelképesség vizsgálat

Saját kockázatú rendelések

Ütemezési adatok

Elfogadott (vevői) rendelések

Primer szükséglet

4.1. ábra Rendelésfeldolgozás eseményei és funkciói

Rendelés elfogadása Indulhat vevői érdeklődésre adott válasszal (ajánlat). Saját kockázatú megrendelést piackutatás előzi meg. A rendelés elfogadásának lépései: 1. Teljesíthetőség vizsgálat, a szereplő cikk, mennyiség, határidő, ár vonatkozásában (ezt a lépést az ajánlat kibocsátásakor is el kell végezni) 2. Hitelképesség elbírálása 3. Visszaigazolás (szükség szerint)

Ajánlat A rendelésfeldolgozás ajánlat adásával indul, amely egy adásvételi szerződés kötésére vonatkozó egyoldalú nyilatkozat. Tartalmazza a kötendő ügyek minden lényeges elemét: a. megnevezés b. mennyiség c. minőség d. ár e. szállítási határidő f. szállítási mód g. paritás (az ár hol értendő: pl. gyárkapun való kihozatalkor, célállomáshoz érkezve, stb.). h. ajánlattevő kikötéseit: kötelezettség nélkül, időközbeni eladás joga fenntartva, érvényességi idő. Nem célszerű túl sok részletet kiadni, mert az ajánlat publikus a konkurencia felé is. Változtatás nélküli elfogadása esetén létrejön a kétoldalú szerződés. Ez kötelezettségekkel jár, az ajánlatban foglaltakat teljesítenünk kell. A vevő ellenajánlattal is élhet, ekkor meg kell egyezni és szükség esetén új ajánlatot adni.

59 / 136

Vállalati Információs Rendszerek BSc Ajánlat nélkül is érkezhet vevői megrendelés, ami viszont a vevőre nézve egyoldalú szerződés (itt persze semmiféle kötelezettségünk nincs – dönthetünk, hogy teljesíthető-e a rendelés, és ha igen, visszaigazoljuk).

Ellenajánlat Az ajánlat címzettje változtatásokkal fogadja el a kapott ajánlatot. (Másik jelentése: konkurenciától kapott ajánlat.) Szerződés Két-, vagy többoldalú jogügylet, a felek egymás közötti viszonyát meghatározó nyilatkozat. Szóban, vagy írásban köthető (erre utaló magatartással is). A szerződésből bírói úton érvényesíthető jogok és kötelezettségek származnak, amelyek tartalmát a felek szabadon állapítják meg. Jogszabályba ütköző szerződés érvénytelen. Az egyoldalú szerződés is lehet kétoldalú, mert az egyik fél jogosítva, a másik kötelezve van a szerződés tárgyában. A szerződésből folyó kötelezettség megszegése (pl. hibás, vagy késedelmes teljesítés) szerződésszegés. Adásvétel Dolgok, tevékenységek mozgása az eladótól a vevőig pénz ellenérték fejében. Az áru és a pénz mozgása történhet egyidejűleg (készpénz) és eltérő időben (hitelügylet). Jogilag: szerződés, amelynek alapján az eladó köteles az eladott dolog tulajdonjogát a vevőre átruházni és a dolgot meghatározott időben átadni; ugyanakkor a vevő köteles a dolog átvételére és a vételár megfizetésére. Az eladót jogszavatosság terheli azért, hogy harmadik félnek az árun nincsen olyan joga, amely a vevő tulajdonszerzését megakadályozhatja (korlátozhatja). Másfelől kellékszavatosság szerint felelős, hogy az áru rendeltetésszerű használatra alkalmas, megvannak a szerződésben kikötött tulajdonságai. Adásvételi szerződéshez kapcsolódó fogalmak: Kötbér Előre meghatározott pénzösszeg, melyet felróható szerződésszegés esetén kell a szerződésszegőnek fizetnie, függetlenül attól, hogy a szerződésszegésből a másik félnek származott-e ilyen mértékű kára. Alapulhat szerződésen és jogszabályon. A kötbér megfizetése nem zárja ki a kártérítést, ha a kár bizonyíthatóan meghaladja a kötbért. Kártérítés Szerződéssel vállalt kötelezettség megszegésének vagy jogellenes károkozásnak a szankciója. Jogosságát illetve mértékét megállapodással, vagy bírói úton határozzák meg. A kár lehet tényleges, vagy elmaradt haszon. Elmaradt haszon A károsult vagyonának a jogellenes cselekmény következtében elmaradt gyarapodása. Jogcím lehet szerződés szerint és szerződésen kívül. Akadályközlés A szerződő felek kötelezettsége, hogy előre nem látható, elháríthatatlan akadályok esetén tartoznak a másik felet a jogszabályban előírt módon a szerződésben foglaltaknak teljesíthetetlenségéről értesíteni. Ez azonban nem mentesít a kötbérfizetés alól, viszont elmulasztása szerződésszegésnek minősül. 60 / 136


Árjegyzék Az árupropaganda legelterjedtebb eszköze. Tartalmazza az áru leírását, választékát, árát, eladási feltételeit stb. Alapár Adott termelési illetve szolgáltatási feltételek mellett kialakított állandó jellegű árak összefoglaló neve. Árengedmény Az áru előzetesen megállapított, vagy kikötött árából elengedett, vagy visszatérített összeg. Az árengedmény oka lehet rosszabb minőség (defenzív ok), nagyobb mennyiség (offenzív ok), kedvezőbb szállítási illetve fizetési feltételek. Az árengedmény formái: •

Skontó (vagy kasszaskontó) Pénztári engedmény: kedvezőbb fizetési mód alapján (pl. részletfizetés helyett készpénz, vagy fizetési határidő lejárta előtt teljesített fizetés), vagy nagy összegű készpénzes vásárlás esetén.

•

Rabat Árjegyzéki árakból árengedmény az állandó, vagy rendszeres vevőknek. Marketing célokat is szolgálhat. o Mennyiségi rabat A vásárlás nagysága szerint meghatározott százalékos árengedmény. o Káló rabat Száradó, vagy párolgó súlyveszteséggel járó árut is árengedménnyel számolják el. A termelési folyamat során a veszteség összegét a termelési költségek között, a vállalati Általános költségek rovatban számoljuk el normán belüli mérték esetén. o Beremenson rabat Tapadós, ragadós anyagok szállításakor a csomagolóanyaghoz tapadt mennyiségre vonatkozó árengedmény. o Fusti rabat Az áru szennyezettségének árengedmény.

megfelelően

előre

kikötött

nagyságú

Árrés A beszerzési ár (gyártásnál: bekerülési ár) és az eladási ár közötti különbözet, amely fedezi a forgalmi költségeket és a nyereséget. Meghatározása legtöbbször az értékesítés nettó ár százalékában történik, vagy abszolút értékben. Jellemzően cikkekre, vagy cikkcsoportokra megállapított árrést használnak.

61 / 136


4.2. SZÜKSÉGLETSZÁMÍTÁS, ÜTEMEZÉS A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.2. ábra szemlélteti. Ütemezési adatok

Primer szükséglet

Szükségletszámítás és ütemezés Bruttó, nettó szükséglet Anyagjegyzék feloldás Határidőzítés

Cikktörzs

Beszerzési javaslat

Gyártási javaslat

Anyagjegyzék

4.2. ábra Szükségletszámítás és ütemezés eseményei és funkciói

A szükségletszámítás és ütemezés célja:

Készletszintek szabályozása Határidőfigyelés Beszerzési terv elkészítése Termelési terv kialakítása a termelési rendszer kapacitásaira (gyártásnál)

Szükségletszámítás Indító esemény a primer szükséglet (ami késztermékre vonatkozik). Cikk lehet késztermék vagy annak alkatrésze is. Összetett cikk komponenseit az anyagjegyzék (anyagszükségleti jegyzék, receptúra) írja le. Egy összetett cikkhez tartozhat egy műveletterv, ami előírja, hogy hogyan kell alkatrészeiből előállítani. A műveletterv tartalmazhatja a tervek szerint az elvégzéshez szükséges időnormát is. Az anyagjegyzék lehet strukturált. A strukturáltság itt azt jelenti, hogy egy beépülő cikknek is van anyagjegyzéke, ezért a cikk felépülése hierarchikus formában van megadva. A szükségletszámítási algoritmus meghatározza – az anyagjegyzék segítségével – a másodlagos szükségleteket, és a művelettervek (vagy más ún. átfutási idők) segítségével a szükségletek felmerülésének időpontját. A számítást a Net change (nettó változások) elve szerint csak azokra a cikkekre végzi el, amelyek Ütemezési adataiban, vagy gyártási programját érintő tényezőiben változás történt. Ezért a változásokat figyelni kell: meg kell határozni azokat a tevékenységeket, amik hatással lehetnek a tervezett készletszintekre. Gyártott cikkek esetén a figyelemnek ki kell terjednie a gyártási programban szereplő objektumokra (pl. a gyártó gépek adataiban történt változásokra) is. Ezt hívjuk nettó változásoknak (Net Change). Először bruttó, aztán nettó szükségletet számol, figyelembe véve (és a bruttó szükségletből levonva) az adott (jövőbeli) időpontban terv szerint rendelkezésre álló raktárkészletet. Szükségletszámítás eredménye:

62 / 136

Vállalati Információs Rendszerek BSc Gyártási javaslat a gyártott cikkekre (cikk, mennyiség, határidő adatok) Beszerzési javaslat a vásárolt cikkekre (cikk, mennyiség, határidő adatokkal) Miért javaslat? Mert lehetnek adatok, amiket a rendszer nem vesz figyelembe (nem tudja), a beszerzés vezetője pedig igen (kézzel módosítható).

4.2.1. Szükségletszámító rendszerek Egyszerű anyagtervező rendszer Anyagjegyzékekkel, művelettervekkel és gépekkel nem foglalkozik. A kezelők készletszinteket írnak elő cikkenként, és ezek meglétéről gondoskodik. Jellemzően kereskedő vállalkozások alkalmazzák. Cikkenként előírt jelzési szintek meglétét lekérdező programokkal ellenőrzik. Tipikusan használt készletszintek: • Minimális (biztonsági) készletszint: vevőmegtartás biztonsága érdekében fenntartott készlet. • Jelzési készletszint: figyelmeztető üzenet keletkezik, ha a készlet ez alá csökken. • Maximális készletszint: ennél több ne legyen. A lekérdező programok cikkenként megvizsgálják és összehasonlítják a cikk: • valamely előírt készletszintjét és • raktérkészletét. Az eredményről jelentést készítenek. Ez a komparatív lekérdezés. Fejlettebb változata előállíthat Beszerzési javaslatot is.

MRP I (Material Requirement Planning): Anyagszükséglet tervezés Közepesen fejlett rendszer, művelettervekkel, gépi erőforrásokkal nem foglalkozik, csak anyagokkal (cikkekkel, anyagjegyzékekkel) és időkkel: • Cikkek • Anyagjegyzékek • Beszerzési idők Tervezhet: • a futás pillanatában meglévő készletekkel • a jövőbeli tervezett raktárkészlettel (ez már fejlettebb rendszer) • jövőbeli készlettel és a beszerzési idők figyelembe vételével, az időtengelyen visszafelé (ez itt a legfejlettebb rendszer) MRP II (Manufacturing Resource Planning): Gyártási erőforrás tervezés Anyagokkal, művelettervekkel és gépekkel egyaránt foglalkozik. Az időtengelyen visszafelé haladva (a kész termék kért szállítási időpontjától kiindulva) tervez (minimális készlettartási elv). Ez a legfejlettebb módszer. Foglalkozik: • cikkekkel • anyagjegyzék struktúrákkal • művelettervvel • időkkel (beszerzési idő, különféle műveleti idő, pontos módszer az átfedési idővel is) • gépekkel Inputja a vállalati telephelyeken jelentkező primer igények (elfogadott vevői igények, sajátkockázatú rendelések és raktárkészlet igények), mint anyagszükségletek. Outputjai ütemezett, tervezett beszerzési és gyártási rendelések, beszerzési és gyártási rendelések és intézkedési üzenetek (például, ha nem jelent meg a bevét könyvelés, sürgessük meg a dolgot egy kicsit, azaz nézzünk utána).

63 / 136

Vállalati Információs Rendszerek BSc Működése vázlatosan: A bruttó szükségletből nettó szükségletet számít. Ezekre tervezett beszerzési vagy gyártási rendeléseket készít. A tervezett rendelések feladási dátumát a szükséglet felmerülésének időpontjától visszafelé számolja, figyelembe véve a beszerzési és gyártási időket. Az anyagjegyzék alapján meghatározza az alkatrészekre vonatkozó igényeket, és ezekre rekurzívan futtatja az algoritmust. DRP (Distribution Resource Planning): Elosztási erőforrás-tervezés Kettő- vagy többszintű áruelosztási és -ellátási rendszernél alkalmazott tervezési módszer. Például: - fogyasztók kiszolgálása (tranzitraktár, elosztóraktár egy régió közepére), - beszerzés a szállítóktól, - többtelephelyes vállalat, - munkahely és munkahely közt is van ilyen (bár földrajzilag kicsi a távolság, a mozgatóeszköz-igény miatt mégis fontos megemlíteni). A rendszer egységei között függőségi struktúra építhető föl az áruk forrásai és célállomásai alapján. (Például ilyen volt régen az állami kenyéripar is.) Ez a függőségi struktúra analóg az anyagjegyzék-struktúrával. A tervezés célja az egységenként jelentkező anyag- és áruszükséglet szállításokkal való kielégítése, optimális módon. Részletesen a következő fejezetben tárgyaljuk.

4.2.2. MRP I. - MRP II. Szükségletszámítás és ütemezés részletes algoritmusa Kiindulási állapot: 1. A rendszer felépít egy erdő gráfot a cikkek és az anyagjegyzék-struktúrák definiálása alatt. 2. Minden cikkhez hozzárendel egy ún. alacsonyszint kódot, nullától indulva a negatív számok felhasználásával. A legmagasabb szinten levő cikkek így 0, az ezek alatt szereplő cikkek -1 értékű alacsonyszint kódot kapnak, és így tovább lefelé. 3. Ha egy cikk több fában is szerepel, akkor a cikk az előforduló legkisebb kódot kapja. Egy cikk alacsonyszint kódjának módosítása esetén az alatta szereplő cikkeket a rendszer rendre újra besorolja. 4. A rendszer a cikkek iránt felmerülő igények kielégítését a cikkek alacsonyszint kódja által meghatározott sorrendben, ezen belül növekvő határidő szerint tervezi. Elsőként a 0 szinten levőkét, majd a -1 szinten lévőkét é.í.t. Működése: 1. MRP tervezést igénylő, legmagasabb szinten levő cikkekre vonatkozó igények (sajátkockázatú rendelések, vevői primer szükségletek, minimál készletek stb.) rendezése növekvő határidő szerint: • Cikk, termék. Legyen ez cj. • Igényelt mennyiség (szükséglet). Legyen ez Nj. • Határidő: a szükséglet felmerülésének időpontja. Legyen ez t1,j. 2. Nettó szükséglet meghatározása. A növekvő határidő szerinti cj igények összevetése a szükséglet felmerülésének időpontjában rendelkezésre álló raktárkészlettel, nettó szükséglet meghatározása cj-re: • nettó_szükséglet(t1,j) = szükséglet(t1,j) – készlet(t1,j), ha ez> 0, akkor ez az új Nj, és az új készlet(t1,j) = 0, • egyébként az igény készletről kielégíthető, és az új készlet(t1,j) = készlet(t1,j) – szükséglet(t1,j)

64 / 136

Vállalati Információs Rendszerek BSc 3. Minimális készletszint ellenőrzése. További nettó igény keletkezik cj-re abban a legkorábbi t1,j időpontban, amikor a minimális készletszint nincs meg. Ha nincs semmilyen nettó igény cj-re, akkor ugrás a 12. pontra. 4. Nettó szükséglet módosítása: • Kihozatal szerint. • Számítások az idő-tengelyen: A készletpolitikai besorolás és a tervezési adatok szerinti számítások elvégzése az időtengelyen. Ilyenek pédául a nettó igények összevonása (például az egy héten belül jelentkező nettó szükségletek mennyiségeinek összevonása a legkorábbi határidőre), ami új Nj nettó szükségletet és új t1,j-t jelenthet; továbbá az időhatár figyelembe vétele. 5. Nettó szükséglet fedezése: Az összevont (vagy nem összevont) igényeket kielégítő tervezett rendelések mennyiségi adatainak meghatározása a készletpolitikai előírás és az előírt tervezési adatok szerint (minimális rendelési mennyiség, sorozatnagyság, rendelési mennyiség stb.). (A cikktörzs tervezési adatai itt fontos szerepet játszanak.) 6. Határidőzés: A cj cikk t1,j határidejű nettó szükségletét fedező tervezett rendelés feladási határidejének meghatározása: • Vásárolt cikkekre beszerzési javaslat, ennek kiadási időpontja t2,j = t1,j – BRÁI, ahol BRÁI a cikktörzs egy adata, a beszerzési rendelés átfutási ideje. • Gyártott cikkekre gyártási javaslat, ennek kiadási időpontja: - MRP I esetén: t2,j = t1,j – GYÁI, ahol GYÁI a cikktörzs egy adata, a gyártási rendelés átfutási ideje. - MRP II esetén: t2,j = t1,j – átfutási_idő_számítása(szükséges mennyiség és műveletterv, mint paraméter alapján). 7. Bejegyzés t1,j határidőre az igényelt cj termék készlet- vagy forgalom nyilvántartásába. Várható fedezetként, ellátásként jelentkezik. 8. Ha gyártott cj, akkor folytatás a 9. ponton, egyébként ugrás a 12. pontra. 9. A cj alkatrészei, az ezekre vonatkozó mennyiségi igény és a felmerülési időpont meghatározása: • Alkatrész: anyagjegyzékben van definiálva, legyenek ezek Ai -k. • Mennyiségi igény alkatrészenként Li: Li = ni * szülő_cikk_szükséges_mennyisége / (100 – selejt%)/100, ahol ni az i-ik alkatrészből az anyagjegyzék szerint szükséges mennyiség. • Az igény felmerülésének időpontja t1,i = t2,j. __________ Eddig fix gyártási átfutási idővel MRP I (vagy mrp)_______________ 10. Gyártott cikkek kapacitásszükségletének meghatározása: • Az igénybe vett gépek azonosítása műveletterv alapján. Legyenek ezek Gm –k. • Foglalás kezdési és befejezési időpontjának meghatározása t2,j-ből, mint határidőből kiindulva. (Nem minden műveleti idő foglal gépet, tehát a gépfoglalás tényleges kezdeti időpontja későbbi lehet, mint t2,j, és a kapacitás felszabadulásának időpontja korábbi lehet t1,j -nél.) Bejegyzés a kapacitások foglaltság-nyilvántartásába: • Kezdet (dátum). • Vég (dátum). • Időtartam (óra).

65 / 136

Vállalati Információs Rendszerek BSc • Gyártási rendelés, mint foglaló azonosító szám, gyártott cikkel. Ezt minden gépre végig kell csinálni, amelyek az előállított cikk gyártásához kellenek. 11. A szekunder igények rendezése: • Cikkek: cj = Ai, azaz a c tömb bővítése Ai elemekkel, • Mennyiség: Nj = Li, azaz az N tömb alkalmas bővítése Li elemekkel, • Határidő: t1,j = t1,i, azaz a t1 tömb alkalmas bővítése t1,i elemekkel. 12. cj MRP-tervezése kész. Ugrás a 1. pontra, ha van még feldolgozatlan cikk. 13. Szükségletszámítás vége.

Eddig átfutási idő számítással MRP II (vagy MRP): Manufacturing Resource Planning 14. Visszacsatolás a termeléstervezéshez, vezérprogram készítéshez, ha nincs elég szabad kapacitás.

Eddig zárt hurkú MRP

Szükségletszámítás és ütemezés további alkalmazása: A gyártási erőforrásszükséglet-tervezés hatékony eszköz a termelés két területén is: a tervezésben és a végrehajtásban az alábbiak szerint. 1. Tervezés: A termelésprogramozás alatt, valamint az ajánlatok kibocsátása és a vevői rendelések elfogadása előtt a gyártás szimulálható, és az egyes események következményei előzetesen megvizsgálhatók, ezért a részletes tervezés fontos eszköze. Szimulációnak az ismételt szükségletszámítással és ütemezéssel végzett termelési terv összeállítását nevezzük. A szimuláció menete a következő: – A tervezett termelési programra, ajánlatra és vevői rendelésre részletes szükségletszámítás végezhető: = ellenőrizhető az alapanyagok biztosíthatósága, valamint = a vállalat egyes kapacitásainak, főként a szűk gyártási keresztmetszetet jelentő kapacitásoknak a terhelése. Szükség esetén a kapacitásfoglalás belső tervezett időpontjait lehet módosítgatni a kapacitásigények kielégítése céljából, akár kézi úton is. – Ha a szükséges kapacitások nem állnak rendelkezésre, akkor az el nem fogadott vevői megrendeléseket vissza lehet utasítani, vagy a vevői határidő módosítását lehet kezdeményezni. Egyébként pótlólagos kapacitásokat kell biztosítani (pl. külső bedolgozókat). – Az egyedi módosítás befolyásolja a szükséges alapanyagok (legkésőbbi) megrendelési időpontját, ezért a szükségletszámítást és ütemezést ismételten végre kell hajtani. A rendszer ilyenkor a (kézileg) beállított új adatokhoz igazítja a szükséges anyagok beszerzésének ütemezését. Ha lehet olyan határidőket találni, amely esetén a szükséges kapacitások és alapanyagok biztosíthatók, akkor a rendelés teljesíthető, a termelési terv megalapozott lesz. – A szimulációval, a szükségletek gyors és pontos meghatározásával biztosítható a vezetői döntésekhez szükséges információ. 2. Végrehajtás: az igények kielégítésére betervezett rendelések, és a vállalati erőforrások részletes és folyamatos felügyeletét is ellátja. A felügyelet, az ellenőrzés kiterjed az összes aktuális folyamatra: – Az ütemezett beszerzési és gyártási rendelési terv elkészítésére. (Pl. jelzi, hogy egy új vevői megrendelés végrehajtását be kell tervezni.) – A tervezett rendelések jóváhagyásának és végrehajtásának sürgetésére. – A vevői rendelések változását követve, a jóvá nem hagyott rendelések átütemezésére. – A jóvá nem hagyott és szükségtelen rendelések eltörlésére. – Jelentés készítésére a feladott rendelések határidejében történt változásokról, csúszásokról. – A készlethelyzet adatainak aktualizálására. – A kapacitáshelyzet adatainak aktualizálására. 66 / 136

Vállalati Információs Rendszerek BSc Példa az MRP I működésének szemléltetésére. 4.1. táblázat Cikktörzs P/M Rendelési politika Összevonási időszak [nap] Rendelési mennyiség MIN rendelési mennyiség Többszöröz Műveleti idő [nap/db] Szállítási idő [nap] MIN készlet Készlet ma

P1 M FOQ

A1 P POQ

A2 P LFL

60

60

60

10

10

10

10

10

10

5 1

5

5

5

5

Anyagjegyzék: P1 ← A1, beépülési mennyiség: 1

25 50

25 73

Anyagjegyzék: P1 ← A2, beépülési mennyiség: 1

25 27

4.2. táblázat Vevői megrendelések CIKK_ID P1 P1

Mennyiség [db] 15 50

Határidő [nap] 2 50

Kiindulási állapot: A hét minden napján dolgozunk. Az erdő gráf felépítése, és az alacsonyszint kódok hozzárendelése a cikkekhez. 4.3. táblázat Alacsonyszint kódok Kód Szint P1 0 A1 -1 A2 -1

P1

A1

0

A2

-1

Működése: 1. Legmagasabb szinten lévő igények. M1: P1 15 db 2 nap M2: P1 50 db 50 nap 2/P1. Nettó szükséglet meghatározása.

Nettó igények: 38 db 50. napra (50 – 12 = 38 db) 25 db 2. napra (3/P1. Minimális készletszint ellenőrzés.)

4/P1. Nettó szükséglet módosítása.

67 / 136

Vállalati Információs Rendszerek BSc • Kihozatal: 100% • Összevonás: Az FOQ összevonási időszaka (1 nap), de most nincs összevonás, mivel nincs egy napon belül több igény 5/P1. Nettó szükséglet fedezése. A FOQ-ban megadott rendelési mennyiség (10 db) figyelembe vételével • 25 db-os rendelés helyett 3x10 db-os rendelés a 2. napra • 38 db-os rendelés helyett 4x10 db-os rendelés az 50. napra 6/P1. Határidőzés. A műveleti idő figyelembe vételével, de a múltba nem ütemezve, a határidőzés eredménye: • 3x10 db-os rendelés: Kezdés: 1. nap; Kész: 10. nap • 4x10 db-os rendelés: Kezdés: 41. nap; Kész: 50. nap Megjegyzés: A párhuzamosítás miatt kapacitástúlterhelés valószínűsíthető. 7/P1. Bejegyzés a forgalom nyilvántartásba. A bejegyzések alapján meghatározható a készlet valamely időpontban.

8/P1. Anyagjegyzék lebontása. P1

A1

0

A2

-1

9/P1. Alkatrészigények meghatározása. A1 cikkre: L1 10 db-os rendelés 0. napra (hogy az 1. napon megkezdhessük a szülő cikk gyártását) L2 10 db-os rendelés 0. napra L3 10 db-os rendelés 0. napra L4 10 db-os rendelés 40. napra (hogy a 41. napon megkezdhessük a szülő cikk gyártását) L5 10 db-os rendelés 40. napra L6 10 db-os rendelés 40. napra L7 10 db-os rendelés 40. napra A2 cikkre: hasonlóan az A1-re.

68 / 136


A gépfoglalások számítása egyszerű, de azt most nem részletezzük. A még feldolgozatlan cikkekre (A1-re és A2-re) újrafut az MRP. 2/A1. Nettó szükséglet meghatározása.

Nettó igények: 2x10 db 40. napra (4x10 – 20 = 2x10 db) 25 db 0. napra (3/A1. Minimális készletszint ellenőrzés.) 4/A1. Nettó szükséglet módosítása. • Kihozatal: 100% • Összevonás: A POQ összevonási időszaka (60 nap) miatt, 45 db-os rendelés a 0. napra 5/A1. Nettó szükséglet fedezése. A POQ-ban megadott MIN rendelési mennyiség (10 db) és a Többszöröz (5 db) figyelembe vételével • 45 db-os rendelés a 0. napra 6/A1. Határidőzés. A múltba nem ütemezünk. A szállítási idő figyelembe vételével a határidőzés eredménye: • 45 db-os rendelés: Feladás: 1. nap; Megjön: 5. nap 7/A1. Bejegyzés a forgalom nyilvántartásba.

8/A1. Anyagjegyzék lebontása. A1-nek nincs anyagjegyzéke:

69 / 136


P1

A1

0

A2

-1

A még feldolgozatlan cikkre (A2-re) újrafut az MRP. 2/A2. Nettó szükséglet meghatározása.

Nettó igények: 22 db 40. napra (3/A2. Minimális készletszint ellenőrzés.)

4/A2. Nettó szükséglet módosítása. • Kihozatal: 100% • Összevonás: A LFL-nál nincs összevonás, ezért 22 db-os rendelés a 40. napra 5/A2. Nettó szükséglet fedezése. A LFL-ban megadott MIN rendelési mennyiség (10 db) és a Többszöröz (5 db) figyelembe vételével • 22 db-os rendelés helyett 25 db-os rendelés a 40. napra 6/A2. Határidőzés. A szállítási időt figyelembe vételével a határidőzés eredménye: • 25 db-os rendelés: Feladás: 36. nap; Megjön: 40. nap 7/A2. Bejegyzés a forgalom nyilvántartásba.

70 / 136

Vállalati Információs Rendszerek BSc 8/A2. Anyagjegyzék lebontása. P1

A1

0

A2

-1

Nincs további feldolgozatlan cikk, így vége az algoritmusnak.

71 / 136


4.2.3. Elosztási erőforrás tervezés (Distribution Resource Planning, DRP)

Elosztási erőforrás-tervezést (Distribution Resource Planning, DRP) kettő- vagy többszintű anyag- ill. áruelosztási és ellátási rendszereknél alkalmazzuk. A DRP feladata az egyes telephelyek közti szükségletek és ellátások egyensúlyának megteremtése. Ennek érdekében tételszükségleteket közvetít az ellátó telephelyek felé, szállítási terveket hoz létre az igénylő és az ellátó telehelyek között, ütemezi, szervezi és irányítja a szállításokat. Az értékesítési és az elosztási helyeken a vevői rendelések és a vállalat részletes termelési programja alapján előrejelzi és összesíti az egyes cikkek iránt felmerült szükségleteket. Ezután megtervezi a térben egymástól távol elhelyezkedő telephelyek közti anyag- és termékáramlást úgy, hogy a szükséges anyagok és félkész vagy késztermékek a felhasználási helyükön – az előállítási illetve raktározási helyükről átszállítva – a szükséges mennyiségben és időben rendelkezésre álljanak. A DRP szorosan összefügg az MRP-vel, a két rendszer kiegészíti egymást. Míg az MRP egy telephelyen belül, addig a DRP a telephelyek között tervez. A két rendszert megfelelően együtt futtatva, a termelés minden telephelyen az összes többi telephely vagy elosztóközpont igénylését fedezni tudja.

4.2.3.1. A DRP törzsadatai A DRP működése sok hasonlóságot mutat az MRP-hez, több tervezési adatot azzal azonos módon használ, de igényel saját törzsadatállományt is. A DRP a szállítások tervezésekor a globális vállalati naptárt használja, alapértelmezés szerint.

Ellátó telephely: Az a telephely, ahonnan a tétel elszállításra kerül. Ez többnyire (de nem mindig!) a tételt gyártó vagy vásárló telephely, így a tételt itt gyártottként vagy vásároltként kell bejegyezni. Többszintű elosztási rendszer esetén egyes ellátó telephelyek is kaphatják az árut (más ellátó telephelytől), ekkor a továbbosztott árut itt is ellátási tételként kell definiálni. Átvevő telephely: Egy adott tételt fogadó, felhasználó telephely. A tételt itt mindig ellátási tételként kell definiálni. Az ellátási tételek a termékstruktúra bármely szintjén megjelenhetnek. Fuvardíjtáblázatok: fajlagos fuvarköltségek. Szállítási módok: homogén szállítóeszközök definíciója darabbal, mérettel, kapacitással, típussal (pl. közúttal vagy vasúttal); előírható a be- és kirakodási idő. Ellátó csatorna: Lényegében két telephely között működő ellátó csatornák rendszere. Egy ellátó csatornát meghatároz egy ellátó és egy átvevő telephely, valamint a szállításhoz igénybe vehető szállítási mód.. E három attribútum összetett kulcsként funkcionál. Csak egyirányú ellátási kapcsolatot határoz meg, azaz fordított irányhoz új csatornát kell létrehozni. További attribútumai az alapértelmezett menetidő, valamint – amennyiben a cikket több ellátó telephelyről kell beszerezni – a szükségletnek az ellátó telephelyre eső százalékos aránya. Ellátó hálózat: Ha egy ellátási tételt több telephelyről szállítanak, akkor minden kapcsolathoz külön ellátó csatornát kell definiálni, és az ellátásból való részesedésük összegének 100%-nak kell lennie. Az összetartozó csatornákat össze kell fogni közös csokorba egy közös kóddal, az ún. hálózati kóddal, így alakul ki az ellátó hálózat.

72 / 136

Vállalati Információs Rendszerek BSc Szállítási hálózat: Előírható benne, hogy a hét mely napjain történhet ki- és berakodás, ami előírás eltérhet a vállalati naptártól. Az itt előírt munkarendnek lesz nagyobb a prioritása. Továbbá, átdefiniálható egy ellátó csatornához tartozó menetidő, be- és kirakodási idő. Szállításütemezés: A naptárt bírálja felül pontosan megadott dátumokkal. Ezeknek a dátumoknak a prioritása nagyobb lesz még a szállítási hálózatokban meghatározottaknál is. Tétel törzsadatok: A telephelyre érvényes tervezési adatokat kell itt megadni (ellátó hálózat kódja, P/M kód = ellátási tétel, valamint a már MRP-nél megismert tervezési paraméterek). Az úton lévő készlet raktára: A telephelyközi szállítás végrehajtásakor a készlet nem kerül át közvetlenül az ellátó telephelyről az átvevő telephely célraktárába, hanem – mintegy a szállítóeszköz rakterét modellezve – először egy átmeneti raktárba, az ún. úton-lévő-készletraktárba kerül. Ebbe kerül berakodáskor az áru, és innen adható át az átvevő telephely megfelelő raktárába kirakodáskor. Ez az eljárás megfelel annak a gyakorlatnak, hogy a raktárból való kiadás után az áru az átvevő tulajdonába kerül. (Az úton-lévő-készlet-raktár egyébként alapértelmezés szerint az átvevő telephelyen van. Általános esetben külön létrehozható egy ún. úton-lévő-készlettelephely is.) E törzsadatokat és kapcsolataikat a 4.3. ábra szemlélteti.

Fuvardíjtáblázat

Telephely 1), 3)

Szállítási mód

Ellátó telephely

2)

Átvevő telephely

1), 2), 3)

Ellátó csatorna

Szállítási hálózat

Hálózati kód

Tételtörzs

Szállításütemezés

Ellátási arány

4.3. ábra A DRP törzsadatainak áttekintő egyed-kapcsolat ábrája (a kapcsolattípusok nélkül, néhány attribútumot feltüntetve: 1): Berakodási ÁI, 2): Menetidő, 3): Kirakodási ÁI)

Az ábra lényege a következő. A Tételtörzsben hivatkozhatunk egy Hálózati kódra. Egy Hálózati kód Ellátó csatornákat fog össze. Egy Ellátó csatornához tartozik egy Szállítási mód, egy Ellátó telephely és egy Átvevő telephely, valamint tartozhat egy vagy több Szállítási hálózat és Szállításütemezés is. (Amennyiben több tartozik, úgy azokat a dátumok különböztetik meg egymástól, adott napon, adott dátumon csak egy hálózat, illetve egy ütemezés lehet érvényben.) A Szállítási módhoz pedig megadható egy Fuvardíjtáblázat is.

73 / 136


4.2.3.2. A DRP működése vázlatosan Egy telephelyen ellátási tételként kell definiálni azt a cikket, amelyet más telephelyen gyártanak vagy vásárolnak. A gyártó vagy vásárló telephelyet ellátó (vagy átadó) telephelynek, az igénylőt pedig átvevő telephelynek nevezzük. Az ellátási tételek a termékstruktúra bármely szintjén megjelenhetnek. Többszintű elosztási rendszer esetén egyes ellátó telephelyek is más telephelytől kapják az árut, így ezekben is ellátási tételként kell definiálni a továbbosztott árut. Mindegyik ellátási tételhez ellátó hálózatot rendelünk. A DRP meghatározza a felhasználási telephelyen az ellátási tételek nettó szükségletét, és az ennek kielégítésére szolgáló telephelyközi igényléseket. Az igényléseket szétosztja az ellátó hálózatban szereplő átadó telephelyek között a hálózatban definiált arány szerint. Az igényeket összevonja, majd módosítja a cikkek készletpolitikai előírásai alapján, hasonlóan az MRP-hez. A szállításokat a definiált átfutási idők alapján, a szállítási kapacitások figyelembe vételével ütemezi. (Ez utóbbit csak a jobb rendszerek tudják.) A határidők számítását az MRP-hez hasonlóan végzi, azonban tételek anyagjegyzékeinek lebontása helyett az ellátó hálózatok lebontásával és az ellátási arányok figyelembe vételével számol; a művelettervben meghatározott átfutási idő helyett pedig a telephelyközi szállítások átfutási idejét veszi figyelembe. A szállítás megkezdésének időpontját a DRP is az időtengelyen visszafelé történő ütemezéssel határozza meg. Felügyeli a tervezett szállítások lebonyolítását is. A számítás eredményeképp létrejött ütemezett tervezett telephelyközi szállítások minden esetben tartalmazzák az ellátási tételt, az ellátó és átvevő telephelyeket, az igény felmerülésének dátumát, a szállítás megkezdésének és befejezésének tervezett dátumát, valamint a szükséges és az eddig kiszállított vagy bevételezett mennyiségeket, telephelyenként megfelelő nézetben.

4.2.3.3. DRP és MRP együttműködése A DRP szorosan együttműködik az MRP-vel. Az átvevő telephelyen az ellátási tételekre vonatkozó igényt minden esetben az MRP határozza meg, a DRP pedig az igényt elosztva közvetíti az ellátó telephelyek felé. Az MRP és DRP külön-külön is és együttesen, kombináltan is futtatható. Kombinált futtatás esetén a rendszer létrehozza a tervezett telephelyközi szállításokat, valamint a gyártási vagy beszerzési rendeléseket is. Két vagy több telephelyes ellátó hálózat esetén a kombinált számításokat egyszerre kell elvégezni az összes érintett telephelyen, mert ekkor és csak ekkor határozható meg komplex módon az összes telephely igénye és ellátása. A külön futtatásra csak különleges esetben lehet szükség. Az elosztási- és erőforrástervezés a logisztikai rendszerek működtető logikai rendszere. A DRP működésének részleteit a 4.4-4.8. táblázat adatai valamint a 4.4. és 4.5. ábra alapján egy példán követjük végig.

74 / 136

Vállalati Információs Rendszerek BSc 1. Adottak a következő adatok 4.5. táblázat Ellátó hálózat

4.4. táblázat Szállítási mód ID

SZM1 SZM2 SZM3

Berakodási idő 1 1 1

Kirakodási idő 1 1 1

MAX terhelhetőség [db] 200 200 200

Hálózat kód Átvevő telephely Átadó telephely Szállítási mód Kiszolgálási % Menet idő

Járművek száma [db] 2 2 2

HK1 TH1

HK2 TH2

HK21 TH21

TH211 SZM1 100 1

TH21 SZM2 100 1

TH211 SZM3 100 1

4.6. táblázat Cikktörzs P1 Telephely kód P/M Ellátó hálózat kódja Rendelési politika Összevonási időszak Rendelési mennyiség Többszöröz Műveleti idő [nap/db] Szállítási idő [nap] MIN készlet Készlet ma

A1 TH211 P

TH1 D HK1

TH2 D HK2

TH21 D HK21

TH211 M

FOQ

FOQ

POQ

POQ

10

10

10

10

100

300

100

100

100

20

20

20

20 0.1

20

LFL

4.7. táblázat Vevői megrendelések TH_ID TH1 TH2 TH21 TH211

CIKK_I D P1 P1 P1 P1

Mennyiség [db] 50 50 50 50

Határidő [nap] 60 60 60 60

5 0 40

0 40

0 40

0 40

100 120

Anyagjegyzék: P1 ← A1 Beépülési mennyiség: 1

Kérdés: Milyen rendeléseket készít a DRP és az MRP a fenti vevői megrendelések hatására? Válasz: Input: Az egységeknél jelentkező szükséglet : (TH-ra beérkezett vevői rendelések minimálkészletek stb.). TH1 TH2 Működés vázlatosan: - A függőségi struktúrát felépíti, és ebből kiválasztja a forrás és cél állomásokat. - Bruttó szükségletből nettó szükségletet számol az összes egységben (telephelyen). TH211 TH21 - Ütemezést készít a szállításokra a szállítási idő figyelembe vételével. - Felügyeli a tervezett szállítások lebonyolítását. TH2 Output: Ütemezett, tervezett szállítások és intézkedési üzenetek. Részletesen: 1. Tekintsük a feldolgozandó ellátási tételeket, TH1 TH21 legyenek ezek a Pi cikkek. Ha nincs feldolgozandó ellátási tétel, akkor vége. 2. Határozzuk meg egy Pi cikkre vonatkozó TH211 függőségi struktúrát vállalati szinten, rekurzív módon a hivatkozott ellátó hálózati kód alapján. Ez minden esetben egy DAG (körmentes irányított gráf), melynek 4.4. ábra. Példa ellátó hálózatra 75 / 136

Vállalati Információs Rendszerek BSc csomópontjai a telephelyek, élei pedig azon ellátó csatornák, melyeken a Pi cikket be kell szerezni. A fának lehet több gyökere is. 3. Határozzuk meg a telephelyek szintkódját a függőségi struktúrában: • A gyártó vagy vásárló telephelyek kapják a 0 kódot. (Több is lehet.) • Azok a telephelyek, melyek felette vannak (azaz a Pi cikket a 0 szintű telephelytől kapják) az 1 szintkódot kapják, é.í.t. • Ha többféle bejárás is lehetséges, akkor egy telephely az előforduló legmagasabb szintkódot kapja. Tekintsük a legmagasabb szintű telephelyet. 4. Telephelyközi igény meghatározása: Határozzuk meg az aktuális telephelyen növekvő időrendi sorrendben a Pi ellátási tétel bruttó-nettó szükségletét, és végezzük el a szükséges készletpolitikai számításokat az MRP-nél tanultak alapján: az időtengelyen az összevonást és az eltolást ha kell, valamint a mennyiségi korrekciókat. Kihozatallal és selejttel a DRP nem számol. Ha nincs nettó szükséglet, akkor ugrás a 8. pontra. 5. Osszuk szét az így kapott mennyiséget az ellátó hálózatban előírt arányok szerint az ellátó telephelyek felé. 6. Határozzuk meg a Pi-re szóló szükséglet felmerülésének időpontját az egyes ellátó telephelyeken az ellátó csatornák időadatai alapján, az időtengelyen visszafelé haladva. 7. Jegyezzük be az ellátó telephelyeken az igényelt mennyiségeket és időpontokat, ha vannak. 8. Tekintsük az azonos szinten levő következő telephelyet, ha van. Ha nincs, lépjünk lejjebb a függőségi struktúra eggyel alacsonyabb szintjére. Ha nem gyártó vagy beszerző telephelyre léptünk, akkor ugrás a 4. pontra, egyébként lépjünk tovább. 9. Határozzuk meg az MRP algoritmusával a gyártott vagy a vásárolt cikkek gyártási vagy beszerzési rendeléseit a 0-ás telephelyen (telephelyeken). Ugrás az 1. pontra. Az eredményeket a 4.8. táblázatba foglaltuk össze. 4.8. táblázat Eredmények CIKK

Esedékesség [nap]

Bruttó Szüks.

Tervezett készlet

Rend. Menny.

Kibocs. [nap]

TH_ID

Szint

P1 P1 P1

60 60 60 57 60 57 54 10

50 50 50 300 50 100 320 440

40 40

100 300 320

57 57 54

TH1 TH2 TH21

1 2 1

TH211

0

P1

A1

A számítás részleteit a 4.5. ábrán követhetjük végig, lépésről, lépésre.

40

40 120

440 320 100

10 5 5

76 / 136

Legmagasabb szinten levő telephellyel kezdünk.


Készlet [db] Szükséglet(10)

TH1

40

50

Idő [nap]

60 Készlet [db] Szükséglet(10)

TH2

40

50

Idő [nap]

Készlet [db]

300

TH21

40

50

57 Készlet [db]

440

320

Idő [nap]

60 100

TH211 40

50 Idő [nap]

Készlet [db] 320 120

440

A1: 5 nap szállítási idő

100

100

5

Idő [nap]

4.5. ábra A DRP számítás menetének szemléltetése

77 / 136


4.2.4. Logisztika A logisztika az a vállalati tevékenység, amely biztosítja (az üzleti folyamatok zavartalan lebonyolításához azt), hogy a szükséges anyag/áru/termék a megfelelő helyen, a megfelelő időpontban, a szükségletnek megfelelő mennyiségben és a megfelelő minőségben rendelkezésre álljon. Logisztikai rendszer: a készletek, az anyagáramlások valamint a rájuk vonatkozó információk és irányítási struktúrák rendszere. Alkotórészei: Anyagáramoltatás technikai eszközei: • Teherszállító járművek (vasúti, közúti, vízi, légi). • Szállító berendezések (targoncák, daruk, görgős pályák, szállítószalagok stb.). • Rakodógépek (manipulátorok, robotok, átrakó berendezések). • Raktári berendezések (raktári állványok, állvány kiszolgáló gépek, targoncák). • Egységrakomány képző, és bontó gépek, csomagoló gépek. Információ-áramoltató technikai eszközök: • számítógépek és perifériák, • hálózatok, • adatátviteli rendszerek, GPS, • szenzorok, • kódrendszerek (a kettőt együtt alkalmazza a vonalkód olvasó). A logisztikai rendszer az anyagáramoltatás speciális nézőpontjából integrálja a vállalati tevékenységet (pl. bankban: készpénzlogisztika).

Logisztikai folyamat szakaszai: Beszerzés: szükséges inputok tényleges technológiai lebonyolítása. Termelésellátás: termelési folyamaton belüli anyagellátás biztosítása. Értékesítés: vevői igények tényleges technológiai lebonyolítása (a kész áru kiszállítása, eljuttatása a végfelhasználókhoz). Egy logisztikai rendszer fejlesztésének célja elsősorban az anyagáramlás hatékonyságának fokozása és az anyagkövetés korszerűsítése. Az anyagáramlás hatékonyságának a fokozása csökkenti az anyagáramoltatás költségeit, lerövidíti az átfutási időket, fokozottan óvja a szállított elemek minőségét, megelőzi az elkeveredést. Az anyagkövetés korszerűsítése révén pontosabb adatok nyerhetők a szállítás alatt vagy a gyártásban lévő anyagok helyzetéről, állapotáról közel valós időben. Az anyagáramoltatás és az anyagkövetés között szoros kölcsönhatás van: Megfelelő színvonalú anyagkövetés nélkül gyors anyagáramoltatás nem valósítható meg, illetve igényes anyagkövetést csak megfelelően kialakított anyagáramlás esetén célszerű létrehozni. A logisztikai folyamat bármely szakasza két fő tevékenységből áll: raktározás és szállítás.

Raktározás: Logisztikai megközelítésben a raktározás néhány speciális szemponttal egészül ki: Célja az elvárt ellátási, kiszolgálási színvonal biztosítása: A szállítási távolságok csökkentésével a reagáló képesség növekedése a keresletváltozásra, és szállítási költségek csökkenése. 78 / 136

Vállalati Információs Rendszerek BSc A rendeléseknek megfelelő termékek összegyűjtése, elosztása, szortírozása. A kereslet-kínálat közötti ütemkülönbség áthidalása (klasszikus készletgazdálkodás). Raktározási technológia: A raktárak működését meghatározó rendszer elemei: • Áruválaszték (sokféle áru több gondot okoz). • Tárolási jellemzők és módok (pl. tárolási hőmérséklet). • Készletszintek (nagyobb készletszintek mozgatása nehezebb). • Forgalom (több szállítmány kezelése nehezebb). • Információ-áramoltató rendszer (pl. bevásárlóközpontban a kasszánál lévő vonalkód-olvasó készlet-nyilvántartási feladatok ellátásának is fontos eleme). • Anyagáramoltatási rendszer (pl. palackozás, cimkézés). • Munkafolyamatok (milyen feladatok adódnak a raktárban, mi az ott dolgozók feladata és hogyan kell végezniük). • Eszközszükséglet. • Munkaerő-szükséglet. • Külső kapcsolatrendszer (pl. EDI – Electronic Data Interchange – kapcsolat SCMSupply Chain Management-tel). Komissiózás: a megrendelés szerinti áru/anyagválaszték összeállítása. Elemei: • Keresés (az áru megtalálása a raktárban). • Azonosítás (ellenőrzés: amit megtaláltam valóban az, amit a vevő kért?). • Kiszedés (megfelelő eszközzel, pl. targonca). • Ellenőrzés (újbóli ellenőrzés a kiadási ponton: azonosítás és mennyiség, az anyagáramlás és információáramlás szinkronizálása). A raktár ellátási funkciójának kritikus eleme a komissiózás. A tevékenység hibalehetősége nagy a dolgozók erős szellemi és fizikai igénybevétele miatt. Alkalmas helyen létrehozott raktárakkal növelhető a reagáló képesség a keresletváltozásra, mert a szállítási távolságok csökkenthetők. Áthidalható a kereslet-kínálat közötti ütemkülönbség is (ami a klasszikus készletgazdálkodás fő célja). Csökkenthetők a szállítási költségek is a nagytételű szállítások és a rendező-elosztó raktárak működtetésével. A raktározásnál használatos legfontosabb teljesítménymérők a következők: •

Átfutási idővel kapcsolatos mutatók (árubetárolás időigénye, kiszállításra való előkészítés időigénye stb.).

•

Rendelésteljesítés pontosságával kapcsolatos mutatók (határidők betartása, kiadáskori hiány és felcserélés mértéke stb.).

•

Erőforrásokkal kapcsolatos mutatók (pl. a térkihasználás, a raktár általános teljesítménymutatói, a személyzet teljesítménye és hatékonysága, az anyagmozgató berendezések hasznosítási foka és termelékenysége).

Szállítás A szállítási tevékenység megteremti a kapcsolatot az ellátási lánc két földrajzi pontja között, és teljesíti a logisztika követelményrendszeréből a „megfelelő hely”-re követelményt. A szállításnak is gazdaságosnak kell lennie, mert a szállítási költségek gyakran a logisztikai költségek jelentős részét okozzák. A szállításnál használatos teljesítménymutatók: • Teljesítési idővel kapcsolatos mutatók (szállítási átfutási idő, ezen belül a be/kirakodási idő, menetidő hossza).

79 / 136

Vállalati Információs Rendszerek BSc • •

Minőséggel kapcsolatos mutatók (szállítási minőség, árukárok és sérülések mértéke, szállítási megbízhatóság). Erőforrásokkal kapcsolatos mutatók (járművek kapacitás-kihasználása, járművek hasznosítási aránya, járművek termelékenysége).

80 / 136


4.3. BESZERZÉS A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.6. ábra szemlélteti.

Beszerzési javaslat született

Szállítói hálózat Anyagok, vagy cikkek és a lehetséges szállítók

Szállítók és a beszerzési javaslatok összerendelése

Korábbi szállítások

Beszerzési megrendelés elkészült

Szállítók

4.6. ábra Beszerzés eseményei és funkciói A beszerzés célja a szükségletek kielégítése megfelelő mennyiségben, megfelelő időben, megfelelő minőségben, megfelelő áron, (megfelelő szállítótól). Beszerzési javaslat születhet komparatív lekérdezés szükségletszámítás és ütemezés, közvetlen bevitel útján. Ez utóbbi cikktörzsben nem szereplő cikkre is vonatkozhat. Emiatt jól be kell paraméterezni.

Korábbi szállítások A szállítók eddigi szállítási adatait tartalmazza (csúszás, minőség). Az adatokat folyamatosan karban kell tartani (naprakészség)! Szállítói hálózat A szállítók ajánlatai alapján állítjuk elő, és az adatokat folyamatosan karbantartjuk. Részei: Szállítók törzsadatállománya Cikkek (tételek, anyagok) törzsadatállománya Szállítói ajánlatok, vagy szerződések cikkekre ár és szállítási idő megadásával (de tartalmaz egyéb feltételeket is) A Szállítók törzs kiépítése történhet piackutatással és beszállítói hálózat felépítésével.

81 / 136


4.3.1. Szállítói hálózat felépítése A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.7. ábra szemlélteti. Szállítói ajánlat rögzítése Potenciális Ajánlatkérés a Érvényes árak szállítók és szállítási potenciális felkutatása szállítótól feltételek Keretszerződés megkötése, rögzítése 4.7. ábra Szállítói hálózat felépítése Legfontosabb adatai: Szállító Cikk Minimális rendelési mennyiség, kiszerelés és kiszerelési mennyiség Ár Szállítási/beszerzési idő: A megrendeléstől a raktárba kerülésig szükséges munkanapok száma (időtartam jellegű szám). Egyszerűbb rendszerek nem tartalmazzák, vagy nem kezelik az időt. Ekkor a szakemberek által becsült várható szükségleti trend alapján meghatározott jelzési szinttel, vagy minimálkészlettel kezelhető a probléma, lásd Szükségletszámítás és ütemezés. Ezeket piackutatással, ajánlatkéréssel, belső nyilvántartások vezetésével és a külső piaci helyzet kevésbé strukturált adatainak begyűjtésével és rendezésével kell létrehozni. További feladat az engedmények kezelése, legtöbbször a mennyiségi rabat kezelése, esetleg összevont megrendelések teljes összegének vizsgálata (pl. 1 millió Ft rendelés felett mindenre 5% engedményt kap). Erre általánosan működő program még nincs. A szállítói hálózat felépítése után létre kell hozni a korábbi szállítások adattárát. Az adattár lehet osztott is. Ebben a vásárolt cikkekre vonatkozó lebonyolított beszerzésekkel kapcsolatosan történeti adatokat, és a szállítókra vonatkozó más információkat tárolunk. A létrehozott adatokat folyamatosan frissíteni kell, hogy a szükséges időpontban minden rendelkezésre álljon. Ezek alapján meg kell határozni cikkenként a szállítók prioritását. A prioritás meghatározásának inputja a korábbi beszállítások és a beszállítói hálózat adattára. Módszere az input adatokra támaszkodó döntéssorozat. Outputja a szállítók rangsorolása. A rangsorban legelöl álló szállító lesz az alapértelmezett szállító. Egyes rendszerek esetében a cikktörzsben rögzíthető az alapértelmezett szállító, a szállítási idő, az ár, és egyéb a szállításra vonatkozó adat. Az ilyen rendszerek beszerzési javaslatai az alapértelmezett szállítók szerinti bontásban automatikusan is megjelennek, melyeket jóváhagyás előtt, vezetői döntéssel, módosítani lehet. Megjegyezzük, hogy más rendszerekben több szállító is hozzárendelhető egy cikkhez meghatározott rangsorban, a fenti adatsorral együtt. A szállítói ajánlatokat (szállító, ár, szállítási határidő cikkenként) rögzíthetők: Szállítókhoz kötve A szállítók által szállított cikkek adatai egy táblában (árlista) hozzájuk van kötve. Ekkor többnyire nem készül javaslat a szállításra (pl.: QAD EA). Feladási időpont sem születik meg, mert a szállítási idők szállító specifikusak.

82 / 136

Vállalati Információs Rendszerek BSc ☺ Karbantartás egyszerű (pl. áremelésnél) Plusz lista kell a konkurenciával történő összehasonlításhoz Cikkekhez kötve Cikktörzsben megadva minden potenciális szállítót, annak árát, szállítási időszükségletét. Ekkor a beszerzési javaslat többnyire tartalmaz javaslatot szállítóra, feladási időpontra. ☺ Konkurencia könnyen összehasonlítható. Az adatok karbantartása nehezebb, vagy plusz funkciót/listát igényel. Egy árlistában minden cikkre szóló ajánlatot minden szállítótól ☺ Egyszerűbb az adatbázis megtervezése. A fenti funkcionális előnyt elveszítjük.

Szállítók és a beszerzési javaslatok összerendelése A szükséglet minden cikkre vonatkozóan mennyiségi és határidő adatot jelent. A szükségletszámítás és határidőzés által előállított Beszerzési javaslat tartalmazza. A korábbi szállítások és a szállítói hálózat adatai alapján össze kell rendelni a javaslatban szereplő cikkeket és a szállítókat (mit kitől rendelünk meg) azokban a rendszerekben, amelyek nem támogatják az alapértelmezett szállító és a cikkek összerendelését.

Jóváhagyás: A beszerzendő cikkek és a szállítók összerendelése optimalizáció után, legjobb szállító, szállítási feltétel, optimális rendelési mennyiség kiválasztásával. (Tényleges jóváhagyásra akkor van csak szükség, ha a rendszer automatikusan meghatározza a legjobb szállítót, és a beszerzési javaslatot annak címezve készíti el.) A jóváhagyást gyakran külön jogosultsághoz kötik. A jogok szólhatnak telephelyre, cikkrecikkcsoportra, összeghatárra, ameddig a rendelést jóváhagyhatják, a beszerzési rendelés nélkül érkező számla elfogadására. Az eredmény: beszerzési megrendelés a szállítók felé. Várható reláció a rendelés visszaigazolása, és később megérkezik az áru egy szállítólevél kíséretében, majd a számla is.

4.3.2. Fogalomtár Beszerzési ár Az áru vételárát és a beszerzés összes költségtényezőjét arányosan tartalmazó ár. A figyelembe vehető költségtényezők a következők: Vám Környezetvédelmi díj Szállítási költség A beszerzési ár az elő- és utókalkulációban figyelembe vehető anyagköltség alapja termelő vállalkozásnál. Kereskedelmi vállalatoknál az eladott áru beszerzési értéke (ELÁBÉ). Keretszerződés A szállítási-, vagy hitelszerződés olyan változata, mely meghatározott, rendszerint nagyobb volumenű, részletekben teljesítendő és hosszabb időre szóló (legalább negyedév) munkák, illetve ügyletek folyamatos lebonyolítására szolgál. Szólhat időtartamra, valamely körülírt munkára és ügyletre (pl. építkezés). A szállítási keretszerződésben megállapodnak árról is. Két megadott időpont között kell teljesíteni, amelyen belül később határozzák meg a pontos szállítási dátumokat és mennyiségeket.

83 / 136


4.4. ÁRU BEÉRKEZTETÉSE ÉS MINŐSÉGI ÁTVÉTELE A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.9. ábra szemlélteti.

Felszabadítás jelentés

Rendelésállomány

Szállítólevél

Minőségvizsgálat Árubeérkeztetés megtörtént jelentés

Min. vizsgálati előírások

Árubeérkeztetés bevételezés az idegenáru raktárba

JIT áru jelentés

Raktárkészlet

Áruátkönyvelés / Anyag rendelkezésre szállítás a szabad állás jelentés készletek közé

4.9. ábra Áru beérkeztetésének és minőségi átvételének eseményei és funkciói

4.4.1. Árubeérkeztetés Szállítólevél indítja a műveletet. Az árubeérkeztetésnek az alapja a kibocsátott megrendelés. Az árubeérkeztetés feladatai: A szállítás jogosságának ellenőrzése: megrendeltük-e azt a cikket és mennyiséget, arra a határidőre, attól a szállítótól, olyan minőségben? Mennyiségi átvétel (ha a fentiek mindegyike OK) A tényleges és a nyilvántartási mennyiségnek egyeznie kell (raktáros felelőssége).

Bevételezés az idegenáru raktárba, bevét könyvelése Bizonytalan minőség esetén az áru az idegenáru raktárba kerül, jelzéssel ellátva (sárga → zöld/piros). Árubeérkeztetés megtörtént jelentés generálódik. Garantált minőség esetén JIT (Just In Time, azonnal) áru jelentés születik, ami automatikus átkönyvelést indít a szabad/felhasználható készletek közé, és Anyag rendelkezésre állás jelentés generálódik. (Színek jelentése: sárga – még nincs megvizsgálva, zöld - megfelelt, piros – nem felelt meg)

Minőségvizsgálat Árubeérkeztetés megtörtént jelentés indítja a Minőségvizsgálat eljárást. A minőségvizsgálatot előírt eljárásrend szerint kell elvégezni. Eredménye a műbizonylat és döntés a megfelelésről. Megfelelés esetén Felszabadítás jelentés születik. Nem megfelelés esetén az árut zárolni kell, és a tényállást a szállítóval tisztázni kell.

4.4.2. Áruátkönyvelés/szállítás a szabad készletek közé Felszabadítás jelentés indítja az áru átkönyvelését a szabad/felhasználható készletek közé. Az átkönyvelés eredménye a raktárkészletek változása, és (ismét) Anyag rendelkezésre állás jelentés születik.

84 / 136

Vállalati Információs Rendszerek BSc A szállítólevél elkönyvelése készletkönyveléssel jár. A könyvelés mennyiségi könyvelést jelent. Az Anyag rendelkezésre állás jelentés a gyártásban, vagy a készáru terjesztésében indít újabb folyamatokat.

4.4.3. Fogalomtár Minőségi bizonyítvány Az áru minőségét igazoló mindenfajta okirat. Minőségellenőrző intézet, vagy -osztály igazolása az áru minőségének ellenőrzéséről. Műbizonylat A vállalat saját minőségi bizonyítványa. Garancia Feltétlen felelősség az áru hibamentességéért az ún. garanciális időn belül. Jótállás Majdnem feltétlen felelősség, mert megállapodáshoz kötött. Ebben határozzák meg az időtartamot, ami rendszerint hosszabb a szavatosság időtartamánál, és a törvényi kötelezettségeknél többletfelelősséget vállalnak – kötnek ki. Szavatosság Az eladó törvényi felelőssége az eladott áru jogi és fizikai hiányosságaiért saját gyártás esetén. Termékfelelősség A szállító felel a nem általa gyártott termék hibájáért is. Szállítólevél / fuvarlevél A szállított áru feletti rendelkezési jogot megtestesítő/igazoló okmány/bizonylat. Szállítmányozás Áruk eljuttatásának megszervezése más földrajzi helyre, harmadik fél megbízásával (vagyis nincs saját szállítóeszköze). Fuvarozás Saját eszközzel történő áruszállítás szárazon, vízen és levegőben.

85 / 136


4.5. SZÁMLAFOGADÁS A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.10. ábra szemlélteti.

Fizetési feltételek

Szállítói számla

Számlaellenőrzés Rajta szereplő tételek ellenőrzése Számla zárolása, vagy feladása könyvelésre

Rendelés

Nyitott feladás

Számla könyvelése

Fizetési rendelés

Árubeérkezés

4.10. ábra Számlafogadás eseményei és funkciói

4.5.1. Számlaellenőrzés A beérkező szállítói számla jogosságának, helyességének megállapítása, a számla rögzítése, feladása és könyvelése. A beérkező számlákat (a vállalat belső rendjének előírása alapján) két csoportra lehet osztani: - Kereskedelmi számlákra, melyek a kereskedelmi rendszeren keresztül kerülnek a pénzügyi rendszerbe (pl. áru számlák, tárgyi eszközök számlája, fuvarszámlák). - Pénzügyi számlákra, melyek NEM a kereskedelmi rendszeren keresztül kerülnek pénzügyi könyvelésre (pl. előírhatja egy cég, hogy a gáz, víz, villany, illeték számlák, fizetések bizonylatai csak így kerüljenek rögzítésre.) A számla ellenőrzése történhet: Rendelés alapján, ha nincs készletkönyvelés (rezsi számla) A megfelelő árubeérkeztetés könyvelése és a kikötött fizetési feltételek ellenőrzésével A számla minden tételére vagy pozíciójára vonatkozóan Megvizsgáljuk, hogy nekünk szól-e, kitől jött, jogos-e, fizetési feltételek megfelelnek-e a szerződésben/megrendelésben foglaltaknak, határidő rendben van-e stb. Az összehasonlítás alapja a Rendelés és az Árubeérkeztetés adatai. Ha az összehasonlítás egyenlege nulla, vagy egy előre meghatározott tűréshatáron belül van, akkor a számlát rögzítjük (másolatot készítünk - iktatás). Különben a számlát zárolni kell, és a tényállást a szállítóval tisztázni kell. Ha minden rendben, akkor a számlát könyvelésre fel kell adni, el kell könyvelni és kifizetésre meg kell nyitni. Az átadást adatbázis szinten átadótábla használatával szokták megoldani.

86 / 136


Nyitott feladás A számlaellenőrzés lezárása a számla jóváhagyásával történik, így a számla (tartalmilag) teljesített, de kifizetetlen (nyitott) számla lesz. A Nyitott feladás esemény átmenet a kereskedelmi és a pénzügyi rész között. A feladás után a számlát a pénzügyi modul átveszi, és automatikusan elkönyveli.

4.5.2. Számla könyvelése A számla könyvelése a feladással (kereskedelmi oldal) és az átvétellel (pénzügyi oldal) indul. Folyószámla könyvelés, vagy pénzügyi könyvelés lépései: 1. Ellenőrzés Van-e a szállítónak folyószámlája? Ha nincs, akkor létre kell hozni, pl.: 4 Források 45 Rövid lejáratú hitelek, kölcsönök 4541 Belföldi szállítók 4541 002233 Remény Kft. szállítói folyószámla Ez a szám a rendszerben sztringként tárolódik. 2. A számla bruttó összegének könyvelése a szállító folyószámláján a Követel oldalra 3. A számla nettó összegének könyvelése 2 Eszközök 261 Készletek beszerzési áron (raktár), Tartozik 4. Áfa könyvelések 4 46 466 4661 46612

Források Adó jellegű kötelezettségek Előzetesen felszámított forgalmi adó Belföldi beszerzések előzetesen felszámított forgalmi adója Előzetesen felszámított ÁFA (25%), Tartozik

Bankszámla T

3841

K

Bruttó szállítói számla összege

Szállító (Remény Kft.) T 45410002233 K Bruttó összeg

Bruttó összeg

Készletek beszerzési áron T

261

K

Nettó összeg

Előzetesen felszámított ÁFA 25% T K 46612

87 / 136

Vállalati Információs Rendszerek BSc A kontírozás: bruttó értéket a Szállítói főkönyvi számla Követel oldalára, a nettó értéket a Raktári számla Tartozik oldalára, míg az ÁFA értékét az Előzetesen felszámított forgalmi adó számla ugyancsak Tartozik oldalára könyveljük el, ÉS KÉZZEL ráírjuk ezeket a főkönyvi számlaszámokat a kapott számlára. A számla a pénzügyi könyvelés szabályaival könyvelődik el, és megindítja a Kifizetés folyamatát.

4.5.3. Fogalomtár Számla Az áru szállításakor, vagy szolgáltatás teljesítésekor a teljesítésről szóló elszámolást és az érte fizetendő összeget tartalmazó kereskedelmi okirat (bizonylat), amely szerint történik meg az ellenérték kifizetése.

Főkönyvi gyűjtőszámla Olyan számla, amelyre könyvelés nem végezhető, csak a kimutatásokban használható fel. Forgalma megegyezik a számozás szerint „alatta” lévő számlák forgalmával, egyenlege pedig ezeknek a számláknak az összevont egyenlege.

88 / 136


4.6. SZÁMLA KIFIZETÉSE

Kifizetés

A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.11. ábra szemlélteti.

Fizetési rendelés

Szállítói számla kifizetése Szállítói számla ellenőrzése Fizetőképesség ellenőrzése Banki adatok ellenőrzése Számla kifizetése

Kifizetés jelentés

Kifizetés könyvelés és számlaleszámítolás Jelentés ellenőrzése és könyvelése Nyitott feladások összerendelése

Pénzeszközök Szállítók

Bankok Szállítói számlák 4.11. ábra Számla kifizetésének eseményei és funkciói

4.6.1. Kifizetés A szállítói számla kifizetése előtti lépések:

Szállítói számla ellenőrzése • Nincs-e kifizetve: rendezetlen tételek között van, és átutalási megbízást még nem adtunk ki. • Van-e tartozása: vásárolhatott is tőlünk. Ha van tartozása, akkor egyenleget kell képezni, és a különbséget fizetjük vagy követeljük meg. Fizetőképesség ellenőrzése A kifizetés (jövőbeli) időpontjában a cég pénzügyi helyzetének ellenőrzése, elemzése (cash-flow management típusú tevékenységek). A Pénzeszközök számlák (38) valamelyikéről ki kell fizetnünk: • Készpénzfizetés esetén a Házipénztárból (381) – szigorú számadású bizonylat, nem lehet visszadatálni, • Átutalás esetén az Elszámolási betétszámláról (3841 - MNB bankszámla). Banki adatok ellenőrzése • Szállítói számla helyes-e? (A bank neve másodlagos, csak tájékoztató jellegű, mert a bankszámla száma egyértelmű azonosító – 2 x 8 vagy 3 x 8 karakter).

89 / 136


Elszámolási betétszámlákhoz rendelt bankszámlaszám kiválasztása, amelyről fizetni akarunk. A kiválasztás vezetői döntést igényel.

Számla kifizetése Döntés a számla összegének kifizetéséről, az időpontról és az összegről a kedvezmények mérlegelésével. A funkció eredménye a Kifizetés és a Kifizetés jelentés megérkezése. Fizetési módozatok: Fizetési kötelezettség teljesítésének formája (partnerspecifikus). Típusai: •

Készpénzfizetés Kifizetés: a házipénztárból elviszi a pénzt. Kifizetés jelentés: egy pénztárkiadási bizonylat születik, amit a szállító aláírt, elismerve, hogy a pénzt átvette. Mindkettő azonnal megtörténik. Ide tartozik a postai utánvétes kiegyenlítés is, amely készpénzes, az áru kézhezvételekor azonnali készpénzes fizetés. •

Átutalással A bankoknak szóló utasítást papíron vagy elektronikusan küldhetjük el. o Papír használatakor a rendszerben rögzíteni kell a bizonylat adatait (átutalási megbízás száma, összeg, dátum, kedvezményezett bankja és számla száma). A közlemény rovatba a kifizetett számla számát fel kell tüntetnünk. o Elektronikus átutalásnál a rendszerből elő kell állítani a banki terminál által megkövetelt formában az átutalási megbízás fájlt. (Ma ez bankonként, és forint-deviza vonatkozásban is különbözik.) A fájl tartalmát a VIR-ből exportálni kell. o A fájl tartalmát importálja a banki terminálprogram, kapcsolatfelvétel és autentikálás után elküldi a megbízást.

Megbízás teljesítése A bank a megbízást a társbankokkal együttműködve háromféle rendszer egyikében teljesíti: GIRO (zsiró) Egy központi bankba (a zsiróbankba) küldik az átutalási megbízásokat, és az összeget a bankszámlánkról kivezeti. A zsiróbank a bankok közötti átutalások között egyenleget képez, és a különbséget írja jóvá vagy terheli meg a bankok nála vezetett bankszámláján. A szállító bankja és a mi bankunk értesít az ügyletről, a teljesítésről. VIBER (Valós Idejű Bruttó Elszámolási Rendszer) A jóváírás-terhelés a vevő-szállító bankszámláján azonnal (max. 1-2 perc alatt) megtörténik. Nagyon költséges, ritkán élnek vele. Értesítés elektronikusan azonnal, papíron pedig naponta postázva történik. SWIFT (Society for Worldwide International bank and Financial Telecommunication) Devizás átutalás külföldi bankoknak speciális titkosított, nagy biztonságú protokoll segítségével. A végrehajtás-értesítés ugyanúgy történik, mint a GIRO-nál.

90 / 136


4.6.2. Kifizetés könyvelése és számlaleszámítolás Jelentés ellenőrzése és könyvelése A Kifizetés jelentés esemény bekövetkeztének feltétele mindhárom esetben a bankkivonat papíron történő megérkezése, vagy a házipénztár kifizetési bizonylat elkészülte. A bankkivonat több ügyletet is tartalmazhat. Azonosító száma van, ami a bankkal, évvel, ügyféllel együtt egyértelműen azonosítja a bizonylatot. Az értesítés elektronikusan is elérhető, de a bank papíron is postázza. Elektronikus másolatról nem lehet könyvelni, csak papírról! A kivonaton szereplő adatokat a nyilvántartással össze kell vetni (keltezés, egyenleg, összeg) és egyezés esetén el kell könyvelni. A Kifizetés könyvelés a szállító esetében a bankszámla megterhelését (Követel) és a szállító folyószámlájának Tartozik oldalára történő könyvelését jelenti. A korábban említett példa szerint a 3841-es bankszámla Követel oldalára, illetve a szállítói (főkönyvi) folyószámlájának Tartozik oldalán könyveljük el a kifizetést.

Nyitott feladások összerendelése A szállítói számlákat a banki kivonaton igazolt kifizetésekkel össze kell rendelni. A teljes kiegyenlítés lezárja a beszerzés teljes folyamatát.

4.6.3. Fogalomtár Bankszámla A pénzeszközök elhelyezésére, pénzforgalom lebonyolítására szolgáló banki nyilvántartás. Könyvvitelben: a bankokkal szemben fennálló követelések, illetve tartozások nyilvántartására szolgáló főkönyvi számla. Bankkivonat A bank által a számlatulajdonos nála vezetett számláit érintő változásokról készített hiteles könyvelési bizonylat. Értesítés a bank által vezetet számlán lebonyolított forgalomról, illetve a számla egyenlegéről. Bankköltség A bankműveletek és a banki ügyletek lebonyolításáért számított jutalék és költség összege. Jóváírás Valamely összeget a számla javára könyvelni, pl. az átutalás vagy kifizetés megtörténtének elismeréséül. Zsiró (GIRO) Fizetés pénz nélkül, átírásos teljesítés. Készpénzforgalmat kikapcsoló fizetési mód, a bankok közötti kölcsönös átutalással való elszámolás. Zsiróbank Olyan bank, amely az átírásra (zsirálásra) szakosodott.

91 / 136


Egyéb fizetési módozatok: Beszedési megbízás (inkasszó) A szállító (jogosultja) bízza meg a vevő bankját, hogy a követelését jóváírja, amit a bank az adós hozzájárulásával tesz meg. Elszámolási utalvány ≈ csekk A kibocsátó megbízza a bankot, hogy az utalványon szereplő összeget írja a kedvezményezett javára. Fizetési meghagyás Fizetési kényszer, melyet az adós jóváhagyása nélkül is teljesít a bank. Megfelelő eljárásokhoz van kötve (pl.: bírósági végzés). Akkreditív A vevő megbízásából a bank ígéri meg a fizetést. A bank itt tulajdonképpen kölcsönadja az üzleti jó hírnevét térítés ellenében.

92 / 136


4.7. KISZÁLLÍTÁS ÉS SZÁMLÁZÁS A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.12. ábra szemlélteti.

Raktár

Vevői rendelés Anyag rendelkezésre állás jelentés

Szállítólevél elkészítése

Szállítólevél másolata

Szállítás Kiszállítás Kiszállítás könyvelése

Kiszállítás könyvelés jelentés

Számla elkészítése

Számla másolata

Számla

Szállítólevél 4.12. ábra Kiszállítás és számlázás eseményei és funkciói

4.7.1. Szállítólevél elkészítése A Vevői rendelés és az Anyag rendelkezésre állás jelentés indítja. Lényege: vezetői döntés a megrendelés teljesítéséről. Kritikus döntés, ha az összes rendelési igény nagyobb, mint a rendelkezésre álló anyag mennyisége. Részszállítás lehetséges: ilyenkor nem indítunk el egyszerre mindent. Ezt az adatbázisban is rögzíteni kell. Szállítólevelet a megrendelés alapján készítünk az adatok átmásolásával. Az átmásolt adatok módosíthatók (pl. részszállítás esetén), kiegészíthetők (előzetes megegyezés alapján) a lezárás pillanatáig. A teljesítés időpontja kritikus, leggyakrabban nem szabad módosítani! Szigorú számadású bizonylat, felelősséget vállalunk! Elkészülte után jóvá kell hagyni, ami lezárja a szállítólevelet (nem lehet módosítani), foglalja az árut (legalább foglalja, hogy ne lehessen másnak eladni, esetenként a készletet is kikönyveli), archiválja a megrendelést (részben vagy egészen), és ki kell nyomtatni. A szállítólevél kíséri az árut a vevőhöz, és ott bevételezést indít. A szállítólevél másolata indítja a Szállítást.

93 / 136


4.7.2. Szállítás Kettős feladata van: 1. Kiszállítás Az áru útnak indítása. Feladata az áru összeszedése a készáruraktárakban alkalmas módon, és kitárolása. Ez a komissiózás. Tényezők: Raktározási technológia Hol találjuk az árut, hogyan szedjük ki és vigyük ki az átadótérbe, és hogyan adjuk át. Fuvarszervezés Megrendeléseken szereplő szállítási címek látogatási sorrendje, ha több szállítási címre kell szállítani (egy, vagy több megrendelés alapján). (Pl.: cikkcsoportos, fordított szállítási cím szerinti sorrend.) Szállítás és az átvétel jellemzői Hogyan szállíthatók, rakhatók fel és le az áruk (súly- és térfogatkorlát stb.). Térfogatkorlátos pl. a Hungarocell. 2. Kiszállítás könyvelése Az árukiadás után a foglalt készleteket ki kell könyvelni, azaz csökkenteni kell a készletet a kiszállított mennyiséggel. A folyamat eredménye a szállítás lezárása, a Kiszállítás könyvelés jelentés elkészítése. (Egyes rendszerekben automatikusan végbemegy a bizonylat lezárásakor a könyvelés. Ekkor az aktív állapotú szállítólevél már foglalja az árut, a lezárás, a kész állapotba való átmenet pedig kikönyveli.)

4.7.3. Számla elkészítése A kiszállított árut leszámlázzuk (feltételezzük a szállítás és áruátvétel terv szerinti végrehajtását). A számla a szállítólevél alapján, az azon lévő adatok átmásolásával készül. Tárolni kell a szerkesztés alatti számlát is. Elkészülte után jóvá kell hagyni, ami lezárja a számlát, archiválja a szállítólevelet, és feladja a könyvelésnek. A számla könyvelését a szállítólevél könyvelése megelőzheti, ha a rendszer úgy van konfigurálva, paraméterezve, de nem mindig készül szállíólevél. A kész számlát ki kell nyomtatni (bizonylat), két példányban. Az eredeti számla a vevőhöz megy, a másolat a könyvvitelünk bizonylata. A feladott számla (a másodpéldány), a folyamat eredménye indítja a pénzügyi könyvelést.

4.7.4. Fogalomtár Komissiózás A megrendelés szerinti áruválaszték összeállítása a tárolási egységekből (egy, vagy több raktárból és egy, vagy több tárolóhelységből) és kitárolása. Részfeladatai: keresés, azonosítás, kiszedés, ellenőrzés. A raktár ellátási funkciójának ez a legkritikusabb tevékenysége, mert a dolgozók erős szellemi és fizikai igénybevétele miatt nagy a hibalehetőség. Negatív raktárkészlet Előbb állítjuk ki a szállítólevelet, mint ahogy áru kerül a raktárba. Ezt a megoldást, ha lehet, kerülni kell.

94 / 136


4.8. A SZÁMLA KÖNYVELÉSE ÉS KIEGYENLÍTÉSE A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.13. ábra szemlélteti.

Számla (adós) könyvelése

Nyitott feladás

Fizetésbeérkezés

Számla másolata

Fizetés beérkezés könyvelése és számlaleszámítolás Nyitott feladások összerendelése Engedményvizsgálat Határidővizsgálat

4.13. ábra Fizetésbeérkeztetés eseményei és funkciói Nyitott feladás: el kell könyvelni a számlát, ami ez után a kiegyenlítésre vár.

4.8.1. Számla könyvelése A könyvelés a Vevő folyószámlájára (adós könyvelés), az Árbevétel és az ÁFA számlára történik az alábbi példa szerint.

T

Árbevétel 911

K

Számla

Követelés belföldi áruszállításból (Gipsz Kft.) T K 311001 Számla

Bankszámla T K 3841 Számla bruttó

Számla bruttó

Fizetendő ÁFA 25% T K 46712

A könyvelési tételt és állapotát azonosítani kell tudni, utólag is. Ezért az analitikában is nyilvántartjuk: a számla számát (vevőét), keltét, teljesítési és fizetési dátumát, hivatkozását (pl. szállítólevél száma), összegét, kiegyenlített vagy kiegyenlítetlen állapotát és a kiegyenlített összeget (+/-), főkönyvi ellenszámláját, időbélyegét.

95 / 136


Folyamat definiálása és azonosítása Kézi könyvelés esetén a folyamatot fejből tudták. A különböző folyamatok követéséhez különkülön egy-egy számlálót vezettek. Ezeket a folyamatokat és a hozzájuk tartozó számlálót nevezik naplónak. Egy naplóhoz alapértelmezett könyvelési számla is tartozhat. Az aktuális folyamatnak megfelelő számlálóból levették a következő számot, és a megfelelő főkönyvi bejegyzések mellé megjegyzésként beírták. Ezzel segítették a visszakeresést, a hibakeresést. Gépi könyvelés esetén a napló kiválasztása folyamatválasztást jelent, ezután a rendszer már tudja, hogyan kell könyvelni. Ezzel együtt – az eredeti céloknak megfelelően – azonosítható lesz a könyvelés folyamata. Ez az alábbiak szerint történik: Folyamat jellege: könyvelési napló (pl. VB = belföldi vevő) A napló leírja a könyvelés menetét, az aktuálisan használandó főkönyvi számlákat, vagy azok kiválasztási algoritmusát, valamint esetenként a könyvelési oldalt. Példa algoritmus (VB): 1. A tételen van vevő, vedd az azonosítóját! 2. Keresd meg a folyószámláját! Ha nincs, hozasd létre, vagy engedélyezés után hozd létre! 3. A Vevői számla végösszegét írd a Tartozik oldalra a többi adattal, mint attribútummal együtt (folyamat azonosítók, tétel- és állapotazonosítók)! 4. Nézd meg a vevő adózási besorolását! a. Ha nem ÁFA-köteles, ne könyvelj ÁFA-t! b. Ha ÁFA-köteles, keresd ki a Vevői számlán lévő ÁFA összesítő kulcsaihoz rendelt áfa számlákat, és írd be az összegeket rendre a Követel oldalra! (érdemes a 0%-t is bejegyezni) 5. Írd be a nettó összeget az Árbevétel számla Követel oldalára! ÁFA szempontjából figyelembe veendő adatok: a vevő székhelye, és szállítási címe.

Folyamat időbeli hovatartozása: hónap vagy év Ezt minden naplóra külön-külön nyitjuk meg és vezetjük, tehát folyamaton belül igaz. Folyamat sorszáma: szám (vagy sztring) Azonosítja, hogy a naplón belül adott hónapban vagy évben hányadikként futott le a folyamat és került könyvelésre az adott tétel. Tipikus folyamatok: Belföldi vevőszámla (VB) könyvelése Alapértelmezett ellenszámla: árbevétel (911) + áfa szla Külföldi vevőszámla (VK) könyvelése Alapértelmezett ellenszámla: export értékesítés árbevétele (941) Belföldi szállítói számla (SB) könyvelése Alapértelmezett ellenszámla: elábé (814), vagy raktár (2611), vagy technikai szla (2619) Külföldi szállítói számla (SK) könyvelése Alapértelmezett ellenszámla: elábé (814), nincs áfa Banki kivonatok könyvelése (BA) Házipénztár könyvelése (HP) Vegyes könyvelés (VE): minden más, ami nem a fentiek közé tartozik Ezeket külön-külön alkalmas módon kell megírni.

96 / 136


4.8.2. Fizetés beérkezés könyvelése és számlaleszámítolás A fizetés tipikusan készpénzben, vagy átutalással történik (esetleg másként). A könyvelés ennek megfelelően a Házipénztárba (3811), vagy Bankszámlára (3841) történik, Tartozik oldalra. Számlaleszámítolás (kipontozás, kiegyenlítés): a beérkezés könyvelése után a Vevői számlán lévő nyitott tételt ki kell egyenlíteni. Több számla kipontozása: ha több vevői számla egyösszegű kifizetése történik meg, akkor technikai számlát lehet nyitni, és azon lehet bontani a beérkezett összeget.

Követelés belföldi áruszállításból (Gipsz Kft.) T K 311001

Házipénztár T K 3811 Számla1

Házipénztár technikai számla T

3818

Számla1 Számla1

Számla1

Számla1

Számla2

Árbevétel, ÁFA

Számla2 Számla2

K

Számla2

Számla2

A kiegyenlítés lépései: A fizetés beérkezés után össze kell vetni a kikötött fizetési határidőt, fizetési feltételeket és az összegeket az egyik oldalon, valamint a kapott összegeket és az érkezés időpontját a másikon. Ha az egyenleg nem nulla, akkor az eltéréseket kezelni kell. Példák az eltérések kezelésére : Engedmény alapján kevesebbet fizet: a különbséget a Vevőnek utólag adott engedmények főkönyvi számlára való könyveléssel kell kiegyenlíteni. Többet fizet határidő túllépése miatt: a többletet máshova (pl. Egyéb bevételek alá) kell könyvelni. Határidőn túl névleges összeget fizetett: késedelmi kamatot lehet reklamálni, ha ki volt kötve. A reklamáció nem a rendszer feladata! Esetenként a tényállást tisztázni kell. (A többletutalást vissza kell utalni.)

4.8.3. Bizonylatok életciklusa A fizetés beérkezés könyvelése újabb rendezetlen tételt, vagy nyitott tételt generál. A vevői számla és a fizetés beérkezés egymáshoz rendelése mindkettőt archiválja (pontos egyezés esetén). Ezzel lezárul a vevői rendelés teljesítésének teljes folyamata. (Hozzápontozott összeg látható a kereskedelmi modulból is.)

97 / 136


4.9. ELŐLEG- ÉS RÉSZLETFIZETÉS A funkciót, a bemeneti és a kimeneti eseményeket, valamint a segédinputokat a 4.14. ábra szemlélteti.

Előlegfizetési követelmény

Előleg- Előlegfizetés fizetés jelentés

Végszámla könyvelése és előlegfizetés átkönyvelése

Kifizetés elküldése

Szállítói számlázás

Rendelés a szállító felé

Előleg-és részletfizetési követelmény megállapítása, kezelése

Vevői számlázás

Fizetésbeérkezés

Vevői rendelés

4.14. ábra Előlegfizetés eseményei és funkciói

4.9.1. Előleg-és részletfizetési követelmény Előleg- és részletfizetési követelmény szállítói és vevői oldalon egyaránt felmerülhet. Előlegfizetés történik, ha a pénzmozgás megelőzi a gazdasági eseményt. Előlegfizetést kötnek ki, követelnek meg, ha a vevő hitelképessége nem elég nagy. Előlegfizetés kikötésének eredménye az előlegfizetési követelmény megállapítása, amit az előlegbekérő okmány jelez (szállító küldi a vevőnek). A szállító tétlen marad az előleg beérkezéséig.

Részletfizetés történik, ha a gazdasági esemény után, több kisebb részletben fizetik meg az ellenértéket. Részletfizetési engedményt adhatnak, ha a vevő hitelképessége nagy. Részletfizetési engedményt a Számlavizsgálatban és a Számlázásban kezeljük. Ellenőrző vizsgálathoz nyilvántartást kell vezetni. Hitelezéssel is kombinálható.

98 / 136


4.9.2. Előlegfizetés A folyamat vevői és szállítói oldalon egyaránt értelmezett. Az előlegek szerződés szerinti átutalását követően a gazdasági esemény végbemegy. Funkcióit a 4.15. ábrán mutatjuk be. Vevő felé

Szállítótól Előlegbekérő fogadása (okirat, de nem könyvelési bizonylat)

Előlegfizetés beérkezése és könyvelése Előlegszámla kiállítása (könyvelési bizonylat) Előlegszámla könyvelése

Szükség esetén ismétlés

Szükség esetén ismétlés

Előlegbekérő kiállítása (okirat, de nem könyvelési bizonylat)

Előlegfizetés és könyvelése Előlegszámla fogadása (könyvelési bizonylat) Előlegszámla könyvelése

Eredmény: Előlegfizetés jelentés (indítja a Szállítást és a Végelszámolást)

4.15. ábra Előlegbekérés és -fogadás folyamata Az előlegbekérőre a vevő fél úgy fizet, hogy közben az eladó fél még nem teljesített semmit. Valójában tehát nincs igazi gazdasági esemény, éppen ezért nem lehet az alapján kitölteni az előlegszámla „teljesítés időpontja” mezőjét. A pénzmozgás időpontja viszont ismert, ezért azt kell ide írni.

4.9.3. Vevői végszámla elkészítése és könyvelése Kiszállítás könyvelése vagy Nyitott feladás (szállítói szla ellenőrzése után) és Előlegfizetés események indítják. Amennyiben a teljesítés megtörtént, kiállítjuk a végszámlát, mely az áru teljes áráról szól. A vevőnek a végszámla kiegyenlítése érdekében azonban csak a fennmaradó részt kell kifizetnie, hiszen a teljes összeg egy részét már előlegként befizette. Ehhez össze kell gyűjteni az előlegeket és meg kell határozni, hogy azokból melyeket kell aktuálisan elszámolni, vagyis melyek tartoznak az adott számlához. A végszámla ezeket az előlegszámlákat minden esetben hatástalanná teszi, lényegében „stornózza”. Informatikai rendszer szempontjából követelmény végszámla készítésekor a rendezetlen előlegszámlákat felajánlani. A kezelő ezekből választhatja ki a rendezendőket.

99 / 136


Vevői számla könyvelése előleg-és végszámla kiállítása esetén: Mi vagyunk a szállítók, a vevőnek kiállítunk egy számlát, amit az elvisz, tehát kimenő számlát kell könyvelnünk. A folyamatot a kiszállítás elkönyvelve és előlegfizetés megtörtént események indítják. A folyamat a következő öt főkönyvi számlát érinti: Bankszámla (pl. 3841), Követelés belföldi áruszállításból (Gipsz Kft.) (pl. 311001), Vevői előlegek (pl. 453), Árbevétel (pl. 911) és Fizetendő ÁFA 20% (pl. 46712). A könyvelési folyamatot az ábrán követhetjük.

Követelés belföldi áruszállításból (Gipsz Kft.) T K 311001

Vevői előlegek T K 453 Előleg számla

Előleg számla

2 T

Árbevétel 911

K

Előleg számla

Előleg pénz

Végszla

Előleg számla

Bankszámla T K 3841 Előleg pénz

1

3 Végszla

Fizetendő ÁFA 20% T

46712

K

4 1

Előleg fizetés beérkezése vevőtől (bankkivonatból könyvelve)

2

Előlegszámla könyvelése

3

Végszámla, teljes nettó és maradék áfa könyvelése

4

Előlegszámla visszakönyvelése

A megfizetett előleg beérkezésekor az előlegpénzt a Bankszámla (3841) főkönyvi számla tartozik oldalára és a Követelés belföldi áruszállításból (311001), a vevő folyószámlájának követel oldalára kell könyvelni. A pénz beérkezése után kiállítjuk és a vevőnek elküldjük az előlegszámlát és mi is könyveljük azt: a Követelés belföldi áruszállítótól (311001) folyószámla tartozik oldalára a bruttó értéket, a Fizetendő ÁFA 20% (46712) főkönyvi számla követel oldalára az áfát, és a Vevői előlegek (453) számla ugyancsak a követel oldalára az előlegszámla nettó értékét. A kibocsátott végszámla fizetendő értéke az előlegek levonása utáni maradék összeg. Könyvelni viszont „bruttó” módon kell, azaz egyrészt a végszámla teljes összegét (nettó+áfa) kell a Követelés belföldi áruszállításból (311001) folyószámla tartozik oldalára könyvelni, másrészt pedig a teljes nettó értékét az Árbevétel (911) követel oldalára, valamint a még meg nem fizetett áfa (vigyázat, nem a teljes áfa!) értékét a Fizetendő ÁFA 20% (46712) követel oldalára kell könyvelni. A következő lépés az előlegszámla „visszakönyvelése”, ami egy „csonka stornózás”: be kell írni az előlegszámla nettó adatait egyrészt a Vevői előlegek (453) tartozik oldalára, másrészt a Követelés belföldi áruszállításból (311001) számla követel oldalára. A folyamat a kiegyenlítések (hozzárendelések) rendezésével zárul (legalábbis a befizetés beérkezéséig): egyrészt a Vevői előlegek (453) számlán a visszakönyvelt tétellel kiegyenlítjük az eredeti könyvelést, másrészt a Követelés belföldi áruszállításból (311001) folyószámlán a visszakönyvelt (nettó) előlegszámlát a tartozik oldalon levő (bruttó) előlegszámlához kötjük, az előlegpénzt pedig a végszámlához is(!). (Az utóbbi két hozzárendelést az ábra nem mutatja.) Az előlegszámlát

100 / 136

Vállalati Információs Rendszerek BSc tehát két tétel egyenlíti ki: a visszakönyvelt előlegszámla és az előlegpénz egy része. A könyvelés eredményeként fizetési rendelés keletkezik, ami kiegyenlítésre (vevői befizetés érkezésére) vár. Végszámla stornózásnál az előleg számlákat is vissza kell könyvelni az eredeti állapotukra vagyis a végszámla előtti állapotot kell visszaállítani.

4.9.4. Szállítói végszámla fogadása és könyvelése Megtörténik a beérkező szállító számla ellenőrzése. Ennek kimenete (eseménye), együtt az előírt előlegfizetés eredményével (eseményével) indítja a végszámla könyvelését, azaz: Nyitott feladás és Előlegfizetés jelentés eseményekre történik meg a számla könyvelése. Ez is két lépésből áll, mint a vevői végszámla könyvelése, azzal teljesen szimmetrikus: 1. Végszámla könyvelése 2. Előlegfizetések átkönyvelése Most mi vagyunk a vevők, kaptunk egy számlát a szállítónktól, tehát bejövő számlát kell könyvelnünk. A beérkező végszámla könyvelési folyamatát a nyitott feladás beérkezett és előlegfizetés jelentés beérkezett események indítják. A folyamat a következő öt főkönyvi számlát érinti: Bankszámla (3841), Szállító (Remény Kft.) (45410002233), Szállítói előlegek (353), Ráfordítások, ELÁBÉ (811) és Előzetesen felszámított ÁFA 20% (46612). Az egyszerűség kedvéért legyünk viszonteladók, és nem tárgyaljuk a Készlet és Költségszámlákat, hanem közvetlenül a Ráfordítások számlára könyvelünk. Az előleg kifizetésekor megtörténik az előlegpénz elkönyvelése a Bankszámla (3841) főkönyvi számla követel oldalára és a Szállítói (45410002233) folyószámla tartozik oldalára. Ezután beérkezik az előlegszámla, amit le kell könyvelni. Ezt egyrészt a Szállító (45410002233) főkönyvi számla követel oldalára kell könyvelni, ami így az előlegpénzzel áll szemben. Másrészt, az előlegszámla áfa részét az Előzetesen felszámított ÁFA 20% (46612) főkönyvi számla tartozik oldalára, továbbá a nettó részét a Szállítói előlegek (353) tartozik oldalára kell könyvelni. A végszámla beérkezése után azt ellenőrizni majd könyvelni kell. A könyvelést most is „bruttó” módon kell elvégezni. Egyrészt a Szállító (45410002233) folyószámla követel oldalára a végszámla teljes összegét (nettó+áfa), másrészt a teljes nettó értékét pedig a Ráfordítások, ELÁBÉ (811) tartozik oldalára, valamint a még el nem könyvelt áfá-t (vigyázat, nem a teljes áfá-t!) az Előzetesen felszámított ÁFA 20% (46612) tartozik oldalára kell könyvelni. (A folyamatot az alábbi ábra szemlélteti.) A következő lépés az előlegszámla „visszakönyvelése”: a végszámla szerint is kifizetett előleg nettó értékét egyrészt a Szállítói előlegek (353) követel oldalára, másrészt a Szállítói (45410002233) folyószámla tartozik oldalára kell könyvelni. A folyamat a kiegyenlítések (kipontozások) rendezésével zárul (legalábbis a maradék kifizetéséig): egyrészt a Szállítói előlegek (353) számlán a visszakönyvelt tétellel kiegyenlítjük az eredeti könyvelést, másrészt a Szállítói (45410002233) folyószámlán a visszakönyvelt (nettó) előlegszámlát a követel oldalon levő (bruttó) előlegszámlához rendeljük, az előlegpénzt (a maradék részt) pedig a végszámlához is hozzákötjük. (Az utóbbi két hozzárendelést az ábra nem mutatja.)

101 / 136


Szállító (Remény Kft.)

Bankszámla T K 3841

Szállítói előlegek T K 353

T 45410002233 K

Előleg pénz

1

Előleg pénz

Előleg számla

Előleg számla

Végszla

Előleg számla

Előleg számla

2 Ráfordítások, ELÁBÉ 3

T

811

K

4 Végszla

1

Előleg bekérőre utalt (bankkivonatból könyvelve)

2

Előlegszámla könyvelése

3

Végszámla, teljes nettó és maradék áfa könyvelése

4

Előlegszámla visszakönyvelése

pénz,

Előzetesen felszámított ÁFA 20% T K 46612

A Végszámla könyvelés és az Előlegszámla átkönyvelés, valamint a kipontozások eredményei: Vevői fizetési kötelezettség, ha a végszámlán az egyenleg nem nulla. Kiegyenlített (kipontozott) számlák, ha ∑Előleg = Végszámla összege (vagyis 0 az egyenleg). Ha az egyenleg nem zérus, akkor vevői oldalon nyitott feladás keletkezik, szállítói oldalon fizetési rendelés keletkezik. Mindkettő kiegyenlítésre vár.

Végszámla stornózásnál az előleg számlákat is vissza kell könyvelni az eredeti állapotukra vagyis a végszámla előtti állapotot kell visszaállítani. A végszámla elkészítése előtt az előlegszámlák és az előlegbefizetések egymást egyenlítették ki, pontozták ki. Amikor a végszámlát elkészítjük, és az előlegszámlák nettó értékét a szállító artozik oldalára írjuk („stornózzuk”), akkor az előlegbefizetések kipontozó párját szüntetjük meg voltaképpen. Éppen ezért a végszámla „magához ragadja” az előlegbefizetéseket, és ő fogja azokat kipontozni.

102 / 136


4.9.4. Bizonylatok életciklusa Az előlegbekérő váltja ki az előlegfizetést, az előlegfizetés archiválja az előlegbekérőt. Az előlegfizetés hatására készül el az előlegszámla, majd később ez beépül a végszámlába. A végszámla elkönyvelése archiválja a megrendelést, továbbá az átkönyveléssel archiválódik az előlegszámla. A végszámla kiváltja a maradék megfizetését, aminek megtörténte archiválja a végszámlát. Ha az előleg megfizetése után nincs maradék, akkor a végszámlát már a megfizetett előleg archiválja. A bizonylatok életciklusát a 4.16. ábra szemlélteti.

archiválja Előlegbekérő

kiegyenlíti, de nem archiválja Előlegfizetés

(archiválja) archiválja Megrendelés

Előlegszámla

archiválja (átkönyvelés)

Végszámla

Maradék megfizetése archiválja

4.16. ábra Előlegkezeléshez kapcsolódó bizonylatok élettörténete (Érdemes áttekinteni az eddig tanult összes bizonylatot és azok archiválási menetét!)

4.9.5. Fogalomtár Előleg Jövőbeli teljesítésért kifizetett illetve felvett összeg. Típusai: Áruelőleg: a megvásárolt, de át nem vett áru vételárára felvett összeg Gyártási előleg: nagy befektetést igénylő anyagára, költségére stb. felvett összeg Adóelőleg: adózónak előre fizetett összege, később megállapítandó adója előzetes törlesztésére. Fizetési előleg: bér terhére folyósított kölcsön. Előlegszámla Áruátvétel előtti fizetés igazolás céljára kiállított számla Részletfizetés Az adásvétel olyan fajtája, melyben a vevő az árut azonnal birtokba veszi, de a vételárat csak később, meghatározott időpontokban, részletekben egyenlíti ki.

103 / 136


4.10. BEFEKTETETT ESZKÖZÖK KEZELÉSE A befektetett eszközök olyan eszközök, melyeket a vállalat várhatóan egy évnél hosszabb időtartamon át használ illetve birtokol. Két fő csoportja van: tárgyi eszközök és pénzeszközök (utóbbiakkal itt nem foglalkozunk.)

4.10.1. A befektetett alosztályai

eszközök

osztályai

és

fontosabb

Befektetett eszközök (1) Immateriális javak (11) Szellemi termékek (112) Vagyoni értékű jogok (113) Ingatlanok (12) Telkek (121) Épületek (122) Ingatlanok értékhelyesbítése (127) Ingatlanok értékcsökkenése (129) Telek értékcsökkenése (1291) Épületek értékcsökkenése (1292)

Műszaki berendezések, gépek, járművek (13) (Ide csak az írható ami kell a termeléshez. Pl autó ide kerül egy taxis vállalkozás esetében, de nem ide ha csak az igazgató autójáról van szó egy sima cégnél.) Járművek a termelésben (131) Gépek, berendezések a termelésben (132) Kisértékű berendezések (133) (kevesebb mint 50e Ft) Műszaki berendezések értékhelyesbítése (137) Műszaki berendezések értékcsökkenése (139) Járművek értékcsökkenése (1391) Gépek, berendezések értékcsökkenése (1392) Kisértékű berendezések értékcsökkenése (1393)

Egyéb berendezések, járművek (14) (Ide kerül az igazgató autója, meg a titkárnő számítógépe.) Egyéb járművek (141) Egyéb műszaki berendezések (142) Kisértékű egyéb berendezések (143) Egyéb berendezések értékehelyesbítése (147) Egyéb brendezések értékcsökkenése (149) Egyéb járművek értékcsökkenése (1491) Egyéb berendezések értékcsökkenése (1492) Kisértékű egyéb berendezések értékcsökkenése (1493)

Állatok (15) Tenyészállatok (151) Állatok értékcsökkenése (159) Tenyészállatok értékcsökkenése (1591)

Beruházások (16) Egyszeri beruházások (161) Folyamatos beruházások (162) Kisértékű beruházások (1621) (kevesebb mint 50e Ft)

Értékpapírok (17) Kölcsönök (18) Hosszú lejáratú befektetések (19)

104 / 136


4.10.2. A tárgyi eszközök információs folyamatai A funkciót, a bemeneti és a kimeneti eseményeket a 4.17. ábra szemlélteti.

Tárgyi eszköz igény

Beszerzés - igény elbírálása - vásárlás - saját fejlesztés

Tárgyi eszköz beszerzése

Tárgyi eszköz főkönyvi életciklusa

Eszköz kivezetés - jogcím meghatározása (értékesítés, selejt, aport) - nettó érték meghatározása - főkönyvi kivezetés

Kivezetés esedékes

Nyilvántartásba vétel - bekerülési érték meghatározása - eszközosztály meghatározása - értékcsökkenési adatok meghatározása - leltárkörzet meghatározása - költséghely meghatározása - tárgyi eszköz nyilvántartásba vétele

Eszköz felvéve a nyilvántartásba megtörtént

Eszközkezelés, módosítás - üzembehelyezés (ÜZBE) - értékcsökkenés elszámolás - tartozékok kezelése - egyéb módosítások

Eszköz főkönyvből kivezetve nyilvántartá Törlés - döntés - törlés

Eszköz törölve

4.17. ábra Tárgyi eszközök kezelésének eseményei és funkciói

Beszerzés Igény elbírálása: jogos-e a tárgyi eszköz igény, van-e rá fedezet, beszerzési forrás meghatározása (Vásárolunk vagy legyártjuk? Ha vásorolunk, kitől?), jóváhagyás Vásárlás: Vásárlás esetén az eljárás hasonló a (termeléshez szükséges) anyagok beszerzéséhez, de mégsem ugyanaz! Ezért elkülönítetten kell végrehajtani, mert nem áru (raktárkészlet), hanem tárgyi eszköz lesz belőle. Nincs tehát szükség készletkönyvelésre, helyette tárgyi eszköz nyilvántartást kell vezetni. Pénzügyi szemszögből pedig nincs készletérték könyvelés sem, a szállítói számlát más főkönyvi számlára: a beruházásokba kell könyvelni. Itt kezdi pályafutását a tárgyi eszköz a beszerzése után, innen fogjuk majd a felhasználási módjának megfelelően átkönyvelni más főkönyvi számlára. 105 / 136

Vállalati Információs Rendszerek BSc A beruházásokon belül megkülönböztetjük az egyedi beruházásokat és a folyamatos beruházásokat.

Egyedi beruházás: egy lépésben minden beszerezhető, például veszünk egy hűtőt Folyamatos beruházás: több lépésben, hosszabb ideig tart a beruházás (pl. építkezés) és több szállítói számla kapcsolódik az eszközhöz. Saját fejlesztés (saját magunk legyártjuk a tárgyi eszközt amire szükségünk van) esetén a költségeket elkülönítetten gyűjtjük, hogy a ráfordítás később meghatározható legyen

Nyilvántartásba vétel Bekerülési érték meghatározása: az ár, a szállítási költségek és a tárgyi eszközzel kapcsolatos összes ráfordítás kiválogatása, összegyűjtése. Ezt ÁFA nélkül végezzük, vagyis a bekerülési érték egy áfa nélküli érték, mégis a tárgyi eszköz bruttó értékének nevezzük, mivel nettó érték alatt az értékcsökkenés utáni, kisebb értékét fogjuk érteni. A bruttó, nettó megnevezés itt tehát nem az adótartalomra, hanem az értékcsökkenésre utal. Eszközosztály meghatározása: Meg kell határozni a főkönyvi besorolást, azaz melyik főkönyvi számlára kell kerüljön az eszköz, hova kell átkönyvelni a beruházásokból. Ez az eszköz jellege és használati célja alapján együttesen történik. (Lásd pl. autó esete a taxisnál és a cégvezetőnél.) Értékcsökkenés: Az értékcsökkenési elszámolás lényege, hogy egy befektetett eszköz értéke folyamatosan átalakul, „átmegy” a termelési folyamat outputjába, ezt szeretnénk mi elszámolni a költségek között. Jó példa erre az asztalosnál a félmilliós gyalugép: 1000 bútordarab legyártása után használhatatlanná válik, értéke ekkor legyen százezer forint, hiszen van még benne néhány értékes alkatrész, esetleg el lehet adni a méhtelepnek. Az értékcsökkenés elszámolás során pl. 10 bútordarab legyártása után 9000 forintot elszámolhatunk költségként, a hiszen a gépünk most ennyivel ér kevesebbet, vagyis ez nálunk költségként felmerült. Ez a folyamat implicite meghatározza az eszköz mindenkori értékét. Értékcsökkenési adatok meghatározása: Egyrészt a leírási kulcs (százalékban kifejezett) értékének meghatározását jelenti a számviteli és a társasági törvény alapján. Másrészt meg kell határozni a maradványértéket, vagyis hogy mennyit ér az eszköz az értékcsökkenési leírás végének pillanatában. Az értékcsökkenés számítás alapja a bruttó érték mínusz a maradványérték, vagyis az az összeg, amennyit az eszköz veszít az értékéből az egész értékcsökkenési eljárás ideje alatt. Leltárkörzet: ki felel az eszközért Költséghely: ahol a költségek felmerülnek, a felmerülés időpontjában nem tudjuk, hogy hova számoljuk el, mit milyen arányban terheljünk vele. Nyilvántartásba vétel: Leltári azonosítószámot kell rendelni az eszközhöz, és a megnevezésének meghatározása után a fentebb említett adatokkal (écs adatok, osztály, leltárkörzet, beszerzési költségek) együtt ezek egy rekordként tárolódnak az adatbázisban. Az összes ilyen rekord együtt adja a tárgyi eszköz nyilvántartást.

Eszközkezelés, módosítás Az eszközt az értékcsökkenés megkezdéséhez üzembe kell helyezni, más szóval aktiválni kell. Üzembe helyezés: bizonylattal igazolni kell a dátumot, amikor az eszköz rendeltetésszerű használatát megkezdték. Ez az időpont az értékcsökkenés számítás kezdődátuma is egyben. Könyvviteli megnevezése az üzembe helyezésnek: aktiválás. A tárgyi eszköz költségadatai a beruházások főkönyvi számláról az eszköz eszközszámlájára kerülnek át. (Tehát arra a főkönyvi számlára, ahova az eszközt osztálya alapján be kell sorolni.)

106 / 136

Vállalati Információs Rendszerek BSc Példa: Szállítói számla

Folyamatos beruházás

cpu

cpu

ram

ram

hdd

hdd

S Z G É P

Egyéb berendezések S Z G É P

Értékcsökkenés elszámolás Lásd feljebb is. Lehet terv szerinti és terven felüli. Terv szerinti: az üzembe helyezés dátumától vagy az utolsó értékcsökkenés napjától induló és egy adott napig tartó (ami nem lehet jövőbeli) időszakra vonatkozó értékcsökkenés meghatározása az eszköz törzslapja szerinti százalékérték alapján, és ennek (kettős) könyvelése az eszköz értékcsökkenési számlájára és az értékcsökkenési leírás (57) számlaosztály megfelelő alszámlájára. (költségnem számla). Arról van tehát szó, hogy felteszem az alábbi kérdést: „mennyit vesztett értékéből a rendeltetésszerű használat során az eszköz az utolsó elszámolás dátuma óta?” és ezt az összeget elszámolom költségként. Terven felüli értékcsökkenés elszámolása az adótörvények szerint megengedett esetekben lehetséges. Tartozékok kezelése Célunk: A tárgyi eszközhöz üzembe helyezés előtt vagy után hozzárendelt kiegészítők könyvelése, illetve kiegészítő leválasztása eszközről. A tárgyi eszköz bruttó értéke változik, ha egy tartozékkal bővítjük. Az értékcsökkenési elszámolást „a háttérben” külön kell vezetni az eszközről és a tartozékokról, azért hogy az esetleges leválasztás megoldható legyen. Példa: autó és benne az akkumulátor. Egyéb módosítások Inaktiválás: a berendezést a termelésből kivonjuk Reaktiválás: a berendezést a termelésbe visszaállítjuk Leltárkörzet változás: pl. áttelepítés esetén Költséghely változás: pl. áttelepítés esetén Értékcsökkenés leírási kulcs vagy maradvány változása: a vállalat újraértékelése szerint Eszközosztály változása: pl. egy termelő berendezés irodai gép lett (a gyártósort vezérlő számítógépet a főnök kéri az irodájába szövegszerkesztésre, a gyártósort pedig majd inkább kézzel vezérlik)

Eszköz kivezetése Ha az eszközre már nincs szüksége a vállalatnak azt ki kell vezetni. (Nem kell, de célszerű.) Jogcím meghatározása: Milyen jogcímen szabadulunk meg az eszköztől: eladás, selejtezés, apport (bevitel leányvállalatba), leltárhiány stb. Nettó érték meghatározása: mennyi az eszköz aktuális, értékcsökkenés alapján számított értéke? Első lépés: értékcsökkenés meghatározása a kivezetés napjára vonatkozóan. Második lépés: nettó érték = bruttó érték mínusz az elszámolt értékcsökkenés. (Másik neve: a nyilvántartás szerinti érték.)

107 / 136

Vállalati Információs Rendszerek BSc Főkönyvi kivezetés Az eszköz nettó értékének és az elszámolt értékcsökkenésnek a kivezetése, vagyis az eszköz és a hozzá tartozó értékcsökkenési számla egyenlegének kiegyenlítése (az adott eszköz vonatkozásában, hiszen egy ilyen eszközosztály számlán több eszközt vezetünk). Érintett számlák: (zárójelben hogy melyik mikor) 8 Ráfordítások o 86 Egyéb ráfordítások 861 Értékesített tárgyi eszközök nyilvántartás szerinti értéke (amennyiben az eszközt eladjuk) 866 Értékvesztés, terven felüli értékcsökkenés (amennyiben az eszközt selejtezzük) o 88 Rendkívüli ráfordítás 881 Társaságba bevitt eszközök nyilvántartási értéke (apport esetén) A kivezetés könyvelése: Értékesítés (eladás) esetén: Tartozik 861, Követel az eszköz számlája az eszköz nettó értékének összegében, továbbá tartozik az eszköz értékcsökkenési számlája és követel az eszköz számlája az elszámolt értékcsökkenés összegében. Selejtezés esetén: mint az értékesítés, de 861 helyett 866. Apport vagy leltárhiány esetén: hasonlóan a fentiekhez, de egyéb kézzel végzendő műveletekre is szükség van. Példa:

142

1492

5711

Egyéb berend.

Egyéb b. écs.

Terv.szerinti Écs.

leírás 100

60

60

2

0 Ennek a beruházásoknál van a párja

50 10

1a 1b

50 10

40

3

861 Értékesített TE

40

0 1a 1b 2 3

Bruttó érték: 100 eFt Értékcsökkenés 50eFt Értékcsökkenés az eladás napja-1-ig 10eFt Értékcsökkenés kivezetés: 50 + 10 = 60eFt Nettó kivezetés: 100 – 60 = 40eFt

Törlés: Eszközök listáján nem jelenik meg, de fizikailag az adatok nem semmisülnek meg. 108 / 136


Az eszköz élettörténete: mikor hova került (leltárkörzet, költséghely), mennyi értékcsökkenést számoltak el, stb. Erre bármikor szükség lehet, hogy az apeh kérdéseire válaszolni tudjunk. Ha az eszköz élettörténetére már nincs szükség (kivezettük és elévült), törölhető a nyilvántartásból. Vagyis az adatokat véglegesen, fizikailag törölhetjük. Ha egy eszköz inaktív, akkor nincs értékcsökkenés. Lehet, hogy a leltár körzet megváltozik, akkor sem szabad átütni.

egyéb } módosítások

A korábban tárgyalt mozgásnem „filozófia” alkalmazható a tárgyieszköztök kezelésében is. Erre mutatunk be néhány példát a 4.9. és 4.10. táblázatban. 4.9. táblázat. Példa tárgyi eszköz nyilvántartásban használt mozgásnemekre

Tranzakció típus

Tranzakció

Mozgásnem

Új

Beszerzés

Módosítás

ÜZBE

Kp vásárlás Vásárlás Üzembehelyezés, egyedi Üzembehelyezés, folyamatos Tervszerinti ÉCS Rendkívüli ÉCS ...

ÉCS elszám. ...

...

4.10. táblázat. Példa, hogyan kell paraméterezni a tranzakciókat, hogy mozgásnemeket hozzunk létre

Tranzakció Mozgásnem Könyvelés vonzata Beszerzés ÜZBE ÜZBE

Vásárlás Üzbe, egyedi Üzbe, foly

Aktiválás ÉCS elszámolás

T1611,K<szállító> --T<eszk>,K1611 A T<eszk>,K1612 A

109 / 136

-------


5. SAP MYSAP ERP Dőlt betűvel: elolvasni, megérteni. Ez is vizsgaanyag, de nem kell szóról szóra tudni. Pl. felsorolásoknál párat kell tudni említeni, egyéb bekezdéseknél pár mondatban saját szavakkal tudni kell összegezni. Nem dőlt betűvel: vizsgán számon kért anyag, tételesen tudni kell. Az SAP céget 1972-ben öt volt IBM dolgozó alapította, a gépidőt megspórolandó éjszaka dolgoztak egy valósidejű standard adatfeldolgozó rendszer kialakításán. Mára az SAP rövidítés jelentése megváltozott (Systems, Applications and Products), s egyúttal a világ piacvezető üzleti szoftvermegoldás szolgáltatóját jelképezi. A német walldorf-i központú részvénytársaságnak több fejlesztőközpontja, több mint 20.000 alkalmazottja, közel ugyanennyi ügyfele, rendszerének pedig 12 millió felhasználója van a világ 120 országában. Termékeinek magja a kliens-szerver architektúrájú, R/3 névre keresztelt háromrétegű rendszer. Ma az SAP több különböző terméket kínál. A klasszikus vállalatirányítási funkciók a mySAP ERP-ben kaptak helyet. Emellett a termékkínálatban megtalálhatók egyéb speciális funkciókat ellátó termékek, mint például a mySAP CRM (Customer Relationship Management), a mySAP SCM (Supply Chain Management), mySAP PLM (mySAP Product Lifecycle Management) stb. is. Ezekre a termékekre összefoglalóan mySAP Business Suite néven szokás hivatkozni. Az általános funkcionalitású (R/3 alapú) termékeknek általában létezik az egy-egy iparágra szakosodó változata is. Összesen 25 iparágat támogat az SAP, mint például „közművek” (víz, gáz, fűtés), „média”, „telekommunikáció” vagy akár a „postai szolgáltatások”. A mySAP ERP rendszert futattató környezetet SAP NetWeaver applikációs és integrációs platformnak hívják. Ez futtatja a főként ABAP nyelven, továbbá a JAVA-ban írt alkalmazásokat is. A JAVA alkalmazások száma gyorsan nő, és nő a webes megoldások száma is (pl. internetes értékesítés), melyeket a NetWeaver ugyancsak támogat. SAP NetWeaver applikációs és integrációs platform az információt, a folyamatokat és a személyeket is integráló környezet, egybefoglalja és támogatja az üzleti alkalmazások összes aspektusát. Ezek együttesét Ecosystem néven emlegetik. Az Ecosystem általában azzal kapcsolatban merül fel SAP berkekben, hogy az SAP egy platformot akar kialakítani, amit aztán más gyártók is használnak a saját termékeikhez, illetve kibővítik azt. Ezzel ugyanaz a célja, mint a Microsofnak (volt, mert már elérte) a windows-val: szinte mindenki arra fejleszt, így a harmadik fél által megírt program is bevételt generál a Microsoftnak, hiszen meg kell vennie hozzá a windowst is, hogy futtatni tudja. A régi R/3, vagy mai nevén mySAP ERP rendszer: üzleti alkalmazásmodulok integrált készlete. Minden modul 1000-nél több üzleti folyamatot tartalmaz. A rendszer 10000-nél több táblát tartalmaz.

110 / 136


5.1. A MYSAP ERP FŐBB FUNKCIONÁLIS MODULJAI A modulokat az 5.1. ábrán szemléltetjük.

SD

FI

Értékesítés

Pénzügyszámvitel

Sales & Distribution Material Management

Production Planning

Financing

MM

CO

Anyaggazdálkodás

Controlling

PP

AM

Termeléstervezés

Eszközgazdálkodás

R/3

Asset Management

Client/Server Quality Assurance

QA

PS

Minőségbiztosítás

Projektrendszer

ABAP/4 PM

OC

Karbantartás

Iroda & automatizálás

Plant Management ≈ Facility Management

HR

IS

Személyzeti gazdálkodás

Szakmai megoldások

Project System

Workflow

Industrial Solutions Human Resources

5.1. ábra mySAP ERP főbb funkcionális moduljai A mySAP ERP rendszer teljeskörűen tartalmazza a vállalati erőforrástervezéshez szükséges összes funkciót. A modulokba rendezett magfunkciók a kliens-szerver architektúrájú R/3 rendszerből származnak. A legfontosabb modulok a FI és SD, valamint a CO. (Legtöbb cégnél ezek kerülnek bevezetésre, többeknél még az MM is): − FI – Financial Accounting – Számvitel − CO – Controlling – Belső számvitel − SD – Sales and Distribution – Értékesítés és „eladás oldali” logisztika − MM – Material Management – Anyaggazdálkodás, „beszerzés oldali” logisztika − PP – Production Planning – Termeléstervezés − PM – Plant Maintenance – Üzemkarbantartás − AM – Asset Management – Eszköznyilvántartás − HR – Human Resources – Humán erőforrás kezelés − QA – Quality Assurance - Minőségbiztosítás A modulok egymással képesek kooperálni, ettől lesz a rendszer integrált. Pl. az SD modulban egy eladás lebonyolítása után az FI modulban automatikusan könyvelésre kerül a művelet számviteli vonzata, valamint MM-ben a készletállapot frissül. A legfontosabb modul az FI, ezt lényegében mindenhol bevezetik, hiszen az össze többi modul erre épül.

111 / 136


5.2. A MYSAP ERP RENDSZER ALAPJAI Az SAP rendszerek háromrétegű kliens-szerver architektúrájú rendszerek. Az átlagos felhasználó a három rétegből csak a saját gépén futó grafikus kliens programot, az úgynevezett SAPGUI-t látja. A SAPGUI hálózaton keresztül kommunikál az alkalmazásszerverekkel, ennek megfelelően meg kell számára adni a kapcsolódási paramétereket, melyet egy URL szerű szintaktikával rendelkező karakterlánc formájában kap meg. Annak érdekében, hogy ezt a karakterláncot ne kelljen a felhasználónak begépelnie, egy SAPLogon nevű segédprogramot fejlesztettek ki, mely képes az általunk használt SAP rendszerek elérési információit nyilvántartani, és kattintásra megfelelő paraméterekkel indítani a SAPGUIt1. Amint a SAPGUI kapcsolódott a szerverhez, be kell lépnünk, ezután a szerepkörünknek megfelelő menüt látjuk.

5.3. RENDSZER, MANDANT (KLIENS), VÁLLALAT ÉS DOMAIN Rendszernek az azonos adatbázisban dolgozó alkalmazásszerverek csoportját nevezzük. A rendszereket általában három betűs névvel látják el. Egy rendszerben több mandant hozható létre az alábbiak szerint. A mandant, ahogy a német szó is mutatja, onnan ered, hogy régen könyvelő cégek használták az SAP-t ügyfeleik (mandant = client = ügyfél) könyveléseinek elvégzésére, és egy rendszerben több ügyfélnek könyveltek. Így az ügyfelek adatait el kellett különíteni. Ma a mandantokat (klienseket) általában tesztelési célra használják, az éles rendszerekben csak egyetlen mandant (kliens) található. A klienseket általában háromjegyű számmal azonosítják. A rendszerben vannak kliensfüggő és kliensfüggetlen adatok (helyesebben adattáblák.) A kliensfüggő adatok esetében az egyik kliensben végrehajtott adatmódosítások, vagy az abban felvett új rekordok csak ugyanabban 1

A SAPGUI felületén az alábbi elemeket figyelhetjük meg: Menüsor: a System és Help menük mindig megtalálhatók, a többi menüpontot az éppen futtatott alkalmazás (tranzakció) állítja be − Gyorsindító mező: különböző parancsokat adhatunk ki, tipikusan új tranzakciók indítására használható − SAPGUI toolbar: mindig látható gombsor, a gombok többségéhez tartozó funkciókat az alkalmazások kezelik le (vissza gomb, bezárás gomb, keresés gomb, nyomtatás gomb stb.), a többit a futtató rendszer. − Alkalmazás címsor: a képernyőhöz tartozó cím, alkalmazásfüggő − Alkalmazás toolbar: az alkalmazás által összeállított gombsor − Fő képernyőrész: itt jelennek meg az alkalmazás képernyői − Státuszsor: hasznos rendszerinformáció Hasznos ismerni a rendszer-menüben található státusz menüpontot: itt különböző paramétereket tekinthetünk meg a rendszerről és az éppen futtatott alkalmazásról. Ezek az információk igen jól jöhetnek különösen fejlesztés során. Hasonlóképp információt kaphatunk egy-egy beviteli mezőről is (pl. hogy melyik táblában tárolódik), ha fókuszálása után megnyomjuk a F1 gombot, majd a technikai információk gombot. Szintén beviteli mezőn állva használható az F4 gomb, mely a mezőhöz tartozó input help-et hozza fel, vagyis listát ad arról, hogy a mezőbe mely értékek írhatók. A legtöbb helyen alkalmazhatjuk a navigációt: egy-egy mezőre vagy szövegrészletre kattintva általában elindul a logikailag hozzátartozó tranzakció és megjeleníti a kattintás tárgyát képző azonosító adatait. Így például ha egy ABAP forráskód szövegében duplán kattintunk egy adattípus nevére, megjelenik az adattípus szerkesztője. Ezáltal a tranzakciók igen szorosan össze vannak „hálózva”. Egy SAPGUI indítása után több (de korlátos számú) új ablakot, úgynevezett móduszt, vagy session-t nyithatunk, az erre szolgáló ikonnal. Munkánkat ezután a több ablakban párhuzamosan végezhetjük. A gyorsindító mezőben az alábbi parancsok használhatók: − Tranzakciókód - Csak a kezdeti menü képernyőn. Elindítja az adott tranzakciót. − /n – Megszakítja az aktuális alkalmazás futását, és a menühöz visz. − /nXXX – Megszakítja az alkalmazás futását, és elindítja az XXX tranzakciót. − /oXXX – Új ablakban indítja az XXX tranzakciót. − /h – Elindítja a debugger-t. −

112 / 136

Vállalati Információs Rendszerek BSc a kliensben látszanak, míg a kliensfüggetlen adatokon végzett módosítások az összes kliensben érvényesülnek. A kliens tehát bizonyos adatkörökre nézve teljes mértékben elkülönülő adatbázist szimulál. Technikai megvalósítását tekintve az ilyen adatok tárolására használt táblákban van egy MANDT nevű további kulcsmező, melyet a rendszer a lekérdezések, és adatmódosítások során automatikusan kitölt az éppen használt kliens számával. Egy-egy kliens (mandant) alatt több vállalat is lehet, ezek a company code-dal érhetők el, amely egy négyjegyű szám szokott lenni. A company code-ot tipikusan multinacionális nagyvállalatok használják, melyek működésüket tekintve egy közös érdekeltségnek minősülnek, azonban könyvelésüket és jogi, pénzügyi valamint adóügyi tagolódásukat illetően (amely alapvetően az FI különbözőségét jelenti) több részre vannak osztva. A fő cél tehát, hogy az üzleti folyamatok végrehajtása során a company code megadásával kijelöljük, hogy mely jogi és pénzügyi értelemben vett vállalat főkönyvi számláján kívánjuk a tranzakciót könyvelni, de a különböző vállalatok adatai (pénzügyi szempontból) könnyen összevonhatók, konszolidálhatók legyenek. A company code-nak tehát nem az a célja, hogy egy rendszerben egymástól teljesen független, különböző (esetleg konkurens) vállalatok adatait tároljuk, költséghatékonysági okokból. A company code mellett egyéb szervezeti egységekre is szükség lehet, így például a CO modul használatához költséghelyeket, míg az SD modul használatához értékesítési szervezeteket, továbbá elosztási csatornákat és divíziókat kell definiálnunk.

Rendszer térkép (System landscape) Négy „fajta” rendszert különböztetünk meg, ezeket más-más céllal hozzák létre: 1. Integrated Systems (eredeti rendszer) Az SAP saját rendszere. A rendszer jele SAP, ebben végzik a fejlesztést. Innen származnak a kibocsátott rendszerek, új verziók. 2. Development Systems (fejlesztő rendszer) Opcionális rendszer, ahol az eredeti rendszertől (SAP) függetlenül végezhetnek fejlesztéseket és beállításokat az SAP tanácsadók. Jele: DEV. 3. Consolidation Systems (gyakorló, teszt rendszer) A változásokat már tartalmazó, a működés tesztelésére gyakorlatoztatására szolgáló rendszer. Jele: CON.

és

a

kezelők

4. Production Systems (produktív, éles rendszer) A legfontosabb, a működő, az éles használatban levő rendszer. Ennek fejlesztése, támogatása a cél, de tilos benne fejleszteni és tesztelni. Jele: PRD. Jele: PRD. Mint azt feljebb láttuk, egy rendszerben sok kliensfüggetlen adatot találunk, ilyenek például maguk az ún. ABAP programok. Ezért különösen fontos, hogy szinte fizikailag elkülönítsük a teszt és éles rendszert egymástól, nem elég csak két külön klienst létrehozni ugyanazon rendszerben, hiszen a módosított ún. repository objektumok a produktív kliensben is módosulnának. Fontos továbbá, hogy éles rendszerben nem szabad kiadni fejlesztői jogosultságot, egy fejlesztő ugyanis képes akár a rendszergazda jelszót is felülírni, és a teljes adatbázishoz korlátlanul hozzáfér. Ennek megfelelően a produktív rendszerekben általában csak egyetlen kliens található, míg a teszt és fejlesztői rendszerekben több klienst hoznak létre, hogy különféle adatokon tesztelhessék a fejlesztéseket. Az SAP háromrendszeres konfigurációt, ún. System Landscape-t ajánl ügyfeleinek, melytől természetesen el lehet térni. Így előfordulhat, hogy a fejlesztői és konszolidációs rendszereket költséghatékonysági okokból összevonják, de elképzelhető olyan eset is, hogy

113 / 136

Vállalati Információs Rendszerek BSc például három tesztrendszer működik a vállalatnál. Az ajánlott konfiguráció szerint a vállalat három rendszert üzemeltett, és azokban az 5.2. ábra szerint hozzák létre:

Development system (DEV) CUST : customizing és fejlesztői mandant. TEST : kiegészítő fejlesztői mandant. SAND : homokozó (sandbox) mandant. (Innen az esetleges módosítások nem vihetők át más rendszerekbe.) Consolidation system (CON) QTST : quality assurance mandant. TRNG : training mandant (nem módosíthatók a customizing és repository objektumok). Production system (PRD) PROD : produktív mandant. DEV

CON

PRD

CUST

QTST

PROD

TEST

TRNG

SAND

5.2. ábra Rendszer térkép a mySAP ERP telepítéséről A 3 rendszeres landscape azt jelenti, hogy a vállalat három SAP rendszert tart fent: egyet a fejlesztések elvégzésére, egyet a fejlesztések tesztelésére és oktatására és egy valóban használt, éles rendszert. Két rendszeres landscape kevés fejlesztés esetén fordul elő. Ekkor a DEV és CON egyben van kialakítva. Ennek hátránya, hogy a mandant-független adatok a teszt és a fejlesztői rendszerben is módosulnak. Felhívjuk a figyelmet, hogy fizikailag a fejlesztések, módosítások a PRD rendszerbe közvetlenül a DEV rendszerből (vagy az SAP rendszerből) kerülnek át, és nem a CON-ból. A CON-ból csak az elvi jóváhagyás érkezik meg tesztelés után. Az ábrán jelölt átvitel így logikai útvonalat jelöl. Terhelésmegosztási célból egy rendszer funkcióit fizikailag több gépre vagy fürtbe kapcsolt gépek csoportjaira (clusterekre) is telepíthetik. A fürtbe kapcsolt gépek kívülről egy szervernek látszanak. Egy rendszeren belül SAP példánynak vagy SAP instance-nek nevezzük az egy szerverre telepített SAP modulok és funkciók összességét. Például, egy rendszeren belül a csak SD modult futtató alkalmazás szerver is egy SAP példány. Egy domainba (vigyázat, az nem ugyanaz mint az ABAP nyelben haszált a domain) tartoznak egy adott PROD mandant támogatására létrehozott rendszerek. Nagyobb vállalatoknál jellemző, hogy több domain-nel is találkozunk, a HR funkciókat tipikusan külön domain-ben valósítják meg, az igen érzékeny adatok miatt.

114 / 136

Vállalati Információs Rendszerek BSc A javasolt három rendszer egy domainba tartozik, és 6 mandantot foglal magában. Egyegy mandant alatt több vállalat is lehet, ezek a company code-dal érhetők el. A vállalatok alatt vannak a telephelyek, gyáregységek stb. A fogalmi hierarchiát az 5.3. ábra szemlélteti: Domain

Instance . . . Instance

Mandant . . . Mandant

Company (Vállalatok) . . .

Gyár Telephely . . .

5.3. ábra mySAP rendszer szervezeti egységeinek hierarchiája

5.4. A RENDSZER MAGAS SZINTŰ ADATMODELLJE A rendszer adatmodelljét, amit az 5.4. ábrán szemléltetünk, általában az alábbiak szerint tagolják, figyelembe véve a kliensfüggőséget: − Repository: az alkalmazások objektumai, például programok, tábladefiníciók, adattípus definíciók, tranzakciókódok, funkciós modulok, osztályok, interfészek, search help-ek, dokumentációk, package-ek − Cross-client customizing: klienseken átívelő customizing adatok, például a rendszernaptár − Client-specific customizing: kliensfüggő customizing adatok, pl. szervezeti egységek − User: felhasználói adatok, jogosultságok − Application data: alkalmazás adatok, vagyis törzsadatok és tranzakciós adatok, pl. ügyféltörzs, beszerzési megrendelések

5.4. ábra mySAP ERP magas szintű adatmodellje

115 / 136


5.5. TESTRESZABÁS A CD lemezen szállított SAP rendszer telepítés után nem használható a vállalat folyamatainak végrehajtására, azt előbb testre kell szabni, a vállalat egyedi sajátosságaihoz kell igazítani. Szinte minden alkalmazáshoz tartoznak a működését befolyásoló vezérlő adatok, valamint olyan konfigurációs adatok, melyeket a mindennapi használat során nem módosítanak (pl. szervezeti egységek, főkönyvi számlák listája stb.) Ezen adatok módosítására, szerkesztésére szintén rendelkezésre állnak programok illetve tranzakciók, melyeket általában az alkalmazásokkal együtt hoznak létre és adnak ki. A testreszabás folyamatát az úgynevezett Implementation Guide (IMG) könnyíti meg azáltal, hogy egybegyűjti, és hierarchikusan rendezett struktúrában megjeleníti a testreszabáshoz szükséges konfigurációs adatokat módosító tranzakciókat. A végrehajtandó feladatok IMG projektekhez is rendelhetők. Az egyes beállító tranzakciókat kattintásra is lehet indítani, kérésre megjeleníti a dokumentáció, valamint az IMG képes megjegyezni, hogy mely testreszabási lépést végeztük már el. Az Implementation Guide az SPRO tranzakció indítása után, a megfelelő gombra kattintva érhető el. Az IMG segíti a szervezeti egységek, az üzleti folyamatok stb. konfigurálását is, pl.: - általános beállítások (ország, időzóna, pénznem), - vállalati struktúra (üzletág, társaság, raktárhely, pénzügyi körök, gyárak, telephelyek, értékesítési szervezetek), - átfogó komponensek, melyek különböző modulok közötti adatfolyamatokat definiálnak (bank, üzleti partnerek, számkörök (anyagszámok, megrendelési számok stb.)) definiálása, - modulokra jellemző beállítások elvégzését, pl. FI (pénzügy-számvitel), SD (értékesítés), CO (kontrolling), MM (anyaggazdálkodás), HR (személyzeti gazdálkodás) modulok beállítását.

5.6. FEJLESZTÉS Amennyiben az IMG-ben található tranzakciók által biztosított testreszabási lehetőségek nem elegendők – például szükség van egy egyedi heti jelentésre a vállalatnál, akkor a rendszerben újabb alkalmazásokat kell fejleszteni, vagy a meglévőket kell módosítani. Az SAP rendszer az alkalmazásokat egy ún. ABAP (Advance Business Application Programming) nyelven megírt programok, valamint egyéb adatdefiníciós objektumok halmazának formájában tartalmazza. Az ABAP olyan programozási nyelv, mely az üzleti folyamatokat támogató programok elkészítését kívánja egyszerűsíteni. Ennek megfelelően beépített adatbázis elérési utasításokat, strukturált belső adattáblákat és gyors, egyszerű képernyőkezelést biztosít. Automatikusan felügyeli az adatbázis tranzakciók lezárását illetve visszagörgetését, a futás kimenetelének függvényében. A standard alkalmazások forráskódjához és objektumaihoz is hozzáférhetünk, sőt elviekben módosíthatjuk is azokat. Ehhez a rendszerben rendelkezésünkre állnak ugyanazok az eszközök, melyeket az SAP, mint cég is használ alkalmazásai fejlesztésére. Ha a rendszerben fejleszteni szeretnénk, szükségünk van a fejlesztői jogosultságokra, amit egy úgynevezett fejlesztői kulcs ad meg, amit az SAP-tól kell kérni minden egyes felhasználóhoz. A kulcs lehetővé teszi, hogy a fejlesztőeszközöket használjuk, azokkal új objektumokat hozzunk létre, vagy meglévőket módosítsunk. Ilyen objektumokat kizárólag „vásárlói namespace-ben” tudunk létrehozni, ami a gyakorlatban azt jelenti, hogy az objektum nevének Z (vagy Y) betűvel kell kezdődnie. Amennyiben standard objektumot is szeretnénk módosítani, úgy ehhez külön objektumkulcsot kell kérnünk. Lehetőség van a standard programok működését befolyásolni anélkül is, hogy módosítanánk őket. A legtöbb standard program jól definiált pontokon úgynevezett user-exit-eket hív meg. Ezek a gyakorlatban olyan eredetileg üres törzsű függvények, melyeket a vásárló

116 / 136

Vállalati Információs Rendszerek BSc „kitölthet”, ezáltal befolyásolhatja a program működését. Hasonlóan, az adatbázistáblák és strukturált adattípusok úgynevezett append structure-ekkel kibővíthetők, új oszlopok definiálhatók. Ezen technológiák előnye, hogy a standard objektumok esetleges frissítése esetén sem íródnak felül módosításaink.

5.6.1. Data Dictionary A Data Dictionary (DD vagy DDIC) magyarul adatszótár olyan komponens az SAP rendszeren belül, mely meta-adatokat tárol a rendszerben található adatokról. Szerkesztő eszköze, az úgynevezett Abap Dictionary (az SE11 tranzakciókóddal érhető el). Segítségével módosíthatjuk a rendszerben található adatbázistáblák felépítését, újakat definiálhatunk, illetve adattípusokat hozhatunk létre, melyeket aztán ABAP programjainkban használni tudunk. A DDIC-ben tárolt adatok igen fontosak a rendszer működéséhez. A programok futtatása során ennek segítségével tudja ellenőrizni a rendszer, hogy az elérni kívánt adatbázistábla, illetve annak az elérni kívánt mezője létezik-e. A képernyők kirajzolása során ez alapján tudja a rendszer megállapítani, hogy a megjelenítendő mező milyen típusú adatot tartalmazhat, és milyen címkeszöveget és F1 help-et kell mellette megjeleníteni. Az itt megadott adatok alapján képes a rendszer automatikusan származtatni az F4 megnyomásának hatására megjelenő input help értékeit. Itt lehet beállítani, hogy kívánjuk-e egy adattábla rekordjait pufferelni az alkalmazásszerveren stb. A Data Dictionary támogatja a többnyelvűséget, így pl. egy-egy adatelemhez a mezőcímkék különböző nyelveken eltárolhatók. A DDIC többek között az alábbi objektumokat tudja kezelni: − Adatbázis táblák. A logikailag definiált táblákat a rendszer automatikusan létrehozza illetve módosítja az adatbázisban is. Megadható a táblák mezőlistája, kulcsa, külső kulcsok, pufferelési vezérlőadatok, input help hozzárendelés stb. − Domain. Technikai adattípus, mely tartalmazza az adat alaptípusát (szöveg, szám stb.), hosszát, lehetséges értékeit (pl. listából való kiválasztás) és/vagy a lehetséges értékeket tartalmazó táblát stb. − Adatelem (Data Element). Üzleti adattípus, mely hivatkozik egy domain-re, vagy a domainben található információkat egyéb módon biztosítja, továbbá tartalmazza az adathoz tartozó leírásokat (mezőcímke). − Struktúra. Összetett adattípus, mely adatelemekből (struktúrákból, táblatípusokból) több komponensű, összetett adatot épít fel. − Táblatípus. Összetett adattípus, mely adott struktúrának megfelelő sortípusú táblatípust hoz létre. ABAP programokban belső táblák létrehozására alkalmas. A sortípus mellett tartalmazza a belső tábla tárolási módját (lineáris, indexelt, hashelt) és kulcsát is.

5.6.2. Futtatható objektumok A Data Dictionary objektumai mellett a repositoryban még „futtatható jellegű” objektumokat, valamint az ezekhez kapcsolódó segédobjektumokat találjuk. Ilyenek például: − Programok: report, module pool. ABAP forráskódú futtatható programok. Az egyszerűbb report alapvetően nem rendelkezik bemeneti képernyőkkel csak listakimenettel, míg a module pool alapvetően grafikus bemeneti képernyőkezeléssel is ellátott, ún. flow logic-os program (lásd lent). A kettő közötti határvonal igen elmosódott, a technikák keverhetők. A könnyebb fejlesztés, az összetettebb beviteli felületek és megjelenített üzenetek több részre tagozódhatnak az alábbiak szerint: = Képernyők, gui status-ok, gui title-k. (Screen, Gui Status, Gui Title, összfoglaló nevük: Dynpro=Dynamic Program.) Egy-egy programhoz kapcsolódóan képernyőtervek, gombsortervek és címsortervek, melyekkel a grafikus felület kinézetét vezérelhetjük. A képernyőket grafikus szerkesztővel rajzolhatjuk meg, majd

117 / 136

Vállalati Információs Rendszerek BSc programjaink meghívhatják ezeket a képernyőket. A képernyők megjelenítése előtt, és a felhasználó által kiváltott esemény után (kattintás, gombnyomás), eseménykezelő rutinok futnak le. Ezeknek a rutinoknak a logikai tartalmát egy úgynevezett „flow logic” nyelven írhatjuk le, melyből aztán ABAP kódrészleteket hívhatunk meg. A képernyő megjelenítése előtti flow logic a PBO (Process Before Output), a felhasználói esemény után lefutó a PAI (Process After Input). A flow logic képes a képernyőn bekövetkezett eseményeket részletesebben megkülönböztetni, majd ez alapján a megfelelő ABAP kódrészt meghívni. Az ilyen eseményvezérlőből meghívott ABAP kódrészleteket moduloknak nevezik, innen a module pool elnevezés is. A module nem keverendő össze az alábbiakban részletezendő funkciós modullal. = Szövegelemek, üzenetek. (Text Elements.) A programokban bedrótozott szövegek helyett szövegelemekre hivatkozhatunk, majd külön szerkesztőprogramban megadhatjuk, hogy az adott szövegelemhez mely nyelven milyen szöveg tartozzon. − Tranzakciók. (Transaction.) Programok egyszerű indítását teszik lehetővé azáltal, hogy egy bonyolultabb nevű programhoz rövid tranzakciókódot rendelünk. Az így létrehozott tranzakció futtatható kódjának közvetlen beírásával, vagy felvehető a menübe. − Funkciós csoportok. (Function Group.) Funkciós modulokat (Function Module) tartalmaznak. A funkciós modulok lényegében függvények, melyeket a szokásos moduláris fejlesztés érdekében hoznak létre. Az egy funkciós csoportba tartozó funkciós moduloknak lehet közös adatterületük, mely az egyes függvényhívások között megmarad. − Osztályok, Interfészek. Az ABAP objektum-orientált részének megfelelően objektumosztályokat és interfészeket hozhatunk létre.

5.6.3. Fejlesztői Eszközök A rendszer fejlesztéséhez rendelkezésre álló eszközöket gyűjtő néven Abap Workbench-ként hivják. Az alábbi eszközök állnak rendelkezésünkre, tranzakciók formájában: − Abap Dictionary. (SE11) Adatdefiníciós eszköz, lásd feljebb. − Abap Editor. (SE38) Forráskódok szerkesztése, programok futtatása. − Abap Debugger. Hibakeresést tesz lehetővé, a /h gyorsparanccsal indítható. − ScreenPainter. Képernyőtervek elkészítése. − MenuPainter. Menüstruktúrák, GUI státuszok elkészítésére. − Class Builder. (SE24) Osztályok és interfészek definiálására alkalmas. − Function Builder. (SE23) Funkciós csoportok és modulok definiálására alkalmas. − Object Navigator. (SE80) Integrált fejlesztői környezet, mely egyesíti a fentieket.

5.6.4. Aktiválás A repository-ban található objektumok többségének a rendszerben két változata van: aktív és inaktív. A rendszer futása során az aktív változatot használja, míg mi az inaktív változatot szerkeszthetjük. Az inaktív változatot aktívvá tehetjük az aktiválás gomb (gyufa ikon) megnyomásával. Ennek a mechanizmusnak a célja a következő: Tegyük fel, hogy a rendszerben van egy működő programunk. Csak aktív verzió létezik belőle. Azt a feladatot kapjuk, hogy módosítsuk ezt a programot. Nekiállunk hát szerkeszteni, félig elkészülünk a módosítással, majd hirtelen vége a munkaidőnek. A félig elkészült program még nyilván nem működik az elvárások szerint, viszont már részben módosítottuk a funkcionalitását. Amennyiben csak egy változat létezne a rendszerben, úgy ha elmentenénk a programot az érvényre jutna, és nem lenne használható holnap reggel. Így viszont ha a programot elmentjük, annak két változata lesz: az eredeti aktív változat megmarad, a módosított változat inaktívként mentésre kerül. Következő reggel

118 / 136

Vállalati Információs Rendszerek BSc programunk megírását folytathatjuk, majd ha kész, aktiváljuk. Ennek során az eredeti verzió törlődik, majd az inaktív verzió kerül helyébe, és aktívvá változik. Ezután ismét csak aktív verzió lesz a rendszerben a programból. Az aktiválás egyúttal generálást is vonhat maga után: táblák aktiválása esetén az adatbázisban lévő valódi adatbázistáblák ilyenkor generálódnak vagy módosulnak, program aktiválása során a programot a rendszer bájtkóddá lefordítja.

5.7. CHANGE AND TRANSPORT SYSTEM A Change And Transport System (röviden CTS) olyan segédeszközök halmaza, melyek megkönnyítik az – általában egy domain-be tartozó – rendszerek között a testreszabások, módosítások, fejlesztések átvezetését. A módosítás okai lehetnek: - bevezetés, - a cég üzleti, szerkezeti változtatása - új SAP funkció bevezetése - új verzió installálása (upgrade). Rendszerek között átvezetni alapvetően két fajta objektumot lehet: customizing beállításokat (vagyis lényegében a customizing táblák rekordjait) továbbá repository objektumokat, vagyis programokat, DDIC elemeket. (Nem lehet átvezetni például törzsadatokat, tranzakciós adatokat, számlálókat vagy számköröket stb.) 1. Repository adatok (Workbench) mint korábban már láttuk DDIC elemek és futtatható objektumok: - ABAP programok, osztályok, interfészek, funkciós modulok - táblastruktúrák, táblabejegyzések (dictionary objects) - adattípusok - képernyők (screen) - dokumentációk 2. Customizing adatok (az IMG-vel történő változtatások), mint említettük: - szervezeti egységek beállításai - pénznemek, országlista - főkönyvi számlák definiálása - egyéb alkalmazásbeállítási adatok (pl. főkönyvi szövegek változtatása, fizetési feltételek definiálása stb.) A rendszerben létrehozott objektumokat az átvezetéshez csoportokba kell sorolni, erre két csoportosítási fogalom áll rendelkezésre. Egyik a package (régi nevén development class) – mely csak a repository objektumok esetében értelmezett, a másik a transport request, amely mindkettőre. A repository objektumokat létrehozásukkor kell package-hez rendelni. Ennek célja, hogy a rendszerben található objektumokat logikailag csoportosítsa: egy package-be általában egy alkalmazáshoz kapcsolódó összes objektum tartozik. A package-hez való hozzárendelés az objektum egész éltére szól. Hasonló ez, mint a fájlok könyvtárba csoportosítása számítógépünkön, vagy a Java package fogalma. A transport request ellenben egy ideiglenes hozzárendelés: Célja, hogy egy request-hez rendeljük hozzá az összekapcsolódó módosításokat, annak érdekében, hogy a módosításokat együtt, egyszerre lehessen átvezetni más rendszerekbe. A transport request-et tehát úgy képzelhetjük el, mint egy listát, mely az átvezetést végző kollegának leírja, mit kell átvezetnie az új rendszerbe. Amint az átvezetés megtörtént, a transport request hozzárendelés érdektelenné válik. A fentiek alapján tehát transport request-hez rendelendő minden customizing beállítás és

119 / 136

Vállalati Információs Rendszerek BSc minden repository objektum módosítása vagy létrehozása. Egy objektum egyszerre csak egy nyitott transport request-hez rendelhető. A rendszer konfigurációjától függően elképzelhető, hogy az a transport request-hez való hozzárendelést nem erőszakolja ki. Repository objektumok esetében az objektumot rendelhetjük egy $TMP nevű, úgynevezett lokális package-hez is. Az ilyen objektumok azért lokálisak, mert helyben maradnak, vagyis nem transportálhatók. Ennek megfelelően transport request-re nincs szükség. A transport request lényegében egy fejlesztési, módosítási projekt modellezésére is alkalmas. Egy transport request-en belül több task-ot definálhatunk, melyekhez felhasználókat (fejlesztőket) rendelünk. Minden fejlesztő elvégzi saját fejlesztéseit, majd a hozzá tartozó task-ot release-eli, vagyis késznek jelöli. Ha minden fejlesztő elkészült a munkával, a projektvezető az egész transport request-et release-eli, vagyis kiadja transzportálásra. Ebben a pillanatban a transport request-hez rendelt összes objektumot a rendszer összegyűjti, majd fájlba kiírja. Az így kapott fájlt a célrendszerbe át lehet tölteni, majd ott importálni lehet. A transport request release-elése során az objektumok felszabadulnak abban az értelemben, hogy újabb módosítások esetén ismét (egy másik) transport requesthez kell majd őket rendelni. A transport requestek létrehozására, karbantartására, release-elésére a Transport Organizer (SE09) tranzakció használható. A feladott transport requestek kezelésére, az átvezetési útvonalak definiálásra, a transport végrehajtására, a transport importálására, a Transport Manager tranzakció használható. Az átvezetéshez szükségesek még továbbá az operációs rendszer szintjén különálló tp és r3trans programok, melyek a transport fájlokat kezelik. Tipikus folymat: DEV CON jóváhagyás után pedig DEV PRD azaz a javításokat a CON rendszerben végzett tesztelés után kell – megfelelés esetén – az éles rendszerbe, mint célrendszerbe átvinni (hibamentes üzemelés elősegítése az előzetes tesztelés segítségével). Kivétel előfordulhat az idő szűkössége vagy más miatt, magas prioritású (repair) üzemmódban. Ekkor a változtatás először a PRD rendszerbe kerül, esetleg ezzel együtt vagy ezután a CON rendszerbe is. A fentieket az 5.6. ábra szemlélteti, kiegészítve az éles működő rendszer tipikus adattartalmával (törzsadatokkal, tranzakciós adatokkal, amiket ugyancsak a DDIC definiál):

120 / 136


Működő példány (éles rendszer) (Production Instance)

Javítás és átvezetés rendszer (CTS – Change and Transport System)

Fejlesztői példány (Development Instance)

Megelőző példány (tesztpéldány) (Preproduction Instance) Production Instance

Rendszerkonfigurációs táblák

CTS

Development Instance ABAP/4 fejlesztő rendszer, IMG (ABAP Development Workbench)

Vezérlőtáblák

Repository, IMG beállítások mySAP ERP alkalmazás

Törzsadattáblák

mySAP ERP alkalmazás

Eszközök a tesztelésre, debuggolásra és optimalizálásra (Tools for testing, debugging and optimizing)

Tranzakciós adattáblák

5.6. ábra Módosítások és javítások átvezetése

Éles rendszer 1. Rendszerkonfigurációs táblák (DDIC elemek) Definiálják a rendszer struktúráját: - használható táblatípusokat, - átvezetett javítások leírását. Csak az SAP módosíthatja. 2. Vezérlőtáblák (Customizing adatok) A kezelők tevékenységét vezérlik. A mandant hierarchikus struktúráját irják le: - vállalati kódokat, - telephelyeket, - értékesítési szervezeteket, - összefüggéseket: melyik telephely melyik másikkal áll kapcsolatban, milyen értékesítési szervezet melyik termékét értékesíti. Az SAP tanácsadók és a vállalat módosíthatják. 3. mySAP ERP (R/3) alkalmazás (Futtatható objektumok) Az üzleti folyamatok működését meghatározó leírások, tranzakciók (pl. megrendelések lefutása, anyagmozgások stb.). 4. Törzsadattáblák Ritkán változó adatok, pl. cikktörzs, vevőtörzs. Ezekre hivatkoznak a tranzakciós adatok. 5. Tranzakciós adattáblák Egy-egy üzleti feldolgozás állapotának megfelelő, gyorsan változó adatokat tartalmaz. Pl. vevői rendelés, beszerzési megrendelés.

121 / 136


Fejlesztői rendszer ABAP/4 fejlesztő rendszer (ABAP Workbench): Teljes programozói környezet, amellyel kiegészíthető a standard SAP. Funkciói: - adatstruktúra-definiálás (ABAP Dictionary, Class Builder), - programfejlesztés (ABAP Editor, Function Builder), tesztelés, debuggolás, optimalizálás, - interfésztervezés (Screen Painter, Menu Painter).

5.8. FUTTATÁSI KÖRNYEZET A mySAP futtató rendszer eredetileg ANSI C nyelven íródott. Az újabb változatok esetében a futtatási környezetet „Web Application Server”, röviden WebAS névvel illetik, mivel szolgáltatásait web service formájában képes nyújtani. Sőt, újabban akár SAPGUI nélkül, webböngésző segítségével is beléphetünk a rendszerbe. A mySAP alkalmazói programok többsége ABAP/4-ben íródtak (néhány újabban JAVAban), bájtkóddá vannak fordítva, és ez az interpreter dolgozza fel azokat.

5.8.1. Architektúra A rendszer három rétegből áll, úgymint adatbázis réteg, alkalmazás réteg és megjelenítési (avagy kliens) réteg. Az adatbázisszerverből csak egy logikai létezhet, de fizikailag természetesen ez lehet clusterezve. A megjelenítési réteg szerepét a SAPGUI látja el. Az alkalmazások futtatását, az üzleti logikát az alkalmazásszerver réteg biztosítja. Egy rendszerhez több alkalmazásszerver is tartozhat, aminek előnye, hogy a terhelést jól el lehet osztani, gyakorlatilag korlátlanul skálázható a rendszer. Rendszerenként létezik még egy message server, melyen keresztül az alkalmazásszerverek kommunikálni tudnak egymással. Ez egyúttal képes felügyelni az alkalmazásszerverek terhelését, és a kliensen futó SAPLogon programnak kérésre ezt az információt át tudja adni. A SAPLogon program így ki tudja választani a legkevésbé terhelt alkalmazásszervert, és a SAPGUI programot erre a szerverre irányíthatja, megvalósítva ezzel egy terhelésmegosztást. Ez a döntés azonban csak a kapcsolódás pillanatában lehetséges, ezután az adott SAPGUI már fixen az alkalmazásszerverhez van rendelve. (A message server további feladataira később visszatérünk.) A jobb szabályozás érdekében logon group-okat alakíthatunk ki: alkalmazásszerverek csoportjait, így a SAPLogon csak az adott logon group-hoz rendelt alkalmazásszerverek közül választja a legkisebb terhelésűt. Létrehozhatunk pl. külön logon group-ot a HR osztály és a könyvelés számára. Ennek előnye, hogy ezáltal az egyes alkalmazásszerver-csoportokon futtatott alkalmazások köre adott lesz, pl. a HR osztály tipikusan a munkaerő nyilvántartással kapcsolatos alkalmazásokat, míg a pénzügy a könyvelési tranzakciókat fogja használni. Így az egyes csoportokra állandósul a pufferekben tárolt adatok mintája, nem kell két külön adatkörnek „versengenie” a pufferért, egyfolytában kiszorítva egymást. Egy felhasználó egyszerre több ablakot nyithat meg SAPGUI-ban, az így létrehozott külön ablakokhoz az alkalmazásszerveren külön External Session jön létre, ezek egymástól függetlenek.

122 / 136


5.8.2. Működés Egy SAP alkalmazásszerverben az alábbi alapvető komponensek találhatók meg: - egy dispatcher (diszpécser) folyamat, mely koordinálja a feldolgozást; - több workprocess folyamat, melyek a feldolgozást végzik; valamint - adatpuffer az adatbázis tartalmának pufferelésére a gyors feldolgozás érdekében. A párbeszéd-feldolgozás menete a következő: 1. Amikor a felhasználó eseményt vált ki, pl. kattint az egérrel, az SAPGUI az eseményt és a képernyőmezők értékeit összecsomagolja, majd elküldi az alkalmazásszervernek. 2. Itt a dispatcher fogadja a kérést. A kéréseket sorba állítja, majd amikor talál egy szabad workprocesst előveszi a következő feldolgozandó kérést. 3. Betölti a kéréshez tartozó felhasználói kontextust (azaz az external session állapotadatait, a belépett felhasználó adatait, a program futásához lefoglalt erőforrásokat), és a kérést feldolgoztatja a workprocess-vel. 4. A dispatcher a felhasználói kontextust elmenti, és az eredményt a SAPGUI felé továbbítja. Minden egyes SAP workprocess-hez az adatbázisszerveren külön feldolgozó folyamat tartozik, avagy minden workprocess saját kapcsolatot hoz létre az adatbázissal annak érdekében, hogy párhuzamosan el tudják azt érni. Amint a kérés kiszolgálásra került, a workprocess felszabadul, és képes újabb kéréseket fogadni. A kéréseket a dispatcher véletlenszerűen osztja ki az éppen szabad workprocess-ek között, ennek megfelelően egy felhasználó kérései nem mindig ugyanahhoz a workprocess-hez kerülnek. (Időbeli multiplexálás.) A workprocess csak egy-egy esemény feldolgozásának idejéig foglalkozik a felhasználó kérésével, az események között, amíg pl. a felhasználó nézegeti a képernyőt, vagy szövegmezőket tölt ki, a workprocess képes más felhasználók kéréseit kiszolgálni. (Esemény: funkcióbillentyű nyomása, menüpont vagy gomb aktiválása, kattintás navigációra, input help kérése stb.) A rendszert az 5.7. ábrán szemléltetjük.

5.7. ábra mySAP ERP rendszer működése

5.8.3. Adatbázis-elérési módok, az Open SQL Az adatbázist a workprocess-ek kétféle képpen érhetik el. Egyik lehetőség közvetlen natív SQL utasítások kiadása. Hátránya azonban, hogy ezek nem lesznek függetlenek az alkalmazott adatbázis szerver típusától.

123 / 136

Vállalati Információs Rendszerek BSc A másik lehetőség ún. adatbázis interfészen keresztül, ha az ABAP programban az SAP által kifejlesztett OPEN SQL utasításokat használjuk. Ez az SQL-nek egy egyszerűsített változata. Az adatbázis interfész komponens az alkalmazásszerverben található, és képes lefordítani az OPEN SQL lekérdezést az adatbázis-kezelő natív SQL formátumára, ismerve annak típusát. Az adatbázis interfész egyúttal képes a lekérdezéseket optimalizálni, illetve az alkalmazásszerverben található puffert is használja és frissíti: amennyiben az adat itt is megtalálható, nem fordul az adatbázishoz, amennyiben nem, felveszi az adatot a pufferbe is.

5.8.4. Workprocess típusok Ötféle típusú feldolgozó folyamat létezik: − DIA (Dynpro interpreter, D-WP): interaktív módban futtatott programok feldolgozásáért felelős, round-robin ütemezéssel. − BTC (Background Batch Process, B-WP): interpreter a háttérben futó programok végrehajtására . − UPD (Update process, V-WP): adatbázis frissítő folyamat. − SPO (Spool Process, S-WP): nyomtatósor vezérlő és feldolgozó. − ENQ (Enqueue Lock Manager, E-WP): SAP logikai zárkezelő. Egy működő rendszerhez minden típusú folyamatból legalább egy kell hogy létezzen, azonban nem minden alkalmazásszerver kell hogy mindegyikkel rendelkezzen. Egy rendszerben azonban legalább egy alkalmazásszerver kell legyen, amelyiken minden típus megtalálható, ezt hívják central instance-nek. Zárkezelő folyamat csak a central instance-en futhat, mivel a zárakat csak központilag lehet kezelni. A Central Instancia és a többi alkalmazás szerver közötti kapcsolatot az ún. Message Serveren tartja fenn, melyet az 5.8. ábra szemléltet. (A Message Server – MS – a Central Instance-on belül fut külön task-ként.):

5.8. ábra Alkalmazás szerverek közötti kapcsolat felügyelete A mySAP alkalmazásszerverek valamint más (esetleg régebbi verziójú) rendszerek közötti kapcsolatot az 5.9. ábrán mutatjuk be. A kapcsolatot két modul vezérli:

124 / 136


Kommunikációs és megjelenítési rendszerek

Központi adatbázis szolgálat

Központi adatbázis

Gateway

feldolgozó felügyelet

APPC



Dispatcher Diszpécser

Alkalmazás szerver központi szolgálatai

Helyi adatbázis

5.9. ábra Alkalmazás szerverek a központi rendszer felügyelete alatt futnak és egy adatbázisba dolgoznak

APPC (Advanced Program-to-Program Communication) A diszpécser beépített modulja szerver feladatkörrel. A feldolgozó folyamatok kapcsolatait kezeli, felügyeli, szükség esetén más gépek felé is az átjárón keresztül. Gateway Az átjáró kezeli a TCP/IP és a LU 6.2 (az IBM saját hálózati protokollja) alapú kapcsolatokat, régebbi rendszerekhez való csatlakozás érdekében.

5.8.4.1. Az adatbázis-frissítés folyamata A DIA és a BTC programok elérik, és adott esetben módosítják is az adatbázist. A sebességnövelés érdekében az adatbázis módosítása szinkron vagy aszinkron módban történhet.

1. Synchronous Update (szinkron adatbázis frissítés) Az adatbázis-frissítés a felhasználó párbeszédével egyidőben megy végbe. A képernyő elhagyásakor megtörténik az update. Ritkán használják, lassú lehet. 2. Asynchronous Update (aszinkron adatbázis frissítés) Ilyenkor a futó program nem menti le azonnal az adatbázisba az adatokat, hanem egy saját funkciós modult hív meg a SAP LUW (lásd lent) lezárása után, „IN UPDATE TASK” jelzővel. Ennek hatására a rendszer lementi a hívás tényét egy sorba (VBLOG), valamint a paramétereket, de az adatbázis-frissítő funkciós modul nem fut le. A program futása véget ér, a felhasználó akár már ki is léphet az egész rendszerből.

125 / 136

Vállalati Információs Rendszerek BSc Amikor a diszpécser talál egy szabad UPD workprocess-t, elindítja, az betölti a paramétereket, majd meghívja a funkciós modult, amely a szükséges adatbázis parancsokat kiadja. A valódi mentés csak ekkor történik meg az adatbázisba. Előnye, hogy a sok munkával járó mentések késleltetődnek és sorosítódnak, így nagy terhelés esetében nem lassítják a rendszert. A technika természetesen nem alkalmazható minden esetben (pl. szigorú sorszámozás.) Hátránya, hogy a felhasználó nem kap azonnali visszajelzést tevékenységéről. Amennyiben az update meghiúsul (pl. mert tele van az adatbázis), a felhasználó és a rendszergazda értesítést kap e-mailben, majd az update szükség esetén újrafuttatható. Ennek ellenére általában ilyenkor a teljes tranzakciót kézzel meg szokták ismételni. Az adatok frissítésének sürgősségi szintjére két szint egyike állítható be: - Primary adatok Ilyenek az időkritikus vezérlőadatok, melyeket a lehető leggyorsabban frissíteni kell a fizikai (központi) adatbázisban. Egy update komponens az egy tranzakcióhoz tartozó adatok csoportja, pl. helyfoglalást vagy anyagrendelkezésreállás-változást érintő adatok. - Secondary adatok Kevésbé fontos a gyors frissítésük, nincs meghatározó szerepük. Update komponensek itt is vannak, pl. statisztikai kiértékelések eredménye. A prioritásos adatbázisfrissítést végrehajtó processzek: - Sürgős frissítés: Primary Update (U1 process) Először a primary adatok frissítése történik meg. A diszpécser magasabb prioritással indítja az U1 processzt, amely az összes primary adatelemet frissíti a fizikai adatbázisban. Egyidejűleg több U1 processz is futhat. - Nem sürgős frissítés: Secondary Update (U2 process) Csak az összes primary adatelem frissítése után indul a secondary adatelemek frissítése. Több U2 processz is működhet párhuzamosan.

5.8.4.2. Zárkezelés Az üzleti adatok feldolgozása során fontos a tranzakciós jelleg, vagyis hogy a folyamat vagy teljesen rögzítésre kerüljön, vagy egyáltalán nem. Az ilyen atomi tranzakciókat az SAP Logical Unit of Works-nek nevezi (LUW). Az adatbázis-kezelők az adatbázis tranzakciókat támogatják a COMMIT és a ROLLBACK parancsok segítségével, egy ilyen tranzakciót nevezünk DB LUWnak. Az SAP üzleti folyamatai szintén tranzakciós jelleget kell mutassanak, ezeket SAP LUWnak nevezzük. Egy SAP LUW lehet pl. egy megrendelői rekord szerkesztése, mely a megnyitás, szerkesztés, mentés lépésekből áll. Mivel a workprocess-ek csak a felhasználói események hatására létrejött kéréseket szolgálják ki, és két ilyen között nem foglalkoznak egy adott felhasználó programjával, hanem másikat futtatnak, szükségszerűen egy DB LUW csak addig tarthat, amíg egy képernyőlépés folyamatban van. Példánkban azonban az adatok betöltése és mentése két képernyőlépés, közötte pedig a workprocess felszabadul. A SAP LUW-ot tehát csak két DB LUW-ban tudjuk megvalósítani. Ez két következményt von maga után. - Egyik, hogy az adatokat mindig csak akkor mentsük, ha már biztos, hogy ezt egy DB LUW-ban meg tudjuk oldani, (feltéve, hogy nem lesz hiba). Nem szabad tehát részleges adatokat lementeni, ha közben még majd esetleg vissza kell adni a vezérlést a felhasználónak, hiszen ekkor a DB LUW kettészakad. Amennyiben az első DB LUW sikeres, a második hibás, máris piszkos adat van az adatbázisban, hiszen félig lementettük a tranzakció eredményét.

126 / 136

Vállalati Információs Rendszerek BSc - A másik következmény, hogy a DB LUW során az adatbázis kezelőben létrejövő zárak nem ölelik át az egész SAP LUW-ot. Ennek megfelelően lehetséges, hogy egy másik felhasználó is módosítja az adatokat, mielőtt mi mentenénk azokat, így az ő módosításai elvesznek. Ennek érdekében szükség van egy olyan zárolási mechanizmusra, mely az adatbázisnál magasabb szinten van, és képes fennmaradni az egész SAP LUW idejére. Ilyen zárakat az ABAP programból kézzel helyezhetünk el, nyilvántartásukat az ENQ workprocess végzi. Ezek a zárak logikai zárak, lényegében „paraméteres szemaforok”, így nem csak egyetlen rekordot, hanem akár teljes rekordhalmazokat is lehet velük zárolni, sőt akár még nem is létező rekordok is zárolhatók, vagy akár egyéb célokra is használhatók. (Amennyiben van update process az adott programhoz, úgy a zárak egészen addig érvényben maradnak, amíg az update process le nem fut.) Az SAP kétféle logikai zárat különböztet meg: - Kizárólagos zárolás (E): zárolás írásra, akkor és csak akkor, ha más felhasználó még sehogy sem zárolta az adatrekordot (olvasásra sem). - Megosztott zárolás (S): zárolás olvasásra. Ugyanarra a rekordra több olvasási zár is helyezhető (de írási nem). Mivel egy dialógust több processz vihet végbe, ezért aktuális processz mindig megkapja a kihelyezett zárakat is (a kontextust azaz az external session állapotadatai között). A zárakat az update processzek távolítják el.

5.8.4.3. Background batch process A programok futtatása történhet a háttérben is, ilyenkor nem DIA, hanem BTC workprocess-ek dolgozzák fel a programot. Ennek előnyei: - A hosszú programok (tipikusan report) futása nem foglalja le a DIA workprocesseket, így a többi felhasználó tudja folytatni munkáját. - A háttérben futó programok futását lehet ütemezni, például éjszakára, vagy akár naponta automatikusan. - A háttérben futó programok nem igényelnek interakciót, így a kliens számítógépet ki lehet kapcsolni, a program mégis tovább fut.

5.8.4.4. Spool process A spool workprocess-ek a nyomtatásért felelősek. A DIA vagy BTC workprocess-ektől kapják a nyomtatandó adatot, majd ezt ideiglenes fájlokba mentik, sorba állítják, és a konfigurációnak megfelelően kérésre vagy azonnal kinyomtatják.

5.9. INTERFÉSZ TECHNIKÁK Nagy cégek több különböző, de egymással szoros kapcsolatban álló rendszert használnak. Ezek interfészeken keresztül kommunikálnak egymással, cserélnek adatot. Egy interfész általában több rétegből áll, melyek egymásnak szolgáltatást nyújtanak. Két csoportot különböztetünk meg: alkalmi és állandó interfészek.

5.9.1. Alkalmi interfészek Ritkán alkalmazott, de nagy mennyiségű adat átvitelére használatos (pl. adatbázis feltöltés). Létrehozásukat segíti a Data Transfer Workbench és a Legacy System Migration Workbench. Megvalósítása szekvenciális fájlokkal történik, melyeket az alábbi standard módszerekkel dolgozhatunk fel. (Megjegyezzük, hogy az állandó interfész is használható alkalmi adatok bevitelére.)

127 / 136


Direct Input (DI) Az input file adatait a DI modul speciális függvényei (nem mySAP tranzakciók) dolgozzák fel. Ezeket a függvényeket az SAP készítette el adatfeltöltési célokra. (Sajnos nem minden adatkörhöz áll rendelkezésre ilyen DI függvény.) A függvények az átadott adatokat részben ellenőrzik csak, a „rendes” képernyős tranzakciók jóval teljesebb ellenőrzést végeznek. A hibákat kivételkezelő rutinokkal dolgozzák fel. Az adatfeltöltés lépései: - ellenőrzés, vizsgálat - az adatok beírása a megfelelő táblákba. Ez a leggyorsabb adatbeviteli mód. Az adatok beírása tehát néhány vizsgálat után közvetlenül a táblákba történik, ezért igen veszélyes, viszont gyors. Veszélyessége és a számítógépek sebességének megnövekedése miatt ma már nemigen használják.

Call Transaction (CT) A feldolgozás tranzakció-hívásokkal gondoskodnia:

történik,

hibakezelésről

a

programozónak

kell

- az input file adatai egy szabványos átmeneti táblába kerülnek - a táblából a „call transaction” ABAP/4 parancsra induló tranzakciók az adatokat az adatbázisba írják. Mindez úgy történik, mintha egy „virtuális felhasználó” szépen végiglépkedne a tranzakció képernyőin, beírná a mezőbe a megfelelő adatokat, majd megnyomná a megfelelő gombokat. (Ami azt illeti, az említett átmeneti tábla is pontosan ilyen formában, mezőnként tartalmazza az adatokat.) Nincs felügyelet! Egyszerre egy bejegyzést tudunk így felvenni.

Batch Input (BI) Szabványos mySAP tranzakciót használunk, és a feldolgozás kötegelve zajlik ún. szakaszonként: - az input file adatai egy szabványos átmeneti táblába kerülnek, - a feldolgozó ágens megnyit egy szakaszt (session), majd a rendszer a táblából kitölti a képernyőmezőket, pont úgy, mintha azt a felhasználó kézzel vitte volna be. A felhasználónak csak az entert kell nyomogatnia, vagy az egész feltöltés futtatható a háttérben automatikusan, - a szakasz adatait szabványos mySAP tranzakciók - melyeket a programozó határoz meg - az adatbázisba írják. A batch input lényegében a Call Transaction módszerre épül, viszont itt a batch bevitel ellenőrzését, felügyeletét az SM35 tranzakció ellátja, a programozónak nem kell hibakezeléssel foglalkoznia. Automatikusan gondoskodik több bejegyzés egymás utáni felvételéről.

5.9.2. Állandó interfészek Sok alkalmazás állandóan kommunikál egymással, de kevesebb adatot forgalmaznak. Az ilyen, alkalmazások közötti közvetlen adatcserére gyakran az ALE rövidítéssel hivatkoznak (Application Link Enabling). Egy új ALE kapcsolat esetében az alábbiakat kell tisztázni: Honnan származik az adat, melyik a célrendszer, és mi maga az adat illetve a folyamat? Milyen gyakorisággal történjen az adatok átküldése? A kommunikáció időzítése: - szinkron: A forrásrendszer tranzakciója megáll és vár, amíg a célrendszer feldolgozza az adatot és válaszol.

128 / 136

Vállalati Információs Rendszerek BSc - aszinkron: A forrásrendszer tranzakciója nem vár, az összes adatot elküldi, vagy csak összegyűjti és azonnal tovább fut. A kommunikációs csatorna: - CPI-C - RFC - HTTP(S) - SMTP A kommunikációhoz használt adatformátum: - Q-API - BAPI - IDoc - EDI - XML (nem részletezzük, mert jól ismert).

CPI-C (Common Programming Interface Communication) Programok közti kommunikációt valósít meg belső átjárón keresztül. Működése: - kommunikáció telepítése - félduplex adatcsere (az első meghatalmazást a hívó fél küldi) - szükség esetén kódkonverzió (ASCII-EBCDIC) - lezárás. A protokoll támogatja a szinkron és aszinkron kapcsolatot is. Ez biztosítja, hogy külső, C-ben írt programból is elérjük az SAP-t (API). Főleg az R/2 rendszerben használták, mert az még nem támogatta az RPC-t, RFC-t. Hálozati protokollja: TCP/IP, LU6.2. RFC, RPC (Remote Function Call) = Távoli eljáráshívás Jellemzői: - Valódi program-program kommunikációt valósít meg, nemcsak fájl alapon. - Elfedi a felhasználó elől a CPI-C hívásokat. - Automatikusan konvertálja az egyszerű ABAP adattípusokat a külső formára (nemcsak kódkonverziót végez, hanem pl. a bináris egészeket is konvertálja) - Az SAP-ban létrehozott funkciós modulok esetében egy flag bejelölésével szabályozhatjuk, hogy azokat RFC segítségével kívülről meg lehessen-e hívni. (A bejelölés az egyik előfeltétele annak, hogy a funkció meghívható legyen web szolgáltatásként is.) Komponensei: - SAP Assistant: Windows alkalmazásokhoz - RFC generátor: C v. Basic kódot generál - RFC könyvtár Kommunikáció típusai: - szinkron - aszinkron - tranzakció alapú aszinkron: mindkét oldalon biztosítja az adatok konzisztenciáját. Q-API (Queued Application Programming Interface) Az adatok tényleges - automatikus v. kézi - kiküldésük előtt várakozósorba kerülnek. Ebből a sorból RFC vagy CPI-C hívásokkal kerülnek át a fogadó rendszerbe. Aszinkron kapcsolatban használják, ha a két kommunikáló rendszer nem érhető el egyszerre. BAPI (Business Application Programming Interface) Az SAP adataihoz üzleti objektumokon keresztül (pl. vevői megrendelés) férünk hozzá, szabványos, platformfüggetlen függvényekkel. Az RFC-re épül, megvalósítását tekintve szintén 129 / 136

Vállalati Információs Rendszerek BSc funkciós modulokból áll. Különbség az RFC-hez képest, hogy objektum-orientált szemlélettel rendelkezik, s így nem csak technikailag, hanem egyben üzletileg is definiálja az átvitelt. A rendszerben a BAPI tranzakciókód segítségével érhetjük el a Business Object Repository-t, ahol ezek az objektumok definiálva vannak. A programozónak csak a függvény interfészdefinicióját kell ismernie (be/kimenő adatok, kivételkezelés).

IDOC (Intermediate Document) Az SAP által szabványosított dokumentumformátum. Felépítése: - vezérlőrekord: tartalmazza az IDOC típusát, az üzenet típusát, az IDOC küldőjét, fogadóját - státusz rekord: a feldolgozás eddigi élettörténete, állapota (pl. 30-IDOC kiszállításra kész) - adatszegmensek: minden szegmensnek van: fejléce, amely a szegmens adatait írja le törzse, amely az adatokat tartalmazza EDI (Electronic Data Interchange) Csak fájlokat tud fogadni, tipikusan IDOC-ot. Az adott elektronikus adatfeldolgozó a saját formátumára alakítja az IDOC tartalmát és ezt továbbítja a partner rendszerhez. Általában különböző vállalatok közötti adatcserére használják, pl. számlák elektronikus formában történő átküldése.

5.10. A MYSAP ERP TULAJDONSÁGAI 1., 1980-as évek technológiája: Ügyfél – kiszolgáló (szerver – kliens) architektúra integrált modell alapján készült. Alapjaiban nem objektum-orientált, üzleti objektumokról van szó. (Az újabb fejlesztések és a JAVA persze igen.) 2., Háromrétegű modellt feltételezve íródott: Az ügyfélre nem bíz sok feladatot: Az alkalmazásszerver(ek) elosztott mainframe-ként viselkednek, és funkcióhívásokkal elégíti ki az ügyfél kéréseit. 3., Nem elég rugalmas. Az üzleti folyamatok és funkciók erősen központosítottak, ami nem felel meg mindenkinek. (Pl. a struktúra nem változtatható olyan gyorsan, amilyen gyorsan a cég változik ) Támogatja a központi ellenőrzést, de az eltérő módon üzemelő üzleti egységeket nem eléggé. A megoldás a SAP ALE (Application Link Enabling): meghívhatók külső folyamatok, de azonos adatbázisra. 4., Nagyon bonyolult. Telepítés, felparaméterezés, változások átvezetése, bevezetése miatt.

130 / 136


6. A QAD ENTERPRISE APPLICATION VÁLLALATIRÁNYÍTÁSI RENDSZER A QAD Enterprise Application (a továbbiakban QAD EA, korábbi verziók neve MFG/PRO volt) többféle UNIX és Windows alapú operációs rendszer alatt futtatható, a Progress adatbázis-kezelő rendszerre épített integrált vállalatirányítási rendszer. Egyedi és nagysorozatú termékek gyártásával (és kereskedésével) foglalkozó vállalkozások számára fejlesztették. Fontosabb funkciói három témakörbe rendeződnek: logisztika, gyártás, pénzügy. A rendszer ügyfélkiszolgáló (kliens-szerver) architektúrájú, mely az installációtól függően több szinten is megvalósítható. A rendszer négy rétegű installációját a 6.1. ábra szemlélteti.

ÜGYFÉL

.NET környezet vagy Webes böngésző

MEGJELENÍTÉSI SZERVER

Tomcat WebSpeed Progress Admin Server

ALKALMAZÁS SZERVER

QAD 2008 SE Application Code

ADATBÁZIS SZERVER

Progress RDBMS (OpenEdge 10.1b) QAD 2008 SE Database

6.1. ábra. QAD EA rendszer négy rétegű installációja Az ügyfelek terminálok, terminálemulátorok, Windows alkalmazások (DDE támogatással), böngészők illetve .Net webes felületek lehetnek. Egy web alapú ügyfelet a Tomcat szerver szolgál ki. A Tomcat alatt helyezkedik el a WebSpeed szerver, ami átjáróként működik az alkalmazási réteg és a Tomcat között: oda-vissza elvégzi a szükséges átalakításokat a web alapú kliens és a Progress alapú alkalmazás között. A 6.2. részletező ábrán látható, hogy a WebSpeed szerveren kap helyet a kéréseket fogadó és továbbító Broker, a kapcsolatokat támogató NameServer (IP cím helyett név alapú a kommunikáció), valamint a feldolgozást végző Agent Processes (ügynök folyamatok). A WebSpeed szervert a Progress AdminServer felügyeli és irányítja.

131 / 136


6.2. ábra. QAD EA részletes architektúrája A QAD EA alkalmazási rétege a QAD 2008 SE Application Code. A felhasználók által használt adatok Progress (vagy Oracle) adatbázisban tárolódnak, ez alkotja a rendszer architektúrális szerkezetének legalsó szintjét. A webes kliens és az alkalmazás szerver közötti kapcsolatok telnet alapúak. A kliens minden munkafelülete egy-egy önálló kapcsolattal rendelkezik az alkalmazás felé. A kapcsolatokat az alkalmazás szerveren futó Telnet Server biztosítja. A .NET környezetben működő ügyfél ugyancsak webes alapú, de a kliens kezelőjének sokkal magasabb szintű szolgáltatásokat nyújt. Elvi működése hasonló az egyszerű webes klienst kiszolgáló rendszer működéséhez. Nagyon nagy szervezetek esetén terhelésmegosztás céljából ajánlott az adatbázis réteg és az alkalmazás réteg különálló szerverekre való telepítése. Közepes (esetleg nem túl nagy) méretű vállalatok esetén az alsó két réteg összevonható, telepíthető egy szerverre anélkül, hogy a válaszidők jelentősen nagyok lennének. A programkörnyezet és az adatbázis-kezelő által létrehozott együttes terhelést ugyanis részben ellensúlyozza a gyorsabb adatbázis hozzáférés (pl. MRP futása alatt). Egy adatbázishoz több programkörnyezet (több QAD 2008 SE Application Code) rendelhető, illetve egy környezet alá akár több adatbázis is. (A laboratóriumi gyakorlatok alatt például két adatbázist használunk párhuzamosan egy alkalmazás rétegből.) Az alkalmazás réteg tehát adatbázis független, a bejelentkezéskor választható ki a használni kívánt adatbázis. A Progress képességeit kihasználva a rendszer telepíthető úgy is, hogy a logikai adatbázis két vagy több, fizikailag távollévő szerveren helyezkedik el a vállalat különböző telephelyein.

132 / 136

Vállalati Információs Rendszerek BSc Egy adatbázisban több domain definiálható. Ennek megfelelően vannak domain függő és domain független adatok egy adatbázisban. Domain független adatok a feldolgozó programok, a rendszerkonfigurációs adatok, valamint a felhasználók táblája. Domain függő adatok a törzsadatok és a tranzakciós adatok (ezek definícióját lásd lejjebb), ezért egy adatbázisba több, hasonlóan működő (sok közös programot használó) vállalat építhető fel. Egy vállalat önálló, a törvényes előírások értelmében működő, zárt mérleget készítő jogi egység. A QAD Enterprise Application konkrét futtatható változata a rendszerben előre definiált vállalati modellből vezethető le. A futtatható változat létrehozásához meg kell határozni a konkrét vállalat adatmodelljét, a QAD Enterprise Application-t ennek megfelelően konfigurálni kell, és be kell állítani a szükséges rendszerfunkciókat is. Ezt követően tekinthető a QAD Enterprise Application az alkalmazó vállalat adat és működési modelljének, mellyel szimuláció és vállalatirányítás végezhető.

133 / 136


7. RENDSZERINTEGRÁCIÓ Az információintegrációs rendszereknek a fő feladata általában egy nagyobb szervezet, például egy vállalat információforrásainak egységes keretbe foglalása. Igény, hogy fel tudja dolgozni az adatokat, és képes legyen új adatokat szolgáltatni az alkalmazások igényeinek kielégítésére. Legacy rendszer (örökölt rendszer): meglévő, gyakran önálló szigetrendszerek.

7.1. Az integrációs kényszer kialakulása 1. Egy információ, egy tudás megszerzéséhez az adatok több különböző rendszerben állnak rendelkezésre. 2. Ugyanazt az adatot több rendszerben is nyilvántartják

Konzisztens adattárolás nehéz feladat. Eltérés esetén melyik a helyes? Félmegoldás (mert a fenti 1. problémára nem megoldás): A 7.1. ábrán látható köztes réteggel biztosítható az adatok azonossága.

ABAS ERP CÉG 1 törzsadatok

ABAS ERP CÉG 2 törzsadatok

Törzsadatok karbantartása

7.1. ábra A kétrétegű architektúrák határvonalai Az integráció során ezekre a problémákra keresünk olyan megoldást, amely (újra-)hasznosítja a már meglévő adatokat és alkalmazásokat. Ahhoz, hogy az integráció sikeres legyen, érdemes lehet egy kicsit magasabb szinten vizsgálni, hogy milyen adataink vannak és ezek milyen struktúrában tárolódnak. Ezáltal lehetségessé válik, hogy meghatározzunk egy egységes struktúrát az adatok összessége számára.

7.2. Fizikai összeépítés 1. Adatbázisokat integráljuk, az alkalmazásokat erre csak felkészítjük, ezeket csak „igazítjuk”, ahogyan ez a 7.2. ábra szemlélteti. Előny: a konzisztencia megőrződik.

7.2. ábra Adatbázis-integráció

134 / 136

Vállalati Információs Rendszerek BSc 2. Alkalmazásokat és az adatbázisokat összeépítjük Adatbázis konzisztens (lásd 7.3. ábrát), de minden adatot kezelni kell tudni, még akkor is, ha ezekre nincs szükség.

7.3. ábra Adatbázisok és alkalmazások összeépítése

Értékelés: Mindkettő egy „ad hoc” integráció, mivel a módszer nem általánosítható. Később ismét szükség lehet újabb integrációra, amit ismét az adott rendszerek sajátosságai alapján lehet végrehajtani. Ez hosszútávon nem oldja meg a problémákat, mert nem ad útmutatást arra nézve, hogy a következőnek felmerülő integrációs problémát hogyan lehet megoldani. Magas a költség és a kockázat az implementáció során. 3. Adattárház Új, egyesített adatbázist hozunk létre, lásd 7.4. ábrát. (Szándékos duplikálás! Frissítés időközönként.) Ez a megoldás lehetővé teszi az adatokban rejlő összes információ lekérését, elérését.

7.4. ábra Adattárház működésének alapelve KÁB – Köztes SW: Kivon Extract Átalakít Transform Betölt Load

Működés: Az alkalmazások saját adatbázisukat folyamatosan frissítik, de a köztes szoftver csak időnként frissíti a származtatott adatbázist: • Kiolvassa, • Átalakítja,  • Feleslegeseket eldobja,  adattisztítás • Ellenőrzi az előírt konzisztenciát,  • Beírja a megtisztított adatokat új szerkezetben az új adatbázisba A tisztítás során keletkezett hibákról az adatbázis gazdáit tájékoztatja. Eredmény: Adatokat szolgáltat elemzéshez. A rendszer az elemzés végrehajtásához kiegészül adatbányászati eszközökkel és ad hoc lekérdezés-generáló eszközökkel. (Az architektúra skálázhatósága legnagyobb részben azon múlik, hogy a származtatott adatbázis mennyire skálázható.)

135 / 136


7.3. Alkalmazásintegráció Jellemzői (lásd a 7.5. ábrát): • • • • •

A felhasználó felé egységes felületet nyújt. Köztes rétegre van szükség, ami az integrációs logikát tartalmazza. Adatbázis módosítására nincs szükség, csak alkalmazások (kismértékű) módosítására. Jól skálázható architektúra. A köztes SW folyamatokat kezel.

7.5. ábra Alkalmazásintegráció

Működése: Kliens felől kérés érkezik. Bróker átalakítja a kérést, az előre definiált munkafolyamat szerint eljuttatja az alkalmazás(ok)nak, mindegyiknek előírja, mit kell tennie. (A brókernek okosnak kell lennie.) A bróker a válaszokat feldolgozza, tovább küldi a következő alkalmazásnak az előre definiált logika szerint, vagy visszaküldi a kliensnek. Alkalmazások jelzik adatbázisuk megváltozását a brókernek, és az a többi alkalmazásnak a kapott jelzést – átalakítás után – továbbítja. => Konzisztens adatbázis. Pl. WebSphere Business Integration Message Broker (BPEL: Business Process Execution Language) BEA WebLogic Intergation

7.4. Szemantikával bővített vállalati alkalmazások integrációja EAI – Semantically enriched Enterprise Application Integration. Több európai projekt kutatja (pl FUSION, lásd www.fusionweb.org). Felhasználják a szolgáltatásorientált architektúra logikáját, a szemantikus web eszközeit, és továbbfejlesztik ezek alapgondolatát.

136 / 136

Vállalati Információs Rendszerek Szakirány

Recommend Documents