Почему не снимаются объекты с регистрации при обмене между 1С:ERP и 1С:УПП и как настроить счетчик сообщений

Настройка обмена данными между такими сложными конфигурациями, как 1С:ERP Управление предприятием и 1С:Управление производственным предприятием (УПП), часто сопровождается техническими нюансами. Одна из наиболее распространенных и неприятных проблем — ситуация, когда файлы обмена успешно передаются в обе стороны, номера сообщений в заголовках XML корректны, однако объекты в базе-отправителе упорно не снимаются с регистрации. Это приводит к тому, что при следующей выгрузке система пытается отправить те же самые данные повторно, неоправданно увеличивая объем файлов и нагрузку на сервер.

В этой статье мы подробно разберем, почему счетчик принятых сообщений может оставаться на нуле или почему при его росте не происходит очистка таблиц регистрации изменений. Мы проанализируем внутренние механизмы Библиотеки стандартных подсистем (БСП) и определим конкретные шаги для решения проблемы.

Механизм работы подтверждений в 1С:Предприятие

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

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

Проблема 1: Односторонний обмен и «пустые» правила в УПП

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

1. Отсутствие метаданных в ответе: Даже если данные из УПП не нужны в ERP, ответный файл должен содержать корректный заголовок XML. Если правила в УПП не настроены или узел обмена не инициализирован должным образом, формируемый файл может игнорироваться БСП в ERP как неинформативный.
2. Эмуляция приема: Как отмечалось в обсуждении, база-получатель (УПП) должна не просто отправить «пустой» XML, а подтвердить, что она приняла пакет с конкретным номером. Для этого в УПП должен быть настроен тот же код узла обмена, что и в ERP.

Решение: Попробуем в УПП в правилах обмена добавить хотя бы один фиктивный объект или один неиспользуемый справочник. Это заставит механизм обмена отработать полный цикл формирования сообщения с заполнением всех необходимых структур заголовка.

Проблема 2: Поиск места сбоя в коде ERP

Если номера в файлах (НомерИсходящегоСообщения и НомерВходящегоСообщения) выглядят корректно, но регистрация не снимается, нам необходимо локализовать место в коде ERP, где должна происходить очистка. Разберем по шагам, где ставить точки останова для отладки:

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

Проанализируем примерный фрагмент кода, который отвечает за удаление регистрации в типовых конфигурациях:

Процедура УдалитьРегистрациюИзмененийНаУзле(УзелИнформационнойБазы, НомерПринятогоСообщения)
    
    Если НомерПринятогоСообщения = 0 Тогда
        Возврат;
    КонецЕсли;
    
    // Платформенный метод, который очищает записи в таблицах регистрации 
    // для всех объектов, у которых номер сообщения меньше или равен переданному
    ПланыОбмена.УдалитьРегистрациюИзменений(УзелИнформационнойБазы, НомерПринятогоСообщения);
    
КонецПроцедуры

Если при отладке вы видите, что этот код срабатывает, но объекты остаются в таблице, проверьте соответствие номеров. Например, если в таблице регистрации объект зафиксирован под номером сообщения 46, а НомерПринятогоСообщения равен 24, то очистка для этого объекта не произойдет. Это логично: система считает, что этот объект был изменен уже после того, как пакет №24 был сформирован.

Проблема 3: Влияние ручной регистрации (Подписки на события)

Часто в ERP для гибкости настройки отключают авторегистрацию объектов и используют собственные подписки на события. Разберем, может ли это мешать процессу:

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

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

Практические рекомендации по «лечению» обмена

Для исправления ситуации выполним следующие действия:

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

   
   УзелОбъекта = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоКоду("ФП");
   НомерДляОчистки = УзелОбъекта.НомерПринятого;
   ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбъекта, НомерДляОчистки);
   

   Если после этого объекты исчезли из регистрации — значит, стандартный механизм БСП по какой-то причине обходит эту процедуру стороной при загрузке файла.
4. Настройка правил регистрации: Даже при одностороннем обмене рекомендуется иметь хотя бы базовые правила регистрации в обеих базах. Это гарантирует, что программные интерфейсы БСП будут корректно инициализировать структуры данных, необходимые для обмена служебной информацией (подтверждениями).

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