A programban a vonalkódolvasással történő árukezelés az idők során nagyon széleskörű tudásra tett szert, ennek viszont az lett a következménye, hogy bizonyos esetekben lassúvá vált, mert mindenáron próbált valahogy eredményre jutni a beolvasott értékkel. Szükségessé vált tehát egy paraméterező funkció, amelynek beállításai segítenek a programnak optimálisabban, "okosabban" működni.
A sERPa készletkezelő funkciói igen sokfélék, ezért az itt beállított értékekkel való munkafolyamat változást (az eredeti működéshez képest értve) funkciónként valósítjuk meg. Hogy mely funkciók dolgoznak ezzel a paraméterrel, azt alább, az Alkalmazó funkciók bekezdésnél lehet megtudni.
Ennek a paraméterező funkciónak a feladata tehát alapvetően két fő részből áll:
1, Gyorsítja a termékazonosítást a vonalkód leolvasása után azáltal, hogy csak ott keres termék vonalkódot az adatbázisban, ahol itt, az általános fülön a beállítások szerint esély van ennek fellelésére,
2, Lehetővé teszi, hogy termék szinten meghatározhassuk azt, hogy milyen adatokat kell vonalkódolvasóval leolvasni és ezt akár több, különálló vonalkód címke leolvasásával is be lehessen vinni a programba. (Az eredeti működés nem tudott ilyet kezelni.) Ezek a beállítások az Attribútumok fülön érhetők el.
Általános információk:
- a vonalkód olvasók csak egy karaktersort küldenek, sem a vonalkód típusa (GS1 databar vagy valami más), sem a leolvasott érték rendeltetése - hogy az egy termék vonalkód, vagy gyártási szám, esetleg gyártás dátum, vagy lejárat - nem derül ki belőle, ezt a programnak kell megpróbálni kitalálni. Ez egy nagyon bonyolult tennivaló, mert például, ha a vonalkódolvasótól a program azt kapja, hogy 10123456789012 akkor ez vajon mi? Ha GS1 - de ezt ugye nem tudjuk - akkor a 10 gyártási szám szegmenst jelenthet és a valódi gyártási szám az 123456789012, ha nem GS1, akkor az egész karaktersor gyártási szám. De az is lehet, hogy ez egy termék vonalkód...
Olyan esetek is vannak, hogy egy GS1 vegyes adatokat tartalmaz, például termék (01) és lejárat (15)vagy(17) de lehet külön termék(01) és külön gyártás(11) és ezek mindenféle variációi a négyféle adat (termék, gyári szám, gyártás dátum, lejárat dátum), melyek mind-mind egy összefolyt karaktersorként érkeznek a programba. Ebből a karaktersorból a GS1 szabályai szerint megoldható annak kitalálása, hogy mi mindent kaptunk. A termék (01) vagy (02)+14 karakter, a gyártás(11) és lejárat(15) vagy (17) dátum 6 karakter, azonban a gyártási szám(10) már változó karakterszámú, ezért ennek mindig a leolvasott kódsor végén kell lennie és ez szerencsére így is van a gyakorlatban is. Ha nem így lenne, nem tudnánk egy (10)+(17) esetén hogy a 10-nek hol van vége.
A gyártási számos példa okán úgy működünk, hogy ha a termék azonosítása GS1-el sikerült, akkor a program ezt megjegyzi és a további vonalkód adatokat is GS1-ként próbálja értelmezni, ha nem GS1, akkor utána is úgy jár el, hogy nem GS1-et kap. Az, hogy egy termék csomagolásán vegyes vonalkódok legyenek, nem életszerű ezért nem is próbáljuk lekezelni.
Mindezekből kifolyólag nem lehet elvárni azt, hogy minden egyes esetet képes legyen a program megoldani.
- a programnak ki és be irányban különböző a feladata a kapott adatokkal. Be irányban a vonalkóddal leolvasott adatokat gyakorlatilag csak rögzíteni kell a programban, ki irányban azonban már készletet is kell figyeljen és képesnek kell lennie arra is, hogy akár egyetlen információ alapján (például egy gyártási szám leolvasása) eredményt / találatot érjen el.
Be iránynál nagyon fontos, hogy megtudjuk milyen termékkel állunk szemben, ezért elsődlegesen mindig termékazonosításra (is) alkalmas kódot kell a raktárosnak leolvasnia.
Ki iránynál már összetettebb a működés, mert például egy egyedi gyári számos terméknél elegendő lehet gyártási számot leolvasni, abból egyértelműen ki fog derülni a termék is. Ez csak ilyenkor képes működni, mert már készleten lévő gyártási számok közt van lehetőség keresni (be iránynál a gyártási szám még csak egy karaktersor, gyári szám akkor lesz belőle, ha lementettük a szállítólevelet). Azt, hogy ilyenkor kell-e gyártási számban keresni, szintén beállítható ebben a funkcióban.
- nagyon komoly különbség van a leolvasott adat azonosíthatóságának szempontjából, hogy GS1 databar, vagy egyéb vonalkód típussal van dolgunk. A GS1 szegmenseiből tudható, hogy milyen adattal van dolgunk (01 vagy 02 = termék, 10 = gyártási szám, 11 = gyártás dátum, 15 vagy 17 = lejárat dátum) de persze a szegmenseket a kapott karaktersorból kell a programnak észrevenni.
egyéb esetben viszont a kapott karaktersorból nem derül ki, hogy az mi. Itt a program nem tehet mást, mint azt, hogy terméket azonosít, majd sorban bekéri a paraméter szerint még szükséges vonalkódokat a paraméterezett vonalkódolvasáshoz kifejlesztett ablakban.
- amennyiben olyan vonalkód adat kerül leolvasásra, melyre a paraméterezés szerint nincs szükség, azt a program nem fogja eldobni, elfelejteni. Az ilyen esetet paraméterezési hibaként értelmezzük és nem hagyjuk elveszni a létező adatot. Példa: A termékhez paraméter szerint csak lejáratot kell megadni de a leolvasott GS1 vonalkód 01+11+17+10, akkor a program a gyártás dátumot és a gyártási számot is be fogja írni a gyártási számhoz.
- fontos, hogy a vonalkód olvasó úgy legyen beállítva, hogy az F8 gomb utasítását elküldje a programnak, mert ez indítja el a vonalkódolvasás folyamatát, amennyiben ez hiányzik kézzel kell az F8-at megnyomni és a kódsor végén egy entert is küldjön, hogy a megjelenő ablakban a mezőkön való léptetés és ezzel akár az ablak bezárása is automatikusan zajlódjon, kézi beavatkozás nélkül)
- a dátum adatokkal hasonló a probléma, mint a gyártási számmal kapcsolatosan. GS1 esetén szerencsére szabvány szerint pontosan lehet tudni mit jelent a karaktersor (ÉÉHHNN), de egyéb típus esetén ez közel sem egyértelmű. Ezeket a variációkat tudjuk értelmezni: (ahol nincs megadva nap, ott az Attribútumok fülön a Nap kiegészítés mezőben leírtak jutnak érvényre)
ÉÉHH
ÉÉHHNN
HH/ÉÉÉÉ
A GS1 szegmensekről bővebb információ a következő, angol nyelvű oldalon elérhető: https://www.databar-barcode.info/application-identifiers/
A következő GS1 szegmensek kerülnek feldolgozásra:
(01) Termék azonosítás
(02) Termék azonosítás
(10) Gyártási szám
(11) Gyártás dátum
(15) Lejárat dátum
(17) Lejárat dátum
(21) Gyártási szám
Egyedi gyártási számok tárolására való, de mi annak megfelelően dolgozzuk fel (mennyiség tekintetében), hogy a beazonosított terméknek a programban milyen gyártási szám beállítása van.
Tehát csak annyi történik, hogy ebben a szegmensben is tudunk gyártási számot fogadni.
Első leolvasáskor, tehát amikor a termék azonosítása történik, akkor a fenti szegmensek tekintetében a szabály az, hogy a kapott karaktersor elején kell legyen a termék azonosításra szolgáló adat és ha ez a vonalkód tartalmaz gyártási számot, akkor annak pedig a végén. Az összes többi feldolgozásra kerülő szegmens ezeken belül bármilyen sorrendben elhelyezkedhet. Ebből következően ha például nincs benne gyártási szám, akkor egy lejárat, vagy gyártás dátum elhelyezkedhet a karaktersor végén is.
Termékazonosítás után, második leolvasásnál már nincs ilyen kötöttség, csak annyi, hogy, ha elsőre nem kaptunk gyártási számot, akkor annak a második leolvasás során is a kapott karaktersor végén, vagy egyedül kell szerepelnie.
(Lásd még alább a Speciális adatfeldolgozási lehetőség bekezdést)
Nézzünk egy paraméterezési, majd működési példát a Szállítólevél funkcióban megvalósított folyamattal:
Paraméterezés:
Az Általános fülön
- azt mondjuk, hogy fogunk használni termékkategóriát mert egyes termékeink nem gyári számosak, mások mennyiséggel gyári számosak és vannak egyedi gyári számos termékeink is és ezeknél más-más adatokat kapunk, melyeket készletkezeléskor le kell olvasni. Ezért a Termékkategória mezőt kitöltjük mondjuk a Vonalkód elvárás nevű termékkategóriával.
- a Keresés gyártási számban mezőben (csak ki iránynál van szerepe) azt mondjuk, hogy Utólagosan, azaz csak akkor keressen a program gyári számban, ha a leolvasott érték alapján nem talál terméket.
- a Termékazonosítás keretben csak a Termék vonalkódban mező áll igaz értéken, mert sehol máshol nem tárolunk termék vonalkódot a programban.
Az Attribútumok fülön
- kitöltjük a táblázatot a Vonalkód elvárás termékkategória tételeivel.
A nem gyári számos termékeket jelentő kategóriatételnél egyetlen pipát sem állítunk igazra, mivel nem várunk gyári számmal kapcsolatos adatot,
A mennyiséggel gyári számos termékeket jelentő kategóriatétel sorában a gyártás és a lejárat mezőt állítjuk igazra, mert csak ilyen információt tartalmazó vonalkódot fogunk hozzájuk kapni, (ezek jellemzően az élelmiszerek)
Az egységenként gyári számos termékeket jelentő kategóriatétel sorában csak a gyártási szám mezőt állítjuk igazra, (ezek lehetnek például informatikai eszközök)
Működés:
Amennyiben itt a Használható pipa igaz értéken áll, úgy a következő lesz a folyamat a Szállítólevél funkcióban:
Be iránynál elengedhetetlen, hogy elsőként a terméket azonosító vonalkódot olvassuk le, hiszen ebből fogja a program megtudni azt, hogy hogyan kell továbblépni. Ilyenkor, ha nem találjuk a terméket, lehetőség van a azt a megjelenő ablakban kézzel megadni.
Első esetként tegyük fel, hogy nem GS1 kódot kap a program, ezért a kapott karaktersorral nem tehet mást, mint azt, hogy ezt fogja keresni a termékben megadott vonalkódok közt. (máshol nem keres, mert a Termékazonosítás keretben azt mondtuk, hogy csak ott tárolunk vonalkód adatot) Ha nem találja meg a terméket, akkor felajánlja, hogy válasszuk ki. Ha megvan, de nem egyértelmű, akkor egy felugró ablakban egy táblázatban kiírja a szóba jöhető termékek kódját és nevét. Az itt kiválasztott termékkel dolgozik tovább.
A termék besorolása alapján megtudjuk innen a paraméterből, hogy milyen további vonalkód adatokat kell még beolvasni. Ha a termék nincs besorolva, a program átvált az eredeti vonalkód olvasásos működésre, a terméket felveszi a tételbe és ha gyári számos a termék, akkor megjeleníti a gyártási szám táblázatot is de innentől nem tud már segíteni abban, ami itt a paraméterben be van állítva. Látható tehát, hogy gondos paraméterezésre van szükség a helyes működéshez, az új termékeknél nem szabad elfelejteni a besorolás megadását, ezért hasznos lehet, ha az itt használt termékkategória kötelezőre is van állítva.
Nézzük tovább: a termék megvan, egyértelmű, be is van sorolva és azt tudta meg a program, hogy ez egy nem gyári számos termék, azaz semmi további teendő nincs, felveszi a tételbe a terméket olyan mennyiséggel, amilyen mennyiséget a vonalkód alapján sikerült meghatározni. (a termékben adhatunk meg alapértelmezett mennyiséghez is vonalkódot, ekkor a mennyiség 1 lesz, de átváltásokhoz is adható meg vonalkód, mondjuk 1 karton = 20 db és ha karton vonalkód lett leolvasva, akkor a tételmennyiség 20 lesz.)
Ha a leolvasás eredményeként mennyiséggel gyári számos terméket sikerült azonosítani, akkor ugye azt mondtuk itt a paraméterben, hogy ilyenkor még várunk gyártás és lejárat adatot is. Mivel még csak a terméket tudjuk, ezért a program feldobja a fentebb már említett ablakot, kiírja benne a leolvasott vonalkódot, az ennek segítségével azonosított terméket, majd a gyártás dátum mezőre kerül a fókusz, mint soron következő leolvasandó vonalkód adatra. Tehát a következő csippantás eredménye ebbe a mezőbe fog bekerülni, a fókusz átlép a lejárat mezőre, mert fentről lefelé az következik. Ha ez is leolvasásra került, akkor a program észreveszi, hogy nem várunk több adatot, mert elfogytak a kitöltendő mezők és a Rendben gombot is lenyomja a felhasználó helyett, majd a kapott adatokat beviszi a bizonylattételbe. Ha kartonos kód került leolvasásra (a példánál maradva 20db), akkor mennyiséggel gyári számos termék esetén a gyártási szám táblázatba is 20 mennyiség kerül be, kitöltve a sorban a gyártás és lejárat dátumot is. Ha ez után újra ezt a termék vonalkódot olvassa le a felhasználó, akkor a mennyiséghez hozzá fogunk írni 20-at (összesen immár 40), ha a gyártás és a lejárat értéke azonos az előzővel, akkor a gyártási szám táblázatban is 40 lesz a mennyiség, ha ez eltérő, akkor új sort veszünk fel 20-al.
Ugyan ez az eset egységenként gyári számos terméknél kénytelen egy kicsit másként működni, mivel a gyártási szám mennyisége mindig csak 1 lehet, nincs értelme 20 azonos gyártási számot tartalmazó sort beszúrni. Ilyenkor a termékazonosítás után a program ugye gyártási szám mezőt fog várni, a kis ablakban is azon lesz a fókusz, majd a gyártási szám leolvasása után felveszi a tételt 20 mennyiséggel 1 gyártási szám sorral, mert nem tehet mást. Ez az eset általában nem fordul elő, mivel a kartonon jellemzően nincs rajta a beltartalom összes tételének egyedi gyári száma külön, hanem ilyenkor a karton kibontásával egyesével történik a termékek és gyári számok beolvasása. A termék azaz tételmennyiséget ugyan úgy fogja növelni a program egyesével és veszi fel a gyártási szám sorokat is sorban, egyesével.
Amennyiben GS1 vonalkódokkal van dolgunk, úgy a program is sokkal okosabb tud lenni és képes arra, hogy ha nem sorban vannak leolvasva az adatok, akkor a helyére illessze be a leolvasott vonalkódot. A termék azonosításra alkalmas kezdés itt is előfeltétel, azonban akár ezzel egy időben, akár utána, akár többféle szegmens kezelését is elvégzi a program. Példák:
- Termék és gyártási szám egy vonalkódban van (a termékünk legyen az egyedi gyári számos példa), a termékből az derül ki hogy a gyártási számon kívül mást nem várunk, így ezt az egyetlen vonalkódot leolvasva a program azonnal beolvassa a tételbe a terméket és a gyártási szám táblázatba is felveszi a sort.
- Termék és lejárat dátum egy vonalkódban van (a termékünk legyen a mennyiséggel gyári számos példa), ez esetben még egy gyártás dátumot várunk, azaz felugrik az ablak, lejárat kitöltve, a fókusz pedig az egyetlen még kitöltetlen mezőn, a gyártás dátumon lesz. Ennek lecsippantása után a bizonylattétel kitöltésre kerül.
Összefoglalva röviden a be irányt: Elsőre tudnunk kell a terméket, ha kell még adat, feljön az ablak, ha minden hiányzó mezőbe csippantottak adatot, akkor a program automatikusan bezárja az ablakot és tölti a bizonylattételt. NEM GS1 esetén sorban kell csippantani, GS1 esetén ez nem szükséges, a szegmens alapján az adatot a helyére tudja tenni a program.
A ki irány annyiban különbözik a be iránytól, hogy itt előfordulhatnak olyan esetek, amikor nincs feltétlen szükség arra, hogy a termék vonalkódját tudjuk meg először. Ennek szabályzását végzi az Általános fülön a Keresés gyártási számban mező. A termék azonosítást követően (mindegy, hogy termék vonalkódon, vagy gyártási szám vonalkódon keresztül sikerült beazonosítani) ha az itteni paraméter szerint van még leolvasandó adat, azt a program a be irányban taglaltak szerint a kis ablakban be fogja kérni.
Speciális adatfeldolgozási lehetőség:
A GS1DataBar tartalmaz(hat) úgynevezett GroupSeparator karaktereket, amelyek láthatatlanok, tehát beolvasáskor nem jelennek meg, azonban a fejlettebb vonalkód olvasók felprogramozhatók úgy, hogy ezek helyett egy tetszőleges speciális karaktert adjanak vissza. Ezt a karakterek fel lehet használni arra, hogy egyes - számunkra akár felesleges - szegmenseket fel lehessen ismerni. A fix hosszúságú adattartalom azonosítók előtt (ezt szoktuk szegmens kódnak hívni), jellemzően nincs ilyen karakter, de lehet. A nem fix hosszúságúak előtt és főleg után jellemzően van, ha ezek nem a kód legvégén vannak.
A program vonalkód olvasási algoritmusába ezt a GroupSeparator karaktert pipe-ra azaz | (AltGr+W) kell fordítani az olvasó programozásával, ekkor fogjuk tudni értelmezni és felhasználni ezt az adatot.
A szabály ezzel a karakterrel kapcsolatban az, hogy egy szegmens mindig maximum a | karakterig tart, továbbá egy | karakter után mindig új szegmenskód következik. Ha ez olyan, amit nem ismerünk / dolgozunk fel (lásd fentebb a (01), (02), ...), akkor el kell dobni ezt és az ezt követő adatsort egészen a következő | karakterig, vagy annak hiányában a kód végéig kell feldolgozni.
Mindez példákkal:
Ha Group Separator karaktert kapunk, akkor arra számítunk, hogy adattartalom azonosító (szegmenskód) fogja követni. Ha olyan szegmenskódot találunk itt, ami nem olyan, amit feldolgozunk, akkor azt a kódrészt figyelmen kívül hagyjuk, de számítunk rá, hogy ezt is lezárhatja egy újabb Group Separator és utána még jöhet számunkra is értelmezhető adattartalom: (a szegmenskód félkövérrel, sárgával pedig a feldolgozásra nem kerülő adatrész)
0112345678901234112312311725063010987654321|30213146546513213 feldolgozott eredménye: 0112345678901234112312311725063010987654321, mert a kód végén állt egy irreleváns, (30) szegmenskód.
Itt a haszon abban rejlik, hogy a 10-es szegmensben lévő gyártási számot - mivel az egy változó karakterszámú szegmens - a Group Separator nélkül a kód végéig gyártási számnak vennénk, de így, hogy a | karakter lezárja azt a szegmenst, már tudjuk, hogy csak addig tart a gyártási szám.
021234567890123415250731|2414654654654654|10555666555 feldolgozott eredménye: 02123456789012341525073110555666555, mert a kód belsejében van a felesleges, feldolgozásra nem kerülő (241)-es kódrész, a végén pedig a számunkra is fontos (10) gyártási szám.
Fülek
Leírás
A funkció bal oldala nem látható.
A funkciónak csak módosítás és lekérdezés üzemmódja van, mert ez a beállítás csak egyedileg értelmezhető, nincs értelme több variációban megadni.
Az Attribútumok fülre csak akkor lehet átváltani, ha az általános fülön a termékkategória ki van töltve. Ennek oka, hogy a tétel fülön az itt megadott kategória tételeiből lehet választani. Amennyiben a tétel fülön egyetlen sor is felvételre került a táblázatba, az Általános fülön a termékkategória mező már nem módosítható.
Javasolt almenü
Funkció elérése menüszerkesztéskor: sERPa Alap / Logisztika / Készlet / Struktúra
Ellenőrzések
Az Attribútumok fülön egy kategóriatétel csak egyszer vehető fel.
Amennyiben ez a feltétel nem valósul meg, akkor az alábbi hibaüzenetet kapjuk: "Egy kategóriatétel csak egyszer vehető fel az Attribútumok táblázatba! (Kategóriatétel kód)"
Az Általános fülön a Termékazonosítás keretben legalább egy mezőnél a pipának igaz értéken kell állnia.
Amennyiben ez a feltétel nem valósul meg, akkor az alábbi hibaüzenetet kapjuk: "A Termékazonosítás sávban legalább egyet be kell jelölni!"
Alkalmazó funkciók
Vonalkódos áruellenőrzés - a pontos működést lásd a funkció leírásánál.
