← На главную

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

Разберем по шагам, как выстроить надежную топологию обмена данными, обеспечить автономность магазинов, учесть специфику работы с ЕГАИС и автоматизировать передачу отчетов без перегрузки слабого сервера.

Шаг 1. Анализ ограничений архитектуры и выбор топологии сети

Проанализируем технические возможности платформ и конфигураций. В распределенных системах часто возникает соблазн объединить все узлы в единый Распределенный информационный банк (РИБ) или перевести все кассы на работу через браузер/веб-клиент. Выясним причину, почему простые решения здесь не сработают:

1. РИБ между разнородными конфигурациями невозможен: механизм распределенной информационной базы платформы «1С:Предприятие» работает исключительно между идентичными конфигурациями. Нельзя построить прямой РИБ между КА 1.1 и Розница 2.
2. Риски веб-клиента и тонкого клиента в рознице: работа кассового узла через онлайн-подключение (HTTP/HTTPS) полностью зависит от стабильности интернет-канала. Любой обрыв связи или высокая нагрузка на центральный сервер приведут к остановке работы РМК (Рабочего места кассира) и зависанию чеков в момент фискализации. Кроме того, прямое взаимодействие веб-браузера с торговым оборудованием (сканеры, фискальные регистраторы) через драйверы виртуальных COM-портов часто приводит к сбоям тайм-аутов.
3. Специфика ЕГАИС: продажа алкоголя жестко привязана к физическому аппаратному ключу (JaCarta или Рутокен ЭЦП) и локальному сервису УТМ (Универсальный транспортный модуль), который разворачивается непосредственно в контуре торговой точки. Сама конфигурация КА 1.1 снята с поддержки в части актуальных форматов ЕГАИС, поэтому весь учет алкоголя должен замыкаться внутри Розницы 2.

Оптимальным решением является трехуровневая гибридная схема:

КА 1.1 <--(XML / План обмена)--> Центральная Розница 2 <--(РИБ по магазинам)--> Периферийные узлы Розницы 2

Шаг 2. Разделение потоков: РИБ внутри розницы и шлюз в учетную систему

Разберем подробнее, как функционирует каждый контур такой системы:

1. Контур розничной сети (Центральный узел «Розницы» — Периферийные кассы):

   Разворачиваем центральную базу Розница 2 на сервере и создаем стандартный механизм РИБ по магазинам. На каждый ноутбук в торговой точке устанавливается локальная файловая информационная база. Это обеспечивает полную автономность: кассиры бьют чеки, сканируют марки и отправляют запросы в локальный УТМ даже при полном отсутствии интернета. При появлении связи пакеты изменений штатно курсируют между магазином и центральным узлом розницы. Механизм РИБ по магазинам автоматически фильтрует данные, не перегружая ноутбуки остатками чужих торговых точек.

2. Контур регламентного учета (Центральный узел «Розницы» — КА 1.1):

   Для связи розницы с оптовой системой настраивается синхронизация в формате XML с использованием Конвертации данных 2.0 и стандартных планов обмена. В КА 1.1 из розницы не нужно транслировать почековые продажи алкоголя и внутренние логи ЕГАИС. Передаются только сводные документы Отчет о розничных продажах, складские перемещения и выручка. За счет того, что обмен с КА выполняет одна центральная база «Розницы», а не 24 магазина одновременно, слабый сервер опта не испытывает пиковых перегрузок.

Шаг 3. Нормализация справочников и централизация НСИ

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

Организуем процесс упорядочивания справочников по следующим правилам:

1. Сведение номенклатуры по жестким идентификаторам: в качестве эталонных ключей для склейки одинаковых позиций используем штрихкоды производителей (EAN-13), а для алкогольной продукции — АлкоКод из справочников ЕГАИС. Для устранения накопившихся дубликатов в базах применяется штатная обработка Поиск и удаление дублей с заменой ссылок во всех документах.
2. Блокировка создания номенклатуры на местах: после очистки справочников в центральном узле розницы на уровне прав доступа кассирам и администраторам магазинов категорически запрещается создание и редактирование элементов справочника Номенклатура. Все новые карточки товаров заводятся централизованно товароведами и спускаются в периферийные базы через РИБ.

Шаг 4. Настройка регламента обменов и разрешение коллизий

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

Организуем периодический цикл обмена по цепочке:

КА 1.1 -> Центр «Розницы» -> Магазины -> Центр «Розницы» -> КА 1.1

Выгрузку из центрального узла «Розницы» в КА 1.1 целесообразно запускать регламентным заданием в ночные часы или в моменты минимальной загрузки операторов. В результате бухгалтеры утром получают готовые документы розничных продаж за закрытую смену, исключая ручной ввод данных из таблиц, а бизнес сохраняет полную масштабируемость для подключения новых торговых точек без риска потери отказоустойчивости.