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

Почему Аналитики можно группировать только в корневом разделе?
Внутри корневых групп кнопки "создать группу" нет.

Да, мы посчитали что для Аналитик и Отчетов одного уровня будет достаточно.

Если это не связано с текущими технологическими ограничениями, то такое решение вызывает вопросы:

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

Нет единообразия: Справочники можно по каталогам распределять, а Аналитики нельзя, почему?

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

А с какой ситуацией Вы столкнулись, что захотелось прятать аналитики внутрь дерева групп? Опишите кейс, если можно. А то мне это пока все еще кажется излишеством.

Описание ситуации:

Мы решили сделать документооборот на основе Аналитик, как вы посоветовали: http://forum.planfix.ru/viewtopic.php?f=6&t=1564

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

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

Сделал Аналитику с полями: "документ" "№" "контрагент" "состояние" "дата поставки" "исполнитель" "сумма" "краткое описание" и др.

Снабженец видит заказ, находит поставщика, забивает его в список контрагентов с реквизитами и т.п. (если его не было в списке),
после получения счета делает комментарий, к которому прикрепляет счет и Аналитику:
"документ - счет" "№25" "ООО "Бурый медведь" "состояние-выставлен" "дата поставки - 01.01.2013" "исполнитель" "сумма-100 руб." "кабели 10 шт."

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

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

Все работает хорошо, но есть неудобства:

При каждой операции надо заполнять Аналитику, а в ней выбирать контрагента.

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

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

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

Еще один аргумент - меньше запоминать частных случаев, удобнее внедрять.

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

Еще пожелания:
При создании Аналитики нельзя указывать поля, обязательные для заполнения, как в справочнике. Это было бы удобно.

В выпадающих списках нет возможности не выбирать ничего. Это полезно для привлечения внимания при группировке в отчетах: например, я группирую по типу документов, получается список папок: счета, платежки, накладные, ошибка. Если тип не выбран, то соответствующая запись будет в корне - сразу привлекает внимание к ошибочным документам - в папку "ОШИБКА" не каждый полезет. Эту возможность можно отменить выбором предыдущего пункта при создании Аналитики.

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

Тимур, спасибо за развернутое описание кейса, впечатляет.

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

Раз случилась такая оказия, сразу выделяю отмеченные неудобства для того, чтобы создать задачу на исправление:
1. В аналитике переименовать реквизит Клиент в Контрагент (это атавизм, когда-то Контрагенты везде в ПланФиксе назывались Клиентами).
2. Для работы с реквизитами аналитики типов "Список", "Сотрудник", "Клиент" использовать тот же контрол выбора, который работает в Справочниках.
3. Сделать возможность указывать в Аналитике поля, обязательные для заполнения.
4. Сделать возможность не выбирать значения реквизитов аналитики типов "Справочник", "Список", "Сотрудник", "Клиент" при вводе аналитики.

Если что-то не учел - поправьте меня.

Теперь непосредственно к первоначальной теме, по поводу вложенности аналитик. Как она помогла бы Вам в данной ситуации?

Да я сам после написания заметил, что к теме описанный кейс имеет отдаленное отношение. Просто мы периодически обсуждаем вопросы организации документооборота, товарооборота и производства с помощью ПланФикса и Аналитик и похоже, Аналитик потребуется много, значит проблема их систематизации возникнет, как возникла аналогичная проблема с Контрагентами. Ну а если планировать решение так уж сразу с единым подходом для всех. (Это не означает, что надо делать все одновременно). Вот такая простая логика.

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

возможность п.4 отключается если выбран п.3.

в отчетах при группировании по пунктам "список" и т.д. элементы с пустым реквизитом помещаются на одном уровне с группами списка (т.е. в корне)


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

ОК, уточнения добавил.

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

Еще вопрос: почему настраиваемые поля у Контрагентов отличаются от полей справочников?
Например, хочу сделать поле "р/с", чтобы это было число, во избежание ошибок.

Еще поля, обязательные для заполнения сделать желательно - иначе путаница будет.

Контрагенты - тот же справочник, только с доп. функциями. Может не стоит другие функции урезать?

Добавлено спустя 2 часа 6 минут 9 секунд:
ВОПРОС по складу: не будет ли ограничений по быстродействию системы? Или ограничения связаны только с функционалом?

Еще вопрос: почему настраиваемые поля у Контрагентов отличаются от полей справочников?
Например, хочу сделать поле "р/с", чтобы это было число, во избежание ошибок.

Еще поля, обязательные для заполнения сделать желательно - иначе путаница будет.

Контрагенты - тот же справочник, только с доп. функциями. Может не стоит другие функции урезать?

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

ВОПРОС по складу: не будет ли ограничений по быстродействию системы? Или ограничения связаны только с функционалом?

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