← На главную

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

Причины возникновения рассинхронизации и блокировок

Проанализируем техническую сторону процесса пробития чека. В момент нажатия кнопки оплаты в РМК программа выполняет последовательность действий:

1. Открывается транзакция базы данных 1С, подготавливаются движения по регистрам.
2. Посылается команда фискальному регистратору на печать и фискализацию операции в фискальном накопителе (ФН).
3. ККТ записывает операцию в ФН, отправляет данные в ОФД и печатает чек. Это действие необратимо.
4. Драйвер ККТ возвращает в 1С подтверждение об успешной печати с фискальными реквизитами.
5. 1С фиксирует реквизиты, проводит документ Чек ККМ и закрывает транзакцию СУБД.

Если на шаге 4 или 5 возникает любая ошибка, транзакция в 1С аварийно откатывается. Чек на фискальнике уже пробит, а в информационной базе документ остается непроведенным. Выделим главные факторы, вызывающие этот сбой:

1. Конфликт с фоновым обменом РИБ (Распределенная Информационная База): Это наиболее частая причина в конфигурациях с планом обмена По магазину. Во время выполнения сеанса синхронизации платформа 1С накладывает транзакционную блокировку на таблицы базы данных для обеспечения целостности данных. Если кассир пробивает чек именно в этот момент, проведение документа блокируется ошибкой вида «Не удалось заблокировать таблицу...». Блокировка РИБ инициируется на уровне платформы, поэтому отключить ее стандартными средствами конфигуратора нельзя.
2. Файловый режим работы информационной базы: В файловых базах (.1CD) блокировки накладываются не на отдельные строки, а на целые таблицы. Одновременная запись чека и фоновый обмен неизбежно приводят к коллизиям.
3. Таймауты драйвера торгового оборудования: При задержках ответа от ККТ или нестабильной связи по интерфейсам COM/USB драйвер 1С регистрирует ошибку связи по таймауту и прерывает транзакцию, хотя ККТ уже завершила печать.
4. Сбои эквайрингового терминала: При задержке ответа от банковского сервера кассовый модуль 1С может выдать ошибку тайм-аута после списания средств, отменяя проведение документа в учетной системе.

Пошаговый порядок действий при обнаружении зависшего чека

Разберем регламент, которому необходимо следовать кассиру и администратору при возникновении зависшего чека:

1. Категорический запрет на повторное пробитие из РМК: Ни в коем случае нельзя нажимать кнопку повторной оплаты или пробития в РМК. Так как фискальный чек уже зарегистрирован в ФН, повторная отправка команды приведет к задвоению выручки в ОФД и кассовой недостаче при сверке смены.
2. Сверка фактической фискализации: Проверим, действительно ли чек прошел через кассу. Для этого снимем на ККТ отчет без гашения (X-отчет), сверим номер чека и сумму в личном кабинете ОФД либо проверим записи в регистре сведений ФискальныеОперации в 1С.
3. Корректировка статуса документа Чек ККМ:

   Откроем список документов «Чеки ККМ» (вне интерфейса РМК). Если документ позволяет выполнить ручное проведение без отправки команды на ККТ, проведем его.

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

   1. Выбираем проблемный документ Чек ККМ.
   2. Устанавливаем реквизит Проведен в значение Истина.
   3. Устанавливаем реквизит СтатусЧекаККМ в значение Пробит.
   4. Заполняем фискальные параметры (номер фискального документа, номер смены, фискальный признак) в соответствии с данными бумажного чека или ОФД.
4. Штатное закрытие кассовой смены: После того как статус чека скорректирован и движения сформированы, выполняем штатную процедуру закрытия смены в РМК. При этом формируется корректный и сбалансированный документ ОтчетОРозничныхПродажах.

Способы устранения причин и профилактика сбоев

Рассмотрим комплексные меры, которые помогут полностью исключить зависание непробитых чеков в торговой точке:

1. Разнесение по времени обменов РИБ и кассовых операций:

   Настроим расписание регламентных заданий обмена данными в узлах магазинов так, чтобы синхронизация происходила в нерабочие часы (до открытия или после закрытия смены) либо в строго определенные технологические перерывы кассы. Если обмен требуется в течение дня, частоту синхронизации необходимо снизить, а кассиров проинформировать о недопустимости пробития чеков в моменты ручного запуска обмена.

2. Переход на клиент-серверную архитектуру (SQL):

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

3. Настройка параметров драйверов торгового оборудования:

   Откроем параметры подключенного оборудования в 1С и увеличим время ожидания ответа (таймаут) для фискального регистратора и эквайрингового терминала. В диспетчере устройств операционной системы на кассовом ПК обязательно отключим опцию «Разрешить отключение этого устройства для экономии энергии» для всех USB-концентраторов и виртуальных COM-портов.

4. Отключение некритичных регламентных заданий на кассовых узлах:

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

5. Использование автономного рабочего места (1С:РМК):

   Для высоконагруженных магазинов оптимальным решением является разделение учетного контура и контура продаж — переход на автономное приложение «1С:РМК» или специализированные POS-системы с последующей пакетной загрузкой документов в центральную базу.