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

Skirbo +
Shift4Shop

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

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

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

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

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

Сохранить номер, физические строки и выбранные покупателем опции.

Доступность опции товараSkirbo → Shift4ShopНужна проверка

Проверить, какие сочетания опций имеют собственный учёт количества.

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

Согласовать запись результата и частичное исполнение заказа.

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

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

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

Shift4Shop, исторически 3dcart, рассматриваем как один продукт магазина с выбранной версией API. Документация на домене 3dcart не означает отдельный сервис каталога. Для склада важны товарные опции, физический SKU и частичные результаты массового обновления.

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

В сохранённой документации описаны PrivateKey, Token и SecureUrl, а также авторизация магазина приложению; OAuth-вариант требует своего контракта. Секреты не попадают в журнал, отзыв доступа прекращает новые действия.

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

  1. Получаем заказ разрешённым приложением и сохраняем магазин, выбранную версию, исходные строки и изменение заказа. SecureUrl и токен относятся к конкретному магазину.
  2. Для каждой позиции определяем, какая опция формирует отдельный складской SKU, а какая описывает услугу, например надпись. Правило подтверждается реальным каталогом клиента.
  3. Сопоставляем физический вариант с SKU владельца и складом, сохраняем остальные опции как инструкции оператору, если они согласованы.
  4. Skirbo резервирует, комплектует и фиксирует фактическую партию; при недопоставке сохраняет оставшийся объём исходной строки.
  5. Возвращаем отправление/исполнение только по проверенному контракту выбранной API-версии. При массовой записи разбираем результат каждого объекта, включая 206 Partial update.
  6. Принятые объекты связываем с партией и читаем контрольное состояние. Ошибка одного элемента не должна скрыться за общим ответом и не требует повторять уже принятые элементы.
  7. При повторе, смене опции после отбора или отзыве доступа изолируем исключение. Исправленные записи повторяются адресно; создание новой партии вместо исправления запрещается проектным правилом.

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

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

Заказ с товарными опциями и проверяемой обратной записью

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

Когда начинается: Заказ выбранного магазина и API-версии прошёл коммерческий допуск.

  1. Получаем заказ разрешённым приложением и сохраняем магазин, выбранную версию, исходные строки и изменение заказа. SecureUrl и токен относятся к конкретному магазину.
  2. Для каждой позиции определяем, какая опция формирует отдельный складской SKU, а какая описывает услугу, например надпись. Правило подтверждается реальным каталогом клиента.
  3. Сопоставляем физический вариант с SKU владельца и складом, сохраняем остальные опции как инструкции оператору, если они согласованы.
  4. Skirbo резервирует, комплектует и фиксирует фактическую партию; при недопоставке сохраняет оставшийся объём исходной строки.
  5. Возвращаем отправление/исполнение только по проверенному контракту выбранной API-версии. При массовой записи разбираем результат каждого объекта, включая 206 Partial update.
  6. Принятые объекты связываем с партией и читаем контрольное состояние. Ошибка одного элемента не должна скрыться за общим ответом и не требует повторять уже принятые элементы.
  7. При повторе, смене опции после отбора или отзыве доступа изолируем исключение. Исправленные записи повторяются адресно; создание новой партии вместо исправления запрещается проектным правилом.

Результат: Вариант и отправление сохраняют связь, а частичные ошибки видимы оператору.

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

  • Нужные shipment fields и допустимые статусы ещё проверяются по методу, а не по оглавлению API.

Опции, дополнительные услуги и складской код

Задача: Не превратить персонализацию в несуществующий вариант.

Когда начинается: Добавлен товар с размером, цветом и пользовательской надписью.

  1. Размер и цвет сопоставляются с физическим SKU, если они действительно разделяют запас.
  2. Надпись или иная услуга передаётся как согласованное задание оператору с проверкой содержимого, а не как новый остаток.
  3. Контрольный заказ подтверждает, что количество и вариант выбираются однозначно.

Результат: Каталог сохраняет разные значения коммерческих опций.

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

  • Схема advanced options конкретного магазина может требовать дополнительного контракта.

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

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

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

  1. Фиксируем перечень SKU/объектов и исходное намерение каждой записи.
  2. Разбираем индивидуальные результаты 206; принятые изменения отмечаем, непринятые классифицируем по причине.
  3. После исправления повторяем только нужные элементы и сверяем итоговое наличие.

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

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

  • Актуальные лимиты и версия метода проверяются, исторические числа не обещаются.

Возврат товара с персонализацией

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

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

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

Результат: Возврат сохраняет вариант, персонализацию и принятое решение по годности.

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

  • Методы и статусы возвратов конкретного магазина не установлены одним оглавлением API; автоматическая обратная запись остаётся вопросом проектирования.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиShift4Shop выбранного магазинаКоммерческий допуск и состав строки принадлежат магазину.
SKU и вариантыКаталог/SKU и карта опцийФизические варианты отделены от дополнительных услуг.
Остатки и резервНазначенный складской учётПубликуемое количество и резерв согласуются до массовой записи.
СтатусыМагазин и SkirboРезультат каждого элемента обновления проверяется отдельно.
ДокументыУчётный контур продавцаДокументы и оплата не выводятся из HTTP-кода обновления.
ВозвратыПродавец и склад осмотраПерсонализированный товар и возврат имеют отдельное решение по годности.

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

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

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

  • Версия API Shift4Shop и зарегистрированное приложение для нужного магазина.
  • Карта товарных опций и складских SKU, примеры комплектов.
  • Контракт обновления отправлений и правила повторной обработки заказа.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

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

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

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

Почему ссылка на документацию ведёт на 3dcart?

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

Почему ссылка на документацию ведёт на 3dcart?

Официальная документация Shift4Shop использует этот домен. В каталоге это один продукт с историческим названием, без отдельного дублирования 3dcart.

Как работать с гравировкой или другой неотдельной опцией?

Сохраним её как инструкцию к строке, если она не меняет физический SKU. Размер или отдельная комплектация требуют соответствия складской позиции.

3dcart и Shift4Shop — две интеграции?

В этой карточке это историческое и текущее имя одного продукта. Важно различать версии API и конкретный магазин, а не создавать дубли по бренду.

Что делать с HTTP 206?

Разобрать результаты каждого элемента, сохранить успешные и исправить непринятые. Повторять весь пакет без сверки опасно для количеств и отправлений.

Что делать, если вместо результата обновления пришёл 429?

Учесть Retry-After и запланировать ограниченный повтор. Для уже неопределённой записи сначала выясняют её результат; тайм-аут и 429 не дают права повторно создавать физическое отправление.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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