Записи регистра сведений стали неуникальными в 1С: причины и способы исправить

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

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

Исправление сводится к трём шагам: найти дублирующиеся записи, удалить лишние (или изменить значения измерений так, чтобы комбинации стали уникальными) и устранить источник появления дублей, чтобы ошибка не вернулась. Ниже разобраны все три этапа с конкретными инструментами.

Почему возникают неуникальные записи

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

Типичные причины появления неуникальных записей:

• загрузка данных внешними обработками с отключённым контролем (запись набором с ОбменДанными.Загрузка = Истина);
• обмен данными между базами, где в разных узлах созданы записи с одинаковыми измерениями;
• добавление нового измерения в регистр: старые записи получают пустое значение, и если по каким-то причинам проводилась «лечебная» запись, возникают совпадения;
• программная запись без проверки существования записи с таким же ключом;
• сбой во время записи, когда транзакция зафиксировалась частично (редкий, но встречающийся сценарий при аварийном завершении).

Как найти дублирующиеся записи

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

Пример запроса для независимого непериодического регистра сведений с измерениями «Организация» и «Номенклатура»:

ВЫБРАТЬ
Организация,
Номенклатура,
КОЛИЧЕСТВО(*) КАК КоличествоЗаписей
ИЗ
РегистрСведений.ЦеныНоменклатуры
СГРУППИРОВАТЬ ПО
Организация,
Номенклатура
ИМЕЮЩИЕ
КОЛИЧЕСТВО(*) > 1

Для периодического регистра в группировку добавьте поле Период. Результат покажет конкретные комбинации, по которым есть дубли. Дальше по каждой комбинации выводите полный список записей и решайте, какая из них корректная — обычно по ресурсам, дате изменения или ответственному.

Поиск через консоль запросов и универсальные обработки

Если под рукой нет конфигуратора, используйте консоль запросов в режиме предприятия или типовую обработку «Поиск и удаление дублей» из состава БСП — она работает со справочниками, но логику группировки легко перенести. Для регистров удобнее всего консоль кода: она позволяет сразу после поиска удалить лишние записи тем же сеансом.

Исправление через удаление лишних записей

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

Типовой фрагмент кода для удаления дубля:

Набор = РегистрыСведений.ЦеныНоменклатуры.СоздатьНаборЗаписей();
Набор.Отбор.Организация.Установить(НужнаяОрганизация);
Набор.Отбор.Номенклатура.Установить(НужнаяНоменклатура);
Набор.Прочитать();
// анализируем Набор, оставляем корректную запись
Пока Набор.Количество() > 1 Цикл
Набор.Удалить(0); // удаляем устаревшую
КонецЦикла;
Набор.Записать();

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

Исправление через тестирование и исправление

Инструмент «Тестирование и исправление» (ТиИ) в конфигураторе не удаляет дубли регистров сведений напрямую, но полезен в двух случаях. Во-первых, проверка логической и ссылочной целостности помогает выявить битые ссылки в измерениях — иногда «неуникальность» на самом деле вызвана повреждёнными записями. Во-вторых, реиндексация таблиц восстанавливает индексы уникальности после сбоев.

Порядок работы с ТиИ: откройте конфигуратор, меню «Администрирование — Тестирование и исправление», отметьте «Реиндексация таблиц информационной базы» и «Проверка логической целостности». Для файловой базы выполняйте проверку в монопольном режиме, для клиент-серверной — лучше в нерабочее время, так как реиндексация больших таблиц занимает заметное время.

Если после ТиИ ошибка сохраняется, значит дубли реально существуют в данных, и вернуться нужно к поиску и удалению через запрос — индексы тут ни при чём.

1. 1
   Сделайте резервную копию базы
2. 2
   Запросом с группировкой найдите комбинации измерений с дублями
3. 3
   Выгрузите полный список записей по проблемным комбинациям и определите корректные
4. 4
   Удалите лишние записи набором записей с отбором
5. 5
   Повторите проверочный запрос — дублей быть не должно
6. 6
   Найдите и устраните источник появления дублей (обмен, обработка, код)

Как предотвратить повторное появление дублей

Удаление дублей решает симптом, но не причину. Если источник не устранён, ошибка вернётся при следующем обмене или загрузке. Проверьте три направления.

Первое — код загрузок и обменов. Везде, где выполняется запись в регистр сведений программно, должна быть либо предварительная проверка существования записи с таким ключом, либо запись через менеджер записи с корректной установкой всех измерений. Флаг ОбменДанными.Загрузка = Истина отключает бизнес-логику, но не отключает контроль уникальности платформы — дубли всё равно вызовут ошибку, просто позже и в неожиданном месте.

Второе — настройки обмена. Если дубли приходят из другого узла РИБ или через план обмена, проверьте правила регистрации и сопоставление объектов: одинаковые записи с разными GUID могут «схлопываться» в одну комбинацию измерений при загрузке.

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

Особые случаи и ограничения

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

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

Контрольные точки

Как проверить результат

Повторный запрос с группировкой

Норма

Нет строк с количеством больше 1

Тревожный признак

Остались комбинации с дублями

Запись/проведение документа, вызывавшего ошибку

Норма

Записывается без сообщений

Тревожный признак

Ошибка неуникальности повторяется

Обмен данными после исправления

Норма

Синхронизация проходит без конфликтов

Тревожный признак

Дубли приходят снова — источник не устранён

Часто задаваемые вопросы

Можно ли исправить ошибку без конфигуратора?

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

Почему ошибка появилась сразу после обновления конфигурации?

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

Удалятся ли дубли автоматически при реиндексации?

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

Что делать, если дубли появляются при каждом обмене?

Проблема в правилах обмена или сопоставлении объектов. Проверьте, не создаются ли в разных узлах записи с одинаковыми измерениями, и настройте правила конвертации так, чтобы запись либо обновлялась, либо отклонялась. Временно можно включить обработку коллизий, но правильное решение — исправить правила.

Опасно ли записывать набор с ОбменДанными.Загрузка = Истина?

Сам по себе флаг безопасен — он лишь отключает обработчики бизнес-логики. Опасность в том, что вместе с логикой отключаются и ваши проверки на существование записи. Контроль уникальности платформы при этом работает всегда, поэтому дубль всплывёт ошибкой, но, возможно, не в момент загрузки, а позже.

Как быстро найти регистр, в котором возникла ошибка?

Имя регистра указано в тексте самой ошибки. Если сообщение обрезано, откройте технологический журнал или журнал регистрации — там фиксируется полное описание с именем объекта метаданных и значениями измерений проблемной записи.