Как организовать работу филиалов 1С в разных странах и синхронизировать общие остатки номенклатуры?

← На главную

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

Проблема: Почему «простое объединение» не всегда работает

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

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

Проанализируем более гибкие и надежные способы реализации этой задачи.

Вариант 1. Архитектура с «Мастер-базой» и односторонним обменом

Этот вариант считается оптимальным для среднего бизнеса. Мы выделяем одну информационную базу как «эталонную» (Мастер-база), в которой заводится вся номенклатура. Остальные базы филиалов становятся «потребителями» этих данных.

Разберем по шагам, как настроить такую схему:

Выбор эталона. Выбираем наиболее наполненную базу (например, головного офиса). Из нее выгружаем весь справочник Номенклатура.
Запрет редактирования. В базах филиалов (UZ, KZ, KG) на уровне прав доступа или через подписки на события ПередЗаписью устанавливаем запрет на создание и изменение элементов справочника номенклатуры. Все изменения должны приходить только извне.
Синхронизация по GUID. Это критически важный момент. Чтобы избежать дублей, сопоставление товаров должно идти не по наименованию или артикулу, а по уникальному идентификатору GUID. Это гарантирует, что «Порошок А» в Казахстане и «Порошок А» в Узбекистане — это один и тот же объект в системе, даже если их названия локализованы.

Для реализации программного запрета редактирования в подчиненных базах можно использовать следующий пример кода:


Процедура ПриЗаписиНоменклатурыПередЗаписью(Источник, Отказ) Экспорт
    Если НЕ Источник.ОбменДанными.Загрузка Тогда
        Если Пользователи.ТекущийПользователь() <> Справочники.Пользователи.НайтиПоНаименованию("АдминистраторОбмена") Тогда
            Сообщить("Редактирование номенклатуры разрешено только через центральный узел!");
            Отказ = Истина;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Вариант 2. Использование систем класса MDM

Если справочник товаров насчитывает десятки тысяч позиций и характеристики товаров постоянно меняются, рассмотрим использование специализированного решения — 1С:MDM Управление нормативно-справочной информацией.

В чем преимущество такого подхода? MDM-система берет на себя роль «полицейского» данных:

Проверяет новые карточки на дубли по сложным алгоритмам.
Позволяет настраивать маршруты согласования (например, менеджер в KG создал заявку на товар, а категорийный менеджер в центре ее одобрил).
Транслирует данные во все подключенные базы через универсальный формат EnterpriseData.

Этот вариант требует наличия в штате администратора НСИ, но он полностью исключает «чертову тучу характеристик», в которых легко запутаться при ручном сопоставлении.

Вариант 3. Агрегация данных для сайта через API

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

Посмотрим, как это работает:

На стороне сайта или промежуточного микросервиса создается таблица соответствий (маппинг).
Каждая база (UZ, KZ, KG) раз в час отдает свои остатки по HTTP-сервису в формате JSON.
Сайт суммирует остатки по одинаковым артикулам/GTIN и выводит общую цифру пользователю.

Для реализации выгрузки из 1С удобно использовать HTTPСервис. Пример формирования JSON с остатками:


Функция ПолучитьОстаткиДляСайта(Запрос)
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    
    ЗапросОстатков = Новый Запрос;
    ЗапросОстатков.Текст = "ВЫБРАТЬ Номенклатура.Артикул, ЕСТЬNULL(ТоварыНаСкладахОстатки.ВНаличииОстаток, 0) КАК Остаток ...";
    
    Результат = ЗапросОстатков.Выполнить().Выгрузить();
    ЗаписатьJSON(ЗаписьJSON, Результат);
    
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(ЗаписьJSON.Закрыть());
    Возврат Ответ;
КонецФункции

Важные нюансы: Языки и Характеристики

При работе в разных странах неизбежно встает вопрос языка. Выясним, как лучше поступить: наименования в Мастер-базе лучше вести на русском языке (как на основном языке сайта), а для локальных печатных форм в филиалах использовать дополнительные реквизиты или механизмы интернационализации 1С.

Что касается характеристик, проанализируем ситуацию: если их слишком много, попытка синхронизировать их «в лоб» через Excel-файлы (как предлагали некоторые участники форума) приведет к краху системы. Используйте только штатные механизмы обмена 1С, которые поддерживают выгрузку дополнительных реквизитов и сведений. Это сохранит ссылочную целостность данных.