Допустим, в n8n пришли четыре заказа, но дальше нужны только готовые заказы от 1000 рублей. Filter оставит подходящие записи, а остальные не передаст по цепочке. Соберём такой отбор и добавим сводку, которая явно покажет результат даже тогда, когда не подошёл ни один заказ.
Результат инструкции
Workflow ezGPT - Filter Orders получает четыре вымышленных заказа. Условие: status равен ready и amount_minor не меньше 100000 копеек. Останутся O1 и O4, их общая сумма — 250000 копеек, или 2500 рублей. Сводка покажет: пришло 4, выбрано 2, исключено 2.
Отбор не меняет исходные записи и ничего не оплачивает. action_performed будет false. Если подходящих заказов нет, итог получит result no_matches и selected_count 0. Это не AI-анализ: для точного статуса и числового порога достаточно обычных условий.
Что понадобится
- Работающий n8n и права создать отдельный workflow. Пример проверен на n8n 2.42.4, узел Filter версии 2.3.
- Только вымышленные данные. API-ключи, внешняя база и платная модель не нужны.
- Неопубликованная учебная схема. Запускаем её вручную, без подключения оплаты, CRM или рассылки.
Установить локальный n8n через Docker
Шаг 1. Импортируйте готовый workflow
Скачать n8n-filter-orders.json
Создайте новый workflow. В меню редактора выберите Import from File и загрузите JSON. Если ссылка открывает текст, сначала сохраните файл через «Сохранить как». Импорт содержит четыре узла, без credentials и чужого ID workflow:
Manual Trigger → Sample Orders → Filter Orders → Filter SummarySample Orders и Filter Summary — узлы Code. Filter Orders — Filter. При ручной сборке соедините узлы последовательно и задайте эти имена: код сводки обращается к Sample Orders по имени. Не импортируйте схему поверх рабочего процесса.
Шаг 2. Подготовьте четыре заказа
Откройте Sample Orders. Mode: Run Once for All Items, Language: JavaScript. Вставьте код ниже вместо стандартного примера:
const orders = [
{
"order_id": "O1",
"status": "ready",
"amount_minor": 150000
},
{
"order_id": "O2",
"status": "pending",
"amount_minor": 180000
},
{
"order_id": "O3",
"status": "ready",
"amount_minor": 99999
},
{
"order_id": "O4",
"status": "ready",
"amount_minor": 100000
}
];
return orders.map(json => ({ json }));| Поле | Тип | Что означает |
|---|---|---|
| order_id | String | Уникальный ID заказа |
| status | String | ready или pending |
| amount_minor | Number | Целые копейки |
Нажмите Execute Step у Sample Orders после ручного запуска триггера либо выполните весь workflow. В Output должно быть четыре items, не один item с массивом внутри. Сумма 100000 записана без кавычек: это число в копейках, а не текст «100000» и не 100000 рублей.
Шаг 3. Добавьте условие по статусу
Откройте Filter Orders. В Conditions первое условие: левое значение переключите в Expression и вставьте:
{{ $json.status }}В выпадающем списке типа и операции выберите String → is equal to. Правое значение оставьте в Fixed и напишите ready. Сравниваем поле текущего item, а не текст названия столбца.
Шаг 4. Добавьте порог суммы через AND
Нажмите Add condition. Левое значение второго условия также переведите в Expression:
{{ $json.amount_minor }}Тип и операция: Number → is greater than or equal to. Правое значение: число 100000. Между двумя условиями выберите AND. Так заказ должен одновременно иметь status ready и сумму не меньше 1000 рублей.
O4 с суммой ровно 100000 должен пройти. Операция is greater than вместо is greater than or equal to его исключит. Не заменяйте AND на OR: тогда достаточно одного из условий и в отбор попадёт даже pending с большой суммой.
Шаг 5. Задайте регистр и строгие типы
В Options добавьте Ignore Case и выключите его. Статус Ready тогда отличается от ready. Пробелы по краям тоже не удаляются автоматически: « ready » не равен ready. Если источник использует разный регистр или пробелы, сначала отдельно нормализуйте данные по согласованным правилам.
Less Strict Type Validation оставьте выключенным. Число 150000 допустимо для числового сравнения, строка «150000» в нашем тесте вызвала Wrong type. Если включить менее строгую проверку, n8n может сравнить строку как число, но исходное поле в записи останется строкой. Наш код сводки такую сумму всё равно отклонит.
Не скрывайте эту проблему через Continue On Error. Для рабочей выгрузки явно преобразуйте и проверьте числа до Filter; не используйте преобразование, превращающее пустую строку в ноль.
Шаг 6. Включите обработку пустого отбора
В Settings узла Filter Orders включите Always Output Data. On Error: Stop Workflow. Execute Once оставьте выключенным, чтобы не ограничить обработку первой записью.
Обычно Filter при отсутствии совпадений передаёт ноль items, поэтому следующий узел может вообще не запуститься. Always Output Data выдаёт один служебный item с пустым JSON. Это не заказ. Следующий код должен отличить его от реальных записей.
Не подключайте выход с Always Output Data непосредственно к оплате, созданию задачи или CRM: иначе пустой объект может запустить действие. В этой схеме после Filter стоит только сводка, которая исключает пустой объект из расчёта.
Шаг 7. Добавьте сводку результата
Откройте Filter Summary. Mode: Run Once for All Items, Language: JavaScript. Вставьте код целиком:
const source = $('Sample Orders').all().map(item => item.json);
const selected = $input.all()
.filter(item => Object.keys(item.json).length > 0)
.map(item => item.json);
const seen = new Set();
for (const row of source) {
if (typeof row.order_id !== 'string' || !row.order_id.trim() || seen.has(row.order_id)) {
throw new Error('source_id_missing_or_duplicate');
}
seen.add(row.order_id);
}
let total = 0;
for (const row of selected) {
if (!seen.has(row.order_id) || !Number.isSafeInteger(row.amount_minor) || row.amount_minor < 0) {
throw new Error('selected_order_invalid');
}
total += row.amount_minor;
if (!Number.isSafeInteger(total)) throw new Error('selected_sum_out_of_range');
}
return [{ json: {
result: selected.length ? 'selected' : 'no_matches',
input_count: source.length,
selected_count: selected.length,
excluded_count: source.length - selected.length,
selected_ids: selected.map(row => row.order_id),
selected_amount_minor: total,
selected_amount_rub: total / 100,
action_performed: false,
} }];source читает исходные items из Sample Orders. selected берёт результат Filter и отбрасывает служебный пустой объект. Сводка не восстанавливает исключённые записи: она считает их количество как разность входа и отбора.
Дополнительные проверки не разрешают суммировать дробные, строковые или отрицательные копейки; повтор ID и выход суммы за безопасный диапазон JavaScript останавливают выполнение. Это защитные проверки нашего примера, не встроенные возможности Filter. Они не заменяют полную проверку всех полей исходного набора.
Шаг 8. Запустите всю цепочку
Нажмите Execute Workflow. Откройте Output узла Filter Orders: в передаваемом дальше результате должны быть O1 и O4, с исходными значениями полей. Затем откройте Filter Summary:
{
"result": "selected",
"input_count": 4,
"selected_count": 2,
"excluded_count": 2,
"selected_ids": [
"O1",
"O4"
],
"selected_amount_minor": 250000,
"selected_amount_rub": 2500,
"action_performed": false
}| Заказ | Данные | Почему прошёл или исключён |
|---|---|---|
| O1 | ready, 150000 | Прошёл оба условия |
| O2 | pending, 180000 | Не прошёл статус |
| O3 | ready, 99999 | Не прошёл сумму |
| O4 | ready, 100000 | Прошёл, порог включён |
selected означает только соответствие условиям отбора. Он не подтверждает право списать деньги, корректность заказа или согласование оператором.
Шаг 9. Проверьте границу в одну копейку
В Sample Orders временно замените сумму O4 с 100000 на 99999. Запустите весь workflow: останется только O1, selected_count 1 и selected_amount_minor 150000.
Теперь поставьте у O4 сумму 100001 и выполните цепочку заново. Останутся O1 и O4, итог — 250001 копейка, или 2500.01 рубля. Верните O4 значение 100000. Эта проверка помогает обнаружить неверную операцию сравнения или путаницу между рублями и копейками.
Шаг 10. Сравните AND и OR
На исходных данных временно переключите AND на OR в Filter Orders и запустите workflow. Пройдут все четыре заказа: O2 проходит по сумме, O3 — по статусу. Итог — selected_count 4 и selected_amount_minor 529999.
Это не поломка: OR означает «хотя бы одно условие». Для нашей задачи нужен AND. Верните его и повторите запуск: опять должны остаться только O1 и O4. Когда нужно обработать обе группы отдельными действиями, используйте If, а не пытайтесь восстановить отклонённую ветку после Filter.
If в n8n: две ветки результата
Шаг 11. Проверьте отсутствие совпадений и ошибку типа
У всех четырёх заказов в Sample Orders временно замените status на pending. Выполните всю цепочку с включённым Always Output Data: сводка должна показать result no_matches, input_count 4, selected_count 0, excluded_count 4, пустой selected_ids и нулевую сумму. action_performed false.
Теперь выключите Always Output Data у Filter и повторите запуск. Filter Summary не должен выполниться. Успешный execution без сводки не равен записанному результату no_matches. Верните Always Output Data и исходные статусы.
У O1 временно заключите 150000 в кавычки. С выключенной Less Strict Type Validation ожидается ошибка Wrong type у Filter и отсутствие успешной сводки. Верните число без кавычек. Если сумма отсутствует или равна null, в проверенном сравнении она не проходит порог; это не делает запись корректной и не объясняет, почему поле пропало.
Для ещё одной проверки поставьте у O1 число 150000.5. Сам порог оно пройдёт, но Filter Summary остановится с selected_order_invalid, потому что копейки должны быть целыми. Верните 150000. Не выдавайте проваленную проверку как успешный пустой отбор.
Шаг 12. Восстановите настройки и проверьте итог
В Sample Orders верните исходные четыре записи. В Filter Orders: ready, порог 100000, AND, Ignore Case off, Less Strict Type Validation off, Always Output Data on, On Error Stop Workflow. Сохраните изменения и выполните весь workflow ещё раз.
Итог должен точно совпасть с шагом 8: O1 и O4, 4 входных записи, 2 выбранные, 2 исключённые, 250000 копеек и action_performed false. Публиковать ручную схему для этого не нужно. Снимите pin data, если закрепляли данные для отладки, иначе повторный прогон может использовать старую выборку.
Прочитать реальные строки CSV перед отбором
Сохранить результат в Data Tables
Если результат отличается
| Симптом | Причина | Что проверить |
|---|---|---|
| Проходят pending или маленькие суммы | Используется OR | Верните AND |
| Заказ ровно на 1000 рублей исключён | Строгое больше вместо порога | Number: greater than or equal to |
| Wrong type | Сумма пришла строкой или boolean | Тип JSON и явное преобразование |
| Сводка не запускается при нуле | Нет служебного пустого item | Always Output Data и весь workflow |
| Заказов больше, чем ожидалось | Старые закреплённые данные | Снимите pin data и повторите запуск |
Перед подключением рабочих данных
Filter не удаляет заказ из CRM и не создаёт журнал исключений: он только ограничивает набор, передаваемый по текущей цепочке. Если нужно объяснить причину отказа каждому заказу или сохранить обе группы, создайте отдельную проверку и ветки, например через If.
Наш подсчёт source.length — selected.length рассчитан на один набор из Sample Orders без циклов и нескольких запусков узлов внутри одного execution. Для пакетной обработки и объединения веток нужен отдельный контроль счётчиков. Если сам источник вернул ноль items и цепочка не дошла до Filter, Always Output Data на Filter этого не исправит.
Не считайте результат selected разрешением на оплату, изменение цены или отправку сообщения. Перед такими действиями отдельно проверяются права, качество данных, дубли и подтверждение. Учебный workflow не подключён к внешним системам, а его история содержит только вымышленные заказы.
Что проверено редакцией
14 октября 2026 года схема проверена на n8n 2.42.4 в отдельном локальном Docker-экземпляре через штатные ручные запуски API. Двадцать тестов: основной отбор; сумма на копейку ниже и выше порога; отсутствие совпадений с Always Output Data и без него; прохождение всех записей; OR; регистр с Ignore Case off и on; крайние пробелы; строковая сумма со строгим и менее строгим сравнением; дробные копейки; повтор ID; переполнение суммы; отрицательная сумма; нулевой порог; отсутствующая сумма; null; boolean вместо числа. Сверены переданные items, исходные значения, ID, счётчики, суммы и action_performed false. При ошибках успешной сводки нет. Без Always Output Data пустой отбор не запускает Filter Summary; с ним пустой объект не засчитывается как заказ. Редакторские клики, Cloud, пустой источник, большие наборы, циклы и реальные интеграции не тестировались. Официальные настройки сверены с документацией и кодом штатного Filter 2.3. Учебный контейнер остановлен; чужие workflows не менялись. Обложка — редакционная AI-иллюстрация.
Частые вопросы
Чем Filter отличается от If?
Filter передаёт по цепочке только подходящие записи. If нужен, когда нужно выполнить разные действия для подходящей и неподходящей групп. В этой инструкции исключённым заказам отдельное действие не назначается.
Почему после Filter следующий узел не запускается?
Если ни одна запись не прошла, узел обычно выдаёт ноль items. Для нашей сводки включён Always Output Data, а код явно исключает служебный пустой объект из счётчика заказов.
Почему строка «150000» вызывает Wrong type?
Числовое сравнение в строгом режиме требует число. Получите или явно преобразуйте корректное числовое поле до Filter. Less Strict Type Validation может помочь сравнению, но не превращает исходную строку в числовое поле для дальнейших расчётов.
Как оставить записи, подходящие хотя бы по одному условию?
Вместо AND выберите OR. В нашем исходном наборе пройдут все четыре заказа. Для задачи «готовый заказ от 1000 рублей» это неправильное правило: здесь нужны оба условия одновременно.
Filter удаляет исключённые заказы?
Нет. Он не передаёт их дальше по своей цепочке, но не удаляет из исходной системы. В примере вообще нет записи в CRM или другой внешний сервис, action_performed false.
