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

Skirbo +
Prom.ua

Предлагаем начать с допуска оплаченного заказа к сборке, общей карты заказов Prom/CRM и возврата подтверждённого отправления. Состав полей и права API проверим до разработки автоматической записи.

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

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

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

ОперацияНаправлениеСостав и готовность
Заказ компании и допуск к сборкеProm.ua → SkirboНужна проверка

Внешний заказ и строки; источник продажи и статус оплаты сохраняются отдельно.

Товар, вариант и наличиеКаталог компании ↔ SkirboНужна проверка

Карта идентификаторов и SKU; точные поля чтения/записи количества ещё надо подтвердить.

Этап исполнения и номер отправленияSkirbo → Prom.uaНужна проверка

Только разрешённый переход и принятый способ записи ЭН; операторский ввод остаётся явным до проверки API.

Отмена и возвратProm.ua/продавец ↔ складНужна проверка

Отмена резерва, физическая приёмка и финансовый возврат не объединяются в одну операцию.

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

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

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

Prom.ua: кабинет компании и её магазин в украинском торговом контуре. Рассматриваются заказы маркетплейса и сайта этой же компании, а Пром-оплата — отдельный способ расчёта со своими правилами. Satu.kz и другие порталы не входят в этот контракт.

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

Предметно прочитан операторский процесс кабинета Prom.ua. Возможность автоматического API-обмена находится на проверке: описание видно в поисковой выдаче официального справочника, однако читаемое тело спецификации, методы и права не получены. До их проверки маршрут передачи согласуется с продавцом и фиксируется в журнале.

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

  1. Получают заказ выбранной компании через подтверждённый интерфейс либо согласованную передачу менеджера. Сохраняют внешние идентификаторы, строки, источник продажи, оплату, доставку и принятую редакцию.
  2. Сравнивают внешний заказ с уже пришедшим из CRM: одна покупка должна иметь общий ключ. Находят клиента Skirbo и нужный физический склад.
  3. Товары и варианты связывают с SKU и единицами хранения; неизвестные или спорные строки оставляют на разборе. Для Пром-оплаты проверяют оплату и наличие товара.
  4. Склад резервирует и собирает только допущенный состав. Недостачу или просьбу изменить оплаченный заказ передают менеджеру, не переписывая состав на стороне склада.
  5. Выбранный отправитель оформляет одну ЭН. Номер связывают с исходным заказом разрешённым способом и сохраняют результат в журнале обмена.
  6. Перепроверяют номер в кабинете, физически передают посылку перевозчику и отдельно фиксируют факт выдачи со склада.
  7. Если ответ потерян или состояние заказа изменилось, перед повтором сверяют заказ и отправление. Несовпадение оплаты/состава блокирует дальнейшую выдачу, а не создаёт второе задание.

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

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

Оплаченный заказ Prom на сборку

Задача: Передать складу разрешённый состав и подтвердить реальное отправление.

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

  1. Получают заказ выбранной компании через подтверждённый интерфейс либо согласованную передачу менеджера. Сохраняют внешние идентификаторы, строки, источник продажи, оплату, доставку и принятую редакцию.
  2. Сравнивают внешний заказ с уже пришедшим из CRM: одна покупка должна иметь общий ключ. Находят клиента Skirbo и нужный физический склад.
  3. Товары и варианты связывают с SKU и единицами хранения; неизвестные или спорные строки оставляют на разборе. Для Пром-оплаты проверяют оплату и наличие товара.
  4. Склад резервирует и собирает только допущенный состав. Недостачу или просьбу изменить оплаченный заказ передают менеджеру, не переписывая состав на стороне склада.
  5. Выбранный отправитель оформляет одну ЭН. Номер связывают с исходным заказом разрешённым способом и сохраняют результат в журнале обмена.
  6. Перепроверяют номер в кабинете, физически передают посылку перевозчику и отдельно фиксируют факт выдачи со склада.
  7. Если ответ потерян или состояние заказа изменилось, перед повтором сверяют заказ и отправление. Несовпадение оплаты/состава блокирует дальнейшую выдачу, а не создаёт второе задание.

Результат: Склад исполняет один подтверждённый заказ, а отправление прослеживается до исходной покупки.

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

  • Средства у банка-партнёра и выплата продавцу — разные состояния.
  • Неподтверждённый API-метод записи ЭН заменяется только явно согласованным операторским шагом.

Маркетплейс, сайт и CRM без дублей

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

Когда начинается: Одна покупка поступила напрямую из Prom и через текущую CRM.

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

Результат: Одна продажа резервирует и списывает товар один раз.

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

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

Каталог и доступное количество

Задача: Согласовать исходную товарную задачу без предположений о полях API.

Когда начинается: Компания хочет связать товары кабинета с единым складским запасом.

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

Результат: Есть принятая карта и измеримый первый участок товарного обмена.

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

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

Снятие резерва, отмена и физический возврат

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

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

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

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

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

  • Живые финансовые операции не используются для редакционной проверки API.

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

ДанныеОтветственный источникПравило обмена
Заказ и источник продажиКабинет компании Prom / согласованная CRMЕдинственный маршрут создания и изменения заказа.
Товар и вариантКаталог компании + карта складаУстойчивые внешние ID связываются с tenant/SKU, а не только названием.
Физический запас и резервSkirbo для выбранного складаПубликуемое количество рассчитывает один утверждённый контур.
Оплата и выплатаProm/платёжная сторона и продавецСклад не выводит денежный статус из своей сборки.
ЭН и передачаОдин отправитель; склад подтверждает выдачуПовтор результата не создаёт новую посылку.
Отмена и возвратМенеджер — разрешение; склад — приёмкаФинансовое действие проверяется отдельно от движения товара.

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

  • Описание API видно в выдаче, но полный контракт и права не проверены: где получить читаемую действующую спецификацию компании?
  • Какой действующий допуск Public API и какие права есть у компании?
  • Какие схемы читают изменения заказов и записывают статусы, ЭН и количество?
  • Каков общий внешний ключ заказа Prom и вашей CRM?
  • Какие переходы Пром-оплаты разрешены автоматизации и кто подтверждает денежный результат?
  • Кто резервирует товар и как отмена отражается в доступном количестве?
Перед оценкой

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

  • Подтвердить компанию и доступ к Public API.
  • Описать источники заказов и существующие CRM-подключения.
  • Подготовить карту product ID и SKU.
  • Обезличенные заказы сайта и маркетплейса с исходными ID и их связью с CRM.
  • Подтверждение доступности Public API именно этой компании и текущий способ выдачи/ротации ключа.
  • Пример оплаченного заказа с Пром-оплатой, допустимые действия и ответственный за отмену.
  • Правила владения количеством, вариантами, резервом и валютой заказа.
Границы сценария

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

  • Официальный справочник содержит условия ограниченного доступа; фактические права нужно подтвердить.
  • Общие API-понятия Prom.ua нельзя автоматически переносить на другие порталы.
  • Изменение статуса заказа не заменяет отдельное подтверждение доставки перевозчиком.
  • Описание API видно в поисковой выдаче, но тело спецификации и права компании не проверены; фрагмент сохранён только как исследовательская навигация.
  • Не заявлены endpoint статусов/отмены/ЭН, webhook, лимиты или гарантии повторов, которые не были прочитаны.
  • Изменение оплаченного заказа с Пром-оплатой имеет специальные ограничения.
  • Отмена Пром-оплаты может иметь финансовые последствия, поэтому не выводится автоматически из складского исключения.
  • Украинские документы, деньги и доставка рассматриваются по договору компании; правила РФ не переносятся.
Стоимость и запуск

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

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

Подготовьте один оплаченный заказ Prom.ua, его запись в вашей CRM и карту товарных ID — по ним согласуем единый маршрут на склад и безопасные обратные статусы.

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

Можно оставить текущую CRM между Prom и складом?

Да, обсудим один маршрут и одного владельца записи. Нельзя одновременно импортировать ту же покупку из Prom и CRM без общего внешнего ключа.

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

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

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

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

Оплачено означает, что деньги уже на счёте продавца?

Нет. В Пром-оплате есть отдельный статус выплаты продавцу. Для допуска к отгрузке согласуем бизнес-правило, сохраняя оба состояния.

Можно автоматически отменять заказ при ошибке сборки?

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

Уже есть API, значит подключение готово?

Нет. Для этой ревизии получен только поисковый фрагмент API. Нужны прочитанная спецификация, доступ компании, проверенные методы и приёмка адаптера Skirbo. Операторские процессы подтверждены отдельными официальными справками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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