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

Добрый день!

Заработался и продублировал собственный пост http://vetrf.ru/vetrf-forum/posts/list/7729.page
Прошу удалить.

Павел.

Добрый день!

В праздники 30.04.2018 сервера ФГИС Меркурий были недоступны с 04:53:03 по 05:06:36.

Павел.

Добрый день!

Коллеги, прошу Вашей помощи.
При отгрузке штучного товара никаких проблем не возникает, в упаковке указываю:

Подскажите пожалуйста что указывать при отгрузке весовых товаров с плавающим весом.

Павел.

Вот совет так совет, благодарю. В следующий раз на заправке попробую не полный бак, а по литру 80 литров залить )

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

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

Вывод, как в общем то и всегда, все манипуляции с остатками, в том числе инвентаризация, производятся при остановленных отгрузках и процессах производства

Добрый день!

Сегодня я был сильно избит своими пробелами в знаниях.
Проверял несколько ВСД операцией http://help.vetrf.ru/wiki/GetVetDocumentByUuidOperation_v2.0.
В ФГИС Меркурий нашел транзакцию, распечатал "сжатое с расширенной информацией", скопировал оттуда Код: 89B3-C79C-E562-4D17-9DC6-6964-0ED7-2D09, отправил запрос и ... получил ошибку "APLM0007 - Wrong application data format. Format validation failed due to XML Schema rules: Invalid text '89B3-C79C-E562-4D17-9DC6-6964-0ED7-2D09' in element: 'uuid'"
Далее проверил код в https://mercury.vetrf.ru/pub/operatorui?_action=checkVetDocument, корректно вернул информацию.

Сразу обратил внимание на разность групп и количество дефисов.

Формат вполне четко описан http://help.vetrf.ru/wiki/UUID [a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}
И никак не [a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}

Это конечно мои фантазии, но дотошный пользователь без труда определит не идентичность идентификаторов ВСД в распечатках их ФГИС Меркурий и документах поставщика.

Зачем и для кого я это все написал?) Оформление заняло времени больше, чем определение и исправление ошибки.

Павел.

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

Конечно прецедент "чтения грязных данных" довольно мрачно рисует будущее. Но ведь и блокировать остатки нельзя.

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

Добрый день!

Очередное открытие ограничений.
Одним запросом пытаюсь заменить признак "скоропорт" на "нескоропорт" для 2700+ позиций с помощью инвентаризации.
Другими словами, нужно каждую скоропорт продукцию списать и оприходовать аналогичный, но без признака скоропорт.
Возвращается ошибка:
The remote server returned an error: (413) Request Entity Too Large. Ошибка не Меркурий.

Далее пробую 1000 записей обработать и ... уже более 14 часов запрос в статусе IN_PROCESS.
Еще бы знать отработает он как надо или упадет/уже упал в ошибки, но ответа не вернул.

К слову, запросы и ответы храню как XML в MS SQL, запрос сохранился, но открыть его не представляется возможным (

Подскажите пожалуйста. У кого какой опыт по проведению масштабных процедур.

Павел.

у enterprise тип merc

xmlns:merc=""http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2""

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

Сегодня прошел вебинар компании Визард-Софт, на котором упоминалась регионализация. Мой вывод: кешировать постоянно меняющуюся информацию нельзя, тем более, что она зависит и от категории товара.

видел Ваш пост, стало страшновато, но не удивился

Добрый день!

Предлагаю выделить эту тему для сбора возвращаемых ошибок Меркурием, которые не соответствуют действительности. Если уже есть такая тема, не ругайтесь сильно.

Начну сам.
При попытке списания продукции инвентаризацией, которая была произведена через операцию "незавершенное производство" и еще не завершена, получим ошибку "MERC24008 Запись складского журнала продукции с указанным идентификатором не найдена в реестре РСХН, либо идентификатор не соответствует установленному формату."
Естественно идентификатор корректный, позиция есть, active и last = true

Павел.