Как выгрузить в СБИС данные из дополнительного реквизита табличной части, добавленного через расширение 1С?

← На главную

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

Стандартная внешняя обработка от СБИС при попытке обратиться к такому реквизиту выдает ошибку, сообщая, что поле не найдено. Давайте разберемся, почему это происходит и какие существуют способы решения этой задачи.

Анализ проблемы: почему внешняя обработка не видит реквизит расширения

Основная причина проблемы кроется в механизме работы расширений и внешних обработок в 1С. Платформа 1С работает со слоями метаданных:

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

Внешние обработки, особенно написанные давно или без учета современных возможностей платформы, часто "видят" только первый слой — метаданные основной конфигурации. Они просто не знают о существовании реквизитов, добавленных через расширения. Поэтому, когда в настройках выгрузки вы указываете [ТаблДок].МойРеквизитИзРасширения, обработка не может найти это поле в описании объекта и сообщает об ошибке.

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

Решение 1: Настройка пользовательского XML-файла

Обработка СБИС позволяет гибко настраивать правила выгрузки через пользовательские XML-файлы. Это основной инструмент кастомизации. Разберем его возможности и ограничения.

Шаг 1. Создание файла настроек.

Никогда не редактируйте оригинальные файлы настроек с расширением .sbis3.xml (например, ВО82КА2-5-7-390_РеализацияТоваровУслуг.sbis3.xml). Все ваши изменения будут затерты при обновлении обработки. Вместо этого создайте в той же папке файл с таким же именем, но без .sbis3 в конце. В нашем примере это будет ВО82КА2-5-7-390_РеализацияТоваровУслуг.xml. Именно в этом файле и нужно описывать свои правила.

Шаг 2. Переопределение существующих полей.

Пользовательский XML-файл отлично подходит для того, чтобы заполнять стандартные поля электронного документа значениями из нестандартных реквизитов. Например, если нам нужно заполнить наименование товара из реквизита Содержание (если он заполнен), а если нет — то из полного наименования номенклатуры. XML будет выглядеть так:


<?xml version="1.0" encoding="UTF-8" ?> 
<ини>
    <мФайл Имя="ЭДОНакл">
        <мТаблДок Имя="Товары">
            <ТаблДок_Название>^=([ТаблДок].Содержание,[ТаблДок].Содержание,[Номенклатура].НаименованиеПолное)</ТаблДок_Название> 
        </мТаблДок>
    </мФайл>
</ини>

Здесь конструкция ^=() означает "взять первое непустое значение из списка".

Шаг 3. Попытка добавления нового поля и ее ограничения.

А вот с добавлением совершенно нового поля, которое не описано в оригинальном файле .sbis3.xml, возникают трудности. Предположим, наш реквизит из расширения называется СКК_PID. Попытки добавить его в выгрузку могут выглядеть так:


<!-- Попытка через стандартный синтаксис -->
<ТаблДок_СКК_PID>=[ТаблДок].СКК_PID</ТаблДок_СКК_PID>

<!-- Попытка через создание нового параметра -->
<мПараметр Имя="СКК_PID">
    <Параметр_Имя>'СКК_PID'</Параметр_Имя>
    <Параметр_Значение>[ТаблДок].СКК_PID</Параметр_Значение>
</мПараметр>

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

Совет по отладке: Чтобы проверить, видит ли обработка ваш реквизит из расширения в принципе, попробуйте присвоить его значение стандартному полю. Например, полю "Название":

<ТаблДок_Название>=[ТаблДок].СКК_PID</ТаблДок_Название>

Если в выгруженном документе в поле "Название" будет пусто, это окончательно подтверждает, что обработка не может получить доступ к реквизиту [ТаблДок].СКК_PID.

Решение 2: Разработка обработки внутри расширения (Workaround)

Это надежный обходной путь, который гарантирует доступ ко всем нужным данным. Суть его в том, чтобы временно сделать внешнюю обработку "внутренней" частью вашего расширения.

Разберем по шагам:

Откройте ваше расширение в конфигураторе.
Добавьте в него новый объект — обработку. Можете скопировать в нее код и формы из внешней обработки СБИС, если они открыты, или создать свою с нуля.
Находясь в контексте расширения, код обработки будет иметь полный доступ как к объектам основной конфигурации, так и ко всем реквизитам, добавленным самим расширением. Ошибки "поле не найдено" не будет.
Отладьте всю логику получения данных внутри этой обработки.
Когда все будет готово и протестировано, сохраните вашу обработку из расширения как внешний файл (.epf).
Этот сохраненный файл теперь можно использовать как обычную внешнюю обработку, и он будет корректно работать, так как вся логика доступа к данным уже отлажена в "родной" среде.

Решение 3: Использование копии базы для отладки XML (Workaround)

Этот метод подходит, если вы хотите заставить работать именно XML-настройку, но вам мешают ошибки на этапе сохранения. Идея в том, чтобы "обмануть" обработку на время отладки.

Порядок действий:

Сделайте копию вашей рабочей базы.
В этой копии снимите конфигурацию с поддержки.
Откройте конфигуратор и добавьте ваш реквизит (например, СКК_PID) непосредственно в объект конфигурации (документ РеализацияТоваровУслуг, табличная часть Товары).
Теперь для обработки СБИС этот реквизит стал "родным", и она его прекрасно видит.
В этой копии базы вы можете спокойно отлаживать свой пользовательский XML-файл. Сохраняйте его, запускайте обработку, проверяйте результат.
Когда вы добьетесь нужного результата и ваш XML-файл будет полностью готов, просто скопируйте его в рабочую базу. Так как имя реквизита в расширении и в измененной конфигурации совпадает, отлаженный XML-файл должен заработать и на основной базе.

Этот способ не решает проблему видимости, но позволяет обойти ошибки редактора и отладить синтаксис в комфортных условиях.

Решение 4: Использование внешних функций (Продвинутый способ)

Обработка СБИС поддерживает вызов функций из общих модулей 1С прямо из XML-файла. Это самый гибкий и мощный способ кастомизации.

Разберем по шагам:

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


// Содержимое общего модуля МодульИнтеграцииСоСБИС в расширении

&НаСервере
Функция ПолучитьЗначениеPID(КонтекстСтроки) Экспорт
    
    // В зависимости от версии обработки СБИС, в функцию может приходить
    // структура с полями или объект данных. Нужно проверять экспериментально.
    // Предположим, приходит структура, содержащая нужный нам реквизит.
    Попытка
        Возврат КонтекстСтроки.СКК_PID;
    Исключение
        // Если что-то пошло не так, возвращаем пустое значение
        Возврат "";
    КонецПопытки;
    
КонецФункции

Шаг 3. Вызов функции из XML-файла.

Теперь в вашем пользовательском XML-файле вы можете вызвать эту функцию для заполнения нужного поля. Обратите внимание, что вам нужно найти подходящее, уже существующее в формате СБИС поле, чтобы записать туда значение.


<?xml version="1.0" encoding="UTF-8" ?> 
<ини>
    <мФайл Имя="ЭДОНакл">
        <мТаблДок Имя="Товары">
            <!-- Заполняем, например, дополнительное инфо-поле товара -->
            <ТаблДок_ИнфПолФХЖ2>=МодульИнтеграцииСоСБИС.ПолучитьЗначениеPID(ТаблДок)</ТаблДок_ИнфПолФХЖ2> 
        </мТаблДок>
    </мФайл>
</ини>

В данном примере ТаблДок — это переменная, которую обработка СБИС передает в качестве контекста строки. Ее точное имя может отличаться, это нужно уточнять в документации СБИС или подбирать экспериментально.

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