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

Skirbo +
Эвотор

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

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

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

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

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

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

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

SKU, штрихкод, точка и единица измерения; общий и отдельный ассортимент не смешиваются.

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

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

Приёмка возвратаСклад → SkirboОбсудим в составе подключения

Количество, состояние и решение о доступности товара; кассовая запись не повторяет приход.

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

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

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

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

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

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

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

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

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

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

Возврат части продажи

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

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

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

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

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

  • Товар, появившийся в кассовой базе после возврата, не становится автоматически доступным складским остатком.
  • Нельзя обходить контур исходного приложения из-за неудобства сопоставления.

Несколько торговых точек и товарная база

Задача: Избежать ошибочного SKU при разных списках товаров.

Когда начинается: Один продавец использует несколько Эвоторов и складов.

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

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

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

  • Справка о товарной базе не подтверждает универсальное API изменения каталога.

Найти нужный чек для возврата

Задача: Разделить два вида номера и не возвратить чужую продажу.

Когда начинается: По обращению известен фискальный документ, но чек на терминале не найден.

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

Результат: Неверный номер не превращается в возврат случайного чека.

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

  • Совпадение суммы и даты без магазина и строк недостаточно.

Дочитать документы магазина после разрыва связи

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

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

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

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

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

  • Порядок возобновления и устойчивость идентификаторов необходимо подтвердить на клиентских примерах.
  • Получение PAYBACK не даёт права оформить новый возврат через другой контур.
  • Завершение cursor не означает полноту документов всего магазина: данные зависят от установок приложения и области доступа терминалов.

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

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

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

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

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

  • Перечень точек и устройств, источник формирования чека.
  • Сопоставление SKU/штрихкодов и обезличенный чек с частичным возвратом.
  • Правило раздельного подтверждения товарной приёмки, кассового результата и денежного возврата.
  • Установленное приложение и разрешённый токен пары приложение/пользователь, перечень доступных магазинов и выбранная версия API.
  • Обезличенные документы продажи, частичного возврата покупателя и, при наличии, возврата поставщику; проверка их разных значений.
  • Сверенный список ожидаемых и фактически доступных терминалов магазина: где приложение установлено и какие терминалы оплачены. Доступ к магазину не доказывает видимость всех его касс.
Границы сценария

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

  • Прочитан REST-метод чтения документов магазина. Создание возврата, запись каталога и webhook этим материалом не подтверждены.
  • Срок возврата денег из справки не обещается; подтверждение зависит от реального платёжного процесса.
  • Российский кассовый процесс не переносится на Казахстан и Узбекистан; маркированные товары требуют отдельной проверки по категории.
  • В перечне документов возврат товара от покупателя продавцу и возврат поставщику — разные типы; их нельзя объединять в одно складское действие.
  • API чтения магазина и отдельный путь данных Платформы ОФД имеют разные области доступа. Наличие одного не предоставляет другое.
  • Неустановленное приложение или несоответствие числа оплаченных терминалов может ограничить обмен и вызвать ошибку 402. Пропуск терминала не трактуется как отсутствие продаж.
Стоимость и запуск

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

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

Для оценки нужны одна точка Эвотора, источник формирования чека и обезличенный частичный возврат с физической приёмкой склада.

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

Возврат можно всегда сделать на терминале?

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

Почему номер фискального документа не находится как чек?

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

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

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

Это та же интеграция, что Платформа ОФД?

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

Почему возврат поставщику нельзя обработать как возврат покупателя?

API различает возврат товара продавцу от покупателя и возврат товара поставщику. У них разные основания и складские действия. Сам тип товарного документа не подтверждает денежное возмещение.

Достаточно токена одного магазина для всех клиентов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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