С ситуацией, когда после планового обновления конфигурации (чаще всего «Управление торговлей», «ERP» или «Комплексная автоматизация») вдруг ломается привычная нумерация документов, сталкивались многие специалисты. Вместо привычного номера 0000-008314 система начинает выдавать странные конструкции вида 0000-0000-1, добавляя лишние дефисы, нули или меняя структуру префикса. Давайте разберем эту проблему подробно, проанализируем причины её возникновения и выработаем алгоритм действий для восстановления порядка.
В основе механизма автонумерации в платформе 1С:Предприятие лежит простой принцип: система ищет максимальный номер в базе данных, который соответствует текущему префиксу, и увеличивает его на единицу. Однако, когда мы видим, что номер изменился с 0000-008314 на 0000-0000-1, это означает, что платформа начала работать в новом пространстве нумерации.
Рассмотрим, почему это происходит. Механизм префиксации в современных конфигурациях (на базе БСП — Библиотеки Стандартных Подсистем) формирует итоговый номер из нескольких частей:
Если после обновления в алгоритме формирования префикса произошли изменения — например, добавился лишний дефис или изменился порядок сбора строки — система считает, что это совершенно новый поток документов. Для платформы номер с префиксом 0000- и номер с префиксом 0000-00- — это разные вселенные. Не найдя ни одного документа с новым "длинным" префиксом, платформа начинает отсчет с единицы.
В попытках быстро исправить ситуацию, некоторые специалисты (как и автор рассматриваемой темы) прибегают к изменению длины номера в конфигураторе. Например, увеличивают длину строки с 11 до 13 символов, чтобы новые "длинные" номера помещались и не вызывали ошибку уникальности.
Мы настоятельно не рекомендуем так делать по следующим причинам:
Если вы уже изменили длину номера, как в примере из обсуждения, первым шагом к исправлению должно стать возвращение штатной длины (после исправления данных).
Прежде чем приступать к исправлению ("лечению"), необходимо точно установить причину. Рассмотрим возможные варианты:
Решение: Проверить наличие исправлений (патчей) или более свежего релиза конфигурации. В примере автора помогло обновление с версии 3.2 на 3.3.
Давайте разберем пошагово, как вернуть нумерацию в нормальное русло, если обновление релиза уже выполнено или код исправлен, но номера продолжают создаваться неправильно.
Самое важное правило: пока в системе есть хотя бы один документ с неправильным форматом номера, который хронологически (или по сортировке) является "последним", автонумерация будет работать неправильно.
Нам необходимо найти все документы, созданные после сбоя (вида 0000-0000-1, 0000-0000-2 и т.д.), и перенумеровать их в соответствии со старым форматом (продолжить серию 0000-008315, 0000-008316...).
Для поиска проблемных документов лучше использовать консоль запросов. Обратите внимание, что простая сортировка по убыванию номера может не показать проблему, если длина строк отличается. Используйте сортировку с учетом длины:
ВЫБРАТЬ
РеализацияТоваровУслуг.Ссылка,
РеализацияТоваровУслуг.Дата,
РеализацияТоваровУслуг.Номер,
ДЛИНАСТРОКИ(РеализацияТоваровУслуг.Номер) КАК ДлинаНомера
ИЗ
Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
ГДЕ
РеализацияТоваровУслуг.Дата >= &ДатаСбоя
УПОРЯДОЧИТЬ ПО
ДлинаНомера УБЫВ,
РеализацияТоваровУслуг.Номер УБЫВ
Найденные документы необходимо перенумеровать. Это можно сделать вручную, если документов немного, или написать простую обработку, которая присвоит корректные номера (не забываем про режим ОбменДанными.Загрузка = Истина, чтобы не срабатывали лишние проверки при записи).
Даже если мы исправили все номера в базе данных, платформа 1С может продолжать выдавать неправильные номера. Это происходит потому, что сервер приложений 1С кэширует (запоминает) последние выданные номера для повышения производительности, чтобы не обращаться к таблице базы данных при каждом создании документа.
Чтобы заставить платформу "забыть" неправильную серию и заново просканировать базу в поисках настоящего максимального номера, необходимо использовать метод ОбновитьНумерациюОбъектов.
Выполнить этот код можно в обработке или через "Функции для технического специалиста" -> "Стандартные" -> "Управление нумерацией" (если такая обработка встроена в БСП вашей конфигурации), либо просто запустить внешний код:
// Обновляем нумерацию для конкретного типа документов
ОбновитьНумерациюОбъектов(Метаданные.Документы.РеализацияТоваровУслуг);
// Или, если нужно обновить вообще всё (может занять время)
ОбновитьНумерациюОбъектов();
Этот метод сбрасывает буфер нумератора. При следующем создании документа система обратится к базе данных, увидит наш исправленный номер 0000-0083XX и корректно присвоит следующий 0000-0083(XX+1).
В конфигурациях на базе БСП (ERP, КА, УТ) логика формирования номера часто вынесена в подписки на события (например, ПриУстановкеНовогоНомера). Если проблема не уходит, имеет смысл включить отладку и поставить точку останова в модуле объекта документа в процедуре ПриУстановкеНовогоНомера или в общем модуле ПрефиксацияОбъектовСобытия.
Посмотрим на типовую логику, которая может давать сбой:
Процедура УстановитьПрефикс(Источник, Префикс, ...)
// Если здесь "Префикс" уже содержит дефис,
// а потом код добавляет еще один дефис - мы получим двойной разделитель.
// Это часто случается при ошибках в обновлении общих модулей.
КонецПроцедуры
В теме на форуме выяснилось, что проблема была именно в обновлении (переход с 3.2 на 3.3). Это подтверждает правило: если код типовой и сбой произошел массово после обновления — в первую очередь проверяем список ошибок релиза на сайте поддержки и ищем обсуждения коллег.
Если у вас слетела нумерация после обновления, выполните следующие действия:
ОбновитьНумерациюОбъектов() для проблемных видов документов.Такой подход позволит вам сохранить целостность данных и избежать проблем с хронологией документов в будущем.