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