Привет всем!

Наша команда WB API анализирует методы, связанные с логистикой и управлением поставками. В фокусе нашего внимания сейчас — метод GET /api/v3/supplies и связанные с ним процессы.

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

Пожалуйста, поделитесь в комментариях опытом работы с методом GET /api/v3/supplies:

• Для каких конкретных бизнес-задач и в каких сценариях вы используете этот метод?
• Какие именно данные из ответа метода являются для вас наиболее важными и как они применяются в ваших системах?
• С какими сложностями, ограничениями или неудобствами вы сталкиваетесь при использовании текущего метода?

Наши команды будут внимательно следить за этой темой и участвовать в обсуждении.

Приветствуем ваше мнение!

А мнение сообщества, уже выраженное в двух темах этого же форума:

https://dev.wildberries.ru/forum/topics/1617 https://dev.wildberries.ru/forum/topics/1661 как-то ускользнуло из этого фокуса?

Судя по реакции (и особенно ее отсутствию), элементарная схема "получаем поставки (НАДО КОЛИЧЕСТВО ЗАКАЗОВ! АУ!!!) - получаем заказы (НАДО ВЫБОР ЗАКАЗОВ ИЗ ПОСТАВКИ! НА КОЙ ХРЕН НАМ ИХ ПЕРЕБИРАТЬ?! ЗДЕСЬ ЕСТЬ КТО-НИБУДЬ?..)" разработчикам пока и в голову не приходила.

Добавить поле updatedAt для мониторинга изменения поставок, если например изменился состав поставки, то это поле должно обновлятся. Это нужно чтобы лишний раз не запрашивать данные о составе поставки через https://marketplace-api.wildberries.ru/api/marketplace/v3/supplies/{supplyId}/order-ids

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

Добрый день!

Обратной связи по работе FBS методов получено достаточно, и объективно работать с этими методами стало только хуже.

Метод: Получить информацию о сборочных заданиях GET /api/v3/orders

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

- Было: 1 запрос на поставку чтобы получить список заданий

- Стало: 1 запрос на получение orderIDs, 1 запрос на получение заданий с фильтром по дате (читай пальцем в небо) [GET /api/v3/orders] если повезло и заказов мало. Если не повезло еще +3-5-10 запросов в зависимости от количества заказов.

Нужно сократить количество запросов?

Как буто бы логично, что для минимизации запросов к API нужно ПРЕДОСТАВЛЯТЬ фильтры в запросе, чтобы получать только ту информацию которая нужна, например по ORDER_ID или SUPPLY_ID, тем самым сокращая размер выборки, а не УБИРАТЬ фильтры, заставляя получать 1000 заданий и искать в них нужные 15.

--------------------

Метод: Получить список поставок /api/v3/supplies

Вот ваш посыл: мы хотим сократить количество запрсов к API.

Уже тысячу раз писали что в этом методе нужна элементарная сортировка по ID\DATE_CREATE ASC\DESC.

Но нет - давайте получать каждый раз все 2500 поставок, чтобы найти только что созданную.

--------------------

Не бьется логика внесения изменений в API с посылом - сократить количество запросов к API.

Запросов и костылей становится только больше.

Получить нужную информацию и следить за ее актуальностью становится сложней.

API Платный. Платный и платный, только делайте нормально.

Свежий пример.

Заказ отправлен 23 февраля. ВБ его в процессе доставки протерял и предлагает продавцу - отгрузите заново.

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

..И ломаем вывод листа подбора, потому что заказ 8-дневной давности. А при формировании листа, чтобы не увеличивать энтропию, проверяются заказы только за последние три дня - у нас сотни заказов в день, если я буду перебирать все, что было за месяц, у меня кончится либо память на VPS, либо терпение сборщиц. А может, и лимиты ВБ.

При этом предложенный ВБ вариант - хранить у себя заказы для уменьшения количества запросов - ни хрена не поможет в этой конкретной ситуации. Он же у меня неделю как обработан...