В современной экосистеме 1С синхронизация данных через формат Enterprise Data (XDTO) стала стандартом де-факто. Однако часто возникают задачи, когда нам не требуется полный зеркальный обмен между базами — например, нужно передавать только документы ЗаказКлиента и только при соблюдении определенных условий (по конкретному подразделению, сумме или статусу). В этой статье мы разберем, как реализовать такую задачу в 1С:Комплексная автоматизация или 1С:ERP, используя как стандартные настройки интерфейса, так и возможности Конвертации данных 3.1.
Начиная с версий 2.5.16 и выше в конфигурациях на базе ERP-платформы, разработчики существенно расширили штатный функционал. Рассмотрим, как воспользоваться этими возможностями. Проанализируем настройки синхронизации в разделе «Администрирование» — «Синхронизация данных».
Ранее мы могли настраивать фильтры только по организации, складу или периоду. Теперь же мы можем зайти в пункт «Состав отправляемых данных» непосредственно в узле обмена. Выберем тип объекта ЗаказКлиента. В расширенном режиме настройки мы можем задать произвольное условие, используя механизм компоновки данных. Это позволяет нам установить отборы не только «по разделу учета», но и по любым реквизитам шапки документа, например:
Этот способ является самым простым и предпочтительным, так как не требует изменения кода или использования внешних инструментов программирования.
Если штатных фильтров недостаточно (например, нужно проверить условие в табличной части или обратиться к данным связанных объектов), нам на помощь приходят Правила регистрации объектов (ПРО). Разберем по шагам, как это работает.
Правила регистрации определяют, попадет ли объект в план обмена в момент его записи. Если документ не соответствует условиям ПРО, он просто не будет зарегистрирован к отправке, что экономит трафик и ресурсы системы. Для реализации сложной логики нам потребуется программа «1С:Конвертация данных 3.1».
Алгоритм действий следующий:
ПравилаРегистрацииОбъектов).Конвертацию данных 3.1.Документ.ЗаказКлиента.ПередРегистрациейОбъекта напишем код на языке 1С, который будет проверять наши условия.Рассмотрим пример кода в обработчике, который разрешает регистрацию только для заказов с определенным префиксом или заполненным менеджером:
// Пример условия в правилах регистрации
Если Объект.Менеджер.Пустая() Тогда
Отказ = Истина;
ИначеЕсли Найти(Объект.Номер, "МСК") = 0 Тогда
Отказ = Истина;
КонецЕсли;
После внесения изменений правила необходимо сохранить, выгрузить в файл и загрузить обратно в рабочую базу через форму настройки синхронизации или напрямую в регистр. После этого система начнет фильтровать заказы «на лету» при их записи или проведении.
Бывают ситуации, когда нам нужно разово выгрузить определенный массив данных, не меняя логику постоянного обмена. Проанализируем ситуацию, когда нам нужно отправить заказы за прошлый месяц только по одному складу. В этом случае мы воспользуемся типовой обработкой «Регистрация изменений для обмена данными».
Эту обработку можно найти через меню «Функции для технического специалиста». Выполним следующие действия:
Заказ клиента.Теперь при следующем сеансе синхронизации система отправит только те объекты, которые мы выбрали вручную, игнорируя общие правила, если они настроены иначе.
Разберем, почему важно правильно настраивать фильтрацию именно на стороне источника. В технологии Enterprise Data процесс обмена разделен на два этапа: выгрузка в промежуточное XDTO-сообщение и загрузка из него. Если мы не настроим фильтрацию на стороне источника, база-приемник все равно получит файл с данными. Мы могли бы прописать фильтры на стороне приемника в модуле менеджера обмена в обработчике ПриПриемеДанных, но это неэффективно: база-источник будет тратить время на формирование XML, а база-приемник — на его чтение, чтобы в итоге просто «выкинуть» объект.
Поэтому всегда стремимся отсекать лишние данные на этапе регистрации изменений.
Также обратим внимание на версию формата Enterprise Data. При обмене между одинаковыми конфигурациями (например, КА 2.5 — КА 2.5) всегда выбирайте максимально возможную версию формата (например, 1.15 или 1.16). Это гарантирует, что практически все реквизиты документа ЗаказКлиента будут переданы без потерь, так как состав полей в последних версиях формата максимально приближен к типовым объектам ERP/КА.
Если ваша задача — это не полноценная синхронизация, а периодическая «переброска» только одного типа документов, выясним, не будет ли проще использовать облегченные механизмы. Синхронизация данных — это мощный, но довольно тяжелый инструмент.
Вариант с OData: База-приемник может обращаться к базе-источнику по протоколу HTTP и запрашивать заказы по фильтру. Это удобно, если инициатором обмена выступает принимающая сторона.
Вариант с HTTP-сервисами: Мы можем написать небольшую процедуру в модуле объекта ЗаказКлиента на стороне источника:
Процедура ПослеЗаписи(ПараметрыЗаписи)
Если ЭтоНовый() Или Проведен Тогда
// Формируем JSON и отправляем через HTTPСоединение в базу-приемник
ОтправитьДанныеВБазуПриемник(ЭтотОбъект);
КонецЕсли;
КонецПроцедуры
Такой подход работает мгновенно (real-time) и не требует настройки планов обмена, правил регистрации и форматов XDTO, что может быть значительно быстрее в реализации для одного конкретного объекта.
Подводя итог, выбор метода зависит от ваших компетенций и требований к архитектуре. Для простых условий используйте штатные отборы в узле обмена. Для сложной логики — Конвертацию данных 3.1. А для разовых задач — регистрацию изменений вручную.