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

Вот должен быть гуид и уид ХС.
А вообще Гуид ХС лучше искать по ИНН или же затребовать у самого ХС, если в меркурии с таким ИНН несколько ХС

А вообще Гуид ХС лучше искать по ИНН или же затребовать у самого ХС, если в меркурии с таким ИНН несколько ХС

Подскажите как это сделать? Запрос GUID ХС (и его площадок) по ИНН (через апи).

Хотим наполнить мастер-данные гуидами наших поставщиков.
Опрашивать по почте всех долго и неэффективно, да и присылают они как правило не то, что нужно.

Вот хороший запрос по поиску ХС
http://help.vetrf.ru/wiki/GetBusinessEntityList_v2.0

Запрос на получение подчиненных площадок, но это если уже привязаны площадки. иначе их надо искать по наименованию, которое может быть любым.
http://help.vetrf.ru/wiki/GetActivityLocationList_v2.0

Если делаю запрос PrepareOutgoingConsignmentOperation с указанием двух наименований и двух записей журнала откуда надо списать.
Но допустим по одной записи журнала количества не хватает. какой будет ответ?

Весь запрос будет REJECTED или ... ?

Написал в форум по Аргусу, дублирую сюда (не знаю, куда лучше):

Добрый день.
Не подскажете, почему в запросе getRussianEnterpriseList:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://api.vetrf.ru/schema/cdm/cerberus/enterprise/ws-definitions" xmlns:base="http://api.vetrf.ru/schema/cdm/base" xmlns:ent="http://api.vetrf.ru/schema/cdm/cerberus/enterprise" xmlns:ikar="http://api.vetrf.ru/schema/cdm/ikar">
<soapenv:Header/>
<soapenv:Body>
<ws:getRussianEnterpriseListRequest>

<base:listOptions>

<base:count>100</base:count>

<base:offset>0</base:offset>
</base:listOptions>

<ent:enterprise>

<ent:name>ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ "ЭСКОРТ СЕРВИС"</ent:name>
</ent:enterprise>
</ws:getRussianEnterpriseListRequest>
</soapenv:Body>
</soapenv:Envelope>

Я получаю в ответе 0, а при входе в Аргус или Меркурий (https://t2-mercury.vetrf.ru/hs/operatorui?_action=settingsForm&_language=ru) вполне себе вижу Хозяйствующий субъект: ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ "ЭСКОРТ СЕРВИС"?

Спасибо. И, кстати, где и как можно завести в тестовой базе новые площадки?

Уважаемые разработчики, нельзя ли услышать ответ на простой вопрос:

Не подскажете, почему в запросе getRussianEnterpriseList по имени я получаю в ответе 0, а при входе в Аргус или Меркурий (https://t2-mercury.vetrf.ru/hs/operatorui?_action=settingsForm&_language=ru) вполне себе вижу Хозяйствующий субъект: ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ "ЭСКОРТ СЕРВИС"?
Что именно я делаю не так?

С уважением, Залкинд Дмитрий.

Добрый день!

У меня есть пожелание к разработчиками системы Ветис.API

Уважаемые разработчики сделайте тест-бота!
Чтобы любой разработчик интеграционных систем мог в любое время получить тестовые запросы или тестовые ответы на свои запросы,
подавая какие-то команды этому тест-боту.

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

Алексей Баранов wrote:Добрый день!

У меня есть пожелание к разработчиками системы Ветис.API

Уважаемые разработчики сделайте тест-бота!
Чтобы любой разработчик интеграционных систем мог в любое время получить тестовые запросы или тестовые ответы на свои запросы,
подавая какие-то команды этому тест-боту.

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

А что не устраивает на тестовом контуре? Сделали весь цикл, все отработано без ошибок, значит готовы, есть ошибки, значит не готовы.
Зачем еще какой то бот?
Единственное что было бы интересно, это проверка корректности запроса, если запрос не корректен. то показывал бы где именно, а то бывает у людей буковку "с" на русском напишут, а потом не понятно где ошибка.

oleg-x wrote:

Алексей Баранов wrote:Добрый день!

У меня есть пожелание к разработчиками системы Ветис.API

Уважаемые разработчики сделайте тест-бота!
Чтобы любой разработчик интеграционных систем мог в любое время получить тестовые запросы или тестовые ответы на свои запросы,
подавая какие-то команды этому тест-боту.

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

А что не устраивает на тестовом контуре? Сделали весь цикл, все отработано без ошибок, значит готовы, есть ошибки, значит не готовы.
Зачем еще какой то бот?
Единственное что было бы интересно, это проверка корректности запроса, если запрос не корректен. то показывал бы где именно, а то бывает у людей буковку "с" на русском напишут, а потом не понятно где ошибка.

Бот нужен
1. чтобы не просить сторонних людей что-то посылать, подтверждать, отменять и т.п.
2. чтобы иметь множество эталонных вариантов запросов/ответов в исполнении госоргана, потому что иначе тестовая выборка ограничена парой-тройкой поставщиков.
А практика показывает, что в начале работы возникает куча особенностей и каждую особенность с каждым поставщиком нужно учитывать отдельно. Ибо нечеткие стандарты рождают нечеткую реализацию.
3. чтобы при возникновении претензий со стороны API-шлюза (превышение 10% ошибок) меня не могли отключить от продуктивного контура, если система корректно проходит комплексный тест.

Кто-нибудь знает заклинание, как приманить в форум кого-нибудь из команды разработчиков?
Как-то печально работа проходит: видишь нечто странное, а что с ним делать и как обойти - непонятно.
На что их приманить можно - в жертву кого/чего принести, или специальные молитвы есть?

Бот нужен
1. чтобы не просить сторонних людей что-то посылать, подтверждать, отменять и т.п.
2. чтобы иметь множество эталонных вариантов запросов/ответов в исполнении госоргана, потому что иначе тестовая выборка ограничена парой-тройкой поставщиков.
А практика показывает, что в начале работы возникает куча особенностей и каждую особенность с каждым поставщиком нужно учитывать отдельно. Ибо нечеткие стандарты рождают нечеткую реализацию.
3. чтобы при возникновении претензий со стороны API-шлюза (превышение 10% ошибок) меня не могли отключить от продуктивного контура, если система корректно проходит комплексный тест.

1) Можно зарегистрировать два ХС на тестовом сервере (ни кто не запрещает), опять же ни кто не проверяет реальные данные.
2) Множество эталонных вариантов вы получите только на рабочем сервере и все равно будете встречать какую нить бяку в процессе.
Пару вариантов исключения бяк, поставщиков обязывать присылать даты указанные только в необходимых полях, без указания даты строкой и не принимать такие ЭВСД.
Не принимать братские могилы и прочее и прочее. Круг сразу становится меньше.
3) Ни кто просто так Вас не заблокирует, сначала сделают предупреждение. И если на него не реагировать, то уже крайняя мера блокировка.
Перед отправкой запросов, проверять заполненность всех данных, это не сложно и тупо не отправлять ВСД. И тогда большинство ошибок не будет.

oleg-x wrote:
1) Можно зарегистрировать два ХС на тестовом сервере (ни кто не запрещает), опять же ни кто не проверяет реальные данные.
2) Множество эталонных вариантов вы получите только на рабочем сервере и все равно будете встречать какую нить бяку в процессе.
Пару вариантов исключения бяк, поставщиков обязывать присылать даты указанные только в необходимых полях, без указания даты строкой и не принимать такие ЭВСД.
Не принимать братские могилы и прочее и прочее. Круг сразу становится меньше.
3) Ни кто просто так Вас не заблокирует, сначала сделают предупреждение. И если на него не реагировать, то уже крайняя мера блокировка.
Перед отправкой запросов, проверять заполненность всех данных, это не сложно и тупо не отправлять ВСД. И тогда большинство ошибок не будет.

Вот это же самое я говорю всем, кто у меня спрашивает совет как делать/выкручиваться из разных ситуаций.
И всем говорю, что надо действовать по принципу: "Главное ввязаться в драку, а там разберемся!"
Так было с ЕГАИС. Так будет с Меркурием.

Имея бота, РСХН наконец-то сами бы поняли, как нужно делать правильно.

И кто-то бы ещё (а лучше сам РСХН) составил полный список рекомендаций, чего не надо делать, чтобы сузить круг возможных ошибок.
А то ведь согласно формату сделать можно очень много того, что не совместимо с понятием интеграция.

Имея бота, РСХН наконец-то сами бы поняли, как нужно делать правильно.

И кто-то бы ещё (а лучше сам РСХН) составил полный список рекомендаций, чего не надо делать, чтобы сузить круг возможных ошибок.
А то ведь согласно формату сделать можно очень много того, что не совместимо с понятием интеграция.

Бота не сделают, ограниченный бюджет, а это дополнительные траты финансовые и человеческие ресурсы.
Рекомендации есть. Есть видео с разъяснениями: https://www.youtube.com/watch?v=n6CuNkCJFzA всего три видео. Есть приказы.
Система позволяет многое делать, но и многие вещи являются нарушением, за что по голове ни кто не погладит.

Постоянно через раз выходит ошибка:
APLM0012 An unexpected error has occurred while invoking target service operationon
это что? как от нее избавиться?

Добрый день!

В тестовой платформе оформляю производственную операцию (настраиваю интеграцию 1С:Предприятие 8.3).
29 мая все работало хорошо, вчера (видимо после обновления) стала выдаваться ошибка "MERC56410 - Номер производственной партии обязателен для заполнения".
Судя по всему, проблема в поле "batchID" - я его не заполняла. Пытаюсь заполнить как в примере <vd:batchID>ПП64219</vd:batchID> - простым присвоением кода, получаю ошибку "поле недоступно для записи".
В отладчике это поле показывается как "СписокXDTO".
Я куда-то не туда копаю? Кто сталкивался с такой проблемой подскажите, пожалуйста, что такое номер производственной партии и как правильно его заполнить?