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

Skirbo +
Webflow Ecommerce

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

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

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

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

ОперацияНаправлениеСостав и готовность
Каталог ecommerce-вариантовWebflow → SkirboОбсудим в составе подключения

Различать product и SKU, сохраняя связь варианта с размером или комплектацией.

Заказ физических товаровWebflow → SkirboНужна проверка

Проверить контракт заказов и состояние, допускающее складское исполнение.

Доступность SKUSkirbo → WebflowНужна проверка

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

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

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

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

Webflow Ecommerce рассматриваем отдельно от обычных CMS-коллекций Webflow. Для продавца физических товаров первый проверяемый участок — связь ecommerce-продуктов и их SKU со складом; для заказов и наличия прочитаны отдельные методы, а доступ и правила применения проверяются для сайта клиента.

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

Чтение продуктов и заказов сайта использует Bearer и ecommerce:read; fulfill и изменение inventory требуют ecommerce:write. Права конкретного приложения и доступ плана проверяются отдельно; роль записи выдаётся только для согласованного процесса.

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

  1. Получаем продукты выбранного site_id разрешённой ролью чтения. Сохраняем исходный контекст сайта и положение страницы; соседние сайты одного владельца не объединяем автоматически.
  2. Для каждого продукта разбираем все возвращённые SKU. Следующую страницу запрашиваем по продуктам, а не по количеству уже разобранных вариантов.
  3. Сопоставляем стабильный SKU-идентификатор и вариант со складским SKU клиента; название и изображение служат проверке человеком, но не основным ключом.
  4. Оператор склада сверяет физический образец, единицу хранения и допустимый вариант. Неоднозначные и нефизические позиции исключаются из автоматического задания до решения владельца каталога.
  5. Возвращаем владельцу сайта протокол сопоставлений: принятые SKU, дубли, отсутствующие коды и товары, требующие уточнения. Запись в Webflow этим процессом не предполагается.
  6. Владелец каталога утверждает карту и контрольный заказ подтверждает, что по ней выбирается нужный товар. Сохраняем принятую редакцию карты.
  7. При неполной странице, удалённом SKU или изменении варианта не считаем выгрузку полной. Повторное чтение обновляет существующие связи; спорный SKU блокируется до сверки.

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

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

Справочник ecommerce-SKU для складского запуска

Задача: Принять полный набор физических вариантов без потери SKU на границах страниц.

Когда начинается: Владелец сайта разрешил обследование ecommerce-каталога перед подключением склада.

  1. Получаем продукты выбранного site_id разрешённой ролью чтения. Сохраняем исходный контекст сайта и положение страницы; соседние сайты одного владельца не объединяем автоматически.
  2. Для каждого продукта разбираем все возвращённые SKU. Следующую страницу запрашиваем по продуктам, а не по количеству уже разобранных вариантов.
  3. Сопоставляем стабильный SKU-идентификатор и вариант со складским SKU клиента; название и изображение служат проверке человеком, но не основным ключом.
  4. Оператор склада сверяет физический образец, единицу хранения и допустимый вариант. Неоднозначные и нефизические позиции исключаются из автоматического задания до решения владельца каталога.
  5. Возвращаем владельцу сайта протокол сопоставлений: принятые SKU, дубли, отсутствующие коды и товары, требующие уточнения. Запись в Webflow этим процессом не предполагается.
  6. Владелец каталога утверждает карту и контрольный заказ подтверждает, что по ней выбирается нужный товар. Сохраняем принятую редакцию карты.
  7. При неполной странице, удалённом SKU или изменении варианта не считаем выгрузку полной. Повторное чтение обновляет существующие связи; спорный SKU блокируется до сверки.

Результат: Подключение начинается с проверенной карты ecommerce-SKU, пригодной для физических заказов.

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

  • Чтение каталога не подтверждает метод получения заказа, резервирования или записи наличия.

Заказ физических товаров после проверки контрактов

Задача: Передать на склад только допущенные строки конкретного сайта.

Когда начинается: Подтверждённый интерфейс заказов или операторский процесс дал разрешённый заказ.

  1. Фиксируем заказ из отдельного метода списка заказов, его строки, оплату по согласованному правилу и сайт; право чтения проверяется в аккаунте клиента.
  2. Применяем утверждённую карту ecommerce-SKU, выбираем клиента и склад, затем резервируем и комплектуем.
  3. Результат строк и отправления возвращаем разрешённым способом и проверяем принятие; до проверки API допускается явно согласованный операторский шаг.

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

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

  • Не создаём задание из обычной CMS-записи или содержимого корзины.

Изменение варианта после начала продаж

Задача: Не разрушить связь старых заказов с физическим товаром.

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

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

Результат: История товара не теряется при редактировании витрины.

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

  • Удаление из каталога не доказывает отмену уже принятого заказа.

Наличие SKU после потерянного подтверждения

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

Когда начинается: Склад разрешил обновить доступность варианта, но ответ на запись не получен.

  1. В журнале проекта фиксируем сайт, коллекцию SKU, конкретный SKU, клиента, расчёт доступности и причину изменения. Физический остаток и уже выделенный резерв учитываются раздельно.
  2. Проверяем, кто одновременно меняет наличие при покупке. Владелец магазина утверждает режим finite и способ записи; infinite не означает безграничный запас на складе.
  3. Для абсолютного режима формируем согласованное значение quantity; для дельты сохраняем исходное значение, updateQuantity и единственный идентификатор задания адаптера.
  4. Передаём выбранную операцию разрешённой ролью. Она изменяет витринное наличие и сама по себе не является приёмкой, списанием или передачей коробки перевозчику.
  5. При тайм-ауте останавливаем слепой повтор дельты и проверяем текущее наличие через подтверждённое чтение либо кабинет; сверяем параллельные продажи и журнал проекта.
  6. Ответственный сопоставляет расчёт с фактом. После подтверждения сохраняем принятую версию; если причина расхождения не установлена, SKU остаётся в ручном разборе.
  7. При возврате сначала принимаем и осматриваем товар. Только разрешённая к продаже часть участвует в следующем расчёте; возврат денег сам не увеличивает запас.

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

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

  • Проектная защита от повторов не является заявлением встроенной идемпотентности Webflow.
  • Запись наличия требует отдельно согласованного владельца конкурентных изменений.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиWebflow Ecommerce для коммерческого заказаМетод чтения заказов подтверждён документацией; коммерческий допуск согласует продавец. CMS-элемент заказом не считается.
SKU и вариантыEcommerce-каталог и согласованная карта складаProduct и SKU различаются; вариант хранится по стабильному идентификатору.
Остатки и резервSkirbo физически, назначенный контур резерваМетод inventory различает установку количества и дельту; единого владельца резерва и правила конкурентной записи согласуют отдельно.
СтатусыМагазин и склад в своих областяхОплата, допуск, сборка и отгрузка не выводятся из наличия продукта.
ДокументыУчёт продавцаФинансовые и юридические документы не входят в прочитанный метод каталога.
ВозвратыПродавец и принимающий складВозврат связывается с историческим SKU и исходной строкой, даже если вариант удалён.

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

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

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

  • Идентификатор сайта Webflow, права Ecommerce API и обезличенный заказ.
  • Карта Webflow SKU и складских кодов, включая варианты одного продукта.
  • Подтверждённые методы заказов и наличия, владелец резерва.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
  • Страна продавца и договора, валюта магазина и заказа, налоги и правила платёжного провайдера проверяются для конкретного проекта; склад не подменяет коммерческую и юридическую проверку продавца.
Границы сценария

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

  • CMS-коллекция Webflow и ecommerce-SKU — разные объекты обмена.
  • Пагинация списка продуктов не должна приводить к потере или двойной обработке их вариантов.
  • Операции связи со Skirbo описаны как проектные; наличие API поставщика не подтверждает установленный коннектор.
  • Для продавца в России сначала проверяются допустимость обслуживания его организации, страна аккаунта и договорный доступ. Наличие международной документации не подтверждает доступность SaaS или лицензии в РФ. Для Казахстана и Узбекистана отдельно проверяются договор и местные документы; российские правила ЭДО, кассы и маркировки не переносятся.
  • Документированный fulfill не подтверждает построчное частичное исполнение. Физическую выдачу, общий статус заказа и уведомление покупателя согласуют раздельно.
Стоимость и запуск

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

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

Можно ли использовать обычную CMS-коллекцию как каталог склада?

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

Можно ли использовать обычную CMS-коллекцию как каталог склада?

Только после отдельного проектирования. Для магазина нужен устойчивый ecommerce-SKU; запись CMS сама по себе не содержит подтверждённую семантику заказа или остатка.

Как учитывать несколько размеров одного товара?

Создадим соответствие для каждого SKU-варианта. Остаток родительского продукта не должен заменять количество конкретного размера.

Изменение названия варианта должно изменить старый заказ?

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

Почему полный список продуктов ещё не означает полный каталог SKU?

Нужно разобрать все SKU внутри каждого продукта и корректно завершить обход страниц продуктов. Контроль проводится по обоим уровням и карте складских соответствий.

Можно ли закрыть весь заказ после выдачи одной из двух посылок?

Прочитанный Fulfill Order меняет состояние заказа целиком и не принимает количества строк. В предлагаемом процессе частичные партии сначала учитываются в складском журнале; момент общего закрытия согласует продавец.

Что делать после тайм-аута обновления наличия?

Сначала сверить текущее состояние и последние продажи. Особенно опасно повторить updateQuantity как новый запрос: это прибавление дельты, поэтому без проверки можно изменить запас второй раз.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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