Ошибка регионализации меркурий - Не ошибается лишь тот, кто ничего не делает!

Автор	Сообщение
01/07/2019 12:07:01 Тема: CheckShipmentRegionalizationOperation и ошибка MERC02469
machik Зарегистрирован: 01/07/2019 11:55:06 Сообщений: 2 Оффлайн	Добрый день. Формируем ВСД через API. Параметры регионализации получаем с помощью операции CheckShipmentRegionalizationOperation . Операция выдает, что перемещение возможно без дополнительных условий, но ВСД не оформляется из за ошибки: Код ошибки: MERC02469. Описание: Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение). Когда формируем эту же ВСД на сайте, то выскакивает куча условий на перемещение. Как так может быть? Операция CheckShipmentRegionalizationOperation работает не корректно? Куда копать? Тех. поддержка на мое письмо не ответила


01/07/2019 12:08:29 Тема: Re:CheckShipmentRegionalizationOperation и ошибка MERC02469
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4977 Оффлайн	добрый а позвонить 8 (4922) 52-99-29


01/07/2019 12:10:23 Тема: CheckShipmentRegionalizationOperation и ошибка MERC02469
Yoreg07 Зарегистрирован: 21/07/2016 06:41:02 Сообщений: 572 Оффлайн	machik wrote:Добрый день. Формируем ВСД через API. Параметры регионализации получаем с помощью операции CheckShipmentRegionalizationOperation . Операция выдает, что перемещение возможно без дополнительных условий, но ВСД не оформляется из за ошибки: Код ошибки: MERC02469. Описание: Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение). Когда формируем эту же ВСД на сайте, то выскакивает куча условий на перемещение. Как так может быть? Операция CheckShipmentRegionalizationOperation работает не корректно? Куда копать? Тех. поддержка на мое письмо не ответила Добрый день, пробовали ещё раз запросить список условий? Просто я сталкивался с таким: пока выполняется запрос списка условий и подставление их в расходный ВСД, сам список условий в Меркурии изменился и на момент оформления транспортной партии он стал неактуальным/неполным … просто не повезло. Попробуйте снова проделать те же самые операции. Это сообщение было редактировано 1 раз. Последнее обновление произошло в 01/07/2019 12:11:02


01/07/2019 12:27:19 Тема: Re:CheckShipmentRegionalizationOperation и ошибка MERC02469
machik Зарегистрирован: 01/07/2019 11:55:06 Сообщений: 2 Оффлайн	Повторно запрашивать условия пробовали конечно, ни чего не получается Заметил закономерность: Предприятия- получатели, с которыми проблемы, имеют статус предприятия в ИС «Цербер»: не синхронизирован …


01/07/2019 12:57:48 Тема: Re:CheckShipmentRegionalizationOperation и ошибка MERC02469
Yoreg07 Зарегистрирован: 21/07/2016 06:41:02 Сообщений: 572 Оффлайн	machik wrote:Повторно запрашивать условия пробовали конечно, ни чего не получается Заметил закономерность: Предприятия- получатели, с которыми проблемы, имеют статус предприятия в ИС «Цербер»: не синхронизирован … ну тогда в тех.поддержку, наверное


01/07/2019 14:25:13 Тема: Re:CheckShipmentRegionalizationOperation и ошибка MERC02469
thinker Зарегистрирован: 13/10/2017 07:37:41 Сообщений: 25 Оффлайн	Я, может быть, не по теме, но… Регионализация задолбала. Откровенно. От слова «задолбала». Мы звонили в ветуправление (или как там правильно, называется) и там нам высказали следующий тезис: Меркурию плевать на то, что площадка находится в благополучном районе — главное, в каком районе зарегистрирован ХС. И, если там проблемы, то ВСД выписать не получится. «Регионализация, сэр!» («И это понятно любому…», ну, в общем, вы знаете) Это сообщение было редактировано 1 раз. Последнее обновление произошло в 01/07/2019 14:25:42


02/07/2019 11:26:50 Тема: CheckShipmentRegionalizationOperation и ошибка MERC02469
v.isaev Зарегистрирован: 04/04/2017 13:29:33 Сообщений: 81 Оффлайн	machik wrote:Добрый день. Формируем ВСД через API. Параметры регионализации получаем с помощью операции CheckShipmentRegionalizationOperation . Операция выдает, что перемещение возможно без дополнительных условий, но ВСД не оформляется из за ошибки: Код ошибки: MERC02469. Описание: Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение). Когда формируем эту же ВСД на сайте, то выскакивает куча условий на перемещение. Как так может быть? Операция CheckShipmentRegionalizationOperation работает не корректно? Куда копать? Тех. поддержка на мое письмо не ответила А для какого SubProduct выполняется проверка условий регионализации? Который висит на товаре, или который внутри записи складского журнала?


02/07/2019 11:50:12 Тема: CheckShipmentRegionalizationOperation и ошибка MERC02469
Вячеслав Феньченко Зарегистрирован: 29/05/2018 16:15:09 Сообщений: 29 Оффлайн	v.isaev wrote:А для какого SubProduct выполняется проверка условий регионализации? Который висит на товаре, или который внутри записи складского журнала? Добрый день. На товаре.


02/07/2019 11:52:48 Тема: CheckShipmentRegionalizationOperation и ошибка MERC02469
v.isaev Зарегистрирован: 04/04/2017 13:29:33 Сообщений: 81 Оффлайн	Вячеслав Феньченко wrote: v.isaev wrote:А для какого SubProduct выполняется проверка условий регионализации? Который висит на товаре, или который внутри записи складского журнала? Добрый день. На товаре. текущий сабпродукт на товаре может отличаться от того, какой фигурирует в записи складского журнала. Запросите условия регионализации по сабпродакту из ЗСЖ.


02/07/2019 12:06:02 Тема: CheckShipmentRegionalizationOperation и ошибка MERC02469
Вячеслав Феньченко Зарегистрирован: 29/05/2018 16:15:09 Сообщений: 29 Оффлайн	v.isaev wrote:текущий сабпродукт на товаре может отличаться от того, какой фигурирует в записи складского журнала. Запросите условия регионализации по сабпродакту из ЗСЖ. Попробую передавать сабпродакт из ЗСЖ. Хотя делали ВСД для одной и той же ЗСЖ, для разных предприятий-получателей, для одних все нормально проходило, а для других нет…


10/12/2019 18:06:51 Тема: Re:CheckShipmentRegionalizationOperation и ошибка MERC02469
efspb-180706 Зарегистрирован: 08/11/2019 16:01:39 Сообщений: 3 Оффлайн	Ну как, решили проблему?)

Источник

Ошибка 02469. Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия

При Возникновении такой ошибки :

Нужно:

1. Проверить подкатегорию товаров в накладной.

2. Проверить включена ли настройка Авторегионализации :

3. Также нужно попробовать нажать регионализация в самом сертификате.

Источник

Ошибка при проверке возможности осуществления перевозки в рамках регионализации
XML

Индекс форума
» Компонент МЕРКУРИЙ

Автор	Сообщение
26/05/2018 11:54:39 Тема: Ошибка при проверке возможности осуществления перевозки в рамках регионализации
apavlov Зарегистрирован: 16/11/2017 14:12:22 Сообщений: 4 Оффлайн	Добрый день. Пытаюсь сформировать транспортную ВСД через ветис API 2.0 При отправке запроса выдает ошибку MERC02469 — Указаны не все обязательные условия перевозки в соответствии с регионализацией. Далее пытаюсь сформировать запрос на проверку возможности осуществления перевозки в рамках регионализации (CheckShipmentRegionalizationOperation), однако запрос возвращает ошибку. вот сам запрос: <Envelope xmlns=»http://schemas.xmlsoap.org/soap/envelope/» xmlnss=»http://www.w3.org/2001/XMLSchema» xmlnssi=»http://www.w3.org/2001/XMLSchema-instance»> <Body> <submitApplicationRequest xmlns=»http://api.vetrf.ru/schema/cdm/application/ws-definitions»> <apiKey>???????</apiKey> <application xmlns=»http://api.vetrf.ru/schema/cdm/application»> <serviceId>mercury-g2b.service:2.0</serviceId> <issuerId>fe128bbe-218a-11e2-a69b-b499babae7ea</issuerId> <issueDate>2018-05-26T10:53:23</issueDate> <data> <сheckShipmentRegionalizationRequest xmlns=»http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2″> <localTransactionId>3bddd831-35c2-46fb-9e5e-35718cc31c9f</localTransactionId> <initiator xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:login>???????</d7p1:login> </initiator> <cargoType xmlns=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>80b7fc16-110c-a663-67e3-b5d9ce3f02ff</guid> </cargoType> <shipmentRoute xmlns=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <routePoint> <sqnId>1</sqnId> <location xmlns:d9p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d9p1:name>4, Новгородская обл., Боровичский район, г. Боровичи, Коммунарная ул., дом № 42</d9p1:name> <d9p1:address> <d9p1:country> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</guid> </d9p1:country> <d9p1:region> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>e5a84b81-8ea1-49e3-b3c4-0528651be129</guid> </d9p1:region> <d9p1:district> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>dbb5ed6e-9f4c-49d1-ab5b-345222f57856</guid> </d9p1:district> <d9p1:locality> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>ae2f372e-7df2-400c-95f9-4b0522567634</guid> </d9p1:locality> <d9p1:street> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>baea539a-42a2-4048-bf24-0b52aa984900</guid> </d9p1:street> <d9p1:addressView>4, Новгородская обл., Боровичский район, г. Боровичи, Коммунарная ул., дом № 42</d9p1:addressView> </d9p1:address> </location> <transshipment>false</transshipment> </routePoint> <routePoint> <sqnId>2</sqnId> <location xmlns:d9p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <d9p1:name>141014, Московская область, Мытищинский район, г. Мытищи, Осташковское шоссе, д. 1</d9p1:name> <d9p1:address> <d9p1:country> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>74a3cbb1-56fa-94f3-ab3f-e8db4940d96b</guid> </d9p1:country> <d9p1:region> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>29251dcf-00a1-4e34-98d4-5c47484a36d4</guid> </d9p1:region> <d9p1:district> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>a87ff831-986b-44a7-8405-00fc699de4ce</guid> </d9p1:district> <d9p1:locality> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>5f290be7-14ff-4ccd-8bc8-2871a9ca9d5f</guid> </d9p1:locality> <d9p1:street/> <d9p1:addressView>141014, Московская область, Мытищинский район, г. Мытищи, Осташковское шоссе, д. 1</d9p1:addressView> </d9p1:address> </location> <transshipment>false</transshipment> </routePoint> </shipmentRoute> </сheckShipmentRegionalizationRequest> </data> </application> </submitApplicationRequest> </Body> </Envelope> Ответ: <?xml version=»1.0″ encoding=»UTF-8″?> <soapenv:Envelope xmlns:soapenv=»http://schemas.xmlsoap.org/soap/envelope/»><env:Header xmlns:env=»http://schemas.xmlsoap.org/soap/envelope/»/><env:Body xmlns:env=»http://schemas.xmlsoap.org/soap/envelope/»><env:Fault><faultcode xmlns:soap-env=»http://schemas.xmlsoap.org/soap/envelope/»>soap-env:Server</faultcode><faultstring>Exception occured when binding was invoked. Exception occured during invocation of JCA binding: «JCA Binding execute of Reference operation ‘InsertApplicationMetadata’ failed due to: Pure SQL Exception. Pure SQL Execute of INSERT INTO `APPLICATION_METADATA` (`APPLICATION_ID`,`RECEIVE_REQUEST_DATE`,`STATUS`,`ISSUER_ID`,`SERVICE_ID`,`SERVICE_VERSION`,`OPERATION`,`ISSUE_DATE`,`API_KEY`) VALUES (?,?,?,?,?,?,?,?,?); failed. Caused by java.sql.SQLException: Incorrect string value: ‘xD1x81heck…’ for column ‘OPERATION’ at row 1. The Pure SQL option is for border use cases only and provides simple yet minimal functionality. Possibly try the «Perform an operation on a table» option instead. This exception is considered not retriable, likely due to a modelling mistake. To classify it as retriable instead add property nonRetriableErrorCodes with value «-1366» to your deployment descriptor (i.e. weblogic-ra.xml). To auto retry a retriable fault set these composite.xml properties for this invoke: jca.retry.interval, jca.retry.count, and jca.retry.backoff. All properties are integers. «. The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution. </faultstring><faultactor/><detail><ws:internalServiceFault xmlns:ws=»http://api.vetrf.ru/schema/cdm/base/ws-definitions»><base:message xmlns:base=»http://api.vetrf.ru/schema/cdm/base»>Internal Service Error!!</base:message></ws:internalServiceFault></detail></env:Fault></env:Body></soapenv:Envelope> В чем может быть ошибка? PS: пробовал отправлять запрос и в тестовой и в продуктивной версия — результат одинаковый. Также в точках маршрута пробовал вместо секций location указывать секцию enterprise — результат тот же


27/05/2018 12:12:59 Тема: Re:Ошибка при проверке возможности осуществления перевозки в рамках регионализации
oleg-x Зарегистрирован: 20/11/2017 11:24:40 Сообщений: 2005 Онлайн	У себя реализовал по другому. Тег <vd:location> не заполняю. Заполняю тег <vd:enterprise>, таким образом мне не надо где то хранить гуиды стран, городов, районов и поселков.
https://vk.com/mercuriy_rf


27/05/2018 12:45:39 Тема: Re:Ошибка при проверке возможности осуществления перевозки в рамках регионализации
apavlov Зарегистрирован: 16/11/2017 14:12:22 Сообщений: 4 Оффлайн	Я писал выше, что пробовал разными способами. Запрос: <Envelope xmlns=»http://schemas.xmlsoap.org/soap/envelope/» xmlnss=»http://www.w3.org/2001/XMLSchema» xmlnssi=»http://www.w3.org/2001/XMLSchema-instance»> <Body> <submitApplicationRequest xmlns=»http://api.vetrf.ru/schema/cdm/application/ws-definitions»> <apiKey>??????</apiKey> <application xmlns=»http://api.vetrf.ru/schema/cdm/application»> <serviceId>mercury-g2b.service:2.0</serviceId> <issuerId>fe128bbe-218a-11e2-a69b-b499babae7ea</issuerId> <issueDate>2018-05-27T12:43:38</issueDate> <data> <сheckShipmentRegionalizationRequest xmlns=»http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2″> <localTransactionId>44163408-b657-4ad7-bc88-3b997cc59da0</localTransactionId> <initiator xmlns:d7p1=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <d7p1:login>?????????</d7p1:login> </initiator> <cargoType xmlns=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>80b7fc16-110c-a663-67e3-b5d9ce3f02ff</guid> </cargoType> <shipmentRoute xmlns=»http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2″> <routePoint> <sqnId>1</sqnId> <enterprise xmlns:d9p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>eaf63f85-4b82-4b08-a9cb-c5d6917eeb6b</guid> </enterprise> <transshipment>false</transshipment> </routePoint> <routePoint> <sqnId>2</sqnId> <enterprise xmlns:d9p1=»http://api.vetrf.ru/schema/cdm/dictionary/v2″> <guid xmlns=»http://api.vetrf.ru/schema/cdm/base»>2eddcbbb-8e68-485a-8d86-4c2fd91c0e9c</guid> </enterprise> <transshipment>false</transshipment> </routePoint> </shipmentRoute> </сheckShipmentRegionalizationRequest> </data> </application> </submitApplicationRequest> </Body> </Envelope> Ответ: <?xml version=»1.0″ encoding=»UTF-8″?> <soapenv:Envelope xmlns:soapenv=»http://schemas.xmlsoap.org/soap/envelope/»><env:Header xmlns:env=»http://schemas.xmlsoap.org/soap/envelope/»/><env:Body xmlns:env=»http://schemas.xmlsoap.org/soap/envelope/»><env:Fault><faultcode xmlns:soap-env=»http://schemas.xmlsoap.org/soap/envelope/»>soap-env:Server</faultcode><faultstring>Exception occured when binding was invoked. Exception occured during invocation of JCA binding: «JCA Binding execute of Reference operation ‘InsertApplicationMetadata’ failed due to: Pure SQL Exception. Pure SQL Execute of INSERT INTO `APPLICATION_METADATA` (`APPLICATION_ID`,`RECEIVE_REQUEST_DATE`,`STATUS`,`ISSUER_ID`,`SERVICE_ID`,`SERVICE_VERSION`,`OPERATION`,`ISSUE_DATE`,`API_KEY`) VALUES (?,?,?,?,?,?,?,?,?); failed. Caused by java.sql.SQLException: Incorrect string value: ‘xD1x81heck…’ for column ‘OPERATION’ at row 1. The Pure SQL option is for border use cases only and provides simple yet minimal functionality. Possibly try the «Perform an operation on a table» option instead. This exception is considered not retriable, likely due to a modelling mistake. To classify it as retriable instead add property nonRetriableErrorCodes with value «-1366» to your deployment descriptor (i.e. weblogic-ra.xml). To auto retry a retriable fault set these composite.xml properties for this invoke: jca.retry.interval, jca.retry.count, and jca.retry.backoff. All properties are integers. «. The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution. </faultstring><faultactor/><detail><ws:internalServiceFault xmlns:ws=»http://api.vetrf.ru/schema/cdm/base/ws-definitions»><base:message xmlns:base=»http://api.vetrf.ru/schema/cdm/base»>Internal Service Error!!</base:message></ws:internalServiceFault></detail></env:Fault></env:Body></soapenv:Envelope>


27/05/2018 16:43:19 Тема: Re:Ошибка при проверке возможности осуществления перевозки в рамках регионализации
oleg-x Зарегистрирован: 20/11/2017 11:24:40 Сообщений: 2005 Онлайн	Вот мой рабочий запрос, убрать только перенос на другую строку и все будет работать.
https://vk.com/mercuriy_rf


28/05/2018 10:54:14 Тема: Re:Ошибка при проверке возможности осуществления перевозки в рамках регионализации
apavlov Зарегистрирован: 16/11/2017 14:12:22 Сообщений: 4 Оффлайн	Да вроде все тоже самое, что и у меня?


29/05/2018 11:10:25 Тема: Re:Ошибка при проверке возможности осуществления перевозки в рамках регионализации
apavlov Зарегистрирован: 16/11/2017 14:12:22 Сообщений: 4 Оффлайн	Вопрос закрыт. Проблема была в неправильном написании имени операции (кирилица в наименовании сheckShipmentRegionalizationRequest). Спасибо техподдержке. Это сообщение было редактировано 1 раз. Последнее обновление произошло в 29/05/2018 11:12:17

Индекс форума
» Компонент МЕРКУРИЙ

Перейти:

Источник

ВЕТИС. Вторая неделя работы

ProxyInspector

17.07.18 — 12:15

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

ProxyInspector

1 — 17.07.18 — 12:17

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

EuVod

2 — 17.07.18 — 16:23

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

Мы формально имеем право такой товар принимать?

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

Kigo_Kigo

3 — 17.07.18 — 16:55

Кто нибудь покупал вот эту доработку?

http://catalog.mista.ru/public/857304/

Если да, то вопрос есть

Здравствуйте, что требуется для доработки типовой ТиС чтобы ваша конфигурация заработала на типовой ТиС?

Можно ли работать от нескольких организаций заведенных в ТиС?

а то там автор молчит как рыба

RKx

4 — 17.07.18 — 16:58

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

https://redmine.kb99.pro/projects

Kigo_Kigo

5 — 17.07.18 — 17:13

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

Chieftain

6 — 17.07.18 — 23:35

(0) Три разные группы компаний.

В первой — ошибка «MERC30127 Указанные предприятие и хозяйствующий субъект должны быть связаны друг с другом».

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

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

big

7 — 18.07.18 — 04:55

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

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

ProxyInspector

8 — 18.07.18 — 07:42

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

  С остатками тоже примерно такая же проблема. Делал инвентаризацию, обнулил остатки. В меркурии инвентаризация прошла. Но остатки еще несколько минут не менялись.

  Надо настраиваться на время отклика Меркурия несколько минут, и не напрягаться.

  А совсем правильно делать все запросы к Меркурию в фоне с большими таймаутами

spectre1978

9 — 18.07.18 — 09:20

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

big

10 — 18.07.18 — 09:44

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

spectre1978

11 — 18.07.18 — 10:43

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

big

12 — 18.07.18 — 10:54

(11) Я правильно понял, что тикет = applicationId?

Собссно, примерно так и сделано, но пока что в полуручном режиме.

spectre1978

13 — 18.07.18 — 11:18

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

spectre1978

14 — 18.07.18 — 11:20

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

EuVod

15 — 18.07.18 — 11:39

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

EuVod

16 — 20.07.18 — 10:05

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

ks_83

17 — 20.07.18 — 11:12

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

EuVod

18 — 20.07.18 — 12:45

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

spectre1978

19 — 25.07.18 — 19:19

http://www.vetrf.ru/vetrf/news/27465.html

в воскресенье обещают перекуры до 15 минут

Рэйв

20 — 25.07.18 — 20:28

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

spectre1978

21 — 25.07.18 — 21:57

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

kofeinik

22 — 25.07.18 — 23:24

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

Boleev

23 — 26.07.18 — 11:45

Всем привет. Подскажите с получением доступа для хозсубъекта к системе — есть группа компаний и одни и те же пользователи. Сколько заявлений

о регистрации в ФГИС ВетИС и предоставлении доступа к ФГИС «Меркурий» сотрудникам надо подавать?

spectre1978

24 — 26.07.18 — 14:38

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

spectre1978

25 — 26.07.18 — 14:38

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

YurAnt

26 — 26.07.18 — 14:41

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

NSSerg

27 — 03.08.18 — 15:54

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>

spectre1978

28 — 03.08.18 — 17:02

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

ProxyInspector

29 — 08.08.18 — 11:31

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

ВЕТИС еще жив?

spectre1978

30 — 08.08.18 — 11:45

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

lucbak

31 — 08.08.18 — 11:58

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

spectre1978

32 — 08.08.18 — 12:06

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

NSSerg

33 — 08.08.18 — 14:50

А кто-нибудь заметил что двух видов продукции (третий уровень, ТНВЭД) сменился Гуид — со всеми вытекающими.

У номенклатуры в меркурии недействительный вид продукции, ну и операции с товаром не работают.

14657ed1-9fb7-4d0f-ab30-bbc1779bc9e8

67f10d49-9cfa-64d1-d308-069304a1a873

Путассу холодного копчения и икра горбуши соленая — теперь имеют другие гуиды.

NSSerg

34 — 08.08.18 — 14:56

Вот как выглядят последствия (у меня вид продукции подставляется из результатов запроса по GUID номенклатуры)

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

ProxyInspector

35 — 10.08.18 — 12:41

Стали дальше внедрять эту ВЕТИС.

Вылазит ошибка MERC14562.

В интернете нашел, что это «название продукции в сведениях о принимаемой партии не совпадает с указанной в ветеринарно-сопроводительном документе».

Сразу возник вопрос: «Существует ли описание ошибок Меркурия». Или можно ли получить через API описание ошибки по ее коду.

Пока описания ошибок не нашел.

NSSerg

36 — 10.08.18 — 14:27

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

NSSerg

37 — 10.08.18 — 14:30

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

http://help.vetrf.ru/wiki/GetVetDocumentByUuidOperation_v2.0

Внизу «Коды ошибок»

NSSerg

38 — 10.08.18 — 14:31

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

NSSerg

39 — 12.08.18 — 19:10

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

Cyberhawk

40 — 12.08.18 — 19:45

(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

ProxyInspector

41 — 12.08.18 — 19:47

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

spectre1978

42 — 12.08.18 — 20:00

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

spectre1978

43 — 17.08.18 — 08:32

ProxyInspector

44 — 17.10.18 — 12:47

Столкнулся с ошибкой Меркурия при работе через API

Ошибка MERC02469 Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение)

   Сначала при оформлении возврата поставщику, а потом и при отгрузке чужой продукции в магазин.

   Пару дней убил на изучение Китайской логики работы с регионализацией у разработчиков Меркурия.

   Я просто в шоке.

ProxyInspector

45 — 17.10.18 — 12:53

Короче логика очень интересная.

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

ProxyInspector

46 — 17.10.18 — 13:03

Дальше имеем перемещение товара от производителя по маршруту А — Б — В

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

Перемещение Б — В. Такая же фигня. Надо указывать условия, которые придумал поставщик при поставке продукции.

   Описания этого механизма нигде нет. Он реализован в WEB интерфейсе, а для API даже не описан. Вернее описан совсем другой алгоритм.

   Как народ работает?

Sasha_1CK

47 — 17.10.18 — 13:31

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

EuVod

48 — 22.10.18 — 20:38

коллеги,

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

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

Это нормально??

я думал при отправке заявок в обработку (раз уж заявка принята и AppID присвоено) такого быть не должно??

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

big

49 — 23.10.18 — 05:02

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

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

spectre1978

50 — 23.10.18 — 06:35

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

EuVod

51 — 23.10.18 — 10:48

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

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

big

52 — 23.10.18 — 11:03

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

EuVod

53 — 23.10.18 — 11:05

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

«фиг его знает, может провелась, может нет, мы сейчас перегружены, дать ответ не можем».

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

ProxyInspector

54 — 23.10.18 — 11:07

(51) Это нормально для Меркурия. такое поведение они называют выравнивание нагрузки. Алгоритм работы примерно такой. Посылаете запрос по API получаете applic,issuerId.

  По этим данным спрашиваете результат запроса.

  Если receiveApplicationResultResponse.application.status=»COMPLETED» тогда все нормально.

  Если «REJECTED» и «APLM0012»   ИЛИ «IN_PROCESS» тогда задержку!!! 3 сек и снова запрос

  Если просто «REJECTED» тогда все пропало.

EuVod

55 — 23.10.18 — 15:22

таки были проблемы в самой заявке )

разобрались, успех, нужные данные получили

Источник

Управлением Россельхознадзора по Челябинской и Курганской областям во время мониторинга оформления эВСД во ФГИС «Меркурий» установлены нарушения. Так, 14 февраля в ходе мониторинга оформления ветеринарных сопроводительных документов в ФГИС «Меркурий» выявлены нарушения, совершенные бухгалтером общества с ограниченной ответственностью (город Курган) М. , которая 7 февраля при оформлении ветеринарного сопроводительного документа на партию охлажденной свинины в полутушах (499 кг) не указала в ветеринарном свидетельстве сведения о потребительской или транспортной упаковке, исключающей контакт с внешней средой.

Кроме того, бухгалтер согласно правилам регионализации по ящуру свиней указала условие, что свинина выработана в официально признанной МЭБ благополучной без вакцинации зоне по ящуру на территории РФ.

Что является неверным, так как производителем является предприятие, расположенное в Челябинской области, а Челябинская область, согласно регионализации РФ по ящуру, является неблагополучным регионом с вакцинацией. Своими действиями ответственное лицо нарушило Приказы Министерства сельского хозяйства РФ от 27.12.2016 № 589 «Об утверждении Ветеринарных правил организации работы по оформлению ветеринарных сопроводительных документов, порядка оформления ветеринарных сопроводительных документов в электронной форме и порядка оформления ветеринарных сопроводительных документов на бумажных носителях» и от 18.12.2015 № 646 «Об утверждении Перечня продукции животного происхождения, на которую уполномоченные лица организаций, являющихся производителями подконтрольных товаров и (или) участниками оборота подконтрольных товаров, и индивидуальные предприниматели, являющиеся производителями подконтрольных товаров и (или) участниками оборота подконтрольных товаров, могут оформлять ветеринарные сопроводительные документы».

25 февраля на бухгалтера был составлен протокол об административном правонарушении. В марте она будет привлечена к административной ответственности.

Источник