Синхронизация данных между различными конфигурациями 1С (например, 1С:Бухгалтерия и 1С:Управление торговлей) — это стандартная задача, которая, тем не менее, вызывает множество вопросов у специалистов. Одним из самых частых является вопрос о том, как именно настроить расписание и нужно ли запускать процедуры выгрузки и загрузки в обеих базах или достаточно одной «активной» стороны. Разберем детально механизмы обмена, чтобы понять логику работы системы.
Первое, что нам необходимо проанализировать, — это способ связи между информационными базами. От этого напрямую зависит количество настроенных регламентных заданий и расписаний. В современной платформе 1С используются два основных подхода:
COM-соединение или через Web-сервисы.FTP-сервер или электронную почту.Рассмотрим подробнее ситуацию с прямым подключением. В этом случае достаточно настроить расписание синхронизации только в одной базе (базе-инициаторе). Когда срабатывает регламентное задание, база-инициатор выполняет следующие действия: подключается к удаленной базе, считывает там данные, помеченные к выгрузке, забирает их себе, а затем отправляет свои измененные данные в удаленную базу. Таким образом, за один сеанс работы в одной базе происходит и загрузка, и выгрузка для обеих сторон.
Проанализируем ситуацию с файловым обменом. Здесь архитектура иная. База «А» выгружает файл в папку и «забывает» о нем. База «Б» ничего не узнает об этом файле, пока в ней самой не сработает команда загрузки. Поэтому при использовании файлов, FTP или почты обязательно настраивать сценарии синхронизации (расписание) на обеих сторонах.
Выясним, какие технологии стоят за прямым подключением, так как это влияет на стабильность системы:
COM-соединение: Традиционный, но постепенно устаревающий метод. Основная сложность здесь заключается в настройке окружения. Важно, чтобы разрядность сервера 1С (32 или 64 бита) совпадала с разрядностью установленных COM-компонент. Кроме того, на стороне сервера должны быть правильно настроены права доступа DCOM.
Web-сервисы и HTTP-сервисы: Более современный и рекомендуемый вариант. В базе-приемнике публикуется специальный сервис, к которому обращается база-источник. Это позволяет базам находиться в разных сетях и не требует регистрации специфических библиотек в операционной системе. Весь обмен идет по стандартным протоколам Интернета.
Чтобы понять, почему документы «мигрируют» между базами, разберем работу Плана обмена. Система синхронизации не пересылает всю базу целиком каждый раз. В 1С существует объект метаданных — ПланыОбмена.
Когда вы изменяете документ или справочник, платформа делает запись в специальной таблице регистрации изменений для конкретного узла обмена. Посмотрим на примере, как это выглядит в логике системы:
// Пример логики регистрации изменений (упрощенно)
ПланыОбмена.ЗарегистрироватьИзменения(УзелИнформационнойБазы, ОбъектСсылка);
При запуске синхронизации (даже с одной стороны при прямом подключении), база-инициатор обращается к этой таблице в удаленной базе. Она считывает все зарегистрированные ссылки и получает данные объектов. Если регистрация изменений для объекта отсутствует, он не попадет в обмен, даже если он был создан недавно. Это критически важно понимать при ручном исправлении ошибок синхронизации.
Современный универсальный обмен чаще всего базируется на формате EnterpriseData (технология XDTO). Это XML-основанный стандарт, который позволяет конфигурациям обмениваться данными без жесткой привязки к внутренней структуре метаданных друг друга.
Рассмотрим преимущество этого подхода: даже если вы обновили 1С:Управление торговлей до новой версии, а 1С:Бухгалтерия осталась на старой, обмен продолжит работать, если обе версии поддерживают одну и ту же версию формата EnterpriseData. В отличие от старых правил Конвертации данных 2.0, здесь не нужно каждый раз обновлять файл правил при малейшем изменении структуры документов.
Одной из самых больших проблем является появление дублей контрагентов, номенклатуры или складов. Проанализируем, как система понимает, что «Контрагент А» в одной базе — это тот же «Контрагент А» в другой.
Сначала система ищет объект по GUID (Уникальный идентификатор). Если идентификаторы совпадают, объект считается найденным. Если GUID разные (например, данные заводились вручную в обеих базах до настройки обмена), система переходит к полям поиска. Обычно это:
ИНН + КПП.ФИО + Дата рождения.Артикул или Наименование.Важно провести сопоставление данных при первом запуске синхронизации в ручном режиме, чтобы избежать дублирования информации.
Перейдем к практической настройке. В типовых решениях (БП 3.0, УТ 11) расписание задается в разделе «Администрирование» — «Синхронизация данных» — «Настройки синхронизации». Здесь мы создаем Сценарий синхронизации.
Рекомендуем придерживаться следующих правил при настройке расписания:
В процессе совместной работы часто возникают ситуации, когда один и тот же документ редактируется в обеих базах. Это приводит к конфликту. В настройках синхронизации можно указать приоритет (какая база считается главной), но лучше всего периодически открывать окно «Конфликты» и вручную проверять, чьи изменения должны остаться.
Для защиты данных в бухгалтерии крайне важно использовать Дату запрета загрузки. Она настраивается отдельно от общей даты запрета редактирования и гарантирует, что данные из торговой базы не «прилетят» и не изменят закрытый отчетный период, даже если бухгалтер по какой-то причине открыл этот период для ручных правок.
Несмотря на удобство настройки в одну сторону, многие эксперты рекомендуют использовать обмен через файлы или FTP. Рассмотрим причины:
Отказоустойчивость: Если при прямом подключении произойдет кратковременный обрыв связи, процесс обмена может «зависнуть» или прерваться с ошибкой, требующей вмешательства. Файловый обмен более терпим к нестабильной сети: файл просто дождется своего часа в папке.
Безопасность: Прямое подключение требует открытия портов и возможности входа одной системы в другую. Файловый обмен через защищенный FTP позволяет изолировать базы друг от друга, обмениваясь только пакетами данных.
Производительность: Выгрузка в файл происходит быстрее, чем обработка объектов через COM-соединение в режиме реального времени, так как базы работают независимо и не тратят ресурсы на поддержание активного удаленного сеанса.
Таким образом, мы выяснили: если ваше подключение — прямое, достаточно одной стороны для инициации процесса. Если же вы работаете через промежуточный ресурс — настраивайте обе стороны обязательно. Удачной настройки!