Часто при настройке обмена между 1С:ERP Управление предприятием и 1С:Бухгалтерия предприятия 3.0 (БП) специалисты сталкиваются с ситуацией: справочник НоменклатураПоставщика успешно регистрируется к обмену в плане обмена, но физически данные в файл выгрузки не попадают или не загружаются в базу-приемник. Рассмотрим детально, почему это происходит и какими способами можно решить данную задачу.
Разберем внутренний механизм работы обмена через универсальный формат (Enterprise Data). Тот факт, что объект включен в состав плана обмена (флаг регистрации срабатывает), еще не гарантирует его фактическую передачу. Синхронизация данных через универсальный формат работает на базе XDTO-пакетов и программного кода в модулях менеджера обмена.
Выясним основную причину: в типовых конфигурациях 1С:Бухгалтерия предприятия, начиная с версии формата 1.0 и выше, справочник НоменклатураПоставщика не описан как самостоятельный объект обмена в правилах обработки данных (ПОД). Разработчики фирмы «1С» придерживаются методологии, согласно которой в бухгалтерской программе учет должен вестись строго по внутренней номенклатуре организации. Названия товаров от поставщиков считаются избыточной информацией для регламентированного учета и налоговой отчетности.
Проанализируем ситуацию в ERP: здесь этот справочник является ключевым для службы закупок. Он позволяет сопоставлять входящие прайс-листы и накладные с внутренними позициями. Однако при выгрузке в БП через формат Enterprise Data, движок обмена обращается к модулю менеджера. Если для данного типа объекта не прописана процедура выгрузки в соответствующую версию формата EnterpriseData, объект будет проигнорирован, даже если он «висит» в очереди на выгрузку.
Прежде чем приступать к программированию, рассмотрим наиболее современный и методически верный путь. Если ваша цель — видеть наименования поставщика в документах ПриобретениеТоваровУслуг (в БП — ПоступлениеТоваровУслуг), использование электронного документооборота решает проблему автоматически.
Рассмотрим, как это работает:
НоменклатураПоставщиков непосредственно в базе БП.Этот способ позволяет избежать замусоривания основной синхронизации и дублирования логики сопоставления, которая уже реализована в модуле ЭДО.
Если использование ЭДО невозможно, и справочник жизненно необходим в БП, нам потребуется доработка правил обмена. Это сложный процесс, требующий создания расширений для обеих конфигураций. Разберем шаги по реализации этого механизма:
Шаг 1. Добавление объекта в XDTO-пакет. Нам необходимо создать расширение, в котором в пакет EnterpriseData (соответствующей версии, например 1.15) будет добавлен тип объекта НоменклатураПоставщика с необходимыми свойствами (Наименование, Артикул, Владелец, Ссылка на основную номенклатуру).
Шаг 2. Описание правил выгрузки в ERP. В модуле менеджера обмена ERP через расширение нужно переопределить процедуру ПриЗаполненииДанныхXDTO. Пример логики кода может выглядеть следующим образом:
Процедура ПередВыгрузкойОбъекта(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена) Экспорт
Если ТипЗнч(ДанныеИБ) = Тип("СправочникСсылка.НоменклатураПоставщика") Тогда
// Логика заполнения свойств XDTO из объекта справочника
ДанныеXDTO.Наименование = ДанныеИБ.Наименование;
ДанныеXDTO.Артикул = ДанныеИБ.Артикул;
// Передаем GUID основной номенклатуры для связи
ДанныеXDTO.Номенклатура = СопоставлениеСсылок.ПолучитьСсылкуXDTO(ДанныеИБ.Номенклатура);
КонецЕсли;
КонецПроцедуры
Шаг 3. Описание правил загрузки в БП. Аналогично в БП создается расширение, которое описывает, как данные из формата EnterpriseData должны записываться в справочник НоменклатураПоставщиков (в БП он может называться иначе или быть реализован через регистр).
Если полноценный справочник в БП не нужен, а бухгалтер хочет лишь видеть «как это называлось у поставщика» для контроля, можно воспользоваться механизмом дополнительных реквизитов. Рассмотрим этот вариант подробнее:
Поступление (акты, накладные, УПД) дополнительный реквизит (текстовое поле) «Наименование у поставщика».Приобретение товаров и услуг программно заполним этот реквизит данными из справочника НоменклатураПоставщика.Проанализируем преимущества этого подхода: мы не нарушаем типовую структуру данных БП, не создаем лишних ссылочных связей, которые могут привести к ошибкам «Объект не найден», и при этом выполняем требование бухгалтерии.
Важно понимать юридическую сторону вопроса. Согласно письмам Минфина РФ, организация имеет право приходовать товар под собственными наименованиями, отличными от тех, что указаны в документах поставщика. Главное условие — наличие документа (акта, приказа или таблицы соответствия), который подтверждает, что Товар А от поставщика — это Товар Б в вашем учете.
В системе ERP таким «приказом о соответствии» фактически является справочник НоменклатураПоставщика. В БП достаточно хранить информацию о соответствии в регистрах, не перенося справочник целиком. Это позволяет поддерживать чистоту базы и высокую скорость работы обмена.
Подводя итог, отметим: отсутствие справочника НоменклатураПоставщика в стандартном обмене — это не ошибка, а осознанное ограничение типового функционала. Для решения проблемы мы рекомендуем:
Помните, что любая кастомизация типового обмена EnterpriseData требует глубоких знаний структуры XDTO и механизмов работы Библиотеки Стандартных Подсистем (БСП). Перед внесением изменений всегда проверяйте работу обмена на копиях баз.