Пара последних роллапов (Rollup 10 / 11) с одной стороны решают часть накопившихся проблем, а с другой, как порой это бывает, приносят с собой дополнительные «неожиданности»:)

Вот, например, некоторые из них, с которыми мы столкнулись недавно:

1. После установки роллапа (ставился сразу 11) попытка экспортировать Default Solution заканчивается ничем. После нажатия кнопки Next браузер просто не загружает файл солюшена. (При этом прочие Solutions могут быть экспортированы нормально).

Заглянув в Fiddler, наблюдаем не слишком информативную ошибку  “Invalid Argument”.

Включив tracing, находим в куче следующее сообщение:

Crm Exception: Message: A non valid page number was received: 0, ErrorCode: -2147220989

На данный момент возможное лечение это проблемы видеться только следующее: необходимо найти ключ TurnOffFetchThrottling в реестре и установить его значение в 0; затем перезапустить IIS. Скорее всего, если вы столкнулись с подобной ошибкой, то у вас текущее значение этого ключа равно 1.

«Внешние» симптомы, приводящие к подобной ошибке в трейсе, могут быть различные. Например, в этой статье http://www.interactivewebs.com/blog/index.php/server-tips/crm-2011-rollup-10-invalid-argument-error/ рекомендуется указанное решение в случае проблем загрузки изображений в IFD среде.

Надо заметить, что, не смотря на то, что указанный обходной манёвр решает данную проблему, возможно, в некоторых случаях он может вызвать нежелательное поведение в кастомных и интеграционных решениях. Вероятность такого сценария зависит от конкретной реализации этих решений. Связано это с задачей, для решения которой ключ TurnOffFetchThrottling изначально предназначался (снятие ограничения на количество возвращаемых записей).

2. «Microsoft Dynamics CRM Asynchronous Processing Service (maintenance)» Windows  Service остановился и не мог стартовать.  Ошибка в логах Windows показала, что проблема связана запуском одной из scheduled job, которая имела период запуска несколько месяцев. Система, похоже, не воспринимала период в месяцах. Замена периода в месяцах на соответствующий период в днях решила проблему, и сервис запустился. Детальней копать причину такого поведения времени пока не было.

3. Похоже на то, что поведение плагинов зарегистрированных на Stage 50 немного изменилось. Как известно, Stage 50 предназначен только для обратной совместимости с плагинами CRM 4.0, где те могут быть зарегистрированы. Если до установки роллапа, 100 процентов вызовов на этом этапе шли уже за пределами транзакции, то после установки роллапа около 7% вызовов стали проходить внутри основной транзакции. Для некоторых специфических интеграционных подходов, использующих «старые 4.0» плагины на данном этапе, это может быть критично так как может вызвать блокировки в базе данных.  Но тут по большому счёту не «придерёшься»:). Майкрософт заявляет, что на этом этапе часть вызовов все-таки может проходить внутри транзакции. Просто раньше, до указанных роллапов, такого не наблюдалось, и этим можно было пользоваться. В общем, отсутствие в MS CRM 2011 этапа, который бы гарантированно выполнялся после основной операции и за пределами транзакции, можно рассматривать ряде случаев как недостаток функционала (мы рассматрваем тут синхронный вариант выполнения плагина).

4. Стили в Currency полях немного исказились. Вот как выглядит поле после роллапа:

Говорят эта проблема будет решена в 12 роллапе. Если такое форматирование нервирует довольно сильно, то на этой ветке форума можно посмотреть временное unsupported решение, связанное с модификацией базовых стилей:

http://social.microsoft.com/Forums/en-US/crm/thread/f3d8cb21-448b-4dc9-9cdc-3d5c91969adc

Кроме указанных выше случаев, можно обратить внимание на эту пару статей:

http://social.technet.microsoft.com/wiki/contents/articles/13437.update-rollup-10-for-microsoft-dynamics-crm-2011.aspx

http://social.technet.microsoft.com/wiki/contents/articles/14101.update-rollup-11-for-microsoft-dynamics-crm-2011-en-us.aspx

Они содержат интересные заметки о прочих возможных потенциальных проблемах, которые могут появиться после установки 10 и 11 пакета обновления.

В заключении хочется сказать, все это лишний раз говорит в пользу того, что не стоит спешить с установкой новых роллапов на продакшен  (конечно, если нет крайней потребности в каком-то конкретном исправлении или функциональности).  Все-таки стоит «прогнать» лишний раз основные сценарии на тестовом окружении, подождать отзывов в интернете от других пользователей, а … возможно и перевыпуска роллапа в целом  (что уже имело место в этом году).

Надеемся, что последующие пакеты обновлений для MS CRM будут более стабильны:)

Удачи!

Pavel Khorozhansky email: khorozhansky@gmail.com

Для чего нужны подразделения

В первую очередь, для отражения в CRM организационной структуры компании и объединения сотрудников в группы с целью работы на уровне бизнес-единиц, а не отдельных пользователей.

Кроме того, идеология Подразделения реализует один из трех механизмов управления доступом к данным: на уровне Подразделений, в дополнении к Ролям безопасности (security roles) и к Политике безопасности полей (fields security).

Суть управления доступом с использованием понятия Подразделения заключается в следующем. Если принадлежность сущности – «пользователь» (а не «организация»), то можно определить уровень доступа к экземплярам сущности: никому, только владельцу, пользователям своего Подразделения, пользователям своего и дочерних (подчиненных) Подразделений, всем.

Поэтому, если мы хотим регулировать доступ к данным в зависимости от принадлежности пользователей к тому или иному Подразделению, то нужно использовать тип принадлежности сущности – «пользователь».

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

При создании Роли безопасности она автоматически привязывается к Подразделению, которое указано в представлении Ролей безопасности. Если Роль создается из записи Подразделения, то она (Роль) также привязывается к текущему Подразделению.

Однако если Роли безопасности всегда создаются на уровне root, то тогда использование Подразделения в качестве аккумулятора нужного набора Ролей теряется. Поскольку для всех дочерних (по отношению к root) Подразделений будет создан одинаковый, что и у root, набор копий Ролей безопасности (подробнее см. Роли безопасности).

Особенности

Головное подразделение

Может быть только одно. Создается автоматически при развертывании CRM.

Головное Подразделение не имеет родительского подразделения.

Головное Подразделение – root – нельзя удалить или сделать неактивным.

Остальные подразделения

Подразделение всегда должно иметь головное подразделение. Поле родительское Подразделение (parent) в записи Подразделения не может быть пустым.

Циклические связи между Подразделениями не поддерживаются.

Переименовывать можно любое активное Подразделение.

Подразделение можно отключить. Достаточно сделать его неактивным. Неактивное Подразделение становится read only.

Однако неактивному Подразделению можно назначить другое головное Подразделение.

При отключении Подразделения все дочерние подразделения также становятся неактивными.

При отключении Подразделения его пользователи не удаляются и не переводятся в неактивные.

Пользователи неактивного Подразделения не могут подключаться к CRM.

Ресурсы и команды неактивного Подразделения не удаляются, но становятся недоступными для использования (выбора).

Чтобы удалить Подразделение, нужно сначала сделать его неактивным.

При переносе пользователя из одного Подразделения в другое (изменить Подразделение у пользователя) удаляются все его роли. Нужно назначать заново вручную.

При создании подразделения автоматически создается рабочая группа с таким же названием.

Нельзя назначить Роли безопасности подразделению. Однако это можно сделать с одноименной Рабочей группой.

Роли безопасности привязываются к Подразделению. Т.е. любое Подразделение имеет свой набор Ролей безопасности (см. Роли безопасности). Соответственно пользователям Подразделения могут быть назначены только Роли безопасности, которые привязаны к текущему Подразделению либо которые унаследованы из родительского (и выше) Подразделения.

Для определения того, какие Роли безопасности есть у Подразделения, следует использовать Расширенный поиск по Ролям безопасности с критерием «Родительская роль не содержит данных».

Важно

В документации к CRM 2011 сказано, что переименовывать и удалять Подразделения нельзя. На самом деле – можно (удалять нельзя только root). См. выше.

Ниже приводится один из простых и элегантных способов размещения фотографии пользователя в карточке пользователя Microsoft Dynamics CRM 2011.

Известно решение на базе Silverlight, в котором изображение хранится в примечании, а затем подгружается в форму. Однако добавить подобную функциональность можно проще, используя JScript и web ресурсы.

Краткое описание решения:

Фотография пользователя хранится в виде веб-ресурса.

Ссылка на веб-ресурс с фото помещается в поле photourl записи о пользователе, а значит, фото становится доступно во всех сущностях (и отчетах в том числе), в которых имеется привязка к пользователю.

Ссылка на фото (поле photourl) обновляется автоматически при открытии карточки пользователя и при обнаружении соответствующего веб-ресурса с фото.

Описанное решение пригодно, в первую очередь, для пользователей CRM, поскольку записи о пользователях хранятся от момента их регистрации до исключения из организации и не меняют своих Id. Регистрация пользователя в CRM – событие довольно редкое, поэтому можно себе позволить уделить немного времени на загрузку фото в виде веб-ресурса (с последующей публикацией ресурса).

Реализация.

  1. Выбираем фото неизвестного пользователя. Это фото будет загружено в виде веб-ресурса с именем UnknownUser, и затем будет отображаться в карточках тех пользователей, которые не имеют своих фотографий. Масштабируем и кадрируем фото, чтобы получить разрешение 100 х 133 пикселей (вы можете использовать другое разрешение на свое усмотрение).
  2. Выбираем фото пользователя. Масштабируем и кадрируем фото пользователя в разрешение 100 х 133. Для всех фото используем тип PNG.
  3. Создаем тестовое решение. В нем создаем ресурс для хранения изображения в формате PNG. Добавляем фото неизвестного пользователя:

  1. Открываем запись пользователя, фото которого мы подготовили, и копируем ссылку на запись. Секрет использования фото в виде веб-ресурса состоит в правильном именовании ресурса. Имя ресурса с фото образуется путем прибавления к префиксу уникального идентификатора записи пользователя, в котором убраны все знаки ‘-‘. Вот что должно получиться:

 

  1. Публикуем оба созданных веб-ресурса. А затем добавляем сущность Пользователь (systemuser).

 

  1. Открываем форму сущности Пользователь и вставляем в нее веб-ресурс – неизвестное фото. Параметры настройки веб-ресурса показаны ниже:

    

  1. Редактируем раскладку полей на форме на свой вкус. Например, так:

Не забываем добавить на форму поле photourl и скрыть это поле.

  1. Создаем и загружаем в CRMследующий JScript (логика его работы откомментирована):

 

if (typeof (Demo) == "undefined")
{ Demo = { }; }                                                     // пространство имен
 
Demo.User = {                                             // имя контейнера
//*************************************************************************
// Обработчики событий для формы Пользователь
//*************************************************************************
        // Инициализация
        //---------------------------------------------------------------------
        init : function ( )
        {
               this.setPhoto();
        },
        //----------------------------------------------------------------------     
        // Задание фотографии пользователя
        //----------------------------------------------------------------------     
        setPhoto : function ( )
        {     
               try
               {
                       // ищем элемент, где записана ссылка на ресурс с фото
                       var element = document.getElementById("WebResource_UserPhoto");                                                  
                       // вешаем на element обработчик успешной  загрузки WebResource                                                   
                       element.onload = function ()                                                                                                                                         
                       {
                              Xrm.Page.getControl("WebResource_UserPhoto").setVisible(true);                            // показываем фото
                              Xrm.Page.getAttribute("photourl").setValue(url);                                            // сохраняем в поле photourl правильный url
                       }
                       // вешаем на element обработчик ошибки загрузки WebResource                                                
                       element.onerror = function ()                                                                                                                                        
                       {
                              Demo.User.setImageUrl(element,"new_Photo_UnknownUser");                  // грузим фото UnknownUser
                              Xrm.Page.getControl("WebResource_UserPhoto").setVisible(false);           // на всякий случай
                       }
                       var url = Xrm.Page.getAttribute("photourl").getValue();                                         // считываем URL фото пользователя
                       // если url на фото еще не установлен или в поле photourl хранится ссылка на UnknownUser
                       If ( url == null || url.search(/UnknownUser/i) != -1 )                                                                                          
                              // конструируем url с фото пользователя и пытаемся загрузить
                              // важно использовать правильную последовательность знаков в регулярном выражении
                              // {-} работать не будет, поскольку является специальной конструкцией регулярного выражения
                              // В функции setImageUrl произойдет вызов element.setAttribute(url) - поэтому нужно else ниже
                              this.setImageUrl(element,"new_Photo_" + Xrm.Page.data.entity.getId().replace(/[{}-]/g, "").toUpperCase());      
                       else
                              element.setAttribute("src",url);                                          // пытаемся загрузить фото по url в поле photourl
               }
               catch (e) { }
        },
        //----------------------------------------------------------------------     
        // Конструирование url и его загрузка
        //----------------------------------------------------------------------     
        setImageUrl : function ( element, imageName )
        {
               var serverUrl = Xrm.Page.context.getServerUrl();
               if ( serverUrl.match(/\/$/) )                                                              // если есть адрес сервера заканчивается на /
                       serverUrl = serverUrl.substring(0, serverUrl.length - 1);          // убираем конечный слэш
               var url = serverUrl + "/WebResources/" + imageName;                 // конструируем url
               Xrm.Page.getControl("WebResource_UserPhoto").setSrc(url);      // устанавливаем атрибут ресурса "src" на url с фото
        }     
};

  1. Публикуем и добавляем скрипт на форму; устанавливаем обработчик события открытия формы на функцию init().

  1. Публикуем решение и проверяем его работу:

 

Успехов! Sergiy.Yezhov@gmail.com

Интерес — это основная сущность в CRM. Именно с Интереса начинается вся работа коммерсанта по заключению контракта.  Доступ к Интересам открыт из раздела Продажи и раздела Маркетинг.

Интерес, согласно концепции Microsoft Dynamics CRM, это некая информация о потенциально возможной сделке.

Важно понимать, что Интерес отличается от Возможной сделки тем, что вероятность будущей продажи на основе Интереса не оценивается. Т.е. в воронке продаж Интересы не фигурируют (однако рейтинг Интересу все же поставить можно; об этом ниже).

Значение сущности Интерес:

-       для коммерсанта — побудительный мотив реализовать некие действия: запланировать встречу, отправку электронного письма, звонок и т.п. Таким образом, сформированный в CRM Интерес — это открытая заявка для отработки ее менеджером;

-       для маркетолога — способ оценки эффективности маркетинговой кампании (по количеству созданных Интересов), а также возможность проанализировать каналы продаж и оценить активность клиентов в целевых группах.

-       для руководителя — объективный контроль эффективности работы менеджеров (отработки ими входящих звонков, электронных писем, обращений клиентов по телефону и через сайт).

С точки зрения коммерсанта, Интерес — это заинтересованность клиента в покупке. Что нам нужно, чтобы четко локализовать интерес клиента?

-       ФИО собственно клиента и данные о нем (включая название организации и ее координат);

-       суть его интереса к нашим продуктам и решениям (что клиент хочет);

-       наша оценка вероятности сделки и ее суммы;

-       планы по дальнейшей работе.

Логично? Вполне! Вот эти данные от нас и хочет получить CRM при создании новой записи об Интересе.

Как может появиться Интерес? Откуда CRM о нем узнает?

Три возможных варианта создания Интереса:

-       мы занесем данные об Интересе в CRM вручную. Это, например, может сделать секретарь, приняв входной звонок; маркетолог, обработав сообщение с сайта компании и т.п.;

-       мы импортируем данные из внешнего файла, формат которого «понимает» CRM. Например, мы можем загрузить контакты с выставки сразу списком и преобразовать их в Интересы;

-       CRM автоматически сгенерирует запись об Интересе исходя их имеющихся данных. Это может быть электронное письмо в ответ на рекламную кампанию или данные от цифровой офисной АТС.

Два последних способа требует дополнительной настройки CRM, поэтому мы их пока опускаем.

Создадим интерес к покупке акустической системы для домашнего кинозала. Выглядеть это будет примерно так:

Объем сведений, который стоит вносить в карточку Интереса, зависит от того, зарегистрирован ли потенциальный клиент в CRM или данные о нем заносятся впервые.  Если клиент уже зарегистрирован, то достаточно указать его ФИО; ведь все данные о клиенте уже известны и находятся в карточке Контакт.

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

Не следует также забывать указывать в карточке Интереса источник интереса, отрасль, в которой работает организация и приблизительный годовой доход организации. Эти сведения в последующем помогут проанализировать эффективность каналов продаж и сегментировать клиентов по различным признакам.

На странице представления Интересов справа можно открыть область диаграмм и заставить CRM построить следующие графики:

Дополнительно можно построить диаграммы Интересы по маркетинговой кампании, Интересы по ответственному и даже Скорость создания Интересов! CRM позволяет также создавать свои собственные виды диаграмм.

Заметьте, что хотя Интересам и не назначается вероятность их реализации в виде сделки, однако Интересам можно поставить рейтинговые оценки: Высокий, Средний, Низкий рейтинг. Соответственно, коммерсант получает возможность задать приоритет отработки входных заявок Интересов, а руководитель — примерно оценить значимость обращений в компанию.

 

Квалификация Интереса

Во что должен или может превратиться Интерес? Очевидно, в потенциальную сделку. Но так как мы заполняли еще и поля ФИО клиента и Название организации, то, очевидно, было бы логичным заставить CRM создать на основе этих данных нового Контакта и новую Организацию. Либо, если таковые существуют, то связать Интерес с уже зарегистрированными Контактом и Организацией.

Итак, вот причины, по которым мы квалифицируем интерес:

-       требуется зарегистрировать в CRM нового Контакта (проявившего Интерес);

-       требуется зарегистрировать в CRM новую Организацию (проявившую Интерес);

-       требуется перейти на шаг вперед в цепочке продажи — к Возможной сделке.

Жмем на кнопку Квалифицировать (в карточке Интереса или на главной ленте). Устанавливаем отметки в полях Контакт и Возможная сделка и щелкаем мышкой по кнопке ОК. Готово! Запись об Интересе преобразована в Возможную сделку, а попутно создана запись о Контакте, к которой привязаны и Интерес, и только что созданная Возможная сделка.

Теперь можно открыть вновь Возможную сделку и внести недостающие сведения: Предполагаемый доход, Вероятность, Предполагаемую дату закрытия, Оценку. А если в систему уже были бы загружены прайс-листы товаров, то можно было бы сформировать спецификацию продуктов.

В процессе работы с клиентом может выясниться, что он не хочет работать с компанией, или сама компания не заинтересована в работе с этим клиентом (не ее профиль). В этом случае пользователь может дисквалифицировать Интерес. Дисквалификация происходит по нажатию все той же кнопки Квалифицировать и выбором команды Дисквалифицировать. В дополнительном поле можно указать причины дисквалификации Интереса.

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

Интересы, преобразованные в Возможную сделку или дисквалифицированные, называются  закрытыми Интересами.

Ниже — рассмотренная нами схема работы с Интересом.

Дополнительные возможности анализа Интересов

На странице Интересы пользователь может выбрать несколько предустановленных фильтров для вывода списка зарегистрированных в CRM Интересов, например:

-       Все интересы (открытые и закрытые, к которым имеет доступ текущий пользователь);

-       Мои открытые интересы (интересы, за которые отвечает текущий пользователь; не обязательно создатель Интереса );

-       Закрытые интересы (квалифицированные и дисквалифицированные);

-       Интересы старше 6 месяцев;

-       Интересы, открытые на этой неделе;

-       Интересы, открытые на предыдущей неделе.

При необходимости можно легко задать свой фильтр для вывода списка Интересов. Для этого используется инструмент создания представлений на базе Расширенного поиска (об этом в следующий раз). Например, можно отфильтровать все Интересы по условию Интересы в отрасли Финансовая деятельность для организаций с годовым доходом, больше 1 000 000 долларов в год.

В заключении несколько соображений по квалификации и дисквалификации Интересов:

В первые недели работы с Интересами у пользователей-новичков часто возникает вопрос, на каком этапе работы с клиентом следует перевести Интерес в Возможную сделку. Можно предложить несколько явных признаков наступившей потребности в квалификации:

  1. Клиент попросил отправить ему Коммерческое предложение.
  2. Ответственный за Интерес сам счел целесообразным направить клиенту Коммерческое предложение.
  3. В процессе работы стало ясно, что необходимо составить спецификацию продуктов.
  4. Клиент сообщил свои планы по покупке: срок реализации сделки, бюджет, требуемые продукты и т.п.
  5. Стало известно, что в скором будущем состоится или уже объявлен тендер.
  6. Поступило распоряжение от руководителя начать работу с клиентом.

Часто спрашивают, как долго Интерес может быть открытым. Если принять во внимание, что Интересы – это отражение активной работы коммерсантов с клиентами, то очевидно, что «время жизни» Интереса должно быть не больше, чем время, достаточное для выяснения или уточнения потребностей клиента в товарах или услугах компании. В одном случае для этого хватит 5 минут и телефонного звонка, в другом случае – обмена несколькими сообщениями по электронной почте. Значит, Интерес не должен «висеть» в списке Открытых интересов пользователя. Если же Интересы «замерзают», то, наверное, ваш коммерсант сильно суетиться и не выглядит  убедительным перед потенциальными клиентами. Помните, что отложенный интерес клиента всегда можно повторно активировать!

Продолжение следует.
Sergiy
.Yezhov@gmail.com

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

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

Вряд ли, поскольку все же остается один вариант, когда вы напрямую транслируете цену Продукта в Прайс-лист, минуя механизм ценообразования Позиции прайс-листа. Но тогда вы теряете всю привлекательность использования Позиций прайс-листов!

Как это работает:

Вы создаете запись Продукта и указываете как минимум одну цену на Продукт. Всего же предусмотрена возможность задания трех разных цен, которые называются: Цена в прайс-листе, Нормативная стоимость и Текущая стоимость. Для чего три и с чем их «едят» – узнаете чуть позже.

Вы создаете Прайс-лист, в который будете включать созданные Продукты.

Наконец, находясь в карточке Прайс-листа, вы создаете запись Позиция прайс-листа и указываете, для какого Продукта она создана и как нужно пересчитать цену Продукта, когда он добавляется в Возможную сделку, Предложение, Счет или Заказ.

Вот, собственно, и главная особенность CRM: цена (цены) Продукта будет пересчитана при добавлении в Возможную сделку, Предложение, Счет или Заказ. До этого момента вы не можете увидеть (стандартными средствами CRM) какая же конечная цена Продукта для клиента.

Модели ценообразования

Microsoft Dynamics CRM содержит продвинутый механизм ценообразования с тремя предопределенными моделями:

  • сумма в валюте;
  • процент наценки;
  • процент маржи.

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

Сумма в валюте

Цена за единицу Продукта определяется как фиксированная сумма.

CRM будет использовать только эту цену, а не цены, введенные в полях Цена в прайс-листе, Нормативная стоимость и Текущая стоимость карточки Продукта.

Фактически это означает переопределение цены Продукта при продаже (с сохранением изначальной цены Продукта в его карточке).

Рекомендации по использованию:

Для временного переопределения цены Продукта (например, в период распродажи).

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

Процент наценки

Эта модель ценообразования может использоваться для всех видов цен Продукта: Цены в прайс-листе (требуется выбрать Процент списка), Нормативной стоимости (Процент наценки на нормативную стоимость), Текущей стоимости (Процент наценки на текущую стоимость).

Формулы для расчета:

Цена за единицу Продукта = Цена в прайс-листе х % наценки (списка)

Цена за единицу Продукта = Нормативная стоимость х % наценки

Цена за единицу Продукта = Текущая стоимость х % наценки

Например, если в поле Процент Позиции прайс-листа  с моделью ценообразования Процент списка будет введено 110, то при добавлении Продукта в спецификацию Предложения (Заказа, Счета) CRM рассчитает цену Продукта следующим образом: Цена за Продукт = Цена в прайс-листе х 110% (х 1,1).

Например, если в поле Процент Позиции прайс-листа с моделью ценообразования Процент наценки на текущую стоимость будет введено 120, то при добавлении Продукта в спецификацию Предложения (Заказа, Счета) CRM рассчитает цену Продукта следующим образом: Цена за Продукт = Текущая стоимость х 120% (х 1,2).

Рекомендации по использованию:

Для компаний, работающих с оптовыми (закупочными) ценами. Оптовые (закупочные) цены указываются в карточках Продуктов как Цена в оптовом прайс-листе. В случае продаж конечным клиентам, оптовые цены умножаются на заданный коэффициент и получаются розничные цены.

Для случая, когда используется две и более несвязанных между собой баз ценообразования. Т.е. при расчете цены на Продукт для разных категорий покупателей используется не одна базовая цена, а несколько. Одну базовую цену Продукта записываем в поле Цена в прайс-листе, другую — в поле Текущая стоимость. Далее можем использовать одну и ту же модель ценообразования Процент списка (применяется к Цене в прайс-листе) и Процент наценки (применяется к Текущей стоимости).

Для быстрого временного изменения цены на акционный Продукт. У вас должны существовать прайс-листы с разными моделями ценообразования Процент наценки, а в карточке Продукта должны быть указаны одинаковые цены в полях Цена в прайс-листе, Нормативная стоимость, Текущая стоимость. Когда потребуется использовать специальные цены, просто отредактируйте цены в полях Нормативная / Текущая стоимость. Соответственно, все прайс-листы с моделями наценки на нормативную / текущую стоимость позволят получить другие, отличные от обычных, цены.

Процент маржи

Формулы для расчета:

Цена за единицу Продукта = Нормативную стоимость / (100% – % маржи).

Цена за единицу Продукта = Текущая стоимость / (100% – % маржи).

Например, если в поле Процент позиции прайс-листа будет введено 30, то при добавлении Продукта в спецификацию Предложения (Заказа, Счета) CRM рассчитает цену Продукта следующим образом: Цена за Продукт = Текущая/Нормативая стоимость / (100% — 30%).

Пример: Текущая стоимость  = 240. Маржа = 30%.

Цена за продукт = 240 / (100% — 30%) = 342,86

Рекомендации по использованию:

Для случая, когда используется две несвязанные между собой базы ценообразования. Т.е. при расчете цены на Продукт для разных категорий покупателей используется не одна базовая цена, а две. Одну базовую цену Продукта записываем в поле Нормативная стоимость, другую — в поле Текущая стоимость. Далее можем использовать одну и ту же модель ценообразования Процент маржи.

Модель наиболее пригодна для компаний, строящих ценообразование по системе скидок. В этом случае базовые (закупочные) цены указываются в Нормативной и Текущей стоимости, а на выходе получаем розничные цены. Примем, Позиции прайс-листа будут содержать процент скидки, а при умножении розничной цены на процент скидки будем получать базовую (закупочную) цену.

Для быстрого временного изменения цены на акционный Продукт. См. выше.

Важное отступление

Чем принципиально отличается модель процент наценки от модели процент маржи?

Базой, от которой считается заработок продавца.

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

Пример:

Нормативная стоимость = 200. Наценка = 115%.

Цена Продукта для сделки = 200 х 115% = 200 + 15% от 200 = 230.

Заработок продавца 15% от начальной цены = 30.

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

Пример:

Нормативная стоимость = 200. Маржа = 15%.

Цена Продукта для сделки = 200 / (100 – 15)% = 235,29.

Заработок продавца 15% от розничной цены = 35,29.

Очевидно, что при равных розничных ценах и заданных процентах, модель ценообразования Процент маржи дает заработать продавцу больше :-)

Собственно, о механизме ценообразования в CRM – все!

Алгоритм занесения в CRM данных о ценах

  1. Выбираем требуемую модель ценообразования.
  2. Создаем в CRM группы единиц измерения и единицы измерения.
  3. Создаем в CRM необходимое количество прайс-листов и присваиваем им осмысленные наименования. Например: Прайс-лист Мелкая бытовая техника ОПТ. Прайс-лист Мелкая бытовая техника РОЗНИЦА. Прайс-лист Фотоаппараты ДИЛЕРЫ. Прайс-лист Фотоаппараты ОПТ…
  4. Выгружаем из CRM шаблон для сущности Продукт и на основе шаблона создаем нужное количество файлов для загрузки Продуктов. Указываем правильные значения (существующие в CRM) в столбцах Группа единиц измерения и Единица измерения по умолчанию. Рекомендуется создавать отдельный файл для каждой категории (группы) Продуктов.
  5. Загружаем Продукты в CRM. Устраняем, если были, ошибки импорта.
  6. Выгружаем шаблон Позиция прайс-листа. Создаем столько файлов на основе выгруженного шаблона, сколько Прайс-листов мы внесли в CRM на шаге 3.
  7. Экспортируем из CRM Продукты, которые должны быть включены в первый Прайс-лист.
  8. Открываем первый файл с шаблоном Позиции прайс-листа. Вставляем весь перечень выгруженных Продуктов (на шаге 7) в столбец Продукт. Заполняем все остальные столбцы файла (именно на этом этапе указывается модель ценообразования и сумма/процент). Загружаем файл в CRM.
  9. Повторяем шаг 8 с каждым Прайс-листом.
  10. Проверяем результаты.

Sergiy.Yezhov@gmail.com