Как синхронизировать номенклатуру и контрагентов между УТ 10.3 и БП 2.0 без дублирования данных

← На главную

При объединении двух уже работающих информационных баз — например, нетиповой конфигурации «Управление торговлей 10.3» и «Бухгалтерия предприятия 2.0» — часто возникает страх получить тысячи дублей номенклатуры и контрагентов. Попытка решить эту проблему «в лоб» через уравнивание внутренних идентификаторов (GUID) во внешнем файле или настройку распределенной информационной базы (РИБ) является распространенной архитектурной ошибкой. Разберем, почему этот путь тупиковый и как правильно организовать сопоставление справочников при старте обмена.

Почему РИБ и ручная правка GUID не работают

Проанализируем технические ограничения платформы «1С:Предприятие», которые делают первоначальный замысел невозможным:

РИБ работает только на одинаковых конфигурациях. Механизм распределенных информационных баз предназначен исключительно для узлов с абсолютно идентичной структурой метаданных. Конфигурации «Управление торговлей» и «Бухгалтерия предприятия» имеют принципиально разную структуру, поэтому синхронизация между ними строится только через нераспределенные планы обмена с использованием правил конвертации данных (формат XML).
Неизменяемость GUID у существующих объектов. Уникальный идентификатор ссылки УникальныйИдентификатор() формируется в момент первоначальной записи объекта в базу данных и является постоянным. Платформа 1С не имеет штатных инструментов для перезаписи GUID существующего элемента. Задать собственный GUID можно только в момент создания нового объекта через вызов Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор(...)). Попытки изменить поле _IDRRef напрямую в таблицах СУБД разрушают ссылочную целостность базы данных, ломают индексы и приводят к непредсказуемым ошибкам в движениях документов.

Как типовой обмен сопоставляет объекты без совпадения GUID

Для успешного обмена равенство системных идентификаторов в двух базах не требуется. Механизм универсального обмена данными («Конвертация данных 2.1») и типовые планы обмена находят объекты по четкой иерархии приоритетов:

Регистр сведений «Соответствие объектов для обмена». Это приоритетный уровень поиска. В регистре хранится связь между ссылкой на элемент в текущей базе и идентификатором объекта базы-корреспондента для конкретного узла плана обмена. Если объект уже сопоставлен, система сразу подставляет нужную ссылку без сверки реквизитов.
Поля поиска в правилах конвертации объектов (ПКО). Если записи в регистре соответствий нет, система ищет совпадения по ключевым бизнес-полям. Для справочника контрагентов это обычно комбинация ИНН + КПП (либо наименование для физических лиц). Для номенклатуры — Артикул, Код или полное наименование с учетом признака ЭтоГруппа.
Создание нового элемента. Только в том случае, если объект не найден ни по регистру, ни по ключевым реквизитам, система создает новую карточку в справочнике.

Почему нельзя «свернуть» номенклатуру при УСН («Доходы минус расходы»)

Нередко возникает идея не переносить детальный справочник номенклатуры из 15–20 тысяч позиций в бухгалтерскую базу, а свернуть его до нескольких обобщенных номенклатурных групп. Выясним, почему при объекте налогообложения УСН «Доходы минус расходы» так делать категорически нельзя.

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

Пошаговый алгоритм объединения баз без дублей

Рассмотрим правильный порядок действий для запуска синхронизации между работающими базами УТ 10.3 и БП 2.0.

Аудит и нормализация НСИ внутри каждой базы. До включения обмена необходимо запустить обработку «Поиск и замена дублей» отдельно в УТ и отдельно в БП. Особое внимание уделим контрагентам: проверяем корректность ИНН и КПП, удаляем лишние пробелы и спецсимволы. В номенклатуре выверяем артикулы и уникальные коды.
Определение мастер-системы (ведущего узла). Устанавливаем организационное правило: в какой базе создаются новые элементы. Как правило, для номенклатуры ведущей базой выступает «Управление торговлей», а в бухгалтерию позиции только загружаются из обмена.
Предварительное программное заполнение регистра соответствий. Чтобы избежать риска создания дублей при первой выгрузке, напишем внешнюю обработку, которая свяжет уже существующие элементы обеих баз. Для этого сопоставим данные через COM-соединение по ключевым полям и сразу сделаем записи в регистр СоответствиеОбъектовДляОбмена.

Посмотрим на пример кода для программной привязки элементов в базе-приемнике:


// Создаем запись соответствия для предотвращения дублирования
ЗаписьСоответствия = РегистрыСведений.СоответствиеОбъектовДляОбмена.СоздатьМенеджерЗаписи();
ЗаписьСоответствия.УзелОбмена = СсылкаНаУзелПланаОбмена;
ЗаписьСоответствия.СобственнаяСсылка = НайденнаяСсылкаВТекущейБазе;
ЗаписьСоответствия.ИмяТипаПриемника = "СправочникСсылка.Номенклатура";
ЗаписьСоответствия.ИдентификаторБазыПриемника = Строка(GUIDОбъектаИзБазыИсточника);

ЗаписьСоответствия.Записать(Истина);

После заполнения этого регистра штатный механизм обмена при чтении входящего XML-сообщения сразу найдет нужную ссылку по идентификатору базы-источника и не станет создавать дублирующий элемент.

Корректировка правил поиска в «Конвертации данных»

Если сопоставить данные напрямую по кодам или артикулам невозможно из-за расхождений в написании, скорректируем правила поиска в конфигурации «Конвертация данных 2.1» (КД 2.1):

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

Применение таких правил позволяет безопасно соединить две исторически изолированные базы, сохранив прозрачный партионный учет для целей УСН и исключив рутинную ручную зачистку дублей после каждого сеанса обмена.