Как настроить обмен номенклатурой между 1С:УНФ и 1С:Бухгалтерия при разных наименованиях и сопоставлении «многие к одному»

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

При интеграции систем 1С:Управление нашей фирмой (УНФ) и 1С:Бухгалтерия предприятия (БП) часто возникает классический конфликт интересов. Кладовщику и менеджеру в УНФ важна максимальная детализация (например, «Доска сосновая 20х100х6000», «Доска еловая сорт 1»), в то время как бухгалтеру в БП достаточно одной обобщенной позиции «Доска» для упрощения учета и отчетности. Если обе базы уже заполнены данными с разными названиями, стандартная синхронизация может создать дубли или испортить существующие справочники. Разберем по шагам, как настроить корректное сопоставление объектов и реализовать механизм «многие к одному».

Метод 1. Использование регистра «Соответствие объектов информационных баз»

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

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

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

Метод 2. Синхронизация по кодам или артикулам (Технологический код)

Если мы не хотим глубоко погружаться в программирование регистров, воспользуемся стандартной настройкой поиска. Выясним, как настроить правила поиска без изменения наименований. Для этого удобно использовать поле Артикул или Код.

Рассмотрим алгоритм действий:

В базе БП у позиции «Доска» устанавливаем определенный артикул, например WOOD-001.
В базе УНФ у всех детальных позиций (сосна, ель, лиственница) проставляем точно такой же артикул WOOD-001.
В настройках синхронизации данных (состав правил преобразования) устанавливаем приоритет поиска «По артикулу».

Проанализируем ситуацию: когда из УНФ придет документ с «Доской сосновой», система поиска в БП увидит артикул WOOD-001, найдет по нему «Доску» и подставит ее в документ. При этом названия в обеих базах останутся нетронутыми.

Метод 3. Создание дополнительных реквизитов для сопоставления

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

В этом случае программист может внести изменения в правила выгрузки (модуль менеджера обмена):


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

Такой подход позволяет кладовщику в УНФ самому указывать, в какую «бухгалтерскую» позицию должна превратиться та или иная номенклатура при обмене.

Метод 4. Использование механизма «Номенклатура поставщиков»

Интересный способ — адаптировать типовой регистр НоменклатураПоставщиков. Несмотря на название, его логика идеально подходит для хранения соответствий. Мы можем рассматривать базу БП как «виртуального поставщика». В регистре прописывается связь: «Наша номенклатура (УНФ)» — «Номенклатура контрагента (БП)». При обмене через расширение или изменение правил Enterprise Data, система будет брать данные для пакета обмена не из основной карточки, а из этого регистра соответствий.

Риски и особенности «схлопывания» данных

Выясним, какие опасности таит в себе сопоставление «многие к одному» (когда несколько позиций УНФ превращаются в одну в БП). Основная проблема заключается в расчете себестоимости. Посмотрим на пример:

В УНФ у вас есть:

Доска сосна (закупка 100 руб.)
Доска дуб (закупка 500 руб.)

Если в БП они обе станут просто «Доской», то при расчете себестоимости по «средней» бухгалтер получит 300 руб. Это может быть неприемлемо для налогового учета или анализа прибыли. Поэтому, прежде чем реализовывать «схлопывание», обязательно проанализируйте следующие моменты:

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