Как в 1С OData отфильтровать работающих сотрудников и получить наименования ссылочных полей?

← На главную

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

Фильтрация работающих сотрудников: способы и подходы

Одной из первых задач при работе со справочником Сотрудники является отсечение тех, кто уже уволен. Сложность заключается в том, что в типовых конфигурациях (ЗУП 3.1, ERP) статус «работает/уволен» является расчетным и не всегда хранится в явном виде прямо в реквизитах справочника. Рассмотрим два основных пути решения этой задачи.

Вариант 1: Использование дополнительного реквизита (простой путь)

Проанализируем ситуацию, когда в конфигурации создается дополнительный реквизит типа Булево (например, ШтатныйСотрудник), который заполняется регламентным заданием. В этом случае запрос через $filter будет выглядеть максимально просто:

ПараметрыЗапроса.Вставить("$filter", "ШтатныйСотрудник_Custom eq true");

Однако этот метод требует внесения изменений в конфигурацию и настройки расписания обновления признака. Если нам нужно решение «из коробки», стоит рассмотреть второй вариант.

Вариант 2: Обращение к кадровым регистрам (профессиональный путь)

В ЗУП 3.1 информация о текущем состоянии сотрудника хранится в регистре сведений ТекущиеКадровыеДанныеСотрудников. Вместо того чтобы запрашивать сам справочник, мы можем обратиться к этому регистру. Выясним причину, почему это эффективнее: регистр уже содержит готовые поля, такие как ДатаУвольнения и ТекущееСостояние.

Пример условия фильтрации для поиска сотрудников, у которых дата увольнения не заполнена (пустая дата в 1С передается как 0001-01-01):


/odata/standard.odata/InformationRegister_ТекущиеКадровыеДанныеСотрудников?$filter=ДатаУвольнения eq datetime'0001-01-01T00:00:00'

Это позволит получить список актуальных сотрудников без создания «костылей» в структуре метаданных.

Получение наименований ссылочных типов через $expand

Типичная проблема при использовании OData: вместо понятного названия (например, «Иванов Иван Иванович» или «Toyota Camry») в ответе приходит техническая строка вида Catalog_ТранспортныеСредства(guid'...'). Разберем по шагам, как «достучаться» до реального наименования объекта.

Для этого в протоколе OData существует параметр $expand. Он заставляет сервер 1С выполнить соединение таблиц и включить данные связанного объекта в основной ответ.

Шаг 1: Расширение выборки

Допустим, у нас есть поле МодельТС, которое является ссылкой на другой справочник. Чтобы получить свойства модели, укажем:

ПараметрыЗапроса.Вставить("$expand", "МодельТС");

Шаг 2: Точечный выбор полей

Если мы просто используем $expand, сервер вернет все реквизиты связанного справочника, что может быть избыточно. Чтобы получить только наименование, используем связку с $select. Рассмотрим подробнее синтаксис:


// Пример для справочника Сотрудники и их подразделений
ПараметрыЗапроса.Вставить("$expand", "Подразделение");
ПараметрыЗапроса.Вставить("$select", "Description, Подразделение/Description");

Важно: В стандартном интерфейсе OData 1С названия стандартных полей (таких как Наименование или Код) часто требуют использования англоязычных синонимов — Description и Code соответственно.

Решение ошибки «Сегмент пути не найден»

Проанализируем ситуацию, когда запрос вроде бы написан верно, но система возвращает ошибку code: 6, message: Сегмент пути Наименование не найден. Это происходит по нескольким причинам:

Регистр имен: OData крайне чувствительна к регистру. Поле description (с маленькой буквы) не будет найдено, если в метаданных оно Description.
Язык метаданных: Если публикация выполнена с использованием английских имен, используйте Description вместо Наименование.
Состав публикации: Если вы недавно добавили реквизит в 1С, он может не появиться в OData автоматически. Необходимо обновить публикацию на веб-сервере (перезаписать vrs-файл через конфигуратор).

Использование системного поля Ref_Presentation

Если ваша задача — просто вывести название объекта в интерфейс сторонней системы и вам не нужны другие реквизиты (код, ИНН и т.д.), в 1С OData есть очень удобное системное поле — Ref_Presentation. Оно возвращает готовую строку представления объекта (то, что возвращает функция Строка(Ссылка) в коде 1С).

Посмотрим на пример запроса:

GET /odata/standard.odata/Catalog_Сотрудники?$select=Ref_Key, Ref_Presentation

Этот способ работает быстрее, чем использование $expand, так как серверу не нужно собирать полную структуру связанного объекта.

Применение строковых функций в фильтрах

Часто возникает вопрос: можно ли передать функцию для условия поиска? В OData 1С реализована поддержка стандартных функций фильтрации. Рассмотрим наиболее полезные:

substringof('Иванов', Description) — найдет всех сотрудников, в чьем наименовании встречается подстрока «Иванов» (аналог оператора ПОДОБНО %Иванов%).
startswith(Description, 'А') — найдет объекты, начинающиеся на букву «А».

Пример использования в коде 1С:


ПараметрыЗапроса.Вставить("$filter", "substringof('Транспорт', Description) eq true");

Подводя итог, можно сказать, что эффективная работа с OData в 1С строится на грамотном сочетании кадровых срезов (через регистры) и правильном использовании параметров $expand и $select. Это позволяет получать чистые, оптимизированные данные без необходимости написания сложных промежуточных обработчиков на стороне 1С.