В процессе работы с распределенными информационными базами (РИБ) технические специалисты часто сталкиваются с ситуацией, когда механизмы автоматической нумерации начинают вести себя непредсказуемо. Одной из наиболее запутанных проблем является подмена префикса информационной базы: например, вместо ожидаемого префикса XM документ внезапно получает префикс XC, который принадлежит совершенно другому узлу или складу. Особенно часто это проявляется в конфигурации «1С:Розница» с документами складского учета или ЕГАИС, такими как Передача в регистр №2.
В данной статье мы подробно разберем, почему штатные настройки синхронизации могут игнорироваться, как платформа выбирает «следующий» номер и какими способами можно восстановить корректный порядок нумерации в системе.
Для начала проанализируем, как вообще формируется номер документа в современных конфигурациях на базе БСП (Библиотеки стандартных подсистем). Процесс разделен на два уровня:
ПриУстановкеНовогоНомера. Когда мы создаем новый документ, срабатывает программный код, который обращается к константам или настройкам узла РИБ, забирает оттуда префикс (например, XM) и принудительно устанавливает его в начало номера.Разберем ситуацию автора темы: в базе присутствуют документы с префиксами обоих узлов, так как данные мигрируют между магазинами и складами. Если в базу попал документ с номером XC000015, и система считает его «максимальным», то следующий документ, созданный даже в узле XM, получит номер XC000016, потому что платформа не знает о логике разделения префиксов — она видит только строку текста.
Выясним основную причину, почему префикс игнорируется. В типовых конфигурациях, таких как «Розница», за установку префиксов отвечают подписки на события. Если документ ПередачаВРегистр2ЕГАИС (или аналогичный) не включен в состав подписки ПриУстановкеНовогоНомераДокумента, то никакой магии с подстановкой XM не произойдет.
Проанализируем состав метаданных. Вам необходимо проверить объект Подписки на события в конфигураторе. Найдите те, в имени которых фигурирует «Префиксация» или «УстановитьНовыйНомер». Если в списке типов объектов для этой подписки нет нужного вам документа, платформа будет использовать стандартную автонумерацию, ориентируясь на последний физически существующий номер в таблице базы данных.
Рассмотрим подробнее, как «чужие» номера попадают в базу. В РИБ данные синхронизируются. Если в магазине №1 (префикс XM) и в магазине №2 (префикс XC) создаются документы одного типа, то после обмена в обеих базах будут документы и с XM, и с XC.
Важный технический нюанс: Платформа 1С выполняет поиск максимального номера по строковым правилам сравнения. Если по какой-то причине номер XC программа считает «старшим» (например, из-за алфавитного порядка или длины строки), автонумерация «цепляется» за него и продолжает плодить документы с чужим префиксом. Это происходит именно тогда, когда программный механизм БСП не переопределяет номер при создании.
Прежде чем менять программный код, необходимо «очистить» базу от ошибочных номеров, иначе платформа продолжит их использовать как образец. Посмотрим на алгоритм действий:
XC на XM).После исправления номеров в базе необходимо заставить платформу «забыть» старый максимальный номер. Для этого используется встроенная функция ОбновитьНумерациюОбъектов. Разберем пример кода, который нужно запустить в обработке или через консоль кода:
МетаданныеДокумента = Метаданные.Документы.ПередачаВРегистр2ЕГАИС;
ОбновитьНумерациюОбъектов(МетаданныеДокумента);
Предупреждение("Нумерация обновлена. Перезайдите в программу.");
Эта команда очищает внутренний кэш сервера 1С, который хранит последний выданный номер. Без этого действия даже после исправления всех документов система может продолжать выдавать старые номера по инерции.
Если вы хотите решить проблему радикально и гарантировать, что префикс всегда будет браться из настроек узла, выполните следующие действия в конфигураторе:
ПрефиксацияОбъектовПриУстановкеНовогоНомераДокумента).ПередачаВРегистр2ЕГАИС.После этого при создании документа система будет вызывать стандартный обработчик БСП, который принудительно добавит префикс из константы ПрефиксИнформационнойБазы или из настроек текущего узла обмена, игнорируя «чужие» номера, пришедшие по синхронизации.
Посмотрим на ситуацию, когда изменения в конфигурацию вносить нельзя (база на поддержке). В этом случае можно воспользоваться механизмом расширений. Создайте расширение и добавьте в него процедуру-обработчик ПриУстановкеНовогоНомера для конкретного документа. В этой процедуре можно вручную прописать логику:
&НаСервере
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ЭтотОбъект.ЭтоНовый() Тогда
ПрефиксБСП = ПрефиксацияОбъектовКлиентСервер.ПолучитьПрефиксИнформационнойБазы();
// Дополнительная логика формирования номера с учетом префикса РИБ
КонецЕсли;
КонецПроцедуры
Важный момент по поводу РИБ: Помните, что префикс информационной базы не всегда совпадает с префиксом узла в плане обмена. Проверьте обе настройки. В некоторых случаях (как в сообщении 15 форума) префикс может не входить в состав состава РИБ специально, чтобы каждый узел генерировал свои уникальные номера независимо от других.
Подводя итог: проблема с «чужими» префиксами в 1С:Розница — это следствие работы стандартного механизма автонумерации платформы в обход подсистемы префиксации БСП. Решается она либо исправлением состава подписок на события, либо ручной корректировкой последних номеров с последующим обновлением кэша нумерации через ОбновитьНумерациюОбъектов().