Цены

02.03.2015 14:24

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

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

Регистр истории цен
Цены меняются, и чтобы отчет по работам выполненным в прошлом месяце формировался по ценам прошлого месяца нужно хранить историю цен. Т.е. у цены должен быть реквизит "дата" начиная с которой она действует. Соответственно изменение цены предполагает добавления в этот регистр новой записи, а не просто взял и изменил существующую цену.

Я понимаю что данный функционал с пол пинка не прикрутить, т.е. там и в отчетах нужно мудрить, и доступы организовывать, ибо некоторым можно видеть только определенные типы цен, но все же хотелось бы чтобы разработчики об этом думали.
Тем более, что есть мысль использовать план фикс в качестве CRM системы, здесь бы цены очень к стати..

02.03.2015 15:46

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

Я готов подсказать предметно по возникающим в ходе настройки вопросам - так что задавайте здесь или задачей на Службу поддержки, как удобнее.

03.03.2015 02:05

1. Оплата сотрудникам. Справился с задачей расчета почасовой оплаты для сотрудников через ставку по виду работ и коэффициент сотрудника. Но опять таки не знаю как сделать стоимость сотрудника (коэффициент) периодическим. Там оставил в комменте вопрос:например в январе у сотрудника был коэффициент 8, а в феврале подняли ему до 10. Нужно чтобы январские работы считались по 8, а февральские по 10.

2. Счета для клиентов. Фактически передо мной стоит такая задача:
Я хочу чтобы клиенты заходили в ПланФикс и видели в отчете на какую сумму мы наработали за период, т.е. из чего складывается счет, который я выставил. Для этого в отчете мне нужно умножать фактически потраченное время не на ставку сотрудника, а на цену клиента (проекта).

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

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

03.03.2015 18:50

1. Оплата сотрудникам. Справился с задачей расчета почасовой оплаты для сотрудников через ставку по виду работ и коэффициент сотрудника. Но опять таки не знаю как сделать стоимость сотрудника (коэффициент) периодическим. Там оставил в комменте вопрос:например в январе у сотрудника был коэффициент 8, а в феврале подняли ему до 10. Нужно чтобы январские работы считались по 8, а февральские по 10.

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

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

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

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

Добавлено спустя 39 минут 16 секунд:
В качестве временного решения для ставок проекта (пока не появятся кастомные поля проектов) можно использовать кастомные поля задач:
- делаем кастомное поле задачи "Ставка";
- заполняем его при создании задачи вручную - или делаем для каждого проекта шаблон задачи по-умолчанию, в котором нужная ставка проекта уже вбита, тогда создавая задачу в этом проекте будем сразу видеть нужное значение в поле "Ставка";
- используем это поле в отчетах для отображения ставки проекта и расчетов.

04.03.2015 17:34

Только увидел дополнение.
Действительно это решает задачу. Кроме того саму ставку проекта я сделал справочником одним из реквизитов которого - дата. Это решает и вопрос с периодичностью.
Теперь если ставка по проекту меняется достаточно добавить в справочник новую ставку и изменить ее в шаблоне, таким образом новые задачи уже будут с новой ставкой.
Прекрасное решение, спасибо!
Нужна фича по копированию шаблонов. Эта прекрасная функция "создать копию" есть уже везде в системе, а в шаблонах нету.

04.03.2015 18:00

Нужна фича по копированию шаблонов. Эта прекрасная функция "создать копию" есть уже везде в системе, а в шаблонах нету.

Да, действительно не хватает ее. В списке доработок она уже есть, обязательно сделаем.

12.05.2015 23:21

Присоединюсь к обсуждению...
Меня тоже особо сильно волнует этот вопрос:

например в январе у сотрудника был коэффициент 8, а в феврале подняли ему до 10. Нужно чтобы январские работы считались по 8, а февральские по 10.

Наш случай.
В команде работает несколько человек. С каждым индивидуальная договоренность об оплате конкретной суммы в час.
Я вижу такое решение. Добавляем каждому сотруднику поле "Стоимость часа" и далее используя аналитики и отчеты делаем подсчет/рассчет....

Проблема. А если договоренность изменится и стоимость часа поменяем, то все ранее сделанные отчеты "поплывут" (((
Как тут быть? Есть идеи???

13.05.2015 15:52

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

14.05.2015 09:48

Какой-то очень не удобный способ решения (((

27.07.2015 22:34

(с надеждой) Как было бы хорошо, если бы в грядущем релизе разработчики добавили и кастомные поля проектов и "периодические" реквизиты
:)

28.07.2015 00:57

+ "периодическим реквизитам"

28.07.2015 12:48

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

28.07.2015 23:26

Периодические реквизиты однозначно нужны, также как и сроки действия связей.
Подробнее по срокам действия связей:
Сегодня контакт является директором в компании N, завтра шофером в компании Y. Неплохо бы чтобы эта информация фиксировалась. Как это видится уже расписывал: кроме просто информации кто с кем связан (контакт такой то в контрагенте таком то и таком то) добавить название связи (по умолчанию просто СВЯЗАН, а для тех кто хочет заполнять, пусть заполняет что угодно текстом, ну или дать возможность выбрать название связи из справочника, примеры названий связей: такой то ЗНАЕТ такого то, такой то ПОЗНАКОМИЛ с тем то, такой то ДИРЕКТОР там то, такая то ХОЛДИНГ с тем то, такой то РОДСТВЕННИК такого то и так далее), а также срок действия с какого по какое, дать возможность не заполнять сроки, тогда связь либо бессрочная, либо с датой с одной стороны. В карточке контакта-контрагента показывать связи по видам: действующие (у которых нет даты завершения связи или она больше текущего момента), прошлые (соответственно дата завершения меньше текущей даты) и будущие (у которых дата начала действия связи в будущем).

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

Если сделаете такое — окончательно будем переходить целиком с CRM и оперативным учетом в PlanFix. Сейчас приходится перекачивать данные еще и в другую самописную и порядком устаревшую систему.

Готов расписать более подробно, если не складывается до конца как это все должно быть.

29.07.2015 13:25

Думаю, что Срок действия должен определятся не специальным реквизитом "Действует по дату", а просто следующей записью с заполненной датой начала действия.
К пример Коэфициент (тариф) для проекта действует начиная с 01/01/2015. Не нужно делать в этой записи дату ограничения. Она и так понятна если мы добавим новую запись с "Датой начала" 01/04/2015. Т.е. первая запись начинала действовать с 01/01/2015 и актуальна для всех задач до 01/04/2015, а начиная с 1-го апреля действует другой коэффициент.

30.07.2015 15:24

Для дат по связям точно нужна ДАТА ЗАВЕРШЕНИЯ ДЕЙСТВИЯ этой конкретно связи.

По прайс-листам мы не работаем, но мне кажется там вообще должна быть другая схема. Есть справочник ЦЕНЫ ТОВАРОВ, в котором есть поля: дата, наименование (которое в свою очередь ссылка на справочник НАИМЕНОВАНИЯ ТОВАРОВ), цена. Обычный справочник. А при добавлении цены товара в накладную мы выбираем не значение из справочника НАИМЕНОВАНИЯ ТОВАРОВ, а значение из справочника ЦЕНЫ (отфильтрованного по наименованию и по дате, вот тут можно дать больше свободы пользователю и дать возможность выбрать, например, любую цену из списка, либо меньше свободы — например автоматически выбирать ближайшую раннюю по дате цену). Мне кажется все это можно и сейчас делать. Единственно в справочники надо бы тогда сделать фильтры, которые бы отбирали сразу цены для конкретного наименования (т.е. получается при вводе накладной зависимые фильтры) и реализовывали алгоритм отбора цен: все цены за весь срок или только последнюю цену, или цену близкую к конкретной дате документа.

04.08.2015 13:48

+ допиливанию справочников!

04.08.2015 20:28

Либо уже прийти к тому с чего начинали: справочники вообще убрать, а всю дополнительную функциональность справочников дать тому, что сейчас называется ЗАДАЧА. Как говорится уменьшить количество сущностей. Сущность ЗАДАЧА переобозвать как то по другому. Это если кардинально подойти.

05.08.2015 11:36

Такой вариант, кстати, давно предлагает Тимур Халфин. Но мы пока держимся на позиции сохранения этой сущности.

05.08.2015 18:18

Если посмотреть на "Базовые принципы" https://blog.planfix.ru/ideologiya-planfiksa-2015/ то окажется, что справочники это такой фильтр для задач :) :) :), а эти задачи сделаны по шаблону в котором есть кастомные поля соответствующие полям справочников как они есть сейчас.

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

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

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

Добавлено спустя 9 минут 45 секунд:
Можно даже снаружи оставить все как есть, но чтобы функционал взаимно обогатился.

Добавлено спустя 7 минут 34 секунды:
Название кстати можно дать: ЗАПИСЬ (расширенное — ЗАПИСЬ ДАННЫХ), раз уж у нас есть ПОЛЯ. Вполне вроде бы устоявшийся термин для набора значений полей.

Добавлено спустя 1 час 27 минут 39 секунд:
Даже контакты полностью сходятся :)
У них есть и Дата начала и Дата завершения. (Здесь должна быть картинка с диаграммой Ганта на годы жизни Толстого, Лермонтова и Пушкина).
И исполнители имеются, и подзадачи есть!!! дети, внуки, друзья и вообще связанные контакты.

Цены

Нужно?

Цены