Как исправить ошибку «Конфликт блокировок» при пробитии чека в «1С:Розница» при обмене РИБ?

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

При этом физическое устройство — фискальный регистратор (ККТ) — успевает получить команду, печатает бумажный чек и отправляет данные в ОФД. Однако в самой программе «1С» документ Чек ККМ не проводится и остается в статусе «Черновик» или «Отложен». Повторное нажатие кнопки «Пробить» приведет к дублированию чека на кассовом аппарате и, как следствие, к расхождению кассовой смены и завышению выручки в налоговых органах.

В этой статье мы подробно разберем, как исправить уже возникшие расхождения без повторной печати на ККТ, почему эта ошибка возникает на системном уровне и как настроить программу, чтобы предотвратить такие сбои в будущем.

Раздел 1. Способы исправления расхождений (чек на кассе пробит, а в «1С» нет)

Рассмотрим детально три проверенных практических способа, которые помогут провести зависший чек в «1С» без отправки команды на печать в фискальный накопитель.

Способ 1. Использование встроенной обработки «Групповое изменение реквизитов»

Этот способ является наиболее безопасным и штатным, так как не требует написания программного кода. Выполним следующие шаги:

1. Перейдем в раздел Администрирование — Обслуживание — Корректировка данных и откроем обработку Групповое изменение реквизитов.
2. В правом нижнем углу нажмем кнопку Дополнительные параметры и в открывшемся окне установим флаг Показывать служебные реквизиты. Это необходимо, чтобы получить доступ к системным полям проведения документа.
3. В поле «Выбирать элементы» укажем тип данных Документ: Чек ККМ.
4. С помощью ссылки «Все элементы» настроим жесткий отбор по нашему конкретному ошибочному чеку (например, по номеру, дате или уникальному идентификатору), чтобы случайно не изменить другие документы.
5. В списке доступных реквизитов найдем поле Проведен и установим для него значение Да.
6. Найдем реквизит Статус (или Статус чека ККМ в зависимости от версии релиза) и установим для него значение Пробит.
7. Нажмем кнопку Изменить реквизиты. Программа принудительно запишет новые системные статусы в документ без вызова обработчиков торгового оборудования.
8. Дополнительно, чтобы закрытие смены прошло корректно, нам необходимо вручную связать этот чек с фискальной операцией. Для этого откроем регистр сведений Номера чеков ККТ (или Фискальные операции) через «Все функции» («Функции для технического специалиста») и добавим запись, указав наш документ, номер чека из бумажной ленты и номер смены.

Способ 2. Временный переход на «1С:Эмулятор ККТ»

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

1. Перейдем в раздел Администрирование — Подключаемое оборудование.
2. Найдем в списке наш работающий фискальный регистратор и временно снимем флаг Устройство используется (или запишем настройки подключения и удалим устройство, если этого требует релиз).
3. Создадим новое подключение оборудования, выбрав тип устройства ККТ с передачей данных, а в качестве драйвера укажем встроенный 1С:Эмулятор ККТ.
4. Зайдем в рабочее место кассира (РМК) или откроем наш отложенный/непроведенный чек из списка документов Чеки ККМ.
5. Нажмем кнопку Пробить чек. Программа сымитирует отправку команды на кассу, эмулятор вернет положительный ответ, и «1С» успешно проведет документ, изменив его статус на «Пробит» и списав остатки товаров со склада. Физической печати на реальной кассе при этом не произойдет.
6. Вернемся в настройки подключаемого оборудования, отключим или удалим эмулятор и снова активируем нашу рабочую кассу, вернув флаг использования.

Способ 3. Программное проведение чека (для программистов)

Если у вас есть доступ к конфигуратору или возможность запустить внешнюю обработку, мы можем провести документ программно. Для этого используется свойство объекта ОбменДанными.Загрузка. Установка этого свойства в значение Истина отключает стандартные проверки при проведении, включая обращение к кассовому аппарату.

Посмотрим на пример программного кода, который можно выполнить в режиме «1С:Предприятие» через универсальную обработку групповой обработки объектов или консоль кода:

// Выберем нужный документ по уникальной ссылке
ЧекСсылка = Документы.ЧекККМ.НайтиПоНомеру("00РЗ-000123", ТекущаяДата());

Если Не ЧекСсылка.Пустая() Тогда
    // Получим объект для редактирования
    ЧекОбъект = ЧекСсылка.ПолучитьОбъект();
    
    // Включаем режим загрузки данных, чтобы обойти фискализацию и блокировки
    ЧекОбъект.ОбменДанными.Загрузка = Истина;
    
    // Принудительно устанавливаем корректный статус документа
    ЧекОбъект.СтатусЧека = Перечисления.СтатусыЧековККМ.Пробит;
    
    Попытка
        // Записываем документ с проведением
        ЧекОбъект.Записать(РежимЗаписиДокумента.Проведение);
        Сообщить("Документ " + ЧекСсылка + " успешно проведен в режиме загрузки данных.");
    Исключение
        Сообщить("Ошибка проведения документа: " + ОписаниеОшибки());
    КонецПопытки;
КонецЕсли;

Раздел 2. Почему возникает ошибка: техническая суть бага

Выясним причину, почему в старых релизах конфигурации «1С:Розница 2.2» эта проблема носила массовый характер. Дело в том, что в ранних версиях разработчики использовали неделимую транзакционную модель проведения чека. Вся цепочка действий происходила внутри одной транзакции СУБД:

1. Начало транзакции в «1С».
2. Запись предварительных движений чека.
3. Отправка команды на ККТ и ожидание физической печати чека.
4. Получение ответа от ККТ (фискального признака, номера чека в смене).
5. Запись этих данных в базу и завершение транзакции.

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

Для исправления этого поведения разработчики «1С» зарегистрировали официальную ошибку под кодом 00-00147179. Начиная с поздних релизов «1С:Розница 2.2» и во всех версиях «1С:Розница 2.3 / 3.0», архитектура была изменена: процесс фискализации был вынесен за рамки основной транзакции проведения документа. Теперь чек сначала записывается со статусом подготовки, затем фискализируется на кассе, и только после этого отдельной быстрой транзакцией регистрируется факт его пробития.

Раздел 3. Системные настройки для предотвращения блокировок

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

1. Переход с файлового режима работы на клиент-серверный (SQL)
В файловом режиме базы данных (когда файл 1Cv8.1CD расположен на сетевом диске или локальном компьютере) при любой транзакции часто происходит блокировка целых таблиц. В клиент-серверном варианте (под управлением MS SQL Server, PostgreSQL) СУБД использует механизм управляемых блокировок. Блокируются только конкретные строки данных, относящиеся к проводимому чеку, что позволяет обмену РИБ и кассиру работать одновременно без взаимных конфликтов.

2. Корректировка расписания обменов данными
Частой ошибкой администраторов является настройка обмена РИБ каждые 5–10 минут в течение всего рабочего дня. Проанализируем интенсивность работы торговой точки и применим одно из следующих решений:

• Увеличим интервал обмена до 1–2 часов, либо настроим запуск обмена в периоды наименьшей активности покупателей.
• Полностью отключим автоматический обмен в рабочее время и переведем его на ручной режим. Кассир сможет самостоятельно запускать обмен кнопкой в РМК в моменты отсутствия очереди у кассы.
• Настроим выполнение регламентного задания обмена строго во внерабочее время (утром перед открытием смены и вечером после снятия Z-отчета).

3. Увеличение времени ожидания блокировки данных
По умолчанию время ожидания блокировки в СУБД или на сервере «1С:Предприятие» составляет 20 секунд. Если обмен данными занял таблицу на 22 секунды, транзакция кассы завершится ошибкой. Увеличим этот параметр до 60 секунд. Кассовая программа просто «задумается» на лишние несколько секунд во время проведения чека, дождется, пока обмен отпустит таблицу, и успешно завершит операцию без ошибок.

Для этого в свойствах информационной базы на сервере «1С» или в настройках СУБД найдем параметр Время ожидания блокировки данных (Lock timeout) и установим значение 60.

Применение этих комплексных мер позволит вам полностью исключить возникновение конфликтов блокировок на кассовых узлах и обеспечит стабильную работу торговой точки.