Как отфильтровать список задач по конкретному исполнителю через OData в 1С:Документооборот

← На главную

Работа с автоматическим REST-интерфейсом (OData) в 1С часто преподносит сюрпризы, особенно когда речь идет о сложных конфигурациях вроде 1С:Документооборот. Одной из самых частых проблем является фильтрация задач. Вроде бы данные в JSON видны, GUID известен, но запрос возвращает пустой массив или ошибку несовместимости типов. В этой статье мы подробно разберем, почему так происходит и как правильно составить запрос для получения задач конкретного сотрудника.

Анализ проблемы: почему GUID как строка не работает

Рассмотрим ситуацию: вы обращаетесь к сущности Task_ЗадачаИсполнителя и видите в поле Исполнитель значение типа c01e23dd-3a04-11eb-80c6-cc1a7e589028. Логично предположить, что фильтр $filter=Исполнитель eq 'c01e23dd-3a04-11eb-80c6-cc1a7e589028' должен сработать. Однако система возвращает пустой результат.

Выясним причину. В 1С:Документооборот поле Исполнитель имеет составной тип данных. Оно может содержать ссылку на справочник Пользователи, РолиИсполнителей или даже ГруппыПользователей. Несмотря на то что в метаданных OData свойство может отображаться как Edm.String, платформа 1С внутри себя обрабатывает его как объектную ссылку. Когда мы передаем GUID в кавычках, 1С пытается сравнить строку со ссылкой в базе данных, что приводит к ложному результату или ошибке.

Решение №1: Использование квалификатора guid

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

Если поле в метаданных определено как ключ, мы обращаемся к нему через суффикс _Key. Посмотрим на пример корректного URL:


http://localhost/Doc/odata/standard.odata/Task_ЗадачаИсполнителя?$filter=Исполнитель_Key eq guid'c01e23dd-3a04-11eb-80c6-cc1a7e589028'&$format=json

Важный нюанс: обратите внимание, что мы используем Исполнитель_Key. В 1С OData для ссылочных полей автоматически создается скрытое поле с суффиксом _Key, которое принимает значения типа guid. Именно по нему фильтрация проходит наиболее эффективно.

Решение №2: Фильтрация с учетом типа (cast)

Поскольку поле Исполнитель составное, 1С должна точно знать, в какой таблице искать этот GUID. Если в задаче указано Исполнитель_Type со значением StandardODATA.Catalog_Сотрудники, то и в фильтре желательно это учитывать. Разберем, как применить функцию cast для точного поиска:


http://localhost/Doc/odata/standard.odata/Task_ЗадачаИсполнителя?$filter=Исполнитель eq cast(guid'c01e23dd-3a04-11eb-80c6-cc1a7e589028', 'StandardODATA.Catalog_Сотрудники')

В этом случае мы явно говорим платформе: "Найди мне задачу, где исполнителем является ссылка на справочник Сотрудники с указанным идентификатором". Это исключает неоднозначность при сравнении типов.

Решение №3: Проблема ролевой адресации (Ловушка 1С:ДО)

Если вы применили все вышеуказанные фильтры, но список задач все равно пуст, скорее всего, вы столкнулись с главной особенностью 1С:Документооборот — ролевой адресацией. Рассмотрим подробнее, как это устроено:

Задачи в 1С:ДО часто назначаются не лично пользователю "Белугин М.А.", а на роль, например, "Бухгалтер".
В этом случае в поле Исполнитель будет записан GUID роли, а не сотрудника.
Сотрудник видит эту задачу в своем интерфейсе 1С, потому что он является исполнителем этой роли, но в самой записи задачи его персонального GUID нет.

Чтобы получить "все задачи пользователя" (как в списке "Мои задачи" в самой программе), одного запроса к Task_ЗадачаИсполнителя недостаточно. Нам придется действовать по шагам:

Шаг 1: Получить список ролей, в которые входит данный сотрудник. Это можно сделать через регистр сведений ИсполнителиЗадач или соответствующий справочник.

Шаг 2: Составить сложный фильтр с использованием оператора or, где будут перечислены GUID самого сотрудника и GUID всех его ролей.

Пример структуры такого фильтра:


$filter=(Исполнитель_Key eq guid'GUID_Сотрудника') or (Исполнитель_Key eq guid'GUID_Роли_1') or (Исполнитель_Key eq guid'GUID_Роли_2')

Сотрудники против Пользователей

Проанализируем еще один важный момент. В 1С:Документооборот есть два справочника: Сотрудники и Пользователи. Сотрудники — это кадровые данные (должность, подразделение). Пользователи — это объекты для авторизации в системе.

Часто программисты пытаются фильтровать задачи по GUID из справочника Catalog_Сотрудники, в то время как в бизнес-процессах и задачах используются ссылки на Catalog_Пользователи. У одного и того же человека в этих справочниках будут разные GUID. Всегда проверяйте содержимое поля Исполнитель_Type в ответе от OData. Если там написано StandardODATA.Catalog_Пользователи, то искать нужно по идентификатору пользователя, а не сотрудника.

Итоги и рекомендации

Подводя итог, для успешного получения задач через OData в 1С:Документооборот, рекомендуем придерживаться следующего алгоритма:

Всегда используйте литерал guid'...' вместо простых строк в одинарных кавычках.
Используйте поле Исполнитель_Key для прямой фильтрации по идентификатору.
Убедитесь, что вы используете GUID именно того объекта (Пользователь или Сотрудник), который указан в поле _Type задачи.
Помните про роли: если задача назначена на роль, поиск по GUID пользователя не даст результатов без дополнительной логики.
Для сложных задач по получению списка "Мои задачи" рассмотрите возможность создания собственного HTTP-сервиса на стороне 1С, который будет возвращать уже отфильтрованный по всем правилам (включая роли и делегирование) список.

Эти методы позволят вам избежать типичных ошибок новичков и эффективно интегрировать 1С:Документооборот с внешними системами через протокол OData.