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

Ошибка «Записи регистра сведений стали неуникальными» появляется при обновлении конфигурации 1С, когда платформа пытается изменить структуру регистра — например, добавить новое измерение, изменить состав ключей или включить режим «Ведущее» — и обнаруживает, что существующие записи нарушают новое требование уникальности. Реструктуризация прерывается, обновление не завершается, а база остаётся в состоянии, когда работа пользователей невозможна до устранения конфликта.

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

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

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

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

Наиболее частые причины:

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

Как определить, какие записи стали дублями

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

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

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

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

Порядок устранения: от копии до повторного обновления

Работайте строго в следующей последовательности. Каждый шаг снижает риск потери данных, пропуск шагов — типичная причина того, что после «успешного» исправления обнаруживаются удалённые нужные сведения.

1. 1
   Сделайте полную резервную копию рабочей базы (выгрузка в dt или копия средствами СУБД)
2. 2
   Разверните копию базы и выполните запрос для поиска дублей по новому набору ключей
3. 3
   Проанализируйте дубли: какие записи актуальны, какие — технические копии или устаревшие
4. 4
   Удалите лишние записи через обработку с явным отбором, зафиксируйте, что именно удалено
5. 5
   Запустите обновление конфигурации на копии и убедитесь, что реструктуризация проходит без ошибок
6. 6
   Проверьте прикладную логику: отчёты, проведение документов, обмены, использующие регистр
7. 7
   Повторите процедуру на рабочей базе в регламентное время с блокировкой сеансов пользователей

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

Выбор стратегии очистки в зависимости от ситуации

Не существует единственно правильного способа очистки — он зависит от природы дублей. Ниже сопоставлены основные варианты.

Сравнение вариантов очистки

Ручное удаление через форму списка

Подходит при единичных дублях. Ограничение: неприменимо при массовых дублях и требует доступа к форме регистра

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

Универсальный вариант для массовой очистки по заданному правилу. Требует аккуратности с отборами и тестирования на копии

Отказ от изменения структуры (откат обновления)

Подходит, если обновление не критично, а данные ценны. Ограничение: проблема вернётся при следующем обновлении

Перенос данных в новый регистр

Если структура изменилась радикально — создаётся новый регистр, данные переносятся обработкой с разрешением конфликтов. Трудоёмко, но безопасно

Если дубли появились из-за обмена данными

Когда регистр участвует в обмене (РИБ, универсальный формат, синхронизация с другими системами), дубли часто приходят из периферийных узлов или внешних систем. В этом случае недостаточно почистить центральную базу — при следующем обмене дубли вернутся. Сначала найдите источник: узел обмена, правило конвертации или внешнюю систему, которая шлёт повторные записи, и устраните причину там.

Если регистр используется в типовых механизмах

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

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

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

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

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

Повторный запрос на дубли

Норма

Запрос по новому набору ключей не возвращает строк

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

Остаются комбинации с количеством больше одной

Реструктуризация при обновлении

Норма

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

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

Ошибка повторяется на том же или другом регистре

Количество записей до и после

Норма

Уменьшение соответствует числу удалённых дублей

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

Записей стало заметно меньше, чем ожидалось — удалили лишнее

Прикладные отчёты и документы

Норма

Отчёты по данным регистра дают ожидаемые значения

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

В отчётах пропали строки или изменились итоги

Как предотвратить повторение ошибки

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

Дополнительные меры: контролируйте обмены и загрузки, которые пишут в регистры напрямую; не допускайте программной записи в регистр без установки отборов по всем измерениям; при изменении структуры регистра в поставке включайте обработчик обновления, который заранее разрешает конфликты (например, объединяет дубли по понятному правилу) до начала реструктуризации.

Маршрут решения

Как выбрать действие

Дублей мало и они полностью идентичныУдалите лишние копии вручную или простой обработкой, оставив по одной записи

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

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

Обновление не срочное, а данные критичныОтложите обновление, подготовьте и протестируйте обработку очистки на копии

Ошибка возникает на нескольких регистрахСоставьте полный список проблемных регистров запросами и обрабатывайте все за одну итерацию

Частые вопросы

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

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

Как быстро найти все регистры сведений с дублями, а не только тот, на котором упало обновление?

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

Потеряются ли данные при удалении дублей?

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

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

База после прерванной реструктуризации обычно остаётся в рабочем состоянии на старой версии конфигурации. Немедленно сделайте выгрузку в dt или копию средствами СУБД, затем работайте по стандартной схеме: копия, анализ, очистка, повторное обновление.

Почему ошибка появилась именно после обновления, хотя раньше всё работало?

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

Нужно ли блокировать работу пользователей во время исправления?

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