Почему не регистрируются объекты в плане обмена 1С и как это исправить?

Работа в распределенных информационных базах (РИБ) на платформе 1С — это всегда баланс между стабильностью каналов связи, производительностью СУБД и корректностью программного кода. Иногда администраторы и разработчики сталкиваются с аномальным поведением системы: обмен данными работает исправно месяцами, но в какой-то момент регистрация изменений по определенным объектам полностью прекращается. При этом в Журнале регистрации нет абсолютно никаких ошибок, а сама проблема через несколько дней может «самопроизвольно» исчезнуть.

Давайте подробно разберем эту ситуацию на примере конфигурации УПП (Управление производственным предприятием) и выясним, какие скрытые механизмы платформы и особенности СУБД могут приводить к избирательному отказу регистрации изменений.

1. Влияние свойства ОбменДанными.Загрузка

Первое, на что стоит обратить внимание при анализе механизмов обмена — это использование свойства ОбменДанными.Загрузка при записи объектов. В стандартных конфигурациях 1С (особенно построенных на базе Библиотеки стандартных подсистем или классических решений вроде УПП) это свойство регулирует поведение подписок на события и встроенных обработчиков конфигурации.

Когда данные записываются программно (например, при загрузке из внешних систем, работе обработок группового изменения или интеграциях), разработчики часто устанавливают признак загрузки в значение Истина:

Объект.ОбменДанными.Загрузка = Истина;
Объект.Записать();

Рассмотрим, к чему это приводит. В платформе 1С при установке этого свойства отключается большинство стандартных проверок в модулях объектов, а также блокируется выполнение подписок на события, которые отвечают за авторегистрацию изменений. Если в вашей базе регистрация реализована через подписки на события перед записью или при записи (что является стандартом для многих конфигураций), то использование ОбменДанными.Загрузка = Истина полностью заблокирует попадание объекта в план обмена.

Для решения этой проблемы необходимо проанализировать код кастомных обработок, регламентных заданий и внешних интеграций, работавших в период сбоя. Если запись объектов выполнялась с этим флагом, следует пересмотреть логику: либо регистрировать изменения принудительно, либо отказаться от флага в пользу стандартной записи. Для быстрой отправки пропущенных данных подойдёт обработка для массовой регистрации объектов к обмену.

2. Отключение автозаполнения получателей в коде

Еще один частый сценарий программного обхода регистрации изменений — это манипуляция коллекцией получателей конкретного объекта. У каждого объектного типа данных в 1С есть свойство ОбменДанными.Получатели, которое управляет тем, для каких именно узлов планов обмена будет зарегистрировано изменение при записи.

Разберем пример кода, который разработчики используют для «тихой» записи объекта без его миграции по сети распределенной базы:

Объект.ОбменДанными.Получатели.АвтоЗаполнение = Ложь;
Объект.ОбменДанными.Получатели.Oчистить();
Объект.Записать();

Если этот код выполняется в контексте работы обычного пользователя (например, при проведении документа через кастомную кнопку, регламентную процедуру или при проведении зависимых документов), объект запишется в базу успешно, но в таблицу регистрации изменений не попадет. При этом никаких записей об ошибках в Журнале регистрации не появится, так как с точки зрения платформы это штатное, задокументированное поведение.

Рекомендуется выполнить глобальный поиск по конфигурации и внешним обработкам по ключевому слову АвтоЗаполнение = Ложь, чтобы локализовать места, где разработчики могли намеренно или случайно отключить авторегистрацию.

3. Динамическое обновление конфигурации («демонское» обновление) и кэш метаданных

Если сбой в регистрации носил временный характер (продолжался ровно два дня и затрагивал разных пользователей и разные объекты), одной из наиболее вероятных причин является проведение динамического обновления конфигурации базы данных.

Динамическое обновление (когда изменения вносятся в базу без монопольного выгона пользователей) — известная зона риска для платформы 1С. При этом процессе на сервере приложений или на рабочих станциях пользователей кэш метаданных может обновиться некорректно. Рассмотрим последствия этого сбоя:

1. Сбой вызова подписок на события: Платформа хранит список активных подписок в кэше. После динамического обновления у некоторых сеансов пользователей подписки на события (отвечающие за регистрацию изменений) могут просто перестать инициализироваться.
2. Избирательность проблемы: Сбой проявляется хаотично. У одного пользователя (чей сеанс не обновил кэш) документы не регистрируются в плане обмена, а у другого пользователя (который зашел в систему позже) все работает корректно.
3. Отсутствие ошибок: В Журнале регистрации не фиксируется никаких аномалий, так как для платформы транзакция записи документа завершается штатно, просто обработчик регистрации не вызывается.

Выясним, как с этим бороться. Единственный надежный способ устранить последствия такого сбоя — это полная очистка кэша на сервере 1С:Предприятие (перезапуск службы сервера с предварительным удалением папки сомнительных кэшей) и очистка локального кэша у пользователей. Это полностью объясняет, почему через 2 дня (например, после планового перезапуска сервера в выходные) проблема исчезла сама собой.

4. Скрытые ошибки в конструкциях Попытка — Исключение

Проанализируем ситуацию, когда регистрация изменений прописана программно в модулях конфигурации. Очень часто разработчики, пытаясь обезопасить транзакцию записи основного документа от падения из-за ошибок обмена, оборачивают вызов регистрации в блок обработки исключений.

Посмотрим на классический пример опасного кода:

Попытка
    ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ОбъектСсылка);
Исключение
    // Ошибка перехвачена, но никак не обработана и не записана в журнал
КонецПопытки;

В случае возникновения любой нештатной ситуации (например, кратковременная блокировка таблицы регистрации на уровне СУБД, нехватка прав доступа у конкретного пользователя на чтение узла плана обмена, повреждение структуры базы данных), платформа перейдет в ветку Исключение. Объект будет успешно записан в базу данных, транзакция зафиксируется, но регистрация изменений «молча» сорвется.

Давайте перепишем этот блок кода правильно, с обязательной фиксацией проблемы в Журнале регистрации:

Попытка
    ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ОбъектСсылка);
Исключение
    ЗаписатьВЖурналРегистрации(
        "ОбменДанными.ОшибкаРегистрации",
        УровеньЖурналаРегистрации.Ошибка,
        ОбъектСсылка.Метаданные(),
        ОбъектСсылка,
        ПодробноеПредставлениеОшибки(ИнформацияОбОшибке())
    );
КонецПопытки;

Используя правильную обработку исключений, вы всегда будете видеть реальную картину происходящего в Журнале регистрации.

5. Блокировки таблиц регистрации СУБД (Deadlocks)

На высоконагруженных базах данных, таких как УПП, критически важным фактором является производительность СУБД (MS SQL Server, PostgreSQL). Для каждого плана обмена в базе данных создаются служебные таблицы регистрации изменений. На уровне СУБД они имеют постфикс _ChngR.

При интенсивной работе пользователей (например, массовое проведение документов, проведение тяжелых цепочек документов, групповое перепроведение за прошлые периоды) таблицы регистрации подвергаются частым операциям записи и удаления. Рассмотрим механизм возникновения проблемы:

• Транзакция записи основного документа завершается успешно.
• Параллельно пытается выполниться запись в таблицу регистрации изменений _ChngR.
• Если СУБД фиксирует взаимоблокировку (deadlock) или таймаут ожидания блокировки из-за параллельных транзакций других пользователей, транзакция записи в таблицу регистрации может откатиться.
• В ряде случаев, при специфических настройках СУБД или особенностях работы платформы 1С, этот откат может произойти без аварийного завершения сеанса пользователя, приводя к потере регистрации изменения.

6. Правила регистрации объектов (ПРО) и режим выгрузки «При необходимости»

Если в вашем плане обмена используются сложные правила регистрации объектов (настроенные, например, через «Конвертацию данных» или встроенные механизмы БСП), логика регистрации перестает быть линейной.

Рассмотрим две важные настройки, которые могут сымитировать сбой регистрации:

1. Режим выгрузки «При необходимости»: При таком режиме объект (например, договор контрагента или номенклатура) регистрируется к обмену только тогда, когда он входит в состав другого выгружаемого объекта (например, ссылки в документе продажи). Если пользователи создавали такие справочники «впрок» без привязки к документам, они не будут зарегистрированы в течение этих двух дней. Как только документы с ними были проведены — объекты сразу ушли в обмен.
2. Несовпадение отборов по аналитике: Правила обмена часто содержат жесткие фильтры (например, выгружать документы только по определенной Организации или Складу). Если пользователи ошибочно ввели пул документов по другой организации, эти документы закономерно проигнорируют регистрацию. После того как бухгалтеры заметили ошибку и исправили Организацию в документах на разрешенную, авторегистрация мгновенно сработала, создав иллюзию того, что «все само починилось».

Рекомендованный план диагностики при повторении проблемы

Если вы снова столкнулись с тем, что объекты перестали регистрироваться в плане обмена, рекомендуем действовать по следующему алгоритму:

1. Выясните, проводилось ли в ближайшее время динамическое обновление конфигурации. Если да — выполните очистку кэша сервера и перезапустите службу 1С.
2. Проверьте права доступа пользователей, у которых не прошла регистрация. Достаточно ли у них прав на чтение и изменение самого плана обмена?
3. Выполните замер производительности СУБД на предмет наличия взаимоблокировок (deadlocks) в моменты записи документов.
4. Проверьте, не запускались ли в этот период специализированные обработки интеграции, которые могли программно устанавливать ОбменДанными.Загрузка = Истина или очищать коллекцию получателей.