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

Точно, вспомнил, это называется консольный интерфейс. Ладно, не буду больше стебаться.

Да, есть такая команда:
Этот вариант я пробовал еще в апреле (сигареты и пиво разливное),
на Штрих эта команда отрабатывала, но не всегда корректно,
на некоторых нормальных сигаретах возвращался отрицательный ответ (не 15)...

Перешел на запрос через curl в Честный знак (специально так пишу, если кому-то не нравится ОИСМ),
работает быстро и корректно...

Да, есть такое, это проверка по "разрешительному режиму", как Вы называете "через курл"...
Только на нее нельзя "перейти", это дополнение к первой, имевшейся ранее, до ввода разрешительного режима проверки самим ККТ в ОИСМ...
Проверка по РР не отменяет необходимость проверок ОИСМ, а дополняет их...
Вот так, была раньше одна - ОИСМ, а теперь две: РР + ОИСМ...

И тегов в чеке с результатами проверок два - 1060, с результатами проверки по РР, составной, как Вы говорите "четыре реквизита", и 2106, результат проверки в ОИСМ - там одно число, 15, если все нормально, 0, если проверка не состоялась(например связи нет), 5 если что-то не то, и т.д....
Это разные проверки, и одна другую не заменяет, должны быть ОБЕ!

Если у вас все работает, и сделано правильно, то я только рад!!!

Только проясню, что я имел ввиду, когда писал, что проверка некорректно работала на части сигарет в апреле, на примере команд для Штриха. Может кому-то пригодится...

В апреле, после каждого сканирования маркировки, пробовал запускать команду:
"Проверка маркированного товара". Код команды FF61h. Корректный ответ = 15.

Ответ был некорректным на части "нормальных" сигарет...

Отказался от этой команды совсем... Перешел на "РР" (curl).

При оформлении команд продажи, выполняю в т.ч., команду
"Привязка маркированного товара к позиции". Код команды FF67h.
Там в примечаниях написано:
"В случае если код маркировки не проверялся ранее командой FF61h «Проверка
маркированного товара», ККТ сама еѐ подаст и добывит ответ на неѐ к ответу на команду
FF67h."

И да, здесь, корректный ответ, тоже вроде =15, но я даже не разбирался,
т.к. вообще не анализирую ответ, ибо маркировка уже проверена "РР" (curl),
а некорректный ответ может быть по вполне объективным причинам,
и пусть там сам фискал разбирается, посылает дублирующие запросы в ОФД и т.д.,
меня это уже не волнует, мне нужно чек закрыть и отпустить покупателя побыстрей...

И да, именно на этой команде FF67 (возможно и на другой (4 тэга)) у меня и происходит задержка.
И именно по этим командам я и пробую убрать ожидание ответа от ФР совсем!
Какой уж тут анализ ответа...

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

Остальные клиенты вообще не жалуются,
т.к. у них только сигареты, и у некоторых пиво разливное.

И да, я считаю это правильным и очень надеюсь, что разработчики ПО для ФР, сами бы озаботились этой проблемой, и на эту команду (у Штриха "Привязка маркированного товара к позиции". Код команды FF67h.)

- сами бы слали мгновенно положительный ответ, ибо у всех "нормальных" и так есть "РР" на первичном сканировании, а потом бы сами разбирались с этими командами с ОФД (задержками интернета, перегруз трафика у ОФД и т.д.)...

И да, на это же "намекает" и разрешение не печатать на чеке M, М+, М-.

Ибо всем очевидно, что есть задержки, и эта информация может быть не актуальна в момент печати чека, т.к. обмен с ОФД просто еще не завершился...

Ну и вообще, с учетом, что у всех проходит предварительно "РР" (curl),
там по сути всегда М+ должен быть...

У моих клиентов не выводится по умолчанию...

Нет такого разрешения.

Тоже первый раз о таком слышу... Дайте ссылку, если такое где-то было опубликовано.

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