Ошибка при вызове функции getcurrentstatus

По RS-232 не может быть ошибки «FFFFFFF8h, Connect timed out.»
FFFFFFF8h, Connect timed out. — ошибка подключения по TCP
Нет связи — ошибка подключения по СОМ-порту.

Ошибка постоянная или плавающая? При каких обстоятельствах возникает?

Ошибка плавающая, взаимосвязи не нашли, подключали по rs и по ethernet, возникает при пробитии сигарет

В последние дни сервера КМ (ОИСМ) Честного Знака работают со сбоями. Проблемы наблюдаются даже на тестовых серверах. Очень много обращений по данному вопросу. Проскакивают долгие ожидания ответов сервера. Возможно, на них большая нагрузка.
Рекомендуется понизить таймауты ожидания ответа (Т19П7=5, Т19П8=2, таймаут в Тесте Драйвера и в кассовой программе 10000), и игнорировать ошибки. Коды потом все равно спишутся.
Как долго это продлится, можете попробовать уточнить в техподдержке Честного Знака.

А разве ккт должна зависать при этом?

Аппарат с УИМ или без? Какой год производства?

Добрый день.
Такая же проблема, ККТ РР-02, РР-03 прошивки от 26.08.2021, 17.01.2022, драйвер 5.16.0.874, если есть неотправленные уведомления, связь теряется и TCP и по COM (железному). При понижении таймаута Т19П7=5, Т19П8=2, ничего не меняется.

Тут не форум по РР!
Вам сюда https://rr-electro.com/forum/

Похожая проблема со штрих-м01ф 2016 г.в.
 Версия ПО                 : C.3
 Сборка ПО                 : 62507
 Дата ПО                   : 28.12.2022
ФН 7281440500398090
Подключен по USB отправка через ethernet

работает под 1С
При пробитии чека с маркировкой ошибка нет связи. Пробывал через тест драйвера, ошибка остаётся при этом обычные чеки бьются. может и с маркировкой закрыть с N-ной попытки при этом в чеке отсутствует  признак марки, а в ОФД всё норм отображается.

Похожая проблема со штрих-м01ф 2016 г.в.
 Версия ПО                 : C.3
 Сборка ПО                 : 62507
 Дата ПО                   : 28.12.2022
ФН 7281440500398090
Подключен по USB отправка через ethernet

работает под 1С
При пробитии чека с маркировкой ошибка нет связи. Пробывал через тест драйвера, ошибка остаётся при этом обычные чеки бьются. может и с маркировкой закрыть с N-ной попытки при этом в чеке отсутствует  признак марки, а в ОФД всё норм отображается.

Человек прочитал все мои подписи, написал в техподдержку и проблему решили.

Человек прочитал все мои подписи, написал в техподдержку и проблему решили.

Спасибо

Проблема в сканере была

I’ve spent a few hours deciphering what happens when calling getCurrentStatus() with a barcode. The data returned from the API is valid, but things seem to go horribly wrong at parsing the JSON data into the appropriate data structures. Docs are unclear at what should happen, but I assume the returned object from getCurrentStatus() (a CurrentStatusResponse) should be hydrated with data. It’s not. There’s only one fillable prop on CurrentStatusResponse ($Shipments) and that doesn’t get touched. Makes sense, in the returned JSON there is no «Shipments» key, only a «Shipment» key, but this gets entirely ignored AbstractEntity’s jsonDeserialize(). I assume that there should actually be a property $CurrentStatus on CurrentStatusResponse (so you can call getCurrentStatus() on it). If I add that, then it gets filled, but all the other data from the API call is not getting attached to it.

So what happened here? Did PostNL change the returned JSON, or did this never work, and am I the only actually trying to get this working?

Меркурий 119Ф RS. Прошивка 1.5 от 25.09.2017. Драйвер MercuryOfdFPDrv v1.5.2.

Подскажите, как нибудь можно отследить готовность принтера непосредственно перед вызовом функции ProcessCheck?
А то получается следующая ситуация: вызываем ProcessCheck когда принтер не готов (нет бумаги, поднята крышка). Функция возвращает ошибку 4 — «Оформление документа прервано по окончанию времени ожидания готовности принтера», но чек в ФН фиксируется. Повторить этот чек возможности нет, в документации такой возможности не нашел. Тоже самое происходит и при обрыве бумаги — когда бумага заканчивается уже в процессе печати. Он также фиксируется в ФН, и допечатать его нет возможности. По хорошему, нужна и возможность проверить готовность принтера (например в той же функции GetCurrentStatus) и возможность повторить последний зафиксированный в ФН чек — что-то типа RepeateCheck. Просмотрел всю ветку форума, в самом начале поднимался такой вопрос, но решился ли, я так и не понял (может плохо смотрел). Неужели никто больше его не поднимал, ведь он достаточно актуален?

slan писал(а):p.s. эти вопросы поднимаются в данной ветке редко, потому что драйвер пользуют в основном 1сники через интеграционную библиотеку по 1с-Совместимо, а там функционал оборудования ограничен 1сным API, т.е. если в драйвер понадобавляю различных методов — для 1сников (по 1с-Совместимо) они будут бесполезны.

У нас самописный софт, не 1С.

slan писал(а): а как вам поможет функция проверки готовности принтера перед вызовом печати чека? К примеру добавлю я эту функцию, вы её вызовете, получите ответ от драйвера что всё хорошо, а потом при печати кончится бумага и повторится вся описанная вами выше ситуация.

Да, если бумага закончилась в процессе печати чека, никак не поможет. В этом случае как раз нужна функция повтора чека.
Но иметь возможность узнать состояние принтера, считаю, не помешает. Хотя бы для того, чтобы вообще не вызывать ProcessCheck, когда заранее известно что принтер не готов.

slan писал(а): Если вам нужна копия чека — могу добавить в драйвер, начиная с прошивки 1.2 аппарат поддерживает функцию печати документа из буфера фискального накопителя (т.е. по сути копия последнего чека).

Да, такая функция нужна.

salex29 писал(а):У нас самописный софт, не 1С.

Это я уже понял. Я пытался объяснить почему данный вопрос не сильно актуален в данной ветке.

salex29 писал(а):Да, если бумага закончилась в процессе печати чека, никак не поможет. В этом случае как раз нужна функция повтора чека.
Но иметь возможность узнать состояние принтера, считаю, не помешает. Хотя бы для того, чтобы вообще не вызывать ProcessCheck, когда заранее известно что принтер не готов.

Вы итак имеете возможность знать состояние принтера: после каждого метода, который использует печать на чековой ленте, драйвер проверяет состояние принтера, и если была ошибка принтера — драйвер оповещает об этом ошибкой. Соответственно при выполнении вами очередного метода вам достаточно знать что предыдущий метод выполнился без ошибок. API ККТ реализовано таким образом, что само по себе ни о чем не оповещает драйвер. Т.е. ответ от ККТ получается только при каком-либо запросе от драйвера, и в каждом ответе содержатся статусы принтера. В принципе, если вам по каким-то причинам не удается сохранить результат выполнения предыдущего метода, я могу добавить отдельный метод запроса состояния принтера, который будет спрашивать у ККТ какую-либо информацию, например версию прошивки, и обновлять статусы принтера.

slan писал(а):Вы итак имеете возможность знать состояние принтера: после каждого метода, который использует печать на чековой ленте, драйвер проверяет состояние принтера, и если была ошибка принтера — драйвер оповещает об этом ошибкой. Соответственно при выполнении вами очередного метода вам достаточно знать что предыдущий метод выполнился без ошибок.

Да, но проверить состояние принтера непосредственно перед операцией на мой взгляд будет надежнее.

slan писал(а):API ККТ реализовано таким образом, что само по себе ни о чем не оповещает драйвер. Т.е. ответ от ККТ получается только при каком-либо запросе от драйвера, и в каждом ответе содержатся статусы принтера.

Это понятно.

slan писал(а):В принципе, если вам по каким-то причинам не удается сохранить результат выполнения предыдущего метода, я могу добавить отдельный метод запроса состояния принтера, который будет спрашивать у ККТ какую-либо информацию, например версию прошивки, и обновлять статусы принтера.

Да, такой метод нужен.

По хорошему конечно механизм повтора чека при обрыве бумаги должен быть реализован в прошивке аппарата. Передал чек в ФН, начал печать, получил ошибку принтера (крышка открыта, бумага кончилась, принтер сломался и т.п.) — возвел флаг незавершенной печати, ушел в ошибку. Отследил готовность принтера (бумагу вставили, принтер починили), если есть флаг незавершенной печати — взял документ из ФН и напечатал его заново автоматически или по команде из вне. Тогда и для 1С этот вопрос решится автоматически, и в стороннем софте не надо будет городить огород с этими дополнительными методами.

Я вас понял. Со следующим релизом добавлю методы для копии чека и получения статуса принтера.

salex29 писал(а):По хорошему конечно механизм повтора чека при обрыве бумаги должен быть реализован в прошивке аппарата. Передал чек в ФН, начал печать, получил ошибку принтера (крышка открыта, бумага кончилась, принтер сломался и т.п.) — возвел флаг незавершенной печати, ушел в ошибку. Отследил готовность принтера (бумагу вставили, принтер починили), если есть флаг незавершенной печати — взял документ из ФН и напечатал его заново автоматически или по команде из вне. Тогда и для 1С этот вопрос решится автоматически, и в стороннем софте не надо будет городить огород с этими дополнительными методами.

Может быть. Здесь дело за разработчиком прошивки. Однако я думаю в прошивке эту проблему полностью всё равно не решить, так как может например пропасть питание у ККТ при печати чека. По-хорошему надо бы запоминать номер последнего напечатанного чека на самом верхнем уровне.

salex29 писал(а):

slan писал(а):Вы итак имеете возможность знать состояние принтера: после каждого метода, который использует печать на чековой ленте, драйвер проверяет состояние принтера, и если была ошибка принтера — драйвер оповещает об этом ошибкой. Соответственно при выполнении вами очередного метода вам достаточно знать что предыдущий метод выполнился без ошибок.

Да, но проверить состояние принтера непосредственно перед операцией на мой взгляд будет надежнее.

slan писал(а):API ККТ реализовано таким образом, что само по себе ни о чем не оповещает драйвер. Т.е. ответ от ККТ получается только при каком-либо запросе от драйвера, и в каждом ответе содержатся статусы принтера.

Это понятно.

slan писал(а):В принципе, если вам по каким-то причинам не удается сохранить результат выполнения предыдущего метода, я могу добавить отдельный метод запроса состояния принтера, который будет спрашивать у ККТ какую-либо информацию, например версию прошивки, и обновлять статусы принтера.

Да, такой метод нужен.

По хорошему конечно механизм повтора чека при обрыве бумаги должен быть реализован в прошивке аппарата. Передал чек в ФН, начал печать, получил ошибку принтера (крышка открыта, бумага кончилась, принтер сломался и т.п.) — возвел флаг незавершенной печати, ушел в ошибку. Отследил готовность принтера (бумагу вставили, принтер починили), если есть флаг незавершенной печати — взял документ из ФН и напечатал его заново автоматически или по команде из вне. Тогда и для 1С этот вопрос решится автоматически, и в стороннем софте не надо будет городить огород с этими дополнительными методами.

Ещё выше уровень когда покупка проходит по банковской карте, а ФР не готов к печати, деньги с карты списываются, в банке операция проходит, а вот чек не печатается, покупка в 1С не проводится. Было уже несколько таких случаев, в 1С списанием повёл, больше ничего не придумал.

slan писал(а):Вы наверное не очень понимаете смысл фразы «уровень ПО». Я имел ввиду, что для наибольшей надежности, контроль должен осуществляться на самом верхнем уровне ПО (потому что только там можно глазами кассира увидеть напечатан чек на устройстве или нет): самый нижний уровень — прошивка устройства, далее драйвер, далее программа использующая драйвер. Вот эта программа и есть самый верхний уровень.

Какой бы уровень не был,может я их путаю, а действие оплаты происходит: оплата картой, далее печать чека с терминала, далее продажа в 1С, далее передача данных ОФД, далее печать чека как бумажного документа. И если при безналичной оплате происходит сбой печатающего устройства, происходят действия описанные мной выше. Бывает на этапе наличной оплаты, чек не распечатался, а данные в ОФД ушли, продажа в 1С так же не прошла. И если в случае с безналом ничего не сделать, в случае с налом делаем «отложенную продажу» в 1С, устраняю неисправность, провожу продажу отложенного чека(случай с алкоголем при сбое не рассматриваю, там ко всему ещё и обращение к транспортному модулю, полные дебри).
Да, если 1С считать верхним уровнем, то для 1С пишется Интеграционная библиотека, может я опять не о том?

slan писал(а):Интеграционная библиотека нужна 1С для работы с драйвером по стандарту 1С-Совместимо. Она реализована в соответствии с требованиями 1С к такому типу ПО и содержит все описанные в этих требованиях функции. Эти функции 1С потом дергает сама.
Далее. Предположим, что при пробитии чека из 1С он записался в ФН (и через некоторое время ушел в ОФД), а при печати чековая лента закончилась. По-хорошему после заправки новой чековой ленты нужно напечатать копию чека. Однако как драйвер должен определить что новая лента заправлена чтобы напечатать копию? Кроме как по нажатию кнопки в программе самого верхнего уровня кассиром мне в голову не приходит больше вариантов. И это лишь один пример. Их можно много написать. Но смысл будет один и тот же.

Во всяком случае проблема существует и не только по Меркуриям, слышу такие проблемы и от других продавцов, особенно касается оптовиков у которых акцизный товар. Позиций по сотне, лента метрами, учёт серьёзный, пока не слышал как они выходят из таких положений. Ну а мы в рознице обвешались оборудованием с передачей данных и не отлучиться никуда дальше своего города, спасибо правительству.

slan писал(а):Я это все написал к тому — что претензии стоило бы предъявлять к софту верхнего уровня, а не к драйверу. Только там получится реализовать нужное поведение для пользователя перед которым стоит аппарат.

Вы знаете, то что я имею в виду — это не претензия, тонкостей я не понимаю да и не хочу вникать, не судите строго. Кому и какие претензии высказывать я вообще не понимаю в теперешнее время, Вы мне очень помогаете и огромное Вам СПАСИБО.

salex29 писал(а):Проверил метод GetHardwareStatus — работает. Единственное замечание — при отсутствии связи с ФР метод все равно возвращает успех (True).

Странно, вроде не должен. Проверю. Вы имеете ввиду — возвращает успех если не было произведено подключение т.е. сразу выполнен запрос GetHardwareStatus , или при установленном соединении выключить питание и вызвать GetHardwareStatus?

salex29 писал(а):С методом PrintDocCopy проблема. Он требует номер фискального документа, но взять его негде. Метод ProcessCheck в параметре CheckNumber возвращает локальный номер чека внутри смены, а не номер фискального документа (ФД), хотя в описании написано, что «CheckNumber — Номер фискального чека возвращаемый ФН». Метод GetCurrentStatus тоже возвращает локальный номер чека.

Видимо это произошло из-за разной терминологии в документациях 1С и фискальника. В требованиях 1С методом ProcessCheck должен возвращаться CheckNumber (Номер фискального чека возвращаемый ФН), а в документации фискальника номер чека — это номер чека внутри смены, а номер документа — это сквозной номер независящий от смены. Видимо номер чека из 1С соответствует номеру документа из документации ККТ. Если это так — то тогда переделаю метод ProcessCheck: в параметр CheckNumberзапишу сквозной номер документа. А метод PrintDocCopy переделывать не нужно, он будет принимать этот номер (только в документации поправлю НомерДокумента на НомерЧека). Соответственно эти изменения коснутся и методов GetCurrentStatus, ProcessCorrectionCheck,

slan писал(а): … или при установленном соединении выключить питание и вызвать GetHardwareStatus?

Да, именно это я имел ввиду. У меня ФР с интерфейсом RS-232, если это важно.

slan писал(а): … в параметр CheckNumber запишу сквозной номер документа.

Если при этом еще и номер чека внутри смены останется доступным (через какой-нибудь дополнительный параметр), будет совсем замечательно.