Greska br. 1:

"Private Sub Izlaz_Enter testom" ; Naziv procedure mora biti jedna rec, tj. ne sme imati SPACE kakraktere

Greska br. 2:

Losa IF...THEN...ELSE konstrukcija, tj. ili ces pisati

umesto

ili ces dodati jos jedno End If na kraju.

SAVET: koristi uvlacenje blokova sa tabovima da bi lakse otkrila gresku.

Nisam nigde definisala proceduru vec sam u polju

Private Sub Izlaz_Enter

a do kog sam dosla linijom

Forms/Knjizenja/Design View/Izlaz/Properties/Event/On Enter/Event procedure

definisala vec napisani Code.

Sada sam Code prepravila (iako mislim da sam i to vec isprobala) i ponovo se javlja Debug okvir
pri cemu mi se javlja greska da funkcija nije definisana.

Prvo, los ti je izbor eventa. Nemoj na OnEnter, nego na BeforeUpdate i to za polje u koje unosi zeljenu kolicinu.
Logika je ovakva:

Pretpostavimo da se polje zive ZadataKolicina - to hoces da skines sa lagera
Ona ide otpriike ovako:

Sub ZadataKolicina_BeforeUpdate(cancel as integer)

IF (TrenutnoStanje(ArtiklID) - ZadataKolicina) < 0 THEN
Cancel=TRUE 'ovim se ponistava Update, nista se nece upisati u tabelu
Msg "Ne mozete izdati vise robe nego sto imate na legeru trenutmo!"
exit sub 'dalja provera nije potrebna, izlazimo napolje
END IF

IF (TrenutnoStanje - ZadataKolicina) <= [SafetyStock] Then
Msg "Trazi odobrenje za izdavanje"
End if

IF ((TrenutnoStanje - ZadataKolicina) <= [Reordering point]] Then
Msg "Treba naruciti"
End If

End Sub

TrenutnoStanje je funkcija koja u sustini radi ono tvoje SUM(Ulaz) -SUM(Izlaz). Mozes to da procitas iz kverija, ili da koristis DSum, kako god hoces, a funkcija vraca trenutno stanje za zadati artikl. Trenutno stanje je PRE transakcije koju pokusavas da odradis. Onako kako si upisala, nece raditi. Vidu temi "Kafic" ili "Magacin" ima nesto slicno (top tema "Teme koje su nekad bile top....")

Code sam prepravila prema predlozenoj opciji
pri cemu mi nije bas bilo jasno polje TrenutnoStanje(ArtiklID)s obzirom na to da
trenutno stanje u magacinu nisam definisala kroz takvo polje vec se ono
dobija bas razlikom svih ulaza i svih izlaza u izvestajima.

Razocarenje je usledilo kada se pojavio cuveni Debug okvir sa istom
greskom kako funkcija nije definisana.

Na kraju, krenula sam drugim nacinom koji mi je delovao malo logicniji,
pa sam prvo definisala to neko polje Stanje i sve je to izgledalo ovako:

Private Sub Izlaz_BeforeUpdate(Cancel As Integer)
Dim Stanje As Currency
Stanje = DSum("[Ulaz]-[Izlaz]", "[Knjizenja II]")
If [Stanje] - [Izlaz] <= [Safety stock] Then
Msg "Trazi odobrenje za izdavanje sirovine!"
End If
If [Stanje] - [Izlaz] <= [Reordering point] Then
Msg "Treba naruciti novu kolicinu sirovine"
End If
End Sub

I na kraju - nista. Sve po starom, funkcija nije definisana.....

Koje ti stanje trazis? Stanje ima smisla za tekuci artikl, otud ArtiklID. Ako izdajes iz magacina jabuke, interesuje te stanje jabuka a ne stanje krusaka. [ULAZ]-[IZlAZ] se podrazumeva za jedan odredjeni artikl, ne za ceo magacin. Ne razumem sta radis......

Koja funkcija nije definisana? Proverui da li su sve refernce OK kad budes u code modulu (Tools/Referencses)

Trece, onako kako si napisala DSUM, nisam siguran da ce da radi. Pogledaj sinatksu za DSUM u Helpu. Mislim da ne moze da se stavi DSUM("[ULAZ]-[IZlAZ]"....)

Posle nekog vremena vratila sam se svom resavanju problema.
Pregledala sam dosta tema koje su se bavile ovom problematikom
i pri tom sam videla da je nekoliko korisnika ovog foruma imalo slican problem.

Svoj prethodni Code sam prvo prepravila pri cemu sam definisala polje Stanje
koje ranije nisam ni imala u svojoj aplikaciji.
Ovim sam uspela da odstranim Debug i upozorenje kako funkcija nije definisana.

Medjutim, novi problem se odnosi na polja koja se uporedjuju u proverama
stanja odnosno novog stanja i zadatog stanja (Reordering point i Safety stock)
i njihovog ne pronalazenja u proceduri....

Ti imas mnogo problema u aplikaciji.
1) prerano si napravila aplikaciju, nis zavrsila dizajn baze
Greske u dizajnu baze:
- imena tabela i kolona sadrze razmake => mnogo teze napisati tacan kod
- imena tabela su besmislena.
- umesto "Knjizenje I" i "Knjizenje II" trebalo je 'Knjizenje' i 'StavkeKnjizenja'
- umesto "sirovibne - Materijali" treba ili "Sirovine" ili "Materijali", nikako dve reci
- umesto "Vrste Materijala" treba "VrsteMaterijala"
- za imena kolona vazi isto - dve reci zameni jednom, ako bas koristis dve reci umesto razmka stavi _ (underscore karakter)
- data integrity problems:
- tabela Knjizenje II nema PK, kolone koje bi trebalo da budu PK dozvoljavaju NULL vrednosti, vec imas jedan red koji je prazan, ne znaci nista i ni sa cim nije popvezan. Pretpostavljam da kombinacija (BrojOpisa,KontrolniBroj) cini red jedinstvenim. Ako je tako, ova dva polja moraju biti PK i moraju biti Required u tabeli.
- tabela Knjizenje II ima kolone Ulaz i Izlaz. Obe kolone dozvoljavaju NULL vrednosti. Ako se nista ne unese u ove kolone, kveru qryStanje nece rediti dobro. Znaci, treba staviti Default=0 i da su Required i Vlidation rule >0 za obe kolone . Jos jedan problem; ne sme se dozvoliti da obe kolone budu 0 istovremeno, niti da obe kolone budu >0 istovremeno. To mozes da postignes na nivou tabele. razmisli malo kako, malo matematike ce pomoci. kako da od dva broja jedan uvek bude nula? kako da dva broj u zbiru daju vrednost vecu od nule? Kad ispunis oba ova uslova istovremeno onda imas da je 'bar jedan od brojeva >0 a nijedan nije manji ili jednak nuli"

Ima jos, ali nemam vremena, mozda kasnije.

Kod koji imas na subformi "Knjizenje II" nije dobar, malo sam ga pepravio, ali jos uvek moze da ne radi sve kako treba zbog nabrojanih problema. i opet lose imenoanje. Zasto se forma zove isto kao i tabela, a oba naziva su losa zbog dve reci i razmaka?

Hvala Zidaru na pomoci.
Greske sa kojima se susrecemo u mojoj aplikaciji, bar sto se tice naziva tabela, polja i razmaka
su mi sada vec poznate, sto nije bio slucaj i pre sedam godina, kada je aplikacija otprilike i nastala.
Sada mi je tesko da menjam te greske, iako radim na tome, jer se program neprekidno koristi, i
pri svakom mom menjanju ili podesavanju baze napravim zastoj kod mojih kolega.

Nebitno, ali ono sto me samo cudi, pa cak i sa matematicke strane, da li je uopste moguce da
imam dva polja, da njihov zbir daje vecu vrednost od nule,a da pri tome jedno polje ima vecu vrednost od nule a drugo polje nije manje ili jednako nuli? Pri tome znam da mi je prilikom knjizenja jedno polje uvek 0.

Posto su nazivi takvi kavi su, sta je tu je. Budi pazljiva kad upotrebljavas nazive kolona sa razmacima, koristi uglaste zagrade [ ] i srecno.

Kako obezbediti za dva broja da tacno jedan bude veci od nule, a drugi je uvek nula?
Po matematici, ide ovako:
Imas dva broja A i B da bi bar jedan bio nula treba da je A*B = 0
Da bi bar jedan bio razlicit od nule treba da je zbir njihovih kvadrata veci od nule (A*A + B*B) > 0
Dabi oba uslova bila ispunjena, treba da stavis na nivou tabele Validation Rule. Otvoris tabelu u Design modu, pa ides na Properties i pod validation rule upises nesto kao:

(Ulaz*Izlaz = 0 AND (Ulaz*Ulaz+Izlaz*Izlaz)>0)

Ovo sve ne vazi nista kao je bilo koji od brojeva NULL, posto NULL * A = NULL i NULL*NULL + B*B = NULL

Znaci, moras da stavis da ti kolone za Ulaz/Izlaz ne smeju biti NULL, a to je Required=Yes za svaku od ovih kolona u dizajnu tabele

Da ne bi bili manji od nule, stavis za ove kolone da je Validation Rule: >=0 i Default Value = 0

Ja sam probao tvoju formu, nije radilo, pa sam napravio moju i pri prvom pokusaju sam 'uneo' NULL u Ulaz jer sam samo upisao 50 u izlaz. To naravno moze da se spreci na nivou aplikacije, ali nikad ne znas kad ce neki nepazljivi programer kao ja da napravi novu aplikaciju, za usko specijalizovani zadatak, i da ti isprlja podatke.

Posto sam uneo NULL, onda qryStanje nije radio korektno jer NULL vrednosti su kvarile SUM([Ulaz]-[Izlaz]) - uvek je pokazivalo ist netacan broj. Ako ocekuje da neka od velicina u agregatnoj funkciji bude NULL, koristi NZ funkciju da zamenis NULL sa recimo 0 Nz(Ulaz,0) i Nz(Izlaz,0). Onda ce kveri da ti radi. Ali da se ne bi mucila, lakse je da jednom za svagda resis problem tako sto ces da u dizajnu tabele postavis uslove i to ti garantuje da u tabeli nemas djubre ni pod kojim uslovima.

Mnogo j bolje da kveri ili forma prijave gresku i ne rade uopste, nego da prikazuju lazne podatke. Sa NULL vrednostima, sanse za lazne podatke rastu strahovito. Za kveri i formu koja ne radi, radis prekovremeno da resis problem, a za lazne podatke u finansijskom izvestaju ides u zatvor, a da nisi ni svesna zasto su podaci u izvestaju lazni.

Pogane NULL vrednosti, crkle dabogda

Da li bih sve ove probleme uspela da izbegnem ako bih razdvojila
tabelu ulaza i tabelu izlaza?

Mislim da bih da na taj nacin jednostavnije podesila Validation Rule a
pretpostavljam da bi i problemi u qryStanje bili time otklonjeni.

Gresim li?

Ne mislim da bi razdvajanje ulaza i izlaza resilo problem NULL vrednosti. I u tim tabelama bi morala da stavis da je polje Ulaz/Izlaz required (NOT NULL) i verovatno >0. Ne bi morala da resavas samo vezu izmedju ulaza i izlaza. Ali, zato bi qryStanje bio kombinacija tri izvora podtaka, sa dva LEFT JOIN. Zasto?
Verovatno u qryStanje zelis da izlistas SVE artikle, pa i one koji nisu imali ni jedan ULAZ ili ni jedan IZLAZ. Treba ti dakle nesto kao

SELECT tblARtikli.ArtiklID, SUM(tblUlaz.Ulaz) AS SUM_ULAZ, SUM(tblIzlaz.Izlaz) AS SUM_IZLAZ
FROM tblARtikli
LEFT JOIN tblUlaz ON tblARtikli.ArtiklID = tblUlaz.ArtiklID
LEFT JOIN tblIZlaz ON tblARtikli.ArtiklID = tblIZlaz.ArtiklID
GROUP BY tblARtikli.ArtiklID

Ako nemas ULAz/IZLAZ za svaki artikl, onda ce neki od tblUlaz.Ulaz, tblIzlaz.Izlaz biti NULL, pa ti opet treba ispitivanje i provera NULL vrednosti u samom kveriju koji je sada mnogo tezi za razumevanje jer sadrzi LEFT JOIN, i to dva komada. U stvari, sa dve tabele NE MOZES da garantujes da nece biti NULL vrednosti. Sa jednom tabelom i pravilno postavljenim constraints (validation rule na nivou kolona i tabele)
mozes da izbegnes NULL vrednosti potpuno i da ti kveri ostane kakav jeste, jednostavan i razumljiv.

Priznajem da ja kad pocnem projekat obicno razdvojim tabele Ulaz i IZlaz, cisto po navici, ali to ne mora da bude najbolje resenje. Meni nije posebno tesko da sastavim komplikovane kverije, pa ni ne primetim da je to u stvari lmozda i losije resenje. To je Zidarevo pravilo dobrih programera, a glasi" Dobri programeri su obicno losi data modelers" Zasto? Pa sve probleme rese programiranjem i nije im tesko da pisu komplikovani kod, uzivaju u tome, to znaju da rade, efikasno, pa tako i rade. Tako i ja. Brzo pisem komplikovanje kverije pa mi promaknu mnoga bolja resenja.

Tvoje resenje sa jednom tabelom mi u ovom momentu izgleda bolje, ukoliko se malo pritegnu srafovi dodavanjem validation rules.

Ako ti je sistem u upotrebo nekoliko godina, ni slucajno ne razdvajaj tabele, moze se desiti da pokvaris sve ostalo sto za sada radi.

Nakon svih ovih informacija i sugestija od strane Zidara,
pokusala sam da i nauceno u teoriji primenim i u praksi.

Podesila sam Properties na nivou tabele, a podesila sam i polja Ulaz i Izlaz.

Moj prvobitni napisani Code sam prepravila i kada sam krenula u proveru
ispravnosti rada tabele, pri knjizenju Izlaza sa kojim bih dobila manju kolicinu
od Reordering point dobila sam poruku da treba naruciti sirovinu ali mi nije bilo
omoguceno da knjizenje zavrsim.

Ono sto sam prepravila jeste deo Coda gde se vrsi ispitivanje stanja tj.
zamenila sam redosled ispitivanja i kako sam mogla da vidim sve je radilo
kako treba.

Sada samo sledi pitanje kako da ponistim taj red knjizenja kada pokusam
da proknjizim vise nego sto je dozvoljeno, jer se tu javlja problem
i nemogu pravilno da odustanem od knjizenja te kolicine?

Zidar će ti ovo verovatno rešiti. Ja samo želim da te upozorim da u knjigovodstvu nema brisanja i da bi trebalo uvesti kolonu storno, koja se kasnije kod izveštaja adekvatno tretira. Ne znam ti tačnu lokaciju ali ako si sa prostora gde važe JRS-33 (JUGOSLOVENSKI RAČUNOVODSTVENI STANDARD RAČUNOVODSTVENI SOFTVER) onda toplo preporučujem adresu
http://uprsys.fon.bg.ac.yu/bozic/bozic2000/jrs33.htm Verujem da će ti pomoći i oko drugih stvari.

na osnovu ovoga sam zakljucio sledece:

1) akoce novi izlaz da izazove da stanje padne ispod Reordering_Point, ond treba da se pojavi poruka, ali da se dozvoli unos.

2) kad preti opasnost da ce novo stanje biti ispod SafetyStock, onda se NE SME knjiziti dok se ne dobije odobrenje od rukovodioca. Tako sam ja protumacio pravila. Posto u momentu knjizenja ne postoji odobrenje od rukovodioca, zato valjda stoji ono Cancel = TRUE. Ako je moje tumacenje lose, izbaci tu liniju i knjizenje ce proci u svakom slucaju. meni ostaje nejasno kako se onda garantuje da ce radnik traziti zaista odobrenje od rukovodioca, i kako ce kompjuter znati da je rukovodioc izdao ili nije izdao odbrenje za izdavanje robe?



Usput, ako samo izbacis Cancel= TRUE, knjizenje ce proci i kada narucis vise nego sto imas. Na primer, imas na lageru 5 komada necega a hoces da izdas 25. Stanje ide u -25. Ako to dozvoljavas, onda si OK. Ako to ne zelis da dozvolis, onda ti treba jos neki test.

Razmisli malo o pravilu koje proizilazi iz onoga sta si nam opisala:

0 < SafetyStock < ReorderingStock

Ja bih uradio nesto ovako:

IF (Stanje-Izlaz) > ReorderingStock ==> OK, dozvoli knjizenje, nema poruka

IF (Stanje-Izlaz) BETWEEN SafetyStock AND ReorderingStock ==> OK, dozvoli knjizenje, poruka: "reorder material"

IF (Stanje-Izlaz) BETWEEN 0 AND SafetyStock ==> OK, dozvoli knjizenje, poruka: "Trazi odobrenje od rukovodioca"

IF (Stanje-Izlaz) < 0 ==> ne dozvoli knjizenje, poruka "ne mozete izadti vise robe nego sto ima na lageru"

Sa trecom opcijom, (Stanje-Izlaz) BETWEEN 0 AND SafetyStock , ponovo je nejasna situacija - kako kompjuter zna da je radnik dobio odobrenje ili da ce dobiti odobrenje? Mislim da ovo sa odobrenjem ionako nece zaziveti u praksi, proces je nejasan i nedefinisan.

Poslednji IF sprecava knjizenja koja bi prouzrokovala negativno stanje.

:-)

Program radi bas onako kako treba i kako si shvatio.

Kada prilikom knjizenja dobijem poruku "Trazi odobrenje" ta kolicina
se ne moze proknjiziti ali ne mogu da izadjem iz tog polja.
Svaki put kada se pritisne OK vrati se poruka.

Cak i kada izlaznu kolicinu postavim na nulu tesko se izlazi iz forme
knjizenja.

Postoji li mogicnost da nakon te poruke se izbrise ceo red knjizenja
ili makar da izlazna vrednost ostane nula a da imam mogucnost da predjem
u naredni red (slog) i knjizim drugu sirovinu?

Moram da priznam da se ni meni ova zamisao bas nije dopala sa odobrenjima,
pogotovo kada nam je poznata cinjenica da nabavka (uvoz) sirovine
traje nekoliko nedelja.

Resenje takvog problema lezi u pravilnom planiranju proizvodnje i normalno
blagovremene nabavke sirovine.

Ali, nove promene nalazu nova pravila.

Probaj da pritisnes ESC kad se javi poruka koja ne dozvoljava knjizenje. Cancel = TRUE znaci da se ne dozvoljava 'update' za polje koje se proverava kodom na Before_Update. Jedna Esc treba da ponisti promene u tom polju, a sledeci Esc treba da ponisti ceo rekord. Verujem da knjizenej sa Ulaz=0 i Izlaz=0 nema mnogo smisla, a i tabela Knjizenej II ne bi trebalo to da dozvoli. Seti se, treba da vazi pravilo (Ulaz^2+Izlaz^>2) > 0

Ako ne radi ovo sa Esc, pomeri ceo kod iz BeforeUpdate za polje na BeforeUpdate za formu, onda ce biti dovoljan samo jedan Esc.

Ako vec moras da se mucis sa odobrenjima, onda negde treba zapisati da je odobrenje dobijeno/odbijeno. Ali sta ces onda? To te dovodi u situaciju da imas nepotvrdjena knjizenja, uslovan knjizenja, koja zavise od odobrenja. Mozda Getsbi moze da pomogne sa ovim. Da li su dozvoljena uslovna knjizenja? Na primer, ako se neki uslov ispuni naknadno, sledi da je knjizenje OK , a ako se ne ispuni uslov, onda se knjizenje ponisti (stornira?)

Dakle brisanje pre knjiženja, storno posle knjiženja. Storniraju se pogrešna knjiženja. Nikad svesno ne knjižiš nešto što je pogrešno ili ne ispunjava uslove. E sad tehnologija. Ja držim sve unešene dokumente u tabeli imali uslova za knjiženje ili ne (dokumenti na čekanju). U momentu kad odlučim da su uslovi ispunjeni (kod finansijskog, ako je nalog u ravnoteži ili kod robnog ako je roba stigla u magacin, pošto se dešava da nekad papiri stignu pre robe itd.) pokrećem proceduru za knjiženje. Podaci se rasknjiže, a u tabeli dokumenata dotičnom dokumentu dodelim status "proknjiženo". Sve uočene greške nakon knjiženja ispravljam procedurom storniranja, dodeljujući dokumentu staus "storno". To naravno podrazumeva update nekih tabela gde je izvršeno knjiženje.
Što se proizvodnje tiče Marija je u pravu: < Resenje takvog problema lezi u pravilnom planiranju proizvodnje i normalno
blagovremene nabavke sirovine>. Zato su u svetu najcenjeniji organizacioni tipovi:
CIM (kompjuterski integrisana proizvodnja)
JIT (Just in time)
KANBAN (sistem omogućava održavanje minimalno potrebnih zaliha nedovršene proizvodnje).
Ali da ne odem van teme. Mnogi procesi papirološki započeti traju neko vreme, zbog toga treba predvideti mogućnost da se oni zbog ne završavanja eventualno opozovu (čitaj storniraju). Dozvoljavam dakako mogućnost da ima i boljih rešenja ali bi svakako trebala da se oslanjaju na važeće standarde ukoliko postoje.

Nadam se da sam od pomoći.

Pozdrav!

Od jutros sam sa kolegom uspela da promenim ovo oko odobrenja, pa smo to konacno definisali
i prilagodili nekim stvarima.

Sve u svemu, ubacila sam samo proveru Stanja i Izlaza tj.

If (sngStanje - sngIzlaz) < 0 Then
MsgBox "Ne moze se trebovati vise sirovine nego sto je u magacinu"
Cancel = True
Exit Sub
End If

If (sngStanje - sngIzlaz) < Safety_Stock Then
MsgBox "Trebovanje mora potpisati rukovodilac sektora!!!"

End If

If (sngStanje - sngIzlaz) < Reordering_point Then
MsgBox "Potrebno je naruciti novu kolicinu ove sirovine!!!"
End If

Koliko sam mogla da primetim, uz nekoliko provera, uz ESC sve to lepo radi.

Konacno, ne mogu da knjizim ispod 0, ukoliko stanje padne ispod Reordering pointa pise se nalog
za nabavku nove kolicine a ukoliko stanje padne ispod Safety stock trebovanje koje se
odstampa potpisuje rukovodilac sektora i pri tome ce znati da je frka sa sirovinom a on ce vec naci resenje
za njenu nabavku.

Ponovila bih da je ovakvo pracenje stanja sirovina koja se neprekidno koristi u proizvodnji lose
a da je dobro planiranje mnogo vaznije.....

Ovo je definitivno najbolja stvar koju sam naucio o knjigovodstvu na ovom forumu:


Ja sam ne znajuci tacno sat se desava nebrojene ljude savetovao pogresno - to jest nekompletno - za mene je
'knjizenje' = 'unose rekorda u tabelu' gotova stvar. A u stvari postoji jedan zastoj, neko vreme mora da prodej izmedju upisa u nesto (knjigu, tabelu) i konformacije ili odbacivanja. Znaci li to da sve ili bar neke tabele u koje se upisuju 'knjizenja' treba da imaju nekakav indikator koji ima tri vrednosti: (cekanje, proknjizeno, stornirano)? Onda svi kveriji za stanje treba da kazu WHERE Knjizenej.Status = 'proknjizeno'. Ili postoji neki skup tabela gde zapisi stoje dok nisu spremni za knjizenje, pa dopbri idu u raj, a losi se odbacuju (brisu) ili idu u pakao?

Ovo je ili veoma ocigledno u knjigovodstvu pa ga niko nije spomenuo na forumu u diskusijama, ili je vecina diskutanata spada u kategoriju 'programeri sa ogranicenim znanjem knjigovodstva', bas kao i ja, pa se unesemo u diskusiju o resenju bez potpunog poznavanja prirode problema. Kakvo poznavanje prirode problema takva i resenja. :-(

Getsbi, skidam kapu, svaka cast.

Ne bih da koleginici ometam topic ali ovo je jedina tema na podforumu Access koja u nazivu ima reč knjizenje, te stoga odlučih da dovršim priču. Na formi zaglavlja dokumenta koristim sledeći kood ispod dugmeta "Knjizi".

Ono "Knjizi_Glavnu" je VBA modul u kojem napišem proceduru za knjiženje. Tehnika je dobra iz razloga eventualnog prekida jer se na ovaj način ili proknjiži sve i na kraju dobije pozitivna poruka ili u slučaju greške sve vrati na staro. Nema polovično proknjiženih podataka.
Zidar verujem zna za transakcije ali neka ostane na forumu za neka eventualna interesovanja.
Odgovor Zidaru: Koristim indikatore stanja.

_{[Ovu poruku je menjao Getsbi dana 06.06.2007. u 23:46 GMT+1]}

Na postojecoj aplikaciji sam do sada imala nekoliko izmena sto se tice ispitivanja roka trajanja sirovina
pa shodno tome doslo se do toga da se u svakom trebovanju unosi kontrolni broj i datum ispitivanja
sirovina (iz razloga sto jedna sirovina moze vise puta da stigne iz uvoza sa istim kontrolnim brojem ali razlicitim datumom ispitivanja).
Iz tog razloga sam tabeli qryStanje dodala polja [Kontrolni broj] i [Datum ispitivanja].

Prilikom unosenja kolicine u polje [Izlaz] trebalo bi da mi se proverava stanje sirovine po jednakosti unetog
kontrolnog broja, datuma i naziva sirovine.

Kako trebam sada da definisem sngStanje koje smo prvobitno definisali kao

sngStanje = DLookup("Stanje", "qryStanje", "[Naziv materijala]= '" & Me![Naziv materijala] & "'") ?

[qoute]Kako trebam sada da definisem sngStanje koje smo prvobitno definisali kao

sngStanje = DLookup("Stanje", "qryStanje", "[Naziv materijala]= '" & Me![Naziv materijala] & "'") ?
[/quote]

Morace da se zakomplikuje posednji parametar u Dlookup. Nesto ovako:

sngStanje = DLookup("Stanje", "qryStanje", "[Naziv materijala]= '" & Me![Naziv materijala] & "'") ?


"[Naziv materijala]= '" & Me![Naziv materijala] & "' AND KontrolniBroj =" & me!KontrolniBroj & " AND DatumInspekcije = " & SQLDAte(me!DatumInspekcije)

Funkciju SQLDate nadji u bazi znanja, da ti olaksa zivot kad radis sa datumima. Pretpostavio sam da je KontrolniBroj numericki podatak. Ako nije, treba dodati single quote, kao sto je uradjeno za Naziv materijala ili koristi funkciju QUoted() - takodje je imas u bazi znanja. Naravno da KontrolniBroj i DatumInspekcije moraju biti u qryStanje. Mozda i qryStanje treba da se modifikuje. Posla koliko volis ;-)

Ovakvi komplikovani uslovi nikada ne prodju iz prve, pa ce biti verovatno nekoliko iteracija dok se ne natera da radi kako treba.

Nakon poslednje Zidareve pomoci, pokusala sam da resim moj problem ali
ipak nisam uspela u tome.

Za pocetak, prvo sam funkciji DLookup dodala polje [Kontrolni broj] i u proveri rada aplikacije pokazalo se da ona vec nije radila.

Test sa poljem [Datum ispitivanja] takodje nije prosao.

sngStanje = DLookup("Stanje", "qryStanje", "[Naziv materijala]= '" & Me![Naziv materijala] & "'" _
"[Kontrolni broj]= '" & Me![Kontrolni broj] & "'")

Da dodam da je Kontrolni broj definisan kao tekstualno polje.

U bazi znanja sam pronasla opis fukncije SQLDate() i moram da priznam da uvek koristim
Short format za unos datuma i vodim racuna da takva polja imaju i masku.

Interesuje me da li ovakav rad ipak moze dovesti do nekih poteskoca u radu aplikacija?

Umesto
probaj ovako:



Nije bitan Short format, nego redosled y/m/d kojin koristis u SQL stringu. Redosled mora uvek biti onako kako ga definise funkcija SQLDate() - mm/dd/yyy. Ako tvoj Short Date ima bas taj redosled, to je slucajno i imala si srecu :-)

Vidi ovaj link obavezno: http://allenbrowne.com/ser-36.html
tamo ima objasnjeno mnogo toga u vezi sa datumima i data je bolja funkcija SQLDate (vodi racuna o satima i minutima i o delimiters):

Function SQLDate(varDate As Variant) As String
'Purpose: Return a delimited string in the date format used natively by JET SQL.
'Argument: A date/time value.
'Note: Returns just the date format if the argument has no time component,
' or a date/time format if it does.
'Author: Allen Browne. [email protected], June 2006.
If IsDate(varDate) Then
If DateValue(varDate) = varDate Then
SQLDate = Format$(varDate, "\#mm\/dd\/yyyy\#")
Else
SQLDate = Format$(varDate, "\#mm\/dd\/yyyy hh\:nn\:ss\#")
End If
End If
End Function

U proveri rada aplikacije sa ovako napisanim Codom

sngStanje = DLookup("Stanje", "qryStanje", "[Naziv materijala]= '" & Me![Naziv materijala] & "'" _
And "[Kontrolni broj]= '" & Me![Kontrolni broj] & "'")

pojavio se Debug okvir sa greskom br.13 - Type mismatch.


Htela sam da vidim kako bi aplikacija radila kada bih u Cod ostavila samo [Kontrolni broj] kao kriterijum

sngStanje = DLookup("Stanje", "qryStanje", "[Kontrolni broj]= '" & Me![Kontrolni broj] & "'")

i ona je radila.


Zatim sam dodala i [Datum ispitivanja] i opet mi se pojavio debug sa greskom br.13.

Problem se pojavi cim mi se u kriterijumu pojave dva i tri polja??!

Ako su ti kompatabilni tipovi podataka u promenljivima na formi gde se referenciraš sa tipovima podataka u tabelama, onda preostaje da je greška u nedoslednosti korišćenja ključa tabela. Probaj da na prvo mesto u kriterijumu postaviš ključ pa onda druga polja. Daklle prvo kontrolni broj pa onda naziv materjala.

Ja sam kao kljuc stavila [Naziv sirovine] iz razloga sto u nekim slucajevima sirovine mozemo primiti i
bez kontrolnog broja a takodje mozemo jednu sirovinu u jednoj isporuci da primimo sa dva razlicita
kontrolna broja.

Da li bih u tom slucaju morala da promenim redosled unosenja podataka

[Naziv sirovine] -> [Kontrolni broj] -> [Datum ispitivanja] -> ..... ?

OK, uspeo sam da napravim da Dlookup proradi. Ja sam dobijao 'invalid use of null'. Kad je 'where' uslov u Dlookup komplikovan, onda se lako gresi. Vidi kod na BeforeUpdate, doao sam jednu novu varijablu i jednu novu funkciju, Quoted, das nam bude lakse da napravimo 'where' uslov za Dlookup.

Takodje sam na formi [Knjizenej I] promenio DataEntry property na No, da bih video sta se desava. verovatno zelis da to vratis kako je bilo, DataEntry = Yes.

Medjutim, qryStanej mi ne izgleda dobro ili ne razumem sta se desava. qryStanje bi morao da vrati jedan rekord po materijalu, ni vise ni manje. Ovako kako je qryStanje ne vraca stanje, nego pokazuje svaku transakciju ponaosob. qryStanje vraca isti broj redova kao i tabela [Knjizenja II] sto nikako ne moze da bude u redu.

Mislim da redosled unosa podataka u formi nije od presudnog značaja za problem. Bitno je da Ako ti tabela Sirovine -materjali ima primarni ključ "Naziv sirovine" onda taj primarni ključ postaje preneseni ključ query-a (ako se varam neka me neko ispravi). E onda bi u DLookUp funkciji trebala da pretražuješ po "Naziv sirovine", a u qryStanje da uključiš takođe "Naziv sirovine", umesto "Naziv materjal". U svakom slučaju mislim da tvoj problem ima neke veze sa ključem. Probaj. Možda se javi Zidar.

E dobro, vidim da se javio.

Što se tiče query-ja.Skini sve ostale GroupBy osim po nazivu i dobićešono što želiš. Dakle samo jedan group By. U međuvremenu sam pokušavao da pomognem koleginici oko greske br.13 - Type mismatch. ali nisam baš uspeo. Ono sa Quoted je odlično. sintaksa mi je uvek bila problematična.

Kada sam qryStanje otklonila sve grupacije osim na polju [Naziv sirovine]
query nije radio uopste.

Zidarev Code sam prenela (kopirala) u moju aplikaciju i u proveri mi se
pojavila poruka da finkcija nije definisana pri cemu je u pozadini
funkcija Quoted bila markirana.

U fajlu koji sam zakacio imas u jednom od modula funkciju. Prebaci je u neki od modula tvoje aplikacije.

U svakoj aplikaciji imam modul koji se zove Utils i on sadrzi sve uniarzalno korisne funkcije. Taj modul Utils se nalazi u zasebnom Access MDB fajlu, koji zovem na primer AccessLIbrary, koji ne radi nista osim sto cuva neke vazne module sa funkcijama koje se prenose iz aplikacije u aplikaiju. Kad pocnem aplikaciju, prvo sta uradim je da iskopiram modul Utils iz AccessLibrary.MDB

Sto se tice kverija, vrati se na pocetak. Imam utisak da si stalnim dodavanjem odlutala od prvobitne funkcije kverija, ili pokusavas da dodas funkcionalnosti koje nam nisi rekal pa stalno nesto zapinje. Polako, ostavi malo posao na dan dva pa se vrati na problem odmorna.

Ajde pokreni qryStanje u ovom prikačenom fajlu. To je Zidarev fajl, samo sam poskidao ostale GroupBY. Moguće je da Zidar nije pročitao moj prethodni post.

Naravno da je Getsbijev kveri OK :-)

Kveri u fajlu Sirovina_Z.zip nisam ja napravio, to je originalni Marijin kveri koji mi nije bio jasan. Ja sam samo naterao kod oko Dlookup da radi u tom fajlu :-)

Moj cuveni qryStanje koji Vam je napravio toliku zabunu prikazuje stanje sirovina ponaosob po kontrolnim brojevima i datumima ispitivanja. (svim poljima sam vratila prvobitni Group By i sada je sve u redu).

Ovim sam olaksala postupak izdavanja sirovina operaterima jer u formi KnjizenjaI imaju mogucnost da otvore ovaj
pregled i da istog trenutka imaju uvid u to koja se sirovina izdaje po redu.
Naime, vodjeni ISO standardnom, svaki postupak rada ima ispisanu proceduru pa prema tome postoji i
procedura izdavanja sirovine a bas te procedure razdvajaju sirovine po kontrolnim brojevima i datumima ispitivanja.

Kada smo se pre nekih mesec dana bavili Reordering pointom i Safety stockom qryStanje je prikazivao stanje samo po nazivu sirovine a onda je operater otvarao karticu svake sirovine, zapisivao na papiru kontrolni broj i datum ispitivanja sirovine i to tako, recimo za 20 - 30 sirovina na dan, pa tu je i pomocni materijal sa istom pricom i tek tada je mogao da ispise i izda trebovanje. (Takvo trebovanje se prosledjuje magacioneru i on ima sve podatke po kojima izdaje sirovinu)

Sada kada sam modulu dodala funkciju Quoted aplikacija radi dobro.
Uradila sam i proveru aplikacije i rekla bih da je zadatak resen.

Veliko HVALA kolegama na pomoci i savetima.





_{[Ovu poruku je menjao marija rnic dana 06.07.2007. u 15:35 GMT+1]}