|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: Павел Большаков
Индекс форума » Профиль для Павел Большаков » Сообщения, отправленные пользователем Павел Большаков
Автор Сообщение
dk wrote:
Павел Большаков wrote:В предыдущем моем посте речь о гос. вебе.

Допилим чтобы дополнительно была проверка внутрянки.

Понял, Контур гос веб собрался допиливать? Можем только поддержать инициативу



Вы реально не понимаете что находитесь в теме по мониторингу доступности государственных сервисов? И в чем суть обещанного допила?
По хорошему Вам следует покупать молоко в магазинах, которые смогут оформить вам ВСД, например в Ленте или в Метро (возможно еще кто-то умеет)
Нал/безнал не имеет значения.

Если к вам в кофейню придет роспотребнадзор и попросит предъявить ВСД на молоко, то что вы им покажете? Они тут же вам протокол составят.

Просто сейчас они этим не занимаются. И риски их прихода конкретно к вам (по состоянию на сейчас) в целом маленькие и большинство ими пренебрегает. (Но не все так делают, у нас в офисе кофейня тарится в метро и те исправно делают ВСД)
null
Ап.
https://mercury.kontur.ru/monitoring

А еще можно было узнать о проблеме за 30 минут до официального объявления в этом телеграм канале: https://t.me/mercury_monitoring
+можно было заметить затруднения ещё за 10 минут взглянув на графики https://mercury.kontur.ru/monitoring.

С вебом получилось неочень: Сайт был доступен, просто он внутри не работал. Допилим чтобы дополнительно была проверка внутрянки.
Если там одинаковый номер партии, даты и все остальные реквизиты, то особого криминала я тут не вижу. Но лично я бы забрил и спросил поставщика, не против ли он, если я проконсультируюсь в РСХН, или он все-таки перевыставит нормальный ВСД?
Если это отдельный единичный ВСД Вы можете просто позвонить в ТУ и объяснить ситуацию. Уверен что они разблокируют Вас.
Если откажут (что очень маловероятно) - напишите мне в личку до конца вторника - попробую Вам помочь.
Он никогда и не был обязательным. Требовали только некоторые получатели для автоматизации обработки на своей стороне
Круглова Ольга wrote:
Я так и не поняла есть ли возможность убрать эту регионализацию, чтоб при оформлении ЭВСДэ она не выскакивала. У нас причем колбасная продукция.
Как убрать её?


Её убрать нельзя, это требование системы.

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

В вебе есть специальные расширения для браузера которые кликают вам эти галки.
АнтонКос wrote:А как понять в API какая условность И / ИЛИ? Кто нибудь знает? Потому что в ВЭБе это видно. Там где условие И оно должно быть выполнено, там где условие ИЛИ - должно быть выполнено одно из условий.

http://help.vetrf.ru/wiki/CheckShipmentRegionalizationOperation_v2.0 - внимательно прочитайте комментарии в колонке описание строки номер 017 в блоке Данные ответа. там хорошо написано.

Вам приезжают в разрезе requirement (по болезням) N conditionGroup , которые содержат в себе N condition.
Для удовлетворения требования вы должны понять какая conditionGroup (или все) по каждой болезни у вас выполняются. Внутри conditionGroup логика для condition - И (все условия). но сами conditionGroup для удовлетворения requirement - ИЛИ (хотя бы 1 группа)
И потом при отправке прикладной транзакции перечислить ему все condition из выполняемых групп по каждой болезни. Если что-то забудете - он вам кинет REJECTED на транзакцию.

Для разной продукции список болезней различный.
Группы и условия постоянно меняются.
Danisa wrote:ой а поделитесь секретом как искать не привязанные площадки? Мне один раз сотрудник РСХБ искал сам через свою базу, у меня через контур только по адресу не находит.
Второй вопрос как оформлять такие документы? ТТН должна по идее сходиться с меркурием, а если мы отправим на левую площадку то на основании чего будет грузополучатель?

Какой именно у вас продукт? интеграция(какая версия?)/веб/мобильное приложение?

*В любом случае техподдержка с удовольствием Вам ответит на оба вопроса https://kontur.ru/mercury/support
Заведите шаблон письма, что если не аннулируют ошибочные и не прекратят гасить все подряд без разбору, то вы в такую то дату обратитесь в РСХН, по факту внесения недостоверных сведений в систему. За это банят только в путь.
И рассылайте таким товарищам. Работает в 99%.
Лучше уточнить в РСХН.
Не уверен что регистрация площадки по месту юр. адреса подходит т.к. вы на ней не осуществляете деятельность с поднадзорным товаром.
ИМХО ведение деятельности на самом ПВКП - очень даже походит на правду.
Gala wrote:Запрос а инвентаризацию ушел в 12:53:48, до сервера дошел в 12:54:15, обработан в 12:54:18, а получили обратно в 12:54:47.
<status>COMPLETED</status>
<serviceId>mercury-g2b.service</serviceId>
<issuerId>743bb413-c497-450a-9167-a26ed56c9e9e</issuerId>
<issueDate>2020-05-06T00:00:00+03:00</issueDate>
<rcvDate>2020-05-06T12:54:15+03:00</rcvDate>
<prdcRsltDate>2020-05-06T12:54:18+03:00</prdcRsltDate>

Очень долго, отрабатывало намного быстрее, раз в 5. Теперь по минуте на каждую позицию.
Пинг до сервера шлюза хороший. Что подскажете, можно сделать ?

12:53:48 - это откуда время взято?

У вас разница между rcvDate и prdcRsltDate - 3 секунды. (Это если верить Меркурию) Это очень хороший показатель.

Если предположить, что 12:53:48 - это время создания заявки в вашем решении, а 12:54:15 - время отправки, то Выглядит так, как будто ваше решение (возможно из-за большой очереди заявок или еще каких-то факторов) долго не решало отправить эту заявку. - целых 27 секунд.

далее Мерк думает 3 секунды

После её выполнения в 12:54:18 вы решили запросить результат в 12:54:47
Т.е. спустя 29 сек после того как заявка уже была выполнена.

таким образом из вашего ожидания в 1 минуту меркурий думал всего 3 сек.

А вот почему в конкретно вашем случае ожидание на стороне интеграции составило 56 сек - надо посмотреть на особенности обмена с Ветис у Вас.
Возможно, просто в этот момент было очень много других заявок (возможно не ваших, а другого пользователя), и они оказались более приоритетны чем ваша заявка.
Gala wrote:Шлюз работает очень медленно, что делать, может кто подскажет?

Да вроде у шлюза дела более-менее. https://mercury.kontur.ru/monitoring
У вас в интеграции есть сущность заявка? Там есть информация о времени получения заявки Меркурием и дате формирования ответа?
Валентин п/ф wrote:я рад что вы показываете , нам не легче . тайм аут не у всех настроен на 250 сек . причины этой задержки и сроки восстановления в обычный режим ??

таймаут асинхронной части 250 сек (и тем более меньше) - это ошибка. Верное значение явно более 900 сек. Что у вас за интеграция?
 
Индекс форума » Профиль для Павел Большаков » Сообщения, отправленные пользователем Павел Большаков
Перейти:   

Powered by JForum 2.1.8 © JForum Team