Обсудить задачу
Документы и маркировка

Skirbo +
Платформа ОФД

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

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

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

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

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

Заказ, организация, точка, касса, сумма и исходные реквизиты. В кабинете доступен поиск по периоду и ФД/ФП; одной суммы недостаточно.

Фискальные сведенияПлатформа ОФД → SkirboОбсудим в составе подключения

Результат чтения кабинета; для согласованного клиента Эвотора — возможное чтение через его API. Общий API кабинета остаётся неподтверждённым.

РасхождениеSkirbo → ответственный кассового процессаОбсудим в составе подключения

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

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

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

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

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

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

Основной подтверждённый путь — поиск и сверка в разрешённом личном кабинете Платформы ОФД. Для клиента, использующего Эвотор, можно оценить отдельное чтение документов через API Эвотора; договор и права этого пути проверяются отдельно. Общий API чтения фискальных данных любых касс кабинета пока не подтверждён.

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

  1. Получить заказ, платёжный идентификатор, сумму и реквизиты кассовой операции из её источника.
  2. Сопоставить организацию, торговую точку, кассу и доступные фискальные реквизиты; сумма сама по себе не идентифицирует чек.
  3. Уполномоченный оператор ищет документ в разделе «Чеки» по периоду, торговой точке и кассе, затем уточняет ФД/ФП и сумму. Для отдельно согласованного клиента Эвотора допустим проверенный маршрут чтения через его API.
  4. Ответственный сверяет расчёт, документ и физическую выдачу склада; каждый факт сохраняется независимо.
  5. Вернуть в Skirbo результат сопоставления, источник и время проверки, включая неподтверждённые элементы.
  6. Ответственный подтверждает совпадение организации, кассы, фискальных реквизитов и состава; фиксирует дату чека и время проверки. Статус приёма ФНС хранит отдельно от денег и физической выдачи.
  7. При отсутствии или несоответствии открыть исключение с владельцем кассового процесса; не создавать автоматически новый платёж, чек или отгрузку.

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

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

Оплата есть — фискальный результат нужно сверить

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

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

  1. Получить заказ, платёжный идентификатор, сумму и реквизиты кассовой операции из её источника.
  2. Сопоставить организацию, торговую точку, кассу и доступные фискальные реквизиты; сумма сама по себе не идентифицирует чек.
  3. Уполномоченный оператор ищет документ в разделе «Чеки» по периоду, торговой точке и кассе, затем уточняет ФД/ФП и сумму. Для отдельно согласованного клиента Эвотора допустим проверенный маршрут чтения через его API.
  4. Ответственный сверяет расчёт, документ и физическую выдачу склада; каждый факт сохраняется независимо.
  5. Вернуть в Skirbo результат сопоставления, источник и время проверки, включая неподтверждённые элементы.
  6. Ответственный подтверждает совпадение организации, кассы, фискальных реквизитов и состава; фиксирует дату чека и время проверки. Статус приёма ФНС хранит отдельно от денег и физической выдачи.
  7. При отсутствии или несоответствии открыть исключение с владельцем кассового процесса; не создавать автоматически новый платёж, чек или отгрузку.

Результат: Видно, какого подтверждения не хватает и кто его проверяет.

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

  • Отсутствие записи в доступных данных не доказывает отсутствие самого расчёта.
  • Передача фискальных данных не доказывает банковское поступление.

Проблема одной кассы в нескольких точках

Задача: Отделить техническую проблему источника от отсутствия оплат.

Когда начинается: У нескольких заказов одной кассы нет ожидаемого подтверждения.

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

Результат: Сбой одной кассы не объявляет неоплаченными заказы всех клиентов.

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

  • Пропавший доступ к кабинету не является статусом кассы.
  • Универсальный API мониторинга касс не подтверждён; чтение чеков по одному устройству Эвотора не означает полный мониторинг кабинета.

Документ возврата и принятый товар

Задача: Не связывать разные возвращённые позиции по одной сумме.

Когда начинается: По исходному заказу оформлен возврат.

  1. Склад фиксирует фактически принятые SKU и состояние; финансовый контур подтверждает своё действие.
  2. Ответственный находит связанный кассовый результат и проверяет исходный заказ, суммы и реквизиты.
  3. Сохраняет три отдельные связи: товар, деньги, документ; незавершённую часть оставляет в очереди.

Результат: Возврат прослеживается по основаниям без двойного прихода.

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

  • Отсутствующий кассовый результат не исправляется повторным денежным возвратом.

Проверить период по кассе Эвотора

Задача: Разобрать пропуск документов по конкретному разрешённому устройству.

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

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

Результат: По одной разрешённой кассе видно, какие документы сопоставлены и какие требуют ручного разбора.

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

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

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

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

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

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

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

  • Организации, кассы и торговые точки с разрешённым доступом.
  • Подтверждённый клиентский интерфейс или образец доступного реестра.
  • Таблица связей заказ → платёж → кассовый документ и ответственный за каждый контур.
  • Для чтения через Эвотор — перечень разрешённых магазинов и устройств, приложение с подтверждёнными правами, образец продажи и возврата по конкретной кассе.
  • Если требуется передача третьему лицу — проверить доступность конкретного получателя и законное согласие в кабинете. Наличие инструкции не означает, что Skirbo уже подключён как получатель.
Границы сценария

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

  • Документы ЭДО Платформы ОФД не являются спецификацией API фискальных чеков.
  • Не подтверждены формирование чеков, webhook и автоматический мониторинг касс.
  • РФ: предметная сверка не заменяет определение обязанностей кассового учёта. Правила других стран не переносились.
  • Сведения из раздела «Чеки» и сводная аналитика могут отражать разные моменты обработки. Отсутствие строки в отчёте не разрешает повторить расчёт.
  • Ограниченный API через Эвотор не снимает вопрос универсального чтения касс личного кабинета. Покрытие возвратов, типы полей и права конкретного приложения требуют контрольного примера.
Стоимость и запуск

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

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

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

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

Можно выпускать чек прямо через ОФД?

Для этой карточки рассматривается получение и сверка фискальных данных. Формирование чека потребует отдельно подтверждённого кассового продукта.

Что делать, если чек не найден?

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

Можно найти чек только по сумме?

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

Если доступ к ОФД пропал, заказы станут неоплаченными?

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

Чем найденный API через Эвотор отличается от общего доступа к ОФД?

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

Статус ФНС означает, что деньги поступили продавцу?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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