Создайте приложение для предложений по перезаказу: храните min/max для каждого SKU, рассчитывайте объёмы пополнения и формируйте черновой список закупок для проверки командой.
Управление магазином часто сводится к выбору между двумя дорогостоящими ошибками: нехватка хитов продаж (потерянные продажи, недовольные покупатели) или перепокупка медленно продаваемых позиций (деньги заморожены в запасах). Ежедневная задача не в том, «есть ли у нас вообще товар?», а в том, «что нужно купить дальше и в каком количестве?», при этом не тратя час на таблицы и расчёты.
Схема min/max упрощает это решение. Для каждого SKU вы храните два числа:
Если на складе 6 единиц, min = 10, max = 25, то предложение — заказать 19. Вы не полагаетесь на память, а используете простое правило, которое сохраняет последовательность из недели в неделю.
Приложение для предложений перезаказа берёт текущие остатки (и при желании — что уже в заказе), применяет правила min/max для каждого SKU и формирует черновой список закупок. Этот черновик — основной результат: короткий, удобный для проверки список, который отвечает на вопрос «что заказать и в каком количестве?» до того, как кто‑то откроет портал поставщика или напишет менеджеру.
Что оно не делает — автоматически не отправляет заказы. Это важно, потому что у закупок есть исключения: поставщик может быть временно недоступен, упаковка товара диктует округление, сезонную позицию можно пропустить или скоро будет акция. Приложение должно быстро генерировать предложения, а человек — их утверждать, редактировать или удалять строки.
Такой инструмент обычно используют управляющие магазинами, операционные руководители и сотрудники отдела закупок. Он также полезен для небольших команд, где один человек выполняет несколько ролей и ему нужен надёжный отправной пункт.
Хорошие предложения начинаются с аккуратных, однообразных данных по SKU. Если базовая информация хаотична, черновой список будет выглядеть случайным и люди перестанут ему доверять.
Стремитесь к структуре карточки SKU, которая сохраняет свою «форму» со временем, даже если процесс меняется.
Чтобы система работала с первого дня, требуется:
Min и Max — это направляющие. Отдельная точка перезаказа полезна, если вы хотите перезаказать раньше минимума из‑за большого срока поставки или ненадёжности поставщика.
Эти поля превращают «сколько купить» в «что реально можно заказать»:
Будьте конкретны, откуда берётся «на руках». Если начинаете с ручного ввода, храните дату последнего подсчёта. Если позже подключите синхронизацию с POS или WMS, храните дату последней синхронизации. Эта деталь часто отвечает на вопрос «почему система предложила именно это?».
Min/max — простое правило: заказывать только тогда, когда запас низкий, и пополнять до безопасного уровня. Результат — черновой список, который легко понять и проверить.
Выберите один триггер и держитесь его. Самый распространённый вариант:
Это предотвращает шум от рекомендаций для вполне здоровых товаров.
Когда позиция подходит под условие, базовая идея — «дополнить до Max». Простая формула:
base_suggested = max - on_hand
suggested = max(0, base_suggested)
Пример: Min = 10, Max = 40, On Hand = 14.
Если On Hand опускается до 8:
После базового расчёта добавьте несколько правил, чтобы учесть реальную практику закупок:
Плохие данные создают плохие предложения, поэтому сделайте эти ситуации очевидными:
Лучший поток — тот, которым ваша команда будет действительно пользоваться. Сделайте его простым: зафиксировать имеющийся запас, затем сгенерировать предложения. Дополнения (этикетки, панели, аналитика) можно добавить позже.
Типичная сессия: пользователь быстро пересчитывает, выбирает местоположение (если нужно), вводит остатки по SKU, сохраняет, затем нажимает одну кнопку, чтобы создать черновой список закупок. Закупщик просматривает черновик и правит его перед утверждением.
Чтобы интерфейс не перегружал, добавьте один практичный фильтр: показывать только SKU ниже min или показывать все с явным статусом. «Только ниже min» быстрее в напряжённые дни. «Показать все» помогает убедиться, что ничего не упустили.
Простой поток, подходящий для большинства небольших команд:
Переопределения важны, потому что реальность бывает сложной. Покупатель может заказать больше из‑за акции, или меньше из‑за дефицита средств или задержки поставщика. Рассматривайте предложенное количество как стартовую точку, а не как строгое правило.
Небольшие элементы управления предотвращают много проблем:
Наконец, сохраняйте снимок при генерации черновика: временную метку, используемые остатки, min/max на тот момент и предложенные количества до внесения корректировок. Когда спросят «почему мы заказали 24?», вы откроете черновик и увидите точные входные данные, которые к этому привели.
Хорошее приложение для перезаказа начинается с небольшого набора таблиц, которым можно доверять. Цель — не идеальная ERP, а чистая база, которая может расти, когда вы добавите поставщиков, локации или более умные правила.
Для одного магазина разделите «что это за товар» и «что у вас есть» и «как вы перезаказываете»:
Это гибко: вы можете менять правила перезаказа, не переписывая карточки SKU, а черновые заказы сохранять как историю предложений и утверждённых заказов.
Если у вас сегодня только один магазин, не усложняйте с локациями. Храните инвентарь как одно число на SKU. Когда появится второй магазин или склад, добавьте таблицу Locations и переключите Inventory levels на строки на SKU на каждую локацию.
Небольшие правила валидации предотвращают ошибки ввода, превращающиеся в плохие заказы. Добавьте проверки: min должен быть меньше max, точки перезаказа не могут быть отрицательными, размер упаковки не может быть нулём. Решите, что делать при отсутствии настроек: блокировать предложения или помечать SKU как "требует настройки".
Роли помогают, когда несколько людей считают запасы и меняют настройки:
Планируйте, как будете отправлять заказы. Даже если позже автоматизируете, большинство команд начинают с простого экспорта: CSV или списка, готового для поставщика, который можно скопировать из экрана чернового заказа.
Начните с двух простых списков: каталог SKU и список поставщиков. У каждой карточки SKU должно быть название, понятное людям, поставщик по умолчанию и единица покупки (шт., коробка, картон). Делайте практично. Это тот список, который ваша команда будет искать каждый день.
Далее добавьте настройки перезаказа в карточку SKU. Min и Max — базис, но предложения станут лучше, если хранить ещё размер упаковки и срок поставки. Если один товар покупается у двух поставщиков, выберите одного по умолчанию и разрешите менять его уже в черновике.
Для ввода остатков сделайте быстрый экран, где важна скорость, а не точность: быстрый грид для редактирования работает хорошо: фильтр по проходу или категории, ввести посчитанное количество и сохранить.
Большинству команд нужны эти основные экраны:
Затем реализуйте логику предложений: для каждого SKU сравнивайте «on hand» (и при желании «on order») с вашими правилами перезаказа, вычисляйте предложенное количество, чтобы вернуть запас к max, и применяйте округление по упаковке, чтобы не предлагать 13 штук, если поставщик продаёт только коробки по 12.
Генерируйте черновой заказ для проверки и воспринимайте его как документ со статусами Draft, Approved, Sent. Когда пользователь создаёт черновик, копируйте строки предложений в строки заказа, группируйте по поставщику и позволяйте людям редактировать количества, менять поставщиков или удалять позиции.
Завершите чистым шагом вывода: кто‑то печатает черновик и делает заказ вручную, кто‑то экспортирует файл. В любом случае сохраняйте утверждённые данные, чтобы позже сравнить «предложено vs заказано» и улучшать правила на основе реальных данных.
Математика перезаказа проста. Что подрывает доверие — неправильная настройка. Большинство проблем проявляется в виде черновика, который кажется «не таким», даже если формула верна.
Классическая ошибка — смешанные единицы. Вы считаете в «шт.» а заказываете в «коробках», или приёмка — в «упаковках». Если единица SKU неясна, приложение может предложить 24, когда вы имели в виду 24 коробки. Выберите базовую единицу на SKU (часто «шт.») и храните конверсию типа «1 коробка = 24 шт.», чтобы итоговое количество корректно переводилось.
Min и Max часто устанавливают наугад. Если игнорировать скорость продаж и срок поставки, правила выглядят аккуратно, но в реальной жизни ломаются. Медленно продающийся товар с высоким max блокирует деньги, а быстрый товар с низким min приводит к нехватке.
Другие частые ошибки:
Простой сценарий: вы продаёте капсулы для кофе. На полке 6 коробок, в подсобке 18, в другом магазине 12. Если учитывать только одно «on hand», кто‑то посчитает 6 и система предложит перезаказ, хотя на самом деле у вас 36. Появление полей локаций быстро решает проблему.
Система min/max проста, но черновой список хорош ровно настолько, насколько хорошы данные за ним. Перед отправкой чего‑либо поставщику уделите минуту на поиск тихих ошибок, из‑за которых предложения выглядят уверенно, но неверны.
Начните с настроек: у каждого оборачиваемого SKU должны быть min, max (или целевой уровень) и правильный размер упаковки. Если что‑то отсутствует, приложение должно пометить SKU и либо пропустить его, либо выделить как «требует настройки». Одна пустая ячейка может незаметно породить огромный заказ или вовсе не дать заказа.
Далее проверьте реалистичность остатков. Отрицательные запасы случаются, но это редкость. Если вы видите -12 по медленно продающемуся товару, воспринимайте предложение как сигнал «проверьте», а не как команду заказать. Пересчёт или быстрый аудит транзакций дешевле, чем исправление лишних закупок.
Короткий чеклист, который ловит большинство проблем:
Правила упаковки требуют особого внимания. Если поставщик продаёт коробки по 24, а черновик предлагает 13, система должна скорректировать по вашей политике (часто округляя вверх). То же для MOQ: показывайте исходное предложение и скорректированное число, чтобы проверяющий понимал, что и почему изменилось.
Также решите, что для вашей команды «достаточно хорошо». Заказывать до max — агрессивно и может заморозить оборот. Более консервативный подход (например, до max для бестселлеров и до среднего для медленных позиций) поможет снизить перепокупки, пока доверие растёт.
Наконец, ведите аудит. Даже простые поля «последнее изменение кем» и «последнее изменение когда» повышают доверие и помогают разбирать спорные ситуации.
Представьте лавку с 30 SKU. Владелец каждое утро по понедельникам делает физический подсчёт и хочет, чтобы приложение генерировало черновой список закупок для быстрой проверки.
Он закупается у двух поставщиков: Поставщик A (снэки и напитки) и Поставщик B (товары для дома).
SKU 1: Газированная вода, упаковка по 12 (Поставщик A)
На руках: 8 упаковок. Min: 10. Max: 30. Размер упаковки: 6.
Поскольку 8 ниже min (10), приложение предлагает пополнить до max.
Нужно до max = 30 - 8 = 22 упаковки.
Округление по упаковке (6): 22 → 24.
Предложение: 24 упаковки.
SKU 2: Картофельные чипсы (Поставщик A)
На руках: 14 пакетов. Min: 12. Max: 36. Размер упаковки: 12.
Поскольку 14 выше min, предложение = 0. Даже если это не до max, товар в норме и не требует пополнения на этой неделе.
SKU 3: Средство для посуды 500 мл (Поставщик B)
На руках: 3 бутылки. Min: 6. Max: 18. Размер упаковки: 6.
Поскольку 3 ниже min, нужно пополнить до max.
Нужно до max = 18 - 3 = 15 бутылок.
Округление по упаковке (6): 15 → 18.
Предложение: 18 бутылок.
Черновик — начало, а не приказ. На этой неделе у владельца ограниченный бюджет, и он знает, что продажи газировки падают в дождливую погоду.
Он снижает Sparkling Water с 24 до 18 упаковок (по‑прежнему кратно 6). Чипсы остаются 0. Средство для посуды остаётся 18, так как это стабильный товар и ситуация кажется рискованной.
Эта проверка и правка — причина, по которой черновик чаще полезнее автоматической отправки заказов.
Поставщик A
Поставщик B
С 30 SKU этот цикл занимает около 10 минут: подсчёт, просмотр предложений, пара правок и отправка сгруппированных черновиков поставщикам.
Самый быстрый путь к ценности — начать узко. Выберите один магазин (или одну локацию) и одну группу поставщиков с управляемым набором SKU. Вы получите больше пользы от чистого, проверенного черновика, чем от попытки сразу учесть все крайние случаи.
Решите заранее, как вы будете фиксировать остатки. Ручной ввод подходит сначала, если он последовательный. Простое правило вроде «подсчёты обновляются каждый четверг перед заказом» эффективнее сложной схемы, которой никто не доверяет.
Практический план запуска:
Когда базовые вещи работают, улучшайте математику постепенно. Два апгрейда обычно окупаются быстро: оценка среднего спроса (например, средние недельные продажи за последние 4 недели) и немного защитного запаса, основанного на сроке поставки. Если поставщик даёт 10 дней, поднятие точки перезаказа на запас примерно на неделю продаж помогает пережить задержки.
Установите ритм обновления правил: еженедельно просматривайте предложения и правьте очевидные ошибки. Ежемесячно корректируйте min/max для бестселлеров и позиций с наибольшим риском перепокупки.
Если вы делаете это как безкодовое приложение, AppMaster (appmaster.io) — один из вариантов: моделируйте SKU и поставщиков в базе, поместите логику min/max в визуальный процесс и генерируйте черновой заказ, который персонал может проверить и утвердить перед отправкой.
What is a min/max reorder system in plain terms?Система min/max хранит два уровня для каждого SKU: минимальный уровень, ниже которого не следует опускаться, и максимальный уровень, до которого нужно пополнять. Когда запас опускается до минимума или ниже, приложение предлагает количество для заказа, чтобы вернуть запас к целевому уровню.
When should the app actually suggest reordering an item?Используйте одно понятное правило и придерживайтесь его: предлагать пополнение, когда запас на месте равен или ниже минимума (или вашего reorder point, если он есть). Если запас выше триггера, предложенное количество должно быть нулём, чтобы черновой список оставался спокойным и удобным для проверки.
How do you calculate the suggested quantity?Самый простой расчёт: suggested = max(0, max_level - on_hand) после того, как товар подошёл под условие для перезаказа. Это легко объяснить: вы просто заполняете запас до заранее заданной цели.
Should I include items already on order in the math?Да — если вы надёжно отслеживаете «on order», вычитайте его из того, что нужно, чтобы не купить одновременно лишний товар. Часто доступный запас считают как on_hand + on_order, а затем рассчитывают, сколько ещё нужно заказать.
How do case packs and rounding work in a reorder app?Округляйте предложения до того формата, в котором реально можно купить товар, и показывайте скорректированное число. Например, если поставщик продаёт коробки по 12, вычисленная потребность 32 должна стать 36, если ваша политика — округлять вверх, чтобы избежать нехватки.
What should happen if a SKU is missing min/max settings?Не рискуйте. Если у SKU нет значения min или max, установите предложенное количество в 0 и пометьте товар как "требует настройки", чтобы кто-то поправил данные до того, как это повлияет на закупки.
How should the app handle negative inventory counts?Отрицательный on-hand — сигнал тревоги, а не нормальная ситуация. Можно всё же посчитать предложение, чтобы покупатель видел проблему, но интерфейс должен выделять такую запись и предлагать пересчитать или проверить транзакции.
Do I need to track inventory by location (back room vs shelf, multiple stores)?Если у вас есть более одного места хранения, отслеживайте их отдельно; иначе предложения будут неверными даже при корректных min/max. Минимально разделите полку и склад, позже расширьте до отдельных магазинов и складов при необходимости.
How do I make reorder suggestions auditable and trustworthy?Сохраняйте снимок входных данных, использованных для генерации черновика: on-hand, min/max на момент расчёта и кто одобрил изменения. Тогда на вопрос «почему мы заказали 24?» будет простой ответ с исходными данными.
Can this workflow stay manual but still save time, and can I build it in AppMaster?Оставьте процесс с подтверждением человеком по умолчанию: генерируйте черновой заказ, пусть кто‑то правит количества, затем помечайте его как утверждённый и экспортируйте или скопируйте финальный список. Это легко реализовать в AppMaster (appmaster.io), моделируя SKU и черновые заказы в базе данных и переводя логику min/max в визуальный бизнес-процесс, который создаёт строки чернового заказа, сгруппированные по поставщикам, для проверки.
21 янв. 2026 г.
1 мин
20 янв. 2026 г.1 мин
20 янв. 2026 г.1 минЭкспериментируйте с AppMaster с бесплатной подпиской.
Как только вы будете готовы, вы сможете выбрать подходящий платный план.
