Обсудить задачу
Доставка

Skirbo +
B2CPL / Халва Экспресс

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

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

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

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

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

Согласовать идентификаторы и индивидуальные результаты загрузки.

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

Хранить клиентский номер и номер перевозчика; разбирать частичное исполнение.

Ожидаемый возвратB2CPL → SkirboОбсудим в составе подключения

Подготовить приёмку без преждевременного увеличения остатка.

Физический результат приёмкиSkirbo → продавецОбсудим в составе подключения

Подтвердить реальные единицы, качество и расхождение.

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

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

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

Для продавца или фулфилмента, использующего договор и кабинет B2CPL / Халва Экспресс в России. Прочитан официальный API-документ редакции 28 мая 2024 года; применимость этой редакции к вашему кабинету нужно подтвердить. Переименование не считается дополнительной интеграцией.

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

В опубликованной спецификации описан JSON-обмен по HTTPS, выдаваемые клиенту параметры доступа, опрос состояний и уведомления о смене основного статуса. Их включение и действующую редакцию согласуем до реализации.

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

  1. Продавец подтверждает получателя, способ доставки, оплату и разрешение на частичный отказ. Склад фиксирует фактические коробки и их вложения.
  2. Сопоставляют клиента договора, склад, номера заказов и номера мест. Артикулы разных продавцов не объединяют; масса и размеры передаются в единицах выбранной спецификации.
  3. Проектируемый адаптер сохраняет снимок партии и внешние связи, затем отправляет только разрешённые заказы. Параметры доступа остаются в защищённой настройке клиента.
  4. Проверяют результат каждой строки ответа. Если часть заказов отклонена, они остаются на разборе; успешно принятые получают номера B2CPL и связи мест.
  5. При потере ответа сверяют уже загруженные заказы по уникальному коду заказа в пределах кабинета; код получателя для обзвона не используют как номер отправления. Сопоставление полей разных методов подтверждают прежде, чем повторять создание. Режим изменения заказа не используется как универсальная защита от дублей.
  6. Перед выдачей оператор сверяет реальные коробки с оформленными отправлениями и согласованными документами. Физический приём перевозчиком фиксируется отдельным событием.
  7. При несовпадении состава или неизвестном номере отгрузку удерживают. Исправление подтверждается новым предметным результатом, а не общим успешным ответом партии.

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

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

Загрузить партию и выпустить только принятые отправления

Задача: Не выдать груз по технически успешному, но частично отклонённому запросу.

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

  1. Продавец подтверждает получателя, способ доставки, оплату и разрешение на частичный отказ. Склад фиксирует фактические коробки и их вложения.
  2. Сопоставляют клиента договора, склад, номера заказов и номера мест. Артикулы разных продавцов не объединяют; масса и размеры передаются в единицах выбранной спецификации.
  3. Проектируемый адаптер сохраняет снимок партии и внешние связи, затем отправляет только разрешённые заказы. Параметры доступа остаются в защищённой настройке клиента.
  4. Проверяют результат каждой строки ответа. Если часть заказов отклонена, они остаются на разборе; успешно принятые получают номера B2CPL и связи мест.
  5. При потере ответа сверяют уже загруженные заказы по уникальному коду заказа в пределах кабинета; код получателя для обзвона не используют как номер отправления. Сопоставление полей разных методов подтверждают прежде, чем повторять создание. Режим изменения заказа не используется как универсальная защита от дублей.
  6. Перед выдачей оператор сверяет реальные коробки с оформленными отправлениями и согласованными документами. Физический приём перевозчиком фиксируется отдельным событием.
  7. При несовпадении состава или неизвестном номере отгрузку удерживают. Исправление подтверждается новым предметным результатом, а не общим успешным ответом партии.

Результат: У каждой выданной коробки есть успешный результат регистрации её заказа и проверенная внешняя связь.

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

  • Один неуспешный заказ не делает всю партию успешной; общий success описывает техническую обработку.
  • Изменение состава до и после приёма на сортировочном центре требует разных правил. Обновление уже принятой посылки не выполняется произвольной повторной загрузкой.

Частичное вручение и сверка пропущенной истории

Задача: Различать доставленные и возвращаемые вложения.

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

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

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

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

  • Webhook не гарантирует извещение о любом изменении истории; документация связывает его с основным статусом.
  • Интервалы опроса из редакции 2024 года не выдаются за новый SLA; действующие ограничения согласуют с провайдером.

Запрос возврата → фактическая приёмка

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

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

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

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

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

  • Отмена заявки на машину и возврат конкретной посылки — разные операции.
  • Статус о направлении на возврат не подтверждает, что товар уже находится на складе.

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

ДанныеОтветственный источникПравило обмена
Заказ, стоимость и разрешение возвратаПродавецПринятые деньги и состояние доставки не подменяют друг друга.
Состав коробок и SKUСклад / Skirboparcels и items отражают реальную упаковку конкретного клиента.
Номер перевозчика и историяB2CPLИсходные коды хранятся рядом с внутренними, без замены одного другим.
Клиентский договор и доступВладелец кабинетаФулфилмент не объединяет client/key разных продавцов.
Приход возвратаФизический складПринять по количеству и качеству, затем сообщить продавцу.

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

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

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

  • Действующая спецификация именно вашего кабинета B2CPL / Халва Экспресс и подтверждение применимости редакции 2024 года.
  • Обезличенные примеры партии с отклонённым заказом и посылки с частичным вручением.
  • Правило уникальности клиентских номеров, складских кодов и коробок между продавцами.
  • Согласованные доставка, ПВЗ, возврат, интервалы сверки и владелец ответа на webhook.
Границы сценария

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

  • Доступная документация историческая; её чтение не подтверждает нынешние договоры, тарифы и условия API.
  • Статус «доставлено частично» нельзя применять ко всем строкам заказа одинаково.
  • Результат загрузки, вызов машины и фактическая сдача товара — отдельные события.
  • Готовый коннектор Skirbo, построчная финансовая сверка и рабочие API-вызовы этим материалом не подтверждены.
Стоимость и запуск

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

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

Какой кабинет B2CPL / Халва Экспресс используется и есть ли пример частичного вручения по нескольким коробкам?

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

Что сначала проверять в обмене B2CPL?

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

Можно сохранить номера из старой системы?

Это возможно оценить после проверки формата и пересечений. Номер продавца и номер B2CPL сохраняют раздельно; совпадение номеров у разных клиентов не должно объединять отправления.

Почему общий успешный ответ ещё не означает успех всей партии?

В API разделены техническое принятие запроса и результат отдельного заказа. Склад выпускает только отправления с проверенной регистрацией.

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

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

Что делать с частично доставленным заказом?

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

B2CPL и Халва Экспресс — два подключения?

В каталоге это одна тема. До проектирования уточняются действующий оператор, договор и интерфейс кабинета; историческое объединение само по себе не гарантирует одинаковых доступов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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