Драйвер "Инкотекс: ККТ Меркурий с передачей данных в ОФД (54-ФЗ)" (М119Ф) [Обсуждение]

[slan]

Может совпадение?

Скорее всего

[salex29]

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

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

[slan]

salex29, а как вам поможет функция проверки готовности принтера перед вызовом печати чека? К примеру добавлю я эту функцию, вы её вызовете, получите ответ от драйвера что всё хорошо, а потом при печати кончится бумага и повторится вся описанная вами выше ситуация. Если вам нужна копия чека - могу добавить в драйвер, начиная с прошивки 1.2 аппарат поддерживает функцию печати документа из буфера фискального накопителя (т.е. по сути копия последнего чека).
p.s. эти вопросы поднимаются в данной ветке редко, потому что драйвер пользуют в основном 1сники через интеграционную библиотеку по 1с-Совместимо, а там функционал оборудования ограничен 1сным API, т.е. если в драйвер понадобавляю различных методов - для 1сников (по 1с-Совместимо) они будут бесполезны.

[salex29]

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

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

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

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

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

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

[slan]

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

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

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

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

[salex29]

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

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

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

Это понятно.

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

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

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

[slan]

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

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

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

[salex29]

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

Спасибо

[andrish]

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

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

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

Это понятно.

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

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

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

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

[slan]

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

[andrish]

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

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

[slan]

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

[andrish]

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

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

[slan]

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

[andrish]

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

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

[slan]

Обновил драйвер до 1.6.0. Добавил методы получения копии документа и статуса оборудования. Исправил работу со скидками, в предыдущих версиях были косяки при количестве больше 1. Скидки пока довожу до ума, пока что не решены проблемы округления.

[salex29]

Спасибо, будем пробовать.

[salex29]

Проверил метод GetHardwareStatus - работает. Единственное замечание - при отсутствии связи с ФР метод все равно возвращает успех (True). С методом PrintDocCopy проблема. Он требует номер фискального документа, но взять его негде. Метод ProcessCheck в параметре CheckNumber возвращает локальный номер чека внутри смены, а не номер фискального документа (ФД), хотя в описании написано, что "CheckNumber - Номер фискального чека возвращаемый ФН". Метод GetCurrentStatus тоже возвращает локальный номер чека.

[slan]

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

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

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

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

[salex29]

... или при установленном соединении выключить питание и вызвать GetHardwareStatus?

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

... в параметр CheckNumber запишу сквозной номер документа.

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