Все о Microsoft Dynamics CRM: Работа с полями поиска двойного типа в бизнес-процессах

[Blog bot]

Источник: http://ms-dynamics-crm.com.ua/2012/0...s-in-workflow/
==============

Полями двойного типа я называю поля поиска, которые могут содержать идентификаторы записей различных типов.

Например, поле Потенциальный клиент в Возможной сделке может содержать идентификатор записи типа Организация и типа Контакт. Если нажать на кнопку поиска в этом поле, то CRM предложит нам определиться с типом записи:



Такая, безусловно, удобная функциональность вносит определенные проблемы при разработке бизнес-процессов.

Рассмотрим это на примере обработки экземпляра Возможной сделки (ВС) в бизнес-процессе (БП).



Задача

Обеспечить хранение в ВС имени старого потенциального клиента. Т.е. при выборе нового потенциального клиента, данные о предыдущем клиенте должны сохраняться.

Примечание: задача выдумана от начала и до конца и не имеет ничего общего с реальной функциональностью J.

Логика

Напишем БП, который будет срабатывать на изменение поля Потенциальный клиент (событие OnChange).

Так как срабатывание произойдет ПОСЛЕ сделанных изменений, то потребуется 2 кастомных поля для хранения данных о клиентах.

Первое кастомное поле (CurrentClient) дублирует значение поля Потенциальный клиент.

Второе кастомное поле (OldClient) содержит данные о старом Потенциальном клиенте.

При обнаружении события OnChange на поле Потенциальный клиент:

1)       Переписать значение из CurrentClient в OldClient

2)       Переписать значение из Потенциальный клиент в CurrentClient

Реализация

Первая трудность, с которой мы столкнемся, — это невозможность создать кастомное поле типа Клиент, которое позволяло бы записывать в него и Организацию, и Контакта. Вы можете создать поле типа Поиск либо для Организации, либо для Контакта.

Ок, продублируем и создадим CurrentOrganization, CurrentContact, OldOrganization, OldContact.

Вторая трудность: как распознать на этапе отработки БП, в какое из кастомных полей писать значение поля Потенциальный клиент? Ведь БП не содержит в своем функционале определение типа записи…

Решение достаточно простое: использовать в БП динамические значения. Дело в том, что динамические значения полей точно так же не имеют объединяющего поля Клиент и, соответственно, явно разделяют типы записей Организация и Контакт.



Ну вот, теперь достаточно добавить в БП шаг с проверкой условия:



Как и следует ожидать, CRM при использовании динамических значений выполняет операцию приведение типа поля Потенциальный клиент к типу Организация или к типу Контакт (в зависимости от того, какое динамическое значение выбрано). Операция приведения к типу даст null для поля несоответствующего типа, поэтому указанное выше условие вернет false, если мы попытаемся сравнить поле Потенциальный клиент (в котором указан Контакт) с динамическим значением
ВС→Потенциальный клиент (Организация).

PS. Не мешает еще проверить условие: ВС→Потенциальный клиент содержит данные. Иначе вы будете сравнивать null c null и получите в условии выше результат true.



Источник: http://ms-dynamics-crm.com.ua/2012/0...s-in-workflow/