для разработчиков На сайт Rentu

Продажи по месяцам

Месячные итоги с посетителями и площадью. На PRO добавляются средний чек, выручка на м² и OCR.

GET /api/external/v2/sc/{sc_id}/reports/shops/{shop_id}/by_months   BASIC +PRO поля

Параметры#

ИмяТипОбяз.Описание
sc_id, shop_idstring, в путидаИдентификаторы центра и точки
start_datedateдаYYYY-MM-DD
end_datedateдаYYYY-MM-DD, не раньше start_date

Период расширяется до целых месяцев. Запрос с 10 мая по 20 июня вернёт май и июнь целиком. Тарифное ограничение при этом проверяется по исходным датам, а не по расширенным.

Пагинации нет: даже год это двенадцать строк.

Ответ#

Суммы в копейках, строки отсортированы по возрастанию месяца.

ПолеТипТарифОписание
datestringМесяц в формате YYYY-MM
receipts_countintegerВсего чеков за месяц
income_receipts_countintegerЧеков прихода
refund_receipts_countintegerЧеков возврата
income_sumintegerПриход, копейки
income_without_nds_sumintegerПриход без НДС, копейки
refund_sumintegerВозвраты, копейки
refund_without_nds_sumintegerВозвраты без НДС, копейки
manual_turnoverintegerЗадекларированный оборот офлайн-точки, копейки. 0, если точка на кассе
is_manualbooleanОборот внесён вручную, а не собран с кассы
visitorsintegerПосетители за месяц
area_sizenumberПлощадь точки, м²
is_outdoorbooleanТочка вне здания центра
average_check_sumintegerPROСредний чек, копейки
revenue_per_areaintegerPROВыручка на м², копейки
ocrnumberPROДоля аренды в товарообороте, проценты
turnoverintegerPROТоварооборот по настройкам центра, копейки
rentintegerPROНачисленная аренда за месяц, копейки

На Basic PRO-поля отсутствуют в объекте, а не приходят как null. Проверять нужно наличие ключа, а не значение.

Разница между turnover и manual_turnover в источнике. turnover считаем мы: берём чеки и применяем настройки центра, решающие, что делать с возвратами, НДС, авансами и корректировками. manual_turnover арендатор или центр вносит сам через сдачу товарооборота либо в интерфейсе Rentu.

is_manual показывает, что за этот месяц применяется внесённое вручную значение: именно оно идёт в расчёт OCR. О наличии кассы флаг ничего не говорит. Месяц может оказаться ручным и у точки с подключённой кассой. Тогда рядом с manual_turnover придут receipts_count, income_sum и остальные кассовые поля, и им можно верить.

У офлайн-точки кассовых полей просто нет. Нули в них означают, что данных неоткуда взять, а не что продаж не было.

json
{
  "success": true,
  "data": [
    {
      "date": "2026-05",
      "receipts_count": 8420,
      "income_receipts_count": 8380,
      "refund_receipts_count": 40,
      "income_sum": 128430000,
      "income_without_nds_sum": 107025000,
      "refund_sum": 214000,
      "refund_without_nds_sum": 178333,
      "manual_turnover": 0,
      "is_manual": false,
      "visitors": 51200,
      "area_size": 120.5,
      "is_outdoor": false,
      "average_check_sum": 15325,
      "revenue_per_area": 106500,
      "ocr": 12.5,
      "turnover": 128216000,
      "rent": 16027000
    }
  ]
}

Про revenue_per_area#

Считается как income_sum / area_size, то есть от выручки. Источник хранит результат целыми рублями, наружу он отдаётся в копейках: значение всегда кратно 100, дробная часть рубля отбрасывается. Для сравнения периодов эта потеря несущественна.

Для сверки берите ту же пару полей: поделите income_sum на area_size, отбросьте копейки, умножьте на 100. Через turnover результат не сойдётся: он учитывает настройки центра или подменяется ручным значением, и расхождение с выручкой доходит до десятков процентов.

Про average_check_sum#

Приходит из месячной агрегации и из полей той же строки не выводится: деление income_sum на income_receipts_count даёт другое число. Для сверки берите продажи по дням.

Ошибки#

Те же, что у продаж по дням: not_found, period_too_long, fresh_data_requires_pro, validation_error.