Baza za STR tj. pracenje ulaza/izlaza robe.

Pozdrav svima, poceo sam da pravim bazu za STR pa mi je potrebna pomoć. Pre svega da razjasnim cilj ovog projekta. Pokusavam da napravim bazu u koju ću unositi artikle, kolicinu, nabavnu i prodajnu cenu artikla. Pored toga treba potrebno je s' vremena na vreme da izvršim popis i tu nailazim na najveće probleme pri dizajniranju tabela. Dodatno da bi se sve poklapalo potrebno je pratiti stanje veresije kao i stanje pazara tj. koliko para gazda uzme na kraju dana iz kase. Naravno postoje i rashodi. Rashod bi na primer bio ako ne prodamo danas dva hleba i moramo da ih bacimo.

Ovo je postavka problema. Odatle se vidi na za početak moram da imam sledeće tabele: tblArtikal, tblNabavka (ulaz), tblPopis, tblVeresija, tblKasa (pazar) i tblRashod.

Kad izvršim popis i prebrojim robu onda ukupna vrednost te robe (prodajna cena*kolicina) plus ukupna vrednost kase plus vrednost rashoda plus veresija treba da bude jednaka ukupnoj vrednosti robe koju sam uneo. Kada bi zbog razumevanja uprostio stvar matematički bi mogao ovo da zapišem kao:
tblNabavka=tblPopis+tblKasa+tblRashod+tblVeresija

Naravno ovo je samo uprošćen prikaz.


Problem se javlja kad vršim popis jer sam jednom na primer uneo 10 komada smokija čija je cena 13 dinara a onda unesem 15 komada smokija po 14 dinara. Kada izvršim popis vidim da na tezgi imam 17 komada smokija. Znači iz dve nabavke imam 25 komada smokija. Od ovih 17 smokija očigledno je da su 15 iz druge ture a 2 iz prve. Gazda kaže da kad je doneo drugu turu smokija koja je poskupela tj. 14 dinara onda onih dva smokija koji su preostali se ne prodaju više po staroj ceni već po novoj od 14 dinara i to mi mnogo koplikuje stvar prilikom popisa. Ima li neko ideju kako da rešim ovaj problem.

Napomena: Trenutno me samo interesuje struktura baze i nisam se još odlučio da li ću je raditi u Accessu ili u Oraclu. Jer ukoliko budem morao da u toku rada primenim trigger moraću na Oraclu da radim jer Access nema triggere. Nije mi problem da radim u Oraclu a i sto se tiče koštanja postoji besplatna verzija sa ograničenjima koja mogu da zaobiđem. Ako radim na Oraclu aplikaciju ću raditi na Visual Basic .NET jer imam iskustva sa radom Visual Basica i Oracla. Ali da ne komplikujem na početku hajde da probamo da rešimo ovaj problem sa različitim cenama a kasnije možemo da diskutujemo o izboru baze i aplikacije.

Bazu ću razvijati samostalno i kad je završimo postaviću je na uvid svim članovima foruma. Pozdrav

Potpis

http://biske.rs

Za početak moraš da se upoznaš sa osnovama računovodstva. Tek onda ćeš moći da sagledaš barem deo problema koji treba da budu rešeni. Do tada mani se ćorava posla

Ne radi se o nekom velikom marketu vec o maloj prodavnici. Ne treba mi baza da bih vrsio neko ozbiljnije racunovodstvo vec sa s vremena na vreme izvrsim popis, cisto da bi video da li me radnici zavrcu ili ne. Imam iskustvo rada sa bazama i samo sam pitao da li moze neko da mi pomogne ako je imao slican problem ili ako je imao iskustva sa ovakvim stvarima.

Potpis

http://biske.rs

OK, racunovodstvo je "must" za bilo sta ozbiljno, ali za ovako jednostavniji primjer, ne mora odgovor biti mani se corava posla. Momak nije napisao niti koja je svrha baze, u pogledu da li je komercijalni program, ili nije, niti bilo sta drugo. Od necega se mora krenuti.
Ni to samo racunovodstvo nije toliko komplikovano, barem sto se tice osnovnih pojmova i stvari. Problem su poslovni procesi razlicitih firmi, te odgovor na njihove potrebe. Standardni pojmovi sta su racuni(fakture), sta je kalkulacija, sta su rabat i marza, to se sve jednom nauci, i nema se sa tim problema. Kad bi nekad samo bilo sve tako jednostavno.. :)




Sto se tice samog odgovora na temu:




Prvo sto moras je krenuti od realnog pogleda u svijetu, koju svrhu baza ispunjava, te sto vise u detalje unaprijed odrediti sve potrebne operacije i zahtjeve nad njom (ovo podrazumijeva prikupljanje business rules-a ). Nakon toga sastavljas model, te opet od zahtjeva zavisi i nacin na koji ces je modelirati. Normalizacija se podrazumijeva za relacione baze, problem oko performansi i denormalizacije ti je za sve manje upotrebe zanemarljiv, i najvaznije je da sto bolje cuvas integritet podataka (da te ne bunim - to jednostavno znaci da izvrsis pravilnu normalizaciju - po mogucnosti i do 4. i 5. normalne forme, i da nista vise ne diras).

Entiteti koje treba da odredis isto moraju oslikavati realno stanje, i ono sto ti je potrebno moras da saznas analizom.
- Da li baza treba da pamti podatke ulaznih racuna (kao broj racuna, ko je dobavljac i slicno)?
- Da li ima kakve potrebe za evidencijom kupaca?
- Ostali napredniji zahtjevi koji mislim da su ovdje potpuno nepotrebni, ali samo da navedem sta bi se moglo uraditi: cjenici, narudzbenice, detalji knjigovodstva itd...

Strucni termin za ovo oko bacanja hljeba je kalo / rastur. Moze se napraviti kao obicni rashod na fiktivni racun kalo/rastur, ali o tome malo kasnije... Stanje veresije - mislim da je potrebno uvesti evidenciju kupaca (ako to program treba da radi), a kao jedno od rjesenja - dovoljno je u neku tabelu prodaje, kakva god ona bila, staviti polje koje oznacava da li je stavka prodaje placena. Sto se tice popisa, ne razumijem sta zelis sa tim? Unos robe na lager ide preko dobave, roba sa lagera se mice prodajom. Ako se vodi ta evidencija, kakav je popis potreban? Ja koliko shvatam kod tebe je popis == prodaja; ali opet i kasno je, mozda sam samo pospan :))

Mislim da ti je jedan od pocetnih problema u ovome sto zelis da sve rjesis sto jednostavnije. Zelis da imas lager artikala, ali ne zelis pamtiti dobavljace, niti racune nabave. Zelis kasu, ali ne zelis racune prodaje (opet kazem, ovo nisam dobro ni razumio sta zelis).




Tabela artikala je svakako potrebna. Nabavku mozes zvati tako, mozes je zvati i ulazni racuni, svejedno, uradis onako kako najbolje oslikava potrebe. E sad, popis pretpostavljam da regulise lager na izlazu, pa mislim da je bolji naziv Prodaja. Za veresiju sam vec rekao, kao atribut u tabeli prodaje, a posto si od rashoda nabrojao samo kalo/rastur, to bi rjesio fiktivnim kupcem sa tim imenom. Tabela kasa moze ostati kao jednostavno rjesnje za gledanje koliko je novca uzeto iz iste, ali vrijednost ukupnog pazara u nekoj rel. bazi mora biti dinamicki izracunat, nema spremanja u neku tabelu ili polje. Jedini izuzetak ovome pravilu su performanse. Jedno od mogucih rjesenja je da nakon bilo koje transakcije spremas staro i novo stanje, tako da ne moras praviti upit nad cijelom bazom podataka, samo sto bi se javio taj novi problem redudanse podataka.
Rijec i o nazivima samih tabela: ja nikad ne upotrijebljavam Hungarian notation za imena tabela. Iste je jako jednostavno prepoznati da su tabele, ovaj nacin obiljezavanja sa tbl je staro naslijedje. Druga stvar su stored procedure i triggeri, kod njih uvijek koristim Hungarian notation radi mogucnosti isih imena kao i tabele (a i ovo je rijetko). Ipak, samo navodim svoje misljenje, ti radi kako tebi odgovara najbolje.





Ovo se rjesava samom normalizacijom odnosa Artikla i Nabave. U jednoj dobavi neces imati isti artikl sa dvije razlicite cijene. Jedna dobava (nabava, whatever) je u biti jedan racun. Na jednom racunu mozes imati vise artikala, a jedan artikl moze biti na vise racuna dobave. To je n:m veza, koja se rjesava dodavanjem nove tabele. U tu novu tabelu se smjestaju detalji - mozemo je nazvati detalji nabave. Znaci, da ponovim - sad su u pitanju nabave tri tabele: Artikl, DetaljiNabave, Nabava. U nabavi drzis podatke o datumu, dobavljacu, i ostalim podacima, nema stranih kljuceva. U DetaljimaNabave atributi su ti ArtiklId (FK), NabavaId (FK), Kolicina i CijenaNabave. Prodajnu cijenu drzis u tabeli Artikl, koja nema nikakve veze sa Nabavom, osim u slucaju da zelis praviti automatsku kalkulaciju kroz program. Prodajna cijena se mjenja rucno (govorim opet prema ovome sta tebi treba), znaci - gazda mjenja kako mu pase. Stanje na izlazu sa lagera je isto, samo sto imas tabele Artikl (ona ista od maloprije naravno), DetaljiProdaje i Prodaja. Prica je potpuno simetricna, cijena po kojoj je neki artikl prodan se zapisuje u DetaljeProdaje, tu se vise nikad ne mjenja, mjenja se samo prodajna cijena u tabeli Artikl, koja govori po kojoj ce se cijeni artikl prodavati kada dodje trenutak prodaje (znaci, koji ce se iznos preslikati u DetaljeProdaje). Nakon prodaje cijena u tabeli Artikl moze ostati ista, a moze se i promijeniti. Ona cijena po kojoj je prodano, u tabeli DetaljiProdaje, nikad se ne mjenja. U tabeli Prodaja mozes povezati i neku tabelu Kupci, medju kojima moze biti i kupac Kalo/Rastur, te mozes dodati atribut da li je neka "prodaja" placena ili ne (znaci - veresija).




Eto, de odgovori na navedena pitanja, prvenstveno ovo sto mi je nejasno, pa ako budes znao okaci i sliku baze podataka neka stoji...
Pozdrav!

Potpis

My programs don’t have bugs, they just develop random features.

Jedna stvar mora biti jasna . A to je da se konkretan problem vezuje za materijalno računovodstvio i tako mora biti i tretiran.

Kakva normalizacija i kakvi bakrači. Gde je tu nivelacija? Ma sva pitanja koja su postavljena rešena su knjigovodstvenim pravilama i tako i samo tako i moraju biti rešavana. Nema malih ili velikih STR. Svi rade na isti način, samo sa različitom količinom podataka. Nema svrhe izmišljati novi sistem knjiženja kada je već sve izmišljeno.

Najpre moram da kazem da se ocigledno nismo razumeli. Program radim za svoju prodavnicu tj. ne vodim poslove ja vec moj brat. Posto je to mala porodicna prodavnica ne treba mi nesto ozbiljan program vec samo baza koja ce pratiti koliko novca sam ulozio za odredjeni period a kolika bi trebala da mi bude dobit. Moj brat ima svesku u koju pise artikle prilikom svake nabavke, pa onda racuna i odprilike sagledava mesecni bilans. Ono sto ja hocu je da mu olaksam posao prilikom unosa da ne mora da zapisuje po knjigama vec da se evidencija vodi u racunaru i da mogu da se generisu neki statisticki izvestaji na primer koliko je para ulozio za mesec januar i kolika bi zarada trebala da bude. Posto je to, kao sto rekoh, mala porodicna prodavnica brat nikad nije radio popis ali je resio da pocne i sa tim pa sam hteo i tu funkcionalnost da mu ubacim. Posto smo odlucili da bude tako onda moramo da pratimo stanje kase tj. koliko para on uzme na kraju dana iz kase i da pratimo rashode (kada se ne prodaju svi hlebovi pa ih bacimo). Da bi se sve slagalo potrebno je jos imati evidenciju o veresiji ali ne u smislu koji kupac ima koliko veresije vec kolika je ukupna vrednost veresije da bi se poklapalo stanje. Da rezimiram, vrednost robe koju sam nabavio mora da bude jednaka vrednosti preostale robe (popis) + ukupan iznos koji sam uzeo iz kase + rashodi + veresija. Znaci potrebna mi je ukupna vrednost veresije. Nju cu pregledati prilikom popisa. Prilikom nabavke ne pamtim informacije o dobavljacima jer mi to nije bitno. Brat sedne u kola i ode i nabavi robu. Oni mu daju racune i on sa tih racuna uvece unese u bazu sta je sve nabavio po kojoj ceni i u kojoj kolicini.

Nije meni problem shvatanje redundanse i normalizacije znam ja normalizovati relacije do pete normalne forme (u ovom slucaju mozemo ici samo do trece normalne forme jer nemam ni u jednoj tabeli primarni kljuc koji se sastoji od tri ili vise atributa). Kao sto rekoh najveci problem imam kod popisa kad se menjaju cene. Analizom procesa sam dosao do sledeceg podatka: ukoliko sam prilikom jedne nabavke doneo u prodavnicu smoki po 13 dinara i to 10 komada i sledecom nabavkom donesem jos 10 smokija od po 14 dinara a u medjuvremenu sam prodao 8 smokija po 13 dinara i od te ture su mi ostala 2 smokija onda se ta dva smokija kad dodje nova tura od 10 komada po 14 dinara prodaju po novoj ceni od po 14 dinara i izdaje se jedan papiric radniku u prodavnici koji on pokazuje prilikom popisa (da ne bi morao da daje 2 dinara razlike iz svog dzepa za ona dva smokija).

mkaras


Razmislicu o normalizaciji ove dve tabele mozda to pomogne oko ovog popisa.

Mozes li mozda da nam pomognes oko ovih dilema sa popisom?

Potpis

http://biske.rs

Ma u pravu si, unajmis knjigovodju i ne patis se sa tim problemima, sto bi uopste netko i pravio programe?
Samo sam pokusao pomoci, dosta ljudi naidje na ovakve teme, i dobro je da se ponudi bar bilo kakvo rjesenje. Ako smatras da nesto ne valja, onda reci tacno sta, kako i zasto. Kod ovoga sto si ti naveo, poenta je bila da se samo objasni zabuna kako i sta kad se cijena promjeni u nabavi.

EDIT: i nemoj sada uzimati pod lose sto sam spomenuo racune u materijalnom knjigovodstvu... Nekada moze biti potrebno da se jako puno razlicitih segmenata preklopi, da bi se postiglo zeljeno.

Potpis

My programs don’t have bugs, they just develop random features.

Jedan artikal imaš na lageru po jednoj ceni. Imaš određen broj komada. Kada kupiš ponovo taj isti artikal ali po drugoj ceni, radiš nivelaciju cene. Znači sada imaš novu količinu robe ali drugačijom cenom. To je nivelacija cene. Da bi odradio nivelaciju moraš da znaš koja količina robe već postoji u magacinu i na koju količinu se odnosi nivelacija. Znači radiš popis količine robe za koju želiš da radiš nivelaciju, .... Zato i kažem da se moraju poznavati osnove knjigovodstva. Ne može se pričati o nečemu što apsolutno ne poznaješ. Možda je i najbolje da bratovljeve pisanije pretočiš u elektronsku formu.

@Sapphire
Da, mislim da ništa ne valja u načinu postavljanja problema, pa samim tim i u načinu rešavanja problema. A razlog je potpuno nepoznavanje problema. Nadam se da je to dovoljan odgovor na tvoje pitanje

U pravu si ocigledno da dovoljno ne poznajem knjigovodstvo. Znas li neki link koji detaljnije objasnjava ove pojmove tj. sta se od informacija cuva prilikom knizenja. Mozes li da mi malo pojasnis ovo oko nivelacije cene. Sta se od informacija tu cuva. Kakva bi tabela to bila. Jel' moramo pisati datum promene?

Potpis

http://biske.rs

Nabavi barem knjige za treću i četvrtu godinu ekonomske škole, upiši neki kurs, razgovaraj sa knjigovođom. Moraš da sagledaš suštinu problema pa tek onda rešavaj finese. A to traje i traje. Brže rešenje i bolje je knjigovođa. Svakako ti treba radi poslovanja radnje. Sve to što ti treba od evidencije možeš lako dobiti i od njega. Nadam se da ne vodiš sam knjige jer ....

Taj "papirić" se ispravno zove nivelacija cena. Nivelacija cena treba da sadrži gotovo sve što si gore i naveo: datum nivelacije, artikal koji se niveliše, popisano stanje, stara cena, nova cena. U tvom slučaju bi to izgledalo:
- datum nivelacije = 8.3.2009.
- artikal = smoki
- zatečena količina = 2 kom
- stara cena = 13 Din
- nova cena = 14 Din
- povećanje vrednosti = 2 * (14 - 13) = 2 Din

Napravi tabelu u kojoj ćeš čuvati ove informacije (ili deo njih pošto nepraviš zvaničan knjigovodstveni program), a definitivno moraš čuvati onu informaciju o povećenju vrednosti.


U ovu formulu ubaci podatke o nivelacijama cena pa će ti ona izgledati: vrednosti preostale robe (popis) + ukupan iznos koji sam uzeo iz kase + rashodi + veresija - nivelisano povećanje vrednosti.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Ne bih se složio! Čovek verovatno i ima knjigovođu koji mu radi kalkulacije, izvode, pk1, poreske prijave, bilanse, ... Knjigovođa nemože da da "tačne" evidencije, jer ...
, ... a samo deo tih računa završi kod knjigovođe! Iz činjenice da biske86 i njegov brat neznaju za pojam nivelacije proizilazi da im se trgovačka knjiga nikada neslaže sa popisom radnje :) A da ne spominjemo "veresija", "bacanje hleba" :), "vlasnik uzeo iz kase"

@mkaras: Nemojmo više ni ti ni ja u offtopic. Za temu nije bitno da li neko zna ili nezna knjigovodstvo i da li je vođenje STR-a uređeno zakonom. Zamisli da se radi o oblasti koja nije uređena zakonom i da treba da se napravi softverska podrška.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Dobro si primetio :) Ja sam to i naznacio cini mi se negde u tekstu da brat ima knjigu gde belezi samo artikle koje unosi u prodavnicu i onda na digitron i sracuna koliko je ulozio i koliko bi trebalo da ima zaradu od toga. Nemamo knjigovodju jer ne placamo poreze (zivim na Kosovu i Metohiji). Do sad nismo radili popis ali upravo pokusavam da olaksam taj posao bratu, da ne sabira rucno po knjigama vec da se to radi u programu. Mislim da je ova nivelacija problem koji me je mucio. Probacu da implementiram i ako se stanja poklapaju pocecu sa izradom baze a onda i aplikacije. Hvala svima.

Potpis

http://biske.rs