F18

Sada radi po principu:

1. napravim dokument u pripremi
2. na opciju štampe dokumenta iz pripreme setuje se u tabeli fakt_doks master zapis te se pri tome setuje:
3. dodjuje se novi broj dokumenta na osnovu zadnjeg broja iz doks
4. polje m1 se setuje na "Z" (kao rezervisan zapis)
5. setuje se broj dokumenta u tabeli pripreme
6. prilikom ažuriranja dokumenta, ako je mrežna numeracija, pronalazi se ovaj broj dokumenta sa markerom "Z" i radi se update tog zapisa u fakt_doks i dodaju stavke u fakt_fakt tabelu

Postoji otvoren i ovaj tiket #25077 gdje smo već pisali na tu temu

ovaj gornji algoritam bi trebao bez problema raditi i na F18. provjeri.

Uključiti kod nas.

I to u F18 ne radi!

Treba ispravit par stvari

kada već radiš ... preskoči dbf/semafore na ključnim mjestima.

znači kada se "uzima" novi broj gledaj bazu.

mislim naravno na server db tabele

commit

ispravio sam dio gdje se dodaje append u bazu fakt_doks, to sada radi, međutim ažuriranje ne radi, ažuriranje se desi ali dokumenta nigdje

moram pogledati šta se događa kod ažuriranja u ovoj varijanti

Sama procedura ažuriranja će se trebati ispraviti, jer se uvijek dešava "INSERT" transakcija, u ovoj varijanti će trebati "UPDATE" da se dešava

čini mi se da ideš u pogrešnom smijeru.

Ovdje je (u dijelu koji utvrđuje broj dokumenta je) potrebno napustiti FMK logiku ...

zaključavanje dbf + server db putem semafora ovdje treba skroz isključiti ...

po svemu sudeći pogrešno da debugiraš FMK kod i bakćeš se sa logikom dbf/semafori.

treba direktno ažurirati serversku tabelu čime će se postići i kvalitetnije i jednostavnije rješenje.

da stvar preciziram:

1) utvrđivanje broja dokumenta treba da gleda isključivo serverske tabele, uopšte ne treba gledati dbf.

Ako ti je lakše možeš slijediti tu logiku rezervacije brojeva koja se koristila

daj_mi_slobodan_broj_dokumenta() => stavlja se broj , stavlja se ime usera da se zna ko je zauzeo tabelu

(u slučaju brisanja dokumenta pojavljuje se rupa u fakt_doks koja se popunjava kod sljedeceg uzimanja broja)

ono što je ovdje bitno jeste da funkcija daj_mi_broj_dokumenta() ne gleda dbf-ove nego serverske tabele.

kasnije se ažurira lokalno stanje ali ne sa update_server_and_dbf nego sa update_server

2) kada je korisnik dobio broj koji je validan, operacija ažuriranja je identična onoj koja trenutno funkcioniše u F18

nikakvko žongliranje i komplikovanje sa markerima nije potrebno.

trenutno je problem sve ovo "umotati" u jednu transakciju (za to su potrebni semafori v1.1) što bi proceduri dalo potrebnu robusnost, ali se i sada bez problema može dobiti zadovoljavajuče, sigurno puno bolje i jednostavnje rješenje nego je to postojeća implementacija mrežne numeracija u FMK koja je zbog tehnoloških ograničenja neminovno bila komplikovana.

Ma da ti kažem, nisam ni mislio nastavljati tako, nego sam samo postojeći kod otkočio pošto je izbacivao greške.

a ono rekao si da provjerim da bi to trebalo raditi bez problema, mislim postojeći kod, pa eto

pretpostavio sam, ali svakako od početka moramo imati jasnu strategiju šta želimo.

dovođenje stanja na nulu u ovom slučaju će najprije biti izbacivanje nepotrebnog koda za mrežnu numeraciju.

Kada uključiš mrežnu numeraciju sam dio ažuiraranja dokumenta treba biti 99% identičan postojećem kada je mrežna numeracija = N.

ključna razilika je dodjeljivanje broja i nju treba napisati u par čistih funkcija koje direktno rade sa serverskim tabelama.

evo jedne super jednostavne implementacije

funkcija get_next_broj_fakture()

cBroj := get_globalni_parametar(10/broj_dokumenta")

ova implementacija znači ima brojače za svaki tip dokumenta posebno kao globalne serverske parametre

Ona ne handlira rupe (ako jedan korisnik izbriše dokument iz pripreme, a ranije je uzeo broj)

sljedeća je već puno pametnija:

cBroj := get_globalni_parametar( ...)

for i:=1 to 10

   // da li je zauzet raniji broj, pogledaj na serveru
   if da_li_je_zauzet_broj(cBroj minus i)
            daj korisniku raniji broj
   endif
next

ova implementacija znači gleda 10 brojeva unazad i popunjava rupe u numeraciji.

čitav ovaj algoritam riješen je znači sa par serverskih parametara i provjerom da li na serveru imamo određeni broj dokumenta u fakt_doks.

Ovo je jednostavno ali radi posao siguran sam puno bolje nego li FMK mrežna numeracija

Nikakvi lokovi fakt_doks nam ne trebaju

Međutim i dalje mi nije jasno...

radna stanica 1 pravi dokument i dodjeli joj sa servera novi broj, recimo 00532 (dokument je u pripremi)

radna stanica 2 pravi dokument i dobija identičan broj 00532

opet imamo 2 ista broja.

Treba napraviti na način da se dodjeljeni broj upiše kao parametar, nešto slično kao kod automatskih PLU kodova...

Tako da ćemo u parametrima imati:

• fakt_10_broj = 00520
• fakt_11_broj = 00125
• kalk_10_broj = 00012
• itd...

Kada pozovem funkciju ona mi praktično treba uvećati ovaj broj i upisati ga na server tako da drugi operater dobija odmah drugi broj i slično.

Brojač dokumenata treba upakovati u jednu funkciju, gdje će se koristiti za sve module.

Parametri su:

• modul
• firma
• tip dokumenta

E sada, imamo i one varijante sa sufiksima i prefiksima itd... znam da to KALK koristi recimo.

čitam komentar 12 još...

ako napravim ovako:

• daj_mi_zadnji_broj_iz_sql -> i da mi broj 00520
• pravim insert na server -> tabela doks sa brojem 00521 (uvećan broj za 1)

zatim u fakt-u recimo se mora izmjeniti logika ažuriranja dokumenta, treba se izbaciti postojeća sql funkcija ažuriranja i ići na varijantu

• update_rec_server...

jer ta funkcija onda odradi

• delete
• insert

tako da će mi pobrisati ovaj append koji sam dodao i zamjeniti ga sa pravim dokumentom

hm...

Ali je onda to uvijek mrežna numeracija dokumenta.

da, tako nešto slično si ti već stavio na 18 komentaru...

znači čak i taj update fakt_doks na serveru ne treba, nego upravo sa globalnim parametrima.

Ima samo jedan problem u cijeloj priči a on je sljedeći:

• radna stanica 1 uzme novi broj - globalni parmetar se setuje 00520
• radna stanica 2 uzme novi broj - opet se setuje na 00521

• radna stanica 2 ažurira dokument - ok
• radna stanica 3 uzima novi broj - globalni parametar prolazi zadnjih 10 i vidi da u bazi nema 00520 ažiriran i daje taj broj

jer radna stanica 1 još radi na dokumentu

to je varijanta koja popunjava praznine i ona će tu napraviti problem

U slučaju da samo gledamo brojač globalnog parametra stvar će raditi, ali su moguće rupe.

Saša Vranić je napisao/la:

Ali je onda to uvijek mrežna numeracija dokumenta.

Pa naravno

F18 treba napraviti da svi brojači dokumenata funkcionišu po sličnom principu kao što smo radili kod FMK FAKT mrežne numeracije.

To ne treba biti nikakva posebna opcija nego standardno funkcionisanje brojača dokumenata.

Kada se to napravi za FAKT, isto treba uraditi za sve brojače

Saša Vranić je napisao/la:

U slučaju da samo gledamo brojač globalnog parametra stvar će raditi, ali su moguće rupe.

To nije neki problem. Kao da se i sada ne može desiti rupa.

Bitno je da se u normalnom scenariju rada ne dešavaju konflikti. Bitno je i da algoritam ne bude "rocket science" kako je manje-više sada.

Dobro, znači idemo na tu varijantu

čitav koncept dodjeljivanja broja je po meni sporan, i o tome sam već pisao.

Do ažuriranja broj dokumenta ne bi ni trebao da postoji, odnosno trebalo bi da stoji jasna oznak PRIPREMA pa neki privremeni broj koji u konačnici može biti zamjenjen brojem koji nam brojač nudi.

1. broj dokumenta se dobija kada se izvrši privi puta štampa dokumenta iz pripreme
2. ako se nakon toga dokument izbriše moguća je rupa u numeraciji
3. rupa se može popuniti ručnim navođenjem - ispravkom broja dokumenta

Saša Vranić je napisao/la:

da, tako nešto slično si ti već stavio na 18 komentaru...

znači čak i taj update fakt_doks na serveru ne treba, nego upravo sa globalnim parametrima.

Ima samo jedan problem u cijeloj priči a on je sljedeći:

• radna stanica 1 uzme novi broj - globalni parmetar se setuje 00520
• radna stanica 2 uzme novi broj - opet se setuje na 00521

• radna stanica 2 ažurira dokument - ok
• radna stanica 3 uzima novi broj - globalni parametar prolazi zadnjih 10 i vidi da u bazi nema 00520 ažiriran i daje taj broj

jer radna stanica 1 još radi na dokumentu

ne. mislim da komplikuješ.

posljednji dokument tipa 10 je 100, u pripremi.

Brojač 10-last_brdok = 100

user hernad unosi u pripremu novi dokument. Dobija broj 00000 (nema broja)

Vrši štampu dokumenta => dobija broj 100 + 1 = 00101

user vsasa unosi istovremeno kada i hernad drugi dokument tipa 10.

Dobija isti broj 00000 (nema dodjeljen broj)

Šalje dokument na štampu. hernad je već odštampao dokument 00101.

Brojač je u tom trenutku 101, on dobija 102 => broj dokumenta = 00102.

Znači davanje broja dokumenta TEK prilikom prve štampe omogućava nam da započnemo unos dokumenta i odustanemo bez ikakvih konsekvenci, odnosno "rupa".

takođe broj dokumenta 0 (odnosno 00000 ovisno od načina generacije brdok-a) nam jasno kazuje stanje - ovo je dokument koji tek unosimo, sa njim možemo raditi šta god želimo.

praktično sve što dodajemo je jedan jednostavni globalni brojač po tipovima dokumenata.

kada proširim priču na sve programske module imam:

fakt/10/brdok
fakt/20/brdok
fakt/25/brdok
fin/10/brdok
fin/IF/brdok
kalk/16/brdok

brojač treba biti najobičnija numerička vrijednost

dobro, to je jednostavna priča :)

Imamo brojače po kontima, sufiksi, prefiksi koji se koriste i aktuelni su

Saša Vranić je napisao/la:

dobro, to je jednostavna priča :)

Imamo brojače po kontima, sufiksi, prefiksi koji se koriste i aktuelni su

sve to možeš zadržati.

sufiksi se tvore opet na osnovu broja

znam da kod nekih korisnika postoje varijante kod kojih su se koristili i neki dodatni uslovi za brojače dokumenata

ali to sve se može primjeniti na ovaj gornji princip bez ikakvih problema.

recimo želim da svaki korisnik ima svoj brojač. To naravno mora biti poseban parametar na nivou korisnika.

Ali se opet svodi na to da dodajemo brojače koji funkcionišu:

fakt/10/hernad/brdok
fakt/10/vsasa/brdok

i opet su sami parametri najibičniji globalni parametri - brojevi.

na chatu govoriš da su brojači dokumenata u KALK po brojevima konta.

To ima smisla.

Evo takvog seta parametara

kalk/10/1310/brdok
kalk/10/1311/brdok

ukratko opet se sve svodi na istu priču - obične brojače. samo što ih ima više.

mislim na ovo:

magacin 13201 koristi sufix /1 i brojač mu ide:

• 00001/1
• 00002/1
• itd...

magacin 13202 koristi sufix /2 i brojač mu ide:

• 00001/2
• 00002/2
• itd..

ma ja, to je to

ključna stvar je da se logika ažuiranja uopšet ne mjenja i da se sve te specifičnosti bez problema mogu dodavati.

Naravno bitno je da sve te specifičnosti budu nešto što opet neće činiti kod nepreglednim.

Zato je bolje, ako je to neophodno, uraditi glavne - najjednostavnije varijante a onda te specifične varijante dodavati jednu po jednu.

Bitno je da iz svega ovoga dobijemo pregledan kod i da ono što smo osposobili radi kako treba.

Logika koju ćemo ovdje primjeniti sa pripremom i "0" brojem dokumenta je već aktuelna u modulu RNAL.

Prva varijanta je pala :)

commit

znači kod unosa dokumenta sam ukinuo dodjeljivanje broja

prilikom štampe se provjerava da li treba dodjeliti broj pa se i dodjeljuje...

ili ako drito ažuriramo

Znači u pitanju su dvije funkcije koje se koriste:

Prilikom štampe prvo se poziva fakt_set_broj_dokumenta() funkcija koja odlučuje da li će puniti broj dokumenta ili ne.

Funkcija koja generiše novi broj je fakt_novi_broj_dokumenta()

Evo obrade štampe (c+P) ovdje čisto da se vidi kako se koristi.

Funkcija za dodajeljivanje broja također, ako nema broja u parametru potraži zadnji iz baze pa setuje...

To je kada prvi put nakon uvođenja štampamo

Izbrisao sam iz fakt-a jedno 10 funkcija za određivanje novog broja.

fanovibroj()

fakt_naredni_broj()

odredinbroj()

nbroj()

itd...

commit

dobro, nastavljam sutra

očistiti još kod ažuriranja, ono gMrezno itd..

Kod ažuriranja je sve ok, ta je funkcija davno korigovana.