Коллеги, здравствуйте!

Возник вопрос: Как скрыть базовую цену продукта и оставить только для руководителей? 

Заранее спасибо!

Нравится

5 комментариев

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

Учтите, что если на значение поля завязана какая-то логика, она может начать работать неправильно из-за отсутствия доступа. Лучше сначала проверить на тесте, допустимо ли такое разграничение прав.

Зверев Александр,

можно скрыть только доступ к записи, объекту или колонке. А есть ли возможность скрыть доступ к справочному значению?

Можно раздать права доступа по записям на объект справочника. Но это как раз не поможет, поскольку первичное поле записи (то есть название) видится независимо от наличия прав.

Разве что прикрутить на уровне карточки фильтрацию на справочное поле.

Зверев Александр, а каким образом можно установить фильтрацию на справочник?

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

Показать все комментарии

Добрый день. Интересует вопрос по обучению. Сколько будет стоить курс обучения по настройке, адаптации и интеграции с последующей сертификацией? Какова длительность курса? Возможно ли удаленное обучение?
С уважением, Александр.

Нравится

1 комментарий

Цены на курсы - в академии (ссылка). Длительность - 4 дня (по 4-5 часов, насколько я помню).
Сертификация - в районе 7к за 1 попытку. Тестовый прогон можно, опять же, пройти в академии забесплатно сколько угодно раз.

Добавлю от себя: наберитесь терпения, заварите побольше чая, скачайте мануал SDK в pdf (или можно просто смотреть в браузере тут) и штудируйте. Делайте все тестовые примеры, а после попытайтесь настроить какую-нибудь конфигурацию (хотя бы тестовую). Ибо на обучении рассказывают 1 в 1 всё то же самое, что написано в sdk. А, там можно вопросы ведущему задать. Такая себе польза за 20+к...

В целом неплохо настраивать конфигурацию поможет только практика. Вот.

Ps. весь свой "экспириенс" по обучению настройки bpm я могу описать так - огромное поле, на котором валяются тысячи граблей :smile:

Показать все комментарии

Нужна следующая функция в CRM: отправление ценового предложения клиенту
из CRM. или чтобы файл с ценовым предложением крепился к истории
клиента. В общем, чтобы информация о цене, которую менеджер дал клиенту,
сохранялась в CRM. Есть ли такая возможность? Версия 7.2.0.1184 bpmonline crm
Я так поняла, необходима доработка приложения, но что именно? Пожалуйста, помогите!

Нравится

1 комментарий

Татьяна, добрый день!

Обе задачи требуют навыков программирования.

Для решения можно создать бизнес процесс. Логика процесса:
1) Создать активность с типом "Email". запись может быть создана элементом "Добавить данные". Обязательно нужно заполнить поля "Кому", "От кого", "Тема", "Тело"
2) Элементом "Задание-сценарий" необходимо:

  • Сформировать ценовое предложение. Для этого можно использовать методы из схемы ReportService
  • Заинсертить сформированный файл в таблицу ActivityFile, обязательно указав в поле ActivityId значение Id созданной на первом шаге активности
  • Отправить письмо

Не уверен, что в версии 7.2.0 есть пример такой отправки. Рекомендую зарегистрировать себе trial версию продукта service enterprise. В процессе "Отправка email сообщения контакту обращения" вы сможете найти пример кода.

3) Конец процесса

В случае с прикреплением ценового предложения к клиенту, можно пропустить первый пункт, поскольку активность не нужна. На втором пункте INSERT сформированного файла необходимо осуществлять в таблицу ContactFile/AccountFile (в зависимости от того контакт или контрагент является клиентом).

Показать все комментарии
В настоящий момент при смене курса валюты в счёте, в продукты зачитывается цена из прайс-листа.В итоге, во-первых, при частой смене цен будут неверно пересчитываться счета. А во-вторых, чтобы разрешить вводить цены, отличные от прайс-листа (и чтобы после этого bpm не переписывал поверху введенные цены), надо перелопатить много кода. Предлагаю в InvoiceProduct фиксировать цену на момент добавления, и уже пересчитывать в будущем, исходя из неё
9 комментариев

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

Мы в проектах делаем 3 цены:

Base Price (стандартная цена продукта)
Contracted Price (цена продукта из прайс-листа для конкретного клиента)
Invoiced Price (согласованная цена в счёт).

В итоге всегда можно посмотреть и посчитать, насколько выгодны клиенты и насколько много дают скидки/наценки менеджеры

Но для этого надо:

переписать логику в карточке продукта в счёте
переписать логику процесса в объекте продукта в счёте
переписать логику в ProductEntryUtils
....

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

Считаю, что точно должны быть такие цены в коробке
Base Price (стандартная цена продукта)
Invoiced Price (согласованная цена в счёт).

Contracted Price (цена продукта из прайс-листа для конкретного клиента) - это уже по желанию ( не всегда есть прайс-листы, как мне кажется)

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

"Татаровская Дарья" написал:Я просто считаю, что в ситуация, когда в CRM-продукте в счете нельзя менять цену в коробочной версии, нежизнеспособна

Есть компании, в которых жесткая политика. Но в таком случае всё решается правами на операцию - давать пользователю править цену или не давать.

Да,согласна есть компании, где жесткая политика.
А есть компании, которые работают не с прайсовыми позициями, цена вообще может быть нефиксированной, а может быть своя в каждой спецификации, в каждом тендере.
Так что возможность править в коробке должна быть ( и ведь была в прошлых продуктах-то была).
Чем гибче система, тем лучше. А уже запретить всегда можно было бы при желании. И уж точно скидка никак не на сумму должна применяться, а на цену.
Форма счета, которая в коробке предлагается, тоже вряд ли можно назвать ведь достойной - в ней указывается первичная цена, а не цена конечная, что весьма спорно.

Добрый день всем!!!

тогда уже лучше в продуктах для поля цена ввести понятия "История изменения цен". И в таблице где будет храниться история, ввести понятие базовая цена, т.е признак базовая цена. И все историю изменения цены имеем, для построения тренда. Понятие базовая цена имеем. Вот вам и решение проблемы. Первая мысль что пришла в голову :) Я бы так сделал.

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

"Владимир Соколов" написал:Предлагаю в InvoiceProduct фиксировать цену на момент добавления, и уже пересчитывать в будущем, исходя из неё

Я за данное предложение - в момент добавления товара в счет
фиксируется цена на момент добавления (цена по прайсу).
Ну и
заполняется цена в счете=цене по прайсу по умолчанию.
При необходимости цена в счете должна иметь возможность меняться ( если есть такое право)
Хотим руками меняем, хотим пишем % скидки, цена в счете посчитается как цена со скидкой от прайсовой цены в счете.
И я, на самом деле, нового ничего не придумываю) Это уже было придумано в 3.х Террасофтом, но до 7.х почему-то не дошло.

Коллеги, всем добрый день!

Данные пожелания к доработке уже занесены в бэклог команды Sales (пожелания от наших МРК :smile:)

Планируется к реализации в будущих версиях (ориентировочно в версии 7.8)

Спасибо!

Показать все комментарии

Здравствуйте.
При оформлении заказа, изменяя процентную ставку, к примеру, на 5% расчёт идёт только итоговой суммы. Однако, сама цена продукта остаётся неизменной.
Подскажите пожалуйста, как можно настроить систему, чтобы пересчёт так же осуществлялся и на саму цену продукта, а не только на итог?
Благодарю.

Нравится

6 комментариев

Лучше сделать дополнительное поле "Цена с налогом", нежели менять саму цену

"Владимир Соколов" написал:

Лучше сделать дополнительное поле "Цена с налогом", нежели менять саму цену

Тогда для расчёта этой цены нужно будет создавать отдельный бизнес-процесс

"Ануфриев Дмитрий Юрьевич" написал:Тогда для расчёта этой цены нужно будет создавать отдельный бизнес-процесс

лучше прямо на странице считать, чтобы пользователь сразу при вводе видел изменение этой цены

"Владимир Соколов" написал:
Ануфриев Дмитрий Юрьевич пишет:

Тогда для расчёта этой цены нужно будет создавать отдельный бизнес-процесс

лучше прямо на странице считать, чтобы пользователь сразу при вводе видел изменение этой цены

Вы имеете в виду вручную менять?

"Ануфриев Дмитрий Юрьевич" написал:Вы имеете в виду вручную менять?

нет, java script надо написать

Привет всем!!!

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

Показать все комментарии

В настоящий момент возможна следующая ситуация:
1) менеджер создал счёт в bpm'online, добавил продукты, согласовал цены с клиентом.
2) затем на продукт изменилась цена
3) менеджер открывает счёт, меняет валюту счёта, сохраняет.

В результате система самостоятельно вписывает в счёт новые цены на продукты. Во многих случаях не самая лучшая логика. Как её исправить?

Нравится

2 комментария

Владимир, здравствуйте!

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

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

Спасибо

Добрый день Владимир, Добрый день Артем!!!

в Таблице продукты у нас есть 2 поля Цена, Цена б.в. Базовая валюта, это та валюта которая выбрана как валюта по умолчанию, Я сделал так в своих системах, что если меняют Валюту в Счетах, Договорах, то происходит Пересчет поля "Цена", Цена б.в. (к примеру это рубли) остается без изменений. По умолчанию в системе BPMOnline этот механизм работал и работает ошибочно. Сейчас на память не помню, но если мне пасять не изменяет, то при изменении Валюты система пересчитывала (по умолчанию) поле Цена б.в. а это ни есть правильно. Базовая валюта, это валюта по умолчанию, валюта системы.

Показать все комментарии
Публикация

А сколько стоит всё это?

Нравится

Поделиться

2 комментария

http://terrasoft.ua/software/tscrm30/price/
--------------------------------------------
Лабитек
Центр разработки приложений

Доброго дня, п.Вікторе!

Наша компанія партнер Террасофт у Львові. Ваша компанія - працює у Львівській області.
Можемо провести для Вас презентацію!

З повагою,
Віталій Ковалишин "АйТі-СФЕРА"
--
www.it-sfera.com.ua

Показать все комментарии

Уважаемые коллеги, предлагаю обсудить возможную стоимость CRM-решений. Представим себе абстрактное вертикальное CRM-решение (например, решение партнера группы компаний Террасофт на платформе Terrasoft CRM) для определенного сегмента рынка. К какой стоимости решения готовы клиенты? Какой логикой руководствуются клиенты, когда определяют "справедливая" цена, или не очень? От чего зависят ценовые ожидания клиентов при покупке CRM-системы?

Нравится

5 комментариев

Дмитрий,

не имея длительной истории продвижения Террасофт, тем не менее, обратил внимание на одну любопытную деталь. Цена в Москве(на фоне комплексного функционала, русскоязычной техподдержки, отсутствия ежегодных лицензионных платежей и демократической ТСО,количества внедрений по сравнению с конкурентами, способность к изменению вместе с изменениями в бизнесе) воспринимается НОРМАЛЬНО. Логика руководителей? "Если ПО/решение закрывает все мои проблемы и Вы способны мне это объяснить, я куплю Ваши услуги." Наш опыт говорит, что до 2тыс. евро/1 лицензия в случае проекта воспринимается в качестве справедливой. Плохой эффект мы получаем только в случае "коробочных" продаж (до 1 тыс. евро/1 лицензия), т.к. наш продукт - это, все таки, не "коробка" других СРМ-поставщиков (их продукцию и СРМ-то называть неудобно), но, которая сразу выдает 100% своего весьма ограниченного функционала. Но ведь выдает! А наша "коробка"=сумма функций, сложение которых дает результат, значительно ниже проектного решения. И осваивает клиент (исключения, конечно же, бывают), максимум, 2-4 из них (даже воронку и бизнес-процессы редко кто сам и без помощи способен начать использовать). И даже мы, уже успели ознакомиться с весьма неприятными последствиями такого освоения. В период кризиса многие не готовы на проекты. Но...продавать "коробки" Террасофт в имеющейся сейчас степени готовности стандартной версии, - это просто вредить самому себе :-( Возникает вопрос "ЗАЧЕМ это делать"? Деньги нужны всем и их мало не бывает, но...

Резюме:
- цена должна зависеть от региональной покупательной способности клиента; не должен один и тот же продукт или модель стоить одних и тех же денег в Москве, Ростове-на-Дону и Петропавловске Камчатском; или должен, если нас не интересует доля рынка, а лишь маржинальная прибыль, или только прибыль, или только сейчас;
- одинаковых клиентов/проектов не бывает; но, уже есть база из более 2000 проектов, т.е. можно предлагать модели различной степени готовности и по разным ценам; поскольку есть огромные наработки по программированию стандартных скриптов для решения огромного количества задачек, неплохо бы и этот "багаж" заставить работать на Террасофт (в виде пакетов, дополнений, расширений и т.д. к моделям, продуктам);
- степень "готовности к использованию" модели или "КОРОБКИ" должна быть, как, минимум, 60-70%; с тем, чтобы у пользователя был хотя бы какой-то шанс начать самостоятельное КОМПЛЕКСное использование ВСЕГО функционала, убедиться в том, что это возможно и трудно, а...затем с положительным знаком мотивировало вернуться к своему поставщику за проектом;
- оторванное от остальных возможностей функционала использование клиентами только "контактов", "контрагентов", "задач" ничем не отличает наш продукт от продуктов совсем другого ценового диапазона, (что не в наших интересах); мы должны дистанцировать себя от других и это различие (разница в цене) должны быть четко понимаемо и принимаемо нашей целевой аудиторией;
- коробка "Террасофт" должна иметь конкретную завершенность/степень готовности, создавая "позитивный" фон для торговой марки в целом; "разрыв" между коробкой и проектом не должен определяться отсутствием в коробке "кирпичиков" внутри функционала (скриптов, незаполненных справочников, шаблонов, процессов и т.д.);

- мы должны реагировать на изменение микросреды бизнеса (экономический спад - изменение, в кот. мы живем с сентября 2008 года); мы пока никак не отреагировали...

- в случае изменения среды, если мы принимаем решение НЕ изменять цены, мы должны принять решение радикально ИЗМЕНИТЬ наполнение этой цены, т.е. предоставлять клиентам БОЛЬШЕ за ТЕ ЖЕ деньги (большая степень готовности продукта в стандарте; больше готовых к работе шаблонов процессов, больше шаблонов документов, больше утилит в стандарте, включить стоимость обучения ит-спеца заказчика в стоимость лицензий, интенсивнее и "прицельнее" обучать парнтеров продажам, продукту, моделям, внедрению, конфигурированию). Большинство мировых брендов так поступает, начиная с ноября. У "Террасофта" и всех партнеров есть все шансы последовать их примеру!

Владимир, благодарю за ответ! Вы подняли сразу несколько очень интересных тем.

Тезисно:
1) Цена должна зависеть от региональной покупательной способности клиента.
В теории согласен, это очень логично. На практике - как мы технически будем делать разные цены на лицензии для Москвы и для Ростова-на-Дону? Учтите, что многие наши клиенты присутствуют в нескольких регионах, и вопрос где клиент "находится" на практике неоднозначен.

2) Степень готовности "коробки" должна быть 60-70%%
Абсолютно согласен и поддерживаю! По моему опыту, большинство клиентов не хотят абсолютно индивидуальную разработку, а хотят готовое (но гибкое) решение, уже опробованное в аналогичных проектах. Поэтому мы и стараемся развивать отраслевые решения, и наполняем их готовыми инструментами.

3) Мы должны реагировать на экономический спад
Снова, в теории согласен. На практике - я встречался с клиентами 2х типов. Первый тип, когда есть стратегическое решение срезать ВСЕ бюджеты на развитие. Например, осенью прошлого года был у нас запланирован пилотный проект в крупном московском банке, входящем в top-50 банков РФ. Пилот был совсем маленьким: пару лицензий и обучение ИТ-банка, стоимость пилота была пару тысяч евро, банк хотел за 2 недели провести пилот и принять решение о комплексном проекте.
Наступает кризис и банк стратегическим решением срезает бюджеты вообще в ноль. Понятно, что 2-3 тысячи евро для московского банка вообще не сумма (это и для Террасофт вообще не сумма, я был бы рад провести пилот бесплатно), но вопрос не в сумме, вопрос был в принципе.
Второй тип клиентов - несмотря на экономический спад, инвестируют в развитие. Такие клиенты могут брать более дешевые лицензии (например, Terrasoft CRM X15), могут часть работ поручать своим ИТ, чтобы сэкономить на услугах. Но принципиально у них бюджет на CRM выделен, а значит Террасофт может быть внедрен в рамках этого бюджета, за счет гибкости продукта. Не так ли?

4) мы должны принять решение предоставлять клиентам БОЛЬШЕ
Согласен! У Террасофт есть 22 основных отрасли специализации, и в каждой отрасли у нас есть готовые инструменты, опыт проектов. И мы должны развиваться и развиваемся именно по пути увеличения функциональности и гибкости решений.

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

Данный шаг, по сути, позволяет Вам в 2 раза сократить бюджет клиента на лицензии, так как, по статистике, соотношение конкурентных лицензий к пользовательским - 1 к 3, но цена, кнкурентных выше.

Действительно, мы не спешили с данным решением, необходимо было собрать достаточно информации для принятия взвешенного решения. Но есть такая хорошая поговорка: скорость нужна, а поспешность вредна :)

Еще очень часто можно слышать от клиентов вопрос о необходимости покупки одинаковых лицензий для всех пользователей.

Например, если компании нужна функциональность проведения опросов (чем занимаются 2-3 человека) и репликации для двух пользователей, которые часто работают вне офиса, то X25 приходится покупать на всех, хотя остальные 90% пользуются только функциональностью X15.

То же самое по X25+SD, когда SD нужен реально только отделу сервиса, но не продавцам.

Владимир,

В ситуации Х25+SD сотрудникам сервиса ставится Х25+SD Agent, a продавцам X25+SD User. Стоимость SD User = 29 euro, то есть "доплата" незначительная в сравнении с основной ценой лицензии.

А вот относительно невозможности совмещать 2 типа лицензий (Х15 и Х25) - это маркетинговая тактика, направленная на стимулирование up-sales.

Показать все комментарии