Казначейство в 1С: что контролировать и какую систему выбрать

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

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

Выбор программы начинается не со сравнения кнопок. Сначала компания описывает этот процесс и степень централизации. Затем становится понятно, достаточно ли 1С:Комплексной автоматизации, нужен ли контур 1С:ERP, требуется ли 1С:Управление холдингом или отдельная казначейская система.

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

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

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

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

Сквозной процесс расхода выглядит так:

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

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

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

Казначейский контур удобно проектировать не по документам программы, а по управленческим вопросам.

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

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

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

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

Последствия появляются по цепочке:

В официальной документации 1С:ERP казначейство описано как отдельный набор сценариев планирования, лимитирования и движения денег. Но сама настройка не отвечает на организационный вопрос: какие платежи обязаны идти через заявку, кто может создать исключение и как оно будет видно в календаре.

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

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

Инициатор описывает потребность и прикладывает основание. Он не должен выбирать любой удобный вид платежа, если от этого зависит лимит и аналитика.

Владелец бюджета или руководитель ЦФО подтверждает, что расход нужен подразделению и соответствует его приоритетам.

Финансовый контролёр проверяет статью, бюджет, лимит, договорные условия и влияние на финансовый план.

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

Утверждающий руководитель принимает решения по крупным суммам, исключениям и конфликтующим приоритетам.

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

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

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

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

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

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

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

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

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

Чтобы сравнение продуктов не превратилось в спор вкусов, зафиксируйте ответы:

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

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

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

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

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

Лимитирование имеет смысл, когда статьи и ЦФО уже стабильны, а заявки проходят через систему. Решите, что происходит при превышении: запрет, дополнительное согласование или осознанное изменение бюджета.

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

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

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

Перед настройкой проверьте:

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

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

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

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