Как настроить обмен из 1С:УТ в 1С:Бухгалтерию, чтобы характеристики превращались в отдельные карточки номенклатуры?

← На главную

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

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

Рассмотрим стандартную ситуацию: в УТ мы имеем одну карточку номенклатуры «Носок» и две характеристики: «Красный» (артикул 89-12) и «Зеленый» (артикул 89-13). Наша цель — получить в БП две разные карточки: «Носок красный 89-12» и «Носок зеленый 89-13». Проанализируем, почему это сложно сделать «в один клик»:

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

Реализация через формат Enterprise Data (ED)

Современный обмен между УТ 11 и БП 3.0 работает через универсальный формат Enterprise Data. Основная логика выгрузки сосредоточена в модуле менеджера обмена внутри УТ. Разберем по шагам, как модифицировать этот процесс.

Для начала нам необходимо перехватить данные в момент формирования сообщения. Рассмотрим алгоритм подмены ссылки. Нам нужно создать «виртуальный» идентификатор, который будет уникален для комбинации «Номенклатура + Характеристика».

Посмотрим на пример логики формирования такого ключа:


// Пример формирования уникального ключа в модуле менеджера обмена
Функция ПолучитьКлючСинхронизации(НоменклатураСсылка, ХарактеристикаСсылка)
    
    Если ЗначениеЗаполнено(ХарактеристикаСсылка) Тогда
        // Создаем новый GUID на основании хеша двух ссылок
        СтрокаКлюча = Строка(НоменклатураСсылка.УникальныйИдентификатор()) + "_" + Строка(ХарактеристикаСсылка.УникальныйИдентификатор());
        Возврат СтрокаКлюча;
    КонецЕсли;
    
    Возврат Строка(НоменклатураСсылка.УникальныйИдентификатор());
    
КонецФункции

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

Алгоритм трансформации наименования

Выясним причину, по которой простого изменения наименования в XML недостаточно. Бухгалтерия должна принять этот объект как новую номенклатуру. Поэтому в правилах конвертации (или в логике заполнения XDTO-объекта) мы прописываем следующее:

Извлекаем Наименование основной номенклатуры.
Извлекаем Наименование характеристики.
Извлекаем Артикул из реквизитов характеристики.
Склеиваем строку: ПолноеНаименование = Номенклатура + " " + Характеристика + " " + Артикул;

Важно помнить про единицы измерения. В БП единица измерения жестко привязана к карточке. Проанализируем ситуацию: если в УТ у характеристики может быть своя упаковка, при создании новой карточки в БП необходимо корректно заполнить базовую единицу измерения (обычно это шт с кодом 796), иначе документ в бухгалтерии не проведется по счетам учета.

Использование расширений для сохранения поддержки

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

ПКО_Справочник_Номенклатура_Отправка: здесь мы меняем логику формирования данных, отправляемых в БП.
Обработчики выгрузки табличных частей документов: здесь мы заменяем передачу пары Номенклатура + Характеристика на одну «виртуальную» номенклатуру.

Пример кода для модификации данных перед отправкой:


Процедура ПКО_Справочник_Номенклатура_Отправка_ПриОбработке(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
    
    // Если у товара есть характеристика, меняем представление
    Если СтруктураСвойств.Свойство("Характеристика") И ЗначениеЗаполнено(СтруктураСвойств.Характеристика) Тогда
        НовоеНаименование = СокрЛП(ДанныеИБ.Наименование) + " " + СокрЛП(СтруктураСвойств.Характеристика.Наименование);
        ДанныеXDTO.Наименование = НовоеНаименование;
        ДанныеXDTO.НаименованиеПолное = НовоеНаименование;
        
        // Артикул берем из характеристики, если он там заполнен
        Если ЗначениеЗаполнено(СтруктураСвойств.Характеристика.Артикул) Тогда
            ДанныеXDTO.Артикул = СтруктураСвойств.Характеристика.Артикул;
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Методические риски и налоговый учет

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

Объем справочника: Количество элементов в справочнике Номенклатура в БП вырастет кратно количеству характеристик. Если в УТ 1000 товаров и у каждого по 10 цветов, в БП будет 10 000 карточек.
Прослеживаемость и ГТД: Если товар импортный, разделение на карточки упрощает учет номеров ГТД, так как в БП они привязаны к номенклатуре и партиям.
Сложность возвратов: При оформлении возвратов в БП нужно будет внимательно следить, чтобы выбиралась именно та «цветовая» карточка, которая была при поступлении.

Альтернативный вариант: Текстовое содержание

Если задача бухгалтера — только видеть название цвета в печатных формах (УПД, счета-фактуры), то создавать тысячи карточек не обязательно. Рассмотрим вариант передачи характеристики в поле Содержание строки документа БП. В этом случае в справочнике остается один «Носок», но в проводках и печатных формах будет уточнение: «Носок (Красный)». Однако этот метод не позволяет видеть остатки по цветам на складе в БП, что часто является критическим требованием заказчика.

В заключение отметим, что задача по превращению характеристик в номенклатуру при обмене является классической задачей по кастомизации правил обмена. Несмотря на кажущуюся простоту («30 минут с кофе»), она требует тщательной отладки генерации идентификаторов и проверки всех типов документов (поступления, реализации, перемещения, возвраты), чтобы исключить пересортицу и дублирование данных в учетной системе.