Как исправить внутреннюю ошибку динамического списка «не найдены поля сортировки данных» при добавлении реквизитов в журнал операций

← На главную

В процессе разработки в среде 1С:Предприятие 8.3, особенно при работе с такими сложными конфигурациями, как БГУ 2.0 или БП 3.0, программисты часто сталкиваются с необходимостью кастомизации стандартных журналов документов. Типичная задача — вывести дополнительную колонку (например, «Договор») в Журнал операций. Однако попытка просто добавить поле через точку от реквизита Ссылка (например, Ссылка.Договор) в динамическом списке часто приводит к критическому сбою: «Внутренняя ошибка динамического списка. не найдены поля сортировки данных для полей Дата, Ссылка».

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

Почему возникает эта ошибка: глубокий анализ ситуации

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

Когда мы пытаемся в динамическом списке обратиться к реквизиту через точку от поля составного типа (Ссылка.Договор), платформа 1С на уровне СУБД пытается выполнить неявное левое соединение (LEFT JOIN) со всеми таблицами, которые входят в этот составной тип. Это порождает несколько проблем:

Неопределенность типа: Платформа не может однозначно определить тип возвращаемого значения, так как в разных документах реквизит «Договор» может иметь разные типы или отсутствовать вовсе.
Проблема сортировки: Динамический список по своей природе требует наличия ключевых полей для обеспечения стабильной сортировки и пагинации (постраничного вывода). Обычно это Дата и Ссылка. Когда запрос «ломается» из-за некорректного обращения к составному полю, механизм построения внутреннего SQL-запроса платформы теряет ориентацию и выдает ошибку о невозможности найти поля сортировки.
Производительность: Огромное количество левых соединений крайне негативно сказывается на скорости открытия списка.

Решение 1: Использование конструкции ВЫРАЗИТЬ в запросе

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

Использование конструкции ВЫРАЗИТЬ (CAST) заставляет платформу делать соединение только с конкретными таблицами, что стабилизирует работу списка. Проанализируем пример кода, который решает задачу вывода договора:


ВЫБОР
    КОГДА ЖурналДокументовЖурналОпераций.Ссылка ССЫЛКА Документ.СчетФактураВыданный
        ТОГДА ВЫРАЗИТЬ(ЖурналДокументовЖурналОпераций.Ссылка КАК Документ.СчетФактураВыданный).Договор
    КОГДА ЖурналДокументовЖурналОпераций.Ссылка ССЫЛКА Документ.СчетФактураПолученный
        ТОГДА ВЫРАЗИТЬ(ЖурналДокументовЖурналОпераций.Ссылка КАК Документ.СчетФактураПолученный).Договор
    // Добавьте остальные типы документов, где есть договор
    ИНАЧЕ ЗНАЧЕНИЕ(Справочник.ДоговорыКонтрагентов.ПустаяСсылка)
КОНЕЦ КАК ДоговорКонтрагента

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

Решение 2: Настройка свойств полей в конфигураторе

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

Основная таблица: Откройте свойства динамического списка. На вкладке «Запрос» убедитесь, что в поле «Основная таблица» выбран ЖурналДокументов.ЖурналОпераций. Если там стоит «Авто» или пусто, платформа может некорректно генерировать команды сортировки.
Флаг «Использовать всегда»: Перейдите в настройки списка (кнопка «Настройка списка» в нижней части окна редактирования запроса). Найдите в списке полей Дата и Ссылка, а также ваше новое поле ДоговорКонтрагента. Установите для них флажок «Использовать всегда». Это гарантирует, что данные будут выбираться из базы, даже если пользователь скроет колонку в интерфейсе.
Автозаполнение полей: Если вы используете сложный «Произвольный запрос», попробуйте снять галочку «Автозаполнение» и вручную сопоставить поля запроса с полями списка. Это предотвратит попытки платформы автоматически добавить связи, которые могут конфликтовать с вашим кодом ВЫРАЗИТЬ.

Решение 3: Очистка настроек и кэша

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

Выполним следующие действия:

Зайдем в раздел Администрирование — Настройки пользователей и прав.
Выберем Очистка настроек.
Найдем нужного пользователя и форму журнала операций, после чего удалим все настройки для этой формы.
В крайнем случае выполним очистку локального кэша конфигурации на компьютере пользователя (удаление папок из %AppData%\1C\1cv8).

Альтернативные способы добавления реквизитов

Рассмотрим ситуацию, когда лезть в запрос динамического списка нежелательно (например, чтобы не снимать конфигурацию с поддержки). В современных версиях БГУ 2.0 и БП 3.0 реализован механизм Дополнительных реквизитов и сведений.

Если «Договор» настроен как дополнительный реквизит, он может быть выведен в список через команду «Изменить форму» в пользовательском режиме. Этот механизм штатно оптимизирован разработчиками 1С и, как правило, не вызывает ошибок с полями сортировки, так как использует внутренние оптимизированные запросы к таблицам дополнительных сведений.

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

Резюме

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

Основные правила для предотвращения этой ошибки:

Всегда используйте ВЫРАЗИТЬ при обращении к реквизитам через точку от полей составного типа.
Всегда указывайте Основную таблицу в настройках динамического списка.
Используйте свойство Использовать всегда для ключевых полей.
Не забывайте очищать пользовательские настройки после изменения метаданных формы.

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