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

Skirbo +
Первый ОФД — облачная касса

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

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

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

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

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

Фискальное событие направляется в согласованную организацию и группу. Для queue-варианта PDF сохраняются внешний ID события и requestId заявки; формат и адрес доступа подтверждаются отдельно.

Результат обработки выбранного APIПервый ОФД → учётный контурОбсудим в составе подключения

По queue-контракту PDF результат может быть конечным или IN_PROCESS; подтверждение читается по requestId. Синхронная модель старой инструкции сохраняется отдельной областью, не общей гарантией.

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

Подтверждён ручной сценарий по исходному чеку.

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

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

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

Рассматривается продукт «Облачные кассы» Первого ОФД. Сохранённая обзорная инструкция называет ФФД 1.2, форматы OKassa/Атол и синхронный ответ без очереди. Отдельно прочитанный PDF OKassa описывает queue API со статусом обработки. Эти модели привязываются к своим документам; применимую поверхность и редакцию должен подтвердить поставщик для доступа клиента. Это не API аналитики ОФД и не ЭДО.

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

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

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

  1. Сопоставить клиента, организацию, ИНН, группу и формат API; получить подтверждение точной поверхности и редакции. Сохранённая инструкция требует группу даже для единственной кассы.
  2. Склад подтверждает фактический состав, продавец — цены, вид расчёта и актуальные фискальные реквизиты. Для queue-варианта заранее зафиксировать внешний идентификатор события и группу, не менять их при неизвестном исходе.
  3. Отправить запрос в выбранный контур. Тестовая группа и рабочая группа имеют отдельные настройки; результат теста не прикрепляется как чек реальной выдачи.
  4. Разобрать ответ по выбранному контракту. В queue-варианте сохранить requestId и состояние; при IN_PROCESS запросить окончательный результат. Синхронный путь проверяется по своему контракту. Ответственный сверяет организацию, состав, сумму и документ.
  5. Передать в складской процесс согласованный результат и отдельно зафиксировать фактическую выдачу. Созданный чек не доказывает, что курьер уже забрал товар.
  6. При явном отказе применить регламент выбранной поверхности. При потере сетевого ответа сначала проверить известную заявку или документ; не считать таймаут отказом и не создавать новый внешний номер для того же расчёта.

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

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

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

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

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

  1. Сопоставить клиента, организацию, ИНН, группу и формат API; получить подтверждение точной поверхности и редакции. Сохранённая инструкция требует группу даже для единственной кассы.
  2. Склад подтверждает фактический состав, продавец — цены, вид расчёта и актуальные фискальные реквизиты. Для queue-варианта заранее зафиксировать внешний идентификатор события и группу, не менять их при неизвестном исходе.
  3. Отправить запрос в выбранный контур. Тестовая группа и рабочая группа имеют отдельные настройки; результат теста не прикрепляется как чек реальной выдачи.
  4. Разобрать ответ по выбранному контракту. В queue-варианте сохранить requestId и состояние; при IN_PROCESS запросить окончательный результат. Синхронный путь проверяется по своему контракту. Ответственный сверяет организацию, состав, сумму и документ.
  5. Передать в складской процесс согласованный результат и отдельно зафиксировать фактическую выдачу. Созданный чек не доказывает, что курьер уже забрал товар.
  6. При явном отказе применить регламент выбранной поверхности. При потере сетевого ответа сначала проверить известную заявку или документ; не считать таймаут отказом и не создавать новый внешний номер для того же расчёта.

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

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

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

Оформить возврат в кабинете по исходному чеку

Задача: Сохранить связь с продажей при ручной операции.

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

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

Результат: Возврат имеет проверенное основание.

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

  • Частичный состав и корректировки требуют отдельной инструкции; не считать автоматическое заполнение универсальным решением.

Разобрать занятость группы касс

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

Когда начинается: Касса отказала из-за занятости.

  1. Сохранить задание и причину, не меняя организацию ради быстрого ответа.
  2. Повторить только по подтверждённому регламенту этой поверхности и группы. Состояние IN_PROCESS уже принятой queue-заявки ведёт к чтению статуса, а не к новой фискальной заявке.
  3. Сверить результат и снять задачу только после окончательного подтверждения.

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

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

  • Случайный перевод на группу другого продавца недопустим.

Довести queue-заявку до проверенного результата

Задача: Разделить ожидание, ошибку и неопределённую отправку без повторного чека.

Когда начинается: Для клиента подтверждён queue-вариант OKassa, и после отправки ещё нет окончательного документа.

  1. Проверить уже сохранённые организацию, группу, внешний ID события и requestId. Связать их с версией расчёта, а не только номером заказа.
  2. Если requestId известен, получить заявку и её статус по соответствующим методам. Сохранить исходный статус и время наблюдения.
  3. При IN_PROCESS оставить ожидание и выполнить согласованную повторную проверку. При ERROR сохранить причину для ответственного; при COMPLETED проверить документный результат.
  4. Сверить организацию, суммы и состав результата с расчётом. Склад отдельно подтверждает физическую выдачу; наличие документа не передаёт товар курьеру.
  5. Вернуть подтверждение в учётный процесс и завершить одну локальную задачу. Повторное чтение конечного результата не создаёт новую выдачу.
  6. Если requestId потерян, остановить создание нового основания и согласовать поиск существующей заявки с поставщиком. Изменение группы или внешнего номера не используется как обход неопределённости.

Результат: Известно, какая заявка завершилась и какой результат относится к одному расчёту.

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

  • Этот сценарий включается только после подтверждения queue-поверхности клиента.
  • Отдельный callback не считается гарантированным до проверки транспорта, подписи/доступа и повторов.

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

ДанныеОтветственный источникПравило обмена
Заказ и фискальные реквизитыПродавецСклад не назначает налоговую модель.
SKU, остаток и выдачаSkirbo / складФизическое движение отделено от фискального документа.
Группа и доступПродавец / Первый ОФДИдентификатор группы и ИНН проверяются вместе.
Чек и отказОблачная кассаПроверяется содержимое ответа и окончательный статус выбранной поверхности; HTTP-успех или принятая заявка не заменяют фискальный документ.
Возврат товара и денегСклад и продавецПриёмка, финансовый возврат и чек имеют отдельные подтверждения.

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

  • Какой формат API выбран и как проверяется уже созданный документ?
  • Кто разбирает отказы и согласует повтор в рабочей группе?
  • Какой точный адрес и редакция доступны по договору: синхронный маршрут или queue API, и чем это подтверждено?
  • Как найти уже принятую заявку, если первый ответ с requestId потерян?
Перед оценкой

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

  • Выбранный формат API, организация и группа, логин/API-доступ.
  • Проверенный контракт идентификаторов, сверки и безопасного повтора.
  • Актуальные реквизиты и правила ФФД для ассортимента продавца.
  • Подтверждение поставщиком, относится ли клиентский доступ к синхронному интерфейсу статьи или queue-поверхности PDF, включая точный адрес и редакцию.
  • Для queue-варианта — журнал requestId, стабильный внешний идентификатор события в области группы и регламент запроса результата.
Границы сценария

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

  • API облачной кассы не объединяется с API чтения данных ОФД, ЭДО или ЭПД.
  • Два прочитанных источника описывают разные модели завершения. Их соотношение и доступная клиенту поверхность остаются открытым вопросом; API не объединяются по сходству названия.
  • Историческую паузу повтора и условия договора нужно подтвердить; сроки подключения не обещаются.
  • В queue-контракте повтор по той же группе и externalId защищает от повторной обработки. Это не доказывает поиск по externalId и восстановление requestId после потерянного первого ответа.
  • Callback упомянут в PDF, но проверенный безопасный контракт доставки и авторизации не установлен. В предлагаемом процессе рассматривается запрос состояния, а не обещание webhook.
Стоимость и запуск

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

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

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

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

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

В прочитанной инструкции адресатом всегда является группа, даже при одной кассе.

Успех означает только постановку в очередь?

Нужно различать принятый запрос и конечный документ. PDF OKassa описывает очередь и IN_PROCESS с последующей проверкой по requestId; сохранённая обзорная статья — синхронный результат без очереди. Какой вариант относится к вашему доступу, подтверждается до разработки.

При любом таймауте можно повторить чек?

Нет. Явная занятость и потерянный сетевой ответ — разные случаи. Во втором сначала выясняют, не был ли документ создан.

Этим API можно подписывать УПД?

Такое утверждение не следует из документации облачной кассы. ЭДО — отдельный продукт и отдельный контракт.

Что делать, если requestId получен, а чек ещё не готов?

Для описанной в PDF queue-поверхности предусмотрены запрос заявки и её текущего статуса. До конечного результата запись остаётся ожидающей; новая фискальная операция для ускорения не создаётся.

Можно поменять externalId и повторить потерянный запрос?

Для одного расчёта так делать нельзя по предлагаемому регламенту: защита в PDF привязана к той же группе и внешнему ID. Если первый requestId потерян, нужен согласованный способ поиска уже принятой заявки, а не новое основание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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