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

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

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

Что означает сообщение и когда оно вылезает

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

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

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

• 🔄 обновление конфигурации на новый релиз (типовой или доработанной);
• ⬆️ переход между редакциями — например, УТ 11.4 → УТ 11.5, Бухгалтерия 3.0 на свежий релиз, ЗУП между версиями;
• 🧩 приёмка расширения или объединение конфигураций, где у регистра поменялся состав измерений;
• 🛠️ реструктуризация через Тестирование и исправление (chdbfl / ТиИ) после сбоя.

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

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

Причина всегда одна: в таблице лежат ≥2 строки с одинаковым ключом. А вот откуда они взялись — вариантов несколько.

• 💥 Сбой при записи — обрыв транзакции, падение сервера, жёсткая перезагрузка. Часть записей продублировалась.
• 🧷 Кривая обработка или обмен — внешняя обработка/загрузка писала в регистр напрямую, минуя проверку уникальности.
• 🔧 Смена состава измерений в новом релизе. Раньше ключ был из трёх измерений, стало из двух — и строки, ранее различавшиеся по «лишнему» измерению, схлопнулись в дубли.
• 🐘 Тонкости на PostgreSQL/файловой базе — рассинхрон индексов после некорректного восстановления или переноса.
• ⏭️ Обновление «через ступеньку» — пропущенные промежуточные релизы, в которых как раз чинились такие данные штатным обработчиком.

Быстрая диагностика по симптому:

Способы исправить: коротко в таблице

⚠️ Перед любыми правками данных сделайте резервную копию базы. Мы удаляем записи напрямую — откатить «Ctrl+Z» уже не выйдет.

Способ 1. Найти и удалить неуникальные записи запросом

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

1. Снимите резервную копию (обязательно).
2. Откройте консоль запросов (внешняя обработка «Консоль запросов» или Универсальные инструменты).
3. Найдите ключи, у которых больше одной записи. Пример для непериодического регистра сведений:

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

4. Для каждого «плохого» ключа откройте список записей регистра (Все функции → Регистр сведений), отберите по этим измерениям и оставьте одну актуальную строку, лишние — удалите.
5. Повторите обновление конфигурации.

Для периодического регистра добавьте в группировку Период (а если есть — Регистратор). Часто дубли различаются только миллисекундами — оставляйте более позднюю запись.

💡 Если строк-дублей десятки, не удаляйте руками. Напишите обработку, которая читает набор записей по ключу и оставляет одну. Либо переходите к свёртке (способ 2).

Способ 2. Свёртка (свертка) неуникальных записей обработкой

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

Логика обработки:

1. Запросом получаем список ключей с КОЛИЧЕСТВО(*) > 1 (как выше).
2. По каждому ключу создаём РегистрыСведений.ИмяРегистра.СоздатьНаборЗаписей().
3. Устанавливаем отбор по всем ключевым измерениям, читаем набор.
4. Оставляем в наборе одну строку (первую или последнюю), остальные убираем.
5. Записываем набор с Записать(Истина) — платформа заменит все строки по ключу на одну.

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

⚠️ Готовые обработки «свёртки неуникальных записей» есть в свободном доступе (Infostart и форумы). Прежде чем запускать чужой код на рабочей базе — обкатайте на копии.

Способ 3. Обновление без «пропусков»: последовательно по релизам

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

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

1. Определите текущий релиз (Справка → О программе).
2. Обновляйтесь по цепочке промежуточных релизов, а не сразу на последний.
3. Особенно это критично при смене редакции: сначала доведите старую редакцию (УТ 11.4, БП 3.0 и т.п.) до её последнего релиза, и только потом переходите на новую.
4. После каждого шага — проверяйте, что база открывается и проводит документы.

Настройка автоматического обновления

Если базу давно не трогали, ручная цепочка релизов утомительна. Автоматическое обновление (через раздел «Администрирование → Обновление программы» в типовых) само подтянет промежуточные релизы по порядку и применит их обработчики.

Но при уже существующих дублях авто-обновление тоже упрётся в ту же ошибку. Логика простая: сначала чистим данные, потом обновляемся — не наоборот.

Сравнение конфигураций: найти, откуда «лишнее» измерение

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

Особые случаи и edge-кейсы

• 🧮 Файловая база (.dt / PostgreSQL перенос). После восстановления из выгрузки индексы иногда пересобираются, и латентные дубли всплывают именно на обновлении. Помогает Тестирование и исправление → Реструктуризация.
• 🗂️ Регистр расчёта или подчинённый регистратору. Не удаляйте строки набором вслепую — сначала найдите документ-регистратор и перепроведите его; движения перестроятся корректно.
• 🔁 Дубли возвращаются после чистки. Значит, их плодит код — обмен, обработка, регламентное задание. Ищите место прямой записи в регистр и чините уникальность там, иначе ошибка вернётся на следующем обновлении.
• 🧬 Значения ключа в ошибке — GUID-ы (Состояния предметов взаимодействия и т.п.). Часто это служебные регистры CRM/взаимодействий. Дубли безопасно сворачиваются обработкой — данные учёта не затрагиваются.

Если не помогло

Обновление всё равно падает — пройдитесь по списку:

• ✅ Проверьте, что чистили тот самый регистр, что в ошибке (имён-близнецов много).
• ✅ Прогоните запрос на дубли ещё раз — возможно, остался ключ с КОЛИЧЕСТВО(*) > 1.
• ✅ Для периодического регистра включите в группировку Период и Регистратор.
• ✅ Запустите Тестирование и исправление с галкой «Реструктуризация таблиц информационной базы».
• ✅ Если регистр из расширения — временно отключите расширение, обновитесь, включите обратно.
• ✅ Уберите пропуски релизов: доведите текущую редакцию до последнего релиза перед переходом.

Не сработало и на этом — снимите копию базы и обратитесь к специалисту 1С с текстом ошибки и именем регистра. По этим двум данным проблема решается быстро.

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

• 💾 Регулярный бэкап — чтобы правки данных были обратимы.
• ⏭️ Обновляться по цепочке релизов, без прыжков через версии.
• 🧪 Любое крупное обновление — сначала на копии базы, потом на рабочей.
• 🔍 Периодически прогонять Тестирование и исправление, не дожидаясь обновления.
• 🧷 Проверять внешние обработки и обмены: они не должны писать в регистры в обход проверки уникальности.