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

Тут 1.5 сек на что? На ОИСМ или на РР?
Если речь про РР, то при проверке марок "чохом" не будет задержки 15 сек (10марок*1,5), а будет только 1.5 сек, т.к. можно отправить ОДИН общий запрос АПИ на все 10 марок. При этом время будет не более 1.5 сек на весь запрос из 10 марок (а не на каждую марку, если отправлять запрос в момент ее сканирования).
Т.е. для РР можно получить какой-то выигрыш во времени, если проверять все марки сразу при закрытии чека.
А вот для ОИСМ - нет, нельзя, там на каждую марку нужно отправлять отдельный запрос (что при закрытии чека, что при сканировании "на лету").

об этом и речь..

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

Многодесятилетняя практика автоматизации и огромное количество моих довольных клиентов показывают иное. Только я решаю как правильно. У меня опыт работы моей личной торговой сети из 4-х магазинов которые проработали 10 лет, опыт автомализации моего собственного производственного цеха, моего собственного оптового склада. Я ЗНАЮ ВСЁ. Я писал эту программу ДЛЯ СЕБЯ, КАК МНЕ УДОБНО, КАК ДОЛЖНО БЫТЬ ИДЕАЛЬНО. Поэтому моя программа максиаально удобна, а моему функционалу нет равных. Никакая 1С по функционалу не сравнится. А всё потому что 1с- ники писали свою поделку не для себя, а для других, их программисты сами не владели предприятиями, и не знают как правильно должно быть. Они писали, выполняя заявки клиентов, принятые на основе неправильных решений руководителей. В итоге написали тормозящего монстра, расходующего ресурсы неправильно, требующего дорогих мощнейших компьютеров. У меня программа в ТЫСЯЧИ раз меньше по размеру, а может больше, работает мгновенно в сетевом режиме на самом отстойном компьютере 20-летней давности за 8000р , используемом в качестве сервера для работы многих рабочих мест в единой базе данных.
А законодательство у меня всё поддерживается. Вот, даже разрешительный режим работает как надо.
Всем клиентам говорю, если вы спросите , а есть ли вот такая функция, я сразу заранее отвечаю ДА на любой ваш вопрос, что бы вы ни спросили. Вы не придумаете никакую функцию, которой бы не было в моей программе.

Это неправильно, так как нужно на этапе сканирования исключить запрещенный к реализации товар в тот момент, когда продавец, сканируя, держит его в руках, чтобы отложил его в сторону, а не в конце сканирования, когда из 20 одинаковых таркируемых товаров компьютер скажет что нужно из кучи убрать один вот с этой маркой (как??? сканируя в блокноте и глазами сверяя код марикровки??) Ну нет. Проверять в РР нужно каждую единицу пока ее в руках держит продавец.
Вот пример когда спрашивать руководителя как он бы хотел проверить в РР - по одной или сразу все, НЕ НУЖНО. Руководителя вообще не нужно спрашивать как вести учет. Его нужно научить делать это правильно а не давать фантазировать.

Еще я бы научил чиновников как правильно придумывать правила учета.
Еще я бы научил Гущанского как правильно ЕГАИС разрабатывать (помним про механизм негарантированной доставки который он в ЕГАИС сотворил).

У меня был ночной клуб трехэтажный с двумя ресторанами и 6-ю барами. На кухне моя программа вела учет грамм в грамм. Повара офигели - никакой полуфабрикат даже 30 грамм не украсть. Начали жаловаться руководителю что слишком сложный учет. Руководитель вызвал меня и начал заяснять что надо учет упрощать - персонал жалуется. Я ему обьяснил что если упрорстить, пойдет воровство, и жалуются потому что каждый грамм даже соли с перцем на учете, чуть что сразу недостача и видно на каком этапе - если недостача фарша то виноват не кладовщик, не повар, не официант, а тот, кто его молол на мясорубке. Руководитель тогда сказал - не будем упрощать. Воровство недопустимо. Эти руководители сами не понимают как правильно. Нефиг их спрашивать.

Вариант посылать марки на проверку при формировании чека на ккм после сканирования всех товаров, как обычно и делают. Но не ждать результата совсем, а принимать решение на основании онлайн проверки в ЧЗ. То есть всегда ставить успех (15). Вероятность, что по ЧЗ все нормально, а запрос в ккм вернет некорректную марку, не высока. Если, конечно, ккм так позволит работать, надо проверять.

Отправить запрос на проверку через ккм и отложить получение результата на потом просто так не получится, насколько я знаю. Результат возвращается по последнему запросу. Можно попробовать соорудить очередь проверяемых марок. То есть, пикнули марку, послали на проверку, пикаем следующий товар. Если это снова маркировка, то получаем результат по предыдущему запросу. После получения (в штрихах управлять из приложения не получится, запрос статуса это одна команда, в отличии от атолов), шлем запрос на проверку следующей марки и т.п. То есть тут параллельно проверяется марка через ккм и сканируется следующий товар. Это достаточно громоздкий путь, так как надо держать чек открытым и обрабатывать внештатные ситуации (аннулировать открытый чек, очищать буфер проверяемых марок в ккм).

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

Абсолютно согласен!!! И со всеми вашими предыдущими высказываниями...!

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

И тут в ветке конечно все "немножко" путаются в терминологии, поэтому идет разноголосица...

1) Так называемый здесь "РР" /разрешительный режим/
(на самом деле это прямое общение программы с ОИСМ через curl запрос),
конечно делается сразу после сканирования маркировки, тут я с вами абсолютно солидарен,
пока товар в руках у кассира.

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

И так реализовано и у меня, и (наверное) у всех...

2) То что здесь называют "запросом ОИСМ" (в конце всех сканирований, при оформлении продаж и потом, закрытии чека),
на самом деле, это общение с ФР определенными командами, в т.ч. связанными с маркировкой.
А именно, по каждой марк.позиции:
- Передача самого кода маркировки (у Штрих команда FF67)
- Передача ответа (полученного через curl-запрос ранее) 4 ТЭГа (ну те кто в теме, знают, какие)

А уже ФР общается с ОФД, а ОФД общается с ОИСМ.
И если "общение" по любым причинам "стопорится" (упал интернет, перегруз трафика с ОФД) откладывает в ФН, потом дообрабатывает...

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

Суть: Не ждать ответа от ФР именно по этим командам, а продолжать дальше грузить команды из чека...

По факту реализации и итогового тестирования - обязательно отпишусь...

И есть еще вероятность, что разные производители ФР, по разному решили проблему с определенными командами, связанными с маркировкой.

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

Условно "Атолл" эти команды кладет в ФН, сразу возвращает положительный ответ (ведь маркировка уже заведомо проверена), а потом спокойно их отрабатывает... Задержки нет.