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

Skirbo +
VTEX

Не потерять заказ после commit и не создавать повторную сборку при дубликатах. Ниже описано предложение проектирования связи со Skirbo; готовность коннектора не подтверждена.

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

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

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

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

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

Доступность складаSkirbo → VTEXНужна проверка

Согласовать warehouse и логистическую привязку; не смешивать наличия разных seller.

Отправление и фактические строкиSkirbo → VTEXНужна проверка

Проверить нужный OMS-переход, документы и данные отправления для этой роли.

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

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

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

VTEX рассматриваем в области конкретного account и роли seller либо оператора marketplace. Для склада важны разрешённый заказ, логистическая площадка и подтверждение обработки Feed: событие очереди не равно физической отгрузке.

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

AppKey/AppToken привязываются к account и роли; нужны минимальные permissions выбранных API. Feed связан с appKey; при его смене согласуется перенос и сверка незавершённых событий.

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

  1. Читаем запись Feed и затем актуальные детали заказа. Фильтр и статус допуска выбираем по процессу клиента; ошибочно написанный фильтр не считаем автоматически проверенным сервисом.
  2. Сохраняем событие, заказ и решение обработки в надёжном журнале. Проверяем seller, логистические строки, SKU, оплату и допустимость исполнения.
  3. Сопоставляем строки с клиентом фулфилмента и физическим складом, затем фиксируем единственное принятое задание. Дубликат события связываем с этой записью.
  4. После надёжного приёма в согласованный процесс подтверждаем запись Feed через commit. Нерелевантную, но обработанную запись тоже подтверждаем с причиной; временно не обработанную не теряем.
  5. Skirbo резервирует и комплектует физическую партию. Разрешённый переход к обработке и дальнейший маршрут результата проверяются отдельно от commit очереди.
  6. Возвращаем фактические строки, отправление и необходимые по договору данные в OMS подтверждённым методом; затем читаем принятое состояние. Номер накладной или документ не выдумывается из складского статуса.
  7. При сбое после commit продолжаем работу из собственного журнала; при потере события сверяем заказы отдельно. Отмена после начала отбора становится отдельным решением, а не повторной выдачей исходного задания.

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

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

Надёжный приём заказа из Feed

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

Когда начинается: Feed сообщил об изменении заказа в согласованной области account/продавца.

  1. Читаем запись Feed и затем актуальные детали заказа. Фильтр и статус допуска выбираем по процессу клиента; ошибочно написанный фильтр не считаем автоматически проверенным сервисом.
  2. Сохраняем событие, заказ и решение обработки в надёжном журнале. Проверяем seller, логистические строки, SKU, оплату и допустимость исполнения.
  3. Сопоставляем строки с клиентом фулфилмента и физическим складом, затем фиксируем единственное принятое задание. Дубликат события связываем с этой записью.
  4. После надёжного приёма в согласованный процесс подтверждаем запись Feed через commit. Нерелевантную, но обработанную запись тоже подтверждаем с причиной; временно не обработанную не теряем.
  5. Skirbo резервирует и комплектует физическую партию. Разрешённый переход к обработке и дальнейший маршрут результата проверяются отдельно от commit очереди.
  6. Возвращаем фактические строки, отправление и необходимые по договору данные в OMS подтверждённым методом; затем читаем принятое состояние. Номер накладной или документ не выдумывается из складского статуса.
  7. При сбое после commit продолжаем работу из собственного журнала; при потере события сверяем заказы отдельно. Отмена после начала отбора становится отдельным решением, а не повторной выдачей исходного задания.

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

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

  • Точное окно хранения Feed и действующие лимиты проверяются перед запуском; исторические значения не обещаются.

Разделённый заказ продавцов и складов

Задача: Не забрать чужие строки marketplace.

Когда начинается: Заказ распределён между несколькими sellers или логистическими маршрутами.

  1. Определяем роль account и право обработки только своей части заказа.
  2. Логистические строки связываем с SKU, warehouse и физической площадкой клиента; одинаковый SKU другого seller не объединяет запас.
  3. Каждая часть получает собственный фактический результат и подтверждение OMS; общий заказ не закрывается по одной собранной партии.

Результат: Фулфилмент работает только в разрешённой области продавца.

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

  • Доступ оператора marketplace не переносится на seller и наоборот.

Наличие и отмена в ходе обработки

Задача: Согласовать обещанный остаток с начатой работой.

Когда начинается: Пришла отмена или изменилось наличие логистического склада.

  1. Сверяем актуальный заказ и степень физической готовности, затем останавливаем допустимую часть задания.
  2. Освобождаем резерв только после подтверждённого решения; уже переданный перевозчику товар оформляется по отдельному процессу.
  3. Обновлённое наличие публикуем в согласованной warehouse-области и проверяем приём, сохраняя историю отмены.

Результат: Складской запас не возвращается в продажу раньше времени.

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

  • Применимость cancelation-request и права third-party fulfillment подтверждаются для конкретной роли.

Восстановление после простоя потребителя Feed

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

Когда начинается: Мониторинг обнаружил простой потребителя, смену appKey или расхождение очереди с собственным журналом.

  1. Останавливаем неконтролируемое создание новых заданий и фиксируем account, appKey и последний подтверждённый участок собственного журнала.
  2. Проверяем действующую конфигурацию Feed и её временные параметры; не принимаем пустую очередь за доказательство отсутствия заказов.
  3. Сравниваем сохранённые события с актуальными заказами разрешённого seller; для пропущенного интервала согласуем отдельную сверку OMS с владельцем магазина.
  4. Сопоставляем найденные строки с уже существующими складскими заданиями и физическими партиями. Повторное событие не запускает вторую сборку.
  5. Возобновляем незавершённые задания из долговечного журнала; отменённые или уже отгруженные позиции проходят отдельный разбор.
  6. Обработанные события подтверждаем только после сохранённого решения, а результат физического исполнения возвращаем по его самостоятельному контракту.
  7. Ответственный сверяет число открытых заказов и партий с обеих сторон; несовпадения остаются адресными задачами до подтверждения, а не исчезают при очистке Feed.

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

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

  • Способ восстановления истории и права чтения OMS проверяются для account клиента; гарантии бесконечного хранения не заявляются.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиVTEX OMS в области account/sellerДопуск определяется актуальным заказом, а не одним событием Feed.
SKU и вариантыКаталог VTEX и учёт клиентаSKU сохраняется в области seller/account и связывается с физическим товаром.
Остатки и резервЛогистический контур VTEX и выбранный складской учётWarehouse-проекция и резерв согласуются; несколько sellers не делят запас без правила.
СтатусыOMS и складFeed commit, start handling и физическая отгрузка — разные подтверждения.
ДокументыОтветственный учётный контурИнвойс/фискальные данные формируются установленным процессом, не генерируются из предположения.
ВозвратыОператор заказа и склад приёмкиОтмена до передачи и возврат после передачи имеют разный физический смысл.

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

  • Какие фильтры, статусы и действия доступны вашему seller/account?
  • Какие данные OMS принимает для частичной отгрузки и документов?
  • Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
Перед оценкой

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

  • Account VTEX и роль seller/marketplace, перечень нужных разрешений.
  • Связь логистических складов и физических площадок, карта SKU.
  • Пример разделённого заказа и правила возврата результата в OMS.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

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

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

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

Можно ли считать общий marketplace-заказ одним складским заданием?

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

Можно ли считать общий marketplace-заказ одним складским заданием?

Только после определения исполняющего продавца и его строк. Части других seller не должны попасть на ваш склад.

Что нужно знать о логистическом складе VTEX?

Нужны его связь с физической площадкой и правила доступности. Маршрут доставки и складское наличие согласуются совместно, а не только по названию склада.

Commit Feed означает, что склад отгрузил заказ?

Нет. Он подтверждает обработку записи очереди. Заказ сначала надёжно принимается в процесс, затем отдельно собирается и получает проверенный результат в OMS.

Можно использовать один поток для всех наших клиентов VTEX?

Каждый account и роль должны иметь явную область данных и доступа. Потребители одного appKey разделяют Feed; объединение клиентов требует контролируемой маршрутизации и изоляции.

После простоя Feed пуст. Значит новых заказов не было?

Такой вывод делать нельзя. Нужно сверить сохранённые задания и состояние заказов в OMS, проверить конфигурацию очереди и её срок хранения. Если источник событий уже не хранит нужный интервал, восстановление согласуется с владельцем заказа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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