УТМ 2.0.4

[Александр Сергеевич]

Скажите какой вы видите альтернативный выход или надстройку?

Все очень просто! Если УТМ вернул ошибку, не нужно лезть в лог, УТМ ничего не должен отправлять после этого сам. Я уже об этом писал выше не хочется повторяться.

[Александр Сергеевич]

Скажите какой вы видите альтернативный выход или надстройку?

Код: Выбрать все

<Cheque inn="5009022295" kpp="500901002" address="142006,Московская область" kassa="00106901966622" shift="14" number="2" datetime="1307170934">
   <Bottle price="389.00" barcode="22N0000012MXWPQ5V4U0310622220010197845A84ZJIOB3FH2E9YD2XMYG8S18L38Y9" ean="4623721249181" volume="0.7500"/>
</Cheque>

Если все хорошо УТМ вернет:

Код: Выбрать все

<?xml version="1.0" encoding="UTF-8" standalone="no"?><A><url>http://check.egais.ru?id=917091d8-1cb0-4212-95b1-42bc92e22de7&amp;dt=1307170934&amp;cn=020000164900</url><sign>9B5B662807F234D0537AFED458AEDF274E900F1408B68CC398EA902294C762EC1F6D754199399DBA0114E51434469D2395EB46B770FC3AC2B50FE02B28070E70</sign><ver>2</ver></A>

Отсюда видно чек подписан.
Другое дело когда УТМ возвращает, а может и Apache точно сказать не могу:

Код: Выбрать все

14.06.2017 21:33 "Failure when receiving data from the peer"

Обратите внимание эту ошибку "рисует" не УС, а УТМ,
что сулит нам о том что чек не ушел или что то пошло не так, QR откуда печатать?
Возможно, опять же моё предположение, на это сообщение стоит реагировать положительно и чек выбивать, но возникает вопрос почему в док. по УТМ про это не сказано, а сказано только что подтверждением является подпись.

[alcodream]

Александр Сергеевич, специально зарегистрировался чтобы написать Вам - Вы красавчик!

Все описанное выше Вами действительно имеет место быть, и это чудовищная ошибка.

У нас тоже самое:

на post-запрос c xml <check> УТМ возвращает что-то вроде <A><error>1: Проверка не пройдена: [акцизы] </error><ver>2</ver></A>
При этом продажа реально проходит.

Из логов УТМ можно узнать как такое получилось, например вот как это у нас происходит:

2017-07-26 12:08:10,356 INFO - ID: [87ee639d959fce91] - Получен чек.
2017-07-26 12:08:10,458 INFO - ID: [87ee639d959fce91] - Подпись чека [тип: Bottle, uuid: d7e9eb60-ebdf-403b-816a-6f1f07532bad, касса: 0502899, смена: 1882, чек: 1882, дата: 2607171201]
2017-07-26 12:08:11,510 INFO - ID: [87ee639d959fce91] - Чек подписан [7E4DC05C91ACC3D49A55D0F023FF58580D3ACCEEC505D55C08D9AE9A73F09BCF35838D743D3B55CBB30FC61D873EA8AFC630EE976F184EAFB4241E4F27C44DBE]
2017-07-26 12:08:11,548 INFO - ID: [87ee639d959fce91] - Отправлена квитанция.
2017-07-26 12:08:51,745 INFO - ID: [2f20d06fa774bb5b] - Получен чек.
2017-07-26 12:08:51,860 WARN - ID: [2f20d06fa774bb5b] - Чек уже был подписан [тип: Bottle, касса: 0502899, смена: 1882, чек: 1882, дата: 2607171201]
2017-07-26 12:08:51,871 INFO - ID: [2f20d06fa774bb5b] - Подпись чека [тип: Bottle, uuid: 11a09734-48ed-40e3-b5c3-b70616856f90, касса: 0502899, смена: 1882, чек: 1882, дата: 2607171201]
2017-07-26 12:08:53,044 INFO - ID: [2f20d06fa774bb5b] - Чек подписан [F92651BAF8772CEBA099CAA9ABAE956B0FA6663C1B8E8310AD910281881CCDDFFA6E66A37C21BAF5D10740376E938F59661EC5169DDD8B664DDAA224B907B697]
2017-07-26 12:08:53,057 ERROR - ID: [2f20d06fa774bb5b] - Некорректное состояние транспортного терминала.
2017-07-26 12:08:53,058 ERROR - ID: [2f20d06fa774bb5b] - Отправлена информация об ошибке: [<A><error>1: Проверка не пройдена: 22N00002NS4CKHMTYQK7I7J610180040007457YNY22R3L3X6LI4HEEUIZO8NWO0VZZ8, 22N00002NS4CKHMTYQK7I7J61018004000748IONYTLQF8YUUALL2DHAQMHG7A15U2SV, 22N00002NS4CKHMTYQK7I7J6101800400085420Y1EHF77WJZ81PWV3QINFL7X7XNRJC, 22N00002NS4CKHMTYQK7I7J61018004000860862LBAF8B0H89S24JP877I69X6QITE5, 22N00002NU5DBKYDOT07ID970321014003046RKFB0MONTWV9D3PF4PWKLD3WK4TKIIT, 22N00002NU5DBKYDOT07ID970321014003047BJYFBLRNQREOF1QVT15YSZMCG9DGLJW, 22N00002NU5DBKYDOT07ID970321014003048TJB32CL4V1W0AAFIWH0AR8J6R5VQ1OQ, 22N00002NU5DBKYDOT07ID970321014003049M04DN002IF1UG4G5DPO0SXNOWU8H02H, 22N00002NU5DBKYDOT07ID9703210140030500KU26GLKRF2O68JXPO2HXCBC3V3P9TT, 22N00002NU5DBKYDOT07ID970321014003051QE71U29Z1R1CJ5HEPTBY633XPZFK9Q2</error><ver>2</ver></A>]

что мы видим: утм успешно зарегистрировал продажу, подождал секунд 30-40 и отправил ещё раз такой же запрос, который теперь не прошел (логично) и вернул ошибку.

Система из которой мы отправляем запрос на платформе 1С. В ответ всего на один запрос приходит ошибка (в самом начале поста) и больше ничего.

Господа операторы, есть что сказать по этому поводу?
Возможно проблема из-за промежуточных каких то звеньев (платформа 1с, операционная система и т.д.) ? уж очень не хочется винить разработчиков УТМ.

Про логи Вы конечно извините - это действительно каменный век.

[DionisK]

Александр Сергеевич, специально зарегистрировался чтобы написать Вам - Вы красавчик!

Все описанное выше Вами действительно имеет место быть, и это чудовищная ошибка.

У нас тоже самое:

на post-запрос c xml <check> УТМ возвращает что-то вроде <A><error>1: Проверка не пройдена: [акцизы] </error><ver>2</ver></A>
При этом продажа реально проходит.

Из логов УТМ можно узнать как такое получилось, например вот как это у нас происходит:

2017-07-26 12:08:10,356 INFO - ID: [87ee639d959fce91] - Получен чек.
2017-07-26 12:08:10,458 INFO - ID: [87ee639d959fce91] - Подпись чека [тип: Bottle, uuid: d7e9eb60-ebdf-403b-816a-6f1f07532bad, касса: 0502899, смена: 1882, чек: 1882, дата: 2607171201]
2017-07-26 12:08:11,510 INFO - ID: [87ee639d959fce91] - Чек подписан [7E4DC05C91ACC3D49A55D0F023FF58580D3ACCEEC505D55C08D9AE9A73F09BCF35838D743D3B55CBB30FC61D873EA8AFC630EE976F184EAFB4241E4F27C44DBE]
2017-07-26 12:08:11,548 INFO - ID: [87ee639d959fce91] - Отправлена квитанция.
2017-07-26 12:08:51,745 INFO - ID: [2f20d06fa774bb5b] - Получен чек.
2017-07-26 12:08:51,860 WARN - ID: [2f20d06fa774bb5b] - Чек уже был подписан [тип: Bottle, касса: 0502899, смена: 1882, чек: 1882, дата: 2607171201]
2017-07-26 12:08:51,871 INFO - ID: [2f20d06fa774bb5b] - Подпись чека [тип: Bottle, uuid: 11a09734-48ed-40e3-b5c3-b70616856f90, касса: 0502899, смена: 1882, чек: 1882, дата: 2607171201]
2017-07-26 12:08:53,044 INFO - ID: [2f20d06fa774bb5b] - Чек подписан [F92651BAF8772CEBA099CAA9ABAE956B0FA6663C1B8E8310AD910281881CCDDFFA6E66A37C21BAF5D10740376E938F59661EC5169DDD8B664DDAA224B907B697]
2017-07-26 12:08:53,057 ERROR - ID: [2f20d06fa774bb5b] - Некорректное состояние транспортного терминала.
2017-07-26 12:08:53,058 ERROR - ID: [2f20d06fa774bb5b] - Отправлена информация об ошибке: [<A><error>1: Проверка не пройдена: 22N00002NS4CKHMTYQK7I7J610180040007457YNY22R3L3X6LI4HEEUIZO8NWO0VZZ8, 22N00002NS4CKHMTYQK7I7J61018004000748IONYTLQF8YUUALL2DHAQMHG7A15U2SV, 22N00002NS4CKHMTYQK7I7J6101800400085420Y1EHF77WJZ81PWV3QINFL7X7XNRJC, 22N00002NS4CKHMTYQK7I7J61018004000860862LBAF8B0H89S24JP877I69X6QITE5, 22N00002NU5DBKYDOT07ID970321014003046RKFB0MONTWV9D3PF4PWKLD3WK4TKIIT, 22N00002NU5DBKYDOT07ID970321014003047BJYFBLRNQREOF1QVT15YSZMCG9DGLJW, 22N00002NU5DBKYDOT07ID970321014003048TJB32CL4V1W0AAFIWH0AR8J6R5VQ1OQ, 22N00002NU5DBKYDOT07ID970321014003049M04DN002IF1UG4G5DPO0SXNOWU8H02H, 22N00002NU5DBKYDOT07ID9703210140030500KU26GLKRF2O68JXPO2HXCBC3V3P9TT, 22N00002NU5DBKYDOT07ID970321014003051QE71U29Z1R1CJ5HEPTBY633XPZFK9Q2</error><ver>2</ver></A>]

что мы видим: утм успешно зарегистрировал продажу, подождал секунд 30-40 и отправил ещё раз такой же запрос, который теперь не прошел (логично) и вернул ошибку.

Система из которой мы отправляем запрос на платформе 1С. В ответ всего на один запрос приходит ошибка (в самом начале поста) и больше ничего.

Господа операторы, есть что сказать по этому поводу?
Возможно проблема из-за промежуточных каких то звеньев (платформа 1с, операционная система и т.д.) ? уж очень не хочется винить разработчиков УТМ.

Про логи Вы конечно извините - это действительно каменный век.

Лично я с подобной ошибкой не сталкивался. Если проверка не пройдена, то нашей 1с:рознице УТМ просто не даст продать, вылетает окно в программе, чек не пробивается.

http://forum.fsrar.ru/viewforum.php?f=116 пишите сюда с предложениями, это официальный форум егаис, если много людей поддержат, то вполне реально, что введут подобную редакцию

[Operator 4]

Проверьте лог на наличие чека в 12:01, так как все марки из данного лога которые не прошли проверку в 12:08 были проданы ранее. Дело в том что ответ о прохождении проверки ,с сервера, возвращается в течение 3-х секунд. Возможно ваша УС ждет ответ быстрее. Если у вас есть такая возможность, вы можете протестировать продажи увеличив время ожидания ответа с сервера в УС.

[alcodream]

про время: у нас утм и компьютер с которого продают на разных машинах - время на утм похоже опережает время на кассе.
Соответственно на кассе когда продавали было время: 12:01, на утм - 12:08
Это может как то повлиять?

По поводу ожидания:
тут вообще не понял, все по стандартам как везде.
Конкретно в 1с 10.3 (у нас) устанавливается новое http-соединение, формируется post-запрос и отправляется на утм через "Попытку" через метод "ОтправитьДляОбработки" с тайм-аутом - 60 секунд.
Ответ через несколько секунд приходит в виде "исключительной ситуации" ("Попытка", "Исключение" - операторы 1с, не знаю как на других языках это выглядит) в которой платформа ретранслирует ответ утм. (см. выше)

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

Не могу понять как в случае описанном выше получилось два запроса с интервалом в пол минуты, второй естественно был ошибочным и ретранслировался 1с-платформой.

Есть здесь независимые технические специалисты - интересно Ваше мнение.

Hеально ли добиться от разработчиков УТМ поменять логику обработки ответов:
можно присылать не "исключительную ситуацию" (ошибки времени выполнения?),а все тот же xml в котором будет блок "error" со всей нужной информацией.

[DionisK]

Hеально ли добиться от разработчиков УТМ поменять логику обработки ответов:
можно присылать не "исключительную ситуацию" (ошибки времени выполнения?),а все тот же xml в котором будет блок "error" со всей нужной информацией.

http://forum.fsrar.ru/viewforum.php?f=116 пишите сюда с предложениями, это официальный форум егаис, если много людей поддержат, то вполне реально, что введут подобную редакцию

[Rubzel]

"Failure when receiving data from the peer" - это системная ошибка связанная с интернет-запросами, может ошибка передачи данных, может сервер ЕГАИС протупил, это неважно откуда она взялась. Но абсолютно согласен с Александром Сергеевичем, если сервер УТМ получил сообщение об ошибки, то и обработать его должен УТМ и передать в УС однозначный результат - прошла продажа или нет. Я не могу бесконечно обучать свою УС обработке каждой новой ошибки в работе УТМ-ЕГАИС.
Есть в конце концов официальные схемы XML, которыми руководствуются программисты УС, соответственно всё что выходит за рамки этих документов это проблемы разработчиков УТМ.
Мы должны сообщить о выявленном "баге" и ждать ОПЕРАТИВНОГО устранения!

[Operator 4]

Приложите лог transport_tranzaction за дату продажи, интересует именно он.

[Александр Сергеевич]

Мы должны сообщить о выявленном "баге" и ждать ОПЕРАТИВНОГО устранения!

Сколько текста было исписано, только все время получаешь заученные одни и те-же фразы (1. Предоставьте лог; 2. Ковыряйтесь в мусоре лога утрированно) .
Если будет больше возмущений думаю будет сдвиг.