При настройке синхронизации между конфигурациями «Управление торговлей» (УТ) и «Бухгалтерия предприятия» (БП) часто возникает задача ограничить передачу определенных данных. Одной из наиболее популярных задач является полное исключение документов РеализацияТоваровУслуг из выгрузки. Это может потребоваться, если учет продаж ведется в БП вручную или документы поступают туда из другого источника.
Проанализируем различные способы решения этой задачи — от простых манипуляций в коде до использования профессиональных инструментов настройки правил регистрации. Разберем по шагам, как реализовать каждый из них, и выясним, какие риски несет каждый метод.
Это наиболее «цивилизованный» и рекомендуемый метод для современных конфигураций на базе БСП (Библиотека стандартных подсистем), использующих обмен через Enterprise Data. Правила регистрации объектов (ПРО) определяют условия, при которых документ вообще должен попадать в таблицу изменений плана обмена. После настройки правил для автоматизации постоянного обмена по расписанию без изменения конфигураций применяется программа для автоматического обмена данными между базами 1С.
Рассмотрим порядок действий для настройки ПРО:
РеализацияТоваровУслуг.ПередОбработкой. Это программная точка входа, которая срабатывает перед тем, как система решит, регистрировать объект или нет.
Отказ = Истина;
Важное преимущество: при использовании ПРО документ не будет регистрироваться даже при перепроведении. Это экономит ресурсы сервера и исключает «замусоривание» таблицы изменений.
Если мы не хотим возиться с внешними правилами регистрации или нам нужно более гибкое программное управление, проанализируем возможность использования подписки на события. Этот метод хорош тем, что он не требует внесения изменений в типовой код модулей документов, что упрощает дальнейшее обновление конфигурации. При сохранении типовой конфигурации для автоматического проведения технического обслуживания баз применяется программа автоматического обновления и тестирования 1С.
Создадим новую Подписку на событие в расширении или основной конфигурации:
ДокументОбъект.РеализацияТоваровУслуг.ПриЗаписи.Внутри обработчика пропишем следующий код, который будет принудительно очищать список получателей для обмена:
Процедура ИсключитьРТУИзОбменаПриЗаписи(Источник, Отказ) Экспорт
// Если это загрузка из другой базы, ничего не делаем, чтобы не нарушать логику БСП
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Очищаем список узлов-получателей для данного документа
Источник.ОбменДанными.Получатели.АвтоЗаполнение = Ложь;
Источник.ОбменДанными.Получатели.Очистить();
КонецПроцедуры
Использование свойства ОбменДанными.Получатели.АвтоЗаполнение = Ложь гарантирует, что платформа 1С не попытается автоматически добавить документ в план обмена на основании стандартных правил конфигурации. Это «железобетонный» способ предотвратить регистрацию объекта.
Рассмотрим ситуацию, когда документы уже зарегистрированы в плане обмена и их нужно оперативно удалить оттуда программно. Посмотрим на пример кода, который часто пытаются использовать начинающие разработчики, и выясним, почему он может быть неэффективным.
В некоторых случаях предлагают перебирать все изменения через ПланыОбмена.ВыбратьИзменения. Однако это создает колоссальную нагрузку на память. Правильнее выполнить очистку одной командой:
// УзелИнформационнойБазы - ссылка на конкретный узел БП в плане обмена
ПланыОбмена.УдалитьРегистрациюИзменений(УзелИнформационнойБазы, Метаданные.Документы.РеализацияТоваровУслуг);
Эта команда работает мгновенно на уровне базы данных, удаляя все записи о регистрации РеализацияТоваровУслуг для указанного узла. Рассмотрим, где это можно применить: например, в регламентном задании, которое запускается раз в час, или в обработке «Групповое изменение реквизитов». Для удобного ручного управления регистрацией объектов напрямую из интерфейса подойдёт расширение для регистрации и снятия объектов с плана обмена из формы.
Проанализируем ситуацию, описанную в сообщениях форума, когда попытка снять документ с регистрации в момент начала обмена (например, в форме монитора обмена) приводит к ошибке «Сообщение обмена было принято ранее».
Выясним причину: когда вы запускаете процесс синхронизации, система фиксирует номер отправленного сообщения. Если в этот же момент вы начинаете программно удалять записи из таблицы регистраций (DeleteRegistrationChanges), вы нарушаете целостность транзакции обмена. Платформа ожидает одну последовательность данных, а получает другую.
Рекомендация: Никогда не выполняйте УдалитьРегистрациюИзменений внутри процедур, которые вызываются непосредственно в процессе выполнения или настройки обмена (например, ПриСозданииНаСервере формы обмена). Манипуляции с регистрацией должны происходить либо до начала обмена, либо в момент записи самого документа.
Если ваша задача — оставить возможность видеть документ в плане обмена, но физически не передавать его в файл выгрузки, разберем метод ПриОтправкеДанныхПодчиненному (или аналогичный в модуле менеджера плана обмена).
В модуле менеджера плана обмена можно перехватить отправку:
Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
Если ТипЗнч(ЭлементДанных) = Тип("ДокументОбъект.РеализацияТоваровУслуг") Тогда
// Запрещаем отправку, но не снимаем с регистрации автоматически
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
КонецЕсли;
КонецПроцедуры
Этот способ более гибкий, так как он позволяет анализировать содержимое документа непосредственно перед тем, как он попадет в XML-пакет. Например, можно игнорировать только те РТУ, которые помечены на удаление или относятся к определенной организации.
Подводя итог, можно выделить следующую стратегию:
Отказ = Истина.Получатели.ПланыОбмена.УдалитьРегистрациюИзменений, но делайте это вне сеанса синхронизации.Помните о свойстве ОбменДанными.Загрузка. Всегда проверяйте его в своих обработчиках, чтобы не блокировать запись данных, которые приходят в вашу базу из других систем. Соблюдение этих правил сделает вашу синхронизацию между УТ и БП стабильной и предсказуемой.