
ELMA365 CSP — лидер рейтинга ИИ в СЭД
Аналитики оценили решения по 50+ критериям, охватывающим ИИ-функциональность, возможности, безопасность и зрелость.
В летнем релизе команда ELMA365 CSP сосредоточилась на ежедневных задачах пользователей: упростили работу с файлами и версиями документов, улучшили поиск, расширили возможности автоматизации процессов и добавили новые инструменты для эффективной договорной работы.


Частая ситуация: сотрудник работает над документом, вносит правки и сохраняет промежуточную версию, но коллегам важно видеть только финальный вариант. При этом предыдущие версии всё равно нужно сохранить в истории, чтобы при необходимости к ним можно было вернуться.
Раньше версии файла не имели полноценной статусной модели, поэтому было сложнее быстро определить, какая из них находится в работе, а какая – уже не используется. Это создавало риск случайно выбрать не ту версию и усложняло работу с историей изменений.
Теперь каждая версия файла имеет понятный статус: «Текущая», «Устаревшая», «Черновик» или «Удаленная».
В виджете «Все версии» можно быстро отфильтровать версии по статусу: черновик не отображается другим пользователям в форме просмотра и задачах согласования, пока он не станет текущей версией, а устаревшую версию можно вернуть в работу или использовать как основу для новой версии.
Это помогает контролировать жизненный цикл файла, не смешивать рабочие и финальные версии и снижает риск ошибок при работе с документами.
Функциональность особенно полезна при активном редактировании и согласовании документов: автор может спокойно работать над черновиком, а коллеги всегда видят актуальную версию, сохраняя при этом возможность быстро вернуться к предыдущим вариантам.

Удаление версии файла не всегда означает, что от неё нужно избавиться навсегда. Особенно важно сохранить возможность вернуть документ, если версия была удалена случайно или понадобилась для работы с историей изменений.
Ранее удаление версии приводило к её окончательной потере. Пользователю приходилось особенно внимательно проверять свои действия, поскольку восстановить ошибочно удалённую версию было невозможно.
Теперь удалённые файлы перемещаются в отдельную вкладку в виджете «Версии документа».
Оттуда их можно восстановить в любой момент, а если версия действительно больше не нужна — удалить окончательно после дополнительного подтверждения.
Такой подход снижает риск безвозвратной потери данных и делает работу с версиями более безопасной и предсказуемой.
В результате пользователи получают больше свободы при работе с историей изменений: можно не опасаться случайного удаления и при необходимости быстро восстановить нужную версию.

Отдельный файл редко существует сам по себе — чаще он относится к договору, проекту, заявке или другому рабочему объекту. Когда коллега получает ссылку только на файл, без контекста бывает сложно понять, к чему он относится и где искать связанную информацию.
До появления этой возможности пользователю приходилось самостоятельно искать в системе элемент, к которому прикреплён файл. Это добавляло лишние шаги, особенно если документом поделились напрямую и его происхождение было неочевидно.
Теперь на боковой панели файла отображается ссылка «Связанный элемент». Одного клика достаточно, чтобы открыть карточку договора, проекта или заявки на обслуживание, к которым относится файл, и сразу получить полный контекст работы с ним.
Благодаря доработке удалось сократить время на поиск связанной информации и снизить риск работы с файлом без дополнительного контекста.

При работе с объёмными PDF-документами нужную информацию не всегда удаётся найти быстро: если файл содержит десятки или сотни страниц, скроллинг всего документа может занимать слишком много времени.
Просто представьте, документ на 100+ страниц, а вам нужно найти информацию на 37 странице, как указано коллегой в комментарии или в оглавлении документа.
Ранее для поиска приходилось скроллить весь документ, пока нужная страница не отобразится.
Теперь в стандартном PDF-просмотрщике достаточно указать номер нужной страницы — система сразу откроет её. Не нужно последовательно пролистывать документ и искать нужное место вручную.

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

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

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

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

В сложных документах может понадобиться указать нескольких пользователей, несколько файлов или сразу несколько значений категории. Раньше такие данные было сложно корректно представить внутри табличной структуры документа.
При формировании документов по шаблонам значения из полей типа «несколько» не удавалось выводить непосредственно в таблицах.
Теперь данные из полей с множественными значениями — пользователей, файлов, категорий и других типов — можно выводить прямо в таблицах при генерации по шаблону.
Например, в таблице можно указать сразу нескольких ответственных сотрудников или прикреплённых к конкретной позиции файлов, сохранив всю необходимую информацию непосредственно в сформированном документе.

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

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

При интеграции с контрактами через Web API не всегда требуется загружать весь объём данных. В одних сценариях достаточно нескольких конкретных полей, а в других — важно сразу получить всю связанную информацию, не выполняя дополнительные запросы.
Ранее при работе с контрактами возможности управления объёмом загружаемых данных были ограничены. Это могло приводить к лишним запросам и дополнительной обработке данных со стороны интеграции.
Теперь Web API поддерживает два варианта загрузки данных по аналогии с обычными приложениями: можно запросить только необходимые поля или сразу загрузить все связанные данные.
Это позволяет точнее адаптировать интеграции под конкретный сценарий, сократить количество избыточных операций и повысить скорость работы с данными контрактов.

При настройке контрактов важно, чтобы данные из разных источников корректно связывались между собой. Если типы полей не совпадают, администратору может потребоваться менять структуру приложений даже тогда, когда существующая архитектура уже соответствует бизнес-сценарию.
Ранее поле типа «Приложение» в источнике контракта нельзя было сопоставить с полем типа «Произвольное приложение» в самом контракте. Из-за этого для корректной работы приходилось искать обходные решения или менять архитектуру приложений.
Теперь эти типы полей можно напрямую сопоставлять при настройке источника контракта. Связанные элементы корректно отображаются в контракте без дополнительных изменений структуры приложений.
Это делает работу с контрактами гибче и снижает объём технических доработок при настройке системы.
В результате администраторам проще адаптировать контракты под существующую архитектуру приложений, а необходимые данные остаются доступными пользователям в привычном виде.