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].