Algorytm księgowania płatności masowych

[Misiu]

W tym watku jest mowa o rozksiegowywaniu wielokrotnosci wplat abonementowych i to dziala jak najbardziej poprawnie.

Sam ten wątek założyłem, więc wiem doskonale o jaki problem mi chodziło, czyli czy uwzględniany jest rabat, tj. "kwota z szablonu"-"rabat"="kwota do zaznaczenia"?

[Pyxis]

"Jak działa algorytm zaznaczania i księgowania abonamentów w płatnościach masowych? Z reguły znajdzie się kilka, których nie zaznaczy mimo, że kwota na fakturze zgadza się z kwotą wpłaty. Jak zaznaczę je ręcznie, to zaksięguje prawidłowo. Nie mogę znaleźć żadnej prawidłowości."

Ja czytam i wydawalo mi sie, ze chodzi wlasnie o ta wielokrotnosc.

[Misiu]

"Jak działa algorytm zaznaczania i księgowania abonamentów w płatnościach masowych? Z reguły znajdzie się kilka, których nie zaznaczy mimo, że kwota na fakturze zgadza się z kwotą wpłaty. Jak zaznaczę je ręcznie, to zaksięguje prawidłowo. Nie mogę znaleźć żadnej prawidłowości."

Ja czytam i wydawalo mi sie, ze chodzi wlasnie o ta wielokrotnosc.

Nie, nie o to mi chodziło. O wielokrotnościach to kotś dorzucił dodatkowo.

"Z reguły znajdzie się kilka, których nie zaznaczy mimo, że kwota na fakturze zgadza się z kwotą wpłaty.

Sob Maj 21, 2011 9:53 am
Ale uwzględniany jest rabat, czyli "kwota z szablonu"-"rabat"="kwota do zaznaczenia"?

Problem główny to nieuzwględnianie rabatu, co jest bez sensu, gdyż większości wpłat mi nie zaznacza i muszę ręcznie wchodzić w faktury usera, sprawdzać kwotę i ręcznie zaznaczać. Przy coraz większej ilości klientów z rabatem jest to strasznie upierdliwe.

[Pyxis]

Niestety nie da sie sensownie zrobic uwzgledniania rabatow. Algorytm mozna oprzec na pewnych stalych warunkach a sam rabat moze sie zmieniac w czasie i do tego czesto jest przyznawany jednorazowo lub na okreslony termin i pozniej informacja o jego kwocie znika z systemu.

[Misiu]

Niestety nie da sie sensownie zrobic uwzgledniania rabatow. Algorytm mozna oprzec na pewnych stalych warunkach a sam rabat moze sie zmieniac w czasie i do tego czesto jest przyznawany jednorazowo lub na okreslony termin i pozniej informacja o jego kwocie znika z systemu.

Nie bardzo rozumiem dlaczego, przecież porówanie dokonywane jest przy każdym księgowaniu. Jeśli wpłata zgadza się z kwotą z szablonu to jest zaznaczana. Kwota w szablonie może się tak samo zmieniać jak i kwota rabatu. Co więc stoi na przeszkodzie, aby jedną zmienną odejmować od drugiej? Przecież to tylko zwiększy skuteczność działania algorytmu i nie wpłynie negatywnie na wynik.

Skoro sprawdzanie rabatu i uwzględnianie go przy każdym seryjnym wystawianiu faktury nie jest problemem, to dlaczego miałoby to sprawiać trudność podczas zaznaczania płatności masowych?

Można na problem spojrzeć z drugiej strony i np. dorobić drugie porównanie, tj. jeśli kwota wpłaty zgadza się z kwotą ostatniej faktury usera to ją zaznaczyć.

[Pyxis]

W przypadku rabatow jednorazowych kwota rabatu w momencie wystawiania FV jest zerowana, wiec juz na starcie jestesmy na straconej pozycji.

Co do porownywania z FV - nie kazdy (stety/niestety) fakturuja swoich klientow a juz wiekszosc nie fakturuje kazdego tylko jakas grupe, wiec to nie bedzie dobrze dzialalo.

[Misiu]

W przypadku rabatow jednorazowych kwota rabatu w momencie wystawiania FV jest zerowana, wiec juz na starcie jestesmy na straconej pozycji.

Hmm, mam wrażanie, że rozmawiamy o zupełnie różnych rzeczach. Spróbuję jeszcze raz wyjaśnić.

1. Zanaczenie w płatnoścaich masowych następuje tylko gdy kwota wpłaty zgadza się z kwotą w szablonie.
2. Jeśli p. 1 jest prawdziwy to przy założeniu, że wszyscy klienci mają przyznany rabat w karcie użytkownia, automatycznie nie zostanie zaznaczona żadna wpłata. Wiąże się to z tym, że trzeba spojrzeć u każdego na kwotę faktury i jeśli jest zgodna to zanaczyć ręcznie wpłatę do zaksięgowania.
3. Jeśli algorytm sprawdzający od kwoty w szablonie odejmowałby kwotę rabatu i dopiero dokonywał porównania, to wpłaty zaznaczałby prawidłowo.


W czym problem? Jeśli rabat się skończy lub nie będzie go wogóle, to po prostu od kwoty w szablonie odjęte zostałoby zero, więc dalej wszystko będzie dzialać prawidłowo.

[Misiu]

W przypadku rabatow jednorazowych kwota rabatu w momencie wystawiania FV jest zerowana, wiec juz na starcie jestesmy na straconej pozycji.

Hmm, mam wrażanie, że rozmawiamy o zupełnie różnych rzeczach. Spróbuję jeszcze raz wyjaśnić.

1. Zanaczenie w płatnoścaich masowych następuje tylko gdy kwota wpłaty zgadza się z kwotą w szablonie.
2. Jeśli p. 1 jest prawdziwy to przy założeniu, że wszyscy klienci mają przyznany rabat w karcie użytkownia, automatycznie nie zostanie zaznaczona żadna wpłata. Wiąże się to z tym, że trzeba spojrzeć u każdego na kwotę faktury i jeśli jest zgodna to zanaczyć ręcznie wpłatę do zaksięgowania.
3. Jeśli algorytm sprawdzający od kwoty w szablonie odejmowałby kwotę rabatu i dopiero dokonywał porównania, to wpłaty zaznaczałby prawidłowo.


W czym problem? Jeśli rabat się skończy lub nie będzie go wogóle, to po prostu od kwoty w szablonie odjęte zostałoby zero, więc dalej wszystko będzie dzialać prawidłowo.

Ewentualnie może nie zostać zaznaczona wpłata, gdy rabatu już nie będzie, ale to jest niewlielki problem w porównaniu z ręcznym księgowaniem przez cały czas, w którym rabat jest uwzględniany.

[Pyxis]

Ale jest tez sytuacja, ze masz nierozliczone FV i po wstawieniu rabatu te starsze tez nie beda rozliczane, wiec to tak samo ulatwi jak i utrudni. Nie wide tu jakiegos generalnego sensownego rozwiazania.

[wrobli]

Poprostu program musilaby jestcze porownywac date lub fakture do ktorej zostal wystawiony rabat a to juz mi sie wydaje nie jest takie proste, ponieważ rabat by musialbys udzielany nie do uzytkownika a do faktury. Panie Piotrze poprostu wszyscy zakladaja ze platnosci sa regularne a takie nie sa przynajmniej u mnie i wtedy faktycznie sprawa wydaje sie prosta.

Pan Piotr proboje zwrocic uwage na sytuacje ze klient ma 3 fv nie rozliiczone z czego my ustawilismy rabat dla nastepnej a program juz bedzie staral sie odjac wartosc rabatu od zaleglych platnosci co wskazane nie jest.

Tak jak pisalem wczesniej funkcja dzialala by prawidlowo gdyby rozrowniala ze rabat ma byc odejmowany dla dokumentow wystepujacych po dacie ustawienia rabatu.

[Pyxis]

NApisanie takiego algorytmu to jedna sprawa a jego poprawne dzialnie to jeszcze inna. Mysle, ze to by nazbyt skomplikowalo cala sprawe rozliczen. Chyba sie na taki krok nie odwaze. :-)

[wrobli]

Mi by przydała się funkcja w płatnościach masowych przypisania kwoty do danej fv bo czasem muszę ręcznie rozliczać jeśli wpłata się nie zgadza kwoto.

Chyba że jest taka funkcja to poproszę o podpowiedz.

[Pyxis]

Przypisanie jest automatyczne wlasnie po kwocie danej FV. Recznie nie przypiszesz.

[wrobli]

A szkoda przydała by się funkcja przypisania wybrania fv która ma byc rozliczona jeśli nie może się określić.

Ale i tak juz jest w miarę wygodnie