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

Skirbo +
commercetools

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

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

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

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

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

Сохранить Project, магазин и внешний номер вместе со строками физических товаров.

Наличие SKU по каналуSkirbo → commercetoolsНужна проверка

Проверить модель канала запаса и различие физического количества и доступности.

Результат исполненияSkirbo → commercetoolsНужна проверка

Согласовать разрешённые обновления заказа и защиту от перезаписи параллельных изменений.

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

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

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

commercetools рассматриваем в рамках конкретного Project, региона API и выбранных Store. Для продавца и фулфилмента важны SKU, supply channel и версии объектов: складской запас, коммерческий резерв и частичные доставки должны изменяться согласованно.

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

Адрес API и учётные данные должны соответствовать региону Project. Нужные scopes на orders/inventory проверяются по актуальному контракту приложения; примеры региона не копируются в другой tenant.

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

  1. Читаем актуальный заказ, его версию, строки, shipping-контекст и уже зарегистрированные доставки. Проверяем, что партия относится к нужному Store и владельцу товара.
  2. Сопоставляем line item с SKU клиента и физической площадкой; при Multiple shipping сохраняем нужный shippingKey. Доставка без соответствующего shipping-контекста не создаётся.
  3. Skirbo фиксирует фактическую партию и собственный устойчивый идентификатор результата. До записи проверяет сумму уже отгруженного и новой партии по каждой строке.
  4. Отправляем addDelivery по подтверждённой схеме с исходными items и при необходимости parcels. Контроль перепоставки остаётся нашим правилом: API сам такую границу не обеспечивает.
  5. Читаем обновлённый заказ и находим созданную доставку по согласованной связи; при потере ответа сначала ищем результат, не повторяем создание вслепую.
  6. Принятый delivery связывается со складской партией и становится основанием для обратного статуса клиентского канала. Факт добавления delivery не подтверждает физическое вручение покупателю.
  7. При конфликте версии перечитываем заказ и пересчитываем оставшееся количество. Если параллельная партия уже заняла лимит, блокируем повтор и передаём расхождение оператору.

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

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

Частичная доставка с собственным контролем количества

Задача: Не превысить количество заказа при нескольких партиях и повторе запроса.

Когда начинается: Склад завершил очередную разрешённую партию заказа выбранного Project/Store.

  1. Читаем актуальный заказ, его версию, строки, shipping-контекст и уже зарегистрированные доставки. Проверяем, что партия относится к нужному Store и владельцу товара.
  2. Сопоставляем line item с SKU клиента и физической площадкой; при Multiple shipping сохраняем нужный shippingKey. Доставка без соответствующего shipping-контекста не создаётся.
  3. Skirbo фиксирует фактическую партию и собственный устойчивый идентификатор результата. До записи проверяет сумму уже отгруженного и новой партии по каждой строке.
  4. Отправляем addDelivery по подтверждённой схеме с исходными items и при необходимости parcels. Контроль перепоставки остаётся нашим правилом: API сам такую границу не обеспечивает.
  5. Читаем обновлённый заказ и находим созданную доставку по согласованной связи; при потере ответа сначала ищем результат, не повторяем создание вслепую.
  6. Принятый delivery связывается со складской партией и становится основанием для обратного статуса клиентского канала. Факт добавления delivery не подтверждает физическое вручение покупателю.
  7. При конфликте версии перечитываем заказ и пересчитываем оставшееся количество. Если параллельная партия уже заняла лимит, блокируем повтор и передаём расхождение оператору.

Результат: Частичные поставки сохраняют количественный контроль даже там, где провайдер его не выполняет.

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

  • Корректный shipping-контекст и права записи проверяются на среде клиента.

Остатки по supply channel

Задача: Избежать двойного вычитания резерва и смешения площадок.

Когда начинается: После движения изменилось физическое количество SKU.

  1. Связываем SKU и supplyChannel с выбранным складским контуром; отсутствие channel — отдельная область, а не любой склад.
  2. Согласуем, кто меняет quantityOnStock и кто создаёт reservation. Не отправляем availableQuantity как физический остаток без учёта определения поля.
  3. После записи сверяем состояние с учётом документированной задержки пересчёта; не обещаем немедленную видимость всем каналам.

Результат: Физический запас и коммерчески доступный объём сохраняют разные значения.

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

  • Supply channel не объявляется физическим складом без карты соответствия.

Конфликт версии при параллельных изменениях

Задача: Сохранить чужое принятое изменение при обновлении запаса.

Когда начинается: Запись получила ConcurrentModification.

  1. Сохраняем исходное намерение и перечитываем текущую version и quantities.
  2. Повторно рассчитываем допустимое изменение с учётом нового состояния; слепой повтор старого абсолютного значения запрещён проектным правилом.
  3. После успешной записи фиксируем принятую version и контрольное состояние; непримиримый конфликт разбирает ответственный за запас.

Результат: Обновление не теряет параллельный резерв или приёмку.

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

  • API-версия объекта не заменяет бизнес-решение о том, чья корректировка верна.

Возврат части партии с отдельной проверкой товара

Задача: Согласовать возвратные строки Order с реальной приёмкой и не вернуть повреждённую единицу в продажу.

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

  1. Находим исходный Project, Order, line item и складскую партию; менеджер подтверждает допустимое количество возврата с учётом прежних приёмок.
  2. Согласуем с владельцем Order, как его процесс создаёт returnInfo и связывает возвратную позицию с исходной строкой; неизвестный идентификатор не заменяем совпавшим артикулом.
  3. Склад принимает фактически привезённые единицы, отдельно отмечает недостачу, подмену и повреждение. Обещанный возврат не увеличивает остаток.
  4. До автоматической записи проверяем допустимый переход состояния возвратной позиции. Для неописанного перехода сохраняем операторскую задачу, а не подбираем похожую команду.
  5. Ответственный за товар разрешает возвращение пригодного количества в доступный запас; брак остаётся в отдельной области. Политику влияния возвратного статуса на inventory проверяем на среде клиента, чтобы не оприходовать одну единицу дважды.
  6. Финансовый владелец отдельно подтверждает компенсацию покупателю. Складская приёмка и изменение платёжного состояния не считаются доказательством банковского возврата.
  7. Перечитываем принятую возвратную позицию и согласованный запас. Потерянный ответ сначала разрешаем сверкой, а конфликт версии — чтением актуального Order и повторной оценкой намерения.

Результат: По каждой возвращённой единице видны исходная отгрузка, фактическое качество, решение о запасе и отдельное финансовое действие.

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

  • Автоматическое изменение запасов при возвратном статусе и правила возврата комплекта требуют проверки проекта; это не готовый возвратный коннектор.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиcommercetools OrderСостав, Store и shipping-контекст принадлежат коммерческому заказу.
SKU и вариантыProduct variant/SKU и учёт клиентаSKU связывается с владельцем товара; supplyChannel дополняет область запаса.
Остатки и резервНазначенный физический учёт и reservation policyquantityOnStock, availableQuantity и reserved не взаимозаменяемы.
СтатусыOrder/delivery и физическая партия SkirboРегистрация delivery и вручение покупателю различаются.
ДокументыERP/финансовый контурПлатёж и юридический документ не выводятся из addDelivery.
ВозвратыПродавец и склад осмотраReturn data, refund и пригодный запас согласуются отдельными действиями.

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

  • Какой inventoryMode и кто создаёт reservation в проекте?
  • Каковы shipping mode, права и устойчивый ключ связи delivery с партией?
  • Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
Перед оценкой

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

  • Регион API и Project commercetools, выбранные Store и права приложения.
  • Связь SKU, складов и каналов запаса.
  • Пример заказа с изменением версии и правила распределения ответственности за его состояние.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

  • Регион и адрес API должны соответствовать tenant клиента, а не примеру из документации.
  • Правила reservation и кастомные типы проекта требуют отдельной проверки; наличие API не подтверждает готовый процесс Skirbo.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • Удаление Delivery из Order само по себе не возвращает товар со стороны перевозчика. Физический возврат, восстановление запаса и финансовая компенсация имеют отдельных владельцев.
Стоимость и запуск

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

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

Нужно ли хранить Project рядом с номером заказа?

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

Нужно ли хранить Project рядом с номером заказа?

Да, в проектном соответствии внешний идентификатор должен однозначно указывать контур. Одинаковый номер в другом Project не должен стать повтором или чужим заказом.

Что если заказ изменён менеджером во время сборки?

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

API сам запретит отгрузить больше заказанного?

В прочитанной схеме addDelivery прямо указано отсутствие такой проверки. Поэтому сумма партий проверяется в предлагаемом процессе до записи и повторно после конфликта версии.

Почему нельзя отправить свободный остаток как quantityOnStock?

Свободный объём уже учитывает reserved. Подмена им физического количества может вычесть резерв повторно; значения и владельца расчёта нужно согласовать.

Можно вернуть товар в продажу сразу после создания returnInfo?

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

Почему резерв может отличаться сразу после принятого обновления?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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