Содержание

Кассовый разрыв возникает, когда наступает срок платежа, а доступных денег не хватает. Ожидаемая оплата заказа может прийти через несколько дней, но поставщику, арендодателю или сотрудникам нужно платить раньше. Чтобы увидеть такую нехватку заранее, составьте платёжный календарь: начальный остаток, поступления и выплаты с конкретными датами.
Разберём вымышленный пример небольшой мастерской. В конце расчётного периода у неё останется 60 000 ₽, но между двумя оплатами не хватит 70 000 ₽. Ниже — формула, таблица по дням и учебный календарь, в котором можно заменить суммы своими. Затем покажем, как поставить задачу на такую форму в mottorable и проверить результат.
Что показывает кассовый разрыв
Для текущего платежа имеют значение доступная сумма и дата её поступления. Подписанный заказ, выставленный счёт и обещание клиента заплатить позже сами по себе не увеличивают остаток на банковском счёте. Поэтому бизнесу полезно отдельно следить за результатом продаж и движением денег.
Разницу между сроками поступлений и выплат описывает Яндекс Пэй в разборе кассового разрыва. Для нашей задачи достаточно практического вывода: проверять нужно каждую дату обязательного платежа, даже если общий итог периода выглядит благополучно.
Показатели отвечают на разные вопросы. Юнит-экономика помогает разобрать доход и расходы отдельного заказа или клиента. Точка безубыточности — объём продаж для покрытия включённых затрат. Платёжный календарь показывает, хватит ли доступных средств к нужному дню. Одного из этих расчётов недостаточно для двух остальных.
Почему продажи растут, а платить нечем
Проверьте, где именно расход и связанное с ним поступление разошлись по времени. Например, мастерская закупает материалы перед началом работы, а клиент переводит остаток оплаты после приёмки. Магазин оплачивает новую поставку, пока предыдущая ещё находится на складе. В обоих случаях деньги уже нужны, а поступление ожидается позже.
Другой источник нехватки — неполный список выплат. В календарь внесли поставщиков и аренду, но забыли про согласованную покупку оборудования, очередной платёж или возврат клиенту. Прогноз выглядел положительным только потому, что часть движений в него не попала.
Начните со сверки конкретных дат и сумм. Объяснение «сейчас мало продаж» слишком общее: оно не показывает, какой платёж создаёт дефицит, когда он возникает и какая сумма нужна для выбранного плана.
Формула расчёта по дням
Для каждой даты используйте одно уравнение:
Остаток на конец дня = остаток на начало дня + поступления − выплаты.
Остаток предыдущего дня становится начальным для следующего. Если в день нет движений, сумма переносится без изменений. Такой принцип платёжного календаря описан и в материале Сбера о расчёте кассового разрыва.
Чтобы определить максимальную нехватку в выбранном прогнозе, найдите самый низкий остаток. Если он отрицательный, возьмите его величину без знака минус. Если все остатки неотрицательные, дефицита по введённому плану нет.
Например, последовательность остатков −40 000, −70 000, 80 000 и 60 000 ₽ означает максимальную нехватку 70 000 ₽. Складывать два отрицательных остатка и получать 110 000 ₽ нельзя: второй остаток уже включает предыдущее движение денег.
Минус в таблице — расчётная потребность в средствах. Он не означает, что банк разрешит провести платёж при недостаточном остатке.
Пример: мастерская получает оплату позже закупки
На начало периода доступны 80 000 ₽. Мастерская запланировала четыре движения. Все числа и даты вымышлены; это учебная модель, а не данные клиента.
| Дата | Движение | Поступление | Выплата | Расчётный остаток |
|---|---|---|---|---|
| 5 ноября | Оплата поставщику | 0 ₽ | 120 000 ₽ | −40 000 ₽ |
| 8 ноября | Аренда | 0 ₽ | 30 000 ₽ | −70 000 ₽ |
| 10 ноября | Оплата заказа клиентом | 150 000 ₽ | 0 ₽ | 80 000 ₽ |
| 12 ноября | Дополнительные материалы | 0 ₽ | 20 000 ₽ | 60 000 ₽ |
Проверим первые две строки. После оплаты поставщику расчёт даст 80 000 − 120 000 = −40 000 ₽. Затем аренда увеличит нехватку: −40 000 − 30 000 = −70 000 ₽. Оплата заказа 10 ноября вернёт прогноз в положительную область.
Если посмотреть только на весь период, получится 80 000 + 150 000 − 170 000 = 60 000 ₽. Итог верный, но из него не видно, что денег на платежи 5 и 8 ноября не хватает. Именно поэтому для этой задачи нужен расчёт по датам.
Откройте учебный платёжный календарь или скачайте исходную таблицу CSV. В календаре уже заполнены четыре движения: первый день дефицита — 5 ноября, максимальная нехватка — 70 000 ₽, остаток на конец — 60 000 ₽.
Как составить свой платёжный календарь
Зафиксируйте доступные деньги на начало
Возьмите остаток, которым можете распоряжаться для включённых в модель платежей. Если часть средств зарезервирована и вы исключаете её из доступного остатка, не вычитайте ту же сумму повторно как будущую выплату.
Для начала удобно считать один понятный денежный контур: например, один счёт и связанные с ним платежи. Если объединяете несколько счетов, учитывайте переводы между ними последовательно. Перемещение собственных средств внутри объединённого контура не должно искусственно увеличивать общее поступление.
Внесите будущие движения с датами
Для каждой строки нужны дата, поступление, выплата и короткое пояснение. Дата должна отражать ожидаемое движение денег. Если клиент обещает оплатить 10 ноября, продажа 3 ноября не переносит эти деньги на неделю раньше.
Проверьте ближайшие обязательства по своим документам: договоры, счета, графики и согласованные покупки. Размеры и сроки налогов, зарплаты и других платежей берите из собственного учёта; учебная форма их не определяет.
Отделите факт от ожидания
Запланированное поступление ещё не подтверждает оплату. Когда деньги действительно пришли, сверяйте сумму и дату с фактом. Если срок изменился, обновите прогноз и пересчитайте будущие остатки.
Наш учебный календарь работает с одним набором плановых движений. Отдельного учёта статусов «план» и «факт» в нём нет. Если добавляете такую функцию в собственное приложение, заранее задайте правило: одна операция после оплаты не должна попадать в расчёт дважды.
Проверьте ближайшую отрицательную дату
Запишите три результата: когда впервые не хватает средств, каков максимальный дефицит и какой остаток получается в конце выбранного периода. Вместе они помогают увидеть и срок задачи, и её размер.
Нулевой остаток в модели означает, что перечисленные движения сошлись без запаса. Он не учитывает незапланированные траты и ошибки исходных данных. Для оценки устойчивости сделайте отдельный сценарий с задержкой ожидаемой оплаты.
Как проверить изменение сроков на том же примере
Допустим, в учебном сценарии удалось согласовать получение части оплаты раньше. Из общей суммы 150 000 ₽ клиент перечислит 70 000 ₽ 4 ноября, а оставшиеся 80 000 ₽ — 10 ноября. Общая сумма заказа и все выплаты сохраняются.
| Дата | Поступление | Выплата | Расчётный остаток |
|---|---|---|---|
| 4 ноября | 70 000 ₽ | 0 ₽ | 150 000 ₽ |
| 5 ноября | 0 ₽ | 120 000 ₽ | 30 000 ₽ |
| 8 ноября | 0 ₽ | 30 000 ₽ | 0 ₽ |
| 10 ноября | 80 000 ₽ | 0 ₽ | 80 000 ₽ |
| 12 ноября | 0 ₽ | 20 000 ₽ | 60 000 ₽ |
В этом варианте отрицательных остатков нет, а итог периода по-прежнему равен 60 000 ₽. Изменилось распределение поступлений по датам. Скачайте CSV второго сценария, чтобы сравнить строки.
Это проверка арифметики согласованного плана. Она не доказывает, что конкретный клиент согласится на раннюю оплату. Любое изменение сроков сначала нужно согласовать с участниками сделки и только затем отражать в рабочем прогнозе.
Если изменить поступления не удаётся, можно так же проверить другой допустимый план выплат или дополнительный источник средств. Введите реальные условия и посмотрите, где останется нехватка. Сам календарь не выбирает финансовый инструмент и не рассчитывает его стоимость за вас.
Что умеет учебная форма и где её границы
Календарь принимает начальный остаток и строки движений, сортирует даты, объединяет операции одного дня и пересчитывает остаток. Он показывает первую отрицательную дату, максимальную нехватку и итог. Результат можно скачать в CSV для сверки.
Данные в отдельном HTML-файле сохраняются локально в браузере, если такое хранение доступно. Это удобно для учебного расчёта, но не заменяет резервную копию. Другой браузер или устройство не получит эти записи автоматически; очищенное хранилище их не восстановит. Рабочие сведения лучше сохранять отдельно.
Расчёт показывает остаток на конец дня. Если утром нужно выплатить 100 000 ₽, а такое же поступление придёт вечером, итог дня может быть нулевым, хотя утром денег недостаточно. Для подобного сценария нужна более подробная модель со временем и порядком операций.
Форма не подключается к банку, не отправляет платежи, не сверяет бухгалтерский учёт и не раздаёт доступ сотрудникам. Эти возможности нельзя считать готовыми по наличию полей и таблицы.
Как подготовить такую форму в mottorable
Для небольшого расчёта сначала достаточно одного экрана и нескольких проверяемых правил. В mottorable мы импортировали готовый HTML-календарь и проверили его в приватном предпросмотре: базовые суммы, увеличение начального остатка, отказ от отрицательного ввода, неверную дату и возврат учебного примера. Публичный пилот для этого не запускался.
Если хотите собрать свой вариант по описанию, начните с ограниченного задания:
Подготовь учебную форму платёжного календаря для небольшой мастерской.
Поля: доступный остаток на начало, дата, поступление, выплата, пояснение.
Сортируй движения по датам и объединяй суммы одного дня.
Остаток дня = предыдущий остаток + поступления − выплаты.
Покажи первый день отрицательного остатка, максимальную нехватку и итог.
Не складывай отрицательные остатки разных дней.
Используй только вымышленные данные. Начальный остаток 80000.
5 ноября: выплата 120000; 8 ноября: выплата 30000;
10 ноября: поступление 150000; 12 ноября: выплата 20000.
Ожидается: первый дефицит 5 ноября, максимальная нехватка 70000, итог 60000.
Проверяй даты и неотрицательные суммы с точностью до копеек.
Явно укажи: расчёт по концу дня, без банка, отправки платежей и общего доступа.
Не добавляй реальные клиентские данные или новые интеграции.В примере нет банковских платежей, общей базы и доступа команды. Эти функции требуют отдельной приёмки.
Запустить ТЗ в MottorableОписание задаёт ожидаемый результат, но не гарантирует, что сгенерированная версия сразу посчитает всё верно. Сверьте её с контрольными значениями ниже. Любые дополнительные функции — например, роли сотрудников, напоминания или загрузку выписки — проверяйте отдельно до использования.
Начните свою форму в mottorable, если готовы адаптировать поля и пройти приёмку. Для самого расчёта дефицита можно продолжать пользоваться скачанным учебным календарём без регистрации.
Как проверить календарь перед использованием
В базовом примере должно получиться: −40 000, −70 000, 80 000, 60 000 ₽ по четырём датам. Затем увеличьте начальный остаток до 150 000 ₽: дефицит исчезнет, итог составит 130 000 ₽.
Переставьте исходные строки местами. Результат должен сохраниться, потому что расчёт следует датам, а не порядку ввода. Попробуйте неверную дату и отрицательную сумму: форма должна объяснить ошибку и не оставлять старый результат как действующий.
Отдельно проверьте сохранение именно в той среде, где собираетесь работать. Записи предпросмотра не подтверждают сохранность после публикации, а локальное хранилище не подтверждает доступ с другого устройства. Для командной работы нужны собственные проверки прав и хранения.
После технической приёмки остаётся регулярная сверка с фактическими поступлениями и выплатами. Полезный календарь отвечает на конкретный вопрос: какой платёж, в какую дату и при каких исходных данных создаёт нехватку денег.
Частые вопросы
Почему денег не хватает, если итог периода положительный?
Итог объединяет все движения периода. В учебной мастерской оплата приходит 10 ноября, а крупные выплаты запланированы раньше: к 8 ноября прогноз достигает −70 000 ₽. После поступления денег итог становится положительным.
Нужно складывать отрицательные остатки за несколько дней?
Нет. Для максимальной нехватки берут самый низкий остаток со знаком плюс. Каждый следующий остаток уже учитывает прошлые движения; их повторное сложение завысит потребность.
Учитывает ли календарь утренние и вечерние платежи?
Учебная версия объединяет операции одной даты и считает закрытие дня. Для контроля утренней выплаты до вечернего поступления нужен порядок операций внутри дня.
Сохранятся ли записи на другом устройстве?
В скачанном файле используется локальное хранилище браузера. Общей базы и синхронизации нет. Сохранность данных и права команды для рабочего приложения нужно проверять отдельно.