Обсудить задачу
Уведомления

Skirbo +
Altcraft Platform

Рассмотрим передачу подтверждённых этапов из Skirbo в Market и коммуникационные сценарии Altcraft. Для каждого события выберем один способ запуска сообщения, сохраним связь с конкретным заказом и отдельно проверим подписку, повтор и результат канала.

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

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

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

ОперацияНаправлениеСостав и готовность
Подтверждённый этапWMS / Skirbo → адаптер AltcraftОбсудим в составе подключения

Зафиксировать продавца, заказ, строки, версию и владельца факта; передать только необходимые поля и безопасную ссылку.

Заказ и позиции MarketАдаптер → Market AltcraftОбсудим в составе подключения

Сопоставить точку контакта, профиль, product/SKU и external_id строк; проверять результат каждого заказа, сохраняя склад источником физического состояния.

Уведомление по событиюАдаптер / Market → выбранный триггер AltcraftОбсудим в составе подключения

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

Корректировка и возвратWMS / учёт → Market и ответственному за коммуникациюОбсудим в составе подключения

Отдельно отражать отменённые или принятые обратно строки и подтверждение денег; ещё не выполненные сообщения проверять на актуальность.

Повтор и сверкаАдаптер ↔ AltcraftОбсудим в составе подключения

Хранить неизменяемое событие и попытки; защищать API-триггер устойчивым Request-ID, а историю Market восстанавливать с контролем запуска и проверкой каждой записи.

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

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

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

Для продавца и фулфилмента, которым нужны точные данные об исполнении заказа в клиентских коммуникациях. Altcraft Platform рассматривается как платформа профилей, Market и рассылок; WMS сохраняет ответственность за товар, резерв, отгрузку и приёмку возврата. Финансовый возврат и изменение баллов не выполняются отправкой события. Российский сценарий не подтверждает доступность конкретного канала или правила обработки данных в другой стране.

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

Предлагается обмен через API Altcraft: данные заказа и позиций — в Market, сообщение — через согласованный триггер Market либо отдельный API call trigger. Текущий импорт поддерживает skip_triggers для управляемого восстановления; API call trigger принимает контент сообщения и срок актуальности. Маршрут, авторизация, подписка на ресурс и доступ проекта должны пройти отдельную приёмку.

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

  1. Сохранить неизменяемое событие: продавец, заказ, версия, время, подтверждённый этап и необходимые строки. Резерв, остаток и физическую операцию ведёт WMS.
  2. Сопоставить заказ с профилем в нужной базе Altcraft, каналом продаж и точкой контакта. Для каждой строки проверить external_id и выбор product либо SKU.
  3. Получить разрешение на выбранное сообщение и конкретную подписку ресурса. Передавать только нужные для текста данные; не менять status подписки при обновлении заказа.
  4. Записать данные Market и проверить общий ответ и результат каждого external_id. Для отдельного API-триггера использовать согласованный режим импорта без запуска триггеров; при маршруте Market отдельный запуск того же сообщения исключить.
  5. Сформировать контент именно текущего заказа, проверить ссылку, строки и сумму. Не выбирать без проверки последний заказ профиля: другой заказ мог появиться между импортом и отправкой.
  6. Запустить единственный утверждённый сценарий. Для API call trigger сохранить Request-ID неизменяемого запроса и согласованный expiration; записать ответ отдельно от результата доставки.
  7. Сверить результат запуска и наблюдаемый статус сообщения по согласованному контракту отчёта или обратного события. Поддержка должна видеть событие, адресата, попытку и причину отсутствия подтверждения.
  8. При тайм-ауте проверять прежний результат и условия повтора. При расхождении ID, неподходящей подписке или конфликте версий остановить коммуникацию и передать запись ответственному; складской факт не откатывать по ошибке письма.

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

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

Подтверждённый этап заказа запускает точное сообщение

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

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

  1. Сохранить неизменяемое событие: продавец, заказ, версия, время, подтверждённый этап и необходимые строки. Резерв, остаток и физическую операцию ведёт WMS.
  2. Сопоставить заказ с профилем в нужной базе Altcraft, каналом продаж и точкой контакта. Для каждой строки проверить external_id и выбор product либо SKU.
  3. Получить разрешение на выбранное сообщение и конкретную подписку ресурса. Передавать только нужные для текста данные; не менять status подписки при обновлении заказа.
  4. Записать данные Market и проверить общий ответ и результат каждого external_id. Для отдельного API-триггера использовать согласованный режим импорта без запуска триггеров; при маршруте Market отдельный запуск того же сообщения исключить.
  5. Сформировать контент именно текущего заказа, проверить ссылку, строки и сумму. Не выбирать без проверки последний заказ профиля: другой заказ мог появиться между импортом и отправкой.
  6. Запустить единственный утверждённый сценарий. Для API call trigger сохранить Request-ID неизменяемого запроса и согласованный expiration; записать ответ отдельно от результата доставки.
  7. Сверить результат запуска и наблюдаемый статус сообщения по согласованному контракту отчёта или обратного события. Поддержка должна видеть событие, адресата, попытку и причину отсутствия подтверждения.
  8. При тайм-ауте проверять прежний результат и условия повтора. При расхождении ID, неподходящей подписке или конфликте версий остановить коммуникацию и передать запись ответственному; складской факт не откатывать по ошибке письма.

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

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

  • Общий error=0 не закрывает обработку пачки, если отдельная запись не принята.
  • Повтор события не должен повторно менять подписку или запускать второй маршрут уведомления.

Частичная отмена и возврат позиций

Задача: Сохранить точность строк заказа и не сообщить о деньгах раньше подтверждения учёта.

Когда начинается: Продавец подтвердил отмену строки либо склад принял обратно конкретные товары.

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

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

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

  • Позднее старое событие не возвращает строку из отменённой в отгруженную без решения владельца заказа.
  • Смена статуса Market не запускает физическую приёмку или платёж.

Восстановление истории без повторной рассылки

Задача: Закрыть пропуск обмена и сохранить действующие отписки.

Когда начинается: После сбоя обнаружены неподтверждённые или пропущенные события.

  1. Сверить журнал событий с текущим состоянием WMS и историей принятых попыток. Разделить восстановление данных и новые сообщения, которые ещё нужны клиенту.
  2. Для исторического импорта Market использовать skip_triggers=true по текущему контракту, проверять каждый заказ и не присваивать status=subscribed профилю. Старые сообщения не воспроизводить автоматически.
  3. Для неизвестного результата API-триггера учитывать срок дедупликации, Request-ID и прежний токен; ротация ключа или истечение суток не являются разрешением слепо повторить вызов.
  4. После сверки владелец коммуникаций разрешает только актуальные сообщения. Они получают отдельное основание, срок действия и связь с исходным событием; остальные записи закрываются как восстановленные без отправки.

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

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

  • Успешная защита от дубля API-триггера не подтверждает такую же защиту Market.
  • Отписки, жалобы и недействительные адреса не сбрасываются историческим импортом.

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

ДанныеОтветственный источникПравило обмена
Заказ, резерв и физический этапПродавец / WMSТолько подтверждённое действие владельца меняет складское состояние; коммуникация получает его снимок.
Товар, вариант и строка заказаКаталог продавца / владелец заказаProduct, SKU и строка имеют разные идентификаторы; переименование не создаёт новое соответствие автоматически.
Профиль, контакт и согласиеCRM продавца / владелец клиентских данныхОпределяет устойчивую личность, назначение сообщения, минимальные данные и законное основание по конкретной стране.
База, ресурс и подпискаВладелец аккаунта AltcraftСопоставляет профиль с нужной подпиской и защищает отписки от непреднамеренной перезаписи.
Шаблон, sender и триггерВладелец коммуникаций AltcraftУтверждает текст, точный заказ, срок актуальности и единственный путь запуска.
Событие, попытки и расхожденияАдаптер интеграции / ответственный за обменСохраняет корреляцию, версии, результат каждого запроса и решение о допустимом повторе.
Возврат денег и баллыУчёт продавца / владелец программы лояльностиПередаёт подтверждённый финансовый факт отдельно; статус строки и письмо не выполняют эту операцию.

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

  • Какие база профилей, канал продаж и точка контакта относятся к каждому продавцу и как сопоставляются заказы и строки?
  • Какое подтверждённое событие запускает сообщение и кто отвечает за его версию, отмену и минимальный состав данных?
  • Используется триггер Market или API call trigger; как исключается второй запуск и выбор другого последнего заказа?
  • Как проверяются ресурс, подписка и основание сообщения без перезаписи отписки?
  • Какие гарантии повторов у методов Market и как учитываются срок дедупликации и смена токена API-триггера?
  • Как сверяется результат сообщения, останавливается устаревшая очередь и отражается возврат части количества?
Перед оценкой

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

  • Аккаунт и актуальная версия Altcraft, адрес API, разрешения токена, доступ к Market и выбранному триггеру; секреты хранит администратор интеграции.
  • Карта продавец → база профилей → канал продаж → точка контакта, а также сопоставление заказа, строки, продукта и SKU без склейки по названию.
  • Определённый владелец подтверждённого события, версия порядка его применения и минимальный состав персональных данных.
  • Проверенная подписка на нужный ресурс и канал, подтверждённое основание сообщения, утверждённый sender и шаблон; статус подписки не изменяется обычным событием заказа.
  • Один путь запуска сообщения, отдельный режим исторического импорта, сроки актуальности и журнал event → попытка → ответ → наблюдаемый результат канала.
  • Приёмка двух одновременных заказов одного профиля, частичного возврата, повтора после тайм-аута, смены токена и восстановления событий после срока дедупликации.
Границы сценария

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

  • Успех импорта Market или запуска триггера не доказывает доставку сообщения и не меняет физический результат складской операции.
  • Пример шаблона с последним заказом профиля может выбрать другой заказ при параллельных покупках. Для уведомления нужна явная связь с событием и проверенный снимок данных.
  • В прочитанном списке дедупликации есть запуск API-триггера, но нет Market orders/import и смены статуса строки. Гарантию нельзя автоматически распространить на эти методы.
  • Срок дедупликации по умолчанию ограничен одним днём, а ключ связан с токеном. Длительное восстановление и ротация токена требуют собственного журнала и сверки.
  • expiration удаляет просроченное сообщение из очереди, но до срока оно может быть отправлено. Параметр не отзывает доставленное письмо и не доказывает возможность адресной отмены произвольного сообщения.
  • Наличие email или телефона в профиле не заменяет подходящую подписку и разрешение. Передача status=subscribed без отдельного основания может затереть отписку.
  • Уведомление об отмене или возврате строки не подтверждает возврат денег; текст и состояние каждой позиции определяются подтверждёнными действиями их владельцев.
  • Каналы, лимиты, размещение данных и договор проверяются для конкретного аккаунта и страны; наличие документации не означает готовый коннектор Skirbo.
Стоимость и запуск

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

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

Для оценки подготовьте обезличенный заказ с двумя вариантами товара, подтверждённое событие и частичный возврат, карту профиля/ресурса/точки контакта, выбранный маршрут сообщения и ожидаемое поведение после тайм-аута.

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

Можно ли взять последний заказ профиля для письма?

Только если такая выборка проверена для вашего сценария. При двух заказах подряд она может выбрать другой заказ; надёжнее связать контент с конкретным событием и проверить параллельные покупки.

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

Импорт Market может запустить настроенный триггер, а отдельный API call trigger создаёт ещё одно действие. Для одного уведомления маршрут выбирают заранее; при отдельном запуске импорт согласуют без триггеров.

Product и SKU — одно и то же?

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

Request-ID защищает любой импорт от дубля?

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

Нужно ли ставить subscribed при каждом заказе?

Нет. Поле status перезаписывает состояние подписки. Обычное событие заказа не должно отменять отписку; основание и подходящий ресурс проверяются отдельно.

Что отправлять при возврате части заказа?

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

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

Разделить историю и коммуникацию: импортировать нужные данные Market с skip_triggers=true, сверить каждую запись и затем отдельно решить, какие сообщения ещё актуальны.

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

Изучаем возможность. Описан предлагаемый процесс обмена; готовый коннектор Skirbo, проведённый пилот и приёмка на заказах клиента не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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