При разработке или доработке сложных интерфейсов, таких как Контакт-центр в конфигурации 1С:Управление нашей фирмой (УНФ), программисты часто сталкиваются с ситуацией, когда запрос идеально работает в консоли запросов, но выдает ошибку или пустой результат при попытке отобразить данные в динамическом списке на форме. Рассмотрим подробнее, почему это происходит и как правильно диагностировать и устранять подобные ошибки.
Проанализируем типичный запрос, который используется для вывода данных из различных источников (записи календаря и задачи сотрудников) через конструкцию ОБЪЕДИНИТЬ ВСЕ. Основная сложность динамического списка заключается в том, что в отличие от обычной таблицы или отчета, ему требуется четкий механизм идентификации каждой строки для корректной работы позиционирования, выделения и обновления данных.
В представленном примере запроса мы видим следующую структуру:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
ЗаписиКалендаряСотрудника.Источник КАК Ссылка,
ЗаписиКалендаряСотрудника.Ссылка КАК ЗаписьКалендаря,
...
ЗадачаСотрудника.Теги.( Тег КАК Тег ) КАК Теги,
...
ИЗ
Справочник.ЗаписиКалендаряСотрудника КАК ЗаписиКалендаряСотрудника
ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЗадачаСотрудника КАК ЗадачаСотрудника ПО ...
ГДЕ ...
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ЗадачаСотрудника.Ссылка,
ЗНАЧЕНИЕ(Справочник.ЗаписиКалендаряСотрудника.ПустаяСсылка),
...
ЗадачаСотрудника.Теги.( Тег ),
...
ИЗ
Документ.ЗадачаСотрудника КАК ЗадачаСотрудника
Разберем по шагам, какие критические ошибки здесь присутствуют и как они влияют на работоспособность формы.
Самая частая причина, по которой динамический список «отказывается» работать — это невозможность однозначно идентифицировать строку. Посмотрим на поле Ссылка в первой части запроса. Здесь используется ЗаписиКалендаряСотрудника.Источник.
Выясним причину ошибки: Если у одного документа-источника (например, задачи) создано несколько записей в календаре, то в итоговой выборке поле Ссылка будет содержать дублирующиеся значения. Платформа 1С:Предприятие при получении таких данных для динамического списка теряет возможность определить, к какой именно записи календаря относится строка, и выдает ошибку инициализации.
Решение: В качестве ключевого поля (колонки Ссылка) всегда нужно использовать наиболее уникальный идентификатор для данной части запроса. В первой части это должна быть ЗаписиКалендаряСотрудника.Ссылка, а не поле источника.
В запросе мы видим попытку выбрать теги: ЗадачаСотрудника.Теги.( Тег КАК Тег ) КАК Теги. Это использование вложенных таблиц непосредственно в выборке.
Проанализируем ситуацию: Динамический список предназначен для построения линейной, плоской структуры данных. Хотя консоль запросов и СКД умеют обрабатывать вложенные наборы, динамический список на уровне платформы часто дает сбой при попытке «развернуть» такие данные. Это может приводить к ошибкам типа «Поле не найдено» или некорректному отображению строк.
Как поправить:
В тексте сообщения упоминается условие ЗаписиКалендаряСотрудника.Источник <> НЕОПРЕДЕЛЕНО. Рассмотрим подробнее, почему это плохая практика для запросов к базе данных.
В языке запросов 1С поля ссылочного типа в таблицах БД практически никогда не принимают значение НЕОПРЕДЕЛЕНО. Они могут быть либо заполнены конкретной ссылкой, либо быть Пустой ссылкой, либо содержать NULL (в случае левого соединения).
Решение: Замените проверку на более корректную:
ГДЕ
ЗаписиКалендаряСотрудника.Источник <> ЗНАЧЕНИЕ(Документ.ЗадачаСотрудника.ПустаяСсылка)
И НЕ ЗаписиКалендаряСотрудника.Источник ЕСТЬ NULL
Когда мы используем ОБЪЕДИНИТЬ ВСЕ, важно правильно настроить свойства самого объекта «Динамический список» в конфигураторе.
Посмотрим на настройки: если в свойстве Основная таблица указан какой-то конкретный объект (например, Справочник.ЗаписиКалендаряСотрудника), то платформа будет ожидать, что все данные в списке принадлежат именно этой таблице. При использовании UNION вторая часть запроса выбирает данные из Документ.ЗадачаСотрудника, что вступает в конфликт с настройкой основной таблицы.
Рассмотрим правильный алгоритм настройки:
Подводя итог, для исправления ошибки в Контакт-центре УНФ или аналогичной обработке, выполним следующие действия:
Применяя эти шаги, мы превращаем нестабильный запрос в надежный инструмент отображения данных, который будет корректно работать во всех режимах функционирования управляемой формы.