Как организовать обмен данными между семью магазинами на 1С:Розница, центральным складом на 1С:УТ 10.3 и 1С:Бухгалтерией 3.0?

← На главную

Автоматизация распределенной торговой сети — классическая, но ответственная задача. Когда в контуре задействованы разнородные конфигурации разных поколений (управляемые формы в 1С:Розница 2.2 и 1С:Бухгалтерия предприятия 3.0, а также обычные формы в устаревшей 1С:Управление торговлей 10.3), неправильный выбор топологии неизбежно приводит к хаосу: дублированию номенклатуры, блокировкам баз данных и нестыковкам в бухгалтерских регистрах.

Разберем детально, как правильно выстроить архитектуру обменов, защитить базу от «засемерения» справочников, передавать оперативные остатки и связать все узлы в единый стабильный комплекс.

Архитектурная топология: почему нельзя подключать магазины напрямую к УТ

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

Проанализируем проверенную и надежную топологию обмена:

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

Преимущество распределенной базы в розничном контуре очевидно: система гарантирует единое пространство дисконтных карт, подарочных сертификатов и централизованное ведение нормативно-справочной информации (НСИ).

Решение проблемы дублирования номенклатуры («засемерения»)

Главный риск при объединении нескольких рабочих баз — появление одинаковых товаров с разными кодами. Если каждый магазин начнет заводить номенклатуру самостоятельно, синхронизация сольет их воедино с образованием множественных дублей.

Для предотвращения этой проблемы реализуем регламент мастер-системы (MDM):

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

Техническая реализация обмена: форматы и несовместимость поколений

Выясним причину технической сложности стыковки данных конфигураций. Конфигурации Розница 2.2 и БП 3.0 построены на базе Библиотеки стандартных подсистем (БСП) и применяют формат EnterpriseData (механизм XDTO). В то же время УТ 10.3 — конфигурация прежнего поколения, работающая по классическим правилам обмена конфигурации Конвертация данных 2.1 через формат XML.

Для организации обмена УТ 10.3 — Розница 2.2 доступны два рабочих пути:

Типовые правила обмена через КД 2.1: используем встроенные или адаптированные внешние правила конвертации данных. Передача пакетов осуществляется через общий сетевой каталог, FTP-сервер или прямое COM-соединение. Важно помнить: при использовании COMConnector разрядность платформы клиента и сервера должна строго совпадать.
Интеграция через Web/HTTP-сервисы: разработка собственных веб-сервисов позволяет связать системы напрямую без создания промежуточных файлов обмена, что существенно повышает стабильность и скорость передачи данных.

Как передавать оперативные остатки склада в магазины

Стандартный план обмена регистрирует изменения только ссылочных объектов (документов, справочников) и не предназначен для трансляции виртуальных итогов регистров накопления, таких как свободные складские остатки.

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

Регламентный документ фиксации остатков: в УТ 10.3 по расписанию формируется информационный документ или заполняется специализированный регистр сведений, который фиксирует срез свободных остатков по складу. Этот объект регистрируется в плане обмена, мигрирует в центральную Розницу, а оттуда через РИБ расходится по магазинам.
Онлайн-запрос через HTTP-сервис: на стороне УТ 10.3 публикуется легковесный HTTP-сервис. В интерфейсе кассира или менеджера в Рознице 2.2 добавляется кнопка «Запросить остаток на складе», которая отправляет быстрый REST-запрос к УТ и моментально возвращает актуальное число без нагрузки на базу постоянным обменом.

Посмотрим на пример структуры функции в 1С, выполняющей онлайн-запрос остатка к центральной базе через HTTP:


Функция ПолучитьОстатокНаСкладе(ИдентификаторТовара) Экспорт
    Соединение = Новый HTTPСоединение("192.168.1.10", 80, "WebUser", "SecretPass", , 5);
    Запрос = Новый HTTPЗапрос("/ut10_base/hs/stock/get?id=" + XMLСтрока(ИдентификаторТовара));
    
    Попытка
        Ответ = Соединение.Получить(Запрос);
        Если Ответ.КодСостояния = 200 Тогда
            ЧтениеJSON = Новый ЧтениеJSON;
            ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
            Данные = ПрочитатьJSON(ЧтениеJSON);
            Возврат Данные.Остаток;
        КонецЕсли;
    Исключение
        ЗаписьЖурналаРегистрации("СвязьСУТ", УровеньЖурналаРегистрации.Ошибка, , , ОписаниеОшибки());
        Возврат 0;
    КонецПопытки;
КонецФункции

Трансляция данных в «1С:Бухгалтерию 3.0»

Для передачи данных бухгалтеру, работающему удаленно, используется штатный обмен между УТ 10.3 и БП 3.0. Выгрузка розничной выручки выполняется через сводные документы ОтчетОРозничныхПродажах, а оптовые отгрузки со склада — через документы РеализацияТоваровИУслуг.

При настройке бухгалтерского обмена необходимо проконтролировать следующие параметры:

Сопоставление счетов учета: статьи доходов, расходов и номенклатурные группы должны быть синхронизированы заранее, чтобы избежать зависания сумм на счетах 62.Р, 57.03 (эквайринг) и 90.01.
Своевременная актуализация правил: поскольку УТ 10.3 снята с активного развития, регулярные изменения законодательства и форм отчетности в БП 3.0 требуют ручной корректировки правил конвертации с помощью конфигурации Конвертация данных 2.1.

Итог: описанная трехуровневая схема (РИБ в контуре магазинов + единый центральный узел «Розницы» + складская «УТ 10.3» + удаленная «БП 3.0») гарантирует надежную работу сети, исключает появление дублей номенклатуры и обеспечивает корректный учет товарных и финансовых потоков.