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

Ссылка на файл - https://blog.affcontext.ru/wp-content/u ... лаева.xlsx

Писал в группе партнеров в телеграме, это продолжение той истории - на больших по настройкам аккаунтах крайне необходимо иметь некую структурную архитектуру, чтобы понимать ВСЕ взаимосвязи объектов между собой, а-ля:

• Это поле типа "Запись справочника" смотрит на справочник "ААА"

• Этот сценарий смотрит на такие-то поля, аналитики, справочники и пр.

• Это письмо разбора почты использует такие-то шаблоны, аналитики и пр.

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

И в целом я на проектах для себя уже нашёл решение через Эксель. Оно очень затратное первично на создание файла + немного затрат на поддержание актуальности, но в целом на практике нескольких лет показало себя как очень рабочее. Но вот смотрю на развитие ИИ и есть мысли о том, что если бы ПФ мог в живом режиме делать выгрузку архитектуры в похожем виде, то с ней можно было бы работать не в экселе (особенно если в эксель нельзя так выгрузить), а внутрии ИИ-бота (того же ChatGPT).

И тут я собираюсь показать эти наработки. В аттаче файл, который представляет из себя обезличенную короткую версию этой архитектуры некоего аккаунта, чтобы понять именно суть, как происходит описание взаимосвязей всех объектов. Я понимаю, что там не все возможные настройки описаны, но могу уверенно сказать, что на 95% описанное закрывает потребности развития аккаунта (практика 2х лет). Если бы ПланФикс смог выгружать такие данные даже в Json, то уверен уже ИИ-бот сможет из них и сам сгенерить подобный документ.

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

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

Файл в аттаче + опишу, какие объекты описаны по горизонтали и вертикали:

Настраиваемые объекты (горизонталь):
Шаблон задачи
Шаблон период. Задачи
Шаблон контактов
Шаблон проекта
Текущий проект
Поле задачи
Поле контакта
Поле проекта
Поле сотрудника
Общее поле
Аналитики
Сотрудники
Справочники
Отчеты
Шаблон документа
Шаблон документов экспорта
email - входящие- вирт. почта - ИМЯ почты
email - исходящие - шаблоны писем
Интеграции - telegram
Интеграции - viber
Интеграции - Виртуальные АТС
Интеграции - Сервисы почтовых рассылок
Фильтры задач
Фильтры контактов
Планировщики
Вебхуки
Сценарии задач (всегда оч много данных)
Сценарии контактов

Статические объекты (вертикаль)
Процесс
Шаблон задач
Шаблон контактов
Поля задач (да, оно может быть описано и вертикально, и горизонтально, т.к. само поле тоже может ссылать на другие объекты, например на справочник)
Поля контактов
Поля проектов
Аналитики
Статус
Гр. проектов
Проект
Группы
Сотрудник
Шаблоны писем
Шаблоны документов
Прочие условия
Справочники
Экспорт
API интеграции
Контакты (конкретные ссылки)
Глобальные переменные
Планировщик (конкретные ссылки)
Фильтр задач (конкретные ссылки)

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

ПРО РАБОТУ С ChatGPT
Буквально сделал пару общих запросов к нему с файлом (а там был файл на 2000 строк) + корректировок и смотрите, бот смог в табличной форме вывести нужную мне информацию. Если я дам ему ещё больше вводных + опишу детально структуру файла, он сможет давать очень точные ответы. Это я к тому, что наверняка бот сможет из огромнейшего JSONа со всеми данными по структуре сделать вот такой эксель-файл, а потом с ним даже как-то работать. Возможности тут явно будут.

Круто.

Интересный пример что может ChatGPT.

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

Формат конфигурации должен иметь версию, т.к. представляю что сделать сразу идеально не получиться и будут какие-то итерации: версия 1.0, версия 2.0, и т.д. Это даст возможность развивать формат конфигурации, например,

• в 1-ой версии, закрыть вопрос с пониманием ссылочных связей полей и настроек на эти поля,

• во 2-ой версии, вдруг появились новоиспеченные объекты (а возможно это версия 1.1),

• в 3-ей версии появилось информация о порядке расположения полей в шаблонах,

• и т.д.

Так же я понимаю, что для описания конфигурации данные всё таки нужны. Не все, но некоторые да.
Например,

• В параметрах отбора я отбираю по значению списка - а это данные.

• Статусы - это данные и они нужны.

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

Конфигурация может представлять из себя JSON-файл.

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

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

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

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

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

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

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

- Проблема 1: в аккаунте настройки делают несколько человек. Как понять что изменилось как я ушёл в отпуск? Либо другая похожая ситуация: я технический директор, и у меня есть подчинённый, который большую часть настроек делает. Как мне понимать что он сделал (на прошлой неделе, например), если меня спросит директор?
Тут мне могут возразить: делайте документацию. Но это полу-решение, т.к. является дублированием. И человеческий фактор (забыл отразить в документации) приводит документацию к неактуальной.

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

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

- Проблема 4: при настройке упёрлись в лимит: например, в количество полей. Как понять какое поле можно удалить? Например, количественная характеристика количество связей направила бы администратора в правильном направлении.

- Проблема 5: у меня есть конфигурацию, на момент 15.01.2024 я её поставил клиенту №1, далее происходит развитие конфигурации, и на момент времени 15.02.2024 мы её упаковываем по новому и ставим клиенту №2. Эту логику продолжаем ещё 10 раз. Приходим к ситуации, что клиентов 12, и у всех разная настройка в их аккаунтах. Как мне пройтись по этим аккаунтам и понять какие именно изменения я должен внести в каждом аккаунте, чтобы все 12 клиентов были приближены к версии на момент времени 15.01.2025 ?

- Проблема 6: у меня есть конфигурацию, в этой конфигурации 300 шаблонов, 70 процессов, 600 полей. В одной голове уже нельзя удержать всю эту информацию, не говоря уже о связях, что с чем связано. Как провести рефакторинг настройки аккаунта?

Кейсов можно придумать ещё...

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

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

Всем привет.
На эту тему в 1С есть такое понятие как "хранилище конфигурации".

Что такое хранилище конфигурации в 1С

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

Давайте разберемся более детально. По сути, хранилище – это своего рода копия кода базы 1С, в которой записывается история внесения правок всей конфигурации и отдельных её объектов.

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

Вот простое видео "Принцип работы" https://www.youtube.com/watch?v=sXSeL2Bvrew&t=344s
И такого видео много.

Если мы хотим посмотреть, кто и что изменял в выбранном нами объекте, необходимо воспользоваться историей объекта 1С. В ней хранится информация о том, кто изменял объект, когда и как именно. Также при особых правах можно будет откатиться до определенной версии истории объекта 1С.

Хранилище – очень удобный инструмент, который помогает нам – разработчикам, уберечь себя от ошибок при программировании. Он помогает избежать ошибок как при доработке нового кода в программе 1С, так и при изменении уже существующего функционала. Кроме того, можно всегда увидеть, кто и какие изменения вносил и сравнить их с копией именно Вашего кода и структуры.

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

Есть куда двигаться План-Фикс. Взять идею переработать для План-Фикса. И протестировать с партнерами.

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

Отдельным лучиком подсвечу проблему с api id сущностей. Кажется, создавая конфиг, надо бы как-то "обновлять" id полей для нового аккаунта. Например, в родительской конфигурации поле "руководитель" имело id 100000. При разворачивании в новой конфигурации оно будет точно другим id (например, 10001), и если это поле создается конфигурацией (как правило так и происходит), то было бы логично в сценарии сразу прописать обновленный id созданного поля (текст запроса у нас стандартизирован и кажется это технически реализуемо)

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

А вот если был бы ещё не только экспорт, но и импорт, или мерж (как в 1С сравнение конфигураций), то вообще была бы песня.

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

И сейчас придумал (при наличии импорта или мержа) ещё один кейс конфигурации.

1. Выгружаем настройки аккаунта Планфикс в конфигурацию JSON
2. Берем переводчик, переводим конфигурацию JSON на другой язык
3. Импортируем в новый аккаунт и вуаля