Сообщения, отправленные пользователем: RomanWBD

Добрый день, коллеги.

Объясните пожалуйста зачем при оформлении возвратного ВСД поставщику в момент гашении ХС должен указывать условия для правил регионализации.
Почему эту информацию не брать автоматически из входящего ВСД поставщика в момент оформления возвратного ВСД, а то получается следующая ситуация, что я продукцию не прининял и вернуть его не могу без предварительной проверки правил регионализации. В чем суть данного процесса и почему это должен делать принимающий ХС? Почему не сделать проброску тега <dt:condition> автоматически на уровне БД Меркурий без указания на уровне XML сообщения.

Возможно ли такая ситуация, что мне поставщик отгрузил продукцию, а мы по правилам регионализации не сможем её вернуть? Если да, то прокомментируйте, что мы должны делать в данной ситуации.

Да похоже, что адрес сервера API 1.4, а не API 2.0.
Должен быть указан вот этот EndPoint: https://api2.vetrf.ru:8002/platform/services/2.0/ApplicationManagementService

А сейчас он возможно такой:
https://api2.vetrf.ru:8002/platform/services/ApplicationManagementService

В поправке к закону этого разделения нет(рыба, мясо и т.д.), ниже выдержка из самой попправки:

1) часть 2 изложить в следующей редакции:
«2. С 1 июля 2018 года оформление ветеринарных сопроводительных
документов производится в электронной форме, за исключением случаев,
установленных частью 21 настоящей статьи.»;
2) дополнить частью 21 следующего содержания:
«21. С 1 июля 2018 года оформление ветеринарных сопроводительных
документов осуществляется на бумажном носителе в случаях:....
3) в части 3 слово «января» заменить словом «июля»;
4) в части 4 слово «января» заменить словом «июля».

Александр Александрович wrote:Всем ДВС! Такой вот вопрос: в журнале продукции после нескольких отписок с партии продукции пропадает количество и упаковка остается только вес при следующей отписки в чем может быть проблема???

Cкорее всего в некачественном тестирование и отладке ключевых операций Меркурия от записи журнала до ВСД после очередного обновления. Как у нас бывает - сделал прямую цепочку, увидел что работает и забыл...

Коллеги,
почему не получается погасить ВСД через API 2.0 для записи журнала которому не присвоен производитель(там просто пусто на уровне ВСД)? При попытке гашения выдает ошибку MERC14237 Укажите список производителей, сделайте чтобы производитель был всегда обязательным полем в Web версии. Потому что сейчас, если кто-то и создаст входящий остаток в журнале остатков без указания конкретного производителя и сформирует для него Транспортный ВСД, то ХС получатель просто не сможет его погасить через шлюз, только через Web.

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

Порядок действий:
1. Сделал инвентаризацию (входной продукция - > добавить) на 1000 кг, указал для него завод-производитель.
2. Сформировал транспортный ВСД на 1000 кг с этой записью журнала.
3. В транспортном ВСД поле "Выработанная" пустое.
4. При попытке гасить в API2.0 ошибка, но при этом в Вебе погасить дает без проблем.

Вопрос как узнать производителя, если эту запись в журнале создал другой ХС? И при чтении ВСД эта информация не передается.

С учетом того, что в шлюзе при гашении сделана проверка на производителя, при этом Веб версия не соответствует логике работы шлюза.
Чтобы изежать таких ошибок нужно тогда сделать поля "Страна происхождения", "Производитель", "Страна производителя" обязательными полями при добавлении входной продукции(бумажная справка) и инвентаризации-добавлении входящей продукции + всегда пробрасывать эти поля в Транспортный ВСД и возвращать эти теги при чтении ЭВСД.

Ну или вторая опция, вообще не проверять эти поля при гашении через API 2.0.

Видимо не всее так просто и без полного отключения не получается. Ждем и надеемся, что скоро заработает.

Стабильной работы тестового шлюза 2.0 пока не наблюдается..

Александр Осминин wrote:

RomanWBD wrote:Коллеги, можно хотя бы делать объявление перед выполнением каких-то работ в тестовом шлюзе, потому что это реально мешает работе.

Можно продолжать работать.

Александр, проверил сейчас тестовый шлюз 2.0, снова не доступен.

Коллеги, можно хотя бы делать объявление перед выполнением каких-то работ в тестовом шлюзе, потому что это реально мешает работе.

1.4 вроде работает, проверял как раз после того как 2.0 перестал отправлять нормальные результаты.

Все делаете так, а вот шлюз API 2.0 с тестовым Меркурием явно работает не так. Сейчас по этому сервису в ответе всегда возвращается ошибка по любому сервису из ams-mercury-g2b.service_v2.0_pilot.wsdl.

Natalya0303 wrote:Правомерно ли объединять все однородное сырье (например полутуши говяжьи) и потом производить продукцию из этой объединенной записи?

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

Жуковская Н.Б. wrote:У меня вопрос по теме справка о безопасности сырого молока.
1. Можно ли сделать так, что бы не дублировать лабораторные исследования.
Вношу данные в справку о безопасности сырого молока . Затем оформляю транзакцию производство/переработка. И тут приходится заново вбивать данные лабораторных исследований.
2. В транзакции справка о безопасности сырого молока вносится опись животных.
Когда оформляю на следующий месяц справку о безопасности молока приходится вбивать снова эту опись.
И еще вопрос: можно ли вносить несколько номеров ушных бирок в одну строчку?

А вы попробуйдет сделать шаблон на основании уже окончательно сформированного документа.

max_01 wrote:Вопрос: что я делаю не так?

Шлюз имеет два уровня авторизации:
1) Доступ к шлюзу(выдается на ФЛ, ЮЛ) - логин и пароль.
2) Доступ пользователя - логин для входа через браузер.

Текущая ошибка говорить о том, что у Вас на уровне Postmana не определены логин и пароль для первого уровня авторизации - эту информация предоставляет РСХН по запросу ФЛ или ЮЛ.

http://help.vetrf.ru/wiki/%D0%9F%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81_%D0%B0%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8_%D0%B2_%D1%88%D0%BB%D1%8E%D0%B7%D0%B5

Anna P. wrote:Друзья, у меня другая проблема, связанная с GUID товара.
Существует РЦ, куда едут поставщики с бумажными ВСД, вся продукция входит в 646 Приказ.
Может ли уполномоченный сотрудник РЦ для дальнейшего перемещения на другое юр.лицо завести GUID продукции (без ветеринаров)?
Или при заведении GUID - нас автоматически начнут расценивать как производителя и нам нужно будет воспользоваться услугами ветеринаров?

GUID(Product Item) продукции должен создавать только производитель(переработчик).
В вашем случае любое перемещение продукции, указанной как исключение в 646(не подвергнутое обработке или не упакованное), на другое РЦ допустимо оформлять только с полномочиями ветврача.
И полномочия уполномоченного лица здесь не помогут. В тестовой системе этого ограничения нет, но в продуктивной системе говорят работает.