Можно ли настроить два обмена между одними и теми же базами 1С?

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

При настройке синхронизации данных между конфигурациями, например, 1С:Бухгалтерия 3.0 и 1С:Управление нашей фирмой (УНФ), специалисты часто сталкиваются с необходимостью разделить потоки данных. Распространенный сценарий: один обмен должен работать полностью автоматически по расписанию, а второй — запускаться вручную для «догрузки» специфических документов или исправления ошибок за прошлые периоды.

Однако при попытке создать вторую настройку синхронизации система выдает ошибку о том, что префикс базы не уникален, либо блокирует изменение кода узла. В этой статье мы разберем, почему архитектура 1С накладывает такие ограничения, и как решить задачу «автоматика + ручной ввод» корректными методами.

Почему нельзя создать два обмена стандартными средствами?

Разберем техническую причину этого ограничения. Современные конфигурации 1С построены на базе Библиотеки стандартных подсистем (БСП). Механизм синхронизации данных в БСП опирается на объект метаданных ПланыОбмена.

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

  1. Уникальность идентификации: Когда в систему поступает файл обмена (сообщение), программа считывает код отправителя. Если в базе будет два узла с одинаковым кодом, система не сможет определить, к какой именно настройке (с какими правилами и фильтрами) относится этот пакет данных.
  2. Регистрация изменений: Механизм 1С отслеживает измененные объекты (документы, справочники) через таблицы регистрации. Регистрация происходит «в разрезе» узлов. Если создать два узла для одной и той же базы-корреспондента, один и тот же документ будет регистрироваться дважды. Это приведет к огромным очередям выгрузки, конфликтам версий и избыточной нагрузке на сервер.
  3. Целостность данных: БСП хранит информацию о последнем принятом и отправленном номере сообщения для каждого узла. Дублирование узлов приведет к рассинхронизации номеров сообщений, и обмен просто перестанет работать.

Решение задачи через «Состав отправляемых данных»

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

Шаг 1. Настройка автоматического обмена.
В параметрах синхронизации данных (раздел «Настройки — Синхронизация данных») установите расписание. Например, каждые 15 минут. В этом режиме система будет автоматически находить все новые и измененные документы и отправлять их в другую базу.

Шаг 2. Использование монитора регистрации.
Если вам нужно срочно отправить конкретный документ, который по каким-то причинам не попал в автоматический обмен (например, он не менялся, а вам нужно его переотправить), не нужно создавать новый обмен. Выполните следующие действия:

Теперь при следующем сеансе связи (автоматическом или ручном) эти документы будут выгружены вместе с остальными данными.

Вариант «Синхронизация с дополнительными параметрами»

Проанализируем еще одну возможность. Если вы нажмете кнопку «Синхронизировать» в интерактивном режиме, вы можете выбрать пункт «Синхронизировать с дополнительными параметрами». Это позволяет на лету изменить настройки текущего сеанса:

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

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

Использование «Универсального обмена данными в формате XML»

Если ваша задача требует совершенно иных правил выгрузки для ручного режима, которые кардинально отличаются от основной синхронизации, мы рекомендуем использовать обработку V8Exch83.epf (Универсальный обмен данными в формате XML).

Посмотрим на преимущества этого подхода:

Технический обход ограничений (для продвинутых специалистов)

Если вы всё же решите настоять на создании второго узла (что крайне не рекомендуется), разберем, как программисты иногда обходят проверку уникальности. Для этого используется стандартная обработка «Групповое изменение реквизитов».

Процесс выглядит так:

  1. Создается новый обмен с фиктивным префиксом (например, если реальный префикс «УН», создается «У2»).
  2. После завершения настройки открывается обработка «Групповое изменение реквизитов».
  3. В поле «Изменяемые объекты» выбирается нужный ПланОбмена.
  4. Для нового узла значение реквизита Код принудительно меняется с «У2» на «УН».

Внимание! Мы крайне не рекомендуем этот метод. Проанализируем последствия: при попытке загрузки данных в 1С:Бухгалтерию система может выдать ошибку «Объект не найден», так как код отправителя в файле будет соответствовать двум разным узлам, и механизмы БСП (например, ОбменДаннымиСервер.ОпределитьУзелПоКоду) могут вернуть не тот узел, который вы ожидали.

Резюме

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

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

← На главную