Подскажите, планируется ли увеличение квот на количество операций в API 2 для уменьшения количества

Подскажите, планируется ли увеличение квот на количество операций в API 2 для уменьшения количества ошибок APLM0012?
Или мы так и будет топтаться на месте?

Конечно

Вырезка из всех еженедельных отчетов

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

а Вы работайте... всё штатно...

лично у меня ни разу, начиная с 25.07 не получилось синхронизировать записи СЖ полностью, это печально...

Подскажите, господа

с 25.07 аплм0012 сильно участились
с 14.08 аплм0012 участились ещё больше + стали очень долго получаться ответы по запросам (если раньше заявка оформлялась секунды 2-3, то теперь до 3-х минут!!!)

Сегодня 26 заявок на перевозку на одно ТС отправлялись 56 минут!!!

Только у нас такие проблемы? или у всех?

Погоди, молочники придут, тогда вы будете эти 56 минут вспоминать как золотые времена)

Zoeh wrote:Подскажите, планируется ли увеличение квот на количество операций в API 2 для уменьшения количества ошибок APLM0012?
Или мы так и будет топтаться на месте?

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

Как таковых квот нет, покрайне мере мы не наблюдаем на свих внедрениях.

За последние 2 месяца, ошибка стала реже как минимум в два раза.
Как только введут более явные ограничения на запросы, обязательные периоды дат, еще лучше частоту запросов, тогда ситуация будет еще лучше.

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

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

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

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

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

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

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

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

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

Shadasp wrote:
Скорее всего проблема в корректности заполнения заявки, тоесть в ней может быть не корректно заполнена цель реализации, не кооректная упаковка и т.д.

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

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

результат ВСЭ = ВСЭ подвергнуто сырьё, из которого произведена продукция
назначение - в корм непродуктивным животным
способ хранения при перевозке - Вентилируемый
благополучие - Местность благополучна по заразным болезням животных

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

Vesta_IT wrote:

Shadasp wrote:
Скорее всего проблема в корректности заполнения заявки, тоесть в ней может быть не корректно заполнена цель реализации, не кооректная упаковка и т.д.

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

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

результат ВСЭ = ВСЭ подвергнуто сырьё, из которого произведена продукция
назначение - в корм непродуктивным животным
способ хранения при перевозке - Вентилируемый
благополучие - Местность благополучна по заразным болезням животных

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

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

Категория продукции у вас как я понимаю: "корма для кошек" ?

допустим "корма для непродуктивных животных" - это устаревшая категория продукции, ее нужно изменять инветаризацией.

да мы пару дней назад получили такой ВСД.
с этим назначением груза..

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

Vesta_IT wrote:таки были проблемы в самой заявке )
разобрались, успех, нужные данные получили

Рад, что нишли проблему