Почему в регистре сведений появляются одинаковые записи и как работает контроль уникальности

← На главную

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

Понятие уникального ключа записи

Для начала проанализируем, как платформа 1С понимает уникальность. В независимом непериодическом регистре сведений ключом уникальности является совокупность всех его измерений. Это означает, что для записи в базу данных система проверяет комбинацию значений: Измерение1 + Измерение2 + ... + ИзмерениеN.

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

Визуальные дубли и ловушка ссылочных типов

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

Проанализируем сценарий:

Программно создается новый элемент справочника с наименованием «Синий».
Создается запись в регистре с этим элементом.
Затем программно создается еще один элемент справочника с таким же наименованием «Синий».
Создается вторая запись в регистре.

Визуально в списке мы увидим две строки, где в колонке «Характеристика» написано «Синий». Однако технически это ссылки на два разных объекта в базе данных с разными UUID. Для платформы это абсолютно разные значения измерений, и контроль уникальности успешно проходит. Выясним причину: при программном заполнении важно не создавать новые элементы «на лету», а сначала пытаться найти существующие по наименованию или другим реквизитам.

Бизнес-логика против платформенного контроля

Рассмотрим роль обработчика ОбработкаПроверкиЗаполнения в модуле набора записей. Многие начинающие разработчики путают техническую уникальность с логической. Платформа 1С никогда не позволит записать в одну таблицу два набора измерений, которые полностью совпадают (на уровне SQL это ограничение PRIMARY KEY).

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


Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    
    // Проверка логической уникальности штрихкода в рамках системы
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Штрихкоды.Штрихкод,
        |   Штрихкоды.Владелец
        |ИЗ
        |   РегистрСведений.Штрихкоды КАК Штрихкоды
        |ГДЕ
        |   Штрихкоды.Штрихкод В(&СписокШтрихкодов)";
    
    // ... дальнейшая логика анализа выборки и установка Отказ = Истина
КонецПроцедуры

Этот код не заменяет проверку платформы, а дополняет её, накладывая ограничения, специфичные для конкретной бизнес-задачи.

Особенности работы с наборами записей

Важно помнить, как работает метод Записать() у объекта РегистрСведенийНаборЗаписей. Работа с регистрами всегда ведется через наборы. Рассмотрим механизм замещения:

Если при записи набора установлен параметр Замещать = Истина, платформа сначала удаляет из базы данных все старые записи, которые соответствуют установленному фильтру (отбору) набора.
Затем записываются новые строки, подготовленные в памяти.

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

Как проверить реальную идентичность записей

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


ВЫБРАТЬ
    Штрихкоды.Штрихкод КАК Штрихкод,
    Штрихкоды.Владелец КАК Владелец,
    ПРЕДСТАВЛЕНИЕ(Штрихкоды.Владелец) КАК ВладелецПредставление,
    Штрихкоды.Владелец.Ссылка КАК СсылкаУИД
ИЗ
    РегистрСведений.Штрихкоды КАК Штрихкоды
ГДЕ
    Штрихкоды.Штрихкод = &НужныйШтрихкод

Если в результате запроса вы увидите две строки, где колонки с представлением одинаковы, а при переходе в объект (или при детальном изучении UUID) вы попадаете в разные элементы — значит, проблема в данных, а не в сбое платформы. Также полезно проверить строковые измерения на наличие невидимых символов (пробелов, неразрывных пробелов, символов табуляции), которые визуально неразличимы, но делают строку уникальной.

Подведем итоги

Разберем основные выводы нашего исследования:

Платформа всегда контролирует уникальность по всей совокупности измерений. Создать абсолютно идентичные записи (бит-в-бит) невозможно на уровне архитектуры СУБД.
Визуальные дубли — это чаще всего результат того, что в измерениях хранятся разные ссылки на объекты с одинаковыми наименованиями.
Программный контроль в модуле регистра нужен для соблюдения бизнес-логики (например, запрет одного штрихкода для разных товаров), а не для технического обеспечения целостности БД.
Тип данных имеет значение. Строка "123" и число 123 — это разные значения для ключа записи, даже если они выглядят похоже в интерфейсе.

Для предотвращения подобных проблем рекомендуем всегда проверять существование ссылочных объектов перед их записью в измерения регистра и использовать типизацию данных максимально строго.