В практике работы с конфигурациями 1С, такими как Управление нашей фирмой (УНФ) и Бухгалтерия предприятия (БП), часто возникают ситуации-загадки. Одна из самых неприятных — внезапное появление пометки на удаление у важного документа, при этом стандартный Журнал регистрации (ЖР) молчит о том, кто и когда совершил это действие. Разберем детально, как такое возможно, и проанализируем неочевидные механизмы платформы 1С:Предприятие 8.3.
Первым делом проанализируем ситуацию, описанную в теме. Пользователь видит запись от регламентного задания Удаление помеченных объектов с текстом «Данные. Удаление — Отменена». Это важный маркер: он означает, что система уже обнаружила объект с установленным признаком DeletionMark = True и попыталась его физически стереть из базы, но не смогла из-за наличия ссылок на этот документ. Значит, пометка была поставлена ранее. Почему же мы не видим событие «Данные. Изменение» с пометкой удаления?
Рассмотрим основные технические причины отсутствия записи:
ОбменДанными.Загрузка = Истина. В этом режиме платформа отключает многие стандартные проверки и, что критично, может изменять логику записи в Журнал регистрации._Marked в таблице базы данных напрямую через SQL-запрос. В этом случае ЖР вообще ничего не зафиксирует, так как действие происходит в обход сервера 1С.Разберем подробнее, как программный код может изменить состояние документа «невидимо» для обычного фильтра ЖР. Рассмотрим пример кода, который часто используется в правилах обмена или внешних обработках:
// Пример программной установки пометки удаления
ДокументОбъект = СсылкаНаДокумент.ПолучитьОбъект();
ДокументОбъект.ОбменДанными.Загрузка = Истина; // Включаем режим загрузки
ДокументОбъект.УстановитьПометкуУдаления(Истина);
ДокументОбъект.Записать();
Когда установлен флаг ОбменДанными.Загрузка, событие в ЖР все равно должно создаться, но оно может быть помечено не как действие конкретного пользователя, а как системное событие сеанса связи. Если вы ищете по фильтру «Пользователь», а обмен идет под специально выделенной системной учетной записью (или под фоновым заданием), вы просто не увидите эту запись.
Если у нас настроен односторонний обмен, нужно обязательно проверить Журнал регистрации в обеих базах. Посмотрим на ситуацию пошагово:
Журнал регистрации в базе УНФ (откуда приходят данные).Если в УНФ запись есть, а в БП — нет, значит, пометка «прилетела» вместе с пакетом синхронизации. В БП в ЖР это событие может отображаться под именем пользователя, от имени которого запускается Фоновое задание обмена (например, «Администратор» или «System»).
Иногда отсутствие записей связано с тем, что уровень детализации логов был намеренно или случайно снижен. Проанализируем настройки в конфигураторе:
Перейдем в меню Администрирование — Настройка журнала регистрации. Убедимся, что выбран режим «Регистрировать ошибки, предупреждения, информацию и примечания». Если выбрано только «Ошибки», то успешные действия по изменению и удалению документов записываться не будут.
Поскольку Журнал регистрации может быть очищен или неинформативен при программных изменениях, рекомендуется использовать механизм «История изменений» (Версионирование). Рассмотрим, как это помогает:
Записать().Важно: Если в вашей базе История изменений была выключена (как в случае автора темы), восстановить события задним числом через этот механизм невозможно. Это повод включить его прямо сейчас для наиболее критичных документов (Приходные накладные, Заказы покупателей).
Рассмотрим специфический сценарий обмена. В типовых правилах 1С существует логика «очистки» дублей или удаления объектов, которые были удалены в источнике. Если вы используете синхронизацию через универсальный формат, система может пометить документ на удаление в приемнике, если в источнике этот документ был физически удален (через Удаление помеченных объектов) или если он перестал попадать в фильтры обмена (например, у него изменилась дата на период, который не входит в текущую выгрузку).
Проанализируем действия пользователей. Часто бухгалтер в БП случайно помечает документ на удаление, думая, что это «черновик», а так как настроен односторонний обмен, УНФ об этом «не знает». Но если обмен двусторонний, то пометка может «мигрировать» между базами, создавая иллюзию хаотичного поведения системы.
Подведем итог нашего анализа. Если документ помечен на удаление, а в ЖР нет записи:
ОбменДанными.Загрузка = Истина может маскировать действия пользователя под системные процессы.Проблема «невидимых» удалений чаще всего кроется не в ошибке платформы, а в архитектуре распределенных систем, где действие в одной базе является лишь «отражением» события, произошедшего в другой.