ФФД и теги¶
ФФД — формат фискальных документов. Он задает не внешний вид чека, а состав и правила реквизитов: какие теги существуют, когда они обязательны, в какой форме передаются и как входят в фискальный документ.
Основной официальный источник — приказ ФНС России от 14.09.2020 № ЕД-7-20/662@ и приложения к нему. При споре между API-полем провайдера и ФФД сначала проверяется ФФД, затем документация провайдера и свежий API-прогон.
Зачем ФФД интегратору¶
| Вопрос | Как помогает ФФД |
|---|---|
| Какой чек нужен | Через тип документа, признак расчета и способ расчета. |
| Какие поля обязательны | Через атрибут обязательности: 1, 2, 3 или условия П/Э. |
| Можно ли не передавать поле | Только если это допускает ФФД и контракт провайдера. |
| Почему ОФД не показывает реквизит | Публичная витрина ОФД не равна полной электронной форме ФД. |
| Почему провайдеры ведут себя по-разному | Каждый API маппит свои поля на ФФД и валидирует их по-своему. |
Версии¶
| Версия | Где встречается в интеграциях | Что важно |
|---|---|---|
| 1.05 | Старые и совместимые контуры, например АТОЛ v4 и часть банковских маппингов. | Базовая модель онлайн-касс, ОФД и фискального накопителя. |
| 1.1 | Может встречаться как внутренняя версия у отдельных провайдеров или при маппинге. | Не надо механически называть ее 1.05 или 1.2 без проверки контракта. |
| 1.2 | Актуальная практическая версия для маркировки и расширенного состава реквизитов. | Больше требований к маркированным товарам, отраслевым реквизитам и электронному составу. |
ФФД 1.05, 1.1 и 1.2 живут в одной нормативной линии приказа и его редакций. Для сайта важна не история редакций сама по себе, а то, какая версия включена в конкретном кассовом контуре и как провайдер принимает payload.
Обязательность реквизитов¶
| Обозначение | Смысл |
|---|---|
| 1 | Реквизит обязателен. |
| 2 | Реквизит условно обязателен: нужен при условиях из примечаний ФФД. |
| 3 | Реквизит необязателен. |
| П | Требование для печатной формы. |
| Э | Требование для электронной формы. |
Важно: если тег обязателен в электронной форме, это не значит, что публичная страница ОФД обязана вывести его отдельной строкой. Проверка поля на витрине ОФД — отдельная задача.
Ключевые теги¶
Признак способа расчета, тег 1214¶
| Значение | Смысл |
|---|---|
| 1 | Полная предварительная оплата до передачи предмета расчета. |
| 2 | Частичная предварительная оплата до передачи. |
| 3 | Аванс, когда предмет расчета или его состав еще не определен окончательно. |
| 4 | Полный расчет, включая зачет ранее внесенной предоплаты/аванса. |
| 5 | Частичный расчет и кредит. |
| 6 | Передача в кредит. |
| 7 | Оплата кредита. |
Для e-commerce чаще всего спорят о границе между авансом, предоплатой и полным расчетом. Решение зависит от бизнес-события: известен ли состав товара, передан ли товар, происходит ли только списание денег или уже поставка.
Признак предмета расчета, тег 1212¶
Тег 1212 описывает, что именно продается или отражается в позиции: товар, подакцизный товар, работа, услуга, платеж, агентское вознаграждение, иной предмет и т.д. Для агентских схем и маркетплейсов это один из ключевых тегов: позиция поставщика и агентское вознаграждение не должны сливаться в один смысл.
Суммы оплат¶
Суммы оплат раскрываются отдельными тегами: 1031 наличные, 1081 безналичные, 1215 зачет аванса/предоплата, 1216 постоплата/кредит, 1217 встречное предоставление. API-блок payments у провайдера — это контейнер, а не один тег ФФД.
Cashless payments¶
В документации АТОЛ v4 cashless_payments — API-блок для сведений о безналичной оплате; сумма внутри него связана с тегом 1082. Поэтому нельзя писать, что весь блок cashless_payments является тегом 1082. Для BNPL и сверки банковских транзакций с кассовыми чеками этот блок важен именно как связь фискального документа с реальной безналичной операцией.
НДС¶
Суммы НДС по чеку раскрываются тегами 1102, 1103, 1106, 1107 и другими ставками. Блок taxes у провайдера — API-контейнер. При проверке ОФД нельзя делать вывод “НДС потерян” только потому, что конкретная витрина не вывела налоговый блок в ожидаемом месте.
Маркировка¶
ФФД 1.2 добавляет расширенный состав реквизитов для маркированных товаров и обмена с ОИСМ. Для маркировки недостаточно передать название товара и Data Matrix: нужно учитывать товарную группу, разрешительный режим, результат проверки и ограничения канала продажи.
Связь с API провайдеров¶
| Провайдер | Практическое отличие |
|---|---|
| АТОЛ Онлайн | В v5 строже валидирует ФФД 1.2 и может отвергать лишние поля в receipt. |
| Эвотор | В 1.05 часть разных ошибок возвращается как общий системный сбой, в 1.2 чаще появляются более предметные driver-коды. |
| Ferma / OFD.RU | Часть ошибок возвращается generic-кодами или пустым error envelope; токен передается в query. |
| Бизнес.Ру | Подробно валидирует JSON-schema; типы некоторых полей отличаются между v4/1.05 и v5/1.2. |
Вывод для интегратора: ФФД задает нормативную модель, но финальная проверка всегда делается на конкретном провайдере и версии API.