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

[slan]

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

Лучше бы наверное не менять количество параметров уже существующих методов, иначе возникнут проблемы у людей, которые уже написали код. Можно добавить отдельным методом.

[salex29]

Да, изменять количество параметров в функциях из-за этого конечно же не стоит. Я имел ввиду, может если добавить отдельный тэг в выходной xml (StatusParameters), который возвращает GetCurrentStatus. От него, я думаю, никому хуже не будет.
Но я вообщем не настаиваю. Доработка не критичная.

[slan]

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

[slan]

Обовил до 1.7.0. Изменения в теме с драйвером

[salex29]

Да, теперь метод ProcessCheck возвращает номер фискального документа из ФН. Это при успешном завершении. Но если метод завершился с ошибкой из-за отсутствия бумаги в принтере, то в номере чека возвращается 0, хотя чек при этом в ФН регистрируется. Поэтому вызвать PrintDocCopy после заправки бумаги не получается.

[salex29]

Обнаружил, что GetCurrentStatus нормально возвращает номер чека в ситуации, когда произошел обрыв бумаги. Буду использовать его для печати копии чека.

[slan]

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

[salex29]

GetCurrentStatus решает проблему. Так наверное будет правильнее.

[andreynso]

Интересуем момент. Будет в 1С устанавливаться в будущем не совместимо, а как другие производители?

[slan]

Интересуем момент. Будет в 1С устанавливаться в будущем не совместимо, а как другие производители?

Не очень понимаю, что вы имеете ввиду. Сформулируйте вопрос как-то по-другому.

[grufov]

Интересуем момент. Будет в 1С устанавливаться в будущем не совместимо, а как другие производители?

Не очень понимаю, что вы имеете ввиду. Сформулируйте вопрос как-то по-другому.

Вероятно имелось ввиду что драйвер будет поставлятся в составе конфигурации, а не подключатся по стандарту "1С:Совместимо".

[slan]

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

[grufov]

slan, добрый день. Можно повторить библиотеку из поста с учетом версии 1.8.1? Суть проблемы, в определенный момент от "драйвера" нет ответа, бумажный чек печатается. В связи с чем повисает весь кассовый интерфейс в 1с, его перезапускают, "повисший" чек валится в непробитые, и проводится в конце смены, как результат дубли продаж. Не факт что виноват драйвер, может и сама ккт/коммуникационный интерфейс, но очень сложно застать момент момент проблемы и возможность проверить связь через туже "панель управления". Нужно понять что в данный момент делает драйвер, ибо сейчас там только лог офд, который мало чем поможет в данной ситуации. Спасибо.

[slan]

grufov, добрый.
Да в общем-то в этой библиотеке реализован весь функционал драйвера, потому смысла повторять ее нет. Можно поновой обложить логами, только надо знать где. Давайте уточним: вся эта ситуация происходит из-за возникновения ошибки "Нет ответа от устройства"? Интерфейс ккт случайно не юсб? Если да, то возможно не потребуется дополнительно логировать, так как недавно обнаружились небольшие расхождения между документацией и прошивкой и скоро будут изменения.
Если же имеется ввиду что драйвер "повисает", не отвечает никакой ошибкой в 1с, и происходит это все в произвольный момент времени, независимо от того выполнялось ли что либо в 1с или нет, то придётся залогировать по максимуму.

[andrish]

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

Ну, наконец сбылось. С последним обновлением 1С Розница реализовано автоматом возврат денежных средств на карту если не напечатан чек по какой либо причине. Уже проверено - работает.

[grufov]

grufov, добрый.
Да в общем-то в этой библиотеке реализован весь функционал драйвера, потому смысла повторять ее нет. Можно поновой обложить логами, только надо знать где. Давайте уточним: вся эта ситуация происходит из-за возникновения ошибки "Нет ответа от устройства"? Интерфейс ккт случайно не юсб? Если да, то возможно не потребуется дополнительно логировать, так как недавно обнаружились небольшие расхождения между документацией и прошивкой и скоро будут изменения.
Если же имеется ввиду что драйвер "повисает", не отвечает никакой ошибкой в 1с, и происходит это все в произвольный момент времени, независимо от того выполнялось ли что либо в 1с или нет, то придётся залогировать по максимуму.

c 1.8.1 и библиотекой mercuryofdfpdrv.exe вываливается в ошибку "библиотека mercuryofd.dll не загружена. приложение будет закрыто". Интерфейс RS-232(COM).
Сегодня поймал ситуацию, и судя по всему корень проблемы един: вчера вечером при закрытии смены цитирую - "всё повисло", "всё" это как выяснилось 1с, ибо завершали работу через пуск. Итог имеем закрытую смену в ККТ(проверялось в панели управления), и не закрытую в 1с. Ок, открываем 1с, жмем закрытие смены, после ~5 минутного ожидания вывалилась в ошибку "При выполнении операции произошла ошибка: Нет ответа от устройства. Отчет на фискальном регистраторе не сформирован." Как следствие кассовая смена в системе(1С) не закрыта. При этом в настройках подключаемого оборудования тест устройства успешно проходит. Панель управления также "видит" ккт. Пока предположение что в ккт происходит какая то исключительная ситуация(например кончилась бумага на печати отчета о закрытии смены, либо смена уже закрыта), а драйвер это некорректно возвращает наружу(в 1С)....

[grufov]

Ок, открываем 1с, жмем закрытие смены, после ~5 минутного ожидания вывалилась в ошибку "При выполнении операции произошла ошибка: Нет ответа от устройства. Отчет на фискальном регистраторе не сформирован." Как следствие кассовая смена в системе(1С) не закрыта.

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

[slan]

Ок. Запилю побольше логов. Протокол, кстати, с подтверждением или без (посмотреть можно через Панель управления ККТ)?
Только вот знать бы в какое место... Вообще, в драйвере обмен реализован по такому принципу: отправляется команда на фискальник, дальше запускается ожидание то него ответа, во время которого фискальник отвечает что он занят каждые 200 миллисекунд. Если он так отвечает около двух минут, то драйвер считает что фискальник повис и выкидывает ошибку. Либо если совсем ничего не отвечает около 20 секунд - та же ошибка о потере связи.
По всей видимости, логи надо добавить в функции непосредственного обмена между драйвером и коммуникационным портом. Ближе к вечеру выложу.

[slan]

c 1.8.1 и библиотекой mercuryofdfpdrv.exe вываливается в ошибку "библиотека mercuryofd.dll не загружена. приложение будет закрыто". Интерфейс RS-232(COM).

А вот тут поподробнее, 1.8.1 и mercuryofdfpdrv.exe это одно и то же. Вы подсовывали что ли длл с расширенными логами из прошлого поста в 1.8.1? Если так то всё правильно, в той dll отсутствуют некоторые функции, добавленные в драйвер 1.8.1. Поэтому драйвер, не обнаружив этих функций в dll, отказывается с ней работать дальше, чтобы в один прекрасный момент всё не закончилось системной ошибкой с подвисанием всего и вся.

[slan]

grufov ,
Прикладываю dll для замены в папке с драйвером. Лучше замените её перед тем когда будете закрывать смену (перед получением ошибки), а то лог сильно разрастётся.
После получения ошибки выслайте лог мне (плюс укажите примерное время возникновения ошибки) и возращайте на место оригинальную dll чтоб сильно не забивался ненужной информацией лог. Скорее всего нам придётся эту процедуру выполнить несколько раз чтобы разобраться в ситуации, так как пока непонятно где логировать по максимуму.