Witam Mam pytanie co do sposobu działania skryptu lms-payments.
Generalnie zauważyłem że gdy Klient ma ustawioną należność na 4 maja to faktura generuje mu się 4 go maja. Problem polega na tym że gdy zapuszczę dwa razy skrypt lms-payments - faktura wygeneruje mu się dwa razy mimo że należność ustawiona jest jedna.
Kolejna kwestia - co jeżeli z jakiegoś powodu skrypt się nie wykona? owszem mogę cofnąć datę i wygenerować ręcznie ale nie zwsze muszę wiedzieć o tym że się nie wygenerowało. Czy nie ma możliwość by skrypt analizował każdą należność z całego okresu (np miesiąca) i sprawdzał czy FV została już wystawiona, jeżeli nie to generuje a jeżeli tak to pomija generowanie ?
pozdrawiam Michał Korzeniowski
Dnia 6 maj 2012 o godz. 14:31 Michał Korzeniowskimichal.korzeniowski@mediatelekom.pl napisał(a):
Witam Mam pytanie co do sposobu działania skryptu lms-payments.
Generalnie zauważyłem że gdy Klient ma ustawioną należność na 4 maja to faktura generuje mu się 4 go maja. Problem polega na tym że gdy zapuszczę dwa razy skrypt lms-payments - faktura wygeneruje mu się dwa razy mimo że należność ustawiona jest jedna.
Uruchamiaj raz dziennie okolo polnocy.
Kolejna kwestia - co jeżeli z jakiegoś powodu skrypt się nie wykona? owszem mogę cofnąć datę i
Mozesz tez uzyc opcji --fakedate
wygenerować ręcznie ale nie zwsze muszę wiedzieć o tym że się nie wygenerowało. Czy nie ma możliwość by skrypt analizował każdą należność z całego okresu (np miesiąca) i sprawdzał czy FV została już wystawiona, jeżeli nie to generuje a jeżeli tak to pomija generowanie ?
Afaik to wymagaloby dodatkowego powiazania dokuments/cash z assignments oraz zrezygnowania z usuwania zobowiazan na rzecz czegos w stylu deletetime.
nie wiem jak zbudowany jest cały system, może wystarczyłoby zaznaczać przy każdym naliczaniu/wystawianiu FV, że dana należność została "zafakturowana"
W poprzedniej firmie uczestniczyłem we wdrażaniu systemu ARA (od ksi.pl) oraz później we wdrażaniu systemu SORT od Comfortela i z tego co mówili wdrożeniowcy tam proces fakturowania polegał na analizowaniu całego zadanego okresu i wyszukiwaniu zobowiązań. do każdego zobowiązania wystawiane były FV i zobowiązanie system zaznaczał jako "załatwione".
Dzięki temu nie było możliwości by wystawić FV 2 razy za to samo jak również nie było szans by jakieś zobowiązanie zostało przeoczone. Może warto byłoby pójść w tym kierunku?
MK
W dniu 2012-05-06 14:51, Rafał Ramocki pisze:
Dnia 6 maj 2012 o godz. 14:31 Michał Korzeniowskimichal.korzeniowski@mediatelekom.pl napisał(a):
Witam Mam pytanie co do sposobu działania skryptu lms-payments.
Generalnie zauważyłem że gdy Klient ma ustawioną należność na 4 maja to faktura generuje mu się 4 go maja. Problem polega na tym że gdy zapuszczę dwa razy skrypt lms-payments - faktura wygeneruje mu się dwa razy mimo że należność ustawiona jest jedna.
Uruchamiaj raz dziennie okolo polnocy.
Kolejna kwestia - co jeżeli z jakiegoś powodu skrypt się nie wykona? owszem mogę cofnąć datę i
Mozesz tez uzyc opcji --fakedate
wygenerować ręcznie ale nie zwsze muszę wiedzieć o tym że się nie wygenerowało. Czy nie ma możliwość by skrypt analizował każdą należność z całego okresu (np miesiąca) i sprawdzał czy FV została już wystawiona, jeżeli nie to generuje a jeżeli tak to pomija generowanie ?
Afaik to wymagaloby dodatkowego powiazania dokuments/cash z assignments oraz zrezygnowania z usuwania zobowiazan na rzecz czegos w stylu deletetime.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 6 maja 2012 15:09 użytkownik Michał Korzeniowski michal.korzeniowski@mediatelekom.pl napisał:
nie wiem jak zbudowany jest cały system, może wystarczyłoby zaznaczać przy każdym naliczaniu/wystawianiu FV, że dana należność została "zafakturowana"
nie da się tego zrealizować bez zmian w strukturze bazy + części dotychczasowej logiki. Mnie nie zdarzyło się jeszcze że obecny system coś naliczył nie tak, ale faktycznie trzeba uważać co i jak się robi i obecny stan jest "kryminogenny".
W poprzedniej firmie uczestniczyłem we wdrażaniu systemu ARA (od ksi.pl) oraz później we wdrażaniu systemu SORT od Comfortela i z tego co mówili wdrożeniowcy tam proces fakturowania polegał na analizowaniu całego zadanego okresu i wyszukiwaniu zobowiązań. do każdego zobowiązania wystawiane były FV i zobowiązanie system zaznaczał jako "załatwione".
Dzięki temu nie było możliwości by wystawić FV 2 razy za to samo jak również nie było szans by jakieś zobowiązanie zostało przeoczone. Może warto byłoby pójść w tym kierunku?
Może warto... zrobisz? :)
W dniu 2012-05-06 14:51, Rafał Ramocki pisze:
Dnia 6 maj 2012 o godz. 14:31 Michał Korzeniowskimichal.korzeniowski@mediatelekom.pl napisał(a):
Witam Mam pytanie co do sposobu działania skryptu lms-payments.
Generalnie zauważyłem że gdy Klient ma ustawioną należność na 4 maja to faktura generuje mu się 4 go maja. Problem polega na tym że gdy zapuszczę dwa razy skrypt lms-payments - faktura wygeneruje mu się dwa razy mimo że należność ustawiona jest jedna.
Uruchamiaj raz dziennie okolo polnocy.
Kolejna kwestia - co jeżeli z jakiegoś powodu skrypt się nie wykona? owszem mogę cofnąć datę i
Mozesz tez uzyc opcji --fakedate
wygenerować ręcznie ale nie zwsze muszę wiedzieć o tym że się nie wygenerowało. Czy nie ma możliwość by skrypt analizował każdą należność z całego okresu (np miesiąca) i sprawdzał czy FV została już wystawiona, jeżeli nie to generuje a jeżeli tak to pomija generowanie ?
Afaik to wymagaloby dodatkowego powiazania dokuments/cash z assignments oraz zrezygnowania z usuwania zobowiazan na rzecz czegos w stylu deletetime.
W dniu 06.05.2012 15:09, Michał Korzeniowski napisał(a):
nie wiem jak zbudowany jest cały system, może wystarczyłoby zaznaczać przy każdym naliczaniu/wystawianiu FV, że dana należność została "zafakturowana"
W poprzedniej firmie uczestniczyłem we wdrażaniu systemu ARA (od ksi.pl) oraz później we wdrażaniu systemu SORT od Comfortela i z tego co mówili wdrożeniowcy tam proces fakturowania polegał na analizowaniu całego zadanego okresu i wyszukiwaniu zobowiązań. do każdego zobowiązania wystawiane były FV i zobowiązanie system zaznaczał jako "załatwione".
Dzięki temu nie było możliwości by wystawić FV 2 razy za to samo jak również nie było szans by jakieś zobowiązanie zostało przeoczone. Może warto byłoby pójść w tym kierunku?
Może i warto. To co przygotujesz łatkę?
MK
W dniu 06.05.2012 14:51, Rafał Ramocki napisał(a):
Dnia 6 maj 2012 o godz. 14:31 Michał Korzeniowskimichal.korzeniowski@mediatelekom.pl napisał(a):
Witam Mam pytanie co do sposobu działania skryptu lms-payments.
Generalnie zauważyłem że gdy Klient ma ustawioną należność na 4 maja to faktura generuje mu się 4 go maja. Problem polega na tym że gdy zapuszczę dwa razy skrypt lms-payments - faktura wygeneruje mu się dwa razy mimo że należność ustawiona jest jedna.
Uruchamiaj raz dziennie okolo polnocy.
Kolejna kwestia - co jeżeli z jakiegoś powodu skrypt się nie wykona? owszem mogę cofnąć datę i
Mozesz tez uzyc opcji --fakedate
wygenerować ręcznie ale nie zwsze muszę wiedzieć o tym że się nie wygenerowało. Czy nie ma możliwość by skrypt analizował każdą należność z całego okresu (np miesiąca) i sprawdzał czy FV została już wystawiona, jeżeli nie to generuje a jeżeli tak to pomija generowanie ?
Afaik to wymagaloby dodatkowego powiazania dokuments/cash z assignments oraz zrezygnowania z usuwania zobowiazan na rzecz czegos w stylu deletetime.
Niekoniecznie. U siebie używam w daemonie modułu payments, który wykorzystuje dodatkowe pole assignments.issuedto (przechowuje uniksowy znacznik czasu określający datą do której dane zobowiązanie zostało już wystawione).
W dniu 6 maja 2012 17:59 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Niekoniecznie. U siebie używam w daemonie modułu payments, który wykorzystuje dodatkowe pole assignments.issuedto (przechowuje uniksowy znacznik czasu określający datą do której dane zobowiązanie zostało już wystawione).
którą wersje bazy masz, że masz pole issuedto? mysql> describe assignments; +--------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | tariffid | int(11) | NO | MUL | 0 | | | customerid | int(11) | NO | MUL | NULL | | | period | smallint(6) | NO | | 0 | | | at | int(11) | NO | | 0 | | | datefrom | int(11) | NO | | 0 | | | dateto | int(11) | NO | | 0 | | | invoice | tinyint(1) | NO | | 0 | | | suspended | tinyint(1) | NO | | 0 | | | pdiscount | decimal(4,2) | NO | | 0.00 | | | liabilityid | int(11) | NO | | 0 | | | settlement | tinyint(1) | NO | | 0 | | | paytype | smallint(6) | YES | | NULL | | | numberplanid | int(11) | YES | MUL | NULL | | | vdiscount | decimal(9,2) | NO | | 0.00 | | +--------------+--------------+------+-----+---------+----------------+ 15 rows in set (0.01 sec)
mysql>
On Sun, 06 May 2012 17:59:16 +0200, Tomasz Chiliński tomasz.chilinski@chilan.com wrote:
W dniu 06.05.2012 14:51, Rafał Ramocki napisał(a):
Dnia 6 maj 2012 o godz. 14:31 Michał Korzeniowskimichal.korzeniowski@mediatelekom.pl napisał(a):
Witam Mam pytanie co do sposobu działania skryptu lms-payments.
Generalnie zauważyłem że gdy Klient ma ustawioną należność na 4 maja to faktura generuje mu się 4 go maja. Problem polega na tym że gdy zapuszczę dwa razy skrypt lms-payments - faktura wygeneruje mu się dwa razy mimo że należność ustawiona jest jedna.
Uruchamiaj raz dziennie okolo polnocy.
Kolejna kwestia - co jeżeli z jakiegoś powodu skrypt się nie wykona? owszem mogę cofnąć datę i
Mozesz tez uzyc opcji --fakedate
wygenerować ręcznie ale nie zwsze muszę wiedzieć o tym że się nie wygenerowało. Czy nie ma możliwość by skrypt analizował każdą należność z całego okresu (np miesiąca) i sprawdzał czy FV została już wystawiona, jeżeli nie to generuje a jeżeli tak to pomija generowanie ?
Afaik to wymagaloby dodatkowego powiazania dokuments/cash z assignments oraz zrezygnowania z usuwania zobowiazan na rzecz czegos w stylu deletetime.
Niekoniecznie. U siebie używam w daemonie modułu payments, który wykorzystuje dodatkowe pole assignments.issuedto (przechowuje uniksowy znacznik czasu określający datą do której dane zobowiązanie zostało już wystawione).
Hmmm jak tak myślę, to można to zrealizować również nie dodając całej kolumny, tylko zostawiając w bazie jakiś znacznik (tak jak czas ostatniego reloadu w tabeli hosts).
W dniu 06.05.2012 20:50, Rafał Ramocki napisał(a):
Niekoniecznie. U siebie używam w daemonie modułu payments, który wykorzystuje dodatkowe pole assignments.issuedto (przechowuje uniksowy znacznik czasu określający datą do której dane zobowiązanie zostało już wystawione).
Hmmm jak tak myślę, to można to zrealizować również nie dodając całej kolumny, tylko zostawiając w bazie jakiś znacznik (tak jak czas ostatniego reloadu w tabeli hosts).
Pod warunkiem, że uruchamiasz lms-payments jednokrotnie od razu dla wszystkich klientów. U siebie używam zmodyfikowanej wersji modułu payments daemona.
uczestnicy (5)
-
Marcin -
Michał Korzeniowski -
Rafał Ramocki -
Rafał Ramocki -
Tomasz Chiliński