Добрый день! Предлагаю в этой теме всем программистам обсуждать технические вопросы по Ветис.API
Сейчас я плотно работаю с интеграцией с Меркурий через Ветис.API и хотелось бы обсудить вопросы, с которыми я столкнулся.
Пишу обмен с помощью xdto, сильно помогла вот эта публикация http://infostart.ru/public/560823/ Уже получается сделать полный цикл на тестовом контуре - принять входящий эвсд, сделать производство и продажу (транспортную операцию).
РЕКОМЕНДУЮ методичку "первые шаги в интеграции с ФГИС Меркурий"
http://help.vetrf.ru/images/b/bc/Ecr.pdf
1) как обеспечивается прослеживаемость в Меркурии?
при продаже в транспортном эвсд видно только номер производственного эвсд (типа 576423) но не его guid.
при запросе производственного эвсд через API не видно ни guid/номера входящего эвсд сырья, ни даже guid записей складского журнала для сырья (stockEntry).
то есть, прослеживаемость обрывается на производственном эвсд.
или как-то ее видно в веб-интерфейсе?
я смотрел, по-моему нет, в транзакции производства видно только название сырья без подробностей и всё. от кого оно поступило, например, неясно.
писал об этом на форуме подробнее
http://www.fsvps.ru/vetrf-forum/posts/list/1380/169.page#42196
2) где конечная точка Меркурия? то есть, обязаны ли розничные магазины гасить входящие эвсд? тогда будет "веселье" как с егаис) хотя , конечно API меркурия и проще
судя по приказу Минсельхоза 646 от 18.12.2015 где написано "организации...являющиеся участниками оборота подконтрольных товаров", так что да, рознице тоже нужно.
https://minjust.consultant.ru/documents/18335?items=1&page=1
2.1) исходя из предыдущего вопроса, магазин может гасить входящие эвсд, но что дальше? на магазине в меркурии повиснет куча входящих записей складского журнала (StockEntry) которые будут только увеличиваться? или при продаже в розницу их надо как-то уменьшать инвентаризацией например?
3) Создание площадок (они же "поднадзорные объекты" или "предприятия") в Меркурий.
Сейчас в другом регионе, если нет площадки, ее может создать только ветврач. Есть ли более простой способ?
Иначе выходит что при любой отгрузке в другой регион, если площадки нет, надо искать ветврача и тратить время.
В пределах своего региона площадки может создавать через API любой подключенный от юрлица пользователь с правами ветврача, но при этом надо еще заполнять правильно адреса из системы ИКАР - получать все guid городов и улиц в своем регионе. Ну хотя бы эти адреса можно заполнить один раз.
4) Неочевидные связи.
Например, у меня встречалась ошибка MERC01229 - Из данного сырья не может быть выработана указанная продукция.
Где посмотреть эту неочевидную связь, из какого сырья что можно выработать?
похожая ошибка была MERC24263, что для подвида продукции не разрешена единица измерения "штуки". Также нигде не прописана связь между подвидом продукции и разрешенными для него единицами измерения.
5) эцп
еще вот в статье http://infostart.ru/public/439710/ упоминалось что "обмен значимой электронной информацией между предприятиями должен быть подтвержден ЭЦП".
пока не видел каких-то планов по внедрению эцп в меркурий...
(2) без ЭЦП вся система теряет смысл как юридически значимая, так как без неё нет никакой достоверности. Скорее всего это в том же пакете законовом, который даст возможность выписывать ветеринарки аккредитованым организация и лицам, а не только ветеринарам.
2. судя по форуму на vetrf.ru могут но не обязаны
2.1. может гасить, а могут висеть до посинения, смысл всей этой беды не в информации об остатках, а в сопроводительных документах, которые показывают что откуда и куда едет, кто разрешил и откуда оно взялось, ну ещё вариант - когда магазин не принимает продукцию - это уже проблема отправителя
3. города, улицы конечно надо заполнять верно, но мне вет.врачи говорили, что иногда адреса в других регионах успешно регистрируются.
5. поищи на форуме - разработчики мычат что-то невразумительное, ладно хоть https работает..
(6) ну я делал через ModifyEnterpriseOperation
пробую из Моск. Области создать площадку в москве
заполняю region и street
в ответ приходит ошибка MERC07400
"Регион указанной организации и обслуживаемого предприятия должны совпадать"
(7)добрый день Иван. Получилось у Вас через ModifyEnterpriseOperation создать площадку? у меня приходит ответ с ошибкой APLM0002 Unsupported application data format. это уже на запрос receiveApplicationResultRequest. текст запроса совпадает с примером из документации, в чем проблема не знаю куда копать. мне надо площадку создать, т.к. у нас нет её, а без неё, я понял, дальше транзакции не созашь на вход, производство и транспортную.
в каком регионе ваше юрлицо? попробуйте сделать запрос getBusinessEntityByGUID и скопируйте поля region locality и street оттуда.
https://pastebin.com/1miKtTiK
(17)в принципе я так и делал, по запросу getBusinessEntityByGUID получил данные, скопировал данные адреса (какие заполнены были), текст запроса соответствует документации. регион Новосибирск.
пока писал ответ, нашел причину ошибки, в методе:
ApplicationDataWrapper = ФабрикаXD.Создать("http://api.vetrf.ru/schema/cdm/application", "ApplicationDataWrapper");
ApplicationDataWrapper.Добавить(ФормаXML.Элемент, modifyEnterpriseRequest.Тип().URIПространстваИмен, "modifyEnterpriseRequest", modifyEnterpriseRequest);
"modifyEnterpriseRequest" писал как "ModifyEnterpriseRequest".
исправил, но теперь выдает код ошибки MERC 07369 Инициатор, ответственный за выполнение операции, с указанным идентификатором не найден в реестре РСХН, либо идентификатор не соответствует установленному формату.
в качестве intiator использую Login, который дали для тестовой БД.
(15) во всех случаях, когда получаете ошибку формата - лучше всего фиддлером копируйте запрос и прикладывайте сюда. Можете затереть информацию, которая не предназначена для всеобщего обозрения. Посмотрев запрос, вам можно попробовать помочь. Не видя запроса - вряд ли.
О, по поводу вопроса 4 нашел ответ в инструкции к веб-интерфейсу, есть табличка что из чего можно производить
(Ведение журнала вырабатываемой на предприятии продукции в Меркурий.ХС)
https://clck.ru/B9FnD
добрый день Иван, т.к. Вы уже разобрались с обменом с Меркурием, можно вопрос. Хочу получить список предприятий чтобы узнай guid нашей фирмы. согласно документации формирую запрос через сервис Цербер (EnterpriseService) операция GetRussianEnterpriseList, отправляю запрос, но в ответ получаю тот же самый текст, что и послал.Что не так? текст процедуры ниже. текст запроса формируется вроде нормально (как в документации).буду очень признателен за ответ.
это текст запроса
<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>
<getRussianEnterpriseListRequest xmlns="http://api.vetrf.ru/schema/cdm/cerberus/enterprise/ws-definitions">
<listOptions xmlns="http://api.vetrf.ru/schema/cdm/base">
<count>100</count>
</listOptions>
<enterprise xmlns="http://api.vetrf.ru/schema/cdm/cerberus/enterprise">
<name>Проксима</name>
</enterprise>
</getRussianEnterpriseListRequest>
</Body>
</Envelope>
//////////////////////
это код программы
Процедура getRussianEnterpriseListRequest()
ListOptions = ФабрикаXD.Создать("http://api.vetrf.ru/schema/cdm/base", "ListOptions");
ListOptions.count = 100;
enterprise = ФабрикаXD.Создать("http://api.vetrf.ru/schema/cdm/cerberus/enterprise", "Enterprise");
enterprise.name="Проксима";
getStockEntryListRequestDO = ФабрикаXD.Создать("http://api.vetrf.ru/schema/cdm/cerberus/enterprise/ws-definitions", "getRussianEnterpriseListRequest");
getStockEntryListRequestDO.ListOptions = ListOptions;
getStockEntryListRequestDO.enterprise = enterprise;
EnvelopeDO = ФабрикаXD.Создать("http://schemas.xmlsoap.org/soap/envelope/", "Envelope");
EnvelopeDO.Body = ФабрикаXD.Создать("http://schemas.xmlsoap.org/soap/envelope/", "Body");
EnvelopeDO.Body.Добавить(ФормаXML.Элемент, getStockEntryListRequestDO.Тип().URIПространстваИмен, "getRussianEnterpriseListRequest", getStockEntryListRequestDO);
ТелоXML = Новый ЗаписьXML;
ТелоXML.УстановитьСтроку("UTF-8");
ФабрикаXD.ЗаписатьXML(ТелоXML, EnvelopeDO);
ЗапросWeb = Новый HTTPЗапрос("platform/services/ApplicationManagementService");
ЗапросWeb.УстановитьТелоИзСтроки(ТелоXML.Закрыть());
СоединениеWeb = Новый HTTPСоединение("api2.vetrf.ru", 8002, login, password,,Истина);
ОтветWeb = СоединениеWeb.ОтправитьДляОбработки(ЗапросWeb);
Если (ОтветWeb.КодСостояния = 200) Тогда // значит, все ок
ОтветXML = Новый ЧтениеXML;
ОтветXML.УстановитьСтроку(ОтветWeb.ПолучитьТелоКакСтроку("UTF-8"));
MercAppDO = ФабрикаXD.ПрочитатьXML(ОтветXML, EnvelopeDO.Тип()).Body.getRussianEnterpriseListResponse;
КонецЕсли;
КонецПроцедуры
(11) на самом деле в меркурии есть 2 типа запросов: синхронные и асинхронные. в первом случае вы сразу получаете ответ, во втором - отправляете на обработку, получаете applicationId и смотрите пока его статус не станет Confirmed.
запрос getRussianEnterpriseListRequest - синхронный. его можно выполнить вот так:
СтрокаТела = ТелоXML.Закрыть();
ЗапросWeb = Новый HTTPЗапрос("platform/cerberus/services/EnterpriseService");
ЗапросWeb.УстановитьТелоИзСтроки(СтрокаТела);
ОтветWeb = СоединениеWeb.ОтправитьДляОбработки(ЗапросWeb);
ХмлОтвета = ОтветWeb.ПолучитьТелоКакСтроку("UTF-8");
Иван, спасибо за ответ. За это время я уже нашел ошибку. принцип запросов- ответов Меркурий, я понял из документации,
я в этом объекте
ЗапросWeb = Новый HTTPЗапрос("platform/services/ApplicationManagementService");
не поменял на
ЗапросWeb = Новый HTTPЗапрос("platform/cerberus/services/EnterpriseService");
поэтому меня сервер и не понимал, все исправил, работает.
еще раз спасибо.
может подскажете по другому вопросу.
guid своего ХС я получил по ИНН через метод getBusinessEntityListRequest
для оформления произв.операций мне надо guid предприятия- это что-то другое, пытаюсь получить по методу getRussianEnterpriseListRequest, но там по фильтру наименования не может найти, выводит по 1000 шт. у вас работает фильтр ( если вы пользовались этим методом)?
(13)
можно поискть в getBusinessEntityByGUID в поле activityLocations. если там нет, то думаю проще создать через веб-интерфейс, или привязать существующее через веб-интерфейс. чтоб не заполнять адреса ikar можно попробовать создать без адреса с помощью ModifyEnterpriseOperation.
Или еще вариант - получить все предприятия из системы в цикле изменяя offset в ListOptions для запроса getRussianEnterpriseListRequest
(16)добрый день, смотрел по этому методу, пусто в поле activityLocations, уже делал как Вы советуете в цикле перебрал все записи по запросу getRussianEnterpriseListRequest, искал по полю owner гуид нашего ХЗ, не нашел. в интерфейсе Меркурия не нашел где предприятие создается (в тестовой версии), надо в икаре это делать что-ли?
(23) вот про это не знал, спасибо
(24) да, вам должны были дать два логина, один юрлица типа oooRomashka-123456 и второй пользователя типа Pupkin-iv-123456, вот второй и нужно в поле логин
28.
spectre1978
6024.05.17 12:48 Сейчас в теме+1 $m
(26) не совсем так. Один логин - это логин (и пароль) для авторизации в Ветис.API. Он дается на организацию обязательно - без него не получится работать через шлюз. А вот логина в веб-интерфейс у вас, как у организации, на самом деле может и не быть - достаточно логина приходящего ветврача, который можно указать в программе для дальнейшей передачи в initiator->login. Т.е. ветврач заходит в систему через данные предприятия, но заявку на ВСД создает, указывая свои данные.
И если вы при получении доступа к Ветис.API не сообщаете, что вам нужен доступ к Web - вам его никто и не даст. Полезно иметь это в виду, чтобы потом не обращаться второй раз.
(23)фильтр по наименованию работает нормально, если запрос формировать средствами 1С. я проверял на других предприятиях. и по адресу и по наименованию фильтр работает. в моем конкретном случае просто нет моего в списке предприятий.
пример рабочий
(27) Ну вот у меня по латинице и цифрам фильтр работал, а по кириллице нет, пока явно не прописал заголовок
(36) Я одним глазом глянул. Не понравилось, что это отдельная конфа с обменами, которые чуть ли не в ручную нужно прописывать. Чтобы встроить ее в ту же УТ, чтоб было аналогично ЕГАИСу и ШУБОИСУ, нужно очень долго пилить. Ну и все самое интересное закрыто компонентой.
(37) о как, про компоненту не знал. Что именно компонентой сделано, не разбирались?
Что касается того что это отдельная конфа - может, и неплохо, потому что этот меркурий поначалу будет изрядной мусоркой и тащить его в базу предприятия может быть не особенно хорошо.
(38) Компонента это защита обработки. Там обработка зашифрована, и когда к ней происходит обращение - проверяется ключ. Если ключ есть, то обработка расшифровывается в память и работает оттуда, после чего убивается.
Не очень удобно при отгрузках с РТУ/ордерами работать в одной базе, а с вет. документами в другой. Особенно когда хочется в печатной форме от рту присабачить штрихкоды с ссылками на ВСД
да intiator - это пользователь , объект у которого есть свойства UUID и LOGIN, можно использовать любой, где взять UUID пользователя я не знаю (не искал), поэтому определяю его через LOGIN, полученный при регистрации Ветис.API.
22.
spectre1978
6024.05.17 08:47 Сейчас в теме+1 $m
3) Создание площадок (они же "поднадзорные объекты" или "предприятия") в Меркурий.
Сейчас в другом регионе, если нет площадки, ее может создать только ветврач. Есть ли более простой способ?
Есть. Нужно получить веб-логин в системе Меркурий.ХС, для этого требуется подать заявку во Владимир (разработчикам). В дальнейшем вам в вашей системе надо будет поддерживать два веблогина - один врача, для заявок на работу с ВСД, и второй ваш, для заявок на работу с хозсубъектами. Я получил такой логин и сейчас благополучно создаю то что мне надо. Но следует иметь в виду, что к данному вопросу нужно подходить ответственно. Если вы не будете тщательно искать площадки и создавать дубликаты, соответствующие ветуправления областей могут иметь к вам претензии, заставлять аннулировать сертификаты и удалять точки. У меня была ситуация, что ветврач понасоздавал точек торговой сети, не поискав как следует, в результате пришлось заниматься аннулированием десятка-другого ВСД.
п.52 Приложения 2 Приказа МСХ РФ от 27.12.2016 г. № 589.
"Гашение ВСД на транспортную партию подконтрольного товара, перемещаемого со сменой владельца или без смены владельца осуществляется в течение 1 рабочего дня после доставки и приемки подконтрольного товара в месте назначения зарегистрированным пользователем ФГИС с правом доступа "гашение сертификатов"".
А далее зам. руководителя РосСельхознадзора Николай Власов тоже говорит что гасить нужно.
Так что - магазинам тоже нужен будет доступ к АПИ)
В пределах своего региона площадки может создавать через API любой подключенный от юрлица пользователь с правами ветврача, но при этом надо еще заполнять правильно адреса из системы ИКАР - получать все guid городов и улиц в своем регионе. Ну хотя бы эти адреса можно заполнить один раз.
Вытащил себе из икара нужные регионы вместе с гуидами в локальную базу и передаю гуиды в запрос на создание точки. Имея права на Меркурий.ХС - могу создавать как у себя, так и в других регионах. Ветврач, кстати, не может, у него права только на свой регион... Похоже, то же самое - выкачивать в локальную базу - придется и со StockEntry, потому что сейчас в API нет никакого механизма, который бы позволял выбрать конечный остаток, скажем, по конкретной продукции/материалу или или хотя бы по виду продукции. Есть всего два "регистровых" запроса - getStockEntryList и getStockEntryChangesList. Первый вытаскивает конечные остатки, но по всей имеющейся на предприятии номенклатуре и всем партиям. Объем может быть колоссальным, никакой фильтрации не предусмотрено. Второй тянет изменения журнала в пределах ограничения по датам, можно даже получить конечный остаток, если последнее изменение попало в диапазон дат. Вот и весь выбор операций с данными в складской системе... Я был бы очень рад, если бы я ошибался, кто знает больше - поправьте меня, пожалуйста...
(32) да, со StockEntry непонятно, я вот тоже думаю если появляются входящие ветсертификаты - как определить сколько количества и с какой StockEntry списать при производстве. Пока также делаем производство "из воздуха" без сырья.
Суть вопроса, как я понимаю, в том что надо сохранять в 1с инфу о пришедших StockEntry, особенно о виде продукции subProduct и наименовании продукции productItem.name. Потому что если не сохранить, то потом остатки не найти через АПИ.
35.
spectre1978
6026.05.17 10:43 Сейчас в теме+1 $m
(34) определять - если по-правильному, то только руками или используя штрихкодирование для идентификации нужной партии. Т.е. человек, который будет оформлять производство, должен знать, какое именно сырье взяли технологи, и списать именно его. Иначе никак не проследить, из какого сырья что сделано. На практике, ясное дело, будут списывать первое попавшееся. Тем более что одно мясо от другого мяса отличить в некоторых случаях бывает сложновато...
Я представляю себе так - при загрузке или в процессе выполнения регламента выкачиваем кон. остатки по партиям (getStockEntryList) и куда-то сохраняем, скажем в специальный регламентный документ, который потом проводится и создает движения. Делаем это, например, в начале дня. Дальше, проводя ветеринарные документы, проводим также и движения по остаткам, таким образом ведется двойной учет - у нас локально и в Меркурии удаленно одно и то же. Храним меркуриевские сток-энтри гуиды у себя - это позволяет нам формировать корректные запросы на создание ветдокументов. А если есть подозрения что произошли расхождения - опять заказываем регламентную выкачку сток-энтрисов из Меркурия и по ней инвентаризируем нашу базу, приводим остатки в соответствие с Меркурием. По-другому я не вижу как можно сделать. Регламент по выкачке будет делаться долго, возможно очень долго - это минус. Но если все сделать аккуратно, я не думаю что в нем часто будет необходимость.
Суть вопроса, как я понимаю, в том что надо сохранять в 1с инфу о пришедших StockEntry, особенно о виде продукции subProduct и наименовании продукции productItem.name. Потому что если не сохранить, то потом остатки не найти через АПИ.
На самом деле там есть еще справочник продукции и после занесения туда данных становится доступен GUID продукта. Т.е. в отношении своей продукции можно вести справочник и в дальнейшем сохранять ссылку на него. Но на практике я пока не не очень понял, как это сочетается с также имеющимся механизмом свободного ввода productItem.name при указании product и subproduct. В реальной ИС такой двойственный подход может создать достаточно тяжелую ситуацию - строки в регистрах хранить точно не дело :)
примерно так ублюдочно и работает, первое время у меня работала схема:
ночью регламентным заданием формируется выпуск планового объёма продукции
в течении дня вет.врачи оформляют ВСД, кодом подбираю подходящие по срокам годности остатки записей журнала
на следующий день, дперед формированием новых производственных партий - запускалась процедура инвентаризации, которая приводила в соответствие остатки записей журнала с фактическими остатками партий
но как бы я не старался - всё равно возникали нештатные ситуации, когда остатков было недостаточно - приходилось генерить новые производственные партии, останавливать работу вет.врачей на период синхронизации записей журнала Меркурия и складских остатков
в результате переделал так: в момент оформления ВСД врачём генерируются производственные партии с нужными сроками годности и тут же списываются в 0 документом транзакции
выпуск продукции происходит "из воздуха" - система пока позволяет, в моём случае вет.врачи согласились на такую схему, потому что мы и производитель и продавец - в одном лице, плюс сырьё для выпуска продукции - живая птица, выращивается и забивается в рамках одной производственной площадки
как кто выгручивается с реальными остатками партий и остатками Меркурия - подумать страшно, потому как механизм работы с остатками куцый до невозможности...
в результате переделал так: в момент оформления ВСД врачём генерируются производственные партии с нужными сроками годности и тут же списываются в 0 документом транзакции
выпуск продукции происходит "из воздуха" - система пока позволяет, в моём случае вет.врачи согласились на такую схему, потому что мы и производитель и продавец - в одном лице, плюс сырьё для выпуска продукции - живая птица, выращивается и забивается в рамках одной производственной площадки
Угу, в принципе интересная тема, наверно, сделаю также (сейчас у меня один вид "колбасные изделия и деликатесы" на всю накладную). Весь вопрос в том, что это опять ненадолго, максимум до конца года, потом, скорее всего, забанят "воздушную" продукцию и могут запретить даты изготовления, не равные текущей. Диапазоны дат точно запретят, об этом уже говорили. На перспективу есть мысли, как выкручиваться? Я уже думаю на предмет того, что может быть, производить некий полуфабрикат, скажем "фарш", списывать в него сырье, а потом уже из него делать колбасу по мере надобности. Не думали про такой вариант? Можно делать несколько видов "фарша". В принципе, такая схема близка к правде, потому что из одного замеса могут набивать разные виды колбас.
(43) о, а где говорили про диапазоны дат, я не видел? я сейчас в принципе и так только firstDate указываю, а не диапазон.
насчет "фарша" - можно, да. вообще по табличке
Табличка Ограничений на вырабатываемую продукцию если вам поступают полутуши (с видом Мясо и мясопродукты), а не живые животные, из них можно сразу производить Готовую Продукцию без фарша)
вопрос какое количество из stockentry списывать - либо считать пропорцию сколько колбасы получается из туш, либо при поступлении связывать ЭВСД с партиями на складе, списывать в производство меркурия какое-то примерное количество, а в конце дня/смены делать инвентаризацию, чтоб остатки сошлись. Достаточно непростой вопрос, пока не вижу простого решения. Если заморочиться - можно для каждого документа производства в 1с делать производство в Меркурии, и тогда количество будет сходиться.
о, а где говорили про диапазоны дат, я не видел? я сейчас в принципе и так только firstDate указываю, а не диапазон.
Сейчас там разрешено задавать диапазон дат - firstDate и secondDate. Может, конечно, это и не совсем диапазон, а просто две даты - но выглядит именно как диапазон. Кроме того, есть возможность задать дату неформально, т.е. в свободной записи, что вообще делает бессмысленным всякое датирование - для этой цели там есть строчка informalDate.
А о том что с нового года будет допускаться только одна дата изготовления, говорилось на вебинаре, который проводила компания Э-КОМ (EDI-провайдер) для своих клиентов примерно полмесяца назад (спикером была сотрудница ВНИИЗЖ). Если нужны полные выходные данные вебинара, могу поискать и привести здесь. Лично своими ушами не слышал, на вебинар отправил заместителя, и он мне сообщил об этом моменте как о существенном - что планируется оставить одну дату. Как-то так.
(45) Может под запрет все таки запись в свободной форме попадет? Вот про это даже я слышал. Ее то ли уже нельзя указывать на боевом или тестовом контуре, то ли нельзя будет с ближайшего обновления.
(46) Дословной информации у меня нет. Но насколько понял я, речь идет о том что должна быть одна четкая дата изготовления. Со временем, если срок хранения продукции исчисляется часами. Зачем вообще делали неформальную дату - я не очень понял, это ж потенциально огромный геморрой - партии заморозки могут лежать годами, и если им ввели такую дату, то гадить своим присутствием они смогут еще долго. И нужно забивать голову тем чтобы обрабатывать такие партии, у которых не работают никакие вычисления на датах.
мне немного проще - у нас полный цикл на предприятии от выращивания птицы до выпуска готовой продукции, а выращивание птицы - можно выполнять из воздуха, т.е. получится:
из воздуха -> выращивание птицы
из живой птицы -> тушки птицы
тушки птицы -> готовая продукция
и я думаю это устроит всех более чем полностью, конечно остаются всякие специи и вспомогательные ингридиенты, часть из них при получении я смогу так же передать в Меркурий, но это дело относительно не близкое
в итоге, в момент оформления транзакции на отгрузку - будет формироваться цепочка вышеперечисленных транзакций, порядка минуты в чистом виде
(47) а специи и вспомогательные вообще-то надо? Они же не подконтрольные. Мне казалось, что к этой системе имеют отношение только продукты растительного и животного происхождения, подконтрольные россельхознадзору. Что не подконтрольное - то через систему не проводим.
кстати, господа, никто не смотрел управление ветсертификатами от 1С? Там не совсем 1С, но продают обычные 1Совские франчайзи. Как оно, рабочее, не совсем? Я заказал себе демо-ссылку, вот жду...
а ни у кого не было ли ошибки при транспортной операции? поле vetCertificate правильно заполнено...
<apl:error code="APLM0071" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">VetDocument properties do not correspond one of valid transaction types.</apl:error>
А вот опять вылезло, пробовал произвести живых животных, вылезла ошибка
MERC01263
Указанная единица измерения не разрешена для данной вырабатываемой продукции
Пробовал и кг, и штуки.
Оказалось подошла ед. изм. голова с uuid 06979926-053d-11e1-99b4-d8d385fbc9e8
затем вылезли еще 2 ошибки
MERC02214 Период нахождения животных на территории таможенного союза обязателен для заполнения.
и ошибка
MERC02216 Место для карантинирования обязательно для заполнения.
что еще нашел:
При производстве живых животных заполняю в запросе ProductionOperation поля
expertiseInfo, immunizationInfo, cargoInspected и прочее
и в TransportOperation тоже
в итоге в веб-интерфейсе они не заполнены!
производство http://clip2net.com/s/3KXjfro транспортная http://clip2net.com/s/3KXjqAb
то же с полем "Входящий ВСД"
заполняю precedingVetDocuments - и оно пустое в веб-интерфейсе.
(55) пробуйте подбором. если входная была в кг, даже не знаю, можно ли поменять.
(56) не очень понял зачем вы устанавливаете на входное сырье. Если вам приходит ЭВСД, то там уже указаны параметры. если бумажный - тогда надо делать инвентаризацию или операцию поступления с бумажным всд.
При расфасовке unit меняете?
и ещё один вопрос по произв.операции:
мы покупаем желатин весовой, для сырья по справочнику для входной операции устанавливаю ProductType=5, Product=желатин( uuid из справочника), subProduct=желатин говяжий( uuid из справочника).
для производственной операции по выпуску ГП из этого желатина (расфасовали по пакетам) указываю те же параметры ProductType=5, Product=желатин( uuid из справочника), subProduct=желатин говяжий( uuid из справочника).
это правильно?
ошибка выходит: error code="MERC01263" qualifier="PB_2d373231383737303531303839393837" Указанная единица измерения не разрешена для данной вырабатываемой продукции
сейчас делаю прием входящих сертификатов и есть вопрос, что будет если остатки записей Складского Журнала будут "зависать" на остатках? то есть партию приняли, создалась на нашем Предприятии запись и дальше с ней ничего не происходит, она так и висит и не расходуется в производство. нужно ли делать инвентаризацию на такие записи?
нашел ОШИБКУ при оформлении через API производства.
делаю ProductionOperation, указываю в поле vetDocument поля cargoInspected и cargoExpertized в true
а в веб-интерфейсе они все равно не заполнены, написано "не подвергнута ветеринарно-санитарной экспертизе"
вот пример запроса
https://pastebin.com/Pc6TcSV1
(61)а распечатку пробовали делать? Именно по нажатию кнопки "печать"? Кажется, я раньше уже с таким сталкивался - в мордочке показывает что не подвергнуто, а на печати все нормально.
И еще кто не в курсе Минсельхоз организовал рабочую подгруппу по вводу ФГИС Меркурий координация которой осуществляется в телеграмм. Приказ во вложении.
Коллеги, не знаю у кого как, но с сегодняшнего дня посыпались ошибки: не проходит контроль запрос на оформление транспортной транзакции, по причине не заполненных полей.
Delivery[0] There are several vetDocuments without FOR attribute. Only one common vetDocument (without FOR attr) is allowed.
Delivery[0] When use common vetDocument pattern only one vetDocument (common, without FOR attr) is allowed in document list.
добавил эти поля в запрос
ID в consignment и for в accompanyingForms.vetCertificate
впихивал туда нумератор строковый, гуиды строкой - в любом случае не нравится тип
Wrong application data format. Format validation failed due to XML Schema rules: Недопустимое значение '6cb81b2f-6f59-4b5e-8661-85fd6fe37160' для атрибута: 'id'
// http://vetrf.ru/vetrf-forum/posts/list/825/6855.page#41188 // В случае если вы передаете в запросе несколько объектов consignment ("..Request/delivery/consignment")
// и несколько объектов vetCertificate ("..Request/delivery/accompanyingForms/vetCertificate")
// то связь между ними должна быть установлена путем указания атрибутов "id" - у элемента consignment
// и "for" - для элемента vetCertificate.
//
// В случае если вы передаете в запросе несколько объектов consignment и один объект vetCertificate,
// то атрибуты id и for могут быть не указаны,
// но в этом случае информация из единственного элемента vetCertificate будет распространяться на все ВСД,
// оформляемые в этом запросе.
//
// http://vetrf.ru/vetrf-forum/posts/list/825/6855.page#41192 // Возможно, что неверно указали значения для атрибутов id и for.
// Их типы ID и IDREF, соответственно, и должны начинаться с "_" или буквенного символа.
Показать
собственно обо всём знал, кроме последней строки, теперь генерю эти идентификаторы строкой
и всё работает... что самое смешное - ссылка на форум ведёт к моей же переписке с разработчиками, где они ответили на счёт типов идентификаторов, а я ответ прохлопал и забил на это дело пол-года назад, так бы и не упало сегодня ничего
Коллеги, ситуация слегка запутанная, от разработчиков ответа пока не дождался, обращаюсь к коллективному разуму:
есть ХС1 и ПО1, ранее по ним всё работало от производства до реализации и вопросов не было
появились ХС2, ХС3, ПО2 и ПО3, где ХС3 - занимается реализацией, а ХС1 и ХС2 производством, ну и ХС1 пока ещё реализацией, пока все клиенты не перезаключат договора с ХС3
По словам разработчиков, после отправки наших заявлений - они выполнили привязку ХС2 и ХС3 к APIKey изначально выданному ХС1
На тестовом сервере они этого точно не сделали, а на рабочем пытаюсь получить список записей журнала и входящих оформленных ВСД методами GetStockEntryListOperation и GetVetDocumentListOperation
При отправке запроса GetVetDocumentListOperation получаю разное
1. от ХС1: получаю список входящих ВСД, но только часть из тех что видны через web-интерфейс вет.врачу, ещё часть почему-то недоступна через шлюз
2. от ХС2: MERC31383 "Хозяйствующий субъект-инициатор запроса должен быть связан с обслуживающим предприятием"
3. от ХС3: вообще ничего, хотя ВСД есть в наличии в web-морде
При отправке запроса GetStockEntryListOperation получаю разное
1. от ХС1: не пытаюсь запускать, поскольку работа через шлюз идёт больше года и записей в журнале - вагон, а фильтров у этого запроса нет, попробовал один раз и устал ждать пока все данные получу
2. от ХС2: MERC37383 "Хозяйствующий субъект-инициатор запроса должен быть связан с обслуживающим предприятием"
3. от ХС3: четыре каких-то левые записи, которых в веб-интерфейсе нет
Во всех случаях при отправке запросов указываю enterpriseGuid того ПО, которое доступно вет.врачам через web-интерфейс, мои мысли на этот счёт:
по ХС1 - почти всё в порядке, кроме утери части входящих ВСД, но это пока не критично
по ХС2 - несколько вариантов: разработчики НЕ привязали ХС2 к APIKey ХС1 и потому данные получить нельзя, ещё идея - вет.врачи привязали ПО2 к какому-то ХС, не тому которого разработчики привязали к APIKey ХС1
по ХС3 - нет предположений
Что-то не так с пространством имён или как дать понять сервису что необходимо получить с одного Предприятия те или иные данные принадлежашие конкретному ХС?
Пытаюсь привязать предприятие к хс, через функцию modifyActivityLocationsRequest, для нее нужно заполнить параметр modificationOperation с типом BEActivityLocationsModificationOperation. У BEActivityLocationsModificationOperation есть реквизиты, которые не получается заполнить:
ХсГУИД = ЭлементыФормы.НайденныеХО.ТекущаяСтрока.guid;
BusinessEntity = Прокси.GetBusinessEntityByGuid(ХсГУИД); (тут всё находит)
BEActivityLocationsModificationOperation = ФабрикаXD.Создать("http://api.vetrf.ru/schema/cdm/cerberus/enterprise", "BEActivityLocationsModificationOperation");
BEActivityLocationsModificationOperation.type = "FIND_OR_CREATE";
BEActivityLocationsModificationOperation.businessEntity = BusinessEntity; (а тут выдает ошибку, скрин во вложении)
У всех все в порядке с упаковками? А то до меня дошли слухи, что в Меркурий выкатили новые упаковки, но апи для их получения нет, а предопределенные значения все еще старые http://help.vetrf.ru/wiki/PackingForm
(78) я пока жду разведчиков, которые соберут глюки и попинают разработчиков, те починят самое кривое, а потому буду пилить
хотя есть слух что старт Меркурия переносится на пол-года
https://www.esphere.ru/press/mercury-perenos-srokov
(80) Татьяна, день добрый.
Была подобная ошибка, решилась входом на Ветис.Паспорт и сменой пароля пользователя присвоенного при регистрации (как сказала поддержка - тестового пароля). Так что попробуйте сменить пароль.
81.
user610556_9159530134
01.11.17 16:36 Сейчас в теме
Добрый день.
Может кто нибудь скинуть пример работы с меркурием, в частности интересует как добавлять подназорные объекты методом ModifyEnterpriseOperation.
Добрый день.
Может кто нибудь скинуть пример работы с меркурием, в частности интересует как добавлять подназорные объекты методом ModifyEnterpriseOperation.
84.
user610556_9159530134
21.11.17 15:50 Сейчас в теме
Добрый день.
Подскажите по ошибке:
<errors><apl:error code="MERC02275" qualifier="_consignment1" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Идентификатор записи складского журнала продукции обязателен для заполнения.</apl:error>
Пытаюсь создать транспортную операцию, в ней указывают две производственные партии, в id указываю _consignment1 и _consignment2, так же указываю для вет документов эти данные, версия 1.4
Добрый день.
Подскажите по ошибке:
Идентификатор записи складского журнала продукции обязателен для заполнения.
Пытаюсь создать транспортную операцию, в ней указывают две производственные партии, в id указываю _consignment1 и _consignment2, так же указываю для вет документов эти данные, версия 1.4
Разобрался, но оказалось что ошибка была не там где я думал
87.
user610556_9159530134
28.11.17 14:48 Сейчас в теме
Возникла проблема.
При отправле ВДС через шлюз (версия 1.4) мы указываем тип транспортного средства 1 (автомобиль) и все остальные данные, при частичном гашении такой ВСД все проходит без проблем, если транспортную ВСД создавать через веб-интерфейс, то при частичном гашении по входным данным мы не можем получить тип транспортного средтсва, так как во входном ВДС его просто нет. Если тип не указан возникает ошибка "APLM0007 Wrong application data format. Format validation failed due to XML Schema rules: Элемент 'transportInfo' не предусмотрен", если его назначить как 1, то ошибка другого рода "MERC15234 Транспорт в сведениях о возврате продукции должен совпадать с указанным в ветеринарно-сопроводительном документе". Как можно обойти данную ошибку?
Добрый день! Пытаюсь создать новый ХС через Ветис.Api, запрос все сформировал, отправляю, получаю ответ, и пишет что
<?xml version="1.0" encoding="UTF-8"?>
<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>82594528-4b57-42fa-b4e4-f9f655ebb13a</applicationId><status>REJECTED</status><serviceId>mercury-g2b.service</serviceId><issuerId>fd8820a2-bb3f-4032-9584-9bc78c20fab1</issuerId><issueDate>2018-02-08T11:07:26.000+03:00</issueDate><rcvDate>2018-02-08T10:07:27.000+03:00</rcvDate><prdcRsltDate>2018-02-08T10:07:27.000+03:00</prdcRsltDate><errors><apl:error code="APLM0002" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Unsupported application data format</apl:error></errors></application></receiveApplicationResultResponse></env:Body></env:Envelope>
Я понимаю что где то ошибка в запросе, но никак найти не могу, уже все перепроверил. Помогите плз решить проблему.
Код формирования запроса ниже
Господа, кто то налаживал интеграцию для ветеринарии именно? Там и шлюз другой и т.д. Есть такие? Мне заказала ветеринория региональная, апи получил, опыт комерческих мясозаводов успешный есть, а вот там жесть. Есть кто пробовал ветеринарию, на подконтрольные субьекты а не на саму себя?