Источник:
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/