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

Связать две базы 1С можно пятью разными способами, и выбор зависит от того, что нужно: гонять документы между типовыми конфигурациями, отдавать данные во внешнюю систему по запросу или разово вытащить справочник. Для типовых баз на платформе 8.3 почти всегда подходит штатная синхронизация в разделе Администрирование → Синхронизация данных. Для связи с сайтом или чужой программой — HTTP- и Web-сервисы. Для разовой выгрузки в Excel или внешнюю БД — ODBC и внешние источники данных.

Ниже разберём каждый метод: когда он уместен, что настроить и где обычно всё ломается. Общее правило простое — чем теснее две системы должны быть связаны «вживую», тем дороже и сложнее интеграция, поэтому не стоит городить веб-сервис там, где хватит файлового обмена раз в час.

С чего начать: какой метод выбрать под задачу

Прежде чем лезть в настройки, определитесь с тремя вещами: какие базы связываем (две типовые 1С или 1С с внешней системой), в какую сторону идут данные и как быстро они должны появляться на другой стороне.

Штатная синхронизация через планы обмена

Это основной механизм для связи двух баз 1С между собой. В его основе — объект конфигурации «План обмена»: он регистрирует изменения объектов (документов, справочников) и формирует сообщения, которыми базы обмениваются. Данные передаются порциями в формате XML, каждая сторона знает, что она уже отправила и что приняла.

В типовых конфигурациях на Библиотеке стандартных подсистем всё это завёрнуто в понятный мастер. Настройка идёт так:

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

Дальше обмен можно поставить на расписание через регламентное задание, чтобы базы синхронизировались сами раз в N минут.

Если конфигурация нетиповая или дорабатывалась, типовые правила обмена могут не подойти — тогда правила конвертации объектов настраивают отдельно (раньше в «Конвертации данных 2.0», сейчас чаще в формате EnterpriseData). Это уже работа для специалиста.

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

HTTP-сервисы и Web-сервисы: связь с внешними системами

Когда данные нужны не другой 1С, а стороннему приложению — сайту, CRM, мобильному клиенту, — используют веб-сервисы. 1С выступает сервером: внешняя система обращается к ней по URL и получает ответ.

Есть два варианта:

• HTTP-сервис — лёгкий REST-подход. Внешняя система шлёт запрос на адрес вида https://сервер/база/hs/имя_сервиса/метод, 1С возвращает ответ, обычно в JSON. Проще в разработке и отладке, удобен для обмена с сайтами.
• Web-сервис (SOAP) — строгий обмен с описанием контракта через WSDL. Тяжеловеснее, но его «понимают» многие корпоративные системы из коробки.

Чтобы сервис заработал, его нужно опубликовать на веб-сервере (Apache или IIS). Публикация выполняется из Конфигуратора: меню Администрирование → Публикация на веб-сервере. В окне публикации отмечаете, какие HTTP- и Web-сервисы выставить наружу, и указываете каталог публикации.

После публикации проверьте доступность: откройте в браузере корневой адрес публикации — веб-сервер должен ответить, а не выдать ошибку 404. Для Web-сервиса можно запросить WSDL, дописав к адресу ?wsdl.

Про доступ. Веб-сервис нужно закрыть от посторонних: 1С проверяет логин и пароль пользователя базы, но этого мало. Публикуйте сервис только по HTTPS, заводите под обмен отдельного пользователя с минимальными правами (только те объекты, что реально нужны внешней системе) и по возможности ограничивайте доступ по списку адресов на стороне веб-сервера. Открытый наружу сервис под полноправным пользователем — прямая дыра в учётную систему.

Прямое чтение чужой базы через ODBC и внешние источники данных

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

Подключение настраивается через строку соединения ODBC или напрямую к серверу СУБД. В конфигурацию добавляется внешний источник, в нём — таблицы, которые нужно читать, с указанием полей и типов. После этого данные доступны в запросах и формах.

Классический ADO (объект ADODB.Connection через COM) тоже работает — им пользуются в коде обработок, когда нужно выполнить произвольный SQL-запрос к внешней базе. Но это уже ручное программирование без удобства языка запросов 1С.

Ключевое ограничение касается записи. Напрямую писать в таблицы базы 1С через SQL категорически нельзя: платформа хранит данные в собственной структуре с итогами, движениями по регистрам и служебными полями. Ручная вставка строки в таблицу СУБД в обход платформы ломает целостность базы, и восстановить её потом почти невозможно. Поэтому ODBC/ADO к базе 1С — только на чтение, а любая запись идёт через встроенные средства: обмен, сервисы или COM.

COM-соединение для локальной связи двух баз

COM-соединение — способ, когда одна база 1С программно управляет другой на том же компьютере или в локальной сети. Внешняя обработка или сторонняя программа создаёт объект соединения, открывает вторую базу под нужным пользователем и работает с её объектами так, будто код выполняется внутри неё.

Для платформы 8.3 используется COM-объект V83.COMConnector. Чтобы он заработал, компонент нужно зарегистрировать в системе — обычно это делает установщик платформы, но при ручной установке регистрируют библиотеку comcntr.dll командой через regsvr32.

Упрощённо схема такая:

1. В коде создаётся соединитель: Соединитель = Новый COMОбъект("V83.COMConnector").
2. Устанавливается соединение со второй базой с указанием пути, имени пользователя и пароля.
3. Через полученный объект вызываются методы и обращения к данным второй базы.
4. После работы соединение закрывается.

COM удобен для разовых или редких операций: ночная выгрузка, перенос справочника, сверка остатков. Минусы — соединение привязано к машине и разрядности платформы (32/64 бита должны совпадать), а при большом объёме данных работает медленно.

Автоматизация обмена через внешние обработки и задания

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

Типовой сценарий: внешняя обработка по ночам соединяется со второй базой (через COM или веб-сервис), забирает новые документы и загружает их. Запускается она регламентным заданием на сервере 1С.

Что здесь важно учесть:

• Регламентные задания выполняются только в клиент-серверном варианте на сервере 1С, либо в файловой базе — пока открыт сеанс с запущенным планировщиком. На «спящем» компьютере файловое задание не отработает.
• Логируйте каждый запуск. Обмен, который молча падает ночью, вы заметите только когда данные разойдутся. Пишите в журнал регистрации результат каждого сеанса.
• Обрабатывайте ошибки связи. Вторая база может быть недоступна, сервер — перезагружаться. Обработка должна не падать с ошибкой, а переносить попытку на следующий запуск.

Для типовых конфигураций почти всё это уже реализовано в подсистеме обмена БСП — расписание настраивается прямо в карточке синхронизации. Своя обработка нужна там, где штатная схема не покрывает задачу.

Типичные ошибки интеграции и как их устранить

Большинство проблем при связи баз 1С сводится к нескольким повторяющимся причинам. Вот самые частые и что с ними делать.

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

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