Кейс: особенности работы с автоматически созданными Заявками на оплату в 1С:УХ 3.2

Заявки на оплату позволяют эффективно контролировать денежные потоки и своевременно расплачиваться по обязательствам.

Варианты создания заявок на оплату

В системе 1С:УХ 3.2. существует два способа создания заявок на оплату:

• ручной;
• автоматический.

При ручном способе документ создается из журнала документов «Заявки на оплату» раздела «Казначейство». В форме списка нажимается кнопка «Создать» (см.рис.1).

Рисунок 1. Создание заявки на оплату

При создании по умолчанию устанавливается вид заявки «Оплата поставщику». При необходимости, вид операции меняется из перечня доступных вариантов по команде «Выбрать из списка» — «Показать все» (см.рис.2).

Рисунок 2. Подбор вида операции в заявке на оплату

В зависимости от выбранного вида операции, будет зависеть реквизитный состав вкладки «Основное». Например, при выборе вида операции «Оплата поставщику» обязательные к заполнению реквизиты: Организация, Контрагент, Договор, Сумма платежа (см.рис.3).

Рисунок 3. Заполнение обязательных реквизитов в заявке на оплату

При выборе вида операции «Перечисление заработной платы работнику» обязательны к заполнению реквизиты: Организация, Сотрудник, сумма (см.рис.4).

Рисунок 4. Заполнение обязательных реквизитов в заявке на оплату

Также следует отметить, что при ручном создании заявок на оплату выбор договора ограничивается видом операции (см.рис.5). Например, если выбран тип операции «Оплата поставщику», то при выборе договора доступны только виды:

— С поставщиком;

— С комитентом (принципалом) на продажу;

— С комиссионером (агентом) на продажу;

— С комитентом (принципалом) на закупку;

— С комиссионером (агентом) на закупку;

— Ввоз из ЕАЭС;

— Импорт;

— С переработчиком;

— С поклажедателем;

— Расчетно-кассовое обслуживание;

— Страхование.

Рисунок 5. Ограничения видов договоров

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

Из опыта внедрения! При необходимости, данный функционал изменяется посредствам доработки – снятием автоматической отправки на согласование. Данная доработка необходима в тех случаях, когда плановые данные не подлежат согласованию, но при этом они необходимы для формирования каких-либо отчетных форм (например, Отчет по планам).

Автоматическое формирование заявок на оплату включается в настройках блока Казначейство (Раздел «Общие справочники и настройки» — подраздел «Настройки») (см.рис.6). Там же задается настройка — за сколько до наступления даты платежа будет формироваться заявка.

Автоматически формируются следующие виды заявок:

— Оплата поставщику;

— Возврат поставщику;

— Выдача займа контрагенту;

— Возврат займа контрагенту;

— Возврат кредита банку.

Рисунок 6. Настройки автоматического формирования заявок

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

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

Также следует отменить, что в типовой системе 1С:УХ 3.2 если в заявке, отправленной на согласование, частично не заполнены поля, то на последнем этапе перед утверждением система выдает ошибку. Тогда либо заявка отклоняется текущем согласующим и возвращается инициатору на доработку, после чего процесс согласования возобновляется, либо корректируется согласующим (если в настройках предоставлена возможность редактирования на этапах согласования), после чего утверждается документ.

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

Особенности настроек договоров

При оформлении как коммерческих, так и финансовых договоров в случае, если вводится график расчетов и планируется автоматическое формирование документов планирования (Заявки на оплату, Планируемы поступление ДС), необходимо особое внимание уделять ряду настроек, благодаря которым снизится вероятность возникновения потребности ручных корректировок в автоматически созданных документах.

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

На вкладке «Планирование» в группе реквизитов «Расчеты и платежи» представлено два параметра настройки (см.рис.7):

— Режим актуализации графика при изменении первичных документов;

— Режим актуализации заявок.

Рисунок 7. Настройки режимов в договоре

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

• По настройкам системы – в зависимости от настроек системы будет действовать режим Не актуализировать/ Создавать новые версии / Обновлять текущую версию.

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

• Не актуализировать – вне зависимости от того, будет ли отклонение плановых данных от фактических, текущая версия будет оставаться неизменной.

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

• Создавать новые версии – автоматически создаются новые версии спецификации, в случае отклонения плановых данных от фактических (банковских выписок).

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

• Обновлять текущую версию – при отклонении банковских выписок от плана автоматически обновляется текущая версия, тем самым затираются исторические данные планирования.

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

Режим актуализации заявок включает в себя два варианта настройки:

• По настройкам системы

Как будет работать данный режим зависит от константы «Автоматически актуализировать заявки по графикам договоров» (см.рис.8).

Рисунок 8. Настройки актуализации заявок

Данная настройка применима для всех Договоров в целом, в которых сформирован график расчетов.

Если флажок «Автоматически актуализировать заявки по графикам договоров» установлен, то тогда при ручном изменении аналитик в заявке, программа при очередной актуализации (запуске регламента) снимет с проведения старую заявку (в которую внесены были ручные корректировки) и создаст новую с теми же аналитиками, которые прописаны в Договоре.

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

• Не актуализировать

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

Также на вкладке «Планирование и учет», перед тем как будет введен график расчетов, необходимо заполнить все аналитики, которые при автоматическом создании будут по умолчанию устанавливаться в заявке на оплату, во избежание потребности вносить корректировки после создания документа (см.рис.9):

Поле «ЦФО» – организация, являющаяся центром финансовой ответственности по договору. Данный реквизит является обязательным к заполнению.

Поле «Проект» — заполняется, если ведется учет по проектам.

Поле «Статья движения денежных средств» – статья бюджета, по которой будет проходить расход.

Поля «Аналитики» — заполняются, если по статье ДДС предусмотрен учет по аналитикам.

Рисунок 9. Аналитики к заполнению в договоре

После заполнения аналитик, можно приступать к формированию графика расчетов. Аналитики в графики будут заполнятся автоматически на основании данных, введенных на вкладке «Планирование и учет» (см.рис.10).

Рисунок 10. Аналитики в графике договора

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

Рисунок 11. Параметры операций графика

Таким образом, при заполнении аналитик на этапе формирования договоров отпадает необходимость вносить изменения непосредственно в заявки.

Особенности работы с автоматически созданными заявками на оплату

Автоматически созданные заявки на оплату на основании графиков договоров можно отобрать в журнале документов «Заявки на оплату» с использование отбора «Это операция по графику» по команде «Еще» — «Настроить список» (см.рис.12).

Рисунок 12. Осуществление отборов в журнале «Заявки на оплату»

Заявка на оплату по умолчанию заполняется данными из Договора.

Система на вкладке «Контроль документа» выводит предупреждение о том, что в случае ручных корректировок, данная заявка будет приведена с соответствие графику, что приведет к дублированию документов (см.рис.13).

Рисунок 13. Контроль документа

Например, поменяем на вкладке «Аналитики учета и планирования» аналитику статьи ДДС с «Компьютеры» на «Мебель офисная» и проведем документ (см.рис.14).

Рисунок 14. Вкладка «Аналитики учета и планирования» документа «Заявка на оплату»

После автоматического запуска регламента, система сняла с проведения документ, в который мы внесли корректировку, и создала новый документ с теми же аналитиками, которые были до внесения корректировок (см.рис.15).

Рисунок 15. Журнал документов «Заявки на оплату»

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

Либо же, устанавливать в Договоре «Режим актуализации заявок» — «Не актуализировать» (как описано выше в статье), тогда, даже если будут внесены корректировки в заявку, дублирование в системе происходить не будет.

Принципы работы с инструментами контроля документов

Одной из причин необходимости внесения корректировок после создания документов планирования является несоответствие введенных статей и аналитик установленным бюджетам (БДДС, БДР).

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

В случае если введенные платежи превышают сумму доступного лимитам, программа выводит на вкладке «Контроль документа» восклицательный знак (см.рис.16).

Рисунок 16. Контроль документа «Заявка на оплату»

Нажав на пиктограмму «Подробнее», можно вывести расшифровку по контролю бюджетных лимитов (см.рис.17).

Рисунок 17. Контроль документа «Заявка на оплату»

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

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

В случае, если суммы графика соответствует бюджетным лимитам, то в карточке договора на вкладке «Контроль документа» данные вида контроля «Контроль бюджетных лимитов» подсвечиваются зеленым цветом (см.рис.18).

Рисунок 18. Положительный контроль документа «Заявка на оплату»

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

После автоматического формирования документа «Заявка на оплату» на вкладке «Контроль документа» помимо контроля лимитов включается контроль резервов (см.рис.19).

Рисунок 19. Контроль документа «Заявка на оплату» с учетом резерва

Если в данном документе изменить хотя бы одну аналитику, то контроли нарушатся и при очередной актуализации система создаст повторно новую заявку с аналитиками, указанными в договоре (см.рис.20).

Рисунок 20. Отрицательный контроль документа «Заявка на оплату» с учетом резерва

Для контроля лимитов служит отчетная форма «Отчет по лимитам» (Раздел «Планирование и контроль» подраздел «Отчеты»), в которой по колонке «Лимит» отражается сумма установленного лимита, а по колонке «Доступный лимит» — остаток лимита (см.рис.21):

Рисунок 21. Отчет по лимитам

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

Проблемы при автоматизации блока Казначейство в 1С:УХ 3.2

В процессе автоматизации блока Казначейства компании сталкиваются с рядом проблем:

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

Для решения данных проблем при автоматизации необходимо:

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

Получите бесплатную консультацию от экспертов NFP Первый Бит