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

Skirbo +
OrangeData

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

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

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

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

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

Склад даёт факты; продавец задаёт финансовые и фискальные реквизиты.

Документ и статусАдаптер ↔ OrangeDataОбсудим в составе подключения

SDK подтверждает отправку и запрос состояния по ID; рабочая редакция проверяется.

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

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

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

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

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

Рассматривается прямой контур OrangeData и официальный PHP SDK. README закреплён коммитом и описывает протокол 2.29.1 от 15.11.2023: клиент с ключами и сертификатами, документ, позиции, оплаты, отправка и проверка статуса. Исторические налоговые перечисления не используются как актуальные правила.

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

Есть официальная SDK-документация прямой связи. Она прочитана в закреплённой версии, но не доказывает текущую совместимость её справочников и вашего договора. Готовый партнёрский модуль OrangeData не является готовым коннектором Skirbo.

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

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

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

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

Подтвердить фискализацию фактического расчёта

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

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

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

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

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

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

Возврат прихода по принятому товару

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

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

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

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

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

  • Чек коррекции — отдельный инструмент; его применение не выводится из факта возврата.

Развести группы касс и версии документов

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

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

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

Результат: Клиенты и фискальные форматы не смешиваются.

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

  • Адрес склада не автоматически место расчёта; реквизиты подтверждает продавец.

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

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

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

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

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

  • Актуальный протокол, организация, группа, ФФД и комплект доступа.
  • Правило формирования уникального документа и сверки неизвестного результата.
  • Ответственный за фискальные справочники и маркировку по реальному ассортименту.
Границы сценария

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

  • Протокол SDK датирован 2023 годом; его ставки, перечисления и примеры требуют актуализации.
  • Наличие SDK не подтверждает сроки разработки, SLA или готовность Skirbo.
  • Российский кассовый контур не переносится на Казахстан и Узбекистан без проверки.
Стоимость и запуск

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

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

Какой расчёт, организация и группа касс должны фискализировать выдачу или возврат?

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

«Заказ» SDK — это складской заказ?

В этом контексте он описывает фискальный документ. Его ID необходимо хранить отдельно от складского заказа и транзакции оплаты.

Можно работать по старым налоговым кодам README?

Нет основания считать их актуальными. Перед подключением нужны действующие справочники и подтверждение продавца.

Что делать, если ответ отправки потерян?

Проверить статус того же документа. Новый ID без сверки может создать второй фискальный документ.

Можно отключить проверку маркировки ради чека?

Такой обход не является способом исправить ошибку. Нужно разобрать код, формат и основание операции по действующему контракту и правилам продавца.

Можно использовать тестовые сертификаты в рабочем магазине?

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

Почему одного номера заказа недостаточно для сверки?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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