Возможности УПП 1.3

 

Доступно – соответствующие подсистемы УПП 1.3:

 

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

 

 

Если попробовать в типовой конфигурации, в файловом режиме, открыть форму документа «Заявка на расход д/с» (она же, ЗРДС), то сразу возникает ошибка по переменной «глОбщиеЗначения» из общего модуля «РаботаСОбщимиПеременными».

Такого рода ошибки можно будет исправить, однако, как говорится: «осадочек остался». Т.е «шероховатостей» в подсистеме ЗРДС УПП – хватает.

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

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

При работе с ЗРДС важное место занимает регламент согласования и утверждения заявок. В зависимости от организационной структуры предприятия и других особенностей бизнеса, внутренний порядок согласования заявок (регламент согласования) может быть достаточно сложным (многоступенчатым, вариативным и т.д). Таким образом, для автоматизации это – не простая задача.

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

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

Утверждение – это завершающее подтверждение (со стороны казначея) того, что заявка будет оплачена. При этом обязательно должна быть определена дата платежа, расчетный счет/касса с которой будет осуществлена оплата. Таким образом, платеж попадает в оперативный план (платежный календарь).

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

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

 

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

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

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

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

Для каждого подразделения можно назначить соответствующую точку маршрута согласования. Суть в этом такая: при оформлении заявки (ЗРДС) обязательно должно быть указано ЦФО (подразделение). И в зависимости от указанного подразделения, УПП «находит» соответствующую ему точку согласования и «отправляет» заявку на согласование в эту точку.

 

Так же в настройке маршрута согласования допустимо не указать подразделение. В этом случае, такая точка согласования будет «применятся» для всех ЦФО, для которых конкретно не указана соответствующая точка маршрута.

Само согласование выполняется с помощью специальной обработки «Согласование заявок».

 

 

 

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

 

Помимо планируемого расхода д/c (ЗРДС) можно учитывать и планируемое поступление д/c. Для этих целей предусмотрено оформление специального документа «Планируемое поступление д/c».

 

 

Нужно отметь, что документ «Планируемое поступление д/c» хотя и есть состояния (подготовлен, согласован и т.д), возможность согласовать этот документ (так же как ЗРДС) отсутствует. Т.е. изменение статусов документа возможно только в режиме «ручного управления».

И еще в УПП есть возможность учитывать планируемое поступление д/с от покупателей без оформления документов «Планируемое поступление д/с».

Т.е если для покупателя оформляются «Заказы клиентов», то в отдельном отчете «Платежный календарь с учетом заказов» это запланированное поступление д/c можно будет увидеть.

 

Помимо отчета «Платежный календарь» предусмотрен отчет «Анализ доступности денежных средств».

 

При этом предусмотрена возможность резервировать д/c (по заявкам на расход) или размещать заявки в счет запланированных поступлений.

 

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

Однако, данная функциональность так же не поддерживается в режиме тонкого/web-клиента.

Здесь нужно понимать, что методика «жесткого резервирования» сильно завязана на хронологию ввода документов, и это затрудняет корректировки и перепланирование.

По этому, функциональность оставлена в УПП скорее как «наследие прошлого», а для анализа доступности д/c следует применять платежный календарь.

Помимо задачи календарного планирования и контроля остатков д/c существует (и востребована) другая, схожая c ней задача – контроль задолженности по дням/ срокам долга. Зачастую, могут называть (и понимать под) «платежным календарем» - задолженность (просроченную и текущую), сгруппированную по датам, по интервалам.

В УПП предусмотрены отчеты «Дебиторская задолженность по срокам/по интервалам».

 

 

Однако важно понимать, что целей управленческого применение этих отчетов сильно ограничено. Суть в следующем:

· Во-первых, в этих отчетах анализируется фактическая задолженность и не учитывается планируемая, т.е, ожидаемое увеличение задолженности клиентов не учитывается (например, по оформленным заказам), а учитывается только свершившиеся факты отгрузки и т.п.

· Во-вторых, учитываются только расчеты покупателями, но не учитываются расчеты с поставщиками.

При оформлении ЗРДС есть возможность автоматически контролировать заявку на предмет превышения запланированных бюджетов. Однако, эта функциональность не работает в тонком/web-клиенте, т.е в режиме «обычного приложения» в заявке предусмотрена закладка «Бюджетирование», на которой можно указывать статью оборотов по бюджетам, а так же сценарий. И если эти данные указаны, то УПП выполняет соответствующий контроль по подсистеме бюджетирования.

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

 

По документу «Заявка на расходование д/c»:

1. В документе можно указать «Подразделение» (кстати, в конфигурации оно обозначено как ЦФО – центр финансовой ответственности). Но вполне возможна ситуация, когда заявка оформляется от одного подразделения (ЦФО), и при этом затраты нужно будет далее отнести/распределить на другое/другие подразделения (ЦФУ – центры финансового управления). Возможность указывать ЦФУ и т.д. – отсутствует.

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

3. «Управлять» выбором маршрута согласования заявки можно только по средствам установки (при первоначальном вводе документа) подразделения. Но на практике, могут требоваться «отклонения» от обычных маршрутов, переадресация (в определенных случаях) заявки на других ответственных лиц и т.д. Возможность изменять маршрут, перенаправлять заявку на другие маршруты – отсутствует.

1. Отсутствует возможность запланировать перемещение д/c между расчетными счетами, cо счета в кассу и прочее.

2. Процесс согласования:

1. Существует возможность согласовывать ЗРДС, но отсутствует возможность согласовывать планируемое поступление д/с.

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

3. В процессе согласования заявок, когда заявка переходит на согласование следующему по маршруту, востребована функциональность автоматического информирования (по e-mail) следующего исполнителя, а так же автора заявки.

4. Если автор заявки уже является ответственным за согласование/утверждение (на любом из этапом маршрута!), то вполне логично что бы программа автоматически «сокращала» маршрут, переадресую заявку на наиболее высокий, доступный уровень. Однако, в УПП это не предусмотрено.

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

1. Отчеты, права доступа.

1. Востребована возможность ограничения доступа к заявкам только по доступным авторам / исполнителям (согласователям); по доступным пользователю подразделениям.

2. Отсутствует отчетность по контролю (по дням и интервалам) фактической и запланированной задолженности. Это актуально и для покупателей и для поставщиков.

3. Отчетность и часть функционала не пригодны для работы в режиме тонкого/web-клиента.

2. Учет по регулярным соглашениям, договорам.

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

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