Автоматизация запросов и телеграм-рассылок в PlanFix — кейсы и решения

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

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

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

Ситуация следующая. Есть несколько тысяч объектов, объединенных одним значением. Это подъезд, да? Вот возьмем подъезд дома. 6 тысяч подъездов, в которых есть некие кастомные поля. В данном случае это обозначение городского округа. Балашиха и Воскресенск, неважно, городской округ. То есть в одном округе 20 подъездов, в другом 500 подъездов в этом проекте.

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

Сейчас появился запрос на получение информации полностью, например, по городскому округу. Ответственное лицо округа пишет слово «справка», например, да, там, «справка подъезда», все что угодно. И мы бы хотели вернуть ему Word-овский файл, Word-овский, Excel-овский, неважно, с перечнем всех подъездов, ну, всех задач, которые имеют отношение к его городскому округу, который там прописан в кастомном поле Балашиха.

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

Вот именно вопрос такой: как можно по кастомному полю изменить множество задач? То есть Планфикс предлагает или в одном дереве, или конкретную, или задачи из поля, да? Но прописывать там 500 задач в какую-то задачу, в задачу из поля, как-то для меня это тупиковая ветка получилась. Над задачей тоже не получается, потому что, ну, то есть, Балашиха, и в ней, там, 50 подзадач, там, или 500 подзадач. Тоже пробовал, не схлопывается логика, потому что таких кастомных полей может быть много. По городскому округу, по управляющей компании, по типу дома, да, то есть вот можно ли в Планфиксе по кастомному полю изменить задачи?

Давайте я проверю прямо на ходу одну из гипотез. Насколько я помню, есть вариант задачи в одном проекте в текущие соответствующие условия. По-моему, есть такой вариант. Мне кажется, он вам подошел.

На ходу проверить историю процесса задач, новый сценарий, операции, изменить другие задачи. Так, задачи в одном дереве с текущей соответствующей условием точно есть. Задачи в одном проекте с текущей соответствующей.

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

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

Поле равно Балашиха? Да.

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

Почему? У меня же тоже.

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

Нет, смотрите, у меня... Да, вот давайте попробуем, раз уж со мной разговор пошел.

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

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

Я даже смотрел такое видео ваше.

Вот. Там, получается, в зависимости от того, какие есть на данном исполнителе задачи, формируется облако меток. Ну, в вашем случае, соответственно, облако меток там будет Балашиха, еще что-то, еще что-то.

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

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

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

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

Этого действия, то есть добавлен комментарий, и измени вот в такой задаче. Ну, давайте так, упрощая, чтобы задачу с телеграммом, куда пришло слово «справка», каждая задача, которая сейчас мы подобрали, и она совпала, да, по Балашихе, изменила именно ту задачу, в которую пришел запрос.

Конечно, ставите соответствующее буферное поле.

Ну, да, будет задача.

Пишите, да, эту задачу. Дальше идет проверка на совпадение. Если все совпало, то передаете информацию, задачу из этого буферного поля, и потом обновляете, естественно, очищаете это буферное поле в следующем действии. А если не совпало, просто очищаете. Нет, нет, нет, нет. Это информация.

Это понятно. Немного неудобно, что я вас отвлек со сценарием. Да, я просмотрел в одной задаче, в одном проекте с условиями.

Вот, ничего страшного. Мы, в принципе, здесь все собрались сегодня.

Не, ровно для этого мы здесь и собираемся. На самом деле, поэтому все отлично.

Спасибо, коллеги.

Если у вас... Да, понадобится обязательно.

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

Оно, в принципе, собирается, но там не получается их сложить по времени, ну, там, по полю, да, кастомному время, время мероприятия, чтобы они были все ровно там с 10 до 19, грубо говоря. То есть она создала там 8 задач, которые на завтра, и сейчас мы вынуждены выгружать отчет, загружать его обратно в PlanFix, чтобы оно уже выстроилось по порядку.

Мы пытались там с одним из интеграторов, там это очень дорого для нас оказалось, что через сервер он забирал все эти задачи, у себя их устраивал и обратно отдавал. То есть есть 10 задач, которые могли быть созданы не вчера, не сегодня, а некоторые сегодня. Соответственно, их номера и даты создания и так далее, они совершенно разные, не зависят от времени завтрашнего мероприятия, именно времени.

Вот можно ли их как-то собрать и вывести? Ну, опять, телеграмму руководителю отправить, поведомляем вас о мероприятиях на завтра. И там уже именно 10, 11, 12 и поехали.

Кирилл, пожалуйста.

Правильно ли я понимаю, что руководитель в PlanFix не работает?

Руководитель работает в PlanFix, но ему очень понравилась идея, что он в Телеграме вечером в 8 вечера получает, там, Иван Иванович, уведомляю вас о мероприятиях на завтра. Очень красивое расписание на завтра.

Пока оно делается руками, но он тоже не всегда в PlanFix. Он довольно-таки разъездной сотрудник. И, ну, неудобно, наверное, даже и в планировщике в мобильном приложении. Ему очень понравилась идея с Телеграмом. Может быть, к сожалению, но так вот сложилось.

И пока это вот действительно через отчет мы импортируем аналитики. Аналитики выстраиваются так, как нам надо, и уже отправляют ему сводные данные. Вот такой костыль-костыль в автомате.

Интересно, как это можно? Хотя бы в какую сторону можно посмотреть, подумать?

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

Костыль – это когда у нас есть некое временное решение, которое стенку подпирает. Но мы знаем о неком лучшем решении или идеальном, но пока мы не способны его сделать. А если нет, то это вполне себе решение.

Принято.

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

Вопрос только, нумерацию правильно придумать по времени. В этом и вопрос.

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

Вот у тебя вчера появилась задача на 14:00, совещание. Сегодня появилась еще новая задача на 13:00. И как правильно пронумеровать вчерашнюю и сегодняшнюю задачу?

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

Ну, то есть, при создании мероприятия, отправлять данные в аналитику. Не знаю, я так пытался.

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

А как мы узнаем, что дата мероприятия завтра?

Есть конкретное поле, в котором написано дата и время мероприятий.

А у нас много таких руководителей, которые хотят?

Один. Один.

И, соответственно, задача Telegram у него тоже одна с ним.

Да, да.

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

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

Прекрасно.

Вы сейчас рекомендуете по одному, да? Их присылать в 6 часов вечера?

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

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

И вот все они начинают дружно утром кидать всю эту информацию. Если там накопится эта информация, ровно в 18:00 сценарий кидает содержимое этого поля в этот чат.

Степан, там тоже секретарь может сегодня, ну допустим, сделать сначала мероприятие на 10 часов. Вы имеете в виду, что он в какой-то момент времени начнет по времени смотреть, что у него в 10 утра это первое сработает?

Нет, кинем мы в 18:00, а накапливать мы будем…

А если она в 17.50 добавит мероприятие, которое на завтра на 9 утра? Оно уже не будет минус час, минус сутки, оно не сработает.

Почему?

Ну, а как оно сработает, если оно… на завтра, на 9 утра, но уже минус сутки уже проскочили? Через 12 часов мы будем совещать.

Нет, там один день. Ну ладно, хорошо. Завтра. Дата. У нас есть такая опция с датами. Дата равно завтра. Задача создана и соответствует условиям. Равно завтра. Она же, они дважды не попадали. Придумайте тег какой-то, который будет добавляться, добавлена в отчет заказчику, но там кому-то она же.

Допустим, вот есть расписание, отличное течение дня. Завтрашние все сработали, добавились до задач на 10, на 11, на 12.

А если секретарь в 17:50 добавит новую задачу на 9 утра, то она попадет в конец текстового поля, и там не пойдет. Да и она не будет в расписании, как бы она не будет вот именно по часам расписания директора, не по часам. Просто набор мероприятий. Ну, да не стоит заморачиваться.

Просто все задачи прислали ему 8 сообщений. У вас так, так и так. Именно вот чтобы 10 часов, 11, 12. Тут мы логику потеряли.

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

Ну, там уже webhook надо использовать.

Ну, вот. Можно точно так же сделать, если мы.

Создали мероприятие. Изменяется задача назад, она уже ранее создана. В ней создается аналитика, потом сценарием. Выгружаем в поле аналитику, сортировку... Я.

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

А сейчас ему просто в Telegram кидают, что у него когда. Если мистер секретарь может зайти в чат в 17:55, когда он понял, что он уже всё сделал, я думаю, для него не составит проблемы в текстовом поле строчки местами поменять, чтобы они улетели качественно. И таким образом они пойдут ровно так, как ему надо.

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

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

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

Он в приложении же увидит план фикса. Можно, в принципе, скидывать сообщение, что в приложении у вас по порядку будет.

Нет, но это прикольная конструкция, когда ты получаешь такое уведомление. Единственное, что вот эти даты и время, что, скажем, мероприятие на 18:00 будет раньше, чем мероприятия на 9:00.

Ну, можно с этим играть, но стоит ли овчинка выделки, что человеку... Ведь когда...

Мы создаем документ по шаблонам. Мы разве не можем, ну вот, из аналитики, да, Word-овский файл или там Excel-овский? Разве там нет сортировки сразу? Аналитики могут сортироваться в момент создания.

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

Поэтому, если нам неудобно с файлами и сортировками, давайте придумать решение. Пусть он пожалуется, что вот они не отсортированы ему в этом сообщении как надо. Хорошо. Напрягаем нашего секретаря, который зарплату получает за это. Мы, дорогой, тебе упростили историю одну. Может быть, ты справишься с работой сортировки строчек внутриадного текстового поля? Если он справится, молодец. Не справится, ну, наверное, он должен прям возопить, как же справиться с этой задачей.

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

Такую штуку можно сделать. И она все равно сформирует список, вот этот список в текстовом поле, чтобы кинуть этому человеку в сообщении. Ну, сложновато. Мне кажется, ни один нормальный начальник ругаться не будет за то, что история упрощена. Если у нас другой кейс, ну, текстовое поле доступно для редактирования секретарю. Он сможет справиться.

Ну да, там тоже можно сделать ему расстелитель, чтобы он не мучился.

Да, коллеги, наверное, вы правы.

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

Копируйте и вставьте: Ctrl-X, Ctrl-V, и все.

Да-да, на мой взгляд, ничего страшного в этом нет.

Ну да, зато мы будем делать отчеты, которые мы сейчас формируем. Это проще будет намного. Спасибо, коллеги.

Слушай, Степан, у меня к тебе вопрос. Мы же, получается, через API можем искать, даже через WebHub, наверное, какой-то определенный фильтр. У нас же фильтр — это, по сути, ссылка.

А если мы будем, например, создавать эти задачи и присылать им какой-то признак, чтобы они соответствовали этому фильтру задач, а внутри будет устраивание по какому-то номеру, мы сможем потом этот фильтр обратно готовый выгрузить в какой-то момент времени? Уже в правильном порядке или нет?

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

И если там сортировка задач в этом фильтре будет передаваться в ответе, но аппетит его будет прикольным. Надо попробовать. Задача довольно, на мой взгляд, редкая, и она скорее, так сказать, аппетит приходит во время еды.

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

А что придет ваше предпоказание?

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

Всегда все с чего-то начинается.

Да, я вам там в чате кинул кнопки в Ватсапе. Мне сегодня прилетело интересное. Посмотрите, вот прям даже интересно. Ватсап и прочее умеют такое делать?

То есть, ты по аналогии с Телеграмм. Так у них же API закрыт или открыт все-таки WhatsApp?

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

А, это тебе прислали? То есть, какой-то бот, написанный, что ли?

Да, да.

Я думал, это ты сделал уже.

Не-не, это мне пока интересно стало.

Похоже, не тем ты задал ребятам вопрос.

Не, ну мало ли, может, вам тоже понравится идея.

Мне идея понравится, вопрос реализации.

Я тоже пока не знаю, как это реализовать. Ничего страшного.

Не знаю, если хотите. Это решение кейса клиента конкретного, который использует функционал автоответов для своих клиентов. Пока прототип, сразу скажу. В общем, кейс такой. У них есть в справочнике некий загружен пул ответов, которые сейчас в существующей системе. Другой, не в план фиксе. Control-C, Control-V вставляют комментарий вот такого типа и отправляют. Соответственно, перед этим им нужно там около 4-5 значений, максимум, не очень много, заполнить руками. И потом только отправлять.

В FunFix похожая история возможна, то есть реализуется через запись справочника. Кстати, узнали, что если нам сразу же нажимать, вставить... Ты откроешь доступ к этой записи справочника. Вот. А если провалиться на один уровень внутрь, то мы можем непосредственно вставить текст. Для себя эту фичу открыл.

В общем, первое решение, которое мы предложили, это аналог существующей системы. Конкретно вот эта вот фича, это не из-за того, что они выбрали план фикс, поэтому в этом плане клиент согласен и на то, чтобы использовать в таком виде. То есть он вставляет какой-то заранее заготовленный текст, берет там номер счета, посмотрит менеджер, 555, приложит файл и отправит сообщение. Оно улетит на почту. Хотелось бы придумать более автоматизированный вариант.

В первом варианте это работало так. Мы выбирали через поле запись справочника некий ответ для клиента, например, запрос в работе. Он здесь в кнопке добавляет комментарий, берет текст этого ответа, автоответа, и отправляет сразу же на клиента. Но единственная сложность в том, что мы вот эти все поля, которые у нас заполняются из задачи, можем добавлять уже только при отправке в кнопки. То есть мы не можем их прямо в тексте вычислить. У нас, соответственно, этот блок всегда будет идти после самого ответа и справочника.

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

А в чем некрасивость? В пустых полях или в чем?

Да, в пустых полях. То есть, например, смотри, мы должны здесь для того, чтобы быстрый ответ отправить, чтобы не делать control-c, control-v, должны сделать некую маску. То есть, здесь у меня будет счет, потом я здесь заполняю переменную Задача, точка, счет.

Потом, например, у меня следующее будет накладная. Здесь у меня будет задача, точка накладная. И, например, если у нас 15 записей справочника с разными значениями, у нас хвост этот вырастает.

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

А почему ты не хочешь использовать "вычислить"? Просто вычисли какое-нибудь буферное поле, вставь туда все, что тебе надо.

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

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

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

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

Если поле счет номер больше или равно нуля, или еще что-то, zen, точка с запятой, ты вставляешь счет номер такой-то. Собрал вот эту фразу. Если нет, то дальше по формуле идешь.

Ну, возможно. В общем, я решил по-другому. Немножко посложнее хотел показать.

Давай, давай.

В общем, у меня здесь выбирается вопрос. Это вот записи справочника, и вот для наглядности здесь вытаскивается из справочника текст этого вопроса. Здесь некий такой, назвал парсером, не знаю, сколько это правильно, но так назвал. Вот и работает так. То есть сейчас у нас буферное поле тек содержит некую метку в своем тексте, ставка срок, а внизу уже то учисляемое поле, которое пойдет к нам в ответ на кнопку. В данном случае у нас всего лишь одна. Здесь подтверждение заказа. У нас тоже одно. Хорошо, тоже посчиталось. Теперь товар готов к отгрузке. Здесь уже две. Все, подставила две переменных. Отгрузка заказа. Ага, ну вот. Да, тоже все посчиталось. Я сделал вот так. Ну, по сути, очень похоже, что вы предложили, только вычисляется в другом месте. Вычисляется в аналитике. Я под каждую запись создаю аналитику, которая состоит из, по сути, вычисляемых полей. Вся аналитика, ну, кроме первого. Первый отсюда исходник. Дальше она уже смотрит... там вообще много текстовых форм. Она смотрит, что пришло на входе. Если там содержит какое-то из значений нужных нам, да, старт для проверки на срок, единичка, она вычисляет. Потом, если нет, то передает просто сроку дальше, исходную, и так далее. То есть в конце концов мы забираем в конце вот этот ответ уже с переменными, которые содержатся внутри текста, а не снаружи. То есть тут фишка в том еще была, что мы, если делаем, даже как вы предложили, через вычисляемое поле, мы в любом случае маску будем высчитывать снаружи. А здесь считается прям в тексте.

Это же опять же вычисляемое поле аналитики. Оно может, он может стрельнуть потом у тебя отдельно. Так-то работает, но до момента x-пересчета аналитики не впопад. То есть жесткая система должна быть. Но с другой стратой тоже работает.

У меня это страхуется двумя вычислениями. Ну, повторный просто вызов пересчета полей аналитик.

Диман, а сколько это масштабирует?

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

То есть, практически под каждый шаблон ответа отдельная аналитика, которая отдельно считается?

Нет, они же повторяются здесь. Вот смотри, например, вот в этом вопросе у нас две переменных, но они примерно одинаковые везде.

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

И в конце концов, соответственно, это увеличивает скорость ответа. Нам не нужно ничего делать. Ctrl-C, Ctrl-V. Мы выбрали нужную запись и нажали на кнопку.

Нас портят, что приходит такой ответ в таком виде. Здравствуйте. Текст вычислен на наш. И там подпись внизу.

Да, ты не воспринимай наши нападки, что ты плохо сделал.

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

Для примера, почему это сложно: например, у нас вычисляется функция "если" может только с двумя параметрами, то есть или это, или это. А у нас вариантов намного больше, чем два.

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

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

Ты считаешь, что если двумя аргументами тебе сейчас сложно, то есть более сложные ситуации, в которых точно сложно?

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

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

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

Оно может долго вычисляться.

Но у меня там немного, ты видел. Но тем не менее... У меня вот.

Есть пример с 18 вложенными "если", и вот ты просто дернул чуть-чуть аналитику, понеслось вычисление, и несколько полей все это дело вычисляют. Зато это работает очень удобно, строить.

Это забавно, да? Согласись, сколько часов уходит.

На эту руку набить на эту механику, да.

Я, кстати, еще кейс у меня был. Вычислял для одного клиента ссылку для оплаты, которая смотрела в поле типа контрагент. Смотрела, откуда он там: Украина или Россия, или Белоруссия, какая у него карточка. В общем, все эти условия сопоставлял и в конце концов выдавал результат. Это не 19 вложенных "если", но тоже весело было.

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

Прекрасно.

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

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

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

На каждом этапе контролируешь…

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

Я просто имею в виду, когда ты уже выстроил бороду большую, тебе говорят: вот там у нас было 12, а нужно поменять на 10. Или там было синее, а нужно поменять на красное. И тебе нужно везде эту десяточку правильно вычислить.

Если у тебя почесовка, почему нет?

Объяснить потом, что ты менял визу на мастер-карт двое суток.

Ну, да, да, ребят, а вы думали, что мы тут что, в бирюльки играем, что ли?

Ну что, закругляем официальную часть? Как вы?

Давайте так. В нынешнюю пору доброжелательность в выставленной комьюнити Palm Fix'а особенно ценна.

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

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

Спасибо всем, кто пришел, спасибо всем, кто посмотрел.