Dobra, Krzyś rysuje reszta komentować:

teraz mamy cash:

id integer time integer DEFAULT 0 NOT NULL, adminid integer DEFAULT 0 NOT NULL, type smallint DEFAULT 0 NOT NULL, value numeric(9,2) DEFAULT 0 NOT NULL, taxvalue numeric(9,2)DEFAULT 0, userid integer DEFAULT 0 NOT NULL, comment varchar(255) DEFAULT '' NOT NULL, invoiceid integer DEFAULT 0 NOT NULL, PRIMARY KEY (id)

i np ID type value taxvalue 1 | 4 | 70.00 | | Abonament miesięczny "Pakiet 256" (za 2 | 4 | 30.00 | 22.00 | karta sieciow 3 | 3 | 70.00 | | Abonament miesięczny "Pakiet 256" (za

przyczym ID=3 oznacza wpłatę (type=3) a odpowiadający jej abo to ID=1 (type=4)

Rejestrowanie tutaj (w tabelce cash) okresów jest khem mało obiecujące na "przyszłość"

z cyklu różnych pomysłów:

a) TAXVALUe to VALUE być powinno: nie 22.00 (%) tylko 22% z 30, czyli 6.60.

b) type jest mocno dziwne, imvho dobrze jest rejestrować kierunek przepływu pieniędzy jak i sposób, a więc nie tyle type co direction: -1/1 albo 3/4 oraz rzeczywisty "typ" przy wpłatach np: 1-wpłata gotówką 2-przelewem 3-?chgw?

i przy obciążeniach: 1- fakturowane usługi miesięczne (internet) 2- fakturowane sprzedaż (karty sieciowe) 3- fakturowane usługi typu instalacja 100..103- to co wyżej tylko nie fakturowane

C)

Dodatkowe pole document_id: (int) jeśli to było zafakturowane obciążenie to jest to numer id z tabelki szczegółów faktur (invoice_contents). Jeśli nie było zafakturowane to jest to być może nr z piszączego się modułu KP.

W ten sposób mamy coś prostego: wyszukujemy np fakurę nr 33, ma ona 2 pozycje, id 30 i id 31, szukamy po document_id w cash i mamy obciązenie i wpłatę. Wpłat z tym samym document_id może być więcej, można dać 5 wpłat na poczet abonamentu, można zobaczyć czy ktoś nie przepłacił etc..

Aha: wpłąty robi się tylko w kwotach brutto, więc taxvalue tam będzie 0 albo NULL.

Jeśli chodzi o b) to jest to dodatek pozwalający zobaczyć po prostu czym dane obciążenie/wpłata jest i potem je filtrować.

Czekam na komentarze

kd.