Задержки при закрытии чека с маркировкой : Маркировка

Проверить - то можно без открытия чека, но после открытия чека перед добавлением позиции в чек придется проверять заново, иначе не даст добавить позицию в чек.

Не придется.

Спасибо, но без разницы, они идут друг за другом...

Вот если бы разработчики ПО ФР (или кто там им законы им пишет) убрали первое (Проверка маркировки в ОИСМ) за ненадобностью, ибо проверка уже прошла (РР) и результат мы им тоже передаем, то это было бы самое простое и мудрое решение...

Правильнее, "не передача чека" (это некорректное высказывание), а "Привязка маркированного товара к позиции".

Повторюсь, уже писал:

В моем случае, одна команда Штрих "FF67" запускает обе команды...

Протокол:

Привязка маркированного товара к позиции
Код команды FF67h
....

Примечания:
....
4
– В случае если код маркировки не проверялся ранее командой FF61h «Проверка
маркированного товара», ККТ сама еѐ подаст и добывит ответ на неѐ к ответу на команду
FF67h.

если это про FNBindMarkingItem то там не 2 а 3 внутри и вводилось (из переписки со штрихом) для тех кто не успевал модифицировать софт под новые требования и что там внутри никто кроме штриха не знает :)
штрих даже в доках пишет что это устаревший метод



и какова вероятность что команда будет удалена в последующих релизах драйвера тоже никто не скажет

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

Итоги сегодняшних тестов:

Да, отказывается Штрих принимать следующую команду, не выдав ответ на предыдущую.
(если что, смотрите, в начале темы)

Что было ожидаемо...

Но меня "слегка" дезинформировали, сказав что у других так работает...

Правда там протокол "RNDIS", у меня по USB, но мне кажется,
что от протокола здесь ничего не зависит, или я ошибаюсь?

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

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

P.S. Я в принципе не вижу других вариантов, как внедрять у себя построчные продажи,
сразу после сканирования, чтобы "размазать" задержки по чеку...
И это уже здесь обсуждалось, хотя я с самого начала видел этот вариант, ибо он очевиден,
но больно много переделок и новых тестов, поэтому искал другие варианты.

P.S.S. Какие есть предположения у сообщества?

P.S.S.S Но, плиз, прошу, только по сути, азбучных истин мне не нужно...

P.S.S.S.S. Напомню еще раз, что проблемы проявились с внедрением молочки и воды у моего клиента, у многих из вас они проявятся после 1 сентября...

Всем спасибо...

Я написал именно про передачу чека в ОФД.
Если есть атолы, то лучше посмотреть организацию процесса в них, там более понятно, как что работает.

Спасибо конечно, но это банально уже всем понятно, что здесь речь не о команде "Закрыть чек".

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

Атолов нет, ориентируюсь на Штрих, ну и не будем "ссориться" по пустякам, есть вопросы посерьезнее...

нет - у нас закрытие всего чека со всеми маркированными и не маркированными товарами сразу при оплате, построчной печати нет, как и задержек при закрытии :)