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

На запрос по https://api2.vetrf.ru:8002/platform/services/ProductService в т.ч. из примера http://help.vetrf.ru/wiki/GetProductByGuid

получаю 500 Code Response

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">soap-env:Server: BEA-380002</faultcode>
            <faultstring>Error in operation: GetProductByGuid</faultstring>
            <faultactor>http://test-argus.vetrf.ru:80/api/argus/services/DictionaryService</faultactor>
            <detail>
                <ws:internalServiceFault xmlns:ws="http://api.vetrf.ru/schema/cdm/base/ws-definitions">
                    <base:message xmlns:base="http://api.vetrf.ru/schema/cdm/base">Internal Service Error!</base:message>
                </ws:internalServiceFault>
                <business/>
                <runtime>
                    <con:fault xmlns:con="http://www.bea.com/wli/sb/context">
                        <con:errorCode>BEA-380002</con:errorCode>
                        <con:reason>Not Found</con:reason>
                        <con:location>
                            <con:node>RouteToGetProductByGuid</con:node>
                            <con:path>response-pipeline</con:path>
                        </con:location>
                    </con:fault>
                </runtime>
            </detail>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

"Мониторинг доступности" на странице http://help.vetrf.ru/wiki/Ветис.API - Статус сервера: доступен, другие запросы отрабатывает.

Слабо надеюсь на ответ, но ситуация такая... есть цепочка транзакций:
- выпуск продукции ХС1 - ПО1
- реализация выпущеной продукции на ХС2 - ПО2
- гашение входящих ВСД у ХС2 - ПО2
- реализация полученной продукции на СХ3 - ПО3
проблема нарисовалась где не ждал: на третьем этапе при попытке получить список входящих ВСД - получаю пустоту
захожу в веб интерфейс - вижу на обслуживаемом ПО2 два входящих ВСД, гашу один руками
запрашиваю по этому ПО список записей - отсутствуют, запрашиваю список входящих ВСД - отсутствуют, но в веб-интерфейсе всё есть
первое что приходит в голову - не тот ПО указывается при получении входящих ВСД и запросе записей журнала
но guid ПО один и то же что и на шаге 2 - когда оформлялась транспортная транзакция
есть ещё одна цепочка:
- выпуск продукции ХС1 - ПО1
- перемещение продукции ХС1 - ПО4
- гашение входящих ВСД у ХС1 - ПО4
- реализация продукции на ХС3 - ПО3
тут всё отрабатывает без проблем, разница в двух моментах:
1. получатели ВСД - разные ХС, во второй цепочке перемещений - нет смены владельца
2. ХС2 и ПО2 были созданы и права на обслуживание в АРГУС-е были выданы около месяца назад
права на обслуживание ПО1, ПО2, ПО4 - выданы одному пользователю, привязки ХС1 и ХС2 на те же ПО выполнены там же в АРГУС-е аналогично
всю голову сломал...

Возможно проблема в следующем:
доступ к шлюзу предоставлен ХС1, который работает на ПО1 и ПО4
ХС2 - ещё одно юр.лицо группы компаний, работает на ПО2
что нужно для полноценной работы ХС2 через шлюз?

Ну вот))

Сделал запрос на погашение выписанного ранее ВСД по перемещению внутри одного ХС (между площадками), и в ответ получил замысловатую ошибку, под которую даже выделили отдельный меркурианский код:
<apl:error code="MERC14464" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported error code: 14464</apl:error>

Неподдерживаемая ошибка в Меркурии - интересно, есть ли, все же, способ понять что пошло не так?))

Добрый день, уважаемые участники Сообщества и евангелисты системы Меркурий!

Все же хотелось бы вновь поднять вопрос о добавлении опционального поля "ProducerBatchCode" в структуру vetd:Batch. Маркировка не покрывает все многообразие ситуаций, когда необходимо будет в Меркурии идентифицировать складские записи в соответствии с кодом партии, присвоенном производителем. Приведя аналогию с геометрией, отсутствие данного поля в структуре vetd:Batch схоже с переходом из трехмерного пространства (со всеми его степенями свободы) на плоский мир. Просто одно измерение убрано, и чтобы спроецировать красивый трехмерный мир, нужно использовать сложные геометрические преобразования. Так и в нашем случае, код партии производителя (а производитель одному и тому же продукту в течение суток при производстве может присвоить много кодов партий) используется в богатом многообразии бизнес-процессов, которые должны отражаться в Меркурии. Но поскольку Меркурий настойчиво не хочет разрешить производителям установить соответствие своих партий с партиями этого производителя, появляется необходимость строить изощренные средства преобразования на интеграционных порталах производителей....

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

Эти проблемы решаются одним простым способом: добавлением опционального поля ProducerBatchCode (или что-то в этом роде) в структуру vetd:Batch. Пусть кому не нужно, не пользуются. Но зато все остальные будут жить в красивом трехмерном мире, где птицы летают, а не скользят по плоскости

Спасибо!

Результаты тестов по выписке ВСД и гашению ВСД с применением <vet:productName> и <vet:productCode>, которые якобы были созданы для передачи номенклатуры, отличной от номенклатуры производителя:

1) Несмотря на то, что в документации (изменения в версии 1.5) указано, что <vet:productName> и <vet:productCode> в запросе prepareOutcomingConsignmentRequest должны присутствовать в структуре <vet:consignment>, при добавлении этих полей в нее, постоянно возникают ошибки некорректной структуры XML. Наконец, убив несколько тысяч нервных клеток, я все же получил успешный результат теста, добавив их в структуру <vet:sourceStockEntry> вот в таком виде:

2) В ответе на свой запрос (prepareOutcomingConsignmentRsponse) я получил уже другую картину. Опять же в структуре </merc:stockEntry> (не понятно, кстати, почему у нее в Rquest'e пространство имен vet, а в respons'e пространство имен merc) получил вот такой результат:

То есть в ответе вместо того, что указал я при создании ВСД, приехало обратно описание товара в номенклатуре производителя, которое я ранее задавал для ProductItem в запросе ModifyProducerStockListRequest, а код - ТНВЭД, вместо кода, который указал я...

Отлично работает

. Ну ок, на этом я не остановился и пошел дальше:

3) Решил погасить созданный ВСД на получающей площадке (т.к. у меня перемещение между площадками моего же ХС).
3.1) Сначала решил не указывать <vet:productName> и <vet:productCode>, ведь по документации они являются опциональными. Но не тут-то было. Меркурий вернул ошибку:

ОК, надо так надо:
3.2) Поскольку в запросе на погашение ВСД нет структуры <vet:stockEntry>, то вписывать <vet:productName> и <vet:productCode> больше некуда, кроме как в <vet:consignment>. Ну я и вписал, по аналогии со stockEntry в самом низу, настойчиво указывая следующее:
<vet:productName>TEST TEST TEST</vet:productName>
<vet:productCode>TEST TEST TEST</vet:productCode>[/code]

Ответ от Меркурия:

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

Выводы:
1) Документация не соответствует функционалу (я молчу про help.vetrf.ru, на котором все уже устарело, но даже в описании версии 1.5 - приложено, информация представлена некорректно).
2) Функционал не соответствует заявленной идее. При попытке передать номенклатуру клиента в выделенных для этого полях, Меркурий все равно при создании ВСД в эти поля вписал не то, что нужно.
3) Погашение не получается сделать из-за неподдерживаемой ошибки.

Вопрос:
1) Кто-нибудь это читает? И куда писать, чтобы быть услышанным?

писать надо на api@vetrf.ru <api@vetrf.ru>

А полезно иногда писать на форуме))

Думаешь о том, что тебя прочитала куча людей, начинаешь испытывать ответственность, и сам находишь причину ошибки. Я разобрался. Все отработало. Прошу прощения за эмоциональность, но именно так, видимо, находятся правильные решения. Все загвоздка была в том, что как <vet:consignment>, так и <vet:stockEntry> могут содержать <vet:productName> и <vet:productCode>. И методом перебора, я нашел правильное место в запросе на выписку ВСД, куда нужно вставить <vet:productName> и <vet:productCode> в структуре <vet:consignment>, чтобы вся цепочка далее отработала. Это место между элементами <vet:packageList> и <vet:sourceStockEntry>.
При этом в запросе на погашение данные поля идут в конце структуры <vet:consignment>, сразу после элемента <vet:owner>.

alpsmirnov wrote:Результаты тестов по выписке ВСД и гашению ВСД с применением <vet:productName> и <vet:productCode>, которые якобы были созданы для передачи номенклатуры, отличной от номенклатуры производителя:

1) Несмотря на то, что в документации (изменения в версии 1.5) указано, что <vet:productName> и <vet:productCode> в запросе prepareOutcomingConsignmentRequest должны присутствовать в структуре <vet:consignment>, при добавлении этих полей в нее, постоянно возникают ошибки некорректной структуры XML. Наконец, убив несколько тысяч нервных клеток, я все же получил успешный результат теста, добавив их в структуру <vet:sourceStockEntry> вот в таком виде:
<vet:productName>TEST TEST TEST</vet:productName> <vet:productCode>TEST TEST TEST</vet:productCode>

2) В ответе на свой запрос (prepareOutcomingConsignmentRsponse) я получил уже другую картину. Опять же в структуре </merc:stockEntry> (не понятно, кстати, почему у нее в Rquest'e пространство имен vet, а в respons'e пространство имен merc) получил вот такой результат:
<vetd:productName xmlns:vetd="http://api.vetrf.ru/schema/cdm/mercury/vet-document">Pedigree dry first feeding 12*600g</vetd:productName> <vetd:productCode xmlns:vetd="http://api.vetrf.ru/schema/cdm/mercury/vet-document">2309</vetd:productCode>

То есть в ответе вместо того, что указал я при создании ВСД, приехало обратно описание товара в номенклатуре производителя, которое я ранее задавал для ProductItem в запросе ModifyProducerStockListRequest, а код - ТНВЭД, вместо кода, который указал я...

Отлично работает . Ну ок, на этом я не остановился и пошел дальше:

3) Решил погасить созданный ВСД на получающей площадке (т.к. у меня перемещение между площадками моего же ХС).
3.1) Сначала решил не указывать <vet:productName> и <vet:productCode>, ведь по документации они являются опциональными. Но не тут-то было. Меркурий вернул ошибку:
<apl:error code="MERC14098">Наименование продукции в сведениях о принимаемой партии обязательно для заполнения.</apl:error>

ОК, надо так надо:
3.2) Поскольку в запросе на погашение ВСД нет структуры <vet:stockEntry>, то вписывать <vet:productName> и <vet:productCode> больше некуда, кроме как в <vet:consignment>. Ну я и вписал, по аналогии со stockEntry в самом низу, настойчиво указывая следующее:
<vet:productName>TEST TEST TEST</vet:productName>
<vet:productCode>TEST TEST TEST</vet:productCode>[/code]

Ответ от Меркурия:
<apl:error code="MERC14232">Наименование продукции в запросе отличается от указанного в ветеринарно-сопроводительном документе без указания причины в акте несоответствия.</apl:error> <apl:error code="MERC14464">Unsupported error code: 14464</apl:error>

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

<apl:error code="MERC14464">Unsupported error code: 14464</apl:error>

Выводы:
1) Документация не соответствует функционалу (я молчу про help.vetrf.ru, на котором все уже устарело, но даже в описании версии 1.5 - приложено, информация представлена некорректно).
2) Функционал не соответствует заявленной идее. При попытке передать номенклатуру клиента в выделенных для этого полях, Меркурий все равно при создании ВСД в эти поля вписал не то, что нужно.
3) Погашение не получается сделать из-за неподдерживаемой ошибки.

Вопрос:
1) Кто-нибудь это читает? И куда писать, чтобы быть услышанным?

Добрый день.

Насколько точно система адресов в Икар соответствует КЛАДР?

Вопрос в том, как мне сопоставить площадки из Меркурия с системой торговых точек (адресов) в своей УС?

Был бы КПП, я бы по КПП сопоставил. Правда у ИП нет КПП, и снова надо что-то изобретать.

Кто как решил у себя проблему - поделитесь пожалуйста!

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

Насколько точно система адресов в Икар соответствует КЛАДР?

Вопрос в том, как мне сопоставить площадки из Меркурия с системой торговых точек (адресов) в своей УС?

Был бы КПП, я бы по КПП сопоставил. Правда у ИП нет КПП, и снова надо что-то изобретать.

Кто как решил у себя проблему - поделитесь пожалуйста!

По вчерашнему ECR-форуму, в версии ветис.АПИ 2.0 должен появиться ИНН/КПП и GLN у площадок.
Сейчас соответствие смутное, как завели в системе, так и живет адрес.

v.isaev wrote:
По вчерашнему ECR-форуму, в версии ветис.АПИ 2.0 должен появиться ИНН/КПП и GLN у площадок.
Сейчас соответствие смутное, как завели в системе, так и живет адрес.

Та-ак. У ИП КПП нет, GLN вообще есть только у производителей да IDE-шников.

В общем, нас ждет сопоставление вручную.

Очередная "благодарность" разработчикам Ветис за "заботу".

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

Возникла такая проблема на тестовой версии.
Формирую запрос на TransportOperation вида:

В ответ приходит ошибка MERC02146, что "Хозяйствующий субъект-получатель продукции не должен совпадать с хозяйствующим субъектом-отправителем".

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

Подскажите, в чём загвоздка.

alpsmirnov wrote:1) Документация не соответствует функционалу (я молчу про help.vetrf.ru, на котором все уже устарело, но даже в описании версии 1.5 - приложено, информация представлена некорректно).

Спасибо вам большое за файл во вложении, пользуюсь только help.vetrf.ru даже и не знал о другой документации кроме этой. Можно поинтересоваться где вам выдали данную "секретную информацию"?

Также полностью согласен с alpsmirnov по поводу добавления опционального поля ProducerBatchCode в структуру vetd:Batch.

кудесники кода, сориентируйте, пожалуйста, по поводу использования логина пользователя ГВЭ в интеграционной системе
для чего это может понадобится я догадываюсь, но это просто догадки, а в реальности я очень далек от программирования, и не могу знать, зачем он может быть необходим некой организации для работы в интеграционной системе???
ну и если еще конкретнее - насколько вероятна возможность использования логина врача (без пароля) неким ХСом для дого, чтобы оформлять ЭВСД от его имени??

Agnostik wrote:кудесники кода, сориентируйте, пожалуйста, по поводу использования логина пользователя ГВЭ в интеграционной системе
для чего это может понадобится я догадываюсь, но это просто догадки, а в реальности я очень далек от программирования, и не могу знать, зачем он может быть необходим некой организации для работы в интеграционной системе???
ну и если еще конкретнее - насколько вероятна возможность использования логина врача (без пароля) неким ХСом для дого, чтобы оформлять ЭВСД от его имени??

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