Код ошибки merc56558

Автор	Сообщение
29/01/2020 08:58:37      Тема: MERC37558
undefined Зарегистрирован: 04/12/2019 02:23:39 Сообщений: 11 Оффлайн	Здравствуйте. При попытке получить данные по всем записям складского журнала, получаю ошибку MERC37558 (Данные не могут быть получены, так как у пользователя, ответственного за выполнение, отсутствует доступ). В вики информации по данной ошибки не нашёл и не могу понять каких прав не хватает. В чём может быть проблема?
29/01/2020 09:01:02      Тема: Re:MERC37558
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4977 Оффлайн	здравствуйте посмотрите права юзера в ветисе и перечислите здесь если нетрудно
29/01/2020 09:19:04      Тема: Re:MERC37558
undefined Зарегистрирован: 04/12/2019 02:23:39 Сообщений: 11 Оффлайн	nmzn1 wrote:здравствуйте посмотрите права юзера в ветисе и перечислите здесь если нетрудно Не понимаю зачем, но пожалуйста: — Доступ к веб-интерфейсу ИС Меркурий только на чтение — Доступ к веб-интерфейсу ИС Меркурий на выполнение операций — Авторизованный заявитель в системе Аргус — Доступ к ИС Меркурий через Ветис.API только на чтение — Управление зонами ответственности пользователей — Доступ к ИС Меркурий через Ветис.API на выполнение операций — Гашение ВСД — Уполномоченное гашение ВСД — Уполномоченное оформление возвратных ВСД — Оформление ВСД на производственную партию — Уполномоченное лицо (Оформление ВСД на продукцию из Приказа МСХ РФ №646) — Оформление ВСД на сырое молоко (при наличии справки о безопасности сырого молока) — Авторизованный заявитель в системе Меркурий — Оформление возвратных ВСД
29/01/2020 09:23:52      Тема: Re:MERC37558
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4977 Оффлайн	с правами всё нормально вроде как возможно из-за глюков в работе, пробуйте позже, тема тут https://vetrf.ru/vetrf-forum/posts/list/1395/8243.page тех.поддержка 8 (4922) 52-99-29
29/01/2020 09:27:23      Тема: Re:MERC37558
undefined Зарегистрирован: 04/12/2019 02:23:39 Сообщений: 11 Оффлайн	nmzn1 wrote:возможно из-за глюков в работе У других организаций проблем нет — только у одной.
29/01/2020 09:29:30      Тема: Re:MERC37558
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4977 Оффлайн	могу только посоветовать под другим пользователем попробовать
29/01/2020 09:39:48      Тема: Re:MERC37558
undefined Зарегистрирован: 04/12/2019 02:23:39 Сообщений: 11 Оффлайн	nmzn1 wrote:могу только посоветовать под другим пользователем попробовать Это было первым, что я попробовал.
29/01/2020 09:48:07      Тема: Re:MERC37558
nmzn1 Зарегистрирован: 11/05/2017 09:25:20 Сообщений: 4977 Оффлайн	может предприятие блокирнули
29/01/2020 09:52:06      Тема: Re:MERC37558
undefined Зарегистрирован: 04/12/2019 02:23:39 Сообщений: 11 Оффлайн	Я только сегодня получил данные API. С ним ещё не успели поработать. Я застрял на первом получении остатков. При этом в фоне спокойно получаю данные по ВСД этого предприятия.
29/01/2020 10:20:43      Тема: Re:MERC37558
undefined Зарегистрирован: 04/12/2019 02:23:39 Сообщений: 11 Оффлайн	Вопрос решён. Звёзды совпали таким образом, что при отправке запроса в качестве инициатора подставлялся единственный заблокированный пользователь этого предприятия. Сейчас посмотрю алгоритм выбора пользователя, исправлю. Доложен был подставиться администратор предприятия и я был уверен что так и происходит.
29/01/2020 10:37:39      Тема: Re:MERC37558
oleg-x Зарегистрирован: 20/11/2017 11:24:40 Сообщений: 2020 Онлайн	undefined wrote:Вопрос решён. Звёзды совпали таким образом, что при отправке запроса в качестве инициатора подставлялся единственный заблокированный пользователь этого предприятия. Сейчас посмотрю алгоритм выбора пользователя, исправлю. Доложен был подставиться администратор предприятия и я был уверен что так и происходит. Плохая идея. Нужно подставлять того пользователя, который работает. А администратор вообще не должен участвовать, что бы не получить бан админу.
https://vk.com/mercuriy_rf
29/01/2020 10:43:52      Тема: Re:MERC37558
undefined Зарегистрирован: 04/12/2019 02:23:39 Сообщений: 11 Оффлайн	oleg-x wrote:Плохая идея. В запросе остатков нельзя допустить ошибку, да и формируется он программно. Пользователи не принимают в этом участия.
30/01/2020 11:19:28      Тема: Re:MERC37558
dk Зарегистрирован: 03/11/2017 00:49:55 Сообщений: 566 Оффлайн	oleg-x wrote: undefined wrote:Вопрос решён. Звёзды совпали таким образом, что при отправке запроса в качестве инициатора подставлялся единственный заблокированный пользователь этого предприятия. Сейчас посмотрю алгоритм выбора пользователя, исправлю. Доложен был подставиться администратор предприятия и я был уверен что так и происходит. Плохая идея. Нужно подставлять того пользователя, который работает. А администратор вообще не должен участвовать, что бы не получить бан админу. Это как раз хорошая практика. Работать могут много пользователей одновременно, а остатки и новые ВСД одни на всех.
https://Меркурий.рус — Автогашение ВСД(от 250 руб. в месяц). Автоудаление просрочки. Выписка ВСД и инвентаризация по сохранённым шаблонам. Тестовый контур — БЕСПЛАТНО. https://play.google.com/store/apps/details?id=com.skysent.mercury.rus — Android приложение для группового гашения ВСД по QR-кодам.
30/01/2020 14:32:37      Тема: Re:MERC37558
oleg-x Зарегистрирован: 20/11/2017 11:24:40 Сообщений: 2020 Онлайн	dk wrote:Это как раз хорошая практика. Работать могут много пользователей одновременно, а остатки и новые ВСД одни на всех. Имеется ввиду не получения остатков каждым пользователем, а выполнение запросов под администратором.
https://vk.com/mercuriy_rf
30/01/2020 14:36:09      Тема: Re:MERC37558
dk Зарегистрирован: 03/11/2017 00:49:55 Сообщений: 566 Оффлайн	oleg-x wrote: dk wrote:Это как раз хорошая практика. Работать могут много пользователей одновременно, а остатки и новые ВСД одни на всех. Имеется ввиду не получения остатков каждым пользователем, а выполнение запросов под администратором. Остатки и новые ВСД от администратора, а действия от пользователя. Не обязательно у пользователя будут права на запрос новых ВСД, а у администратора должны быть.
https://Меркурий.рус — Автогашение ВСД(от 250 руб. в месяц). Автоудаление просрочки. Выписка ВСД и инвентаризация по сохранённым шаблонам. Тестовый контур — БЕСПЛАТНО. https://play.google.com/store/apps/details?id=com.skysent.mercury.rus — Android приложение для группового гашения ВСД по QR-кодам.

Форумы » Вопросы и ответы по интеграции »

MERC02558 — права на отправку ВСД у вет.врача

Ответы (4)

(1-4/4)

При регистрации исходящего сертификата возникает ошибка:

MERC24009 В запросе для записи складского журнала продукции указан идентификатор устаревшей версии записи реестра РСХН.

Это значит, что подтянулась складская запись которой уже нет в меркурии.

1. Удалить сертификаты

2. Очистить кеш остатков динамики

3. Если режим статический сделать загрузку остатков

Столкнулись с проблемой: при отправке документа «Транспортный документ» в Меркурий периодически появляется ошибка «MERC02137», это значит, что мы пытаемся отправить продукцию больше, чем у нас есть на остатках, но какой именно продукции не хватает, не указано, а если позиций больше 100, придется проверять остаток каждой продукции в документе.

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

Открываем обработку, выбираем предприятие меркурий, транспортный документ меркурий, нажимаем кнопку «Сформировать». В табличную часть загрузятся позиции из документа с не обеспеченным расходом.

В первом столбце указанно «номер строки в документе»

Во втором столбце номенклатура меркурия (а точнее аналитика, это можно сказать партия)

В третьем столбце количество в документу и количество на остатках

!!! Для корректной работы обработки и в целом с транспортными документами меркурий у вас в базе должны быть актуальные остатки меркурий, иначе получится так, что в базе у вас указано одно количество, а на самом деле в меркурии числится другое количество. Для этого делайте запросы для получения остатков меркурия, в обработке указан последний документ с остатками из меркурия.

При нажатие на позицию в таблице, покажет все остатки по выбранной позиции.

Возможно сделать корректировку документа

Нажимаем на кнопку «Выбрать партию с обеспеченным расходом» — проверит все позиции с не обеспеченным расходом есть ли у них нужный остаток и если есть заменит в документе.

Нажимаем на кнопку «Изменить остаток» — изменит в документе количество на нужное для отправки.

Обработка тестировалась и работает

на конфигурациях «ДАЛИОН: Управление магазином.» и «Трактиръ: Head-Office».  

на платформе 1С 8.3 (тестировался и работает на разных платформах начиная с 8.3.8.1933 )

Гарантированно работает:

«ДАЛИОН: Управление магазином.ПРО»,на версии от ред. 1.2 (1.2.50.06) и выше

«Трактиръ: Head-Office», на версии от 1.0 (1.0.44.06)  и выше.

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

ProxyInspector

17.07.18

✎

12:15

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

1

ProxyInspector

17.07.18

✎

12:17

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

2

EuVod

17.07.18

✎

16:23

3

Kigo_Kigo

17.07.18

✎

16:55

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

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

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

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

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

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

4

RKx

17.07.18

✎

16:58

5

Kigo_Kigo

17.07.18

✎

17:13

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

6

Chieftain

17.07.18

✎

23:35

7

big

18.07.18

✎

04:55

8

ProxyInspector

18.07.18

✎

07:42

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

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

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

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

9

spectre1978

18.07.18

✎

09:20

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

10

big

18.07.18

✎

09:44

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

11

spectre1978

18.07.18

✎

10:43

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

12

big

18.07.18

✎

10:54

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

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

13

spectre1978

18.07.18

✎

11:18

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

14

spectre1978

18.07.18

✎

11:20

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

15

EuVod

18.07.18

✎

11:39

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

16

EuVod

20.07.18

✎

10:05

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

17

ks_83

20.07.18

✎

11:12

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

18

EuVod

20.07.18

✎

12:45

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

19

spectre1978

25.07.18

✎

19:19

20

Рэйв

25.07.18

✎

20:28

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

21

spectre1978

25.07.18

✎

21:57

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

22

kofeinik

25.07.18

✎

23:24

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

23

Boleev

26.07.18

✎

11:45

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

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

24

spectre1978

26.07.18

✎

14:38

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

25

spectre1978

26.07.18

✎

14:38

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

26

YurAnt

26.07.18

✎

14:41

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

27

NSSerg

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>

28

spectre1978

03.08.18

✎

17:02

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

29

ProxyInspector

08.08.18

✎

11:31

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

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

30

spectre1978

08.08.18

✎

11:45

31

lucbak

08.08.18

✎

11:58

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

32

spectre1978

08.08.18

✎

12:06

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

33

NSSerg

08.08.18

✎

14:50

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

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

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

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

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

34

NSSerg

08.08.18

✎

14:56

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

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

35

ProxyInspector

10.08.18

✎

12:41

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

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

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

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

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

36

NSSerg

10.08.18

✎

14:27

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

37

NSSerg

10.08.18

✎

14:30

38

NSSerg

10.08.18

✎

14:31

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

39

NSSerg

12.08.18

✎

19:10

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

40

Cyberhawk

12.08.18

✎

19:45

41

ProxyInspector

12.08.18

✎

19:47

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

42

spectre1978

12.08.18

✎

20:00

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

43

spectre1978

17.08.18

✎

08:32

44

ProxyInspector

17.10.18

✎

12:47

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

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

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

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

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

45

ProxyInspector

17.10.18

✎

12:53

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

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

46

ProxyInspector

17.10.18

✎

13:03

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

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

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

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

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

47

Sasha_1CK

17.10.18

✎

13:31

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

48

EuVod

22.10.18

✎

20:38

49

big

23.10.18

✎

05:02

50

spectre1978

23.10.18

✎

06:35

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

51

EuVod

23.10.18

✎

10:48

52

big

23.10.18

✎

11:03

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

53

EuVod

23.10.18

✎

11:05

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

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

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

54

ProxyInspector

23.10.18

✎

11:07

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

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

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

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

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

55

EuVod

23.10.18

✎

15:22

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

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