При работе со старыми конфигурациями на платформе 1С:Предприятие 7.7 программисты и системные администраторы часто сталкиваются с крайне коварной проблемой. Во время печати чека на фискальном регистраторе (ФР) семейства АТОЛ (например, популярном FPrint-22K) система выдает ошибку: «Фискальный регистратор: ошибка при печати чека. Не поддерживается в данном режиме устройства».
Самый примечательный и сбивающий с толку симптом этой неисправности — так называемый «эффект отладчика». Когда разработчик заходит в конфигуратор, открывает код обработки обслуживания ККТ и начинает проходить процедуру печати пошагово (нажимая клавишу F10 на каждой строке кода), чек печатается без каких-либо сбоев, а устройство возвращает статус успешного закрытия документа. Но стоит запустить программу в обычном режиме кассира — и касса снова наотрез отказывается работать, вылетая в ошибку режима.
В этой статье мы подробно разберем природу данной проблемы, выясним скрытые причины ее возникновения и рассмотрим пошаговые сценарии ее исправления как на уровне кода 1С, так и на уровне системных настроек торгового оборудования.
Основной причиной, почему чек пробивается при пошаговой отладке (через F10), но выдает ошибку в обычном сеансе, является несовпадение скоростей работы программного обеспечения и железа (Race Condition). Платформа 1С 7.7 генерирует и передает команды через OLE-объект драйвера ККТ (например, AddIn.FPrnM45) быстрее, чем физический процессор фискального регистратора успевает завершить предыдущее действие (отрезать бумагу, продвинуть ленту или записать фискальный признак в память) и перевести ККТ в соответствующий режим.
Когда мы нажимаем F10 в конфигураторе, мы искусственно создаем огромные паузы между командами. За это время фискальный накопитель и процессор кассы успевают завершить все процессы. В штатном режиме задержек нет, из-за чего касса получает команду на регистрацию новой позиции в тот момент, когда еще не завершился предыдущий этап, реагируя на это ошибкой режима устройства.
Чтобы решить эту проблему в коде 1С, нам потребуется принудительно добавить задержки (паузы) перед отправкой критически важных команд в модуле обслуживания кассы (обычно это файл fr_comm.ert). Рассмотрим, как это сделать программно с помощью объекта Windows Script Host.
Для начала найдем в коде строки вызова методов открытия документа (OpenDocument) или регистрации позиций (Registration). Добавим перед ними следующий код:
// Создаем системный объект для вызова задержки
Попытка
WshShell = СоздатьОбъект("Wscript.Shell");
// Задаем принудительную паузу в 150-200 миллисекунд
WshShell.Sleep(150);
Исключение
// Альтернативный пустой цикл, если WScript заблокирован политиками безопасности
Для Инд = 1 По 10000 Цикл
ВремПерем = Инд;
КонецЦикла;
КонецПопытки;
Также чрезвычайно эффективно написать цикл, который будет опрашивать ККТ на предмет готовности и ждать, пока устройство вернет статус отсутствия ошибок, прежде чем передавать следующую строчку чека:
// Ожидание готовности ККТ перед отправкой следующей команды
ПопыткаЦиклов = 0;
Успешно = 0;
Пока ПопыткаЦиклов < 15 Цикл
Объект.GetStatus(); // Получаем текущий статус кассы
Если Объект.ResultCode = 0 Тогда
Успешно = 1;
Прервать;
КонецЕсли;
WshShell.Sleep(100); // Ожидаем 100 мс перед повторным запросом
ПопыткаЦиклов = ПопыткаЦиклов + 1;
КонецЦикла;
В процессе эксплуатации кассы из-за микросбоев электропитания, случайных обрывов кабеля связи или замятия чековой ленты устройство может аварийно зависнуть в так называемом «дополнительном режиме» (режим ожидания подтверждения операции, работы с фискальным накопителем или отрезчиком). Из этого режима обычные торговые конфигурации 1С 7.7 вывести кассу не способны, выдавая ошибку режима.
Для исправления этой ситуации выполним сброс режима вручную через низкоуровневые команды драйвера:
EC 02.Если во время предыдущей продажи произошел программный сбой, касса могла остаться в состоянии открытого документа. При попытке 1С открыть новый чек через метод OpenDocument (или его аналог), ККТ возвращает ошибку «Не поддерживается в данном режиме устройства», так как ККТ ждет либо аннулирования, либо закрытия уже висящего в ее памяти чека.
Проанализируем структуру кода и добавим безопасный сброс буфера перед открытием нового чека. В самом начале процедуры печати чека в fr_comm.ert следует разместить команду отмены документа. Если документ не был открыт, метод вернет ошибку, которую мы просто перехватим и проигнорируем, но если чек «завис» — кассовый аппарат успешно его аннулирует.
// Принудительное аннулирование зависшего документа перед открытием нового
Попытка
Объект.CancelReceipt(); // Метод отмены чека в драйвере АТОЛ
Исключение
// Игнорируем ошибку, если открытых чеков в данный момент не было
КонецПопытки;
Этот простой блок кода убережет кассиров от регулярных блокировок кассы при аварийном завершении работы компьютера или перебоях с электричеством.
В современных версиях прошивок ККТ АТОЛ требования к передаваемым параметрам существенно ужесточились по сравнению со временами активного использования 1С 7.7. Старые обработки обслуживания могут отправлять на печать позицию номенклатуры с незаполненным номером отдела (секции) или неверной ставкой налога.
Если в драйвер уходит параметр Department = 0 или значение секции не передается вовсе, касса может заблокировать операцию регистрации строки, сославшись на неверный режим устройства.
Рассмотрим пример правильного заполнения свойств объекта драйвера перед вызовом регистрации позиции в коде 1С:
// Заполнение обязательных реквизитов позиции чека
Объект.Name = СокрЛП(Товар.Наименование);
Объект.Price = ЦенаСНДС;
Объект.Quantity = Количество;
// Явно передаем номер секции (отдела) - строго больше нуля
Объект.Department = 1;
// Передаем корректный индекс налоговой ставки (согласно настройкам в ККТ)
Объект.TaxNumber = ИдентификаторНалога;
// Вызываем метод регистрации позиции чека
Объект.Registration();
Рекомендуется сверить индексы налоговых ставок (TaxNumber) в настройках таблиц ККТ через утилиту «Тест драйвера ККТ» и передавать из 1С именно те идентификаторы, которые запрограммированы в аппарате.
Так как ФР FPrint-22K подключается к компьютеру по интерфейсу USB, операционная система Windows эмулирует виртуальный последовательный порт (COM-порт) для работы драйвера. По умолчанию Windows использует аппаратные буферы FIFO (First In, First Out) для оптимизации передачи пакетов данных. При интенсивном обмене командами эти буферы могут фрагментировать или задерживать отправку критических байтов к ККТ, вызывая сбои связи и ошибки режимов.
Выполним настройку операционной системы для стабилизации обмена данными:
Также обратим внимание на скорость порта. Фискальный регистратор FPrint-22K стабильно работает на высоких скоростях. Убедимся, что скорость обмена данными установлена на уровне 115200 бит/с (или как минимум 9600 бит/с) и совпадает во всех трех местах: в настройках COM-порта в Диспетчере устройств Windows, в параметрах связи утилиты «Тест драйвера ККТ» и непосредственно в настройках торгового оборудования внутри 1С 7.7 (меню Сервис -> Параметры -> вкладка Драйвер ККМ).