При переходе на формат фискальных данных ФФД 1.2 и начале работы с маркированными товарами (шины, одежда, парфюмерия, молочная продукция или антисептики) многие разработчики и системные администраторы сталкиваются с ошибкой D3h. Полный текст ошибки обычно звучит так: «Ошибка привязки КМ: Код товара не распознан». Эта проблема специфична для кассового оборудования Штрих-М и возникает непосредственно в момент попытки пробития чека — для этого подойдёт универсальная обработка подключения ККТ Штрих-М с ФФД 1.2.
В этой статье мы подробно разберем природу данной ошибки, выясним, почему она возникает на этапе фискализации, и рассмотрим программные способы ее решения в конфигурациях 1С — поможет обработка для корректной печати чеков с маркировкой и ФФД 1.2.
Для начала проанализируем логику работы ФФД 1.2. В отличие от старых форматов, здесь процесс продажи маркированного товара разделен на два ключевых этапа:
AddPosition) касса должна сопоставить передаваемый код с тем, который был проверен ранее.Ошибка D3h означает, что на втором этапе касса не смогла найти в своем внутреннем буфере код, идентичный тому, что передает программа 1С. Даже если разница составляет один невидимый символ или неверно указан формат разделителей, ККТ вернет ошибку привязки.
Самая частая причина — это отсутствие или неправильное расположение символов GS (Group Separator, ASCII 29) в строке кода маркировки. Кассы Штрих-М крайне чувствительны к структуре кода. В спецификации GS1 символы-разделители должны стоять перед идентификаторами применения (AI), такими как (91), (92) и другими, если предыдущее поле имеет переменную длину.
Рассмотрим ситуацию: при сканировании марки сканер может передавать данные в одном виде, а при формировании XML-пакета для драйвера (через БПО) 1С может «проглатывать» спецсимволы. В результате в кассу улетает «плоская» строка, которую ФН-М не может сопоставить с ранее проверенным кодом.
Разберем пример функции, которая помогает правильно подготовить строку кода маркировки для передачи в драйвер. Этот код базируется на логике БСП и БПО, адаптированной под требования Штрих-М:
Функция ПодготовитьКодМаркировкиДляШтрихМ(КодМаркировки) Экспорт
// Используем стандартные средства БПО для разбора структуры GS1
СтруктураШК = МенеджерОборудованияМаркировкаКлиентСервер.РазобратьСтрокуШтрихкодаGS1(КодМаркировки);
КодКонтрольнойМаркиСтрока = "";
Если СтруктураШК.Разобран Тогда
Для Каждого ДанныеШК Из СтруктураШК.ДанныеШтрихкода Цикл
// Нам нужно собрать строку заново, явно вставляя разделители
// Символ \u001d — это стандартное обозначение GS для XML/JSON
КодКонтрольнойМаркиСтрока = КодКонтрольнойМаркиСтрока + ДанныеШК.Ключ + ДанныеШК.Значение.Значение + "\u001d";
КонецЦикла;
// Важный нюанс: перед блоком 21 символ GS часто оказывается лишним или, наоборот,
// его нужно жестко контролировать в зависимости от версии прошивки.
// Убираем лишний разделитель в конце или специфические блоки
КодКонтрольнойМаркиСтрока = СокрЛП(КодКонтрольнойМаркиСтрока);
// Заменяем текстовое представление на реальный разделитель драйвера
Разделитель = МенеджерОборудованияМаркировкаКлиентСервер.РазделительGS1();
Результат = СтрЗаменить(КодКонтрольнойМаркиСтрока, "\u001d", Разделитель);
Возврат Результат;
КонецЕсли;
Возврат КодМаркировки;
КонецФункции
Обратите внимание: опытным путем выяснено, что перед блоком идентификатора 21 символ GS (ASCII 29) иногда требуется удалять, если он дублируется, или, напротив, следить за его наличием перед блоками 91 и 92. Рекомендуется связаться с техподдержкой «Честного Знака» для получения актуального лога проверки вашего конкретного типа товара.
Проанализируем ситуацию, упомянутую пользователями Розницы 2.3. Ошибка D3h часто возникает при продаже разливного пива, если объем составляет дробное число (например, 6.5 литра), при этом на целых числах (1 литр) все работает корректно.
Это связано с тегом 2108 (единица измерения). В ФФД 1.2 при частичном выбытии маркированного товара (когда одна марка кеги используется для множества чеков) необходимо передавать в кассу информацию о том, что это именно розлив. Если 1С передает данные некорректно или драйвер неверно интерпретирует вес/объем, привязка КМ сбрасывается.
Для решения этой проблемы проверим следующие настройки в 1С:
В кассах Штрих-М существует таблица настроек №17 (Региональные настройки). Поле 41 этой таблицы называется «Rus принимать все КТ».
Если установить значение этого поля в 1, касса перестанет выдавать ошибку D3h и позволит пробить чек. Однако это «костыльное» решение. В этом случае на чеке будет печататься признак [М-], что означает: «код не прошел проверку». Такой товар считается проданным с нарушениями, данные в «Честный Знак» могут уйти некорректно, что потенциально ведет к штрафам.
Рассмотрим правильный подход к настройке через «Тест драйвера»:
Если вы столкнулись с этой ошибкой, пройдите по шагам:
RequestKM и какие в AddPosition. Они должны быть идентичны символ в символ (включая невидимые разделители).Base64, убедитесь, что при кодировании не теряется управляющий символ GS.Подводя итог, можно сказать, что ошибка D3h — это чаще всего ошибка форматирования строки MarkingCode в XML-пакете, который 1С отправляет на кассу. Тщательная проверка символов-разделителей GS1 и использование актуальных релизов БПО позволяют полностью устранить эту проблему.