Гашение ВСД через API

Пытаюсь на продуктиве погасить ВСД, использую вторую версию
шапка запроса на гашение:

<SOAP-ENV:Envelope xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2" 
  xmlns:bs="http://api.vetrf.ru/schema/cdm/base" 
  xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2" 
  xmlns:apldef="http://api.vetrf.ru/schema/cdm/application/ws-definitions" 
  xmlns:apl="http://api.vetrf.ru/schema/cdm/application" 
  xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2" 
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header/>
  <SOAP-ENV:Body>
    <apldef:submitApplicationRequest>
      <apldef:apiKey>XXXXXXXX</apldef:apiKey>
      <apl:application>
        <apl:serviceId>mercury-g2b.service:2.0</apl:serviceId>
        <apl:issuerId>ХС_UUID</apl:issuerId>
        <apl:issueDate>2017-12-14T19:27:45</apl:issueDate>
        <apl:data>
          <merc:processIncomingConsignmentRequest>
            <merc:localTransactionId>IDENTITY</merc:localTransactionId>
            <merc:initiator>
              <vd:login>LOGIN</vd:login>
            </merc:initiator>

возвращается следующая ошибка

В чем проблема ошибки???

Надо не UUID, а GUID.

да гуид там, поторопился

Разобрались в чем ошибка?
у меня тоже, в тестовой среде
<receiveApplicationResultResponse xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions"><application xmlns="http://api.vetrf.ru/schema/cdm/application"><applicationId>4511a147-8a06-42e3-80da-859ff82bc250</applicationId><status>REJECTED</status><serviceId>mercury-g2b.service</serviceId><issuerId>2d9d2f7e-4978-46a4-ae67-004f5977393a</issuerId><issueDate>2018-03-29T09:33:47.000+03:00</issueDate><rcvDate>2018-03-29T09:33:48.000+03:00</rcvDate><prdcRsltDate>2018-03-29T09:33:48.000+03:00</prdcRsltDate><errors><apl:error xmlns:apl="http://api.vetrf.ru/schema/cdm/application" code="APLM0017">An unexpected error has occurred while processing target service response.</apl:error></errors></application></receiveApplicationResultResponse>

в чем может быть проблема?
Сам запрос
<SOAP-ENV:Envelope xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2"
xmlns:bs="http://api.vetrf.ru/schema/cdm/base"
xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2"
xmlns:apldef="http://api.vetrf.ru/schema/cdm/application/ws-definitions"
xmlns:apl="http://api.vetrf.ru/schema/cdm/application"
xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<apldef:submitApplicationRequest xmlns:apl="http://api.vetrf.ru/schema/cdm/application"
xmlns:apldef="http://api.vetrf.ru/schema/cdm/application/ws-definitions"
xmlns:bs="http://api.vetrf.ru/schema/cdm/base"
xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2"
xmlns:merc="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2" xmlns:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2"><apldef:apiKey>ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ</apldef:apiKey><apl:application><apl:serviceId>mercury-g2b.service:2.0</apl:serviceId><apl:issuerId>2d9d2f7e-4978-46a4-ae67-004f5977393a</apl:issuerId><apl:issueDate>2018-03-29T10:44:31</apl:issueDate><apl:data><merc:processIncomingConsignmentRequest><merc:localTransactionId>0000000165</merc:localTransactionId><merc:initiator><vd:login>skornjakov_ei_171001</vd:login></merc:initiator><merc:delivery><vd:deliveryDate>2018-03-28T10:14:27</vd:deliveryDate><vd:consignor><dt:businessEntity><bs:guid>2d9d2f7e-4978-46a4-ae67-004f5977393a</bs:guid></dt:businessEntity><dt:enterprise><bs:guid>39695e2d-e4fe-4a10-8f9a-21b6e7e85c10</bs:guid></dt:enterprise></vd:consignor><vd:consignee><dt:businessEntity><bs:guid>2d9d2f7e-4978-46a4-ae67-004f5977393a</bs:guid></dt:businessEntity><dt:enterprise><bs:guid>7640f020-070a-4770-a8e9-54a0decb94bc</bs:guid></dt:enterprise></vd:consignee><vd:consignment><vd:productType>7</vd:productType><vd:product><bs:guid>3c8757a3-7c47-f420-b1b4-35521981dadf</bs:guid></vd:product><vd:subProduct><bs:guid>68c0e227-092e-31f3-5771-25adcacd778e</bs:guid></vd:subProduct><vd:productItem><bs:guid>21fcc36d-b760-4e05-aadc-83db19e102eb</bs:guid><dt:name>Камбала б/г.потр.охлаж. 500 -/ 0,5-1,2 кг</dt:name></vd:productItem><vd:volume>100.0</vd:volume><vd:unit><bs:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</bs:guid></vd:unit><vd:dateOfProduction><vd:firstDate><dt:year>2017</dt:year><dt:month>11</dt:month><dt:day>22</dt:day><dt:hour>00</dt:hour></vd:firstDate></vd:dateOfProduction><vd:expiryDate><vd:firstDate><dt:year>2017</dt:year><dt:month>12</dt:month><dt:day>22</dt:day><dt:hour>00</dt:hour></vd:firstDate></vd:expiryDate><vd:batchID>KAMBALA1</vd:batchID><vd:perishable>false</vd:perishable><vd:origin><vd:country><bs:guid>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</bs:guid></vd:country><vd:producer><dt:enterprise><bs:guid>39695e2d-e4fe-4a10-8f9a-21b6e7e85c10</bs:guid></dt:enterprise><dt:role>PRODUCER</dt:role></vd:producer></vd:origin><vd:lowGradeCargo>false</vd:lowGradeCargo></vd:consignment><vd:transportInfo><vd:transportType>1</vd:transportType><vd:transportNumber><vd:vehicleNumber>А111МР77</vd:vehicleNumber></vd:transportNumber></vd:transportInfo><vd:transportStorageType>VENTILATED</vd:transportStorageType><vd:accompanyingForms><vd:vetCertificate><bs:uuid>1db6c69b-e7be-4249-9653-dd805c407d0a</bs:uuid></vd:vetCertificate></vd:accompanyingForms></merc:delivery><merc:deliveryFacts><vd:vetCertificatePresence>ELECTRONIC</vd:vetCertificatePresence><vd:docInspection><vd:responsible><vd:login>skornjakov_ei_171001</vd:login></vd:responsible><vd:result>CORRESPONDS</vd:result></vd:docInspection><vd:vetInspection><vd:responsible><vd:login>skornjakov_ei_171001</vd:login></vd:responsible><vd:result>CORRESPONDS</vd:result></vd:vetInspection><vd:decision>ACCEPT_ALL</vd:decision></merc:deliveryFacts></merc:processIncomingConsignmentRequest></apl:data></apl:application></apldef:submitApplicationRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

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

Повторно все равно тоже самое, попробовал погасить в продуктивном контуре, такая же ошибка. Сдается мне не в сервере дело.

Меркурий при приходной операции входящего эВСД заявку отклоняет, с ошибкой "MERC14585 Тип ТТН в сведениях о принимаемой партии должен совпадать с указанным в ветеринарно-сопроводительном документе." В Вебе все нормально гасится, кто нибудь сталкивался с этой ошибкой?

PS. Ошибочку нашел

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

Banzaai wrote:Добрый день,
подскажите поле блок waybill при гашении, что в нем указывается?

http://help.vetrf.ru/wiki/IncomingOperation#.D0.9E.D0.B1.D1.8A.D0.B5.D0.BA.D1.82_..Request.2Fdelivery.2FaccompanyingForms

Banzaai wrote:Добрый день,
подскажите поле блок waybill при гашении, что в нем указывается?

Скорее всего вам приехал ВСД где ТТН отсутствует. (знаете наверное этот новый переключатель - так вот, это он был задействован при оформлении)
Такие ВСД мне так и не удалось погасить в 2.0 как я не изворачивался с блоком waybill (и даже указание другого номера и даты ТТН + mismatch не дают погасить ВСД)

Полностью погасить ВСД удалось, спасибо

подскажите
Перемещение без смены владельца, с одной своей площадки на другую
Ошибка

<?xml version="1.0"?>
<receiveApplicationResultResponse xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions"><application xmlns="http://api.vetrf.ru/schema/cdm/application"><applicationId>9e0f85ea-fb7a-4c11-89b2-54e63b1eaa6e</applicationId><status>REJECTED</status><serviceId>mercury-g2b.service</serviceId><issuerId>d9a70617-38d3-4789-893e-cd5706a06bea</issuerId><issueDate>2018-04-05T15:51:33.000+03:00</issueDate><rcvDate>2018-04-05T15:51:36.000+03:00</rcvDate><prdcRsltDate>2018-04-05T15:51:36.000+03:00</prdcRsltDate><errors><apl:error xmlns:apl="http://api.vetrf.ru/schema/cdm/application" code="MERC15027">В сведениях о возврате продукции предприятие-производитель с указанным идентификатором не найдено в реестре РСХН, либо идентификатор не соответствует установленному формату.</apl:error></errors></application></receiveApplicationResultResponse>

при запросе
</vd:dateOfProduction><vd:expiryDate><vd:firstDate><dt:year>2018</dt:year><dt:month>4</dt:month><dt:day>8</dt:day></vd:firstDate></vd:expiryDate><vd:perishable>false</vd:perishable><vd:origin><vd:productItem><dt:name>Лангет из говядины 1/350 г</dt:name></vd:productItem><vd:country><bs:uuid>72a84b51-5c5e-11e1-b9b7-001966f192f1</bs:uuid><bs:guid>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</bs:guid></vd:country><vd:producer><dt:enterprise><bs:uuid>6ad34954-5fb7-4c81-95d1-4d8c2cbc17cd</bs:uuid><bs:guid>0bc7f295-b994-4a46-8346-aff1d99310d5</bs:guid></dt:enterprise><dt:role>PRODUCER</dt:role></vd:producer></vd:origin><vd:lowGradeCargo>false</vd:lowGradeCargo></vd:consignment><vd:transportInfo><vd:transportType>1</vd:transportType><vd:transportNumber><vd:vehicleNumber>К735РА177</vd:vehicleNumber></vd:transportNumber></vd:transportInfo><vd:transportStorageType>FROZEN</vd:transportStorageType><vd:accompanyingForms><vd:waybill><vd:issueNumber>4508</vd:issueNumber><vd:issueDate>2018-04-02</vd:issueDate><vd:type>1</vd:type></vd:waybill><vd:vetCertificate><vd:authentication><vd:purpose><bs:uuid>19cefc1b-743a-4f6f-8368-177c3bd0dc79</bs:uuid><bs:guid>5b90da1b-e089-11e1-bcf3-b499babae7ea</bs:guid></vd:purpose><vd:cargoInspected>false</vd:cargoInspected><vd:cargoExpertized>UNFULFILLED</vd:cargoExpertized><vd:locationProsperity>Местность благополучна по заразным болезням животных</vd:locationProsperity></vd:authentication></vd:vetCertificate><vd:relatedDocument><vd:issueNumber>4508</vd:issueNumber><vd:issueDate>2018-04-02</vd:issueDate><vd:type>1</vd:type><vd:relationshipType>1</vd:relationshipType></vd:relatedDocument><vd:relatedDocument><vd:issueNumber>36095448</vd:issueNumber><vd:issueDate>2018-04-02</vd:issueDate><vd:type>16</vd:type><vd:relationshipType>6</vd:relationshipType></vd:relatedDocument></vd:accompanyingForms></merc:returnedDelivery></merc:processIncomingConsignmentRequest></apl:data></apl:application></apldef:submitApplicationRequest>

Проверяли, GUID такой есть в блоке enterprise в блоке returned delivery., мы его наследуем из входящего ВСД. В чем может быть ошибка?

Павел Большаков wrote:

Banzaai wrote:Добрый день,
подскажите поле блок waybill при гашении, что в нем указывается?

Скорее всего вам приехал ВСД где ТТН отсутствует. (знаете наверное этот новый переключатель - так вот, это он был задействован при оформлении)
Такие ВСД мне так и не удалось погасить в 2.0 как я не изворачивался с блоком waybill (и даже указание другого номера и даты ТТН + mismatch не дают погасить ВСД)

Если нет по ТТН - то waybill указываю пустой - все гасится без проблем

СергейА wrote:

Павел Большаков wrote:

Banzaai wrote:Добрый день,
подскажите поле блок waybill при гашении, что в нем указывается?

Скорее всего вам приехал ВСД где ТТН отсутствует. (знаете наверное этот новый переключатель - так вот, это он был задействован при оформлении)
Такие ВСД мне так и не удалось погасить в 2.0 как я не изворачивался с блоком waybill (и даже указание другого номера и даты ТТН + mismatch не дают погасить ВСД)

Если нет по ТТН - то waybill указываю пустой - все гасится без проблем

Не всегда. Видимо, это была временная ошибка. Отправитель через веб указывал данные о ТТН, а через api мы эти данные получали или пустыми или корявыми. Никакие варианты с ветками не помогали. Сейчас вроде такого уже нет.
Осталась пока только проблема с маркировкой/клеймом. Получить его через api не получается. Нашел выход - смотрю маркировку через веб и заношу её вручную при гашении. Такой вариант проходит. Кроме одной мелочи - маркировка задваивается.

anig99 wrote:

СергейА wrote:

Павел Большаков wrote:

Banzaai wrote:Добрый день,
подскажите поле блок waybill при гашении, что в нем указывается?

Скорее всего вам приехал ВСД где ТТН отсутствует. (знаете наверное этот новый переключатель - так вот, это он был задействован при оформлении)
Такие ВСД мне так и не удалось погасить в 2.0 как я не изворачивался с блоком waybill (и даже указание другого номера и даты ТТН + mismatch не дают погасить ВСД)

Если нет по ТТН - то waybill указываю пустой - все гасится без проблем

Не всегда. Видимо, это была временная ошибка. Отправитель через веб указывал данные о ТТН, а через api мы эти данные получали или пустыми или корявыми. Никакие варианты с ветками не помогали. Сейчас вроде такого уже нет.
Осталась пока только проблема с маркировкой/клеймом. Получить его через api не получается. Нашел выход - смотрю маркировку через веб и заношу её вручную при гашении. Такой вариант проходит. Кроме одной мелочи - маркировка задваивается.

На данный момент, если приходят странные данные - есть дата, но нет серии и номера - то надо делать акт несоответствия, а если нет ни даты, ни серии ни номера - то можно передавать пустые данные - все отлично гасится
С маркировкой пока не сталкивался.
Но вот есть проблема с производителями, указано 11, у трех роль "UNKNOWN" и если указать все как есть в ВСД - то выкидывает ошибку - что не все роли корректно указаны, если им назначить другую роль - то та же ошибка, если их не указывать - то ошибка - не все производители указаны. И как бы я не старался, каким бы бубном не стучал - ничего не помогает - не могу погасить и все тут

Проблему гашения с пустым номером ТТН починили вместе с 6.6 6го апреля.