Статусы от банка до ФНС¶

Главная ошибка в фискализации - считать один успешный ответ финальным статусом всей цепочки. В реальности каждый слой подтверждает только свой участок.

Цепочка статусов¶

Слой	Что подтверждает	Что не подтверждает
Платежный шлюз	Платежное событие и прием фискальных данных в API банка	Что касса сформировала ФД и ФНС его приняла.
Кассовый провайдер, регистрация	Задание принято, обычно есть `uuid`	Что чек уже фискализирован.
Кассовый провайдер, report	Итог обработки задания кассой	Что публичная витрина ОФД покажет все ожидаемые поля.
ККТ и ФН	Фискальный документ сформирован и подписан	Что документ уже прошел весь путь до ФНС.
ОФД	Документ принят ОФД и может отображаться на публичной странице	Что ФНС не отправила документ в карантин.
ФНС	Финальный форматно-логический контроль	Что мерчант правильно выбрал бизнес-сценарий.

Принят и зарегистрирован¶

В интеграциях нужно различать два состояния:

Состояние	Практический смысл
Принят	Провайдер получил задание и вернул идентификатор.
Зарегистрирован	Report вернул успешный результат с фискальными реквизитами.

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

Почему ссылка ОФД не финальный источник¶

ОФД обычно показывает человекочитаемую страницу чека. Это не полная техническая модель ФФД. Часть реквизитов может быть в фискальном документе, но не отображаться на витрине. Обратная ситуация тоже возможна: публичная страница открывается, но вопрос ФНС-статуса или карантина остается отдельным.

Рабочий порядок проверки¶

Найти бизнес-событие: продажа, предоплата, зачет, возврат, коррекция.
Проверить payload, который ушел в банк или кассовый сервис.
Найти ответ регистрации и uuid.
Получить report.
Сверить фискальные реквизиты: номер ФН, ФД, ФП, сумма, тип оплаты, позиции, СНО.
Проверить ОФД только как отображение и маршрут передачи, а не как единственный источник всех тегов.
При признаках карантина проверять финальный статус в доступном кабинете ОФД/ФНС.