Az oldal megtekintéséhez kérjük, engedélyezze a JavaScriptet.

sERPa súgó

Fejlesztés alatt...

Fontos! Az alábbi leírásban említett folyamat beüzemeléséhez szükséges beállításokat a fejlesztés jelen állásában kizárólag a Progen Kft. tanácsadója végezheti el az Ügyfél kifejezett írásos kérésére és a Progen Kft jóváhagyásával!

 

A programban lehetőség van arra, hogy az áru igényt támasztó rendelés tételeket (vevő, belső, stb.) foglaláskapcsolattal összekapcsoljuk egy vagy több, igényt kiszolgáló (szállító, belső, stb...) rendeléstétellel. Ez a kapcsolat biztosítja azt, hogy amikor az áru szállítólevéllel beérkezik egy raktárba, akkor a foglalás kapcsolatban szereplő igénylő rendelések elsőbbséggel megkapják az árut, egy a program által generált diszponálás válasz segítségével. (Például vevőrendelésnél a válasz típus: Vevő rendelés diszponálás (Rendelés foglalásból))

A program alapértelmezetten úgy működik, hogy abban a táblában, ahol a foglaláskapcsolatokat nyilvántartjuk (dbo.AruforgBizTetelFoglalas), oda a fenti folyamat során lezajlott áru diszponálást nem jegyzi fel. Ennek oka, hogy ez a látszólag egyszerű feladat valójában roppant bonyolult. A széleskörű programbeállítási lehetőségeknek köszönhetően nagyon sokféle működési környezetben kell helytálljon és az árukezelés további folyamataira is kihat, azok során is szükséges ezen adatok karbantartása, továbbá a Logisztika és a Termelés modul számtalan területére hatással van.

Egyéb fejlesztéseink mellett több éve igyekszünk azon, hogy a foglalásteljesítések feljegyzését megvalósítsuk. Eljutottunk arra a pontra, amikor a programba fixen még nem építjük be a működést, de az ezt igénylő ügyfeleknek biztosítjuk a lehetőséget arra, hogy kipróbálják.

Azt, hogy milyen pluszt nyújt a Foglalásteljesítés feljegyzés bekapcsolása egy adatbázisban, azt az érintett táblában történő változáson keresztül lehet legjobban szemléltetni.
A tábla alapértelmezetten így néz ki: (a téma szempontjából irreleváns mezőket halványítva jelenítjük meg)

A négy félkövér mezőre megszorítás van a táblán, ezek azonos értékekkel csak egyszer szerepelhetnek, ebből kifolyólag a diszponálás válasszal "odaadott" árumennyiséget sem lehet feljegyezni.
Tehát a foglalás táblában egy ilyen "rendeléspár" vonatkozásában a foglalt mennyiség akkor is ennyi, ha az igénylő rendeléstétel azt már régen megkapta.

A tábla a foglalás teljesítés feljegyzés bekapcsolása után:

A különbség elég szembeötlő, látszik hogy ugyan az a rendeléspár több soron is szerepelhet és bekerült három új oszlop. Nézzük mit kell tudni róluk:
A két piros szám azt mutatja meg, hogy összesen mennyi árut vár az igénylő rendeléstétel eredetileg, a két zöld pedig azt, hogy összesen mennyit kapott meg eddig és ez a lelke az egész átalakításnak, hogy meg tudjuk mondani, hol tartunk, kinek, mennyi áruval tartozik még az igényt kiszolgáló rendeléstétel (mennyi a szabad kapacitása), illetve egy igénylő rendeléstétel honnan mennyi árut kap még összesen (mennyi a fedezetlen áruigénye). Ezeket a roppant fontos adatokat a tábla eredeti állapotában és a program eredeti működése szerint nem lehetett nyújtani, mert nem volt meg a lehetőség az adatok feljegyzésére. Jelen példán nézve tehát összesen kért eddig 13-at, megkapott 9-et, tehát még kap ez az igénylő rendelés tétel 4-et.
A három új mezőről néhány szó:
- RendAruforgBizValasz_ID:        Annak a (diszponálás) rendelés válasznak az ID-jét jegyezzük fel, amelynek kapcsán az igénylő rendeléstétel az árut megkapta. Ennek következménye, hogy az igénylő rendeléseken az ilyen válaszok érinthetetlenek.
- AruforgBizTetelTeljesites:        Valójában technikai jelentősége van, de érdemes róla szót ejteni. A szállítólevél tételben lévő teljesítés mennyiségeltérés esetén is pipa igaz értékét jegyezzük be ebbe a táblába is a szállítólevél tételben szereplő rendelés tétel vonatkozásában a kiszolgáló oldali rendelés tételre. Tesszük ezt azért, hogy ennek a táblának a vizsgálata során (rengeteg funkció és programelem nézi ezt a táblát) a lehető leggyorsabban ki lehessen ejteni azokat a rendeléstételeket, amelyeknél ugyan a kért és kapott mennyiségek összege szerint még van nyitott mennyiség, de emiatt a speciális programhasználat miatt, az ilyen rendelés tételek már nem számítanak, hisz az azt teljesítő egyik szállítólevél tételen bepipálták, hogy Teljesítés mennyiség eltérés esetén is.
- RendAruforgBizTetelTeljesites: Az előzővel egyező a szerepe, csak az igénylő rendeléstétel vonatkozásában.

 

Hol tartunk a fejlesztéssel?
Száz feletti tárolt eljárást és függvényt vizsgáltunk meg, hogy a tábla megszorításának feloldása után hibára futnak-e, több tízet kellett módosítani emiatt és letesztelni, hogy foglalásteljesítés feljegyzéses és eredeti környezetben is rendben működnek-e.
Minden olyan programelem készen van, amely a táblába adatot ír, vagy módosít - ezeket is mindkét környezetben kellett tudni működtetni és tesztelni. Mindegyikre készültek olyan automatizált (úgynevezett unittest) tesztek, amelyek a működésüket monitorozzák minden nap, hogy kiderüljön, ha menet közben romlana el valami (egy esetleges jövőbeni) program módosítás akaratlan mellékhatásaként).
Több helyen elkészült a program felületén az, hogy ennek a táblának a plusz tudását kihasználja, például a rendelés bevitelekben a tételeknél a foglalás táblázatok. (Igénylő és kiszolgáló oldalon is megmutatják, hogy mennyi van még hátra, mi teljesült már, stb.)

Még több helyen fogunk folyamatosan fejleszteni azokban a funkciókban, amik adatot szolgáltatnak ebből a táblából, például egy várható beérkezés részletezés művelet. Az ilyen és ehhez hasonló programelemeknél egyesével fogjuk megnézni, hogy a rendelkezésre álló plusz tudást hogyan használjuk ki. Funkciótól függően kellhetnek új oszlopok, vagy elég lehet egy meglévő oszlopokban algoritmus pontosítás, stb. Ezekkel is folyamatosan haladunk.

 

Ez a látszólag pici, de valójában rendkívül szerteágazó program bővítés a foglaláskapcsolatok vonatkozásában szigorúbb, pontosabb programhasználatot és folyamatokat követel meg, ezért az erre a funkcionalitásra igény tartó ügyfeleink részére először egy nagyon alapos adatbázis átvizsgálást kell végezzünk, melynek tapasztalatait ügyfelünkkel megosztva döntünk a továbbiakról. Ezt a vizsgálatot egy külön ajánlat keretében nyújtott díjazás ellenében fogjuk elvégezni.

Ha felkeltettük érdeklődését, hívja kapcsolattartóját, vagy a sERPa központi ügyeletét.

 

Fontos egyéb információ:
A foglalásteljesítés feljegyzés beállítása után az adatbázis frissítések során a frissítési naplóban ez a sor normális, nem kell miatta bejelentést tenni:
AdatbazisStrukturaEllenorzes.sql
 Hiányzó megszorítás: dbo.AruforgBizTetelFoglalas_IX1