Реализация товара с маркировкой

Смысла нет, т.к. в ККТ отправляется значение КМ из регистра, записанное ранее при оприходовании (во время сверки КМ), а не считанное сканером во время продажи.

Хочу заметить, что после очистки регистра "Коды маркировки", КМ корректно считываются и проходят проверку средствами ККТ даже при работе сканера ШК в режиме клавиатуры. В итоге вернул сканер в режим клавиатуры, т.к. имеющийся АТОЛ SB2109 BT плохо работает в режиме эмуляции COM-порта. Полагаю, была проблема в релизе 6.0.37.13, когда КМ некорректно записались регистр, ну а после я столкнулся с последствиями этого даже после обновления на актуальный релиз.

Но осталась другая проблема с проверкой КМ на ККТ - иногда появляется сообщение: "Проверка КП КМ не выполнена, статус товара ОИСМ не проверен" и далее уже "При выполнении операции произошла ошибка: Процедура проверки КМ уже запущена" - эта ошибка возникает при последующих проверках, пока не очистишь буфер КМ на ККТ, но не всегда помогает.
В логах драйвера при этом появляются ошибки:
Объекту 0x0F3D7410 присвоен код ошибки 410 [Неверное состояние процесса проверки КМ]
Объекту 0x0F3D7410 присвоен код ошибки 401 [Процедура проверки КМ уже запущена]

Может быть есть способы борьбы с этим?

В этом случае проблема не в сканере ШК, т.к. КМ считывается 1 раз, и после нескольких попыток пробить чек (с очисткой буфера на ККТ между попытками), КМ проходят валидацию и чек все-таки пробивается.

Артем, добрый день, ответ сможем дать после анализа лога фискального регистратора.

Добрый день.

У нас такое тоже иногда бывает. Проблема может уйти через какое-то время. А если не уходит - отключаем питание у ФР и включаем обратно. И чек с маркировкой успешно пробивается

Светлана Сулименко, перед отправкой решил заглянуть в лог ККТ и обнаружил, что наряду с корректными КМ, стали попадаться также КМ, в которых вместо разделителя GS опять содержится комбинация "\x1d". Стал разбираться и выяснил, что некорректные КМ записываются в регистр "Коды маркировки" при выполнении сопоставления КМ из документа "Поступление товаров". При сканировании марки в документах "Реализация товаров" и "Чек на оплату" КМ в регистр записывается корректный с разделителями GS, но при условии, что в регистре КМ с таким серийным номером отсутствует.

Другой момент: если при сопоставлении КМ в поступлении товаров вручную ввести марку без криптохвоста, то сопоставление в документе произойдет без ошибок, но в регистре запись зафиксируется в обрезанном виде и такую марку будет невозможно реализовать посредством ККТ, несмотря на то, что в реализации товаров или чеке на оплату будет считан полный КМ сканером ШК перед пробитием чека. Единственный пока вариант - вручную удалить некорректную запись из регистра, после чего считать марку сканером ШК в документе реализация товаров или чек на оплату, чтобы в регистр попала корректная запись.

Очевидно, что проблема с появление комбинации "\x1d" в регистре "Коды маркировки" это не проблема сканера, а ошибка в алгоритме в процессе парсинга и разложения КМ при сопоставлении КМ в документе "Поступление товаров", т.к. на том же оборудовании в документах "Реализация товаров" и "Чек на оплату" такой проблемы не наблюдается. Да и сама комбинация "\x1d" передается не сканером, а используется в конфигурации в процессе обработки КМ:

Скрытый текст
// Функция возвращает разделитель GS1. // Функция РазделительGS1() Экспорт; Возврат Символ(29); // Dec 29 КонецФункции // Функция возвращает экранированный символ GS1. // Функция ЭкранированныйСимволGS1() Экспорт; Возврат "\x1d"; // Используется для экранирования символа GS1. КонецФункции

Пока разработчики не исправят данную ошибку, вижу такое решение: не сопоставлять КМ в документе "Поступление товаров".

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

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

Артем, рекомендуем использовать наш драйвер Драйвер ККТ АТОЛ ДТО10 для 1С:БПО 3.X NativeAP. Более подробный ответ предоставлен Вам по почте.

Светлана Сулименко, с этим драйвером не могу пробить чек, появляется ошибка:

При выполнении операции произошла ошибка:"ККТ не зарегистрирована с указанной системой налогообложения.".

Пришлось вернуться на стандартный драйвер. ККТ фискализирован с СНО УСН доход минус расход, в учетной политике организации выставлено также.

Артем, с драйвером никакой ошибки нет. Перед началом работы с другим драйвером ФР Вы делали закрытие кассовой смены на фискальном регистраторе, затем открытие новое?

Светлана Сулименко, нет, заменил оборудование в документе "Кассовая смена". Сейчас сделал закрытие смены на стандартном драйвере и открыл уже под новым - больше на СНО не ругается. Спасибо. Будем наблюдать, но на первый взгляд работает стабильнее и пока не было ошибок при валидации КМ на ККТ при использовании драйвера от РАРУС.

Остался открытым вопрос по некорректной записи КМ в регистр "Коды маркировки" при сканировании сканером ШК в процессе сверки КМ из документа "Поступление товаров".

уточните, как запрограммирован сканер при таком сканировании?

Светлана, сканер сейчас работает в режиме клавиатуры, я понимаю, что это как как красная тряпка, но это не имеет значения, т.к. в документах "Реализация товаров" и "Чек на оплату" при считывании КМ тем же сканером и при тех же настройках в регистре "Коды маркировки" записывается корректная запись, т.е. мы получаем разный результат записи в регистр при сканировании в поступлении товаров и в реализации товаров. Причем эта же модель сканера без каких-либо проблем работает с кодами маркировки шин в режиме клавиатуры в других конфигурациях 1С, например в УНФ.

Сейчас я вышел из ситуации, запретив пользователям производить сверку КМ в документе "Поступление товаров" и проблема исчезла. Но не хотелось бы лишаться возможности производить сверку КМ пришедших по ЭДО и фактически нанесенных на товар в момент оприходования.

Артем, для корректной сверки кодов маркировки сканер не должен быть клавиатурным.

Светлана, я снова подключил сканер в режиме COM-порта, но ничего не поменялось. А все потому, что в модуле формы обработки "Сопоставление кодов маркировки" при обработке события "ScanData" вызывается процедура ШтрихкодированиеКлиент.ЗаменитьНаЭкранированныйСимвол(ШтрихКод), которая вместо GS кода добавляет комбинацию "\x1d". И уже преобразованная строка конвертируется в Base64 и записывается в регистр. Как мне кажется, для хранения преобразованного штрихкода с "экраном GS" для последующей обработки и штрихкода, который будет записан в регистр лучше использовать разные переменные.

При этом в документах "Реализация товаров" и "Чек на оплату" считанный штрихкод не подвергается экранированию символа GS до конвертации в Base64 и записи в регистр (при условии, что КМ отсутствует в регистре, иначе запись не обновится). Правда в этих документах тоже не всё идеально, т.к. за каждое считывание сканером ШК попытка записи в регистр происходит дважды. При этом, если в первый раз ШК отправляется полный, то во второй раз в регистр зачем-то производится попытка записи укороченного ШК (без криптохвоста), которого вообще не должно быть в регистре. Но т.к. перед записью в регистр производится проверка на наличие уже имеющейся записи, то повторные попытки записи игнорируются и в итоге в регистре имеем корректный КМ, при условии, что мы его не считывали сканером ШК ранее.

Артем, добрый день, вопрос требует разбирательства, ответ будет дан позже.

Светлана, спасибо!

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

Доброе утро.

Когда ошибка будет исправлена в Альфа-Авто 6.1?

У нас сканер в режиме COM-порта (как рекомендовали в техподдержке через email), документы по шинам приходят в электронном УПД через 1С-ЭДО, в документе "Поступление товаров" делается "сопоставление кодов маркировки". Далее в документе "Реализация товаров" через сканер в режиме COM-порта сканируются коды маркировки, проверяется статус по данным "Честного знака". Далее кассир пробивает кассовый чек документом "Чек на оплату" - в этот момент коды маркировки получают отрицательный результат проверки.

Уже надоедает постоянно удалять коды из регистра при отрицательных результатах проверки у кассиров.

Данил Василига, ошибка исправлена в будущем релизе 6,1,03.

Можно получить исправление в виде расширения? Когда ждать выхода релиза 6.1.03?

Данил Василига, по данному исправлению не получится сделать расширение, лучше дождаться исправления в релизе, релиз 6,1,03 ожидается в середине февраля 2023

Светлана Сулименко, а в релизе 6.0 будет это исправление?

Артем Лабузный, да. в будущем релизе 6,0 исправление также будет

Добрый день! Подскажите, пжл, у меня после ввода кодов маркировки в документ поступления товаров и его проведения в регистре КодыМаркировки не появляется записи. Каким образом в этот регистр попадают коды?

Какой у Вас Релиз АА?
КМ сканируете сканером в режиме виртуальный сом-порт?