Работа в режиме распределенной информационной базы (РИБ) в конфигурации «1С:Розница 2» часто сопровождается неприятной ситуацией: в момент выполнения автоматической синхронизации кассир пытается пробить чек, но система выдает ошибку блокировки. Особенно критично это становится, когда по фискальному регистратору чек уже «прошел», а в базе 1С документ не создался или не провелся из-за конфликта доступа. Рассмотрим подробно, почему это происходит и как настроить систему для бесперебойной работы.
Проанализируем механику процесса. В режиме РИБ (Распределенная Информационная База) обмен данными — это не просто пересылка файлов. При загрузке сообщения обмена система открывает транзакцию, в рамках которой записывает новые объекты и, что самое важное, зачастую сразу пытается их провести. Проведение документа — это ресурсоемкая операция, которая накладывает блокировки на таблицы регистров накопления (например, «Остатки товаров на складах», «Продажи» и др.).
Если в этот же момент кассир нажимает кнопку «Пробить чек», его сеанс пытается записать данные в те же самые таблицы. Возникает конфликт: транзакция обмена «держит» таблицу, а транзакция чека ждет её освобождения. Если ожидание превышает установленный лимит (обычно 20 секунд), кассир получает ошибку. Выясним, какие инструменты позволяют нам развести эти процессы во времени и ресурсах.
Самый простой и эффективный способ снизить нагрузку на базу в момент синхронизации — запретить системе проводить документы сразу «потоком». Разберем, как это сделать программно и в настройках.
В настройках синхронизации (в узле обмена) необходимо найти опцию «Проводить документы при поступлении». Если этот флаг установлен, система пытается выполнить проведение каждого входящего документа в рамках процесса загрузки. Мы рекомендуем снять этот флаг. В этом случае документы будут загружены в базу со статусом «Записан», но без движений по регистрам. Это мгновенно снимет блокировки с таблиц остатков.
Для автоматизации последующего проведения можно использовать механизм «Отложенного проведения». Рассмотрим, как это работает на уровне логики системы:
ОбменДанными.Загрузка = Истина.ОчередьДокументовДляПроведения.Такой подход позволяет основному обмену завершиться максимально быстро, не блокируя работу кассового узла.
Рассмотрим подробнее настройку отложенного проведения. В «1С:Розница» этот механизм реализован для того, чтобы минимизировать время ожидания пользователя. Когда документы приходят из центрального офиса (например, новые цены или перемещения), они не обязательно должны быть проведены сию секунду.
Чтобы активировать этот режим, проанализируем настройки параметров учета. В разделе «Администрирование» — «Синхронизация данных» проверьте расписание регламентного задания «Отложенное проведение документов». Оптимально настроить его так, чтобы оно отрабатывало короткими порциями. Это позволит избежать ситуации, когда «накопившаяся» пачка документов заблокирует базу в середине дня.
Если стандартных настроек недостаточно, и блокировки продолжаются, следует обратить внимание на объем данных, обрабатываемых в одной транзакции. По умолчанию РИБ может пытаться загрузить весь файл обмена в одной транзакции. Если файл содержит 1000 документов, блокировка будет висеть долго.
Мы можем изменить это поведение, настроив количество объектов в одной транзакции. Посмотрим на пример кода, который может быть использован в обработке обмена или подписке на событие (в зависимости от версии БСП):
// Установка лимита объектов в транзакции загрузки
ПараметрыЗагрузки = ОбменДаннымиСервер.ПараметрыЗагрузкиДляУзла(СсылкаНаУзел);
ПараметрыЗагрузки.КоличествоОбъектовВТранзакции = 50;
// Вместо стандартных 0 (все в одной) или 1000
Разбив загрузку на небольшие порции по 50-100 объектов, мы даем возможность другим сессиям (кассирам) «вклиниться» между транзакциями обмена и выполнить свои операции.
Проанализируем ситуацию, описанную пользователями форума: «Если ставить обмен каждый час — все равно ловим блокировки». Здесь важно понимать бизнес-процесс. Если магазину критически нужны актуальные остатки каждые 30 минут, обмен неизбежен. Но если цель — просто передать продажи в центр, то частоту можно снизить или перенести на время обеда/пересменки.
Интересным решением является создание отдельного узла для оборудования. Если в магазине несколько компьютеров, можно выделить один как «серверный» для обмена, а на кассовых терминалах минимизировать активность фоновых заданий. Однако в 1С:Розница чаще всего касса и есть узел РИБ. В таком случае стоит рассмотреть возможность перехода на работу через Тонкий клиент к центральной базе (если позволяет интернет) или использование Автономного рабочего места (АРМ), которое работает через веб-сервисы и менее агрессивно блокирует таблицы.
Если ваша база работает в клиент-серверном варианте (MS SQL, PostgreSQL), одной из причин блокировок является механизм управления блокировками самой СУБД. Выясним, как это оптимизировать.
Для MS SQL Server крайне рекомендуется включение режима Read Committed Snapshot Isolation (RCSI). Рассмотрим, что это дает: при включении этого режима операции чтения перестают блокироваться операциями записи. Кассир, формируя чек (чтение остатков), не будет ждать, пока процесс обмена допишет данные в таблицу. Включить его можно следующим скриптом в SQL Management Studio:
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [Имя_Вашей_Базы] SET READ_COMMITTED_SNAPSHOT ON;
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
Важно: этот режим значительно снижает количество блокировок TLOCK в системе и является «золотым стандартом» для высоконагруженных розничных сетей.
Что делать, если чек на фискальном регистраторе пробит, а в 1С его нет из-за ошибки блокировки? Проанализируем правильный алгоритм действий:
Попытка...Исключение с повтором транзакции записи при ошибке блокировки.Рассмотрим пример логики повтора:
КоличествоПопыток = 0;
УспешноЗаписано = Ложь;
Пока КоличествоПопыток < 3 И НЕ УспешноЗаписано Цикл
Попытка
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
УспешноЗаписано = Истина;
Исключение
КоличествоПопыток = КоличествоПопыток + 1;
// Ожидание 1-2 секунды перед повтором
Приостановить(2);
КонецПопытки;
КонецЦикла;
Такой программный «запас прочности» позволяет кассе дождаться окончания короткой транзакции обмена и успешно завершить операцию без участия программиста.
Подведем итог нашему разбору. Чтобы победить блокировки при синхронизации в «1С:Розница 2», нужно действовать комплексно:
Применяя эти шаги, мы обеспечим стабильную работу кассиров и актуальность данных в системе без конфликтов и нервных ситуаций на торговой точке.