Почему возникает ошибка «Выявлено дублирование ключевых значений» в динамическом списке и как ее исправить?

← На главную

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

Причина возникновения ошибки

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

Ошибка чаще всего возникает при использовании ЛЕВОЕ СОЕДИНЕНИЕ. Если у одного ПоступлениеТоваровУслуг есть несколько документов УстановкаЦенНоменклатуры, левое соединение «размножит» строки: для одного поступления будет создано столько записей, сколько цен было установлено. Поскольку Ссылка у них одна, 1С блокирует вывод, чтобы избежать некорректной работы интерфейса.

Решение 1: Агрегация данных и использование вложенных запросов

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

Рассмотрим пример использования вложенного запроса с группировкой:


ВЫБРАТЬ
    ПТУ.Ссылка,
    ПТУ.Дата,
    ПТУ.Номер,
    ЕСТЬNULL(Цены.Ссылка, ЗНАЧЕНИЕ(Документ.УстановкаЦенНоменклатуры.ПустаяСсылка)) КАК ПоследняяУстановкаЦен
ИЗ
    Документ.ПоступлениеТоваровУслуг КАК ПТУ
ЛЕВОЕ СОЕДИНЕНИЕ (
    ВЫБРАТЬ
        УЦН.ДокументОснование КАК ДокументОснование,
        МАКСИМУМ(УЦН.Ссылка) КАК Ссылка
    ИЗ
        Документ.УстановкаЦенНоменклатуры КАК УЦН
    ГДЕ
        УЦН.Проведен = ИСТИНА
    СГРУППИРОВАТЬ ПО
        УЦН.ДокументОснование
) КАК Цены
ПО ПТУ.Ссылка = Цены.ДокументОснование

В данном примере мы заранее группируем установки цен по основанию, выбирая, например, МАКСИМУМ(Ссылка). Это гарантирует, что для каждого ПоступлениеТоваровУслуг вернется не более одной строки с ценой.

Решение 2: Использование условного оформления

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

Разберем шаг за шагом:

Добавьте в запрос вычисляемое поле, которое проверяет наличие связанного документа через ВЫБРАТЬ ... КОГДА ... ТОГДА ... ИНАЧЕ ... КОНЕЦ.
В настройках ДинамическийСписок на форме установите Условное оформление.
Настройте правило: если поле ЕстьУстановкаЦен равно ИСТИНА, подсветить строку или изменить цвет шрифта.

Это решение наиболее производительно и не ломает стандартную логику работы списка.

Решение 3: Переосмысление интерфейса

Если задача пользователя — постоянно контролировать, по каким ПТУ не созданы установки цен, возможно, ДинамическийСписок документов поступления — не лучшее место для такой аналитики. Проанализируем ситуацию: если документов много, лучше использовать специализированные инструменты:

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

Важные замечания по настройке ключевых полей

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

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