Добавили метод получения ID сборочных заданий поставки. Используйте его вместо метода Получить сборочные задания в поставке, чтобы оптимизировать работу с поставками. Подробные данные сборочных заданий доступны в ответе отдельного метода.
Неактуальный метод Получить сборочные задания в поставке отключим 17 декабря.
Я может чего-то не понимаю, но не бред ли? Раньше я мог получить сразу все данные для сборки на конкретную поставку. Теперь мне нужно выгружать список всех поставок за определенный период и в них искать перебором нужные заказы из нового метода. Так что ли?
Довольно странная идея. Теперь придется вместо запроса на конкретно количество заказов делать запрос на 1000 и в этих 1000 искать по конкретной поставке, наоборот нагрузка возрастет
Работая со сборкой FBS, магазину нужно:
1. Вывести список поставок, из которого можно выбрать то, что будем собирать.
2. И вывести заказы на сборку в эту конкретную поставку.
Сейчас в 1 приходится дергать метод получения заданий - просто потому, что в методе получения поставок нет одной-единственной цифры: количества заказов в ней. Что мешало добавить эту цифру и облегчить нагрузку на API - непонятно.
Теперь во 2 получается полный привет: угадай, с какого момента тебе нужны заказы, да не промахнись, и получи список из тысячи, чтобы выбрать из него сорок нужных. Или несколько списков, если не угадал. Тот, кто это натворил, вообще представляет, как идет работа по FBS?
Старый метод надо оставить. Оба нужны
Нужно для метода "Получить информацию о сборочных заданиях" сделать возможность указать массив orderId и сделать его POST Так же как в "Получить статусы сборочных заданий"
Метод "Получить информацию о сборочных заданиях" в текущей реализации - рудимент
Ну это прям выстрел в ногу какой-то, а не оптимизация, чесслово. У нас полотно поставок, в каждую поставку по определенной логике кладется сборочное задание, чтобы определить куда что класть - нужно четко понимать что в поставке лежит на текущий момент. Очевидно, что для получения сборочных заданий диапазон дат будет указываться с большим запасом, чтобы точно не пропустить ничего. В итоге вместо одного запроса как было раньше, нам предлагается долбить АПИ по диапазону дат с пагинацией. Ну штош, хто мы такие чтоб удобно нам было)
Для получения стикеров
Было:
https://marketplace-api.wildberries.ru/api/v3/supplies/%s/orders
https://marketplace-api.wildberries.ru/api/v3/orders/stickers
Стало:
https://marketplace-api.wildberries.ru/api/v3/supplies
https://marketplace-api.wildberries.ru/api/marketplace/v3/supplies/%s/order-ids
https://marketplace-api.wildberries.ru/api/v3/orders
https://marketplace-api.wildberries.ru/api/v3/orders/stickers
Может не стоит отключать работающий и востребованный метод?
Действительно сомнительная “оптимизация ”, у нас связь между ERP и заказами FBS устроена через этот метод, благодаря ему получали информацию о товаре в заказе и формировали заказ для склада, а теперь для всего этого нужно скостылить получение того же артикула из заказа через еще массу запросов с пагинацией, естественно большого периода. Вместо того, чтобы получить свои 500 заказов с инфой из поставки 1 запросом - будем перебирать ближайший период в поисках каждого id. Думаю, что старый метод необходимо оставить.
Как теперь получить задания по идентификаторам? Нет же такого метода.
Почитал комментарии - приуныл и пошел править наш код.
И не понял, в чем проблема. По сути, стало меньше запросов ведь.
Формирование поставки:
Сборка:
Я что-то не так понял или из-за чего негатив? Зачем нам все данные по сборочному заданию получать второй раз, если мы их уже получили из метода /api/v3/orders/.
Приветствуем!
Новый метод призван ускорить обмен данными, но понимаем, что из-за него появилось много вопросов.
Согласно информации в инструкции по работе с разделом FBS, мы призываем минимизировать дополнительные обращения. Подробно описано здесь: https://dev.wildberries.ru/news/127.
Все сборочные задания появляются в методе "Получить список новых сборочных заданий": https://marketplace-api.wildberries.ru/api/v3/orders/new. Поэтому советуем сохранять информацию c его помощью и сверяться с ней. Это - самый надёжный способ, позволяющий избежать лишних запросов.
Тем не менее, перестройка логики и систем - трудоёмкий процесс, поэтому мы заложили период работы старого метода до 17 декабря. Дополнительно для сверки остаётся активным метод "Получить информацию о сборочных заданиях": https://marketplace-api.wildberries.ru/api/v3/orders.
Нам важно слышать сообщество, поэтому, если у вас остаются кейсы, в которых данный подход невозможен, или существуют другие проблемы - призываем описать их на форуме подробно.
Я уже дважды столкнулся с проблемой из-за того, что теперь не могу получать содержимое поставки. Был сбой, новые задания отправились в поставку, а у меня в базу не все записались.
В результате мои работники с поставкой работать просто не могут (вся работа идет через мою систему). Раньше содержимое поставки просто перечитали бы от ВБ. А сейчас пришлось логинить их в ЛК ВБ, и доделывать через него. Из-за этого меня разбудили в 9 утра, пришлось давать им доступ...
Отключив старый метод вы всем причинили просто страшные неудобства :( Это самое странное нововведение, которое только можно себе представить! Все остальные новинки помогали, улучшали производительность. А эта создает просто дикие проблемы! :((((
Пожалуйста!!! Верните метод получения содержимого поставки. Он ОЧЕНЬ нужен!
У нас сотни новых заданий, получаем через /api/v3/orders/new, мы их раскидываем по поставкам, раскидали.
В процессе появляются новые задания которые вручную можем раскинуть по поставкам, информация по этим заказам уже не подтянется.
Далее открываем поставку, /api/v3/supplies/{supplyId}/orders получаем всю информацию, если что, можно обновить то, что нужно.
Сейчас нужно колбасить /api/v3/orders по 1-6 запросов на каждую поставку. Новое задание добавилось, опять всё обновлять. Получается нужно создавать буфер для всех заданий который постоянно обновляется, например за последние 72 часа, включая те, что уже отсортированы и тд.
Рассмотрите возможность сделать альтернативу /api/v3/orders по списку.