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

Skirbo +
Хорошоп

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

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

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

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

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

Сохранить заказ магазина, строки и отдельно dropshipping_details; схема экспорта проверяется до автоматизации.

SKU, вариант и упаковкаХорошоп ↔ карта соответствий SkirboОбсудим в составе подключения

Утвердить артикулы и коэффициент единицы; договориться о единственном владельце доступного остатка.

Сборка и накладнаяSkirbo → ХорошопОбсудим в составе подключения

Сверить состав и уже имеющуюся ЭН; передача номера через «Обновление заказов» документирована для Pro+, но endpoint, поля, права и повтор проверяются до реализации. Операторский путь доступен с Standard.

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

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

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

Хорошоп — магазин продавца; B2B-дропшиппинг рассматривается как включённая опция определённой группы покупателей. Основной пример относится к украинскому магазину с доставкой Новой почтой или Укрпочтой. Продажи в другие страны требуют отдельной проверки договора, валюты и перевозчика.

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

Официальный API использует адрес магазина и JSON POST. Справка внешних ЭН документирует передачу номера в операцию «Обновление заказов» на тарифе Pro и выше; её endpoint, поля, права и обработку повторов требуется проверить. Операторское добавление доступно с Standard. Вебхуки и гарантии доставки событий в прочитанных разделах не установлены.

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

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

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

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

Дроп-заказ на конечного получателя

Задача: Собрать товары нужного владельца и не отправить их по адресу B2B-покупателя.

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

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

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

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

  • Сумму закупки B2B-клиента нельзя молча подставлять в сумму для конечного получателя.
  • Если неизвестна принадлежность товара или SKU, заказ остаётся в разборе до сборки.

Товары с единицами измерения

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

Когда начинается: В заказе появляется упаковка, комплект или дробное количество.

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

Результат: Одна упаковка не превращается в одну штуку без явного правила.

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

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

Своя накладная без повторного создания

Задача: Сохранить единственного владельца отправления.

Когда начинается: Дропшиппер или внешняя система уже предоставили номер или файл ЭН.

  1. Из заказа извлекают наличие собственной ЭН и сопоставляют номер с заказом и коробкой; чужой файл не доказывает соответствие адреса или веса.
  2. Проверяют документ и печатают принятую версию; второй контур создания накладных для этой коробки выключают по согласованному процессу.
  3. Номер возвращают операторским способом либо после проверки схемы через «Обновление заказов» на Pro+. Сохраняют результат записи и повторно читают заказ; передача файла ЭН через API не предполагается.
  4. После передачи посылки сверяют движение перевозчика и отображение в Хорошопе. При неверном номере обращаются к владельцу отправления вместо повторного автоматического создания.
  5. Сохраняют историю замен: новая накладная не стирает исходную попытку и не вызывает повторное списание товара.

Результат: Магазин, дропшиппер и склад видят одно отправление.

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

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

Отмена и возврат дроп-заказа

Задача: Отделить согласование с партнёром от физического возврата товара.

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

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

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

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

  • Автоматический статус трекинга не заменяет осмотр возвращённого товара.

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

ДанныеОтветственный источникПравило обмена
Коммерческий заказ и пользовательМагазин ХорошопМенеджер определяет оплату и допуск к сборке.
Получатель и сумма для негоДроп-заказ магазинаНе подменять данными аккаунта B2B-покупателя или ценой закупки.
SKU и единицаКаталог магазина + утверждённая карта складаМагазин, вариант и владелец товара входят в ключ связи.
Остаток и резервSkirbo для обслуживаемого складаПраво записи наличия и семантика количества согласуются отдельно.
НакладнаяОдин выбранный отправительСуществующий документ используется после проверки; повторное создание исключается.
Возврат и расчётыСклад — приёмка; продавец — деньгиБрак, возврат оплаты и расчёт с дропшиппером ведутся раздельно.

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

  • Какие методы и права возвращают заказ, его изменения и dropshipping_details в этой редакции?
  • Какие endpoint, поля, права и правила повторов у передачи внешней ЭН через «Обновление заказов», и какие отдельные переходы статуса разрешены?
  • Кто резервирует товар и в какой единице записывается доступное количество?
  • Как подтверждаются отмена и расчёт с дропшиппером после возврата?
Перед оценкой

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

  • Указать тариф и используемые B2B/дропшиппинг-функции.
  • Описать владельца товара, покупателя и конечного получателя.
  • Подготовить таблицу единиц измерения и складских артикулов.
  • Адрес и редакция магазина, нужная группа покупателей и включённые опции дропшиппинга.
  • Обезличенные обычный и дроп-заказ, включая сведения о своей ЭН и разных суммах.
  • Права технического пользователя на согласованные операции; секреты не передавать через форму заявки.
  • Договориться, какой контур создаёт накладную и подтверждает её принятие.
  • Подтвердить тариф: операторское внесение внешней ЭН — Standard+, передача номера через API — Pro+; сверить фактическую доступность в магазине.
Границы сценария

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

  • Возможности зависят от настроек и тарифа магазина.
  • Сумма заказа партнёра может отличаться от суммы к оплате получателем.
  • Создание накладной в двух системах нужно исключить из процесса.
  • Вводная API-страница не раскрыла схемы методов заказов, остатков и возвратов; их нельзя считать принятыми.
  • Данные клиента и конечного получателя нельзя объединять по совпавшему телефону.
  • Складской факт передачи перевозчику, статус магазина и оплата проверяются отдельно.
  • Поддержка Новой почты/Укрпочты не подтверждает такой же процесс для другого перевозчика или страны.
Стоимость и запуск

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

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

Подготовьте обезличенный дроп-заказ Хорошопа с отдельным получателем, примером собственной ЭН и картой упаковок — по нему согласуем первый процесс склада.

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

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

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

Оптовые упаковки можно считать штуками?

Только по согласованному коэффициенту и правилам округления. В оценке зафиксируем единицу заказа и единицу складского учёта для каждой позиции.

Можно брать адрес из профиля покупателя?

В дроп-заказе это может быть адрес партнёра. Для сборки и этикетки нужен получатель конкретного заказа; несовпадение проверяет менеджер.

Кто создаёт накладную, если она уже приложена?

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

Статус доставки автоматически возвращает товар на остаток?

Нет в предлагаемой складской схеме. Доступный остаток увеличивается после физической приёмки и оценки состояния.

Подтверждён автоматический обмен со Skirbo?

Пока подтверждены предметные функции Хорошопа. Для Skirbo предстоят проверка методов, разработка и приёмка на конкретном магазине.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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