Почему ККТ Штрих-М выдает ошибку «00h, Ошибок нет» при печати чека в 1С и как ее исправить?

← На главную

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

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

В чем природа ошибки «00h, Ошибок нет»

Код состояния 00h формируется самим фискальным накопителем или прошивкой онлайн-кассы и буквально означает: на аппаратном уровне контрольно-кассовая техника работает штатно и никаких внутренних сбоев не зафиксировано.

Почему же тогда в 1С выводится ошибка? Проанализируем цепочку вызовов при фискализации:

Конфигурация 1С собирает пакет данных чека и вызывает функцию фискализации чека (например, в общем модуле МенеджерОборудованияКлиент или ПодключаемоеОборудованиеУниверсальныйДрайверКлиент).
Вызывается метод внешней компоненты: Результат = ОбъектДрайвера.СформироватьЧек(...).
Скомпилированная библиотека внешней компоненты (AddIn / Native) перед отправкой низкоуровневых команд в порт ККТ выполняет внутреннюю валидацию переданных аргументов и структуры XML-пакета.
Если хотя бы один аргумент имеет неверный тип данных или нарушена схема XML, метод AddIn немедленно завершает работу и возвращает значение Ложь, вообще не отправляя фискальные команды в устройство.
Обвязка БПО в 1С видит, что функция вернула Ложь, и сразу обращается к объекту драйвера за описанием последней ошибки устройства. Но поскольку в кассу никакая ошибочная команда не передавалась, драйвер транслирует последний ответ от ККТ: «00h, Ошибок нет».

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

Основная причина: нарушение строгой типизации параметров

Внешние компоненты драйверов ККТ разработаны на C/C++ и требуют строгого соответствия типов данных платформы 1С и типов аргументов COM/AddIn-интерфейса. Платформа 1С позволяет использовать динамическую типизацию, но внешняя библиотека не способна неявно преобразовать ссылочный тип данных конфигурации в строку.

Наиболее распространенная ошибка — передача в структуру параметров чека реквизита Кассир (или Пользователь) в виде ссылки на справочник СправочникСсылка.Пользователи или СправочникСсылка.ФизическиеЛица вместо строки.

Посмотрим на пример ошибочного заполнения данных:


// ОШИБКА: передача ссылки на справочник
ПараметрыЧека.Вставить("Кассир", ПараметрыСеанса.ТекущийПользователь);
ПараметрыЧека.Вставить("КассирИНН", ПараметрыСеанса.ТекущийПользователь.ИНН);

Внутри внешней компоненты парсер ожидает стандартный тип VT_BSTR (строку). Получая внутренний COM-указатель или сериализованную ссылку 1С, валидатор отклоняет пакет данных.

Исправим ситуацию, выполнив явное приведение типов:


// ПРАВИЛЬНО: строгая передача строкового представления
ПараметрыЧека.Вставить("Кассир", СокрЛП(ПараметрыСеанса.ТекущийПользователь.Наименование));
// Либо через функцию Строка():
// ПараметрыЧека.Вставить("Кассир", Строка(ПараметрыСеанса.ТекущийПользователь));

Если ЗначениеЗаполнено(ПараметрыСеанса.ТекущийПользователь.ИНН) Тогда
    ПараметрыЧека.Вставить("КассирИНН", СокрЛП(ПараметрыСеанса.ТекущийПользователь.ИНН));
КонецЕсли;

Другие критические параметры валидации чека

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

Логические флаги: параметры признака отправки электронного чека (по СМС или e-mail) должны иметь тип Булево (строго Истина или Ложь). Передача числовых флагов 0/1 или строк "Да"/"Нет" приводит к сбою валидации.
Копеечные расхождения и математический баланс: сумма всех строк чека с учетом скидок, наценок и округлений обязана до копейки совпадать с итоговой суммой оплат (наличными, безналичными, постоплатой). Расхождение даже на 0.01 руб. блокирует операцию на этапе проверки пакета.
Формат ИНН: для реквизита ИНН кассира или покупателя недопустимо наличие посторонних символов, пробелов и переносов. Длина должна составлять строго 10 либо 12 знаков.
Система налогообложения (СНО): код системы налогообложения в чеке должен точно соответствовать тем СНО, которые были активированы при фискализации самого накопителя в кассе. Передача неактивной СНО отклоняется драйвером.
Спецсимволы в наименованиях: при формировании XML-пакета чека наименования товаров с символами &, <, >, " должны быть экранированы, иначе XML-документ становится невалидным (Not Well-Formed).

Пошаговая инструкция по диагностике

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

Включение расширенного логирования: откройте штатную утилиту «Тест драйвера ККТ» от Штрих-М. В настройках драйвера перейдите на вкладку «Лог» и установите уровень детализации протокола на максимум (отметьте логирование вызовов интеграционной компоненты). В отличие от отладчика 1С, текстовый файл лога зафиксирует точное сообщение валидатора, например: Validation error: invalid type for attribute 'Cashier'.
Сравнение с эталонной базой: откройте демонстрационную конфигурацию БПО той же редакции. Выполните успешное пробитие чека на данном устройстве. Точкой останова в процедуре ФискализацияЧека перехватите входные параметры в обеих базах и сравните типы значений каждого свойства через панель вычисления выражений с помощью функции ТипЗнч().
Проверка совместимости версий: убедитесь, что версия установленного драйвера ККТ поддерживается используемой редакцией БПО. При значительной разнице версий структура XML-пакета чека может отличаться, что также приводит к падению метода СформироватьЧек до обращения к аппарату.