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

← На главную

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

Архитектурная схема объединения данных

Для успешного перехода рекомендуется разделить проект на последовательные этапы, не пытаясь настроить сквозной двухсторонний обмен сразу между тремя информационными базами:

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

Очистка дублей и особенности сопоставления справочников

Проанализируем специфику идентификации ключевых объектов учета при слиянии баз:

Контрагенты: для юридических лиц сопоставление выполняется строго по связке ИНН + КПП. Если среди контрагентов присутствуют индивидуальные предприниматели и частные лица, у которых КПП отсутствует или заведены одинаковые наименования, сопоставление необходимо выполнять по ИНН, а при его отсутствии — по ФИО и контактной информации (номерам телефонов, адресам электронной почты из регистра КонтактнаяИнформация).
Номенклатура: сопоставление следует производить по артикулу либо полному наименованию. Важно учитывать, что в УТ номенклатура может вестись с характеристиками и упаковками, тогда как в БП учет ведется по плоскому справочнику.
Физические лица: поиск совпадений выполняется по связке ФИО, даты рождения и паспортных данных.

После первоначального переноса нормативно-справочной информации в базу УТ воспользуемся типовой обработкой ПоискИУдалениеДублей (раздел НСИ и администрирование → Обслуживание → Корректировка данных). Выполним поиск совпадений по ИНН/наименованию, назначим правильные элементы оригинальными и произведем слияние с заменой ссылок во всех перенесенных объектах.

Почему контрагент не подставляется в документ и открывается в режиме создания

При самостоятельной разработке правил конвертации (в «Конвертации данных 2.0» или 3.0) разработчики часто сталкиваются с двумя проблемами в УТ 11:

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

Посмотрим на пример заполнения связки партнера и контрагента в обработчике «ПослеЗагрузки» правила конвертации объекта (ПКО) справочника Контрагенты:


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

Подключение собственных правил обмена без снятия с поддержки

Выясним, как внести корректировки в типовой обмен, не изменяя конфигурацию поставщика:

Подключение внешней обработки в узле обмена: типовая библиотека стандартных подсистем (БСП) позволяет переопределить логику правил. В форме настроек параметров синхронизации данных (или через редактирование узла плана обмена) можно выгрузить типовой модуль конвертации во внешнюю обработку, отредактировать алгоритмы формирования данных и подключить ее обратно в качестве внешнего обработчика узла.
Использование расширений конфигурации: если обмен настраивается через универсальный формат (EnterpriseData), правила выгрузки и загрузки сосредоточены в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. Создадим расширение конфигурации и переопределим необходимые обработчики событий выгрузки или загрузки с помощью директив &Перед, &После или &Вместо.

Рассмотрим пример в расширении для общего модуля, где мы переопределяем заполнение реквизитов объекта при выгрузке, чтобы избежать ошибок валидации схемы XDTO:


&Вместо("ПКО_Справочник_БанковскиеСчета_ПриВыгрузке")
Процедура Расш1_ПКО_Справочник_БанковскиеСчета_ПриВыгрузке(Источник, ДанныеXDTO, КомпонентыОбмена)
    // Выполняем стандартное поведение
    ПродолжитьВызов(Источник, ДанныеXDTO, КомпонентыОбмена);
    
    // Защита от незаполненного наименования банковского счета для формата EnterpriseData
    Если ПустаяСтрока(ДанныеXDTO.Наименование) Тогда
        ДанныеXDTO.Наименование = "Основной счет (авто)";
    КонецЕсли;
КонецПроцедуры

Ошибки XDTO при использовании универсального формата EnterpriseData

При использовании типового универсального формата разработчики регулярно сталкиваются с фатальными ошибками проверки XML по схеме XDTO. Причина заключается в том, что в схеме формата многие реквизиты имеют ограничение minOccurs="1" (обязательное наличие поля в пакете). Если в базе-источнике не заполнены наименование счета, ставка НДС или подразделение, выгрузка прерывается аварийно.

Для устранения этой проблемы применяются два подхода:

Переход на более свежую версию формата: начиная с версии формата EnterpriseData 1.3 и выше, разработчики 1С существенно смягчили жесткие требования к обязательности заполнения многих вспомогательных реквизитов. Убедимся, что базы обновлены до релизов, поддерживающих актуальные версии формата обмена.
Заполнение реквизитов значениями по умолчанию: в правилах выгрузки (в обработчиках «ПриВыгрузке» или «ПередОбработкойПравила») следует программно подставлять значения по умолчанию для пустых реквизитов источника, гарантируя корректное формирование структуры XDTO.