Чеки

Параметры#

Две пары дат#

Нужна как минимум одна полная пара. Половина пары без второй полной даёт 422.

• created: когда чек пробит на кассе. Это то, что нужно для отчётности за период.
• received: когда чек дошёл до нас. Это то, что нужно для дозагрузки, потому что чек мог быть пробит вчера, а прийти сегодня из-за офлайн-режима кассы.

Если заданы обе пары, они применяются одновременно: «пробит в этом окне и получен в том».

Типы документов#

shift_opening_report, report_on_the_current_state_of_settlements, receipt, correction_receipt, delivery, form_of_strict_accountability, correction_strict_reporting_form, shift_closing_report.

По умолчанию отдаются только продажи: receipt, delivery и БСО. Служебные документы вроде открытия смены запрашиваются явно. Принимаются обе формы записи: document_types=receipt,delivery и document_types[]=receipt&document_types[]=delivery.

Ответ#

Суммы в копейках. Сортировка по возрастанию того времени, по которому вы фильтруете: по времени пробития, если задана пара created, и по времени поступления, если задана только пара received.

Позиции чека#

По умолчанию в ответе только items_count. Состав запрашивается явно:

?include=items

Так сделано из-за объёма: при per_page=1000 чеки с позициями весят в разы больше, и платить за это тем, кому нужны только итоги, неправильно.

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

"items": [
  { "quantity": 2, "price": 39525, "sum": 79050 },
  { "quantity": 0.437, "price": 100000, "sum": 43700 }
]

{
  "success": true,
  "data": [
    {
      "id": "6686000000000000000004a1",
      "document_type": "receipt",
      "created_datetime": "2026-07-01T00:30:00+03:00",
      "received_datetime": "2026-07-01T00:31:12+03:00",
      "kkt_id": "6512a3000000000000000201",
      "kkt_reg_id": "0000123456789012",
      "kkt_serial_number": "00107801234567",
      "kkt_fiscal_drive_number": "9289000100123456",
      "fiscal_document_number": 10245,
      "shift_number": 312,
      "shift_check_number": 7,
      "operation_type": 1,
      "total_sum": 149900,
      "cash_sum": 0,
      "ecash_sum": 149900,
      "nds_20_sum": 24983,
      "items_count": 3,
      "items": [
        { "quantity": 1, "price": 79900, "sum": 79900 },
        { "quantity": 2, "price": 35000, "sum": 70000 }
      ]
    }
  ],
  "meta": {
    "pagination": {
      "page": 1,
      "per_page": 500,
      "total": 8412
    },
    "time_zone": "Europe/Moscow"
  }
}

Практика#

Границы суток считаются в зоне центра. Чек, пробитый в 00:30 по Москве, попадёт в первое июля, а не в тридцатое июня. Именно поэтому в примере выше первая строка — половина первого ночи.

Дозагрузку стоит фильтровать по received. Касса могла работать офлайн и передать чеки с задержкой в несколько дней. Периодический запрос по created их пропустит, по received заберёт.

Ограничивать её парой created не стоит. Задержки бывают большими: из чеков, поступающих за сутки, около 9 % пробиты больше недели назад, а 4–5 % — больше месяца. Окно по времени пробития, поставленное «с запасом», такие чеки отрежет. Запрашивайте одну пару received.

received — время последнего изменения записи. Пересчёт или уточнение данных сдвигает его вперёд, и чек приходит в выгрузку повторно, уже с исправленными суммами. Поэтому инкрементальную загрузку стоит строить на обновлении по id: повторный id означает, что данные уточнились, а не что пришёл новый чек.

У части касс сбиты часы, и время пробития оказывается впереди времени поступления. При выгрузке по created такие чеки попадают в другие сутки, чем ожидает арендатор; по received они приходят на своё место.

Ошибки#