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

Добрый день всем.

Клиент крупный, в каждом магазине от 5 до 10 касс, около 20 торговых точек.

Раньше были задержки только по сигаретам.
Полмесяца назад внедрили молочку и воду...

Задержки стали колоссальные при закрытии чека, больше минуты иногда ...

У меня все продажи из чека оформляются в конце, при закрытии чека.
Задержки на командах передачи маркировки, и передачи результата проверки маркировки.
В этот момент идет обмен информацией ФР с ОФД, который в свою очередь общается с ЧЗ, по каждой позиции...

По каждой позиции идут задержки с ответом, которые по итогу, при кол-ве маркированного больше 5-10, превращаются в подвисании кассы перед распечаткой чека. Причем проблема "плавающая", обостряется в часы пик...

Если маркированного в чеке нет, закрывается мгновенно, как обычно...

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

1) Пришла идея просто не ждать ответа от ФР по этим командам, связанным с маркировкой...

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

У кого-то есть схожие проблемы?

И как вам эта идея...

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

Что касается проверок - ИМХО правильнее делать их сразу, при сканировании марки(добавления товара в чек)...
Иначе, действительно может долго закрытие чека проходить, когда он при(перед) закрытиием чека начнет всю кучу маркированных товаров проверять, да еще и на двух серверах, ОИСМ и ЦРПТ(разрешительный режим)...
А если интернет отвалится? На каждую позицию будет по два раза запрашивать согласие покупателя приобрести товар без проверки Х на количество марок в чеке...
Покупатель просто психанет, пошлет на три буквы и уйдет.

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

А что за программа если не секрет, так то формально это нарушение разрешительного режима)

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

1) Проверку маркировки я делаю сразу после сканирования, если не прошла, в чек не попадает.

2) Продажи по каждой позиции делаю в конце, после поступления денег от покупателя, нал или безнал...

3) "Что такое продажа по каждой позиции?"

Это набор команд по каждой позиции:

- Стандартная команда продажи
- Передача единиц измерения, там где нужно
- Передача маркировки (акцизки), если есть
- Передача ответа из проверки маркировки, если есть (4 тэга)

Потом закрытие чека. И после этого чек вылезает...

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

P.S. У всех с этим все ОК, тормозов нет?

P.S.S. Возможно это связано с конкретным ОФД (оператором фискальных данных),
которых по стране более 400

По идее, это все то тормозить не должно... И от ОФД зависеть не должно. Проверки - да, могут. А само закрытие, когда уже все проверено - нет. Там продажа должна проходить сразу, без каких- то ожиданий ответа от ОФД. Чек может быть закрыт, а данные в ОФД могут уходить еще пол часа, в том числе и уведомление о продаже маркированного товара. В ФН попадает сразу, а потом неспеша передается в ОФД, даже когда Вы уже следующий чек оформляете.

Или в Вашем пункте 3 "-передача маркировки(акцизки) если есть" заложена команда проверки ее в ОИСМ - ? Не по РР? Тогда, да, может от ОФД зависеть, и тормозить... Но, ее тоже можно вынести в добавление позиции, с сохранением результата для закрытия чека, о чем я и написал выше...

Вдогонку:

Это набор команд по каждой позиции, как планирую сделать:

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

- Передача единиц измерения, там где нужно, НЕ жду ответа, и так на нем не бывает ошибок
- Передача маркировки (акцизки), если есть, НЕ жду ответа, и так на нем не бывает ошибок,
так как маркировка уже проверена (только задержки)
- Передача ответа из проверки маркировки, если есть (4 тэга), НЕ жду ответа, и так на нем не бывает ошибок
(возможно есть задержки)

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

Проблем у других клиентов, маленьких магазинов, практически не заметно, да и молочка (+вода) там еще не внедрена, и трафик не тот...

А здесь куча касс одновременно "ломится" через один IP в ОФД, да и молочка почти в каждом чеке...

Ну это все в теории (данные в ОФД могут уходить еще пол часа), а я визуально вижу задержки. Т.е. очевидно, ФР ждет ответа от ОФД, пока он не одобрит, и ФР не возвращает мне ответ, пока не дождется ответа от ОФД...
Чтобы потом вывести "М+" на чеке...

Для Штрих эта команда: Привязка маркированного товара к позиции
Код команды FF67h. Длина сообщения: 7+N байт.

Вот если я не буду ждать ответа, и запущу следующую команду, то пока не знаю, может ФР и "ругнется", а может и нет...

ОИСМ проверка идет через ОФД.
Разрешительный режим - напрямую на сервера ЧестногоЗнака.

И бывали случаи, что ОИСМ проверка не проходит, потому что у ОФД все сломалось, и они просто чеки нормально не принимают.

Как вариант, можно предложить автору ветки попробовать на нескольких кассах другого оператора фискальных данных.

А еще вопрос, вы время ОИСМ проверки не контроллируете? В документации написано - не пришло за 1,5 секунды, ну и фиг с ним.

Я запутался в вашей терминологии,
то что я здесь в ветке называю проверкой маркировки, что сразу после сканирования, это через curl в ЧЗ...
И здесь нет ни задержек, ни проблем, почти мгновенно...

Проблемы с задержками, это все при оформлении продаж в ФР, с сопутствующими командами...
Вот там я и хочу попробовать не ждать ответа от ФР, пока он там "обменами" занимается, а запускать следую команду...