Каждый практикующий специалист 1С рано или поздно сталкивается с ситуацией, когда в информационной базе нарушается автонумерация документов. Вместо стройного ряда номеров вроде 000000001, 000000002 в системе внезапно появляется хаос: номера без ведущих нулей, случайные символы, лишние пробелы, а новые документы начинают получать совершенно непредсказуемые индексы. Попытки использовать стандартный метод платформы ОбновитьНумерациюОбъектов() часто не дают результата, оставляя администратора наедине с "капризным" нумератором.
В этой статье мы подробно разберем, почему ломается автонумерация в 1С, как быстро найти документы, вызвавшие сбой, и какими техническими способами можно вернуть систему в рабочее состояние.
Для начала давайте проанализируем, как платформа 1С работает с номерами документов. Чтобы повысить производительность и сократить количество обращений к СУБД, сервер приложений 1С кеширует диапазон номеров. Когда создается новый документ, платформа берет из кеша последний максимальный номер и увеличивает его на единицу.
Сбой автонумерации происходит в тот момент, когда в базу физически записывается документ с некорректно заполненным номером. Это может быть ручной ввод пользователя (например, вместо 00000000015 написали 15 или 15000000000) либо результат некорректного обмена данными.
Причины неэффективности простого сброса кеша:
Метод ОбновитьНумерациюОбъектов() выполняет ровно одну задачу — он очищает кеш номеров на сервере приложений 1С и заставляет систему обратиться напрямую к СУБД для поиска максимального номера. Если в таблице базы данных продолжает лежать документ с "кривым" номером (например, 1004000099), СУБД по правилам строкового сравнения (где символ "9" приоритетнее "0") выберет именно его в качестве максимального. В результате автонумерация продолжит генерировать ошибочную последовательность.
Прежде чем приступать к исправлению номеров, нам необходимо локализовать проблему и найти те самые документы, которые сбивают алгоритм платформы. Для этого напишем простой запрос в консоли запросов.
Наша цель — отобрать документы за проблемный период (обычно это текущий год, так как у большинства документов периодичность нумерации установлена в пределах года), определить их реальную длину и отсортировать по убыванию строкового значения.
Рассмотрим пример запроса для поиска некорректных номеров:
ВЫБРАТЬ
Ссылка КАК ДокументСсылка,
Номер КАК ИсходныйНомер,
ДЛИНАСТРОКИ(Номер) КАК ДлинаНомера
ИЗ
Документ.РеализацияТоваровУслуг КАК Реализация
ГДЕ
Реализация.Дата МЕЖДУ &НачалоПериода И &КонецПериода
УПОРЯДОЧИТЬ ПО
ИсходныйНомер УБЫВ
На что следует обратить внимание при анализе результатов запроса:
/), дефисов (-) или нижних подчеркиваний (_) может разделять номер на префиксную и числовую части некорректно с точки зрения платформы."000000015 "). Визуально номер кажется правильным, но для СУБД это совершенно другая строка, нарушающая автоинкремент.После того как проблемные документы обнаружены, у нас есть несколько путей решения проблемы. Рассмотрим их по шагам.
Если сбой произошел в стандартной типовой конфигурации (например, "1С:Бухгалтерия") и затронул кассовые или налоговые документы (ПКО, РКО, Счета-фактуры), мы можем воспользоваться встроенным помощником:
Для любых видов документов, в том числе в самописных конфигурациях, отлично подходит универсальный метод сброса номеров без программирования:
Номер."0" и выполним изменение. Это освободит старые ошибочные номера из индекса базы данных.Номер оставим пустое значение (система автоматически подставит команду <Сбросить>) и запустим процесс изменения.После завершения групповой обработки обязательно выполним в коде (например, через внешнюю обработку в одну строку) команду сброса кеша:
ОбновитьНумерациюОбъектов(Метаданные.Документы.РеализацияТоваровУслуг);
Если база данных файловая, а стандартные методы перенумерации по какой-то причине недоступны или не сбрасывают внутренний счетчик таблиц СУБД, мы можем прибегнуть к проверенному системному приему, который принудительно перестраивает структуру индексов автонумерации:
Этот простой шаг заставляет СУБД физически пересоздать индексные таблицы автонумерации и полностью стереть историю ложных максимальных значений счетчиков.
Если специфика бизнеса не позволяет массово перенумеровывать документы за прошлые месяцы (поскольку первичные печатные формы уже отданы контрагентам), мы можем настроить программный обход проблемы. Для этого добавим новый уникальный префикс, с которого начнется чистая, правильная цепочка номеров.
Мы можем использовать стандартное событие модуля объекта документа ПриУстановкеНовогоНомера. Проанализируем пример кода, который принудительно задает новый префикс и сбрасывает нумерацию к началу новой числовой последовательности:
Процедура ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)
// Задаем новый уникальный префикс для отделения от старого "бардака"
// Например, добавим буквенный префикс текущего квартала или года
Префикс = "НОВ-";
// Если требуется полностью кастомный алгоритм, можно отключить стандартную обработку
// и рассчитать номер самостоятельно на основании запроса к СУБД:
// СтандартнаяОбработка = Ложь;
// Номер = ПолучитьСледующийСвободныйНомерСПрефиксом(Префикс);
КонецПроцедуры
Добавление нового префикса (например, префикса информационной базы или организации) решает проблему мгновенно: платформа начинает искать максимальный номер только среди документов с новым префиксом НОВ-00000001, полностью игнорируя старые беспрефиксные записи с некорректным заполнением.
Чтобы раз и навсегда избавить базу данных от хаоса в номерах документов, мы рекомендуем выполнить два важных профилактических шага:
Режим автонумерации объектов. Установите его в значение Освобождать автоматически. Это позволит платформе повторно использовать номера удаленных документов и предотвратит появление "дыр" в последовательности.Номер установите свойство Доступность в значение Ложь либо снимите право "Редактирование номеров" в ролях пользователей. Если номер действительно нужно изменить в исключительном случае — пусть это делает администратор базы данных с помощью специализированной обработки.