Mislim da mozes to da integrises u jednu tabelu koju bi recimo nazvao Korisnik. Naravno tada bi tabela imala vise atributa kojima bi morao da dozvolis svojstvo NULL jer nesto sto poseduje Firma, to ne poseduje Klijent, i obrnuto.

E sada ne razumem tvoje pitanje, kako se pravilno resavaju uplate, u kom smislu???

Upravo to! PREVISE NULL polja bi trebalo nekako izbeci. odatle i
razdvajanje u zasebne tabele. Ako ne, kompletnija slika bi bila ovakva:

[Korisnik] -------->[Faktura]-----------<[Po Fakturi]>----------[Uplata]
(PoFakturi je vezna tabela)

Da li za 'obicne klijente' napraviti posebnu relaciju od Korisnika do Uplate?

Inace mislim da se ovakvi slucajevi cesto javljaju pa i sablon po kome se
kreira baza, zato sam pitao kako je 'Ispravno...'



_{[Ovu poruku je menjao diplIng dana 21.09.2006. u 15:29 GMT+1]}

Nema potrebe da toliko komplikujes.

U tabeli klijenti drzi naziv, adresu, pib, telefon i druga polja. Po pravilu svakome moras izdati racun tako da u sustini i nema razlike da li je klijent firma ili fizicko lice.

Ko duplata, jednostavno stavi polje DOKUMENt koje ce sadrzavati vezu ka dokumentu po kome je izvrsena uplata. ako je uplata po fakturi, tu stavis id fakture, ako nije po fakturi, onda otavis prazno.

Vodi racuna o specijalnom slucaju: delimicna uplata. Sto ce reci da mozes da imas uplatu po fakturi ali koja ne pokriva pun iznos fakture, a takodje i vise uplata pojednoj fakturi ali je moguce da imas i jednu uplatu koja pokriva vise faktura. to se u prinicpu resava tako sto se za vise uplata navodi isti id dokumenta a ako jedna uplata pokriva vise dokumenata onda je razbijes na vise stavki i svaku pojedinacno vezes za odgovarajuci dokument.

Ako ces bas po PS-u onda ti treba pet tabela:


KOMITENTI (ID_KOMITENTA, NAZIV...) - sadrzi sve potrebne podatke o komitentima

FAKTURE (ID_FAKTURE, DATUM, ID_KOMITENTA, ...) - sadrzi zaglavlja faktura

STAVKE_FAKTURE (ID_STAVKE, ID_FAKTURE, ID_ARTIKLA, KOLICINA, JEDINACNA_CENA, POREZ, RABAT...) - sadrzi stavke faktura

PROMET (ID_PROMETA, DATUM, ID_DOKUMENTA, DUGUJE, POTRAZUJE...) - sadrzi podatke o prometu (ukupni iznosi faktura se knjize u promet na dugovnu stranu, uplate se knjize na potraznu, ako jedna uplata pokriva vise faktura, ovde se kreira vise stavki tako da se iznosi knjize za svaku fakturu posebno)

UPLATE (ID_UPLATE, DATUM, ID_KOMITENTA, IZNOS...) - evidencija uplata


Napomena: tri tackice u listi polja znace: i ostala polja po potrebi)

PS - Pravilo sluzbe ili Predrag Supurovic 8-)))))....

Svidja mi se razmisljanje mada ja vidim da bi za ovaj problem trebalo nesto i o ekonomiji znati... Nazalost tu bas i ne spadam.

Kod Uplate ti fali nesto prilicno bitno - kao poziv na broj ili tako nesto gde bi vodio po kom dokumentu (id_dok) je izvrsena uplata.
Pozdrav

I meni se cini, ali nisam siguran (ID_DOKUM. postoji u tabeli PROMET)!

(?Help!)






_{[Ovu poruku je menjao diplIng dana 22.09.2006. u 22:48 GMT+1]}

Preptostavljam da je broker mislio na klasican sifarnik DOKUMENT(ID_DOKUMENTA, NAZIV).

Necu da te davim sa strukturama tabela, to verovatno vec imas

Broker ti je lepo napisao, tesko je nesto dodati. Ali da probam

Nigde se ne pominje avansna uplata, sto je vrlo interesantno.

Varijante su uplata, delimicna uplata, ili uplata za vise faktura (vec spomenuto). Onda se radi povezivanje, mozes da napravis i neku rutinu koja ce to povezati, mada je to uspesno u vrlo malom broju slucajeva. Ostalo treba da se rucno doradi, u smislu unosa broja veze, razbijanje uplata i slicno (vec pomenuto)

Ono sto ce ti traziti je izvestaj o stanju dugovanja/potrazivanja za partnere i ukupno. Vodis koliko dana kasne pa ih svrstas u neku grupu, prvu obojis zeleno (do 3 dana), pa zuto (do 7 dana), koji najvise kasne (svi ostali) crveno i svima jasno kad vide. Konkretan broj dana ce ti reci neko ko to prati.

Ako sam dobro razumeo, kraca varijanta je:

*tabela UPLATE sadrzi atribut DOKUMENT_ID (allow NULL);
*tabela UPLATE vezana je sa KOMITENTI;
*tabela UPLATE nije u relaciji sa tabelom FAKTURE;

Tako?

Malo kasnim, samo da pojasnim ono ID_DOKUMENTA u tabeli PROMET predstavlja sifru dokumenta po kome je nastala promena, a posto to ne mora uvek biti faktura ja po navici stavljam malo opstiji naziv polja.

@broker


Sve to stoji i potpuno se slazem sa tobom, jedino bih u tabelu Uplate dodao taj ID_Dokumenta.

@DiplIng



Da, ovo stoji sto si napisao + brokerova struktura tabela.

Pozdrav

Zaboravih da se zahvalim.