При настройке синхронизации между конфигурациями «Управление торговлей 11» (УТ) и «Бухгалтерия предприятия 3.0 КОРП» (БП) часто возникает задача трансформации данных. Одна из типичных ситуаций — когда в торговой базе ведется детальный учет по множеству подразделений (структурных единиц предприятия), а в бухгалтерской базе все эти операции должны отражаться на одном единственном подразделении (например, «Основное подразделение» или «Торговый отдел»).
Сложность заключается в том, что современные типовые обмены используют универсальный формат (Enterprise Data). В отличие от старых обменов через «Конвертацию данных 2.0», здесь нельзя просто поправить одно ПКО (правило конвертации объекта) для справочника, так как ссылка на подразделение передается внутри каждого документа. Изменение правил для каждого типа документа — трудоемкий процесс, который к тому же затрудняет последующее обновление конфигураций.
В этой статье мы разберем несколько эффективных способов решения этой задачи, начиная от простых пользовательских настроек и заканчивая программными методами через расширения конфигурации.
Проанализируем самый простой и штатный путь, который предоставляет платформа 1С. При выполнении первой синхронизации (или при появлении новых объектов) система предлагает выполнить сопоставление данных. Рассмотрим, как использовать это для объединения подразделений.
Подразделения (или Структура предприятия в УТ).Важный нюанс: Система запомнит эти связи в специальном регистре. Однако, если в будущем в УТ будет создано новое подразделение, оно автоматически не сопоставится с вашим «мастер-подразделением» и прилетит в БП как новый объект (или потребует ручного сопоставления). Поэтому данный метод хорош при стабильной структуре компании.
Разберем техническую сторону того, как 1С понимает, что объект А в одной базе — это объект Б в другой. В обменах через универсальный формат ключевую роль играет регистр сведений ПубличныеИдентификаторыОбъектов. В нем хранится связь между внутренним GUID объекта в текущей базе и его «публичным» идентификатором (который обычно совпадает с GUID в базе-источнике).
Чтобы «обмануть» систему и заставить ее схлопывать данные, мы можем программно или вручную создать записи в этом регистре. Рассмотрим алгоритм действий:
ПубличныеИдентификаторыОбъектов, где для разных Идентификатор (строка) (пришедших из УТ) будет указана одна и та же Ссылка на подразделение в БП.Этот метод позволяет избежать дублей на уровне ядра системы обмена. Система при загрузке XML-файла увидит идентификатор подразделения, найдет по нему готовую ссылку в регистре и подставит ее в документ еще до начала записи самого объекта.
Если подразделений много и они часто меняются, ручное сопоставление становится обузой. В этом случае мы рекомендуем использовать расширение конфигурации в базе-приемнике (БП). Это самый гибкий и «чистый» с точки зрения обновлений способ. Нам нужно перехватить момент конвертации данных XDTO.
Проанализируем пример кода, который можно разместить в модуле менеджера обмена через расширение. Мы будем использовать обработчик, который вызывается при чтении данных из формата Enterprise Data.
&НаСервере
Процедура Последовательность_ПриКонвертацииДанныхXDTO(ДанныеXDTO, КомпонентыОбмена, СсылкаНаОбъект) Экспорт
// Проверяем, что обрабатываемый тип - это Подразделение
Если ДанныеXDTO.Тип() = ФабрикаXDTO.Тип("http://v8.1c.ru/edi/erp_2_0_subsytems", "Справочник.ПодразделенияОрганизаций") Тогда
// Указываем ссылку на наше мастер-подразделение
// Его можно найти по коду, наименованию или предопределенному значению
МастерПодразделение = Справочники.ПодразделенияОрганизаций.НайтиПоНаименованию("Основное подразделение");
Если Не МастерПодразделение.Пустая() Тогда
СсылкаНаОбъект = МастерПодразделение;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Преимущество этого метода в том, что он работает глобально. Каким бы документом ни пришло подразделение, на этапе обработки XDTO оно будет заменено на нужное нам. Это избавляет от необходимости править правила для каждого ПриобретениеТоваровУслуг, РеализацияТоваровУслуг и прочих документов.
Выясним еще один альтернативный вариант, который полезен, если вы не хотите глубоко погружаться в механизмы обмена (XDTO, менеджеры обмена). Можно создать общую подписку на событие ПередЗаписью для всех документов, участвующих в обмене.
Разберем логику работы этого метода:
ПередЗаписью.Подразделение.ОбменДанными.Загрузка. Если оно равно Истина, значит, документ пришел из обмена.Пример кода обработчика:
Процедура ПодменаПодразделенияПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
// Проверяем, что идет загрузка данных из обмена
Если Источник.ОбменДанными.Загрузка Тогда
// Проверяем наличие реквизита "Подразделение" у объекта
МетаданныеОбъекта = Источник.Метаданные();
Если МетаданныеОбъекта.Реквизиты.Найти("Подразделение") <> Неопределено Тогда
НужноеПодразделение = Справочники.ПодразделенияОрганизаций.НайтиПоКоду("00-000001");
Если Источник.Подразделение <> НужноеПодразделение Тогда
Источник.Подразделение = НужноеПодразделение;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Важно: При использовании этого метода в БП КОРП следует помнить, что подразделение может использоваться не только как реквизит шапки документа, но и как аналитика (субконто) на счетах учета в табличных частях. В этом случае код должен быть дополнен обходом табличных частей и проверкой движений документа.
Рассмотрим важный аспект, касающийся версии КОРП. В данной версии бухгалтерии реализован сквозной учет по подразделениям на всех планах счетов. Если вы решите «схлопнуть» все подразделения из УТ в одно в БП, вы потеряете возможность анализировать финансовый результат в разрезе этих подразделений на стороне бухгалтерии.
Если ваша задача — просто избежать дублирования справочников, но сохранить аналитику, возможно, стоит рассмотреть создание в БП иерархии подразделений, где все «торговые» подразделения будут подчинены одной группе. Однако, если требование заказчика жесткое — «все в одно», то использование Способа 3 (расширение через XDTO) является наиболее профессиональным и надежным решением.
Для решения задачи объединения подразделений при обмене через Enterprise Data мы рекомендуем:
Помните, что любые манипуляции с данными в момент загрузки должны быть тщательно протестированы на копии базы, чтобы убедиться в корректности формирования проводок и заполнения всех необходимых аналитик.