|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: Konup
Индекс форума » Профиль для Konup » Сообщения, отправленные пользователем Konup
Автор Сообщение
Доброго...

Вот тут написано:

https://help.vetrf.ru/wiki/%D0%9F%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B_%D0%B2_%D0%9C%D0%B5%D1%80%D0%BA%D1%83%D1%80%D0%B8%D0%B9.%D0%A5%D0%A1

Ещё в нескольких местах встречается информация про 5%
Тоже не можем получить остатки, постоянно "IN_PROCESS". Причём по одному ХС с позавчерашнего вечера на все запросы получить остатки постоянно "IN_PROCESS", а по некоторым ХС изредка проскакивает ответ...
oleg-x wrote:По крайне мере в справке где то такое читал.

Так у них справку одни "гении" писали, а шлюз Меркурия другие...

GusVal wrote:Проблема не в том, что объединили, а в том, что по одному и тому же UUID (состоянию в конкретный момент) документа разные методы возвращают разные GUID'ы

Пока писал интеграцию не раз сталкивался с тем, что при получении документов списком некоторые данные отличаются от данных при получении одного документа по uuid. Видимо одно правят, другое калечат...
Николай Власов wrote:
Lugano wrote:

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


Я, например, за пол года был готов к интеграции.
После дня Х с трудом входящие получаю, а со вчерашнего дня и остатки


Был готов или начал работать?
Так ведь дело-то не в ком-то лично: дело в массе: очень многие были готовы, но не работали. Вот некоторые проблемы и остались невыявленными или недооцененными.


А какая разница... У меня с февраля-марта полная работа была без особых проблем (опт, магазины, небольшое производство). Сейчас или еле-еле ворочается или всё стоит... Вся цепочка начинается с получения новых входящих ВСД, а по ним постоянно ошибка APLM0012 или пусто в ответе. А без гашения ВСД нет продукции, а без неё нет сырья для производства, нет исходящих транзакций...
egais2018 wrote:Ситуация осложняет еще и то что в один день сразу три нововведения хотят сделать. Меркурий, ЕГАИС и Онлайн-кассы. Как специально.


А в это время идёт чемпионат мира... Это уже не специально, это уже диверсии...
Доброго...

В последние дни Меркурий полный тормоз... Всё еле-еле дышит...
Доброго...

У всех в тестовом ВетИС.API работает (работало)? Или это проблема с тестовым ВетИС.API, а на продуктивном нормально?
<vd:issueSeries/> убрали и в <vd:waybill> и в <vd:relatedDocument>?
разработчикам?
http://vetrf.ru/vetrf/news/26826.html
Легче уж застрелиться...
Да, вроде правильно.
А попробуйте убрать пустые теги <vd:issueSeries/>, фиг знает как у разработчиков воспринимаются они.
Ппосмотрел у себя. Да, везде вставляю при гашении внутрь тега accompanyingForms relatedDocument. И проблем нет, пользователи с марта работают через шлюз ВетИС.API 2.0
Доброго...

А вы попробуйте и очень удивитесь...
Если вы смотрите мануал по запросам на сайте, например, http://help.vetrf.ru/wiki/ProcessIncomingConsignment_v2.0, то и там встречаются ошибки...
Доброго...

Может не прав, но если мне память не изменяет, то у меня в запросе на гашение используются теги relatedDocument, в которых я перечисляю документы, указанные во входящем ВСД в тегах referencedDocument. Тупость конечно повторять всю информацию, но что поделаешь...
Доброго...

Решил попробовать сделать мультимодальные перевозки.
Для теста использую тестовый ВетИС.API 2.0
Посылаю запрос с исходящей транзакцией со сведениями о маршруте следования, используя ShipmentRoute, вот пример:

<vd:shipmentRoute>
<vd:routePoint>
<vd:sqnId>1</vd:sqnId>
<vd:location>
<dt:name>1-ый перекресток</dt:name>
<dt:address>
<dt:country>
<bs:guid>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</bs:guid>
</dt:country>
<dt:region>
<bs:guid>0b940b96-103f-4248-850c-26b6c7296728</bs:guid>
</dt:region>
</dt:address>
</vd:location>
<vd:transshipment>true</vd:transshipment>
<vd:nextTransport>
<vd:transportType>1</vd:transportType>
</vd:nextTransport>
</vd:routePoint>
<vd:routePoint>
<vd:sqnId>2</vd:sqnId>
<vd:location>
<dt:name>2-ой перекресток</dt:name>
<dt:address>
<dt:country>
<bs:guid>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</bs:guid>
</dt:country>
<dt:region>
<bs:guid>0b940b96-103f-4248-850c-26b6c7296728</bs:guid>
</dt:region>
</dt:address>
</vd:location>
<vd:transshipment>true</vd:transshipment>
<vd:nextTransport>
<vd:transportType>1</vd:transportType>
</vd:nextTransport>
</vd:routePoint>
</vd:shipmentRoute>

Приходит ответ, что транзакция прошла. Есть в ответе данные по stockEntry и по vetDocument. Вроде всё хорошо, но в ответе нет данных о маршруте следования (нет ShipmentRoute).
Через Веб интерфейс тоже нет сведений о маршруте следования, только отправитель и получатель.
Пытаюсь изменить номера транспорта через UpdateTransportMovementDetailsOperation 2.0, приходит ошибка "MERC72474: Точка маршрута с указанным идентификатором не найдена"
Понимаю, что маршрут следования в запросе не прошел, но что тогда делаю не так?
Ну так понятно, это же техподдержка...
 
Индекс форума » Профиль для Konup » Сообщения, отправленные пользователем Konup
Перейти:   

Powered by JForum 2.1.8 © JForum Team