Взаимодействие с учетными системами хозяйствующих субъектов

T.Grakhov wrote:

+1

maltsev wrote:да, вроде вчера прошло обновление. Скоро и wsdl по 2.0 выложат, пока только документация для 2.0 под Ветис.API

1) Под документацией следует понимать Подсистема обработки заявок в Ветис.API v2.0?
2) Если док. по версии 2.0 по аналогии с ""Изменения структуры Меркурий v1.5.docx"

Добрый день.
Может быть, кто-нибудь из разработчиков сможет помочь?
Отправляю запрос:

<?xml version="1.0" encoding="UTF-8" ?>
- <soapenv:Envelope xmlns:bs="http://api.vetrf.ru/schema/cdm/base" xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary" xmlns

s="http://www.w3.org/2001/XMLSchema" xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document" xmlns:ws="http://api.vetrf.ru/schema/cdm/application/ws-definitions" xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/applications" xmlns:app="http://api.vetrf.ru/schema/cdm/application" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header />
- <soapenv:Body>
- <ws:submitApplicationRequest>
<ws:apiKey>ZDc5YTNiYmItMjk1MC00N2RiLWExNmMtNzVmMDRjZmU4MTQyYTA2YTljNDAtZGI5Ny00Yzc4LWFkNWMtMzYyYjE3ZjY0NDVj</ws:apiKey>
- <app:application>
<app:serviceId>mercury-g2b.service</app:serviceId>
<app:issuerId>a06a9c40-db97-4c78-ad5c-362b17f6445c</app:issuerId>
<app:issueDate>2017-08-05T15:21:10</app:issueDate>
- <app:data>
- <merc:prepareOutgoingConsignmentRequest>
<merc:localTransactionId>TTN2017-000203279</merc:localTransactionId>
- <merc:initiator>
<dt:login>perelygina-an-170310</dt:login>
</merc:initiator>
- <merc:delivery>
<vd:deliveryDate>2017-08-04T15:49:00</vd:deliveryDate>
- <vd:consignor>
- <dt:businessEntity>
<bs:guid>a06a9c40-db97-4c78-ad5c-362b17f6445c</bs:guid>
<bs:uuid>f012fa20-325c-4a8a-812e-4e9b88df3987</bs:uuid>
</dt:businessEntity>
- <dt:enterprise>
<bs:guid>3acff758-6cf0-4bbe-a6db-51ee46440cb6</bs:guid>
<bs:uuid>3b4e1825-80f4-440d-91c5-e7cbbda3bbe5</bs:uuid>
</dt:enterprise>
<dt:globalID>9863524740194</dt:globalID>
</vd:consignor>
- <vd:consignee>
- <dt:businessEntity>
<bs:guid>fde895e7-218a-11e2-a69b-b499babae7ea</bs:guid>
<bs:uuid>00687e1b-0479-4fe1-a2a7-ab03812a8830</bs:uuid>
</dt:businessEntity>
- <dt:enterprise>
<bs:guid>bcb04861-42d0-4cf7-b7c8-b20e670a48c0</bs:guid>
<bs:uuid>cc6a757c-55ca-42a1-bdbe-0870b5aa92e5</bs:uuid>
</dt:enterprise>
<dt:globalID>9863525440260</dt:globalID>
</vd:consignee>
- <vd:consignment id="fc008815">
<vd:volume>11</vd:volume>
- <vd:unit>
<bs:guid>4a55ffa0-b0a6-4ba5-a841-c0333fcd056b</bs:guid>
<bs:uuid>069795e8-053d-11e1-99b4-d8d385fbc9e8</bs:uuid>
<vd:batchID>fc008815</vd:batchID>
</vd:unit>
- <vd:origin>
- <vd:productItem>
<bs:uuid>9ba584b4-ad4c-4002-85fc-91c4ee6a2e42</bs:uuid>
<bs:guid>8dd8d2c7-ccdb-4ad0-a4e8-7d27d9f490d9</bs:guid>
<dt:globalID />
<dt:name>СОСИСКИ ДЫМОВ МОЛОЧНЫЕ ГОСТ 300Г</dt:name>
<dt:code>UT-00001300</dt:code>
- <dt:packaging>
- <dt:packagingType>
<bs:uuid>069795e8-053d-11e1-99b4-d8d385fbc9e8</bs:uuid>
<dt:globalID>4H</dt:globalID>
<dt:name>Коробка</dt:name>
</dt:packagingType>
<dt:quantity>11</dt:quantity>
<dt:volume>74250</dt:volume>
- <dt:unit>
<bs:guid>4a55ffa0-b0a6-4ba5-a841-c0333fcd056b</bs:guid>
<bs:uuid>069795e8-053d-11e1-99b4-d8d385fbc9e8</bs:uuid>
</dt:unit>
</dt:packaging>
</vd:productItem>
</vd:origin>
<vd:lowGradeCargo>false</vd:lowGradeCargo>
- <vd:packageList>
- <vd:package>
<vd:level>3</vd:level>
- <vd:packingType>
<dt:globalID>4H</dt:globalID>
</vd:packingType>
<vd:quantity>11</vd:quantity>
<vd:productMarks class="UNDEFINED">fc008815</vd:productMarks>
</vd:package>
</vd:packageList>
- <vd:sourceStockEntry>
<bs:uuid>0f76557d-0d60-4147-92b6-3b208a0bc1e3</bs:uuid>
<bs:guid>5279d496-a2e4-49a4-9744-5abb0a267cb0</bs:guid>
</vd:sourceStockEntry>
</vd:consignment>
- <vd:transportInfo>
<vd:transportType>1</vd:transportType>
- <vd:transportNumber>
<vd:vehicleNumber />
</vd:transportNumber>
</vd:transportInfo>
<vd:transportStorageType>FROZEN</vd:transportStorageType>
- <vd:accompanyingForms>
- <vd:waybill for="fc008815">
<vd:issueSeries />
<vd:issueNumber>TTN2017-0002032</vd:issueNumber>
<vd:issueDate>0100-01-01</vd:issueDate>
<vd:type>1</vd:type>
</vd:waybill>
- <vd:vetCertificate for="fc008815">
- <vd:authentication>
- <vd:purpose>
<bs:uuid>b0263721-e974-40db-9153-1dc44746a788</bs:uuid>
<bs:guid>5b90da1b-e089-11e1-bcf3-b499babae7ea</bs:guid>
</vd:purpose>
<vd:cargoInspected>true</vd:cargoInspected>
<vd:cargoExpertized>true</vd:cargoExpertized>
<vd:locationProsperity>местность благополучна</vd:locationProsperity>
<vd:specialMarks>все в норме</vd:specialMarks>
</vd:authentication>
</vd:vetCertificate>
</vd:accompanyingForms>
</merc:delivery>
</merc:prepareOutgoingConsignmentRequest>
</app:data>
</app:application>
</ws:submitApplicationRequest>
</soapenv:Body>
</soapenv:Envelope>

Ответ приходит, что статус "ACCEPTED", и applicationID.

А при попытке получить результаты запроса через receiveApplicationResultRequest возвращается вот такая штука:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<receiveApplicationResultResponse xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
<application xmlns="http://api.vetrf.ru/schema/cdm/application">
<applicationId>91c9d9c1-2475-4ea7-bad8-2e75fc3a1b4c</applicationId>
<status>REJECTED</status>
<serviceId>mercury-g2b.service</serviceId>
<issuerId>a06a9c40-db97-4c78-ad5c-362b17f6445c</issuerId>
<issueDate>2017-08-05T15:21:10.000+03:00</issueDate>
<rcvDate>2017-08-05T15:21:29.000+03:00</rcvDate>
<prdcRsltDate>2017-08-05T15:21:29.000+03:00</prdcRsltDate>
<errors>
<apl:error code="APLM0002" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported application data format</apl:error>
</errors>
</application>
</receiveApplicationResultResponse>
</env:Body>
</env:Envelope>

Вопрос: что именно я делаю не так, и формат ЧЕГО не нравится парсеру?

Залкинд Дмитрий wrote:Добрый день.
Может быть, кто-нибудь из разработчиков сможет помочь?
Отправляю запрос:

.....

Вопрос: что именно я делаю не так, и формат ЧЕГО не нравится парсеру?

Вам повезло, что пришел ответ ACCEPTED. У меня вообще возвращает просто текст моего запроса, когда я пытаюсь отправить его в терминах версии 2.0.

Интересно, у кого-нибудь, на фоне тотального молчания со стороны разработчиков "Меркурия", получилось сделать хоть один успешный запрос в версии 2.0?

Добрый день!

К какому сервису относится операция http://help.vetrf.ru/wiki/GetVetDocumentListOperation_v1.2

SBekrenev wrote:Добрый день!

К какому сервису относится операция http://help.vetrf.ru/wiki/GetVetDocumentListOperation_v1.2

Очевидно, она относится к сервису http://api.vetrf.ru/schema/platform/services/ApplicationManagementService_v1.2_production.wsdl но зачем Вам это старье?
Любопытно, удалось ли кому-то получить ответ по запросу в сервисе v2.0?

Формирую список ВСД getVetDocumentListRequest в 1.5, в результате нет последнего документа, который добавила сегодня в веб-интерфейсе. Делаю то же самое в 1.4 - получаю на один документ больше, сегодняшний ВСД есть. В чем прикол?

nsnt wrote:Формирую список ВСД getVetDocumentListRequest в 1.5, в результате нет последнего документа, который добавила сегодня в веб-интерфейсе. Делаю то же самое в 1.4 - получаю на один документ больше, сегодняшний ВСД есть. В чем прикол?

Добрый день!
Аналогичная ситуация..

Nevzor wrote:

nsnt wrote:Формирую список ВСД getVetDocumentListRequest в 1.5, в результате нет последнего документа, который добавила сегодня в веб-интерфейсе. Делаю то же самое в 1.4 - получаю на один документ больше, сегодняшний ВСД есть. В чем прикол?

Добрый день!
Аналогичная ситуация..

Есть подозрение, что 1.5 колбасит, т.к. мы тоже не можем resolveDiscrepancy-операцией изменить складскую запись со ссылкой на последний UUID. Выдает ошибку, что мол ссылаемся на устаревшую версию складской записи. Но getStockEntryByGuid выдает именно эту версию. Противоречие...

alpsmirnov wrote:Есть подозрение, что 1.5 колбасит, т.к. мы тоже не можем resolveDiscrepancy-операцией изменить складскую запись со ссылкой на последний UUID. Выдает ошибку, что мол ссылаемся на устаревшую версию складской записи. Но getStockEntryByGuid выдает именно эту версию. Противоречие...

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

alpsmirnov wrote:Вам повезло, что пришел ответ ACCEPTED. У меня вообще возвращает просто текст моего запроса, когда я пытаюсь отправить его в терминах версии 2.0.

alpsmirnov wrote:Интересно, у кого-нибудь, на фоне тотального молчания со стороны разработчиков "Меркурия", получилось сделать хоть один успешный запрос в версии 2.0?

alpsmirnov wrote:Любопытно, удалось ли кому-то получить ответ по запросу в сервисе v2.0?

alpsmirnov wrote:Есть подозрение, что 1.5 колбасит

Алексей, не нагнетайте, пожалуйста. Никакого тотального молчания нет, по ошибкам при составлении запросов к 2.0 в скайпе вам написал. По ошибке в 1.5 с актуальной версией записи складского журнала разбираемся.

Залкинд Дмитрий wrote:<apl:error code="APLM0002" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported application data format</apl:error>
Вопрос: что именно я делаю не так, и формат ЧЕГО не нравится парсеру?

Техподдержка получает просто бесконечное количество подобных вопросов. Чтобы сэкономить друг другу время, просьба валидируйте XML по схеме. Это можно сделать, например, с помощью SoapUI или любым другим XML-редактором.
Конкретно в данном случае ошибка в следующем. Application data, т.е. то, что находится внутри тэга <data> заявки, не распознано шлюзом. Т.е. или пространство имён или наименование корневого элемента для содержимого заявки указано некорректно.
Имеем в запросе корневой элемент {http://api.vetrf.ru/schema/cdm/mercury/applications}prepareOutgoingConsignmentRequest, сервис <app:serviceId>mercury-g2b.service</app:serviceId>, т.е. версия форматов 1.4 (по умолчанию). В ХSD для версии 1.4 (http://api.vetrf.ru/schema/platform/mercury/g2b/applications_v1.4.xsd) нет элемента prepareOutgoingConsignmentRequest, корректное название -- prepareOutcomingConsignmentRequest.

T.Grakhov wrote:Уважаемые разработчики!

Не могли бы Вы прямо и четко обозначить сроки начало действия и окончания всех версий api, на боевом и тестовом серверах. И почему бы заранее не оповещать о предстоящих работах на серверах.

Даже Google с Фейсбуком не публикуют такой информации

Версия 1.4 -- последняя в ветке 1.x, возможны только багфиксы. Просуществует на бою, как минимум, до марта 2018.
Версия 1.5 -- по сути является версией 2.0-alpha. С выходом 2.0 отмечена как deprecated, сопровождаться не будет. На пилотном стенде просуществует ещё какое-то время (до последнего клиента), на бой публиковаться не будет.
Версия 2.0 -- опубликована на пилотном сервере 03.08.2017 в статусе beta, документация размещена в справочной системе. В сентябре 2017 планируется публикация 2.x на бой, совместно с 1.4. В настоящее время на пилотном сервере 1.4 и 2.0 работают с единым хранилищем в точно такой конфигурации, которая планируется на бою в сентябре. Так что есть возможность оттестировать совместную работу с 1.4 и 2.0.

Для доступа к 2.0 в ближайшее время (одна-две недели) будут опубликованы форматы данных (XSD) и WSDL, включая адреса endpoint'ов. Просьба набраться терпения.
Доступ к 2.0 можно запросить (по почте) и сейчас, если есть желание включиться в beta-тестирование.

Алексей Тимофеев wrote:

alpsmirnov wrote:Вам повезло, что пришел ответ ACCEPTED. У меня вообще возвращает просто текст моего запроса, когда я пытаюсь отправить его в терминах версии 2.0.

alpsmirnov wrote:Интересно, у кого-нибудь, на фоне тотального молчания со стороны разработчиков "Меркурия", получилось сделать хоть один успешный запрос в версии 2.0?

alpsmirnov wrote:Любопытно, удалось ли кому-то получить ответ по запросу в сервисе v2.0?

alpsmirnov wrote:Есть подозрение, что 1.5 колбасит

Алексей, не нагнетайте, пожалуйста. Никакого тотального молчания нет, по ошибкам при составлении запросов к 2.0 в скайпе вам написал. По ошибке в 1.5 с актуальной версией записи складского журнала разбираемся.

Залкинд Дмитрий wrote:<apl:error code="APLM0002" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported application data format</apl:error>
Вопрос: что именно я делаю не так, и формат ЧЕГО не нравится парсеру?

Техподдержка получает просто бесконечное количество подобных вопросов. Чтобы сэкономить друг другу время, просьба валидируйте XML по схеме. Это можно сделать, например, с помощью SoapUI или любым другим XML-редактором.
Конкретно в данном случае ошибка в следующем. Application data, т.е. то, что находится внутри тэга <data> заявки, не распознано шлюзом. Т.е. или пространство имён или наименование корневого элемента для содержимого заявки указано некорректно.
Имеем в запросе корневой элемент {http://api.vetrf.ru/schema/cdm/mercury/applications}prepareOutgoingConsignmentRequest, сервис <app:serviceId>mercury-g2b.service</app:serviceId>, т.е. версия форматов 1.4 (по умолчанию). В ХSD для версии 1.4 (http://api.vetrf.ru/schema/platform/mercury/g2b/applications_v1.4.xsd) нет элемента prepareOutgoingConsignmentRequest, корректное название -- prepareOutcomingConsignmentRequest.

Алексей, да, прошу прощения. Про тотальное молчание написал еще до того, как получил информацию от Вас. Правда на последние мои вопросы все же ответа не последовало, но я понимаю, что Вам сейчас тоже там нелегко приходится. Сейчас у всех напряженка, т.к. ситуация действительно непростая.

По поводу валидации. У меня тоже возникает ошибка, указанная выше, а также другие, например то, что элементы XML не распознаны, в частности login из структуры initiator.
Думаю, что в версии 1.5 мы не сталкивались с подобными проблемами, потому что на help.vetrf.ru были выложены примеры с заполнением ссылок на все необходимые неймспейсы в элементе <soapenv:Envelope >. По версии 2.0 в документации нет таких документов, а то, что Вы прислали в скайпе (перечислено ниже) является неполным списком всех ссылок на все необходимые неймспейсы. Может, Вы выложите тогда общий пример для всех запросов того, как правильно необходимо оформлять элемент <soapenv:Envelope>, чтобы мы не гадали в чем же действительно заключается проблема, которую мне выдает валидатор SoapUI.
== Зависимости
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/application_v1.1.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/application_ws_definitions_v1.1.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/ApplicationManagementService_v1.1.wsdl
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/base_v1.1.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/base_ws_definitions_v1.1.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/dictionary_v2.0.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/document_v2.0.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/mercury-g2b.service_v2.0.wsdl
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/mercury-vu.service_v2.0.wsdl
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/mercury_g2b_applications_v2.0.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/mercury_vu_applications_v2.0.xsd
http://api.vetrf.ru/schema/platform/services/2.0-RC-last/registry_ws_definitions_v2.0.xsd
В данный момент ни один из моих запросов версии 2.0 не проходит валидацию потому что условный элемент merc:"AnyOperation" не распознается сервисом. Например:

Но вот по этому поводу я от Вас пока не получил ответа со вчерашнего дня.
В любом случае, мы очень ценим любую информацию со стороны разработчиков и очень за нее благодарны!

В версии 2.0 изменились пространства имён, добавился суффикс версии. Пространство http://api.vetrf.ru/schema/cdm/mercury/applications из примера соответствует версии 1.x.
Пространства имён версии 2.0 объявлены в http://api.vetrf.ru/schema/platform/services/2.0-RC-last/mercury_g2b_applications_v2.0.xsd, см. targetNamespace.

Алексей Тимофеев wrote:
Техподдержка получает просто бесконечное количество подобных вопросов. Чтобы сэкономить друг другу время, просьба валидируйте XML по схеме. Это можно сделать, например, с помощью SoapUI или любым другим XML-редактором.
Конкретно в данном случае ошибка в следующем. Application data, т.е. то, что находится внутри тэга <data> заявки, не распознано шлюзом. Т.е. или пространство имён или наименование корневого элемента для содержимого заявки указано некорректно.
Имеем в запросе корневой элемент {http://api.vetrf.ru/schema/cdm/mercury/applications}prepareOutgoingConsignmentRequest, сервис <app:serviceId>mercury-g2b.service</app:serviceId>, т.е. версия форматов 1.4 (по умолчанию). В ХSD для версии 1.4 (http://api.vetrf.ru/schema/platform/mercury/g2b/applications_v1.4.xsd) нет элемента prepareOutgoingConsignmentRequest, корректное название -- prepareOutcomingConsignmentRequest.

Большое спасибо за ответ.