Mennyiségi egység átváltás – hány helyen kell hozzányúlni?

Cégünk belekezdett a mennyiségi egység átváltásba. Korábban Axapta és Navision termékeket fejlesztő kollégák jelezték, hogy ezzel valóban nagyvállalativá válna a rendszer. Nem miattuk, de belekezdtünk ebbe a fejlesztésbe.

Alapvetés

Napokig gondolkoztunk rajta, hogy mit lehet vajon beállítani? Jöttek a jobbnál-jobb ötletek. Több mennyiségi egységet, ezek váltószámait, a bizonylaton való megjelenésüket. Majd pár nap múlva befutottak a kedvenc mondataim: “az jutott eszembe…“, már rosszul kezdődik.

A tervezett kiépítésben, amelyet a megrendelőink (de jó lenne, ha csak egy cégnek dolgoznánk! jó lenne?) elfogadnak, mennyiségi egységenként (kiszerelésenként) lehet megadni a tizedesek számát. A saroklécet lehet értékesíteni méterben, ilyenkor 1.45m eladható. Lehet értékesíteni szálban, ilyenkor 1.5 szál nem értékesíthető.

És eltérő ára lehet a szálnak és a méternek? A méter ár 1000Ft, a szál, amely 2.7m, 2400Ft most akciósan. “Ugye nem azt akarod mondani, hogy az akciók is különbözőek a mértékegységtől függően?” De, azt akarom mondani…

Megvalósítás

Symbol Ügyvitel rendszerünk minden félévben átesik egy olyan mértékű módosításon, amiből szeretnénk, ha a dobozos ügyfeleink nem vennének észre semmit. Ez is egy ilyen lesz. Sarkából kell kifordítanunk az árkezelést, a bizonylatok kinézetét, az akciókat, szerződéseket. Sőt még a vonalkód kezelést is, hiszen a lecsippantott vonalkód lehet egy szál vagy egy méteres darab is.

Egyelőre még szakmai homlokráncolás történik. Az üzleti oldal igényeit megpróbáljuk a lehető legkisebb kockázatú fejlesztési feladatokra bontani. A megrendelői igények csak minimálisan tudnak ehhez alkalmazkodni. Nekünk kell alkalmazkodni!

 

A számítógépes problémákról…

A régi mondás szerint: “A számítógéppel olyan problémák oldhatóak meg, amelyek számítógépek nélkül nem is léteznének.” Ez jutott nekem is eszembe akkor, amikor körbenéztünk, hogy mások hogy csinálják. Sejtettük, hogy sehogy, de hogy ennyire sehogy…

1. Vannak “rendszerek”, ahol a bizonylaton megjelenő mennyiségi egység állítható. De nincs mögötte készletkezelés. Hoppá, úgy könnyű!

2. Vannak rendszerek, ahol az értékesítés előtt az egyik mennyiségi egység alapján gyártani kell. 10m lécből gyártok egy másik terméket, amely 2 szál mennyiségben rendelkezésre áll és eladható.

Nos, a sokféle problémát megoldó rendszerünkben valóban komplex feladat a mennyiségi egység átváltását megvalósítani. Ezt a “problémát” magunknak okoztuk. De ennél nagyobb falattal is megbirkóztunk, most is sikerülni fog. Tervezetten 145 emberóra ráfordításon belül megpróbáljuk megoldani a feladatot, addig türelmüket kérjük!

Jól működik a vevőkeresés… Miről is beszélsz?

Egy pillanatra az jutott eszembe, hogy a gépek átveszik az irányítást. Öntudatukra ébrednek. A Symbol Ügyvitel ma elkezdett automatikusan gondolkodni, jól viselkedni.

Értékesítési vezetőnk jelezte, hogy milyen jó dolog a főképernyőn lévő jegyzetekben a vevőkre keresni. Mi is örültünk, de hirtelen nem tudtuk, hogy miről beszél. Kis gondolkodás után is kérdőn álltunk a pozitív visszajelzés előtt. Mi lehet ez? Vezető fejlesztőnk az automatizmusok mestere, de neki sem ugrott be, hogy miért került oda egy olyan funkció (véletlenül vagy szándékosan)

15 perc kellett hozzá: Minden többsoros beviteli mező menüje (jobb klikk) tartalmaz egy vevő kereső funkciót, hogy a szabadszövegekben is tudjunk keresni. Ez a főképernyőn lévő jegyzetekre is igaz, ott is megjelent és működik. Szuper!

Amellett döntöttünk, hogy továbbra is hagyjuk a rendszert “öntanulni”, úgy látszik, kellemes és hasznos dolgok születnek belőle.

Számlázó program vs. Ügyviteli rendszer

A kék sarokban a számlázó programok, a piros sarokban az ügyviteli rendszerek. Most, hogy a hölgyek kimentek a konyhába, beszélgessünk egy kicsit arról, hogy kinek mire van szüksége, melyik megoldás mire való. Célok, eszközök, használati módok. Dobozos körkép.

A gondolkodásmódon nem fogunk tudni változtatni, a csapból is ez folyik, számlázó programra mindenkinek szüksége van. Modern világban élünk, a technológia fejlődés is abba az irányba mutat, hogy dobjuk a kukába a kézi számlatömböt és a mozgó árusok is e-megoldásokat használjanak. De számlázó programot? Vagy komplett ügyviteli rendszert? Vagy ezeknek csak egy szeletét? De melyiknek van egyáltalán szelete?

 

Számlakiállító alkalmazások

Nem egyértelmű, de mégis létezik határvonal, amelynek egyik oldalán a számlázó programok állnak. A hozzáállás ugyanaz, mint a névjegykártya esetén. Kell, hogy legyen. Rajta legyen a nevem, az elérhetőségeim, nívós esetben a fényképem is. Számlázó program is kell, hogy legyen. Ahogy névjegykártyával illik azonosítani magunkat egy tárgyalás elején, ugyanúgy illik a megállapodás megkötésekor a gazdasági esemény megvalósulásakor számlát kiállítani. Gyorsan fogok egy számlatömböt számlázó programot, a lehető legkevesebb munkával (van Nálad bélyegző, hogy ne kelljen a cégnevet ráírni kézzel?) kiállítom azt a fránya bizonylatot. Jogszabályilag jó legyen, rajta legyen a bruttó, nívós esetben a céges logó. Ennyi számít.

Az ilyen alkalmazások könnyen használhatóak, kettőt-négyet kell kattintani és már jön is ki a fekete-fehér számla, lekerekített sarokkal, 8 éves dizájnnal. Kompromisszumokat kell kötni. Számlát csak stornózni lehet (de nem azért, mert a gazdasági esemény nem valósult meg, hanem mert elrontottam a tétel nevét és így nem fogadja be a vevő könyvelője), sok esetben nincs is vevőtörzs, elég minden alkalommal beírni a vevő adatait (név+cím pont elég), gyorsan kiválasztom a 8 napos átutalást és már mehet is. Ezek a hátrányok nem is hátrányok. Nincs is rájuk szükség. A nyomtatóból kijövő papír (7 hónap alatt ez már a 31. számlám!) a lényeg, no meg, hogy a pénz megérkezzen a bankszámlára. Ha nem így lenne, gyorsan telefonálok egyet…

Ügyviteli rendszer

Vannak olyan cégek, ahol nem csak számlázás folyik és nem a papír számít. Üzleti folyamatok vannak, sok vevővel, sok termékkel, kevés dolgozóval. Nem lehet fejben tartani mindent! Amint nem csak árulunk, hanem kereskedünk, a dolgok megváltoznak. Már nem csak az ismerősöknek állítok ki számlát, nem tudom két kezemen nyilvántartani a vevőimet, a kintlévőséget nem emlékezetből kell kezelnem. Erre valamilyen rendszer kell! Ez iránt el kell kötelezni magunkat. Innentől ez nem egy programocska, hanem egy eszköz (mint a kalapács) vagy egy új munkatárs (mint egy személyi asszisztens).

A kalapácsnak van egy helye, a polc. A személyi asszisztensnek van egy helye, íróasztalnak hívják. Az ügyviteli rendszernek van egy helye, szervernek hívják. Ettől a ponttól már nem “valamelyik” számítógépre telepítjük a programot, hanem a szerverre telepítjük a rendszert.

A készlet még nem ügyvitel, ugye?

De, a készletkezelés már ügyvitel. Van beérkező mennyiségem, el akarok adni valami, de nincs raktáron. Majd a rendszer szóljon, ha lesz annyi készleten. Ezek már folyamatok, ez már az ügyek vitele, azaz ügyvitel.

Akkor honnan számít ügyvitelnek?

A kérdés jó, de nehezem megválaszolható. Talán onnan érdemes megfogni a dolgot, hogy a cégvezető fejben tudja-e tartani a dolgokat? Emlékszik-e minden rendelésre, minden árubeérkezésre, minden terméket ismer és össze is tudja őket hasonlítani? Ha a válasz “nem” vagy “nem az én feladatom”, akkor szükség van ügyviteli rendszerre.

 

Mennyire legyen kihegyezve?

Ügyviteli rendszerből sok található a piacon. Ha már ügyviteli rendszer mellett döntünk, mert a cég ügyeinek vitele a cél, akkor ne kelljen a számlakiállító alkalmazásokhoz hasonló kompromisszumokat kötni! Ne fogadjuk el azokat a válaszokat, hogy a “Program ezt így tudja!” Válasszunk olyan rendszert, amely az üzleti folyamatok (beszerzés, értékesítés, gyártás, készlet-elemzés és -tervezés, stb.) nagy részét, egészét le tudja fedni. A Symbol Ügyvitel és nagyvállalati testvére a Symbol Enterprise a fenti folyamatok közel 100%-át megvalósítja.

Döntsön jól! A mai mérkőzésen az ügyviteli rendszer nyert, a következő összecsapáson a vállalatirányítási rendszerek és az ügyviteli rendszerek mérkőznek meg. A fogadóirodáknál – a tömeg elkerülése érdekében – tegye fel kérdéseit vagy töltse ki rendszerfelmérő adatlapunkat!

Symbol Connect – fejlesztés alatt

Cégünk LAB csoportja új feladatot kapott. Egy olyan biztonságos, ügyviteli célokat szolgáló speciális hálózati kapcsolatot kell tudnunk létrehozni, amely hatékony és kellően titkosított adatátvitelt tesz lehetővé országhatárokat átívelően is.

Ez egy egyedülálló biztonsági megoldás lesz a felhő alapú infrastruktúrákban megvalósuló kommunikációban, melyet először az ügyvitelben használunk fel a cégek érzékeny adatainak védelmére, illetve a telephelyek és mozgó munkahelyek (árusok, értékesítők) közötti titkos kommunikációra.

Ez a kommunikáció egyedisége és a matematikus kollégák szakmai tudása miatt biztonságosabb megoldást kínál mint az adatbázis szerverek és kliensek közötti elterjedt és sokak által ismert általános rejtjelezési eljárásoknál.

Index használata kötelező – nem csak sávváltáskor

Szabadságom derekán benéztem az irodába és azzal fogadtak, hogy a v1.94-es verzió lassú. De mi lehet a probléma, hány ügyfélnél jelentkezett, komoly-e a baj? Tanulságos volt az a 30 perc a fejlesztőknek.

Mik az indexek?

Az adatbázisban tárolt információk nagyon sokan vannak, hasonlóan egy könyvtárhoz. Az adatok/könyvek közti keresésben segítenek az indexek. Például Molnár Ferenc Pál utcai fiúk könyve egy rendes könyvtárban kétszer van indexelve. Az M betűnél, azon belül Molnár Ferencnél is megtalálható, emellett a P betűnél, Pál utcai fiúk jelölés alatt is megtalálható, közvetlenül a “Pakura készítése” és a “Pálinkafőzés” című könyvek között. (Attól most tekintsünk el, hogy a regény címe A betűvel kezdődik, ez annyira általános, hogy az indexekből ki is szokták hagyni).

Indexelni kötelező!

Minden adatbázis kell, hogy tartalmazzon indexeket, amelyek automatikusan jönnek létre vagy a programozó készíti őket, hogy az adatelérés gyorsabb legyen. Például az ABC Kft. tárgy havi számláinak lekérdezésében egy automatikus index (idegen kulcs a vevőre) és egy kézi index (dátum) segít. Indexek nélkül az összes számlát végig kellene nézni, hogy megtaláljuk a megfelelőket (full scan, nagyon rossz stratégia).

Rakjunk mindenre indexet!

Az indexek az adatbázisban tárolt adatok másolatai (minden adat kétszer szerepel), emiatt mindent indexelni nem célszerű. És ez a problémánkat nem is oldja meg! Az indexeket a rendszer csak akkor használja, ha értelme van (lásd lentebb). Intelligensek ezek a rendszerek!

Akkor mi volt a probléma?

Megszüntettünk egy egyedi (unique) indexet, de létrehoztuk helyette a négy (!!!) mezőjére vonatkozó indexeket. Gondoltuk, ezzel készen is vagyunk… De a régi index helyett létrehozott négy új nem ugyanazt a hatást váltotta ki. A négy indexből a rendszer csak kettőt használt (query plan), a többinek annyira kicsi volt az értékkészlete, hogy az adatbázis kezelő figyelem kívül hagyta őket.

Értékkészlet?

Egy indexszel gyorsított adatmező(k) előfordulási értékei lehetnek nagyon kicsik. A számlák tábla dátum mezője az első héten még csak 5 különböző értéket tartalmaz (ha szombat-vasárnap is állítunk ki számlát, akkor 7-et). Az adatbázis kezelő az ilyen kis variációjú indexekre azt mondja, hogy nincs értelme használni őket. Ha például kiállítunk 3 nap alatt 9000 számlát (ez persze csak egy példa), akkor minden dátumhoz 3000 számla fog tartozni. Az index nem sokat segít nekünk abban, hogy melyik számlák készültek ma, hiszen 3000 értéket fog visszaadni, az összes számla egy harmadát.

Mi lehet a megoldás?

A v1.94-es verzió hibáját azonnal javítottuk, de családommal nyaralás és bevásárlás közben is azon gondolkodtam, hogy akkor milyen indexeket kell létrehozni “úgy általában”. A programozás inkább hasonlít az orvoslásra, mint a marketingre, próbálkozni nem lehet, de mi most mégis ki fogunk választani 2-3 speciálisan előkészített adatbázist, hogy teszteket hajtsunk végre rajta.

Minden bizonnyal a megoldás az lesz, hogy a leggyakoribb lekérdezések (a Symbol Ügyvitelbe beépített  lekérdezésfordító ebben segíteni fog nekünk) esetén létrehozunk olyan “furcsa” indexeket, amelyek nem logikusak, de nagy értékkészletük miatt az adatbázis kezelő mégis használni fogja őket.

 

 

Eközben nyugaton…

Tengerentúli példákkal jönni sikkes, nem is szeretem, de mégis hadd álljon itt egy amerikai példa. Ott jellemzőbbek a saját fejlesztőcsapattal rendelkező cégek (nálunk a bankoknak/pénzintézeteknek sincs ilyen, egy kivételt ismerek a Concorde Értékpapír Zrt-t, amelynek van egy saját, profi csapata), ahol a DBA (adatbázis adminisztrátor) feladata, hogy a lassú lekérdezéseket (1mp helyett 90-120mp) optimalizálja és indexekkel támogassa. Nekünk, dobozos szoftver szállítóknak ezt helyi rendszergazda nélkül kell tudnunk megoldani. Eddig sikerrel!