Статус возвратного чека в УТМ : ЕГАИС в опте и рознице

█ 16.03.2023 04:13

Подскажите, если в файле transport_transaction.log
есть записи " Получен ChequeV3
Подпись чека [, transportId: , type: Возврат, касса: *99, смена:*, чек:* , дата: 1503231223]
- Чек подписан
403 INFO transactionLogger - ID: [ ] - Отправлена квитанция." Это же не гарантирует прохождение возврата?
Где именно можно в УТМ увидеть эту квитанцию?

█ 16.03.2023 04:14

Да, наличие записи "Отправлена квитанция" еще не гарантирует, что процесс возврата был завершен успешно.

Чтобы узнать статус возвратного чека и проверить, был ли он успешно обработан системой, можно воспользоваться функцией "Журнал событий" в УТМ.

В этом журнале будут отображаться все события, связанные с данной операцией возврата, включая отправку квитанции.

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

Для удобства можно также использовать специализированные программы для мониторинга операций в УТМ и уведомления о событиях.

█ 16.03.2023 06:54

И какая запись должна быть в журнале УТМа?

█ 16.03.2023 07:30

Отправку чека транспортным модулем на сервер ЕГАИС - смотрите в фале transport_info.log (а не в файле transport_transaction.log), штатный процесс отправки и получения результата должен выглядеть так (УТМ 4.2.0 b2531):

Цитата:

2023-03-15 22:07:52,993 INFO ru.centerinform.transport.backbone.http.controller.workflow.WorkflowChequeController - Получен ChequeV3
2023-03-15 22:07:54,022 INFO ru.centerinform.transport.validate.retail.ChequeV3Handler - [Future] Результат проверки чека: [Проверка пройдена]
2023-03-15 22:07:54,024 INFO ru.centerinform.transport.backbone.http.controller.workflow.WorkflowChequeController - Сохранение данных для последующей отправки: ChequeV3 ...
...
2023-03-15 22:09:02,335 INFO ru.centerinform.transport.backbone.schedule.WSExchangeJob - Начало задачи обмена документами с сервером ЕГАИС по расписанию
2023-03-15 22:09:02,336 INFO ru.centerinform.transport.backbone.schedule.WSExchangeJob - Отправка данных на сервер ЕГАИС по расписанию
2023-03-15 22:09:02,336 INFO ru.centerinform.transport.backbone.schedule.Publisher - Отправка данных на сервер ЕГАИС
2023-03-15 22:09:02,337 INFO ru.centerinform.transport.backbone.schedule.Publisher - Публикация списков тикетов в кол-ве: 1
2023-03-15 22:09:02,579 INFO ru.centerinform.transport.rest.sender.RestSender - Отправка через REST тикет 2d185493-2654-4d2d-88d5-63cd3f727ebf в статусе 0, docType: ChequeV3
2023-03-15 22:09:04,289 INFO ru.centerinform.transport.rest.sender.RestSender - Получен ответ на отправку тикета через RESTful API 200: OK
2023-03-15 22:09:04,289 INFO ru.centerinform.transport.persist.service.TicketService - Удаление тикета c uuid: 2d185493-2654-4d2d-88d5-63cd3f727ebf
2023-03-15 22:09:04,337 INFO ru.centerinform.transport.backbone.schedule.Publisher - Конец публикации данных

Но даже это не может гарантировать отражение продажи/возврата на остатках в ЕГАИС, т.к. на серверной части ЕГАИС периодически даже успешно отправленные чеки "теряются" из-за проблем в архитектуре серверной части ЕГАИС.

█ 16.03.2023 12:35

volk13, Спасибо, такое там видел:

Цитата:

"2023-03-15 17:45:01,306 INFO ru.centerinform.transport.backbone.http.controller.api.v2.ApiRsaController - Поступил запрос на получение информации об организации
2023-03-15 17:45:01,322 WARN ru.centerinform.transport.util.a - Поле [OID.1.2.840.113549.1.9.2] не найдено в сертификате
2023-03-15 17:45:23,730 INFO ru.centerinform.transport.backbone.http.controller.api.v2.ApiRsaController - Поступил запрос на получение информации об организации
2023-03-15 17:45:23,746 WARN ru.centerinform.transport.util.a - Поле [OID.1.2.840.113549.1.9.2] не найдено в сертификате
2023-03-15 17:45:26,111 INFO ru.centerinform.transport.backbone.schedule.WSExchangeJob - Начало задачи обмена документами с сервером ЕГАИС по расписанию
2023-03-15 17:45:26,111 INFO ru.centerinform.transport.backbone.schedule.WSExchangeJob - Отправка данных на сервер ЕГАИС по расписанию
2023-03-15 17:45:26,111 INFO ru.centerinform.transport.backbone.schedule.Publisher - Отправка данных на сервер ЕГАИС
2023-03-15 17:45:26,126 INFO ru.centerinform.transport.backbone.schedule.Publisher - Публикация списков тикетов в кол-ве: 1
2023-03-15 17:45:26,258 INFO ru.centerinform.transport.rest.sender.RestSender - Отправка через REST тикет 00780343-2c7b-42d7-821a-d3707bcb8786 в статусе 0, docType: ChequeV3
2023-03-15 17:45:28,287 INFO ru.centerinform.transport.rest.sender.RestSender - Получен ответ на отправку тикета через RESTful API 200: OK
2023-03-15 17:45:28,287 INFO ru.centerinform.transport.persist.service.TicketService - Удаление тикета c uuid: 00780343-2c7b-42d7-821a-d3707bcb8786
2023-03-15 17:45:28,334 INFO ru.centerinform.transport.backbone.schedule.Publisher - Конец публикации данных
"

думал можно где то сам тикет посмотреть, да и в описании к утм другой кусок, или если отправлять чек первой версии то и должен быть ответ как в документации
:

Цитата:

" УТМ автоматически направляет документ на сервер ЕГАИС и удаляет его из УТМ после
получения из ЕГАИС подтверждения о фиксации чека. Чек зарегистрирован в ЕГАИС
успешно, если в журнале УТМ отображаются следующие события:
Полученo
1
документ(ов)
с
сервера
ЕГАИС:
[[Документ
с
сервера
{fileId=0x5af25e778f8406d7aaf7fe040d977edec43ee956,
replyId=97d7a3d2-f06c-4060-968d-3e6a38974163,
replyDocType=A, dataFile=C:\TT\transporter\xml\ws\95638112-4a86-45a2-b2f2-50933b05e130}]]
2015-11-12 17:37:32,131 INFO es.programador.transport.h.c - Анализ содержимого документов с сервера ЕГАИС,
сопоставление с отправленными документами
2015-11-12
17:37:32,131
INFO
es.programador.transport.h.c
-
Анализ
содержимого
документа
0x5af25e778f8406d7aaf7fe040d977edec43ee956:
[C:\TT\transporter\xml\ws\95638112-4a86-45a2-b2f2-
50933b05e130]
2015-11-12 17:37:32,131 INFO es.programador.transport.h.c - Тип документа - квитанция на чек (Cheque) с UUID
[97d7a3d2-f06c-4060-968d-3e6a38974163]
2015-11-12 17:37:32,131 INFO es.programador.transport.h.c - Содержимое документа: [<?xml version="1.0"
encoding="utf-8"?>
<a id="5068459b-4a89-e511-9e6e-b4b52f6e66dc" />]
2015-11-12 17:37:32,131 INFO es.programador.transport.h.c - Документ Cheque c UUID: [97d7a3d2-f06c-4060-968d-
3e6a38974163] – успешная фиксация на сервереЕГАИС
2015-11-12 17:37:32,131 INFO es.programador.transport.l – Удаление тикета c uuid: 97d7a3d2-f06c-4060-968d-
3e6a38974163
2015-11-12
17:37:32,131
INFO
es.programador.transport.h.c
-
Удаление
временного
файла:
C:\TT\transporter\xml\97d7a3d2-f06c-4060-968d-3e6a38974163
Журнал (лог) УТМ расположен по пути UTM/l/transport_info.log"

?

█ 16.03.2023 12:58

Цитата:

asdr12 ➤ думал можно где то сам тикет посмотреть, да и в описании к утм другой кусок

Какой смысл его (тикет) глядеть, если он содержит лишь uuid?

В логах вся необходимая информация есть, и если в логах есть фраза "Получен ответ на отправку тикета через RESTful API 200: OK" - значит УТМ свою задачу выполнил - отправил успешно чек на сервер (вам же именно это инетересно было).

Всё остальное - ненужные и лишние манипуляции.

Ну а по поводу описания к УТМ - там всегда были неактуальные данные, которые уже устарели, и которые видимо некому вычищать или выправлять со стороны "писателей" документации к УТМ

█ 16.03.2023 13:05

volk13, Задача понять, почему технический возврат не проходит и можно ли повторно пытаться или, если марка одна и та же, то несколько подрояд бутылок точно на баланс не встанут?

█ 16.03.2023 13:16

Задачу разбиваем на части:

1. "Почему технический возврат не проходит"? - потому что скорее всего онлайн проверка не пропускает из-за задержки обработки на серверной стороне прямого чека и из-за разделённых потоков на серверной части ЕГАИС.., это всё смотрится по логу transport_info.log, и в этом случае - УТМ при попытке подписать чек - не вернёт подпись, и соответственно чек отправлен не будет. Анализировать нужно возврат подписи (успех/неуспех), а не на тикет глядеть.

2. "Можно ли повторно пытаться.."? - попытаться что? - отправить повторно прямой чек или чек возврата? Если возвратный не прошёл (см. п.1) - то пытайтесь. Если речь о прямом чеке - то есть вероятность того, что онлайн проверка не сработает и вы отправите дубль марки в ЕГАИС (со всеми вытекающими), поэтому в правильной учётной системе - необходимо предусмотреть контроль дублей на уровне учётной системы, не полагаясь на онлайн проверку УТМ. Только причём тут желание "посмотреть тикет" - непонятно.
Если же онлайн проверка сработает - так опять же (в случае попытки отправить дубль) - чек не будет подписан и УТМ её (подпись) не вернёт (это всё будет отражено в логе, см. п.1)

█ 16.03.2023 13:30

продажа была давно, задача вернуть эту бутылку на баланс, фраза "ок" была(вчера). на баланс бутылка не попала.

█ 16.03.2023 13:35

Цитата:

asdr12 ➤ продажа была давно, задача вернуть эту бутылку на баланс, фраза "ок" была(вчера). на баланс бутылка не попала.

варианты:

1. запросите свежие остатки и проверьте (может быть не на тот алкокод смотрите, т.к. на один и тот же товар (по наименованию) могут меняться алкокоды)... лучше всего проанализируйте сам файл остатков, полученный из УТМ (а не в учётной системе)

2. выше я отметил, что:

Цитата:

volk13 ➤ даже это не может гарантировать отражение продажи/возврата на остатках в ЕГАИС, т.к. на серверной части ЕГАИС периодически даже успешно отправленные чеки "теряются" из-за проблем в архитектуре серверной части ЕГАИС.

в этом случае - пишите в тех.поддержку РАР, приложите чек и логи УТМ и потребуйте исправить.

Интересно будет узнать, чем всё закончилось, просьба сюда сообщить о результатах, спасибо