← На главную

При регулярном обновлении конфигурации «1С:Бухгалтерия предприятия» многие разработчики сталкиваются с неожиданным поведением: после изменения налогового законодательства и появления новых ставок НДС типовой обмен через универсальный формат EnterpriseData с недоработанной или не обновляемой «1С:Управление торговлей» завершается с ошибками валидации XML. При анализе выясняется, что в используемом пакете XDTO новые ставки отсутствуют. Разберем причины такого поведения платформы и конфигураций, а также рассмотрим технические способы решения возникшей проблемы.

Причины поведения типовых конфигураций и неизменности пакетов XDTO

Проанализируем архитектуру универсального формата EnterpriseData и правила версионирования, принятые фирмой «1С»:

1. Политика версионирования и заморозка схем. Формат обмена EnterpriseData проектируется по строгому принципу обратной совместимости. Как только выходит новая версия XSD-схемы (пакета XDTO), ее состав полностью фиксируется. Фирма «1С» не вносит изменения в состав уже опубликованных и утвержденных пакетов старых версий, так как это нарушило бы совместимость со сторонними системами, строго соблюдающими стандарт конкретной версии. Все изменения в законодательстве (включая новые ставки НДС) добавляются разработчиками платформенных решений исключительно в новые версии формата. Старые версии пакетов переводятся в статус архивных и больше не поддерживаются вендором.
2. Ограничение валидации перечислений в платформе. В ранних версиях формата EnterpriseData ставка НДС была реализована в виде простого типа данных с фиксированным фасетом перечисления (enumeration). Механизм платформы ФабрикаXDTO при сериализации и десериализации осуществляет строгую проверку соответствия переданных строк значениям фасета. Если в потоке данных встречается значение, отсутствующее в схеме, платформа выбрасывает исключение валидации. В современных версиях формата EnterpriseData ставки НДС были перенесены из строго типизированного перечисления в структуру справочника, что сняло жесткое ограничение на валидацию.

Технические нюансы: почему простой правки схемы XDTO недостаточно

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

Дело в том, что механизм конвертации универсального формата в Библиотеке стандартных подсистем жестко завязан на программный код общего модуля МенеджерОбменаЧерезУниверсальныйФормат (или отдельных менеджеров конкретных версий формата). Для корректной обработки данных требуется сопоставление сразу на нескольких уровнях:

1. В правилах сопоставления значений перечислений и справочников, формируемых в процедуре ЗаполнитьПравилаКонвертацииПредопределенныхДанных.
2. В специализированных алгоритмах модуля менеджера обмена, таких как процедура ОпределитьСтавкуНДС_Отправка и соответствующих методах чтения данных при загрузке документов.

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

Способ 1. Перенос свежего пакета XDTO и модулей в конфигурацию-источник (рекомендуемый)

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

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

1. Из актуального релиза конфигурации «1С:Бухгалтерия» экспортируем современную версию пакета XDTO формата EnterpriseData (в которой ставки НДС уже перенесены в справочник).
2. Импортируем полученный пакет в конфигурацию «1С:Управление торговлей».
3. Переносим или обновляем код общего модуля менеджера универсального формата, отвечающего за эту версию, обеспечив формирование объектов по обновленной схеме.
4. В настройках узла плана обмена в обеих базах переключаем версию используемого формата на актуальную.

Этот вариант исключает проблемы с будущими типовыми обновлениями базы бухгалтерского учета.

Способ 2. Доработка логики обмена на стороне БП через расширение конфигурации

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

Посмотрим на алгоритм реализации перехвата данных:

1. Создаем расширение конфигурации с назначением «Адаптация» или «Дополнение».
2. Подключаем расширение к процедурам модуля МенеджерОбменаЧерезУниверсальныйФормат с использованием аннотаций &Вместо, &После или &ИзменениеИКонтроль.
3. Перехватываем обработку табличных частей загружаемых документов после валидации пакета XDTO, сопоставляя ставку НДС программно на основании суммовых показателей, реквизитов или даты документа.

Такой подход сохраняет основную конфигурацию на полной поддержке и гарантирует корректное проведение документов даже при использовании устаревших версий формата обмена.

Способ 3. Передача ставки через свойство AdditionalInfo

Проанализируем еще один универсальный механизм формата EnterpriseData. Все объекты, унаследованные от базового типа Object, содержат дополнительное составное свойство AdditionalInfo. Это свойство предназначено разработчиками именно для передачи произвольных структур данных без вмешательства в утвержденную XSD-схему.

Схема реализации следующая:

1. На стороне конфигурации-источника («1С:Управление торговлей») перед формированием сообщения сериализуем реальное значение ставки НДС в свойство AdditionalInfo строки документа или объекта, а в основное типизированное поле подставляем допустимое для старой схемы фиктивное значение, проходящее валидацию.
2. На стороне приемника («1С:Бухгалтерия») в обработчиках конвертации объекта (например, в событии ПриПолученииДанных или алгоритмах постобработки) считываем данные из AdditionalInfo и устанавливаем корректный элемент справочника ставок НДС в загруженный документ перед его записью.

Данный способ позволяет обойти строгое ограничение фасетов платформы без нарушения структуры типового пакета XDTO.