Kereskedelmi Rendszer 2007 nevű számítógépes rendszer áttekintő bemutatása

Kereskedelmi Rendszer 2007 2007 nevű számítógépes rendszer áttekintő bemutatása

Multiszolg Bt. Szentes +36/30/535-1142 www.multiszolg.hu [email protected]

1.1.

A célközönség bemutatása A program funkcióinak kidolgozása során alapkövetelményeket és felhasználói terü-

lettől függő követelményeket lehet feltárni. Az alapkövetelmények minden területen igényelt funkciókat foglalnak magukban, mint például a rugalmasság, a könnyű használhatóság, az átláthatóság és a hálózaton keresztüli elérhetőség. Egyre több helyen az interneten keresztüli elérhetőség is szóba jön. A felhasználói területtől függő követelmények vizsgálatakor öt egymástól jól elkülöníthető felhasználói terület merül fel. Az első felhasználói terület a bolti kiskereskedelmi tevékenységet folytató vállalkozások köre, amelyek jellemzően egy vagy több számítógépen használnak információs rendszert, felmerülhet a céghez tartozó több bolt közötti állandó kommunikáció igénye is. Fontos igény a szerződött vevői partnerek szállítólevélen történő kiszolgálása és elszámolási időszak végén a tételek összevont számlázása. Előfordul bizományosi értékesítő partner kezelése, készlet kihelyezés és annak rendszeres elszámolása és végelszámolása. A bolti kiskereskedelemben egyre jobban előtérbe kerül a vonalkódos termék azonosítás lehetősége. Sok esetben igényként merül fel a pénztárgép számítógépes rendszerhez kapcsolásának lehetősége. A másik nagy felhasználói csoportot a nagykereskedelmi vállalkozások körében találjuk meg. Ennél a vállalkozási formánál az ügynök kezelés és forgalmi jutalék elszámolás árbevétel vagy realizált hasznon alapján a fontosabb követelmény. Szükséges lehet a pénztár nyilvántartás, pénztár bizonylat és pénztárnapló készítés. A nagykereskedelmi tevékenységgel párhuzamosan folytatott kiskereskedelmi tevékenység esetén azok teljes elválasztása szükséges. Itt már egyre nagyobb igény jelentkezik a jól kidolgozott vezetői információs szolgáltatásra. Fontos lehet még a kommunikáció a vevőkkel interneten keresztül: adott ajánlatok, viszszaigazolások e-mail formában, továbbá állandó internetes adatszolgáltatás a vevők részére: eladási árak, készleten levőség jelzése, valamint részletes partner nyilvántartás igénye is megjelenik. A harmadik területet a gyártással és értékesítéssel is foglalkozó vállalkozás nyújtja ahol a fentieken túl az egyszerű (egyszintű) anyagszükséglet és műveleti utasítás karton kezelésére van szükség. Igény lehet továbbá az értékesítés és a gyártás közötti jól szervezett automatikus kommunikáció igénye: pl. a boltok automatikus jelentése a napi forgalomról. Egyedi kiszolgálandó terület még a rendszeres szolgáltatást és folyamatos számlázást végző vállalkozások köre. Itt a havonta, negyedévente vagy évente ismétlődő állandó díj mellett készülő számlák kezelésének igénye tér el az előzőkben tárgyaltaktól. Követelmény még a partner nyilvántartás kiegészítése szerződés nyilvántartással, egyszerű (esetleg beavatkozás mentes) számla készítés a szerződésekre támaszkodva. -2-

Az utolsó terület a projekt irányítással működő és beruházással foglalkozó vállalkozások területe. Ebben a körben az árajánlat készítéstől a végszámlázásig zártrendszerű folyamat kezelés szükséges. A vezetői információs rendszer kiegészítését igénylik a felhasználók, úgy hogy a pénzügyi folyamatokat projektenként is láthatóvá lehessen tenni. A pénzügyi tervezést kiegészítő Cash-Flow kimutatás is szükséges lehet, amely vállalkozás és projekt szinten is megmutatja, hogy a folyamatok hogyan befolyásolják a vállalkozás erőforrásait.

1.2.

A program funkciói, további tervezési alapelvek A program a következő fő funkciókkal kell, hogy rendelkezzen a fenti vállalkozás faj-

ták igényeinek teljes kielégítése érdekében: ●

Partner nyilvántartás: beszállítók és vevők nyilvántartása, munkatársak nyilvántartása, partner csoportok kezelése, levelezési lista kezelése, beszállítói ISO minősítési rendszer kezelése, partnerfüggő kedvezmények kezelése

●

Termék nyilvántartás: besorolás törzs kezelése (VTSZ, SZJ számok), Egységárak kezelése, Fajta csoportosítás lehetősége,

●

Raktár kezelés: kapcsolódó raktárak / telephelyek kezelése, mozgásnem törzs, bevét és kiadás valamint raktárak közötti mozgások kezelése, raktármozgás bizonylatok kezelése.

●

Bizonylatok kezelése (értékesítés): Számlák, szállító levelek, nyugta kísérő feljegyzések, bizományosi átadó listák készítése és kezelése

●

Pénzügyi és pénztár kezelés: pénzeszköz törzs, bank és pénztár mozgások rögzítése és kezelése, pénztár bizonylatok létrehozása, pénztár napló kezelés, vevői számlanyilvántartás.

●

1.3.

Gyártás kezelés: gyártás szükséglet karton kezelése, gyártási művelet

A program technikai felépítése A megelőző programváltozatok tapasztalatai szerint a tervezés során a lehető legkeve-

sebb korlátot szabad a programba építeni. Így például az eladási árakat, a kezelt raktárak számát, mozgásnemeket korlátlan számúra terveztem. Továbbá a program úgynevezett modális ablakokkal működik. Ez lényegében azt jelenti, hogy egyszerre csak egy munkaablak lehet a képernyőn, pontosabban csak a legfelső ablakban lehet dolgozni. Az alatta lévő ablakok, csak a legfelső bezárását követően érhetők csak el. Jellemzője ennek a programozás módnak, hogy egyszerű és átlátható használatot kínál.

-3-

1.3.1. PostGreSQL Szerverről A Kereskedelmi Rendszer 2007 program a PostGreSQL szerverre épített adatbázissal kerül forgalomba. A PostGreSQL szerver üzleti felhasználás esetén is ingyenesen használható klasszikus BSD (nyílt-forráskód) licensz. A gyártó nyilatkozata szerint nem áll szándékunkban megváltoztatni a licenc formáját. Összehasonlítva más DBMS-ekkel: Számos nézőpontból lehet vizsgálni a szoftvert: képességek, teljesítmény megbízhatóság, támogatottság és ár. ●

Képességek: A PostgreSQL rendelkezik a nagy, kereskedelmi DBMS-ek képességeivel: tranzakciók, al-lekérdezések, triggerek, nézetek, külső kulcsok, integritás és kifinomult zármechanizmusok. Van néhány képessége, ami a kereskedelmi adatbázisokból hiányzik, mint például a felhasználó által definiált típusok, öröklődés, szabályok és verzió kontroll a zárolási viták redukálásáért.

●

Teljesítmény: A PostgreSQL teljesítménye hasonlít a kereskedelmi és más nyílt adatbázis szerverekéhez. Lehet bizonyos esetekben lassabb, másokban gyorsabb. A MySQL nevű tanuló RDBMS például gyorsabban hajt végre insert/update műveleteket, mivel a tranzakciókat elsumákolja. Persze a MySQL nem rendelkezik a képességek részben felsoroltak nagy részével.

●

Megbízhatóság: Ha egy DBMS nem megbízható, akkor teljesen haszontalan. A gyártó saját bevallása szerint igyekszik jól tesztelt, stabil kódot kiadni, amiben a lehető legkevesebb hiba van. Minden kiadás előtt eltelik legalább 1 hónap béta teszt, a kiadási verziótörténet is azt mutatja, hogy stabil kód került kiadásra, ami készen áll a produktív felhasználásra.

●

Támogatás: A postgresql.org levelezési listái kapcsolatot teremtenek a fejlesztők és felhasználók csoportjával, akik segítenek a problémák megoldásában. A fejlesztő csoport közvetlen elérési lehetősége, a közösség, a dokumentáció és a forráskód gyakran támogatást biztosít, mint más adatbázisoknál. Létezik kereskedelmi, alkalmi támogatás azoknak, akiknek szüksége van rá.

●

Ár: A PostgreSQL szabad bármilyen felhasználásra, akár kereskedelmire is. A termékhez hozzáadható a saját fejlesztésű forráskód is korlátozás nélkül.

(www.postgresql.org 2007) Összességében elmondható, hogy a PostgreSQL BSD licencelésű szerver a nagy hírű Oracle rendszerrel vetekszik képességeiben, egyébként nagy a technikai hasonlóság is a két rendszer között. Egyedül a támogatásban marad el a piaci értékesítésű rendszerektől, az ingyenes használat viszont kárpótolja a felhasználót ezért az egyetlen kellemetlenségért. A fejlesztett Kereskedelmi Rendszer 2007 már túljutott az előtesztelésen, jelenleg az éles tesztelés

-4-

keretén belül öt vállalkozás folyamatosan ezzel a rendszerrel támogatja az ügyvitelét. Az éles teszt eredményeinek birtokában kijelenthető, hogy nem csak a kliens program, de a PostgreSQL szerver rendszer is jól vizsgázott. 1.3.2. A kliens programról A kliens program a Borland Delphi 2006 V10.0 programmal készült. A lefordított kliens program Windows alatt futtatható. A kliensprogram mellé további kiegészítők nem kellenek, önmagában futtatható. Minimális rendszer követelmény: PIII 500Mhz, 128M RAM, CDROM. Operációs rendszer igény: Windows 2000, XP, Vista. 1.3.3. Helyi és internet elérésű használat Az adatbázis telepíthető egy internetre kapcsolt Linux szerverre, ilyenkor a kliensgép és a szerver között az internet világhálózat teremti meg a kapcsolatot. Ez esetben a kliensgép rendszerkövetelménye kiegészül a széles sávú internet kapcsolat meglétének szükségességével. A szerver üzemeltetéssel kapcsolatban megjegyzendő, hogy a már beüzemelt rendszerek egy részében felmerült felhasználói igény arra, hogy az általunk üzemeltetett szerveren tárolódjanak az éles adatok. A felhasználóknak így nem kell saját széles sávú internet eléréssel rendelkező szervert beállítani a feladat ellátására. Így lehetőség nyílik a program licenc értékesítésén túl egyfajta alkalmazásszolgáltatás nyújtásra is, amely a szolgáltató és szolgáltatást igénybe vevő fél számára is igen hasznos rendszeressége, tervezhetősége és nagyfokú adatbiztonsága miatt. Az adatbázis telepíthető a vállalkozás telephelyén vagy székhelyén elhelyezett Linux szerverre, ekkor a kliens programok a kiépített helyi hálózaton keresztül kapcsolódnak a helyi szerverhez. A szerver illeszthető internetre is, így a tulajdonos otthonról vagy az ügynökök a mobil számítógépükkel is csatlakozhatnak a rendszerhez. Az ilyen jellegű használat esetén a költséges szinkron üzemű internet kapcsolat javasolt.

1.4.

Vonatkozó törvényi szabályozás A program elkészítése során a általános forgalmi adóról szóló az 1992. évi LXXIV.

Törvény 13. paragrafusára, 24/1995. (XI. 22.) PM rendeletre, 8/1999. (III. 5.) PM rendeletre kell figyelemmel lenni. „A 24/1995. (XI. 22.) PM rendelet 1. § (6) bekezdés b) pontja számítógéppel előállított számla esetén a számla adóigazgatási azonosításra alkalmasságának feltételeként írja elő többek között azt, hogy a gépi program kihagyás vagy ismétlés nélkül biztosítsa a sorszámozást, és a másolatok alapján a hiánytalan elszámolást.” (2000/19. APEH iránymutatás) A számítógéppel előállított számla csak akkor tekinthető adóigazgatási azonosításra alkalmasnak, -5-

ha a bizonylat példánysorszámát, hasonlóan a számlasorszámhoz a gépi program biztosítja, de csakis akkor szükséges, ha a nyomtatás technikája révén a számla eredeti példánya nem különböztethető meg a másolati példányoktól (pl. lézernyomtatóval történő előállítás során). Amennyiben a nyomtatás során a számla alakilag hibás, beszorul a papír a nyomtatóban, vagy a szöveg nem olvasható stb. akkor sem engedhető meg, hogy az eredeti példányt még egyszer - ismételt előállítással – kinyomtassák. Fentiek alapján csak abban az esetben nem biztosítható a számlák gépi program által történő példány sorszámozása, amikor azokat több példányos, előnyomás nélküli leporellón készíti el a számítógépes program. Ezen számlák esetében a számlán azt kell feltüntetni, hogy a számla hány példányban készült. „A 24/1995. (XI. 22.) PM rendeletet módosító 8/1999. (III. 5.) PM rendelet 2. §-a alapján gépi számlázás alkalmazása esetén a program használójának (a számla kibocsátójának) rendelkeznie kell a számlázási programra vonatkozóan a szoftverkészítő által a felhasználó részére kiállított azon nyilatkozattal, mely szerint a program megfelel a vonatkozó jogszabályi előírásoknak. Rendelkeznie kell továbbá a szoftverkészítő által készített használati utasítással (felhasználói kézikönyvvel), mely tartalmazza a számlák kiállításának módját, az eredeti és másolati számlapéldányok kezelésének rendjét, a sorszámozás rendjét, a számlamásolatok készítésének módját, a helyesbítések, stornírozások lehetőségét, végrehajtását.” (1999/116. APEH iránymutatás). Tehát az értékesítésre készített program mellé nyilatkozatot és programleírást kell adni, vagy más módon elérhetővé tenni. Ezeket a felhasználó a számítógép közelében köteles tartani, és esetleges ellenőrzéskor átadni.

-6-

1.5.

Miben lehet jobb ez a program a versenytársakénál? Az internetes technológia alkalmazása még nem elterjedt a mikro és kisvállalkozások-

nak szánt programcsomagokban. Ez a program alkalmas lesz interneten keresztül a vállalkozás telephelyei és üzletkötői vagy akár partnerei között megosztani a rájuk vonatkozó információkat. Könnyen kialakítható a rendszer és a cég weboldala közötti adatkapcsolat. Az utóbbi tíz évben az ügyviteli szoftverek igen nagy fejlődésen mentek keresztül, a mikro és kisvállalkozásoknak szánt rendszerek pedig többnyire maradtak egyszerű készletkezelést végző számlázóprogramok. Ebben a programban igyekszem a vezetői információs szolgáltatásra helyezni a hangsúlyt, és mindezt úgy hogy a legkorszerűbb kommunikációs formákat alkalmazom. Továbbá a nagyrendszerekben alkalmazott módszerek mikro és kisvállalkozásra adaptált változatával igyekszem a program szolgáltatáskörét bővíteni. Mivel cégünk a tevékenységét mikrovállalkozási formában végzi, nagy rugalmasság és alacsony költséghányad jellemző rá. Ezért cégünknek lehetősége van a széleskörű integrált rendszerek bekerülési költségének töredékéért szolgáltatni. Cégünk létrehozott már egy-két olyan programcsomagot is, amely egy-egy szűk réteg piacot céloz. Ezeket a termékeket interneten keresztül országosan forgalmazzuk. Ilyen programunk pl. a Munkabiztonsági irodák részére készült programcsomag és a Végrehajtói Nyilvántartó rendszer. A Kereskedelmi Rendszer 2007 termékünkhöz hasonló jellegű programból – természetesen változó műszaki színvonalon – több száz is található a piacon. Így az értékesítését elsősorban a lokális piacon tervezzük, ahol viszont az segítheti az eladást, hogy helyben van a megoldás. A webtervezésben járatos kollégám segítségével kialakított professzionális dizájn segítségével igyekszem a stabil, bizalmat keltő rendszer benyomást erősíteni. Fontos tény, hogy termékértékesítés esetén a piac szereplői a termékhez társult kiegészítő szolgáltatások alapján is választanak. Ezért a programtermék mellé a vásárlástól számított egy évig tartó ingyenes segítségnyújtást társítunk. Ezzel egyúttal a termék használhatóságát is bizonyítjuk, csökkentjük az új belépők bizalmatlanságát. Ugyanezt a célt szolgálja az ingyenes demó verzió kipróbálásának lehetősége is. A demó verzió viszont nem nyomtathat hiteles számlát, az esetleges visszaélések elkerülése érdekében.

-7-

1.6.

Fejlesztési folyamat, adatbázis szervezés. Minden adatbázisra alapuló program lelke az adatbázis, amelynek létrehozása egy

többlépcsős átgondolt folyamat. Ezt a folyamatot a 11. ábra ismerteti. 1. ábra - Adatbázis életciklusa

Probléma megértése Egyed-kapcsolat modell felépítése Normalizálás Táblák létrehozása Fájlok szervezése, indexelés Lekérdezési terv elkészítése Képernyő tervezés Lista tervek és listák elkészítése

Tesztelés

Termék átadása Forrás: Szelezsán

Az adatbázis kialakítását a program egy részfunkciójának kialakításán mutatom be. A bemutatásra kerülő részfunkció a partner nyilvántartás. A partner nyilvántartás adattábláinak kialakítása a következő módon történt. Az első lépés a fejlesztés során a valós probléma pontos definiálása: a partnerek teljes részletességgel történő nyilvántartása a cél, amely az értékesítési – ezen belül az árképzési – rendszer megfelelő működéséhez szükséges teljes körű információt szolgáltatni képes. Továbbá alkalmas kell hogy legyen a korszerű partnerkapcsolati nyilvántartás (Customer Relationship Management) elvégzésére is.

-8-

A következő lépés a funkció adatszükségletének a nyilvántartásra alkalmas adatok körének meghatározása. Ebben az esetben ezek a következők: ●

partner név,

●

származási ország,

●

székhely cím, fax, email, telefon,

●

további címek (postacím, telephely, szállítási cím)

●

bank adatok (bankszámla vezető intézet neve, bank számla szám, swift kód, iban szám)

●

adószám, egyéb engedély számok (őstermelői szám, őstermelői regisztrációs szám, családi gazd. reg. száma, növényvédőszer felhasználásával kapcs. eng. szám, jövedéki eng. szám)

●

magánszemély esetén további adatok (születési név, születés helye és időpontja, anyja neve, TAJ száma, stb.) - ezek felvásárlói jegy kiállítása esetén szükségesek

●

üzletkötői adatok (üzletkötő, jutalék %)

●

fizetéssel kapcsolatos adatok (fizetésmód, jellemző fizetési határidő napban)

●

ISO beszállítói minősítéssel kapcsolatos adatok (minősítés, minősítő, beszállíthat-e)

●

tartozások kezeléséhez kapcsolódó információk (tartozás - szállítók és ki nem fizetett számlák, valamint lejárt tartozás – lejárt ki nem fizetett számlák)

●

csoportosítás (partner csoportok)

●

partnerekhez kapcsolódó kedvezmények

●

kapcsolattartó személyek adatai

●

internetes levelezési listák, stb. A fejlesztés következő lépése az adatok függőségeinek meghatározása, normalizálás és

kapcsolatok kialakítása. Normalizálás során induláskor egyetlen táblázatot alakítunk ki, amelyben minden szükséges tulajdonságot elhelyezünk. Ezt követően feltárjuk a táblázat belső szerkezetét, azaz meghatározzuk az oszlopok függőségi viszonyait, majd megvizsgáljuk, hogy a feltárt függősségek eleget tesznek-e azoknak a követelményeknek, melyeket normálformáknak nevezünk. A normálformákat megsértő függőségeket úgy szüntetjük meg, hogy a táblázatot egy meghatározott szabály szerint, több lépésben további táblázatokra bontjuk (Szelezsán). A jól tervezett adatbázisból egyszerűen készíthetők SQL lekérdezések, továbbá a lehető legkisebb helyszükségletre való törekvés is fontos szempont a kialakítás során. Az így kialakult partner nyilvántartás alapjául szolgáló adattábla rendszert a 12. ábra mutatja be.

-9-

2. ábra – A partner adattábla és ahhoz kapcsolódó táblák valamint kapcsolatai

Forrás: saját összeállítás

- 10 -

1.7.

A program fő funkcióinak leírása

1.7.1. Felhasználó kezelés A felhasználók jogosultságaik elkülönítése már a mikrovállalkozási közegben is szükségszerű követelmény az informatikai rendszerekben. A minőségbiztosítással nem rendelkező vállalkozások belső működési rendjét szabályozhatja és dolgozónként dokumentálja az egyes beavatkozási folyamatokat. A felhasználó kezelés részterület által a programban ellátott funkciók közül az elsődleges a felhasználók (munkatársak) kezelése, jelszók, felhasználói azonosítók nyilvántartása. Rendkívül fontos, hogy a programban végrehajtott beavatkozásokat felhasználókhoz tudjuk kötni, ez a szükséglet több területen is felmerül. Elsősorban a minőségbiztosítás területén szükséges a biztonsági naplózást végző felügyeleti rendszer működtetése, de például több bolti alkalmazott esetén a pénztár forgalom elkülönítését vagy a forgalom után számítandó jutalék kalkulálásban is segítségre lehet. A biztonsági rendszer használatával előre beállíthatók az egyes dolgozókhoz tartozó feladatok, mégpedig úgy hogy a nem szükséges vagy esetleg hatáskörön kívüli területeket (menüpontokat) a program a felhasználó függő menüpont hozzárendelésen (13. ábra) keresztül el is rejti. 3. ábra – Menüpontok beállítása felhasználónként


- 11 -

Az internetes rendszerek esetében különösen nagy hangsúlyt kell fektetni a biztonságra, mivel számítani kell az esetleges külső támadásokra is. Ezért az adatbázis szerverre történő bejelentkezést 64 bites kódolású jelszóval végzi a rendszer.

1.7.2. Általános törzsek kezelése Az általános törzsek a program működtetése során felhasznált – legtöbbször magától értetődő – adatokat tárolják. Ilyen törzs például a magyarországi települések és irányítószámaik jegyzéke vagy a szolgáltatások (SZJ) és a termékek (VTSZ) azonosítására szolgáló törzsek.

1.7.3. Egyes területekhez kapcsolódó törzsek kezelése A törzsek kialakítása még a program üzemszerű használata előtt célszerű, de persze a folyamatos karbantartásra is lehetőség nyílik. A törzsek gondoskodnak arról, hogy egy-egy dolgot ne kelljen többször leírni a programon belül, biztosítja továbbá hogy csak az előre meghatározott információ legyenek megadhatók. A törzsekben a működéssel kapcsolatos egyes tulajdonságok is definiálhatók, ami további könnyebbséget jelent a használat során. Ilyen törzsek például a következők: Fizetésmód törzs, Áfakulcs törzs, Kedvezmény törzs, Mennyiségi egység törzs, Üzletkötő, Mozgásnem.

1.7.4. Partner kezelés A partner kezelése jelenti egyrészt a partnerek (szállítók, vevők, saját vállalkozáson belüli telephelyek, bizományosi partnerek) adatainak strukturált tárolását. Jelenti továbbá a partnerekkel kapcsolatos előre definiálható eljárásrendszer működtetését. Ide tartozik a vásárláskori jellemző fizetésmód és fizetési határidő, ISO beszállítói minősítés használata esetén a beszállító minősítése, vásárláskor alkalmazható kedvezmény, kapcsolódó üzletkötő és jutalék, partnerenkénti tartozás kezelési rendszer adatai (tartozás, lejárt tartozás, engedélyezett kintlévőség). Az értékesítést végző rendszerekben a kedvezményrendszer kialakítása okozza a legnagyobb feladatot, mivel a leendő felhasználó vállalkozások mind-mind más elképzeléssel bírnak a kedvezmény rendszer kialakítással kapcsolatban. Kedvezmények alap változatai: fizetésmódtól függő kedvezmények, vásárlási volumentől függő kedvezmények, termék függő kedvezmények, egyedi kedvezmények. A jelen ügyviteli rendszerben többféle módon üzemeltethető kedvezmény rendszer került kialakításra. Az első módszer alapjául egy kedvezménytörzs szolgál, amelyben a kedvez- 12 -

mény százalékon és a kedvezmény elnevezésén túl megadható egy nettó limit összeg is, amely feletti éves vásárlási összeg elérését követően aktiválódhat. Továbbá megadható egy kapcsolt fizetésmód is, amellyel elérhető hogy egy kedvezmény pl. csak készpénzfizetés esetén legyen számításba véve. A második módszer a partnerenként, azon belül termékcsoportonként alkalmas a kedvezmény százalék vagy egységár meghatározására. A rendszer alapjául a korlátlan egységár kialakítás, valamint a partnerek intelligens csoportosítás szolgál. Az egységárak kezelése egy törzsön keresztül történik, a törzsben felvihető például „listaár”, „nagykerár”, „kiskerár”, „boltiár”, „nagykerár 2”, stb. ármegnevezés. A törzskarbantartással egy időben a tétel (termék) törzsben kitöltésre megjelennek a megfelelő névvel ellátott egységár mezők. Az egyes árfajták a későbbiekben képlet alapján automatikus értéket is kaphatnak, így kialakíthatók lesznek olyan egységárak amelyek egy másik egységártól (pl.: listaár * 80%), vagy egy belső számított értéktől (pl.: legnagyobb beszerzési ár * 110%) függhetnek. A partnerenkénti csoportosításra egy példát a 14. ábrán látható képernyőkép mutat. 4. ábra – Partner csoport példa


A fenti beállítás szerint az a vevő partner, aki a „Kedves vevő” csoportba kerül a következő árak mellett vásárolhat. A termékek mindegyikét az alapértelmezett egységáron kapja, viszont azokat a tételeket amelyek a „fajta 1” csoportosítási szempont szerint az „áruk” csoportba tartoznak a „Nagyker” egységár 100%-án kerülnek számlázásra. A „fajta 1” csoportosítási szempont szerint a „valami más” csoportba tartozó tételeket viszont az „Egységár” elnevezésű egységár 50%-án kapja meg a „Kedves vevő”.

- 13 -

A programba beépített kedvezményrendszerrel várhatóan akármely jövőbeli felhasználó már kialakított és sikerrel használt árképzési rendszere támogatható lesz. A kialakított árképzési rendszer a mikro és kisvállalkozásokban alkalmazott metódusokat követi, de az inkább nagykereskedelemben jellemző visszatérítési rendszer kezelését is támogatja. 1.7.5. Tételek kezelése A bizonylatokon feltűnő tételek kezelése lényegében a termékek és szolgáltatási tételek azonosítását, leírását valamint besorolását jelenti. A tételek besorolása lehet: Szolgáltatási tétel, Áru, Késztermék, Félkésztermék, Alapanyag, Mezőgazdasági termék, Göngyöleg, Közvetített szolgáltatási tétel. Ezek közül a szolgáltatás típusú tételek a többitől eltérő módon kezelendő, ezeknek nincs folyamatos készletnyilvántartása. Az előzőleg tárgyalt árképzéshez az itt beállítható „Akciós tétel” kapcsoló úgy illeszkedik, hogy az akciós tétel alapértelmezett egységárából már semmilyen körülmények között nem adható további kedvezmény. 5. ábra – Tételtörzs ablak példa


Megadhatók a tétel leírása során a következő információk (15. ábra): mennyiségi egység, Áfakulcs, vonalkód, kerekítés tizedes jegyei, garancia hónapokban, VTSZ/SZJ száma, maximum és minimum készlet, jellemző haszonkulcs, minimum haszonkulcs, kompenzációs felár. A kompenzációs felár a felvásárlási jegy kiállítása során használja a program.

- 14 -

Megadható továbbá az egy egységre vonatkozó súly, amely a rendelés összeállítás esetén használatos, korlátozott szállítási súlyhatár esetén. Az automatikus rendelés összeállítás esetén szükséges lehet a jellemző beszállító megadása, mivel a program ettől a szállítótól rendeli a terméket. Olyan vállalkozásnál, ahol a gyártóbeszállító pontgyűjtő kártya akcióval kívánja segíteni a kiskereskedelmi partnereinek forgalmazását, kártya olvasó eszközt kell üzemeltetni a kereskedelmi programmal együttműködve. Ilyenkor megadható az egy egység vásárlásáért járó pont mennyisége, más néven pont érték. Egyes termékek kizárólag engedély birtokában vásárolhatók vagy értékesíthetők tovább, ilyenek például a növényvédőszerek vagy a jövedéki termékek. Az ilyen termékeket mindenképpen meg kell jelölni, mivel mind a két esetben hatósági ellenőrzés esetén törvényben meghatározott formátumú forgalmi jelentéseket kell készíteni és bemutatni. A VPOP esetében a jövedéki termékek forgalmát időszakonként tételesen, vevőnként kell bemutatni. A listának tartalmaznia kell a partner nevét címét és jövedéki engedély számát is. Lényeges szempont, hogy a készlettel bíró vagy bármely forgalmi bizonylaton szereplő tétel törlését meg kell akadályoznia a programnak. Szükség lehet a tétel használatból történő kivételére, annak piacról történő kivezetése esetén, de mindeközben törlésre nem kerülhet. 1.7.6. Készlet kezelése A program szabadon definiálható raktárakon keresztül tartja nyilván a készletet. Egyedi látásmódot igényel, hogy a programban definiált raktárak egyben telephelyeket is jelölhetnek. Alkalmazható a telephely meghatározás például egy olyan vállalkozás esetében, amely több bolttal rendelkezik, ahol a boltok más-más helyrajzi számon és településen helyezkednek el. Más esetekben viszont kizárólag a raktár meghatározás illeszthető a bejegyzésre, amikor egy vállalkozás egy telephelyén több raktár is található, mint például fő raktár és selejt raktár. Fontos megjegyezni, hogy amennyiben a raktárat telephelyként is azonosítjuk és ebből a raktárból számla vagy más bizonylat készül el, akkor a bizonylat kiállító fejrészbe egyedi a telephely (raktár) definiálásakor megadott címadatok kerülnek. A raktárak típusuk szerint a következők lehetnek: Saját felügyeletű raktár (saját székhelyen vagy telephelyen található raktár), Mobil raktár (szintén saját felügyeletű raktár, amely saját használatban levő gépjárműn létesült), Bizományos raktár (közvetlenül nem saját felügyeletű és nem saját telephelyen üzemelő raktár, amely készlete viszont a vállalkozás készletei közé beszámítandó). Minden egyes mozgás – szintén szabadon definiálható – mozgásnemmel van ellátva a rendszeren belül. A mozgásnemek definiálása során a mozgás elnevezésén túl egy alapértelmezett forrás és egy alapértelmezett cél raktár kerül megadásra. A mozgásnem a megadott

- 15 -

forrás raktár készletét csökkenti és a cél raktár készletét növeli a mozgás megvalósulása során. A bevét típusú mozgásnemek esetén a forrás raktár, kiadás típusú mozgásnemek esetében pedig a cél raktár marad üresen. Az üres forrás vagy cél-raktár megjelölés egy a szervezeten kívüli raktárra utal (16. ábra). 6. ábra – Mozgásnem törzs ablak


A tényleges raktármozgás rögzítése az érintett partner, a mozgást leíró mozgásnem valamint a forrás és célraktárak megadásával kezdődik, továbbá a tételek felvitelével zárul. A rögzített raktármozgás során a rendszer egy raktármozgás bizonylatot készít. A bizonylat leírja a mozgásban résztvevőket és a mozgás körülményeit (dátumait) és az érintett tételeket. A raktármozgás bizonylat egy folyamatos számozású bizonylatszámmal van ellátva, valamint a raktármozgáshoz esetlegesen kapcsolódó főbizonylat száma is feltüntetésre kerül rajta (17. ábra).

- 16 -

7. ábra – Raktármozgás bizonylat minta


A készletkezeléshez tartozik még az egyes raktárak készletlistázás funkciója. Ez a funkció alkalmas különböző értékelésmódokat választva meghatározni a megadott elszámolás dátum alapján a készleten levő tételek listáját. A lista tartalmazza továbbá az értékelésmód szerint számított készlet értéket is. Az értékelési módok közül az átlagáras, a FIFO és a kiskeráras nyilvántartási formát választottam a programba, mivel a számviteli törvény ezeket és az elszámolóáras rendszert engedélyezi. A készlet kezelését a raktármozgások tételes listázása funkció teszi teljessé, amely alkalmas a mozgások termékenkénti nyomon követésére. A lista készítő ablak mindegyike részletes szűréssel és az elkészülő lista sorrendjének rugalmas meghatározásával egyszerűsíti a használatot. A kisebb programrendszerek jellemzően csak egy értékelési módot képesek egy időben alkalmazni. Az év végi készlet meghatározásánál viszont egy mikro vagy kisvállalkozásban szükség lehet a választható értékelési módok segítségével számított készletértékek összehasonlítására. Ezzel a programmal ez megvalósítható, így lehetőség nyílik az adózás szempontjából legelőnyösebb értékelési mód kiválasztására.

- 17 -

1.7.7. Bizonylatok kezelése Az értékesítés során a program bizonylatokat állít ki, a bizonylatok elkészítése mellett – ha szükséges – raktárbizonylat is készül a rendszerben. A raktárbizonylat gondoskodik az érintett raktárak készletének kezeléséről. A fő bizonylatok négy fő csoportba kerültek besorolásra a programon belül: 1.) nyugtakísérő bizonylat (Az áfa-törvény 43. § (1) bek. b) pont, 24/1995. (XI. 22.) PM rendelet szerint pénztárgép használatra kötelezett vállalkozások a számítógépes készletnyilvántartás mellett a nyugtaadási kötelezettséget csak pénztárgéppel teljesíthetik. A pénztárgéppel elkészített nyugta mellett a számítógépben – a tételenkénti készlet nyilvántartás folytatása érdekében – rögzítenie kell az eladott tételeket. A számítógépes program egy nyugtakísérő jegy elnevezésű nyomtatvány formájában jeleníti meg a termékek tételes jegyzékét, amelyet a vállalkozás tételes elszámolásként és jótállási jegyként alkalmazhat.) 2.) számla bizonylat (Az értékesített termékről a legtöbb esetben számla bizonylat kerül kiállításra, a számlán szükséges a vevő nevének, címének a feltüntetése, ezen adatok nélkül ugyanis a kiállított bizonylat nem felel meg a számlára vonatkozó jogszabályi követelményeknek.) 3.) szállító bizonylat (Szerződés vagy szóbeli megállapodás alapján egyes vállalkozások között az áru szállítás és a számlázás időpontja nem esik egybe. Ilyen esetekben az áru mozgásról elkészített szállító bizonylatok a megállapodás szerinti időszak lejártával együttesen kerülnek számlázásra. A készlet kezelése a szállító kiállításakor, az árbevétel elszámolás pedig a szállítókat összesítő számlázáskor történik meg.) 4.) bizományosi átadó bizonylat (A bizományos partnerünknek szállító levél formátumú bizonylaton adjuk át az árut. A bizományosi partnerrel későbbi elszámolásról köt a vállalkozás megállapodást. Az elszámolás időszakonként lejelentett értékesítési adatok alapján történik. Az elszámolás során a bizományosi átadó a bizományosi partner részére a lejelentett tételeket leszámlázza. A vállalkozás bizományosnál lévő készleteit a vállalkozás saját telephelyein tárolt készletekkel megegyezően legalább évente egyszer leltározni kell. A leltározás során a bizományos az összes terméket a vállalkozás birtokába adja vissza, az eltéréseket számla bizonylaton korrigálják a felek.)

- 18 -

1.7.8. Rendszeres számlák kezelése A rendszeres számlák kiállítását az un. folyamatos szolgáltatást végző vállalkozások preferálják. Ezek a vállalkozások – szerződéstől függő – időszakonként jellemzően havonta vagy negyedévente állítanak ki számlát, legtöbbször változatlan feltételekkel. A feltételeket a program egyfajta szerződés nyilvántartásban tárolja le, és ebből a szerződés nyilvántartásból automatikusan készíti el az időszaki számlákat. A szerződés nyilvántartása kiterjed a megállapodás kezdetére és végére valamint a felülvizsgálatának tervezett dátumára. Az érintett partner levelezési és számlázási címére, az időszakra (hónap, negyedév, stb. valamint előre vagy visszaszámlázás), fizetésmódra és időpontra, megjegyzésekre, záradékokra, a számlán feltüntetendő tételek egységáraira és egységeire (18. ábra). 8. ábra – Szerződés nyilvántartás ablak


A program a rendszeres számlákat a szerződésekben megadott paraméterek alapján intelligensen, közbeavatkozás nélkül készíti el. A számlázási folyamat a nyomtató sebességéhez szinkronizálható sebességgel működik, bármikor leállítható. A nyomtatási idő szinkronizálásra azért van szükség, mert a Windows alatti nyomtatások jellemzően a nyomtatásvezérlőn keresztül történnek, így a program nem értesülhet közvetlenül a nyomtató leállásáról. - 19 -

A rendszeres számlák készítését a legtöbb számlázással is foglalkozó program nem támogatja. Az ezzel a területtel foglalkozó programok általában egyedi programozás során előállt célrendszerek, amelyek általánosan forgalmazható dobozos termékként nem állíthatók ki. Ennek a programmodulnak a kialakításakor az általam ismert jellegzetes igényekre voltam tekintettel. A 2007-es évben várhatóan több rendszeres számlázást igénylő vállalkozásban kerül beüzemelésre a program. A beüzemelést megelőző előtesztelési folyamat során tervezem a modul finomhangolását. A finomhangolás során egyedileg választható beállításokkal lehet majd a program működést a vállalkozás kialakult ügymenetéhez igazítani.

1.7.9. Pénzügyi nyilvántartás A pénzügyi nyilvántartás kiterjed a vállalkozás gondozásában levő bankszámlák és pénztárak nyilvántartására. A bankszámlák és pénztárak egy külön törzsben definiálhatók. A pénztárak hozzárendelhetők egy telephelyhez, amelyen az üzemeltetésük megvalósul. Ez a készpénzes értékesítés esetén rendkívül fontos, mivel az eladás során azonnal befolyt készpénzt a program automatikusan könyveli a pénztárba. A hozzárendelés alapján tudja, hogy melyik pénztárban könyvelje a beérkezett árbevételt. Különös figyelmet igényelnek a vállalkozás pénzeszközei között megvalósuló mozgások, mint a bankszámla – bankszámla, a bankszámla – pénztár, a pénztár – bankszámla, valamint a pénztár – pénztár közötti mozgások. A pénzügyi nyilvántartás során a pénztárakat érintő pénzmozgások esetén bevételi és kiadási pénztár bizonylatot állít ki a program. A pénzeszköz mozgásokról pedig folyamatos naplót vezet, amely bármely időszakra esetleg érintett partner szűréssel is listázható. Ezen pénzügyi nyilvántartásnak és a kibocsátott számláknak az összevetéséből alakul ki a vevői számla nyilvántartás. A vevői számla nyilvántartás a megadott időszakban kiállított számlákat és a kiegyenlítések figyelembe vehető időszakát alapul véve határozza meg a vállalkozás kintlévőségét és lejárt kintlévőségét (19. ábra).

- 20 -

9. ábra – Vevői számlanyilvántartás ablak


A pénzügyi nyilvántartáson belül egy fontos kérdéssel kiemelten foglalkoztam a Kereskedelmi Rendszer 2007 kialakítása során, ez pedig a pénztárral kapcsolatos nyilvántartás. Ugyanis a mikrovállalkozások körében több módja használatos a pénztár nyilvántartásának. A pénztár kezelés legelterjedtebb módja az amikor a pénzmozgáskor azonnal pénztárbizonylat készül, és ezzel párhuzamosan a pénztárnapló is vezetésre kerül. Kisebb vállalkozások viszont előszeretettel alkalmazzák azt a megoldást, hogy a teljes napi készpénz bevételt egyetlen a nap végén kiállított pénztárbizonylaton tüntetik fel. Így a bizonylatolás és a könyvelés is egyszerűbbé válik, ez az analógia érvényesül például a bolti kiskereskedelemben működtetett pénztárgép zárásánál is. Ezt az egyszerűbb nyilvántartási módszert is képes a program megalapozni.

- 21 -

1.8.

Továbbfejlesztési lehetőségek A saját fejlesztésű Kereskedelmi Rendszerrel kapcsolatban számos továbbfejlesztési

elképzelés merülhet fel, ilyenek például a következők: Az előzetes célokban benne volt, de még nem valósult meg az egyszintű beépülési rendszerre épülő gyártási modul kialakítása, amely a beépülő termékek készlet rendezését a gyártási folyamaton belül automatikusan végzi. A gyártási modul kiegészíthető lenne egy az alapanyagok átlagos beszerzési idejét is figyelembe vevő gyártási irányítási programrésszel. Szükség lenne egy emberi beavatkozást csak ellenőrzés szinten igénylő rendelési rendszer kialakítására, amelyet gyártócégek esetén a gyártási irányítási rendszer vezérelne, értékesítésre szakosodott vállalkozások esetében pedig a termékenként meghatározott minimum és maximum készlet szintek szabályozhatnák. A fenti két funkciót egy egyszerűsített MRP rendszerrel össze lehetne fogni, mégpedig úgy hogy a gyártás tervezés alapján előállt anyagszükséglet és a megadott átlagos beszállítási idő alapján a megrendelések automatikusan készülhetnének el. A csak saját raktárakat érintő raktármozgások esetében felmerülhet a termék összekészítés során történt emberi tévedés vagy a szállítás során előállt szállítási veszteség kezelésének problémája. Ennek megoldására célszerű lehet az ilyen mozgások átalakítása, miszerint a két raktár között egy úgynevezett úton lévő raktár teremtsen közvetett kapcsolatot. Mindezt természetesen az úton lévő raktár rendszeres felügyelete mellett. A korunk marketing slágerének számító CRM rendszer lehető legjobb integrálása is távlati cél lehet, amely során a partnerekkel folytatott kommunikáció teljes körű naplózása lehetővé válna, valamint közvetlen körlevél (boríték címzés és/vagy címke nyomtatás) és kör-email küldő funkciók beépítése, előre gyártott sablonokkal lenne célszerű. A szállítói számla nyilvántartás kialakítása is szükséges lenne. Főleg azért, mert a szükséges információk feldolgozása már megtörténik a programban. A bevételezés során rögzítésre kerül a szállítói bizonylat minden adata, a pénztár és bankmozgások szintén rögzítésre kerülnek a programban. Egy összesítő lista hiányzik a ki nem fizetett és lejárt számlákról. A készletet nem érintő szállítói számlák rendszerbe kerüléséről kell csak gondoskodni a listázó helyes működése érdekében. A mikro vállalkozások esetében a könyvviteli rendszerekkel feladás formájában kellene a programnak kapcsolatot tartani, mivel az ilyen méretű vállalkozások legtöbbször külső könyvelő irodát bíznak meg a könyvelési munka elvégzésére alvállalkozásban. A könyvelő program piac már-már kevés résztvevősnek mondható, így a kereskedelmi rendszer néhány egyedi interfész segítségével a legtöbb vállalkozás választott könyvelő irodájának könyvviteli

- 22 -

rendszerével kapcsolatot teremthet. A kapcsolat teremtés az interfész jellegű kapcsolat miatt egyirányú kommunikációra szorítkozhat, ezen belül a kiállított számlák és a partnerjegyzék átadását jelentheti. A folyamatos fejlesztési tervemben benne van a deviza alapú és többnyelvű bizonylatok létrehozása is. Fontos megemlíteni, hogy többnyelvű bizonylatok hazánkban a belföldi forgalomban is szép számmal jelennek meg, elsősorban a telekommunikációban és az energiaszektorban érdekelt nagyszolgáltatóknál figyelhető meg ez a tendencia. Tervezem a program kiegészítését árajánlat készítő modullal, amelyből – elfogadás esetén – közvetlenül származtatható lehet szállítólevél vagy számla. Az elkészült ajánlat digitális formában is elküldhető lesz az ajánlatkérő részére. A modul alkalmas lesz a beérkezett árajánlatok értékelésére is. Leendő felhasználók előzetes igénye alapján rövid időn belül kialakításra kerül a programon belül egy „pro forma” és előleg számla elkészítését is lehetővé tevő kiegészítés. Mivel az adatbázis – jellemzően – egy állandó internetkapcsolattal rendelkező számítógépen van telepítve, kézenfekvő a vállalkozás weboldalának ugyanazon szerveren történő elhelyezése. Ilyen esetben minden adatkonverzió nélkül aktuális árjegyzék publikálható a cég weboldalán közvetlenül az SQL adatbázisra épülve. Lehetőség van részleges készlet információk közlésére is, mint például „jelenleg van készleten a szentesi boltunkban”. A vásárló partner biztonsági beléptetése után PHP webes programmal a partnereknek egyedi áras árjegyzéket is meg lehetne jeleníteni. A program mindenkori DEMÓ verziója a következő címen érhető el: http://letoltes.multiszolg.hu/kereskedelmi%20r.%202007/setup.exe A demó verzió a multiker.hu szerveren futó adatbázissal működik, ezért csak állandó internetes kapcsolat esetén működtethető.

- 23 -

Kereskedelmi Rendszer 2007 nevű számítógépes rendszer áttekintő bemutatása

Recommend Documents