При печати чека на ККМ при проверке в честном знаке касса возвращает ошибку "D3h. Код товара не распознан".
Причем если марка на которую возвращается ошибка первая, то ошибки нет. Ошибка только когда марка не первая.
В чем может быть дело?

(0) xml чека при ошибке нужно посмотреть. скидка в чеке есть?

xml проверки:
<?xml version="1.0" encoding="UTF-8"?>
<RequestKM GUID="bd965267-621d-4728-9738-60f3d60ea2ab" WaitForResult="True" NotSendToServer="False" MarkingCode="MDEwNDYyMDIzMDExMDAyNTIxNXBQPTUuTUNGaDFtUh05MzgyQXc=" PlannedStatus="1"/>

xml ответа:
<?xml version="1.0"?>
<ProcessingKMResult GUID="bd965267-621d-4728-9738-60f3d60ea2ab" Result="true" ResultCode="15" StatusInfo="1" HandleCode="0"/>

Ошибку возвращает код:
Результат = ОбъектДрайвера.ПодтвердитьКМ(ПараметрыПодключения.ИДУстройства, ИдентификаторЗапроса, ?(Выбытие, 0, 1) );

ИдентификаторЗапроса равен bd965267-621d-4728-9738-60f3d60ea2ab

Описание ошибки:
D3h, Код товара не распознан

А вот это что такое вообще: MDEwNDYyMDIzMDExMDAyNTIxNXBQPTUuTUNGaDFtUh05MzgyQXc

Это не код марки. По структуре видно. Сюда, должен передаваться код марки "как есть", как со сканера прилетает.
Или сканируют "что-то не то", или сканер так настроен - возможно, это фрагмент кода марки из нее "вырезан".
Приложите фотку марки, которая в этом чеке была, посмотрим что это такое, как ее нормальный сканер прочитает.

(1) В данном случае, скидка тут вообще ни при чем. Тут явно "кривой" код марки.

PS И ТС как большинство, путает, где ошибка возникла - в РР или кассе, при проверке через ОИСМ. Тот идентификатор запроса - это ЧЗ возвращает, при проверке по РР. Там скорее всего отрицательный результат (будет в нем так-же, что марка не найдена, если конечно, там такой-же код на проверку по РР передавался, а не полный, как со сканера прилетел, и позже он был "изуродован" где-то в недрах программы), но запрос отрабатывает, раз его ИД вернулся. А вот то, что касса ошибку выдает - это следствие попытки проверить "кривую марку" средствами ККТ в ОИСМ, ККТ не может распознать, что ему подсунули, и падает в ошибку...

+(3) Разбинарь строку

(4) Ну, да, возможно и в этом причина. Марка должна передаваться "как есть", а тут, очень похоже, что ее в base64 закодировали. В этом месте не нужно этого делать.

+(4) и (5) - Вот такая марка там: 0104620230110025215pP=5.MCFh1mR9382Aw
Абсолютно нормальная:





Где-то Вы перестарались, лишнее преобразование в Base64 делаете.

Это - "НАПИТОК ГАЗИРОВАННЫЙ COCA-COLA CLASSIC В СТЕКЛЯННОЙ БУТЫЛКЕ 0.33 "
(последнее - не из ЧЗ, а из базы ОлегОН по ЕАН, выделенному из кода марки. Можно получить наименование и из ЧЗ по GTIN, другим запросом, но лень... :-) )

Ну, хотя... Чего лень - нужно было то, всего залезть под стол и токен поменять, там другой стоял. Первый запрос по РР, для него не нужен "физический" токен-ключ, там токен из ЛК ЧЗ.
А вот этот запрос уже по API из ЧЗ:





Это как карточка продукта в ЧЗ заведена производителем.
К этим запросам доступ только по ЭЦП...

Хорошо "сунулся", заметил у себя косяк...
Вот это надо "починить":



У меня там функция "перевода месаг ЧЗ на человеко-читаемый язык". Добавить туда эти значения.

Блин, и внизу еще одно: "tnVedEaesGroup"...
Просто, когда делал, соковой продукции еще не было и такое не попадалось.

Вот так правильно:

(3) Конфа Ут11.5 код стандартный.
Если бы проблема была в коде марки тогда бы все было легко.

Проблема в том, что иногда проверка этой марки (0104620230110025215pP=5.MCFh1mR) проходит, а иногда нет.
Точнее если позиция первая - проходит, когда пятая нет.

Такое ощущение, что дело в ККМ.

Попробовал в запрос подсунуть код марки незашифрованный (0104620230110025215pP=5.MCFh1mR):
<?xml version="1.0" encoding="UTF-8"?>
<RequestKM GUID="66d47fce-2076-4924-88b9-44da8357c728" WaitForResult="True" NotSendToServer="False" MarkingCode="0104620230110025215pP=5.MCFh1mR" PlannedStatus="1"/>

Выдает ошибку: D3h, Код товара не распознан.

Все правильно у 1с сделано, код правильный передает.

(11) Так ты наверно символ который невидимы не передал.
ASCII 232 (FNC1) и ASCII 29 (GS)

(5) Все там правильно передается. Это требования компоненты от 1С. https://its.1c.ru/db/metod8dev#content:4829:hdoc:requestkm

(10) так что насчет скидки? У меня такое было когда скидка, и форматно логический контроль, чтобы привести ценасоскидкой*количество = суммапостроке (допускается отклонение не более 1 копейки), делил строку на две, соответственно на ККТ отправлялись 2 одинаковые марки на проверку в рамках одной сессии(чека).

Скидок нет.
До скидок и не доходит, ошибка на этапе проверки КМ. (14)

(13) А, ну, получается да:
"MarkingCode    Да    string    Код контрольной марки
Кодируется текстом в кодировке Base64."
Это извращение в драйвере (компоненте) по технологии 1С-совместимо...
В нативных драйверах передается строкой "как есть".
Тогда, х.з...
Может драйвер обновить надо?
Кстати, а что за ККТ -? На уровне драйвера 1С, не понять - они все едины со стороны 1С...  

Вот это: <RequestKM GUID="66d47fce-2076-4924-88b9-44da8357c728"
Похоже, ИД запроса по РР... Кстати, а что он возвращает? Не его ИД, а результат, если его в отладчике поймать?
Ну, хотя, в первом сообщении - "ResultCode="15"" Это похоже на ответ ОИСМ, что с маркой все ОК... Трудно понять без контекста.

(16) тут речь про проверку средствами ККТ-ОФД-ОИСМ. РР здесь совсем нет. <RequestKM GUID="66d47fce-2076-4924-88b9-44da8357c728" - https://its.1c.ru/db/metod8dev#content:4829:hdoc:chapter270
через компоненту 1С, проверка делается 3-мя методами последовательно: ЗапросКМ(RequestKM), ПолучитьРезультатыЗапросаКМ(GetProcessingKMResult), ПодтвердитьКМ (ConfirmKM).

(16) Результат = ОбъектДрайвера.ПодтвердитьКМ(ПараметрыПодключения.ИДУстройства, ИдентификаторЗапроса, ?(Выбытие, 0, 1) );

В результате ошибка. Отладкой не посмотреть это процедура драйвера - внешней компоненты.

(17) через компоненту 1С

Тогда все, я молчу...
Я сам делал только через нативные драйвера, без компоненты 1С. Для Штрихов, АТОЛов, Спарка-130. А там все немного не так.
А через компоненту в паре мест у меня работают типовые "Розницы", лазить туда не приходилось, оно и так заработало, "из коробки" :-) .

С телеги "Злой ЦТОшник":

Виктор, [30.01.2025 15:18]
Всем привет. Есть атол 11 и ПО Мой склад. Прошивка на Атоле самая последняя. Проблема такая, при сканировании маркированного товара, проверка в ЧЗ и ККТ проходит отлично, но если отсканировать быстро 2 или 3 маркий, первая проходит проверку в ККТ, остальные выходят с ошибкой. Но в ЧЗ все так же все хорошо и проверено. Может кто сталкивался?

Виктор, [30.01.2025 15:18]
Тайминги уже пробовал менять, не помогает

Виктор, [30.01.2025 15:19]
Хотя может есть какие то волшебные

Alfa Dog, [30.01.2025 15:20]
Не сканировать быстро :)

Виктор, [30.01.2025 15:21]
Ну быстро, тоже относительно, разница во времени должна быть сек 10-20

Не ваша ситуация, часом?

(20) Тоже такое подозрение возникло. Но почему на одном и том же коде?
Написали в штрих, посмотрим что ответят.

(20) (21) Похожее поведение было у меня на Розница 3. При сканировании нескольких марок первая нормально проверялась, какая то из последующих выдавала ошибку. Дело было в том, что в типовой Рознице (в остальных типовых так же) проверка осуществлялась описаниями оповещения и обработчиком ожидания. Выше я уже писал, что проверка состоит из 3-х методов и если подтверждение предыдущей марки не успело завершиться и отсканировали новую, то новая могла перетереть контекст операции предыдущей марки. Причем в отладке это поймать не удавалось, так как время в отладчике позволяло успешно провериться маркам. После того как сделал вызов ПолучитьРезультатыЗапросаКМ() последовательным, а не через ПодключитьОбработчикОжидания() проблема ушла.

(22) А нельзя было марки перед пробитием проверять все скопом? А не при сканировании?

(23) можно, то же самое происходило

(23) В моей ситуации нельзя. Проверка идет средствами ККТ, там проверка по одной.
(21) Мож кто знает как увеличить таймаут проверки кодов на кассовом аппарате?

(25) В атоле вот такое есть. Но у нас редкие продажи маркированного товара
https://atol-kassa.ru/kkt-atol-nastrojka-parametrov-raboty-s-ism-informaczionnaya-sistema-markirovki/

(25) так перед пробитием тоже по одной проверяется и из за асинхронности иногда эти проверки пересекаются. Даже еще с большей вероятностью, так как при сканировании есть хоть какая то пауза.

(26) Спасибо!
Такое описание бы для штриха. Если что драйвер 5.18.0.1068

В штрихе сказали что вот эта проблема:
https://teletype.in/@shtrih-support/fnbug