Szállítólevélen minden termék mellé valahogy be kéne tuszkolni a VTSZ számot

Amennyiben a raktármodul aktiválva van és ha különböző sarzsú de azonos termékeket teszünk rá egy szállítólevélre akkor mikor fel akarjuk dolgozni ezt a szállítólevelet, a számlán is ugyanígy több sorban jelenik meg az adott termék.

Éva kérése alapján ezen termékeket vonja össze a számlán 1 sorba.

Felmerülő problémák:

Példa eset:
X termékből

• QQQ sarzs számmal, 5 db szerepel a szállítólevélen
• ZZZ sarzs számmal, 3 db szerepel a szállítólevélen

1. probléma:

Ha az összevonást már a szállító -> számla összekészítéskor meg akarnánk csinálni akkor ha nem mindent emelünk be, csak bizonyos mennyiségű terméket, akkor "visszamódosítás" esetén (a már átpakolt tételeken módosítunk és csökkentünk rajta) nem tudja a program, hogy hova pakolja vissza a különbözetet.

1. Átrakunk 2-t QQQ-ból és 2-t ZZZ-ből
2. Módosítjuk az átpakol 4 db-ot 3 db-ra
3. A visszakerült 1 db QQQ vagy ZZZ-be menjen?

Lehetséges megoldás:

Egy extra felugró ablakkal ki lehetne választani, hogy melyikre tegye vissza.

2. probléma:

Az összevonást csak akkor végezzük el mikor felugrik a számla form ahol már nem lehet a tételeket módosítani. A gondot az okozza, hogy a számla rögzítése után mikor a szállítóra lekönyveli a SZAMLA_UJ tárolt eljárás, hogy mennyit lett az egyes tételekből kiszámlázva, az első lehetőséget megragadja és a teljes mennyiséggel frissíti.

1. Átrakjuk a 5 db QQQ-t és 3 db ZZZ-t
2. Számlát elkészítjük
3. A szállítólevél nem lesz feldolgozott állapotú. Tétel szinten a QQQ sarzsúra el lesz könyvelve 8 db számlázott tranzakció, a ZZZ sarzsúra 0. Extra poén, hogy kvótára -3 értéket hoz (kvóta = mennyiség - számlázott)

Lehetséges megoldás:

Le kéne tárolni a számla készítése előtti állapotot és aszerint visszaírni a kvótát

Jelenlegi állapot

Egyelőre kiveszem az összevonást mert egy csomó plusz munka és eleve ritkán fog előfordulni, hogy össze kell vonni 2 vagy több sort.

DB frissítés menete:

1. A frissítő script elindításakor a script mellett kell lennie egy *.sql fájlnak ami a migrációhoz szükséges scriptet tartalmazza, valamint egy dbs.exe-nek. Ezek nélkül nem indul el a folyamat. Induláskor a scriptnek meg kell adnunk egy új célverziót. Ha nem adunk meg, nem indul el a script futása.
2. Migrációs script elkészül ami elvégzi az adatbázis szintű módosításokat az 1-es verzióról a 2-es verzióra. A script futtatásánál a következő teendők/kritériumok vannak:
   1. Távoli és automatizálható (nem VNC/TV!) kapcsolat.
   2. A távoli adatbázisok DB_VERSION értékét le kell kérdezni és ellenőrizni, hogy azok kisebbek az új célverziónál. Ha több mint 1-el kisebbek, akkor figyelmeztetni, hogy biztosan akarjuk-e futtatni a frissítést.
   3. Adatbázis backup futtatása frissítés előtt (emiatt kell a remote connection). A futás sikerességéről egy válasz kell.
   4. Update script futtatása. Siker esetén adott response. Nagyobb update esetén (séma változás, fontos adatokkal variálás) FRISSITES tábla törlése, DB kapcsolatok eldobása (DB motor restart?) majd a kapcsolatok nélküli adatbázis frissítése. Esetleg érdemes egy DB_VERSION hasonló változót létrehozni DB_UPDATING és DB_UPDATETIME névvel. Ha éppen updating van ÉS még nem telt el ~1-2 perc akkor nem lehet bejelentkezni senkinek. Ezt majd a DBS-sel kell lekezelni. Ha már letelt 1-2 perc akkor le kell szarni mert könnyen lehet, hogy itt is beragad egy DB_UPDATING kapcsoló frissítés közben aztán akkor megint lehet kijelentkezni.
   5. Adatbázisban a DB_VERSION univerzális változó értékét megnövelni az aktuális verzióra. Visszajelzés a sikerről.
   6. Fontos, hogy a teljes folyamat párhuzamosan fusson le telephelyenként. Tudnunk kell, hogy minden telephelyhez sikerült csatlakozni, mindenhol sikeresen(!) lefutott a backup és sikeresen lefutott az migrációs script.
3. Amennyiben az előző folyamat sikerrel zárult, a script ellenőrizné, hogy található-e másik exe fájl az FTP könyvtárban. Ha található akkor létrehozna az aktuális dátum+idő névvel egy új könyvtárat az FTP-n és oda áthelyezné azt. A lényeg, hogy csak 1 exe fájl legyen az FTP-n. Ezek után az aktuális dbs.exe-t feltenné verziószám.exe néven. Így nincs szükség info.txt fájlra, azonnal meg lehet állapítani, hogy az aktuális fájl milyen verziójú.
   Opcionális: Mielőtt az egész 2. folyamat megindulna, ha a script valami rendszer hívással le tudná ellenőrizni a mellette található dbs.exe "tényleges" verzióját (windowsban jobb klikk -> properties -> details és ott a verzió) az jó lenne. Így összevetné az átadott célverzióval és ha nem egyezik a kettő akkor megállna a frissítés.

6 use-case állhat fenn:

1. FTP-n levő DBS verzió a 2-es, usernél levő verzió 2-es, az adatbázis verziója 2-es: Nem kell frissíteni mert nincs új verzió
2. FTP-n levő DBS verzió a 2-es, usernél levő verzió 1-es, az adatbázis verziója 2-es: Ez az ideális sorrend, a user kliense frissül
3. FTP-n levő DBS verzió a 2-es, usernél levő verzió 2-es, az adatbázis verziója 1-es: Ez elvileg nem fordulhat elő. Ha mégis, akkor jelezni kell a usernek, hogy lépjen kapcsolatba a fejlesztővel mert az adatbázis nincs frissítve.
4. FTP-n levő DBS verzió a 2-es, usernél levő verzió 1-es, az adatbázis verziója 1-es: A felhasználónál NINCS frissítés. Meg kell várni amíg az adatbázis frissítve lesz
5. FTP-n levő DBS verzió az 1-es, usernél levő verzió 2-es, az adatbázis verziója 2-es: Ez elvileg nem fordulhat elő. A felhasználónál nincs frissítés.
6. FTP-n levő DBS verzió az 1-es, usernél levő verzió 1-es, az adatbázis verziója 2-es: Figyelmeztetés, hogy szóljon a rendszergazdának, hogy nem található újabb DBS kliens, holott az adatbázis friss.

Kliens frissítés menete

1. Induláskor a program ellenőrzi, hogy milyen verziójú az adatbázis amihez csatlakozik és ezt letárolja.
2. Megnézi a helyi UpdateDirt, található-e újabb verziójú verziószám.exe. Ha az adatbázis megegyezik a saját kliens verziójával és nincs újabb DBS sem az UpdateDirben, sem az FTP-n akkor NEM frissít (lásd 1. use-case). Ilyenkor csatlakozás előtt a DB_UPDATING és DB_UPDATETIME változókat le kell kérni és ez alapján engedélyezni a csatlakozást.
3. Ha nem éri el vagy ott nincs újabb verziójú exe akkor csatlakozik az FTP-re és ugyanezt megteszi és azzal hasonlítja össze a saját verióját.
4. Ha nem tud egyik helyre sem csatlakozni vagy tud csatlakozni de ott nem talál újabb verziójú exe-t és a DB verziója nagyobb akkor kiírja, hogy szólni kell a rendszergazdának mert az adatbázis friss de csak a régi dbs-t lehet elérni (6. use-case)
5. Ha talál újabb verziójú DBS-t akkor ha azt NEM az UpdateDirben találta meg akkor először oda kezdi letölteni verziószám.exe néven.
   Opcionális: SHA hash fájlt is letölthetne FTP-ről és a végén leellenőrizni, hogy jó-e a letöltött állomány

Kliens oldali módosítások:

1. Ha nem elérhető a helyi UpdateDir, akkor mindig próbáljon csatlakozni az FTP-hez és lehúzni az új verziót
2. Ha konzolból indítjuk a dbs.exe-t a --version kapcsolóval akkor kiírná az aktuális verzióját. Ezzel ki lehetne váltani a "Frissítés menete" 3. pontjánál található "Opcionális" részt.
3. A FRISSITES táblából ki lehet szedni az updating oszlopot mert a kliens frissítése során már nem történhet adatbázis frissítés
4. Induláskor egy DB_UPDATING és a DB_UPDATETIME változók segítségével lehet eldönteni, hogy tud-e csatlakozni vagy sem.
5. SHA hash-el ellenőrizni, hogy nem sérült-e meg a fájl letöltéskor

További kérdések:

1. Reportok kezelése?
2. SHA fájl: generálás, hash feltöltése
3. Maga az update script is elvégezhetné az updatedirek feltöltését az új verzióval! Akkor a kliensnek mindig csak az updatedirből kéne lerántani az új filet!

Mivel kiderült, hogy a helyesbítőszámláknál az ID tárolás pont a fordítottja a normálisnak (az eredeti számla tárolja a helyesbítőszámla ID-jét) ezért ezt jó lenne módosítani:

2 megközelítést tudok elképzelni:

1. Szimplán átírni az értékeket egyikből a másikba (Az eredeti számlánál ha szerepel valami az ID_HELYESBITO cellában akkor azt áthelyezni a helyesbítő számla ID_HELYESBITO mezőjébe). Ezzel az a baj, hogy megtévesztő az elnevezés.
2. Létrehozni egy új oszlopot ID_HELYESBITETT névvel. A meglévő számla-helyesbítőszámla kapcsolatoknál az 1.-es pontban leírtak szerint járnánk el annyi különbséggel, hogy ebbe az új mezőbe írnánk be az értéket. Később lehet törölni a régi elnevezésű oszlopot.

Én a 2.-at javasolnám az átláthatóság végett.

Amikor helyesbítünk egy számlát és a program automatikusan kinyomtatja rögzítéskor akkor a nyomtatott számlán hibás az előlegszámlán (ha van persze) fennmaradó összeg értéke. Ha manuálisan nyomtatunk a számlalistából egy helyesbítőszámlát akkor az összeg jó.

Az lett megállapítva a vezetőség által, hogy ne tételesen legyen gyűjtve a számlán, hogy melyik termékért mennyi pontot kap, hanem amelyik tételnél be van állítva, hogy pontot ér, azoknak az értékét összeadja és minden 3500 forint után jár 1 pont a vevőnek. Ez azonban a végösszegből van megállapítva.

Ez több módosítást is magával von a programon belül. Mivel már megvalósítottál egy nagyon jó és működő rendszer ezért azt ne dobjuk ki szvsz hanem rakjuk be ezt az új módot mint egy másik pontgyűjtési rendszer.

A következőket kéne módosítani:

1. A beállításokban kell egy külön rész ahol be lehet állítani a pontgyűjtés általános szabályait. Először is kell egy checkbox ami enabled/disabledre teszi az összes pontgyűjtős controlt. A checkbox felirata lehet Pontgyűjtés bekapcsolása. Alatta/mellette kell egy textbox Általános hűségpontlépték. Mellé pedig egy kérdőjel ikon ami magyarázatul szolgál a textboxra. A magyarázat hasonló mint a terméklapon található kérdőjel szövege. Annyiban más itt a dolog, hogy ez az összeg lesz érvényes minden termékre amely hűségpontra jogosult.
2. A DB-ben az OPCIO táblában 2 új mező kell: ENABLE_LOYALTY SMALLINT DEFAULT 0 NOT NULL és GLOBAL_LOYALTY_SCALE INT DEFAULT 3500 NOT NULL
3. A termék adatlapon az első fülön az EKAER köteles checkbox mellé jobbra be lehet tenni egy másik checkboxot Hűségpont jár utána felirattal.
4. A DB-ben a termékhez kéne egy LOYALTY_ELIGIBLE mező amit az előbbi Hűségpont jár utána mező állítana 1-re vagy 0-ra.
5. A termék adatlapon a További adatok fülön a Hűségpont beállítások groupbox Visible propertyjét false-ra állítani. Ezt azért szeretném így, hogy ha esetleg utólag megint variálnak akkor ne vesszen kárba az eddig elkészített munkád.
6. A VEVO táblát ki kell egészíteni egy újabb oszloppal, LOYALTY_REMAINDER. Itt kell tárolni azt az összeget ami hátramaradt abból amit az utolsó vásárlásánál nem tudott pontokra váltani. (3500 forint után jár 1 pont. Ha valaki vesz pontot érő termékeket 10000 forint értékben akkor kap 2 pontot + 3000 kerül be a LOYALTY_REMAINDER mezőbe.)
7. A pontgyűjtő logikát átírni úgy, hogy azon termékeknél melyeknél be van pipálva, hogy Hűségpont jár utána (LOYALTY_ELIGIBLE), szummázza az összegüket és annyi pontot adjon utána, ahányszor megvan benne a 3500 forint plusz adja hozzá még az adott vevőhöz tartozó LOYALTY_REMAINDER mező összegét. Az így képződött összeg után fogja számolni a pontokat. Miután kiszámolta, a maradék összeget vissza kell írni a vevő LOYALTY_ELIGIBLE mezőjébe.

Én sem örülök neki, hogy megvariálták az egészet és félek, hogy még mást is kitalálnak hozzá. Majd beszélünk még róla, addig ne kezdd el.

A vevő adatlapon az engedélyek kezelésére szolgáló fülön 2 hibát kéne kijavítani:

• "Engdedélyszám" -> "Engedélyszám" typo
• Az a label van ott, hogy "Szakmérnök". Ez állítólag megtéveszti az adatrögzítőket mert az engedély tulajdonosa nem csak szakmérnök lehet hanem más is. Ezért ezt át kéne írni "Engedély tulajdonos"-ra

Kell egy periodikusan lefutó művelet ami összeveti a DBS készletét és a raktármodul készletét. Ha eltérést talál akkor értesíti a felelős felhasználókat.

A készlet ablakon legyen egy új gomb amire ha rákattint a user, akkor lejárati dátum szerint növekvő sorrendben listázza ki a raktármodulból azokat a rakhelyeket amin az adott termék található

Szállítónál és számlánál alul tétel résznél a termék megjelenített neve időnként le van vágva. Valamikor bekerült egy metódus/beállítás ami levágja a hosszát kb ~20 karakterre.

Szekeres Sanyi kérésére az EKAER ellenőrzést ki kell bővíteni egy új lehetőséggel. A cél az lenne, hogy a program külön kövesse, hogy egy termék EKAER kockázatos vagy EKAER nem kockázatos illetve a 2 kategóriára külön számítást végezzen a szállítólevél kiállításakor.

Feladatok:

• Program beállításoknál felvinni egy új csoportot az EKAER részhez: EKAER nem kockázatos
• Az előző pontban megemlített résznél a régi résznél fel kell tüntetni, hogy az a rész az EKAER kockázatos termékekre vonatkozik
• Az új EKAER nem kockázatos régióhoz 2 új mezőt fel kell vinni ahová az EKAER kockázatos részhez hasonlóan egy tömeg és egy érték határt lehet majd megadni. Ezen értékek 2500 kg és 5000000 Forint lesznek alapból.
• A termék törzsadatlapján szintén a fentiekhez hasonlóan szeparálni kell, hogy egy termék az EKAER "kötelességén" túl kockázatos vagy nem kockázatos. Ezt vagy RadioButtonnal vagy DropDown controllerrel lehet majd megvalósítani. A jelenlegi pipálgatós azért nem jó mert egyszerre lehetővé teszi, hogy egy termék kockázatos és nem kockázatos legyen egyszerre.
• Az EKAER számítás algoritmusát frissíteni kell, hogy a fenti határértékeket is vegye figyelembe.

1.: Csak 1 példányt lehessen indítani belőle
2.: Le lehessen csukni a jobb alsó sarokba

Kéne csinálni egy megoldást arra, hogy egy kattintással/paranccsal tudjunk deployolni az FTP-re és olyan verziót ami az SVN alapján lett lebuildelve.

Az implementáció teljesen mindegy (batch, python, stb) de jó lenne ha valami scriptnyelvben íródna, hogy könnyű legyen helyben módosítani.

A szükséges lépések:

1. SVN-ből checkoutolja a trunk legutolsó verizióját egy üres mappába
2. A checkoutolt forrást buildelje le.
3. Az FTP-n levő verzióról csináljon egy biztonsági mentést (mentse le a dbs.exe-t és az info.txt-t egy külön almappába aminek a neve az FTP-n levő előző verzió legyen)
4. A lebuildelt exe-ből szedje ki a verziószámát
5. Generálja le az info.txt-t a verziószám és az update igénye alapján (paraméterben adnánk meg, hogy 0,1 vagy 2-es típusú legyen az update)
6. Töltse fel az új info.txt-t és a dbs.exe-t az FTP-re

Tehát 1 vagy 2 paramétert lehetne megadni a scriptnek, attól függően, hogy a verziószámot ki tudjuk-e szedni a lebuildelt exe-ből. Ha nem akkor kézzel adjuk meg majd a script futtatásakor, hogy mit írjon az info.txt-be.

Próbáljuk meg hibatűrőre megcsinálni az ésszerűség keretein belül (pl nem kell ráellenőrizni, hogy valóban létre tudott hozni egy helyi temp mappát, stb). Ha valami hiba történik akkor hasaljon el.

Van előlegszámla. Van jogosultság. Kell jogosultság. Most nincs. Előlegszámlához jogosultság. Mert jó. A jogosultság jó. Én értem. Az előlegszámla jó.

Tudom, hogy leírtad már ezeket magadnak de ide is rögzítsük fel

• Előlegszámla létrehozásánál az egyedi tétel hozzáadása után nem frissül a teljes összeg az alsó sávban a gombok mellett (Azt mondtad, hogy azért nem ment ez nálam mert az update scriptbe nem tetted bele az egyik tárolt eljárás módosítását ami ezt elvégzi)
• Szállítólevél feldolgozásánál az előlegszámlás groupbox felirata az, hogy "Előlegszámlák". Ez legyen csak "Csatolt előlegszámla"
• Szállítólevél feldolgozásánál az előlegszámlás groupboxnál az első és a második textbox szövege legyen már úgy megfogalmazva, hogy egy 7 éves gyerek is megértse. "Előlegszámlán jelenleg található összeg (bruttó (vagy nettó, nem tudom mit írsz itt ki))" ill. "Előlegszámlán fennmaradó összeg a számla elkészülte után"
• Kimenő számlák listánál ha rákattintok a "Tartalom" gombra, hogy megnézzem a számlát akkor itt legyen már megjelenítve az, hogy milyen előlegszámla lett hozzácsatolva.

Mivel pár ADR kód hosszabb mint egy G.R.R. Martin könyv ezért előfordul, hogy nem fér rá teljesen a szállítóra. Ez azért gond mert szabály írja elő, hogy teljesen ki kell írni ami ha elmarad, vaskos százezrekre vághatják meg a céget. Az ADR megnevezések rövidítése nem megoldás.

Javaslat:
Még kisebbre venni az ADR szövegének a méretét és megnézni, hogy így jó-e.

Devizanemek kezelése a DBS-ben.

Napi szinten le kell kérni az aktuális árfolyamot, ezt le is kell tárolni az adatbázisban.

Van 1 Ft különbség a db-ből kiszedett előlegszámlán fennmaradó összeg és a dbs-ben számolt bruttóösszes között (áfánál csúszik el)

Sorbarendezés nem működik mindenhol az előlegszámla és számalista formokon miután beállitjuk a számlatípus filtert.

A felhasználó listánál jó lenne megjeleníteni, hogy az adott felhasználó melyik telephelyhez tartozik (ez lehet, hogy csak Böszörménynél érdekes mert ott látszik minden user)

Mikor a felhasználó megnyitja a kimenő szállítólevelek ablakát, akkor jelenjen meg egy plusz sávban piros színnel egy label. A label szövege legyen "Számlázatlan szállítólevelek száma: X".

Mikor X-et akarod megszerezni akkor ezekre figyelj oda:

• Próbáld meg úgy implementálni, hogy ne tegyen fölösleges kört az SQL adatbázis felé. Ha nem sikerül ilyen megoldást találni ~30 percen belül akkor maradjon az SQL lekérdezés.
• A beállított szűrő feltételek alapján számolja ki X-et
• Meg kéne nézni, hogy milyen módosítások lehetnek hatással még erre az X értékre (módosítod a szállítót, stb). Ha van ilyen a "Kimenő szállítólevelek" formon belül akkor updateld X-et. Erre se pazarolj 1 óránál többet.

Jelenleg szállítólevél feldolgozásánál, valamint kézi számla készítésénél (lehet, hogy előlegszámlánál is!) ha úgy húzunk be tételt, hogy 0-t állítunk be mennyiségnek akkor ezt engedi a program és 0 Ft-os számlát tudunk létrehozni.

Ezt meg kéne úgy akadályozni, hogy felugorjon egy figyelmeztető ablak akkor ha 0 mennyiséget akar beállítani a user egy termékhez.

Éva jelezte, hogy egyes telephelyek termékei és a központban tárolt termékek között hatalmasak az eltérések.

Példa:

• Központban Laudis beszerzési ára ~5000 Ft, eladási ára ~9000
• Nyírbátorban Laudis FIFOs beszerzési ára ~9000 Ft

Sajnos ez nem egy kiugró eset hanem rengeteg tételnél jelentkezik. Éva először felvetette, hogy valahogy a nyitó készletet kellene rendbe rakni de ezt manuálisan kéne elvégezni telephelyenként.

A probléma valójában 2 részre oszlik:

1. Tűzoltás: A jelenlegi problémák kiküszöbölése
2. Megelőzés: A következő záráskor ne forduljon elő ez a hiba

A fent említett példa alapján elsőre azt gondolom, hogy valahogy az eladási ár és a beszerzési ár összekeveredett de Éva szerint ez lehetetlen mert a többi telephely csak telephelyek közti mozgással vételez be terméket, ahol beszerzési árat nem adnak meg

A Megelőzésre javasoltam a következőt:
Év záráskor ha nem Böszörményben tolom a zárást akkor az adott telephely tolna egy mini-szinkront és leellenőrizné, hogy a központi telephelynél az adott termék beszerzési ára különbözik-e a saját termékének beszerzési árával. Ha igen akkor felülírná és a nyitó készletet az adott termékhez már ezzel indítaná.

A tűzoltásra esetleg működhet:
A megelőzéshez hasonlóan lenne egy parancs ami végigmenne a nem-központi telephely nyitó készletén és összevetné a központ nyitó készletével. Amennyiben van eltérés akkor felülcsapná a nyitó napló bejegyzés árát.

Feladatok:

• Ellenőrizni, hogy a nyitó készletnél az árakat hogy számítja ki a program (átlagol, utolsó ár, egyéb más)
• Megnézni, hogy mi írhatja felül a beszerzési árat automatikusan.
• Megvizsgálni 1-1 példa-problémát és megkeresni az esetleges okokat

A Vevő formon az Engedélyek fülön találhatóak a vevőkhöz tartozó szakmérnökök, zöldkönyvek adatai. Jelenleg nem lehet ezeket törölni ha van hozzájuk tartozó számla, ilyen márpedig szinte mindig van. A következőt kéne módosítani:

1.: Hozzáadni egy TOROLVE mezőt a VEVO_ENGEDELY táblához ami NOT NULL és default 0

2.: Módosítani a vevői engedélyekhez kapcsolódó lekérdezéseket, tárolt eljárásokat. Ezekből jelenleg 2 jut eszembe:

1. A vevői módosítás formon az Engedélyek fülön szereplő datagrid. Itt pirossal kellene megjeleníteni azokat a bejegyzéseket amelyek már törölve lettek. A törölt engedélyeket NEM lehet módosítani/törölni. Ezekre a gombokra szimplán ne reagáljon semmit a program.
2. CHECK_WORK_ENGEDELY. Ebben a tárolt eljárásban kérdezi le a program, hogy a szállítólevélre való kiírásnál rendelkezik-e a vevő a megfelelő engedélyekkel. Itt kulcsfontosságú, hogy csak azokat nézze amely engedélyek nincsenek törölve.

Természetesen lehet még más helyen is rá hivatkozás/utalás. Azon kívül, hogy átgondoljuk, hogy mik lehetnek ezek, a legbiztosabb az lenne ha az egész adatbázis scriptjét ki tudnád exportálni egy fileba az adatok nélkül (tehát csak a tábla sémákat, tárolt eljárásokat, stb) és ebben a fájlban keresnél rá a VEVO_ENGEDELY táblára. Illetve ugyanezt a DBS forráson is meg kéne csinálni, hátha ott is van 1-2 kósza utalás rá.

Mikor eladásra kerül egy 1-es kategóriás termék akkor:

1. Pirossal jelölje az 1.-es kategóriás termékeket a tételeknél
2. Ha a termék felvitelekor nem ad meg 1-es kategóriás terméknél receptet, akkor ugorjon fel egy ablak, hogy "A termék I. kategóriába tartozik és nem adott meg receptszámot. Biztos folytatja?". Ha igent nyom akkor adjuk csak hozzá a tételekhez üres recept azonosítóval, nemnél pedig fennmarad a popup ablak ahol megadhatja a recept számát.

A jelenlegi "Vevő kedvezmény fej" és "Vevő kedvezmény részletes" menüpontokat át kell dolgozni. A feladatok:

• Új jogosultság típust kell felvinni, külön a kedvezmény fejre és részletre. Ha valaki nem rendelkezik ezekkel akkor ne láthassa ezeket a menüpontokat
• Ellenőrizni, hogy a szinkron áthozza-e a kedvezmény fejet és részletet
• Ellenőrizni, hogy egyáltalán be van-e állítva szinkronizálásra a kedvezmény fej vagy kedvezmény részlet
• A tblVevoKedvFej táblából udm-ben ki kell szedni, hogy csak akkor jelenítse meg a kedvezményeket, ha az adott telephelyen lett létrehozva
• A vevő kedvemény fej formját át kell állítani, csak egy számot kelljen beírni és azt lementeni. Ne legyen grid

Jelenleg egy szállítólevelet úgy tudunk feldolgozottra állítani, hogy a STATUS mezőjét 2-re állítjuk. Ezt egy tárolt eljárás végzi most ami akkor fut le, mikor számlát készítünk egy szállítóból. Ez megvizsgálja, hogy a szállítólevél kvótája mennyi (a szállító tételeiből mennyi lett kiszámlázva) és az alapján állítja át ezt az értéket.

Ezzel 2 baj van:

• Valamiért néha nem állítja át a STATUS mezőt a tárolt eljárás. Ez sokszor előjött az emődi telephelyen és csak ott
• Ha konkurrens feldolgozása folyik egy szállítólevélnek akkor átmehet a kvóta minuszba is

Feladatok:

• Megvizsgálni, hogy a STATUS mezőt ki lehet-e iktatni, mennyi a referencia rá.
• A Szállítólevél listázásnál a feldolgozottság állapotát ne a STATUS alapján nézze a program hanem KIHIVATKOZAS / KIHIVATKOZASTETEL tábla alapján nézze meg, hogy a kvótát meghaladja-e a tételek mennyiségének összege. Ha igen, akkor már feldolgozott az adott szállítólevél
• Mikor egy számlát elkészítünk egy szállítólevél alapján akkor az "Számlázás" gombra kattintva még egyszer ellenőrizze le a program, hogy nem-e megy át így minuszba a kvóta.

Ha egy előlegszámlát hozzáadunk egy számlához, számlázunk, majd ezt a számlát helyesbítjük és utána stornózzuk akkor a csatolt előlegszámlára nagyobb összeg kerül mint ami eredetileg volt rajta.

Egy számla többszöri helyesbítése számolási hibákhoz vezet. Nem kéne engedni, hogy egy helyesbített számlát lehessen újra helyesbíteni ha a róla készült helyesbítőszámla nincs stornózva. (a kérdés, hogy egyáltalán ez irl lehetséges e vagy van rá valami törvény vagy full valid eljárás)

A címben benne van minden. Esetleg be lehetne tenni további oszlopokat is a dátumokkal kapcsolatban.

Kéne olyan funkcionalitás, hogy előlegszámla:

A számla felépítése hasonló a normális számlához, az alján viszont az szerepel, hogy mely termékhez fizetett előleget.

A végszámla amit egy előlegszámlához készítünk lezárja az előlegszámlát. Az alján szövegesen szerepeltetni kell a teljes eredeti összeget valamint az előlegszámla tételeit mínusz előjellel.

Specifikáció:

• Előlegszámla működése: ABC ügyfél befizet 50 millió előlegszámlát. Ekkor még nem kap semmit mivel ezt akkor használjuk ha a terméket még nem tudjuk átadni az ügyfélnek. Tételként kerülhet rá konkrét termék de kerülhet rá egy egyedi sor is (pl az, hogy "Szerződés szerinti előleg"). Ha pl rendel 20 millióért Gladiatort, 30 millióért műtrágyát és megjön a Gladiator akkor ha elkészült a szállítólevél akkor készülhet egy Végszámla amihez egyszerre kell csatolni az adott előlegszámlát illetve az adott szállítólevelet. Az előlegszámla lehet, hogy egy ideig csak részlegesen lesz feldolgozva, pl az előbbi esetben maradna 30 millió még az ügyfél "bankjában".
• Előlegszámla készítése és listázása külön ablak az "Értékesítés" menüben. Itt egy lista jönne fel amit lehetne szűrni ügyfél és státusz alapján alapján. Státusz lehet az, hogy felhasználatlan, részlegesen felhasznált vagy teljesen felhasznált/lezárt.
• Ugyanúgy kell szerepelnie a "Szállítólevelek feldolgozása" -> "Számla" menüponton belül. Itt ki lehetne választani, hogy előlegszámláról szeretnénk behúzni
• Egy végszámlához mindig tartozik egy előlegszámla és egy szállítólevél

Az előlegszámlához is kell sztornó, helyesbítés, összegzés mint a sima számláknál

2 esetben kell dropshippinget használni:

• Egy árú egyenesen kimegy egy ügyfélnek
• Egy árú egyenesen átmegy egy telephelyre

Ami fontos, hogy ezen funkciók NEM használnk a raktármodult. A háttérben mindegyik egy bevételezéssel kezdené majd vagy egy kimenő szállítót vagy egy telephelyi átadást csinálna azonnal.

Szanka Imre kívánsága.
Ők nap közben sokszor úgy rögzítenek szállítókat, hogy hozzáadja mondjuk du. 1-kor, majd hozzáad még egy tételt du. 2-kor. Ha azonban jön egy tök másik vevő akkor dobniuk kell az eddig felvitt félkész szállítót.

Javaslat: Nem csak egy "working-state" szállító lehetne hanem bármennyi. Ezek ilyenkor draft állapotban lennének.

#4 alapján az 1. pontban vázolt DB módosítások a következők:

• Számlatétel táblában az ID_TERMEK mező nullázható kell hogy legyen. Amikor előlegszámlánál egy szöveges sort viszünk fel akkor ID_TERMEK értéke NULL lesz és a szöveget a COMMENT mezőbe kell letárolni. Amennyiben nincs még COMMENT oszlop akkor létre kell hozni.
• Mikor kilistázzuk az előlegszámla tételeit akkor a megjelenített szöveg attől függően lesz kalkulálva, hogy az ID_TERMEK értéke null-e. Ha igen akkor a COMMENT mező, ha nem akkor a kapcsolódó termék NEV mezője a megjelenítendő szöveg.

A jelenlegi manuális folyamatot kéne automatizálni. Teljesen mindegy, hogy batchfilelal, valamilyen scripttel vagy programmal végeznénk el. A cél az, hogy hibatűrő legyen és ha nincs gond akkor magától elvégezze a teljes telepítést.

A telepítés lépései:

1. Leállítani a szinkront
2. Leállítani a futó DBS(eke)t
3. DB backupot csinálni
4. DBS frissítését elindítani

Az első 2 pontot meg lehet batchből is oldani taskkillel. A 3. pont már most megvan batch filelal valósítva.

A DBS frissítéséhez lehet, hogy a programon is kéne módosítani. Meg kéne csinálni úgy, hogy ha bizonyos kapcsolóval futtatnánk le a DBS-t command lineból, akkor automatikusan lefutna a frissítés mindenféle visszakérdezés nélkül. Ebben benne van a FRISSITES tábla törlése, az FTP-n levő verziószám ellenőrzése, letöltés és a jelenlegi DBS felülírása majd futtatása.

Bevételezéskor lehet, hogy egy csomagot hoznak amit sok esetben össze kell vonni. Ez csak "virtuális" csomagoknál lesz majd szükséges. Ezen csomagok fizikailag nincsenek egy dobozba összerakva hanem egyszerűen csak olcsóbb őket egybe megvenni.

Ennek az az oka, hogy mikor bevételeznek a raktárosok akkor ők nem tudják, hogy egy adott termék csomagnak lett rendelve vagy "sima" terméknek. Mikor a DBS-ben átvesszük ezeket akkor meg kell adni a lehetőséget, hogy össze lehessen vonni egy "Csomag összevonás" gombbal a tételek közül azokat amik összevonhatóak.

Azon vevőknél akiknek nincs adószáma (minta: 12345678-9-01) azoknak ne lehessen szállítót és számlát kiállítani.

Még nem biztos, hogy ezt le kell fejleszteni. Majd értesítenek ha van valami.

A CRM alkalmazást be kéne tolni a DBS-be

Egyre többször előfordul, hogy olyan lekérdezésekkel nyaggatnak az alkalmazottak amiket az "Általános lekérdezések" menüpontból nem lehet összerakni. Ennek az az oka, hogy az általános lekérdezésekben nem tudnak maguk készíteni bonyolultabb kapcsolt táblákat, de még ha meg tudnák csinálni akkor se tennék meg mert nem értenek hozzá.

A Lekérdezések menüpontba kellene egy Speciáli lekérdezések almenü. Ha erre rákattint valaki akkor felugrik egy form ami az frmVerzio-hoz hasonlít. Egy lista megjeleníti a lekérdezéseket, mellette pedig egy label egy rövid leírást ad az adott lekérdezésről. Annyit kell módosítani, hogy a betűk a listában és a leírásban is nagyobbak legyenek. A lista hard-coded lesz, nem adatbázisból szedi ki a program.

Ezek után ez a form eltűnne és felugrana egy másik ami 2 részből áll: Paraméterek illetve a datatable ami megjeleníti az eredményeket. A paramétereket felosztanám 2 groupboxba, kötelező és opcionális.
A formon 2 gomb lenne, egy Lekérdez és egy Excel export gomb.
Mikor a lekérdezést lefuttatja a user akkor fontos, hogy az SQL parancsot nem string összefűzéssel rakjuk össze hanem paraméterek használatával. Ez az SQL injection kivédése miatt kell.

Ami nehézséget fog okozni majd az a paraméterek bevitelére szolgáló input controlok dinamikus hozzáadása a formhoz. Ezt a végére hagyni.

Implementációs sorrend:

1. Form a lekérdezés kiválasztásához
2. Form a lekérdezés futtatásához paraméterek nélkül
3. A lekérdezés eredményének exportálása
4. DSL írása a speciális lekérdezések paramétereihez
5. Paraméter inputok dinamikus létrehozása a lekérdezés formon