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

Skirbo +
LIFE PAY / LIFE POS

Связать складской заказ с sale/deal, оплатой и фискальным документом, чтобы изменяемое поле состояния продажи не становилось единственным основанием для выдачи.

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

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

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

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

org_guid + deal_guid, строки и версия; проданный товар сопоставляется с заказом.

Документ оплатыLIFE POS / платёжный контур → SkirboОбсудим в составе подключения

Проверить платёжный документ и transaction guid для выбранного способа расчёта.

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

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

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

Физические SKU, количества и состояние; не выводятся из Paid или Returned автоматически.

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

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

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

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

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

Прочитана инструкция управления продажами LIFE POS v5 и краткое описание авторизации v6. Версии не смешиваются: операции v5 требуют собственной проверки доступа, а выключенная OAuth-заготовка из v6 не используется как рабочая схема. Дополнительно исследована v6-модель продажи и чтения сессий; найдено расхождение кодов возврата в двух официальных разделах, требующее уточнения перед настройкой.

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

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

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

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

Готовый заказ и продажа на точке

Задача: Выдавать товар по проверенному расчёту, сохраняя три независимых факта.

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

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

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

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

  • В v5 состояние Paid можно установить изменением продажи; это само по себе не доказательство банковского списания.
  • Удаление/архивирование продажи не равно отмене платежа.

Частичный возврат

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

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

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

Результат: Частичный возврат товара не превращается в полную отмену продажи.

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

  • Смена состояния PartlyReturned не доказывает деньги и не заменяет приёмку.

Восстановление после разрыва связи

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

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

  1. Найти продажу по сохранённому org_guid/deal_guid и связанные документы/transaction guid.
  2. Прочитать историю с учётом архивированных объектов и сверить с фактом выдачи.
  3. Обновить прежнюю запись; новый расчёт инициировать только после подтверждённого отсутствия результата и согласования.

Результат: Потеря сетевого ответа не превращается во второй платёж.

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

  • Список только активных продаж может скрывать нужный архивный объект.

Проверка перехода на LIFE POS v6

Задача: Сохранить самостоятельные основания для оплаты, выдачи и возврата при смене модели продажи.

Когда начинается: Продавец выбирает подключение или переход на API v6.

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

Результат: Для v6 принят отдельный маппинг с проверяемыми финансовыми и складскими фактами.

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

  • Этот сценарий — критерий будущей приёмки; рабочая продажа или платёж в рамках исследования не создавались.
  • Коды v5 PartlyReturned и v6 PartiallyReturned/PartiallyRefunded не приравниваются автоматически.

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

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

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

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

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

  • Точный продукт LIFE POS/LIFE PAY и версия интерфейса, организация и точки расчёта.
  • Таблица org_guid/deal_guid, SKU и документов оплаты/фискализации.
  • Порядок действий при разрыве связи, частичном возврате и архивной продаже.
Границы сценария

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

  • v5-операции продаж и v6-страница доступа не доказывают взаимозаменяемость версий.
  • Paid может быть установлен редактированием; архивирование обратимо и не является отменой расчёта.
  • Кассовые и маркировочные правила оцениваются отдельно для РФ; не переносятся на Казахстан и Узбекистан.
  • В v6 руководство и справочник ListSale расходятся в кодах возврата shipping_status. До проверки поставщиком и на тестовой продаже автоматическое сопоставление этих кодов не принимается.
  • Перечень валют или стран в схеме не подтверждает договорное обслуживание организации за пределами РФ.
Стоимость и запуск

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

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

Выберите конкретный продукт и точку LIFE PAY/LIFE POS: нужны обезличенные sale/deal, документ оплаты, чек и пример частичного возврата.

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

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

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

Что делать, если терминал подтвердил платёж без связи со складом?

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

Почему недостаточно статуса Paid?

В прочитанном API состояние продажи может изменяться запросом. Поэтому для выдачи нужен проверенный платёжный документ и принятая клиентом схема подтверждения.

Можно отменить платёж, удалив продажу?

Описанное удаление архивирует объект и связанные данные. Архивирование не доказывает отмену оплаты или возврат денег; эти операции проверяют в соответствующем продукте.

Можно переключить интеграцию с v5 на v6 заменой адреса?

Такой переход требует отдельного сопоставления. У v5 есть общий жизненный цикл сделки и документы оплаты; v6 разделяет состояние продажи, оплаты и отгрузки и описывает сессии. Нужно сравнить одну продажу, частичную оплату и возврат в выбранной версии.

Почему код возврата товара нужно проверить до запуска?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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