sERPa súgó

Az ebben a funkcióban történő beállítások azt a problémát hivatottak kezelni, amikor az áru két raktár közt mozog és egyáltalán nem biztos, hogy minden hiánytalanul oda is ér a cél raktárba. Az ilyen jellegű készletmozgásokat a programban alap esetben raktárközi szállítólevelek valósítják meg, azonban ezek esetén nincs olyan lehetőség, hogy A raktárból kiment valamiből 10db, de a B raktárba már csak 8 érkezett meg, mert mondjuk levitte a menetszél a teherautóról.
Azonban hiába is tudna ilyet egy raktárközi szállítólevél, mert a külső raktár irányítási rendszerek nem tudnak értelmezni ilyen jellegű szállítási utasításokat - gyakorlatilag egy belsőrendelést kellene feldolgozzanak, de nem tudnak ilyet.

Ezt a problémát úgy lehet megoldani, hogy belsőrendelés helyett rendelés (szállító és vevő) párokat generálunk.

Azt, hogy milyen szállítórendelés esetén milyen vevőrendelésnek kell születnie - illetve, hogy milyen vevőrendelés esetén milyen szállítórendelésnek - azt lehet ebben a funkcióban beparaméterezni. Ahhoz, hogy a felvett rendelések után a párja is megszülessen, ahhoz elengedhetetlenül szükséges, hogy a Rendelés - Kétlépéses áttárolás automatikus üzenet fusson. Tehát itt csak a beállítások vannak, az automatikus üzenet pedig ezek figyelembevételével fogja legenerálni a rendeléspárt.

 

A folyamat szemléltetését egy olyan példán keresztül mutatjuk be, amikor szállítórendelés felvétel hatására generálja le a program a vevőrendelést.

Amikor a generált vevőrendelést elkészíti a program, akkor az őt létrehozó szállítórendelés SQL azonosítójával (AruforgBiz_ID) együtt bejegyzi őket az AruforgBizKiBePar táblába. Ezt azért teszi, mert az ilyen rendelés "párokat" teljesítő szállítólevelek a nyilvántartási árak követése érdekében (ha a ki irányú szállítólevél nyilvántartási ára megváltozik, azt követhesse a be irányú szállítólevélben szereplő nyilvántartási ár) ennek az AruforgBizKiBePar táblában szereplésüknek köszönhetően bekerülnek a SzLevelTetelKiBePar táblába is. Ebből következően ezekkel a szállítólevelekkel kapcsolatban két nagyon fontos feltétel van:
- A vevőrendelést teljesítő ki irányú szállítólevél nem lehet későbbi dátumú, mint a be irányú szállítólevél. A program nem enged ilyen dátummal ilyen szállítólevelet menteni.
 Raktár irányítási interfészek esetén a szállítólevél ilyenkor is létrejön és a program a hibanaplóba bejegyzi, hogy ilyen problémával sikerült felvenni a szállítólevelet.
- Egy ilyen rendelésre hivatkozva csak egy szállítólevél készíthető, azaz részteljesítések nem lehetségesek, mert ebbe a táblába egy szállítólevél csak egyszer kerülhet be. Ebben az esetben a program megpróbálja újra legenerálni az SzLevelTetelKiBePar táblába az adatot, de ez nem sikerülhet neki és Duplikált kulcs a(z) dbo.SzLevelTetelKiBePar tábla SzLevelTetelKiBePar_PK indexében szövegű SQL hibaüzenetet fog küldeni.

Amennyiben valamilyen oknál (pl. hibás/hiányos paraméterezés, vagy technikai probléma miatt nem futnak az AUT-ok) fogva egy szállítórendelésről nem készül el a vevőrendelés pár, úgy ezt a szállítórendelésen állva az Automatizmusok kézi indítása művelettel az ezt végző automatikus üzenetet kiválasztva pótolni lehet.
Előfordulhat hogy egy szállítórendelés rossz adatokkal készült el és ezért rossz lesz a program által generált vevőrendelés párja is. Ekkor a teendő az, hogy a vevőrendelést le kell törölni, majd a szállítórendelés javítása után az előbb említett művelettel újra lehet generálni a vevőrendelés párját. Erre azért van szükség, mert a párként generált rendelésen néhány kivételtől eltekintve semmi sem módosítható, azt a rendelést csak törölni lehet. Ez miatt, ha a vevőrendeléseken kötelező diszponálás van, akkor a folyamatot a vevőrendelés irányából kell kezdeményezni.

A párként generált rendelésre
- minden egyéb ellenőrzés nélkül átkerül a forrás rendelésen megadott útvonal,
- fizetési mód az ügyfélben megadott,
 (ha szállítórendelés keletkezik, akkor a Szállító-Pénzügy sávban megadott, ha vevőrendelés, akkor a Vevő-Pénzügy sávban megadott.)
- nem történik hitelkeret ellenőrzés,
- dátum mindig a forrás rendelés dátuma

Az ilyen áttárolás céllal felvett rendeléseket teljesítő szállítólevelekben például az árak, fizetési módok teljesen irrelevánsak, hiszen nem ezek alapján történik majd a számlázás, ezek csak az áru mozgatására szolgálnak. Ugyan ez miatt ezek a szállítólevek számlázatlanok is maradnak, és így számlák készítésekor útban lehetnek. Érdemes tehát ezeknek a rendeléspároknak a teljesítését végző szállítóleveleket teljesen külön mozgásnemen kezelni. A fejlesztés jelen fázisában azt javasoljuk, hogy egy technikai, nem nyomtatható számla sorozatra, bizonyos időközönként generáljanak ezekből számlát egy erre a célra felparaméterezett Számla generálás több szállítólevélről funkcióval.

 

Példák a használatra:
 (Amikor itt alábontásmentes raktárat emlegetünk, akkor nem gondolunk a raktárhely alábontásra, mert az sosem szerepel rendelésnyilvántartás bizonylatokon és itt most kizárólag rendelés bizonylatokról esik szó.
 Tehát a szóba kerülő raktárak esetén teljesen mindegy, hogy van-e raktárhelyük, vagy nincs, az számít, hogy egyéb alábontásuk van-e.
 A példákkal megjelenített táblázatokba az egyszerűbb megjelenítés miatt nem kerültek külön bele az egyes törzsadatok kód és név mezői, ezeket egy "közösített" oszlopban mutatjuk be.)

1, Egyszerű eset, egyéb alábontás nélküli raktárak közt mozgatunk árut, mondjuk bizományba tárolunk ki egy-egy vásárlónkhoz árut, illetve esetenként hozzuk vissza azt onnan.

A folyamathoz tehát szükséges, hogy a programban keletkezzen egy szállítórendelés (akár bármely generáló funkcióval létrehozva, akár a szállítórendelés bevitelben felvéve). A példában szereplő esetben a szállítórendest jellemzően egy felhasználó veszi fel a szállítórendelés bevitelben.

Ennek a szállítórendelésnek a szállítólevéllel történő teljesítése lesz hivatott a vásárló dedikált raktárába készletre venni azt az árumennyiséget, amit a vásárló átvett. Ez lesz az áttárolási folyamat BE lába.
Ahhoz, hogy a KI lába (amivel a forrás raktár készletéről lekerül a kiadott árumennyiség) is lekeletkezzen, ahhoz van szükség a vevőrendelés legenerálására (majd később annak szállítólevéllel történő teljesítésére).

A BE lábnál a szállítórendelés (cél)raktára az a raktár lesz, amiben a vásárlónk számára bizományba átadott árut tároljuk, nevezzük ezt a raktárt XY -nak.
A szállítórendelés bizonylatra szükség lesz egy szállítóra is, ehhez érdemes egy technikai ügyfelet felvenni az ügyféltörzsbe. Őt nevezzük Progen technikai -nak.

A KI lábhoz kell ugye a bizományosi vásárlónk, ő rendelkezésre áll az ügyféltörzsben, nevezzük őt XY Kft.-nek, azt a raktárt pedig, ahonnan az árut átadjuk számára bizományba, nevezzük Közp -nak.

Nézzük, hogy néz ki ebben az esetben a beállítás:
A táblázatban
- az első sor a fent leírt példát mutatja be,
- a második sorban ugyan attól az ügyféltől a visszafelé történő mozgatás beállítása látható,
- a harmadik és negyedik sorban pedig egy másik ügyféllel ugyan ez,
- az ötödik sorban pedig látható, hogy akár a két bizományos vásárlónk raktára közti áttárolás is beállítható. (az XY Kft raktárából viszünk át árut az MZ/X Kft raktárába.)

 

Ebből az esetből kiderül, hogy ezeket a rendeléspárokat ilyen struktura(raktárbeállítás) esetén minden egyes olyan ügyfélre be kell állítani, akihez így bizományba helyezünk ki árut. Egy későbbi példában lehet látni, hogy mennyivel egyszerűbb helyzetet eredményez, ha a bizományba átadott árukat egyetlen - ügyfél alábontásos - raktárban tartjuk nyilván.

 

 

2, Alábontásmentes és témaszám alábontásos raktárak közti áttárolás. Ez csak kicsit bonyolultabb eset, mint az első, azért szerepel itt a példaként, hogy látható legyen, hogy adott esetben generált szállítórendeléssel is működtethető a folyamat és bemutatja egy nem alábontásmentes és nem ügyfél alábontásos raktár példáját is.

A képzelt működési környezet: A szállítónk az ömlesztett mákot a Budapesti központ raktárunkba (nevezzük KR-nek.) szállítja be, amit csomagolásra el kell szállítanunk a vidéki csomagolóüzemünk raktárába. Ez a raktár témaszám alábontásos, mert ezekben elkülönítjük az eladható árut, a selejtezésre várót, stb. A vidéki csomagolóüzemünk raktára is adott, nevezzük CSR -nek, ebben a raktárban nincs semmilyen alábontás.
Szükségünk van egy ügyfélre, aki a csomagolt mákot szállítja, őt nevezzük Csomagolóüzem -nek. A különböző kiszerelésű csomagolt mákok (1kg, 0,5kg, szemenként csomagolt, stb.) cikktörzsében érvényes szállítói ajánlatot kell felvenni ezekre, szállító ügyfél a Csomagolóüzem. A vásárlóink vevőrendelései alapján igény keletkezik a csomagolt mákokra, melyre például a Szállító és belső rendelés generálás funkcióval lehet forrást biztosítani, azaz szállítórendelést generáltatni. Ehhez a szállítórendeléshez pedig lehet vevőrendelés áttárolást párt generáltatni. Szükség van most is egy technikai ügyfél, aki a csomagolt mákot fogja kapni a vevőrendelésen, legyen ismét a neve Progen technikai. A példa excel első sora mutatja meg a beállítást.
 (A szállítórendelésben szereplő KR raktár témaszám alábontása a szállítórendelésben meg lesz adva, ezért nem lehet a szállítói oldalon alábontásokat megadni itt a paraméterben.)

Ennek a képzelt működési környezetnek van egy másik vetülete is, a Csomagolóüzemnek szüksége van ömlesztett mákra, hogy csomagolni tudjon. Ehhez szükség lesz a fentebb már említett Progen technikai ügyfélre, aki az ömlesztett mákot szállítja a Csomagolóüzembe. A csomagolóüzemben létrejön (akár kézzel felvéve, akár generálva) a szállítórendelés az ömlesztett mákra (melyet a Progen technikai szállít), ehhez kell készítenie a programnak egy vevőrendelés párt. Ez a példa beállítás a táblázat második sorában látható. Itt azt is észre kell venni, hogy mivel a központi raktár témaszám alábontásos és ezt a témaszám alábontást a program nem tudja sehonnan sem kitalálni, ezért ilyen esetben itt a paraméterben ennek megadása kötelező. Az itt megadott témaszám alábontás kerül a generált vevőrendelésbe.

 

 

3, Központi raktárból tárolunk ki árut ügyfél alábontásos bizományosi raktárba, onnan vissza és mozgatunk árut a bizományosi raktár egyes alábontásai közt is. Ez az eset a legbonyolultabb a szabályok megértése szempontjából, paraméterezési szempontból viszont sokkal egyszerűbb, mint a hozzá hasonló első eset.

A vásárló ügyfeleink adottak az ügyféltörzsben és itt is szükséges a Progen technikai ügyfél, aki a szállító lesz az ügyfél alábontásos raktárba.
Megtehetnénk azt, hogy itt is minden egyes bizományosi módon kiszolgálandó ügyfelünkre felveszünk a paraméterben 1-1 rendeléspárt oda és vissza irányra, valamint az ügyfeleink kereszt kombinációira is, de ez akár több száz sor is lehetne és szerencsére erre semmi szükség nincs. Az eddig leírtakból kitűnik, hogy a szállítórendeléshez megadható három oszlop valójában egy szűrés a programban keletkező szállítórendelésekre. Ha egyezik a felvett szállítórendelés Sorozata, Ügyfele, Raktára egy itt beállítottal, akkor a hozzá megadott beállításokkal generál egy vevőrendelés párt. (Pontosan ez miatt nem lehet két olyan adatsort felvenni, ahol a szállító oldalon ez a három adat egyezik, mert a program képtelen lenne eldönteni, hogy melyik adatsorhoz megadott vevőrendelést készítse el.)
A több száz soros paraméterezés helyett a megoldást a Raktárban ügyfél alábontásos esetben megadható ügyfélkategória szolgáltatja. Ez a beállítás is egy szűrés, csak olyan ügyfél választható alábontásként az adott raktárban, amelyik megfelel a Raktárban megadott kategóriának és tételnek. Ezt a lehetőséget kihasználva megtehetjük azt, hogy a paraméterben a szállítórendelésnél és a vevőrendelésnél is üresen hagyjuk az ügyfelet. Ennek eredménye a következő lesz:
Ha itt, a paraméterben megadott sorozatú és raktárú szállítórendelés születik ÉS a szállító ügyfél megfelel a Vevőrendelésnél megadott raktárban beállított ügyfélkategóriának és tételnek, akkor fog a program vevőrendelést generálni. Tehát nem kell megadni a szállító ügyfelet, azt hogy milyen szállító ügyfél esetén kell vevőrendelést generálni, azt a vevőrendelésnél megadott raktárban beállított ügyfélkategória alapján dönti el a program.
Felmerülhet a kérdés, hogy miért a vevőrendelésnél megadott raktárban lévő ügyfélkategóriát figyeljük? Ezt egy példán keresztül lehet a legjobban megérteni:
Bizományosi ügyfeleink üzemanyag töltőállomások (OMV, Shell, stb.). Ők vannak besorolva bizományosi ügyfélkategóriába. Ha például az OMV Tétény töltőállomásról kell a Shell Siófok töltőállomásra áttárolni az árut, akkor készül egy szállítórendelésünk (jellemzően kézzel, a szállítórendelés bevitelben), amelyen a raktár az ügyfél alábontásos bizományos raktár (nevezzük BÜ -nek), a szállító az OMV Tétény, az ügyfél alábontása pedig a Shell Siófok. Ennek a vevőrendelés párja úgy fog kinézni, hogy az ügyfél a Shell Siófok (mert ha üres az ügyfél itt a paraméterben a vevőrendelésnél, akkor a vevőrendelés ügyfele a szállítórendelésben megadott ügyfél alábontásban megadott ügyfél lesz***) az ügyfél alábontásba pedig az OMV Tétény fog kerülni, hiszen tőle hozzuk el az árut, máshogy mondva ő a forrás alábontás, a vevőrendelést teljesítő szállítólevél nála kell majd csökkentse a készletet. Az OMV Tétény pedig csak akkor tud bekerülni ide ügyfél alábontásként, ha ebben a vevőrendelésnél megadott raktárban az ügyfélkategória beállítás ezt megengedi.

 ***Ez az egyszerű és frappáns szabály teszi lehetővé, hogy egyetlen sorban beállítható legyen a bizományosi ügyfeleink közti árumozgáshoz generálandó rendeléspár.

Nézzük a példa paraméterezést: (a központi raktárunkat nevezzük most is KR -nek, az pedig látható, hogy a Vevőrendelés alábontás oszlop üres, hiszen ilyenkor a program a fent vázoltak szerint az ügyfélalábontásokból fog dolgozni.)
- Az első sorban azt látjuk, amikor árut tárolunk ki valamely ügyfelünknek:
 Mi szállítunk az ügyfél alábontásos raktárba, egy megadott ügyfél alábontásba -> a központi raktárból kell az árut vinni a szállítórendelésen megadott ügyfélalábontás ügyfelének.(mivel üres a vevőrendelés ügyfél itt a paraméterben.)
- A másodikban amikor azt a központi raktárba hozzuk vissza:
 Ha bármely bizományos ügyfelünk a szállító a központi raktárba -> készül egy vevőrendelés, ahol mi vagyunk a vásárlói az ügyfél alábontásos raktárból jövő árunak. A program a háttérben kitölti ezen a vevőrendelésen az ügyfél alábontást a szállítórendelésen szereplő ügyfél alapján, hiszen az ő alábontásából kell majd levenni készletről az árut.
- A harmadikban pedig a bizományosi ügyfelek közti mozgást:
 Ha bármely bizományos ügyfelünk a szállító az ügyfél alábontásos raktárba -> készül egy vevőrendelés az ügyfél alábontásos raktárra, ahol a vevő a szállítórendelésen megadott alábontás ügyfele. A program a háttérben kitölti ezen a vevőrendelésen az ügyfél alábontást a szállítórendelésen szereplő ügyfél alapján, hiszen az ő alábontásából kell majd levenni készletről az árut.

 

 

Javasolt almenü

Funkció elérése menüszerkesztéskor: Rendelés-nyilvántartás / Struktúra / Áttárolás paraméter

 

A Funkció egyetlen felületből áll, ahol két összecsukható sávban lehet megadni a beállításokat.

 

"Szállítórendelésből Vevőrendelés" táblázat

 

"Vevőrendelésből Szállítórendelés" táblázat