ошибка APLM0012 An unexpected error has occurred while invoking target service operationon

WendyH wrote:Николай Анатольевич, все эти сообщения на форуме - не просто нытьё лентяев-сопротивленцев. Это - сорванные нервы людей под грузом ответственности, штрафы, реальные деньги на штрафы.
Вчера Ленте за недопоставку на 160 тыс встряли. Настоящих денег. А причина всем непонятна. Машина стоит на разгрузке, её не принимают, потому как ВСД приёмщики не видят. Никто там ни в чьё положение вставать и не собирался. ВСД просто приходят позже окна приёмки.
И это только один из множества случаев.

Отправляйте информацию по штрафу в Россельхознадзор.
Они говорили, что с сетями есть договоренность штрафы не брать.
Все понимают, что это вранье, потому что штрафы выписывают.
Ну так получите хоть официальный ответ.

TWAIN wrote:с сетями есть договоренность штрафы не брать.

Лучше бы была договоренность принимать товар без эВСД, а не просто штрафы.
Как там в магазинах ситуация по стране? Перебои с продуктами уже начались? )

egais2018 wrote:

TWAIN wrote:с сетями есть договоренность штрафы не брать.

Лучше бы была договоренность принимать товар без эВСД, а не просто штрафы.
Как там в магазинах ситуация по стране? Перебои с продуктами уже начались? )

Я из-за Меркурия и в магазин-то сходить не могу.
Доползаю вечером до подвала в соседнем доме, беру там кефир и булочку.
На работе вроде в столовой проблем нет.

TWAIN wrote:Отправляйте информацию по штрафу в Россельхознадзор.
Они говорили, что с сетями есть договоренность штрафы не брать.
Все понимают, что это вранье, потому что штрафы выписывают.
Ну так получите хоть официальный ответ.

Руководство сказало, что написать в РСХН и потерять сеть (которая маляву явно не поприветствует), не очень так вариант.
Поэтому продолжаем жрать кактус.

WendyH wrote:

TWAIN wrote:Отправляйте информацию по штрафу в Россельхознадзор.
Они говорили, что с сетями есть договоренность штрафы не брать.
Все понимают, что это вранье, потому что штрафы выписывают.
Ну так получите хоть официальный ответ.

Руководство сказало, что написать в РСХН и потерять сеть (которая маляву явно не поприветствует), не очень так вариант.
Поэтому продолжаем жрать кактус.

Терпилы терпят, вопросов нет.

TWAIN wrote:

WendyH wrote:Николай Анатольевич, все эти сообщения на форуме - не просто нытьё лентяев-сопротивленцев. Это - сорванные нервы людей под грузом ответственности, штрафы, реальные деньги на штрафы.
Вчера Ленте за недопоставку на 160 тыс встряли. Настоящих денег. А причина всем непонятна. Машина стоит на разгрузке, её не принимают, потому как ВСД приёмщики не видят. Никто там ни в чьё положение вставать и не собирался. ВСД просто приходят позже окна приёмки.
И это только один из множества случаев.

Отправляйте информацию по штрафу в Россельхознадзор.
Они говорили, что с сетями есть договоренность штрафы не брать.
Все понимают, что это вранье, потому что штрафы выписывают.
Ну так получите хоть официальный ответ.

Вчера отправил в час дня ВСД, в 16:00 звонят и спрашивают когда я отправлю. Пришлось по электронке отправлять распечатку сжатой формы с расширенной информацией из вэб интерфейса. Там и дата и время есть, если что.

TWAIN wrote:

WendyH wrote:

TWAIN wrote:Отправляйте информацию по штрафу в Россельхознадзор.
Они говорили, что с сетями есть договоренность штрафы не брать.
Все понимают, что это вранье, потому что штрафы выписывают.
Ну так получите хоть официальный ответ.

Руководство сказало, что написать в РСХН и потерять сеть (которая маляву явно не поприветствует), не очень так вариант.
Поэтому продолжаем жрать кактус.

Терпилы терпят, вопросов нет.

Пф, как сказал сегодня руководитель: "Мы в позе пьющего оленя".
Вы с сетями то работали, чтобы советовать качать права там? Мы для них никто.
Ненавижу, ..., сети. Особенно Тандер. Производителей ни во что не ставят. Презрительней отношения не видел.

WendyH wrote:

TWAIN wrote:

WendyH wrote:

TWAIN wrote:Отправляйте информацию по штрафу в Россельхознадзор.
Они говорили, что с сетями есть договоренность штрафы не брать.
Все понимают, что это вранье, потому что штрафы выписывают.
Ну так получите хоть официальный ответ.

Руководство сказало, что написать в РСХН и потерять сеть (которая маляву явно не поприветствует), не очень так вариант.
Поэтому продолжаем жрать кактус.

Терпилы терпят, вопросов нет.

Пф, как сказал сегодня руководитель: "Мы в позе пьющего оленя".
Вы с сетями то работали, чтобы советовать качать права там? Мы для них никто.
Ненавижу, ..., сети. Особенно Тандер. Производителей ни во что не ставят. Презрительней отношения не видел.

Какая разница работал или нет? Это субъективный переход на личности.
Разве моя фраза "Терпилы терпят, вопросов нет." не отражает объективной реальности?
Ваш очередной ответ еще раз это подтверждает. Я не говорю, что у вас и у нас много вариантов.
Но именно потому что все терпят - они и наглеют. Есть профильные объединения, они могут объединить производителей,
лишить сети молочной и мясной продукции в принципе, пусть в дворовых хозяйствах ее заказывают.

А касательно страха пожаловаться в Россельхознадзор?
Я конечно, понимаю, что они ничего не сделают и скажут:
это взаимоотношения бизнеса, мы тут не при чем.
Что вы ждете от торгашей и чиновников?
Пока ФАС не возбудится - толку не будет.

При попытке получить список записей журнала продукции, естественно, получаем ошибку APLM012.
На данный момент прогрузилось ~7000 записей из примерно 10000.
Пытались разными способами оптимизировать выборки, чтобы не грузить лишние данные.

Были такие варианты:

1) Запрашивать данные за небольшой период(неделя - месяц) с использованием фильтра receiptDateInterval.
Не получилось добиться корректной работы фильтра. Выяснилось, что, во-первых, правильно работает только параметр beginDate.
А endDate отрабатывает как-то странно. Например, запрашиваю данные за 2 декабря. Получаю какую-то странную выборку с некоторыми (не всеми) записями, созданными 2 - 18 декабря.
Причем у меня в базе записей, которые проскочили между ошибками, уже гораздо больше.

На всякий случай прикладываю текст запроса в xml, может кто заметит ошибку:

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="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.1</serviceId>
				<issuerId>***********************************</issuerId>
				<issueDate>2019-05-29T11:24:22</issueDate>
				<data>
					<getStockEntryListRequest xmlns="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2">
						<localTransactionId>69ea5614-a48e-4418-9931-1a8f836ab1d8</localTransactionId>
						<initiator xmlns:d7p1="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
							<d7p1:login>*********************</d7p1:login>
						</initiator>
						<listOptions xmlns="http://api.vetrf.ru/schema/cdm/base">
							<count>100</count>
							<offset>0</offset>
						</listOptions>
						<enterpriseGuid xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">*****************************</enterpriseGuid>
						<searchPattern xmlns:d7p1="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
							<d7p1:blankFilter>ALL</d7p1:blankFilter>
							<d7p1:receiptDateInterval xmlns:d8p1="http://api.vetrf.ru/schema/cdm/base">
								<d8p1:beginDate>2018-01-01T00:00:00</d8p1:beginDate>
								<d8p1:endDate>2019-01-31T23:59:59</d8p1:endDate>
							</d7p1:receiptDateInterval>
						</searchPattern>
					</getStockEntryListRequest>
				</data>
			</application>
		</submitApplicationRequest>
	</Body>
</Envelope>

2) Пытались записывать, в какой пачке пришли правильные записи, т.е. записывали параметры offset и Индекс в выдаче для каждой полученной записи.
А потом пытались делать запросы только для пропущенных пачек. Каково же было мое удивление, когда оказалось, что записи выдаются каждый раз в новом порядке.
То есть то, что мне выдали в одном запросе с офсетом, например 1000, не совпадает с тем, что выдается с таким же офсетом в другом запросе.

Вопрос - я не ошибаюсь? Может я чего-то не учитываю?

Зачем указываете период создания? Если вам просто нужно получить все записи, то период можно не указывать. Получение записей нормально проходит при указании 500-600 записей в выборке. У меня период создания нормально работал за один день, проблем с получением записей не было, всегда приходили все записи, но я запрашивал только не нулевые. Может быть некоторые записи уже помечены к перемещению в архив и метод не возвращает их.

serg882 wrote:Зачем указываете период создания? Если вам просто нужно получить все записи, то период можно не указывать. Получение записей нормально проходит при указании 500-600 записей в выборке. У меня период создания нормально работал за один день, проблем с получением записей не было, всегда приходили все записи, но я запрашивал только не нулевые. Может быть некоторые записи уже помечены к перемещению в архив и метод не возвращает их.

У человека 10000 записей

serg882 wrote:Зачем указываете период создания? Если вам просто нужно получить все записи, то период можно не указывать.

Как я уже писал, мы рассматривали два варианта сокращения объемов загрузки - по периоду или по смещению (офсету). Ни тот, ни другой способ нормально не работают.
Кстати, техподдержка рекомендует запрашивать интервалом не больше 1 суток.

Там у них какая-то путаница в терминологии. Оказывается, receiptDateInterval фильтрует не по дате создания, а по дате обновления. Но и это не все. В поле createDate, судя по всему, выводится не дата создания записи, а дата редактирования (ата создания актуальной версии). Пока это не точно, нужно проверять и анализировать.

shmuylovich wrote:

serg882 wrote:Зачем указываете период создания? Если вам просто нужно получить все записи, то период можно не указывать.

Как я уже писал, мы рассматривали два варианта сокращения объемов загрузки - по периоду или по смещению (офсету). Ни тот, ни другой способ нормально не работают.
Кстати, техподдержка рекомендует запрашивать интервалом не больше 1 суток.

Там у них какая-то путаница в терминологии. Оказывается, receiptDateInterval фильтрует не по дате создания, а по дате обновления. Но и это не все. В поле createDate, судя по всему, выводится не дата создания записи, а дата редактирования (ата создания актуальной версии). Пока это не точно, нужно проверять и анализировать.

Самый нормальный вариант, ничего не запрашивать в Меркурии. Если у вас работа и в веб-интерфейсе и в апи, тогда это не вариант. Кто-то использует метод GetStockEntryChangesListOperation для получения записей, возможно он и вам подойдет. У меня записи запрашиваются только, если были отправлены дубли документов (заявка на отправку приходит со статусом rejected, но по факту она проходит). У них путаница в коде скорее всего, в самой записи журнала есть поле Дата создания и поле Дата обновления.

Кто-то использует метод GetStockEntryChangesListOperation

Спасибо, попробую.

Не ломайте голову как бы вы не извращались с датами и т.п. избавится от APLM012 не получится. Её можно победить только повторными запросами, пока не получите результат.
Мы пришли к выводу, что ошибка возникает от загрузки самого шлюза, если очередь из запросов на шлюзе образовалась больше какого-то значения, то идёт APLM012, пока очередь не уменьшится.