В конфигурациях 1С, работающих в режиме совместимости, иногда возникает ситуация, когда штатный механизм "История данных" корректно фиксирует создание и изменение записей в регистре сведений, но полностью игнорирует их удаление. Давайте подробно разберемся, почему так происходит и какие есть способы решения этой проблемы.
Проанализируем ситуацию: у нас есть независимый, непериодический регистр сведений (например, Штрихкоды в УТ 10.3). Для него включен механизм "История данных" с опцией "Обновлять историю данных сразу после записи". При добавлении новой записи история сохраняется, но при удалении — в отчетах по истории пусто. Выясним, в чем может быть причина и что с этим делать.
Прежде всего, важно понимать, что стандартный платформенный механизм "История данных", появившийся начиная с версии 8.3.11, предназначен для отслеживания всего жизненного цикла данных, включая удаление. Его задача — фиксировать абсолютно все действия пользователей.
Когда вы удаляете запись из регистра сведений, механизм не просто стирает информацию о ней. Вместо этого он создает новую специальную версию записи, которая помечает данный набор измерений как "удаленный". Это позволяет в стандартных отчетах по истории изменений увидеть, кто и когда удалил запись. Таким образом, сама идея механизма полностью покрывает фиксацию удалений.
Если на практике удаление не фиксируется, скорее всего, мы столкнулись с техническими особенностями или ограничениями конкретной конфигурации и версии платформы. Рассмотрим основные причины.
Асинхронное обновление истории
Это одна из самых частых причин. Даже при включенной опции "Обновлять историю данных сразу после записи", механизм не всегда записывает изменения в таблицы истории мгновенно. Сначала информация об изменении (включая удаление) помещается в специальную очередь. Фактический перенос данных из этой очереди в постоянное хранилище истории происходит при выполнении команды ИсторияДанных.ОбновитьИсторию().
Обычно для этой операции настраивается отдельное регламентное задание. Если это задание не настроено, отключено или выполняется с ошибками, информация об удалении так и останется в промежуточной очереди, не попадая в отчеты. В старых конфигурациях или в сложных режимах совместимости опция немедленного обновления может не отрабатывать корректно именно для операций удаления.
Что делать:
_DataHistory...), чтобы проверить, есть ли там вообще какие-либо данные об удаленных объектах.Версия платформы и режим совместимости
Функциональность "Истории данных" постоянно дорабатывалась. Возможно, в используемой вами комбинации версии платформы и режима совместимости (например, 8.3.13) существуют ошибки или ограничения в работе этого механизма именно для независимых непериодических регистров сведений. Режим совместимости, сохраняя старое поведение, может мешать корректной работе новых платформенных механизмов.
Что делать:
Путаница с механизмом "Версионирование объектов"
Важно не путать два разных механизма: "История данных" (платформенный) и "Версионирование объектов" (из Библиотеки стандартных подсистем). У них разные настройки и принципы работы. Убедитесь, что вы настроили именно платформенную "Историю данных", а не старый механизм версионирования, который мог иметь свои ограничения.
Если диагностика не дала результатов или изменение настроек невозможно, существует надежный и проверенный архитектурный подход, который позволяет полностью контролировать "удаление" записей. Суть его в том, чтобы не удалять записи физически, а делать их неактивными.
Разберем этот метод по шагам:
Добавление реквизита "Активность"
В структуру регистра сведений (в нашем примере Штрихкоды) добавляется новый реквизит, например, Активность с типом Булево. Он может быть как ресурсом, так и измерением, в зависимости от логики. Чаще его делают ресурсом.
Изменение логики "удаления"
Вместо физического удаления записи из регистра, код теперь должен изменять значение реквизита Активность на Ложь. С точки зрения механизма "История данных", это будет обычное изменение записи, которое он гарантированно зафиксирует. Вы всегда сможете увидеть, кто и когда "удалил" (то есть сделал неактивным) штрихкод.
Доработка всех запросов
Это самый важный и трудоемкий этап. Все запросы в конфигурации, которые обращаются к этому регистру сведений, необходимо модифицировать. В условие ГДЕ нужно обязательно добавить проверку нового флага.
Например, старый запрос:
ВЫБРАТЬ
Штрихкоды.Штрихкод,
Штрихкоды.Номенклатура
ИЗ
РегистрСведений.Штрихкоды КАК Штрихкоды
ГДЕ
Штрихкоды.Номенклатура = &Номенклатура
Должен быть изменен на:
ВЫБРАТЬ
Штрихкоды.Штрихкод,
Штрихкоды.Номенклатура
ИЗ
РегистрСведений.Штрихкоды КАК Штрихкоды
ГДЕ
Штрихкоды.Номенклатура = &Номенклатура
И Штрихкоды.Активность = ИСТИНА
Как справедливо заметили на форуме, это может потребовать значительных усилий. В типовой конфигурации количество таких запросов может исчисляться сотнями. Однако такой подход считается хорошей практикой, так как он дает полный контроль над данными.
Подведем итог. Если вы столкнулись с тем, что "История данных" не фиксирует удаление записей регистра сведений, действуйте в следующем порядке:
Активность. Хоть это и требует доработки кода, вы получите полный контроль над жизненным циклом записей, возможность легкого восстановления "удаленных" данных и гарантированную фиксацию всех изменений в истории.