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

Skirbo +
Elastic Path

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

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

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

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

ОперацияНаправлениеСостав и готовность
Заказ выбранной редакцииElastic Path → SkirboНужна проверка

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

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

Согласовать, какая сущность варианта или комплекта соответствует физическому SKU.

Исполнение и доступностьSkirbo → Elastic PathНужна проверка

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

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

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

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

Elastic Path — семейство продуктов, поэтому сначала фиксируем редакцию. Composable Commerce, Product Experience Manager и Self-Managed Commerce/Cortex имеют разные границы. Для склада предметный проект строится вокруг выбранного владельца заказа и физических компонентов товара.

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

Для Composable Commerce прочитаны GET заказа и PUT обновления: запись заказа требует client-credentials token с ролью Seller Admin. Редакцию, среду, область магазина и разрешения клиента нужно подтвердить отдельно; этот контракт не переносится на Self-Managed/Cortex.

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

  1. Фиксируем точное название продукта, версию/окружение и владельца заказа. Документ Cortex не используем как спецификацию Composable Commerce.
  2. Получаем разрешённый заказ по контракту этой редакции либо согласованной операторской передаче, сохраняя исходные строки и коммерческий состав.
  3. Связываем строку со складским SKU. Если проект продаёт комплект, продавец предоставляет утверждённую спецификацию физических компонентов и правило частичного исполнения.
  4. Skirbo резервирует компоненты на площадке клиента и фиксирует сборку. Наличие каталожного описания комплекта не даёт права автоматически выбрать замены.
  5. Возвращаем фактическое исполнение в владельца заказа, сохраняя связь коммерческой строки с физическими частями. PXM не используется как адрес обратной записи заказа только потому, что хранит описание товара.
  6. Проверяем принятое состояние заказа и, при необходимости, подтверждение ответственным оператором. Факт публикации каталога не является подтверждением приёма отгрузки.
  7. При неизвестной редакции, неоднозначном составе или нехватке компонента останавливаем затронутую строку. Изменения спецификации после начала сборки требуют согласования.

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

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

Заказ выбранной редакции с физическими компонентами

Задача: Не смешать контракт одной редакции и товарную модель другой.

Когда начинается: В подтверждённом commerce-продукте клиент допустил заказ к складскому исполнению.

  1. Фиксируем точное название продукта, версию/окружение и владельца заказа. Документ Cortex не используем как спецификацию Composable Commerce.
  2. Получаем разрешённый заказ по контракту этой редакции либо согласованной операторской передаче, сохраняя исходные строки и коммерческий состав.
  3. Связываем строку со складским SKU. Если проект продаёт комплект, продавец предоставляет утверждённую спецификацию физических компонентов и правило частичного исполнения.
  4. Skirbo резервирует компоненты на площадке клиента и фиксирует сборку. Наличие каталожного описания комплекта не даёт права автоматически выбрать замены.
  5. Возвращаем фактическое исполнение в владельца заказа, сохраняя связь коммерческой строки с физическими частями. PXM не используется как адрес обратной записи заказа только потому, что хранит описание товара.
  6. Проверяем принятое состояние заказа и, при необходимости, подтверждение ответственным оператором. Факт публикации каталога не является подтверждением приёма отгрузки.
  7. При неизвестной редакции, неоднозначном составе или нехватке компонента останавливаем затронутую строку. Изменения спецификации после начала сборки требуют согласования.

Результат: Проект имеет одну выбранную API-семью и проверяемую связь коммерческой строки с физическим товаром.

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

  • Поддержка комплектов в конкретной редакции не доказана одним обзором; сценарий применяется только после подтверждения модели проекта.

Каталог и наличие как разные потоки

Задача: Сохранить роли PXM и складского учёта.

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

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

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

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

  • Нельзя переносить поля inventory из другой редакции.

Смена редакции или окружения

Задача: Не потерять старые заказы при миграции.

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

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

Результат: Миграция не выдаёт старые идентификаторы за объекты новой системы.

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

  • Совпадение названий ресурсов не подтверждает совместимость схем.

Оплаченный заказ Composable Commerce без двойного списания

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

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

  1. Закрепляем product/environment/store и выбранный single-location либо multi-location контракт. Для нескольких площадок карта location → физический склад принадлежит владельцу учёта; неизвестное соответствие блокирует строку.
  2. Читаем заказ с items и сохраняем вход вместе с историческими SKU/компонентами. Коммерческий владелец подтверждает допуск; корзина или unpaid сами по себе не запускают физическую отгрузку.
  3. Отдельно фиксируем выделение в commerce и резерв склада. Интегратор согласует одну формулу публикации доступности с владельцем запаса, чтобы тот же оплаченный объём не вычитался второй раз.
  4. Склад собирает фактические компоненты и сохраняет партии, количество и отправление. Неполный комплект остаётся спорной строкой; общий fulfil не используется для сокрытия недовложения.
  5. Через разрешённый контракт возвращаем результат только после фактического этапа. Перед записью перечитываем заказ и проверяем совместимость нового состояния; потерянный ответ разрешаем чтением результата и журнала операций.
  6. При отмене до отгрузки отдельно снимаем физический резерв по подтверждённому решению. После отгрузки оформляем приёмку возвращённых компонентов и осмотр; бухгалтерия отдельно подтверждает возврат денег.
  7. Сверяем order/items, коммерческое allocated, физический резерв и подтверждённые партии. Расхождения количества, location или оплаты получает назначенный оператор до следующей попытки.

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

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

  • Семантика частичного исполнения и комплекта должна быть подтверждена контрактом проекта; прочитанный общий Update an Order её не устанавливает.
  • Смена редакции, среды или API inventory требует проверки открытых заказов перед возобновлением потока.

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

ДанныеОтветственный источникПравило обмена
Заказ и строкиВыбранный commerce-продуктРедакция фиксируется до выбора контрактов и маршрута результата.
SKU и вариантыPXM/каталог проекта и учёт клиентаТоварная публикация и физические компоненты разделяются.
Остатки и резервНазначенный складской учёт и reservation policyAPI запаса выбирается отдельно для нужной редакции.
СтатусыВладелец заказа и SkirboКаталожная публикация не является стадией исполнения.
ДокументыERP/учёт продавцаСостав документов не выводится из overview портала.
ВозвратыКоммерческий процесс и склад осмотраВозврат комплекта проверяется по фактически принятым компонентам.

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

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

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

  • Точный продукт Elastic Path, версия, окружение и соответствующая API-документация.
  • Карта вариантов, комплектов и их физических компонентов.
  • Владелец заказа и резерва, пример частичного исполнения комплекта.
  • Обезличенный контрольный пример с частичным исполнением, отменой и повторной передачей; ответственные за согласование расхождений.
Границы сценария

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

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

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

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

Какой продукт Elastic Path нужен для оценки?

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

Какой продукт Elastic Path нужен для оценки?

Нужно название редакции и адрес документации вашего окружения. Каталог, composable commerce и Self-Managed имеют разные границы и способы интеграции.

Как собирать комплект из нескольких компонентов?

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

Как сохранить незавершённые заказы при смене редакции?

Задаём новую область идентификаторов и явные соответствия. Старые заказы продолжаются по согласованному маршруту до сверки исполнения; совпавшее имя ресурса новой API-семьи не делает его тем же объектом.

Если PXM знает комплект, склад уже может его собрать?

Складу нужен утверждённый состав физических SKU, количества и правила замены/частичного исполнения. Каталожная публикация этих условий сама по себе не гарантирует.

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

Нет. В прочитанном контракте Composable Commerce отмена и refund разделены. В проекте бухгалтерия подтверждает денежный результат отдельно, а склад фиксирует снятие резерва либо фактическую приёмку после отгрузки.

Как избежать двойного вычитания уже выделенного товара?

Сначала согласуем, какая система владеет доступностью и как коммерческое allocated связано с физическим резервом. Затем сверяем один и тот же заказ и location в обеих системах; механическое вычитание всех резервов из уже уменьшенного Available не принимается как универсальная формула.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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