[ubuntu-hu] számla és raktár

[bojozsi at t-online.hu]

Szerintem ennek a kérdésnek a megtárgyalása nem erre a
listára való, lehetne/kellene erről külön listát nyitni,
hogy ne zavarjuk az oprendszer kérdéseire kíváncsiakat.

De azért amennyire lehet röviden:

"van-e köztetek végzett rendszer tervező
ki késziti el a tesztanyagot
és ka az az örült AKI LETESZTELI"

Hát...Egy őrültnek talán megfelelnék :-) (Azt hiszem. Mivel
az utóbbi néhány évben eltöltöttem ilyen tevékenységgel elég
jelentős időt..... A fodrász kérdezte is, hogy hogy van az,
hogy mifelénk mindig hullik valami fehér, és ha ez van,
miért nem hordok sapkát?)

"én egy vén roka redszer tervező és teszelő vagyok
10-15 keménytökü szakember nélkül még bérmunkában se
vállaná el egy ilyen reenszer."

Tapasztalataim szerint egy ilyen egyszerű készletkezelőhöz
azért ezt kicsit túlzásnak tartom. 10-15 keménytökű
szakemberrel egy egész ERP rendszernek neki lehet menni.
(két-három átlagos tudású programozónak, egy két hónap)
Ezeket a kisebb funkcionalitású szoftvereket kis
informatikai cégek csinálják, itt általában van 2-5 fejlesztő.

Az első továbbra is a koncepció meghatározása. Mit tudjon,
mit kezeljen? Ezt hogyan tegye és milyen eszközökkel. Ha
csak raktárkezelésről van szó, akkor is lehet egyszerűen is
és bonyolultan is megoldani. Ha ez megvan, jöhet a tervezés,
majd a megoldás.

Példa kérdések:

Fő kérdés, mennyire legyen bonyolult! Csak alma be-ki
partnertől-partnernek ennyi db, kg, cm stb.

Vagy bonyolultabb egy kicsit:

1. Hány raktárt kell kezelni? (Egy cég/vállalat hány
telephelyén hány raktár?)
2. A raktárban kell -e külön termeket, termekben tárhelyeket
kezelni. (Például: 1-es raktár, 1-es terme, 1-es utca, 1-es
polc, 1-es magasság. Kell -e ezeknek
kapacitáskihasználtságát ellenőrizni?)
3. Kardinális kérdés szokott lenni a készletkezelési szint
meghatározása. (Ezen sok bevezetés elbukott ekőbb-utóbb. 
"A" mód: cikkszintű készletkezelés, amikor megadom hogy
milyen cikk -cikkszám, cikknév, mennyiségi egység, mennyiség. 
"B" mód: cikk-sarzs, amikor az "A" mellé megadok egy tétel
azonosítót -például szállítmány sarzsa, vagy termék
eltarthatósági ideje.
"C" mód: cikk-sarzs-gyári szám, amikor gyűjtőcsomagokat
-és/vagy egyedi csomagokat- egyedi sorszámmal kezelem. Ebben
az esetben már kezelni kell
"C1": gyári számok összesítését, raklapképzést
"C2": raklap azonosító bonthatóságát, azaz az egyedi gyári
számok levehetőségét a raklapról és/vagy másik gyári szám
hozzáadhatóságát.

Illik kezelni tudni göngyöleget, rakszert (raklap, rakonca,
konténer, stb.) is, valamint a raktár kiegészítő
tevékenységét (fóliázás, komissiózás, szettkészítés)
Meg kell határozni ebben az esetben, hogy egy tárhelyen csak
raklap lehet -e, vagy lehet egyedi csomag is.
Kell -e tárhelytérkép? Ha igen elég -e listában
megjeleníteni, vagy grafikusan is kell? Meg kell határozni,
hogy a raktáron belüli tárhelyek közötti mozgás vezérlése
hogyan történjen. (Fogd és vidd módszer, vagy listás
rögzítéssel egyikről ki - a másikba be.)
Meg kell határozni, hogy milyen készletkezelési szint legyen
figyelve:
"A1": minimumkészlet
"A2": optimális alsó határa
"A3": optimális felső határa
"A4": maximális szint (és akkor mi történjen?)

Készletkezelési elv: FIFO, FEFO, LIFO
Termék nyomonkövetési szabályai, termékvisszahívási,
zárolási elv.
Bevételezéskor legyen -e automatikus betárolási javaslat.
(Ha igen, mi alapján készüljön: cikkcsoport, sarzscsoport,
optimalizált útvonal.)
Kitároláskor legyen -e automatikus kiszedési javaslat. (Ha
igen, mi alapján készüljön, FEFO elv, optimális bejárási
útvonal.)
Legyen -e túrabesorolási kapcsolat.
Azért egy partnertörzs is kell a cikktörzs mellé, mert tudni
kell kinek adom ki, kitől vételezem be. (Ebből lesz
szállítólevél, számla, stb.)

Ha ezek megvannak, ebből már egész jó raktári program lehet.
Ennek a számlázási oldala már bagatell kérdés.........
De tényleg... ;-)

BJ