Temat: Zależności funkcyjne w bazie danych

Witam
Mam jedno pytanie, ponieważ mam za zadanie wyznaczyć zależności funkcyjne w moim projekcie bazy danych. Podczas wyznaczania zależności funkcyjnych natrafiłem na jeden główny problem z wyznaczeniem zależności funkcyjnych w tabeli Pozycja, ponieważ w tej tabeli od klucza obcego zależy więcej niż jeden rekord tzn. jeżeli wykonamy operację SELECT z warunkiem WHERE Pozycje.Faktura = 2, to może zostać zwrócony w wyniku tej operacji więcej niż jeden rekord.








I tutaj właśnie mam problem, ponieważ nie wiem czy poprawnie wyznaczyłem zależności funkcyjne dla tabeli Pozycje.

Z góry dziękuję za pomoc w rozwiązaniu mojego problemu.Maciej Morawski edytował(a) ten post dnia 18.06.12 o godzinie 17:19

Temat: Zależności funkcyjne w bazie danych

Hmm,

Dziwne że przy relacji 1 faktura <-> n pozycji miałeś problem a przy relacji 1 kontrahent <-> n faktur takiego problemu nie miałeś :)

Fajny diagram tylko nie rozumiem dlaczego można przypisywać rodzaj płatności do konkretnej pozycji. Z tego co wiem to cała fv jest albo przelew albo gotówka. Na to tylko się narzuca wpłaty a przy fv wylicza (lub przechowuje) ile pozostało do zapłaty...

Temat: Zależności funkcyjne w bazie danych

Marcin Mackiewicz:
Z tego co wiem to cała fv jest albo przelew albo gotówka. Na to tylko się narzuca wpłaty a przy fv wylicza (lub przechowuje) ile pozostało do zapłaty...

Niestety świat nie jest tak piękny i prosty.
Spotkałem się nie raz z sytuacją, gdzie faktura miała kilka form płatności z podziałem procentowym.
Np. 30% płatne gotówką na miejscu, a 70% przelewem w ciągu 7 dni...

Temat: Zależności funkcyjne w bazie danych

Krzysztof Magosa:

Marcin Mackiewicz:
Z tego co wiem to cała fv jest albo przelew albo gotówka. Na to tylko się narzuca wpłaty a przy fv wylicza (lub przechowuje) ile pozostało do zapłaty...

Niestety świat nie jest tak piękny i prosty.
Spotkałem się nie raz z sytuacją, gdzie faktura miała kilka form płatności z podziałem procentowym.
Np. 30% płatne gotówką na miejscu, a 70% przelewem w ciągu 7 dni...

No ok ale to nie jest na zasadzie typu płatności do pozycji tylko w podsumowaniu pod pozycjami robi się zapłacono i do zapłaty a i termin płatności. Z tego co ja wiem to polskie prawo nie uwzględnia różnych terminów płatności dla jednej faktury - czyli 2 pozycje 7 dni a dwie 14 dni - można to zrobić rozdzielając dokument na dwa.

Temat: Zależności funkcyjne w bazie danych

Owszem, przypisywanie płatności do konkretnego rekordu na fakturze nie ma większego sensu.
Ale spotkałem się z fakturami, które miały zaplanowane płatności cząstkowe na jednym dokumencie.
Potem do takich faktur w systemie było przypisywane wiele KP.

Temat: Zależności funkcyjne w bazie danych

Nadal nie rozumiem idei cząstkowania kwoty należności. Liczy się tylko czy kwota należności jest równa sumie wpłat.

Weźmy:
faktura_v: id, kwota_fv, do_zaplaty, plat_termin, plat_forma

faktura: id, kwota, plat_termin, plat_forma
faktura_pozycje: id_faktury, lp_pozycji, vat, kwota_netto, produkt, opis, komentarz

wplaty_faktury: id, id_faktury, kwota_platy, rodzaj_dokumentu, id_wyciagu, lp_pozycji_wyciagu

wplaty_wyciagi: id, data_wyciagu, data_importu
wplaty_wyciagi_pozycje: id_wyciagu, lp_pozycji, id_faktury, kwota_pozycji

Faktura i fv pozycje opisuja fakture (z grubsza), Wplaty_faktury to lista wpłat dokonanych przez np KP lub przez ręczne księgowanie wyciągu z banku lub automatyczne księgowanie (np MT940).

Faktura_v to widok na bazie który zwraca listę faktur wraz z informacją o tym jaka kwota pozostała do zapłaty.

Cząstkowanie płatności to dla mnie zupełnie inna sprawa. Np. mój dostawca internetu wystawia mi jedną, zbiorczą fakturę za cały rok. Ja zaś płacę równą kwotę co miesiąc. Faktura jest jedna a płatności (polecenia zapłaty wystawiane przez dostawcę) dwanaście. Jest to swoiste rozłożenie kwoty należności na x części. Tylko w takim przypadku dzielenie FV ma sens; w każdym innym wierzyciel ma nadpłatę lub niedopłatę względem kwoty należności. Teraz każda płatność jest przypisana do fv a wpłata korelowana jest zarówno z FV jak i z konkretną płatnością.

Temat: Zależności funkcyjne w bazie danych

Maciej Morawski:
jeżeli wykonamy operację SELECT z warunkiem WHERE Pozycje.Faktura = 2, to może zostać zwrócony w wyniku tej operacji więcej niż jeden rekord.

>

I tutaj właśnie mam problem, ponieważ nie wiem czy poprawnie wyznaczyłem zależności funkcyjne dla tabeli Pozycje.

Jeśli projekt zakłada więcej niż jedną pozycje do faktury to jest to jak najbardziej prawidłowe.

I koledzy maja racje ze Płatnosc powinna powędrować do nagłówka faktury. Mozesz tak jak sugerują rozbudować tę strukturę pozwalając na przypisanie wiecej niz jednego rodzaju płatności.

W rozliczenia z klientami bym sie nie pakował jeśli nie musze bo tu jest multum zależności (płatności cząstkowe, co zrobic jesli klient zapłaci 2 faktury jednym przelewem)

Temat: Zależności funkcyjne w bazie danych

Oj tam. Płatności cząstkowe nie są wcale takie złe jak je malują.

Wszystko opiera się na odpowiednim przemyśleniu mechanizmu i zaprojektowaniu bazy.
Zauważ proszę, że każda wpłata (nawet 1 przelew = kwota 2 fv) jest przypisana do konkretnego kontrahenta. To samo dotyczy wysokości należności wynikającej z faktu wystawienia tych fv.

Zatem kwestia opracowania mechanizmu rozliczania należności względem wpłat...

Same fv posiadają swój identyfikator, datę wystawienia, termin zapłaty oraz formę płatności. Co za problem automatycznie rozliczać należności według np terminów płatności a jeżeli termin jest ten sam po identyfikatorze. Przy płatności zapisuje jaka kwota została rozliczona (wyjątkiem są wpłaty gotówkowe które powinny być rozliczone przy tej konkretnej fv) czyli przechowuję kwotę pozostałej należności. Jeżeli kwota do zapłaty jest równa 0 to oznacza że płatność została rozliczona. Jeżeli nie jest równa 0 to bardzo łatwo mogę obliczyć jaką kwotę wpłaty (lub całej fv) rozliczyłem:
KP - KDZ = KRW (kwota płatności - kwota płatności do zapłaty = kwota wpłaty rozliczona dla tej płatności)

Przy wpłacie natomiast pamiętałbym które płatności (lub całe fv) były rozliczane z danej wpłaty. Nie muszę pamiętać jaka kwota wpłat nie została rozliczona bo nie jest to potrzebne (przy płatnościach jest to wymagane - należy wiedzieć dla których płatności należność nie została uregulowana).

To czy wszystko zostało rozliczone wiem z salda:
SW - SP = S (suma wpłat - suma płatności = saldo)

Teraz jeżeli saldo jest ujemne to znaczy, że kontrahent nie uregulował należności w całości (pomijam branie pod uwagę terminu aby uprościć schemat). Wartość bezwzględna z tej wartości powinna być równa sumie pozostałych do zapłaty płatności (kolumna przechowująca wartość do zapłaty dla konkretnych płatności). Jeżeli wartość jest dodatnia to znaczy, że kontrahent ma nadpłatę a jego wszystkie płatności są uregulowane (kolumny do zapłaty wszędzie mają wartość 0)

Kwestia tylko nałożyć na to terminy zapłaty w przypadku fv lub terminy ściągnięcia części w przypadku płatności cząstkowych.
To ma w sumie związek z księgowaniem memoriałowym. Ale to nie działa dla wystawionych FV (bo z tego co wiem to dla każdej księgowej wystawiona FV zawsze wchodzi w przychody danego miesiąca).

Temat: Zależności funkcyjne w bazie danych

Marcin Mackiewicz:
Oj tam. Płatności cząstkowe nie są wcale takie złe jak je malują.

Wszystko opiera się na odpowiednim przemyśleniu mechanizmu i zaprojektowaniu bazy.

Wszystko jak zwykle jest kwestią dobrego przemyślenia i pomysłów ;-)