При работе с маркированным товаром в формате ФФД 1.2 пользователи часто сталкиваются с ситуацией, когда первая марка в чеке проверяется успешно, а на последующих ККТ возвращает ошибку D3h (или 211 в десятичном виде) — «Код товара не распознан». Эта проблема специфична для новых фискальных накопителей (ФН-М) и механизмов проверки кодов в реальном времени через ОИСМ (Честный Знак). Разберем подробно, почему возникает этот сбой и как его устранить.
Проанализируем сначала, что происходит «под капотом» системы. В ФФД 1.2 проверка кода маркировки (КМ) — это не просто передача строки, а целая сессия взаимодействия между 1С, драйвером ККТ, самим фискальным накопителем и серверами «Честного Знака». Ошибка D3h означает, что ФН не смог корректно обработать структуру переданного кода или нарушена последовательность команд в текущей сессии. Также сбой может возникать, если буфер чека переполнен после включения разрешительного режима, что часто встречается на фискальных регистраторах «Штрих-М» при длинных наименованиях — для правильного взаимодействия с ОИСМ есть настройка онлайн-касс по ФФД 1.2.
Рассмотрим стандартную цепочку вызовов в 1С при проверке КМ:
ЗапросКМ (RequestKM) — отправка кода в ФН для формирования запроса к серверам маркировки.ПолучитьРезультатыЗапросаКМ (GetProcessingKMResult) — ожидание и получение ответа от ОИСМ.ПодтвердитьКМ (ConfirmKM) — завершение проверки и фиксация результата в ФН.Выясним главную причину сбоя на второй марке: если сессия по первой марке не была корректно закрыта командой ПодтвердитьКМ или ОтменитьКМ, ФН блокирует начало новой проверки, выдавая ошибку D3h.
В типовых конфигурациях 1С (например, «Розница 3.0» или «УНФ») проверка марки часто реализована через асинхронные вызовы и ПодключитьОбработчикОжидания. Разберем ситуацию: если кассир сканирует товары слишком быстро или если в системе запущено несколько параллельных процессов проверки, контекст выполнения может «перетереться».
Посмотрим на пример логики, которая может приводить к ошибке:
// Неправильный подход: запуск проверки без контроля завершения предыдущей
&НаКлиенте
Процедура ПослеСканирования(КодМаркировки)
ПараметрыПроверки = СформироватьЗапросКМ(КодМаркировки);
// Ошибка может возникнуть здесь, если предыдущий вызов еще не отработал ConfirmKM
Результат = ОбъектДрайвера.ЗапросКМ(ПараметрыПодключения.ИДУстройства, ПараметрыПроверки);
КонецПроцедуры
Чтобы решить эту проблему, необходимо сделать вызовы методов проверки строго последовательными. Если вы используете доработанную логику, убедитесь, что метод ПолучитьРезультатыЗапросаКМ дожидается ответа, прежде чем начнется обработка следующей позиции в чеке. В некоторых случаях помогает отказ от асинхронности в пользу синхронного ожидания ответа от драйвера с небольшим таймаутом.
Проанализируем аппаратную часть. Для ККТ производства «Штрих-М» ошибка D3h официально признана багом в ряде прошивок (например, в версиях конца 2023 — начала 2024 года). Проблема заключается в том, что ФН-М «подвисает» при попытке разобрать структуру кода, если запрос к ОИСМ завершился с сетевой ошибкой или таймаутом.
Рекомендации для исправления:
Выясним, как передается код маркировки. Для ФН критически важно наличие разделителя GS (ASCII 29) перед криптохвостом. Если сканер настроен в режиме «Keyboard Wedge» (эмуляция клавиатуры), он может «проглатывать» невидимые символы. В результате 1С получает «битый» код, который ФН не может распарсить. Для диагностики проблемы полезно выполнить сохранение полных кодов маркировки с криптохвостом в текстовый файл и проверить их структуру.
Проанализируем код, передаваемый в драйвер. 1С требует кодирования марки в Base64. Посмотрим, как должен выглядеть правильный фрагмент передачи данных:
// Пример формирования XML для компоненты 1С
// MarkingCode должен содержать марку со всеми спецсимволами, закодированную в Base64
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.УстановитьСтроку();
ЗаписьXML.ЗаписатьОбъявлениеXML();
ЗаписьXML.ЗаписатьНачалоЭлемента("RequestKM");
ЗаписьXML.ЗаписатьАтрибут("MarkingCode", Base64Строка(ДвоичныеДанныеМарки));
ЗаписьXML.ЗаписатьАтрибут("PlannedStatus", "1"); // Выбытие
ЗаписьXML.ЗаписатьКонецЭлемента();
XMLЗапроса = ЗаписьXML.Закрыть();
Важный совет: Переведите все сканеры в режим Native vCOM (USB-COM). Только в этом случае спецсимволы гарантированно будут переданы в 1С в исходном виде.
Если ошибка возникает «иногда», проанализируем стабильность интернет-канала. Когда ККТ отправляет запрос на проверку в «Честный Знак», она ждет ответ определенное время. Если ответ не пришел, сессия в ФН остается в «подвешенном» состоянии. Также важно исключить другие факторы сбоев обмена, например, настроить автоматическое обновление токенов Честного Знака в 1С, чтобы минимизировать риски остановки процессов на стороне учетной системы.
Для ККТ АТОЛ рекомендуется проверить настройки через «Тест драйвера»:
Если вы столкнулись с ошибкой D3h на второй позиции чека, выполните следующие шаги:
ОчиститьОчередьКодовМаркировки. Попробуйте вызвать его программно перед началом оформления чека.GS (код 29). Это легко проверить в отладке или через блокнот (символ отображается как «пустое место» или спецзнак, в зависимости от настроек).Соблюдение этих технических регламентов позволит стабилизировать работу с маркировкой — для безошибочного пробития чеков есть готовый инструмент подключения онлайн-касс АТОЛ, ШТРИХ-М и Viki с ФФД 1.2. Если же проблема сохраняется и не пробивается марка на кассе, рекомендуется проанализировать логи драйвера и отчеты о сканировании в документах.