Мы с вами рассмотрим крайне необычную и потенциально критичную проблему, с которой сталкиваются пользователи 1С:Документооборот: система, казалось бы, "самостоятельно" помечает на удаление ключевые настройки обработки видов объектов. Такое поведение может привести к полной остановке движения документов и серьезным сбоям в работе предприятия. Давайте вместе проанализируем возможные причины и найдем пути решения этой загадки.
Прежде чем углубляться в детали, важно вспомнить, как работает механизм удаления объектов в платформе 1С:Предприятие. Объекты не удаляются из базы данных мгновенно. Сначала они помечаются на удаление. Это своеобразный флаг, который сообщает системе о намерении удалить объект. Фактическое удаление происходит позже, посредством специальной обработки "Удаление помеченных объектов". Этот двухэтапный процесс необходим для поддержания ссылочной целостности базы данных, предотвращая удаление объектов, на которые существуют ссылки в других местах. В нашем случае, речь идет о НастройкахОбработкиВидовОбъектов, которые являются критически важными для корректного функционирования документооборота.
Когда пользователи говорят, что система что-то делает "самостоятельно", это обычно означает, что действие произошло без их явного участия и понимания. В контексте 1С:Предприятие, пометка на удаление, если она не была выполнена пользователем вручную, почти всегда является результатом программного кода. Мы с вами должны понимать, что система не обладает собственным "интеллектом" для принятия таких решений. Это действие может быть:
Пометка на удаление таких объектов, как НастройкиОбработкиВидовОбъектов, является критически важным событием, так как эти настройки определяют маршруты согласования, правила обработки и другие ключевые параметры для различных типов документов. Их удаление полностью парализует работу с соответствующими видами документов.
Как верно было подмечено в одном из сообщений форума, журнал регистрации является нашим основным инструментом для выявления источника проблемы. В нем фиксируются все значимые события, происходящие в системе: действия пользователей, фоновые задания, ошибки и, что особенно важно для нас, изменения объектов, включая их пометку на удаление.
Чтобы эффективно использовать журнал регистрации, мы с вами предпримем следующие шаги:
НастройкиОбработкиВидовОбъектов являются элементами справочника.НастройкаОбработкиВидаОбъектов или ВидДокумента, к которому эти настройки относятся. В некоторых случаях это может быть просто Справочник или другой типовой объект, к которому относятся эти настройки. В идеале, мы хотим найти записи, где объект явно относится к тем настройкам, которые были помечены на удаление.Нас будут интересовать записи, где явно указана установка пометки на удаление для объектов типа "Настройки обработки видов объектов". В идеале, запись будет содержать информацию о том, кто и когда выполнил это действие, а также приложение, через которое это действие было инициировано (например, "Фоновое задание").
Давайте рассмотрим наиболее распространенные сценарии, которые могут привести к "самостоятельной" пометке на удаление в 1С:Документооборот, основываясь на нашем понимании платформы и опыте.
Иногда при обновлении конфигурации или платформы разработчики могут изменять структуру хранения данных или логику работы с определенными объектами. В результате этого старые или несовместимые настройки могут быть автоматически помечены на удаление системой, чтобы предотвратить конфликты или некорректную работу. Мы с вами должны проверить историю обновлений: не было ли недавних обновлений, которые могли вызвать такое поведение? Если обновления были, внимательно изучите описание изменений к ним. Иногда типовые обновления включают миграцию данных, в ходе которой устаревшие объекты помечаются на удаление.
Если в вашей системе 1С:Документооборот используются нетиповые доработки, расширения или внешние обработки, существует вероятность того, что именно их код вызывает пометку на удаление. Ошибка в логике этих доработок может приводить к нежелательным действиям. Мы с вами должны проанализировать, какие доработки были установлены или изменены незадолго до возникновения проблемы. Возможно, один из разработчиков случайно или ошибочно добавил код, который выполняет пометку на удаление. Такой код может выглядеть примерно так:
// Пример некорректного кода, который может быть в доработке
// или фоновом задании
&НаСервере
Процедура ОбработкаУстаревшихНастроек()
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| НастройкиОбработкиВидовОбъектов.Ссылка
|ИЗ
| Справочник.НастройкиОбработкиВидовОбъектов КАК НастройкиОбработкиВидовОбъектов
|ГДЕ
| НастройкиОбработкиВидовОбъектов.ЭтоУстаревшиеНастройки"; // Условие, которое ошибочно определяет настройки как устаревшие
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектНастройки = Выборка.Ссылка.ПолучитьОбъект();
Если ОбъектНастройки <> Неопределено Тогда
ОбъектНастройки.УстановитьПометкуУдаления(Истина);
ОбъектНастройки.Записать();
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Или же, какая-то регламентная обработка, написанная сторонним разработчиком, могла выполнять подобное действие. Используйте поиск по конфигурации, чтобы найти все вхождения УстановитьПометкуУдаления(Истина) и проанализируйте контекст их вызова.
В 1С существует функционал для автоматического удаления помеченных объектов по расписанию. Хотя чаще всего это касается объектов, помеченных вручную, теоретически, если какая-то фоновая задача сначала помечает объекты (по причинам, описанным выше), а затем срабатывает регламентное задание на фактическое удаление, это может привести к их фактическому исчезновению из базы. Мы с вами должны проверить список и настройки регламентных заданий в вашей системе. Ищите задания, которые потенциально могли бы манипулировать данными или удалять объекты. В 1С:Документооборот есть стандартные регламентные задания, но также могут быть добавлены и кастомные, которые могли быть настроены некорректно.
Хотя и менее вероятно для такой специфической и повторяющейся проблемы (так как она воспроизвелась даже после восстановления из бэкапа), повреждение информационной базы также может приводить к непредсказуемому поведению системы, включая некорректную пометку объектов. Регулярное тестирование и исправление базы данных — это хорошая практика. Мы с вами можем выполнить это через конфигуратор (меню "Администрирование" -> "Тестирование и исправление информационной базы...") или с помощью утилиты chdbfl.exe для файловых баз. Однако, учитывая воспроизводимость проблемы (после восстановления из бэкапа), причина, скорее всего, кроется в логике программы, а не в физическом повреждении данных.
Некоторые сложные бизнес-процессы или специфические настройки маршрутизации документов в 1С:Документооборот могут иметь скрытые механизмы, которые при определенных условиях могут влиять на состояние других объектов. Это более редкий случай, но стоит его иметь в виду при глубоком анализе, особенно если вы используете сложную логику согласования и обработки документов.
Хотя "настройки обработки видов объектов" обычно не относятся к чисто пользовательским настройкам, некоторые операции по очистке или сбросу системных параметров могут косвенно затронуть и часть конфигурационных данных. Однако это маловероятно, поскольку такие настройки являются частью метаданных или справочников конфигурации и обычно не подвергаются случайному сбросу.
Основываясь на нашем анализе, мы с вами можем сформулировать четкий план действий для решения проблемы:
Мы видим, что автор уже восстановил базу из бэкапа, и это правильный первый шаг, чтобы временно вернуть работоспособность системы. Однако, как показал опыт, проблема воспроизводится, значит, причина не устранена. Этот шаг дает нам возможность выиграть время для диагностики.
Это самый важный шаг. Мы с вами должны немедленно приступить к анализу журнала регистрации после следующего воспроизведения проблемы. Запишите точное время, когда настройки были помечены на удаление. Отфильтруйте журнал по этому времени и по типам событий, связанным с изменением объектов или установкой пометки удаления. Обратите особое внимание на поле "Пользователь" или "Приложение". Если это не конкретный пользователь, ищите записи от фоновых заданий или системных процессов. Эта информация позволит нам определить, кто или что инициировало пометку на удаление.
Если журнал регистрации укажет на программное действие (например, от фонового задания или конкретного модуля), следующим шагом будет анализ исходного кода конфигурации. Мы с вами будем искать фрагменты кода, которые могли бы обращаться к объектам НастройкаОбработкиВидаОбъектов и устанавливать им пометку на удаление (метод УстановитьПометкуУдаления(Истина)). Особое внимание уделите нетиповым доработкам, расширениям и обработкам, которые были реализованы в вашей системе. Используйте поиск по конфигурации, чтобы найти все вхождения УстановитьПометкуУдаления и тщательно проанализируйте контекст их вызова, чтобы понять логику, которая приводит к пометке. Если вы обнаружите такой код в типовой конфигурации, это может быть баг, требующий обновления или обращения к разработчикам 1С.
Мы с вами должны просмотреть список всех активных регламентных заданий (через "Администрирование" -> "Настройки" -> "Поддержка и обслуживание" -> "Регламентные задания"). Особое внимание уделите заданиям, которые выполняются в фоновом режиме и могут иметь отношение к обработке документов, настроек или обслуживанию базы данных. Проанализируйте их расписание и код, если это кастомные задания. Возможно, одно из них запускает обработку, которая ошибочно помечает настройки на удаление.
Если после тщательного анализа журнала регистрации и кода вы не смогли локализовать проблему, возможно, потребуется помощь опытного специалиста по 1С:Документооборот или разработчика. Они смогут провести более глубокий анализ конфигурации и бизнес-логики вашей системы, используя свои знания и инструменты для отладки.
Хотя это менее вероятная причина для такой конкретной проблемы, регулярное тестирование и исправление базы данных через конфигуратор (меню "Администрирование" -> "Тестирование и исправление информационной базы...") или утилиту chdbfl.exe (для файловых баз) является хорошей профилактической мерой, которую мы с вами всегда должны выполнять для поддержания работоспособности системы.
Помните, что "самостоятельные" действия системы в 1С всегда имеют под собой логическую основу, закодированную в программе. Наша задача – найти этот код или настройку, которая инициирует нежелательное поведение. Тщательный анализ журнала регистрации – это первый и самый важный шаг на пути к решению этой проблемы.