Код ошибки MERC37387

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

Код ошибки - MERC37387 "Пользователь-инициатор запроса обязателен для заполнения"

В запросе инициатор указан, пример отправляемого запроса:
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:submitApplicationRequest xmlns:ns0="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<ns0:apiKey>****</ns0:apiKey>
<ns1:application xmlns:ns1="http://api.vetrf.ru/schema/cdm/application">
<ns1:serviceId>mercury-g2b.service:2.1</ns1:serviceId>
<ns1:issuerId>****</ns1:issuerId>
<ns1:issueDate>2019-06-19T11:48:20.112000</ns1:issueDate>
<ns1:data>
<ns2:getStockEntryListRequest xmlns:ns2="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2">
<ns2:localTransactionId>al</ns2:localTransactionId>
<ns2:initiator>
<ns3:login xmlns:ns3="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">****</ns3:login>
</ns2:initiator>
<ns4:listOptions xmlns:ns4="http://api.vetrf.ru/schema/cdm/base">
<ns4:count>1000</ns4:count>
<ns4:offset>0</ns4:offset>
</ns4:listOptions>
<ns5:enterpriseGuid xmlns:ns5="http://api.vetrf.ru/schema/cdm/dictionary/v2">****</ns5:enterpriseGuid>
<ns2:searchPattern>
<ns6:blankFilter xmlns:ns6="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">NOT_BLANK</ns6:blankFilter>
</ns2:searchPattern>
</ns2:getStockEntryListRequest>
</ns1:data>
</ns1:application>
</ns0:submitApplicationRequest>
</soap-env:Body>
</soap-env:Envelope>

В ответ приходит такое сообщение:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<receiveApplicationResultResponse xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<application xmlns="http://api.vetrf.ru/schema/cdm/application">
<applicationId>****</applicationId>
<status>REJECTED</status>
<serviceId>mercury-g2b.service</serviceId>
<issuerId>****</issuerId>
<issueDate>2019-06-19T11:48:20+03:00</issueDate>
<rcvDate>2019-06-19T09:54:01+03:00</rcvDate>
<prdcRsltDate>2019-06-19T09:54:02+03:00</prdcRsltDate>
<apl:errors xmlns:apl="http://api.vetrf.ru/schema/cdm/application">
<apl:error code="MERC37387">Пользователь-инициатор запроса обязателен для заполнения</apl:error>
</apl:errors>
</application>
</receiveApplicationResultResponse>
</soap:Body>
</soap:Envelope>

Может кто-то сталкивался и знает решение? Или у кого-то есть предположение, как это можно решить?

Проверьте права пользователя на доступ к площадке запрашиваемой записи (через Меркурий.ХС в веб). Если делали работу с пользователями через АПИ, тогда обновите зоны ответственности для пользователя (нужно передать в запросе UpdateUserWorkingAreas все площадки на которые он имеет доступ).

serg882 wrote:Проверьте права пользователя на доступ к площадке запрашиваемой записи (через Меркурий.ХС в веб). Если делали работу с пользователями через АПИ, тогда обновите зоны ответственности для пользователя (нужно передать в запросе UpdateUserWorkingAreas все площадки на которые он имеет доступ).

Спасибо, результат все тот же.
Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"

nmzn1 wrote:

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"

Проверил, действительно прав не было у админа, поставил роль "управление зонами ответственности пользователей" и после успешно привязал через API другого пользователя к площадке, но результат получения складского журнала все тот же - "пользователь-инициатор не указан".

sergmercury wrote:

nmzn1 wrote:

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"

Проверил, действительно прав не было у админа, поставил роль "управление зонами ответственности пользователей" и после успешно привязал через API другого пользователя к площадке, но результат получения складского журнала все тот же - "пользователь-инициатор не указан".

Самый простой способ проверить доступ: зайти в веб ХС на все площадки - Настройки - Настройки зон ответственности - выбрать пользователя - доступные площадки будут окрашены в зеленый цвет.

serg882 wrote:

sergmercury wrote:

nmzn1 wrote:

sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.

а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"

Проверил, действительно прав не было у админа, поставил роль "управление зонами ответственности пользователей" и после успешно привязал через API другого пользователя к площадке, но результат получения складского журнала все тот же - "пользователь-инициатор не указан".

Самый простой способ проверить доступ: зайти в веб ХС на все площадки - Настройки - Настройки зон ответственности - выбрать пользователя - доступные площадки будут окрашены в зеленый цвет.

Проверил и веб интерфейсе, с правами все в порядке, спасибо. Но ошибка возникает все равно, думаю все же проблема в другом.

Возможно начали блокировать пользователей без СНИЛСА и телефона.

serg882 wrote:Возможно начали блокировать пользователей без СНИЛСА и телефона.

СНИЛС был прописан, а телефон вот старый стоял, поменял на новый, но и это не помогло))
А так-то эти мастера могут подобное осуществить, даже не сомневаюсь, но думаю если бы забанили, то вообще ничего не отправлялось бы, а так одна на сотню вет. справка отправляется. Что вообще недоумение вызывает. Вчера вот с теми же данными, нормально работало. На прошлой неделе смена шлюза с 2.0 на 2.1 помогла исправить эту ошибку, теперь уже не работает и шлюз 2.1.

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

sergmercury wrote:На прошлой неделе смена шлюза с 2.0 на 2.1 помогла исправить эту ошибку, теперь уже не работает и шлюз 2.1

может опять попробовать 2.0

nmzn1 wrote:

sergmercury wrote:На прошлой неделе смена шлюза с 2.0 на 2.1 помогла исправить эту ошибку, теперь уже не работает и шлюз 2.1

может опять попробовать 2.0

Да уж пробовали и 2.1. и 2.0 и без цифр и в латинской, и в русской, и в китайской раскладке и даже в запросе писали: "умоляем отправься во славу великого Меркурия" - ничего не меняется. Поддержка отвечает, что разбираются... Сами не знают, что у них там вообще происходит. Бардак, как обычно.

Ты точно хотя бы раз в жизни слышал словосочетание «ретроградный Меркурий», но вряд ли знаешь, что это такое. Объясняем!

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

Думаю дело в этом...

Здравствуйте!

Мы разобрались в возникшей проблеме и отправили Вам ответ с рекомендациями по её решению.
Однако, позвольте прояснить следующее:
1. Вы обратились в техническую поддержку позже, чем на форум
2. В изначальном сообщении вы не прислали ни единого идентификатора, по которому можно было бы опознать запрос и найти его в логах.
3. Уточните, пожалуйста, с какой целью вы отправляете в адрес технической поддержки письма одинакового содержания с частотой от получаса до минуты?

Егорова Ирина wrote:Здравствуйте!

Мы разобрались в возникшей проблеме и отправили Вам ответ с рекомендациями по её решению.
Однако, позвольте прояснить следующее:
1. Вы обратились в техническую поддержку позже, чем на форум
2. В изначальном сообщении вы не прислали ни единого идентификатора, по которому можно было бы опознать запрос и найти его в логах.
3. Уточните, пожалуйста, с какой целью вы отправляете в адрес технической поддержки письма одинакового содержания с частотой от получаса до минуты?

1. Какая разница куда я там позже обратился, куда раньше, следите и за почтой и за форумом, люди ищут здесь вашей помощи.
2. В ответном сообщении я отправил необходимую вам информацию. И на ваше письмо я ответил спустя 3 минуты после того как получил ваше письмо. А вашего ответа не получил, ни по времени ожидания, ни подтверждения о получении письма. Научитесь вести обратную связь, а не отмалчиваться.
3. Столько писем я вам отправляю, потому что вы на них не отвечаете своевременно и не даете обратной связи. В прошлый раз вы ответили только через полгода. Я вас тормошу, чтобы вы там не забывали о моей проблеме. Более того я вам и звонил и в случае чего готов звонить по 500 раз, чтобы вы там шевелились.

И последнее, ответ меня ваш убил наповал, вам я отписал уже свое мнение об этой ситуации.
И ниже для других пользователей привожу ответ, чтобы в случае чего остальные могли быстро найти проблему.
Ребята, это просто трэш

:
"Причиной ошибки является наименование имя префикса ns0. Как временное решение техническая поддержка рекомендует сменить его на любое другое, например, на apl. В этом случае проблема уйдёт. Данные об инциденте переданы разработчикам.
Приносим извинения за причинённые неудобства."
Слов нет.

Год мы нормально отправляли запросы с этим ns0 и не знали проблем, это надо же было так умудрится исправить систему, что она стала некорректно реагировать на этот ns0.
С чем это связано вообще?

Здравствуйте.
Аналогичная проблема с ns0, только помимо указанного выше метода(методы Журнала Продукции), проявляется еще и на методе GetVetDocumentByUuidOperation:
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns0:submitApplicationRequest xmlns:ns0="http://api.vetrf.ru/schema/cdm/application/ws-definitions" xmlns:ns2="http://api.vetrf.ru/schema/cdm/application">
<ns0:apiKey>*****</ns0:apiKey>
<ns2:application xmlns:ns1="http://api.vetrf.ru/schema/cdm/base" xmlns:ns6="http://api.vetrf.ru/schema/cdm/base/ws-definitions" xmlns:ns5="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
<ns2:serviceId>mercury-g2b.service</ns2:serviceId>
<ns2:issuerId>*****</ns2:issuerId>
<ns2:issueDate>2019-07-05T17:05:38.046+03:00</ns2:issueDate>
<ns2:data>
<ns4:getVetDocumentByUuidRequest xmlns:ns4="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2" xmlns:ns3="http://api.vetrf.ru/schema/cdm/dictionary/v2">
<ns4:localTransactionId>*****</ns4:localTransactionId>
<ns4:initiator>
<ns5:login>*****</ns5:login>
</ns4:initiator>
<ns1:uuid>*****</ns1:uuid>
<ns3:enterpriseGuid>*****</ns3:enterpriseGuid>
</ns4:getVetDocumentByUuidRequest>
</ns2:data>
</ns2:application>
</ns0:submitApplicationRequest>
</S:Body>
</S:Envelope>

Ответ:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<receiveApplicationResultResponse xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<application xmlns="http://api.vetrf.ru/schema/cdm/application">
<applicationId>*****</applicationId>
<status>REJECTED</status>
<serviceId>mercury-g2b.service</serviceId>
<issuerId>*****</issuerId>
<issueDate>2019-07-05T17:05:38+03:00</issueDate>
<rcvDate>2019-07-09T11:41:43+03:00</rcvDate>
<prdcRsltDate>2019-07-09T11:41:44+03:00</prdcRsltDate>
<apl:errors xmlns:apl="http://api.vetrf.ru/schema/cdm/application">
<apl:error code="MERC29222">Идентификатор ветеринарно-сопроводительного документа (UUID) обязателен для заполнения.</apl:error>
</apl:errors>
</application>
</receiveApplicationResultResponse>
</soap:Body>
</soap:Envelope>

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

В ходе переписки, тоже предлагали следующие решения:
1. Заменить ns0 на любое другое имя. Уж точно не решение, а обходной путь.
2. Проявляется только на тестовом контуре. Странно, но тот кто разрабатывает все с нуля, то логично, что нужно все проводить на тестовом сервере.

Некоторые специалисты техподдержки и вовсе говорили, что все работает в порядке и нет никаких обращений по данному поводу, - зайдя на форум убедился, что не я один такой.

Вопрос с решением ns0 крайне важен, так как общем случае, уверен, что большинство разработчиков не берут на себя ответственность за сам механизм формирования и отправки запроса на сервер - используют необходимые библиотеки предназначенные для этого. В моем случае JAXWS, где значительно упрощается работа с протоколом SOAP.

PS:
Как долго будет обрабатываться инцидент?
Почему бы не поставить в известность техподдержку о существующей проблеме? Чтобы не создавать инцидентов по каждому обращению, а они, я так понимаю, - есть.
Конечно, есть и положительные моменты, особенно в работающих методах, при чем, как ни странно в них проходит ns0.