zawieszenie blokowania, data wygaśnięcia umowy
Czy w ferworze zmian dało by się również wprowadzić dwa pola u klienta: 1. checkbox mówiący o zablokowaniu blokad. znaczy, że user mimo zaległości nie zobaczy ostrzeżeń ani nie będzie zablokowany. jedno pole tinyint(1) w tableli nodes, defaultowo "0", czyli normalne blokowanie a przy zaznaczonym "ptaszku" pole zmienia wartość na "1"
2. pole mówiące o dacie zakończenia umowy, chętnie dodatkowo nr tej umowy. można by wtedy parserem do terminarza wrzucać kończące się umowy.
zapewne pomogłoby to nie tylko mi.
W dniu 12.04.2012 14:21, Marcin napisał(a):
Czy w ferworze zmian dało by się również wprowadzić dwa pola u klienta:
- checkbox mówiący o zablokowaniu blokad. znaczy, że user mimo
zaległości nie zobaczy ostrzeżeń ani nie będzie zablokowany. jedno pole tinyint(1) w tableli nodes, defaultowo "0", czyli normalne blokowanie a przy zaznaczonym "ptaszku" pole zmienia wartość na "1"
Nie rozwiązałoby problem dozwolenie na wpisywanie do nodes.cutoffstop daty bardzo odległej w przyszłości?
tej umowy. można by wtedy parserem do terminarza wrzucać kończące się umowy.
Myślę, że do tego lepiej użyć schematu promocyjnego - on w końcu od tego jest.
zapewne pomogłoby to nie tylko mi.
W dniu 12 kwietnia 2012 16:18 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Nie rozwiązałoby problem dozwolenie na wpisywanie do nodes.cutoffstop daty bardzo odległej w przyszłości?
teoretycznie może i tak. ale jeśli nie blokujemy to nie blokujemy wcale, bo ta data z odległej przyszłości może się okazać przeszłością :)
tej umowy. można by wtedy parserem do terminarza wrzucać kończące
się umowy.
Myślę, że do tego lepiej użyć schematu promocyjnego - on w końcu od tego jest.
ale nie każdy używa promocji. może być zwykła lojalka i co wówczas ? nie ma promocji.
W dniu 12.04.2012 15:22, Marcin napisał(a):
W dniu 12 kwietnia 2012 16:18 użytkownik Tomasz Chiliński <tomasz.chilinski@chilan.com [1]> napisał:
Nie rozwiązałoby problem dozwolenie na wpisywanie do nodes.cutoffstop daty bardzo odległej w przyszłości?
teoretycznie może i tak. ale jeśli nie blokujemy to nie blokujemy wcale, bo ta data z odległej przyszłości może się okazać przeszłością :)
tej umowy. można by wtedy parserem do terminarza wrzucać kończące się umowy.
Myślę, że do tego lepiej użyć schematu promocyjnego - on w końcu od tego jest.
ale nie każdy używa promocji. może być zwykła lojalka i co wówczas ? nie ma promocji.
Nie no nazwa promocja to kwestia umowna. Przecież równie dobrze możemy między sobą lojalkę nazywać promocją. Istotny jest mechanizm a nie nazwa własna.
W dniu 12 kwietnia 2012 16:25 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
Nie no nazwa promocja to kwestia umowna. Przecież równie dobrze możemy między sobą lojalkę nazywać promocją. Istotny jest mechanizm a nie nazwa własna.
ja osobiście z tych "promocji" nie używałem, szczerze powiedziawszy widziałem tą opcję, ale co i jak nie zagłębiałem się. z drugiej strony było by fajnie widzieć czas kiedy kończy się umowa.
W dniu 2012-04-12 15:21, Marcin pisze:
Czy w ferworze zmian dało by się również wprowadzić dwa pola u klienta:
- checkbox mówiący o zablokowaniu blokad. znaczy, że user mimo
zaległości nie zobaczy ostrzeżeń ani nie będzie zablokowany. jedno pole tinyint(1) w tableli nodes, defaultowo "0", czyli normalne blokowanie a przy zaznaczonym "ptaszku" pole zmienia wartość na "1"
Zrób sobie grupę vip i wrzucaj di niej takich klientów.
- pole mówiące o dacie zakończenia umowy, chętnie dodatkowo nr tej
umowy. można by wtedy parserem do terminarza wrzucać kończące się umowy.
zapewne pomogłoby to nie tylko mi.
-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 12 kwietnia 2012 17:53 użytkownik Admin - Dar.Net admin@darnet.plnapisał:
Zrób sobie grupę vip i wrzucaj di niej takich klientów.
to jest myśl
Przyglądam się jeszcze, analizuje i wywnioskowałem że przydały by się 3 statusy komputera klienta. obecnie są dwa: włączony i wyłączony, przydałby się jeszcze zablokowany. stany: włączony - normalna praca zablokowany - klient może się połączyć, dostanie ip ale zostanie przekierowany na odpowiednią stronę. wyłączony - klient nie zaloguje się (pppoe), lub przy dhcp nie dostanie adresu, przy radiusie itp żadne eapy go nie wpuszczą.
co do grupy VIP i wrzucanie ludzi do tej grupy i uwzględnienie tego w skryptach by ich nie blokować jest dobrym pomysłem, ale każdy wówczas musi przerabiać skrypty pod siebie. nie jest to problemem, ale mało uniwersalne :)
W dniu 2012-04-12 18:24, Marcin pisze:
Przyglądam się jeszcze, analizuje i wywnioskowałem że przydały by się 3 statusy komputera klienta. obecnie są dwa: włączony i wyłączony, przydałby się jeszcze zablokowany. stany: włączony - normalna praca zablokowany - klient może się połączyć, dostanie ip ale zostanie przekierowany na odpowiednią stronę. wyłączony - klient nie zaloguje się (pppoe), lub przy dhcp nie dostanie adresu, przy radiusie itp żadne eapy go nie wpuszczą.
co do grupy VIP i wrzucanie ludzi do tej grupy i uwzględnienie tego w skryptach by ich nie blokować jest dobrym pomysłem, ale każdy wówczas musi przerabiać skrypty pod siebie. nie jest to problemem, ale mało uniwersalne :)
Jest przecież lms.ini
-- Pozdrawiam Marcin / nicraM
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 12 kwietnia 2012 18:30 użytkownik Admin - Dar.Net admin@darnet.plnapisał:
Jest przecież lms.ini
w lms.ini jest tylko wzmianka o kwocie. analizując kod lms-cutof mam takie fragmetny kodu"
#v+ my $limit = $ini->val('cutoff', 'limit') || 0; my $message = $ini->val('cutoff', 'message') || 'Automatic cutoff caused by exceeding of liabilities limit on %now'; my $only_due = $ini->val('cutoff', 'only_due') || '1'; my $extend_deadline = $ini->val('cutoff', 'extend_deadline') || '7'; my $excluded_customergroups = $ini->val('cutoff', 'excluded_customergroups') || ''; my $customergroups = $ini->val('cutoff', 'customergroups') || '
if ($excluded_customergroups ne '') { $filter = $filter . " AND (SELECT count(*) FROM customerassignments WHERE customerassignments.customerid = customers.id AND customerassignments.customergroupid IN ($excluded_customergroups)) = 0"; #v-
czyli mam excluded_cusotmergroups. co tu mam wpisać? nazwę grupy czy id grupy? przy id, to każdy będzie miał inne.
W dniu 12 kwietnia 2012 18:39 użytkownik Marcin marcin@nicram.net napisał:
czyli mam excluded_cusotmergroups. co tu mam wpisać? nazwę grupy czy id grupy? przy id, to każdy będzie miał inne.
ok, wpisac id
dobra, mam dwie zmienne: $customergroups - z tego co rozumem, zmienna ta ma zawierać id grup dla których robić odcięcie oraz $excluded_customergroups - jak rozumiem, id grup dla których nie robić odcięcia. u mnie grupa vip ma id 15
w zmiennej $customergropus wstawiam nr nie istniejącej grupy. czyli, skrypt nie powinien mi nikogo znaleźć. w zmiennej $excluded_customergroups ustawiam moje id 15 dla grupy vip.
zapuszczam skrypt lms-cutoff i dla grupy id 15 jak najbardzien nie wyłączył komputera, ale wyłączył mi dziesiątki innych. tak wygląda zmienna $fileter po wyłołaniu:
#v+ deleted = 0 AND cutoffstop < UNIX_TIMESTAMP() AND ((documents.paytime > 0 AND cdate + ((documents.paytime + 7) * 86400) < UNIX_TIMESTAMP()) OR documents.paytime = 0 OR documents.paytime IS NULL) AND (SELECT count(*) FROM customerassignments WHERE customerassignments.customerid = customers.id AND customerassignments.customergroupid IN (15)) = 0 AND (SELECT count(*) FROM customerassignments WHERE customerassignments.customerid = customers.id AND customerassignments.customergroupid IN (1111)) = 0 #v-
kasuję id ze zmiennej $excluded_customergroups i zostawiam nie istniejącą grupę w $customergroups, czyli nie powinien mi wyłapać żadnego komputera, gdyż taka grupa nie istnieje. ale tu jest zonk. znajduje wszystkich a zmienna $filter wygląda tak:
#v+ deleted = 0 AND cutoffstop < UNIX_TIMESTAMP() AND ((documents.paytime > 0 AND cdate + ((documents.paytime + 7) * 86400) < UNIX_TIMESTAMP()) OR documents.paytime = 0 OR documents.paytime IS NULL) AND (SELECT count(*) FROM customerassignments WHERE customerassignments.customerid = customers.id AND customerassignments.customergroupid IN (1111)) = 0 #v- czyli jest błąd w samym zapytaniu sql :(
Wiadomość napisana przez Marcin w dniu 2012-04-12, o godz. 15:21:
- pole mówiące o dacie zakończenia umowy, chętnie dodatkowo nr tej umowy. można by wtedy parserem do terminarza wrzucać kończące się umowy.
To akurat kiepski pomysł aby w boxie z informacjami o klientach umieszczać info o końcu umowy. Mamy klientów, którzy mają po 2-3 umowy na różne lokalizacje, różne pakiety
W dniu 12 kwietnia 2012 20:33 użytkownik "D.Wesołowski" wesoly@klu.plnapisał:
To akurat kiepski pomysł aby w boxie z informacjami o klientach umieszczać info o końcu umowy. Mamy klientów, którzy mają po 2-3 umowy na różne lokalizacje, różne pakiety
no tak, taka sytuacja może się zdarzyć. w jaki sposób jesteś informowany o kończących się umowach skoro klienci mają ich i po 3?
Wiadomość napisana przez Marcin w dniu 2012-04-12, o godz. 20:46:
W dniu 12 kwietnia 2012 20:33 użytkownik "D.Wesołowski" wesoly@klu.pl napisał: To akurat kiepski pomysł aby w boxie z informacjami o klientach umieszczać info o końcu umowy. Mamy klientów, którzy mają po 2-3 umowy na różne lokalizacje, różne pakiety
no tak, taka sytuacja może się zdarzyć. w jaki sposób jesteś informowany o kończących się umowach skoro klienci mają ich i po 3?
zobowiązania mają daty pokrywające się z datami umów, w liscie klientow dodalem dwa filtry 'bez taryfy < 35 dni' oraz 'bez taryfy < 65 dni', czyli lista osob, którym zobowiązania do 35/65 dni przestaną obowiązywać
W dniu 12 kwietnia 2012 21:36 użytkownik "D.Wesołowski" wesoly@klu.plnapisał:
zobowiązania mają daty pokrywające się z datami umów, w liscie klientow dodalem dwa filtry 'bez taryfy < 35 dni' oraz 'bez taryfy < 65 dni', czyli lista osob, którym zobowiązania do 35/65 dni przestaną obowiązywać
pomysł dobry, ale nie do końca ergonomiczny
W dniu 2012-04-13 08:06, Marcin pisze:
W dniu 12 kwietnia 2012 21:36 użytkownik "D.Wesołowski" <wesoly@klu.pl mailto:wesoly@klu.pl> napisał:
zobowiązania mają daty pokrywające się z datami umów, w liscie klientow dodalem dwa filtry 'bez taryfy < 35 dni' oraz 'bez taryfy < 65 dni', czyli lista osob, którym zobowiązania do 35/65 dni przestaną obowiązywaćpomysł dobry, ale nie do końca ergonomiczny
w dużym systemie z którym mam do czynienia, do zarządzania procesami, dokumentami, umowami, fakturami w wodociągach, też wygląda to podobnie, generuje się raport, które umowy kiedy się kończą oraz jest możliwość wyświetlania okienka z listą umów, które się kończą.
Można by rozszerzyć w takim razie welcome.html o box z takimi informacjami - ilość umów które wygasną, kwestia tylko co dla kogo jest jednoznaczne z umową, dla nas termin zobowiązania na podstawie którego nasz szablon umowy generuje treść umowy, łącznie z przypisanym komputerem i miejscem jego instalacji.
Pomysł z pogranicza fantazji, może dorobimy tabele - powiązanie taryfy z umową np documentassignments :) + info o długości umowy ( ew. powiązanie na sztywno terminów umowy z zobowiązaniem )
hehehe
Pozdrawiam
W dniu 12 kwietnia 2012 20:33 użytkownik "D.Wesołowski" wesoly@klu.plnapisał:
Wiadomość napisana przez Marcin w dniu 2012-04-12, o godz. 15:21:
- pole mówiące o dacie zakończenia umowy, chętnie dodatkowo nr tej umowy.
można by wtedy parserem do terminarza wrzucać kończące się umowy.
To akurat kiepski pomysł aby w boxie z informacjami o klientach umieszczać info o końcu umowy. Mamy klientów, którzy mają po 2-3 umowy na różne lokalizacje, różne pakiety
-- D.Wesołowski wesoly@klu.pl
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
W dniu 12.04.2012 19:47, milek napisał(a):
Pomysł z pogranicza fantazji, może dorobimy tabele - powiązanie taryfy z umową np documentassignments :) + info o długości umowy ( ew. powiązanie na sztywno terminów umowy z zobowiązaniem )
hehehe
Albo zrobić tak jak jest rzeczywiście, czyli dodać pola ustalające okres obowiązywania/ważności dokumentu (data od i data do). Do tego powiadamiacz o zbliżających się datach wygaśnięcia dokumentu.
Pozdrawiam
W dniu 12 kwietnia 2012 20:52 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
W dniu 12.04.2012 19:47, milek napisał(a):
Pomysł z pogranicza fantazji, może dorobimy tabele - powiązanie
taryfy z umową np documentassignments :) + info o długości umowy ( ew. powiązanie na sztywno terminów umowy z zobowiązaniem )
hehehe
Albo zrobić tak jak jest rzeczywiście, czyli dodać pola ustalające okres obowiązywania/ważności dokumentu (data od i data do). Do tego powiadamiacz o zbliżających się datach wygaśnięcia dokumentu.
Tutaj, potrzebny byłby jeszcze jakiś znacznik + ( moje umowy po "dacie do" przechodzą w bezterminowe )
Pozdrawiam
-- Pozdrawiam Tomasz Chiliński, Chilan ______________________________**_________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/**mailman/listinfo/lmshttp://lists.lms.org.pl/mailman/listinfo/lms
W dniu 12.04.2012 20:12, milek napisał(a):
W dniu 12 kwietnia 2012 20:52 użytkownik Tomasz Chiliński <tomasz.chilinski@chilan.com [3]> napisał:
W dniu 12.04.2012 19:47, milek napisał(a):
Pomysł z pogranicza fantazji, może dorobimy tabele - powiązanie taryfy z umową np documentassignments :) + info o długości umowy ( ew. powiązanie na sztywno terminów umowy z zobowiązaniem )
hehehe
Albo zrobić tak jak jest rzeczywiście, czyli dodać pola ustalające okres obowiązywania/ważności dokumentu (data od i data do). Do tego powiadamiacz o zbliżających się datach wygaśnięcia dokumentu.
Tutaj, potrzebny byłby jeszcze jakiś znacznik + ( moje umowy po "dacie do" przechodzą w bezterminowe )
To u Ciebie taki dokument nie traci ważności. A zmiana warunków i tak powinna być realizowana poprzez zmianę obowiązującego zobowiązania.
uczestnicy (5)
-
"D.Wesołowski" -
Admin - Dar.Net -
Marcin -
milek -
Tomasz Chiliński