Форум сервиса Планфикс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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