Ветис уже скоро. А что-то вокруг тишина. В программах даже что-то появилось, а на ИТС ни одной инструкции. Все ждут? или может кто-то что-нибудь делает для подготовки?

Я не уверен, но похоже что если в getProductItemByUuidRequest
Подставить реальный GUID товара, то получаем http ответ не 200, а 500.
error code="20022" В реестре РСХН не найдено подходящих наименований продукции.

В моем случае вместо UUID подставляется GUID товара с  active=false
У нас бывает что вместо GUID поставщик присылает UUID.
Поэтому если запрос на GUID выдал что такого нет, то пробуем проверить не UUID ли это.
По GUID функция вернула что такого товара нет (из-за active=false), а запрос getProductItemByUuidRequest выдает ошибку 500.

Это уже просто жесть.
А если к GUID добавить еще знак, например я дописал в конец "3", то вместо того чтоб дать нормальный ответ, опять падает с HTTP ответом 500
string value
'57796bf2-ea12-47f4-b3dc-b54f3af1009f3'
does not match pattern for UUID in namespace

Походу у них действительно сломался метод. Теперь если UUID в базе есть, то отдает всё по формату, с кодом ответа 200, если UUID нет, то получаем код ответа 500, и внутреннюю ошибку сервера.

Транспортная ВСД. Не знаю есть она или нет, но была выписана 02/07, и был получен GUID ВСД.
Сейчас при попытке получить ВСД по тикету выдает HTTP ответ 500.
Получается я должен и при HTTP 500 обрабатывать полученную XML?

Они что-ли все старые тикеты порезали в базе?

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

(909) Как можно перезапросить?
У тебя при создании транспортной ВСД дается тикет.
Потом по тикету ты получешь GUID ВСД.
Если тикет удален, как ты теперь ссылку на ВСД получишь? Еще одну ВСД выписать?

(910) я постоянно мониторю ответы по тикетам и записываю данные сразу как ответ положительный, после чего тикет мне не нужен.

Я бы с логов поднял обработкой. Но я их стер. :(
Не велика конечно потеря, но неплохо было бы где-нибудь получить полную документацию, в каких случаях HTTP ответ 500, в каких 200. Что хранится на сервере и сколько времени, что уничтожается и т.д.
По уму ошибки 500 быть не должно. Ошибка 500 - то это их внутренняя ошибка.

(911) А у меня получает номер ВСД в момент печати по тикету, и нигде он не сохраняется.
Конечно допишу чтоб сохраняла, но честно говоря я не понимаю как продукт в таком состоянии можно было запускать в продуктив в масштабах страны.

(912) так они просто xml валидируют, поэтому  (905) и не проходит

(914) Если дать uuid по формату, но которого нет в базе - то тоже внутренняя ошибка. Хотя это ненормально.
Должна же быть проверка, есть ли uuid в базе, и она не должна падать с ошибкой. А код ответа http 500 - это по сути и есть падение.

(915) тут согласен

(912) ошибка 500 это ошибка веб-сервера, которая не определена явно другими 5ХХ ошибками. Похоже что они пихнули туда результаты валидации XML, который им приходит в SOAP-пакетах. Собственно, я не вижу причин почему так делать нельзя.

(917) Потому что так делать не принято.
Это соответствует их описанию, но так не делают.

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

(919) Теперь и я сохраняю. А все старые похерены.

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

это я про тикеты. А UUIDы я сохранял изначально. Помимо UUIDов, я подбираю из веток еще кое-какое барахлишко для локальной печати веток (без участия Меркурия).

(921) Зачем? У меня и так всё отлично работает. Я их в любом случае получаю в момент печати. Без него же не распечатать. Теперь как получил буду сохранять.
(922) И тикеты в любом случае нужно сохранять, если ассинхрон как у меня. Конечно сохраняются.

Короче в итоге вернул обратно - код 500 у меня опять равносилен либо пустому запросу, либо REJECTED. Даже не разбираю его. Что конечно-же неправильно.

Вопрос. "Зелененькую машинку" кто-нибудь на API реализовывал? Т.е. возможно ли API двойкой как-нибудь получить все непогашенные входящие? Пока приходит в голову только getVetDocumentListChangesRequest за ближайшие несколько дней и ручками отобрать из массива непогашенные. Но это какое-то извращение...

Похоже, что ответ на мой вопрос кроется в версии API 2.1. Чует мое сердце, что надо переползать...

Довольно интересная прессуха, если кто не видел https://www.youtube.com/watch?time_continue=887&v=CCsPt3uNvdg

По (925) вопрос снят, разобрался

(927) Интересная встреча. Но это только десяток крупнейших производителей и сетей.Каждый из которых вбухал по 100 млн. руб и имеет процент гашения на уровне 30% - 70%. А каково остальным сотням тысяч предприятий. И что будет с системой Меркурий, когда эти предприятия начнут активно работать.

Лично у нас распределительный центр на 50 магазинов. На сегодняшний день мы получаем только на 10% продукции входящие ВСД, и изготовляем 0% исходящих ВСД

(927) Магнит в касте избранных? Похоже из 80 серверов - половина у них. Имхо, нечестная конкуренция и попытка задавить частные сети. Власов всех затыкал, когда разговор заходил не в то русло, а им минут 10 дал поболтать совсем не по-делу.
И да, все кругом идиоты, а у них все шикарно без ошибок.

(931) Вот что животворящий выкуп акций ВТБ делает! :)

(931) вы думаете они х5 задавят.

Я не понял. оборудование меркурия на площадках магнита или на их серверах крутится? или все это магнит задумал

(933) там странная история. Вы статистику смотрели? Магнит обрабатывает четверть всего трафика ВСД. А Х5 - несколько процентов.

(934) обрабатывает или использует ВСД?

(935) http://www.vetrf.ru/vetrf/news/27218.html
Я, правда, не очень понимаю с какой целью Магниту оформлять ВСД, если это розница. Ему их гасить надо... Поэтому все это выглядит странно.

(936) Элементарно. Это их распредцентры генерят.

Поставщики отдают товар не по магазинам а на РЦ, у х5 РЦ меньший траффик видимо.

а ВСД формировать то надо от РЦ в магазин. т.к. перевозка хоть и без смены владельца.

(937) Видимо, у x5 прямых поставок в магазины больше, чем у Магнита.

(937) да, точняк. Но тогда тем более интересно, почему такое различие между Х5 и Тандером. Тандер раньше начал, да. Они требовали ЭВСД еще в середине прошлого года.
(938) Не исключено. Х5 загонять своих поставщиков на РЦ в обязательном порядке стали не так давно как Тандер.

(938) видимо
(939) судя по моим знакомым. тандер стал еще с июня требовать ВСД.
2. с чего. не все возможно в РЦ загнать. У Магнита кстати логистика построена видимо через РЦ. более. чтобы не отвлекать народ в магазинах на поставки. да и поставка на РЦ всегда цена ниже. чем поставщик развозит по магазинам. и у Тандера остается больше бабла.

У Магнита может быть куча распределительных центров, куча магазинов, все от разных юр.лиц. При этом гасить ВСД магазины не могут чисто физически. Получается ситуация как у нас.
  Распределительный склад + 50 магазинов должны генерить 10 млн. ВСД в год. При количестве номенклатуры 1000 позиций.
  А у сетей и магазинов и позиций поболее. Поэтому для крупных сетей  количество ВСД может достигать мрлд. в год.
  Не завидую я им

(941) если прибавить еще алкоголь. то Ит трафик у магазина огого

(933) Я думаю, либо они часть серверов сами купили и поставили Россельхозу под Меркурий под свои нужды, либо пришла директива выделить им сервера чисто под них. Иначе ситуация когда никто не может получить ВСД, а у них все хорошо - выглядит странной.

(943) ну да. Причем если Галицкий еще мог заупрямиться, то теперь-то там зеленая улица. Скажут - сделают.

Либо они сами не понимают в какой ж-пе находятся.

(943) ну это да. что-то тут явно не так

для компаний у кого РЦ тут ве проще. Им не надо в одночасье выплевывать всд в магазины. главное чтобы в РЦ пришло все с ВДС. А далее они оформят когда будет свободно..

Это если поставщик в магазин приводит должно быть уже ВСД. а для своих то поставок такой спешки явно нет. и авто едет из РЦ порой сутки. всегда есть время.

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

(947) Больше всех производители страдают, как собственно обычно.

(948) производителю до РЦ тоже не проблема сделать. хоть в ручную.

а вот если у производителя свой распределенный сбыт. тут вот уже проблема

(949) Между площадками при производстве ничего не перевезешь толком. Через дорогу перевезти - тоже нужно ВСД выписать.

(950) знаю. у нас 3 завода 2-4 км друг от друга. и все 3 находятся в разных раонных ветслужбах.

У меня сейчас Ветис умер. При этом умер он на функции getProductByGuid. Это основополагающая функция. Если она умирает, тогда останавливается весь Ветис. При этом умирал он медленно. Сначала умерла функция getProductByGuid, а через несколько минут - Ветис

(952) У меня если продукт не может получить по guid-у (а проверяет active обязательно, ибо выводят из базы продукцию), тогда инвентаризация, и отгрузка по ТНВЭД (третьему уровню). Ничего не останавливается.

И, кстати, только что делал большую ВСД на 41 позицию - всё нормально, ушло с гуидами. Значит getProductByGuid работает.

Сейчас массово
<apl:error code="APLM0017" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">An unexpected error has occurred while processing target service response.</apl:error>

Как на неё реагировать? Это в ответ на запрос по тикету.

(954) Похоже, что у них в разных регионах разные сервера, и балансировка нагрузки не очень работает...

(955) Вроде позавчера 12 было... Чет новое?

По поводу getProductByGuid ошибочка у меня вышла.
Оказывается что
Родитель второго уровня это  GetProductByGuid
Родитель третьего уровня это это  GetSubProductByGuid
    И если по GUID элемент не найден, тогда возвращается код ошибки 500 - сервис не доступен.

(957) Да. Причем ночью опять всё штатно отработало.
Буду писать список кодов при которых нужно пытаться перевыписать ВСД (ошибка со стороны меркурия), и список с которыми нужно разбираться.

Часть накладных не уехало, потому что по непонятной причине не дало выписать от имени уполномоченного сотрудника, с ошибкой
"MERC02386" Данная транзакция не может быть оформлена, так как роль пользователя не позволяет оформлять ВСД
ПО ТНВЭД
d99981f8-b4a3-4d13-867c-01ed252edb1b
желированные продукты из мяса и субпродуктов (1602)
Это продукция прошедшая термообработку, из 646 приказа.

(960) Назначение какое указали?

(961) Как и все остальные. Реализация в пищу людям

(960) Это была ошибка в меркурии, вроде по нашему обращению поправили. Действительно под этим ТНВЭД уполномоченным не давала выписывать. Завтра проверим.

Что-то ветка затихла.
Насчет APLM20001 - битые площадки.
Вывели полный список - у нас их сотни. И оказалось что проблема решаемая, сотрудником РСХН с достаточными правами. Чтоб решить проблему нужно изменить что-либо в площадке и пересохранить. GUID площадки при этом не меняется. Единственная проблема в правах.

(964) очевидно, все как-то приноровились и работают...

Назначить обновление на пятницу 13-ое это сильно.
https://www.vetrf.ru/vetrf/news/27290.html
Всем причастным к этой загашочной планете рекомендую в выходные не пить, из города не уезжать и быть на связи.
Так хотелось отдохнуть, а придется вздрагивать от каждого звонка. 146% что всё ляжет.

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

вот про лабораторные исследования надо уточнить. По-моему, я при запросе партий это дело проверяю, но я работаю через getStockEntryList, не через Changes. Так что меня коснуться не должно

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

(965) У нас на такие площадки в день сотни ВСД, выписать на них невозможно в принципе. Эти площадки не выбираются в меркурии, через API на них не сделать ни регионализацию, ни транспортную ВСД.
(969) Мы закачали справочник иностранных площадок, и во всех товарах проставили площадку производителя. Хотя ИМХО почему бы этот справочник просто не выложить? Почему РСХН его не выкладывает? Там по каждой стране всего лишь несколько сотен площадок. Все наши площадки там есть.

Есть ли в Меркурии функция получения описания ошибки по ее коду через API
  А то посылаешь запрос на гашение, а тебе в ответ
REJECTED   ERR  MERC13286
В ВИКИ есть http://help.vetrf.ru/wiki/IncomingOperation
описание. Но хочется как то более цивильно

(971) нет. У меня тот же вопрос, но походу нет, у тебя вместе с ошибкой возвращается её текстовое описание.

(971) так вроде в BusinessError возвращаются текстовые описания. Или у вас провайдер, а не API?

У меня в IncomingOperation - оформление входящей партии возвращает только КодОшибки.

Кто нибудь сталкивался с такой ошибкой. MERC14023    В сведениях о принимаемой партии указана устаревшая версии записи вида продукции наименовании продукции.
Что то я не вижу способа обойти эту ошибку по API

В справке написано "В запросе для номенклатуры продукции указан идентификатор устаревшей версии записи реестра РСХН" и как это перевести на русский язык?

(975) это значит продукция выведена из реестра РСХН?

Через WEB Я погасил эту ВСД. Где-то проскакивало, что в Меркурии утверждают, что такую ВСД можно погасить только через WEB интерфейс

Через API не смог, хотя продукция полностью обновлена.

(975)(976)(977) скорее всего это означает, что в запросе для продукции указали UUID продукции, а не GUID, и этот UUID является идентификатором непоследней версии продукции. Я не Ванга, но думаю, что произошло следующее: ваши контрики выписали ВСД, используя последний на тот момент UUID продукции. А потом, пока ВСД летел к вам, что-то подправили в справочнике для этой номенклатуры - название там поменяли или еще чего, может, просто ОК нажали. В результате для соответствующего GUID номенклатуры образовалась новая последняя версия с новым UUID, а тот UUID, который был в ВСД - стал неактуальным. Чтобы это полечить, наверно, нужно при приемке либо сменить UUID на последний, либо очистить его и заполнить GUID.

Кстати! Ща скажу важную вещь, на которую напоролся. Если для какой-то версионной сущности в запросе заполнен и GUID, и UUID, приоритет у UUID! Так что если не хотите ловить ошибки с устаревшей версией, не пользуйтесь UUID без крайней необходимости.

В конфигурацию Розница (2.2.9.19) добавили работу с Меркурием, кто уже тестил?

Конечно функционал только для подписчиков ИТС.

И в УТ11 не в курсе когда?

+ (979) чтобы было более понятно, как это работает, надо понимать, как работает механизм Versioning Entity в Ветис.АПИ. Грубо говоря, каждая номенклатура это связный список элементов, каждый из которых содержит GUID и UUID. GUID уникален для каждого элемента справочника номенклатуры, это типа как код в справочнике 1С. А UUID уникален для каждого элемента списка. Когда создается новый элемент номенклатуры, в списке создается первый элемент. Первая версия. Она активна и не содержит ссылок на предыдущие и следующие элементы. Потом решили ее подправить. Создается второй элемент списка, ссылающийся на первый. GUID у него тот же, а UUID уже другой. И теперь уже второй элемент активен, а первый нет. Второй ссылается на первый, первый на второй. Если запустили процедуру удаления - признак активности у последнего элемента снимается, т.е. все элементы в списке тупо неактивные, а физически ничего не удалилось. Старые документы могут ссылаться на неактивные версии номенклатуры, а новые нет - будет вот эта самая ваша ошибка с устаревшей версией. Как-то так это все работает...

У вас ВЕТИС у НАС ВС внедряют.
Виртуальный склад.
Скоро будут следить за всеми движениями товаров (((

(983) у нас каждый день несколько Guid ( а не uuid) становятся неактуальными.

(985) Т.е. вы уверены что используете GUID в запросе, но получаете ошибку неактуальной версии? Тогда, возможно, в цепочке вообще нет актуальных, т.е. номенклатура "удалена" хозсубъектом который ее завел.

И надо проверить (981) - если вдруг вышло так что указали и GUID и UUID, то используется UUID

(982) В УТ 11 уже давно.
Вот только у меркурия пока проблемы с APLM0012

(988) У нас уже нет APLM0012. Эта ошибка на 80% проблема разработчиков интеграционных решений и на 20% Меркурия.

(988) Понятно, скоро знакомые колбасники с УТ11 начнут доставать по интеграции.

(989) по-моему, все в точности наоборот. Проблемы с перегрузками связана с тем, что изначально разработчики меркурия сделали сверхтяжелые запросы вроде получения всех ветеринарок или всех партий практически без фильтрации или с минимальной. И когда все разработчики начали это себе выкачивать ввиду того, что у них просто не было других вариантов - все вполне ожидаемо прилегло отдохнуть. Лично мне это было очевидно еще в 2016 году, что так оно и будет.

то же самое, кстати, подтвердил Власов на встрече с представителями бизнеса. И сейчас (конкретно в сегодняшнем обновлении) они уже пытаются повыкинуть из ответов часть данных, чтобы хотя бы снизить нагрузку на сеть.

(989) Как вы решили вопрос с получением входящих документов без запросов списков?

(993) Корректно сделали таймауты.
Запрос на получение списка вет сертификатов. Цикл с таймоутом 120 сек и задержкой между запросами 10 сек. Прерываемся только если COMPLETED. На все остальные ошибки не смотрим.
  Получение ответа на запрос. Цикл с таймоутом 120 сек и задержкой между запросами 3 сек. Прерываемся только если COMPLETED ИЛИ REJECTED. На все остальные ошибки не смотрим.
  Где то так примерно. Не могу посмотреть точно.
  Проблем с получением списка сертитификатов имеем если на протяжении 120 сек не смогли отправить запрос на получение. Но это происходит когда Меркурий совсем висит.

(994) Ну хорошо, обошли. А вы сами как считаете, ожидания не в миллисекундах, а в десятках секунд для продуктивной системы уровня не много не мало федеральной - это вообще как? Я тут даже слово "нормально" не употребляю, потому что по-моему, это вообще за гранью добра и зла. И кто в этом виноват, интеграторы?

Не так страшен черт.
У нас гашение входящих ВСД 1 машины занимает 30 секунд. Не очень много. Если взять распределительный склад уровня Метро, то у них не более 1000 машин в сутки. Вполне могут работать.
Интеграционное решение должно быть нормальным.

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

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

(998) у нас после отмены молочки осталось 10000 ВСД транспортных в сутки, по бизнес-процессу они должны выписываться за полтора часа. То есть это нормально, что внедрение электронной сертификации взамен бумажной ухудшило процессы у дистрибьютеров? Я так не думаю. ИМХО это неудовлетворительно.

(999) есно исходящих

Получается 100 ВСД в секунду. Выписывай в фоне. Если Меркурий не режет количество одновременных запросов с одного IP, то должно получиться

(1001) Естественно они в фоне и выписываются, ассинхронно.