---
metadata:
  - name: generator
    content: Diplodoc Platform v5.63.4
style:
  - _style/main.css
vcsPath: analytics/analytics-orders.md
alternate:
  - href: https://help.curs24.online/analytics/analytics-orders.md
    type: text/markdown
    title: Markdown version
  - href: https://help.curs24.online/llms.txt
    rel: describedby
---
# Отчёты по заказам

Два пункта меню отвечают на главный денежный вопрос: **сколько мы заработали на заказах и на чём именно.**

- **«Отчёты по заказам»** — сколько набрали, сдали или потеряли за период и что осталось после затрат.
- **«Отчёт по типам изделий»** — какие типы изделий приносят деньги, а какие только занимают производство.

{% note info %}

Оба отчёта доступны только роли **«Собственник»**.

{% endnote %}

## Отчёты по заказам

![экран «Отчёты по заказам»](../_assets/images/analytics/analytics_orders.png)

### Отборы

| Отбор | Что делает |
|---|---|
| **«Период оформления»** | Границы отчёта. По умолчанию текущий месяц |
| **«Точка продаж»** | Одна точка или **«Все точки продаж»** |
| **«Ответственный сотрудник»** | Один менеджер или **«Все сотрудники»** |
| **«Показать»** | **«Принятые»**, **«Сданные»** или **«Отмененные»** |

{% note warning %}

**Отбор «Показать» меняет не только состав заказов, но и смысл периода.**

- **«Принятые»** — заказы, взятые в работу, **по дате оформления**. Расчёты и отменённые заказы не в счёт.
- **«Сданные»** — заказы, закрытые в статусе «Сдан», **по фактической дате сдачи**.
- **«Отмененные»** — отклонённые заказы, тоже по дате закрытия.

Поэтому один и тот же заказ может попасть в сентябрьские «принятые» и в ноябрьские «сданные». Это не ошибка: набор и сдача — разные события, и мерить их одной датой нельзя.

{% endnote %}

### Три кнопки — три глубины

Отбор один, а построить можно три разных документа.

**«Краткий отчёт»** — таблица заказов: **«Номер заказа»**, **«Дата»**, **«Дата закрытия»**, **«Клиент»**, **«Проект»**, **«Источник клиента»**, **«Дизайнер»**, **«Статус заказа»**, **«Сумма заказа»**, **«Оплачено»**, **«Форма оплаты»**, **«Затраты»**, **«Прибыль»**, **«Рен-сть,%»**.

В столбце **«Форма оплаты»** видно, чем платил клиент. Прошло несколько оплат разными формами — они перечислены через запятую. Платежи со статусом **«Черновик»** в отчёт не идут, как и в столбец **«Оплачено»**.

Сверху — итоги за период: **«Кол-во заказов»**, **«Сумма заказов»**, **«Средний чек»**, **«Общая прибыль»**, **«Средняя прибыль»**, **«Рентабельность, %»**. Обычно смотрят именно их, а таблица нужна, чтобы найти заказ, выбивающийся из ряда.

**«Расширенный отчёт»** — те же итоги, но каждый заказ разложен до изделия и до отдельной позиции: наименование, количество, цена, скидка, наценка, стоимость, затраты, прибыль и рентабельность по каждому товару и услуге.

Сюда приходят с вопросом «почему на этом заказе мы почти ничего не заработали». Ответ виден строкой: позиция, купленная дороже, чем закладывали, или услуга, проданная со скидкой.

**«Сводный отчёт»** — кросс-таблица: заказы в столбцах, товары и услуги в строках, и по каждой позиции три показателя — **«Доход»**, **«Расход»**, **«Прибыль»**. Нужен, когда сравниваете несколько заказов между собой.

{% note info %}

Средний чек и рентабельность считаются по заказам, попавшим в отчёт. Сузили отбор до одного менеджера — цифры станут его, а не компании.

{% endnote %}

Откуда берутся «Затраты» — это закупочные цены товаров, транспортные расходы и себестоимость услуг по заказу. Если по заказу не заполнили цену закупа, затраты окажутся заниженными, а прибыль — завышенной: [«Комплектация заказов»](../purchase/purchase.md).

## Отчёт по типам изделий

Заголовок экрана — **«Отчёт по проданным типам изделий»**.

Отборы те же: **«Период оформления»**, **«Точка продаж»**, **«Ответственный сотрудник»**. Кнопка одна — **«Сформировать»**.

Колонки: **«Тип изделия»**, **«Продано изделий»**, **«% от продаж»**, **«Доход»**, **«Расход»**, **«Прибыль»**, **«Рен-сть,%»**, **«Средний чек»**.

Отчёт отвечает на вопрос, который в потоке заказов не виден: **на чём вы на самом деле зарабатываете.** Часто выясняется, что самый ходовой тип изделия даёт мало прибыли, а редкий и «неудобный» — наоборот. После этого разговор с менеджерами о том, что предлагать клиенту, становится предметным.

{% note info %}

В отчёт попадают изделия заказов, **оформленных в периоде** и дошедших дальше стадии расчёта. Изделия из расчётных заказов не считаются — это ещё не продажа.

{% endnote %}

Типы изделий ведёте вы сами — [«Типы изделий»](../directories/orderinstancetypes.md). Чем аккуратнее они заведены, тем осмысленнее отчёт: если половина изделий лежит в типе «Прочее», отчёт ничего не покажет.

## Если не получилось

**Отчёт пуст, хотя заказы за месяц были.** Скорее всего, дело в отборе **«Показать»**. При **«Сданные»** период читается по дате сдачи: заказы, оформленные в сентябре и ещё не сданные, в сентябрьский отчёт не попадут.

**Заказа нет в отчёте «Принятые».** Он либо на стадии расчёта, либо отменён — ни те, ни другие в «принятые» не входят.

**Прибыль подозрительно большая.** Проверьте затраты: если по позициям заказа не заполнена цена закупа, система не знает, сколько вы потратили.

**Рентабельность 100 %.** То же самое: затрат по заказу нет вовсе.

**Отчёт по типам изделий пустой.** За период нет проданных изделий либо все заказы остались на стадии расчёта.

**Система пишет «Произошла ошибка построения отчёта».** Сузьте период и повторите; расширенный отчёт за год на большой базе может не собраться.