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