«Значение поля Код не уникально» в 1С: причины и способы исправления

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

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

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

Почему 1С требует уникальности кода

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

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

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

Как определить источник проблемы

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

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

Исправление при ручном вводе кода

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

1. 1
   Скопируйте код, который вызвал ошибку, из поля ввода
2. 2
   Откройте список справочника и выполните поиск по этому коду
3. 3
   Определите, какой элемент должен сохранить код: существующий или новый
4. 4
   Если код нужен новому элементу — сначала измените код старого (например, добавьте суффикс) и запишите его
5. 5
   Вернитесь к новому элементу, введите освободившийся код и запишите
6. 6
   Если код не принципиален — очистите поле «Код» у нового элемента и дайте платформе присвоить код автоматически

Если автонумерация включена, оптимальное решение — вообще не трогать поле «Код»: платформа сама присвоит следующее свободное значение. Ручное редактирование кодов оправдано только тогда, когда этого требует учётная политика, и тогда стоит регламентировать правила формирования кодов, чтобы исключить совпадения.

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

Исправление при обмене данными и загрузке

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

Что проверить в первую очередь:

• Настройки поиска объектов в правилах обмена. Если поиск выполняется по коду, а коды в базах не синхронизированы, система пытается создать новый элемент с занятым кодом. Надёжнее искать по уникальному идентификатору (GUID) или по комбинации ключевых полей — наименованию, ИНН, артикулу.
• Префиксы баз. В распределённых системах каждой базе назначается префикс, который входит в состав кода или номера. Если префиксы не заданы или совпадают, разные базы генерируют одинаковые коды. Проверьте префикс в настройках обмена и в параметрах информационной базы.
• Правила конвертации в типовых обменах. В некоторых настройках есть вариант «Не создавать новые элементы» или режим загрузки с замещением — подберите режим под свою задачу.

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

Восстановление автонумерации

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

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

Способы восстановления:

• Вручную для разовой ситуации. Найдите максимальный существующий код (отсортируйте список по коду по убыванию), затем при создании нового элемента введите в поле «Код» значение больше максимального — платформа скорректирует счётчик, и дальше нумерация пойдёт корректно.
• Обработкой обновления нумерации. В типовых конфигурациях и на диске ИТС есть служебные обработки обновления нумерации объектов. Они перебирают существующие элементы и устанавливают счётчик в правильное значение. Запускать такие обработки следует в монопольном режиме или в период минимальной активности пользователей.
• Программно. Администратор или разработчик может выполнить метод платформы ОбновитьНумерациюОбъектов для нужного вида объектов через консоль кода.

ОбновитьНумерациюОбъектов(Метаданные.Справочники.Номенклатура);

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

Повреждение индексов: когда дубля нет, а ошибка есть

Редкий, но реальный сценарий: поиск по коду ничего не находит, элементов с таким кодом в базе нет, а платформа при записи упорно сообщает о неуникальности. Это признак рассогласования индекса уникальности — служебной структуры, которую СУБД использует для контроля.

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

Если после тестирования и исправления ошибка сохраняется, проблема глубже — возможно, повреждена сама таблица или есть особенности в расширениях конфигурации. На этом этапе разумно привлечь специалиста с опытом администрирования 1С и СУБД: самостоятельные эксперименты с прямым редактированием таблиц базы данных могут привести к потере данных.

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

Большинство случаев неуникальности кодов предотвращаются организационными и настроечными мерами:

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

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