CRM + Excel

Ogromna wartość dodana posiadania Dynamics CRM to integracja z pakietem Office. Oprócz dodatku do Outlook Dynamics CRM bardzo fajnie współpracuje z Excel. Jedną z możliwości jest eksport danych.

Każdy z użytkowników (posiadając uprawnienie do eksportu danych do programu Excel) ma możliwość eksportu danych. Każda encja w Dynamics CRM posiada we wstążce Grid oraz Sub-grid przycisk służący do eksportu danych:

 

 

 

 

 

 

 

Kliknięcie tego przycisku spowoduje wyświetlenie okienka pozwalającego wybrać opcję eksportu danych:

 

• Pierwsza opcja pozwala na eksport danych prezentowanych w wybranym widoku. Kolumny jakie są eksportowane są definiowane na poziomie widoku. Jeśli lista prezentuje dużo danych (jest więcej niż jedna strona danych) to opcja ta umożliwia eksport danych z jednej strony lub ze wszystkich stron.
• Druga opcja (Dynamic PivotTable) to możliwość eksportu danych do tabeli przestawnej. Przy wykorzystaniu tej opcji mamy aktywny przycisk wyboru kolumn jakie będą eksportowane. Co ważne, kolumny mogą być wybrane z obiektów powiązanych z eksportowaną encją. Oznacza to, że eksportując dane o klienta możemy wyspecyfikować kolumny z encji użytkownik, klient nadrzędny. Możemy zatem poruszać się po obiektach encji nadrzędnych.
• Trzecia opcja to eksport do arkusza dynamicznego. Arkusz dynamiczny pozwala na wybór kolumn jakie będą zamieszczone w pliku wynikowym (analogicznie do opcji 2) a dane prezentowane są w postaci arkusza (analogicznie do opcji 1).

Opcja druga oraz trzecia ma jedną ważna rzecz – jeśli poświęcimy czas na to, aby plik wynikowy odpowiednio przygotować, pokazać wykresy, zmienić formatowanie, itd. to pliki te można wykorzystać jako raport. Taki plik posiada połączenie z Dynamics CRM i korzystając z opcji odświeżenia danych w Excel możemy pobrać aktualne dane:

Liczba rekordów jaka zwracana jest w takim połączeniu jest ograniczone do 10 000 (limit ten można zmienić, ale jest to niewspierane!).

Oprócz tego, że plik Excel może zostać “odświeżony” może również zostać udostępniony użytkownikom jako raport w Dynamics CRM. W tym celu należy w obszarze roboczym stworzyć nowy raport wybierając jako typ raportu Istniejący plik. Dzięki temu udostępniamy plik wybranym użytkownikom oraz posiadamy jedno miejsce, w którym zarządzamy raportem – nie ma potrzeby przesyłania gotowego pliku pocztą czy też udostępniania go na różne sposoby.

O czym jeszcze nie pisałem a jest bardzo istotne to fakt, iż dane eksportowane do pliku Excel (w przypadku opcji 2 lub 3) są pobierane z widoków filtrowanych – dzięki temu użytkownicy zobaczą tylko te rekordy, do których mają uprawnienia – nie ma problemu wycieku danych :).

CRM 2011–OnSave

Wydawać by się mogło, że zwyczajne zdarzenie OnSave wywoływane jest w momencie kiedy użytkownik kliknie przycisk Zapisz, Zapisz i Zamknij lub też Zapisz i Utwórz nowy, który znajduje się we wstążce.
Okazuje się, że nie tylko wtedy kod ten jest uruchamiany. Dzieję się to również kiedy chcemy obiekt dezaktywować lub aktywować jak również wtedy kiedy chcemy wykonać operację przypisania rekordu – oczywiście jeśli wykonujemy te operacje z poziomu formularza. Powstaje zatem pytanie: jak odróżnić w JS kiedy jest on uruchamiany. Można by się pokusić o sprawdzanie FormType, ale zadziała to tylko w przypadku aktywacji obiektu bo możemy sobie zobaczyć, że formularz jest wtedy tylko do odczytu. Dla pozostałych operacji zawsze będziemy mieli typ formularza Update.
Jest na szczęście wspierane (to moje ulubione stwierdzenie :D) rozwiązanie tej zagadki. W czasie kiedy konfigurujemy zdarzenie OnSave widzimy na formularzu następujące coś:

Co się dzieje kiedy zaznaczymy ten checkbox ? Po pierwsze nasza funkcja musi być odpowiednio zmodyfikowana i wyglądać powinna mniej więcej tak:

A co daje nam ten parametr ? Widać to już na obrazku wyżej: eContext.getEventArgs().getSaveMode() – pozwala nam na “dobranie” się do wartości, które pomogą nam w zrozumieniu co jest powodem wystąpienia operacji Zapisz. Te numerki, które widać na obrazku są do odnalezienia w SDK. Na wszelki wypadek zamieszczam je tutaj (wartości pochodzą z SDK opublikowanego 2.12.2011 :) – kto wie czy będą w przyszłości zmienione):

Entity	Event Mode	Value
All	Save	1
All	Save and Close	2
All	Save and New	59
Activities	Save as Completed	58
All	Deactivate	5
All	Reactivate	6
User or Team owned entities	Assign	47
Email (E-mail)	Send	7
Lead	Qualify	16
Lead	Disqualify	15

Dostęp do raportów w CRM

Czasami zdarza się, aby dostęp do specyficznych raportów dostęp mieli tylko konkretni użytkownicy lub też aby domyślne raporty dostępne w CRM były poukrywane przed większością użytkowników. Jak do tego podejść ?

Raport w Dynamics CRM jest prawie takim samym obiektem jak Klient czy Kontakt. Powoduje to, iż konfigurując uprawnienia możemy zdecydować czy użytkownik może widzieć tylko swoje raporty, raporty wszystkie (w całej organizacji):

Z drugiej jednak strony napisałem, że Raport jest prawie jak Klient czy Kontakt. To prawie polega na tym, że w ustawieniach raportu możemy określić czy raport jest indywidualny czy też dostępny w organizacji.

Co to właściwie znaczy ? A dokładnie to, że ustawienie na Organizacja powoduje, że raport jest dostępny nawet dla tych użytkowników, którzy mają dostęp w uprawnieniach tylko do swoich raportów. Jeśli Raport ustawiony jest jako Indywidualny to dostępny jest dla właściciela raportu, tych komu jest on udostępniony oraz tych, których rola daje dostęp do tego raportu.

Patrząc z drugiej strony – jeśli użytkownik ma dostęp tylko do swoich raportów to widzi on naprawdę następujące raporty:

• Te, których jest właścicielem
• Te, które są mu udostępnione
• Te, które są ustawione jako raporty Organizacyjne.

Filtrowane pola typu Lookup

W CRM 4.0 w większości projektów trzeba było tworzyć niewspierane rozwiązanie, które pomagało korzystać z filtrowanych pól typu Lookup. Przykładem takiego zastosowania było np. umieszczenie na formularzu klienta powiązania z bazą kodów pocztowych. Zamiast polegać na tym, aby użytkownicy CRM sami wprowadzali wartości w polach budowany był słownik kodów pocztowych. Słownik ten miał również dodatkowe informacje takie jak województwo czy też powiat (również w postaci słownika). Na formularzu klienta umieszczane były pola Kod Pocztowy, Powiat, Województwo. Wybranie np. województwa powodować powinno zawężenie wartości w słowniku Powiat oraz Kod Pocztowy do wartości z danego województwa.

W CRM 2011 Microsoft zaimplementował wsparcie dla tego typu funkcjonalności i filtrowane lookupy stały się wspierane “z pudełka”. Konfigurując pola typu lookup na formularzu można wybrać sobie czy ma to pole być filtrowane czy też nie. A jeśli ma to na podstawie jakiego pola – uwaga – tylko jednego:

 

 

 

 

 

W większości przypadków wykorzystanie filtrowania po jednym polu wystarczy. Gdyby jednak to było za mało mamy do dyspozycji coś co powala i czego nie było w poprzedniej wersji CRM. Możemy sami definiować sobie widok jaki będzie pokazywany w oknie wyszukiwania (po kliknięciu lupki w polu typu lookup). Jak to się robi ?

Pisze się odpowiedni kod w JS i umieszcza jego wykonania np. w zdarzeniu OnLoad formularza. Definiując taki kod określamy przede wszystkim kryteria wyszukiwania (w postaci FetchXML) oraz tego jak ma być prezentowany widok – czyli określamy jakie kolumny, w jakiej szerokości mają prezentować się w okienku wyszukiwania. W efekcie możemy otrzymać filtrowany lookup bez ograniczeń. Przykładowe zastosowanie tego mechanizmu: rejestrujemy w CRM szanse sprzedaży, ale dla jednej szansy sprzedaży można dowiązać wielu klientów (relacja N:1 pomiędzy szansą sprzedaży a klientem). Następnie na formularzu szansy chcemy wskazać jedną osobę kontaktową (Kontakt), która będzie wskazywać osobę decyzyjną spośród wszystkich osób kontaktowych wszystkich klientów biorących udział w szansie sprzedaży. Aby pokazać w oknie wyszukiwania tylko te osoby kontaktowe, które dowiązane są do klientów dowiązanych do szansy sprzedaży korzystamy właśnie z kodu JS.

Przykładowy kod wygląda następująco:

Po więcej szczegółów odsyłam do SDK – słowo kluczowe do znalezienia to addCustomView :)

CRM 2011 i jego dostosowywanie

Wydawać się by mogło, że nowa wersja CRM usprawni edycję takich dostosowań jak znana z CRM 4.0 mapa witryny (sitemap) czy też ISV.config. Ten pierwszy plik w nowej wersji CRM nie został zmieniony natomiast ISV.config zastąpiony został plikiem xml definiującym elementy wstążki. Wstążka to zupełnie nowa rzecz, która wykracza daleko poza możliwości starego ISV.config. Nowe możliwości niosą za sobą rozbudowaną strukturę, bardziej skompilowanie definicje pliku xml czy też rozbicie wstążki na poszczególne encje – kto miał do czynienia z dodaniem przycisku do wstążki ten wie o czym mowa ;)

Niestety Microsoft nie zaprezentował narzędzia, które pozwoli na łatwą edycję zarówno mapy witryny jak też wstążki. Na szczęście społeczność Dynamics CRM nie śpi i na codeplex znaleźć można dwa fajne narzędzia:

1. http://sitemapeditor.codeplex.com/

   

2. http://ribboneditor.codeplex.com/

   

 

Pamiętać jednak należy, że są to narzędzia, które mogą działać niestabilnie i trzeba wiedzieć co kryje się pod maską CRMa aby, jeśli będzie to konieczne, naprawić to co zostanie zepsute :)

CRM 2011–Ukrywanie widoków systemowych

Kto miał za zadanie ukryć widoki systemowe w CRM 4.0 ten wie jakie to było problematyczne :) Co się zmieniło w nowym CRM ? Podobnie jak np. klienta może być aktywny lub nieaktywny tak samo widoki. Z poziomu dostosowań możemy oznaczyć widok jako aktywny/nieaktywny:

Po dezaktywacji widok będzie widoczny w liście widoków nieaktywnych:

Po wyłączeniu kilku widoków i opublikowaniu zmian w efekcie dostajemy przykładową listę widoków:

Efekt osiągnięty w prosty sposób co w CRM 4 zajmowało czas na napisanie pluginu, który przestawał działać kiedy ktoś przypadkiem zmienił nazwę widoku :)

CRM 2011–pierwszy egzamin MB2-866

Na stronie Microsoft Learning znaleźć można już informacje o egzaminie związanym z Dynamics CRM 2011: MB2-866: Microsoft Dynamics CRM 2011 Customization and Configuration. Szczegółowe informacje znaleźć można na stronie ML: http://www.microsoft.com/learning/en/us/exam.aspx?ID=MB2-866