← На главную
При автоматизации розничных точек часто возникает задача объединения нескольких магазинов в единую учетную систему. Однако покупка модуля распределенной информационной базы (РИБ) или дополнительных базовых лицензий может существенным образом увеличить бюджет проекта. Разберем, почему попытки работать с удаленной файловой базой 1С напрямую через сеть приводят к зависаниям, и проанализируем наиболее эффективные варианты решения этой проблемы.
Причины проблемы: почему файловая 1С не работает через Wi-Fi
Проанализируем техническую сторону вопроса. Если информационная база находится в файловом режиме (файл .1cd) на одном компьютере, а второй магазин подключается к расшаренной сетевой папке через Wi-Fi (даже при скорости 3–4 МБ/с), система будет работать крайне нестабильно.
Причины регулярных зависаний и сбоев заключаются в следующем:
- Высокие требования к задержке сети (Latency). Платформа 1С в файловом режиме постоянно считывает и перезаписывает блоки файла
.1cd и индексы. Любой микрообрыв Wi-Fi соединения приводит к фатальной ошибке чтения/записи.
- Риск повреждения базы данных. При обрыве связи в момент записи документа или проведения чека информационная база может получить повреждения внутренних таблиц и индексов, что потребует процедуры
Утилита dbk2.exe или тестирования и исправления.
- Ограничения обычных форм. Конфигурация «Далион: Управление магазином» построена на обычных формах (в отличие от «Далион: Тренд», работающего на управляемых формах). Обычные формы не поддерживают работу через Тонкий клиент или Веб-клиент, поэтому запустить базу через веб-сервер (Apache или IIS) без использования сторонних компонентов не получится.
Основное решение: настройка терминального режима (RDP)
Самым простым, надежным и бюджетным решением в данном случае является организация терминального доступа (RDP). Вместо того чтобы передавать тяжелые файловые данные 1С по нестабильному радиоканалу, обработка данных происходит непосредственно на компьютере-сервере, а по сети передается только графическое изображение экрана и сигналы ввода.
Рассмотрим преимущества этого подхода:
- Стабильность работы. Если Wi-Fi связь временно пропадает, сессия 1С на сервере не завершается аварийно. При восстановлении сети кассир или оператор просто продолжают работу с того места, где остановились.
- Высокая скорость. Скорости канала 3–4 МБ/с более чем достаточно для комфортной работы RDP-сессии без задержек.
- Поддержка торгового оборудования. Современные протоколы RDP позволяют без проблем пробрасывать сканеры штрихкодов, принтеры чеков и печати этикеток с локального ПК в терминальную сессию.
Для организации работы разберем варианты инфраструктуры:
- Использование имеющегося ПК. На первое время можно выделить выделенный компьютер в главном магазине с операционной системой Windows Pro / Server и настроить на нем терминальные подключения.
- Сторонние RDP-серверы. Если покупка полноценной Windows Server с лицензиями RDS выходить за рамки бюджета, существуют специализированные программные решения (например, Thinstuff TSX), позволяющие организовать многопользовательский терминальный сервер на базе десктопных ОС.
- Объединение сетей через VPN. Для защиты трафика и стабильности подключения между магазинами рекомендуется настроить VPN-туннель (например, на базе WireGuard или OpenVPN).
Альтернативные способы обмена данными без РИБ
Если терминальный режим по каким-то причинам не подходит и требуется автономная работа двух независимых баз в каждом магазине, разберем способы ручной синхронизации данных без покупки модуля РИБ.
1. Использование планов обмена без флага РИБ
В платформе 1С можно настроить стандартный план обмена, у которого в конфигураторе снят признак «Распределенная информационная база». Выгрузка и загрузка изменений выполняется через файл XML вручную или по расписанию через сетевую папку или FTP.
2. Универсальный обмен данными XML
С помощью стандартной внешней обработки УниверсальныйОбменДаннымиXML.epf и правил обмена, сформированных в «1С:Конвертация данных», можно периодически переносите документы, справочники и остатки за выбранный период из одной базы в другую.
Предотвращение коллизий при синхронизации двух баз
При параллельной работе двух независимых баз неизбежно возникают конфликты дублирования кодов и штрихкодов. Выясним, как их правильно решить:
- Префиксация нумерации. В настройках параметров учета каждой базы обязательно задается свой уникальный префикс (например, «М1» для первого магазина и «М2» для второго). Это исключает пересечение номеров документов и кодов справочников при обмене.
- Централизованный ввод справочников. Заведение новых товаров, контрагентов и штрихкодов выполняется исключительно в одной головной базе. Во второй магазин данные передаются только в режиме чтения.
- Разделение диапазонов EAN-13. Если товары и внутренние штрихкоды вводятся на обеих точках, за каждым магазином закрепляют свой префикс внутренних штрихкодов (например, префиксы с 20 по 24 используются в первом магазине, а с 25 по 29 — во втором).
- Синхронизация по GUID. При настройке обмена через правила сопоставление справочников должно выполняться по уникальному внутреннему идентификатору элемента (GUID), а не по наименованию или коду.
Таким образом, использование терминального режима (RDP) является наилучшим практическим решением для работы с конфигурацией «Далион» на обычных формах через нестабильный Wi-Fi канал, позволяя полностью избежать затрат на дорогие модули и сохранить целостность данных 1С.