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