Прекращение поддержки формата XML фирмой 1С

Фирма «1С» в 2026 году объявила, что в ближайших релизах Библиотеки стандартных подсистем (БСП) планируется отключение обмена данными по правилам конвертации XML. Это затрагивает все современные типовые конфигурации 1С, подключающие соответствующие подсистемы. В частности, будет удалена обработка «КонвертацияОбъектовИнформационныхБаз» – ключевой компонент механизма обменов на XML-правилах.

Важно отметить, что не весь XML-обмен исчезнет. Фирма 1С сохраняет поддержку внешней обработки «УниверсальныйОбменДаннымиXML», предназначенной для разовых (единоразовых) операций передачи данных. То есть регулярные, запланированные обмены по XML будут недоступны, но «Универсальный обмен» останется как удобный инструмент для единичной загрузки/выгрузки (например, переноса остатков или настроек).

Таким образом, после изменений регулярный обмен по правилам XML в стандартной поставке исчезнет, а останется лишь универсальная внешняя обработка для разовых задач. Это означает, что все текущие механизмы синхронизации, настроенные на основе правил конвертации XML (так называемый КД2), в будущем перестанут работать – их придется заменять новыми подходами.

Почему 1С отказалась от XML-обмена

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

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

Наконец, в заявленных причинах фигурируют вопросы безопасности и стандартизации. Правила обмена XML могут содержать программный код, который при выгрузке/загрузке исполняется через методы Выполнить() или Вычислить(). Без строгого безопасного режима этот код выполняется на сервере и плохо поддается аудиту. 1С указывает, что подобный подход нарушает внутренние стандарты безопасности (нормы 770, 669), что тоже указывает на необходимость отказа от технологии.

Итог: XML-правила конвертации перегружены зависимостями от конфигураций и несут риски в поддержке, что подтолкнуло разработчиков к отказу от них в пользу более универсальных форматов обмена.

Остальное, что остается: разовые обмены и начальные перенесы

Важно не путать регулярные обмены с разовыми операциями. Стандартные разовые сценарии переноса данных (например, при переходе с одной конфигурации на другую) по-прежнему выполняются на XML-правилах. Во многих случаях используют ту же внешнюю обработку «УниверсальныйОбменДаннымиXML»: она остается и будет продолжать поставляться как инструмент для единичных задач.

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

Таким образом, XML в разовой миграции никуда уходит – он остается допустимым сценарием для первоначального переноса или редких операций.

Альтернатива 1: переход на формат EnterpriseData

Для регулярного обмена данными фирма 1С рекомендует переходить на формат EnterpriseData (ED). Этот формат, разработанный «1С», основан на XML, но устроен по-другому: объекты в ED соответствуют бизнес-сущностям (акты, приказы, контрагенты и т.д.). Благодаря этому не требуется знать внутреннее устройство ни отправителя, ни получателя – формат самодостаточен.

1. Что такое EnterpriseData: Официально ED – это универсальный формат обмена данными внутри продуктов 1С. Он покрывает все основные области деятельности (финансы, закупки, продажи, производство, склад и т.п.) и постоянно расширяется новой версией. В данных ED-XML нет «сырого» низкоуровневого форматирования, описываются сразу бизнес-объекты.
2. Преимущества ED: во-первых, независимость от конкретных конфигураций. Если меняется метаданные одной из баз, достаточно изменить версию схем ED – сами правила конвертации (функции обмена) остаются одними и теми же. Во-вторых, ED поддерживает обратную совместимость: 1С гарантирует, что новые версии формата будут работать с базами старых версий без доработок.
3. Поддержка типовых конфигураций: большинство современных типовых программ 1С (ERP, БП, ЗУП, Розница, УТ, КА и др.) уже поддерживают ED-формат. Это значит, что «из коробки» между типовыми конфигурациями налажен обмен через ED.

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

В итоге схема обмена становится примерно такой:

База-А (1С:УТ) → формат EnterpriseData → База-Б (1С:БП)

Где оба конца знают только об общем формате ED. Это значительно упрощает синхронизацию и снижает зависимость от обновлений конфигураций.

Альтернатива 2: собственный механизм через регламентные задания

Если формат ED по каким-то причинам не подходит (например, обмен очень специфичных данных между сильно кастомными конфигурациями), можно разработать собственную систему обмена. Идея такая:

1. Регламент в источнике. В базе-источнике настраивается регламентное задание, которое в нужное время формирует файл или пакет данных для передачи. Обычно делают так: в модуле вызывается обработка, которая собирает все новые и изменившиеся объекты (через запросы или алгоритмы) и выгружает их в заранее согласованный формат (XML, JSON, CSV и т.д.).
2. Передача данных. Полученный файл кладут в общее хранилище (папка, FTP, веб-сервис и т.п.). Либо сразу передают по сети. Главное – оба конца договорились о способе.
3. Регламент в приёмнике. В базе-получателе запускается регламентное задание (на стороне 1С:Администрирование → Регламент), которое проверяет наличие новых файлов/сообщений. При появлении данных запускается процедура обработки: она читает файл и «накатывает» изменения на целевую базу. Здесь вы сами решаете, как преобразовать поступившие записи – возможно, нужно преобразовывать коды, искать соответствия справочников и т.д.
4. Журнал обмена и ошибки. Любая процедура должна фиксировать результат: какие объекты удачно загружены, какие возникли ошибки. Это позволит отследить проблемные места и при необходимости повторить обмен.
5. Инкрементные передачи. Важный момент – передавать только изменения. Обычно при первом запуске выгружают всё, затем сохраняют метки или метаданные (хранить последнее время синхронизации, списки уже переданных справочников и т.д.). При следующем запуске регламент собирает только новые или изменённые записи.

Такой подход даёт полную свободу: вы сами контролируете весь алгоритм и формат обмена. Но и требует больше работы: нужно самим написать и тестировать обработку выгрузки/загрузки, следить за корректностью передачи и иметь надёжный канал обмена (файловый, веб-сервис, базу через OData и т.д.). Обычно этот путь выбирают, если другие варианты (ED, XML-правила) не могут покрыть бизнес-логику обмена.

Альтернатива 3: МС:Автообмен от MoscowSoft

Если у вас уже есть обмены на правилах конвертации XML (КД2), и переводить их на ED пока нецелесообразно, можно рассмотреть продукт МС:Автообмен от MoscowSoft. Это готовая конфигурация 1С, которая автоматизирует регулярный обмен по расписанию между базами 1С, используя привычные правила XML, но без ручного запуска.

1. Как это работает: МС:Автообмен позволяет в три клика настроить обмен между любыми двумя базами 1С (на платформе 8.3) без внесения изменений в сами базы. Вы указываете подключение к обеим базам, выбираете регламентный график, указываете правила обмена (импорт/экспорт). Затем МС:Автообмен по расписанию сам выполняет процедурку выгрузки и загрузки данных в обе базы, используя стандартный механизм «Универсальный обмен XML». В итоге результат будет таким же, как при ручном обмене через XML-обработку, но теперь всё автоматически.
2. Важное условие: МС:Автообмен требует наличия правил конвертации (КД2) между конкретными базами. То есть он не создает эти правила сам, он их лишь использует. Если у вас уже есть прописанные правила обмена, то МС:Автообмен запускает их по расписанию. Если правил нет или они неполные, их нужно либо разработать, либо приобрести готовый вариант у нас. MoscowSoft предлагает каталог стандартных переносов и шаблонных правил обмена, которые можно использовать (см. раздел «Каталог» на сайте).
3. Пример настроек:
   1. Установите и запустите конфигурацию МС:Автообмен.
   2. Создайте новый «Регламентный обмен» между вашей базой А и базой Б.
   3. Укажите правила конвертации КД 2 (макеты правил для переноса объектов) и способ транспорта (файлы/FTP/COM/SOAP и т.д.).
   4. Настройте расписание – например, «каждый час выгружать изменения» или «раз в сутки».
   5. Сохраните и запустите обмен – МС:Автообмен будет фиксировать, когда и что выгружено/загружено, и вести лог.

В итоге МС:Автообмен – это удобный инструмент для тех, кто хочет сохранить привычные правила XML без постоянного ручного труда. Он поддерживает любые сценарии обмена (в одну или обе стороны) и гибкие фильтры выгрузки. Однако повторим: без самих правил обмена он бесполезен. Их вы разрабатываете сами или берете из готовых решений (например, у нас есть большое число типовых правил под различные конфигурации).

Практические рекомендации: что делать владельцам обменов сейчас

Если в ваших 1С-базах настроены регулярные обмены на XML-правилах, не откладывайте изучение ситуации. Чтобы не оказаться «в пролете» после обновления, рекомендуется действовать заранее по следующему плану:

1. Инвентаризация обменов. Составьте список всех синхронизированных баз и обменов. Определите, какие из них выполняются по правилам XML (КД2), а какие – другими способами. В частности, отметьте, какие обмены проходят по универсальному шаблону, а какие односторонние и т.п.
2. Разовые vs Регулярные. Разделите обмены на разовые переносы (переходы на новую конфигурацию или периодические обновления) и регулярные обмены (повседневные синхронизации продаж, остатков, заказов и т.д.). Для разовых задач продолжайте использовать «Универсальный обмен XML» – он будет работать и дальше. Крупные одномоментные миграции актуальны, в этом случае изменений почти не потребуется.
3. Анализ EnterpriseData. Посмотрите, поддерживают ли нужные вам объекты формат ED. Если вы используете типовые конфигурации (БП, УТ, ЗУП, Розница, ERP, КА и т.д.), скорее всего большинство данных уже можно передавать в ED. Попробуйте настроить тестовый обмен в формате EnterpriseData между нужными конфигурациями (стандартный интерфейс синхронизации это позволяет). Если всё проходит корректно, переход на ED – оптимальный путь. Это соответствует рекомендации 1С использовать ED для регулярных обменов.
4. Сложные или кастомные обмены. Если ED не охватывает вашу бизнес-логику (например, у вас очень специфичные справочники или документы), нужно выбирать другой путь. Это может быть разработка собственного регламентного обмена (как описано выше) или использование МС:Автообмен. Оцените затраты: написать свою обработку vs. настроить МС:Автообмен + прописать правила.
5. Планирование миграции. Не дожидайтесь срочного обновления, начните миграцию своевременно. Перенос сложных обменов может занять месяцы. Помните, что указанные изменения поступят через новые версии Библиотек синхронизации и БСП. По неофициальным данным, удаление механизма произойдёт в релизах Библиотеки синхронизации данных (БСД 1.0.7, БСП 3.1.13) для «толстого» интерфейса и 1.1.2 (БСП 3.2.2) для «тонкого» интерфейса. Лучше до этого момента перевести обмены.
6. Тест и откат. Организуйте тестовый стенд, где поставьте новые версии платформы с обновлёнными БСП. Проверьте, как отработают обмены (ED и/или новые сценарии). Убедитесь, что данные передаются без искажений, журналы чистые, а логика сохранилась. Если что-то ломается, ищите обходные пути или корректируйте правила до релиза.

Регулярно информируйте бизнес о грядущих изменениях обмена – пусть отделы знают, что интеграции и отчетность могут измениться. И, конечно, пользуйтесь помощью специалистов, если обмен слишком сложен. MoscowSoft готова помочь с аудитом обменов, подбором готовых правил или настройкой МС:Автообмен.

Кратко о технических изменениях

1. Удаляется механизм обмена по правилам XML (КД2): компоненты «обмена данными по правилам конвертации XML» будут удалены из БСП/БСД.
2. В частности, исчезнет обработка «КонвертацияОбъектовИнформационныхБаз».
3. Метаданные и API обмена по правилам XML (регистры обмена, планы, модули менеджера обмена) пометят устаревшими и затем исключат из будущих версий «Синхронизации данных» и «Стандартных подсистем».
4. Сохраняется только внешняя «УниверсальныйОбменДаннымиXML» – она будет продолжать поставляться и использоваться для разовых выгрузок/загрузок.
5. Для регулярных обменов 1С рекомендует EnterpriseData. В Библиотеке синхронизации данных встроена возможность переводить существующие XML-обмены в формат ED. 1С планирует и дальше расширять и улучшать формат ED, добавляя новые бизнес-сущности.
6. Официально упоминались планируемые версии: изменение запланировано примерно в БСД 1.0.7 (соответствует БСП 3.1.13) и 1.1.2 (БСП 3.2.2), но точные сроки зависят от выхода прикладных релизов.

Заключение: какой путь выбрать и что делать

Подведем итоги. Если обмены между типовыми конфигурациями у вас возникают регулярно и охватывают стандартные объекты (справочники, документы, остатки и т.д.), самым логичным решением будет перейти на формат EnterpriseData. Он отвечают архитектурной задумке 1С: независимость, расширяемость и поддержка нескольких версий. Также он уже реализован «из коробки» во многих популярных конфигурациях. EnterpriseData лучше подходит для масштабных интеграций и развития системы.

Если же обмен крайне специфический, либо ED пока не закрывает необходимые сценарии, рассмотрите разработку своего обменного механизма на регламентных заданиях. Это даст максимум гибкости, но потребует времени на разработку.

В ситуациях, когда есть необходимость сохранить текущий обмен по XML, но сделать его автоматическим, удобно использовать МС:Автообмен от MoscowSoft. Этот продукт позволяет без глубоких доработок организовать регулярный обмен по расписанию, ориентируясь на существующие XML-правила. Напомним, что в любом случае для работы по КД2 нужны сами правила конвертации – их вы разрабатываете самостоятельно или можете приобрести у нас.

Рекомендуемый ход действий: начните с аудита и планирования миграции. Попробуйте прототип на ED, оцените, какие объекты не покрываются. Параллельно проверьте, что готовитесь к выходу новых версий платформы. Опыт показывает: подготовиться заранее гораздо легче, чем столкнуться с неработающим обменом после обновления.

Не пугайтесь изменений – многие уже переходят на новые механизмы. Если же возникли вопросы или нужна помощь, обратитесь к экспертам MoscowSoft. Мы поможем подобрать оптимальный способ перехода и реализуем необходимые решения (например, настроим МС:Автообмен или разработаем правила).

Будьте в курсе последних новостей и рекомендаций по технологиям 1С – подписывайтесь на рассылку и Telegram-канал MoscowSoft. Там мы публикуем инструкции по интеграции, обновления и советы по обмену данными. Если остались вопросы по теме, задайте их нашим специалистам – мы всегда рады помочь организовать надежный обмен в ваших информационных базах.