По запросу
Платежи
ЮKassa
Статусы оплат и возвратов для складского заказа.
ПлатежиSkirbo +
Skirbo +
Чек Онлайн — модуль InSales
Согласовать, какие складские результаты разрешают магазину менять статусы, запускающие модуль, и исключить второй параллельный источник чеков.
Какой обмен обсудим
Зафиксируем нужные операции, направление данных и условия приёмки.
| Операция | Направление | Состав и готовность |
|---|---|---|
| Подтверждённый складской этап | Skirbo → InSales | Обсудим в составе подключения Предлагается контролируемая запись статуса по отдельному контракту магазина. |
| Данные фискального события | Модуль InSales → Чек Онлайн | Обсудим в составе подключения Подтверждён статусный механизм для заданных способов оплаты. |
| Журнал чеков и частичный возврат | Чек Онлайн / InSales ↔ оператор | Обсудим в составе подключения Проверка результата и кабинетная частичная операция. |
На узком экране таблицу можно прокрутить в сторону.
Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.
Для какой задачи подходит сервис
Рассматривается «Чек Онлайн» через документированный модуль InSales. Источник описывает автоматическое формирование чеков по выбранным статусам заказа и способам оплаты, а частичные возвраты — в кабинете «Чек Онлайн». Это самостоятельный фискальный контур магазина, не повтор общей интеграции InSales и не универсальный API чеков.
Как организовать обмен
Подтверждён модуль магазина и кабинетная настройка. Связь Skirbo → статус InSales требует отдельного проверенного контракта; прямой вызов универсального кассового API не предполагается.
Предлагаемый порядок работы
- Связать клиента, магазин InSales, заказ и кассу/точку продажи «Чек Онлайн». Проверить, какая система уже отвечает за чек.
- Склад фиксирует фактические SKU и количество, продавец подтверждает состав, оплату и реквизиты расчёта. Складское «собрано» само по себе не выбирается как фискальный триггер.
- По согласованной таблице передать результат в магазин и проверить запись нужного статуса. Модуль получает заказ по своим настройкам статусов и способов оплаты.
- Проверить журнал чеков и информацию в карточке заказа. Сохранить подтверждённую связь документа с магазином и исходным событием; изменение статуса ещё не доказательство готового чека.
- Ответственный подтверждает фискальный результат, склад отдельно завершает физическую выдачу. Другой кассовый адаптер не должен формировать документ по тому же событию.
- Если статус сменился, а результата нет, сначала разобрать журнал и состояние подключения. Повторное переключение статусов не используется как универсальный способ повтора без проверки существующего чека.
Практические сценарии
Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.
Запустить чек через согласованный статус магазина
Задача: Не сформировать чек раньше подтверждённого расчёта или дважды из разных систем.
Когда начинается: Склад завершил согласованный этап выдачи, а продавец подтвердил соответствующее фискальное событие.
- Связать клиента, магазин InSales, заказ и кассу/точку продажи «Чек Онлайн». Проверить, какая система уже отвечает за чек.
- Склад фиксирует фактические SKU и количество, продавец подтверждает состав, оплату и реквизиты расчёта. Складское «собрано» само по себе не выбирается как фискальный триггер.
- По согласованной таблице передать результат в магазин и проверить запись нужного статуса. Модуль получает заказ по своим настройкам статусов и способов оплаты.
- Проверить журнал чеков и информацию в карточке заказа. Сохранить подтверждённую связь документа с магазином и исходным событием; изменение статуса ещё не доказательство готового чека.
- Ответственный подтверждает фискальный результат, склад отдельно завершает физическую выдачу. Другой кассовый адаптер не должен формировать документ по тому же событию.
- Если статус сменился, а результата нет, сначала разобрать журнал и состояние подключения. Повторное переключение статусов не используется как универсальный способ повтора без проверки существующего чека.
Результат: Фискальный документ создаётся одним согласованным модулем по проверенному событию.
Если возникло исключение
- Исторические настройки автономной кассы с открытым портом не копируются; рабочий защищённый вариант подтверждается отдельно.
Оформить частичный возврат в кабинете
Задача: Не применить общий статус возврата ко всему заказу.
Когда начинается: Склад принял только часть проданных товаров.
- Зафиксировать фактические позиции и решение продавца о сумме возврата.
- Уполномоченный сотрудник выполняет частичный возврат в кабинете «Чек Онлайн», как указано в инструкции.
- Сверить полученный документ и отражение в магазине, не запуская дополнительно полный возврат статусом.
Результат: Частичный возврат не превращается в полный.
Если возникло исключение
- Наличие частичного возврата в кабинете не доказывает его автоматизацию через модуль.
Разделить несколько магазинов на одной кассе
Задача: Сохранить происхождение каждого чека.
Когда начинается: Одна касса обслуживает несколько магазинов.
- Задать согласованные различающиеся идентификаторы точек продаж по инструкции.
- Сопоставить магазин, клиента и событие с кассовым документом.
- Проверить, что одинаковые номера заказов разных магазинов не объединяются.
Результат: История чеков разделена по источнику заказа.
Если возникло исключение
- Один общий номер заказа без магазина недостаточен для дедупликации.
Кто управляет данными
| Данные | Ответственный источник | Правило обмена |
|---|---|---|
| Заказ, цены и статус магазина | InSales / продавец | Таблица фискальных триггеров согласуется с фактом расчёта. |
| SKU, запас и выдача | Skirbo / склад | Сборка не является самостоятельным основанием кассового решения. |
| Чек и точка продажи | Чек Онлайн | Каждый документ связан с магазином и событием. |
| Платёж | Платёжный контур продавца | Модуль чека не подтверждает получение денег. |
| Возврат | Склад и продавец | Частичный физический возврат сверяется с кабинетным документом. |
Что обсудить перед пилотом
- Какие статусы реально запускают модуль и есть ли другой отправитель чеков?
- Кто выполняет частичный возврат и сверяет журнал?
- Кто согласует таблицу статусов при изменении бизнес-процесса магазина и проверяет отсутствие второго отправителя чеков?
Перед оценкой
Что нужно уточнить
- Действующий модуль, магазин, касса и различающиеся точки продаж.
- Таблица статусов прихода/возврата и способов оплаты; один владелец фискализации.
- Регламент проверки журнала и частичного возврата без повторного полного документа.
Границы сценария
Что учесть заранее
- Источник описывает безналичный сценарий; другие способы расчёта не добавляются по предположению.
- Инструкция историческая, действующие настройки сертификатов и защищённого транспорта проверяются.
- Прямой API, webhook, идемпотентность и автоматический частичный возврат не подтверждены.
Стоимость и запуск
Оценим ваш набор операций
На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.
Какие статусы InSales запускают чек прихода/возврата и кто подтверждает их после складского события?
Вопросы о подключении
Достаточно статуса «собран» для чека?
Статусный триггер должен соответствовать подтверждённому расчёту по правилам продавца. Складская готовность сама по себе не задаёт фискальное событие.
Можно параллельно отправлять чек напрямую из Skirbo?
Нужно выбрать одного ответственного отправителя на событие. Иначе модуль магазина и отдельный адаптер могут создать два документа.
Частичный возврат проходит через статус магазина?
В прочитанной инструкции частичные возвраты выполняются в кабинете «Чек Онлайн». Автоматический механизм модуля для них не доказан.
Как различать одинаковые номера заказов разных магазинов?
Использовать связку магазина, точки продажи и номера заказа. Документ рекомендует разные идентификаторы точек для нескольких магазинов на одной кассе.
Почему нужно согласовать способ оплаты вместе со статусом?
Модуль использует обе настройки. В инструкции он ограничен безналичными расчётами; один и тот же статус без проверки способа оплаты не даёт оснований распространить сценарий на любую продажу.
Какой результат склад должен получить от ответственного за чек?
Связь с исходным заказом, подтверждённый результат и состав расчёта. Конкретные поля журнала и способ передачи согласуются на пилоте; произвольная отметка «отправлено» не заменяет эту сверку.
Интеграция уже готова?
Изучаем возможность связи со Skirbo. Рабочий коннектор и сроки подключения не подтверждены; сначала согласуем описанный ниже процесс и проверим доступный интерфейс. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.
Официальные материалы сервиса
Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.
- Чек Онлайн — настройка интеграции с InSales (PDF) — дата проверки: 2026-10-30
Посмотрите другие сценарии
Весь каталог →Ваш процесс → следующий шаг
Что хотите связать со Skirbo?
Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.
- Разберём задачуУточним роли, склады и операции.
- Проверим возможностьОпределим доступы, ограничения и состав работ.
- Согласуем запускОбсудим стоимость, сроки и критерии готовности.
Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.