Zakaci tabelu pa da vidimo. :-)

eto brate postavio sam i bazu , spasavaj me brate!

Znaci jedan kupac moze imati vise racuna, a isto tako za jedan racun moze biti vise uplata-veze 1:vise.
Znaci covjek hoce analiticku karticu.Mozda bi trebao dodati status stavke (otvorena/zatvorena) tako da kasnije mozes kupcima izvuci i IOS (izvod otvorenih stavki).Da li treba da zatvara stavke hronoloski od najstarijeg otvorenog racuna, posto se ne poziva na broj?

jeste jedan kupac ima vise racuna. a jedan kupac moze da plati taj racun iz vise puta al nece da ima poziv na broj znaci da ga ne vezem sa racunom. a hoce da ima kartice i da rasknjizava racune od najstarijeg datuma pa nadalje. pa i ja sam mislio tipa nesto da dodam u tabelu racun placen nije placen al kad mi suma uplata bude ok onda da sam oznaci da je placen ili ima neki drugi nacin . ne znam kako to da uradim, a frka me puca jos mi je to ostalo da sredim. on oce karticu kupca njegov saldo koliko on duguje koliko je uplatio i koje je racune izmirio, al kad uplacuje da se ne veze za racun nego tipa upalti danas 50 sutra 100 itd a da mu skida racune sa liste

Kveri ovde, kveri onde i evo ga resenje:


Kveri zStatusRacuna ti pokazuje sve racune i njihov status = {'Razduzen','Nerazduzen'}
Taj kveri je baziran na zKumulativRacuna i zZbirUplataPoKupcu a oni opet baziraju se na zKumulativRacuna i zIznosRacuna.

Ako hoces da izlistas recim samo nerazduzene racune, pogledaj zNeRazduzeniRacuni.

hvala puno zidar , al ima problem posto racun moze biti minusni , znaci kad je racun minusni da to racuna kao da je kupac platio i da automatski taj rasknizi i da mu doda na isnos uplata jos taj pozitivan iznos. jer sma se zbunio sad u vezi ovog minusnog kad vidjoh,. a kako ti se dopada ovo ostalo sto sam uradio?

Račune složiš po datumu, kao i uplate i računaš zbir uplata. Račune sabiraš dok ne dobiješ zbir jednak ili manji od zbira uplata. Ono što ti preostane su neplaćeni računi.

Izbaci sva izračunata polja koja čuvaš u tabelama (tipa iznos, iznosSPDV i sličn). Ovako samo opterećuješ model i otežavaš održavanje konzistentnosti (čvrstine i ispravnost) podataka u tabelama. Dovoljni su samo elementarni podaci: kolicina, cijena, cijen-rabat i slično. Sve ostalo se može uvek izračunati u query-ju ili reportu onog momenta kad za to bude potrebe. Ako ti nekom nesmotrenošću bude obrisan ili pogrešno ručno ažuriran podatak u tim kolonama, bićeš u neprilici i izgubićeš silno vreme da uspostaviš rečenu konzistentost.

@strucchy:
kako lepo rece mkaras
Tako su radili kveriji u prvoj varijanti. Prva varijanta radi uzima u obzir negativne racune tako sto oni smanjuju kumulativ racuna. medjutim, vidim da imas kupca koji nema ni jedan pozitivan racun, nema ni jednu pozitivnu uplatu, ali ima negativan racun. Prva varijanta prikazuje i ovo, druga bas i nece.



Evo druga varijanta. Ali dalje moras sam. Pokazao sam ti kako se radi i koje su ti mogucnosti (kumulativi, UNION, kako se negativni racuni dodaju uplatama i tako dalje). Prouci kverije i vidi sta ti od toga odgovara.



Kako mi s svidja aplikacija? nemam komentar jer knjigovodstvo nije moja oblast. za to je merodavniji Getsbi. Sto se mene tice, pitao si interesantno pitanje i ja sam ti pokazao kako se to moze resiti kverijima. Da li je to dobra ili losa poslovna i knjigovodstvena praksa, ne znam, nije moja oblast.

Srecan rad.

:-)

Zidar hvala puno , upravo prepravljam sve greske,
Getsbi sredjujem to sto si mi rekao , nadam se da ce biti ok!
Eto kad zavrsim pa da vidimo ako bude OK da se stavi u gotova resenja.!

:)