Ситуация, когда после планового обновления типовой конфигурации (например, 1С:Бухгалтерия) внезапно исчезают данные в добавленных программистом регистрах сведений, является критической. Это может привести к потере истории операций, настроек или аналитических данных, которые собирались месяцами. Разберем подробно, почему это происходит, как диагностировать проблему и каков правильный алгоритм обновления модифицированных баз.
Рассмотрим стандартный сценарий, который часто приводит к беде. При обновлении через поддержку или через файл конфигурации (.cf) открывается окно сравнения и объединения. Основная ошибка кроется в логике расстановки флагов (галочек). Проанализируем типичный неверный подход: программист отмечает только измененные типовые объекты, а самописные объекты оставляет без флажков, полагая, что «раз я их не трогаю, то и система их не тронет».
На самом деле механизм 1С работает иначе. Если вы выполняете объединение с файлом, в котором ваших объектов нет (а в типовом .cf их, разумеется, нет), и при этом снимаете флаг с объекта в основной конфигурации, система может интерпретировать это как команду на удаление объекта или исключение его из структуры метаданных. Если объект помечается к удалению в процессе реструктуризации, платформа физически удаляет таблицу из базы данных SQL вместе со всеми записями.
Как правильно: При обновлении измененной конфигурации на самописных объектах флаги должны стоять всегда. Это гарантирует, что объект перейдет в новую итерацию конфигурации базы данных в неизменном виде. Если в окне сравнения ваш регистр подсвечен как «отсутствующий в файле поставщика», установка флага подтверждает сохранение этого объекта в вашей базе.
Выясним причину, связанную с внутренними идентификаторами. Каждый объект метаданных в 1С имеет свой внутренний уникальный идентификатор (UUID). Если вы создали регистр в копии базы вручную и такой же регистр (с тем же именем) создали в рабочей базе тоже вручную, их UUID будут разными.
Когда вы попытаетесь «накатить» конфигурацию из копии в рабочую базу через «Загрузить конфигурацию из файла», система увидит, что ID регистра в файле не совпадает с ID регистра в базе. Для платформы это означает, что старый регистр нужно удалить, а новый (с тем же именем, но другим ID) — создать. Результат: пустая таблица. Проанализируем процесс: всегда используйте только «Сравнить и объединить» для переноса доработок между базами, чтобы сохранить идентификаторы объектов.
Даже если регистр является независимым и непериодическим, у его измерений может быть включено свойство Ведущее. Проанализируем ситуацию: если измерение ссылается на объект (например, документ или справочник), который в процессе обновления подвергся серьезной реструктуризации или был программно пересоздан обработчиками обновления, сработает механизм «очистки ссылок».
Если объект-владелец (на который указывает ведущее измерение) удаляется, 1С автоматически удаляет все записи в регистрах сведений, где это измерение заполнено данной ссылкой. В типовых конфигурациях при переходе на новые версии часто запускаются скрытые процедуры конвертации данных, которые могут заменять ссылки или очищать «мусорные» объекты, что косвенно бьет по вашим регистрам.
Посмотрим на ситуацию со стороны кода. В современных конфигурациях на базе БСП (Библиотека стандартных подсистем) после обновления (при первом запуске в режиме «Предприятие») выполняются обработчики обновления. Иногда в этих обработчиках заложена логика очистки «неактуальных» данных. Если ваш самописный регистр по ошибке попал в состав какой-либо стандартной подсистемы (например, включен в состав функциональных опций или подписок на события), типовой код может очистить его, посчитав данные некорректными.
Обратите внимание на подписки на события. Рассмотрим пример подозрительного кода в подписке ПередЗаписью, который часто встречается при попытках «заглушить» функционал:
Процедура ИмяПроцедуры_ПередЗаписью(Источник, Отказ) Экспорт
Возврат; // Прерывание выполнения
// Дальнейшая логика, которая никогда не сработает
Если ТипЗнч(Источник) = Тип("ДокументОбъект.СчетНаОплатуПокупателю") Тогда
// Запись в регистр
КонецЕсли;
КонецПроцедуры
Если запись в ваш регистр происходит через подписки на события типовых документов, а после обновления эти подписки были изменены или «заремированы» (закомментированы), данные перестанут поступать, а старые могут быть перезаписаны пустыми значениями при массовом перепроведении документов обработчиками обновления.
Рассмотрим пошагово, как выяснить, в какой момент произошла очистка:
ПередЗаписью. Проанализируйте стек вызова: какая процедура инициирует очистку._InfoRegXXXX (где XXXX — внутренний номер регистра). Если после обновления номер таблицы изменился, значит, произошла пересоздание (дроп) таблицы.Чтобы избежать подобных проблем в будущем, разберем правильную последовательность действий:
И помните: если регистр независимый и записи в него вносятся вручную, платформа никогда не очистит его «просто так». Причиной всегда является либо явное действие программиста в окне объединения, либо работа программного кода (триггеров, подписок), либо удаление ведущих объектов-владельцев.