При работе с типовыми конфигурациями 1С, особенно снятыми с поддержки или сильно кастомизированными, разработчики часто сталкиваются с необходимостью доработки правил обмена. Начиная с современных версий «1С:Управление торговлей 11» и «1С:Бухгалтерия предприятия 3.0», обмен данными строится на базе технологии EnterpriseData (КД 3.0) через универсальный формат.
Стандартный подход подразумевает использование специализированной конфигурации «Конвертация данных 3.0» (КД 3) для редактирования правил и последующей выгрузки кода модуля менеджера обмена. Однако развертывание КД 3, настройка синхронизации метаданных и генерация модулей ради добавления одного реквизита или нового значения перечисления часто кажутся избыточными. В этой статье мы подробно разберем, как вносить изменения в типовой обмен напрямую через конфигуратор 1С, минуя КД 3, и рассмотрим альтернативные элегантные подходы, которые уберегут вашу конфигурацию от снятия с поддержки.
Прежде чем перейти к практике, давайте проанализируем принципиальное различие между технологиями КД 2.0 и КД 3.0. В КД 2.0 правила обмена представляли собой сложный XML-файл, который интерпретировался универсальной обработкой во время выполнения обмена. Изменение таких правил вручную в текстовом редакторе было крайне трудоемким и чреватым ошибками процессом.
В КД 3.0 ситуация в корне изменилась. Конвертация данных 3.0 — это просто генератор кода BSL (встроенного языка 1С). Весь обмен выполняется на чистом коде внутри общего модуля МенеджерОбменаЧерезУниверсальныйФормат (или аналогичных модулей с суффиксом версии, например, МенеджерОбменаЧерезУниверсальныйФормат13). Это означает, что разработчик имеет полную свободу действий: мы можем модифицировать этот модуль в обычном конфигураторе точно так же, как и любой другой общий модуль программы.
---
Рассмотрим классический сценарий из практики: в старую конфигурацию «1С:Управление торговлей 11.3» было вручную добавлено новое значение перечисления (например, ставка НДС 20% в период перехода с 18%). Требуется передать это значение в «1С:Бухгалтерию 3». Давайте разберем этот процесс по шагам.
Шаг 1. Анализ используемых общих модулей
В конфигурации источника может присутствовать несколько модулей менеджера обмена. Например, МенеджерОбменаЧерезУниверсальныйФормат и МенеджерОбменаЧерезУниверсальныйФормат13. Число в конце названия указывает на версию формата EnterpriseData (в данном случае 1.3). Выясним, какой формат используется в настройках вашего узла обмена, и найдем соответствующий модуль. Для надежности изменения логики (например, добавление новых ставок НДС) рекомендуется продублировать в обоих модулях, если используются разные версии формата для разных корреспондентов.
Шаг 2. Добавление сопоставления значений в коде модуля
Нам необходимо найти обработчики, отвечающие за конвертацию конкретного перечисления. В коде общего модуля найдем процедуры инициализации правил конвертации свойств (ПКС) и правил конвертации объектов (ПКО). Поиском по ключевому слову (например, НДС18 или названию перечисления СтавкиНДС) найдем место, где происходит сопоставление значений конфигурации и формата XDTO.
Допишем сопоставление для нашего нового значения по аналогии со старыми значениями:
// Пример модификации сопоставления перечислений в модуле МенеджерОбмена
Процедура ПКО_Перечисления_СтавкиНДС_Отправка(ДанныеВыгрузки, ПолученныеДанные, КомпонентыОбмена) Экспорт
Если ДанныеВыгрузки = Перечисления.СтавкиНДС.НДС20 Тогда
ПолученныеДанные = "НДС20";
ИначеЕсли ДанныеВыгрузки = Перечисления.СтавкиНДС.НДС18 Тогда
ПолученныеДанные = "НДС18";
// ... остальной типовой код сопоставления
КонецЕсли;
КонецПроцедуры
Шаг 3. Модификация пакета XDTO
Если мы просто укажем новое строковое значение "НДС20" в коде, система выдаст ошибку валидации XML-документа, так как схема XDTO-пакета обмена не знает такого значения в типе данных VATRate (или аналогичном). Нам необходимо зайти в ветку метаданных Общие -> Пакеты XDTO, найти используемый пакет (например, EnterpriseData_1_3_2) и вручную добавить новое значение в список разрешенных значений (enumeration) для соответствующего типа.
Важное правило: пакеты XDTO в базе-источнике (УТ) и базе-приемнике (БП) должны быть абсолютно идентичными! Если вы изменили схему пакета в УТ, вам обязательно нужно внести точно такие же изменения в пакет XDTO в базе БП. В противном случае принимающая сторона отклонит файл обмена на этапе десериализации с ошибкой структуры XML.
Лайфхак для проверки идентичности пакетов: Выгрузите измененные пакеты XDTO из обеих конфигураций в файлы схем (.xsd) и сравните их через стандартный инструмент 1С: Главное меню -> Файл -> Сравнить файлы.... Это позволит мгновенно обнаружить любые расхождения в структуре типов.
---
Прямая модификация типовых пакетов XDTO имеет огромный минус: при обновлении конфигурации эти изменения будут затерты или вызовут конфликты при сравнении/объединении метаданных. К счастью, разработчики платформы и стандартов EnterpriseData заложили штатную возможность передачи произвольных данных без изменения схем XDTO. Для этого используется свойство AdditionalInfo (Дополнительная информация).
Почти каждый объект в формате EnterpriseData (документы, справочники) содержит текстовое поле AdditionalInfo. Мы можем упаковать туда любые наши данные на стороне источника и прочитать их на стороне приемника.
Давайте подробно рассмотрим, как это реализовать программно.
Реализация на стороне источника (выгрузка):
В общем модуле менеджера обмена на стороне источника находим событие отправки нужного объекта (например, документа Реализация товаров и услуг) и сериализуем наши данные в JSON-строку:
Процедура ПКО_Документ_РеализацияТоваровУслуг_Отправка_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена) Экспорт
// Создаем структуру для хранения нетиповых параметров
ДополнительныеПараметры = Новый Структура;
ДополнительныеПараметры.Вставить("СпециальнаяСтавкаНДС", "НДС20");
ДополнительныеПараметры.Вставить("УникальныйИдентификаторСделки", Строка(ДанныеИБ.Сделка.УникальныйИдентификатор()));
// Сериализуем структуру в строку JSON
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ДополнительныеПараметры);
СтрокаJSON = ЗаписьJSON.Закрыть();
// Записываем данные в стандартное свойство формата, не меняя XDTO схему!
ДанныеXDTO.ДополнительнаяИнформация = СтрокаJSON;
КонецПроцедуры
Реализация на стороне приемника (загрузка):
В базе-приемнике в обработчике получения данных считываем переданную строку, десериализуем её обратно в структуру и заполняем нужные реквизиты объекта информационной базы:
Процедура ПКО_Документ_РеализацияТоваровУслуг_Получение_ПриПолученииДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена) Экспорт
Если ЗначениеЗаполнено(ДанныеXDTO.ДополнительнаяИнформация) Тогда
Попытка
// Читаем JSON из поля ДополнительнаяИнформация
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(ДанныеXDTO.ДополнительнаяИнформация);
ДопПараметры = ПрочитатьJSON(ЧтениеJSON);
ЧтениеJSON.Закрыть();
// Заполняем реквизиты документа в приемнике
Если ДопПараметры.Свойство("СпециальнаяСтавкаНДС") Тогда
Если ДопПараметры.СпециальнаяСтавкаНДС = "НДС20" Тогда
ДанныеИБ.СтавкаНДС = Перечисления.СтавкиНДС.НДС20;
КонецЕсли;
КонецЕсли;
Исключение
// Пишем информацию об ошибке парсинга в журнал регистрации обмена
ЗаписьЖурналаРегистрации("ОбменДанными.ОшибкаЗагрузкиДопСвойств",
УровеньЖурналаРегистрации.Предупреждение,
ДанныеИБ.Метаданные(),,
ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
КонецПроцедуры
Главное преимущество этого метода: XDTO-пакеты в обеих базах остаются абсолютно нетронутыми и типовыми. Это гарантирует беспроблемное прохождение контроля и обновлений конфигурации.
---
Если вам требуется передавать не просто пару значений, а целые структуры новых табличных частей или тяжелых связанных объектов, механизм AdditionalInfo может стать неудобным для отладки. В таких случаях по стандартам разработки 1С рекомендуется использовать механизм расширения формата обмена XDTO.
Этот подход позволяет зарегистрировать собственный пакет схем параллельно с основным пакетом EnterpriseData. Выполняется это следующим образом:
http://www.yourcompany.ru/ED/extension).ОбменДаннымиПереопределяемый переопределяем процедуру регистрации расширений формата:
Процедура ПриПолученииДоступныхРасширенийФормата(РасширенияФормата) Экспорт
// Регистрируем наше расширение формата обмена, привязывая его к базовой версии 1.3
РасширенияФормата.Вставить("http://www.yourcompany.ru/ED/extension", "1.3");
КонецПроцедуры
После этого при формировании правил конвертации объектов (ПКО) вы сможете использовать типы данных из своего расширенного пакета XDTO. Это наиболее технологичный метод доработки обмена «по-взрослому», сохраняющий основную конфигурацию на полной поддержке.
---
Чтобы не снимать с поддержки основной модуль МенеджерОбменаЧерезУниверсальныйФормат, всю логику доработок правил обмена (ПОД, ПКО, ПКС) можно вынести в расширение конфигурации, перехватив процедуры инициализации правил.
Рассмотрим, как это сделать программно с помощью аннотации &После (&After):
&После("ЗаполнитьПравилаКонвертацииОбъектов")
Процедура Мой_ЗаполнитьПравилаКонвертацииОбъектов(ПравилаКонвертации)
// Находим существующее правило конвертации для интересующего нас объекта
ПКО = ПравилаКонвертации.Найти("Документ_РеализацияТоваровУслуг");
Если ПКО <> Неопределено Тогда
// Динамически переопределяем имя процедуры-обработчика события отправки данных
ПКО.Вставить("ПриОтправкеДанных", "Мой_ПКО_РеализацияТоваровУслуг_Отправка_ПриОтправкеДанных");
КонецЕсли;
КонецПроцедуры
Саму процедуру-обработчик Мой_ПКО_РеализацияТоваровУслуг_Отправка_ПриОтправкеДанных мы также размещаем в модуле расширения. Таким образом, исходный код типовой конфигурации остается нетронутым, что колоссально облегчит дальнейшую поддержку и обновление систем.
Подводя итог, можно с уверенностью сказать: доработка обмена EnterpriseData без использования визуального редактора «Конвертация данных 3.0» — это не просто рабочий, а зачастую более быстрый и контролируемый метод решения задач автоматизации.
Для простых задач (добавление реквизита, новой ставки НДС, статуса) идеальным выбором будет Способ 2 (использование AdditionalInfo) в связке со Способом 4 (вынос кода в расширение). Это позволит выполнить доработку за считанные минуты, не затрагивая типовые метаданные и обеспечив абсолютную стабильность обновлений баз 1С.