Как связать две базы 1С и держать их данные одинаковыми

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

Под «синхронизацией» в 1С понимают одно: изменения из одной информационной базы автоматически попадают в другую. Механизм один и тот же в Бухгалтерии 3.0, УТ 11, ЗУП 3.1, Рознице и КА — все они построены на Библиотеке стандартных подсистем. Методы различаются только каналом связи и форматом передачи, настройки и ошибки — у всех общие.

Когда обмен данными между базами действительно нужен

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

• 🏪 УТ 11 → Бухгалтерия 3.0. Торговля ведётся в УТ, а документы реализации, поступления и банк уходят в бухгалтерскую базу для отчётности.
• 👥 ЗУП 3.1 → Бухгалтерия 3.0. Из зарплатной базы передаются сводные начисления, НДФЛ и взносы для отражения в учёте. Справочник сотрудников и подразделений — в обе стороны.
• 🏬 Розница ↔ УТ. Магазины работают в своих базах, центральный офис получает продажи и отправляет цены и номенклатуру.
• 🌐 Распределённая база (РИБ). Одна конфигурация, несколько копий: главный узел в офисе и подчинённые в филиалах. Передаётся всё, включая изменения самой конфигурации.
• 📱 Мобильные клиенты и сайты. Обмен с мобильным приложением или интернет-магазином через веб-сервисы.

Принципиальная развилка — одинаковые конфигурации или разные. Если базы одной конфигурации (РИБ), данные передаются «как есть». Если разные (УТ и БП), между ними стоит конвертация: общий формат EnterpriseData, в который каждая программа переводит свои объекты.

Каналы связи: какой протокол синхронизации выбрать

Канал — это способ, которым пакет с изменениями доезжает до второй базы. В настройке синхронизации предлагаются несколько вариантов.

Прямое подключение

Самый удобный способ. Одна база подключается к другой напрямую:

• 🖧 в локальной сети — к файловой базе по пути к каталогу или к серверной базе по имени сервера и базы;
• 🌍 через интернет — к базе, опубликованной на веб-сервере (HTTP/HTTPS). Для этого вторую базу публикуют на IIS или Apache с включёнными веб-сервисами.

Плюс прямого подключения — обмен идёт в обе стороны за один сеанс, и программа сразу видит, дошли ли данные. Минус — обе базы должны быть доступны одновременно.

Файловые каналы: папка, FTP, почта

Если прямого доступа нет, пакеты обмена передаются файлами. Каждая база выгружает XML-сообщение (обычно в архиве) и забирает встречное.

Про COM и TCP/IP

COM-соединение (внешнее соединение через V83.COMConnector) — это технический способ прямого подключения к базе в локальной сети. Пользователь его отдельно не выбирает: программа использует его сама, когда вы указываете путь к соседней базе. Для 64-битного клиента и 32-битного компонента нужны совпадающие разрядности, иначе подключение не создаётся.

TCP/IP как отдельный «режим синхронизации» в типовых конфигурациях не настраивается. Клиент-серверная база и так работает по TCP: клиент обращается к агенту сервера (порт 1540), затем к менеджеру кластера (1541) и рабочим процессам. Если прямое подключение к серверной базе не проходит, проверяйте доступность этих портов и диапазона рабочих процессов из свойств рабочего сервера.

Настройка плана обмена и регистрации изменений

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

Пошагово для типовой пары баз

1. В обеих базах откройте Администрирование → Синхронизация данных и включите флажок «Синхронизация данных».
2. Задайте префикс каждой базы — два символа, разные у разных баз (например, БП и УТ). Префикс попадает в номера документов и не даёт кодам пересечься.
3. Перейдите по ссылке настроек синхронизации и создайте новую. В списке выберите программу, с которой нужен обмен.
4. Укажите канал связи и параметры подключения. Нажмите проверку подключения, если она доступна для выбранного канала.
5. Задайте правила отправки: с какой даты передавать документы, по каким организациям, нужны ли справочники полностью или только используемые в документах.
6. Запустите первую синхронизацию. Программа предложит сопоставить данные — связать одинаковые справочники в обеих базах.
7. Настройте расписание: сценарий синхронизации запускается регламентным заданием.

Сопоставление — самый ответственный шаг. Если номенклатура или контрагенты не связаны, во второй базе появятся дубли. Сопоставляют обычно по ИНН для контрагентов и по артикулу или наименованию для номенклатуры.

Как работает регистрация изменений

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

Если нужно повторно отправить конкретные объекты, их регистрируют вручную. Программно это делается так:

// Зарегистрировать элемент справочника для отправки в узел обмена
Узел = ПланыОбмена.ОбменУправлениеТорговлейБухгалтерия.НайтиПоКоду("УТ");
ПланыОбмена.ЗарегистрироватьИзменения(Узел, СсылкаНаНоменклатуру);

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

Алгоритм синхронизации: что происходит за один сеанс

Один цикл обмена состоит из одинаковых этапов, независимо от канала:

У каждого узла два счётчика: номер отправленного и номер принятого сообщения. Квитирование работает так: база А отправила сообщение № 15, база Б в своём ответе сообщает «я приняла № 15». Только после этого А снимает регистрацию с объектов из этого пакета. Если ответ не пришёл, объекты уйдут повторно в следующем сообщении — данные не теряются.

Отсюда практическое правило: не удаляйте и не перекладывайте файлы обмена вручную в папке или на FTP. Нарушенная последовательность номеров — частая причина «зависшего» обмена.

Конфликты при двустороннем обмене

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

Чтобы конфликтов было меньше, делят зоны ответственности: справочник номенклатуры ведут только в УТ, план счетов и учётную политику — только в БП. Дополнительно в БП ставят дату запрета загрузки: документы закрытого периода, пришедшие из обмена, не перезапишут уже сданную отчётность.

Ошибки синхронизации и как их устранить

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

Если ничего не помогло

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

Для РИБ есть крайняя мера — пересоздание подчинённого узла из главного (новая начальная выгрузка). Её делают в нерабочее время: пользователи подчинённой базы должны отправить все изменения до начала, иначе непереданные данные пропадут.

Как ускорить обмен при больших объёмах

Медленная синхронизация почти всегда объясняется тем, что передаётся больше, чем нужно. Что проверить в первую очередь:

• 📉 Дата начала отправки. Если документы выгружаются «с начала времён», первые сеансы идут часами. Поставьте начало текущего года или квартала.
• 🎯 Отбор по организациям и складам. Филиалу не нужны продажи других подразделений.
• 📚 Справочники только используемые. Режим «передавать только задействованные в документах» резко сокращает пакет.
• ⏱️ Частота расписания. Сеанс раз в 1–2 минуты при сотне пользователей создаёт лишние блокировки. Для бухгалтерии обычно хватает интервала 15–60 минут или ночного обмена.
• 🗜️ Сжатие сообщений. Для файловых каналов включайте архивацию: XML сжимается в разы.

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

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

Безопасность данных при синхронизации

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

1. Отдельный пользователь для обмена. Создайте пользователя с правами только на синхронизацию данных, без полных прав. Его логин и пароль указывайте в настройке подключения.
2. HTTPS вместо HTTP для подключения через интернет. Сертификат — от нормального центра сертификации, без отключения проверки.
3. Пароль архива для файловых каналов. Сообщение в папке или на FTP без пароля откроет любой, у кого есть доступ.
4. Права на папку и FTP — только у учётной записи, под которой выполняется обмен.
5. Резервная копия обеих баз перед первой синхронизацией и перед сменой правил отправки.

Для РИБ отдельно важно: подчинённый узел получает изменения конфигурации. Если в главную базу внесли доработку с ошибкой, она разойдётся по всем филиалам. Доработки сначала проверяют на копии.

Частые вопросы