Реквизиты чека: состав и справочники

Здесь — полный состав объекта receipt (для чеков коррекции он называется correction) и все справочники значений, которые принимает API кассового сервера. Всё, что описано ниже, проверяется на приёме: непрошедший проверку чек возвращает ошибку 32, и текст ошибки называет конкретное поле.

1. Каркас#

{
  "client":   { "email": "buyer@example.com" },
  "company":  { "email": "shop@example.com", "sno": "usn_income",
                "inn": "7736570901", "payment_address": "https://shop.example" },
  "items":    [ /* 1…100 позиций */ ],
  "payments": [ /* минимум одна оплата */ ],
  "vats":     [ { "type": "vat20", "sum": 416.67 } ],
  "total": 2500.00,
  "cashier": "Иванов И.И.",
  "cashier_inn": "123456789047",
  "additional_check_props": "Заказ №10421",
  "additional_user_props": { "name": "Менеджер", "value": "Петров" },
  "internet": true,
  "device_number": "web-1"
}

Обязательный минимум: client (для операций-продаж), company, items, payments, total.

Денежные правила#

Суммы передаются числами, не строками. Позиция считается как price × quantity, но итог позиции берётся из sum — если у вас скидка на позицию, кладите в sum фактическую стоимость.

2. client — покупатель#

Для интернет-расчёта чек всегда электронный, поэтому нужен адрес доставки чека: минимум одно из email / phone. Если заданы оба, ОФД отправит чек на e-mail.

Расширенные реквизиты (name…address) нужны в отдельных отраслевых случаях — обычному интернет-магазину достаточно email или phone. Их поддержка зависит от модели кассы: если ККТ их не умеет, документ вернётся с ошибкой драйвера — текстом самой кассы (например: «реквизиты покупателя (теги 1227/1228/1008/1256)… не поддерживаются»), без отдельного кода ошибки.

3. company — продавец#

ИНН обязан совпадать с ИНН, на который зарегистрирован ФН вашей кассы. Несовпадение отклоняется сразу при регистрации: HTTP 400, ошибка 32, текст называет оба ИНН — чека и группы. Документ в очередь не попадает.

Системы налогообложения (sno)#

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

4. items — позиции#

{
  "name": "Кофе в зёрнах, 1 кг",
  "price": 1250.00,
  "quantity": 2,
  "sum": 2500.00,
  "measure": 11,
  "payment_method": "full_payment",
  "payment_object": 1,
  "vat": { "type": "vat20" },
  "user_data": "Артикул A-100"
}

Признак способа расчёта (payment_method)#

Признак предмета расчёта (payment_object, v5 — число)#

Обычный товар интернет-магазина — код 1; услуга — 4; маркируемый товар со сканированным кодом — 33.

В протоколе v4 то же поле передаётся строкой (commodity, service, job, payment, agent_commission, another и т. д.) — исторические имена v4 принимаются и приводятся к современной таблице автоматически.

Единица измерения (measure, v5 — число)#

В v4 вместо кода передаётся строка measurement_unit («шт», «кг», «л», «час»); нераспознанная строка приводится к «иной единице».

Ставки НДС (vat.type)#

Расчётные ставки применяются к суммам, в которых налог уже «сидит» внутри, — например к авансам и предоплатам.

Ставки 22 % и 22/122 требуют кассы с прошивкой, знающей новую ставку. Часть моделей старых поколений её физически не принимает — уточните у своего ЦТО.

5. payments — оплаты#

"payments": [ { "type": 1, "sum": 2500.00 } ]

Оплат может быть несколько, их сумма обязана совпадать с total; своего лимита на число оплат сервис не ставит — ограничение задаёт сама ККТ и формат фискальных документов. Для интернет-магазина, принимающего оплату картой на сайте, это всегда {"type": 1, "sum": <итог>}.

6. vats — сводные ставки#

Необязательный блок: сводка по НДС на весь чек ([{ "type": "vat20", "sum": 416.67 }]). Если не передан, касса посчитает налоги по позициям сама.

7. Маркировка#

Код маркировки передаётся ровно одним полем-форматом:

"payment_object": 33,
"mark_code": { "gs1m": "MDEwNDYwNzQyODY3OTA5MDIxOU..." },
"mark_quantity": { "numerator": 1, "denominator": 2 }

mark_quantity (дробная продажа маркированного товара) допускается только вместе с кодом маркировки. В протоколе v4 вместо mark_code используется nomenclature_code — hex-строка.

Важно. Код маркировки передаётся в вашу кассу как есть: проверку кода в «Честном знаке» и разрешительный режим (ТС ПИоТ) сервис не выполняет. Если ваш товар подлежит разрешительному режиму, проверку нужно выполнять до отправки чека — на стороне вашей учётной системы или кассового ПО.

8. Агентская схема#

Когда вы продаёте товар принципала (маркетплейс, платёжный агент, комиссионер), позиция дополняется двумя блоками:

"agent_info": { "type": "commission_agent" },
"supplier_info": { "name": "ООО Поставщик", "inn": "7736570901", "phones": ["+79001234567"] }

supplier_info с корректным ИНН обязателен, если задан agent_info, — иначе чек не пройдёт валидацию. Для платёжных агентов дополнительно заполняются телефоны оператора приёма платежей и данные оператора перевода внутри agent_info.

9. Прочие реквизиты чека#

10. Чек коррекции#

Для операций *_correction тело документа передаётся в корне correction, а основание — в correction_info:

{
  "timestamp": "04.08.2026 15:00:00",
  "external_id": "corr-10421",
  "correction_info": { "type": "self", "base_date": "03.08.2026", "base_number": "1" },
  "correction": {
    "company": { "sno": "usn_income", "inn": "7736570901", "payment_address": "https://shop.example" },
    "items": [ /* как в обычном чеке */ ],
    "payments": [ { "type": 1, "sum": 2500.00 } ],
    "total": 2500.00
  }
}

• correction_info.type: self — самостоятельно, instruction — по предписанию налогового органа.
• base_date обязателен всегда, base_number — обязателен при instruction.
• Блок client в коррекции не обязателен.

Когда какой чек коррекции нужен по закону — в справочнике Чек коррекции и разборе типовых ситуаций рядом с ним.

Дальше: сценарии интернет-магазина · ошибки и диагностика · справочник API.