|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: vld
Индекс форума » Профиль для vld » Сообщения, отправленные пользователем vld
Автор Сообщение
Егорова Ирина wrote:
несколько дней назад в ответах ветиса (API) сменился формат блока ошибки, если ранее он был, к примеру таким:
Это не дефект, а внутренние технические изменения, которые не должны влиять на работоспособность интеграционного решения. При необходимости с уточняющими вопросами Вы можете обратиться на почту api@vetrf.ru



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

<errors>
<apl:error xmlns:apl="http://api.vetrf.ru/schema/cdm/application" code="MERC14091">Объём в сведениях о принимаемой партии указан неверно.</apl:error>
</errors>

Интеграционное решение зависит от этого, так как пути для разбора XML меняются.

Спасибо
несколько дней назад в ответах ветиса (API) сменился формат блока ошибки, если ранее он был, к примеру таким:
<errors>
<apl:error xmlns:apl="http://api.vetrf.ru/schema/cdm/application" code="MERC14268">Ветеринарно-сопроводительный документ должен быть в состоянии "оформлен" (т.е. не погашен).</apl:error>
</errors>

то сейчас namespace переехал в другое место:

<apl:errors xmlns:apl="http://api.vetrf.ru/schema/cdm/application">
<apl:error code="MERC14256">Так как номер транспортного средства в сведениях о принимаемой партии не совпадает с указанным в ветеринарно-сопроводительном документе, то необходимо указать причину в акте о несоответствии.</apl:error>
</apl:errors>

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

Ситуация вообще то нехорошая - из документации следует, что поле globalID для описания товара - не является обязательным - я его при гашении и не посылаю, а Ветис ругается, видимо, на исходный ВСД - в котором указан кривой шк - у него контрольная цифра кривая - но так пришло от поставщика. При сопоставлении с хорошими всд от этого же поставщика видно, что в других случаях контролька верная - поэтому гашение проходит. Вообще странная ситуация - зафиксировать у себя ВСД (в Меркурии), а потом при попытке погасить - говорить - ай-ай-ай, код-то неверный - конечно неверный, только зачем же было такой у себя сохранять???
Хм. Спасибо, нужно проверить
Печально
Это возможно, в схемах наверняка есть ошибки, удивляет только, что все практически идентично - но в одном случае все норм, в другом - нет.
Обычно если по схеме не проходит, то в валидации ошибка появляется немного другого вида, значительно раньше, еще не доходя до анализа фактических данных -
тут же на мой взгляд видно, что валидация по схеме уже прошла - проблем проявляется дальше. У меня подозрение такое, что данные, которые в исходном ВСД
пришли, не отражают фактические данные, с которыми при попытке гашения работает API - как это было, например, с типом сопроводительных документов - когда в
электронном виде приходил тип 1, а по факту в WEB-интерфейсе - стояло 5.
Проблема возникает при частичном гашении с оформлением возвратного ВСД - только в одном случае все хорошо, во втором - нет
Нет, дело не в этом. На руках имеются 2 ВСД, который погашен и тот. что нет.
Исходные "хороший" и "плохой" ВСД практически идентичны за исключением продукции - и в части сопроводительных документов - и в части других значимых параметров.
Практически идентичны и xml, которые отсылались при гашении - видимо дело в чем-то другом.
Спасибо! Попробую посмотреть, что было в исходном ВСД
День добрый!
Вы не разобрались в чем была проблема?
У меня возникает тоже самое - неясно в чем причина
Вы удивитесь, но по всей видимости эта ошибка уже давнишняя, она возникла на днях у нас тоже - причина очень простая - тип документа в данных по ВСД (getVetDocumentListRequest) - для данного конкретного ВСД - НЕ ТОТ, что в Web-интерфейсе. Так, у нас во входящем XML со списком - 1 тип, а в Web - 5 тип. Поэтому догадаться, какой вы должны проставить тип при гашении - вам не удастся, пока все типы не переберете. В новости о внедрении версии API 2.1 (http://vetrf.ru/vetrf/news/26806.html) сказано:

>>- исправлен дефект, в результате которого в ответе
>>сервиса на запрос изменений в ВСД (операция
>>getVetDocumentChangesList) тип сопроводительного
>>документа (ТТН) мог возвращаться неверно.

Фактически такая ошибка содержится и в запросе getVetDocumentListRequest в текущей версии шлюза 2.0, вот только вопрос - будет ли кто-то ее исправлять?
В дополнении к сообщению о GetProductItemList в продуктиве:

В справке http://help.vetrf.ru/wiki/GetProductItemList_v2.0 сказано:

"Операция GetProductItemList предназначена для получения списка наименований продукции с возможностью фильтрации по
уровням продукции иерархического справочника, по номенклатуре определенного предприятия-производителя или всех предприятий
определенного хозяйствующего субъекта"

Методом проб и ошибок получено, что запрос отрабатывает только

1. по уровням иерархического справочника безотносительно ХС и ПЛ
2. по ПЛ, правда пока не удалось получить непустой результат.

по ХС, если его указывать в тэгах <dt:businessEntity><bs:guid>, запрос нормально не работает - возвращает все подряд.
Ну что сказать, это просто какой-то позор....

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

1. в формате передачи дат производства и сроков годности. В руководстве http://help.vetrf.ru/wiki/ProcessIncomingConsignment_v2.0#.D0.A1.D1.86.D0.B5.D0.BD.D0.B0.D1.80.D0.B8.D0.B9_1.1.1._.D0.A1.D0.B2.D0.B5.D0.B4.D0.B5.D0.BD.D0.B8.D1.8F_.D0.B2.D0.BE_.D0.B2.D1.85.D0.BE.D0.B4.D1.8F.D1.89.D0.B5.D0.BC_.D0.92.D0.A1.D0.94_.D1.81.D0.BE.D0.BE.D1.82.D0.B2.D0.B5.D1.82.D1.81.D1.82.D0.B2.D1.83.D1.8E.D1.82_.D1.84.D0.B0.D0.BA.D1.82.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.BC.2C_.D0.BF.D0.B0.D1.80.D1.82.D0.B8.D1.8F_.D0.BF.D1.80.D0.B8.D0.BD.D0.B8.D0.BC.D0.B0.D0.B5.D1.82.D1.81.D1.8F_.D0.B2_.D0.BF.D0.BE.D0.BB.D0.BD.D0.BE.D0.BC_.D0.BE.D0.B1.D1.8A.D0.B5.D0.BC.D0.B5.
по ProcessIncomingConsignment v2.0 сказано, что передача часов и минут является необязательной для скоропорта - так вот, это не так - они требуются, первый блин, так сказать.

2. оказалось, что страну - производителя и собственно производителя НЕЛЬЗЯ просто так взять и написать, как это следует из свойств товара - только так, как было во входящем ВСЭД. В нашем примере был товар - российского производства, для него НЕЛЬЗЯ указывать его реального производителя, поскольку такой не приходил с ВСЭД. Поскольку приходила только страна, то и указывать нужно только ее, не очевидно совсем, ведь производитель товара то не меняется никоим образом.

3. общие замечания (наверняка уже риторический вопрос) - зачем повторять в гашении все, что было во входящем ВСЭД и является его неотъемлемой частью - и поставщик и получатель и машины, перевозящие грузи и т.п. - масса всего, все это, очевидно, может быть получено и так, из свойств самого ВСЭД в основной базе, но, видимо, повторение - мать "мученья" + скучать не приходится.

4. перейдем к отказу от поставки, посмотрим, что будет там.


Добрый вечер!
Возможно, кто-то сталкивался, прояснит ситуацию.

В продуктиве, при запросах вида http://help.vetrf.ru/wiki/GetProductItemList_v2.0 возникает масса проблем, так, например,

1. при попытке получить все товары по ПЛ с GUID = 9383cab9-83ec-49b4-a2b4-0e973aa00404, возникает сообщение - Предприятие с указанным идентификатором не найдено в реестре РСХН, либо идентификатор не соответствует установленному формату. Тем не менее запрос по этому ПЛ возвращает данные совершенно нормально, т.е. такая ПЛ существует. Как это может быть?

2. при запросе всех товаров с указанием GUID ХС =BF36CCF4-83EF-401A-B21C-B8B18F06B64B , приходит, например товар - мука мясо-костная с GUID = E3CA26FC-BDF0-4C1D-9A06-CF5991C80002. У данного товара в свойствах указан 3 уровень классификатора - 02EEC86C-54F3-2D20-6311-D3DB41A2E2D1, имеющего родительский 2 уровень GUID = 90E46DCA-D73C-1FD2-690B-51DE080D67A8 однако такого 3 уровня при запросе классификатора по данному GUID не возвращается. Что бы это значило? И таких товаров, у которых указаны GUID 3 уровня, которые никак не получить стандартными запросами - масса.

3. невозможно использовать фильтрацию по уровням классификатора одновременно с наложением фильтра по ХС и ПЛ. Работает либо запрос по классификатору без учета ХС и ПЛ, либо запрос по ХС или ПЛ, но тут возможны варианты - см. п.1 (ошибка), либо запрос отрабатывает, но уверенности в том, что он возвращает товар конкретного ХС или ПЛ нет.

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

Да, пробовали, блок вида
<vd:waybill>
<vd:issueNumber>цц2ц4454454</vd:issueNumber>
<vd:issueDate>2017-12-21</vd:issueDate>
<vd:type>1</vd:type>
</vd:waybill>
ошибка та же самая
 
Индекс форума » Профиль для vld » Сообщения, отправленные пользователем vld
Перейти:   

Powered by JForum 2.1.8 © JForum Team