пиот и облачная касса — ПИОТ и облачную кассу связывают с 1С, когда заказ создаётся на сайте или в CRM, оплату подтверждает платёжный сервис, а продажи и возвраты ведутся в учётной системе. Задача интеграции — не «автоматически пробивать чеки», а сопоставить каждую стадию расчёта с одним кассовым действием и не допустить дублей.
ПИОТ в этой схеме — платформа интеграции онлайн-торговли: она передаёт события и данные между сайтом, платёжным сервисом, 1С и кассой. Кассовый контур — это ККТ, фискальный накопитель, ОФД и журнал, в котором видны результаты обработки фискальных документов.
Подключайте связку, если менеджеры не должны вручную создавать чеки по интернет-заказам, а в 1С требуется видеть продажи, предоплаты и возвраты. Сайт или приложение передаёт заказ, платёжный сервис сообщает результат оплаты, а интеграция отправляет в кассовый контур данные именно того расчёта, который произошёл.
Сразу назначьте единственный источник кассового события. Например, сайт не должен отправлять команду в кассу, если её уже отправляет обработка 1С по тому же платёжному идентификатору. Защита от дублей строится на сохранении идентификаторов заказа, платежа и кассовой операции.
Облачную ККТ используют для дистанционных расчётов, если это соответствует модели работы бизнеса и настройкам регистрации кассы. Для расчётов в торговой точке нужна ККТ, подходящая для этого сценария; один и тот же расчёт не следует проводить одновременно через стационарную и облачную кассу. Подробные критерии собраны в материале «Облачная касса для бизнеса: выбор, запуск и типовые ошибки».
Применение ККТ регулирует Закон № 54-ФЗ. Официальные сервисы и материалы по кассовой технике размещены на сайте ФНС России.
Статус «оплачен» сам по себе не говорит, какой кассовый документ нужен. Он может означать предоплату, полный расчёт или доплату. Поэтому до настройки составьте матрицу: событие → фактическая стадия расчёта → документ 1С → кассовое действие → идентификатор операции.
| Событие | Что произошло фактически | Что настроить | Контроль |
|---|---|---|---|
| Успешная оплата до передачи товара или услуги | Предоплата | Отдельное кассовое действие и документ 1С для предоплаты | Сумма, состав позиций, ID платежа |
| Передача товара или оказание услуги после предоплаты | Зачёт ранее внесённой предоплаты | Отдельное событие из отгрузки или акта, если оно предусмотрено вашей схемой | Связь с исходной предоплатой |
| Оплата при передаче товара или оказании услуги | Полный расчёт | Кассовое действие по событию фактического расчёта | Заказ, платёж, позиции и скидки |
| Покупатель вносит остаток суммы | Доплата | Отдельная команда с суммой доплаты и связью с заказом | Исключить повтор предоплаты |
| Успешное рекуррентное списание | Оплата услуги по условиям подписки | Передавать состав услуги и параметры расчёта, заданные схемой подписки | Подтверждение списания и уникальный ID операции |
| Возврат денег | Полный или частичный возврат | Документ возврата с позициями и суммой возврата | Связь с исходной продажей, отсутствие нового чека продажи |
Не копируйте эту матрицу механически: состав позиций, признаки расчёта и последовательность действий зависят от того, когда бизнес получает деньги и исполняет обязательство. Но сами события должны быть разнесены — это устраняет главную причину неверных чеков в сложных схемах.
Интернет-магазин с полной онлайн-оплатой. Корзина и скидки окончательно формируются на сайте, платёж подтверждается эквайрингом, а заказ попадает в 1С. В качестве источника кассового события выбирайте одну систему: либо обработку в 1С после получения подтверждённого платежа, либо API сайта. Второй канал отправки отключите.
Сервис с предоплатой и доплатой. Создайте разные статусы и документы для предоплаты, зачёта и доплаты. Не объединяйте эти операции одним статусом «оплачен», иначе интеграция потеряет стадию расчёта.
Подписка. После успешного регулярного списания отправляйте данные в кассу по матрице подписки. Перед запуском проверьте, какие услуги, периоды, суммы и стадии расчёта передаются в каждом цикле, а не только факт списания.
Несколько витрин или организаций. В заказе должны определяться организация, договор и кассовый контур. Проверьте это на каждой витрине и для каждого способа оплаты: ошибка здесь приводит к оформлению документа не от того пользователя ККТ.
Если приём платежей ещё не настроен, начните с выбора платёжного решения: как подключить онлайн-эквайринг и выбрать тариф. Для выбора формата сайта с каталогом, корзиной и оплатой используйте материал о сайте с онлайн-оплатой и кассой.
| Вариант | Кому подходит | Запуск и разработка | Ручные операции | Возвраты и несколько юрлиц |
|---|---|---|---|---|
| Обмен через 1С | Бизнесу, где финальные продажи и возвраты оформляют в 1С | Быстрее при совместимом модуле; доработка нужна при нестандартных документах | Минимум после настройки, если сотрудники работают в 1С | Подходит, если обмен поддерживает частичные возвраты и выбор организации |
| API ПИОТ | Сервису с собственной CMS, CRM или личным кабинетом | Требуется разработчик; срок зависит от готовности событий и API | Минимум, если события оплат и возвратов автоматизированы | Гибко настраивается, но ответственность за логику лежит на разработке |
| Готовый модуль CMS | Типовому магазину на поддерживаемой CMS | Самый быстрый старт без программирования при полной совместимости | Обычно минимум для типовой продажи | До установки отдельно проверьте частичный возврат, предоплаты и несколько организаций |
Выбирайте обмен через 1С, если именно там создаются окончательные документы продажи и возврата. API выгоднее, когда логика живёт в собственной разработке и требуется контролировать каждое событие. Модуль CMS подходит для типового магазина, но его нельзя считать готовым решением, пока не проверены ваши оплаты, возвраты и версия CMS.
Контролируйте не только отправку команды, но и результат фискализации. В журнале должны быть видны статус принятия документа кассой и ОФД, номер фискального документа (ФД), фискальный признак (ФП), время обработки и текст ошибки при отказе.
Один статус используют для всех оплат. Предоплата, доплата и полный расчёт превращаются в одно событие. Решение: вести матрицу событий и настроить отдельное действие для каждой стадии.
Повторно отправляют запрос после тайм-аута. Первая команда могла уже дойти до кассы, а вторая создаст дубль. Решение: искать операцию по исходному идентификатору и повторять запрос только с тем же ключом идемпотентности.
Проверяют только факт отправки. Команда ушла из 1С, но документ мог быть отклонён или остаться в очереди. Решение: контролировать итоговый статус, номер ФД и ФП, а не только запись об отправке.
Оставляют возвраты «на потом». Деньги возвращают, а кассовая операция не создаётся или превращается в повторную продажу. Решение: тестировать полный и частичный возврат до включения боевого потока.
Не назначают владельца ошибок. Платёж и чек расходятся, пока продажи, бухгалтерия и разработка ждут друг друга. Решение: закрепить сотрудника, доступ к журналу и порядок эскалации.
Перед обращением подготовьте схему заказа, список статусов, используемую конфигурацию 1С и по одному примеру продажи, предоплаты, доплаты и возврата. Этого достаточно, чтобы разобрать, где возникает расчёт и какой канал должен отправлять кассовую команду.
Оставьте заявку на проверку схемы интеграции. Специалисты Интернет Касса разберут ваш путь заказа и оплаты, отметят риск дублей, подготовят матрицу событий и список тестов для запуска. По итогам вы получите понятный план: что настраивается модулем, что требует доработки и какие операции нужно проверить до приёма реальных оплат.
Да, если ваша конфигурация 1С и готовый модуль поддерживают нужные документы, оплаты и возвраты. Для подписок, нескольких организаций, нестандартных предоплат и доработанной 1С потребуется настройка обмена или интеграция через API.
Нет, сначала определите фактическую стадию расчёта в вашей схеме. Подтверждённая оплата может означать предоплату, полный расчёт или доплату; зачёт предоплаты при передаче товара или оказании услуги настраивается отдельным событием.
Да, протестируйте полный и частичный возврат по каждому доступному способу оплаты. Проверьте, что операция создаёт документ возврата, сохраняет связь с исходным заказом и не повторяет чек продажи.
Нет, сначала проведите тестовые операции или ограниченный запуск на нескольких заказах. До массового приёма оплат сверяйте заказ, платёж, документ 1С, статус фискализации, номер ФД и ФП.
Повторите идемпотентный запрос с тем же идентификатором операции после проверки статуса в журнале интеграции. Не создавайте новый запрос с новым идентификатором, пока не исключили успешную обработку первого.
Назначьте одного владельца очереди ошибок внутри компании. Он должен видеть номер заказа, платёжный идентификатор, статус кассы и ОФД, текст ошибки и срок эскалации в поддержку.