Есть пять заказов с сайта и из Telegram. Нужны не пять отдельных сообщений, а две строки: сколько заказов пришло из каждого канала и на какую сумму. Соберём ручной workflow в n8n через Summarize. Сначала проверим весь набор, затем посчитаем его. AI-модель здесь не нужна: арифметику выполняет узел, а не чат.
Результат инструкции
Report Rows выдаст site: 3 заказа на 2400 рублей и telegram: 2 заказа на 1200 рублей. Всего 5 заказов на 3600 рублей. Это суммы вымышленных заказов, не подтверждённые оплаты и не выручка. Дубль ID, строковая сумма, неизвестный канал или другая валюта остановят подсчёт: вместо частичного отчёта Input Review выдаст needs_review.
Что понадобится
- Уже установленный локальный n8n и доступ к созданию нового workflow.
- Для проверенного маршрута: Windows, Docker Desktop и n8n 2.42.4. Начальную установку можно пройти по ссылке ниже.
- Отдельная папка для JSON и около 20 минут. API-ключи, внешняя база, реальные заказы и платная модель не нужны.
Установить n8n локально через Docker
Шаг 1. Откройте учебный n8n
Откройте свой локальный редактор. Если он запущен через Docker Desktop, проверьте движок командой ниже: должен присутствовать раздел Server. Запустите свой учебный контейнер обычным способом, но не создавайте второй поверх его папки данных. В этом упражнении дополнительный API-сервер и новый открытый порт не нужны.
docker versionНаши выполнения проверены через CLI n8n 2.42.4. Самостоятельный запуск в редакторе описан по структуре узлов и официальной документации, но в этом проходе редактор не тестировался. Не обновляйте рабочий экземпляр только ради упражнения; используйте отдельный учебный.
Шаг 2. Скачайте готовый workflow
В отдельной папке выполните команду. Если файл с таким именем уже есть, выберите новое имя, чтобы не затереть свою версию. Это неопубликованная схема из семи узлов без credentials, автоматических запусков и отправки данных наружу. Перед импортом откройте JSON в редакторе и посмотрите содержимое.
curl.exe --fail --location "https://ezgpt.ru/storage/article-files/n8n-summary-demo.json" --output n8n-summary-demo.jsonСкачать готовый workflow Summarize
Шаг 3. Импортируйте схему в новый workflow
Создайте новый workflow. В меню с тремя точками выберите Import from File и n8n-summary-demo.json. Не импортируйте поверх рабочей автоматизации. Проверьте цепочку ниже: true у Valid Input идёт в Split Orders, false - в Input Review. Publish не нажимайте: достаточно Manual Trigger.
Manual Trigger → Test Orders → Valid Input
true → Split Orders → Channel Summary → Report Rows
false → Input ReviewЕсли собираете вручную, Test Orders и оба конечных узла - Edit Fields (Set), Valid Input - If, Split Orders - Split Out, Channel Summary - Summarize. Имена можно задать точно как в примере: так проще сравнить OUTPUT и тесты.
Шаг 4. Подготовьте пять заказов
Откройте Test Orders. Mode: JSON Output. Вставьте JSON ниже как обычные данные, не Expression. Узел выдаёт один item с массивом orders; это ещё не пять items. Значения amount_minor записаны целыми числами в копейках: 100000 означает 1000 рублей. У каждого заказа есть ID, канал и RUB.
Показать код (34 строк)
{
"orders": [
{
"order_id": "O1",
"channel": "site",
"amount_minor": 100000,
"currency": "RUB"
},
{
"order_id": "O2",
"channel": "telegram",
"amount_minor": 50000,
"currency": "RUB"
},
{
"order_id": "O3",
"channel": "site",
"amount_minor": 80000,
"currency": "RUB"
},
{
"order_id": "O4",
"channel": "telegram",
"amount_minor": 70000,
"currency": "RUB"
},
{
"order_id": "O5",
"channel": "site",
"amount_minor": 60000,
"currency": "RUB"
}
]
}Не добавляйте кавычки вокруг чисел. Не пишите 1 000 ₽, 1000,00 или символ валюты в amount_minor. Суммы в копейках позволяют не складывать дробные рубли; итог для показа переведём в рубли после подсчёта. Контракт упражнения: неотрицательное безопасное целое число JavaScript, одна валюта и уникальные ID без пробелов по краям.
Шаг 5. Проверьте весь набор до разделения
В Valid Input добавлено одно Boolean-условие is true. Левое значение переведено в Expression; вставьте выражение ниже. В импортированной схеме оно уже сохранено. Оно проверяет массив целиком, поэтому один плохой заказ не исчезает незаметно из суммы. Convert types where required оставьте выключенным.
{{ (() => {
const rows = $json.orders;
if (!Array.isArray(rows) || rows.length === 0) return false;
if (!rows.every(o => o !== null && typeof o === 'object'
&& typeof o.order_id === 'string' && o.order_id.trim() !== ''
&& o.order_id === o.order_id.trim()
&& ['site', 'telegram'].includes(o.channel)
&& o.currency === 'RUB'
&& Number.isSafeInteger(o.amount_minor) && o.amount_minor >= 0)) return false;
return new Set(rows.map(o => o.order_id)).size === rows.length
&& Number.isSafeInteger(rows.reduce((s, o) => s + o.amount_minor, 0));
})() }}Проверяются непустой массив, строковые ID, отсутствие повторов, каналы site/telegram, валюта RUB и целые неотрицательные суммы. Дополнительно проверяется, что общий итог остаётся безопасным целым числом. Если хотя бы одно условие не выполнено, весь item попадёт в false. В этой первой версии пустой массив тоже требует проверки: ноль найденных записей сам по себе не доказывает полноту загрузки.
В Input Review задайте Manual Mapping: status - String, Fixed needs_review; reason - String, Fixed input_invalid_or_empty. Include Other Input Fields выключено. Соедините его только с false у Valid Input. В импортированном JSON эти поля уже заполнены.
Шаг 6. Разделите orders на отдельные items
В Split Orders задайте Field to Split Out: orders и Include: No Other Fields. Destination Field Name не добавляйте. Из одного item с массивом получатся пять items, в каждом поля order_id, channel, amount_minor и currency лежат на верхнем уровне. Проверка Valid Input должна стоять перед этим узлом.
Если оставить массив внутри одного item и сразу направить его в Summarize, поля отдельных заказов не станут пятью входными записями. В OUTPUT Split Orders проверьте именно 5 items, а не один объект с пятью элементами массива.
Шаг 7. Настройте количество и сумму
Откройте Channel Summary. В Fields to Summarize добавьте два поля. Первое: Aggregation = Count, Field = order_id, Include Empty Values выключено. Второе: Aggregation = Sum, Field = amount_minor. Field содержит имя поля обычным текстом, не {{ $json.amount_minor }} и не сумму отдельного заказа.
Count здесь считает заполненные ID, а Sum складывает числовые значения. Count Unique не решает задвоение суммы: если посчитать уникальные ID, но просуммировать обе копии заказа, деньги всё равно удвоятся. Поэтому дубли в нашем примере отклоняются до Summarize.
Шаг 8. Разделите итог по каналам
Fields to Split By: channel. В Options выберите Output Format: Each Split in a Separate Item. Ignore items without valid fields to group by оставьте выключенным: проверка канала уже выполнена выше. В Channel Summary должны получиться два items с полями ниже. Порядок строк не важен, сравнивайте значения по channel.
[
{
"count_order_id": 3,
"sum_amount_minor": 240000,
"channel": "site"
},
{
"count_order_id": 2,
"sum_amount_minor": 120000,
"channel": "telegram"
}
]sum_amount_minor - сумма в копейках, count_order_id - количество заказов. Поля с такими именами получены в нашем реальном тесте узла Summarize 1.1. Если удалить channel из Fields to Split By, получится общий итог вместо двух групп; настройки Report Rows тогда тоже придётся изменить.
Параметры Summarize в официальной документации n8n
Шаг 9. Подготовьте понятные поля отчёта
В Report Rows выбран Edit Fields / Manual Mapping, Include Other Input Fields выключено. channel - String с Expression {{ $json.channel }}. orders_count - Number с выражением ниже.
{{ $json.count_order_id }}amount_minor - Number с выражением ниже. Сохраняем исходную точную сумму в копейках, а не только её представление для чтения.
{{ $json.sum_amount_minor }}amount_rub - Number с выражением ниже. currency - String с Fixed RUB, status - String с Fixed ready. ready означает, что проверенный вход посчитан; это не разрешение платить или отправлять отчёт клиенту.
{{ $json.sum_amount_minor / 100 }}Шаг 10. Выполните схему и сверяйте арифметику
Нажмите Execute workflow от Manual Trigger, а не только Execute step в последнем узле. В Report Rows должны появиться site: orders_count 3, amount_minor 240000, amount_rub 2400; telegram: orders_count 2, amount_minor 120000, amount_rub 1200. У обеих строк currency RUB и status ready.
Ручная сверка: сайт 1000 + 800 + 600 = 2400 рублей; Telegram 500 + 700 = 1200 рублей. 3 + 2 = 5 заказов, 2400 + 1200 = 3600 рублей. Input Review при этом не выполняется. Если результат другой, сначала проверьте вход и параметры группировки, а не добавляйте AI для объяснения расхождения.
Шаг 11. Проверьте неверные данные
Меняйте только копию Test Orders и после каждого изменения запускайте workflow полностью. Ожидаемый результат для всех ошибок ниже: один item в Input Review со status needs_review и reason input_invalid_or_empty, а Channel Summary и Report Rows не выполняются.
- Замените amount_minor первого заказа на строку "100000": проверка должна отклонить набор.
- Добавьте точную копию O1: повтор ID не должен увеличить итог.
- Замените amount_minor на -100000 или удалите channel: подсчёт не выполняется.
- Замените RUB одного заказа на USD: разные валюты не складываются вместе.
- Замените orders на []: пустой набор идёт на проверку, не выдаётся за подтверждённый нулевой отчёт.
Input Review специально содержит общий reason, а не точный диагноз для каждой строки. Это результат в OUTPUT, не постоянный журнал и не уведомление оператору. Для поиска причины откройте Test Orders и сравните поля с шагом 4. В рабочей версии понадобится отдельный журнал с ID выполнения и конкретными причинами.
Шаг 12. Восстановите данные и сохраните прототип
Верните JSON из шага 4, снимите закрепление тестовых данных, если включали его, и снова выполните всю схему. Итог должен вернуться к двум строкам на 3600 рублей. Сохраните workflow ручным и неопубликованным. Дополнительных контейнеров этот пример не запускает; чужие workflows, Docker volumes и базы удалять не нужно.
Если результат отличается
| Симптом | Причина | Что проверить |
|---|---|---|
| Одна группа вместо двух | Нет разделения по каналу | Fields to Split By: channel |
| Сумма меньше ожидаемой | Сумма пришла строкой | Valid Input до Summarize |
| Count равен 1 | Массив не разделён | Split Orders должен дать 5 items |
| Дубль увеличил сумму | Нет проверки ID | Уникальность до подсчёта |
| Поля отчёта пустые | Неверные имена итогов | count_order_id / sum_amount_minor |
| Только needs_review | Вход не прошёл контракт | Восстановите JSON шага 4 |
Перед подключением настоящих заказов
Уберите Test Orders только после проверки источника. Сначала получите все страницы API, затем соберите один item с полным массивом orders и сохраните тот же контракт. Не копируйте только первую страницу и не считайте, что пяти items достаточно для доказательства полноты реальной выгрузки. Наш пример использует заранее известные пять заказов.
Как получить все страницы API в n8n
Определите период, статусы оплаченных заказов, отмены и возвраты. Разные валюты разделяйте, а не складывайте под одной подписью RUB. Отрицательные суммы возвратов этот прототип отклоняет: для них нужен отдельный согласованный расчёт. Дубли сначала исследуйте; не удаляйте запись с тем же ID вслепую, если у неё изменились статус или сумма.
Не подключайте выплаты, изменение цен, удаление заказов и массовые отправки к Report Rows. Сначала добавьте постоянное хранение отчётов, обработку ошибок источника и ручную сверку с контрольной выгрузкой. Доступ к рабочим данным должен быть только для чтения. Проверка полей не гарантирует, что исходный сервис прислал все заказы.
Что проверено редакцией
11 октября 2026 года схема выполнена через CLI n8n 2.42.4 в отдельной тестовой базе. Десять сценариев: исходные пять заказов, обратный порядок, один заказ, пустой массив, строковая сумма, дубль ID, отрицательная сумма, отсутствующий канал, другая валюта и небезопасный общий итог. Точные количество, суммы и отсутствие готового отчёта при ошибке проверены. Рабочие контейнеры и существующие workflows не менялись. Запуск в редакторе, n8n Cloud, настоящая CRM, загрузка всех страниц, постоянный журнал, рассылка, возвраты и большие наборы не тестировались. Обложка - редакционная иллюстрация.
Частые вопросы
Summarize использует AI и расходует токены?
В этой схеме нет AI-модели. Summarize считает количество и сумму обычными операциями, без API-ключа LLM и расхода токенов.
Почему сумма хранится в копейках?
Вход amount_minor содержит целые числа. Сначала складываем копейки и проверяем безопасный диапазон, затем делим итог на 100 для показа в рублях. В отчёте остаются оба поля.
Почему строка "100000" не проходит проверку?
Это текст, а не Number. Проверка намеренно запрещает неявное преобразование, чтобы неправильная сумма не исчезла из расчёта. Нормализацию реальной выгрузки нужно сделать отдельно по её формату.
Почему не использовать Count Unique вместо проверки дублей?
Count Unique меняет количество, но не убирает вторую копию из Sum. Наш прототип блокирует повторяющиеся ID до подсчёта: иначе количество и деньги могут относиться к разным наборам.
Можно ли считать нулевой отчёт при пустом массиве?
Можно после отдельного подтверждения, что источник успешно вернул полный пустой набор за нужный период. Здесь такого подтверждения нет, поэтому пустой массив направляется в needs_review.
