1С:Розница для нескольких магазинов — распределенная база (РИБ) или тонкий клиент на сервере?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Розница Управленческий учет Торговля и дистрибуция
← На главную

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

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

Вариант №1: Единая база и тонкий клиент через веб-сервер

Этот подход предполагает, что и центральный офис, и все торговые точки работают в одной физической базе данных, которая расположена на сервере (в офисе или в облаке). Магазины подключаются к ней через интернет.

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

Единственный правильный способ работы в единой базе — это публикация информационной базы на веб-сервере (IIS или Apache). В этом случае подключение касс выполняется через тонкий клиент по протоколам HTTP/HTTPS.

Рассмотрим ключевые преимущества такого подхода:

  1. Абсолютная централизация. Все данные по продажам, остаткам, ценам и контрагентам доступны в режиме реального времени. Руководитель видит актуальную картину бизнеса без задержек на обмен.
  2. Простота администрирования. База данных всего одна. Обновление конфигурации, установка исправлений (патчей) и резервное копирование выполняются централизованно в один клик. Нет необходимости контролировать доставку обновлений на периферийные узлы.
  3. Минимальные требования к оборудованию на точках. На кассовых компьютерах не нужно хранить тяжелую базу данных, следовательно, требования к оперативной памяти и дискам (SSD) касс минимальны.

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

Для минимизации этого риска проанализируем и внедрим схему резервирования связи на точках. Для этого рекомендуется использовать роутеры с поддержкой нескольких провайдеров (Dual-WAN, например, Keenetic). В качестве основного канала заводится проводной интернет, а в USB-порт роутера устанавливается 4G-модем с SIM-картой другого оператора. При обрыве основного кабеля роутер бесшовно за 2–3 секунды переключает весь трафик на мобильную сеть, и кассир в тонком клиенте даже не замечает сбоя.

Вариант №2: Распределенная информационная база (РИБ)

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

Главный плюс РИБ — полная автономность торговой точки. Касса работает со своей локальной базой со скоростью физического диска. Ей абсолютно неважно, есть ли интернет в данный момент. Продажи идут непрерывно, чеки бьются мгновенно, а торговое оборудование работает стабильно.

Но за эту стабильность приходится платить высокой сложностью сопровождения. Выясним основные проблемы РИБ:

Современный компромисс: гибридная схема и РИБ по рабочему месту

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

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

2. Использование легкого приложения «1С:РМК» вместо полноценного РИБ.
В современных версиях платформы (особенно на редакции 1С:Розница 3.0) разработчики предлагают отказаться от классического РИБ в пользу связки «Центральная база + 1С:РМК» (Рабочее место кассира). 1С:РМК — это отдельное, очень легкое приложение, созданное исключительно для оформления продаж. Оно синхронизируется с центральной базой по веб-сервисам через универсальный формат EnterpriseData. Оно полностью автономно (умеет продавать офлайн и накапливать чеки), не требует мощного железа и вообще не содержит внутри себя тяжелых метаданных основной конфигурации 1С:Розница, что навсегда решает проблему мучительных обновлений на кассах.

Решение нештатных ситуаций в РИБ: практические инструкции

Если вы все же остановили свой выбор на классическом РИБ, вам необходимо знать, как оперативно справляться с техническими сбоями.

Как правильно обновлять конфигурацию в РИБ

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

  1. Перед запуском обновления в центральной базе (ЦБ) обязательно завершите все сеансы пользователей и остановите регламентные задания обмена. Проследите, чтобы все периферийные базы (ПБ) прислали свои последние данные, и ЦБ приняла их.
  2. Обновите конфигурацию центральной базы в режиме конфигуратора. Примите изменения базы данных.
  3. Запустите сеанс ЦБ в режиме «Предприятие», чтобы выполнились все фоновые обработчики обновления данных.
  4. Выполните выгрузку обмена из ЦБ. В периферийный узел уйдет только файл конфигурации.
  5. В ПБ запустите синхронизацию. Платформа обнаружит обновление конфигурации, выдаст предупреждение и закроет режим «Предприятие».
  6. Запустите конфигуратор периферийной базы. В меню «Конфигурация» выберите пункт «Обновить конфигурацию базы данных» (кнопка F7). Примените изменения.
  7. Если на слабом компьютере кассы обновление зависает или аварийно завершается, запустите базу с параметром отключения логики начала работы, чтобы снизить нагрузку на оперативную память:

"C:\Program Files\1cv8\current\bin\1cv8.exe" ENTERPRISE /F"C:\1C_Bases\Retail_PB" /N"Администратор" /P"Пароль" /C"ОтключитьЛогикуНачалаРаботыСистемы"

Что делать, если базы «разъехались» (рассинхронизация данных)

В случае аппаратного сбоя, повреждения жесткого диска или критической ошибки базы данных на торговой точке, данные в ЦБ и ПБ могут стать неидентичными. Попытка восстановить ПБ из старого бэкапа приведет к нарушению нумерации сообщений обмена.

Проанализируем правильный алгоритм восстановления работоспособности точки:

  1. Не пытайтесь вручную «смержить» разъехавшиеся базы через COM-соединение или сторонние утилиты — это приведет к появлению дублей справочников.
  2. Если база на точке «умерла», но в ней остались неотправленные чеки и документы, выгрузите их во внешний XML-файл с помощью универсальной обработки «Выгрузка и загрузка данных XML».
  3. В центральной базе создайте новый чистый образ периферийного узла для этого магазина.
  4. Установите созданный образ базы на кассовый компьютер торговой точки. При первом запуске он будет содержать абсолютно актуальные и чистые данные из центра.
  5. Загрузите ранее сохраненные неотправленные документы из XML-файла обратно в новую базу точки. При синхронизации платформа автоматически сопоставит объекты по их уникальным идентификаторам (УИД), исключая дублирование данных.

Рекомендация по минимизации коллизий при обмене

Настройте правила регистрации объектов в плане обмена розничной сети так, чтобы минимизировать двустороннее редактирование. Идеальный сценарий:

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

← На главную