Казначейство в 1С:ERP: заявки на оплату, лимиты и очередь платежей

Практический материал по подсистеме казначейства в 1С:ERP. Не заменяет финансовый регламент компании: лимиты, статьи ДДС и маршрут согласования задаёте вы. Официальное описание — «Казначейство» и «Планирование и контроль денежных средств» на 1С:ИТС.

Короткий вывод

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

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


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

Из каких документов состоит контур

Базовый набор планирования — в главе про планирование и контроль ДС:

• заявка на расходование денежных средств — исходящая потребность;
• ожидаемое поступление — чтобы календарь видел приход, а не только расход;
• распоряжение на перемещение — между счетами и кассами без «рисунка» в Excel.

Статусы заявки обычно идут по цепочке «не согласована → согласована → к оплате / оплачена / отклонена». Рабочее место согласования как раз и нужно для пакетной обработки, а не для того, чтобы каждый документ открывать отдельно.

Сложные маршруты (сумма, ЦФО, статья ДДС, замещение) часто выносят в 1С:Документооборот с бесшовной связкой. Это нормальный сценарий, если в ERP не хотите раздувать статусы. Ненормальный сценарий — согласование в почте и статус в ERP «по памяти».

Лимиты: зачем они ломаются в первый же месяц

Лимиты расходования можно вести документами лимитов и/или через бюджет движения денежных средств. Пример контроля «по документам лимитов» описан в документации линейки ERP/УТ; по БДДС ориентир — лимиты расходования ДС.

Лимит не работает, если:

• оплата идёт без заявки;
• статья ДДС в заявке «Прочее», потому что так быстрее;
• лимит задан на месяц, а заявки ставят датой «как получится»;
• часть платежей проводят в одной организации, лимит смотрят по другой;
• возвраты и комиссии банка не попали в ту же аналитику.

Пока эти обходы живы, отчёт по лимитам можно показывать руководству только как демо.


Казначейский стол: календарь платежей, карточки счетов, без логотипов банков и читаемого интерфейса

Как запускать, чтобы очередь стала рабочей

1. Включите заявки и запретите списание без распоряжения на выбранных счетах — не на всех сразу, если есть зарплатный или налоговый поток со своими правилами.
2. Соберите статьи ДДС до уровня, которым реально пользуются инициаторы. Слишком дробный справочник убивает заявки быстрее, чем отсутствие лимита.
3. Назначьте приоритеты оплаты: налоги, зарплата, критичные поставщики, остальное.
4. Ведите платёжный календарь на неделю, а не «на квартал в одной картинке».
5. Раз в неделю разбирайте частично оплаченные и просроченные заявки — иначе очередь превращается в свалку.

Налоги через ЕНП тоже должны жить в этой очереди, а не мимо неё: иначе казначейство видит «дыру», которой в банке нет, или наоборот.

Что прописать в финансовом регламенте

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

Казначейство в ERP начинает экономить время, когда заявка становится единственной дверью в банк. Пока дверей две, лимиты — декорация.

Контакты: it-digit.ru/about/contacts · +7 (495) 646-01-17 · sales@it-digit.ru