[OT] Podziekowania
Witam.
Nigdy jakoś specjalnie nie lubiłem LMS-a, ale muszę obiektywnie przyznać, ze w tym roku uratował mi dojpę ;) Oczywiście do spólki z dużą ilością kung-fu i rękodzieła, ale siis za 2011 został odpykany ;)
Dzięki.
PS, teraz juz tylko winko i relaks ..
Pokaż odpowiedzi według wątków
Witam
Widzę, że ostatnio rozwój LMS przyspieszył. Przesyłam więc poniżej listę propozycji do wprowadzenia
1. dodawanie informacji do klienta w formie wpisów (data godzina, kto dokonał wpisu), tak żeby mieć historię kontaktów z klientem ( chodzi mi o okienko informacje) 2. Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja) 3. Normalne prawa dostępu, obecnie jest to źle rozwiązane i nie można ustawić np. żeby serwisanci widzieli klienta, mogli edytować jego komputery, widzieli że jest zadłużony (kwota łączna), ale nie mieli widoku na dokumenty finansowe, żeby nie widzieli na liście klientów ile łącznie kasy jest. Tak samo w taryfach, żeby nie widzieli jaki łącznie przychód. 4. Informacje o kończących się umowach 5. Poprawienie ergonomii systemu. Tutaj dużo by pisać. LMS niestety nie jest intuicyjnym systemem i wymagał by sporych modyfikacji w interfejsie użytkowania. Nie wiem tylko czy takie coś jest w ogóle możliwe ?
pozdrawiam
Daniel
W dniu 16.03.2012 09:58, Daniel Kulesza napisał(a):
Witam
Witaj.
Widzę, że ostatnio rozwój LMS przyspieszył. Przesyłam więc poniżej listę propozycji do wprowadzenia
Miejmy nadzieję, że i ludzie zaczną w gitach znacznie więcej przetwarzać, co zaowocuje zwiększeniem ilości kodu włączanego do głównej gałęzi.
- dodawanie informacji do klienta w formie wpisów (data godzina, kto
dokonał wpisu), tak żeby mieć historię kontaktów z klientem ( chodzi mi o okienko informacje)
Dlaczego nie w helpdesku?
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Możliwe, że do tego nadałaby się opcja przy zobowiązaniu typu "wyłącz z grupowania na faktrze". Chyba, że chodzi nie tylko o wyłączenie z grupowania zobowiązań w jednej fakturze, ale o dowolne grupowanie zobowiązań?
- Normalne prawa dostępu, obecnie jest to źle rozwiązane i nie można
ustawić np. żeby serwisanci widzieli klienta, mogli edytować jego komputery, widzieli że jest zadłużony (kwota łączna), ale nie mieli widoku na dokumenty finansowe, żeby nie widzieli na liście klientów ile łącznie kasy jest. Tak samo w taryfach, żeby nie widzieli jaki łącznie przychód.
Większość z tego już jest w wersji git.
- Informacje o kończących się umowach
Tu zapewne będzie przydatny skrypt, albo opcja w jednym z istniejących skryptów. Kończące się umowy rozpoznajesz na podstawie daty końca obowiązywania zobowiązania?
- Poprawienie ergonomii systemu. Tutaj dużo by pisać. LMS niestety
nie jest intuicyjnym systemem i wymagał by sporych modyfikacji w interfejsie użytkowania. Nie wiem tylko czy takie coś jest w ogóle możliwe ?
Tutaj to jest roboty na wiele lat, ale trzeba zaczynać od drobiazgów. W wielu miejscach można uniknąć pełnych przeładowań strony wykorzystując chociażby AJAX i nieco więcej javascriptu.
Nie jestem zwolennikiem rewolucji, bo wiem czym to się często kończy (w przypadku projektów programistycznych zwykle następuje wtedy okres zniechęcenia i marazmu).
pozdrawiam
Daniel
W dniu 16.03.2012 09:58, Daniel Kulesza napisał(a):
Witam
Widzę, że ostatnio rozwój LMS przyspieszył. Przesyłam więc poniżej listę propozycji do wprowadzenia
- dodawanie informacji do klienta w formie wpisów (data godzina, kto
dokonał wpisu), tak żeby mieć historię kontaktów z klientem ( chodzi mi o okienko informacje) 2. Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja) 3. Normalne prawa dostępu, obecnie jest to źle rozwiązane i nie można ustawić np. żeby serwisanci widzieli klienta, mogli edytować jego komputery, widzieli że jest zadłużony (kwota łączna), ale nie mieli widoku na dokumenty finansowe, żeby nie widzieli na liście klientów ile łącznie kasy jest. Tak samo w taryfach, żeby nie widzieli jaki łącznie przychód. 4. Informacje o kończących się umowach 5. Poprawienie ergonomii systemu. Tutaj dużo by pisać. LMS niestety nie jest intuicyjnym systemem i wymagał by sporych modyfikacji w interfejsie użytkowania. Nie wiem tylko czy takie coś jest w ogóle możliwe ?
Zapomniałem dodać, że teraz "na radarze" mamy: 1) Przejście z lokalizacjami klientów na obsługę TERYT (nadal musi zostać możliwość wpisywania dowolnych adresów). Tu zmiany zaczniemy od rozbicia pola address i post_address na *_street, *_house, *_flat. Będziemy wymagana aktualizacja schematu bazy danych, która przy okazji spróbuje automatycznie rozbić pola adresu na poszczególne części. Trochę doświadczeń związanych z lms-teryt już jest, więc na pewno będzie łatwiej, ale dobrze byłoby, żeby pojawiło się więcej uwag odnośnie rozbijania adresu na części. 2) Integracja obsługi platformy VoIP jednej z firm z którą jestem w kontakcie. W chwili obecnej są dostępne patche tylko do wersji 1.11.x, więc troszkę roboty z portowaniem na pewno będzie, a jeszcze więcej z i18n oraz dostosowaniem do baz obsługiwanych przez LMSDB. Zobaczymy jak i czy uda się to zrobić.
pozdrawiam
Daniel
W dniu 2012-03-16 10:18, Tomasz Chiliński pisze:
W dniu 16.03.2012 09:58, Daniel Kulesza napisał(a):
Witam
Witaj.
Widzę, że ostatnio rozwój LMS przyspieszył. Przesyłam więc poniżej listę propozycji do wprowadzenia
Miejmy nadzieję, że i ludzie zaczną w gitach znacznie więcej przetwarzać, co zaowocuje zwiększeniem ilości kodu włączanego do głównej gałęzi.
- dodawanie informacji do klienta w formie wpisów (data godzina, kto
dokonał wpisu), tak żeby mieć historię kontaktów z klientem ( chodzi mi o okienko informacje)
Dlaczego nie w helpdesku?
Z założenia heldesk u mnie służy do obsługi serwisowej (przez serwisantów) i kontaktów z klientami.
W informacjach klienta zapisujemy to co dzieje się w BOK np. Klient zobowiązał się do spłaty zadłużenia ratami, Klient zmienił taryfę (takie rzeczy to już z automatu powinny być logowane), Że należy coś tam wyjaśnić z klientem. Ogólnie chodzi o informacje, które ma widzieć pracownica przy przyjmowaniu wpłaty. Dla mnie idealne by było (dodaj wpis, edytuj, usuń) do tego data dodania i nazwa użytkownika. Wyświetlanie kilku wpisów, a reszta po kliknięciu np. historia wpisów.
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Możliwe, że do tego nadałaby się opcja przy zobowiązaniu typu "wyłącz z grupowania na faktrze". Chyba, że chodzi nie tylko o wyłączenie z grupowania zobowiązań w jednej fakturze, ale o dowolne grupowanie zobowiązań?
Jeżeli będzie to konfigurowalne dla każdego klienta osobno to wtedy może być samo wyłączenie.
- Normalne prawa dostępu, obecnie jest to źle rozwiązane i nie można
ustawić np. żeby serwisanci widzieli klienta, mogli edytować jego komputery, widzieli że jest zadłużony (kwota łączna), ale nie mieli widoku na dokumenty finansowe, żeby nie widzieli na liście klientów ile łącznie kasy jest. Tak samo w taryfach, żeby nie widzieli jaki łącznie przychód.
Większość z tego już jest w wersji git.
Sprawdzę dzisiaj :)
- Informacje o kończących się umowach
Tu zapewne będzie przydatny skrypt, albo opcja w jednym z istniejących skryptów. Kończące się umowy rozpoznajesz na podstawie daty końca obowiązywania zobowiązania?
Tak. Tylko jest jeden problem (może jest taka opcja a nie znalazłem), chciałbym, aby była możliwość ustawienia w opcjach, że zobowiązanie(taryfa) mimo końca swojego terminu dalej jest naliczane. Chodzi tutaj o przypadek, gdy umowy na czas określony przechodzą na czas nieokreślony.
- Poprawienie ergonomii systemu. Tutaj dużo by pisać. LMS niestety
nie jest intuicyjnym systemem i wymagał by sporych modyfikacji w interfejsie użytkowania. Nie wiem tylko czy takie coś jest w ogóle możliwe ?
Tutaj to jest roboty na wiele lat, ale trzeba zaczynać od drobiazgów. W wielu miejscach można uniknąć pełnych przeładowań strony wykorzystując chociażby AJAX i nieco więcej javascriptu.
Nie jestem zwolennikiem rewolucji, bo wiem czym to się często kończy (w przypadku projektów programistycznych zwykle następuje wtedy okres zniechęcenia i marazmu).
Też jestem zwolennikiem ewolucji a nie rewolucji. Zastanowię się i opiszę listę drobiazgów do poprawienia.
W dniu 2012-03-16 10:50, Daniel Kulesza pisze:
W dniu 2012-03-16 10:18, Tomasz Chiliński pisze:
W dniu 16.03.2012 09:58, Daniel Kulesza napisał(a):
- dodawanie informacji do klienta w formie wpisów (data godzina, kto
dokonał wpisu), tak żeby mieć historię kontaktów z klientem ( chodzi mi o okienko informacje)
Dlaczego nie w helpdesku?
Z założenia heldesk u mnie służy do obsługi serwisowej (przez serwisantów) i kontaktów z klientami.
Podobne założenie jest u mnie. Do zgłaszania i przetwarzania zgłoszeń klienta.
W informacjach klienta zapisujemy to co dzieje się w BOK np. Klient zobowiązał się do spłaty zadłużenia ratami, Klient zmienił taryfę (takie rzeczy to już z automatu powinny być logowane), Że należy coś tam wyjaśnić z klientem. Ogólnie chodzi o informacje, które ma widzieć pracownica przy przyjmowaniu wpłaty. Dla mnie idealne by było (dodaj wpis, edytuj, usuń) do tego data dodania i nazwa użytkownika. Wyświetlanie kilku wpisów, a reszta po kliknięciu np. historia wpisów.
Trzeba rozgraniczyć dwie osobne sprawy. Historie zmian w kliencie, a informacje o kliencie od obslugi
Jeśli chodzi o historie zmian to jest jak najbardziej za aby to gdzieś przetrzymywać bo w tej chwili jedyna opcja to zaciągniecie backupu z danego dnia. Oczywiści zapisujemy tylko to co laduje w bazie w czasie backupu. Historia zmian z UI badz z trigerów trzymała by pełny obraz modyfikacji.
Informacje dla obsługi, w zasadzie już są (informacje) ale czy zmodyfikować je do formy poszczególnych wpisów z datownikiem to pozostawiam do osobnej dyskusji.
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Możliwe, że do tego nadałaby się opcja przy zobowiązaniu typu "wyłącz z grupowania na faktrze". Chyba, że chodzi nie tylko o wyłączenie z grupowania zobowiązań w jednej fakturze, ale o dowolne grupowanie zobowiązań?
Jeżeli będzie to konfigurowalne dla każdego klienta osobno to wtedy może być samo wyłączenie.
Mój pomysł na... w taryfie (assignments) dodać pole groupinvoice::smallint z domyślna wartością 0 bądź 1 (nie ma znaczenia w założeniu). I teraz grupować będzie taryfy na FV zgodnie z ich nr grupy. Mam nadzieje ze to dość jasne.
- Informacje o kończących się umowach
Tu zapewne będzie przydatny skrypt, albo opcja w jednym z istniejących skryptów. Kończące się umowy rozpoznajesz na podstawie daty końca obowiązywania zobowiązania?
Tak. Tylko jest jeden problem (może jest taka opcja a nie znalazłem), chciałbym, aby była możliwość ustawienia w opcjach, że zobowiązanie(taryfa) mimo końca swojego terminu dalej jest naliczane. Chodzi tutaj o przypadek, gdy umowy na czas określony przechodzą na czas nieokreślony.
Bez sensu... Jeśli chcesz coś takiego dodaj taryfę rozpoczynającą się dzień zaraz po "todate" tej poprzejnmiej ale już bez opcji "todate"
W dniu 16.03.2012 10:50, Daniel Kulesza napisał(a):
Dlaczego nie w helpdesku?
Z założenia heldesk u mnie służy do obsługi serwisowej (przez serwisantów) i kontaktów z klientami.
W informacjach klienta zapisujemy to co dzieje się w BOK np. Klient zobowiązał się do spłaty zadłużenia ratami, Klient zmienił taryfę (takie rzeczy to już z automatu powinny być logowane), Że należy coś tam wyjaśnić z klientem. Ogólnie chodzi o informacje, które ma widzieć pracownica przy przyjmowaniu wpłaty. Dla mnie idealne by było (dodaj wpis, edytuj, usuń) do tego data dodania i nazwa użytkownika. Wyświetlanie kilku wpisów, a reszta po kliknięciu np. historia wpisów.
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Możliwe, że do tego nadałaby się opcja przy zobowiązaniu typu "wyłącz z grupowania na faktrze". Chyba, że chodzi nie tylko o wyłączenie z grupowania zobowiązań w jednej fakturze, ale o dowolne grupowanie zobowiązań?
Jeżeli będzie to konfigurowalne dla każdego klienta osobno to wtedy może być samo wyłączenie.
No raczej byłoby to ustawiane per zobowiązanie, a nie per klient, bo to zobowiązanie miałoby być wyłączone z grupowania. Ta opcja mogłaby się również nazywać: "obciążaj indywidualnie". Nie wiem jaka nazwa najlepiej określałaby o co chodzi.
- Informacje o kończących się umowach
Tu zapewne będzie przydatny skrypt, albo opcja w jednym z istniejących skryptów. Kończące się umowy rozpoznajesz na podstawie daty końca obowiązywania zobowiązania?
Tak. Tylko jest jeden problem (może jest taka opcja a nie znalazłem), chciałbym, aby była możliwość ustawienia w opcjach, że zobowiązanie(taryfa) mimo końca swojego terminu dalej jest naliczane. Chodzi tutaj o przypadek, gdy umowy na czas określony przechodzą na czas nieokreślony.
Do tego co piszesz warto rozważyć użycie schematów promocyjnych, a nie wystawiania obciążeń mimo przekroczenia terminu obowiązywania zobowiązania!
Bez sensu... Jeśli chcesz coś takiego dodaj taryfę rozpoczynającą się dzień zaraz po "todate" tej poprzejnmiej ale już bez opcji "todate"
W sumie mogę to tak stosować, muszę tylko zmodyfikować zapytanie pobierające prędkość, żeby nie uwzględniało nieaktywnej taryfy.
Tylko jeszcze pytanko, czy w liście taryf uwzględniane są nieaktywne taryfy czy nie ?
On 16.03.2012 11:08, Tomasz Chiliński wrote:
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Możliwe, że do tego nadałaby się opcja przy zobowiązaniu typu "wyłącz z grupowania na faktrze". Chyba, że chodzi nie tylko o wyłączenie z grupowania zobowiązań w jednej fakturze, ale o dowolne grupowanie zobowiązań?
Jeżeli będzie to konfigurowalne dla każdego klienta osobno to wtedy może być samo wyłączenie.
No raczej byłoby to ustawiane per zobowiązanie, a nie per klient, bo to zobowiązanie miałoby być wyłączone z grupowania. Ta opcja mogłaby się również nazywać: "obciążaj indywidualnie". Nie wiem jaka nazwa najlepiej określałaby o co chodzi.
W sumie pewnie na większość przypadków wystarczy, ale potrafię sobie wyobrazić klienta z czterema taryfami, gdzie powinny zostać wystawione dwie faktury, na każdej dwie taryfy.
Można to rozwiązać poprzez jakiś dodatkowy identyfikator działający w obrębie jednego klienta, gdzie - zobowiązania bez identyfikatora są traktowane jakby identyfikatorem było np. "0" (czyli identyfikator jest opcjonalny) - zobowiązania z tym samym identyfikatorem idą na tą samą fakturę,
W dniu 16.03.2012 11:05, Waldemar Dymkiewicz napisał(a):
W informacjach klienta zapisujemy to co dzieje się w BOK np. Klient zobowiązał się do spłaty zadłużenia ratami, Klient zmienił taryfę (takie rzeczy to już z automatu powinny być logowane), Że należy coś tam wyjaśnić z klientem. Ogólnie chodzi o informacje, które ma widzieć pracownica przy przyjmowaniu wpłaty. Dla mnie idealne by było (dodaj wpis, edytuj, usuń) do tego data dodania i nazwa użytkownika. Wyświetlanie kilku wpisów, a reszta po kliknięciu np. historia wpisów.
Trzeba rozgraniczyć dwie osobne sprawy. Historie zmian w kliencie, a informacje o kliencie od obslugi
Jeśli chodzi o historie zmian to jest jak najbardziej za aby to gdzieś przetrzymywać bo w tej chwili jedyna opcja to zaciągniecie backupu z danego dnia. Oczywiści zapisujemy tylko to co laduje w bazie w czasie backupu. Historia zmian z UI badz z trigerów trzymała by pełny obraz modyfikacji.
Informacje dla obsługi, w zasadzie już są (informacje) ale czy zmodyfikować je do formy poszczególnych wpisów z datownikiem to pozostawiam do osobnej dyskusji.
Możliwe, że do tego nadałaby się opcja przy zobowiązaniu typu "wyłącz z grupowania na faktrze". Chyba, że chodzi nie tylko o wyłączenie z grupowania zobowiązań w jednej fakturze, ale o dowolne grupowanie zobowiązań?
Jeżeli będzie to konfigurowalne dla każdego klienta osobno to wtedy może być samo wyłączenie.
Mój pomysł na... w taryfie (assignments) dodać pole groupinvoice::smallint z domyślna wartością 0 bądź 1 (nie ma znaczenia w założeniu). I teraz grupować będzie taryfy na FV zgodnie z ich nr grupy. Mam nadzieje ze to dość jasne.
Waldku, a może masz już gotowy zarys czegoś takiego? To byłby bardzo fajny feature...
W dniu 16 marca 2012 10:26 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
- dodawanie informacji do klienta w formie wpisów (data godzina, kto
dokonał wpisu), tak żeby mieć historię kontaktów z klientem ( chodzi mi o okienko informacje)
to jest bardzo wskazane. obecnie jest tylko kto ostatnio modyfikował, ale nie co.
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
jeśli w opcji to ok, a IMHO nie widzę takiej potrzeby.
- Normalne prawa dostępu, obecnie jest to źle rozwiązane i nie można
ustawić np. żeby serwisanci widzieli klienta, mogli edytować jego komputery, widzieli że jest zadłużony (kwota łączna), ale nie mieli widoku na dokumenty finansowe, żeby nie widzieli na liście klientów ile łącznie kasy jest. Tak samo w taryfach, żeby nie widzieli jaki łącznie przychód.
tak, bo teraz z tymi prawami to jakiś dziwny myk jest. nie wszsytko jest tak, jakby intuicja wskazywała.
- Informacje o kończących się umowach
to bardzo wskazane. najlepiej wrzucać do terminarza. ale to chyba musiałby robić jakiś skrypt. do tego dorzuciłbym dodatkowe pole w urzytkowniku mówiące o dacie zakończenia umowy.
- Poprawienie ergonomii systemu. Tutaj dużo by pisać. LMS niestety
nie jest intuicyjnym systemem i wymagał by sporych modyfikacji w interfejsie użytkowania. Nie wiem tylko czy takie coś jest w ogóle możliwe ?
IMHO, nie widzę potrzeby. u mnie lms w bieżącym kodzie śmiga. jedynie ta ilość zwracanych rekordów dla listy faktur i rejestru operacji :)
- Integracja obsługi platformy VoIP jednej z firm z którą jestem w
kontakcie. W chwili obecnej są dostępne patche tylko do wersji 1.11.x, więc troszkę roboty z portowaniem na pewno będzie, a jeszcze więcej z i18n oraz dostosowaniem do baz obsługiwanych przez LMSDB. Zobaczymy jak i czy uda się to zrobić.
hmm, a z jaką firmą współpraca idzie? bo my współpracujemy z ADESCOM, co prawda sporo kodu zrobili do 1.11, ale zrobili to u siebie i teraz jakakolwiek zmiana u mnie, to update ich kodu :/ masakra
do listy życzeń dodałbym informacje o usuwanych/zmienianych komputerach. że dany ip należał kiedyś do kowalskiego.
W dniu 16.03.2012 11:17, A.L.E.C napisał(a):
On 16.03.2012 11:08, Tomasz Chiliński wrote:
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Możliwe, że do tego nadałaby się opcja przy zobowiązaniu typu "wyłącz z grupowania na faktrze". Chyba, że chodzi nie tylko o wyłączenie z grupowania zobowiązań w jednej fakturze, ale o dowolne grupowanie zobowiązań?
Jeżeli będzie to konfigurowalne dla każdego klienta osobno to wtedy może być samo wyłączenie.
No raczej byłoby to ustawiane per zobowiązanie, a nie per klient, bo to zobowiązanie miałoby być wyłączone z grupowania. Ta opcja mogłaby się również nazywać: "obciążaj indywidualnie". Nie wiem jaka nazwa najlepiej określałaby o co chodzi.
W sumie pewnie na większość przypadków wystarczy, ale potrafię sobie wyobrazić klienta z czterema taryfami, gdzie powinny zostać wystawione dwie faktury, na każdej dwie taryfy.
Można to rozwiązać poprzez jakiś dodatkowy identyfikator działający w obrębie jednego klienta, gdzie
- zobowiązania bez identyfikatora są traktowane jakby identyfikatorem
było np. "0" (czyli identyfikator jest opcjonalny)
- zobowiązania z tym samym identyfikatorem idą na tą samą fakturę,
Po prostu takie etykietki używane podczas generowania faktur, ale warto od razu tak to "ubrać" w UI, żeby było a miarę czytelne. Przecież nie będziemy wymagać od użytkownika LMS, żeby wpisywał liczbę w polu edycyjnym czy ustawiał ją z listy wyboru ;-)
W dniu 16.03.2012 11:18, Marcin napisał(a):
- Integracja obsługi platformy VoIP jednej z firm z którą
jestem w kontakcie. W chwili obecnej są dostępne patche tylko do wersji 1.11.x, więc troszkę roboty z portow
o będzie, a jeszcze więcej z i18n oraz dostosowaniem do baz obsługiwanych przez LMSDB. Zobaczymy jak i czy uda się to zrobić.
hmm, a z jaką firmą współpraca idzie? bo my współpracujemy z ADESCOM, co prawda sporo kodu zrobili do 1.11, ale zrobili to u siebie i teraz jakakolwiek zmiana u mnie, to update ich kodu :/ masakra
Nettelekom.
-- Pozdrawiam Marcin / nicraM
no to teraz ja daje swoja liste marzen 1. sensowne prawa dostepu to mowia wszyscy !!! 2. pole interfejsc w urządzeniach sieciowych 3. podłacz nowe urzadzenie (utworzenie nowego urzadzenia i automatyczne podłaczenie do okreslonego 4. blokowanie by klient nie widzial w zgloszeniach helpdesku wpisow innych niz wyznaczona kolejka serwisanci we wszystkich firmach jakie znam pisza tam czesto informacje o stanie psychicnym klientow jego inteligencji czy tez zapachu w domu klienci nie musza tego czytac 5. modul magazynowy 6 logowanie operacji i zmian zarowno w taryfach jak i komputerach 7 obsluga grup klientow w skryptach perlowych generujacych kolekji tc to na poczatek tyle najistotniejszych brakow
On 16.03.2012 11:21, Tomasz Chiliński wrote:
Po prostu takie etykietki używane podczas generowania faktur, ale warto od razu tak to "ubrać" w UI, żeby było a miarę czytelne. Przecież nie będziemy wymagać od użytkownika LMS, żeby wpisywał liczbę w polu edycyjnym czy ustawiał ją z listy wyboru ;-)
A propos czytelności, proszę o dokumentację odnośnie blokad zobowiązań. Nie kumam do tego to ma służyć.
przydało by się również w gicie poprawić skypt lms-sendinvoices, powinien uwzględnić zgodę klienta na wysyłanie faktury na maila. defaultowo tego nie robi i śle do każdego z mailem.
moja poprawka: około linii 225 #v+ $dbq = $dbase->prepare("SELECT d.id, d.number, d.cdate, c.email, d.name, d.customerid, n.template FROM documents d LEFT JOIN customers c ON (c.id = d.customerid) LEFT JOIN numberplans n ON (n.id = d.numberplanid) $groupjoin WHERE c.deleted = 0 AND d.type = 1 AND c.email != '' AND d.cdate >= $daystart AND d.cdate <= $dayend AND c.invoicenotice = '1' $groupwhere");
#v+
On 16.03.2012 11:18, Marcin wrote:
W dniu 16 marca 2012 10:26 użytkownik Tomasz Chiliński <tomasz.chilinski@chilan.com mailto:tomasz.chilinski@chilan.com> napisał:
1. dodawanie informacji do klienta w formie wpisów (data godzina, kto dokonał wpisu), tak żeby mieć historię kontaktów z klientem ( chodzi mi o okienko informacje)to jest bardzo wskazane. obecnie jest tylko kto ostatnio modyfikował, ale nie co.
2. Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)jeśli w opcji to ok, a IMHO nie widzę takiej potrzeby.
3. Normalne prawa dostępu, obecnie jest to źle rozwiązane i nie można ustawić np. żeby serwisanci widzieli klienta, mogli edytować jego komputery, widzieli że jest zadłużony (kwota łączna), ale nie mieli widoku na dokumenty finansowe, żeby nie widzieli na liście klientów ile łącznie kasy jest. Tak samo w taryfach, żeby nie widzieli jaki łącznie przychód.tak, bo teraz z tymi prawami to jakiś dziwny myk jest. nie wszsytko jest tak, jakby intuicja wskazywała.
4. Informacje o kończących się umowachto bardzo wskazane. najlepiej wrzucać do terminarza. ale to chyba musiałby robić jakiś skrypt. do tego dorzuciłbym dodatkowe pole w urzytkowniku mówiące o dacie zakończenia umowy.
5. Poprawienie ergonomii systemu. Tutaj dużo by pisać. LMS niestety nie jest intuicyjnym systemem i wymagał by sporych modyfikacji w interfejsie użytkowania. Nie wiem tylko czy takie coś jest w ogóle możliwe ?IMHO, nie widzę potrzeby. u mnie lms w bieżącym kodzie śmiga. jedynie ta ilość zwracanych rekordów dla listy faktur i rejestru operacji :)
2) Integracja obsługi platformy VoIP jednej z firm z którą jestem w kontakcie. W chwili obecnej są dostępne patche tylko do wersji 1.11.x, więc troszkę roboty z portowaniem na pewno będzie, a jeszcze więcej z i18n oraz dostosowaniem do baz obsługiwanych przez LMSDB. Zobaczymy jak i czy uda się to zrobić.hmm, a z jaką firmą współpraca idzie? bo my współpracujemy z ADESCOM, co prawda sporo kodu zrobili do 1.11, ale zrobili to u siebie i teraz jakakolwiek zmiana u mnie, to update ich kodu :/ masakra
Co do ADESCOMU to bardzo możliwe, że niedługo w LMS pojawi się wsparcie do ich systemu, na razie rozmowy trwają :)
W dniu 16 marca 2012 12:20 użytkownik Grzegorz Chwesewicz < grzegorz.chwesewicz@retis.net.pl> napisał:
Co do ADESCOMU to bardzo możliwe, że niedługo w LMS pojawi się wsparcie do ich systemu, na razie rozmowy trwają :)
hmm, to zaraz z nimi pogadam i spróbuję "przyśpieszyć' sprawę
W dniu 16.03.2012 11:28, A.L.E.C napisał(a):
On 16.03.2012 11:21, Tomasz Chiliński wrote:
Po prostu takie etykietki używane podczas generowania faktur, ale warto od razu tak to "ubrać" w UI, żeby było a miarę czytelne. Przecież nie będziemy wymagać od użytkownika LMS, żeby wpisywał liczbę w polu edycyjnym czy ustawiał ją z listy wyboru ;-)
A propos czytelności, proszę o dokumentację odnośnie blokad zobowiązań. Nie kumam do tego to ma służyć.
Ależ proszę bardzo: kontrola rodzicielska. Oczywiście to tylko interfejs użytkownika, więc ciężko wymagać, żeby coś robiło same z siebie.
W dniu 16 marca 2012 01:20 użytkownik Przemysław Kudyba < przemekk@zwierzu.zepsul.net> napisał:
Witam.
Nigdy jakoś specjalnie nie lubiłem LMS-a, ale muszę obiektywnie przyznać, ze w tym roku uratował mi dojpę ;) Oczywiście do spólki z dużą ilością kung-fu i rękodzieła, ale siis za 2011 został odpykany ;)
Dzięki.
PS, teraz juz tylko winko i relaks ..
I po piwie dla deweloperów! Howgh!
On Fri, Mar 16, 2012 at 09:58:07AM +0100, Daniel Kulesza wrote:
Witam
Widzę, że ostatnio rozwój LMS przyspieszył. Przesyłam więc poniżej listę propozycji do wprowadzenia
[..]
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym samym
dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Myślałem o takim rozwiązaniu: Taryfa - powiązana z linią numeracyjną, w ten sposób jeżeli jest kilka zobowiązań z jednej "grupy" usług są na jednej fakturze, Dodatkowo można zrobić potem saldo per-grupa. Nie mówię że jest to najlepsze rozwiązanie, ale takie u siebie zrobiłem i się sprawdza ;-)
- Normalne prawa dostępu, obecnie jest to źle rozwiązane i nie można
ustawić np. żeby serwisanci widzieli klienta, mogli edytować jego komputery, widzieli że jest zadłużony (kwota łączna), ale nie mieli widoku na dokumenty finansowe, żeby nie widzieli na liście klientów ile łącznie kasy jest. Tak samo w taryfach, żeby nie widzieli jaki łącznie przychód.
Większość z tego już jest w wersji git.
Sprawdzę dzisiaj :)
Sprawdzałem to i działa lepiej niż kiedyś, ale nadal to nie to co powinno być. np. - nadal serwisant widzi na liście klientów wysokość ich zobowiązań i ile jest zaległości (tak samo widzi to w informacjach) - zablokowanie dostępu do listy taryf jest błędnym założeniem, serwisant powinien je widzieć, ale bez danych finansowych - po "wejściu na klienta" Konto klienta: (ostatnie 10 transakcji) nie ma co prawda dostępu do faktur, ale widać je na liście i kwoty. W ogóle lista powinna być zmodyfikowana tak, żeby było widać w niej zamiast pozycji z faktur same faktury (przy kilku pozycjach jest nieczytelna),
to tak na szybko
W dniu 16.03.2012 13:56, Marcin Król napisał(a):
W dniu 16 marca 2012 01:20 użytkownik Przemysław Kudyba <przemekk@zwierzu.zepsul.net [1]> napisał:
Witam.
Nigdy jakoś specjalnie nie lubiłem LMS-a, ale muszę obiektywnie przyznać, ze w tym roku uratował mi dojpę ;) Oczywiście do spólki z dużą ilością kung-fu i rękodzieła, ale siis za 2011 został odpykany ;)
Dzięki.
PS, teraz juz tylko winko i relaks ..
I po piwie dla deweloperów! Howgh!
O Marcinie to Ty żyw i zdrów ;-)
W dniu 16.03.2012 15:07, Przemysław 'Repcio' Gubernat napisał(a):
On Fri, Mar 16, 2012 at 09:58:07AM +0100, Daniel Kulesza wrote:
Witam
Widzę, że ostatnio rozwój LMS przyspieszył. Przesyłam więc poniżej listę propozycji do wprowadzenia
[..]
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym
samym dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Myślałem o takim rozwiązaniu: Taryfa - powiązana z linią numeracyjną, w ten sposób jeżeli jest kilka zobowiązań z jednej "grupy" usług są na jednej fakturze, Dodatkowo można zrobić potem saldo per-grupa. Nie mówię że jest to najlepsze rozwiązanie, ale takie u siebie zrobiłem i się sprawdza ;-)
Nie wiem czy to nie byłoby wystarczające...
+-=-=- Przemysław Gubernat repcio@repcio.net -=-=-=-=-=-=-+ | _API Internet_ A. Stolarczyk i P. Gubernat Spółka Jawna | | System Administrator @ Repcio.NET | | Jestem twoim ostatecznym rozwiązaniem ! | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
On 03/16/2012 03:59 PM, Tomasz Chiliński wrote:
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym samym
dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Myślałem o takim rozwiązaniu: Taryfa - powiązana z linią numeracyjną, w ten sposób jeżeli jest kilka zobowiązań z jednej "grupy" usług są na jednej fakturze, Dodatkowo można zrobić potem saldo per-grupa. Nie mówię że jest to najlepsze rozwiązanie, ale takie u siebie zrobiłem i się sprawdza ;-)
Nie wiem czy to nie byłoby wystarczające...
Plan numeracyjny można przypisać do zobowiązania już teraz, więc zakładam, że nie o to chodzi. Potrzebujemy możliwość grupowania w jednej linii numeracyjnej.
W dniu 2012-03-16 15:59, Tomasz Chiliński pisze:
W dniu 16.03.2012 15:07, Przemysław 'Repcio' Gubernat napisał(a):
On Fri, Mar 16, 2012 at 09:58:07AM +0100, Daniel Kulesza wrote:
Witam
Widzę, że ostatnio rozwój LMS przyspieszył. Przesyłam więc poniżej listę propozycji do wprowadzenia
[..]
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym samym
dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Myślałem o takim rozwiązaniu: Taryfa - powiązana z linią numeracyjną, w ten sposób jeżeli jest kilka zobowiązań z jednej "grupy" usług są na jednej fakturze, Dodatkowo można zrobić potem saldo per-grupa. Nie mówię że jest to najlepsze rozwiązanie, ale takie u siebie zrobiłem i się sprawdza ;-)
Nie wiem czy to nie byłoby wystarczające...
Jestem w trakcie przepisywania swojego rozwiązania do nowego LMS'a. Muszę robić GUI do zarządzania grupami z UI, gdyż aktualnie robiłem to ręcznie w bazie ;-)
W dniu 2012-03-16 17:46, A.L.E.C pisze:
On 03/16/2012 03:59 PM, Tomasz Chiliński wrote:
- Jedno zobowiązanie 1 Faktura. Mam np. 2 usługi naliczane w tym samym
dniu i chciałbym, żeby były na osobnych fakturach (obecnie są to 2 pozycje na 1 FV, oczywiście było by to jako opcja)
Myślałem o takim rozwiązaniu: Taryfa - powiązana z linią numeracyjną, w ten sposób jeżeli jest kilka zobowiązań z jednej "grupy" usług są na jednej fakturze, Dodatkowo można zrobić potem saldo per-grupa. Nie mówię że jest to najlepsze rozwiązanie, ale takie u siebie zrobiłem i się sprawdza ;-)
Nie wiem czy to nie byłoby wystarczające...
Plan numeracyjny można przypisać do zobowiązania już teraz, więc zakładam, że nie o to chodzi. Potrzebujemy możliwość grupowania w jednej linii numeracyjnej.
Z tego co widzę przy dodawaniu taryfy możesz wybrać typ usługi (internet/hosting/itp), natomiast definiując plan numeracyjny nie jest on w żaden sposób powiązany z typem usługi. Grupa/typ usług powinna być do przypisania dla wszystkich finansowych planów numeracyjnych (faktura, dokument kasowy, nota obciążeniowa, faktura korekta). Nie wiem czy inny też to stosują u siebie kaucje. Kaucja sama z siebie nie powinna być wliczana do salda klienta i z tego powodu powinna być wyłączona z sumowania, jednakże jako grupa powinna widnieć na koncie klienta.
W dniu 2012-03-16 11:14, Daniel Kulesza pisze:
Bez sensu... Jeśli chcesz coś takiego dodaj taryfę rozpoczynającą się dzień zaraz po "todate" tej poprzejnmiej ale już bez opcji "todate"
W sumie mogę to tak stosować, muszę tylko zmodyfikować zapytanie pobierające prędkość, żeby nie uwzględniało nieaktywnej taryfy.
Tylko jeszcze pytanko, czy w liście taryf uwzględniane są nieaktywne taryfy czy nie ?
Ja genruje przez daemona i tam nie bierze pd uwage. Zainteresuj sie promocjami. Tam ladnie dodaje taryfy w trakcie i po umowie promocyjnej + zobowiazania jednorazowe.
pozdrawiam
W dniu 2012-03-16 10:26, Tomasz Chiliński pisze:
Widzę, że ostatnio rozwój LMS przyspieszył.
Ja juz nic nie mowie - nie czytalem listy kilka dni i 300 nowych postow :( Moze uda sie wkoncu to o czym glosno nie rozmawiamy - stala wspolpraca z 2-3 developerami i ich stale finansowanie.
Zapomniałem dodać, że teraz "na radarze" mamy:
- Przejście z lokalizacjami klientów na obsługę TERYT (nadal musi zostać
możliwość wpisywania dowolnych adresów). Tu zmiany zaczniemy od rozbicia pola address i post_address na *_street, *_house, *_flat. Będziemy wymagana aktualizacja schematu bazy danych, która przy okazji spróbuje automatycznie rozbić pola adresu na poszczególne części. Trochę doświadczeń związanych z lms-teryt już jest, więc na pewno będzie łatwiej, ale dobrze byłoby, żeby pojawiło się więcej uwag odnośnie rozbijania adresu na części.
Ja do powyzszego moge tylko napisac, ze obserwujac komercyjny projekt/system pewnej kablowki tam idealnie sprawdza sie trzymanie w bazie wszystkich lokalizacji, w ktorych mamy zasieg. A wiec miasto/ulica/numer_bloku/numer_mieszkania. I na listach wyboru wlasnie te wszystkie pozycje sa wybieralne. Wbrew pozorom nie dodaje to wcale wiecej pracy (wyklikiwanie), ale za to minimalizuje do zera ryzyko pomylek itp. Oczywiscie obok listy wyboru jest formularzyk dodawania nowej lokalizacji do bazy. Tak wiec w praktyce trzymamy tylko pelne HP klientow (konkretne punkty w ktorych mamy swoje gniazdka). Powyzszy oczywiscie tyczy sie lokalizacji komputerow/urzadzen. Choc przy klientach jest podobnie z tym ze adresy korespondencyjne sa wpisywane recznie, a lokalizacje na umowie (z dowodu) sa niby wybieralne, ale mozna je recznie nadpisywac (nowe nie zapisuja sie juz w bazie). Moze wiec warto w tym kierunku pojsc przy uewnetualnych zmianach w lokalizacjach komputerow. Bo z klientami nie ma co za duzo dumac. Rozbic na poszczegolne pola i trzymac zgodnie z terytem lub bez terytu. W komputerach moim zdaniem powinien pojawic sie juz tylko teryt i to tylko te pola w ktorych mamy zasieg.
pozdrawiam
uczestnicy (12)
-
A.L.E.C -
Andrzej Banach -
Daniel Kulesza -
Grzegorz Chwesewicz -
jlc＠tlen.pl -
Marcin -
Marcin Król -
Przemysław 'Repcio' Gubernat -
Przemysław Gubernat -
Przemysław Kudyba -
Tomasz Chiliński -
Waldemar Dymkiewicz