Объединение автономно работающих торговых точек в распределенную информационную базу (РИБ) — одна из наиболее сложных задач администрирования 1С. Ситуация усложняется тем, что магазины не могут остановить розничные продажи, а в каждой базе за время независимой работы накопились собственные дубли справочников, различающиеся уникальные идентификаторы (GUID) одних и тех же товаров, несовпадающие настройки торгового оборудования и префиксы документов.
Разберем детально, как спланировать и реализовать процесс объединения действующей сети магазинов на базе конфигурации 1С:Розница 2.2 в единую РИБ без длительного простоя кассовых узлов.
Анализ исходных данных и выбор стратегии перехода
Перед началом технических манипуляций проанализируем ключевые сложности, с которыми сталкивается разработчик:
Рассинхронизация нормативно-справочной информации (НСИ). В разных базах один и тот же товар может иметь разные наименования, штрихкоды или артикулы. Прямая загрузка приведет к лавинообразному появлению дублей.
Коллизии нумерации. Если во всех магазинах документы создавались без уникальных префиксов узлов, документы с одинаковыми номерами (чеки ККМ, ПКО, РКО) начнут перезаписывать друг друга при слиянии.
Особенности маркировки и алкогольной продукции (ЕГАИС). В рознице сопоставление алкоголя по наименованию или штрихкоду EAN-13 категорически недопустимо. Идентификация должна осуществляться строго по коду алкогольной продукции (алкокоду) из классификатора ЕГАИС, иначе перестанут сходиться остатки в регистрах ЕГАИС и сломается фиксация вскрытия тары.
Существуют два основных сценария объединения. Рассмотрим каждый из них.
Сценарий 1. Пошаговое слияние НСИ в центральной базе и создание новых периферийных узлов
Этот путь является наиболее чистым и безопасным с точки зрения целостности данных, хотя и требует времени на подготовку центрального узла.
Разберем по шагам алгоритм реализации:
Формирование эталонного центрального узла (ЦБ). За основу берется информационная база с наиболее полной и актуальной номенклатурой (либо база из управляющей системы, например, Управление торговлей).
Консолидация и сопоставление справочников. Из остальных магазинов последовательно выгружаются данные по номенклатуре, штрихкодам и контрагентам. Сопоставление позиций производится по цепочке правил:
— Для алкоголя: строго по коду ФСРАР (алкокоду);
— Для штучного товара: по штрихкоду EAN-13 производителя;
— Для весового или немаркированного товара: по связке артикула и наименования.
Позиции, которые не удалось сопоставить в автоматическом режиме, передаются товароведам на ручную сверку.
Устранение дублей и перенос ссылок. В центральной базе запускается типовая обработка ПоискИУдалениеДублей. Все дублирующиеся карточки заменяются на эталонные элементы с перенаправлением ссылок во всех документах и регистрах сведений (включая регистр Штрихкоды).
Ввод начальных остатков по каждому магазину. По каждому магазину фиксируются фактические остатки на дату перехода (посредством проведения инвентаризации или выгрузки остатков документом ОприходованиеТоваров с фиксацией розничных цен).
Создание начального образа периферийного узла. В центральной базе создается узел плана обмена ПоМагазинам с фильтром по конкретному магазину. Формируется файл начального образа, который доставляется на точку и разворачивается вместо старой базы.
Подключение торгового оборудования. На новой базе в магазине настраиваются рабочие места кассиров (справочник РабочиеМеста), подключаются фискальные регистраторы, сканеры и эквайринговые терминалы.
Сценарий 2. Превращение существующей базы магазина в узел РИБ без остановки продаж
Если магазины не могут выделить время на переустановку баз и повторное подключение оборудования, можно подключить существующую базу магазина к главному узлу программно. В этом случае база магазина объявляется подчиненным узлом уже существующего центра.
Рассмотрим порядок действий для подключения действующей базы к РИБ:
Выравнивание конфигураций. Конфигурация подключаемого магазина и конфигурация центральной базы должны быть приведены к абсолютно идентичному состоянию (одинаковый релиз конфигурации поставщика, идентичные изменения метаданных).
Установка префиксов. В подключаемой базе обязательно настраивается уникальный префикс информационной базы и префикс узла (например, двузначный код точки М1, М2), чтобы исключить пересечение номеров документов.
Очистка регистрации изменений. Это критический шаг: если в подключаемой базе есть зарегистрированные изменения, она попытается выгрузить весь массив своих старых документов в центр, что разрушит структуру данных центрального узла. Перед подключением необходимо программно удалить всю регистрацию изменений по всем планам обмена.
Программное назначение главного узла. С помощью встроенного языка 1С подключаемой базе указывается ссылка на главный узел.
Посмотрим на пример программного назначения главного узла через внешнюю обработку:
// Пример назначения главного узла для текущей информационной базы
УзелЦентр = ПланыОбмена.ПоМагазинам.НайтиПоКоду("ЦБ");
Если Не ЗначениеЗаполнено(УзелЦентр) Тогда
ВызватьИсключение "Главный узел с указанным кодом не найден в плане обмена!";
КонецЕсли;
// Устанавливаем главный узел для текущей ИБ
ПланыОбмена.УстановитьГлавныйУзел(УзелЦентр);
Сообщить("База успешно переведена в подчиненный узел РИБ.");
Если в дальнейшем потребуется временно отвязать узел от РИБ (например, для экстренного обновления или восстановления структуры), используется установка значения Неопределено:
Критические нюансы эксплуатации РИБ при 27 магазинах
Выясним причину возможных проблем при работе большой сети и меры по их предотвращению:
Настройка параметров ЕГАИС и УТМ. В плане обмена ПоМагазинам конфигурации «Розница 2.2» настройки обмена с ЕГАИС привязаны к конкретным магазинам и организациям. Убедитесь, что IP-адреса УТМ и идентификаторы FSRAR_ID в узле каждого магазина указывают именно на локальный транспортный модуль данной торговой точки, иначе касса начнет отправлять чеки в чужой УТМ.
Разделение расписания регламентных заданий. Если 27 узлов начнут одновременную выгрузку по расписанию (например, каждые 15 минут), центральная база столкнется с жесткими транзакционными блокировками таблиц регистрации изменений. Разнесите расписания автоматического обмена для разных узлов по времени.
Архивация чеков ККМ. Поток детальных чеков от 27 магазинов приведет к взрывному росту объема базы данных центрального узла. Обязательно включите в настройках параметров учета флаг автоматической архивации чеков ККМ при закрытии кассовой смены: детальные строки будут свернуты в ОтчетОРозничныхПродажах, снижая нагрузку на систему хранения данных.
Справочник «Рабочие места». Оборудование (ККТ, эквайринг, сканеры) жестко привязано к идентификатору рабочего места клиента. При слиянии баз необходимо проследить, чтобы рабочие места не затирались при миграции справочников через РИБ.