Платёжный календарь из 1С: как увидеть кассовый разрыв

Как собрать календарь в VibeLab

Финансовый сценарий платформы объединяет данные, правила и проверку результата. Из 1С через коннектор «1С: аналитика» можно получить необходимые срезы по счетам, оплатам и обязательствам — после того как специалист сопоставит объекты конкретной базы с управленческими понятиями. Другие источники, например банк и таблица плановых выплат, подключаются отдельно по доступным интерфейсам.

Затем ИИ-сотруднику задают регламент:

1. Какие платежи считать обязательными и кто может менять дату.
2. Как отличать подтверждённое поступление от ожидаемого.
3. По каким дням строить остаток и какую минимальную величину считать сигналом риска.
4. Кто проверяет спорные строки и утверждает финальную версию календаря.

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

Какие статусы нужны каждой строке

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

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

От предупреждения к полезному действию

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

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

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

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

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

Какие ошибки искать при первой сверке

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

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

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

Первый шаг на вашей базе

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

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