Сообщения, отправленные пользователем: verleon

verleon wrote:

verleon wrote:А к чему тогда ошибка MERC14460 Для гашения ВСД необходимо внести сведения о транспортном средстве в месте перегрузки?

Мы ее сейчас получаем, если гасим даже без возврата.
В нашем случае была оформлена ВСД с маршрутным листом с перегрузкой в двух точках, в последней все правильно указано - тип транспорта - автомобильный, номера транспорта указаны. А в первой - указано только, что перегрузка и тип - автомобильный, номеров нет. Web-интерфейс такое позволяет, но просто погасить такую ВСД через API нельзя - получаем MERC14460

Через 2 года возвращаюсь к тому же вопросу - он актуален до сих пор. Может кто-нибудь научился через API гасить без возврата ВСД, которая приехала с мультимодальной перевозкой?

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

verleon wrote:А к чему тогда ошибка MERC14460 Для гашения ВСД необходимо внести сведения о транспортном средстве в месте перегрузки?

Мы ее сейчас получаем, если гасим даже без возврата.
В нашем случае была оформлена ВСД с маршрутным листом с перегрузкой в двух точках, в последней все правильно указано - тип транспорта - автомобильный, номера транспорта указаны. А в первой - указано только, что перегрузка и тип - автомобильный, номеров нет. Web-интерфейс такое позволяет, но просто погасить такую ВСД через API нельзя - получаем MERC14460

Через 2 года возвращаюсь к тому же вопросу - он актуален до сих пор. Может кто-нибудь научился через API гасить без возврата ВСД, которая приехала с мультимодальной перевозкой?

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

По-моему это очевидный баг в API.

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

Здравствуйте!
Возникла проблема с ResolveDiscrepancyOperation
Пытаемся на тестовом контуре поставить на баланс вырабатываемою продукцию таким запросом:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
                   xmlns:ws="http://api.vetrf.ru/schema/cdm/application/ws-definitions"
                   xmlns:app="http://api.vetrf.ru/schema/cdm/application">
  <soapenv:Header/>
  <soapenv:Body>
    <ws:submitApplicationRequest>
      <ws:apiKey>XXXXX</ws:apiKey>
      <app:application>
        <app:serviceId>mercury-g2b.service:2.0</app:serviceId>
        <app:issuerId>0a201384-c5c0-4cc6-a0d8-b826dd8e0b65</app:issuerId>
        <app:issueDate>2018-06-15T13:56:44</app:issueDate>
        <app:data>

<merc:resolveDiscrepancyRequest
       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:vd="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
      <merc:localTransactionId>35</merc:localTransactionId>
      <merc:initiator>
       <vd:login>shvecova_oa_171015</vd:login>
      </merc:initiator>
      <merc:enterprise>
        <bs:guid>156bf633-1c9e-44b7-ba2a-8adb9939ab84</bs:guid>
      </merc:enterprise>
      <merc:inventoryDate>2018-06-15T00:00:00</merc:inventoryDate>
      <merc:responsible>
        <vd:login>shvecova_oa_171015</vd:login>
      </merc:responsible>

<merc:stockDiscrepancy id="SM30">
     <vd:resultingList>
       <vd:stockEntry>
         <vd:batch>
           <vd:productType>5</vd:productType>
           <vd:product>
             <bs:guid>8fef4b73-9cc6-46c0-ad88-a5621febf30f</bs:guid>
           </vd:product>
           <vd:subProduct>
             <bs:guid>95d80c33-148c-4865-af4e-c8e5b3de6f5c</bs:guid>
           </vd:subProduct>
           <vd:productItem><bs:guid>77774da2-1e57-47b3-803f-eb0643726c10</bs:guid>
        </vd:productItem>
        <vd:volume>100.000000</vd:volume>
        <vd:unit>
         <bs:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</bs:guid>
        </vd:unit>
        <vd:dateOfProduction>
         <vd:firstDate>
          <dt:year>2018</dt:year>
          <dt:month>6</dt:month>
          <dt:day>15</dt:day>
          <dt:hour>0</dt:hour>
         </vd:firstDate>
        </vd:dateOfProduction>
        <vd:expiryDate>
         <vd:firstDate>
          <dt:year>2018</dt:year>
          <dt:month>6</dt:month>
          <dt:day>16</dt:day>
          <dt:hour>0</dt:hour>
         </vd:firstDate>
        </vd:expiryDate>
        <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>156bf633-1c9e-44b7-ba2a-8adb9939ab84</bs:guid>
                </dt:enterprise>
              <dt:role>PRODUCER</dt:role>
            </vd:producer>
        </vd:origin>
       </vd:batch>
       </vd:stockEntry>
     </vd:resultingList>
    </merc:stockDiscrepancy>

<merc:discrepancyReport for="SM30">
       <vd:reason>
        <vd:name>Излишек</vd:name>
       </vd:reason>
       <vd:description>Акт несоотвествия</vd:description>
    </merc:discrepancyReport>

</merc:resolveDiscrepancyRequest>

</app:data>
      </app:application>
    </ws:submitApplicationRequest>
  </soapenv:Body>
</soapenv:Envelope>

Меркурий вдруг начал отвечать:

<?xml version="1.0" encoding="UTF-8" ?> 
 <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>8be7c2a3-7167-43d7-8192-8eea64da9711</applicationId> 
  <status>REJECTED</status> 
  <serviceId>mercury-g2b.service</serviceId> 
  <issuerId>0a201384-c5c0-4cc6-a0d8-b826dd8e0b65</issuerId> 
  <issueDate>2018-06-15T13:56:44.000+03:00</issueDate> 
  <rcvDate>2018-06-15T09:56:47.000+03:00</rcvDate> 
  <prdcRsltDate>2018-06-15T09:56:47.000+03:00</prdcRsltDate> 
 <errors>
  <apl:error code="APLM0007" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Wrong application data format. Format validation failed due to XML Schema rules: Invalid value '30' for attribute: 'id'</apl:error> 
  </errors>
  </application>
  </receiveApplicationResultResponse>
  </env:Body>
  </env:Envelope>

Такой ответ приходит именно на вырабатываемую продукцию, со входной все нормально. Причем обнаружили пару дней назад, до этого и вырабатываемая нормально отрабатывалсь
В построении запросов вроде ничего не меняли.
Кто-нибудь сталкивался?
Очень похоже, что опять что-то поменяли в API, если заломали - то ладно, есть надежда что исправят (по крайней мере мы с этим ничего сделать не можем), а вот если теперь надо как-то по другому запрос строить - то хотелось бы знать как.

sergmercury wrote:Вот так видимо многие и думают, а программисты Ветис и не дорабатывают ничего опираясь на эту позицию. Вы правда считаете что это правильный подход выгружать весь справочник? Может тогда мне вет.справки всех компаний себе подгружать, а среди них выбирать только нужные? Или справочник всех торговых точек в России, а из них только нужные?

Мне этот справочник весь совершенно не нужен.
Мне нужны только те позиции, по которым мне потребуется отправлять ЭВСД, а их не более тысячи. И если в документации предложили вариант фильтрации, то пусть будут любезны довести его до ума.
В документации даже приведен пример фильтрации, который не работает!

И более всего удивляет подход тех. поддержки Меркурия. Если они знали, что многие начнут переходить на ЭВСД в июне, то могли бы и подготовится к этому. Это что за позиция такая, взять и игнорировать вопросы от пользователей? Ладно бы если все до ума было доведено, тогда можно было как-то оправдать эту позицию.

Там веселее. Фильтры работали (по крайней мере по группе 3-го уровня) до 20 мая. Потом они обновили API и перестало работать.
Так что массовый переход на ЭВСД тут никаким боком. Тупо сломали и не хотят чинить.

loki wrote:я воткнул костыль, при выводе проверяю совпадение гуида 3 уровня.
если не совпадает - не вывожу.
идиотизьм, конечно.
но работать как-то нужно...

Дело в том, что он возвращает на тестовом контуре больше 140 тысяч записей - их еще выкачать надо, чтобы отфильтровать. А что там на продуктиве даже боюсь представить.

Дело даже не в том, кто может этот признак менять. Мы пока в своей системе вообще не даем его менять при гашении - отложили на потом, когда понятно будет, что с ним делать. Отправляем ровно то, что было во входящей ВСД. Но API иногда не принимает этот признак и почему-то считает (100% ошибочно), что он имеет не то значение, которое было во входящей.
И если не отправлять его, хотя продукция некачественная по входящему ВСД, то погасится прекрасно и возвратную ВСД сделает как некачественную (если входящая была некачественная), но - в некоторых случаях. А в некоторых будет ругаться.
Но в каких случаях принимает, а в каких ругается - мы не поняли. Пока понятно только, что при гашении возвратных ВСД этот признак всегда принимается правильно. В транспортных - то принимается, то нет.

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

Извиняюсь, запрос, который я посчитал "новым" на самом деле наоборот старый - от формата 1.4, потому и не проходит (так как пытался отправить его в сервис 2.0.)
Но фильтр в правильном запросе так и не работает

Чего делать-то? Старый запрос не фильтрует теперь ничего. Новый запрос, описанный тут: http://help.vetrf.ru/wiki/GetProductItemList не работает ВООБЩЕ. Ответ на запрос из примера, приведенного там:

А теперь и по SubProduct не работают...

b35 wrote:

verleon wrote:Здравствуйте!
... в ночь на 30 июня ...

вы наверно хотели сказать 30 мая.

Да, конечно, заработался. А конец июня сильно волнует в плане интеграции с Меркурием

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

Пытаемся получить список наименований продукции по продукции (SubProduct)
Делаем такой запрос:

В ответ приходит список ВСЕЙ продукции в Меркурии (судя по всему, не дождался полного выполнения, но точно не отфильтровано по SubProduct)
До обновления 30 мая этот запрос работал правильно.
Вопрос: что-то изменили в запросе, теперь надо что-то еще указывать (Product, ProductType)? Или это ошибка в обновленном API?

Здравствуйте!
После обновления API и интерфейсов в ночь на 30 июня на тестовом контуре возникла проблема с гашением ВСД и постановкой на баланс по непищевой продукции.
Меркурий выдает ошибку MERC24087 Дата окончания срока годности продукции указана неверно.
Судя по интерфейсам теперь срок годности у непищевой продукции указывать не надо, но как это сделать в запросах?
Пытались отправлять ExpiryDate полностью (так как были тестовые входящие ВСД на непищевые продукты с указанным сроком годности), пытались исключать этот элемент из запроса вообще - результат одинаков - MERC24087.
Вопрос - это временная ошибка в API, которую исправят или теперь в запросе нужно что-то особенное указывать про сроки годности непищевых продуктов?