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

Практически у всех ККТ есть метод сохранения результата проверки ОИСМ для последующего закрытия чека. И хранятся эти результаты в ФН, до того момена, как чек закроется и уведомление отправится, с их удалением из ФН. Ну, или его не станут закрывать, отменят. Тогда подается специальная команда, которая очищает эти результаты проверки в ФН. От "капризов питания", сохранность результатов проверки не зависит.

А моя программа позволяет подключить одну ККТ к неограниченному количеству РМК, организуя очередь пробития чеков с разных РМК на одну ККТ ;)

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

А, ну тут - да. Проверять и сохранять результаты проверки можно только при открытом чеке.
Ну, тут уж - "кто во что горазд" Если несколько экземпляров кассовой программы работают с одним ККТ, то конечно такая схема работы не пройдет.

Вот тут и будет ситуация как у ТС - при закрытии заранее сформированного чека, могут быть тормоза из-за проверок ОИСМ... В конце, всей кучей.
Хотя, вариант "отрицательного результата" проверки ОИСМ - минимален, так, как при добавлении в формируемый чек скорее всего была успешная проверка по РР, соответственно и по ОИСМ должна пройти... Но время... Если там 10 марок, то до 1.5 секунды на марку(если связи нет и ограничено время разрешенным), это разовая(одномоментная) задержка на 15 секунд... Что будет заметно...

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

Здесь, полностью согласен...
Но, там хоть время суммарное и меньше, но оно более заметно, так, как 10 раз по 1.5 секунды, так в глаза покупателю не бросятся, как одна задержка(У вас, ЧО, все висло??? ) в 15 секунд...
Поэтому, тут каждый "сам себе злобный буратино!"

Вывод?
- правильно! -
предусмотреть в ПО - оба режима, и пусть пользователь ПО - сам выбирает наиболее подходящий для него режим..
Рад, что договорились!
;)

Ага... У Олега(student), в УКМWIN так и сделано - параметр настраиваемый...
Хоч так, хоч иначе

Вы не поняли - предлагают открыть чек, при каждом сканировании проверять его не только в РР но и в ИСМ, а потом в конце прорсто закрыть чек. В итоге чек будет открыт на время сканирования товаров (несколько минут). Это и опасно - держать чек ККТ открытым несколько минут. У меня как у Вас до конца сканирования чек в ККТ не открывается.

Я так не считаю. Пока продавец после пикания положит одни товар и возьмет другой, проверка ИСМ за эти полторы-две секунды пройдет не тормозя процесс продажи. А проверка в конце отнимет эти 15 секунд точно.