Ветис "победно" шагает по стране. Хочется иногда попросить помощи. Поплакаться. Рассказать о своих проблемах и решениях. Для этого ветка и создана

Лично наш распределительный склад на 50 магазинов. Пока еще не оформляет сопроводительных ВСД. Работает по старому. Однако должны запуститься. Пока гасили все входящие ВСД. Инвентаризацией обнуляли остатки в Меркурии

а что с правовой точки зрения означает ситуация, когда мы ВСД выпустили, клиент не гасил/возвратных не выпускал, а товар (частично) вернулся.

Мы формально имеем право такой товар принимать?
Как с технической точки зрения правильно это делать - аннулировать свои ВСД и возвращать себе фактические приехавшее количество и оформлять новые ВСД на "чистую" накладную?

Кто нибудь покупал вот эту доработку?
http://catalog.mista.ru/public/857304/
Если да, то вопрос есть
Здравствуйте, что требуется для доработки типовой ТиС чтобы ваша конфигурация заработала на типовой ТиС?
Можно ли работать от нескольких организаций заведенных в ТиС?
а то там автор молчит как рыба

(3) У кб99 покупали для ТиС. Сейчас работает.

https://redmine.kb99.pro/projects

(4) Они там очень сильно много хотят, причем для каждой организации отдельно

(0) Три разные группы компаний.
В первой - ошибка "MERC30127 Указанные предприятие и хозяйствующий субъект должны быть связаны друг с другом".
Тульские госветинспекторы поправляют ошибку, на следующее утро - то же самое. Техподдержка хер забила - не отвечает.

2 и 3 ГК аналогично: по две фирмы. На одной отсутствуют эВСД - синхронизация проходит. На второй околонулевой оборот, постоянная ошибка APLM0012.

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

Если отправка всд хоть боле-менее работает, то получение данных - полная ж.

(7) Проблема с получением входящих ВСД не очень сильная. На одну площадку занимает от 30 до 100 сек. У нас у одного хозяйствующего субъекта 6 площадок, так там минут 5 получает входящие ВСД.
  С остатками тоже примерно такая же проблема. Делал инвентаризацию, обнулил остатки. В меркурии инвентаризация прошла. Но остатки еще несколько минут не менялись.
  Надо настраиваться на время отклика Меркурия несколько минут, и не напрягаться.
  А совсем правильно делать все запросы к Меркурию в фоне с большими таймаутами

(8) с инвентаризациями сейчас проблем много. У меня не проходят с большим количеством позиций к списанию, стараюсь делать не более 10 позиций. Тогда оно более-менее фурычит.

(8)  "А совсем правильно делать все запросы к Меркурию в фоне с большими таймаутами" - это как понять? Делать, например, запрос входящих ВСД один раз в 1-2-...Х минут? Или же опрашивать результат выполнения запроса один раз в 1-2-...ХХХ  секунд? Или же, что скорее всего, сочетание и того, и другого?

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

(11) Я правильно понял, что тикет = applicationId?
Собссно, примерно так и сделано, но пока что в полуручном режиме.

(12) да. Для большого объема запросов других вариантов не видать. Маленький, в принципе, можно и синхронно обрабатывать.

Большим недостатком является еще скудость документации. Практически до всего приходится доходить своим умом, хотя если бы они внятно описали работу той же Versioning Entity, отличие GUID и UUID, прочие базовые вещи простым и понятным языком - всем было бы в разы проще.

у нас пока нет автоочереди с таймаутом, но вручную в 2.0 не получается почти ничего получить. А на 1.4 пришло

Коллеги - было у вас такое, что погасили вы входящий тВСД, в вебморде мерка видно, что он погашен, но соответствующей записи СЖ нема? (к сожалению ответ а гашение утерян, не знаем что там было)

(16) Было другое. Через апи все успешно ушло, а в вебе и у клиента ничего не появилось. Причем сформированные ВСД обновлялись через апи и я даже смог их аннулировать, но в вебе вообще никаких движений по этим ВСД не было.

(16), (17) проблема решиалсь - оказывается мы немного вручную напортачили и система наша решила оформить немного возвратных ВСД )) - аннулировали их и все встало

http://www.vetrf.ru/vetrf/news/27465.html
в воскресенье обещают перекуры до 15 минут

(0)Если работа заставляет плакаться, может ну ее эту работу?

(20) все бы ничего, но вот если пожар - то тут хоть увольняйся (с)

(21) особенно если ты не пожарный, а гасить приходится

Всем привет. Подскажите с получением доступа для хозсубъекта к системе - есть группа компаний и одни и те же пользователи.  Сколько заявлений
о регистрации в ФГИС ВетИС и предоставлении доступа к ФГИС «Меркурий» сотрудникам надо подавать?

(23) они могут сделать одного и того же админа ХС на несколько ХСов.

но заявления нужно писать от каждого ХСа и заверять ЭЦП этого ХСа.

(23) мы подавали на каждый ХС, лицо одно и то же во всех случаях, учетки разные

MERC02129
Впервые налетел. У нас покупателей - на текущий момент осталось 88 битых площадок, и вот теперь первый битый ХС.
http://www.fsvps.ru/vetrf-forum/posts/list/8414.page
Ошибка аналогичная ошибке в этой ветке. ХС есть, по ИНН находится, по GUID тоже, но ВСД транспортную на него не выписать
<apl:error code="MERC02129" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Хозяйствующий субъект, получатель партии продукции, с указанным идентификатором не найден в реестре РСХН, либо идентификатор не соответствует установленному формату.</apl:error>

пора уже заводить ветку "ВЕТИС. Второй месяц работы" :))

Что происходит на фронте ВЕТИС? А то я забросил вндрение ВЕТИС на две недели из за отпуска.
  ВЕТИС еще жив?

(29) Судя по http://www.vetrf.ru/vetrf/news/27598.html, немножко на него подзабили... Но так-то работает вроде. С ошибкой 12 ничего не сделали, так и лезет.

(29) Забили на ВЕТИС почти все...

(31) ну не совсем так. Существенный процент универсамов Х5 в центральной полосе, например, начал гасить ВСД. По состоянию на начало июля гасили только РЦ и частично ГМ (Карусели), и то не все.

А кто-нибудь заметил что  двух видов продукции (третий уровень, ТНВЭД) сменился Гуид - со всеми вытекающими.
У номенклатуры в меркурии недействительный вид продукции, ну и операции с товаром не работают.
14657ed1-9fb7-4d0f-ab30-bbc1779bc9e8
67f10d49-9cfa-64d1-d308-069304a1a873
Путассу холодного копчения и икра горбуши соленая - теперь имеют другие гуиды.

Вот как выглядят последствия (у меня вид продукции подставляется из результатов запроса по GUID номенклатуры)
error code="MERC24019" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">В запросе для вида продукции указан идентификатор устаревшей версии записи реестра РСХН.</apl:error>

Стали дальше внедрять эту ВЕТИС.
Вылазит ошибка MERC14562.
В интернете нашел, что это "название продукции в сведениях о принимаемой партии не совпадает с указанной в ветеринарно-сопроводительном документе".
  Сразу возник вопрос: "Существует ли описание ошибок Меркурия". Или можно ли получить через API описание ошибки  по ее коду.
  Пока описания ошибок не нашел.

(35) В ответе (в xml) вместе с кодом ошибки возвращается её описание.

список возможных ошибок обычно прилагается на сайте внизу описания метода.
http://help.vetrf.ru/wiki/GetVetDocumentByUuidOperation_v2.0
Внизу "Коды ошибок"

В (34) кусок возвращаемого xml.

В Питере частично нет интернета, запасной канал нам включить тоже не смогли. До утра точно интернета не будет. И что РСХН говорит делать в таких случаях? Печатать на защищенных бланках?

(39) "за последний час легли и все ещё мигают Reddit, discord, appear.in, gnu.org и несколько других крупных американских сайтов. И все это во время крупнейшей ежегодной конференции по кибербезопасности DEFCON" // http://pics.wikireality.ru/upload/thumb/f/f3/Kiselyov-2014_66401280_orig_.jpeg/300px-Kiselyov-2014_66401280_orig_.jpeg

По API не всегда выдается описание ошибки. Более того ошибки  MERC14562 нет и в документации.

(41) значит, чет новенькое, не успели внести. Там дока не всегда поспевает вовремя.

Хакеры отакуэ: http://www.vetrf.ru/vetrf/news/27709.html

Столкнулся с ошибкой Меркурия при работе через API
Ошибка MERC02469 Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение)
   Сначала при оформлении возврата поставщику, а потом и при отгрузке чужой продукции в магазин.
   Пару дней убил на изучение Китайской логики работы с регионализацией у разработчиков Меркурия.
   Я просто в шоке.

Короче логика очень интересная.
По описанию системы Меркурий при перевозке товара из точки А в точку Б. Требуется запросить условия регионализации для перемещения товара. Это список болезней, которые должны отсутствовать у перемещаемой продукции. И при запросе на перемещение мы должны указать эти болезни в тексте запроса, подтвердив, тем самым что они отсутствуют. Если хотя бы одна из болезней не указана, то считается что продукция больна и ее запрещено возвращать. И тогда возникает ошибка MERC02469 Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение)

Дальше имеем перемещение товара от производителя по маршруту А -- Б -- В
Оформление возврата:  из точки Б в точку А. Казалось бы надо запросить условия регионализации при перевозке Б -- А, но это не так. Можно запросить условия при перевозке А --- Б. Самое интересное, что эти условия не равны. И это тоже будет ошибка. На самом деле надо указать условия, которые придумал поставщик при поставке продукции и указал их в ВСД
Перемещение Б -- В. Такая же фигня. Надо указывать условия, которые придумал поставщик при поставке продукции.
   Описания этого механизма нигде нет. Он реализован в WEB интерфейсе, а для API даже не описан. Вернее описан совсем другой алгоритм.
   Как народ работает?

(46) Большей частью - никак. Занимается залепухой разной степени залепушности.

коллеги,
подскажите, этот APLM0012 выдается (по идее) только при запросах на получение?

Мы вот отправляем заявку на оформление тВСД (и кровь из носу надо из 1с ки нашей самописной, т.е. через API-2). Получили AppID, но по нему в ответ получаем реджектед с этим же APLM0012.  (и так 70 раз)
Это нормально??
я думал при отправке заявок в обработку (раз уж заявка принята и AppID присвоено) такого быть не должно??

Подскажите плиз.

(48) Если вы СРАЗУ получили REJECTED, то значит ваша тВСД не принята и AppID уже не имеет значения. Возможно, что из-за этого потом ваши запросы просто игнорируются, то есть возвращают APLM0012.

Или я не так понял вами сказанное?

(48) вообще я полагал, что он выдается только в запросах на получение, где тяжёлые ответы и создаётся нагрузка на их серверы. Т.е. главным образом getStockEntryList и getVetDocumentList. На формирование не видел никогда. Речь про api 2.

(49) мы отправили заявку на оформление тВСД. В ответ ACCEPTED (и значит имеем AppID). По этому APPID запрашиваем результат обработки операции - а там APLM0012.

(50)  мы тоже так полагали. теперь сидим и думаем что делать )

(51) Странно конечно же. При отправке тВСД особых проблем нет (т-т-т), в отличие от получения журнала продукции и входящих ВСД. Я не занимался реальными подсчетами, но у нас хватает 40 шагов цикла для отправки тВСД. В реальности - гораздо быстрее, хотя есть тВСД по 20-30 позиций, там ответ размером в 1,5 Мб

тут вот сообщают, что APLM0012 может быть реакцией перегруженного сервера на запрос результат операции (а не сам ответе на обрботку заявки). Т.е. типа (Как я понимаю) получение aplm0012 на запрос заявки по сути означает
"фиг его знает, может провелась, может нет, мы сейчас перегружены, дать ответ не можем".
и соответственно либо заявка провелась (тогда в вебе должны увидеть исходящий) либо отклонена (но причину отклонения увидеть не можем, потому что вместо нее приходит aplm).

(51) Это нормально для Меркурия. такое поведение они называют выравнивание нагрузки. Алгоритм работы примерно такой. Посылаете запрос по API получаете applic,issuerId.
  По этим данным спрашиваете результат запроса.
  Если receiveApplicationResultResponse.application.status="COMPLETED" тогда все нормально.
  Если "REJECTED" и "APLM0012"   ИЛИ "IN_PROCESS" тогда задержку!!! 3 сек и снова запрос
  Если просто "REJECTED" тогда все пропало.

таки были проблемы в самой заявке )
разобрались, успех, нужные данные получили