+6
Исправлен

Статус транзакции Переотправить. При этом в web интерфейсе данное эВСД уже отправлено контрагенту

Anastasiya 2 года назад обновлен Ольга К 2 года назад 17

Добрый день, коллеги
В Контур-меркурий пытаемся отправить отранзакцию отгрузки ХП-14742

После отправки транзакции возвращает ошибки и ставит статус "Переотправить транзакцию"

Файлы ответа и запроса прилагаю
При этом при просмотре в Web интерфейсе транзакция отправлена

С чем может быть связана данная ошибка.
Версия модуля Меркурий М8.11.001

+1

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

На рассмотрении

Добрый день.


Обновите модуль до ver. M8.11.004


В данное время функция переотправить, отправляет транзакцию заново.

По этому и появляются дубли.

Перед переотправкой необходимо аннулировать появившиеся ВСД по данной транзакции в ВЭБе.

8.11.50b.

И как-то не очень хочется девочкам на каждый документ ходить в веб интерфейс и аннулировать его. Таких документов 20 штук на смену может быть легко.

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

Мы отловили аналогично дублирование при гашении эВСД. Сейчас заскриним и разместим отдельным топиком. 

По поводу дублирующего отслеживания в web поддерживаю Всеволода. У нас нет ресурса отследить все транзакции в 2х интерфейсах.

+1

Анастасия, Всеволод.

Я Вас прекрасно понимаю. 

Данный функционал обязательно появиться в будущих релизах.

Добрый день!

Всеволод, подскажите данная проблема актуальна на версии M8.12.001, строки по M_DES дублируются?

Я 8.12 еще только на тесте держу. На этой неделе, думаю, поставлю в рабочую базу, потом скажу результат. Но в 8.11.50 такой глюк за сегодня вылез 4 раза. (по крайней мере мне сказали про 4, может и больше было). 

Добрый день,

Всеволод пршу уточнить вопрос решен или нет?

нет. 8.12.01, таких ошибок стало меньше, но они все равно есть.

на всякий случай еще раз уточню. отправляем транзакцию, она висит в обрабатывается. ничего не делаем. через некоторое время "обрабатывается" пропадает (от 1 до 20 минут). Если обработало до 5 минут - практически 100%, что вопросов никаких не будет. Если долго - есть вероятность того, что документ задублируется. на 8.12 такого стало меньше, но все равно за смену пара транзакций попадает. 

Вопрос адресован разработке E1C_in-107539. Статус задачи можете уточнять у технической поддержки

Сейчас, если прошло 2 часа с момента отправки транзакции и мы все равно получаем от Меркурия Статус IN_PROCESS

То такое сообщение считаем зависшим по вине Меркурия.

Статус такого сообщения при обмене будет выставлен "Ошибка проверки статуса" требуемое действие будет выставлено: "Переотправить транзакцию".

В описании ошибки будет указано "Сервер Меркурия уже 2 часа не отвечает на эту заявку. Ждать дальше уже бессмысленно. Следует вручную проверить обработана ли транзакция и либо нажать "Пропустить" (в случае если транзакция прошла успешно) либо нажать "Отправить" (если транзакция не прошла)"

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

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

Я еще раз попробую акцентировать на втором варианте. Отправляем транзакцию, она или (в 95-98% случаев) уходит за пару минут, или зависает в in_process на 30-40 минут. Причем это "сезонно", т.е. у меня автоообмен фоновым заданием раз в 3 минуты, вот в большинстве случаев или все задание обмена обработалось, или (редко) все задание обмена "зависло". В этом задании обмена могут быть от 5 до 15 накладных, и они все становятся в in_process.

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

А какие-то накладные на самом деле прошли, но это видно только в веб интерфейсе.

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

А какой текст ошибки в этих накладных? (которые в Меркурии создались, но в интеграции приехали в "переотправить") Это APLM0012 или другая ошибка?

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

Исправлен

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


если проблема повторится, то необходимо создать новое обращение и отправить логи на почту merc-in@skbkontur.ru

Сервис поддержки клиентов работает на платформе UserEcho