On Thu, Jan 27, 2005 at 10:23:56PM +0100, A.L.E.C wrote:
> hunter wrote:
>
> > Dodatkowe pole document_id: (int)
> > jeśli to było zafakturowane obciążenie to jest to numer id z tabelki
>
> znaczy się piszesz?
>
> 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.
> i teraz możemy do każdego obciążenia przypisać kilka wpłat albo na odwrót. Z
> tym, że potrzebowałbym jeszcze propozycji co do nazw kolumn, bo być może 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ę.
Cośtam mi mówią o planach kont i zespołach (aktualnie 4), ale:
w 99.9% przypadków F/V i tak isp czekają (a AŚKI(*) już się martwią o
odpisy podatku ich klientów).
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ę.
Spróbuj mają tabelkę z powiązaniami zrobić cokolwiek nie sięgając do
cash. Mało się uda, może % opłaconych i tyle. Zobacz:
dodajesz wpłatę, dodajesz cashlink, być może go nie dodajesz.
Mój model zakłada że każda wpłata jednak jest jakoś powiązana z nr
dokumentu co Ci pozwoli poszkać tam np rekordów z document_id==NULL i
już masz nadpłąty (type=3)/nierozdysponowane wpłaty oraz braki w
papierkach (bo co to za obiciążenie bez jakiegoś dokumentu).
Powiązanie wpłat/zobowiązań masz proste:
szukasz po id dokumentu. czynność powtarzasz dla każdej (pozycji) FV
(paragonu).
Owszem to co proponujesz nadaje się np do "rozdysponowywania nadpłat"
czy też "kompensat" ale nie zmierzam ychyba w tym kiernuku co?
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.
Można teżhybrydowo, zobowiązania oznaczać documentID, a cashlinks mieć
jako takie. Wtedy jeden rekord w cash z type=3 to jeden rzeczywisty
przelew/wpłąta od usera, co np przy próbach automagicznych wyciągów może
być korzystniejsze.
kd.
ps/
*) pozdrawiamy Taką Jedną[tm].
--
Krzysztof Drewicz
Podsłuchane na pogrzebie: "Wiem, że to niezręcznie pytać o takie rzeczy w tej
chwili, ale przypominasz sobie, żeby on kiedykolwiek wspomniał coś o kodzie
źródłowym?" --- Charles Addams
