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

Тогда вам надо читать вот это [ ➜ ]

По поводу смены ОФД, это первое что в голову пришло, но "другая" кассовая прога, которую я упоминал (в другом подразделении одного клиента), работает мгновенно на том же ОФД, хотя там трафик пониже, но вообще ноль задержек - это нечто!

Мне пришла мысль не ждать ответа, я поделился идеей с главным айтишником, и выяснилось, что они в другой "проге" тоже не ждут ответа, шлют следующую команду, и все ОК. И в личном кабинете все чеки - ОК...

И я не вижу здесь никаких нарушений, поделился мыслями со всеми....

Спасибо, я знаком...

Вообще проверка маркировки была изначально заложена в протокол ФР (у Штрих, по крайней мере).

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

Перешел на ОИСМ через curl.

Но и эти 5 и 3 ни о чем не говорят...

По факту у меня задержки на каждой позиции (по всем командам) от 0.5 до 2 сек может плавать, но когда маркированного много, касса может на целую минуту "подвиснуть", пока начнет печатать чек...

Вы не путаете проверку ККТ с проверкой в разрешительной системе?
У меня все чеки закрываются быстро всегда.
Разрешительный режим я задействую в момент сканирования товара.
А добавление позиций в чек с проверкой в ОФД я делаю после полного сканирования покупки.
Сигареты и молочка - все реализовано и никаких задержек нет.

И функция "Отложить насканированную покупку чтобы обслужить следующего по очереди а потом вернуться к отложенной покупке" тоже реализована, просканированные товары уже прошли разрешительный режим, маркировки запомнены и откладываются вместе с покупкой, никаких проблем.
20 касс и прочих рабочих мест в единой базе в реальном времени тоже поддерживает моя программа.

Я не путаю, у меня все как у вас, список команд по каждой позиции приводил в начале...
Возможно, ваш ОФД лучше работает, чем наш...

"А добавление позиций в чек с проверкой в ОФД я делаю после полного сканирования покупки"-
вы же дожидаетесь ответа от ФР (на корректное завершение команды) по каждой отправляемой команде,
а их несколько на одну позицию или нет?

Я дожидаюсь... И у меня есть серьезные задержки (на крупном клиенте).

Но мне нужно решить проблему без смены ОФД, поэтому и буду пробовать,
не ждать ответа от Штрих-ФР, слать следующую команду,
но "переварит" ли Штрих такой режим, пока не знаю...

По итогу отпишусь...

Блин.... Каша какая-то...

Еще раз - проверок при продаже чеков - 2 вида, одна, по разрешительному режиму, на сайте ЦРПТ(как Вы пишете - через curl), и вторая - это к РР не имеет никакого отношения, проверка на сервере ОИСМ через ОФД... Она была с самого начала, как только ФФД-1.2 появился. Именно по ее результатам печатается на чеке "M", "M+", "M-". Да, она делается через ОФД и время на нее, зависит от скорости обмена с ним и скорости его работы.
Не надо сваливать в одну кучу все команды продажи маркировки! Там тоже есть и проверка отдельно, и отправка уведомления о реализации. И можно это тоже разнести по времени. Проверку можно делать вместе с проверкой по РР, сразу следом за ней, при добавлении в чек, а уведомление о реализации делать при закрытии чека. Тогда тормозов при пробитии чека не будет. А проверки при добавлении в чек,будут, как Вы говорите "размазанными" и незаметными.

Я тоже в чек позиции добавляю после полного сканирования.
Ответ обязательно дожидаюсь.
Я Штрихи не использую (моя программа их поддерживает но они мне не нравятся, все поменял на АТОЛы). Возможно проблема в самом железе Штрих.
Возможно тормозит не ККТ а учетная программа при доступе к своей базе данных? Не думали?
Какой у Вас ОФД. У меня Первый ОФД, самый удобный, с ним никогда не было проблем. С Эвотор ОФД я просто замучался и много лет назад от него отказался.

Я считаю это опасным и ненадежным. Чек я открываю на короткое время при его пробитии в самом конце. Открыть на несколько минут чек это рисковать что питание отрубится и чек останется открытым. Лишние хлопоты. А во-вторых, моя программа позволяет подключить один ККТ на два рабочих места кассира стоящих рядом, один ККТ чеки пробивает и с одной и со второй кассы. Если чек открыть в начале сканирования, вторая касса не сможет на этом ККТ пробить чек, ККТ быдет занята с первой кассы. А клиентов которые один ККТ ставят на два рабочих места касссира у меня полно. Экономия.

И вот это - поясните, что это такое вообще? при чем тут ОИСМ и curl - ?
Как они связаны?
Проверку по ОИСМ делает сам ККТ, своими средствами, или внутренним сетевым интерфейсом(если сеть "на борту"), или средствами драйвера(тут у разных ККТ их целый "зоопарк", в зависимости от производителя - например, для того-же АТОЛа, это EoU или EoT)...
В какое тут место curl засунуть можно, я как-то и не представляю...
Другое дело проверка по РР, она делается средствами кассовой программы и тут куча средств запросов к HTTPS, в том числе и тот-же curl