Как правильно использовать прайс-листы в CRM (часть 2)
Теги customization, price, прайс-лист
Спецификация продуктов
Для Возможной сделки, Предложения с расценками, Счета и Заказа в CRM предусмотрена возможность формировать перечень продаваемых товаров — Спецификацию. Чтобы включить Продукт в Спецификацию, необходимо явно указать Прайс-лист, в котором этот Продукт содержится.
Казалось бы, не очень удобная вещь. Если в Спецификацию будут включаться Продукты из разных категорий товаров, а значит — входящие в разные Прайс-листы, то придется каждый раз указывать нужный Прайс-лист в форме Возможной сделки (Предложения, Счета, Заказа), да еще и сохранять форму перед дальнейшей работой со Спецификацией.
Однако все логично и обоснованно.
Рассмотрим случай, когда один и тот же Продукт может продаваться по разным ценам.
Например, фотоаппарат; в случае его отдельной покупки он будет стоить 1000 у.е., а в случае покупки комплекта фотостудии — его цена составит 950 у.е. в составе Спецификации студии.
Соответственно, могут использоваться Прайс-лист Розница и Прайс-лист Комплекты студии с разными схемами ценообразования, заложенными в разные Позиции прайс-листов. Т.е. в карточке самого фотоаппарата будет указана одна цена, например, Нормативная стоимость, в Позиции прайс-листа Розница может быть указан процент наценки 115%, а в Позиции прайс-листа Комплекты студии — процент наценки 110%.
Понятно, что такое «хитрое» ценообразование было бы невозможно, если бы не существовал промежуточный объект Позиция прайс-листа, позволяющий транслировать по заданным правилам закупочную стоимость Продукта на его цену для конечного клиента.
Итак, неудобство в необходимости выбора Прайс-листа для добавления Продукта компенсируется поддержкой гибкого ценообразования.
Если цены на Продукты для клиента всегда рассчитываются по неизменным правилам, ну что ж, создайте сводный Прайс-лист, который будет содержать все продаваемые Продукты. А если неудобно работать с одним большим прайсом, то логично было бы получить от CRM возможность оперативно переключаться с одного прайс-листа на другой при выборе Продукта.
Попробуем это сделать с помощью кастомизации сущности Продукт для ХХХ (Возможной сделки, Предложения, Счета, Заказа).
Кастомизация сущности Продукт для ХХХ
Цель: обеспечить возможность выбора представления Продуктов в диалоговом окне, появляющемся при щелчке на кнопке Поиск в поле Существующий продукт.
По умолчанию CRM показывает Продукты только в родительском Прайс-листе, т.е. Продукты, которые содержатся в указанном вами Прайс-листе в карточке Возможной сделки (Предложения, Счета, Заказа).
И это правильно, поскольку разные Прайс-листы могут содержать разные формулы расчета конечной цены одного и того же Продукта (благодаря использованию Позиций прайс-листа).
Однако если в вашей CRM системе всегда используется одна и та же формула расчета конечной цены для одного и того же Продукта, то можете смело выполнять описываемую ниже небольшую доработку функционала CRM.
Идем в раздел Параметры / Решения. Создаем новое Тестовое решение и добавляем в него сущность Продукт для возможной сделки. Открываем форму, щелкаем дважды по полю Существующий продукт на форме, чтобы настроить представления Продуктов.
Видим, что, к сожалению, CRM не предоставляет нам возможности выбрать нужные представления Продуктов.
Не беда! Выгрузим Тестовое решение и отредактируем файл customization.xlm.
Небольшое отступление из-за ошибки
ВАЖНО!
На этом этапе ни в коем случае не изменяйте никакие настройки в свойствах поля Существующий продукт!
На момент написания этой статьи в CRM 2011 до сих пор осталась досадная ошибка:
Редактирование свойств поля Существующий продукт, например, свойства Фильтрация связанный записей, приводит к замене представления Продукты в родительском прайс-листе на представление для поиска продуктов.
Таким образом, если раньше открыв диалоговое окно для выбора Продуктов, вы получали список Продуктов в родительском (выбранном вами) Прайс-листе, то после изменения свойств поля Существующий продукт вы получите полный список всех продуктов!
Кстати, описанная ниже кастомизация файла customizaton.xlm поможет исправить эту ошибку, если кто-то вдруг случайно отредактировал свойства поля Существующий продукт и «потерял» представление продуктов из родительского прайс-листа.
Правка файла customizaton.xlm
Итак, извлекаем из выгруженного архива нашего решения файл customizaton.xlm и открываем его в каком-либо редакторе, поддерживающим синтаксис XML (лично я использую программу Notepad++).
Ищем раздел, связанный с полем Существующий продукт. Можно использовать поиск по фразе <control id="productid".
Правильный код узла <parameters> должен быть такой:
где {270BD3DB-D9AF-4782-9025-509E298DEC0A} — id сущности Продукт.
{BCC509EE-1444-4a95-AED2-128EFD85FFD5} — id представления Продукты в родительском прайс-листе.
Ошибка CRM, возникающая после редактирования свойств поля Существующий продукт, связана как раз с заменой представления {BCC509EE-1444-4a95-AED2-128EFD85FFD5} на представление {8BA625B2-6A2A-4735-BAB2-0C74AE8442A4} для поиска продуктов.
В качестве параметров для настройки представлений могут использоваться:
DefaultViewReadOnly — true, если в настройках свойств поля Существующий продукт запрещено выбирать представление, используемое по умолчанию
ViewPickerReadOnly — true, если в настройках свойств поля Существующий продукт нельзя выбирать наборы представлений, которые будут включаться в раскрывающийся список представлений (поле Выбор представлений в конструкторе формы будет запрещено).
DisableViewPicker — true, если запрещено раскрытие списка представлений
DefaultViewId — id представления, которое выбирается по умолчанию (при открытии диалогового окна для выбора представления)
AutoResolve — true, если разрешена подстановка текста в строке быстрого поиска
DisableMru — true, если CRM не производит сохранение последних введенных строк поиска
DisableQuickFind — true, если строка быстрого поиска не отображается
AvailableViewIds — набор id представлений, которые включаются в раскрывающийся список
FilterRelationshipName — имя сущности, которая связана с Продуктом
DependentAttributeName — имя атрибута в связанной сущности, по которому производится фильтрация Продуктов
DependentAttributeType — тип поля атрибута у связанной сущности
AllowFilterOff — true, если пользователь может отключать фильтр по связанным записям.
Чтобы разрешить пользователю выбирать вид представления и отфильтровывать Продукты по заданной Валюте, следует установить такие значения:
Упакуйте исправленный файл customization.xml в архив и загрузите решение в CRM. Проверьте, что теперь вы можете выбирать представление Продуктов в поле Существующий продукт.
ВАЖНО!
Используйте описанный метод только в случае, если конечная цена Продукта одинакова во всех Прайс-листах.
Для Возможной сделки, Предложения с расценками, Счета и Заказа в CRM предусмотрена возможность формировать перечень продаваемых товаров — Спецификацию. Чтобы включить Продукт в Спецификацию, необходимо явно указать Прайс-лист, в котором этот Продукт содержится.
Казалось бы, не очень удобная вещь. Если в Спецификацию будут включаться Продукты из разных категорий товаров, а значит — входящие в разные Прайс-листы, то придется каждый раз указывать нужный Прайс-лист в форме Возможной сделки (Предложения, Счета, Заказа), да еще и сохранять форму перед дальнейшей работой со Спецификацией.
Однако все логично и обоснованно.
Рассмотрим случай, когда один и тот же Продукт может продаваться по разным ценам.
Например, фотоаппарат; в случае его отдельной покупки он будет стоить 1000 у.е., а в случае покупки комплекта фотостудии — его цена составит 950 у.е. в составе Спецификации студии.
Соответственно, могут использоваться Прайс-лист Розница и Прайс-лист Комплекты студии с разными схемами ценообразования, заложенными в разные Позиции прайс-листов. Т.е. в карточке самого фотоаппарата будет указана одна цена, например, Нормативная стоимость, в Позиции прайс-листа Розница может быть указан процент наценки 115%, а в Позиции прайс-листа Комплекты студии — процент наценки 110%.
Понятно, что такое «хитрое» ценообразование было бы невозможно, если бы не существовал промежуточный объект Позиция прайс-листа, позволяющий транслировать по заданным правилам закупочную стоимость Продукта на его цену для конечного клиента.
Итак, неудобство в необходимости выбора Прайс-листа для добавления Продукта компенсируется поддержкой гибкого ценообразования.
Если цены на Продукты для клиента всегда рассчитываются по неизменным правилам, ну что ж, создайте сводный Прайс-лист, который будет содержать все продаваемые Продукты. А если неудобно работать с одним большим прайсом, то логично было бы получить от CRM возможность оперативно переключаться с одного прайс-листа на другой при выборе Продукта.
Попробуем это сделать с помощью кастомизации сущности Продукт для ХХХ (Возможной сделки, Предложения, Счета, Заказа).
Кастомизация сущности Продукт для ХХХ
Цель: обеспечить возможность выбора представления Продуктов в диалоговом окне, появляющемся при щелчке на кнопке Поиск в поле Существующий продукт.
По умолчанию CRM показывает Продукты только в родительском Прайс-листе, т.е. Продукты, которые содержатся в указанном вами Прайс-листе в карточке Возможной сделки (Предложения, Счета, Заказа).
И это правильно, поскольку разные Прайс-листы могут содержать разные формулы расчета конечной цены одного и того же Продукта (благодаря использованию Позиций прайс-листа).
Однако если в вашей CRM системе всегда используется одна и та же формула расчета конечной цены для одного и того же Продукта, то можете смело выполнять описываемую ниже небольшую доработку функционала CRM.
Идем в раздел Параметры / Решения. Создаем новое Тестовое решение и добавляем в него сущность Продукт для возможной сделки. Открываем форму, щелкаем дважды по полю Существующий продукт на форме, чтобы настроить представления Продуктов.
Видим, что, к сожалению, CRM не предоставляет нам возможности выбрать нужные представления Продуктов.
Не беда! Выгрузим Тестовое решение и отредактируем файл customization.xlm.
Небольшое отступление из-за ошибки
ВАЖНО!
На этом этапе ни в коем случае не изменяйте никакие настройки в свойствах поля Существующий продукт!
На момент написания этой статьи в CRM 2011 до сих пор осталась досадная ошибка:
Редактирование свойств поля Существующий продукт, например, свойства Фильтрация связанный записей, приводит к замене представления Продукты в родительском прайс-листе на представление для поиска продуктов.
Таким образом, если раньше открыв диалоговое окно для выбора Продуктов, вы получали список Продуктов в родительском (выбранном вами) Прайс-листе, то после изменения свойств поля Существующий продукт вы получите полный список всех продуктов!
Кстати, описанная ниже кастомизация файла customizaton.xlm поможет исправить эту ошибку, если кто-то вдруг случайно отредактировал свойства поля Существующий продукт и «потерял» представление продуктов из родительского прайс-листа.
Правка файла customizaton.xlm
Итак, извлекаем из выгруженного архива нашего решения файл customizaton.xlm и открываем его в каком-либо редакторе, поддерживающим синтаксис XML (лично я использую программу Notepad++).
Ищем раздел, связанный с полем Существующий продукт. Можно использовать поиск по фразе <control id="productid".
Правильный код узла <parameters> должен быть такой:
где {270BD3DB-D9AF-4782-9025-509E298DEC0A} — id сущности Продукт.
{BCC509EE-1444-4a95-AED2-128EFD85FFD5} — id представления Продукты в родительском прайс-листе.
Ошибка CRM, возникающая после редактирования свойств поля Существующий продукт, связана как раз с заменой представления {BCC509EE-1444-4a95-AED2-128EFD85FFD5} на представление {8BA625B2-6A2A-4735-BAB2-0C74AE8442A4} для поиска продуктов.
В качестве параметров для настройки представлений могут использоваться:
DefaultViewReadOnly — true, если в настройках свойств поля Существующий продукт запрещено выбирать представление, используемое по умолчанию
ViewPickerReadOnly — true, если в настройках свойств поля Существующий продукт нельзя выбирать наборы представлений, которые будут включаться в раскрывающийся список представлений (поле Выбор представлений в конструкторе формы будет запрещено).
DisableViewPicker — true, если запрещено раскрытие списка представлений
DefaultViewId — id представления, которое выбирается по умолчанию (при открытии диалогового окна для выбора представления)
AutoResolve — true, если разрешена подстановка текста в строке быстрого поиска
DisableMru — true, если CRM не производит сохранение последних введенных строк поиска
DisableQuickFind — true, если строка быстрого поиска не отображается
AvailableViewIds — набор id представлений, которые включаются в раскрывающийся список
FilterRelationshipName — имя сущности, которая связана с Продуктом
DependentAttributeName — имя атрибута в связанной сущности, по которому производится фильтрация Продуктов
DependentAttributeType — тип поля атрибута у связанной сущности
AllowFilterOff — true, если пользователь может отключать фильтр по связанным записям.
Чтобы разрешить пользователю выбирать вид представления и отфильтровывать Продукты по заданной Валюте, следует установить такие значения:
Упакуйте исправленный файл customization.xml в архив и загрузите решение в CRM. Проверьте, что теперь вы можете выбирать представление Продуктов в поле Существующий продукт.
ВАЖНО!
Используйте описанный метод только в случае, если конечная цена Продукта одинакова во всех Прайс-листах.
Всего комментариев 0
