Матрица ошибок провайдеров¶
Эта страница переводит технические ошибки кассовых сервисов на язык поддержки и интеграции. Она не заменяет логи и API-отчеты, но помогает быстро понять класс проблемы: авторизация, структура чека, касса, ожидание статуса или неподдержанный сценарий.
Как читать ошибку¶
| Класс | Что обычно означает | Первое действие |
|---|---|---|
| Авторизация | Неверный или просроченный токен, неправильный контур, ошибка доступа. | Проверить контур, учетные данные и способ передачи токена. |
| Структура чека | Провайдер не принял payload: сумма, тип поля, enum, обязательный реквизит. | Сверить payload с версией ФФД и требованиями провайдера. |
| Касса или драйвер | Задание принято, но ККТ или кассовый сервис не смогли сформировать чек. | Смотреть итоговый статус, сообщение драйвера и повторяемость. |
| Ожидание статуса | Провайдер еще не отдал финальный результат. | Подождать в пределах регламента и повторить запрос статуса. |
| Неподдержанный сценарий | Операция не работает у выбранного провайдера или версии ФФД. | Выбрать другой сценарий или провайдера; не маскировать ошибку повтором. |
Сводка по провайдерам¶
| Провайдер | Что видно в тестах | Риск для поддержки |
|---|---|---|
| АТОЛ Онлайн | Хорошо различает часть структурных ошибок, особенно в ФФД 1.2. Иногда итоговая ошибка приходит без детального идентификатора. | Нельзя останавливаться на факте регистрации: нужен финальный статус. |
| Эвотор | В ФФД 1.05 разные причины могут выглядеть как одна системная ошибка; ФФД 1.2 дает больше деталей. | Нужно проверять обязательность кассира и версию партнерского API. |
| Ferma / OFD.RU | Часть ошибок приходит обобщенно, без удобной классификации. | Нужна осторожная трактовка: generic-ошибка не говорит, какой реквизит сломан. |
| Бизнес.Ру | Самые подробные ошибки структуры payload на регистрации. | Ошибка часто точная, но требует читать тип поля и допустимые значения. |
Типовые ситуации¶
Чек не принят на регистрации¶
Это обычно проблема входного чека: неверная сумма, тип поля, признак предмета расчета, ставка НДС, контакт покупателя или обязательный реквизит. Для ФФД 1.2 такие ошибки чаще всплывают сразу.
Что проверить:
- версия ФФД и API-версия провайдера;
- сумма по позициям и сумма оплаты;
- типы enum: строка или число;
- обязательность кассира, email/телефона, признаков агента, маркировки;
- нет ли лишних полей, которые провайдер запрещает.
Задание принято, но итог неуспешен¶
Регистрация не равна фискализации. Если провайдер принял задание, но финальный статус неуспешен, нужно смотреть уже не только payload, но и состояние ККТ, драйвера, ФН, очереди и доступности контура.
Что проверить:
- есть ли финальный статус или только ожидание;
- повторяется ли ошибка на базовом чеке;
- затрагивает ли она один провайдер или все контуры;
- есть ли отклонение от ежедневного healthcheck.
Долго нет финального статуса¶
Короткое ожидание статуса нормально: кассовый сервис может обрабатывать чек асинхронно. Риск появляется, когда ожидание выходит за обычный профиль провайдера или не завершается повторно.
Для поддержки важно не создавать повторный чек вслепую. Сначала нужно понять, был ли исходный чек фискализирован.
Ошибка в коррекции¶
Коррекция не является универсальным повтором. Ошибка в коррекции может означать, что провайдер не поддерживает операцию, требует полный состав позиций, требует кассира или не принимает выбранную модель для этой версии ФФД.
Перед эскалацией нужно собрать: провайдер, ФФД, тип коррекции, основание, дата, сумма, позиции, исходный чек и финальный статус.
Что не выводить из ошибок¶
- Подробная ошибка провайдера не доказывает юридическую корректность альтернативного payload.
- Обобщенная ошибка не доказывает, что реквизиты были корректны.
- Успешный test-контур не равен production SLA.
- Отсутствие поля на ОФД-витрине не равно отсутствию ФФД-тега в фискальном документе.