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

Skirbo +
Модулькасса

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

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

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

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

ОперацияНаправлениеСостав и готовность
Внешний документПродавец / адаптер → МодулькассаОбсудим в составе подключения

Подтверждены документы SALE/RETURN и привязка к торговой точке.

Проведённый документМодулькасса → учётный контурОбсудим в составе подключения

Проверять linkedDocId, а не только ответ создания.

Состав и выдачаSkirbo ↔ продавецОбсудим в составе подключения

Склад даёт факты, кассовый контур подтверждает проведение.

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

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

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

Рассматривается API внешних заказов Модулькассы, включая документ для конкретной торговой точки и получение связанного кассового документа. Это кассовый продукт, отдельный от банковского обслуживания Модульбанка. Созданный внешний заказ ещё не является проведённым чеком.

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

Подтверждён HTTP API внешних заказов. Сохранены две редакции PDF; для внедрения нужна применимая версия, особенно для ФФД и маркированных позиций. Это не подтверждение автоматического эквайринга или готовой интеграции Skirbo.

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

  1. Сопоставить клиента, заказ, торговую точку и склад. Проверить retailPointId и в URL, и в теле: при конфликте по документу действует значение тела.
  2. Склад фиксирует состав и коды физических единиц; продавец подтверждает цены, признаки расчёта и статус предоплаты.
  3. Создать внешний документ SALE с согласованными позициями. Сохранить серверный orderId отдельно от внешнего номера/remoteId.
  4. Кассир в точке сверяет полученный заказ и проводит расчёт. Склад физически выдаёт товар по согласованному разрешению, фиксируя момент и состав.
  5. Получить связанный проведённый кассовый документ по orderId и проверить сумму, точку и состав. Подтверждение возвращается в учётный контур и привязывается к выдаче.
  6. Если документ только создан или ответ неизвестен, не считать его чеком. Сначала прочитать существующий заказ и проверить кассовое проведение; повтор создания с новым ID откладывается до сверки.

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

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

Передать заказ на выдачу с оплатой в точке

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

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

  1. Сопоставить клиента, заказ, торговую точку и склад. Проверить retailPointId и в URL, и в теле: при конфликте по документу действует значение тела.
  2. Склад фиксирует состав и коды физических единиц; продавец подтверждает цены, признаки расчёта и статус предоплаты.
  3. Создать внешний документ SALE с согласованными позициями. Сохранить серверный orderId отдельно от внешнего номера/remoteId.
  4. Кассир в точке сверяет полученный заказ и проводит расчёт. Склад физически выдаёт товар по согласованному разрешению, фиксируя момент и состав.
  5. Получить связанный проведённый кассовый документ по orderId и проверить сумму, точку и состав. Подтверждение возвращается в учётный контур и привязывается к выдаче.
  6. Если документ только создан или ответ неизвестен, не считать его чеком. Сначала прочитать существующий заказ и проверить кассовое проведение; повтор создания с новым ID откладывается до сверки.

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

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

  • Предоплаченный заказ по источнику ограничен в редактировании на кассе; изменения состава согласуются до отправки.

Перенести заказ в другую точку

Задача: Не оставить две точки готовыми выдать один товар.

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

  1. Проверить отсутствие проведения и физической выдачи.
  2. Согласовать перенос существующего orderId с новым retailPointId, отдельно переместив или переразместив товар по складскому процессу.
  3. Прочитать результат в новой точке и отозвать старое поручение выдачи.

Результат: У заказа одна действующая точка расчёта.

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

  • Перенос кассового документа сам по себе не перемещает товар между складами.

Возврат после проведённой продажи

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

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

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

Результат: История продажи и возврата сохраняется.

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

  • DELETE заказа не объявляется способом отмены уже проведённого фискального результата.

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

ДанныеОтветственный источникПравило обмена
Заказ и ценыПродавецСостав/предоплата согласуются до кассы.
SKU, коды и остатокСклад / учётный справочникФизический товар не перемещается от смены retailPointId.
Внешний orderIdМодулькассаСерверный ID отделён от номера и remoteId.
Чек и статус проведенияКасса / МодулькассаСоздание заказа и проведение различаются.
ВозвратПродавец и складRETURN и приёмка имеют раздельные результаты.

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

  • Где проходит граница между готовностью к выдаче и проведением кассы?
  • Нужны переносы точек и как проверяется отсутствие прежней выдачи?
  • Какая схема уведомления на responseURL и способ проверки его отправителя разрешены для вашего подключения?
Перед оценкой

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

  • Точная редакция API, торговые точки и область доступа пользователя.
  • Таблица внешних и серверных ID, правило переноса и проверки проведения.
  • Актуальные фискальные справочники, формат кодов и ответственный кассир.
Границы сценария

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

  • Исторические примеры PDF не определяют текущие налоговые ставки и ФФД.
  • Смысл responseURL, повторов и ошибок не раскрыт полностью в прочитанном документе.
  • Банковские операции Модульбанка не входят в эту статью.
  • Редакции PDF различаются описанием кода маркировки и перечнями значений; объединять их в одну схему без подтверждения поставщика нельзя.
Стоимость и запуск

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

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

Какая торговая точка принимает расчёт и как склад получает подтверждение проведённого заказа?

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

Созданный заказ уже пробит?

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

Какая точка важнее при несовпадении?

В PDF поле retailPointId в теле имеет приоритет над URL. Интеграция должна выявлять такое расхождение до записи.

Можно исправить предоплаченный заказ на кассе?

В прочитанном описании prepaid-заказ нельзя редактировать на кассе. Изменение состава требует заранее согласованного процесса.

Удаление заказа возвращает деньги?

Такого подтверждения нет. Удаление внешнего документа нельзя подменять возвратным расчётом или отменой проведённого чека.

Зачем responseURL, если есть чтение кассового документа?

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

Можно скопировать пример JSON из PDF в реализацию?

Нужна проверенная схема. В извлечённом тексте встречаются типографские кавычки, переносы адресов и различие remoteId/remoteID; редакции также различаются описанием маркировки. Такие примеры не используются как готовый исполняемый контракт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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