Обсудить задачу
Платежи

Skirbo +
БИФИТ Касса — Касса Курьер

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

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

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

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

ОперацияНаправлениеСостав и готовность
Поручение доставкиПродавец / оператор → курьерский контурНужна проверка

Возможен проект на подтверждённом создании онлайн-заказа: организация, торговый объект, внешний ID, строки и условие оплаты. Доступ и назначение сотрудника проверяются у клиента.

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

Фиксируется отдельным действием по клиенту и складу.

Результат расчёта и врученияКурьерский контур → ответственный продавцаНужна проверка

Чтение онлайн-заказа подтверждено; его состояние сопоставляется с отдельными подтверждениями расчёта, вручения и возврата. Один статус не доказывает все три факта.

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

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

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

Официальный каталог БИФИТ различает «Касса Курьер», розничные программы, личный кабинет учёта, облачную кассу и ТСД. Здесь выбран только «Касса Курьер» для расчёта и доставки собственными сотрудниками. Дополнительно прочитаны его адресная страница API, авторизация, создание и чтение онлайн-заказа.

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

Для «Касса Курьер» подтверждены REST-операции создания онлайн-заказа и чтения по внутреннему ID, с токеном доступа. Перед реализацией проверяются редакция клиента, права организации и торгового объекта, назначение курьера и результат расчёта. Операторский процесс остаётся вариантом до приёмки автоматического маршрута.

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

  1. Зафиксировать клиента фулфилмента, организацию продавца, заказ, склад выдачи и ответственного курьера. Выбрать операторский путь либо отдельно принимаемый API-маршрут для конкретной редакции.
  2. Склад проверяет SKU, количество и грузовые места. Продавец подтверждает сумму к получению, уже внесённую оплату и необходимые реквизиты расчёта.
  3. При операторском пути уполномоченный диспетчер передаёт задание и сверяет его видимость у сотрудника. При API-маршруте проверяются внутренний ID задания и назначенный сотрудник; создание заказа не подменяет физическую передачу.
  4. Кладовщик и курьер подтверждают физическую передачу мест по одной ведомости или записи согласованного процесса. Финансовый итог в этот момент ещё не известен.
  5. После вручения ответственный получает подтверждение фактически переданного состава и результата расчёта из проверенного курьерского/кассового контура. Он сопоставляет его с исходной выдачей и принимает результат в учётной системе.
  6. При отказе или расхождении деньги, товар и документ разбираются отдельно. Неполученное подтверждение не превращается в успешную доставку; остаток восстанавливается только после физической приёмки возврата.

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

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

Сверить выдачу курьеру с расчётом у покупателя

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

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

  1. Зафиксировать клиента фулфилмента, организацию продавца, заказ, склад выдачи и ответственного курьера. Выбрать операторский путь либо отдельно принимаемый API-маршрут для конкретной редакции.
  2. Склад проверяет SKU, количество и грузовые места. Продавец подтверждает сумму к получению, уже внесённую оплату и необходимые реквизиты расчёта.
  3. При операторском пути уполномоченный диспетчер передаёт задание и сверяет его видимость у сотрудника. При API-маршруте проверяются внутренний ID задания и назначенный сотрудник; создание заказа не подменяет физическую передачу.
  4. Кладовщик и курьер подтверждают физическую передачу мест по одной ведомости или записи согласованного процесса. Финансовый итог в этот момент ещё не известен.
  5. После вручения ответственный получает подтверждение фактически переданного состава и результата расчёта из проверенного курьерского/кассового контура. Он сопоставляет его с исходной выдачей и принимает результат в учётной системе.
  6. При отказе или расхождении деньги, товар и документ разбираются отдельно. Неполученное подтверждение не превращается в успешную доставку; остаток восстанавливается только после физической приёмки возврата.

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

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

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

Выбрать правильный продукт семейства

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

Когда начинается: У клиента уже есть БИФИТ, но не определено, в какой программе работают сотрудники.

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

Результат: Техническое задание относится к конкретному продукту.

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

  • Наличие ссылки на «Фискальный процессинг» не доказывает API заказов «Касса Курьер».

Передать онлайн-заказ и сверить его исполнение

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

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

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

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

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

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

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

ДанныеОтветственный источникПравило обмена
Заказ, сумма и условияПродавецОплата подтверждается финансовым владельцем, не догадкой склада.
SKU, остаток, резерв и местаSkirbo / складОдна ведомость передачи, отдельная приёмка возврата.
Курьерское заданиеУполномоченный диспетчерСпособ записи и идентификаторы проверяются по реальному приложению.
Статус расчёта и документыКассовый контур продавцаФакт выдачи не подтверждает чек или получение денег.
ВозвратКурьер, склад и продавецОтказ, физическая сдача и финансовое решение раздельны.

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

  • Как сейчас курьер получает задание и подтверждает деньги и товар?
  • Какая документация и тестовая среда доступны по договору именно «Касса Курьер»?
  • Кто имеет право создавать заказ для организации и торгового объекта, и как подтверждается назначение курьера?
  • Как находят уже созданное задание, если ответ создания не дошёл?
  • Каким отдельным документом подтверждается частичная выдача или возврат?
Перед оценкой

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

  • Точное название продукта, редакция и ОС, договор и ответственные сотрудники.
  • Пример заказа, ведомости выдачи и доступного результата курьерского расчёта.
  • Разделение организаций клиентов и правила доступа к кассовым данным.
  • Учётная запись интеграции с согласованными правами; токены хранятся в защищённой настройке, а не в тексте заявки на сайте.
  • Соответствие organizationId, tradeObjectId, номенклатуры и внутреннего ID заказа; внешний номер сохраняется у исходного заказа.
Границы сценария

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

  • API создания и чтения онлайн-заказа прочитан. Его наличие не доказывает все переходы состояний, подтверждение чека или договорный доступ клиента.
  • PDF-руководства перечислены, но их содержимое не использовалось как прочитанное доказательство.
  • Нет обещаний маршрутизации, онлайн-трекинга, частичного расчёта, SLA или готового Skirbo-коннектора.
  • Уникальный внешний номер используется для прослеживаемости, но прочитанная документация не гарантирует защиту от повторного создания.
  • При неизвестном сетевом исходе сначала сверяются существующие задания; назначение нового номера не используется как способ обойти разбор.
Стоимость и запуск

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

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

Какая редакция «Касса Курьер», организация и процесс приёма оплаты используются вашими выездными сотрудниками?

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

Это статья об облачной кассе БИФИТ?

Выбран «Касса Курьер». Облачная касса и фискальный процессинг существуют в отдельном разделе каталога; их подключение требует своего контракта.

Почему пока предлагается операторская передача?

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

Можно сразу включить приложение ТСД в ту же интеграцию?

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

Когда возвращать товар в остаток после отказа?

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

Достаточно передать внешний номер, чтобы не создать дубль?

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

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

Нет. Состояние заказа, результат расчёта, документ и физическое движение проверяются раздельно; при отказе товар возвращается в остаток только после приёмки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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