Платёжный календарь: данные, прогноз и сверка с фактом

Как спроектировать платёжный календарь в ERP: источники, план и факт, частичные платежи, версии прогноза, права и проверка расчёта.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

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

Статья предназначена руководителю проекта автоматизации, финансовой команде и разработчикам ERP-модуля. Рассматриваем требования к программе и проверке данных, а не рекомендации по инвестициям, кредитованию или выбору платежей. Управленческие решения остаются у уполномоченных сотрудников. Учебные примеры не являются финансовыми результатами клиентов 404gen.

Что должен объяснять платёжный календарь

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

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

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

План, обязательство, разрешение и факт

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

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

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

Модель данных будущего ERP-модуля

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

Откуда брать данные и кто ими владеет

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

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

Документация Microsoft Dynamics 365 о прогнозировании денежных потоков описывает настройку источников и счетов ликвидности. Это пример того, что прогноз строится из выбранного контура данных. Конкретные правила вашей учётной системы проверяются отдельно; перенос названий полей из чужого продукта не определяет готовую архитектуру.

Сценарии для проектирования и приёмки

Одно обязательство появилось из двух источников

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

Загрузите оба документа сначала по отдельности, затем повторно вместе. Итоговый прогноз должен учитывать потребность один раз, а карточка — показывать оба основания. Отдельно добавьте действительно независимые одинаковые счета. Они не должны исчезнуть из прогноза из-за слишком агрессивного поиска дублей.

Часть запланированного платежа исполнена

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

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

Поступление перенесли на другую дату

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

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

Банковский обмен остановился

Виджет должен сохранить последний известный остаток с отметкой времени и показать, что новые данные не поступают. Подстановка нуля создаёт ложный дефицит, а скрытое продолжение графика без предупреждения — ложную актуальность. Управленческий экран должен объяснять ограничение до того, как пользователь примет решение.

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

Внутренний перевод проходит через два счёта

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

Проверьте календарь по каждому счёту и общий отчёт. Совокупное изменение не должно удваиваться. Между списанием и зачислением нужен объяснимый промежуточный результат, если он предусмотрен источником. Несопоставленная сторона переводится в очередь сверки; система не выдумывает подтверждение ради красивого баланса.

План ведётся в нескольких валютах

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

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

Документ согласован, затем его сумму изменили

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

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

Операцию загрузили после закрытия периода

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

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

Сотрудник видит не все организации

Ограничение доступа применяется к календарю, расшифровкам, поиску и выгрузкам. Скрытая строка не должна раскрывать сумму через общий итог, если это нарушает модель полномочий. Иногда руководителю разрешён агрегат без деталей; это отдельное право, которое проверяется явно, а не случайный побочный эффект интерфейса.

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

Пользователь сравнивает несколько вариантов

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

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

Как должен выглядеть рабочий экран

Начните с периода, организации и валюты, затем покажите начальный остаток, ожидаемые движения и конечное состояние. Любой итог раскрывается до исходных записей. Цвет помогает увидеть отклонение, но смысл должен быть выражен текстом. Отдельно обозначайте отсутствие данных, отрицательный прогноз и неподтверждённую часть ожиданий: это разные состояния.

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

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

Контроль качества расчёта

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

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

Пилот и границы первой версии

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

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

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

Частые вопросы

Чем календарь отличается от отчёта о движении денег?

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

Обязательно ли сразу подключать банк?

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

Можно ли сделать календарь поверх существующей ERP?

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

Почему совпавший общий остаток ещё не означает верный расчёт?

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

Какие материалы нужны для оценки разработки?

Подготовьте карту источников, обезличенный пример периода, правила согласования и список доступных API или выгрузок. Укажите владельца каждого поля, порядок исправлений и ожидаемую свежесть данных. Это позволяет оценить интеграции и сверку. Тариф и срок проекта определяются после разбора объёма, а не по одной картинке календаря.

Подготовить требования к платёжному календарю

Запишите, какие решения команда принимает по календарю, на какие сведения опирается и что произойдёт при задержке источника. Для каждого показателя нужен путь до исходной записи. Такой документ помогает отличить полезный ERP-модуль от второго несогласованного финансового реестра.

Обсудить реализацию можно на странице разработки ERP-модулей. Для связанного процесса пригодится статья про согласование документов, а для наблюдения за итогами — материал о BI для управленческой отчётности. Передавайте для обсуждения обезличенные схемы и примеры, а не банковские доступы.