Почему в 1С:ЗУП перестала работать регистрация документов на узлах обмена после обновления

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом IT и автоматизация бизнеса
← На главную

При переходе на новые релизы конфигурации 1С:Зарплата и управление персоналом (начиная с 3.1.27) многие технические специалисты сталкиваются с неприятной ситуацией: документы, такие как ВедомостьНаВыплатуЗарплатыПеречислением или ПлатежноеПоручение, перестают автоматически регистрироваться на узлах обмена при записи или проведении. Это происходит даже в тех случаях, когда в конфигурации прописаны кастомные подписки на события или используется стандартный механизм БСП.

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

Анализ проблемы и исходного кода

Рассмотрим ситуацию, когда в системе реализована процедура для регистрации документов через универсальный формат. Типичный пример кода, который исправно работал в версии 3.1.23, выглядит следующим образом:


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

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

Изменение логики в подсистеме обмена данными

Выясним причину такого поведения. В новых версиях БСП процедура ЗарегистрироватьИзменениеОбъекта стала использовать более строгую проверку на модифицированность объекта. Проанализируем ключевой фрагмент кода в общем модуле:


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

Раньше (в старых релизах) при проведении документа переменная ОбъектМодифицирован часто принимала значение Истина по умолчанию или в силу менее строгих проверок. Теперь же функция ОбъектМодифицированДляПланаОбмена выполняет реальное сравнение данных объекта с данными, уже записанными в базе. Если значимые реквизиты (входящие в состав обмена) не изменились, система считает регистрацию избыточной и возвращает Ложь.

Разберем работу функции ОбъектМодифицированДляПланаОбмена

Эта функция является "сердцем" современной регистрации. Рассмотрим, на что она обращает внимание при анализе:

  1. Состав плана обмена: Проверяются только те реквизиты, которые указаны в составе плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат. Если вы изменили комментарий, а он не участвует в обмене, регистрация не произойдет.
  2. Хеширование данных: В последних версиях система вычисляет хеш-сумму значимых полей. Если хеш нового состояния совпадает с хешем в БД, объект игнорируется.
  3. Фильтры регистрации: Если для узла настроены фильтры (например, по организации или подразделению), и объект под них не попадает, функция также вернет Ложь.

Таким образом, простое "перепроведение" документа без изменения сумм, дат или ключевых аналитик больше не вызывает автоматическую повторную отправку данных в другую базу (например, в 1С:Бухгалтерию).

Как решить проблему и вернуть регистрацию

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

Вариант 1: Прямая регистрация на узлах

Вместо вызова сложных механизмов БСП, которые пытаются "умничать" и экономить трафик, мы можем использовать прямой метод платформы ПланыОбмена.ЗарегистрироватьИзменения(). Посмотрим на пример кода:


Процедура ПринудительнаяРегистрацияНаУзлах(Источник)
    ПланОбменаИмя = "СинхронизацияДанныхЧерезУниверсальныйФормат";
    ВыборкаУзлов = ПланыОбмена[ПланОбменаИмя].Выбрать();
    
    Пока ВыборкаУзлов.Следующий() Цикл
        // Исключаем предопределенный узел (это наша текущая база)
        Если ВыборкаУзлов.Ссылка <> ПланыОбмена[ПланОбменаИмя].ЭтотУзел() Тогда
            ПланыОбмена.ЗарегистрироватьИзменения(ВыборкаУзлов.Ссылка, Источник);
        КонецЕсли;
    КонецЦикла;
КонецПроцедуры

Этот метод работает безусловно и игнорирует любые проверки модифицированности, внедренные в БСП.

Вариант 2: Использование ДополнительныхСвойств

Как мы видели в коде общего модуля, система проверяет наличие свойств ОтложеннаяЗапись или ОтложенноеПроведение. Мы можем попробовать "обмануть" механизм, добавив признак модифицированности программно перед вызовом регистрации:


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

Однако этот способ менее надежен, так как логика БСП может измениться в следующем патче.

Вариант 3: Отладка функции сравнения

Если документы не регистрируются даже при реальном изменении данных, нам необходимо зайти отладчиком внутрь ОбменДаннымиРегистрацияСервер.ОбъектМодифицированДляПланаОбмена. Проанализируем ситуацию:

Особенности для Ведомостей и Платежных поручений в ЗУП 3.1.27

Важно учитывать, что в последних релизах ЗУП была переработана внутренняя структура учета НДФЛ и взаиморасчетов. Это привело к тому, что некоторые поля, которые раньше были "ведущими", теперь могут заполняться иначе. Если ваша кастомная логика регистрации опирается на момент ПередЗаписью, попробуйте перенести её в ПриЗаписи, когда физическое состояние объекта в базе данных уже обновлено. Это позволит функции ОбъектМодифицированДляПланаОбмена корректно сопоставить старое и новое значения.

Заключение

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

← На главную