В процессе эксплуатации систем на платформе «1С:Предприятие 8» (особенно в конфигурациях на базе «Управление торговлей 10.3») пользователи могут столкнуться с крайне неприятной ситуацией: при попытке записать новый элемент справочника или провести документ система выдает ошибку «Код не является уникальным» или «Номер не является уникальным». При этом стандартные методы, такие как использование встроенных обработок по перенумерации или попытка вручную исправить номер, не всегда приносят результат.
В этой статье мы подробно проанализируем ситуацию, когда проблема затрагивает сразу несколько видов объектов (например, Номенклатура, Контрагенты, Заказ покупателя), и выясним, почему стандартные инструменты платформы иногда оказываются бессильны. Рассмотрим неочевидные причины этого сбоя и найдем эффективное решение.
Давайте выделим ключевые симптомы, которые указывают на то, что проблема носит не случайный характер (ошибка ввода пользователя), а системный технический сбой:
ОбновитьНумерациюОбъектов() через консоль кодов не исправляет ситуацию.Проанализируем причины такого поведения системы, начиная от наиболее вероятных в современной инфраструктуре и заканчивая специфическими программными нюансами.
Как показывает практика, одной из самых частых причин внезапного «размножения» неуникальных номеров является наличие нескольких менеджеров нумерации, работающих с одной и той же базой данных SQL. Рассмотрим, как это происходит.
При переносе базы данных на новый сервер или при клонировании виртуальных машин системные администраторы могут забыть остановить службы 1С на старом сервере. Если старый сервер сохранил настройки подключения к базе данных SQL, он продолжает «считать» себя владельцем этой базы. В платформе 8.3 реализован механизм агрессивного кэширования номеров. Сервер приложений запрашивает у базы данных сразу блок номеров (например, с 100 по 110), чтобы не обращаться к таблицам SQL при каждой записи объекта.
Если к одной базе подключены два разных кластера 1С, каждый из них заберет свой кэш. Когда «основной» сервер запишет объект с номером 100, «фантомный» сервер об этом не узнает. В следующий момент основной сервер попытается записать объект, а фантомный уже «занял» этот номер в своей памяти или даже успел внести запись. Возникает конфликт уникальности.
Как решить эту проблему по шагам:
Этот метод является самым быстрым и надежным способом «отстрелить» невидимые связи, мешающие нормальной работе менеджера нумерации.
Если после манипуляций с паролями SQL проблема сохраняется, разберем программные настройки самих объектов метаданных. В платформе «1С:Предприятие 8.3» существует свойство объекта «Режим управления нумерацией».
Рассмотрим подробнее два варианта:
rphost.Для исправления ситуации попробуем выполнить программное обновление нумерации для проблемных объектов. Для этого можно воспользоваться следующим кодом:
ВыбранныеМетаданные = Новый Массив;
ВыбранныеМетаданные.Добавить(Метаданные.Справочники.Номенклатура);
ВыбранныеМетаданные.Добавить(Метаданные.Документы.ЗаказПокупателя);
Для Каждого ОбъектМетаданных Из ВыбранныеМетаданные Цикл
ОбновитьНумерациюОбъектов(ОбъектМетаданных);
КонецЦикла;
Эта процедура заставляет платформу пересчитать текущий максимальный номер в таблицах базы данных и сбросить серверный кэш номеров для указанных типов объектов.
Часто причиной сбоя в УТ 10.3 становится человеческий фактор или некорректная работа обменов (например, модуля Битрикс). Если кто-то из пользователей вручную ввел код, который нарушает строковую последовательность, алгоритм автонумерации может «заблудиться».
Проанализируем типичные ошибки в данных:
ЕдиницыИзмерения существуют коды «00001», «00002» и внезапно появляется код «1» или «А001».Для выявления таких записей выполним простой запрос к проблемному справочнику, отсортировав его по коду в обратном порядке. Посмотрим на последние 10–20 записей. Если мы видим странные символы или коды, выбивающиеся из общей длины, их необходимо исправить вручную или с помощью обработки перенумерации.
Выясним причину, связанную с интеграциями. Если ваша система обменивается данными с сайтом или внешними CRM, проверьте способ записи данных.
Если интеграция производит запись в таблицы базы данных напрямую через SQL-запросы (минуя объектную модель 1С), системная таблица ConfigAutoNumbering не обновляется.
В этом случае платформа «не видит» новых записей в контексте нумерации и при создании нового объекта в интерфейсе 1С предлагает номер, который в реальности уже занят в базе данных. Рекомендация здесь однозначна: любая запись данных должна производиться только через средства платформы (создание объекта, заполнение свойств и вызов метода Записать()).
Также проанализируем фоновые задания. Использование COM-соединений для синхронизации может создавать свои собственные менеджеры нумерации, которые не всегда синхронно обновляют основной кэш сервера приложений. Проверьте список активных сеансов в консоли кластера на наличие зависших фоновых процессов или старых COM-соединений и завершите их.
Если вы столкнулись с массовой неуникальностью кодов после миграции сервера или обновления конфигурации, не спешите сразу менять код программы. Первым делом выполните смену пароля пользователя SQL, чтобы исключить влияние сторонних серверных процессов. Это самое эффективное решение для устранения конфликтов кэширования в распределенной или часто меняющейся инфраструктуре. Вторым шагом всегда должна идти программная проверка данных на наличие «кривых» кодов, введенных вручную или импортированных извне с нарушением длины и префиксации.