On Sun, Jan 30, 2005 at 06:43:13PM +0100, A.L.E.C wrote:

hunter wrote:

...

imvho: cash to cash, obiciążenie nie wynika tylko z FV/invoice a więc nie można tego powiązywania zawężać do invoice. dodanie do cash w rekordach obciążających invhoice/contentid nie zaszkodzi (8 bajtów więcej/rekord)

czyli tutaj już nie mam wątpliwości

/me too. Tzn w kwestii notowania id obciążenia, jeszcze tylko aby nie strzelać sobie po stopach: "obciążenia nie-fakturowane np na paragon chcemy jakoś numerować?" Albo: "czy w tabeli invoices mogą się pojawić nie-faktury, tylko np rachunki[*]" Bo invoice może również przechowywać inne iności, wystarczy że mają swoją numerację inną. Chodzi mi tutaj o ucieczkę z typem dokumentu do invoices.

*] np dla osób podmiotowo zwolnionych z płacenia VAT.

Z cyklu głupich pytań: w invoicecontents to invoiceid i jeszcze jakiś order by się przydał, tzn numerek na FV od razu możemy założyć to będzie raczej 8 bitów :) czyli nr z invoiceid+1-bajt do cash, małe obciążenie a od razu widać za co to jest obciążenie. Od razu mówię że olewamy szerokim strumieniem moczu 3-pn w kwestji np dublowania userid ale tłumaczymy to wydajnością bazy czy specyfiką rejestracji FV (rejestrować trzeba to co jest drukowane).

...

jedną wpłate 100 do cash i likujemy jako rozliczenie zaległości (czyli id z cash, id faktury/pozycji być_może_duplikujemy), księgujemy dodatkowe 50 bez zaznaczenia "za co". Bo to się na prawdę do tego sprowadza. W przypadku nr 2 mamy zupełnie za darmo (no za mniej pracy) wpisy w bilansie użytkownika "wpłata" i np <<rozliczenie za>> "tutaj tekst z 30ciej pozycji faktury nr.5" oraz około sekundy później: "wpłata" -- <<nadpłata>>.

ja byłbym tutaj za przypadkiem nr 2, i to wcale nie dlatego że mniej pracy, ale zawsze jestem za upraszczaniem czego się da, no i w niczym chyba nie przeszkadza, żeby rozbijać wpłaty użytkownika na kilka pozycji.

No mi też nie. Powstaje pytanie tylko czy ktoś będzie chciał potem jakieś zestawienia bazujące na "ile dni po terminie w skali roku użytkonicy opłacali zobowiązania". Ale raczej normalne będzie np Faktrua na 122.00 zł, (np id=5) -> cash 100 + 22 vatu, obciążenie, invoice_id=5 wpłąta 150 -> cash 122 wpłata, invoice_id=5 -> cash 38 wpłata, invoice_id=null

Następna faktura (122.00, id=7). do starej wpłaty dopisujemy invoice_id=7 (to MOŻE dziać się pół-automagicznie, kwestia implementacji). -> cash 38 wpłata, invoice_id=7 wpłata 84 -> cash 84 wpłata, invoice_id=7

Jednocześnie mamy gratis timestamp w przedpłacie, co powoduje że mój ekonometryczno-statystyno-informatyczno-ekonomiczy uśmiech się poszerza.

hmm.. mi invoicecontents odpowiada tak jak teraz jest

Mi też. Tylko lubię wysłuchać opinii kilku ludzi, zanim będzie za późno na odkręcanie.

...

Alec?

zbliżamy stanowiska, pewnie w tym tygodniu zacznę, jak się sponsor

uhu, ja tam zawsze kompromisowy byłem. Jedyne przy czym będę się upierał to aby po zarejestrowaniu np 10 wpłat nie edytować tej 11 wstecz, co najwyżej ją inaczej opisać np dodać invoice/content_id, etc ale nie zmieniać kwoty i timestampa.

zdecyduje, a może się jeszcze ktoś przyłączy finansowo?

lms-support :p

kd.