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

← На главную

В процессе эксплуатации распределенных систем на базе 1С часто возникает ситуация, когда после успешной, на первый взгляд, выгрузки данных объекты остаются в узле плана обмена. Это приводит к тому, что при следующем сеансе система снова пытается выгрузить те же самые данные, создавая избыточную нагрузку и «замусоривая» файлы обмена. Особенно остро эта проблема проявляется после обновления платформы (например, на версию 8.3.16.1148) в связке «1С:Документооборот» — «1С:ERP».

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

Разбор механизма подтверждения (квитирования) сообщений

Для начала проанализируем базовый принцип работы любого обмена в 1С, использующего планы обмена. Важно понимать, что «односторонний обмен» — это понятие, относящееся к бизнес-данным (документам, справочникам), но с технической точки зрения обмен всегда должен быть двусторонним.

Рассмотрим, как это происходит по шагам:

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

Если второй этап (получение ответа) не выполняется или прерывается с ошибкой, регистрация не будет очищена, и объекты будут «висеть» в плане обмена вечно.

Проблема COM-соединения после обновления платформы

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

Во-первых, при работе через COM-соединение база-источник напрямую обращается к методам базы-приемника. Если после обновления платформы на сервере не была перерегистрирована компонента comcntr.dll или возник конфликт разрядности (например, сервер 64-бит, а COM-соединение инициализируется в 32-битном контексте), метод возврата номера сообщения может возвращать неопределенное значение или вызывать исключение, которое «проглатывается» кодом обмена.

Во-вторых, в версии 8.3.16 наблюдались проблемы с методом УдалитьРегистрациюИзменений(). Даже при корректном вызове метода записи из таблицы регистрации изменений физически не удалялись. Это платформенный баг, который лечится либо обновлением на более стабильную версию (например, 8.3.17 и выше), либо установкой соответствующих патчей.

Шаг 1: Проверка номеров сообщений в плане обмена

Выясним, на каком этапе происходит сбой. Для этого нам необходимо зайти в обе базы и сравнить номера сообщений в настройках обмена данными.

В базе ДО откройте настройки синхронизации и посмотрите на поле «Номер отправленного сообщения» и «Номер принятого сообщения».
Перейдите в базу ERP и посмотрите аналогичные поля.

Если в ДО НомерОтправленного постоянно растет (например, уже 500), а НомерПринятого замер на значении 100, это означает, что подтверждения от ERP не доходят или не обрабатываются. Проанализируем ситуацию: если ERP сообщает, что приняла сообщение №100, то все объекты, отправленные в сообщениях №101, №102 и далее, будут выгружаться повторно при каждом запуске.

Шаг 2: Анализ процесса «второго этапа» обмена

Как мы выяснили из обсуждения, обмен запускается из Документооборота и состоит из двух этапов. Разберем, что именно должно происходить во втором этапе. Даже если данные передаются только в сторону ERP, алгоритм должен быть следующим:


// Псевдокод логики подтверждения
Соединение = УстановитьCOMСоединение(ПараметрыERP);
// Этап 1: Выгрузка данных в ERP
РезультатВыгрузки = Соединение.ВыполнитьЗагрузкуДанных(ДанныеДляВыгрузки);

// Этап 2: Получение квитанции
// Даже если из ERP ничего не грузим, мы должны получить номер принятого сообщения
НомерПодтверждения = Соединение.ПолучитьНомерПоследнегоПринятогоСообщения();
ПланыОбмена.УдалитьРегистрациюИзменений(УзелERP, НомерПодтверждения);

Проверьте, не настроен ли обмен так, что он ожидает файл ответа. Если в настройках указан «Обмен через общий каталог», а ERP по какой-то причине перестала записывать туда файлы подтверждения (например, из-за прав доступа к папке после обновления ОС или платформы), то ДО никогда не узнает об успешной доставке.

Шаг 3: Проверка прав доступа и блокировок

Рассмотрим еще одну техническую причину. В новых версиях платформы 1С ужесточила контроль прав доступа. Пользователь, под которым устанавливается COM-соединение, должен обладать правами не только на чтение/запись данных, но и на «Администрирование данных» в отношении конкретного Плана обмена.

Также проанализируем влияние фоновых заданий. Если в момент попытки очистки регистрации в базе ДО запущено фоновое задание (например, «Расчет прав доступа»), таблица регистрации изменений может быть заблокирована. В платформе 8.3.16 это иногда приводило к молчаливому пропуску транзакции удаления без записи в Журнал регистрации.

Шаг 4: Диагностика через типовую обработку

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

Запустите типовую обработку «Регистрация изменений для обмена данными» (ее можно найти в разделе Администрирование или через функции для технического специалиста).
Выберите ваш узел обмена с ERP.
Посмотрите на количество зарегистрированных объектов.
Выполните обмен в обычном режиме.
Снова проверьте количество объектов в обработке. Если оно не уменьшилось — подтверждение не сработало.
Попробуйте в этой же обработке вручную нажать кнопку «Удалить регистрацию» (или «Очистить все»).

Если вручную регистрация удаляется без проблем, значит, инфраструктура плана обмена исправна, и проблема кроется именно в коде/процедуре вызова подтверждения во «втором этапе» обмена.