УТ 11.4.
Ситуация: копия базы, тест нового функционала.
В новом функционале есть программное создание партнера (Справочник Партнеры)

При выполнении кода

```1c
    ПартнерОбъект.Записать();
```

вылетает исключение: Значение "00-00000680" поля "Код" не уникально.

С интерактивной записью нового партнера такая же проблема.
Ранее такое бывало на копиях баз, при записи новых документов (не уникален номер). Решал простым кодом:

```1c
    ОбновитьНумерациюОбъектов(Документ.метаданные());
```
---
Пока писал вопрос, проблема стала не актуальной. Решил не удалять, мб кому поможет

ОбновитьНумерациюОбъектов - метод сбрасывает не только нумерацию документов (как я всегда думал смотря на название метода). Действует и для справочников.И вообще лучше вызывать метод без параметров, тогда:
 Если значение параметра не указано, то обновление будет выполнено для всех типов объектов.

СП рулит xD
---
Пока писал вопрос, проблема стала не актуальной. Решил не удалять, мб кому поможет

ОбновитьНумерациюОбъектов - метод сбрасывает не только нумерацию документов (как я всегда думал смотря на название метода). Действует и для справочников.И вообще лучше вызывать метод без параметров, тогда:
 Если значение параметра не указано, то обновление будет выполнено для всех типов объектов.

СП рулит xD
---
Очень часто аналогичная проблема возникает при копировании базы: через SQL (не выгоняя пользователей) делаем бекап, потом загружаем его в копию базы. После этого в копии может все нормально работать, а может у некоторых справочников при создании нового ругаться на неуникальный номер. При этом, в справочнике, например, максимальный номер 100, а при записи говорит, что номер 85 не уникальный. если еще раз нажать на "Запись", пишет "номе 86 не уникальный"... и так, пока не дойдет до номера 101 и начинает нормально работать.
Может кто-то сталкивался с такой проблемой и может объяснить в чем проблема? В рабочей базе при этом все нормально и продолжает работать.
---
в чем проблема?

У меня именно такая ситуация.

Глобальный контекст (Global context)
ОбновитьНумерациюОбъектов (RefreshObjectsNumbering)
Синтаксис:
ОбновитьНумерациюОбъектов(<Метаданные>)
Параметры:
<Метаданные> (необязательный)

Описание:
Выполняет обновление номеров в соответствии с номерами, записанными в базе данных. После вызова данного метода все выданные, но незаписанные номера, становятся невалидными т.к. не гарантируется их уникальность. Данный метод разрешено вызывать только администратору системы.
Доступность:
Сервер, толстый клиент, внешнее соединение, мобильное приложение(сервер).

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

Механизм работы:
В копии кэш отсутствует, перед записью документа 1с идёт в БД и видит последний выданный номер 84, выдает новый 85.
При записи документа, 1с видит что номер 85 уже занят, и ругается. В кэш записывает "85 - уже выдан".

При повторной попытки записи, 1с видит что есть кэш. В кэше последний номер 85, выдает новый 86. При записи документа, 1с видит в БД что номер 86 уже занят, и ругается. В кэш записывает "86 - уже выдан".

и так до номера 101

А проблема в том что последний выданный номер (перед записью документа) 1с ищет в кэше/ таблице_1 БД, а проверка уникальности выданного номера идет по таблица_2 БД.
Грубо говоря, таблица_1 БД это СрезПоследних по таблице_2 БД. И Таблица_1 БД иногда получает рассинхрон с таблицей_2 БД (из за того что не сразу в нее пишется инфа, а в кэш).

Метод ОбновитьНумерациюОбъектов актуализирует информацию в таблице_1 БД, используя таблицу_2 БД.
Это упрощенное ИМХО, возможно некорректное. Если кто действительно в теме - буду рад полному объяснению
---
Интересное предположение, но ведь кэш может храниться для каждого пользователя отдельно. Тогда всё будет вообще печально)) думаю, что последний номер всё таки должен храниться в самой базе. Кроме того, у нас копия базы может не обновляться несколько месяцев. За это время будет создано огромное количество документов и разница в номерах будет большая (у нас же в пределах нескольких десятков номеров). кроме того, такая проблема наблюдается не у всех документов и справочников, а только у некоторых.
За ОбновитьНумерациюОбъектов спасибо, в следующий раз воспользуюсь, просто интересно, почему такая проблема возникает.
---
https://kuharbogdan.com/stati-po-1s/kak-ochistit-kesh-servera-1s/ - про серверный кэш

такая проблема наблюдается не у всех документов и справочников, а только у некоторых.
Если моя теория верна, то проблема будет у тех справочников и документов, в которые добавлялись новые элементы с момента последнего сохранения данных из кэша в Таблицу_1 БД. По остальным документам и справочникам информация в таблице_1 БД - актуальная
---
Да. знаю, что у серверной базы кэш может храниться на сервере. Я имел ввиду про файловые базы. Хотя у них возможно тоже есть какой-то общий кэш.
Смысл вашей теории мне вполне понятен. Мне не понятно, зачем это так реализовано, если ваша теория верна)))
Хотя, может быть это ускоряет работу...
На мой взгляд правильнее хранить эти данные внутри базы, чтобы не было таких ошибок.