Содержание:

Привет, коллеги!

Если вы хотя бы раз работали с планами обмена в 1С, то знаете, что это не просто настройка пары кнопок – здесь каждая мелочь имеет значение. В этой статье я поделюсь опытом, нюансами и даже парой нестандартных приёмов, которые реально помогли мне и многим знакомым настроить обмен данными между базами без головной боли.

1. Необходимость использования планов обмена

Представьте: у вас три филиала, интернет-магазин и склад на другом конце страны. Все они работают с 1С, но данные должны быть синхронизированы. Вручную это нереально – вот здесь и выручают планы обмена. Они реализуют 3 основных механизма:

●      Механизм распределенных информационных баз
   Позволяет создавать в рамках конкретного плана обмена распределенную информационную базу. Распределенная информационная база представляет собой иерархическую структуру, состоящую из отдельных информационных баз 1С:Предприятия — узлов распределенной информационной базы, между которыми организован обмен данными с целью синхронизации конфигурации и данных. 

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

●      Инфраструктура сообщений
   С точки зрения плана обмена, между узлами происходит обмен сообщениями. Каждое сообщение содержит изменения данных, изменения конфигурации (если это распределенная информационная база) и ряд служебной информации. Каждое сообщение точно ассоциировано с планом обмена, имеет уникальный номер и имеет одного отправителя и одного получателя. 

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

2. Функционал планов обмена в учетной системе 1С

Узлы — «адреса» баз, с которыми вы работаете. Каждый узел имеет уникальный GUID.
Совет из практики: Всегда делайте резервные копии узлов перед обновлением конфигурации. Один раз потерял GUID узла – час восстанавливал историю обмена!

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

P.S. В современных версиях платформы (начиная с 8.3.15) появился механизм История данных, который во многом использует таблицы регистрации изменений для построения полноценного аудита. Здесь, помимо стандартного механизма регистрации (как в планах обмена или регистрах сведений), реализована очередь обработки – изменения сначала записываются в одну таблицу, а затем, по регламенту или программно, производится обновление истории, при этом создаются версии объектов.

Обычно это XML-файлы. Есть два сценария:
•          Пакетная отправка: Разбиваем данные по 500 документов – так снижаем риск таймаута.
•          Прямая отправка через HTTP: Работает быстрее, но требует стабильного канала.
Лайфхак: Всегда добавляйте в XML-файл контрольную сумму (CRC32 или MD5) для проверки целостности.

3. Автоматическая и ручная регистрация изменений в 1С

Автоматическая регистрация
Можно например через подписки (например, «ПриЗаписи») регистрировать изменения для объектов, включённых в план обмена.

Пример кода, который я использую в модуле документа:

// В модуле документа
Процедура ПередЗаписью(Отказ, РежимЗаписи)
    // Автоматическая регистрация – запись добавится в регистр плана обмена "ОсновнойПлан"
    ПланыОбмена.ОсновнойПлан.ЗарегистрироватьИзменение(ЭтотОбъект);
КонецПроцедуры

Важно помнить: если документ проводит другие документы (например, проводки), их тоже надо регистрировать отдельно.
Совет: Если нужно запускать обмен только при определённых условиях (например, только после оплаты), используйте ручную регистрацию – вызывайте ЗарегистрироватьИзменение() после необходимых проверок.

4. Типовые проблемы и способы их решения

Конфликты версий: «Кто последний, тот и прав»

Ситуация: Два пользователя меняют один документ в разных базах. При синхронизации возникает конфликт.
Решение:
•          Добавьте в документ поле «Версия» (счетчик или дата изменения) и выбирайте объект с большей версией при конфликте.
Мой совет: Никогда не удаляйте конфликтующие объекты вручную – это может сломать всю цепочку обмена!

Дублирование данных: «Атака клонов!»

Проблема: После обмена в базе появляются дубли справочников (например, контрагенты «ООО Ромашка» и «ООО Ромашка (1)»).
Как бороться:
•          Используйте универсальные механизмы сопоставления из «Конвертации данных» (например, сравнение по ИНН для контрагентов).
•          Перед загрузкой проверяйте существование объекта через функции НайтиПоНаименованию() или НайтиПоРеквизиту().

Обмен «завис» на 99%

Что делать:
•          Разбейте выгрузку на пакеты по 100-200 записей.
•          Включите логирование в обработке обмена, чтобы определить, на каком объекте происходит сбой.
Лайфхак: Однажды обмен падал из-за документа с неверной датой (31 февраля). Логгирование спасло часы дебага!

5. Настройка XML-схемы выгрузки и конфигурация Конвертация данных

После того как мы создали план обмена и добавили узлы, возникает вопрос: «Как же теперь выгружать данные?». В большинстве случаев на помощь приходит специальная конфигурация Конвертация данных. Она позволяет:
•          Описать структуру исходной и принимающей баз;
•          Настроить правила соответствия между объектами, реквизитами, табличными частями и т.д.;
•          Преобразовывать данные «на лету» (добавлять какие-то дополнительные поля, фильтровать, объединять).

2.1 Версии «Конвертации данных» – 2.1 и 3.1

1.        Версия 2.1 – более старая, со своими нюансами, но многие привыкли к ней и продолжают использовать, если обмены настроены давно.
2.        Версия 3.1 – современный вариант, где есть улучшенный функционал, более удобный интерфейс и поддержка универсального формата (1С Enterprise Data). В версии 3.1 можно выполнять все те же операции, что и в 2.1, но, по отзывам специалистов, делать это проще и быстрее.

Универсальный формат 1С Enterprise Data — Это формат, позволяющий описать объект информационной базы (контрагента, накладную и т.п.) или сообщить о факте удаления этого объекта. Ожидается, что конфигурация, получившая файл в формате EnterpriseData, отреагирует соответствующим образом – создаст у себя новые объекты и удалит те, которые в файле помечены как удаленные.

Как обмениваться данными в формате EnterpriseData
Помимо информации об объектах, файл в формате EnterpriseData содержит заголовок (секцию <Header>) со служебной информацией. По этой информации конфигурация сможет понять, от какого внешнего приложения получена информация и какую информацию нужно отправить приложению в ответ (данные о тех объектах, которые были обновлены в информационной базе со времени последней синхронизации с данным сторонним приложением).

Таким образом, обмен данными в формате EnterpriseData с конфигурацией - это обмен файлами. В ответ на полученный от внешнего приложения файл конфигурация обработает его и создаст файл-ответ. Обмен файлами может происходить:
•          через выделенный файловый каталог,
•          через каталог FTP,
•          через веб-сервис, развернутый на стороне информационной базы. Файл с данными передается как параметр веб-методов.

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

1.        Выгружаем описание базы-источника и описание базы-приёмника. Это делается с помощью обработки, которая смотрит метаданные конфигурации и формирует XML-описание.
2.        Загружаем полученные описания в «Конвертацию данных».
3.        Настраиваем правила преобразования (соответствие объектов, полей, табличных частей). Здесь же можем указать, что какие-то реквизиты нам не нужны, а какие-то требуют специфичной трансформации.
4.        Формируем схему (правила обмена), которую можно далее добавить в макет плана обмена. В итоге при запуске обработки выгрузки/загрузки 1С будет пользоваться этими правилами.

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

Предположим, мы создали план обмена ПланОбменаПродажи, добавили в него узлы: «ОсновнаяБаза» и «Филиал». Дальше нам нужно настроить экспорт/импорт документов «ЗаказПокупателя».

1.        В «Конвертации данных» мы создали правила, которые сопоставляют документ «ЗаказПокупателя» в Базе1 с тем же документом «ЗаказПокупателя» в Базе2. Указали соответствия по реквизитам, табличной части и т.д.
2.        Далее мы экспортируем эти правила в XML-файл (так называемый макет правил), который потом можно подключить к плану обмена (или к специальной обработке, которая запускается регламентным заданием).
3.        Когда в основной базе документ «ЗаказПокупателя» меняется, он регистрируется в плане обмена, затем (при выполнении регламентного задания) обработка выгрузки ищет изменения и применяет правила из макета (фактически передавая данные в виде, понятном приёмной базе).

Пример кода, где мы задействуем подготовленные правила из макета:

Процедура ВыгрузитьДокументыПланОбмена()
    // 1. Загружаем правила конвертации из внешнего XML-файла
    // (Предполагается, что правила были заранее созданы в конфигураторе
    // через обработку "Конвертация данных 3.1" и экспортированы в XML)
    ПутьКПравилам = ОбщегоНазначения.ПолучитьПутьКВременнымФайлам() + "ПравилаОбменаЗаказами.xml";
    ПравилаОбмена = ПланыОбмена.ПланОбменаПродажи.ПолучитьМенеджерПравил().ЗагрузитьПравилаИзФайла(ПутьКПравилам);

    // 2. Инициализируем выгрузку для узла "Филиал"
    ПараметрыВыгрузки = Новый Структура;
    ПараметрыВыгрузки.Вставить("Узел", ПланыОбмена.ПланОбменаПродажи.НайтиУзелПоИмени("Филиал"));
    ПараметрыВыгрузки.Вставить("Правила", ПравилаОбмена);

    // 3. Создаем сессию выгрузки
    СессияВыгрузки = ПланыОбмена.ПланОбменаПродажи.СоздатьСессиюВыгрузки(ПараметрыВыгрузки);

    // 4. Выгружаем данные пакетами по 100 записей
    Пакет = СессияВыгрузки.ПолучитьПакет(100); // Размер пакета можно настроить
    Пока Пакет.Количество() > 0 Цикл
        // 5. Формируем файл выгрузки
        ФайлВыгрузки = Новый Файл(ОбщегоНазначения.ПолучитьПутьКВременнымФайлам() + "Выгрузка_" + ТекущаяДата() + ".xml");
        ЗаписьXML = Новый ЗаписьXML;
        ЗаписьXML.ОткрытьФайл(ФайлВыгрузки.ПолноеИмя);

        // 6. Сериализуем пакет в XML с применением правил
        СессияВыгрузки.ВыгрузитьПакет(Пакет, ЗаписьXML);
        ЗаписьXML.Закрыть();

        // 7. Отправляем файл получателю (пример через HTTP)
        HTTP = Новый HTTPСоединение("filial.company.ru");
        HTTP.ОтправитьФайл("/exchange", ФайлВыгрузки.ПолноеИмя);

        // 8. Получаем следующий пакет
        Пакет = СессияВыгрузки.ПолучитьПакет(100);
    КонецЦикла;

    // 9. Фиксируем завершение выгрузки
    СессияВыгрузки.Завершить();

Исключение
    // Обработка ошибок с записью в лог
    Сообщить("Ошибка выгрузки: " + ОписаниеОшибки());
    ЗаписатьЖурналРегистрации("ОбменДанными", УровеньЖурналаРегистрации.Ошибка, ОписаниеОшибки());
КонецПроцедуры

Часто компании хотят, чтобы обмен работал «без рук»:
•          Подписка на события: когда в документе или справочнике что-то меняется, мы автоматически вызываем процедуру ЗарегистрироватьИзменение для плана обмена.
•          Регламентное задание: с заданным интервалом (к примеру, раз в 10 минут) запускается обработка, которая выгружает накопленные изменения и отправляет их в приёмную базу.
В итоге весь процесс становится полностью автоматическим, и никто не забывает «нажать на кнопку» и «синхронизировать» данные.

Если вы работаете с БСП (Библиотека стандартных подсистем), многие задачи по организации обмена уже решены. Ниже приведены примеры полезных процедур и функций, которые существенно упрощают настройку и поддержку синхронизации данных.

В БСП для регистрации изменений объектов в планах обмена используются следующие методы:​

●       ЗарегистрироватьИзменения()
Вызывается у менеджера плана обмена для регистрации изменений конкретного объекта.​

Пример:

  ПланОбмена.ЗарегистрироватьИзменения(СсылкаНаОбъект);

●      ОбменДаннымиСобытия.ЗарегистрироватьИзмененияДанных()
Универсальный метод для регистрации изменений, включая проверку прав доступа.​

Пример:

  ОбменДаннымиСобытия.ЗарегистрироватьИзмененияДанных(Получатель, Данные);

Функция ИспользуемыеТранспортыСообщенийОбмена в Библиотеке стандартных подсистем (БСП) 1С предназначена для определения доступных видов транспорта сообщений обмена для конкретного узла информационной базы. Она возвращает массив транспортов, которые могут быть использованы при обмене данными с этим узлом.​

Назначение функции

Функция ИспользуемыеТранспортыСообщенийОбмена используется для:​

●       Получения списка транспортов обмена (например, FTP, FILE, EMAIL), доступных для конкретного узла информационной базы.​

●       Определения, какие виды транспорта поддерживаются в зависимости от настроек узла и конфигурации системы.​

●       Исключения неподдерживаемых транспортов в определённых условиях (например, COM-соединение может быть исключено для базовых версий конфигураций или при работе на ОС Linux).​

Пример использования

1C

Результат = ИспользуемыеТранспортыСообщенийОбмена(УзелИнформационнойБазы);

В этом примере функция возвращает массив транспортов, доступных для указанного узла информационной базы.​

• НастройкиТранспортаУзла – получает параметры транспорта (например, путь к каталогу или FTP-серверу) для данного узла обмена.
Пример кода:

НастройкиТранспорта = НастройкиТранспортаУзла(УзелОбмена, ДействиеОбмена);

• ПриВыгрузке и ПриЗагрузке – переопределяемые процедуры для реализации нестандартной логики выгрузки/загрузки.
Пример для выгрузки:

Процедура ПриВыгрузке(СтандартнаяОбработка, Получатель, ИмяФайлаСообщения, ДанныеСообщения, ...)
    СтандартнаяОбработка = Ложь;
    // Кастомная логика выгрузки
    ОбщегоНазначения.МенеджерОбъектаПоСсылке(Получатель).ПриВыгрузке(...);
КонецПроцедуры

• СоздатьФайлВыгрузкиЗаглушкуДляОбменаНаБСП – создает файл-заглушку для подтверждения успешной выгрузки.
Пример кода:

Процедура СоздатьФайлВыгрузкиЗаглушкуДляОбменаНаБСП(ИмяФайлаСообщения)
    ЗаписьХМЛ = Новый ЗаписьXML;
    ЗаписьХМЛ.ЗаписатьНачалоЭлемента("Данные");
    ЗаписьХМЛ.ЗаписатьТекст("Заглушка");
    ЗаписьХМЛ.ЗаписатьКонецЭлемента();
КонецПроцедуры

В стандартной платформе 1С:Предприятие существуют следующие механизмы для работы с форматами JSON и XML:

Начиная с версии 8.3.6, платформа 1С предоставляет функции для сериализации и десериализации данных в формат JSON. Например:​

●       СериализоватьВJSON(Данные) — преобразует структуру или массив в строку JSON.​

●       ДесериализоватьИзJSON(СтрокаJSON) — преобразует строку JSON обратно в структуру или массив.​

Эти функции удобны для обмена данными между различными системами, особенно при использовании REST API или ESB.​

Для работы с XML в 1С используется механизм XDTO (XML Data Type Object). Он позволяет описывать структуры данных и автоматически выполнять их сериализацию и десериализацию в формат XML. Это особенно полезно при интеграции с внешними системами, требующими обмена данными в формате XML.​

План обмена — это «двигатель» регистрации изменений, а «Конвертация данных» даёт возможность тонко настроить трансформацию и фильтрацию этих данных. В связке с универсальным форматом (1С Enterprise Data) этот механизм становится ещё более гибким: вы можете передавать данные между самыми разными конфигурациями.

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

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

Надеюсь, мой личный опыт, реальные примеры и советы помогут вам добиться идеальной синхронизации и избежать множества проблем. Если будут вопросы или свои истории – делитесь в комментариях. Удачи, и пусть ваши базы синхронизируются как Швейцарские часы.

Специалист компании ООО "Кодерлайн"
Денис Гетман