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

Skirbo +
Square Online

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

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

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

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

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

Согласовать фильтр происхождения, merchant и location; исключить уже исполненные POS-продажи.

Товарный вариант заказаSquare → SkirboОбсудим в составе подключения

Сопоставить товарные вариации со складским SKU и выделить физические позиции.

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

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

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

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

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

Square Online рассматриваем как онлайн-источник внутри экосистемы Square. Общий Orders API может содержать кассовые продажи и заказы других приложений, поэтому задача склада — выделить нужный онлайн-поток, location и физический fulfillment.

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

ORDERS_READ указан для прочитанных событий; остальные scopes, OAuth и country/account eligibility проверяются по текущему контракту. Location не заменяет tenant/merchant-изоляцию.

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

  1. Читаем актуальный Order и проверяем источник, location, fulfillment и коммерческий допуск. Заказ POS или другого приложения не принимается в онлайн-поток только по факту наличия в API.
  2. Выделяем физические строки и связываем catalog variation с SKU клиента. Для ad hoc строки нет доказанного складского кода, поэтому её передаём на ручное сопоставление.
  3. Сопоставляем location с допустимой физической площадкой и типом исполнения: доставка, отправка или выдача. Модификатор блюда/товара не превращается автоматически в отдельный складской вариант.
  4. Skirbo резервирует и комплектует допущенные позиции. Для самовывоза готовность и фактическая выдача фиксируются раздельно; для отправки сохраняется передача перевозчику.
  5. Возвращаем фактический результат в разрешённый fulfillment-контракт после его проверки, сохраняя связь с Order и строками. Финансовое завершение не вызывается автоматически из факта упаковки.
  6. Читаем состояние Order/fulfillment и сверяем влияние на Square inventory. Один физический расход учитывается один раз, даже если завершение заказа меняет inventory автоматически.
  7. Повторный event запускает сверку, а не новую сборку. Неясный источник, отсутствующая catalog variation, отмена или refund без физического возврата выделяются в очередь разбора.

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

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

Только онлайн-заказ нужной location на склад

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

Когда начинается: Событие или сверка обнаружили заказ в подключённом аккаунте Square.

  1. Читаем актуальный Order и проверяем источник, location, fulfillment и коммерческий допуск. Заказ POS или другого приложения не принимается в онлайн-поток только по факту наличия в API.
  2. Выделяем физические строки и связываем catalog variation с SKU клиента. Для ad hoc строки нет доказанного складского кода, поэтому её передаём на ручное сопоставление.
  3. Сопоставляем location с допустимой физической площадкой и типом исполнения: доставка, отправка или выдача. Модификатор блюда/товара не превращается автоматически в отдельный складской вариант.
  4. Skirbo резервирует и комплектует допущенные позиции. Для самовывоза готовность и фактическая выдача фиксируются раздельно; для отправки сохраняется передача перевозчику.
  5. Возвращаем фактический результат в разрешённый fulfillment-контракт после его проверки, сохраняя связь с Order и строками. Финансовое завершение не вызывается автоматически из факта упаковки.
  6. Читаем состояние Order/fulfillment и сверяем влияние на Square inventory. Один физический расход учитывается один раз, даже если завершение заказа меняет inventory автоматически.
  7. Повторный event запускает сверку, а не новую сборку. Неясный источник, отсутствующая catalog variation, отмена или refund без физического возврата выделяются в очередь разбора.

Результат: Склад обслуживает именно выбранный онлайн-поток и не дублирует кассовые операции.

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

  • Страна и договорная доступность Square для организации проверяются отдельно; наличие документации не подтверждает обслуживание РФ.

Самовывоз и отправка

Задача: Сохранить физический смысл разных fulfillment.

Когда начинается: Заказ требует выдачи на location или передачи перевозчику.

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

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

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

  • Нельзя менять fulfillment произвольным переходом без проверки контракта.

Refund и запас после осмотра

Задача: Не допустить автоматической продажи ещё не вернувшегося товара.

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

  1. Сверяем, какое изменение inventory уже сделал Square для каталожной строки.
  2. Склад принимает товар и фиксирует годность; до осмотра он не должен стать физически свободным в Skirbo.
  3. Согласованная модель устраняет расхождение коммерческого inventory и физического остатка, сохраняя отдельное финансовое подтверждение.

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

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

  • Корректировку нельзя выполнять дважды или считать refund доказательством возврата.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиSquare Order выбранного источникаAccount-wide видимость фильтруется до складского допуска.
SKU и вариантыCatalog variation и карта складаAd hoc и modifiers требуют отдельного решения, названия недостаточно.
Остатки и резервSquare inventory и физический учёт по согласованной моделиПобочные эффекты completion/refund учитываются до внешней корректировки.
СтатусыOrder/fulfillment и складОплата, готовность, выдача и отправка различаются.
ДокументыSquare/учёт продавца в своей финансовой областиЛокальные документы и кассовые требования проверяются по стране.
ВозвратыПродавец и склад осмотраRefund не доказывает физическую приёмку; годный запас появляется после осмотра.

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

  • Как доказуемо выделить Square Online в аккаунте и разрешено ли обслуживание организации?
  • Какие transitions и inventory effects применимы к типам fulfillment клиента?
  • Какие клиенты фулфилмента и физические склады входят в первый запуск и кто подтверждает обратный результат?
  • Какой тип и набор fulfillment реально возвращает Square Online клиента и доступен ли нужный delivery-контракт приложению?
Перед оценкой

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

  • Merchant, location и страна обслуживания Square; приложение с согласованными правами.
  • Пример заказа именно Square Online и карта товарных вариаций.
  • Правила допуска после оплаты, выдачи и доставки.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

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

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

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

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

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

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

Фильтры источника и состояния должны исключать уже исполненные продажи POS. Проверим это на примерах онлайн-заказа и кассового заказа одной локации.

Можно ли объединить выдачу и доставку одним статусом?

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

Все заказы из Orders API относятся к Square Online?

Нет. В API доступны и другие источники подключённого аккаунта, включая POS. Нужны проверяемые фильтры источника и location до передачи в склад.

Как обрабатывать строку без catalog ID?

Это может быть ad hoc позиция. До физической сборки оператор должен однозначно сопоставить её со SKU; одно название и цена не дают надёжного ключа.

Если у заказа несколько fulfillment, можно ли оставить только первое?

Нет: нужно учесть все существующие исполнения и связать их с физическими партиями. Ограничение API на создание fulfillment не означает, что в прочитанном заказе Square Online всегда один элемент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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