Ситуация, когда документы в информационной базе начинают «самопроизвольно» помечаться на удаление, является одной из самых неприятных для администратора и программиста 1С. Особенно критично это проявляется в связке 1С:CRM и УТ 10.3, где автоматизация процессов глубоко интегрирована в типовые механизмы торговли. В данной статье мы разберем, почему документы могут помечаться на удаление «рандомно», как диагностировать проблему, если журнал регистрации не дает четких ответов, и что делать в случае системных сбоев на уровне СУБД.
Первым делом нам необходимо выяснить, какой именно программный код инициирует установку пометки удаления. Часто это происходит не в самом модуле документа, а в общих модулях или подписках. Проанализируем ситуацию, выполнив глобальный поиск по конфигурации. Нам необходимо искать все вхождения следующих конструкций:
УстановитьПометкуУдаления — это метод объекта, который чаще всего используется для программного изменения состояния.ПометкаУдаления = Истина — прямое присваивание значения реквизиту (обычно встречается перед вызовом метода Записать()).Важно помнить, что поиск нужно проводить не только в основной конфигурации, но и в расширениях, если они используются. Рассмотрим пример типичной подписки на событие ПередЗаписью, которая может каскадно помечать связанные объекты:
Процедура ПриЗаписиСвязанногоОбъектаПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Если Источник.ПометкаУдаления Тогда
// Логика, которая может случайно зацепить лишние документы
МассивСсылок = НайтиСвязанныеДокументы(Источник.Ссылка);
Для Каждого СсылкаИзСписка Из МассивСсылок Цикл
ОбъектСвязи = СсылкаИзСписка.ПолучитьОбъект();
ОбъектСвязи.УстановитьПометкуУдаления(Истина);
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Разберем этот код: если в условии НайтиСвязанныеДокументы допущена логическая ошибка, система может начать «веерно» помечать реализации при удалении невинного входящего письма или события CRM.
Если журнал регистрации показывает, что изменения вносятся под пользователем, который в данный момент не работает в системе, это верный признак работы регламентного задания. В 1С:CRM часто предустановлены задания по очистке почты, поиску дублей или синхронизации с внешними сервисами.
Проанализируем список активных регламентных заданий в консоли. Особое внимание стоит уделить:
Посмотрим на пример кода, который может запускаться в фоновом задании и приводить к пометке на удаление:
Процедура ВыполнитьОчисткуУстаревшихСобытий() Экспорт
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ Ссылка ИЗ Документ.Событие ГДЕ Дата < &ПороговаяДата";
Запрос.УстановитьПараметр("ПороговаяДата", ДобавитьМесяц(ТекущаяДата(), -12));
Результат = Запрос.Выполнить().Выбрать();
Пока Результат.Следующий() Цикл
Объект = Результат.Ссылка.ПолучитьОбъект();
Объект.УстановитьПометкуУдаления(Истина);
КонецЦикла;
КонецПроцедуры
Если в такой запрос по ошибке попадут ссылки на Документ.РеализацияТоваровУслуг, мы получим тот самый «рандомный» эффект удаления документов.
Наиболее сложный случай — это когда журнал регистрации фиксирует транзакцию как «Отменена», но пометка удаления в базе данных все равно остается. Это указывает на критическую проблему взаимодействия платформы 1С и СУБД (PostgreSQL или MS SQL).
Выясним причину такого поведения. Существует известный баг платформы (встречался в версиях 8.3.10–8.3.12), при котором в условиях высокой нагрузки или некорректного завершения процесса rphost, команда ROLLBACK (откат) отправлялась в СУБД слишком поздно или не доходила. В итоге:
Объект.Записать() внутри транзакции.Для решения этой проблемы необходимо обновить платформу до актуального релиза и проверить настройки PostgreSQL (параметры synchronous_commit и fsync). Также стоит временно отключить использование расширений конфигурации, так как они могут влиять на стабильность выполнения транзакций.
Если обычные логи не помогают, нам придется задействовать Технологический журнал (ТЖ). Это позволит увидеть, какие именно SQL-запросы уходят в базу в момент установки пометки удаления. Создадим файл конфигурации logcfg.xml, который будет собирать события ошибок и запросов к БД:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\LOGS\DB_UPDATE" history="24">
<event>
<eq property="Name" value="DBV8DBPostgr"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="All"/>
</log>
</config>
Проанализируем полученные файлы логов. Нам нужно найти SQL-инструкции UPDATE для таблицы документа (например, _Document150), где меняется поле _Marked. Рядом с этим событием в ТЖ будет указан номер сеанса и имя процесса, что позволит однозначно идентифицировать виновника — будь то внешняя обработка, мобильное приложение или некорректно работающий скрипт интеграции.
Подведем итог и составим план действий для устранения проблемы:
Помните, что в сложных интеграциях Первого Бита часто используются защищенные модули. Если причина кроется в них, самостоятельно найти код не удастся — в этом случае требуйте от техподдержки анализа работы именно их закрытых фоновых заданий (модули лицензирования или защиты конфигурации).