hunter wrote:
Ja to widziałem trochę inaczej. Nie mieszamy w to dokumentów (faktur/KP), czyli dodatkowa tabelka ustalająca relacje pozycji z tabeli cash
table cashlinks ( covenant integer /id obciążenia w cash payment integer /id wpłaty w cash )
Dodaj cashlink_id i wygląda miło.
Ale idąc o 3 kroki dalej: masz F/V chcesz znaleźć czy/które pozycje zostały opłacone:
masz id z invoice_contents i pupę gołą bo nie masz powiązania z cash/cashlinks. Żadnego powiązania poza opisem w cash.
rozwiązaniem tego problemu może być po prostu dodanie kolumny cash.icontentid, a wtedy nawet możnaby chyba wywalić z cash kolumnę invoiceid (choć jej wywalenie spowodowałoby spadek wydajności).
w przyszłości możnaby w ten sposób powiązywać przychody i rozchody sieci. Ale ja się nie znam na księgowości, więc może bredzę.
ERGO: jeśli już powiązywać to w kierunku takim aby wiązać wpłaty z dokuemntami czyli przyczyna (FV/paragon) -> skutek. To co proponujesz kojaży mi się z Kreowaniem Bytów Ponad Normę.
miałem na myśli powiązywanie operacji z cash.type=1 i 2, ale zaznaczyłem, że mogę bredzić i nie wiem czy będzie to komuś potrzebne.
I świadom jestem że mój model zakłada: wpłatę 120 (przy abonamencie 100 brutto) należy rozpisać tak że dodać 100 i numer dokumentu z abonamnetem oraz wpłatę 20 "luźną", ale widać też jak na dłoni potem w cash where userid=Dowlony_ustalony, wszystkie NAD płaty, im ktoś ma takich więcej tym bardziej go lubimy :) Twój model zakłada: dodać120, potem martwić się jak to rozksięgowąć. "potem" to złe założenie imvho. No chyba że zrobimy UI tak aby wymuszał powiązania w cashlinks.
właśnie o tym myślałem, żeby przy rejestrowaniu wpłaty pokazywać do wyboru nieopłacone zobowiązania użytkownika. A teraz jak wyciągnąć nieopłacone pozycje z cash? Proszę
SELECT cash.* FROM cash LEFT JOIN cashlinks ON (cash.id = covenant) WHERE userid = x AND type = 4 AND covenant IS NULL
trochę trudniej byłoby, gdy pozwolimy na opłacenie jednego obciążenia kilkoma wpłatami, czyli przy abonamencie 100,- user wpłaca 50,- ale myślę że i z tym bysmy sobie poradzili, choć może nie w jednym zapytaniu.
Oczywiście jeśli user dokona przedpłaty, to trzebaby później jakoś dopasowywać tą przedpłatę do nowego obciążenia, ale to i w twoim rozwiązaniu występuje.