Stepa86 wrote:Добрый день. Есть вопросы.

1) Где-нибудь есть шаблон формирования строки адреса для веб версии? Хочу иметь возможность из нашей системы в один клик открывать объект в веб-версии. Особенно актуально на этапе разработки и тестирования. Для ВСД сейчас это выглядит примерно так: https://t2-mercury.vetrf.ru/gve/operatorui?_action=showVetDocumentForm&_language=ru&vetDocument=00001 , но вот как раз этот номер и не передается в ответах. Как сформировать аналогичную строку на основе гуида ВСД - не понятно.

2) Кто как работает с кодами ошибок? Откуда взять весь список? Я походил по вики, собрал все в одну табличку, получилось 912 кодов. Но чаще в ответе приходит какой-нибудь новый код, который не гуглится на вики и иногда находится на форуме, но чаще и там не находится. Как с такими быть? Разработчикам: может есть возможность вместе с кодом ошибки отдавать и его описание? Ну или сделать веб-сервис, который будет отдавать список соответствия кодов описаниям. А то в случае появления нового кода ошибки и занесения его в вики шансов узнать о нем нашей системе немного.

3) Совершенно не понял как работать с организационно-правовой формой в ХС. Везде в документации написано, что это объект с тремя полями name, code и shortName 1, 2, 3 Но при импорте ХС списком и по гуиду там приходит ууид (или вообще ничего не приходит), а при попытке изменить ХС с заполнением 3х полей возвращается ошибка MERC04347, описания которой я нигде не нашел. Возможно это как раз изза того, что в ОПФ указаны эти 3 поля, а не ууид. Как правильно с ними работать? Как получить соответстие ууид и коду по ОКОПФ? Я пока вижу только такой способ: получить все ХС списком, у кого указан ууид ОПФ и ОПФ можно определить из наименования, то ставить в соответствие.

Алексей Тимофеев wrote:
Да, ограничение есть. На данный момент это не более 5 запросов от одного пользователя/IP в секунду. Запросы, не удовлетворяющие этим правилам, отклоняются с http-статусом 429 -- Too Many Requests.

Алексей Тимофеев wrote:
Да, это общее ограничение для всех запросов к шлюзу. Даже если это будет обычный GET-запрос на получение WSDL.
На наш взгляд, 5 запросов в секунду достаточно большая цифра, может быть даже очень. Но если всё-таки будут возникать какие-то проблемы с этим (при нормальном режиме работы с сервером), дайте знать.

Ограничение одинаковое и для пилотного сервера, и для боевого -- можно оттестироваться ещё в процессе разработки. К слову, ещё и поэтому мы обычно рекомендуем поработать какое-то время всем врачам предприятия (в многопользовательском режиме) на пилотном сервере.

Николай Власов wrote:Что касается "Выбора получателя для возврата", то ваше предложение однозначно не проходит: оно нарушает логику процесса: возврат - это совершенно конкретно - из точки В в точку А и ни каких других вариантов. Иначе это не возврат, а новое перемещение.
Касательно StockEntry не могу ни чего сказать - программисты пусть ответят.

2. по StockEntry - разработчики системы, просьба уточнить, зачем так сделано.

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

1) Где-нибудь есть шаблон формирования строки адреса для веб версии? Хочу иметь возможность из нашей системы в один клик открывать объект в веб-версии. Особенно актуально на этапе разработки и тестирования. Для ВСД сейчас это выглядит примерно так: https://t2-mercury.vetrf.ru/gve/operatorui?_action..._language=ru&vetDocument=00001 , но вот как раз этот номер и не передается в ответах. Как сформировать аналогичную строку на основе гуида ВСД - не понятно.

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

3) Совершенно не понял как работать с организационно-правовой формой в ХС. Везде в документации написано, что это объект с тремя полями name, code и shortName 1, 2, 3 Но при импорте ХС списком и по гуиду там приходит ууид (или вообще ничего не приходит), а при попытке изменить ХС с заполнением 3х полей возвращается ошибка MERC04347, описания которой я нигде не нашел. Возможно это как раз изза того, что в ОПФ указаны эти 3 поля, а не ууид. Как правильно с ними работать? Как получить соответстие ууид и коду по ОКОПФ? Я пока вижу только такой способ: получить все ХС списком, у кого указан ууид ОПФ и ОПФ можно определить из наименования, то ставить в соответствие.

Егорова Ирина wrote:
Вот ссылка: http://mercury.vetrf.ru/pub/operatorui?_language=ru&_action=showVetDocumentFormByUuid&uuid={uuid}

Егорова Ирина wrote:
Вместе с кодом ошибки возвращается и её описание. Код ошибки возвращается как атрибут code тега error в receiveApplicationResultResponse. Описание ошибки содержится в самом теге. К сожалению, сейчас в справке есть описание только ошибок с кодом MERC. Также вам могут быть возвращены ошибки с кодами APL или APLM. Обычно это означает, что у вас что-то не так с запросом.

Егорова Ирина wrote:
Ошибка MERC04347 означает, что организационно-правовая форма не найдена в реестре Россельхознадзора. Код ошибки добавлен в список ошибок. При задании кода организационно-правовой формы необходимо указывать код из справочника ОКОПФ. То есть для ООО, например, это 12300.

Егорова Ирина wrote:

2. по StockEntry - разработчики системы, просьба уточнить, зачем так сделано.

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

Уточню такой момент: возвратный сертификат оформляется в случае, если продукция была осмотрена получателем, и он решил отправить её обратно той же машиной. Если же получатель принял товар, погасил входной ВСД и только потом решил, что продукция по каким-то параметрам ему не подходит и её надо вернуть, то оформляется обычный транспортный сертификат.
Возвратный сертификат с точки зрения Меркурия ничем не отличается от транспортного, кроме типа "возвратный". Когда вы гасите у себя возвратный сертификат, у вас появляется новая запись в журнале входной продукции (точно так же, как если бы вы гасили транспортный), а в дальнейшем вы решаете, что с ней делать: "схлопывать" её, отдавать на экспертизу, утилизровать и т.д.
Почему не объединяется автоматически при возврате. Во-первых, возврат может быть произведён из-за ненадлежащего качества товара. Объединять качественную и некачественную продукцию как минимум неправильно, тем более автоматически. Во-вторых, по сути, партия, которую перемещали от поставщика к получателю и от получателя к поставщику, может отличаться от той что вы храните на складе: могли меняться условия хранения, есть вероятность нарушения упаковки, потери части партии и другие неприятности. Это могло привести к тому, что качество товара изменилось.

anig99 wrote:Добрый день! Пытаюсь оформить производство

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Body> <submitApplicationRequest xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions"> <apiKey>apiKey</apiKey> <application xmlns="http://api.vetrf.ru/schema/cdm/application"> <serviceId>mercury-g2b.service</serviceId> <issuerId>issuerId</issuerId> <issueDate>2016-11-04T15:17:40</issueDate> <data> <RegisterProductiveBatchRequest xmlns="http://api.vetrf.ru/schema/cdm/mercury/applications"> -------------------------------------------------------------------------------------------- </RegisterProductiveBatchRequest> </data> </application> </submitApplicationRequest> </Body> </Envelope>

Возвращает ошибку APLM0002 Unsupported application data format. В чём проблема?

T.Grakhov wrote:Здравствуйте.

Господа разработчики, а есть инструкции для ХС? Что нужно делать и зачем? В какой последовательности? Особенности для производственного, торгового предприятия? А то тыкаемся извините за выражение в шлюз, получаем данные, отправляем. Вообщем, пытаемся получить работающую версию. А что это? Какие требования, что надо, что не надо - совершенно не понятно.

T.Grakhov wrote:Еще раз здравствуйте.

Начну с конца. У нас нет конкретного предприятия для которого ведется разработка модуля. Мы разрабатываем модуль для добавление его в решение написанное на платформе 1С:Предприятие. Решение предназначено для автоматизации учета рыбоперерабатывающих предприятий. Поэтому использовать бизнес-процессы, конкретного предприятия не представляется возможным, приходиться их унифицировать и связывать с уже описанными в решении процессами. Есть предприятие, которое использует наше решение и мы совместно с ними занимаемся разработкой модуля. Операторы" этого предприятия в данном вопросе нам помочь не смогли. Это, я понимаю, в результате того, что на данный момент они не используют сервис в своей деятельности. С ветеринарными врачами связывались, результата тоже нет.
С информацией по ссылкам работаем активно, но этого не достаточно, поэтому и пишем вопросы, так как в решении придется задать алгоритм и написать под него инструкцию вида "делай - раз! делай - два!".
Давайте попробуем по конкретным вопросам.
Стандартный бизнес процесс: на предприятие поступило несколько номенклатурных позиций по некоему документу (ТТН). Первый шаг как мы полагаем запросить информацию по входящим ВСД. Это нами реализовано. Предположим ВСД есть и все номенклатурные позиции приняты на склад. Какие действия в системе предполагаются в этом случае?

T.Grakhov wrote:Мы тоже так подумали и реализовали запрос.
И получили ответ...

<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>ddc59b70-a842-4cd9-b282-054eb7d9a4e9</applicationId><status>REJECTED</status><serviceId>mercury-g2b.service</serviceId><issuerId></issuerId><issueDate>2016-11-03T18:41:57.000+03:00</issueDate><rcvDate>2016-11-03T16:41:50.000+03:00</rcvDate><prdcRsltDate>2016-11-03T16:41:51.000+03:00</prdcRsltDate><errors><apl:error xmlns:apl="http://api.vetrf.ru/schema/cdm/application" code="MERC14386">Данная транзакция не может быть оформлена, так как роль пользователя не позволяет гасить ВСД</apl:error></errors></application></receiveApplicationResultResponse></env:Body></env:Envelope>