Почему при загрузке документов из СБИС в 1С УТ не заполняется поле «Склад» и как это исправить?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

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

Решение 1: Использование расширения конфигурации (рекомендуемый метод)

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

Для реализации выполним следующие шаги:

  1. Создадим расширение конфигурации для документа ПриобретениеТоваровУслуг.
  2. В расширении определим обработчик события ПередЗаписью (на сервере).
  3. Напишем логику, которая проверяет, заполнен ли склад. Если склад пустой, присвоим ему предопределенное значение или конкретный склад из настроек.

Пример кода для расширения:


&ПередЗаписью
Процедура ПриЗаписиСклад(Отказ)
    Если ЗначениеЗаполнено(ЭтотОбъект.Склад) = Ложь Тогда
        // Подставляем нужный склад по ссылке или коду
        ЭтотОбъект.Склад = Справочники.Склады.НайтиПоКоду("000000001");
    КонецЕсли;
КонецПроцедуры

Этот метод хорош тем, что он «всеяден»: даже если склад не был проставлен при ручном создании или через другие обработки, система всегда гарантирует наличие нужного значения.

Решение 2: Модификация правил обмена в файле СБИС

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

Рассмотрим вариант с использованием поиска по коду склада:


<НайденыйСклад Отбор_Код="'06'">Справочник.Склады</НайденыйСклад>
<НужныйСклад Вычислить="[НайденыйСклад]">[Документ].Склад</НужныйСклад>

В этом случае при импорте система принудительно найдет склад с кодом '06' и присвоит его документу. Это решение требует аккуратности, так как при изменении кодов в справочнике правила потребуется актуализировать.

Решение 3: Создание внешней функции через ВнешниеФункции_Клиент.epf

Если вы не хотите менять основные правила, можно создать дополнительный файл ВнешниеФункции_Клиент.epf. Этот подход позволяет инкапсулировать логику выбора склада в отдельном модуле, сохраняя чистоту основных правил интеграции.

В модуле этой обработки вы создаете экспортную функцию:


Функция МояФункция() Экспорт
    // Здесь можно прописать любую сложную логику выбора склада
    // Например, исходя из организации или условий поставки
    Возврат Справочники.Склады.НайтиПоНаименованию("Основной склад");
КонецФункции

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

Важные советы при настройке

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

← На главную