Сбой автонумерации документов в платформе 1С:Предприятие 7.7 — классическая проблема, с которой рано или поздно сталкивается любой администратор или разработчик. Ситуация обычно выглядит следующим образом: система исправно присваивала документам последовательные номера (например, последним был № 374), но в какой-то момент очередной документ неожиданно получил огромный номер (например, № 1672). Все последующие документы начинают нумероваться от этого ошибочного значения.
Простое перенумерование базы «назад» часто оказывается невозможным. Если документы уже распечатаны, подписаны контрагентами и отражены в учете, изменение их номеров повлечет за собой колоссальные трудозатраты и путаницу. В этой статье мы подробно разберем, как вернуть автонумерацию к правильному значению (в нашем примере — к № 375), не изменяя уже созданные «ошибочные» документы с большими номерами, и как технически обойти ограничения платформы, если программа не дает редактировать номера вручную.
Чтобы понять, как исправить проблему, проанализируем внутренние механизмы платформы 1С 7.7. В отличие от современных версий, где нумерация более гибкая, в «семерке» номера документов чаще всего имеют текстовый тип (Строка). Это сделано для возможности использования буквенных префиксов.
При определении следующего свободного номера система ищет максимальный существующий номер в базе данных за установленный период. Однако поиск происходит не по математическому принципу, а по лексикографическому (алфавитному) порядку сравнения строк. Символы сравниваются поочередно, слева направо:
"374" (без ведущих нулей) и строки "00001672" (с ведущими нулями) система оценивает их первые символы."3" по кодовой таблице старше, чем символ "0"."374" распознается платформой как большая, чем строка "00001672".Если пользователь хотя бы один раз вручную ввел номер, случайно стерев лидирующие нули (например, вместо "00000374" написал "374"), система зафиксирует эту длину как максимальную и продолжит автонумерацию в укороченном формате. Лидирующие нули для последующих документов отбросятся, что мгновенно приведет к хаосу в журналах. Для восстановления ведущих нулей без изменения последовательности документов можно использовать обработку для восстановления штатной разрядности номеров.
Представим ситуацию: в базе уже созданы документы с номерами от 1672 до 1680. Мы хотим, чтобы следующий созданный документ получил номер 375, но трогать документы 1672+ нам строго запрещено. Мы можем использовать особенность лексикографической сортировки строк в 1С 7.7, применив так называемый «трюк с ведущими нулями».
Выполним процедуру по шагам:
"00000374"."0000374"."00001672" и наш измененный "0000374"."1"), а во втором — тройка ("3"). Так как "3" больше, чем "1", строка "0000374" будет признана системой как **максимальный** номер в базе."0000375".Этот изящный способ позволяет мгновенно вернуть автонумерацию в нужное русло, избегая болезненного перенумерования сотен уже проведенных и распечатанных документов. Для системного предотвращения таких сбоев в конфигурации можно внедрить универсальный алгоритм автонумерации с защитой от ручных правок.
При попытке реализовать описанный лайфхак пользователи часто сталкиваются с системным запретом: поле «Номер» на форме документа заблокировано для редактирования, доступен только автоматический режим. Выясним основные причины этой блокировки:
ВводНового() или ПриЗаписи().Если интерфейс программы не позволяет изменить номер документа интерактивно, мы можем прибегнуть к техническим средствам администратора и программиста 1С 7.7.
Ограничения экранной формы не распространяются на программный доступ к объектам базы данных. Мы можем написать и запустить простейшую внешнюю обработку, которая найдет нужный документ и перезапишет его номер в обход любых интерфейсных запретов.
Рассмотрим пример кода для внешней обработки:
Процедура ВыполнитьИсправление()
Док = СоздатьОбъект("Документ.Договор");
// Ищем документ по старому номеру и дате (или позиции)
Если Док.НайтиПоНомеру("00000374", РабочаяДата()) = 1 Тогда
// Снимаем блокировку номера, если она установлена программно
Док.АвтоВремяКонецДня();
Док.НомерДок = "0000374"; // Убираем один ведущий ноль
Попытка
Док.Записать();
Предупреждение("Номер успешно изменен на 0000374!");
Исключение
Предупреждение("Не удалось записать документ: " + ОписаниеОшибки());
КонецПопытки;
Иначе
Предупреждение("Документ с номером 00000374 не найден!");
EndIf;
КонецПроцедуры
Если вы не хотите писать код вручную, воспользуйтесь проверенными временем универсальными инструментами для 1С 7.7:
НомерДок.Важно: Перед выполнением этого действия обязательно создайте резервную копию базы данных! При обслуживании нескольких баз задачу регулярного создания копий можно упростить с помощью программы для автоматического архивирования и тестирования баз 1С.
Если база данных работает в файловом режиме (DBF), технический специалист может напрямую отредактировать таблицы базы данных с помощью любого DBF-редактора (например, DBF Commander или DBF Navigator):
1sjourn.dbf.DOCNO измените значение номера с "00000374" на "0000374".Если ручное исправление номера не помогло, и система продолжает выдавать некорректные автономера, проанализируем структуру метаданных в Конфигураторе: