Как организовать работу филиалов в 1С:Комплексная автоматизация 2 при нестабильном интернете?

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

Особенности и скрытые ограничения механизма РИБ в КА 2

Проанализируем работу штатного механизма РИБ в конфигурации 1С:Комплексная автоматизация 2. Вопреки расхожему мнению, механизм РИБ в конфигурации присутствует, однако имеет строгие архитектурные рамки:

1. Только полный РИБ без фильтрации: В типовой конфигурации доступен план обмена Полный. В отличие от 1С:Управление торговлей 11 или 1С:Бухгалтерия предприятия, здесь штатно отсутствует РИБ с отборами по организациям или подразделениям. Это означает, что вся база целиком (все справочники, документы и тяжелые регистры накопления) полностью дублируется на каждом филиале.
2. Блокировка процедуры закрытия месяца: Регламентные расчеты (расчет себестоимости товаров, распределение расходов, формирование финансовых результатов) программно заблокированы в периферийных узлах. Выполнять закрытие месяца разрешено исключительно в центральном узле. В филиалы результаты расчета передаются исключительно в виде готовых движений по регистрам после сеанса обмена.
3. Высокий объем служебных данных: Механизмы онлайн-взаиморасчетов и партионного учета КА 2 формируют значительно больше записей в регистрах, чем УТ 10.3. При интенсивном документообороте (от 400 документов в день на филиал) сообщения обмена достигают сотен мегабайт. При слабом или нестабильном интернет-канале передача таких XML-пакетов регулярно завершается таймаутом, что приводит к критическому накоплению очереди изменений.
4. Блокировка при обновлении конфигурации: Любое обновление релиза или изменение метаданных передается в периферийный узел в теле сообщения обмена. До тех пор пока на филиале не примут конфигурацию и не запустят базу в режиме обновления через Конфигуратор, миграция оперативных документов полностью останавливается.

Решение 1. Двухуровневая архитектура: Front-офис + Back-офис через EnterpriseData

Если филиалам требуется полная автономность и независимость от интернет-соединения, разберем двухуровневую схему учета. Вместо развертывания тяжелой копии КА 2 на точках настраивается разделение контуров:

1. На филиалах: Устанавливается легкая конфигурация оперативного контура — например, 1С:Розница или 1С:Управление торговлей. База филиала работает полностью автономно, в ней оформляются продажи, складские перемещения и кассовые операции.
2. В центральном офисе: Эксплуатируется единая база 1С:Комплексная автоматизация 2, выступающая в роли учетного центра (Back-офиса).
3. Механизм обмена: Настраивается синхронизация данных через универсальный формат обмена EnterpriseData. В правилах синхронизации указываются фильтры по конкретным складам и подразделениям филиала.

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

Решение 2. Единая информационная база через веб-сервер и тонкий клиент

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

1. Откажемся от передачи графического интерфейса по RDP, так как протокол удаленного рабочего стола крайне чувствителен к потерям пакетов и задержкам канала.
2. Опубликуем центральную базу 1С:Комплексная автоматизация на веб-сервере (Apache или IIS) по протоколу HTTPS.
3. На рабочих местах филиала настроим запуск штатного Тонкого клиента с подключением по веб-ссылке.
4. В параметрах подключения базы в окне запуска 1С обязательно перейдем в раздел «Параметры подключения» и установим флаг «Скорость соединения: Низкая».

Параметр Скорость соединения: Низкая активирует сжатие серверного трафика, минимизирует количество контекстных серверных вызовов и позволяет комфортно работать с формами даже на мобильном 3G/4G-интернете. При кратковременном обрыве связи сеанс тонкого клиента корректно восстанавливается без потери несохраненных реквизитов формы.

Решение 3. Организация отказоустойчивого интернет-канала (Multi-WAN)

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

1. Установка маршрутизатора с Multi-WAN: В филиале и центральном офисе устанавливаются маршрутизаторы с поддержкой нескольких независимых провайдеров и автоматическим переключением каналов (Failover).
2. Подключение резервного канала: В качестве резервного провайдера подключается роутер с SIM-картой сотового оператора (LTE/4G). При падении кабельной линии роутер мгновенно переключает трафик тонкого клиента на мобильную сеть без разрыва пользовательских сессий.
3. Организация отказоустойчивого VPN: Для защиты передачи данных настраивается зашифрованный туннель (IPsec или WireGuard) между филиалом и центром поверх резервируемых каналов.

Связав стабильный резервированный канал связи с публикацией базы на веб-сервере, мы получаем прозрачную работу в единой базе без сложностей, присущих администрированию распределенных баз данных.