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

Skirbo +
Squarespace Commerce

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

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

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

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

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

Отделить физические товары от услуг, цифровых продуктов и подарочных карт.

Наличие по вариантамSkirbo → SquarespaceОбсудим в составе подключения

Передавать согласованный доступный запас по variant, сохраняя выбранную стратегию резерва.

Исполнение отправленияSkirbo → SquarespaceНужна проверка

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

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

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

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

Squarespace Commerce — торговые функции сайта, включая физические товары и повторяющиеся покупки. Для фулфилмента важно отделить конкретный заказ очередной поставки от самой подписки, а физические строки — от услуг, загрузок и подарочных карт.

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

Прочитаны правила API key/OAuth и отдельные права Orders/Inventory на чтение и запись. Webhook-подписки требуют OAuth. Фактические права приложения, допустимый план и область сайта проверяются до запуска; секреты разделяются по сайту/клиенту.

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

  1. Получаем конкретный заказ и сохраняем его идентификатор вместе с сайтом; идентификатор подписки не используется как единственный ключ отгрузки.
  2. Проверяем допуск по оплате и коммерческому правилу, затем выделяем физические строки. Услуги, скачиваемый контент и подарочные карты не включаем в подбор.
  3. Сопоставляем вариант с SKU клиента и складом, сохраняем исходную строку, количество и период поставки, если он представлен в контракте заказа.
  4. Skirbo резервирует и собирает только разрешённый объём этого заказа. Отсутствие товара передаём продавцу, не переносим автоматически в следующую подписочную поставку.
  5. Фактические количества передаём ответственному за заказ. Метод Fulfill order вызывается лишь после согласованного полного исполнения; частичную партию фиксируем отдельно и не закрываем весь заказ преждевременно.
  6. Подтверждаем отражение исполнения именно у текущего заказа. Финансовая транзакция сама по себе не является квитанцией о приёме складского результата.
  7. При повторном webhook читаем актуальный заказ и сверяем ключ обработки. Пропущенный период, изменение состава подписки или отмена начатой сборки требуют решения продавца.

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

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

Физическая поставка по подписочному заказу

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

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

  1. Получаем конкретный заказ и сохраняем его идентификатор вместе с сайтом; идентификатор подписки не используется как единственный ключ отгрузки.
  2. Проверяем допуск по оплате и коммерческому правилу, затем выделяем физические строки. Услуги, скачиваемый контент и подарочные карты не включаем в подбор.
  3. Сопоставляем вариант с SKU клиента и складом, сохраняем исходную строку, количество и период поставки, если он представлен в контракте заказа.
  4. Skirbo резервирует и собирает только разрешённый объём этого заказа. Отсутствие товара передаём продавцу, не переносим автоматически в следующую подписочную поставку.
  5. Фактические количества передаём ответственному за заказ. Метод Fulfill order вызывается лишь после согласованного полного исполнения; частичную партию фиксируем отдельно и не закрываем весь заказ преждевременно.
  6. Подтверждаем отражение исполнения именно у текущего заказа. Финансовая транзакция сама по себе не является квитанцией о приёме складского результата.
  7. При повторном webhook читаем актуальный заказ и сверяем ключ обработки. Пропущенный период, изменение состава подписки или отмена начатой сборки требуют решения продавца.

Результат: Каждая физическая поставка имеет собственное исполнение и не смешивается с жизненным циклом подписки.

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

  • Гарантии доставки webhook и правила отмены подписочной поставки нужно проверить отдельно.

Наличие варианта при нескольких складах

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

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

  1. Связываем variant с SKU владельца и разрешёнными площадками; задаём, какие склады обслуживают сайт.
  2. Выбираем единую модель резерва и согласуем установку количества либо increment/decrement по Inventory API; ключ одной корректировки сохраняем для безопасного повтора.
  3. После записи читаем состояние и сверяем результат; возвращённый товар не увеличивает доступность до осмотра.

Результат: Доступность не удваивается из-за нескольких площадок.

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

  • Конкретные операции Inventory прочитаны; Idempotency-Key не устраняет конфликт двух независимых владельцев запаса.

Возврат товара и финансовая операция

Задача: Не считать возврат денег физическим возвращением товара.

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

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

Результат: Финансовая и физическая стороны возврата согласованы.

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

  • Наличие Transactions API не подтверждает автоматический возврат денег по складскому событию.

Одна посылка отправлена, вторая ещё комплектуется

Задача: Сохранить частичный физический результат без ложного завершения всего заказа.

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

  1. Берём идентификатор конкретного заказа Squarespace, а не всей подписки, и связываем обе партии с исходными физическими строками, вариантами и количеством.
  2. Ответственный подтверждает, какая часть выдана. Склад сохраняет время фактической передачи, отправление и недостающий остаток заказа; недостача остаётся назначенному владельцу.
  3. Первую партию фиксируем в журнале исполнения проекта. Не используем Fulfill order как подтверждение одной строки: он меняет состояние всего заказа.
  4. Продавец согласует ожидание второй партии либо изменение коммерческого решения. Отмена уже переданной посылки не возвращает товар на полку.
  5. После завершения всех разрешённых физических строк передаём сведения об отправлениях и отдельно согласованный параметр уведомления покупателя.
  6. После ответа перечитываем заказ и проверяем состояние и отправления. Потерянный ответ сначала разрешаем сверкой, чтобы не продублировать письмо или результат.
  7. Если во время сборки заказ отменён, возвращён платёж или изменился состав, автоматическое закрытие приостанавливаем. Менеджер сопоставляет коммерческий и физический результат и фиксирует дальнейшее действие.

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

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

  • Сценарий частичных партий относится к проектному журналу Skirbo и не обещает построчную запись fulfillment в Squarespace.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиSquarespace CommerceКаждый разовый/подписочный заказ является отдельным объектом исполнения.
SKU и вариантыProducts и карта складаФизический variant сопоставляется отдельно от нефизических видов товара.
Остатки и резервSkirbo и согласованная Inventory-проекцияВладелец резерва один; установка количества и дельта выбираются явно, ключ повтора сохраняется.
СтатусыCommerce и складСобытие создания, оплата и исполнение различаются.
ДокументыФинансовый/учётный контурTransactions не заменяет складской факт или локальные юридические документы.
ВозвратыПродавец и складРазрешение возврата, приёмка, годность и деньги имеют отдельные подтверждения.

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

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

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

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

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

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

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

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

Как обрабатывать повторную покупку по подписке?

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

Как обрабатывать повторную покупку по подписке?

Каждый подлежащий исполнению заказ связывается со своим внешним идентификатором. Подписка служит контекстом, но не основанием повторно собрать старый заказ.

Будут ли складскими заданиями услуги и цифровые товары?

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

Как свести остаток нескольких площадок к варианту сайта?

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

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

Только после физической приёмки и решения о годности. Финансовая транзакция и состояние товара могут возникать в разное время.

Две записи shipment означают два частичных исполнения?

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

Нужно ли менять Idempotency-Key при повторе корректировки остатка?

Для повтора того же результата сохраняют тот же ключ и исходный запрос. Новая бизнес-корректировка получает собственную идентичность; актуальные правила ключей нужно проверить при реализации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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