Можно ли настроить несколько синхронизаций между 1С:ЗУП 3.1 и 1С:БП 3.0 по отдельным организациям?

При ведении учета нескольких юридических лиц в одной информационной базе 1С часто возникает задача разграничения ответственности. Бухгалтеры, отвечающие за разные организации, хотят контролировать отправку данных самостоятельно. Естественным желанием в такой ситуации является настройка нескольких независимых каналов синхронизации (например, «ЗУП — БП по Организации А» и «ЗУП — БП по Организации Б»).

В этой статье мы подробно разберем, почему попытка настроить несколько типовых синхронизаций между одной базой 1С:ЗУП 3.1 и одной базой 1С:БП 3.0 наталкивается на жесткие платформенные ограничения, какие риски несут в себе попытки «обойти» эти правила, и как решить задачу разграничения обменов стандартными и безопасными методами.

Техническое ограничение платформы: почему нельзя создать дублирующие узлы?

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

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

Когда мы пытаемся создать вторую синхронизацию, платформа выполняет следующие проверки:

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

Риски использования «костылей» и обходных путей

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

• Задвоение нормативно-справочной информации (НСИ): Синхронизация сопоставляет объекты (контрагенты, физические лица, подразделения) по их уникальным идентификаторам (UUID). Если обмен идет по разным узлам с измененными префиксами, правила регистрации и сопоставления могут сбоить. Это неизбежно приведет к появлению дублей сотрудников и организаций в базе «1С:Бухгалтерия».
• Лавинообразный рост таблиц регистрации изменений: Механизм регистрации изменений фиксирует данные, подлежащие выгрузке, для каждого узла отдельно. При наличии «фиктивных» узлов подтверждения о получении пакетов (квитанции) от одного узла не будут снимать регистрацию объектов на другом. База начнет хранить избыточные объемы информации, файлы обмена будут бесконечно раздуваться, а производительность системы резко снизится.

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

Решение 1. Ограничение доступа на уровне записей (RLS) при одной синхронизации

Это наиболее правильный методологический подход. Вместо создания нескольких обменов мы настраиваем одну стандартную синхронизацию, но ограничиваем права пользователей, которые ее запускают.

Разберем этот процесс по шагам:

1. В настройках прав пользователей в обеих базах (ЗУП и БП) включаем механизм ограничения доступа на уровне записей (RLS) по виду доступа «Организации».
2. Бухгалтеру А назначаем группу доступа, в которой разрешена только Организация А. Бухгалтеру Б — только Организация Б.
3. Обоим бухгалтерам добавляем типовую роль Выполнение синхронизации данных.
4. При запуске обмена Бухгалтером А система авторизуется под его учетной записью. Платформа 1С на уровне RLS физически скроет от этого сеанса все документы и справочники по Организации Б. В результате будут зарегистрированы и выгружены только те данные, к которым у пользователя есть непосредственный доступ.

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

Минусы: Использование RLS может незначительно снизить общую производительность баз данных при больших объемах информации.

Решение 2. Интерактивная регистрация изменений (Состав отправляемых данных)

Если включать тяжелый механизм RLS не хочется, можно использовать встроенный штатный инструмент выборочной регистрации объектов. Для этого обучим бухгалтеров работать с окном состава отправляемых данных.

Рассмотрим порядок действий пользователя:

1. В окне «Синхронизация данных» вместо нажатия на общую кнопку «Синхронизировать» бухгалтер нажимает на кнопку «Показать зарегистрированные данные» (иконка с синей шестеренкой).
2. В открывшемся окне отображаются все объекты, подготовленные к отправке. Нам необходимо очистить автоматическую регистрацию и зарегистрировать объекты вручную.
3. Нажимаем кнопку «Зарегистрировать» — «Документы по отбору».
4. В появившемся окне настройки отбора выбираем нужный тип документа (например, Отражение зарплаты в бухучете) и устанавливаем фильтр: Организация Равно [Наша Организация].
5. Нажимаем «Зарегистрировать». В очередь отправки попадут только документы по выбранному юрлицу. После этого запускается стандартный процесс синхронизации.

Преимущества: Работает полностью в рамках штатного функционала, не требует доработки конфигурации или включения RLS.

Минусы: Требует от бухгалтеров внимательности при ручной работе с регистрацией изменений.

Решение 3. Использование внешней обработки для программной регистрации

Чтобы минимизировать человеческий фактор и избавить пользователей от необходимости вручную настраивать фильтры в составе отправляемых данных, программист может написать простую внешнюю обработку.

Рассмотрим логику работы такой обработки:

На форме обработки бухгалтер выбирает организацию и период. По нажатию кнопки «Зарегистрировать к обмену» обработка выполняет следующий код:

// Очищаем текущую авторегистрацию, чтобы не отправить лишнего
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена);

// Запрос для поиска документов конкретной организации
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ОтражениеЗарплаты.Ссылка КАК Ссылка
    |ИЗ
    |	Документ.ОтражениеЗарплатыВБухучете КАК ОтражениеЗарплаты
    |ГДЕ
    |	ОтражениеЗарплаты.Организация = &Организация
    |	И ОтражениеЗарплаты.ПериодРегистрации = &Период";

Запрос.УстановитьПараметр("Организация", ВыбраннаяОрганизация);
Запрос.УстановитьПараметр("Период", ВыбранныйПериод);

Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();

// Регистрируем найденные объекты на узле обмена
Пока Выборка.Следующий() Цикл
    ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, Выборка.Ссылка);
КонецЦикла;

// Запускаем синхронизацию программно
ОбменДаннымиКлиент.ВыполнитьОбменДаннымиИнтерактивно(УзелОбмена);

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

Решение 4. Автоматизация обмена и установка даты запрета изменения данных

Очень часто потребность бухгалтеров в ручном управлении обменом продиктована страхом, что коллеги изменят или перезапишут их документы за прошлые периоды. Наиболее современным решением этой проблемы является полный уход от ручного запуска синхронизации.

Проанализируем шаги по автоматизации этого процесса:

1. Настраивается автоматическая синхронизация по расписанию (например, каждые 15-30 минут) под системной учетной записью администратора.
2. В базах ЗУП и БП настраивается Дату запрета загрузки данных. Этот механизм настраивается индивидуально для каждого пользователя или для групп пользователей (в разрезе организаций).
3. Как только бухгалтер закрывает период по своей организации, он устанавливает дату запрета изменения. После этого никакие автоматические или ручные обмены не смогут изменить данные в закрытом периоде по этой организации, в то время как по другим юридическим лицам обмен продолжит беспрепятственно функционировать.

Такой подход полностью снимает необходимость в ручном контроле синхронизации и существенно ускоряет документооборот между подразделениями.