Обсудить задачу
Интернет-магазины

Skirbo +
Saleor

Не отгрузить одну строку дважды и не вычесть остаток второй раз. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

ОперацияНаправлениеСостав и готовность
Заказ выбранного каналаSaleor → SkirboОбсудим в составе подключения

Передавать оформленный заказ с разрешением на исполнение, а не незавершённый checkout.

Складской результат по строкамSkirbo → SaleorНужна проверка

Проверить способ отражения выполненного количества и частичных отправлений.

Наличие варианта на складеSkirbo → SaleorНужна проверка

Уточнить связь склада, канала и резерва; не складывать запасы несвязанных площадок.

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

Saleor рассматриваем как commerce-контур с GraphQL, каналами продаж и складами. Канал определяет коммерческий контекст, а warehouse — место хранения; их нельзя смешивать. Для фулфилмента главный процесс — исполнение строк заказа по конкретным складам с корректным резервом.

Как организовать обмен

В прочитанной документации для order fulfillment указано MANAGE_ORDERS; область приложения и остальные разрешения проверяются для версии клиента. Доступ каналов и складов не предполагается автоматически по наличию GraphQL.

Предлагаемый порядок работы

  1. Читаем заказ, канал, строки и оставшееся к исполнению количество; проверяем коммерческий допуск и права приложения. Checkout не используется вместо созданного заказа.
  2. Сопоставляем variant и исходную строку с SKU клиента, а Saleor warehouse — с физическим складом. Для строки сохраняем распределение количества по складам.
  3. Skirbo резервирует и комплектует согласованную партию. До записи проверяем, что сумма новых и уже исполненных количеств не превышает разрешённую строку.
  4. Фактическую партию передаём через подтверждённую mutation orderFulfill с исходной строкой, складом и количеством; номер отслеживания добавляется только для реального отправления.
  5. Учитываем shop.fulfillmentAutoApprove: при выключенном автоматическом одобрении результат может оставаться WAITING_FOR_APPROVAL. Ответ о создании fulfillment ещё не является финальным подтверждением исполнения.
  6. Читаем fulfillment и количество исполнения заказа; при необходимости уполномоченный процесс одобряет результат. Одновременно сверяем влияние trackInventory, чтобы отдельный поток остатков не повторил списание.
  7. При потере ответа сначала ищем уже созданный результат. Отмена или ошибка после физической передачи товара требует разбирательства; не выполняем автоматическую отмену, которая восстановит запас несуществующего на складе товара.

Практические сценарии

Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.

Частичное исполнение из конкретного warehouse

Задача: Не отгрузить одну строку дважды и не вычесть остаток второй раз.

Когда начинается: Допущенный заказ Saleor имеет физические строки, доступные к исполнению.

  1. Читаем заказ, канал, строки и оставшееся к исполнению количество; проверяем коммерческий допуск и права приложения. Checkout не используется вместо созданного заказа.
  2. Сопоставляем variant и исходную строку с SKU клиента, а Saleor warehouse — с физическим складом. Для строки сохраняем распределение количества по складам.
  3. Skirbo резервирует и комплектует согласованную партию. До записи проверяем, что сумма новых и уже исполненных количеств не превышает разрешённую строку.
  4. Фактическую партию передаём через подтверждённую mutation orderFulfill с исходной строкой, складом и количеством; номер отслеживания добавляется только для реального отправления.
  5. Учитываем shop.fulfillmentAutoApprove: при выключенном автоматическом одобрении результат может оставаться WAITING_FOR_APPROVAL. Ответ о создании fulfillment ещё не является финальным подтверждением исполнения.
  6. Читаем fulfillment и количество исполнения заказа; при необходимости уполномоченный процесс одобряет результат. Одновременно сверяем влияние trackInventory, чтобы отдельный поток остатков не повторил списание.
  7. При потере ответа сначала ищем уже созданный результат. Отмена или ошибка после физической передачи товара требует разбирательства; не выполняем автоматическую отмену, которая восстановит запас несуществующего на складе товара.

Результат: Физическая партия, fulfillment и изменение резерва согласованы по строке и складу.

Если возникло исключение

  • Приложение и версия должны поддерживать требуемые permissions и mutation; это не доказательство установленного приложения Skirbo.

Возврат после отгрузки и осмотр

Задача: Вернуть в продажу только реально принятый годный товар.

Когда начинается: Покупатель согласовал возврат исполненной строки.

  1. Сохраняем связь с заказом, fulfillment, вариантом и исходным warehouse; выбираем фактический склад возврата.
  2. Принимаем и осматриваем количество, отделяя годное от брака и недокомплекта.
  3. Согласуем отражение возврата в Saleor и отдельную корректировку пригодного запаса; финансовое возмещение подтверждает коммерческий контур.

Результат: Возврат не подменяется отменой fulfillment с автоматическим восстановлением запаса.

Если возникло исключение

  • При trackInventory=false стандартные складские изменения не происходят; модель проекта нужно проверить.

Канал продаж и доступные склады

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

Когда начинается: Меняется ассортимент канала, зона доставки или связанный склад.

  1. Проверяем связь channel, shipping zone, warehouse и стран обслуживания.
  2. Карта исполнения разрешает только подходящие склады и SKU; коммерческая доступность канала не равна полному физическому остатку всех площадок.
  3. Контрольный заказ проверяет выбранный маршрут и резерв; синхронное решение доставки на checkout не выполняет складскую комплектацию.

Результат: Многоскладское распределение учитывает коммерческий контекст и доставку.

Если возникло исключение

  • Правила конкретного shipping app и allocation strategy проверяются отдельно.

Исполнение ожидает одобрения после упаковки

Задача: Не повторить физическую сборку и не выдать ожидание одобрения за принятый результат.

Когда начинается: Для уже подготовленной партии создан fulfillment со статусом WAITING_FOR_APPROVAL.

  1. Связываем полученный fulfillment ID с заказом, строками, variant, warehouse и единственным журналом физической партии. Подтверждаем, что ответ mutation не содержит бизнес-ошибок.
  2. Проверяем настройки fulfillmentAutoApprove, trackInventory и allocation конкретной установки. Допуск по оплате отдельно подтверждает продавец даже при разрешённом fulfillmentAllowUnpaid.
  3. Упакованный товар остаётся в известном складском состоянии. Ожидание одобрения не создаёт второе задание на подбор и не увеличивает исполненное количество в журнале.
  4. Уполномоченный процесс проверяет строки и оставшееся количество и передаёт одобрение существующего fulfillment. Превышение запаса не включается автоматически ради успешного ответа.
  5. Перечитываем fulfillment и quantityFulfilled/quantityToFulfill по строкам. Владелец запасов сверяет изменение allocation и остатка с единственной фактической партией.
  6. Физическую выдачу перевозчику подтверждаем отдельно. Отслеживание обновляется у существующего исполнения, когда номер относится к реальному отправлению.
  7. Если ответ одобрения потерян, сначала проверяем состояние существующего fulfillment. Если появилась отмена, после выдачи товара запускаем разбор возврата, а не автоматическое восстановление наличия.

Результат: Одно физическое исполнение связано с одним согласованным fulfillment и подтверждённым этапом одобрения.

Если возникло исключение

  • Не считаем любой HTTP-успех GraphQL отсутствием ошибок конкретной mutation.
  • Правила уведомления покупателя и складского допуска согласуют отдельно.

Кто управляет данными

ДанныеОтветственный источникПравило обмена
Заказ и строкиSaleor OrderКоммерческий состав и канал принадлежат заказу, а не checkout.
SKU и вариантыSaleor variant и учёт клиентаГлобальный идентификатор variant связывается со складским SKU в области клиента.
Остатки и резервСогласованная модель Saleor/SkirbotrackInventory и allocation учитываются так, чтобы одна отгрузка не дала двойное списание.
СтатусыSaleor fulfillment и физический факт складаWAITING_FOR_APPROVAL отделён от принятого исполнения; warehouse сохраняется.
ДокументыУчёт/платёжный контур продавцаFulfillment не является самостоятельным доказательством финансового документа.
ВозвратыПродавец и склад осмотраВозврат, отмена fulfillment, восстановление запаса и refund различаются.

Что обсудить перед пилотом

  • Каковы версия, trackInventory, fulfillmentAutoApprove и стратегия allocation?
  • Какая сторона делает итоговую корректировку stock после осмотра возврата?
  • Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
Перед оценкой

Что нужно уточнить

  • Версия Saleor, приложение и минимальные permissions для согласованных операций.
  • Каналы, склады и связь variants со SKU.
  • Пример заказа с частичным исполнением и правила освобождения резерва.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Страна юридического лица, валюта и коммерческие правила выбранного channel; warehouse и shipping zone проверяются отдельно от валютного контекста.
  • Тип размещения Saleor, версия схемы и значения fulfillmentAutoApprove, fulfillmentAllowUnpaid, trackInventory; бизнес-разрешение превышать запас не выводится из примера документации.
Границы сценария

Что учесть заранее

  • Checkout и заказ имеют разный смысл; завершение оплаты также проверяется отдельно.
  • Конкретные webhook-события и гарантии доставки нельзя выводить только из наличия GraphQL.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • GraphQL mutation может вернуть предметные errors при успешном сетевом обмене. Подтверждение проверяется по результату операции, fulfillment и количествам строк.
Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

Почему необходимо назвать канал Saleor?

Вопросы о подключении

Почему необходимо назвать канал Saleor?

Канал определяет контекст продаж; для складского сценария нужно понять, какие товары, склады и правила исполнения к нему относятся.

Можно ли считать fulfillment полным, если отправлена одна строка?

Только для фактически исполненной части. Остальные строки сохраняют собственные количества и требуют отдельного результата или отмены.

Что означает WAITING_FOR_APPROVAL для складского результата?

Fulfillment создан, но ещё ожидает одобрения по настройке магазина. В предложенном процессе это отдельный этап: проверяем одобрение и количество исполнения, прежде чем считать обратный результат принятым.

Можно отменить fulfillment, чтобы оформить любой возврат?

Такая отмена может восстановить stock и allocation. Возврат после передачи товара требует физической приёмки и отдельного решения; иначе в наличии появится товар, которого на складе нет.

Оплаченный заказ обязателен для любого fulfillment?

Это зависит от настройки Saleor fulfillmentAllowUnpaid и бизнес-правила продавца. В предлагаемом процессе оплата или разрешённый вид расчёта проверяются отдельно; факт появления fulfillment не заменяет эту проверку.

Нужно ли включить allowStockToBeExceeded, если не хватает товара?

В обычном предлагаемом сценарии — нет. Этот параметр позволяет превысить проверяемый запас; сначала разбирают резерв и физическое наличие, а отдельную модель предзаказа согласует владелец магазина.

Интеграция уже готова?

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

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Посмотрите другие сценарии

Весь каталог →
Ваш процесс → следующий шаг

Что хотите связать со Skirbo?

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

  1. Разберём задачуУточним роли, склады и операции.
  2. Проверим возможностьОпределим доступы, ограничения и состав работ.
  3. Согласуем запускОбсудим стоимость, сроки и критерии готовности.

Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.

1. Какие сервисы подключить?

До 5 сервисов в одной заявке.

Укажите роль — подскажем, какие особенности процесса описать.

2. Какие задачи решить?

Выберите от 1 до 8 задач.

Компания и объём заказов необязательно
3. Как с вами связаться?
Проверяем возможность отправки. Вы также можете подготовить запрос и передать его поддержке.
Открыть поддержку в Telegram

Копирование и переход в Telegram сами по себе не отправляют заявку.

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