Платёжный календарь 1С:ERP — управляемые платежи без Excel
Настраиваем управляемые платежи в 1С:ERP: заявка на оплату → согласование → лимиты денежных средств → платёжный календарь → загрузка факта из банка → автоматическое формирование платежных поручений для клиент-банка → выгрузка в банк платежных поручений на исполнение.
Кому подойдет этот продукт
Подходит компаниям, у которых:
- уже внедрена 1С:ERP или 1С:КА
- платежей много, приоритеты конфликтуют, срочности слишком много
- Excel стал «системой принятия решений», а 1С — «для учета»
- нужен контроль не постфактум, а до оплаты
Отрасли, в которых у нас есть опыт внедрения:
производство (пищевое, алкогольное, капиталоёмкое), торгово-производственные компании, логистика, строительство, холдинги.
.jpg)
Сложности с которыми сталкиваются компании
Формально всё работает. Фактически — управление денежными потоками заменено контролем руководителей.
Вот типовые потери, которые мы видим в компаниях до наведения порядка:
- ERP внедрена, но платёжный календарь ведётся в Excel
- до 8 часов/нед уходит на пересборку реестра и сверки «что оплатили»
- 20% согласований повторяются из-за изменения вводных
- 2-3 «кассовых сюрприза» в полугодие — не из-за бизнеса, а из-за управления
- операционист/бухгалтер «крайний» за «не тот платёж»
В чём корень проблемы
Проблема не в ERP. И не в людях. Проблема в разрыве между планом, фактом и ответственностью. Банк живёт отдельно. ERP — отдельно. Excel «склеивает» всё вручную.
В итоге:
- решение согласовали, но оплатили другое
- ответственность «размыта»
- казначейство превращается в диспетчерскую
Что мы делаем: казначейство 1С:ERP как процесс «от заявки до факта»
Финансовый контур ERP — это не просто включить модуль. Это:
- функциональный контур Казначейство 1С:ERP
- методология внедрения
- выстроенный бизнес-процесс и регламент ответственности
Мы настраиваем:
- заявки на расходование денежных средств (РДС)/заявки на оплату
- процесс согласования (маршруты, роли, правила)
- лимитирование расхода денежных средств и приоритеты (лимиты, БДДС)
- платёжный календарь 1С:ERP и реестр платежей
- интеграцию 1С:ERP с банком: выгрузка платежей и загрузка выписки/факта
Так, чтобы платёж был следствием утвержденного решения, а не ручного выбора.
Наш подход к реализации
Мы встраиваем платёжный календарь 1С:ERP в бизнес-процесс принятия решений, поэтому:
- календарь отражает реальные приоритеты
- ответственность за платёж известна заранее
- человеческий фактор исключён из критических точек
Что меняется после внедрения
Для бизнеса
- Появляется управляемый платёжный календарь
- Рост горизонта управляемости увеличивается с «2–3 дня» до 6 недель
- Решения принимаются на основе факта, а не «ощущений»
Для финансового директора
- Прогноз и контроль без ручного микроменеджмента
- Прозрачная ответственность за решения
- План/факт становится рабочим инструментом, а не отчетом «после»
- Меньше «пожаров» на 30-50 % в конце дня/недели
Для финансовой службы
- Больше контроля и меньше ошибок
- Автоматическое создание заявок по периодическим платежам «не надо помнить когда плачу аренду - система это напоминает сама»
- Понятные правила «что можно оплачивать»
- Меньше ручной сборки реестров и сверок
- Контроль дебиторской и кредиторской задолженности
Как это работает
Подтвержденный опыт на примере двух крупных ЛВЗ
- Замкнули контур оплат в 1С:ERP: заявки на расходование ДС → согласование → формирование управляемого реестра платежей с учётом условий договоров
- Дали прозрачность платежей: реестр строится из заявок и правил, а не из ручной «сводки» в файлах
- Настроили казначейство и бюджетирование «в одной логике»: финансовая структура, статьи затрат, ДДС и аналитические разрезы для согласованного учёта и управленческих решений
- Встроили лимиты в процесс: руководители подразделений контролируют исполнение бюджета по своему направлению, видят лимиты и создают заявки на расходование ДС
Важно учитывать
Продукт не подойдёт, если:
- решения принимаются устно
- ERP используется формально
- нет готовности фиксировать ответственность
Продукт подойдёт, если:
- вы хотите управлять деньгами, а не проверять людей
- ERP должна стать инструментом управления
- важна предсказуемость и контроль
Что вы получите после внедрения
- Платежи — только по утверждённым заявкам
- План/факт закрывается автоматически
- Приоритеты закреплены правилами
- Разрывы видны заранее на горизонте 30-60 дней
- Ответственность за решение прозрачна
- Меньше ручной работы с реестрами на 10–30%
- Меньше «срочных» оплат на 30–50%
Рекомендуем посмотреть
Дополнительно
Вопросы и ответы
Начинать нужно не с «кнопок», а с процесса:
- описать, откуда берутся платежи (обычно — заявки на расходование ДС),
- определить роли и маршруты согласования,
- включить лимиты/приоритеты,
- настроить формирование реестра платежей и календаря,
- подключить загрузку факта из банка.
Тогда календарь станет «рабочим местом» казначея, а не ещё одной таблицей.
В бытовом языке часто говорят «заявка на оплату», а в 1С:ERP чаще используется термин «заявка на расходование денежных средств (РДС)». По смыслу это одно и то же: документ, который фиксирует инициирование платежа, основания, статью ДДС/ЦФО и запускает согласование.
Нужны два элемента:
- заявки на РДС + согласование (решение фиксируется в системе),
- настройки процесса оплаты так, чтобы платежи попадали в реестр/календарь только из утверждённых заявок, а «ручные» обходы были ограничены регламентом и правами.
В результате формируется правило: оплатить можно только утверждённое.
Лимиты — это механизм контроля, который ограничивает платежи рамками БДДС/бюджета/утверждённых лимитов (по подразделениям, статьям, проектам и т.д.). Лимитирование позволяет:
- предотвращать «вылеты» за бюджет,
- видеть план-факт,
- снижать хаотичные платежи «по ситуации».
Да. Типовой подход — вести лимиты/БДДС в разрезе ЦФО/подразделений и сделать так, чтобы руководители ЦФО могли:
- видеть остаток лимита,
- согласовывать заявки в рамках лимитов,
- анализировать исполнение бюджета (план-факт).
В контуре казначейства настраивается:
- выгрузка платёжных поручений/реестра в банк,
- загрузка банковской выписки (факт оплат и поступлений) обратно в 1С:ERP.
Это критично для корректного план-факта и чтобы календарь отражал реальную ситуацию по деньгам.
Самая частая причина — календарь делают без «правил»:
- заявки согласуют формально, но платят «по ситуации»,
- лимитов нет или их обходят,
- факт из банка загружается нерегулярно,
- нет владельца процесса (казначейство превращается в диспетчерскую).
Мы поэтому и внедряем календарь как часть процесса: заявка → лимит → согласование → календарь → факт.