Pole e-mail na koncie klienta
Witam,
szykuję się, żeby dodać możliwość dodawania kilku kont e-mail, na podobnej zasadzie co z telefonami. Najłatwiej byłoby użyć do tego kolumny customercontacts. Na zasadzie, że:
type = 4 to będzie po prostu e-mail, type = 5 e-mail na który mają/nie mają być wysyłane faktury elektroniczne.
Mile widziane propozycje i uwagi. Od jutra zaczynam prace nad tym.
© 2011
W dniu 11.04.2012 13:18, Skiba Marek napisał(a):
Witam,
Witam.
szykuję się, żeby dodać możliwość dodawania kilku kont e-mail, na podobnej zasadzie co z telefonami. Najłatwiej byłoby użyć do tego kolumny customercontacts. Na zasadzie, że:
type = 4 to będzie po prostu e-mail, type = 5 e-mail na który mają/nie mają być wysyłane faktury elektroniczne.
To jest dobry pomysł! Może po prostu flaga określająca czy to główny mail czy dodatkowy, a jeśli klient wyraził zgodę na otrzymywania faktur drogą elektroniczną to faktury będą wysyłane na mail główny?
Mile widziane propozycje i uwagi. Od jutra zaczynam prace nad tym.
On 11.04.2012 14:18, Skiba Marek wrote:
szykuję się, żeby dodać możliwość dodawania kilku kont e-mail, na podobnej zasadzie co z telefonami. Najłatwiej byłoby użyć do tego kolumny customercontacts. Na zasadzie, że:
type = 4 to będzie po prostu e-mail, type = 5 e-mail na który mają/nie mają być wysyłane faktury elektroniczne.
Type to suma, więc jeśli już to 4, 8, 16, itd.
Wypada dodać kolumnę email. Natomiast jeśli chodzi o UI to widziałbym to ładnie rozbudowane na podobieństwo boksów Komputery klienta, Grupy klienta, etc.
W dniu 11.04.2012 13:34, A.L.E.C napisał(a):
On 11.04.2012 14:18, Skiba Marek wrote:
szykuję się, żeby dodać możliwość dodawania kilku kont e-mail, na podobnej zasadzie co z telefonami. Najłatwiej byłoby użyć do tego kolumny customercontacts. Na zasadzie, że:
type = 4 to będzie po prostu e-mail, type = 5 e-mail na który mają/nie mają być wysyłane faktury elektroniczne.
Type to suma, więc jeśli już to 4, 8, 16, itd.
Wypada dodać kolumnę email. Natomiast jeśli chodzi o UI to widziałbym to ładnie rozbudowane na podobieństwo boksów Komputery klienta, Grupy klienta, etc.
Po co nowa kolumna? Lepiej zmienić nazwę pola phone na powiedzmy content, a type określa nam rodzaj kontaktu.
Jeśli chodzi o UI to przerzucanie wszystkiego do grupy boksów wcale nie jest idealne. Często daje to efekt odwrotny zmniejszając spójność i czytelność interfejsu. Alku, jakoś nie jestem przekonany, że kontakty powinny być w oddzielnym boksie, ale jeśli już to wspólnymi siłami zrobimy nowy box kontaktów w oparciu o xajax.
On 11.04.2012 14:52, Tomasz Chiliński wrote:
Wypada dodać kolumnę email. Natomiast jeśli chodzi o UI to widziałbym to ładnie rozbudowane na podobieństwo boksów Komputery klienta, Grupy klienta, etc.
Po co nowa kolumna? Lepiej zmienić nazwę pola phone na powiedzmy content, a type określa nam rodzaj kontaktu.
Jeśli chodzi o UI to przerzucanie wszystkiego do grupy boksów wcale nie jest idealne. Często daje to efekt odwrotny zmniejszając spójność i czytelność interfejsu. Alku, jakoś nie jestem przekonany, że kontakty powinny być w oddzielnym boksie, ale jeśli już to wspólnymi siłami zrobimy nowy box kontaktów w oparciu o xajax.
A gdybyśmy do kontaktów przenieśli także komunikatory, to nam się to bardziej rozbudowuje i wtedy osobny box ma większy sens. Dodatkowo gdy spojrzymy na kontakty jak na osoby (co ma zwłaszcza sens w przypadku firm) to takie rozwiązanie wygląda wręcz na jedyne sensowne. Także w przypadku osób prywatnych ma to sens, bo możemy sobie napisać do kogo należy dany telefon, czy mail i wtedy nie tworzymy x rekordów (nie chodzi mi tu tyle o bazę co UI), tylko wszystkie dane mogą być przypisane do jednego kontaktu.
On 12.04.2012 08:27, A.L.E.C wrote:
Także w przypadku osób prywatnych ma to sens, bo możemy sobie napisać do kogo należy dany telefon, czy mail
W sensie domowników klienta, Np. ktoś jest naszym klientem, ale w zasadzie wszystkie kontakty odbywają się przez syna klienta itp.
W dniu 12.04.2012 07:27, A.L.E.C napisał(a):
On 11.04.2012 14:52, Tomasz Chiliński wrote:
Wypada dodać kolumnę email. Natomiast jeśli chodzi o UI to widziałbym to ładnie rozbudowane na podobieństwo boksów Komputery klienta, Grupy klienta, etc.
Po co nowa kolumna? Lepiej zmienić nazwę pola phone na powiedzmy content, a type określa nam rodzaj kontaktu.
Jeśli chodzi o UI to przerzucanie wszystkiego do grupy boksów wcale nie jest idealne. Często daje to efekt odwrotny zmniejszając spójność i czytelność interfejsu. Alku, jakoś nie jestem przekonany, że kontakty powinny być w oddzielnym boksie, ale jeśli już to wspólnymi siłami zrobimy nowy box kontaktów w oparciu o xajax.
A gdybyśmy do kontaktów przenieśli także komunikatory, to nam się to bardziej rozbudowuje i wtedy osobny box ma większy sens. Dodatkowo gdy spojrzymy na kontakty jak na osoby (co ma zwłaszcza sens w przypadku firm) to takie rozwiązanie wygląda wręcz na jedyne sensowne. Także w przypadku osób prywatnych ma to sens, bo możemy sobie napisać do kogo należy dany telefon, czy mail i wtedy nie tworzymy x rekordów (nie chodzi mi tu tyle o bazę co UI), tylko wszystkie dane mogą być przypisane do jednego kontaktu.
Tak to faktycznie ma sens. Komunikatory już od dawna powinny być również trzymane jako kontakty. Gdy Pjona weźmie się za to na pewno pomogę jak będzie taka potrzeba.
W dniu 12.04.2012 07:27, A.L.E.C napisał(a):
A gdybyśmy do kontaktów przenieśli także komunikatory, to nam się to bardziej rozbudowuje i wtedy osobny box ma większy sens. Dodatkowo gdy spojrzymy na kontakty jak na osoby (co ma zwłaszcza sens w przypadku firm) to takie rozwiązanie wygląda wręcz na jedyne sensowne. Także w przypadku osób prywatnych ma to sens, bo możemy sobie napisać do kogo należy dany telefon, czy mail i wtedy nie tworzymy x rekordów (nie chodzi mi tu tyle o bazę co UI), tylko wszystkie dane mogą być przypisane do jednego kontaktu.
Hm... czyli robimy osobny box 'Kontakty', gdzie będzie możliwość dodania nowego kontaktu, i teraz przy dodawaniu kontaktu, najpierw zaznaczamy do kogo należy kontakt, np wpiszemy 'Syn właściciela', i dopiero do tej osoby przypisujemy kontakty, typu GG, e-maile itd, dobrze zrozumiałem?
© 2012
On 12.04.2012 10:47, Skiba Marek wrote:
Hm... czyli robimy osobny box 'Kontakty', gdzie będzie możliwość dodania nowego kontaktu, i teraz przy dodawaniu kontaktu, najpierw zaznaczamy do kogo należy kontakt, np wpiszemy 'Syn właściciela',
Tak, kolumna customercontacts.name
dopiero do tej osoby przypisujemy kontakty, typu GG, e-maile itd, dobrze zrozumiałem?
tak, oprócz komunikatorów i maila, ja bym jeszcze dodał pole opis na dodatkowe uwagi.
W dniu 12.04.2012 09:56, A.L.E.C napisał(a):
On 12.04.2012 10:47, Skiba Marek wrote:
Hm... czyli robimy osobny box 'Kontakty', gdzie będzie możliwość dodania nowego kontaktu, i teraz przy dodawaniu kontaktu, najpierw zaznaczamy do kogo należy kontakt, np wpiszemy 'Syn właściciela',
Tak, kolumna customercontacts.name
dopiero do tej osoby przypisujemy kontakty, typu GG, e-maile itd, dobrze zrozumiałem?
tak, oprócz komunikatorów i maila, ja bym jeszcze dodał pole opis na dodatkowe uwagi.
A ja bym name zamienił na comment i będzie można tam wpisać do kogo należy kontakt jak i inne rzeczy. Pole type będzie mapą bitową na której będą kodowane typy kontaktu. Pole phone zmieni nazwę na np. contact, albo data.
On 12.04.2012 11:13, Tomasz Chiliński wrote:
A ja bym name zamienił na comment i będzie można tam wpisać do kogo należy kontakt jak i inne rzeczy. Pole type będzie mapą bitową na której będą kodowane typy kontaktu. Pole phone zmieni nazwę na np. contact, albo data.
potrzebujemy osobno telefon, mail i komunikatory. Nie ma sensu tworzyć wielu rekordów jeśli faktycznym kontaktem jest jedna osoba. No chyba że idziemy jeszcze dalej z normalizacją i telefony, maile, komunikatory, wszystko wywalamy do osobnej tabeli (customercontactdata), a w customercontacts zostają tylko dane osoby-kontaktu (imie/nazwisko, opis, typ np. reprezentant) i do osoby-kontaktu doczepiamy dowolną ilość z customercontactdata.
W dniu 12.04.2012 10:26, A.L.E.C napisał(a):
On 12.04.2012 11:13, Tomasz Chiliński wrote:
A ja bym name zamienił na comment i będzie można tam wpisać do kogo należy kontakt jak i inne rzeczy. Pole type będzie mapą bitową na której będą kodowane typy kontaktu. Pole phone zmieni nazwę na np. contact, albo data.
potrzebujemy osobno telefon, mail i komunikatory. Nie ma sensu tworzyć wielu rekordów jeśli faktycznym kontaktem jest jedna osoba. No chyba że idziemy jeszcze dalej z normalizacją i telefony, maile, komunikatory, wszystko wywalamy do osobnej tabeli (customercontactdata), a w customercontacts zostają tylko dane osoby-kontaktu (imie/nazwisko, opis, typ np. reprezentant) i do osoby-kontaktu doczepiamy dowolną ilość z customercontactdata.
Ja to widzę jako tabelę customercontacts postaci: id integer customerid integer REFERENCES customers (id) ON DELETE CASCADE ON UPDATE CASCADE, data varchar(255) comment varchar(255) type smallint
Nie widzę na razie powodu, żeby to bardziej komplikować. Jeśli kontaktem jest sam klient to nie będzie miał wtedy dopisanego żadnego kontaktu typu "reprezentant".
W dniu 12 kwietnia 2012 11:26 użytkownik A.L.E.C alec@alec.pl napisał:
No chyba że idziemy jeszcze dalej z normalizacją i telefony, maile, komunikatory, wszystko wywalamy do osobnej tabeli (customercontactdata), a w customercontacts zostają tylko dane osoby-kontaktu (imie/nazwisko, opis, typ np. reprezentant) i do osoby-kontaktu doczepiamy dowolną ilość z customercontactdata.
Tak byłoby chyba najporządniej zrobione. Najwięcej roboty też niby, ale myślę że warto.
Konkretnie:
customercontacts: id integer, customerid integer, REFERENCES customers (id) ON DELETE CASCADE ON UPDATE CASCADE, name varchar(255), -- imie nazwisko comment varchar(255), -- opis, krótka notatka o kontakcie type smallint -- 1 reprezentant, 0 nie reprezentant
customercontactdata: contactid integer REFERENCES customercontacts (id) ON DELETE CASCADE ON UPDATE CASCADE, value varchar(255), -- adres e-mail, numer telefonu zalezne od typu type smallint
Coś takiego? Przy takim schemacie będzie więcej klikania w samym UI, bo niby większość klientów to osoby prywatne gdzie zazwyczaj jest jeden/dwa telefony, jeden e-mail, ale przy większych firmach będzie można sobie ładniej poukładać dane.
W dniu 12.04.2012 11:30, Skiba Marek napisał(a):
W dniu 12 kwietnia 2012 11:26 użytkownik A.L.E.C alec@alec.pl napisał:
No chyba że idziemy jeszcze dalej z normalizacją i telefony, maile, komunikatory, wszystko wywalamy do osobnej tabeli (customercontactdata), a w customercontacts zostają tylko dane osoby-kontaktu (imie/nazwisko, opis, typ np. reprezentant) i do osoby-kontaktu doczepiamy dowolną ilość z customercontactdata.
Tak byłoby chyba najporządniej zrobione. Najwięcej roboty też niby, ale myślę że warto.
Konkretnie:
customercontacts: id integer, customerid integer, REFERENCES customers (id) ON DELETE CASCADE ON UPDATE CASCADE, name varchar(255), -- imie nazwisko comment varchar(255), -- opis, krótka notatka o kontakcie type smallint -- 1 reprezentant, 0 nie reprezentant
customercontactdata: contactid integer REFERENCES customercontacts (id) ON DELETE CASCADE ON UPDATE CASCADE, value varchar(255), -- adres e-mail, numer telefonu zalezne od typu type smallint
Coś takiego? Przy takim schemacie będzie więcej klikania w samym UI, bo niby większość klientów to osoby prywatne gdzie zazwyczaj jest jeden/dwa telefony, jeden e-mail, ale przy większych firmach będzie można sobie ładniej poukładać dane.
Jeśli chcemy mieć bardzo uniwersalnie to zapewne tak - wtedy od strony kontaktów mierzymy od razu w miniCRM ;-) Czy będzie więcej klikania - to zależy od tego czy wykorzystamy dobrze Javascript i Ajax. Wcale nie musi być tak dużo klikania wbrew pozorom.
W dniu 12 kwietnia 2012 12:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Jeśli chcemy mieć bardzo uniwersalnie to zapewne tak - wtedy od strony kontaktów mierzymy od razu w miniCRM ;-) Czy będzie więcej klikania - to zależy od tego czy wykorzystamy dobrze Javascript i Ajax. Wcale nie musi być tak dużo klikania wbrew pozorom.
Chodzi mi o sytuacje, że przy dodawaniu nowego klienta, wpisujesz: imię, nazwisko, ulica itd, zapisujesz, później musisz kliknąć dodaj kontakt, dodajesz informacje o kontakcie, zapisujesz. Trochę więcej klikania będzie, bo nie wszystko będzie dostępne na jeden podstronie.
W dniu 12 kwietnia 2012 12:51 użytkownik Jaroslaw Dziubek yaro@perfect.net.pl napisał:
Ja bym bardziej rozbudowal:
- reprezentant (osoba upoważniona do zaciągania zobowiązań)
- wysyłka faktur
- płatności
- sprawy handlowe (oferty, itp)
- sprawy techniczne
Yhym, bardzo dobry pomysł, jedynie "wysyłka faktur", bym wyciągnął z tego i przypisywał tą opcje do konkretnego e-maila, a nie samego kontaktu.
W dniu 12.04.2012 11:55, Skiba Marek napisał(a):
W dniu 12 kwietnia 2012 12:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Jeśli chcemy mieć bardzo uniwersalnie to zapewne tak - wtedy od strony kontaktów mierzymy od razu w miniCRM ;-) Czy będzie więcej klikania - to zależy od tego czy wykorzystamy dobrze Javascript i Ajax. Wcale nie musi być tak dużo klikania wbrew pozorom.
Chodzi mi o sytuacje, że przy dodawaniu nowego klienta, wpisujesz: imię, nazwisko, ulica itd, zapisujesz, później musisz kliknąć dodaj kontakt, dodajesz informacje o kontakcie, zapisujesz. Trochę więcej klikania będzie, bo nie wszystko będzie dostępne na jeden podstronie.
W tym przypadku będzie na pewno więcej o jeden etap, ale już przy edycji kontaktów będzie lepiej. Raczej częściej edytuje się kontakty niż wprowadza się na nowo klienta i dopisuje mu świeże dane kontaktowe.
On Thu, 12 Apr 2012 11:58:50 +0100, Tomasz Chiliński tomasz.chilinski@chilan.com wrote:
W dniu 12.04.2012 11:55, Skiba Marek napisał(a):
W dniu 12 kwietnia 2012 12:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Jeśli chcemy mieć bardzo uniwersalnie to zapewne tak - wtedy od strony kontaktów mierzymy od razu w miniCRM ;-) Czy będzie więcej klikania - to zależy od tego czy wykorzystamy dobrze Javascript i Ajax. Wcale nie musi być tak dużo klikania wbrew pozorom.
Chodzi mi o sytuacje, że przy dodawaniu nowego klienta, wpisujesz: imię, nazwisko, ulica itd, zapisujesz, później musisz kliknąć dodaj kontakt, dodajesz informacje o kontakcie, zapisujesz. Trochę więcej klikania będzie, bo nie wszystko będzie dostępne na jeden podstronie.
W tym przypadku będzie na pewno więcej o jeden etap, ale już przy edycji kontaktów będzie lepiej. Raczej częściej edytuje się kontakty niż wprowadza się na nowo klienta i dopisuje mu świeże dane kontaktowe.
Może warto by się wzorować na formacie vcard przy określaniu jakie pola itd w kontaktach. Potem łatwo będzie takie kontakty importować eksportować itd.
http://en.wikipedia.org/wiki/VCard
pozdrawiam
Dnia 12 kwietnia 2012 13:37 Dariusz Kowalczyk dariusz.kowalczyk@webvisor.pl napisał(a):
On Thu, 12 Apr 2012 11:58:50 +0100, Tomasz Chiliński tomasz.chilinski@chilan.com wrote:
W dniu 12.04.2012 11:55, Skiba Marek napisał(a):
W dniu 12 kwietnia 2012 12:43 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Jeśli chcemy mieć bardzo uniwersalnie to zapewne tak - wtedy od strony kontaktów mierzymy od razu w miniCRM ;-) Czy będzie więcej klikania - to zależy od tego czy wykorzystamy dobrze Javascript i Ajax. Wcale nie musi być tak dużo klikania wbrew pozorom.
Chodzi mi o sytuacje, że przy dodawaniu nowego klienta, wpisujesz: imię, nazwisko, ulica itd, zapisujesz, później musisz kliknąć dodaj kontakt, dodajesz informacje o kontakcie, zapisujesz. Trochę więcej klikania będzie, bo nie wszystko będzie dostępne na jeden podstronie.
W tym przypadku będzie na pewno więcej o jeden etap, ale już przy edycji kontaktów będzie lepiej. Raczej częściej edytuje się kontakty niż wprowadza się na nowo klienta i dopisuje mu świeże dane kontaktowe.
Może warto by się wzorować na formacie vcard przy określaniu jakie pola itd w kontaktach. Potem łatwo będzie takie kontakty importować eksportować itd.
http://en.wikipedia.org/wiki/VCard
pozdrawiam
o wlasnie wszystko co jest zgodne z jakims standardem jest dobre
[Thursday, 12 April 2012], Skiba Marek napisał(a):
type smallint -- 1 reprezentant, 0 nie reprezentant
Ja bym bardziej rozbudowal: - reprezentant (osoba upoważniona do zaciągania zobowiązań) - wysyłka faktur - płatności - sprawy handlowe (oferty, itp) - sprawy techniczne
W dniu 12.04.2012 11:51, Jaroslaw Dziubek napisał(a):
[Thursday, 12 April 2012], Skiba Marek napisał(a):
type smallint -- 1 reprezentant, 0 nie reprezentantJa bym bardziej rozbudowal:
- reprezentant (osoba upoważniona do zaciągania zobowiązań)
- wysyłka faktur
- płatności
- sprawy handlowe (oferty, itp)
- sprawy techniczne
Żeby tylko kolega nie zniechęcił się wizją ogromu prac i nie okazało się, że nie ma komu robić...
[Thursday, 12 April 2012], Tomasz Chiliński napisał(a):
W dniu 12.04.2012 11:51, Jaroslaw Dziubek napisał(a):
[Thursday, 12 April 2012], Skiba Marek napisał(a):
type smallint -- 1 reprezentant, 0 nie reprezentant
Ja bym bardziej rozbudowal:
- reprezentant (osoba upoważniona do zaciągania zobowiązań)
- wysyłka faktur
- płatności
- sprawy handlowe (oferty, itp)
- sprawy techniczne
Żeby tylko kolega nie zniechęcił się wizją ogromu prac i nie okazało się, że nie ma komu robić...
W miarę wolnego czasu chętnie pomogę (np. mogę poprawić lms-sendinvoices + skrypt do powiadamiania na e-mail o zaległościach płatniczych do którego przymierzam się już od dłuższego czasu ;-)
W dniu 12.04.2012 11:58, Jaroslaw Dziubek napisał(a):
[Thursday, 12 April 2012], Tomasz Chiliński napisał(a):
W dniu 12.04.2012 11:51, Jaroslaw Dziubek napisał(a):
[Thursday, 12 April 2012], Skiba Marek napisał(a):
type smallint -- 1 reprezentant, 0 nie reprezentant
Ja bym bardziej rozbudowal:
- reprezentant (osoba upoważniona do zaciągania zobowiązań)
- wysyłka faktur
- płatności
- sprawy handlowe (oferty, itp)
- sprawy techniczne
Żeby tylko kolega nie zniechęcił się wizją ogromu prac i nie okazało się, że nie ma komu robić...
W miarę wolnego czasu chętnie pomogę (np. mogę poprawić lms-sendinvoices + skrypt do powiadamiania na e-mail o zaległościach płatniczych do którego przymierzam się już od dłuższego czasu ;-)
Ja mam już większość skryptów przepisanych na PHP. Czekam z ich upublicznieniem do momentu, gdy będzie już oficjalnie dostępne wiki z pełną dokumentacją i wtedy je wrzucę do git oraz uzupełnię dokumentację wiki o informacje jak korzystać z tych skryptów - ogólnie są w bardzo dużym stopniu z wersjami perlowymi, ale są pewne różnice. lms-sendinvoices też można by przepisać na php. Właściwie pierwszymi skryptami, które wykorzystuje szkielet PHP są lms-pna.php, lms-cashimport-bgz.php oraz lms-gps.php. Dzięki takiemu podejściu oszczędza się dużo linii kodu wykorzystując gotowe rozwiązania z LMS, a jedyna poważną wadą może być brak dostępności PHP dla urządzeń wbudowanych.
W dniu 12 kwietnia 2012 12:56 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Żeby tylko kolega nie zniechęcił się wizją ogromu prac i nie okazało się, że nie ma komu robić...
Ruszyła maszyna, nie ma odwrotu.
W dniu 12.04.2012 12:11, Skiba Marek napisał(a):
W dniu 12 kwietnia 2012 12:56 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
Żeby tylko kolega nie zniechęcił się wizją ogromu prac i nie okazało się, że nie ma komu robić...
Ruszyła maszyna, nie ma odwrotu.
Bardzo mnie to cieszy i na pewno nie tylko mnie! Na każdym etapie możesz liczyć na pomoc z mojej strony, jeśli takowej będziesz potrzebował.
Tak to faktycznie ma sens. Komunikatory już od dawna powinny być również trzymane jako kontakty. Gdy Pjona weźmie się za to na pewno pomogę jak będzie taka potrzeba.
Przy okazji tej "rewolucji" proponowałbym dodanie pola "reprezentant" dla klienta który jest firmą, z możliwością dodania większej liczby reprezentantów, jak to jest w przypadku telefonów. Brakuje teraz tego pola przez co nie ma jak automatycznie sporządzać umów dla klientów którzy mają osobowość prawną np typu sp. zo.o. czy s.a. gdzie w umowie trzeba wpisywać reprezentanta spółki czasem dwóch
W dniu 12.04.2012 09:56, Dariusz Kowalczyk napisał(a):
Tak to faktycznie ma sens. Komunikatory już od dawna powinny być również trzymane jako kontakty. Gdy Pjona weźmie się za to na pewno pomogę jak będzie taka potrzeba.
Przy okazji tej "rewolucji" proponowałbym dodanie pola "reprezentant" dla klienta który jest firmą, z możliwością dodania większej liczby reprezentantów, jak to jest w przypadku telefonów. Brakuje teraz tego pola przez co nie ma jak automatycznie sporządzać umów dla klientów którzy mają osobowość prawną np typu sp. zo.o. czy s.a. gdzie w umowie trzeba wpisywać reprezentanta spółki czasem dwóch
To jeśli już to będzie typ kontaktu "reprezentant".
W dniu 2012-04-12 10:56, Dariusz Kowalczyk pisze:
Tak to faktycznie ma sens. Komunikatory już od dawna powinny być również trzymane jako kontakty. Gdy Pjona weźmie się za to na pewno pomogę jak będzie taka potrzeba.
Przy okazji tej "rewolucji" proponowałbym dodanie pola "reprezentant" dla klienta który jest firmą, z możliwością dodania większej liczby reprezentantów, jak to jest w przypadku telefonów. Brakuje teraz tego pola przez co nie ma jak automatycznie sporządzać umów dla klientów którzy mają osobowość prawną np typu sp. zo.o. czy s.a. gdzie w umowie trzeba wpisywać reprezentanta spółki czasem dwóch
My to ogarniamy poprzez plugin.html w szablonie ;)
W dniu 11 kwietnia 2012 14:34 użytkownik A.L.E.C alec@alec.pl napisał:
Wypada dodać kolumnę email.
No właśnie korzystanie z tej kolumny customercontacts to trochę brzydki sposób, bo wypadałoby dodać nową kolumnę 'email', chyba że zmienić nazwę kolumny 'phone' na coś bardziej ogólnego typu 'value'.
Natomiast jeśli chodzi o UI to widziałbym to ładnie rozbudowane na podobieństwo boksów Komputery klienta, Grupy klienta, etc.
Hm... niby można, ale czy aż tyle tych e-maili będzie żeby wyciągać to do osobnego boxu? W sensie za dużo opcji nie będzie apropo tych e-maili, tylko właśnie czy ma iść na ten e-mail faktura, i opcjonalnie opis e-mailu, czyli mam np. jakąś spółdzielnie gdzie będę miał e-mail jakiś i podpisane, że to e-mail do informatyka, do pani z biura itd.
Sorry, że dwa pod rząd, nie widziałem odpowiedzi Tomka.
Albo właśnie tak, że wyciągnąć wszystkie kontakty, czyli: e-maile, telefony, gg itp do osobnego boxu. Jeszcze apropo telefonów, to widzę że jest możliwość wyboru 'fax', 'tel. kom.' brakuje jeszcze 'dom', mogę też dopisać przy okazji.
W dniu 11.04.2012 14:02, Skiba Marek napisał(a):
Sorry, że dwa pod rząd, nie widziałem odpowiedzi Tomka.
Nie ma problemu.
Albo właśnie tak, że wyciągnąć wszystkie kontakty, czyli: e-maile, telefony, gg itp do osobnego boxu. Jeszcze apropo telefonów, to widzę że jest możliwość wyboru 'fax', 'tel. kom.' brakuje jeszcze 'dom', mogę też dopisać przy okazji.
To może od razu pogrupować bity w type funkcjonalnie i - jedna grupa bitów - typ kontaktu, np. telefon stacjonarny, telefon komórkowy, mail itp. - druga grupa bitów - właściwości kontaktu, np. domowy, służbowy, itp. - trzecia grupa bitów - rodzaje akceptowanych powiadomień, np. sms, mms, fax, mail, inne.
Trzeba to jakoś w jedną całość złożyć rozpatrując wszystkie istniejące przypadki.
uczestnicy (7)
-
"D.Wesołowski" -
A.L.E.C -
Dariusz Kowalczyk -
Jan Ciećko -
Jaroslaw Dziubek -
Skiba Marek -
Tomasz Chiliński