Как объединить независимую рабочую базу 1С:Розница с существующей распределенной базой (РИБ)?

← На главную

Приветствуем вас, уважаемые коллеги! Сегодня мы детально разберем одну из наиболее частых и в то же время сложных задач, с которыми сталкиваются администраторы и программисты 1С при масштабировании розничных сетей. Представим ситуацию: у вас уже успешно функционирует распределенная информационная база (РИБ) «1С:Розница», состоящая из Главного узла (например, Офис) и подчиненных узлов (Магазин, Склад). В то же время в рамках той же организации открывается или уже работает другой магазин, учет в котором некоторое время велся обособленно в точно такой же версии конфигурации «1С:Розница».

Казалось бы, базы одинаковые, структура метаданных идентична — почему бы просто не «привязать» существующую базу к Главному узлу напрямую? Однако при первой же попытке стандартного обмена данными вы столкнетесь с катастрофическими последствиями: задвоением справочников номенклатуры, контрагентов, касс и складов. Давайте проанализируем причины этой проблемы и подробно рассмотрим три практических метода ее решения.

В чем заключается главная техническая сложность?

Ключевая проблема кроется в понятии уникального идентификатора объекта (GUID или UUID). Платформа «1С:Предприятие 8.3» идентифицирует любой элемент справочника или документ не по его коду, артикулу или наименованию, а по уникальной 128-битной строке GUID.

Даже если в обеих базах заведена номенклатура «Молоко 3.2%» с одинаковым кодом и штрихкодом, в независимой базе этой позиции соответствует один GUID, а в базе РИБ — совершенно другой. При прямом объединении баз платформа воспримет их как два абсолютно разных товара. В результате в вашей системе образуется огромное количество дублей, что полностью парализует складской и финансовый учет. Для решения этой задачи нам потребуется выполнить синхронизацию и сопоставление этих идентификаторов.

Метод 1. Классический и безопасный (Слияние данных и создание нового узла)

Рассмотрим по шагам наиболее надежный, штатный метод, гарантирующий полную целостность данных в вашей системе. Суть метода заключается в выгрузке данных из обособленной базы, их загрузке и сопоставлении в Главном узле РИБ с последующим созданием «чистого» начального образа подчиненного узла.

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

Метод 2. Синхронизация через универсальный формат обмена (EnterpriseData)

Что делать, если замена рабочей базы на точке новым начальным образом РИБ крайне нежелательна? Например, на кассовом компьютере подключено и тонко настроено сложное торговое оборудование, эквайринг, ККТ, и перенастройка системы с нуля займет слишком много времени. В такой ситуации проанализируем альтернативный вариант — отказ от РИБ для этой конкретной точки в пользу универсального формата обмена.

Вместо механизма РИБ настроим регулярную синхронизацию данных через встроенный формат EnterpriseData. Рассмотрим особенности этого механизма:

При обмене через универсальный формат сопоставление объектов происходит не по внутренним GUID, а по ключевым полям поиска. Для номенклатуры такими полями могут выступать Штрихкод, Артикул или Наименование. Для контрагентов — ИНН и КПП.
При первом сеансе синхронизации система предложит интерактивно сопоставить данные двух баз. Вы сможете вручную связать одинаковые позиции, избежав дублирования.
Этот способ отлично подходит для файловых баз, находящихся в разных частях города, так как обмен файлами можно настроить через каталог на Яндекс.Диске, FTP или по электронной почте.

Метод 3. Программное преобразование существующей базы в подчиненный узел РИБ

Выясним, существует ли способ обойтись без создания огромного начального образа, если база весит десятки гигабайт, а интернет-канал на точке слабый. Да, существует программный метод привязки. Обращаем внимание, что данный способ требует высокой квалификации и обязательного создания резервных копий обеих баз!

Разберем алгоритм программного связывания баз:

В Главном узле РИБ заходим в соответствующий план обмена и вручную создаем карточку нового подчиненного узла. Запоминаем его код (например, «М2») и код главного узла (например, «ЦБ»).
В базе второго магазина, которая пока еще является независимой, открываем тот же план обмена. Нам необходимо программно изменить свойства узлов так, чтобы текущая база считала себя узлом «М2», а узел «ЦБ» стал для нее Главным узлом.
Для этого используем внешнюю обработку или пишем короткий программный код на встроенном языке 1С. Посмотрим на пример кода:


// Программное назначение главного узла РИБ
Процедура УстановитьСвязьРИБ()
    // Находим или создаем предопределенный узел (ЭтотУзел)
    ЭтотУзелОбъект = ПланыОбмена.ПоМагазинам.ЭтотУзел().ПолучитьОбъект();
    ЭтотУзелОбъект.Код = "М2";
    ЭтотУзелОбъект.Наименование = "Магазин 2 (бывший независимый)";
    ЭтотУзелОбъект.Записать();

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

    // Устанавливаем признак подчиненности главному узлу
    ПланыОбмена.УстановитьГлавныйУзел(УзелЦентр);
    Сообщить("База успешно преобразована в подчиненный узел РИБ!");
КонецПроцедуры

Критически важно: Сразу после выполнения этого кода запускать обмен категорически запрещено! Нам необходимо предварительно выровнять GUID в обеих базах. Для этого используем специализированные обработки по переносу и замене ссылок (например, обработку «Выгрузка загрузка данных XML» с опцией сопоставления по ключевым полям). Только после того, как справочники в обеих базах будут иметь абсолютно идентичные идентификаторы, можно выполнить первый тестовый обмен.

Резюме и рекомендации

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