Отправка уведомлений в ИСМ

[vistavista]

Добрый день.
фн с момента регистрации не отправляет уведомления в исм. Чеки в офд отправляет. Соответственно накопив неотправленные уведомления касса заблокировала работу с маркированными товарами. Программой от рестарта тоже уведомления не отправляются. Кто нибудь сталкивался? Возможно неисправна ФН? Что посоветуете?

[Bit]

https://kkmcom.ru/index.php?action=downloads;sa=view;down=6108
Нет исходной инфы.
Сегодня с утра наш программист спрашивал...
Подключился к ПК , ККТ Атоловский ФР, настроен по ЕОТ, сменил на EOU чеки ушли, ключи ессно сами не обновились.
Обновил ключи с 10 ДТО. Открытие смены прошло.
Верхнее ПО Микроинвест вероятно не поддерживает ЕОТ.

[vistavista]

Ссылку что дали, это прога от рестарта я написал что её тоже не отправляет - грешу на фн. Но может кто сталкивался что из-за фн не отправляются уведомления. Так сказать подтвердить подозрения.

[Ильназ]

Попробуйте сначала в ОФД обратиться, что они скажут

[Bit]

Ссылку что дали, это прога от рестарта

Виноват. Изменил.

[RomanPrg]

Программой от рестарта тоже уведомления не отправляются.

В утилите на вкладке «сервер ИСМ» не забыли правильный адрес ОИСМ прописать и нажать кнопку «Применить» ?
По умолчанию, настроен адрес для работы с МГМ.

[easy2105]

Сталкивался. Было одно неотправленное уведомление. Отправили в Инвенту. Наш менеджер сказал, что признали гарантийный случай.
Сейчас жду пока  пришлют обратно.

[GeorgSerg]

Было одно неотправленное уведомление...признали гарантийный случай...

Нихераськи себе деффки пляшуть.... Теперь что - при неотправке ( имхо, но если точнее, то при отказе в приёмке серваком ЧЗ) сразу ФН на гарантию, то есть можно считать прецедентом? Однако...
P.S. Это так, мысли вслух.. Проверять / тестить всё равно нечем.

[Смирновка]

У нас тоже было такое. ФН не мог принять квитанцию. За месяц скопилось 2000 уведомлений.
Закрыли архив и отправили на экспертизу. Ответ Инвенты таков - ФН признан неисправным по причине программного сбоя. Тип брака неисправимый.

[GeorgSerg]

ФН не мог принять квитанцию

Это как так? Ничё не понятно. По вашему посту получается, что некое уведомление от ФН через ККТ и прокси - сервак ОФД в ЧЗ ушло, ЧЗ его принял, записал в ЛК клиента,отправил квитанцию, но уже ФН не принял - так , что ли?

скопилось 2000 уведомлений

Или всё - таки сервак ЧЗ отказал в приёмке по причине кривоты от ФН? Это ж абс-но разные ситуёвины..
P.S. Коллеги, если уж что такое и выкладываете - то подробно, с конкретикой.. 

[Stok]

Или всё - таки сервак ЧЗ отказал в приёмке по причине кривоты от ФН? Это ж абс-но разные ситуёвины..

Одно другому не противоречит. Если ФН не смог принять одну квитанцию, то все последующие уведомления он просто не будет отдавать. Алгоритм с квитанциями и уведомлениями точно такой же как и с чеками для ОФД и их подтверждениями приемки.

[easy2105]

Нихераськи себе деффки пляшуть.... Теперь что - при неотправке ( имхо, но если точнее, то при отказе в приёмке серваком ЧЗ) сразу ФН на гарантию, то есть можно считать прецедентом? Однако...

Пока официального ответа не читал, жду.
Чуть подробнее:
сканер был в клавиатурном режиме. били молочку с ффд1.2; Было пробито много товара с "М-"
Но ЧЗ не принял только одно. Обзвонил всех: Эвотор, ОФД, ЧЗ, Инвента.
Естесственно, все друг на друга валили. Слава богу, была возможность отправить на экспертизу.
Кстати, эту ФН мы покупали не у Инвенту, а у партнера.
И ещё: Проработал ФН ДВА месяца после неотправленного уведомления. Перестал бить маркированный товар.

[easy2105]

Алгоритм с квитанциями и уведомлениями точно такой же как и с чеками для ОФД и их подтверждениями приемки

Вот тут не уверен!
В моём случае было только одно неотправленное уведомление двухмесячной давности.
А пробивают они очень много маркированного товара

[zival]

Бы аналогичный случай, отправили в Инвенту - поменяли по гарантии без проблем.

[GeorgSerg]

Алгоритм с квитанциями и уведомлениями точно такой же 

Ой ли.. Я не был бы столь категоричен.. Что, с серверов ОФД / ФНС идет для ФП чеков такое же обновление крипты в ФН, как и у марок?

[Stok]

Вот тут не уверен!
В моём случае было только одно неотправленное уведомление двухмесячной давности.
А пробивают они очень много маркированного товара

А я уверен. Если было одно неотправленное уведомление, то все следующие уведомления должны копиться в буфере неотправленных пока он не заполнился. После чего блокируется продажа маркированного товара. Это естественно верно при условии если ФН работает согласно документации "Протокол информационного обмена ККТ-ФН":
4.11.1 Алгоритм передачи уведомлений
Шаг 1. ККТ вызывает команду BAh и смотрит на количество уведомлений в очереди на передачу.
Шаг 2. ККТ вызывает команду BBh для получения размера очередного уведомления для передачи.
Шаг 3. ККТ использует команду BCh, чтобы вычитать всё уведомление для передачи. ККТ вызывает команду BDh, если хочет прервать процедуру чтения уведомления. ККТ вызывает команду BEh, когда полностью вычитает уведомление, ФН переходит в состояние ожидания квитанции на прочитанное уведомление.
Шаг 4. ККТ передает уведомление и получает квитанцию на уведомление.
Шаг 5. ККТ использует команду BFh, чтобы передать в ФН квитанцию на уведомление. В случае успешной обработки квитанции ФН возвращает ККТ реквизиты TLV, содержащиеся в квитанции.

[Stok]

Ой ли.. Я не был бы столь категоричен.. Что, с серверов ОФД / ФНС идет для ФП чеков такое же обновление крипты в ФН, как и у марок?

Георгий, какая разница какая крипта у чека и у марки? Мы ведём речь об алгоритме отправки уведомлений. Он последовательный как и у чека. То есть, если есть хотя бы одно неотправленное уведомление (не важно по какой причине: крипта кривая, сбой связи, не пришла квитанция и т.п.), то все следующие не будут отправлены.

[chellenger]

Если с точки зрения программера говорить это принцип работы стека только на оборот. Пока самое первое в очереди не отправлено следующие не уйдут.

[Stok]

Если с точки зрения программера говорить это принцип работы стека только на оборот. Пока самое первое в очереди не отправлено следующие не уйдут.

Совершенно верно, стандартный алгоритм FIFO - первый пришел, первый ушел.

[GeorgSerg]

Мы ведём речь об алгоритме отправки уведомлений

Хе... Вот-вот..А ежели серьёзно, то мы сейчас говорим ни о чём. Алгоритм отправки - это микро-надстройка над сборкой ответов на выборку из "общего массива команд" *. И знаем только один факт -

если есть хотя бы одно неотправленное уведомление .....то все следующие не будут отправлены

*В "алгоритме" какого протокола есть закладка "про карантины ОФД - жёсткий / мягкий"? Если нет такого - то это не алгоритм, а филькина грамота, позволяющая формировать и отправлять заведомо неверные данные..

[Stok]

*В "алгоритме" какого протокола есть закладка "про карантины ОФД - жёсткий / мягкий"? Если нет такого - то это не алгоритм, а филькина грамота, позволяющая формировать и отправлять заведомо неверные данные..

См. протокол информационного обмена ОФД - ФНС (ФФД-1.2) версия 1.9
https://kkt-online.nalog.ru/materials/

[GeorgSerg]

См. протокол ..версия 1.9...

Ну у нас с тобой и разговорчик !    

"Рюмку водки, плаху, палача и таблицу 39!
Водку мне - остальное Georg_у! " (с)

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

[vistavista]

По сути своей проблемы - поменял фн. С новым фн квитанции идут. фн готовлю на отправку по гарантии.

[vistavista]

0302 - до проблемной сери 0502

[AlexSAN]

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

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

[Stok]

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

Это свидетельствует о том, что ФН глюканул. Вероятно у него внутренний указатель в какой-то момент перескочил через группу неотправленных документов.

[chellenger]

AlexSAN, или был переход в автоном и обратно.

[AlexSAN]

Не- точно не было. Первый непереданный - открытие смены. Последний - чек в этой же смене. Дальше все чеки в этой же смене - переданы и подтверждены. Однозначно глюк ФН.

[easy2105]

А я уверен. Если было одно неотправленное уведомление, то все следующие уведомления должны копиться в буфере неотправленных пока он не заполнился

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

[Олег1950]

На Эвоторе СТ2Ф зависло одно уведомление в ИСМ. В ОФД чеки уходят без проблем.
Попытка отправки через WIN_TEST_FM_OFD_FFD_1_2. выдает ошибку чтения порта. Пинги с ОФД и ИСМ проходят.
Попытка отправки через FNarc3114 выдает неверное состояние ФН.
ФН активирован в июне.      Похоже ФН копец?
Что-то еще можно предпринять?

[chellenger]

Олег1950, Эвотор советует сделать техобнуление для начала. Пробовал?

[chellenger]

Потом в параметрах ОФД заново забить ОФД и ИСМ

[Олег1950]

Александр, а смысл, если проги через комп не отправляют.

[Олег1950]

Александр, понадеялся на АВОСЬ,  но техобнул с восстановлением ОФД и ИСМ не помог.

[chellenger]

Олег1950, я не понял причём тут открытие какого то порта.
У ФН нет портов.

[Олег1950]

Александр, наверное прога так написана.

[chellenger]

Недавно приносили Эвотор, встала очередь уведомлений.
Все чеки в ОФД переданы, настройки верные.
Воспользовались советом Эвотор.
Тех. обнуление и ввод по новой параметров ОФД и ИСМ
-все уведомления отправились, торговля маркированными товарами возобновилась.

[Олег1950]

Недавно приносили Эвотор, встала очередь уведомлений.
Все чеки в ОФД переданы, настройки верные.
Воспользовались советом Эвотор.
Тех. обнуление и ввод по новой параметров ОФД и ИСМ
-все уведомления отправились, торговля маркированными товарами возобновилась.

В моем случае не прокатило.

[Олег1950]

Прога FNTest_1_2 также показывает : НЕВЕРНОЕ СОСТОЯНИЕ ФН

[chellenger]

Олег1950, у нас нет инструментов как корректно оттестить работу ФН в плане маркировки.

[chellenger]

А прога FNarc3114 вообще предназначена для выгрузки из ФН которые в автономе.
Возможно по этому "неверное состояние ФН"

[chellenger]

Всё что нам доступно это потыкаться почти в слепую прогой FNTest_1_2
Пробовал через неё выяснить "состояние ФН" ?

[Niro]

Всё что нам доступно это потыкаться почти в слепую прогой FNTest_1_2
Пробовал через неё выяснить "состояние ФН" ?

Прога FNTest_1_2 также показывает : НЕВЕРНОЕ СОСТОЯНИЕ ФН

[GeorgSerg]

Эвотор советует

Смысл? WIN_TEST - прямое подключение.. ОФД выступает транспортом для отправки запросов в ИСМ, а ИСМ (ЧЗ) уже отдает статусы. По скану уведомления Ответ #29 - размер тела ноль, команда Out ноль и отправляет
Касаемо FNArc - ошибок нет, выдает "неверное состояние ФН" - неверное для КОНКРЕТНОЙ команды, то есть НЕТ уведомлений для отправки, нечего отправлять.

ИМХО - трупень. И опять в полный рост встает проблема - это мы в ЦТО ничем и никак не можем определить..

[chellenger]

Niro, я в смысле в этой проге есть все команды (документированные) по работе с этим ФН. Там можно и другие запросы делать и т.д.
А не один ответ на команду  0xB0

[Олег1950]

В FNTest_1_2 дата уведомления 1899г. И дальше НЕВЕРНОЕ СОСТОЯНИЕ ФН
Скорее всего - гарантия.

[chellenger]

Олег1950, Вот этого и нужно было добиться от ФН.
Теперь можно смело отправлять в гарантийку и чётко описать что не так с ФН.
Как минимум дата застрявшего уведомления.

[GeorgSerg]

Как минимум дата застрявшего уведомления

Это НЕ дата уведомления...Это программисты так шутят "сигнал о сбое" при формировании уведомления из "битых ячеек" флеш-памяти..

[chellenger]

GeorgSerg, ну это понятно. Как минимум на дату выделено 2 байта, слёт хотя бы одного бита приведёт к неверной интерпретации. И шутки программеров тут не причём. Скорее недоразвитость... так как в блоке памяти выделенном под это уведомление должна быть КС по которой можно однозначно выдать ошибку "повреждено уведомление №хххх "
И вообще данные должны по хорошему быть защищены от повреждения.
Де факто буфер уведомлений это аля оперативка.
Я вот помню древние времена ещё 1999 года когда ручками карту памяти ОЗУ самсунга 4615 составлял. Там все счётчики были записаны по 3 раза в раных адресах. Если один повредить -восстановит на основании двух других, повредить 2, но не одинаково -ошибка 22 (сбой ОЗУ)

[Niro]

Я вот помню древние времена ещё 1999 года когда ручками карту памяти ОЗУ самсунга 4615 составлял. Там все счётчики были записаны по 3 раза в раных адресах.

В ЭКР 2102Ф так же было сделано.

[GeorgSerg]

должна быть КС

Оно ж, сцуко, шифруется... И да - откуда взяться алгоритму, если кодов маркировки больше, чем."цветков в проруби плавает", тем более, что ФН эту крипту не проверяет - что из проруби достали, то и отправляет... В итоге, если довести всё до.. ну, до этого, вам по пояс будет - надо в ККТ отдельный от ФН "блок ЧЗ" ставить, только для работе с марками... И при продаже маркированного товара первым делом печатать "пречек" ( +/-М, М) с ответом от сервака ЧЗ, а уж опосля хреначить продажу.

[chellenger]

Niro, да я позже в оперативке ЭКР тоже покопался, аналогично сделано было.

[chellenger]

Оно ж, сцуко, шифруется... И да - откуда взяться алгоритму

Да какая блин разница?
КС шифрованного пакета добавить... с тупой целью, сформировалось уведомление, поклалось на полочку в условном ОЗУ -получи КС на внутреннее хранение.