Думаю, большинство сталкивалось с такой проблемой. Довольно часто у объектов метаданных сбивается нумерация. Чаще всего причина заключается в некорректной работе нумератора. Если вы вручную исправляете номер и используете дополнительные символы, нумератор может «не понять», каким должен быть следующий номер. Механизм нумерации в том виде, в котором его знают пользователи, был разработан достаточно давно — ещё в версии 8.1. Он представляет собой специальный менеджер автонумерации кластера серверов — сервис нумерации. Максимальный номер не хранится ни в одной из таблиц базы данных, а существует в оперативной памяти процесса менеджера кластера (rmngr). Этот процесс хранит максимальное значение номера в контексте информационной базы кластера. Сервис хранит последний выданный номер для каждого объекта (документа, справочника) в разрезе каждого префикса и владельца (для иерархических справочников с уникальностью в пределах владельца) в контексте информационной базы (это важно для дальнейшего анализа). Важно понимать, что номера присваиваются ДО непосредственной записи объекта в базу данных. Если в процессе записи произошёл откат транзакции, ранее выданный номер будет возвращён и может быть присвоен другому объекту. Первичная выдача максимального номера происходит по данным информационной базы. Выполняется неблокирующее чтение максимального номера из базы данных. Далее максимальный номер из БД не перечитывается, а используется значение «максимальный + 1». Это позволяет сервису, не обращаясь к физической таблице, понимать, какой следующий номер необходимо присвоить. Если по какой-то причине в информационной базе сбилась нумерация, можно воспользоваться методом ОбновитьНумерациюОбъектов(Метаданные), который обновляет максимальный номер по данным информационной базы. Существует также ещё одна неприятная ситуация, которая может возникнуть при восстановлении базы данных из бэкапа средствами СУБД. Представим, что у нас есть ежедневная копия рабочей базы данных за прошлый день. Эта копия восстанавливается каждую ночь. После восстановления при любой попытке создать новый элемент справочника или документа возникает ошибка «Номер/код не уникален». Почему это происходит? Дело в том, что сервис нумерации хранит максимальный номер в разрезе информационной базы, причём эта связка хранится в оперативной памяти сервиса. Что же происходит при восстановлении базы? Сервис нумерации не знает, что база была восстановлена из резервной копии и что максимальный номер изменился. Разберём следующую ситуацию: - Рабочая база: максимальный код — 3. - Делаем бэкап. - Восстанавливаем базу в копию. - В копии создаём один элемент — максимальный номер становится равен 4. - В рабочей базе создаём ещё 3 элемента — максимальный номер становится равен 6. - Снова делаем бэкап и восстанавливаем его в копию. - Пытаемся создать элемент и получаем ошибку. Сервис "думает", что в копии максимальный номер 4, и пытается присвоить следующему элементу значение 5, а в базе уже есть элемент с таким номером. Что можно сделать в этой ситуации? Вот несколько рабочих вариантов: 1️⃣После восстановления базы перезапустить службу 1С. Это не всегда удобно, но помогает, так как после перезапуска сбрасываются значения максимального номера, и при первом присвоении номера сервис получит его по данным базы данных. 2️⃣ Вручную удалить информационную базу из кластера и добавить её заново. В этом случае кластер воспримет базу как новую, и счётчик нумерации будет восстановлен. 3️⃣ Вызвать метод ОбновитьНумерациюОбъектов.