Как исправить ошибку «Внутренняя ошибка динамического списка. Не найдены поля сортировки данных» в 1С

← На главную

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

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

Разберем причину ошибки

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

Решение 1: Использование механизмов конфигурации (Графы журнала)

Прежде чем приступать к написанию кода в динамическом списке, проанализируем архитектуру самого журнала документов. Самый правильный и производительный способ добавить колонку в журнал — это использование Граф.

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

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

Решение 2: Корректный запрос в Динамическом списке с использованием ВЫРАЗИТЬ

Если по каким-то причинам использование граф невозможно, и нам нужно получить данные через запрос динамического списка, рассмотрим, как сделать это правильно. Ошибка часто возникает, когда мы пытаемся получить реквизит через общую ссылку Журнал.Ссылка.Договор. Поскольку в журнале могут быть документы разных типов, не у каждого из которых есть поле «Договор», система может работать нестабильно.

Проанализируем пример безопасного запроса с использованием типизации:


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

Использование оператора ВЫРАЗИТЬ помогает платформе жестко определить тип данных колонки, что предотвращает ошибки при открытии ссылок и сортировке.

Решение 3: Обработка пустых значений через ЕСТЬNULL

Если в журнале уже есть определенные поля или вы используете левое соединение, важно убедиться, что результирующая колонка всегда имеет определенный тип, а не значение NULL. Рассмотрим вариант решения, который помог пользователю в обсуждении:


ЕСТЬNULL(ЖурналДокументовЖурналОпераций.ДоговорКонтрагента, ЗНАЧЕНИЕ(Справочник.Договоры.ПустаяСсылка)) КАК Договор

В данном случае, если поле договора не заполнено или отсутствует для данного типа документа, система подставит пустую ссылку справочника. Это стабилизирует работу динамического списка.

Решение 4: Настройка свойств «Использовать всегда» и «Основная таблица»

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

Откроем свойства Динамического списка в конфигураторе.
Убедимся, что свойство Основная таблица заполнено (например, ЖурналДокументов.ЖурналОпераций). Это позволяет платформе использовать индексы таблицы для сортировки по дате.
Перейдем в список реквизитов динамического списка (закладка «Набор данных»).
Для полей Ссылка и Дата установим флаг Использовать всегда.

Важный момент: Если вы программно устанавливаете порядок в коде (например, через Список.Порядок.Элементы), убедитесь, что поле, по которому идет сортировка, присутствует в выбранных полях запроса и доступно для использования.

Решение 5: Проверка на неоднозначность имен (псевдонимов)

Проанализируем ситуацию, когда в запросе динамического списка присутствуют соединения. Если мы присоединяем дополнительные таблицы (например, регистры сведений), в запросе может появиться несколько полей с одинаковыми именами, такими как Дата.

Рассмотрим фрагмент кода, который может вызвать конфликт:


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

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

Дополнительные рекомендации

Если все вышеперечисленные шаги не помогают, попробуйте выполнить следующие действия:

Очистка кэша: Ошибка часто бывает «фантомной» и связана с локальным кэшем метаданных. Попробуйте запустить базу с параметром /ClearCache.
Обновление конфигурации: Если список был изменен в расширении, убедитесь, что структура метаданных в расширении соответствует основной конфигурации. Иногда помогает простое переоткрытие формы в конфигураторе и нажатие кнопки «Заполнить автоматически» в конструкторе запроса.
Проверка индексов: Если в журнале сотни тысяч записей, а вы пытаетесь добавить сортировку по непроиндексированному полю, динамический список может выдавать «Внутреннюю ошибку» из-за таймаута СУБД.

Таким образом, для устранения ошибки «не найдены поля сортировки» мы рекомендуем в первую очередь использовать Графы журнала, а во вторую — тщательно проверять запрос на наличие ВЫРАЗИТЬ и флаги Использовать всегда для ключевых полей.