Товар заканчивается: уведомления о низких остатках через n8n

MAATRIX · 17 октября 2026 · 8 мин чтения

На складе лежит двенадцать коробок. В системе тоже двенадцать. Но десять уже обещаны покупателям, одна повреждена, а последнюю вчера попросили отложить для витрины. Уведомление «запаса достаточно» в такой ситуации математически аккуратно и практически бесполезно.

Контроль остатков начинается с ответа на вопрос, какое количество действительно доступно для продажи. Затем появляются пороги, ответственные и правила повторных сигналов. n8n связывает эти части в процесс, который помогает закупщику заметить проблему раньше покупателя.

Какое число мы наблюдаем

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

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

Ключ наблюдения обычно включает товар, вариант и склад. Размеры одежды, упаковки и разные точки хранения нельзя смешивать в одну строку только по названию. При нескольких складах отдельно решите, можно ли закрывать спрос перемещением и сколько оно занимает.

Для пилота выберите небольшую группу важных товаров. У них должны быть понятные единицы измерения и ответственные. Настроить точный контроль двадцати позиций полезнее, чем отправить закупщику первую таблицу из пяти тысяч строк с пометкой «срочно».

Порог — это время на решение

Фиксированный порог подходит, когда спрос и сроки поставки достаточно стабильны. Для каждой позиции задайте минимальный доступный остаток и уровень восстановления. Например, сигнал появляется при пяти единицах и закрывается только после увеличения до восьми. Разные уровни не дают уведомлению постоянно открываться и закрываться около одной границы.

Более содержательный ориентир — ожидаемый спрос за срок поставки плюс запас на неопределённость. Но среднее значение за месяц может плохо описывать сезон, акцию или редкие крупные заказы. Прежде чем автоматизировать расчёт, сравните его предложения с решениями закупщика на нескольких реальных периодах.

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

Порог храните вместе с автором и датой изменения. Если сотрудник временно снизил его из-за распродажи, полезно указать срок действия. Иначе исключение переживёт акцию и станет незаметным постоянным правилом.

Где взять данные для n8n

Если источник — собственная PostgreSQL, предоставьте отдельной роли чтение подготовленного представления. Для внешней учётной системы используйте штатный узел или документированный API. Сопоставьте поля и проверьте, на какой момент актуальны данные.

Не запрашивайте остаток каждого товара отдельным вызовом, если API позволяет получать согласованную выгрузку. Но и не скачивайте весь каталог бесконечно, когда доступен поток изменений. Выбор зависит от возможностей источника, ограничения запросов и требуемой свежести.

Вместе с количеством сохраняйте время обновления. Если последнее успешное чтение было вчера, система должна сообщить об устаревших данных. Отсутствие свежего значения не означает нулевой остаток, а ошибка соединения не означает, что склад внезапно опустел.

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

Пошаговая схема проверки

Создайте Manual Trigger, затем чтение данных и Edit Fields для внутренней схемы. Пусть в ней будут ID товара, склад, доступное количество, порог открытия, порог закрытия и время источника. Названия полей выберите сами и сохраните соответствие с исходной системой.

Перед сравнением добавьте проверку обязательных значений. Пустое количество отправляйте в очередь ошибок данных. Не заменяйте его нулём автоматически: такая подмена создаёт ложный дефицит. В PostgreSQL агрегаты тоже требуют понимания пустых наборов и NULL; их поведение описано в официальной документации.

Далее прочитайте сохранённое состояние сигнала для пары «товар — склад». Если открытого события нет и количество достигло порога, создайте событие дефицита. Если оно уже есть, обновите наблюдаемое количество и время, но не отправляйте новое сообщение на каждом проходе.

Когда запас поднимется до уровня восстановления, закройте событие и при необходимости отправьте одно уведомление о нормализации. Если количество выросло немного, но остаётся ниже этого уровня, событие продолжает жить. Так процесс различает устойчивое пополнение и небольшое колебание.

Журнал событий храните в базе с уникальным ограничением, соответствующим вашей модели. Для первого пилота достаточно одного исполнителя. При параллельных запусках простая последовательность «проверить, затем создать» может породить два сигнала; понадобится атомарная запись или блокировка.

После ручной приёмки поставьте Schedule Trigger, задайте интервал, часовой пояс и опубликуйте workflow. Частота должна соответствовать скорости продаж и свежести источника. Проверять устаревающую раз в час выгрузку каждую секунду — довольно дорогой способ узнавать одно и то же.

Сообщение закупщику: достаточно для действия

Покажите название и артикул, склад, доступный запас, порог, резерв и ближайшее подтверждённое поступление. Добавьте ссылку на карточку в учётной системе. Если считаете рекомендованное количество, явно обозначьте его как предложение и покажите использованные исходные данные.

Для доставки подойдёт узел Telegram или корпоративная почта. Сначала отправьте пробное сообщение себе. Убедитесь, что длинные названия не скрывают важные числа, а ссылка открывает нужный товар, не результат поиска по похожей строке.

Разрешите сотруднику отметить «проверено», «заказано», «ожидаем поставку» или «не закупаем». Эти действия не должны изменять физический остаток. Они описывают работу с сигналом и помогают не тревожить человека повторно без новой причины.

Если поставка заказана, сохраните её идентификатор и ожидаемую дату. Когда дата прошла, а запас не восстановился, создайте отдельное напоминание о задержке. Сообщение «товар заканчивается» и сообщение «подтверждённая поставка опаздывает» ведут к разным действиям.

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

Что делать с особыми товарами

Комплекты требуют отдельного расчёта. Доступность набора зависит от компонентов и их количества, но компоненты могут одновременно продаваться отдельно. Не суммируйте запасы набора и деталей как независимые товары, если это один и тот же физический ресурс.

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

При перемещении между складами не учитывайте товар одновременно на отправляющей и принимающей стороне. Используйте статусы и момент учёта, принятые в вашей системе. Если источник не даёт достаточно данных, показывайте ограничение в карточке сигнала вместо уверенного расчёта.

Товары, снятые с продажи, исключайте по явному статусу. Нулевой остаток не всегда требует закупки: иногда это желаемое завершение ассортимента. История исключений поможет понять, почему система перестала напоминать о конкретной позиции.

Приёмка на одной полке

Проведите тестовую позицию через последовательность: запас выше порога, снижение, повторная проверка без изменений, небольшое пополнение, полноценное восстановление и новое снижение. Должны получиться два разных события дефицита, а не длинная переписка из одинаковых сообщений.

Затем проверьте смену порога, устаревший источник и неизвестное количество. Изменение правила должно быть видно в журнале. При недоступности учётной системы процесс сообщает о проблеме данных, сохраняя последнее известное состояние с датой.

Попросите закупщика обработать несколько сигналов без устных пояснений автора. Если он не понимает, почему пришло сообщение и что делать дальше, добавьте недостающий контекст. Автоматизация готова тогда, когда помогает принять решение, а не когда удалось отправить первое уведомление.

Для небольшого каталога и внешнего источника можно начать с VPS MAATRIX Uab Start с 4 GB RAM на поддерживаемой Ubuntu или Debian. Большие снимки, локальная база и расчёт комплектов потребуют замера ресурсов; Heka Standard с 8 GB может быть следующим ориентиром для пилота. Сохраняйте историю сигналов и резервные копии настроек, ограничивайте доступ к закупочным данным.

VPS MAATRIX с n8n позволит проверять запас по расписанию, пока сотрудники заняты складом и поставщиками. Хороший сигнал приходит не тогда, когда полка уже пуста, а тогда, когда у человека ещё есть время что-то предпринять.